Startordningen är en fördröjning, inte ett beroende

Alla ställer in startordningen i tron att den andra maskinen väntar tills den första är klar. Den väntar inte. Den väntar ett fast antal sekunder och startar sedan ändå, och därför fallerar ordningen som fungerade i test på morgonen efter ett riktigt strömavbrott.

AtlasPVE ·

Den här artikeln svarar på

  • proxmox startordning
  • proxmox boot order fungerar inte
  • proxmox vm startfördröjning
  • proxmox avstängningsordning
  • proxmox start order

Värden kommer tillbaka efter ett strömavbrott och hälften av det som borde köra gör det inte. Databasmaskinen är uppe men programmet framför den gav upp, eller en behållare kunde inte montera lagring som en annan behållare fortfarande höll på att starta. Ingenting är trasigt och ingen loggade ett fel värt att läsa. Delarna kom helt enkelt upp i fel ordning.

Här slutar formen på din uppsättning, vilken gäst som beror på vilken, att vara en skiss i huvudet och blir något maskinen faktiskt utför. Det lönar sig att veta exakt vad den mekanismen gör, för den är smalare än de flesta antar.

Meningen som förklarar de flesta överraskningar

Startfördröjningen är ett intervall, inte ett villkor.

När du ger en gäst en fördröjning startar Proxmox VE den gästen, väntar det antal sekunder du angav och går sedan vidare till nästa. Den kontrollerar inte om starten blev klar inuti gästen. Den kontrollerar inte om en tjänst svarar. Den väntar och fortsätter.

Uppställningen i ditt huvud, "programmet väntar på databasen", blir alltså aldrig det som konfigureras. Det som konfigureras är "programmet startar nittio sekunder efter att databasen blev tillsagd att starta". Vid en lugn testomstart går de två inte att skilja åt. Efter ett riktigt strömavbrott, när diskarna är långsammare, en filsystemskontroll körs eller en gäst startar i räddningsläge, går det.

Fyra regler värda att kunna innan du sätter siffror

Lägre startar först och stängs av sist. Avstängningsordningen är omvändningen av startordningen; det finns ingen separat inställning. En gäst med ordning 1 är först upp och sist ner, vilket oftast är precis vad man vill för det som allt annat beror på.

Lika tal är inte slumpmässiga. Gäster som delar samma ordning sorteras dessutom efter stigande identitet. Lika lägen är alltså stabila och förutsägbara, och du behöver inte ge varje gäst ett unikt nummer för att få upprepbart beteende.

Gäster utan ordning startar alltid efter dem som har en. Det är nyttigare än det låter. Du behöver inte numrera allt. Numrera de tre eller fyra saker som verkligen måste vara tidiga och lämna resten ifred.

Ordningen gäller en värd, inte klustret. Den kan inte uttrycka att en gäst på nod A måste upp före en gäst på nod B. I samma stund som ditt beroende korsar en nodgräns har den här mekanismen inget att säga om saken.

Fällan som dyker upp senare

Gäster som sköts av högtillgänglighetsstacken ignorerar både starta vid uppstart och startordningen. Start- och stopprutinen hoppar över dem helt, eftersom det är högtillgänglighetshanteraren som avgör när de kör.

Den här biter sent. En ensam värd med noggrant avstämd ordning fungerar i ett år. Sedan kommer en andra nod, några gäster flyttas under högtillgänglighet, och deras ordning slutar tyst att gälla. Ingenting varnar dig, för ingenting är fel; ansvaret bytte bara händer.

Fördröjningen du egentligen vill ha är ofta en annan

Ett vanligt skäl att gripa efter gästfördröjningar är en extern resurs: nätverkslagring som måste vara nåbar innan något monterar den, eller en switch som behöver ett ögonblick. Att köpa den tiden genom att glesa ut enskilda gäster är en klumpig väg, för det tänjer ut hela sekvensen.

Det finns en separat inställning per nod för precis detta: en fördröjning mellan att värden är färdigstartad och att den första automatstartande gästen går igång. Ett enda tal, tillämpat en gång, och på den plats där väntandet faktiskt hör hemma.

Talet ingen ställer in förrän det gör ont

Avstängningens tidsgräns är som standard 180 sekunder per gäst. Proxmox VE ber gästen stänga av, väntar, och om gästen fortfarande kör när tiden går ut stoppas den med tvång. Ett samlat stopp av alla gäster har en egen sammanlagd gräns på tre minuter innan samma sak händer.

För en maskin som skriver till disk vid avstängning är det taket värt att kontrollera med flit i stället för att upptäcka under ett avbrott. Standardvärdet är generöst för de flesta gäster och för kort för några få, och just de få är precis de där ett tvingat stopp kostar dig något.

Vad vi faktiskt ser i praktiken

På värden som användes för att kontrollera beteendet som beskrivs här fanns nio gäster konfigurerade och tre inställda på att starta vid uppstart. Ingen enda hade en startordning.

Det är det normala läget, och ofta är det bra så. Maskiner som inte beror på varandra behöver ingen ordning. Syftet med den här texten är smalare: om du någonsin sagt högt att en gäst behöver att en annan är uppe först, så lever den meningen just nu bara i ditt minne, och ett strömavbrott läser inte ditt minne.

Vad Atlas gör

Atlas ordnar inte om något åt dig och hittar inte på ett beroendesystem ovanpå det Proxmox VE har. Det Atlas gör är att synliggöra sambanden i en enda bild i stället för en gäst i taget, så att frågan "vad beror egentligen på vad här" kan ställas medan maskinen är lugn och inte medan den är på väg tillbaka.

Att se formen konfigurerar den inte. Men ingen sätter en vettig ordning för en uppställning de aldrig sett uppritad.

Källor

Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.

Relaterade artiklar

Hur ser det här ut inne i Atlas?

Gå till produktsidan