htg-content/content/posts/le-san-maison-pas-cher.md

title	date	author	template	tags
Le SAN maison pas cher	2023-06-16	raspbeguy	post

Dans un précédent article, je parlais de ma solution de stockage pour ma grappe d'hyperviseurs, pour pouvoir faire des migrations à chaud, tout ça. Si vous vous souvenez bien, pour la mise à disposition du stockage par plusieurs machines en même temps, j'avais évoqué plusieurs possibilités, dont DRBD multi-master et iSCSI sur un bon gros SAN bien gras. J'étais parti sur DRBD pour plusieurs raisons, aujourd'hui je vais vous parler de monter votre propre SAN avec multipath sans avoir à manger des pâtes pendant la prochaine décennie.

Rappel

On part du besoin de pouvoir exécuter des machines virtuelles sur plusieurs hyperviseurs, et de pouvoir interchanger ces hyperviseurs comme bon nous semble, à chaud comme à froid, et de pouvoir parer rapidement à une défaillance de l'un d'eux.

En conséquence, d'un point de vue purement stockage, on a deux chose à gérer :

• Mise à disposition d'un point de stockage bloc unique à toutes les machines
• Partitionnement de ce stockage avec gestion de verrous

Pour le partitionnement, ma solution est de passer par un VG, ou volume group LVM, partagé à l'aide de sanlock. Cela consiste a disposer d'un petit LV (logical volume) appelé lvmlock dédié au sein de ce VG, dont le rôle est simplement de consigner qui utilise quoi afin que les hyperviseurs se se mettre à plusieurs pour modifier une partition et donc très probablement la corrompre. En effet les systèmes de fichiers traditionnels ne supportent pas les accès concurrentiels.

Au moment de l'activation d'un LV sur un hyperviseur, LVM va dire "Attends voir, je vais demander à mon démon (lvmlockd) si j'ai le droit d'utiliser ce LV". lvmlockd peut supporter plusieurs gestionnaires de verrous, dont sanlock, ce qui est notre cas. Il va donc lui demander "Hello, nous sommes l'hyperviseur numéro X, est-ce qu'on peut monter ce LV s'il te plaît ? J'en ai un besoin exclusif si possible", et donc le petit sanlock prend sa redingote, sa bougie et son lorgnon de clerc, et va consulter le registre des verrous maintenu dans le LV lvmlock. Ensuite, deux possibilités :

• Le petit sanlock trouve un verrou actif sur le LV demandé, et il répond alors, l'air tout penaud : "Je suis vraiment navré, mais ce LV est déjà utilisé par une autre machine, je vous invite donc à réessayer plus tard.". Alors lvmlockd se voit contraint, non sans une certaine pointe de dépit, de devoir annuler l'activation du LV. Ce sont des choses qui arrivent.

• sanlock ne trouve pas de verrou actif pour ce LV, et il répond tout guilleret : "C'est avec quand plaisir que je vous confirme que vous pouvez activer localement ce LV dès l'instant. Je vais vous inscrire au registre afin de signaler à mes confrères que cette ressources vous est exclusivement allouée jusqu'à nouvel ordre de votre part". Ce qu'il s'empresse de faire avec le très agréable sentiment de travail accompli, comme seuls les petits processus peuvent le faire.

Lorsque lvmlockd revient voir sanlock à la désactivation du LV, c'est avec le même entrain que sanlock marque le verrou comme relâché dans son grimoire.

Pour les migrations, au lieu d'un verrou exclusif, il est possible de solliciter un verrou partagé, qui a vocation bien sûr de ne pas durer.

La scène décrite a besoin d'un décors, c'est à dire ici d'un point de stockage bloc. Comme les verrous sont gérés au niveau du partitionnement, ce stockage ne s'encombre pas de contrôler qui peut accéder à quoi.

DRBD ou iSCSI ?

Les deux ont des avantages indéniables, ceux de DRBD étant de ne pas nécessiter un équipement tiers (donc moins cher) et de permettre la réplication des données sur les différents serveurs. Cependant un gros soucis de DRBD... c'est qu'il n'est pas fait pour faire du multi-master infini. La réplication devient vite très instable et j'ai eu plusieurs séances d'arrachage des dernier cheveux qu'il me reste à devoir réparer un split-brain, ce cas où la synchronisation est par terre et les serveurs se mettent à écrire sur le stockage indépendamment, et la réconciliation est très très compliquée. Personnellement je n'ai jamais eu la chance de pouvoir les réconcilier, j'ai du à chaque fois reconstruire la réplication en invalidant l'un de mes serveurs et en lui faisant recopier son copain.

J'en ai eu assez de gérer ça (et les accros de DRBD me diront qu'ils me l'avaient bien dit). J'ai donc songé à la possibilité de changer de camp et de disposer d'un SAN, et face au coup exorbitant de ces bestioles, m'en faire un moi-même avec les moyens du bord.