Die Basiskomponente von Ceph wird RADOS (Reliable Autonomic Distributed Object Store, Zuverlässiger autonomer dezentraler Objektspeicher) genannt. Sie ist für die Verwaltung der im Cluster gespeicherten Daten zuständig. Daten werden in Ceph normalerweise als Objekte gespeichert. Jedes Objekt besteht aus einer Kennung und den Daten.

RADOS bietet die folgenden Methoden für den Zugriff auf gespeicherte Objekte, die viele Anwendungsfälle abdecken:

librados wird vom Object Gateway und RBD verwendet, während CephFS direkt mit RADOS (Abbildung 1.1, „Schnittstellen zum Ceph-Objektspeicher“) interagiert.

Abbildung 1.1: Schnittstellen zum Ceph-Objektspeicher #

 

Der CRUSH-Algorithmus ist das zentrale Element eines Ceph-Clusters. CRUSH ist das Akronym für Controlled Replication Under Scalable Hashing. CRUSH ist eine Funktion für die Speicherzuordnung und benötigt vergleichsweise wenig Parameter. Es sind also nur wenige Informationen erforderlich, um die Speicherposition eines Objekts zu berechnen. Die Parameter stellen eine aktuelle Zuordnung für den Cluster dar, einschließlich Integrität, einiger vom Administrator definierter Platzierungsregeln und des Namens des Objekts, das gespeichert oder abgerufen werden muss. Mit diesen Informationen können alle Knoten im Ceph-Cluster berechnen, wo ein Objekt und dessen Reproduktionen gespeichert sind. Dies macht das Schreiben und Lesen von Daten sehr effizient. CRUSH versucht, Daten gleichmäßig auf alle Knoten im Cluster zu verteilen.

Die CRUSH-Zuordnung umfasst alle Speicherknoten und vom Administrator definierte Platzierungsregeln zum Speichern von Objekten im Cluster. Sie definiert eine hierarchische Struktur, die normalerweise mit der physischen Struktur des Clusters korrespondiert. Beispielsweise befinden sich Festplatten mit Daten in Hosts, Hosts in Racks, Racks in Reihen und Reihen in Rechenzentren. Diese Struktur wird zur Definition von Fehlerdomänen herangezogen. Ceph stellt dann sicher, dass Reproduktionen in verschiedenen Verzweigungen einer bestimmten Fehlerdomäne gespeichert werden.

Wenn die Fehlerdomäne auf „Rack“ festgelegt ist, werden Reproduktionen von Objekten auf verschiedene Racks verteilt. Dadurch werden Ausfälle entschärft, die durch einen fehlerhaften Schalter in einem Rack verursacht wurden. Wenn eine Stromversorgungseinheit eine Reihe von Racks bereitstellt, kann die Fehlerdomäne auf „Reihe“ festgelegt werden. Wenn die Stromversorgungseinheit ausfällt, sind die Reproduktionsdaten noch in anderen Reihen verfügbar.

In Ceph sind Knoten Server, die für den Cluster arbeiten. Sie können verschiedene Typen von Daemons ausführen. Es wird empfohlen, nur einen Typ von Daemon pro Knoten auszuführen, ausgenommen Ceph Manager Daemons, die gemeinsam mit Ceph Monitors auf einem Knoten ausgeführt werden. Für jeden Client sind mindestens Ceph Monitor, Ceph Manager und Ceph OSD Daemons erforderlich:

Für CephFS, Object Gateway, NFS Ganesha oder iSCSI Gateway sind zusätzliche Knoten erforderlich:

In einem Ceph-Cluster gespeicherte Objekte werden in Pools abgelegt. Pools stellen logische Partitionen des Clusters zur Außenwelt dar. Für jeden Pool kann ein Regelsatz definiert werden, beispielsweise wie viele Reproduktionen eines jeden Objekts vorhanden sein müssen. Die Standardkonfiguration von Pools wird als reproduzierter Pool bezeichnet.

Pools enthalten normalerweise Objekte, können jedoch auch so konfiguriert werden, dass sie wie ein RAID 5 funktionieren. In dieser Konfiguration werden Objekte in Datenblöcken zusammen mit zusätzlichen Codierungs-Datenblöcken gespeichert. Die Codierungs-Datenblöcke enthalten die redundanten Informationen. Die Anzahl der Daten und Codierungs-Datenblöcke werden vom Administrator definiert. In dieser Konfiguration werden Pools als Pools mit Löschcodierung oder EC-Pools (Erasure Coded Pools, EC) bezeichnet.

Placement Groups (PGs) dienen zur Verteilung von Daten in einem Pool. Beim Erstellen eines Pools wird eine bestimmte Anzahl von Placement Groups festgelegt. Die Placement Groups werden intern zur Gruppierung von Objekten verwendet. Sie sind ein wichtiger Faktor für die Leistung eines Ceph-Clusters. Die PG für ein Objekt wird durch den Namen des Objekts bestimmt.

In diesem Abschnitt finden Sie ein vereinfachtes Beispiel dafür, wie Ceph Daten verwaltet (Abbildung 1.2, „Beispiel eines kleinen Ceph-Speichers“). Dieses Beispiel stellt keine empfohlene Konfiguration für einen Ceph-Cluster dar. Die Hardwareeinrichtung umfasst drei Speicher-Knoten oder Ceph OSDs (Host 1, Host 2, Host 3). Jeder Knoten hat drei Festplatten, die als OSDs (osd.1 bis osd.9) verwendet werden. In diesem Beispiel sind keine Ceph-Monitor-Knoten berücksichtigt.

Anmerkung: Unterschied zwischen Ceph OSD und OSD

Die Begriffe Ceph OSD oder Ceph OSD Daemon beziehen sich auf einen Daemon, der auf einem Knoten ausgeführt wird. Der Begriff OSD dagegen bezieht sich auf einen logischen Datenträger, mit dem der Daemon interagiert.

Der Cluster umfasst zwei Pools, Pool A und Pool B. Während Pool A Objekte nur zweimal reproduziert, ist Ausfallsicherheit für Pool B wichtiger und es gibt daher drei Reproduktionen für jedes Objekt.

Wenn eine Anwendung ein Objekt in einen Pool stellt, beispielsweise über die REST API, dann wird eine Placement Group (PG1 bis PG4) auf Basis des Pools und des Objektnamens ausgewählt. Der CRUSH-Algorithmus berechnet dann, auf welchen OSDs das Objekt gespeichert ist, basierend auf der Placement Group, die das Objekt enthält.

In diesem Beispiel ist die Fehlerdomäne auf Host festgelegt. Dadurch wird sichergestellt, dass die Reproduktionen von Objekten auf verschiedenen Hosts gespeichert sind. Je nach der für einen Pool festgelegten Reproduktionsstufe wird das Objekt auf zwei oder drei OSDs gespeichert, die von der Placement Group verwendet werden.

Eine Anwendung, die ein Objekt schreibt, interagiert nur mit einem Ceph OSD, nämlich dem primären Ceph OSD. Der primäre Ceph OSD führt die Reproduktion aus und bestätigt die Durchführung des Schreibvorgangs, nachdem alle anderen OSDs das Objekt gespeichert haben.

Wenn osd.5 ausfällt, sind alle Objekte in PG1 immer noch auf osd.1 verfügbar. Sobald der Cluster feststellt, dass ein OSD ausgefallen ist, übernimmt ein anderer OSD. In diesem Beispiel wird osd.4 als Ersatz für osd.5 verwendet. Die auf osd.1 gespeicherten Objekte werden dann auf osd.4 reproduziert, um die Reproduktionsstufe wiederherzustellen.

Abbildung 1.2: Beispiel eines kleinen Ceph-Speichers #

 

Die Cluster-Zuordnung ändert sich, wenn ein neuer Knoten mit neuen OSDs zum Cluster hinzugefügt wird. Die CRUSH-Funktion gibt dann verschiedene Standorte für Objekte zurück. Objekte, die neue Standorte erhalten, werden verschoben. Durch diesen Vorgang bleiben alle OSDs gleichmäßig ausgelastet.

Wir empfehlen ein einzelnes fehlertolerantes Netzwerk mit ausreichender Bandbreite für Ihre Anforderungen. Für die öffentliche Ceph-Netzwerkumgebung empfehlen wir zwei verbundene 25-GbE-Netzwerkschnittstellen (oder schneller), die über 802.3ad (LACP) verbunden sind. Dies wird als die Mindesteinrichtung für Ceph betrachtet. Wenn Sie zusätzlich ein Clusternetzwerk verwenden, empfehlen wir vier verbundene 25-GbE-Netzwerkschnittstellen. Durch Verbinden von zwei oder mehr Netzwerkschnittstellen verbessern sich der Durchsatz durch Link-Aggregation und, bei redundanten Links und Switches, die Fehlertoleranz und Wartbarkeit.

Sie können auch VLANs erstellen, um verschiedene Arten von Datenverkehr über eine Verbindung zu isolieren. Sie können beispielsweise eine Verbindung erstellen, um zwei VLAN-Schnittstellen bereitzustellen, eine für das öffentliche Netzwerk und die zweite für das Clusternetzwerk. Beim Einrichten des Ceph-Netzwerks ist dies jedoch nicht erforderlich. Details zum Verbinden von Schnittstellen finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-iface-bonding.

Die Fehlertoleranz kann durch Isolierung der Komponenten in Fehlerdomänen erhöht werden. Zur Erhöhung der Fehlertoleranz des Netzwerks wird durch Verbinden einer Schnittstelle von zwei separaten Netzwerkschnittstellenkarten (NIC) Schutz vor dem Ausfall einer einzelnen NIC erreicht. In ähnlicher Weise schützt das Erstellen einer Verbindung zwischen zwei Switches vor dem Ausfall eines Switches. Wir empfehlen, den Hersteller der Netzwerkgeräte zu konsultieren, um den erforderlichen Grad an Fehlertoleranz zu ermitteln.

Wichtig: Verwaltungsnetzwerk

Die Einrichtung eines zusätzlichen Verwaltungsnetzwerks, das zum Beispiel die Trennung von SSH-, Salt- oder DNS-Netzwerken ermöglicht, wurde weder getestet, noch wird sie unterstützt.

Tipp: Über DHCP konfigurierte Knoten

Wenn Ihre Speicherknoten über DHCP konfiguriert werden, reichen die standardmäßigen Zeitüberschreitungen möglicherweise nicht für eine korrekte Konfiguration des Netzwerks aus, bevor die Ceph Daemons starten. Wenn dies geschieht, werden die Ceph-MONs und -OSDs nicht korrekt gestartet (das Ausführen von systemctl status ceph\* führt zur Fehlermeldung „unable to bind“ (Verbinden nicht möglich)). Zur Vermeidung dieses Problems empfehlen wir, die DHCP-Client-Zeitüberschreitung auf jedem Knoten in Ihrem Speichercluster auf mindestens 30 Sekunden zu erhöhen. Dies wird erreicht durch Ändern der folgenden Einstellungen in jedem Knoten:

Legen Sie in /etc/sysconfig/network/dhcp Folgendes fest:

DHCLIENT_WAIT_AT_BOOT="30"

Legen Sie in /etc/sysconfig/network/config Folgendes fest:

WAIT_FOR_INTERFACES="60"

2.1.1.2 Überwachungsknoten in verschiedenen Teilnetzen #

 

Wenn sich die Überwachungsknoten in mehreren Teilnetzen befinden, beispielsweise in verschiedenen Räumen und gesteuert durch verschiedene Schalter, dann müssen Sie ihre öffentliche Netzwerkadresse in der CIDR-Schreibweise entsprechend anpassen:

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Beispiel:

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"

Warnung

Wenn Sie, wie in diesem Abschnitt beschrieben, mehr als ein Netzwerksegment für das öffentliche Netzwerk (oder für das Clusternetzwerk) angeben, muss jedes dieser Teilnetze zur Weiterleitung zu den anderen Teilnetzen in der Lage sein. Andernfalls können die MONs und andere Ceph-Daemons auf verschiedenen Netzwerksegmenten nicht miteinander kommunizieren, was zu einem geteilten Cluster führen würde. Wenn Sie eine Firewall verwenden, stellen Sie außerdem sicher, dass Sie jede IP-Adresse oder jedes Teilnetz in Ihre iptables einbeziehen und Ports für sie auf allen Knoten öffnen, falls erforderlich.

Eine Mindestkonfiguration für den Produktcluster besteht aus:

Eine detaillierte Konfiguration besteht aus folgenden Komponenten:

Abbildung 2.2: Mindestkonfiguration für den Cluster #

 

Sobald Sie Ihren Cluster vergrößern, empfehlen wir, Ceph Monitors, Metadatenserver und Gateways auf separate Knoten zu verlagern, um eine bessere Fehlertoleranz zu erreichen.

Wenn Sie Multipfadhardware verwenden möchten, stellen Sie sicher, dass LVM in der Konfigurationsdatei unter dem Abschnitt Geräte die Einstellung multipath_component_detection = 1 sieht. Dies wird mit dem Kommando lvm config geprüft.

Stellen Sie alternativ sicher, dass LVM die Multipfadkomponenten eines Geräts über die LVM-Filterkonfiguration filtert. Das ist hostspezifisch zu verstehen.

Anmerkung

Es wird nicht empfohlen und sollte immer nur dann in Betracht gezogen werden, wenn multipath_component_detection = 1 nicht festgelegt werden kann.

Weitere Informationen zur Multipfadkonfiguration finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

Zwei Arten von Datenträgerspeicherplatz werden zur Ausführung auf OSD benötigt: der Speicherplatz für das WAL/DB-Gerät sowie der primäre Speicherplatz für die gespeicherten Daten. Der Mindestwert (und Standardwert) für das WAL/DB beträgt 6 GB. Der Mindestspeicherplatz für Daten beträgt 5 GB, da Partitionen, die kleiner als 5 GB sind, das Gewicht 0 zugewiesen wird.

Auch wenn nun der Mindestspeicherplatz für ein OSD 11 GB beträgt, empfehlen wir mindestens 20 GB pro Festplatte, sogar für Testzwecke.

Solid-State- oder Festkörperlaufwerke (SSD) haben keine beweglichen Teile. Dadurch wird die Zeit für den zufälligen Zugriff und die Leselatenz reduziert und der Datendurchsatz beschleunigt. Da der Preis pro 1 MB für SSDs erheblich höher ist als der Preis für sich drehende Festplatten, eignen sich SSDs nur für kleinere Speicher.

Die Leistung von OSDs wird möglicherweise erheblich verbessert, wenn Sie deren WAL/ DB auf einem SSD speichern und die Objektdaten auf einer separaten Festplatte.

Tipp: Freigabe einer SSD für mehrere WAL/DB-Partitionen

Da WAL/DB-Partitionen relativ wenig Speicherplatz belegen, können Sie einen SSD-Datenträger mit mehreren WAL/DB-Partitionen freigeben. Bedenken Sie dabei jedoch, dass sich mit jeder WAL/DB-Partition die Leistung des SSD-Datenträgers verschlechtert. Wir empfehlen, maximal sechs WAL/DB-Partitionen pro SSD-Datenträger zu speichern und zwölf pro NVMe-Datenträger.

Jeder Server kann so viele Festplatten enthalten wie für ihn zulässig sind. Bei der Planung der Anzahl von Festplatten pro Server gibt es einiges zu bedenken:

SUSE Manager und SUSE Enterprise Storage sind nicht integriert. Daher kann SUSE Manager aktuell keinen SES-Cluster verwalten.

ceph-salt stellt Werkzeuge zum Bereitstellen von Ceph-Clustern bereit, die von cephadm verwaltet werden. ceph-salt nutzt die Salt-Infrastruktur, um die Verwaltung des Betriebssystems – beispielsweise Softwareaktualisierungen oder Zeitsynchronisierung – durchzuführen und Rollen für Salt Minions zu definieren.

Installieren Sie am Salt Master das Paket ceph-salt :

root@master # zypper install ceph-salt

Mit obigem Kommando wurde ceph-salt-formula als Abhängigkeit installiert, die die Salt-Master-Konfiguration durch Einfügen zusätzlicher Dateien im Verzeichnis /etc/salt/master.d geändert hat. Um die Änderungen anzuwenden, starten Sie salt-master.service neu und synchronisieren Sie die Salt-Module:

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

Konfigurieren Sie mit dem Kommando ceph-salt config die grundlegenden Eigenschaften des Clusters.

Wichtig

Die Datei /etc/ceph/ceph.conf wird von cephadm verwaltet und sollte nicht von Benutzern bearbeitet werden. Die Ceph-Konfigurationsparameter sollten mit dem neuen Kommando ceph config festgelegt werden. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Book “Betriebs- und Verwaltungshandbuch”, Chapter 28 “Konfiguration des Ceph-Clusters”, Section 28.2 “Konfigurationsdatenbank”.

5.3.2.1 Verwenden der ceph-salt-Shell #

 

Wenn Sie ceph-salt config ohne Pfad oder Unterbefehl ausführen, gelangen Sie in eine interaktive ceph-salt-Shell. Die Shell ist praktisch, wenn Sie mehrere Eigenschaften in einem Stapel konfigurieren müssen und nicht die vollständige Kommandosyntax eingeben möchten.

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]

Wie Sie der Ausgabe des ls-Kommandos von ceph-salt entnehmen können, ist die Cluster-Konfiguration in einer Baumstruktur organisiert. Sie haben zwei Möglichkeiten zum Konfigurieren einer bestimmten Eigenschaft des Clusters in der ceph-salt-Shell:

• Führen Sie das Kommando von der aktuellen Position aus und geben Sie den absoluten Pfad zur Eigenschaft als erstes Argument ein:

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

• Wechseln Sie zu dem Pfad, dessen Eigenschaft Sie konfigurieren müssen, und führen Sie das Kommando aus:

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

Tipp: Automatische Vervollständigung von Konfigurations-Snippets

Während Sie sich in einer ceph-salt-Shell befinden, können Sie die Funktion der automatischen Vervollständigung ähnlich wie in einer normalen Linux-Shell (Bash) verwenden. Sie vervollständigt Konfigurationspfade, Unterkommandos oder Salt-Minion-Namen. Beim automatischen Vervollständigen eines Konfigurationspfads haben Sie zwei Möglichkeiten:

• Drücken Sie zweimal die TAB-Taste →|, damit die Shell einen Pfad relativ zu Ihrer aktuellen Position beendet.

• Geben Sie / ein und drücken Sie zweimal die TAB-Taste →|, damit die Shell einen absoluten Pfad beendet.

Tipp: Navigieren mit den Cursortasten

Wenn Sie cd aus der ceph-salt-Shell heraus ohne Pfad eingeben, wird durch das Kommando eine Baumstruktur der Cluster-Konfiguration ausgegeben, wobei die Zeile des aktuellen Pfads aktiv ist. Mit den Cursortasten nach oben und nach unten navigieren Sie durch die einzelnen Zeilen. Nach dem Bestätigen mit der Eingabetaste Eingabetaste wird der Konfigurationspfad zum letzten aktiven Pfad geändert.

Wichtig: Konvention

Wir verwenden eine einzige Kommandosyntax ohne Eingabe der ceph-salt-Shell, um die Dokumentation konsistent zu halten. Sie können zum Beispiel den Cluster-Konfigurationsbaum mit folgendem Kommando auflisten:

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 Festlegen des Admin Knoten #

 

Der Admin-Knoten ist der Knoten, auf dem die Konfigurationsdatei ceph.conf und der Ceph-Admin-Schlüsselbund installiert sind. Normalerweise führen Sie Ceph-spezifische Kommandos auf dem Admin-Knoten aus.

Tipp: Salt Master und Admin-Knoten auf demselben Knoten

In einer homogenen Umgebung, in der alle oder die meisten Hosts zu SUSE Enterprise Storage gehören, wird empfohlen, dass sich der Admin-Knoten auf demselben Host befindet wie der Salt Master.

In einer heterogenen Umgebung, in der eine Salt-Infrastruktur mehr als einen Cluster hostet (z. B. SUSE Enterprise Storage zusammen mit SUSE Manager), sollten Sie den Admin-Knoten nicht auf demselben Host wie den Salt Master platzieren.

Geben Sie den Admin-Knoten mit folgendem Kommando an:

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]

Tipp: Installieren Sie ceph.conf und den Admin-Schlüsselbund auf mehreren Knoten

Sie können die Ceph-Konfigurationsdatei und den Admin-Schlüsselbund auf mehreren Knoten installieren, wenn dies für Ihre Bereitstellung erforderlich ist. Vermeiden Sie aus Sicherheitsgründen, sie auf allen Knoten des Clusters zu installieren.

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 Festlegen von abgestimmten Profilen #

 

Sie müssen angeben, in welchen der Minions des Clusters aktiv abgestimmte Profile vorhanden sein sollen. Fügen Sie dazu diese Rollen mit den folgenden Kommandos explizit hinzu:

Anmerkung

Ein Minion kann nicht gleichzeitig über die Rollen Latenz und Durchsatz verfügen.

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 Konfigurieren des Berechtigungsnachweises für die Anmeldung am Ceph Dashboard #

 

Ceph Dashboard ist nach der Bereitstellung des Basisclusters verfügbar. Um darauf zuzugreifen, müssen Sie einen gültigen Benutzernamen und ein Passwort festlegen, zum Beispiel:

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD

Tipp: Erzwingen der Passwortaktualisierung

Standardmäßig wird der erste Dashboard-Benutzer gezwungen, sein Passwort bei der ersten Anmeldung am Dashboard zu ändern. Deaktivieren Sie diese Funktion mit folgendem Kommando:

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

5.3.2.10 Konfigurieren des Pfads zu den Container-Images #

 

cephadm benötigt einen gültigen URI-Pfad zu Container-Images für die Bereitstellung. Prüfen Sie, ob der Standardpfad festgelegt ist:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

Wenn kein Standardpfad festgelegt ist oder für die Bereitstellung ein bestimmter Pfad erforderlich ist, fügen Sie ihn wie folgt hinzu:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph

Anmerkung

Für den Überwachungs-Stack werden weitere Container-Images benötigt. Für eine Air-Gap-Bereitstellung sowie für die Bereitstellung von einer lokalen Registrierung sollten Sie diese Images an diesem Punkt abrufen, um Ihre lokale Registrierung entsprechend vorzubereiten.

Beachten Sie, dass diese Container-Images nicht von ceph-salt für die Bereitstellung verwendet werden. Es ist eine Vorbereitung für einen späteren Schritt, bei dem cephadm für die Bereitstellung oder die Migration von Überwachungskomponenten eingesetzt wird.

Weitere Informationen zu den vom Überwachungs-Stack verwendeten Images und dazu, wie Sie sie anpassen können, finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 16 “Überwachung und Warnungen”, Section 16.1 “Konfigurieren von benutzerdefinierten oder lokalen Images”.

5.3.2.11 Konfigurieren der Container-Registrierung #

 

Optional können Sie eine lokale Container-Registrierung festlegen. Sie dient als Spiegel der Registrierung registry.suse.com. Denken Sie daran, dass Sie die lokale Registrierung neu synchronisieren müssen, wenn neue aktualisierte Container von registry.suse.com verfügbar sind.

In den folgenden Szenarien ist es nützlich, eine lokale Registrierung zu erstellen:

• Sie haben viele Cluster-Knoten und möchten Downloadzeit und Bandbreite sparen, indem Sie einen lokalen Spiegel der Container-Images erstellen.

• Ihr Cluster hat keinen Zugriff auf die Online-Registrierung (eine Air-Gap-Bereitstellung), und Sie benötigen einen lokalen Spiegel, von dem Sie die Container-Images abrufen.

• Wenn Konfigurations- oder Netzwerkprobleme Ihren Cluster daran hindern, über eine sichere Verbindung auf Remote-Registrierungen zuzugreifen, so benötigen Sie stattdessen eine lokale, unverschlüsselte Registrierung.

Wichtig

Zum Bereitstellen von Program Temporary Fixes (PTFs) auf einem unterstützten System müssen Sie eine lokale Container-Registrierung bereitstellen.

Gehen Sie folgendermaßen vor, um eine lokale Registrierungs-URL zusammen mit dem Berechtigungsnachweis für den Zugriff zu konfigurieren:

1. Konfigurieren Sie die URL der lokalen Registrierung:

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REGISTRY_URL

2. Konfigurieren Sie den Benutzernamen und das Passwort für den Zugriff auf die lokale Registrierung:

   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. Führen Sie ceph-salt apply aus, um den Salt-Pillar auf allen Minions zu aktualisieren.

Tipp: Registrierungs-Cache

Sie können einen Registrierungs-Cache konfigurieren, um zu verhindern, dass die lokale Registrierung neu synchronisiert wird, wenn neue aktualisierte Container auftauchen.

Für die Methoden der Cloud-nativen Anwendungsentwicklung und Zustellung sind eine Registrierung und eine CI/CD-Instanz (Continuous Integration/Delivery) für die Entwicklung und Produktion von Container-Images erforderlich. Sie können in dieser Instanz eine private Registrierung verwenden.

5.3.2.12 Aktivieren der Datenverschlüsselung während der Ausführung (msgr2) #

 

Das Messenger-v2-Protokoll (MSGR2) ist das On-Wire-Protokoll von Ceph. Es bietet einen Sicherheitsmodus, der alle Daten verschlüsselt, die über das Netzwerk übertragen werden, verkapselt Authentifizierungs-Nutzlasten und ermöglicht die zukünftige Integration von neuen Authentifizierungsmodi (wie Kerberos).

Wichtig

msgr2 wird derzeit nicht von Linux-Kernel-Ceph-Clients, wie CephFS und RBG, unterstützt.

Ceph-Daemons können an mehrere Ports binden, so dass sich sowohl ältere Ceph-Clients als auch neue v2-fähige Clients mit demselben Cluster verbinden können. Standardmäßig binden MONs jetzt an den neuen, von der IANA zugewiesenen Port 3300 (CE4h oder 0xCE4) für das neue v2-Protokoll. Für das alte v1-Protokoll binden Sie auch an den alten Standardport 6789.

Das v2-Protokoll (MSGR2) unterstützt zwei Verbindungsmodi:

crc mode (CRC-Modus)

Eine starke anfängliche Authentifizierung beim Aufbauen der Verbindung und eine CRC32C-Integritätsprüfung.

secure mode (sicherer Modus)

Eine starke anfängliche Authentifizierung beim Aufbauen der Verbindung und eine vollständige Verschlüsselung des gesamten Datenverkehrs nach der Authentifizierung, einschließlich einer kryptografischen Integritätsprüfung.

Für die meisten Verbindungen stehen Optionen zur Verfügung, mit denen die Verwendung der Modi gesteuert wird:

ms_cluster_mode (MS_Cluster_Modus)

Der für die Intra-Clusterkommunikation zwischen Ceph-Daemons verwendete Verbindungsmodus (oder die zulässigen Modi). Wenn mehrere Modi aufgeführt sind, werden die zuerst aufgeführten Modi bevorzugt.

ms_service_mode (MS_Service_Modus)

Eine Liste der zulässigen Modi, die für Clients beim Herstellen der Verbindung mit dem Cluster verwendet werden sollen.

ms_client_mode (MS_Client_Modus)

Eine nach Präferenz geordnete Liste von Verbindungsmodi, die für Clients bei der Kommunikation mit einem Ceph-Cluster verwendet (oder zugelassen) werden sollen.

Parallel dazu gibt es eine Reihe von Optionen, die speziell für Monitore gelten und es Administratoren ermöglichen, unterschiedliche (in der Regel sicherere) Anforderungen an die Kommunikation mit den Monitoren festzulegen.

ms_mon_cluster_mode (MS_MON_Cluster_Modus)

Der Verbindungsmodus (oder zulässige Modi), der zwischen den Monitoren verwendet werden soll.

ms_mon_service_mode (MS_MON_Service_Modus)

Eine Liste der für Clients oder andere Ceph-Daemons zulässigen Modi, die beim Herstellen der Verbindung mit Monitoren verwendet werden sollen.

ms_mon_client_mode (MS_MON_Client_Modus)

Eine nach Präferenz geordnete Liste der Verbindungsmodi, die für Clients oder Nicht-Monitor-Daemons beim Herstellen einer Verbindung mit Monitoren verwendet werden sollen.

Zum Aktivieren des MSGR2-Verschlüsselungsmodus während der Bereitstellung müssen Sie einige Konfigurationsoptionen zur ceph-salt-Konfiguration hinzufügen, bevor Sie ceph-salt apply ausführen.

Führen Sie für den sicheren Modus folgende Kommandos aus.

Fügen Sie den globalen Abschnitt zu ceph_conf im Konfigurationswerkzeug ceph-salt hinzu:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

Wählen Sie eine der folgenden Optionen aus:

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"

Anmerkung

Stellen Sie sicher, dass secure vor crc steht.

Führen Sie zum Erzwingen des sicheren Modus folgende Kommandos aus:

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

Tipp: Aktualisieren der Einstellungen

Wenn Sie eine der oben genannten Einstellungen ändern möchten, legen Sie die Konfigurationsänderungen im Monitor-Konfigurationsspeicher fest. Dies wird mit dem Kommando ceph config set erreicht.

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

Beispiel:

root@master # ceph config set global ms_cluster_mode "secure crc"

Überprüfen Sie den aktuellen Wert, einschließlich des Standardwerts, mit folgendem Kommando:

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

Führen Sie beispielsweise zum Abrufen des ms_cluster_mode für OSDs folgendes Kommando aus:

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 Überprüfen der Cluster-Konfiguration #

 

Die minimale Cluster-Konfiguration ist abgeschlossen. Überprüfen Sie sie auf offensichtliche Fehler:

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]

Tipp: Status der Cluster-Konfiguration

Mit folgendem Kommando können Sie überprüfen, ob die Konfiguration des Clusters gültig ist:

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

5.3.2.15 Exportieren von Cluster-Konfigurationen #

 

Nachdem Sie den Basiscluster konfiguriert haben und die Konfiguration gültig ist, ist es sinnvoll, die Konfiguration in eine Datei zu exportieren:

root@master # ceph-salt export > cluster.json

Warnung

Die Ausgabe von ceph-salt export enthält den privaten SSH-Schlüssel. Wenn Sie Bedenken hinsichtlich sicherheitsrelevanter Auswirkungen haben, führen Sie dieses Kommando nur mit den entsprechenden Vorsichtsmaßnahmen aus.

Führen Sie folgendes Kommando aus, falls Sie die Cluster-Konfiguration unterbrechen und zu einem Sicherungszustand zurückkehren müssen:

root@master # ceph-salt import cluster.json

Aktualisieren Sie vor dem Bereitstellen des Clusters alle Softwarepakete auf allen Knoten:

root@master # ceph-salt update

Wenn ein Knoten während der Aktualisierung Reboot is needed (Reboot erforderlich) meldet, wurden wichtige Betriebssystempakete (z. B. der Kernel) auf eine neuere Version aktualisiert. Sie müssen den Knoten daraufhin neu booten, um die Änderungen zu übernehmen.

Für einen erforderlichen Reboot aller Knoten hängen Sie entweder die Option --reboot an

root@master # ceph-salt update --reboot

oder Sie booten sie neu in einem separaten Schritt:

root@master # ceph-salt reboot

Wichtig

Der Salt Master wird niemals mit den Kommandos ceph-salt update --reboot oder ceph-salt reboot neu gebootet. Wenn der Salt Master neu gebootet werden muss, müssen Sie ihn manuell neu booten.

Führen Sie nach dem Aktualisieren des Clusters ein Bootstrapping des Minimalclusters aus:

root@master # ceph-salt apply

Anmerkung

Wenn das Bootstrapping abgeschlossen ist, verfügt der Cluster über einen Ceph Monitor und einen Ceph Manager.

Mit obigem Kommando wird eine interaktive Benutzeroberfläche geöffnet, die den aktuellen Fortschritt der einzelnen Minions anzeigt.

Abbildung 5.1: Bereitstellung eines Minimalclusters #

 

Tipp: Nicht-interaktiver Modus

Wenn Sie die Konfiguration über ein Skript anwenden müssen, gibt es auch einen nicht-interaktiven Modus für die Bereitstellung. Dies ist auch nützlich, wenn Sie den Cluster von einem Remote-Rechner aus bereitstellen, da das ständige Aktualisieren der Fortschrittsinformationen auf dem Bildschirm über das Netzwerk störend sein kann:

root@master # ceph-salt apply --non-interactive

Nach dem Ausführen des Kommandos ceph-salt apply sollten Sie einen Ceph Monitor und einen Ceph Manager zur Verfügung haben. Sie sollten das Kommando ceph status erfolgreich auf jedem der Minions ausführen können, denen die Admin-Rolle als root oder der Benutzer cephadm mit sudo zugewiesen wurde.

In den nächsten Schritten werden mit cephadm zusätzlich der Ceph Monitor, der Ceph Manager, die OSDs, der Überwachungs-Stack und die Gateways installiert.

Bevor Sie fortfahren, überprüfen Sie die Netzwerkeinstellungen Ihres neuen Clusters. Zu diesem Zeitpunkt wurde die Einstellung public_network (öffentliches Netzwerk) auf der Grundlage dessen, was für /cephadm_bootstrap/mon_ip in der ceph-salt-Konfiguration eingegeben wurde, ausgefüllt. Diese Einstellung wurde jedoch nur auf Ceph Monitor angewendet. Sie können diese Einstellung mit dem folgenden Kommando überprüfen:

root@master # ceph config get mon public_network

Dies ist das Minimum, das Ceph benötigt, um zu funktionieren. Wir empfehlen jedoch, diese public_network-Einstellung global zu machen, was bedeutet, dass sie für alle Arten von Ceph-Daemons gilt und nicht nur für MONs:

root@master # ceph config set global public_network "$(ceph config get mon public_network)"

Anmerkung

Dieser Schritt ist nicht erforderlich. Wenn Sie diese Einstellung jedoch nicht verwenden, überwachen die Ceph-OSDs und andere Daemons (außer Ceph Monitor) auf allen Adressen.

Führen Sie folgendes Kommando aus, wenn Sie möchten, dass Ihre OSDs untereinander über ein komplett separates Netzwerk kommunizieren:

root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"

Durch dieses Kommando wird sichergestellt, dass die in Ihrer Bereitstellung erstellten OSDs von Anfang an das vorgesehene Clusternetzwerk verwenden.

Wenn für Ihren Cluster dichte Knoten festgelegt sind (mehr als 62 OSDs pro Host), stellen Sie sicher, dass Sie genügend Ports für Ceph OSDs zuweisen. Der Standardbereich (6800–7300) lässt derzeit nicht mehr als 62 OSDs pro Host zu. Für einen Cluster mit dichten Knoten müssen Sie die Einstellung ms_bind_port_max auf einen geeigneten Wert anpassen. Jedes OSD verbraucht acht zusätzliche Ports. Bei einem Host, der zum Beispiel für die Ausführung von 96 OSDs eingerichtet ist, werden 768 Ports benötigt. ms_bind_port_max sollte mit folgendem Kommando mindestens auf 7568 festgelegt werden:

root@master # ceph config set osd.* ms_bind_port_max 7568

Sie müssen Ihre Firewall-Einstellungen entsprechend anpassen, damit dies funktioniert. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Mit dem Ceph-Orchestrator-Kommando ceph orch (einer Schnittstelle zum cephadm-Modul) werden die Clusterkomponenten aufgelistet und Ceph-Services auf neuen Cluster-Knoten bereitgestellt.

cephuser@adm > ceph orch status

5.4.1.2 Auflisten von Geräten, Services und Daemons #

 

Führen Sie zum Auflisten aller Datenträgergeräte folgendes Kommando aus:

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

Tipp: Services und Daemons

Service ist ein allgemeiner Begriff für einen Ceph-Service eines bestimmten Typs, zum Beispiel Ceph Manager.

Daemon ist eine bestimmte Instanz eines Service, z. B. ein Prozess mgr.ses-min1.gdlcik, der auf einem Knoten namens ses-min1 ausgeführt wird.

Führen Sie zum Auflisten aller Services, die cephadm kennt, folgendes Kommando aus:

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

Tipp

Sie können die Liste mit dem optionalen Parameter --host auf Services auf einem bestimmten Knoten und mit dem optionalen Parameter --service-type auf Services eines bestimmten Typs beschränken (akzeptable Typen sind mon, osd, mgr, mds und rgw).

Führen Sie folgendes Kommando aus, um alle von cephadm bereitgestellten aktiven Daemons aufzulisten:

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

Tipp

Fragen Sie den Status eines bestimmten Daemons mit --daemon_type und --daemon_id ab. Bei OSDs ist die ID die numerische OSD-ID. Bei MDS ist die ID der Name des Dateisystems:

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

Die Spezifikation der Bereitstellung von Ceph-Services erfolgt am besten durch Erstellen einer YAML-formatierten Datei mit der Spezifikation der Services, die Sie bereitstellen möchten.

5.4.2.1 Erstellen von Servicespezifikationen #

 

Sie können für jede Art von Service eine eigene Spezifikationsdatei erstellen, wie zum Beispiel:

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

Alternativ können Sie mehrere (oder alle) Servicetypen in einer Datei angeben, z. B. cluster.yml, die beschreibt, auf welchen Knoten bestimmte Services ausgeführt werden sollen. Denken Sie daran, einzelne Servicetypen mit drei Bindestrichen (---) zu trennen:

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

Die oben genannten Eigenschaften haben folgende Bedeutung:

service_type

Der Typ des Service. Er kann entweder ein Ceph-Service (mon, mgr, mds, crash, osd oder rbd-mirror), ein Gateway (nfs oder rgw) oder Teil des Überwachungs-Stacks (alertmanager, grafana, node-exporter oder prometheus) sein.

service_id

Der Name des Service. Für Spezifikationen vom Typ mon, mgr, alertmanager, grafana, node-exporter und prometheus ist die Eigenschaft service_id nicht erforderlich.

placement

Gibt an, auf welchen Knoten der Service ausgeführt wird. Weitere Informationen finden Sie in Abschnitt 5.4.2.2, „Erstellen von Platzierungsspezifikationen“.

spec

Zusätzliche Spezifikation, die für den Servicetyp relevant ist.

Tipp: Anwenden spezifischer Services

Ceph-Cluster-Services haben in der Regel eine Reihe von für sie spezifischen Eigenschaften. Beispiele und Details zu den Spezifikationen der einzelnen Services finden Sie in Abschnitt 5.4.3, „Bereitstellen von Ceph-Services“.

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

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

5.4.2.4 Exportieren der Spezifikation eines aktiven Clusters #

 

Obwohl Sie dem Ceph-Cluster Services mithilfe der Spezifikationsdateien bereitgestellt haben (wie in Abschnitt 5.4.2, „Service- und Platzierungsspezifikation“ beschrieben), kann die Konfiguration des Clusters während seines Betriebs von der ursprünglichen Spezifikation abweichen. Möglicherweise haben Sie auch die Spezifikationsdateien versehentlich entfernt.

Führen Sie zum Abrufen der vollständigen Spezifikation eines aktiven Clusters folgendes Kommando aus:

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

Tipp

Sie können die Option --format anhängen, um das Standard-Ausgabeformat yaml zu ändern. Sie können zwischen json, json-pretty oder yaml wählen. Beispiel:

ceph orch ls --export --format json

Sobald der Basiscluster ausgeführt wird, können Sie Ceph-Services auf weiteren Knoten bereitstellen.

5.4.3.1 Bereitstellen von Ceph Monitors und Ceph Managers #

 

Für den Ceph-Cluster werden drei oder fünf MONs bereitgestellt, die auf verschiedenen Knoten verteilt sind. Wenn sich fünf oder mehr Knoten im Cluster befinden, empfehlen wir die Bereitstellung von fünf MONs. Es hat sich bewährt, MGRs auf denselben Knoten wie MONs zu installieren.

Wichtig: Beziehen Sie den Bootstrap-MON ein

Wenn Sie MONs und MGRs bereitstellen, denken Sie daran, den ersten MON einzubeziehen, den Sie bei der Konfiguration des Basisclusters in Abschnitt 5.3.2.5, „Festlegen des ersten MON/MGR-Knotens“ hinzugefügt haben.

Wenden Sie zum Bereitstellen von MONs folgende Spezifikation an:

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Anmerkung

Wenn Sie einen weiteren Knoten hinzufügen müssen, hängen Sie den Hostnamen an dieselbe YAML-Liste an. Beispiel:

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

Wenden Sie auf ähnliche Weise zum Bereitstellen von MONs folgende Spezifikationen an:

Wichtig

Stellen Sie sicher, dass mindestens drei Ceph Manager in jeder Bereitstellung vorhanden sind.

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Tipp

Wenn sich MONs oder MGRs nicht im gleichen Teilnetz befinden, müssen Sie die Teilnetzadressen anhängen. Beispiel:

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 Bereitstellen von Ceph OSDs #

 

Wichtig: Wenn ein Speichergerät verfügbar ist

Ein Speichergerät gilt als verfügbar, wenn alle folgenden Bedingungen erfüllt sind:

• Das Gerät hat keine Partitionen.

• Das Gerät hat keinen LVM-Status.

• Das Gerät ist nicht eingehängt.

• Das Gerät enthält kein Dateisystem.

• Das Gerät enthält kein BlueStore-OSD.

• Das Gerät ist größer als 5 GB.

Wenn die oben genannten Bedingungen nicht erfüllt sind, verweigert Ceph die Bereitstellung derartiger OSDs.

Zum Bereitstellen von OSDs haben Sie zwei Möglichkeiten:

• Weisen Sie Ceph an, alle verfügbaren und nicht verwendeten Speichergeräte zu verbrauchen:

  cephuser@adm > ceph orch apply osd --all-available-devices

• Verwenden Sie DriveGroups (weitere Informationen hierzu finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 13 “Betriebsaufgaben”, Section 13.4.3 “Hinzufügen von OSDs mit der DriveGroups-Spezifikation”), um OSD-Spezifikationen zu erstellen, die Geräte beschreiben, die basierend auf ihren Eigenschaften bereitgestellt werden. Beispiele hierfür sind der Gerätetyp (SSD oder HDD), die Gerätemodellnamen, die Größe oder die Knoten, auf denen die Geräte vorhanden sind. Wenden Sie dann die Spezifikation mit folgendem Kommando an:

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

5.4.3.3 Bereitstellen von Metadatenservern #

 

Für CephFS sind ein oder mehrere Metadata Server (MDS)-Services erforderlich. Wenn Sie ein CephFS erstellen möchten, erstellen Sie zunächst MDS-Server durch Anwenden der folgenden Spezifikation:

Anmerkung

Stellen Sie sicher, dass Sie mindestens zwei Pools, einen für CephFS-Daten und einen für CephFS-Metadaten, erstellt haben, bevor Sie die folgende Spezifikation anwenden.

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Erstellen Sie das CephFS, sobald die MDS funktionsfähig sind:

ceph fs new CEPHFS_NAME metadata_pool data_pool

5.4.3.4 Bereitstellen von Object Gateways #

 

cephadm stellt ein Object Gateway als eine Sammlung von Daemons bereit, die einen bestimmten Bereich und eine Zone verwalten.

Sie können entweder einen Object-Gateway-Service mit einem bereits vorhandenen Bereich und einer bereits vorhandenen Zone verknüpfen (weitere Informationen finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “Object Gateways an mehreren Standorten”), oder Sie können einen nicht vorhandenen REALM_NAME (Bereichsnamen) und ZONE_NAME (Zonennamen) angeben, die dann automatisch erstellt werden, nachdem Sie die folgende Konfiguration angewendet haben:

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 Verwenden des sicheren SSL-Zugangs #

 

Um eine sichere SSL-Verbindung zum Object Gateway zu verwenden, benötigen Sie ein Paar gültiger SSL-Zertifikats- und Schlüsseldateien (weitere Details finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 21 “Ceph Object Gateway”, Section 21.7 “Aktivieren von HTTPS/SSL für Object Gateways”). Sie müssen SSL aktivieren, eine Portnummer für SSL-Verbindungen sowie die SSL-Zertifikats- und Schlüsseldateien angeben.

Nehmen Sie Folgendes in Ihre Spezifikation auf, um SSL zu aktivieren und die Portnummer anzugeben:

spec:
  ssl: true
  rgw_frontend_port: 443

Um das SSL-Zertifikat und den Schlüssel festzulegen, können Sie deren Inhalte direkt in die YAML-Spezifikationsdatei einfügen. Das Pipe-Zeichen (|) am Zeilenende weist den Parser darauf hin, dass er eine mehrzeilige Zeichenkette als Wert erwarten soll. Beispiel:

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

Tipp

Statt den Inhalt der SSL-Zertifikats- und Schlüsseldateien einzufügen, können Sie die Schlüsselwörter rgw_frontend_ssl_certificate: und rgw_frontend_ssl_key: weglassen und sie in die Konfigurationsdatenbank hochladen:

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 Bereitstellung mit einem Untercluster #

 

Mit Unterclustern können Sie die Knoten in Ihren Clustern organisieren, um Workloads zu isolieren und die elastische Skalierung zu erleichtern. Wenden Sie die folgende Konfiguration an, wenn Sie die Bereitstellung mit einem Untercluster durchführen:

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 Bereitstellen von iSCSI-Gateways #

 

iSCSI ist ein Storage Area Network (SAN)-Protokoll, das Clients (genannt Initiators) das Senden von SCSI-Kommandos an SCSI-Speichergeräte (Ziele) auf Remote-Servern ermöglicht.

Wenden Sie die folgende Konfiguration für die Bereitstellung an. Stellen Sie sicher, dass trusted_ip_list die IP-Adressen aller iSCSI-Gateway- und Ceph-Manager-Knoten enthält (wie im folgenden Ausgabebeispiel gezeigt).

Anmerkung

Stellen Sie sicher, dass der Pool erstellt wurde, bevor Sie die folgende Spezifikation anwenden.

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"

Anmerkung

Stellen Sie sicher, dass die für trusted_ip_list aufgelisteten IPs kein Leerzeichen nach der Kommatrennung aufweisen.

5.4.3.5.1 Sichere SSL-Konfiguration #

 

Zur Verwendung einer sicheren SSL-Verbindung zwischen dem Ceph Dashboard und der iSCSI-Ziel-API benötigen Sie ein Paar gültiger SSL-Zertifikate und Schlüsseldateien. Sie können entweder von einer Zertifizierungsstelle ausgestellt oder eigensigniert sein (weitere Informationen finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 10 “Manuelle Konfiguration”, Section 10.1.1 “Erstellen von eigensignierten Zertifikaten”). Nehmen Sie zum Aktivieren von SSL die Einstellung api_secure: true in Ihre Spezifikationsdatei auf:

spec:
  api_secure: true

Um das SSL-Zertifikat und den Schlüssel festzulegen, können Sie den Inhalt direkt in die YAML-Spezifikationsdatei einfügen. Das Pipe-Zeichen (|) am Zeilenende weist den Parser darauf hin, dass er eine mehrzeilige Zeichenkette als Wert erwarten soll. Beispiel:

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 Bereitstellen von NFS Ganesha #

 

cephadm stellt NFS Ganesha unter Verwendung eines vordefinierten RADOS-Pools und eines optionalen Namespace bereit. Wenden Sie zum Bereitstellen von NFS Ganesha folgende Spezifikation an:

Anmerkung

Sie müssen über einen vordefinierten RADOS-Pool verfügen, da sonst der ceph orch apply-Vorgang fehlschlägt. Weitere Informationen zum Erstellen eines Pools finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 18 “Verwalten von Speicher-Pools”, Section 18.1 “Erstellen eines Pools”.

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

• EXAMPLE_NFS mit einer beliebigen Zeichenkette, die den NFS-Export identifiziert.

• EXAMPLE_POOL mit dem Namen des Pools, in dem das NFS-Ganesha-RADOS-Konfigurationsobjekt gespeichert werden soll.

• EXAMPLE_NAMESPACE (optional) mit dem gewünschten Object-Gateway-NFS-Namespace (zum Beispiel ganesha).

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

5.4.3.8 Bereitstellen des Überwachungs-Stacks #

 

Der Überwachungs-Stack besteht aus Prometheus, Prometheus-Exportern, Prometheus Alertmanager und Grafana. Ceph Dashboard nutzt diese Komponenten, um detaillierte Kennzahlen zur Clusternutzung und -leistung zu speichern und zu visualisieren.

Tipp

Wenn für Ihre Bereitstellung benutzerdefinierte oder lokal bereitgestellte Container-Images der Überwachungs-Stack-Services erforderlich sind, finden Sie Informationen hierzu im Book “Betriebs- und Verwaltungshandbuch”, Chapter 16 “Überwachung und Warnungen”, Section 16.1 “Konfigurieren von benutzerdefinierten oder lokalen Images”.

Führen Sie zum Bereitstellen des Überwachungs-Stacks folgende Schritte aus:

1. Aktivieren Sie das Modul prometheus im Ceph-Manager-Daemon. Dadurch werden die internen Ceph-Kennzahlen offengelegt, so dass Prometheus sie lesen kann:

   cephuser@adm > ceph mgr module enable prometheus

   

   Anmerkung

   Stellen Sie sicher, dass dieses Kommando vor dem Bereitstellen von Prometheus ausgeführt wird. Wenn das Kommando vor der Bereitstellung nicht ausgeführt wurde, müssen Sie Prometheus erneut bereitstellen, um die Konfiguration von Prometheus zu aktualisieren:

   cephuser@adm > ceph orch redeploy prometheus

2. Erstellen Sie eine Spezifikationsdatei (z. B. monitoring.yaml) mit einem Inhalt ähnlich dem folgenden:

   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. Wenden Sie die Überwachungsservices mit folgendem Kommando an:

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

   Es kann ein oder zwei Minuten dauern, bis die Überwachungsservices bereitgestellt sind.

Wichtig

Prometheus, Grafana und das Ceph Dashboard sind automatisch so konfiguriert, dass sie miteinander kommunizieren. Dies führt zu einer voll funktionsfähigen Grafana-Integration im Ceph Dashboard, wenn es wie oben beschrieben bereitgestellt wird.

Die einzige Ausnahme von dieser Regel ist die Überwachung mit RBD-Images. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Book “Betriebs- und Verwaltungshandbuch”, Chapter 16 “Überwachung und Warnungen”, Section 16.5.4 “Aktivieren der RBD-Image-Überwachung”.

Das iSCSI-Ziel des Linux-Kernels wurde ursprünglich LIO genannt. Es steht für linux-iscsi.org, die ursprüngliche Domäne und Website des Projekts. Einige Zeit standen für die Linux-Plattform nicht weniger als vier konkurrierende Target-Implementierungen zur Verfügung, doch LIO hat sich schließlich als einziges iSCSI-Referenz-Target durchgesetzt. Der hauptsächliche Kernel-Code für LIO verwendet den einfachen, doch in gewisser Weise zweideutigen Namen „Target“ und unterscheidet dabei zwischen „Target Core“ und einer Vielzahl an Frontend- und Back-End Target-Modulen.

Das am häufigsten verwendete Frontend-Modul ist wohl iSCSI. LIO unterstützt jedoch auch Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) und verschiedene andere Frontend-Protokolle. Zum gegenwärtigen Zeitpunkt unterstützt SUSE Enterprise Storage nur das iSCSI-Protokoll.

Das am häufigsten verwendete Target Back-End-Modul kann einfach jedes verfügbare Blockgerät am Target-Host neu exportieren. Dieses Modul wird iblock genannt. LIO verfügt jedoch auch über ein RBD-spezifisches Back-End-Modul. Es unterstützt den parallelisierten Multipath-E/A-Zugriff auf RBD-Images.

In diesem Abschnitt erhalten Sie einen kurzen Überblick über die iSCSI Initiator, die auf Linux-, Microsoft Windows und VMware-Plattformen verwendet werden.

Die Bereitstellung des Ceph iSCSI Gateways erfolgt nach dem gleichen Verfahren wie die Bereitstellung anderer Ceph-Services, nämlich mit cephadm. Weitere Informationen finden Sie unter Abschnitt 5.4.3.5, „Bereitstellen von iSCSI-Gateways“.

RBD-Images werden im Ceph Store erstellt und anschließend zu iSCSI exportiert. Wir empfehlen zu diesem Zweck einen dedizierten RADOS-Pool. Sie können mit dem Ceph rbd-Kommandozeilenprogramm ein Volume von jedem Host aus erstellen, der eine Verbindung zu Ihrem Speicher-Cluster herstellen kann. Dazu benötigt der Client mindestens eine ceph.conf-Datei mit Mindestkonfiguration und den entsprechenden CephX-Berechtigungsnachweis zur Authentifizierung.

Erstellen Sie ein neues Volume für den späteren Export über iSCSI mit dem Kommando rbd create und geben Sie die Volume-Größe in Megabyte an. Beispiel: Führen Sie zum Erstellen eines Volumes mit 100 GB und der Bezeichnung testvol im Pool iscsi-images folgendes Kommando aus:

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

Zum Exportieren von RBD-Images über iSCSI stehen zwei Möglichkeiten zur Auswahl: die Ceph-Dashboard-Weboberfläche oder das ceph-iscsi-Dienstprogramm „gwcli“. Dieser Abschnitt befasst sich ausschließlich mit „gwcli“, wobei erläutert wird, wie Sie ein iSCSI-Ziel erstellen, mit dem ein RBD-Image über die Kommandozeile exportiert wird.

Anmerkung

RBD-Images mit den folgenden Eigenschaften können nicht über iSCSI exportiert werden:

• Images mit aktivierter Journaling-Funktion

• Images mit einer Stripe-Einheit von weniger als 4096 Byte

Geben Sie den iSCSI-Gateway-Container als root ein:

root # cephadm enter --name CONTAINER_NAME

Starten Sie die Kommandozeilenschnittstelle für das iSCSI Gateway als root:

root # gwcli

Wechseln Sie zu iSCSI-Ziele und erstellen Sie ein Ziel namens iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol:

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

Erstellen Sie die iSCSI-Gateways. Geben Sie hierzu den Namen (name) und die IP-Adresse (ip) des Gateways an:

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

Tipp

Mit dem Kommando help rufen sie eine Liste der verfügbaren Kommandos im aktuellen Konfigurationsknoten ab.

Nehmen Sie das RBD-Image namens testvol in den Pool iscsi-images auf:

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

Ordnen Sie das RBD-Image dem Ziel zu:

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

Anmerkung

Sie können die lokale Konfiguration mit systemnahen Werkzeugen wie targetcli abfragen, jedoch nicht bearbeiten.

Tipp

Mit dem Kommando ls können sie die Konfiguration prüfen. Einige Konfigurationsknoten unterstützen auch das Kommando info, mit dem Sie ausführlichere Informationen erhalten.

Es ist zu beachten, dass die ACL-Authentifizierung standardmäßig aktiviert ist, weshalb der Zugriff auf dieses Ziel noch nicht möglich ist. Weitere Informationen zur Authentifizierung und zur Zugriffssteuerung finden Sie in Abschnitt 6.4.4, „Authentifizierung und Zugriffssteuerung“.

Die iSCSI-Authentifizierung ist flexibel und deckt zahlreiche Authentifizierungsmöglichkeiten ab.

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 Aktivieren der CHAP-Authentifizierung #

 

Neben der ACL-Authentifizierung können Sie die CHAP-Authentifizierung aktivieren. Geben Sie hierzu einen Benutzernamen und ein Passwort für die einzelnen Initiatoren an:

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

Anmerkung

Die Benutzernamen müssen 8 bis 64 Zeichen lang sein und dürfen alphanumerische Zeichen enthalten, ., @, -, _ oder :.

Die Passwörter müssen 12 bis 16 Zeichen lang sein und dürfen alphanumerische Zeichen enthalten, , @, -, _ oder /.

Optional können Sie außerdem die gegenseitige CHAP-Authentifizierung aktivieren. Geben Sie hierzu die Parameter mutual_username und mutual_password im Kommando auth an.

6.4.4.4 Konfigurieren der Ermittlungsauthentifizierung und der gegenseitigen Authentifizierung #

 

Die Ermittlungsauthentifizierung ist unabhängig von den obigen Authentifizierungsverfahren. Es ist ein Berechtigungsnachweis für die Suche erforderlich, die Suche ist optional und sie wird wie folgt konfiguriert:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

Anmerkung

Die Benutzernamen müssen 8 bis 64 Zeichen lang sein und dürfen nur Buchstaben enthalten, ., @, -, _ oder :.

Die Passwörter müssen 12 bis 16 Zeichen lang sein und dürfen nur Buchstaben enthalten, @, -, _ oder /.

Optional können Sie auch die Parameter mutual_username und mutual_password im Kommando discovery_auth angeben.

Die Ermittlungsauthentifizierung wird mit folgendem Kommando deaktiviert:

gwcli >  /iscsi-targets> discovery_auth nochap

ceph-iscsi kann mit erweiterten Parametern konfiguriert werden, die anschließend an das LIO-E/A-Ziel übergeben werden. Die Parameter sind in Ziel- und Datenträger-Parameter aufgeteilt.

Warnung

Soweit nicht anders angegeben, ist es nicht zu empfehlen, die Standardeinstellung dieser Parameter zu ändern.

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

Lesen Sie vor dem Upgrade unbedingt die folgenden Abschnitte durch, um sicherzustellen, dass Sie alle auszuführenden Aufgaben verstehen.

Wir empfehlen dringend, vor Beginn des Upgrades auf SUSE Enterprise Storage 7 alle Cluster-Konfigurationen und -Daten zu sichern. Eine Anleitung zur Sicherung aller Daten finden Sie unter https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.

Falls Sie zuvor ein Upgrade von Version 5 durchgeführt haben, prüfen Sie, ob das Upgrade auf Version 6 erfolgreich abgeschlossen wurde:

Prüfen Sie, ob die Datei /srv/salt/ceph/configuration/files/ceph.conf.import vorhanden ist.

Diese Datei wird durch den Importvorgang während des Upgrades von SUSE Enterprise Storage 5 auf 6 erstellt. Die Option configuration_init: default-import wird in /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml festgelegt.

Wenn configuration_init noch auf default-import festgelegt ist, greift der Cluster auf ceph.conf.import als Konfigurationsdatei zurück, nicht auf die Standarddatei ceph.conf von DeepSea, die aus Dateien in /srv/salt/ceph/configuration/files/ceph.conf.d/ kompiliert wird.

Sie müssen daher ceph.conf.import auf benutzerdefinierte Konfigurationen prüfen und diese Konfigurationen ggf. in eine der Dateien in /srv/salt/ceph/configuration/files/ceph.conf.d/ verschieben.

Entfernen Sie dann die Zeile configuration_init: default-import aus /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Überprüfen Sie, ob alle aktuellen Aktualisierungen von SUSE Linux Enterprise Server 15 SP1 und SUSE Enterprise Storage 6 auf alle Cluster-Knoten angewendet werden:

root # zypper refresh && zypper patch

Überprüfen Sie nach der Anwendung der Aktualisierungen den Zustand des Clusters:

cephuser@adm > ceph -s

Stellen Sie sicher, dass alle Cluster-Knoten Zugriff auf die Software-Repositorys von SUSE Linux Enterprise Server 15 SP2 und SUSE Enterprise Storage 7 sowie auf die Registrierung von Container-Images haben.

In SUSE Enterprise Storage 7 werden die Object Gateways immer mit einem Bereich konfiguriert, was in Zukunft mehrere Standorte ermöglicht (weitere Details finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “Object Gateways an mehreren Standorten”). Wenn Sie in SUSE Enterprise Storage 6 eine Object-Gateway-Konfiguration für einen einzigen Standort verwendet haben, gehen Sie folgendermaßen vor, um einen Bereich hinzuzufügen. Wenn Sie nicht vorhaben, die Funktionalität für mehrere Standorte tatsächlich zu nutzen, ist es in Ordnung, die Standardwerte für die Namen des Bereichs, der Zonengruppe und der Zone zu verwenden.

Um den Object-Gateway-Service zu containerisieren, erstellen Sie dessen Spezifikationsdatei wie in Abschnitt 5.4.3.4, „Bereitstellen von Object Gateways“ beschrieben, und wenden Sie sie an.

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

Im Folgenden wird demonstriert, wie ein bestehender NFS-Ganesha-Service unter Ceph Nautilus in einen NFS-Ganesha-Container unter Ceph Octopus migriert wird.

Warnung

Die folgende Dokumentation setzt voraus, dass Sie für die wichtigsten Ceph-Services bereits erfolgreich ein Upgrade durchgeführt haben.

NFS Ganesha speichert zusätzlich die Konfiguration pro Daemon und exportiert die Konfiguration in einen RADOS-Pool. Den konfigurierten RADOS-Pool finden Sie in der Datei ganesha.conf im Block RADOS_URLS in der Zeile watch_url. Standardmäßig wird dieser Pool ganesha_config genannt.

Bevor Sie eine Migration durchführen, empfehlen wir dringend, eine Kopie der Export- und der Daemon-Konfigurationsobjekte zu erstellen, die sich im RADOS-Pool befinden. Führen Sie das folgende Kommando aus, um den konfigurierten RADOS-Pool zu finden:

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

So listen Sie den Inhalt des RADOS-Pools auf:

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

So kopieren Sie die RADOS-Objekte:

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

Pro Knoten muss ein bestehender NFS-Ganesha-Service gestoppt und anschließend durch einen von cephadm verwalteten Container ersetzt werden.

Die vorhandenen Exporte können auf zwei verschiedene Arten migriert werden:

Nach der erfolgreichen Migration des Service kann der Nautilus-basierte NFS-Ganesha-Service entfernt werden.

Im Gegensatz zu MONs, MGRs und OSDs kann der Metadata Server nicht an Ort und Stelle übernommen werden. Stattdessen müssen Sie sie mit dem Ceph-Orchestrator neu in Containern bereitstellen.

Für ein Upgrade des iSCSI Gateways müssen Sie es mithilfe des Ceph-Orchestrators neu in Containern bereitstellen. Wenn Sie über mehrere iSCSI Gateways verfügen, müssen Sie diese nacheinander neu bereitstellen, um die Ausfallzeit des Service zu reduzieren.