Y a-t-il parmi nous (les utilisateurs de Ceph) ceux qui n'aiment pas « l'extrême professionnel » ?
Peu probable — sinon nous ne nous serions pas lancés dans ce produit extrêmement intéressant et amusant.
Beaucoup de ceux qui ont travaillé avec Ceph ont rencontré un cas peu fréquent (voire très rare) mais parfois demandé — connecter Ceph via iSCSI ou FC. Pourquoi ? Eh bien, par exemple, pour fournir une image de Ceph à un serveur Windows ou Solaris qui n'est pas encore virtualisé. Ou à un serveur virtualisé, mais via un hyperviseur qui ne supporte pas Ceph — et ils sont, comme nous le savons, assez nombreux. Par exemple ? Eh bien, des exemples comme HyperV ou ESXi, qui sont largement utilisés. Et si la tâche consiste à fournir une image de Ceph à une machine virtuelle, cela devient une tâche plutôt intéressante.
Donc, donné :
- un cluster Ceph déjà opérationnel
- une image existante à fournir via iSCSI
- Nom du pool mypool, nom de l'image myimage
Prêt à commencer ?
Tout d'abord, lorsque nous parlons de FC ou d'iSCSI, nous rencontrons des entités telles que l'initiateur (initiator) et la cible (target). La cible est en fait le serveur, l'initiateur — le client. Notre tâche est de fournir l'image Ceph à l'initiateur avec un minimum d'efforts. Donc, nous devons déployer la cible. Mais où, sur quel ordinateur ?
Heureusement, dans le cluster Ceph, nous avons au moins un composant dont l'adresse IP est fixe et sur lequel l'un des composants les plus importants de Ceph est configuré, et ce composant est le moniteur. Par conséquent, nous installons la cible iSCSI sur le moniteur (et l'initiateur aussi, au moins pour les tests). Je l'ai fait sur CentOS, mais pour toute autre distribution, la solution convient également — il suffit d'installer les paquets de la manière acceptable pour votre distribution.
# yum -y install iscsi-initiator-utils targetcli
Quel est le but des paquets installés ?
- targetcli — un utilitaire de gestion de la cible SCSI intégrée dans le noyau Linux
- iscsi-initiator-utils — un paquet d'outils utilisés pour gérer également l'initiateur iSCSI intégré dans le noyau Linux
Pour soumettre une image via iSCSI à l'initiateur, il y a deux façons de procéder : utiliser un backend de cible en espace utilisateur ou connecter l'image en tant que périphérique de bloc visible par le système d'exploitation et l'exporter via iSCSI. Nous allons opter pour cette seconde méthode, car le backend en espace utilisateur est encore dans un état "expérimental" et n'est pas tout à fait prêt pour un usage en production. De plus, il y a des pièges avec lesquels on peut argumenter longuement (et oh désespoir !) commenter.
Si nous utilisons une distribution stable avec un long cycle de support, le cœur est généralement d'une version très ancienne. Par exemple, dans CentOS 7, il s'agit de la version 3.10.*, dans CentOS 8, de la version 4.19. Or, nous avons besoin d'un noyau d'au moins 5.3 (voire 5.4) ou plus récent. Pourquoi ? Parce que par défaut, les images dans Ceph sont livrées avec un ensemble d'options qui ne sont pas compatibles avec de anciens noyaux. Cela signifie que nous devons activer un dépôt avec un nouveau noyau pour notre distribution (par exemple, pour CentOS, c'est elrepo), installer le nouveau noyau et redémarrer le système pour travailler avec ce nouveau noyau :
- Connectons-nous au moniteur choisi pour l'expérimentation.
- Ajoutons les dépôts elrepo selon les instructions —
- Installons le noyau : yum -y —enablerepo=elrepo-kernel install kernel-ml
- Redémarrons le serveur avec le moniteur (nous avons bien trois moniteurs, n'est-ce pas ?)
Connectons l'image en tant que périphérique de bloc.
# carte rbd monpool/monimage
/dev/rbd0
Il ne reste plus qu'à configurer la cible. Dans cet exemple, je vais configurer la cible en mode dit "demo" — sans authentification, visible et accessible à tous. Dans un environnement de production, vous souhaiterez probablement configurer une authentification, mais c'est un peu hors sujet pour cet exercice juste pour le plaisir.
Créons un backend nommé disk1 associé au fichier /dev/rbd/mypool/myimage. Le fichier spécifié est un lien symbolique automatiquement créé par le démon udev vers /dev/rbd0. Nous utilisons précisément le lien symbolique, car le nom du périphérique rbd peut changer en raison de l'ordre de connexion des images Ceph à l'hôte.
Créons le backend :
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Créons la cible iSCSI :
# targetcli /iscsi créer iqn.2020-01.demo.ceph:mypool
Connectons le backend en tant que LUN à la cible :
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Ajustons la cible pour le mode demo :
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribut demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribut generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribut cache_dynamic_acls=1
Enregistrons la configuration :
# targetcli saveconfig
Vérifions l'existence de la cible :
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Connectons la cible :
# iscsiadm -m node --login
Connexion à [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiple)
Connexion à [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] réussie.
Si vous avez tout fait correctement, un nouveau disque apparaîtra sur le serveur, qui ressemble à un périphérique SCSI, mais qui est en fait une image de Ceph, accessible via le ciblage iSCSI. Pour éviter des problèmes au démarrage, il est préférable de supprimer le disque connecté et la cible découverte de l'initiateur local :
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Tout ce qui reste à faire est de persister la configuration, afin que l'image se connecte automatiquement et que la cible démarre après la connexion. Le démarrage de la cible se compose de deux étapes : connexion RBD et démarrage de la cible elle-même.
Commençons par configurer la connexion automatique des images RBD à l'hôte. Cela se fait en ajoutant des lignes dans le fichier /etc/ceph/rbdmap :
# chat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/mymage id=admin
# systemctl activer rbdmap
La restauration de la configuration de la cible est un peu plus compliquée — nous devons écrire une unité pour systemd, qui restaurera la configuration :
# chat /usr/lib/systemd/system/scsi-target.service
[Unité]
Description=Démarrer la cible iSCSI
After=network-online.target rbdmap.service
Before=remote-fs-pre.target
Wants=network-online.target remote-fs-pre.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/targetcli restoreconfig
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable scsi-target
Le test final — redémarrons à nouveau notre moniteur (qui est maintenant la cible iSCSI). Il convient de noter que si nous n'avions pas nettoyé la base de l'initiateur avec la commande iscsiadm -n discoverydb -o delete … nous aurions pu obtenir un serveur qui ne démarre pas ou qui démarre lentement.
Que reste-t-il ?
Configurer l'initiateur sur le serveur où nous voulons transmettre la cible.
Comment assurer la résilience de notre cible ?
Il est possible de configurer de manière similaire des cibles sur d'autres moniteurs et d'organiser un multipath (vmware le comprendra et fonctionnera même, Hyper-V ne le comprendra pas — des verrouillages SCSI sont nécessaires). Étant donné que le client Ceph du noyau n'utilise pas de mise en cache, cela fonctionne parfaitement. Une autre option est de créer une ressource en cluster composée de trois composants : la cible dédiée et les services rbdmap et scsi-target, et de gérer cette ressource via des outils de clustering (qui a dit pacemaker ?) adresses IP Comme on peut le comprendre, cet article est un peu une blague — mais j'ai essayé d'aborder « rapidement et par des exemples » plusieurs sujets assez populaires — la cible iSCSI, qui peut tout à fait ne pas exporter des images Ceph — mais par exemple exporter des volumes LVM, les bases du fonctionnement avec l'initiateur iSCSI (comment scanner la cible, comment se connecter à la cible, se déconnecter, supprimer l'enregistrement de la cible de la base), la rédaction de votre propre unité pour systemd et quelques autres aspects.
En guise de postface
Comme vous pouvez le comprendre, cet article est un peu une blague — mais j'ai essayé de traiter « rapidement et par des exemples » plusieurs sujets assez populaires en même temps — iSCSI target, qui peut tout à fait ne pas nécessairement exporter des images Ceph — mais par exemple exporter des volumes LVM, les bases du travail avec un initiateur iSCSI (comment scanner un target, comment se connecter à un target, se déconnecter, supprimer l'enregistrement d'un target de la base), l'écriture de votre propre unité pour systemd et quelques autres.
J'espère que même si vous ne répétez pas cette expérience dans son intégralité, au moins quelque chose de cet article vous sera utile.
Source : habr.com
