*New 12.1 series Release:
2019-11-08: XigmaNAS 12.1.0.4.7091 - released!

*New 11.3 series Release:
2019-10-19: XigmaNAS 11.3.0.4.7014 - released


We really need "Your" help on XigmaNAS https://translations.launchpad.net/xigmanas translations. Please help today!

Producing and hosting XigmaNAS costs money. Please consider donating for our project so that we can continue to offer you the best.
We need your support! eg: PAYPAL

Retour d expérience disque dur 8 - 14 To ?

French community

Moderators: mtiburs, velivole18, ernie

Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Retour d expérience disque dur 8 - 14 To ?

#1

Post by ernie » 12 Jul 2019 15:54

Bonjour

J aimerais savoir si parmi vous certains avaient déjà des disques de 8 à 14 To sous xigmanas.

Vos retours d expériences m intéressent devant investir dans des disques de plus grandes capacités (pool occupé à plus de 80% proche 90%).

Quelle marque et quelle type de pool (mirror, raidz1,...), disque bruyant ou silencieux (même si cela reste subjectif), sata ou sas ...?

De mon côté j ai identifié seagate et WD mais ils ont pas mal de références pour une même taille.

Merci par avance de vos retours
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#2

Post by ernie » 26 Aug 2019 17:15

Bonjour à tous
Une petite relance sur le sujet en ce temps de rentrée professionnelle, ou pour les chanceux, de dernières semaines de vacances
Merci par avance
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

sleid
PowerUser
PowerUser
Posts: 759
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#3

Post by sleid » 27 Aug 2019 16:57

Personnellement je me limite au 4T red de wd c'est le moins couteux au To et j'en ai qui ont maintenant 4 ans sans aucun souci.

https://www.alternate.fr/WD/Digital-Red ... ct/1098412?
12.1.0.4 - Ingva (revision 7091)
FreeBSD 12.1-RELEASE #0 r354387M: Wed Nov 6 15:18:53 CET 2019
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 x WDC WD40EFRX + 3 x WDC WD30EZRX

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#4

Post by ernie » 27 Aug 2019 18:44

Merci Sleid

Je vais voir car j hésites entre le 4To et le 6 To.
L’hesitation vient du constat suivant : 5 ans de données clés occupent 80% d’un raid z2 avec 4 disques de 2 To.
Donc un passage à des disques de 4 To me donne 5 ans de plus, 6 To 10 ans...

Est ce que tes disques de 4 To sont bruyants ?
Mes 2 To de WD sont très silencieux

Encore merci
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

sleid
PowerUser
PowerUser
Posts: 759
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#5

Post by sleid » 27 Aug 2019 19:13

Non ils ne sont pas bruyant du tout.
12.1.0.4 - Ingva (revision 7091)
FreeBSD 12.1-RELEASE #0 r354387M: Wed Nov 6 15:18:53 CET 2019
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 x WDC WD40EFRX + 3 x WDC WD30EZRX

sleid
PowerUser
PowerUser
Posts: 759
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#6

Post by sleid » 27 Aug 2019 19:15

D'autre part je pense que dans 5 ans ce seront des SSD car les prix baissent très vite.
12.1.0.4 - Ingva (revision 7091)
FreeBSD 12.1-RELEASE #0 r354387M: Wed Nov 6 15:18:53 CET 2019
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 x WDC WD40EFRX + 3 x WDC WD30EZRX

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#7

Post by ernie » 28 Aug 2019 18:55

Je me posse une autre question:
Ne vaut il pas mieux rajouter 4 disques de 2 To pour faire un raidz2 avec 8 disques
Cela donne un stockage de 8-10 To

Ou vaut mieux que 4 disques car moins de risque de panne que 8 disques ?
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

sleid
PowerUser
PowerUser
Posts: 759
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#8

Post by sleid » 29 Aug 2019 07:20

Personnellement je préfère avoir plusieurs vdev dans un pool, cela permet d'avoir moins de disques à changer pour augmenter la taille du pool et l'on augmente légèrement la tolérance de panne mais on augmente statistiquement le risque d'avoir un disque en panne
12.1.0.4 - Ingva (revision 7091)
FreeBSD 12.1-RELEASE #0 r354387M: Wed Nov 6 15:18:53 CET 2019
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 x WDC WD40EFRX + 3 x WDC WD30EZRX

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#9

Post by ernie » 29 Aug 2019 20:12

sleid wrote:
29 Aug 2019 07:20
Personnellement je préfère avoir plusieurs vdev dans un pool, cela permet d'avoir moins de disques à changer pour augmenter la taille du pool et l'on augmente légèrement la tolérance de panne mais on augmente statistiquement le risque d'avoir un disque en panne
Merci Sleid et très clair

Autre subtilité qui me questionne:
Mon pool contient un vdev constitué de 4 disques de 2 To en raidz2
Vaut il mieux rajouter un vdev avec des disques de 2To ou peut importe la taille des disques du 2ème vdev car il y a une « independence » vis a vis du hardware du premier vdev ?
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

sleid
PowerUser
PowerUser
Posts: 759
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#10

Post by sleid » 29 Aug 2019 20:59

Ma signature montre que j'ai un vdev avec des 3T et un autre avec des 4T avant c'était des 2T avec 3T petit à petit j'ai augmenté la taille.
Quand les 2T ont commencé à vieillir (smart) je les ai remplacé au fur à mesure par des 3T avec autoexpand=on.
Pour l'instant j'ai des 3T Green qui ont entre 5 et 7 ans et des 4T Red qui ont entre 3 et 5 ans.
Les vdev sont indépendants, c'est le pool qui "stripe" sur les vdev, rien n'empêcherai d'avoir un vdev en RzaidZ1 et un autre en RaidZ2.
L'importance c'est la cohérence dans le vdev pas au niveau de la capacité des devices mais du type on peut mais on ne doit pas mélanger les types disque,partition,fichiers, cela peut causer des erreurs d'écriture.
ZFS est souple mais quand même!!
12.1.0.4 - Ingva (revision 7091)
FreeBSD 12.1-RELEASE #0 r354387M: Wed Nov 6 15:18:53 CET 2019
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 x WDC WD40EFRX + 3 x WDC WD30EZRX

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#11

Post by ernie » 30 Aug 2019 07:23

Merci Sleid
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#12

Post by CorbeilleNews » 01 Oct 2019 23:13

Pour info évites les disques à écriture perpendiculaire car au début cela ne pose pas de soucis mais plus tu les rempliras plus ce sera long après chaque écriture de fichier car il faut réécrire les couches inférieures et ou supérieures

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#13

Post by mtiburs » 02 Oct 2019 04:09

CorbeilleNews wrote:
01 Oct 2019 23:13
Pour info évites les disques à écriture perpendiculaire car au début cela ne pose pas de soucis mais plus tu les rempliras plus ce sera long après chaque écriture de fichier car il faut réécrire les couches inférieures et ou supérieures
Je pense que ce ralentissement peut être évité en utilisant un Zlog: cache en écriture (deux disques en miroirs tous petits), de cette façon le pool se fera à son rythme, sauf si le brassage de données en écritures est vraiment trop important.
à confirmer par sleid :ugeek:
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#14

Post by CorbeilleNews » 02 Oct 2019 18:06

En effet car usure du ssd prématurée tu risqueras

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#15

Post by mtiburs » 02 Oct 2019 18:15

CorbeilleNews wrote:
02 Oct 2019 18:06
En effet car usure du ssd prématurée tu risqueras
Je ne vois pas le rapport avec le SSD :roll:

Peux-tu développer ton raisonnement de l'usure du SSD (on n'en a pas parlé) et l'écriture perpendiculaire ?
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#16

Post by CorbeilleNews » 02 Oct 2019 18:26

Si le SSD fait tampon trop souvent et sur des grosses quantité de données il risque de s'user prématurément

L'écriture perpendiculaire ralenti l'écriture sur le disque car si l'on veut écrire à un endroit ou les autres étages ne sont pas encore écris cela ne pose pas de pb donc débit normal.

Par contre, quand il y a déjà des choses écrites sur les autres couches, il faut réécrire toutes les couches se trouvant à cet endroit et ca cela ralenti pas mal le débit du/des disques.

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#17

Post by mtiburs » 02 Oct 2019 19:10

oui mais on n'a pas forcément besoin d'un SSD pour "épauler" un disque perpendiculaire, y'à d'autres solutions !

deux disques SAS de 36Go (5e pièces en général) çà marche très bien: 15000 tours/mn et c'est largement suffisant (le but est d'avoir un bon temps d'accès, le débit on s'en fout)
le SAS est méconnu des gens mais c'est pourtant le must coté performances et optimisation (car les données transitent directement vers le processeur, et les commandes sont de 64 en même temps ... pour une en SATA !) ... pas le même monde 8-)
Bon d'accord, il faut une carte SAS (car c'est elle qui va gérer les I/O et les 64 commandes simultanées), mais on peut en trouver à 15 ou 20e et des très bonnes en SAS2 pour 50 à 100e.
Moi, un coup j'ai acheté des cartes perc6/IR avec 256Mo/cache interne pour 20e pièces, sur des vieilles cartes mères c'est 465Mo/s d'assuré ! çà passe par le bus PCI express par contre (donc quand on veut garder sa carte vidéo ... il faut plusieurs PCI express), et avec une carte SAS2/1Go de cache interne à 100e d'occase (800e neuve), je suis déjà monté à 3200Mo/s ... mais en vrai, c'est à dire que je peux écrire un fichiers de 500Go ou plus avec ce débit, çà tarbeule :mrgreen:

Alors le SSD, c'est bien mais oui çà s'use.
Moi, je ne l'utilise que sur des machines en Zcache et qui tournent 24/24 sans trop de débit, je privilégie le SAS le plus possible
Je ne mets que le Zcache qu'en metadata (zpool set secondarycache=metadata monpool)
C'est en fonction des données qui "passent" aussi, il faut toujours adapter son système par rapport à ce qu'on en fait
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#18

Post by mtiburs » 02 Oct 2019 19:16

il faut surtout regarder attentivement son zpool iostat -v
car "on voit" ce que ZFS fait, et privilégie ce qui lui convient le mieux
Au début, je voulais faire des montages poussés, et je me suis aperçu que çà servait souvent à rien ou pas grand chose (à par chauffer la pièce), donc, aujourd'hui je monte d'abord simple, et ensuite, j'optimise si nécessaire.
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#19

Post by CorbeilleNews » 02 Oct 2019 19:20

Tiens nous informé quand tu auras terminé ton projet en signature, cela m'intéresse :p

Le Xigmanas existe en Pi ? Ou c'est que NAS4Free ?

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#20

Post by mtiburs » 02 Oct 2019 20:08

Mon système est fonctionnel et est adopté définitivement.

je vais préparer un petit texte pour en parler ;)
Mais c'est quelque chose qui est personnel avant tout, çà n'a rien d'officiel et j'en parlerai juste dans le cas oû certaines personnes peuvent être intéressé.

Ce n'est pas quelque chose de facile à conceptualiser, même moi je m'y perds des fois tellement c'est "tordu" :mrgreen:
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#21

Post by CorbeilleNews » 02 Oct 2019 20:22

mtiburs wrote:
02 Oct 2019 20:08
Ce n'est pas quelque chose de facile à conceptualiser, même moi je m'y perds des fois tellement c'est "tordu" :mrgreen:
C'est que tu as du penser presque à tout avec les bons compromis, et c'est justement ce que je recherche

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#22

Post by mtiburs » 11 Oct 2019 05:10

CorbeilleNews wrote:
02 Oct 2019 20:22
C'est que tu as du penser presque à tout avec les bons compromis, et c'est justement ce que je recherche
:mrgreen: tu vas pas être déçu ... mais surtout te sauver en courant les bras "au ciel" :lol:


mon projet en signature fonctionne actuellement.
j'hésitais à en parler car la conception de ZFS peut sembler souvent complexe, et mon "bazar" ... c'est pire ! :lol:
C'est un projet personnel ... je partage juste mes infos.

Pourquoi et comment j'ai fais ce système ?
Et bien parce que je suis étourdi et que je fais des conneries (par exemple je tape zpool add nas1 /dev/ada5 au lieu de zpool add nas1 cache /dev/ada5, et çà, çà pardonne pas car je me retrouve alors avec mon dev de cache en entrelacement avec le pool).
L'idée première qui me venait dans ces moments là, était "Ahhh si je pouvais remettre comme c'était avant".
Donc, le but est de me protéger de moi-même en plus de tout le reste qui arrive classiquement: un disque qui claque, ...
De plus, en cas de pb de mémoire ECC ou autre, je ne veux pas d'un pool qui soit bloqué ou avoir une situation nouvelle qui ne me convienne pas.

En plus de celà:
- je veux une fiabilité à toute épreuve (je ne cherche pas la haute-dispo, mais un stockage totalement "infaillible" ... rien que çà !)
Une modularité: pouvoir utiliser les données par une machine légère (grand public) ou par un serveur pro (avec mémoire ECC)
si possible: ne pas pouvoir altérer les données par la machine légère (que l'intégrité du pool soit garantie même en cas de pb de mémoire)
- je veux que le système soit scindé (cas d'incendie)
- si possible sans sauvegarde
- optimisable en vitesse et performant
- le moins cher possible
- malléable dans le temps (pouvoir accéder "au passé" sans arrêter ou altérer le stockage existant)
- pouvoir avoir une grosse taille sans "effondrer" le système (pour ce coté là, çà me désole d'avoir un gros pool avec des données qui ne servent jamais, et qui alourdisse un scrub et la gestion du pool, pour pallier à çà il faut une grosse machine, et je veux utiliser du matos "léger".

J'ai réussis tout çà, mais en plus
il est:
- regénérable (de quelques % à 100% ou plus), c'est à dire qu'on peut reformater, remplir de zéro totalement le pool ou les disques du pool , ou mettre carrément un autre FS, partitionner différemment, et, en une seconde, l'ancien FS se remet en place ... comme avant.
- utilisable dans des temps différents (faire marcher le pool en même temps qu'une ou des versions de ce même pool à des époques différentes).
- possibilté de réduire la taille du pool (pour cela, il faut le prévoir à l'avance)
- réparable "hors conscience" du FS (le FS ou pool principal peut fonctionner sans maintenance, alors qu'un dev est en cours de maintenance)

çà fait en gros une décennie que je cherchais à faire ce genre de chose, et j'ai mis un an pour le mettre en service.

Comment çà marche ?
Si on considère ZFS comme une étoile, dans mon cas, ZFS se situera non pas au centre de tout, mais au bout de chaque branches (il existera toujours d'une manière normale au centre si on utilise ZFS, mais çà peut être un autre FS (je préfère toutefois ZFS: j'appelerai ce dernier à l'avenir "pool principal" ou pool "classique")
Toute la puissance et la sécurité de ZFS est mise à profit pour des sortes de "pseudo-device", j'appelle çà des SDA (Super-Devices-Autonomes). "Super" car ce n'est pas un device "passif" géré par un FS, mais un device "actif" car il peut reprendre des états voulus et servir plusieurs serveurs en même temps.

Mon système "laboratoire" (qui est en production désormais) est basé actuellement sur des RPI2b (15e d'occase) avec NAS4Free 10.3.
Le débit étant complètement pourri, j'ai multiplié ces derniers (le nbr de branches) pour avoir un débit acceptable.
Il y en a donc 11 et le pool qui va gérer çà est en raidz3 (donc 8 d'utilisables en capacité), pour info: un RPI2b à la base (pool classique) c'est 3,5 Mo/s en écriture et un peu plus de 10Mo/s en lecture (wow ! ... lol ... de la performance "gastéropodienne" :lol: )
Avec mon système, en raidz3 sur un serveur normal avec mes branches constituées de rpi, j'arrive à un scrub à presque 40Mo/s et 70 à 120 Mo/s en lecture pour les données (mais ceci d'une bonne façon, c'est à dire que çà "tracte" toujours, car le pool ne gère plus les données sur des dev physiques mais des dev un peu "idéaux". Ces derniers (SDA) sont en NFS.
Au départ, je voulais utiliser l'iscsi mais c'est trop lourd à l'usage, j'ai abandonné.

Le principe est le suivant:
- Le RPI n'est pas accessible par l'admin (il est autonome et je ne me connecte pas dessus par le réseau). Pour expliquer le principe, il faut imaginer le pool principal comme une salle au centre d'une prison, et chaque SDA se trouve à l'intérieur d'une cellule fermée à double tour (c'est là, là le principe de la sécurité de ce système). Donc pour y accéder, il faut faire une intervention séparée sur chaque RPI.
- Le RPI possède un pool ou plusieurs et des datasets sont crées, un fichier (conçu par dd) est mis en place dans chaque datasets, le fichier est partagé en NFS.
- le serveur va se connecter à chaque RPI, et chaque fichier est installé dans des montages dédiés, mais, grâce à un lien symbolique, tout ce petit monde 'finit dans un répertoire unique (sur le serveur) qui contient donc des fichiers qui vont représenter chaque dev du pool (en gros c'est comme si on utilisait ZFS sous forme de fichiers, sauf que les fichiers sont en NFS)
- le pool principal va utiliser ces fichiers NFS (on peut toutefois optimiser les choses avec du cache ou du log, mais çà marche tellement bien que je laisse le pool sans rien)
- pour ma part, je triche un peu coté serveur, car je monte les SDA avec l'option "fsc" (cache en lecture) de mount ... autant en profiter !

ZFS se trouvant au niveau de chaque SDA, et, par son extraordinaire fonctionnalité de snapshot, il permet donc de retrouver une situation précise pour chaque SDA.

Pour des raisons de facilité, j'ai des scripts qui me permettent des faire certaines opérations (je veux çà pour ne pas me tromper dans mes manœuvres en tapant des commandes risquées).
Par exemple, je peux lister (zfs list), lister les snapshots des SDA, faire des snapshot des SDA, ... par l'intermédiaire de scripts.

Le principe est le suivant:
(cas d'un pool de 80Go)
- je crée un fichier de 10Go sur chaque SDA
- je crée mes partages en NFS (webgui de NAS4Free)
- je monte les 11 fichiers des SDA en NFS sur le serveur (mount -t nfs ...)
- je crée un pool principal sur mon serveur en raidz3
à ce niveau:
- je scrub et j'exporte le pool principal
- je démonte les partages NFS (script sur le serveur)
- je lance un script qui fait un snapshot sur chaque SDA (avec le même nom: en fait "@date_et_heure")
et à partir de ce moment, rien ne pourra altérer mon pool tout neuf, il est figé.
après:
- je remonte mon NFS
- j'importe mon pool (zpool import -d /repcommun monpool)
je rajoute des fichiers, et je fais vivre mon pool
ensuite, quand j'en ai envie (mais comme je suis parano: donc à chaque fois ;-)
- je scrub et j'exporte le pool
- je snapshot sur chaque SDA (par le script)
et cette fois, j'ai deux versions d'un même pool et ceci sans prendre beaucoup de place (car c'est seulement les blocs modifiés sur les SDA qui sont pris en compte).

Imaginons la chose suivante:
je me reconnecte depuis le serveur en montant mes dev en NFS
je peux formater ou effacer la totalité de mes dev par des zéros (en fait, je n'altère que le pool courant)
et bien ce formatage, ne posera en fait aucun pb !
car
- je me déconnecte
- fais un rollback sur chaque SDA
- je me reconnecte
- j'importe mon pool et je retrouve tout ce qu'il y avait avant le formatage !

Mais on peut aller plus loin !
- sur chaque SDA, je fais un clone (çà crée une copie de pool ZFS à partir d'un snapshot)
J'ai un partage NFS fantôme de disponible sur chaque SDA (sorte d’aiguillage par "lien")
- je monte les SDA en NFS
- et je peux importer le pool normal + la copie du pool cloné (et faire un rsync par exemple avec l'option backup pour générer les différences dans un répertoire)

Mais on peut faire encore mieux !
- sur chaque SDA, je fais un ZFS promote (çà crée un pool ZFS complet et totalement utilisable à partie d'un clone)
- je monte les SDA en NFS (le normal + le partage fantôme en faisant quand même un reguid du pool car on ne peut pas monter deux fois le même pool ayant le même id)
- et je peux importer le pool normal + le pool ancien (par exemple le premier que j'ai fais quand il était vide)
De cette manière, si je fais un snapshot de fichier à 10Go, et qu'ensuite je suis monté à 20 puis 30 (par des autoexpand sur le pool principal), je peux remonter la version à 10Go, faire du tri et ensuite valider ce pool "ancien remis à jour" (çà aura réduit indirectement sa taille)
Là, j'en conviens ... faut vraiment avoir toute sa tête, car c'est pas du tout évident, mais çà marche.

Pour ne pas avoir de gros pools lourds à gérer, je découpe tous en morceaux
Et je ne monte que ce que j'ai envie, du coup le scrub et rapide.
Je peux monter aussi plusieurs pools en même temps (attention toutefois à la limitation des serveurs NFS déclarés)
Je peux aussi monter un pool sur un serveur 1 et un autre pool sur un serveur 2 (sur les même SDA physiquement). Dans ce cas, les serveurs sont multiples mais le système de stockage reste unique)
un SDA peut contenir des entités qui sont en ZFS sur le serveur + BTRFS + ext4 et même du bcache en sous-FS (on peut avoir un pool principal en raidz2, un autre en raidz3 et un pool en BTRFS, les trois pouvant fonctionner en même temps)

Un SDA peut se gérer ou travailler d'une manière totalement autonome (mirroir ou autre)
On peut faire un scrub dessus pendant que le pool principal "tourne", le pool principal ne le sait pas.
Pour augmenter la taille, il suffit:
- de mettre un disque en miroir, et une fois le resilvering ok
- de spliter, puis enlever l'ancien disque
Le pool principal ne verra rien, il n'en est pas "conscient".

Le fonctionnement est très bon au niveau vélocité, et j'utilise désormais directement mes mv depuis le serveur.
Le gros avantages, c'est que je peux faire pleins de petits espaces de stockages, du coup j'en fais un pour chaque mv.

C'est extrêmement solide.
Pas besoin de sauvegarde, car on peut toujours tout retrouver (si une version du pool principal ne fonctionne pas, celle n-1 fonctionnera)
Toutefois, par principe, je fais aussi des snapshots sur le pool principal, car c'est un contexte de données "unique", alors que pour les SDA, il y a 11 parties totalement différentes (c'est là que les choses peuvent sembler "complexes" sur ce système, car une perte totale d'un SDA engage la perte des snapshots attenant aux SDA, en gros, le pool principal pourra reconstruire le pool courant (donc le pool courant du SDA) mais pas les snapshots du SDA, car ces dernièrs n'ont aucun rapport avec le pool principal. Ceci étant, si il existe des snapshots du pool principal, il sera alors possible de reconstruire autant de versions sur le SDA que de snapshots du pool principal; c'est pour cela que je fais systématiquement un snapshot sur chaque SDA et un sur le pool principal, car de cette façon, toutes versions du SDA est potentiellement reconstructibles)

Coté taille, avec mes RPI2b, je peux monter 4 disques de 2 To, soit 8 To et çà donne 64 To max (8 x 8To + 3 disques perdu par le raidz3)
En utilisant des petites cartes mères avec des ports usb on monter très très haut en taille.

Pour moi, c'est un peu le Graal.
Ce n'est pas toujours facile à appréhender, mais je sais que mes données sont là et seront toujours accessible.

Dans quelques temps, je vais mettre en place un concept encore plus poussé ... les SDA deviendront des HDA, c'est à dire qu'un HDA sera un SDA + copie d'un autre SDA.
Si on coupe les disques en deux groupes, le HDA 1 (Hyper-Device-Autonome) contiendra l'équivalent du SDA 1 (grp1) + une copie du SDA 6 (grp2)
Le but est que ce système soit délocalisé en deux endroits différents, et qu'une partie puisse fonctionner totalement sans l'autre (HS/volée/carbonisée) tout en bénéficiant toujours des fonctionnalités "raidz".
Une autre possibilité (la moins cher et ne bouffe pas de ports usb sur les SDA, c'est de faire une sauvegarde "verticale" (c'est à dire un serveur qui contient une copie de tous les SDA (une seule machine avec du volume, le but étant de compenser rapidement un SDA HS).

On peut aussi basculer ce système de "réseau" en "local", sur mon bi-xéon qui me sert de serveur (pool principal), j'ai 11 disques SAS de 300Go disponible et je peux basculer un pool de mon système sur le serveur local, pour celà, il faut faire des zpool replace.
Et on peut aussi basculer un pool "local" en "réseau".

L'avantage du NFS, c'est qu'on peut "jouer avec" ... sans rien décâbler.

Pour avoir de la vitesse:
- le SDA peut être Zcaché (j'ai des rpi de modèles différents (v1.1 ou 1.2)et des disques différents, et donc des vélocités non-identiques entre chaques SDA, je compense donc les plus faibles)
- le pool principal peut avoir un très gros Zcache, soit en SAS (secondarycache=all) ou en SSD (secondarycache=metadata pour éviter l'usure de ce dernier)

Je testerai un mode 'turbo" (vitesse de lecture égale au performance "SSD" sur une partie ou la totalité du pool, sans utiliser de Zcache), mais c’est à tester complètement, je n'ai pas encore d'expérience sur ce type de montage.

Voilà en gros.
Ce n'est pas du tout évident comme "structure", car il faut bien connaître son FS (ZFS ou non), et, l'imbriquer dans une "sous-couche ZFS" au sein de chaque device et ceci au travers de NFS.
Mais, pour ma part, je ne pourrais plus m'en passer.
Les SDA peuvent être "mixtes" (du DD pour un type de données, et du SSD pour un autre type), ils peuvent être maintenus et modifier sans que le pool principal le sache.
(mes 11 rpi consomme 11 watts pour le tout, et les disques peuvent s'arrêter totalement), c'est accessible 24h/24h)

Si besoin, je peux faire des schémas de tout ceci ... car je reconnais que ce n'est pas évident.
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#23

Post by ernie » 11 Oct 2019 08:28

Wow !!!!
Bravo
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#24

Post by CorbeilleNews » 11 Oct 2019 08:43

Merci pour ces explications,

Comme tu le propose, je veux bien un petit schéma même fait à la main tant que c'est lisible et compréhensible 😀

Comment connecte tu tes disques aux raspberry Pi car ils n'ont pas de port SATA

Quel OS tourne sur les Pi ?

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#25

Post by mtiburs » 11 Oct 2019 13:38

CorbeilleNews wrote:Comment connecte tu tes disques aux raspberry Pi car ils n'ont pas de port SATA
Les disques sont branchés en USB (4 ports) ... c'est pas terrible pour un RPI, mais sur 11 en raidz3, çà marche bien.

CorbeilleNews wrote:Quel OS tourne sur les Pi ?
Je l'avais indiqué: Mon système "laboratoire" (qui est en production désormais) est basé actuellement sur des RPI2b (15e d'occase) avec NAS4Free 10.3.

C'est sur que des rpi4 seraient mieux (port rj en 1000) et "vrai" usb, mais comme xigmanas n'est pas porté dessus, il faudrait utiliser Linux genre: ubuntu-server_18.04 et jouer avec l'export NFS.
Le tout est de savoir si on peut installer ZFS dessus, il me semble que non.
Il y a aussi l'orange PI (vraiment peu cher) ou bananaPi.


Je vais étudier comment mettre çà sur des croquis, mais pas dans l'heure qui suis 8-)
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

CorbeilleNews
Advanced User
Advanced User
Posts: 256
Joined: 04 Jul 2012 20:40
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#26

Post by CorbeilleNews » 11 Oct 2019 17:05

Pourquoi NAS4Free sur les Pi et pas Xigmanas ?

En fait il y avait une explication sur le forum mais le lien et les sources des iso semblent ne plus fonctionner, on sait pourquoi ?

Merci

User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 937
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#27

Post by mtiburs » 11 Oct 2019 19:24

CorbeilleNews wrote:
11 Oct 2019 17:05
Pourquoi NAS4Free sur les Pi et pas Xigmanas ?
Nas4Free a été porté pour le rpi 1 et 2, mais le 3 n'a jamais été fait (ni le 4)
C'est dommage car le 3 et surtout le 4 sont suffisamment performant pour faire un bon petit nas (sachant que le 2 fonctionne déjà bien, lentement mais çà marche)

Le pi4 est vraiment top, j'en ai acheté un en version 4Go, çà tourne super bien (démarrage rapide et utilisation correcte en linux)
Ahhh , si seulement, les développeurs avaient cette "tentation" de mettre xigmanas dessus ;)
Serveur Intel bi-Xéon P5530 / 6 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / 21 x Nas4Free-PI-ARM / 1 X Xigmanas :o
Développement d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en iscsi ou NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h)

User avatar
ernie
Forum Moderator
Forum Moderator
Posts: 1418
Joined: 26 Aug 2012 19:09
Location: France - Val d'Oise
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#28

Post by ernie » 11 Oct 2019 19:55

Hello
Il existe une pseudo version de xigmanas pour Pi3.
Voir une version bêta
viewtopic.php?f=17&t=14379#p89428
Le post explique ce qu il manque mais cela semble marcher (non testé de mon côté )
Si besoin on peut faite une demande si c est envisagé de finaliser pour le pi3 voir faire la version pour le pi4
Bon weekend
NAS 1&2:
System: GA-6LXGH(BIOS: R01 04/30/2014) / 16 Go ECC
XigmaNAS 12.0.0.4.6766 embedded
NAS1: Xeon E3 1241@3.5GHz, 4HDD@2To/raidz2 (WD red), 3HDD@300Go/sas/raidz1 (Hitachi), 1SSD cache, Zlog on sas mirror
NAS2: G3220@3GHz, 3HDD@2To/raidz1 (Seagate), 1SSD cache, 1HDD@300Go/UFS
UPS: APC Back-UPS RS 900G
Case : Fractal Design XL R2

Extensions & services:
NAS1: OBI (Plex, extendedGUI, BTSync, zrep, rclone), nfs, UPS,
NAS2: OBI (extendedGUI, zrep (backup mode))

sleid
PowerUser
PowerUser
Posts: 759
Joined: 23 Jun 2012 07:36
Location: FRANCE LIMOUSIN CORREZE
Status: Offline

Re: Retour d expérience disque dur 8 - 14 To ?

#29

Post by sleid » 11 Oct 2019 21:32

Normal, les versions de freebsd 12 et 13 sont les seules à êtres portées sur les RPI3 pour les RPI4 il faudra encore attendre.
12.1.0.4 - Ingva (revision 7091)
FreeBSD 12.1-RELEASE #0 r354387M: Wed Nov 6 15:18:53 CET 2019
X64-embedded sur Intel(R) Atom(TM) CPU C2750 @ 2.40GHz Boot UEFI
ASRock C2750D4I 2 X 8GB DDR3 ECC
Pool of 2 vdev Raidz1: 3 x WDC WD40EFRX + 3 x WDC WD30EZRX

Post Reply

Return to “Français”