Trident Protect 실행 후크 관리
변경 제안
PDF
실행 후크는 관리형 앱의 데이터 보호 작업과 함께 실행되도록 구성할 수 있는 사용자 지정 작업입니다. 예를 들어 데이터베이스 앱이 있는 경우 실행 후크를 사용하여 스냅샷 생성 전에 모든 데이터베이스 트랜잭션을 일시 중지하고 스냅샷 생성이 완료된 후 트랜잭션을 다시 시작할 수 있습니다. 이렇게 하면 애플리케이션 정합성 보장 스냅샷을 생성할 수 있습니다.
실행 후크의 유형
Trident Protect는 실행 가능 시점에 따라 다음과 같은 유형의 실행 후크를 지원합니다.
-
사전 스냅샷
-
스냅샷 이후
-
사전 백업
-
백업 후
-
복원 후
-
페일오버 후
실행 순서
데이터 보호 작업이 실행될 때 실행 후크 이벤트는 다음 순서로 발생합니다.
-
적용 가능한 사용자 지정 사전 작업 실행 후크는 해당 컨테이너에서 실행됩니다. 필요한 만큼 사용자 지정 사전 작업 후크를 생성하고 실행할 수 있지만, 작업 전에 이러한 후크가 실행되는 순서는 보장되지 않으며 구성할 수도 없습니다.
-
해당되는 경우 파일 시스템이 일시 중지됩니다. "Trident Protect를 사용한 파일 시스템 동결 구성에 대해 자세히 알아보십시오".
-
데이터 보호 작업이 수행됩니다.
-
동결된 파일 시스템은 해당되는 경우 동결이 해제됩니다.
-
적용 가능한 사용자 지정 사후 작업 실행 후크는 해당 컨테이너에서 실행됩니다. 필요한 만큼 사용자 지정 사후 작업 후크를 생성하고 실행할 수 있지만, 작업 후 이러한 후크의 실행 순서는 보장되지 않으며 구성할 수도 없습니다.
동일한 유형(예: pre-snapshot)의 실행 후크를 여러 개 생성하는 경우 해당 후크의 실행 순서는 보장되지 않습니다. 하지만 유형이 다른 후크의 실행 순서는 보장됩니다. 예를 들어, 다음은 모든 유형의 후크가 포함된 구성의 실행 순서입니다.
-
스냅샷 이전 후크가 실행되었습니다
-
스냅샷 후 후크가 실행되었습니다
-
사전 백업 후크 실행됨
-
백업 후 후크 실행됨
|
앞의 순서 예는 기존 스냅샷을 사용하지 않는 백업을 실행할 때만 적용됩니다. |
|
|
운영 환경에서 실행 후크 스크립트를 활성화하기 전에 항상 테스트해야 합니다. 'kubectl exec' 명령을 사용하여 스크립트를 편리하게 테스트할 수 있습니다. 운영 환경에서 실행 후크를 활성화한 후에는 생성된 스냅샷과 백업이 일관성을 유지하는지 테스트해야 합니다. 이를 위해 앱을 임시 네임스페이스에 복제하고 스냅샷 또는 백업을 복원한 다음 앱을 테스트하면 됩니다. |
|
|
스냅샷 실행 전 후크가 Kubernetes 리소스를 추가, 변경 또는 제거하는 경우 이러한 변경 사항은 스냅샷 또는 백업 및 이후의 모든 복원 작업에 포함됩니다. |
사용자 지정 실행 후크에 대한 중요 참고 사항
앱 실행 후크를 계획할 때 다음 사항을 고려하십시오.
-
실행 후크는 작업을 수행하기 위해 스크립트를 사용해야 합니다. 여러 실행 후크가 동일한 스크립트를 참조할 수 있습니다.
-
Trident Protect에서는 실행 후크가 사용하는 스크립트를 실행 가능한 셸 스크립트 형식으로 작성해야 합니다.
-
스크립트 크기는 96KB로 제한됩니다.
-
Trident Protect는 실행 후크 설정과 일치하는 기준을 사용하여 스냅샷, 백업 또는 복원 작업에 적용할 수 있는 후크를 결정합니다.
|
|
실행 후크는 종종 실행되는 애플리케이션의 기능을 제한하거나 완전히 비활성화하기 때문에 사용자 지정 실행 후크의 실행 시간을 최소화해야 합니다. 실행 후크가 연결된 백업 또는 스냅샷 작업을 시작한 후 취소하더라도 백업 또는 스냅샷 작업이 이미 시작된 경우 후크는 계속 실행될 수 있습니다. 즉, 백업 후 실행 후크에서 사용되는 로직은 백업이 완료되었다고 가정할 수 없습니다. |
실행 후크 필터
애플리케이션에 실행 후크를 추가하거나 편집할 때, 후크가 일치할 컨테이너를 관리하기 위해 필터를 추가할 수 있습니다. 필터는 모든 컨테이너에서 동일한 컨테이너 이미지를 사용하지만 각 이미지를 다른 용도로 사용하는 애플리케이션(예: Elasticsearch)에 유용합니다. 필터를 사용하면 실행 후크가 모든 동일한 컨테이너가 아닌 일부 컨테이너에서만 실행되는 시나리오를 만들 수 있습니다. 하나의 실행 후크에 여러 필터를 생성하는 경우 논리 AND 연산자로 결합됩니다. 실행 후크당 최대 10개의 활성 필터를 사용할 수 있습니다.
실행 후크에 추가하는 각 필터는 정규 표현식을 사용하여 클러스터의 컨테이너를 일치시킵니다. 후크가 컨테이너와 일치하면 해당 컨테이너에서 연결된 스크립트를 실행합니다. 필터에 사용되는 정규 표현식은 RE2(Regular Expression 2) 구문을 사용하며, 이 구문은 일치 목록에서 컨테이너를 제외하는 필터를 생성하는 것을 지원하지 않습니다. Trident Protect에서 실행 후크 필터의 정규 표현식에 대해 지원하는 구문에 대한 자세한 내용은 "정규식 2(RE2) 구문 지원"을 참조하십시오.
|
|
복원 또는 클론 작업 후에 실행되는 실행 후크에 네임스페이스 필터를 추가하고 복원 또는 클론 소스와 타겟이 서로 다른 네임스페이스에 있는 경우 네임스페이스 필터는 타겟 네임스페이스에만 적용됩니다. |
실행 후크 예
https://github.com/NetApp/Verda["NetApp Verda GitHub 프로젝트"]를 방문하여 Apache Cassandra 및 Elasticsearch와 같은 인기 애플리케이션의 실제 실행 후크를 다운로드하세요. 또한 예제를 살펴보고 자신만의 사용자 지정 실행 후크를 구성하는 데 필요한 아이디어를 얻을 수 있습니다.
실행 후크를 생성합니다
Trident Protect를 사용하여 앱에 대한 사용자 지정 실행 후크를 생성할 수 있습니다. 실행 후크를 생성하려면 소유자, 관리자 또는 구성원 권한이 필요합니다.
-
사용자 정의 리소스(CR) 파일을 생성하고 이름을 지정합니다
trident-protect-hook.yaml. -
다음 속성을 Trident Protect 환경 및 클러스터 구성에 맞게 구성합니다.
-
metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 환경에 맞는 고유하고 적절한 이름을 선택하세요.
-
spec.applicationRef: (필수) 실행 후크를 실행할 애플리케이션의 Kubernetes 이름입니다.
-
spec.stage: (필수) 실행 후크가 실행되어야 하는 작업 중 단계를 나타내는 문자열입니다. 가능한 값:
-
사전
-
게시
-
-
spec.action: (필수) 지정된 실행 후크 필터가 모두 일치하는 경우 실행 후크가 수행할 작업을 나타내는 문자열입니다. 가능한 값:
-
스냅샷
-
백업
-
복원
-
페일오버
-
-
spec.enabled: (선택 사항) 이 실행 후크가 활성화되었는지 비활성화되었는지 나타냅니다. 지정하지 않으면 기본값은 true입니다.
-
spec.hookSource: (필수) base64로 인코딩된 훅 스크립트를 포함하는 문자열입니다.
-
spec.timeout: (선택 사항) 실행 후크가 실행될 수 있는 시간을 분 단위로 정의하는 숫자입니다. 최소값은 1분이며, 지정하지 않으면 기본값은 25분입니다.
-
spec.arguments: (선택 사항) 실행 후크에 지정할 수 있는 인수의 YAML 목록입니다.
-
spec.matchingCriteria: (선택 사항) 실행 후크 필터를 구성하는 각 쌍의 기준 키-값 쌍의 선택적 목록입니다. 실행 후크당 최대 10개의 필터를 추가할 수 있습니다.
-
spec.matchingCriteria.type: (선택 사항) 실행 후크 필터 유형을 식별하는 문자열입니다. 가능한 값:
-
ContainerImage
-
ContainerName
-
PodName
-
PodLabel
-
NamespaceName
-
-
spec.matchingCriteria.value: (선택 사항) 실행 후크 필터 값을 식별하는 문자열 또는 정규 표현식입니다.
YAML 예:
apiVersion: protect.trident.netapp.io/v1 kind: ExecHook metadata: name: example-hook-cr namespace: my-app-namespace annotations: astra.netapp.io/astra-control-hook-source-id: /account/test/hookSource/id spec: applicationRef: my-app-name stage: Pre action: Snapshot enabled: true hookSource: IyEvYmluL2Jhc2gKZWNobyAiZXhhbXBsZSBzY3JpcHQiCg== timeout: 10 arguments: - FirstExampleArg - SecondExampleArg matchingCriteria: - type: containerName value: mysql - type: containerImage value: bitnami/mysql - type: podName value: mysql - type: namespaceName value: mysql-a - type: podLabel value: app.kubernetes.io/component=primary - type: podLabel value: helm.sh/chart=mysql-10.1.0 - type: podLabel value: deployment-type=production -
-
CR 파일에 올바른 값을 입력한 후 CR을 적용합니다.
kubectl apply -f trident-protect-hook.yaml
-
실행 후크를 생성할 때 괄호 안의 값을 환경 정보로 바꾸세요. 예를 들면 다음과 같습니다.
tridentctl-protect create exechook <my_exec_hook_name> --action <action_type> --app <app_to_use_hook> --stage <pre_or_post_stage> --source-file <script-file> -n <application_namespace>
수동으로 실행 후크 실행
테스트 목적으로 또는 오류 발생 후 수동으로 실행 후크를 다시 실행해야 하는 경우 수동으로 실행 후크를 실행할 수 있습니다. 수동으로 실행 후크를 실행하려면 소유자, 관리자 또는 멤버 권한이 필요합니다.
실행 후크를 수동으로 실행하는 것은 기본적으로 두 단계로 구성됩니다.
-
리소스 백업을 생성합니다. 이 백업은 리소스를 수집하고 백업을 생성하며 후크가 실행될 위치를 결정합니다
-
백업에 대해 실행 후크를 실행합니다
1단계: 리소스 백업 생성
-
사용자 정의 리소스(CR) 파일을 생성하고 이름을 지정합니다
trident-protect-resource-backup.yaml. -
다음 속성을 Trident Protect 환경 및 클러스터 구성에 맞게 구성합니다.
-
metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 환경에 맞는 고유하고 적절한 이름을 선택하세요.
-
spec.applicationRef: (필수) 리소스 백업을 생성할 애플리케이션의 Kubernetes 이름입니다.
-
spec.appVaultRef: (필수) 백업 콘텐츠가 저장되는 AppVault의 이름입니다.
-
spec.appArchivePath: 백업 콘텐츠가 저장되는 AppVault 내부 경로입니다. 다음 명령을 사용하여 이 경로를 찾을 수 있습니다.
kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'YAML 예:
--- apiVersion: protect.trident.netapp.io/v1 kind: ResourceBackup metadata: name: example-resource-backup spec: applicationRef: my-app-name appVaultRef: my-appvault-name appArchivePath: example-resource-backup -
-
CR 파일에 올바른 값을 입력한 후 CR을 적용합니다.
kubectl apply -f trident-protect-resource-backup.yaml
-
백업을 생성할 때 괄호 안의 값을 사용자 환경 정보로 바꿔주세요. 예를 들면 다음과 같습니다.
tridentctl protect create resourcebackup <my_backup_name> --app <my_app_name> --appvault <my_appvault_name> -n <my_app_namespace> --app-archive-path <app_archive_path> -
백업 상태를 확인하세요. 이 예시 명령어를 작업이 완료될 때까지 반복해서 사용할 수 있습니다.
tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name> -
백업이 성공했는지 확인합니다.
kubectl describe resourcebackup <my_backup_name>
2단계: 실행 후크 실행
-
사용자 정의 리소스(CR) 파일을 생성하고 이름을 지정합니다
trident-protect-hook-run.yaml. -
다음 속성을 Trident Protect 환경 및 클러스터 구성에 맞게 구성합니다.
-
metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 환경에 맞는 고유하고 적절한 이름을 선택하세요.
-
spec.applicationRef: (필수) 이 값이 1단계에서 생성한 ResourceBackup CR의 애플리케이션 이름과 일치하는지 확인하십시오.
-
spec.appVaultRef: (필수) 이 값이 1단계에서 생성한 ResourceBackup CR의 appVaultRef와 일치하는지 확인하십시오.
-
spec.appArchivePath: 이 값이 1단계에서 생성한 ResourceBackup CR의 appArchivePath와 일치하는지 확인하세요.
kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}' -
spec.action: (필수) 지정된 실행 후크 필터가 모두 일치하는 경우 실행 후크가 수행할 작업을 나타내는 문자열입니다. 가능한 값:
-
스냅샷
-
백업
-
복원
-
페일오버
-
-
spec.stage: (필수) 실행 후크가 실행되어야 하는 작업 중 단계를 나타내는 문자열입니다. 이 후크 실행은 다른 단계의 후크를 실행하지 않습니다. 가능한 값:
-
사전
-
게시
YAML 예:
-
--- apiVersion: protect.trident.netapp.io/v1 kind: ExecHooksRun metadata: name: example-hook-run spec: applicationRef: my-app-name appVaultRef: my-appvault-name appArchivePath: example-resource-backup stage: Post action: Failover -
-
CR 파일에 올바른 값을 입력한 후 CR을 적용합니다.
kubectl apply -f trident-protect-hook-run.yaml
-
수동 실행 후크 실행 요청을 생성합니다.
tridentctl protect create exechooksrun <my_exec_hook_run_name> -n <my_app_namespace> --action snapshot --stage <pre_or_post> --app <my_app_name> --appvault <my_appvault_name> --path <my_backup_name> -
실행 후크 실행 상태를 확인합니다. 작업이 완료될 때까지 이 명령을 반복해서 실행할 수 있습니다.
tridentctl protect get exechooksrun -n <my_app_namespace> <my_exec_hook_run_name> -
exechooksrun 객체를 설명하여 최종 세부 정보 및 상태를 확인합니다.
kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>