Stockage LINSTOR et son intégration avec OpenNebula

Il n'y a pas si longtemps, les gars de LINBIT ont présenté leur nouvelle solution SDS — Linstor. C'est un stockage complètement libre basé sur des technologies éprouvées : DRBD, LVM, ZFS. Linstor allie simplicité et architecture bien conçue, ce qui permet d'atteindre une stabilité et des résultats assez impressionnants.

Aujourd'hui, je voudrais en parler un peu plus en détail et montrer à quel point il est simple de l'intégrer avec OpenNebula en utilisant linstor_un — un nouveau pilote que j'ai développé spécialement pour cela.

Linstor, associé à OpenNebula, permet de construire un cloud rapide et fiable, qui peut être déployé sans problème sur une infrastructure propre.

Architecture de Linstor

Linstor n'est ni un système de fichiers ni un stockage en bloc à lui seul, Linstor est un orchestrateur qui fournit une couche d'abstraction permettant d'automatiser la création de volumes dans LVM ou ZFS et de les répliquer avec DRBD9.

Bousculons les stéréotypes

Mais attendez, DRBD ? — Pourquoi l'automatiser et comment cela peut-il fonctionner ?

Souvenons-nous du passé, lorsque DRBD8 était très populaire. Son utilisation standard supposait la création d'un grand dispositif de blocs et la découpe de celui-ci en plusieurs petits morceaux, à l'aide de LVM. Une sorte de RAID-1 mdadm mais avec réplique sur le réseau.

Ce type d'approche n'est pas sans défauts, et c'est pourquoi avec l'arrivée de DRBD9, les principes de construction du stockage ont changé, désormais pour chaque machine virtuelle, un dispositif DRBD distinct est créé.

L'approche avec des dispositifs de blocs indépendants permet une meilleure utilisation de l'espace dans le cluster, et ajoute une série de possibilités supplémentaires. Par exemple, pour chaque dispositif, on peut définir le nombre de répliques, leur emplacement et des réglages individuels. Il est facile de les créer/détruire, de faire des instantanés, de modifier leur taille, d'activer le chiffrement et bien plus encore. Il est à noter que DRBD9 prend également en charge le quorum, ce qui permet d'éviter les situations de split-brain.

Ressources et backends

En créant un nouveau dispositif de blocs, Linstor place le nombre requis de répliques sur différentes nœuds dans le cluster. Chaque réplique sera appelée ressource DRBD.

Les ressources se divisent en deux types :

• Ressource de données — représentent un dispositif DRBD situé sur un nœud dans un pool LVM ou ZFS.
  Actuellement, il y a un support pour plusieurs backends et leur nombre ne cesse d'augmenter. Le support de LVM, ThinLVM et ZFS est disponible. Les deux derniers permettent de créer et d'utiliser des snapshots.
• Ressource sans disque — représente un dispositif DRBD situé sur un nœud sans backend, mais permettant d'interagir avec lui comme avec un dispositif de bloc classique, toutes les opérations de lecture/écriture seront redirigées vers des ressources de données. L'analogue le plus proche des ressources sans disque est un LUN iSCSI.

Chaque ressource DRBD peut avoir jusqu'à 8 répliques, et une seule d'entre elles peut être active par défaut — Primaire, toutes les autres seront Secondaire et leur utilisation sera impossible tant qu'il y a au moins un Primaire, c'est-à-dire qu'elles répliqueront simplement les données entre elles.

En montant le dispositif DRBD dans le système, il devient automatiquement Primaire, ainsi même une ressource sans disque, dans la terminologie DRBD, peut être Primaire.

Alors, pourquoi a-t-on besoin de Linstor ?

En confiant toutes les tâches gourmandes en ressources au noyau, Linstor se présente essentiellement comme une application Java ordinaire qui permet d'automatiser facilement la création de ressources DRBD.
Chaque ressource créée sera un cluster DRBD indépendant, qui fonctionne de manière autonome, indépendamment de l'état du plan de contrôle et des autres ressources DRBD.

Linstor se compose de deux composants :

• Linstor-controller — Le contrôleur principal, qui fournit une API pour créer et gérer des ressources. Il communique également avec les satellites, vérifiant l'espace libre sur ceux-ci, et envoie des tâches pour la création et la suppression de nouvelles ressources. Il est exécuté en instance unique et utilise une base de données qui peut être interne (H2) ou externe (PostgreSQL, MySQL, MariaDB).
• Linstor-satellite — S'installe sur tous les nœuds de stockage et fournit au contrôleur des informations sur l'espace disponible, ainsi qu'exécute des tâches reçues du contrôleur pour créer et supprimer de nouveaux volumes et des dispositifs DRBD au-dessus d'eux.

Linstor opère avec les concepts clés suivants :

• Nœud — un serveur physique, sur lequel les ressources DRBD seront créées et utilisées.
• Storage Pool — un pool LVM ou ZFS, créé sur le nœud où les ressources DRBD seront hébergées. Un pool sans disque est également possible — c'est un pool qui ne contiendra que des ressources sans disque.
• Définition de la ressource — Définition de la ressource, c'est essentiellement un prototype qui décrit le nom et toutes ses propriétés.
• Définition du volume — Définition d'un volume. Chaque ressource peut être composée de plusieurs volumes, chaque volume doit avoir une taille.
• Ressource — Instance créée d'un dispositif de bloc, chaque ressource doit être placée sur un certain nœud et dans un pool de stockage.

Installation de Linstor

Je recommande d'utiliser Ubuntu, car il existe un PPA prêt à l'emploi:

add-apt-repository ppa:linbit/linbit-drbd9-stack
apt-get update

Ou Debian, où Linstor peut être installé depuis le dépôt officiel pour Proxmox :

wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" > 
    /etc/apt/sources.list.d/linbit.list
apt-get update

Contrôleur

Ici, c'est simple :

apt-get install linstor-controller linstor-client
systemctl enable linstor-controller
systemctl start linstor-controller

Nœuds de stockage

Actuellement, le noyau Linux fournit un module de noyau in-tree DRBD8, malheureusement il ne nous convient pas et nous devons installer DRBD9:

apt-get install drbd-dkms

Dans la pratique, la plupart des difficultés surviennent lorsque le module DRBD8 est chargé dans le système, et non DRBD9. Heureusement, cela peut être facilement vérifié en exécutant :

modprobe drbd
cat /proc/drbd

Si vous voyez version: 9 — tout va bien, si version: 8 — cela signifie que quelque chose s'est mal passé et que vous devez prendre des mesures supplémentaires pour comprendre les raisons.

Maintenant, installons linstor-satellite et drbd-utils:

apt-get install linstor-satellite drbd-utils
systemctl enable linstor-satellite
systemctl start linstor-satellite

Création du cluster

Pools de stockage et nœuds

Pour le backend, nous allons prendre ThinLVM, car c'est le plus simple et qu'il prend en charge les instantanés.
Installez lvm2, si vous ne l'avez pas encore fait, créons un pool ThinLVM sur tous nos nœuds de stockage :

sudo vgcreate drbdpool /dev/sdb
sudo lvcreate -L 800G -T drbdpool/thinpool

Toutes les actions suivantes peuvent être effectuées directement sur le contrôleur :

Ajoutons nos nœuds :

linstor node create node1 127.0.0.11
linstor node create node2 127.0.0.12
linstor node create node3 127.0.0.13

Créons des pools de stockage :

linstor storage-pool create lvmthin node1 data drbdpool/thinpool
linstor storage-pool create lvmthin node2 data drbdpool/thinpool
linstor storage-pool create lvmthin node3 data drbdpool/thinpool

Vérifions maintenant les pools créés :

linstor storage-pool list

Si tout a été fait correctement, nous devrions voir quelque chose comme :

+-------------------------------------------------------------------------------------------------------+
| StockagePool | Nœud  | Pilote   | NomDuPool        | CapacitéLibre | CapacitéTotale | SupporteLesSnapshots |
|-------------------------------------------------------------------------------------------------------|
| données      | nœud1 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | vrai              |
| données      | nœud2 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | vrai              |
| données      | nœud3 | LVM_THIN | drbdpool/thinpool |       64 GiB |        64 GiB | vrai              |
+-------------------------------------------------------------------------------------------------------+

Ressources DRBD

Essayons maintenant de créer notre nouvelle ressource DRBD :

linstor resource-definition create myres
linstor volume-definition create myres 1G
linstor resource create myres --auto-place 2

Vérifions les ressources créées :

linstor resource list 

+------------------------------------------------------------------------------------------------------+
| Nœud  | Ressource | StockagePool | NuméroVolume | MinorNr | NomDuDispositif  | Alloué   | EnUtilisation  |    État |
|------------------------------------------------------------------------------------------------------|
| nœud1 | myres    | données      | 0        | 1084    | /dev/drbd1084 | 52 KiB   | Non utilisé | À jour |
| nœud2 | myres    | données      | 0        | 1084    | /dev/drbd1084 | 52 KiB   | Non utilisé | À jour |
+------------------------------------------------------------------------------------------------------+

Excellent ! — nous voyons que la ressource a été créée sur les deux premiers nœuds, nous pouvons également essayer de créer une ressource sans disque sur le troisième :

linstor resource create --diskless nœud3 myres

Sur les nœuds, vous trouverez toujours cet appareil comme /dev/drbd1084 ou /dev/drbd/by-res/myres/0

C'est ainsi que fonctionne Linstor, vous pouvez obtenir plus d'informations à partir de la documentation officielle.

Je vais maintenant parler de l'intégration avec OpenNebula

Configuration d'OpenNebula

Je ne vais pas entrer dans les détails sur le processus de configuration d'OpenNebula, car toutes les étapes sont décrites en détail dans la documentation officielle, que je vous recommande de consulter, je vais juste parler de l'intégration d'OpenNebula avec Linstor.

linstor_un

Pour résoudre ce problème, j'ai écrit mon propre pilote — linstor_un, actuellement il est disponible sous forme de plugin et doit être installé séparément.

Toute l'installation se fait sur les nœuds frontend d'OpenNebula et ne nécessite aucune action supplémentaire sur les nœuds compute.

Tout d'abord, nous devons nous assurer que nous avons jq et linstor-client:

apt-get install jq linstor-client

Commande linstor node list devrait afficher la liste des nœuds. Tous les nœuds compute d'OpenNebula doivent être ajoutés au cluster Linstor.

Téléchargeons et installons le plugin :

curl -L https://github.com/OpenNebula/addon-linstor_un/archive/master.tar.gz | tar -xzvf - -C /tmp

mv /tmp/addon-linstor_un-master/vmm/kvm/* /var/lib/one/remotes/vmm/kvm/

mkdir -p /var/lib/one/remotes/etc/datastore/linstor_un
mv /tmp/addon-linstor_un-master/datastore/linstor_un/linstor_un.conf /var/lib/one/remotes/etc/datastore/linstor_un/linstor_un.conf

mv /tmp/addon-linstor_un-master/datastore/linstor_un /var/lib/one/remotes/datastore/linstor_un
mv /tmp/addon-linstor_un-master/tm/linstor_un /var/lib/one/remotes/tm/linstor_un

rm -rf /tmp/addon-linstor_un-master

Maintenant, nous devons l'ajouter à la configuration OpenNebula, pour cela, nous suivons les étapes simples décrites ici.

Après cela, nous redémarrerons OpenNebula :

systemctl restart opennebula

Et nous ajouterons nos datastores, système :

cat > system-ds.conf <<EOT
NAME="linstor-system"
TYPE="SYSTEM_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
CLONE_MODE="snapshot"
CHECKPOINT_AUTO_PLACE="1"
BRIDGE_LIST="node1 node2 node3"
TM_MAD="linstor_un"
EOT

onedatastore create system-ds.conf

Et le stockage des images :

cat > images-ds.conf <<EOT
NAME="linstor-images"
TYPE="IMAGE_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
BRIDGE_LIST="node1 node2 node3"
DISK_TYPE="BLOCK"
DS_MAD="linstor_un"
TM_MAD="linstor_un"
EOT

onedatastore create images-ds.conf

• Paramètre AUTO_PLACE indique le nombre de répliques de données qui seront créées pour chaque nouvelle image dans OpenNebula.
• Paramètre CLONE_MODE indique comment les images seront clonées lors de la création de nouvelles machines virtuelles, snapshot — un snapshot de l'image sera créé et la machine virtuelle sera déployée à partir du snapshot, copy — une copie complète de l'image sera faite pour chaque machine virtuelle.
• Dans BRIDGE_LIST il est recommandé d'indiquer tous les nœuds qui seront utilisés pour effectuer les opérations de clonage des images.

La liste complète des paramètres pris en charge est fournie dans README .

À ce stade, la configuration est terminée, vous pouvez maintenant charger un appliance depuis le OpenNebula Marketplace et créer des machines virtuelles à partir de celle-ci.

Lien vers le projet :
https://github.com/OpenNebula/addon-linstor_un

Source : habr.com