De drie knooppunten van het basisdienstencluster staan in drie rekken; uitval van een rek is voor dit cluster uitval van één knooppunt. De bundel over het leafpaar vangt uitval van een poort, kabel of leaf op, en het capaciteitsbudget zorgt dat twee knooppunten alle diensten dragen.
Onderwerp
Foutdomeinen, uitval en uitsluiting
Hoe het basisdienstencluster de uitval van een exemplaar, een knooppunt of een rek opvangt, en hoe een dienst met één exemplaar pas elders start als het oude knooppunt aantoonbaar is uitgeschakeld.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
- Domein
- Volgt uit
- Functies
- Producten
- Verwant
Wat het is
Het basisdienstencluster heeft drie knooppunten in drie rekken. Dit onderwerp legt vast hoe de exemplaren over de knooppunten zijn gespreid, wat er gebeurt bij uitval van een exemplaar, een knooppunt, twee knooppunten, het opslagcluster of de cel, en hoe een dienst met één exemplaar veilig op een ander knooppunt start.
Waarom zo
Met drie knooppunten moet iedere dienst de uitval van één knooppunt of rek doorstaan. Het versiebeheer en het firmwarebeheer hebben maar één exemplaar. Zij starten elders pas als vaststaat dat het oude knooppunt uit is, want twee schrijvers op één volume beschadigen de gegevens. Die uitsluiting gaat automatisch via iLO, zodat de hersteltijd niet van een beheerder afhangt.
Spreiding
Een dienst met drie exemplaren staat op drie knooppunten, een dienst met twee op twee, met een verstoringsbudget (PodDisruptionBudget) van één exemplaar.
Toelichting
Gecontroleerd met plaatsingsregels en de uitvalproef.
Quay, Clair, NetBox en ieder onderdeel van de automatisering hebben ten minste twee exemplaren. Alleen het versiebeheer en het firmwarebeheer zijn enkelvoudig.
Toelichting
De exemplaren per basisdienst staan bij De basisdiensten en hun plaatsing.
Uitval
Uitval van één knooppunt of rek onderbreekt geen dienst met meer exemplaren merkbaar. Het versiebeheer is binnen 15 minuten terug, het firmwarebeheer binnen 30 minuten.
Toelichting
Aangetoond met een halfjaarlijkse uitvalproef onder referentiebelasting. De proef meet de onderbreking per dienst, inclusief de databases en volumes waarvan de diensten afhangen.
Per gebeurtenis ligt vast hoe het basisdienstencluster zich gedraagt en hoe het herstelt.
| Gebeurtenis | Gedrag | Herstel |
|---|---|---|
| Uitval van een exemplaar | Geen merkbare onderbreking; een database schakelt over op een replica | Herstart door het cluster; bij beschadigde gegevens uit back-up |
| Uitval van een knooppunt of rek | etcd en Raft houden quorum; iedere dienst met meer exemplaren houdt er één; het paar van de externe verkeersverdeling schakelt over; versiebeheer en firmwarebeheer starten na uitsluiting elders | Knooppunt herstellen of vervangen; Raft-lid, replica’s en virtuele machines opnieuw opgebouwd; tot dan geen reserve |
| Uitval van twee knooppunten | Geen quorum: geen nieuwe geheimen, verlengingen, certificaten of clusterwijzigingen; tijdelijke inloggegevens verlopen | Knooppunten terug, anders etcd en Raft uit de laatste momentopname, vóór ieder ander herstel in de cel |
| Uitval van het opslagcluster | Diensten op lokale opslag werken door; containerregistry, versiebeheer, firmwarebeheer en sessieopname vallen uit | Herstart na herstel van het opslagcluster; beheer tot dan via de noodroute |
| Hardwaresleutelmodule onbereikbaar | Draaiende exemplaren van het geheimenbeheer werken door; een herstart ontgrendelt niet, ook niet met de herstelsleutels | Geen herstart tot de module terug is |
| Uitval van naam- of tijdvoorziening | Naamgebruik en certificaatcontroles mislukken | Herstel door netwerkbeheer |
| Verlies van de cel | Alle basisdiensten van de cel vallen uit; de andere cel werkt met haar eigen exemplaren | Herbouw in de herstelvolgorde, vanuit code en herstelkern; het versiebeheer vanaf groeipadstap 2 in cel 2 uit de laatste dagelijkse export, daarvóór vanuit de herstelkern |
| Vermoeden van compromittering | Geheimenbeheer en toegangsvoorziening zijn het doel | Isoleren, intrekken en sleutels vervangen; herbouw vanuit de herstelkern met nieuwe geheimen en een nieuwe tussen-CA |
Verliest het cluster zijn quorum, dan komen etcd en Raft terug uit de laatste momentopname, vóór ieder ander herstel in de cel. Wijzigingen en intrekkingen van na die momentopname worden daarna opnieuw doorgevoerd.
Uitsluiting bij één exemplaar
Het versiebeheer draait als één exemplaar met strategie Recreate en een snelle herstart na uitsluiting, binnen 15 minuten. Twee actieve exemplaren worden niet ondersteund: wachtrijen, geplande taken en cache kennen geen leider. De clusters draaien intussen door op hun laatste inrichting.
Toelichting
Afgewezen alternatief: twee actieve exemplaren. Dat past alsnog bij een versie die het ondersteunt.
Een dienst met één exemplaar start pas elders als het oude knooppunt aantoonbaar is uitgeschakeld of van het volume is losgekoppeld. Zo zijn er nooit twee schrijvers op één volume.
Toelichting
Aangetoond met een uitvalproef met isolatie.
Een melding dat een knooppunt onbereikbaar is, start op de automatisering een vooraf goedgekeurd draaiboek, zonder tussenkomst van een beheerder. Daarna herstarten versiebeheer en firmwarebeheer vanzelf op een ander knooppunt.
| Stap | Handeling |
|---|---|
| 1 | De bewaking meldt dat een knooppunt langer dan 5 minuten onbereikbaar is |
| 2 | Het uitsluitingsdraaiboek start op de automatisering |
| 3 | Een uitvoeringsknooppunt schakelt het knooppunt via iLO uit en controleert de uitschakeling |
| 4 | Het knooppunt krijgt de taint ‘out-of-service’ |
| 5 | Kubernetes koppelt de volumes los en start de dienst op een ander knooppunt |
Toelichting
Toont iLO de uitschakeling niet aan, dan volgt geen herstart tot platformbeheer het knooppunt ter plaatse heeft uitgeschakeld. De automatische uitsluiting is een voorwaarde bij de acceptatie; de terugvaloptie is dat platformbeheer het draaiboek start. Afgewezen alternatief: herstart na beoordeling door platformbeheer, omdat de hersteltijd dan van een beheerder afhangt.