Uitval, back-up en herstel

Het rek is het foutdomein van het clusterbeheer: uitval van één werkerknooppunt of één rek laat iedere besturing beschikbaar. Het gedrag bij uitval en het herstel staan in de tabel.

Valt een werkerknooppunt van het clusterbeheer weg, dan houdt iedere besturing haar quorum en draaien de toepassingen door. Bij verlies van de hele besturing stoppen nieuw uitrollen, opnieuw plannen en opschalen; dat bestaande processen doordraaien, maakt de dienst nog niet volledig beheersbaar.

Vanuit een applicatiecluster gezien is het gedrag bij uitval zoals in de tabel.

In de herstelvolgorde van de cel volgt het clusterbeheer op het vlootbeheer. Een herstart vraagt alleen fabric, naam- en tijdvoorziening en lokale opslag, zolang de beelden op de knooppunten staan; een nieuw knooppunt, een nieuw cluster of een terugzetting vraagt ook de basisdiensten, het vlootbeheer, de objectopslag en de werkervirtualisatie.

Een herbouw van een applicatiecluster begint pas als naam- en tijdvoorziening, geheimenbeheer, containerregistry, toegang en opslag van de cel werken. Na besturing, werkers en standaardinrichting volgen, zodra het nalevingsoverzicht ‘voldoet’ toont, de toepassingen en volumes uit de gecontroleerde kopie.

Ieder gehost cluster heeft een vast API-adres uit de geregistreerde reeks van de cel, met een vaste naam die bij herstel gelijk blijft, omdat herstel uit een momentopname dezelfde naam vraagt. Bij herstel in de andere cel of in de herstelomgeving krijgt het een adres uit de reeks van die cel, en de naam wijst pas naar het nieuwe adres na uitsluiting van de oude besturing.

Van iedere besturing en van het clusterbeheer zelf bestaat iedere 6 uur een etcd-momentopname en dagelijks een back-up van de clusterobjecten, met een versleutelde, onveranderbare kopie buiten de cel. De momentopnamen lopen als geplande taak, één cluster tegelijk per cel. Een momentopname pauzeert de afstemming van het cluster met een eindtijdstip en hervat haar altijd.

Clusterobjecten en volumes van een applicatiecluster hebben een back-up volgens het back-upschema, met een onveranderbare kopie buiten de cel: per naamruimte een DataProtectionApplication en een Schedule, met een eigen RGW-gebruiker en bucket per cluster. Databases volgen de eigen back-up van de beheerde database. Het cluster is uit code en back-up opnieuw op te bouwen.

Na blijvend verlies van een werkerknooppunt heeft iedere besturing binnen 1 werkdag weer drie etcd-exemplaren, op de koude reserveserver. Na verlies van het clusterbeheer worden de besturingen teruggezet in de volgorde: het besturingscluster van het dienstennetwerk, de clusters in bedrijfskritische productie, die in reguliere productie, het bouw- en het portaalcluster, en ten slotte die in ontwikkelen en beproeven.

Een verloren configuratiedatabase wordt teruggezet uit de laatste bruikbare momentopname, met de sleutelversie van het tijdstip van die momentopname. De LoadBalancer-diensten komen terug met hun geregistreerde adres, en naam en route worden gecontroleerd. De eigen sleutel per cluster gaat daarom mee in de back-up, en een vervangen sleutel blijft bewaard zolang momentopnamen haar nodig hebben.

Op een herbouwd clusterbeheer wordt een besturing alleen teruggezet langs de route die bij de acceptatie is aangetoond: uit de momentopname, met de volumes uit de back-up binnen het cluster. Anders wordt het gastcluster uit code en back-up opnieuw opgebouwd.

Een applicatiecluster dat in de herstelzone wordt teruggezet, krijgt een definitie met storageDriver Manual: zijn volumes komen uit de kopie op de gastklasse van de werkervirtualisatie en gaan pas bij de terugkeer naar productie naar het opslagcluster. Wordt het in de herstelzone van de andere cel teruggezet, dan krijgt het een API-adres uit de reeks van die cel en gebruikt de API-server het certificaat van de eigen clusterautoriteit van het cluster, omdat de tussen-CA van de andere cel die naam niet uitgeeft. Vanaf groeipadstap 2 staat de herstelomgeving van iedere cel op het clusterbeheer van de andere cel, op de vrije plaats.

Het terugzetten van een besturing wordt ieder kwartaal beproefd, de herbouw van het clusterbeheer ieder half jaar in de leeromgeving. Bij de acceptatie is een momentopname met de bijbehorende sleutel teruggezet in de leeromgeving, en met de productiesleutel in de herstelomgeving.

Valt een cel uit, dan neemt de andere cel een dienst in bedrijfskritische productie over: de oude kant wordt uitgesloten, de andere cel wordt leidend en de terugkeer verloopt gecontroleerd. De naam van het cluster wijst pas om na uitsluiting van de oude kant.

Bij een incident op het clusterbeheer trekt platformbeheer samen met het SOC de rechten in, vervangt het de sleutels en toegangsbewijzen van de betrokken clusters en zet het zo nodig een besturing van vóór de aantasting terug, eerst in de herstelomgeving. Bij een beveiligingsincident in een applicatiecluster isoleert het platform de naamruimte of het cluster volgens het SOC: verkeer dicht, werklast stoppen, identiteiten intrekken en bewijs bewaren.