ZFS hot spares versus mai multă paritate (Administrarea sistemului, Raid, Zfs)

AlanObject a intrebat.

Sunt un pic nou în ZFS, dar am adus un nou grup de stocare cu 12 unități fizice.

Planul meu actual este de a avea RAIDZ2 pe 10 unități și două hot spares.

Dar mă întreb dacă nu mi-ar fi mai bine să am RAIDZ3 pe toate cele 12 unități și fără hot spares.

Raționamentul este că unitățile de rezervă sunt, practic, unități inactive alimentate. Ar putea trece luni sau ani până când acestea vor fi puse în funcțiune, iar în acel moment aș putea afla că nu sunt viabile. Dacă ar face parte dintr-o bandă RAID, aș putea cel puțin să aflu dacă sunt bune sau nu.

Nu am văzut prea multe discuții despre acest lucru pe internet. Are cineva un sfat?

Comentarii

  • Care sunt cerințele dumneavoastră de disponibilitate? Cum se va face backup-ul datelor? –  > Por Andrew Henle.
3 răspunsuri
user121391

Despre piesele de schimb la cald

Rezervele fierbinți sunt setate la o anumit grup, dar pot fi atașate la orice vdev din pool în mod automat în cazul unor defecțiuni. Dacă aveți doar un singur vdev format din toate discurile, este mai bine să încorporați direct discurile (cu excepția cazului în care aveți deja RAIDZ3 și încă mai aveți discuri de rezervă).

În plus, resilverizarea durează și are loc într-o stare vulnerabilă (RAIDZ1, oglinzi cu 2 căi) sau cu performanțe reduse (RAIDZ2, RAIDZ3, oglinzi cu 3 căi), ceea ce nu s-ar fi întâmplat dacă ați fi atașat deja dispozitivul la vdev.

Practic, rezervele la cald sunt o chestie pentru matricele mari. Dacă aveți 27 de discuri împărțite în 3 vdev-uri de 9 discuri în RAIDZ3, puteți adăuga 3 hot spare-uri pentru a reduce momentele de genul „Este ora 2 dimineața și 3 discuri au cedat, acum trebuie să mă ridic și să repar mizeria asta” (presupunând un sistem cu 32 de discuri). Sistemele mai mici nu au de obicei suficiente discuri pentru a ajunge măcar la situația „2+ vdevs și Z2/Z3”. O excepție ar fi oglinzile (de exemplu, 6 x 2), unde coliziunile sunt mult mai aproape de a fi fatale pentru pool (și nu aveți suficiente discuri pentru a le face 6 x 3).


Dispunerea optimă a pool-ului

Câteva sfaturi de la blogul Nex7 cu privire la dispunerea pool-ului:

  • Nu folosiți raidz1 pentru discuri de 1TB sau mai mari.
  • Pentru raidz1, nu folosiți mai puțin de 3 discuri și nici mai mult de 7 discuri în fiecare vdev (și, din nou, acestea ar trebui să aibă o dimensiune mai mică de 1 TB, de preferință sub 750 GB) (5 este o medie tipică).
  • Pentru raidz2, nu folosiți mai puțin de 6 discuri și nici mai mult de 10 discuri în fiecare vdev (8 este o medie tipică).
  • Pentru raidz3, nu folosiți mai puțin de 7 discuri, nici mai mult de 15 discuri în fiecare vdev (13 & 15 reprezintă media tipică).
  • Oglinzile învinge raidz aproape de fiecare dată. Potențial IOPS mult mai mare de la un pool de oglinzi decât de la orice pool raidz, la un număr egal de unități. Singurul dezavantaj este redundanța – raidz2/3 sunt mai sigure, dar mult mai lente. Singura modalitate care nu schimbă performanța în favoarea siguranței este oglinzile cu 3 căi, dar sacrifică o tonă de spațiu (dar am văzut clienți care fac acest lucru – dacă mediul dvs. o cere, costul poate merita).
  • Pentru >= discuri de 3TB, oglinzile cu 3 căi încep să devină din ce în ce mai convingătoare.

Aceasta înseamnă că, în cazul dvs., ați avea următoarele opțiuni:

  1. 9 discuri utilizabile: (Z3 cu 9+3)
  2. 8 discuri utilizabile: (Z2 cu 4+2) ++ (Z2 cu 4+2)
  3. 5 discuri utilizabile: (2 oglinzi) * 5 ++ (rezervă la cald) * 2
  4. 4 discuri utilizabile: (3 oglinzi) * 4

Le-aș clasifica (descrescător) astfel:

  • În termeni de spațiu utilizabil: 1, 2, 3, 4
  • Din punct de vedere al siguranței: 1, 2/4, 3
  • Din punct de vedere al vitezei: 4, 3, 2, 1
  • Din punct de vedere al capacității de a extinde/adăuga unități: 3, 4, 2, 1

Eu nu aș folosi RAIDZ1 indiferent de dimensiune, deoarece s-ar putea să doriți mai târziu să le înlocuiți cu discuri mai mari și atunci se vor vedea problemele (ceea ce înseamnă că nu ați dori să faceți upgrade în acest mod și s-ar putea să nu puteți mări spațiul de stocare fără a adăuga discuri suplimentare).

Comentarii

  • Wow, aceasta este o postare excelentă; sper ca mulți oameni să aibă ocazia să se refere la ea. Ați acoperit o mulțime de compromisuri într-un spațiu foarte scurt. În cazul meu, încarc aproximativ 5-10TB de lucruri de la sistemele care se retrag, apoi, după aceea, mă aștept la un raport de citire/scriere foarte mare. Deoarece performanța nu este prioritatea mea, se pare că #1 este cea mai bună alegere. Vă mulțumesc din nou. –  > Por AlanObject.
Cédric Dufour

Tocmai am testat o configurație ZFS de test pentru a răspunde la această întrebare în ceea ce privește performanțele (pe o pereche de servere vechi și prăfuite, reînviate din cenușă).

Configurația mea este:

  • 2x Intel Xeon L5640 CPU @ 2.27GHz (total: 12 nuclee; HT dezactivat)

  • 96GiB DDR3 RAM @ 1333MHz

  • Controler Adaptec 5805Z, exportând toate discurile ca JBOD (cu write-cache activat, datorită NVRAM-ului cu baterie a controlerului)

  • 12x discuri SAS de 146GB la 15kRPM (Seagate ST3146356SS).

  • pe-replicare DRBD pe discuri (protocol C) prin IP-over-Infiniband (20Gb/s Mellanox MT25204).

  • ZFS 0.7.6 pe Debian/Stretch

  • zpool create -o ashift=12 … /dev/drbd{…} (Notă: DRBD funcționează cu o dimensiune a „unității” de replicare de 4KiB)

  • zfs create -o recordsize=128k -o atime=off -o compression=off -o primarycache=metadata … (ultimele două doar în scopuri de analiză comparativă)

Mai jos, rezultatele bonnie++ pentru toate combinațiile interesante posibile de RAIDz2 și RAIDz3 (media a 5 rulări a 12 procese bonnie++ sincronizate):

TEST: # data bandwidth
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 1024:1024k -n 0 -q -x 1 -y s &
      done
      # create/stat/delete operations
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 0 -n 128:0:0:16 -q -x 1 -y s &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=278273, RW=150845, RD=487315
 ops/s: SCr=132681, SDl=71022, RCr=133677, RDl=71723

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=276121, RW=158854, RD=480744
 ops/s: SCr=132864, SDl=71848, RCr=127962, RDl=71616

CASE: 1*RAIDz2(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=260164, RW=151531, RD=541470
 ops/s: SCr=137148, SDl=71804, RCr=137616, RDl=71360

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=269130, RW=184821, RD=672185
 ops/s: SCr=134619, SDl=75716, RCr=127364, RDl=74545

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=255257, RW=135808, RD=509976
 ops/s: SCr=136218, SDl=74684, RCr=130325, RDl=73915

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=379814, RW=225399, RD=586771
 ops/s: SCr=120843, SDl=69416, RCr=122889, RDl=65736

DATA: WR  = Sequential Write
      RW  = Sequential Rewrite
      RD  = Sequential Read
      SCr = Sequential Create
      SDl = Sequential Delete
      RCr = Random Create
      RDl = Random Delete

În ceea ce privește performanțele:

  • 2*RAIDz2(4d+2p+0s) este câștigătorul pentru performanțe echilibrate de citire/scriere

  • 1*RAIDz3(8d+3p+1s) pentru performanțe maxime de citire (destul de ciudat)

În ceea ce privește modul de interpretare/explicare a acestor rezultate; 1 penny al meu:

  • 8 discuri de date împart exact dimensiunea înregistrărilor de 128k, ceea ce ar putea explica (?) de ce acestea depășesc întotdeauna performanța a 9 sau 10 discuri de date (având în vedere că testul este efectuat cu o dimensiune a bucăților de 1024k, care se aliniază exact pe toate discurile).

  • M-aș aștepta ca RAIDz3 să aibă performanțe mai slabe decât RAIDz2, însă cazul 1*RAIDz3(8d+3p+1s) contrazice foarte ciudat acest lucru

  • dimensiunea semnificativ mai mică a VDEV-urilor din cazul 2*RAIDz2(4d+2p+0s) ar putea explica (?) de ce se comportă semnificativ mai bine la scriere.

EDIT 1

Ca răspuns la comentariul lui @AndrewHenle, mai jos sunt prezentate benchmark-uri suplimentare cu diferite dimensiuni ale „chunk-urilor”. Din păcate, bonnie++ nu permite alte dimensiuni ale „chunk-urilor” decât puterea lui 2; așa că am revenit la (5 rulări medii) de dd:PS: nu uitați, memoria cache de citire ZFS (ARC) este dezactivată

TEST: # WR: Sequential Write
      rm /zfs/.../dd.*
      for n in $(seq 1 <threads>); do
        dd if=/dev/zero of=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done
      # RD: Sequential Read
      for n in $(seq 1 <threads>); do
        dd of=/dev/null if=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  418.64   (n/a)  434.56  404.44  361.76
        RD  413.24   (n/a)  469.70  266.58   15.44

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  428.44  421.78  440.76  421.60  362.48
        RD  425.76  394.48  486.64  264.74   16.50

CASE: 1*RAIDz3(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  422.56  431.82  462.14  437.90  399.94
        RD  420.66  406.38  476.34  259.04   16.48

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  470.42   (n/a)  508.96  476.34  426.08
        RD  523.88   (n/a)  586.10  370.58   17.02

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  411.42   (n/a)  450.54  425.38  378.38
        RD  399.42   (n/a)  444.24  267.26   16.92

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  603.64   (n/a)  643.96  604.02  564.64
        RD  481.40   (n/a)  534.80  349.50   18.52

În ceea ce privește cei 1 penny ai mei:

  • ZFS optimizează în mod evident scrierile suficient de inteligent (chiar și pentru dimensiuni ale bucăților sub dimensiunea înregistrării) și/sau (?) controlerul Adaptec (nevolatilă, 512MiB) ajută în mod semnificativ în această privință.

  • Evident, din nou, dezactivarea memoriei cache de citire ZFS (ARC) este foarte dăunătoare pentru dimensiuni ale bucăților apropiate sau mai mici decât dimensiunea înregistrării; și se pare că memoria cache a controlerului Adaptec nu este (surprinzător?) utilizată în scopuri de citire. În concluzie: dezactivarea ARC în scopuri de benchmark permite obținerea de informații despre performanțele „brute, de nivel inferior”, dar este nerecomandată pentru utilizarea în producție (în afară de cazuri specifice, cum ar fi o bibliotecă de fișiere de mari dimensiuni rareori utilizată).

  • Se pare că ajustarea dimensiunii chunk-urilor pentru a se potrivi cu dimensiunea VDEV-urilor nu să joace un rol pozitiv [presupunere greșită; a se vedea EDIT 2].

EDIT 2

Despre RAIDz și dimensiunea blocurilor (ashift) și dimensiunea înregistrărilor (sistemul de fișiere ZFS):

Și un AVERTISMENT:

LINIA DE FUND(confirmând ceea ce s-a spus deja în alte răspunsuri)

  • (Striping) VDEV-urile mai mici – cu mai puține discuri de date – au performanțe mai bune decât cele mari; calcularea/verificarea parității este în mod evident o operațiune costisitoare, care crește mai rău decât liniar în funcție de cantitatea de discuri de date (cf. cazurile 8d <-> 2*4d).

  • VDEV-urile de aceeași mărime cu mai multe discuri de paritate au performanțe mai bune decât cele cu mai puține discuri de paritate și discuri de rezervă la cald, și asigură o mai bună protecție a datelor

  • Folosiți hot spare(s) pentru a răspunde preocupărilor de tipul „nu mă treziți în miez de noapte”, dacă mai aveți încă un disc sau mai multe discuri de rezervă după ce ați favorizat discurile de paritate [ATENȚIE! vezi EDIT 2]

POST SCRIPTUM

Eventualul meu caz de utilizare fiind găzduirea unei baze de date de serii temporale (pe termen lung) (scrieri constante de dimensiuni medii și citiri sporadice potențial foarte mari), pentru care am foarte puțină documentație detaliată privind modelele de I/O (cu excepția unei recomandări „optimizate pentru SSD”), voi opta personal pentru 1*RAIDz2(8d+3p+1s): securitate maximă, capacitate puțin mai mică, (a 2-a) cea mai bună performanță

Comentarii

  • Nu știu să interpretez din mers argumentele bonnie++, dar cât de mari au fost citirile/scrierile tale? Par a fi de 1 MB, ceea ce probabil se întinde pe vdev-uri întregi. Încercați ceva de genul scrierilor nealiniate de 4 kb într-o matrice RAIDZ, care este o dimensiune IO mai tipică pentru lucruri precum clienții de e-mail și alte aplicații de utilizator. –  > Por Andrew Henle.
  • @AndrewHenle Confirm dimensiunea „chunk” de 1 MB frumos aliniată VDEV-s writes/reads „chunk” (pentru cazurile de 8 discuri de date). De asemenea, am efectuat unele teste cu această dimensiune „chunk” la fel de mică ca 4KiB (mult sub dimensiunea de înregistrare de 128KiB), ceea ce a dus la o amplicare catastrofală a citirilor (și la scăderea performanțelor) în absența primarycache=all (absență pe care chiar nu v-ar plăcea să o doriți pentru modelele de utilizare din viața reală, altele decât cele de benchmark). Ceea ce ar putea fi interesant ar fi efectuarea de teste suplimentare cu dimensiunea chunk-ului care să se potrivească perfect cu VDEV-urile pentru 9 și 10 discuri de date (s-ar putea să mă interesez de acest lucru și să raportez; nu promit nimic, totuși). –  > Por Cédric Dufour.
ewwhite

Recomandarea mea este:

2 x 5 discuri RAIDZ1 + două de rezervă.

sau

3 x 3 discuri RAIDZ1 + rezerve

sau

10 discuri RAID oglinzi

sau 2 x RAIDZ2 de 5 sau 6 discuri cu sau fără rezerve

Acest lucru depinde de tipul de disc utilizat. Dacă sunt unități de 7200 RPM de peste 2 TB, alegeți RAIDZ2. Dacă sunt de 2TB și utilizator, RAIDZ1 este bun.

Tags:,