Les clés pour choisir un système de stockage distribué

L’évolutivité 

L’une des raisons pour lesquelles on choisit un système de stockage distribué est son aptitude à évoluer beaucoup plus simplement qu’un système de stockage monolithique. La capacité n’est plus contrainte par le maximum de disques supportés par une baie et les performances sont censées s’accroître plus ou moins linéairement avec le nombre de nœuds. Avant de faire son choix, il est toutefois essentiel de tester si le système se comporte tel qu’annoncé lorsque l’on ajoute ou retire des nœuds. Les points importants à évaluer sont les suivants.

• Granularité : L’intérêt d’un système de stockage distribué est son aptitude à accueillir des nœuds additionnels. Mais tous les systèmes de fichiers n’ont pas les mêmes attributs. Certains contraignent les nœuds à être homogènes (CPU et disques identiques), tandis que d’autres autorisent l’insertion de nœuds ayant des caractéristiques de stockage très différentes. Pour un système hyperconvergé, l’aptitude à supporter des configurations asymétriques est essentielle. Cela permet en effet de faire évoluer dans des dimensions différentes la capacité et les performances de calcul. Il est aussi à noter que certains systèmes permettent de faire évoluer la capacité interne d’un nœud (par exemple de commencer avec quelques disques dans un serveur puis d’en ajouter d’autres) alors que d’autres posent des limites importantes à l’évolution interne de la capacité d’un nœud.

• Simplicité d’insertion et retrait d’un nœud du cluster : L’idéal est la détection automatique par le cluster existant de l’insertion d’un nouveau nœud sur le réseau. C’est l’une des forces des systèmes de fichiers distribués des solutions hyperconvergées. Certains systèmes requièrent toutefois des commandes manuelles pour l’ajout de capacité au cluster existant. Il est aussi important de tester les mécanismes de retrait d’un nœud. Idéalement, le fournisseur doit avoir prévu un mécanisme d’éviction des données d’un nœud sur le point d’être retiré.

• Impact des ajouts et retraits de nœuds sur les performances : Tous les systèmes de stockage incorporent des mécanismes automatisés de redistribution des données et des métadonnées en cas d’ajout de nœud ou de retrait d’un nœud. Il est important d’évaluer l’impact des opérations d’ajout et de retrait de nœuds sur la performance du cluster. Les opérations de redistribution de données et de métadonnées consomment en effet du CPU et de la bande passante sur le cluster. 

La résilience 

Avant de choisir un système de fichiers distribué, que ce soit pour un système autonome, ou pour un système hyperconvergé, il est important d’être informé sur ses caractéristiques en matière de résilience. Les systèmes de fichiers distribués du marché sont loin d’avoir les mêmes caractéristiques, car ils ne servent pas les mêmes besoins. Un système de fichier en cluster optimisé pour un usage hyperconvergé a en effet des contraintes de fonctionnement différentes de celles d’un système de fichiers NAS ou SAN. Quelques points communs doivent toutefois être analysés en détail dans le cadre d’un POC (Proof Of Concept) en testant de multiples configurations et en simulant des pannes. Il est ainsi intéressant, entre autres, de simuler la déconnexion de nœuds du réseau, la déconnexion de contrôleurs, des ruptures d’alimentation de tout ou partie des nœuds, l’extraction de disques (aussi bien des dispositifs utilisés pour le cache, que ceux utilisés pour le stockage persistant), etc. 

• Analyser les mécanismes de gestion des E/S : Tous les systèmes de fichiers distribués modernes permettent de choisir le niveau de protection des données (facteur de réplication ou niveau de parité dans un schéma de type Erasure coding). Il est donc intéressant de bien comprendre le chemin de données pour les lectures et les écritures pour comprendre comment le système de fichiers place les données en fonctions des paramètres critiques comme la localité des données, la performance, la résilience ou l’optimisation de la capacité).
  Il est aussi important de comprendre comment ce chemin de données est affecté par la défaillance d’un composant matériel ou logiciel. Par exemple dans un système hyperconvergé, que se passe-t-il si la VM délivrant les services de stockage aux applications défaille ? Comment sont reroutées les E/S ?
  
  
• Étudier la présence de points de faille : Idéalement, les composants logiciels d’un système de fichier distribué doivent être eux-mêmes distribués afin d’éviter toute présence d’un point unique de faille (ou SPOF, pour Single Point of failure) notamment la gestion des métadonnées doit être distribuée, plutôt que confiée à quelques nœuds. Pour un système de fichiers orienté NAS, il est par exemple important que la gestion de l’espace de nommage soit distribuée. 

• Quels mécanismes sont utilisés pour assurer la résilience et l’intégrité des données : Il faut étudier en détail les mécanismes utilisés pour protéger les données contre les défaillances d’un composant ou d’un nœud (RAID, RAID distribué, Erasure Coding, réplication des données), mais aussi les mécanismes de vérification d’intégrité destinés à protéger les données stockées d’événements comme un bit-flip (corruption silencieuse d’une donnée sur un disque ou un SSD). Un système de fichier moderne doit permettre de définir le niveau de résilience attendu (configuration du facteur de réplication, niveau de parité pour un mécanisme de code à effacement), mais aussi intégrer des mécanismes de checksum avancés pour garantir l’intégrité des données stockées. Si le système permet des déploiements en mode stretched cluster, il faut s’intéresser à la définition des domaines de pannes, à la configuration des serveurs témoins (witness) afin d’éviter les situations de « split brain ».
  
  
• Réactions aux pannes : En cas de défaillance d’un composant ou d’un nœud, le système doit être à même de s’autoreconfigurer sans intervention humaine et d’assurer un rééquilibrage transparent des données et métadonnées sur les nœuds survivants. Il doit aussi autant que possible pouvoir faire la différence entre une panne temporaire (perte momentanée d’alimentation d’un ou plusieurs nœuds) et une panne définitive (si nécessaire via confirmation d’un opérateur). Ce qui peut éviter de lancer un processus coûteux et perturbant de rééquilibrage de l’ensemble du cluster. Un dernier point important à contrôler est le mécanisme de reconstruction de données en cas de défaillance d’un nœud qui doit être aussi parallélisé que possible afin de minimiser l’exposition à une défaillance additionnelle. Le temps de reconstruction des données et métadonnées affectées par une panne doit ainsi être réduit au maximum.

La performance 

Les systèmes de fichiers distribués ayant vocation à remplacer des systèmes SAN ou NAS monolithiques en place, il est important de valider que leur performance satisfera les applications existantes et à venir. Quelques points importants sont à évaluer : 

• Gestion du cache, maintien de la localité des données : Les mécanismes de cache et de gestion de la localité des données sont importants, notamment si des traitements doivent être colocalisés sur les nœuds de stockage. Pour des applications hyperconvergées, le maintien de la localité permet d’éviter d’avoir à aller chercher des données sur d’autres nœuds et donc de garantir une performance optimale (surtout dans des configurations Flash modernes).

• Optimisation du positionnement des données : Certains systèmes de fichiers embarquent des fonctions avancées de placement de données pour garantir des performances optimales. Ils sont par exemple à même de placer dynamiquement des données sur le cluster en fonction de la performance mesurée en temps réel des différents composants du cluster. Par exemple, le système peut être capable de diagnostiquer en temps réel la performance (CPU, disque, etc.) des membres du cluster et de prioriser le placement des données sur les nœuds les mieux à même de servir les requêtes.

• Gestion du réseau : Certains systèmes de fichiers utilisent le même back-end réseau pour servir les requêtes utilisateurs et pour assurer leur fonctionnement interne. D’autres dissocient le réseau utilisé pour le back-end du cluster (celui qui sert pour les échanges entre nœuds) et celui utilisé pour servir les données aux applications. Selon l’architecture utilisée, il est important de veiller à ce que le réseau soit dimensionné pour faire face aux besoins du cluster.

• Gestion de la qualité de service et du tiering : Certains systèmes de fichiers incorporent des mécanismes avancés de QoS (Quality Of Service) et de tiering afin de garantir une performance adaptée à chaque type d’application consommant les ressources de stockage du cluster. D’autres en sont dépourvus. Selon la nature des applications que l’on souhaite déployer, il est donc important de vérifier si le système de stockage distribué est à même de garantir ou non une qualité de service prédictible.

• Processus de tâche de fond du cluster : Périodiquement, les systèmes de fichiers distribués réalisent des opérations de maintenance et d’optimisation (garbage collection, vérification de la cohérence des données, défragmentation du cluster, etc.) Il est important de vérifier que ces opérations, qui consomment des ressources, n’auront pas d’impact sur la performance délivrée aux applications.

La gestion du cloud 

Certains systèmes de stockage distribué permettent aux entreprises de simplifier leur migration vers le cloud ou de basculer des données froides vers le cloud. La première fonction qui a émergé au cours des dernières années est la capacité à déplacer des données froides d’un cluster vers le cloud à des fins de réduction des coûts. Mais plus récemment, on a aussi vu émerger des capacités plus sophistiquées.

Certains systèmes de stockage distribués peuvent ainsi être déployés aussi bien on-premises que sur des infrastructures cloud. Dans certains cas, notamment pour les systèmes de fichiers distribués, il peut même être possible d’avoir un espace de nommage commun entre les installations on-premises et dans le cloud (ce qui dans la pratique permet en fait d’opérer une infrastructure hybride comme un pool unique).

Il est à noter que lorsque les solutions supportent des déploiements hybrides, ce support ouvre la porte à la construction de solutions hautement disponibles. Il est par exemple possible de répliquer des données entre le on-premises et le cloud public ou de bâtir des scénarios avancés de reprise après désastre.