L’offre Red Hat Storage et son intégration avec Hadoop

J’ai eu l’occasion d’être introduit à Red Hat Storage et Gluster lors d’une présentation menée conjointement par Red Hat France et la société StartX. J’ai ici recompilé mes notes, du moins partiellement. Je terminerai pas l’intégration entre Red Hat Storage et Hadoop, plus particulièrement ce qu’on peut en attendre avant de mener une expérimentation en réel.

Inutile de présenter Red Hat. La société StartX, crée en 2003, officie en France et se spécialise dans les produits Red Hat. Elle possède un partenariat avec Red Hat et Amazon.

En 2012, Red Hat annonça l’acquisition de GlusterFS lors du JBoss summit 2012 dans le but de valoriser ce système de stockage distribué dans l’offre plus complète que constitue Red Hat Storage (ci-dessous appelée RH Storage). Précédemment, l’acquisition de Qumranet avait ouvert les portes pour Red Hat au marché de la virtualisation en donnant naissance à l’offre Red Hat Enterprise Virtualization. Le brassage de ces deux offres tournant sous un même cluster unis calcul et stockage sur des composants standards (traduction de la notion de “community hardware”). Notons aussi qu’en 2012, Red Hat fit aussi les acquisitions de FuseSource spécialisé dans l’intégration et les messages et de Polymita spécialisé dans le Business Process Management (BPM).

Calcul et stockage unifié, le tout sur des architectures matérielles à la porté de tous, nous sommes là très proche d’une définition d’Hadoop. Qui plus est, depuis la version 3.3beta, GlusterFS est un stockage compatible Hadoop en remplacement de HDFS.

L’offre RH Storage s’articule autour des pôles suivant: base de connaissance, portail clients & forums, certifications hard et soft, software assurance, service support global, stabilité & cycle de vie jusqu’à 10 ans, mise à jours …

Cloud

Le cloud est aujourd’hui bien en route, en voici les grands axes :

• virtualisation, 48% des apps dans machines virtuelles — Gartner
• banalisation, serveurs x86, réduction des risques autour des mainframes, mais le stockage reste encore honéreux et proprietaire — ESG
• cloudification, tendance à regarder de + en + le cloud, réflexion autour des avantages/inconvenients d’utiliser au moins en partie le cloud sans rupture technologique entre son propre datacenter et celui qui serait dans le cloud — IDG
• explosion — les volumes de données traitées sont en explosion exponentiel — Gartner

RH storage

Sa conception repose sur des objectifs de haute performance et de haute disponibilité. Il ne comporte pas de point de défaillance unique, chaque donnée écrite est redondée sur plusieurs disques et le système lui-même est répliquable sur un autre datacenter.

• Service de fichier unifié avec un point de montage global (traduction de “global namespace”) quelque soit soit le nombre de composants
• Méta-données distribuées selon un algorithme de hashage entre l’ensemble des composants du cluster, il n’a donc pas de point faible unique (traduction de “single point of failure”)
• Système de fichier virtualisé, il est possible de formater les disques sous différents formats
• Évolution lineaire (traduction de “horizontal scalibilité”) par ajout de noeuds (de 2 à 64)
• Volumétrie de plusieurs peta octets validé sur architecture, plus anticipé dans le future
• Interconnection 1GbE et InfinyBand 10GbE (SDR, Single Data Rate) en cours de validation
• Réplication des données en temps réel et géo-réplication en mode asynchronisé sur LAN, WAN internet, possibilité de faire du multi-site cascading

Artchitecture

RH storage est une couche logicielle sans adhérence avec le noyau ou le système sur lequel il évolue. Il s’installe sous Red Hat Enterprice Linux sur des matériels x86 dont le client possède la propriété. Il est conçu de manière entièrement distribuée et redondante. De plus, Gluster dont il est issu est un produit mature.

Le système peut être mise en place sur un cloud tel que celui-ci d’Amazon ou bien sur un cluster local. L’offre est intégrable dans un système virtualisé sur Red Hat Virtualisation et sera prochainement supporté sur VMware vSphere.

Il est conçu pour gérer de 2 à 64 noeuds, chaque noeud étant un serveur standard disponible sur le marché à moindre coût. Par exemple, à la date de cet article, la recommandation s’orienterait vers des serveurs 2 sockets de 4 à 6 coeurs et une mémoire d’environ 32 GB ou 48GB pour un HPC. Dans l’offre RH Storage, les disques doivent être formaté en XFS mais d’autres systèmes de fichiers sont utilisables. C’est en se sens que le système de fichier est dit virtualisé, il se positionne à un niveau au dessus du système de fichier gérant le disque.

Les cas d’utilisation d’une telle infrastructure peuvent par exemple être l’archivage de données enrichies par un environnement de fichiers objets ou encore une environnement High Performance Computing (HPC) capable d’adresser ses besoins avec de l’infiny band.

Le système se gère depuis une ligne de commande ou au travers d’une interface Web simple d’utilisation mais implémentant partiellement l’ensemble des outils.

La souscription de l’offre se fait par multiple de 2 noeuds.

Le stockage hétérogène (en anglais tearing) n’est pas encore présent (sauf ajout/création manuelle d’un “translator”), mais l’idee fait son chemin.

Feuille de route

Les prochaines évolutions sont attendues pour les environs du mois de mars 2013. Parmi celles-ci: volume snapshotting, rhs-C full support (console), nfsv4 support, smb 2.1 support.

Connection

Le plus simple est l’utilisation d’un montage NFS mais celui-ci implique l’interrogation du cluster pour faire tourner l’algorythm de hash qui localisera les données. En terme de performance, il est souhaitable d’utiliser un client Gluster, plus intelligent car il réalise le hashing en local.

Mots clés

• brick, répertoire monté sur le node au format XFS (disques groupé en raid)
• client, Gluster, CIFS, NFS
• server, hébergeur des briques
• subvolume, ensemble de brick formatée pour un volume
• volume, ensemble présenté comme un point de montage unique

Stratégie

• Distributed, distribution homogène et équitable
• Replicated, continuité de service au travers d’une adresse virtuelle si un noeud tombe ou part en maintenance
• striped, pouvoir utiliser différentes briques de différents noeuds en coupant les fichiers (pour multiplier les accès concurrents sur un même fichier large), similaire à la notion de chunk dans Hadoop HDFS
• mixage, distributed striped, distributed replicated, …

Exemple

Note, les notes de cette section restent à dégrossir.

Sur amazone, Red Hat fourni une image toute prête pour amazon mais peut bien sur etre recree manuellement 1 noeud console — image m1 medium — ram 4go (jboss consome) — Red Hat enterprise 6.3 4 noeuds Gluster — image m1 small — ram 1.7 go — Red Hat enterprise 6.2 utilisation des elastic ip en mode produciotn et amener la resolution de nom sur cette ip si montage NFS, utiliser le mechanisme d’IP flottante pour eviter le single point of failure sur l’addressage.

system
 -> clusters
    -> Europe
       -> servers
          -> node1
          -> node2
       -> volumes
          -> data1
    -> US
       -> servers
       -> volumes

le volume data1 est repliqué sur les briques n1_b1 et n2_b1 respectivement sur les nodes 1 et 2 le cluster us est architecturé de la meme manière nfs -> node1.eu.glluster.toto.fr:/data1 on /var/data type nfs (rw,vers=3,addr=10.208.23.48) ce volume correspond à la taille de chaque brique (10Go ds cet exemple) La création des briques ce fait manuellement au préalable en ligne de commande. L’interface graphique est encore en beta et ne permet pas toutes les visualations et opérations. Dans Amazone, pour chaque instance il faut aller dans volume, créer un nouveau volumne (eg tagle 10tb ou 50gb) et l’attacher à l’instance crée, se connecter au noeud et le disque a éte ajouter et un en fait un PV (physical volume) ou LV (logical volume) et finalement on crée une brique

objectifs -> cloud, virtualisation (dont VMware) et l’aspect bigdata dont hadoop

hadoop

Gluster a été développé dans sa version actuelle pour travailler conjointement avec Hadoop. Mais le plus intéressant n’est pas sa faculté de s’interfacer avec Hadoop mais la possibilité qu’il a de s’intercaler comme module de stockage dans Hadoop, remplaçant ainsi le natif HDFS. De plus, mais j’aurai ici besoin de plus ample précisions pour en tirer des conclusions, il m’a été dit que RH Storage embarquait nativement des composants Map/Reduce.

Les performances seraient similaires à celles d’HDFS. Notons que la limitation d’HDFS ne se situe pas au niveau de ses performances. Ce qu’une alternative comme Gluster peut apporter de plus est la conformité avec POSIX (Portable Operating System Interface, ), la distribution homogène et équitable des données sans adressage centralisé, la géo-réplication et encore la simplification de l’utilisation d’Hadoop dans un environnement virtualisé.

Originally published at Adaltas.