[Resolu] Règle 10 non respectée : changer un DD sans casse

[ernie]

Hello,

Je n'ai pas respecté la règle 10 : je n'achète pas, autant que possible, mes disques en lot chez le même fournisseur pour qu'ils ne soient pas tous de la même série.

Je le savais dès le départ et j'ai prévu de temps en temps de changer un disque par ci par là.

Par contre comment faire pour que cela ne soit pas trop dur pour les disques qui resteront dans le pool ?

J'ai plusieurs stratégies:

1) J'enlève physiquement un disque de mon pool et je mets un nouveau. Je sais que le resilvering est sévère pour l'ensemble des disques du pool. Est ce à éviter ?

2) Je reformate tous les disques du pool et j'utilise le backup pour remettre les données. Est ce moins sévère pour les disques qu'un resilvering ?

3) je ne fais rien et je changerai un DD lorsque cela sera nécessaire

4) autres solutions ?

Le but est d'éviter de faire potentiellement faillir d'autres disques du pool.

Merci

[mtiburs]

Salut,

Je sais que le resilvering est sévère pour l'ensemble des disques du pool.

Je ne comprends pas tellement "cette certitude"
... c'est plus l'intégrité du pool qui est important que "l'ensemble des disques"

ZFS ne fait que des transactions de blocs.
Il a des objectifs (lire,écrire, "resilverer", ...) Tout ceci se fait par transaction, il récupère ce qu'il a besoin puis met en place les choses avec une "logique".
Certes, dans un environment très sollicité, pour éviter des usures prematurées de la mécanique des disques durs, il faut respecter des "montages propres" pour que le matériel s'use correctement.
Mais, hormis cet aspect, il n'y aucune importance, ZFS est un FS moderne et il s'adapte (il lui faut juste de la mémoire).
En gros, on peut faire les pires montages, mélanger des disques lents et rapides, faire un pool entrelacés avec un vieux disque IDE et un SSD, faire un miroir avec un disque dur et une clef USB, et autres joyeuseté, çà n'a aucune importance !, il fera ce qu'il faut avec ce qu'il a, tout simplement.

Si tu veux utliser ton pool pendant un resilvering, le soucis se situera sur les capacités de la machine que tu mets a disposition, c'est à dire que dans l'idéal il faut que le temps de resilvering soit le plus court possible (pour retrouver le niveau de fiabilité le plus haut).
C'est là que tombe tous les artifices qui permettent d'optimiser le fonctionnement de ZFS, je veux dire par là qu'on peut mettre un SSD en zcache pour accélérer les lectures (en fait diminuer les lectures sur le pool) et éventuellement un zlog (pour faire des écritures mieux "absorbées" par le pool), mais dans le cas d'un resilvering ou d'un scrub, le zcache et le zlog ne servent à rien, c'est le pool uniquement qui est en jeu.
Donc, c'est purement un aspect "matériel" qui sera important. C'est pour çà qu'un resilvering qui se fera sur un pool à base de SATA et pire encore en USB durera "une plombe" ou plus exactement "une durée critique gênante pendant l'opération". Quand on a des données importantes il faut "penser" au système lorsqu'il sera dans ce genre de phase (resilvering ou scrub).
Mais peut importe le type de dev, ce qui est important, c'est d'avoir des dev qui soit viable.
Pour moi, le plus important et de revenir à une situation optimale dans le niveau le plus élevé et dans le plus bref délai, on pourrait imaginer une chose du style:
niveau 3: scrub venant d'être terminée et tous les dev OK et de même type et de hautes performances (SAS)
niveau 2: scrub venant d'être terminée et tous les dev OK et de même type
niveau 1: scrub venant d'être terminée et tous les dev OK
niveau 0: pool en fonctionnement (çà semble marcher, on en sait pas plus)
niveau -1: dev en défaut mais avec une structure prête (comme le miroir)
niveau -2: dev en défaut mais avec une structure/action a mettre en place (action physique à faire)
niveau -3: dev en défaut mais avec une structure/action a mettre en place et avec des dev lents ou hétérogènes
Mais c'est un vision simpliste.
Car il faut metre par là-dessus une charge éventuelle et des risques potentiels (un resilvering depuis 2 jours à 97% avec une coupure de courant ... Yeesss ! )

Par expérience (la mienne, et, elle n'est pas forcément bonne car limitée), il faut retrouver le meilleur état de fonctionnement et au plus vite, ZFS pardonnera et fermera les yeux sur les dev qu'on lui donne, mais il lui faut un niveau de réplication de données suffisant.

Dans ton cas, il faudrait voir comment se passe un scrub (temps), ce que çà représente.
- si il est rapide, tu peux te permettre d'enlever un disque et de le remplacer par un autre (l'idéal serait un raidz2: un disque en panne et un disque pour "l'échange" volontaire".
C'est pour moi le plus tranquille

Il faut voir ta charge en cas de resilvering, avoir un SSD n'améliorera aucunement le resilvering mais allégera la lecture du pool, donc, laissera "la dispo système" pour le resilvering. Il faut bien voir là deux opérations avec des buts distincts et malheureusement, utiliser un système en charge avec une opération de resilvering sera dans la réalité un "tout".

A moins d'avoir une "charge immense", ne te focalise pas sur les dev de différents types, ZFS gère très bien la chose, il faut en priorité absolue avoir une niveau de réplication le plus élevé possible.

Je ne sais pas si j'ai vraiment répondu à ta question
... mais je donne le fond de ma pensée (Sleid aura peut-être une vision différente)

[mtiburs]

En gros, on peut faire les pires montages, mélanger des disques lents et rapides, faire un pool entrelacés avec un vieux disque IDE et un SSD, faire un miroir avec un disque dur et une clef USB, et autres joyeuseté, çà n'a aucune importance !, il fera ce qu'il faut avec ce qu'il a, tout simplement.

Quand j'écris çà, çà ne veut pas dire qu'il faut le faire, qu'il faut "négliger" le montage d'un pool matérielement.
Je dis juste que "techniquement" c'est possible (pour se dépanner par exemple).

[sleid]

4) autres solutions ?
Pour le RaidZ1

J'achète un boitier de réplication, j'arrête mon Nas, je fais une copie bit à bit de mon disque sur le nouveau disque dans le boitier de réplication, je place le nouveau disque dans le Nas et je le démarre.
Dans ce cas je n'ai fatigué que 2 disques non essentiels à la survie du pool.

Pour les raidS2 et 3

J'ai une sauvegarde donc j'utilise le resilvering.

Je n'ai pas de sauvegarde, je considère que ce n'est que du raidZ1 amélioré mais que 1 ou 2 disque peuvent encore lâcher donc voir RaidZ1 !!!!

Avec des disques qui vont atteindre sous peu les 10 To donc un resilvering long, la solution de la copie externe bit à bit va s"imposer, sauf pour les kamikazes.

[mtiburs]

Une idée "comme çà" !

Pour le raidz1
- Un tiroir extractible (avec dedans le nouveau disque)
- redémarrer le Nas avec une clé ou un Linux en Live-CD
- copier le disque bit à bit avec dd ou dfldd
- inverser les disques et redémarrer le Nas


Je vais tester "une idée" et je mettrai le résultat si ok

[sleid]

J'utilise un boitier autonome qui fait des clones de disques:
http://www.inateck.com/hdd-docking-stat ... iiiii.html

En 2 heures il clone un disque de 2 téra et supporte les disques jusquà 6 To.

[ernie]

Hello

Merci mtiburs et sleid

Je vais tester le changement de disques avec resilvering. Mon dernier scrub avait duré 3h30.

[mtiburs]

j'ai tester un truc ... et çà semble marcher

Toutefois, il faut que Sleid me confirme une chose:
Est-ce qu'un disque de remplacement qui serait à l'identique sauf les 100 premiers MO sera plus vite resilveré qu'un disque vierge ?
En gros, est-ce que ZFS va faire des passes sur des cheksum de blocs ou sur les blocs réels ?

[sleid]

Non tout est revérifié

[mtiburs]

Voilà, j'ai fais mon essai et çà marche !

L'idée est de "préparer" le disque de remplacement avant de faire le remplacement.

Mes essais sont:
- fait en Linux avec des fichiers dans un FS (le pool crée en ZfsOnLinux est compatible Nas4Free).
et,
- fallocate a été nécessaire pour créer mes futurs dev
- losetup pour transformer mes fichiers en dev

Je crée mes fichiers:
root@bx:~# fallocate -l 20G /mnt/test/testdisk1.dsk
root@bx:~# fallocate -l 20G /mnt/test/testdisk2.dsk
root@bx:~# fallocate -l 20G /mnt/test/testdisk3.dsk
root@bx:~# fallocate -l 20G /mnt/test/testdisk4.dsk
root@bx:~# fallocate -l 20G /mnt/test/testdiskR.dsk

Je crée mes dev:
root@bx:~# losetup /dev/loop1 /mnt/test/testdisk1.dsk
root@bx:~# losetup /dev/loop2 /mnt/test/testdisk2.dsk
root@bx:~# losetup /dev/loop3 /mnt/test/testdisk3.dsk
root@bx:~# losetup /dev/loop4 /mnt/test/testdisk4.dsk
root@bx:~# losetup /dev/loop0 /mnt/test/testdiskR.dsk

Je crée mon pool:
root@bx:~# zpool create monpool raidz1 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4

On regarde si tout est ok:
root@bx:~# zpool iostat -v
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
monpool 114K 79,5G 0 11 0 10,4K
raidz1 114K 79,5G 0 11 0 10,4K
loop1 - - 0 8 2,67K 169K
loop2 - - 0 8 2,67K 169K
loop3 - - 0 8 2,67K 168K
loop4 - - 0 7 2,67K 168K
---------- ----- ----- ----- ----- ----- -----

On copie des données:
root@bx:~# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
monpool 79,5G 52,0G 27,5G - 36% 65% 1.00x ONLINE -

Cette fois c'est prêt !


On copie "bit à bit" le contenu du disque à remplacer sur celui de remplacement:
dcfldd if=/mnt/test/testdisk1.dsk of=/mnt/test/testdiskR.dsk

Très important !
Il faut cacher à ZFS que c'est une partie de son propre pool:
dcfldd if=/dev/zero of=/dev/loop0 bs=1M count=100
/dev/loop0 étant /mnt/test/testdiskR.dsk on peut aussi écrire:
dcfldd if=/dev/zero of=/mnt/test/testdiskR.dsk bs=1M count=100

On remplace le disque et on regarde:
root@bx:~# zpool status -v
pool: monpool
state: ONLINE
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 Sun Aug 21 17:49:52 2016
51,9G scanned out of 52,0G at 280M/s, 0h0m to go
13,0G resilvered, 99,79% done
config:
NAME STATE READ WRITE CKSUM
monpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
replacing-0 ONLINE 0 0 0
loop1 ONLINE 0 0 0
loop0 ONLINE 0 0 0 (resilvering)
loop2 ONLINE 0 0 0
loop3 ONLINE 0 0 0
loop4 ONLINE 0 0 0
errors: No known data errors
On constate que la vitesse est de presque 300Mo/s

Une fois le resilvering fait
root@bx:~# zpool status -v
pool: monpool
state: ONLINE
scan: resilvered 13,0G in 0h3m with 0 errors on Sun Aug 21 17:53:03 2016
config:
NAME STATE READ WRITE CKSUM
monpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
loop0 ONLINE 0 0 0
loop2 ONLINE 0 0 0
loop3 ONLINE 0 0 0
loop4 ONLINE 0 0 0
errors: No known data errors
On voit qu'il aura fallut 3min pour le faire


Cette fois, on va faire un disque qu'avec des zéros (un disque vierge):
dcfldd if=/dev/zero of=/dev/loop1

On met le disque en place:
zpool replace monpool /dev/loop2 /dev/loop1

root@bx:~# zpool status -v
pool: monpool
state: ONLINE
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 Sun Aug 21 17:55:19 2016
290M scanned out of 52,0G at 48,3M/s, 0h18m to go
71,1M resilvered, 0,54% done
config:
NAME STATE READ WRITE CKSUM
monpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
loop0 ONLINE 0 0 0
replacing-1 ONLINE 0 0 0
loop2 ONLINE 0 0 0
loop1 ONLINE 0 0 0 (resilvering)
loop3 ONLINE 0 0 0
loop4 ONLINE 0 0 0
errors: No known data errors
On voit que la vitesse est inférieure à 50Mo/s et qu'il faudra 18min pour le faire

root@bx:~# zpool status -v
pool: monpool
state: ONLINE
scan: resilvered 13,0G in 0h10m with 0 errors on Sun Aug 21 18:06:08 2016
config:
NAME STATE READ WRITE CKSUM
monpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
loop0 ONLINE 0 0 0
loop1 ONLINE 0 0 0
loop3 ONLINE 0 0 0
loop4 ONLINE 0 0 0
errors: No known data errors
En fait, il aura fallut 10min pour faire le resilvering

Voilà
On peut donc pour aller plus vite, copier le disque à partir d'un dev "à chaud" (c'est en lecture donc pas de soucis)
Sur un resilvering de 2 jours ... çà peut valoir le coup

[mtiburs]

Je n'avais pas vu ta réponse Sleid
... il semblerait qu'on puisse gagner un peu de temps