Embed Size (px)
Citation preview
SUSE Enterprise Storage 6
Bereitstellungshandbuch
BereitstellungshandbuchSUSE Enterprise Storage 6von Tomáš Bažant, Jana Haláčková, Alexandra Settle und Sven Seeberg
Veröentlicht: 04.07.2021
SUSE LLC1800 South Novell PlaceProvo, UT 84606USA
https://documentation.suse.com
Copyright © 2021 SUSE LLC
Copyright © 2016, RedHat, Inc., und Mitwirkende.
Der Text und die Abbildungen in diesem Dokument sind unter Creative Commons Attribution-Share
Alike 4.0 International ("CC-BY-SA") lizenziert. Eine Erläuterung zu CC-BY-SA ist verfügbar unter
http://creativecommons.org/licenses/by-sa/4.0/legalcode . Gemäß CC-BY-SA müssen Sie die URL für die
Originalversion angeben, wenn Sie dieses Dokument oder Teile daraus verteilen.
Red Hat, Red Hat Enterprise Linux, das Shadowman-Logo, JBoss, MetaMatrix, Fedora, das Innity-Logo
und RHCE sind Marken von Red Hat, Inc. und in den Vereinigten Staaten und anderen Ländern eingetragen.
Linux ist die eingetragene Marke von Linus Torvalds in den Vereinigten Staaten und in anderen Ländern.
Java ist eine eingetragene Marke von Oracle und/oder deren Partnern. XFS ist eine Marke von Silicon
Graphics International Corp. oder deren Tochterunternehmen in den Vereinigten Staaten und/oder anderen
Ländern. Alle anderen Marken sind das Eigentum der jeweiligen Besitzer.
Die SUSE-Marken nden Sie unter http://www.suse.com/company/legal/ . Alle anderen Marken von
Drittanbietern sind Besitz ihrer jeweiligen Eigentümer. Markensymbole (®, ™ usw.) kennzeichnen Marken
von SUSE und der Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.
Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Doch auch
dadurch kann hundertprozentige Richtigkeit nicht gewährleistet werden. Weder SUSE LLC noch ihre
Tochtergesellschaften noch die Autoren noch die Übersetzer können für mögliche Fehler und deren Folgen
haftbar gemacht werden.
Inhaltsverzeichnis
Allgemeines zu diesem Handbuch x1 Verfügbare Dokumentation x
2 Rückmeldungen xi
3 Konventionen in der Dokumentation xi
4 Informationen über die Herstellung dieses Handbuchs xii
5 Mitwirkende bei Ceph xii
I SUSE ENTERPRISE STORAGE 1
1 SUSE Enterprise Storage 6 und Ceph 21.1 Eigenschaften von Ceph 2
1.2 Wichtige Komponenten 3
RADOS 3 • CRUSH 4 • Ceph Nodes und Daemons 5
1.3 Speicherstruktur 7
Pool 7 • Placement Group 7 • Beispiel 7
1.4 BlueStore 9
1.5 Weitere Informationen 10
2 Hardwareanforderungen und Empfehlungen 11
2.1 Konfigurationen mit mehreren Architekturen 11
2.2 Mindestkonfiguration für den Cluster 11
2.3 Objektspeicher-Nodes 12
Mindestanforderungen 12 • Mindestfestplattengröße 13 • Empfohlene
Größe für das WAL- und DB-Gerät von BlueStore 13 • Verwenden von SSD
für OSD-Journale 14 • Maximale empfohlene Anzahl von Festplatten 14
2.4 Monitor Nodes 15
iv Bereitstellungshandbuch
2.5 Object Gateway Nodes 15
2.6 Metadata Server Nodes 15
2.7 Salt Master 16
2.8 iSCSI Nodes 16
2.9 Netzwerkempfehlungen 16
Hinzufügen eines privaten Netzwerks zu einem aktiven Cluster 17 • Monitor
Nodes in verschiedenen Teilnetzen 18
2.10 Benennungseinschränkungen 18
2.11 Ein einziger Server für OSD und Monitor 19
2.12 Empfohlene Konfiguration für Produktions-Cluster 19
2.13 SUSE Enterprise Storage 6 und andere SUSE-Produkte 20
SUSE Manager 20
3 Einrichten des Hochverfügbarkeits-Clusters für denAdmin Node 21
3.1 Überblick zum Hochverfügbarkeits-Cluster für Admin Node 21
3.2 Erstellen eines Hochverfügbarkeits-Clusters mit Admin Node 22
4 Benutzerrechte und Kommandozeilen 24
4.1 Salt-/DeepSea-spezifische Kommandos 24
4.2 Ceph-spezifische Kommandos 24
4.3 Allgemeine Linux-Kommandos 25
4.4 Weitere Informationen 26
II CLUSTER-BEREITSTELLUNG UND UPGRADE 27
5 Bereitstellen mit DeepSea/Salt 285.1 Lesen Sie die Versionshinweise 29
v Bereitstellungshandbuch
5.2 Einführung zu DeepSea 29
Organisation und wichtige Standorte 31 • Adressieren der Minions 32
5.3 Cluster-Bereitstellung 34
5.4 DeepSea CLI 44
DeepSea CLI: Überwachungsmodus 45 • DeepSea CLI: Stand-Alone-
Modus 45
5.5 Konfiguration und Anpassung 47
Die Datei policy.cfg 47 • DriveGroups 53 • Anpassen von
ceph.conf mit benutzerdefinierten Einstellungen 62
6 Upgrade von vorigen Versionen 63
6.1 Vor dem Upgrade zu beachtende Punkte 63
6.2 Sichern von Clusterdaten 67
6.3 Migration von ntpd zu chronyd 68
6.4 Patchen des Clusters vor dem Upgrade 69
Erforderliche Software-Repositorys 69 • Repository-Staging-
Systeme 70 • Patchen des gesamten Clusters mit den aktuellen
Patches 70
6.5 Überprüfen der aktuellen Umgebung 71
6.6 Prüfen des Cluster-Status 72
6.7 Oine-Upgrade von CTDB-Clustern 73
6.8 Upgrade Knoten für Knoten – Grundverfahren 73
Manuelles Knoten-Upgrade mit der Installationsprogramms-
DVD 74 • Knoten-Upgrade mit dem SUSE Distribution Migration
System 76
6.9 Upgrade des Admin Node 78
6.10 Upgrade von Ceph Monitor/Ceph Manager Nodes 79
6.11 Upgrade von Metadatenservern 80
6.12 Upgrade von Ceph OSDs 81
vi Bereitstellungshandbuch
6.13 OSD-Migration zu BlueStore 85
6.14 Upgrade von Anwendungsknoten 86
6.15 Aktualisieren von policy.cfg und Deploy Ceph Dashboard mitDeepSea 87
6.16 Migration von profilbasierten Implementierungen zu DriveGroups 89
Analysieren des aktuellen Layouts 90 • Erstellen von
passenden DriveGroups für das aktuelle Layout 90 • OSD-
Implementierung 91 • Komplexere Einrichtungen 92
7 Anpassen der Standardkonfiguration 93
7.1 Verwenden benutzerdefinierter Konfigurationsdateien 93
Deaktivieren eines Bereitstellungschritts 93 • Ersetzen
eines Bereitstellungschritts 94 • Bearbeiten
eines Bereitstellungschritts 96 • Bearbeiten einer
Bereitstellungsphase 97 • Updates und Neustarts in Phase 0 99
7.2 Bearbeiten der ermittelten Konfiguration 100
Aktivieren von IPv6 für die Ceph Cluster-Implementierung 102
III INSTALLATION ZUSÄTZLICHER SERVICES 104
8 Installation der Services für den Zugri auf IhreDaten 105
9 Ceph Object Gateway 106
9.1 Manuelle Installation von Object Gateway 107
Konfiguration des Object Gateway 107
10 Installation des iSCSI Gateway 114
10.1 iSCSI-Blockspeicher 114
Linux Kernel iSCSI Target 115 • iSCSI Initiator 115
10.2 Allgemeine Informationen zu ceph-iscsi 116
10.3 Überlegungen zur Bereitstellung 118
vii Bereitstellungshandbuch
10.4 Installation und Konfiguration 118
Bereitstellen des iSCSI Gateway auf einem Ceph Cluster 119 • Erstellen
von RBD-Images 119 • Exportieren von RBD-Images über
iSCSI 119 • Authentifizierung und Zugrissteuerung 121 • Erweiterte
Einstellungen 123
10.5 Exportieren von RADOS Block Device-Images mit tcmu-runner 126
11 Installation des CephFS 128
11.1 Unterstützte CephFS-Szenarios und Anleitungen 128
11.2 Ceph Metadata Server 129
Hinzufügen eines Metadatenservers 129 • Konfigurieren eines Metadata
Server 130
11.3 CephFS 136
Erstellen eines CephFS 136 • Größe des MDS Clusters 137 • MDS Cluster
und Updates 138 • Datei-Layouts 139
12 Installation von NFS Ganesha 145
12.1 Vorbereitung 145
Allgemeine Informationen 145 • Anforderungen im Überblick 146
12.2 Installationsbeispiel 146
12.3 Hochverfügbare Aktiv-Passiv-Konfiguration 147
Standardinstallation 147 • Bereinigen der Ressourcen 150 • Einrichten
der Ping-Ressource 150 • NFS Ganesha HA und DeepSea 151
12.4 Aktiv/Aktiv-Konfiguration 152
Voraussetzungen 152 • Konfigurieren von NFS Ganesha 153 • Befüllen
der Cluster-Kulanzdatenbank 154 • Neustarten der NFS Ganesha-
Services 155 • Schlussfolgerung 155
12.5 Weitere Informationen 156
viii Bereitstellungshandbuch
IV CLUSTER-IMPLEMENTIERUNG ZUSÄTZLICH ZU SUSE CAAS PLATFORM 4(TECHNOLOGY PREVIEW) 157
13 SUSE Enterprise Storage 6 zusätzlich zu SUSE CaaSPlatform 4 auf einem Kubernetes-Cluster 158
13.1 Vorüberlegungen 158
13.2 Voraussetzungen 158
13.3 Abrufen der Rook-Manifeste 159
13.4 Installation 159
Konfiguration 159 • Erstellen des Rook-Operators 161 • Erstellen des
Ceph Clusters 161
13.5 Rook als Speicher für Kubernetes-Workload 162
13.6 Deinstallation von Rook 163
A Ceph-Wartungs-Updates auf der Grundlage vonvorgeschalteten „Nautilus“-Unterversionen 164
Glossar 167
B Aktualisierungen der Dokumentation 170
B.1 Wartungs-Update der Dokumentation zu SUSE EnterpriseStorage 6 170
B.2 Juni 2019 (Freigabe von SUSE Enterprise Storage 6) 171
ix Bereitstellungshandbuch
Allgemeines zu diesem Handbuch
SUSE Enterprise Storage 6 ist eine Erweiterung zu SUSE Linux Enterprise 15 SP1. Es kombiniertdie Funktion des Speicherprojekts Ceph (http://ceph.com/ ) mit der Unternehmenstechnikund dem Support von SUSE. Mit SUSE Enterprise Storage 6 stellen IT-Organisationen einedezentrale Speicherarchitektur bereit, die eine Reihe von Anwendungsfällen auf kommerziellenHardwareplattformen unterstützt.
Dieses Handbuch vermittelt Ihnen das Konzept von SUSE Enterprise Storage 6. Es konzentriertsich dabei hauptsächlich auf die Verwaltung der Ceph-Infrastruktur. Es demonstriert auch, wieCeph mit anderen verwandten Lösungen wie OpenStack oder KVM verwendet wird.
Viele Kapitel in diesem Handbuch enthalten Links zu zusätzlichen Dokumentationsressourcen.Dazu gehört auch weitere Dokumentation, die auf dem System bzw. im Internet verfügbar ist.
Einen Überblick über die Dokumentation, die für Ihr Produkt verfügbar ist, und die neuestenDokumentationsupdates nden Sie unter http://www.suse.com/documentation .
1 Verfügbare DokumentationFür dieses Produkt sind folgende Handbücher verfügbar:
Buch „Verwaltungshandbuch”
Das Handbuch beschreibt verschiedene Verwaltungsaufgaben, die normalerweise nach derInstallation ausgeführt werden. Das Handbuch stellt auch die Schritte zur Integration vonCeph in Virtualisierungslösungen wie libvirt , Xen oder KVM vor sowie Methoden fürden Zugri auf im Cluster gespeicherte Objekte über iSCSI und RADOS-Gateways.
Bereitstellungshandbuch
Führt Sie durch die Installationsschritte des Ceph Clusters und aller Services, die sich aufCeph beziehen. Das Handbuch veranschaulicht auch die Basisstruktur eines Ceph Clustersund stellt Ihnen die entsprechende Terminologie vor.
HTML-Versionen der Produkthandbücher nden Sie im installierten System unter /usr/share/doc/manual . Die neuesten Dokumentationsaktualisierungen sind unter http://www.suse.com/
documentation verfügbar. Hier können Sie die Handbücher für Ihr Produkt in verschiedenenFormaten herunterladen.
x Verfügbare Dokumentation SES 6
2 RückmeldungenFür Rückmeldungen stehen mehrere Kanäle zur Verfügung:
Fehler und Verbesserungsanforderungen
Informationen zu Diensten und Support-Optionen, die für Ihr Produkt verfügbar sind,nden Sie unter http://www.suse.com/support/ .Um Fehler für eine Produktkomponente zu melden, melden Sie sich über http://
www.suse.com/support/ beim Novell Customer Center an und wählen Sie dieOptionsfolge My Support (Mein Support) Service Request (Service-Anforderung).
Anregungen und Kritik unserer Leser
Wir freuen uns über Ihre Kommentare und Vorschläge zu diesem Handbuch undden anderen Teilen der Dokumentation dieses Produkts. Verwenden Sie die Funktion„Benutzerkommentare“ unten auf den einzelnen Seiten der Online-Dokumentationoder geben Sie Ihre Kommentare auf der Seite http://www.suse.com/documentation/
feedback.html ein.
Für Feedback zur Dokumentation dieses Produkts können Sie auch eine E-Mail an [email protected] senden. Geben Sie auf jeden Fall auch den Titel der Dokumentation, dieProduktversion und das Datum der Veröentlichung der Dokumentation an. Geben Sieeine genaue Beschreibung des Problems an und beziehen Sie sich auf die entsprechendeAbschnittsnummer und Seite (oder URL), wenn Sie Fehler melden oder Verbesserungenvorschlagen.
3 Konventionen in der DokumentationIn diesem Handbuch werden folgende typograsche Konventionen verwendet:
/etc/passwd : Verzeichnis- und Dateinamen
Platzhalter : Ersetzen Sie Platzhalter durch den tatsächlichen Wert.
PATH : die Umgebungsvariable PATH
ls , --help : Kommandos, Optionen und Parameter
Benutzer : Benutzer oder Gruppen
xi Rückmeldungen SES 6
Alt , Alt – F1 : Eine Taste oder Tastenkombination. Tastennamen werden wie auf derTastatur in Großbuchstaben dargestellt.
Datei, Datei Speichern unter: Menüelemente, Schaltächen
Tanzende Pinguine (Kapitel Pinguine, ↑Zusätzliches Handbuch): Dies ist ein Verweis auf einKapitel in einem anderen Handbuch.
4 Informationen über die Herstellung diesesHandbuchsDieses Handbuch wurde in GeekoDoc geschrieben, das zu DocBook gehört (weitereInformationen nden Sie unter http://www.docbook.org ). Die XML-Quelldateien wurden mitxmllint überprüft, von xsltproc verarbeitet und mit einer benutzerdenierten Version derStylesheets von Norman Walsh in XSL-FO konvertiert. Das nale PDF kann über FOP von Apacheoder über XEP von RenderX formatiert werden. Die Erstellungs- und Veröentlichungstools, diezur Herstellung dieses Handbuchs verwendet wurden, nden Sie im Paket daps . Die DocBookAuthoring and Publishing Suite (DAPS) wurde als Open Source Software entwickelt. WeitereInformationen nden Sie unter http://daps.sf.net/ .
5 Mitwirkende bei CephDas Ceph-Projekt und dessen Dokumentation ist das Ergebnis der Arbeit von Hundertenvon Mitwirkenden und Organisationen. Weitere Einzelheiten nden Sie in https://ceph.com/
contributors/ .
xii Informationen über die Herstellung dieses Handbuchs SES 6
I SUSE Enterprise Storage
1 SUSE Enterprise Storage 6 und Ceph 2
2 Hardwareanforderungen und Empfehlungen 11
3 Einrichten des Hochverfügbarkeits-Clusters für den Admin Node 21
4 Benutzerrechte und Kommandozeilen 24
1 SUSE Enterprise Storage 6 und Ceph
SUSE Enterprise Storage 6 ist ein dezentrales Speichersystem, das auf Skalierbarkeit,Zuverlässigkeit und Leistung ausgelegt ist und auf der Ceph-Technologie basiert. EinCeph Cluster kann auf Standardservern in einem gemeinsamen Netzwerk wie Ethernetausgeführt werden. Der Cluster lässt sich gut für Tausende von Servern (im Folgendenals Nodes bezeichnet) und im Petabyte-Bereich skalieren. Im Gegensatz zu herkömmlichenSystemen, die Daten über Zuordnungstabellen speichern und abrufen, verwendet Cepheinen deterministischen Algorithmus zum Zuordnen von Speicher für Daten und hat keinezentralisierte Informationsstruktur. Ceph geht davon aus, dass in Speicher-Clustern dasHinzufügen oder Entfernen von Hardware die Regel ist und nicht die Ausnahme. DerCeph Cluster automatisiert Verwaltungsaufgaben wie Datenverteilung und -neuverteilung,Datenreproduktion, Ausfallerkennung und Wiederherstellung. Ceph kann sich selbst reparierenund selbst verwalten, was den Verwaltungsaufwand und die Gemeinkosten reduziert.
In diesem Kapitel erhalten Sie einen ersten Überblick über SUSE Enterprise Storage 6 und einekurze Beschreibung der wichtigsten Komponenten.
TippSeit SUSE Enterprise Storage 5 ist DeepSea die einzige Methode zur Cluster-Bereitstellung. In Kapitel 5, Bereitstellen mit DeepSea/Salt nden Sie weitere Details zumBereitstellungsprozess.
1.1 Eigenschaften von CephDie Ceph Umgebung weist die folgenden Eigenschaften auf:
Skalierbarkeit
Ceph ermöglicht das Skalieren auf Tausende von Nodes und kann Speicher im Petabyte-Bereich verwalten.
Kommerzielle Hardware
Zum Ausführen eines Ceph Clusters ist keine spezielle Hardware erforderlich. WeitereInformationen nden Sie in Kapitel 2, Hardwareanforderungen und Empfehlungen
Selbstverwaltung
2 Eigenschaften von Ceph SES 6
Der Ceph Cluster verwaltet sich selbst. Wenn Nodes hinzugefügt oder entfernt werdenoder ausfallen, verteilt der Cluster die Daten automatisch um. Er erkennt auch überlasteteFestplatten.
Keine Single Points of Failure
Kein Node im Cluster speichert wichtige Informationen exklusiv. Die Anzahl derRedundanzen kann konguriert werden.
Open Source-Software
Ceph ist eine Open Source-Softwarelösung und unabhängig von spezischer Hardwareoder Anbietern.
1.2 Wichtige KomponentenZur vollen Nutzung aller Funktionen in Ceph ist es erforderlich, einige Basiskomponenten undKonzepte zu verstehen. In diesem Abschnitt werden einige Komponenten von Ceph eingeführt,auf die oft in anderen Kapiteln verwiesen wird.
1.2.1 RADOS
Die Basiskomponente von Ceph wird RADOS (Reliable Autonomic Distributed Object Store,Zuverlässiger autonomer dezentraler Objektspeicher) genannt. Sie ist für die Verwaltung der imCluster gespeicherten Daten zuständig. Daten werden in Ceph normalerweise als Objektegespeichert. Jedes Objekt besteht aus einer Kennung und den Daten.
RADOS bietet die folgenden Methoden für den Zugri auf gespeicherte Objekte, die vieleAnwendungsfälle abdecken:
Object Gateway
Ein Object Gateway ist ein HTTP REST Gateway für den RADOS-Objektspeicher. Esermöglicht den Direktzugri auf Objekte, die im Ceph Cluster gespeichert sind.
RADOS-Blockgerät
Der Zugri auf RADOS-Blockgeräte (RADOS Block Device, RBD) erfolgt genauso wie aufandere Blockgeräte. Sie werden beispielsweise für Virtualisierungszwecke in Kombinationmit libvirt verwendet.
CephFS
Das Ceph File System (CephFS) ist ein POSIX-fähiges Dateisystem.
3 Wichtige Komponenten SES 6
librados
librados ist eine Bibliothek, die mit vielen Programmiersprachen verwendet werdenkann, um eine Anwendung zu erstellen, die direkt mit dem Speicher-Cluster interagiert.
librados wird vom Object Gateway und RBD verwendet, während CephFS direkt mit RADOS-Abbildung 1.1, „Schnittstellen zum Ceph-Objektspeicher“ interagiert.
RADOS
ABBILDUNG 1.1: SCHNITTSTELLEN ZUM CEPH-OBJEKTSPEICHER
1.2.2 CRUSH
Der CRUSH-Algorithmus ist das zentrale Element eines Ceph Clusters. CRUSH ist dasAkronym für Controlled Replication Under Scalable Hashing. CRUSH ist eine Funktion fürdie Speicherzuordnung und benötigt vergleichsweise wenige Parameter. Es sind also nurwenige Informationen erforderlich, um die Speicherposition eines Objekts zu berechnen. DieParameter stellen eine aktuelle Zuordnung für den Cluster dar, einschließlich Zustand, einigevom Administrator denierte Platzierungsregeln und der Name des Objekts, das gespeichertoder abgerufen werden muss. Mit diesen Informationen können alle Nodes im Ceph Clusterberechnen, wo ein Objekt und dessen Reproduktionen gespeichert sind. Dies macht dasSchreiben und Lesen von Daten sehr ezient. CRUSH versucht, Daten gleichmäßig auf alleNodes im Cluster zu verteilen.
Die CRUSH Map umfasst alle Speicher-Nodes und vom Administrator deniertePlatzierungsregeln zum Speichern von Objekten im Cluster. Sie deniert eine hierarchischeStruktur, die normalerweise mit der physischen Struktur des Clusters korrespondiert.Beispielsweise benden sich Festplatten mit Daten in Hosts, Hosts in Racks, Racks in Reihen undReihen in Rechenzentren. Diese Struktur wird zur Denition von Fehlerdomänen herangezogen.Ceph stellt dann sicher, dass Reproduktionen in verschiedenen Verzweigungen einer bestimmtenFehlerdomäne gespeichert werden.
4 CRUSH SES 6
Wenn die Fehlerdomäne auf „Rack“ festgelegt ist, werden Reproduktionen von Objekten aufverschiedene Racks verteilt. Dadurch werden Ausfälle entschärft, die durch einen fehlerhaftenSchalter in einem Rack verursacht wurden. Wenn eine Stromversorgungseinheit eine Reihevon Racks bereitstellt, kann die Fehlerdomäne auf „Reihe“ festgelegt werden. Wenn dieStromversorgungseinheit ausfällt, sind die Reproduktionsdaten noch in anderen Reihenverfügbar.
1.2.3 Ceph Nodes und Daemons
In Ceph sind Nodes Server, die für den Cluster arbeiten. Sie können verschiedene Typen vonDaemons ausführen. Es wird empfohlen, nur einen Typ von Daemon pro Node auszuführen,ausgenommen Ceph Manager Daemons, die gemeinsam mit Ceph Monitors auf einem Nodelaufen. Für jeden Client sind mindestens Ceph Monitor, Ceph Manager und Ceph OSD Daemonserforderlich:
Admin Node
Admin Node ist ein Ceph Cluster Node, in dem der Salt Master Service ausgeführt wird.Der Admin Node ist das Zentrum des Ceph Clusters, weil er alle anderen Cluster Nodesverwaltet, indem er deren Salt Minion Services abfragt und ihnen Anweisungen gibt.Er enthält normalerweise auch andere Services, beispielsweise die Ceph Dashboard-Weboberäche mit dem Grafana-Dashboard, das vom Prometheus-Überwachungs-Toolkitunterstützt wird.
Ceph Monitor
Ceph Monitor (oft als MON abgekürzt) Nodes pegen Informationen zum Cluster-Zustand,eine Zuordnung aller Nodes und Datenverteilungsregeln (weitere Informationen hierzunden Sie in Abschnitt 1.2.2, „CRUSH“).Wenn Fehler oder Konikte auftreten, entscheiden die Ceph Monitor Nodes im Cluster nachdem Mehrheitsprinzip, welche Informationen korrekt sind. Um eine qualizierte Mehrheitzu bilden, empehlt es sich, eine ungerade Anzahl von Ceph Monitor Nodes einzurichten,jedoch mindestens drei davon.Bei mehreren Standorten sollten die Ceph Monitor Nodes auf eine ungerade Anzahl vonStandorten verteilt werden. Die Anzahl der Ceph Monitor Nodes pro Standort sollte sogewählt werden, dass die Hälfte der Ceph Monitor Nodes funktionsfähig bleiben, wennein Standort ausfällt.
Ceph Manager
5 Ceph Nodes und Daemons SES 6
Der Ceph Manager (MGR) sammelt die Statusinformationen aus dem gesamten Cluster. DerCeph Manager Daemon wird neben den Monitor Daemons ausgeführt. Er bietet zusätzlicheÜberwachung und dient als Schnittstelle zwischen der externen Überwachung und denVerwaltungssystemen.Der Ceph Manager muss nicht weiter konguriert werden. Sie müssen nur sicherstellen,dass er ausgeführt wird. Sie können ihn mit DeepSea als separate Rolle bereitstellen.
Ceph OSD
Ein Ceph OSD ist ein Daemon, der Objektspeichergeräte steuert. Dabei handelt essich um physische oder logische Speichereinheiten (Festplatten oder Partitionen).Objektspeichergeräte können physische Datenträger/Partitionen oder logische Volumessein. Der Daemon kümmert sich außerdem um die Datenreproduktion und den Ausgleich,falls Nodes hinzugefügt oder entfernt wurden.Ceph OSD Daemons kommunizieren mit Monitor Daemons und informieren diese über denZustand der anderen OSD Daemons.
Für CephFS, Object Gateway, NFS Ganesha oder iSCSI Gateway sind zusätzliche Nodeserforderlich:
Metadata Server (MDS)
Metadatenserver speichern Metadaten für das CephFS. Über einen MDS führen Sie einfacheDateisystemkommandos wie ls aus, ohne den Cluster zu überlasten.
Object Gateway
Das Object Gateway ist ein HTTP-REST-Gateway für den RADOS-Objektspeicher. Esist mit OpenStack Swift und Amazon S3 kompatibel und verfügt über eine eigeneBenutzerverwaltung.
NFS Ganesha
NFS Ganesha bietet NFS-Zugri auf das Object Gateway oder auf das CephFS. Es wird imBenutzerbereich statt im Kernel-Bereich ausgeführt und interagiert direkt mit dem ObjectGateway oder dem CephFS.
iSCSI Gateway
iSCSI ist ein Speichernetzwerkprotokoll, über das Clients SCSI-Kommandos an SCSI-Speichergeräte (Targets) auf Remote Servern senden können.
Samba Gateway
Der Samba Gateway bietet SAMBA-Zugri auf die Daten, die auf dem CephFS gespeichertsind.
6 Ceph Nodes und Daemons SES 6
1.3 Speicherstruktur
1.3.1 PoolIn einem Ceph Cluster gespeicherte Objekte werden in Pools abgelegt. Pools stellen logischePartitionen des Clusters zur Außenwelt dar. Für jeden Pool kann ein Regelsatz deniert werden,beispielsweise wie viele Reproduktionen eines jeden Objekts vorhanden sein müssen. DieStandardkonguration von Pools wird als reproduzierter Pool bezeichnet.
Pools enthalten normalerweise Objekte, können jedoch auch so konguriert werden, dass sie wieein RAID 5 funktionieren. In dieser Konguration werden Objekte in Datenblöcken zusammenmit zusätzlichen Codierungs-Datenblöcken gespeichert. Die Codierungs-Datenblöcke enthaltendie redundanten Informationen. Die Anzahl der Daten und Codierungs-Datenblöcke werden vomAdministrator deniert. In dieser Konguration werden Pools als Erasure Coded Pools bezeichnet.
1.3.2 Placement GroupPlacement Groups (PGs) dienen zur Verteilung von Daten in einem Pool. Beim Erstellen einesPools wird eine bestimmte Anzahl von Placement Groups festgelegt. Die Placement Groupswerden intern zur Gruppierung von Objekten verwendet. Sie sind ein wichtiger Faktor für dieLeistung eines Ceph Clusters. Die PG für ein Objekt wird durch den Namen des Objekts bestimmt.
1.3.3 BeispielIn diesem Abschnitt nden Sie ein vereinfachtes Beispiel dafür wie Ceph-Daten verwaltet(Abbildung 1.2, „Beispiel eines kleinen Ceph-Speichers“). Dieses Beispiel stellt keine empfohleneKonguration für einen Ceph Cluster dar. Die Hardwareeinrichtung umfasst drei Speicher-Nodesoder Ceph OSDs ( Host 1 , Host 2 , Host 3 ). Jeder Node hat drei Festplatten, die als OSDs( osd.1 bis osd.9 ) verwendet werden. In diesem Beispiel sind keine Ceph Monitor Nodesberücksichtigt.
Anmerkung: Unterschied zwischen Ceph OSD und OSDDie Begrie Ceph OSD oder Ceph OSD Daemon beziehen sich auf einen Daemon, der aufeinem Node ausgeführt wird. Der Begri OSD dagegen bezieht sich auf einen logischenDatenträger, mit dem der Daemon interagiert.
7 Speicherstruktur SES 6
Der Cluster umfasst zwei Pools, Pool A und Pool B . Während Pool A Objekte nur zweimalreproduziert, ist Ausfallsicherheit für Pool B wichtiger und es gibt daher drei Reproduktionenfür jedes Objekt.
Wenn eine Anwendung ein Objekt in einen Pool stellt, beispielsweise über die REST API,dann wird eine Placement Group ( PG1 bis PG4 ) auf Basis des Pools und des Objektnamensausgewählt. Der CRUSH-Algorithmus berechnet dann, auf welchen OSDs das Objekt gespeichertist, basierend auf der Placement Group, die das Objekt enthält.
In diesem Beispiel ist die Fehlerdomäne auf Host festgelegt. Dadurch wird sichergestellt, dass dieReproduktionen von Objekten auf verschiedenen Hosts gespeichert sind. Je nach der für einenPool festgelegten Reproduktionsstufe wird das Objekt auf zwei oder drei OSDs gespeichert, dievon der Placement Group verwendet werden.
Eine Anwendung, die ein Objekt schreibt, interagiert nur mit einem Ceph OSD, nämlich demprimären Ceph OSD. Der primäre Ceph OSD führt die Reproduktion aus und bestätigt dieDurchführung des Schreibvorgangs, nachdem alle anderen OSDs das Objekt gespeichert haben.
Wenn osd.5 ausfällt, sind alle Objekte in PG1 immer noch auf osd.1 verfügbar. Sobald derCluster feststellt, dass ein OSD ausgefallen ist, übernimmt ein anderer OSD. In diesem Beispielwird osd.4 als Ersatz für osd.5 verwendet. Die auf osd.1 gespeicherten Objekte werden dannauf osd.4 reproduziert, um die Reproduktionsstufe wiederherzustellen.
ABBILDUNG 1.2: BEISPIEL EINES KLEINEN CEPH-SPEICHERS
8 Beispiel SES 6
Die Cluster-Zuordnung ändert sich, wenn ein neuer Node mit neuen OSDs zum Clusterhinzugefügt wird. Die CRUSH Funktion gibt dann verschiedene Standorte für Objekte zurück.Objekte, die neue Standorte erhalten, werden verschoben. Durch diesen Vorgang bleiben alleOSDs gleichmäßig ausgelastet.
1.4 BlueStoreBlueStore ist seit SUSE Enterprise Storage 5 ein neues standardmäßiges Speicher-Back-End für Ceph. Seine Leistung ist besser als die von FileStore. Es umfasst vollständigePrüfsummenerstellung für Daten und weist eine integrierte Komprimierung auf.
BlueStore verwaltet ein, zwei oder drei Speichergeräte. Im einfachsten Fall lastet BlueStore eineinzelnes primäres Speichergerät aus. Das Speichergerät ist normalerweise in zwei Abschnittepartitioniert:
1. Eine kleine Partition namens BlueFS, die Dateisystem-ähnliche Funktionalitätenimplementiert, die von RocksDB benötigt werden.
2. Eine große Partition belegt normalerweise das restliche Gerät. Sie wird direkt vonBlueStore verwaltet und enthält alle Ist-Daten. Dieses primäre Gerät ist normalerweisedurch eine Blocksymbolverknüpfung im Datenverzeichnis gekennzeichnet.
BlueStore kann auch auf zwei weiteren Geräten bereitgestellt werden:
Ein WAL-Gerät, das für das interne Journal oder Write Ahead-Protokoll von BlueStore verwendetwird. Es ist durch den symbolischen Link block.wal im Datenverzeichnis gekennzeichnet. Einseparates WAL-Gerät ist nur sinnvoll, wenn das Gerät schneller als das primäre Gerät oder dasDB-Gerät ist. Beispiel:
Das WAL-Gerät ist ein NVMe, das DB-Gerät ist ein SSD und das Datengerät ist entwederein SSD oder HDD.
Das WAL-Gerät und das DB-Gerät sind separate SSDs. Das Datengerät ist ein SSD oder HDD.
Ein DB-Gerät kann zum Speichern der internen Metadaten von BlueStore verwendet werden.BlueStore (eigentlich die eingebettete RocksDB) legt zur Leistungsoptimierung so vieleMetadaten wie möglich auf dem DB-Gerät ab. Auch hier ist die Bereitstellung eines gemeinsamgenutzten DB-Geräts nur sinnvoll, wenn es schneller ist als das primäre Gerät.
9 BlueStore SES 6
Tipp: Die DB-Größe planenPlanen Sie sorgfältig eine ausreichende Größe für das DB-Gerät. Wenn das DB-Gerät vollist, laufen die Metadaten an das primäre Gerät über, was die Leistung des OSD extrembeeinträchtigt.
Mit dem Kommando ceph daemon osd.ID perf dump können Sie prüfen, ob eine WAL/DB-Partition voll wird und überläuft. Der Wert slow_used_bytes gibt die Anzahl derDaten an, die überlaufen:
cephadm@adm > ceph daemon osd.ID perf dump | jq '.bluefs'"db_total_bytes": 1073741824,"db_used_bytes": 33554432,"wal_total_bytes": 0,"wal_used_bytes": 0,"slow_total_bytes": 554432,"slow_used_bytes": 554432,
1.5 Weitere Informationen
Ceph hat als Community-Projekt eine eigene Online-Dokumentation. WeitereInformationen zu Themen, die in diesem Handbuch nicht behandelt werden, nden Sieunter http://docs.ceph.com/docs/master/ .
In der ursprünglichen Veröentlichung mit dem Titel CRUSH: Controlled, Scalable,Decentralized Placement of Replicated Data von S.A. Weil, S.A. Brandt, E.L. Miller, C. Maltzahnnden Sie nützliche Informationen zu den inneren Abläufen in Ceph. Die Lektüre empehltsich vor allem für die Bereitstellung von Clustern mit großem Volumen. Sie nden dieVeröentlichung unter http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf
SUSE Enterprise Storage kann zusammen mit OpenStack-Distributionen anderer Herstellerverwendet werden. Die Ceph Clients müssen sich auf einer Ebene benden, die mit SUSEEnterprise Storage kompatibel sind.
AnmerkungSUSE unterstützt die Serverkomponente der Ceph-Bereitstellung, der Client wirdvom Anbieter der OpenStack-Distribution unterstützt.
10 Weitere Informationen SES 6
2 Hardwareanforderungen und Empfehlungen
Die Hardwareanforderungen für Ceph hängen stark vom E/A-Workload ab. Die folgendenHardwareanforderungen und Empfehlungen sollten als Ausgangspunkt für die detailliertePlanung betrachtet werden.
Im Allgemeinen sind die Empfehlungen in diesem Abschnitt auf jeweils einen Prozess ausgelegt.Wenn auf dem selben Rechner mehrere Prozesse ablaufen, müssen die CPU-, RAM-, Festplatten-und Netzwerkanforderungen entsprechend erhöht werden.
2.1 Konfigurationen mit mehreren ArchitekturenSUSE Enterprise Storage unterstützt sowohl x86- als auch Arm-Architekturen. Bei der Erwägungder einzelnen Architekturen ist zu beachten, dass es bei den Cores pro OSD, der Frequenz unddem RAM keine gravierenden Unterschiede zwischen den CPU-Architekturen gibt, die sich aufdie Größenfestlegung auswirken würden.
Wie bei kleineren x86-Prozessoren (keine Server) bieten weniger leistungsstarke Arm-basierteCores unter Umständen keine optimalen Arbeitsbedingungen, insbesondere wenn sie für Poolsmit Löschcodierung eingesetzt werden.
2.2 Mindestkonfiguration für den Cluster
Es sind mindestens vier OSD Nodes mit jeweils acht OSD-Festplatten erforderlich.
Drei Ceph Monitor Nodes (SSD für dediziertes Betriebssystemlaufwerk erforderlich).
iSCSI-Gateways, Object Gateways und Metadatenserver benötigen inkrementell 4 GB RAMund vier Cores.
Für Ceph Monitors, Object Gateways und Metadatenserver Nodes ist eine redundanteBereitstellung erforderlich.
Separater Verwaltungs-Node mit 4 GB RAM, vier Cores, 1 TB Kapazität. Dies ist in der Regelder Salt Master Node. Ceph Services und Gateways, z. B. Ceph Monitor, Ceph Manager,Metadatenserver, Ceph OSD, Object Gateway oder NFS Ganesha, werden auf dem AdminNode nicht unterstützt.
11 Konfigurationen mit mehreren Architekturen SES 6
2.3 Objektspeicher-Nodes
2.3.1 Mindestanforderungen
CPU-Empfehlungen:
Ein 2-GHz-CPU-Thread pro rotierendem Datenträger
Zwei 2-GHz-CPU-Threads pro SSD
Vier 2-GHz-CPU-Threads pro NVMe
Separate 10-GbE-Netzwerke (öentlich/Client und Back-End), erforderlich 4 × 10 GbE,empfohlen 2 × 25 GbE.
Insgesamt benötigtes RAM = Anzahl der OSDs × (1 GB + osd_memory_target ) + 16 GBWeitere Informationen zu osd_memory_target nden Sie in Buch „Verwaltungshandbuch”,
Kapitel 16 „Ceph Cluster-Konfiguration“, Abschnitt 16.2.1 „Automatische Festlegung der Cache-
Größe“.
OSD-Datenträger in JBOD-Kongurationen oder individuelle RAID-0-Kongurationen.
OSD-Journal darf sich auf der OSD-Festplatte benden.
OSD-Festplatten sollten exklusiv von SUSE Enterprise Storage verwendet werden.
Dedizierte Festplatte/SSD für das Betriebssystem, vorzugsweise in einer RAID 1-Konguration.
Wenn dieser OSD-Host einen Teil eines Cache Pools hostet, der für ein Cache Tieringverwendet wird, müssen Sie mindestens weitere 4 GB RAM zuordnen.
Ceph Monitors, Gateway und Metadata Server dürfen in Objektspeicher-Nodes vorhandensein.
Aus Gründen der Datenträgerleistung wird Bare Metal-Hardware für OSD Nodes empfohlen(keine virtuellen Maschinen).
12 Objektspeicher-Nodes SES 6
2.3.2 Mindestfestplattengröße
Zwei Arten von Festplattenspeicherplatz werden zur Ausführung auf OSD benötigt: derSpeicherplatz für das Festplattenjournal (für FileStore) oder WAL/DB-Gerät (für BlueStore)sowie der primäre Speicherplatz für die gespeicherten Daten. Der Mindestwert (undStandardwert) für Journal/WAL/DB beträgt 6 GB. Der Mindestspeicherplatz für Daten beträgt5 GB, da Partitionen, die kleiner als 5 GB sind, das Gewicht 0 zugewiesen wird.
Auch wenn nun der Mindestspeicherplatz für ein OSD 11 GB beträgt, empfehlen wir mindestens20 GB pro Festplatte, sogar für Testzwecke.
2.3.3 Empfohlene Größe für das WAL- und DB-Gerät von BlueStore
Tipp: Weitere InformationenWeitere Informationen zu BlueStore nden Sie in Abschnitt 1.4, „BlueStore“.
Es wird empfohlen, 4 GB für das WAL-Gerät zu reservieren. Die empfohlene Größe für DBliegt bei den meisten Workloads bei 64 GB.
Falls Sie beabsichtigen, das WAL- und DB-Gerät auf dieselbe Festplatte zu stellen, dannempfehlen wir eine einzelne Partition für beide Geräte statt eine eigene Partition proGerät. Dadurch kann Ceph das DB-Gerät auch für WAL-Operationen verwenden. DieVerwaltung des Festplattenspeicherplatzes ist daher ezienter, weil Ceph die DB-Partitionfür WAL nur dann verwendet, wenn es unbedingt erforderlich ist. Ein weiterer Vorteilbesteht darin, dass eine volle Auslastung der WAL-Partition sehr unwahrscheinlich istund kein Speicherplatz verschwendet wird, da er gegebenenfalls auch für DB-Operationenverwendet werden kann.Um das DB-Gerät für WAL freizugeben, geben Sie nicht das WAL-Gerät an, sondern nurdas DB-Gerät.Weitere Informationen zum Festlegen eines OSD-Layouts nden Sie in Abschnitt 5.5.2,
„DriveGroups“.
13 Mindestfestplattengröße SES 6
2.3.4 Verwenden von SSD für OSD-Journale
Solid-State- oder Festkörperlaufwerke (SSD) haben keine beweglichen Teile. Dadurch wird dieZeit für den zufälligen Zugri und die Leselatenz reduziert und der Datendurchsatz beschleunigt.Da der Preis pro 1 MB für SSDs erheblich höher ist als der Preis für sich drehende Festplatten,eignen sich SSDs nur für kleinere Speicher.
Die Leistung von OSDs wird möglicherweise erheblich verbessert, wenn Sie deren Journal aufeinem SSD speichern und die Objektdaten auf einer separaten Festplatte.
Tipp: Gemeinsame Nutzung eines SSD für mehrere JournaleDa Journaldaten relativ wenig Speicherplatz belegen, können Sie mehrereJournalverzeichnisse auf einer einzigen SSD-Festplatte einhängen. Bedenken Sie dabeijedoch, dass sich mit jedem freigegebenen Journal die Leistung der SSD-Festplatteverschlechtert. Wir empfehlen, maximal sechs Journale pro SSD-Festplatte zu speichernund zwölf pro NVMe-Festplatte.
2.3.5 Maximale empfohlene Anzahl von Festplatten
Jeder Server kann so viele Festplatten enthalten wie für ihn zulässig sind. Bei der Planung derAnzahl von Festplatten pro Server gibt es einiges zu bedenken:
Netzwerk-Bandbreite. Je mehr Festplatten ein Server enthält, desto mehr Daten müssen fürdie Schreiboperationen der Festplatte über die Netzwerkkarte(n) übertragen werden.
Arbeitsspeicher. RAM ab 2 GB wird für den BlueStore-Cache herangezogen. Mit demStandardwert von 4 GB für osd_memory_target erhält das System eine angemesseneCache-Anfangsgröße für rotierende Datenträger. Bei SSD oder NVME sollten Sie die Cache-Größe und die RAM-Zuordnung pro OSD erhöhen, damit die höchstmögliche Leistungerzielt wird.
Fehlertoleranz. Wenn der Server komplett ausfällt, verliert der Cluster temporär so vieleOSDs wie er Festplatten hat. Darüberhinaus müssen Sie alle Daten des ausgefallenenServers auf die anderen Nodes im Cluster kopieren, damit die Reproduktionsregelnweiterhin ausgeführt werden.
14 Verwenden von SSD für OSD-Journale SES 6
2.4 Monitor Nodes
Mindestens drei Ceph Monitor Nodes sind erforderlich. Die Anzahl der Monitors sollteimmer ungerade sein (1+2n).
4 GB RAM.
Prozessor mit vier logischen Cores.
Ein SSD oder ein anderer ausreichend schneller Speichertyp ist für Monitorssehr zu empfehlen, insbesondere für den Pfad /var/lib/ceph in jedem MonitorNode, da das Quorum bei hohen Festplattenlatenzen möglicherweise instabil ist.Zwei Festplatten in der RAID 1-Konguration werden aus Redundanzgründenempfohlen. Es wird empfohlen, dass separate Festplatten oder mindestens separateFestplattenpartitionen für die Überwachungsprozesse zur Verfügung stehen, um denverfügbaren Festplattenspeicherplatz des Monitors vor Ereignissen wie schleichenderProtokolldateiausweitung zu schützen.
Pro Node darf nur ein Überwachungsprozess vorhanden sein.
Die Kombination von OSD, Monitor oder Object Gateway Nodes wird nur unterstützt, wennausreichend Hardwareressourcen verfügbar sind. Dies bedeutet, dass die Anforderungenfür alle Services aufsummiert werden müssen.
Zwei Netzwerkschnittstellen verbunden mit mehreren Schaltern.
2.5 Object Gateway NodesObject Gateway Nodes sollten sechs bis acht CPU Cores und 32 GB RAM haben (64 GBempfohlen). Wenn sich noch andere Prozesse auf demselben Rechner benden, müssen derenAnforderungen aufsummiert werden.
2.6 Metadata Server NodesDie richtige Größe der Metadata Server Nodes hängt vom spezischen Anwendungsfall ab.Generell gilt, je mehr oene Dateien der Metadata Server verarbeiten muss, desto mehr CPUund RAM benötigt er. Nachfolgend nden Sie die Mindestanforderungen an die
15 Monitor Nodes SES 6
3 GB RAM für jeden Metadatenserver-Daemon.
Gebundene Netzwerkschnittstelle.
2,5 GHz CPU mit mindestens 2 Cores.
2.7 Salt MasterMindestens 4 GB RAM und ein CPU mit vier Cores sind erforderlich. Dies umfasst die Ausführungdes Ceph Dashboards auf dem Admin Node. Für große Cluster mit Hunderten von Nodes werden6 GB RAM vorgeschlagen.
2.8 iSCSI NodesiSCSI Nodes sollten sechs bis acht CPU-Cores und 16 GB RAM haben.
2.9 NetzwerkempfehlungenDie Netzwerkumgebung, in der Sie Ceph ausführen möchten, sollte idealerweise einegebundene Gruppe von mindestens zwei Netzwerkschnittstellen sein, die logisch aufgeteilt istin einen öentlichen Teil und einen verbürgten internen Teil über VLANs. Der empfohleneBindungsmodus ist 802.3ad, falls möglich, um maximale Bandbreite und Stabilität zurVerfügung zu stellen.
Das öentliche VLAN dient dazu, den Service für Kunden bereitzustellen. Der interne Teilsorgt für die authentizierte Ceph Netzwerkkommunikation. Der Hauptgrund dafür bestehtdarin, dass die Nachrichten zum Kongurieren geheimer Schlüssel möglicherweise öentlichübertragen werden und daher eine Schwachstelle darstellen, denn Ceph bietet Authentizierungund Schutz vor Angrien erst, nachdem diese geheimen Schlüssel hinzugefügt wurden.
Tipp: Über DHCP konfigurierte NodesWenn Ihre Speicher-Nodes über DHCP konguriert werden, reichen die standardmäßigenZeitüberschreitungen möglicherweise nicht für eine korrekte Konguration desNetzwerks aus, bevor die Ceph Daemons starten. In diesem Fall starten die Ceph MONsund OSDs nicht korrekt (die Ausführung von systemctl status ceph\* führt zu
16 Salt Master SES 6
„unable to bind“-Fehlern). Wir empfehlen, die Zeitüberschreitung des DHCP-Clients injedem Node in Ihrem Speicher-Cluster auf mindestens 30 Sekunden zu erhöhen. Dies wirderreicht durch Ändern der folgenden Einstellungen in jedem Node:
Legen Sie in /etc/sysconfig/network/dhcp Folgendes fest:
DHCLIENT_WAIT_AT_BOOT="30"
Legen Sie in /etc/sysconfig/network/config Folgendes fest:
WAIT_FOR_INTERFACES="60"
2.9.1 Hinzufügen eines privaten Netzwerks zu einem aktivenCluster
Wenn Sie bei der Ceph-Bereitstellung kein Cluster-Netzwerk angeben, dann wird eine einzelneöentliche Netzwerkumgebung angenommen. Auch wenn Ceph in einem öentlichen Netzwerkgut funktioniert, wird seine Leistung und Sicherheit durch Festlegen eines zweiten privatenCluster-Netzwerks erhöht. Zur Unterstützung von zwei Netzwerken muss jeder Ceph Node übermindestens zwei Netzwerkkarten verfügen.
Sie müssen auf jeden Ceph Node die folgenden Änderungen anwenden. Bei einem kleinen Clusterist dies relativ schnell erledigt, doch bei einem Cluster mit Hunderten oder Tausenden Nodeskann dieser Vorgang sehr zeitaufwändig sein.
1. Halten Sie die auf Ceph bezogenen Services in jedem Cluster Node an.Fügen Sie eine Zeile zu /etc/ceph/ceph.conf hinzu, um das Cluster-Netzwerk zudenieren. Beispiel:
cluster network = 10.0.0.0/24
Wenn Sie eigens statische IP-Adressen zuweisen oder die cluster network -Einstellungenaußer Kraft setzen müssen, können Sie dies mit der optionalen Einstellung cluster addrerledigen.
2. Überprüfen Sie, ob das private Cluster-Netzwerk auf Betriebssystemebene wie erwartetfunktioniert.
3. Starten Sie die auf Ceph bezogenen Services in jedem Cluster Node.
17 Hinzufügen eines privaten Netzwerks zu einem aktiven Cluster SES 6
root # systemctl start ceph.target
2.9.2 Monitor Nodes in verschiedenen Teilnetzen
Wenn sich die Monitor Nodes in mehreren Teilnetzen benden, beispielsweise in verschiedenenRäumen und durch verschiedene Schalter gesteuert, dann müssen Sie die Datei ceph.confentsprechend anpassen. Wenn beispielsweise die Nodes die IP-Adressen 192.168.123.12, 1.2.3.4und 242.12.33.12 aufweisen, fügen Sie die folgenden Zeilen zum Abschnitt global hinzu:
[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]
Müssen Sie eine öentliche Adresse oder ein öentliches Netzwerk pro Monitor angeben, dannmüssen Sie außerdem einen Abschnitt [mon.X] für jeden Monitor hinzufügen:
[mon.MON1]public network = 192.168.123.0/24
[mon.MON2]public network = 1.2.3.0/24
[mon.MON3]public network = 242.12.33.12/0
2.10 BenennungseinschränkungenCeph unterstützt nicht generell Nicht-ASCII-Zeichen in Kongurationsdateien, Pool-Namen,Benutzernamen und so weiter. Wir empfehlen, beim Kongurieren eines Ceph Clusters in allenCeph-Objekt- bzw. Kongurationsnamen nur einfache alphanumerische Zeichen (A-Z, a-z, 0-9)und wenige Satzzeichen ('.', '-', '_') zu verwenden.
18 Monitor Nodes in verschiedenen Teilnetzen SES 6
2.11 Ein einziger Server für OSD und MonitorObwohl es technisch möglich ist, Ceph OSDs und Monitors in Testumgebungen auf demselbenServer auszuführen, empfehlen wir dringend, einen separaten Server für jeden Monitor Nodein der Produktionsumgebung einzurichten. Der hauptsächliche Grund dafür ist die Leistung.Je mehr OSDs der Cluster enthält, desto mehr E/A-Operationen müssen die Monitor Nodesdurchführen. Wenn ein Server von einem Monitor Node und OSD(s) gemeinsam genutzt wird,stellen die E/A-Operationen des OSD eine Beschränkung für den Monitor Node dar.
Es ist weiterhin zu überlegen, ob Festplatten von einem OSD, einem Monitor Node und demBetriebssystem auf dem Server gemeinsam genutzt werden sollen. Die Antwort ist einfach: wennmöglich, stellen Sie eine separate Festplatte für den OSD bereit und einen separaten Server füreinen Monitor Node.
Obwohl Ceph verzeichnisbasierte OSDs unterstützt, sollte für einen OSD immer eine eigeneFestplatte vorhanden sein und nicht die des Betriebssystems dafür genutzt werden.
TippWenn es wirklich erforderlich ist, OSD und Monitor Node auf demselben Serverauszuführen, führen Sie den Monitor auf einer separaten Festplatte aus. Hängen Siedazu die Festplatte im Verzeichnis /var/lib/ceph/mon ein, um die Leistung etwas zuverbessern.
2.12 Empfohlene Konfiguration für Produktions-Cluster
Sieben Objektspeicher-Nodes
Die einzelnen Nodes dürfen nicht mehr als ca. 15 % des Gesamtspeichers ausmachen
10 GB Ethernet (vier physische Netzwerke gebunden an mehrere Schalter)
Mindestens 56 OSDs pro Speicher-Cluster
RAID 1-Betriebssystemfestplatte für jeden OSD-Speicher-Node
SSDs für Journal im Verhältnis 6:1 von SSD-Journal zu OSD
19 Ein einziger Server für OSD und Monitor SES 6
1,5 GB RAM pro TB der OSD-Basiskapazität für jeden Objektspeicher-Node
2 GHz pro OSD für jeden Objektspeicher-Node
Dedizierte physische Infrastruktur-Nodes
Drei Ceph Monitor Nodes: 4 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte
Ein SES-Verwaltungs-Node: 4 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte
Redundante physische Bereitstellung von Gateway oder Metadata Server Nodes:
Object Gateway Nodes: 32 GB RAM, 8-Core-Prozessor, RAID 1-SSDs alsFestplatte
iSCSI Gateway Nodes: 16 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte
Metadata Server Nodes (einer aktiv, einer unmittelbar betriebsbereit imStandby-Modus): 32 GB RAM, 8-Core-Prozessor, RAID 1-SSDs als Festplatte
2.13 SUSE Enterprise Storage 6 und andere SUSE-ProdukteDieser Abschnitt enthält wichtige Informationen zur Integration von SUSE Enterprise Storage6 in andere SUSE-Produkte.
2.13.1 SUSE Manager
SUSE Manager und SUSE Enterprise Storage sind nicht integriert. Daher kann SUSE Manageraktuell keinen SUSE Enterprise Storage Cluster verwalten.
20 SUSE Enterprise Storage 6 und andere SUSE-Produkte SES 6
3 Einrichten des Hochverfügbarkeits-Clusters für denAdmin Node
Der Admin Node ist ein Ceph Cluster Node, in dem der Salt Master Service ausgeführt wird.Der Admin Node ist das Zentrum des Ceph Clusters, weil er alle anderen Cluster Nodesverwaltet, indem er deren Salt Minion Services abfragt und ihnen Anweisungen gibt. Er enthältnormalerweise auch andere Services, beispielsweise die Ceph Dashboard-Weboberäche mitdem Grafana Dashboard, das vom Prometheus-Überwachungs-Toolkit unterstützt wird.
Falls im Admin Node ein Fehler auftritt, müssen Sie normalerweise neue funktionierendeHardware für den Node zur Verfügung stellen und den gesamten Kongurationsstapel desClusters von einer kürzlich erstellten Sicherung wiederherstellen. Eine derartige Methode istzeitaufwändig und verursacht den Ausfall des Clusters.
Wir empfehlen einen Hochverfügbarkeits-Cluster für den Ceph Admin Node, um Ausfallzeitenin der Ceph Cluster-Leistung, die durch Admin Node-Fehler verursacht werden, zu verhindern.
3.1 Überblick zum Hochverfügbarkeits-Cluster fürAdmin NodeHinter einem Hochverfügbarkeits-Cluster steckt die Überlegung, dass im Fall eines Fehlersim Cluster Node der andere Node automatisch dessen Rolle übernimmt, einschließlich desvirtualisierten Admin Node. Auf diese Weise bemerken andere Ceph Cluster Nodes gar nicht,dass im Admin Node ein Fehler aufgetreten ist.
Für die Mindestlösung eines Hochverfügbarkeits-Clusters für den Admin Node ist die folgendeHardware erforderlich:
Zwei Bare Metal Server, auf denen SUSE Linux Enterprise mit derHochverfügbarkeitserweiterung ausgeführt und der Admin Node virtualisiert wird.
Mindestens zwei redundante Pfade für die Netzwerkkommunikation, beispielsweise durchNetzwerkgeräte-Bonding.
Gemeinsamer Speicher zum Hosten von Festplatten-Images der virtuellen Maschine desAdmin Node. Beide Server müssen auf den gemeinsamen Server zugreifen können. Es kannsich dabei beispielsweise um einen NFS-Export, eine Samba-Freigabe oder ein iSCSI-Zielhandeln.
21 Überblick zum Hochverfügbarkeits-Cluster für Admin Node SES 6
Weitere detaillierte Informationen zu den Cluster-Anforderungennden Sie in https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/
sec_ha_inst_quick_req.html .
ABBILDUNG 3.1: HOCHVERFÜGBARKEITS-CLUSTER MIT ZWEI NODES FÜR ADMIN NODE
3.2 Erstellen eines Hochverfügbarkeits-Clusters mitAdmin NodeDer folgende Vorgang fasst die wichtigsten Schritte zur Erstellung des Hochverfügbarkeits-Clusters zur Virtualisierung des Admin Node zusammen. Weitere detaillierte Informationennden Sie unter den angegebenen Links.
1. Richten Sie einen einfachen Hochverfügbarkeits-Cluster mit zwei Nodesund gemeinsamem Speicher ein. Eine Beschreibung hierzu ndenSie unter https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/
art_sleha_install_quick.html .
2. Installieren Sie in beiden Cluster Nodes alle Pakete, die zur Ausführung desKVM-Hypervisors und des libvirt -Toolkits erforderlich sind. Eine Beschreibunghierzu nden Sie unter https://www.suse.com/documentation/sles-15/book_virt/data/
sec_vt_installation_kvm.html .
22 Erstellen eines Hochverfügbarkeits-Clusters mit Admin Node SES 6
3. Erstellen Sie im ersten Cluster Node eine neue virtuelle KVM-Maschine und nutzenSie dazu libvirt . Eine Beschreibung hierzu nden Sie unter https://www.suse.com/
documentation/sles-15/book_virt/data/sec_libvirt_inst_vmm.html . Speichern Sie dieFestplatten-Images der VM im vorkongurierten gemeinsamen Speicher.
4. Exportieren Sie nach Abschluss der VM-Einrichtung deren Konguration in eine XML-Datei im gemeinsamen Speicher. Verwenden Sie die folgende Syntax:
root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml
5. Erstellen Sie eine Ressource für die VM des Admin Node.Allgemeine Informationen zum Erstellen von Hochverfügbarkeits-Ressourcennden Sie unter https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/
cha_conf_hawk2.html . Detaillierte Informationen zum Erstellen einer Ressource füreine virtuelle KVM-Maschine nden Sie unter http://www.linux-ha.org/wiki/VirtualDomain_
%28resource_agent%29 .
6. Stellen Sie auf dem neu erstellten VM-Gast den Admin Node einschließlich der dortbenötigten weiteren Services bereit. Befolgen Sie die relevanten Anweisungen unterAbschnitt 5.3, „Cluster-Bereitstellung“. Stellen Sie gleichzeitig die restlichen Ceph ClusterNodes auf den Servern ohne Hochverfügbarkeits-Cluster bereit.
23 Erstellen eines Hochverfügbarkeits-Clusters mit Admin Node SES 6
4 Benutzerrechte und Kommandozeilen
Als Ceph Cluster-Administrator können Sie das Cluster-Verhalten mit bestimmten Kommandoskongurieren und anpassen. Hierzu benötigen Sie verschiedene Arten von Kommandos:
4.1 Salt-/DeepSea-spezifische KommandosMit diesen Kommandos können Sie den Ceph Cluster implementieren oder aufrüsten,Kommandos auf mehreren (oder allen) Cluster Nodes gleichzeitig ausführen oder auch ClusterNodes hinzufügen oder entfernen. Die Kommandos salt , salt-run und deepsea werden amhäugsten verwendet. Salt-Kommandos müssen auf dem Salt Master Node (siehe Abschnitt 5.2,
„Einführung zu DeepSea“) als root ausgeführt werden. Diese Kommandos werden in der folgendenKommandozeile eingegeben:
root@master #
Beispiel:
root@master # salt '*.example.net' test.ping
4.2 Ceph-spezifische KommandosMit diesen systemnahen Kommandos können Sie alle Aspekte des Clusters und dessen Gatewaysüber die Kommandozeile kongurieren und abstimmen. ceph , rbd , radosgw-admin odercrushtool sind nur einige Beispiele.
Zum Ausführen von Ceph-spezischen Kommandos benötigen Sie den Lesezugri auf einenCeph-Schlüssel. Die Capabilities des Schlüssels denieren dann Ihre Rechte in der Ceph-Umgebung. Sie können die Ceph-Kommandos als root (oder über sudo ) ausführen und denuneingeschränkten Standard-Schlüsselbund „ceph.client.admin.key“ verwenden.
Als sichere und empfohlene Alternative erstellen Sie je einen stärker eingeschränkten,individuellen Schlüssel für die einzelnen verwaltungsberechtigten Benutzer, den Sie dann ineinem Verzeichnis ablegen, in dem die Benutzer ihn lesen können, beispielsweise:
~/.ceph/ceph.client.USERNAME.keyring
24 Salt-/DeepSea-spezifische Kommandos SES 6
Tipp: Pfad der Ceph-SchlüsselSollen ein benutzerdenierter verwaltungsberechtigter Benutzer und Schlüsselbundverwendet werden, müssen Sie den Benutzernamen und den Pfad des Schlüssels bei jederAusführung des Kommandos ceph mit den Optionen -n client angeben.USER_NAMEund --keyring PATH/TO/KEYRING angeben.
Um dies zu vermeiden, nehmen Sie diese Optionen in die Variable CEPH_ARGS in denDateien ~/.bashrc der einzelnen Benutzer auf.
Ceph-spezische Kommandos können auf jedem Cluster Node ausgeführt werden; es wird jedochempfohlen, sie ausschließlich auf dem Admin Node auszuführen. In dieser Dokumentationwerden die Kommandos mit dem Benutzer cephadm ausgeführt. Die Kommandozeile lautetdaher:
cephadm@adm >
Beispiel:
cephadm@adm > ceph auth list
Tipp: Kommandos für bestimmte KnotenWenn Sie laut Dokumentation ein Kommando für einen Cluster Node mit einerbestimmten Rolle ausführen sollen, ist dies an der Bezeichnung der Kommandozeileersichtlich. Beispiel:
cephadm@mon >
4.3 Allgemeine Linux-KommandosBei Linux-Kommandos, die nicht mit Ceph oder DeepSea zusammenhängen, z. B. mount , catoder openssl , wird entweder cephadm@adm > oder root # als Kommandozeile angezeigt,abhängig von den Berechtigungen, die für das betreende Kommando erforderlich sind.
25 Allgemeine Linux-Kommandos SES 6
4.4 Weitere InformationenWeitere Informationen zur Ceph-Schlüsselverwaltung nden Sie in Buch „Verwaltungshandbuch”,
Kapitel 8 „Authentifizierung mit cephx“, Abschnitt 8.2 „Schlüsselverwaltung“.
26 Weitere Informationen SES 6
II Cluster-Bereitstellung und Upgrade
5 Bereitstellen mit DeepSea/Salt 28
6 Upgrade von vorigen Versionen 63
7 Anpassen der Standardkonfiguration 93
5 Bereitstellen mit DeepSea/Salt
Salt bildet zusammen mit DeepSea ein Paket von Komponenten, die bei der Bereitstellung undVerwaltung von Serverinfrastruktur nützlich sind. Es ist hoch skalierbar, schnell und lässt sichrelativ leicht in Betrieb nehmen. Lesen Sie die folgenden Überlegungen, bevor Sie mit derBereitstellung des Clusters mit Salt beginnen:
Salt Minions sind die Nodes, die von einem dedizierten Node namens Salt Master gesteuertwerden. Salt Minions verfügen über Rollen wie zum Beispiel Ceph OSD, Ceph Monitor,Ceph Manager, Object Gateway, iSCSI Gateway oder NFS Ganesha.
Ein Salt Master führt seinen eigenen Salt Minion aus. Er ist erforderlich zum Ausführenvon privilegierten Aufgaben, beispielsweise Erstellen, Autorisieren und Kopieren vonSchlüsseln für Minions, sodass Remote Minions niemals privilegierte Aufgaben ausführenmüssen.
Tipp: Freigeben mehrerer Rollen pro ServerSie erreichen die optimale Leistung Ihres Ceph Clusters, wenn jede Rolle in einemseparaten Node bereitgestellt wird. Manchmal ist es jedoch bei Bereitstellungenerforderlich, einen Node für mehrere Rollen freizugeben. Stellen Sie die Ceph OSD-,Metadatenserver- oder Ceph Monitor-Rolle nicht auf dem Admin Node bereit, umProbleme mit der Leistung und dem Upgrade-Vorgang zu vermeiden.
Salt Minions müssen den Hostnamen des Salt Master im gesamten Netzwerk korrektauösen. Standardmäßig suchen sie nach dem Hostnamen salt , Sie können jedochauch in Datei /etc/salt/minion jeden vom Netzwerk erreichbaren Hostnamen angeben.Weitere Informationen hierzu nden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.
28 SES 6
5.1 Lesen Sie die VersionshinweiseIn den Versionshinweisen nden Sie zusätzliche Informationen zu den Änderungen, die seit dervorigen Version von SUSE Enterprise Storage vorgenommen wurden. Informieren Sie sich inden Versionshinweisen über Folgendes:
Sind bei der Hardware besondere Überlegungen zu beachten?
Wurden erhebliche Änderungen an den verwendeten Software-Paketen vorgenommen?
Gelten besondere Vorsichtsmaßnahmen für die vorliegende Installation?
In den Versionshinweisen nden Sie auch Informationen, die erst nach der Fertigstellung desHandbuchs bekannt wurden. Auch bekannte Probleme werden beschrieben.
Nach Installation des Pakets release-notes-sesnden Sie die Versionshinweise lokalim Verzeichnis /usr/share/doc/release-notes oder online unter https://www.suse.com/
releasenotes/ .
5.2 Einführung zu DeepSeaDas Ziel von DeepSea besteht darin, dem Administrator Zeit zu sparen und komplexeOperationen im Ceph Cluster zuverlässig durchzuführen.
Ceph ist eine umfassend kongurierbare Softwarelösung. Systemadministratoren gewinnendadurch mehr Freiheit, haben aber auch mehr Verantwortung.
Die minimale Einrichtung von Ceph eignet sich gut für Demonstrationszwecke, zeigt jedochnicht die interessanten Funktionen von Ceph, die bei einer großen Anzahl von Nodes zum Tragenkommen.
DeepSea erfasst und speichert Daten über individuelle Server, wie Adressen und Gerätenamen.Bei einem dezentralen Speichersystem wie Ceph müssen gegebenenfalls Hunderte solcherElemente erfasst und gespeichert werden. Manuelles Erfassen von Informationen und Eingebender Daten in ein Kongurationsmanagement-Tool ist ermüdend und fehleranfällig.
Die zum Vorbereiten des Servers, Erfassen der Konguration sowie zum Kongurieren undBereitstellen von Ceph erforderlichen Schritte sind weitgehend dieselben. Dies trit jedoch nichtauf das Verwalten der unterschiedlichen Funktionen zu. Bei täglich anfallenden Vorgängenbraucht man unbedingt die Möglichkeit, Hardware problemlos zu einer vorliegenden Funktionhinzuzufügen und sie wieder zu entfernen.
29 Lesen Sie die Versionshinweise SES 6
DeepSea setzt hierfür folgende Strategie ein: DeepSea konsolidiert die Entscheidungen desAdministrators in einer einzelnen Datei. Zu den Entscheidungen zählen Cluster-Zuweisung,Rollenzuweisung und Prolzuweisung. Und DeepSea fasst jede Aufgabengruppe zu einemeinfachen Ziel zusammen. Jedes Ziel ist eine Phase:
BESCHREIBUNG VON DEEPSEA-PHASEN
Phase 0 – Vorbereitung – in dieser Phase werden alle erforderlichen Updates angewendetund Ihr System wird möglicherweise neugestartet.
Wichtig: Erneute Ausführung der Phase 0 nach demNeustart des Admin NodesWenn in Phase 0 der Admin Node neu startet, um die neue Kernel-Version zuladen, müssen Sie Phase 0 erneut ausführen, ansonsten werden die Minions nichtadressiert.
Phase 1 – die Ermittlung – hier wird die gesamte Hardware im Cluster erkannt unddie erforderlichen Informationen für die Ceph-Konguration werden zusammengestellt.Ausführliche Informationen zur Konguration nden Sie in Abschnitt 5.5, „Konfiguration und
Anpassung“.
Phase 2 – Konguration – Kongurationsdaten müssen in einem bestimmten Formatvorbereitet werden.
Phase 3 – Bereitstellung – erstellt einen einfachen Ceph Cluster mit obligatorischen CephServices. Eine Liste der Services nden Sie in Abschnitt 1.2.3, „Ceph Nodes und Daemons“.
Phase 4 – Services– zusätzliche Funktionen von Ceph wie iSCSI, Object Gateway undCephFS können in dieser Phase installiert werden. Jede der Funktionen ist optional.
Phase 5 – Entfernen. Diese Phase ist nicht obligatorisch und bei der ersten Einrichtungnormalerweise nicht erforderlich. In dieser Phase werden die Rollen der Minions undauch die Cluster-Konguration entfernt. Sie müssen diese Phase ausführen, wenn Sie einenSpeicher-Node von Ihrem Cluster entfernen müssen. Weitere Informationen nden Sie imBuch „Verwaltungshandbuch”, Kapitel 2 „Cluster-Verwaltung mit Salt“, Abschnitt 2.3 „Entfernen und
erneute Installation von Cluster Nodes“.
30 Einführung zu DeepSea SES 6
5.2.1 Organisation und wichtige Standorte
Salt wendet für Ihren Master Node einige standardmäßige Standorte undBenennungskonventionen an:
/srv/pillar
In diesem Verzeichnis werden Kongurationsdaten für Ihre Cluster Minions gespeichert.Pillar ist eine Schnittstelle zum Bereitstellen globaler Kongurationswerte für alle ClusterMinions.
/srv/salt/
In diesem Verzeichnis speichert Salt die Zustandsdateien (auch sls-Dateien genannt).Zustandsdateien sind formatierte Beschreibungen zum Zustand, in dem sich der Clusterbenden sollte.
/srv/module/runners
In diesem Verzeichnis werden Python-Skripts gespeichert, die als Ausführungsprogramme(runner) bezeichnet werden. Die Ausführungsprogramme werden im Master Nodeausgeführt.
/srv/salt/_modules
In diesem Verzeichnis werden Python-Skripts gespeichert, die als Module bezeichnetwerden. Die Module werden auf alle Minions in Ihrem Cluster angewendet.
/srv/pillar/ceph
Dieses Verzeichnis wird von DeepSea verwendet. Erfasste Kongurationsdaten werden hiergespeichert.
/srv/salt/ceph
Ein von DeepSea verwendetes Verzeichnis. In ihm werden sls-Dateien gespeichert, dieunterschiedliche Formate aufweisen, doch jedes Unterverzeichnis enthält sls-Dateien.Jedes Unterverzeichnis enthält nur einen Typ von sls-Datei. Beispiel: /srv/salt/
ceph/stage enthält Orchestrierungsdateien, die durch salt-run state.orchestrateausgeführt werden.
31 Organisation und wichtige Standorte SES 6
5.2.2 Adressieren der Minions
DeepSea-Kommandos werden über die Salt-Infrastruktur ausgeführt. Für das salt -Kommandomüssen Sie eine Gruppe von Salt Minions angeben, auf die das Kommando zutreen soll. Wirbeschreiben diese Gruppe von Minions als target für das salt -Kommando. In den folgendenAbschnitten werden mögliche Methoden zum Adressieren der Minions beschrieben.
5.2.2.1 Abgleichen des Minion-Namens
Sie können einen Minion oder eine Gruppe von Minions adressieren, indem Sie deren Namenabgleichen. Der Name eines Minions ist normalerweise der kurze Hostname des Nodes, indem die Minions ausgeführt werden. Diese Adressierungsmethode ist für Salt spezisch undtrit nicht auf DeepSea zu. Sie können den Bereich der Minion-Namen durch Verwendenvon Platzhaltern, reguläre Ausdrücke oder Listen eingrenzen. Im Allgemeinen sieht die Syntaxfolgendermaßen aus:
root@master # salt target example.module
Tipp: Nur im Ceph ClusterWenn alle Salt Minions in Ihrer Umgebung zu Ihrem Ceph Cluster gehören, können Sietarget problemlos durch "*" ersetzen, um alle registrierten Minions einzubeziehen.
Gleichen Sie alle Minions in der Domäne "example.net" ab (unter der Annahme, dass alle Minion-Namen mit den "vollständigen" Hostnamen identisch sind):
root@master # salt '*.example.net' test.ping
Gleichen Sie die "web1"- bis "web5"-Minions ab:
root@master # salt 'web[1-5]' test.ping
Gleichen Sie sowohl die "web1-prod"- als auch die "web1-devel"-Minions mit einem regulärenAusdruck ab.
root@master # salt -E 'web1-(prod|devel)' test.ping
Gleichen Sie eine einfache Liste von Minions ab:
root@master # salt -L 'web1,web2,web3' test.ping
32 Adressieren der Minions SES 6
Gleichen Sie alle Minions im Cluster ab:
root@master # salt '*' test.ping
5.2.2.2 Adressieren mithilfe eines DeepSea Grains
In einer heterogenen, mit Salt verwalteten Umgebung, in der SUSE Enterprise Storage 6 aufeiner Untergruppe von Knoten neben anderen Cluster-Lösungen installiert ist, müssen Sie dierelevanten Minions mithilfe eines „deepsea“ Grains markieren, bevor Sie die DeepSea-Phase 0ausführen. Auf diese Weise werden DeepSea Minions leicht in Umgebungen adressiert, in denender Abgleich anhand des Minion-Namens problematisch ist.
Führen Sie zum Anwenden des „deepsea“ Grain auf eine Gruppe von Minions folgendesKommando aus:
root@master # salt target grains.append deepsea default
Führen Sie zum Entfernen des „deepsea“ Grain von einer Gruppe von Minions folgendesKommando aus:
root@master # salt target grains.delval deepsea destructive=True
Nach Anwenden des „deepsea“ Grain auf die relevanten Minions adressieren Sie diese wie folgt:
root@master # salt -G 'deepsea:*' test.ping
Das folgende Kommando funktioniert gleichermaßen:
root@master # salt -C 'G@deepsea:*' test.ping
5.2.2.3 Festlegen der Option deepsea_minions
Für die DeepSea-Bereitstellungen muss das Ziel der Option deepsea_minions festgelegtwerden. DeepSea gibt den Minions während der Ausführung der Phasen darüber Anweisungen(weitere Informationen hierzu nden Sie in der Beschreibung von DeepSea-Phasen).
Bearbeiten Sie zum Festlegen oder Ändern der Option deepsea_minions die Datei /srv/pillar/ceph/deepsea_minions.sls auf dem Salt Master und fügen Sie die folgende Zeilehinzu oder ersetzen Sie sie:
deepsea_minions: target
33 Adressieren der Minions SES 6
Tipp: deepsea_minions TargetAls target für die Option deepsea_minions können Sie eine der beidenAdressierungsmethoden anwenden: Abgleichen des Minion-Namens und Adressieren mithilfe
eines DeepSea Grains.
Gleichen Sie alle Salt Minions im Cluster ab:
deepsea_minions: '*'
Gleichen Sie alle Minions mit „deepsea“ Grain ab:
deepsea_minions: 'G@deepsea:*'
5.2.2.4 Weiterführende Informationen
Über die Salt-Infrastruktur können Sie anspruchsvollere Methoden zur Adressierung vonMinions anwenden. Auf der Handbuchseite „deepsea-minions“ nden Sie außerdem weitereInformationen zur DeepSea-Adressierung ( man 7 deepsea_minions ).
5.3 Cluster-BereitstellungDer Cluster-Bereitstellungsprozess besteht aus mehreren Phasen. Zunächst müssen Sie alleNodes des Clusters durch Kongurieren von Salt vorbereiten und dann Ceph bereitstellen undkongurieren.
Tipp: Bereitstellen von Monitor Nodes ohne OSD-Profile zudefinierenWenn Sie die Denition der OSD-Speicherrollen gemäß Abschnitt 5.5.1.2, „Rollenzuweisung“
überspringen und die Monitor Nodes vorher bereitstellen müssen, können Sie dazu dieVariable DEV_ENV festlegen.
Dies ermöglicht die Bereitstellung von Monitors, auch wenn das Verzeichnis role-storage/ nicht vorhanden ist, sowie die Bereitstellung eines Ceph Clusters mitmindestens einer Speicher-, Monitor- und Manager-Rolle.
34 Cluster-Bereitstellung SES 6
Zum Festlegen der Umgebungsvariable aktivieren Sie diese entweder global, indem Siesie in Datei /srv/pillar/ceph/stack/global.yml festlegen, oder sie legen sie nur fürdie aktuelle Shell-Sitzung fest:
root@master # export DEV_ENV=true
Als Beispiel kann /srv/pillar/ceph/stack/global.yml mit dem folgenden Inhalterstellt werden:
DEV_ENV: True
Das folgende Verfahren beschreibt die Cluster-Vorbereitung im Detail.
1. Installieren und registrieren Sie SUSE Linux Enterprise Server 15 SP1 zusammen mit derSUSE Enterprise Storage 6-Erweiterung auf jedem Node des Clusters.
2. Verizieren Sie, dass die entsprechenden Produkte installiert und registriert sind. ListenSie dazu die bestehenden Software-Repositorys auf. Führen Sie zypper lr -E aus undvergleichen Sie die Ausgabe mit folgender Liste:
SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates
3. Kongurieren Sie Netzwerkeinstellungen einschließlich der ordnungsgemäßen DNS-Namensauösung auf jedem Node. Der Salt Master und alle Salt Minions müssen sichgegenseitig anhand ihrer Hostnamen auösen. Weitere Informationen zum Konguriereneines Netzwerks nden Sie unter https://www.suse.com/documentation/sles-15/
book_sle_admin/data/sec_network_yast.html . Weitere Informationen zum Konguriereneines DNS Servers nden Sie unter https://www.suse.com/documentation/sles-15/
book_sle_admin/data/cha_dns.html .
35 Cluster-Bereitstellung SES 6
4. Wählen Sie mindestens einen Zeitserver/Pool aus und synchronisieren Sie die lokale Zeitdamit. Prüfen Sie bei jedem Starten des Systems, ob der Zeitsynchronisierungsserviceaktiviert ist. Mit dem Kommando yast ntp-client in einem Paket yast2-ntp-clientkönnen Sie die Zeitsynchronisierung kongurieren.
TippVirtuelle Maschinen sind keine zuverlässigen NTP-Quellen.
Weitere Informationen zum Einrichten von NTP nden Sie unter https://www.suse.com/
documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html .
5. Installieren Sie die Pakete salt-master und salt-minion im Salt Master Node:
root@master # zypper in salt-master salt-minion
Überprüfen Sie, ob der salt-master Service aktiviert und gestartet wurde und aktivierenund starten Sie ihn gegebenenfalls:
root@master # systemctl enable salt-master.serviceroot@master # systemctl start salt-master.service
6. Falls Sie beabsichtigen, eine Firewall zu verwenden, verizieren Sie, dass im Salt MasterNode die Ports 4505 und 4506 für alle Salt Minion Nodes oen sind. Wenn die Portsgeschlossen sind, können Sie diese mit dem Kommando yast2 firewall önen, indemSie den SaltStack Service zulassen.
Warnung: DeepSea-Phasen werden bei aktiver Firewallnicht durchgeführtDie DeepSea-Phasen zur Bereitstellung werden nicht ausgeführt, wenn die Firewallaktiv ist (und sogar konguriert). Um die Phasen korrekt abzuschließen, müssenSie entweder die Firewall durch Ausführen von
root # systemctl stop firewalld.service
36 Cluster-Bereitstellung SES 6
ausschalten oder die Option FAIL_ON_WARNING in /srv/pillar/ceph/stack/global.yml auf „False“ festlegen:
FAIL_ON_WARNING: False
7. Installieren Sie das Paket salt-minion in allen Minion Nodes.
root@minion > zypper in salt-minion
Vergewissern Sie sich, dass der vollqualizierte Domänenname eines Nodes von allenanderen Nodes zur IP-Adresse des öentlichen Netzwerks aufgelöst werden kann.
8. Kongurieren Sie alle Minions (einschließlich des Master Minion) zur Herstellung einerVerbindung zum Master. Wenn Ihr Salt Master mit dem Hostnamen salt nicht erreichbarist, 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 Kongurationsdateien Änderungen vorgenommenhaben, starten Sie den Salt Service auf allen Salt Minions neu:
root@minion > systemctl restart salt-minion.service
9. Überprüfen Sie, ob der salt-minion Service in allen Nodes aktiviert und gestartet wurde.Aktivieren und starten Sie ihn, falls erforderlich:
root # systemctl enable salt-minion.serviceroot # systemctl start salt-minion.service
10. Verizieren Sie den Fingerabdruck der einzelnen Salt Minions und akzeptieren Sie alleSalt-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 eine Salt Master-Konguration umfasst und ob der Minion mitdem Salt Master kommunizieren kann.
37 Cluster-Bereitstellung SES 6
Zeigen Sie den Fingerabdruck der einzelnen Minions an:
root@master # salt-call --local key.fingerlocal: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 dieFingerabdrü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-all
11. Verizieren Sie, dass die Schlüssel akzeptiert wurden:
root@master # salt-key --list-all
12. Löschen Sie alle Datenträger vor der Bereitstellung von SUSE Enterprise Storage 6 manuell.Denken Sie daran, „X“ durch den korrekten Festplattenbuchstaben zu ersetzen:
a. Stoppen Sie alle Prozesse, die die spezische Festplatte verwenden.
b. Verizieren Sie, ob eine Partition auf der Festplatte eingehängt ist, und hängen Siesie gegebenenfalls aus.
c. Wenn die Festplatte von LVM verwaltet wird, deaktivieren und löschen Siedie gesamte LVM-Infrastruktur. Weitere Informationen nden Sie in https://
www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html .
d. Wenn die Festplatte Teil von MD RAID ist, deaktivieren Sie RAID.Weitere Informationen nden Sie in https://www.suse.com/documentation/sles-15/
book_storage/data/part_software_raid.html .
38 Cluster-Bereitstellung SES 6
e. Tipp: Server neustartenWenn Sie in den folgenden Schritten Fehlermeldungen erhalten wie „Partitionwird verwendet“ oder „Kernel kann nicht mit der neuen Partitionstabelleaktualisiert werden“, dann starten Sie den Server neu.
Löschen Sie den Anfang der einzelnen Partitionen (als root ):
for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone
f. Löschen Sie den Anfang des Laufwerks:
root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
g. Löschen Sie das Ende des Laufwerks:
root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \ seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
h. Prüfen Sie mit folgendem Kommando, ob das Laufwerk leer ist (keine GPT-Strukturenenthält):
root # parted -s /dev/sdX print free
oder
root # dd if=/dev/sdX bs=512 count=34 | hexdump -Croot # dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
13. Optional: Wenn Sie die Einstellungen des Clusters vorkongurieren müssen, bevordas Paket deepsea installiert wurde, erstellen Sie /srv/pillar/ceph/stack/
ceph/cluster.yml manuell und legen Sie die Optionen cluster_network: undpublic_network: fest. Die Datei wird nach der Installation von deepsea nichtüberschrieben.
39 Cluster-Bereitstellung SES 6
Tipp: Aktivieren von IPv6Wenn Sie die IPv6-Netzwerkadressierung aktivieren müssen, beachten SieAbschnitt 7.2.1, „Aktivieren von IPv6 für die Ceph Cluster-Implementierung“
14. Installieren Sie DeepSea im Salt Master Node:
root@master # zypper in deepsea
15. Der Wert für den Parameter master_minionwird aus der Datei /etc/salt/minion_idauf dem Salt Master abgeleitet. Wenn Sie den ermittelten Wert überschreiben müssen,bearbeiten Sie die Datei /srv/pillar/ceph/stack/global.yml und legen Sie einenrelevanten Wert fest:
master_minion: MASTER_MINION_NAME
Wenn der Salt Master über mehrere Hostnamen erreichbar ist, verwenden Sie denSalt Minion-Namen für den Speicher-Cluster, der vom Kommando salt-key -Lzurückgegeben wurde. Wenn Sie den Standard-Hostnamen für Ihren Salt Master (salt) inder ses-Domäne verwendet haben, dann sieht die Datei folgendermaßen aus:
master_minion: salt.ses
Nun stellen Sie Ceph bereit und kongurieren es. Alle Schritte sind obligatorisch, falls nichtanders angegeben.
Anmerkung: Salt-KommandokonventionenSie haben zwei Möglichkeiten zum Ausführen von salt-run state.orch : zum einen mit„stage. STAGE_NUMBER “, zum anderen mit dem Namen der Phase. Beide Schreibweisenhaben dieselbe Wirkung. Es liegt ganz bei Ihnen, welches Kommando Sie verwenden.
PROZEDUR 5.1: AUSFÜHREN VON BEREITSTELLUNGSPHASEN
1. Prüfen Sie, ob die Salt Minions im Ceph Cluster ordnungsgemäß über dieOption deepsea_minions in /srv/pillar/ceph/deepsea_minions.sls adressiertsind. Weitere Informationen nden Sie unter Abschnitt 5.2.2.3, „Festlegen der Option
deepsea_minions“.
40 Cluster-Bereitstellung SES 6
2. Standardmäßig stellt DeepSea die Ceph Cluster mit aktiven abgestimmten Prolen aufCeph Monitor, Ceph Manager und Ceph OSD Nodes bereit. In einigen Fällen muss dieBereitstellung ohne abgestimmte Prole durchgeführt werden. Tragen Sie hierzu diefolgenden Zeilen in /srv/pillar/ceph/stack/global.yml ein, bevor Sie die DeepSea-Phasen ausführen:
alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off
3. Optional: Erstellen Sie Btrfs Sub-Volumes für /var/lib/ceph/ . Dieser Schritt mussvor der DeepSea-Phase 0 ausgeführt werden. Weitere Informationen zum Migrierenvorhandener Verzeichnisse sowie allgemeine weitere Informationen nden Sie in Buch
„Verwaltungshandbuch”, Kapitel 25 „Hinweise und Tipps“, Abschnitt 25.6 „Btrfs-Subvolume für /
var/lib/ceph auf Ceph Monitor Nodes“.Führen Sie folgende Kommandos für jeden Salt Minion aus:
root@master # salt 'MONITOR_NODES' saltutil.sync_allroot@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
AnmerkungMit dem Kommando „Ceph.subvolume“ wird /var/lib/ceph als ein Btrfs-Subvolume für @/var/lib/ceph erstellt.
Das neue Subvolume wird nun eingehängt und /etc/fstab wird aktualisiert.
4. Bereiten Sie Ihren Cluster vor. Weitere Informationen nden Sie in Beschreibung von
DeepSea-Phasen.
root@master # salt-run state.orch ceph.stage.0
oder
root@master # salt-run state.orch ceph.stage.prep
41 Cluster-Bereitstellung SES 6
Anmerkung: Phasen mit DeepSea CLI ausführen oderüberwachenMit DeepSea CLI können Sie den Fortschritt der Phasenausführung in Echtzeitverfolgen. Führen Sie dazu DeepSea CLI im Überwachungsmodus aus oder führenSie die Phase direkt über DeepSea CLI aus. Weitere Informationen nden Sie imAbschnitt 5.4, „DeepSea CLI“.
5. In der Ermittlungsphase werden Daten von allen Minions erfasst undKongurationsfragmente erstellt, die im Verzeichnis /srv/pillar/ceph/proposals
gespeichert sind. Die Daten werden im YAML-Format in SLS- oder YML-Dateiengespeichert.Mit folgendem Kommando lösen Sie die Ermittlungsphase aus:
root@master # salt-run state.orch ceph.stage.1
oder
root@master # salt-run state.orch ceph.stage.discovery
6. Erstellen Sie nach erfolgreicher Ausführung des vorigen Kommandos eine policy.cfg -Datei in /srv/pillar/ceph/proposals . Weitere Informationen nden Sie imAbschnitt 5.5.1, „Die Datei policy.cfg“.
TippWenn Sie die Netzwerkeinstellungen des Clusters ändern müssen, bearbeiten Sie dieDatei /srv/pillar/ceph/stack/ceph/cluster.yml und passen Sie die Zeilenan, die mit cluster_network: und public_network: beginnen.
7. In der Kongurationsphase wird die policy.cfg -Datei analysiert und die enthaltenenDateien in der nalen Form zusammengeführt. Auf Cluster und Rolle bezogene Inhaltewerden in /srv/pillar/ceph/cluster hinzugefügt, Ceph-spezische Inhalte dagegenin /srv/pillar/ceph/stack/default .Führen Sie folgendes Kommando aus, um die Kongurationsphase auszulösen:
root@master # salt-run state.orch ceph.stage.2
42 Cluster-Bereitstellung SES 6
oder
root@master # salt-run state.orch ceph.stage.configure
Der Kongurationsschritt kann einige Sekunden dauern. Nach Ausführung desKommandos sehen Sie die Pillar-Daten für die angegebenen Minions (beispielsweise mitNamen ceph_minion1 , ceph_minion2 usw.), indem Sie folgendes Kommando ausführen:
root@master # salt 'ceph_minion*' pillar.items
Tipp: Bearbeiten des OSD-LayoutsSoll das standardmäßige OSD-Layout bearbeitet und die DriveGroups-Kongurationgeönet werden, befolgen Sie die Anweisungen in Abschnitt 5.5.2, „DriveGroups“.
Anmerkung: Überschreiben von StandardwertenSobald das Kommando ausgeführt ist, sehen Sie die Standardkonguration undkönnen sie entsprechend Ihrer Anforderungen ändern. Weitere Informationennden Sie im Kapitel 7, Anpassen der Standardkonfiguration.
8. Nun führen Sie die Bereitstellungsphase aus. In dieser Phase wird der Pillar validiert unddie Ceph Monitor und Ceph OSD Daemons werden gestartet:
root@master # salt-run state.orch ceph.stage.3
oder
root@master # salt-run state.orch ceph.stage.deploy
Die Ausführung des Kommandos kann einige Minuten dauern. Wenn es nicht ausgeführtwird, müssen Sie das Problem beheben und die vorigen Phasen erneut ausführen. FührenSie nach erfolgreicher Ausführung des Kommandos das folgende Kommando aus, um denStatus zu prüfen:
cephadm@adm > ceph -s
43 Cluster-Bereitstellung SES 6
9. Die letzte Phase der Ceph Cluster-Bereitstellung ist die Services-Phase. Hier instanziierenSie die gewünschten Services, die aktuell unterstützt werden: iSCSI Gateway, CephFS,Object Gateway, und NFS Ganesha. In dieser Phase werden die erforderlichen Pools,die autorisierenden Schlüsselbunde und Start-Services erstellt. Führen Sie folgendesKommando aus, um die Phase zu starten:
root@master # salt-run state.orch ceph.stage.4
oder
root@master # salt-run state.orch ceph.stage.services
Je nach Einrichtung kann die Ausführung des Kommandos einige Minuten dauern.
10. Bevor Sie den Vorgang fortsetzen, wird dringend empfohlen, das Ceph-Telemetriemodulzu aktivieren. Weitere Informationen und Anweisungen nden Sie in Buch
„Verwaltungshandbuch”, Kapitel 10 „Ceph Manager-Module“, Abschnitt 10.2 „Telemetriemodul“.
5.4 DeepSea CLIDeepSea stellt auch eine Kommandozeilenschnittstelle (Command Line Interface, CLI) zurVerfügung, mit dem Benutzer Phasen überwachen oder ausführen, während sie denAusführungsfortschritt in Echtzeit visualisieren. Prüfen Sie, ob das Paket deepsea-cli
installiert ist, bevor Sie die ausführbare Datei deepsea ausführen.
Zwei Modi werden zur Visualisierung des Ausführungsfortschritts einer Phase unterstützt:
DEEPSEA CLI-MODI
Überwachungsmodus: visualisiert den Ausführungsfortschritt einer DeepSea-Phase,die vom salt-run -Kommando ausgelöst wurde, das wiederum in einer anderenTerminalsitzung ausgestellt wurde.
Stand-Alone-Modus: führt eine DeepSea-Phase aus bei gleichzeitiger Echtzeit-Visualisierung der Komponentenschritte während ihrer Ausführung.
Wichtig: DeepSea CLI-KommandosDie DeepSea CLI-Kommandos können nur auf dem Salt Master Node ausgeführt werdenund es sind root -Berechtigungen dazu erforderlich.
44 DeepSea CLI SES 6
5.4.1 DeepSea CLI: Überwachungsmodus
Die Fortschrittsüberwachung bietet eine detaillierte Echtzeit-Visualisierung der Vorgängebei der Ausführung von Phasen mit salt-run state.orch -Kommandos in anderenTerminalsitzungen.
Tipp: Starten der Überwachung in einer neuen TerminalsitzungSie müssen die Überwachung in einem neuen Terminalfenster starten, bevor Sie einsalt-run state.orch -Kommando ausführen, damit die Überwachung den Start derPhasenausführung erkennt.
Wenn Sie die Überwachung nach Ausgabe des Kommandos salt-run state.orch starten,wird kein Ausführungsfortschritt angezeigt.
Sie können den Überwachungsmodus durch Ausführen des folgenden Kommandos starten:
root@master # deepsea monitor
Weitere Informationen zu den verfügbaren Kommandozeilenoptionen des deepsea monitor -Kommandos nden Sie auf der entsprechenden Handbuchseite:
root@master # man deepsea-monitor
5.4.2 DeepSea CLI: Stand-Alone-Modus
Im Stand-Alone-Modus wird über DeepSea CLI eine DeepSea-Phase ausgeführt und dieAusführung wird in Echtzeit angezeigt.
Das Kommando zur Ausführung einer DeepSea-Phase an der DeepSea CLI weist folgende Formauf:
root@master # deepsea stage run stage-name
stage-name stellt dabei die Methode dar, wie die Zustandsdateien der Salt-Orchestrierungreferenziert werden. Beispiel: Phase Ermittlung, die dem Verzeichnis in Pfad /srv/salt/ceph/stage/deploy entspricht, wird als ceph.stage.deploy referenziert.
Dieses Kommando stellt eine Alternative zu den Salt-basierten Kommandos zur Ausführung vonDeepSea-Phasen (oder von Zustandsdateien der DeepSea-Orchestrierung) dar.
Das Kommando deepsea stage run ceph.stage.0 entspricht salt-run state.orchceph.stage.0 .
45 DeepSea CLI: Überwachungsmodus SES 6
Weitere Informationen zu den verfügbaren Kommandozeilenoptionen, die vom deepsea stagerun -Kommando akzeptiert werden, nden Sie auf der entsprechenden Handbuchseite:
root@master # man deepsea-stage run
Die folgende Abbildung zeigt ein Beispiel der Ausgabe der DeepSea CLI bei Ausführung vonPhase 2:
ABBILDUNG 5.1: AUSGABE DES FORTSCHRITTS DER PHASENAUSFÜHRUNG AN DER DEEPSEA CLI
5.4.2.1 DeepSea CLI-Alias für stage run
Für fortgeschrittene Benutzer von Salt unterstützen wir einen Alias für die Ausführungeiner DeepSea-Phase. Dieser betrachtet das Salt-Kommando, das zur Ausführung einer Phaseverwendet wird (beispielsweise salt-run state.orch stage-name ) als Kommando derDeepSea CLI.
46 DeepSea CLI: Stand-Alone-Modus SES 6
Beispiel:
root@master # deepsea salt-run state.orch stage-name
5.5 Konfiguration und Anpassung
5.5.1 Die Datei policy.cfg
Mit der Kongurationsdatei /srv/pillar/ceph/proposals/policy.cfg werden Rolleneinzelner Cluster Nodes ermittelt. Beispiel: Welche Knoten fungieren als Ceph OSDsoder Ceph Monitors? Bearbeiten Sie policy.cfg , um die gewünschte Cluster-Einrichtungwiderzuspiegeln. Die Reihenfolge der Abschnitte ist beliebig, doch der Inhalt der enthaltenenZeilen überschreibt die passenden Schlüssel vom Inhalt der vorigen Zeilen.
Tipp: Beispiele für policy.cfgSie nden verschiedene Beispiele von fertiggestellten Richtliniendateien im Verzeichnis/usr/share/doc/packages/deepsea/examples/ .
5.5.1.1 Cluster-Zuweisung
Im Abschnitt cluster wählen Sie Minions für Ihren Cluster aus. Sie können alle Minionsauswählen oder Minions auf eine Blacklist oder Whitelist setzen. Beispiele für einen Clusternamens ceph folgen.
Fügen Sie die folgenden Zeilen hinzu, um alle Minions einzubeziehen:
cluster-ceph/cluster/*.sls
So setzen Sie einen bestimmten Minion auf eine weiße Liste:
cluster-ceph/cluster/abc.domain.sls
oder eine Gruppe von Minions, mit Shell Glob-Abgleich:
cluster-ceph/cluster/mon*.sls
47 Konfiguration und Anpassung SES 6
Um Minions auf eine schwarze Liste zu setzen, legen Sie sie als unassigned (nicht zugewiesen)fest:
cluster-unassigned/cluster/client*.sls
5.5.1.2 Rollenzuweisung
In diesem Abschnitt erhalten Sie detaillierte Informationen zur Zuweisung von „Rollen“ zu IhrenCluster Nodes. Eine „Rolle“ bezeichnet in diesem Kontext einen Service, den Sie zur Ausführungim Node benötigen, z. B. Ceph Monitor, Object Gateway oder iSCSI-Gateway. Keine Rolle wirdautomatisch zugewiesen. Es werden nur Rollen bereitgestellt, die zu policy.cfg hinzugefügtwurden.
Die Zuweisung erfolgt nach dem folgenden Muster:
role-ROLE_NAME/PATH/FILES_TO_INCLUDE
Die einzelnen Elemente haben die folgende Bedeutung und Werte:
ROLE_NAME bezeichnet eines der folgenden Elemente: „master“, „admin“, „mon“, „mgr“,„storage“, „mds“, „igw“, „rgw“, „ganesha“, „grafana“ oder „prometheus“.
PATH ist ein relativer Verzeichnispfad zu SLS- oder YML-Dateien. Bei SLS-Dateien lauteter normalerweise cluster , YML-Dateien benden sich unter stack/default/ceph/minions .
FILES_TO_INCLUDE bezeichnet die Salt-Zustandsdateien oder die YAML-Kongurationsdateien. Sie bestehen normalerweise aus den Hostnamen der Salt Minions,beispielsweise ses5min2.yml . Ein weiterer spezischen Abgleich kann über ShellGlobbing erfolgen.
48 Die Datei policy.cfg SES 6
Nachfolgend sehen Sie ein Beispiel für jede Rolle:
master - der Node hat Admin-Schlüsselbunde zu allen Ceph Clustern. Aktuell wird nur eineinzelner Ceph Cluster unterstützt. Da die master-Rolle obligatorisch ist, fügen Sie immereine ähnliche Zeile wie die folgende hinzu:
role-master/cluster/master*.sls
admin - der Minion verfügt über einen Admin-Schlüsselbund. Sie denieren die Rolle wiefolgt:
role-admin/cluster/abc*.sls
mon – der Minion stellt den Überwachungs-Service für den Ceph Cluster zur Verfügung.Diese Rolle benötigt Adressen der zugewiesenen Minions. Ab SUSE Enterprise Storage 5werden die öentlichen Adressen dynamisch berechnet und sind im Salt Pillar nicht mehrerforderlich.
role-mon/cluster/mon*.sls
Im Beispiel wird die Überwachungsrolle einer Gruppe von Minions zugewiesen.
mgr - der Ceph Manager Daemon, der alle Zustandsinformationen des gesamten Clusterserfasst. Stellen Sie ihn auf allen Minions bereit, auf denen Sie die Ceph Monitor-Rollebereitstellen möchten.
role-mgr/cluster/mgr*.sls
storage – mit dieser Rolle geben Sie bestimmte Speicher-Nodes an.
role-storage/cluster/data*.sls
mds - der Minion stellt den Metadaten-Service zur Unterstützung von CephFS bereit.
role-mds/cluster/mds*.sls
igw - der Minion fungiert als iSCSI Gateway. Diese Rolle benötigt Adressen derzugewiesenen Minions. Daher müssen Sie auch die Dateien aus dem stack -Verzeichnishinzufügen:
role-igw/cluster/*.sls
rgw - der Minion fungiert als Object Gateway.
49 Die Datei policy.cfg SES 6
role-rgw/cluster/rgw*.sls
ganesha - der Minion fungiert als NFS Ganesha Server. Für die „ganesha“-Rolle ist eine„rgw“- oder „mds“-Rolle im Cluster erforderlich. Andernfalls wird die Validierung in Phase3 nicht durchgeführt.
role-ganesha/cluster/ganesha*.sls
Für die erfolgreiche Installation von NFS Ganesha ist eine weitere Kongurationerforderlich. Wenn Sie NFS Ganesha verwenden möchten, lesen Sie Kapitel 12, Installation
von NFS Ganesha, bevor Sie Phase 2 und 4 ausführen. Es ist jedoch möglich, NFS Ganeshaspäter zu installieren.In einigen Fällen kann es nützlich sein, benutzerdenierte Rollen für NFS Ganesha Nodeszu denieren. Weitere Informationen nden Sie in Buch „Verwaltungshandbuch”, Kapitel
21 „NFS Ganesha: Exportieren von Ceph-Daten über NFS“, Abschnitt 21.3 „Benutzerdefinierte NFS
Ganesha-Rollen“.
grafana, prometheus – dieser Knoten fügt Grafana-Diagramme auf der Grundlage derPrometheus-Warnmeldungen in das Ceph Dashboard ein. Eine ausführliche Beschreibungnden Sie in Buch „Verwaltungshandbuch”, Kapitel 22 „Ceph Dashboard“.
role-grafana/cluster/grafana*.sls
role-prometheus/cluster/prometheus*.sls
Anmerkung: Mehrere Rollen von Cluster NodesSie können einem einzelnen Node verschiedene Rollen zuweisen. Beispielsweise könnenSie die „mds“-Rollen zu Monitor Nodes zuweisen:
role-mds/cluster/mon[1,2]*.sls
50 Die Datei policy.cfg SES 6
5.5.1.3 Allgemeine Konfiguration
Im Abschnitt zur allgemeinen Konguration sind Kongurationsdateien enthalten, die in derPhase der Ermittlung (Phase 1) generiert wurden. In diesen Kongurationsdateien werdenParameter wie fsid oder public_network gespeichert. Fügen Sie die folgenden Zeilen hinzu,um die erforderliche allgemeine Ceph-Konguration einzubeziehen:
config/stack/default/global.ymlconfig/stack/default/ceph/cluster.yml
5.5.1.4 Filtern von Elementen
Manchmal ist es nicht praktisch, alle Dateien eines vorliegenden Verzeichnisses zum *.slsGlobbing hinzuzufügen. Das Dateianalyseprogramm policy.cfg versteht die folgenden Filter:
Warnung: Erweiterte MethodenIn diesem Abschnitt werden Filtermethoden für fortgeschrittene Benutzer beschrieben.Wenn die Filter nicht korrekt verwendet werden, können sie Probleme verursachen,beispielsweise wenn sich die Node-Nummerierung ändert.
slice=[start:end]
Mit dem Slice-Filter beziehen Sie nur die Elemente start bis end-1 ein. Beachten Sie, dassdie im vorliegenden Verzeichnis vorhandenen Elemente alphanumerisch sortiert sind. Diefolgende Zeile enthält die dritte bis fünfzigste Datei des Unterverzeichnisses role-mon/cluster/ :
role-mon/cluster/*.sls slice[3:6]
re=regexp
Mit dem regex Filter werden nur Elemente einbezogen, die den vorliegenden regulärenAusdrücken entsprechen. Beispiel:
role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$
5.5.1.5 Beispiel einer policy.cfg-Datei
Nachfolgend sehen Sie ein Beispiel einer einfachen policy.cfg -Datei:
## Cluster Assignment
51 Die Datei policy.cfg SES 6
cluster-ceph/cluster/*.sls 1
## Roles# ADMINrole-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3
# MONrole-mon/cluster/ses-example-[123].sls 4
# MGRrole-mgr/cluster/ses-example-[123].sls 5
# STORAGErole-storage/cluster/ses-example-[5,6,7,8].sls 6
# MDSrole-mds/cluster/ses-example-4.sls 7
# IGWrole-igw/cluster/ses-example-4.sls 8
# RGWrole-rgw/cluster/ses-example-4.sls 9
# COMMONconfig/stack/default/global.yml 10
config/stack/default/ceph/cluster.yml 11
1 Gibt an, dass alle Minions im Ceph Cluster enthalten sind. Wenn Sie über Minions verfügen,die nicht im Ceph Cluster enthalten sein sollen, verwenden Sie:
cluster-unassigned/cluster/*.slscluster-ceph/cluster/ses-example-*.sls
Die erste Zeile kennzeichnet alle Minions als nicht zugewiesen. Die zweite Zeileüberschreibt Minions, die "ses-example-*.sls" entsprechen, und weist sie dem Ceph Clusterzu.
2 Der Minion namens „examplesesadmin“ verfügt über die „master“-Rolle. Dies bedeutetübrigens, dass er Admin-Schlüssel für den Cluster erhält.
3 Alle Minions, die "sesclient*" entsprechen, erhalten ebenfalls Admin-Schlüssel.
4 Alle Minions, die "ses-example-[123]" entsprechen (vermutlich drei Minions: ses-example-1, ses-example-2 und ses-example-3), werden als MON Nodes eingerichtet.
52 Die Datei policy.cfg SES 6
5 Alle Minions, die "ses-example-[123]" entsprechen (alle MON Nodes in diesem Beispiel),werden als MGR-Nodes eingerichtet.
6 Alle Minions, die „ses-example-[5,6,7,8]“ entsprechen, werden als Speicher-Nodeseingerichtet.
7 Minion "ses-example-4" erhält die MDS-Rolle.
8 Minion "ses-example-4" erhält die IGW-Rolle.
9 Minion "ses-example-4" erhält die RGW-Rolle.
10 Bedeutet, dass wir die Standardwerte für allgemeine Kongurationsparameter wie fsidund public_network akzeptieren.
11 Bedeutet, dass wir die Standardwerte für allgemeine Kongurationsparameter wie fsidund public_network akzeptieren.
5.5.2 DriveGroups
DriveGroups bestimmen das Layout der OSDs im Ceph Cluster. Sie sind in einer einzelnen Dateideniert ( /srv/salt/ceph/configuration/files/drive_groups.yml ).
Ein Administrator muss manuell eine Gruppe von OSDs erstellen, die zusammenhängen (Hybrid-OSDs, die auf Solid-State-Laufwerken und rotierenden Datenträgern implementiert sind) oderdieselben Implementierungsoptionen aufweisen (identisch, z. B. gleicher Objektspeicher, gleicheVerschlüsselungsoption, Stand-Alone-OSDs). Damit die Geräte nicht explizit aufgelistet werdenmüssen, werden sie in den DriveGroups anhand einer Liste von Filterelementen geltert, dieeinigen wenigen ausgewählten Feldern in den ceph-volume -Bestandsberichten entsprechen. Imeinfachsten Fall ist dies die „rotierende“ Flagge (alle Solid-State-Laufwerke müssen db_devicessein, alle rotierenden Laufwerke dagegen Datengeräte), alternativ und etwas aufwendiger sindz. B. „Modell“-Zeichenketten oder Größen. Der Code in DeepSea wandelt diese DriveGroups inGerätelisten um, die dann vom Benutzer geprüft werden können.
Dieses einfache Verfahren veranschaulicht den grundlegenden Workow beim Kongurierender DriveGroups:
1. Prüfen Sie die Eigenschaften Ihrer Datenträger, die vom Kommando ceph-volumezurückgegeben wurden. DriveGroups akzeptieren ausschließlich folgende Eigenschaften:
root@master # salt-run disks.details
53 DriveGroups SES 6
2. Önen Sie die YAML-Datei /srv/salt/ceph/configuration/files/
drive_groups.yml und passen Sie sie an Ihre Anforderungen an. Weitere Informationennden Sie unter Abschnitt 5.5.2.1, „Spezifikation“. Denken Sie daran, Leerzeichen anstelle vonTabulatoren anzugeben. Ausführliche Beispiele nden Sie in Abschnitt 5.5.2.4, „Beispiele“
Das folgende Beispiel umfasst alle Datenträger, die in Ceph als OSDs verfügbar sind:
default_drive_group_name: target: '*' data_devices: all: true
3. Prüfen Sie die neuen Layouts:
root@master # salt-run disks.list
Dieses Ausführungsprogramm gibt eine Struktur der passenden Datenträger auf derGrundlage Ihrer DriveGroups zurück. Wenn Sie mit dem Ergebnis nicht zufrieden sind,wiederholen Sie den vorherigen Schritt.
Tipp: Ausführlicher BerichtNeben dem Ausführungsprogramm disks.list steht das Ausführungsprogrammdisks.report bereit, das einen detaillierten Bericht über die Abläufe beimnächsten Aufrufen der DeepSea-Phase 3 zurückgibt.
root@master # salt-run disks.report
4. Imitieren Sie die OSDs. Beim nächsten Aufrufen der DeepSea-Phase 3 werden die OSD-Datenträger gemäß Ihrer DriveGroups-Spezikation implementiert.
5.5.2.1 Spezifikation
/srv/salt/ceph/configuration/files/drive_groups.yml akzeptiert folgende Optionen:
drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION db_devices: drive_spec: DEVICE_SPECIFICATION
54 DriveGroups SES 6
wal_devices: drive_spec: DEVICE_SPECIFICATION block_wal_size: '5G' # (optional, unit suffixes permitted) block_db_size: '5G' # (optional, unit suffixes permitted) osds_per_device: 1 # number of osd daemons per device format: # 'bluestore' or 'filestore' (defaults to 'bluestore') encryption: # 'True' or 'False' (defaults to 'False')
Für FileStore-Einrichtungen kann drive_groups.yml wie folgt aussehen:
drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION journal_devices: drive_spec: DEVICE_SPECIFICATION format: filestore encryption: True
5.5.2.2 Abstimmung von Datenträgergeräten
Sie können die Spezikation mit folgenden Filtern beschreiben:
Nach Datenträgermodell:
model: DISK_MODEL_STRING
Nach Datenträgerhersteller:
vendor: DISK_VENDOR_STRING
Tipp: Hersteller-ZeichenketteGeben Sie DISK_VENDOR_STRING stets in Kleinbuchstaben an.
Angabe, ob ein rotierender oder ein nicht rotierender Datenträger vorliegt. SSDs undNVME-Laufwerke sind keine rotierenden Datenträger.
rotational: 0
Implementieren Sie einen Knoten mit allen verfügbaren Laufwerken für OSDs:
data_devices:
55 DriveGroups SES 6
all: true
Zusätzlich mit Einschränkung der Anzahl passender Datenträger
limit: 10
5.5.2.3 Filtern von Geräten nach Größe
Sie können die Datenträgergeräte nach ihrer Größe ltern – wahlweise nach einer genauenGrößenangabe oder einem Größenbereich. Der Parameter size: akzeptiert Argumente wiefolgt:
„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 5.1: ABSTIMMUNG NACH DATENTRÄGERGRÖßE
drive_group_default: target: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'
Anmerkung: Anführungszeichen erforderlichBeim Begrenzer „:“ müssen Sie die Größe in Anführungszeichen setzen, da das Zeichen„:“ ansonsten als neuer Konguration-Hash interpretiert wird.
Tipp: Abkürzungen für EinheitenAnstelle von (G)igabyte können Sie die Größen auch in (M)egabyte oder (T)erabyteangeben.
5.5.2.4 Beispiele
Dieser Abschnitt enthält Beispiele verschiedener OSD-Einrichtungen.
56 DriveGroups SES 6
BEISPIEL 5.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:
drive_group_default: target: '*' data_devices: model: SSD-123-foo db_devices: model: MC-55-44-XZ
Eine solche Konguration ist unkompliziert und zulässig. Es stellt sich allerdings dasProblem, dass ein Administrator in Zukunft eventuell Datenträger von anderen Herstellerneinfügt, die dann nicht berücksichtigt werden. Zur Verbesserung geben Sie weniger Filterfür die wesentlichen Eigenschaften der Laufwerke an:
drive_group_default: target: '*' 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.
57 DriveGroups SES 6
Wenn Laufwerke mit mehr als 2 TB stets als langsamere Datengeräte eingesetzt werdensollen, können Sie nach Größe ltern:
drive_group_default: target: '*' data_devices: size: '2TB:' db_devices: size: ':2TB'
BEISPIEL 5.3: ERWEITERTE KONFIGURATION
Dieses Beispiel umfasst zwei getrennte Einrichtungen: 20 HDDs sollen gemeinsam 2 SSDsnutzen 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 deniert werden:
drive_group: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ
58 DriveGroups SES 6
drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: vendor: samsung size: 256GB
BEISPIEL 5.4: ERWEITERTE EINRICHTUNG MIT NICHT EINHEITLICHEN KNOTEN
In den vorherigen Beispielen wurde angenommen, dass alle Knoten dieselben Laufwerkeumfassen. 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
59 DriveGroups SES 6
Mit dem „target“-Schlüssel im Layout können Sie bestimmte Knoten adressieren. Die Salt-Zielnotation trägt zur Vereinfachung bei:
drive_group_node_one_to_five: target: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0
gefolgt von:
drive_group_the_rest: target: 'node[6-10]' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo
BEISPIEL 5.5: EXPERTENEINRICHTUNG
In allen vorherigen Fällen wird angenommen, dass die WALs und DBs dasselbe Gerätnutzen. 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
60 DriveGroups SES 6
drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo wal_devices: model: NVME-QQQQ-987
BEISPIEL 5.6: KOMPLEXE (UND UNWAHRSCHEINLICHE) EINRICHTUNG
In der folgenden Einrichtung soll Folgendes deniert 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
61 DriveGroups SES 6
Die DriveGroups-Denition lautet:
drive_group_hdd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: NVME-QQQQ-987
drive_group_hdd_ssd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ wal_devices: model: NVME-QQQQ-987
drive_group_ssd_nvme: target: '*' data_devices: model: SSD-123-foo db_devices: model: NVME-QQQQ-987
drive_group_ssd_standalone_encrypted: target: '*' data_devices: model: SSD-123-foo encryption: True
Eine HDD verbleibt, da die Datei von oben nach unten analysiert wird.
5.5.3 Anpassen von ceph.conf mit benutzerdefiniertenEinstellungen
Wenn Sie benutzerdenierte Einstellungen zur Datei ceph.conf hinzufügen müssen, ndenSie die entsprechenden Informationen dazu im Buch „Verwaltungshandbuch”, Kapitel 2 „Cluster-
Verwaltung mit Salt“, Abschnitt 2.13 „Anpassen von ceph.conf mit benutzerdefinierten Einstellungen“.
62 Anpassen von ceph.conf mit benutzerdefinierten Einstellungen SES 6
6 Upgrade von vorigen Versionen
In diesem Kapitel nden Sie die Schritte zum Aufrüsten von SUSE Enterprise Storage 5.5 aufVersion 6. Version 5.5 entspricht im Grunde der Version 5, auf die alle aktuellen Patchesangewendet wurden.
Anmerkung: Keine Unterstützung für das Upgrade ältererVersionenDas Upgrade von SUSE Enterprise Storage-Versionen vor 5.5 wird nicht unterstützt. Siemüssen zunächst auf die aktuelle Version von SUSE Enterprise Storage 5.5 aufrüsten unddann die Schritte in diesem Kapitel ausführen.
6.1 Vor dem Upgrade zu beachtende Punkte
In den Versionshinweisen nden Sie zusätzliche Informationen zu den Änderungen, die seitder vorigen Version von SUSE Enterprise Storage vorgenommen wurden. Informieren Siesich in den Versionshinweisen über Folgendes:
Sind bei der Hardware besondere Überlegungen zu beachten?
Wurden erhebliche Änderungen an den verwendeten Software-Paketenvorgenommen?
Gelten besondere Vorsichtsmaßnahmen für die vorliegende Installation?
In den Versionshinweisen nden Sie auch Informationen, die erst nach der Fertigstellungdes Handbuchs bekannt wurden. Auch bekannte Probleme werden beschrieben.Nach Installation des Pakets release-notes-sesnden Sie die Versionshinweise lokal imVerzeichnis /usr/share/doc/release-notes oder online unter https://www.suse.com/
releasenotes/ .
Falls Sie zuvor Version 4 aufgerüstet haben, prüfen Sie, ob das Upgrade auf Version 5erfolgreich abgeschlossen wurde:
Prüfen Sie, ob folgende Datei vorhanden ist:
/srv/salt/ceph/configuration/files/ceph.conf.import
63 Vor dem Upgrade zu beachtende Punkte SES 6
Die Datei wird beim Importprozess während des Upgrades von SES 4 auf 5 erstellt.Außerdem wird die Option configuration_init: default-import in folgenderDatei festgelegt:
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Wenn configuration_init noch auf default-import eingestellt ist, greift derCluster auf ceph.conf.import als Kongurationsdatei zurück, nicht auf dieStandarddatei ceph.conf von DeepSea, die aus Dateien in folgendem Verzeichniskompiliert wird:
/srv/salt/ceph/configuration/files/ceph.conf.d/
Sie müssen daher ceph.conf.import auf benutzerdenierte Kongurationen prüfenund diese Kongurationen ggf. in eine der Dateien in folgendem Verzeichnisverschieben:
/srv/salt/ceph/configuration/files/ceph.conf.d/
Entfernen Sie anschließend die Zeile configuration_init: default-import aus
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Warnung: Standardmäßige DeepSea-KonfigurationWenn Sie nicht die Konguration aus ceph.conf.import zusammenführenund die Option configuration_init: default-import entfernen, werdenalle standardmäßigen Kongurationseinstellungen von DeepSea (in /srv/salt/ceph/configuration/files/ceph.conf.j2 gespeichert) nicht aufden Cluster angewendet.
Prüfen Sie, ob der Cluster den neuen Bucket-Typ „straw2“ nutzt:
cephadm@adm > ceph osd crush dump | grep straw
Prüfen Sie, ob das Ceph Prol „jewel“ verwendet wird:
cephadm@adm > ceph osd crush dump | grep profile
64 Vor dem Upgrade zu beachtende Punkte SES 6
Werden ältere RBD-Kernel-Clients (vor SUSE Linux Enterprise Server 12 SP3) verwendet,beachten Sie Buch „Verwaltungshandbuch”, Kapitel 12 „RADOS-Blockgerät“, Abschnitt 12.9 „RBD-
Zuordnung mit älteren Kernel-Clients“. Es wird empfohlen, ältere RBD-Kernel-Clients nachMöglichkeit aufzurüsten.
Wenn sich openATTIC auf dem Admin Node bendet, ist es nach dem Aufrüsten desKnotens nicht mehr verfügbar. Das neue Ceph Dashboard ist dann verfügbar, wenn Sie esmit DeepSea implementiert haben.
Das Cluster-Upgrade kann lange dauern, nämlich in etwa so lange, wie es dauert, einUpgrade eines Computers multipliziert mit der Anzahl der Cluster Nodes durchzuführen.
Ein einzelner Knoten kann nicht aufgerüstet werden, wenn darauf noch die vorherigeSUSE Linux Enterprise Server-Version ausgeführt wird, sondern muss mit demInstallationsprogramm der neuen Version neu gestartet werden. Die Services, die dieserKnoten anbietet, stehen daher eine gewisse Zeit lang nicht zur Verfügung. Die wesentlichenCluster-Services sind weiterhin verfügbar – ist beispielsweise ein MON während desUpgrades inaktiv, gibt es dennoch mindestens zwei aktive MONs. Services, für die nureine einzelne Instanz vorliegt, z. B. ein einzelnes iSCSI-Gateway, stehen leider nicht zurVerfügung.
Bestimmte Arten von Daemons hängen von anderen ab. Beispielsweise hängen ObjectGateways von Ceph MON und Ceph OSD Daemons ab. Wir empfehlen für das Upgrade diefolgende Reihenfolge:
1. Admin Node
2. Ceph Monitors/Ceph Managers
3. Metadata Server
4. Ceph OSDs
5. Object Gateways
6. iSCSI Gateways
7. NFS Ganesha
8. Samba Gateways
65 Vor dem Upgrade zu beachtende Punkte SES 6
Wenn Sie AppArmor im Modus „complain“ oder „enforce“ ausgeführt hatten, müssen Sievor dem Upgrade eine Salt-Pillar-Variable festlegen. SUSE Linux Enterprise Server 15 SP1umfasst standardmäßig AppArmor, weshalb die AppArmor-Verwaltung in die DeepSea-Phase 0 integriert wurde. Laut dem Standardverhalten in SUSE Enterprise Storage 6 werdenAppArmor und die zugehörigen Prole entfernt. Soll das in SUSE Enterprise Storage 5.5kongurierte Verhalten beibehalten werden, prüfen Sie, ob die Datei /srv/pillar/ceph/stack/global.yml eine der folgenden Zeilen enthält, bevor Sie das Upgrade starten:
apparmor_init: default-enforce
oder
apparmor_init: default-complain
Ab SUSE Enterprise Storage 6 sind MDS-Namen, die mit einer Zier beginnen, nicht mehrzulässig und MDS-Daemons werden nicht gestartet. Sie können prüfen, ob Ihre Daemonssolche Namen aufweisen. Führen Sie hierzu entweder das Kommando ceph fs statusaus oder starten Sie einen MDS neu und prüfen Sie, ob dessen Protokolle die folgendeMeldung enthalten:
deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden ina future version. MDS names may not start with a numeric digit.
Wird die obige Meldung angezeigt, müssen die MDS-Namen migriert werden, bevor Sie aufSUSE Enterprise Storage 6 aufrüsten können. DeepSea umfasst eine Orchestrierung, mitder diese Migration automatisiert wird. Den MDS-Namen, die mit einer Zier beginnen,wird „mds“ vorangestellt.:
root@master # salt-run state.orch ceph.mds.migrate-numerical-names
66 Vor dem Upgrade zu beachtende Punkte SES 6
Tipp: Benutzerdefinierte Konfiguration mit Bindung anMDS-NamenWenn bestimmte Kongurationseinstellungen an MDS-Namen gebunden sind unddie Namen Ihrer MDS-Daemons mit einer Zier beginnen, prüfen Sie, ob IhreKongurationseinstellungen auch für die neuen Namen angewendet werden (mitdem Präx „mds“). Betrachten Sie den folgenden Beispielabschnitt in der Datei /etc/ceph/ceph.conf :
[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digitmds cache memory limit = 1073741824mds standby for name = 456-another-mds
Der Orchestrator ceph.mds.migrate-numerical-names ersetzt den MDS-Daemon-Namen „123-my-mds“ durch „mds.123-my-mds“. Sie müssen dieKonguration gemäß dem neuen Namen anpassen:
[mds.mds,123-my-mds] # config setting specific to MDS name with the new namemds cache memory limit = 1073741824mds standby for name = mds.456-another-mds
Damit werden MDS-Daemons mit den neuen Namen eingefügt, bevor die bisherigen MDS-Daemons entfernt werden. Die Anzahl der MDS-Daemons verdoppelt sich für kurze Zeit.Die Clients können erst nach einer kurzen Pause für das Failover auf CephFS zugreifen.Planen Sie die Migration daher für einen Zeitraum, in dem Sie nur eine geringe oder garkeine CephFS-Auslastung erwarten.
6.2 Sichern von ClusterdatenDie Sicherung der Konguration und Daten eines Clusters ist nicht obligatorisch. Es wird jedochdringend empfohlen, wichtige Kongurationsdateien und Clusterdaten zu sichern. WeitereInformationen nden Sie in Buch „Verwaltungshandbuch”, Kapitel 3 „Sichern der Cluster-Konfiguration
und -Daten“.
67 Sichern von Clusterdaten SES 6
6.3 Migration von ntpd zu chronydSUSE Linux Enterprise Server 15 SP1 synchronisiert die Uhrzeit des lokalen Hosts nicht mehrüber ntpd . Stattdessen wird chronyd verwendet. Sie müssen den Zeitsynchronisierungs-Daemon auf jedem Cluster Node migrieren. Sie können wahlweise vor dem Cluster-Upgrade zuchronyd migrieren oder zunächst den Cluster aufrüsten und die Migration zu chronyd danachdurchführen.
PROZEDUR 6.1: MIGRATION ZU chronyd VOR DEM CLUSTER-UPGRADE
1. Installieren Sie das Paket chrony :
root@minion > zypper install chrony
2. Bearbeiten Sie die chronyd -Kongurationsdatei /etc/chrony.conf und fügen Sie NTP-Quellen aus der aktuellen ntpd -Konguration in /etc/ntp.conf ein.
Tipp: Weitere Informationen zur chronyd-KonfigurationIn https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html ndenSie weitere Anweisungen, wie Sie Zeitquellen in die chronyd -Kongurationeinfügen.
3. Deaktivieren und stoppen Sie den ntpd -Service:
root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
4. Starten und aktivieren Sie den chronyd -Service:
root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
5. Überprüfen Sie den Status von „chrony“:
root@minion > chronyc tracking
PROZEDUR 6.2: MIGRATION ZU chronyd NACH DEM CLUSTER-UPGRADE
1. Fügen Sie während des Cluster-Upgrades die folgenden Software-Repositorys ein:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
68 Migration von ntpd zu chronyd SES 6
2. Rüsten Sie den Cluster auf Version 6 auf.
3. Bearbeiten Sie die chronyd -Kongurationsdatei /etc/chrony.conf und fügen Sie NTP-Quellen aus der aktuellen ntpd -Konguration in /etc/ntp.conf ein.
Tipp: Weitere Informationen zur chronyd-KonfigurationIn https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html ndenSie weitere Anweisungen, wie Sie Zeitquellen in die chronyd -Kongurationeinfügen.
4. Deaktivieren und stoppen Sie den ntpd -Service:
root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
5. Starten und aktivieren Sie den chronyd -Service:
root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
6. Migrieren Sie von ntpd zu chronyd .
7. Überprüfen Sie den Status von „chrony“:
root@minion > chronyc tracking
8. Entfernen Sie die eingefügten Legacy-Software-Repositorys, mit denen ntpd während desUpgrade-Prozesses im System beibehalten wurde.
6.4 Patchen des Clusters vor dem UpgradeWenden Sie die aktuellen Patches vor dem Upgrade auf alle Cluster Nodes an.
6.4.1 Erforderliche Software-Repositorys
Prüfen Sie, ob die erforderlichen Repositorys auf den einzelnen Knoten konguriert sind. Mitfolgendem Kommando rufen Sie eine Liste aller verfügbaren Repositorys ab:
root@minion > zypper lr
69 Patchen des Clusters vor dem Upgrade SES 6
Für SUSE Enterprise Storage 5.5 erforderlich:
SLES12-SP3-Installer-Updates
SLES12-SP3-Pool
SLES12-SP3-Updates
SUSE-Enterprise-Storage-5-Pool
SUSE-Enterprise-Storage-5-Updates
Für NFS/SMB Gateway auf SLE-HA unter SUSE Linux Enterprise Server 12 SP3 erforderlich:
SLE-HA12-SP3-Pool
SLE-HA12-SP3-Updates
6.4.2 Repository-Staging-Systeme
Wenn Sie mit einem Repository-Staging-System arbeiten (SMT, RMT oder SUSE Manager),erstellen Sie eine neue, eingefrorene Patchstufe für die aktuelle und die neue SUSE EnterpriseStorage-Version.
Weitere Informationen nden Sie in:
https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html ,
https://www.suse.com/documentation/sles-15/book_rmt/data/book_rmt.html .
https://www.suse.com/documentation/suse-manager-3/index.html ,
6.4.3 Patchen des gesamten Clusters mit den aktuellen Patches
1. Wenden Sie die aktuellen Patches für SUSE Enterprise Storage 5.5 und SUSE LinuxEnterprise Server 12 SP3 auf jeden Ceph Cluster Node an. Prüfen Sie, ob dierichtigen Software-Repositorys mit den einzelnen Cluster Nodes verbunden sind (sieheAbschnitt 6.4.1, „Erforderliche Software-Repositorys“) und führen Sie die DeepSea-Phase 0 aus:
root@master # salt-run state.orch ceph.stage.0
70 Repository-Staging-Systeme SES 6
2. Prüfen Sie nach Abschluss der Phase 0, ob der Status der einzelnen Cluster „HEALTH_OK“umfasst. Falls nicht, beheben Sie das Problem, bevor Sie etwaige Neustarts innachfolgenden Schritten vornehmen.
3. Prüfen Sie mit zypper ps , ob Prozesse vorliegen, die mit veralteten Bibliotheken oderBinärdateien ausgeführt werden, und starten Sie die betreenden Prozesse neu.
4. Prüfen Sie, ob der ausgeführte Kernel die aktuell verfügbare Version aufweist, und startenSie ihn neu, wenn dies nicht der Fall ist. Prüfen Sie die Ausgabe der folgenden Kommandos:
cephadm@adm > uname -acephadm@adm > rpm -qa kernel-default
5. Prüfen Sie, ob das Paket ceph in Version 12.2.12 (oder höher) vorliegt. Prüfen Sie, obdas Paket deepsea in Version 0.8.9 (oder höher) vorliegt.
6. Wenn Sie bislang mit Einstellungen für bluestore_cache gearbeitet haben, sind dieseEinstellungen ab ceph Version 12.2.10 nicht mehr in Kraft. Die neue Einstellungbluestore_cache_autotune , die standardmäßig auf „true“ eingestellt ist, deaktiviertdie manuelle Festlegung der Cache-Größe. Soll das bisherige Verhalten wieder aktiviertwerden, legen Sie bluestore_cache_autotune=false fest. Weitere Informationennden Sie unter Buch „Verwaltungshandbuch”, Kapitel 16 „Ceph Cluster-Konfiguration“, Abschnitt
16.2.1 „Automatische Festlegung der Cache-Größe“.
6.5 Überprüfen der aktuellen Umgebung
Wenn oensichtliche Probleme im System vorliegen, beheben Sie sie, bevor Sie dasUpgrade starten. Allein durch das Upgrade werden bestehende Systemprobleme unterkeinen Umständen behoben.
Prüfen Sie die Cluster-Leistung. Wählen Sie hierzu unter Kommandos wie rados bench ,ceph tell osd.* bench oder iperf3 .
Prüfen Sie den Zugri auf Gateways (z. B. iSCSI-Gateway oder Object Gateway) und aufRADOS Block Device.
Dokumentspezische Teile der Systemeinrichtung, z. B. Details zur Netzwerkeinrichtung,Partitionierung oder Installation.
71 Überprüfen der aktuellen Umgebung SES 6
Stellen Sie wichtige Systeminformationen mit supportconfig zusammen undspeichern Sie sie außerhalb der Cluster Nodes. Weitere Informationennden Sie in https://www.suse.com/documentation/sles-12/book_sle_admin/data/
sec_admsupport_supportconfig.html .
Prüfen Sie, ob ausreichend freier Speicherplatz auf jedem Cluster Node bereitsteht. PrüfenSie den freien Speicherplatz mit df -h . Bei Bedarf geben Sie Speicherplatz frei: EntfernenSie nicht mehr benötigte Dateien/Verzeichnisse oder veraltete OS-Snapshots. Falls derSpeicherplatz nicht ausreicht, setzen Sie das Upgrade erst dann fort, wenn Sie genügendSpeicherplatz freigegeben haben.
6.6 Prüfen des Cluster-Status
Führen Sie das Kommando cluster health aus, bevor Sie den Upgrade-Vorgang starten.Starten Sie das Upgrade erst dann, wenn jeder Cluster Node „HEALTH_OK“ meldet.
Prüfen Sie, ob alle Services ausgeführt werden:
Salt Master und Salt Master Daemons.
Ceph Monitor und Ceph Manager Daemons.
Metadatenserver Daemons.
Ceph OSD Daemons.
Object Gateway-Daemons.
iSCSI-Gateway-Daemons.
Die folgenden Kommandos geben Details zum Cluster-Status und zur jeweiligen Kongurationzurück:
ceph -s
Gibt eine kurze Zusammenfassung des Ceph Cluster-Zustands, der ausgeführten Services,der Datenauslastung und der E/A-Statistik zurück. Prüfen Sie, ob die Meldung„HEALTH_OK“ vorliegt, bevor Sie das Upgrade starten.
ceph health detail
Gibt Details zurück, wenn der Ceph Cluster-Zustand nicht in Ordnung ist.
72 Prüfen des Cluster-Status SES 6
ceph versions
Gibt die Versionen der ausgeführten Ceph Daemons zurück.
ceph df
Gibt den gesamten und den freien Speicherplatz auf dem Cluster zurück. Starten Sie dasUpgrade nur dann, wenn der freie Speicherplatz im Cluster bei mindestens 25 % desgesamten Speicherplatzes liegt.
salt '*' cephprocesses.check results=true
Gibt die ausgeführten Ceph-Prozesse und ihre PIDs zurück, sortiert nach den Salt Minions.
ceph osd dump | grep ^flags
Prüfen Sie, ob die Flaggen „recovery_deletes“ und „purged_snapdirs“ vorhanden sind. Fallsnicht, können Sie mit folgendem Kommando ein Scrubbing für alle Platzierungsgruppenerzwingen: Beachten Sie, dass dieses erzwungene Scrubbing die Leistung Ihrer Ceph Clientsunter Umständen negativ beeinusst.
cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub
6.7 Oine-Upgrade von CTDB-ClusternCTDB umfasst eine geclusterte Datenbank, die von Samba Gateways herangezogen wird. DasCTDB-Protokoll ist sehr einfach und unterstützt keine Cluster mit Knoten, die mit anderenProtokollversionen kommunizieren. CTDB-Knoten müssen daher vor einem Upgrade oinegeschaltet werden.
6.8 Upgrade Knoten für Knoten – GrundverfahrenDamit die wesentlichen Cluster-Services auch während des Upgrades verfügbar sind, müssenSie die Cluster Nodes einzeln nacheinander aufrüsten. Für das Upgrade eines Knotens stehenzwei Möglichkeiten zur Auswahl: entweder mit der Installationsprogramm-DVD oder mit demDistribution Migration System.
Nach dem Aufrüsten der einzelnen Knoten wird empfohlen, mit rpmconfigcheck nachaktualisierten Kongurationsdateien zu suchen, die lokal bearbeitet wurden. Wenn dasKommando eine Liste von Dateinamen mit dem Sux .rpmnew , .rpmorig oder .rpmsavezurückgibt, vergleichen Sie diese Dateien mit den aktuellen Kongurationsdateien, damit
73 Oine-Upgrade von CTDB-Clustern SES 6
gewährleistet ist, dass keine lokalen Änderungen verloren gehen. Aktualisieren Sie ggf. diebetroenen Dateien. Weitere Informationen zur Verwendung von .rpmnew -, .rpmorig - und.rpmsave -Dateien nden Sie in https://documentation.suse.com/sles/15-SP1/single-html/SLES-
admin/#sec-rpm-packages-manage .
Tipp: Bezuglose PaketeNach dem Aufrüsten eines Knotens sind einige Pakete „bezuglos“, besitzen alsokein übergeordnetes Repository mehr. Dieser Fall tritt ein, da python2-Pakete nichtautomatisch veraltet sind, wenn python3-spezische Pakete vorliegen.
Weitere Informationen zum Abrufen bezugloser Pakete nden Sie in https://
www.suse.com/documentation/sles-15/book_sle_admin/data/
sec_zypper.html#sec_zypper_softup_orphaned .
6.8.1 Manuelles Knoten-Upgrade mit der Installationsprogramms-DVD
1. Starten Sie den Knoten von der Installationsprogramm-DVD/dem Image mit LinuxEnterprise Server 15 SP1 neu.
2. Wählen Sie im Boot-Menü die Option Upgrade.
3. Prüfen Sie im Bildschirm Select the Migration Target (Migrationsziel auswählen), ob „SUSELinux Enterprise Server 15 SP1“ ausgewählt ist, und aktivieren Sie das KontrollkästchenManually Adjust the Repositories for Migration (Repositorys für Migration manuellanpassen).
74 Manuelles Knoten-Upgrade mit der Installationsprogramms-DVD SES 6
ABBILDUNG 6.1: AUSWAHL DES MIGRATIONSZIELS
4. Wählen Sie die folgenden Module zur Installation aus:
SUSE Enterprise Storage 6 x86_64
Basesystem Module 15 SP1 x86_64
Desktop Applications Module 15 SP1 x86_64
Legacy Module 15 SP1 x86_64
Server Applications Module 15 SP1 x86_64
5. Prüfen Sie im Bildschirm Previously Used Repositories (Bisher verwendete Repositorys), obdie richtigen Repositorys ausgewählt sind. Falls das System nicht bei SCC/SMT registriertist, müssen Sie die Repositorys manuell einfügen.Für SUSE Enterprise Storage 6 erforderlich:
SLE-Module-Basesystem15-SP1-Pool
SLE-Module-Basesystem15-SP1-Updates
SLE-Module-Server-Applications15-SP1-Pool
SLE-Module-Server-Applications15-SP1-Updates
75 Manuelles Knoten-Upgrade mit der Installationsprogramms-DVD SES 6
SLE-Module-Desktop-Applications15-SP1-Pool
SLE-Module-Desktop-Applications15-SP1-Updates
SLE-Product-SLES15-SP1-Pool
SLE-Product-SLES15-SP1-Updates
SLE15-SP1-Installer-Updates
SUSE-Enterprise-Storage-6-Pool
SUSE-Enterprise-Storage-6-Updates
Wenn ntpd nach der SES-Migration zu chronyd migriert werden soll (siehe Abschnitt 6.3,
„Migration von ntpd zu chronyd“), fügen Sie die folgenden Repositorys ein:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
Für NFS/SMB Gateway auf SLE-HA unter SUSE Linux Enterprise Server 15 SP1erforderlich:
SLE-Product-HA15-SP1-Pool
SLE-Product-HA15-SP1-Updates
6. Prüfen Sie die Installation Settings (Installationseinstellungen) und starten Sie denInstallationsvorgang mit Update (Aktualisieren).
6.8.2 Knoten-Upgrade mit dem SUSE Distribution MigrationSystem
Das Distribution Migration System (DMS) bietet einen Pfad für das Upgrade eines installiertenSUSE Linux Enterprise-Systems von einer Hauptversion auf eine andere Hauptversion. Imnachfolgenden Verfahren wird SUSE Enterprise Storage 5.5 mit DMS auf Version 6 aufgerüstet,wobei auch die zugrunde liegende Migration von SUSE Linux Enterprise Server 12 SP3 auf SUSELinux Enterprise Server 15 SP1 durchgeführt wird.
76 Knoten-Upgrade mit dem SUSE Distribution Migration System SES 6
Allgemeine und ausführliche Informationen zu DMS ndenSie in https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/
distribution-migration-system/ .
1. Installieren Sie die RPM-Pakete für die Migration. Damit wird der GRUB-Bootloaderso angepasst, dass das Upgrade beim nächsten Neustart automatisch ausgelöst wird.Installieren Sie das Paket SLES15-SES-Migration und suse-migration-sle15-
activation :
root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation
2. a. Ist der aufzurüstende Knoten bei einem Repository-Staging-System wie SCC,SMT, RMT oder SUSE Manager registriert, erstellen Sie /etc/sle-migration-service.yml mit folgendem Inhalt:
use_zypper_migration: truepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
b. Ist der aufzurüstende Knoten nicht bei einem Repository-Staging-System wie SCC,SMT, RMT oder SUSE Manager registriert, nehmen Sie die folgenden Änderungenvor:
i. Erstellen Sie /etc/sle-migration-service.yml mit folgendem Inhalt:
use_zypper_migration: falsepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
ii. Deaktivieren oder entfernen Sie die Repositorys für SLE 12 SP3 und SES 5und fügen Sie die Repositorys für SLE 15 SP1 und SES 6 ein. Eine Liste derzugehörigen Repositorys nden Sie in Abschnitt 6.4.1, „Erforderliche Software-
Repositorys“.
3. Führen Sie einen Neustart durch, sodass das Upgrade gestartet wird.Während des laufenden Upgrades können Sie sich vom Hostsystem aus überssh mit dem vorhandenen SSH-Schlüssel als Migrationsbenutzer anmelden(siehe https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/
distribution-migration-system/ ). Wenn Sie bei SUSE Enterprise Storage den physischen
77 Knoten-Upgrade mit dem SUSE Distribution Migration System SES 6
Zugri oder den direkten Konsolenzugri auf den Computer besitzen, können Sie sich auchan der Systemkonsole als root mit dem Passwort sesupgrade anmelden. Der Knotenwird nach dem Upgrade automatisch neu gestartet.
Tipp: Upgrade-FehlerWenn das Upgrade fehlschlägt, prüfen Sie /var/log/distro_migration.log .Beheben Sie das Problem, installieren Sie die RPM-Pakete für die Migration erneutund starten Sie den Knoten neu.
6.9 Upgrade des Admin Node
Die folgenden Kommandos sind weiterhin funktionsfähig, auch wenn auf den Salt Minionsveraltete Versionen von Ceph und Salt ausgeführt werden: salt '*' test.ping undceph status
Nach dem Upgrade des Admin Node ist openATTIC nicht mehr installiert.
Wenn SMT auf dem Admin Node gehostet wurde, führen Sie dessen Migrationzu RMT durch (siehe https://www.suse.com/documentation/sles-15/book_rmt/data/
cha_rmt_migrate.html ).
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten –
Grundverfahren“.
Tipp: Status der Cluster NodesNach dem Upgrade des Admin Node können Sie mit dem Kommando salt-runupgrade.status nützliche Informationen zu den Cluster Nodes abrufen. Mit diesemKommando werden die Ceph- und OS-Versionen aller Knoten aufgelistet und Sie erhalteneine Empfehlung für die Reihenfolge, in der die Knoten aufgerüstet werden sollten, aufdenen noch ältere Versionen ausgeführt werden.
root@master # salt-run upgrade.statusThe newest installed software versions are: ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable) os: SUSE Linux Enterprise Server 15 SP1
78 Upgrade des Admin Node SES 6
Nodes running these software versions: admin.ceph (assigned roles: master) mon2.ceph (assigned roles: admin, mon, mgr)
Nodes running older software versions must be upgraded in the following order: 1: mon1.ceph (assigned roles: admin, mon, mgr) 2: mon3.ceph (assigned roles: admin, mon, mgr) 3: data1.ceph (assigned roles: storage)[...]
6.10 Upgrade von Ceph Monitor/Ceph ManagerNodes
Wenn Ihr Cluster keine MDS-Rollen nutzt, rüsten Sie die MON/MGR Nodes einzelnnacheinander auf.
Wenn der Cluster MDS-Rollen nutzt und sich die MON/MGR- und MDS-Rollen aufdemselben Rechner benden, müssen Sie den MDS Cluster verkleinern und dann die aufdemselben Rechner bendlichen Knoten aufrüsten. Weitere Informationen nden Sie inAbschnitt 6.11, „Upgrade von Metadatenservern“.
Wenn Ihr Cluster MDS-Rollen nutzt und diese Rollen auf dedizierten Servern ausgeführtwerden, rüsten Sie alle MON/MGR Nodes einzeln nacheinander auf; verkleinern Sie dannden MDS Cluster und rüsten Sie ihn auf. Weitere Informationen nden Sie in Abschnitt 6.11,
„Upgrade von Metadatenservern“.
Anmerkung: Upgrade von Ceph MonitorAufgrund einer Einschränkung im Ceph Monitor-Design gilt Folgendes: Sobald zweiMONs auf SUSE Enterprise Storage 6 aufgerüstet wurden und ein Quorum gebildet haben,wird der dritte MON (auf dem weiterhin SUSE Enterprise Storage 5.5 ausgeführt wird)nicht wieder in den MON-Cluster aufgenommen, wenn er neu gestartet wurde (z. B. nachdem Neustart eines Knotens). Wenn zwei MONs aufgerüstet wurden, sollten die restlichenMONs daher so rasch wie möglich ebenfalls aufrüstet werden.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
79 Upgrade von Ceph Monitor/Ceph Manager Nodes SES 6
6.11 Upgrade von MetadatenservernSie müssen den Metadatenserver (MDS)-Cluster verkleinern. Aufgrund einer Inkompatibilitätbestimmter Funktionen in den SUSE Enterprise Storage-Versionen 5.5 und 6 werden dieälteren MDS-Daemons heruntergefahren, sobald ein einzelner MDS mit SES 6 in den Clustereingefügt wird. Für die Dauer des Upgrades der MDS Nodes muss der MDS-Cluster daher aufeinen einzelnen aktiven MDS (ohne Standbys) verkleinert werden. Sobald der zweite Knotenaufgerüstet wurde, können Sie den MDS-Cluster wieder erweitern.
TippAuf einem stark ausgelasteten MDS-Cluster müssen Sie die Auslastung ggf. vermindern(z. B. Clients anhalten), sodass ein einzelner MDS den gesamten Workload tragen kann.
1. Beachten Sie den aktuellen Wert der Option max_mds :
cephadm@adm > ceph fs get cephfs | grep max_mds
2. Verkleinern Sie den MDS-Cluster, wenn mehrere aktive MDS-Daemons vorliegen, alsowenn max_mds > 1 ist. Mit folgendem Kommando verkleinern Sie den MDS-Cluster:
cephadm@adm > ceph fs set FS_NAME max_mds 1
FS_NAME bezeichnet hierbei den Namen der CephFS-Instanz (standardmäßig „cephfs“).
3. Ermitteln Sie den Knoten, auf dem einer der Standby-MDS-Daemons ausgeführt wird.Betrachten Sie die Ausgabe des Kommandos ceph fs status und starten Sie das Upgradedes MDS-Clusters auf diesem Knoten.
cephadm@adm > ceph fs statuscephfs - 2 clients======+------+--------+--------+---------------+-------+-------+| Rank | State | MDS | Activity | dns | inos |+------+--------+--------+---------------+-------+-------+| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |+------+--------+--------+---------------+-------+-------++-----------------+----------+-------+-------+| Pool | type | used | avail |+-----------------+----------+-------+-------+| cephfs_metadata | metadata | 2688k | 96.8G || cephfs_data | data | 0 | 96.8G |
80 Upgrade von Metadatenservern SES 6
+-----------------+----------+-------+-------++-------------+| Standby MDS |+-------------+| mon3-6 || mon2-6 |+-------------+
In diesem Beispiel müssen Sie den Upgrade-Vorgang entweder auf dem Knoten „mon3-6“oder auf dem Knoten „mon2-6“ starten.
4. Rüsten Sie den Knoten mit dem Standby-MDS-Daemon auf. Sobald der aufgerüstete MDS-Knoten startet, werden die veralteten MDS-Daemons automatisch heruntergefahren. Zudiesem Zeitpunkt kann der CephFS-Service für die Clients kurzzeitig ausfallen.Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten –
Grundverfahren“.
5. Rüsten Sie die verbleibenden MDS-Knoten auf.
6. Setzen Sie max_mds auf die gewünschte Konguration zurück:
cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT
6.12 Upgrade von Ceph OSDsFühren Sie die folgenden Schritte auf jedem Speicher-Node aus:
1. Ermitteln Sie die OSD-Daemons, die auf einem bestimmten Knoten ausgeführt werden:
cephadm@osd > ceph osd tree
2. Legen Sie die Flagge „noout“ für jeden OSD Daemon auf dem aufzurüstenden Knoten fest:
cephadm@osd > ceph osd add-noout osd.OSD_ID
Beispiel:
cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done
Prüfen Sie mit:
cephadm@osd > ceph health detail | grep noout
81 Upgrade von Ceph OSDs SES 6
oder
cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN 6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
3. Erstellen Sie /etc/ceph/osd/*.json -Dateien für alle vorhandenen OSDs. Führen Siehierzu das folgende Kommando auf dem aufzurüstenden Knoten aus:
cephadm@osd > ceph-volume simple scan --force
4. Rüsten Sie den OSD Node auf. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade
Knoten für Knoten – Grundverfahren“.
5. Aktivieren Sie alle im System aufgefundenen OSDs:
cephadm@osd > ;ceph-volume simple activate --all
Tipp: Aktivieren einzelner DatenpartitionenSollen die Datenpartitionen einzeln aktiviert werden, müssen Sie das entsprechendeKommando ceph-volume für die jeweilige Partitionen ermitteln. Ersetzen Sie X1durch den richtigen Buchstaben/die richtige Zahl der Partition:
cephadm@osd > ceph-volume simple scan /dev/sdX1
Beispiel:
cephadm@osd > ceph-volume simple scan /dev/vdb1[...]--> OSD 8 got scanned and metadata persisted to file:/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json--> To take over management of this scanned OSD, and disable ceph-diskand udev, run:--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
82 Upgrade von Ceph OSDs SES 6
Die letzte Zeile der Ausgabe enthält das Kommando, mit dem Sie die Partitionaktivieren:
cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290[...]--> All ceph-disk systemd units have been disabled to prevent OSDsgetting triggered by UDEV events[...]Running command: /bin/systemctl start ceph-osd@8--> Successfully activated OSD 8 with FSIDd7bd2685-5b92-4074-8161-30d146cd0290
6. Prüfen Sie, ob der OSD Node nach dem Neustart ordnungsgemäß gestartet wird.
7. Reagieren Sie auf die Meldung „Legacy BlueStore stats reporting detected on XXOSD(s)“ (Gemeldete Legacy-BlueStore-Statistik auf XX OSD(s) erkannt):
cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)
Diese Warnmeldung ist beim Upgrade von Ceph auf Version 14.2.2 normal. Mit folgenderEinstellung können Sie sie deaktivieren:
bluestore_warn_on_legacy_statfs = false
Zur Problembehebung führen Sie das folgende Kommando auf allen OSDs aus, währendsie gestoppt sind:
cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX
Das folgende Helper-Skript führt ceph-bluestore-tool repair für alle OSDs auf demKnoten NODE_NAME aus:
OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\
83 Upgrade von Ceph OSDs SES 6
salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done
8. Heben Sie die Flagge „noout“ für jeden OSD Daemon auf dem aufzurüstenden Knoten auf:
cephadm@osd > ceph osd rm-noout osd.OSD_ID
Beispiel:
cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done
Prüfen Sie mit:
cephadm@osd > ceph health detail | grep noout
Hinweis:
cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)
9. Prüfen Sie den Cluster-Status. Die Ausgabe ähnelt der folgenden:
cephadm@osd > ceph statuscluster: id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12 health: HEALTH_WARN 3 monitors have not enabled msgr2
services: mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h) mgr: mon2(active, since 22m), standbys: mon1, mon3 osd: 30 osds: 30 up, 30 in
data: pools: 1 pools, 1024 pgs objects: 0 objects, 0 B usage: 31 GiB used, 566 GiB / 597 GiB avail pgs: 1024 active+clean
10. Prüfen Sie, ob alle OSD Nodes neu gestartet und ob die OSDs nach dem Neustartautomatisch gestartet wurden.
84 Upgrade von Ceph OSDs SES 6
6.13 OSD-Migration zu BlueStoreOSD BlueStore ist ein neues Back-End für die OSD Daemons. Ab SUSE Enterprise Storage5 ist dies die Standardoption. Verglichen mit FileStore, das Objekte als Dateien in einemXFS-Dateisystem speichert, kann BlueStore eine höhere Leistung bereitstellen, weil es Objektedirekt auf dem zugrundeliegenden Blockgerät speichert. BlueStore ermöglicht außerdem weitereFunktionen, wie integrierte Komprimierung und EC-Überschreibungen, die bei FileStore nichtzur Verfügung stehen.
Für BlueStore spezisch umfasst ein OSD ein „wal“ (Write Ahead-Protokoll)-Gerät und ein„db“ (RocksDB-Datenbank)-Gerät. Die RocksDB-Datenbank enthält die Metadaten für einenBlueStore OSD. Diese beiden Geräte benden sich standardmäßig auf demselben Gerät wie einOSD, doch jedes der beiden kann auf andere (z. B. schnellere) Medien platziert werden.
In SUSE Enterprise Storage 5 werden sowohl FileStore als auch BlueStore unterstützt undFileStore und BlueStore OSDs können gemeinsam in einem einzelnen Cluster vorhanden sein.Während des Upgrade-Vorgangs für SUSE Enterprise Storage werden FileStore OSDs nichtautomatisch zu BlueStore konvertiert. Beachten Sie, dass die BlueStore-spezischen Funktionennicht auf OSDs verfügbar sind, die nicht zu BlueStore migriert wurden.
Vor der Konvertierung zu BlueStore müssen die OSDs SUSE Enterprise Storage 5 ausführen. DerKonvertierungsvorgang ist langsam, weil alle Daten zweimal umgeschrieben werden. Obwohlder Migrationsvorgang möglicherweise lange dauert, fällt der Cluster nicht aus und alle Clientskönnen währenddessen weiterhin auf den Cluster zugreifen. Rechnen Sie für die Dauer derMigration jedoch mit einer geringeren Leistung. Der Grund dafür besteht in einem Ausgleichund Abgleich der Cluster-Daten.
Gehen Sie bei der Migration von FileStore OSDs zu BlueStore folgendermaßen vor:
Tipp: Sicherheitsmaßnahmen ausschaltenSalt-Kommandos, die zur Ausführung der Migration erforderlich sind, werden durchSicherheitsmaßnahmen blockiert. Führen Sie folgendes Kommando aus, um dieseVorsichtsmaßnahmen auszuschalten:
root@master # salt-run disengage.safety
Bauen Sie die Knoten vor dem Fortsetzen des Vorgangs neu auf:
root@master # salt-run rebuild.node TARGET
85 OSD-Migration zu BlueStore SES 6
Sie können die Knoten auch einzeln neu aufbauen. Beispiel:
root@master # salt-run rebuild.node data1.ceph
Mit rebuild.node werden stets alle OSDs im Knoten entfernt und neu erstellt.
WichtigWenn ein OSD nicht konvertiert werden kann, zerstört die erneute Ausführungdes Aufbaus die bereits konvertierten BlueStore OSDs. Anstatt den Aufbau neuauszuführen, können Sie Folgendes ausführen:
root@master # salt-run disks.deploy TARGET
Nach der Migration zu BlueStore bleibt die Anzahl der Objekte gleich und dieDatenträgerauslastung ist nahezu dieselbe.
6.14 Upgrade von AnwendungsknotenRüsten Sie die Anwendungsknoten in der folgenden Reihenfolge auf:
1. Object Gateways
Wenn sich ein Lastausgleich vor Object Gateways bendet, sollte ein Upgrade derObject Gateways bei laufendem Betrieb ohne Ausfall möglich sein.
Prüfen Sie nach jedem Upgrade, ob die Object Gateway-Daemons ausgeführt werden,und testen Sie mit einem S3/Swift-Client.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten –
Grundverfahren“.
2. iSCSI Gateways
86 Upgrade von Anwendungsknoten SES 6
Wenn iSCSI Initiatoren mit Multipath konguriert sind, sollte ein Upgrade der iSCSI-Gateways bei laufendem Betrieb ohne Ausfall möglich sein.
Prüfen Sie nach jedem Upgrade, ob der lrbd -Daemon ausgeführt wird, und testenSie mit einem Initiator.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten –
Grundverfahren“.
3. NFS Ganesha. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für
Knoten – Grundverfahren“.
4. Samba Gateways. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für
Knoten – Grundverfahren“.
6.15 Aktualisieren von policy.cfg und Deploy CephDashboard mit DeepSeaBearbeiten Sie /srv/pillar/ceph/proposals/policy.cfg auf dem Admin Node und wendenSie die folgenden Änderungen an:
Wichtig: Keine neuen ServicesNehmen Sie während des Cluster-Upgrades keine neuen Services in die Datei policy.cfgauf. Ändern Sie die Cluster-Architektur erst dann, wenn das Upgrade abgeschlossen ist.
1. Entfernen Sie role-openattic .
2. Fügen Sie role-prometheus und role-grafana in den Knoten ein, auf dem Prometheusund Grafana installiert waren (in der Regel der Admin Node).
3. Die Rolle profile-PROFILE_NAME wird nunmehr ignoriert. Fügen Sie die neue Rolle inder Zeile role-storage ein. Für die vorhandene Rolle
profile-default/cluster/*.sls
fügen Sie beispielsweise Folgendes ein:
role-storage/cluster/*.sls
87 Aktualisieren von policy.cfg und Deploy Ceph Dashboard mit DeepSea SES 6
4. Synchronisieren Sie alle Salt-Module:
root@master # salt '*' saltutil.sync_all
5. Aktualisieren Sie den Salt-Pillar mit DeepSea-Phase 1 und Phase 2:
root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2
6. Bereinigen Sie openATTIC:
root@master # salt OA_MINION state.apply ceph.rescind.openatticroot@master # salt OA_MINION state.apply ceph.remove.openattic
7. Heben Sie das Grain „restart_igw“ auf, sodass Phase 0 nicht das iSCSI-Gateway neu startet,das bislang noch nicht installiert wurde:
Salt mastersalt '*' grains.delkey restart_igw
8. Führen Sie abschließend die DeepSea-Phasen 0–4 aus:
root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4
Tipp: Fehler „subvolume missing“ (Subvolume fehlt) inPhase 3Unter Umständen schlägt die DeepSea-Phase 3 mit diesem Fehler fehl:
subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \'/var/lib/ceph subvolume missing on 4510-1', \[...]'See /srv/salt/ceph/subvolume/README.md']
In diesem Fall müssen Sie /srv/pillar/ceph/stack/global.yml bearbeiten unddie folgende Zeile einfügen:
subvolume_init: disabled
88 Aktualisieren von policy.cfg und Deploy Ceph Dashboard mit DeepSea SES 6
Aktualisieren Sie dann den Salt-Pillar und führen Sie die DeepSea-Phase 3 erneutaus:
root@master # salt '*' saltutil.refresh_pillar root@master # salt-run state.orch ceph.stage.3
Sobald die DeepSea-Phase 3 erfolgreich beendet wurde, wird das Ceph Dashboardausgeführt. Eine ausführliche Übersicht der Ceph Dashboard-Funktionen nden Siein Buch „Verwaltungshandbuch”, Kapitel 22 „Ceph Dashboard“.
Mit folgendem Kommando rufen Sie eine Liste der Knoten ab, auf denen dasDashboard ausgeführt wird:
cephadm@adm > ceph mgr services | grep dashboard
Mit folgendem Kommando rufen Sie eine Liste der Admin-Berechtigungsnachweiseab:
root@master # salt-call grains.get dashboard_creds
9. Starten Sie die Object Gateway-Services einzeln nacheinander, sodass sie den „beast“-Webserver anstelle des veralteten „civetweb“ nutzen:
root@master # salt-run state.orch ceph.restart.rgw.force
10. Bevor Sie den Vorgang fortsetzen, wird dringend empfohlen, das Ceph-Telemetriemodulzu aktivieren. Weitere Informationen und Anweisungen nden Sie in Buch
„Verwaltungshandbuch”, Kapitel 10 „Ceph Manager-Module“, Abschnitt 10.2 „Telemetriemodul“.
6.16 Migration von profilbasiertenImplementierungen zu DriveGroupsIn SUSE Enterprise Storage 5.5 wurde das Layout Ihrer OSDs mit sogenannten „Prolen“ inDeepSea beschrieben. Mit SUSE Enterprise Storage 6 wurde auf eine andere Vorgehensweiseumgestellt, auf die sogenannten DriveGroups (weitere Informationen siehe Abschnitt 5.5.2,
„DriveGroups“).
89 Migration von profilbasierten Implementierungen zu DriveGroups SES 6
AnmerkungDie Migration auf die neue Vorgehensweise ist nicht sofort obligatorisch. DestruktiveOperationen wie salt-run osd.remove , salt-run osd.replace oder salt-runosd.purge sind nach wie vor verfügbar. Sollen neue OSDs eingefügt werden, ist jedochIhre Mithilfe gefordert.
Angesichts der unterschiedlichen Vorgehensweise dieser Implementierungen bieten wirkeinen automatisierten Migrationspfad an. Wir bieten jedoch verschiedene Werkzeuge (Salt-Ausführungsprogramme) an, die die Migration so weit wie möglich erleichtern sollen.
6.16.1 Analysieren des aktuellen Layouts
Mit folgendem Kommando rufen Sie Informationen zu den derzeit implementierten OSDs ab:
root@master # salt-run disks.discover
Alternativ können Sie den Inhalt der Dateien in den Verzeichnissen /srv/pillar/ceph/proposals/profile-*/ prüfen. Ihre Struktur sieht in etwa wie folgt aus:
ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore
6.16.2 Erstellen von passenden DriveGroups für das aktuelleLayout
Weitere detaillierte Informationen zur DriveGroups-Spezikation nden Sie in Abschnitt 5.5.2.1,
„Spezifikation“.
Der Unterschied zwischen einer frischen Implementierung und einem Upgrade-Szenario liegtdarin, dass die zu migrierenden Laufwerke bereits „genutzt“ werden. Da
root@master # salt-run disks.list
nur nach nicht genutzten Datenträgern sucht, verwenden Sie
root@master # salt-run disks.list include_unavailable=True
90 Analysieren des aktuellen Layouts SES 6
Passen Sie die DriveGroups gemäß Ihrer aktuellen Einrichtung an. Mit folgendem Kommandoerhalten Sie eine eher bildliche Darstellung der Abläufe. Beachten Sie, dass dieses Kommandonichts zurückgibt, wenn keine freien Datenträger vorliegen:
root@master # salt-run disks.report bypass_pillar=True
Wenn Sie die ordnungsgemäße Konguration Ihrer DriveGroups geprüft haben und nun dieneue Vorgehensweise anwenden möchten, entfernen Sie die Dateien aus dem Verzeichnis /srv/pillar/ceph/proposals/profile-PROFILE_NAME/ , entfernen Sie die entsprechenden Zeilenfür profile-PROFILE_NAME/cluster/*.sls aus der Datei /srv/pillar/ceph/proposals/policy.cfg und führen Sie die DeepSea-Phase 2 aus, sodass der Salt-Pillar aktualisiert wird.
root@master # salt-run state.orch ceph.stage.2
Prüfen Sie das Ergebnis mit folgenden Kommandos:
root@master # salt target_node pillar.get ceph:storageroot@master # salt-run disks.report
Warnung: Fehlerhafte DriveGroups-KonfigurationWenn Ihre DriveGroups nicht ordnungsgemäß konguriert sind und Ihre EinrichtungErsatz-Datenträger umfasst, werden diese Datenträger so implementiert, wie Sie diesangegeben haben. Wir empfehlen, Folgendes auszuführen:
root@master # salt-run disks.report
6.16.3 OSD-Implementierung
In einfachen Fällen wie Stand-Alone-OSDs erfolgt die Migration im Lauf der Zeit. Immer wennSie einen OSD im Cluster entfernen oder ersetzen, wird er durch einen neuen, LVM-basiertenOSD ersetzt.
Tipp: Migration zum LVM-FormatImmer wenn ein einzelner „Legacy“-OSD in einem Knoten ersetzt werden muss, müssenauch alle OSDs, die bestimmte Geräte gemeinsam mit diesem OSD nutzen, zum LVM-basierten Format migriert werden.
Aus Gründen der Vollständigkeit sollten Sie die OSDs im gesamten Knoten migrieren.
91 OSD-Implementierung SES 6
6.16.4 Komplexere Einrichtungen
Bei einer dierenzierteren Einrichtung, die über Stand-Alone-OSDs hinausgeht (z. B. dedizierteWAL/DBs oder verschlüsselte OSDs), kann die Migration nur dann durchgeführt werden, wennalle dem betreenden WAL/DB-Gerät zugeordneten OSDs entfernt wurden. Dies ergibt sichaus dem Kommando ceph-volume , mit dem logische Volumes auf Datenträgern vor derImplementierung erstellt werden. So wird verhindert, dass der Benutzer partitionsbasierteImplementierungen mit LV-basierten Implementierungen vermischt. In diesen Fällen ist es ambesten, alle einem WAL/DB-Gerät zugeordneten OSDs manuell zu entfernen und mit demDriveGroups-Verfahren neu zu implementieren.
92 Komplexere Einrichtungen SES 6
7 Anpassen der Standardkonfiguration
Sie können die in Phase 2 generierte Cluster-Konguration ändern (weitere Informationenhierzu nden Sie im Abschnitt Beschreibung von DeepSea-Phasen). Beispielsweise müssen Siedie Netzwerkeinstellungen ändern oder eine standardmäßig auf dem Admin Node installierteSoftware. Ersteres erfolgt durch Ändern des Pillar, der nach Phase 2 aktualisiert wurde.Letzteres wird normalerweise durch Erstellen einer benutzerdenierten sls -Datei ausgeführt,die dann zum Pillar hinzugefügt wird. Detaillierte Informationen erhalten Sie in den folgendenAbschnitten.
7.1 Verwenden benutzerdefinierterKonfigurationsdateienIn diesem Abschnitt sind einige Aufgaben aufgeführt, für die Sie zunächst Ihre eigenen sls -Dateien hinzufügen/ändern müssen. Dieses Verfahren wird normalerweise angewendet, wennSie den standardmäßigen Bereitstellungsprozess ändern müssen.
Tipp: Präfix für benutzerdefinierte SLS-DateienIhre benutzerdenierten SLS-Dateien benden sich im selben Unterverzeichnis wie dieSLS-Dateien von DeepSea. Stellen Sie die Zeichenkette custom- als Präx vor den NamenIhrer SLS-Dateien, um zu verhindern, dass sie von den möglicherweise neu hinzugefügtenDateien aus dem DeepSea-Paket überschrieben werden.
7.1.1 Deaktivieren eines Bereitstellungschritts
Wenn Sie eine spezische Aufgabe außerhalb des DeepSea-Bereitstellungsvorgangs ausführenund sie daher überspringen müssen, erstellen Sie eine "no-operation"-Datei anhand des folgendenBeispiels:
PROZEDUR 7.1: DEAKTIVIEREN DER ZEITSYNCHRONISIERUNG
1. Erstellen Sie die Datei /srv/salt/ceph/time/disabled.sls mit folgendem Inhalt undspeichern Sie sie:
disable time setting:
93 Verwenden benutzerdefinierter Konfigurationsdateien SES 6
test.nop
2. Bearbeiten Sie die Datei /srv/pillar/ceph/stack/global.yml , fügen Sie die folgendeZeile hinzu und speichern Sie sie:
time_init: disabled
3. Verizieren Sie das Ergebnis durch Aktualisieren des Pillar und Ausführen des folgendenSchritts:
root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.timeadmin.ceph: Name: disable time setting - Function: test.nop - Result: Clean
Summary for admin.ceph------------Succeeded: 1Failed: 0------------Total states run: 1
Anmerkung: Eindeutige KennungDie Aufgabenkennung „disable time setting“ kann durch eine eindeutigeBezeichnung in einer sls -Datei ersetzt werden. Geben Sie eindeutigeBeschreibungen an, um zu verhindern, dass Kennungen missverständlich sind.
7.1.2 Ersetzen eines Bereitstellungschritts
Wenn Sie das Standardverhalten eines bestimmten Schritts durch ein benutzerdeniertesVerhalten ersetzen müssen, erstellen Sie eine benutzerdenierte sls -Datei mit dementsprechenden Inhalt.
Standardmäßig erstellt /srv/salt/ceph/pool/default.sls ein RBD-Image namens „demo“.In unserem Beispiel soll dieses Image nicht erstellt werden, sondern zwei Images namens„archive1“ und „archive2“.
94 Ersetzen eines Bereitstellungschritts SES 6
PROZEDUR 7.2: ERSETZEN DES RBD-IMAGE DEMO DURCH ZWEI BENUTZERDEFINIERTE RBD-IMAGES
1. Erstellen Sie die Datei /srv/salt/ceph/pool/custom.sls mit folgendem Inhalt undspeichern Sie sie:
wait: module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR" 1
- fire_event: True
archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024" 2
- unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True
archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True
1 Das wait-Modul pausiert bis der Status HEALTH_ERR des Ceph Clusters nicht mehrerscheint. Bei Neuinstallationen weist ein Ceph Cluster diesen Status möglicherweiseso lange auf, bis eine ausreichende Anzahl von OSDs verfügbar und die Erstellungder Pools abgeschlossen ist.
2 Das Kommando rbd ist nicht idempotent. Wird dasselbe Erstellungskommandoerneut ausgeführt, wenn das Image bereits vorhanden ist, ist der Salt-Zustandfehlerhaft. Durch die Anweisung unless wird dies verhindert.
2. Sie müssen die Datei /srv/pillar/ceph/stack/ceph/cluster.yml bearbeiten, diefolgende Zeile hinzufügen und sie speichern, um die neu erstellte benutzerdenierte Dateistatt der Standarddatei aufrufen zu können:
pool_init: custom
3. Verizieren Sie das Ergebnis durch Aktualisieren des Pillar und Ausführen des folgendenSchritts:
root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool
95 Ersetzen eines Bereitstellungschritts SES 6
Anmerkung: AutorisierungFür die Erstellung von Pools oder Images ist eine ausreichende Autorisierung erforderlich.Der admin.ceph -Minion verfügt über einen Admin-Schlüsselbund.
Tipp: Alternative MethodeAlternativ können Sie die Variable in Datei /srv/pillar/ceph/stack/ceph/roles/master.yml ändern. Durch Verwendung dieser Datei wird die Fülle von Pillar-Daten fürandere Minions reduziert.
7.1.3 Bearbeiten eines Bereitstellungschritts
Manchmal benötigen Sie zum Ausführen zusätzlicher Aufgaben möglicherweise einenbestimmten Schritt. Es ist nicht zu empfehlen, die entsprechende Zustandsdatei zu bearbeiten,weil ein zukünftiges Update dadurch kompliziert werden könnte. Erstellen Sie stattdessen zumAusführen der zusätzlichen Aufgaben eine separate Datei, die mit dem übereinstimmt, was inAbschnitt 7.1.2, „Ersetzen eines Bereitstellungschritts“ beschrieben ist.
Geben Sie der neuen sls -Datei einen beschreibenden Namen. Beispiel: Wenn Sie zweiRBD-Images zusätzlich zum Demo-Image erstellen müssen, geben Sie der Datei den Namenarchive.sls .
PROZEDUR 7.3: ERSTELLEN VON ZWEI ZUSÄTZLICHEN RBD-IMAGES
1. Erstellen Sie die Datei /srv/salt/ceph/pool/custom.sls mit folgendem Inhalt undspeichern Sie sie:
include: - .archive - .default
Tipp: Reihenfolge angebenIn diesem Beispiel erstellt Salt die archive-Images und dann das demo-Image. DieReihenfolge spielt in diesem Beispiel keine Rolle. Vertauschen Sie die Zeilen nachder Anweisung include: , um die Reihenfolge zu ändern.
96 Bearbeiten eines Bereitstellungschritts SES 6
Sie können die Zeile mit „include“ direkt zu archive.sls hinzufügen und alleImages werden ebenfalls erstellt. Allerdings verarbeitet Salt die Schritte in derenthaltenen Datei zuerst, unabhängig davon wo die Zeile mit „include“ platziertwird. Obwohl dieses Verhalten durch die Anweisungen requires und order außerKraft gesetzt werden kann, garantiert eine separate Datei, die die anderen enthält,die Einhaltung der Reihenfolge und verringert die Gefahr von Verwechslungen.
2. Bearbeiten Sie die Datei /srv/pillar/ceph/stack/ceph/cluster.yml , fügen Sie diefolgende Zeile hinzu und speichern Sie sie:
pool_init: custom
3. Verizieren Sie das Ergebnis durch Aktualisieren des Pillar und Ausführen des folgendenSchritts:
root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool
7.1.4 Bearbeiten einer Bereitstellungsphase
Wenn Sie einen völlig anderen Bereitstellungsschritt hinzufügen müssen, erstellen Sie drei neueDateien: eine sls -Datei, die das Kommando ausführt, eine Orchestrierungsdatei sowie einebenutzerdenierte Datei, die den neuen Schritt mit den ursprünglichen Bereitstellungsschrittenabstimmt.
Beispiel: Wenn Sie logrotate auf allen Minions als Teil der Vorbereitungsphase ausführenmüssen:
Erstellen Sie zunächst eine sls -Datei und fügen Sie das Kommando logrotate hinzu.
PROZEDUR 7.4: AUSFÜHREN VON logrotate AUF ALLEN SALT-MINIONS
1. Erstellen Sie ein Verzeichnis wie /srv/salt/ceph/logrotate .
2. Erstellen Sie /srv/salt/ceph/logrotate/init.sls mit dem folgenden Inhalt undspeichern Sie die Datei:
rotate logs: cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"
97 Bearbeiten einer Bereitstellungsphase SES 6
3. Verizieren Sie, dass das Kommando an einem Minion funktioniert:
root@master # salt 'admin.ceph' state.apply ceph.logrotate
Fügen Sie die Orchestrierungsdatei der Phase 0 prep hinzu, da sie vor allen anderenVorbereitungsschritten ausgeführt werden muss:
1. Erstellen Sie /srv/salt/ceph/stage/prep/logrotate.sls mit dem folgenden Inhaltund speichern Sie die Datei:
logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate
2. Verizieren Sie, dass die Orchestrierungsdatei funktioniert:
root@master # salt-run state.orch ceph.stage.prep.logrotate
Die letzte Datei ist die benutzerdenierte Datei. Sie enthält den zusätzlichen Schritt sowie dieursprünglichen Schritte:
1. Erstellen Sie /srv/salt/ceph/stage/prep/custom.sls mit dem folgenden Inhalt undspeichern Sie die Datei:
include: - .logrotate - .master - .minion
2. Setzen Sie das Standardverhalten außer Kraft. Bearbeiten Sie die Datei /srv/pillar/ceph/stack/global.yml , fügen Sie die folgende Zeile hinzu und speichern Sie sie:
stage_prep: custom
3. Verizieren Sie, dass Phase 0 funktioniert:
root@master # salt-run state.orch ceph.stage.0
98 Bearbeiten einer Bereitstellungsphase SES 6
Anmerkung: Wieso global.yml?Die Datei global.yml wird anstelle der Datei cluster.yml gewählt, weil in der Phaseprep noch kein Minion zum Ceph Cluster gehört und keinen Zugri auf Einstellungen incluster.yml hat.
7.1.5 Updates und Neustarts in Phase 0
In Phase 0 (weitere Informationen zu DeepSea-Phasen siehe Beschreibung von DeepSea-Phasen)werden der Salt Master und die Salt Minions optional neu gestartet, da für neue Pakete,beispielsweise kernel , ein Neustart des Systems erforderlich ist.
Aus dem Standardverhalten werden verfügbare neue Updates installiert und die Knoten werdenselbst bei einem Kernel-Update nicht neu gestartet.
Sie können das standardmäßige Update-/Neustartverhalten der DeepSea-Phase 0 ändern. FügenSie hierzu die Optionen stage_prep_master und stage_prep_minion in die /srv/pillar/ceph/stack/global.yml Datei ein oder ändern Sie diese Optionen. Mit _prep_master wirddas Verhalten des Salt Masters in Phase festgelegt, mit stage_prep_minion das Verhalten allerMinions. Die folgenden Parameter sind verfügbar:
default
Installiert die Updates ohne Neustart.
default-update-reboot
Installiert die Updates und neustartet nach dem Update-Vorgang.
default-no-update-reboot
Neustart ohne Installation der Updates.
default-no-update-no-reboot
Updates werden nicht installiert und es wird kein Neustart durchgeführt.
Wenn beispielsweise keine Updates auf den Cluster Nodes installiert und die Cluster Nodes nichtneu gestartet werden sollen, bearbeiten Sie /srv/pillar/ceph/stack/global.yml und fügenSie die folgenden Zeilen ein:
stage_prep_master: default-no-update-no-rebootstage_prep_minion: default-no-update-no-reboot
99 Updates und Neustarts in Phase 0 SES 6
Tipp: Werte und zugehörige DateienDie Werte von stage_prep_master entsprechen den Dateinamen in /srv/salt/ceph/stage/0/master , die Werte von stage_prep_minion dagegen den Dateien in /srv/salt/ceph/stage/0/minion :
root@master # ls -l /srv/salt/ceph/stage/0/masterdefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]
root@master # ls -l /srv/salt/ceph/stage/0/miniondefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]
7.2 Bearbeiten der ermittelten KonfigurationNach Abschluss von Phase 2 möchten Sie möglicherweise die ermittelte Konguration ändern.Führen Sie zur Anzeige der aktuellen Einstellungen Folgendes aus:
root@master # salt target pillar.items
Die Ausgabe der Standardkonguration für einen einzelnen Minion ähnelt normalerweise derfolgenden Ausgabe:
---------- available_roles: - admin - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs
100 Bearbeiten der ermittelten Konfiguration SES 6
- master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp
Die oben genannten Einstellungen werden auf verschiedene Kongurationsdateien verteilt.Die Verzeichnisstruktur mit diesen Dateien ist im Verzeichnis /srv/pillar/ceph/stack/stack.cfg deniert. Die folgenden Dateien beschreiben normalerweise Ihren Cluster:
/srv/pillar/ceph/stack/global.yml - die Datei hat Auswirkungen auf alle Minionsim Salt Cluster.
/srv/pillar/ceph/stack/ceph/cluster.yml - die Datei hat Auswirkungen auf alleMinions im Ceph Cluster namens ceph .
/srv/pillar/ceph/stack/ceph/roles/role.yml - die Datei hat Auswirkungen auf alleMinions, denen eine spezische Rolle im ceph Cluster zugewiesen wurde.
/srv/pillar/ceph/stack/cephminions/MINION_ID/yml – die Datei hat Auswirkungenauf den einzelnen Minion.
101 Bearbeiten der ermittelten Konfiguration SES 6
Anmerkung: Überschreiben von Verzeichnissen mitStandardwertenIn einem parallelen Verzeichnis ist die Standard-Kongurationseinrichtung gespeichertunter /srv/pillar/ceph/stack/default . Ändern Sie hier keine Werte, weil dieseüberschrieben werden.
Das normale Verfahren zum Ändern der gesammelten Konguration ist wie folgt:
1. Suchen Sie den Standort des Kongurationselements, das Sie ändern müssen. Wenn Siebeispielsweise eine auf den Cluster bezogene Einstellung wie das Cluster-Netzwerk ändernmüssen, bearbeiten Sie die Datei /srv/pillar/ceph/stack/ceph/cluster.yml .
2. Speichern Sie die Datei.
3. Führen Sie zum Verizieren der Änderungen Folgendes aus:
root@master # salt target saltutil.pillar_refresh
und danach
root@master # salt target pillar.items
7.2.1 Aktivieren von IPv6 für die Ceph Cluster-Implementierung
Die IPv4-Netzwerkadressierung ist derzeit gängig; IPv6 muss daher als benutzerdenierteAnpassung aktiviert werden. DeepSea bietet keine automatische Erkennung von IPv6-Adressen.
Zum Kongurieren von IPv6 legen Sie in den Variablen public_network undcluster_network in der Datei /srv/pillar/ceph/stack/global.yml gültige IPv6-Subnetzefest. Beispiel:
public_network: fd00:10::/64cluster_network: fd00:11::/64
Führen Sie dann die DeepSea-Phase 2 aus und prüfen Sie, ob die Netzwerkinformationen mitden Einstellungen übereinstimmen. In Phase 3 wird ceph.conf mit den erforderlichen Flaggenerzeugt.
102 Aktivieren von IPv6 für die Ceph Cluster-Implementierung SES 6
Wichtig: Keine Unterstützung für Dual StackCeph bietet keine Unterstützung für Dual Stack – die gleichzeitige Ausführung vonCeph auf IPv4 und IPv6 ist nicht möglich. Die DeepSea-Validierung lehnt einenfehlerhaften Abgleich zwischen public_network und cluster_network bzw. innerhalbder einzelnen Variablen ab. Im folgenden Beispiel schlägt die Validierung fehl.
public_network: "192.168.10.0/24 fd00:10::/64"
Tipp: Keine Verwendung von fe80::/10 link-local-AdressenVerwenden Sie keine fe80::/10 link-local -Adressen. Allen Netzwerkschnittstellenist eine fe80 -Adresse zugewiesen und für das ordnungsgemäße Routing ist einSchnittstellen-Qualizierer erforderlich. Weisen Sie entweder IPv6-Adressen zu, dieIhrem Standort zugeordnet sind, oder verwenden Sie fd00::/8 . Diese Adressen sind Teilder ULA und sind nicht global routingfähig.
103 Aktivieren von IPv6 für die Ceph Cluster-Implementierung SES 6
III Installation zusätzlicher Services
8 Installation der Services für den Zugri auf Ihre Daten 105
9 Ceph Object Gateway 106
10 Installation des iSCSI Gateway 114
11 Installation des CephFS 128
12 Installation von NFS Ganesha 145
8 Installation der Services für den Zugri auf IhreDaten
Nach der Bereitstellung des SUSE Enterprise Storage 6-Clusters müssen Sie möglicherweiseweitere Software für den Zugri auf Ihre Daten installieren, wie zum Beispiel das Object Gatewayoder das iSCSI-Gateway. Sie können alternativ auch ein geclustertes Dateisystem zusätzlich zumCeph Cluster bereitstellen. Dieses Kapitel konzentriert sich im Wesentlichen auf die manuelleInstallation. Wenn Sie einen Cluster über Salt bereitgestellt haben, nden Sie das Verfahren zurInstallation der entsprechenden Gateways oder des CephFS in Kapitel 5, Bereitstellen mit DeepSea/
Salt.
105 SES 6
9 Ceph Object Gateway
Das Ceph Object Gateway ist eine Objektspeicherschnittstelle, die zusätzlich zu librgw erstelltwurde, um für Anwendungen ein RESTful Gateway zu Ceph Clustern zur Verfügung zu stellen.Es unterstützt zwei Schnittstellen:
S3-compatible: Bietet die Objektspeicherfunktionalität mit einer Schnittstelle, die mit einemGroßteil der Amazon S3 RESTful API kompatibel ist.
Swift-compatible: Bietet die Objektspeicherfunktionalität mit einer Schnittstelle, die miteinem Großteil der OpenStack Swift API kompatibel ist.
Der Object Gateway-Daemon greift standardmäßig auf das „Beast“-HTTP-Front-End zurück. DasHTTP-Parsing wird mit der Boost.Beast-Bibliothek durchgeführt und die asynchrone Netzwerk-E/A mit der Boost.Asio-Bibliothek.
Das Object Gateway verfügt über eine eigene Benutzerverwaltung, weil es Schnittstellen zurVerfügung stellt, die mit OpenStack Swift und Amazon S3 kompatibel sind. Das Object Gatewayspeichert Daten im Cluster, das auch zum Speichern von Daten von den CephFS Clients oder denRADOS Blockgeräte-Clients verwendet wird. Die S3 und Swift APIs nutzen einen gemeinsamenNamespace. Somit können Sie Daten mit einer API schreiben und mit der anderen API abrufen.
Wichtig: Object Gateway bereitgestellt von DeepSeaDas Object Gateway wird als DeepSea-Rolle installiert. Daher müssen Sie es nicht manuellinstallieren.
Informationen zur Installation von Object Gateway während der Cluster-Bereitstellungnden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.
Informationen zum Hinzufügen eines neuen Nodes mit Object Gateway zum Clusternden Sie im Buch „Verwaltungshandbuch”, Kapitel 2 „Cluster-Verwaltung mit Salt“, Abschnitt 2.2
„Hinzufügen neuer Rollen zu Nodes“,
106 SES 6
9.1 Manuelle Installation von Object Gateway
1. Installieren Sie Object Gateway in einem Node, in dem Port 80 nicht genutzt wird. Mitdem folgenden Kommando werden alle erforderlichen Komponenten installiert:
cephadm@ogw > sudo zypper ref && zypper in ceph-radosgw
2. Wenn der Apache-Server der früheren Object Gateway-Instanz ausgeführt wird, stoppenSie ihn und deaktivieren Sie den entsprechenden Service:
cephadm@ogw > sudo systemctl stop disable apache2.service
3. Bearbeiten Sie /etc/ceph/ceph.conf und fügen Sie die folgenden Zeilen hinzu:
[client.rgw.gateway_host] rgw frontends = "beast port=80"
TippWenn Sie Object Gateway/Beast zur Verwendung der SSL-Verschlüsselungkongurieren möchten, bearbeiten Sie die Zeile entsprechend:
rgw frontends = beast ssl_port=7480 ssl_certificate=PATH_TO_CERTIFICATE.PEM
4. Starten Sie den Object Gateway Service neu.
cephadm@ogw > sudo systemctl restart [email protected]_host
9.1.1 Konfiguration des Object Gateway
Zum Kongurieren eines Object Gateways müssen einige Schritte ausgeführt werden.
107 Manuelle Installation von Object Gateway SES 6
9.1.1.1 Basiskonfiguration
Zur Konguration eines Ceph Object Gateways ist ein aktiver Ceph Storage Cluster erforderlich.Das Ceph Object Gateway ist ein Client des Ceph Storage Cluster. Als Ceph Storage Cluster-Client benötigt es Folgendes:
Einen Hostnamen für die Gateway-Instanz, beispielsweise gateway .
Einen Benutzernamen für den Speicher-Cluster mit den entsprechenden Berechtigungensowie einen Schlüsselbund.
Pools zum Speichern seiner Daten.
Ein Datenverzeichnis für die Gateway-Instanz.
Einen Instanzeintrag in der Ceph-Kongurationsdatei.
Jede Instanz muss zur Kommunikation mit einem Ceph Storage Cluster über einenBenutzernamen und einen Schlüssel verfügen. In den folgenden Schritten verwenden wireinen Monitor Node zum Erstellen eines Bootstrap-Schlüsselbunds. Dann erstellen wir denSchlüsselbund für den Benutzer der Object Gateway-Instanz basierend auf dem Bootstrap-Schlüsselbund. Danach erstellen wir einen Client-Benutzernamen und -Schlüssel. Als nächstesfügen wir den Schlüssel zum Ceph Storage Cluster hinzu. Zuletzt verteilen wir den Schlüsselbundan den Node, der die Gateway-Instanz enthält.
1. Erstellen Sie einen Schlüsselbund für das Gateway:
cephadm@adm > ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm@adm > sudo chmod +r /etc/ceph/ceph.client.rgw.keyring
2. Generieren Sie für jede Instanz einen Ceph Object Gateway-Benutzernamen und -Schlüssel.Als Beispiel verwenden wir den Namen gateway nach client.radosgw :
cephadm@adm > ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key
3. Fügen Sie Capabilities zum Schlüssel hinzu:
cephadm@adm > ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring
108 Konfiguration des Object Gateway SES 6
4. Sobald Sie einen Schlüsselbund und Schlüssel zum Aktivieren des Ceph Object Gatewaymit Zugri auf den Ceph Storage Cluster erstellt haben, fügen Sie den Schlüssel zu IhremCeph Storage Cluster hinzu. Beispiel:
cephadm@adm > ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \ -i /etc/ceph/ceph.client.rgw.keyring
5. Verteilen Sie den Schlüsselbund an den Node mit der Gateway-Instanz:
cephadm@adm > scp /etc/ceph/ceph.client.rgw.keyring ceph@HOST_NAME:/home/cephcephadm@adm > ssh ceph@HOST_NAMEcephadm@ogw > mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring
Tipp: Bootstrap-Schlüsselbund verwendenAls alternative Methode erstellen Sie den Bootstrap-Schlüsselbund für das Object Gatewayund verwenden diesen zum Erstellen des Object Gateway-Schlüsselbunds:
1. Erstellen sie einen Bootstrap-Schlüsselbund für das Object Gateway in einem derMonitor Nodes:
cephadm@mon > ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \ --cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-NODE_HOST/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring
2. Erstellen Sie das Verzeichnis /var/lib/ceph/radosgw/ceph-RGW_NAME zumSpeichern des Bootstrap-Schlüsselbunds:
cephadm@mon > mkdir \/var/lib/ceph/radosgw/ceph-RGW_NAME
3. Erstellen Sie einen Object Gateway-Schlüsselbund aus dem neu erstellten Bootstrap-Schlüsselbund:
cephadm@mon > ceph \ auth get-or-create client.rgw.RGW_NAME osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --name client.bootstrap-rgw \
109 Konfiguration des Object Gateway SES 6
--keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-RGW_NAME/keyring
4. Kopieren Sie den Object Gateway-Schlüsselbund zum Object Gateway Host:
cephadm@mon > scp \/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring \RGW_HOST:/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring
9.1.1.2 Erstellen von Pools (optional)
Ceph Object Gateways benötigen Ceph Storage Cluster-Pools zum Speichern spezischerGateway-Daten. Das Gateway erstellt die Pools automatisch, wenn der erstellte Benutzerüber die richtigen Berechtigungen verfügt. Stellen Sie jedoch sicher, dass Sie in der Ceph-Kongurationsdatei eine entsprechende Standardanzahl von Placement Groups pro Poolfestgelegt haben.
Die Namen der Pools entsprechen der ZONE_NAME.POOL_NAME -Syntax. Wenn ein Gateway mitder Standardregion und -zone konguriert wird, lautet der Standardzonenname „default“ wiein unserem Beispiel:
.rgw.rootdefault.rgw.controldefault.rgw.metadefault.rgw.logdefault.rgw.buckets.indexdefault.rgw.buckets.data
Informationen zum manuellen Erstellen von Pools nden Sie im Buch „Verwaltungshandbuch”,
Kapitel 11 „Verwalten von Speicher-Pools“, Abschnitt 11.2.2 „Erstellen eines Pools“.
Wichtig: Object Gateway und Pools mit LöschcodierungNur der Pool default.rgw.buckets.data kann ein Pool mit Löschcodierung sein. Alleanderen Pools müssen reproduziert werden, ansonsten wäre ein Zugri auf das Gatewaynicht möglich.
110 Konfiguration des Object Gateway SES 6
9.1.1.3 Hinzufügen einer Gateway-Konfiguration zu Ceph
Fügen Sie die Ceph Object Gateway-Konguration zur Ceph-Kongurationsdatei hinzu. Für dieCeph Object Gateway-Konguration müssen Sie die Ceph Object Gateway-Instanz nden. GebenSie dann den Namen des Hosts an, auf dem Sie den Ceph Object Gateway Daemon installierthaben, einen Schlüsselbund (zur Verwendung mit cephx) und optional eine Protokolldatei.Beispiel:
[client.rgw.INSTANCE_NAME]host = HOST_NAMEkeyring = /etc/ceph/ceph.client.rgw.keyring
Tipp: Object Gateway-ProtokolldateiFügen Sie zum Überschreiben der Object Gateway-Protokolldatei folgende Zeile hinzu:
log file = /var/log/radosgw/client.rgw.INSTANCE_NAME.log
Der Teil [client.rgw.*] der Gateway-Instanz erkennt diesen Teil der Ceph-Kongurationsdatei als Konguration eines Ceph Storage Cluster-Clients, bei dem der Client-Typ ein Ceph Object Gateway (radosgw) ist. Der Name der Instanz lautet entsprechend. Beispiel:
[client.rgw.gateway]host = ceph-gatewaykeyring = /etc/ceph/ceph.client.rgw.keyring
AnmerkungDer HOST_NAME muss der Hostname Ihres Rechners sein, der Domänennameausgenommen.
Schalten Sie dann print continue aus. Wenn Sie dies auf „true“ festgelegt haben, tretenmöglicherweise Probleme mit PUT-Operationen auf:
rgw print continue = false
Zur Verwendung eines Ceph Object Gateway mit Aufrufen der Unterdomäne S3 (beispielsweisehttp://bucketname.hostname ) müssen Sie den DNS-Namen des Ceph Object Gateways imAbschnitt [client.rgw.gateway] der Ceph-Kongurationsdatei hinzufügen:
[client.rgw.gateway]
111 Konfiguration des Object Gateway SES 6
...rgw dns name = HOST_NAME
Sie sollten auch in Erwägung ziehen, einen DNS-Server wie Dnsmasq auf Ihren Client-Rechnernzu installieren, wenn Sie die Syntax http://BUCKET_NAME verwenden.Syntax HOST_NAME .Die Datei dnsmasq.conf sollte die folgenden Einstellungen enthalten:
address=/HOST_NAME/HOST_IP_ADDRESSlisten-address=CLIENT_LOOPBACK_IP
Fügen Sie dann die IP-Adresse CLIENT_LOOPBACK_IP als ersten DNS-Server auf den Client-Rechnern hinzu.
9.1.1.4 Erstellen eines Datenverzeichnisses
Bereitstellungsskripts erstellen möglicherweise kein standardmäßiges Datenverzeichnis für dasCeph Object Gateway. Erstellen Sie Datenverzeichnisse für jede Instanz eines radosgw-Daemons,falls nicht bereits erfolgt. Durch die host -Variablen in der Ceph-Kongurationsdatei wirdfestgelegt, auf welchem Host die einzelnen Instanzen eines radosgw-Daemons ausgeführtwerden. Die normale Form gibt den radosgw-Daemon, den Cluster-Namen und die Daemon-IDan.
root # mkdir -p /var/lib/ceph/radosgw/CLUSTER_ID
Mit den oben im Beispiel genannten ceph.conf -Einstellungen würden Sie Folgendes ausführen:
root # mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway
9.1.1.5 Neustarten der Services und Starten des Gateways
Wir empfehlen, den Ceph Storage Cluster-Service neu zu starten, um sicherzustellen, dass alleKomponenten ihre Kongurationen neu geladen haben. Starten Sie dann den Service radosgw .Weitere Informationen hierzu nden Sie im Buch „Verwaltungshandbuch”, Kapitel 4 „Einführung“
und im Buch „Verwaltungshandbuch”, Kapitel 17 „Ceph Object Gateway“, Abschnitt 17.3 „Ausführen des
Object Gateway Service“.
Wenn der Service ausgeführt wird, können Sie eine anonyme GET-Anforderung stellen, umzu sehen, ob das Gateway eine Antwort zurückgibt. Eine einfache HTTP-Anforderung an denDomänennamen sollte Folgendes zurückgeben:
<ListAllMyBucketsResult>
112 Konfiguration des Object Gateway SES 6
<Owner> <ID>anonymous</ID> <DisplayName/> </Owner> <Buckets/></ListAllMyBucketsResult>
113 Konfiguration des Object Gateway SES 6
10 Installation des iSCSI Gateway
iSCSI ist ein Storage Area Network (SAN)-Protokoll, das Clients (genannt Initiators) dasSenden von SCSI-Kommandos an SCSI-Speichergeräte (Targets) auf Remote Servern ermöglicht.SUSE Enterprise Storage 6 umfasst eine Funktion, die die Ceph-Speicherverwaltung fürheterogene Clients wie Microsoft Windows* und VMware* vSphere über das iSCSI-Protokoll önet. Multipath iSCSI-Zugri ermöglicht die Verfügbarkeit und Skalierbarkeitfür diese Clients. Das standardisierte iSCSI-Protokoll stellt außerdem eine zusätzlicheEbene der Sicherheitsisolation zwischen Clients und dem SUSE Enterprise Storage 6-Cluster zur Verfügung. Die Kongurationsfunktion wird ceph-iscsi genannt. Über ceph-iscsi denieren Ceph-Speicheradministratoren für schlanke Speicherzuweisung geeignete,reproduzierte, hochverfügbare Volumes, die schreibgeschützte Snapshots, Lesen-Schreiben-Klone und eine automatische Anpassung der Größe über Ceph RADOS Block Device(RBD)unterstützen. Administratoren können dann Volumes entweder über einen einzelnen ceph-iscsi Gateway Host oder über mehrere Gateway Hosts exportieren, die Multipath Failoverunterstützen. Linux, Microsoft Windows und VMware Hosts stellen über das iSCSI-Protokolleine Verbindung zu den Volumes her. Dadurch werden sie verfügbar wie jedes andere SCSI-Blockgerät. Dies bedeutet, dass Kunden von SUSE Enterprise Storage 6 auf Ceph ezient einvollständiges Blockspeicher-Infrastruktur-Teilsystem ausführen können, das alle Funktionen undVorteile eines konventionellen SAN bietet und zukünftiges Wachstum ermöglicht.
In diesem Kapitel erhalten Sie detaillierte Informationen zum Einrichten einer Ceph Cluster-Infrastruktur mit einem iSCSI Gateway, sodass die Client-Hosts über das iSCSI-Protokolldezentral gespeicherte Daten als lokale Speichergeräte verwenden können.
10.1 iSCSI-BlockspeicheriSCSI ist eine Implementierung des Small Computer System Interface (SCSI)-Kommandos, dasmit dem in RFC 3720 angegebenen Internet Protocol (IP) festgelegt wird. iSCSI ist als Serviceimplementiert, in dem ein Client (der Initiator) über eine Sitzung auf TCP-Port 3260 mit einemServer (dem Target) kommuniziert. Die IP-Adresse und der Port eines iSCSI Targets werden alsiSCSI Portal bezeichnet, wobei ein Target über einen oder mehrere Portale sichtbar gemachtwerden kann. Die Kombination aus einem Target und einem oder mehreren Portalen wird alsTarget Portal Group (TPG) bezeichnet.
114 iSCSI-Blockspeicher SES 6
Das zugrundeliegende Daten-Link-Schicht-Protokoll für iSCSI ist normalerweise Ethernet.Genauer gesagt, moderne iSCSI-Infrastrukturen verwenden 10 Gigabit Ethernet oder schnellereNetzwerke für optimalen Durchsatz. 10 Gigabit Ethernet-Konnektivität zwischen dem iSCSIGateway und dem Backend Ceph Cluster wird dringend empfohlen.
10.1.1 Linux Kernel iSCSI Target
Das Linux Kernel iSCSI Target wurde ursprünglich LIO genannt. Es steht für linux-iscsi.org, dieursprüngliche Domäne und Website des Projekts. Einige Zeit standen für die Linux-Plattformnicht weniger als vier konkurrierende Target-Implementierungen zur Verfügung, doch LIO hatsich schließlich als einziges iSCSI-Referenz-Target durchgesetzt. Der hauptsächliche Kernel-Code für LIO verwendet den einfachen, doch in gewisser Weise zweideutigen Namen „Target“und unterscheidet dabei zwischen „Target Core“ und einer Vielzahl an Frontend- und BackendTarget-Modulen.
Das am häugsten verwendete Frontend-Modul ist wohl iSCSI. LIO unterstützt jedoch auchFibre Channel (FC), Fibre Channel over Ethernet (FCoE) und verschiedene andere Frontend-Protokolle. Zum gegenwärtigen Zeitpunkt unterstützt SUSE Enterprise Storage nur das iSCSI-Protokoll.
Das am häugsten verwendete Target Backend-Modul kann einfach jedes verfügbare Blockgerätam Target-Host neu exportieren. Dieses Modul wird iblock genannt. LIO verfügt jedoch auchüber ein RBD-spezisches Backend-Modul. Es unterstützt den parallelisierten Multipath-E/A-Zugri auf RBD-Images.
10.1.2 iSCSI Initiator
In diesem Abschnitt erhalten Sie einen kurzen Überblick über die iSCSI Initiator, die auf Linux-,Microsoft Windows und VMware-Plattformen verwendet werden.
10.1.2.1 Linux
Der Standard-Initiator für die Linux-Plattform ist open-iscsi . open-iscsi ruft einen Daemonauf ( iscsid ), den Benutzer zum Ermitteln von iSCSI Targets auf jedem vorhandenen Portal,zum Anmelden bei Targets und zum Zuordnen von iSCSI Volumes verwenden können. iscsidkommuniziert mit der mittleren SCSI-Schicht, um Kernel-interne Blockgeräte zu erstellen, die
115 Linux Kernel iSCSI Target SES 6
der Kernel dann wie jedes andere SCSI-Blockgerät im System behandeln kann. Der open-iscsi Initiator kann zusammen mit der Funktion Device Mapper Multipath ( dm-multipath )bereitgestellt werden, um ein hochverfügbares iSCSI-Blockgerät zur Verfügung zu stellen.
10.1.2.2 Microsoft Windows und Hyper-V
Der standardmäßige iSCSI Initiator für das Microsoft Windows Betriebssystem ist der MicrosoftiSCSI Initiator. Der iSCSI-Service kann über die grasche Bedienoberäche (GUI) konguriertwerden und unterstützt Multipath E/A für Hochverfügbarkeit.
10.1.2.3 VMware
Der standardmäßige iSCSI Initiator für VMware vSphere und ESX ist der VMware ESX SoftwareiSCSI Initiator, vmkiscsi . Wenn er aktiviert ist, kann er entweder vom vSphere Client odermit dem Kommando vmkiscsi-tool konguriert werden. Sie können dann Speicher-Volumesformatieren, die über den vSphere iSCSI Speicheradapter mit VMFS verbunden sind, unddiese wie jedes andere VM-Speichergerät verwenden. Der VMware Initiator unterstützt auchMultipath E/A für Hochverfügbarkeit.
10.2 Allgemeine Informationen zu ceph-iscsiceph-iscsi vereint die Vorteile von RADOS Block Devices mit der universellen Vielseitigkeitvon iSCSI. Durch Anwenden von ceph-iscsi auf einem iSCSI-Zielhost (als iSCSI-Gatewaybezeichnet) kann jede Anwendung, die die Blockspeicherung nutzen muss, von Ceph protieren,auch wenn sie kein Ceph Client-Protokoll kennt. Stattdessen können Benutzer iSCSI oder einbeliebiges anderes Target Frontend-Protokoll verwenden, um eine Verbindung zu einem LIOTarget herzustellen, das alle Target E/A in RBD-Speicheroperationen überträgt.
116 Allgemeine Informationen zu ceph-iscsi SES 6
ABBILDUNG 10.1: CEPH CLUSTER MIT EINEM EINZIGEN ISCSI GATEWAY
ceph-iscsi ist von Natur aus hochverfügbar und unterstützt Multipath-Operationen. Somitkönnen Downstream Initiator Hosts mehrere iSCSI Gateways für Hochverfügbarkeit sowieSkalierbarkeit verwenden. Bei der Kommunikation mit einer iSCSI-Konguration mit mehr alseinem Gateway sorgen Initiator möglicherweise für eine Lastausgleich von iSCSI-Anforderungenüber mehrere Gateways hinweg. Falls ein Gateway ausfällt und zeitweise nicht erreichbarist oder zu Wartungszwecken deaktiviert wird, werden E/A-Operationen transparent über einanderes Gateway weiter ausgeführt.
ABBILDUNG 10.2: CEPH CLUSTER MIT MEHREREN ISCSI GATEWAYS
117 Allgemeine Informationen zu ceph-iscsi SES 6
10.3 Überlegungen zur BereitstellungEine Mindestkonguration von SUSE Enterprise Storage 6 mit ceph-iscsi setzt sich ausfolgenden Komponenten zusammen:
Einem Ceph Storage Cluster Der Ceph Cluster besteht aus mindestens vier physischenServern, auf denen jeweils mindestens acht Objektspeicher-Daemons (OSDs) gehostetwerden. In einer derartigen Konguration fungieren drei OSD-Nodes auch als Monitor(MON)-Host.
Ein iSCSI-Zielserver, auf dem das LIO-iSCSI-Ziel ausgeführt wird und das über ceph-iscsikonguriert wurde.
Einem iSCSI Initiator-Host, auf dem open-iscsi (Linux), der Microsoft iSCSI Initiator(Microsoft Windows) oder eine beliebige andere iSCSI Initiator-Implementierungausgeführt wird.
Eine empfohlene Produktionskonguration von SUSE Enterprise Storage 6 mit ceph-iscsibesteht aus:
Einem Ceph Storage Cluster Ein Ceph Cluster für die Produktionsumgebung besteht auseiner beliebigen Anzahl (normalerweise mehr als 10) von OSD-Nodes. Auf jedem werdennormalerweise 10 bis 12 Objektspeicher-Daemons (OSDs) ausgeführt, mit mindestens dreidedizierten MON-Hosts.
Einige iSCSI-Zielserver, auf denen das LIO-iSCSI-Ziel ausgeführt wird und die über ceph-iscsi konguriert wurden. Zum Zweck von iSCSI Failover und Lastausgleich müssen dieseServer einen Kernel ausführen, der das target_core_rbd -Modul unterstützt. Update-Pakete sind im SUSE Linux Enterprise Server-Wartungskanal verfügbar.
Eine beliebige Anzahl von iSCSI Initiator-Hosts, auf denen open-iscsi (Linux), derMicrosoft iSCSI Initiator (Microsoft Windows) oder eine beliebige andere iSCSI Initiator-Implementierung ausgeführt wird.
10.4 Installation und KonfigurationIn diesem Abschnitt werden die Schritte zum Installieren und Kongurieren eines iSCSIGateways zusätzlich zu SUSE Enterprise Storage beschrieben.
118 Überlegungen zur Bereitstellung SES 6
10.4.1 Bereitstellen des iSCSI Gateway auf einem Ceph Cluster
Sie können das iSCSI-Gateway entweder im Zug der Ceph Cluster-Bereitstellung bereitstellenoder es mittels DeepSea zu einem bestehenden Cluster hinzufügen.
Informationen zur Bereitstellung während des Cluster-Bereitstellungsvorgangs nden Sie inAbschnitt 5.5.1.2, „Rollenzuweisung“.
Informationen zum Hinzufügen des iSCSI Gateways zu einem bestehenden Cluster nden Siein Buch „Verwaltungshandbuch”, Kapitel 2 „Cluster-Verwaltung mit Salt“, Abschnitt 2.2 „Hinzufügen neuer
Rollen zu Nodes“.
10.4.2 Erstellen von RBD-Images
RBD-Images werden im Ceph Store erstellt und anschließend zu iSCSI exportiert.Wir empfehlen zu diesem Zweck einen dedizierten RADOS-Pool. Sie können mit demCeph rbd -Kommandozeilenprogramm ein Volume von jedem Host aus erstellen, dereine Verbindung zu Ihrem Speicher-Cluster herstellen kann. Dazu benötigt der Clientmindestens eine ceph.conf.Datei mit Mindestkonguration und den entsprechenden CephX-Berechtigungsnachweis zur Authentizierung.
Erstellen Sie ein neues Volume für den späteren Export über iSCSI mit dem Kommando rbdcreate und geben Sie die Volume-Größe in Megabyte an. Beispiel: Führen Sie zum Erstelleneines Volumes mit 100 GB und der Bezeichnung „testvol“ im Pool „iscsi-images“ das folgendeKommando aus:
cephadm@adm > rbd --pool iscsi-images create --size=102400 'testvol'
10.4.3 Exportieren von RBD-Images über iSCSI
Zum Exportieren von RBD-Images über iSCSI stehen zwei Möglichkeiten zur Auswahl: die CephDashboard-Weboberäche oder das ceph-iscsi -Dienstprogramm „gwcli“. Dieser Abschnittbefasst sich ausschließlich mit „gwcli“, wobei erläutert wird, wie Sie ein iSCSI-Ziel erstellen,mit dem ein RBD-Image über die Kommandozeile exportiert wird.
119 Bereitstellen des iSCSI Gateway auf einem Ceph Cluster SES 6
AnmerkungEs werden lediglich die folgenden RBD-Image-Funktionen unterstützt: layering ,striping (v2) , exclusive-lock , fast-diff und data-pool . RBD-Images, beidenen andere Funktionen aktiviert sind, können nicht exportiert werden.
Starten Sie die Kommandozeilenschnittstelle für das iSCSI-Gateway als root :
root # gwcli
Wechseln Sie zu iscsi-targets und erstellen Sie das Ziel iqn.2003-01.org.linux-
iscsi.iscsi.x86:testvol :
gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol
Erstellen Sie die iSCSI-Gateways. Geben Sie hierzu den Namen ( name ) und die IP-Adresse ( ip )des Gateways an:
gwcli > /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/gatewaysgwcli > /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli > /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
TippMit dem Kommando help rufen sie eine Liste der verfügbaren Kommandos im aktuellenKongurationsknoten ab.
Nehmen Sie das RBD-Image „testvol“ in den Pool „iscsi-images“ auf:
gwcli > /iscsi-target...tvol/gateways> cd /disksgwcli > /disks> attach iscsi-images/testvol
Ordnen Sie das RBD-Image dem Ziel zu:
gwcli > /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/disksgwcli > /iscsi-target...testvol/disks> add iscsi-images/testvol
AnmerkungSie können die lokale Konguration mit systemnahen Werkzeugen wie targetcliabfragen, jedoch nicht bearbeiten.
120 Exportieren von RBD-Images über iSCSI SES 6
TippMit dem Kommando ls können sie die Konguration prüfen. EinigeKongurationsknoten unterstützen auch das Kommando info , mit dem Sieausführlichere Informationen erhalten.
Es ist zu beachten, dass die ACL-Authentizierung standardmäßig aktiviert ist, weshalb derZugri auf dieses Ziel noch nicht möglich ist. Weitere Informationen zur Authentizierung undzur Zugrissteuerung nden Sie in Abschnitt 10.4.4, „Authentifizierung und Zugrissteuerung“.
10.4.4 Authentifizierung und Zugrissteuerung
Die iSCSI-Authentizierung ist exibel und deckt zahlreiche Authentizierungsmöglichkeitenab.
10.4.4.1 Keine Authentifizierung
„Keine Authentizierung“ bedeutet, dass jeder Initiator·auf alle LUNs·im entsprechenden Zielzugreifen kann.· Soll „Keine Authentizierung“ aktiviert werden, deaktivieren Sie die ACL-Authentizierung:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> auth disable_acl
10.4.4.2 ACL-Authentifizierung
Bei der ACL-Authentizierung anhand des Initiatornamens dürfen lediglich die deniertenInitiatoren eine Verbindung herstellen. So denieren Sie einen Initiator:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20
Denierte Initiatoren können eine Verbindung herstellen, erhalten den Zugri jedoch nur aufdie RBD-Images, die dem Initiator explizit hinzugefügt wurden:
gwcli > /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol
121 Authentifizierung und Zugrissteuerung SES 6
10.4.4.3 CHAP-Authentifizierung
Neben der ACL können Sie die CHAP-Authentizierung aktivieren. Geben Sie hierzu einenBenutzernamen und ein Passwort für die einzelnen Initiatoren an:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20gwcli > /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
AnmerkungDie Benutzernamen müssen 8 bis 64 Zeichen enthalten, wobei lediglich Buchstaben unddie Sonderzeichen „.“, „@“, „-“, „_“ oder „:“ zulässig sind.
Die Passwörter müssen 12 bis 16 Zeichen enthalten, wobei lediglich Buchstaben und dieSonderzeichen „@“, „-“, „_“ oder „/“ zulässig sind.
Optional können Sie außerdem die gegenseitige CHAP-Authentizierung aktivieren. Geben Siehierzu die Parameter mutual_username und mutual_password im Kommando auth an.
10.4.4.4 Ermittlung und gegenseitige Authentifizierung
Die Ermittlungsauthentizierung ist unabhängig von den obigen Authentizierungsverfahren. Esist ein Berechtigungsnachweis für die Suche erforderlich, die Suche ist optional und sie wirdwie folgt konguriert:
gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> discovery_auth username=du123456 password=dp1234567890
AnmerkungDie Benutzernamen müssen 8 bis 64 Zeichen enthalten, wobei lediglich Buchstaben unddie Sonderzeichen „.“, „@“, „-“, „_“ oder „:“ zulässig sind.
Die Passwörter müssen 12 bis 16 Zeichen enthalten, wobei lediglich Buchstaben und dieSonderzeichen „@“, „-“, „_“ oder „/“ zulässig sind.
Optional können Sie auch die Parameter mutual_username und mutual_password imKommando discovery_auth angeben.
122 Authentifizierung und Zugrissteuerung SES 6
Die Ermittlungsauthentizierung wird mit folgendem Kommando deaktiviert:
gwcli > /iscsi-targets> discovery_auth nochap
10.4.5 Erweiterte Einstellungen
ceph-iscsi kann mit erweiterten Parametern konguriert werden, die anschließend andas LIO-E/A-Ziel übergeben werden. Die Parameter sind in „target“- und „disk“-Parameterunterteilt.
WarnungSoweit nicht anders angegeben, ist es nicht zu empfehlen, die Standardeinstellung dieserParameter zu ändern.
10.4.5.1 Zieleinstellungen
Mit dem Kommando info rufen Sie den Wert dieser Einstellungen ab:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvolgwcli > /iscsi-target...i.x86:testvol> info
Mit dem Kommando reconfigure ändern Sie eine Einstellung:
gwcli > /iscsi-target...i.x86:testvol> reconfigure login_timeout 20
Die folgenden „target“-Einstellungen stehen zur Auswahl:
default_cmdsn_depth
Standardmäßige CmdSN (Command Sequence Number)-Tiefe. Beschränkt die Anzahl derAnforderungen, die für einen iSCSI Initiator zu einem beliebigen Zeitpunkt ausstehend seinkönnen.
default_erl
Standardmäßige Fehlerwiederherstellungsstufe.
login_timeout
Wert der Zeitüberschreitung bei der Anmeldung in Sekunden.
netif_timeout
123 Erweiterte Einstellungen SES 6
NIC-Fehler-Zeitüberschreitung in Sekunden.
prod_mode_write_protect
Wert 1 verhindert das Schreiben in LUNs.
10.4.5.2 Datenträgereinstellungen
Mit dem Kommando info rufen Sie den Wert dieser Einstellungen ab:
gwcli > /> cd /disks/rbd/testvolgwcli > /disks/rbd/testvol> info
Mit dem Kommando reconfigure ändern Sie eine Einstellung:
gwcli > /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0
Die folgenden „disk“-Einstellungen stehen zur Auswahl:
block_size
Blockgröße des zugrundeliegenden Geräts.
emulate_3pc
Wert 1 aktiviert das Drittanbieterexemplar.
emulate_caw
Wert 1 aktiviert „Vergleichen“ und „Schreiben“.
emulate_dpo
Wert 1 schaltet „Disable Page Out“ ein.
emulate_fua_read
Wert 1 aktiviert das Lesen von „Force Unit Access“.
emulate_fua_write
Wert 1 aktiviert das Schreiben von „Force Unit Access“.
emulate_model_alias
Wert 1 verwendet den Backend-Gerätenamen für den Modell-Alias.
emulate_pr
Beim Wert 0 ist die Unterstützung für SCSI-Reservierungen (auch permanenteGruppenreservierungen) deaktiviert. Ist diese Option deaktiviert, kann der iSCSI-Gatewayden Reservierungsstatus ignorieren, sodass die Anforderungslatenz verbessert wird.
124 Erweiterte Einstellungen SES 6
TippWenn die iSCSI-Initiatoren keine Unterstützung für die SCSI-Reservierungbenötigen, wird empfohlen, den Wert 0 für „backstore_emulate_pr“ festzulegen.
emulate_rest_reord
Bei Wert 0 weist der Queue Algorithm Modier eingeschränkte Neusortierung auf.
emulate_tas
Wert 1 aktiviert „Task Aborted Status“.
emulate_tpu
Wert 1 aktiviert „Thin Provisioning Unmap“.
emulate_tpws
Wert 1 aktiviert „Thin Provisioning Write Same“.
emulate_ua_intlck_ctrl
Wert 1 aktiviert „Unit Attention Interlock“.
emulate_write_cache
Wert 1 schaltet „Write Cache Enable“ ein.
enforce_pr_isids
Wert 1 erzwingt ISIDs für permanente Reservierungen.
is_nonrot
Bei Wert 1 ist der Backstore eine sich nicht drehende Festplatte.
max_unmap_block_desc_count
Maximale Anzahl der Blockbeschreibungen für UNMAP.
max_unmap_lba_count:
Maximale Anzahl der LBAs für UNMAP.
max_write_same_len
Maximale Länge für WRITE_SAME.
optimal_sectors
Optimale Anforderungsgröße in Sektoren.
pi_prot_type
125 Erweiterte Einstellungen SES 6
DIF-Schutz-Typ.
queue_depth
Warteschlangentiefe.
unmap_granularity
UNMAP-Granularität.
unmap_granularity_alignment
Abstimmung der UNMAP-Granularität.
force_pr_aptpl
Ist diese Option aktiviert, schreibt LIO stets den Status der permanenten Reservierung inden permanenten Speicher, unabhängig davon, ob der Client diesen Status mit aptpl=1angefordert hat oder nicht. Dies wirkt sich nicht auf das Kernel-RBD-Back-End für LIOaus – hier wird der PR-Status in jedem Fall beibehalten. Im Idealfall sollte die Optiontarget_core_rbd den Wert „1“ erzwingen und einen Fehler auslösen, wenn ein Benutzerversucht, die Option über congfs zu deaktivieren.
unmap_zeroes_data
Diese Option gibt an, ob LIO den SCSI-Initiatoren gegenüber LBPRZ bekannt gibt, also dassNullen aus einem Bereich nach UNMAP oder WRITE SAME mit einem Bit zum Aufhebender Zuordnung gelesen werden.
10.5 Exportieren von RADOS Block Device-Images mittcmu-runnerceph-iscsi unterstützt sowohl den Backstore rbd (kernelbasiert) als auch den Backstoreuser:rbd (tcmu-runner), sodass die gesamte Verwaltung transparent und unabhängig vomBackstore abläuft.
Warnung: Technology Previewtcmu-runner -basierte iSCSI Gateway-Bereitstellungen sind aktuell ein TechnologyPreview.
Im Gegensatz zur Kernel-basierten iSCSI Gateway-Bereitstellung unterstützen tcmu-runner -basierte iSCSI Gateways keine Multipath E/A oder permanente SCSI-Reservierungen.
126 Exportieren von RADOS Block Device-Images mit tcmu-runner SES 6
Soll ein RADOS Block Device.Image mit tcmu-runner exportiert werden, müssen Sie lediglichden user:rbd -Backstore angeben, wenn Sie den Datenträger anhängen:
gwcli > /disks> attach rbd/testvol backstore=user:rbd
AnmerkungZur Verwendung von tcmu-runner muss die Funktion exclusive-lock für dasexportierte RBD-Image aktiviert sein.
127 Exportieren von RADOS Block Device-Images mit tcmu-runner SES 6
11 Installation des CephFS
Das Ceph-Dateisystem (CephFS) ist ein POSIX-fähiges Dateisystem, das seine Daten ineinem Ceph Storage Cluster speichert. CephFS verwendet dasselbe Cluster-System wie Ceph-Blockgeräte, Ceph-Objektspeicher mit seinen S3 und Swift APIs, oder systemeigene Bindungen( librados ).
Zur Verwendung eines CephFS muss ein Ceph Storage Cluster und mindestens ein Ceph MetadataServer ausgeführt werden.
11.1 Unterstützte CephFS-Szenarios und AnleitungenMit SUSE Enterprise Storage 6 führt SUSE den oziellen Support für viele Szenarios ein, indenen die dezentrale Scale-Out-Komponente CephFS verwendet wird. Dieser Eintrag beschreibtklare Grenzen und stellt Anleitungen für die vorgeschlagenen Anwendungsfälle zur Verfügung.
Eine unterstützte CephFS-Bereitstellung muss die folgenden Anforderungen erfüllen:
Mindestens einen Metadatenserver. SUSE empehlt die Bereitstellung von mehreren Nodesmit der MDS-Rolle. Nur einer davon ist aktiv , die anderen sind passiv . Denken Siedaran, alle MON Nodes im Kommando mount anzugeben, wenn Sie das CephFS von einemClient aus einhängen.
Clients arbeiten mit SUSE Linux Enterprise Server 12 SP3 (oder höher) bzw. SUSE LinuxEnterprise Server 15 (oder höher) und dem Kernel-Modultreiber cephfs . Das FUSE-Modulwird nicht unterstützt.
CephFS-Kontingente werden in SUSE Enterprise Storage 6 unterstützt und können fürbeliebige Unterverzeichnisse im Ceph-Dateisystem festgelegt werden. Das Kontingentbeschränkt entweder die Anzahl der Byte oder die Anzahl der Dateien , die unterhalbdes angegebenen Punkts in der Verzeichnishierarchie gespeichert werden können. WeitereInformationen nden Sie in Buch „Verwaltungshandbuch”, Kapitel 19 „Cluster-Dateisystem“,
Abschnitt 19.6 „Festlegen von CephFS-Kontingenten“.
128 Unterstützte CephFS-Szenarios und Anleitungen SES 6
CephFS unterstützt Änderungen des Datei-Layouts wie unter Abschnitt 11.3.4, „Datei-Layouts“
dokumentiert. Weil das Dateisystem jedoch von einem beliebigen Client aus eingehängtwird, werden neue Daten-Pools möglicherweise nicht zu einem bestehenden CephFS-Dateisystem hinzugefügt ( ceph mds add_data_pool ). Sie dürfen nur hinzugefügt werden,wenn das Dateisystem ausgehängt ist.
Mindestens einen Metadatenserver. SUSE empehlt die Bereitstellung von mehreren Nodesmit der MDS-Rolle. Zusätzliche MDS Daemons werden standardmäßig als Standby -Daemons eingerichtet und fungieren als Reserve für die aktiven MDS. Auch mehrere aktiveMDS Daemons werden unterstützt (siehe Abschnitt 11.3.2, „Größe des MDS Clusters“).
11.2 Ceph Metadata ServerDer Ceph Metadata Server (MDS) speichert Metadaten für das CephFS. Ceph-Blockgeräte undCeph-Objektspeicher verwenden keinen MDS. MDSs ermöglichen es Benutzern eines POSIX-Dateisystems, einfache Kommandos auszuführen wie ls oder find , ohne dass der Ceph StorageCluster übermäßig belastet wird.
11.2.1 Hinzufügen eines Metadatenservers
Einen MDS stellen Sie im Zug der ersten Cluster-Bereitstellung bereit. Eine Beschreibung hierzunden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“. Alternativ können Sie ihn auch zu einembereits bereitgestellten Cluster hinzufügen wie in Buch „Verwaltungshandbuch”, Kapitel 2 „Cluster-
Verwaltung mit Salt“, Abschnitt 2.1 „Hinzufügen neuer Cluster Nodes“ beschrieben.
Nach der Bereitstellung des MDS müssen Sie den Ceph OSD/MDS -Service in den Firewall-Einstellungen des Servers zulassen, auf dem der MDS bereitgestellt ist: Starten Sie yast ,navigieren Sie zuSecurity and Users (Sicherheit und Benutzer) Firewall Allowed Services(Zugelassene Services) und wählen Sie im Dropdown-Menü Service to Allow (Zuzulassender Service)die Option Ceph OSD/MDS aus. Wenn im Ceph MDS Node kein umfassender Datenverkehrzugelassen ist, tritt beim Einhängen eines Dateisystems ein Fehler auf, auch wenn andereOperationen ordnungsgemäß funktionieren.
129 Ceph Metadata Server SES 6
11.2.2 Konfigurieren eines Metadata Server
Sie können das Verhalten des MDS durch Einfügen relevanter Optionen in der ceph.conf -Kongurationsdatei weiter anpassen.
METADATENSERVER-EINSTELLUNGEN
mon force standby active
Mit „true“ (Standard) erzwingen die Monitors, dass Standby Replay aktiv ist. Festlegungim Abschnitt [mon] oder [global] .
mds cache memory limit
Das Softlimit des Arbeitsspeichers (in Byte), das der MDS für seinen Cache erzwingt.Administratoren sollten dies anstelle der alten Einstellung mds cache size verwenden.Der Standardwert ist 1 GB.
mds cache reservation
Die Cache-Reservierung (Arbeitsspeicher oder Inode) für den MDS Cache, die beibehaltenwerden soll. Wenn der MDS seinen reservierten Cache nahezu auslastet, stellt er den Client-Zustand vorübergehend wieder her, bis sich die Größe des Cache so weit verringert hat,dass die Reservierung wiederhergestellt wird. Der Standardwert ist 0,05.
mds cache size
Anzahl der im Cache zu speichernden Inodes. Der Wert 0 (Standard) bedeutet eineunbegrenzte Anzahl. Es wird empfohlen, die vom MDS Cache genutzte Speichermenge mitmds cache memory limit einzuschränken.
mds cache mid
Einfügepunkt für neue Elemente im Cache LRU (von oben). Der Standardwert ist 0.7.
mds dir commit ratio
Anteil des Verzeichnisses mit kürzlich bearbeiteten („dirty“) Daten, bevor Ceph einevollständige Aktualisierung anstelle einer Teilaktualisierung durchführt. Der Standardwertist 0,5.
mds dir max commit size
Maximale Größe einer Verzeichnisaktualisierung, bevor Ceph sie in kleinere Transaktionenaufteilt. Der Standardwert ist 90 MB.
mds decay halflife
Halbwertszeit der MDS Cache-Temperatur. Der Standardwert ist 5.
mds beacon interval
130 Konfigurieren eines Metadata Server SES 6
Zeitabschnitt (in Sekunden), in dem Beacon-Meldungen an den Monitor gesendet werden.Der Standardwert ist 4.
mds beacon grace
Zeitraum ohne Beacons, bevor Ceph einen MDS als langsam kennzeichnet und ggf. ersetzt.Der Standardwert ist 15.
mds blacklist interval
Blacklist-Dauer für ausgefallene MDSs in der OSD-Karte. Diese Einstellung steuert, wielange ausgefallene MDS Daemons in der Blacklist der OSD-Karte verbleiben. Für den Fall,dass der Administrator ein Element manuell in die Blacklist aufnimmt, bleibt die Blacklist-Dauer unverändert. Das Kommando ceph osd blacklist add greift beispielsweiseweiterhin auf die standardmäßige Blacklist-Zeit zurück. Der Standardwert ist 24 * 60.
mds reconnect timeout
Zeitraum (in Sekunden), den die Clients beim MDS-Neustart auf die Wiederherstellung derVerbindung warten. Der Standardwert ist 45.
mds tick interval
Zeitabstand, in dem der MDS interne periodische Aufgaben durchführt. Der Standardwertist 5.
mds dirstat min interval
Mindestzeitabstand (in Sekunden), mit dem die Übertragung rekursiver Statistiken nachoben in der Baumstruktur unterbunden werden soll. Der Standardwert ist 1.
mds scatter nudge interval
Zeitraum, in dem dirstat-Änderungen nach oben übertragen werden. Der Standardwert ist5.
mds client prealloc inos
Anzahl der Inode-Nummern, die pro Client-Sitzung vorab zugewiesen werden sollen. DerStandardwert ist 1000.
mds early reply
Angabe, ob das MDS den Clients gestatten soll, die Anforderungsergebnisse abzurufen,bevor sie in das Journal aufgenommen wurden. Die Standardeinstellung ist „true“.
mds use tmap
Angabe, dass eine triviale Karte für Verzeichnisaktualisierungen verwendet werden soll.Die Standardeinstellung ist „true“.
131 Konfigurieren eines Metadata Server SES 6
mds default dir hash
Funktion für das Hashing von Dateien über Verzeichnisfragmente hinweg. DerStandardwert ist 2 (also „rjenkins“).
mds log skip corrupt events
Angabe, ob das MDS versuchen soll, beschädigte Journal-Ereignisse bei der Wiedergabedes Journals zu überspringen. Die Standardeinstellung ist „false“.
mds log max events
Maximale Anzahl der Ereignisse im Journal, bevor eine Kürzung eingeleitet wird. Mit demWert -1 (Standard) werden die Grenzwerte deaktiviert.
mds log max segments
Manchmal Anzahl der Segmente (Objekte) im Journal, bevor eine Kürzung eingeleitetwird. Mit dem Wert -1 werden die Grenzwerte deaktiviert. Der Standardwert ist 30.
mds log max expiring
Maximale Anzahl der Segmente, die parallel ablaufen sollen. Der Standardwert ist 20.
mds log eopen size
Maximale Anzahl von Inoden in einem EOpen-Ereignis. Der Standardwert ist 100.
mds bal sample interval
Zeitabstand für die Ermittlung der Verzeichnistemperatur im Rahmen vonFragmentierungsentscheidungen. Der Standardwert ist 3.
mds bal replicate threshold
Maximale Temperatur, bevor Ceph versucht, die Metadaten auf anderen Knoten zureproduzieren. Der Standardwert ist 8000.
mds bal unreplicate threshold
Minimale Temperatur, bevor Ceph die Reproduktion der Metadaten auf anderen Knotenanhält. Der Standardwert ist 0.
mds bal split size
Maximale Verzeichnisgröße, bevor der MDS ein Verzeichnisfragment in kleinere Teileaufteilt. Der Standardwert ist 10000.
mds bal split rd
Maximale Verzeichnis-Lesetemperatur, bevor Ceph ein Verzeichnisfragment aufteilt. DerStandardwert ist 25000.
mds bal split wr
132 Konfigurieren eines Metadata Server SES 6
Maximale Verzeichnis-Schreibtemperatur, bevor Ceph ein Verzeichnisfragment aufteilt.Der Standardwert ist 10000.
mds bal split bits
Datenmenge (in Bit), nach der ein Verzeichnisfragment aufgeteilt werden soll. DerStandardwert ist 3.
mds bal merge size
Minimale Verzeichnisgröße, bevor Ceph versucht, nebeneinanderliegendeVerzeichnisfragmente zusammenzuführen. Der Standardwert ist 50.
mds bal interval
Zeitabstand (in Sekunden) für den Workload-Austausch zwischen MDSs. Der Standardwertist 10.
mds bal fragment interval
Verzögerung (in Sekunden) zwischen dem Zeitpunkt, an dem ein Fragment aufgeteilt oderzusammengeführt werden kann, und der Durchführung der Fragmentierungsänderung. DerStandardwert ist 5.
mds bal fragment fast factor
Verhältnis, um das die Fragmente die Aufteilungsgröße überschreiten können, bevor eineAufteilung sofort durchgeführt wird (also ohne den Fragmentzeitabstand abzuwarten). DerStandardwert ist 1.5.
mds bal fragment size max
Maximale Größe eines Fragments, bevor neue Einträge mit ENOSPC abgelehnt werden.Der Standardwert ist 100000.
mds bal idle threshold
Minimale Temperatur, bevor Ceph einen Teilbaum wieder zurück zu dessenübergeordnetem Baum migriert. Der Standardwert ist 0.
mds bal mode
Methode zur Berechnung der MDS-Last:
0 = Hybrid.
1 = Anforderungsrate und Latenz.
2 = CPU-Last.
Der Standardwert ist 0.
133 Konfigurieren eines Metadata Server SES 6
mds bal min rebalance
Minimale Teilbaumtemperatur, bevor Ceph die Migration durchführt. Der Standardwertist 0.1.
mds bal min start
Minimale Teilbaumtemperatur, bevor Ceph einen Teilbaum durchsucht. Der Standardwertist 0.2.
mds bal need min
Minimaler zu akzeptierender Anteil der Zielteilbaumgröße. Der Standardwert ist 0.8.
mds bal need max
Maximaler zu akzeptierender Anteil der Zielteilbaumgröße. Der Standardwert ist 1.2.
mds bal midchunk
Ceph migriert alle Teilbäume, die größer als dieser Anteil der Zielteilbaumgröße sind. DerStandardwert ist 0.3.
mds bal minchunk
Ceph ignoriert alle Teilbäume, die kleiner als dieser Anteil der Zielteilbaumgröße sind.Der Standardwert ist 0.001.
mds bal target removal min
Minimale Anzahl an Ausgleichsprogramm-Iterationen, bevor Ceph ein altes MDS-Ziel ausder MDS-Karte entfernt. Der Standardwert ist 5.
mds bal target removal max
Maximale Anzahl an Ausgleichsprogramm-Iterationen, bevor Ceph ein altes MDS-Ziel ausder MDS-Karte entfernt. Der Standardwert ist 10.
mds replay interval
Zeitabstand für das Journal-Polling im Standby Replay-Modus („unmittelbar betriebsbereitim Standby-Modus“). Der Standardwert ist 1.
mds shutdown check
Zeitabstand für das Cache-Polling beim Herunterfahren des MDS. Der Standardwert ist 0.
mds thrash fragments
Ceph führt eine willkürliche Fragmentierung oder Zusammenführung der Verzeichnissedurch. Der Standardwert ist 0.
mds dump cache on map
134 Konfigurieren eines Metadata Server SES 6
Ceph legt den Inhalt des MDS-Caches in eine Datei auf jeder MDS-Karte ab. DieStandardeinstellung ist „false“.
mds dump cache after rejoin
Ceph legt den Inhalt des MDS-Caches in eine Datei ab, nachdem er bei einerWiederherstellung wieder in den Cache aufgenommen wurde. Die Standardeinstellung ist„false“.
mds standby for name
Ein MDS Daemon fungiert als Standby für einen anderen MDS Daemon mit dem Namen,der in dieser Einstellung angegeben ist.
mds standby for rank
Ein MDS Daemon fungiert als Standby für einen MDS Daemon mit diesem Rang. DerStandardwert ist -1.
mds standby replay
Angabe, ob ein Ceph MDS Daemon ein Polling für das Protokoll eines aktiven MDSdurchführen und dieses Protokoll wiedergeben soll („unmittelbar betriebsbereit imStandby-Modus“). Die Standardeinstellung ist „false“.
mds min caps per client
Mindestanzahl der Capabilities, die ein Client besitzen kann. Der Standardwert ist 100.
mds max ratio caps per client
Maximales Verhältnis der aktuellen Caps, die bei MDS-Cache-Druck abgerufen werdenkönnen. Der Standardwert ist 0.8.
METADATENSERVER-JOURNALER-EINSTELLUNGEN
journaler write head interval
Zeitabstand, in dem das Journal-Kopfobjekt aktualisiert wird. Der Standardwert ist 15.
journaler prefetch periods
Anzahl der Stripe-Zeiträume, die bei der Wiedergabe des Journals im Voraus gelesenwerden. Der Standardwert ist 10.
journal prezero periods
Anzahl der Stripe-Zeiträume bis null vor der Schreibposition. Der Standardwert ist 10.
journaler batch interval
Maximale zusätzliche Latenz (in Sekunden), die künstlich hervorgerufen wird. DerStandardwert ist 0.001.
135 Konfigurieren eines Metadata Server SES 6
journaler batch max
Maximale Datenmenge (in Byte), um die die Verschiebung verzögert wird. DerStandardwert ist 0.
11.3 CephFSWenn Ihr Ceph Storage Cluster mit mindestens einem Ceph Metadata Server ordnungsgemäßfunktioniert, können Sie Ihr Ceph-Dateisystem erstellen und einhängen. Stellen Sie sicher, dassIhr Client mit dem Netzwerk verbunden ist und über einen ordnungsgemäßen Schlüsselbundzur Authentizierung verfügt.
11.3.1 Erstellen eines CephFS
Ein CephFS benötigt mindestens zwei RADOS-Pools: einen für Daten und einen für Metadaten.Beim Kongurieren dieser Pools sollten Sie Folgendes in Erwägung ziehen:
Eine höhere Reproduktionsstufe für den Metadaten-Pool, da jeglicher Datenverlust indiesem Pool dazu führen kann, dass auf das gesamte Dateisystem nicht mehr zugegrienwerden kann.
Ein Speicher mit geringerer Latenz für den Metadaten-Pool wie SSDs, weil dadurch diebeobachtete Latenz der Dateisystemoperationen an Clients verbessert wird.
Bei der Zuweisung eines role-mds in Datei policy.cfg werden die erforderlichenPools automatisch erstellt. Sie können vor dem Einrichten des Metadata Server die Poolscephfs_data und cephfs_metadata manuell erstellen, um die Leistung manuell anzupassen.Diese Pools werden von DeepSea nicht erstellt, wenn sie bereits vorhanden sind.
Weitere Informationen zur Verwaltung von Pools nden Sie im Buch „Verwaltungshandbuch”,
Kapitel 11 „Verwalten von Speicher-Pools“.
Führen Sie die folgenden Kommandos aus, um die beiden erforderlichen Pools (z. B.„cephfs_data“ und „cephfs_metadata“) mit Standardeinstellungen für das CephFS zu erstellen:
cephadm@adm > ceph osd pool create cephfs_data pg_numcephadm@adm > ceph osd pool create cephfs_metadata pg_num
Es ist möglich, EC-Pools anstelle von reproduzierten Pools zu verwenden. Wir empfehlen,EC-Pools nur für geringe Leistungsanforderungen und gelegentlichen zufälligen Zugri zuverwenden, beispielsweise für Cold Storage, Sicherungen oder Archivierung. Für die Aktivierung
136 CephFS SES 6
von CephFS in EC-Pools ist BlueStore erforderlich und die Option allow_ec_overwrite mussfür den Pool festgelegt sein. Diese Option kann durch Ausführung des Kommandos ceph osdpool set ec_pool allow_ec_overwrites true festgelegt werden.
Ein Erasure Coding (EC) vergrößert erheblich den Overhead für Dateisystemoperationen,insbesondere kleine Updates. Dieser Overhead entsteht zwangsläug, wenn Erasure Coding alsFehlertoleranzmechanismus verwendet wird. Diese Einbuße ist der Ausgleich für einen erheblichreduzierten Speicherplatz-Overhead.
Wenn die Pools erstellt sind, können Sie das Dateisystem mit dem Kommando ceph fs newaktivieren:
cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name
Beispiel:
cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data
Durch Auisten aller verfügbarer CephFSs prüfen Sie, ob das Dateisystem erstellt wurde:
cephadm@adm > ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
Wenn das Dateisystem erstellt wurde, kann der MDS den Zustand aktiv annehmen. Beispielsweisein einem einzelnen MDS-System:
cephadm@adm > ceph mds state5: 1/1/1 up
Tipp: Weitere ThemenWeitere Informationen zu spezischen Aufgaben (beispielsweise Einhängen, Aushängenund erweiterte CephFS-Einrichtung) nden Sie im Buch „Verwaltungshandbuch”, Kapitel 19
„Cluster-Dateisystem“.
11.3.2 Größe des MDS Clusters
Eine CephFS-Instanz kann von mehreren aktiven MDS Daemons bedient werden. Alle aktivenMDS Daemons, die einer CephFS-Instanz zugewiesen sind, teilen den Verzeichnisbaum desDateisystems unter sich auf. Dadurch wird die Last gleichmäßig auf die gleichzeitig ausgeführten
137 Größe des MDS Clusters SES 6
Clients verteilt. Zum Hinzufügen eines aktiven MDS Daemon zu einer CephFS-Instanz ist einezusätzliche Standby-Instanz erforderlich. Starten Sie entweder einen zusätzlichen Daemon oderverwenden Sie eine vorhandene Standby-Instanz.
Durch das folgende Kommando wird die aktuelle Anzahl der aktiven und passiven MDS Daemonsangezeigt.
cephadm@adm > ceph mds stat
Durch die folgenden Kommandos wird die Anzahl der aktiven MDSs auf zwei proDateisysteminstanz festgelegt.
cephadm@adm > ceph fs set fs_name max_mds 2
Sie müssen zwei Schritte ausführen, um den MDS Cluster vor einem Update zu verkleinern.Legen Sie zunächst max_mds fest, damit nur noch eine Instanz vorhanden ist:
cephadm@adm > ceph fs set fs_name max_mds 1
Deaktivieren Sie danach explizit die anderen MDS Daemons:
cephadm@adm > ceph mds deactivate fs_name:rank
Dabei bezeichnet rank die Nummer eines aktiven MDS Daemons einer Dateisysteminstanz imBereich von 0 bis max_mds -1.
Es wird empfohlen, mindestens einen MDS als Standby-Daemon beizubehalten.
11.3.3 MDS Cluster und Updates
Bei Ceph Updates ändern sich möglicherweise die Feature-Einstellungen (normalerweisedurch Hinzufügen neuer Features). Nicht kompatible Daemons (wie die älteren Versionen)funktionieren nicht bei einem nicht kompatiblen Feature-Satz und starten nicht. Dies bedeutet,dass durch das Update und den Neustart eines Daemons alle anderen noch nicht aktualisiertenDaemons möglicherweise anhalten und nicht mehr starten. Aus diesem Grund empfehlen wir,vor einem Update von Ceph den aktiven MDS Cluster auf die Größe einer Instanz zu verkleinernund alle Standby Daemons anzuhalten. Die manuellen Schritte für diesen Update-Vorgang sindwie folgt:
1. Aktualisieren Sie die auf Ceph bezogenen Pakete mithilfe von zypper .
138 MDS Cluster und Updates SES 6
2. Verkleinern Sie den MDS Cluster wie oben beschrieben auf eine Instanz und halten Siealle MDS Standby Daemons an. Verwenden Sie dazu deren systemd -Einheiten in allenanderen Nodes:
cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target
3. Starten Sie erst dann den einzig verbleibenden MDS Daemon und verursachen Sie seinenNeustart anhand der aktualisierten Binärdatei.
cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target
4. Starten Sie alle anderen MDS Daemons neu und legen Sie die gewünschte Einstellungmax_mds neu fest.
cephadm@mds > systemctl start ceph-mds.target
Wenn Sie DeepSea verwenden, führt es diesen Vorgang aus, falls das ceph -Paket in Phase 0und 4 aktualisiert wurde. Es ist möglich, diesen Vorgang auszuführen, während bei Clients dieCephFS-Instanz eingehängt ist und E/A weiterhin ausgeführt wird. Beachten Sie jedoch, dasses beim Neustart des aktiven MDS eine kurze E/A-Pause gibt. Die Clients werden automatischwiederhergestellt.
Es hat sich bewährt, vor dem Aktualisieren eines MDS Clusters die E/A-Last so weit wiemöglich zu reduzieren. Ein inaktiver MDS Cluster durchläuft diesen Update-Vorgang schneller.Umgekehrt ist es auf einem sehr ausgelasteten Cluster mit mehreren MDS Daemons sehr wichtig,die Last vorher zu reduzieren, um zu verhindern, dass ein einzelner MDS Daemon durchfortlaufende E/A-Vorgänge überlastet wird.
11.3.4 Datei-Layouts
Das Layout einer Datei steuert die Zuordnung ihrer Inhalte zu Ceph RADOS-Objekten. Sie könnendas Layout einer Datei mit virtuellen erweiterten Attributen (kurz xattrs) lesen und schreiben.
Der Name des Layout-xattrs ist davon abhängig, ob eine Datei eine normale Datei oder einVerzeichnis ist. Die Layout-xattrs normaler Dateien werden als ceph.file.layout bezeichnet,die Layout-xattrs von Verzeichnissen dagegen als ceph.dir.layout . In Beispielen, die aufceph.file.layout verweisen, tragen Sie entsprechend den Teil .dir. ein, wenn Sie mitVerzeichnissen arbeiten.
139 Datei-Layouts SES 6
11.3.4.1 Layoutfelder
Die folgenden Attributfelder werden erkannt:
pool
ID oder Name eines RADOS-Pools, in dem die Datenobjekte einer Datei gespeichert werden.
pool_namespace
RADOS-Namespace in einem Daten-Pool, in den die Objekte geschrieben werden. DiesesAttribut ist standardmäßig leer, sodass der standardmäßige Namespace verwendet wird.
stripe_unit
Größe eines Datenblocks (in Byte) in der RAID-0-Verteilung einer Datei. Alle Stripe-Einheiten für eine Datei sind gleich groß. Die letzte Stripe-Einheit ist in der Regelunvollständig – sie enthält die Daten am Ende der Datei sowie den nicht belegten „Platz“nach dem Dateiende bis zum Ende der festen Größe der Stripe-Einheit.
stripe_count
Anzahl aufeinanderfolgender Stripe-Einheiten, die einen RAID-0-„Stripe“ mit Dateidatenbilden.
object_size
Größe der RADOS-Objekte (in Byte), auf die die Dateidaten blockweise aufgeteilt werden.
Tipp: ObjektgrößenRADOS erzwingt einen kongurierbaren Grenzwert für Objektgrößen. WennSie die CephFS-Objektgrößen über diesen Grenzwert hinaus erhöhen,schlagen Schreibvorgänge möglicherweise fehl. Die OSD-Einstellung lautetosd_max_object_size und liegt standardmäßig bei 128 MB. Sehr große RADOS-Objekte können den reibungslosen Betrieb des Clusters beeinträchtigen. Es wirddaher nicht empfohlen, den Grenzwert für die Objektgröße über den Standardwerthinaus zu erhöhen.
11.3.4.2 Lesen des Layouts mit getfattr
Mit dem Kommando getfattr lesen Sie die Layoutinformationen der Beispieldatei file alseinzelne Zeichenkette:
root # touch file
140 Datei-Layouts SES 6
root # getfattr -n ceph.file.layout file# file: fileceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430
So lesen Sie einzelne Layoutfelder:
root # getfattr -n ceph.file.layout.pool file# file: fileceph.file.layout.pool="cephfs_data"root # getfattr -n ceph.file.layout.stripe_unit file# file: fileceph.file.layout.stripe_unit="4194304"
Tipp: Pool-ID oder NameBeim Lesen der Layouts ist der Pool in der Regel mit seinem Namen angegeben. Wenn einPool erst vor Kurzem erstellt wurde, wird in seltenen Fällen stattdessen die ID ausgegeben.
Verzeichnisse besitzen erst dann ein explizites Layout, wenn es angepasst wird. Ein Versuch,das Layout zu lesen, schlägt fehl, wenn das Layout bislang noch nicht bearbeitet wurde. Diesbedeutet, dass das Layout des nächstgelegenen übergeordneten Verzeichnisses mit explizitemLayout verwendet wird.
root # mkdir dirroot # getfattr -n ceph.dir.layout dirdir: ceph.dir.layout: No such attributeroot # setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"
11.3.4.3 Schreiben von Layouts mit setfattr
Mit dem Kommando setfattr bearbeiten Sie die Layoutfelder der Beispieldatei file :
cephadm@adm > ceph osd lspools0 rbd1 cephfs_data2 cephfs_metadataroot # setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot # setfattr -n ceph.file.layout.stripe_count -v 8 file
141 Datei-Layouts SES 6
# Setting pool by ID:root # setfattr -n ceph.file.layout.pool -v 1 file# Setting pool by name:root # setfattr -n ceph.file.layout.pool -v cephfs_data file
Anmerkung: Leere DateiWenn die Layoutfelder einer Datei mit setfattr bearbeitet werden, muss diese Dateileer sein, da ansonsten ein Fehler auftritt.
11.3.4.4 Löschen von Layouts
Mit folgendem Kommando können Sie ein explizites Layout aus dem Beispielverzeichnis mydirentfernen und wieder zur Übernahme des Layouts vom übergeordneten Element zurückkehren:
root # setfattr -x ceph.dir.layout mydir
Ähnliches gilt, wenn Sie das Attribut „pool_namespace“ festgelegt haben und das Layout nunwieder auf den Standard-Namespace zurückgreifen soll:
# Create a directory and set a namespace on itroot # mkdir mydirroot # setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons"
# Clear the namespace from the directory's layoutroot # setfattr -x ceph.dir.layout.pool_namespace mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"
11.3.4.5 Übernahme von Layouts
Dateien übernehmen bei ihrer Erstellung das Layout ihres übergeordneten Verzeichnisses.Nachfolgende Änderungen am Layout des übergeordneten Verzeichnisses wirken sich jedochnicht auf die untergeordneten Elemente aus:
root # getfattr -n ceph.dir.layout dir
142 Datei-Layouts SES 6
# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"
# file1 inherits its parent's layoutroot # touch dir/file1root # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"
# update the layout of the directory before creating a second fileroot # setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot # touch dir/file2
# file1's layout is unchangedroot # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"
# ...while file2 has the parent directory's new layoutroot # getfattr -n ceph.file.layout dir/file2# file: dir/file2ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Dateien, die als untergeordnete Elemente des Verzeichnisses erstellt wurden, übernehmenebenfalls dessen Layout, wenn für die dazwischenliegenden Verzeichnisse keine Layoutsfestgelegt sind:
root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root # mkdir dir/childdirroot # getfattr -n ceph.dir.layout dir/childdirdir/childdir: ceph.dir.layout: No such attributeroot # touch dir/childdir/grandchildroot # getfattr -n ceph.file.layout dir/childdir/grandchild# file: dir/childdir/grandchildceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
143 Datei-Layouts SES 6
11.3.4.6 Hinzufügen eines Daten-Pools zum Metadatenserver
Bevor Sie einen Pool mit CephFS verwenden können, müssen Sie ihn zum Metadatenserverhinzufügen:
cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm > ceph fs ls # Pool should now show up.... data pools: [cephfs_data cephfs_data_ssd ]
Tipp: cephx-SchlüsselDie cephx-Schlüssel müssen dem Client den Zugri auf diesen neuen Pool gestatten.
Anschließend können Sie das Layout für ein Verzeichnis in CephFS aktualisieren und dabei denhinzugefügten Pool angeben:
root # mkdir /mnt/cephfs/myssddirroot # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir
Alle in diesem Verzeichnis erstellten neuen Dateien übernehmen nun dessen Layout undplatzieren die Daten in den soeben hinzugefügten Pool. Unter Umständen steigt die Anzahlder Objekte in primären Daten-Pool selbst dann weiterhin an, wenn die Dateien im soebenhinzugefügten Pool erstellt werden. Dies ist völlig normal. Die Dateidaten werden in dem Poolgespeichert, der im Layout angegeben ist, doch für alle Dateien wird eine kleine Metadaten-Menge im primären Daten-Pool abgelegt.
144 Datei-Layouts SES 6
12 Installation von NFS Ganesha
NFS Ganesha ermöglicht den NFS-Zugri auf das Object Gateway oder das CephFS. In SUSEEnterprise Storage 6 werden die NFS-Versionen 3 und 4 unterstützt. NFS Ganesha wird imBenutzerbereich statt im Kernel-Bereich ausgeführt und interagiert direkt mit dem ObjectGateway oder dem CephFS.
Warnung: Protokollübergreifender ZugriNative CephFS- und NFS-Clients sind nicht durch Dateisperren in Samba eingeschränktund umgekehrt. In Anwendungen, die auf der protokollübergreifenden Dateisperreberuhen, können dort Beschädigungen auftreten, wenn der Zugri auf CephFS-gestützteSamba-Freigabepfade auf andere Weise erfolgt.
12.1 Vorbereitung
12.1.1 Allgemeine Informationen
Zur erfolgreichen Bereitstellung von NFS Ganesha müssen Sie eine role-ganesha zu /
srv/pillar/ceph/proposals/policy.cfg hinzufügen. Weitere Informationen nden Sie inAbschnitt 5.5.1, „Die Datei policy.cfg“. Für NFS Ganesha muss entweder eine role-rgw odereine role-mds in der Datei policy.cfg vorhanden sein.
Es ist zwar möglich, den NFS Ganesha-Server in einem bereits vorhandenen Ceph Node zuinstallieren und auszuführen, wir empfehlen jedoch, ihn auf einem dedizierten Host mit Zugriauf den Ceph Cluster auszuführen. Die Client-Hosts sind normalerweise nicht Teil des Clusters,doch sie müssen Netzwerkzugri auf den NFS Ganesha-Server haben.
Fügen sie zur Aktivierung des NFS Ganesha-Servers zu einem beliebigen Zeitpunkt nach derersten Installation die role-ganesha zu policy.cfg hinzu und führen Sie mindestens dieDeepSea-Phasen 2 und 4 erneut aus. Weitere Informationen nden Sie in Abschnitt 5.3, „Cluster-
Bereitstellung“.
NFS Ganesha wird über die Datei /etc/ganesha/ganesha.conf konguriert, die im NFSGanesha Node vorhanden ist. Diese Datei wird jedoch bei jeder Ausführung der DeepSea-Phase 4 überschrieben. Wir empfehlen daher, die von Salt verwendeten Schablonen zubearbeiten, bei der es sich um die Datei /srv/salt/ceph/ganesha/files/ganesha.conf.j2
145 Vorbereitung SES 6
am Salt Master handelt. Detaillierte Informationen zur Kongurationsdatei nden Sie im Buch
„Verwaltungshandbuch”, Kapitel 21 „NFS Ganesha: Exportieren von Ceph-Daten über NFS“, Abschnitt 21.2
„Konfiguration“.
12.1.2 Anforderungen im Überblick
Die folgenden Anforderungen müssen erfüllt sein, bevor DeepSea-Phasen 2 und 4 zur Installationvon NFS Ganesha ausgeführt werden können:
Die role-ganesha muss mindestens einem Node zugewiesen sein.
Sie können nur eine role-ganesha pro Minion denieren.
NFS Ganesha benötigt entweder ein Object Gateway oder ein CephFS.
Auf Minions mit der Rolle role-ganesha muss das kernelgestützte NFS deaktiviertwerden.
12.2 InstallationsbeispielIn diesem Installationsbeispiel werden sowohl das Objekt Gateway als auch die CephFS FileSystem Abstraction Layers (FSAL) von NFS Ganesha verwendet.
1. Wenn Ihnen dies nicht geläug ist, führen Sie zunächst die DeepSea-Phasen 0 und 1 aus,bevor Sie mit diesem Verfahren fortfahren.
root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1
2. Bearbeiten Sie nach Ausführung der Phase 1 von DeepSea die Datei /srv/pillar/ceph/proposals/policy.cfg und fügen Sie folgende Zeile hinzu:
role-ganesha/cluster/NODENAME
Ersetzen Sie NODENAME durch den Namen eines Nodes in Ihrem Cluster.Stellen Sie außerdem sicher, dass eine role-mds und eine role-rgw zugewiesen sind.
3. Führen Sie mindestens die Phasen 2 und 4 von DeepSea aus. Wir empfehlen, dazwischenauch Phase 3 auszuführen.
146 Anforderungen im Überblick SES 6
root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3 # optional but recommendedroot@master # salt-run state.orch ceph.stage.4
4. Prüfen Sie, ob NFS Ganesha funktionsfähig ist. Stellen Sie hierzu fest, ob der NFS Ganesha-Service auf dem Minion Node ausgeführt wird:
root@master # salt -I roles:ganesha service.status nfs-ganeshaMINION_ID: True
12.3 Hochverfügbare Aktiv-Passiv-KonfigurationIn diesem Abschnitt nden Sie ein Beispiel, wie eine Aktiv-Passiv-Konguration mit zwei Nodesdes NFS Ganesha-Servers eingerichtet wird. Für die Einrichtung ist die SUSE Linux EnterpriseHigh Availability Extension erforderlich. Die beiden Nodes werden earth und mars genannt.
Wichtig: Services auf demselben ComputerServices mit eigener Fehlertoleranz und eigenem Lastenausgleich dürfen nicht auf ClusterNodes ausgeführt werden, die im Rahmen der Failover-Services isoliert werden. FührenSie Ceph Monitor-, Metadatenserver-, iSCSI- oder Ceph OSD-Services daher nicht inHochverfügbarkeits-Einrichtungen aus.
Detaillierte Informationen zu SUSE Linux Enterprise High Availability Extension nden Sie unterhttps://www.suse.com/documentation/sle-ha-15/ .
12.3.1 Standardinstallation
In dieser Einrichtung hat earth die IP-Adresse 192.168.1.1 und mars die Adresse192.168.1.2 .
Außerdem können Clients über zwei virtuelle IP-Adressen nach dem Floating-IP-Prinzip eineVerbindung mit dem Service herstellen, und zwar unabhängig davon, auf welchem physischenNode er ausgeführt wird. 192.168.1.10 wird für die Cluster-Verwaltung mit Hawk2 verwendetund 192.168.2.1 exklusiv für die NFS-Exporte. Dies erleichtert später die Anwendung vonSicherheitsbeschränkungen.
147 Hochverfügbare Aktiv-Passiv-Konfiguration SES 6
Das folgende Verfahren beschreibt das Installationsbeispiel. Weitere Informationennden Sie unter https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/
art_sleha_install_quick.html .
1. Bereiten Sie die NFS Ganesha Nodes am Salt Master vor:
a. Führen Sie die DeepSea-Phasen 0 und 1 aus.
root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1
b. Weisen Sie den Nodes earth und mars die role-ganesha in Datei /srv/pillar/ceph/proposals/policy.cfg zu:
role-ganesha/cluster/earth*.slsrole-ganesha/cluster/mars*.sls
c. Führen Sie die DeepSea-Phasen 2 bis 4 aus.
root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4
2. Registrieren Sie die SUSE Linux Enterprise High Availability Extension in earth undmars .
root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
3. Installieren Sie ha-cluster-bootstrap in beiden Nodes:
root # zypper in ha-cluster-bootstrap
4. a. Initialisieren Sie den Cluster in earth :
root@earth # ha-cluster-init
b. Lassen Sie mars dem Cluster beitreten:
root@mars # ha-cluster-join -c earth
5. Prüfen Sie den Status des Clusters. Sie sollten zwei Nodes sehen, die im Cluster hinzugefügtwurden:
root@earth # crm status
148 Standardinstallation SES 6
6. Deaktivieren Sie in beiden Nodes den automatischen Start des NFS Ganesha Service beimBooten des Systems:
root # systemctl disable nfs-ganesha
7. Starten Sie die crm -Shell im Node earth :
root@earth # crm configure
Die nächsten Kommandos werden in der crm-Shell ausgeführt.
8. Führen Sie in earth die crm-Shell aus, um die folgenden Kommandos zur Kongurationder Ressource für NFS Ganesha Daemons als Klon des Ressourcentyps „systemd“auszuführen:
crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \op monitor interval=30scrm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure# commitcrm(live)configure# status 2 nodes configured 2 resources configured
Online: [ earth mars ]
Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]
9. Erstellen Sie eine einfache IPAddr2 mit der crm-Shell:
crm(live)configure# primitive ganesha-ip IPaddr2 \params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \op monitor interval=10 timeout=20
crm(live)# statusOnline: [ earth mars ]Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth
10. Wir stellen eine Beziehung zwischen dem NFS Ganesha-Server und der Floating-IP-Adresseüber Kollokation und Anordnung her.
149 Standardinstallation SES 6
crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
11. Führen Sie das Kommando mount am Client aus, um sicherzustellen, dass die Cluster-Einrichtung vollständig ist:
root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt
12.3.2 Bereinigen der Ressourcen
Falls ein NFS Ganesha, wie zum Beispiel earth , in einem der Nodes ausfällt, beheben Siedas Problem und bereinigen Sie die Ressource. Erst nach Bereinigung der Ressource kann einFailback der Ressource zu earth ausgeführt werden, falls NFS Ganesha in mars ausfällt.
So bereinigen Sie die Ressource:
root@earth # crm resource cleanup nfs-ganesha-clone earthroot@earth # crm resource cleanup ganesha-ip earth
12.3.3 Einrichten der Ping-Ressource
Es kann vorkommen, dass der Server den Client aufgrund eines Netzwerkproblems nicht erreicht.Eine Ping-Ressource kann dieses Problem erkennen und abschwächen. Die Konguration dieserRessource ist optional.
1. Denieren Sie die Ping-Ressource:
crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \ params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \ op monitor interval=60 timeout=60 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60
host_list ist eine Liste mit IP-Adressen, die durch Leerzeichen getrennt sind. Die IP-Adressen werden regelmäßig gepingt, um nach Netzwerkausfällen zu suchen. Wenn einClient ständig Zugri auf den NFS-Server haben muss, fügen Sie ihn zu host_list hinzu.
150 Bereinigen der Ressourcen SES 6
2. Erstellen Sie einen Klon:
crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true
3. Das folgende Kommando erstellt eine Einschränkung für den NFS Ganesha-Service. DerNode wird dadurch gezwungen, zu einem anderen Node zu wechseln, wenn host_listnicht erreichbar ist.
crm(live)configure# location nfs-ganesha-server-with-ganesha-ping nfs-ganesha-clone \ rule -inf: not_defined ping or ping lte 0
12.3.4 NFS Ganesha HA und DeepSea
DeepSea unterstützt nicht die Konguration von NFS Ganesha HA. Um zu verhindern, dassDeepSea nach der Konguration von NFS Ganesha HA ausfällt, schließen Sie Starten undStoppen des NFS Ganesha-Service von DeepSea-Phase 4 aus:
1. Kopieren Sie /srv/salt/ceph/ganesha/default.sls zu /srv/salt/ceph/ganesha/ha.sls .
2. Entfernen Sie den Eintrag .service aus /srv/salt/ceph/ganesha/ha.sls , sodass siewie folgt aussieht:
include:- .keyring- .install- .configure
3. Fügen Sie die folgende Zeile zu /srv/pillar/ceph/stack/global.yml hinzu:
ganesha_init: ha
151 NFS Ganesha HA und DeepSea SES 6
12.4 Aktiv/Aktiv-KonfigurationDieser Abschnitt zeigt ein Beispiel einer einfachen NFS Ganesha-Aktiv/Aktiv-Einrichtung. Essollen zwei NFS Ganesha-Server auf demselben vorhandenen CephFS implementiert werden.Die Server bestehen aus zwei Ceph Cluster Nodes mit separaten Adressen. Die Clients müssenmanuell darauf verteilt werden. Bei einem „Failover“ in dieser Konguration muss der andereServer auf dem Client manuell ausgehängt und wieder eingehängt werden.
12.4.1 Voraussetzungen
Für die Beispielkonguration ist Folgendes erforderlich:
Aktiver Ceph Cluster. Weitere Informationen zum Implementieren und Kongurieren desCeph Clusters mit DeepSea nden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“.
Mindestens ein konguriertes CephFS. Weitere Informationen zum Implementieren undKongurieren von CephFS nden Sie in Kapitel 11, Installation des CephFS.
Zwei Ceph Cluster Nodes, auf denen NFS Ganesha implementiert ist. WeitereInformationen zum Implementieren und Kongurieren von NFS Ganesha nden Sie inKapitel 12, Installation von NFS Ganesha.
Tipp: Verwenden dedizierter ServerNFS Ganesha Nodes können Ressourcen gemeinsam mit anderen Ceph-spezischenServices nutzen. Zur Leistungssteigerung werden dennoch dedizierte Serverempfohlen.
Prüfen Sie nach der Implementierung der NFS Ganesha Nodes, ob der Cluster funktionsfähig istund die standardmäßigen CephFS-Pools vorhanden sind:
cephadm@adm > rados lspoolscephfs_datacephfs_metadata
152 Aktiv/Aktiv-Konfiguration SES 6
12.4.2 Konfigurieren von NFS Ganesha
Prüfen Sie, ob auf beiden NFS Ganesha Nodes die Datei /etc/ganesha/ganesha.conf
installiert ist. Falls die folgenden Blöcke noch nicht vorhanden sind, fügen Sie sie in dieKongurationsdatei ein, damit RADOS als Wiederherstellungs-Back-End für NFS Ganeshaaktiviert wird.
NFS_CORE_PARAM{ Enable_NLM = false; Enable_RQUOTA = false; Protocols = 4;}NFSv4{ RecoveryBackend = rados_cluster; Minor_Versions = 1,2;}CACHEINODE { Dir_Chunk = 0; NParts = 1; Cache_Size = 1;}RADOS_KV{ pool = "rados_pool"; namespace = "pool_namespace"; nodeid = "fqdn" UserId = "cephx_user_id"; Ceph_Conf = "path_to_ceph.conf"}
Die Werte für rados_pool und pool_namespace nden Sie in der bereits vorhandenen Zeilein der Konguration mit der Form:
%url rados://rados_pool/pool_namespace/...
Der Wert für die Option nodeid entspricht dem FQDN des Computers und die Werte für dieOptionen UserId und Ceph_Conf sind im bereits vorhandenen Block RADOS_URLS zu nden.
Aufgrund von Legacy-Versionen von NFS sind wir nicht in der Lage, den Kulanzzeitraumvorzeitig aufzuheben, weshalb der Neustart des Servers verlängert wird. Aus diesem Grund sindOptionen für NFS vor Version 4.2 deaktiviert. Auch der Großteil des NFS Ganesha-Cachings istdeaktiviert, da die Ceph-Bibliotheken bereits ein aggressives Caching vornehmen.
153 Konfigurieren von NFS Ganesha SES 6
Das Wiederherstellungs-Back-End „rados_cluster“ speichert seine Daten in RADOS-Objekten.Auch wenn dies keine große Datenmenge ist, soll sie doch hochverfügbar sein. Hierzu wird derCephFS-Metadaten-Pool herangezogen, in dem ein neuer Namespace „ganesha“ erstellt wird,getrennt von den CephFS-Objekten.
Anmerkung: Cluster Node-IDsDer Großteil der Konguration auf beiden Hosts ist identisch; die Option nodeid imBlock „RADOS_KV“ muss jedoch jeweils eine eindeutige Zeichenkette für die einzelnenKnoten enthalten. Standardmäßig wird nodeid als Hostname des Knotens in NFSGanesha festgelegt.
Sollen andere feste Werte verwendet werden, also nicht die Hostnamen, legen Siebeispielsweise nodeid = 'a' auf einem Knoten fest und nodeid = 'b' auf dem anderenKnoten.
12.4.3 Befüllen der Cluster-Kulanzdatenbank
Es muss gewährleistet sein, dass alle Knoten im Cluster gegenseitig sichtbar sind. Hierzu wirdein RADOS-Objekt zwischen den Hosts freigegeben. NFS Ganesha übermittelt anhand diesesObjekts den aktuellen Status im Hinblick auf einen Kulanzzeitraum.
Das Paket nfs-ganesha-rados-grace enthält ein Kommandozeilenwerkzeug zum Abfragenund Bearbeiten dieser Datenbank. Wenn das Paket nicht auf mindestens einem Knoten installiertist, installieren Sie es wie folgt:
root # zypper install nfs-ganesha-rados-grace
Mit dem Kommando werden die Datenbank erstellt und beide nodeid s hinzugefügt. In diesemBeispiel erhalten die beiden NFS Ganesha Nodes die Bezeichnung ses6min1.example.com undses6min2.example.com . Führen Sie folgendes Kommando auf einem der NFS Ganesha-Hostsaus:
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=1 rec=0======================================================ses6min1.example.com Eses6min2.example.com E
154 Befüllen der Cluster-Kulanzdatenbank SES 6
Hiermit wird die Kulanzdatenbank erstellt und sowohl „ses6min1.example.com“ als auch„ses6min2.example.com“ werden in die Datenbank aufgenommen. Das letzte Kommando gibtden aktuellen Status zurück. Bei neu hinzugefügten Hosts wird stets angenommen, dass sie denKulanzzeitraum erzwingen; bei beiden ist daher die Flagge „E“ gesetzt. Die Werte „cur“ und„rec“ zeigen die aktuelle Epoche und die Wiederherstellungsepoche, womit nachverfolgt werdenkann, welche Hosts die Wiederherstellung zu welchem Zeitpunkt durchführen dürfen.
12.4.4 Neustarten der NFS Ganesha-Services
Starten Sie auf beiden NFS Ganesha Nodes die entsprechenden Services neu:
root # systemctl restart nfs-ganesha.service
Prüfen Sie nach dem Neustart der Services die Kulanzdatenbank:
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=3 rec=0======================================================ses6min1.example.comses6min2.example.com
Anmerkung: Flagge „E“ gelöschtBeachten Sie, dass bei beiden Knoten die Flagge „E“ gelöscht ist. Dies bedeutet, dassdie Knoten den Kulanzzeitraum nicht mehr erzwingen und sich nun im normalenBetriebsmodus benden.
12.4.5 Schlussfolgerung
Sobald Sie alle obigen Schritte ausgewählt haben, können Sie das exportierte NFS von einem derbeiden NFS Ganesha-Server einhängen und normale NFS-Operationen für die Server ausführen.
In der Beispielkonguration wird vorausgesetzt, dass Sie einen NFS Ganesha-Server bei einemAusfall manuell innerhalb von 5 Minuten neu starten. Nach 5 Minuten kann der Metadatenserverdie Sitzung des NFS Ganesha-Clients abbrechen und den gesamten zugehörigen Zustandstornieren. Werden die Capabilities der Sitzung storniert, bevor der restliche Cluster in denKulanzzeitraum eintritt, können die Clients des Servers unter Umständen nicht den gesamtenZustand wiederherstellen.
155 Neustarten der NFS Ganesha-Services SES 6
12.5 Weitere InformationenWeitere Informationen nden Sie im Buch „Verwaltungshandbuch”, Kapitel 21 „NFS Ganesha:
Exportieren von Ceph-Daten über NFS“.
156 Weitere Informationen SES 6
IV Cluster-Implementierung zusätzlichzu SUSE CaaS Platform 4 (TechnologyPreview)
13 SUSE Enterprise Storage 6 zusätzlich zu SUSE CaaS Platform 4 auf einemKubernetes-Cluster 158
13 SUSE Enterprise Storage 6 zusätzlich zu SUSE CaaSPlatform 4 auf einem Kubernetes-Cluster
Warnung: Technology PreviewDie Ausführung eines containerisierten Ceph Clusters auf SUSE CaaS Platform isteine Technology Preview. Nehmen Sie keine Implementierung auf einem Produktions-Kubernetes-Cluster vor.
In diesem Kapitel wird die Implementierung von SUSE Enterprise Storage 6 in containerisierterForm zusätzlich zu SUSE CaaS Platform 4 auf einem Kubernetes-Cluster erläutert.
13.1 VorüberlegungenVor der Implementierung sind folgende Punkte zu beachten:
SUSE Enterprise Storage 6 führt Ceph in Kubernetes mithilfe des vorgeschalteten ProjektsRook aus (https://rook.io/ ).
Je nach Konguration belegt Rook unter Umständen alle nicht genutzten Datenträger aufallen Knoten in einem Kubernetes-Cluster.
Für die Einrichtung sind privilegierte Container erforderlich.
13.2 VoraussetzungenVor der Implementierung muss Folgendes vorliegen:
Ein funktionsfähiger Cluster mit SUSE CaaS Platform 4.
Worker-Knoten mit SUSE CaaS Platform 4 und einer Reihe zusätzlicher Datenträger, dieals Speicher für den Ceph Cluster angehängt sind.
158 Vorüberlegungen SES 6
13.3 Abrufen der Rook-ManifesteDer Rook-Orchestrator nutzt Kongurationsdateien im YAML-Format, sogenannte Manifeste.Die erforderlichen Manifeste benden sich im RPM-Paket rook-k8s-yaml . Führen Sie dieInstallation mit folgendem Befehl aus:
root # zypper install rook-k8s-yaml
13.4 InstallationRook-Ceph besteht aus zwei Hauptkomponenten: dem „Operator“, der durch Kubernetesausgeführt wird und die Erstellung von Ceph Clustern ermöglicht, und dem Ceph „Cluster“selbst, der vom Operator erstellt und teilweise verwaltet wird.
13.4.1 Konfiguration
13.4.1.1 Globale Konfiguration
Mit den Manifesten in dieser Einrichtung werden alle Rook- und Ceph-Komponenten imNamespace „rook-ceph“ installiert. Soll dies geändert werden, passen Sie alle Verweise auf denNamespace in den Kubernetes-Manifesten entsprechend an.
Bearbeiten Sie ggf. die Konguration der Pod-Sicherheitsrichtlinie (Pod Security Policy) incommon.yaml und beschränken Sie die Sicherheitsanforderungen von Rook, je nach den zuverwendenden Rook-Funktionen. Beachten Sie die Kommentare in der Manifestdatei.
13.4.1.2 Operatorkonfiguration
Mit dem Manifest operator.yaml wird der Rook-Operator konguriert. Änderungen sind inder Regel nicht erforderlich. Weitere Informationen nden Sie in den Kommentaren in derManifestdatei.
159 Abrufen der Rook-Manifeste SES 6
13.4.1.3 Ceph Cluster-Konfiguration
Das Manifest cluster.yaml ist für die Konguration des eigentlichen Ceph Clusters zuständig,der in Kubernetes ausgeführt wird. Eine ausführliche Beschreibung aller verfügbaren Optionennden Sie in der vorgeschalteten Rook-Dokumentation unter https://rook.io/docs/rook/v1.0/
ceph-cluster-crd.html .
Standardmäßig ist Rook für die Nutzung aller Knoten konguriert, dienicht mit node-role.kubernetes.io/master:NoSchedule behaftet sind und diekongurierten Platzierungseinstellungen befolgen (siehe https://rook.io/docs/rook/v1.0/ceph-
cluster-crd.html#placement-configuration-settings ). Im folgenden Beispiel wird diesesVerhalten deaktiviert und es werden nur die Knoten herangezogen, die explizit im Abschnittmit den Knoten angegeben sind:
storage: useAllNodes: false nodes: - name: caasp4-worker-0 - name: caasp4-worker-1 - name: caasp4-worker-2
AnmerkungStandardmäßig ist Rook für die Nutzung aller freien und leeren Datenträger auf allenKnoten als Ceph-Speicher konguriert.
13.4.1.4 Dokumentation
In der vorgeschalteten Rook-Ceph-Dokumentation unter https://rook.github.io/docs/rook/
master/ceph-storage.html nden Sie ausführliche Informationen zur Kongurationerweiterter Implementierungen. Hier nden Sie Erläuterungen zu den Grundlagen vonRook-Ceph, bevor Sie sich mit erweiterten Kongurationen beschäftigen.
Weitere Informationen zu SUSE CaaS Platform nden Sie unter https://www.suse.com/
documentation/suse-caasp .
160 Konfiguration SES 6
13.4.2 Erstellen des Rook-Operators
Installieren Sie die gängigen Rook-Ceph-Komponenten, die CSI-Rollen und den Rook-Ceph-Operator. Führen Sie hierzu folgendes Kommando auf dem SUSE CaaS Platform Master Nodeaus:
root # kubectl apply -f common.yaml -f operator.yaml
Mit common.yaml werden der Namespace „rook-ceph“, die Ceph CRDs (Custom ResourceDenition) (siehe https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-
resources/ ), mit denen Kubernetes die Ceph-Objekte erkennt (z. B. „CephCluster“), sowiedie RBAC-Rollen und die Pod-Sicherheitsrichtlinien erstellt (siehe https://kubernetes.io/docs/
concepts/policy/pod-security-policy/ ), sodass Rook in der Lage ist, die clusterspezischenRessourcen zu verwalten.
Tipp: Verwendung von hostNetwork und hostPortsWenn hostNetwork: true in der Cluster-Ressourcendenition angegeben ist, mussdie Nutzung von hostNetwork zugelassen werden. Außerdem muss die Nutzung vonhostPorts in PodSecurityPolicy zugelassen werden.
Prüfen Sie die Installation. Führen Sie hierzu kubectl get pods -n rook-ceph auf dem SUSECaaS Platform Master Node aus, beispielsweise:
root # kubectl get pods -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h
13.4.3 Erstellen des Ceph Clusters
Sobald Sie cluster.yaml gemäß Ihren Anforderungen angepasst haben, können Sie den CephCluster erstellen. Führen Sie folgendes Kommando auf dem SUSE CaaS Platform Master Nodeaus:
root # kubectl apply -f cluster.yaml
161 Erstellen des Rook-Operators SES 6
Beobachten Sie den Namespace „rook-ceph“, in dem der Ceph Cluster erstellt wird. Sie werdenso viele Ceph Monitors sehen, wie im Manifest cluster.yaml konguriert (standardmäßig 3),außerdem einen Ceph Manager und so viele Ceph OSDs, wie freie Datenträger vorhanden sind.
Tipp: Temporäre OSD-PodsBeim Bootstrapping des Ceph Clusters werden einige Pods mit dem Namen rook-ceph-osd-prepare-NODE-NAME eine Zeit lang ausgeführt und dann mit dem Status„Completed“ beendet. Wie der Name schon besagt, implementieren diese Pods die CephOSDs. Sie werden nicht gelöscht, sodass Sie ihre Protokolle nach dem Beenden einsehenkönnen. Beispiel:
root # kubectl get pods --namespace rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-mgr-a-6d48564b84-k7dft 1/1 Running 0 22hrook-ceph-mon-a-cc44b479-5qvdb 1/1 Running 0 22hrook-ceph-mon-b-6c6565ff48-gm9wz 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-ceph-osd-0-57bf997cbd-4wspg 1/1 Running 0 22hrook-ceph-osd-1-54cf468bf8-z8jhp 1/1 Running 0 22hrook-ceph-osd-prepare-caasp4-worker-0-f2tmw 0/2 Completed 0 9m35srook-ceph-osd-prepare-caasp4-worker-1-qsfhz 0/2 Completed 0 9m33srook-ceph-tools-76c7d559b6-64rkw 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h
13.5 Rook als Speicher für Kubernetes-WorkloadMit Rook können Sie drei verschiedene Speicherarten nutzen:
Objektspeicher
Der Objektspeicher stellt eine S3-API für den Speicher-Cluster bereit, mit der dieAnwendungen Daten schreiben und abrufen können. Eine ausführliche Beschreibungnden Sie in https://rook.io/docs/rook/v1.0/ceph-object.html .
Gemeinsames Dateisystem
162 Rook als Speicher für Kubernetes-Workload SES 6
Ein gemeinsames Dateisystem kann mit Lese-/Schreibberechtigungen von mehreren Podseingehängt werden. Dies ist für Anwendungen nützlich, die mithilfe eines gemeinsamenDateisystems zu einem Cluster zusammengefasst sind. Eine ausführliche Beschreibungnden Sie in https://rook.io/docs/rook/v1.0/ceph-filesystem.html .
Blockspeicher
Mithilfe des Blockspeichers können Sie Speicher für einen einzelnen Pod einhängen. Eineausführliche Beschreibung nden Sie in https://rook.io/docs/rook/v1.0/ceph-block.html .
13.6 Deinstallation von RookSo deinstallieren Sie Rook:
1. Löschen Sie alle Kubernetes-Anwendungen, die Rook-Speicher belegen.
2. Löschen Sie alle erstellten Objekt-, Datei- und/oder Blockspeicherartefakte gemäß denAnweisungen in Abschnitt 13.5, „Rook als Speicher für Kubernetes-Workload“.
3. Löschen Sie den Ceph Cluster, den Operator und die zugehörigen Ressourcen:
root # kubectl delete -f cluster.yamlroot # kubectl delete -f operator.yamlroot # kubectl delete -f common.yaml
4. Löschen Sie die Daten auf Hosts:
root # rm -rf /var/lib/rook
5. Löschen Sie ggf. die von Rook verwendeten Datenträger. Weitere Informationen ndenSie in https://rook.io/docs/rook/master/ceph-teardown.html .
163 Deinstallation von Rook SES 6
A Ceph-Wartungs-Updates auf der Grundlage vonvorgeschalteten „Nautilus“-Unterversionen
Mehrere wesentliche Pakete in SUSE Enterprise Storage 6 beruhen auf der Nautilus-Versionsserievon Ceph. Wenn das Ceph-Projekt (https://github.com/ceph/ceph ) neue Unterversionen in derNautilus-Serie veröentlicht, wird SUSE Enterprise Storage 6 aktualisiert, damit das Produktvon den aktuellen vorgeschalteten Bugxes und Funktions-Backports protiert.
In diesem Kapitel erhalten Sie einen Überblick über wichtige Änderungen in den einzelnenvorgeschalteten Unterversionen, die bereits in das Produkt aufgenommen wurden oder künftigaufgenommen werden.
Nautilus-Unterversion 14.2.4Diese Unterversion behebt einen schwerwiegenden Rückschritt, der sich in dieUnterversion 14.2.3 eingeschlichen hatte. Dieser Rückschritt hat sich nicht auf SUSE EnterpriseStorage-Kunden ausgewirkt, da wir keine Version auf der Grundlage von 14.2.3 veröentlichthatten.
Nautilus-Unterversion 14.2.3
Hier wurde eine Denial-of-Service-Schwachstelle repariert, bei der einnichtauthentizierter Client des Ceph Object Gateway einen Absturz aufgrund eines nichterkannten Ausnahmefehlers auösen konnte.
librbd-Clients auf Nautilus-Basis können nunmehr Images in Jewel-Clustern önen.
num_rados_handles wurde aus dem Object Gateway entfernt. Wenn Sie einen Wertgrößer 1 für num_rados_handles verwendet hatten, multiplizieren Sie die aktuellenParameter objecter_inflight_ops und objecter_inflight_op_bytes mit dembisherigen Wert für num_rados_handles . So erzielen Sie dieselbe Drosselung wie zuvor.
Der sichere Modus des Messenger-v2-Protokolls ist ab dieser Version nicht mehrexperimentell. Dieser Modus ist nunmehr der bevorzugte Verbindungsmodus für Monitors.
164 Nautilus-Unterversion 14.2.4 SES 6
osd_deep_scrub_large_omap_object_key_threshold wurde herabgesetzt, sodass einObjekt mit zahlreichen omap-Schlüsseln leichter erkannt wird.
Das Ceph Dashboard unterstützt nunmehr die Stummschaltung von Prometheus-Benachrichtigungen.
Nautilus-Unterversion 14.2.2
Die Kommandos mit no{up,down,in,out} wurden überarbeitet. Die Flaggen fürno{up,down,in,out} können nunmehr auf zwei Arten festgelegt werden: mit dembisherigen Befehl
ceph osd [un]set FLAG
mit dem clusterweite Flaggen festgelegt werden, sowie mit dem neuen Befehl
ceph osd [un]set-group FLAGS WHO
mit dem die Flaggen gesammelt auf der Granularität eines Crush-Knotens oder einerGeräteklasse festgelegt werden.
radosgw-admin erhält zwei Unterkommandos für die Verwaltung von abgelaufenenObjekten, die nach einem Bucket-Resharding in früheren Versionen des Object Gatewayzurückgeblieben sind. Mit einem Unterkommando rufen Sie diese Objekte ab, mit demzweiten löschen Sie sie.
In früheren Nautilus-Versionen (14.2.1 und 14.2.0) gab es ein Problem, bei dem die vonceph df gemeldete Pool-Auslastungsstatistik durch die Implementierung eines einzelnenneuen Nautilus BlueStore-OSD in einem aufgerüsteten Cluster (also in einem Cluster,der ursprünglich vor Nautilus implementiert wurde) durcheinandergebracht wurde. Biszur erneuten Bereitstellung oder Aktualisierung aller OSDs (mit ceph-bluestore-toolrepair ) sind die Werte in der Pool-Statistik niedriger als die tatsächlichen Werte.Dies wurde in Version 14.2.2 behoben, wobei der Cluster erst dann zur genaueren
165 Nautilus-Unterversion 14.2.2 SES 6
Statistik für die einzelnen Pools wechselt, wenn alle OSDs Version 14.2.2 aufweisen,mit der Blockspeicherung arbeiten und (falls sie vor Nautilus erstellt wurden) mit derReparaturfunktion aktualisiert wurden.
Der bisherige Standardwert firefly für mon_crush_min_required_version wurdedurch hammer ersetzt, sodass der Cluster eine Zustandswarnung ausgibt, wenn die CRUSH-Tunables älter sind als Hammer. Im Allgemeinen wird nach der Umstellung auf Hammer-Tunables ein Ausgleich für eine geringe Datenmenge (größer null) vorgenommen.Stellen Sie den ältesten zulässigen Client nach Möglichkeit auf hammer (oder höher) ein.Mit folgendem Kommando ermitteln Sie den derzeit ältesten zulässigen Client:
cephadm@adm > ceph osd dump | grep min_compat_client
Ist der aktuelle Wert älter als hammer , ermitteln Sie mit folgendem Kommando, ob dieseÄnderung gefahrlos durchgeführt werden kann (es dürfen keine Clients, die älter alsHammer sind, mit dem Cluster verbunden sein):
cephadm@adm > ceph features
In Hammer wurde der neuere CRUSH-Bucket-Typ straw2 eingeführt. Wenn alle Clientsmaximal so alt wie Hammer sind, können neue Funktionen verwendet werden, dieausschließlich für straw2 -Buckets unterstützt werden, beispielsweise der Modus crush-compat für das Ausgleichsprogramm (Buch „Verwaltungshandbuch”, Kapitel 10 „Ceph Manager-
Module“, Abschnitt 10.1 „Ausgleichsprogramm“).
Ausführliche Informationen zum Patch nden Sie unter https://download.suse.com/Download?
buildid=D38A7mekBz4~
Nautilus-Unterversion 14.2.1Dies war die erste Unterversion nach der ursprünglichen Nautilus-Version (14.2.0). Dieursprüngliche Version von SUSE Enterprise Storage 6 („General Availability“ oder „GA“) beruhteauf dieser Unterversion.
166 Nautilus-Unterversion 14.2.1 SES 6
Glossar
Allgemein
Admin NodeDer Node, in dem Sie das Dienstprogramm ceph-deploy zur Bereitstellung von Ceph aufOSD Nodes ausführen.
BucketPunkt, der andere Nodes in eine Hierarchie physischer Standorte aggregiert.
Wichtig: Keine Vermischung mit S3-BucketsS3-Buckets oder Container sind verschiedene Bezeichnungen für Ordner, in denenObjekte gespeichert werden.
CRUSH, CRUSH MapControlled Replication Under Scalable Hashing: Dieser Algorithmus berechnetDatenspeicherorte und bestimmt damit, wie Daten gespeichert und abgerufen werden.CRUSH benötigt eine Karte (Map) des Clusters zum pseudozufälligen Speichern und Abrufenvon Daten in OSDs mit gleichmäßiger Datenverteilung im Cluster.
Monitor Node, MONEin Cluster Node, der Karten vom Cluster-Zustand einschließlich Monitor-Karte oder OSD-Karte beibehält.
NodeEin einzelner Rechner oder Server in einem Ceph Cluster.
OSDObjektspeichergerät (Object Storage Device) oder Objektspeicherdomäne, je nach Kontext.Der ceph-osd -Daemon ist als Ceph-Komponente dafür zuständig, Objekte in einemlokalen Dateisystem zu speichern und den Zugri auf diese Objekte über das Netzwerkbereitzustellen.
167 SES 6
OSD NodeEin Cluster Node, der Daten speichert, Reproduktion, Wiederherstellung, Backlling undAusgleich der Daten verarbeitet und Überwachungsinformationen für Ceph Monitors zurVerfügung stellt, indem er andere Ceph OSD-Daemons überprüft.
PGPlatzierungsgruppe: Teilbereich eines Pools zur Leistungsanpassung.
PoolLogische Partitionen zum Speichern von Objekten wie Festplatten-Images.
RegelsatzRegeln zur Festlegung der Datenplatzierung für einen Pool.
Routing-BaumBezeichnung für ein Diagramm mit den verschiedenen Wegen, die ein Empfängerdurchlaufen kann.
Ceph-spezifische Begrie
AlertmanagerEinzelne Binärdatei, die die vom Prometheus-Server gesendeten Warnmeldungen verarbeitetund die Endbenutzer benachrichtigt.
Ceph Storage ClusterEin zentraler Satz von Speichersoftwareprogrammen, die die Daten des Benutzers speichern.Ein derartiger Satz besteht aus Ceph Monitors und OSDs.
Wird auch als „Ceph Object Store“ (Ceph-Objektspeicher) bezeichnet.
GrafanaLösung für die Datenbankanalyse und -überwachung.
PrometheusToolkit für die Systemüberwachung und die Ausgabe von Warnmeldungen.
168 SES 6
Spezielle Begrie im Zusammenhang mit dem ObjectGateway
Archiv-SynchronisierungsmodulModul, mit dem eine Object Gateway-Zone erstellt werden kann, in der der Verlauf der S3-Objektversionen abgelegt wird.
Object GatewayDie S3/Swift Gateway-Komponente für Ceph Object Store.
169 SES 6
B Aktualisierungen der Dokumentation
In diesem Kapitel nden Sie eine Liste der geänderten Inhalte seit der Freigabedes aktuellen Wartungs-Updates von SUSE Enterprise Storage 5. Sie nden dieÄnderungen, die sich auf die Cluster-Bereitstellung beziehen und auf frühereVersionen zutreen unter https://www.suse.com/documentation/suse-enterprise-storage-5/
book_storage_deployment/data/ap_deploy_docupdate.html .
Die Dokumentation wurde an folgenden Terminen aktualisiert:
Abschnitt B.1, „Wartungs-Update der Dokumentation zu SUSE Enterprise Storage 6“
Abschnitt B.2, „Juni 2019 (Freigabe von SUSE Enterprise Storage 6)“
B.1 Wartungs-Update der Dokumentation zu SUSEEnterprise Storage 6ALLGEMEINE AKTUALISIERUNGEN
Die Ausführung von rpmconfigcheck zur Vermeidung des Verlusts lokaler Änderungenwurde in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“ vorgeschlagen (https://
jira.suse.com/browse/SES-348 ).
Buch „Verwaltungshandbuch”, Kapitel 15 „Leistungsverbesserung mit dem LVM-Cache“ wurdehinzugefügt (https://jira.suse.com/browse/SES-269 ).
Kapitel 13, SUSE Enterprise Storage 6 zusätzlich zu SUSE CaaS Platform 4 auf einem Kubernetes-
Cluster wurde hinzugefügt (https://jira.suse.com/browse/SES-720 ).
FEHLERBEHEBUNGEN
Tipps zur Überwachung des Status der Cluster Nodes beim Upgrade wurden in Abschnitt 6.9,
„Upgrade des Admin Node“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?id=1154568 ).
Abschnitt 6.8.2, „Knoten-Upgrade mit dem SUSE Distribution Migration System“ (https://
bugzilla.suse.com/show_bug.cgi?id=1154438 ) hinzugefügt.
Das Kapitel zum Upgrade wurde zeitlich geordnet, Kapitel 6, Upgrade von vorigen Versionen
(https://bugzilla.suse.com/show_bug.cgi?id=1144709 ).
170 Wartungs-Update der Dokumentation zu SUSE Enterprise Storage 6 SES 6
Ein Änderungsprotokolleintrag für Ceph 14.2.4 wurde hinzugefügt (https://
bugzilla.suse.com/show_bug.cgi?id=1151881 ).
Der Pool-Name in den Beispielen in Kapitel 12, Installation von NFS Ganesha
wurde vereinheitlicht und lautet nunmehr „cephfs_metadata“ (https://bugzilla.suse.com/
show_bug.cgi?id=1148548 ).
Abschnitt 5.5.2.1, „Spezifikation“ wurde mit realistischeren Werten aktualisiert (https://
bugzilla.suse.com/show_bug.cgi?id=1148216 ).
Zwei neue Repositorys für „Module-Desktop“ wurden in Abschnitt 6.8.1, „Manuelles Knoten-
Upgrade mit der Installationsprogramms-DVD“ eingefügt, da unsere Kunden hauptsächlich mitder GUI arbeiten (https://bugzilla.suse.com/show_bug.cgi?id=1144897 ).
deepsea-cli ist kein untergeordnetes Element von deepsea in Abschnitt 5.4, „DeepSea CLI“
(https://bugzilla.suse.com/show_bug.cgi?id=1143602 ).
Ein Hinweis zur Migration von ntpd zu chronyd wurde in Abschnitt 6.1, „Vor dem Upgrade
zu beachtende Punkte“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?id=1135185 ).
Buch „Verwaltungshandbuch”, Kapitel 2 „Cluster-Verwaltung mit Salt“, Abschnitt
2.15 „Deaktivieren von abgestimmten Profilen“ (https://bugzilla.suse.com/show_bug.cgi?
id=1130430 ) hinzugefügt.
Überlegungen zur Migration des ganzen OSD Nodes wurden in Abschnitt 6.16.3, „OSD-
Implementierung“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?id=1138691 ).
Ein Punkt zur Migration von MDS-Namen wurde in Abschnitt 6.1, „Vor dem Upgrade zu
beachtende Punkte“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?id=1138804 ).
B.2 Juni 2019 (Freigabe von SUSE EnterpriseStorage 6)ALLGEMEINE AKTUALISIERUNGEN
Abschnitt 5.5.2, „DriveGroups“ wurde hinzugefügt (jsc#SES-548).
Kapitel 6, Upgrade von vorigen Versionen wurde umgeschrieben (jsc#SES-88).
Abschnitt 7.2.1, „Aktivieren von IPv6 für die Ceph Cluster-Implementierung“ wurde hinzugefügt(jsc#SES-409).
171 Juni 2019 (Freigabe von SUSE Enterprise Storage 6) SES 6
Die Blockspeicherung wurde als standardmäßiges Speicher-Back-End festgelegt (Fate-Nr. 325658).
Alle Verweise auf externe online-Dokumentation wurden entfernt und durch die relevantenInhalte ersetzt (Fate-Nr. 320121).
FEHLERBEHEBUNGEN
Informationen wurden zu AppArmor während des Upgrades in Abschnitt 6.1, „Vor
dem Upgrade zu beachtende Punkte“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?
id=1137945 ).
Informationen wurden zu CDTB-Clustern, die kein Online-Upgrade unterstützen, inAbschnitt 6.1, „Vor dem Upgrade zu beachtende Punkte“ eingefügt (https://bugzilla.suse.com/
show_bug.cgi?id=1129108 ).
Informationen zu Ceph-Services auf denselben Computern in Hochverfügbarkeits-Einrichtungen wurden in Abschnitt 12.3, „Hochverfügbare Aktiv-Passiv-Konfiguration“ eingefügt(https://bugzilla.suse.com/show_bug.cgi?id=1136871 ).
Ein Tipp zu bezuglosen Paketen wurde in Abschnitt 6.8, „Upgrade Knoten für Knoten –
Grundverfahren“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?id=1136624 ).
profile-* wurde in Tipp: Bereitstellen von Monitor Nodes ohne OSD-Profile zu definieren mitrole-storage aktualisiert (https://bugzilla.suse.com/show_bug.cgi?id=1138181 ).
Abschnitt 6.16, „Migration von profilbasierten Implementierungen zu DriveGroups“ wurdehinzugefügt (https://bugzilla.suse.com/show_bug.cgi?id=1135340 ).
Abschnitt 6.11, „Upgrade von Metadatenservern“ wurde hinzugefügt (https://bugzilla.suse.com/
show_bug.cgi?id=1135064 ).
Ein Hinweis, dass der MDS-Cluster verkleinert werden muss, wurde in Abschnitt 6.1,
„Vor dem Upgrade zu beachtende Punkte“ eingefügt (https://bugzilla.suse.com/show_bug.cgi?
id=1134826 ).
Die Kongurationsdatei wurde durch /srv/pillar/ceph/stack/global.yml ersetzt(https://bugzilla.suse.com/show_bug.cgi?id=1129191 ).
Verschiedene Teile von Buch „Verwaltungshandbuch”, Kapitel 20 „Exportieren von Ceph-Daten
mit Samba“ wurden aktualisiert (https://bugzilla.suse.com/show_bug.cgi?id=1101478 ).
172 Juni 2019 (Freigabe von SUSE Enterprise Storage 6) SES 6
master_minion.sls wurde aus Abschnitt 5.3, „Cluster-Bereitstellung“ gelöscht (https://
bugzilla.suse.com/show_bug.cgi?id=1090921 ).
Das Paket deepsea-cli wurde in Abschnitt 5.4, „DeepSea CLI“ erwähnt (https://
bugzilla.suse.com/show_bug.cgi?id=1087454 ).
173 Juni 2019 (Freigabe von SUSE Enterprise Storage 6) SES 6
