Nos amis les Filesystems… Part I

Les types de filesystem.

Les classiques.

Lorsque vous installez votre Linux, sachez que vous avez la possibilité de choisir votre filesystem, et de le partitionner vous-même (c’est-à-dire le scinder en morceau de disque). Par défaut, Linux, dans ses versions récentes, installera votre filesystem sous ext4 -Extended FileSystem- (Ubuntu Karmic Koala, Fedora 12 Constantine, …). Mais comme cela est si bien dit dans les notes d’Ubuntu, cela ne signifie pas que les autres filesystems ne sont plus supportés. Il existe en effet, historiquement, d’autres versions d’ext : ext2, ext3 sont les plus souvent rencontrées (au-delà, votre serveur est vraiment vieux).

Ah. Question au fond. La différence ? Entre ? AAAH !!!

Déjà, entre ext2 et ext3, nous avons principalement une différence au niveau de la journalisation. En effet, ext2 est un des dinosaures de Linux. Il était certes plus intelligent que le FAT de Windows, en ce sens qu’il organisait les fichiers et donc limitait le recours à la fragmentation, mais il restait perfectible. Vous en avez révé ? Ext3 l’a fait ! La journalisation sert essentiellement à maintenir la cohérence des métadonnées, notamment en cas de crash. Cela évite par exemple le gentil fsck de ext2 lorsque le système a subi un arrêt impromptu. Le système relit tranquillement son fichier de log, retrace les dernières transactions non commitées et remet d’aplomb un système sain en 2 temps trois mouvements. Hop, ne soyons pas radin, un peu de doc vous fera du bien !

Ext3 et Ext4, c’est une autre histoire. Ext4 est une évolution puisqu’étant encore attaché à la compatibilité descendante, il reste limité dans ses mouvements. Ext4 oriente la majorité de son travail sur les problèmes de tailles et de fragmentation. Hop, moment opportun pour un petit lien d’info sur Linuxfr.org et sur le Wiki officiel Ext4.

Ext3 et Ext4 sont principalement utilisés, ce sont eux qui supportent votre Linux. Ils peuvent travailler sur disques durs, sur volumes logiques, sur partition raid, toussa toussa, sans broncher (ou si peu).

Les outils et fichier impliqués font partie du noyau Linux depuis belle lurette, ce sont, entre autre :

• fdisk : permet de manipuler / voir / gérer les partitions,
• mkfs.ext2 ou mkfs.ext3 : créer le système de fichier (respectivement ext2 ou ext3),
• fsck : monitorer et réparer votre système de fichier,
• resize2fs : redimensionner le filesystem,
• mount : « monter », c’est-à-dire rendre accessible en lecture (et, pourquoi pas, en écriture-exécution) un système de fichier,
• /etc/fstab : fichier de configuration pour les montages automatiques au démarrage des différents filesystems. Par défaut, votre filesystem est déjà monté et inscrit dans ce fichier.

Les extensibles et les hautes disponibilités.

Lorsque l’on donne, dans son immense bonté, vie à une machine Linux, elle a, comme tout être vivant, un cycle de vie. Parce que oui, dans un contexte généralisé, votre machine aussi a besoin de grandir, en terme de composant, de performances, de service et d’espace.

Il existe plusieurs moyens permettant de construire et d’étendre un système de fichier. Certaines approches nécessitent un travail de réflexion en amont, à savoir si réellement on a besoin de rajouter de l’espace, si ce doit être opérationnel sans avoir à réinstaller, rapidement, de manière modulaire, si il y a une forte contrainte de temps et de disponibilité,… Bref, plus on veut, plus fallait réfléchir avant.

De même, souhaitons-nous recourir à des outils qui ont fait leurs preuves depuis des années, des solutions toutes packagées, principalement hardware, ou bien préférerons-nous les versions plus intelligentes, plus intuitives, plus modulables ? Les alternatives sont nombreuses, et je ne les maîtrise pas toutes.

RAID. Voilà le premier point qu’il vous vient à l’esprit.

Un RAID (Redundant Array of Inexpensive Disks) est une agrégation de device de stockage qui permet d’avoir une tolérance aux éventuels accidents (panne, crash d’un disque dur,…) et qui améliore les performances d’accès aux données. En effet, composé de plusieurs disques, cela lui permet d’une part d’étaler les données sur l’ensemble des disques, mais en plus, et c’est vital, de rajouter des brides d’information concernant ces données tour à tour sur chacun des disques (RAID 5). Ces bribes d’information (bits de parité) sont stockés dans des stripes et servent à contrôler les données ajoutées et, au besoin, de les reconstruire. En conséquence, puisque ces données sont éclatées sur plusieurs disques, les temps d’accès en lecture et en écriture sont grandement améliorés.

Notre ami Wiki est toujours là pour vous.

Construire un RAID -logiciel, j’entends, puisqu’il n’y a jamais assez de moyens pour le tout packagé et qu’on est curieux de savoir ce qu’il y a sous le capot-, et surtout le maintenir, ce n’est pas de tout repos. Dans la meilleure des configurations, il vous faut n fois le même genre de disque dur (capacité, mémoire cache, vitesse, connectique), sinon le bonus de capacité qu’un disque pourrait avoir sur les autres sera jeté aux oubliettes. Il vous faut aussi, de préférence (mais c’est comme dans la vraie vie, tout est une histoire de bon matériel au bon moment) des disques en spare, histoire que vous ne soyez pas en position malheureuse si un autre « incident » survenait. De même, en cas de fail d’une unité du raid, la reconstruction des données peut prendre du temps.

Le RAID est une bonne solution concernant la scalabilité et la haute disponibilité, mais ce n’est pas un système de fichier, c’est une technologie. Vos meilleurs amis seront :

• mdadm : monitorer, créer, gérer le raid,
• mkraid : créer un raid,
• lsraid : lister les composants du (des) raid(s),
• raidhotadd : ajout à chaud de volume dans le raid,
• raidsetfaulty : forcer la sortie d’une volume en le mettant en faulty,
• raidstop, raidstart,…
• mknod : créer un fichier spécial block ou character
• /etc/raidtab : fichier de configuration d’un raid (optionnel)
• /proc/mdstat : fichier monitorant l’état du raid (pensez à watch pour le visionner en temps réel),
• /var/log/messages : log système,
• tous les outils gérant le filesystem sous-jacent.

Resté sur votre faim ? Par ici !

Une autre façon de faire serait de passer par LVM (Logical Volume Manager).

La principale différence entre RAID et LVM, c’est que justement LVM n’est pas un RAID. LVM ne travaille pas directement sur les disques, mais sur des entités appelées Logical Volumes, crées, maintenus et gérés par tout un arsenal d’outil rattachés au package lvm2. LVM apporte donc un niveau d’abstraction supplémentaire qui permet à vous, utilisateur et administrateur, de pouvoir redimensionner, créer, supprimer, étendre,… vos partitions sans avoir à vous soucier du hardware en dessous.

Plus en détail, LVM décompose le disque dur en pv, physical volumes, qu’il regroupe au sein d’un vg, Volume Group, et sur lequel il crée un lv, Logical Volume. C’est sur le Logical Volume que le filesystem s’installe, donc « quelque part » sur le Volume Group. Il est vraiment très facile d’étendre et de shrinker (réduire) l’espace disque.

LVM est très stable, éprouvé en production, modulable à souhait, un brin plus souple que le RAID, et plus que propice à la scalabilité mais en revanche, il n’aide pas niveau haute-disponibilité. Il est cependant possible d’utiliser LVM sur un RAID pour ajouter les avantages du RAID -et ses inconvénients par la même occasion- à ceux de LVM.

Les outils qui vous aideront :

• lvm2 : le package de référence,
• pv{change||ck||create||display||move||remove||resize||display||scan||s} : gestion des physical volumes (par exemple, pvcreate /dev/sda2),
• vg{cfgbackup||cfgrestore||change||ck||convert||create||display||export||extend||import
  ||merge||mknodes||reduce||remove||rename||s||scan||split} : gestion des volume groups,
• lv{change||convert||create||display||extend||reduce||remove||rename||resize||s||scan} : gestion des logical volumes,
• lvm{||change||diskscan||dump||sadc||sar} : gestion lvm.

Si vous voulez en venir aux mains, faites.

Le dernier point que je souhaiterais voir avec vous au niveau des extensibles et hautement disponibles, se cache sous trois lettres : ZFS.

ZFS, contrairement aux deux autres points, est un filesystem à part entière, il ne s’agit donc pas d’un outil. Zeta Filesystem, de son petit nom, a été développé par Sun. Ce système de fichier présente des caractéristiques très particulières mais n’est pas intégré au noyau Linux pour une raison simple : la licence sous lequel il est distribué (CDDL) est incompatible avec GPL dans sa version 2. Mais là encore, grâce à Ricardo Correia, développeur, nous pouvons utiliser ZFS via fuse (filesystem in userspace), environnement qui met à disposition, comme son nom l’indique, les fonctionnalités des filesystems dans l’espace User.

ZFS constitue un peu le fantasme de tout administrateur système. Il fait en sorte d’être toujours cohérent. Oui. Vous avez bien entendu. Il se corrige tout seul. Cette citation à elle seule, comme ça, sans preuve peut choquer. De même, il fournit une très haute capacité de stockage (nettement plus haute que tous les autres filesystems d’après notre ami Wiki). Voyons comment tout ça fonctionne.

Eh bien ZFS nous rappelle un peu le fonctionnement de LVM. En effet, notre filesystem s’appuie en réalité sur des pools de stockage. Les pools permettent, comme on l’a vu précédemment, d’éviter de se soucier du hardware, partionnement compris. Dans ZFS, ils sont utilisés pour centraliser les IO (entrées-sorties) et comme lien entre les différents périphériques de stockage. Lorsqu’une donnée est destinée à être écrite sur un disque, elle passe par le pool, à ce moment-là, elle est vérifiée à la volée, dupliquée, puis stockée. ZFS dispose donc de tous les éléments nécessaires pour contrôler à n’importe quel moment la cohérence et la véracité des données et va même jusqu’à corriger la donnée corrompue sans que vous ayez à le lui demander.

De la même manière, ZFS s’appuie sur du RAID Z, qui est un peu semblable à notre bon vieux RAID 5, à la différence que les stripes de données ont une largeur variable, de sorte que ZFS limite les pertes d’espace disque à leur origine.

Si vous avez envie d’en savoir plus, jetez un coup d’oeil sur le site officiel, la doc officielle, et l’article d’Unix Garden sur sa mise en place. Sachez aussi que ZFS est présent nativement sous OpenSolaris, version Open Source de Solaris.

Il existe beaucoup d’autres qui mériteraient d’être dans cette catégorie, mais j’arrêterais là. Sachez que je vous encourage à participer si vous estimez qu’il manque vraiment quelque chose.

C’est tout pour la première partie et encore !!! Je suis loin d’être exhaustive, même en me cantonnant à Linux.

Sur ce, potassez bien, farmez, complétez et n’oubliez pas de passer de Bonnes Fêtes -oui, un ASR aussi, ça se repose parfois- !!!