Replizierte Pools (Standard)

Die Standard-ODF-Konfiguration verwendet eine 3-Wege-Replikation. Jede Dateneinheit wird in drei Kopien auf verschiedenen Knoten gespeichert und schützt vor bis zu zwei gleichzeitigen Festplatten- oder Knotenausfällen.

• Vorteile: Einfache Architektur, schnelle Lesevorgänge, schnelle Wiederherstellung und vorhersehbare Latenz.
• Erhöhte Nutzung: 3x Rohspeicherplatz pro Byte nutzbarer Daten.

Was passiert, wenn Kopien verloren gehen ( rep3 ):

Der Parameter min_size steuert die Mindestanzahl der Kopien, die verfügbar sein müssen, bevor Ceph I/O zulässt. ODF legt standardmäßig für min_size=2 rep3-Pools fest und setzt dies über durch requireSafeReplicaSize: true. Das bedeutet, dass Lese- und Schreibvorgänge normal ablaufen, wenn 2 oder 3 Kopien verfügbar sind. Wenn nur eine Kopie verfügbar ist, blockiert Ceph die E/A, um weitere Dateninkonsistenzen zu verhindern.

Dieses Verhalten ist ein bewusster Sicherheitsmechanismus, der die Datenintegrität gegenüber der Verfügbarkeit priorisiert.

Die Zeit zwischen dem Verlust der zweiten Kopie und dem Abschluss der erneuten Replikation ist die gefährlichste. Während dieser Zeit führt ein dritter Fehler zu einem dauerhaften Datenverlust. Aus diesem Grund ist die Kapazitätsplanung wichtig, da die Geschwindigkeit der Ceph-Replikation von der verfügbaren Cluster-Bandbreite und dem freien Speicherplatz abhängt. Bei einem überlasteten oder fast vollen Cluster dauert die erneute Replikation länger, wodurch sich die Dauer der Sicherheitslücke verlängert.

Bei rep2-Pools verläuft die Entwicklung dynamischer. Wenn 1 Exemplar verloren geht, bleibt nur 1 Exemplar übrig. Bei ( min_size=2 Standard) wird die E/A auf den betroffenen PGs sofort gesperrt, bis das fehlende OSD wieder verfügbar ist oder eine neue Kopie repliziert wurde. Bei einem solchen min_size=1 Fehler läuft die E/A auf der einzigen verbleibenden Kopie weiter, doch ein zweiter Ausfall führt zu einem dauerhaften Datenverlust.

Das ODF-Add-on Red Hat OpenShift ( Kubernetes Service ) erstellt automatisch ausschließlich rep3-Pools mit ocs-storagecluster-cephblockpool. Rep2 Pools werden nicht durch das Add-on erstellt. Sie müssen manuell eine benutzerdefinierte CephBlockPool mit replicated.size: 2 und eine entsprechende StorageClass erstellen. Weitere Informationen finden Sie unter Erstellen eines benutzerdefinierten StorageClass s für die Virtualisierung.

Da rep2 eine geringere Fehlertoleranz bietet als rep3, sollten Sie prüfen, ob die Einsparungen beim Speicherplatz das erhöhte Risiko für Ihre Workload rechtfertigen.

IBM empfiehlt eine 3-Wege-Replikation für alle Virtualisierungs-Workloads in der Produktion, um die Verfügbarkeit und Datensicherheit zu gewährleisten.

Erasure-codierte Pools

Für Umgebungen, in denen die Effizienz der Speicherkapazität im Vordergrund steht, unterstützt ODF auch erasure-coded (EC) Pools. EC unterteilt Daten in k Datenblöcke und Paritätsblöcke m, wodurch der Rohspeicherbedarf im Vergleich zur Replikation reduziert wird, während gleichzeitig die Fehlertoleranz gewährleistet bleibt.

Supportstatus: Erasure Coding für RBD und CephFS in ODF ist eine Funktion in der Entwicklervorschau, die erstmals in ODF 4.20 eingeführt wurde. Die Funktionen der Entwicklervorschau werden im Produktivbetrieb nicht unterstützt. Sie fallen zudem nicht unter das Fallmanagement des Red Hat-Kundenportals. Vor der ODF- 4.20 stand nur RGW (Objektspeicher) EC als Entwicklervorschau zur Verfügung (aus der ODF- 4.16 ). Obwohl die zugrunde liegende Ceph-Speicher-Engine seit dem Luminous-Release (2017) EC-Überschreibungen für RBD unterstützt, zertifizieren der ODF-Betreiber und sein verwaltetes Bereitstellungsmodell noch keine EC-Pools für produktive Blockspeicher-Workloads. Planen Sie die Verwendung replizierter Pools ( rep2 oder rep3 ) für alle Produktions VM-Speicher ein und ziehen Sie EC-Pools nur für Nicht-Produktionsumgebungen in Betracht, in denen die Einschränkungen der Entwicklervorschau akzeptabel sind.

Die folgende Tabelle enthält einen Vergleich aller verfügbaren Pooltypen als Orientierungshilfe.

Die folgenden Listen enthalten die wichtigsten Überlegungen zum Erasure-Coding.

• EC-Pools weisen aufgrund der Paritätsberechnung und der Notwendigkeit, pro Vorgang mehr Chunks zu schreiben, eine höhere Schreiblatenz auf als replizierte Pools.
• EC-Pools liefern einen wettbewerbsfähigen sequentiellen Lesedurchsatz, weisen aber möglicherweise geringere IOPS für zufällige Schreibvorgänge auf.
• Die Anzahl der Fehlerdomänen muss mindestens k+m betragen. In einem Cluster mit drei Knoten sind nur rep2, rep3 und ec-2-1 möglich.
• Für einen Cluster mit 6 Knoten stehen alle zuvor aufgeführten Pooltypen zur Verfügung.

Pool mit einer einzigen Replik (nicht ausfallsicher, nur für Entwicklung und Tests)

Ab der ODF-Zusatzversion 4.14 unterstützt Red Hat OpenShift Kubernetes Service einen einzelnen Replikationspool ( rep1 ) über den Parameter addSingleReplicaPool. Dieser Parameter erstellt einen nicht ausfallsicheren Ceph-Blockpool ohne Datenreplikation, bei dem jeder Datenblock nur einmal gespeichert wird.

Um den Single-Replica-Pool bei der Bereitstellung von ODF zu aktivieren, verwenden Sie den folgenden Befehl

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

Dieser Befehl erstellt ein zusätzliches StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd: Einzelne Replikat-Blockspeicher mit WaitForFirstConsumer volume binding.

Der Standard- replica-3-Pool (ocs-storagecluster-cephblockpool) wird weiterhin damit erstellt. Der nicht-ausfallsichere Pool ist eine separate Option, für die man sich entscheiden kann.

Ein einzelner Replikationspool bietet die folgenden Anwendungsfälle.

• Entwicklungs- und Testumgebungen – in denen die Datendauerhaftigkeit keine entscheidende Rolle spielt und Einsparungen bei den Speicherkosten im Vordergrund stehen.
• Anwendungen mit integrierter Replikation – diese Anwendungen verwalten ihre eigene Datenredundanz auf der Anwendungsebene. Diese Anwendungen verwalten mehrere Kopien über verschiedene Knoten hinweg, was bedeutet, dass eine Replikation auf Speicherebene überflüssig ist.

Der einzelne Replikationspool bietet Null-Fehler-Toleranz. Der Ausfall einer einzelnen OSD oder eines Knotens führt zu einem dauerhaften, nicht wiederherstellbaren Datenverlust für alle Daten auf dieser OSD. Es steht keine zweite Kopie für die Wiederherstellung zur Verfügung. Die Dokumentation von IBM Cloud warnt ausdrücklich davor, dass diese Option das Risiko von Datenverlust, Datenbeschädigung und möglicher Systeminstabilität erhöht. Weitere Informationen finden Sie in der Ceph-Dokumentation.

Einschränkungen:

• Nur Blockspeicher: Dateispeicher wird nicht mit einer einzigen Replik unterstützt.
• Erfordert zusätzliche Festplatten: Mindestens eine zusätzliche nutzbare NVMe-Festplatte pro Knoten, zusätzlich zu dem, was der replica-3-Pool belegt. Ohne diese zusätzliche Festplatte werden die replica-1 OSDs nicht gestartet und der Speichercluster bleibt in einem fortlaufenden Zustand.
• Ein Pool pro Ausfalldomäne: ODF erstellt einen nicht-ausfallsicheren CephBlockPool pro Ausfalldomäne, mit Volumes, die durch die Verwendung von WaitForFirstConsumer gebunden sind, um die Datenlokalität zu überprüfen.
• Nicht empfohlen für Root-Datenträger für den Workload virtueller Maschinen: Wenn der OSD, der eine Root-Disk hostet, ausfällt, geht der Workload der virtuellen Maschine dauerhaft verloren. Verwenden Sie den nicht-ausfallsicheren Pool nur für Einweg-Datenfestplatten in Entwicklungs- oder Test-Workloads virtueller Maschinen.

Verwenden Sie für Virtualisierungs-Workloads in der Produktion stets replica-3-Pools (oder zumindest replica-2-Pools).

VMware vSAN Migrationsvergleich

Für Teams, die von VMware vSAN™ migrieren, entsprechen diese Ceph-Pool-Typen den bekannten Speicherrichtlinien von vSAN:

Wesentliche Unterschiede zu vSAN:

• Geringere Host-Mindestanforderungen: Ceph trennt das Quorum des Clusters von der Datenplatzierung. Ein rep3-Pool benötigt nur 3 Hosts, da jeder Host eine vollständige Kopie speichert. vSAN RAID-1 FTT=2 benötigt 5 Hosts.
• rep2 entspricht dem Standard vSAN RAID-1: Die meisten vSAN-Bereitstellungen nutzen FTT=1, das zwei Kopien speichert. Das rep2 von Ceph ist das direkte Äquivalent.
• ec-3-1 entspricht vSAN RAID-5: Beide verwenden ein 3+1-Layout und erreichen eine 1.33x-Nutzung, die platzsparendste Option für die Toleranz gegenüber einem einzelnen Ausfall.
• ec-4-2 Entspricht vSAN RAID-6: Beide verwenden ein 4+2-Layout und erreichen eine 1.5x-Nutzung mit Toleranz gegenüber zwei Ausfällen.
• ec-2-1 und ec-2-2 haben keine direkte Entsprechung in vSAN: Kleinere Ceph-EC-Konfigurationen mit weniger Datenblöcken, was zu einer höheren Auslastung pro Byte führt, aber weniger Hosts erfordert. Sie tauschen Speichereffizienz gegen geringere Anforderungen an die Anzahl der Hosts ein.

Planungskapazität

Berücksichtigen Sie bei der Planung Ihres ODF-Clusters den Rohspeicherbedarf der von Ihnen gewählten Datensicherungsrichtlinie. Die nutzbare Kapazität ist geringer als die gesamte NVMe-Rohkapazität.

Die Formel für die nutzbare Kapazität lautet Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor.

Siehe das folgende Berechnungsbeispiel für einen 3-Knoten-Cluster mit 8 x 3.2 TB NVMe-Laufwerken pro Knoten ( 76.8 TB roh insgesamt):

Schätzung der Kapazität der Arbeitslast einer virtuellen Maschine: Ein typischer Workload einer virtuellen Maschine mit einer Root-Disk von 30 GB und einer Daten-Disk von 100 GB benötigt 130 GB nutzbaren Speicher. Mit rep3 benötigt diese Workload auf einer virtuellen Maschine 390 GB Rohspeicherplatz. Auf dem oben genannten Cluster mit 3 Knoten könnten Sie etwa 196 Workloads virtueller Maschinen dieser Größe bereitstellen. In der Praxis sollten Sie die Ceph-Nutzung auf weniger als 75 % beschränken, um die Leistung aufrechtzuerhalten und Wiederherstellungsvorgänge zu unterstützen.

Die Ceph-Leistung nimmt mit zunehmender Clusterauslastung ab. ODF löst die Warnmeldung PrometheusCephOSDNearFull aus, sobald die Auslastung eines OSD 75 % überschreitet. Bei 85 % setzt Ceph das native nearfull OSD-Flag (mon_osd_nearfull_ratio) und ODF löst die CephOSDCriticallyFull Warnmeldung aus. Bei 90 % stoppt Ceph die Backfill- und Wiederherstellungsvorgänge für das betroffene OSD (mon_osd_backfillfull_ratio). Bei 95 % markiert Ceph das OSD full (mon_osd_full_ratio), blockiert alle Schreibvorgänge und gibt aus HEALTH_ERR. Planen Sie Ihre Kapazität so, dass die Auslastung im Normalbetrieb unter 70 % bleibt, damit bei der Wartung oder bei Ausfällen von Knoten genügend Spielraum für die Datenwiederherstellung und die Neuverteilung der Last vorhanden ist.

Um die aktuelle Cluster-Auslastung zu überprüfen, führen Sie den folgenden Befehl aus:

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

Anzahl der Worker-Knoten und Topologie

Die vom ODF-Add-on IBM Cloud verwendete Topologie des Ausfallbereichs hängt von Ihrer Clusterkonfiguration ab:

• Cluster mit mehreren Verfügbarkeitszonen (3 Verfügbarkeitszonen): Die Ausfalldomäne ist auf zone. festgelegt. Worker-Knoten sind über verschiedene Zonen verteilt, und ODF muss in Vielfachen von 3 wachsen, um das Gleichgewicht zwischen den Zonen aufrechtzuerhalten. Um optimale Verfügbarkeit, Leistung und Datensicherheit zu gewährleisten, verwenden Sie 3, 6 oder 9 Knoten im ODF-Speichercluster – jede Zone erhält die gleiche Anzahl an Knoten.
• Cluster mit einer einzigen Verfügbarkeitszone oder Cluster mit weniger als drei Verfügbarkeitszonen: Die flexible Skalierung wird automatisch aktiviert, und die Ausfalldomäne wird auf gesetzt host. Sie können mit 3 Knoten beginnen und nach und nach weitere Knoten hinzufügen.

Alle Knoten, die am ODF-Speichercluster teilnehmen, müssen Bare Metal sein. Das Mischen von virtualisierten und Bare-Metal-Knoten innerhalb desselben ODF-Clusters wird nicht unterstützt.

Bei Clustern mit mehreren Zonen: Das Hinzufügen von Knoten in einer Anzahl, die kein Vielfaches von 3 ist, führt zu einem Ungleichgewicht zwischen den Zonen. Bei 4 Knoten erhält eine Zone 2 Knoten, während die anderen jeweils 1 erhalten, was zu einer ungleichmäßigen OSD-Gewichtsverteilung, einer suboptimalen Datenplatzierung, einer ungleichmäßigen Auslastung und teilweise ungenutzten OSDs führt.

Bei Clustern mit mehreren Zonen sollten Sie stets in Vielfachen von 3 skalieren, um eine ausgewogene Zonentopologie zu gewährleisten.

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

ODF-Abonnementpläne

Wählen Sie den Tarif, der Ihren Anforderungen am besten entspricht:

• Essentials

  • Verringerte Kosten
  • Nur Bereitstellung im internen Modus
  • Unterstützt keine Notfallwiederherstellung, keine Stretch-Cluster und keine Bereitstellungen im externen Modus
  • Am besten geeignet für Test- und Entwicklungsumgebungen, Proof-of-Concepts oder kleine Implementierungen

• Erweitert

  • Umfassender Funktionsumfang, der Disaster Recovery, Stretch-Cluster, Bereitstellung im externen Modus, erweiterte granulare Verschlüsselung sowie Multi-Cluster-Unterstützung umfasst
  • Empfohlen für Virtualisierungs-Workloads in der Produktion mit virtuellen Maschinen

Beide Tarife umfassen BlueStore-Komprimierung für Blockpools, Thin Provisioning, Snapshots und Klonen. Die Unterschiede zwischen den Tarifen beziehen sich eher auf Disaster Recovery, Verschlüsselungsgranularität und Flexibilität bei der Bereitstellung als auf Funktionen zur Speichereffizienz.

ODF unterstützt Deduplizierung nur für Objektspeicher über das Multicloud Object Gateway (MCG). Die Blockspeicherung unterstützt keine Deduplizierung. Dieser Support gilt sowohl für den Essentials- als auch für den Advanced-Tarif. Die vorgelagerte Ceph-Deduplizierung für RBD bleibt experimentell und ist nicht für die Verwendung in ODF zertifiziert.

Weitere Informationen finden Sie unter ODF Essentials versus Advanced.

Speichertyp

• Wählen Sie Lokaler Speicher.
• Lokaler Speicher verwendet den lokalen NVMe-Instanzspeicher, der auf Bare Metal Worker Nodes verfügbar ist.
• NVMe-Laufwerke bieten eine geringere Latenz und eine hohe IOPS-Leistung, die für die Festplatten von Workloads auf virtuellen Maschinen erforderlich ist.

ODF-Ressourcenprofil

ODF bietet drei Ressourcenzuordnungsprofile, die die für Ceph-Dämonen reservierte CPU und den Speicher steuern.

• Lean: Minimaler Ressourceneinsatz. Das Lean-Profil eignet sich für ressourcenbeschränkte Umgebungen, Tests, Entwicklung und Proofs of Concept. Lean wird für Virtualisierungs-Workloads in der Produktion nicht empfohlen.
• Ausgewogen: Das Standardprofil auf Red Hat OpenShift Kubernetes Service. Das Profil "Ausgewogen" bietet ein Gleichgewicht zwischen Ressourcenverbrauch und Leistung für allgemeine Arbeitslasten.
• Leistung: Weist den Ceph-Daemons mehr CPU-Leistung und Arbeitsspeicher zu, wodurch das Risiko von Engpässen auf Daemon-Seite verringert wird. Ideal für Workloads mit hoher IOPS-Anzahl, eine große Anzahl virtueller Server und anspruchsvolle Anwendungen.

Verwenden Sie für Bare-Metal-Bereitstellungen mit lokalen NVMe-Laufwerken das Ressourcenprofil Performance. Bare-Metal-Knoten mit 8 oder mehr NVMe-Laufwerken pro Knoten führen zu einer hohen Anzahl an OSDs pro Host. Beim Balanced-Profil werden die CPU- und Speichergrenzen des Ceph-Daemons oft erreicht, bevor die zugrunde liegende NVMe-Hardware ausgelastet ist, was die IOPS begrenzt und die Latenz erhöht. Das Performance-Profil ist das empfohlene Mindestprofil für Produktions- Red Hat OpenShift-Virtualisierungs-Workloads auf Bare-Metal-Systemen.

Der Ressourcenbedarf, der während der ODF-Installation in der Webkonsole Red Hat OpenShift angezeigt wird, wird dynamisch auf der Grundlage der Anzahl der Cluster-OSDs berechnet. Daher benötigen Cluster mit mehr NVMe-Laufwerken proportional mehr Ressourcen. Die Werte sind nicht fest vorgegeben. Überprüfen Sie immer die in der Konsole angezeigten Anforderungen für Ihre spezifische Clusterkonfiguration.

Das Profil wird bei der Erstellung von StorageSystem über den Bildschirm " Leistung konfigurieren" in der Webkonsole Red Hat OpenShift ausgewählt. Ceph-Daemons mit unzureichender Ressourcenausstattung können zu einem versteckten Engpass werden und zu einer geringeren IOPS-Leistung oder einer höheren Latenz führen, als die zugrunde liegende Speicherhardware leisten kann.

Stimmen Sie Ihre Bare-Metal-Server-Profile mit den für das gewählte Profil angezeigten Ressourcenanforderungen ab: IBM Cloud VPC-Bare-Metal-Server-Profile.

Eine leichte Überbelegung von Ressourcen ist auf einem Bare-Metal-Server oft akzeptabel. Stellen Sie jedoch niemals deutlich weniger als die angezeigten Mindestanforderungen bereit, da dies die Leistung und Stabilität von ODF beeinträchtigt.

Anzahl der OSD-Platten pro Knoten

• Ermitteln Sie die Anzahl der lokalen NVMe-Laufwerke, die auf jedem Bare-Metal-Server verfügbar sind.
• Stellen Sie sicher, dass die Anzahl der pro Knoten konfigurierten OSDs die Anzahl der nutzbaren NVMe-Laufwerke nicht überschreitet.
• Empfohlen wird ein OSD pro NVMe-Laufwerk, um eine optimale Leistung und Fehlerisolierung zu gewährleisten.
• Stellen Sie sicher, dass die Anzahl der OSD-Festplatten in der Regel mit der Anzahl der NVMe-Laufwerke pro Bare-Metal-Knoten übereinstimmt. Die in der Benutzeroberfläche angezeigte Berechnung der Speicherkapazität spiegelt nicht die tatsächlich nutzbare Kapazität bei lokalen Speicherkonfigurationen wider und kann daher ignoriert werden.

Wenn Sie bei der Erstellung von StorageSystem s Knoten auswählen, sollten Sie vermeiden, alle Knoten im Cluster auszuwählen. Durch die Auswahl aller Knoten wird ein LVS ( LocalVolumeSet ) ohne nodeSelector. erstellt. Jeder Worker-Knoten, der dem Cluster in Zukunft hinzugefügt wird, wird von ODF automatisch erkannt, auch wenn er nicht für die Speicherung vorgesehen ist. Unerwartet erkannte Knoten müssen manuell aus dem LVS entfernt werden. Um dies zu verhindern, wählen Sie nur die Knoten in Ihrem dedizierten Storage-Worker-Pool aus oder stellen Sie sicher, dass diese Knoten vor der Erstellung von StorageSystem das Label cluster.ocs.openshift.io/openshift-storage tragen.

Standard StorageClass für den Cluster

Nach der Bereitstellung von ODF werden in der Regel folgende Dokumente erstellt: followingStorageClasses:

• ocs-storagecluster-ceph-rbd: Blocklagerung
• ocs-storagecluster-cephfs: Dateiablage
• ocs-storagecluster-ceph-rgw: Objektspeicherung

Damit Workloads automatisch den leistungsstarken, ODF-gestützten persistenten Blockspeicher ohne zusätzliche Konfiguration nutzen können, wählen Sie Ceph RADOS Block Device (RBD) als Standard-Speicherklasse aus oder legen Sie RBD (ocs-storagecluster-ceph-rbd) nach der Installation des ODF-Add-ons manuell als Standard- StorageClass für den Cluster fest.

1. RBD als Standard markieren:

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. Entfernen Sie bei Bedarf den Standardwert aus der zuvor konfigurierten Standardeinstellung:

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

ODF-Konfigurations-Checkliste

• Der Cluster enthält mindestens einen Bare-Metal-Server-Pool
• Red Hat OpenShift Version 4.17 oder höher
• Das ODF-Add-on und der Operator sind installiert und laufen
• Die Bare-Metal-Server verfügen über ausreichend nutzbare lokale NVMe-Laufwerke
• Das ausgewählte Ressourcenprofil stimmt mit der Knotenkapazität überein
• Ein ODF-Speichercluster besteht aus mindestens 3 Knoten; Cluster mit mehreren Zonen müssen ein Vielfaches von 3 haben (3, 6, 9, …) um das Zonen-Gleichgewicht aufrechtzuerhalten
• Alle teilnehmenden ODF-Knoten sind Bare Metal
• Die RBD StorageClass wird erstellt und vorzugsweise als Standard eingestellt
• Der Status des ODF-Clusters lautet Bereit (oc get storagecluster -n openshift-storage)
• Der Ceph-Zustand ist HEALTH_OK (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

Voraussetzungen: Installieren Sie den Virtualisierungsoperator Red Hat OpenShift

Bevor Sie Red Hat OpenShift-Virtualisierung auf IBM Cloud nutzen, stellen Sie sicher, dass der Virtualisierungsoperator Red Hat OpenShift in Ihrem Red Hat OpenShift- Kubernetes Service-Cluster installiert ist.

Der Virtualisierungsoperator Red Hat OpenShift ermöglicht die Verwaltung von Workloads auf virtuellen Maschinen, die für Kubernetes nativ sind. Außerdem bietet es die erforderlichen Controller, CRDs und Integrationen mit Speicher- und Netzwerkkomponenten.

Weitere Informationen finden Sie unter Red Hat OpenShift Virtualisierung auf IBM Cloud.

Verwendung von ODF-Speicher für Arbeitslasten virtueller Maschinen

Red Hat OpenShift Data Foundation (ODF) bietet persistenten, softwaredefinierten Speicher für Virtualisierungs-Workloads, die auf Red Hat OpenShift ausgeführt werden. Wenn Sie ODF als Speicher-Backend für virtuelle Maschinen verwenden, ist die Auswahl der richtigen StorageClass entscheidend, um Leistung, Stabilität und vollständige Funktionskompatibilität zu gewährleisten.

Sie müssen in den folgenden Situationen die entsprechenden StorageClass angeben:

• Virtuelle Server werden erstellt
• Virtuelle Server werden importiert oder geklont
• Virtuelle Server werden auf einen Red Hat OpenShift-Cluster migriert Kubernetes Service

Standard-Virtualisierung StorageClass

Wenn der Red Hat OpenShift Virtualization Operator installiert ist und ein ODF-Cluster verfügbar ist, wird automatisch ein für Virtualisierungs-Workloads optimiertes StorageClass erstellt:

• ocs-storagecluster-ceph-rbd-virtualization

Dies ist StorageClass:

• Abgestimmt auf Festplatten-E/A-Muster wie zufällige Lese- und Schreibvorgänge und anhaltenden Durchsatz
• Validiert für Virtualisierungs-Lebenszyklusvorgänge wie Start, Stopp, Live-Migration und Snapshots
• Vollständig unterstützt und empfohlen für Produktionsumgebungen Red Hat OpenShift Virtualisierung

Für die meisten Anwendungsfälle können Sie diese StorageClass ohne Änderungen verwenden.

Speicherbedarf für die Live-Migration

Bei der Live-Migration wird ein laufender Workload einer virtuellen Maschine ohne Ausfallzeit von einem Arbeitsknoten auf einen anderen verlagert. Für eine erfolgreiche Live-Migration muss der Speicher sowohl von den Quell- als auch von den Zielknoten gleichzeitig zugänglich sein. Für die Live-Migration sind die folgenden Konfigurationen erforderlich.

• ReadWriteMany Zugriffsmodus auf PVCs zur Auslastung virtueller Maschinen. Ceph RBD unterstützt RWX im Blockmodus, der die Standardkonfiguration für die ODF-Virtualisierung ist StorageClass.
• Der StorageClassocs-storagecluster-ceph-rbd-virtualization ist für die Unterstützung ReadWriteMany im RBD-Blockmodus vorkonfiguriert. Virtuelle Server, die diese StorageClass verwenden, können ohne zusätzliche Konfiguration migriert werden.
• Der generische ocs-storagecluster-ceph-rbd StorageClass verwendet standardmäßig den Zugriffsmodus ReadWriteOnce. Virtuelle Server, die RWO-PVCs verwenden, können keine Live-Migration durchführen. Die Migration schlägt fehl, weil die PVC nicht auf dem Zielknoten eingehängt werden kann, während sie an der Quelle angeschlossen ist.

Wenn Sie customStorageClasses für virtuelle Server erstellen, die eine Live-Migration erfordern, stellen Sie sicher, dass die PVCs mit accessModes: [ReadWriteMany] und erstellt werden volumeMode: Block.

Eine Live-Migration ist ebenfalls erforderlich:

• Konfigurieren des Red Hat OpenShift Virtualization Operator mit einer geeigneten Migrationsrichtlinie
• Überprüfung, ob auf dem Zielknoten genügend CPU und Speicher verfügbar sind

Virtualisierungsspezifisch im Vergleich zu allgemeinem RBD StorageClass

Obwohl virtuelle Maschinen ein generisches Ceph-RBD- StorageClass, verwenden können, ist das virtualisierungsspezifische StorageClass für die besonderen I/O- und Lebenszyklusmerkmale von Festplatten in virtuellen Maschinen optimiert.

Allgemeine RBD- StorageClasses en eignen sich weiterhin für Container-Workloads, für Produktions-Virtualisierungsumgebungen wird jedoch die virtualisierungsspezifische StorageClass empfohlen.

Erstellen einer benutzerdefinierten StorageClass für die Virtualisierung

In einigen Szenarien benötigen Sie möglicherweise eine benutzerdefinierte StorageClass, um bestimmte Anforderungen an Leistung, Ausfallsicherheit oder Kapazität zu erfüllen.

Um eine benutzerdefinierte StorageClass-Anforderung zu erstellen, müssen Sie zunächst eine benutzerdefinierte CephBlockPool erstellen. Wenn Sie einen benutzerdefinierten Pool erstellen, müssen Sie targetSizeRatio für den Pool festlegen. Ohne diese Einstellung weist der Ceph-Platzierungsgruppen-Autoscaler dem Pool nur eine Platzierungsgruppe zu. Diese Zuweisung führt dazu, dass der gesamte Ein-/Ausgabedurchsatz auf einem einzelnen OSD gebremst wird, was zu einer schlechteren Leistung als beim Standard-Pool führt.

Wenn Sie eine benutzerdefinierte StorageClass für Virtualisierungs-Workloads erstellen, stellen Sie sicher, dass die folgenden Parameter richtig konfiguriert sind.

• Bereitsteller (Provisioner)

  StorageClass muss den von ODF bereitgestellten Ceph-RBD-CSI-Provisioner verwenden:

  openshift-storage.rbd.csi.ceph.com
  

  Dieser Provisioner ermöglicht die dynamische Bereitstellung von Ceph RBD-Volumes, die durch den ODF-Cluster gesichert werden.

• Speicherpool

  Geben Sie die CephBlockPool an, die die Workload-Festplatten der virtuellen Maschine sichert. Sie können eine der folgenden Optionen auswählen:

  • Standard-Blockpool. Der standardmäßige 3-fach replizierte Ceph-Blockpool, der von ODF erstellt wird:

      ocs-storagecluster-cephblockpool
      ```
  
  - Kundenspezifischer Blockpool. Eine benutzerdefinierte CephBlockPool. Der Pool muss die folgenden Einstellungen enthalten, um Leistungseinbußen zu vermeiden:
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• Bildmerkmale

  Die Website StorageClass muss RBD-Bildmerkmale enthalten, die für die Arbeitslastleistung entscheidend sind:

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  RBD-Bildmerkmale und ihr Zweck

  Feature	Zweck
  exclusive-lock	Ermöglicht die Zwischenspeicherung von Schreibvorgängen und die Optimierung von Einzelschreibern. Ohne diese Funktion kann die IOPS-Schreibgeschwindigkeit bis zu 7x schlechter sein.
  object-map	Ermöglicht Bitmap-Tracking von zugewiesenen Objekten für spärliche Bilder.
  fast-diff	Beschleunigt Snapshot-Diff- und DataVolume Clone-Vorgänge für kürzere Bootzeiten.
  deep-flatten	Macht Klone völlig unabhängig, nachdem sie abgeflacht wurden.
  layering	Ermöglicht das Copy-on-Write-Klonen, das für DataVolume cloning erforderlich ist.

• Kartenoptionen

  mapOptions: krbd:rxbounce
  

  Diese Option behebt Probleme mit beschädigten Daten, die auftreten, wenn Sie den RBD-Kernel-Treiber mit virtuellen Windows-Servern verwenden. Dadurch wird der Kernel gezwungen, einen Bounce-Puffer für empfangene Daten zu verwenden, um die Kompatibilität sicherzustellen. Diese Option muss auf allen Workload- StorageClasses festgelegt werden.

• Vollständige benutzerdefinierte StorageClass Beispiel

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  Um die clusterID für Ihren Cluster zu finden, führen Sie den folgenden Befehl aus:

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  Für Pools mit Löschcodierung (nur Entwickler-Vorschau) siehe Grundlagen zum Datenschutz; fügen Sie hinzu, dataPool dass auf den EC-Pool verwiesen wird, und lassen Sie den Verweis pool auf den standardmäßig replizierten Pool bestehen:

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

Komprimierung

ODF unterstützt BlueStore Inline-Komprimierung auf Ceph-Blockpools, wodurch der von den Festplatten verwendete Rohspeicher reduziert werden kann. Die Komprimierung erfolgt transparent auf der OSD-Ebene, sodass die Workload der virtuellen Maschine und ihr Gastbetriebssystem nicht bemerken, dass die Daten komprimiert werden.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

Verschlüsselung

ODF unterstützt Data-at-Rest-Verschlüsselung auf mehreren Ebenen, die Sie unabhängig voneinander aktivieren können.

• IBM Cloud Infrastrukturverschlüsselung: Vollständige Festplattenverschlüsselung auf physischen NVMe-Laufwerken – verwaltet von IBM Cloud.
• Clusterweite ODF-Verschlüsselung: Alle Ceph-OSD-Festplatten werden auf Geräteebene mit dm-crypt verschlüsselt. Aktiviert über encryption.clusterWide: true im Speichercluster-CR. Schützt vor physischem Datenträgerdiebstahl.
• ODF-Verschlüsselung pro Volume: Einzelne RBD-Volumes werden mit LUKS2 verschlüsselt, wobei jedes Volume über einen eigenen Datenverschlüsselungsschlüssel verfügt. Bietet Mandantenisolierung und detaillierte Schlüsselverwaltung.

Auf Red Hat OpenShift Kubernetes Service ist ODF mit IBM Key Protect als externer Schlüsselverwaltungsdienst sowohl für die clusterweite als auch für die volumenbezogene Verschlüsselung integriert. Wenn die Verschlüsselung pro Datenträger aktiviert ist, erstellt ODF automatisch -encrypted StorageClass Varianten (zum Beispiel ocs-storagecluster-ceph-rbd-encrypted).

Ceph-Leistungsoptimierung für NVMe-Bare-Metal-Systeme

Die Standardkonfiguration von Ceph ist auf allgemeine Workloads abgestimmt. Die folgenden Parameterwerte wurden für das mx2d.metal.96x768 Bare-Metal-Profil validiert und erhöhen die IOPS erheblich sowie verringern die Latenz für VM-Festplatten-Workloads auf diesem Profil. Wenn Sie ein anderes Bare-Metal-Profil verwenden, betrachten Sie diese Angaben als Ausgangsbasis und passen Sie die Werte entsprechend der Anzahl der NVMe-Laufwerke und der verfügbaren CPU-Leistung Ihres spezifischen Profils an.

Wenden Sie jeden Parameter mithilfe des Befehls ceph config set aus dem Ceph-Toolbox-Pod an:

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

Überprüfen Sie nach der Anwendung, ob die Konfiguration akzeptiert wurde:

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

OSD-Pods müssen bei Änderungen ceph config set nicht neu gestartet werden. Ceph wendet die Konfiguration dynamisch an. BlueStore-Cache-Änderungen (osd_memory_target) werden jedoch erst nach dem Recycle jedes OSD-Pods vollständig wirksam. Sie können OSD-Pods während eines Wartungsfensters einzeln wiederverwenden, ohne den I/O-Betrieb zu unterbrechen.

Benchmark-Referenz: Interne Tests auf einem Cluster mx2d.metal.96x768 mit 3 Knoten, 200 VMs und unbegrenzten IOPS zeigten, dass die Kombination aus 16 Shards, 8 GB OSD-Speicher und einem 256 MB großen Schreibpuffer für RocksDB etwa 194.000 IOPS und einen Durchsatz von 758 MB/s erreichte. Die Erhöhung der Shards von 8 auf 16 führte in allen Testkonfigurationen durchweg zur größten Einzelverbesserung bei den IOPS.

Snapshot-basierte Sicherung

ODF unterstützt Kubernetes VolumeSnapshots für Ceph RBD-Volumes. Um einen Snapshot einer Festplatte zu erstellen, verwenden Sie den folgenden Befehl:

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots werden beim Schreiben kopiert und können fast sofort erstellt werden. Sie können diese nutzen, um die Workload einer virtuellen Maschine in einen früheren Zustand zurückzusetzen oder eine Festplatte zu klonen. Die Red Hat OpenShift-Virtualisierung bietet zudem eine integrierte VM-Snapshot- und Wiederherstellungs-API, die den vollständigen Zustand der Workload einer virtuellen Maschine – einschließlich der Konfiguration und aller Festplatten – in einem einzigen Vorgang erfasst.

Ruhigstellen von Arbeitslasten virtueller Maschinen für anwendungskonsistente Snapshots

Wenn Sie einen Snapshot einer laufenden Workload auf einer virtuellen Maschine erstellen, müssen sich die Daten auf der Festplatte in einem konsistenten Zustand befinden. Ohne Quiescing erfasst der Snapshot alles, was sich zu diesem Zeitpunkt auf der Festplatte befindet, einschließlich teilweise geschriebener Transaktionen, verschmutzter Puffer und laufender E/A. Dieser Vorgang erzeugt einen absturzkonsistenten Snapshot, der bei der Wiederherstellung möglicherweise eine Wiederherstellung auf Anwendungsebene erfordert.

Um anwendungskonsistente Snapshots zu erstellen, frieren Sie das Gastdateisystem vor der Erstellung des Snapshots ein und tauen Sie es anschließend wieder auf. Red Hat OpenShift Virtualization automatisiert diesen Vorgang mithilfe des QEMU-Gastagenten.

Der Snapshot-Controller erkennt den QEMU-Gastagenten. Vor der Erstellung des Snapshots wird ein Befehl guest-fsfreeze-freeze ausgegeben, der alle E/A-Vorgänge des Dateisystems unterbricht. Der VolumeSnapshot wird erstellt, während das Dateisystem gesperrt ist. Nach Beendigung des Snapshots wird die E/A mit dem Befehl guest-fsfreeze-thaw wieder aufgenommen. Der Snapshot-Status gibt den erreichten Konsistenzgrad an. Die Bedeutung der einzelnen Statusangaben entnehmen Sie bitte der folgenden Tabelle.

Die Installation des QEMU-Gastagenten wird für alle Produktions-VMs empfohlen. Verwenden Sie auf Linux-Gästen den folgenden Befehl.

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Für Windows-Gäste installieren Sie das Treiberpaket VirtIO, das den QEMU-Gastagenten-Dienst enthält.

Benutzerdefinierte Freeze-/Thaw-Hooks für Anwendungen: Für Datenbanken und andere zustandsbehaftete Anwendungen, die über das Einfrieren des Dateisystems hinausgehende zusätzliche Ruhephasen erfordern, platzieren Sie benutzerdefinierte Hook-Skripte innerhalb der Workload der virtuellen Gastmaschine unter /etc/qemu-ga/fsfreeze-hook.d/. Diese Skripte werden vom Gast-Agenten automatisch mit einem Argument freeze vor dem Einfrieren des Dateisystems und einem thaw Argument nach dem Auftauen des Dateisystems ausgeführt. Die Protokolle der Hook-Ausführung werden auf /var/log/qga-fsfreeze-hook.log geschrieben.

Zum Beispiel kann der folgende PostgreSQL Einfrierhaken unter /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh platziert werden:

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware Vergleich: Dieses Beispiel entspricht dem Skript VMware für die Phasen vor dem Einfrieren und nach dem Auftauen, das mit VMware Tools für anwendungskonsistente Snapshots verwendet wird. Der QEMU-Gastagent erfüllt dieselbe Funktion wie die VMware-Tools für das Einfrieren von Snapshots.

Geänderte Einschränkungen beim Block Tracking

Changed Block Tracking ermöglicht inkrementelle Backups, indem nur die Blöcke identifiziert werden, die sich seit dem letzten Backup geändert haben. Das VADP ( vStorage APIs for Data Protection) von VMware nutzt diesen Mechanismus, um effiziente inkrementelle Backups zu ermöglichen.

CBT ist nicht verfügbar für ODF und Ceph RBD auf Red Hat OpenShift Virtualization. Backups basieren derzeit auf vollständigen Snapshots, was zu längeren Backup-Fenstern und einem höheren Speicherbedarf führen kann.

Die Entwicklung von CBT ist auf mehreren Ebenen im Gange:

Obwohl Ceph RBD die zugrunde liegende Funktion rbd diff zur Identifizierung geänderter Blöcke zwischen Snapshots unterstützt, wird diese Funktion noch nicht über die Kubernetes-CSI-API zur Nachverfolgung geänderter Blöcke bereitgestellt. Solange der komplette Stack noch nicht vorhanden ist (CSI CBT API + Ceph CSI Treiberunterstützung + KubeVirt Integration), sind inkrementelle Backups auf Blockebene nicht möglich.

Backup-Lösungen

Mehrere Backup-Anbieter bieten Lösungen für die Virtualisierung von Red Hat OpenShift an, die im Rahmen des aktuellen Snapshot-basierten Modells funktionieren:

• Veeam® Kasten: Kubernetes-native Datensicherung mit Red Hat OpenShift Virtualisierungsunterstützung und inkrementellen Snapshot-Funktionen für ODF. Weitere Informationen finden Sie in der Veeam Kasten Referenzarchitektur.
• Trilio für Kubernetes: Backup und Wiederherstellung für Red Hat OpenShift Virtualisierungs-Workloads mit ODF-Integration. Weitere Informationen finden Sie unter Trilio Red Hat OpenShift Virtualisierungsunterstützung.
• Veritas NetBackup: Enterprise Backup mit Red Hat OpenShift Virtualisierungsunterstützung. Weitere Informationen finden Sie unter NetBackup – Umfassender Datenschutz für Unternehmen.

Empfehlungen für VMware Migrationen

Wenn Ihre aktuelle VMware Umgebung auf CBT-basierte inkrementelle Backups setzt, sollten Sie die folgenden Empfehlungen berücksichtigen:

• Planen Sie vollständige Snapshot-Backups ein. Bewerten Sie Ihre Backup-Fenster und Speicheranforderungen auf der Grundlage von Voll VolumeSnapshots s statt inkrementellen Backups.
• Bewerten Sie die Kubernetes-eigenen Backup-Tools. Veeam Kasten und Trilio sind für die Virtualisierung von Kubernetes und Red Hat OpenShift konzipiert und arbeiten im Rahmen des aktuellen Snapshot-Modells.
• Verwenden Sie die Ceph-Snapshot-Effizienz. Ceph-RBD-Snapshots basieren auf dem Copy-on-Write-Prinzip und belegen nach der Erstellung des Snapshots nur Speicherplatz für geänderte Blöcke, wodurch die fortlaufende Speicherung von Snapshots effizienter ist als bei vollständigen Kopien.

Überwachen Sie den Zustand von ODF und Ceph

Die regelmäßige Überwachung des ODF-Storage-Clusters ist für die Aufrechterhaltung der Verfügbarkeit und Leistung unerlässlich. Im folgenden Abschnitt werden wichtige Befehle und deren Ausgaben beschrieben.

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

ODF aktualisieren auf Red Hat OpenShift Kubernetes Service

Das Add-on IBM Cloud für Red Hat OpenShift Data Foundation (ODF) wendet z-stream-Updates innerhalb derselben Minor-Version automatisch an. Diese Aktualisierungen werden über IBM Cloud verwaltet.

Major- und Minor-Versions-Upgrades (zum Beispiel von 4.18 auf 4.19 ) erfolgen jedoch nicht automatisch. Befolgen Sie die Anleitung zum manuellen Upgrade, um die Datensicherheit und die Stabilität des Clusters zu gewährleisten.

Die Aktualisierung von ODF auf einem Red Hat OpenShift Kubernetes Service Cluster besteht aus zwei Hauptphasen, die beide für eine erfolgreiche Aktualisierung erforderlich sind.

1. Aktualisieren oder ersetzen Sie ODF-Arbeitsknoten.

   • ODF stützt sich auf dedizierte oder gekennzeichnete Arbeitsknoten, um Speicherkomponenten zu hosten.
   • Bei einem größeren oder kleineren Upgrade müssen diese Worker Nodes aktualisiert oder ersetzt werden, um sie an die Zielversion von Red Hat OpenShift und ODF anzupassen.
   • Dieser Prozess stellt sicher, dass ODF-Pods (wie Ceph OSDs, MONs und Manager) korrekt umgeplant werden und ohne Datenverlust weiter funktionieren.
   • Stellen Sie vor Beginn dieses Schritts sicher, dass ausreichende Kapazitäten vorhanden sind und die Knoten einwandfrei funktionieren, um die Verfügbarkeit des Speichers zu gewährleisten.

2. Aktualisieren Sie das ODF-Add-on.

   • Nachdem die Arbeitsknoten aktualisiert oder ersetzt wurden, aktualisieren Sie das ODF-Add-on.
   • In diesem Schritt werden die ODF-Operatoren, CSI-Treiber und zugehörige Komponenten auf die Zielversion aktualisiert.
   • Nach Abschluss des Add-on-Updates gleicht der Cluster automatisch die ODF-Ressourcen ab und wendet die erforderlichen Änderungen an.

   Führen Sie nach dem Upgrade eine Validierung durch, um Folgendes zu überprüfen:

   • ODF und Ceph-Cluster-Gesundheit
   • StorageClasses verfügbarkeit
   • Erfolgreiche PVC-Lese- und Schreibvorgänge durch Anwendungen

Weitere Informationen finden Sie unter Aktualisieren von ODF auf VPC-Clustern.

Erweiterung des ODF-Speichers auf Red Hat OpenShift Kubernetes Service

Dementsprechend wird es mit zunehmendem Arbeitsaufkommen und steigendem Speicherbedarf unerlässlich, Ihre Speicherinfrastruktur zu skalieren. Die Erweiterung in ODF ist eine wichtige Day-2-Operation, die es Ihnen ermöglicht, die Speicherkapazität zu erhöhen, die Leistung zu verbessern und die Ausfallsicherheit aufrechtzuerhalten, ohne die laufenden Anwendungen zu unterbrechen.

In IBM Cloud Red Hat OpenShift Kubernetes Service Umgebungen beinhaltet die Erweiterung in der Regel die Erweiterung des Storage Worker Pools. Dieser Vorgang wird mit minimaler Ausfallzeit durchgeführt und ermöglicht ein nahtloses Wachstum Ihres Speicher-Clusters.

1. Fügen Sie Ihrem VPC-Cluster Worker-Knoten hinzu. Bei Clustern mit mehreren Zonen, bei denen sich der Speichercluster über drei Verfügbarkeitszonen erstreckt, sollten Sie Worker-Knoten in Vielfachen von 3 hinzufügen, um das Gleichgewicht zwischen den Zonen aufrechtzuerhalten (zum Beispiel 3, 6 oder 9). Bei Clustern mit einer einzigen Zone, bei denen die flexible Skalierung aktiviert ist, können Sie Knoten einzeln hinzufügen.

2. Nachdem die Knoten hinzugefügt wurden, registrieren Sie diese bei ODF. Wenn ODF auf allen Worker-Knoten in Ihrem Cluster ausgeführt wird, werden neue Knoten automatisch zur Speichertopologie hinzugefügt. Wenn ODF nur auf einer Teilmenge der Worker-Knoten ausgeführt wird, fahren Sie mit dem nächsten Schritt fort.

3. Wenn ODF auf allen Worker Nodes in Ihrem Cluster läuft, werden neue Worker Nodes automatisch zur ODF-Storage-Cluster-Topologie hinzugefügt. Wenn ODF nur auf einer Teilmenge der Worker-Knoten ausgeführt wird, geben Sie die privaten Parameter <workerNodes> in Ihrer benutzerdefinierten Ressource OcsCluster an. Fügen Sie die Namen der neuen Worker Nodes zu Ihrer ODF-Bereitstellung hinzu, indem Sie die benutzerdefinierte Ressourcendefinition bearbeiten. Passen Sie die benutzerdefinierte Ressource OcsCluster wie folgt an:

   • ocscluster finden

     oc get ocscluster
     

   • Bearbeiten Sie die OCS-Cluster-Custom-Resource-Datei und fügen Sie neue Arbeitsknoten hinzu

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • Speichern Sie die benutzerdefinierte Ressourcen-Datei OcsCluster, um sie erneut auf Ihren Cluster anzuwenden.

4. Erhöhen Sie den Wert von 'numOfOsd' in Ihrer benutzerdefinierten Ressource OcsCluster, damit OCS ODF-Komponenten auf neu hinzugefügten Worker-Knoten bereitstellen und zusätzliche OSDs im Speichercluster bereitstellen kann.

   Die Anpassung an 'numOfOsd' hängt sowohl von der Anzahl der OSD-Festplatten pro Knoten als auch von der Anzahl der hinzugefügten Knoten ab. Wenn beispielsweise jeder Knoten über 8 NVMe-Festplatten verfügt, die für OSDs reserviert sind, erhöht sich die Anzahl der 'numOfOsd' durch das Hinzufügen von 3 Knoten um 8, während sie durch das Hinzufügen von 6 Knoten um 16 steigt.

5. Überprüfen Sie das Ergebnis, indem Sie den folgenden Befehl ausführen:

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. Stellen Sie sicher, dass die neuen Worker-Knoten hinzugefügt und gleichmäßig auf die einzelnen Zonen verteilt sind (bei Clustern mit mehreren Zonen) oder als einzelne Host-Buckets erscheinen (bei flexibel skalierbaren Clustern mit einer Zone), zusammen mit der entsprechenden Anzahl von OSDs, die jedem Knoten zugewiesen sind.

Weitere Informationen finden Sie unter „ Erweiterung von ODF durch Hinzufügen von Worker-Knoten zu Ihrem VPC-Cluster “.

Flexible Skalierung

Das ODF-Add-on IBM Cloud verwendet je nach Ihrer Clusterkonfiguration unterschiedliche Topologien für Ausfalldomänen:

• Cluster mit mehreren Verfügbarkeitszonen (3 Verfügbarkeitszonen): Die Ausfalldomäne ist auf zone. festgelegt. OSDs werden in Vielfachen von 3 bereitgestellt, jeweils ein Satz pro Zone, um die Datenreplikation und die Hochverfügbarkeit über die Zonen hinweg sicherzustellen. Der Speichercluster muss in Vielfachen von 3 erweitert werden, um die Zonen im Gleichgewicht zu halten.
• Cluster mit einer einzigen Verfügbarkeitszone oder Clustern mit weniger als drei Verfügbarkeitszonen: Die flexible Skalierung wird automatisch aktiviert. Die Ausfalldomäne ist auf gesetzt host, was bedeutet, dass jeder einzelne Knoten eine eigene Ausfalldomäne darstellt. Sie können jeweils einen Knoten hinzufügen und den Speicher schrittweise skalieren.

Ab ODF 4.21 wird das flexible Skalierungsverhalten bei der Erstbereitstellung automatisch auf Grundlage der Cluster-Topologie festgelegt und kann anschließend nicht mehr geändert werden.

In einer Single-Zone- oder Flexible-Scaling-Bereitstellung übersteht ein replica-3-Pool den Ausfall eines einzelnen Hosts. In einer Multi-Zone-Bereitstellung übersteht ein replica-3-Pool den Ausfall einer gesamten Zone. Prüfen Sie vor der Bereitstellung von ODF in der Produktion, ob Ihre Cluster-Topologie und die damit verbundene Fehlertoleranz Ihren Anforderungen an die Ausfallsicherheit entsprechen.

Eine vollständige Übersicht über die Add-on-Parameter und die Installationsschritte über die Konsole finden Sie unter Bereitstellung v OpenShift Data Foundation auf VPC-Clustern.

Leistung bei der Erweiterung um einen Knoten: Das Hinzufügen eines Knotens zu einem flexibel skalierbaren ODF-Cluster löst eine Datenausgleichung in Ceph aus. In dem unten beschriebenen internen Test blieben IOPS und Durchsatz stabil, während die Schreiblatenz vorübergehend anstieg. Bei internen Tests auf einem Cluster mit 3 Knoten und 100 VMs bei 50.000 IOPS wurden folgende Ergebnisse festgestellt:

Die Schreiblatenz kehrt nach Abschluss des Rebalancing auf den Ausgangswert zurück. Planen Sie das Hinzufügen von Knoten in Zeiten geringerer Aktivität im VM, wenn Ihre Workloads empfindlich auf Spitzen bei der Schreibleitzeit reagieren.