Backupfönstret som gick från tre och en halv timme till fyra minuter

Övervakningen mejlade om hög disklatens sex gånger per dygn. Första impulsen var att dämpa larmet — flytta den nivån till chatten och låt bara det allvarliga gå till mejl.

Det var rätt åtgärd för mejlkorgen och fel åtgärd för problemet. Larmen var nämligen sanna.

Vad som låg bakom

Varje natt klockan halv fyra startade säkerhetskopieringen av de virtuella maskinerna. Den skrev till en nätverksdisk på en annan ort, över en krypterad tunnel med nitton millisekunders fördröjning, och monteringen var inställd på att vänta på bekräftelse för varje skrivning.

Det sista är hela historien. Med synkron skrivning betalar man fördröjningen om och om igen, för varje block, i stället för att låta trafiken flyta. Resultatet blev åtta till tjugo megabyte i sekunden — och en enskild maskin på åttio gigabyte tog två timmar och trettioåtta minuter. Hela jobbet höll på från halv fyra till sju på morgonen.

Under det fönstret köade all annan läsning mot samma disk. Diskarna var friska hela tiden: självtest godkänt, nitton procent slitage, noll fel. Det var inte hårdvaran som var trött. Det var kön.

Mätningen som avgjorde

Tre vägar fanns. Ta bort kravet på synkron skrivning — snabbt, men man byter bort garantin att en skrivning verkligen ligger på disk. Kopiera lokalt och replikera i efterhand. Eller byta ut filkopieringen mot en riktig backupserver.

Ett test avgjorde saken. En befintlig backupserver på ännu längre avstånd — tjugofem millisekunder — gav 3,7 gånger högre hastighet än den närmare nätverksdisken.

Det är kontraintuitivt tills man ser varför: en backupserver skickar komprimerade block asynkront och bekräftar i efterhand, medan filprotokollet med synkron montering väntar på varje skrivning. Protokollet spelade större roll än avståndet.

Nästa fråga blev var backupen skulle ligga. En liten enkortsdator med en USB-disk fanns på plats och verkade självklar — tills den mättes: hundra megabits nätverk, och nätverkskort och USB-disk på samma buss. Taket hade blivit elva megabyte i sekunden, alltså sämre än det vi försökte komma ifrån.

Det är värt att säga rakt ut: den insikten kostade tio minuters mätning och sparade en helg av besvikelse. Att gissa hade känts snabbare.

Lösningen, och den lilla detaljen som betydde mest

Backupservern lades i en virtuell maskin på klustret självt, med sitt lager på en virtuell disk som i sin tur ligger på en nätverksdisk över gigabit.

Skillnaden mot att låta backupservern montera nätverksdisken direkt är avgörande. En backupserver som delar upp data i tusentals små block vill göra det mot ett lokalt filsystem — inte över ett nätverksprotokoll, där varje blockoperation blir en förfrågan över nätet. Genom att lägga nätverkslagret under den virtuella disken ser backupservern ett vanligt lokalt filsystem, och nätverket får hantera stora sekventiella block i stället för myriader av små.

Samma hårdvara, samma nät, helt annat resultat — beroende på vilket lager som gör vad.

Resultatet

MaskinFörutEfter
20 GB17 minuter39 sekunder
80 GB2 h 38 min4,5 minuter
20 GB, andra körningen1 sekund

Den sista raden är inte ett skrivfel. En backupserver som delar upp data i block känner igen block den redan har och skickar bara det som ändrats. Andra körningen av en maskin som stått still gör i praktiken ingenting.

Backupfönstret gick från tre och en halv timme till några minuter. Larmen om disklatens upphörde — inte för att de tystades, utan för att orsaken försvann.

Så vet du att det funkar

Snabb backup är värdelös om den inte går att läsa tillbaka. Tre kontroller, i den ordningen:

  1. Återställ en maskin på riktigt till en annan plats och starta den. Inte ”verifiera arkivet” — starta den.
  2. Kontrollera att kopian ligger någon annanstans än originalet. En snabb lokal backup som brinner upp tillsammans med servern är en snabbhetsövning, inte en säkerhetskopia.
  3. Titta på hur lång tid jobbet tar över tid. Ett fönster som växer i det tysta är det tidigaste tecknet på att något börjat gå fel — precis som här.

Vad jag tar med mig

Ett återkommande larm är information, inte oljud. Sex mejl om dagen i månader hade varit lätta att filtrera bort. De beskrev ett verkligt problem som växte i takt med att maskinerna blev fler.

Mät innan du väljer. Två av tre antaganden i den här historien var fel: att kortare avstånd ger snabbare backup, och att den lilla datorn med disken skulle duga. Båda kändes självklara. Båda föll på tio minuters mätning.

Och den obekväma: jag hade byggt en backup som fungerade i flera år utan att någon gång fråga vad den kostade under tiden den kördes. Den blev aldrig ett problem för backupen — den blev ett problem för allt annat som ville använda disken samtidigt.

Skrivet av Daniel Azzarri · Om · Alla inlägg