Aller au contenu

mprinfo

Messages recommandés

HARD DISK,

Raid Logiciel, Raid Matériel, SHR, RaidZFS

 

:13: By Lazer, Kiwi et  wikipedia.org :13:

 

Pour les discussions sur DSM, Xpenology, Synology, etc,

je préfèrerais que vous utilisiez le topic dédié avec le tuto de Fredo

 

 

=> Nas Synology Dsm 5 Sur Serveur Hp N54L + Vmware Esxi 5.5

 

Introduction :

 

https://fr.wikipedia.org

 

En informatique, le mot RAID désigne les techniques permettant de répartir des données sur plusieurs disques durs afin d'améliorer soit les performances, soit la sécurité ou la tolérance aux pannes de l'ensemble du ou des systèmes.


L'acronyme RAID a été défini en 1987 par l'Université de Berkeley, dans un article nommé A Case for Redundant Arrays of Inexpensive Disks (RAID)1, soit « regroupement redondant de disques peu onéreux ». Aujourd'hui, le mot est devenu l'acronyme de Redundant Array of Independent Disks, ce qui signifie « regroupement redondant de disques indépendants ». Le coà»t au mégaoctet des disques durs ayant diminué d'un facteur 1 300 000 en 29 ans, aujourd'hui le RAID est choisi pour d'autres raisons que le coà»t de l'espace de stockage.

 

Les différents types de systèmes RAID

 

https://fr.wikipedia.org


Le système RAID est :

    soit un système de redondance qui donne au stockage des données une certaine tolérance aux pannes matérielles (ex : RAID1).
    soit un système de répartition qui améliore ses performances (ex : RAID0).
    soit les deux à  la fois, mais avec une moins bonne efficacité (ex : RAID5).

Le système RAID est donc capable de gérer d'une manière ou d'une autre la répartition et la cohérence de ces données. Ce système de contrôle peut être purement logiciel ou utiliser un matériel dédié.


Le RAID logiciel

En RAID logiciel, le contrôle du RAID est intégralement assuré par une couche logicielle du système d'exploitation. Cette couche s'intercale entre la couche d'abstraction matérielle (pilote) et la couche du système de fichiers.

 

Avantages


C'est la méthode la moins onéreuse puisqu'elle ne demande aucun matériel supplémentaire.
Cette méthode possède une grande souplesse d'administration (logiciel).
Cette méthode présente l'avantage de la compatibilité entre toutes les machines équipées du même logiciel de RAID (c’est-à -dire du même système d'exploitation)


Inconvénients


L'inconvénient majeur réside dans le fait que cette méthode repose sur la couche d'abstraction matérielle des périphériques qui composent le volume RAID. Pour diverses raisons, cette couche peut être imparfaite et manquer de certaines fonctions importantes comme, par exemple, la détection et le diagnostic des défauts matériels et/ou la prise en charge du remplacement à  chaud (Hot-swap) des unités de stockage.
La gestion du RAID monopolise des ressources systèmes (légèrement le processeur et surtout le bus système) qui pourraient être employées à  d'autres fins. La baisse de performances due à  la gestion logicielle du raid est particulièrement sensible dans des configurations où le système doit transférer plusieurs fois les mêmes données comme, par exemple, en RAID1, et, assez faible, dans des configurations sans redondance : exemple, le RAID 0.
L'utilisation du RAID sur le disque système n'est pas toujours possible.


Diverses implémentations


La plupart des systèmes d'exploitation grand public permettent déjà  de mettre en Å“uvre le RAID logiciel, qu'il s'agisse de Microsoft Windows, d'une distribution Linux quelle qu'elle soit, ou de Mac OS X.

Microsoft Windows XP (et supérieur) gère le RAID 0 et 1 par le logiciel, et peut gérer le RAID 5 moyennant une petite adaptation5
Microsoft Windows 2003 Server gère logiciellement le RAID 0, 1, et 5.
Mac OS X gère logiciellement le RAID 0, 1 et la concaténation.
Le noyau Linux (>=2.6) gère logiciellement le RAID 0, 1, 4, 5, 6, et 10 ainsi que les combinaisons de ces modes.

Les RAID logiciels de Microsoft Windows et de Linux sont incompatibles [réf. nécessaire] entre eux 6.


Le RAID pseudo-matériel


L'extrême majorité des contrôleurs RAID bon marché intégrés à  de nombreuses cartes mères récentes en 2004/2005 gèrent souvent le RAID 0 et 1 sur des disques IDE ou SATA. Malgré le discours marketing qui tend systématiquement à  induire en erreur sur ce point, il ne s'agit pas de RAID matériel à  proprement parler, mais plutôt d'un contrôleur de disque doté de quelques fonctions avancées.

D'un point de vue strictement matériel, cette solution hybride n'est pas différente d'un RAID logiciel. Elle diffère cependant sur l'emplacement des routines logicielles de gestion du RAID.


Avantages


L'intérêt principal de ce type de RAID est d'apporter une solution au troisième problème du RAID logiciel, à  savoir qu'il ne peut pas toujours servir à  héberger les fichiers du système d'exploitation puisque c'est justement ce dernier qui permet d'y accéder.
Dans ce type de RAID, la présence d'un BIOS intégrant les routines logicielles basiques de gestion du RAID permet de charger en mémoire les fichiers essentiels du système d'exploitation (le noyau et les pilotes essentiels).
Puis, le pilote du contrôleur intègre les mêmes routines logicielles de gestion du RAID et fournit alors aux couches supérieures de l'OS non pas un accès aux périphériques, mais un accès au volume RAID qu'il émule.

 

Inconvénients


En dehors de cet avantage important, ce type de RAID cumule les défauts des deux autres approches :

Les limitations de performances sont les mêmes que pour le raid logiciel, car il s'agit effectivement d'un RAID logiciel camouflé.
Un problème important posé par ces contrôleurs hybrides est leur piètre gestion des défauts matériels et leurs fonctionnalités BIOS généralement limitées.
L'interopérabilité est très mauvaise surtout si l'on considère qu'il s'agit généralement de matériel intégré aux cartes mères des ordinateurs. Pire, le changement de carte-mère (voire simplement de version de bios), si la nouvelle utilise des jeux de puces différents, peut imposer de reconstruire le RAID entièrement. De manière générale, une reconstruction est possible si l'on reste dans des contrôleurs RAID de même marque, mais de modèles différents, mais il n'existe pas de règle définie de compatibilité.
La fiabilité annoncée de ces dispositifs est assez controversée[citation nécessaire].


Le RAID matériel

 

Dans le cas du RAID matériel, une carte ou un composant est dédié à  la gestion des opérations. Le contrôleur RAID peut être interne à  l'unité centrale (carte d'extension) ou déporté dans une baie de stockage.

Un contrôleur raid est en général doté d'un processeur spécifique, de mémoire, éventuellement d'une batterie de secours, et est capable de gérer tous les aspects du système de stockage RAID grâce au microcode embarqué (firmware).

Du point de vue du système d'exploitation, le contrôleur RAID matériel offre une virtualisation complète du système de stockage. Le système d'exploitation considère chaque volume RAID comme un disque et n'a pas connaissance de ses constituants physiques.


Avantages

 

Les contrôleurs RAID matériels permettent la détection des défauts, le remplacement à  chaud des unités défectueuses et offrent la possibilité de reconstruire de manière transparente les disques défaillants. Mais les systèmes d'exploitation évolués permettent également cela si le matériel le permet.
La charge système (principalement l'occupation du bus) est allégée. (surtout dans des configurations avec beaucoup de disques et une forte redondance)
Les vérifications de cohérence, les diagnostics et les maintenances sont effectués en arrière-plan par le contrôleur sans solliciter de ressources système.

 

Inconvénients


Les contrôleurs RAID matériels utilisent chacun leur propre système pour gérer les unités de stockage. En conséquence, au contraire d'un RAID logiciel, des disques transférés d'un système à  un autre ne pourront pas être récupérés si le contrôleur RAID n'est pas exactement le même (firmware compris). Il est donc conseillé de posséder une deuxième carte en cas de panne de la première.
Les cartes d'entrée de gamme possèdent des processeurs de puissance bien inférieure à  celle des ordinateurs actuels. On peut donc avoir de bien moins bonnes performances pour le même prix qu'un RAID logiciel.
Le coà»t : l'entrée de gamme se situe aux alentours de 200 € mais les cartes plus performantes peuvent souvent dépasser les 1 000 €.
Le contrôleur RAID est lui-même un composant matériel, qui peut tomber en panne. Son logiciel (firmware) peut contenir des erreurs, ce qui constitue un autre risque de panne (un nouveau "single-point-of-failure"). Il est peu probable qu'un RAID actuel contienne des erreurs de programmation (bugs) car il est garanti en moyenne une dizaine d'années.
Les différents fabricants de contrôleurs RAID fournissent des outils de gestion logicielle très différents les uns des autres (et de qualité parfois inégale). À l'opposé, les outils de gestion du RAID logiciel fournis avec un système d'exploitation sont généralement bien intégrés dans ce système.
La durée du support d'un contrôleur RAID par son constructeur (correction de bugs dans le firmware, par exemple), parfois liée à  l'arrivée de nouveaux produits rendant les anciens obsolètes, peut-être moins longue ou plus volatile que le support du RAID logiciel par le fournisseur du système d'exploitation. Le constructeur peut même disparaitre (ce qui est assez rare parmi les fabricants de systèmes d'exploitation).
Une moindre souplesse par rapport au RAID logiciel, qui dispose d'une couche d'abstraction permettant de gérer du RAID au-dessus de tous types de périphériques blocs supportés par le système d'exploitation, locaux ou distants (ATA, SCSI, ATA over Ethernet, iSCSI… et toutes les combinaisons possibles entre eux). Les contrôleurs RAID sont spécialisés pour un seul type de périphérique bloc.
 

 

Pour les niveaux de RAID, il y en a plein, mais les plus courants sont :

 

- RAID 0 : stripping pour augmenter la volumétrie et les performances, aucune sécurité, minimum 2 disques

- RAID 1 : mirroir (donc sécurité), minimum 2 disques

- RAID 5 : stripping avec parité répartie, donc performance + sécurité, minimum 3 disques

- RAID 6 : comment RAID 5 mais avec double parité

- RAID 10 association de RAID 0 et 1, donc stripping + mise en mirroir de toutes les données, donc performance + sécurité, le plus luxueux, minimum 4 disques

 

Au sujet du RAID hardware :

 

De base, un disque dur, ce n'est pas fiable. Donc si tu mets plusieurs disques durs dans une même grappe RAID, les probabilités mathématiques font que tu augmentes les chances de perdre les données !!!

 

On a tendance à  croire que le RAID sert à  protéger les données, ce qui est partiellement faux.

 

Le RAID sert à  2 choses :

 

- continuité de service => suite à  la perte d'un disque, on peut continuer à  travailler.... indispensable en entreprise, un peu moins à  la maison

- performance => plus on ajoute d'axe (bras mécanique de disque dur), plus on augmente les perfs.... phénomène entre amplifié par les controleurs RAID qui ont beaucoup de mémoire cache.

 

Pour la sécurité des données, comme je l'ai déjà  répété de nombreuses fois, il faut des sauvegardes sur support externe (ou au minimum une réplication via le réseau sur un 2nd serveur.... attention toutefois aux réplication, car un fichier supprimé ou corrompu est également répliqué la nuit suivante.... donc rien ne remplace une vraie sauvegarde effectuée ponctuellement)

 

Comme dis précédemment, de mauvais disques ne font qu'augmenter les risques de pertes de données.

 

Il y a de nombreux risques d'erreurs sur les disques....

 

évidemment si il y a la panne franche, le disque est HS, là  on ne discute plus. Mais ce cas est de plus en plus rare quand même, les disques d'aujourd'hui sont beaucoup plus fiables que ceux qu'il y a 20 ans.

Ceci dit, si on prend un disque bas de gamme, et qu'on l'utilise de façon soutenue, on va l'user prématurément. Dans les datasheet des disques, il est indiqué son utilisation : 24/7, quantité de données échangées sur une période de temps, etc. Entre un disque bas de gamme et un disque haut de gamme, l'électronique, et la mécanique ne sont pas du tout les mêmes. J'ai croisé un expert en stockage qui avait créé un profil I/O permettant de détruire un disque SATA en moins de 24h, là  où un disque pro accepte la même charge pendant plusieurs mois !!!

 

A coté de ces pannes mécaniques et électronique, il existe un problème primordial et totalement méconnu : l'état de surface du disque.

Quand un disque n'arrive pas à  lire un secteur, il réessaye de nombreuses fois avant d'y arriver. Ce qui peut prendre trop de temps. Si ce temps est raisonnable, le système d'exploitation va attendre que la donnée finisse par arriver. Si la donnée n'arrive jamais, sous Windows on peut avoir aux choix : un popup qui signale l'erreur de lecture, ou le célèbre BSOD dans le pire des cas.

 

Si ce disque est intégré dans une grappe RAID logicielles, le comportement sera plus ou moins le même, car le driver RAID logiciel est dépendant du driver de l'OS. Ensuite, la couche qui gère le RAID (mdadm sous Linux par exemple, utilisé dans les Synology), va décider si l'erreur est récupérable, ou marquer la donnée comme perdue, voire de décider de marquer le disque complet comme défectueux, ce qui nécessitera un rebuild.

 

Maintenant, si ce même disque est branché sur une carte RAID hardware, là  y'a pas 36 solutions, la réaction est systématiquement la même,

 

la carte dégage le disque. Donc RAID complet dégradé, alors que le disque a juste mis quelques millisecondes de trop à  lire la donnée !!!

Là  où c'est drôle (ou pas....), c'est que le disque n'est pas mort, donc on force le rebuild sur le même disque....

oui sauf que le temps de ça reconstruise, on lit à  fond les données sur les autres disques, donc on a de très grande chance que l'un des autres disques mette trop de temps à  lire un secteur... donc celui-ci est dégagé du RAID à  son tour.... et si on est en RAID 5, alors 2 disques de perdus impliquent une perte totale des données !!!! Gnarf

Et je peux vous assurer que cette situation se produit très souvent avec les disques SATA non prévus pour fonctionner en RAID hardware.

 

Alors en entreprise, on n'a pas trop de problème, car les disques SAS sont tous prévus pour fonctionner en RAID.

 

Alors c'est quoi la différence ?

On a dis plus haut que l'électronique et la mécanique des disques SAS est renforcée. Mais pas que. Il y a aussi l'état de surface (meilleure qualité des plateaux magnétiques). Regardez les datasheet, on passe d'une erreur pour 10^14 à  une erreur pour 10^15 octets.

Ce qui permet à  ces disques d'avoir un firmware différent, qui réagira différemment aux secteurs difficiles à  lire. On ne s'autorise qu'un temps très faible pour lire la donnée, afin de ne pas se faire dégager de la grappe RAID par le contrôleur RAID.

Si on est vraiment pas capable de lire la données, alors on en informe rapidement la carte, qui prend la bonne décision (on dégage le disque....). Chez Western Digital, ce phénomène est bien documenté, et la paramètre permettant de régler le temps de recovery de la donnée se nomme le TLER (time-limited error recovery). Le nom est différent chez les concurrents.

Par chance, en disques SATA, on trouve des disques avec le TLER réglé comme il faut... chez WD, c'est la gamme RE4. Regardez la datasheet, ça n'a rien à  voir avec un disque Green ou Red. C'est plus cher qu'un disque SATA classique, sans être au prix d'un disque SAS.

 

En résumé,

 

le RAID logiciel est beaucoup plus tolérant aux défaillance des disques que le RAID matériel.

Et en plus le RAID logiciel est plus souple (il existe des outils de récupération de données, on peut facilement étendre un volume (surtout chez Syno), etc)
Par contre le RAID matériel garde pour lui ses performances (contrôleur dédié au calcul de parité, mémoire cache), et sa fiabilité (il résiste mieux aux pertes de courant).

 

Si je ne veux pas du RAID logiciel de chez Syno (le SHR, pour rappel basé les couches Linux mdadm et ext4), c'est que je ne trouve pas cela fiable. Il n’apprécie pas du tout les pertes de courant, sur le forum Syno officiel c'est bourré de gens qui ont perdu leur grappe RAID SHR suite aux coupures de courant.

Alors bien sur l'onduleur est une solution, mais malgré cela, le format de filesystem sous Linux, ext4, n'est pas très fiable. Au risque de me faire taper dessus par les Linux fanboys, par expérience personnelle je trouve NTFS plus fiable. Et c'est sans compter JFS2 sous AIX, mais là  on n'est plus vraiment dans le domaine de l'informatique personnelle.


 

 

A propos du ZFS par KIWI

 

Qu'est-ce que le ZFS par (Lazer)

 

Pour le ZFS, il faut avant tout noter qu'il s'agit d'une techno proche de Btrfs qu'on trouve sous Linux.


ZFS a été développé par Sun (avant que Oracle l'achète) et a laissé ce système de fichier se balader sur d'autre OS.
ZFS inclu deux choses principales : un gestionnaire de disques et système de fichiers.

Donc on le trouve sur :


- Solaris (et les forks : Nexenta, IllumOS, ...)
- FreeBSD (un des premier Unix libre a le supporter)
- Linux (avec 2 methodes : FUSE ou dans le noyau)

 

Je ne développerais pas la version Linux car à  mon goà»t un peu trop instable et pas encore finie.

On trouve ZFS sur deux "distributions" de serveurs de fichiers : FreeNAS et NAS4Free (fork de FreeNAS).

Fonctionnalités de ZFS :


- Raid : mirror / raid5 (raidz1) / raid6 (raidz2) / raid7 (raidz3)
- Scrubbing : le système peux faire une vérification complète de l'ensemble du FS pour vérifier que les checksum n'ont pas changés car sur les gros HD, la corruption des données arrive plus souvent qu'on ne le pense
- Deduping : ne garder qu'une copie des données sur le HD (par exemple des VM ou des backup... il y a souvent les même datas)
- Compression transparente : les block de données sont compressés sur le FS, ce qui permet de gagner de la place ET de la BP en lecture
- Snapshotting
- Mirroring distante grâce aux snapshot qu'on peux envoyer via SSH ou netcat par exemple (utile pour des backup à  distance...).
- Possibilité d'augmenter les disques en taille sans que ca n'affecte le file system.
- Sur certain OS : export iSCSI et/ou NFS
- Possibilité d'indiquer le nombre de copies de fichiers en plus du sous système raid (eg : etre capable que tous les fichiers soient copiés completement sur au moins "n" disques).
- Cache lecture / écriture sur SSD
- Quasi illimité en nombre de fichier et taille du file system.
- Quota
- Portabilité des pool ZFS entre OS, c'est a dire que vous pouvez effectuer un pool ZFS sur un Solaris, l'exporter et mettre les HD sur un FreeBSD ou autre.
- Pas d'importance dans l'ordre des HD, vous pouvez faire un zpool export d'un pool et mélanger les HD, le zpool import se débrouillera a trouver ses petits.

 

====>  https://fr.wikipedia.org/wiki/ZFS

 

Par KIWI

 

Qu'est-ce qu'à  besoin ZFS :


- des disques peut importe les tailles de disques, on peux se débrouiller avec
- de CPU (si possible des CPU qui sont capables de faire des calculs AES, type core i3/i5/i7, Atom Avoton, ...)
- de RAM (beaucoup si vous utilisez le deduping et/ou compression)
- de processeur 64bits (oubliez les processeurs 32bits)

Le minimun pour commencer c'est 2 disques et 4Go de RAM, plus ZFS a de ram plus il est content. Sur des serveurs du travail j'ai du bi Xeon E5 et 32Go de ram.

Vous pouvez utiliser ZFS sur FreeNAS ou Nas4Free, par contre ces distribution ajoutent une surcouche spécifique à  FreeBSD (et qui n'est pas obligatoire) qui peux chiffrer les données mais vous obligera a rester soit sur FreeNAS ou Nas4Free, et donc impossible de migrer sur d'autre distributions supportant ZFS.

En général je fais ça à  la main.

Sur FreeBSD vous avez les disques nommés : ada0 / ada1 / ada2 / ada3,

 

Exemple :

zpool create file raidz ada0 ada2 raidz ada1 ada3

Permet de créer 2 raid5 (sur 2 hd, oui je sais), dans le même espace de fichiers.

Pourquoi je mets du raid5 sur 2 hd ?

Sur ZFS si on fait ça, automatiquement ça ajoute les checksum lors des écritures et donc le système de fichiers est donc sécurisé.


Pourquoi 2 raid5 ?

Juste que ceci permet de changer 1 à  1 les disques et passer par ex du 3To au 4To tranquillement sans devoir acheter 4 disques d'un coup.

 

Une fois fait vous avez donc :

    zpool status
    pool: filer
    state: ONLINE
    scan: none requested
    config:
     
    NAME STATE READ WRITE CKSUM
    filer ONLINE 0 0 0
    raidz1-0 ONLINE 0 0 0
    ada0 ONLINE 0 0 0
    ada2 ONLINE 0 0 0
    raidz1-1 ONLINE 0 0 0
    ada1 ONLINE 0 0 0
    ada3 ONLINE 0 0 0
     
    errors: No known data errors

On trouve donc monté en /filer le zpool.


Qu'on peux facilement "segmenter" avec les concepts d'héritage des paramètres :

    zfs get all filer
    NAME PROPERTY VALUE SOURCE
    filer type filesystem -
    filer creation Wed Jan 8 19:44 2014 -
    filer used 4.47T -
    filer available 815G -
    filer referenced 27K -
    filer compressratio 1.00x -
    filer mounted yes -
    filer quota none default
    ...

Exemple pour faire un sous FS "compta" avec une taille d'un 1G:

    zfs create filer/compta
    zfs set quota=1G filer/compta
    zfs set atime=no filer/compta

Après ca vous donne :

df -kh
(...)
filer 815G 27K 815G 0% /filer
filer/applications 1.1T 270G 815G 25% /filer/applications
filer/archives 1.2T 415G 815G 34% /filer/archives
filer/compta 1.0G 47M 977M 5% /filer/compta

Après pour le partage en CIFS ou AFP, le fonctionnement est identique à  toute méthode de partage type : samba, netatalk :)

Si vous avez d'autres questions... n'hésitez pas Kiwi vous répondra....


 

  • Upvote 3
Lien vers le commentaire
Partager sur d’autres sites

Il faudrait développer un peu plus les différents niveaux RAID...

 

Pour le niveau 0, si l'on gagne en performance, un disque défaillant et l'on perd tout

Je ne développerai pas les autres niveaux, mais j'ai apprécié (il y a longtemps, lorsque j'avais quelques responsabilités d'un SI) de ne pas perdre une journée de boulot de dizaines de collègues suite à  un crash disque !

 

J'aurais donc tendance à  écrire "On a tendance à  croire que le RAID sert à  protéger les données, ce qui est partiellement .....VRAI" ;)

 

Bien sà»r, il est indispensable d'effectuer des sauvegardes, la technologie RAID permettant en complément d'éviter de perdre une journée de boulot 

  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

merci,

moi qui croyait que je pourrais mieux comprendre tout ça : ce que j'ai compris, c'est que c'est complexe !

J'ai également compris que ma technique d'avoir plusieurs backup sur des médias différents n'était pas si mauvaise que ça.

  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

Y'a eu du pompage là  :lol:

 

@i-magin, VRAI/FAUX, j'avais volontairement mis le terme FAUX pour appuyer sur le fait que le RAID n'apporte pas de sécurisation des données en soit, ce n'est pas son but premier.

La définition initiale c'était "Redundant Arrays of Inexpensive Disks", donc comment créer un gros disque à  partir de plusieurs petits disques (donc peu chers). La notion de sécurité n'est apparue que plus tard.

 

Pour les niveaux de RAID, il y en a plein, mais les plus courants sont :

- RAID 0 : stripping pour augmenter la volumétrie et les performances, aucune sécurité, minimum 2 disques

- RAID 1 : mirroir (donc sécurité), minimum 2 disques

- RAID 5 : stripping avec parité répartie, donc performance + sécurité, minimum 3 disques

- RAID 6 : comment RAID 5 mais avec double parité

- RAID 10 association de RAID 0 et 1, donc stripping + mise en mirroir de toutes les données, donc performance + sécurité, le plus luxueux, minimum 4 disques

 

JOJO oui les sauvegardes sont primordiales.

  • Upvote 4
Lien vers le commentaire
Partager sur d’autres sites

RAID 5 : il faut un contrôleur hardware (qui est forcément bon, puisque dédié), mais c'est surtout ce qui va à  coté qui importe :

- mémoire cache

- batterie (sans batterie, la mémoire cache est utilisée en lecture seule, donc les perfs en écriture ne sont pas accélérées.... et comme le RAID 5 est mauvais en écriture, donc les perfs globales sont mauvaises).

 

A noter que sur les cartes modernes, la batterie est remplacée par un super condensateur + mémoire flash, cela permet de dépasser très largement la durée de vie limitée (2 à  3 ans) des batteries initiales. Par contre c'est plus cher à  l'achat.

Lien vers le commentaire
Partager sur d’autres sites

Hello,

Pour le ZFS, il faut avant tout noter qu'il s'agit d'une techno proche de Btrfs qu'on trouve sous Linux.

ZFS a été développé par Sun (avant que Oracle l'achète) et a laissé ce système de fichier se balader sur d'autre OS.

ZFS inclu deux choses principales : un gestionnaire de disques et système de fichiers.

Donc on le trouve sur :

- Solaris (et les forks : Nexenta, IllumOS, ...)

- FreeBSD (un des premier Unix libre a le supporter)

- Linux (avec 2 methodes : FUSE ou dans le noyau)

Je ne développerais pas la version Linux car à  mon goà»t un peu trop instable et pas encore finie.

On trouve ZFS sur deux "distributions" de serveurs de fichiers : FreeNAS et NAS4Free (fork de FreeNAS).

Fonctionalités de ZFS :

- Raid : mirror / raid5 (raidz1) / raid6 (raidz2) / raid7 (raidz3)

- Scrubbing : le système peux faire une vérification complète de l'ensemble du FS pour vérifier que les checksum n'ont pas changés car sur les gros HD, la corruption des données arrive plus souvent qu'on ne le pense

- Deduping : ne garder qu'une copie des données sur le HD (par exemple des VM ou des backup... il y a souvent les même datas)

- Compression transparente : les block de données sont compressés sur le FS, ce qui permet de gagner de la place ET de la BP en lecture

- Snapshotting

- Mirroring distante grâce aux snapshot qu'on peux envoyer via SSH ou netcat par exemple (utile pour des backup à  distance...).

- Possibilité d'augmenter les disques en taille sans que ca n'affecte le file system.

- Sur certain OS : export iSCSI et/ou NFS

- Possibilité d'indiquer le nombre de copies de fichiers en plus du sous système raid (eg : etre capable que tous les fichiers soient copiés completement sur au moins "n" disques).

- Cache lecture / écriture sur SSD

- Quasi illimité en nombre de fichier et taille du file system.

- Quota

- Portabilité des pool ZFS entre OS, c'est a dire que vous pouvez effectuer un pool ZFS sur un Solaris, l'exporter et mettre les HD sur un FreeBSD ou autre.

- Pas d'importance dans l'ordre des HD, vous pouvez faire un zpool export d'un pool et mélanger les HD, le zpool import se débrouillera a trouver ses petits.

Qu'est-ce qu'à  besoin ZFS :

- des disques peut importe les tailles de disques, on peux se débrouiller avec

- de CPU (si possible des CPU qui sont capables de faire des calculs AES, type core i3/i5/i7, Atom Avoton, ...)

- de RAM (beaucoup si vous utilisez le deduping et/ou compression)

- de processeur 64bits (oubliez les processeurs 32bits)

Le minimun pour commencer c'est 2 disques et 4Go de RAM, plus ZFS a de ram plus il est content. Sur des serveurs du travail j'ai du bi Xeon E5 et 32Go de ram.

Vous pouvez utiliser ZFS sur FreeNAS ou Nas4Free, par contre ces distribution ajoutent une surcouche spécifique à  FreeBSD (et qui n'est pas obligatoire) qui peux chiffrer les données mais vous obligera a rester soit sur FreeNAS ou Nas4Free, et donc impossible de migrer sur d'autre distributions supportant ZFS.

En général je fais ça à  la main.

Sur FreeBSD vous avez les disques nommés : ada0 / ada1 / ada2 / ada3, par exemple :

 

zpool create file raidz ada0 ada2 raidz ada1 ada3
Permet de créer 2 raid5 (sur 2 hd, oui je sais), dans le même espace de fichiers.

Pourquoi je mets du raid5 sur 2 hd ? Sur ZFS si on fait ça, automatiquement ça ajoute les checksum lors des écritures et donc le système de fichiers est donc sécurisé.

Pourquoi 2 raid5 ? Juste que ceci permet de changer 1 à  1 les disques et passer par ex du 3To au 4To tranquillement sans devoir acheter 4 disques d'un coup.

Une fois fait vous avez donc :

zpool status
pool: filer
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
filer ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ada0 ONLINE 0 0 0
ada2 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
ada1 ONLINE 0 0 0
ada3 ONLINE 0 0 0

errors: No known data errors
On trouve donc monté en /filer le zpool.

Qu'on peux facilement "segmenter" avec les concepts d'héritage des paramètres :

 

zfs get all filer
NAME PROPERTY VALUE SOURCE
filer type filesystem -
filer creation Wed Jan 8 19:44 2014 -
filer used 4.47T -
filer available 815G -
filer referenced 27K -
filer compressratio 1.00x -
filer mounted yes -
filer quota none default
...
Exemple pour faire un sous FS "compta" avec une taille d'un 1G:

 

zfs create filer/compta
zfs set quota=1G filer/compta
zfs set atime=no filer/compta
Après ca vous donne :

df -kh
(...)
filer 815G 27K 815G 0% /filer
filer/applications 1.1T 270G 815G 25% /filer/applications
filer/archives 1.2T 415G 815G 34% /filer/archives
filer/compta 1.0G 47M 977M 5% /filer/compta
Après pour le partage en CIFS ou AFP, le fonctionnement est identique à  toute méthode de partage type : samba, netatalk :)

Si vous avez d'autres questions... n'hésitez pas :)

  • Upvote 3
Lien vers le commentaire
Partager sur d’autres sites

Merci !

Par contre du coup, il faut une sacré machine pour que ça vaille le coup, donc pour une simple NAS privé, peut d'intêret je dirai. En tout as cela àl'air assez puissant !

Lien vers le commentaire
Partager sur d’autres sites

Comme je disais, le coût d'un contrôleur RAID hardware est transféré dans le CPU/RAM du système pour faire tourner ZFS. Il n'y a pas de magie, le stockage performant ça nécessite toujours de la ressource matérielle, quelle que soit son type.

  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

@mprinfo oui sans pb.

@lazer le CPU même "low life" d'un PC sera toujours plus puissant que ceux qu'on trouve dans une carte raid hardware (elle a des limitations : nb de disques type de raid etc...), donc même un ATOM type C2550 suffit largement pour faire du ZFS et aura un comportement "intéressant" par rapport aux raid hardware. J'avais fait un zpool avec 40 HD SAS 73G 10K sur 4 cartes SAS type LSI 1068E, qui défonçais en I/O OPS un SSD SATA... :D Par contre au niveau conso electrique...

@nico je fais tourner mon filer zfs sur un HP MicroServer Gen8 avec le CPU d'origine : CPU: Intel® Pentium® CPU G2020T @ 2.50GHz (2494.39-MHz K8-class CPU), ce processeur a tout ce qu'il faut (et même me permet de faire du transcoding avec plex) :

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0xd9ae3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,XSAVE,OSXSAVE>

AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>

AMD Features2=0x1<LAHF>

Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>

VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID

TSC: P-state invariant, performance statistics

Les grosses features, c'est carrément si tu vas envie de saturer des liens giga en permanance, pour un serveur de fichiers à  la maison, 4Go suffit (mais ca peux être juste des fois).

Il n'as pas l'option AESNI qu'as les ATOM C2550 ou C2750 :

CPU: Intel® Atom CPU C2550 @ 2.40GHz (2400.06-MHz K8-class CPU)

Origin = "GenuineIntel" Id = 0x406d8 Family = 0x6 Model = 0x4d Stepping = 8

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND>

AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>

AMD Features2=0x101<LAHF,Prefetch>

Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS>

VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID

TSC: P-state invariant, performance statistics

Donc dans ce cas, c'est le noyau qui fait des checksum AES, c'est "un peu" plus lent mais pas tant que ça.

Par contre je ne fais pas de dedup ni de compression car j'ai pas assez de RAM.

L'avantage c'est (en simplifiant) :

 

zfs snapshot && zfs send | nc target 5000
nc -l 5000 | zfs receive
Ultra pratique pour faire des backup avec juste le diff des fichiers (au contraire de rsync qui retranfert tout, on ne transfert QUE les "inodes" changées).

J'ai mis "inodes" entre "" car il n'y a pas de concept sur ZFS...

Ah un dernier point ultra important : ZFS est un FS COW (Copy On Write), il ne supporte pas qu'il n'y ait pas d'espace libre sur son dataset.

Par conséquent si vous avez un espace de 1Go plein, vous ne pouvez pas supprimer un fichier s'il n'y a pas d'espace libre... Attention aux pièges a la con dans ce cas (je connais quelques collègues qui m'ont pas crus et qui on eu un jour des suprises, maintenant ils font gaffe quand la supervision envoie "attention reste moins de 5% d'espace libre...").

Lien vers le commentaire
Partager sur d’autres sites

De mémoire de captainigloo, je n'ai jamais eu de pépin avec mes disques sous Synology.

Dix ans au moins que je tourne avec et pas un disque perdu. Certes je choisie pas les disque les moins cher au moment où je me fais une config. Par exemple dans mon 1512+ J'ai 5 Black Caviar 2To. Pareil dans le 710+. Et 4 spares pour la suite. Ben les spares sont pas utile depuis 5 ans

Certes c'est pas du SAS à  15Kt/m mais c'est vraiment robuste.

Il faut surtout bien préparer son raid et ses disques avant toutes choses.

De plus il faut corriger le post initial, un onduleur c'est pas une option, c'est un devoir pour un serveur.

 

raid5synology.png

Lien vers le commentaire
Partager sur d’autres sites

@captainlgoo le post initial et un copy d'un post de lazer

Perso je tourne sans onduleur avec mon serveur il me sert principalement de stockage il est donc souvent éteint lorsque que j'ai un besoin j'envoie un wol je me sert du disque de la freebox qui lui est toujours allumé et je fais des copie entre les 2 donc pour moi un onduleur n'est pas vraiment utile

@nico j'ai tourné pendant presque un an avec freenas 0.72 avant de passer au dsm 4 j'avais 3 disques de 3to en raidzfs sur min n40l aucun soucis j'avais les mêmes débit que sous dsm

Envoyé de mon SM-G900F en utilisant Tapatalk

Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...