Startrekkefølgen er en forsinkelse, ikke en avhengighet

Alle setter startrekkefølgen i troen på at den andre maskinen venter til den første er klar. Den venter ikke. Den venter et fast antall sekunder og starter så uansett, og derfor svikter rekkefølgen som fungerte i test den morgenen strømmen faktisk gikk.

AtlasPVE ·

Denne artikkelen svarer på

  • proxmox startrekkefølge
  • proxmox boot order virker ikke
  • proxmox vm startforsinkelse
  • proxmox avslutningsrekkefølge
  • proxmox start order

Verten kommer tilbake etter et strømbrudd, og halvparten av det som skulle kjøre gjør det ikke. Databasemaskinen er oppe, men programmet foran den ga opp, eller en beholder klarte ikke å montere lagring som en annen beholder fortsatt holdt på å starte. Ingenting er ødelagt, og ingen logget en feil verdt å lese. Delene kom rett og slett opp i feil rekkefølge.

Her slutter formen på oppsettet ditt, hvilken gjest som avhenger av hvilken, å være en skisse i hodet og blir noe maskinen faktisk utfører. Det lønner seg å vite nøyaktig hva den mekanismen gjør, for den er smalere enn de fleste antar.

Setningen som forklarer de fleste overraskelsene

Startforsinkelsen er et intervall, ikke en betingelse.

Når du gir en gjest en forsinkelse, starter Proxmox VE den gjesten, venter det antallet sekunder du oppga, og går så videre til neste. Den sjekker ikke om oppstarten ble ferdig inne i gjesten. Den sjekker ikke om en tjeneste svarer. Den venter, og fortsetter.

Oppstillingen i hodet ditt, "programmet venter på databasen", blir altså aldri det som konfigureres. Det som konfigureres er "programmet starter nitti sekunder etter at databasen fikk beskjed om å starte". Ved en rolig testomstart lar de to seg ikke skille. Etter et ekte strømbrudd, når diskene er tregere, en filsystemsjekk kjører eller en gjest starter i redningsmodus, gjør de det.

Fire regler verdt å kunne før du setter tall

Lavere starter først og slås av sist. Avslutningsrekkefølgen er den omvendte av startrekkefølgen; det finnes ingen egen innstilling. En gjest med rekkefølge 1 er først opp og sist ned, og det er som regel akkurat det man vil ha for det alt annet avhenger av.

Like tall er ikke tilfeldige. Gjester som deler samme rekkefølge sorteres i tillegg etter stigende identitet. Likhet er altså stabil og forutsigbar, og du trenger ikke gi hver gjest et eget nummer for å få gjentakbar oppførsel.

Gjester uten rekkefølge starter alltid etter dem som har en. Det er nyttigere enn det høres ut. Du trenger ikke nummerere alt. Nummerer de tre eller fire tingene som virkelig må være tidlig, og la resten være.

Rekkefølgen gjelder én vert, ikke klyngen. Den kan ikke uttrykke at en gjest på node A må opp før en gjest på node B. I det øyeblikket avhengigheten krysser en nodegrense, har denne mekanismen ingenting å si om saken.

Fella som dukker opp senere

Gjester som styres av høytilgjengelighetsstakken ignorerer både start ved oppstart og startrekkefølgen. Start- og stopprutinen hopper helt over dem, fordi det er høytilgjengelighetsbehandleren som avgjør når de kjører.

Denne biter sent. En enkelt vert med nøye avstemt rekkefølge fungerer i et år. Så kommer en andre node, noen gjester flyttes under høy tilgjengelighet, og rekkefølgen deres slutter stille å gjelde. Ingenting advarer deg, for ingenting er galt; ansvaret skiftet bare hender.

Forsinkelsen du egentlig vil ha er ofte en annen

En vanlig grunn til å gripe etter gjestforsinkelser er en ekstern ressurs: nettverkslagring som må være nåbar før noe monterer den, eller en svitsj som trenger et øyeblikk. Å kjøpe den tiden ved å spre enkeltgjester er en klossete vei, for det strekker hele sekvensen.

Det finnes en egen innstilling per node nettopp for dette: en forsinkelse mellom at verten er ferdig startet og at den første automatstartende gjesten går i gang. Ett eneste tall, brukt én gang, og på det stedet ventingen faktisk hører hjemme.

Tallet ingen setter før det gjør vondt

Tidsgrensen for avslutning er som standard 180 sekunder per gjest. Proxmox VE ber gjesten slå seg av, venter, og hvis gjesten fortsatt kjører når tiden går ut, stoppes den med makt. En samlet stopp av alle gjester har sin egen samlede grense på tre minutter før det samme skjer.

For en maskin som skriver til disk ved avslutning er det taket verdt å sjekke med vilje i stedet for å oppdage under et avbrudd. Standarden er raus for de fleste gjester og for kort for noen få, og nettopp de få er de der en tvungen stopp koster deg noe.

Hva vi faktisk ser i praksis

På verten som ble brukt til å sjekke oppførselen beskrevet her var ni gjester satt opp, og tre var satt til å starte ved oppstart. Ikke én hadde startrekkefølge.

Det er den normale tilstanden, og ofte er det helt greit. Maskiner som ikke avhenger av hverandre trenger ingen rekkefølge. Poenget med denne teksten er smalere: har du noen gang sagt høyt at en gjest trenger at en annen er oppe først, så lever den setningen akkurat nå bare i hukommelsen din, og et strømbrudd leser ikke hukommelsen din.

Hva Atlas gjør

Atlas omorganiserer ingenting for deg og finner ikke opp et avhengighetssystem oppå det Proxmox VE har. Det Atlas gjør er å gjøre sammenhengene synlige i ett bilde i stedet for én gjest om gangen, slik at spørsmålet "hva avhenger egentlig av hva her" kan stilles mens maskinen er rolig og ikke mens den er på vei tilbake.

Å se formen konfigurerer den ikke. Men ingen setter en fornuftig rekkefølge for et oppsett de aldri har sett tegnet.

Kilder

Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.

Relaterte artikler

Hvordan ser dette ut inne i Atlas?

Gå til produktsiden