Startrækkefølgen er en forsinkelse, ikke en afhængighed

Alle sætter startrækkefølgen i troen på, at den anden maskine venter, til den første er klar. Den venter ikke. Den venter et fast antal sekunder og starter så alligevel, og derfor svigter den rækkefølge, der virkede i test, den morgen strømmen faktisk gik.

AtlasPVE ·

Denne artikel besvarer

  • proxmox startrækkefølge
  • proxmox boot order virker ikke
  • proxmox vm startforsinkelse
  • proxmox nedlukningsrækkefølge
  • proxmox start order

Værten kommer tilbage efter et strømsvigt, og halvdelen af det, der burde køre, gør det ikke. Databasemaskinen er oppe, men programmet foran den gav op, eller en container kunne ikke montere lagring, som en anden container stadig var i gang med at starte. Intet er i stykker, og ingen loggede en fejl, der er værd at læse. Delene kom simpelthen op i forkert rækkefølge.

Her holder formen på din opsætning, hvilken gæst der afhænger af hvilken, op med at være en skitse i hovedet og bliver noget, maskinen faktisk udfører. Det betaler sig at vide præcis, hvad den mekanisme gør, for den er smallere, end de fleste går ud fra.

Sætningen, der forklarer de fleste overraskelser

Startforsinkelsen er et interval, ikke en betingelse.

Når du giver en gæst en forsinkelse, starter Proxmox VE den gæst, venter det antal sekunder du angav, og går derefter videre til den næste. Den tjekker ikke, om opstarten blev færdig inde i gæsten. Den tjekker ikke, om en tjeneste svarer. Den venter og fortsætter.

Opstillingen i dit hoved, "programmet venter på databasen", bliver altså aldrig det, der konfigureres. Det, der konfigureres, er "programmet starter halvfems sekunder efter, at databasen fik besked på at starte". Ved en rolig testgenstart kan de to ikke skelnes. Efter et rigtigt strømsvigt, når diskene er langsommere, et filsystemtjek kører eller en gæst starter i nødtilstand, kan de.

Fire regler værd at kende, før du sætter tal

Lavere starter først og lukker ned sidst. Nedlukningsrækkefølgen er den omvendte af startrækkefølgen; der findes ingen særskilt indstilling. En gæst med rækkefølge 1 er først op og sidst ned, og det er som regel netop, hvad man vil have for det, alt andet afhænger af.

Ens tal er ikke tilfældige. Gæster med samme rækkefølge sorteres desuden efter stigende identitet. Uafgjorte tilfælde er derfor stabile og forudsigelige, og du behøver ikke give hver gæst sit eget nummer for at få gentagelig opførsel.

Gæster uden rækkefølge starter altid efter dem, der har en. Det er mere nyttigt, end det lyder. Du behøver ikke nummerere alt. Nummerér de tre eller fire ting, der virkelig skal være tidligt, og lad resten være.

Rækkefølgen gælder én vært, ikke klyngen. Den kan ikke udtrykke, at en gæst på knude A skal op før en gæst på knude B. I samme øjeblik afhængigheden krydser en knudegrænse, har denne mekanisme intet at sige om sagen.

Fælden, der dukker op senere

Gæster, der styres af højtilgængelighedsstakken, ignorerer både start ved opstart og startrækkefølgen. Start- og stopproceduren springer dem helt over, fordi det er højtilgængelighedshåndteringen, der afgør, hvornår de kører.

Denne bider sent. En enkelt vært med omhyggeligt afstemt rækkefølge fungerer i et år. Så kommer en anden knude, nogle gæster flytter under høj tilgængelighed, og deres rækkefølge holder stille op med at gælde. Intet advarer dig, for intet er galt; ansvaret skiftede blot hænder.

Den forsinkelse, du egentlig vil have, er ofte en anden

En almindelig grund til at gribe efter gæsteforsinkelser er en ekstern ressource: netværkslagring, der skal være tilgængelig, før noget monterer den, eller en switch, der har brug for et øjeblik. At købe den tid ved at sprede enkelte gæster er en klodset vej, for det strækker hele forløbet.

Der findes en særskilt indstilling per knude netop til dette: en forsinkelse mellem at værten er færdig med at starte, og at den første automatisk startende gæst går i gang. Ét enkelt tal, anvendt én gang, og netop det sted, hvor ventetiden faktisk hører hjemme.

Tallet, ingen sætter, før det gør ondt

Tidsgrænsen for nedlukning er som standard 180 sekunder per gæst. Proxmox VE beder gæsten lukke ned, venter, og hvis gæsten stadig kører, når tiden udløber, stoppes den med magt. Et samlet stop af alle gæster har sin egen samlede grænse på tre minutter, før det samme sker.

For en maskine, der skriver til disk ved nedlukning, er det loft værd at tjekke med vilje i stedet for at opdage under et nedbrud. Standarden er rundhåndet for de fleste gæster og for kort for nogle få, og netop de få er dem, hvor et tvunget stop koster dig noget.

Hvad vi faktisk ser i praksis

På den vært, der blev brugt til at tjekke adfærden beskrevet her, var ni gæster sat op, og tre var sat til at starte ved opstart. Ikke én havde en startrækkefølge.

Det er den normale tilstand, og ofte er det helt fint. Maskiner, der ikke afhænger af hinanden, behøver ingen rækkefølge. Formålet med denne tekst er smallere: har du nogensinde sagt højt, at en gæst har brug for, at en anden er oppe først, så lever den sætning lige nu kun i din hukommelse, og et strømsvigt læser ikke din hukommelse.

Hvad Atlas gør

Atlas omarrangerer ikke noget for dig og opfinder ikke et afhængighedssystem oven på det, Proxmox VE har. Det, Atlas gør, er at gøre sammenhængene synlige i ét billede i stedet for én gæst ad gangen, så spørgsmålet "hvad afhænger egentlig af hvad her" kan stilles, mens maskinen er rolig, og ikke mens den er på vej tilbage.

At se formen konfigurerer den ikke. Men ingen sætter en fornuftig rækkefølge for en opstilling, de aldrig har set tegnet.

Kilder

Proxmox’ egen dokumentation. På engelsk, og den har det sidste ord i dette spørgsmål.

Relaterede artikler

Hvordan ser det ud inde i Atlas?

Gå til produktsiden