Le composant de base de Ceph est appelé RADOS (Reliable Autonomic Distributed Object Store) (Zone de stockage des objets distribués autonome fiable). Il est chargé de gérer les données stockées dans la grappe. Les données de Ceph sont généralement stockées en tant qu'objets. Chaque objet se compose d'un identificateur et des données.

RADOS fournit les méthodes d'accès suivantes aux objets stockés qui couvrent de nombreux cas d'utilisation :

librados est utilisé par Object Gateway et les RBD alors que CephFS s'interface directement avec RADOS (Figure 1.1, « Interfaces avec la zone de stockage des objets Ceph »).

Figure 1.1 : Interfaces avec la zone de stockage des objets Ceph #

 

Au coeur d'une grappe Ceph se trouve l'algorithme CRUSH. CRUSH est l'acronyme de Controlled Replication Under Scalable Hashing (Réplication contrôlée sous hachage évolutif). CRUSH est une fonction qui gère l'allocation de stockage et nécessite relativement peu de paramètres. Cela signifie que seule une petite quantité d'informations est nécessaire pour calculer la position de stockage d'un objet. Les paramètres sont une carte actuelle de la grappe, comprenant l'état de santé, certaines règles de placement définies par l'administrateur et le nom de l'objet qui doit être stocké ou récupéré. Avec ces informations, tous les noeuds de la grappe Ceph sont en mesure de calculer l'emplacement auquel un objet et ses répliques sont stockés. Cela rend l'écriture ou la lecture des données très efficace. CRUSH tente de distribuer équitablement les données sur tous les noeuds de la grappe.

La carte CRUSH contient tous les noeuds de stockage et les règles de placement définies par l'administrateur pour le stockage des objets dans la grappe. Elle définit une structure hiérarchique qui correspond généralement à la structure physique de la grappe. Par exemple, les disques contenant des données sont dans des hôtes, les hôtes sont dans des racks, les racks dans des rangées et les rangées dans des centres de données. Cette structure peut être utilisée pour définir des domaines de défaillance. Ceph s'assure ensuite que les réplications sont stockées sur différentes branches d'un domaine de défaillance spécifique.

Si le domaine de défaillance est défini sur le niveau rack, les réplications d'objets sont réparties sur différents racks. Cela peut limiter les interruptions de service provoquées par un commutateur défaillant sur un rack. Si une unité de distribution de l'alimentation dessert une rangée de racks, le domaine de défaillance peut être défini sur rangée. En cas de défaillance de l'unité de distribution de l'alimentation, les données répliquées sont toujours disponibles sur les autres rangées.

Dans Ceph, les noeuds sont des serveurs fonctionnant pour la grappe. Ils peuvent exécuter divers types de daemons. Nous recommandons de n'exécuter qu'un seul type de daemon sur chaque noeud, à l'exception des daemons Ceph Manager qui peuvent se trouver au même emplacement que ceux de Ceph Monitor. Chaque grappe nécessite au moins des daemons Ceph Monitor, Ceph Manager, et Ceph OSD :

Pour utiliser CephFS, Object Gateway, NFS Ganesha ou la passerelle iSCSI, des noeuds supplémentaires sont requis :

Les objets qui sont stockés dans une grappe Ceph sont placés dans des réserves. Les réserves représentent les partitions logiques de la grappe vers le monde extérieur. Pour chaque réserve, un ensemble de règles peut être défini, par exemple, combien de réplications de chaque objet doivent exister. La configuration standard des réserves est appelée réserve répliquée.

Les réserves contiennent généralement des objets, mais peuvent également être configurées pour agir de la même manière qu'un RAID 5. Dans cette configuration, les objets sont stockés sous forme de tranches avec d'autres tranches de codage. Les tranches de codage contiennent les informations redondantes. Le nombre de données et les tranches de codage peuvent être définis par l'administrateur. Dans cette configuration, les réserves sont appelées réserves codées à effacement ou réserves EC.

Les groupes de placement (PG) sont utilisés pour la distribution des données au sein d'une réserve. Lorsque vous créez une réserve, un certain nombre de groupes de placement sont définis. Les groupes de placement sont utilisés en interne pour grouper des objets et sont un facteur important en termes de performances d'une grappe Ceph. Le groupe de placement d'un objet est déterminé par le nom de l'objet.

Cette section fournit un exemple simplifié de la façon dont Ceph gère les données (reportez-vous à la Figure 1.2, « Exemple de Ceph à petite échelle »). Cet exemple ne représente pas une configuration recommandée pour une grappe Ceph. La configuration matérielle comprend trois noeuds de stockage ou noeuds Ceph OSD (Hôte 1, Hôte 2, Hôte 3). Chaque noeud comporte trois disques durs qui sont utilisés comme OSD (osd.1 à osd.9). Les noeuds Ceph Monitor sont ignorés dans cet exemple.

Note : différence entre Ceph OSD et OSD

Alors que Ceph OSD ou daemon Ceph OSD fait référence à un daemon exécuté sur un noeud, le terme OSD fait référence au disque logique avec lequel le daemon interagit.

La grappe comporte deux réserves, Réserve A et Réserve B. Alors que Réserve A ne réplique les objets que deux fois, la résilience pour Réserve B est plus importante et comporte trois réplications pour chaque objet.

Lorsqu'une application place un objet dans une réserve, par exemple via l'API REST, un groupe de placement (PG1 à PG4) est sélectionné en fonction de la réserve et du nom de l'objet. L'algorithme CRUSH calcule ensuite les OSD sur lesquels l'objet est stocké, en fonction du groupe de placement qui contient l'objet.

Dans cet exemple, le domaine de défaillance est défini sur le niveau hôte. Cela garantit que les réplications d'objets sont stockées sur des hôtes différents. En fonction du niveau de réplication défini pour une réserve, l'objet est stocké sur deux ou trois OSD utilisés par le groupe de placement.

Une application qui écrit un objet interagit uniquement avec un Ceph OSD, le Ceph OSD primaire. Le Ceph OSD primaire se charge de la réplication et confirme l'achèvement du processus d'écriture une fois que tous les autres OSD ont stocké l'objet.

Si osd.5 échoue, tous les objets du PG1 sont toujours disponibles sur osd.1. Dès que la grappe identifie un échec d'OSD, un autre OSD prend le relais. Dans cet exemple osd.4 est utilisé en remplacement d'osd.5. Les objets stockés sur osd.1 sont ensuite répliqués sur osd.4 pour restaurer le niveau de la réplication.

Figure 1.2 : Exemple de Ceph à petite échelle #

 

Si un nouveau noeud avec de nouveaux OSD est ajouté à la grappe, la carte de la grappe va changer. La fonction CRUSH renvoie alors des emplacements différents pour les objets. Les objets qui reçoivent de nouveaux emplacements seront déplacés. Ce processus aboutit à une utilisation équilibrée de tous les OSD.

Nous vous recommandons d'utiliser un seul réseau tolérant aux pannes avec une bande passante suffisante pour répondre à vos besoins. Pour l'environnement de réseau public Ceph, nous recommandons deux interfaces réseau 25 GbE (ou plus rapides) liées à l'aide de 802.3ad (LACP). Cette recommandation est considérée comme la configuration minimale pour Ceph. Si vous utilisez également un réseau en grappe, nous recommandons quatre interfaces réseau 25 GbE liées. La liaison de deux ou plusieurs interfaces réseau offre un meilleur débit grâce à l'agrégation de liens et, compte tenu des liens et commutateurs redondants, une meilleure tolérance aux pannes et une meilleure maintenabilité.

Vous pouvez également créer des VLAN pour isoler différents types de trafic sur une liaison. Par exemple, vous pouvez créer une liaison pour fournir deux interfaces VLAN, l'une pour le réseau public et l'autre pour le réseau en grappe. Ce n'est toutefois pas nécessaire lors de la configuration du réseau Ceph. Vous trouverez des détails sur la liaison des interfaces sur le site https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding.

La tolérance aux pannes peut être améliorée en isolant les composants dans des domaines de défaillance. Pour améliorer la tolérance aux pannes du réseau, la liaison d'une interface à partir de deux cartes d'interface réseau (NIC) distinctes offre une protection contre la défaillance d'une seule carte réseau. De même, la création d'une liaison entre deux commutateurs protège contre la défaillance d'un commutateur. Nous vous recommandons de vous adresser au fournisseur de l'équipement réseau afin de définir le niveau de tolérance aux pannes requis.

Important : réseau d'administration non pris en charge

La configuration réseau d'administration supplémentaire (qui permet, par exemple, de séparer les réseaux SSH, Salt ou DNS) n'est ni testée ni prise en charge.

Astuce : noeuds configurés via DHCP

Si les noeuds de stockage sont configurés via DHCP, les timeouts par défaut peuvent ne pas être suffisants pour que le réseau soit configuré correctement avant le démarrage des différents daemons Ceph. Si cela se produit, les instances MON et OSD de Ceph ne démarreront pas correctement (l'exécution de systemctl status ceph\* entraînera des erreurs de type « unable to bind » [liaison impossible]). Pour éviter ce problème, nous vous recommandons d'augmenter le timeout du client DHCP sur au moins 30 secondes pour chaque noeud de votre grappe de stockage. Pour ce faire, vous pouvez modifier les paramètres suivants sur chaque noeud :

Dans /etc/sysconfig/network/dhcp, définissez

DHCLIENT_WAIT_AT_BOOT="30"

Dans /etc/sysconfig/network/config, définissez

WAIT_FOR_INTERFACES="60"

2.1.1.2 Noeuds de moniteur sur des sous-réseaux distincts #

 

Si les noeuds de moniteur se trouvent sur plusieurs sous-réseaux, par exemple s'ils se trouvent dans des pièces différentes et sont desservis par différents commutateurs, vous devez spécifier leur adresse de réseau public en notation CIDR :

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Par exemple :

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"

Avertissement

Si vous spécifiez plusieurs segments de réseau pour le réseau public (ou en grappe) comme décrit dans cette section, chacun de ces sous-réseaux doit pouvoir être routé vers tous les autres. Dans le cas contraire, les daemons MON et les autres daemons Ceph sur différents segments de réseau ne peuvent pas communiquer et il en résulte une grappe divisée. De plus, si vous utilisez un pare-feu, veillez à inclure chaque sous-réseau ou adresse IP dans vos iptables et ouvrez leur les ports nécessaires sur tous les noeuds.

Une configuration de grappe minimale pour le produit se compose des éléments suivants :

Une configuration détaillée est la suivante :

Figure 2.2 : Configuration minimale de la grappe #

 

Une fois votre grappe développée, nous vous recommandons de déplacer les instances Ceph Monitor, les serveurs de métadonnées et les passerelles vers des noeuds distincts afin d'améliorer la tolérance aux pannes.

Si vous souhaitez utiliser du matériel multipath, assurez-vous que LVM voit multipath_component_detection = 1 dans le fichier de configuration sous la section devices. Vous pouvez vérifier à l'aide de la commande lvm config.

Vous pouvez également vous assurer que LVM filtre les composants mpath d'un périphérique via la configuration du filtre LVM. Cela dépendra de l'hôte.

Note

Ce n'est pas recommandé et ne doit être envisagé que si multipath_component_detection = 1 ne peut pas être défini.

Pour plus d'informations sur la configuration multipath, consultez l'adresse https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

Deux types d'espace disque sont nécessaires pour l'exécution sur un OSD : l'espace pour le périphérique WAL/DB et l'espace primaire pour les données stockées. La valeur minimale (et par défaut) pour le périphérique WAL/DB est de 6 Go. L'espace minimum pour les données est de 5 Go, car les partitions inférieures à 5 Go sont automatiquement assignées à une pondération de 0.

Ainsi, bien que l'espace disque minimal pour un OSD soit de 11 Go, il est recommandé de ne pas utiliser un disque inférieur à 20 Go, même à des fins de test.

Les disques SSD n'ont pas de pièces mobiles. Cela réduit le temps d'accès aléatoire et la latence de lecture tout en accélérant le débit de données. Comme leur prix par Mo est significativement plus élevé que le prix des disques durs tournants, les disques SSD ne conviennent que pour un stockage plus petit.

Les OSD peuvent constater une amélioration significative de leurs performances en stockant leurs partitions sur un disque SSD et les données d'objet sur un disque dur distinct.

Astuce : partage d'un disque SSD pour plusieurs partitions WAL/DB

Étant donné que les partitions WAL/DB occupent relativement peu d'espace, vous pouvez partager un disque SSD avec plusieurs partitions WAL/DB. N'oubliez pas qu'avec chaque partition WAL/DB, les performances du disque SSD se dégradent. Il est déconseillé de partager plus de six partitions WAL/DB sur le même disque SSD et 12 sur des disques NVMe.

Vous pouvez avoir autant de disques sur un serveur que ce dernier l'autorise. Il existe quelques aspects à considérer lorsque vous planifiez le nombre de disques par serveur :

SUSE Manager et SUSE Enterprise Storage n'étant pas intégrés, SUSE Manager ne peut actuellement pas gérer une grappe SES.

Si vous exécutez config sans chemin ni sous-commande, vous accédez à un shell ceph-saltceph-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 ceph-saltls de , 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 :

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

Incluez tout ou partie des minions Salt que vous avez déployés et acceptés au Chapitre 6, 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]

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

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

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

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

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.

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]

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 :

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-SP3/html/SLES-all/cha-ntp.html#sec-ntp-yast.

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

La grappe Ceph doit avoir accès à un registre de conteneurs afin de pouvoir télécharger et déployer des services Ceph conteneurisés. Il existe deux façons d'accéder au registre :

7.2.10.1 Création et configuration du registre local (facultatif) #

 

Important

Il existe de nombreuses méthodes pour créer un registre local. Les instructions de cette section proposent des exemples de création de registres sécurisés et non sécurisés. Pour obtenir des informations générales sur l'exécution d'un registre d'images de conteneur, consultez le site https://documentation.suse.com/sles/15-SP3/single-html/SLES-container/#sec-docker-registry-installation.

Astuce : placement et utilisation des ports

Déployez le registre sur une machine accessible par tous les noeuds de la grappe. Nous recommandons le noeud Admin. Par défaut, le registre écoute sur le port 5000.

Dans le noeud de registre, utilisez la commande suivante pour vérifier que le port est libre :

ss -tulpn | grep :5000

Si d'autres processus (tels que iscsi-tcmu) écoutent déjà sur le port 5000, définissez un autre port libre qui peut être utilisé pour l'assignation au port 5000 dans le conteneur de registres.

Procédure 7.1 : Création du registre local #

 

1. Vérifiez que l'extension Containers Module est activée :

   > SUSEConnect --list-extensions | grep -A2 "Containers Module"
   Containers Module 15 SP3 x86_64 (Activated)

2. Vérifiez que les paquetages suivants sont installés : apache2-utils (en cas d'activation d'un registre sécurisé), cni, cni-plugins, podman, podman-cni-config et skopeo.

3. Réunissez les informations suivantes :

   • Nom de domaine complet de l'hôte de registre (REG_HOST_FQDN).

   • Numéro de port disponible utilisé pour l'assignation du port 5000 au conteneur de registres (REG_HOST_PORT)

   • Si le registre doit être sécurisé ou non (insecure=[true|false]).

4. Pour démarrer un registre non sécurisé (sans chiffrement SSL), procédez comme suit :

   1. Configurez ceph-salt pour le registre non sécurisé :

      cephuser@adm > ceph-salt config containers/registries_conf enable
      cephuser@adm > ceph-salt config containers/registries_conf/registries \
       add prefix=REG_HOST_FQDN insecure=true \
       location=REG_HOST_PORT:5000

   2. Démarrez le registre non sécurisé en créant le répertoire nécessaire (par exemple, /var/lib/registry) et en démarrant le registre avec la commande podman :

      # mkdir -p /var/lib/registry
      # podman run --privileged -d --name registry \
       -p REG_HOST_PORT:5000 -v /var/lib/registry:/var/lib/registry \
       --restart=always registry:2

   3. Pour que le registre se lance après un redémarrage, créez un fichier d'unité systemd et activez-le :

      > sudo podman generate systemd --files --name registry
      > sudo mv container-registry.service /etc/systemd/system/
      > sudo systemctl enable container-registry.service

5. Pour démarrer un registre sécurisé, procédez comme suit :

   1. Créez les répertoires nécessaires :

      # mkdir -p /var/lib/registry/{auth,certs}

   2. Générez un certificat SSL :

      # openssl req -newkey rsa:4096 -nodes -sha256 \
       -keyout /var/lib/registry/certs/domain.key -x509 -days 365 \
       -out /var/lib/registry/certs/domain.crt

      

      Note

      Définissez la valeur CN=[valeur] sur le nom de domaine complet de l'hôte ([FQDN_HÔTE_REG]).

   3. Copiez le certificat sur tous les noeuds de la grappe et rafraîchissez le cache du certificat :

      # salt-cp '*' /var/lib/registry/certs/domain.crt \
       /etc/pki/trust/anchors/
      # salt '*' cmd.shell "update-ca-certificates"

   4. Générez une combinaison de nom d'utilisateur et de mot de passe pour l'authentification auprès du registre :

      # htpasswd2 -bBc /var/lib/registry/auth/htpasswd \
       REG_USERNAME REG_PASSWORD

   5. Démarrez le registre sécurisé. Utilisez le drapeau REGISTRY_STORAGE_DELETE_ENABLED=true pour pouvoir supprimer les images par la suite à l'aide de la commande skopeo delete.

      podman run --name myregistry -p REG_HOST_PORT:5000 \
       -v /var/lib/registry:/var/lib/registry \
       -v /var/lib/registry/auth:/auth:z \
       -e "REGISTRY_AUTH=htpasswd" \
       -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
       -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
       -v /var/lib/registry/certs:/certs:z \
       -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
       -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
       -e REGISTRY_STORAGE_DELETE_ENABLED=true \
       -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true -d registry:2

   6. Testez l'accès sécurisé au registre :

      > curl https://REG_HOST_FQDN:REG_HOST_PORT/v2/_catalog \
       -u REG_USERNAME:REG_PASSWORD

6. Lorsque le registre local a été créé, vous devez synchroniser les images de conteneur du registre SUSE officiel sur le site registration.suse.com avec le registre local. Vous pouvez utiliser la commande skopeo sync trouvée dans le paquetage skopeo à cette fin. Pour plus de détails, reportez-vous à la page de manuel (man 1 skopeo-sync). Prenez en considération les exemples suivants :

   Exemple 7.1 : affichage des fichiers de manifeste #

    

   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/ceph | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/grafana | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 | jq .RepoTags

   Exemple 7.2 : synchronisation avec un répertoire #

    

   Synchronisez toutes les images Ceph :

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph /root/images/

   Synchronisez les dernières images uniquement :

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph:latest /root/images/

   Exemple 7.3 : synchronisation des images Grafana : #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana /root/images/

   Synchronisez uniquement les dernières images Grafana :

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana:latest /root/images/

   Exemple 7.4 : synchronisation des dernières images Prometheus #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 /root/images/

Procédure 7.2 : configuration du registre local et des informations d'identification d'accès #

 

1. Configurez l'URL du registre local :

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REG_HOST_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 REG_USERNAME

   cephuser@adm > ceph-salt config /containers/registry_auth/password set REG_PASSWORD

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.

7.2.10.2 Configuration du chemin d'accès aux images du conteneur #

 

Important

Cette section vous aide à configurer le chemin d'accès aux images de conteneur de la grappe Bootstrap (déploiement de la première paire Ceph Monitor et Ceph Manager). Le chemin d'accès ne s'applique pas aux images de conteneur de services supplémentaires, par exemple, la pile de surveillance.

Astuce : configuration du proxy HTTPS

Si vous devez utiliser un proxy pour communiquer avec le serveur de registre de conteneur, effectuez les étapes de configuration suivantes sur tous les noeuds de grappe :

1. Copiez le fichier de configuration des conteneurs :

   > sudo cp /usr/share/containers/containers.conf /etc/containers/containers.conf

2. Modifiez le fichier que vous venez de copier et ajoutez le paramètre http_proxy à sa section [moteur], par exemple :

   > cat /etc/containers/containers.conf
    [engine]
    http_proxy=proxy.example.com
    [...]

cephadm doit connaître un chemin URI valide vers les images de conteneur. Vérifiez le paramètre par défaut en exécutant

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

Si vous n'avez pas besoin d'un autre registre ou d'un registre local, spécifiez le registre de conteneurs SUSE par défaut :

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

Si votre déploiement nécessite un chemin d'accès spécifique, par exemple, un chemin d'accès à un registre local, configurez-le comme suit :

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set LOCAL_REGISTRY_PATH

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

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 :

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

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.

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

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

É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

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.1/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 : é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

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

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

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 Book “Guide d'opérations et d'administration”, Chapter 21 “Ceph Object Gateway”, 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 Book “Guide d'opérations et d'administration”, Chapter 21 “Ceph Object Gateway”, 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 Book “Guide d'opérations et d'administration”, Chapter 18 “Gestion des réserves de stockage”, 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 Book “Guide d'opérations et d'administration”, Chapter 20 “Périphérique de bloc RADOS”, 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 Book “Guide d'opérations et d'administration”, Chapter 16 “Surveillance et alertes”, 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 Book “Guide d'opérations et d'administration”, Chapter 16 “Surveillance et alertes”, Section 16.5.4 “Activation de la surveillance des images RBD”.

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

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

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

Figure 9.1 : grappe Ceph avec une passerelle iSCSI unique #

 

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

Figure 9.2 : Grappe Ceph avec plusieurs passerelles iSCSI #

 

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

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

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

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

9.1.4.3 Exportation d'images RBD via iSCSI #

 

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

Note

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

• images avec la fonction journaling activée

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

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

# cephadm enter --name CONTAINER_NAME

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

# gwcli

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

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

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

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

Astuce

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

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

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

Assignez l'image RBD à la cible :

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

Note

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

Astuce

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

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

9.1.4.4 Authentification et contrôle d'accès #

 

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

9.1.4.4.1 Désactivation de l'authentification ACL #

 

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

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

9.1.4.4.2 Utilisation de l'authentification ACL #

 

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

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

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

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

9.1.4.4.3 Activation de l'authentification CHAP #

 

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

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

Note

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

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

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

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

 

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

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

Note

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

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

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

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

gwcli >  /iscsi-targets> discovery_auth nochap

9.1.4.5 Configuration des paramètres avancés #

 

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

Avertissement

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

9.1.4.5.1 Affichage des paramètres cibles #

 

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

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

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

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

Les paramètres target disponibles sont les suivants :

default_cmdsn_depth

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

default_erl

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

login_timeout

Valeur de timeout de connexion en secondes.

netif_timeout

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

prod_mode_write_protect

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

9.1.4.5.2 Affichage des paramètres du disque #

 

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

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

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

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

Les paramètres disk disponibles sont les suivants :

block_size

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

emulate_3pc

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

emulate_caw

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

emulate_dpo

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

emulate_fua_read

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

emulate_fua_write

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

emulate_model_alias

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

emulate_pr

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

Astuce

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

emulate_rest_reord

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

emulate_tas

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

emulate_tpu

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

emulate_tpws

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

emulate_ua_intlck_ctrl

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

emulate_write_cache

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

enforce_pr_isids

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

is_nonrot

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

max_unmap_block_desc_count

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

max_unmap_lba_count:

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

max_write_same_len

Longueur maximale pour WRITE_SAME (Écriture identique).

optimal_sectors

Taille de la requête optimale dans les secteurs.

pi_prot_type

Type de protection DIF.

queue_depth

Profondeur de la file d'attente.

unmap_granularity

Granularité UNMAP (Annuler l'assignation).

unmap_granularity_alignment

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

force_pr_aptpl

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

unmap_zeroes_data

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

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

Avertissement : avant-première technologique

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

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

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

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

Note

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

Avant la mise à niveau, veillez à lire les sections suivantes pour vous assurer que vous comprenez toutes les tâches à exécuter.

Nous vous recommandons vivement de sauvegarder l'ensemble de la configuration et des données de la grappe avant de commencer votre mise à niveau vers SUSE Enterprise Storage 7.1. Pour savoir comment sauvegarder toutes vos données, consultez le site https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

Si vous avez au préalable effectué une mise à niveau à partir de la version 5, vérifiez que la mise à niveau vers la version 6 a bien abouti :

Vérifiez l'existence du fichier /srv/salt/ceph/configuration/files/ceph.conf.import.

Ce fichier est créé par le processus engulf lors de la mise à niveau de SUSE Enterprise Storage 5 vers la version 6. L'option configuration_init: default-import est définie dans le répertoire /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Si l'option configuration_init reste définie sur default-import, la grappe utilise ceph.conf.import comme fichier de configuration, au lieu du fichier ceph.conf par défaut de DeepSea, qui est compilé à partir des fichiers dans le répertoire /srv/salt/ceph/configuration/files/ceph.conf.d/.

Par conséquent, vous devez rechercher les configurations personnalisées potentielles dans ceph.conf.import et, éventuellement, les déplacer dans l'un des fichiers du répertoire /srv/salt/ceph/configuration/files/ceph.conf.d/.

Supprimez ensuite la ligne configuration_init: default-import du répertoire /srv/pilleur/ceph/proposals/config/stack/default/ceph/cluster.yml.

Vérifiez que les dernières mises à jour de SUSE Linux Enterprise Server 15 SP1 et SUSE Enterprise Storage 6 sont toutes appliquées à tous les noeuds de la grappe :

# zypper refresh && zypper patch

Astuce

Reportez-vous au site https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates pour obtenir des informations détaillées sur la mise à jour des noeuds de grappe.

Une fois les mises à jour appliquées, redémarrez Salt Master, synchronisez les nouveaux modules Salt et vérifiez l'état de santé de la grappe :

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

Vérifiez que chaque noeud de la grappe a accès aux dépôts logiciels SUSE Linux Enterprise Server 15 SP3 et SUSE Enterprise Storage 7.1, ainsi qu'au registre des images de conteneur.

Dans SUSE Enterprise Storage 7.1, les passerelles Object Gateway sont toujours configurées avec un domaine, ce qui permet une utilisation sur plusieurs sites (voir Book “Guide d'opérations et d'administration”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “Passerelles Object Gateway multisites” pour plus de détails) à l'avenir. Si vous avez utilisé une configuration Object Gateway monosite dans SUSE Enterprise Storage 6, procédez comme suit pour ajouter un domaine. Si vous ne prévoyez pas d'utiliser la fonctionnalité multisite, vous pouvez utiliser la valeur par défaut pour les noms de domaine, de groupe de zones et de zone.

Pour conteneuriser le service Object Gateway, créez son fichier de spécification comme décrit à la Section 8.3.4, « Déploiement d'instances Object Gateway » et appliquez-le.

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

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.

Les paragraphes qui suivent expliquent comment migrer un service NFS Ganesha existant qui exécute Ceph Nautilus vers un conteneur NFS Ganesha qui exécute Ceph Octopus.

Avertissement

La documentation suivante implique que vous ayez déjà mis à niveau les services Ceph principaux.

NFS Ganesha stocke la configuration par daemon supplémentaire et l'exporte dans une réserve RADOS. La réserve RADOS configurée se trouve sur la ligne watch_url du bloc RADOS_URLS dans le fichier ganesha.conf. Par défaut, cette réserve est nommée ganesha_config

Avant de tenter une migration, nous vous recommandons vivement de faire une copie des objets de configuration d'exportation et daemon situés dans la réserve RADOS. Pour localiser la réserve RADOS configurée, exécutez la commande suivante :

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Pour répertorier le contenu de la réserve RADOS :

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Pour copier les objets RADOS :

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Pour chaque noeud, tout service NFS Ganesha existant doit être arrêté, puis remplacé par un conteneur géré par cephadm.

Les exportations existantes peuvent être migrées de deux manières différentes :

Une fois le service migré, le service NFS Ganesha basé sur Nautilus peut être supprimé.

Contrairement aux instances MON, MGR et OSD, le serveur de métadonnées ne peut pas être adopté sur place. Vous devez le redéployer dans des conteneurs à l'aide de l'orchestrateur Ceph.

Pour mettre à niveau la passerelle iSCSI, vous devez la redéployer dans des conteneurs à l'aide de l'orchestrateur Ceph. Si vous disposez de plusieurs passerelles iSCSI, vous devez les redéployer une par une pour réduire le temps d'indisponibilité du service.

Avant la mise à niveau, veillez à lire les sections suivantes pour vous assurer que vous comprenez toutes les tâches à exécuter.

Nous vous recommandons vivement de sauvegarder l'ensemble de la configuration et des données de la grappe avant de commencer la mise à niveau. Pour savoir comment sauvegarder toutes vos données, reportez-vous au Book “Guide d'opérations et d'administration”, Chapter 15 “Sauvegarde et restauration”.

Vérifiez que chaque noeud de la grappe a accès aux dépôts logiciels SUSE Linux Enterprise Server 15 SP3 et SUSE Enterprise Storage 7.1, ainsi qu'au registre des images de conteneur.