Configuration RAID pour les grands NAS


13

Je pense à construire une boîte NAS à disque de 24 To, mais je ne sais pas quelle est la meilleure configuration de lecteur. J'envisage d'utiliser le contrôleur areca ARC-1280ML-2G et d'en suspendre les 24 disques.

J'aimerais que tout soit monté en un seul volume, en raison du type de données que nous stockons dessus. Une idée folle que nous avons eue était de configurer 6 volumes RAID 5 à 4 disques, puis de faire le RAID 5 logiciel sur ces 6 volumes. Cela signifierait que n'importe quel volume pourrait mourir sur nous et nous ne perdrions toujours pas de données.

Je dois noter qu'il s'agit d'un projet de R&D, nous avons une application à venir où nous aurons besoin de dizaines de téraoctets de stockage pour être rapide et hautement disponible. Mais pour la phase initiale de R&D, nous pouvons accepter certains risques.

Quelle est la meilleure solution à ce type de configuration? Avec 24 disques de 1 To, il est probable que plusieurs échoueront en même temps (ou dans le temps nécessaire pour reconstruire le volume après un premier échec), j'ai donc du mal à trouver une bonne solution.

Réponses:


10

Il existe déjà un niveau RAID pour ce que vous voulez; cela s'appelle RAID 10.

Le MTBF pour les disques professionnels et grand public a augmenté d'un ordre de grandeur ces dernières années, le taux d'erreur non corrigible est resté relativement constant. Ce taux est estimé à 10 ^ 14 bits, donc un bit par 12 téraoctets lus, pour les disques SATA grand public, source .

Ainsi, pour chaque analyse de vos passes de votre lecteur 24 To, statistiquement, vous rencontrerez au moins 2 erreurs de bit unique. Chacune de ces erreurs déclenchera une reconstruction RAID5, et pire encore, lors de la reconstruction, une deuxième erreur entraînera une double erreur.


D'excellents points sur le taux d'erreur non corrigible, mais dans le 3ème paragraphe, vous devez ajouter que "statistiquement, vous rencontrerez ...", car nous savons tous que les erreurs de lecture (ou leur absence) ne sont pas certaines
Matt Simmons

N'essaiera-t-il pas de relire avant de reconstruire?
Antoine Benkemoun

Antoine: Bien sûr, mais s'il ne peut vraiment pas être lu, il va falloir le reconstruire pour obtenir les données de la parité, IIRC.
Matt Simmons

@Antonie, ce sont des erreurs de lecture non corrigibles, c'est-à-dire des erreurs qui ne peuvent pas être corrigées par la logique ECC des lecteurs (qui corrige les erreurs à un taux significativement supérieur à 1: 10 ^ 14)
Dave Cheney

Ce sont donc des erreurs causées par des erreurs d'écriture? qu'est-ce qui empêche une deuxième lecture de réussir?
Antoine Benkemoun

11

C'est précisément mon travail quotidien ... construire des serveurs de stockage Linux.

  • La carte Areca est OK. Vous pouvez l'utiliser en RAID-6, il fournira une sécurité raisonnable. Achetez également l'unité de sauvegarde sur batterie en option .
  • Utilisez des disques d'entreprise , pas des disques de bureau. Vous dépenserez 400 dollars de plus sur votre serveur, mais cela en vaut la peine. Achetez deux disques de rechange. Ne vous en faites pas, utilisez des disques du même modèle.
  • Pour le système de fichiers, utilisez XFS . Sans blague, ext3 et amis ne seront tout simplement pas à la hauteur des systèmes de fichiers 16 To +. Même en cas de crash grave, xfs_repair sera assez rapide sur un volume de 20 To (15 minutes, pas plus).
  • De préférence, utilisez LVM2 , cela facilitera la gestion du stockage, même si vous ne prévoyez pas de le modifier beaucoup.
  • installez l'outil de gestion d'areca et rédigez un travail cron pour vous envoyer un e-mail quotidien avec un bilan de santé.
  • N'oubliez pas la sauvegarde . RAID n'est pas une sauvegarde; si quelqu'un supprime simplement un fichier important, vous ne pourrez pas récupérer sans une sauvegarde appropriée. J'utilise personnellement rdiff-backup pour enregistrer toutes les données importantes sur un serveur dédié avec un historique d'un mois; vous pouvez également créer deux volumes RAID sur votre serveur de fichiers et sauvegarder l'un sur l'autre.

6

wow, RAID5 sur RAID5? Vous souhaitez discuter des problèmes de performances? Vous aurez des tonnes . L'hôte auquel vous suspendez ceux-ci aura des chatons calculant la parité, écrivant cette parité sur 3 disques, puis calculant la parité de CETTE parité et l'écrivant sur le 4ème disque de cet ensemble. HOU LA LA!

Parlons de RAID10. Il s'agit essentiellement de RAID 1, mais vous divisez vos disques en deux et reflétez cela. Il est tolérant aux pannes en ce sens que vous pouvez perdre 2 disques tout en restant bien, et les performances sont exceptionnelles.

Si vous n'avez pas besoin d'un espace insensé, mais que vous avez une baie de 24 To avec rien de mieux à faire, mais qu'elle doit absolument être en place, alors vous pourriez envisager RAID60. Il s'agit essentiellement de RAID6 utilisant des ensembles de disques en miroir. Vous perdrez environ la moitié de vos disques et les performances seront mauvaises, mais vous serez presque assuré que les données seront là.

Vraiment, j'irais avec RAID10. Il fonctionne bien et fonctionne bien. J'appuie l'opinion d'Evan selon laquelle vous ne devriez probablement pas créer d'ensembles RAID géants avec autant de disques, car comme il le dit, des choses comme fsck et chkdsk prendront une éternité, mais plus important encore dans mon esprit, car la probabilité statistique d'une erreur de lecture augmente comme le fait la taille du disque individuel. Je recommanderais 7 à 10 disques par ensemble. Vous pouvez créer 3 volumes RAID de taille très décente avec ce nombre de broches.

Quel que soit votre choix, n'oubliez pas de laisser quelques disques en réserve, afin de pouvoir commencer la reconstruction immédiatement, plutôt que de faire attendre la baie pour les remplacer. Dès qu'un disque meurt, l'horloge commence à tourner pour qu'un autre disparaisse.


@Matt: Je ne parle pas de la taille des ensembles RAID - je parle de la taille du système de fichiers. Utiliser un seul système de fichiers aussi volumineux, quel que soit le type de système de fichiers, demande un temps d'arrêt énorme lorsque vous devez exécuter une vérification du système de fichiers parce que le système d'exploitation hôte a «corrompu» le système de fichiers, etc.
Evan Anderson

@Evan - Désolé, ma mauvaise. Mais c'est aussi un autre argument contre cela.
Matt Simmons

@Matt: Un argument contre quoi? La disposition des conteneurs RAID et le nombre de systèmes de fichiers sur ces conteneurs RAID sont des préoccupations orthogonales. Vous n'avez pas besoin d'avoir un seul système de fichiers dans un seul conteneur RAID, et un système de fichiers peut s'étendre sur plusieurs conteneurs RAID dans la plupart des systèmes d'exploitation.
Evan Anderson

Vous avez raison sur les deux. Nous sommes d'accord. Vous ne devez pas créer des systèmes de fichiers extrêmement volumineux car le temps de vérification est mauvais. Vous ne devez pas non plus effectuer des volumes de raid extrêmement importants car la probabilité statistique d'une erreur de lecture augmente.
Matt Simmons

2

Pourquoi pas RAID 1 + 0? Tout est géré au niveau du contrôleur ...


1

Je sais que vous avez dit «R&D», mais vous avez également dit «hautement disponible». Je remettrais en question les «économies» d'une solution de bricolage par rapport à l'achat de matériel SAN standard pour ce faire. Lorsque les choses tournent mal avec votre solution de bricolage, vous serez dans la position peu enviable de n'avoir personne à contacter pour obtenir de l'aide. Qu'est-ce que le temps d'arrêt vous coûte par heure? Vous pouvez consommer assez rapidement le coût de certains équipements SAN de niveau moyen en temps d'arrêt, en ignorant les dépenses associées à la perte de données.

Indépendamment de ce que vous faites sur le disque sous-jacent, je ne créerais pas un seul système de fichiers aussi volumineux.

La corruption du système de fichiers est une possibilité réelle (problème de contrôleur RAID, bogues du système d'exploitation, etc.). Dans un volume aussi volumineux, une vérification du système de fichiers va prendre une éternité. Je recommanderais fortement d'utiliser plusieurs volumes qui peuvent être logiquement combinés pour apparaître comme un seul système de fichiers (par divers moyens - vous n'avez pas mentionné le système d'exploitation, donc je ne peux pas vous donner d'idées spécifiques). Si vous avez une corruption du système de fichiers, vous perdrez une partie du volume logique, mais vous serez toujours "actif".

Par exemple: dans un monde Windows, l'exécution de CHKDSK sur un volume NTFS de 20 To rempli de fichiers va être LENTE . Dans ce type d'environnement, je créerais plusieurs volumes NTFS plus petits et les combinerais logiquement dans un seul espace de noms avec DFS.


1

wazoox, les réponses sont bonnes, je n'ai pas le représentant pour lui donner plus de points positifs, mais j'ajouterais ce qui suit.

RAID 6 ou au moins 2 disques de parité en direct pour 10 disques, 16 au maximum, c'est-à-dire si vous pouvez prendre environ une journée lorsque les performances seront affectées par la reconstruction de votre raid. Si vous ne pouvez pas vivre avec la dégradation, il faudra que ce soit des bandes miroir.

Si vous optez pour la route Linux, j'utiliserais soit une carte RAID matérielle (avec batterie de secours), soit un contrôleur RAID dans le boîtier du disque. Je suis d'accord que xfs est le système de fichiers de choix sous Linux, mais sachez que les systèmes de fichiers d'environ 50 To sur xfs prennent plus de 16 Go de RAM si vous devez exécuter xfs_check.

Je considérerais sérieusement un bon boîtier NAS tel qu'un NetApp car ils sont beaucoup moins de travail à long terme, cela dépend de la valeur de votre temps / des administrateurs de stockage pour l'entreprise.

Faire fonctionner nfs / samba est un peu un art sombre, allez-vous utiliser de l'éther de 10 Go ou simplement des agrégations de 1 Go / sec? (N'obtenez pas de cartes Broadcomm, en particulier celles de 10 Go).

LVM2 est une évidence, mais n'utilisez pas le snap shotting car il n'est pas rapide.

N'oubliez pas que les sauvegardes de cette opération prendront un certain temps.

Testez la façon dont le système peut échouer avant qu'il ne soit mis en production et faites-le écrire où vous et vos collègues pouvez trouver les documents lorsque tout va mal.


1

Cela dépend de votre rapport lecture / écriture. Nous utilisons beaucoup de boîtiers de disques SAS externes HP MSA70 à 25 disques et les créons toujours comme une seule matrice RAID6 car notre rapport de lecture / écriture est de 99%: 1%, donc nous ne nous soucions pas que R6 soit à peu près le plus lent à écrire ( toujours assez rapide, mais pas très bon par rapport aux autres). De cette façon, nous disposons de 23 disques de données, avons de très bons avantages, comme en TRÈS bons, des avantages de bande passante en lecture aléatoire et en lecture globale et pouvons survivre à deux pannes de disque.

À titre indicatif, une matrice RAID5 ne devrait pas avoir plus d'environ 14 disques dans une même matrice, tandis qu'un RAID6 devrait convenir avec jusqu'à 54 disques environ - évidemment, plus la baie est grande, plus l'écart entre les performances de lecture et d'écriture et le des reconstructions plus lentes prendront mais cela PEUT être un bon compromis.


0

J'ajouterais deux disques de secours pour commencer.

RAID 5 ou 6 est OK pour les lectures aléatoires ou les grandes lectures et écritures séquentielles. Si vous souhaitez obtenir de nombreuses petites écritures, optez pour RAID 10, car RAID 5+ prend un coup 4 x sur les petites écritures.

Si vous souhaitez activer le cache d'écriture, n'oubliez pas de le sauvegarder avec une batterie.

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.