début de l'article

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

@@ -0,0 +1,38 @@
+---
+title: Le SAN maison pas cher
+date: 2023-06-16
+author: raspbeguy
+template: post
+tags: 
+---
+
+Dans [un précédent article](/posts/la-virtu-pour-les-nuls-le-stockage), 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.