Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / Dokumentation zu SUSE Enterprise Storage 7 / Betriebs- und Verwaltungshandbuch / Clustervorgang / Betriebsaufgaben
Gilt für SUSE Enterprise Storage 7

13 Betriebsaufgaben

13.1 Ändern der Cluster-Konfiguration

Gehen Sie zum Ändern der Konfiguration eines vorhandenen Ceph-Clusters folgendermaßen vor:

  1. Exportieren Sie die aktuelle Konfiguration des Clusters in eine Datei:

    cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
  2. Bearbeiten Sie die Datei mit der Konfiguration und aktualisieren Sie die entsprechenden Zeilen. Beispiele der Spezifikation finden Sie im Abschnitt 5.4, „Bereitstellen von Services und Gateways“ sowie in Abschnitt 13.4.3, „Hinzufügen von OSDs mit der DriveGroups-Spezifikation“.

  3. Wenden Sie die neue Konfiguration an:

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

13.2 Hinzufügen von Knoten

Führen Sie zum Hinzufügen eines neuen Knotens zu einem Ceph-Cluster folgende Schritte aus:

  1. Installieren Sie SUSE Linux Enterprise Server und SUSE Enterprise Storage auf dem neuen Host. Weitere Informationen finden Sie im Abschnitt 5.1, „Installieren und Konfigurieren von SUSE Linux Enterprise Server“.

  2. Konfigurieren Sie den Host als Salt Minion eines bereits vorhandenen Salt Masters. Weitere Informationen finden Sie im Abschnitt 5.2, „Bereitstellen von Salt“.

  3. Fügen Sie den neuen Host zu ceph-salt hinzu und machen Sie cephadm darauf aufmerksam:

    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

    Weitere Informationen finden Sie im Abschnitt 5.3.2.2, „Hinzufügen von Salt Minions“.

  4. Überprüfen Sie, ob der Knoten zu ceph-salt hinzugefügt wurde:

    root@master # ceph-salt config /ceph_cluster/minions ls
    o- minions ................................................. [Minions: 5]
    [...]
      o- ses-min5.example.com .................................... [no roles]
  5. Wenden Sie die Konfiguration auf den neuen Clusterhost an:

    root@master # ceph-salt apply ses-min5.example.com
  6. Stellen Sie sicher, dass der neu hinzugefügte Host nun zur cephadm-Umgebung gehört:

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

13.3 Entfernen von Knoten

Tipp
Tipp: Entfernen Sie die OSDs

Wenn der Knoten, den Sie entfernen möchten, OSDs ausführt, entfernen Sie zuerst die OSDs und überprüfen Sie, dass keine OSDs auf diesem Knoten ausgeführt werden. Weitere detaillierte Informationen zum Entfernen von OSDs finden Sie in Abschnitt 13.4.4, „Entfernen von OSDs“.

Gehen Sie zum Entfernen eines Knotens von einem Cluster folgendermaßen vor:

  1. Entfernen Sie bei allen Ceph-Servicetypen mit Ausnahme von node-exporter und crash den Hostnamen des Knotens aus der Spezifikationsdatei für die Clusterplatzierung (z. B. cluster.yml). Weitere Informationen finden Sie im Abschnitt 5.4.2, „Service- und Platzierungsspezifikation“. Wenn Sie beispielsweise den Host namens ses-min2 entfernen, müssen Sie alle Vorkommen von - ses-min2 aus allen placement:-Abschnitten entfernen:

    Aktualisieren Sie

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

    zu

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

    Wenden Sie die Änderungen an der Konfigurationsdatei an:

    cephuser@adm > ceph orch apply -i rgw-example.yaml
  2. Entfernen Sie den Knoten aus der Umgebung von cephadm:

    cephuser@adm > ceph orch host rm ses-min2
  3. Wenn auf dem Knoten die Services crash.osd.1 und crash.osd.2 ausgeführt werden, entfernen Sie sie, indem Sie folgendes Kommando auf dem Host ausführen:

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

    Beispiel:

    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
  4. Entfernen Sie alle Rollen von dem Minion, den Sie löschen möchten:

    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

    Wenn der zu entfernende Minion der Bootstrap-Minion ist, müssen Sie auch die Bootstrap-Rolle entfernen:

    cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset
  5. Nachdem Sie alle OSDs auf einem einzelnen Host entfernt haben, entfernen Sie den Host aus der CRUSH-Zuordnung:

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

    Der Bucket-Name sollte mit dem Hostnamen identisch sein.

  6. Sie können den Minion nun aus dem Cluster entfernen:

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

Wenn ein Fehler auftritt und sich der zu entfernende Minion in einem dauerhaft ausgeschalteten Zustand befindet, müssen Sie den Knoten vom Salt Master entfernen:

root@master # salt-key -d minion_id

Entfernen Sie dann den Knoten manuell aus pillar_root/ceph-salt.sls. Er befindet sich normalerweise in /srv/pillar/ceph-salt.sls.

13.4 OSD-Verwaltung

In diesem Abschnitt wird beschrieben, wie Sie OSDs in einem Ceph-Cluster hinzufügen, löschen oder entfernen.

13.4.1 Auflisten von Datenträgergeräten

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

13.4.2 Löschen von Datenträgergeräten

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

13.4.3 Hinzufügen von OSDs mit der DriveGroups-Spezifikation

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
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
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.3 Abstimmung von Datenträgergeräten

Sie können die Spezifikation mit folgenden Filtern beschreiben:

  • Nach Datenträgermodell:

    model: DISK_MODEL_STRING
  • Nach Datenträgerhersteller:

    vendor: DISK_VENDOR_STRING
    Tipp
    Tipp

    Geben Sie den DISK_VENDOR_STRING immer in Kleinbuchstaben ein.

    Details zu Datenträgermodell und Hersteller erhalten Sie in der Ausgabe des folgenden Kommandos:

    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
    [...]
  • Angabe, ob ein rotierender oder ein nicht rotierender Datenträger vorliegt. SSDs und NVMe-Laufwerke sind keine rotierenden Datenträger.

    rotational: 0
  • Implementieren Sie einen Knoten mit allen verfügbaren Laufwerken für OSDs:

    data_devices:
      all: true
  • Zusätzlich mit Einschränkung der Anzahl passender Datenträger

    limit: 10

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
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
Tipp: Abkürzungen für Einheiten

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

13.4.3.5 Beispiele für DriveGroups

Dieser Abschnitt enthält Beispiele verschiedener OSD-Einrichtungen.

Beispiel 13.2: Einfache Einrichtung

Dieses Beispiel zeigt zwei Knoten mit derselben Einrichtung:

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 2 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

Die entsprechende Datei drive_groups.yml sieht wie folgt aus:

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

Eine solche Konfiguration ist unkompliziert und zulässig. Es stellt sich allerdings das Problem, dass ein Administrator in Zukunft eventuell Datenträger von anderen Herstellern einfügt, die dann nicht berücksichtigt werden. Zur Verbesserung geben Sie weniger Filter für die wesentlichen Eigenschaften der Laufwerke an:

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

Im vorherigen Beispiel wird die Deklaration aller rotierenden Geräte als „Datengeräte“ erzwungen und alle nicht rotierenden Geräte werden als „freigegebene Geräte“ (wal, db) genutzt.

Wenn Laufwerke mit mehr als 2 TB stets als langsamere Datengeräte eingesetzt werden sollen, können Sie nach Größe filtern:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'
Beispiel 13.3: Erweiterte Einrichtung

Dieses Beispiel umfasst zwei getrennte Einrichtungen: 20 HDDs sollen gemeinsam 2 SSDs nutzen und 10 SSDs nutzen gemeinsam 2 NVMes.

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 12 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

  • 2 NVMes

    • Hersteller: Samsung

    • Modell: NVME-QQQQ-987

    • Größe: 256 GB

Eine solche Einrichtung kann wie folgt mit zwei Layouts definiert werden:

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
Beispiel 13.4: Erweiterte Einrichtung mit nicht einheitlichen Knoten

In den vorherigen Beispielen wurde angenommen, dass alle Knoten dieselben Laufwerke umfassen. Dies ist jedoch nicht immer der Fall:

Knoten 1–5:

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 2 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

Knoten 6–10:

  • 5 NVMes

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 20 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

Mit dem „target“-Schlüssel im Layout können Sie bestimmte Knoten adressieren. Die Salt-Zielnotation trägt zur Vereinfachung bei:

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

gefolgt von:

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
Beispiel 13.5: Experteneinrichtung

In allen vorherigen Fällen wird angenommen, dass die WALs und DBs dasselbe Gerät nutzen. Es ist jedoch auch möglich, WAL auf einem dedizierten Gerät zu implementieren:

  • 20 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 2 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

  • 2 NVMes

    • Hersteller: Samsung

    • Modell: NVME-QQQQ-987

    • Größe: 256 GB

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
Beispiel 13.6: Komplexe (und unwahrscheinliche) Einrichtung

In der folgenden Einrichtung soll Folgendes definiert werden:

  • 20 HDDs mit 1 NVMe

  • 2 HDDs mit 1 SSD(db) und 1 NVMe(wal)

  • 8 SSDs mit 1 NVMe

  • 2 Stand-Alone-SSDs (verschlüsselt)

  • 1 HDD fungiert als Ersatz und soll nicht bereitgestellt werden

Zusammenfassung der verwendeten Datenträger:

  • 23 HDDs

    • Hersteller: Intel

    • Modell: SSD-123-foo

    • Größe: 4 TB

  • 10 SSDs

    • Hersteller: Micron

    • Modell: MC-55-44-ZX

    • Größe: 512 GB

  • 1 NVMe

    • Hersteller: Samsung

    • Modell: NVME-QQQQ-987

    • Größe: 256 GB

Die DriveGroups-Definition lautet:

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

Eine HDD verbleibt, da die Datei von oben nach unten analysiert wird.

13.4.4 Entfernen von OSDs

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.

  1. Identifizieren Sie das zu entfernende OSD, indem Sie dessen ID ermitteln:

    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. Entfernen Sie ein oder mehrere OSDs aus dem Cluster:

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

    Beispiel:

    cephuser@adm > ceph orch osd rm 1 2
  3. Sie können den Status des Entfernungsvorgangs abfragen:

    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 Anhalten der OSD-Entfernung

Nach dem Planen einer OSD-Entfernung können Sie die Entfernung bei Bedarf stoppen. Mit folgendem Kommando wird der Ausgangszustand des OSDs zurückgesetzt und es wird aus der Warteschlange entfernt:

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

13.4.5 Ersetzen von OSDs

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

13.5 Verschieben des Salt Masters auf einen neuen Knoten

Wenn Sie den Salt-Master-Host durch einen neuen ersetzen müssen, führen Sie folgende Schritte aus:

  1. Exportieren Sie die Cluster-Konfiguration und sichern Sie die exportierte JSON-Datei. Weitere Informationen finden Sie im Abschnitt 5.3.2.15, „Exportieren von Cluster-Konfigurationen“.

  2. Wenn der alte Salt Master auch der einzige Verwaltungsknoten im Cluster ist, dann verschieben Sie /etc/ceph/ceph.client.admin.keyring und /etc/ceph/ceph.conf manuell auf den neuen Salt Master.

  3. Stoppen und deaktivieren Sie den Salt Master systemd-Service auf dem alten Salt-Master-Knoten:

    root@master # systemctl stop salt-master.service
    root@master # systemctl disable salt-master.service
  4. Wenn der alte Salt-Master-Knoten nicht mehr im Cluster ist, stoppen und deaktivieren Sie auch den systemd-Service des Salt Minion:

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

    Stoppen oder deaktivieren Sie den salt-minion.service nicht, wenn auf dem alten Salt-Master-Knoten irgendwelche Ceph-Daemons (MON, MGR, OSD, MDS, Gateway, Monitoring) ausgeführt werden.

  5. Installieren Sie SUSE Linux Enterprise Server 15 SP2 auf dem neuen Salt Master entsprechend dem im Abschnitt 5.1, „Installieren und Konfigurieren von SUSE Linux Enterprise Server“ beschriebenen Verfahren.

    Tipp
    Tipp: Übergang der Salt Minions

    Damit der Übergang der Salt Minions auf den neuen Salt Master erleichtert wird, entfernen Sie den öffentlichen Schlüssel des ursprünglichen Salt Masters aus allen Minions:

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  6. Installieren Sie das salt-master -Paket und gegebenenfalls das salt-minion -Paket auf dem neuen Salt Master.

  7. Installieren Sie ceph-salt auf dem neuen Salt-Master-Knoten:

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

    Stellen Sie sicher, dass Sie alle drei Kommandos ausführen, bevor Sie fortfahren. Die Befehle sind idempotent. Es spielt keine Rolle, ob sie wiederholt werden.

  8. Fügen Sie den neuen Salt Master im Cluster hinzu, wie im Abschnitt 5.3.1, „Installieren von ceph-salt, im Abschnitt 5.3.2.2, „Hinzufügen von Salt Minions“ und im Abschnitt 5.3.2.4, „Festlegen des Admin Knoten“ beschrieben.

  9. Importieren Sie die gesicherte Cluster-Konfiguration und wenden Sie sie an:

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

    Benennen Sie die minion id des Salt Masters in der exportierten Datei CLUSTER_CONFIG.json um, bevor Sie sie importieren.

13.6 Aktualisieren der Cluster-Knoten

Wenden Sie regelmäßig Updates im laufenden Betrieb an, damit die Ceph-Cluster-Knoten auf dem neuesten Stand bleiben.

13.6.1 Software-Repositorys

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 7.1.5.1, „Software-Repositorys“.

13.6.2 Repository-Staging

Wenn Sie mit einem Repository-Staging-System arbeiten (z. B. SUSE Manager, Repository Management Tool oder RMT), mit dem die Software-Repositorys für die Cluster-Knoten bereitgestellt werden, müssen die Phasen für beide „Aktualisierungen“-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.

13.6.3 Ausfallzeit von Ceph-Services

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.

13.6.4 Ausführen der Aktualisierung

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

root@master # ceph-salt update

13.7 Aktualisieren von Ceph

Sie können cephadm anweisen, Ceph von einer Bugfix-Version auf eine andere zu aktualisieren. Die automatische Aktualisierung der Ceph-Services hält sich an die empfohlene Reihenfolge. Sie beginnt mit Ceph Managers, Ceph Monitors und geht dann weiter zu anderen Services wie Ceph OSDs, Metadatenservern und Object Gateways. Jeder Daemon wird erst dann neu gestartet, wenn Ceph anzeigt, dass der Cluster verfügbar bleibt.

Anmerkung
Anmerkung

Die folgende Aktualisierung wird mit dem Kommando ceph orch upgrade ausgeführt. Beachten Sie, dass in den folgenden Anweisungen detailliert beschrieben ist, wie Sie Ihren Ceph-Cluster mit einer Produktversion aktualisieren (z. B. einem Wartungsupdate). Sie erhalten darin keine Informationen, wie Sie Ihren Cluster von einer Produktversion auf eine andere aktualisieren.

13.7.1 Starten der Aktualisierung

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

Rüsten Sie die Pakete auf den Hosts auf:

cephuser@adm > ceph-salt update

13.7.2 Überwachen der Aktualisierung

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

Sie können auch das cephadm-Protokoll beobachten:

cephuser@adm > ceph -W cephadm

13.7.3 Abbrechen einer Aktualisierung

Sie können den Aktualisierungsvorgang jederzeit stoppen:

cephuser@adm > ceph orch upgrade stop

13.8 Anhalten oder Neustarten des Clusters

In einigen Fällen muss möglicherweise der gesamte Cluster angehalten oder neugestartet werden. Wir empfehlen, sorgfältig nach Abhängigkeiten von aktiven Services zu suchen. Die folgenden Schritte beschreiben den Vorgang zum Stoppen und Starten des Clusters:

  1. Weisen Sie den Ceph-Cluster an, für OSDs das Flag „noout“ zu setzen:

    cephuser@adm > ceph osd set noout
  2. Stoppen Sie die Daemons und Knoten in der folgenden Reihenfolge:

    1. Speicher-Clients

    2. Gateways wie NFS Ganesha oder Object Gateway

    3. Metadata Server

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Führen Sie Wartungsaufgaben aus, falls erforderlich.

  4. Starten Sie die Knoten und Server in umgekehrter Reihenfolge des Herunterfahrens:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Metadata Server

    5. Gateways wie NFS Ganesha oder Object Gateway

    6. Speicher-Clients

  5. Entfernen Sie das Flag „noout“:

    cephuser@adm > ceph osd unset noout

13.9 Vollständiges Entfernen eines Ceph-Clusters

Mit dem Kommando ceph-salt purge wird der gesamte Cluster entfernt. Wenn weitere Ceph-Cluster bereitgestellt sind, wird der von ceph -s gemeldete Cluster bereinigt. Auf diese Weise können Sie die kleinste menschliche Umgebung bereinigen, wenn Sie verschiedene Einrichtungen testen.

Damit nicht versehentlich ein Löschvorgang durchgeführt wird, prüft die Orchestrierung, ob die Sicherheitsmaßnahmen deaktiviert sind. Mit folgendem Kommando können Sie die Sicherheitsmaßnahmen deaktivieren und den Ceph-Cluster entfernen:

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