https://blog.hilpert.me

Ce blog me sert à garder une trace de différents travaux IT que je mène

Test OCFS2

Rédigé par Frédéric Aucun commentaire

Dans le cadre de l'étude d'une solution pour servir le même contenu sur plusieurs serveurs, et donc d'accéder simultanément au même stockage, j'ai décidé de tester le système de fichiers clusterisé : OCFS2 - Oracle Cluster File System 2.

L'infrastructure de test est la suivante :

  • 2 machines virtuelles
  • Ubuntu 16.04.4 LTS (Xenial Xerus)
  • ocfs2-tools version 1.6.4-3.1 amd64
  • Une cible ISCSi de 10Go
  • deux interfaces réseau comme ci-dessous :
schéma de principe du lab de test

J'ai donc constitué ce rapide lab de test dans le but d'obtenir un système de fichier disponible sur plusieurs machines, tout en étant physiquement sur le même stockage partagé.

OCFS2 se sert du réseau pour assurer la cohérence du système de fichiers à travers les différents membres du cluster. Selon mes observations cela se passe ainsi : quand on fais un IO en écriture, ce bloc est écrit sur le stockage partagé et un paquet transite par le réseau pour notifier les différents membres du cluster que cette entité à été écrite (certainement avec la position de début et de fin du bloc mémoire qui a été écrit sur le disque)

De mon ressenti, cela fonctionne très bien. Je n'ai pas effectué de mesure, mais selon moi cette techno risque de ralentir un peu le système de fichier car il faut attendre que tout le cluster ait pris connaissance de toute écriture disque.

Installation et configuration

A compléter

Pas d’intelligence particulière

Il faut savoir par contre que OCFS2 n'apporte pas une intelligence particulière. Prenons l'exemple d'une édition simultanée du même fichier avec vim sur deux serveurs qui accèdent au même stockage :
Avec vim quand on édite un fichier, le contenu de celui-ci est chargé en RAM, dans ce qu'on appelle un "buffer". Lorsqu'on édite ce qui s'affiche à l'écran on le fait directement en RAM et quand on execute :w le contenu de la RAM est copié sur disque. Si l'on ouvre le même fichier des deux côtés, les deux serveurs vont le charger dans leur RAM respective et lorsque l'on va sauvegarder le fichier d'abord à gauche et ensuite à droite, nous allons perdre les modifications de gauche car la RAM de la machine de droite ne contiendra pas les modifications effectuées sur la machine de gauche même si sur le système de fichier a été mis à jour entre temps.

Du point de vue système de fichier c'est valide puisque ce sont deux écritures ou mises à jour différentes du même fichier. Selon moi cela sera ainsi peu importe le système de fichier utilisé.

Ce qui se passe en cas de panne réseau

Le réseau est une ressource critique et en cas de problème de communication entre nœuds du cluster, les I/O sont dans un premier temps freezé partout, (probablement pendant les 30 secondes de timeout que j'ai défini dans un fichier de conf) et si le problème ne se résoud pas, un mécanisme de "fencing" entre en jeu : le master du cluster continue de fonctionner et tous les autres membres du cluster se crashent intentionnellement (kernel panic)

C'est violent, oui, mais ce n'est pas dénoué de sens car il vaut mieux crasher une partie des machines que de corrompre le système de fichiers.

Points positifs de la techno :

  • Cela permet donc d'avoir un système de fichiers en lecture/ecriture, sur plusieurs machines tout en écrivant sur le même stockage
  • Pas l'overhead de copier les données à travers le réseau pour répliquer sur une autre machine comme avec DRDB par exemple
  • Possibilité d'étendre le cluster à chaud

Points négatifs de la techno :

  • il ya une dépendance forte sur le réseau puisque c'est grâce au réseau et aux notifications que les serveurs s'envoie que le système de fichier garde une cohérence (le but de cette cohérence étant de ne pas ré-écrire par dessus des blocs qui seraient déjà écrits par un autre serveur.). Ce point négatif est à relativiser dans les cas ou le réseau Ethernet sert aussi de stockage puisque si on perds ce réseau on freeze de toute manière 100% des machines.
  • Certaines opérations se font à froid (cluster éteint) comme la modification d'une IP ou d'une conf d'un noeud existant

Conclusion

Selon mes rapides tests, cette technologie est surtout adaptée à des petits clusters qui contiennent entre 2 et 4-5 machines. Au-delà de 4 ou 5 machines qui font des requêtes sur le même stockage, celui n'encaisserai de toute manière plus la charge, sauf besoins très particuliers. Je recommanderai dans ce cas soit de répartir la charge à travers plusieurs petits cluster que de constituer un gros cluster. Ou bien d'utiliser une autre technologie que des systèmes de fichiers clusterisés. En cas de problème réseau grave, OCFS2 permet néanmoins de continuer à fonctionner en mode dégradé. C'est particulièrement valable pour les architecture qui reposent sur l'Ethernet pour accéder au stockage.
Classé dans : Non classé Mots clés : aucun

Écrire un commentaire

Quelle est la deuxième lettre du mot spkk ?

Fil RSS des commentaires de cet article