13 Tâches opérationnelles #

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

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

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.

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

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

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

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

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

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

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

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

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

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

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.

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

Plusieurs raisons peuvent vous pousser à remplacer un disque OSD. Par exemple :

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

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.

Note

En cas de remplacement d'un OSD à la suite d'un échec, nous vous recommandons vivement de déclencher un nettoyage en profondeur des groupes de placement. Pour plus d'informations, reportez-vous au Section 17.6, « Nettoyage des groupes de placement ».

Exécutez la commande suivante pour lancer un nettoyage en profondeur :

cephuser@adm > ceph osd deep-scrub osd.OSD_NUMBER

Important : échec du périphérique partagé

En cas d'échec d'un périphérique partagé pour DB/WAL, vous devez effectuer la procédure de remplacement pour tous les OSD qui partagent le périphérique ayant échoué.

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 10.1.5.1, « Dépôts logiciels ».

Si vous utilisez un outil de préparation (SUSE Manager, Subscription 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.

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.

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

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

Mettez à niveau les paquetages sur les hôtes :

cephuser@adm > ceph-salt update

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.1/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

Vous pouvez également consulter le journal cephadm :

cephuser@adm > ceph -W cephadm

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

cephuser@adm > ceph orch upgrade stop