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

5 Déploiement avec cephadm

 

SUSE Enterprise Storage 7 utilise l'outil ceph-salt basé sur Salt pour préparer le système d'exploitation sur chaque noeud de la grappe participant en vue d'un déploiement via cephadm. cephadm déploie et gère une grappe Ceph en se connectant aux hôtes à partir du daemon Ceph Manager via SSH. cephadm gère le cycle de vie complet d'une grappe Ceph. Il commence par démarrer une petite grappe sur un seul noeud (un service MON et un service MGR), puis utilise l'interface d'orchestration pour étendre la grappe afin d'inclure tous les hôtes et de provisionner tous les services Ceph. Vous pouvez effectuer cette opération via l'interface de ligne de commande Ceph (CLI) ou partiellement via Ceph Dashboard (GUI).

Important
Important

Notez que la documentation de la communauté Ceph utilise la commande de démarrage cephadm bootstrap lors du déploiement initial. ceph-salt appelle la commande cephadm bootstrap et ne doit pas être exécuté directement. Tout déploiement manuel de grappes Ceph à l'aide de l'outil de cephdm bootstrap ne sera pas pris en charge.

Pour déployer une grappe Ceph à l'aide de cephadm, procédez comme suit :

  1. Installez et effectuez la configuration de base du système d'exploitation sous-jacent (SUSE Linux Enterprise Server 15 SP2) sur tous les noeuds de la grappe.

  2. Déployez l'infrastructure Salt sur tous les noeuds de la grappe pour préparer le déploiement initial via ceph-salt.

  3. Configurez les propriétés de base de la grappe via ceph-salt et déployez-la.

  4. Ajoutez de nouveaux noeuds et rôles à la grappe et déployez des services sur ces derniers à l'aide de cephadm.

5.1 Installation et configuration de SUSE Linux Enterprise Server

 

  1. Installez et enregistrez SUSE Linux Enterprise Server 15 SP2 sur chaque noeud de la grappe. Lors de l'installation de SUSE Enterprise Storage, vous devrez pouvoir accéder aux dépôts de mise à jour. L'enregistrement est donc obligatoire. Incluez au moins les modules suivants :

    • Module Basesystem (Système de base)

    • Module Server Applications (Applications serveur)

    Pour plus de détails sur l'installation de SUSE Linux Enterprise Server, reportez-vous à la documentation https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.html.

  2. Installez l'extension SUSE Enterprise Storage 7 sur chaque noeud de la grappe.

    Astuce
    Astuce : installez SUSE Enterprise Storage en même temps que SUSE Linux Enterprise Server

    Vous pouvez installer l'extension SUSE Enterprise Storage 7 séparément après avoir installé SUSE Linux Enterprise Server 15 SP2 ou l'ajouter au cours de la procédure d'installation de SUSE Linux Enterprise Server 15 SP2.

    Pour plus de détails sur l'installation des extensions, reportez-vous à la documentation https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.html.

  3. Configurez les paramètres réseau, y compris la résolution de nom DNS appropriée sur chaque noeud. Pour plus d'informations sur la configuration d'un réseau, reportez-vous à l'adresse https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yast. Pour plus d'informations sur la configuration d'un serveur DNS, reportez-vous à l'adresse https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.html.

5.2 Déploiement de Salt

 

SUSE Enterprise Storage utilise Salt et ceph-salt pour la préparation initiale de la grappe. Salt vous aide à configurer et à exécuter des commandes sur plusieurs noeuds de grappe simultanément à partir d'un hôte dédié appelé Salt Master. Avant de déployer Salt, tenez compte des points importants suivants :

  • Les minions Salt sont les noeuds contrôlés par un noeud dédié appelé Salt Master.

  • Si l'hôte Salt Master doit faire partie de la grappe Ceph, il doit exécuter son propre minion Salt, mais ce n'est pas obligatoire.

    Astuce
    Astuce : partage de plusieurs rôles par serveur

    Vous obtiendrez les meilleures performances de votre grappe Ceph lorsque chaque rôle est déployé sur un noeud distinct. Toutefois, les déploiements réels nécessitent parfois le partage d'un noeud entre plusieurs rôles. Pour éviter les problèmes liés aux performances et à la procédure de mise à niveau, ne déployez pas le rôle Ceph OSD, Serveur de métadonnées ou Ceph Monitor sur le noeud Admin.

  • Les minions Salt doivent résoudre correctement le nom d'hôte de Salt Master sur le réseau. Par défaut, ils recherchent le nom d'hôte salt, mais vous pouvez spécifier tout autre nom d'hôte accessible par le réseau dans le fichier /etc/salt/minion.

  1. Installez salt-master sur le noeud Salt Master : 

    root@master # zypper in salt-master

  2. Vérifiez si le service salt-master est activé et démarré, puis activez-le et démarrez-le, le cas échéant : 

    root@master # systemctl enable salt-master.service
root@master # systemctl start salt-master.service

  3. Si vous envisagez d'utiliser le pare-feu, vérifiez si les ports 4505 et 4506 du noeud Salt Master sont ouverts pour tous les noeuds minions Salt. Si les ports sont fermés, vous pouvez les ouvrir à l'aide de la commande yast2 firewall en autorisant le service salt-master à accéder à la zone appropriée. Par exemple, public.

  4. Installez le paquetage salt-minion sur tous les noeuds des minions. 

    root@minion > zypper in salt-minion

  5. Modifiez /etc/salt/minion et supprimez les commentaires de la ligne suivante : 

    #log_level_logfile: warning

    Remplacez le niveau de consignation warning par info.

    Note
    Note : log_level_logfile et log_level

    Tandis que log_level contrôle quels messages du journal seront affichés à l'écran, log_level_logfile contrôle quels messages du journal seront écrits dans /var/log/salt/minion.

    Note
    Note

    Veillez à modifier le niveau de consignation sur tous les noeuds de grappe (minion).

  6. Assurez-vous que le nom de domaine complet de chaque noeud peut être résolu sur une adresse IP du réseau de grappes public par tous les autres noeuds.

  7. Configurez tous les minions pour qu'ils se connectent au maître. Si le nom d'hôte salt ne parvient pas à joindre votre Salt Master, modifiez le fichier /etc/salt/minion ou créez un fichier /etc/salt/minion.d/master.conf avec le contenu suivant : 

    master: host_name_of_salt_master

    Si vous avez apporté des modifications aux fichiers de configuration mentionnés ci-dessus, redémarrez le service Salt sur tous les minions Salt qui y sont associés : 

    root@minion > systemctl restart salt-minion.service

  8. Vérifiez que le service salt-minion est activé et démarré sur tous les noeuds. Activez et démarrez-le, le cas échéant : 

    root # systemctl enable salt-minion.service
root # systemctl start salt-minion.service

  9. Vérifiez l'empreinte digitale de chaque minion Salt et acceptez toutes les clés Salt sur Salt Master si les empreintes digitales correspondent.

    Note
    Note

    Si l'empreinte de minion Salt revient vide, vérifiez que le minion Salt a une configuration Salt Master et qu'il peut communiquer avec Salt Master.

    Affichez l'empreinte digitale de chaque minion : 

    root@minion > salt-call --local key.finger
local:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Après avoir collecté les empreintes digitales de tous les minions Salt, répertoriez les empreintes de toutes les clés de minions non acceptées sur Salt Master : 

    root@master # salt-key -F
[...]
Unaccepted Keys:
minion1:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Si les empreintes des minions correspondent, acceptez-les : 

    root@master # salt-key --accept-all

  10. Vérifiez que les clés ont été acceptées : 

    root@master # salt-key --list-all

  11. Testez si tous les minions Salt répondent : 

    root@master # salt-run manage.status

5.3 Déploiement de la grappe Ceph

 

Cette section vous guide tout au long du processus de déploiement d'une grappe Ceph de base. Lisez attentivement les sous-sections suivantes et exécutez les commandes incluses dans l'ordre indiqué.

5.3.1 Installation de ceph-salt

 

ceph-salt fournit des outils pour le déploiement de grappes Ceph gérées par cephdm. ceph-salt utilise l'infrastructure Salt pour gérer le système d'exploitation (par exemple, les mises à jour logicielles ou la synchronisation horaire) et définir les rôles pour les minions Salt.

Sur Salt Master, installez le paquetage ceph-salt  : 

root@master # zypper install ceph-salt

La commande ci-dessus a installé ceph-salt-formula en tant que dépendance qui a modifié la configuration de Salt Master en insérant des fichiers supplémentaires dans le répertoire /etc/salt/master.d. Pour appliquer les modifications, redémarrez salt-master.service et synchronisez les modules Salt : 

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

5.3.2 Configuration des propriétés de grappe

 

Utilisez la commande ceph-salt config pour configurer les propriétés de base de la grappe.

Important
Important

Le fichier /etc/ceph/ceph.conf est géré par cephadm et les utilisateurs ne doivent pas le modifier. Les paramètres de configuration Ceph doivent être définis à l'aide de la nouvelle commande ceph config. Pour plus d'informations, reportez-vous au Section 28.2, « Base de données de configuration ».

5.3.2.1 Utilisation du shell ceph-salt

 

Si vous exécutez ceph-salt config sans chemin ni sous-commande, vous accédez à un shell ceph-salt interactif. Le shell est pratique si vous devez configurer plusieurs propriétés dans un seul lot sans devoir saisir la syntaxe complète de la commande. 

root@master # ceph-salt config
/> ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [no minions]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [no minions]
  |   o- bootstrap ........................................... [no minion]
  |   o- cephadm ............................................ [no minions]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .................................. [ no image path]
  | o- dashboard ................................................... [...]
  | | o- force_password_update ................................. [enabled]
  | | o- password ................................................ [admin]
  | | o- ssl_certificate ....................................... [not set]
  | | o- ssl_certificate_key ................................... [not set]
  | | o- username ................................................ [admin]
  | o- mon_ip .................................................. [not set]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh ............................................... [no key pair set]
  | o- private_key .................................. [no private key set]
  | o- public_key .................................... [no public key set]
  o- time_server ........................... [enabled, no server host set]
    o- external_servers .......................................... [empty]
    o- servers ................................................... [empty]
    o- subnet .................................................. [not set]

Comme vous pouvez le constater dans la sortie de la commande ls de ceph-salt, la configuration de la grappe est organisée en arborescence. Pour configurer une propriété spécifique de la grappe dans le shell ceph-salt, deux options s'offrent à vous :

  • Exécutez la commande à partir de la position actuelle et entrez le chemin absolu de la propriété comme premier argument : 

    /> /cephadm_bootstrap/dashboard ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username .................................................... [admin]
/> /cephadm_bootstrap/dashboard/username set ceph-admin
Value set.

  • Accédez au chemin dont vous devez configurer la propriété et exécutez la commande : 

    /> cd /cephadm_bootstrap/dashboard/
/ceph_cluster/minions> ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username ................................................[ceph-admin]
Astuce
Astuce : saisie semi-automatique des extraits de configuration

Lorsque vous êtes dans un shell ceph-salt, vous pouvez utiliser la fonction de saisie semi-automatique similaire à celle d'un shell Linux normal (bash). Il complète les chemins de configuration, les sous-commandes ou les noms des minions Salt. Lors de la saisie semi-automatique d'un chemin de configuration, deux options s'offrent à vous :

  • Pour laisser le shell terminer un chemin par rapport à votre position actuelle, appuyez deux fois sur la touche TAB.→|

  • Pour laisser le shell terminer un chemin absolu, entrez / et appuyez deux fois sur la touche TAB →|.

Astuce
Astuce : navigation avec les flèches du clavier

Si vous entrez cd à partir du shell ceph-salt sans aucun chemin, la commande imprime une structure d'arborescence de la configuration de grappe avec la ligne du chemin actuellement actif. Vous pouvez utiliser les flèches Haut et Bas pour parcourir les différentes lignes. Après avoir confirmé avec la touche Entrée, le chemin de configuration est remplacé par le dernier chemin actif.

Important
Important : convention

Pour assurer la cohérence de la documentation, nous utiliserons une syntaxe de commande unique sans accéder au shell ceph-salt. Par exemple, vous pouvez répertorier l'arborescence de configuration de la grappe à l'aide de la commande suivante : 

root@master # ceph-salt config ls

5.3.2.2 Ajout de minions Salt

 

Incluez tout ou partie des minions Salt que vous avez déployés et acceptés à la Section 5.2, « Déploiement de Salt » dans la configuration de la grappe Ceph. Vous pouvez spécifier les minions Salt à l'aide de leur nom complet ou utiliser une expression globale « * » et « ? » pour inclure plusieurs minions Salt simultanément. Utilisez la sous-commande add sous le chemin /ceph_cluster/minions. La commande suivante inclut tous les minions Salt acceptés : 

root@master # ceph-salt config /ceph_cluster/minions add '*'

Vérifiez que les minions Salt spécifiés ont été ajoutés : 

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
  o- ses-master.example.com .................................. [no roles]
  o- ses-min1.example.com .................................... [no roles]
  o- ses-min2.example.com .................................... [no roles]
  o- ses-min3.example.com .................................... [no roles]
  o- ses-min4.example.com .................................... [no roles]

5.3.2.3 Spécification des minions Salt gérés par cephadm

 

Spécifiez les noeuds qui appartiendront à la grappe Ceph et qui seront gérés par cephadm. Incluez tous les noeuds qui exécuteront les services Ceph ainsi que le noeud Admin : 

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

5.3.2.4 Spécification du noeud Admin

 

Le noeud Admin est le noeud sur lequel le fichier de configuration ceph.conf et le trousseau de clés Ceph admin sont installés. les commandes liées à Ceph sont généralement exécutées sur le noeud Admin.

Astuce
Astuce : noeud Admin et Salt Master sur le même noeud

Dans un environnement homogène dans lequel tous les hôtes ou la plupart d'entre eux appartiennent à SUSE Enterprise Storage, il est recommandé de placer le noeud Admin sur le même hôte que Salt Master.

Dans un environnement hétérogène dans lequel une infrastructure Salt héberge plusieurs grappes, par exemple SUSE Enterprise Storage avec SUSE Manager, ne placez pas le noeud Admin sur le même hôte que Salt Master.

Pour spécifier le noeud Admin, exécutez la commande suivante : 

root@master # ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/admin ls
o- admin ................................................... [Minions: 1]
  o- ses-master.example.com ...................... [Other roles: cephadm]
Astuce
Astuce : installation de ceph.conf et du trousseau de clés admin sur plusieurs noeuds

Vous pouvez installer le fichier de configuration Ceph et le trousseau de clés admin sur plusieurs noeuds si votre déploiement l'exige. Pour des raisons de sécurité, évitez de les installer sur tous les noeuds de la grappe.

5.3.2.5 Spécification du premier noeud MON/MGR

 

Vous devez spécifier quel minion Salt de la grappe va démarrer la grappe. Ce minion sera alors le premier à exécuter les services Ceph Monitor et Ceph Manager. 

root@master # ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com
Value set.
root@master # ceph-salt config /ceph_cluster/roles/bootstrap ls
o- bootstrap ..................................... [ses-min1.example.com]

En outre, vous devez spécifier l'adresse IP de démarrage du service MON sur le réseau public pour vous assurer que le paramètre public_network est correctement défini, par exemple : 

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

5.3.2.6 Spécification de profils ajustés

 

Vous devez spécifier quels minions de la grappe ont des profils activement ajustés. Pour ce faire, ajoutez ces rôles explicitement à l'aide des commandes suivantes :

Note
Note

Un minion ne peut pas cumuler les rôles de latency (latence) et throughput (débit). 

root@master # ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com
Adding ses-min1.example.com...
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com
Adding ses-min2.example.com...
1 minion added.

5.3.2.7 Génération d'une paire de clés SSH

 

cephadm utilise le protocole SSH pour communiquer avec les noeuds de la grappe. Un compte utilisateur nommé cephadm est automatiquement créé et utilisé pour la communication SSH.

Vous devez générer la partie privée et la partie publique de la paire de clés SSH : 

root@master # ceph-salt config /ssh generate
Key pair generated.
root@master # ceph-salt config /ssh ls
o- ssh .................................................. [Key Pair set]
  o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]

5.3.2.8 Configuration du serveur horaire

 

L'heure de tous les noeuds de la grappe doit être synchronisée avec une source horaire fiable. Plusieurs scénarios existent pour aborder la synchronisation horaire :

  • Si tous les noeuds de la grappe sont déjà configurés pour synchroniser leur heure à l'aide du service NTP de votre choix, désactivez complètement la gestion du serveur horaire : 

    root@master # ceph-salt config /time_server disable

  • Si votre site possède déjà une seule source horaire, spécifiez le nom d'hôte de la source horaire : 

     root@master # ceph-salt config /time_server/servers add time-server.example.com

  • Dans le cas contraire, ceph-salt a la possibilité de configurer l'un des minions Salt pour qu'il fasse office de serveur horaire pour le reste de la grappe. Il est parfois appelé « serveur horaire interne ». Dans ce scénario, ceph-salt configure le serveur horaire interne (qui doit être l'un des minions Salt) pour synchroniser son heure avec celle d'un serveur horaire externe, tel que pool.ntp.org et configure tous les autres minions pour obtenir leur heure à partir du serveur horaire interne. Pour ce faire, procédez comme suit : 

    root@master # ceph-salt config /time_server/servers add ses-master.example.com
root@master # ceph-salt config /time_server/external_servers add pool.ntp.org

    L'option /time_server/subnet spécifie le sous-réseau à partir duquel les clients NTP sont autorisés à accéder au serveur NTP. Elle est définie automatiquement lorsque vous spécifiez /time_server/servers. Si vous devez la modifier ou la spécifier manuellement, exécutez : 

    root@master # ceph-salt config /time_server/subnet set 10.20.6.0/24

Vérifiez les paramètres du serveur horaire : 

root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
  o- external_servers ............................................... [1]
  | o- pool.ntp.org ............................................... [...]
  o- servers ........................................................ [1]
  | o- ses-master.example.com ..................................... [...]
  o- subnet .............................................. [10.20.6.0/24]

Pour plus d'informations sur la configuration de la synchronisation horaire, reportez-vous à l'adresse https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yast.

5.3.2.9 Configuration des informations d'identification de connexion de Ceph Dashboard

 

Ceph Dashboard sera disponible après le déploiement de la grappe de base. Pour y accéder, vous devez définir un nom d'utilisateur et un mot de passe valides, par exemple : 

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD
Astuce
Astuce : mise à jour forcée du mot de passe

Par défaut, le premier utilisateur du tableau de bord est obligé de modifier son mot de passe lors de la première connexion au tableau de bord. Pour désactiver cette fonction, exécutez la commande suivante : 

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

5.3.2.10 Configuration du chemin d'accès aux images du conteneur

 

cephadm doit avoir connaissance d'un chemin URI valide vers les images du conteneur qui sera utilisé au cours de l'étape de déploiement. Vérifiez si le chemin par défaut a été défini : 

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

Si aucun chemin par défaut n'a été défini ou si votre déploiement nécessite un chemin spécifique, ajoutez-le comme suit : 

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph
Note
Note

Pour la pile de surveillance, d'autres images de conteneur sont nécessaires. Pour un déploiement à vide ou à partir d'un registre local, vous souhaiterez peut-être obtenir ces images à ce stade afin de préparer votre registre local comme il se doit.

Notez que ceph-salt n'utilisera pas ces images de conteneur pour effectuer le déploiement. Il s'agit de préparatifs en vue d'une étape ultérieure lors de laquelle cephadm sera utilisé pour le déploiement ou la migration des composants de surveillance.

Pour plus d'informations sur les images utilisées par la pile de surveillance et sur la façon de les personnaliser, consultez la page Section 16.1, « Configuration d'images personnalisées ou locales ».

5.3.2.11 Configuration du registre de conteneurs

 

Vous pouvez éventuellement définir un registre local de conteneurs. Il fera office de miroir pour le registre registration.suse.com. N'oubliez pas que vous devez resynchroniser le registre local chaque fois que de nouveaux conteneurs mis à jour sont disponibles à partir du site registration.suse.com.

La création d'un registre local est utile dans les scénarios suivants :

  • Vous disposez d'un grand nombre de noeuds de grappe et souhaitez réduire le temps de téléchargement et économiser de la bande passante en créant un miroir local des images de conteneur.

  • Votre grappe n'a pas accès au registre en ligne (déploiement à vide) et vous avez besoin d'un miroir local pour extraire les images de conteneur.

  • Si des problèmes de configuration ou de réseau empêchent votre grappe d'accéder aux registres distants par le biais d'un lien sécurisé, vous aurez alors besoin d'un registre local non chiffré.

Important
Important

Pour déployer des correctifs temporaires de programme (PTF) sur un système pris en charge, vous devez déployer un registre local de conteneurs.

Pour configurer une URL de registre local avec des informations d'identification d'accès, procédez comme suit :

  1. Configurez l'URL du registre local : 

    cephuser@adm > ceph-salt config /containers/registry_auth/registry set REGISTRY_URL

  2. Configurez le nom d'utilisateur et le mot de passe pour accéder au registre local : 

    cephuser@adm > ceph-salt config /containers/registry_auth/username set REGISTRY_USERNAME
    cephuser@adm > ceph-salt config /containers/registry_auth/password set REGISTRY_PASSWORD

  3. Exécutez ceph-salt apply pour mettre à jour Salt Pillar sur tous les minions.

Astuce
Astuce : cache de registre

Pour éviter de resynchroniser le registre local lorsque de nouveaux conteneurs mis à jour apparaissent, vous pouvez configurer un cache de registre.

Les méthodes de développement et de distribution des applications natives dans le cloud nécessitent un registre et une instance CI/CD (intégration/distribution continue) pour le développement et la production d'images de conteneur. Vous pouvez utiliser un registre privé dans cette instance.

5.3.2.12 Activation du chiffrement des données à la volée (msgr2)

 

Le protocole Messenger v2 (MSGR2) est le protocole on-wire de Ceph. Il offre un mode de sécurité qui chiffre toutes les données passant sur le réseau, l'encapsulation des charges utiles d'authentification et l'activation de l'intégration future de nouveaux modes d'authentification (tels que Kerberos).

Important
Important

msgr2 n'est actuellement pas pris en charge par les clients Ceph du kernel Linux, tels que le périphérique de bloc RADOS et CephFS.

Les daemons Ceph peuvent se lier à plusieurs ports, ce qui permet aux clients Ceph hérités et aux nouveaux clients compatibles v2 de se connecter à la même grappe. Par défaut, les instances MON se lient désormais au nouveau port 3300 assigné par l'IANA (CE4h ou 0xCE4) pour le nouveau protocole v2, tout en se liant également à l'ancien port par défaut 6789 pour le protocole v1 hérité.

Le protocole v2 (MSGR2) prend en charge deux modes de connexion :

crc mode

Authentification initiale forte lorsque la connexion est établie et contrôle d'intégrité CRC32C.

secure mode

Authentification initiale forte lorsque la connexion est établie et un chiffrement complet de tout le trafic post-authentification, y compris une vérification de l'intégrité cryptographique.

Pour la plupart des connexions, il existe des options qui contrôlent les modes utilisés :

ms_cluster_mode

Mode de connexion (ou modes autorisés) utilisé(s) pour la communication entre les daemons Ceph au sein de la grappe. Si plusieurs modes sont répertoriés, ceux s'affichant en haut de la liste sont les préférés.

ms_service_mode

Liste des modes que les clients sont autorisés à utiliser lors de la connexion à la grappe.

ms_client_mode

Liste des modes de connexion, par ordre de préférence, que les clients peuvent ou sont autorisés à utiliser lorsqu'ils communiquent avec une grappe Ceph.

Il existe un ensemble parallèle d'options qui s'appliquent spécifiquement aux moniteurs, ce qui permet aux administrateurs de définir d'autres exigences (généralement plus sécurisées) en matière de communication avec les moniteurs.

ms_mon_cluster_mode

Mode de connexion (ou modes autorisés) à utiliser entre les moniteurs.

ms_mon_service_mode

Liste des modes autorisés que les clients ou les autres daemons Ceph sont autorisés à utiliser lors de la connexion aux moniteurs.

ms_mon_client_mode

Liste des modes de connexion, par ordre de préférence, que les clients ou les daemons non-moniteurs peuvent utiliser pour se connecter à des moniteurs.

Pour activer le mode de chiffrement MSGR2 pendant le déploiement, vous devez ajouter certaines options de configuration à la configuration de ceph-salt avant d'exécuter ceph-salt apply.

Pour utiliser le mode secure, exécutez les commandes suivantes.

Ajoutez la section globale à ceph_conf dans l'outil de configuration ceph-salt : 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

Paramétrez les options suivantes : 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"
Note
Note

Vérifiez que secure se trouve devant crc.

Pour forcer le mode secure, exécutez les commandes suivantes : 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure
Astuce
Astuce : mise à jour des paramètres

Si vous souhaitez modifier l'un des paramètres ci-dessus, définissez les modifications à apporter à la configuration dans la zone de stockage de la configuration du moniteur. Pour ce faire, utilisez la commande ceph config set. 

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

Par exemple : 

root@master # ceph config set global ms_cluster_mode "secure crc"

Si vous souhaitez vérifier la valeur actuelle, y compris la valeur par défaut, exécutez la commande suivante : 

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

Par exemple, pour obtenir le mode ms_cluster_mode pour les OSD, exécutez : 

root@master # ceph config get osd ms_cluster_mode

5.3.2.13 Configuration du réseau de grappes

 

Éventuellement, si vous exécutez un réseau de grappe distinct, vous devrez peut-être définir l'adresse IP réseau de la grappe suivie de la partie masque de sous-réseau après la barre oblique, par exemple 192.168.10.22/24.

Exécutez les commandes suivantes pour activer cluster_network : 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR

5.3.2.14 Vérification de la configuration de la grappe

 

La configuration de grappe minimale est terminée. Inspectez-la pour voir si elle contient des d'erreurs flagrantes : 

root@master # ceph-salt config ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [Minions: 5]
  | | o- ses-master.example.com .................................. [admin]
  | | o- ses-min1.example.com ......................... [bootstrap, admin]
  | | o- ses-min2.example.com ................................. [no roles]
  | | o- ses-min3.example.com ................................. [no roles]
  | | o- ses-min4.example.com ................................. [no roles]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [Minions: 2]
  |   | o- ses-master.example.com ....................... [no other roles]
  |   | o- ses-min1.example.com ................. [other roles: bootstrap]
  |   o- bootstrap ................................ [ses-min1.example.com]
  |   o- cephadm ............................................ [Minions: 5]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path ............... [registry.suse.com/ses/7/ceph/ceph]
  | o- dashboard ................................................... [...]
  |   o- force_password_update ................................. [enabled]
  |   o- password ................................... [randomly generated]
  |   o- username ................................................ [admin]
  | o- mon_ip ............................................ [192.168.10.20]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh .................................................. [Key Pair set]
  | o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  | o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- time_server ............................................... [enabled]
    o- external_servers .............................................. [1]
    | o- 0.pt.pool.ntp.org ......................................... [...]
    o- servers ....................................................... [1]
    | o- ses-master.example.com .................................... [...]
    o- subnet ............................................. [10.20.6.0/24]
Astuce
Astuce : état de la configuration de la grappe

Vous pouvez vérifier si la configuration de la grappe est valide en exécutant la commande suivante : 

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

5.3.2.15 Exportation des configurations de grappe

 

Une fois que vous avez configuré la grappe de base et que sa configuration est valide, il est recommandé d'exporter sa configuration dans un fichier : 

root@master # ceph-salt export > cluster.json
Avertissement
Avertissement

La sortie de l'exportation ceph-salt export inclut la clé privée SSH. Si les implications au niveau de la sécurité vous inquiètent, n'exécutez pas cette commande sans prendre les précautions appropriées.

Si vous interrompez la configuration de la grappe et que vous devez rétablir un état de sauvegarde, exécutez : 

root@master # ceph-salt import cluster.json

5.3.3 Mise à jour des noeuds et de la grappe minimale de démarrage

 

Avant de déployer la grappe, mettez à jour tous les paquetages logiciels sur l'ensemble des noeuds : 

root@master # ceph-salt update

Si un noeud signale Reboot is needed (Redémarrage requis) au cours de la mise à jour, cela signifie que des paquetages de système d'exploitation importants, tels que le kernel, ont été mis à jour vers une version plus récente. Vous devrez alors redémarrer le noeud pour que les modifications soient prises en compte.

Pour redémarrer tous les noeuds requis, ajoutez l'option --reboot. 

root@master # ceph-salt update --reboot

Vous pouvez également les redémarrer dans le cadre d'une étape distincte : 

root@master # ceph-salt reboot
Important
Important

Salt Master n'est jamais redémarré par les commandes ceph-salt update --reboot ou ceph-salt reboot. Si Salt Master doit être redémarré, vous devez le redémarrer manuellement.

Une fois les noeuds mis à jour, démarrez la grappe minimale : 

root@master # ceph-salt apply
Note
Note

Une fois démarrée, la grappe dispose d'une instance de Ceph Monitor et d'une instance de Ceph Manager.

La commande ci-dessus ouvre une interface utilisateur interactive qui affiche la progression actuelle de chaque minion.

Déploiement d'une grappe minimale
Figure 5.1 : Déploiement d'une grappe minimale
 
Astuce
Astuce : mode non interactif

Si vous devez appliquer la configuration à partir d'un script, il existe également un mode de déploiement non interactif. Ce mode est aussi utile lors du déploiement de la grappe à partir d'une machine distante, car la mise à jour constante des informations de progression à l'écran sur le réseau risque de vous distraire : 

root@master # ceph-salt apply --non-interactive

5.3.4 Examen des dernières étapes

 

Une fois la commande ceph-salt apply exécutée, vous devez disposer d'une instance de Ceph Monitor et d'une instance de Ceph Manager. Vous devriez pouvoir exécuter la commande ceph status sur n'importe quel minion ayant reçu le rôle admin en tant que root ou sur l'utilisateur de cephadm à l'aide de sudo.

Pour les étapes suivantes, vous devrez utiliser cephadm pour déployer des instances Ceph Monitor ou Ceph Manager, des OSD, la pile de surveillance et des passerelles supplémentaires.

Avant de continuer, passez en revue les paramètres réseau de votre nouvelle grappe. À ce stade, le paramètre public_network a été renseigné en fonction de ce qui a été entré pour /cephadm_bootstrap/mon_ip dans la configuration ceph-salt. Toutefois, ce paramètre était uniquement appliqué à Ceph Monitor. Vous pouvez vérifier ce paramètre à l'aide de la commande suivante : 

root@master # ceph config get mon public_network

Il s'agit du paramètre minimal pour que Ceph puisse fonctionner, mais nous vous recommandons de définir le paramètre public_network sur global, ce qui signifie qu'il s'appliquera à tous les types de daemons Ceph, et pas uniquement aux instances MON : 

root@master # ceph config set global public_network "$(ceph config get mon public_network)"
Note
Note

Cette étape n'est pas obligatoire. Toutefois, si vous n'utilisez pas ce paramètre, les OSD Ceph et les autres daemons (à l'exception de Ceph Monitor) écouteront toutes les adresses.

Si vous souhaitez que vos OSD communiquent entre eux au moyen d'un réseau totalement distinct, exécutez la commande suivante : 

root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"

L'exécution de cette commande garantit que les OSD créés dans votre déploiement utiliseront le réseau de grappe prévu dès le début.

Si votre grappe est configurée pour contenir des noeuds denses (plus de 62 OSD par hôte), veillez à assigner suffisamment de ports aux OSD Ceph. La plage par défaut (6800-7300) n'autorise pas plus de 62 OSD par hôte. Pour une grappe contenant des noeuds denses, configurez le paramètre ms_bind_port_max sur une valeur appropriée. Chaque OSD consomme huit ports supplémentaires. Par exemple, si un hôte est configuré pour exécuter 96 OSD, 768 ports seront nécessaires. ms_bind_port_max doit au moins être défini sur 7568 en exécutant la commande suivante : 

root@master # ceph config set osd.* ms_bind_port_max 7568

Vous devrez ajuster vos paramètres de pare-feu en conséquence pour que cela fonctionne. Pour plus d'informations, reportez-vous au Section 13.7, « Firewall settings for Ceph ».

5.4 Déploiement de services et de passerelles

 

Après avoir déployé la grappe Ceph de base, déployez les services principaux sur d'autres noeuds de la grappe. Pour que les clients puissent accéder aux données de la grappe, déployez aussi des services supplémentaires.

Actuellement, nous prenons en charge le déploiement des services Ceph sur la ligne de commande à l'aide de l'orchestrateur Ceph (sous-commandes ceph orch).

5.4.1 Commande ceph orch

 

La commande de l'orchestrateur Ceph ceph orch, qui sert d'interface avec le module cephadm, se charge d'établir la liste les composants de la grappe et de déployer les services Ceph sur les nouveaux noeuds de la grappe.

5.4.1.1 Affichage de l'état de l'orchestrateur

 

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

cephuser@adm > ceph orch status

5.4.1.2 Liste des périphériques, services et daemons

 

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
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
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
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

5.4.2 Spécification de service et de placement

 

La méthode recommandée pour spécifier le déploiement des services Ceph consiste à créer un fichier au format YAML spécifiant les services que vous avez l'intention de déployer.

5.4.2.1 Création de spécifications de service

 

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 :

service_type

Type de service. Il peut s'agir d'un service Ceph (mon, mgr, mds, crash, osd ou rbd-mirror), d'une passerelle (nfs ou rgw) ou d'une partie de la pile de surveillance (alertmanager, grafana, node-exporter ou prometheus).

service_id

Nom du service. Les spécifications de type mon, mgr, alertmanager, grafana, node-exporter et prometheus ne nécessitent pas la propriété service_id.

placement

Spécifie les noeuds qui exécuteront le service. Reportez-vous à la Section 5.4.2.2, « Création d'une spécification de placement » pour plus de détails.

spec

Spécification supplémentaire pertinente pour le type de service.

Astuce
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 5.4.3, « Déploiement des services Ceph ».

5.4.2.2 Création d'une spécification de placement

 

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
[...]

5.4.2.3 Application de la spécification de grappe

 

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 5.4.1.1, « Affichage de l'état de l'orchestrateur ».

5.4.2.4 Exportation de la spécification d'une grappe en cours d'exécution

 

Bien que vous ayez déployé des services sur la grappe Ceph à l'aide des fichiers de spécifications comme décrit à la Section 5.4.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
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

5.4.3 Déploiement des services Ceph

 

Une fois la grappe de base en cours d'exécution, vous pouvez déployer des services Ceph sur d'autres noeuds.

5.4.3.1 Déploiement d'instances de Monitor et Ceph Manager

 

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
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 5.3.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
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
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
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

5.4.3.2 Déploiement des OSD Ceph

 
Important
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 :

  • Indiquez à Ceph de consommer tous les périphériques de stockage disponibles et inutilisés : 

    cephuser@adm > ceph orch apply osd --all-available-devices

  • Utilisez DriveGroups (reportez-vous au Section 13.4.3, « Ajout d'OSD à l'aide de la spécification DriveGroups ») pour créer une spécification OSD décrivant les périphériques qui seront déployés sur la base de leurs propriétés, telles que le type de périphérique (SSD ou HDD), les noms de modèle de périphérique, la taille ou les noeuds sur lesquels les périphériques existent. Appliquez ensuite la spécification en exécutant la commande suivante : 

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

5.4.3.3 Déploiement de serveurs de métadonnées

 

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
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

5.4.3.4 Déploiement d'instances Object Gateway

 

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
5.4.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
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
5.4.3.4.2 Déploiement avec une sous-grappe
 

Les sous-grappes vous aident à organiser les noeuds de vos grappes afin d'isoler les workloads et de gagner en flexibilité. Si vous effectuez un déploiement avec une sous-grappe, appliquez la configuration suivante : 

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

5.4.3.5 Déploiement de passerelles iSCSI

 

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
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
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.

5.4.3.5.1 Configuration SSL sécurisée
 

Pour utiliser une connexion SSL sécurisée entre Ceph Dashboard et l'API cible iSCSI, vous avez besoin d'une paire de fichiers de clés et de certificats SSL valides. Ceux-ci peuvent être émis par une autorité de certification ou auto-signés (reportez-vous au Section 10.1.1, « Création de certificats auto-signés »). Pour activer SSL, ajoutez le paramètre api_secure: true à votre fichier de spécifications : 

spec:
  api_secure: true

Pour spécifier le certificat et la clé SSL, vous pouvez coller le 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:
  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-----

5.4.3.6 Déploiement de NFS Ganesha

 

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
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

  • EXEMPLE_NFS avec une chaîne arbitraire qui identifie l'exportation NFS.

  • EXEMPLE_RÉSERVE avec le nom de la réserve dans laquelle l'objet de configuration NFS Ganesha RADOS sera stocké.

  • EXEMPLE_ESPACE_DE_NOM (facultatif) avec l'espace de nom NFS Object Gateway souhaité (par exemple, ganesha).

5.4.3.7 Déploiement de rbd-mirror

 

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

5.4.3.8 Déploiement de la pile de surveillance

 

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
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 :

  1. Activez le module prometheus dans le daemon Ceph Manager. Cela permet de rendre visibles les mesures Ceph internes afin que Prometheus puisse les lire : 

    cephuser@adm > ceph mgr module enable prometheus
    Note
    Note

    Assurez-vous que cette commande est exécutée avant le déploiement de Prometheus. Si la commande n'a pas été exécutée avant le déploiement, vous devez redéployer Prometheus pour mettre à jour la configuration de Prometheus : 

    cephuser@adm > ceph orch redeploy prometheus

  2. Créez un fichier de spécifications (par exemple, monitoring.yaml) dont le contenu ressemble à ce qui suit : 

    service_type: prometheus
placement:
  hosts:
  - ses-min2
---
service_type: node-exporter
---
service_type: alertmanager
placement:
  hosts:
  - ses-min4
---
service_type: grafana
placement:
  hosts:
  - ses-min3

  3. Appliquez les services de surveillance en exécutant : 

    cephuser@adm > ceph orch apply -i monitoring.yaml

    Le déploiement des services de surveillance peut prendre une à deux minutes.

Important
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 ».