Comparaison de différents FS Distribués : HDFS – GlusterFS – Ceph

comparateur

Comparaison des différents FileSystem Distribués : HDFS – GlusterFS – Ceph

Cette comparaison se fera tant au niveau des fonctionnalités que des capacités en lecture et écriture.
Les tests ne sont pas faits par mes soins, mais par différentes sources externes (ne disposant pas de suffisamment de matériel).

Source :

https://hal.inria.fr/file/index/docid/789086/filename/a_survey_of_dfs.pdf
http://iopscience.iop.org/1742-6596/513/4/042014/pdf/1742-6596_513_4_042014.pdf

Rappel des fonctionnalités de chaque D-FS

Bref rappel des fonctionnalités et mode de fonctionnement de chacun des D-FS.

Hadoop Distributed FS

HDFS est implémenté et maintenu par l’Apache Foundation.
HDFS est utilisé par : Yahoo!, Microsoft, LinkedIn, Facebook, …

HDFS est basé sur une architecture Client/Server. Le « NameNode » est le serveur maître qui gère le FS et régule les accès aux fichiers pour les clients.
Le « NameNode » peut être mis en HA (High Availability) dans une configuration Actif/Passif partageant les Metadata en NFS pour disposer de failover.

HDFS est conçu pour stocker de façon fiable de très gros fichiers dans un grand cluster. Il stocke les fichiers en mode block sur les « DataNodes ».
La taille des blocks est configurable (jusqu’à 1Go) via le paramètre dfs.blocksize. Chaque block est répliqué autant de fois que spécifié par la configuration (dfs.replication) en accord avec la police de placement de réplication du « NameNode ».
Pour être fiable, le « NameNode » a besoin de connaitre la topologie du cluster, et la relation noeud-rack, pour pouvoir placer les blocks sur les « DataNodes » en fonction de la police de réplication.
On écrit la donnée sur un « DataNode », elle est répliquée sur un « DataNode » du même rack, puis sur un « DataNode » d’un autre rack distant (de préférence un autre site) et encore sur un autre « DataNode » de ce même rack distant (avec le taux de réplication à 3).
Le système résiste aux fautes sur un « DataNode », sur un rack complet, voir sur un site.
Après la mise en erreur d’un « DataNode », le « NameNode » programme automatiquement une réplication des blocks stockés sur ce « DataNode ». Si le « DataNode » revient à la vie, les blocks sont marqués comme sur-répliqués, ils seront effacés pour retrouver la configuration optimale.

HDFS n’est pas POSIX mais supporte tout de même une couche FUSE-DFS lui permettant des montages en ‘userspace’. Beaucoup d’opérations sont supportées (cp, ls more, cat, find, less, rm, mkdir, mv, rmdir). Cependant du fait que ce ne soit pas POSIX toutes les données du FS ne sont pas disponibles.
Un simple « ls -lart » ne fonctionnera pas forcement correctement.

GlusterFS

GlusterFS est maintenant une acquisition : Red Hat.
GlusterFS est utilisé par : Amazon, Red Hat, …
GlusterFS est dockerizé (image docker disponible pour créer des noeuds), GlusteFS supporte la virtualisation des datastores de KVM et de RHEV.

GlusterFS permet, en ayant plusieurs volumes sur différents serveurs, la construction d’un FS distribué et répliqué via le réseau, conforme POSIX, il supporte aussi les nouveaux modèles de stockage comme le stockage d’Objets ainsi que le stockage de blocks.

GlusterFS met ses données des Filesystem stables et éprouvés, supportés par l’ensemble des kernel Unix comme EXT4 / XFS / …; il n’utilise pas de serveur de Metadata, il utilise à la place une clef de hash unique pour chaque fichier, stocké à l’intérieur même de GlusterFS.

 Dans la terminologie Gluster, un volume est un partage hébergé par les serveurs portant le FileSystem (ext4, …) et dans lequel les données seront placées et montré au clientt. Chaque volume peut être construit par un ensemble de sous-volumes, généralement hébergés par différents serveurs.
Un sous-volume est construit par une « brick », le FS de stockage attribué au volume, traité par au moins un translator. Un translator se connecte à au moins un sous-volume, travaille dessus et offre une connexion à ces sous-volumes.

Avec ces concepts il est possible d’avoir plusieurs type de mode différents :

  • mode « Distribué », répartition des données sur le volume, permet de profiter de plusieurs bricks et axe d’écriture (RAID 0?).
  • mode « Répliqué », chaque élément écrit sur une brick est répliqué N fois sur d’autres bricks sur des noeuds du cluster. Avec 2 en facteur de réplication on obtient une sorte de RAID 1.
  • mode « Striped », chaque élément est éclaté N fois sur différentes bricks du cluster. Une sorte de RAID 5 mais sans parité, donc à éviter.

Il est possible de mélanger ces différents modes, pour faire :

  • mode « Distribué » + « Répliqué », ce qui permet d’avoir une distribution répliquée des données, en quelque sorte un RAID 10
  • mode « Répliqué » + « Stripped », une sorte de RAID 51, qui s’écurise le mode Striped.

Ceph

Article précédent sur Ceph : ToBeDone

Ceph est supporté par : Inktank

Ceph est modélisé pour supporter les différents stockages : block, object, file. Ceph a pour but la performance, la fiabilité sans « SPOF » (single point of failure), tolérant aux pannes et évolutif.
Ceph fournit un accès continu aux objets via RADOS gateway, une interface RESTful compatible avec les applications écrites pour Amazon S3 et Open Stack Swift.
Les RBD (RADOS Block Device) Ceph fournissent un accès aux blocks éclatés et répliqués sur l’ensemble du cluster de stockage.
Certain Cloud IaaS (OpenStack, CloudStack) supporte Ceph comme fournisseur de solution de gestion de blocks.

Ceph fournit aussi une interface POSIX appelé CephFS utilisant un driver natif du kernel linux ou FUSE au choix.
Ceph est composé de trois types de daemon :

  • OSD (Object Storage Daemon, stocke les objets sur les FS locaux et en donne l’accès via le réseau
  • MON (Monitor) qui maintient un schéma de l’état du cluster
  • MDS (MetaData Server) qui stocke les metadata de CephFS.

Pour éviter les « SPOF » et l’évolutivité, un cluster Ceph doit contenir plusieurs de chacun de ces types de nœuds. Les MON doivent être en nombre pair pour créer un « quorum ».
Ceph utilise l’algorithme CRUSH (Controlled Replication Under Scalable Hashing). L’algorithme calcul le groupe où placer des objets et quel OSD contiendra le groupe.
L’algorithme CRUSH permet d’évoluer, de rééquilibrer la charge et de récupérer dynamiquement.
Avec Ceph il est possible de définir des domaines de pannes au niveau : disque, serveur, rack. Ceci permettra à CRUSH de gérer les différents serveurs et disks et de créer des règles pour la réplication.

Tableau comparatif fonctionnel

HDFS vs Ceph vs GlusterFS – Fonctionnalités HDFS Ceph (0.70) GlusterFS (3.4)
Architecture Centralisée Distribuée Décentralisée
Gestion des Nom Index CRUSH EHA
API CLI, FUSE, REST, API FUSE, mount, REST FUSE, mount
Détection des pannes Connexion Complète Connexion Complète Détéctée
Disponibilité Système Pas de Failover (natif) Haute Haute
Disponibilité de la donnée Réplication Réplication Comme du RAID
Stratégie de répartition Automatique Automatique Manuel
Réplication Asynchrone Synchrone Synchrone
Consistance du Cache WORM, lease Lock icon
Load Balancing Automatique Manuel Manuel

Tableau comparatif des performances

Utilisation de IOzone

IOzone est un outil de benchmark pour FS POSIX.

Avec

  • -r 128k : taille de champs à 128k
  • -i 0 -i 1 -i 2 : test à exécuter, 0=write/rewrite, 1=read/re-read, 2=random-read/write
  • -t 24 : nombre de threads simultanés utilisés
  • -s 10G : Taille du fichier test, ici 10 Go

Vu que HDFS n’est pas complétement POSIX, tous les tests faits avec IOzone ne sont pas fonctionnels.
De même il existe des bugs au niveau driver kernel pour CephFS.

HDFS vs Ceph vs GlusterFS – IOzone – Mo/s HDFS Ceph (0.70) GlusterFS (3.4)
Ecriture Initiale 239.72 51.06 306.34
Re-Ecriture icon 60.05 406.90
Ecriture Aléatiore icon 7.0 406.33
Lecture 155.18 101.58 688.06
Re-Lecture 151.33 133.61 711.46
Lecture Aléatoire 29.06 12.05 284.00

Utilisation de la commande dd

dd est une simple commande lisant et écrivant des blocs depuis et sur différentes sources. dd n’est pas multithread, il suffit de lancer 24 fois dd simultanément pour obtenir un résultat équivalent.

Pour l’écriture :

Pour la lecture :

Avec

  • if : pour « input file », fichier d’entré
  • of : pour « ouput file », fichier de sortie
  • bs : quantité de données de buffer de lecture/écriture, ici 4Mo
  • conv=fdatasync : demande à dd de faire une synchronisation complète avant de sortir.
HDFS vs Ceph vs GlusterFS – DD- Mo/s HDFS Ceph (0.70) GlusterFS (3.3)
Ecriture 220.05 126.91 427.3
Lecture 275.27 64.71 268.57

Utilisation de fichier de taille fixe avec « cp » vers ou depuis le D-FS

Ici des fichiers de taille fixe sont utilisés. Ils sont copiés vers les FS Distribué (Ecriture) ou copiés depuis de FS Distribué (Lecture).

HDFS vs Ceph vs GlusterFS – COPY – En secondes HDFS Ceph (0.70) GlusterFS (3.3)
Ecriture – 1 x 20 Go 407 419 341
Lecture – 1 x 20 Go 401 382 403
Ecriture – 1000 x 1Mo 72 76 59
Lecture – 1000 x 1Mo 17 21 18

Tableau d’aide à la décision

Un fichier d’aide à la décision (à modifier selon les besoins) : PDEC – DFS

4 thoughts on “Comparaison de différents FS Distribués : HDFS – GlusterFS – Ceph”

  1. Bonjour,

    Ceph (versions infernalis & hammer) n’est pour l’instant pas assez stable :
    la commande « ceph-deploy osd prepare » ne fonctionne pas systématiquement.

    Donc, pour l’instant j’attends les fixes et je vais tenter de les contacter pour décrire ces bugs.

  2. Salut, c’est un article interessant, par contre tu parles pour CEPH de quorum et donc de MON pairs, tu dois vouloir dire impair…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

six − 4 =