150 To et en croissance, mais comment grandir?

Mon groupe possède actuellement deux serveurs de stockage de grande taille, les deux NAS exécutant Debian Linux. Le premier est un serveur tout-en-un à 24 disques (SATA) vieux de plusieurs années. Nous avons deux RAIDS matériels installés avec LVM sur ceux-ci. Le deuxième serveur est constitué de 64 disques répartis sur 4 boîtiers, chacun un RAID 6 matériel, connecté via SAS externe. Nous utilisons XFS avec LVM pour créer un stockage utilisable de 100 To. Tout cela fonctionne plutôt bien, mais nous dépassons ces systèmes. Ayant construit deux de ces serveurs et continuant de croître, nous voulons construire quelque chose qui nous permet plus de flexibilité en termes de croissance future, d'options de sauvegarde, qui se comporte mieux en cas de défaillance du disque (la vérification du système de fichiers plus volumineux peut prendre un jour ou plus) et peut rester dans un environnement fortement concurrent (pensez à un petit cluster informatique). Nous n'avons pas de support d'administration système,

Donc, ce que nous recherchons, c'est une solution de stockage de performance acceptable et relativement peu coûteuse qui permettra une croissance future et une configuration flexible (pensez à ZFS avec différents pools ayant des caractéristiques de fonctionnement différentes). Nous sommes probablement en dehors du domaine d'un seul NAS. Nous avons pensé à une combinaison de ZFS (sur openindiana, par exemple) ou de btrfs par serveur avec des glusterfs en plus si nous le faisons nous-mêmes. Ce contre quoi nous pesons, c'est simplement de mordre la balle et d'investir dans des solutions de stockage Isilon ou 3Par.

Toutes suggestions ou expériences sont appréciées.

J'espère que ça va aider un peu. J'ai essayé de ne pas le laisser se transformer en un mur de texte complet. :)

3Par / Isilon

Si vous pouvez et allez consacrer une quantité fixe d'heures-homme à quelqu'un qui prend le rôle d'administrateur SAN et qui veut profiter d'une vie sans douleur avec un sommeil nocturne au lieu d'un travail de nuit, alors c'est comme ça que j'irais.

Un SAN vous permet de faire toutes les choses où un seul "stockage" vous limiterait (c'est-à-dire de connecter une baie flash de purestorage et un gros monstre sata 3par au même serveur), mais vous devez également le payer et le garder bien entretenu. le temps si vous voulez profiter de la flexibilité.

Alternatives

Amplidata

Avantages: évolutif, bon marché, conçu avec un concept agréable et des couches de cache de lecture / écriture dédiées. Cela pourrait être la meilleure chose pour vous.

RisingTideOS

Leur logiciel cible est maintenant utilisé dans presque tous les stockages Linux et il permet une gestion un peu meilleure que les choses simples Linux / Gluster. (À mon humble avis) La version commerciale pourrait valoir le coup d'œil.

Gluster / btrfs

PRO: Scales out et "Bricks" vous donnent une couche d'abstraction qui est très bonne pour la gestion.

CON: Le premier a été un PITA total pour moi. Il n'était pas robuste et les pannes pouvaient être soit locales à une brique, soit tout supprimer. Maintenant, avec RedHat sous contrôle, cela pourrait en fait se transformer en quelque chose qui fonctionne et j'ai même rencontré des gens qui peuvent l' apprivoiser pour que cela fonctionne pendant des années. Et le second est encore à moitié expérimental. Normalement, un FS a besoin de 3 à 4 ans après avoir été "terminé" jusqu'à ce qu'il soit éprouvé et robuste. Si vous vous souciez des données, pourquoi envisageriez-vous cela? En ce qui concerne le support commercial expérimental de Ceph est presque sorti maintenant, mais vous devez vous en tenir à la couche "RBD", le FS n'est tout simplement pas encore suffisamment testé. Je tiens à préciser que Ceph est beaucoup plus attrayant à long terme. :)

ZFS

Pro: fonctionnalités qui mettent définitivement un clou dans le cercueil d'autres choses. Ces fonctionnalités sont bien conçues (pensez L2ARC) et la compression / déduplication est amusante. Avoir plus de «grappes de stockage», ce qui signifie qu'il n'y a également que de petites défaillances au lieu d'un grand boom consolidé

Inconvénient: maintenir de nombreuses petites boîtes logicielles au lieu d'un véritable stockage. Besoin de les intégrer et de dépenser $$$ heures pour avoir une configuration robuste.

La route XFS + LVM est en effet l'une des meilleures options pour une solution de stockage purement Linux évolutive au cours des dernières années. Je suis encouragé que vous y soyez déjà. Maintenant que vous avez besoin de vous développer davantage, vous disposez de quelques options supplémentaires.

Comme vous le savez, les grands fournisseurs de matériel ont des têtes NAS pour leur stockage. Cela vous donnerait en effet un seul fournisseur pour travailler avec tout cela, et cela fonctionnerait plutôt bien. Ce sont des solutions faciles à intégrer (par rapport au bricolage), et leur maintenabilité est plus faible. Mais, ils coûtent beaucoup. D'une part, vous aurez plus de ressources d'ingénierie pour résoudre vos principaux problèmes plutôt que des problèmes d'infrastructure; D'un autre côté, si vous êtes comme la plupart des départements universitaires que je connais, la main-d'œuvre est vraiment bon marché par rapport au paiement en espèces.

En allant sur la route du bricolage, vous avez déjà une bonne appréciation des options de bricolage qui s'offrent à vous. ZFS / BTRFS sont le chemin de mise à niveau évident de XFS + LVM pour un stockage évolutif. J'éviterais BTRFS jusqu'à ce qu'il soit déclaré `` stable '' dans le noyau Linux principal, ce qui devrait être très bientôt maintenant que plusieurs des principales distributions gratuites l'utilisent comme système de fichiers par défaut. Pour ZFS, je recommanderais d'utiliser une base BSD plutôt que OpenIndiana simplement parce qu'elle existe depuis plus longtemps et que les plis (plus) ont été résolus.

Gluster a été conçu pour le cas d'utilisation que vous décrivez ici. Il peut faire de la réplication et présenter un seul serveur virtuel avec beaucoup de stockage attaché. Leurs volumes distribués sonnent exactement ce que vous recherchez, car ils répartissent les fichiers sur tous les serveurs de stockage sur le volume déclaré. Vous pouvez continuer à ajouter des serveurs de stockage discrets pour continuer à étendre le volume visible. Espace de nom unique!

Le problème avec Gluster est qu'il fonctionne mieux lorsque vos clients peuvent utiliser le client Gluster pour accéder au système plutôt que les options CIFS ou NFS. Puisque vous exécutez un petit cluster de calcul de cluster, vous pouvez peut-être simplement utiliser le client GlusterFS.

Vous êtes sur la bonne voie ici.

Autant que je sache, vous pouvez utiliser une solution SAN basée sur Linux SCST + FibreChannel ou infiniband, ce qui est quelque chose que je construis en ce moment. Comme base pour les LUN, vous pouvez utiliser LVM au-dessus des RAID matériels et prendre en charge les instantanés / réplication (prenez DRBD comme exemple) sous le niveau du système de fichiers. En tant que système de fichiers, je ne connais aucune bonne solution pour la concordance car je mets ESXi au-dessus des nœuds, donc les banques de données sont gérées par ESX FS simultané. Je pense que GFS2 pourrait fonctionner avec cet environnement, mais je ne suis pas sûr à 100%, car vous devriez vérifier vos besoins précis. Quoi qu'il en soit, une fois que vous avez un SAN robuste sous vos nœuds, il est assez facile de faire avancer les choses.