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 être colocalisés avec des daemons 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-SP2/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-SP2/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.

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

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

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 Book “Guide d'opérations et d'administration”, Chapter 28 “Configuration de la grappe Ceph”, 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 : 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

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

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]

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

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]

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

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.

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]

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]

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

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 Book “Guide d'opérations et d'administration”, Chapter 16 “Surveillance et alertes”, 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

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

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

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

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

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

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

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

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.

Figure 5.1 : Déploiement d'une grappe minimale #

 

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

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

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 Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

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.

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

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

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

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

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

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

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

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

5.4.3.2 Déploiement des OSD Ceph #

 

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 Book “Guide d'opérations et d'administration”, Chapter 13 “Tâches opérationnelles”, 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

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

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

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

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.

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 Book “Guide d'opérations et d'administration”, Chapter 10 “Configuration manuelle”, 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

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

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

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

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 :

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

   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

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

La cible iSCSI du kernel Linux s'appelait à l'origine LIO pour linux-iscsi.org, le domaine et le site Web d'origine du projet. Pendant un certain temps, pas moins de quatre implémentations de cibles iSCSI concurrentes étaient disponibles pour la plate-forme Linux, mais LIO a finalement prévalu en tant que cible de référence iSCSI unique. Le code du kernel principal de LIO utilise le nom simple, mais quelque peu ambigu « target », en faisant la distinction entre « target core » et une variété de modules cibles d'interface client et d'interface dorsale.

Le module d'interface client le plus couramment utilisé est sans doute iSCSI. Toutefois, LIO prend également en charge Fibre Channel (FC), Fibre Channel sur Ethernet (FCoE) et plusieurs autres protocoles d'interface client. Pour l'instant, seul le protocole iSCSI est pris en charge par SUSE Enterprise Storage.

Le module d'interface dorsale cible le plus fréquemment utilisé est celui qui est capable de réexporter simplement n'importe quel périphérique de bloc disponible sur l'hôte cible. Ce module est nommé iblock. Cependant, LIO dispose également d'un module d'interface dorsale spécifique à RBD prenant en charge l'accès E/S multipath parallélisé aux images RBD.

Cette section présente des informations succinctes sur les initiateurs iSCSI utilisés sur les plates-formes Linux, Microsoft Windows et VMware.

Le déploiement de la passerelle iSCSI Ceph suit la même procédure que le déploiement d'autres services Ceph, à l'aide de cephdm. Pour plus de détails, reportez-vous à la Section 5.4.3.5, « Déploiement de passerelles iSCSI ».

Les images RBD sont créées dans la zone de stockage Ceph et ensuite exportées vers iSCSI. Il est recommandé d'utiliser une réserve RADOS dédiée à cette fin. Vous pouvez créer un volume à partir de n'importe quel hôte pouvant se connecter à votre grappe de stockage à l'aide de l'utilitaire de ligne de commande Ceph rbd. Pour cela, le client doit avoir au moins un fichier de configuration ceph.conf minimal et des informations d'identification d'authentification CephX appropriées.

Pour créer un volume pour l'exportation ultérieure via iSCSI, utilisez la commande rbd create en spécifiant la taille du volume en mégaoctets. Par exemple, pour créer un volume de 100 Go nommé testvol dans la réserve intitulée iscsi-images, exécutez la commande suivante :

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

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 :

root # cephadm enter --name CONTAINER_NAME

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

root # 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 6.4.4, « Authentification et contrôle d'accès » pour plus d'informations sur l'authentification et le contrôle d'accès.

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

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

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

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

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

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

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.

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

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

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

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

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 la mise à niveau vers SUSE Enterprise Storage 7. Pour savoir comment sauvegarder toutes vos données, consultez https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.

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 :

root # zypper refresh && zypper patch

Une fois les mises à jour appliquées, vérifiez l'état de santé de la grappe :

cephuser@adm > ceph -s

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

Dans SUSE Enterprise Storage 7, 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 à proprement parler 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 5.4.3.4, « Déploiement d'instances Object Gateway » et appliquez-le.

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

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 copier les objets de configuration d'exportation et de 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, un 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.