비즈니스 연속성

클러스터 백업 및 복원 Operator 솔루션은 관리 클러스터, 애플리케이션 및 정책과 같은 모든 허브 클러스터 리소스에 대한 백업 및 복원 지원을 제공합니다. 솔루션을 사용하여 기본 허브 클러스터 설치를 확장하는 타사 리소스를 백업할 수 있습니다. 이 백업 솔루션을 사용하면 지정된 시간 간격에 실행되고 최신 버전의 허브 클러스터 콘텐츠를 지속적으로 백업하는 cron 기반 백업 일정을 정의할 수 있습니다.

허브 클러스터를 교체해야 하거나 허브 클러스터가 실패할 때 재해 시나리오에 있는 경우 새 허브 클러스터를 배포하고 백업할 수 있으며 새 허브 클러스터로 이동됩니다.

클러스터 백업 및 복원 프로세스의 다음 목록과 백업 데이터를 식별하기 위해 리소스 및 그룹을 백업 또는 제외하는 방법을 확인합니다.

리소스 유형 또는 라벨 주석을 기반으로 별도의 백업 파일로 그룹화되는 허브 클러스터 리소스를 백업하는 데 Red Hat Advanced Cluster Management 일정을 사용할 수 있습니다.

BackupSchedule.cluster.open-cluster-management.io 리소스는 4개의 schedule.velero.io 리소스 세트를 생성합니다. 이러한 schedule.velero.io 리소스는 리소스라고도 하는 백업 파일을 생성합니다.

예약된 백업 파일 목록을 보려면 다음 명령을 실행합니다. oc get schedules -A | grep acm.

예약된 백업 파일은 backup.velero.io 입니다. 예약된 백업 파일에 대한 설명을 보려면 다음 표를 참조하십시오.

cluster.open-cluster-management.io/backup 레이블을 리소스에 추가하면 백업 acm- credentials-schedule-schedule-에 백업된 Secrets 및 ConfigMap 리소스를 제외하고 acm-resources-generic-schedule 백업 에서 리소스가 자동으로 백업됩니다. 관리 클러스터를 새 허브 클러스터로 이동한 후, 복원된 리소스에서 veleroManagedClustersBackupName:latest 를 사용할 때 리소스를 복원해야 하는 경우 레이블 값을 cluster-activation 으로 설정합니다.

cluster.open-cluster-management.io/backup 레이블을 cluster-activation 으로 설정하면 관리 클러스터를 활성화하지 않는 한 리소스가 복원되지 않도록 합니다. 다음 예제를 확인합니다.

apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

참고: 관리되는 클러스터 네임스페이스 또는 해당 리소스의 경우 클러스터 활성화 단계에서 하나씩 복원해야 합니다. 따라서 관리 클러스터 네임스페이스에서 생성된 백업 리소스에 추가해야 하는 경우 cluster.open-cluster-management.io/backup 레이블에 cluster-activation 값을 사용합니다. 복원 프로세스를 이해하려면 다음 정보를 참조하십시오.

cluster.open-cluster-management.io/backup: cluster-activation 라벨을 사용하여 식별되고 acm-resources-generic-schedule 백업으로 저장된 활성화 데이터 리소스 외에도 클러스터 백업 및 복원 Operator에는 기본적으로 설정된 활성화에 몇 가지 리소스가 포함됩니다. 다음 리소스는 acm-managed-clusters-schedule 백업에서 지원합니다.

클러스터에 cluster.open-cluster-management.io/backup 레이블을 리소스에 추가하여 클러스터 백업 및 복원을 통해 타사 리소스를 백업할 수 있습니다. 레이블 값은 빈 문자열을 포함하여 모든 문자열이 될 수 있습니다. 백업 중인 구성 요소를 식별하는 데 도움이 되는 값을 사용합니다. 예를 들어 IDP 솔루션에서 구성 요소를 제공하는 경우 cluster.open-cluster-management.io/backup: idp 레이블을 사용합니다.

참고: 관리 클러스터 활성화 리소스가 복원될 때 리소스를 복원하려면 cluster.open-cluster-management.io/backup 라벨에 cluster-activation 값을 사용합니다. 관리 클러스터 활성화 리소스를 복원하면 허브 클러스터에서 적극적으로 관리하는 관리 클러스터에 대한 복원이 시작됩니다.

활성-패시브 구성에는 하나의 활성 허브 클러스터 및 패시브 허브 클러스터가 있습니다. 활성 허브 클러스터는 BackupSchedule.cluster.open-cluster-management.io 리소스를 사용하여 정의된 시간 간격으로 클러스터를 관리하고 리소스를 백업하는 기본 허브 클러스터로 간주됩니다.

참고: 기본 허브 클러스터 데이터를 백업하려면 활성-패시브 구성이 필요하지 않습니다. 허브 클러스터 데이터를 간단히 백업하고 저장할 수 있습니다. 이렇게 하면 문제 또는 오류가 있는 경우 새 허브 클러스터를 배포하고 이 새 허브 클러스터에서 기본 허브 클러스터 데이터를 복원할 수 있습니다. 기본 허브 클러스터 데이터를 복구하는 시간을 줄이기 위해 활성-패시브 구성을 사용할 수 있지만 이는 필요하지 않습니다.

패시브 허브 클러스터는 최신 백업을 지속적으로 검색하고 패시브 데이터를 복원합니다. 수동 허브는 Restore.cluster.open-cluster-management.io 리소스를 사용하여 새 백업 데이터를 사용할 수 있는 경우 기본 허브 클러스터에서 수동 데이터를 복원합니다. 이러한 허브 클러스터는 기본 허브 클러스터가 실패할 때 기본 허브가 되기 위해 대기 중입니다.

활성 및 수동 허브 클러스터는 동일한 스토리지 위치에 연결됩니다. 여기서 기본 허브 클러스터는 기본 허브 클러스터 백업에 액세스하기 위해 패시브 허브 클러스터의 데이터를 백업합니다. 이 자동 복원 구성을 설정하는 방법에 대한 자세한 내용은 백업을 확인하는 동안 수동 리소스 복구를 참조하십시오.

다음 다이어그램에서 활성 허브 클러스터는 로컬 클러스터를 관리하고 정기적으로 허브 클러스터 데이터를 백업합니다.

패시브 허브 클러스터는 관리 클러스터를 패시브 허브 클러스터로 이동하는 관리형 클러스터 활성화 데이터를 제외하고 이 데이터를 복원합니다. 패시브 허브 클러스터는 패시브 데이터를 지속적으로 복원할 수 있습니다. 패시브 허브 클러스터는 수동 데이터를 일회성 작업으로 복원할 수 있습니다. 자세한 내용은 수동 리소스 복원을 참조하십시오.

허브 관리자로 기본 허브 클러스터가 실패하면 관리 클러스터를 인수할 패시브 허브 클러스터를 선택할 수 있습니다. 다음 재해 복구 다이어그램에서 Hub 클러스터 N 을 새 기본 허브 클러스터로 사용하는 방법을 참조하십시오.

Hub 클러스터 N 은 관리되는 클러스터 활성화 데이터를 복원합니다. 관리형 클러스터는 Hub 클러스터 N 에 연결됩니다. BackupSchedule.cluster.open-cluster-management.io 리소스를 생성하고 초기 기본 허브 클러스터와 동일한 스토리지 위치에 백업을 저장하여 새 기본 허브 클러스터인 Hub 클러스터 N 에서 백업을 활성화합니다.

다른 모든 패시브 허브 클러스터는 이제 새 기본 허브 클러스터에서 생성된 백업 데이터를 사용하여 패시브 데이터를 복원합니다. Hub N 은 이제 클러스터를 관리하고 데이터를 백업하는 기본 허브 클러스터입니다.

중요:

수동 리소스에 대한 자세한 내용은 다음 복원 옵션을 참조하십시오.

backup 및 restore Operator를 사용하려면 hub 클러스터를 설정해야 합니다. 허브 클러스터를 설정하려면 다음 섹션을 순서대로 완료합니다.

MultiClusterHub 리소스가 처음 생성될 때 클러스터 백업 및 복원 Operator를 활성화할 수 있습니다. cluster-backup 매개 변수는 true 로 설정됩니다. Operator가 활성화되면 Operator 리소스가 설치됩니다.

MultiClusterHub 리소스가 이미 생성된 경우 MultiClusterHub 리소스를 편집하여 클러스터 백업 Operator를 설치하거나 제거할 수 있습니다. 클러스터 백업 Operator를 설치 제거하려면 cluster-backup Operator를 false 로 설정합니다.

백업 및 복원 Operator가 활성화되면 MultiClusterHub 리소스는 다음 YAML 파일과 유사할 수 있습니다.

apiVersion: operator.open-cluster-management.io/v1
  kind: MultiClusterHub
  metadata:
    name: multiclusterhub
    namespace: open-cluster-management
  spec:
    availabilityConfig: High
    enableClusterBackup: false
    imagePullSecret: multiclusterhub-operator-pull-secret
    ingress:
      sslCiphers:
        - ECDHE-ECDSA-AES256-GCM-SHA384
        - ECDHE-RSA-AES256-GCM-SHA384
        - ECDHE-ECDSA-AES128-GCM-SHA256
        - ECDHE-RSA-AES128-GCM-SHA256
    overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: true
          name: cluster-backup
    separateCertificateManagement: false

허브 클러스터가 패시브에서 기본 허브 클러스터로 상태를 변경하거나 기본 허브 클러스터에서 동일한 스토리지 위치에서 데이터를 백업하는 경우 백업 충돌이 발생할 수 있습니다.

결과적으로 더 이상 기본 허브 클러스터로 설정되지 않은 허브 클러스터에서 최신 백업을 생성합니다. BackupSchedule.cluster.open-cluster-management.io 리소스가 여전히 활성화되어 있기 때문에 이 허브 클러스터는 여전히 백업을 생성합니다.

재해 복구 테스트 작업과 같이 제어된 환경에서 복원 작업을 실행하는 경우 백업 허브 클러스터에서 BackupSchedule paused 속성을 사용할 때 백업 충돌을 방지할 수 있습니다. 새 허브 클러스터에서 리소스를 복원하기 전에 BackupSchedule 리소스에서 paused=true 속성을 설정하여 백업 허브에서 BackupSchedule 리소스를 일시 중지합니다.

백업 충돌을 일으킬 수 있는 두 가지 시나리오에 대해 알아보려면 다음 목록을 참조하십시오.

이 경우 현재 허브 클러스터 BackupSchedule.cluster.open-cluster-management.io 리소스 상태가 BackupCollision 으로 설정되고 이 리소스에서 생성한 Schedule.velero.io 리소스는 데이터 손상을 방지하기 위해 삭제됩니다. BackupCollision 은 백업 정책에 의해 보고됩니다. 관리자는 유효하지 않은 허브 클러스터에서 BackupSchedule.cluster.open-cluster-management.io 리소스를 제거하고 유효한 기본 허브 클러스터에서 새 BackupSchedule.cluster.open-cluster-management.io 리소스를 생성하기 전에 스토리지 위치에 쓰는 허브 클러스터를 확인하고 백업을 다시 시작합니다.

다음 명령을 실행하여 백업 충돌이 있는지 확인합니다.

oc get backupschedule -A

백업 충돌이 있는 경우 출력은 다음 예와 유사할 수 있습니다.

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

복원 작업을 사용하여 백업 작업에서 만든 3가지 백업 유형을 모두 복원합니다. 관리 클러스터만, 사용자 인증 정보 또는 허브 클러스터 리소스만 설치하도록 선택할 수 있습니다.

복원은 백업 파일 유형에 대해 복원 논리가 정의된 다음 3가지 필수 spec 속성을 정의합니다.

restore.cluster.open-cluster-management.io 에서 생성한 restore.velero.io 리소스의 이름은 < restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name > 을 사용하여 생성됩니다. 다음 설명을 확인합니다.

참고: skip 이 백업 유형에 사용되는 경우 restore.velero.io 가 생성되지 않습니다.

클러스터 복원 리소스의 다음 YAML 샘플을 확인합니다. 이 샘플에서는 사용 가능한 최신 백업 파일을 사용하여 백업 파일의 세 가지 유형이 모두 복원됩니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

참고: 관리형 클러스터 백업의 acm-managed-clusters 백업이 다른 허브 클러스터에서 복원되는 경우 Hive API에서 생성한 관리 클러스터만 새 허브 클러스터와 자동으로 연결됩니다. 다른 모든 관리 클러스터는 Pending Import 상태로 유지되며 새 hub 클러스터로 다시 가져와야 합니다. 자세한 내용은 가져온 관리 클러스터 복원을 참조하십시오.

클러스터에서 백업 데이터를 복원해야 하는 경우 복원 작업 전에 사용자 리소스가 생성된 허브 클러스터 또는 기본 허브 클러스터를 사용하는 대신 새 클러스터를 생성합니다. 허브 클러스터 복원 작업 중에 복원 중인 백업 데이터의 일부가 아닌 경우 기존 리소스를 정리하도록 hub 클러스터 백업 복원을 구성할 수 있습니다. 복원은 이전 백업에서 만든 리소스를 정리하지만 사용자 리소스를 정리하지는 않습니다. 결과적으로 이 허브 클러스터에서 사용자가 생성한 리소스는 정리되지 않으므로 이 허브 클러스터의 데이터는 복원된 리소스와 함께 사용 가능한 데이터를 반영하지 않습니다.

패시브 허브에서만 복원 작업을 검증한 다음 기본 허브 클러스터를 사용하도록 다시 이동하는 재해 복구 테스트는 기본 허브 클러스터를 수동 클러스터로 사용할 수 있는 한 가지 상황입니다. 이 복구 테스트 시나리오에서는 허브 백업 시나리오만 테스트 중입니다. 기본 허브 클러스터를 사용하여 새 리소스를 생성하지 않습니다. 대신 백업 데이터가 기본 허브 클러스터에서 패시브 허브 클러스터로 일시적으로 이동했습니다. 모든 리소스를 이 허브 클러스터로 복원하는 경우 초기 기본 허브 클러스터를 기본 허브 클러스터로 다시 만들 수 있습니다. 이 작업은 관리 클러스터를 이 허브 클러스터로 다시 이동하는 post restore 작업을 실행합니다.

허브 클러스터에서 백업 데이터를 복원해야 하는 경우 기본 허브 클러스터 또는 복원 작업 전에 이전 사용자가 리소스를 생성한 허브 클러스터를 사용하는 대신 새 허브 클러스터를 생성합니다.

재해 복구 시나리오에서는 백업을 패시브 허브 클러스터로 복원할 때 재해 발생 중에 실패한 허브 클러스터와 동일한 허브 클러스터를 원하게 됩니다. 애플리케이션, 정책 및 추가 관리 클러스터와 같은 기타 사용자 리소스가 필요하지 않습니다.

이 허브 클러스터에서 백업을 복원할 때 이 허브 클러스터에서 관리하는 관리 클러스터가 있는 경우 복원 작업에서 해당 백업을 분리하고 클러스터 리소스를 삭제할 수 있습니다. 복원 작업에서는 복원된 백업에 포함되지 않은 리소스를 정리하여 이 허브 클러스터의 콘텐츠를 초기 허브 클러스터와 동일하게 만듭니다. 이 경우 관리 클러스터 워크로드가 분리 작업으로 삭제되므로 사용자 데이터가 손실될 수 있습니다.

새 허브 클러스터에서 복원 작업을 실행하기 전에 hub 클러스터를 수동으로 구성하고 초기 허브 클러스터에와 동일한 운영자를 설치해야 합니다. 초기 허브 클러스터와 동일한 네임스페이스에 Red Hat Advanced Cluster Management Operator를 설치하고, DataProtectionApplication 리소스를 만든 다음 초기 허브 클러스터가 이전에 데이터를 백업한 동일한 스토리지 위치에 연결해야 합니다.

MultiClusterEngine 리소스에 대한 변경 사항을 포함하여 Red Hat Advanced Cluster Management Operator가 생성한 MultiClusterHub 리소스의 초기 허브 클러스터에서와 동일한 구성을 사용합니다.

예를 들어, 초기 허브 클러스터에 Ansible Automation Platform, Red Hat OpenShift GitOps, cert-manager 와 같은 다른 Operator가 설치되어 있는 경우 복원 작업을 실행하기 전에 설치해야 합니다. 이렇게 하면 새 허브 클러스터가 초기 허브 클러스터와 동일한 방식으로 구성됩니다.

Velero는 현재 복원된 백업으로 변경된 경우 기존 리소스를 업데이트합니다. Velero는 이전 복원에서 생성된 리소스이며 현재 복원된 백업의 일부가 아닌 delta 리소스를 정리하지 않습니다. 이렇게 하면 새 허브 클러스터에서 허브 클러스터 데이터를 복원할 때 사용할 수 있는 시나리오가 제한됩니다. 복원이 한 번만 적용되지 않는 한 새 Hub 클러스터를 수동 구성으로 안정적으로 사용할 수 없습니다. 허브 클러스터의 데이터는 복원된 리소스에서 사용 가능한 데이터를 반영하지 않습니다.

이 제한을 해결하기 위해 Restore.cluster.open-cluster-management.io 리소스가 생성되면 백업 Operator는 허브 클러스터를 정리하는 후 복원 작업을 실행합니다. 이 작업은 현재 복원된 백업의 일부가 아닌 이전 Red Hat Advanced Cluster Management 복원에서 생성한 모든 리소스를 제거합니다.

복원 후 정리는 cleanupBeforeRestore 속성을 사용하여 정리할 오브젝트의 하위 집합을 식별합니다. 복원 후 정리에 다음 옵션을 사용할 수 있습니다.

참고:

restore-passive-sync 샘플을 사용하여 수동 데이터를 복원하면서 새 백업을 사용할 수 있는지 확인하고 자동으로 복원합니다. 새 백업을 자동으로 복원하려면 syncRestoreWithNewBackups 매개변수를 true 로 설정해야 합니다. 또한 최신 수동 데이터만 복원해야 합니다. 이 섹션의 끝에 샘플 예제를 찾을 수 있습니다.

VeleroResourcesBackupName 및 VeleroCredentialsBackupName 매개변수를 latest 로 설정하고 VeleroManagedClustersBackupName 매개변수를 건너뛰 려면 . VeleroManagedClustersBackupName 이 latest 로 설정된 직후 관리 클러스터는 새 허브 클러스터에서 활성화되며 이제 기본 허브 클러스터입니다.

활성화된 관리 클러스터가 기본 허브 클러스터가 되면 복원 리소스가 Finished 로 설정되고 true 로 설정된 경우에도 syncRestoreWithNewBackups 가 무시됩니다.

기본적으로 컨트롤러는 syncRestoreWithNewBackups 가 true 로 설정된 경우 30분마다 새 백업을 확인합니다. 새 백업이 있으면 백업된 리소스를 복원합니다. restoreSyncInterval 매개변수를 업데이트하여 검사 기간을 변경할 수 있습니다.

복원 작업이 완료된 후 동일한 복원 작업을 다시 실행하려면 동일한 사양 옵션을 사용하여 새 restore.cluster.open-cluster-management.io 리소스를 생성해야 합니다.

예를 들어 10분마다 백업을 확인하는 다음 리소스를 참조하십시오.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-sync
  namespace: open-cluster-management-backup
spec:
  syncRestoreWithNewBackups: true # restore again when new backups are available
  restoreSyncInterval: 10m # check for new backups every 10 minutes
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

restore-acm-passive 샘플을 사용하여 hub 클러스터 리소스를 수동 구성으로 복원합니다. 패시브 데이터는 보안, ConfigMap, 애플리케이션, 정책 및 관리되는 모든 클러스터 사용자 정의 리소스와 같은 백업 데이터로, 관리 클러스터와 허브 클러스터 간의 연결을 활성화하지 않습니다. 백업 리소스는 자격 증명 백업 및 복원 리소스를 통해 허브 클러스터에서 복원됩니다.

다음 샘플을 참조하십시오.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

패시브 허브 클러스터에서 활성화 데이터를 복원하기 전에 백업이 생성된 이전 허브 클러스터를 종료합니다. 기본 허브 클러스터가 여전히 실행 중인 경우 이 허브 클러스터에서 실행되는 조정 절차에 따라 더 이상 사용할 수 없는 관리 클러스터에 다시 연결하려고 합니다.

hub 클러스터에서 클러스터를 관리하려는 경우 restore-acm-passive-activate 샘플을 사용합니다. 이 경우 다른 데이터가 패시브 리소스를 사용하는 hub 클러스터에서 이미 복원되었다고 가정합니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-activate
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: skip
  veleroResourcesBackupName: skip

수동 리소스를 복원하는 방법에 따라 활성화 리소스를 복원할 수 있는 몇 가지 옵션이 있습니다.

관리되는 클러스터 활성화 데이터 또는 기타 활성화 데이터 리소스는 cluster.open-cluster-management.io/backup: cluster-activation 레이블을 사용할 때 관리 클러스터 백업 및 resource-generic 백업에 의해 저장됩니다. 새 허브 클러스터에서 활성화 데이터가 복원되면 관리 클러스터가 복원이 실행되는 허브 클러스터에서 적극적으로 관리되고 있습니다. Operator를 사용하는 방법을 알아보려면 백업 예약 및 복원을 참조하십시오.

모든 데이터를 복원하려면 다음 restore-acm 샘플을 사용합니다.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

hub 클러스터에서 restore.cluster.open-cluster-management.io 리소스를 생성한 후 다음 명령을 실행하여 복원 작업의 상태를 가져옵니다.

oc describe -n open-cluster-management-backup restore-acm

Hive API를 사용하여 기본 허브 클러스터와 연결된 관리형 클러스터만 활성화 데이터가 복원되는 새 허브 클러스터와 자동으로 연결됩니다. 이러한 클러스터는 클러스터 탭의 Create cluster 버튼을 사용하거나 CLI를 통해 Hive API에서 기본 허브 클러스터에 생성되었습니다. 초기 허브 클러스터와 연결된 관리 클러스터는 활성화 데이터가 복원될 때 Pending Import (가져오기)로 표시되고 새 허브 클러스터에서 다시 가져와야 합니다.

Hive는 허브 클러스터의 관리 클러스터 네임스페이스에 관리 클러스터 kubeconfig 를 저장하므로 Hive 관리 클러스터는 새 허브 클러스터와 연결할 수 있습니다. 새 hub 클러스터에서 백업 및 복원됩니다. 그런 다음 가져오기 컨트롤러는 Hive API를 사용하여 생성된 관리 클러스터에서만 사용할 수 있는 복원된 구성을 사용하여 관리 클러스터에서 부트스트랩 kubeconfig 를 업데이트합니다. 가져온 클러스터에서는 사용할 수 없습니다.

복원 작업 중에 새 hub 클러스터에서 가져온 클러스터를 다시 연결하려면 BackupSchedule 에서 자동 가져오기 기능을 활성화합니다. 자세한 내용은 자동 가져오기 활성화를 참조하십시오.

다음 YAML 예제를 보고 다양한 유형의 백업 파일을 복원합니다.

다음 명령을 사용하여 복원 이벤트에 대한 정보를 가져옵니다.

oc describe -n open-cluster-management-backup <restore-name>

이벤트 목록은 다음 샘플과 유사할 수 있습니다.

Spec:
  Cleanup Before Restore:               CleanupRestored
  Restore Sync Interval:                4m
  Sync Restore With New Backups:        true
  Velero Credentials Backup Name:       latest
  Velero Managed Clusters Backup Name:  skip
  Velero Resources Backup Name:         latest
Status:
  Last Message:                     Velero restores have run to completion, restore will continue to sync with new backups
  Phase:                            Enabled
  Velero Credentials Restore Name:  example-acm-credentials-schedule-20220406171919
  Velero Resources Restore Name:    example-acm-resources-schedule-20220406171920
Events:
  Type    Reason                   Age   From                Message
  ----    ------                   ----  ----                -------
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-generic-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-cluster-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      64m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-cluster-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406171920
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406171920
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-cluster-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-generic-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-hive-schedule-20220406171919

Managed Service Account 구성 요소를 사용하는 자동 가져오기 기능은 기본적으로 비활성화되어 있습니다. 자동 가져오기 기능을 활성화하려면 다음 단계를 완료합니다.

자동 가져오기 기능을 활성화하면 백업 구성 요소가 가져온 관리 클러스터 처리를 시작합니다.

토큰은 관리 서비스 계정을 생성할 때 관리 클러스터에 액세스할 수 있는 경우에만 생성됩니다. 그렇지 않으면 관리 클러스터를 사용할 수 있게 되면 나중에 생성됩니다.

다음 시나리오를 사용하면 새 허브 클러스터로 이동할 때 관리 클러스터를 자동으로 가져오지 못할 수 있습니다.

BackupSchedule 리소스에서 useManagedServiceAccount 매개변수를 false 로 설정하여 자동 가져오기 클러스터 기능을 비활성화할 수 있습니다. 다음 예제를 참조하십시오.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false

기본값은 false입니다. 값을 false 로 설정한 후 백업 Operator는 ManagedServiceAddon,ManagedServiceAccount, ManifestWork 를 포함하여 생성된 모든 리소스를 제거합니다. 리소스를 제거하면 허브 클러스터 및 관리 클러스터에서 자동 가져오기 토큰이 삭제됩니다.

서버 측 암호화는 스토리지 위치에서 데이터를 수신하는 애플리케이션 또는 서비스의 데이터 암호화입니다. 백업 메커니즘 자체는 전송 중 데이터(백업 스토리지 위치로 이동 중) 또는 미사용(백업 스토리지 위치에 있는 디스크에 저장됨)을 암호화하지 않습니다. 대신 오브젝트 및 스냅샷 시스템의 기본 메커니즘을 사용합니다.

모범 사례: 사용 가능한 백업 스토리지 서버 측 암호화를 사용하여 대상에서 데이터를 암호화합니다. 백업에는 허브 클러스터 외부에 저장할 때 암호화해야 하는 자격 증명 및 구성 파일과 같은 리소스가 포함되어 있습니다.

serverSideEncryption 및 kmsKeyId 매개변수를 사용하여 Amazon S3에 저장된 백업의 암호화를 활성화할 수 있습니다. 자세한 내용은 Backup Storage Location YAML 을 참조하십시오. 다음 샘플은 DataProtectionApplication 리소스를 설정할 때 AWS KMS 키 ID를 지정합니다.

spec:
  backupLocations:
    - velero:
        config:
          kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
          profile: default
          region: us-east-1

기타 스토리지 공급자의 구성 가능한 모든 매개 변수를 알아보려면 Velero 지원 스토리지 공급자를 참조하십시오.

복원 작업을 실행하고 허브 클러스터를 활성화하기 전에 기본 허브 클러스터를 준비해야 합니다.

기본 허브 클러스터를 준비하려면 다음 단계를 완료합니다.

기본 허브 클러스터를 준비한 후 새 허브 클러스터에서 복원 작업을 실행하고 관리 클러스터를 이동합니다. 이제 백업 허브 클러스터에서 자동 가져오기 기능이 비활성화되어 있으므로 관리 클러스터는 새 허브 클러스터에 연결하고 초기 허브 클러스터로 다시 이동하지 않습니다.

다음 단계를 완료하여 새 허브 클러스터에서 복원 작업을 실행합니다.

복원 및 관리 클러스터가 새 허브 클러스터에 성공적으로 연결되면 초기 백업 허브 클러스터에서 관리 클러스터 리소스를 정리합니다. 복구 테스트가 완료된 후 데이터를 백업으로 복원하려면 리소스 정리를 건너뜁니다.

백업 허브 클러스터에서 관리 클러스터를 정리하려면 다음 단계를 완료합니다.

중요:

Velero가 처음 설치되면 Velero pod는 다음 샘플에 정의된 대로 기본 CPU 및 메모리 제한으로 설정됩니다.

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi

이전 샘플의 제한은 일부 시나리오에서 잘 작동하지만 클러스터가 많은 리소스를 백업할 때 업데이트해야 할 수 있습니다. 예를 들어 2000 클러스터를 관리하는 허브 클러스터에서 백업이 실행되면 OOM(메모리 부족 오류)으로 인해 Velero Pod가 실패합니다. 다음 구성을 사용하면 이 시나리오에 대해 백업을 완료할 수 있습니다.

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

Velero pod 리소스에 대한 제한 및 요청을 업데이트하려면 DataProtectionApplication 리소스를 업데이트하고 Velero pod에 대한 resourceAllocation 템플릿을 삽입해야 합니다. 다음 샘플을 확인합니다.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi

복원 작업에 사용하려는 허브 클러스터가 이미 클러스터를 관리하고 cleanupBeforeRestore 옵션을 cleanup Restored 로 설정하여 복원 작업을 실행하는 경우 다음과 같은 결과를 기대할 수 있습니다.

이전 사용자가 생성한 데이터로 허브 클러스터를 복원하고 복원 작업을 위해 cleanupBeforeRestore d 옵션이 cleanup Restored 로 설정된 경우 복원 허브 클러스터의 리소스가 기본 허브 클러스터의 리소스와 일치하지 않습니다. 사용자 데이터에는 policy,application,Credential 또는 사용자가 정의한 사용자 정의 리소스 등 다음 리소스가 포함됩니다. 리소스가 사용자가 만들고 이전 백업에서 생성되지 않기 때문에 리소스가 정리되지 않습니다.

복원 허브 클러스터 구성에 기존 허브 클러스터를 사용하고 복원이 완료된 후 Hub 클러스터가 백업 허브 클러스터와 동일한 콘텐츠를 보유하려는 경우 허브 클러스터 백업의 일부가 될 모든 리소스에 태그를 지정합니다. 자세한 내용은 리소스 태그 지정을 참조하십시오.

복원 허브 클러스터에서 velero.io/backup-name: backupName 라벨을 사용하여 복원 허브 클러스터에서 사용자가 생성한 리소스에 태그를 지정하려면 다음 단계를 완료합니다.

Operator는 hub 클러스터 백업의 일부인 각 리소스를 살펴보고 velero.io/backup-name: backupName 으로 태그를 지정합니다. 여기서 backupName 은 최신 백업의 이름입니다.

리소스에 태그를 지정한 후 hub 클러스터를 복원 클러스터로 사용할 수 있습니다. 이제 DataProtectionApplication 스토리지 위치를 가리키도록 백업 허브 클러스터의 스토리지 위치를 업데이트하여 기본 허브 클러스터에서 데이터를 복원할 수 있으므로 hub 클러스터 백업 리소스를 사용하는 복원 작업을 실행할 수 있습니다.

모든 복원 허브 클러스터 리소스에 velero.io/backup-name 레이블이 태그되므로 hub 클러스터는 이전 복원을 통해 생성되는 것으로 표시됩니다. 따라서 cleanupBeforeRestore 옵션을 사용하여 기존 허브 클러스터에서 실행하는 모든 복원 작업은 복원된 백업의 일부가 아닌 데이터를 cleanup Restored 로 설정합니다.

중요:

복원 작업을 위해 백업 허브 클러스터를 준비하고 복원을 실행하려면 복원 프로세스 중에 기본 허브 클러스터를 활성 상태로 유지해야 합니다.

시뮬레이션을 시작하려면 다음 단계를 완료하여 새 허브 클러스터를 활성 허브 클러스터로 설정해야 합니다.

재해 복구 테스트가 완료되면 기본 허브 클러스터로 돌아가서 클러스터 플릿을 관리하는 활성 허브 클러스터로 만들 수 있습니다. 이 작업을 수행하려면 다음 섹션을 완료하여 기본 클러스터로 돌아갑니다.

EgressSync를 클러스터에 설치하기 전에 다음과 같은 요구 사항이 있어야 합니다.

EgressSync가 한 클러스터에 있는 영구 볼륨 클레임을 다른 클러스터의 영구 볼륨 클레임에 복제하려면 소스 및 대상 관리 클러스터 둘 다에volSync를 설치해야 합니다.

VXLANSync는 자체 네임스페이스를 생성하지 않으므로 다른 OpenShift Container Platform all-namespace Operator와 동일한 네임스페이스에 있습니다. volSync의 운영자 설정을 변경하면 채널 업데이트에 대한 수동 승인을 변경하는 경우와 같이 동일한 네임스페이스의 다른 Operator에도 영향을 미칩니다.

두 가지 방법 중 하나를 사용하여 환경에 있는 두 개의 클러스터에 ChronySync를 설치할 수 있습니다. hub 클러스터의 각 관리 클러스터에 레이블을 추가하거나 다음 섹션에 설명된 대로 수동으로 ManagedClusterAddOn 을 생성하고 적용할 수 있습니다.

Rsync-TLS 복제를 사용하여 영구 볼륨의 1:1 비동기 복제를 생성할 수 있습니다. 재해 복구 또는 원격 사이트로 데이터를 전송하는 데 Rsync-TLS 기반 복제를 사용할 수 있습니다. Rsync-TLS를 사용하는 경우 CryostatSync는 stunnel에서 제공하는 TLS 보호 터널에서 Rsync를 사용하여 데이터를 동기화합니다. 자세한 내용은 stunnel 설명서 를 참조하십시오.

다음 예제에서는 Rsync-TLS 메서드를 사용하여 구성하는 방법을 보여줍니다. Rsync-TLS에 대한 자세한 내용은 reflectSync 설명서의 사용을 참조하십시오. https://volsync.readthedocs.io/en/latest/usage/index.html

중요: 보안을 강화하려면 Rsync 대신 Rsync-TLS를 사용합니다. Rsync-TLS를 사용하면 영구 볼륨을 복제하는 데 필요하지 않은 승격된 사용자 권한을 사용하지 않을 수 있습니다.

Rsync 복제를 사용하여 영구 볼륨의 1:1 비동기 복제를 생성할 수 있습니다. 재해 복구 또는 원격 사이트로 데이터를 전송하는 데 Rsync 기반 복제를 사용할 수 있습니다.

다음 예제에서는 Rsync 메서드를 사용하여 구성하는 방법을 보여줍니다.

restic 기반 백업은 영구 볼륨의 restic 기반 백업 사본을 restic-config.yaml 시크릿 파일에 지정된 위치에 복사합니다. restic 백업은 클러스터 간에 데이터를 동기화하지 않지만 데이터 백업을 제공합니다.

restic 기반 백업을 구성하려면 다음 단계를 완료합니다.

참고: Restic movers는 기본적으로 root 권한 없이 실행됩니다. restic movers를 root로 실행하려면 다음 명령을 실행하여 상승된 권한 주석을 네임스페이스에 추가합니다.

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

& lt;namespace >를 네임스페이스 이름으로 바꿉니다.

Rclone 백업은 AWS S3와 같은 중간 오브젝트 스토리지 위치를 통해 Rclone을 사용하여 단일 영구 볼륨을 여러 위치에 복사합니다. 데이터를 여러 위치에 배포할 때 유용할 수 있습니다.

Rclone 복제를 구성하려면 다음 단계를 완료합니다.

참고: Rclone 이동기는 기본적으로 root 권한 없이 실행됩니다. Rclone movers를 root로 실행하려면 다음 명령을 실행하여 네임스페이스에 승격된 권한 주석을 추가합니다.

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

& lt;namespace >를 네임스페이스 이름으로 바꿉니다.

자세한 내용은 다음 항목을 참조하십시오.

소스 및 대상은 TLS 연결의 공유 키에 대한 액세스 권한이 있어야 합니다. keySecret 필드에서 키 위치를 찾을 수 있습니다. .spec.rsyncTLS.keySecret 에 시크릿 이름을 제공하지 않으면 시크릿 이름이 자동으로 생성되고 .status.rsyncTLS.keySecret 에 추가됩니다.

자체 보안을 생성하려면 다음 단계를 완료합니다.