Bande ZFS au-dessus du RAID matériel 6. Qu'est-ce qui pourrait mal tourner?


9

J'ai 36 * 4 To HDD SAN Rack. Le contrôleur RAID ne prend pas en charge RAID60 et pas plus de 16 disques durs dans un groupe RAID. J'ai donc décidé de faire 2 groupes RAID6 de 16HDD ou 4 de 8 HDD. Je veux obtenir tout le stockage en une seule partition.

Alors, qu'est-ce qui pourrait mal tourner si j'utilise le pool zfs au-dessus du matériel RAID6? Oui, je sais qu'il est fortement recommandé d'utiliser des disques durs natifs ou un mode passe-système. Mais je n'ai pas cette option.

Ou dois-je rester à l'écart de ZFS et des raids logiciels dans cette situation? (Je suis surtout intéressé par la compression et les instantanés)


2
Si vous allez utiliser ZFS, pourquoi ne pas simplement exposer tous les disques individuellement (parfois appelé mode HBA) et laisser ZFS le gérer - c'est ce qu'il fait de mieux. Nous avons un certain nombre de vrais experts en la matière (ewwhite pour commencer) qui vous aideront avec cela - quel contrôleur de disque exact utilisez-vous?
Chopper3

1
Vous subvertirez de nombreuses fonctionnalités ZFS en utilisant cette méthode, mais dans l'ensemble, cela ne fera rien de mal de le faire de cette façon. La somme de contrôle est un peu plus inutile dans cette configuration, car le contrôleur RAID va supprimer tous les détails du disque. Je suis plus intéressé par la raison pour laquelle vous dites que vous ne pouvez pas utiliser JBOD. assuresan 3530 sont des unités compatibles JBOD.
Spooler

2
J'attendrais ewwhite - il est dans le centre des États-Unis, donc il dort mais il connaît ZFS mieux que quiconque
Chopper3

1
@Severgun De plus, 4 disques durs restent inutiles car aucun besoin en hotspare Pensez-vous vraiment qu'il est préférable pour une matrice RAID avec un disque défectueux de boiter en mode dégradé que de récupérer automatiquement un disque de secours, de reconstruire et de revenir à la état fonctionnel?
Andrew Henle

1
@ Chopper3 je vais répondre ... à contrecœur.
ewwhite

Réponses:


5

J'ai donc décidé de faire 2 groupes RAID6 de 16HDD ou 4 de 8 HDD.

Ce n'est pas la meilleure façon de faire les choses. Cela peut fonctionner assez bien, mais en fonction de vos exigences de performances, il se peut que cela ne fonctionne pas.

La taille idéale pour une matrice RAID5 / 6 sera telle qu'un multiple exact de la quantité de données qui "s'étend" la matrice correspond à la taille de bloc du système de fichiers construit au-dessus.

Les baies RAID5 / 6 fonctionnent comme des unités de blocs - un seul bloc de données s'étend sur les disques de la baie, et ce bloc contient également des données de parité. La plupart des contrôleurs RAID écrivent un bloc de données d'une puissance de deux sur chaque disque de la matrice - dont la valeur exacte est configurable dans de meilleurs systèmes RAID - et votre unité Dot Hill est l'un de ces "meilleurs systèmes RAID". C'est important.

Il faut donc N x (quantité de données stockées par bloc de disque) pour s'étendre sur la baie, où N est le nombre de disques de données. Une matrice RAID5 à 5 disques possède 4 disques de «données» et une matrice RAID6 à 10 disques a 8 disques de données.

Parce que lorsque les données sont écrites sur une matrice RAID5 / 6, si le bloc de données est tel qu'il est suffisamment grand pour s'étendre à l'ensemble de la matrice, la parité est calculée pour ces données - généralement dans la mémoire du contrôleur - alors toute la bande est écrite dans disque. Simple et rapide.

Mais si le bloc de données en cours d'écriture n'est pas assez grand pour s'étendre à l'ensemble de la baie, que doit faire le contrôleur RAID pour calculer les nouvelles données de parité? Pensez-y - il a besoin de toutes les données de toute la bande pour recalculer les nouvelles données de parité.

Donc, si vous créez une matrice RAID6 à 16 disques avec le bloc par disque par défaut de 512 Ko, cela signifie qu'il faut 7 Mo pour "étendre" la matrice.

ZFS fonctionne généralement en blocs de 128 Ko.

ZFS écrit donc un bloc de 128 Ko - dans une matrice RAID6 à 16 disques. Dans la configuration que vous proposez, cela signifie que le contrôleur RAID doit lire près de 7 Mo à partir de la baie et recalculer la parité sur ces 7 Mo. Réécrivez ensuite l'intégralité de ces 7 Mo sur le disque.

Si vous êtes chanceux, tout est dans le cache et vous ne prenez pas un énorme coup de performance. (C'est une des principales raisons pour lesquelles la position "ne pas utiliser RAID5 / 6" a un tel suivi - RAID1 [0] n'en souffre pas.)

Si vous n'avez pas de chance et que vous n'avez pas correctement aligné vos partitions de système de fichiers, ce bloc de 128 Ko s'étend sur deux bandes RAID qui ne sont pas dans le cache, et le contrôleur doit lire 14 Mo, recalculer la parité, puis écrire 14 Mo. Tout pour écrire un bloc de 128 Ko.

Maintenant, c'est ce qui doit se passer logiquement . Il existe de nombreuses optimisations que de bons contrôleurs RAID peuvent prendre pour réduire les E / S et la charge de calcul de ces modèles d'E / S, donc ce n'est peut- être pas si mal.

Mais sous une lourde charge d'écriture de blocs de 128 Ko dans des emplacements aléatoires, il y a de très bonnes chances que les performances d'une matrice RAID6 à 16 disques avec une taille de bande de 7 Mo soient absolument terribles.

Pour ZFS, les LUN RAID5 / 6 sous-jacents "idéaux" pour un système de fichiers à usage général où la plupart des accès sont effectivement aléatoires auraient une taille de bande qui est un diviseur pair de 128 Ko, comme 32 Ko, 64 Ko ou 128 Ko. Dans ce cas, cela limite le nombre de disques de données dans une matrice RAID5 / 6 à 1 (ce qui est absurde - même si cela est possible à configurer, il est préférable d'utiliser simplement RAID1 [0]), 2, 4 ou 8. Meilleures performances dans le meilleur des cas, il faudrait utiliser une taille de bande de 128 Ko pour les matrices RAID5 / 6, mais le meilleur des cas ne se produit pas souvent dans les systèmes de fichiers à usage général - souvent parce que les systèmes de fichiers ne stockent pas les métadonnées de la même manière qu'elles stocker les données du fichier.

Je recommanderais de configurer des matrices RAID5 à 5 disques ou des matrices RAID6 à 10 disques, avec la taille de bloc par disque définie suffisamment petite pour que la quantité de données pour couvrir une bande de matrice entière soit de 64 Ko (oui, je l'ai fait avant pour ZFS - plusieurs fois). Cela signifie que pour une matrice RAID avec 4 disques de données, la taille de bloc par disque doit être de 16 Ko, tandis que pour une matrice RAID à 8 disques de données, la taille de bloc par disque doit être de 8 Ko.

Ensuite ZFS permettent d'utiliser l' ensemble de tableau - ne pas partitionner. ZFS s'alignera correctement sur un lecteur entier, qu'il s'agisse d'un simple disque unique ou d'une matrice RAID présentée par un contrôleur RAID.

Dans ce cas, et sans connaître votre espace exact et vos exigences de performances, je vous recommande de configurer trois baies RAID6 à 10 disques ou six baies RAID5 à 5 disques avec une taille de bande de 64 Ko, de configurer quelques disques de rechange et d'enregistrer quatre de vos disques pour tout ce qui arrivera à l'avenir. Parce que quelque chose le fera.

Je n'utiliserais certainement pas ce système de disques en mode JBOD - c'est un appareil entièrement conforme au niveau 3 de NEBS qui offre des protections de fiabilité et de disponibilité importantes intégrées directement dans le matériel. Ne jetez pas ça juste parce que "ZFS !!!!". S'il s'agit d'un matériel bon marché que vous assemblez à partir de pièces? Oui, le mode JBOD avec ZFS gérant le RAID est le meilleur - mais ce n'est PAS le matériel dont vous disposez. UTILISEZ les fonctionnalités fournies par le matériel.


Cela signifie que pour une matrice RAID avec 4 disques de données, la taille de bloc par disque doit être de 16 Ko, tandis que pour une matrice RAID à 8 disques de données, la taille de bloc par disque doit être de 32 Ko. Je suis un peu confus avec ce calcul. Pourquoi 8 disques - bloc de 32 Ko? Corrigez-moi si je me trompe: 128 Ko (bloc ZFS) / 3 (matrices RAID) = 43 Ko par baie RAID. RAID6 de 10 disques 43 Ko / 8 = 5 Ko (taille de bloc non disponible) La taille de bloc de 8 Ko la plus proche n'est pas non plus disponible par matériel. Alors, les meilleures performances ne sont pas accessibles?
Severgun

@Severgun J'ai mis les tailles de morceaux en arrière. Le problème avec la recherche des meilleures performances absolues sur RAID5 / 6 est que cela ne se produira que lorsque presque toutes les opérations d'E / S correspondent parfaitement à la taille de la bande de la matrice RAID. Un nombre important d'opérations d'E / S inférieures à la taille de bande peut sérieusement dégrader les performances. L'utilisation d'une taille de bloc plus petite permet de limiter l'impact des écritures aléatoires sur de petits blocs. D'après mon expérience, il est préférable de renoncer à 1-2% des performances maximales possibles en échange de la limitation de la chute dans le pire des cas. Les systèmes de fichiers à usage général ont tendance à avoir un bon nombre de petites écritures.
Andrew Henle

(suite) 8 disques de données dans une matrice RAID5 / 6 avec une taille de bloc de 16 Ko par disque permettent une taille de bande de 128 Ko sur la matrice. De même, des blocs de 32 Ko pour une matrice de 4 disques de données. ZFS écrit un bloc de données de fichier de 128 Ko sur un seul appareil - il n'est pas réparti sur tous les zdev. Encore une fois, cependant, pour un système de fichiers à usage général, il y aura beaucoup d'écritures inférieures à 128 Ko, donc une taille de bande plus petite (64 Ko) évitera mieux la dégradation des performances sous une charge d'écriture élevée, mais à moindre coût dans le meilleur des cas. performances du boîtier.
Andrew Henle

4

D'accord, je vais mordre ...

Il s'agit du mauvais matériel pour l'application. La configuration DotHill présente les mêmes limites qu'un HP StorageWorks MSA2000 / P2000 en ce que seuls 16 disques peuvent être utilisés dans un seul groupe de baies.

ZFS au-dessus du RAID matériel ou d'un SAN LUN exporté n'est pas nécessairement un problème.

Cependant, le fait de répartir les LUN ZFS sur des interconnexions inconnues sur un châssis d'extension peut présenter certains risques.

  • Par exemple, exécutez-vous SAS multichemin dans une topologie en anneau avec deux contrôleurs?
  • Avez-vous un câblage redondant vers le serveur?
  • Avez-vous réparti les disques verticalement entre les boîtiers d'une manière qui atténuerait la défaillance d'un seul châssis / câble / contrôleur et l'empêcherait de détruire une partie de votre bande RAID0?

Sérieusement, il peut être utile d'évaluer si vous avez besoin de tout ce stockage dans un seul espace de noms ...

Si vous avez besoin de ce type de capacité dans un seul montage, vous devez utiliser un boîtier JBOD dédié HBA et éventuellement plusieurs unités de tête avec un câblage élastique et une configuration plus intelligente.


1

Vous devez attacher DIRECTEMENT tous les lecteurs à une boîte exécutant ZFS. Procurez-vous un HBA SAS et connectez les disques au boîtier compatible ZFS (par exemple, en exécutant OmniOS ou SmartOS). Vous pouvez ensuite partager l'espace via NFS, SMB, iScsi ...


Vous devez connecter DIRECTEMENT tous les lecteurs à une boîte exécutant ZFS. Pas nécessairement - le remplacement des disques défectueux dans une matrice matérielle sur certains contrôleurs est facile : retirez le disque dur avec le voyant de panne allumé puis insérez-en un nouveau. Aucun administrateur système n'a eu besoin d'exécuter des commandes ZFS pour remplacer le disque. Dans une configuration d'entreprise avec des centaines ou des milliers de serveurs et peut-être des dizaines de milliers de disques durs répartis sur plusieurs centres de données, c'est une préoccupation. Les disques échouent beaucoup plus que la pourriture des bits.
Andrew Henle

@Tobi Oetiker me dit comment placer 36 disques durs 3,5 "dans un boîtier 2U
Severgun

nous les mettons juste dans une boîte supplémentaire ... utilisez un extenseur sas ... comme pour les déploiements importants, demandez peut-être à quel point joyent le gère.
Tobi Oetiker

@AndrewHenle Pour être honnête, il est possible d'obtenir la même procédure de remplacement facile et les mêmes voyants d'état avec ZFS et les bons adaptateurs de bus hôte (cela peut impliquer des scripts mineurs si vous n'utilisez pas une solution préemballée).
user121391

0

La raison pour laquelle ZFS au-dessus des volumes logiques HW RAID est une idée TRÈS MAUVAISE , parce que ZFS nécessite un accès au niveau du bloc pour fonctionner correctement. Oui, il sera utilisable, mais la fonctionnalité ne sera pas complète jusqu'à ce que vous connectiez les disques directement au système d'exploitation via un HBA ou des connexions SATA directes. Un exemple est que dans la configuration que vous proposez, ZFS ne peut pas raisonnablement protéger vos données contre les modifications des données ci-dessous (de l'autre côté du contrôleur HW RAID), et en tant que tel ne peut pas garantir la sécurité de vos données . C'est l'une des principales raisons pour lesquelles ZFS est utilisé, en plus d'être très rapide.

ZFS est une technologie géniale, et je la recommande vivement. Mais vous devrez revoir votre structure ici afin de pouvoir l'utiliser correctement. A savoir que ZFS crée directement les volumes logiques (vdevs) à partir des disques.

Il semble qu'il y ait beaucoup plus de lecture à faire sur le fonctionnement de ZFS avant de pouvoir comprendre avec précision ce que vous avez proposé, contrairement à ce qui devrait vraiment être fait à la place.


Oui oui et oui. Je comprends autant que possible le fonctionnement de ZFS. Mais il y a quelques complications: 1) J'ai déjà un boîtier SAN et je dois l' utiliser. Je ne construis pas de stockage à partir de zéro. 2) Ce n'est pas mon NAS à la maison où je peux acheter et jeter des choses. 3) Le budget pour la reconstruction de la configuration du stockage est égal à zéro . Du stockage, j'ai besoin d'une vitesse d'écriture maximale disponible avec un espace d'environ 100 To. Je regarde ZFS principalement en raison de la compression et des instantanés. Je peux essayer btrfs mais c'est expérimental. Hmm, ZoL peut aussi être instable? Je ne sais pas.
Severgun

@Severgun Tant que vous savez quels sont les inconvénients, tout ira bien à mon avis. ZFS possède de nombreuses fonctionnalités intéressantes (comme les instantanés) qui fonctionnent indépendamment des autres. La plupart des conseils sur Internet soulignent l'importance des meilleures pratiques dans tous les domaines, mais ce sont des recommandations, pas des exigences strictes. Ce point deviendra moins important à l'avenir, car de plus en plus de distributions LInux se transforment en ZFS et la plupart des systèmes Linux fonctionnent en virtualisé, ils auront donc votre situation exacte.
user121391

1
La raison pour laquelle ZFS au-dessus des volumes logiques HW RAID est une idée TRÈS MAUVAISE, parce que ZFS nécessite un accès au niveau du bloc pour fonctionner correctement. C'est tellement mauvais que ce n'est même pas assez bon pour être appelé faux. Vous n'avez apparemment aucune idée de ce que signifie un matériel compatible NEBS 3, n'est-ce pas? en plus d'être super rapide duper. ZFS est plein de bonnes choses. "super duper fast" n'en fait PAS partie. Il s'agit d'un système de fichiers rapide . Il en est de même . Dans les systèmes de fichiers, ZFS n'est pas rapide.
Andrew Henle
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.