En NAS fick en större uppgradering av sitt operativsystem. Efteråt rapporterade hypervisorn Connection failure (0x0004) på samtliga iSCSI-targets, och de virtuella maskiner som låg på den lagringen ville inte starta.
Ingenting var borta. Diskarna fanns kvar, volymerna fanns kvar, och all data låg orörd. Det som hade gått sönder var förmågan att hitta lagringen — och det tog en stund att inse, för symptomen ser ut precis som när något är trasigt på riktigt.
Symptomet
Alla targets på den aktuella adaptern gick ner samtidigt. Inte en, inte några — allihop. Det är i sig en ledtråd värd att ta på allvar: när precis allt slutar fungera på en gång är det sällan diskarna som gått sönder. Det är något gemensamt i kedjan, och det gemensamma här var upptäcktsmekanismen.
Jag lät en agent gå igenom felsökningen medan jag följde med i vad den hittade. Nätverket svarade. Porten var öppen. Målsystemet lyssnade. Ändå fick initiatorn inget vettigt svar när den frågade ”vilka targets finns här?”.
Grundorsaken: discovery, inte lagring
iSCSI kan hitta sina targets på två sätt. Antingen frågar initiatorn målsystemet ”räkna upp vad du har” — dynamisk upptäckt, SENDTARGETS — eller så får den veta exakt vilket target den ska ansluta till, en statisk uppgift som någon har skrivit in för hand.
Den dynamiska varianten är bekvämare, och det var den som användes. Efter uppgraderingen svarade målsystemet inte längre på den frågan på det sätt initiatorn förväntade sig. Till det kom att åtkomstlistorna — vilka initiatorer som alls får ansluta — hade fått nya standardvärden i och med den nya versionen.
Med andra ord: två oberoende beteenden ändrades tyst i en uppgradering som annars gick smärtfritt. Inget felmeddelande sa ”din discovery-metod stöds inte längre”. Bara Connection failure.
Fixen
Tre steg, i den ordningen:
- Öppna åtkomsten igen på lagringssidan. Målsystemet behövde tillåta initiatorerna att ansluta — i det här fallet genom att låta det generera åtkomstregler automatiskt i stället för att kräva handskrivna.
- Byt från dynamisk till statisk upptäckt. Peka ut varje target explicit på initiatorsidan, med adress, port och fullständigt targetnamn. Tråkigare att sätta upp, betydligt svårare att tappa bort.
- Montera volymerna manuellt. När filsystemen kom tillbaka betraktades de som ögonblicksbilder av något som redan fanns, och monterades därför inte automatiskt. De måste monteras explicit innan de blir användbara igen.
Punkt tre är den som skrämmer mest i stunden. Volymen syns, den har rätt storlek, och ändå vägrar systemet använda den. Det ser ut som datakorruption. Det är det inte — det är ett skyddsbeteende som finns just för att man inte ska montera två kopior av samma filsystem samtidigt och skriva sönder båda.
Så vet du att det funkar
Att en maskin startar bevisar ingenting. Det gjorde den innan uppgraderingen också.
Testet är en omstart av hypervisorn, hela vägen, och en kontroll av att lagringen kommer tillbaka av sig själv. Det är först då man vet om fixen sitter i konfigurationen eller bara i det aktuella körläget. Jag har sett iSCSI se fullt frisk ut ända fram till nästa strömavbrott.
Kontrollera också att alla targets faktiskt är anslutna, inte bara att de virtuella maskinerna startade. En maskin kan starta på en av sina diskar och fungera i timmar innan den rör den andra.
Vad jag tar med mig
Bekvämlighet i infrastrukturlagret är en skuld man betalar vid uppgraderingar. Dynamisk upptäckt sparar fem minuter när man sätter upp systemet och kostar en kväll varje gång något i kedjan ändrar beteende. Statisk konfiguration är trist, och trist är precis vad man vill ha i lagringslagret.
Större versionslyft ändrar tysta standardvärden. Det som står i releasenoteringarna är sällan det som stjälper en. Åtkomstlistor, standardprotokoll och rättighetsmodeller ändras utan att någon skriver en rad om det, för i tillverkarens huvud är det en förbättring.
Läs symptomet bokstavligt. ”Connection failure” betyder att anslutningen misslyckades, inte att disken är trasig. Skillnaden mellan att inte nå något och att ha förlorat det avgör om nästa steg är felsökning eller återläsning från backup — och panik leder alltid till det senare först.