Ultimate magazine theme for WordPress.

OpenZFS 2.1 je izašao – razgovarajmo o njegovim potpuno novim dRAID vdev-ovima

0

Uvećaj / OpenZFS je dodao distribuiranu RAID topologiju u svoj set alata današnjim izdanjem 2.1.0.

Aurich Lawson

U petak popodne, projekt OpenZFS objavio je verziju 2.1.0 našeg višegodišnjeg omiljenog datotečnog sistema „složeno je, ali vrijedi“. Novo izdanje kompatibilno je s FreeBSD 12.2-RELEASE i novijim verzijama i Linux kernelima 3.10-5.13. Ovo izdanje nudi nekoliko općih poboljšanja performansi, kao i nekoliko potpuno novih karakteristika – uglavnom ciljanih na preduzeća i druge izuzetno napredne slučajeve upotrebe.

Danas ćemo se usredotočiti na vjerojatno najveću značajku koju OpenZFS 2.1.0 dodaje – topologiju dRAID vdev. dRAID je u aktivnom razvoju od najmanje 2015. i dostigao je beta status spajanjem u OpenZFS master u novembru 2020. Od tada je ozbiljno testiran u nekoliko glavnih OpenZFS razvojnih radnji – što znači da je današnje izdanje “novo” u proizvodnom statusu, a ne “novo” kao u neprovjerenom.

Pregled distribuiranog RAID-a (dRAID)

Ako ste već mislili da je ZFS topologija složena tema, pripremite se da vam um oduši. Distribuirani RAID (dRAID) je potpuno nova vdev topologija s kojom smo se prvi put susreli u prezentaciji na OpenZFS Dev Summit-u 2016. godine.

Kada kreira dRAID vdev, administrator određuje broj podataka, pariteta i hotspare sektora po pruzi. Ovi brojevi su nezavisni od broja stvarnih diskova u vdev. To možemo vidjeti na djelu u sljedećem primjeru, preuzetom iz dokumentacije dRAID Basic Concepts:

root@box:~# zpool create mypool draid2:4d:1s:11c wwn-0 wwn-1 wwn-2 ... wwn-A
root@box:~# zpool status mypool

  pool: mypool
 state: ONLINE
config:

        NAME                  STATE     READ WRITE CKSUM
        tank                  ONLINE       0     0     0
          draid2:4d:11c:1s-0  ONLINE       0     0     0
            wwn-0             ONLINE       0     0     0
            wwn-1             ONLINE       0     0     0
            wwn-2             ONLINE       0     0     0
            wwn-3             ONLINE       0     0     0
            wwn-4             ONLINE       0     0     0
            wwn-5             ONLINE       0     0     0
            wwn-6             ONLINE       0     0     0
            wwn-7             ONLINE       0     0     0
            wwn-8             ONLINE       0     0     0
            wwn-9             ONLINE       0     0     0
            wwn-A             ONLINE       0     0     0
        spares
          draid2-0-0          AVAIL

dRAID topologija

U gornjem primjeru imamo jedanaest diskova: wwn-0 kroz wwn-A. Stvorili smo jedan dRAID vdev s 2 paritetna uređaja, 4 podatkovna uređaja i 1 rezervnim uređajem po pruzi – u sažetom žargonu, draid2:4:1.

Iako imamo ukupno jedanaest diskova u draid2:4:1, u svakoj traci podataka koristi se samo šest – i po jedna u svakoj fizički pruga. U svijetu savršenih usisavača, površina bez trenja i sfernih pilića raspored na disku a draid2:4:1 bi izgledalo otprilike ovako:

0 1 2 3 4 5 6 7 8 9 A
s Str Str D D D D Str Str D D
D s D Str Str D D D D Str Str
D D s D D Str Str D D D D
Str Str D s D D D Str Str D D
D D . . s . . . . . .
. . . . . s . . . . .
. . . . . . s . . . .
. . . . . . . s . . .
. . . . . . . . s . .
. . . . . . . . . s .
. . . . . . . . . . s

U stvari, dRAID ide koncept RAID-a sa “dijagonalnim paritetom” korak dalje. Prva paritetna RAID topologija nije bila RAID5 – bila je RAID3, u kojoj je paritet bio na fiksnom pogonu, umjesto da se distribuira kroz niz.

RAID5 je uklonio pogon s fiksnim paritetom i umjesto toga raspodijelio paritet na svim diskovima niza – što je nudilo znatno brže operacije nasumičnog upisa od konceptualno jednostavnijeg RAID3, jer nije usko grlo pri svakom upisivanju na disk s fiksnim paritetom.

dRAID uzima ovaj koncept – raspodjelu pariteta na svim diskovima, umjesto da sve to stavi na jedan ili dva fiksna diska – i proširuje ga na spares. Ako disk ne uspije u dRAID vdev, sektori pariteta i podataka koji su živjeli na mrtvom disku kopiraju se u rezervirani rezervni sektor (e) za svaku pogođenu traku.

Uzmimo pojednostavljeni dijagram gore i ispitajmo šta se događa ako disk padne iz niza. Početni kvar ostavlja rupe u većini grupa podataka (u ovom pojednostavljenom dijagramu, pruge):

0 1 2 4 5 6 7 8 9 A
s Str Str D D D Str Str D D
D s D Str D D D D Str Str
D D s D Str Str D D D D
Str Str D D D D Str Str D D
D D . s . . . . . .

Ali kada se otopimo, učinimo to na prethodno rezerviranom rezervnom kapacitetu:

0 1 2 4 5 6 7 8 9 A
D Str Str D D D Str Str D D
D Str D Str D D D D Str Str
D D D D Str Str D D D D
Str Str D D D D Str Str D D
D D . s . . . . . .

Imajte na umu da su ovi dijagrami pojednostavljeno. Potpuna slika uključuje grupe, kriške i redove, u koje ovdje nećemo pokušavati ulaziti. Logički raspored je također nasumično permutiran kako bi se stvari ravnomjernije rasporedile po pogonima na osnovu odstupanja. Oni koji su zainteresirani za najdlake detalje, potiču se da pogledaju ovaj detaljni komentar u izvornoj predaji koda.

Takođe je vredno napomenuti da dRAID zahtijeva fiksne širine pruga – a ne dinamičke širine podržane od tradicionalnih RAIDz1 i RAIDz2 vdevs. Ako koristimo 4kn diskove, a draid2:4:1 vdev poput gore prikazanog zahtijevat će 24KiB na disku za svaki blok metapodataka, gdje bi tradicionalnom RAIDz2 vdev-u sa šest širina trebalo samo 12 KB. Ovo se odstupanje pogoršava što su vrijednosti veće d+p dobiti draid2:8:1 za isti blok metapodataka bilo bi potrebno ogromnih 40 KB!

Iz tog razloga, special alokacija vdev je vrlo korisna u spremištima s dRAID vdevs-kada je bazen sa draid2:8:1 i troširok special treba pohraniti 4KiB blok metapodataka, i to u samo 12KB na special, umjesto 40 KB na draid2:8:1.

izvedbe dRAID-a, tolerancija kvarova i oporavak

Ovaj graf prikazuje promatrana vremena ponovnog rezultiranja za spremište od 90 diskova.  Tamnoplava linija na vrhu je vrijeme da se ponovo stavi na fiksni hotspare disk;  šarene linije ispod prikazuju vremena kako bi se oživjele na raspoređenom slobodnom kapacitetu.

Ovaj graf prikazuje promatrana vremena ponovnog rezultiranja za spremište od 90 diskova. Tamnoplava linija na vrhu je vrijeme da se ponovo stavi na fiksni hotspare disk; šarene linije ispod prikazuju vremena kako bi se oživjele na raspoređenom slobodnom kapacitetu.

Uglavnom će dRAID vdev raditi slično ekvivalentnoj grupi tradicionalnih vdev-a – na primjer, draid1:2:0 na devet diskova će se izvoditi gotovo ekvivalentno skupu od tri široka 3 RAIDz1 vdeva. Tolerancija grešaka je također slična – zagarantovano ćete preživjeti jedan neuspjeh p=1, baš kao i kod RAIDz1 vdevs.

Primijetite da smo rekli da je tolerancija kvarova slično, nije identično. Tradicionalni bazen od tri široka RAIDz1 vdev-a sa tri široke garancije preživljava samo jedan disk, ali će vjerovatno preživjeti i drugi – sve dok drugi disk koji ne uspije nije dio istog vdeva kao i prvi, sve je u redu.

U devet diskova draid1:2, drugi kvar na disku će gotovo sigurno ubiti vdev (i spremište zajedno s njim), ako da se neuspjeh dogodi prije ponovnog opuštanja. Budući da ne postoje fiksne grupe za pojedinačne pruge, kvar drugog diska će vrlo vjerojatno izbaciti dodatne sektore u već degradiranim prugama, bez obzira koji disk otkaže drugi.

Ta donekle smanjena tolerancija kvara nadoknađuje se drastično kraćim vremenom rezilvera. Na grafikonu na vrhu ovog odjeljka možemo vidjeti da se u bazenu od devedeset diskova od 16 TB resilving na tradicionalni, fiksni spare traje otprilike trideset sati, bez obzira na to kako smo konfigurirali dRAID vdev – ali ponovno razvrstavanje na raspodijeljeni rezervni kapacitet može potrajati i jedan sat.

To je u velikoj mjeri zato što ponovno nanošenje na distribuirani rezervni dio dijeli opterećenje za pisanje među svim preživjelim diskovima. Kada se oporavi tradicionalnom spare, rezervni disk sam po sebi predstavlja usko grlo – očitavanja dolaze sa svih diskova u vdev-u, ali upisi moraju biti dovršeni rezervnim. Ali kada se ponovo odlučite za distribuirani rezervni kapacitet, oboje čitaju i radna opterećenja za pisanje dijele se na sve preživjele diskove.

Distribuirani resilver može biti i sekvencijalni resilver, a ne ljekoviti resilver – što znači da ZFS može jednostavno kopirati sve pogođene sektore, bez brige o tome što blocks tim sektorima pripadaju. Nasuprot tome, iscjeliteljski ostaci moraju skenirati cijelo stablo bloka – što rezultira nasumičnim radnim opterećenjem, a ne sekvencijalnim radnim opterećenjem.

Kada se u spremište doda fizička zamjena za neuspjeli disk, ta ponovna operacija hoće biti iscjeljujuće, a ne sekvencijalno – i usko će uslijediti performanse upisa pojedinačnog zamjenskog diska, a ne cijelog vdeva. Ali vrijeme za dovršetak te operacije je daleko manje bitno, jer vdev za početak nije u degradiranom stanju.

Zaključci

Distribuirani RAID vdev-ovi su uglavnom namijenjeni velikim poslužiteljima za pohranu — OpenZFS draid dizajn i testiranje vrtili su se uglavnom oko sistema sa 90 diskova. U manjim razmjerima, tradicionalni vdev i spares ostaju korisni kao nikada prije.

Posebno upozoravamo na pohranu novorođenčadi s kojima treba biti oprezan draid—To je znatno složeniji raspored od bazena s tradicionalnim vdev-ovima. Brzo oporavak je fantastičan – ali draid postiže pogodak i na razini kompresije i u nekim scenarijima izvedbe zbog svojih pruga nužno fiksne dužine.

Kako se konvencionalni diskovi nastavljaju povećavati bez značajnih povećanja performansi, draid a njegovo brzo otapanje može postati poželjno čak i na manjim sistemima – ali trebat će neko vrijeme da se shvati gdje tačno počinje slatko mjesto. U međuvremenu, imajte na umu da RAID nije sigurnosna kopija – a to uključuje draid!


Pratite nas na Facebook-u | Twitter-u | YouTube-u