Probablement tous ceux qui ont été au moins une fois perplexes face à la recherche d'un stockage haute performance défini par logiciel ont tôt ou tard entendu parler de DRBD , ou peut-être même l'ont traité.
Certes, au sommet de la popularité de Ceph et GlusterFS , qui fonctionnent assez bien en principe, et surtout dès la sortie de la boîte, tout le monde en a juste oublié un peu. De plus, la version précédente ne prenait pas en charge la réplication sur plus de deux nœuds, et à cause de cela, des problèmes avec le split-brain étaient souvent rencontrés, ce qui n'a clairement pas ajouté à sa popularité.
La solution n'est vraiment pas nouvelle, mais assez compétitive. Avec des coûts relativement faibles pour le CPU et la RAM, DRBD fournit une synchronisation très rapide et sûre au niveau du périphérique de bloc . Pendant tout ce temps, les développeurs de LINBIT - DRBD ne s'arrêtent pas et l'affinent constamment. À partir de la version DRBD9 , il cesse d'être simplement un miroir de réseau et devient quelque chose de plus.
Tout d'abord, l'idée de créer un seul périphérique de bloc distribué pour plusieurs serveurs s'est retirée en arrière-plan, et maintenant LINBIT essaie de fournir des outils pour orchestrer et gérer de nombreux périphériques drbd dans un cluster qui sont créés au-dessus des partitions LVM et ZFS .
Par exemple, DRBD9 prend en charge jusqu'à 32 répliques, RDMA, nœuds sans disque et de nouveaux outils d'orchestration vous permettent d'utiliser des instantanés, une migration en ligne et bien plus encore.
Malgré le fait que DRBD9 dispose d'outils d'intégration avec Proxmox , Kubernetes , OpenStack et OpenNebula , ils sont actuellement en mode transitionnel, lorsque de nouveaux outils ne sont pas encore pris en charge partout, et les anciens seront annoncés comme obsolètes très bientôt. Ce sont DRBDmanage et Linstor .
Je profiterai de ce moment pour ne pas trop entrer dans les détails de chacun, mais pour examiner plus en détail la configuration et les principes de travail avec DRBD9 lui-même. Vous devez encore le comprendre, ne serait-ce que parce que la configuration à tolérance de pannes du contrôleur Linstor implique son installation sur l'un de ces appareils.
Dans cet article, je voudrais vous parler de DRBD9 et de la possibilité de son utilisation dans Proxmox sans plug-ins tiers.
DRBDmanage et Linstor
Tout d'abord, il convient de mentionner une fois de plus à propos de DRBDmanage , qui s'intègre très bien dans Proxmox . LINBIT fournit un plugin DRBDmanage prêt à l'emploi pour Proxmox qui vous permet d'utiliser toutes ses fonctions directement à partir de l'interface Proxmox .
Cela a l'air vraiment incroyable, mais a malheureusement quelques inconvénients.
- Tout d'abord, les noms de volume balisés, le groupe LVM ou le pool ZFS doivent être nommés
drbdpool . - Incapacité à utiliser plusieurs pools par nœud
- En raison des spécificités de la solution, le volume du contrôleur ne peut être que sur un LVM normal et pas autrement
- Problèmes de dbus périodiques, qui sont étroitement utilisés par DRBDmanage pour interagir avec les nœuds.
En conséquence, LINBIT a décidé de remplacer toute la logique DRBDmanage complexe par une application simple qui communique avec les nœuds à l'aide d'une connexion TCP régulière et fonctionne sans aucune magie. Il y avait donc Linstor .
Linstor fonctionne vraiment très bien. Malheureusement, les développeurs ont choisi java comme langue principale pour écrire Linstor-server, mais ne vous inquiétez pas, car Linstor lui-même ne s'intéresse qu'à la distribution des configurations DRBD et au découpage des partitions LVM / ZFS sur les nœuds.
Les deux solutions sont gratuites et distribuées sous la licence gratuite GPL3.
Vous pouvez lire sur chacun d'eux et sur la configuration du plug-in susmentionné pour Proxmox sur le wiki officiel de Proxmox
Serveur de basculement NFS
Malheureusement, au moment de la rédaction de ce document, Linstor n'avait qu'une intégration avec Kubernetes . Mais à la fin de l'année, des pilotes sont attendus pour le reste des systèmes Proxmox , OpenNebula , OpenStack .
Mais jusqu'à présent, il n'y a pas de solution toute faite, mais nous n'aimons pas en quelque sorte l'ancienne. Essayons d'utiliser DRBD9 à l'ancienne pour organiser l' accès NFS à une partition partagée.
Néanmoins, cette solution s'avérera également non sans avantages, car le serveur NFS vous permettra d'organiser un accès compétitif au système de fichiers du référentiel à partir de plusieurs serveurs sans avoir besoin de systèmes de fichiers de cluster complexes avec DLM, tels que OCFS et GFS2.
Dans ce cas, vous pourrez changer les rôles du nœud principal / secondaire simplement en migrant le conteneur avec le serveur NFS dans l'interface Proxmox.
Vous pouvez également stocker tous les fichiers à l'intérieur de ce système de fichiers, ainsi que les disques virtuels et les sauvegardes.
Si vous utilisez Kubernetes, vous pourrez organiser l'accès ReadWriteMany pour vos volumes persistants .
Conteneurs Proxmox et LXC
Maintenant, la question est: pourquoi Proxmox?
En principe, pour construire un tel schéma, nous pourrions utiliser Kubernetes ainsi que le schéma habituel avec un gestionnaire de cluster. Mais Proxmox fournit une interface prête à l'emploi, très multifonctionnelle et à la fois simple et intuitive pour presque tout ce dont vous avez besoin. Il est prêt à être mis en cluster et prend en charge le mécanisme d' escrime basé sur softdog. Et lorsque vous utilisez des conteneurs LXC, cela vous permet de minimiser les délais lors du changement.
La solution obtenue n'aura pas un seul point de défaillance .
En fait, nous utiliserons Proxmox principalement comme gestionnaire de cluster , où nous pouvons considérer un conteneur LXC distinct comme un service s'exécutant dans un cluster HA classique, à la différence près que le conteneur est également livré avec son système racine . Autrement dit, vous n'avez pas besoin d'installer plusieurs instances de service sur chaque serveur séparément, vous ne pouvez le faire qu'une seule fois à l'intérieur du conteneur.
Si vous avez déjà travaillé avec un logiciel de gestion de cluster et fourni une haute disponibilité pour les applications, vous comprendrez ce que je veux dire.
Schéma général
Notre solution ressemblera au schéma de réplication standard d'une base de données.
- Nous avons trois nœuds
- Chaque nœud possède un périphérique drbd distribué.
- L'appareil dispose d'un système de fichiers standard ( ext4 )
- Un seul serveur peut être maître
- Le serveur NFS dans le conteneur LXC est lancé sur l'assistant.
- Tous les nœuds accèdent à l'appareil strictement via NFS.
- Si nécessaire, l'assistant peut se déplacer vers un autre nœud, avec le serveur NFS
DRBD9 a une fonctionnalité très cool qui simplifie considérablement tout:
Le périphérique drbd devient automatiquement primaire au moment où il est monté sur un nœud. Si le périphérique est marqué comme principal , toute tentative de le monter sur un autre nœud entraînera une erreur d'accès. Cela garantit le blocage et une protection garantie contre l'accès simultané à l'appareil.
Pourquoi tout cela simplifie-t-il grandement? Parce que lorsque le conteneur démarre, Proxmox monte automatiquement ce périphérique et il devient principal sur ce nœud, et lorsque le conteneur s'arrête, il le démonte au contraire et le périphérique redevient secondaire .
Ainsi, nous n'avons plus à nous soucier de changer de périphérique primaire / secondaire , Proxmox le fera automatiquement , Hourra!
Configuration DRBD
Eh bien, nous avons compris l'idée. Passons maintenant à la mise en œuvre.
Par défaut , la huitième version de drbd est fournie avec le noyau Linux , malheureusement elle ne nous convient pas et nous devons installer la neuvième version du module.
Connectez le référentiel LINBIT et installez tout ce dont vous avez besoin:
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers - pve-headers noyau nécessaires pour construire le moduledrbd-dkms - module du noyau au format DKMSdrbd-utils - utilitaires de gestion de base de DRBDdrbdtop est un outil interactif comme top pour DRBD uniquement
Après avoir installé le module, nous vérifierons si tout est en ordre avec lui:
Si vous voyez la huitième version dans la sortie de la commande, alors quelque chose s'est mal passé et le module du noyau dans l'arborescence est chargé. Vérifiez l' dkms status connaître la raison.
Chaque nœud que nous avons aura le même périphérique drbd fonctionnant au-dessus des partitions régulières. Nous devons d'abord préparer cette section pour drbd sur chaque nœud.
Une telle partition peut être n'importe quel périphérique bloc , elle peut être lvm, zvol, une partition de disque ou le disque entier. Dans cet article, j'utiliserai un disque nvme séparé avec une partition sous drbd: /dev/nvme1n1p1
Il convient de noter que les noms des appareils ont parfois tendance à changer, il est donc préférable de prendre immédiatement l'habitude d'utiliser un lien symbolique constant vers l'appareil.
Vous pouvez trouver un tel lien symbolique pour /dev/nvme1n1p1 cette façon:
Nous décrivons notre ressource sur les trois nœuds:
Il est conseillé d'utiliser un réseau séparé pour la synchronisation drbd.
Maintenant, créez les métadonnées pour drbd et exécutez-le:
Répétez ces étapes sur les trois nœuds et vérifiez l'état:
Maintenant, notre disque incohérent est sur les trois nœuds, c'est parce que drbd ne sait pas quel disque doit être pris comme original. Nous devons marquer l'un d'eux comme primaire pour que son état soit synchronisé avec les autres nœuds:
drbdadm primary --force nfs1 drbdadm secondary nfs1
Immédiatement après cela, la synchronisation commencera:
Nous n'avons pas à attendre qu'il se termine et nous pouvons effectuer d'autres étapes en parallèle. Ils peuvent être exécutés sur n'importe quel nœud , quel que soit son état actuel du disque local dans DRBD. Toutes les demandes seront automatiquement redirigées vers l'appareil avec l'état UpToDate .
N'oubliez pas d'activer l' exécution automatique du service drbd sur les nœuds:
systemctl enable drbd.service
Configuration d'un conteneur LXC
Nous allons omettre la partie configuration du cluster Proxmox de trois nœuds, cette partie est bien décrite dans le wiki officiel
Comme je l'ai déjà dit, notre serveur NFS fonctionnera dans un conteneur LXC . Nous conserverons le conteneur sur le périphérique /dev/drbd100 que nous venons de créer.
Nous devons d'abord créer un système de fichiers dessus:
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
Proxmox inclut par défaut une protection multimount au niveau du système de fichiers, en principe, nous pouvons nous en passer, car DRBD a sa propre protection par défaut, il interdit simplement le deuxième primaire pour l'appareil, mais la prudence ne nous fait pas de mal.
Téléchargez maintenant le modèle Ubuntu:
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
Et créez notre conteneur à partir de celui-ci:
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=nfs1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
Dans cette commande, nous indiquons que le système racine de notre conteneur sera sur le périphérique /dev/drbd100 et ajoutons le paramètre shared=1 pour permettre la migration du conteneur entre les nœuds.
En cas de problème, vous pouvez toujours le corriger via l'interface Proxmox ou dans la /etc/pve/lxc/101.conf conteneur /etc/pve/lxc/101.conf
Proxmox déballera le modèle et préparera le système racine du conteneur pour nous. Après cela, nous pouvons lancer notre conteneur:
pct start 101
Configurez un serveur NFS.
Par défaut, Proxmox n'autorise pas le serveur NFS à s'exécuter dans le conteneur, mais il existe plusieurs façons de l'activer.
L'un d'eux consiste simplement à ajouter lxc.apparmor.profile: unconfined à la /etc/pve/lxc/100.conf notre conteneur /etc/pve/lxc/100.conf .
Ou nous pouvons activer NFS pour tous les conteneurs sur une base continue, pour cela, nous devons mettre à jour le modèle standard pour LXC sur tous les nœuds, ajouter les lignes suivantes à /etc/apparmor.d/lxc/lxc-default-cgns :
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
Après les modifications, redémarrez le conteneur:
pct shutdown 101 pct start 101
Maintenant, connectons-nous:
pct exec 101 bash
Installez les mises à jour et le serveur NFS :
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
Créez une exportation :
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
Configuration HA
Au moment de l'écriture, proxmox HA-manager a un bogue qui ne permet pas au conteneur HA de terminer son travail avec succès, à la suite de quoi les processus d' espace noyau du serveur nfs qui n'ont pas été complètement tués empêchent le périphérique drbd de quitter le secondaire . Si vous avez déjà rencontré une telle situation, vous ne devez pas paniquer et simplement exécuter killall -9 nfsd sur le nœud où le conteneur a été lancé, puis le périphérique drbd doit "libérer" et il ira au secondaire .
Pour corriger ce bogue, exécutez les commandes suivantes sur tous les nœuds:
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
Nous pouvons maintenant passer à la configuration du gestionnaire HA . Créons un groupe HA distinct pour notre appareil:
ha-manager groupadd nfs1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
Notre ressource ne fonctionnera que sur les nœuds spécifiés pour ce groupe. Ajoutez notre conteneur à ce groupe:
ha-manager add ct:101 --group=nfs1 --max_relocate=3 --max_restart=3
C’est tout. C'est simple, non?
La boule nfs résultante peut être immédiatement connectée à Proxmox pour stocker et exécuter d'autres machines virtuelles et conteneurs.
Recommandations et réglages
DRBD
Comme je l'ai noté ci-dessus, il est toujours conseillé d'utiliser un réseau distinct pour la réplication. Il est fortement conseillé d'utiliser des adaptateurs réseau 10 gigabits , sinon vous aurez une vitesse de port.
Si la réplication semble assez lente, essayez certaines des options pour DRBD . Voici la config, qui à mon avis est optimale pour mon réseau 10G :
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
Vous pouvez obtenir plus d'informations sur chaque paramètre dans la documentation officielle DRBD.
Serveur NFS
Pour accélérer le fonctionnement du serveur NFS, il peut être utile d'augmenter le nombre total d' instances en cours d'exécution du serveur NFS. Par défaut - 8 , personnellement, cela m'a aidé à augmenter ce nombre à 64 .
Pour ce faire, mettez à jour le paramètre RPCNFSDCOUNT=64 dans /etc/default/nfs-kernel-server .
Et redémarrez les démons:
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3 vs NFSv4
Connaissez-vous la différence entre NFSv3 et NFSv4 ?
- NFSv3 est un protocole sans état; en règle générale, il tolère mieux les échecs et récupère plus rapidement.
- NFSv4 est un protocole avec état , il fonctionne plus rapidement et peut être lié à certains ports TCP, mais en raison de la présence de l'état, il est plus sensible aux pannes. Il a également la possibilité d'utiliser l'authentification à l'aide de Kerberos et un tas d'autres fonctionnalités intéressantes.
Cependant, lorsque vous exécutez showmount -e nfs_server , le protocole NFSv3 est utilisé. Proxmox utilise également NFSv3. NFSv3 est également couramment utilisé pour organiser les machines de démarrage réseau.
En général, si vous n'avez aucune raison particulière d'utiliser NFSv4, essayez d'utiliser NFSv3 car il est moins pénible pour les échecs en raison de l'absence d'un état en tant que tel.
Vous pouvez monter la balle à l'aide de NFSv3 en spécifiant le paramètre -o vers=3 pour la commande de montage :
mount -o vers=3 nfs_server:/share /mnt
Si vous le souhaitez, vous pouvez désactiver NFSv4 pour le serveur, pour ce faire, ajoutez l'option --no-nfs-version 4 à la variable --no-nfs-version 4 et redémarrez le serveur, par exemple:
RPCNFSDCOUNT="64 --no-nfs-version 4"
iSCSI et LVM
De même, un démon tgt standard peut être configuré à l'intérieur du conteneur, iSCSI produira des performances considérablement plus élevées pour les opérations d'E / S et le conteneur fonctionnera plus facilement car le serveur tgt fonctionne complètement dans l'espace utilisateur.
En règle générale, un LUN exporté est découpé en plusieurs morceaux à l'aide de LVM . Cependant, il y a plusieurs nuances à considérer, par exemple: comment les verrous LVM sont fournis pour partager un groupe exporté sur plusieurs hôtes.
Peut-être ces nuances et d'autres que je décrirai dans le prochain article .