Architektur und Konzepte

Der Longhorn Manager Pod läuft auf jedem Knoten im SUSE Storage Cluster als Kubernetes DaemonSet. Er erstellt und verwaltet Volumes im Kubernetes-Cluster und bearbeitet die API-Aufrufe von der SUSE Storage UI oder dem Longhorn CSI-Plugin. Er folgt dem Kubernetes-Controller-Muster, das manchmal als Operator-Muster bezeichnet wird.

Der Longhorn Manager kommuniziert mit dem Kubernetes API-Server, um ein neues SUSE Storage Volume CR zu erstellen. Dann überwacht der Longhorn Manager die Antwort des API-Servers, und wenn er sieht, dass der Kubernetes API-Server ein neues SUSE Storage Volume CR erstellt hat, erstellt der Longhorn Manager ein neues Volume.

Wenn der Longhorn Manager aufgefordert wird, ein Volume zu erstellen, erstellt er eine Longhorn Engine-Instanz auf dem Knoten, an den das Volume angehängt ist, und er erstellt ein Replikat auf jedem Knoten, wo ein Replikat platziert wird. Replikate sollten auf separaten Hosts platziert werden, um maximale Verfügbarkeit zu gewährleisten.

Die mehreren Datenpfade für Replikate gewährleisten die hohe Verfügbarkeit eines Longhorn Volumes. Wenn ein Problem mit einem Replikat oder der Engine auftritt, hat dies keine Auswirkungen auf alle Replikate oder den Zugriff des Pods auf das Volume. Der Pod wird weiterhin normal funktionieren. Für ein gegebenes Volumen mit einer Replikazahl von N kann das Longhorn-Volumen maximal N-1 Replikatfehler tolerieren. Das liegt daran, dass mindestens ein gesundes Replikat erforderlich ist, damit das Volumen betriebsbereit bleibt.

Die Longhorn-Engine läuft immer auf demselben Knoten wie der Pod, der das SUSE Storage Volumen verwendet. Sie repliziert das Volumen synchron über die mehreren Replikate, die auf mehreren Knoten gespeichert sind.

Die Engine und die Replikate werden mit Kubernetes orchestriert.

In der Abbildung unten,

Abbildung 1. Lese-/Schreibdatenfluss zwischen dem Volumen, der Longhorn-Engine, den Replikat-Instanzen und den Festplatten

Jede Engine muss nur ein Volumen bedienen, was das Design der Speichercontroller vereinfacht. Da der Ausfallbereich der Controller-Software auf einzelne Volumen isoliert ist, wird ein Absturz des Controllers nur ein Volumen beeinträchtigen.

Die Longhorn-Engine ist einfach und leichtgewichtig, was es uns ermöglicht, Tausende von separaten Engines zu erstellen. Kubernetes plant diese separaten Engines und zieht Ressourcen aus einem gemeinsamen Satz von Festplatten, während es mit SUSE Storage arbeitet, um ein widerstandsfähiges verteiltes Blockspeichersystem zu bilden.

Da jedes Volume seinen eigenen Controller hat, können der Controller und die Replikatinstanzen für jedes Volume ebenfalls aktualisiert werden, ohne dass es zu spürbaren Unterbrechungen bei den IO-Operationen kommt.

SUSE Storage kann einen langlaufenden Job erstellen, um das Upgrade aller aktiven Volumes zu orchestrieren, ohne den laufenden Betrieb des Systems zu stören. Um sicherzustellen, dass ein Upgrade keine unvorhergesehenen Probleme verursacht, kann SUSE Storage wählen, eine kleine Teilmenge der Volumes zu aktualisieren und zur alten Version zurückzukehren, falls während des Upgrades etwas schiefgeht.

Der Longhorn CSI-Treiber nimmt das Blockgerät, formatiert es und bindet es am Knoten ein. Dann bindet der kubelet das Gerät innerhalb eines Kubernetes-Pods. Dies ermöglicht dem Pod den Zugriff auf das SUSE Storage Volume.

Die erforderlichen Kubernetes CSI-Treiber-Images werden automatisch vom Longhorn-Treiber-Deploymentsystem bereitgestellt. Um SUSE Storage in einer Air-Gapped-Umgebung zu installieren, siehe dieser Abschnitt.

SUSE Storage wird in Kubernetes über ein CSI-Plugin. verwaltet. Dies ermöglicht eine einfache Installation des Plugins.

Das Kubernetes CSI-Plugin ruft SUSE Storage auf, um Volumes zu erstellen, die persistente Daten für eine Kubernetes-Arbeitslast erzeugen. Das CSI-Plugin gibt Ihnen die Möglichkeit, das Volume zu erstellen, zu löschen, anzuhängen, zu trennen, zu mounten und Snapshots des Volumes zu erstellen. Alle anderen Funktionen, die von SUSE Storage bereitgestellt werden, werden über die Benutzeroberfläche implementiert.

Der Kubernetes-Cluster verwendet intern die CSI-Schnittstelle, um mit dem Longhorn CSI-Plugin zu kommunizieren. Und das Longhorn CSI-Plugin kommuniziert mit dem Longhorn-Manager über die Longhorn-API.

Für v1-Volumes verwendet SUSE Storage iSCSI, was möglicherweise zusätzliche Konfiguration auf Ihren Knoten erfordert:

Im Gegensatz dazu kommen v2-Volumes mit unterschiedlichen Voraussetzungen, abhängig von der Konfiguration:

Die Benutzeroberfläche interagiert über die Longhorn-API mit dem Longhorn-Manager und ergänzt Kubernetes. Über die Benutzeroberfläche können Sie Snapshots, Sicherungen, Knoten und Festplatten verwalten.

Außerdem wird die Speichernutzung der Cluster-Arbeitsknoten erfasst und durch die Benutzeroberfläche veranschaulicht. Siehe hier für Details.

Jede Replik enthält eine Kette von Snapshots eines SUSE Storage Volumens. Ein Snapshot ist wie eine Schicht eines Bildes, wobei der älteste Snapshot als Basisschicht verwendet wird und neuere Snapshots darüber liegen. Daten werden nur in einen neuen Snapshot aufgenommen, wenn sie Daten in einem älteren Snapshot überschreiben. Zusammen zeigt eine Kette von Snapshots den aktuellen Zustand der Daten.

Für jedes SUSE Storage Volumen sollten mehrere Replikate des Volumens im Kubernetes-Cluster laufen, jeweils auf einem separaten Knoten. Alle Replikate werden gleich behandelt, und die Longhorn Engine läuft immer auf demselben Knoten wie der Pod, der auch der Verbraucher des Volumens ist. Auf diese Weise stellen wir sicher, dass selbst wenn der Pod ausfällt, die Engine zu einem anderen Pod verschoben werden kann und Ihr Dienst ununterbrochen weiterläuft.

Die Standardanzahl der Replikate kann in den Einstellungen geändert werden. Wenn ein Volumen angeschlossen ist, kann die Anzahl der Replikate für dieses Volumen in der Benutzeroberfläche geändert werden.

Wenn die aktuelle gesunde Replikazahl geringer ist als die angegebene Replikazahl, wird SUSE Storage mit dem Wiederaufbau neuer Replikate beginnen.

Wenn die aktuelle gesunde Replikazahl höher ist als die angegebene Replikazahl, sind die Replikat-Auto-Balance und die Datenlokalität deaktiviert, SUSE Storage wird nichts tun. In dieser Situation, wenn eine Replik ausfällt oder gelöscht wird, wird SUSE Storage nicht mit dem Wiederaufbau neuer Replikate beginnen, es sei denn, die gesunde Replikazahl fällt unter die angegebene Replikazahl. Wenn Replikat-Auto-Balance oder Datenlokalität eingestellt sind, könnte SUSE Storage eines der Replikate löschen.

SUSE Storage Replikate werden mit Linux sparse files, erstellt, die dünne Bereitstellung unterstützen.

Die Snapshot-Funktion ermöglicht es, ein Volumen auf einen bestimmten Punkt in der Geschichte zurückzusetzen. Sicherungen im sekundären Speicher können ebenfalls aus einem Snapshot erstellt werden.

Wenn ein Volume aus einem Snapshot wiederhergestellt wird, spiegelt es den Zustand des Volumes zum Zeitpunkt der Erstellung des Snapshots wider.

Die Snapshot-Funktion ist auch Teil des SUSE Storage Wiederherstellungsprozesses. Jedes Mal, wenn SUSE Storage erkennt, dass ein Replikat nicht verfügbar ist, wird automatisch ein (System-)Snapshot erstellt und auf einem anderen Knoten mit dem Wiederaufbau begonnen.

Eine Sicherung wird erstellt, indem ein Snapshot als Quelle verwendet wird, sodass sie den Zustand der Daten des Volumes zum Zeitpunkt der Erstellung des Snapshots widerspiegelt. Eine Sicherung wird remote außerhalb des Clusters gespeichert.

Im Gegensatz zu einem Snapshot kann eine Sicherung als eine flachere Version einer Kette von Snapshots betrachtet werden. Ähnlich wie Informationen verloren gehen, wenn ein geschichtetes Bild in ein flaches Bild umgewandelt wird, gehen auch Daten verloren, wenn eine Kette von Snapshots in eine Sicherung umgewandelt wird. Bei beiden Konversionen würden alle überschriebenen Daten verloren gehen.

Da Sicherungen keine Snapshots enthalten, enthalten sie nicht die Historie der Änderungen an den Volumendaten. Nachdem Sie ein Volume aus einer Sicherung wiederhergestellt haben, enthält das Volume zunächst einen Snapshot. Dieser Snapshot ist eine zusammengefasste Version aller Snapshots in der ursprünglichen Kette und spiegelt die aktuellen Daten des Volumes zum Zeitpunkt der Erstellung der Sicherung wider.

Während Snapshots Hunderte von Gigabyte groß sein können, bestehen Sicherungen aus 2 MB großen Dateien.

Jede neue Sicherung des gleichen ursprünglichen Volumes ist inkrementell und erkennt und überträgt die geänderten Blöcke zwischen den Snapshots. Dies ist eine relativ einfache Aufgabe, da jeder Snapshot eine Differenzdatei ist und nur die Änderungen vom letzten Snapshot speichert. Dieses Design bedeutet auch, dass, wenn keine Blöcke geändert wurden und eine Sicherung erstellt wird, diese Sicherung im Backupstore als 0 Bytes angezeigt wird. Wenn Sie jedoch von dieser Sicherung wiederherstellen würden, würde sie dennoch die vollständigen Volumendaten enthalten, da sie die erforderlichen Blöcke, die bereits im Sicherungsspeicher vorhanden sind und für eine Sicherung erforderlich sind, wiederherstellen würde.

Um zu vermeiden, dass eine sehr große Anzahl kleiner Speicherblöcke gespeichert wird, führt SUSE Storage Sicherungsoperationen mit 2 MB großen Blöcken durch. Das bedeutet, dass, wenn ein 4K-Block innerhalb einer 2MB-Grenze geändert wird, SUSE Storage den gesamten 2MB-Block sichern wird. Dies bietet das richtige Gleichgewicht zwischen Handhabbarkeit und Effizienz.

Abbildung 3. Die Beziehung zwischen Sicherungen im Sekundärspeicher und Snapshots im Primärspeicher

Die obige Abbildung beschreibt, wie Sicherungen aus Snapshots erstellt werden:

Wenn ein Backup aus dem Sekundärspeicher gelöscht wird, SUSE Storage löscht nicht alle Blöcke, die es verwendet. Stattdessen führt es regelmäßig eine Garbage Collection durch, um ungenutzte Blöcke aus dem Sekundärspeicher zu bereinigen.

Die 2 MB Blöcke für alle Backups, die zu demselben Volumen gehören, werden unter einem gemeinsamen Verzeichnis gespeichert und können daher über mehrere Backups hinweg geteilt werden.

Um Speicherplatz zu sparen, können die 2 MB Blöcke, die sich zwischen den Backups nicht geändert haben, für mehrere Backups, die dasselbe Backup-Volumen im Sekundärspeicher teilen, wiederverwendet werden. Da Prüfsummen verwendet werden, um die 2 MB Blöcke zu adressieren, erreichen wir ein gewisses Maß an Duplikatsvermeidung für die 2 MB Blöcke im selben Volumen.

Metadaten auf Volumenebene werden in volume.cfg gespeichert. Die Metadatendateien für jedes Backup (z. B. snap2.cfg) sind relativ klein, da sie nur die Offsets und Prüfsummen aller 2 MB Blöcke im Backup enthalten.

Jeder 2 MB Block (.blk-Datei) wird komprimiert.

Sicherungsoperationen können mit der Funktion für wiederkehrende Snapshots und Sicherungen geplant werden, sie können jedoch auch nach Bedarf durchgeführt werden.

Es wird empfohlen, wiederkehrende Sicherungen für Ihre Volumes zu planen. Wenn ein Backupstore nicht verfügbar ist, wird empfohlen, stattdessen den wiederkehrenden Snapshot zu planen.

Die Erstellung von Sicherungen umfasst das Kopieren der Daten über das Netzwerk, daher wird es Zeit in Anspruch nehmen.

Ein Disaster Recovery (DR) Volumen ist ein spezielles Volumen, das Daten in einem Backup-Cluster speichert, falls der gesamte Haupt-Cluster ausfällt. DR-Volumes werden verwendet, um die Widerstandsfähigkeit der SUSE Storage-Volumes zu erhöhen.

Da der Hauptzweck eines DR-Volumes darin besteht, Daten aus dem Backup wiederherzustellen, unterstützt dieser Volumentyp die folgenden Aktionen nicht, bevor er aktiviert wird:

Ein DR-Volumen kann aus einem Backup eines Volumens im Backupstore erstellt werden. Nachdem das DR-Volumen erstellt wurde, wird SUSE Storage sein ursprüngliches Backup-Volumen überwachen und schrittweise aus dem neuesten Backup wiederherstellen. Ein Backup-Volumen ist ein Objekt im Sicherungsspeicher, das mehrere Sicherungen desselben Volumens enthält.

Wenn das ursprüngliche Volumen im Haupt-Cluster ausfällt, kann das DR-Volumen sofort im Backup-Cluster aktiviert werden, wodurch die Zeit zur Wiederherstellung der Daten vom Backup-Speicher auf das Volumen im Backup-Cluster verkürzt wird.

Wenn ein DR-Volumen aktiviert wird, wird SUSE Storage das letzte Backup des ursprünglichen Volumens überprüfen. Wenn dieses Backup noch nicht wiederhergestellt wurde, wird die Wiederherstellung gestartet, und die Aktivierungsaktion schlägt fehl. Benutzer müssen warten, bis die Wiederherstellung abgeschlossen ist, bevor sie es erneut versuchen.

Das Backup-Ziel in den Einstellungen kann nicht aktualisiert werden, wenn DR-Volumes vorhanden sind.

Nachdem ein DR-Volumen aktiviert wurde, wird es zu einem normalen SUSE Storage Volumen und kann nicht deaktiviert werden.

Die inkrementelle Wiederherstellung wird normalerweise durch das regelmäßige Backupstore-Update ausgelöst. Sie können das Update-Intervall auf dem Bildschirm der Backup-Ziel-Einstellungen (Backup und Wiederherstellung → Backup-Ziele) festlegen.

Beachten Sie, dass dieses Intervall potenziell das Recovery Time Objective (RTO) beeinflussen kann. Wenn es zu lang ist, kann es eine große Menge an Daten geben, die für das DR-Volumen wiederhergestellt werden müssen, was lange dauern wird.

Was das Recovery Point Objective (RPO) betrifft, so wird es durch die wiederkehrende Backup-Planung des Backup-Volumes bestimmt. Wenn die wiederkehrende Backup-Planung für das normale Volume A jede Stunde ein Backup erstellt, beträgt das RPO eine Stunde. Hier können Sie überprüfen, wie Sie wiederkehrende Backups in SUSE Storage einrichten können.

Die folgende Analyse geht davon aus, dass das Volume jede Stunde ein Backup erstellt und dass die inkrementelle Wiederherstellung von Daten aus einem Backup fünf Minuten dauert:

Im Großen und Ganzen gibt es zwei Hauptwege, um persistenten Speicher in Kubernetes zu nutzen:

Um ein bestehendes PV zu verwenden, muss Ihre Anwendung ein PVC verwenden, das an ein PV gebunden ist, und das PV sollte die minimalen Ressourcen enthalten, die das PVC benötigt.

Mit anderen Worten, ein typischer Arbeitsablauf zur Einrichtung von bestehendem Speicher in Kubernetes sieht wie folgt aus:

Wenn ein PVC ein Stück Speicher anfordert, wird der Kubernetes-API-Server versuchen, dieses PVC mit einem vorab zugewiesenen PV abzugleichen, sobald passende Volumes verfügbar sind. Wenn eine Übereinstimmung gefunden werden kann, wird das PVC an das PV gebunden, und der Benutzer beginnt, dieses vorab zugewiesene Stück Speicher zu nutzen.

Wenn kein passendes Volume vorhanden ist, bleiben PersistentVolumeClaims unbegrenzt ungebunden. Zum Beispiel würde ein Cluster, das mit vielen 50 Gi PVs bereitgestellt wurde, nicht mit einem PVC übereinstimmen, das 100 Gi anfordert. Das PVC könnte gebunden werden, nachdem ein 100 Gi PV zum Cluster hinzugefügt wurde.

Mit anderen Worten, Sie können unbegrenzt PVCs erstellen, aber sie werden nur an PVs gebunden, wenn der Kubernetes-Master einen ausreichenden PV finden kann, der mindestens den für das PVC erforderlichen Speicherplatz hat.

Für die dynamische Speicherbereitstellung muss Ihre Anwendung ein PVC verwenden, das an eine StorageClass gebunden ist. Die StorageClass enthält die Berechtigung zur Bereitstellung neuer persistenter Volumen.

Der gesamte Workflow zur dynamischen Bereitstellung neuer Speicherressourcen in Kubernetes umfasst eine StorageClass-Ressource:

Kubernetes-Cluster-Administratoren können eine Kubernetes StorageClass verwenden, um die “classes” des Speichers zu beschreiben, den sie anbieten. StorageClasses können unterschiedliche Kapazitätsgrenzen, unterschiedliche IOPS oder andere Parameter haben, die der Bereitsteller unterstützt. Der spezifische Bereitsteller des Speicheranbieters wird zusammen mit der StorageClass verwendet, um PV automatisch zuzuweisen, gemäß den in dem StorageClass-Objekt festgelegten Parametern. Außerdem hat der Bereitsteller jetzt die Möglichkeit, die Ressourcenquoten und Berechtigungsanforderungen für Benutzer durchzusetzen. In diesem Design sind die Administratoren von der unnötigen Arbeit befreit, den Bedarf an PVs vorherzusagen und sie zuzuweisen.

Wenn eine StorageClass verwendet wird, ist ein Kubernetes-Administrator nicht dafür verantwortlich, jedes Stück Speicher zuzuweisen. Der Administrator muss den Benutzern lediglich die Berechtigung geben, auf einen bestimmten Speicherpool zuzugreifen, und das Kontingent für den Benutzer festlegen. Dann kann der Benutzer die benötigten Teile des Speichers aus dem Speicherpool herausnehmen.

StorageClasses können auch verwendet werden, ohne explizit ein StorageClass-Objekt in Kubernetes zu erstellen. Da die StorageClass auch ein Feld ist, das verwendet wird, um ein PVC mit einem PV abzugleichen, kann ein PV manuell mit einem benutzerdefinierten StorageClass-Namen erstellt werden, und dann kann ein PVC erstellt werden, das nach einem PV mit diesem StorageClass-Namen fragt. Kubernetes kann dann Ihr PVC mit dem PV mit dem angegebenen StorageClass-Namen binden, selbst wenn das StorageClass-Objekt nicht als Kubernetes-Ressource existiert.

SUSE Storage führt eine StorageClass ein, damit Ihre Kubernetes-Arbeitslasten nach Bedarf Teile Ihres persistenten Speichers herausnehmen können.

Das VolumeClaimTemplate ist eine Eigenschaft der StatefulSet-Spezifikation, und es bietet eine Möglichkeit, damit die Blockspeicherlösung horizontal für einen Kubernetes-Workload skaliert.

Diese Eigenschaft kann verwendet werden, um passende PVs und PVCs für Pods zu erstellen, die von einem StatefulSet erstellt wurden.

Diese PVCs werden mit einer StorageClass erstellt, sodass sie automatisch eingerichtet werden können, wenn das StatefulSet hochskaliert.

Wenn ein StatefulSet herunter skaliert, bleiben die zusätzlichen PVs/PVCs im Cluster und werden wiederverwendet, wenn das StatefulSet erneut hochskaliert.

Das VolumeClaimTemplate ist wichtig für Blockspeicherlösungen wie EBS und SUSE Storage. Da diese Lösungen von Natur aus ReadWriteOnce, sind, können sie nicht zwischen den Pods geteilt werden.

Deployments funktionieren nicht gut mit persistentem Speicher, wenn mehr als ein Pod mit persistenten Daten läuft. Für mehr als einen Pod sollte ein StatefulSet verwendet werden.