10 votes

Ajout d'une capacité de stockage de 60 To à un serveur SLES 10

Je dois ajouter des archives \staging sur un serveur SLES 10. Il s'agit de présenter des volumes assez importants (9-20 To chacun environ, 60 To au total) qui seront utilisés pour stocker des données d'archives (littéralement, il s'agit d'une bibliothèque) comprenant de gros fichiers images (Tiff's de 150 Mo pour la plupart) et de gros fichiers tarballs. Les données seront très majoritairement orientées vers la lecture IO, certainement >95% et probablement plus de 99%.

Le stockage a déjà été acheté - une baie Dell MD3000 SAS en guirlande avec 2 MD1000 entièrement remplis de disques SATA de 2 To à 7200 tr/min, soit 45 disques au total. La pile de baies est connectée à l'aide de deux adaptateurs SAS externes à double port, ce qui signifie qu'il y a 4 chemins d'accès à la pile.

J'ai l'intention de les configurer comme un ensemble de 4 volumes assis sur 4 groupes RAID avec un hot spare par réseau. Tous les groupes seront RAID 6 avec 7 ou 14 disques, et chaque groupe RAID sera présenté comme un LUN unique utilisant toute la capacité de ce groupe. Du côté de SLES, ces volumes doivent être formatés en tant que volumes XFS.

J'ai une expérience limitée de SLES (et de Linux en général) et je suis à la recherche de recommandations à ce sujet :

  1. Y a-t-il des éléments spécifiques à prendre en compte lors de la configuration de volumes XFS de cette taille sous SLES 10, c'est-à-dire que les paramètres par défaut seront-ils corrects compte tenu du profil IO ?
  2. Quelle est la meilleure façon d'initialiser \partition\format Ceux-ci ? J'ai utilisé Parted pour définir une étiquette de disque et YAST Partition Manager (en acceptant toutes les valeurs par défaut) pour créer et formater le volume XFS pour mon test initial.
  3. Comment configurer le multipathing ? Lorsque je présente un volume de test initial, il apparaît comme quatre périphériques distincts (/dev/sdl,/dev/sdm,/dev/sdn et /dev/sdn). Que dois-je faire pour travailler avec ce volume en tant que volume unique ?
  4. Lors de mes premiers tests, j'ai constaté des taux de transfert d'environ 30 mégaoctets par seconde à partir d'un volume SAN EMC Clariion existant. C'est beaucoup moins que ce à quoi je m'attendais, même en tenant compte de la pénalité d'écriture du RAID 6, je m'attendais à quelque chose de l'ordre de 70 à 100 Mégaoctets/seconde.
  5. Comment puis-je savoir si tout va bien ? Où dois-je chercher les erreurs ? \warnings etc ? L'éditeur de partition YAST met très longtemps à se lancer par exemple et j'aimerais comprendre pourquoi.
  6. Pourriez-vous partitionner cela différemment et \or utilise-t-il un autre système de fichiers et, dans l'affirmative, pourquoi ?

Le serveur est un Dell 2950 - je n'ai pas vérifié les spécifications détaillées, mais le top indique une utilisation de l'ordre d'un chiffre tout au plus.

4voto

3dinfluence Points 12361

Dans mon précédent emploi, nous avions un problème similaire. Nous réalisions des productions pour des planétariums et chaque image était de 64 mégapixels. Beaucoup de grandes images. Celles-ci étaient traitées pour chaque théâtre dans le cadre d'une opération de lecture très agressive sur une grappe d'ordinateurs.

Dans ce cas, le serveur avait une configuration de stockage similaire. Plusieurs matrices RAID externes à connexion directe. Chacune d'entre elles était constituée de volumes RAID6 exposés à l'hôte et ajoutés à un VG (Volume Group) sous LVM (Logical Volume Manager). Chaque émission/production disposait alors de son propre LV (Logical Volume), formaté en XFS, que nous développions au fur et à mesure des besoins du projet.

Si vos ensembles de données sont plutôt statiques ou s'accroissent de manière prévisible, cette approche devrait vous convenir. Mais attention, cette approche a un inconvénient. Vous finissez par devoir micro-gérer les LV sur votre stockage. Certains administrateurs préfèrent cette approche, tandis que d'autres essaient de l'éviter. Mais cela vous permet de faire croître chaque LV et système de fichiers XFS au fur et à mesure que l'ensemble de données s'accroît. Gardez vos volumes XFS aussi petits que possible afin de ne pas vous retrouver avec un fsck qui prend des années à se terminer. Et peut servir de contrôle des dommages en cas de défaillance d'un système de fichiers.

Avertissement : Si je devais mettre cela en place aujourd'hui, j'utiliserais OpenSolaris et ZFS. Principalement parce qu'il évite les problèmes de micro-gestion et qu'il est un système de fichiers/gestionnaire de volumes supérieur. Vous pouvez donc également jeter un coup d'œil à ce système.

4voto

Chopper3 Points 99341

Je serais bien plus enclin à acheter plus de disques et à les mettre en RAID 10.

J'ai rencontré d'horribles problèmes avec des centaines de disques FATA (fibre-attached SATA) de 1 To que nous avons achetés il y a quelque temps. Ils coûtent 1 000 £ chacun et je perds 5 % par mois ! En fait, ils ne sont tout simplement pas conçus pour un cycle de travail 24x7 et le fait que vous puissiez avoir les mêmes problèmes est la raison pour laquelle je recommande le R10.

Le RAID6 est un pas dans la bonne direction, mais si vous en avez la possibilité, je laisserais au moins un disque de côté comme hot-spare - si un disque tombe en panne n'importe où sur votre réseau, il se mettra en marche et fera du stripping en attendant que vous remplaciez le disque défectueux. À ce sujet, assurez-vous d'avoir au moins 2 ou 3 disques de rechange sur site, prêts à être remplacés, et assurez-vous également d'avoir mis en place toutes les alertes nécessaires pour vous avertir en cas de problème, 24 heures sur 24 et 7 jours sur 7.

En ce qui concerne les performances, ces disques de 2 Go ne sont pas si mauvais que ça pour un disque de 7,2 Ko et la technologie SAS peut être très rapide. Je m'attends donc à 70 Mo/s pour les lectures séquentielles que vous avez mentionnées - évidemment, les lectures aléatoires et les écritures seront assez faibles.

Désolé si je semble négatif, cela fait des années que je me bats avec le stockage et je ne peux dormir facilement qu'avec des systèmes de disques d'entreprise - j'ai tout simplement fait trop de quarts de travail de 48/72 heures pour réparer des équipements bas de gamme.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X