13 Betriebsaufgaben #

Um verwendete und nicht verwendete Datenträgergeräte auf allen Cluster-Knoten zu identifizieren, listen Sie sie mit folgendem Kommando auf:

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

Um ein Datenträgergerät wieder zu verwenden, müssen Sie es zuerst löschen (oder zappen):

ceph orch device zap HOST_NAME DISK_DEVICE

Beispiel:

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

Anmerkung

Wenn Sie zuvor OSDs mithilfe von DriveGroups oder der Option --all-available-devices bereitgestellt haben und das Flag unmanaged dabei nicht gesetzt war, stellt cephadm diese OSDs automatisch bereit, nachdem Sie sie gelöscht haben.

DriveGroups bestimmen das Layout der OSDs im Ceph-Cluster. Sie werden in einer einzigen YAML-Datei definiert. In diesem Abschnitt wird die Datei drive_groups.yml als Beispiel herangezogen.

Ein Administrator muss manuell eine Gruppe von OSDs erstellen, die zusammenhängen (Hybrid-OSDs, die auf einer Mischung von HDDs und SDDs implementiert sind) oder dieselben Bereitstellungsoptionen aufweisen (z. B. gleicher Objektspeicher, gleiche Verschlüsselungsoption, Stand-Alone-OSDs). Damit die Geräte nicht explizit aufgelistet werden müssen, werden sie in den DriveGroups anhand einer Liste von Filterelementen gefiltert, die einigen wenigen ausgewählten Feldern in den ceph-volume-Bestandsberichten entsprechen. Der Code in cephadm wandelt diese DriveGroups in Gerätelisten um, die dann vom Benutzer geprüft werden können.

Das Kommando zum Anwenden der OSD-Spezifikation auf den Cluster lautet:

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

Für eine Vorschau der Aktionen und einen Test der Anwendung können Sie die Option --dry-run zusammen mit dem Kommando ceph orch apply osd verwenden. Beispiel:

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

Wenn die --dry-run-Ausgabe Ihren Erwartungen entspricht, führen Sie das Kommando einfach erneut ohne die Option --dry-run aus.

13.4.3.1 Nicht verwaltete OSDs #

 

Alle verfügbaren fehlerfreien Datenträgergeräte, die der DriveGroups-Spezifikation entsprechen, werden automatisch als OSDs verwendet, nachdem Sie sie dem Cluster hinzugefügt haben. Dieses Verhalten wird als verwalteter Modus bezeichnet.

Fügen Sie zum Deaktivieren des verwalteten Modus beispielsweise die Zeile unmanaged: true zu den entsprechenden Spezifikationen hinzu:

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

Tipp

Um bereits bereitgestellte OSDs vom verwalteten zum nicht verwalteten Modus zu ändern, fügen Sie während des in Abschnitt 13.1, „Ändern der Cluster-Konfiguration“ beschriebenen Vorgangs die Zeilen unmanaged: true an den entsprechenden Stellen hinzu.

13.4.3.2 DriveGroups-Spezifikation #

 

Es folgt ein Beispiel für eine DriveGroups-Spezifikationsdatei:

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

Anmerkung

Die bisher als „Verschlüsselung“ bezeichnete Option in DeepSea wurde in „verschlüsselt“ umbenannt. Stellen Sie beim Anwenden von DriveGroups in SUSE Enterprise Storage 7 sicher, dass Sie diese neue Terminologie in Ihrer Servicespezifikation verwenden, da sonst der ceph orch apply-Vorgang fehlschlägt.

13.4.3.4 Filtern von Geräten nach Größe #

 

Sie können die Datenträgergeräte nach ihrer Größe filtern – wahlweise nach einer genauen Größenangabe oder einem Größenbereich. Der Parameter size: akzeptiert Argumente wie folgt:

• „10G“ – Datenträger mit einer bestimmten Größe.

• „10G:40G“ – Datenträger mit einer Größe im angegebenen Bereich.

• „:10G“ – Datenträger mit einer Größe von maximal 10 GB.

• „40G:“ – Datenträger mit einer Größe von mindestens 40 GB.

Beispiel 13.1: Abstimmung nach Datenträgergröße #

 

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

Anmerkung: Anführungszeichen erforderlich

Beim Begrenzer „:“ müssen Sie die Größe in Anführungszeichen setzen, da das Zeichen „:“ ansonsten als neuer Konfiguration-Hash interpretiert wird.

Tipp: Abkürzungen für Einheiten

Anstelle von Gigabyte (G) können Sie die Größen auch in Megabyte (M) oder Terabyte (T) angeben.

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

Vergewissern Sie sich vor dem Entfernen eines OSD-Knotens aus dem Cluster, dass der Cluster über mehr freien Festplattenspeicher verfügt als der OSD-Datenträger, den Sie entfernen möchten. Bedenken Sie, dass durch Entfernen eines OSDs ein Ausgleich des gesamten Clusters durchgeführt wird.

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

Es gibt verschiedene Gründe für den Austausch eines OSD-Datenträgers. Beispiel:

Ersetzen Sie ein OSD unter Beibehaltung seiner ID mit folgendem Kommando:

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

Beispiel:

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

Der Vorgang zum Ersetzen eines OSDs ist identisch mit dem Vorgang zum Entfernen eines OSDs (weitere Details finden Sie in Abschnitt 13.4.4, „Entfernen von OSDs“). Allerdings wird beim Ersetzen das OSD nicht dauerhaft aus der CRUSH-Hierarchie entfernt und stattdessen ein Flag destroyed gesetzt.

Durch das Flag destroyed werden OSD-IDs ermittelt, die beim nächsten OSD-Einsatz wiederverwendet werden. Neu hinzugefügte Datenträger, die der DriveGroups-Spezifikation entsprechen (weitere Details finden Sie in Abschnitt 13.4.3, „Hinzufügen von OSDs mit der DriveGroups-Spezifikation“), erhalten die OSD-IDs des ersetzten Gegenstücks.

Tipp

Durch Anhängen der Option --dry-run wird die eigentliche Ersetzung nicht ausgeführt, sondern es wird eine Vorschau der Schritte angezeigt, die normalerweise ablaufen würden.

Anmerkung

Falls Sie ein OSD nach einem Ausfall austauschen, wird dringend empfohlen, einen umfassenden Scrub der Platzierungsgruppen auszulösen. Weitere Einzelheiten finden Sie unter Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“.

Führen Sie folgendes Kommando aus, um einen umfassenden Scrub zu starten:

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

Wichtig: Ausfall eines freigegebenen Geräts

Wenn ein freigegebenes Gerät für DB/WAL ausfällt, müssen Sie die Ersetzung für alle OSDs durchführen, die das ausgefallene freigegebene Gerät nutzen.

Bevor Sie den Cluster mit den aktuellen Software-Paketen patchen, prüfen Sie, ob alle Cluster-Knoten auf die relevanten Repositorys zugreifen können. Eine Liste aller erforderlichen Repositorys finden Sie in Abschnitt 10.1.5.1, „Software-Repositorys“.

Wenn Sie mit einem Staging-Tool arbeiten (z. B. SUSE Manager, Subscription Management Tool oder RMT), mit dem die Software-Repositorys für die Cluster-Knoten bereitgestellt werden, müssen die Phasen für beide „Updates“-Repositorys für SUSE Linux Enterprise Server und SUSE Enterprise Storage zum gleichen Zeitpunkt erstellt werden.

Wir empfehlen dringend, ein Staging-Tool zu verwenden, um Patches mit eingefrorenen oder gestaffelten Patch-Stufen anzuwenden. Damit wird gewährleistet, dass die neu in den Cluster eintretenden Knoten dieselbe Patchstufe aufweisen wie die Knoten, die sich bereits im Cluster befinden. So müssen Sie nicht mehr die aktuellen Patches auf alle Cluster-Knoten anwenden, bevor neue Knoten in den Cluster aufgenommen werden können.

Je nach Konfiguration werden die Cluster-Knoten während der Aktualisierung ggf. neu gestartet. Wenn ein Single-Point-of-Failure für Services wie Object Gateway, Samba Gateway, NFS Ganesha oder iSCSI vorliegt, werden die Client-Computer unter Umständen vorübergehend von Services getrennt, dessen Knoten neu gestartet werden.

Aktualisieren Sie mit folgendem Kommando die Softwarepakete auf allen Cluster-Knoten auf die aktuelle Version:

root@master # ceph-salt update

Vergewissern Sie sich vor dem Starten der Aktualisierung, dass alle Knoten zurzeit online sind und der Cluster integer ist:

cephuser@adm > cephadm shell -- ceph -s

So aktualisieren Sie auf eine bestimmte Ceph-Version:

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

Beispiel:

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

Rüsten Sie die Pakete auf den Hosts auf:

cephuser@adm > ceph-salt update

Ermitteln Sie mit folgendem Kommando, ob eine Aktualisierung durchgeführt wird:

cephuser@adm > ceph orch upgrade status

Während des Aktualisierungsvorgangs sehen Sie in der Ceph-Statusausgabe einen Fortschrittsbalken:

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

Sie können auch das cephadm-Protokoll beobachten:

cephuser@adm > ceph -W cephadm

Sie können den Aktualisierungsvorgang jederzeit stoppen:

cephuser@adm > ceph orch upgrade stop