Strategien für geschützte Anwendungen

Auf dieser Seite werden die verschiedenen Strategien für geschützte Anwendungen beschrieben, die in Google Distributed Cloud (GDC) Air-Gapped verfügbar sind.

Mit Strategien für geschützte Anwendungen können Sie bestimmte Pre-Execution- und Post-Execution-Hooks ausführen und benutzerdefiniertes Verhalten für das Stilllegen, Sichern oder Wiederherstellen einer zustandsorientierten Arbeitslast definieren.

Es gibt drei Sicherungs- und Wiederherstellungsstrategien, die Sie beim Definieren einer ProtectedApplication-Ressource verwenden können:

• Alle sichern und alle wiederherstellen
• Eine sichern und alle wiederherstellen
• Dump- und Ladevorgang

Strategiedefinitionen können die folgenden Werte enthalten:

Alle sichern und alle wiederherstellen

Mit dieser Strategie werden alle Anwendungsressourcen während der Sicherung gesichert und alle diese Ressourcen werden während des Wiederherstellungsvorgangs wiederhergestellt. Diese Strategie funktioniert am besten mit eigenständigen Anwendungen, also Anwendungen ohne Replikation zwischen Pods.

Für die Strategie „Alle sichern und alle wiederherstellen“ müssen Sie die folgenden Informationen in die Ressourcendefinition aufnehmen:

• Hooks: Definieren Befehle, die vor und nach dem Erstellen von Volume-Sicherungen ausgeführt werden, z. B. Schritte zum Stilllegen und Aufheben von Stilllegungen einer Anwendung. Diese Befehle werden auf allen Pods innerhalb einer Komponente ausgeführt.

• Volume-Auswahl: Ermöglicht eine genaue Bestimmung der Volumes für die Sicherung und Wiederherstellung innerhalb der Komponente. Nicht ausgewählte Volumes werden nicht gesichert. Während der Wiederherstellung werden alle während der Sicherung übersprungenen Volumes als leere Volumes wiederhergestellt.

In diesem Beispiel wird eine ProtectedApplication-Ressource erstellt, die das Dateisystem stilllegt, bevor das Logvolume gesichert wurde, und die Stilllegung nach der Sicherung wieder aufhebt:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: nginx
  namespace: sales
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: nginx
  components:
  - name: nginx-app
    resourceKind: Deployment
    resourceNames: ["nginx"]
    strategy:
      type: BackupAllRestoreAll
      backupAllRestoreAll:
        backupPreHooks:
        - name: fsfreeze
          container: nginx
          Commands: [ /sbin/fsfreeze, -f, /var/log/nginx ]
        backupPostHooks:
        - name: fsunfreeze
          container: nginx
          commands: [ /sbin/fsfreeze, -u, /var/log/nginx ]

Eine sichern und alle wiederherstellen

Mit dieser Strategie wird eine Kopie eines ausgewählten Pods gesichert. Diese eine Kopie ist die Quelle für die Wiederherstellung aller Pods während einer Wiederherstellung. Mit dieser Methode können Sie die Speicherkosten und die Sicherungszeit reduzieren. Diese Strategie funktioniert in einer Hochverfügbarkeitskonfiguration, wenn eine Komponente mit einem primären PersistentVolumeClaim und mehreren sekundären PersistentVolumeClaims bereitgestellt wird.

Für die Strategie „Eine sichern und alle wiederherstellen“ müssen Sie die folgenden Informationen in die Ressourcendefinition aufnehmen:

• Sicherungsziel: Gibt an, welche Deployment oder StatefulSet zum Sichern der Daten verwendet werden soll. Der beste zu sichernde Pod wird automatisch ausgewählt. In einer Konfiguration für Hochverfügbarkeit empfiehlt Google, von einem sekundären PersistentVolumeClaim zu sichern.
• Hooks: Definieren Befehle, die vor und nach dem Erstellen von Volume-Sicherungen ausgeführt werden, z. B. Schritte zum Stilllegen und Aufheben von Stilllegungen einer Anwendung. Diese Befehle werden nur für den ausgewählten Sicherungs-Pod ausgeführt.
• Volume-Auswahl: Ermöglicht eine genaue Bestimmung der Volumes für die Sicherung und Wiederherstellung innerhalb der Komponente.

Wenn eine Komponente mit mehreren Deployment- oder StatefulSet-Ressourcen konfiguriert ist, müssen alle Ressourcen dieselbe PersistentVolume-Struktur haben und die folgenden Regeln einhalten:

• Die Anzahl der PersistentVolumeClaim-Ressourcen, die von allen Deployment- oder StatefulSet-Ressourcen verwendet werden, muss identisch sein.
• Der Zweck von PersistentVolumeClaim-Ressourcen im selben Index muss identisch sein. Bei StatefulSet-Ressourcen wird der Index in der volumeClaimTemplate definiert. Bei Deployment-Ressourcen ist der Index in Volume-Ressourcen definiert und alle nicht nichtflüchtigen Volumes werden übersprungen.

Angesichts dieser Überlegungen können mehrere Volume-Sets für die Sicherung ausgewählt werden, aber nur ein Volume aus jedem Volume-Set wird ausgewählt.

In diesem Beispiel wird davon ausgegangen, dass die Architektur eines primären StatefulSet und eines sekundären StatefulSet eine Sicherung der Volumes in einem einzelnen Pod in einem sekundären StatefulSet und dann eine Wiederherstellung in allen anderen Volumes zeigt:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: mariadb
  namespace: mariadb
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: mariadb
  components:
  - name: mariadb
    resourceKind: StatefulSet
    resourceNames: ["mariadb-primary", "mariadb-secondary"]
    strategy:
      type: BackupOneRestoreAll
      backupOneRestoreAll:
        backupTargetName: mariadb-secondary
        backupPreHooks:
        - name: quiesce
          container: mariadb
          command: [...]
        backupPostHooks:
        - name: unquiesce
          container: mariadb
          command: [...]

Dump- und Ladevorgang

Diese Strategie verwendet ein dediziertes Volume für Sicherungs- und Wiederherstellungsprozesse und benötigt eine dedizierte PersistentVolumeClaim, die an eine Komponente angehängt ist, die Dumpdaten speichert. Für eine Dump- und Ladestrategie müssen Sie die folgenden Informationen in die Ressourcendefinition aufnehmen:

• Dump-Ziel: gibt an, welche Deployment oder StatefulSet für das Ausführen des Dump-Prozesses für die Daten verwendet werden soll. Der beste zu sichernde Pod wird automatisch ausgewählt. In einer Konfiguration für Hochverfügbarkeit wird empfohlen, von einem sekundären PersistentVolumeClaim zu sichern.
• Ladeziel: Gibt an, welche Deployment oder StatefulSet zum Laden der Daten verwendet werden sollen. Der beste zu sichernde Pod wird automatisch ausgewählt. Das Ladeziel muss nicht mit dem Dumpziel identisch sein.
• Hooks:Definiert die Befehle, die vor und nach dem Erstellen von Volume-Sicherungen ausgeführt werden. Es gibt bestimmte Hooks, die Sie für Dump- und Ladestrategien definieren müssen:
  • Dump-Hooks: Definiert die Hooks, die vor dem Sicherungsvorgang einen Dump der Daten in das dedizierte Volume ausführt. Dieser Hook wird nur auf dem ausgewählten Dump-Pod ausgeführt.
  • Lade-Hooks: Definiert die Hooks, die die Daten nach dem Start der Anwendung laden. Dieser Hook wird nur auf dem ausgewählten Lade-Pod ausgeführt.
  • Optional – Hooks nach der Sicherung: Definiert die Hooks, die nach der Sicherung der dedizierten Volumes ausgeführt werden, z. B. Bereinigungsschritte. Dieser Hook wird nur auf dem ausgewählten Dump-Pod ausgeführt.
• Volume-Auswahl:Gibt alle dedizierten Volumes an, in denen die Dumpdaten gespeichert werden. Sie müssen jeweils nur ein Volume pro Dump- und Lade-Pod auswählen.

Wenn die Anwendung aus Deployments besteht, muss jedes Deployment genau ein Replikat haben.

In diesem Beispiel wird davon ausgegangen, dass eine Architektur eines primären StatefulSet und eines sekundären StatefulSet mit dedizierten PersistentVolumeClaims für primäre und sekundäre StatefulSets eine Dump- und Ladestrategie hat:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: mariadb
  namespace: mariadb
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: mariadb
  components:
  - name: mariadb-dump
    resourceKind: StatefulSet
    resourceNames: ["mariadb-primary", "mariadb-secondary"]
    backupStrategy:
      type: DumpAndLoad
      DumpAndLoad:
        loadTarget: mariadb-primary
        dumpTarget: mariadb-secondary
        dumpHooks:
        - name: db_dump
          container: mariadb
          commands:
          - bash
          - "-c"
          - |
            mysqldump -u root --all-databases > /backup/mysql_backup.dump
        loadHooks:
        - name: db_load
          container: mariadb
          commands:
          - bash
          - "-c"
          - |
            mysql -u root < /backup/mysql_backup.sql
    volumeSelector:
      matchLabels:
        gkebackup.gke.io/backup: dedicated-volume

Nächste Schritte

• Eine Reihe von Sicherungen planen