Cassandra CSI-Sicherung und -Wiederherstellung

Sie können Ihre Hybriddaten über CSI-Snapshots (Container Storage Interface) sichern und wiederherstellen. Die CSI-Sicherung generiert Laufwerk-Snapshots und speichert sie als verschlüsselte Daten im Cloud-Speicher. Für die CSI-Sicherung sind weder ein Google Cloud Storage-Bucket noch ein Remoteserver zum Speichern von Sicherungsdaten erforderlich.

CSI-Sicherungen werden für Hybridinstanzen empfohlen, die in Google Cloud, AWS oder Azure gehostet werden.

Auf dieser Seite werden die Schritte zur Verwendung der Sicherung und Wiederherstellung von Hybrid-CSI beschrieben. Eine Übersicht über die Hybrid-Sicherung und -Wiederherstellung im Allgemeinen finden Sie in der Übersicht zum Sichern und Wiederherstellen in Cassandra.

Einschränkungen bei der Sicherung und Wiederherstellung

Beachten Sie diese Einschränkungen bei der Verwendung der CSI-Sicherung und -Wiederherstellung:

Der von der konfigurierten Speicherklasse verwendete CSI-Treiber muss CSI-Snapshots unterstützen. Informationen zu Treibern finden Sie in dieser Kubernetes-CSI-Treiberliste.
Nicht alle Plattformen werden unterstützt. Nur Google Cloud-, AWS- und Azure-Plattformen werden unterstützt.
Die OpenShift-Containerplattform wird aufgrund von Einschränkungen für Volume-Snapshots nicht unterstützt.
Nur Cloud-Plattformen werden unterstützt. Lokale Plattformen werden nicht unterstützt.
CSI-Sicherungsdaten und Nicht-CSI-Hybridsicherungsdaten sind nicht kompatibel. Nicht-CSI-Sicherungen können nicht mit CSI-Wiederherstellungen und CSI-Sicherungen nicht mit Nicht-CSI-Wiederherstellungen verwendet werden.
Für die Installation und Funktionalität der CSI-Treiber ist der jeweilige Anbieter verantwortlich.
Nutzer sind dafür verantwortlich, dass ausreichende Clusterressourcen für die Bereitstellung von CSI-Snapshots verfügbar sind.
Nutzer sind dafür verantwortlich, alte Snapshot-Daten zu entfernen.

CSI-Sicherungen einrichten

Führen Sie die folgenden Schritte aus, um Hybridsicherungen mithilfe von CSI zu planen:

Wenn Sie die Hybridsicherung noch nicht eingerichtet haben:
1. Führen Sie den folgenden Befehl create-service-account aus, um ein Google Cloud-Dienstkonto (Service Account, SA) mit der Standardrolle roles/storage.objectAdmin zu erstellen. Mit dieser Rolle können Sie Sicherungsdaten in Cloud Storage schreiben. Führen Sie den folgenden Befehl in dem Verzeichnis aus, das für Ihr Managementtool geeignet ist:
  - Helm-Diagramme: $APIGEE_HELM_CHARTS_HOME/apigee-operator/etc/
  - apigeectl: HYBRID_BASE_DIRECTORY/hybrid-files/
```
./tools/create-service-account --env non-prod --dir ./service-accounts
```
  Mit diesem Befehl wird ein einzelnes Dienstkonto mit dem Namen apigee-non-prod für die Verwendung in einer Nicht-Produktionsumgebung erstellt und die heruntergeladene Schlüsseldatei im Verzeichnis ./service-accounts abgelegt.
  Hinweis: Wenn Sie alle einzelnen Dienstkonten für eine Produktionsumgebung erstellen möchten, verwenden Sie den folgenden Befehl:
```
./tools/create-service-account --env prod --dir ./service-accounts
```
  Weitere Informationen zu Google Cloud-Dienstkonten finden Sie unter Dienstkonten erstellen und verwalten.
2. Mit dem Befehl create-service-account wird eine JSON-Datei mit dem privaten Schlüssel des Dienstkontos gespeichert. Die Datei wird im selben Verzeichnis gespeichert, in dem der Befehl ausgeführt wird. Sie benötigen den Pfad zu dieser Datei in den folgenden Schritten.
Öffnen Sie Ihre overrides.yaml-Datei. Legen Sie die folgenden Parameter fest, wie unter Beispiel für Überschreibungsdateien gezeigt.
1. Legen Sie die unten aufgeführten allgemeinen Parameter im backup-Block fest. Wenn Sie diese Parameter bereits für die Nicht-CSI-Hybridsicherungslösung festgelegt haben, können Sie dieselben Parameter für Ihre CSI-Snapshots verwenden. Weitere Informationen zu den einzelnen Werten finden Sie in der Referenztabelle für Sicherungsattribute.
  
  Für backup:
  - aktiviert: Legen Sie true fest, um geplante Sicherungen zu aktivieren.
  - pullPolicy im Image: Auf Always festlegen.
  - serviceAccountPath: Der Pfad zum Dienstkonto.
  - schedule: Geben Sie einen Zeitplan für Cron-Ausdrücke an.
2. Legen Sie diese Parameter für die CSI-spezifische Sicherung fest:
  - Cassandra-Speichergruppenwerte: Die konfigurierte Cassandra-Speicherklasse muss CSI-Snapshots unterstützen, damit die CSI-Sicherung und -Wiederherstellung funktionieren. Führen Sie den folgenden Befehl aus, um die verfügbaren Speicherklassen zu erhalten, um zu prüfen, ob eine Speicherklasse CSI-Snapshots unterstützt:
```
kubectl get sc
```
    Sehen Sie sich die Ausgabe „Bereitsteller” für jede Speicherklasse an. Bereitsteller, die CSI verwenden, haben in der Regel ein „.csi.” durch einen Namen wie „pd.csi.storage.gke.io”. Suchen Sie in dieser Kubernetes CSI-Treiberliste nach dem Namen des Bereitstellers. Wenn die Spalte „Andere Features” für den Bereitsteller das Wort „SNAPSHOT” enthält, unterstützt die Speicherklasse mit dem Bereitsteller CSI-Snapshots.
    Fügen Sie diese Parameter der Speichergruppe hinzu. Beide Werte sind erforderlich.
    - storageclass: Ein Speicherklassen-Name, für den CSI-Snapshots aktiviert sind.
    - capacity: Die Kapazität des Ziellaufwerks.
  - Cloud-Anbietertyp:
    Nachdem die CSI-Snapshot-Funktion verifiziert wurde, ändern Sie die Überschreibungsdatei, um die CSI-Sicherung und -Wiederherstellung zu verwenden:
    - cloudProvider: Legen Sie cloudProvider in backup und restore auf CSI fest.

Beispiel für eine Sicherungskonfiguration

In diesem Abschnitt werden die wiederherstellungsbezogenen Teile einer overrides.yaml-Beispieldatei angezeigt.

cassandra:
  hostNetwork: false
  replicaCount: 3
  storage:
    storageclass: standard-rwo
    capacity: 100Gi
  image:
    pullPolicy: Always

  backup:
    enabled: true
    image:
      pullPolicy: Always
    serviceAccountPath: "/Users/myuser/apigee-hybrid/hybrid-files/service-accounts/mycompany-hybrid-apigee-cassandra.json"
    cloudProvider: "CSI"
    schedule: "0 * * 11 *"

Manuelle Sicherung starten

CSI-Sicherungen werden automatisch gemäß dem Cron-Zeitplan generiert, der in der Datei overrides.yaml festgelegt ist.

Verwenden Sie den folgenden Befehl, um eine manuelle CSI-Sicherung zu initiieren:

kubectl create job -n apigee --from=cronjob/apigee-cassandra-backup backup-pod-name

Dabei ist backup-pod-name der Name des zu erstellenden Sicherungs-Pods.

Sicherungen überprüfen

Um zu prüfen, ob eine Sicherung erfolgreich erstellt wurde, können Sie die Volume-Snapshots im Kubernetes-Cluster mit folgendem Befehl prüfen:

kubectl get volumesnapshot -n apigee

Die Ausgabe zeigt die aktuelle Liste der Snapshots im Cluster. Der CSI-Sicherungsprozess erstellt einen Snapshot jedes Cassandra-Laufwerks. Die Anzahl der generierten Snapshots sollte der Gesamtzahl der Cassandra-Pods im Cluster entsprechen.

Sicherung wiederherstellen

Verwenden Sie diesen Prozess, um eine zuvor generierte CSI-Sicherung wiederherzustellen. Allgemeine Informationen zum Wiederherstellen von Sicherungen und eine Übersicht über den Prozess finden Sie auf der Übersichtsseite zur Wiederherstellung

Folgen Sie der Anleitung für die Wiederherstellung einer einzelnen Nicht-CSI-Hybridregion, um eine Wiederherstellung einer CSI-Sicherung zu initiieren. Verwenden Sie diese Werte jedoch im Block restore in Ihrer overrides.yaml. Weitere Informationen zu den einzelnen Werten und ein Beispiel finden Sie in der Referenztabelle zu Sicherungsattributen bzw. in der Beispielkonfiguration für Wiederherstellungen.

enabled: Legen Sie true fest, um die Wiederherstellung für die Sicherung mit dem Zeitstempel snapshotTimestamp zu aktivieren.
snapshotTimestamp: Geben Sie den Zeitstempel einer vorherigen CSI-Sicherung an.
serviceAccountPath: Der Pfad zum Dienstkonto.
pullPolicy im Image: Auf Always festlegen.

Um den wiederherzustellenden Wert snapshotTimestamp zu finden, führen Sie diesen Befehl aus, um die Liste der verfügbaren Snapshots zu erhalten:

kubectl get volumesnapshot -n apigee

In der zurückgegebenen Liste enthalten die Namen der Snapshots den Zeitstempel:

pvc-us-west2-b-20220803004907-47beff0e306d8861

In diesem Beispiel ist der Zeitstempel 20220803004907.

Beispiel für eine Wiederherstellungskonfiguration