Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Enterprise Storage 7.1 / Guide de déploiement / Déploiement de la grappe Ceph / Déploiement de services supplémentaires
S'applique à SUSE Enterprise Storage 7.1

9 Déploiement de services supplémentaires

9.1 Installation d'une passerelle iSCSI

iSCSI est un protocole SAN (Storage area network) qui permet aux clients (appelés initiateurs) d'envoyer des commandes SCSI aux périphériques de stockage SCSI (cibles) sur des serveurs distants. SUSE Enterprise Storage 7.1 comprend une interface qui ouvre la gestion du stockage Ceph aux clients hétérogènes, tels que Microsoft Windows* et VMware* vSphere, via le protocole iSCSI. L'accès iSCSI multipath assure la disponibilité et l'évolutivité à ces clients, et le protocole iSCSI standard fournit également une couche supplémentaire d'isolation de sécurité entre les clients et la grappe SUSE Enterprise Storage 7.1. La fonction de configuration est nommée ceph-iscsi. À l'aide de la fonction ceph-iscsi, les administrateurs du stockage Ceph peuvent définir des volumes à allocation dynamique, hautement disponibles et répliqués, prenant en charge les instantanés en lecture seule, les clones en lecture-écriture et le redimensionnement automatique avec le périphérique de bloc RADOS (RADOS Block Device, RBD) de Ceph. Les administrateurs peuvent ensuite exporter des volumes via un seul hôte de passerelle ceph-iscsi ou via plusieurs hôtes de passerelle prenant en charge le basculement multipath. Les hôtes Linux, Microsoft Windows et VMware peuvent se connecter aux volumes à l'aide du protocole iSCSI, ce qui les rend disponibles comme tout autre périphérique de bloc SCSI. Cela signifie que les clients de SUSE Enterprise Storage 7.1 peuvent exécuter efficacement un sous-système d'infrastructure de stockage de blocs complet sur Ceph, qui offre toutes les fonctionnalités et avantages d'un SAN conventionnel, ce qui permet une croissance future.

Ce chapitre présente des informations détaillées permettant de configurer une infrastructure de grappe Ceph avec une passerelle iSCSI afin que les hôtes clients puissent utiliser des données stockées à distance en tant que périphériques de stockage locaux à l'aide du protocole iSCSI.

9.1.1 Stockage de blocs iSCSI

iSCSI est une implémentation de la commande SCSI (Small Computer System Interface) définie en utilisant le protocole Internet (IP), spécifié dans la norme RFC 3720. iSCSI est implémenté comme un service dans lequel un client (initiateur) se connecte à un serveur (cible) via une session sur le port TCP 3260. L'adresse IP et le port d'une cible iSCSI sont appelés portail iSCSI, où une cible peut être exposée par le bais d'un ou plusieurs portails. La combinaison d'une cible et d'un ou de plusieurs portails est appelée groupe de portails cible (TPG).

Le protocole de couche de liaison de données sous-jacent pour iSCSI est le plus souvent Ethernet. Plus spécifiquement, les infrastructures iSCSI modernes utilisent des réseaux 10 GigE Ethernet ou plus rapides pour un débit optimal. Une connectivité 10 Gigabit Ethernet entre la passerelle iSCSI et la grappe Ceph de l'interface dorsale est fortement recommandée.

9.1.1.1 Cible iSCSI du kernel Linux

La cible iSCSI du kernel Linux s'appelait à l'origine LIO pour linux-iscsi.org, le domaine et le site Web d'origine du projet. Pendant un certain temps, pas moins de quatre implémentations de cibles iSCSI concurrentes étaient disponibles pour la plate-forme Linux, mais LIO a finalement prévalu en tant que cible de référence iSCSI unique. Le code du kernel principal de LIO utilise le nom simple, mais quelque peu ambigu « target », en faisant la distinction entre « target core » et une variété de modules cibles d'interface client et d'interface dorsale.

Le module d'interface client le plus couramment utilisé est sans doute iSCSI. Toutefois, LIO prend également en charge Fibre Channel (FC), Fibre Channel sur Ethernet (FCoE) et plusieurs autres protocoles d'interface client. Pour l'instant, seul le protocole iSCSI est pris en charge par SUSE Enterprise Storage.

Le module d'interface dorsale cible le plus fréquemment utilisé est celui qui est capable de réexporter simplement n'importe quel périphérique de bloc disponible sur l'hôte cible. Ce module est nommé iblock. Cependant, LIO dispose également d'un module d'interface dorsale spécifique à RBD prenant en charge l'accès E/S multipath parallélisé aux images RBD.

9.1.1.2 Initiateurs iSCSI

Cette section présente des informations succinctes sur les initiateurs iSCSI utilisés sur les plates-formes Linux, Microsoft Windows et VMware.

9.1.1.2.1 Linux

L'initiateur standard de la plate-forme Linux est open-iscsi. open-iscsi lance le daemon iscsid, que l'utilisateur peut ensuite utiliser pour découvrir des cibles iSCSI sur n'importe quel portail donné, se connecter à des cibles et assigner des volumes iSCSI. iscsid communique avec la mi couche SCSI pour créer des périphériques de bloc du kernel que ce dernier peut ensuite traiter comme n'importe quel autre périphérique de bloc SCSI du système. L'initiateur open-iscsi peut être déployé en association avec l'outil Device Mapper Multipath (dm-multipath) capable de fournir un périphérique de bloc iSCSI hautement disponible.

9.1.1.2.2 Microsoft Windows et Hyper-V

L'initiateur iSCSI par défaut pour le système d'exploitation Microsoft Windows est l'initiateur iSCSI de Microsoft. Le service iSCSI peut être configuré via une interface graphique (GUI) et prend en charge les E/S multipath pour une haute disponibilité.

9.1.1.2.3 VMware

L'initiateur iSCSI par défaut pour VMware vSphere et ESX est l'initiateur iSCSI du logiciel VMware ESX, vmkiscsi. Lorsque qu'il est activé, il peut être configuré à partir du client vSphere ou à l'aide de la commande vmkiscsi-tool. Vous pouvez ensuite formater les volumes de stockage connectés via l'adaptateur de disque vSphere iSCSI avec VMFS et les utiliser comme tout autre périphérique de stockage VM. L'initiateur VMware prend également en charge les E/S multipath pour une haute disponibilité.

9.1.2 Informations générales concernant ceph-iscsi

La fonction ceph-iscsi associe les avantages des périphériques de bloc RADOS à la polyvalence omniprésente du protocole iSCSI. En utilisant ceph-iscsi sur un hôte de la cible iSCSI (connu sous le nom de passerelle iSCSI), toute application qui a besoin d'utiliser le stockage de blocs peut bénéficier de Ceph, même si elle n'utilise pas un protocole de client Ceph. Au lieu de cela, les utilisateurs peuvent utiliser le protocole iSCSI ou tout autre protocole d'interface client cible pour se connecter à une cible LIO, ce qui traduit toutes les E/S cibles en opérations de stockage RBD.

grappe Ceph avec une passerelle iSCSI unique
Figure 9.1 : grappe Ceph avec une passerelle iSCSI unique

ceph-iscsi est intrinsèquement hautement disponible et prend en charge les opérations multipath. Ainsi, les hôtes initiateurs en aval peuvent utiliser plusieurs passerelles iSCSI pour la haute disponibilité et l'évolutivité. Lors de la communication avec une configuration iSCSI avec plus d'une passerelle, les initiateurs peuvent équilibrer la charge des requêtes iSCSI sur plusieurs passerelles. En cas d'échec d'une passerelle, d'inaccessibilité temporaire ou de désactivation pour maintenance, les E/S continuent de manière transparente via une autre passerelle.

Grappe Ceph avec plusieurs passerelles iSCSI
Figure 9.2 : Grappe Ceph avec plusieurs passerelles iSCSI

9.1.3 Aspects à prendre en considération pour le déploiement

Une configuration minimale de SUSE Enterprise Storage 7.1 avec ceph-iscsi comprend les composants suivants :

  • Une grappe de stockage Ceph. La grappe Ceph consiste en un minimum de quatre serveurs physiques hébergeant au moins huit daemons de stockage des objets (Object Storage Daemon, OSD) chacun. Dans une telle configuration, les trois noeuds OSD doublent également en tant qu'hôte Monitor (MON).

  • Un serveur cible iSCSI exécutant la cible iSCSI LIO, configurée via ceph-iscsi.

  • Un hôte initiateur iSCSI, exécutant open-iscsi (Linux), l'initiateur Microsoft iSCSI (Microsoft Windows) ou toute autre implémentation d'initiateur iSCSI compatible.

La configuration recommandée en production pour SUSE Enterprise Storage 7.1 avec ceph-iscsi est constituée des éléments suivants :

  • Une grappe de stockage Ceph. Une grappe Ceph de production est constituée d'un nombre indéfini de noeuds OSD (généralement plus de 10), chacun exécutant généralement 10 à 12 OSD, avec un minimum de trois hôtes MON dédiés.

  • Plusieurs serveurs cibles iSCSI exécutant la cible iSCSI LIO, configurés via ceph-iscsi. Pour un basculement et un équilibrage de charge iSCSI, ces serveurs doivent exécuter un kernel prenant en charge le module target_core_rbd. Des paquetages de mise à jour sont disponibles à partir du canal de maintenance SUSE Linux Enterprise Server.

  • N'importe quel nombre d'hôtes initiateurs iSCSI exécutant open-iscsi (Linux), l'initiateur Microsoft iSCSI (Microsoft Windows) ou toute autre implémentation d'initiateur iSCSI compatible.

9.1.4 Installation et configuration

Cette section décrit les étapes d'installation et de configuration d'une passerelle iSCSI en plus de SUSE Enterprise Storage.

9.1.4.1 Déploiement de la passerelle iSCSI sur une grappe Ceph

Le déploiement de la passerelle iSCSI Ceph suit la même procédure que le déploiement d'autres services Ceph, à l'aide de cephdm. Pour plus de détails, reportez-vous à la Section 8.3.5, « Déploiement de passerelles iSCSI ».

9.1.4.2 Création d'images RBD

Les images RBD sont créées dans la zone de stockage Ceph et ensuite exportées vers iSCSI. Il est recommandé d'utiliser une réserve RADOS dédiée à cette fin. Vous pouvez créer un volume à partir de n'importe quel hôte pouvant se connecter à votre grappe de stockage à l'aide de l'utilitaire de ligne de commande Ceph rbd. Pour cela, le client doit avoir au moins un fichier de configuration ceph.conf minimal et des informations d'identification d'authentification CephX appropriées.

Pour créer un volume pour l'exportation ultérieure via iSCSI, utilisez la commande rbd create en spécifiant la taille du volume en mégaoctets. Par exemple, pour créer un volume de 100 Go nommé testvol dans la réserve intitulée iscsi-images, exécutez la commande suivante :

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

9.1.4.3 Exportation d'images RBD via iSCSI

Pour exporter des images RBD via iSCSI, vous pouvez utiliser l'interface Web Ceph Dashboard ou l'utilitaire gwcli ceph-iscsi. Dans cette section, nous nous concentrons sur gwcli uniquement et indiquons comment créer une cible iSCSI qui exporte une image RBD à l'aide de la ligne de commande.

Note
Note

Les images RBD avec les propriétés suivantes ne peuvent pas être exportées via iSCSI :

  • images avec la fonction journaling activée

  • images avec une unité stripe unit inférieure à 4 096 octets

En tant qu'utilisateur root, entrez le conteneur de la passerelle iSCSI :

# cephadm enter --name CONTAINER_NAME

En tant qu'utilisateur root, démarrez l'interface de ligne de commande de la passerelle iSCSI :

# gwcli

Accédez à iscsi-targets et créez une cible nommée iqn.2003-01.org.linux-iscsi.iscsi.ARCH-SYSTÈME:testvol :

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

Créez les passerelles iSCSI en spécifiant le nom de la passerelle (name) et l'adresse IP (ip) :

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
Astuce
Astuce

Utilisez la commande help pour afficher la liste des commandes disponibles sur le noeud de configuration actuel.

Ajoutez l'image RBD avec le nom testvol dans la réserve iscsi-images :

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

Assignez l'image RBD à la cible :

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol
Note
Note

Vous pouvez utiliser des outils de niveau inférieur, tels que targetcli pour interroger la configuration locale, mais pas pour la modifier.

Astuce
Astuce

Vous pouvez utiliser la commande ls pour examiner la configuration. Certains noeuds de configuration prennent également en charge la commande info, qui permet d'afficher des informations plus détaillées.

Notez que, par défaut, l'authentification ACL est activée de sorte que cette cible n'est pas encore accessible. Reportez-vous à la Section 9.1.4.4, « Authentification et contrôle d'accès » pour plus d'informations sur l'authentification et le contrôle d'accès.

9.1.4.4 Authentification et contrôle d'accès

L'authentification iSCSI est flexible et couvre de nombreuses possibilités d'authentification.

9.1.4.4.1 Désactivation de l'authentification ACL

No Authentication (Pas d'authentification) signifie que tout initiateur sera en mesure d'accéder à n'importe quelle unité logique sur la cible correspondante. Vous pouvez activer l'option No authentication en désactivant l'authentification ACL :

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl
9.1.4.4.2 Utilisation de l'authentification ACL

Lors de l'utilisation de l'authentification ACL basée sur le nom de l'initiateur, seuls les initiateurs définis sont autorisés à se connecter. Vous pouvez définir un initiateur comme suit :

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

Les initiateurs définis pourront se connecter, mais n'auront accès qu'aux images RBD qui leur ont été explicitement ajoutées :

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol
9.1.4.4.3 Activation de l'authentification CHAP

En plus de l'ACL, vous pouvez activer une authentification CHAP en spécifiant un nom d'utilisateur et un mot de passe pour chaque initiateur :

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
Note
Note

Les noms d'utilisateur doivent comporter entre 8 et 64 caractères et peuvent contenir des caractères alphanumériques ., @, -, _ ou :.

Les mots de passe doivent comporter entre 12 et 16 caractères et peuvent contenir des caractères alphanumériques, @, -, _ ou /.

Éventuellement, vous pouvez aussi activer une authentification mutuelle CHAP en spécifiant les paramètres mutual_username et mutual_password dans la commande auth.

9.1.4.4.4 Configuration de l'authentification mutuelle et de la découverte

L'authentification de la découverte est indépendante des méthodes d'authentification précédentes. Elle nécessite des informations d'identification pour la navigation, est facultative et peut être configurée comme suit :

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890
Note
Note

Les noms d'utilisateur doivent comporter entre 8 et 64 caractères et ne peuvent contenir que des lettres ., @, -, _ ou :.

Les mots de passe doivent comporter entre 12 et 16 caractères, et ne peuvent contenir que des lettres, @, -, _ ou /.

Éventuellement, vous pouvez aussi spécifier les paramètres mutual_username et mutual_password dans la commande discovery_auth.

L'authentification de découverte peut être désactivée à l'aide de la commande suivante :

gwcli >  /iscsi-targets> discovery_auth nochap

9.1.4.5 Configuration des paramètres avancés

ceph-iscsi peut être configuré avec des paramètres avancés qui sont ensuite transmis à la cible des E/S LIO. Les paramètres sont divisés en paramètres target (cible) et disk (disque).

Avertissement
Avertissement

Sauf indication contraire, il est déconseillé de modifier ces paramètres par rapport à leur valeur par défaut.

9.1.4.5.1 Affichage des paramètres cibles

Vous pouvez afficher la valeur de ces paramètres à l'aide de la commande info :

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

Vous pouvez modifier un paramètre à l'aide de la commande reconfigure :

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

Les paramètres target disponibles sont les suivants :

default_cmdsn_depth

Profondeur de CmdSN (numéro de séquence de commande) par défaut. Limite le nombre de requêtes qu'un initiateur iSCSI peut avoir en attente à tout moment.

default_erl

Niveau de la récupération d'erreur par défaut.

login_timeout

Valeur de timeout de connexion en secondes.

netif_timeout

Timeout d'échec de la carte d'interface réseau en secondes.

prod_mode_write_protect

Une valeur définie sur 1 empêche les écritures sur les LUN (numéros d'unité logique).

9.1.4.5.2 Affichage des paramètres du disque

Vous pouvez afficher la valeur de ces paramètres à l'aide de la commande info :

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

Vous pouvez modifier un paramètre à l'aide de la commande reconfigure :

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Les paramètres disk disponibles sont les suivants :

block_size

Taille du bloc du périphérique sous-jacent.

emulate_3pc

Une valeur définie sur 1 active l'option Third Party Copy (Copie tierce).

emulate_caw

Une valeur définie sur 1 active l'option Compare and Write (Comparer et écrire).

emulate_dpo

Si définie sur 1, active l'option Disable Page Out (Désactiver la sortie de page).

emulate_fua_read

Une valeur définie sur 1 active la lecture pour l'option Force Unit Access (Forcer l'accès aux unités).

emulate_fua_write

Une valeur définie sur 1 active l'écriture pour l'option Force Unit Access (Forcer l'accès aux unités).

emulate_model_alias

Une valeur définie sur 1 utilise le nom du périphérique d'interface dorsale pour l'alias du modèle.

emulate_pr

Si définie sur 0, la prise en charge des réservations SCSI, y compris les réservations de groupe persistantes, est désactivée. La passerelle iSCSI SES peut alors ignorer l'état de réservation, ce qui améliore la latence des requêtes.

Astuce
Astuce

Il est recommandé de définir backstore_emulate_pr sur 0 si les initiateurs iSCSI n'ont pas besoin de la prise en charge des réservations SCSI.

emulate_rest_reord

Si la valeur est définie sur 0, la réorganisation est restreinte dans le modificateur d'algorithme de file d'attente.

emulate_tas

Une valeur définie sur 1 active l'option Task Aborted Status (État Tâche abandonnée).

emulate_tpu

Une valeur définie sur 1 active l'option Thin Provisioning Unmap (Annulation d'assignation du provisioning léger).

emulate_tpws

Une valeur définie sur 1 active l'option Thin Provisioning Write Same (Écriture identique provisioning léger).

emulate_ua_intlck_ctrl

Une valeur définie sur 1 active l'option Unit Attention Interlock (Interverrouillage attention unité).

emulate_write_cache

Une valeur définie sur 1 active l'option Write Cache Enable (Écriture sur le cache activée).

enforce_pr_isids

Une valeur définie sur 1 applique les ISID de réservation persistante.

is_nonrot

Si la valeur est définie sur 1, le backstore est un périphérique non rotationnel.

max_unmap_block_desc_count

Nombre maximal de descripteurs de bloc pour UNMAP (Annuler l'assignation).

max_unmap_lba_count:

Nombre maximal de LBA pour UNMAP (Annuler l'assignation).

max_write_same_len

Longueur maximale pour WRITE_SAME (Écriture identique).

optimal_sectors

Taille de la requête optimale dans les secteurs.

pi_prot_type

Type de protection DIF.

queue_depth

Profondeur de la file d'attente.

unmap_granularity

Granularité UNMAP (Annuler l'assignation).

unmap_granularity_alignment

Alignement de la granularité UNMAP (Annuler l'assignation).

force_pr_aptpl

Lorsque ce paramètre est activé, LIO écrira toujours l'état persistent reservation (réservation persistante) dans l'espace de stockage persistant, que le client l'ait demandé ou non via aptpl=1. Cela n'a aucun effet avec l'interface dorsale RBD de kernel pour LIO, qui conserve toujours l'état PR. Idéalement, l'option target_core_rbd devrait imposer la valeur « 1 » et renvoyer une erreur si un utilisateur tente de la désactiver via la configuration.

unmap_zeroes_data

Détermine si LIO annoncera LBPRZ aux initiateurs SCSI, indiquant que les zéros seront relus à partir d'une région suivant UNMAP ou WRITE SAME avec un bit d'annulation d'assignation (« unmap »).

9.1.5 Exportation d'images de périphérique de bloc RADOS à l'aide de tcmu-runner

ceph-iscsi prend en charge les backstores rbd (basé sur le kernel) et user:rbd (tcmu-runner), ce qui rend toute la gestion transparente et indépendante du backstore.

Avertissement
Avertissement : avant-première technologique

Les déploiements de passerelles iSCSI basés sur tcmu-runner représentent actuellement un aperçu de la technologie.

Contrairement aux déploiements de passerelles iSCSI basés sur le kernel, les passerelles iSCSI basées sur tcmu-runner ne prennent pas en charge les E/S multipath ou les réservations persistantes SCSI.

Pour exporter une image RBD à l'aide de tcmu-runner, vous devez juste spécifier le backstore user:rbd lorsque vous attachez le disque :

gwcli >  /disks> attach rbd/testvol backstore=user:rbd
Note
Note

Lors de l'utilisation de tcmu-runner, l'image RBD exportée doit avoir la fonction exclusive-lock activée.