Öffnen Sie zum Anmelden bei Ceph Dashboard die zugehörige URL (unter Angabe der Portnummer). Führen Sie zum Abrufen der Adresse folgendes Kommando aus:

cephuser@adm > ceph mgr services | grep dashboard
"dashboard": "https://host:port/",

Das Kommando gibt die URL für den Standort des Ceph Dashboards zurück. Falls Sie Probleme mit diesem Kommando haben, finden Sie eine Lösung im Book “Troubleshooting Guide”, Chapter 10 “Troubleshooting the Ceph Dashboard”, Section 10.1 “Locating the Ceph Dashboard”.

Abbildung 2.1: Ceph-Dashboard-Anmeldebildschirm #

 

Melden Sie sich mit dem Berechtigungsnachweis an, den Sie während der Cluster-Bereitstellung erstellt haben (weitere Informationen finden Sie im Book “Implementierungsleitfaden”, Chapter 5 “Bereitstellung mit cephadm”, Section 5.3.2.9 “Konfigurieren des Berechtigungsnachweises für die Anmeldung am Ceph Dashboard”).

Tipp: Benutzerdefiniertes Benutzerkonto

Wenn Sie nicht über das Standardkonto admin auf das Ceph Dashboard zugreifen möchten, erstellen Sie ein benutzerdefiniertes Benutzerkonto mit Administratorrechten. Weitere Informationen finden Sie in Kapitel 11, Verwalten von Benutzern und Rollen über die Kommandozeile.

Die Benutzeroberfläche des Dashboards ist grafisch in mehrere Blöcke unterteilt: Dienstprogramm-Menü oben rechts auf dem Bildschirm, Hauptmenü auf der linken Seite und Inhaltsbereich.

Abbildung 2.2: Ceph-Dashboard-Startseite #

 

Oben rechts im Bildschirm befindet sich ein Dienstprogramm-Menü. Es enthält allgemeine Aufgaben, die eher mit dem Dashboard selbst zusammenhängen als mit dem Ceph-Cluster. Über die Optionen gelangen Sie zu den folgenden Themen:

Das Hauptmenü des Dashboards ist links im Bildschirm angeordnet. Hier finden Sie die folgenden Themen:

Der Inhaltsbereich belegt den Hauptteil des Dashboard-Bildschirms. Die Dashboard-Startseite enthält zahlreiche nützliche Widgets, mit denen Sie sich rasch über den aktuellen Status des Clusters, die Kapazität und die Leistung informieren können.

Im Ceph Dashboard arbeiten Sie oft mit Listen, beispielsweise Listen von Pools, OSD-Knoten oder RBD-Geräten. Alle Listen werden standardmäßig automatisch alle fünf Sekunden aktualisiert. Mit den folgenden allgemeinen Widgets verwalten Sie diese Listen oder passen Sie an:

Mit lösen Sie eine manuelle Aktualisierung der Liste aus.

Klicken Sie auf , um einzelne Tabellenspalten anzuzeigen oder auszublenden.

Klicken Sie auf und geben Sie ein (oder wählen Sie aus), wie viele Zeilen auf einer einzelnen Seite angezeigt werden sollen.

Klicken Sie in das Feld und filtern Sie die Zeilen, indem Sie die Zeichenkette eingeben, nach der gesucht werden soll.

Ändern Sie mit die aktuell angezeigte Seite, wenn die Liste mehrere Seiten umfasst.

Die einzelnen Dashboard-Widgets enthalten spezielle Statusinformationen zu einem bestimmten Aspekt eines aktiven Ceph-Clusters. Einige Widgets sind aktive Links. Wenn Sie darauf klicken, werden Sie zu einer detaillierten Seite des jeweiligen Themas weitergeleitet.

Tipp: Weitere Details durch Bewegen des Mauszeigers

Bei einigen grafischen Widgets werden zusätzliche Informationen angezeigt, wenn Sie mit der Maus darauf zeigen.

2.6.1 Status-Widgets #

 

Status-Widgets geben Ihnen einen kurzen Überblick über den aktuellen Status des Clusters.

Abbildung 2.3: Status-Widgets #

 

Cluster-Status

Grundlegende Informationen zum Zustand des Clusters.

Hosts

Gesamtanzahl der Cluster-Knoten.

Monitors

Anzahl der aktiven Monitors und deren Quorum.

OSDs

Gesamtanzahl der OSDs sowie Anzahl der als up und in gekennzeichneten OSDs.

Manager

Anzahl der aktiven und im Standby befindlichen Ceph Manager Daemons.

Object Gateways

Anzahl der aktiven Object Gateways.

Metadata Server

Anzahl der Metadatenserver.

iSCSI Gateways

Anzahl der konfigurierten iSCSI-Gateways.

2.6.2 Kapazitäts-Widgets #

 

Kapazitäts-Widgets bieten kurze Informationen zur Speicherkapazität.

Abbildung 2.4: Kapazitäts-Widgets #

 

Rohkapazität

Verhältnis der belegten und verfügbaren Rohspeicherkapazität.

Objekte

Anzahl der im Cluster gespeicherten Datenobjekte.

Platzierungsgruppenstatus

Diagramm der Platzierungsgruppe gemäß ihrem Status.

Pools

Anzahl der Pools im Cluster.

Platzierungsgruppen pro OSD

Durchschnittliche Anzahl der Platzierungsgruppen pro OSD.

2.6.3 Leistungs-Widgets #

 

Leistungs-Widgets liefern grundlegende Leistungsdaten der Ceph-Clients.

Abbildung 2.5: Leistungs-Widgets #

 

Client-Lese-/Schreibvorgänge

Die Anzahl der Lese-/Schreibvorgänge des Clients pro Sekunde.

Clientdurchsatz

Die Datenmenge in Byte pro Sekunde, die zu und von Ceph-Clients übertragen wird.

Wiederherstellungsdurchsatz

Der pro Sekunde wiederhergestellte Datendurchsatz.

Scrubbing

Zeigt den Scrubbing-Status (weitere Informationen finden Sie in Abschnitt 17.4.9, „Scrubbing einer Platzierungsgruppe“). Er lautet entweder inaktiv, aktiviert oder aktiv.

Klicken Sie im Dienstprogramm-Menü auf und wählen Sie Benutzerverwaltung.

Die Liste enthält den Benutzernamen, den vollständigen Namen und die E-Mail-Adresse jedes Benutzers sowie eine Liste der zugewiesenen Rollen. Zudem ist angegeben, ob die Rolle aktiviert ist und wann das Passwort abläuft.

Abbildung 3.1: Benutzerverwaltung #

 

Klicken Sie zum Hinzufügen eines neuen Benutzers oben links in der Tabellenüberschrift auf Erstellen. Geben Sie den Benutzernamen, das Passwort sowie optional den vollständigen Namen und eine E-Mail-Adresse ein.

Abbildung 3.2: Hinzufügen eines Benutzers #

 

Klicken Sie auf das kleine Stiftsymbol und weisen Sie dem Benutzer vordefinierte Rollen zu. Bestätigen Sie mit Benutzer erstellen.

Klicken Sie zum Bearbeiten der Details zu einem Benutzer auf dessen Tabellenzeile und wählen Sie Bearbeiten aus. Bestätigen Sie mit Benutzer bearbeiten.

Klicken Sie auf die Tabellenzeile des Benutzers, um die Auswahl zu markieren. Wählen Sie die Dropdown-Schaltfläche neben Bearbeiten und dann in der Liste die Option Löschen aus, um das Benutzerkonto zu löschen. Aktivieren Sie das Kontrollkästchen Ja, ich bin sicher und bestätigen Sie mit Benutzer löschen.

Klicken Sie im Dienstprogramm-Menü auf und wählen Sie Benutzerverwaltung. Klicken Sie dann auf die Registerkarte Rollen.

Die Liste enthält den Namen und die Beschreibung der einzelnen Rollen sowie einen Hinweis, ob die betreffende Rolle eine Systemrolle ist.

Abbildung 3.3: Benutzerrollen #

 

Klicken Sie zum Hinzufügen einer neuen benutzerdefinierten Rolle oben links in der Tabellenüberschrift auf Erstellen. Geben Sie den Namen und die Beschreibung ein und wählen Sie neben Berechtigungen die entsprechenden Berechtigungen aus.

Tipp: Bereinigen benutzerdefinierter Rollen

Wenn Sie benutzerdefinierte Rollen erstellen und den Ceph-Cluster später mit dem Kommando ceph-salt purge entfernen möchten, müssen Sie zunächst die benutzerdefinierten Rollen bereinigen. Weitere Informationen finden Sie in Abschnitt 13.9, „Vollständiges Entfernen eines Ceph-Clusters“.

Abbildung 3.4: Hinzufügen einer Rolle #

 

Tipp: Mehrfache Aktivierung

Wenn Sie das Kontrollkästchen vor dem Namen eines Themas aktivieren, aktivieren Sie damit alle Berechtigungen für dieses Thema. Wenn Sie das Kontrollkästchen Alle aktivieren, aktivieren Sie damit alle Berechtigungen für sämtliche Themen.

Bestätigen Sie mit Rolle erstellen.

Klicken Sie auf die Tabellenzeile eines Benutzers. Wählen Sie oben links in der Tabellenüberschrift die Option Bearbeiten aus, um die Beschreibung und die Berechtigungen der benutzerdefinierten Rolle zu bearbeiten. Bestätigen Sie mit Rolle bearbeiten.

Klicken Sie auf die Tabellenzeile einer Rolle, um die Auswahl zu markieren. Wählen Sie die Dropdown-Schaltfläche neben Bearbeiten und dann in der Liste die Option Löschen aus, um die Rolle zu löschen. Aktivieren Sie das Kontrollkästchen Ja, ich bin sicher und bestätigen Sie mit Rolle löschen.

Mit Cluster › Hosts rufen Sie eine Liste der Cluster-Knoten ab.

Abbildung 4.1: Hosts #

 

Klicken Sie auf den Dropdown-Pfeil neben einem Knotennamen in der Spalte Hostname, um die Leistungsdetails des Knotens anzuzeigen.

Die Spalte Services enthält alle Daemons, die auf den einzelnen zugehörigen Knoten ausgeführt werden. Zum Abrufen der ausführlichen Konfiguration eines Daemons klicken Sie auf den Namen dieses Daemons.

Mit Cluster › Inventar rufen Sie eine Liste der Geräte ab. Die Liste enthält den Gerätepfad, den Typ, die Verfügbarkeit, den Hersteller, das Modell, die Größe und die OSDs.

Klicken Sie in der Spalte Hostname einen Knotennamen zur Auswahl an. Klicken Sie nach der Auswahl auf Identifizieren, um das Gerät zu identifizieren, auf dem der Host ausgeführt wird. Dadurch wird das Gerät angewiesen, die LEDs blinken zu lassen. Wählen Sie für die Dauer dieser Aktion zwischen 1, 2, 5, 10 und 15 Minuten. Klicken Sie auf Ausführen.

Abbildung 4.2: Services #

 

Mit Cluster › Monitore rufen Sie eine Liste der Cluster-Knoten mit aktiven Ceph-Monitoren ab. Das Inhaltsfenster ist in zwei Ansichten unterteilt: Status und In Quorum oder Nicht in Quorum.

Die Tabelle Status enthält allgemeine Statistiken zu aktiven Ceph Monitors, einschließlich der folgenden:

Die Bereiche In Quorum und Nicht in Quorum enthalten die Namen der einzelnen Monitore, die Rangnummer, die öffentliche IP-Adresse und die Anzahl der offenen Sitzungen.

Zum Abrufen der Ceph Monitor-Konfiguration eines Knotens klicken Sie auf den Namen dieses Knotens in der Spalte Name.

Abbildung 4.3: Ceph Monitors #

 

Klicken Sie auf Cluster › Services, um Details zu jedem der verfügbaren Services anzuzeigen: crash, Ceph Manager und Ceph Monitors. Die Liste enthält den Namen des Container-Images, die ID des Container-Images, den Status der Services, die ausgeführt werden, sowie die Größe und den Zeitpunkt der letzten Aktualisierung.

Klicken Sie auf den Dropdown-Pfeil neben einem Servicenamen in der Spalte Service, um die Details des Daemons anzuzeigen. Die Detailliste enthält den Hostnamen, den Daemon-Typ, die Daemon-ID, die Container-ID, den Container-Image-Namen, die Container-Image-ID, die Versionsnummer, den Status und den Zeitpunkt der letzten Aktualisierung.

Abbildung 4.4: Services #

 

Mit Cluster › OSDs rufen Sie eine Liste der Knoten mit aktiven OSD-Daemons ab. Die Liste enthält die Namen der einzelnen Knoten, die ID, den Status, die Geräteklasse, die Anzahl der Platzierungsgruppen, die Größe, die Auslastung, ein Diagramm der Lese-/Schreibvorgänge im Zeitverlauf sowie die Rate der Lese-/Schreibvorgänge pro Sekunde.

Abbildung 4.5: Ceph OSDs #

 

Wählen Sie im Dropdown-Menü der clusterweiten Konfiguration in der Tabellenüberschrift den Eintrag Flags aus, um ein Popup-Fenster zu öffnen. Dieser enthält eine Liste von Flags, die für den gesamten Cluster gelten. Sie können einzelne Flags aktivieren oder deaktivieren und dies dann mit Absenden bestätigen.

Abbildung 4.6: OSD-Flags #

 

Wählen Sie im Dropdown-Menü der clusterweiten Konfiguration in der Tabellenüberschrift den Eintrag Wiederherstellungspriorität aus, um ein Popup-Fenster zu öffnen. Dieser enthält eine Liste von OSD-Wiederherstellungsprioritäten, die für den gesamten Cluster gelten. Sie können das bevorzugte Prioritätsprofil aktivieren und die einzelnen Werte darunter anpassen. Bestätigen Sie mit Absenden.

Abbildung 4.7: OSD-Wiederherstellungspriorität #

 

Klicken Sie auf den Dropdown-Pfeil neben einem Knotennamen in der Spalte Host, um eine erweiterte Tabelle mit Details zu den Geräteeinstellungen und der Leistung anzuzeigen. Auf den verschiedenen Karteireitern finden Sie Listen der Attribute, der Metadaten, des Laufwerkszustands, der Leistungsindikatoren sowie ein grafisches Histogramm der Schreib- und Lesevorgänge und die Leistungsdetails.

Abbildung 4.8: OSD-Details #

 

Tipp: Ausführen bestimmter Aufgaben für OSDs

Nach dem Klicken auf einen OSD-Knotennamen wird die Tabellenzeile hervorgehoben. Dies bedeutet, dass Sie nun eine Aufgabe auf dem Knoten ausführen können. Sie können eine der folgenden Aktionen ausführen: Bearbeiten, Erstellen, Scrub, Umfassender Scrub, Neu gewichten, Mit Kommando ‚Out‘ markieren, Mit Kommando ‚In‘ markieren, Als ausgefallen markieren, Als verloren markieren, Bereinigen, Vernichten oder Löschen.

Klicken Sie auf den Abwärtspfeil oben links in der Tabellenüberschrift neben der Schaltfläche Erstellen und wählen Sie die gewünschte Aufgabe aus.

Mit Cluster › Konfiguration erhalten Sie eine umfassende Liste der Ceph-Cluster-Konfigurationsoptionen. Die Liste enthält den Namen der Option, eine Kurzbeschreibung und die aktuellen und Standardwerte sowie die Angabe, ob die Option bearbeitbar ist.

Abbildung 4.14: Cluster-Konfiguration #

 

Klicken Sie auf den Dropdown-Pfeil neben einer Konfigurationsoption in der Spalte Name, um eine erweiterte Tabelle mit detaillierten Informationen über die Option anzuzeigen, z. B. den Wertetyp, die minimal und maximal zulässigen Werte, ob sie zur Laufzeit aktualisiert werden kann und vieles mehr.

Ist eine bestimmte Option hervorgehoben, können Sie ihre(n) Wert(e) mit der Schaltfläche Bearbeiten oben links in der Tabellenüberschrift bearbeiten. Bestätigen Sie die Änderungen mit Speichern.

Mit Cluster › CRUSH map rufen Sie eine CRUSH-Zuordnung des Clusters ab. Weitere allgemeine Informationen zu CRUSH-Zuordnungen finden Sie in Abschnitt 17.5, „Umgang mit der CRUSH-Zuordnung“.

Wenn Sie auf den Root, die Knoten oder die einzelnen OSDs klicken, werden ausführlichere Informationen angezeigt, z. B. das Crush-Gewicht, die Tiefe im Zuordnungsbaum, die Geräteklasse des OSD und vieles mehr.

Abbildung 4.15: CRUSH Map #

 

Mit Cluster › Manager-Module rufen Sie eine Liste der verfügbaren Ceph-Manager-Module ab. Die Zeilen enthalten jeweils einen Modulnamen sowie einen Hinweis, ob das Modul derzeit aktiviert ist oder nicht.

Abbildung 4.16: Manager-Module #

 

Klicken Sie auf den Dropdown-Pfeil neben einem Modul in der Spalte Name, um in der nachfolgenden Tabelle Details eine erweiterte Tabelle mit detaillierten Einstellungen anzuzeigen. Zum Bearbeiten klicken Sie oben links in der Tabellenüberschrift auf die Schaltfläche Bearbeiten. Bestätigen Sie die Änderungen mit Aktualisieren.

Klicken Sie auf den Dropdown-Pfeil neben der Schaltfläche Bearbeiten oben links in der Tabellenüberschrift, um ein Modul zu aktivieren oder zu deaktivieren.

Mit Cluster › Logs rufen Sie eine Liste der letzten Protokolleinträge des Clusters ab. Die Zeilen enthalten jeweils einen Zeitstempel, den Typ des Protokolleintrags sowie die protokollierte Meldung selbst.

Auf der Registerkarte Revisionsprotokoll finden Sie die Protokolleinträge des Revisions-Subsystems. Kommandos zum Aktivieren oder Deaktivieren der Revision finden Sie in Abschnitt 11.5, „Revision von API-Anforderungen“.

Abbildung 4.17: Protokolle #

 

Klicken Sie auf Cluster › Überwachung, um Details zu Prometheus-Warnungen zu verwalten und anzuzeigen.

Wenn Prometheus aktiv ist, können Sie in diesem Bereich detaillierte Informationen zu Aktive Warnungen, Alle Warnungen oder Stummschaltungen anzeigen.

Anmerkung

Wenn Sie Prometheus noch nicht bereitgestellt haben, werden ein Informationsbanner und ein Link zur entsprechenden Dokumentation angezeigt.

Klicken Sie zum Hinzufügen eines neuen Pools oben links in der Tabelle der Pools auf Hinzufügen. Im Pool-Formular können Sie den Namen des Pools, den Typ, seine Anwendungen, den Komprimierungsmodus und die Quoten einschließlich der maximalen Größe in Byte und der maximalen Anzahl der Objekte eingeben. Im Pool-Formular wird automatisch die optimale Anzahl der Platzierungsgruppen für diesen Pool berechnet. Die Berechnung beruht auf der Anzahl der OSDs im Cluster und dem ausgewählten Pool-Typ mit den zugehörigen Einstellungen. Sobald die Anzahl der Platzierungsgruppen manuell festgelegt wird, wird sie durch eine berechnete Anzahl ersetzt. Bestätigen Sie mit Pool erstellen.

Abbildung 5.2: Hinzufügen eines neuen Pools #

 

Wählen Sie einen zu löschenden Pool in der Tabellenzeile aus. Klicken Sie auf den Dropdown-Pfeil neben der Schaltfläche Erstellen und dann auf Löschen.

Wählen Sie zum Bearbeiten der Optionen eines Pools den Pool in der Tabellenzeile aus und klicken Sie oben links in der Tabelle der Pools auf Bearbeiten.

Sie können den Namen des Pools ändern, die Anzahl der Platzierungsgruppen erhöhen sowie die Liste der Pool-Anwendungen und die Komprimierungseinstellungen ändern. Bestätigen Sie mit Pool bearbeiten.

Zum Abrufen ausführlicher Informationen zu einem Gerät klicken Sie auf dessen Zeile in der Tabelle:

Abbildung 6.2: RBD-Details #

 

Zum Abrufen der ausführlichen Konfiguration eines Geräts klicken Sie auf dessen Zeile in der Tabelle und dann in der unteren Tabelle auf die Registerkarte Konfiguration:

Abbildung 6.3: RBD-Konfiguration #

 

Klicken Sie zum Hinzufügen eines neuen Geräts oben links in der Tabellenüberschrift auf Erstellen und verfahren Sie im Bildschirm RBD erstellen folgendermaßen:

Abbildung 6.4: Hinzufügen eines neuen RBD #

 

Wählen Sie ein zu löschendes Gerät in der Tabellenzeile aus. Klicken Sie auf den Dropdown-Pfeil neben der Schaltfläche Erstellen und dann auf Löschen. Bestätigen Sie den Löschvorgang mit RBD löschen.

Tipp: Verschieben von RBDs in den Papierkorb

Das Löschen eines RBDs kann nicht rückgängig gemacht werden. Wenn Sie stattdessen die Option In Papierkorb verschieben wählen, können Sie das Gerät später wiederherstellen. Wählen Sie das Gerät hierzu auf der Registerkarte Papierkorb der Haupttabelle aus und klicken Sie oben links in der Tabellenüberschrift auf Wiederherstellen.

Wählen Sie zum Erstellen eines RBD-Snapshots das Gerät in der Tabellenzeile aus, und das Inhaltsfenster für die detaillierte Konfiguration erscheint. Wählen Sie den Karteireiter Snapshots aus und klicken Sie oben links in der Tabellenüberschrift auf Erstellen. Geben Sie den Namen des Snapshots ein und bestätigen Sie mit RBD-Snapshot erstellen.

Wenn Sie einen Snapshot ausgewählt haben, können Sie weitere Aktionen für das Gerät durchführen, z. B. Umbenennen, Schützen, Klonen, Kopieren oder Löschen. Mit Rollback wird der Zustand des Geräts vom aktuellen Snapshot wiederhergestellt.

Abbildung 6.5: RBD-Snapshots #

 

RBD-Images können asynchron zwischen zwei Ceph-Clustern gespiegelt werden. Mit dem Ceph Dashboard können Sie die Reproduktion von RBD-Images zwischen mindestens zwei Clustern konfigurieren. Diese Funktion ist in zwei Modi verfügbar:

Die Spiegelung wird innerhalb von Peer-Clustern pro Pool konfiguriert. Sie kann für eine bestimmte Untergruppe von Images innerhalb des Pools konfiguriert werden oder so, dass alle Images innerhalb eines Pools automatisch gespiegelt werden, wenn nur die Journal-basierte Spiegelung verwendet wird.

Die Spiegelung wird mit dem Kommando rbd konfiguriert, das standardmäßig in SUSE Enterprise Storage 7 installiert ist. Der rbd-mirror-Daemon ist dafür zuständig, Image-Aktualisierungen aus dem Remote-Peer-Cluster zu entnehmen und sie auf das Image im lokalen Cluster anzuwenden. In Abschnitt 6.6.2, „Konfigurieren des rbd-mirror-Daemons“ finden Sie weitere Informationen zum Aktivieren des rbd-mirror-Daemons.

Abhängig von den gewünschten Anforderungen an die Reproduktion kann die RBD-Spiegelung entweder für eine einseitige oder für eine zweiseitige Reproduktion konfiguriert werden:

Wichtig

Jede Instanz des rbd-mirror-Daemons muss in der Lage sein, sich gleichzeitig mit dem lokalen und dem entfernten Ceph-Cluster zu verbinden, zum Beispiel mit allen Monitor- und OSD-Hosts. Außerdem muss das Netzwerk über eine ausreichende Bandbreite zwischen den beiden Rechenzentren verfügen, um die Spiegelung des Workloads zu bewältigen.

Tipp: Allgemeine Informationen

Allgemeine Informationen und Anweisungen für die RADOS-Block-Device-Spiegelung über die Kommandozeile finden Sie in Abschnitt 20.4, „RBD-Image-Spiegel“.

6.6.1 Konfigurieren von primären und sekundären Clustern #

 

Im primären Cluster wird der ursprüngliche Pool mit Images erstellt. Im sekundären Cluster werden der Pool oder die Images aus dem primären Cluster reproduziert.

Anmerkung: Relative Namen

Die Bezeichnungen primär und sekundär sind im Zusammenhang mit der Reproduktion relativ, da sie sich eher auf einzelne Pools als auf Cluster beziehen. Bei einer bidirektionalen Reproduktion kann ein Pool beispielsweise aus dem primären in den sekundären Cluster gespiegelt werden, während ein anderer Pool aus dem sekundären in den primären Cluster gespiegelt wird.

cephuser@adm > rbd mirror pool disable POOL_NAME

cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name

cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
  image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \
  W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
  joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \
[--direction rx-only or rx-tx] pool-name token-path

cephuser@adm > cat >>EOF < token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \
1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \
bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF
cephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token

cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid

Tipp: Weitere Informationen zu iSCSI-Gateways

Weitere Informationen zu iSCSI-Gateways finden Sie in Kapitel 22, Ceph iSCSI Gateway.

Klicken Sie zum Auflisten aller verfügbaren Gateways und zugeordneten Images im Hauptmenü auf Block › iSCSI. Die Registerkarte Übersicht mit einer Liste der derzeit konfigurierten iSCSI-Gateways und zugeordneten RBD-Images wird geöffnet.

Die Tabelle Gateways enthält den Status der einzelnen Gateways, die Anzahl der iSCSI-Ziele und die Anzahl der Sitzungen. Die Tabelle Images enthält den Namen der einzelnen zugeordneten Images, den Backstore-Typ des zugehörigen Pool-Namens und weitere statistische Daten.

Die Registerkarte Ziele enthält eine Liste der derzeit konfigurierten iSCSI-Ziele.

Abbildung 6.14: Liste der iSCSI-Ziele #

 

Klicken Sie zum Anzeigen detaillierterer Informationen über ein Ziel auf den Dropdown-Pfeil in der Tabellenzeile des Ziels. Eine Baumstruktur mit den Datenträgern, Portalen, Initiatoren und Gruppen wird geöffnet. Wenn Sie auf ein Element klicken, wird es erweitert und sein Inhalt wird angezeigt, optional mit einer zugehörigen Konfiguration in der Tabelle rechts.

Abbildung 6.15: Details zu iSCSI-Zielen #

 

6.7.1 Hinzufügen von iSCSI-Zielen #

 

Klicken Sie zum Hinzufügen eines neuen iSCSI-Ziels links oben in der Tabelle Ziele auf Erstellen und geben Sie die erforderlichen Informationen ein.

Abbildung 6.16: Hinzufügen eines neuen Ziels #

 

1. Geben Sie die Zieladresse des neuen Gateways ein.

2. Klicken Sie auf Portal hinzufügen und wählen Sie ein oder mehrere iSCSI-Portale aus der Liste aus.

3. Klicken Sie auf Image hinzufügen und wählen Sie ein oder mehrere RBD-Images für das Gateway aus.

4. Wenn Sie für den Zugriff auf das Gateway eine Authentifizierung verwenden müssen, aktivieren Sie das Kontrollkästchen ACL-Authentifizierung und geben Sie den Berechtigungsnachweis ein. Weitere erweiterte Authentifizierungsoptionen finden Sie nach Aktivieren von Mutual authentication (Gegenseitige Authentifizierung) und Discovery authentication (Ermittlungsauthentifizierung).

5. Bestätigen Sie mit Ziel erstellen.

Tipp: Weitere Informationen

Allgemeine Informationen und eine Beschreibung der RBD-QoS-Konfigurationsoptionen finden Sie in Abschnitt 20.6, „QoS-Einstellungen“.

Die QoS-Optionen können auf verschiedenen Ebenen konfiguriert werden.

Die globale Konfiguration befindet sich an oberster Stelle in der Liste und wird für alle neu erstellten RBD-Images herangezogen, außerdem für alle Images, in denen diese Werte in der Pool- oder RBD-Image-Schicht nicht überschrieben werden. Ein global festgelegter Optionswert kann für einzelne Pools oder Images überschrieben werden. Die für einen Pool festgelegten Optionen werden für alle RBD-Images dieses Pools übernommen, sofern sie nicht von einer Konfigurationsoption in einem Image überschrieben werden. Die für ein Image festgelegten Optionen überschreiben die für einen Pool festgelegten Optionen sowie die global festgelegten Optionen.

Auf diese Weise können Sie globale Standardwerte definieren, für alle RBD-Images eines bestimmten Pools anpassen und dann die Poolkonfiguration für einzelne RBD-Images überschreiben.

6.8.2 Konfigurieren von Optionen für einen neuen Pool #

 

Zum Erstellen eines neuen Pools und zum Konfigurieren von RBD-Konfigurationsoptionen klicken Sie auf Pools › Erstellen. Wählen Sie den Pooltyp replicated aus. Ergänzen Sie den Pool dann mit dem Anwendungs-Tag rbd, damit Sie die RBD-QoS-Optionen konfigurieren können.

Anmerkung

Bei einem Pool mit Löschcodierung können keine RBD-QoS-Konfigurationsoptionen konfiguriert werden. Zum Konfigurieren der RBD-QoS-Optionen für Pools mit Löschcodierung müssen Sie den reproduzierten Metadaten-Pool eines RBD-Images bearbeiten. Die Konfiguration wird dann für den Daten-Pool mit Löschcodierung dieses Images übernommen.

6.8.3 Konfigurieren von Optionen für einen vorhandenen Pool #

 

Zum Konfigurieren von RBD-QoS-Optionen für einen vorhandenen Pool klicken Sie auf Pools, dann auf die Tabellenzeile des Pools und dann oben links in der Tabelle auf Bearbeiten.

Im Dialogfeld wird der Abschnitt RBD-Konfiguration angezeigt, gefolgt vom Abschnitt Quality of Service.

Anmerkung

Wenn weder der Abschnitt RBD-Konfiguration noch der Abschnitt Quality of Service angezeigt wird, bearbeiten Sie entweder einen Pool mit Löschcodierung, bei dem keine RBD-Konfigurationsoptionen festgelegt werden können, oder der Pool ist nicht für die Verwendung durch RBD-Images konfiguriert. Im letzteren Fall weisen Sie dem Pool das Anwendungs-Tag rbd zu; hiermit werden die entsprechenden Konfigurationsabschnitte angezeigt.

Klicken Sie zum Hinzufügen eines neuen NFS-Exports links oben in der Tabelle der Exporte auf Erstellen und geben Sie die erforderlichen Informationen ein.

Abbildung 7.3: Hinzufügen eines neuen NFS-Exports #

 

Um einen Export zu löschen, wählen Sie den Export in der Tabellenzeile aus und markieren Sie ihn. Klicken Sie auf den Dropdown-Pfeil neben der Schaltfläche Bearbeiten und wählen Sie Löschen aus. Aktivieren Sie das Kontrollkästchen Ja, ich bin sicher und bestätigen Sie mit NFS-Export löschen.

Um einen vorhandenen Export zu bearbeiten, wählen und markieren Sie den Export in der Tabellenzeile und klicken Sie oben links in der Exporttabelle auf Bearbeiten.

Sie können dann alle Details des NFS-Exports anpassen.

Abbildung 7.4: Bearbeiten eines NFS-Exports #

 

Mit Dateisysteme im Hauptmenü rufen Sie einen Überblick der konfigurierten Dateisysteme ab. Die Haupttabelle zeigt den Namen und das Erstellungsdatum der einzelnen Dateisysteme und gibt an, ob ein Dateisystem aktiviert ist oder nicht.

Wenn Sie auf die Tabellenzeile eines Dateisystems klicken, erhalten Sie Details zu dessen Rang und den Pools, die in das Dateisystem eingefügt wurden.

Abbildung 8.1: CephFS-Details #

 

Unten im Bildschirm werden Statistiken mit der Anzahl der zugehörigen MDS-Inodes und Client-Anfragen in Echtzeit angezeigt.

Abbildung 8.2: CephFS-Details #

 

Zum Abrufen einer Liste der konfigurierten Object Gateways klicken Sie auf Object Gateway › Daemons. Die Liste enthält die ID des Gateways, den Hostnamen des Cluster-Knotens, auf dem der Gateway Daemon ausgeführt wird, sowie die Versionsnummer des Gateways.

Klicken Sie auf den Dropdown-Pfeil neben dem Namen des Gateways, um detaillierte Informationen über das Gateway anzuzeigen. Die Registerkarte Leistungsindikatoren enthält Details zu Lese-/Schreiboperationen und Cache-Statistiken.

Abbildung 9.1: Gateway-Details #

 

Mit Object Gateway › Benutzer erhalten Sie eine Liste der vorhandenen Object-Gateway-Benutzer.

Klicken Sie auf den Dropdown-Pfeil neben dem Benutzernamen, um Details zum Benutzerkonto anzuzeigen, wie zum Beispiel die Statusinformationen oder die Details zum Benutzer und zu den Bucket-Quoten.

Abbildung 9.2: Gateway-Benutzer #

 

9.2.1 Hinzufügen eines neuen Gateway-Benutzers #

 

Klicken Sie zum Hinzufügen eines neuen Gateway-Benutzers oben links in der Tabellenüberschrift auf Hinzufügen. Geben Sie den Berechtigungsnachweis, Details zum S3-Schlüssel und die Benutzer- und Bucket-Quote ein und bestätigen Sie mit Benutzer erstellen.

Abbildung 9.3: Hinzufügen eines neuen Gateway-Benutzers #

 

Object Gateway(OGW)-Buckets setzen den Funktionsumfang von OpenStack-Swift-Containern um. Object-Gateway-Buckets fungieren als Container zum Speichern von Datenobjekten.

Klicken Sie auf Object Gateway › Buckets, um eine Liste der Object-Gateway-Buckets anzuzeigen.

9.3.1 Hinzufügen eines neuen Buckets #

 

Klicken Sie zum Hinzufügen eines neuen Object-Gateway-Buckets oben links in der Tabellenüberschrift auf Erstellen. Geben Sie den Namen des Buckets ein, wählen Sie den Inhaber aus und legen Sie das Platzierungsziel fest. Bestätigen Sie mit Bucket erstellen.

Anmerkung

In dieser Phase können Sie durch Auswahl von Aktiviert eine Sperre aktivieren. Sie können dies jedoch auch noch nach der Erstellung konfigurieren. Weitere Informationen zu diesem Thema finden Sie in Abschnitt 9.3.3, „Bearbeiten des Buckets“.

9.3.2 Anzeigen der Bucket-Details #

 

Klicken Sie auf den Dropdown-Pfeil neben dem Bucket-Namen, um detaillierte Informationen zu einem Object-Gateway-Bucket anzuzeigen.

Abbildung 9.4: Gateway Bucket-Details #

 

Tipp: Bucket-Quote

Unterhalb der Tabelle Details werden Details zu den Bucket-Quoteneinstellungen angezeigt.

9.3.3 Bearbeiten des Buckets #

 

Wählen und markieren Sie einen Bucket und klicken Sie dann oben links in der Tabellenüberschrift auf Bearbeiten.

Sie können den Inhaber des Buckets aktualisieren oder die Versionierung, die Multi-Faktor-Authentifizierung oder die Sperre aktivieren. Bestätigen Sie alle Änderungen mit Bucket bearbeiten.

Abbildung 9.5: Bearbeiten der Bucket-Details #

 

Alle HTTP-Verbindungen zum Dashboard werden standardmäßig mit TLS/SSL gesichert. Für eine sichere Verbindung ist ein SSL-Zertifikat erforderlich. Sie können entweder ein eigensigniertes Zertifikat verwenden oder ein Zertifikat erzeugen und durch eine bekannte Zertifizierungsstelle (CA) signieren lassen.

Tipp: Deaktivieren von SSL

Unter Umständen muss die SSL-Unterstützung deaktiviert werden. Dies ist beispielsweise der Fall, wenn das Dashboard hinter einem Proxy ausgeführt wird, der SSL nicht unterstützt.

Deaktivieren Sie SSL nur mit Bedacht, da die Benutzernamen und Passwörter damit unverschlüsselt an das Dashboard gesendet werden.

Mit folgendem Kommando deaktivieren Sie SSL:

cephuser@adm > ceph config set mgr mgr/dashboard/ssl false

Tipp: Neustarten der Ceph-Manager-Prozesse

Die Ceph-Manager-Prozesse müssen nach einer Änderung des SSL-Zertifikats und des Schlüssels manuell neu gestartet werden. Führen Sie hierzu entweder das folgende Kommando aus:

cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME

oder deaktivieren Sie das Dashboard-Modul und aktivieren Sie es wieder, wodurch auch der Manager sich selbst wieder neu erzeugt:

cephuser@adm > ceph mgr module disable dashboard
cephuser@adm > ceph mgr module enable dashboard

10.1.1 Erstellen von eigensignierten Zertifikaten #

 

Ein eigensigniertes Zertifikat für die sichere Kommunikation lässt sich schnell und einfach erstellen. So bringen Sie das Dashboard rasch in Gang.

Anmerkung: Fehlermeldungen bei Webbrowsern

Die meisten Webbrowser geben bei selbstsignierten Zertifikaten eine Fehlermeldung aus und fordern eine explizite Bestätigung, bevor eine sichere Verbindung zum Dashboard hergestellt wird.

Mit dem folgenden integrierten Kommando erzeugen und installieren Sie ein selbstsigniertes Zertifikat:

cephuser@adm > ceph dashboard create-self-signed-cert

10.1.2 Verwenden von Zertifikaten, die von einer Zertifizierungsstelle signiert wurden #

 

Damit die Verbindung zum Dashboard ordnungsgemäß gesichert wird und Webbrowser-Fehlermeldungen zu selbstsignierten Zertifikaten unterbunden werden, wird empfohlen, ein Zertifikat zu verwenden, das von einer CA signiert ist.

Mit einem Kommando wie im folgenden Beispiel erzeugen Sie ein Zertifikat-Schlüsselpaar:

root # openssl req -new -nodes -x509 \
  -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
  -keyout dashboard.key -out dashboard.crt -extensions v3_ca

Das obige Kommando gibt die Dateien dashboard.key und dashboard.crt aus. Sobald die Datei dashboard.crt von einer CA signiert wurde, aktivieren Sie es mit dem folgenden Kommando für alle Ceph-Manager-Instanzen:

cephuser@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/key -i dashboard.key

Tipp: Unterschiedliche Zertifikate für die einzelnen Manager-Instanzen

Wenn Sie unterschiedliche Zertifikate für die einzelnen Ceph-Manager-Instanzen benötigen, bearbeiten Sie die Kommandos und geben Sie den Namen der Instanz wie folgt an. Ersetzen Sie NAME durch den Namen der Ceph-Manager-Instanz (in der Regel der zugehörige Hostname):

cephuser@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key

Ceph Dashboard bindet an eine bestimmte TCP/IP-Adresse und an einen bestimmten TCP-Port. Standardmäßig bindet der derzeit aktive Ceph Manager, auf dem das Dashboard gehostet wird, an den TCP-Port 8443 (oder 8080, wenn SSL deaktiviert ist).

Anmerkung

Wenn auf den Hosts, auf denen Ceph Manager (und damit Ceph Dashboard) ausgeführt wird, eine Firewall aktiviert ist, müssen Sie möglicherweise die Konfiguration ändern, um den Zugriff auf diese Ports zu ermöglichen. Weitere Informationen zu den Firewall-Einstellungen für Ceph finden Sie im Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Ceph Dashboard bindet standardmäßig an „::“, was allen verfügbaren IPv4- und IPv6-Adressen entspricht. Mit folgenden Kommandos können Sie die IP-Adresse und die Portnummer der Webanwendung ändern, sodass sie für alle Ceph-Manager-Instanzen gelten:

cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

Tipp: Separate Konfiguration der Ceph-Manager-Instanzen

Auf jedem ceph-mgr-Daemon wird eine eigene Dashboard-Instanz gehostet; unter Umständen müssen diese Instanzen daher separat konfiguriert werden. Mit folgenden Kommandos ändern Sie die IP-Adresse und die Portnummer für eine bestimmte Manager-Instanz (ersetzen Sie NAME mit der ID der ceph-mgr-Instanz):

cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

Tipp: Auflisten der konfigurierten Endpunkte

Das Kommando ceph mgr services gibt alle derzeit konfigurierten Endpunkte zurück. Über den Schlüssel dashboard erhalten Sie die URL für den Zugriff auf das Dashboard.

Wenn Sie nicht das standardmäßige Administratorkonto verwenden möchten, erstellen Sie ein anderes Benutzerkonto und weisen Sie diesem Konto mindestens eine Rolle zu. Es steht eine Reihe vordefinierter Systemrollen zur Auswahl. Weitere Informationen finden Sie unter Kapitel 11, Verwalten von Benutzern und Rollen über die Kommandozeile.

Mit folgendem Kommando erstellen Sie einen Benutzer mit Administratorrechten:

cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

Sollen die Object-Gateway-Verwaltungsfunktionen des Dashboards genutzt werden, müssen Sie die Anmeldeberechtigung eines Benutzers mit dem aktivierten system-Flag angeben:

Anmerkung

Standardmäßig ist die Firewall in SUSE Linux Enterprise Server 15 SP2 aktiviert. Weitere Informationen zur Firewall-Konfiguration finden Sie im Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Es sind mehrere Punkte zu beachten:

Das Ceph Dashboard verwaltet iSCSI-Ziele mithilfe der REST-API, die vom Service rbd-target-api des Ceph-iSCSI-Gateways bereitgestellt wird. Stellen Sie sicher, dass es auf iSCSI-Gateways installiert und aktiviert ist.

Anmerkung

Die iSCSI-Verwaltungsfunktion des Ceph Dashboards hängt von der neuesten Version 3 des ceph-iscsi-Projekts ab. Stellen Sie sicher, dass Ihr Betriebssystem die richtige Version bereitstellt, da das Ceph Dashboard die Verwaltungsfunktionen andernfalls nicht aktiviert.

Wenn die ceph-iscsi-REST-API im HTTPS-Modus konfiguriert ist und ein eigensigniertes Zertifikat verwendet, konfigurieren Sie das Dashboard so, dass die Überprüfung des SSL-Zertifikats beim Zugriff auf die ceph-iscsi-API vermieden wird.

Deaktivieren Sie die API-SSL-Überprüfung:

cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false

Definieren Sie die verfügbaren iSCSI-Gateways:

cephuser@adm > ceph dashboard iscsi-gateway-list
cephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]
cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name

Mit der Zugriffskontrollmethode Single Sign-on (SSO) können die Benutzer sich mit einer einzigen ID und einem einzigen Passwort bei mehreren Anwendungen gleichzeitig anmelden.

Das Ceph Dashboard unterstützt die externe Authentifizierung von Benutzern über das SAML-2.0-Protokoll. Da die Autorisierung weiterhin durch das Dashboard vorgenommen wird, müssen Sie zunächst Benutzerkonten erstellen und ihnen die gewünschten Rollen zuweisen. Der Authentifizierungsprozess kann jedoch von einem vorhandenen Identitätsanbieter (IdP) durchgeführt werden.

Mit folgendem Kommando konfigurieren Sie das Single Sign-on:

cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \
 IDP_METADATA IDP_USERNAME_ATTRIBUTE \
 IDP_ENTITY_ID SP_X_509_CERT \
 SP_PRIVATE_KEY

Parameter:

Anmerkung: SAML-Anforderungen

Für den Ausstellerwert der SAML-Anforderungen gilt folgende Syntax:

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

Mit folgendem Kommando rufen Sie die aktuelle SAML-2.0-Konfiguration ab:

cephuser@adm > ceph dashboard sso show saml2

Mit folgendem Kommando deaktivieren Sie Single Sign-on:

cephuser@adm > ceph dashboard sso disable

Mit folgendem Kommando prüfen Sie, ob SSO aktiviert ist:

cephuser@adm > ceph dashboard sso status

Mit folgendem Kommando aktivieren Sie SSO:

cephuser@adm > ceph dashboard sso enable saml2

Standardmäßig ist die Passwortrichtlinienfunktion einschließlich der folgenden Prüfungen aktiviert:

Die Passwortrichtlinienfunktion kann komplett ein- oder ausgeschaltet werden:

cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false

Die folgenden Einzelprüfungen können ein- oder ausgeschaltet werden:

cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false

Darüber hinaus stehen zum Konfigurieren des Verhaltens der Passwortrichtlinie die folgenden Optionen zur Verfügung.

Das Ceph Dashboard unterstützt die Verwaltung mehrerer Benutzerkonten. Jedes Benutzerkonto umfasst einen Benutzernamen, ein Passwort (in verschlüsselter Form mit bcrypt gespeichert), einen optionalen Namen und eine optionale E-Mail-Adresse.

Die Benutzerkonten werden in der Konfigurationsdatenbank von Ceph Monitor gespeichert und global für alle Ceph-Manager-Instanzen freigegeben.

Mit folgenden Kommandos verwalten Sie die Benutzerkonten:

In diesem Abschnitt erfahren Sie, welche Sicherheitsbereiche Sie einer Benutzerrolle zuweisen können, wie Sie Benutzerrollen verwalten und wie Sie sie den Benutzerkonten zuweisen.

11.3.2 Festlegen von Benutzerrollen #

 

Eine Rolle bestimmt eine Reihe von Zuordnungen zwischen einem Sicherheitsbereich und einer Gruppe von Berechtigungen. Es gibt vier Arten von Berechtigungen: „read“, „create“, „update“ und „delete“.

Im folgenden Beispiel wird eine Rolle festgelegt, bei der ein Benutzer die Berechtigungen „read“ und „create“ für Funktionen im Rahmen der Pool-Verwaltung sowie uneingeschränkte Berechtigungen für Funktionen im Rahmen der RBD-Image-Verwaltung besitzt:

{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

Das Dashboard bietet bereits eine Gruppe vordefinierter Rollen, die als Systemrollen bezeichnet werden. Diese Rollen können Sie nach einer Neuinstallation des Ceph Dashboards sofort nutzen:

Administrator

Uneingeschränkte Berechtigungen für alle Sicherheitsbereiche.

Nur-Lesen

Leseberechtigung für alle Sicherheitsbereiche mit Ausnahme der Dashboard-Einstellungen.

block-manager

Uneingeschränkte Berechtigungen für die Bereiche „rbd-image“, „rbd-mirroring“ und „iscsi“.

rgw-manager

Uneingeschränkte Berechtigungen für den Bereich „rgw“.

cluster-manager

Uneingeschränkte Berechtigungen für die Bereiche „hosts“, „osd“, „monitor“, „manager“ und „config-opt“.

pool-manager

Uneingeschränkte Berechtigungen für den Bereich „pool“.

cephfs-manager

Uneingeschränkte Berechtigungen für den Bereich „cephfs“.

11.3.2.1 Verwalten benutzerdefinierter Rollen #

 

Mit folgenden Kommandos können Sie neue Benutzerrollen erstellen:

Eine neue Rolle erstellen:

cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

Eine Rolle löschen:

cephuser@adm > ceph dashboard ac-role-delete ROLENAME

Bereichsberechtigungen für eine Rolle festlegen:

cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

Bereichsberechtigungen einer Rolle löschen:

cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

11.3.2.2 Zuweisen von Rollen zu Benutzerkonten #

 

Mit folgenden Kommandos weisen Sie die Rollen den Benutzern zu:

Benutzerrollen festlegen:

cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

Einem Benutzer zusätzliche Rollen zuweisen:

cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

Rollen eines Benutzers löschen:

cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

Tipp: Bereinigen benutzerdefinierter Rollen

Wenn Sie benutzerdefinierte Rollen erstellen und den Ceph-Cluster später mit dem Ausführungsprogramm ceph.purge bereinigen möchten, müssen Sie zunächst die benutzerdefinierten Rollen bereinigen. Weitere Informationen finden Sie in Abschnitt 13.9, „Vollständiges Entfernen eines Ceph-Clusters“.

11.3.2.3 Beispiel: Erstellen eines Benutzers und einer benutzerdefinierten Regel #

 

In diesem Abschnitt wird das Verfahren zum Erstellen eines Benutzerkontos veranschaulicht, das RBD-Images verwalten und den Ceph-Pool abrufen kann sowie den Nur-Lese-Zugriff auf alle anderen Bereiche erhält.

1. Erstellen Sie einen neuen Benutzer namens tux:

    cephuser@adm > ceph dashboard ac-user-create tux PASSWORD

2. Erstellen Sie eine Rolle und legen Sie die Bereichsberechtigungen fest:

   cephuser@adm > ceph dashboard ac-role-create rbd/pool-manager
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \
    rbd-image read create update delete
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. Ordnen Sie die Rollen dem Benutzer tux zu:

   cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

Wenn Sie eine feste URL für das Ceph Dashboard festlegen möchten oder wenn Sie keine direkten Verbindungen zu den Manager-Knoten zulassen möchten, können Sie einen Proxy einrichten, der eingehende Anfragen automatisch an die aktuell aktive ceph-mgr-Instanz weiterleitet.

  cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503

11.4.4 Beispiel einer HAProxy-Konfiguration #

 

Im folgenden Beispiel wird ein TLS/SSL-Durchlauf mit HAProxy konfiguriert.

Anmerkung

Die Konfiguration funktioniert unter den folgenden Bedingungen: Wenn das Dashboard ausfällt, erhält der Frontend-Client möglicherweise eine HTTP-Weiterleitungsantwort (303) und wird an einen nicht auflösbaren Host weitergeleitet.

Dies geschieht, wenn die Ausfallsicherung während zweier HAProxy-Zustandsprüfungen auftritt. In dieser Situation antwortet der zuvor aktive Dashboard-Knoten nun mit einer 303, die auf den neuen aktiven Knoten zeigt. Um diese Situation zu vermeiden, sollten Sie erwägen, das Weiterleitungsverhalten auf Standby-Knoten zu deaktivieren.

  defaults
    log global
    option log-health-checks
    timeout connect 5s
    timeout client 50s
    timeout server 450s

  frontend dashboard_front
    mode http
    bind *:80
    option httplog
    redirect scheme https code 301 if !{ ssl_fc }

  frontend dashboard_front_ssl
    mode tcp
    bind *:443
    option tcplog
    default_backend dashboard_back_ssl

  backend dashboard_back_ssl
    mode tcp
    option httpchk GET /
    http-check expect status 200
    server x HOST:PORT ssl check verify none
    server y HOST:PORT ssl check verify none
    server z HOST:PORT ssl check verify none

Die REST-API des Ceph Dashboards kann PUT-, POST- und DELETE-Anforderungen im Ceph-Revisionsprotokoll festhalten. Die Protokollierung ist standardmäßig deaktiviert; mit folgendem Kommando können Sie sie jedoch aktivieren:

cephuser@adm > ceph dashboard set-audit-api-enabled true

Nach der Aktivierung werden die folgenden Parameter für jede Anforderung protokolliert:

Beispiel für einen Protokolleintrag:

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \
 from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \
 user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "user@example.com"}'

Tipp: Deaktivieren der Protokollierung der Anforderungsnutzlast

Die Protokollierung der Anforderungsnutzlast (die Liste der Argumente und ihrer Werte) ist standardmäßig aktiviert. So können Sie sie deaktivieren:

cephuser@adm > ceph dashboard set-audit-api-log-payload false

Das Ceph Dashboard kann NFS-Ganesha-Exporte verwalten, die CephFS oder Object Gateway als Backstore verwenden. Das Dashboard verwaltet NFS-Ganesha-Konfigurationsdateien, die in RADOS-Objekten auf dem CephFS-Cluster gespeichert sind. NFS Ganesha muss einen Teil ihrer Konfiguration im Ceph-Cluster speichern.

Konfigurieren Sie den Standort der Konfigurationsobjekte von NFS Ganesha mit folgendem Kommando:

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]

Sie können nun NFS-Ganesha-Exporte über das Ceph Dashboard verwalten.

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*

Ceph-Dashboard-Plugins erweitern die Funktionalität des Dashboards. Das Plugin zur Fehlersuche ermöglicht die Anpassung des Verhaltens des Dashboards entsprechend dem Fehlersuchmodus. Es kann mit folgendem Kommando aktiviert, deaktiviert oder überprüft werden:

cephuser@adm > ceph dashboard debug status
Debug: 'disabled'
cephuser@adm > ceph dashboard debug enable
Debug: 'enabled'
cephuser@adm > dashboard debug disable
Debug: 'disabled'

Es ist standardmäßig deaktiviert. Dies ist die empfohlene Einstellung für Produktionsbereitstellungen. Bei Bedarf kann der Fehlersuchmodus aktiviert werden, ohne dass ein Neustart erforderlich ist.

Mit ceph -s oder ceph -s rufen Sie den aktuellen Zustand des Clusters ab:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

Die Ausgabe bietet die folgenden Informationen:

Tipp: Wie Ceph die Datennutzung berechnet

Der Wert used bezeichnet den tatsächlich belegten Basisspeicherplatz. Der Wert xxx GB / xxx GB bezeichnet den verfügbaren Speicherplatz (der kleinere Wert) der gesamten Speicherkapazität des Clusters. Die nominelle Menge spiegelt die Menge der gespeicherten Daten wider, bevor diese reproduziert oder geklont werden oder ein Snapshot davon erstellt wird. Daher übersteigt die Menge der tatsächlich gespeicherten Daten normalerweise die nominelle gespeicherte Menge, weil Ceph Reproduktionen der Daten erstellt und die Speicherkapazität möglicherweise auch zum Klonen und für Snapshots verwendet.

Mit den folgenden Kommandos werden die Statusinformationen ebenfalls sofort angezeigt:

Sollen die Angaben in Echtzeit aktualisiert werden, geben Sie diese Kommandos (auch ceph ‑s) als Argument für das Kommando watch an:

root # watch -n 10 'ceph -s'

Drücken Sie Strg–C, wenn Sie den Vorgang nicht länger beobachten möchten.

Überprüfen Sie den Zustand Ihres Clusters nach dessen Start und bevor Sie mit dem Lesen und/oder Schreiben von Daten beginnen:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Tipp

Wenn Sie nicht standardmäßige Standorte für Ihre Konfiguration oder Ihren Schlüsselbund angegeben haben, können Sie diese angeben mit:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

Der Ceph-Cluster gibt einen der folgenden Zustandscodes zurück:

Tipp

Wenn Sie nicht standardmäßige Standorte für Ihre Konfiguration oder Ihren Schlüsselbund angegeben haben, können Sie diese angeben mit:

root # ceph -c /path/to/conf -k /path/to/keyring health

Mit dem Kommando ceph df prüfen Sie die Datenauslastung und Datenverteilung auf die Pools in einem Cluster. Mit ceph df detail erhalten Sie weitere Details.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

Der Abschnitt RAW STORAGE der Ausgabe gibt einen Überblick über den Speicherplatz, den Ihr Cluster für die Daten nutzt.

Im Abschnitt POOLS der Ausgabe finden Sie eine Liste der Pools und die nominelle Auslastung der einzelnen Pools. Die Ausgabe in diesem Abschnitt umfasst keine Reproduktionen, Klone oder Snapshots. Beispiel: Wenn Sie ein Objekt mit 1 MB Daten speichern, beträgt die nominelle Auslastung 1 MB. Die tatsächliche Auslastung beträgt jedoch möglicherweise 2 MB oder mehr, je nach Anzahl der Reproduktionen, Klone und Snapshots.

Anmerkung

Die Zahlen im Abschnitt POOLS sind nominell. Sie sind nicht inklusive der Anzahl der Reproduktionen, Snapshots oder Klone zu verstehen. Folglich entspricht die Summe der Zahlen unter USED und %USED nicht den Zahlen unter RAW USED und %RAW USED im Abschnitt RAW STORAGE der Ausgabe.

Mit folgenden Kommandos prüfen Sie die OSDs, um sicherzustellen, dass sie aktiv sind:

cephuser@adm > ceph osd stat

oder

cephuser@adm > ceph osd dump

OSDs lassen sich auch entsprechend ihrer Position in der CRUSH-Map anzeigen.

Mit ceph osd tree werden ein CRUSH-Baum mit einem Host und dessen OSDs, der Status der Aktivität und deren Gewicht ausgegeben:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

Ceph verhindert, dass Sie an einen vollen OSD schreiben, damit Sie keine Daten verlieren. In einem betriebsbereiten Cluster sollten Sie eine Warnmeldung erhalten, wenn der Cluster annähernd voll ist. Der Wert für mon osd full ratio beträgt standardmäßig 0,95 bzw. 95 % der Kapazität. Wenn dieser Wert erreicht ist, werden die Clients davon abgehalten, Daten zu schreiben. Der Wert mon osd nearfull ratio beträgt standardmäßig 0,85 bzw. 85 % der Kapazität. Wenn dieser Wert erreicht ist, wird eine Zustandswarnung generiert.

Volle OSD-Knoten werden durch ceph health gemeldet:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

oder

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

Am besten fügen Sie bei einem vollen Cluster neue OSD-Hosts/-Datenträger hinzu. Dadurch kann der Cluster Daten auf dem neu verfügbaren Speicherplatz verteilen.

Tipp: Verhindern voller OSDs

Wenn ein OSD voll wird, also 100 % der Festplattenkapazität nutzt, stürzt er normalerweise schnell und ohne Warnmeldung ab. Nachfolgend sehen Sie einige Tipps, die Sie beim Verwalten von OSD-Knoten beachten sollten.

• Der Festplattenspeicherplatz der einzelnen OSDs (normalerweise eingehängt unter/var/lib/ceph/osd/osd-{1,2..}) muss jeweils auf eine dedizierte zugrundeliegende Festplatte oder Partition gestellt werden.

• Überprüfen Sie die Ceph-Konfigurationsdateien und stellen Sie sicher, dass Ceph die Protokolldatei nicht auf den Festplatten/Partitionen speichert, die explizit für die OSDs vorgesehen sind.

• Vergewissern Sie sich, dass kein anderer Prozess auf die Festplatten/Partitionen schreibt, die explizit für die OSDs vorgesehen sind.

Nachdem Sie den Cluster gestartet haben und bevor die ersten Daten gelesen und/oder geschrieben werden, prüfen Sie die Kontingentstatus der Ceph Monitors. Wenn der Cluster bereits Anforderungen verarbeitet, prüfen Sie den Status der Ceph Monitors regelmäßig, ob sie tatsächlich ausgeführt werden.

Führen Sie zum Anzeigen der Monitor-Zuordnung Folgendes aus:

cephuser@adm > ceph mon stat

oder

cephuser@adm > ceph mon dump

Führen Sie zum Prüfen des Quorum-Status für den Monitor-Cluster Folgendes aus:

cephuser@adm > ceph quorum_status

Ceph gibt den Quorum-Status zurück. Beispielsweise gibt ein Ceph-Cluster, der aus drei Monitors besteht, möglicherweise Folgendes zurück:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

Placement Groups ordnen Objekte zu OSDs zu. Bei der Überwachung Ihrer Placement Groups sollten diese active (aktiv) und clean (intakt) sein. Ausführliche Informationen finden Sie in Abschnitt 12.9, „Überwachen der OSDs und Platzierungsgruppen“.

Wenn sich ein Ceph-Speicher-Cluster seiner maximalen Kapazität annähert, unterbindet Ceph aus Sicherheitsgründen weitere Schreib- oder Lesevorgänge auf Ceph OSDs, damit kein Datenverlust eintritt. Es wird daher nicht empfohlen, die Quote eines Produktions-Clusters voll auszuschöpfen, da damit die Hochverfügbarkeit nicht mehr gewährleistet ist. Die standardmäßige „full“-Quote ist auf 0,95 eingestellt, also auf 95 % der Kapazität. Für einen Test-Cluster mit nur wenigen OSDs ist dies eine äußerst aggressive Einstellung.

Tipp: Erhöhen der Speicherkapazität

Achten Sie bei der Überwachung des Clusters auf Warnmeldungen zur nearfull-Quote. Dies bedeutet, dass ein Ausfall eines (oder mehrerer) OSDs zu einer Serviceunterbrechung führen würde. Ziehen Sie in Erwägung, weitere OSDs einzufügen und damit die Speicherkapazität zu erhöhen.

In einem gängigen Szenario für Test-Cluster entfernt ein Systemadministrator ein Ceph OSD aus dem Ceph-Speicher-Cluster und beobachtet dann den Neuausgleich des Clusters. Anschließend wird ein weiterer Ceph OSD entfernt usw., bis der Cluster schließlich die „full“-Quote erreicht und zum Stillstand kommt. Selbst bei einem Test-Cluster wird eine gewisse Kapazitätsplanung empfohlen. Durch die Planung können Sie einschätzen, wie viel Ersatzkapazität Sie benötigen, damit die Hochverfügbarkeit aufrechterhalten werden kann. Im Idealfall sollten Sie eine ganze Reihe von Ceph OSD-Ausfällen einplanen, bei der Cluster wieder den Status active + clean erreichen kann, ohne die betreffenden Ceph OSDs austauschen zu müssen. Sie können einen Cluster im Status active + degraded ausführen, doch unter normalen Betriebsbedingungen ist dies nicht ideal.

Das nachfolgende Diagramm zeigt einen vereinfachten Ceph-Speicher-Cluster mit 33 Ceph Knoten und je einem Ceph OSD pro Host, die jeweils Lese- und Schreibvorgänge auf einem 3-TB-Laufwerk ausführen. Dieser Beispiel-Cluster besitzt eine maximale Istkapazität von 99 TB. Die Option mon osd full ratio ist auf 0,95 eingestellt. Sobald der Speicherplatz im Cluster unter 5 TB der Restkapazität fällt, werden Lese- und Schreibvorgänge der Clients unterbunden. Die Betriebskapazität des Speicher-Clusters liegt also bei 95 TB, nicht bei 99 TB.

Abbildung 12.1: Ceph-Cluster #

 

In einem solchen Cluster ist ein Ausfall von einem oder zwei OSDs durchaus normal. In einem weniger häufigen, jedoch denkbaren Szenario fällt der Router oder die Netzversorgung eines Racks aus, sodass mehrere OSDs gleichzeitig ausfallen (z. B. OSDs 7–12). In einem solchen Szenario muss der Cluster dennoch weiterhin betriebsbereit bleiben und den Status active + clean erreichen – selbst wenn dafür einige Hosts mit zusätzlichen OSDs in kürzester Zeit eingefügt werden müssen. Wenn die Kapazitätsauslastung zu hoch ist, verlieren Sie unter Umständen keine Daten. Doch beim Beheben eines Ausfalls in einer Fehlerdomäne ist die Datenverfügbarkeit dennoch beeinträchtigt, wenn die Kapazitätsauslastung des Clusters die für Code übersteigt. Aus diesem Grund wird zumindest eine grobe Kapazitätsplanung empfohlen.

Ermitteln Sie zwei Zahlen für Ihren Cluster:

Wenn Sie die Gesamtkapazität des Clusters durch die Anzahl der OSDs im Cluster dividieren, erhalten Sie die Durchschnittskapazität eines OSDs im Cluster. Multiplizieren Sie diese Zahl ggf. mit der Anzahl der OSDs, die laut Ihren Erwartungen im Normalbetrieb gleichzeitig ausfallen könnten (relativ kleine Zahl). Multiplizieren Sie schließlich die Kapazität des Clusters mit der „full“-Quote. Damit erhalten Sie die maximale Betriebskapazität. Subtrahieren Sie dann die Datenmenge der OSDs, die vermutlich ausfallen werden, und Sie erhalten eine angemessene „full“-Quote. Wenn Sie den obigen Vorgang mit einer größeren Anzahl an OSD-Ausfällen (einem OSD-Rack) wiederholen, erhalten Sie eine angemessene Zahl für die „near full“-Quote.

Die folgenden Einstellungen gelten nur bei der Cluster-Erstellung und werden dann in der OSD-Karte gespeichert:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Tipp

Diese Einstellungen gelten nur bei der Cluster-Erstellung. Später müssen sie mit den Kommandos ceph osd set-nearfull-ratio und ceph osd set-full-ratioin der OSD-Karte geändert werden.

Tipp: Prüfen des OSD-Gewichts

Wenn einige OSDs nearfull sind, andere aber noch reichlich Kapazität besitzen, liegt eventuell ein Problem mit dem CRUSH-Gewicht für die nearfull-OSDs vor.

Voraussetzung für Hochverfügbarkeit und hohe Zuverlässigkeit ist eine fehlertolerante Bearbeitung von Hardware- und Softwareproblemen. Ceph enthält keinen Single-Point-of-Failure und kann Anforderungen nach Daten in einem eingeschränkt leistungsfähigen Modus („degraded“) verarbeiten. Die Datenplatzierung bei Ceph umfasst eine Dereferenzierungsschicht, mit der gewährleistet wird, dass die Daten nicht direkt an bestimmte OSD-Adressen binden. Bei der Suche nach Systemfehlern bedeutet dies, dass die richtige Platzierungsgruppe und die zugrunde liegenden OSDs als Problemursache ermittelt werden müssen.

Tipp: Zugriff im Fehlerfall

Bei einem Fehler in einem Teil des Clusters können Sie unter Umständen nicht auf ein bestimmtes Objekt zugreifen. Dies bedeutet nicht, dass Sie nicht auf andere Objekte zugreifen können. Wenn ein Fehler auftritt, befolgen Sie die Anweisungen für die Überwachung Ihrer OSDs und Platzierungsgruppen. Nehmen Sie dann die Fehlerbehebung vor.

Ceph repariert sich im Allgemeinen selbst. Bleiben Probleme jedoch längere Zeit bestehen, trägt die Überwachung der OSDs und Platzierungsgruppen dazu bei, das Problem zu erkennen.

12.9.1 Überwachen der OSDs #

 

Ein OSD befindet sich entweder im Cluster (Status „in“) oder außerhalb des Clusters („out“). Gleichzeitig ist er entweder betriebsbereit und aktiv („up“) oder nicht betriebsbereit und inaktiv („down“). Wenn ein OSD „up“ ist, befindet er sich entweder im Cluster (Sie können Daten lesen und schreiben) oder außerhalb des Clusters. Wenn er sich bis vor Kurzem im Cluster befand und dann aus dem Cluster heraus verschoben wurde, migriert Ceph die Platzierungsgruppen zu anderen OSDs. Befindet sich ein OSD außerhalb des Clusters, weist CRUSH diesem OSD keine Platzierungsgruppen zu. Wenn ein OSD „down“ ist, sollte er auch „out“ sein.

Anmerkung: Fehlerhafter Zustand

Ist ein OSD „down“ und „in“, liegt ein Problem vor und der Cluster ist nicht in einem einwandfreien Zustand.

Wenn Sie ein Kommando wie ceph health, ceph -s oder ceph -w ausführen, meldet der Cluster nicht immer HEALTH OK. Im Hinblick auf OSDs ist unter den folgenden Umständen zu erwarten, dass der Cluster nicht die Meldung HEALTH OK zurückgibt:

• Sie haben den Cluster noch nicht gestartet (er kann nicht antworten).

• Sie haben den Cluster gestartet oder neu gestartet. Er ist jedoch noch nicht betriebsbereit, da die Platzierungsgruppen noch erstellt werden und die OSDs gerade den Peering-Prozess durchlaufen.

• Sie haben ein OSD hinzugefügt oder entfernt.

• Sie haben die Clusterzuordnung geändert.

Bei der Überwachung der OSDs ist in jedem Fall darauf zu achten, dass alle OSDs im Cluster betriebsbereit und aktiv sind, wenn der Cluster selbst betriebsbereit und aktiv ist. Mit folgendem Kommando prüfen Sie, ob alle OSDs aktiv sind:

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

Das Ergebnis umfasst die Gesamtanzahl der OSDs (x), die Anzahl der OSDs mit dem Status „up“ (y), die Anzahl der OSDs mit dem Status „in“ (z) sowie die Zuordnungsepoche (eNNNN). Wenn die Anzahl der „in“-OSDs höher ist als die Anzahl der „up“-OSDs, ermitteln Sie die nicht aktiven ceph-osd-Daemons mit folgendem Kommando:

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Wenn beispielsweise ein OSD mit ID 1 inaktiv ist, starten Sie es mit:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Weitere Informationen zu Problemen im Zusammenhang mit OSDs, die angehalten wurden oder sich nicht neu starten lassen, finden Sie im Book “Troubleshooting Guide”, Chapter 4 “Troubleshooting OSDs”, Section 4.3 “OSDs not running”.

12.9.2 Zuweisen von Platzierungsgruppen #

 

Beim Zuweisen von Platzierungsgruppen zu den OSDs prüft CRUSH die Anzahl der Reproduktionen für den Pool und weist die Platzierungsgruppe den OSDs so zu, dass jede Reproduktion dieser Platzierungsgruppe einem anderen OSD zugeordnet wird. Wenn der Pool beispielsweise drei Reproduktionen einer Platzierungsgruppe benötigt, weist CRUSH die Reproduktionen beispielsweise osd.1, osd.2 und osd.3 zu. CRUSH strebt dabei eine pseudozufällige Platzierung an, bei der die in der CRUSH-Zuordnung festgelegten Fehlerdomänen berücksichtigt werden, sodass Platzierungsgruppen nur in seltenen Fällen den jeweils nächstgelegenen OSDs in einem großen Cluster zugewiesen werden. Der OSD-Satz, in dem sich die Reproduktion einer bestimmten Platzierungsgruppe befinden soll, wird als „acting“-Satz bezeichnet. In einigen Fällen ist ein OSD im „acting“-Satz nicht betriebsbereit oder kann anderweitig keine Anforderungen nach Objekten in der Platzierungsgruppe verarbeiten. In diesen Situationen liegt eines der folgenden Szenarien vor:

• Sie haben ein OSD hinzugefügt oder entfernt. CRUSH hat die Platzierungsgruppe dann anderen OSDs zugewiesen und damit die Zusammensetzung des agierenden Satzes verändert, sodass die Migration der Daten im Rahmen eines „backfill“-Prozesses ausgelöst wurde.

• Ein OSD war „down“, wurde neu gestartet und wird nunmehr wiederhergestellt.

• Ein OSD im „acting“-Satz ist „down“ oder kann keine Anforderungen verarbeiten und ein anderer OSD hat vorübergehend dessen Aufgaben übernommen.

  Ceph verarbeitet eine Client-Anforderung mit dem „up“-Satz, also dem Satz der OSDs, die die Anforderungen tatsächlich verarbeiten. In den meisten Fällen sind der „up“-Satz und der „acting“-Satz praktisch identisch. Ist dies nicht der Fall, kann dies darauf hinweisen, dass Ceph gerade Daten migriert, ein OSD wiederhergestellt wird oder ein Problem vorliegt (in diesen Szenarien gibt Ceph in der Regel den Status HEALTH WARN mit der Meldung „stuck stale“ zurück).

Mit folgendem Kommando rufen Sie eine Liste der Platzierungsgruppen ab:

cephuser@adm > ceph pg dump

Mit folgendem Kommando stellen Sie fest, welche OSDs sich im „acting“-Satz oder im „up“-Satz einer bestimmten Platzierungsgruppe befinden:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

Das Ergebnis umfasst die osdmap-Epoche (eNNN), die Nummer der Platzierungsgruppe (PG_NUM), die OSDs im „up“-Satz („up“) sowie die OSDs im „acting“-Satz („acting“):

Tipp: Hinweis auf Clusterprobleme

Wenn der „up“-Satz und der „acting“-Satz nicht übereinstimmen, kann dies darauf hinweisen, dass der Cluster sich gerade ausgleicht oder dass ein potenzielles Problem mit dem Cluster vorliegt.

12.9.3 Peering #

 

Bevor Sie Daten in eine Platzierungsgruppe schreiben können, muss sie den Status active und auch den Status clean aufweisen. Damit Ceph den aktuellen Status einer Fertigungsgruppe feststellen kann, führt der primäre OSD der Platzierungsgruppe (der erste OSD im „acting“-Satz) ein Peering mit dem sekundären und dem tertiären OSD durch, sodass sie sich über den aktuellen Status der Platzierungsgruppe abstimmen können (unter der Annahme eines Pools mit drei Reproduktionen der PG).

Abbildung 12.2: Peering-Schema #

 

12.9.4 Überwachen des Zustands von Platzierungsgruppen #

 

Wenn Sie ein Kommando wie ceph health, ceph -s oder ceph -w ausführen, gibt der Cluster nicht immer die Meldung HEALTH OK zurück. Sobald Sie geprüft haben, ob die OSDs aktiv sind, prüfen Sie auch den Status der Platzierungsgruppen.

Unter verschiedenen, mit dem Platzierungsgruppen-Peering zusammenhängenden Umständen ist zu erwarten, dass der Cluster nicht die Meldung HEALTH OK zurückgibt:

• Sie haben einen Pool erstellt, und die Platzierungsgruppen haben noch nicht das Peering durchgeführt.

• Die Platzierungsgruppen werden wiederhergestellt.

• Sie haben einen OSD in einen Cluster eingefügt oder daraus entfernt.

• Sie haben die CRUSH-Zuordnung geändert, und Ihre Platzierungsgruppen werden migriert.

• Die verschiedenen Reproduktionen einer Platzierungsgruppe enthalten inkonsistente Daten.

• Ceph führt das Scrubbing der Reproduktionen einer Platzierungsgruppe durch.

• Die Speicherkapazität reicht nicht für die Ausgleichsoperationen von Ceph aus.

Wenn Ceph aus den obigen Gründen die Meldung HEALTH WARN ausgibt, ist dies kein Grund zur Sorge. In zahlreichen Fällen kann sich der Cluster selbst wiederherstellen. In bestimmten Fällen müssen Sie jedoch selbst gewisse Maßnahmen ergreifen. Bei der Überwachung der OSDs ist in jedem Fall darauf zu achten, dass alle Platzierungsgruppen den Status „active“ und nach Möglichkeit auch den Status „clean“ besitzen, wenn der Cluster selbst betriebsbereit und aktiv ist. Mit folgendem Kommando rufen Sie den Status aller Platzierungsgruppen ab:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

Das Ergebnis umfasst die Gesamtanzahl der Platzierungsgruppen (x), die Anzahl der Platzierungsgruppen in einem bestimmten Status, z. B. „active+clean“ (y) sowie die gespeicherte Datenmenge (z).

Neben dem Status der Platzierungsgruppen gibt Ceph außerdem die belegte Speicherkapazität (aa), die verbleibende Speicherkapazität (bb) und die Gesamtspeicherkapazität für die Platzierungsgruppe zurück. Diese Zahlen sind in einigen Fällen von großer Bedeutung:

• Sie nähern sich dem Wert für near full ratio oder full ratio.

• Die Daten werden aufgrund eines Fehlers in der CRUSH-Konfiguration nicht im Cluster verteilt.

Tipp: Platzierungsgruppen-IDs

Die Platzierungsgruppen-IDs bestehen aus der Pool-Nummer (nicht dem Pool-Namen), gefolgt von einem Punkt (.) und der eigentlichen Platzierungsgruppen-ID (eine hexadezimale Zahl). Die Pool-Nummern und zugehörige Namen sind in der Ausgabe des Kommandos ceph osd lspools ersichtlich. Der Standard-Pool rbd entspricht beispielsweise der Pool-Nummer 0. Eine vollständige Platzierungsgruppen-ID weist das folgende Format auf:

POOL_NUM.PG_ID

und sieht in der Regel wie folgt aus:

0.1f

Mit folgendem Kommando rufen Sie eine Liste der Platzierungsgruppen ab:

cephuser@adm > ceph pg dump

Sie können auch die Ausgabe im JSON-Format formatieren und in einer Datei speichern:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Mit folgendem Kommando fragen Sie eine bestimmte Platzierungsgruppe ab:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

In der nachfolgenden Liste werden die gängigen Statusangaben für Platzierungsgruppen näher beschrieben.

CREATING

Beim Erstellen eines Pools wird die angegebene Anzahl der Platzierungsgruppen erstellt. Ceph gibt „creating“ zurück, während eine Platzierungsgruppe erstellt wird. Beim Erstellen führen die OSDs im „acting“-Satz der Platzierungsgruppe das Peering durch. Nach dem Peering sollte die Platzierungsgruppe den Status „active+clean“ aufweisen, sodass ein Ceph-Client in die Platzierungsgruppe schreiben kann.

Abbildung 12.3: Statusangaben für Platzierungsgruppen #

 

PEERING

Beim Peering einer Platzierungsgruppe stimmt Ceph die OSDs, auf denen die Reproduktionen der Platzierung gespeichert sind, hinsichtlich des Status der Objekte und Metadaten in der Platzierungsgruppe ab. Nach dem Peering zeigen also alle OSDs, auf denen die Platzierungsgruppe gespeichert ist, den aktuellen Status dieser Gruppe. Der Abschluss des Peering-Prozesses bedeutet jedoch nicht, dass jede Reproduktion den aktuellen Inhalt enthält.

Anmerkung: Maßgeblicher Verlauf

Ceph bestätigt nur dann einen Schreibvorgang auf einen Client, wenn alle OSDs im „acting“-Satz den Schreibvorgang dauerhaft speichern. Auf diese Weise ist sichergestellt, dass mindestens ein Mitglied des „acting“-Satzes einen Datensatz pro bestätigtem Schreibvorgang seit dem letzten erfolgreichen Peering-Vorgang besitzt.

Anhand der sorgfältigen Aufzeichnungen der einzelnen bestätigten Schreiboperationen kann Ceph einen neuen maßgeblichen Verlauf der Platzierungsgruppe aufstellen und fortführen – also einen vollständigen, geordneten Satz von Operationen, mit dem das Exemplar einer Platzierungsgruppe, die sich auf einem OSD befindet, auf den neuesten Stand gebracht werden kann.

AKTIV

Nach Abschluss des Peering-Prozesses kann eine Platzierungsgruppe den Status active erhalten. Im Status active stehen die Daten in der Platzierungsgruppe im Allgemeinen in der primären Platzierungsgruppe zur Verfügung, die Reproduktionen dagegen für Lese- und Schreiboperationen.

CLEAN

Wenn eine Platzierungsgruppe den Status clean aufweist, haben der primäre OSD und die Reproduktions-OSDs das Peering erfolgreich beendet, und es gibt keine nicht zugeordneten Reproduktionen für die Platzierungsgruppe. Ceph hat alle Objekte in der Platzierungsgruppe so oft wie gefordert reproduziert.

DEGRADED

Wenn ein Client ein Objekt in den primären OSD schreibt, ist der primäre OSD dafür zuständig, die Reproduktionen in die Reproduktions-OSDs zu schreiben. Sobald der primäre OSD das Objekt in den Speicher geschrieben hat, verbleibt die Platzierungsgruppe so lange im Status „degraded“, bis der primäre OSD eine Bestätigung von den Reproduktions-OSDs erhält, dass Ceph die Reproduktionsobjekte erfolgreich erstellt hat.

Eine Platzierungsgruppe kann dann den Status „active+degraded“ aufweisen, wenn ein OSD den Status „active“ besitzt, obwohl er noch nicht alle Objekte enthält. Wenn ein OSD ausfällt, kennzeichnet Ceph die einzelnen Platzierungsgruppen, die diesem OSD zugewiesen sind, als „degraded“. Sobald der OSD wieder funktionsfähig ist, müssen die OSDs das Peering wiederholen. Wenn eine eingeschränkt leistungsfähige Platzierungsgruppe den Status „active“ aufweist, kann ein Client jedoch weiterhin in ein neues Objekt in dieser Gruppe schreiben.

Wenn ein OSD den Status „down“ aufweist und die Bedingung „degraded“ weiterhin vorliegt, kennzeichnet Ceph den ausgefallenen OSD als außerhalb des Clusters („out“) und ordnet die Daten des „down“-OSDs einem anderen OSD zu. Der Zeitraum zwischen der Kennzeichnung als „down“ und der Kennzeichnung als „out“ wird durch die Option mon osd down out interval gesteuert (Standardwert 600 Sekunden).

Eine Platzierungsgruppe kann auch dann den Status „degraded“ erhalten, wenn Ceph mindestens ein Objekt, das sich in der Platzierungsgruppe befinden sollte, nicht auffinden kann. Es ist zwar nicht möglich, in nicht gefundenen Objekten zu lesen oder zu schreiben, doch Sie können weiterhin auf alle anderen Objekte in der „degraded“-Platzierungsgruppe zugreifen.

RECOVERING

Ceph ist für die Fehlertoleranz in Situationen mit anhaltenden Hardware- und Softwareproblemen ausgelegt. Wenn ein OSD ausfällt („down“), bleibt sein Inhalt hinter dem Status anderer Reproduktionen in den Platzierungsgruppen zurück. Sobald der OSD wieder funktionsfähig ist („up“), muss der Inhalt der Platzierungsgruppen gemäß dem aktuellen Stand aktualisiert werden. In diesem Zeitraum befindet sich der OSD im Status „recovering“.

Die Wiederherstellung ist nicht unbedingt trivial, da ein Hardwarefehler durchaus eine Kettenreaktion mit Ausfall mehrerer OSDs auslösen kann. Wenn beispielsweise ein Netzwerkschalter für ein Rack oder einen Schrank ausfällt, können die OSDs zahlreicher Hostmaschinen unter Umständen hinter den aktuellen Status des Clusters zurückfallen. Sobald der Fehler behoben wurde, muss jeder einzelne OSD wiederhergestellt werden.

Ceph bietet verschiedene Einstellungen für den Ausgleich der Ressourcenkonflikte zwischen neuen Serviceanforderungen und der Notwendigkeit, Datenobjekte wiederherzustellen und die Platzierungsgruppen wieder auf den neuesten Stand zu bringen. Mit der Einstellung osd recovery delay startkann ein OSD vor Beginn des Wiederherstellungsprozesses neu starten, das Peering erneut durchführen und sogar einige Wiederholungsanforderungen verarbeiten. Die Einstellung osd recovery thread timeout legt eine Thread-Zeitüberschreitung fest, da mehrere OSDs gestaffelt ausfallen, neu starten und das Peering erneut durchführen können. Die Einstellung osd recovery max active beschränkt die Anzahl der Wiederherstellungsanforderungen, die ein OSD gleichzeitig verarbeitet, damit der OSD nicht ausfällt. Die Einstellung osd recovery max chunk beschränkt die Größe der wiederhergestellten Datenblöcke, sodass eine Überlastung des Netzwerks verhindert wird.

BACK FILLING

Wenn ein neuer OSD in den Cluster eintritt, weist CRUSH die Platzierungsgruppen von den OSDs im Cluster zum soeben hinzugefügten OSD zu. Wird die sofortige Annahme der neu zugewiesenen Platzierungsgruppen durch den neuen OSD erzwungen, kann dies den OSD immens belasten. Durch den Ausgleich des OSD mit den Platzierungsgruppen kann dieser Prozess im Hintergrund beginnen. Nach erfolgtem Ausgleich verarbeitet der neue OSD die ersten Anforderungen, sobald er dazu bereit ist.

Während des Ausgleichs werden ggf. verschiedene Statusangaben angezeigt: „backfill_wait“, bedeutet, dass ein Ausgleichsvorgang aussteht, jedoch noch nicht gestartet wurde; „backfill“ bedeutet, dass ein Ausgleichsvorgang läuft; „backfill_too_full“ bedeutet, dass ein Ausgleichsvorgang angefordert wurde, jedoch aufgrund unzureichender Speicherkapazität nicht ausgeführt werden konnte. Wenn der Ausdruck einer Platzierungsgruppe nicht durchgeführt werden kann, gilt sie als „unvollständig“.

Ceph bietet verschiedene Einstellungen für die Bewältigung der Belastung im Zusammenhang mit der Neuzuweisung von Placement Groups zu einem OSD (insbesondere zu einem neuen OSD). Standardmäßig beschränkt osd max backfills die Anzahl gleichzeitiger Ausgleichsvorgänge mit einem OSD auf maximal 10 Vorgänge. Mit backfill full ratio kann ein OSD eine Ausgleichsanforderung verweigern, wenn der OSD sich seiner „full“-Quote nähert (standardmäßig 90 %). Dieser Wert kann mit dem Kommando ceph osd set-backfillfull-ratio geändert werden. Wenn ein OSD eine Ausgleichsanforderung verweigert, kann der OSD die Anforderung mit osd backfill retry interval wiederholen (standardmäßig nach 10 Sekunden). Die OSDs können außerdem die Scanintervalle (standardmäßig 64 und 512) mit osd backfill scan min und osd backfill scan max verwalten.

REMAPPED

Wenn sich der „acting“-Satz ändert, der für eine Platzierungsgruppe zuständig ist, werden die Daten vom bisherigen „acting“-Satz zum neuen „acting“-Satz migriert. Ein neuer primärer OSD kann unter Umständen erst nach einiger Zeit die ersten Anforderungen verarbeiten. In diesem Fall weist er den bisherigen primären OSD an, weiterhin die Anforderungen zu verarbeiten, bis die Migration der Platzierungsgruppe abgeschlossen ist. Nach erfolgter Datenmigration greift die Zuordnung auf den primären OSD des neuen „acting“-Satzes zurück.

INAKTIV

Obwohl Ceph mithilfe von Heartbeats prüft, ob die Hosts und Daemons ausgeführt werden, können die ceph-osd-Daemons in den Status „stuck“ gelangen, in dem sie die Statistiken nicht zeitnah melden (z. B. bei einem vorübergehenden Netzwerkfehler). Standardmäßig melden die OSD-Daemons in Abständen von einer halben Sekunde (0,5) ihre Statistiken zu Platzierungsgruppen, Startvorgängen und Fehlern, also in deutlich kürzeren Abständen als die Heartbeat-Grenzwerte. Wenn der primäre OSD im „acting“-Satz keine Meldung an den Monitor übergibt oder wenn andere OSDs den primären OSD als „down“ gemeldet haben, kennzeichnen die Monitors die Platzierungsgruppe als „stale“.

Beim Starten des Clusters wird häufig der Status „stale“ angezeigt, bis der Peering-Prozess abgeschlossen ist. Wenn der Cluster eine Weile aktiv war, weisen Platzierungsgruppen mit dem Status „stale“ darauf hin, dass der primäre OSD dieser Platzierungsgruppen ausgefallen ist oder keine Platzierungsgruppenstatistiken an den Monitor meldet.

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

cephuser@adm > rados -p data ls

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

cephuser@adm > rados rm test-object-1 --pool=data

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

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

Tipp: Entfernen Sie die OSDs

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

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

Wichtig

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

root@master # salt-key -d minion_id

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

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

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 Löschen von Datenträgergeräten #

 

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

ceph orch device zap HOST_NAME DISK_DEVICE

Beispiel:

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

Anmerkung

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

13.4.3 Hinzufügen von OSDs mit der DriveGroups-Spezifikation #

 

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

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

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

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

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

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

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

13.4.3.1 Nicht verwaltete OSDs #

 

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

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

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

Tipp

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

13.4.3.2 DriveGroups-Spezifikation #

 

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Anmerkung

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

13.4.3.3 Abstimmung von Datenträgergeräten #

 

Sie können die Spezifikation mit folgenden Filtern beschreiben:

• Nach Datenträgermodell:

  model: DISK_MODEL_STRING

• Nach Datenträgerhersteller:

  vendor: DISK_VENDOR_STRING

  

  Tipp

  Geben Sie den DISK_VENDOR_STRING immer in Kleinbuchstaben ein.

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

  cephuser@adm > ceph orch device ls
  HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
  ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
  ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
  [...]

• Angabe, ob ein rotierender oder ein nicht rotierender Datenträger vorliegt. SSDs und NVMe-Laufwerke sind keine rotierenden Datenträger.

  rotational: 0

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

  data_devices:
    all: true

• Zusätzlich mit Einschränkung der Anzahl passender Datenträger

  limit: 10

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

 

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

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

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

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

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

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

 

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

Anmerkung: Anführungszeichen erforderlich

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

Tipp: Abkürzungen für Einheiten

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

13.4.3.5 Beispiele für DriveGroups #

 

Dieser Abschnitt enthält Beispiele verschiedener OSD-Einrichtungen.

Beispiel 13.2: Einfache Einrichtung #

 

Dieses Beispiel zeigt zwei Knoten mit derselben Einrichtung:

• 20 HDDs

  • Hersteller: Intel

  • Modell: SSD-123-foo

  • Größe: 4 TB

• 2 SSDs

  • Hersteller: Micron

  • Modell: MC-55-44-ZX

  • Größe: 512 GB

Die entsprechende Datei drive_groups.yml sieht wie folgt aus:

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

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

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

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

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

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

Beispiel 13.3: Erweiterte Einrichtung #

 

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

• 20 HDDs

  • Hersteller: Intel

  • Modell: SSD-123-foo

  • Größe: 4 TB

• 12 SSDs

  • Hersteller: Micron

  • Modell: MC-55-44-ZX

  • Größe: 512 GB

• 2 NVMes

  • Hersteller: Samsung

  • Modell: NVME-QQQQ-987

  • Größe: 256 GB

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

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

Beispiel 13.4: Erweiterte Einrichtung mit nicht einheitlichen Knoten #

 

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

Knoten 1–5:

• 20 HDDs

  • Hersteller: Intel

  • Modell: SSD-123-foo

  • Größe: 4 TB

• 2 SSDs

  • Hersteller: Micron

  • Modell: MC-55-44-ZX

  • Größe: 512 GB

Knoten 6–10:

• 5 NVMes

  • Hersteller: Intel

  • Modell: SSD-123-foo

  • Größe: 4 TB

• 20 SSDs

  • Hersteller: Micron

  • Modell: MC-55-44-ZX

  • Größe: 512 GB

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

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

gefolgt von:

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

Beispiel 13.5: Experteneinrichtung #

 

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

• 20 HDDs

  • Hersteller: Intel

  • Modell: SSD-123-foo

  • Größe: 4 TB

• 2 SSDs

  • Hersteller: Micron

  • Modell: MC-55-44-ZX

  • Größe: 512 GB

• 2 NVMes

  • Hersteller: Samsung

  • Modell: NVME-QQQQ-987

  • Größe: 256 GB

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

Beispiel 13.6: Komplexe (und unwahrscheinliche) Einrichtung #

 

In der folgenden Einrichtung soll Folgendes definiert werden:

• 20 HDDs mit 1 NVMe

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

• 8 SSDs mit 1 NVMe

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

• 1 HDD fungiert als Ersatz und soll nicht bereitgestellt werden

Zusammenfassung der verwendeten Datenträger:

• 23 HDDs

  • Hersteller: Intel

  • Modell: SSD-123-foo

  • Größe: 4 TB

• 10 SSDs

  • Hersteller: Micron

  • Modell: MC-55-44-ZX

  • Größe: 512 GB

• 1 NVMe

  • Hersteller: Samsung

  • Modell: NVME-QQQQ-987

  • Größe: 256 GB

Die DriveGroups-Definition lautet:

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

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