Klustret som hängde sig: fem mjukvarufel som alla var fel svar

Två nya servrar skulle bli ett kluster. Installationen gick perfekt, noderna såg varandra, och klustret gick att skapa. Sedan hängde sig den ena.

Inte kraschade — hängde. Små skrivningar till klustrets delade konfigurationsfilsystem gick igenom. Stora skrivningar blev stående, i det tillstånd där en process varken kan fortsätta eller avbrytas. Samma nod var fullständigt frisk så länge den stod ensam.

Allt pekade på mjukvaran

Ett kluster som fungerar utom när det används är en tacksam felkälla att gissa om, och jag gissade i tur och ordning på allt.

  • Paketförlust? Flödestest mellan noderna gav 0,1 procent. Inte bra, inte alls illa nog.
  • Disken? Skrivtest rakt mot lagringen: fullt normal hastighet.
  • Minnet? Friskt.
  • Databasen med klusterkonfigurationen? Integritetskontroll utan anmärkning.
  • Nätverkskortets avlastningsfunktioner? Där fanns faktiskt något — en känd bugg i den kortfamiljen kan korrumpera paket när kortet självt räknar checksummor. Avlastningen stängdes av permanent, som en tjänst som kör innan klusterkommunikationen startar.

Det hjälpte inte. Klustret löstes upp till två fristående noder — båda fungerade felfritt igen — och problemet lämnades över natten.

Siffran som hade legat framför mig hela tiden

Nästa dag tittade jag på något jag borde tittat på först: vad länken faktiskt förhandlade fram.

Den ena noden satt på en gigabitport och körde gigabit. Den andra satt på en gigabitport och körde 100 megabit. Båda sidor — switchen och nätverkskortet — var överens om att 100 var det bästa de kunde erbjuda.

Två gigabitkapabla enheter som självmant nöjer sig med 100 megabit betyder nästan alltid en sak: kabeln har bara två fungerande trådpar. Gigabit kräver fyra. Med två par fungerar länken utmärkt — den blir bara tio gånger långsammare, och ingenting rapporterar ett fel, för det är inget fel. Det är en korrekt förhandling utifrån usla förutsättningar.

Kabeln byttes. Klustret byggdes om från grunden. Noll omsändningar, delat filsystem i synk, stora skrivningar direkt igenom. Migrering av en virtuell maskin mellan noderna kopierade disken i full gigabithastighet.

Varför just stora skrivningar

Det förklarar också varför symptomet var så egendomligt selektivt.

Klusterkommunikationen använder ett protokoll som skickar meddelanden i en sluten ring med garanterad ordning. Små meddelanden får plats i ett paket och kom fram. Stora skrivningar delas upp i många paket som måste anlända i rätt ordning inom en tidsgräns — och en länk på en tiondel av förväntad kapacitet, delad med annan trafik, missar den gränsen. Protokollet gör då det enda rätta: det väntar, i stället för att riskera att noderna får olika bild av verkligheten.

Så det som såg ut som en hängning var i själva verket ett korrekt fungerande skyddsmekanism som gjorde sitt jobb mot en trasig förutsättning.

Det tredje röstkortet

En detalj som är värd att ta med för den som bygger ett kluster med bara två noder: två är ett dåligt antal. Faller den ena vet den kvarvarande inte om kompisen är död eller om den själv blivit isolerad, och den vågar därför inte fortsätta ensam.

Lösningen är en tredje röst som inte behöver vara en server. Här fick en liten enkortsdator som redan stod och gjorde annat agera skiljedomare. Den lagrar ingenting och kör inga laster — den finns bara där för att kunna säga vem som har rätt. Med den på plats överlever klustret att en nod försvinner.

Så vet du att det funkar

Läs av länkhastigheten på varje port, varje gång. Det är en rad utdata och den utesluter en hel felklass. Jag hoppade över det i ett dygn för att problemet ”uppenbart” låg i mjukvaran.

Testa med volym, inte med ping. Ett ping-test som visar 0,1 procent förlust ger falsk trygghet. Flytta en virtuell maskin mellan noderna och mät hastigheten — det är det närmaste ett verkligt arbetsprov man kommer.

Stäng av en nod med flit och kontrollera att den andra fortsätter fungera. Ett kluster som aldrig testats i den situationen är ett kluster med okänt beteende i exakt det ögonblick det ska bevisa sitt värde.

Vad jag tar med mig

Jag är van vid att fel sitter i mjukvaran, för det gör de nästan alltid. Den vanan gjorde att jag uteslöt fem programvarurelaterade orsaker innan jag tittade på ett värde som fysiska lagret skrek ut hela tiden.

Det finns en läxa i det som gäller bortom nätverkskablar: när ett system beter sig omöjligt, kontrollera antagandena innan du felsöker slutsatserna. ”Länken är gigabit” var ett antagande. Det tog tjugo sekunder att kontrollera och kostade ett dygn att låta bli.

Och så det som är svårt att erkänna: en agent hade inte heller hittat det här snabbare. Den letade där jag bad den leta, kompetent och uthålligt, i mjukvaran. Ingen av oss ställde frågan om kabeln — för att frågan om kabeln inte finns i loggarna. Den finns i verkligheten.

Skrivet av Daniel Azzarri · Om · Alla inlägg