Dans un article précédent, j'ai examiné la possibilité de créer un serveur NFS tolérant aux pannes en utilisant DRBD et Proxmox. Cela s'est plutôt bien passé, mais nous ne nous reposons pas sur nos lauriers et maintenant nous allons essayer de "sortir tous les jus" de notre stockage.
Dans cet article, je vais vous expliquer comment créer une cible iSCSI tolérante aux pannes de cette manière, que nous utiliserons LVM pour découper en petits morceaux et l'utiliser pour des machines virtuelles.
C'est cette approche qui réduira la charge et augmentera la vitesse d'accès aux données plusieurs fois, ce qui est particulièrement bénéfique lorsqu'un accès concurrentiel aux données n'est pas requis, par exemple dans le cas où vous devez organiser le stockage des machines virtuelles.
Quelques mots sur DRBD
DRBD est une solution assez simple et mature, le code de la huitième version est adopté dans le cadre du noyau Linux. En fait, il représente un miroir réseau RAID1. La neuvième version a introduit la prise en charge du quorum et de la réplication avec plus de deux nœuds.
En fait, il vous permet de combiner des périphériques blocs sur plusieurs nœuds physiques en un seul réseau partagé commun.
En utilisant DRBD, vous pouvez obtenir des configurations très intéressantes. Aujourd'hui, nous allons parler d'iSCSI et de LVM.
Vous pouvez en savoir plus à ce sujet en lisant mon article précédent , où j'ai décrit cette solution en détail.
Quelques mots sur iSCSI
iSCSI est un protocole de livraison de périphérique de bloc sur un réseau.
Contrairement à NBD, il prend en charge l'autorisation, résout les pannes de réseau sans problème et prend en charge de nombreuses autres fonctions utiles, et surtout, il présente de très bonnes performances.
Il existe un grand nombre de ses implémentations, certaines d'entre elles sont également incluses dans le noyau et ne nécessitent pas de difficultés particulières pour sa configuration et sa connexion.
LVM en quelques mots
Il convient de mentionner que LINBIT a sa propre solution pour Proxmox, il devrait fonctionner hors de la boîte et permettre d'obtenir un résultat similaire, mais dans cet article, je ne voudrais pas me concentrer uniquement sur Proxmox et décrire une solution plus universelle qui convient à la fois à Proxmox et à toute autre chose, dans cet exemple, proxmox est utilisé uniquement comme moyen d'orchestration de conteneurs, en fait vous pouvez le remplacer par une autre solution, par exemple, lancer des conteneurs avec une cible dans Kubernetes.
Quant à Proxmox en particulier, il fonctionne très bien avec les LUN et LVM partagés, en utilisant uniquement ses propres pilotes standard.
Les avantages de LVM incluent le fait que son utilisation n'est pas quelque chose de révolutionnaire nouveau et insuffisamment rodé, mais au contraire, il présente une stabilité à sec, qui est généralement exigée du stockage. Il convient de mentionner que LVM est assez activement utilisé dans d'autres environnements, par exemple, dans OpenNebula ou Kubernetes, et y est assez bien pris en charge.
Ainsi, vous recevrez un stockage universel qui peut être utilisé dans différents systèmes (non seulement dans proxmox), en utilisant uniquement des pilotes prêts à l'emploi, sans besoin particulier de le modifier avec un fichier.
Malheureusement, lorsque vous choisissez une solution de stockage, vous devez toujours faire des compromis. Donc ici, cette solution ne vous donnera pas la même flexibilité que par exemple Ceph.
La taille du disque virtuel est limitée par la taille du groupe LVM, et la zone délimitée pour un disque virtuel spécifique sera nécessairement réallouée - cela améliore considérablement la vitesse d'accès aux données, mais ne permet pas le Thin-Provisioning (lorsque le disque virtuel prend moins d'espace qu'il ne l'est réellement). Il convient de mentionner que les performances de LVM s'affaiblissent beaucoup lors de l'utilisation d'instantanés, et donc la possibilité de leur utilisation gratuite est souvent éliminée.
Oui, LVM prend en charge les pools Thin-Provision qui sont dépourvus de cet inconvénient, mais malheureusement, leur utilisation n'est possible que dans le contexte d'un nœud et il n'y a aucun moyen de partager un pool Thin-Provision pour plusieurs nœuds du cluster.
Mais malgré ces lacunes, en raison de sa simplicité, LVM ne permet toujours pas aux concurrents de le contourner et de le pousser complètement hors du champ de bataille.
Avec une surcharge assez faible, LVM fournit toujours une solution très rapide, stable et assez flexible.
Schéma général
- Nous avons trois nœuds
- Chaque nœud possède un périphérique drbd distribué.
- En plus du périphérique drbd, un conteneur LXC avec une cible iSCSI est lancé.
- La cible est connectée aux trois nœuds.
- Un groupe LVM a été créé sur la cible connectée.
- Si nécessaire, le conteneur LXC peut se déplacer vers un autre nœud, avec la cible iSCSI
Personnalisation
Nous avons compris l'idée maintenant, passons à 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, vérifiez si tout va bien:
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 tgt1 drbdadm secondary tgt1
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 cible iSCSI 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=tgt1 \ --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
Configuration d'une cible iSCSI.
Parmi l'ensemble des cibles , j'ai choisi istgt , car il a les performances les plus élevées et fonctionne dans l'espace utilisateur.
Maintenant, connectons-nous à notre conteneur:
pct exec 101 bash
Installez les mises à jour et istgt :
apt-get update apt-get -y upgrade apt-get -y install istgt
Créez un fichier que nous transmettrons sur le réseau:
mkdir -p /data fallocate -l 740G /data/target1.img
Maintenant, nous devons écrire une configuration pour istgt /etc/istgt/istgt.conf :
[Global] Comment "Global section" NodeBase "iqn.2018-07.org.example.tgt1" PidFile /var/run/istgt.pid AuthFile /etc/istgt/auth.conf MediaDirectory /var/istgt LogFacility "local7" Timeout 30 NopInInterval 20 DiscoveryAuthMethod Auto MaxSessions 16 MaxConnections 4 MaxR2T 32 MaxOutstandingR2T 16 DefaultTime2Wait 2 DefaultTime2Retain 60 FirstBurstLength 262144 MaxBurstLength 1048576 MaxRecvDataSegmentLength 262144 InitialR2T Yes ImmediateData Yes DataPDUInOrder Yes DataSequenceInOrder Yes ErrorRecoveryLevel 0 [UnitControl] Comment "Internal Logical Unit Controller" AuthMethod CHAP Mutual AuthGroup AuthGroup10000 Portal UC1 127.0.0.1:3261 Netmask 127.0.0.1 [PortalGroup1] Comment "SINGLE PORT TEST" Portal DA1 192.168.1.11:3260 [InitiatorGroup1] Comment "Initiator Group1" InitiatorName "ALL" Netmask 192.168.1.0/24 [LogicalUnit1] Comment "Hard Disk Sample" TargetName disk1 TargetAlias "Data Disk1" Mapping PortalGroup1 InitiatorGroup1 AuthMethod Auto AuthGroup AuthGroup1 UseDigest Auto UnitType Disk LUN0 Storage /data/target1.img Auto
Redémarrez istgt:
systemctl restart istgt
Ceci termine le réglage cible
Configuration HA
Nous pouvons maintenant passer à la configuration du gestionnaire HA . Créons un groupe HA distinct pour notre appareil:
ha-manager groupadd tgt1 --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=tgt1 --max_relocate=3 --max_restart=3
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.
Ouvrez iSCSI
Puisque nous n'utilisons pas le multichemin, dans notre cas, il est recommandé de désactiver les vérifications de connexion périodiques sur les clients, ainsi que d'augmenter les délais d'attente pour la récupération de session dans /etc/iscsi/iscsid.conf .
node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 node.session.timeo.replacement_timeout = 86400
Utiliser
Proxmox
La cible iSCSI résultante peut être immédiatement connectée à Proxmox, sans oublier de décocher Use LUN Directly .
Immédiatement après cela, il sera possible de créer LVM par dessus, n'oubliez pas de cocher la case partagée :
Autres environnements
Si vous prévoyez d'utiliser cette solution dans un environnement différent, vous devrez peut-être installer une extension de cluster pour LVM au moment où il y a deux implémentations. CLVM et lvmlockd .
La configuration de CLVM n'est pas anodine et nécessite un gestionnaire de cluster fonctionnel.
Alors qu'en tant que deuxième méthode, lvmlockd n'est pas encore entièrement testé et commence tout juste à apparaître dans des référentiels stables.
Je recommande de lire un excellent article sur le blocage dans LVM
Lors de l'utilisation de LVM avec Proxmox, l' ajout de cluster n'est pas nécessaire , car la gestion du volume est assurée par proxmox lui-même, qui met à jour et surveille les métadonnées LVM indépendamment. Il en va de même pour OpenNebula , comme l'indique clairement la documentation officielle .