1.4. Considérations sur le formatage GFS2

Pour formater votre système de fichiers GFS2 afin d'en optimiser les performances, vous devez tenir compte de ces recommandations.

Taille du système de fichiers : Plus c'est petit, mieux c'est

GFS2 est basé sur une architecture 64 bits, qui peut théoriquement accueillir un système de fichiers de 8 EB. Cependant, la taille maximale actuellement supportée par un système de fichiers GFS2 pour un matériel 64 bits est de 100 To.

Notez que même si les systèmes de fichiers GFS2 de grande taille sont possibles, cela ne signifie pas qu'ils sont recommandés. La règle de base avec GFS2 est que plus c'est petit, mieux c'est : il est préférable d'avoir 10 systèmes de fichiers de 1 To plutôt qu'un système de fichiers de 10 To.

Il y a plusieurs raisons pour lesquelles vous devriez garder vos systèmes de fichiers GFS2 de petite taille :

En outre, la réduction du nombre de groupes de ressources à gérer se traduit par de meilleures performances.

Bien entendu, si votre système de fichiers GFS2 est trop petit, vous risquez de manquer d'espace, ce qui n'est pas sans conséquences. Vous devez prendre en compte vos propres cas d'utilisation avant de décider de la taille du système.

Taille des blocs : Les blocs par défaut (4K) sont privilégiés

La commande mkfs.gfs2 tente d'estimer une taille de bloc optimale basée sur la topologie du périphérique. En général, les blocs de 4K sont la taille de bloc préférée car 4K est la taille de page par défaut (mémoire) pour Red Hat Enterprise Linux. Contrairement à d'autres systèmes de fichiers, GFS2 effectue la plupart de ses opérations en utilisant des tampons de noyau de 4K. Si la taille de votre bloc est de 4K, le noyau doit effectuer moins de travail pour manipuler les tampons.

Il est recommandé d'utiliser la taille de bloc par défaut, qui devrait permettre d'obtenir les meilleures performances. L'utilisation d'une taille de bloc différente n'est nécessaire que si vous avez besoin de stocker efficacement de nombreux petits fichiers.

Taille du journal : La valeur par défaut (128 Mo) est généralement optimale

Lorsque vous exécutez la commande mkfs.gfs2 pour créer un système de fichiers GFS2, vous pouvez spécifier la taille des journaux. Si vous n'indiquez pas de taille, la valeur par défaut est de 128 Mo, ce qui devrait être optimal pour la plupart des applications.

Certains administrateurs de système pourraient penser que 128 Mo est excessif et être tentés de réduire la taille du journal au minimum de 8 Mo ou à 32 Mo, ce qui est plus prudent. Bien que cette solution puisse fonctionner, elle peut avoir un impact important sur les performances. Comme de nombreux systèmes de fichiers avec journalisation, chaque fois que GFS2 écrit des métadonnées, celles-ci sont validées dans le journal avant d'être mises en place. Cela garantit que si le système tombe en panne ou perd de l'énergie, vous récupérerez toutes les métadonnées lorsque le journal sera automatiquement rejoué au moment du montage. Cependant, il ne faut pas beaucoup d'activité au système de fichiers pour remplir un journal de 8 Mo, et lorsque le journal est plein, les performances ralentissent car GFS2 doit attendre les écritures sur le stockage.

Il est généralement recommandé d'utiliser la taille de journal par défaut de 128 Mo. Si votre système de fichiers est très petit (par exemple, 5 Go), l'utilisation d'un journal de 128 Mo peut s'avérer peu pratique. Si vous disposez d'un système de fichiers plus important et que vous pouvez vous permettre d'utiliser l'espace nécessaire, l'utilisation de journaux de 256 Mo peut améliorer les performances.

Taille et nombre des groupes de ressources

Lorsqu'un système de fichiers GFS2 est créé à l'aide de la commande mkfs.gfs2, il divise le stockage en tranches uniformes appelées groupes de ressources. Il tente d'estimer une taille optimale pour les groupes de ressources (entre 32 Mo et 2 Go). Vous pouvez remplacer la valeur par défaut avec l'option -r de la commande mkfs.gfs2.

La taille optimale du groupe de ressources dépend de l'utilisation que vous ferez du système de fichiers. Tenez compte du degré de saturation du système et de la présence ou non d'une fragmentation importante.

Il est conseillé d'expérimenter différentes tailles de groupes de ressources afin de déterminer celle qui permet d'obtenir des performances optimales. La meilleure pratique consiste à expérimenter avec un cluster de test avant de déployer GFS2 en production complète.

Si votre système de fichiers comporte trop de groupes de ressources, chacun d'entre eux étant trop petit, les allocations de blocs peuvent perdre trop de temps à rechercher un bloc libre dans des dizaines de milliers de groupes de ressources. Plus votre système de fichiers est saturé, plus le nombre de groupes de ressources à rechercher est élevé, et chacun d'entre eux nécessite un verrou à l'échelle de la grappe. Les performances s'en trouvent ralenties.

Toutefois, si votre système de fichiers comporte trop peu de groupes de ressources, chacun d'entre eux étant trop grand, les allocations de blocs risquent de se disputer plus souvent le même verrou de groupe de ressources, ce qui a également un impact sur les performances. Par exemple, si vous avez un système de fichiers de 10 Go divisé en cinq groupes de ressources de 2 Go, les nœuds de votre cluster se disputeront ces cinq groupes de ressources plus souvent que si le même système de fichiers était divisé en 320 groupes de ressources de 32 Mo. Le problème est exacerbé si votre système de fichiers est presque plein, car chaque allocation de bloc peut devoir parcourir plusieurs groupes de ressources avant d'en trouver un avec un bloc libre. GFS2 tente d'atténuer ce problème de deux manières :

Le pire scénario est celui d'un répertoire central dans lequel tous les nœuds créent des fichiers, car tous les nœuds se battent constamment pour verrouiller le même groupe de ressources.