Korábban említést tettem róla, hogy a FreeNAS rendszeremet 7 éve építettem. A költséghatékonyság jegyében három WD Green meghajtót vásároltam, melyek nem kifejezetten 0-24 üzemmódra lettek tervezve, legalábbis a vezérlő szoftverük nem erre, hanem a takarékos üzemre van optimalizálva. Egy kis bütyköléssel (WDIDLE3) lehet ezen segíteni. Egy meghajtó hosszabb vergődést követően nemrég produkált egy hibás szektort. A dolog nem ért váratlanul. A S.M.A.R.T. értékeket már több, mint egy éve folyamatosan figyelemmel kisértem, amióta a nullától különböző Raw_Read_Error_Rate és az első Current Pendig Sector megjelent. Nem hittem volna, hogy még ennyi ideig gyakorlatilag érzékelhető hiba nélkül működni fog a meghajtó.
A hibát a TrueNAS az időszakos karbantartás során (scrub) észlelte. A ZFS fájlrendszer ellenőrzése során az egyik meghajtó olvasási hibát jelentett, amely a kötetet azonnal „degraded” státuszba tette. Ez azt jelenti, hogy a szolgáltatások továbbra is elérhetőek maradnak, de a redundancia részlegesen vagy teljesen megszűnik, vagyis az adatok további hiba bekövetkezése esetében nem állíthatóak vissza. A meghajtót tehát sürgősen cserélni kell.
Ez a meghajtó sajnos már nem kapható, a Western Digitalról pedig az utóbbi időben elterjedt, hogy a költségoptimalizálás miatt a kisebb kapacitású meghajtóknál átállt SMR (Shingled Magnetic Recording) technológiára, amely bizonyos felhasználási területen hátrányosnak bizonyult. Még a willhaben-en is körülnéztem használt meghajtók (régebbi WD Red, WD Green) után, de a több évet használt darabok használt árát egyszerűen soknak találtam (70-80€, 7 éve 111€-t fizettem a 4TB WD Green meghajtóért!), így inkább az új meghajtó mellett döntöttem. Pontosabban meghajtók mellett, ugyanis arra jutottam, hogy a RAIDZ helyett, az egyszerűbb tükrözést fogom használni.
A RAIDZ nagyon jól teljesített, de sajnos körülményes a bővítése. Csak egyféle módon lehet meglévő kötetet bővíteni: Minden meghajtót egyenként nagyobb kapacitásúra kell cserélni, és a kötetet újraépíteni. Három 8 TB-os meghajtó pedig már nettó 16 TB kapacitást jelent. Ehhez ajánlott 16 GB memória, amely azt jelentette volna, hogy a szolgáltatások memóriaigénye miatt az egész szervert bővíteni kell. A köztes megoldást két 12TB os meghajtó jelentette, amely éppen „akciós” volt az Amazon-on. Ezek a meghajtók héliummal vannak töltve, amely kisebb belső súrlódást és halkabb, takarékosabb üzemet jelent. Mivel folyamatosan mennek, ez nem elhanyagolható szempont.
| év | redundancia | meghajtók | nettó kapacitás | meghajtó ára | 1 TB ára |
| 2014 | RAIDZ | 3 x 4TB WD40EZRX | 8 TB | 111€ | 41,63€ |
| 2021 | tükör | 2 x 12TB WD120EDAZ | 12 TB | 182,5€ | 30,42€ |
Az új meghajtók megérkeztek, de mielőtt beépítésre kerülnek, át kell esniük egy alapos tesztelésen. Ehhez a WD saját diagnosztikai szoftverét használtam. Az új szoftver Dashboard névre hallgat, de sajnos nem tetszett. Nem tudtam egyszerre a két meghajtót tesztelni, ezért a régi szoftverrel, a Data Lifeguard Diagnostic for Windows-sal dolgoztam.
A futási idők ezeknél a meghajtóknál extrém hosszúak. A meghajtó teljes törlése 21 órát, a bővített tesztelés (extended test) további 21 órát jelentett. Érdekes, hogy bár azonos meghajtókról beszélünk, az egyiknél 1-1 órával tovább tartottak a műveletek. Ez azt jelenti, hogy a meghajtó 5%-kal lassabb. A meghajtók hibátlanok voltak.
Stratégia
Az egyértelmű volt számomra, hogy az adatokat át kell migrálnom, de hogy hogyan, annak utána kellett olvasnom. Az alapötlet az, hogy a snapshotokkal kell az adatokat a két kötet között másolni. Így minden, még a snapshotok maguk is könnyedén átvihetők az új kötetre. A feladat végeztével át kell nevezni a régi kötetet, majd az újat a régi nevére, és elvileg működik minden, ahogy korábban.
Van azonban egy kis apróság, ami bonyolítja a helyzetet: A TrueNAS az új, ZFS alapú titkosítást támogatja, a FreeNAS-ban használt GELI titkosítás már csak a visszafelé kompatibilitás miatt elérhető. Új köteteket ezzel a titkosítással már nem lehet létrehozni. A TrueNAS hivatalos dokumentációjában van egy kis információ erre vonatkozóan.
A migráció
Először offline-ba kapcsoltam a meghibásodott meghajtót, majd kiszereltem:
A helyére bekerült egy új meghajtó. A második meghajtót később adom a tükörhöz. Az újraindítás után a GELI-vel titkosított kötetet kinyitottam, de a szolgáltatásokat (NFS, SMB, Jails) nem indítottam el. Az új kötetet az új ZFS titkosítással hoztam létre:
A titkosítási kulcsot az Encryption Options alatt lecseréltem egy jelszóra. Reményeim szerint a dataset-ek ezt a titkosítást fogják örökölni.
Innentől a terminálban folytattam a munkát. Elsőként kellett egy rekurzív snapshot az egész kötetről:
root@truenas:~#zfs snapshot -r vol0@clone_snapshot
A snapshotot átküldjük az új kötetre. Ehhez a zfs-send rekurzív (-R) kapcsolóval, a zfs-receive pedig felülírás (-F) kapcsolóval, illetve a cél köteten a forrás tömörítési tulajdonságának elhagyásával kerül futtatásra. Ne felejtsük el, hogy a cél dataset ezt a tulajdonságágát a cél kötettől fogja örökölni:
root@truenas:~#zfs send -Rv vol0@clone_snapshot | zfs receive -x encryption -Fdvu vol0_new total estimated size is 7.00T cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one warning: cannot send 'vol0@clone_snapshot': signal received
…aha, nem. Ez így sajnos nem működik. Néhány sikertelen próbálkozás után feladtam az egész kötet másolását, és dataset-enként próbáltam (a legkisebbel kezdtem):
root@truenas:~#zfs send -Rv vol0/iocage@clone_snapshot | zfs receive -x encryption -Fdvu vol0_new
A snapshotok másolása elindult.
received 122G stream in 2062 seconds (60.8M/sec)
Folytattam a többivel is. A legnagyobb dataset másolását éjjelre hagytam. Másnapra minden dataset másolása lekészült.
Következet a csere. A „régi” kötetet le kell csatolni (export). Ezt a GUI-n keresztül csináltam. A TrueNAS figyelmeztetett, hogy a rendszer kötet át fog költözni egy másik elérhető pool-ra.
Azt hittem, hogy ez a művelet csupán néhány másodperc lesz, ehhez képest 40%-nál (Reconfiguring system dataset) megtorpant a folyamat. Eközben ps-sel figyeltem a folyamatot, és láttam, hogy az új pool helyett a boot eszközre költözik vissza a rendszer (rsync -az /var/db/system/ /tmp/system.new). Hmm. Végül aztán sikerrel zárult a folyamat.
Az új kötet lecsatolása eseménytelenül zajlott.
Következzen hát az új kötet régi néven (vol0) történő felcsatolása:
Ezen a ponton elvetettem a felcsatolást, ugyanis én vol0 néven szerettem volna felcsatolni a kötetet. Így megpróbáltam az alábbi parancsot:
root@truenas:~ # zpool import vol0_new vol0
A felcsatolt kötet sajnos nem látszott a GUI-ban, úgyhogy lecsatoltam, és a GUI-n keresztül csatoltam fel:
root@truenas:~ # zpool export vol0
A kötet átnevezése sikeres volt.
A kötetet kinyitottam, a jail menüpontra kattintva kiválasztottam a vol0-poolt. A jail-ek megjelentek.
A végére a rendszerkötet áthelyezése maradt:
Erre nem számítottam. A GELI titkosítás mellett ez megoldható volt??? Itt miért nem? Ráadásul a kötet titkosítását már nem tudom utólag módosítani. Ami még menne, hogy jelszó helyett kulcsra állok át, de a dataset-eket akkor sem tudom jelszóval védeni. Na itt még van mit javítani…
Tükör létrehozása
Az utolsó feladat a második meghajtó hozzáadása a pool-hoz. Ezt a pool status nézetben az extend menüpont kiválasztásával tehetjük meg.
A hozzáadás után rögtön megkezdődik a meghajtó tükrözése (resilver). Remélem, hogy a folyamat gyorsabb lesz, mit a kijelzett 2527 nap. 🙂
Ha nem tapasztalok rendellenességet, akkor a maradék két hibamentes 4 TB-os meghajtó törlés után offline biztonsági másolatként folytathatja pályafutását.