Omnissa Access를 위한 재해 복구 구성

Omnissa Access는 공유 NFS 마운트가 있는 백업 및 복원 모델을 사용하여 재해 복구를 지원합니다. 이 모델에서 보조 클러스터는 기본 클러스터에서 생성된 백업 데이터에 액세스할 수 있습니다. 선언된 DR 이벤트가 발생하면 보조 클러스터가 수동으로 기본 클러스터로 승격되고 읽기/쓰기 트래픽을 처리합니다. 원래 사이트로의 페일백은 계획된 수동 작업입니다. 자동으로 발생하지 않습니다. 원래 기본 사이트를 사용할 수 있게 되면 계획된 페일백이 실행될 때까지 보조 역할로 유지됩니다.

이 항목에서는 페일오버 중에 NFS 백업 스토리지를 구성하고, 백업 스케줄을 관리하고, 필요한 부트스트랩 노드 데이터를 백업하고, 백업에서 Omnissa Access를 복원하는 방법을 설명합니다.

사전 요구 사항

재해 복구를 구성하기 전에 다음 조건이 충족되는지 확인합니다.

복제된 NFS 공유가 구성되어 있고 기본 클러스터 노드와 보조 클러스터 노드 모두에서 네트워크를 통해 액세스할 수 있습니다.
보조 클러스터는 소스 클러스터와 동일한 자산 번들 버전을 사용하여 배포됩니다.
암호 및 구성 파일을 백업하기 위해 기본 클러스터의 부트스트랩 노드에 대한 관리 액세스 권한이 있습니다.

NFS 서버에서 NFS 내보내기 구성

백업 서비스는 루트로 실행되므로 NFS 내보내기에 no_root_squash 옵션이 포함되어야 합니다. NFS 서버에서 /etc/exports의 내보내기 구성을 확인합니다.

cat /etc/exports

출력에는 다음 형식의 항목이 포함되어야 합니다.

<NFS-MOUNT-POINT> <NFS-CLIENT-IP>(rw,sync,no_subtree_check,no_root_squash)

<NFS-CLIENT-IP>는 마운트에 액세스할 수 있는 모든 클러스터 노드를 포함하는 IP 범위 또는 IP 집합입니다. 예를 들어 소스 클러스터 노드가 10.48.34.100–10.48.34.105 범위의 주소를 사용하는 경우 전체 서브넷을 포함하려면 <NFS-CLIENT-IP>를 10.48.34.0/24로 설정합니다. 페일오버 중에 보조 클러스터가 기본 클러스터로 승격되면 해당 노드 주소도 허용된 IP 범위 내에 있어야 합니다.

NFS 백업에 대한 profile.yml 구성

서비스가 배포되기 전에 공유 NFS 마운트에 백업을 작성하도록 소스 클러스터를 구성해야 합니다. 이러한 백업은 페일오버 중에 보조 클러스터를 복원하는 데 사용됩니다.

소스 클러스터의 부트스트랩 노드에서 /root/<cluster_name>/profile.yml을 엽니다.
다음 줄을 찾아서 NFS 서버 세부 정보로 채우고 주석 처리를 제거합니다.
```
nfs_host: <NFS-HOST-IP>
nfs_path: <NFS-MOUNT-POINT>
nfs_version: 4
```
파일을 저장한 다음 이 가이드의 4단계 및 5단계에 설명된 대로 서비스 배포를 계속 진행합니다.

참고: 초기 서비스 배포 전에 NFS 세부 정보가 profile.yml에 포함되지 않은 경우 나중에 NFS 세부 정보를 추가하고 백업 종속 서비스를 다시 배포합니다.
```
  > ```bash
  > wso services deploy -s postgres
  > wso services deploy -s control-plane-backup
  > wso services deploy -s opensearch
  > ```
```
보조 클러스터의 다른 시스템에서 NFS 마운트에 액세스할 수 있는지 확인하려면 별도의 가상 시스템에서 다음 명령을 실행합니다.
```
# Mount the NFS share manually to test connectivity
mount -t nfs <NFS-IP>:<NFS-MOUNT-POINT> /mnt

# List the NFS exports visible to the client
showmount -e <NFS-IP>
```
showmount -e의 출력에는 구성된 마운트 지점에 대한 항목이 포함되어야 합니다.
```
<NFS-MOUNT-POINT> <NFS-IP>
```

부트스트랩 노드 데이터 백업

복원을 계속하려면 기본 부트스트랩 노드의 다음 항목을 보조 부트스트랩 노드에서 사용할 수 있어야 합니다. DR 이벤트가 발생하기 전에 이러한 항목을 안전한 위치에 백업합니다.

Omnissa는 이 데이터를 서비스 백업에 사용되는 동일한 NFS 서버에 저장하되, 자동화된 백업 작업에 간섭이 발생하지 않도록 별도의 NFS 마운트에 저장할 것을 권장합니다.

항목	기본 부트스트랩 노드의 경로
TLS 인증서	`/root/<cluster_name>/cp-cluster/secrets/cp-cluster/tls`
Vault 봉인 해제 키 및 루트 키	`/root/<cluster_name>/cp-cluster/secrets/cp-cluster/vault`
서비스 배포 환경 변수	`/root/<cluster_name>/additional_env_vars.env`
Access 서비스 프로파일	`/root/<cluster_name>/access/access-profile.yml`

백업 빈도 및 보존 구성

부트스트랩 노드의 additional_env_vars.env 파일에 환경 변수를 설정하여 백업이 수행되는 빈도와 보존 기간을 제어할 수 있습니다. 이러한 설정은 실패 시 손실될 수 있는 최대 데이터 양인 RPO(복구 시점 목표)를 결정합니다.

변수	설명
`POSTGRESQL_FULL_BACKUP_CRON_SCHEDULE`	전체 데이터베이스 백업에 대한 Cron 스케줄
`POSTGRESQL_DIFF_BACKUP_CRON_SCHEDULE`	데이터베이스 델타 백업에 대한 Cron 스케줄
`CONTROL_PLANE_BACKUP_CRON_SCHEDULE`	제어부 구성 요소 백업(Nomad, Consul, Vault)에 대한 Cron 스케줄
`KEEP_DAYS_CP`	제어부 백업에 대한 보존 기간(일)
`WALG_RETENTION_DAYS`	데이터베이스 백업에 대한 보존 기간(일)
`KEEP_DAYS_POSTGRES_BACKUP_LOGS`	데이터베이스 백업 로그 파일에 대한 보존 기간(일)

데이터베이스 백업 유형

Omnissa Access는 PostgreSQL 데이터베이스에 대해 두 가지 보완적인 백업 유형을 사용합니다.

전체 백업

전체 백업은 특정 시점에 전체 PostgreSQL 데이터 디렉토리의 전체 스냅샷을 캡처합니다. 전체 백업은 자체 포함되며 추가 백업 파일 없이 복원할 수 있습니다. 기본적으로 전체 데이터베이스 백업은 매일 **오전 5시(UTC)**에 한 번씩 실행되며 델타 백업의 기준선 역할을 합니다.

델타 백업

델타 백업은 가장 최근의 전체 백업 이후 변경된 데이터 페이지만 캡처합니다. 델타 백업은 전체 백업보다 작고 빠르게 완료할 수 있지만 자체 포함되지 않습니다. 델타 백업에서 복원하려면 가장 최근의 전체 백업과 델타 백업이 모두 필요합니다. 기본적으로 델타 백업은 매일 **오후 5시(UTC)**에 한 번씩 실행됩니다.

전체 및 델타 백업 작업은 전체 일별 적용 범위를 제공합니다. 스케줄링된 백업 간에 발생하는 장애에서 복원은 최신 델타가 적용된 최신 전체 백업을 사용하여 잠재적 데이터 손실을 약 12시간 이내로 제한합니다.

델타 백업 체인 깊이

단일 전체 백업 위에 체인으로 연결할 수 있는 델타 백업 계층의 최대 수는 2로 고정되어 있습니다. 이 제한은 WALG_DELTA_MAX_STEPS에 의해 내부적으로 적용되며 구성할 수 없습니다.

Full Backup (base)
└── Delta 1 (changes since Full Backup)
    └── Delta 2 (changes since Delta 1)  ← maximum chain depth

체인이 구성된 최대값에 도달하면 WAL-G는 스케줄링된 다음 델타 백업을 새 전체 백업으로 자동으로 승격합니다.

전체 및 델타 백업에 대한 스케줄을 조정할 수 있지만 연속적인 전체 백업 사이에 두 개 이상의 델타 백업이 실행되지 않도록 해야 합니다. 이 제한을 초과하는 것은 지원되지 않습니다.

FQDN 및 네트워킹 요구 사항

최종 사용자 또는 커넥터 구성을 변경할 필요 없이 페일오버를 지원하려면 DR 이벤트가 발생하기 전에 보조 클러스터가 다음 요구 사항을 충족해야 합니다.

보조 클러스터 끝점의 TLS 인증서는 기본 클러스터와 동일한 FQDN(정규화된 도메인 이름)에 대해 유효해야 합니다. 인증서 순환 프로세스는 기본 사이트와 보조 사이트 모두에 일관되게 적용되어야 합니다.
방화벽 규칙은 기본 및 보조 클러스터 끝점 모두에 대한 아웃바운드 트래픽을 허용해야 합니다. 두 사이트 모두에 대해 게시된 IP 주소 범위를 적극적으로 유지 보수해야 합니다.
커넥터 세션 상태는 보조 게이트웨이에서 완전히 재구축할 수 있어야 하며, 기본 클러스터에만 존재하는 세션 스토리지에 대한 하드 종속성이 없어야 합니다.

백업에서 Omnissa Access 복원

이 절차에서는 페일오버 중에 보조 클러스터를 새 기본 클러스터로 활성화하는 방법을 설명합니다. 복원이 완료되면 보조 클러스터는 모든 읽기 및 쓰기 트래픽을 처리합니다. 원래 기본 클러스터는 다시 사용할 수 있게 되면 계획된 페일백이 수행될 때까지 새 보조 클러스터로 처리됩니다.

중요: 이 절차를 시작하기 전에 보조 클러스터에서 원래 기본 클러스터에 연결할 수 없는지 확인합니다. 복원하는 동안 원래 클러스터에 여전히 연결할 수 있는 경우 OpenSearch 및 PostgreSQL은 원래 클러스터의 노드를 복원된 클러스터에 추가하려고 시도할 수 있습니다.

참고: Omnissa는 운영 환경에 재해 복구를 배포하기 전에 비운영 환경에서 정기적인 복원 훈련을 수행할 것을 권장합니다. 이렇게 하면 실제 데이터 볼륨을 기반으로 실제 RTO(복구 시간 목표) 추정치가 설정됩니다.

사전 요구 사항

복원 절차를 시작하기 전에 다음을 확인합니다.

보조 클러스터는 모든 Omnissa Access 서비스 이미지가 일치하도록 소스 클러스터와 동일한 자산 번들 버전을 사용하여 배포됩니다.
부트스트랩 노드 데이터 백업에 나열된 부트스트랩 노드 데이터는 보조 부트스트랩 노드에서 액세스할 수 있습니다.

절차

1단계: 보조 클러스터 배포

새 가상 시스템을 프로비저닝하고 소스 클러스터와 동일한 자산 번들 버전을 사용하여 제어부 자산 번들을 배포합니다. 보조 클러스터는 소스 클러스터와 동일한 구성을 가져야 합니다.

중요: 이 단계에서는 CP 플랫폼 서비스(Vault, Consul 및 Nomad)만 배포합니다. 이 단계에서는 Omnissa Access 서비스를 배포하지 마십시오. Access 서비스는 절차의 후반부에 복원됩니다.

계속하기 전에 보조 부트스트랩 노드에서 디렉토리 /root/<cluster_name>/cp-cluster/secrets/cp-cluster를 백업합니다.

예상 시간: 30분

2단계: 보조 클러스터 노드 스냅샷 생성

제어부가 성공적으로 배포되면 모든 보조 클러스터 노드의 가상 시스템 스냅샷을 생성합니다. 이러한 스냅샷은 재해 복구 절차를 다시 시작해야 하는 경우 정상 상태의 복원 지점을 제공합니다.

참고: 복원 절차 중에 언제든지 이러한 스냅샷으로 되돌리는 경우 계속하기 전에 보조 클러스터에서 Vault가 봉인 해제되어 있는지 확인합니다. 적절한 자격 증명을 사용하여 Vault UI에 로그인하여 Vault 상태가 봉인 해제되었는지 확인합니다.

3단계: 보조 클러스터에 암호 복사

백업 위치에서 보조 클러스터의 backup_secrets 디렉토리로 tls 및 vault 폴더를 복사합니다.

백업된 tls 폴더를 다음에 복사 → /root/<cluster_name>/cp-cluster/backup_secrets/tls
백업된 vault 폴더를 다음에 복사 → /root/<cluster_name>/cp-cluster/backup_secrets/vault

복사한 후 보조 부트스트랩 노드의 backup_secrets 디렉토리에 다음 두 폴더가 포함되어 있는지 확인합니다.

ls -lrt backup_secrets/
total 0
drwxr-x---. 2 root root 64 May  7 07:46 tls
drwxr-x---. 4 root root 30 May  7 07:46 vault

4단계: 백업 복원 계획

보조 클러스터 디렉토리에서 다음 명령을 실행하여 백업을 검토하고 복원 지점을 확인합니다.

wso cp plan-restore-backup

특정 시점으로부터 복원하려면 -a 플래그와 함께 기간을 사용합니다. 예:

플래그	의미
`-a 1d`	1일 전까지의 최신 백업
`-a 2h`	2시간 전까지의 최신 백업
`-a 30m`	30분 전까지의 최신 백업

이 플래그는 복원 작업에 대한 RPO를 설정합니다.

5단계: 제어부 구성 요소 복원

이 단계에서는 Consul 키-값 데이터 및 Vault 암호를 보조 클러스터로 복원합니다.

보조 클러스터에서 Vault가 봉인 해제되었는지 확인합니다.
복원 명령을 실행하기 전에 tls 및 vault 폴더가 보조 부트스트랩 노드의 backup_secrets에 있는지 확인합니다.
```
ls -lrt /root/<cluster_name>/cp-cluster/backup_secrets/
```
출력에는 tls 및 vault 디렉토리가 모두 표시되어야 합니다.
```
drwxr-x---. 2 root root 64 <date> tls
drwxr-x---. 4 root root 30 <date> vault
```

클러스터 디렉토리에서 다음을 실행합니다.

wso cp restore-backup

명령에서는 Consul 키-값 데이터 및 Vault 암호를 보조 클러스터로 복원합니다. 예상되는 출력:

Imports KV in case of disaster recovery
Backing up control plane credentials
Restoring vault
Restoring control plane credentials
Resetting vault integration tokens
Resetting vault integration token in nomad
Resetting vault PKI integration token
Updated vault with secrets after restore during Disaster recovery
Adding PKI root and intermediate CA to truststore
Deploying vault
Restarting vault servers
Unsealing Vault
Enabling consul and nomad integration with vault
Deploying consul
Configuring consul connect CA provider
Restarting the consul leader
Restarting nomad scheduler agent
Cleaning up
Generating environment file with cluster details and secret tokens

참고: 이 단계에서 오류가 발생하는 경우 모든 보조 클러스터 가상 시스템을 2단계에서 생성된 스냅샷으로 되돌리고, 보조 클러스터에서 Vault가 봉인 해제되었는지 확인한 후 3단계부터 절차를 다시 시작합니다.

예상 시간: 15분

6단계: 서비스 복원

이 단계에서는 데이터베이스 및 모든 서비스를 복원합니다. 이 단계에서는 백업이 수행되지 않습니다.

환경 변수 파일을 백업 위치에서 보조 부트스트랩 노드로 복사합니다.
```
/root/<cluster_name>/additional_env_vars.env
```
Access 서비스 프로파일을 보조 부트스트랩 노드에 복사합니다.
```
/root/<cluster_name>/access/access-profile.yml
```
access-profile.yml 파일에서 다음을 수행합니다.
- 보조 클러스터의 IP 주소 및 구성을 반영하도록 ip_ignore_list_for_xff_header 및 fqdn.ip 필드를 업데이트합니다.
- ip_ignore_list_for_xff_header 목록에 Nomad 서브넷을 추가합니다.
  - 참고: 기본값은 172.26.64.0/20입니다. 사용자 지정 서브넷으로 배포하도록 선택한 경우 그에 따라 ip_ignore_list_for_xff_header 필드의 서브넷 값을 업데이트합니다.
DNS 서버를 업데이트하여 FQDN을 보조 클러스터로 연결합니다.
원래 기본 클러스터가 오프라인 상태이거나 연결할 수 없는지 확인합니다.
다음 명령을 실행하여 모든 서비스를 복원합니다.
```
wso services restore --cps_image <cps-image>
```
참고: 이 단계에서 작업이 실패하면 해당 작업을 제거하고 동일한 명령을 다시 실행합니다.

특정 서비스만 복원하려면 -s 플래그를 포함합니다.
```
wso services restore -s <service-name> --cps_image <cps-image>
```
여기서 <cps-image>는 소스 클러스터 배포와 일치하는 제어부 서비스 이미지 태그입니다.

참고: 이 단계에서 오류가 발생하는 경우 모든 보조 클러스터 가상 시스템을 2단계에서 생성된 스냅샷으로 되돌리고, 보조 클러스터에서 Vault가 봉인 해제되었는지 확인한 후 3단계부터 절차를 다시 시작합니다.

예상 시간: 최소 75분. 실제 시간은 PostgreSQL 및 OpenSearch의 데이터 볼륨으로 선형으로 확장됩니다.

7단계: 복원 완료 및 백업 작업 재개

다음 명령을 실행하여 복원된 데이터를 확인하고 새로 승격된 기본 클러스터에서 백업 작업을 사용하도록 설정합니다.

wso services restore-complete --cps_image <cps-image>

예상 시간: 10분

복구 시간 목표

총 RTO(복구 시간 목표)는 PostgreSQL 및 OpenSearch의 데이터 볼륨에 따라 다릅니다. 예상되는 최소 RTO는 약 2시간이며 실제 시간은 데이터 볼륨에 비례하여 증가합니다. Omnissa는 운영 페일오버에서 이 절차에 의존하기 전에 배포와 관련된 RTO 수치를 설정하기 위해 정기적인 복원 훈련을 수행할 것을 권장합니다.

이 페이지가 도움이 되었나요?

Omnissa Access를 위한 재해 복구 구성

사전 요구 사항

NFS 서버에서 NFS 내보내기 구성

NFS 백업에 대한 profile.yml 구성

부트스트랩 노드 데이터 백업

백업 빈도 및 보존 구성

데이터베이스 백업 유형

전체 백업

델타 백업

FQDN 및 네트워킹 요구 사항

백업에서 Omnissa Access 복원

사전 요구 사항

절차

1단계: 보조 클러스터 배포

2단계: 보조 클러스터 노드 스냅샷 생성

3단계: 보조 클러스터에 암호 복사

4단계: 백업 복원 계획

5단계: 제어부 구성 요소 복원

6단계: 서비스 복원

7단계: 복원 완료 및 백업 작업 재개

복구 시간 목표

이 항목에 대한 피드백 보내기

리뷰 작성