Maskinen lukker ikke ned: en anmodning er ikke en tænd-sluk-knap
Nedlukning beder om; stop trækker stikket. Alt forvirrende ved en maskine, der nægter at lukke ned, kommer fra den ene skelnen, og fra at en anmodning kræver nogen indenfor, der lytter.
AtlasPVE ·
Denne artikel besvarer
- proxmox vm lukker ikke ned
- proxmox stop eller shutdown
- proxmox pæn nedlukning
- proxmox ups luk vm ned
- proxmox vm won't shut down
Du trykker på luk ned. Opgaven starter, hjulet drejer, og tre minutter senere kører maskinen stadig. Til sidst trykker du på stop, og den dør øjeblikkeligt, hvilket rejser et oplagt spørgsmål: hvorfor virkede det første ikke, når det andet tydeligvis kan?
Det er ikke to styrkegrader af samme handling. Det er to helt forskellige ting.
Skelnen, som alt hænger på
Nedlukning er en anmodning. Virtualiseringslaget beder gæsten om at lukke sig selv ned, ligesom et tryk på tænd-sluk-knappen på en fysisk maskine beder et styresystem om at lukke pænt. Hvad der sker med anmodningen, bestemmer gæsten.
Stop er en strømafbrydelse. Det tager strømmen fra den virtuelle maskine øjeblikkeligt, uden nogen samtale. Dokumentationen advarer i klart sprog: at stoppe kan medføre datatab, så brug det med forsigtighed.
Så snart du holder de to adskilt, holder en maskine, der ikke lukker ned, op med at være gådefuld. Den nægter ikke. Ingen indenfor hørte anmodningen.
Hvem der skal lytte
Der er to mulige lyttere, og en sund maskine har mindst én.
Styresystemets håndtering af tænd-sluk-knappen. På en Linux-gæst er den normalt til stede. På et minimalt aftryk, et beholderlignende apparat eller et system, der er havnet i en tidlig opstartsfase eller en redningsskal, kan den mangle.
Gæsteagenten. Når den er slået til og faktisk kører, giver den virtualiseringslaget en direkte kanal indad, og anmodningen går den vej.
Er agenten slukket, og knaphåndteringen mangler eller ikke svarer, går anmodningen ud og når ingen steder hen. Virtualiseringslaget får ikke et "nej". Det får ingenting, hvilket udefra ser præcis ens ud og er grunden til, at opgaven ser ud til at hænge frem for at fejle.
Hvis dine maskiner rutinemæssigt er for længe om at lukke ned, er det et bedre første træk at tjekke, om agenten faktisk virker, end at forkorte tidsgrænser.
Så tidsgrænsen, så magten
Ventetiden har en grænse. Per gæst er standardtidsgrænsen for nedlukning 180 sekunder; når den udløber, stoppes maskinen med magt.
Et samlet stop af alt på en knude har sit eget budget: det forsøger en pæn nedlukning, venter op til tre minutter som standard, og stopper derefter hårdt det, der stadig kører.
Den ærlige beskrivelse af en uovervåget nedlukning er altså: spørg pænt, vent et fast stykke tid, og træk så stikket. Har din database brug for fire minutter til at skrive færdig, har standardværdierne allerede besluttet, at den får tre.
Hæv tallet, men spring ikke spørgsmålet over
Det er fristende at behandle tidsgrænsen som knappen, der skal justeres. For en maskine, der virkelig behøver længere tid, er det rigtigt at hæve den.
Men en maskine, der aldrig lukker ned, uanset hvor længe du venter, har ikke et tidsgrænseproblem, og at give den ti minutter betyder bare, at du venter ti minutter på det samme tvungne stop. Find først ud af, om nogen lytter.
Når en nedlukningsopgave allerede sidder fast
Sidder en nedlukningsopgave fast, og maskinen skal ned nu, findes der en udtrykkelig måde at stoppe den på, som tilsidesætter den kørende nedlukningsopgave i stedet for at stille sig i kø bag den. Den findes netop, fordi tilfældet med den fastlåste opgave er almindeligt nok til at kræve et svar.
Brug den velvidende, hvad den er: stadig en strømafbrydelse, med den samme advarsel hæftet på.
Tilfældet, der overrasker folk: strømsvigt
Her holder hele teksten op med at være teoretisk.
Et strømsvigtsskript, der lukker gæster ned, før batterierne løber tør, arver hver eneste egenskab ovenfor. Det sender anmodninger. Gæster, der ikke lytter, ignorerer dem. Tidsgrænsen løber. Derefter bliver alt, der stadig kører, stoppet hårdt, måske med allerede lavt batteri og måske alt på én gang.
To ting er værd at tjekke, før du stoler på sådan et opsæt, og begge er billige:
Svarer gæsterne faktisk på en nedlukningsanmodning? Test én, med stopur, en helt almindelig eftermiddag.
Passer det samlede budget til batteriet? Gæsterne lukker ned efter tur, og tidsgrænserne lægger sig sammen. En række maskiner, der hver bruger to minutter, er ikke en tominutters nedlukning.
En strømsvigtsplan, der aldrig er øvet, er en plan, der bliver øvet præcis én gang: i mørket, under tidspres.
Hvad Atlas gør
Atlas opfinder ikke en tredje slags nedlukning. At spørge og at afbryde strømmen er de to ting, der findes, og at lade som noget andet ville være en løgn med følger.
Det, Atlas gør, er at nægte at udviske dem. En destruktiv handling siger, at den er destruktiv, før du bekræfter den, så "stop" aldrig dukker op forklædt som en lidt fastere "luk ned". Den skelnen er hele emnet i denne tekst, og et panel, der viser de to som naboknapper med samme vægt, har allerede mistet den.
Det daglige sammendrag bærer den anden halvdel: en uplanlagt genstart meldes som et faktum. En maskine, der blev tvangsstoppet efter en mislykket pæn nedlukning, ser næste morgen præcis ud som en maskine, der brød sammen. Begge fortjener at blive bemærket.
Kilder
Proxmox’ egen dokumentation. På engelsk, og den har det sidste ord i dette spørgsmål.