Back-ups auf einem Remote-Server planen

Version 1.12 

Unterstützte Versionen:

• v1.13 (aktuellste Version)                        
• v1.12                         
• v1.11                         
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Auf dieser Seite wird beschrieben, wie Sie Sicherungen für Cassandra ohne Cloud Storage planen. Bei dieser Methode werden Sicherungen auf einem von Ihnen angegebenen Remoteserver und nicht in einem Cloud Storage-Bucket gespeichert. Apigee verwendet SSH, um mit dem Remote-Server zu kommunizieren.

Sie müssen die Sicherungen als cron-Jobs planen. Nachdem ein Sicherungszeitplan auf Ihren Hybrid-Cluster angewendet wurde, wird regelmäßig ein Kubernetes-Sicherungsjob gemäß dem Zeitplan in der Laufzeitebene ausgeführt. Der Job löst auf jedem Cassandra-Knoten in Ihrem Hybridcluster ein Sicherungsskript aus, das alle Daten auf dem Knoten erfasst, eine (komprimierte) Archivdatei der Daten erstellt und das Archiv an den in der Datei overrides.yaml angegeben Server sendet.

Hinweis:

• Sie müssen sicherstellen, dass auf dem Dateisystem genügend Speicherplatz für die Sicherungen vorhanden ist. Außerdem sollten Sie die Häufigkeit der Sicherungen anpassen, um zu vermeiden, dass der ungenutzte Speicherplatz belegt wird. Apigee legt keine Aufbewahrungsrichtlinie für die Sicherungsdateien fest. Sie können für Ihre Installation geeignete Dateien erstellen.
• Durch das Anwenden der Sicherungskonfiguration auf den vorhandenen Cluster werden Cassandra-Pods neu gestartet.

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

Server und SSH einrichten

1. Back-up-Server auswählen: Wählen Sie einen Linux- oder Unix-Server mit ausreichendem Speicherplatz für Ihre Sicherungen aus und achten Sie darauf, dass er über SSH von Ihrer Apigee Hybrid-Laufzeitebene aus erreichbar ist.
2. SSH-Server konfigurieren: Installieren Sie einen SSH-Server oder prüfen Sie, ob ein vorhandener Server sicher ist.
Achtung: Achten Sie aus Sicherheitsgründen darauf, dass der SSH-Server auf dem neuesten Stand ist.
3. SSH-Schlüsselpaar erstellen: Generieren Sie ein SSH-Schlüsselpaar ohne Passphrase. Beispiel:

   ssh-keygen -t rsa -b 4096 -C [e-mail]
     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 [e-mail]
     The key's randomart image is:
     +---[RSA 4096]----+
     |          +.  ++X|
     |     .   . o.=.*+|
     |    . o . . o==o |
     |   . . . =oo+o...|
     |  .     S +E oo .|
     |   . .   .. . o .|
     |    . . .  . o.. |
     |     .  ...o ++. |
     |      .. .. +o+. |
     +----[SHA256]-----+

   Dabei ist [e-mail] ein String. Jeder String, der im Befehl ssh-keygen auf -C folgt, wird zu einem Kommentar, der im neu erstellten Schlüssel ssh enthalten ist. Der Eingabestring kann ein beliebiger String sein. Wenn Sie einen Kontonamen im Format [e-mail] verwenden, können Sie schnell feststellen, welches Konto mit dem Schlüssel verknüpft wird.

   Der Befehl generiert zwei SSH-Schlüsseldateien, eine private Schlüsseldatei (z. B. „ssh_key.rsa“) und eine öffentliche Schlüsseldatei (z. B. „ssh_key.pub“).

   Speichern Sie den privaten Schlüssel an einem Ort, auf den Ihre Laufzeitebene zugreifen kann.

4. Nutzerkonto hinzufügen: Erstellen Sie auf dem Sicherungsserver einen Nutzer namens „apigee“ mit einem Basisverzeichnis unter /home/apigee. Achten Sie darauf, dass der neue apigee-Nutzer ein Basisverzeichnis unter /home hat.
5. .ssh-Verzeichnis einrichten: Erstellen Sie auf dem Sicherungsserver das Verzeichnis .ssh in /home/apigee/.ssh. Beispiel:

   cd /home/apigee
         mkdir .ssh
         cd .ssh
         vi authorized_keys

6. Öffentlichen Schlüssel installieren: Platzieren Sie den öffentlichen Schlüssel in der Datei authorized_keys im Verzeichnis /home/apigee/. Das Sicherungsverzeichnis kann ein beliebiges Verzeichnis sein, solange der Nutzer apigee Zugriff darauf hat. Fügen Sie den Inhalt der Datei ssh public key in die Datei ein.
7. SSH-Zugriff prüfen: Testen Sie die Verbindung von Ihrem lokalen Computer oder einem Clusterknoten aus:

ssh -i PATH_TO_PRIVATE_KEY_FILE apigee@BACKUP_SERVER_IP

Hinweis: Prüfen Sie, ob Sie auf den Remoteserver zugreifen können, ohne nach einem Passwort oder einer Passphrase gefragt zu werden. Wenn Sie nach einer Passphrase gefragt werden, generieren Sie das SSH-Schlüsselpaar bitte neu, ohne eine Passphrase anzugeben. Wenn Sie nach einem Passwort gefragt werden, prüfen Sie Ihre SSH-Konfiguration auf dem Remoteserver, da sie höchstwahrscheinlich nicht richtig eingerichtet ist.

Zeitplan und Ziel für Sicherung festlegen

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

1. 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: "private.key" # path relative to apigee-datastore path
       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. Dieser Pfad muss sich auf das Diagrammverzeichnis apigee-datastore beziehen.
   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	GCP/HYBRID Legen Sie für eine Cloud Storage-Sicherung das Attribut auf GCP fest. Beispiel: cloudProvider: "GCP". Legen Sie für eine Remote-Serversicherung das Attribut HYBRID fest. Beispiel: cloudProvider: "HYBRID".
   backup:schedule	SCHEDULE Die Zeit, zu der das Backup startet, angegeben in der Standard-Crontab-Syntax. Die Zeitangaben werden in der lokalen Zeitzone des Kubernetes-Clusters angegeben. 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 die Sicherung vor dem Neustart der Knoten startet, schlägt die erste Sicherung fehl und die nachfolgenden Sicherungen sind erfolgreich.

2. Wenden Sie die Sicherungskonfiguration auf den Speicherbereich Ihres Clusters an:

   helm upgrade datastore apigee-datastore/ \
     --namespace apigee \
     --atomic \
     -f OVERRIDES_FILE.yaml
   

   Hinweis: Wenn der Fehler Error: UPGRADE FAILED: "datastore" has no deployed releases angezeigt wird, ersetzen Sie upgrade durch install und wiederholen Sie den Befehl.

   Dabei ist OVERRIDES_FILE der Pfad zu der Überschreibungsdatei, die Sie gerade bearbeitet haben.

3. Ü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

Fehlerbehebung

1. Testen Sie die Verbindung von einem Cassandra-Pod aus. 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 per SSH eine Verbindung zu Ihrem Sicherungsserver her. Verwenden Sie dazu den privaten SSH-Schlüssel, der den Cassandra-Pod und die IP-Adresse des Servers bereitgestellt hat:

      ssh -i /var/secrets/keys/key 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. Sie können an dieser Eingabeaufforderung fortfahren und die SSH-Konfiguration prüfen.
2. Wenn Sie vom Cassandra-Pod aus nicht auf Ihren Remote-Server zugreifen können, prüfen Sie noch einmal Ihre SSH-Konfiguration auf dem Remote-Server und ob das Upgrade des Datenspeichers erfolgreich war.
3. Sie können prüfen, ob Cassandra den richtigen privaten Schlüssel verwendet, indem Sie den folgenden Befehl ausführen, während Sie in Ihrem Cassandra-Pod angemeldet sind, und die Ausgabe mit dem von Ihnen erstellten privaten Schlüssel vergleichen:

   cat /var/secrets/keys/key