5 Bereitstellung mit cephadm #
SUSE Enterprise Storage 7 verwendet das Salt-basierte ceph-salt
-Werkzeug, um das Betriebssystem auf jedem beteiligten Cluster-Knoten für die Bereitstellung über cephadm vorzubereiten. cephadm richtet einen Ceph-Cluster ein und verwaltet ihn. Dazu wird vom Ceph-Manager-Daemon über SSH eine Verbindung zu den Hosts hergestellt. cephadm verwaltet den gesamten Lebenszyklus eines Ceph-Clusters. Es beginnt mit dem Bootstrapping eines winzigen Clusters auf einem einzelnen Knoten (ein MON- und MGR-Service) und verwendet dann die Orchestrierungsschnittstelle, um den Cluster auf alle Hosts zu erweitern und alle Ceph-Services bereitzustellen. Sie können dies über die Ceph-Kommandozeilenschnittstelle (CLI) oder teilweise über Ceph Dashboard (GUI) durchführen.
Beachten Sie, dass in der Ceph-Community-Dokumentation das Kommando cephadm bootstrap
bei der Erstinstallation verwendet wird. ceph-salt
ruft das Kommando cephadm bootstrap
auf und sollte nicht direkt ausgeführt werden. Eine manuelle Bereitstellung eines Ceph-Clusters mit cephadm bootstrap
wird nicht unterstützt.
Sie müssen die folgenden Aufgaben ausführen, um einen Ceph-Cluster mithilfe von cephadm bereitzustellen:
Installieren Sie das zugrunde liegende Betriebssystem (SUSE Linux Enterprise Server 15 SP2) auf allen Cluster-Knoten und nehmen Sie die Grundkonfiguration vor.
Stellen Sie die Salt-Infrastruktur auf allen Cluster-Knoten bereit, um die ersten Bereitstellungsvorbereitungen über
ceph-salt
durchzuführen.Konfigurieren Sie die grundlegenden Eigenschaften des Clusters über
ceph-salt
und stellen Sie ihn bereit.Fügen Sie dem Cluster neue Knoten und Rollen hinzu und stellen Sie darauf mit cephadm Services bereit.
5.1 Installieren und Konfigurieren von SUSE Linux Enterprise Server #
Installieren und registrieren Sie SUSE Linux Enterprise Server 15 SP2 auf jedem Cluster-Knoten. Während der Installation von SUSE Enterprise Storage ist der Zugriff auf die Aktualisierungs-Repositorys erforderlich, weshalb eine Registrierung obligatorisch ist. Fügen Sie mindestens die folgenden Module hinzu:
Basesystem Module
Server Applications Module
Weitere Einzelheiten zur Installation von SUSE Linux Enterprise Server finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.html.
Installieren Sie die SUSE Enterprise Storage 7-Erweiterung auf jedem Cluster-Knoten.
Tipp: Installation von SUSE Enterprise Storage zusammen mit SUSE Linux Enterprise ServerSie können die SUSE Enterprise Storage 7-Erweiterung entweder nach der Installation von SUSE Linux Enterprise Server 15 SP2 separat installieren oder sie während des Installationsvorgangs von SUSE Linux Enterprise Server 15 SP2 hinzufügen.
Weitere Details zur Installation von Erweiterungen finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.html.
Konfigurieren Sie Netzwerkeinstellungen einschließlich der ordnungsgemäßen DNS-Namensauflösung auf jedem Knoten. Weitere Informationen zum Konfigurieren eines Netzwerks finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yast. Weitere Informationen zum Konfigurieren eines DNS Servers finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.html.
5.2 Bereitstellen von Salt #
SUSE Enterprise Storage verwendet Salt und ceph-salt
für die anfängliche Vorbereitung des Clusters. Mit Salt können Sie Kommandos auf mehreren Cluster-Knoten gleichzeitig von einem dedizierten Host, dem Salt Master, aus konfigurieren und ausführen. Vor dem Bereitstellen von Salt sollten Sie folgende wichtige Punkte beachten:
Salt Minions sind die Knoten, die von einem dedizierten Knoten namens Salt Master gesteuert werden.
Wenn der Salt-Master-Host Teil des Ceph-Clusters sein soll, muss er seinen eigenen Salt Minion ausführen, was aber keine Voraussetzung ist.
Tipp: Freigeben mehrerer Rollen pro ServerSie erreichen die optimale Leistung Ihres Ceph-Clusters, wenn jede Rolle in einem separaten Knoten bereitgestellt wird. Manchmal ist es jedoch bei Bereitstellungen erforderlich, einen Knoten für mehrere Rollen freizugeben. Stellen Sie die Ceph OSD-, Metadatenserver- oder Ceph Monitor-Rolle nicht auf dem Admin-Knoten bereit, um Probleme mit der Leistung und dem Upgrade-Vorgang zu vermeiden.
Salt Minions müssen den Hostnamen des Salt Masters im gesamten Netzwerk korrekt auflösen. Standardmäßig suchen sie nach dem Hostnamen
salt
. Sie können jedoch auch in der Datei/etc/salt/minion
jeden vom Netzwerk erreichbaren Hostnamen angeben.
Installieren Sie
salt-master
auf dem Salt-Master-Knoten:root@master #
zypper in salt-masterÜberprüfen Sie, ob der
salt-master
-Service aktiviert und gestartet wurde und aktivieren und starten Sie ihn gegebenenfalls:root@master #
systemctl enable salt-master.serviceroot@master #
systemctl start salt-master.serviceFalls Sie beabsichtigen, die Firewall zu verwenden, überprüfen Sie, ob im Salt-Master-Knoten die Ports 4505 und 4506 für alle Salt-Minion-Knoten offen sind. Wenn die Ports geschlossen sind, können Sie sie mit dem Kommando
yast2 firewall
öffnen. Lassen Sie dazu den -Service für die entsprechende Zone zu. Zum BeispielÖffentlich
.Installieren Sie das Paket
salt-minion
in allen Minion-Knoten.root@minion >
zypper in salt-minionBearbeiten Sie
/etc/salt/minion
und kommentieren Sie die folgende Zeile aus:#log_level_logfile: warning
Ändern Sie die Protokollstufe
Warnung
zuInfo
.Anmerkung:log_level_logfile
undlog_level
Während mit
log_level
gesteuert wird, welche Protokollmeldungen auf dem Bildschirm angezeigt werden, wird mitlog_level_logfile
gesteuert, welche Protokollmeldungen in/var/log/salt/minion
geschrieben werden.AnmerkungStellen Sie sicher, dass Sie die Protokollebene auf allen Cluster-Knoten (Minions) ändern.
Vergewissern Sie sich, dass der vollqualifizierte Domänenname jedes Knotens von allen anderen Knoten in eine IP-Adresse im öffentlichen Clusternetzwerk aufgelöst werden kann.
Konfigurieren Sie alle Minions für die Verbindung mit dem Master. Wenn Ihr Salt Master mit dem Hostnamen
salt
nicht erreichbar ist, bearbeiten Sie die Datei/etc/salt/minion
oder erstellen Sie eine neue Datei/etc/salt/minion.d/master.conf
mit folgendem Inhalt:master: host_name_of_salt_master
Wenn Sie an den oben genannten Konfigurationsdateien Änderungen vorgenommen haben, starten Sie den Salt-Service auf allen entsprechenden Salt Minions neu:
root@minion >
systemctl restart salt-minion.serviceÜberprüfen Sie, ob der
salt-minion
Service in allen Knoten aktiviert und gestartet wurde. Aktivieren und starten Sie ihn, falls erforderlich:root #
systemctl enable salt-minion.serviceroot #
systemctl start salt-minion.serviceÜberprüfen Sie den Fingerabdruck der einzelnen Salt Minions und akzeptieren Sie alle Salt-Schlüssel am Salt Master, wenn die Fingerabdrücke übereinstimmen.
AnmerkungWenn ein leerer Fingerabdruck des Salt Minions zurückgegeben wird, prüfen Sie, ob der Salt Minion über eine Salt-Master-Konfiguration verfügt und ob der Minion mit dem Salt Master kommunizieren kann.
Zeigen Sie den Fingerabdruck der einzelnen Minions an:
root@minion >
salt-call --local key.finger local: 3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...Nachdem Sie die Fingerabdrücke aller Salt Minions gesammelt haben, listen Sie die Fingerabdrücke aller nicht akzeptierten Minion-Schlüssel am Salt Master auf:
root@master #
salt-key -F [...] Unaccepted Keys: minion1: 3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...Wenn die Fingerabdrücke der Minions übereinstimmen, akzeptieren Sie sie:
root@master #
salt-key --accept-allVerifizieren Sie, dass die Schlüssel akzeptiert wurden:
root@master #
salt-key --list-allTesten Sie, ob alle Salt Minions antworten:
root@master #
salt-run manage.status
5.3 Bereitstellen des Ceph-Clusters #
In diesem Abschnitt werden Sie durch den Prozess der Bereitstellung eines Ceph-Basisclusters geführt. Lesen Sie die folgenden Unterabschnitte sorgfältig durch und führen Sie die enthaltenen Kommandos in der angegebenen Reihenfolge aus.
5.3.1 Installieren von ceph-salt
#
ceph-salt
stellt Werkzeuge zum Bereitstellen von Ceph-Clustern bereit, die von cephadm verwaltet werden. ceph-salt
nutzt die Salt-Infrastruktur, um die Verwaltung des Betriebssystems – beispielsweise Softwareaktualisierungen oder Zeitsynchronisierung – durchzuführen und Rollen für Salt Minions zu definieren.
Installieren Sie am Salt Master das Paket ceph-salt :
root@master #
zypper install ceph-salt
Mit obigem Kommando wurde ceph-salt-formula als Abhängigkeit installiert, die die Salt-Master-Konfiguration durch Einfügen zusätzlicher Dateien im Verzeichnis /etc/salt/master.d
geändert hat. Um die Änderungen anzuwenden, starten Sie salt-master.service
neu und synchronisieren Sie die Salt-Module:
root@master #
systemctl restart salt-master.serviceroot@master #
salt \* saltutil.sync_all
5.3.2 Konfigurieren der Clustereigenschaften #
Konfigurieren Sie mit dem Kommando ceph-salt config
die grundlegenden Eigenschaften des Clusters.
Die Datei /etc/ceph/ceph.conf
wird von cephadm verwaltet und sollte nicht von Benutzern bearbeitet werden. Die Ceph-Konfigurationsparameter sollten mit dem neuen Kommando ceph config
festgelegt werden. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 28.2, „Konfigurationsdatenbank“.
5.3.2.1 Verwenden der ceph-salt
-Shell #
Wenn Sie ceph-salt config
ohne Pfad oder Unterbefehl ausführen, gelangen Sie in eine interaktive ceph-salt
-Shell. Die Shell ist praktisch, wenn Sie mehrere Eigenschaften in einem Stapel konfigurieren müssen und nicht die vollständige Kommandosyntax eingeben möchten.
root@master #
ceph-salt config/>
ls o- / ............................................................... [...] o- ceph_cluster .................................................. [...] | o- minions .............................................. [no minions] | o- roles ....................................................... [...] | o- admin .............................................. [no minions] | o- bootstrap ........................................... [no minion] | o- cephadm ............................................ [no minions] | o- tuned ..................................................... [...] | o- latency .......................................... [no minions] | o- throughput ....................................... [no minions] o- cephadm_bootstrap ............................................. [...] | o- advanced .................................................... [...] | o- ceph_conf ................................................... [...] | o- ceph_image_path .................................. [ no image path] | o- dashboard ................................................... [...] | | o- force_password_update ................................. [enabled] | | o- password ................................................ [admin] | | o- ssl_certificate ....................................... [not set] | | o- ssl_certificate_key ................................... [not set] | | o- username ................................................ [admin] | o- mon_ip .................................................. [not set] o- containers .................................................... [...] | o- registries_conf ......................................... [enabled] | | o- registries .............................................. [empty] | o- registry_auth ............................................... [...] | o- password .............................................. [not set] | o- registry .............................................. [not set] | o- username .............................................. [not set] o- ssh ............................................... [no key pair set] | o- private_key .................................. [no private key set] | o- public_key .................................... [no public key set] o- time_server ........................... [enabled, no server host set] o- external_servers .......................................... [empty] o- servers ................................................... [empty] o- subnet .................................................. [not set]
Wie Sie der Ausgabe des ls
-Kommandos von ceph-salt
entnehmen können, ist die Cluster-Konfiguration in einer Baumstruktur organisiert. Sie haben zwei Möglichkeiten zum Konfigurieren einer bestimmten Eigenschaft des Clusters in der ceph-salt
-Shell:
Führen Sie das Kommando von der aktuellen Position aus und geben Sie den absoluten Pfad zur Eigenschaft als erstes Argument ein:
/>
/cephadm_bootstrap/dashboard ls o- dashboard ....................................................... [...] o- force_password_update ..................................... [enabled] o- password .................................................... [admin] o- ssl_certificate ........................................... [not set] o- ssl_certificate_key ....................................... [not set] o- username .................................................... [admin]/> /cephadm_bootstrap/dashboard/username set ceph-admin
Value set.Wechseln Sie zu dem Pfad, dessen Eigenschaft Sie konfigurieren müssen, und führen Sie das Kommando aus:
/>
cd /cephadm_bootstrap/dashboard//ceph_cluster/minions>
ls o- dashboard ....................................................... [...] o- force_password_update ..................................... [enabled] o- password .................................................... [admin] o- ssl_certificate ........................................... [not set] o- ssl_certificate_key ....................................... [not set] o- username ................................................[ceph-admin]
Während Sie sich in einer ceph-salt
-Shell befinden, können Sie die Funktion der automatischen Vervollständigung ähnlich wie in einer normalen Linux-Shell (Bash) verwenden. Sie vervollständigt Konfigurationspfade, Unterkommandos oder Salt-Minion-Namen. Beim automatischen Vervollständigen eines Konfigurationspfads haben Sie zwei Möglichkeiten:
Drücken Sie zweimal die TAB-Taste →|, damit die Shell einen Pfad relativ zu Ihrer aktuellen Position beendet.
Geben Sie / ein und drücken Sie zweimal die TAB-Taste →|, damit die Shell einen absoluten Pfad beendet.
Wenn Sie cd
aus der ceph-salt
-Shell heraus ohne Pfad eingeben, wird durch das Kommando eine Baumstruktur der Cluster-Konfiguration ausgegeben, wobei die Zeile des aktuellen Pfads aktiv ist. Mit den Cursortasten nach oben und nach unten navigieren Sie durch die einzelnen Zeilen. Nach dem Bestätigen mit der Eingabetaste Eingabetaste wird der Konfigurationspfad zum letzten aktiven Pfad geändert.
Wir verwenden eine einzige Kommandosyntax ohne Eingabe der ceph-salt
-Shell, um die Dokumentation konsistent zu halten. Sie können zum Beispiel den Cluster-Konfigurationsbaum mit folgendem Kommando auflisten:
root@master #
ceph-salt config ls
5.3.2.2 Hinzufügen von Salt Minions #
Nehmen Sie alle oder eine Teilmenge der von uns in Abschnitt 5.2, „Bereitstellen von Salt“ bereitgestellten und akzeptierten Salt Minions in die Ceph-Cluster-Konfiguration auf. Sie können die Salt Minions entweder mit ihren vollständigen Namen angeben oder mit einem Globausdruck „*“ und „?“ mehrere Salt Minions gleichzeitig hinzufügen. Verwenden Sie das Unterkommando add
unter dem Pfad /ceph_cluster/minions
. Mit folgendem Kommando werden alle akzeptierten Salt Minions hinzugefügt:
root@master #
ceph-salt config /ceph_cluster/minions add '*'
Überprüfen Sie, ob die angegebenen Salt Minions hinzugefügt wurden:
root@master #
ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
o- ses-master.example.com .................................. [no roles]
o- ses-min1.example.com .................................... [no roles]
o- ses-min2.example.com .................................... [no roles]
o- ses-min3.example.com .................................... [no roles]
o- ses-min4.example.com .................................... [no roles]
5.3.2.3 Festlegen von Salt Minions, die von cephadm verwaltet werden #
Geben Sie an, welche Knoten zum Ceph-Cluster gehören und von cephadm verwaltet werden sollen. Beziehen Sie alle Knoten ein, die Ceph-Services ausführen, sowie den Admin-Knoten:
root@master #
ceph-salt config /ceph_cluster/roles/cephadm add '*'
5.3.2.4 Festlegen des Admin Knoten #
Der Admin-Knoten ist der Knoten, auf dem die Konfigurationsdatei ceph.conf
und der Ceph-Admin-Schlüsselbund installiert sind. Normalerweise führen Sie Ceph-spezifische Kommandos auf dem Admin-Knoten aus.
In einer homogenen Umgebung, in der alle oder die meisten Hosts zu SUSE Enterprise Storage gehören, wird empfohlen, dass sich der Admin-Knoten auf demselben Host befindet wie der Salt Master.
In einer heterogenen Umgebung, in der eine Salt-Infrastruktur mehr als einen Cluster hostet (z. B. SUSE Enterprise Storage zusammen mit SUSE Manager), sollten Sie den Admin-Knoten nicht auf demselben Host wie den Salt Master platzieren.
Geben Sie den Admin-Knoten mit folgendem Kommando an:
root@master #
ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com 1 minion added.root@master #
ceph-salt config /ceph_cluster/roles/admin ls o- admin ................................................... [Minions: 1] o- ses-master.example.com ...................... [Other roles: cephadm]
ceph.conf
und den Admin-Schlüsselbund auf mehreren KnotenSie können die Ceph-Konfigurationsdatei und den Admin-Schlüsselbund auf mehreren Knoten installieren, wenn dies für Ihre Bereitstellung erforderlich ist. Vermeiden Sie aus Sicherheitsgründen, sie auf allen Knoten des Clusters zu installieren.
5.3.2.5 Festlegen des ersten MON/MGR-Knotens #
Sie müssen angeben, welcher der Salt Minions des Clusters das Bootstrapping des Clusters durchführen soll. Dieser Minion führt dann die Services Ceph Monitor und Ceph Manager als Erster aus.
root@master #
ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com Value set.root@master #
ceph-salt config /ceph_cluster/roles/bootstrap ls o- bootstrap ..................................... [ses-min1.example.com]
Zusätzlich müssen Sie die IP-Adresse des Bootstrap-MON im öffentlichen Netzwerk angeben, um sicherzustellen, dass beispielsweise der Parameter public_network
korrekt festgelegt wird:
root@master #
ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20
5.3.2.6 Festlegen von abgestimmten Profilen #
Sie müssen angeben, in welchen der Minions des Clusters aktiv abgestimmte Profile vorhanden sein sollen. Fügen Sie dazu diese Rollen mit den folgenden Kommandos explizit hinzu:
Ein Minion kann nicht gleichzeitig über die Rollen Latenz
und Durchsatz
verfügen.
root@master #
ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com Adding ses-min1.example.com... 1 minion added.root@master #
ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com Adding ses-min2.example.com... 1 minion added.
5.3.2.7 Generieren eines SSH-Schlüsselpaars #
cephadm kommuniziert mit den Cluster-Knoten über das SSH-Protokoll. Ein Benutzerkonto namens cephadm
wird automatisch erstellt und für die SSH-Kommunikation verwendet.
Sie müssen den privaten und den öffentlichen Teil des SSH-Schlüsselpaars generieren:
root@master #
ceph-salt config /ssh generate Key pair generated.root@master #
ceph-salt config /ssh ls o- ssh .................................................. [Key Pair set] o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83] o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
5.3.2.8 Konfigurieren des Zeitservers #
Alle Cluster-Knoten müssen ihre Zeit mit einer zuverlässigen Zeitquelle synchronisieren. Es gibt mehrere Szenarien für die Zeitsynchronisierung:
Deaktivieren Sie die Zeitserververarbeitung vollständig, wenn alle Cluster-Knoten bereits so konfiguriert sind, dass sie ihre Zeit mit einem NTP-Service ihrer Wahl synchronisieren:
root@master #
ceph-salt config /time_server disableGeben Sie den Hostnamen der Zeitquelle an, wenn Ihr Standort bereits über eine einzige Zeitquelle verfügt:
root@master #
ceph-salt config /time_server/servers add time-server.example.comAlternativ bietet
ceph-salt
die Möglichkeit, einen der Salt Minions so zu konfigurieren, dass er als Zeitserver für den Rest des Clusters dient. Dies wird manchmal auch als „interner Zeitserver“ bezeichnet. In diesem Szenario konfiguriertceph-salt
den internen Zeitserver (der einer der Salt Minions sein sollte) so, dass er seine Zeit mit einem externen Zeitserver, zum Beispielpool.ntp.org
, synchronisiert. Alle anderen Minions werden so konfiguriert, dass sie ihre Zeit von dem internen Zeitserver beziehen. Dies kann wie folgt erreicht werden:root@master #
ceph-salt config /time_server/servers add ses-master.example.comroot@master #
ceph-salt config /time_server/external_servers add pool.ntp.orgDie Option
/time_server/subnet
gibt das Teilnetz an, aus dem NTP-Clients auf den NTP-Server zugreifen dürfen. Sie wird automatisch festgelegt, wenn Sie/time_server/servers
angeben. Führen Sie folgendes Kommando aus, wenn Sie sie ändern oder manuell angeben müssen:root@master #
ceph-salt config /time_server/subnet set 10.20.6.0/24
Prüfen Sie die Einstellungen für den Zeitserver:
root@master #
ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
o- external_servers ............................................... [1]
| o- pool.ntp.org ............................................... [...]
o- servers ........................................................ [1]
| o- ses-master.example.com ..................................... [...]
o- subnet .............................................. [10.20.6.0/24]
Weitere Informationen zum Einrichten der Zeitsynchronisierung finden Sie unter https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yast.
5.3.2.9 Konfigurieren des Berechtigungsnachweises für die Anmeldung am Ceph Dashboard #
Ceph Dashboard ist nach der Bereitstellung des Basisclusters verfügbar. Um darauf zuzugreifen, müssen Sie einen gültigen Benutzernamen und ein Passwort festlegen, zum Beispiel:
root@master #
ceph-salt config /cephadm_bootstrap/dashboard/username set adminroot@master #
ceph-salt config /cephadm_bootstrap/dashboard/password set PWD
Standardmäßig wird der erste Dashboard-Benutzer gezwungen, sein Passwort bei der ersten Anmeldung am Dashboard zu ändern. Deaktivieren Sie diese Funktion mit folgendem Kommando:
root@master #
ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable
5.3.2.10 Konfigurieren des Pfads zu den Container-Images #
cephadm benötigt einen gültigen URI-Pfad zu Container-Images für die Bereitstellung. Prüfen Sie, ob der Standardpfad festgelegt ist:
root@master #
ceph-salt config /cephadm_bootstrap/ceph_image_path ls
Wenn kein Standardpfad festgelegt ist oder für die Bereitstellung ein bestimmter Pfad erforderlich ist, fügen Sie ihn wie folgt hinzu:
root@master #
ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph
Für den Überwachungs-Stack werden weitere Container-Images benötigt. Für eine Air-Gap-Bereitstellung sowie für die Bereitstellung von einer lokalen Registrierung sollten Sie diese Images an diesem Punkt abrufen, um Ihre lokale Registrierung entsprechend vorzubereiten.
Beachten Sie, dass diese Container-Images nicht von ceph-salt
für die Bereitstellung verwendet werden. Es ist eine Vorbereitung für einen späteren Schritt, bei dem cephadm für die Bereitstellung oder die Migration von Überwachungskomponenten eingesetzt wird.
Weitere Informationen zu den vom Überwachungs-Stack verwendeten Images und dazu, wie Sie sie anpassen können, finden Sie im Abschnitt 16.1, „Konfigurieren von benutzerdefinierten oder lokalen Images“.
5.3.2.11 Konfigurieren der Container-Registrierung #
Optional können Sie eine lokale Container-Registrierung festlegen. Sie dient als Spiegel der Registrierung registry.suse.com
. Denken Sie daran, dass Sie die lokale Registrierung neu synchronisieren müssen, wenn neue aktualisierte Container von registry.suse.com
verfügbar sind.
In den folgenden Szenarien ist es nützlich, eine lokale Registrierung zu erstellen:
Sie haben viele Cluster-Knoten und möchten Downloadzeit und Bandbreite sparen, indem Sie einen lokalen Spiegel der Container-Images erstellen.
Ihr Cluster hat keinen Zugriff auf die Online-Registrierung (eine Air-Gap-Bereitstellung), und Sie benötigen einen lokalen Spiegel, von dem Sie die Container-Images abrufen.
Wenn Konfigurations- oder Netzwerkprobleme Ihren Cluster daran hindern, über eine sichere Verbindung auf Remote-Registrierungen zuzugreifen, so benötigen Sie stattdessen eine lokale, unverschlüsselte Registrierung.
Zum Bereitstellen von Program Temporary Fixes (PTFs) auf einem unterstützten System müssen Sie eine lokale Container-Registrierung bereitstellen.
Gehen Sie folgendermaßen vor, um eine lokale Registrierungs-URL zusammen mit dem Berechtigungsnachweis für den Zugriff zu konfigurieren:
Konfigurieren Sie die URL der lokalen Registrierung:
cephuser@adm >
ceph-salt config /containers/registry_auth/registry set REGISTRY_URLKonfigurieren Sie den Benutzernamen und das Passwort für den Zugriff auf die lokale Registrierung:
cephuser@adm >
ceph-salt config /containers/registry_auth/username set REGISTRY_USERNAMEcephuser@adm >
ceph-salt config /containers/registry_auth/password set REGISTRY_PASSWORDFühren Sie
ceph-salt apply
aus, um den Salt-Pillar auf allen Minions zu aktualisieren.
Sie können einen Registrierungs-Cache konfigurieren, um zu verhindern, dass die lokale Registrierung neu synchronisiert wird, wenn neue aktualisierte Container auftauchen.
Für die Methoden der Cloud-nativen Anwendungsentwicklung und Zustellung sind eine Registrierung und eine CI/CD-Instanz (Continuous Integration/Delivery) für die Entwicklung und Produktion von Container-Images erforderlich. Sie können in dieser Instanz eine private Registrierung verwenden.
5.3.2.12 Aktivieren der Datenverschlüsselung während der Ausführung (msgr2) #
Das Messenger-v2-Protokoll (MSGR2) ist das On-Wire-Protokoll von Ceph. Es bietet einen Sicherheitsmodus, der alle Daten verschlüsselt, die über das Netzwerk übertragen werden, verkapselt Authentifizierungs-Nutzlasten und ermöglicht die zukünftige Integration von neuen Authentifizierungsmodi (wie Kerberos).
msgr2 wird derzeit nicht von Linux-Kernel-Ceph-Clients, wie CephFS und RBG, unterstützt.
Ceph-Daemons können an mehrere Ports binden, so dass sich sowohl ältere Ceph-Clients als auch neue v2-fähige Clients mit demselben Cluster verbinden können. Standardmäßig binden MONs jetzt an den neuen, von der IANA zugewiesenen Port 3300 (CE4h oder 0xCE4) für das neue v2-Protokoll. Für das alte v1-Protokoll binden Sie auch an den alten Standardport 6789.
Das v2-Protokoll (MSGR2) unterstützt zwei Verbindungsmodi:
- crc mode (CRC-Modus)
Eine starke anfängliche Authentifizierung beim Aufbauen der Verbindung und eine CRC32C-Integritätsprüfung.
- secure mode (sicherer Modus)
Eine starke anfängliche Authentifizierung beim Aufbauen der Verbindung und eine vollständige Verschlüsselung des gesamten Datenverkehrs nach der Authentifizierung, einschließlich einer kryptografischen Integritätsprüfung.
Für die meisten Verbindungen stehen Optionen zur Verfügung, mit denen die Verwendung der Modi gesteuert wird:
- ms_cluster_mode (MS_Cluster_Modus)
Der für die Intra-Clusterkommunikation zwischen Ceph-Daemons verwendete Verbindungsmodus (oder die zulässigen Modi). Wenn mehrere Modi aufgeführt sind, werden die zuerst aufgeführten Modi bevorzugt.
- ms_service_mode (MS_Service_Modus)
Eine Liste der zulässigen Modi, die für Clients beim Herstellen der Verbindung mit dem Cluster verwendet werden sollen.
- ms_client_mode (MS_Client_Modus)
Eine nach Präferenz geordnete Liste von Verbindungsmodi, die für Clients bei der Kommunikation mit einem Ceph-Cluster verwendet (oder zugelassen) werden sollen.
Parallel dazu gibt es eine Reihe von Optionen, die speziell für Monitore gelten und es Administratoren ermöglichen, unterschiedliche (in der Regel sicherere) Anforderungen an die Kommunikation mit den Monitoren festzulegen.
- ms_mon_cluster_mode (MS_MON_Cluster_Modus)
Der Verbindungsmodus (oder zulässige Modi), der zwischen den Monitoren verwendet werden soll.
- ms_mon_service_mode (MS_MON_Service_Modus)
Eine Liste der für Clients oder andere Ceph-Daemons zulässigen Modi, die beim Herstellen der Verbindung mit Monitoren verwendet werden sollen.
- ms_mon_client_mode (MS_MON_Client_Modus)
Eine nach Präferenz geordnete Liste der Verbindungsmodi, die für Clients oder Nicht-Monitor-Daemons beim Herstellen einer Verbindung mit Monitoren verwendet werden sollen.
Zum Aktivieren des MSGR2-Verschlüsselungsmodus während der Bereitstellung müssen Sie einige Konfigurationsoptionen zur ceph-salt
-Konfiguration hinzufügen, bevor Sie ceph-salt apply
ausführen.
Führen Sie für den sicheren
Modus folgende Kommandos aus.
Fügen Sie den globalen Abschnitt zu ceph_conf
im Konfigurationswerkzeug ceph-salt
hinzu:
root@master #
ceph-salt config /cephadm_bootstrap/ceph_conf add global
Wählen Sie eine der folgenden Optionen aus:
root@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"root@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"root@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"
Stellen Sie sicher, dass secure
vor crc
steht.
Führen Sie zum Erzwingen des sicheren
Modus folgende Kommandos aus:
root@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secureroot@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secureroot@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure
Wenn Sie eine der oben genannten Einstellungen ändern möchten, legen Sie die Konfigurationsänderungen im Monitor-Konfigurationsspeicher fest. Dies wird mit dem Kommando ceph config set
erreicht.
root@master #
ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]
Beispiel:
root@master #
ceph config set global ms_cluster_mode "secure crc"
Überprüfen Sie den aktuellen Wert, einschließlich des Standardwerts, mit folgendem Kommando:
root@master #
ceph config get CEPH_COMPONENT CONNECTION_OPTION
Führen Sie beispielsweise zum Abrufen des ms_cluster_mode
für OSDs folgendes Kommando aus:
root@master #
ceph config get osd ms_cluster_mode
5.3.2.13 Konfigurieren des Clusternetzwerks #
Wenn Sie ein separates Clusternetzwerk betreiben, müssen Sie optional die IP-Adresse des Clusternetzwerks festlegen, gefolgt von dem Teil der Teilnetzmaske nach dem Schrägstrich, zum Beispiel 192.168.10.22/24
.
Führen Sie zum Aktivieren von cluster_network
(Clusternetzwerk) folgende Kommandos aus:
root@master #
ceph-salt config /cephadm_bootstrap/ceph_conf add globalroot@master #
ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR
5.3.2.14 Überprüfen der Cluster-Konfiguration #
Die minimale Cluster-Konfiguration ist abgeschlossen. Überprüfen Sie sie auf offensichtliche Fehler:
root@master #
ceph-salt config ls
o- / ............................................................... [...]
o- ceph_cluster .................................................. [...]
| o- minions .............................................. [Minions: 5]
| | o- ses-master.example.com .................................. [admin]
| | o- ses-min1.example.com ......................... [bootstrap, admin]
| | o- ses-min2.example.com ................................. [no roles]
| | o- ses-min3.example.com ................................. [no roles]
| | o- ses-min4.example.com ................................. [no roles]
| o- roles ....................................................... [...]
| o- admin .............................................. [Minions: 2]
| | o- ses-master.example.com ....................... [no other roles]
| | o- ses-min1.example.com ................. [other roles: bootstrap]
| o- bootstrap ................................ [ses-min1.example.com]
| o- cephadm ............................................ [Minions: 5]
| o- tuned ..................................................... [...]
| o- latency .......................................... [no minions]
| o- throughput ....................................... [no minions]
o- cephadm_bootstrap ............................................. [...]
| o- advanced .................................................... [...]
| o- ceph_conf ................................................... [...]
| o- ceph_image_path ............... [registry.suse.com/ses/7/ceph/ceph]
| o- dashboard ................................................... [...]
| o- force_password_update ................................. [enabled]
| o- password ................................... [randomly generated]
| o- username ................................................ [admin]
| o- mon_ip ............................................ [192.168.10.20]
o- containers .................................................... [...]
| o- registries_conf ......................................... [enabled]
| | o- registries .............................................. [empty]
| o- registry_auth ............................................... [...]
| o- password .............................................. [not set]
| o- registry .............................................. [not set]
| o- username .............................................. [not set]
o- ssh .................................................. [Key Pair set]
| o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
| o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
o- time_server ............................................... [enabled]
o- external_servers .............................................. [1]
| o- 0.pt.pool.ntp.org ......................................... [...]
o- servers ....................................................... [1]
| o- ses-master.example.com .................................... [...]
o- subnet ............................................. [10.20.6.0/24]
Mit folgendem Kommando können Sie überprüfen, ob die Konfiguration des Clusters gültig ist:
root@master #
ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK
5.3.2.15 Exportieren von Cluster-Konfigurationen #
Nachdem Sie den Basiscluster konfiguriert haben und die Konfiguration gültig ist, ist es sinnvoll, die Konfiguration in eine Datei zu exportieren:
root@master #
ceph-salt export > cluster.json
Die Ausgabe von ceph-salt export
enthält den privaten SSH-Schlüssel. Wenn Sie Bedenken hinsichtlich sicherheitsrelevanter Auswirkungen haben, führen Sie dieses Kommando nur mit den entsprechenden Vorsichtsmaßnahmen aus.
Führen Sie folgendes Kommando aus, falls Sie die Cluster-Konfiguration unterbrechen und zu einem Sicherungszustand zurückkehren müssen:
root@master #
ceph-salt import cluster.json
5.3.3 Aktualisieren von Knoten und Bootstrapping von Minimalclustern #
Aktualisieren Sie vor dem Bereitstellen des Clusters alle Softwarepakete auf allen Knoten:
root@master #
ceph-salt update
Wenn ein Knoten während der Aktualisierung Reboot is needed
(Reboot erforderlich) meldet, wurden wichtige Betriebssystempakete (z. B. der Kernel) auf eine neuere Version aktualisiert. Sie müssen den Knoten daraufhin neu booten, um die Änderungen zu übernehmen.
Für einen erforderlichen Reboot aller Knoten hängen Sie entweder die Option --reboot
an
root@master #
ceph-salt update --reboot
oder Sie booten sie neu in einem separaten Schritt:
root@master #
ceph-salt reboot
Der Salt Master wird niemals mit den Kommandos ceph-salt update --reboot
oder ceph-salt reboot
neu gebootet. Wenn der Salt Master neu gebootet werden muss, müssen Sie ihn manuell neu booten.
Führen Sie nach dem Aktualisieren des Clusters ein Bootstrapping des Minimalclusters aus:
root@master #
ceph-salt apply
Wenn das Bootstrapping abgeschlossen ist, verfügt der Cluster über einen Ceph Monitor und einen Ceph Manager.
Mit obigem Kommando wird eine interaktive Benutzeroberfläche geöffnet, die den aktuellen Fortschritt der einzelnen Minions anzeigt.
Wenn Sie die Konfiguration über ein Skript anwenden müssen, gibt es auch einen nicht-interaktiven Modus für die Bereitstellung. Dies ist auch nützlich, wenn Sie den Cluster von einem Remote-Rechner aus bereitstellen, da das ständige Aktualisieren der Fortschrittsinformationen auf dem Bildschirm über das Netzwerk störend sein kann:
root@master #
ceph-salt apply --non-interactive
5.3.4 Prüfen der letzten Schritte #
Nach dem Ausführen des Kommandos ceph-salt apply
sollten Sie einen Ceph Monitor und einen Ceph Manager zur Verfügung haben. Sie sollten das Kommando ceph status
erfolgreich auf jedem der Minions ausführen können, denen die Admin
-Rolle als root
oder der Benutzer cephadm
mit sudo
zugewiesen wurde.
In den nächsten Schritten werden mit cephadm zusätzlich der Ceph Monitor, der Ceph Manager, die OSDs, der Überwachungs-Stack und die Gateways installiert.
Bevor Sie fortfahren, überprüfen Sie die Netzwerkeinstellungen Ihres neuen Clusters. Zu diesem Zeitpunkt wurde die Einstellung public_network
(öffentliches Netzwerk) auf der Grundlage dessen, was für /cephadm_bootstrap/mon_ip
in der ceph-salt
-Konfiguration eingegeben wurde, ausgefüllt. Diese Einstellung wurde jedoch nur auf Ceph Monitor angewendet. Sie können diese Einstellung mit dem folgenden Kommando überprüfen:
root@master #
ceph config get mon public_network
Dies ist das Minimum, das Ceph benötigt, um zu funktionieren. Wir empfehlen jedoch, diese public_network
-Einstellung global
zu machen, was bedeutet, dass sie für alle Arten von Ceph-Daemons gilt und nicht nur für MONs:
root@master #
ceph config set global public_network "$(ceph config get mon public_network)"
Dieser Schritt ist nicht erforderlich. Wenn Sie diese Einstellung jedoch nicht verwenden, überwachen die Ceph-OSDs und andere Daemons (außer Ceph Monitor) auf allen Adressen.
Führen Sie folgendes Kommando aus, wenn Sie möchten, dass Ihre OSDs untereinander über ein komplett separates Netzwerk kommunizieren:
root@master #
ceph config set global cluster_network "cluster_network_in_cidr_notation"
Durch dieses Kommando wird sichergestellt, dass die in Ihrer Bereitstellung erstellten OSDs von Anfang an das vorgesehene Clusternetzwerk verwenden.
Wenn für Ihren Cluster dichte Knoten festgelegt sind (mehr als 62 OSDs pro Host), stellen Sie sicher, dass Sie genügend Ports für Ceph OSDs zuweisen. Der Standardbereich (6800–7300) lässt derzeit nicht mehr als 62 OSDs pro Host zu. Für einen Cluster mit dichten Knoten müssen Sie die Einstellung ms_bind_port_max
auf einen geeigneten Wert anpassen. Jedes OSD verbraucht acht zusätzliche Ports. Bei einem Host, der zum Beispiel für die Ausführung von 96 OSDs eingerichtet ist, werden 768 Ports benötigt. ms_bind_port_max
sollte mit folgendem Kommando mindestens auf 7568 festgelegt werden:
root@master #
ceph config set osd.* ms_bind_port_max 7568
Sie müssen Ihre Firewall-Einstellungen entsprechend anpassen, damit dies funktioniert. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Section 13.7, “Firewall settings for Ceph”.
5.4 Bereitstellen von Services und Gateways #
Nachdem Sie den Ceph-Basiscluster bereitgestellt haben, sollten Sie die wichtigsten Services auf weitere Cluster-Knoten verteilen. Stellen Sie zusätzliche Services bereit, um die Daten des Clusters für Clients zugänglich zu machen.
Derzeit unterstützen wir die Bereitstellung von Ceph-Services auf der Kommandozeile mit dem Ceph-Orchestrator (ceph orch
-Unterkommandos).
5.4.1 Das Kommando ceph orch
#
Mit dem Ceph-Orchestrator-Kommando ceph orch
(einer Schnittstelle zum cephadm-Modul) werden die Clusterkomponenten aufgelistet und Ceph-Services auf neuen Cluster-Knoten bereitgestellt.
5.4.1.1 Anzeigen des Orchestrator-Status #
Mit folgendem Kommando werden der aktuelle Modus und Status des Ceph-Orchestrators angezeigt.
cephuser@adm >
ceph orch status
5.4.1.2 Auflisten von Geräten, Services und Daemons #
Führen Sie zum Auflisten aller Datenträgergeräte folgendes Kommando aus:
cephuser@adm >
ceph orch device ls
Hostname Path Type Serial Size Health Ident Fault Available
ses-master /dev/vdb hdd 0d8a... 10.7G Unknown N/A N/A No
ses-min1 /dev/vdc hdd 8304... 10.7G Unknown N/A N/A No
ses-min1 /dev/vdd hdd 7b81... 10.7G Unknown N/A N/A No
[...]
Service ist ein allgemeiner Begriff für einen Ceph-Service eines bestimmten Typs, zum Beispiel Ceph Manager.
Daemon ist eine bestimmte Instanz eines Service, z. B. ein Prozess mgr.ses-min1.gdlcik
, der auf einem Knoten namens ses-min1
ausgeführt wird.
Führen Sie zum Auflisten aller Services, die cephadm kennt, folgendes Kommando aus:
cephuser@adm >
ceph orch ls
NAME RUNNING REFRESHED AGE PLACEMENT IMAGE NAME IMAGE ID
mgr 1/0 5m ago - <no spec> registry.example.com/[...] 5bf12403d0bd
mon 1/0 5m ago - <no spec> registry.example.com/[...] 5bf12403d0bd
Sie können die Liste mit dem optionalen Parameter --host
auf Services auf einem bestimmten Knoten und mit dem optionalen Parameter --service-type
auf Services eines bestimmten Typs beschränken (akzeptable Typen sind mon
, osd
, mgr
, mds
und rgw
).
Führen Sie folgendes Kommando aus, um alle von cephadm bereitgestellten aktiven Daemons aufzulisten:
cephuser@adm >
ceph orch ps
NAME HOST STATUS REFRESHED AGE VERSION IMAGE ID CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago 12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1 ses-min1 running) 8m ago 12d 15.2.0.108 5bf12403d0bd a719e0087369
Fragen Sie den Status eines bestimmten Daemons mit --daemon_type
und --daemon_id
ab. Bei OSDs ist die ID die numerische OSD-ID. Bei MDS ist die ID der Name des Dateisystems:
cephuser@adm >
ceph orch ps --daemon_type osd --daemon_id 0cephuser@adm >
ceph orch ps --daemon_type mds --daemon_id my_cephfs
5.4.2 Service- und Platzierungsspezifikation #
Die Spezifikation der Bereitstellung von Ceph-Services erfolgt am besten durch Erstellen einer YAML-formatierten Datei mit der Spezifikation der Services, die Sie bereitstellen möchten.
5.4.2.1 Erstellen von Servicespezifikationen #
Sie können für jede Art von Service eine eigene Spezifikationsdatei erstellen, wie zum Beispiel:
root@master #
cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
hosts:
- ses-min1
- ses-min2
spec:
pool: EXAMPLE_POOL
namespace: EXAMPLE_NAMESPACE
Alternativ können Sie mehrere (oder alle) Servicetypen in einer Datei angeben, z. B. cluster.yml
, die beschreibt, auf welchen Knoten bestimmte Services ausgeführt werden sollen. Denken Sie daran, einzelne Servicetypen mit drei Bindestrichen (---
) zu trennen:
cephuser@adm >
cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
hosts:
- ses-min1
- ses-min2
spec:
pool: EXAMPLE_POOL
namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
hosts:
- ses-min1
- ses-min2
- ses-min3
---
[...]
Die oben genannten Eigenschaften haben folgende Bedeutung:
service_type
Der Typ des Service. Er kann entweder ein Ceph-Service (
mon
,mgr
,mds
,crash
,osd
oderrbd-mirror
), ein Gateway (nfs
oderrgw
) oder Teil des Überwachungs-Stacks (alertmanager
,grafana
,node-exporter
oderprometheus
) sein.service_id
Der Name des Service. Für Spezifikationen vom Typ
mon
,mgr
,alertmanager
,grafana
,node-exporter
undprometheus
ist die Eigenschaftservice_id
nicht erforderlich.placement
Gibt an, auf welchen Knoten der Service ausgeführt wird. Weitere Informationen finden Sie in Abschnitt 5.4.2.2, „Erstellen von Platzierungsspezifikationen“.
spec
Zusätzliche Spezifikation, die für den Servicetyp relevant ist.
Ceph-Cluster-Services haben in der Regel eine Reihe von für sie spezifischen Eigenschaften. Beispiele und Details zu den Spezifikationen der einzelnen Services finden Sie in Abschnitt 5.4.3, „Bereitstellen von Ceph-Services“.
5.4.2.2 Erstellen von Platzierungsspezifikationen #
Zum Bereitstellen von Ceph-Services muss cephadm wissen, auf welchen Knoten sie bereitgestellt werden sollen. Verwenden Sie die Eigenschaft placement
und führen Sie die Host-Kurznamen der Knoten auf, für die der Service gilt:
cephuser@adm >
cat cluster.yml
[...]
placement:
hosts:
- host1
- host2
- host3
[...]
5.4.2.3 Anwenden von Clusterspezifikationen #
Nachdem Sie eine vollständige cluster.yml
-Datei mit Spezifikationen zu allen Services und deren Platzierung erstellt haben, können Sie den Cluster mit folgendem Kommando anwenden:
cephuser@adm >
ceph orch apply -i cluster.yml
Führen Sie zum Anzeigen des Clusterstatus das Kommando ceph orch
aus. Weitere Informationen finden Sie unter Abschnitt 5.4.1.1, „Anzeigen des Orchestrator-Status“.
5.4.2.4 Exportieren der Spezifikation eines aktiven Clusters #
Obwohl Sie dem Ceph-Cluster Services mithilfe der Spezifikationsdateien bereitgestellt haben (wie in Abschnitt 5.4.2, „Service- und Platzierungsspezifikation“ beschrieben), kann die Konfiguration des Clusters während seines Betriebs von der ursprünglichen Spezifikation abweichen. Möglicherweise haben Sie auch die Spezifikationsdateien versehentlich entfernt.
Führen Sie zum Abrufen der vollständigen Spezifikation eines aktiven Clusters folgendes Kommando aus:
cephuser@adm >
ceph orch ls --export
placement:
hosts:
- hostname: ses-min1
name: ''
network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
count: 2
service_name: mgr
service_type: mgr
---
[...]
Sie können die Option --format
anhängen, um das Standard-Ausgabeformat yaml
zu ändern. Sie können zwischen json
, json-pretty
oder yaml
wählen. Beispiel:
ceph orch ls --export --format json
5.4.3 Bereitstellen von Ceph-Services #
Sobald der Basiscluster ausgeführt wird, können Sie Ceph-Services auf weiteren Knoten bereitstellen.
5.4.3.1 Bereitstellen von Ceph Monitors und Ceph Managers #
Für den Ceph-Cluster werden drei oder fünf MONs bereitgestellt, die auf verschiedenen Knoten verteilt sind. Wenn sich fünf oder mehr Knoten im Cluster befinden, empfehlen wir die Bereitstellung von fünf MONs. Es hat sich bewährt, MGRs auf denselben Knoten wie MONs zu installieren.
Wenn Sie MONs und MGRs bereitstellen, denken Sie daran, den ersten MON einzubeziehen, den Sie bei der Konfiguration des Basisclusters in Abschnitt 5.3.2.5, „Festlegen des ersten MON/MGR-Knotens“ hinzugefügt haben.
Wenden Sie zum Bereitstellen von MONs folgende Spezifikation an:
service_type: mon placement: hosts: - ses-min1 - ses-min2 - ses-min3
Wenn Sie einen weiteren Knoten hinzufügen müssen, hängen Sie den Hostnamen an dieselbe YAML-Liste an. Beispiel:
service_type: mon placement: hosts: - ses-min1 - ses-min2 - ses-min3 - ses-min4
Wenden Sie auf ähnliche Weise zum Bereitstellen von MONs folgende Spezifikationen an:
Stellen Sie sicher, dass mindestens drei Ceph Manager in jeder Bereitstellung vorhanden sind.
service_type: mgr placement: hosts: - ses-min1 - ses-min2 - ses-min3
Wenn sich MONs oder MGRs nicht im gleichen Teilnetz befinden, müssen Sie die Teilnetzadressen anhängen. Beispiel:
service_type: mon placement: hosts: - ses-min1:10.1.2.0/24 - ses-min2:10.1.5.0/24 - ses-min3:10.1.10.0/24
5.4.3.2 Bereitstellen von Ceph OSDs #
Ein Speichergerät gilt als verfügbar, wenn alle folgenden Bedingungen erfüllt sind:
Das Gerät hat keine Partitionen.
Das Gerät hat keinen LVM-Status.
Das Gerät ist nicht eingehängt.
Das Gerät enthält kein Dateisystem.
Das Gerät enthält kein BlueStore-OSD.
Das Gerät ist größer als 5 GB.
Wenn die oben genannten Bedingungen nicht erfüllt sind, verweigert Ceph die Bereitstellung derartiger OSDs.
Zum Bereitstellen von OSDs haben Sie zwei Möglichkeiten:
Weisen Sie Ceph an, alle verfügbaren und nicht verwendeten Speichergeräte zu verbrauchen:
cephuser@adm >
ceph orch apply osd --all-available-devicesVerwenden Sie DriveGroups (weitere Informationen hierzu finden Sie im Abschnitt 13.4.3, „Hinzufügen von OSDs mit der DriveGroups-Spezifikation“), um OSD-Spezifikationen zu erstellen, die Geräte beschreiben, die basierend auf ihren Eigenschaften bereitgestellt werden. Beispiele hierfür sind der Gerätetyp (SSD oder HDD), die Gerätemodellnamen, die Größe oder die Knoten, auf denen die Geräte vorhanden sind. Wenden Sie dann die Spezifikation mit folgendem Kommando an:
cephuser@adm >
ceph orch apply osd -i drive_groups.yml
5.4.3.3 Bereitstellen von Metadatenservern #
Für CephFS sind ein oder mehrere Metadata Server (MDS)-Services erforderlich. Wenn Sie ein CephFS erstellen möchten, erstellen Sie zunächst MDS-Server durch Anwenden der folgenden Spezifikation:
Stellen Sie sicher, dass Sie mindestens zwei Pools, einen für CephFS-Daten und einen für CephFS-Metadaten, erstellt haben, bevor Sie die folgende Spezifikation anwenden.
service_type: mds service_id: CEPHFS_NAME placement: hosts: - ses-min1 - ses-min2 - ses-min3
Erstellen Sie das CephFS, sobald die MDS funktionsfähig sind:
ceph fs new CEPHFS_NAME metadata_pool data_pool
5.4.3.4 Bereitstellen von Object Gateways #
cephadm stellt ein Object Gateway als eine Sammlung von Daemons bereit, die einen bestimmten Bereich und eine Zone verwalten.
Sie können entweder einen Object-Gateway-Service mit einem bereits vorhandenen Bereich und einer bereits vorhandenen Zone verknüpfen (weitere Informationen finden Sie im Abschnitt 21.13, „Object Gateways an mehreren Standorten“), oder Sie können einen nicht vorhandenen REALM_NAME (Bereichsnamen) und ZONE_NAME (Zonennamen) angeben, die dann automatisch erstellt werden, nachdem Sie die folgende Konfiguration angewendet haben:
service_type: rgw service_id: REALM_NAME.ZONE_NAME placement: hosts: - ses-min1 - ses-min2 - ses-min3 spec: rgw_realm: RGW_REALM rgw_zone: RGW_ZONE
5.4.3.4.1 Verwenden des sicheren SSL-Zugangs #
Um eine sichere SSL-Verbindung zum Object Gateway zu verwenden, benötigen Sie ein Paar gültiger SSL-Zertifikats- und Schlüsseldateien (weitere Details finden Sie im Abschnitt 21.7, „Aktivieren von HTTPS/SSL für Object Gateways“). Sie müssen SSL aktivieren, eine Portnummer für SSL-Verbindungen sowie die SSL-Zertifikats- und Schlüsseldateien angeben.
Nehmen Sie Folgendes in Ihre Spezifikation auf, um SSL zu aktivieren und die Portnummer anzugeben:
spec: ssl: true rgw_frontend_port: 443
Um das SSL-Zertifikat und den Schlüssel festzulegen, können Sie deren Inhalte direkt in die YAML-Spezifikationsdatei einfügen. Das Pipe-Zeichen (|
) am Zeilenende weist den Parser darauf hin, dass er eine mehrzeilige Zeichenkette als Wert erwarten soll. Beispiel:
spec: ssl: true rgw_frontend_port: 443 rgw_frontend_ssl_certificate: | -----BEGIN CERTIFICATE----- MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp [...] -----END CERTIFICATE----- rgw_frontend_ssl_key: | -----BEGIN PRIVATE KEY----- MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9 [...] -----END PRIVATE KEY-----
Statt den Inhalt der SSL-Zertifikats- und Schlüsseldateien einzufügen, können Sie die Schlüsselwörter rgw_frontend_ssl_certificate:
und rgw_frontend_ssl_key:
weglassen und sie in die Konfigurationsdatenbank hochladen:
cephuser@adm >
ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \ -i SSL_CERT_FILEcephuser@adm >
ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \ -i SSL_KEY_FILE
5.4.3.4.2 Bereitstellung mit einem Untercluster #
Mit Unterclustern können Sie die Knoten in Ihren Clustern organisieren, um Workloads zu isolieren und die elastische Skalierung zu erleichtern. Wenden Sie die folgende Konfiguration an, wenn Sie die Bereitstellung mit einem Untercluster durchführen:
service_type: rgw service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER placement: hosts: - ses-min1 - ses-min2 - ses-min3 spec: rgw_realm: RGW_REALM rgw_zone: RGW_ZONE subcluster: SUBCLUSTER
5.4.3.5 Bereitstellen von iSCSI-Gateways #
iSCSI ist ein Storage Area Network (SAN)-Protokoll, das Clients (genannt Initiators) das Senden von SCSI-Kommandos an SCSI-Speichergeräte (Ziele) auf Remote-Servern ermöglicht.
Wenden Sie die folgende Konfiguration für die Bereitstellung an. Stellen Sie sicher, dass trusted_ip_list
die IP-Adressen aller iSCSI-Gateway- und Ceph-Manager-Knoten enthält (wie im folgenden Ausgabebeispiel gezeigt).
Stellen Sie sicher, dass der Pool erstellt wurde, bevor Sie die folgende Spezifikation anwenden.
service_type: iscsi service_id: EXAMPLE_ISCSI placement: hosts: - ses-min1 - ses-min2 - ses-min3 spec: pool: EXAMPLE_POOL api_user: EXAMPLE_USER api_password: EXAMPLE_PASSWORD trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
Stellen Sie sicher, dass die für trusted_ip_list
aufgelisteten IPs kein Leerzeichen nach der Kommatrennung aufweisen.
5.4.3.5.1 Sichere SSL-Konfiguration #
Zur Verwendung einer sicheren SSL-Verbindung zwischen dem Ceph Dashboard und der iSCSI-Ziel-API benötigen Sie ein Paar gültiger SSL-Zertifikate und Schlüsseldateien. Sie können entweder von einer Zertifizierungsstelle ausgestellt oder eigensigniert sein (weitere Informationen finden Sie im Abschnitt 10.1.1, „Erstellen von eigensignierten Zertifikaten“). Nehmen Sie zum Aktivieren von SSL die Einstellung api_secure: true
in Ihre Spezifikationsdatei auf:
spec: api_secure: true
Um das SSL-Zertifikat und den Schlüssel festzulegen, können Sie den Inhalt direkt in die YAML-Spezifikationsdatei einfügen. Das Pipe-Zeichen (|
) am Zeilenende weist den Parser darauf hin, dass er eine mehrzeilige Zeichenkette als Wert erwarten soll. Beispiel:
spec: pool: EXAMPLE_POOL api_user: EXAMPLE_USER api_password: EXAMPLE_PASSWORD trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2" api_secure: true ssl_cert: | -----BEGIN CERTIFICATE----- MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3 DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T [...] -----END CERTIFICATE----- ssl_key: | -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4 /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h [...] -----END PRIVATE KEY-----
5.4.3.6 Bereitstellen von NFS Ganesha #
cephadm stellt NFS Ganesha unter Verwendung eines vordefinierten RADOS-Pools und eines optionalen Namespace bereit. Wenden Sie zum Bereitstellen von NFS Ganesha folgende Spezifikation an:
Sie müssen über einen vordefinierten RADOS-Pool verfügen, da sonst der ceph orch apply
-Vorgang fehlschlägt. Weitere Informationen zum Erstellen eines Pools finden Sie im Abschnitt 18.1, „Erstellen eines Pools“.
service_type: nfs service_id: EXAMPLE_NFS placement: hosts: - ses-min1 - ses-min2 spec: pool: EXAMPLE_POOL namespace: EXAMPLE_NAMESPACE
EXAMPLE_NFS mit einer beliebigen Zeichenkette, die den NFS-Export identifiziert.
EXAMPLE_POOL mit dem Namen des Pools, in dem das NFS-Ganesha-RADOS-Konfigurationsobjekt gespeichert werden soll.
EXAMPLE_NAMESPACE (optional) mit dem gewünschten Object-Gateway-NFS-Namespace (zum Beispiel
ganesha
).
5.4.3.7 Bereitstellen von rbd-mirror
#
Der Service rbd-mirror
synchronisiert RADOS-Blockgeräte-Images zwischen zwei Ceph-Clustern (weitere Details finden Sie im Abschnitt 20.4, „RBD-Image-Spiegel“). Stellen Sie rbd-mirror
mit folgender Spezifikation bereit:
service_type: rbd-mirror service_id: EXAMPLE_RBD_MIRROR placement: hosts: - ses-min3
5.4.3.8 Bereitstellen des Überwachungs-Stacks #
Der Überwachungs-Stack besteht aus Prometheus, Prometheus-Exportern, Prometheus Alertmanager und Grafana. Ceph Dashboard nutzt diese Komponenten, um detaillierte Kennzahlen zur Clusternutzung und -leistung zu speichern und zu visualisieren.
Wenn für Ihre Bereitstellung benutzerdefinierte oder lokal bereitgestellte Container-Images der Überwachungs-Stack-Services erforderlich sind, finden Sie Informationen hierzu im Abschnitt 16.1, „Konfigurieren von benutzerdefinierten oder lokalen Images“.
Führen Sie zum Bereitstellen des Überwachungs-Stacks folgende Schritte aus:
Aktivieren Sie das Modul
prometheus
im Ceph-Manager-Daemon. Dadurch werden die internen Ceph-Kennzahlen offengelegt, so dass Prometheus sie lesen kann:cephuser@adm >
ceph mgr module enable prometheusAnmerkungStellen Sie sicher, dass dieses Kommando vor dem Bereitstellen von Prometheus ausgeführt wird. Wenn das Kommando vor der Bereitstellung nicht ausgeführt wurde, müssen Sie Prometheus erneut bereitstellen, um die Konfiguration von Prometheus zu aktualisieren:
cephuser@adm >
ceph orch redeploy prometheusErstellen Sie eine Spezifikationsdatei (z. B.
monitoring.yaml
) mit einem Inhalt ähnlich dem folgenden:service_type: prometheus placement: hosts: - ses-min2 --- service_type: node-exporter --- service_type: alertmanager placement: hosts: - ses-min4 --- service_type: grafana placement: hosts: - ses-min3
Wenden Sie die Überwachungsservices mit folgendem Kommando an:
cephuser@adm >
ceph orch apply -i monitoring.yamlEs kann ein oder zwei Minuten dauern, bis die Überwachungsservices bereitgestellt sind.
Prometheus, Grafana und das Ceph Dashboard sind automatisch so konfiguriert, dass sie miteinander kommunizieren. Dies führt zu einer voll funktionsfähigen Grafana-Integration im Ceph Dashboard, wenn es wie oben beschrieben bereitgestellt wird.
Die einzige Ausnahme von dieser Regel ist die Überwachung mit RBD-Images. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 16.5.4, „Aktivieren der RBD-Image-Überwachung“.