Tips från specialisten - Fallgropar vid utökande av ZFS-pool

Tips från specialisten är en kategori i vårt nyhetsflöde på savecore.se som vi skapat för att ha en gemensam plattform för våra egna specialister att publicera inlägg, i syfte att dela med sig av insikt och kunskap. Först ut är Kjell Högström som, i sin artikel, tar upp problematik och fallgropar vid utökande av ZFS-pool.

Även om ZFS är designat för att vara enkelt att använda krävs viss kunskap om hur ZFS arbetar, för att undvika en del fallgropar. Följande scenario är baserat på verkliga händelser, men för att det här exemplet ska bli så tydligt som möjligt tittar vi på ett extremfall.

I en verklig driftsituation skulle poolen aldrig tillåtas bli helt full, utan den skulle utökas i god tid. En tumregel bland ZFS-användare är att inte fylla poolen mer än till 80 %. Dessutom är det ganska ovanligt med ett skrivmönster som bara lägger till ny data. I ett verkligt fall skulle det förekomma en viss ombalansering genom att data skrivs om.

Till att börja med tar vi en titt på hur ZFS hanterar diskarna i poolen.

En pool består av en eller flera virtual devices (vdevs). En vdev kan bestå av en enda disk, en spegel eller en RAID-grupp. När disk adderas till en pool för att få mer kapacitet  blir det alltid i form av en ny vdev. Det går också att lägga till ytterligare en disk för att få en ensam disk att bli speglad eller öka antalet kopior i en spegel, men det ökar inte poolens kapacitet.

Vid skrivning sprids lasten mellan vdevarna. När en vdev blir full faller den av naturliga skäl bort från de vdevar skrivningarna kan spridas mellan. Om utökningen inte är genomtänkt är det lätt att hamna i en situation där nyskrivet data inte sprids ut som det var tänkt från början.

Låt oss titta närmare på ett exempel ...

Som exempel tar vi en pool som ursprungligen skapades med fyra vdevar för att ge tillräcklig läsprestanda vid rapportkörningar. Poolen används av ett system som bara tillför nya data och rapporterna baseras på de fem senaste dagarnas data.

När poolen är full byggs den ut med 25 % mer disk­utrymme genom att tillföra ytterligare en vdev av samma storlek som de tidigare. Skrivning av data börjar direkt gå långsamt och snart börjar också rapportkörningarna ta längre och längre tid.

Vad har hänt? Eftersom poolen var full och inget existerande data uppdateras hamnar allt nytt data på den nya vdev:en.

Tabellen visar hur stor del av de senaste fem dagarnas data som ligger på varje vdev.

• Dag ett, som är sista dagen innan poolen utökas, har vi en fjärdedel på varje vdev.
• Dag två, som är första dagen med en utbyggd pool, får vi en fin spridning med en femtedel på varje vdev, men sedan går det fort utför.
• Dag sex har vi allt data för de senaste fem dagarna på den nya vdev:en. Det gör att rapportkörningarna bara har tillgång till en fjärdedel av den avsedda I/O-kapaciteten.

Hur undviks detta problem?

Det beror på vilken typ av lagring som används för ZFS-poolen och i hur stora steg det är önskvärt att utöka poolen.

En variant är att lägga till nya vdev:ar, men alltid så många som krävs för bibehållen prestanda. I fallet ovan skulle vi ha lagt till fyra nya vdev:ar. Efter de inledande dagarna kommer vi nu att ha en fjärdedel av nytt data på varje ny vdev och fortfarande ha den prestanda vi designat systemet för.

Den andra varianten förutsätter ett lagringssystem som kan utöka LUNarna. Varje LUN i poolen utökas lika mycket, till exempel 25 %. Beroende på inställningar kommer poolen antingen att växa automatiskt när alla LUNar är utökade eller efter en export och import av poolen. Efter utökningen har vi fortfarande våra fyra ursprungliga vdevar och systemet fortsätter att fungera som avsett.

En tredje, betydligt mindre attraktiv, variant finns också. Det är att bygga en ny större pool och kopiera allt data dit.

Kjell Högström, Senior System Specialist