Travail de fin de session. Z-File System. Par Mathieu Schmitt

Transcription

1 Travail de fin de session Z-File System Par Mathieu Schmitt

2 Introduction Toute entreprise qui veut progresser et s implanter durablement sur le marché actuel nécessite une bonne cohésion interne. Les réseaux informatiques et notamment les systèmes distribués contribuent pour une très grande part à cette cohésion, ils constituent l épine dorsale de la communication. Un nouveau paradigme vient bouleverser les habitudes des entreprises sous une dénomination intitulée le cloud computing 1 : l objectif recherché consiste en un transfert de l ensemble de l infrastructure informatique de l entreprise et des services associés vers des serveurs distants. Ce travail de fin de session traite de Z File System 2. Ce système de fichiers open-source fut introduit et développé en 2005 par Sun Microsystem en proposant une capacité de stockage extrêmement haute. Découvrons ci-dessous quelques-uns de ses points forts : système de fichiers 128 bits, intégrité des données, une cohérence des données, une optimisation automatique des performances, une réplication de données en temps réel. Nous présenterons dans ce travail de session tous les points ci-dessus énumérés. Parce qu il élimine le concept de volume, ZFS se démarque des autres systèmes de fichiers : il partage en effet un pool de stockage composé de supports de stockage (disque dur...) inscriptibles. Le résultat n est pas négligeable : ces supports de stockage peuvent être supprimés ou ajoutés en fonction des besoins du système de fichiers. Nous parlons dans ce cas de notion d élasticité, paradigme du concept de cloud computing. 1. Le terme "nuage" pourra aussi être utilisé. 2. abrégé ZFS par la suite i

3 ZFS représente le candidat parfait pour l équipement des datacenter. Notons que l International Data Corporation publia en 2011 une statistique sur le volume de données dans le cloud : "Celui-ci connaît ainsi une croissance exponentielle 1 qui pourrait le faire flirter avec les Exabytes (8000 milliards de Gigabytes!) à l horizon 2015." 3 : Figure 1: Le volume de données dans le cloud en 2015 Par ailleurs, le système de fichiers grandit et diminue en fonction des exigences de ZFS sans avoir à répartitionner des unités de stockage sous-jacentes. Sun microsystem présente ici un principe sécuritaire bien connu : l économie de mécanisme qui consiste à obtenir un design aussi petit et aussi simple que possible. Nous évitons ainsi des erreurs de design et d implémentation qui peuvent contourner les règles de sécurité en condition normale d utilisation. Il intègre d autres fonctionnalités et de ce fait s incorpore aisément dans de grands systèmes distribués. Ce travail de session s articule comme suit : 1. Dans un 1 er temps, nous parlerons des caractéristiques de ZFS. Nous ferons une mise en contexte en expliquant les raisons pour lesquelles les volumes et les systèmes de fichiers existent et quels sont les apports de ZFS. S en suivra une présentation des qualités intrinsèques du système de fichiers, 2. Nous poursuivrons dans le chapitre 2 par la présentation de l architecture de ZFS en exposant les traits saillants qui la composent, 3. Dans une troisième partie, nous présenterons les qualités de ZFS qui extrinsèquement lui permettent de s intégrer sans difficulté dans de grands systèmes répartis comme les datacenters formant le cloud computing volume-de-donnees.shtml ii

4 Table des matières Introduction Table des matières ii iii 1 Caractéristiques techniques Pourquoi les volumes existent-ils? Quels sont les apports de ZFS? Limites théoriques Portabilité Taille des blocs de données variables Administration simplifiée Généralités Exemples Architecture ZFS Généralités Pool de stockage Ensemble de données et la couche de snapshot Couche ZFS Posix Couche de journalisation Volume ZFS Intégration de ZFS dans un environnement en nuage Qu est ce que le cloud computing? Définition Caractéristiques Intégrité des données avec ZFS Généralités Copy-On-Write ZFS pour la haute disponibilité des données RAID 0 - Striping dynamique RAID 1 - Mode miroir RAID 5 Amélioré Étude de cas : ZFS avec les bureaux Citrix et la virtualisation d applications Généralités Efficacité de stockage Améliorer l efficacité opérationnelle Protection fiable des données iii

5 3.4.5 Flexibilité, rapidité et performance Conclusion 20 Table des figures 21 Bibliographie 22 1

6 Chapitre 1 Caractéristiques techniques 1.1 Pourquoi les volumes existent-ils? Quels sont les apports de ZFS? Dans les années 90, chaque système de fichiers manageait un disque dur unique comme le montre la figure 1.1. Figure 1.1: Système de fichiers manageant un disque unique Cependant, cette solution n offrait pas d évolutivité pour un client qui souhaitait conserver une capacité de stockage très importante. De plus, les données n étaient pas répliquées donc non fiables pour l utilisateur. Statistiquement, une entreprise qui perd ses données périclite dans les deux jours si elle ne les récupère pas! Des scientifiques se sont penchés sur le problème : puisque les utilisateurs désiraient plus d espaces, de bandes passantes et de fiabilité, la solution consistait à re-designer tout le système de fichiers pour répondre à la problématique ou de rajouter des disques de calage (1.2). Figure 1.2: Réponse au problème des disques uniques Cependant, cette solution n est pas appropriée puisque les systèmes de fichiers et les ges- 2

7 tionnaires de volumes 1 sont vendus séparément. De plus, des difficultés apparaissaient à l interfaçage entre le système de gestion de fichiers et le volume qui ne pouvait pas être fixé. Donc, ce n est pas une panacée puisque les entreprises évoluaient autour de ce duo système de fichiers/volumes. C est avec ces problématiques intrinsèques de gestion de fichiers que les chercheurs de Sun Microsystem ont développé ZFS. La figure 1.3 compare le modèle traditionnel avec le modèle de gestion de fichiers ZFS. Figure 1.3: Comparaison entre le modèle système de fichiers/volumes traditionnel et ZFS Comme nous pouvons le constater, le modèle traditionnel est constitué de deux entités distinctes qui manquent de synergie puisque un problème (perte de courant,...) entraîne une resynchronisation des données dans le meilleur des cas. De plus cette solution n est pas flexible, nous sommes en présence d une plateforme dépendante et très complexe à manager si l on veut administrer les unités séparément. La pile ZFS s abstrait de ces contraintes puisque tous les blocs de traitement sont synchronisés ce qui implique une meilleure cohérence et fiabilité des données. Ainsi, ZFS fait appel à des pools de stockage qui n utilisent plus de volumes! Par ailleurs, le dataset ZFS impressionne : nous pouvons observer jusqu à 2 48 objets composé chacun de 2 64 octets. Nous expliquerons l architecture ZFS en détail en On distingue deux types de volume : Les volumes physiques qui sont les disques durs, partitions de disques durs, volumes RAID ou unités logiques provenant d un SAN (On concatène ces volumes physiques dans des «groupes de volumes») et les volumes logiques qui sont découpés dans les groupes de volumes, puis formatés et montés dans des systèmes de fichiers ou utilisés en tant que raw devices. 3

8 Un pool représente un ensemble de périphériques qui procurent de l espace pour le stockage et la duplication des données (figure 1.4). Figure 1.4: Pool de données Le "vdevs" est l unité de base de stockage de données ; nous y retrouvons : les disques : entiers ou juste une partition, fichiers dans un autre système de fichiers, miroirs : 2 (ou plus) disques, partitions ou fichiers, raid-z : plusieurs disques, variante de RAID Limites théoriques Z-File system est comme nous le disions un système de fichiers 128 bits, c est à dire que si nous voulions remplir un tel système de fichiers, les atomes seraient tellement lourds que cela entraînerait irrémédiablement un trou noir. Faisons une comparaison avec le système de fichiers de Microsoft appelé NTFS : il est de 64 bits, ce qui signifie que les fichiers peuvent atteindre 16 exaoctets ; ZFS lui fournit 16 milliards de milliards de fois ce chiffre! La comparaison est cinglante! Voici d autres limites[8] : "2 48 nombre de snapshots possible, 2 48 nombre de fichiers dans chaque système de fichiers, 16 exbioctets : la taille maximum du système de fichiers, 16 exbioctets : la taille maximum d un seul fichier, 2 56 : le nombre maximal théorique de fichiers par répertoire (en réalité limité à 248 par le nombre maximal de fichiers dans un système de fichiers)." 1.3 Portabilité De nombreux systèmes d exploitation utilisent ZFS ; nous vous présentons une liste non-exhaustive : Salaris 10 et 11, OpenSolaris, FreeBSD, FreeNAS, OSX. 4

9 1.4 Taille des blocs de données variables ZFS met à profit des tailles de bloc 2 variables allant jusqu à 1024 kb. Le code source actuel de ZFS accepte d optimiser la taille maximum des blocs. La taille des blocs peut être réglée automatiquement en fonction de la charge de travail. Par ailleurs, si la compression est activée, des blocs de taille variables sont utilisés augmentant ainsi la capacité des disques en évitant la perte d espace liée à la non-utilisation d une partie des blocs non-alloués. La compression peut être activée ou non activée en fonction des besoins. Dans le cas d une activation, des blocs de taille variable sont utilisés. Si un bloc subit une compression pour correspondre à la taille d un bloc de données plus petit, la taille de bloc la plus petite sera retenue et exploitée sur le disque : le débit en entrée et en sortie se voit améliorer et le volume de stockage amoindri. 1.5 Administration simplifiée Généralités Comme ZFS gère des pool de stockage et non des volumes, nous pouvons constater jusqu à 2 48 dataset par pool. Le système de fichiers devient ainsi l unique point de contrôle administratif. Le système de fichiers ZFS est hiérarchique avec des propriétés d héritage (comme en programmation orienté objet) ce qui nous amène à : des règles par dataset : instantanés de machines virtuelles, compression, restauration, quotas par utilisateur,..., connaître l utilisateur de tout l espace, manager logiquement les systèmes de fichiers apparentés comme un groupe, un seul et unique panel d administration pour la gestion de l ensemble, l héritage permet l administration à grande échelle en un clin d oeil! Ces caractéristiques admettent une intégration rapide et facile dans un environnement hautement virtualisé (datacenter), elles offrent une facilité d administration sans pareil. De plus, les règles suivent les données à la grande satisfaction des utilisateurs qui les managent très simplement. ZFS fournit deux commandes bash : La première "zpool" fournit des outils de management pour la création, la destruction, l import/export, l ajout de stockage et procure une vue sur l état et les performances du système. La seconde "zfs", permet la gestion du système de fichiers : création/destruction, montage clones, sauvegardes, gestions des attributs i.e. compression, quotas, Un bloc de données est la plus entité qu un système de fichier puisse gérer. Il est fixe pour des systèmes de fichiers comme FAT ou NTFS. 5

10 1.5.2 Exemples Création d un pool ZFS Pour créer un pool ZFS, nous devons entrer l unique commande : zpool create mypool raidz disk0 disk1 disk2 disk3 disk4 Création de systèmes de fichiers Pour créer les répertoires "Home" de chaque utilisateur, nous entrons les commandes suivantes : zfs create mypool/home zfs create mypool/home/alice zfs create mypool/home/bob zfs create mypool/home/charlie Pour créer le point de montage, il suffit de taper : zfs set mountpoint=/home mypool/home Quotas et réservation Pour définir un quota, il est nécessaire de rentrer la commande : zfs set quota=10g mypool/home/alice zfs list Et pour réserver de l espace disque à un utilisateur, nous rentrons : zfs set reservation=5g mypool/home/alice zfs list Sun Microsystem a rédigé un manuel d administration qui montre toute la puissance et la simplicité d utilisation de ZFS. Ce manuel est disponible dans la ressource [5] de la bibliographie. Snapshots Pour créer un snapshot, il suffit simplement de faire : zfs snapshot -r mypool/home@mercredi_18h30 zfs list -t snapshot ls -l.zfs/snapshot/ Pour restaurer un snapshot, rien de plus simple que : zfs rollback mypool/home@mercredi_18h30 6

11 Chapitre 2 Architecture ZFS 2.1 Généralités L image 2.1 montre l architecture de ZFS. Celle-ci peut se découper en deux parties : la partie utilisateur et la partie noyau. Figure 2.1: Architecture de ZFS Nous trouvons plusieurs composantes au niveau utilisateur : le consommateur du système de fichiers qui a pour fonction d interagir avec les API POSIX 1 du système de fichiers. Le consommateur de matériel qui a pour rôle d émuler des volumes dans /dev. Le management de l interface graphique, JNI : une interface Java pour libzfs spécifiquement conçue pour l interface graphique, LibZFS : une librairie qui interagit directement avec le noyau ZFS ; il interagit à la fois avec le système de fichiers et le pool de stockage. La structure de ZFS au niveau noyau peut être décomposée en trois structures de base : 1. la couche interface, 2. la couche transactionnelle d objets, 3. la couche pool de stockage. La couche la plus basse "Layered Driver Interface (LDI)" interagit avec les supports physiques de stockage sous-jacents. 1. POSIX est le nom d une famille de standards définie depuis 1988 l IEEE. Ces standards ont émergé d un projet de standardisation des API des logiciels destinés à fonctionner sur des variantes du système d exploitation UNIX. 7

12 2.2 Pool de stockage Les pools de stockage ZFS (zpool) sont composés d une collection de périphériques virtuels. Découvrons ci-dessous les deux types de périphériques virtuels : 1. les périphériques virtuels physiques (appelés parfois "feuille vdevs"), 2. les périphériques virtuels logiques (appelés parfois "vdev intérieur") Un vdev physique est un média inscriptible composé de blocs de données. Un vdev logique est un groupement conceptuel de ces vdevs physiques. ZFS structure ces vdevs en arbre au moyen de vdevs physiques en tant que feuille. Tous les pool de stockage utilisent un vdev logique spécifique appelé "vdev root" qui n est ni plus ni moins que le noeud "Top" de l arbre. Tous les nœuds enfants directs de ce root sont intitulés "vdevs de niveau top". La figure 2.2 montre un tel arbre avec deux miroirs. Figure 2.2: Un arbre de vdev ZFS Le premier miroir ("M1") contient deux disques physiques représentés respectivement par "vdev A" et "vdev B". Le deuxième miroir "M2" est également composé de deux disques physiques "vdev C" et "vdev D". Comme nous pouvons le voir, le fonctionnement d un zpool est similaire à la mémoire RAM d un ordinateur : la capacité totale d un pool mémoire dépend de la quantité de barrettes mémoire ainsi que de leur capacité. Par ailleurs, le rajout de disques à chaud dans ces vdevs est possible sans un apport conséquent de configurations supplémentaires. La solution évolutive et flexible correspond parfaitement pour la gestion de serveurs dans un datacenter. 8

13 2.3 Ensemble de données et la couche de snapshot La DSL (Dataset and Snapshot Layer) fournit des mécanismes pour décrire et gérer les relations entre les objets et leurs propriétés. Prenons connaissance de la liste des différents objets de la couche DSL : ZFS Filesystem : le système de fichiers stocke et organise les objets de manière à y accéder facilement tout en respectant la norme POSIX, ZFS Clone : un clone est identique à un système de fichiers excepté sur son origine. Un clone est originaire d un snapshot et son contenu est identique en tout point à ce snapshot dont il est issu, ZFS Snapshot : Un snapshot est une version en lecture seule d un système de fichiers, clone ou volume à un instant t. Chaque jeu d objet est représenté par un jeu de données. Ce dernier gère les statistiques de consommation, les informations de localisations et garde un enregistrement de l interdépendance des snapshot. 2.4 Couche ZFS Posix La couche Posix ZFS (ZPL) permet aux objets de la Data Management Unit de ressembler à un système de fichiers POSIX. Pour être accepté par la norme POSIX, ZFS fournit ces services : aménagement du système de fichiers, répertoires et parcours de dossiers, listes d accès (ACL). La couche ZPL représente le système de fichiers comme étant un objet de type DMU_OST_ZFS. Tous les snapshots, clones, et systèmes de fichiers sont implémentés dans un objet de ce type. 2.5 Couche de journalisation La couche de journalisation ZFS (ZFS Intent Log) sauvegarde les transactions d enregistrements des appels systèmes qui changent le système en mémoire. Les informations contenues dans les journaux sont construites à partir de suffisamment de données pour que celles-ci soient rejouées en cas de défaillance logique ou physique. Ces enregistrements sont stockés en mémoire jusqu à ce que le groupe de transaction de la Data Management Unit les "commits" dans un pool stable. Selon le cas, ces enregistrements sont ensuite détruits ou enregistrés dans un système de journalisation. Dans l hypothèse d une panne électrique ou de "kernel panic", les enregistrements peuvent être rejoués. Cette couche fournit à ZFS un rôle d imputabilité ; nous savons maintenant : qui a fait quoi, quand, comment et dans quelles circonstances. 2.6 Volume ZFS Les ZVOL (ZFS Volume) fournissent un mécanisme pour la création de volumes logiques. Les volumes ZFS sont exportés en tant que bloc de périphérique et utilisés comme tels. Les volumes ZFS peuvent être représentés comme des objets de type DMU_OST_ZVOL. 9

14 Chapitre 3 Intégration de ZFS dans un environnement en nuage 3.1 Qu est ce que le cloud computing? Définition Le cloud computing est un concept très récent, abstrait et en pleine émergence. Il est défini par le National Institue of Standards and Technology (N.I.S.T.) comme tel : "Le cloud computing est l accès via le réseau, à la demande et en libre service à des ressources virtualisées et mutualisées"[3]. Cette nouvelle perception de l informatique bouscule nos habitudes. Au mois de mars 2012, l entreprise Gartner[2] annonce que les services de cloud seront intégrés à 90% dans les appareils connectés : une très large majorité des données sera déportée chez le fournisseur de cloud à la fin de l année Cependant, le concept du cloud n est pas totalement nouveau puisqu il agrège une multitude de services et de technologies. Dans les années 1960, IBM apporte de nouveaux services à des clients sous le nom de Service Bureau. Dans les années 1990 avec l explosion de l Internet, les services sont octroyés via le réseau (Application Service Provider). De nos jours, ces services se distribuent via le cloud computing sous le nom de SaaS et ne nécessite plus l utilisation de clients lourds mais d un simple navigateur internet comme Google Chrome Caractéristiques Les principales caractéristiques de l informatique en nuage ont été définies par la NIST dans "The Nist definition of cloud computing" [3]. Prenons connaissance de la liste : Service à la demande : les services sont fournis au client automatiquement et sans intervention humaine, Élasticité rapide : le stockage, la puissance computationnelle... peuvent être rapidement ajustés parfois systématiquement en fonction des besoins présents de chaque client, Mise en commun des ressources : Les différents utilisateurs bénéficient de ressources de serveurs alloués de manière dynamique et rapide dans le cadre d un modèle de cloud communautaire, Résilience : Le cloud computing est tenu d engendrer des mécanismes hétérogènes où les technologies présentes supportent une multitude de clients légers (ordiphones, tablettes) et de clients lourds (ordinateurs), Paiement à l utilisation : Les services sont facturés à l utilisation des ressources en toute transparence à la fois pour le client et le fournisseur de services en nuage. 10

15 3.2 Intégrité des données avec ZFS Généralités Par définition, l intégrité des données désigne "l état de données qui lors de leur traitement, de leur conservation ou de leur transmission, ne subissent aucune altération ou destruction volontaire ou accidentelle, et conservent un format permettant leur utilisation. L intégrité des données comprend quatre éléments : l intégralité, la précision, l exactitude/authenticité et la validité."[6]. ZFS se démarque ici de ses concurrents en apportant une protection des données utilisateurs sur le disque face aux corruptions de données silencieuses 1. Or, les recherches récentes montrent que les systèmes de fichiers tels que NTFS, Ext, HFS,... ou les systèmes RAID physiques n apportent pas suffisamment de protection face à ce genre de complication. Au niveau physique, les disques durs disposent de nombreux outils qui permettent la détection d erreurs de données : d innombrables erreurs arrivent lors d un usage normal et sont corrigées, cependant un petit nombre d erreurs passent inaperçues. A propos de ZFS, l intégrité des données est permise grâce à un contrôle d erreurs (checksum) et un arbre de hachage. De manière plus précise, relevons les erreurs que ZFS est capable de détecter et de corriger : Écriture fantôme où l écriture n est actuellement pas persistante sur le disque, Mauvaise lecture ou écriture, le disque adresse le mauvais bloc et lit la mauvaise donnée ou écrit par dessus, Erreur de parité concernant l accès direct à la mémoire entre les unités de stockage et la mémoire du serveur, Erreur de pilote où les données arrivent dans le mauvais tampon au sein du noyau système, Écrasement accidentel. 1. Les problèmes de corruption de données silencieuses arrivent au cours du processus d écriture sur le disque. Ces erreurs sont les plus dangereuses dans le sens où les données incorrectes ne font l objet d aucune indication particulière 11

16 3.2.2 Copy-On-Write Généralités Pour éviter une modification telle que : écrire par-dessus d anciennes données avec de nouvelles écritures comme dans les systèmes traditionnelles (figure 3.1a), ZFS écrit les nouvelles données dans un emplacement récent puis réécrit le pointeur vers les nouvelles données (figure 3.1b). Nous évitons les opérations lire-modifier-écrire pour des petits enregistrements en ne faisant appel qu à des écritures full-strip. (a) Méthode traditionnelle (b) Méthode Copy-on-Write Figure 3.1: Comparaison d une méthode traditionnelle avec une méthode de copy-sur-écriture Pour garantir l intégrité des données, ZFS se sert d un arbre de hachage de Merkle qui n est rien d autre qu un arbre pourvu de hachés où les segments de données forment les feuilles. Chaque nœud intermédiaire correspond à la valeur de hachage de ses nœuds enfants. La construction d un tel arbre se réalise de la manière suivante : nous divisons simplement le jeu de données en segment en utilisant une taille constante. Nous hachons ensuite chaque segment de données séparément pour former les segments C 0 et C 1 sur la figure 3.2. Nous concaténons maintenant les hash C 0 et C 1 puis hachons cette valeur (C 01 ). Nous continuons ainsi jusqu à atteindre le nœud root K. Les anciens blocs sont libérés en l absence de snapshots. Il est donc moins onéreux (en terme de CPU) d utiliser des snapshots! Figure 3.2: Arbre de hachage complexe Cette arbre présente l avantage de réduire les coûts de calcul car seule une valeur de haché est calculée chez le client et le serveur ; le but recherché étant de valider les données réseaux et en conséquence la persistance des données sur le disque. De plus, cette structure apporte une isolation entre les données et la somme de contrôle par un stockage séparé : nous évitons ainsi un bon nombre d erreurs. 12

17 3.3 ZFS pour la haute disponibilité des données RAID 0 - Striping dynamique ZFS très ingénieux autorise la distribution de la charge sur tous les matériels physiques. La figure 3.3 montre un pool de stockage composé de quatre miroirs. Figure 3.3: Un pool de stockage en mode striping dynamique Les données sont écrites au travers des quatre miroirs et lues quelque soit l endroit où elles sont écrites, nous parlons dès lors de performance. L allocation des blocs de données considèrent : la capacité du disque, les performances basées sur des métriques telles que la latence, la gigue, la bande passante, la santé du disque. La figure 3.4, comporte un 5 ème disque dur en miroir. Figure 3.4: Ajout d un 5 ème disque dur en miroir Après l ajout d un 5 ème disque, l écriture se fait au travers des cinq miroirs. Les données sont lues quelque soit l endroit où elles sont écrites. Notons un point positif supplémentaire celui de la non-nécessité de migrer les données existantes : les anciennes données sont réparties sur les disques 1 à 4, les nouvelles données sont réparties sur les disques 1 à 5, le mode Copy-On-Write ré-alloue les anciennes données, 13

18 3.3.2 RAID 1 - Mode miroir qu est-ce-que le RAID 1? Le RAID 1 fait appel à des disques redondants (avec n 2 ), chaque disque de la grappe contient rigoureusement et de manière permanente les mêmes données d où l utilisation du mot «miroir». La resynchronisation (ou reconstruction) depuis un miroir est un processus de réparation d un périphérique endommagé par utilisation du contenu du périphérique en parfaite constitution. Dans le cas du miroir traditionnel, il peut s agir tout bonnement d une simple copie du disque entier. (a) Miroir traditionnel - Étape 1 (b) Miroir traditionnel - Étape 2 (c) Miroir traditionnel - Étape 3 Figure 3.5: RAID 1 Traditionnel Un souci de lecture sur une application serait le cas le plus critique. Le miroir lit le 1 er disque qui possède un bloc de données corrompues (figure 3.5a). Le gestionnaire de volume passe ensuite le mauvais bloc de données au système de fichiers. Dans le cas d un bloc de métadonnées le système de fichiers plante (figure 3.5b). Dans le cas contraire, le système retourne une donnée corrompue à l application (figure 3.5c). 14

19 Le RAID 1 avec ZFS Lorsqu une application accède à un bloc de données, que se soit un bloc de données ou de métadonnées, sa somme de contrôle est calculée et comparée avec la valeur stockée dans l arbre de hachage. Si la somme de contrôle est correcte, ZFS retourne le bloc de données à la pile d appel qui l a sollicitée. Lorsqu une application lit un mauvais bloc de données, le miroir ZFS va dans un premier temps tester le 1 er disque ; la somme de contrôle révèle qu un bloc est corrompu sur le disque. ZFS essaie le 2 ème disque ; la somme de contrôle indique que le bloc est convenable. ZFS retourne alors le bloc sain à l application évitant toute erreur et répare le bloc de données corrompu sur le 1 er disque. Figure 3.6: ZFS détecte les données corrompues par une utilisation des sommes de contrôle et peut soigner les données par l intermédiaire de sa copie en miroir Cette solution mise en place par ZFS s abstrait des contraintes présentées en 3.3.2,elle permet également de conserver l intégrité des données sur le disque, cette préservation est essentielle pour un fournisseur de solution en nuage comme pour son client qui ne souhaite pas perdre ses données. De plus, lorsqu un disque subit une avarie, il n est pas nécessaire de resynchroniser tout le disque mais uniquement les parties ayant subi un changement. Par ailleurs, ZFS ne perd pas de temps et de bande passante à copier des blocs de données libres puisque ceux-ci ne font pas partie de l arbre de stockage. La resynchronisation d un disque est très rapide puisqu elle ne prend dès lors qu une poignée de secondes ou quelques minutes tout au plus. Enfin, la reconstruction des disques est arrétable et sécurisée. En effet, si une panne de courant ou un redémarrage du système vient affecté le bon fonctionnement de la restauration, ZFS est capable de résumer l opération là où elle s était arrêtée sans l intervention d un administrateur système. 15

20 3.3.3 RAID 5 Amélioré Qu est-ce-que le RAID 5? Le RAID 5 associe la méthode du volume agrégé par bandes (striping) à une parité répartie. Il s agit là d un ensemble à redondance N + 1. Le bit de parité inclus avec chaque écriture se retrouve répartie circulairement sur les différents disques. Chaque bande est donc constituée de N blocs de données et d un bloc de parité. Ainsi, en cas de défaillance sur l un des disques de la grappe, il manquerait pour chaque bande soit un bloc de données soit le bloc de parité [7]. La figure 3.7 illustre ce concept en image. Figure 3.7: Le RAID 5 en image Malheureusement, le RAID 5 ne détecte pas et ne corrige pas la corruption silencieuse de données. Il souffre du problème du trou d écriture : une perte de synchronisation entre les données et les bits de parité a pour conséquence une corruption des données. 16

21 RAID-Z, le raid à la mode ZFS ZFS fournit une meilleure disponibilité des données que le RAID 5 traditionnel : RAID-Z. En effet, il utilise l approche Copy-On-Write pour résoudre le problème de trou d écriture. De plus, il emploie le même système de parité distribué que RAID 5 à la différence près qu il détecte et corrige la corruption silencieuse de données. Ainsi, des petits blocs sont écrits en miroir au lieu d être protégés en parité, méthode parfaitement réalisable puisque le système de fichiers est conscient de la sous-structure de stockage et peut allouer de l espace supplémentaire si nécessaire. Figure 3.8: RAID Z ZFS propose également un RAID-Z2 et un RAID-Z3 qui utilisent des parités doubles et triples. Ils permettent de perdre respectivement jusqu à deux et trois disques sans perte de données. Cette approche améliore considérablement la disponibilité des données dans de grands systèmes distribués comme le cloud computing. 17