Pour vous connecter à Ceph Dashboard, faites pointer votre navigateur vers son URL, y compris le numéro de port. Exécutez la commande suivante pour rechercher l'adresse :

cephuser@adm > ceph mgr services | grep dashboard
"dashboard": "https://host:port/",

La commande renvoie l'URL où se trouve Ceph Dashboard. Si vous rencontrez des problèmes avec cette commande, reportez-vous au Book “Troubleshooting Guide”, Chapter 10 “Troubleshooting the Ceph Dashboard”, Section 10.1 “Locating the Ceph Dashboard”.

Figure 2.1 : Écran de connexion à Ceph Dashboard #

 

Connectez-vous à l'aide des informations d'identification créées lors du déploiement de la grappe (voir Book “Guide de déploiement”, Chapter 5 “Déploiement avec cephadm”, Section 5.3.2.9 “Configuration des informations d'identification de connexion de Ceph Dashboard”).

Astuce : compte utilisateur personnalisé

Si vous ne souhaitez pas utiliser le compte admin par défaut pour accéder à Ceph Dashboard, créez un compte utilisateur personnalisé avec des privilèges d'administrateur. Pour plus d'informations, reportez-vous au Chapitre 11, Gestion des utilisateurs et des rôles via la ligne de commande.

L'interface utilisateur du tableau de bord est divisée en plusieurs blocs : le menu utilitaire dans la partie supérieure droite de l'écran, le menu principal à gauche et le volet de contenu principal.

Figure 2.2 : Page d'accueil de Ceph Dashboard #

 

La partie supérieure droite de l'écran contient un menu utilitaire. Il comprend des tâches générales liées davantage au tableau de bord qu'à la grappe Ceph. Vous pouvez cliquer sur ses options pour accéder aux éléments suivants :

Le menu principal du tableau de bord occupe la partie gauche de l'écran. Il traite les aspects suivants :

Le volet de contenu occupe la partie principale de l'écran du tableau de bord. La page d'accueil du tableau de bord présente de nombreux widgets utiles pour vous informer brièvement sur l'état actuel de la grappe, la capacité et les performances.

Dans Ceph Dashboard, la plupart des opérations s'effectuent à l'aide de listes, par exemple, des listes de réserves, de noeuds OSD ou de périphériques RBD. Par défaut, toutes les listes se rafraîchissent automatiquement toutes les cinq secondes. Les widgets communs suivants vous aident à gérer ou à ajuster ces listes :

Cliquez sur pour déclencher un rafraîchissement manuel de la liste.

Cliquez sur pour afficher ou masquer des colonnes de table individuelles.

Cliquez sur et entrez (ou sélectionnez) le nombre de lignes à afficher sur une seule page.

Cliquez à l'intérieur de et filtrez les lignes en saisissant la chaîne à rechercher.

Utilisez pour modifier la page affichée si la liste s'étend sur plusieurs pages.

Chaque widget du tableau de bord affiche des informations d'état spécifiques liées à un aspect particulier d'une grappe Ceph en cours d'exécution. Certains widgets sont des liens actifs. Si vous cliquez sur ces derniers, ils vous redirigent vers une page détaillée associée au sujet qu'ils représentent.

Astuce : plus de détails grâce au pointeur de la souris

Certains widgets graphiques vous montrent plus de détails lorsque vous passez le pointeur de la souris sur eux.

2.6.1 Widgets de statut #

 

Les widgets Statut vous donnent un bref aperçu du statut actuel de la grappe.

Figure 2.3 : Widgets de statut #

 

Statut de la grappe

Présente des informations de base sur l'état de santé de la grappe.

Hôtes

Affiche le nombre total de noeuds de la grappe.

Moniteurs

Affiche le nombre de moniteurs en cours d'exécution et leur quorum.

OSD

Affiche le nombre total d'OSD, ainsi que le nombre d'OSD démarrés et rentrés.

Gestionnaires

Affiche le nombre de daemons Ceph Manager actifs et en veille.

Passerelles d'objet

Affiche le nombre d'instances Object Gateway en cours d'exécution.

Serveur de métadonnées (MDS)

Affiche le nombre de serveurs de métadonnées.

Passerelles iSCSI

Affiche le nombre de passerelles iSCSI configurées.

2.6.2 Widgets de capacité #

 

Les widgets Capacité affichent de brèves informations sur la capacité de stockage.

Figure 2.4 : Widgets de capacité #

 

Capacité brute

Affiche le rapport entre la capacité de stockage brute utilisée et celle disponible.

Objets

Affiche le nombre d'objets de données stockés dans la grappe.

Statut du groupe de placements

Affiche une représentation graphique des groupes de placements en fonction de leur statut.

Réserves

Affiche le nombre de réserve dans la grappe.

Groupes de placements par OSD

Affiche le nombre moyen de groupes de placements par OSD.

2.6.3 Widgets de performance #

 

Les widgets Performance font référence aux données de performance de base des clients Ceph.

Figure 2.5 : Widgets de performance #

 

Lectures/Écritures client

Quantité d'opérations de lecture et d'écriture des clients par seconde.

Débit client

Quantité de données transférées vers et depuis les clients Ceph, en octets par seconde.

Débit de récupération

Débit de données récupérées par seconde.

Nettoyage

Affiche le statut du nettoyage (voir Section 17.4.9, « Nettoyage d'un groupe de placement »), à savoir Inactif, Activé ou Actif.

Cliquez sur dans le menu utilitaire, puis sélectionnez Gestion des utilisateurs.

La liste contient le nom d'utilisateur de chaque utilisateur, son nom complet, son adresse électronique, la liste des rôles assignés, l'état d'activation du rôle et la date d'expiration du mot de passe.

Figure 3.1 : Gestion des utilisateurs #

 

Cliquez sur Créer en haut à gauche de l'en-tête de tableau pour ajouter un nouvel utilisateur. Entrez son nom d'utilisateur, son mot de passe et éventuellement un nom complet et une adresse électronique.

Figure 3.2 : Ajout d'un utilisateur #

 

Cliquez sur la petite icône de crayon pour assigner des rôles prédéfinis à l'utilisateur. Confirmez en cliquant sur le bouton Créer Utilisateur.

Dans le tableau, cliquez sur la ligne d'un utilisateur pour la mettre en surbrillance, puis sélectionnez Modifier pour éditer les détails de l'utilisateur. Confirmez en cliquant sur le bouton Edit User (Modifier l'utilisateur).

Cliquez sur la ligne d'un utilisateur dans le tableau pour la mettre en surbrillance, puis sélectionnez le bouton de liste déroulante en regard de Modifier et sélectionnez Supprimer dans la liste pour supprimer le compte utilisateur. Cochez la case Oui et confirmez avec le bouton Delete User (Supprimer l'utilisateur).

Cliquez sur dans le menu utilitaire, puis sélectionnez Gestion des utilisateurs. Cliquez ensuite sur l'onglet Rôles.

La liste contient le nom et la description de chaque rôle, et indique s'il s'agit d'un rôle système.

Figure 3.3 : Rôles utilisateur #

 

Cliquez sur Créer en haut à gauche de l'en-tête de tableau pour ajouter un nouveau rôle personnalisé. Entrez le Nom et la Description, puis en regard de Autorisations, sélectionnez les autorisations appropriées.

Astuce : purge des rôles personnalisés

Si vous créez des rôles utilisateur personnalisés et avez l'intention de supprimer ultérieurement la grappe Ceph à l'aide de la commande ceph-salt purge, vous devez d'abord purger les rôles personnalisés. Pour plus de détails, reportez-vous à la Section 13.9, « Suppression d'une grappe Ceph entière ».

Figure 3.4 : Ajout d'un rôle #

 

Astuce : activation multiple

Si vous cochez la case qui précède le nom du périmètre, vous activez toutes les autorisations pour ce périmètre. Si vous cochez la case Tout, vous activez toutes les autorisations pour tous les périmètres.

Confirmez en cliquant sur le bouton Créer un rôle.

Cliquez sur la ligne d'un utilisateur dans le tableau pour la mettre en surbrillance, puis sélectionnez Modifier en haut à gauche de l'en-tête du tableau pour éditer la description et les autorisations du rôle personnalisé. Confirmez en cliquant sur le bouton Edit Role (Modifier le rôle).

Cliquez sur la ligne d'un rôle dans le tableau pour la mettre en surbrillance, puis sélectionnez le bouton de liste déroulante en regard de Modifier et sélectionnez Supprimer dans la liste pour supprimer le rôle. Cochez la case Oui et confirmez avec le bouton Delete Role (Supprimer le rôle).

Cliquez sur Grappe › Hôtes pour afficher la liste des noeuds de la grappe.

Figure 4.1 : Hôtes #

 

Cliquez sur la flèche de liste déroulante en regard d'un nom de noeud dans la colonne Nom d'hôte pour afficher les détails des performances du noeud.

La colonne Services répertorie tous les daemons qui s'exécutent sur chaque noeud associé. Cliquez sur un nom de daemon pour afficher sa configuration détaillée.

Cliquez sur Grappe › Inventaire pour afficher la liste des périphériques. La liste inclut le chemin, le type, la disponibilité, le fournisseur, le modèle, la taille et les OSD du périphérique.

Cliquez pour sélectionner un nom de noeud dans la colonne Nom d'hôte. Une fois le nom sélectionné, cliquez sur Identifier pour identifier le périphérique sur lequel l'hôte s'exécute. Cela indique au périphérique de faire clignoter ses voyants. Sélectionnez la durée de cette opération entre 1, 2, 5, 10 et 15 minutes. Cliquez sur Exécuter.

Figure 4.2 : Services #

 

Cliquez sur Grappe › Moniteurs pour afficher la liste des noeuds de la grappe hébergeant des moniteurs Ceph en cours d'exécution. Le volet de contenu est divisé en deux vues : Statut et Dans le quorum ou Hors quorum.

Le tableau Statut affiche des statistiques générales sur les instances Ceph Monitor en cours d'exécution, notamment les informations suivantes :

Les volets Dans le quorum et Hors quorum incluent le nom de chaque moniteur, son numéro de rang, son adresse IP publique et le nombre de sessions ouvertes.

Cliquez sur un nom de noeud dans la colonne Nom pour afficher la configuration Ceph Monitor associée.

Figure 4.3 : Ceph Monitor #

 

Cliquez sur Grappe › Services pour afficher les détails de chacun des services disponibles : crash, Ceph Manager et les instances Ceph Monitor. La liste inclut le nom et l'ID de l'image du conteneur, le statut de ce qui est en cours d'exécution, la taille et la date du dernier rafraîchissement.

Cliquez sur la flèche de liste déroulante en regard d'un nom de service dans la colonne Service pour afficher les détails du daemon. La liste détaillée inclut le nom d'hôte, le type et l'ID du daemon, l'ID du conteneur, le nom et l'ID de l'image du conteneur, le numéro de version, le statut et la date du dernier rafraîchissement.

Figure 4.4 : Services #

 

Cliquez sur Grappe › OSD pour afficher la liste des noeuds hébergeant des daemons OSD en cours d'exécution. La liste comprend, pour chaque noeud, le nom, l'ID, le statut, la classe de périphérique, le nombre de groupes de placements, la taille, l'utilisation, un graphique des octets de lecture/d'écriture dans le temps, ainsi que le taux d'opérations de lecture/écriture par seconde.

Figure 4.5 : Instances Ceph OSD #

 

Sélectionnez Drapeaux dans le menu déroulant de configuration de la grappe dans l'en-tête du tableau pour ouvrir une fenêtre contextuelle. Elle contient une liste des drapeaux qui s'appliquent à l'ensemble de la grappe. Vous pouvez activer ou désactiver des drapeaux individuels et confirmer avec le bouton Soumettre.

Figure 4.6 : Drapeaux OSD #

 

Sélectionnez Priorité de récupération dans le menu déroulant de configuration de la grappe dans l'en-tête du tableau pour ouvrir une fenêtre contextuelle. Elle contient une liste des priorité de récupération des OSD qui s'appliquent à l'ensemble de la grappe. Vous pouvez activer le profil de priorité préféré et affiner les différentes valeurs ci-dessous. Confirmez en cliquant sur Soumettre.

Figure 4.7 : Priorité de récupération des OSD #

 

Cliquez sur la flèche de liste déroulante en regard d'un nom de noeud dans la colonne Hôte pour afficher un tableau étendu avec des détails sur les paramètres et les performances des périphériques. En parcourant plusieurs onglets, vous pouvez voir les listes Attributs, Métadonnées, Santé du périphérique, Compteur de performance, ainsi qu'un Histogramme graphique des opérations de lecture et d'écriture et les Détails des performances.

Figure 4.8 : Détails des OSD #

 

Astuce : exécution de tâches spécifiques sur les OSD

Une fois que vous avez cliqué sur un nom de noeud OSD, la ligne du tableau est mise en surbrillance. Cela signifie que vous pouvez désormais effectuer une tâche sur le noeud. Vous pouvez choisir d'effectuer l'une des opérations suivantes : Modifier, Créer, Nettoyer, Nettoyage en profondeur, Réévaluer, Marquer comme sorti, Marquer comme rentré, Marquer comme arrêté, Marquer comme perdu, Purger, Détruire ou Supprimer.

Cliquez sur la flèche vers le bas en haut à gauche de l'en-tête du tableau à côté du bouton Créer et sélectionnez la tâche à effectuer.

Cliquez sur Grappe › Configurationpour afficher une liste complète des options de configuration de la grappe Ceph. La liste contient le nom de l'option, sa brève description et ses valeurs actuelles et par défaut, et indique si l'option est modifiable.

Figure 4.14 : Configuration de la grappe #

 

Cliquez sur la flèche de liste déroulante en regard d'une option de configuration dans la colonne Nom pour afficher un tableau étendu avec des informations détaillées sur l'option, telles que son type de valeur, les valeurs minimales et maximales autorisées, si elle peut être mise à jour au moment de l'exécution, etc.

Lorsqu'une option spécifique est mise en surbrillance, vous pouvez éditer sa ou ses valeurs en cliquant sur le bouton Modifier en haut à gauche de l'en-tête du tableau. Confirmez les modifications en cliquant sur Enregistrer.

Cliquez sur Grappe › Carte CRUSH pour afficher une carte CRUSH de la grappe. Pour plus d'informations générales sur les cartes CRUSH, reportez-vous à la Section 17.5, « Manipulation de la carte CRUSH ».

Cliquez sur la racine, les noeuds ou des OSD spécifiques pour afficher des informations plus détaillées, telles que la pondération CRUSH, la profondeur dans l'arborescence de la carte, la classe de périphérique de l'OSD, etc.

Figure 4.15 : Carte CRUSH #

 

Cliquez sur Grappe › Modules Manager pour afficher une liste des modules Ceph Manager disponibles. Chaque ligne reprend un nom de module et indique s'il est actuellement activé ou non.

Figure 4.16 : Modules Manager #

 

Cliquez sur la flèche de liste déroulante en regard d'un module dans la colonne Nom pour afficher un tableau étendu avec des paramètres détaillés dans le tableau Détails ci-dessous. Pour les éditer, cliquez sur Modifier en haut à gauche de l'en-tête du tableau. Confirmez les modification en cliquant sur Mise à jour.

Cliquez sur la flèche de la liste déroulante en regard du bouton Modifier en haut à gauche de l'en-tête du tableau pour Activer ou Désactiver un module.

Cliquez sur Grappe › Journaux pour afficher une liste des entrées de journal récentes de la grappe. Chaque ligne comprend un tampon horaire, le type de l'entrée de journal et le message consigné.

Cliquez sur l'onglet Journaux d'audit pour afficher les entrées de journal du sous-système d'audit. Reportez-vous à la Section 11.5, « Audit des requêtes API » pour connaître les commandes permettant d'activer ou de désactiver les audits.

Figure 4.17 : Journaux #

 

Cliquez sur Grappe › Surveillancepour gérer et afficher les détails des alertes Prometheus.

Si Prometheus est actif, dans ce volet de contenu, vous pouvez afficher des informations détaillées sur les Alertes actives, Toutes les alertes ou les Silences.

Note

Si Prometheus n'est pas déployé, une bannière d'information apparaît avec un lien vers la documentation appropriée.

Pour ajouter une nouvelle réserve, cliquez sur Créer en haut à gauche du tableau des réserves. Dans le formulaire de la réserve, vous pouvez entrer le nom de la réserve, son type, ses applications, son mode de compression et ses quotas, y compris le nombre maximal d'octets et d'objets. Le formulaire de la réserve calcule lui-même le nombre de groupes de placements qui convient le mieux à cette réserve. Le calcul est basé sur la quantité d'OSD dans la grappe et le type de réserve sélectionné avec ses paramètres spécifiques. Dès qu'un nombre de groupes de placements est défini manuellement, il est remplacé par un nombre calculé. Confirmez en cliquant sur le bouton Create pool (Créer une réserve).

Figure 5.2 : Ajout d'une nouvelle réserve #

 

Pour supprimer une réserve, sélectionnez-la dans la ligne du tableau. Cliquez sur la flèche de liste déroulante en regard du bouton Créer, puis sur Supprimer.

Pour modifier les options d'une réserve, sélectionnez la réserve dans la ligne du tableau, puis cliquez sur Éditer en haut à gauche du tableau des réserves.

Vous pouvez modifier le nom de la réserve, augmenter le nombre de groupes de placements et éditer la liste des applications et les paramètres de compression. Confirmez en cliquant sur le bouton Edit pool (Modifier une réserve).

Pour afficher des informations plus détaillées sur un périphérique, cliquez sur sa ligne dans le tableau :

Figure 6.2 : Détails des RBD #

 

Pour afficher la configuration détaillée d'un périphérique, cliquez sur sa ligne dans le tableau, puis sur l'onglet Configuration dans le tableau inférieur :

Figure 6.3 : Configuration d'un RBD #

 

Pour ajouter un nouveau périphérique, cliquez sur Créer en haut à gauche de l'en-tête du tableau, puis procédez comme suit dans l'écran Créer RBD :

Figure 6.4 : Ajout d'un nouveau RBD #

 

Pour supprimer un périphérique, sélectionnez-le dans la ligne du tableau. Cliquez sur la flèche de liste déroulante en regard du bouton Créer, puis sur Supprimer. Confirmez la suppression en cliquant sur Delete RBD (Supprimer le RBD).

Astuce : déplacement de RBD vers la corbeille

La suppression d'un RDB est une opération irréversible. En revanche, Déplacer vers la corbeille vous permet de restaurer ultérieurement le périphérique en le sélectionnant sur l'onglet Corbeille du principal tableau et en cliquant sur Restaurer en haut à gauche de l'en-tête du tableau.

Pour créer un instantané de périphérique de traitement par blocs RADOS, sélectionnez le périphérique dans la ligne du tableau. Le volet de contenu de configuration détaillé apparaît. Sélectionnez l'onglet Instantanés et cliquez sur Créer en haut à gauche de l'en-tête du tableau. Entrez le nom de l'instantané et confirmez en cliquant sur Create RBD Snapshot (Créer un instantané de RBD).

Après avoir sélectionné un instantané, vous pouvez effectuer des opérations supplémentaires sur le périphérique, telles que renommer, protéger, cloner, copier ou supprimer. Rollback restaure l'état de l'appareil à partir de l'instantané actuel.

Figure 6.5 : Instantanés de RBD #

 

Les images RBD peuvent être mises en miroir de manière asynchrone entre deux grappes Ceph. Vous pouvez utiliser Ceph Dashboard pour configurer la réplication d'images RBD entre plusieurs grappes. Cette fonctionnalité est disponible en deux modes :

La mise en miroir est configurée réserve par réserve au sein des grappes homologues et 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, qui est installée par défaut dans SUSE Enterprise Storage 7. Le daemon rbd-mirror est chargé d'extraire les mises à jour de l'image de la grappe homologue distante et de les appliquer à l'image dans la grappe locale. Reportez-vous à la Section 6.6.2, « Activation du daemon rbd-mirror » pour plus d'informations sur l'activation du daemon rbd-mirror.

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

Important

Chaque instance du daemon rbd-mirror doit pouvoir se connecter simultanément aux grappes Ceph locales et distantes, par exemple tous les hôtes de 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.

Astuce : informations générales

Pour des informations générales et l'approche de ligne de commande pour la mise en miroir de périphérique de bloc RADOS, reportez-vous à la Section 20.4, « Miroirs d'image RBD ».

6.6.1 Configuration de grappes primaires et secondaires #

 

Une grappe primaire est celle sur laquelle la réserve d'origine avec les images est créée. Une grappe secondaire est celle sur laquelle la réserve ou les images sont répliquées à partir de la grappe primaire.

Note : assignation d'un nom relatif

Les termes primaire et secondaire peuvent être relatifs dans le contexte de la réplication, étant donné qu'ils se rapportent davantage aux réserves individuelles qu'aux grappes. Par exemple, dans la réplication bidirectionnelle, une réserve peut être mise en miroir de la grappe primaire vers la grappe secondaire, tandis qu'une autre réserve peut être mise en miroir de la grappe secondaire vers la grappe primaire.

cephuser@adm > rbd mirror pool disable POOL_NAME

cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name

cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
  image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \
  W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
  joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \
[--direction rx-only or rx-tx] pool-name token-path

cephuser@adm > cat >>EOF < token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \
1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \
bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF
cephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token

cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid

Astuce : plus d'informations sur les passerelles iSCSI

Pour plus d'informations sur les passerelles iSCSI, reportez-vous au Chapitre 22, Passerelle Ceph iSCSI.

Pour répertorier toutes les passerelles disponibles et les images assignées, cliquez sur Bloc › iSCSI dans le menu principal. Un onglet Présentation s'ouvre et répertorie les passerelles iSCSI actuellement configurées et les images RBD assignées.

Le tableau Passerelles répertorie l'état de chaque passerelle, le nombre de cibles iSCSI et le nombre de sessions. Le tableau Images répertorie le nom de chaque image assignée, le type de backstore du nom de la réserve associée et d'autres détails statistiques.

L'onglet Cibles répertorie les cibles iSCSI actuellement configurées.

Figure 6.14 : Liste des cibles iSCSI #

 

Pour afficher des informations plus détaillées sur une cible, cliquez sur la flèche de liste déroulante sur la ligne cible du tableau. Un schéma structuré en arborescence s'ouvre et liste les disques, les portails, les initiateurs et les groupes. Cliquez sur un élément pour le développer et afficher son contenu détaillé, éventuellement avec une configuration associée dans le tableau sur la droite.

Figure 6.15 : Détails d'une cible ISCSI #

 

6.7.1 Ajout de cibles iSCSI #

 

Pour ajouter une nouvelle cible iSCSI, cliquez sur Créer en haut à gauche dans le tableau Cibles, puis entrez les informations requises.

Figure 6.16 : Ajout d'une nouvelle cible #

 

1. Entrez l'adresse cible de la nouvelle passerelle.

2. Cliquez sur Add portal (Ajouter un portail) et sélectionnez un ou plusieurs portails iSCSI dans la liste.

3. Cliquez sur Add image (Ajouter une image) et sélectionnez une ou plusieurs images RBD pour la passerelle.

4. Si vous devez utiliser l'authentification pour accéder à la passerelle, sélectionnez la case à cocher Authentification ACL, puis entrez les informations d'identification. Vous pouvez trouver des options d'authentification plus avancées après avoir activé l'authentification mutuelle et l'authentification par détection.

5. Confirmez en cliquant sur le bouton Create Target (Créer une cible).

Astuce : informations supplémentaires

Pour plus d'informations générales et une description des options de configuration QoS RBD, reportez-vous à la Section 20.6, « Paramètres QoS ».

Les options QoS peuvent être configurées à différents niveaux.

La configuration globale est en haut de la liste et sera utilisée pour toutes les images RBD récemment créées et pour les images qui ne remplacent pas ces valeurs au niveau de la couche image RBD ou réserve. Une valeur d'option spécifiée globalement peut être remplacée par réserve ou par image. Les options spécifiées sur une réserve seront appliquées à toutes les images RBD de cette réserve, excepté si elles sont remplacées par une option de configuration définie sur une image. Les options spécifiées sur une image remplaceront les options spécifiées sur une réserve et celles définies globalement.

De cette façon, il est possible de définir des valeurs par défaut de manière globale, de les adapter pour toutes les images RBD d'une réserve spécifique et de remplacer la configuration de la réserve pour des images RBD individuelles.

6.8.2 Configuration des options d'une nouvelle réserve #

 

Pour créer une réserve et configurer ses options de configuration RBD, cliquez sur Réserves ›  Créer. Sélectionnez replicated (répliqué) comme type de réserve. Vous devez ensuite ajouter la balise d'application rbd à la réserve pour être en mesure de configurer les options QoS RBD.

Note

Il n'est pas possible de définir les options de configuration RBD QoS sur une réserve codée à effacement. Pour configurer les options QoS RBD pour les réserves codées à effacement, vous devez modifier la réserve de métadonnées répliquée d'une image RBD. La configuration sera ensuite appliquée à la réserve de données codée à effacement de cette image.

6.8.3 Configuration des options d'une réserve existante #

 

Pour configurer les options QoS RBD sur une réserve existante, cliquez sur Réserves, puis sur la ligne de la réserve dans le tableau, et sélectionnez Modifier en haut à gauche du tableau.

Dans la boîte de dialogue, vous devriez voir la section Configuration RBD suivie d'une section Qualité de service.

Note

Si aucune d'elles n'apparaît, vous êtes probablement occupé à modifier une réserve codée à effacement, qui ne permet pas de définir des options de configuration RBD, ou la réserve n'est pas configurée pour être utilisée par des images RBD. Dans ce dernier cas, assignez la balise d'application rbd à la réserve et les sections de configuration correspondantes s'afficheront.

Pour ajouter un nouvelle exportation NFS, cliquez sur Créer en haut à gauche du tableau des exportations, puis entrez les informations requises.

Figure 7.3 : Ajout d'une nouvelle exportation NFS #

 

Pour supprimer une exportation, sélectionnez-la et mettez-la en surbrillance dans la ligne du tableau. Cliquez sur la flèche de liste déroulante en regard du bouton Modifier et sélectionnez Supprimer. Cochez la case Oui et confirmez avec le bouton Supprimer l'exportation NFS.

Pour modifier une exportation existante, sélectionnez-la et mettez-la en surbrillance dans la ligne du tableau, puis cliquez sur Modifier en haut à gauche du tableau des exportations.

Vous pouvez ensuite régler tous les détails de l'exportation NFS.

Figure 7.4 : Modification d'une exportation NFS #

 

Cliquez sur Systèmes de fichiers dans le menu principal pour afficher la vue d'ensemble des systèmes de fichiers configurés. Le tableau principal affiche le nom de chaque système de fichiers, sa date de création et s'il est activé ou non.

Vous pouvez cliquer sur la ligne d'un système de fichiers dans le tableau afin de découvrir des détails sur son rang et sur les réserves ajoutées au système de fichiers.

Figure 8.1 : Détails CephFS #

 

Au bas de l'écran, vous pouvez voir des statistiques comptant le nombre d'inodes MDS connexes et les demandes des clients, recueillies en temps réel.

Figure 8.2 : Détails CephFS #

 

Pour afficher une liste des passerelles Object Gateway configurées, cliquez sur Object Gateway › Daemons. La liste comprend l'ID de la passerelle, le nom de l'hôte du noeud de grappe sur lequel le daemon de la passerelle est en cours d'exécution et le numéro de version de la passerelle.

Cliquez sur la flèche de liste déroulante en regard du nom de la passerelle pour afficher des informations détaillées sur cette dernière. L'onglet Compteurs de performance affiche les détails des opérations de lecture/d'écriture et les statistiques de cache.

Figure 9.1 : Détails de la passerelle #

 

Cliquez sur Object Gateway › Utilisateurs pour afficher une liste des utilisateurs Object Gateway existants.

Cliquez sur la flèche de liste déroulante en regard du nom d'utilisateur pour afficher des détails sur le compte utilisateur, tels que les informations de statut ou les détails de quota utilisateur et de compartiments.

Figure 9.2 : Utilisateurs de la passerelle #

 

9.2.1 Ajout d'un nouvel utilisateur de la passerelle #

 

Pour ajouter un nouvel utilisateur de la passerelle, cliquez sur Créer en haut à gauche de l'en-tête du tableau. Remplissez les informations d'identification, les détails sur la clé S3 et les quotas utilisateur et de compartiments, puis confirmez en cliquant sur Créer Utilisateur.

Figure 9.3 : Ajout d'un nouvel utilisateur de la passerelle #

 

Les compartiments Object Gateway (OGW) implémentent la fonctionnalité des conteneurs OpenStack Swift. Ils servent de conteneurs pour le stockage des objets de données.

Cliquez sur Object Gateway › Compartiments pour afficher une liste des compartiments Object Gateway.

9.3.1 Ajout d'un nouveau compartiment #

 

Pour ajouter un nouvel compartiment Object Gateway, cliquez sur Créer en haut à gauche de l'en-tête du tableau. Entrez le nom du compartiment, sélectionnez le propriétaire et définissez la cible de placement. Confirmez en cliquant sur le bouton Create Bucket (Créer un compartiment).

Note

À ce stade, vous pouvez également activer le verrouillage en sélectionnant Activé. Cela peut toutefois être configuré après la création. Pour plus d'informations, reportez-vous à la Section 9.3.3, « Modification du compartiment ».

9.3.2 Affichage des détails d'un compartiment #

 

Pour afficher des informations détaillées sur un compartiment Object Gateway, cliquez sur la flèche de liste déroulante en regard du nom du compartiment.

Figure 9.4 : Détails d'un compartiment de passerelle #

 

Astuce : quota de compartiments

Sous le tableau Détails, vous pouvez trouver des détails sur les paramètres de quota de compartiments et de verrouillage.

9.3.3 Modification du compartiment #

 

Sélectionnez et mettez en surbrillance un compartiment, puis cliquez sur Modifier en haut à gauche de l'en-tête du tableau.

Vous pouvez mettre à jour le propriétaire du compartiment ou activer le contrôle des versions, l'authentification multi-critères ou le verrouillage. Cliquez sur Modifier le compartiment pour confirmer les modifications.

Figure 9.5 : Modification des détails du compartiment #

 

Par défaut, toutes les connexions HTTP vers le tableau de bord sont sécurisées via TLS/SSL. Une connexion sécurisée nécessite un certificat SSL. Vous pouvez soit utiliser un certificat auto-signé, soit générer un certificat à faire signer par une autorité de certification bien connue.

Astuce : désactivation de SSL

Vous pouvez souhaiter désactiver le support SSL pour une raison spécifique, par exemple, si le tableau de bord s'exécute derrière un proxy qui ne prend pas en charge SSL.

Soyez toutefois prudent lorsque vous désactivez SSL, car les noms d'utilisateur et les mots de passe seront envoyés au tableau de bord non chiffrés.

Pour désactiver SSL, exécutez la commande suivante :

cephuser@adm > ceph config set mgr mgr/dashboard/ssl false

Astuce : redémarrage des processus Ceph Manager

Vous devez redémarrer manuellement les processus Ceph Manager après avoir modifié le certificat et la clé SSL. Pour ce faire, vous pouvez exécuter la commande

cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME

ou désactiver, puis réactiver le module de tableau de bord, ce qui déclenche une régénération du gestionnaire :

cephuser@adm > ceph mgr module disable dashboard
cephuser@adm > ceph mgr module enable dashboard

10.1.1 Création de certificats auto-signés #

 

La création d'un certificat auto-signé pour une communication sécurisée est simple. Elle vous permet d'exécuter rapidement le tableau de bord.

Note : exigence des navigateurs Web

En cas de certificat auto-signé, la plupart des navigateurs Web exigent une confirmation explicite avant d'établir une connexion sécurisée au tableau de bord.

Pour générer et installer un certificat auto-signé, utilisez la commande intégrée suivante :

cephuser@adm > ceph dashboard create-self-signed-cert

10.1.2 Utilisation de certificats signés par une autorité de certification #

 

Pour sécuriser correctement la connexion au tableau de bord et pour éviter l'exigence de confirmation explicite imposée par les navigateurs Web en cas de certificat auto-signé, nous vous recommandons d'utiliser un certificat signé par une autorité de certification.

Vous pouvez générer une paire de clés de certificat avec une commande similaire à la suivante :

root # openssl req -new -nodes -x509 \
  -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
  -keyout dashboard.key -out dashboard.crt -extensions v3_ca

La commande ci-dessus produit les fichiers dashboard.key et dashboard.crt. Une fois le fichier dashboard.crt signé par une autorité de certification, activez-le pour toutes les instances Ceph Manager en exécutant les commandes suivantes :

cephuser@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/key -i dashboard.key

Astuce : des certificats différents pour chaque instance du gestionnaire

Si vous avez besoin de certificats différents pour chaque instance Ceph Manager, modifiez les commandes et incluez le nom de l'instance comme suit. Remplacez NAME par le nom de l'instance Ceph Manager (généralement le nom d'hôte associé) :

cephuser@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key

Ceph Dashboard se lie à une adresse TCP/IP et à un port TCP spécifiques. Par défaut, l'instance Ceph Manager actuellement active qui héberge le tableau de bord se lie au port TCP 8443 (ou 8080 lorsque SSL est désactivé).

Note

Si un pare-feu est activé sur les hôtes qui exécutent Ceph Manager (et donc Ceph Dashboard), vous devrez peut-être modifier la configuration pour autoriser l'accès à ces ports. Pour plus d'informations sur les paramètres de pare-feu pour Ceph, reportez-vous au Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Ceph Dashboard se lie par défaut à « :: », ce qui correspond à toutes les adresses IPv4 et IPv6 disponibles. Vous pouvez modifier l'adresse IP et le numéro de port de l'application Web afin qu'ils s'appliquent à toutes les instances Ceph Manager en utilisant les commandes suivantes :

cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

Astuce : configuration séparée des instances Ceph Manager

Étant donné que chaque daemon ceph-mgr héberge sa propre instance du tableau de bord, vous devrez peut-être les configurer séparément. Pour changer l'adresse IP et le numéro de port pour une instance spécifique du gestionnaire, utilisez les commandes suivantes (remplacez NAME par l'ID de l'instance ceph-mgr) :

cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

Astuce : liste des noeuds d'extrémité configurés

La commande ceph mgr services affiche tous les noeuds d'extrémité actuellement configurés. Recherchez la clé dashboard pour obtenir l'URL d'accès au tableau de bord.

Si vous ne souhaitez pas utiliser le compte d'administrateur par défaut, créez un compte utilisateur différent et associez-le à au moins un rôle. Nous fournissons un ensemble de rôles système prédéfinis que vous pouvez utiliser. Pour plus d'informations, reportez-vous au Chapitre 11, Gestion des utilisateurs et des rôles via la ligne de commande.

Pour créer un utilisateur avec des privilèges d'administrateur, utilisez la commande suivante :

cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

Pour utiliser la fonctionnalité de gestion d'Object Gateway du tableau de bord, vous devez fournir les informations d'identification de connexion d'un utilisateur avec le drapeau system activé :

Note

Par défaut, le pare-feu est activé dans SUSE Linux Enterprise Server 15 SP2. Pour plus d'informations sur la configuration du pare-feu, reportez-vous au Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Plusieurs points sont à prendre en considération :

Ceph Dashboard gère les cibles iSCSI à l'aide de l'API REST fournie par le service rbd-target-api de la passerelle Ceph iSCSI. Assurez-vous qu'elle est installée et activée sur les passerelles iSCSI.

Note

La fonctionnalité de gestion iSCSI de Ceph Dashboard dépend de la dernière version 3 du projet ceph-iscsi. Vérifiez que votre système d'exploitation fournit la version correcte, sinon Ceph Dashboard n'activera pas les fonctions de gestion.

Si l'API REST ceph-iscsi est configurée en mode HTTPS et qu'elle utilise un certificat auto-signé, configurez le tableau de bord pour éviter la vérification du certificat SSL lors de l'accès à l'API ceph-iscsi.

Désactivez la vérification SSL de l'API :

cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false

Définissez les passerelles iSCSI disponibles :

cephuser@adm > ceph dashboard iscsi-gateway-list
cephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]
cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name

Single Sign-on (SSO) est une méthode de contrôle d'accès qui permet aux utilisateurs de se connecter avec un seul ID et mot de passe à plusieurs applications simultanément.

Ceph Dashboard prend en charge l'authentification externe des utilisateurs via le protocole SAML 2.0. Étant donné que l'autorisation passe toujours par le tableau de bord, vous devez d'abord créer des comptes utilisateur et les associer aux rôles souhaités. En revanche, le processus d'authentification peut être exécuté par un fournisseur d'identité (IdP) existant.

Pour configurer Single Sign-on, utilisez la commande suivante :

cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \
 IDP_METADATA IDP_USERNAME_ATTRIBUTE \
 IDP_ENTITY_ID SP_X_509_CERT \
 SP_PRIVATE_KEY

Paramètres :

Note : requêtes SAML

La valeur de l'émetteur des requêtes SAML suivra ce modèle :

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

Pour afficher la configuration SAML 2.0 actuelle, exécutez :

cephuser@adm > ceph dashboard sso show saml2

Pour désactiver Single Sign-on, exécutez :

cephuser@adm > ceph dashboard sso disable

Pour vérifier si SSO est activé, exécutez :

cephuser@adm > ceph dashboard sso status

Pour activer SSO, exécutez :

cephuser@adm > ceph dashboard sso enable saml2

Par défaut, la fonction de stratégie de mot de passe est activée, y compris les vérifications suivantes :

La fonction de stratégie de mot de passe peut être complètement activée ou désactivée :

cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false

Les vérifications individuelles suivantes peuvent être activées ou désactivées :

cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false

En outre, les options suivantes sont disponibles pour configurer le comportement de la stratégie de mot de passe.

Ceph Dashboard prend en charge la gestion de plusieurs comptes utilisateur. Chaque compte utilisateur se compose d'un nom d'utilisateur, d'un mot de passe (stocké sous forme codée à l'aide de bcrypt), d'un nom facultatif et d'une adresse électronique facultative.

Les comptes utilisateur sont stockés dans la base de données de configuration de Ceph Monitor et sont partagés globalement par toutes les instances Ceph Manager.

Utilisez les commandes suivantes pour gérer les comptes utilisateur :

Cette section décrit les étendues de sécurité que vous pouvez assigner à un rôle utilisateur, comment gérer les rôles des utilisateurs et comment les affecter aux comptes utilisateur.

11.3.2 Spécification des rôles utilisateur #

 

Un rôle spécifie un ensemble d'assignations entre une étendue de sécurité et un ensemble d'autorisations. Il existe quatre types d'autorisations : « read » (lire), « create » (créer), « update » (mettre à jour) et « delete » (supprimer).

L'exemple suivant spécifie un rôle pour lequel un utilisateur dispose des autorisations de lecture et de création concernant les fonctionnalités liées à la gestion des réserves, et possède toutes les autorisations pour les fonctionnalités liées à la gestion des images RBD :

{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

Le tableau de bord fournit déjà un ensemble de rôles prédéfinis que nous appelons les rôles système. Vous pouvez les utiliser instantanément après une nouvelle installation de Ceph Dashboard :

administrateur

Fournit des autorisations complètes pour toutes les étendues de sécurité.

read-only

Fournit une autorisation de lecture pour toutes les étendues de sécurité, à l'exception des paramètres du tableau de bord.

block-manager

Fournit des autorisations complètes pour les étendues « rbd-image », « rbd-mirroring » et « iscsi ».

rgw-manager

Fournit des autorisations complètes pour l'étendue « rgw ».

cluster-manager

Fournit des autorisations complètes pour les étendues « hosts », « osd », « monitor », « manager » et « config-opt ».

pool-manager

Fournit des autorisations complètes pour l'étendue « pool ».

cephfs-manager

Fournit des autorisations complètes pour l'étendue « cephfs ».

11.3.2.1 Gestion des rôles personnalisés #

 

Vous pouvez créer des rôles utilisateur à l'aide des commandes suivantes :

Créer un rôle :

cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

Supprimer un rôle :

cephuser@adm > ceph dashboard ac-role-delete ROLENAME

Ajouter des autorisations d'étendue à un rôle :

cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

Supprimer des autorisations d'étendue d'un rôle :

cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

11.3.2.2 Assignation de rôles à des comptes utilisateur #

 

Utilisez les commandes suivantes pour assigner des rôles aux utilisateurs :

Définir des rôles utilisateur :

cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

Ajouter des rôles supplémentaires à un utilisateur :

cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

Supprimer des rôles d'un utilisateur :

cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

Astuce : purge des rôles personnalisés

Si vous créez des rôles utilisateur personnalisés et avez l'intention de supprimer ultérieurement la grappe Ceph à l'aide de l'exécuteur ceph.purge, vous devez d'abord purger les rôles personnalisés. Pour plus de détails, reportez-vous à la Section 13.9, « Suppression d'une grappe Ceph entière ».

11.3.2.3 Exemple : création d'un utilisateur et d'un rôle personnalisé #

 

Cette section illustre une procédure de création d'un compte utilisateur pouvant gérer les images RBD, afficher et créer des réserves Ceph, et accéder en lecture seule à toutes les autres étendues.

1. Créez un utilisateur nommé tux :

    cephuser@adm > ceph dashboard ac-user-create tux PASSWORD

2. Créez un rôle et spécifiez les autorisations d'étendue :

   cephuser@adm > ceph dashboard ac-role-create rbd/pool-manager
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \
    rbd-image read create update delete
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. Associez les rôles à l'utilisateur tux :

   cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

Si vous souhaitez établir une URL fixe pour accéder à Ceph Dashboard ou si vous ne souhaitez pas autoriser les connexions directes aux noeuds du gestionnaire, vous pouvez configurer un proxy qui transmet automatiquement les requêtes entrantes à l'instance ceph-mgr active.

  cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503

11.4.4 Exemple de configuration HAProxy #

 

L'exemple de configuration suivant concerne le passage TLS/SSL à l'aide de HAProxy.

Note

La configuration fonctionne dans les conditions suivantes : en cas de basculement du tableau de bord, le client frontal peut recevoir une réponse de redirection HTTP (303) et être redirigé vers un hôte impossible à résoudre.

Cela se produit lorsque le basculement intervient au cours de deux vérifications de l'état de santé HAProxy. Dans cette situation, le noeud de tableau de bord précédemment actif répond alors par un code 303 qui pointe vers le nouveau noeud actif. Pour éviter cela, vous devez envisager de désactiver le comportement de redirection sur les noeuds de secours.

  defaults
    log global
    option log-health-checks
    timeout connect 5s
    timeout client 50s
    timeout server 450s

  frontend dashboard_front
    mode http
    bind *:80
    option httplog
    redirect scheme https code 301 if !{ ssl_fc }

  frontend dashboard_front_ssl
    mode tcp
    bind *:443
    option tcplog
    default_backend dashboard_back_ssl

  backend dashboard_back_ssl
    mode tcp
    option httpchk GET /
    http-check expect status 200
    server x HOST:PORT ssl check verify none
    server y HOST:PORT ssl check verify none
    server z HOST:PORT ssl check verify none

L'API REST de Ceph Dashboard peut consigner les requêtes PUT, POST et DELETE dans le journal d'audit Ceph. La consignation est désactivée par défaut, mais vous pouvez l'activer avec la commande suivante :

cephuser@adm > ceph dashboard set-audit-api-enabled true

Si elle est activée, les paramètres suivants sont consignés pour chaque requête :

Un exemple d'entrée de journal ressemble à ceci :

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \
 from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \
 user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "user@example.com"}'

Astuce : désactivation de la consignation de la charge utile de requête

La consignation de la charge utile de requête (la liste des arguments et leurs valeurs) est activée par défaut. Vous pouvez la désactiver comme suit :

cephuser@adm > ceph dashboard set-audit-api-log-payload false

Ceph Dashboard peut gérer les exportations NFS Ganesha qui utilisent CephFS ou Object Gateway comme backstore. Le tableau de bord gère les fichiers de configuration NFS Ganesha stockés dans des objets RADOS sur la grappe CephFS. NFS Ganesha doit stocker une partie de leur configuration dans la grappe Ceph.

Exécutez la commande suivante pour configurer l'emplacement de l'objet de configuration NFS Ganesha :

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]

Vous pouvez désormais gérer les exportations NFS Ganesha à l'aide de Ceph Dashboard.

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*

Les plug-ins Ceph Dashboard étendent les fonctionnalités du tableau de bord. Le plug-in de débogage permet de personnaliser le comportement du tableau de bord en fonction du mode de débogage. Il peut être activé, désactivé ou vérifié à l'aide de la commande suivante :

cephuser@adm > ceph dashboard debug status
Debug: 'disabled'
cephuser@adm > ceph dashboard debug enable
Debug: 'enabled'
cephuser@adm > dashboard debug disable
Debug: 'disabled'

Par défaut, il est désactivé. Il s'agit du paramètre recommandé pour les déploiements de production. Si nécessaire, le mode débogage peut être activé sans redémarrage.

La commande ceph status ou ceph -s permet de connaître l'état immédiat de la grappe :

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

La sortie fournit les informations suivantes :

Astuce : méthode utilisée par Ceph pour calculer l'utilisation des données

La valeur de used reflète la quantité réelle de stockage brut utilisée. La valeur de xxx Go/xxx Go désigne la quantité disponible de la capacité de stockage globale de la grappe (la quantité disponible correspond à la valeur inférieure). Le nombre théorique reflète la taille des données stockées avant qu'elles soient répliquées ou clonées ou qu'elles fassent l'objet d'un instantané. Par conséquent, la quantité de données réellement stockée dépasse généralement la quantité théorique stockée, car Ceph crée des répliques des données et peut également utiliser la capacité de stockage pour le clonage et la création d'instantanés.

Les autres commandes affichant des informations d'état immédiat sont les suivantes :

Pour obtenir les informations mises à jour en temps réel, utilisez l'une de ces commandes (y compris ceph -s) comme argument de la commande watch :

root # watch -n 10 'ceph -s'

Appuyez sur Ctrl–C pour refermer la sortie de la commande.

Après avoir démarré votre grappe et avant de commencer à lire et/ou à écrire des données, vérifiez l'état d'intégrité de votre grappe :

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Astuce

Si vous avez choisi des emplacements autres que ceux par défaut pour votre configuration ou votre trousseau de clés, vous pouvez les indiquer ici :

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

La grappe Ceph renvoie l'un des codes d'intégrité suivants :

Astuce

Si vous avez choisi des emplacements autres que ceux par défaut pour votre configuration ou votre trousseau de clés, vous pouvez les indiquer ici :

root # ceph -c /path/to/conf -k /path/to/keyring health

Pour vérifier l'utilisation des données d'une grappe et leur distribution entre les réserves, utilisez la commande ceph df. Pour obtenir plus de détails, utilisez ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

La section RAW STORAGE de la sortie donne un aperçu de la quantité de stockage utilisée pour vos données par la grappe.

La section POOLS de la sortie fournit la liste des réserves et l'utilisation théorique de chaque réserve. La sortie de cette section ne reflète pas les répliques, les clones ou les instantanés existants. Par exemple, si vous stockez un objet de 1 Mo de données, l'utilisation théorique est de 1 Mo, mais l'utilisation réelle peut être de 2 Mo ou plus selon le nombre de répliques, de clones et d'instantanés.

Note

Les nombres figurant dans la section POOLS sont théoriques. Ils n'incluent pas le nombre de répliques, d'instantanés ou de clones. Par conséquent, la somme des montants USED et %USED ne correspond pas aux montants RAW USED et %RAW USED dans la section RAW STORAGE de la sortie.

Vous pouvez vérifier les OSD pour vous assurer qu'ils sont opérationnels et activés à l'aide de la commande suivante :

cephuser@adm > ceph osd stat

ou

cephuser@adm > ceph osd dump

Vous pouvez également afficher les OSD en fonction de leur position dans la carte CRUSH.

ceph osd tree permet d'afficher une arborescence CRUSH avec un hôte, ses OSD, leur état et leur pondération :

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

Ceph vous empêche d'écrire sur un OSD plein afin de vous éviter de perdre des données. Pour une grappe opérationnelle, un message d'avertissement doit s'afficher lorsque celle-ci est sur le point d'atteindre son ratio complet. La valeur par défaut de monosd full ratio est 0.95, c'est-à-dire 95 % de la capacité au-delà de laquelle les clients ne peuvent plus écrire de données dans la grappe. La valeur par défaut de monosd nearfull ratio est de 0.85, c'est-à-dire 85 % de la capacité à partir de laquelle un message d'avertissement d'intégrité est émis.

Les noeuds OSD pleins sont signalés par la commande ceph health :

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

ou

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

La meilleure façon de gérer une grappe pleine consiste à ajouter de nouveaux hôtes/disques OSD permettant à la grappe de redistribuer les données à l'espace de stockage récemment disponible.

Astuce : prévention de la saturation des OSD

Un OSD plein utilise 100 % de son espace disque. Lorsqu'il atteint ce taux de remplissage, l'OSD se bloque sans avertissement. Voici quelques conseils à retenir lors de l'administration de noeuds OSD.

• L'espace disque de chaque OSD (généralement monté sous /var/lib/ceph/osd/osd-{1,2..}) doit être placé sur une partition ou un disque sous-jacent dédié.

• Vérifiez les fichiers de configuration Ceph et assurez-vous que Ceph ne stocke pas son fichier journal sur les partitions/disques dédiés aux OSD.

• Assurez-vous qu'aucun autre processus n'écrit sur les partitions/disques dédiés aux OSD.

Après avoir démarré la grappe et avant la première lecture et/ou écriture de données, vérifiez le statut du quorum des instances Ceph Monitor. Lorsque la grappe dessert déjà des requêtes, vérifiez périodiquement le statut des instances Ceph Monitor pour vous assurer qu'elles sont en cours d'exécution.

Pour afficher l'assignation des moniteurs, exécutez la commande suivante :

cephuser@adm > ceph mon stat

ou

cephuser@adm > ceph mon dump

Pour contrôler l'état du quorum de la grappe de moniteurs, exécutez la commande suivante :

cephuser@adm > ceph quorum_status

Ceph renvoie l'état du quorum. Par exemple, une grappe Ceph composée de trois moniteurs peut renvoyer les éléments suivants :

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

Les groupes de placement assignent des objets aux OSD. Lorsque vous surveillez vos groupes de placement, vous voulez qu'ils soient actifs (active) et propres (clean). Pour une explication détaillée, reportez-vous à la Section 12.9, « Surveillance des OSD et des groupes de placement ».

Lorsqu'une grappe de stockage Ceph se rapproche de sa capacité maximale, Ceph vous empêche d'écrire ou de lire à partir d'OSD Ceph afin d'éviter toute perte de données. Par conséquent, laisser une grappe de production s'approcher de son ration « full » n'est pas une bonne pratique, car cela nuit au principe de haute disponibilité. Le ratio « full » par défaut est défini sur 0,95, soit 95 % de la capacité. C'est une valeur très agressive pour une grappe de test avec un petit nombre d'OSD.

Astuce : augmentation de la capacité de stockage

Lorsque vous surveillez votre grappe, soyez attentif aux avertissements liés au ratio nearfull. Cela signifie qu'une défaillance de certains OSD pourrait entraîner une interruption de service temporaire en cas d'échec d'un ou de plusieurs OSD. Pensez à ajouter d'autres OSD pour augmenter la capacité de stockage.

Un scénario courant pour les grappes de test implique qu'un administrateur système supprime un OSD Ceph de la grappe de stockage Ceph pour examiner le rééquilibrage de la grappe. Il supprime ensuite un autre OSD Ceph, puis encore un autre, et ainsi de suite jusqu'à ce que la grappe atteigne le ratio « full » et se verrouille. Nous recommandons un minimum de planification de la capacité, même avec une grappe de test. La planification vous permet d'estimer la capacité de réserve dont vous avez besoin pour maintenir une haute disponibilité. Idéalement, vous souhaitez envisager une série de défaillances Ceph OSD où la grappe peut récupérer un état actif et propre (active + clean) sans remplacer ces Ceph OSD immédiatement. Vous pouvez exécuter une grappe dans un état actif et altéré (active + degraded), mais ce n'est pas idéal pour des conditions de fonctionnement normales.

Le diagramme suivant représente une grappe de stockage Ceph simpliste contenant 33 noeuds Ceph avec un Ceph OSD par hôte, chacun d'eux disposant d'un accès en lecture-écriture pour une unité de 3 To. Cette grappe présente une capacité réelle maximale de 99 To. L'option mon osd full ratio est définie sur 0,95. Si la grappe arrive à 5 To de la capacité restante, elle ne permettra plus aux clients de lire et d'écrire des données. Par conséquent, la capacité d'exploitation de la grappe de stockage est de 95 To, et pas de 99.

Figure 12.1 : grappe Ceph #

 

Il est normal dans une telle grappe qu'un ou deux OSD échouent. Un scénario moins fréquent, mais plausible, implique une défaillance du routeur ou de l'alimentation d'un rack, ce qui met hors service plusieurs OSD simultanément (par exemple, les OSD 7 à 12). Dans un tel scénario, vous devez toujours viser à disposer d'une grappe qui peut rester opérationnelle et atteindre un état active + clean, même si cela implique d'ajouter sans délai plusieurs hôtes avec des OSD supplémentaires. Si l'utilisation de votre capacité est trop élevée, vous ne pouvez pas risquer de perdre des données. Cela dit, vous pourriez encore sacrifier la disponibilité des données pendant la résolution d'une panne au sein d'un domaine défaillant si l'utilisation de la capacité de la grappe dépasse le ratio « full ». C'est pour cette raison que nous recommandons au moins une certaine planification approximative de la capacité.

Identifiez deux nombres pour votre grappe :

Si vous divisez la capacité totale de votre grappe par le nombre d'OSD que celle-ci contient, vous obtenez la capacité moyenne d'un OSD au sein de votre grappe. Pensez à multiplier cette valeur par le nombre d'OSD qui, selon vous, pourraient échouer simultanément lors d'opérations normales (un nombre relativement faible). Enfin, multipliez la capacité de la grappe par le ratio « full » pour arriver à une capacité d'exploitation maximale. Ensuite, soustrayez la quantité de données des OSD susceptibles d'échouer pour obtenir un ratio « full » raisonnable. Répétez ce processus avec un nombre plus élevé de défaillances OSD (un rack d'OSD) afin d'obtenir un nombre raisonnable pour un ratio « nearfull ».

Les paramètres suivants ne s'appliquent qu'à la création d'une grappe et sont ensuite stockés dans la carte OSD :

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Astuce

Ces paramètres ne s'appliquent que lors de la création d'une grappe. Par la suite, ils doivent être modifiés dans la carte OSD à l'aide des commandes ceph osd set-nearfull-ratio et ceph osd set-full-ratio.

Astuce : vérification de la pondération des OSD

Si certains OSD sont presque complets (nearfull), mais que d'autres ont beaucoup de capacité, la pondération CRUSH peut être problématique pour les OSD nearfull.

Les principes de haute disponibilité et de haute fiabilité exigent une approche de tolérance aux pannes dans le cadre de la gestion des problèmes matériels et logiciels. Ceph n'a pas de point d'échec unique et peut desservir les requêtes de données en mode altéré (« degraded »). Le placement de données de Ceph introduit une couche d'indirection pour s'assurer que les données ne se lient pas directement à des adresses OSD particulières. Cela signifie que le suivi des pannes du système nécessite de trouver le groupe de placement et les OSD sous-jacents à l'origine du problème.

Astuce : accès en cas de défaillance

Une panne dans une partie de la grappe peut vous empêcher d'accéder à un objet particulier. Cela ne signifie pas que vous ne pouvez pas accéder à d'autres objets. Lorsque vous rencontrez une panne, suivez les étapes de surveillance de vos OSD et groupes de placement. Commencez ensuite le dépannage.

Ceph peut généralement se réparer lui-même. Toutefois, lorsque des problèmes persistent, la surveillance des OSD et des groupes de placement vous aide à identifier ce qui ne va pas.

12.9.1 Surveillance des OSD #

 

Le statut d'un OSD est soit dans la grappe (« rentré », c'est-à-dire « in » en anglais), soit hors de la grappe (« sorti » - « out »). Par ailleurs, il est soit opérationnel et en cours d'exécution (« opérationnel » - « up »), soit arrêté et pas en cours d'exécution (« arrêté » - « down »). Si un OSD est « opérationnel », il peut être dans la grappe (vous pouvez lire et écrire des données) ou hors de celle-ci. S'il était dans la grappe et a été sorti récemment de cette dernière, Ceph migre les groupes de placement vers d'autres OSD. Si un OSD est hors de la grappe, CRUSH ne lui assigne pas de groupes de placement. Si un OSD est « arrêté », il doit également être « sorti ».

Note : état altéré

Si un OSD est « arrêté » et « rentré », il y a un problème et la grappe présente un état altéré.

Si vous exécutez une commande telle que ceph health, ceph -s ou ceph -w, vous pouvez remarquer que la grappe ne renvoie pas toujours la valeur HEALTH OK (État de santé OK). En ce qui concerne les OSD, vous devez vous attendre à ce que la grappe ne renvoie pas la valeur HEALTH OK dans les circonstances suivantes :

• Vous n'avez pas encore démarré la grappe (elle ne répondra pas).

• Vous avez démarré ou redémarré la grappe et elle n'est pas encore prête, car les groupes de placement sont en cours de création et les OSD, en cours d'homologation.

• Vous avez ajouté ou supprimé un OSD.

• Vous avez modifié votre assignation de grappe.

Un aspect important de la surveillance des OSD consiste à s'assurer que lorsque la grappe est opérationnelle et en cours d'exécution, tous ses OSD le sont aussi. Pour vérifier si tous les OSD sont en cours d'exécution, utilisez la commande suivante :

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

Le résultat devrait vous indiquer le nombre total d'OSD (x), combien sont « opérationnels » (y), combien sont « rentrés » (z), et l'époque d'assignation (eNNNN). Si le nombre d'OSD « rentrés » dans la grappe est supérieur au nombre d'OSD qui sont « opérationnels », exécutez la commande suivante pour identifier les daemons ceph-osd qui ne sont pas en cours d'exécution :

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Par exemple, si un OSD avec l'ID 1 est arrêté, démarrez-le :

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Reportez-vous au Book “Troubleshooting Guide”, Chapter 4 “Troubleshooting OSDs”, Section 4.3 “OSDs not running” pour obtenir des informations sur les problèmes associés aux OSD qui se sont arrêtés ou qui ne redémarrent pas.

12.9.2 Assignation d'ensembles de groupes de placement #

 

Lorsque CRUSH assigne des groupes de placement aux OSD, il examine le nombre de répliques pour la réserve et attribue le groupe de placement aux OSD de telle sorte que chaque réplique du groupe de placement soit assignée à un OSD différent. Par exemple, si la réserve nécessite trois répliques d'un groupe de placement, CRUSH peut les assigner à osd.1, osd.2 et osd.3 respectivement. CRUSH vise en fait un placement pseudo-aléatoire qui tiendra compte des domaines de défaillance que vous avez définis dans votre carte CRUSH, de sorte que vous verrez rarement des groupes de placement assignés à des OSD voisins les plus proches dans une vaste grappe. Nous nous référons à l'ensemble d'OSD qui devraient contenir les répliques d'un groupe de placement particulier en tant qu'ensemble agissant. Dans certains cas, un OSD de l'ensemble agissant est arrêté ou n'est pas en mesure de desservir les requêtes d'objets dans le groupe de placement pour l'une ou l'autre raison. Ces situations peuvent se présenter dans l'un des scénarios suivants :

• Vous avez ajouté ou supprimé un OSD. Ensuite, CRUSH a réassigné le groupe de placement à d'autres OSD et a donc modifié la composition de l'ensemble agissant, provoquant la migration de données avec un processus de renvoi (« backfill »).

• Un OSD était « arrêté », a été redémarré et est maintenant en cours de récupération.

• Un OSD de l'ensemble agissant est « arrêté » ou n'est pas en mesure de desservir les requêtes, et un autre OSD a assumé temporairement ses fonctions.

  Ceph traite une requête client à l'aide de l'ensemble opérationnel, qui est l'ensemble d'OSD qui traitera réellement les requêtes. Dans la plupart des cas, l'ensemble opérationnel et l'ensemble agissant sont pratiquement identiques. Lorsqu'ils ne le sont pas, cela peut indiquer que Ceph migre des données, qu'un OSD est en cours de récupération ou qu'il existe un problème (par exemple, dans de tels scénarios, Ceph renvoie habituellement un état HEALTH WARN avec un message « stuck stale » [obsolète bloqué]).

Pour récupérer une liste des groupes de placement, exécutez la commande suivante :

cephuser@adm > ceph pg dump

Pour voir quels OSD se trouvent dans l'ensemble agissant ou dans l'ensemble opérationnel pour un groupe de placement donné, exécutez la commande suivante :

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

Le résultat devrait vous indiquer l'époque osdmap (eNNN), le nombre de groupes de placement (PG_NUM), les OSD dans l'ensemble opérationnel (« up ») et les OSD dans l'ensemble agissant (« acting ») :

Astuce : indicateur de problème de grappe

Si l'ensemble opérationnel et l'ensemble agissant ne correspondent pas, cela peut indiquer que la grappe est occupée à se rééquilibrer ou qu'elle rencontre un problème potentiel.

12.9.3 Homologation #

 

Avant de pouvoir écrire des données dans un groupe de placement, celui-ci doit présenter un état actif (« active ») et propre (« clean »). Pour que Ceph puisse déterminer l'état actuel d'un groupe de placement, l'OSD primaire du groupe de placement (le premier OSD dans l'ensemble agissant) effectue une homologation avec les OSD secondaires et tertiaires pour établir un accord sur l'état actuel du groupe de placement (dans le cas d'une réserve avec trois répliques du groupe de placement).

Figure 12.2 : Schéma d'homologation #

 

12.9.4 Surveillance des états des groupes de placement #

 

Si vous exécutez une commande telle que ceph health, ceph -s ou ceph -w, vous remarquerez peut-être que la grappe ne renvoie pas toujours un message HEALTH OK (État de santé OK). Après avoir vérifié si les OSD sont en cours d'exécution, vous devez également vérifier l'état des groupes de placement.

Attendez-vous à ce que la grappe ne renvoie pas un message HEALTH OK dans un certain nombre de circonstances liées aux homologations des groupes de placement :

• Vous avez créé une réserve et les groupes de placement n'ont pas encore effectué l'homologation.

• Les groupes de placement sont en cours de récupération.

• Vous avez ajouté ou supprimé un OSD au niveau de la grappe.

• Vous avez modifié votre carte CRUSH et vos groupes de placement sont en cours de migration.

• Les données sont incohérentes entre différentes répliques d'un groupe de placement.

• Ceph est en train de nettoyer les répliques d'un groupe de placement.

• Ceph ne dispose pas de suffisamment de capacité de stockage pour effectuer des opérations de renvoi.

Si en raison de l'une des circonstances mentionnées ci-dessus, Ceph renvoie un message HEALTH WARN, ne paniquez pas. Dans de nombreux cas, la grappe se rétablit d'elle-même. Parfois, il peut cependant arriver que vous deviez intervenir. Un aspect important de la surveillance des groupes de placement consiste à vous assurer que lorsque la grappe est opérationnelle et en cours d'exécution, tous les groupes de placement sont actifs et, de préférence, dans un état propre. Pour voir l'état de tous les groupes de placement, exécutez la commande suivante :

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

Le résultat devrait vous indiquer le nombre total de groupes de placement (x), le nombre de groupes de placement dans un état particulier tel que le « active + clean » (y) et la quantité de données stockées (z).

En plus des états des groupes de placement, Ceph renverra également la quantité de capacité de stockage utilisée (aa), la quantité de capacité de stockage restante (bb) et la capacité de stockage totale pour le groupe de placement. Ces chiffres peuvent être importants dans certains cas :

• Vous vous approchez de votre ratio nearfull (presque complet) ou full (complet).

• Vos données ne sont pas distribuées dans l'ensemble de la grappe en raison d'une erreur dans votre configuration CRUSH.

Astuce : ID de groupe de placement

Les ID de groupe de placement se composent du numéro de la réserve (pas de son nom) suivi d'un point (.) et de l'ID du groupe de placement (un nombre hexadécimal). Vous pouvez consulter les numéros des réserves et leur nom dans la sortie de la commande ceph osd lspools. Par exemple, la réserve par défaut rbd correspond au numéro de réserve 0. Un ID de groupe de placement complet se présente sous la forme suivante :

POOL_NUM.PG_ID

Il ressemble généralement à ceci :

0.1f

Pour récupérer une liste des groupes de placement, exécutez la commande suivante :

cephuser@adm > ceph pg dump

Vous pouvez également mettre la sortie au format JSON et l'enregistrer dans un fichier :

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Pour interroger un groupe de placement particulier, exécutez la commande suivante :

cephuser@adm > ceph pg POOL_NUM.PG_ID query

La liste suivante décrit en détail les statuts courants des groupes de placement.

CREATING

Lorsque vous créez une réserve, celle-ci crée le nombre de groupes de placement que vous avez spécifié. Ceph renvoie le statut « creating » (en cours de création) lorsqu'un ou plusieurs groupes de placement sont en cours de création. Une fois les groupes créés, les OSD qui font partie de l'ensemble agissant du groupe de placement effectuent l'homologation. Lorsque l'homologation est terminée, le statut du groupe de placement doit être « active + clean », ce qui signifie qu'un client Ceph peut commencer à écrire dans le groupe de placement.

Figure 12.3 : État des groupes de placement #

 

PEERING

Lorsque Ceph effectue l'homologation (« peering ») d'un groupe de placement, il amène les OSD qui stockent les répliques du groupe de placement à un accord concernant l'état des objets et des métadonnées que ce dernier contient. Lorsque Ceph termine l'homologation, cela signifie que les OSD qui stockent le groupe de placement s'accordent sur l'état actuel du groupe de placement. Toutefois, l'achèvement du processus d'homologation ne signifie pas que chaque réplique dispose du contenu le plus récent.

Note : historique faisant autorité

Ceph ne reconnaîtra une opération d'écriture pour un client que lorsque tous les OSD de l'ensemble agissant conserveront l'opération d'écriture. Cette pratique garantit qu'au moins un membre de l'ensemble agissant aura un enregistrement de chaque opération d'écriture reconnue depuis la dernière opération d'homologation réussie.

Avec un enregistrement précis de chaque opération d'écriture reconnue, Ceph peut construire et développer un nouvel historique faisant autorité pour le groupe de placement, à savoir un ensemble complet et organisé d'opérations qui, si elles sont effectuées, permettent de mettre à jour la copie d'un OSD de groupe de placement.

ACTIVE

Une fois que Ceph a terminé le processus d'homologation, un groupe de placement peut devenir actif (« active »). L'état « active » signifie que les données du groupe de placement sont généralement disponibles dans le groupe de placement primaire et les répliques pour les opérations de lecture et d'écriture.

CLEAN

Lorsqu'un groupe de placement est dans l'état propre (« clean »), cela signifie que l'OSD primaire et les OSD des répliques ont été homologués, et qu'il n'y a pas de répliques errantes pour le groupe de placement. Ceph a effectué le bon nombre de répliques de tous les objets du groupe de placement.

DEGRADED

Lorsqu'un client écrit un objet sur l'OSD primaire, ce dernier est responsable de l'écriture des répliques sur les OSD des répliques. Une fois que l'OSD primaire a écrit l'objet dans le stockage, le groupe de placement reste dans un état altéré (« degraded ») jusqu'à ce que l'OSD primaire ait reçu une confirmation des OSD des répliques indiquant que Ceph a bien créé les objets des répliques.

La raison pour laquelle un groupe de placement peut être à la fois actif et altéré (« active + degraded ») est qu'un OSD peut être actif même s'il ne détient pas encore tous les objets. Si un OSD s'arrête, Ceph marque chaque groupe de placement assigné à l'OSD comme altéré. Lorsque l'OSD en question redevient opérationnel, tous les OSD doivent à nouveau effectuer l'homologation. Toutefois, un client peut toujours écrire un nouvel objet sur un groupe de placement altéré s'il est actif.

Si un OSD est arrêté et que la condition d'altération persiste, Ceph peut marquer l'OSD arrêté comme étant sorti (« out ») de la grappe et réassigne les données de l'OSD arrêté à un autre OSD. Le délai entre le moment où un OSD est marqué comme arrêté et celui où il est considéré comme sorti de la grappe est déterminé par l'option mon osd down out interval, qui est définie par défaut sur 600 secondes.

Un groupe de placement peut également être marqué comme altéré parce que Ceph ne parvient pas à trouver un ou plusieurs objets qui devraient être dans le groupe de placement. Bien que vous ne puissiez pas lire ou écrire sur des objets introuvables, vous pouvez toujours accéder à tous les autres objets du groupe de placement altéré.

RECOVERING

Ceph a été conçu pour permettre une tolérance aux pannes dans un environnement où les problèmes matériels et logiciels sont permanents. Lorsqu'un OSD est arrêté, son contenu peut devenir obsolète par rapport à l'état actuel d'autres répliques dans les groupes de placement. Lorsque l'OSD redevient opérationnel, le contenu des groupes de placement doit alors être mis à jour pour refléter l'état actuel. Durant cette opération, l'état de l'OSD peut indiquer qu'il est en cours de récupération (« recovering»).

La récupération n'est pas toujours simple, car une défaillance matérielle peut provoquer une défaillance en cascade de plusieurs OSD. Par exemple, un commutateur réseau pour un rack ou une armoire peut tomber en panne, de sorte les OSD de plusieurs machines hôtes se retrouvent dans un état obsolète par rapport à celui de la grappe. Chacun de ces OSD doit alors récupérer une fois la panne résolue.

Ceph fournit un certain nombre de paramètres pour équilibrer les conflits de ressources entre les nouvelles requêtes de service et la nécessité de récupérer les objets de données et de restaurer les groupes de placement vers l'état actuel. Le paramètre osd recovery delay start permet à un OSD de redémarrer, d'effectuer un nouveau processus d'homologation et même de traiter certaines demandes de relecture avant d'entamer sa récupération. Le paramètre osd recovery thread timeout définit un timeout de thread, car plusieurs OSD peuvent échouer, redémarrer et effectuer une nouvelle homologation à des moments différents. Le paramètre osd recovery max active limite le nombre de demandes de récupération qu'un OSD traite simultanément afin d'éviter qu'il échoue. Le paramètre osd recovery max chunk limite la taille des tranches de données récupérées pour éviter la congestion du réseau.

BACK FILLING

Lorsqu'un nouvel OSD rejoint la grappe, CRUSH réassigne des groupes de placement des OSD de la grappe à l'OSD récemment ajouté. Obliger le nouvel OSD à accepter immédiatement les groupes de placement réassignés peut lui imposer une charge excessive. Le principe de renvoi (« backfilling ») de l'OSD avec les groupes de placement permet à ce processus de commencer en arrière-plan. Une fois le renvoi terminé, le nouvel OSD commence à desservir les requêtes lorsqu'il est prêt.

Pendant les opérations de renvoi, vous pouvez voir l'un des états suivants : « backfill_wait » indique qu'une opération de renvoi est en attente, mais pas encore en cours ; « backfill » indique qu'une opération de renvoi est en cours ; « backfill_too_full » indique qu'une opération de renvoi a été demandée, mais n'a pas pu être effectuée en raison d'une capacité de stockage insuffisante. Lorsqu'un groupe de placement ne peut pas être renvoyé, il peut être considéré comme incomplet (« incomplete »).

Ceph fournit plusieurs paramètres pour gérer la charge associée à la réassignation de groupes de placement à un OSD (en particulier un nouvel OSD). Par défaut, le paramètre osd max backfills définit le nombre maximal de renvois simultanés vers un OSD ou à partir de celui-ci à 10. Le paramètre backfill full ratio permet à un OSD de refuser une demande de renvoi si l'OSD se rapproche de son ratio « full » (90 % par défaut) et de changer avec la commande ceph osd set-backfillfull-ratio. Si un OSD refuse une demande de renvoi, le paramètre osd backfill retry interval permet à un OSD de réessayer la demande (après 10 secondes, par défaut). Les OSD peuvent également définir les paramètres osd backfill scan min et osd backfill scan max pour gérer les intervalles d'analyse (64 et 512, par défaut).

REMAPPED

Lorsque l'ensemble agissant qui dessert un groupe de placement change, les données migrent de l'ancien ensemble agissant ver le nouvel ensemble agissant. Un nouvel OSD primaire peut nécessiter un certain temps pour desservir des requêtes. C'est pourquoi il peut demander à l'ancien OSD primaire de continuer à traiter les requêtes jusqu'à ce que la migration du groupe de placement soit terminée. Une fois la migration des données terminée, l'assignation utilise l'OSD primaire du nouvel ensemble agissant.

STALE

Tandis que Ceph utilise des pulsations pour s'assurer que les hôtes et les daemons sont en cours d'exécution, les daemons ceph-osd peuvent également se retrouver dans un état bloqué (« stuck ») dans lequel ils ne rendent pas compte des statistiques en temps opportun (par exemple, en cas de défaillance temporaire du réseau). Par défaut, les daemons OSD signalent leurs statistiques de groupe de placement, de démarrage et d'échec toutes les demi-secondes (0,5), ce qui est plus fréquent que les seuils de pulsation. Si l'OSD primaire de l'ensemble agissant d'un groupe de placement ne parvient pas à rendre compte au moniteur ou si d'autres OSD ont signalé l'OSD primaire comme étant arrêté, les moniteurs marquent le groupe de placement comme obsolète (« stale »).

Lorsque vous démarrez votre grappe, il est courant de voir l'état « stale » tant que le processus d'homologation n'est pas terminé. En revanche, lorsque votre grappe est en cours d'exécution depuis un certain temps, si des groupes de placement sont dans l'état « stale », cela indique que l'OSD primaire pour ces groupes de placement est arrêté ou ne rend pas compte de ses statistiques de groupe de placement au moniteur.

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

cephuser@adm > rados -p data ls

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

cephuser@adm > rados rm test-object-1 --pool=data

Pour modifier la configuration d'une grappe Ceph existante, procédez comme suit :

Pour ajouter un noeud à une grappe Ceph, procédez comme suit :

Astuce : suppression des OSD

Si le noeud que vous souhaitez supprimer exécute des OSD, commencez par supprimer ces derniers et vérifiez qu'aucun OSD ne s'exécute sur ce noeud. Pour plus d'informations sur la suppression des OSD, reportez-vous à la Section 13.4.4, « Suppression des OSD ».

Pour supprimer un noeud d'une grappe, procédez comme suit :

Important

En cas d'échec et si le minion que vous essayez de supprimer se trouve dans un état de désactivation permanente, vous devrez supprimer le noeud du Salt Master :

root@master # salt-key -d minion_id

Supprimez ensuite manuellement le noeud du fichier pillar_root/ceph-salt.sls. Celui-ci se trouve généralement dans /srv/pillar/ceph-salt.sls.

Cette section explique comment ajouter, effacer ou supprimer des OSD dans une grappe Ceph.

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 Effacement de périphériques de disque #

 

Pour réutiliser un périphérique de disque, vous devez d'abord l'effacer :

ceph orch device zap HOST_NAME DISK_DEVICE

Par exemple :

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

Note

Si vous avez déjà déployé des OSD à l'aide de DriveGroups ou de l'option --all-available-devices alors que l'indicateur unmanaged n'était pas défini, cephadm déploiera automatiquement ces OSD une fois que vous les aurez effacés.

13.4.3 Ajout d'OSD à l'aide de la spécification DriveGroups #

 

Les groupes d'unités (« DriveGroups ») spécifient les dispositions des OSD dans la grappe Ceph. Ils sont définis dans un fichier YAML unique. Dans cette section, nous utiliserons le fichier drive_groups.yml comme exemple.

Un administrateur doit spécifier manuellement un groupe d'OSD interdépendants (OSD hybrides déployés sur un mélange de disques durs et SSD) ou qui partagent des options de déploiement identiques (par exemple, même magasin d'objets, même option de chiffrement, OSD autonomes). Pour éviter de lister explicitement les périphériques, les groupes d'unités utilisent une liste d'éléments de filtre qui correspondent à quelques champs sélectionnés de rapports d'inventaire de ceph-volume. cephadm fournit le code qui traduit ces DriveGroups en listes de périphériques réelles pour inspection par l'utilisateur.

La commande permettant d'appliquer la spécification d'OSD à la grappe est la suivante :

cephuser@adm > ceph orch apply osd -i drive_groups.yml

Pour afficher un aperçu des opérations et tester votre application, vous pouvez utiliser l'option --dry-run en combinaison avec la commande ceph orch apply osd. Par exemple :

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

Si la sortie de l'option --dry-run correspond à vos attentes, réexécutez simplement la commande sans l'option --dry-run.

13.4.3.1 OSD non gérés #

 

Tous les périphériques de disque propres disponibles correspondant à la spécification DriveGroups sont automatiquement utilisés comme OSD une fois que vous les avez ajoutés à la grappe. Ce comportement est appelé mode managed (géré).

Pour désactiver le mode managed, ajoutez la ligne unmanaged: true aux spécifications appropriées, par exemple :

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

Astuce

Pour faire passer des OSD déjà déployés du mode managed au mode unmanaged, ajoutez les lignes unmanaged: true, le cas échéant, au cours de la procédure décrite à la Section 13.1, « Modification de la configuration d'une grappe ».

13.4.3.2 Spécification DriveGroups #

 

Voici un exemple de fichier de spécification DriveGroups :

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Note

L'option précédemment appelée « encryption » (chiffrement) dans DeepSea a été renommée « encrypted » (chiffré). Lorsque vous appliquez des DriveGroups dans SUSE Enterprise Storage 7, veillez à utiliser cette nouvelle terminologie dans votre spécification de services, sinon l'opération ceph orch apply échouera.

13.4.3.3 Périphériques de disque correspondants #

 

Vous pouvez décrire les spécifications à l'aide des filtres suivants :

• Par modèle de disque :

  model: DISK_MODEL_STRING

• Par fournisseur de disque :

  vendor: DISK_VENDOR_STRING

  

  Astuce

  Saisissez toujours DISK_VENDOR_STRING en minuscules.

  Pour obtenir des informations sur le modèle et le fournisseur du disque, examinez la sortie de la commande suivante :

  cephuser@adm > ceph orch device ls
  HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
  ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
  ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
  [...]

• Selon qu'un disque est rotatif ou non. Les disques SSD et NVMe ne sont pas rotatifs.

  rotational: 0

• Déployez un noeud à l'aide de tous les disques disponibles pour les OSD :

  data_devices:
    all: true

• En outre, vous pouvez limiter le nombre de disques correspondants :

  limit: 10

13.4.3.4 Filtrage des périphériques par taille #

 

Vous pouvez filtrer les périphériques de disque par leur taille, soit en fonction d'une taille précise, soit selon une plage de tailles. Le paramètre size: (taille :) accepte les arguments sous la forme suivante :

• « 10G » : inclut les disques d'une taille exacte.

• « 10G:40G » : inclut les disques dont la taille est dans la plage.

• « :10G » : inclut les disques dont la taille est inférieure ou égale à 10 Go.

• « 40G: » : inclut les disques dont la taille est égale ou supérieure à 40 Go.

Exemple 13.1 : Correspondance par taille de disque #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

Note : guillemets requis

Lorsque vous utilisez le délimiteur « : », vous devez entourer la taille par des guillemets simples, faute de quoi le signe deux-points est interprété comme un nouveau hachage de configuration.

Astuce : abréviations des unités

Au lieu d'indiquer les tailles en gigaoctets (G), vous pouvez les spécifier en mégaoctets (M) ou téraoctets (T).

13.4.3.5 Exemples de DriveGroups #

 

Cette section comprend des exemples de différentes configurations OSD.

Exemple 13.2 : Configuration simple #

 

Cet exemple décrit deux noeuds avec la même configuration :

• 20 HDD

  • Fournisseur : Intel

  • Modèle : SSD-123-foo

  • Taille : 4 To

• 2 SSD

  • Fournisseur : Micron

  • Modèle : MC-55-44-ZX

  • Taille : 512 Go

Le fichier drive_groups.yml correspondant se présentera comme suit :

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

Une telle configuration est simple et valide. Le problème est qu'un administrateur peut ajouter des disques de fournisseurs différents par la suite et ceux-ci ne seront pas inclus. Vous pouvez améliorer cela en limitant les filtres aux propriétés de base des unités :

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

Dans l'exemple précédent, nous imposons de déclarer tous les périphériques rotatifs comme « périphériques de données » et tous les périphériques non rotatifs seront utilisés comme « périphériques partagés » (wal, db).

Si vous savez que les unités de plus de 2 To seront toujours les périphériques de données plus lents, vous pouvez filtrer par taille :

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

Exemple 13.3 : Configuration avancée #

 

Cet exemple décrit deux configurations distinctes : 20 HDD devraient partager 2 SSD, tandis que 10 SSD devraient partager 2 NVMe.

• 20 HDD

  • Fournisseur : Intel

  • Modèle : SSD-123-foo

  • Taille : 4 To

• 12 SSD

  • Fournisseur : Micron

  • Modèle : MC-55-44-ZX

  • Taille : 512 Go

• 2 NVMe

  • Fournisseur : Samsung

  • Modèle : NVME-QQQQQ-987

  • Taille : 256 Go

Une telle configuration peut être définie avec deux dispositions comme suit :

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

Exemple 13.4 : Configuration avancée avec des noeuds non uniformes #

 

Les exemples précédents supposaient que tous les noeuds avaient les mêmes unités. Cependant, ce n'est pas toujours le cas :

Noeuds 1 à 5 :

• 20 HDD

  • Fournisseur : Intel

  • Modèle : SSD-123-foo

  • Taille : 4 To

• 2 SSD

  • Fournisseur : Micron

  • Modèle : MC-55-44-ZX

  • Taille : 512 Go

Noeuds 6 à 10 :

• 5 NVMe

  • Fournisseur : Intel

  • Modèle : SSD-123-foo

  • Taille : 4 To

• 20 SSD

  • Fournisseur : Micron

  • Modèle : MC-55-44-ZX

  • Taille : 512 Go

Vous pouvez utiliser la clé « target » dans la disposition pour cibler des noeuds spécifiques. La notation de cible Salt aide à garder les choses simples :

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

suivi de

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

Exemple 13.5 : Configuration experte #

 

Tous les cas précédents supposaient que les WAL et les DB utilisaient le même périphérique. Il est cependant possible également de déployer le WAL sur un périphérique dédié :

• 20 HDD

  • Fournisseur : Intel

  • Modèle : SSD-123-foo

  • Taille : 4 To

• 2 SSD

  • Fournisseur : Micron

  • Modèle : MC-55-44-ZX

  • Taille : 512 Go

• 2 NVMe

  • Fournisseur : Samsung

  • Modèle : NVME-QQQQQ-987

  • Taille : 256 Go

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

Exemple 13.6 : Configuration complexe (et peu probable) #

 

Dans la configuration suivante, nous essayons de définir :

• 20 HDD soutenus par 1 NVMe

• 2 HDD soutenus par 1 SSD (db) et 1 NVMe (wal)

• 8 SSD soutenus par 1 NVMe

• 2 SSD autonomes (chiffrés)

• 1 HDD est de rechange et ne doit pas être déployé

Le résumé des unités utilisées est le suivant :

• 23 HDD

  • Fournisseur : Intel

  • Modèle : SSD-123-foo

  • Taille : 4 To

• 10 SSD

  • Fournisseur : Micron

  • Modèle : MC-55-44-ZX

  • Taille : 512 Go

• 1 NVMe

  • Fournisseur : Samsung

  • Modèle : NVME-QQQQQ-987

  • Taille : 256 Go

La définition des groupes d'unités sera la suivante :

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

Il reste un HDD dans la mesure où le fichier est en cours d'analyse du haut vers le bas.