Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Enterprise Storage 7 / Guide d'opérations et d'administration / Opération de grappe / Tâches opérationnelles
S'applique à SUSE Enterprise Storage 7

13 Tâches opérationnelles

13.1 Modification de la configuration d'une grappe

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

  1. Exportez la configuration actuelle de la grappe dans un fichier :

    cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
  2. Modifiez le fichier de configuration et mettez à jour les lignes appropriées. Vous trouverez des exemples de spécification dans le Section 5.4, « Déploiement de services et de passerelles » et à la Section 13.4.3, « Ajout d'OSD à l'aide de la spécification DriveGroups ».

  3. Appliquez la nouvelle configuration :

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

13.2 Ajout de noeuds

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

  1. Installez SUSE Linux Enterprise Server et SUSE Enterprise Storage sur le nouvel hôte. Reportez-vous au Section 5.1, « Installation et configuration de SUSE Linux Enterprise Server » (Guide de sécurité, Chapitre 17 « Masquage et pare-feu ») pour plus d'informations.

  2. Configurez l'hôte en tant que minion Salt d'un Salt Master préexistant. Reportez-vous au Section 5.2, « Déploiement de Salt » (Guide de sécurité, Chapitre 17 « Masquage et pare-feu ») pour plus d'informations.

  3. Ajoutez le nouvel hôte à ceph-salt et informez-en cephadm, par exemple :

    root@master # ceph-salt config /ceph_cluster/minions add ses-min5.example.com
    root@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com

    Reportez-vous au Section 5.3.2.2, « Ajout de minions Salt » (Guide de sécurité, Chapitre 17 « Masquage et pare-feu ») pour plus d'informations.

  4. Vérifiez que le noeud a bien été ajouté à ceph-salt :

    root@master # ceph-salt config /ceph_cluster/minions ls
    o- minions ................................................. [Minions: 5]
    [...]
      o- ses-min5.example.com .................................... [no roles]
  5. Appliquez la configuration au nouvel hôte de la grappe :

    root@master # ceph-salt apply ses-min5.example.com
  6. Vérifiez que l'hôte qui vient d'être ajouté appartient désormais à l'environnement cephadm :

    cephuser@adm > ceph orch host ls
    HOST                   ADDR                    LABELS   STATUS
    [...]
    ses-min5.example.com   ses-min5.example.com

13.3 Suppression de noeuds

Astuce
Astuce : suppression des OSD

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

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

  1. Pour tous les types de service Ceph, à l'exception de node-exporter et crash, supprimez le nom d'hôte du noeud du fichier de spécification de placement de la grappe (par exemple, cluster.yml). Pour plus d'informations, reportez-vous au Section 5.4.2, « Spécification de service et de placement ». Par exemple, si vous souhaitez supprimer l'hôte nommé ses-min2, supprimez toutes les occurrences de - ses-min2 de toutes les sections placement: :

    Remplacez

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min2
      - ses-min3

    par

    service_type: rgw
    service_id: EXAMPLE_NFS
    placement:
      hosts:
      - ses-min3

    Appliquez vos modifications au fichier de configuration :

    cephuser@adm > ceph orch apply -i rgw-example.yaml
  2. Supprimez le noeud de l'environnement de cephadm :

    cephuser@adm > ceph orch host rm ses-min2
  3. Si le noeud exécute les services crash.osd.1 et crash.osd.2, supprimez-les en exécutant la commande suivante sur l'hôte :

    root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME

    Par exemple :

    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
  4. Supprimez tous les rôles du minion à supprimer :

    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2

    Si le minion que vous souhaitez supprimer est le minion Bootstrap, vous devez également supprimer le rôle Bootstrap :

    cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset
  5. Après avoir supprimé tous les OSD sur un hôte unique, supprimez ce dernier de la carte CRUSH :

    cephuser@adm > ceph osd crush remove bucket-name
    Note
    Note

    Le nom du compartiment doit être identique au nom d'hôte.

  6. Vous pouvez à présent supprimer le minion de la grappe :

    cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2
Important
Important

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

root@master # salt-key -d minion_id

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

13.4 Gestion des OSD

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

13.4.1 Liste des périphériques de disque

Pour identifier les périphériques de disque utilisés et inutilisés sur tous les noeuds de la grappe, listez-les en exécutant la commande suivante :

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

13.4.2 Effacement de périphériques de disque

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

ceph orch device zap HOST_NAME DISK_DEVICE

Par exemple :

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

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

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

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

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

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

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

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

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

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

13.4.3.1 OSD non gérés

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

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

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

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

13.4.3.2 Spécification DriveGroups

Voici un exemple de fichier de spécification DriveGroups :

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

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

13.4.3.3 Périphériques de disque correspondants

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

  • Par modèle de disque :

    model: DISK_MODEL_STRING
  • Par fournisseur de disque :

    vendor: DISK_VENDOR_STRING
    Astuce
    Astuce

    Saisissez toujours DISK_VENDOR_STRING en minuscules.

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

    cephuser@adm > ceph orch device ls
    HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
    ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
    ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
    [...]
  • Selon qu'un disque est rotatif ou non. Les disques SSD et NVMe ne sont pas rotatifs.

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

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

    limit: 10

13.4.3.4 Filtrage des périphériques par taille

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

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

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

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

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

Exemple 13.1 : Correspondance par taille de disque
service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'
Note
Note : guillemets requis

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

Astuce
Astuce : abréviations des unités

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

13.4.3.5 Exemples de DriveGroups

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

Exemple 13.2 : Configuration simple

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

  • 20 HDD

    • Fournisseur : Intel

    • Modèle : SSD-123-foo

    • Taille : 4 To

  • 2 SSD

    • Fournisseur : Micron

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

    • Taille : 512 Go

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

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

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

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

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

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'
Exemple 13.3 : Configuration avancée

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

  • 20 HDD

    • Fournisseur : Intel

    • Modèle : SSD-123-foo

    • Taille : 4 To

  • 12 SSD

    • Fournisseur : Micron

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

    • Taille : 512 Go

  • 2 NVMe

    • Fournisseur : Samsung

    • Modèle : NVME-QQQQQ-987

    • Taille : 256 Go

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB
Exemple 13.4 : Configuration avancée avec des noeuds non uniformes

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

Noeuds 1 à 5 :

  • 20 HDD

    • Fournisseur : Intel

    • Modèle : SSD-123-foo

    • Taille : 4 To

  • 2 SSD

    • Fournisseur : Micron

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

    • Taille : 512 Go

Noeuds 6 à 10 :

  • 5 NVMe

    • Fournisseur : Intel

    • Modèle : SSD-123-foo

    • Taille : 4 To

  • 20 SSD

    • Fournisseur : Micron

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

    • Taille : 512 Go

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

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

suivi de

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

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

  • 20 HDD

    • Fournisseur : Intel

    • Modèle : SSD-123-foo

    • Taille : 4 To

  • 2 SSD

    • Fournisseur : Micron

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

    • Taille : 512 Go

  • 2 NVMe

    • Fournisseur : Samsung

    • Modèle : NVME-QQQQQ-987

    • Taille : 256 Go

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987
Exemple 13.6 : Configuration complexe (et peu probable)

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

  • 20 HDD soutenus par 1 NVMe

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

  • 8 SSD soutenus par 1 NVMe

  • 2 SSD autonomes (chiffrés)

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

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

  • 23 HDD

    • Fournisseur : Intel

    • Modèle : SSD-123-foo

    • Taille : 4 To

  • 10 SSD

    • Fournisseur : Micron

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

    • Taille : 512 Go

  • 1 NVMe

    • Fournisseur : Samsung

    • Modèle : NVME-QQQQQ-987

    • Taille : 256 Go

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

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987
service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

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

13.4.4 Suppression des OSD

Avant de supprimer un noeud OSD de la grappe, vérifiez que cette dernière dispose de plus d'espace disque disponible que le disque OSD que vous allez supprimer. Gardez à l'esprit que la suppression d'un OSD entraîne un rééquilibrage de l'ensemble de la grappe.

  1. Identifiez l'OSD à supprimer en obtenant son ID :

    cephuser@adm > ceph orch ps --daemon_type osd
    NAME   HOST            STATUS        REFRESHED  AGE  VERSION
    osd.0  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.1  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.2  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
    osd.3  target-ses-090  running (3h)  7m ago     3h   15.2.7.689 ...
  2. Supprimez un ou plusieurs OSD de la grappe :

    cephuser@adm > ceph orch osd rm OSD1_ID OSD2_ID ...

    Par exemple :

    cephuser@adm > ceph orch osd rm 1 2
  3. Vous pouvez exécuter une requête pour connaître l'état de l'opération de suppression :

    cephuser@adm > ceph orch osd rm status
    OSD_ID  HOST         STATE                    PG_COUNT  REPLACE  FORCE  STARTED_AT
    2       cephadm-dev  done, waiting for purge  0         True     False  2020-07-17 13:01:43.147684
    3       cephadm-dev  draining                 17        False    True   2020-07-17 13:01:45.162158
    4       cephadm-dev  started                  42        False    True   2020-07-17 13:01:45.162158

13.4.4.1 Arrêt de la suppression d'un OSD

Après avoir planifié la suppression d'un OSD, vous pouvez interrompre l'opération si nécessaire. La commande suivante permet de rétablir l'état initial de l'OSD et de le supprimer de la file d'attente :

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

13.4.5 Remplacement d'OSD

Pour remplacer un OSD tout en conservant son ID, exécutez la commande suivante :

cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace

Par exemple :

cephuser@adm > ceph orch osd rm 4 --replace

Le remplacement d'un OSD est identique à la suppression d'un OSD (pour plus de détails, reportez-vous à la Section 13.4.4, « Suppression des OSD ») à la différence près que l'OSD n'est pas supprimé de façon permanente de la hiérarchie CRUSH et se voit assigner un indicateur destroyed (détruit).

L'indicateur destroyed (détruit) sert à déterminer les ID d'OSD qui seront réutilisés lors du prochain déploiement d'OSD. Les nouveaux disques ajoutés qui correspondent à la spécification DriveGroups (pour plus de détails, reportez-vous à la Section 13.4.3, « Ajout d'OSD à l'aide de la spécification DriveGroups ») se verront assigner les ID d'OSD de leur homologue remplacé.

Astuce
Astuce

L'ajout de l'option --dry-run ne permet pas d'exécuter le remplacement réel, mais d'afficher un aperçu des étapes qui se produiraient normalement.

13.5 Déplacement du Salt Master vers un nouveau noeud

Si vous devez remplacer l'hôte Salt Master par un autre, procédez comme suit :

  1. Exportez la configuration de la grappe et sauvegardez le fichier JSON exporté. Pour plus de détails, reportez-vous au Section 5.3.2.15, « Exportation des configurations de grappe ».

  2. Si l'ancien Salt Master est également le seul noeud d'administration de la grappe, déplacez manuellement les fichiers /etc/ceph/ceph.client.admin.keyring et /etc/ceph/ceph.conf vers le nouveau Salt Master.

  3. Arrêtez et désactivez le service systemd Salt Master sur l'ancien noeud Salt Master :

    root@master # systemctl stop salt-master.service
    root@master # systemctl disable salt-master.service
  4. Si l'ancien noeud Salt Master ne se trouve plus dans la grappe, arrêtez et désactivez également le service systemd du minion Salt :

    root@master # systemctl stop salt-minion.service
    root@master # systemctl disable salt-minion.service
    Avertissement
    Avertissement

    N'arrêtez ou ne désactivez pas salt-minion.service si des daemons Ceph (MON, MGR, OSD, MDS, passerelle, surveillance) s'exécutent sur l'ancien noeud Salt Master.

  5. Installez SUSE Linux Enterprise Server 15 SP2 sur le nouveau Salt Master en suivant la procédure décrite dans le Section 5.1, « Installation et configuration de SUSE Linux Enterprise Server ».

    Astuce
    Astuce : transition des minions Salt

    Pour simplifier la transition des minions Salt vers le nouveau Salt Master, retirez la clé publique Salt Master d'origine de chacun d'eux :

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  6. Installez le paquetage salt-master et, le cas échéant, le salt minion, sur le nouveau Salt Master.

  7. Installez ceph-salt sur le nouveau noeud Salt Master :

    root@master # zypper install ceph-salt
    root@master # systemctl restart salt-master.service
    root@master # salt '*' saltutil.sync_all
    Important
    Important

    Veillez à exécuter les trois commandes avant de continuer. Les commandes sont idempotentes ; peu importe si elles sont exécutées à plusieurs reprises.

  8. Incluez le nouveau Salt Master dans la grappe comme décrit dans les Section 5.3.1, « Installation de ceph-salt », Section 5.3.2.2, « Ajout de minions Salt » et Section 5.3.2.4, « Spécification du noeud Admin ».

  9. Importez la configuration de grappe sauvegardée et appliquez-la :

    root@master # ceph-salt import CLUSTER_CONFIG.json
    root@master # ceph-salt apply
    Important
    Important

    Renommez le minion id du Salt Master dans le fichier CLUSTER_CONFIG.json exporté avant de l'importer.

13.6 Mise à jour des noeuds de grappe

Gardez les noeuds de grappe Ceph à jour en appliquant régulièrement des mises à jour progressives.

13.6.1 Dépôts logiciels

Avant d'appliquer des correctifs à la grappe avec les paquetages les plus récents, vérifiez que tous les noeuds de la grappe ont accès aux dépôts pertinents. Pour obtenir la liste complète des dépôts requis, reportez-vous au Section 7.1.5.1, « Dépôts logiciels ».

13.6.2 Préparation du dépôt

Si vous utilisez un outil de préparation (SUSE Manager, Repository Management Tool ou RMT, par exemple) qui met à disposition des dépôts logiciels pour les noeuds de la grappe, vérifiez que les phases pour les dépôts de mise à jour de SUSE Linux Enterprise Server et de SUSE Enterprise Storage sont créées au même moment.

Il est vivement recommandé d'utiliser un outil de préparation pour appliquer des correctifs de niveau frozen ou staged. Cela garantit le même niveau de correctif aux noeuds qui rejoignent la grappe et à ceux qui y sont déjà en cours d'exécution. Vous évitez ainsi de devoir appliquer les correctifs les plus récents à tous les noeuds de la grappe avant que de nouveaux noeuds puissent la rejoindre.

13.6.3 Temps d'indisponibilité des services Ceph

Selon la configuration, les noeuds de grappe peuvent être redémarrés pendant la mise à jour. S'il existe un point d'échec unique pour des services tels qu'Object Gateway, Samba Gateway, NFS Ganesha ou iSCSI, les machines clientes peuvent être temporairement déconnectées des services dont les noeuds sont redémarrés.

13.6.4 Exécution de la mise à jour

Pour mettre à jour les paquetages logiciels sur tous les noeuds de grappe vers la dernière version, exécutez la commande suivante :

root@master # ceph-salt update

13.7 Mise à jour de Ceph

Vous pouvez demander à cephadm de mettre à jour Ceph d'une version de correctifs vers une autre. La mise à jour automatique des services Ceph respecte l'ordre recommandé : elle commence par les instances Ceph Manager, Ceph Monitor, puis continue avec d'autres services tels que les OSD Ceph et les instances Metadata Server et Object Gateway. Chaque daemon est redémarré uniquement après que Ceph indique que la grappe restera disponible.

Note
Note

La procédure de mise à jour ci-dessous utilise la commande ceph orch upgrade. Gardez à l'esprit que les instructions suivantes expliquent comment mettre à jour votre grappe Ceph avec une version de produit (par exemple, une mise à jour de maintenance), et non comment mettre à niveau votre grappe d'une version de produit à une autre.

13.7.1 Démarrage de la mise à jour

Avant de démarrer la mise à jour, vérifiez que tous les noeuds sont en ligne et que votre grappe est saine :

cephuser@adm > cephadm shell -- ceph -s

Pour effectuer une mise à jour vers une version spécifique de Ceph :

cephuser@adm > ceph orch upgrade start --image REGISTRY_URL

Par exemple :

cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7/ceph/ceph:latest

Mettez à niveau les paquetages sur les hôtes :

cephuser@adm > ceph-salt update

13.7.2 Surveillance de la mise à jour

Exécutez la commande suivante pour déterminer si une mise à jour est en cours :

cephuser@adm > ceph orch upgrade status

Pendant l'exécution de la mise à jour, vous verrez une barre de progression dans la sortie d'état de Ceph :

cephuser@adm > ceph -s
[...]
  progress:
    Upgrade to registry.suse.com/ses/7/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

Vous pouvez également consulter le journal cephadm :

cephuser@adm > ceph -W cephadm

13.7.3 Annulation d'une mise à jour

Vous pouvez arrêter le processus de mise à jour à tout moment :

cephuser@adm > ceph orch upgrade stop

13.8 Arrêt ou redémarrage de la grappe

Dans certains cas, il faudra peut-être arrêter ou redémarrer l'ensemble de la grappe. Nous vous recommandons de contrôler soigneusement les dépendances des services en cours d'exécution. Les étapes suivantes fournissent un aperçu de l'arrêt et du démarrage de la grappe :

  1. Ordonnez à la grappe Ceph de ne pas marquer les OSD comme étant hors service :

    cephuser@adm > ceph osd set noout
  2. Arrêtez les daemons et les noeuds dans l'ordre suivant :

    1. Clients de stockage

    2. Passerelles, par exemple NFS Ganesha ou Object Gateway

    3. Serveur de métadonnées

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Si nécessaire, effectuez des tâches de maintenance.

  4. Démarrez les noeuds et les serveurs dans l'ordre inverse du processus d'arrêt :

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Serveur de métadonnées

    5. Passerelles, par exemple NFS Ganesha ou Object Gateway

    6. Clients de stockage

  5. Supprimez l'indicateur noout :

    cephuser@adm > ceph osd unset noout

13.9 Suppression d'une grappe Ceph entière

La commande ceph-salt purge permet de supprimer l'intégralité de la grappe Ceph. Si d'autres grappes Ceph sont déployées, celle spécifiée par ceph -s est purgée. De cette façon, vous pouvez nettoyer l'environnement de grappe lors du test de différentes configurations.

Pour éviter toute suppression accidentelle, l'orchestration vérifie si la sécurité est désengagée. Vous pouvez désengager les mesures de sécurité et supprimer la grappe Ceph en exécutant les commandes suivantes :

root@master # ceph-salt disengage-safety
root@master # ceph-salt purge