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 sich gemeinsam mit Ceph Monitors auf einem Knoten befinden können. 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-SP3/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-SP3/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.

Wenn Sie config ohne Pfad oder Unterbefehl ausführen, gelangen Sie in eine interaktive ceph-saltceph-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 ceph-saltls-Kommandos von 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:

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

Nehmen Sie alle oder eine Teilmenge der von uns in Kapitel 6, Bereitstellen von Salt bereitgestellten und akzeptierten Salt Minions in die Ceph-Cluster-Konfiguration auf. Sie können die Salt Minions entweder mit ihren vollständigen Namen angeben oder mit einem Globausdruck „*“ und „?“ mehrere Salt Minions gleichzeitig hinzufügen. Verwenden Sie das Unterkommando add unter dem Pfad /ceph_cluster/minions. Mit folgendem Kommando werden alle akzeptierten Salt Minions hinzugefügt:

root@master # ceph-salt config /ceph_cluster/minions add '*'

Überprüfen Sie, ob die angegebenen Salt Minions hinzugefügt wurden:

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]

Geben Sie an, welche Knoten zum Ceph-Cluster gehören und von cephadm verwaltet werden sollen. Beziehen Sie alle Knoten ein, die Ceph-Services ausführen, sowie den Admin-Knoten:

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

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.

Sie müssen angeben, welcher der Salt Minions des Clusters das Bootstrapping des Clusters durchführen soll. Dieser Minion führt dann die Services Ceph Monitor und Ceph Manager als Erster aus.

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]

Zusätzlich müssen Sie die IP-Adresse des Bootstrap-MON im öffentlichen Netzwerk angeben, um sicherzustellen, dass beispielsweise der Parameter public_network korrekt festgelegt wird:

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

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.

cephadm kommuniziert mit den Cluster-Knoten über das SSH-Protokoll. Ein Benutzerkonto namens cephadm wird automatisch erstellt und für die SSH-Kommunikation verwendet.

Sie müssen den privaten und den öffentlichen Teil des SSH-Schlüsselpaars generieren:

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]

Alle Cluster-Knoten müssen ihre Zeit mit einer zuverlässigen Zeitquelle synchronisieren. Es gibt mehrere Szenarien für die Zeitsynchronisierung:

Prüfen Sie die Einstellungen für den Zeitserver:

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]

Weitere Informationen zum Einrichten der Zeitsynchronisierung finden Sie unter https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-ntp.html#sec-ntp-yast.

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

Der Ceph-Cluster benötigt Zugang zu einer Container-Registrierung, damit er containerisierte Ceph-Services herunterladen und bereitstellen kann. Es gibt zwei Möglichkeiten, auf die Registrierung zuzugreifen:

7.2.10.1 Erstellen und Konfigurieren der lokalen Registrierung (optional) #

 

Wichtig

Es gibt zahlreiche Methoden zur Erstellung einer lokalen Registrierung. Die Anweisungen in diesem Abschnitt sind Beispiele für die Erstellung sicherer und unsicherer Registrierungen. Allgemeine Informationen zur Ausführung einer Container-Image-Registrierung finden Sie unter https://documentation.suse.com/sles/15-SP3/single-html/SLES-container/#sec-docker-registry-installation.

Tipp: Platzierung und Portnutzung

Stellen Sie die Registrierung auf einem Rechner bereit, auf den alle Knoten des Clusters zugreifen können. Es wird empfohlen, den Admin-Knoten zu verwenden. Standardmäßig überwacht die Registrierung Port 5000.

Verwenden Sie auf dem Registrierungsknoten folgendes Kommando, um sicherzustellen, dass der Port frei ist:

ss -tulpn | grep :5000

Wenn Port 5000 bereits von anderen Prozessen (z. B. iscsi-tcmu) überwacht wird, suchen Sie einen anderen freien Port, der Port 5000 im Registrierungscontainer zugeordnet werden kann.

Vorgehen 7.1: Erstellen der lokalen Registrierung #

 

1. Vergewissern Sie sich, dass die Erweiterung Containers Module aktiviert ist:

   > SUSEConnect --list-extensions | grep -A2 "Containers Module"
   Containers Module 15 SP3 x86_64 (Activated)

2. Vergewissern Sie sich, dass die folgenden Pakete installiert sind: apache2-utils (für eine sichere Registrierung), cni, cni-plugins, podman, podman-cni-config und skopeo.

3. Beschaffen Sie sich folgende Informationen:

   • Vollqualifizierter Domänenname des Registrierungshosts (REG_HOST_FQDN).

   • Nummer eines verfügbaren Ports, der dem Registrierungscontainer-Port 5000 (REG_HOST_PORT) zugeordnet wird.

   • Ob es sich um eine sichere oder unsichere Registrierung handelt (insecure=[true|false]).

4. Gehen Sie folgendermaßen bei einer unsicheren Registrierung (ohne SSL-Verschlüsselung) vor:

   1. Konfigurieren Sie ceph-salt für die unsichere Registrierung:

      cephuser@adm > ceph-salt config containers/registries_conf enable
      cephuser@adm > ceph-salt config containers/registries_conf/registries \
       add prefix=REG_HOST_FQDN insecure=true \
       location=REG_HOST_PORT:5000

   2. Erstellen Sie zunächst das benötigte Verzeichnis für die unsichere Registrierung (beispielsweise /var/lib/registry) und starten Sie die Registrierung mit dem Befehl podman:

      # mkdir -p /var/lib/registry
      # podman run --privileged -d --name registry \
       -p REG_HOST_PORT:5000 -v /var/lib/registry:/var/lib/registry \
       --restart=always registry:2

   3. Zum Starten der Registrierung nach einem Reboot erstellen Sie eine systemd-Einheitendatei und aktivieren Sie diese:

      > sudo podman generate systemd --files --name registry
      > sudo mv container-registry.service /etc/systemd/system/
      > sudo systemctl enable container-registry.service

5. Führen Sie folgende Schritte aus, um eine sichere Registrierung zu starten:

   1. Erstellen Sie die benötigten Verzeichnisse:

      # mkdir -p /var/lib/registry/{auth,certs}

   2. Generieren Sie ein SSL-Zertifikat:

      # openssl req -newkey rsa:4096 -nodes -sha256 \
       -keyout /var/lib/registry/certs/domain.key -x509 -days 365 \
       -out /var/lib/registry/certs/domain.crt

      

      Anmerkung

      Legen Sie als Wert für CN=[value] den vollqualifizierten Domänennamen des Hosts ([REG_HOST_FQDN]) fest.

   3. Kopieren Sie das Zertifikat auf alle Cluster-Knoten und aktualisieren Sie den Zertifikatcache:

      # salt-cp '*' /var/lib/registry/certs/domain.crt \
       /etc/pki/trust/anchors/
      # salt '*' cmd.shell "update-ca-certificates"

   4. Generieren Sie eine Kombination aus Benutzernamen und Passwort für die Authentifizierung bei der Registrierung:

      # htpasswd2 -bBc /var/lib/registry/auth/htpasswd \
       REG_USERNAME REG_PASSWORD

   5. Starten Sie die sichere Registrierung. Verwenden Sie das Flag REGISTRY_STORAGE_DELETE_ENABLED=true, damit Sie die Images anschließend mit dem Befehl skopeo delete löschen können.

      podman run --name myregistry -p REG_HOST_PORT:5000 \
       -v /var/lib/registry:/var/lib/registry \
       -v /var/lib/registry/auth:/auth:z \
       -e "REGISTRY_AUTH=htpasswd" \
       -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
       -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
       -v /var/lib/registry/certs:/certs:z \
       -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
       -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
       -e REGISTRY_STORAGE_DELETE_ENABLED=true \
       -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true -d registry:2

   6. Testen Sie den sicheren Zugriff auf die Registrierung:

      > curl https://REG_HOST_FQDN:REG_HOST_PORT/v2/_catalog \
       -u REG_USERNAME:REG_PASSWORD

6. Sobald die lokale Registrierung erstellt ist, müssen Sie Container-Images aus der offiziellen SUSE-Registrierung unter registry.suse.com mit der lokalen Registrierung synchronisieren. Sie können das Kommando skopeo sync im Paket skopeo für diesen Zweck verwenden. Weitere Informationen finden Sie auf der Handbuchseite (man 1 skopeo-sync). Die folgenden Beispiele dienen zur Verdeutlichung:

   Beispiel 7.1: Anzeigen von Manifestdateien #

    

   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/ceph | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/grafana | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 | jq .RepoTags

   Beispiel 7.2: Synchronisieren mit einem Verzeichnis #

    

   Synchronisieren aller Ceph-Images:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph /root/images/

   Synchronisieren nur der neuesten Images:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph:latest /root/images/

   Beispiel 7.3: Synchronisieren von Grafana-Images: #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana /root/images/

   Synchronisieren nur der neuesten Grafana-Images:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana:latest /root/images/

   Beispiel 7.4: Synchronisieren der neuesten Prometheus-Images #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 /root/images/

Vorgehen 7.2: Konfigurieren der lokalen Registrierung und der Zugangsdaten #

 

1. Konfigurieren Sie die URL der lokalen Registrierung:

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REG_HOST_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 REG_USERNAME

   cephuser@adm > ceph-salt config /containers/registry_auth/password set REG_PASSWORD

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.

7.2.10.2 Konfigurieren des Pfads zu den Container-Images #

 

Wichtig

In diesem Abschnitt wird beschrieben, wie Sie den Pfad zu den Container-Images des Bootstrap-Clusters konfigurieren können (Bereitstellung der ersten Kombination aus Ceph Monitor und Ceph Manager). Der Pfad gilt nicht für Container-Images zusätzlicher Services, z. B. des Überwachungs-Stacks.

Tipp: Konfigurieren des HTTPS-Proxys

Wenn Sie einen Proxy für die Kommunikation mit dem Container-Registrierungsserver verwenden müssen, führen Sie die folgenden Konfigurationsschritte auf allen Cluster-Knoten aus:

1. Kopieren Sie die Konfigurationsdatei für Container:

   > sudo cp /usr/share/containers/containers.conf /etc/containers/containers.conf

2. Bearbeiten Sie die kopierte Datei, indem Sie die Einstellung http_proxy in den Abschnitt [engine] einfügen, beispielsweise:

   > cat /etc/containers/containers.conf
    [engine]
    http_proxy=proxy.example.com
    [...]

cephadm muss einen gültigen URI-Pfad zu Container-Images kennen. Überprüfen Sie die Standardeinstellung mit folgendem Kommando:

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

Wenn Sie keine alternative oder lokale Registrierung benötigen, geben Sie die standardmäßige SUSE-Container-Registrierung an:

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

Wenn Ihre Bereitstellung einen bestimmten Pfad erfordert, z. B. einen Pfad zu einer lokalen Registrierung, konfigurieren Sie ihn wie folgt:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set LOCAL_REGISTRY_PATH

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:

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

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.

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

Wenn Sie ein separates Clusternetzwerk betreiben, müssen Sie optional die IP-Adresse des Clusternetzwerks festlegen, gefolgt von dem Teil der Teilnetzmaske nach dem Schrägstrich, zum Beispiel 192.168.10.22/24.

Führen Sie zum Aktivieren von cluster_network (Clusternetzwerk) folgende Kommandos aus:

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

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

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

Mit folgendem Kommando werden der aktuelle Modus und Status des Ceph-Orchestrators angezeigt.

cephuser@adm > ceph orch status

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. Akzeptiert werden die Typen 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

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:

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 8.3, „Bereitstellen von Ceph-Services“.

Zum Bereitstellen von Ceph-Services muss cephadm wissen, auf welchen Knoten sie bereitgestellt werden sollen. Verwenden Sie die Eigenschaft placement und führen Sie die Host-Kurznamen der Knoten auf, für die der Service gilt:

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

Nachdem Sie eine vollständige cluster.yml-Datei mit Spezifikationen zu allen Services und deren Platzierung erstellt haben, können Sie den Cluster mit folgendem Kommando anwenden:

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

Führen Sie zum Anzeigen des Clusterstatus das Kommando ceph orch aus. Weitere Informationen finden Sie unter Abschnitt 8.1.1, „Anzeigen des Orchestrator-Status“.

Obwohl Sie dem Ceph-Cluster Services mithilfe der Spezifikationsdateien bereitgestellt haben (wie in Abschnitt 8.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

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

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:

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

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

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

8.3.4.1.1 Konfigurieren des Object Gateway zur Überwachung von Port 443 und 80 #

 

Führen Sie die folgenden Schritte aus, um das Object Gateway zur Überwachung beider Ports, Port 443 (HTTPS) und Port 80 (HTTP), zu konfigurieren:

Anmerkung

Die Kommandos in diesem Verfahren verwenden den Standardwert default für den Bereich und die Zone.

1. Stellen Sie das Object Gateway bereit, indem Sie eine Spezifikationsdatei angeben. Weitere Informationen zur Object-Gateway-Spezifikation finden Sie in Abschnitt 8.3.4, „Bereitstellen von Object Gateways“. Verwenden Sie den folgenden Befehl:

   cephuser@adm > ceph orch apply -i SPEC_FILE

2. Wenn SSL-Zertifikate nicht in der Spezifikationsdatei enthalten sind, fügen Sie sie mit dem folgenden Kommando hinzu:

   cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. Ändern Sie den Standardwert der Option rgw_frontends:

   cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
    "beast port=80 ssl_port=443"

4. Entfernen Sie die von cephadm erstellte spezifische Konfiguration. Stellen Sie fest, für welches Ziel die Option rgw_frontends konfiguriert wurde, indem Sie dieses Kommando ausführen:

   cephuser@adm > ceph config dump | grep rgw

   Wenn das Ziel beispielsweise client.rgw.default.default.node4.yiewdu lautet, entfernen Sie den aktuellen spezifischen Wert für rgw_frontends:

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   Tipp

   Statt einen Wert für rgw_frontends zu entfernen, können Sie ihn auch angeben. Beispiel:

   cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
    rgw_frontends "beast port=80 ssl_port=443"

5. Starten Sie Object Gateways neu:

   cephuser@adm > ceph orch restart rgw.default.default

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

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.

spec:
  api_secure: true

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

Wichtig

NFS Ganesha unterstützt NFS-Version 4.1 und neuer. NFS Ganesha unterstützt nicht NFS-Version 3.

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

Der Service rbd-mirror synchronisiert RADOS-Blockgeräte-Images zwischen zwei Ceph-Clustern (weitere Details finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 20 “RADOS-Blockgerät”, Section 20.4 “RBD-Image-Spiegel”). Stellen Sie rbd-mirror mit folgender Spezifikation bereit:

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

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:

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

iSCSI ist eine Implementierung des Small Computer System Interface (SCSI)-Kommandos, das mit dem in RFC 3720 angegebenen Internet Protocol (IP) festgelegt wird. iSCSI ist als Service implementiert, in dem ein Client (der Initiator) über eine Sitzung auf TCP-Port 3260 mit einem Server (dem Target) kommuniziert. Die IP-Adresse und der Port eines iSCSI-Ziels werden als iSCSI Portal bezeichnet, wobei ein Ziel über einen oder mehrere Portale sichtbar gemacht werden kann. Die Kombination aus einem Ziel und einem oder mehreren Portalen wird als Zielportalgruppe (Target Portal Group, TPG) bezeichnet.

Das zugrunde liegende Daten-Link-Schicht-Protokoll für iSCSI ist meistens Ethernet. Genauer gesagt, moderne iSCSI-Infrastrukturen verwenden 10 GigE-Ethernet oder schnellere Netzwerke für optimalen Durchsatz. 10 Gigabit Ethernet-Konnektivität zwischen dem iSCSI Gateway und dem Back-End Ceph-Cluster wird dringend empfohlen.

ceph-iscsi vereint die Vorteile von RADOS Block Devices mit der universellen Vielseitigkeit von iSCSI. Durch Anwenden von ceph-iscsi auf einem iSCSI-Zielhost (als iSCSI Gateway bezeichnet) kann jede Anwendung, die die Blockspeicherung nutzen muss, von Ceph profitieren, auch wenn sie kein Ceph-Client-Protokoll kennt. Stattdessen können Benutzer iSCSI oder ein beliebiges anderes Target Frontend-Protokoll verwenden, um eine Verbindung zu einem LIO Target herzustellen, das alle Target E/A in RBD-Speicheroperationen überträgt.

Abbildung 9.1: Ceph-Cluster mit einem einzigen iSCSI Gateway #

 

ceph-iscsi ist von Natur aus hochverfügbar und unterstützt Multipath-Operationen. Somit können Downstream Initiator Hosts mehrere iSCSI Gateways für Hochverfügbarkeit sowie Skalierbarkeit verwenden. Bei der Kommunikation mit einer iSCSI-Konfiguration mit mehr als einem Gateway sorgen Initiator möglicherweise für eine Lastausgleich von iSCSI-Anforderungen über mehrere Gateways hinweg. Falls ein Gateway ausfällt und zeitweise nicht erreichbar ist oder zu Wartungszwecken deaktiviert wird, werden E/A-Operationen transparent über ein anderes Gateway weiter ausgeführt.

Abbildung 9.2: Ceph-Cluster mit mehreren iSCSI Gateways #

 

Eine Mindestkonfiguration von SUSE Enterprise Storage 7.1 mit ceph-iscsi setzt sich aus folgenden Komponenten zusammen:

Eine empfohlene Produktionskonfiguration von SUSE Enterprise Storage 7.1 mit ceph-iscsi besteht aus:

In diesem Abschnitt werden die Schritte zum Installieren und Konfigurieren eines iSCSI Gateways zusätzlich zu SUSE Enterprise Storage beschrieben.

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

9.1.4.3 Exportieren von RBD-Images über iSCSI #

 

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:

# cephadm enter --name CONTAINER_NAME

Starten Sie die Kommandozeilenschnittstelle für das iSCSI Gateway als 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 9.1.4.4, „Authentifizierung und Zugriffssteuerung“.

9.1.4.4 Authentifizierung und Zugriffssteuerung #

 

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

9.1.4.4.1 Deaktivieren der ACL-Authentifizierung #

 

Keine Authentifizierung bedeutet, dass jeder Initiator·auf alle LUNs·im entsprechenden Ziel zugreifen kann.· Sie können Keine Authentifizierung aktivieren, indem Sie die ACL-Authentifizierung deaktivieren:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

9.1.4.4.2 Verwenden der ACL-Authentifizierung #

 

Bei der ACL-Authentifizierung anhand des Initiatornamens dürfen lediglich die definierten Initiatoren eine Verbindung herstellen. So definieren Sie einen Initiator:

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

Definierte Initiatoren können eine Verbindung herstellen, erhalten den Zugriff jedoch nur auf die RBD-Images, die dem Initiator explizit hinzugefügt wurden:

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

9.1.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, ., @, -, _ oder : enthalten.

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.

9.1.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, ., @, -, _ oder : enthalten.

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

9.1.4.5 Konfigurieren von erweiterten Einstellungen #

 

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.

9.1.4.5.1 Anzeigen der Zieleinstellungen #

 

Mit dem Kommando info rufen Sie den Wert dieser Einstellungen ab:

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

Mit dem Kommando reconfigure ändern Sie eine Einstellung:

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

Die folgenden Ziel-Einstellungen stehen zur Auswahl:

default_cmdsn_depth

Standardmäßige CmdSN (Command Sequence Number)-Tiefe. Beschränkt die Anzahl der Anforderungen, die für einen iSCSI Initiator zu einem beliebigen Zeitpunkt ausstehend sein können.

default_erl

Standardmäßige Fehlerwiederherstellungsstufe.

login_timeout

Wert der Zeitüberschreitung bei der Anmeldung in Sekunden.

netif_timeout

NIC-Fehler-Zeitüberschreitung in Sekunden.

prod_mode_write_protect

Wert 1 verhindert das Schreiben in LUNs.

9.1.4.5.2 Anzeigen der Datenträgereinstellungen #

 

Mit dem Kommando info rufen Sie den Wert dieser Einstellungen ab:

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

Mit dem Kommando reconfigure ändern Sie eine Einstellung:

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Die folgenden Datenträger-Einstellungen stehen zur Auswahl:

block_size

Blockgröße des zugrundeliegenden Geräts.

emulate_3pc

Wert 1 aktiviert das Drittanbieterexemplar.

emulate_caw

Wert 1 aktiviert „Vergleichen“ und „Schreiben“.

emulate_dpo

Wert 1 schaltet „Disable Page Out“ ein.

emulate_fua_read

Wert 1 aktiviert das Lesen von „Force Unit Access“ (Zugriff auf Einheit erzwingen).

emulate_fua_write

Wert 1 aktiviert das Schreiben von „Force Unit Access“ (Zugriff auf Einheit erzwingen).

emulate_model_alias

Wert 1 verwendet den Back-End-Gerätenamen für den Modell-Alias.

emulate_pr

Beim Wert 0 ist die Unterstützung für SCSI-Reservierungen (auch permanente Gruppenreservierungen) deaktiviert. Ist diese Option deaktiviert, kann das iSCSI Gateway den Reservierungsstatus ignorieren, sodass die Anforderungslatenz verbessert wird.

Tipp

Wenn die iSCSI-Initiatoren keine Unterstützung für die SCSI-Reservierung benötigen, wird empfohlen, den Wert 0 für backstore_emulate_pr festzulegen.

emulate_rest_reord

Bei Wert 0 weist der Queue Algorithm Modifier (Warteschlangenalgorithmus-Modifizierer) die Option „Restricted Reordering“ auf.

emulate_tas

Wert 1 aktiviert „Task Aborted Status“.

emulate_tpu

Wert 1 aktiviert „Thin Provisioning Unmap“.

emulate_tpws

Wert 1 aktiviert „Thin Provisioning Write Same“.

emulate_ua_intlck_ctrl

Wert 1 aktiviert „Unit Attention Interlock“.

emulate_write_cache

Wert 1 schaltet „Write Cache Enable“ ein.

enforce_pr_isids

Wert 1 erzwingt ISIDs für permanente Reservierungen.

is_nonrot

Bei Wert 1 ist der Backstore ein sich nicht drehendes Gerät.

max_unmap_block_desc_count

Maximale Anzahl der Blockbeschreibungen für UNMAP.

max_unmap_lba_count:

Maximale Anzahl der LBAs für UNMAP.

max_write_same_len

Maximale Länge für WRITE_SAME.

optimal_sectors

Optimale Anforderungsgröße in Sektoren.

pi_prot_type

DIF-Schutz-Typ.

queue_depth

Warteschlangentiefe.

unmap_granularity

UNMAP-Granularität.

unmap_granularity_alignment

Abstimmung der UNMAP-Granularität.

force_pr_aptpl

Ist diese Option aktiviert, schreibt LIO stets den Status der permanenten Reservierung in den permanenten Speicher, unabhängig davon, ob der Client diesen Status mit aptpl=1 angefordert hat. Dies wirkt sich nicht auf das Kernel-RBD-Back-End für LIO aus – hier wird der PR-Status in jedem Fall beibehalten. Im Idealfall sollte die Option target_core_rbd den Wert „1“ erzwingen und einen Fehler auslösen, wenn ein Benutzer versucht, die Option über die Konfiguration zu deaktivieren.

unmap_zeroes_data

Diese Option gibt an, ob LIO den SCSI-Initiatoren gegenüber LBPRZ bekannt gibt, also dass Nullen aus einem Bereich nach UNMAP oder WRITE SAME mit einem Bit zum Aufheben der Zuordnung gelesen werden.

ceph-iscsi unterstützt sowohl den Backstore rbd (kernelbasiert) als auch den Backstore user:rbd (tcmu-runner), sodass die gesamte Verwaltung transparent und unabhängig vom Backstore abläuft.

Warnung: Technologievorschau

tcmu-runner-basierte iSCSI-Gateway-Bereitstellungen sind aktuell ein Technology Preview.

Im Gegensatz zur Kernel-basierten iSCSI-Gateway-Bereitstellung unterstützen tcmu-runner-basierte iSCSI Gateways keine Multipath E/A oder permanente SCSI-Reservierungen.

Soll ein RADOS Block Device.Image mit tcmu-runner exportiert werden, müssen Sie lediglich den user:rbd-Backstore angeben, wenn Sie den Datenträger anhängen:

gwcli >  /disks> attach rbd/testvol backstore=user:rbd

Anmerkung

Zur Verwendung von tcmu-runner muss die Funktion exclusive-lock für das exportierte RBD-Image aktiviert sein.

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

Es wird dringend empfohlen, die gesamte Cluster-Konfiguration und alle Daten zu sichern, bevor Sie mit dem Upgrade auf SUSE Enterprise Storage 7.1 beginnen. Eine Anleitung zur Sicherung aller Daten finden Sie unter https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

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:

# zypper refresh && zypper patch

Tipp

Weitere Informationen zum Aktualisieren der Cluster-Knoten finden Sie unter https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates.

Starten Sie nach Anwendung der Aktualisierungen den Salt Master neu, synchronisieren Sie neue Salt-Module und überprüfen Sie den Cluster-Zustand:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

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

In SUSE Enterprise Storage 7.1 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 zu nutzen, können Sie default für die Namen des Bereichs, der Zonengruppe und der Zone verwenden.

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

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

Wichtig

NFS Ganesha unterstützt NFS-Version 4.1 und neuer. NFS Ganesha unterstützt nicht NFS-Version 3.

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.

Es wird dringend empfohlen, vor einer Migration eine Kopie der Export- und Daemon-Konfigurationsobjekte im RADOS-Pool zu erstellen. Zum Auffinden des konfigurierten RADOS-Pools führen Sie folgendes Kommando aus:

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

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

Es wird dringend empfohlen, die gesamte Cluster-Konfiguration und alle Daten zu sichern, bevor Sie mit dem Upgrade beginnen. Anweisungen zur Sicherung aller Daten finden Sie im Book “Betriebs- und Verwaltungshandbuch”, Chapter 15 “Sichern und Wiederherstellen”.

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