보호되는 애플리케이션 전략

이 페이지에서는 Google Distributed Cloud (GDC) 에어 갭에서 사용할 수 있는 다양한 보호 애플리케이션 전략을 설명합니다.

보호된 애플리케이션 전략을 사용하면 특정 실행 전 및 실행 후 후크를 실행하고 상태 저장 워크로드의 중지, 백업 또는 복원을 위한 맞춤 동작을 정의할 수 있습니다.

ProtectedApplication 리소스를 정의할 때는 세 가지 백업 및 복원 전략을 사용할 수 있습니다.

• 모두 백업 및 모두 복원
• 하나만 백업하여 모두 복원
• 덤프 및 로드

전략 정의에는 다음 값이 포함될 수 있습니다.

유형	속성	설명
BackupAllRestoreAll		구성요소의 모든 항목을 백업하고 복원합니다.
	backupPreHooks	백업 전에 실행할 후크 목록입니다.
	backupPostHooks	백업 후에 실행할 후크 목록입니다.
	volumeSelector	백업할 영구 볼륨을 지정하는 라벨 선택기입니다. 비어 있으면 모든 PV가 선택됩니다.
backupOneRestoreAll		선택한 포드의 사본 하나를 백업하고 이를 사용하여 모든 포드를 복원합니다.
	backupTargetName	백업에 사용할 기본 Deployment 또는 StatefulSet의 이름입니다.
	backupPreHooks	백업 전에 실행할 후크 목록입니다.
	backupPostHooks	백업 후에 실행할 후크 목록입니다.
	volumeSelector	백업할 영구 볼륨을 지정하는 라벨 선택기입니다. 비어 있으면 모든 PV가 선택됩니다.
dumpAndLoad		백업 및 복원에 전용 볼륨을 사용합니다.
	dumpTarget	구성요소 데이터를 덤프하는 데 사용되는 기본 Deployment 또는 StatefulSet의 이름을 지정합니다. 타겟 포드는 이 구성요소가 구성된 방식에 따라 선택됩니다. 배포: 타겟 Deployment에 의해 생성된 포드를 선택합니다. 단일 StatefulSet: 복제본 수가 2보다 큰 경우 타겟 StatefulSet에서 생성된 두 번째 포드를 선택합니다. 그렇지 않으면 포드를 하나만 선택합니다. Multi-StatefulSet: 타겟 StatefulSet에 의해 생성된 첫 번째 포드를 선택합니다.
	loadTarget	구성요소 데이터를 로드하는 데 사용되는 기본 Deployment 또는 StatefulSet의 이름을 지정합니다. 타겟 포드는 이 구성요소가 구성된 방식에 따라 선택됩니다. 배포: 타겟 Deployment에 의해 생성된 포드를 선택합니다. StatefulSet: 항상 타겟 StatefulSet에서 생성된 첫 번째 포드를 선택합니다.
	dumpHooks	데이터를 덤프하는 데 사용되는 후크 목록입니다.
	backupPostHooks	백업 후에 실행할 후크 목록입니다.
	loadHooks	전용 볼륨에서 이 구성요소의 데이터를 로드하는 데 사용되는 후크 목록입니다. 로드 완료 후 정리 단계도 포함될 수 있습니다. 실행 타겟 포드는 LoadTarget에서 선택한 포드 중 하나입니다.
	volumeSelector	백업할 영구 볼륨을 지정하는 라벨 선택기입니다. 비어 있으면 모든 PV가 선택됩니다.

모두 백업 및 모두 복원

이 전략은 백업 중 애플리케이션 리소스를 모두 백업하고 복원 중 이 리소스를 모두 복원합니다. 이 전략은 독립형 애플리케이션에 가장 적합합니다. 독립형 애플리케이션은 포드 간 복제가 없습니다.

모두 백업 및 모두 복원 전략의 경우 리소스 정의에 다음 정보를 포함합니다.

• 후크: 애플리케이션 정지 및 정지 해제 단계와 같이 볼륨 백업 수행 전후에 실행되는 명령어를 정의합니다. 이러한 명령어는 구성요소 내에 있는 모든 포드에서 실행됩니다.

• 볼륨 선택: 구성요소 내에서 백업 및 복원되는 볼륨을 더 세밀하게 제어할 수 있습니다. 선택되지 않은 볼륨은 백업되지 않습니다. 백업 중 건너뛴 볼륨은 복원 중 빈 볼륨으로 복원됩니다.

이 예시에서는 로그 볼륨을 백업하기 전에 파일 시스템을 정지하고 백업 후 정지 해제하는 ProtectedApplication 리소스를 만듭니다.

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 ]

하나만 백업하여 모두 복원

이 전략은 선택한 포드의 사본 하나를 백업합니다. 이 단일 사본이 복원 중 모든 포드를 복원하기 위한 소스입니다. 이 메서드는 스토리지 비용 및 백업 시간을 줄이는 데 도움이 됩니다. 이 전략은 구성요소가 하나의 기본 PersistentVolumeClaim과 여러 개의 보조 PersistentVolumeClaims로 배포되는 고가용성 구성에서 사용됩니다.

하나만 백업하여 모두 복원 전략의 경우 리소스 정의에 다음 정보를 포함해야 합니다.

• 백업 대상: 데이터 백업에 사용할 Deployment 또는 StatefulSet를 지정합니다. 최상의 백업 포드가 자동으로 선택됩니다. 고가용성 구성에서는 보조 PersistentVolumeClaim에서 백업하는 것이 좋습니다.
• 후크: 애플리케이션 정지 및 정지 해제 단계와 같이 볼륨 백업 수행 전후에 실행되는 명령어를 정의합니다. 이러한 명령어는 선택된 백업 포드에서만 실행됩니다.
• 볼륨 선택: 구성요소 내에서 백업 및 복원되는 볼륨을 더 세밀하게 제어할 수 있습니다.

구성요소가 여러 개의 Deployment 또는 StatefulSet 리소스로 구성된 경우 모든 리소스의 PersistentVolume 구조가 동일해야 하며 다음 규칙을 따라야 합니다.

• 모든 Deployment 또는 StatefulSet 리소스에 사용되는 PersistentVolumeClaim 리소스 수가 동일해야 합니다.
• 동일한 색인에 있는 PersistentVolumeClaim 리소스의 목적이 동일해야 합니다. StatefulSet 리소스의 경우 색인이 volumeClaimTemplate에 정의됩니다. Deployment 리소스의 경우 색인이 Volume 리소스에 정의되고 모든 비영구 볼륨을 건너뜁니다.

이러한 조건들을 고려하면 백업에 여러 개의 볼륨 집합을 선택할 수 있지만 각 볼륨 집합에서 하나의 볼륨만 선택됩니다.

이 예시에서는 기본 StatefulSet 하나와 보조 StatefulSet 하나로 이뤄진 구조를 가정해서 보조 StatefulSet에 있는 단일 포드 내 볼륨의 백업과 다른 모든 볼륨에 대한 복원을 보여줍니다.

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: [...]

덤프 및 로드

이 전략은 백업 및 복원 프로세스에 대해 전용 볼륨을 사용하며 덤프 데이터를 저장하는 구성요소에 연결된 전용 PersistentVolumeClaim이 필요합니다. 덤프 및 로드 전략의 경우 리소스 정의에 다음 정보를 포함해야 합니다.

• 덤프 대상: 데이터를 덤프하는 데 사용할 Deployment 또는 StatefulSet를 지정합니다. 최상의 백업 포드가 자동으로 선택됩니다. 고가용성 구성에서는 보조 PersistentVolumeClaim에서 백업하는 것이 좋습니다.
• 로드 대상: 데이터 로드를 위해 사용할 Deployment 또는 StatefulSet를 지정합니다. 최상의 백업 포드가 자동으로 선택됩니다. 로드 대상은 덤프 대상과 동일할 필요가 없습니다.
• 후크: 볼륨 백업 전후에 실행되는 명령어를 정의합니다. 덤프 및 로드 전략에서는 특정 후크를 정의해야 합니다.
  • 덤프 후크: 백업 전 전용 볼륨으로 데이터를 덤프하는 후크를 정의합니다. 이 후크는 선택된 덤프 포드에서만 실행됩니다.
  • 로드 후크: 애플리케이션 시작 후 데이터를 로드하는 후크를 정의합니다. 이 후크는 선택된 로드 포드에서만 실행됩니다.
  • 선택사항 - 포스트 백업 후크: 정리 단계와 같이 전용 볼륨이 백업된 후 실행되는 후크를 정의합니다. 이 후크는 선택된 덤프 포드에서만 실행됩니다.
• 볼륨 선택: 덤프 데이터를 저장하는 모든 전용 볼륨을 지정합니다. 각 덤프 및 로드 포드에 대해 볼륨을 하나만 선택해야 합니다.

애플리케이션이 Deployments로 구성된 경우 각 Deployment에는 정확히 하나의 복제본이 있어야 합니다.

이 예시에서는 기본 StatefulSet 하나와 기본 및 보조 StatefulSets에 대한 전용 PersistentVolumeClaims가 있는 보조 StatefulSet로 이뤄진 구조를 가정해서 덤프 및 로드 전략을 보여줍니다.

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

다음 단계

• 백업 집합 계획