OpenShift Data Foundation verstehen

Virtual Private Cloud Klassische Infrastruktur Satellite

OpenShift Data Foundation ist eine hochverfügbare Speicherlösung, mit der Sie persistenten Speicher für Ihre containerisierten Anwendungen verwalten können.

Was ist OpenShift Data Foundation?

OpenShift Data Foundation ist eine hochverfügbare Speicherlösung, die aus mehreren Open-Source-Betreibern und Technologien wie Ceph, NooBaa und Rook. Diese Operatoren ermöglichen Ihnen die Bereitstellung und Verwaltung von Datei-, Block- und Objektspeichern für Ihre containerisierten Workloads in Red Hat® OpenShift® on IBM Cloud®-Clustern. Im Gegensatz zu anderen Speicherlösungen, bei denen Sie möglicherweise separate Treiber und Operatoren für jeden Speichertyp konfigurieren müssen, ist ODF eine einheitliche Lösung, die sich an Ihre Speicheranforderungen anpassen oder skalieren lässt. Sie können ODF auch in jedem OCP-Cluster einsetzen.

Wie funktioniert OpenShift Data Foundation?

ODF verwendet diese Einheiten, um eine virtualisierte Speicherebene zu erstellen, auf der Ihre App-Daten für hohe Verfügbarkeit repliziert werden. Da ODF Ihren zugrunde liegenden Speicher abstrahiert, können Sie mit ODF Datei-, Block- oder Objektspeicheranforderungen aus demselben zugrunde liegenden unformatierten Blockspeicher erstellen.

ODF verwendet Speicherdatenträger in Vielfachen von 3 und repliziert Ihre Anwendungsdaten über diese Datenträger. Die zugrunde liegenden Speicherdatenträger, die Sie für ODF verwenden, hängen von Ihrem Clustertyp ab.

Bei VPC-Clustern, die virtuelle Maschinen verwenden, sind die Speicher-Volumes Block Storage for VPC Speicher-Volumes.
Bei Classic- oder VPC-Clustern, die Bare-Metal-Worker verwenden, sind die Speicher-Volumes lokale Festplatten auf Ihren Bare-Metal-Worker-Knoten.
Bei Satellite Clustern handelt es sich bei den Speichervolumes entweder um lokale Festplatten auf Ihren Arbeitsknoten oder Sie können Festplatten dynamisch bereitstellen, indem Sie einen kompatiblen Blockspeichertreiber verwenden.

Kann ich OpenShift Data Foundation auf privaten VPC-Clustern installieren?

Ja, Sie können ODF auf VPC-Clustern installieren, die ausschließlich für den privaten Gebrauch bestimmt sind, beginnend mit der Cluster-Version 4.16.23_1546_openshift für CoreOS-Worker und 4.16.21_1544_openshift für RHEL-Worker.

Kann ich das OpenShift Data Foundation-Add-on in Satellite-Clustern installieren?

Anzahl Das Cluster-Add-on ist nur für Classic-und VPC-Cluster verfügbar.

Wie installiert man OpenShift Data Foundation auf Satellite?

Sie können ODF unter Satellite installieren, indem Sie eine der Satellite-Speichervorlagen verwenden. Weitere Informationen finden Sie in der Satellite-Speicherdokumentation.

odf-local: Wählen Sie diese Vorlage aus, wenn für Ihre Workerknoten lokaler Speicher verfügbar ist. Wenn Ihre Speicherdatenträger beim Ausführen von lsblk sichtbar sind, können Sie diese Platten bei der Implementierung von ODF verwenden, wenn sie unformatiert und unformatiert sind.
odf-remote: Wählen Sie diese Schablone aus, falls in Ihrem Cluster ein CSI-Treiber installiert ist. Beispiel: Der azuredisk-csi-driver-Treiber. Sie können den CSI-Treiber verwenden, um Speicherdatenträger bei der Implementierung von ODF dynamisch bereitzustellen.

Einen vollständigen Überblick über die Funktionen und Vorteile finden Sie unter OpenShift Data Foundation.

Architekturübersicht

Lesen Sie das folgende Diagramm und die Tabelle, um mehr über OpenShift Data Foundation zu erfahren.

ODF-Architekturübersicht
Zahl	ODF-Komponente	Beschreibung
1	OpenShift Data Foundation-Speicherklassen	Wenn Sie ODF einsetzen, erstellt der ODF-Operator Datei-, Block- und Objektspeicherklassen in Ihrem Cluster. Verweisen Sie auf diese Speicherklassen in Ihren PVCs und um Speicher für Ihre Apps zu beanspruchen.
2	OSD-Blockspeicher	Diese Geräte dienen der Anwendungsspeicherung in Ihrem Cluster. Jedes OSD ist ein unbearbeitetes Blockspeichergerät, bei dem es sich um eine lokale Festplatte auf Ihrem Workerknoten handeln kann oder das bei der Bereitstellung von ODF dynamisch bereitgestellt wird. In VPC-Clustern werden Ihre OSD-Blockspeichergeräte mit Hilfe des Block Storage for VPC-Treibers dynamisch bereitgestellt. In Satellite-Clustern können Sie lokale Datenträger auf Ihren Workerknoten verwenden oder Blockspeichergeräte dynamisch bereitstellen, indem Sie einen Blockspeichertreiber verwenden, der die dynamische Bereitstellung unterstützt. In klassischen Clustern sind die OSD-Blockgeräte lokale Festplatten auf den Workerknoten. Wenn Sie ODF bereitstellen, wird jedes Gerät durch einen OSD-Pod angehängt. Der gesamte Speicherplatz, der Ihren Apps zur Verfügung steht, ist gleich `osdSize` multipliziert mit `numOfOsd`.
3	Object-Storage-Daemon-(OSD)-Pods	Die OSD-Pods verwalten die Datenplatzierung und -replikation auf Ihren Speichergeräten.
4	Überwachungs-Pods (Mon-Pods)	Die Überwachungs-Pods führen eine Karte Ihres OpenShift Data Foundation-Speicherclusters und überwachen den Zustand des Speicherclusters.
5	Überwachungs-Blockspeichergerät (Mon)	Die Überwachungsspeichergeräte sind die zugrunde liegenden Speichergeräte für die Überwachungs-Pods. Jedes Überwachungsgerät ist ein unbearbeitetes Blockspeichergerät, bei dem es sich um eine lokale Festplatte auf Ihrem Workerknoten handeln kann oder das bei der Bereitstellung von ODF dynamisch bereitgestellt wird. Jedes Gerät stellt einem Überwachungs-Pod Speicherplatz zur Verfügung.

Multi-Cloud-Objekt-Gateway-Übersicht

Das Multicloud Object Gateway besteht aus dem Open-Source-Tool NooBaa und ist eine Komponente von OpenShift Data Foundation. Mit dem Multi-Cloud-Objekt-Gateway können Sie Objekte und Buckets über Cloud-Anbieter hinweg verwalten.

NooBaa-Übersicht
Zahl	Multi-Cloud-Objekt-Gateway-Komponente	Beschreibung
1	Sicherungsspeicher	Sicherungsspeicher sind s3-kompatible Objektspeicher-Buckets. Im Multi-Cloud-Objekt-Gateway können sich Ihre Sicherungsspeicher in jeder beliebigen Cloud-Umgebung befinden, unabhängig vom Anbieter. Sie können mehrere Sicherungsspeicher mit dem Multi-Cloud-Objekt-Gateway verbinden. Wenn Sie ODF bereitstellen, verwendet der Standard-Sicherungsspeicher die unbearbeiteten Blockspeichergeräte, die Sie für Ihren ODF-Speichercluster angeben. Sie können jedoch optional IBM Cloud Object Storage als Standard-Sicherungsspeicher einrichten.
2	Bucket-Klasse	Eine Bucket-Klasse besteht aus einem oder mehreren Sicherungsspeichern (Buckets) und einer Positionierungsrichtlinie. Sie können Sicherungsspeicher und Positionierungsrichtlinien konfigurieren, um Ihre Objekte standort- und cloudübergreifend zu verwalten.
3	Speicherklasse	Eine Speicherklasse im Multicloud Object Gateway ähnelt jeder anderen Kubernetes-Speicherklasse, da sie Speicherressourcenparameter definiert. Im Multi-Cloud-Objekt-Gateway geben Sie jedoch beim Erstellen einer Speicherklasse die Bucket-Klasse an, die Sie verwenden möchten. Indem Sie eine Speicherklasse aus Ihrer Bucket-Klasse erstellen, können Sie Ihre Multi-Cloud-Objekt-Gateway-Ressourcen über Namensbereiche hinweg verfügbar machen.
4	Objekt-Bucket-Claim (OBC)	Ein Objekt-Bucket-Claim (OBC) ähnelt einem Kubernetes Persistent-Volume-Claim (PVC), da Entwickler oder Speicheradministratoren OBCs erstellen können, um Speicherressourcen zu beanspruchen. Wenn Sie einen OBC erstellen, geben Sie die Speicherklasse an, die Sie verwenden möchten, und geben Sie optional einen Namen für den dynamisch erstellten Objekt-Bucket an.
5	Secret	Wenn Sie eine Objektbucketanforderung erstellen, wird auch ein geheimer Kubernetes-Schlüssel in Ihrem Cluster erstellt.
6	ConfigMap	Wenn Sie eine Objektbucketanforderung erstellen, wird auch eine ConfigMap in Ihrem Cluster erstellt.
7	Objekt-Bucket	Ein Objekt-Bucket wird dynamisch bereitgestellt, wenn Sie einen Objekt-Bucket-Claim erstellen. Der Objekt-Bucket abstrahiert einen oder mehrere Sicherungsspeicher zu einer einzigen Ressource.
8	s3-App	Eine Anwendung, die Objektspeicher verwendet.
9	Geheime Schlüsselreferenz	Eine Referenz für geheime Schlüssel ist eine Referenz auf einen geheimen Kubernetes-Schlüssel in Ihrem Cluster. Wenn Sie einen Objekt-Bucket-Claim erstellen, erstellt NooBaa einen entsprechenden geheimen Schlüssel und eine Config-Map. Dann können Sie in Ihren Apps auf den geheimen Schlüssel und die Config-Map verweisen, ohne die Anmeldeinformationen direkt in Ihre Apps aufnehmen zu müssen.
10	ConfigMap-Referenz	Eine Konfigurationszuordnungsreferenz ist eine Referenz auf eine Kubernetes-Konfigurationszuordnung in Ihrem Cluster. Wenn Sie einen Objekt-Bucket-Claim erstellen, erstellt NooBaa dynamisch einen entsprechenden geheimen Schlüssel und eine Config-Map. Sie können in Ihren Apps auf den geheimen Schlüssel und die Config-Map verweisen, ohne diese Anmeldedaten in Ihre Apps aufnehmen zu müssen.
11	Namensbereich-Ressourcen	Eine Namensbereich-Ressource ist ein s3-kompatibler Bucket. Nachdem Sie Ihrem Multi-Cloud-Objekt-Gateway Namensbereich-Ressourcen (Buckets) hinzugefügt haben, können Sie diese Buckets referenzieren, indem Sie einen Namensbereich-Bucket erstellen, der zum Lesen und Schreiben von einer oder mehreren Namensbereich-Ressourcen verwendet werden kann.
12	Namensbereich-Bucket	Ein Namensbereich-Bucket abstrahiert eine oder mehrere Namensbereich-Ressourcen im NooBaa-Namensbereich. Wenn Sie einen Namensbereich-Bucket erstellen, können Sie Lese- oder Schreibrichtlinien für die Namensbereich-Ressourcen festlegen, die Sie in Ihrem Multi-Cloud-Objekt-Gateway konfiguriert haben. So können Sie beispielsweise aus zwei Buckets bei verschiedenen Cloud-Anbietern lesen und in einen dritten Bucket in einer anderen, separaten Cloud-Umgebung schreiben.
13	Namensbereich-Bucket-Zugriffsschlüssel	Der Zugriffsschlüssel wird für den Zugriff auf Ihren Namensbereich-Bucket verwendet. Namensbereich-Buckets können mehrere Namensbereich-Ressourcen von verschiedenen Cloud-Anbietern oder On-Premise-Buckets enthalten. Der Zugriffsschlüssel für den Namensbereich-Bucket und der geheime Schlüssel werden in Ihren s3-Apps verwendet, um den Zugriff auf Ihren Namensbereich-Bucket zu konfigurieren, der dann Lese- und Schreibrichtlinien für die von Ihnen konfigurierten Namensbereich-Ressourcen definiert.
14	Geheimer Schlüssel für Namensbereich-Bucket	Der geheime Schlüssel wird für den Zugriff auf Ihren Namensbereich-Bucket verwendet. Namensbereich-Buckets können mehrere Namensbereich-Ressourcen von verschiedenen Cloud-Anbietern oder On-Premise-Buckets enthalten. Der Zugriffsschlüssel für den Namensbereich-Bucket und der geheime Schlüssel werden in Ihren s3-Apps verwendet, um den Zugriff auf Ihren Namensbereich-Bucket zu konfigurieren, der dann Lese- und Schreibrichtlinien für die von Ihnen konfigurierten Namensbereich-Ressourcen definiert.
15	Positionierungsrichtlinie	Wenn Sie eine Bucket-Klasse erstellen, müssen Sie eine Positionierungsrichtlinie angeben. Positionierungsrichtlinien definieren, wie Ihre Daten in Ihre Sicherungsspeicher geschrieben werden. Eine Spiegelungs-Positionierungsrichtlinie spiegelt Objekte über die Sicherungsspeicher in Ihrer Bucket Klasse und eine Verteilungs-Positionierungsrichtlinie verteilt die Objekte über die Sicherungsspeicher in Ihrer Bucket-Klasse.

Featureunterstützung nach Abrechnungstyp

Übersicht über den Abrechnungsplan
Funktionsunterstützung	Essentials	Erweitert
Blockspeicher	Ja	Ja
Dateispeicher	Ja	Ja
Objektspeicher	Ja	Ja
Node und Plattenausfallsicherheit	Ja	Ja
Operatorbasierte Automatisierung	Ja	Ja
Komprimierung	Ja	Ja
Lokale Momentaufnahmen und Klonen	Ja	Ja
Clusterweite Basisverschlüsselung	Ja	Ja
Erweiterte Verschlüsselung mit KMS	Nein	Ja
Regionale Disaster-Recovery mit Replikation	Nein	Ja
Standortübergreifende Cluster-Metro-Hochverfügbarkeit und Disaster-Recovery	Nein	Ja
Multi-Cluster-Metro-Hochverfügbarkeit und Disaster-Recovery	Nein	Ja

Bewährte Verfahren

In den folgenden Abschnitten finden Sie Informationen zu bewährten Verfahren bei der Installation und Verwaltung von ODF.

Planung

Planen Sie die Verteilung Ihrer Arbeitsknoten: Verteilen Sie den ODF-Cluster auf Fehlerdomänen, um hohe Verfügbarkeit sicherzustellen. Diese Verteilung trägt dazu bei, die Auswirkungen von Knotenausfällen zu minimieren und die Gesamtstabilität des Clusters aufrechtzuerhalten.
Erfüllung der Mindestspezifikationen für Workerknoten: Workerknoten, die ODF verwenden, sollten mindestens 16 vCPUs und 64GB RAM haben. Für IBM Classic-Cluster ist die empfohlene Version mb4c.32x384.3.8tb.ssd oder höher.
Standby-Host für Hochverfügbarkeit beibehalten: Um die Hochverfügbarkeit zu gewährleisten und die Ausfallzeit zu minimieren, wenn ein Host ausfällt, ist es ratsam, immer einen Standby-Host zu haben.
Erfüllen Sie die Empfehlungen für die Anzahl der Speichereinheiten pro Knoten: Planen Sie weniger als neun Speichereinheiten pro Knoten ein. Dies trägt dazu bei, potenzielle Engpässe zu vermeiden und die Effizienz des Datenzugriffs und -abrufs zu verbessern.
Empfohlene Speichereinheitengrößen und -anzahlen verwenden: Wenn Sie lokalen Speicher implementieren, verwenden Sie Plattengrößen von 4 TiB oder weniger. Es ist wichtig sicherzustellen, dass alle Platten im Cluster über alle Speicherknoten hinweg dieselbe Größe und denselben Typ haben, damit der Speicher optimal genutzt werden kann. Verwenden Sie OSDs von mindestens 512Gi.
Scale-up mit Standardreplikationsfaktor und Speicherknotenkonfiguration durchführen: In OpenShift Data Foundation (ODF) ist der Replikationsfaktor standardmäßig auf 3 gesetzt. Wenn Sie Kapazität hinzufügen, planen Sie das Hinzufügen von Speicherknoten in Vielfachen von 3.
Wählen Sie die richtige Konfiguration für Ihre Anforderungen: Remote-Speicher im Vergleich zu lokalem Speicher: Wenn Sie geringere Speicheranforderungen haben oder virtuelle Serverinstanzen verwenden, kann ferner Speicher eine bequeme und kostengünstige Option sein. Wenn Sie jedoch große Speicheranforderungen haben, wäre ein Bare-Metal-Cluster oder ein Hochleistungsspeicher mit geringer Netzwerklatenz, der lokalen Speicher verwendet, besser geeignet.
Vereinfachen Sie Ihre Bereitstellung durch die automatische Erkennungsfunktion: In klassischen oder Umgebungen mit lokalem Speicher können Sie die automatische Erkennungsfunktion nutzen, um die verfügbaren Speicherplatten in Ihrem Cluster automatisch für ODF zu identifizieren und zu konfigurieren. Diese Option macht eine manuelle Plattenauswahl überflüssig. Sofern es keine bestimmten Plattenanforderungen für die ODF-Bereitstellung gibt, optimiert die Verwendung der Funktion für automatische Erkennung den Bereitstellungsprozess und verringert das Risiko von Konfigurationsfehlern.
Metro-Speicherklassen für ODF-Installationen im fernen Speicher verwenden: Wenn Sie eine ODF-Installation ausführen, die fernen Speicher verwendet, stellen Sie sicher, dass Sie eine Speicherklasse mit dem Wert WaitForFirstConsumer für VolumeBindingMode verwenden, die die Erstellung des Block Storage verzögert, bis der erste Pod, der diesen Speicher verwendet, terminiert werden kann.
Größe Ihrer Implementierung festlegen: Für eine detaillierte Analyse des Speicherbedarfs können Sie mit dem Sizing Tool die erforderliche Speicherkapazität ermitteln. Sie können auch das offizielle Red Hat Dimensionierungstool verwenden.
Regelmäßige Sicherungen konfigurieren: Regelmäßige Backups des ODF-Clusters sind unerlässlich, um den Datenschutz zu gewährleisten und die Datenwiederherstellung im Katastrophenfall zu erleichtern. Ohne regelmäßige Sicherungen wird die Wiederherstellung von Daten nach einem Katastrophenfall erheblich schwieriger und kann zu einem permanenten Datenverlust führen.

Deployment

Verwendung dedizierter Speicherknoten planen: Verwenden Sie in Szenarios mit hoher Auslastung dedizierte Speicherknoten für ODF. Durch die Trennung der Operationen von Speicherknoten können Sie eine bessere Leistung und Skalierbarkeit für Ihre Speicherinfrastruktur erzielen.
Einrichten der regelmäßigen Überwachung der Red Hat-Konsole: Die Red Hat Konsole bietet wertvolle Einblicke in den Zustand und die Leistung Ihrer ODF-Umgebung. Es wird empfohlen, die Konsole regelmäßig zu überwachen, um über mögliche Probleme auf dem Laufenden zu bleiben. Die Konsole löst Alerts aus, wenn Probleme mit ODF erkannt werden, sodass Sie proaktive Maßnahmen ergreifen können.
Kapazitätswarnungen unverzüglich adressieren: Wenn Kapazitätswarnungen ausgegeben werden, ist es wichtig, sie umgehend zu beheben. Das Ignorieren oder Verzögern von Aktionen für diese Warnungen kann zu Einschränkungen bei der Speicherkapazität und potenziellen Unterbrechungen Ihrer Workloads führen. Behandeln Sie Kapazitätswarnungen als Chance, Ihren Speicherbedarf zu bewerten und geeignete Maßnahmen zu ergreifen, um potenzielle Probleme zu mindern.

Kapazitätserweiterung

Machen Sie sich mit den Optionen für die Kapazitätserweiterung vertraut: Für die Kapazitätserweiterung in ODF stehen zwei Optionen zur Verfügung. Die erste Option beinhaltet die Erhöhung der Kapazität durch Hinzufügen weiterer OSDs (Object Storage-Dämonen) auf vorhandenen Knoten im Cluster. Dadurch können die verfügbaren Ressourcen genutzt werden, um die Speicherkapazität zu erweitern. Die zweite Option ist die Erweiterung der Kapazität durch Hinzufügen neuer Knoten zum Cluster. Sobald die Anzahl der OSDs erhöht ist, werden die OSDs automatisch auf den neu hinzugefügten Knoten bereitgestellt.

Aktualisieren

Statusprüfungen durchführen, die Knoten ersetzen: Ersetzen Sie einen Speicherknoten nicht, wenn sich ODF nicht in einwandfreiem Zustand befindet. Bevor Sie mit dem Knotenaustausch fortfahren, überprüfen Sie immer den Allgemeinzustand von ODF. Versuchen Sie, alle Probleme zu beheben, bevor Sie den fehlerhaften Knoten ersetzen.
Halten Sie Ihre Umgebung auf dem neuesten Stand: Behalten Sie die Aktualisierung Ihrer Clusterversion auf die verfügbare Standardversion oder die neueste Version bei. Wenn Sie die Clusterversion auf dem neuesten Stand halten, stellen Sie sicher, dass Sie die neuesten Funktionen nutzen und die Kompatibilität mit anderen Komponenten in Ihrer Umgebung aufrechterhalten können.
ODF-Aktualisierungen nach Cluster-Upgrades durchführen: Führen Sie immer zuerst ein Upgrade für den Cluster-Master und den Workerknoten durch und fahren Sie dann mit dem ODF-Upgrade fort. Nach Abschluss eines Cluster-Upgrades ist es wichtig, auch ODF zu aktualisieren. Obwohl ODF sowohl die aktuelle Clusterversion (n) als auch die nächste Clusterversion (n+1) unterstützt, sollte die ODF-Version mit der Clusterversion identisch sein. Diese Ausrichtung gewährleistet eine optimale Kompatibilität.
Upgrade für Speicherknoten nacheinander durchführen: Wenn Sie ein Upgrade für Ihre Speicherknoten durchführen, ist es ein bewährtes Verfahren, die Upgrades nacheinander durchzuführen. Mit diesem sequenziellen Ansatz können Sie den Status von ODF nach jedem Knotenupgrade überprüfen und sicherstellen, dass Ihre Speicherinfrastruktur während des gesamten Prozesses in einwandfreiem Zustand bleibt. Durch das Upgrade einzelner Knoten können Sie die Auswirkungen jedes Upgrades auf ODF genau überwachen und eventuell auftretende Probleme schnell ermitteln und beheben.

Wiederherstellung

Fehlerhafte Hosts ersetzen: Im Falle einer lokalen Katastrophe wird empfohlen, einen ungesunden Cluster-Host durch einen gesunden zu ersetzen.
Befolgen Sie die Anweisungen in der Dokumentation, um OSDs wiederherzustellen.: Wenn ein OSD (Object Storage Daemon) in OpenShift Data Foundation (ODF) inaktiv wird, ist es wichtig, die empfohlenen Schritte für die Wiederherstellung auszuführen. Die bereitgestellte Dokumentation von IBM Cloud Platform enthält detaillierte Anweisungen zur Wiederherstellung eines Betriebssystems in solchen Situationen.

Deinstallieren und Entfernen

Pods und persistente Datenträger (PVs) löschen: Beim Löschen von Ressourcen, die ODF-Speicherklassen verwenden, ist es wichtig, das empfohlene Verfahren zu befolgen. Löschen Sie immer die zugehörigen Pods und PVs, die mit OF-Speicherklassen erstellt wurden, bevor Sie mit der Löschung anderer Ressourcen fortfahren.
Korrekte Bereinigungsreihenfolge befolgen: Wenn Sie ODF stilllegen oder aus Ihrem Cluster entfernen, stellen Sie sicher, dass Sie die Dokumentation befolgen, wenn Sie Ressourcen bereinigen. Löschen Sie zunächst die Ressource ocscluster, die für die Verwaltung der ODF verantwortlich ist. Nachdem die ocscluster-Ressource entfernt wurde, fahren Sie mit dem Entfernen des ODF-Add-ons aus der IBM-Konsole fort. Durch die Einhaltung dieser Reihenfolge wird ein reibungsloses und ordnungsgemäßes Entfernen von ODF aus Ihrem Cluster sichergestellt, wodurch potenzielle Probleme oder Konflikte vermieden werden.

Fehlerbehebung

Kapazitätsalerts und Schwellenwerte überprüfen: ODF generiert Kapazitätsalerts, wenn die Speicherkapazität des Clusters bestimmte Schwellenwerte erreicht. Diese Schwellenwerte werden auf 75% (fast voll) und 85% (voll) der Gesamtkapazität festgelegt. Diese Alerts geben an, dass sich die Speicherkapazität den Grenzwerten nähert und eine Aufmerksamkeit erfordert.
Allgemeine Probleme prüfen: Wenn Probleme mit OpenShift Data Foundation (ODF) auftreten, ist es hilfreich, auf die verfügbaren Runbooks zu verweisen, die Anleitungen zur Fehlerbehebung für häufig auftretende Probleme enthalten. Die Runbooks enthalten eine umfassende Liste bekannter Probleme und die entsprechenden Lösungen für ODF.

OpenShift Data Foundation bereitstellen

Prüfen Sie die Bereitstellungsoptionen für Ihren Infrastrukturanbieter.

Virtual Private Cloud (VPC)-Cluster: Sie können ODF mithilfe von Dynamic Provisioning mit Block Storage for VPC oder mit lokalen Festplatten auf Bare Metal Workern bereitstellen. Weitere Informationen finden Sie unter Bereitstellen von OpenShift Data Foundation auf VPC-Clustern.
Satellite-Cluster: Wenn Sie ODF in Satellite Clustern einsetzen möchten, können Sie die Satellite Speichervorlage verwenden. Weitere Informationen enthalten die folgenden Abschnitte.; Bereitstellen der OpenShift Data Foundation-Vorlage für dynamisch bereitgestellte Remote-Festplatten.; Bereitstellen der OpenShift Data Foundation-Vorlage für lokale Festplatten.
Klassische Cluster: Sie können ODF über lokale Festplatten auf Ihren Bare-Metal-Workerknoten bereitstellen. Weitere Informationen finden Sie unter Bereitstellen von OpenShift Data Foundation auf klassischen Clustern.