https://conf-ng.jres.org/2013/article_134.html

Proposition refusée

Déployer une infrastructure de stockage distribué OpenSource¶

Aux Journées Réseaux de 2011, E. Quemener vous présentait « Stockage dans les laboratoires : quels besoins pour quelles solutions ? ». Aujourd'hui, nous vous proposons de découvrir quelle solution a été retenue et déployée pour répondre à cette problématique. En premier lieu, redéfinissons le contexte : L'Ecole Normale Supérieure de Lyon est un nouvel établissement issu de la fusion, en 2010, des deux Écoles Normales Supérieures lyonnaises (ENS Lyon et ENS Lettres et Sciences Humaines), puis de l'intégration, en 2011, de l'Institut National de la Recherche Pédagogique. Chaque établissement disposait ainsi d'une infrastructure et d'une politique de stockage différente, mais tous avaient un point commun : l'utilisation de solution SAN « propriétaire ». Notre mission : harmoniser le stockage, répondre aux fortes demandes volumétriques, fournir aux services de l’Ecole et aux unités de recherche des volumes de stockage de protocole iSCSI, réduire les coûts de fonctionnement et de maintenance logiciels et matériels »

L'attrait des SAN propriétaires repose principalement sur les fonctionnalités classiques telles que la prise d’instantanés, la déduplication et la réplication des volumes. L'étude de Recherche et Développement que nous avons menée démontre que le coût de ces solutions est principalement associé à l'intelligence logicielle embarquée. Après avoir identifié ces coûts, de nombreuses interrogations sont apparues : Quelle est l'intelligence logicielle ? Est-elle d'origine propriétaire ? Existe-t-elle sur la terre promise de l'OpenSource ? La réponse se trouvait là sous nous yeux, il n'y avait qu'à prononcer la formule magique « SAN Propriétaire, Ouvres Toi !! (ou je sors le pied de biche) » et ZFS arriva ! Mais tout n’était malheureusement pas aussi simple. Car ZFS fût développé par Sun pour Solaris. Nos partenaires Sun et FreeBSD ne nous ont que trop souvent raconté les exploits de ce fabuleux système de fichiers. Cependant notre parc serveurs étant principalement issu de la branche GNU/Linux, nous ne pouvions qu’attendre et espérer un éventuel portage. En 2010, le Lawrence Livermore National Laboratory, qui emploie Brian Behlendorf (principal développeur), et le Department of Energy (DOE) des États-Unis, entreprennent de stabiliser le portage de ZFS natif pour Linux, avec succès (certainement pour les mêmes besoins de rationalisation et de réduction des coûts).

Nous avions l'intelligence, mais il restait à trouver le corps. Un corps matériel assez robuste pour accueillir et exploiter au mieux les capacités de ZFS. Après divers échecs, nous avons trouvé la formule pour créer le réceptacle adéquat. La stabilité tenant d'un savant dosage de CPU, de mémoire, de disques, d'interfaces réseau, et de Debian GNU/Linux. Il ne restait plus qu'à greffer ZFS on Linux dans ce corps inerte :

- Compilation des modules ZFS [OK] !
- Activation des modules ZFS [OK] !
- Création des volumes ZFS [OK] !
- Export en mode bloc [OK] !
- Activation des prises d'instantanés [OK] !
- Activation des fonctions de déduplication [OK] !

Notre SAN OpenSource était vivant. Mais nous devons impérativement valider ses capacités dans ce nouveau corps. Contrairement à la majorité des infrastructures déployées reposant sur ce système et exportant du NFS, nous avons choisi ZFS pour ses capacités à fournir et à gérer des volumes en mode bloc. Ce volume bloc est ensuite offert en iSCSI sur des machines dédiées, jouant à leur tour le rôle de serveurs de fichiers. Tous les tests de charges, de redondance, de simulations de pannes y sont passés, avec succès ! Qualifié, notre SAN ZFS est alors mis en service, pour faire ce à quoi il est destiné : stocker d'importantes volumétries de données (à ce jour : 108 To bruts dans 8 unités d'espace rack).

Certes, à ses débuts, cette solution nous a demandé beaucoup d'attention (métrologie de la performance, de la stabilité, script de gestion des volumes). Aujourd'hui, elle présente l'avantage de ne pas nous surfacturer ses améliorations et sa maintenance logicielle. De plus, sa conception (matériel et intelligence logicielle sont indépendants l'un de l'autre) lui confère l'appréciable capacité de pouvoir évoluer dans les contraintes budgétaires actuelles. Notre satisfaction est telle que nous avons décidé de poursuivre dans cette stratégie de remplacement de SAN propriétaire. En tenant compte des erreurs que nous avions commis lors de la version 1.0, nous avons amélioré nos choix matériels. Au final, ce deuxième SAN ZFS est plus dense et plus capacitif (6U pour 240 To bruts). Il est également plus rapide, plus évolutif et plus performant.
Activation de la réplication des volumes entre deux SAN [OK] !
Mission accomplie ! Et l'harmonisation du stockage ?
Extinction progressive des SAN Propriétaires [OK] !

Il reste néanmoins plusieurs zones d'ombre à clarifier ? Quid de la pérennité de ZFS depuis le rachat de Sun par Oracle ? ZFS est-elle la seule intelligence Open Source capable de répondre aux problématiques des SAN ? Des informateurs nous ont vantés les mérites d’un système de fichiers nommé BTRFS, mais celui-ci est encore à l’état expérimental : à quand une véritable comparaison ?

Nous avons créé notre infrastructure de stockage basée sur une solution SAN OpenSource ! Et vous ?