Kärnuppdateringar: varför den farligaste uppdateringen är den tystaste

Kärnan installeras, ingenting händer, allt ser normalt ut. Faran kommer vid nästa start, och den starten kan ligga veckor bort. Mellan orsak och verkan lägger sig veckor.

AtlasPVE ·

Den här artikeln svarar på

  • proxmox kärnuppdatering
  • proxmox ny kärna startar inte
  • proxmox låsa kärnan
  • proxmox kom inte tillbaka efter omstart
  • proxmox starta med gamla kärnan

En kärnuppdatering installeras, installationen slutar utan besvär, och ingenting ser förändrat ut. Systemet kör fortfarande på den gamla kärnan, för en ny kärna träder i kraft först vid en omstart.

Och just där gömmer sig faran.

Mellan orsak och verkan lägger sig veckor

De flesta paketfel visar sig medan du tittar. En tjänst faller, den ger fel, du märker det samma dag.

Kärnan är inte sådan. Problemet dyker upp vid nästa start, och den starten är kanske ingen planerad underhållsnatt. Strömmen går, maskinen startar om sig själv, och den kommer inte tillbaka.

I det ögonblicket kopplar ingen det till "uppdateringen jag gjorde förra månaden". Det du har är ett oförklarat fel som inte alls ser ut som ett uppdateringsproblem.

Den allmänna principen: det nya bör inte vara standardvalet förrän det bevisat sig

Detta är den överförbara läxan i artikeln, och den gäller inte bara kärnor.

En ny kärna får installeras, men det bestående standardvalet bör förbli den gamla kärnan. Det nya bör provas endast som "prova detta en gång vid nästa start".

Upplagt så ändras felets form: hänger maskinen sig återgår den av sig själv till den gamla vid nästa start. För ett engångsval gäller per definition en gång.

Det du vinner är detta: felets namn blir "ingenting hände", inte "maskinen är borta".

Det andra lagret: det installerade bör inte tyst bli standard

I samma stund som en kärna installeras säger de flesta system "hädanefter startar jag med den nyaste". Vill du inte det måste du låsa den körande kärnan före uppdateringen.

Låsningen hindrar inte den nya kärnan, den hindrar den bara från att bli standard av sig själv. När du vill prova den väljer du.

Det tredje lagret: vem märker hängningen

För att en återfallsmekanism ska verka måste något säga "den här maskinen kom inte upp". Finns en vakt på hårdvarunivå gör den det och startar om maskinen.

Finns ingen kräver återfallet en manuell återställning. Det gör inte mekanismen oduglig, men det bör vara känt: meningen "den faller tillbaka automatiskt" är utan vakt bara halvsann.

Regeln som gäller även utan produkt

Starta om medvetet och snart efter en kärnuppdatering. Medan du tittar.

En omstart du själv planerat är ett prov. En omstart som tvingas fram av ett strömavbrott tre veckor senare är en incident. Den enda skillnaden är om du var på plats i stunden.

Vad Atlas gör

När Atlas utför en uppdatering låser det som standard den körande kärnan, så att den nyss installerade kärnan inte av sig själv blir startens standardval. Det beteendet är inte tvingande: det erbjuds som ett val som går att stänga av i gränssnittet. Produkten beslutar inte här, den gör den säkra sidan till standard.

Även mekanismen för verifierad övergång är byggd på principen ovan: det bestående standardvalet är alltid den gamla kärnan, den nya provas bara med en engångsstart, och hänger den faller systemet tillbaka av sig själv. Startförvaltarens typ upptäcks vid körning, eftersom den skiljer sig mellan maskiner.

Och två ärliga gränser:

Den här mekanismen kör som standard i enbart observerande läge. Den säger alltså vad den skulle göra men rör inte startinställningarna. Att verkligen ingripa är ett separat val.

Finns ingen hårdvaruvakt går mekanismen inte förbi det i tysthet: den stänger av sig snyggt och säger att en manuell återställning kan behövas. Att låtsas om en garanti som inte finns är sämre än att inte ge någon alls.

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