S'applique à SUSE Enterprise Storage 7.1

20 Périphérique de bloc RADOS #

Un bloc est une séquence d'octets, par exemple un bloc de 4 Mo de données. Les interfaces de stockage basées sur des blocs constituent le moyen le plus courant de stocker des données sur des supports rotatifs, tels que des disques durs, des CD ou des disquettes. L'omniprésence des interfaces de périphériques de bloc fait d'un périphérique de bloc virtuel un candidat idéal pour interagir avec un système de stockage de données de masse, tel que Ceph.

Les périphériques de bloc Ceph permettent le partage de ressources physiques et sont redimensionnables. Ils stockent les données réparties sur plusieurs OSD dans une grappe Ceph. Les périphériques de bloc Ceph exploitent les fonctionnalités RADOS, telles que les instantanés, la réplication et la cohérence. Les périphériques de bloc RADOS (RADOS Block Devices, RBD) Ceph interagissent avec les OSD utilisant des modules de kernel ou la bibliothèque librbd.

Figure 20.1 : Protocole RADOS #

Les périphériques de bloc Ceph offrent des performances exceptionnelles ainsi qu'une évolutivité infinie des modules de kernel. Ils prennent en charge des solutions de virtualisation, telles que QEMU, ou des systèmes basés sur le cloud, tels qu'OpenStack, qui reposent sur libvirt. Vous pouvez utiliser la même grappe pour faire fonctionner Object Gateway, CephFS et les périphériques de bloc RADOS simultanément.

20.1 Commandes de périphériques de bloc #

La commande rbd permet de créer, de répertorier, d'explorer et de supprimer des images de périphérique de bloc. Vous pouvez également l'utiliser, par exemple, pour cloner des images, créer des instantanés, restaurer une image dans un instantané ou afficher un instantané.

20.1.1 Création d'une image de périphérique de bloc dans une réserve répliquée #

Avant de pouvoir ajouter un périphérique de bloc à un client, vous devez créer une image associée dans une réserve existante (voir Chapitre 18, Gestion des réserves de stockage) :

cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME

Par exemple, pour créer une image de 1 Go nommée « myimage » qui stocke des informations dans une réserve nommée « mypool », exécutez la commande suivante :

cephuser@adm > rbd create --size 1024 mypool/myimage

Astuce : unités de taille d'image

Si vous n'indiquez pas de raccourci d'unité de taille (« G » ou « T »), la taille de l'image est en mégaoctets. Indiquez « G » ou « T » après le chiffre de la taille pour spécifier des gigaoctets ou des téraoctets.

20.1.2 Création d'une image de périphérique de bloc dans une réserve codée à effacement #

Il est possible de stocker les données d'une image de périphérique de bloc directement dans des réserves codées à effacement (Erasure Coded, EC). Une image de périphérique de bloc RADOS se compose de données et de métadonnées. Seules les données d'une image de périphérique de bloc peuvent être stockées dans une réserve EC. Le drapeau overwrite (écraser) de la réserve doit être défini sur true (vrai), ce qui est possible uniquement si tous les OSD sur lesquels la réserve est stockée utilisent BlueStore.

La partie « métadonnées » de l'image ne peut pas être stockée dans une réserve EC. Vous pouvez spécifier la réserve répliquée pour stocker les métadonnées de l'image à l'aide de l'option --pool= de la commande rbd create ou spécifier pool/ comme préfixe du nom de l'image.

Créez une réserve EC :

cephuser@adm > ceph osd pool create EC_POOL 12 12 erasure
cephuser@adm > ceph osd pool set EC_POOL allow_ec_overwrites true

Spécifiez la réserve répliquée dans laquelle stocker les métadonnées :

cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOL

Ou :

cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL

20.1.3 Liste des images de périphériques de bloc #

Pour lister les périphériques de bloc dans une réserve nommée « mypool », exécutez la commande suivante :

cephuser@adm > rbd ls mypool

20.1.4 Récupération d'informations sur l'image #

Pour récupérer des informations à partir d'une image « myimage » dans une réserve nommée « mypool », exécutez la commande suivante :

cephuser@adm > rbd info mypool/myimage

20.1.5 Redimensionnement d'une image de périphérique de bloc #

Les images de périphérique de bloc RADOS sont provisionnées dynamiquement : en effet, elles n'utilisent aucun stockage physique tant que vous n'y avez pas enregistré des données. Cependant, elles possèdent une capacité maximale que vous définissez à l'aide de l'option --size. Si vous souhaitez augmenter (ou diminuer) la taille maximale de l'image, exécutez la commande suivante :

cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increase
cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease

20.1.6 Suppression d'une image de périphérique de bloc #

Pour supprimer un périphérique de bloc qui correspond à une image « myimage » dans une réserve nommée « mypool », exécutez la commande suivante :

cephuser@adm > rbd rm mypool/myimage

20.2 Montage et démontage #

Après avoir créé un périphérique de bloc RADOS, vous pouvez l'utiliser comme n'importe quel autre périphérique de disque et le formater, le monter pour pouvoir échanger des fichiers et le démonter une fois que vous avez terminé.

La commande rbd accède par défaut à la grappe à l'aide du compte utilisateur Ceph admin. Ce compte dispose d'un accès administratif complet à la grappe. Il existe un risque de causer accidentellement des dommages, comme lorsque vous vous connectez à un poste de travail Linux en tant que root. Par conséquent, il est préférable de créer des comptes utilisateur avec moins de privilèges et d'utiliser ces comptes pour un accès normal en lecture/écriture aux périphériques de bloc RADOS.

20.2.1 Création d'un compte utilisateur Ceph #

Pour créer un nouveau compte utilisateur avec les fonctionnalités Ceph Manager, Ceph Monitor et Ceph OSD, utilisez la commande ceph avec la sous-commande auth get-or-create :

cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \
  [pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'

Par exemple, pour créer un utilisateur appelé qemu avec un accès en lecture-écriture aux vms de la réserve et un accès en lecture seule aux images de la réserve, exécutez la commande suivante :

ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \
  mgr 'profile rbd pool=images'

La sortie de la commande ceph auth get-or-create sera le trousseau de clés de l'utilisateur spécifié, qui peut être écrit dans /etc/ceph/ceph.client.ID.keyring.

Note

Lorsque vous utilisez la commande rbd, vous pouvez spécifier l'ID utilisateur en fournissant l'argument facultatif --id ID.

Pour plus d'informations sur la gestion des comptes utilisateur Ceph, reportez-vous au Chapitre 30, Authentification avec cephx.

20.2.2 Authentification des utilisateurs #

Pour indiquer un nom d'utilisateur, utilisez --id nom-utilisateur. Si vous utilisez l'authentification cephx, vous devez également indiquer un secret. Il peut provenir d'un trousseau de clés ou d'un fichier contenant le secret :

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyring

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file

20.2.3 Préparation du périphérique de bloc RADOS à utiliser #

Assurez-vous que votre grappe Ceph inclut une réserve avec l'image disque que vous souhaitez assigner. Supposons que la réserve soit appelée mypool et l'image myimage.
```
cephuser@adm > rbd list mypool
```
Assignez l'image à un nouveau périphérique de bloc:
```
cephuser@adm > rbd device map --pool mypool myimage
```
Dressez la liste de tous les périphériques assignés :
```
cephuser@adm > rbd device list
id pool   image   snap device
0  mypool myimage -    /dev/rbd0
```
Le périphérique sur lequel nous voulons travailler est /dev/rbd0.
Astuce : chemin du périphérique RBD
Au lieu de /dev/rbdNUMÉRO_PÉRIPHÉRIQUE, vous pouvez utiliser /dev/rbd/NOM_RÉSERVE/NOM_IMAGE comme chemin de périphérique persistant. Par exemple :
```
       /dev/rbd/mypool/myimage
```

Créez un système de fichiers XFS sur le périphérique /dev/rbd0:

# mkfs.xfs /dev/rbd0
      log stripe unit (4194304 bytes) is too large (maximum is 256KiB)
      log stripe unit adjusted to 32KiB
      meta-data=/dev/rbd0              isize=256    agcount=9, agsize=261120 blks
      =                       sectsz=512   attr=2, projid32bit=1
      =                       crc=0        finobt=0
      data     =                       bsize=4096   blocks=2097152, imaxpct=25
      =                       sunit=1024   swidth=1024 blks
      naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
      log      =internal log           bsize=4096   blocks=2560, version=2
      =                       sectsz=512   sunit=8 blks, lazy-count=1
      realtime =none                   extsz=4096   blocks=0, rtextents=0

En remplaçant /mnt par votre point de montage, montez le périphérique et vérifiez qu'il est correctement monté :
```
# mount /dev/rbd0 /mnt
      # mount | grep rbd0
      /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...
```
Vous pouvez maintenant déplacer des données vers et depuis le périphérique comme s'il s'agissait d'un répertoire local.
Astuce : augmentation de la taille du périphérique RBD
Si vous trouvez que la taille du périphérique RBD n'est plus suffisante, vous pouvez facilement l'augmenter.
1. Augmentez la taille de l'image RBD, par exemple jusqu'à 10 Go.
  cephuser@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.
2. Développez le système de fichiers à la nouvelle taille du périphérique:
  # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
Après avoir accédé au périphérique, vous pouvez annuler son assignation et le démonter.
```
cephuser@adm > rbd device unmap /dev/rbd0
# unmount /mnt
```

Astuce : montage et démontage manuels

Un script rbdmap et une unité systemd sont fournis pour faciliter le processus d'assignation et de montage des RBD après le démarrage et de leur démontage avant l'arrêt. Reportez-vous à la Section 20.2.4, « rbdmap : assignation de périphériques RBD au moment du démarrage ».

20.2.4 `rbdmap` : assignation de périphériques RBD au moment du démarrage #

rbdmap est un script shell qui automatise les opérations rbd map et rbd unmap sur une ou plusieurs images RBD. Bien que vous puissiez exécuter le script manuellement à tout moment, les principaux avantages sont l'assignation et le montage automatiques des images RBD au démarrage (ainsi que le démontage et la désassignation à l'arrêt) déclenchés par le système Init. À cet effet, un fichier unité systemd, rbdmap.service, est fourni avec le paquetage ceph-common.

Le script accepte un argument unique, qui peut être map ou unmap. Dans les deux cas, le script analyse un fichier de configuration. Il pointe vers /etc/ceph/rbdmap par défaut, mais peut être remplacé par le biais d'une variable d'environnement RBDMAPFILE. Chaque ligne du fichier de configuration correspond à une image RBD qui doit être assignée ou dont l'assignation doit être annulée.

Le fichier de configuration possède le format suivant :

image_specification rbd_options

image_specification

Chemin d'accès à une image dans une réserve. Indiquez-le en tant que nom_réserve/nom_image.

rbd_options

Liste facultative de paramètres à transmettre à la commande rbd device map sous-jacente. Ces paramètres et leurs valeurs doivent être indiqués en tant que chaîne séparée par des virgules, par exemple :

PARAM1=VAL1,PARAM2=VAL2,...

Dans cet exemple suivant, le script rbdmap exécute la commande suivante :

cephuser@adm > rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2

L'exemple suivant illustre comment spécifier un nom d'utilisateur et un trousseau de clés avec un secret correspondant :

cephuser@adm > rbdmap device map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring

Lorsqu'il est exécuté en tant que rdbmap map, le script analyse le fichier de configuration et, pour chaque image RBD indiquée, tente d'abord d'assigner l'image (à l'aide de la commande rbd device map), puis de la monter.

Lorsqu'elles sont exécutées en tant que rbdmap unmap, les images répertoriées dans le fichier de configuration seront démontées et désassignées.

rbdmap unmap-all tente de démonter puis de désassigner toutes les images RBD actuellement assignées, qu'elles soient ou non répertoriées dans le fichier de configuration.

En cas de réussite, l'opération rbd device map assigne l'image à un périphérique /dev/rbdX ; une règle udev est alors déclenchée afin de créer un lien symbolique de nom de périphérique convivial /dev/rbd/nom_réserve/nom_image pointant vers le périphérique réellement assigné.

Pour que le montage et le démontage réussissent, le nom de périphérique « convivial » doit être répertorié dans le fichier /etc/fstab. Lors de l'écriture d'entrées /etc/fstab pour les images RBD, indiquez l'option de montage « noauto » (ou « nofail »). Cela empêche le système Init d'essayer de monter le périphérique trop tôt, avant même que le périphérique en question existe, car rbdmap.service est généralement déclenché assez tard dans la séquence de démarrage.

Pour obtenir la liste complète des options de rbd, reportez-vous à la page de manuel rbd (man 8 rbd).

Pour obtenir des exemples de l'utilisation de rbd, reportez-vous à la page de manuel de rbd (man 8 rbd).

20.2.5 Augmentation de la taille des périphériques RBD #

Si vous trouvez que la taille du périphérique RBD n'est plus suffisante, vous pouvez facilement l'augmenter.

Augmentez la taille de l'image RBD, par exemple jusqu'à 10 Go.

cephuser@adm > rbd resize --size 10000 mypool/myimage
 Resizing image: 100% complete...done.

Développez le système de fichiers à la nouvelle taille du périphérique.
```
# xfs_growfs /mnt
 [...]
 data blocks changed from 2097152 to 2560000
```

20.3 Images instantanées #

Un instantané RBD est un instantané d'une image de périphérique de bloc RADOS. Avec les instantanés, vous conservez l'historique de l'état de l'image. Ceph prend également en charge la superposition d'instantanés, ce qui vous permet de cloner des images de machine virtuelle rapidement et facilement. Ceph prend en charge les instantanés de périphériques de bloc en utilisant la commande rbd et de nombreuses interfaces de niveau supérieur, notamment QEMU, libvirt, OpenStack et CloudStack.

Note

Arrêtez les opérations d'entrée et de sortie et videz toutes les écritures en attente avant de créer l'instantané d'une image. Si l'image contient un système de fichiers, celui-ci doit être cohérent lors de la création de l'instantané.

20.3.1 Activation et configuration de `cephx` #

Quand cephx est activé, vous devez spécifier un nom ou un ID d'utilisateur et un chemin d'accès au trousseau de clés contenant la clé correspondante pour l'utilisateur. Pour plus d'informations, reportez-vous au Chapitre 30, Authentification avec cephx. Vous pouvez également ajouter la variable d'environnement CEPH_ARGS pour ne pas avoir à saisir à nouveau les paramètres suivants.

cephuser@adm > rbd --id user-ID --keyring=/path/to/secret commands
cephuser@adm > rbd --name username --keyring=/path/to/secret commands

Par exemple :

cephuser@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephuser@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

Astuce

Ajoutez l'utilisateur et le secret à la variable d'environnement CEPH_ARGS afin de ne pas avoir à les saisir à chaque fois.

20.3.2 Notions de base sur les instantanés #

Les procédures suivantes montrent comment créer, répertorier et supprimer des instantanés à l'aide de la commande rbd sur la ligne de commande.

20.3.2.1 Création d'instantanés #

Pour créer un instantané avec rbd, indiquez l'option snap create, le nom de la réserve et le nom de l'image.

cephuser@adm > rbd --pool pool-name snap create --snap snap-name image-name
cephuser@adm > rbd snap create pool-name/image-name@snap-name

Par exemple :

cephuser@adm > rbd --pool rbd snap create --snap snapshot1 image1
cephuser@adm > rbd snap create rbd/image1@snapshot1

20.3.2.2 Liste des instantanés #

Pour répertorier les instantanés d'une image, spécifiez le nom de la réserve et le nom de l'image.

cephuser@adm > rbd --pool pool-name snap ls image-name
cephuser@adm > rbd snap ls pool-name/image-name

Par exemple :

cephuser@adm > rbd --pool rbd snap ls image1
cephuser@adm > rbd snap ls rbd/image1

20.3.2.3 Restauration de l'état initial des instantanés #

Pour rétablir l'état initial d'un instantané avec rbd, indiquez l'option snap rollback, le nom de la réserve, le nom de l'image et le nom de l'instantané.

cephuser@adm > rbd --pool pool-name snap rollback --snap snap-name image-name
cephuser@adm > rbd snap rollback pool-name/image-name@snap-name

Par exemple :

cephuser@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephuser@adm > rbd snap rollback pool1/image1@snapshot1

Note

Le retour à l'état initial d'une image dans un instantané revient à écraser la version actuelle de l'image avec les données d'un instantané. Le temps nécessaire à l'exécution d'un retour à l'état initial augmente avec la taille de l'image. Il est plus rapide de cloner à partir d'un instantané que de rétablir une image vers un instantané, cette méthode étant recommandée pour revenir à un état préexistant.

20.3.2.4 Suppression d'un instantané #

Pour supprimer un instantané avec rbd, indiquez l'option snap rm, le nom de la réserve, le nom de l'image et le nom de l'utilisateur.

cephuser@adm > rbd --pool pool-name snap rm --snap snap-name image-name
cephuser@adm > rbd snap rm pool-name/image-name@snap-name

Par exemple :

cephuser@adm > rbd --pool pool1 snap rm --snap snapshot1 image1
cephuser@adm > rbd snap rm pool1/image1@snapshot1

Note

Les instances Ceph OSD suppriment les données de manière asynchrone de sorte que la suppression d'un instantané ne libère pas immédiatement l'espace disque.

20.3.2.5 Purge des instantanés #

Pour supprimer tous les instantanés d'une image avec rbd, indiquez l'option snap purge et le nom de l'image.

cephuser@adm > rbd --pool pool-name snap purge image-name
cephuser@adm > rbd snap purge pool-name/image-name

Par exemple :

cephuser@adm > rbd --pool pool1 snap purge image1
cephuser@adm > rbd snap purge pool1/image1

20.3.3 Superposition d'instantanés #

Ceph prend en charge la possibilité de créer plusieurs clones de copie à l'écriture (COW) d'un instantané de périphérique de bloc. La superposition d'instantanés donne aux clients de périphériques de bloc Ceph les moyens de créer des images très rapidement. Par exemple, vous pouvez créer une image de périphérique de bloc avec une machine virtuelle Linux écrite, puis capturer l'image, protéger l'instantané et créer autant de clones COW que vous le souhaitez. Un instantané étant en lecture seule, le clonage d'un instantané simplifie la sémantique et permet de créer rapidement des clones.

Note

Dans les exemples de ligne de commande ci-dessous, les termes « parent » et « child » (enfant) désignent un instantané de périphérique de bloc Ceph (parent) et l'image correspondante clonée à partir de l'instantané (enfant).

Chaque image clonée (enfant) stocke une référence à son image parent, ce qui permet à l'image clonée d'ouvrir l'instantané parent et de le lire.

Un clone COW d'un instantané se comporte exactement comme n'importe quelle autre image de périphérique Ceph. Vous pouvez lire, écrire, cloner et redimensionner des images clonées. Il n'y a pas de restrictions spéciales avec les images clonées. Cependant, le clone copy-on-write d'un instantané fait référence à l'instantané, donc vous devez protéger l'instantané avant de le cloner.

Note : --image-format 1 non pris en charge

Vous ne pouvez pas créer d'instantanés d'images créés avec l'option rbd create ‑‑image-format 1 obsolète. Ceph ne prend en charge que le clonage des images format 2 par défaut.

20.3.3.1 Démarrage de la superposition #

La superposition de périphériques de bloc Ceph est un processus simple. Vous devez disposer d'une image. Vous devez créer un instantané de l'image. Vous devez protéger l'instantané. Après avoir effectué ces étapes, vous pouvez commencer le clonage de l'instantané.

L'image clonée contient une référence à l'instantané parent et inclut l'ID de la réserve, l'ID de l'image et l'ID de l'instantané. L'inclusion de l'ID de réserve signifie que vous pouvez cloner des instantanés d'une réserve vers des images d'une autre réserve.

Modèle d'image : un cas d'utilisation courant de la superposition de périphériques de bloc consiste à créer une image principale et un instantané servant de modèle aux clones. Par exemple, un utilisateur peut créer une image pour une distribution Linux (par exemple, SUSE Linux Enterprise Server (SLES)) et créer un instantané correspondant. Périodiquement, l'utilisateur peut mettre à jour l'image et créer un instantané (par exemple, zypper ref && zypper patch suivi de rbd snap create). Au fur et à mesure que l'image mûrit, l'utilisateur peut cloner l'un des instantanés.
Modèle étendu : un cas d'utilisation plus avancée inclut l'extension d'une image modèle fournissant plus d'informations qu'une image de base. Par exemple, un utilisateur peut cloner une image (un modèle de machine virtuelle) et installer d'autres logiciels (par exemple, une base de données, un système de gestion de contenu ou un système d'analyse), puis prendre un instantané de l'image agrandie, qui peut elle-même être mise à jour de la même manière que l'image de base.
Réserve de modèles : une façon d'utiliser la superposition de périphériques de bloc consiste à créer une réserve contenant des images principales agissant comme des modèles et des instantanés de ces modèles. Vous pouvez ensuite étendre les privilèges de lecture seule aux utilisateurs afin qu'ils puissent cloner les instantanés sans possibilité d'écriture ou d'exécution dans la réserve.
Migration/récupération d'image : une façon d'utiliser la superposition de périphériques de bloc consiste à migrer ou récupérer des données d'une réserve vers une autre.

20.3.3.2 Protection d'un instantané #

Les clones accèdent aux instantanés parents. Tous les clones seraient endommagés si un utilisateur supprimait par inadvertance l'instantané parent. Pour éviter toute perte de données, vous devez protéger l'instantané avant de pouvoir le cloner.

cephuser@adm > rbd --pool pool-name snap protect \
 --image image-name --snap snapshot-name
cephuser@adm > rbd snap protect pool-name/image-name@snapshot-name

Par exemple :

cephuser@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1
cephuser@adm > rbd snap protect pool1/image1@snapshot1

Note

Vous ne pouvez pas supprimer un instantané protégé.

20.3.3.3 Clonage d'un instantané #

Pour cloner un instantané, vous devez spécifier la réserve parent, l'image, l'instantané, la réserve enfant et le nom de l'image. Vous devez protéger l'instantané avant de pouvoir le cloner.

cephuser@adm > rbd clone --pool pool-name --image parent-image \
 --snap snap-name --dest-pool pool-name \
 --dest child-image
cephuser@adm > rbd clone pool-name/parent-image@snap-name \
pool-name/child-image-name

Par exemple :

cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2

Note

Vous pouvez cloner un instantané d'une réserve vers une image d'une autre réserve. Par exemple, vous pouvez gérer des images en lecture seule et des instantanés en tant que modèles dans une réserve, d'une part, et des clones inscriptibles dans une autre réserve, d'autre part.

20.3.3.4 Suppression de la protection d'un instantané #

Avant de pouvoir supprimer un instantané, vous devez d'abord le déprotéger. En outre, vous pouvez ne pas supprimer des instantanés contenant des références de clones. Vous devez fusionner chaque clone d'un instantané avant de pouvoir supprimer celui-ci.

cephuser@adm > rbd --pool pool-name snap unprotect --image image-name \
 --snap snapshot-name
cephuser@adm > rbd snap unprotect pool-name/image-name@snapshot-name

Par exemple :

cephuser@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1
cephuser@adm > rbd snap unprotect pool1/image1@snapshot1

20.3.3.5 Liste des enfants d'un instantané #

Pour dresser la liste des enfants d'un instantané, exécutez :

cephuser@adm > rbd --pool pool-name children --image image-name --snap snap-name
cephuser@adm > rbd children pool-name/image-name@snapshot-name

Par exemple :

cephuser@adm > rbd --pool pool1 children --image image1 --snap snapshot1
cephuser@adm > rbd children pool1/image1@snapshot1

20.3.3.6 Mise à plat d'une image clonée #

Les images clonées conservent une référence à l'instantané parent. Lorsque vous supprimez la référence du clone enfant dans l'instantané parent, vous « aplatissez » (fusionnez) l'image en copiant les informations de l'instantané sur le clone. Le temps nécessaire à la fusion d'un clone augmente avec la taille de l'instantané. Pour supprimer un instantané, vous devez d'abord fusionner les images enfant.

cephuser@adm > rbd --pool pool-name flatten --image image-name
cephuser@adm > rbd flatten pool-name/image-name

Par exemple :

cephuser@adm > rbd --pool pool1 flatten --image image1
cephuser@adm > rbd flatten pool1/image1

Note

Comme une image fusionnée contient toutes les informations de l'instantané, elle occupe plus d'espace de stockage qu'un clone en couches.

20.4 Miroirs d'image RBD #

Les images RBD peuvent être mises en miroir de manière asynchrone entre deux grappes Ceph. Cette fonctionnalité est disponible en deux modes :

Mode basé sur un journal: Ce mode utilise la fonctionnalité de journalisation de l'image RBD afin de garantir une réplication ponctuelle, cohérente entre les grappes en cas de panne. Chaque écriture dans l'image RBD est d'abord enregistrée dans le journal associé avant de réellement modifier l'image. La grappe remote lira le journal et relira les mises à jour de sa copie locale de l'image. Étant donné que chaque écriture dans l'image RBD entraîne deux écritures dans la grappe Ceph, attendez-vous à ce que les temps de latence en écriture soient pratiquement multipliés par deux lorsque vous utilisez la fonctionnalité de journalisation de l'image RBD.
Mode basé sur des instantanés: Ce mode utilise des instantanés en miroir d'image RBD planifiés ou créés manuellement pour répliquer des images RBD cohérentes entre les grappes en cas de panne. La grappe remote détermine toutes les mises à jour de données ou de métadonnées entre deux instantanés-miroir et copie les différences dans sa copie locale de l'image. La fonctionnalité d'image RBD fast-diff permet de calculer rapidement les blocs de données mis à jour sans devoir analyser toute l'image RBD. Étant donné que ce mode n'est pas cohérent à un moment donné, la différence de l'instantané complet devra être synchronisée avant d'être utilisée pendant un scénario de basculement. Toutes les différences d'instantanés partiellement appliquées sont restaurées vers l'état du dernier instantané entièrement synchronisé avant utilisation.

La mise en miroir est configurée réserve par réserve au sein des grappes homologues. Elle peut être configurée sur un sous-ensemble spécifique d'images dans la réserve ou configurée pour mettre en miroir automatiquement toutes les images d'une réserve lorsque vous utilisez la mise en miroir basée sur le journal uniquement. La mise en miroir est configurée à l'aide de la commande rbd. Le daemon rbd-mirror est chargé d'extraire les mises à jour de l'image de la grappe homologue remote (distante) et de les appliquer à l'image dans la grappe local (locale).

Selon les besoins de réplication souhaités, la mise en miroir RBD peut être configurée pour une réplication unidirectionnelle ou bidirectionnelle :

Réplication unidirectionnelle: Lorsque les données sont mises en miroir uniquement à partir d'une grappe primaire vers une grappe secondaire, le daemon rbd-mirror s'exécute uniquement sur la grappe secondaire.
Réplication bidirectionnelle: Lorsque les données sont mises en miroir à partir des images primaires sur une grappe vers des images non primaires sur une autre grappe (et inversement), le daemon rbd-mirror s'exécute sur les deux grappes.

Important

Chaque instance du daemon rbd-mirror doit pouvoir se connecter simultanément aux grappes Ceph locales (local) et distantes (remote). Par exemple, tous les hôtes du moniteur et OSD. En outre, le réseau doit disposer de suffisamment de bande passante entre les deux centres de données pour gérer le workload en miroir.

20.4.1 Configuration de la réserve #

Les procédures suivantes montrent comment effectuer les tâches d'administration de base pour configurer la mise en miroir à l'aide de la commande rbd. La mise en miroir est configurée réserve par réserve au sein des grappes Ceph.

Vous devez effectuer les étapes de configuration de la réserve sur les deux grappes homologues. Ces procédures supposent que deux grappes, nommées local et remote, sont accessibles depuis un seul hôte pour plus de clarté.

Reportez-vous à la page de manuel rbd (man 8 rbd) pour plus de détails sur la procédure de connexion à des grappes Ceph différentes.

Astuce : grappes multiples

Le nom de la grappe dans les exemples suivants correspond à un fichier de configuration Ceph du même nom /etc/ceph/remote.conf et à un fichier de trousseau de clés Ceph du même nom /etc/ceph/remote.client.admin.keyring.

20.4.1.1 Activation de la mise en miroir sur une réserve #

Pour activer la mise en miroir sur une grappe, indiquez la sous-commande mirror pool enable, le nom de la réserve et le mode de mise en miroir. Le mode de mise en miroir peut être pool ou image :

pool: Toutes les images de la réserve dont la fonctionnalité de journalisation est activée sont mises en miroir.
image: La mise en miroir doit être explicitement activée sur chaque image. Pour plus d'informations, reportez-vous à la Section 20.4.2.1, « Activation de la mise en miroir d'images ».

Par exemple :

cephuser@adm > rbd --cluster local mirror pool enable POOL_NAME pool
cephuser@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

20.4.1.2 Désactivation de la mise en miroir #

Pour désactiver la mise en miroir sur une grappe, indiquez la sous-commande mirror pool disable et le nom de la réserve. Lorsque la mise en miroir est désactivée sur une réserve de cette manière, la mise en miroir est également désactivée sur toutes les images (dans la réserve) pour lesquelles la mise en miroir a été explicitement activée.

cephuser@adm > rbd --cluster local mirror pool disable POOL_NAME
cephuser@adm > rbd --cluster remote mirror pool disable POOL_NAME

20.4.1.3 Démarrage des homologues #

Pour que le daemon rbd-mirror découvre sa grappe homologue, l'homologue doit être enregistré dans la réserve et un compte utilisateur doit être créé. Ce processus peut être automatisé avec rbd et les commandes mirror pool peer bootstrap create ainsi que mirror pool peer bootstrap import.

Pour créer manuellement un nouveau jeton de démarrage avec rbd, spécifiez la commande mirror pool peer bootstrap create, un nom de réserve, ainsi qu'un nom de site convivial facultatif pour décrire la grappe local :

cephuser@local > rbd mirror pool peer bootstrap create \
 [--site-name LOCAL_SITE_NAME] POOL_NAME

La sortie de la commande mirror pool peer bootstrap create sera un jeton qui doit être fourni à la commande mirror pool peer bootstrap import. Par exemple, sur la grappe local :

cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pool
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5I \
joiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

Pour importer manuellement le jeton de démarrage créé par une autre grappe avec la commande rbd, utilisez la syntaxe suivante :

rbd mirror pool peer bootstrap import \
 [--site-name LOCAL_SITE_NAME] \
 [--direction DIRECTION \
 POOL_NAME TOKEN_PATH

Où :

LOCAL_SITE_NAME: Nom facultatif convivial du site pour décrire la grappe local.
DIRECTION: Direction de la mise en miroir. La valeur par défaut est rx-tx pour la mise en miroir bidirectionnelle, mais peut également être définie sur rx-only pour la mise en miroir unidirectionnelle.
POOL_NAME: Nom de la réserve.
TOKEN_PATH: Chemin du fichier pour accéder au jeton créé (ou - pour le lire à partir de l'entrée standard).

Par exemple, sur la grappe remote :

cephuser@remote > cat <<EOF > token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF

cephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \
 --site-name remote image-pool token

20.4.1.4 Ajout manuel d'un homologue de grappe #

Au lieu de démarrer des homologues comme décrit à la Section 20.4.1.3, « Démarrage des homologues », vous pouvez spécifier des homologues manuellement. Le daemon rbd-mirror distant doit accéder à la grappe locale pour effectuer la mise en miroir. Créez un nouvel utilisateur Ceph local que le daemon rbd-mirror distant utilisera, par exemple, rbd-mirror-peer :

cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \
 mon 'profile rbd' osd 'profile rbd'

Utilisez la syntaxe suivante pour ajouter une grappe Ceph homologue en miroir avec la commande rbd :

rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME

Par exemple :

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-b
cephuser@adm > rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a

Par défaut, le daemon rbd-mirror doit avoir accès au fichier de configuration Ceph situé à l'emplacement /etc/ceph/.NOM_GRAPPE.conf. Il fournit les adresses IP des instances MON de la grappe homologue et un trousseau de clés pour un client nommé NOM_CLIENT situé dans les chemins de recherche par défaut ou personnalisés du trousseau de clés, par exemple /etc/ceph/NOM_GRAPPE.NOM_CLIENT.keyring.

Sinon, l'instance MON et/ou la clé du client de la grappe homologue peut être stockée en toute sécurité dans la zone de stockage locale config-key de Ceph. Pour spécifier les attributs de connexion de la grappe homologue lors de l'ajout d'un homologue en miroir, utilisez les options --remote-mon-host et --remote-key-file. Par exemple :

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool \
 client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \
 --remote-key-file /PATH/TO/KEY_FILE
cephuser@adm > rbd --cluster site-a mirror pool info image-pool --all
Mode: pool
Peers:
  UUID        NAME   CLIENT                 MON_HOST                KEY
  587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...

20.4.1.5 Suppression d'un homologue de grappe #

Pour supprimer une grappe homologue de mise en miroir, indiquez la sous-commande mirror pool peer remove, le nom de la réserve et l'UUID de l'homologue (disponible dans le résultat de la commande rbd mirror pool info) :

cephuser@adm > rbd --cluster local mirror pool peer remove POOL_NAME \
 55672766-c02b-4729-8567-f13a66893445
cephuser@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \
 60c0e299-b38f-4234-91f6-eed0a367be08

20.4.1.6 Réserves de données #

Lors de la création d'images dans la grappe cible, rbd-mirror sélectionne une réserve de données comme suit :

Si une réserve de données par défaut est configurée pour la grappe cible (avec l'option de configuration rbd_default_data_pool), cette réserve sera utilisée.
Dans le cas contraire, si l'image source utilise une réserve de données distincte et qu'une réserve portant le même nom existe sur la grappe cible, cette réserve est utilisée.
Si aucune des conditions ci-dessus n'est vraie, aucune réserve de données n'est configurée.

20.4.2 Configuration de l'image RBD #

Contrairement à la configuration de réserve, la configuration d'image ne doit être effectuée que par rapport à une seule grappe Ceph homologue de mise en miroir.

Les images RBD en miroir sont désignées comme étant soit primaires, soit non primaires. Il s'agit d'une propriété de l'image et non pas de la réserve. Les images qui sont désignées comme non primaires ne sont pas modifiables.

Les images sont automatiquement promues au rang d'images primaires lorsque la mise en miroir est activée pour la première fois sur une image (soit implicitement si le mode de mise en miroir de la réserve était « pool » et que la fonctionnalité de journalisation de l'image a été activée, soit explicitement – reportez-vous à la Section 20.4.2.1, « Activation de la mise en miroir d'images » – à l'aide de la commande rbd).

20.4.2.1 Activation de la mise en miroir d'images #

Si la mise en miroir est configurée en mode image, il est nécessaire d'activer explicitement la mise en miroir pour chaque image de la réserve. Pour activer la mise en miroir d'une image en particulier avec la commande rbd, indiquez la sous-commande mirror image enable ainsi que le nom de la réserve et le nom de l'image :

cephuser@adm > rbd --cluster local mirror image enable \
 POOL_NAME/IMAGE_NAME

Le mode d'image en miroir peut être journal ou snapshot :

journal (valeur par défaut): Lorsqu'elle est configurée en mode journal, la mise en miroir utilise la fonctionnalité de journalisation de l'image RBD pour répliquer le contenu de l'image. Si la fonction de journalisation de l'image RBD n'est pas encore activée sur l'image, elle sera activée automatiquement.
snapshot: Lorsqu'elle est configurée en mode snapshot (instantané), la mise en miroir utilise des instantanés-miroir de l'image RBD pour répliquer le contenu de l'image. Une fois activé, un instantané-miroir initial est automatiquement créé. Des instantanés-miroir de l'image RBD supplémentaires peuvent être créés à l'aide de la commande rbd.

Par exemple :

cephuser@adm > rbd --cluster local mirror image enable image-pool/image-1 snapshot
cephuser@adm > rbd --cluster local mirror image enable image-pool/image-2 journal

20.4.2.2 Activation de la fonctionnalité de journalisation des images #

La mise en miroir RBD utilise la fonctionnalité de journalisation RBD pour garantir que l'image répliquée est préservée en cas de panne. Lorsque vous utilisez le mode de mise en miroir image, la fonctionnalité de journalisation est automatiquement activée si la mise en miroir est activée sur l'image. Lorsque vous utilisez le mode de mise en miroir pool, avant qu'une image puisse être mise en miroir sur une grappe homologue, la fonction de journalisation d'image RBD doit être activée. La fonctionnalité peut être activée au moment de la création de l'image en indiquant l'option --image-feature exclusive-lock,journaling dans la commande rbd.

Le cas échéant, la fonction de journalisation peut être dynamiquement activée sur des images RBD préexistantes. Pour activer la journalisation, indiquez la sous-commande feature enable, le nom de la réserve et de l'image, et le nom de l'entité :

cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lock
cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling

Note : dépendance des options

La fonctionnalité journaling dépend de la fonctionnalité exclusive-lock. Si la fonctionnalité exclusive-lock n'est pas encore activée, vous devez l'activer avant la fonctionnalité journaling.

Astuce

Vous pouvez activer la journalisation sur toutes les nouvelles images par défaut en ajoutant rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling à votre fichier de configuration Ceph.

20.4.2.3 Création d'instantanés-miroir d'images #

Lors de l'utilisation de la mise en miroir basée sur des instantanés, des instantanés-miroir doivent être créés chaque fois que vous souhaitez mettre en miroir le contenu modifié de l'image RBD. Pour créer manuellement un instantané-miroir à l'aide de la commande rbd, spécifiez la commande mirror image snapshot ainsi que le nom de la réserve et de l'image :

cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAME

Par exemple :

cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1

Par défaut, seuls trois instantanés-miroir sont créés par image. L'instantané-miroir le plus récent est automatiquement nettoyé si la limite est atteinte. La limite peut être remplacée par l'option de configuration rbd_mirroring_max_mirroring_snapshots si nécessaire. En outre, les instantanés-miroir sont automatiquement supprimés lors du retrait de l'image ou de la désactivation de la mise en miroir.

Des instantanés-miroir peuvent également être créés automatiquement à intervalles réguliers si des planifications d'instantanés-miroir sont définies. L'instantané-miroir peut être planifié de manière globale, par réserve ou par image. Plusieurs planifications d'instantanés-miroir peuvent être définies à n'importe quel niveau, mais seules les planifications d'instantanés les plus spécifiques qui correspondent à une image en miroir individuelle seront exécutées.

Pour créer une planification d'instantanés-miroir avec rbd, spécifiez la commande mirror snapshot schedule add ainsi qu'un nom de réserve ou d'image, un intervalle et une heure de début facultative.

L'intervalle peut être spécifié en jours, heures ou minutes respectivement à l'aide des suffixes d, h ou m. L'heure de début facultative peut être spécifiée à l'aide du format d'heure ISO 8601. Par exemple :

cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00
cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h

Pour supprimer une planification d'instantané-miroir avec rbd, spécifiez la commande mirror snapshot schedule remove avec des options qui correspondent à la commande d'ajout de planification correspondante.

Pour répertorier toutes les planifications d'instantanés d'un niveau spécifique (global, réserve ou image) avec la commande rbd, spécifiez la commande mirror snapshot schedule ls avec un nom facultatif de réserve ou d'image. En outre, l'option --recursive peut être spécifiée pour répertorier toutes les planifications du niveau spécifié et des niveaux inférieurs. Par exemple :

cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursive
POOL        NAMESPACE IMAGE  SCHEDULE
image-pool  -         -      every 1d starting at 14:00:00-05:00
image-pool            image1 every 6h

Pour savoir quand les prochains instantanés seront créés pour les images RBD en miroir basées sur des instantanés avec rbd, spécifiez la commande mirror snapshot schedule status ainsi qu'un nom de réserve ou d'image facultatif. Par exemple :

cephuser@adm > rbd --cluster local mirror schedule status
SCHEDULE TIME       IMAGE
2020-02-26 18:00:00 image-pool/image1

20.4.2.4 Désactivation de la mise en miroir d'images #

Pour désactiver la mise en miroir d'une image en particulier, indiquez la sous-commande mirror image disable avec le nom de la réserve et le nom de l'image :

cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME

20.4.2.5 Promotion et rétrogradation d'images #

Dans un scénario de basculement où la désignation principale doit être déplacée sur l'image dans la grappe homologue, vous devez arrêter l'accès à l'image primaire, rétrograder l'image primaire actuelle, promouvoir la nouvelle image primaire et reprendre l'accès à l'image sur la grappe alternative.

Note : promotion forcée

La promotion peut être forcée à l'aide de l'option --force. La promotion forcée est nécessaire lorsque la rétrogradation ne peut pas être propagée à la grappe homologue (par exemple, en cas d'échec de la grappe ou de panne de communication). Cela se traduira par un scénario de divergence entre les deux homologues, et l'image ne sera plus synchronisée jusqu'à l'émission de la sous-commande resync.

Pour rétrograder une image non primaire spécifique, indiquez la sous-commande mirror image demote ainsi que le nom de la réserve et le nom de l'image :

cephuser@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME

Pour rétrograder toutes les images primaires, indiquez la sous-commande mirror image demote ainsi que le nom de la réserve :

cephuser@adm > rbd --cluster local mirror pool demote POOL_NAME

Pour promouvoir une image spécifique au rang d'image primaire, indiquez la sous-commande mirror image promote ainsi que le nom de la réserve et le nom de l'image :

cephuser@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME

Pour promouvoir toutes les images non primaires d'une réserve au rang d'images primaires, indiquez la sous-commande mirror image promote ainsi que le nom de la réserve :

cephuser@adm > rbd --cluster local mirror pool promote POOL_NAME

Astuce : division de la charge d'E/S

Comme l'état primaire ou non primaire s'applique au niveau de l'image, il est possible que deux grappes divisent le chargement des E/S et le basculement ou la restauration par phases.

20.4.2.6 Resynchronisation forcée de l'image #

Si le daemon rbd-mirror détecte un événement de divergence, il n'y aura pas de tentative de mettre en miroir l'image concernée jusqu'à ce que celle-ci soit corrigée. Pour reprendre la mise en miroir d'une image, commencez par rétrograder l'image jugée obsolète, puis demandez une resynchronisation avec l'image principale. Pour demander une resynchronisation de l'image, indiquez la sous-commande mirror image resync avec le nom de la réserve et le nom de l'image :

cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

20.4.3 Vérification de l'état du miroir #

L'état de réplication de la grappe homologue est stocké pour chaque image en miroir principale. Cet état peut être récupéré à l'aide des sous-commandes mirror image status et mirror pool status :

Pour demander l'état de l'image miroir, indiquez la sous-commande mirror image status avec le nom de la réserve et le nom de l'image :

cephuser@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

Pour demander l'état du résumé de la réserve miroir, indiquez la sous-commande mirror pool status avec le nom de la réserve :

cephuser@adm > rbd mirror pool status POOL_NAME

Astuce :

L'option --verbose de la sous-commande mirror pool status permet d'afficher des informations détaillées sur l'état de chaque image de mise en miroir présente dans la réserve.

20.5 Paramètres de cache #

L'implémentation de l'espace utilisateur du périphérique de bloc Ceph (librbd) ne peut pas profiter du cache de page Linux. Il comprend donc son propre caching en mémoire. Le caching RBD se comporte comme le caching de disque dur. Lorsque le système d'exploitation envoie une demande de barrière ou de vidage, toutes les données altérées (« dirty ») sont écrites sur l'OSD. Cela signifie que l'utilisation du caching à écriture différée est tout aussi sûre que celle d'un disque dur physique correct avec une machine virtuelle qui envoie correctement des demandes de vidage. Le cache utilise un algorithme Moins récemment utilisée (LRU) et peut, en mode d'écriture différée, fusionner les demandes adjacentes pour un meilleur débit.

Ceph prend en charge le caching à écriture différée pour RBD. Pour l'activer, exécutez

cephuser@adm > ceph config set client rbd_cache true

Par défaut, librbd n'effectue aucun caching. Les écritures et les lectures sont envoyées directement à la grappe de stockage, et les écritures ne reviennent que lorsque les données sont sur disque sur toutes les répliques. Lorsque le caching est activé, les écritures reviennent immédiatement sauf si le volume d'octets non vidés est supérieur à celui défini par l'option rbd cache max dirty. Dans un tel cas, l'écriture déclenche l'écriture différée et les blocs jusqu'à ce que suffisamment d'octets soient vidés.

Ceph prend en charge le caching à écriture immédiate pour RBD. Vous pouvez définir la taille du cache ainsi que des objectifs et des limites pour passer du caching à écriture différée au caching à écriture immédiate. Pour activer le mode d'écriture immédiate, exécutez

cephuser@adm > ceph config set client rbd_cache_max_dirty 0

Cela signifie que les écritures ne reviennent que lorsque les données sont sur disque sur toutes les répliques, mais que les lectures peuvent provenir du cache. Le cache est en mémoire sur le client, et chaque image RBD a son propre cache. Étant donné que le cache est en local sur le client, il n'y a pas de cohérence s'il y a d'autres accès à l'image. L'exécution de GFS ou d'OCFS sur RBD ne fonctionnera pas avec le caching activé.

Les paramètres suivants affectent le comportement des périphériques de bloc RADOS. Pour les définir, utilisez la catégorie client :

cephuser@adm > ceph config set client PARAMETER VALUE

rbd cache: Permet d'activer le caching pour le périphérique de bloc RADOS (RBD). La valeur par défaut est « true ».
rbd cache size: Taille du cache RBD en octets. La valeur par défaut est 32 Mo.
rbd cache max dirty: Limite « dirty » en octets à laquelle le cache déclenche l'écriture différée. rbd cache max dirty doit être inférieur à rbd cache size. Si la valeur est définie sur 0, le caching à écriture immédiate est utilisé. La valeur par défaut est 24 Mo.
rbd cache target dirty: Valeur « dirty target » avant que le cache commence à écrire des données sur le stockage de données. Ne bloque pas les écritures dans le cache. La valeur par défaut est 16 Mo.
rbd cache max dirty age: Temps en secondes pendant lequel les données altérées sont dans le cache avant le début de l'écriture différée. La valeur par défaut est 1.
rbd cache writethrough until flush: Indique de commencer en mode d'écriture immédiate et de passer à l'écriture différée après la réception de la première demande de vidage. Cette configuration classique est judicieuse lorsque les machines virtuelles qui s'exécutent sur rbd sont trop anciennes pour envoyer des vidages (par exemple, le pilote virtio dans Linux avant le kernel 2.6.32). La valeur par défaut est « true ».

20.6 Paramètres QoS #

En règle générale, la qualité de service (QoS) fait référence aux méthodes de priorisation du trafic et de réservation des ressources. Elle est particulièrement importante pour le transport du trafic avec des exigences spéciales.

Important : non pris en charge par iSCSI

Les paramètres QoS suivants sont utilisés uniquement par l'implémentation RBD de l'espace utilisateur librbd et non par l'implémentation kRBD. Étant donné qu'iSCSI utilise kRBD, il n'emploie pas les paramètres QoS. Toutefois, pour iSCSI, vous pouvez configurer la qualité de service sur la couche des périphériques de bloc du kernel à l'aide des fonctionnalités standard du kernel.

rbd qos iops limit: Limite souhaitée des opérations d'E/S par seconde. La valeur par défaut est 0 (pas de limite).
rbd qos bps limit: Limite souhaitée d'octets en E/S par seconde. La valeur par défaut est 0 (pas de limite).
rbd qos read iops limit: Limite souhaitée des opérations de lecture par seconde. La valeur par défaut est 0 (pas de limite).
rbd qos write iops limit: Limite souhaitée des opérations d'écriture par seconde. La valeur par défaut est 0 (pas de limite).
rbd qos read bps limit: Limite souhaitée des octets en lecture par seconde. La valeur par défaut est 0 (pas de limite).
rbd qos write bps limit: Limite souhaitée des octets en écriture par seconde. La valeur par défaut est 0 (pas de limite).
rbd qos iops burst: Limite de rafales souhaitée des opérations d'E/S. La valeur par défaut est 0 (pas de limite).
rbd qos bps burst: Limite de rafales souhaitée des octets en E/S. La valeur par défaut est 0 (pas de limite).
rbd qos read iops burst: Limite de rafales souhaitée des opérations de lecture. La valeur par défaut est 0 (pas de limite).
rbd qos write iops burst: Limite de rafales souhaitée des opérations d'écriture. La valeur par défaut est 0 (pas de limite).
rbd qos read bps burst: Limite de rafales souhaitée des octets en lecture. La valeur par défaut est 0 (pas de limite).
rbd qos write bps burst: Limite de rafales souhaitée des octets en écriture. La valeur par défaut est 0 (pas de limite).
rbd qos schedule tick min: Cycle d'horloge de planification minimal (en millisecondes) pour la qualité de service. La valeur par défaut est 50.

20.7 Paramètres de la lecture anticipée #

Le périphérique de bloc RADOS prend en charge la lecture anticipée/la prérécupération pour optimiser les petites lectures séquentielles. Ces opérations devraient normalement être gérées par le système d'exploitation invité dans le cas d'une machine virtuelle, mais les chargeurs de démarrage peuvent ne pas émettre des lectures efficaces. La lecture anticipée est automatiquement désactivée si le caching est désactivé.

Important : non pris en charge par iSCSI

Les paramètres de lecture anticipée suivants sont utilisés uniquement par l'implémentation RBD de l'espace utilisateur librbd et non par l'implémentation kRBD. Étant donné qu'iSCSI utilise kRBD, il n'emploie pas les paramètres de lecture anticipée. Toutefois, pour iSCSI, vous pouvez configurer la lecture anticipée sur la couche des périphériques de bloc du kernel à l'aide des fonctionnalités standard du kernel.

rbd readahead trigger requests: Nombre de demandes de lecture séquentielle nécessaires pour déclencher la lecture anticipée. La valeur par défaut est 10.
rbd readahead max bytes: Taille maximale d'une demande de lecture anticipée. Lorsque la valeur est 0, la lecture anticipée est désactivée. La valeur par défaut est 512 Ko.
rbd readahead disable after bytes: Après la lecture de tous ces octets à partir d'une image RBD, la lecture anticipée est désactivée pour cette image jusqu'à ce qu'elle soit fermée. Cela permet à l'OS invité de prendre en charge la lecture anticipée quand il est démarré. Lorsque la valeur est 0, la lecture anticipée reste activée. La valeur par défaut est 50 Mo.

20.8 Fonctions avancées #

Le périphérique de bloc RADOS prend en charge les fonctions avancées qui améliorent la fonctionnalité des images RBD. Vous pouvez spécifier les fonctions sur la ligne de commande lors de la création d'une image RBD ou dans le fichier de configuration Ceph à l'aide de l'option rbd_default_features.

Vous pouvez spécifier les valeurs de l'option rbd_default_features de deux façons :

Comme une somme de valeurs internes des fonctions. Chaque fonction a sa propre valeur interne, par exemple 1 pour « layering » et 16 pour « fast-diff ». Par conséquent, pour activer ces deux fonctions par défaut, incluez la ligne suivante :
```
rbd_default_features = 17
```
Comme une liste de fonctions séparées par des virgules. L'exemple précédent se présentera comme suit :
```
rbd_default_features = layering,fast-diff
```

Note : fonctions non prises en charge par iSCSI

Les images RBD avec les fonctions suivantes ne seront pas prises en charge par iSCSI : deep-flatten, object-map, journaling, fast-diff et striping.

Voici une liste de fonctions RBD avancées :

layering

La création de couches, ou superposition (layering), permet d'utiliser le clonage.

La valeur interne est 1, la valeur par défaut est « yes ».

striping

La segmentation (striping) propage les données sur plusieurs objets et contribue au parallélisme pour les workloads séquentiels de lecture/écriture. Elle empêche les goulots d'étranglement de noeud unique pour les périphériques de bloc RADOS volumineux ou fort occupés.

La valeur interne est 2, la valeur par défaut est « yes ».

exclusive-lock

Lorsque cette fonction est activée, il faut qu'un client obtienne un verrouillage sur un objet avant d'effectuer une écriture. Activez le verrouillage exclusif uniquement lorsqu'un seul client accède à une image en même temps. La valeur interne est 4. La valeur par défaut est « yes ».

object-map

La prise en charge de l'assignation d'objet dépend de la prise en charge du verrouillage exclusif. Les périphériques de bloc sont provisionnés dynamiquement, ce qui signifie qu'ils ne stockent que les données qui existent réellement. La prise en charge de l'assignation d'objet permet de suivre quels objets existent réellement (ont des données stockées sur un disque). L'activation de la prise en charge de l'assignation d'objet permet d'accélérer les opérations d'E/S pour le clonage, l'importation et l'exportation d'une image peu peuplée, et pour la suppression.

La valeur interne est 8, la valeur par défaut est « yes ».

fast-diff

La prise en charge de la fonction fast-diff dépend de la prise en charge de l'assignation d'objet et du verrouillage exclusif. Elle ajoute une propriété à l'assignation d'objet, ce qui la rend beaucoup plus rapide pour générer des différentiels entre les instantanés d'une image et l'utilisation réelle des données d'un instantané.

La valeur interne est 16, la valeur par défaut est « yes ».

deep-flatten

La fonction deep-flatten rend rbd flatten (voir la Section 20.3.3.6, « Mise à plat d'une image clonée ») opérationnel sur tous les instantanés d'une image, en plus de l'image elle-même. Sans elle, les instantanés d'une image s'appuieront toujours sur le parent, et vous ne pourrez pas supprimer l'image parent avant que les instantanés soient supprimés. La fonction deep-flatten rend un parent indépendant de ses clones, même s'ils ont des instantanés.

La valeur interne est 32, la valeur par défaut est « yes ».

journaling

La prise en charge de la fonction de journalisation (journaling) dépend de la prise en charge du verrouillage exclusif. La journalisation enregistre toutes les modifications d'une image dans l'ordre où elles se produisent. La mise en miroir RBD (voir la Section 20.4, « Miroirs d'image RBD ») utilise le journal pour répliquer une image cohérente sur une grappe distante en cas de panne.

La valeur interne est 64, la valeur par défaut est « no ».

20.9 Assignation RBD à l'aide d'anciens clients de kernel #

Les anciens clients (par exemple, SLE 11 SP4) peuvent ne pas être en mesure d'assigner les images RBD parce qu'une grappe déployée avec SUSE Enterprise Storage 7.1 force certaines fonctions (à la fois les fonctions de niveau image RBD et celles de niveau RADOS) que ces anciens clients ne prennent pas en charge. Dans ce cas, les journaux OSD afficheront des messages semblables à ce qui suit :

2019-05-17 16:11:33.739133 7fcb83a2e700  0 -- 192.168.122.221:0/1006830 >> \
192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \
protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000

Avertissement : la modification des types de compartiment de carte CRUSH provoque un rééquilibrage massif

Si vous avez l'intention de commuter les types de compartiment de carte CRUSH « straw » et « straw2 », procédez de manière méthodique. Attendez-vous à un impact significatif sur la charge de la grappe, car un tel changement provoque un rééquilibrage massif des grappes.

Désactivez toutes les fonctions d'image RBD qui ne sont pas prises en charge. Par exemple :

cephuser@adm > rbd feature disable pool1/image1 object-map
cephuser@adm > rbd feature disable pool1/image1 exclusive-lock

Remplacez les types de compartiment de carte CRUSH « straw2 » par « straw » :
1. Enregistrez la carte CRUSH :
```
cephuser@adm > ceph osd getcrushmap -o crushmap.original
```
2. Décompilez la carte CRUSH :
```
cephuser@adm > crushtool -d crushmap.original -o crushmap.txt
```
3. Modifiez la carte CRUSH et remplacez « straw2 » par « straw ».
4. Recompilez la carte CRUSH :
```
cephuser@adm > crushtool -c crushmap.txt -o crushmap.new
```
5. Définissez la nouvelle carte CRUSH :
```
cephuser@adm > ceph osd setcrushmap -i crushmap.new
```

20.10 Activation des périphériques de bloc et de Kubernetes #

Vous pouvez utiliser Ceph RBD avec Kubernetes v1.13 et versions ultérieures via le pilote ceph-csi. Ce pilote provisionne dynamiquement des images RBD pour soutenir les volumes Kubernetes et assigne ces images RBD en tant que périphériques de bloc (éventuellement en montant un système de fichiers contenu dans l'image) sur des noeuds de travail exécutant des pods faisant référence à un volume soutenu par RBD.

Pour utiliser des périphériques de bloc Ceph avec Kubernetes, vous devez installer et configurer ceph-csi dans votre environnement Kubernetes.

Important

ceph-csi utilise les modules de kernel RBD par défaut qui peuvent ne pas prendre en charge tous les paramètres Ceph CRUSH ou les fonctions d'image RBD.

Par défaut, les périphériques de bloc Ceph utilisent la réserve RBD. Créez une réserve pour stocker les volumes Kubernetes. Assurez-vous que votre grappe Ceph est en cours d'exécution, puis créez la réserve :
```
cephuser@adm > ceph osd pool create kubernetes
```
Utilisez l'outil RBD pour initialiser la réserve :
```
cephuser@adm > rbd pool init kubernetes
```

Créez un nouvel utilisateur pour Kubernetes et ceph-csi. Exécutez la commande suivante et enregistrez la clé générée :

cephuser@adm > ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'
[client.kubernetes]
    key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==

ceph-csi nécessite un objet ConfigMap stocké dans Kubernetes pour définir les adresses de moniteur Ceph pour la grappe Ceph. Collectez le fsid unique de la grappe Ceph et les adresses de moniteur :

cephuser@adm > ceph mon dump
<...>
fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8
<...>
0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a
1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b
2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.c

Générez un fichier csi-config-map.yaml similaire à l'exemple ci-dessous, en remplaçant le FSID par clusterID et les adresses de moniteur pour monitors :

kubectl@adm > cat <<EOF > csi-config-map.yaml
---
apiVersion: v1
kind: ConfigMap
data:
  config.json: |-
    [
      {
        "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8",
        "monitors": [
          "192.168.1.1:6789",
          "192.168.1.2:6789",
          "192.168.1.3:6789"
        ]
      }
    ]
metadata:
  name: ceph-csi-config
EOF

Une fois généré, stockez le nouvel objet ConfigMap dans Kubernetes :
```
kubectl@adm > kubectl apply -f csi-config-map.yaml
```
ceph-csi a besoin des informations d'identification cephx pour communiquer avec la grappe Ceph. Générez un fichier csi-rbd-secret.yaml similaire à l'exemple ci-dessous, en utilisant l'ID utilisateur Kubernetes et la clé cephx que vous venez de créer :
```
kubectl@adm > cat <<EOF > csi-rbd-secret.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: default
stringData:
  userID: kubernetes
  userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==
EOF
```
Une fois généré, stockez le nouvel objet Secret dans Kubernetes :
```
kubectl@adm > kubectl apply -f csi-rbd-secret.yaml
```
Créez les objets ServiceAccount et RBAC ClusterRole/ClusterRoleBinding Kubernetes requis. Ces objets ne doivent pas nécessairement être personnalisés pour votre environnement Kubernetes et peuvent donc être utilisés directement à partir des fichiers YAML de déploiement ceph-csi :
```
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yaml
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml
```

Créez l'outil de déploiement ceph-csi et les plug-ins de noeud :

kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin-provisioner.yaml
kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin.yaml

Important

Par défaut, les fichiers YAML de l'outil de déploiement et du plug-in de noeud récupèrent la version de développement du conteneur ceph-csi. Les fichiers YAML doivent être mis à jour pour utiliser une version commerciale.

20.10.1 Utilisation de périphériques de bloc Ceph dans Kubernetes #

Kubernetes StorageClass définit une classe de stockage. Plusieurs objets StorageClass peuvent être créés pour être assignés à différents niveaux et fonctionnalités de qualité de service. Par exemple, NVMe par rapport aux réserves sur disque dur.

Pour créer une classe de stockage ceph-csi assignée à la réserve Kubernetes créée ci-dessus, le fichier YAML suivant peut être utilisé, après avoir vérifié que la propriété clusterID correspond au FSID de votre grappe Ceph :

kubectl@adm > cat <<EOF > csi-rbd-sc.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8
   pool: kubernetes
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: default
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete
mountOptions:
   - discard
EOF
kubectl@adm > kubectl apply -f csi-rbd-sc.yaml

PersistentVolumeClaim est une requête de ressources de stockage abstrait émise par un utilisateur. Le paramètre PersistentVolumeClaim serait alors associé à une ressource de pod pour provisionner un volume PersistentVolume, qui serait soutenu par une image de bloc Ceph. Un mode de volume volumeMode facultatif peut être inclus pour choisir entre un système de fichiers monté (par défaut) ou un volume basé sur un périphérique de bloc brut.

À l'aide de ceph-csi, la spécification de Filesystem pour volumeMode peut prendre en charge les réclamations ReadWriteOnce et ReadOnlyMode accessMode et la spécification de Block pour volumeMode peut prendre en charge les réclamations ReadWriteOnce, ReadWriteMany et ReadOnlyMany accessMode.

Par exemple, pour créer une réclamation PersistentVolumeClaim basée sur des blocs qui utilise la classe ceph-csi-based StorageClass créée ci-dessus, le fichier YAML suivant peut être utilisé pour demander un stockage de bloc brut à partir de la classe de stockage csi-rbd-sc StorageClass :

kubectl@adm > cat <<EOF > raw-block-pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: raw-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f raw-block-pvc.yaml

L'exemple suivant illustre la liaison d'une réclamation PersistentVolumeClaim à une ressource de pod en tant que périphérique de bloc brut :

kubectl@adm > cat <<EOF > raw-block-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-raw-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: ["tail -f /dev/null"]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: raw-block-pvc
EOF
kubectl@adm > kubectl apply -f raw-block-pod.yaml

Pour créer une réclamation PersistentVolumeClaim basée sur le système de fichiers qui utilise la classe ceph-csi-based StorageClass créée ci-dessus, le fichier YAML suivant peut être utilisé pour demander un système de fichiers monté (soutenu par une image RBD) à partir de la classe de stockage csi-rbd-sc StorageClass :

kubectl@adm > cat <<EOF > pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f pvc.yaml

L'exemple suivant illustre la liaison d'une réclamation PersistentVolumeClaim à une ressource de pod en tant que système de fichiers monté :

kubectl@adm > cat <<EOF > pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - name: mypvc
          mountPath: /var/lib/www/html
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false
EOF
kubectl@adm > kubectl apply -f pod.yaml

20 Périphérique de bloc RADOS #

20.1 Commandes de périphériques de bloc #

20.1.1 Création d'une image de périphérique de bloc dans une réserve répliquée #

20.1.2 Création d'une image de périphérique de bloc dans une réserve codée à effacement #

20.1.3 Liste des images de périphériques de bloc #

20.1.4 Récupération d'informations sur l'image #

20.1.5 Redimensionnement d'une image de périphérique de bloc #

20.1.6 Suppression d'une image de périphérique de bloc #

20.2 Montage et démontage #

20.2.1 Création d'un compte utilisateur Ceph #

20.2.2 Authentification des utilisateurs #

20.2.3 Préparation du périphérique de bloc RADOS à utiliser #

20.2.4 rbdmap : assignation de périphériques RBD au moment du démarrage #

20.2.5 Augmentation de la taille des périphériques RBD #

20.3 Images instantanées #

20.3.1 Activation et configuration de cephx #

20.3.2 Notions de base sur les instantanés #

20.3.2.1 Création d'instantanés #

20.3.2.2 Liste des instantanés #

20.3.2.3 Restauration de l'état initial des instantanés #

20.3.2.4 Suppression d'un instantané #

20.3.2.5 Purge des instantanés #

20.3.3 Superposition d'instantanés #

20.3.3.1 Démarrage de la superposition #

20.3.3.2 Protection d'un instantané #

20.3.3.3 Clonage d'un instantané #

20.3.3.4 Suppression de la protection d'un instantané #

20.3.3.5 Liste des enfants d'un instantané #

20.3.3.6 Mise à plat d'une image clonée #

20.4 Miroirs d'image RBD #

20.4.1 Configuration de la réserve #

20.4.1.1 Activation de la mise en miroir sur une réserve #

20.4.1.2 Désactivation de la mise en miroir #

20.4.1.3 Démarrage des homologues #

20.4.1.4 Ajout manuel d'un homologue de grappe #

20.4.1.5 Suppression d'un homologue de grappe #

20.4.1.6 Réserves de données #

20.4.2 Configuration de l'image RBD #

20.4.2.1 Activation de la mise en miroir d'images #

20.4.2.2 Activation de la fonctionnalité de journalisation des images #

20.4.2.3 Création d'instantanés-miroir d'images #

20.4.2.4 Désactivation de la mise en miroir d'images #

20.4.2.5 Promotion et rétrogradation d'images #

20.4.2.6 Resynchronisation forcée de l'image #

20.4.3 Vérification de l'état du miroir #

20.5 Paramètres de cache #

20.6 Paramètres QoS #

20.7 Paramètres de la lecture anticipée #

20.8 Fonctions avancées #

20.9 Assignation RBD à l'aide d'anciens clients de kernel #

20.10 Activation des périphériques de bloc et de Kubernetes #

20.10.1 Utilisation de périphériques de bloc Ceph dans Kubernetes #

20.2.4 `rbdmap` : assignation de périphériques RBD au moment du démarrage #

20.3.1 Activation et configuration de `cephx` #