Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Backing Images

SUSE Storage unterstützt nativ Backing-Images.

Ein QCOW2- oder RAW-Image kann als Backing-/Basis-Image eines SUSE Storage-Volumes festgelegt werden, was es SUSE Storage ermöglicht, mit einer Virtualisierungslösung wie SUSE Virtualization integriert zu werden.

Die Bildgröße muss ein Vielfaches von 512 Bytes sein. SUSE Storage verwendet direktes I/O, was eine Ausrichtung der Dateigrößen an der zugrunde liegenden Speicherblockgröße erfordert.

Erstellen Sie ein V1 Data Engine Backing Image

Parameter

Datenquelle

Sie können ein V1 Backing Image mit einer der unterstützten Datenquellen vorbereiten.

  1. Laden Sie eine Backing-Image-Datei (unter Verwendung einer URL) herunter.

  2. Laden Sie eine Datei von Ihrem lokalen Computer hoch. Diese Option steht den SUSE Storage UI-Nutzern zur Verfügung.

  3. Exportieren Sie ein vorhandenes In-Cluster-Volume als Backing Image.

  4. Stellen Sie ein Backing Image aus dem Backupstore wieder her. Für weitere Informationen siehe Backing Image Backup.

  5. Klonen Sie ein Backing Image.

Volume-Export

Ein Backing Image dient als anfänglicher Snapshot in der Snapshot-Kette eines SUSE Storage-Volumes. Wenn Sie ein Volume mit einem zugehörigen Backing Image exportieren, kombiniert SUSE Storage dieses Image mit den Delta-Änderungen, was zu einem neuen konsolidierten Backing Image führt.

Prüfsumme

  • Die Prüfsumme eines Backing Images ist die SHA512-Prüfsumme der gesamten Backing-Image-Datei und nicht die des tatsächlichen Inhalts. Was ist der Unterschied? Wenn SUSE Storage die Prüfsumme einer qcow2-Datei berechnet, wird die Datei als Rohdatei gelesen, anstatt die qcow-Bibliothek zu verwenden, um den richtigen Inhalt zu lesen. Mit anderen Worten, die Benutzer erhalten immer die korrekte Prüfsumme, indem sie shasum -a 512 <the file path> unabhängig vom Dateiformat ausführen.

  • Es wird empfohlen, die erwartete Prüfsumme während der Erstellung des Backing-Images anzugeben. Andernfalls wird SUSE Storage die Prüfsumme der ersten Datei als die korrekte betrachten. Wenn bei der Vorbereitung der ersten Datei etwas schiefgeht, was dann zu einer falschen Prüfsumme als dem erwarteten Wert führt, ist dieses Backing-Image wahrscheinlich nicht verfügbar.

Planung

  • SUSE Storage bereitet zuerst die Backing-Image-Datei auf einem zufälligen Knoten und Datenträger vor und speichert sie, und dupliziert dann die Datei auf die Datenträger, die die Replikate speichern.

  • Für eine verbesserte Raumeffizienz können Sie nodeSelector und diskSelector hinzufügen, um die Speicherung der Backing-Image-Dateien auf einer bestimmten Gruppe von Knoten und Datenträgern zu erzwingen.

  • Die Replikate können nicht auf Knoten oder Datenträgern geplant werden, auf denen das Backing-Image nicht geplant werden kann.

Anzahl Kopien

  • Sie können minNumberOfCopies hinzufügen, um sicherzustellen, dass mehrere Backing-Image-Dateien im Cluster existieren.

  • Sie können das minNumberOfCopies in den globalen Einstellungen anpassen, um den Standardwert auf das Backing Image anzuwenden.

Methoden zur Erstellung eines Backing-Images

Erstelle ein Backing-Image über die SUSE Storage UI

Auf der Seite Erweiterte  Backing Images können Benutzer Backing-Images mit beliebigen Arten von Datenquellen erstellen.

Erstelle ein V1 Backing-Image mit YAML

Sie können eine Datei herunterladen oder ein vorhandenes Volume über YAML als Backing Image exportieren. Es ist besser, eine Datei nicht über YAML zu "hochladen". Andernfalls müssen Sie den Daten-Upload manuell über HTTP-Anfragen abwickeln.

Hierzu einige Beispiele:

apiVersion: longhorn.io/v1beta2
kind: BackingImage
metadata:
  name: bi-download
  namespace: longhorn-system
spec:
  dataEngine: v1
  minNumberOfCopies: 2
  nodeSelector:
    - "node1"
  diskSelector:
    - "disk1"
  sourceType: download
  sourceParameters:
    url: https://longhorn-backing-image.s3-us-west-1.amazonaws.com/parrot.raw
  checksum: 304f3ed30ca6878e9056ee6f1b02b328239f0d0c2c1272840998212f9734b196371560b3b939037e4f4c2884ce457c2cbc9f0621f4f5d1ca983983c8cdf8cd9a
apiVersion: longhorn.io/v1beta2
kind: BackingImage
metadata:
  name: bi-export
  namespace: longhorn-system
spec:
  dataEngine: v1
  minNumberOfCopies: 2
  nodeSelector:
    - "node1"
  diskSelector:
    - "disk1"
  sourceType: export-from-volume
  sourceParameters:
    volume-name: vol-export-src
    export-type: qcow2

Erstelle ein Backing-Image mit einer StorageClass und PVC

  1. In einer Longhorn StorageClass.

  2. Das Setzen des Parameters backingImageName bedeutet, SUSE Storage zu bitten, dieses Backing-Image während der Volumenerstellung zu verwenden.

  3. Wenn Sie das Backing Image erstellen möchten, solange es während der CSI-Volumenerstellung nicht existiert, sollten die Parameter backingImageDataSourceType und backingImageDataSourceParameters gesetzt werden. Ähnlich wie bei YAML ist es besser, ein Backing-Image nicht über "Hochladen" in der StorageClass zu erstellen. Beachten Sie, dass, wenn alle diese Parameter festgelegt sind und das Backing-Image bereits existiert, SUSE Storage überprüft, ob die Parameter mit dem vorhandenen übereinstimmen, bevor es verwendet wird.

    • Für download:

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-backing-image-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  backingImage: "bi-download"
  backingImageDataSourceType: "download"
  backingImageDataSourceParameters: '{"url": "https://backing-image-example.s3-region.amazonaws.com/test-backing-image"}'
  backingImageChecksum: "SHA512 checksum of the backing image"
  backingImageMinNumberOfCopies: "2"
  backingImageNodeSelector: "node1"
  backingImageDiskSelector: "disk1"
  dataEngine: "v1"

    • Für export-from-volume:

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-backing-image-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  backingImage: "bi-export-from-volume"
  backingImageDataSourceType: "export-from-volume"
  backingImageDataSourceParameters: '{"volume-name": "vol-export-src", "export-type": "qcow2"}'
  backingImageMinNumberOfCopies: "2"
  backingImageNodeSelector: "node1"
  backingImageDiskSelector: "disk1"
  dataEngine: "v1"

  4. Erstellen Sie ein PVC mit der StorageClass. Dann wird das Backing-Image (mit dem SUSE Storage Volume) erstellt, wenn es nicht existiert.

  5. SUSE Storage beginnt, die Backing-Images für die Replikate auf die Festplatten vorzubereiten, wenn ein Volume, das das Backing-Image verwendet, an einen Knoten angehängt wird.

  • Bitte seien Sie vorsichtig mit dem Escape-Zeichen \, wenn Sie eine Download-URL in einer StorageClass eingeben.

  • Ein Backing-Image, das mit einer StorageClass erstellt wurde, hat denselben Daten-Engine wie das Volume.

Verwenden Sie ein Backing-Image in einem Volume

Benutzer können direkt ein Backing-Image über die StorageClass erstellen und sofort verwenden oder ein vorhandenes Backing-Image wie unten erwähnt nutzen.

Verwenden Sie ein vorhandenes Backing-Image

Verwenden Sie ein vorhandenes Backing-Image während der Volume-Erstellung

  1. Klicken Sie auf Erweitert  Backing-Images in der SUSE Storage UI.

  2. Klicken Sie auf Backing-Image erstellen, um ein Backing-Image mit einem eindeutigen Namen und einer gültigen URL zu erstellen.

  3. Wählen Sie ein Backing-Image aus der Liste aus. Das Volume und das Backing-Image müssen denselben Daten-Engine verwenden.

  4. SUSE Storage beginnt, das Backing-Image auf die Festplatten für die Replikate herunterzuladen, wenn ein Volume, das das Backing-Image verwendet, an einen Knoten angehängt wird.

Verwenden Sie ein vorhandenes Backing-Image während der Wiederherstellung des Volumes

  1. Klicken Sie auf Backup und wählen Sie ein Backup-Volume für die Wiederherstellung aus.

  2. Solange das Backing-Image bereits für das Backup-Volume festgelegt ist, wird SUSE Storage das Backing-Image während der Wiederherstellung automatisch auswählen.

  3. SUSE Storage ermöglicht es Ihnen, das Backing-Image während der Wiederherstellung erneut anzugeben oder zu überschreiben.

Laden Sie eine Backing-Image-Datei herunter

Seit v1.3.0 können Benutzer vorhandene Backing-Image-Dateien über die UI auf die lokale Maschine herunterladen.

  • Benutzer müssen sicherstellen, dass das Backing Image vorhanden ist, wenn sie die Benutzeroberfläche verwenden, um ein Volume mit einem angegebenen Backing Image zu erstellen oder wiederherzustellen.

  • Bevor Benutzer eine vorhandene Backing-Image-Datei lokal herunterladen, müssen sie garantieren, dass eine bereitstehende Datei dafür vorhanden ist.

  • Der Download von V2 Data Engine Sicherungsbildern wird derzeit nicht unterstützt.

Erstellen Sie ein V2 Data Engine Sicherungsbild.

Ab v1.8.0 können Sie ein Sicherungsbild erstellen, das von der V2 Data Engine unterstützt wird, indem Sie Data Engine in der YAML konfigurieren (über die Benutzeroberfläche oder eine StorageClass).

Parameter

Alle Parameter sind die gleichen wie die des V1 Data Engine Backing Images, mit Ausnahme von Data Engine.

Datenquellen

Sie können ein V2 Data Engine Sicherungsbild mit einer der unterstützten Datenquellen vorbereiten.

  • Laden Sie eine Sicherungsbilddatei (unter Verwendung einer URL) herunter.

  • Laden Sie eine Datei von Ihrem lokalen Computer hoch. Diese Option steht den SUSE Storage UI-Nutzern zur Verfügung.

  • Exportieren Sie ein vorhandenes V1 Data Engine Volume im Cluster als Sicherungsbild.

  • Stellen Sie ein Backing Image aus dem Backupstore wieder her. Für weitere Informationen siehe Backing Image Backup.

  • Klonen Sie ein V1 Sicherungsbild.

  • Die folgenden Operationen werden derzeit nicht unterstützt:

    • Exportieren aus einem V2 Data Engine Volume

    • Klonen eines V2 Sicherungsbildes.

    • Sichern eines V2 Sicherungsbildes.

  • Im Gegensatz zur V1 Data Engine, die dateibasiert ist, erfordert die V2 Data Engine SUSE Storage, um die Sicherungsbilddaten in einem SPDK-logischen Volume zu speichern. Daher muss SUSE Storage für qcow2-Bilder zuerst das qcow2-Bild in ein Rohformat konvertieren, bevor die Daten im V2 Data Engine Sicherungsbild gespeichert werden, damit es die richtigen Daten lesen kann.

Sicherungsbilder bereinigen.

Sicherungsbilder auf Festplatten bereinigen.

  • SUSE Storage bereinigt automatisch die ungenutzten Sicherungsbilder auf den Festplatten basierend auf der Einstellung Backing Image Cleanup Wait Interval. Aber SUSE Storage wird mindestens eine Datei auf einer Festplatte für jedes Sicherungsbild aufbewahren.

  • Sie können Sicherungsbilder manuell von Festplatten über die SUSE Storage Benutzeroberfläche entfernen. Gehen Sie zu Einstellungen > Sicherungsbild und klicken Sie dann auf den Namen eines bestimmten Sicherungsbildes. Wählen Sie im sich öffnenden Fenster eine oder mehrere Festplatten aus und klicken Sie dann auf Bereinigen.

  • Sobald ein Replikat auf einer Festplatte, das ein Backing Image verwendet, vorhanden ist, kann die Backing-Image-Datei auf dieser Festplatte, unabhängig vom aktuellen Zustand des Replikats, nicht bereinigt werden.

Sicherungsbilder löschen

  • Das Sicherungsbild kann nur gelöscht werden, wenn kein Volume es verwendet.

Wiederherstellung des Sicherungsbildes

  • Wenn sich noch eine bereitstehende Backing-Image-Datei auf einer Festplatte befindet, wird SUSE Storage automatisch die fehlgeschlagenen Backing-Image-Dateien bereinigen und anschließend diese Dateien aus der bereitstehenden Datei erneut laden.

  • Wenn aus irgendeinem Grund alle Dateien eines Sicherungsbildes fehlschlagen und die erste Datei ist:

    • von einer URL heruntergeladen, wird SUSE Storage den Download neu starten.

    • Von einem bestehenden Volume exportiert, wird SUSE Storage (bei Bedarf das Volume anhängen und anschließend) den Export neu starten.

    • von der lokalen Umgebung des Benutzers hochgeladen, gibt es keine Möglichkeit, es wiederherzustellen. Benutzer müssen dieses Sicherungsbild löschen und dann ein neues erstellen, indem sie die Datei erneut hochladen.

  • Wenn ein Knoten ausgefallen ist oder der Sicherungsbildmanager-Pod auf dem Knoten nicht verfügbar ist, werden alle Sicherungsbilddateien auf dem Knoten unknown. Später, wenn der Knoten wieder online ist und der Pod läuft, wird SUSE Storage dies erkennen und dann die vorhandenen Dateien automatisch wiederverwenden.

Ausschluss von Sicherungsbildern

  • Sie können alle Sicherungsbilddateien manuell von einem Knoten oder einer Festplatte ausschließen, indem Sie Scheduling auf Disabled und Eviction Requested auf True in der SUSE Storage Benutzeroberfläche einstellen.

  • Wenn nur eine Sicherungsbilddatei im Cluster vorhanden ist, dupliziert SUSE Storage zuerst die Datei auf eine andere Festplatte und löscht dann die Datei.

  • Wenn die Sicherungsbilddatei nicht auf andere Festplatten dupliziert werden kann, löscht SUSE Storage die Datei nicht. Sie können die Einstellungen aktualisieren, um das Problem zu beheben.

Sicherungsbild-Workflow

  1. Um alle Sicherungsbilddateien auf einer Festplatte zu verwalten, erstellt SUSE Storage einen einzelnen Sicherungsbild-Manager-Pod für jede Festplatte. Sobald die Festplatte keine Anforderungen an eine Sicherungsbilddatei hat, wird der Sicherungsbild-Manager automatisch entfernt.

  2. Sobald eine Sicherungsbilddatei vom Sicherungsbild-Manager für eine Festplatte vorbereitet wurde, wird die Datei unter allen Volume-Replikaten auf dieser Festplatte geteilt.

  3. Wenn ein Sicherungsbild erstellt wird, startet SUSE Storage einen Sicherungsbild-Datenquellen-Pod, um die ursprüngliche Datei vorzubereiten. Die Dateidaten stammen aus einer vom Benutzer angegebenen Quelle – wie einem Download von einem entfernten Standort, einem Upload von einer lokalen Datei oder einem Export von einem bestehenden Volume. Sobald die Vorbereitung abgeschlossen ist, übernimmt der Sicherungsbild-Manager-Pod auf derselben Festplatte die Datei, und SUSE Storage beendet den Datenquellen-Pod.

  4. Sobald ein neues Sicherungsbild von einem Volume verwendet wird, werden die Sicherungsbild-Manager-Pods in den Festplatten, auf denen sich die Volume-Replikate befinden, aufgefordert, die Datei von den Sicherungsbild-Manager-Pods zu synchronisieren, die die Datei bereits enthalten.

  5. Wie im Abschnitt #clean_up_backing_images_in_disks erwähnt, wird die Datei automatisch bereinigt, wenn alle Replikate auf einer Festplatte keine Sicherungsbilddatei verwenden.

Gleichzeitige Begrenzung der Sicherungsbild-Synchronisierung

  • Concurrent Backing Image Replenish Per Node Limit in den globalen Einstellungen steuert, wie viele Kopien von Sicherungsbildern auf einem Knoten gleichzeitig wieder aufgefüllt werden können.

  • Wenn auf 0 gesetzt, füllt SUSE Storage die Kopie nicht automatisch wieder auf, selbst wenn sie unter der minNumberOfCopies liegt.

Warnhinweis

  • Die Download-URL des Sicherungsbildes sollte öffentlich sein. Wir werden diesen Teil in Zukunft verbessern.

  • Wenn nach Dateidownload eine hohe Speicherauslastung eines Sicherungsbild-Manager-Pods auftritt, wird dies durch den Systemcache/Puffer verursacht. Die Speicherauslastung wird automatisch sinken, daher müssen Sie sich keine Sorgen darüber machen. Siehe das GitHub-Ticket für weitere Details.

Verlauf