8 Déploiement des services essentiels restants à l'aide de cephadm #

La commande suivante affiche le mode et l'état actuels de l'orchestrateur Ceph.

cephuser@adm > ceph orch status

Pour obtenir la liste de tous les périphériques de disque, exécutez la commande suivante :

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]

Astuce : services et daemons

Service est un terme général désignant un service Ceph d'un type spécifique, par exemple Ceph Manager.

Daemon est une instance spécifique d'un service, par exemple un processus mgr.ses-min1.gdlcik exécuté sur un noeud appelé ses-min1.

Pour obtenir la liste de tous les services connus de cephadm, exécutez :

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd

Astuce

Vous pouvez limiter la liste aux services d'un noeud en particulier avec le paramètre facultatif ‑‑host et aux services d'un type particulier avec le paramètre facultatif ‑‑service-type. Les types acceptables sont mon, osd, mgr, mds et rgw.

Pour obtenir la liste de tous les daemons en cours d'exécution déployés par cephadm, exécutez :

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369

Astuce

Pour interroger l'état d'un daemon en particulier, utilisez --daemon_type et --daemon_id. Pour les OSD, l'ID est l'ID numérique de l'OSD. Pour MDS, l'ID est le nom du système de fichiers :

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

Vous pouvez créer un fichier de spécifications distinct pour chaque type de service, par exemple :

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Vous pouvez également spécifier plusieurs (ou tous les) types de service dans un fichier (par exemple, cluster.yml) pour décrire les noeuds qui exécuteront des services spécifiques. N'oubliez pas de séparer les différents types de services par trois tirets (---) :

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

Les propriétés susmentionnées ont la signification suivante :

Astuce : application de services spécifiques

Les services de grappe Ceph ont généralement un certain nombre de propriétés intrinsèques. Pour obtenir des exemples et des détails sur la spécification des différents services, reportez-vous à la Section 8.3, « Déploiement des services Ceph ».

Pour déployer les services Ceph, cephadm doit savoir sur quels noeuds les déployer. Utilisez la propriété placement et répertoriez les noms d'hôte courts des noeuds auxquels le service s'applique :

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

Après avoir créé un fichier cluster.yml complet avec les spécifications de tous les services et leur placement, vous pouvez appliquer la grappe en exécutant la commande suivante :

cephuser@adm > ceph orch apply -i cluster.yml

Pour afficher l'état de la grappe, exécutez la commande ceph orch status. Pour plus de détails, reportez-vous à la Section 8.1.1, « Affichage de l'état de l'orchestrateur ».

Bien que vous ayez déployé des services sur la grappe Ceph à l'aide des fichiers de spécifications comme décrit à la Section 8.2, « Spécification de service et de placement », la configuration de la grappe peut être différente de la spécification d'origine lors de son fonctionnement. Il se peut également que vous ayez accidentellement supprimé les fichiers de spécifications.

Pour récupérer une spécification complète d'une grappe en cours d'exécution, exécutez :

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]

Astuce

Vous pouvez ajouter l'option --format pour modifier le format de sortie yaml par défaut. Vous pouvez choisir entre json, json-attractive ou yaml. Par exemple :

ceph orch ls --export --format json

La grappe Ceph comporte trois ou cinq instances MON déployées sur différents noeuds. Si la grappe contient au moins cinq noeuds, il est recommandé de déployer cinq instances MON. Une bonne pratique consiste à déployer les instances MGR sur les mêmes noeuds que les instances MON.

Important : inclusion de l'instance MON de démarrage

Lorsque vous déployez des instances MON et MGR, n'oubliez pas d'inclure la première instance MON que vous avez ajoutée lors de la configuration de la grappe de base à la Section 7.2.5, « Spécification du premier noeud MON/MGR ».

Pour déployer des instances MON, appliquez la spécification suivante :

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Note

Si vous devez ajouter un autre noeud, ajoutez le nom d'hôte à la même liste YAML. Par exemple :

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

De la même manière, pour déployer des instances MGR, appliquez la spécification suivante :

Important

Assurez-vous que votre déploiement contient au moins trois instances Ceph Manager dans chaque déploiement.

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Astuce

Si les instances MON ou MGR ne se trouvent pas dans le même sous-réseau, vous devez ajouter les adresses de sous-réseau. Par exemple :

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

Important : lorsque le périphérique de stockage est disponible

Un périphérique de stockage est considéré comme disponible si toutes les conditions suivantes sont remplies :

• Le périphérique n'a pas de partitions.

• Le périphérique n'a pas d'état LVM.

• Le périphérique n'est pas monté.

• Le périphérique ne contient pas de système de fichiers.

• Le périphérique ne contient pas d'OSD BlueStore.

• La taille du périphérique est supérieure à 5 Go.

Si les conditions ci-dessus ne sont pas remplies, Ceph refuse de provisionner ces OSD.

Deux méthodes permettent de déployer des OSD :

CephFS nécessite un ou plusieurs services de serveur de métadonnées (MDS). Pour créer un CephFS, commencez par créer des serveurs MDS en appliquant la spécification suivante :

Note

Assurez-vous d'avoir créé au moins deux réserves, l'une pour les données CephFS et l'autre pour les métadonnées CephFS, avant d'appliquer la spécification suivante.

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Une fois que les MDS sont fonctionnels, créez le CephFS :

ceph fs new CEPHFS_NAME metadata_pool data_pool

cephadm déploie Object Gateway en tant qu'ensemble de daemons qui gèrent un domaine et une zone spécifique.

Vous pouvez soit associer un service Object Gateway à une zone et un domaine préexistants (reportez-vous au Section 21.13, « Passerelles Object Gateway multisites » pour plus de détails) ou vous pouvez spécifier des noms NOM_DOMAINE et NOM_ZONE n'existant pas encore. Ils seront créés automatiquement après avoir appliqué la configuration suivante :

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE

8.3.4.1 Utilisation d'un accès SSL sécurisé #

 

Pour utiliser une connexion SSL sécurisée à l'instance Object Gateway, vous avez besoin d'une paire de certificats SSL et de fichiers de clé valides (reportez-vous au Section 21.7, « Activation de HTTPS/SSL pour les passerelles Object Gateway » pour plus de détails). Vous devez activer SSL, spécifier un numéro de port pour les connexions SSL, ainsi que le certificat SSL et les fichiers de clé.

Pour activer SSL et spécifier le numéro de port, incluez les éléments suivants dans votre spécification :

spec:
  ssl: true
  rgw_frontend_port: 443

Pour spécifier le certificat et la clé SSL, vous pouvez coller leur contenu directement dans le fichier de spécifications YAML. Le signe de barre verticale (|) à la fin de la ligne indique à l'analyseur de s'attendre à une valeur contenant une chaîne s'étendant sur plusieurs lignes. Par exemple :

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----

Astuce

Au lieu de coller le contenu du certificat SSL et des fichiers de clé, vous pouvez omettre les mots-clés rgw_frontend_ssl_certificate: et rgw_frontend_ssl_key: et les télécharger dans la base de données de configuration :

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE

8.3.4.1.1 Configuration de la passerelle Object Gateway pour une écoute sur les ports 443 et 80 #

 

Pour configurer la passerelle Object Gateway afin qu'elle écoute sur les ports 443 (HTTPS) et 80 (HTTP), procédez comme suit :

Note

Les commandes de la procédure utilisent le domaine et la zone default.

1. Déployez la passerelle Object Gateway en fournissant un fichier de spécifications. Reportez-vous à la Section 8.3.4, « Déploiement d'instances Object Gateway » pour plus de détails sur la spécification Object Gateway. Utilisez la commande suivante :

   cephuser@adm > ceph orch apply -i SPEC_FILE

2. Si les certificats SSL ne sont pas fournis dans le fichier de spécifications, ajoutez-les à l'aide de la commande suivante :

   cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. Modifiez la valeur par défaut de l'option rgw_frontends :

   cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
    "beast port=80 ssl_port=443"

4. Supprimez la configuration spécifique créée par cephadm. Identifiez la cible pour laquelle l'option rgw_frontends a été configurée en exécutant la commande :

   cephuser@adm > ceph config dump | grep rgw

   Par exemple, la cible est client.rgw.default.default.node4.yiewdu. Supprimez la valeur rgw_frontends spécifique actuelle :

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   Astuce

   Au lieu de supprimer une valeur pour rgw_frontends, vous pouvez la spécifier. Par exemple :

   cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
    rgw_frontends "beast port=80 ssl_port=443"

5. Redémarrez les passerelles Object Gateway :

   cephuser@adm > ceph orch restart rgw.default.default

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

cephadm déploie une passerelle iSCSI, à savoir un protocole SAN (Storage area network) qui permet aux clients (appelés initiateurs) d'envoyer des commandes SCSI aux périphériques de stockage SCSI (cibles) sur des serveurs distants.

Appliquez la configuration suivante pour effectuer le déploiement. Assurez-vous que la liste trusted_ip_list contient les adresses IP de tous les noeuds de passerelle iSCSI et Ceph Manager (comme dans l'exemple de sortie ci-dessous).

Note

Vérifiez que la réserve a été créée avant d'appliquer la spécification suivante.

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"

Note

Assurez-vous que les adresses IP répertoriées pour trusted_ip_list ne contiennent pas d'espace après la séparation par une virgule.

spec:
  api_secure: true

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

Important

NFS Ganesha prend en charge les versions 4.1 et ultérieures de NFS. Il ne prend pas en charge la version 3 de NFS.

cephadm déploie NFS Ganesha à l'aide d'une réserve RADOS prédéfinie et d'un espace de nom facultatif. Pour déployer NFS Ganesha, appliquez la spécification suivante :

Note

Vous devez disposer d'une réserve RADOS prédéfinie, sinon l'opération ceph orch apply échouera. Pour plus d'informations sur la création d'une, reportez-vous au Section 18.1, « Création d'une réserve ».

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Le service rbd-mirror prend en charge la synchronisation des images de périphériques de bloc RADOS entre deux grappes Ceph (pour plus de détails, reportez-vous au Section 20.4, « Miroirs d'image RBD »). Pour déployer rbd-mirror, utilisez la spécification suivante :

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

La pile de surveillance se compose de Prometheus, d'exportateurs Prometheus, de Prometheus Alertmanager et de Grafana. Ceph Dashboard utilise ces composants pour stocker et visualiser des mesures détaillées concernant l'utilisation et les performances de la grappe.

Astuce

Si votre déploiement nécessite des images de conteneur personnalisées ou mises à disposition localement pour les services de pile de surveillance, reportez-vous au Section 16.1, « Configuration d'images personnalisées ou locales ».

Pour déployer la pile de surveillance, procédez comme suit :

Important

Prometheus, Grafana et Ceph Dashboard sont tous automatiquement configurés pour pouvoir communiquer entre eux, ce qui permet une intégration Grafana entièrement fonctionnelle dans Ceph Dashboard lorsque le déploiement a été effectué comme décrit ci-dessus.

La seule exception à cette règle est la surveillance avec des images RBD. Pour plus d'informations, reportez-vous au Section 16.5.4, « Activation de la surveillance des images RBD ».