De startvolgorde is een vertraging, geen afhankelijkheid
Iedereen stelt de startvolgorde in met de verwachting dat de tweede machine wacht tot de eerste klaar is. Dat doet hij niet. Hij wacht een vast aantal seconden en start daarna hoe dan ook, en daarom faalt de volgorde die in de test werkte op de ochtend van een echte stroomstoring.
AtlasPVE ·
Dit artikel beantwoordt
- proxmox startvolgorde
- proxmox boot order werkt niet
- proxmox vm startvertraging
- proxmox afsluitvolgorde
- proxmox start order
De host komt terug na een stroomstoring en de helft van wat zou moeten draaien, draait niet. De databasemachine staat aan, maar de toepassing ervoor heeft het opgegeven, of een container kon opslag niet aankoppelen die een andere container nog aan het opstarten was. Er is niets kapot en niemand heeft een fout gelogd die het lezen waard is. De onderdelen kwamen simpelweg in de verkeerde volgorde omhoog.
Hier houdt de vorm van uw opstelling, welke gast van welke afhangt, op een schema in uw hoofd te zijn en wordt zij iets dat de machine daadwerkelijk uitvoert. Het loont om precies te weten wat dat mechanisme doet, want het is smaller dan de meesten aannemen.
De zin die de meeste verrassingen verklaart
De startvertraging is een interval, geen voorwaarde.
Wanneer u een gast een vertraging geeft, start Proxmox VE die gast, wacht het opgegeven aantal seconden en gaat dan door naar de volgende. Het controleert niet of het opstarten binnen de gast klaar is. Het controleert niet of een dienst antwoordt. Het wacht en gaat verder.
De opstelling in uw hoofd, "de toepassing wacht op de database", wordt dus nooit geconfigureerd. Wat wordt geconfigureerd is: "de toepassing start negentig seconden nadat de database is opgedragen te starten". Bij een rustige testherstart zijn die twee niet te onderscheiden. Na een echte stroomstoring, wanneer schijven trager zijn, een bestandssysteemcontrole draait of een gast in de herstelmodus opstart, wel.
Vier regels om te kennen voordat u getallen invult
De laagste start eerst en sluit als laatste af. De afsluitvolgorde is de omkering van de startvolgorde; er is geen aparte instelling. Een gast met volgorde 1 is de eerste omhoog en de laatste omlaag, en dat is meestal precies wat u wilt voor datgene waar al het andere van afhangt.
Gelijke getallen zijn niet willekeurig. Gasten met dezelfde volgorde worden bovendien oplopend op kenmerk gesorteerd. Gelijke standen zijn dus stabiel en voorspelbaar, en u hoeft niet elke gast een uniek nummer te geven om herhaalbaar gedrag te krijgen.
Gasten zonder volgorde starten altijd na de gasten met een volgorde. Dat is nuttiger dan het klinkt. U hoeft niet alles te nummeren. Nummer de drie of vier dingen die echt vroeg moeten zijn en laat de rest met rust.
De volgorde geldt voor één host, niet voor het cluster. Zij kan niet uitdrukken dat een gast op knooppunt A vóór een gast op knooppunt B omhoog moet komen. Zodra uw afhankelijkheid een knooppuntgrens oversteekt, heeft dit mechanisme daar niets over te zeggen.
De val die later opduikt
Gasten die door de hogebeschikbaarheidsstapel worden beheerd, negeren zowel starten bij opstarten als de startvolgorde. De start- en stopprocedure slaat ze volledig over, want de hogebeschikbaarheidsbeheerder bepaalt wanneer ze draaien.
Deze bijt laat. Eén host met een zorgvuldig afgestemde volgorde werkt een jaar lang. Dan komt er een tweede knooppunt, gaan enkele gasten onder hoge beschikbaarheid, en stopt hun volgorde stilletjes met gelden. Niets waarschuwt u, want er is niets fout; de verantwoordelijkheid is alleen verschoven.
De vertraging die u eigenlijk wilt, is vaak een andere
Een veelvoorkomende reden om naar vertragingen per gast te grijpen is een externe bron: netwerkopslag die bereikbaar moet zijn voordat iets haar aankoppelt, of een switch die even nodig heeft. Die tijd kopen door losse gasten uit elkaar te trekken is een onhandige weg, want het rekt de hele reeks op.
Er bestaat een aparte instelling per knooppunt precies hiervoor: een vertraging tussen het einde van het opstarten van de host en de eerste automatisch startende gast. Eén getal, één keer toegepast, en wel op de plek waar het wachten werkelijk thuishoort.
Het getal dat niemand instelt tot het pijn doet
De afsluittijdslimiet is standaard 180 seconden per gast. Proxmox VE vraagt de gast af te sluiten, wacht, en als de gast bij het verstrijken nog draait wordt hij hardhandig gestopt. Een verzamelde stop van alle gasten heeft een eigen totaallimiet van drie minuten voordat hetzelfde gebeurt.
Voor een machine die bij het afsluiten naar schijf wegschrijft, is dat plafond het waard om bewust te controleren in plaats van het tijdens een storing te ontdekken. De standaard is royaal voor de meeste gasten en te kort voor enkele, en juist die enkele zijn degene waar een geforceerde stop u iets kost.
Wat we in de praktijk werkelijk zien
Op de host waarmee het hier beschreven gedrag is gecontroleerd, waren negen gasten geconfigureerd en stonden er drie op starten bij opstarten. Geen enkele had een startvolgorde.
Dat is de normale gang van zaken, en vaak is dat prima. Machines die niet van elkaar afhangen hebben geen volgorde nodig. Het doel van dit stuk is smaller: als u ooit hardop hebt gezegd dat een gast eerst een andere omhoog nodig heeft, dan leeft die zin op dit moment alleen in uw geheugen, en een stroomstoring leest uw geheugen niet.
Wat Atlas doet
Atlas herschikt niets voor u en verzint geen afhankelijkheidssysteem bovenop dat van Proxmox VE. Wat het doet is de verbanden zichtbaar maken in één beeld in plaats van gast voor gast, zodat de vraag "wat hangt hier eigenlijk waarvan af" gesteld kan worden terwijl de machine rustig is en niet terwijl zij terugkomt.
De vorm zien configureert haar niet. Maar niemand stelt een verstandige volgorde in voor een opstelling die hij nooit getekend heeft gezien.
Bronnen
De eigen documentatie van Proxmox. In het Engels, en die heeft over dit onderwerp het laatste woord.