FreeNAS – Partea a 3-a: Tutorial ZFS, zpool și partiționare

fn-logoTutorial avansat de partiționare, configurare ZFS și migrare de la două la trei discuri.

Ce putem face ca să păstrăm redundanța și toleranța la defectarea discurilor dar să folosim mai eficient spațiul de stocare?

Ce putem face împotriva fenomenului de “silent corruption” ?

RAID vs ZFS

Atât RAID-ul cât și ZFS-ul oferă mecanisme de redundanță. Totuși ZFS-ul are câteva avantaje:

  • protecție la coruperea ascunsă a datelor “silent corruption” prin mecanisme de checksum pe fiecare bloc scris pe disc, un așa numit self-healing nativ
  • deduplication – un mecanism de scriere o singură dată a unui fișier chiar dacă acesta se află de două sau mai multe ori pe disc, acest “feature” cere totuși resurse de RAM ECC și putere de procesare suplimentare dar și expune la risc în cazul unei căderi de tensiune neașteptate pentru că pot apărea coruperi ale datelor,
  • posibilitatea de a face snapshot-uri ale setului de date la un moment dat,
  • posibilitatea de a amesteca discuri de tipuri și capacități diferite în același set de date sau pool,
  • în loc de fsck, scandisk, chkdsk etc folosite la alte sisteme de operare, ZFS oferă un tool, scrub, care permite detecția și corecția eventualelor erori apărute “on-the-fly” fără a fi nevoie ca pool-ul să fie offline, așa cum se întâmplă în cazul fsck sau chkdsk, totodată, scrub scanează datele în profunzime, nu doar câmpurile metadata, așa cum face fsck, procesul putând dura ore sau zile,
  • fiind un sistem pe 128 de biți, permite scalare practic la infinit, teoretic fiind limitat la milioane de terabytes, permițând în felul acesta adăugarea oricâtor discuri la pool-ul de date,
  • oferă compresie și criptare în mod nativ
  • oferă mecanisme de accelerare în cazul folosirii de drive-uri SSD (ZIL, L2ARC)
  • merge și fără plăci adaptoare de tip controller RAID, chiar sunt contraindicate, iar dacă sunt folosite, se recomandă trecerea lor în mod JBOD, în niciun caz RAID, pentru că vor interfera cu sistemele de detecție și corecție a erorilor ale ZFS,
  • ZFS-ul este mult mai ieftin, fiind o soluție pur software.

Dezavantajele ZFS sunt memoria RAM necesară mai mare, de minim 2GB preferabil cu ECC, și puterea de calcul mai mare pentru acele checksum-uri nesfârșite. RAM-ul cu ECC este recomandat pentru a evita coruperea datelor în cazul funcționării cu o memorie defectă.

Cum folosim ZFS pe NAS-ul nostru?

Presupunem că pe NAS-ul nostru avem de stocat două feluri de date: multimedia, cu importanță moderată dar care ocupă mult și documente foarte importante care ocupă puțin dar pe care nu ne permitem să le pierdem. Vom arăta configurarea unui sistem cu trei discuri care oferă redundanță la pierderea unuia sau a două discuri.

Din cele trei discuri de 30GB pe care le avem la dispoziție pentru exemplificare, vom alege un spațiu util de 5GB pentru documente (pool-ul RAIDZ2) și vom lăsa restul pentru multimedia (pool-ul RAIDZ1).

În exemplul prezentat discurile sunt identificate cu daX din cauza mașinii virtuale, totuși, în cazul unui sistem real cu discuri SATA, acestea vor fi identificate cu adaX!

Pornind de la tutorialul precedent vom migra mirror-ul (cu două discuri) către un sistem cu trei discuri partiționate în două pool-uri RAIDZ1, respectiv RAIDZ2.

De exemplu, un pool cu trei discuri de 30GB în RAIDZ1 oferă redundanță la defectarea unui singur disc și o capacitate utilă de: 92% * 2 * 30GB = 55GB. Procentul de 92% poate scădea în cazul stocării a multor fișiere de mici dimensiuni. După același model, un pool RAIDZ2 din trei discuri de 30GB oferă redundanță la defectarea a două discuri, dar o capacitate de stocare de numai 92% *1 * 30 = 27GB.

Pentru pașii care urmează vom avea nevoie de command line shell. Găsiți aici cum se activează.

Migrarea unui pool ZFS de la MIRROR către două  pool-uri RAIDZ1, respectiv RAIDZ2

Atenție! Procesul pe care îl vom parcurge împreună se poate să dureze mai multe ore, funcție de cantitatea de date aflată pe mirror-ul existent.

Ne asigurăm că cele două discuri sunt în stare bună, vizibile de către sistem:   Storage -> View Diskstwo-disks

apoi că mirror-ul este funcțional: Storage -> Volumesmirror-healthy

Oprim serverul NAS (cu ‘Shutdown’), montăm fizic cel de-al treilea disc și repornim NAS-ul. După repornire trebuie să vedem trei discuri prezente:  Storage -> View Disks

3-disks

Dacă apare o eroare semnalizată prin clipirea semnului roșu alert, procedăm în continuare așa cum se vede în pasul 1, altfel, dacă nu sunt erori mergem direct la pasul 2.

1. Cum procedăm dacă după restart discurile nu mai sunt vizibile din cauza schimbării identificatorilor daX sau adaX?

Mergem la Storage și vedem că mirror-ul este degradedalert-degraded

Trebuie să identificăm eroarea, și anume discul dispărut și discul bun, încă vizibil în sistem.

Folosind shell-ul, verificăm care este problema pool-ului (-x ne va arăta doar pool-urile cu probleme):

# zpool status -x

În cazul nostru, observăm că discul da0 a dispărut:

pool: storage
state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://illumos.org/msg/ZFS-8000-2Q
scan: scrub repaired 0 in 0h18m with 0 errors on Sun Nov 22 17:22:50 2015
config:

NAME                                            STATE     READ WRITE CKSUM
storage                                         DEGRADED     0     0     0
mirror-0                                      DEGRADED     0     0     0
6177333059007759089                         UNAVAIL      0   0   0 was /dev/da0p1
gptid/abace464-6882-11e5-baec-000c297a5a10  ONLINE       0     0     0

errors: No known data errors

Evident, mirror-ul este degraded, discul marcat de mine cu roșu este cel ascuns, iar cel cu verde este cel bun, care trebuie protejat cu orice preț, pentru că momentan acesta conține singura copie validă a datelor noastre!

În shell scriem:

# glabel status

și obținem ceva de forma

                                      Name  Status  Components
gptid/abace464-6882-11e5-baec-000c297a5a10     N/A  da1p1
gptid/31f215a9-67db-11e5-b967-000c297a5a10     N/A  ada0p1

În lista de gptid-uri raportate de glabel, identificăm discul bun cu mare atenție, iar în cazul nostru observăm că acesta este da1. Prin urmare, acest da1 trebuie protejat în continuare. Prin eliminare, da2 este discul lipsă din mirror. Și pentru că ceea ce urmează să facem oricum ar fi implicat stergerea unuia dintre membrii mirror-ului, nu îi mai facem nimic lui da2. Dacă am fi avut nevoie să restaurăm mirror-ul am fi făcut un replace al discului unavailable cu acest da2.

Prin urmare avem:

  • da0 – discul nou introdus, gol,
  • da1 – discul cu date utile,
  • da2 – discul care va fi golit

Acum sărim direct la pasul 3

2. Cum procedăm dacă după restart discurile sunt vizibile ca înainte și nu este semnalată nici o eroare?

mirror-healthy-2

Pe scurt, pașii care urmează:

  • rulăm scrub pentru a asigura integritatea mirror-ului
  • identificăm membrii mirror-ului,
  • stricăm mirror-ul, detașând unul dintre membri

Pe larg, cei trei pași sunt explicați în cele ce urmează.

  • Rulăm scrub pentru a asigura integritatea mirror-ului

Procesul durează ceva timp depinzând de catitatea de date de pe discuri, deci asigurați-vă că poate rula chiar câteva ore:

# zpool scrub storage

după care urmărim evoluția procesului scrub executând din când în când comanda:

# zpool status storage

abia după ce scrub-ul termină de rulat putem trece la următorul pas

  • Identificăm membrii mirror-ului
# zpool status storage
  pool: storage
 state: ONLINE
  scan: scrub repaired 0 in 0h7m with 0 errors on Mon Nov 30 12:44:20 2015
config:

    NAME                                            STATE     READ WRITE CKSUM
    storage                                         ONLINE       0     0     0
      mirror-0                                      ONLINE       0     0     0
        gptid/abace464-6882-11e5-baec-000c297a5a10  ONLINE       0     0     0
        gptid/f8f9726e-974a-11e5-a96b-000c297a5a10  ONLINE       0     0     0

errors: No known data errors

după care identificăm gptid-urile:

# glabel status
                                      Name  Status  Components
gptid/f8f9726e-974a-11e5-a96b-000c297a5a10     N/A  da0p1
gptid/abace464-6882-11e5-baec-000c297a5a10     N/A  da1p1
gptid/31f215a9-67db-11e5-b967-000c297a5a10     N/A  ada0p1
  • La următorul pas, stricăm mirror-ul prin eliminarea unuia dintre discuri

alegem să eliminăm da0 pentru a păstra compatibilitatea cu paragraful precedent

# zpool offline storage gptid/f8f9726e-974a-11e5-a96b-000c297a5a10
# zpool status storage
  pool: storage
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: scrub repaired 0 in 0h7m with 0 errors on Mon Nov 30 12:44:20 2015
config:

    NAME                                            STATE     READ WRITE CKSUM
    storage                                         DEGRADED     0     0     0
      mirror-0                                      DEGRADED     0     0     0
        gptid/abace464-6882-11e5-baec-000c297a5a10  ONLINE       0     0     0
        12985453911403560418      OFFLINE      0     0     0  was /dev/gptid/f8f9726e-974a-11e5-a96b-000c297a5a10

errors: No known data error

verificăm din nou gptid-urile:

# glabel status
                                      Name  Status  Components
gptid/f8f9726e-974a-11e5-a96b-000c297a5a10     N/A  da0p1
gptid/abace464-6882-11e5-baec-000c297a5a10     N/A  da1p1
gptid/31f215a9-67db-11e5-b967-000c297a5a10     N/A  ada0p1

Discul da1 este cel care trebuie protejat în continuare, acesta conținând singura copie a datelor noastre în acest moment!

3. Continuarea procesului indiferent dacă au fost sau nu erori după adăugarea celui de-al treilea disc

Pașii care urmează, pe scurt:

  • partiționăm cele două discuri care nu aparțin mirror-ului
  • creăm un disc virtual, în RAM, necesar la crearea pool-ului
  • creăm primul pool, safe, de tip RAIDZ2 din cele două partiții mici și discul virtual
  • eliminăm discul virtual din pool-ul safe
  • creăm alt disc virtual din motive de conflict în zpool
  • creăm al doilea pool, media, de tip RAIDZ1 din cele două partiții mari și discul virtual
  • eliminăm discul virtual din pool-ul media
  • ștergem discurile virtuale
  • mutăm datele de pe discul rămas în mirror pe cele două pool-uri nou create
  • distrugem mirror-ul
  • partiționăm și cel de-al treilea disc
  • înlocuim discul virtual din pool-ul safe cu partiția mică din cel de-al treilea disc
  • înlocuim discul virtual din pool-ul media cu partiția mare din cel de-al treilea disc
  • scrub pe pool-ul safe
  • scrub pe pool-ul media

În cele ce urmează vom arăta pașii în detaliu.

  • Partiționăm cele două discuri care nu aparțin mirror-ului

Verificăm starea partițiilor de pe cele trei discuri instalate:

# gpart show
=>      34  58720189  da1  GPT  (28G)
        34        94       - free -  (47k)
       128  58720088    1  freebsd-zfs  (28G)
  58720216         7       - free -  (3.5k)

=>      34  15728573  ada0  GPT  (7.5G)
        34      1024     1  bios-boot  (512k)
      1058         6        - free -  (3.0k)
      1064  15727536     2  freebsd-zfs  (7.5G)
  15728600         7        - free -  (3.5k)

=>      34  58720189  da0  GPT  (28G)
        34  58720189    1  freebsd-zfs  (28G)

observăm că discul da2 nu este vizibil și asta deoarece nu este partiționat.

Ștergem eventualele partiții existente pe cele două discuri da0 și da2:

# gpart delete -i 1 da0
da0p1 deleted
# gpart destroy da0
da0 destroyed

Asemănător procedăm și cu da2, dacă este partiționat. Încă o dată, nu facem nicio operație asupra partițiilor discului da1!

Pentru schema noastră cu două niveluri de redundanță, vom crea următoarele partiții:

da0 - 5GB | 23GB
da1 - 5GB | 23GB
da2 - 5GB | 23GB

și următoarea organizare a celor două pool-uri:

safe  - de tip raidz2 - da0p1 | da1p1 | da2p1
media - de tip raidz1 - da0p2 | da1p2 | da2p2

Acum începem crearea partițiilor:

# gpart create -s GPT  da0
da0 created
# gpart add -i 1 -a 4k -t freebsd-zfs  -s 5G da0
da0p1 added
# gpart add -i 2 -a 4k -t freebsd-zfs da0
da0p2 added
# gpart create -s GPT  da2
da2 created
# gpart add -i 1 -a 4k -t freebsd-zfs  -s 5G da2
da2p1 added
# gpart add -i 2 -a 4k -t freebsd-zfs da2
da2p2 added

La final verificăm rezultatul:

# gpart show
=>      34  58720189  da1  GPT  (28G)
        34        94       - free -  (47k)
       128  58720088    1  freebsd-zfs  (28G)
  58720216         7       - free -  (3.5k)

=>      34  15728573  ada0  GPT  (7.5G)
        34      1024     1  bios-boot  (512k)
      1058         6        - free -  (3.0k)
      1064  15727536     2  freebsd-zfs  (7.5G)
  15728600         7        - free -  (3.5k)

=>      34  58720189  da0  GPT  (28G)
        34         6       - free -  (3.0k)
        40  10485760    1  freebsd-zfs  (5.0G)
  10485800  48234416    2  freebsd-zfs  (23G)
  58720216         7       - free -  (3.5k)

=>      34  58720189  da2  GPT  (28G)
        34         6       - free -  (3.0k)
        40  10485760    1  freebsd-zfs  (5.0G)
  10485800  48234416    2  freebsd-zfs  (23G)
  58720216         7       - free -  (3.5k)

Am marcat cu verde discurile proaspăt actualizate și cu roșu discul cu datele utile.

  • Creăm un disc virtual, în RAM, necesar la crearea pool-ului

Discurile virtuale vor fi create în RAM și vor avea 6, respectiv 25GB, și chiar dacă nu avem atâta memorie nu vor fi probleme pentru că îl vom trece offline înainte de utilizarea efectivă a pool-ului. Dimensiunea aleasă pentru acest disc virtual trebuie să fie mai mare decât oricare dintre partițiile implicate în pool, altfel pool-ul creat nu va folosi la maximum partițiile. Discurile virtuale vor face parte din pool-uri, după care vor fi eliminate, iar pool-urile vor funcționa în degraded state, până la terminarea operațiunii de migrare.

Creăm discul virtual:

# mdconfig -a -t malloc -s 6G
md0
  • Creăm primul pool, safe, de tip RAIDZ2 din cele două partiții mici și discul virtual
# zpool create -f safe raidz2 /dev/da0p1 /dev/da2p1 /dev/md0
  • Eliminăm discul virtual din pool-ul safe
# zpool offline safe /dev/md0
  • Creăm alt disc virtual din motive de conflict în zpool
# mdconfig -a -t malloc -s 25G
md1
  • Creăm al doilea pool, media, de tip RAIDZ1 din cele două partiții mari și discul virtual
# zpool create -f media raidz1 /dev/da0p2 /dev/da2p2 /dev/md1
  • Eliminăm discul virtual din pool-ul media
# zpool offline media /dev/md1
  • Ștergem discurile virtuale
# mdconfig -d -u md0
# mdconfig -d -u md1

Verificăm pool-urile nou create:

# zpool status -x
  
  pool: media
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: none requested
config:

    NAME                      STATE     READ WRITE CKSUM
    media                     DEGRADED     0     0     0
      raidz1-0                DEGRADED     0     0     0
        da0p2                 ONLINE       0     0     0
        da2p2                 ONLINE       0     0     0
        11254977217173055466  OFFLINE      0     0     0  was /dev/md1

errors: No known data errors

  pool: safe
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: none requested
config:

    NAME                      STATE     READ WRITE CKSUM
    safe                      DEGRADED     0     0     0
      raidz2-0                DEGRADED     0     0     0
        da0p1                 ONLINE       0     0     0
        da2p1                 ONLINE       0     0     0
        12654067252789104954  OFFLINE      0     0     0  was /dev/md0

errors: No known data errors

  pool: storage
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: scrub repaired 0 in 0h7m with 0 errors on Mon Nov 30 12:44:20 2015
config:

    NAME                                            STATE     READ WRITE CKSUM
    storage                                         DEGRADED     0     0     0
      mirror-0                                      DEGRADED     0     0     0
        gptid/abace464-6882-11e5-baec-000c297a5a10  ONLINE       0     0     0
        12985453911403560418   OFFLINE   0  0  0  was /dev/gptid/f8f9726e-974a-11e5-a96b-000c297a5a10

errors: No known data errors

Și, evident, avem toate cele trei pool-uri degraded.

 

  • Mutăm datele de pe discul rămas în mirror pe cele două pool-uri nou create

Mutarea datelor poate fi făcută fie automat printr-o comandă specială, fie manual prin copierea grupurilor de directoare și fișiere. Pentru că metodele manuale sunt la alegerea fiecăruia, vom insista doar asupra celor automate. Dintre acestea am ales pentru exemplificare două: zfs și rsync.

Prima metodă, zfs, este recomandată doar în cazul în care pool-ul țintă, în cazul nostru media, este gol. Dacă am urmat până acum întocmai pașii din tutorial, media este gol.

Mai întâi vom crea un snapshot al mirror-ului inițial, storage:

# zfs snapshot storage@now

apoi vom iniția un proces care va dura ceva timp, funcție de cantitatea de date aflată pe mirror. Recomand utilizarea unei console ssh, nu pe cea din webGUI:

# zfs send -R storage@now | zfs receive -F media

Consola va părea că s-a blocat. Nu are nicio problemă, comanda rulează mai mult timp fără să arate vreun semn vizibil, iar evoluția operației o putem urmări într-o consolă deschisă separat prin ssh:

# zfs list

Mai întâi am creat acel snapshot storage@now, pe care prin două comenzi concatenate zfs send și zfs receive conectate printr-un pipe, l-am trimis de pe pool-ul inițial storage către pool-ul destinație media. Flag-urile folosite -R se referă la recursivitate, iar -F forțează suprascrierea totală a pool-ului media, indiferent de ce s-ar afla pe el. De aceea acest pool destinație trebuie să fie gol. Vom observa că după rularea comenzilor zfs send/receive, încă un snapshot a fost creat media@now. După terminarea execuției zfs send/receive, cele două snapshot-uri pot fi listate și eventual șterse folosind comenzile de mai jos.

Câteva comenzi utile pentru zfs:

zfs list -t snapshot

– arată o listă a snapshot-urilor

zfs list -o space

– arată o listă cu spațiile ocupate

zfs destroy nume_pool@nume_snapshot

– șterge un snapshot

zfs snapshot nume_pool/nume_dataset@nume_snapshot

– creează un snapshot al unui set de date

 

Mai departe, copierea datelor în pool-ul safe se poate face fie manual cu cp, fie cum vom vedea mai jos, cu rsync.

După cum spuneam, cea de-a doua metodă de copiere propusă este rsync. Pentru a o folosi trebuie să avem montate cele două pool-uri proaspăt create. Bineînțeles acestea se pot monta și cu mount, dar noi vom folosi o metodă diferită. Mai întâi vom exporta cele două pool-uri:

# zpool export -f safe
# zpool export -f media

După care le vom importa din webGUI:

import-volume

import-step1import-step2

 

import-running

Importul durează până la câteva minute, după care repetăm operația și pentru pool-ul media, iar la final, toate cele trei pool-uri vor fi vizibile în webGUI:

pools-imported

Odată importate cele două pool-uri pot fi verificate cu mount, zpool status și pot fi sharate în rețea, la fel ca mirror-ul, așa cum am arătat în partea întâi a tutorialului.

Folosim rsync pentru copierea datelor din storage în media și safe:

# cd /mnt/storage
# ls -al

drwxrwxrwx   4 www   www      5 Dec  1 20:34 ./
drwxr-xr-x   5 root  wheel  160 Dec  1 20:25 ../
drwxrwxrwx   2 www   www      5 Dec  1 20:28 Documents/
drwxrwxrwx  21 www   www     21 Dec  1 15:17 Movies/

# rsync -ah Movies /mnt/media
# rsync -ah Documents /mnt/safe

Observați lipsa caracterului ‘/’ de la finalul numelor Movies și Documents. Lipsa acelui caracter determină rsync să copieze cu tot cu directoarele părinte, Movies, respectiv Documents.

Pentru a fi accesibile din rețea, vom asigura un share prin CIFS, așa cum am văzut la finalul părții întâi a tutorialului.  După ce ne asigurăm că fișierele sunt accesibile și toate la locul lor, putem trece la ștergerea mirror-ului și aducerea pool-urilor media și safe din degraded în healthy. Totodată ar trebui scos share-ul CIFS de pe calea /mnt/storage și rulate din nou comenzile chmod si chown, așa cum am văzut în prima parte.

Mai întâi ștergem mirror-ul:

# zpool destroy storage

apoi scoatem pool-ul storage și din webGUI:

pool-remove-ui

pool-remove-ui-conf

apoi repartiționăm discul recuperat din mirror:

# gpart show

=>      34  58720189  da0  GPT  (28G)
        34         6       - free -  (3.0k)
        40  10485760    1  freebsd-zfs  (5.0G)
  10485800  48234416    2  freebsd-zfs  (23G)
  58720216         7       - free -  (3.5k)

=>      34  58720189  da1  GPT  (28G)
        34  58720189    1  freebsd-zfs  (28G)

=>      34  58720189  da2  GPT  (28G)
        34         6       - free -  (3.0k)
        40  10485760    1  freebsd-zfs  (5.0G)
  10485800  48234416    2  freebsd-zfs  (23G)
  58720216         7       - free -  (3.5k)

=>      34  15728573  ada0  GPT  (7.5G)
        34      1024     1  bios-boot  (512k)
      1058         6        - free -  (3.0k)
      1064  15727536     2  freebsd-zfs  (7.5G)
  15728600         7        - free -  (3.5k)
 
# gpart delete -i 1 da1
da1p1 deleted
# gpart destroy da1
da1 destroyed
# gpart create -s GPT  da1
da1 created
# gpart add -i 1 -a 4k -t freebsd-zfs  -s 5G da1
da1p1 added
# gpart add -i 2 -a 4k -t freebsd-zfs da1
da1p2 added

Procesul ce urmează, resilvering, durează ceva timp pentru fiecare dintre pool-uri.
Înlocuim partiția lipsă din safe:

# zpool status safe
 pool: safe
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: scrub repaired 0 in 0h0m with 0 errors on Tue Dec  1 18:14:01 2015
config:

    NAME                    STATE     READ WRITE CKSUM
    safe                    DEGRADED     0     0     0
      raidz2-0              DEGRADED     0     0     0
        da0p1               ONLINE       0     0     0
        da2p1               ONLINE       0     0     0
        130833272578055237  OFFLINE      0     0     0  was /dev/md0

errors: No known data errors
# zpool replace safe 130833272578055237 /dev/da1p1

procesul de replace poate dura câteva ore sau zile așa că ne înarmăm cu răbdare, timp în care putem urmări evoluția cu zpool status safe. Nu este recomandat să facem două operații de replace simultan pe mai multe pool-uri din motive de performanță, stres al componentelor și de siguranța datelor.

După ce s-a încheiat operația precedentă, continuăm cu următorul pool:

# zpool status media
 pool: media
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: scrub repaired 0 in 0h9m with 0 errors on Tue Dec  1 18:23:25 2015
config:

    NAME                      STATE     READ WRITE CKSUM
    media                     DEGRADED     0     0     0
      raidz1-0                DEGRADED     0     0     0
        da0p2                 ONLINE       0     0     0
        da2p2                 ONLINE       0     0     0
        13465919965475166454  OFFLINE      0     0     0  was /dev/md1

errors: No known data errors 

# zpool replace media 13465919965475166454 /dev/da1p2

În timpul procesului de resilvering, cam așa arată rezultatul comenzii zpool status:

  pool: media
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Dec  1 21:51:18 2015
        21.5G scanned out of 28.3G at 22.9M/s, 0h5m to go
        7.17G resilvered, 76.11% done
config:

    NAME                        STATE     READ WRITE CKSUM
    media                       DEGRADED     0     0     0
      raidz1-0                  DEGRADED     0     0     0
        da0p2                   ONLINE       0     0     0
        da2p2                   ONLINE       0     0     0
        replacing-2             OFFLINE      0     0     0
          13465919965475166454  OFFLINE      0     0     0  was /dev/md1
          da1p2                 ONLINE       0     0     0  (resilvering)

errors: No known data errors

După încheierea înlocuirilor, în webGUI ar trebui să fie totul healthy

two-pools-healthy

La final, dacă doriți și vă permite timpul, puteți să mai rulați câte un scrub, pe rând, pe fiecare dintre pool-uri.

EnjoY 🙂

Începutul tutorialului

Urmează:

  • FreeNAS – Partea a 4-a: norişorul din NAS
Share this:

No Responses

Leave a Reply

Your email address will not be published.