Sicherung und Wiederherstellung ohne Google Cloud

In diesem Abschnitt wird erläutert, wie Sie die Sicherung und Wiederherstellung Ihrer Cassandra-Datenbank mit ssh und Ihrem Dateisystem konfigurieren, statt mit Google Cloud. Weitere Informationen

Was ist Cassandra-Sicherung und -Wiederherstellung ohne Google Cloud-Dienste?

Bei der Sicherung ohne Cloud-Dienste werden Sicherungen Ihrer Cassandra-Datenbank in komprimierte Dateien im Dateisystem eines Servers gespeichert, den Sie angeben. Die Sicherungen werden nach einem Zeitplan ausgeführt, den Sie in der Überschreibungendatei angeben. Die Verbindung zum Server erfolgt über eine sichere SSH-Verbindung.

Sicherungen ohne Cloud-Dienste einrichten

Die folgenden Schritte enthalten gängige Beispiele für die Ausführung bestimmter Aufgaben, z. B. das Erstellen eines SSH-Schlüsselpaars. Verwenden Sie die für Ihre Installation geeigneten Methoden.

Der Vorgang besteht aus folgenden Teilen:

Server und SSH einrichten
Zeitplan und Ziel für Sicherung festlegen
Für die Wiederherstellung einrichten

Server und SSH einrichten

Geben Sie einen Linux- oder Unix-Server für Ihre Sicherungen an. Dieser Server muss über SSH von Ihrer Apigee Hybrid-Laufzeitebene erreichbar sein. Es muss genügend Speicherplatz für die Sicherungen haben.
Richten Sie einen SSH-Server auf dem Server ein bzw. prüfen Sie, ob ein sicherer SSH-Server konfiguriert ist.
Achtung: Achten Sie aus Sicherheitsgründen darauf, dass der SSH-Server auf dem neuesten Stand ist.

Erstellen Sie ein SSH-Schlüsselpaar und speichern Sie die Datei mit dem privaten Schlüssel in einem Pfad, auf den von der Hybrid-Laufzeitebene aus zugegriffen werden kann. Sie müssen ein leeres Passwort für Ihr Schlüsselpaar verwenden. Andernfalls schlägt die Sicherung fehl. Beispiel:

ssh-keygen -t rsa -b 4096 -C exampleuser@example.com
  Enter file in which to save the key (/Users/exampleuser/.ssh/id_rsa): $APIGEE_HOME/hybrid-files/certs/ssh_key
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in ssh_key
  Your public key has been saved in ssh_key.pub
  The key fingerprint is:
  SHA256:DWKo334XMZcZYLOLrd/8HNpjTERPJJ0mc11UYmrPvSA exampleuser@example.com
  The key's randomart image is:
  +---[RSA 4096]----+
  |          +.  ++X|
  |     .   . o.=.*+|
  |    . o . . o==o |
  |   . . . =oo+o...|
  |  .     S +E oo .|
  |   . .   .. . o .|
  |    . . .  . o.. |
  |     .  ...o ++. |
  |      .. .. +o+. |
  +----[SHA256]-----+

Erstellen Sie auf dem Sicherungsserver ein Nutzerkonto mit dem Namen apigee. Achten Sie darauf, dass der neue apigee-Nutzer ein Basisverzeichnis unter /home hat.
Erstellen Sie auf dem Sicherungsserver das Verzeichnis ssh im neuen Verzeichnis /home/apigee.
Kopieren Sie den öffentlichen Schlüssel (im vorherigen Beispiel ssh_key.pub) in eine Datei mit dem Namen authorized_keys im neuen Verzeichnis /home/apigee/ssh. Beispiel:
```
cd /home/apigee
mkdir .ssh
cd .ssh
vi authorized_keys
```
Erstellen Sie auf dem Sicherungsserver ein Sicherungsverzeichnis im Verzeichnis /home/apigee/. Das Sicherungsverzeichnis kann ein beliebiges Verzeichnis sein, solange der Nutzer apigee Zugriff darauf hat. Beispiel:
```
cd /home/apigee
mkdir cassandra-backup
```
Testen Sie die Verbindung. Sie müssen sicherstellen, dass Ihre Cassandra-Pods über SSH eine Verbindung zu Ihrem Sicherungsserver herstellen können:
1. Melden Sie sich in der Shell des Cassandra-Pods an. Beispiel:
```
kubectl exec -it -n apigee APIGEE_CASSANDRA_DEFAULT_0 -- /bin/bash
```
  Dabei ist APIGEE_CASSANDRA_DEFAULT_0 der Name eines Cassandra-Pods. Ändern Sie dies in den Namen des Pods, von dem Sie eine Verbindung herstellen möchten.
2. Stellen Sie über die Server-IP-Adresse eine SSH-Verbindung zu Ihrem Sicherungsserver her:
```
ssh apigee@BACKUP_SERVER_IP
```
  Hinweis: Möglicherweise wird an dieser Stelle eine Warnung angezeigt, die besagt, dass der Fingerabdruck Ihres Servers nicht erkannt wurde und Sie gefragt werden, ob Sie fortfahren möchten. Für diesen Test bedeutet dies, dass Sie Ihren Sicherungsserver über Ihren Cassandra-Pod erreichen können. Sie müssen nicht fortfahren.

Zeitplan und Ziel für Sicherung festlegen

Zeitplan und Ziel für Sicherungen werden in der Datei overrides.yaml festgelegt.

Fügen Sie der Datei overrides.yaml Folgendes hinzu:

Parameter

cassandra:
  backup:
    enabled: true
    keyFile: "PATH_TO_PRIVATE_KEY_FILE"
    server: "BACKUP_SERVER_IP"
    storageDirectory: "/home/apigee/BACKUP_DIRECTORY"
    cloudProvider: "HYBRID" # required verbatim "HYBRID" (all caps)
    schedule: "SCHEDULE"

Beispiel

cassandra:
  backup:
    enabled: true
    keyFile: "/Users/exampleuser/apigee-hybrid/hybrid-files/service-accounts/private.key"
    server: "34.56.78.90"
    storageDirectory: "/home/apigee/cassbackup"
    cloudProvider: "HYBRID"
    schedule: "0 2 * * *"

Wobei:

Attribut	Beschreibung
`backup:enabled`	Die Sicherung ist standardmäßig deaktiviert. Sie müssen dieses Attribut auf `true` festlegen.
`backup:keyFile`	`PATH_TO_PRIVATE_KEY_FILE` Der Pfad in Ihrem lokalen Dateisystem zur privaten SSH-Schlüsseldatei, die Sie in dem Schritt, in dem Sie das SSH-Schlüsselpaar erstellt haben, mit `ssh_key` benannt haben.
`backup:server`	`BACKUP_SERVER_IP` Die IP-Adresse des Sicherungsservers.
`backup:storageDirectory`	`BACKUP_DIRECTORY` Der Name des Sicherungsverzeichnisses auf dem Sicherungsserver. Dies muss ein Verzeichnis innerhalb `home/apigee` (das Sicherungsverzeichnis heißt `cassandra_backup` in dem Schritt, in dem Sie das Sicherungsverzeichnis erstellt haben) sein.
`backup:cloudProvider`	`HYBRID` Das Attribut `cloudProvider: "HYBRID"` ist erforderlich.
`backup:schedule`	`SCHEDULE` Die Zeit, zu der das Backup startet, angegeben in der Standard-Crontab-Syntax. Standard: `0 2 * * ` Hinweis:* Planen Sie kein Backup, das kurz nach dem Anwenden der Backupkonfiguration auf den Cluster startet. Wenn Sie die Backup-Konfiguration anwenden, erstellt Kubernetes die Cassandra-Knoten neu. Wenn das Backup vor dem Neustart der Knoten (möglicherweise mehrere Minuten) startet, schlägt die Backup fehl.

Verwenden Sie apigeectl, um die Sicherungskonfiguration auf den Speicherbereich Ihres Clusters anzuwenden:
```
$APIGEECTL_HOME/apigeectl --datastore -f YOUR_OVERRIDES_FILE
```
Dabei ist YOUR_OVERRIDES_FILE der Pfad zu der Überschreibungsdatei, die Sie gerade bearbeitet haben.

Überprüfen Sie den Sicherungsjob. Beispiel:

kubectl get cronjob -n apigee

NAME                      SCHEDULE     SUSPEND   ACTIVE   LAST SCHEDULE   AGE
apigee-cassandra-backup   33 * * * *   False     0        <none>          94s

Wiederherstellung konfigurieren

Die Wiederherstellung verwendet Ihre Daten vom Backup-Speicherort und stellt die Daten in einem neuen Cassandra-Cluster mit der gleichen Anzahl von Knoten wieder her. Es werden keine Daten aus dem alten Cassandra-Cluster übernommen.

Die folgende Wiederherstellungsanleitung gilt für Bereitstellungen in einer einzigen Region, die Google Cloud Storage nicht für Sicherungen verwenden. Für weitere Bereitstellungen:

Informationen zu Bereitstellungen in einer einzelnen Region, die Google Cloud Storage für Sicherungen verwenden, finden Sie unter Cassandra-Sicherungen und -Wiederherstellungen.
Informationen zu multiregionalen Bereitstellungen finden Sie unter Multiregionale Bereitstellung in GKE und GKE On-Prem.

So stellen Sie Cassandra-Backups wieder her:

Erstellen Sie im vorhandenen Kubernetes-Cluster einen neuen Namespace, mit dem die Hybrid-Laufzeitbereitstellung wiederhergestellt wird. Verwenden Sie nicht den ursprünglichen Namespace-Namen für den neuen Namespace. Verwenden Sie nicht den alten Namespace für die Wiederherstellung.
Erstellen Sie im Stammverzeichnis der Hybridinstallation die neue Datei overrides-restore.yaml.
Kopieren Sie die gesamte Cassandra-Konfiguration aus der ursprünglichen Datei overrides.yaml in die neue Datei overrides-restore.yaml. Beispiel:
```
cp ./overrides.yaml ./overrides-restore.yaml
```

Fügen Sie der neuen Datei overrides-restore.yaml ein Namespace-Element hinzu.

Parameter

namespace: YOUR_RESTORE_NAMESPACE
cassandra:
  ...
  restore:
    enabled: true
    keyFile: "PATH_TO_PRIVATE_KEY_FILE"
    server: "BACKUP_SERVER_IP"
    storageDirectory: "/home/apigee/BACKUP_DIRECTORY"
    cloudProvider: "HYBRID"  # required verbatim "HYBRID" (all caps)
    snapshotTimestamp: "TIMESTAMP"
  ..

Beispiel

namespace: cassandra-restore
cassandra:
  restore:
    enabled: true
    keyFile: "/Users/exampleuser/apigee-hybrid/hybrid-files/service-accounts/private.key"
    server: "34.56.78.90"
    storageDirectory: "/home/apigee/cassbackup"
    cloudProvider: "HYBRID"
    snapshotTimestamp: "20201001183903"

Wobei:

Attribut	Beschreibung
`namespace`	`YOUR_RESTORE_NAMESPACE` Der Name des neuen Namespace, den Sie in Schritt 1 für den neuen Cassandra-Cluster erstellt haben. Verwenden Sie nicht denselben Namespace, den Sie für den ursprünglichen Cluster verwendet haben.
`restore:enabled`	Die Wiederherstellung ist standardmäßig deaktiviert. Sie müssen dieses Attribut auf `true` festlegen.
`restore:keyFile`	`PATH_TO_PRIVATE_KEY_FILE` Der Pfad in Ihrem lokalen Dateisystem zur privaten SSH-Schlüsseldatei, die Sie in dem Schritt, in dem Sie das SSH-Schlüsselpaar erstellt haben, mit `ssh_key` benannt haben.
`restore:server`	`BACKUP_SERVER_IP` Die IP-Adresse des Sicherungsservers.
`restore:storageDirectory`	`BACKUP_DIRECTORY` Der Name des Sicherungsverzeichnisses auf dem Sicherungsserver. Dies muss ein Verzeichnis innerhalb `home/apigee` (das Sicherungsverzeichnis heißt `cassandra_backup` in dem Schritt, in dem Sie das Sicherungsverzeichnis erstellt haben) sein.
`restore:cloudProvider`	`HYBRID` Das Attribut `cloudProvider: "HYBRID"` ist erforderlich.
`restore:snapshotTimestamp`	`TIMESTAMP` Der Zeitstempel des wiederherzustellenden Backup-Snapshots. Wenn Sie prüfen möchten, welche Zeitstempel verwendet werden können, rufen Sie `dbStorageBucket` auf und sehen Sie sich die Dateien im Bucket an. Jeder Dateiname enthält einen Zeitstempelwert wie den folgenden: `backup_20210203213003_apigee-cassandra-default-0.tgz` Dabei ist `20210203213003` der `snapshotTimestamp`-Wert, den Sie verwenden würden, wenn Sie die Backups zu diesem Zeitpunkt wiederherstellen wollten.

Ändern Sie das Label app auf allen Cassandra-Knoten im alten Namespace. Führen Sie dazu den folgenden Befehl aus:
```
kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
```
Erstellen Sie eine neue Hybrid-Laufzeitbereitstellung. Damit wird ein neuer Cassandra-Cluster erstellt und die Backupdaten werden im Cluster wiederhergestellt:
```
./apigeectl init  -f ../overrides-restore.yaml
```
```
./apigeectl apply  -f ../overrides-restore.yaml
```
Nach Abschluss der Wiederherstellung muss der Traffic umgeschaltet werden, damit er den Cassandra-Cluster im neuen Namespace verwendet. Führen Sie die folgenden Befehle aus, um den Traffic umzuschalten:
```
kubectl get rs -n OLD_NAMESPACE # look for the 'apigee-connect' replicaset
```
```
kubectl patch rs -n OLD_NAMESPACE APIGEE_CONNECT_RS_NAME -p '{"spec":{"replicas" : 0}}'
```
Sobald die Traffic-Umschaltung abgeschlossen ist, können Sie die Backups auf dem wiederhergestellten Cluster neu konfigurieren. Entfernen Sie dazu die Konfiguration restore und fügen Sie die Konfiguration backup zur Datei overrides-restore.yaml hinzu. Ersetzen Sie YOUR_RESTORE_NAMESPACE durch den in Schritt 1 erstellten neuen Namespace-Namen.
```
namespace: YOUR_RESTORE_NAMESPACE
cassandra:
  ...
  backup:
    enabled: true
    serviceAccountPath: SA_JSON_FILE_PATH
    dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
    schedule: BACKUP_SCHEDULE_CODE
  ...
```
Wenden Sie dann die backup-Konfiguration mit dem folgenden Befehl an:
```
./apigeectl apply  -f ../overrides-restore.yaml
```