주:

이 자습서에서는 Oracle Cloud에 액세스해야 합니다. 무료 계정에 등록하려면 Oracle Cloud Infrastructure Free Tier 시작하기를 참조하십시오.
Oracle Cloud Infrastructure 자격 증명, 테넌시 및 구획에 예제 값을 사용합니다. 실습을 완료했으면 이러한 값을 자신의 클라우드 환경과 관련된 값으로 대체하십시오.

OCI Full Stack Disaster Recovery를 사용하여 Oracle HeatWave MySQL에 대한 콜드 재해 복구 자동화

소개

Oracle Cloud Infrastructure Full Stack Disaster Recovery(OCI Full Stack DR)는 클릭 한 번으로 전 세계 OCI 리전 간 컴퓨트, 데이터베이스, 애플리케이션 전환을 통합관리합니다. 고객은 기존 인프라, 데이터베이스 또는 애플리케이션을 재설계하거나 재설계하지 않고 전문화된 관리 또는 변환 서버 없이도 하나 이상의 비즈니스 시스템을 복구하는 데 필요한 단계를 자동화할 수 있습니다.

Oracle HeatWave MySQL은 Oracle Cloud Infrastructure(OCI) 내에 배포된 완전 관리형 데이터베이스 서비스로, 안전한 클라우드 전용 애플리케이션을 신속하게 배포하려는 운영자와 개발자를 지원합니다. Oracle HeatWave MySQL은 통합된 고성능 인메모리 쿼리 가속기인 HeatWave를 사용할 수 있는 기능을 포함하는 유일한 MySQL 오퍼링입니다. HeatWave 고객은 운영 중인 MySQL 데이터베이스에 대해 정교한 분석을 직접 실행할 수 있으므로 복잡하고 시간이 많이 걸리고 비용이 많이 드는 데이터 마이그레이션 및 별도의 분석 데이터베이스와의 통합이 필요하지 않습니다. HeatWave 애널리틱스 및 혼합 워크로드를 위해 MySQL 성능을 크게 가속화합니다. HeatWave는 OCI에 완벽하게 최적화되어 있으며 Oracle HeatWave MySQL은 OCI 및 MySQL 엔지니어링 팀에서 100% 구축, 관리 및 지원합니다.

이 사용지침서에서는 OCI에서 Oracle HeatWave MySQL에 대한 콜드 재해 복구를 자동화하는 방법을 알아봅니다. OCI Full Stack DR 서비스를 활용하여 스위치오버 및 페일오버 프로세스를 관리하는 절차를 간략히 설명합니다.

주: 이러한 유형의 DR(재해 복구) 전략은 백업 및 복원 방식에 의존하므로 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)에 대한 비즈니스 요구 사항이 지나치게 까다롭지 않은 중요하지 않은 응용 프로그램에 가장 적합합니다.

구조 설명

이 사용지침서에 제시된 아키텍처는 Oracle HeatWave MySQL과 원활하게 통합된 OCI VM(가상 머신)에서 실행되는 WordPress 애플리케이션을 보여줍니다. 또한 OCI 파일 스토리지 서비스를 NFS(네트워크 파일 시스템) 공유로 활용하여 WordPress 콘텐츠를 저장합니다. 이 공유 스토리지는 각 VM에 마운트되므로 환경의 모든 새 컨텐츠에 즉시 동기식으로 액세스할 수 있습니다.

OCI 로드 밸런서는 공용 서브넷 내에 배포되어 외부 사용자 연결을 효율적으로 관리하며 WordPress VM에 수신 트래픽을 분산합니다.

재해 복구 아키텍처 설명

WordPress 애플리케이션 VM에 대한 DR 전략에는 볼륨 그룹 복제와 함께 VM의 각 부트 볼륨에 대한 전체 복제 및 WordPress 컨텐츠의 동기화를 보장하기 위한 파일 스토리지 복제 활용 등 포괄적인 접근 방식이 포함됩니다.

로드 밸런서는 원격 리전에서 사전 프로비저닝되므로 스위치오버 또는 페일오버 시나리오 동안 WordPress VM이 원격 리전으로 전환될 때 원활하게 트래픽을 처리할 수 있습니다.

Oracle HeatWave MySQL의 경우 데이터 보호 및 재해 복구 준비 상태를 보장하기 위해 백업이 정기적으로 원격 영역에 복사됩니다. 이 프로세스는 자동화된 일관된 실행을 위해 crontab을 통해 예약할 수 있는 사용자정의 스크립트를 사용하여 하나의 애플리케이션 VM에서 시작할 수 있습니다.

다음 다이어그램은 사용 가능한 최신 MySQL 백업을 기본 영역에서 원격 영역으로 복사하는 워크플로우를 보여줍니다.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

WordPress 애플리케이션 VM1의 opc 사용자 아래에 4시간마다 mds_copy_bkp.py 스크립트를 실행하도록 다음 crontab 설정이 구성되었습니다. 이렇게 하면 대기 영역에 대한 자동 백업 동기화가 수행되므로 재해 복구 기능이 향상됩니다.

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

이 작업은 4시간마다 분 15에 스크립트를 실행합니다.

모든 스크립트는 GitHub에서 사용할 수 있으며 다음 절에서 자세히 설명합니다.

주: MySQL 백업을 원격 영역에 정기적으로 복사하려면 업무 요구 사항에 따라 이 스크립트(또는 이와 유사한 스크립트)의 일정을 잡아야 합니다. 이 단계를 수행하지 않으면 보조 영역에서 백업을 사용할 수 없어 복원 프로세스가 실패할 수 있습니다.

복구 작동 방법

계획된 Switchover가 실행되면 롤이 취소됩니다. 기본 작업 로드는 영역 2에서 실행되고 standby는 영역 1에서 실행됩니다. 아키텍처는 다음과 같이 표시됩니다.

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

현재 설정에서는 OCI 전용 DNS 서비스를 활용하여 트래픽을 활성 Oracle HeatWave MySQL 엔드포인트로 전달하는 DNS 레코드를 관리합니다. 복구 프로세스 중에 이 DNS 레코드는 새로운 Oracle HeatWave MySQL을 반영하기 위해 사용자정의 스크립트를 통해 업데이트되어 원활한 페일오버 및 서비스 연속성을 보장합니다.

다음 다이어그램은 대기 영역에서 최신 MySQL 백업을 복원하는 워크플로우를 보여줍니다.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

이 배치를 위한 복구 솔루션을 사용하려면 복구 작업(예: 페일오버 또는 스위치오버) 중 일련의 사용자정의 Python 스크립트를 실행하기 위한 OCI Full Stack DR이 필요합니다. 이 자습서에서 참조된 스크립트는 EMEA 클라우드 아키텍처 전문가 팀에서 제공하며 이 DR 솔루션에 맞게 특별히 조정된 전체 스택 재해 복구에서 사용할 수 있습니다.

이 자습서에서는 스크립트를 다운로드하는 방법과 이후 작업에서 스크립트를 사용하는 방법에 대해 설명합니다.

주: 일반 지침을 위해 다음 스크립트가 제공됩니다. 자체 스크립트를 사용하거나 회사 정책 및 보안 요구 사항에 따라 스크립트를 사용자 정의할 수 있습니다.

자습서 전체에서 정의 및 가정

영역:
- 지역 1은 두바이: 두바이는 초기에 주요 지역으로 사용됩니다. 그러나 이 롤은 스위치오버 프로세스 중 대기로 전환되며, 재해 복구 계획의 일부로 이후 작업에서 수행됩니다.
- 지역 2는 아부다비: 아부다비는 처음에 대기 지역으로 작동합니다. 이 롤은 나중에 스위치오버 프로세스에 따라 기본 롤로 전환되며, 재해 복구 절차의 일부로 후속 작업에서 수행됩니다.
구획: 이 배포 및 OCI Full Stack DR을 IT 거버넌스에 대한 표준 내에서 작동하는 모든 구획 체계로 자유롭게 구성할 수 있습니다. 이 자습서에 대한 모든 OCI 리소스를 단일 컴파트먼트로 구성하도록 선택했습니다.

WordPress 애플리케이션 VM 및 OCI File Storage

이 자습서에서 활용되는 아키텍처는 모든 애플리케이션 VM이 동일한 WordPress 콘텐츠에 대한 공유 액세스를 가질 수 있도록 OCI File Storage를 기반으로 설계되었습니다.

Linux 인스턴스에서 파일 시스템을 올바르게 마운트하는 방법에 대한 자세한 내용은 Configuring a File System to Automatically Mount (Linux Instances)을 참조하십시오.

다음은 WordPress 응용 프로그램 VM에 파일 시스템을 마운트하기 위한 /etc/fstab 파일 구성의 예입니다.

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

적절한 연결을 위해 xxx.xxx.xxx.xxx을 영역 1에 있는 마운트 대상의 IP 주소로 바꿉니다.

목표

이 자습서에서는 다음 작업에 대해 설명합니다.

작업 1: Disaster Recovery를 위한 환경 준비
작업 2: 두 영역에서 DRPG(DR 보호 그룹) 만들기
작업 3: DR 보호 그룹에 구성원 추가
작업 4: 영역 2에서 기본 DR 계획 생성
작업 5: 영역 2의 Switchover Plan 커스터마이즈
작업 6: 영역 2의 Failover 계획 커스터마이즈
작업 7: 영역 2에서 DR 계획의 사전 검사 실행
작업 8: 영역 2에서 switchover 계획 실행
작업 9: 영역 1에서 DR 계획 생성 및 사용자 정의

작업 1: 재해 복구를 위한 환경 준비

작업 1.1: 볼륨 그룹 만들기 및 복제 사용

영역 1에서 WordPress 애플리케이션 VM에 대한 볼륨 그룹을 생성하고 영역 2에서 복제되었는지 확인합니다. 각 애플리케이션 VM(WordPress)의 부트 볼륨이 볼륨 그룹의 멤버이고 볼륨 그룹이 영역 2로 복제되는지 확인합니다.

다음 이미지는 복제가 영역 2로 성공적으로 사용으로 설정된 두 WordPress 애플리케이션 VM의 부트 볼륨을 포함하는 생성된 볼륨 그룹을 표시하는 방법을 보여줍니다. 자세한 내용은 Creating a Volume Group를 참조하십시오.

작업 1.2: WordPress 콘텐츠에 대해 파일 스토리지 복제 사용

영역 2에서 복제용으로 특별히 지정된 파일 시스템을 만듭니다. 이 파일 시스템은 지역 1에서 지역 2로 데이터를 원활하게 복제하는 데 사용됩니다.
영역 2에서 영역 1에서 영역 2로 복구 프로세스 중 사용할 마운트 대상을 생성합니다.
1단계에서 생성한 파일 시스템을 사용하여 지역 1의 소스 OCI File Storage에서 복제를 활성화하고 구성합니다.

다음 이미지는 영역 2에 대한 파일 스토리지 복제 세부정보를 보여줍니다.

자세한 내용은 File System Replication을 참조하십시오.

작업 1.3: 사용자 정의 자동화를 실행하도록 응용 프로그램 VM 준비

Oracle Cloud Infrastructure 명령행 인터페이스(OCI CLI)를 설치 및 구성합니다. 이 사용지침서에서는 Oracle Linux 8이 WordPress 애플리케이션 VM에 사용됩니다. 자세한 내용은 Installing the CLI를 참조하십시오.
/home/opc 폴더의 GitHub 저장소(mds_colddr_scripts)에서 스크립트를 배치합니다.
제공된 스크립트에서 사용되는 판다 및 표기 모듈을 설치합니다.
```
pip install pandas
pip install tabulate
```
영역 1에서 Oracle HeatWave MySQL에 필요한 세부정보로 config.csv 파일을 업데이트합니다.
- MYSQL_DB_SYSTEM_OCID을 Oracle HeatWave MySQL의 OCID로 바꿉니다. 특정 요구 사항에 맞게 MySQL 레이블을 유지하거나 사용자 정의할 수 있습니다.
- COMPARTMENT_OCID을 MySQL 시스템이 있는 컴파트먼트의 OCID로 바꿉니다.
- PRIMARY_SUBNET_OCID 및 STANDBY_SUBNET_OCID을 두 영역의 서브넷 OCID로 바꿉니다.
- PRIMARY_DNS_VIEW_OCID 및 STANDBY_DNS_VIEW_OCID을 Oracle HeatWave MySQL 끝점 레코드를 관리하는 프라이빗 DNS 영역과 연관된 프라이빗 DNS 뷰의 OCID로 바꿉니다.
주: 모든 값이 정확하게 갱신되었는지 확인하십시오.

자습서의 일부로 사용자 정의 스크립트를 실행하는 데 동일한 VM을 사용합니다. DR 제어 노드로 작동하는 VM이 명령을 실행하도록 구성되었는지 확인합니다. 자세한 내용은 Oracle Cloud Infrastructure Full Stack Disaster Recovery와 함께 실행 명령을 사용하여 사용자 정의 스크립트 호출을 참조하십시오.

작업 1.4: OCI Full Stack DR에 대한 OCI IAM 정책 생성

다음 문서에 설명된 대로 OCI Full Stack DR에 필요한 OCI IAM 정책을 구성합니다.

작업 1.5: OCI Full Stack DR에서 관리되는 다른 서비스에 대한 OCI IAM 정책 생성

OCI Full Stack DR은 컴퓨팅, 네트워킹, 스토리지 및 기타 서비스와 같은 기타 주요 OCI 서비스를 제어 및 관리할 수 있어야 합니다. 기타 서비스에 필요한 OCI IAM 정책을 구성하려면 Policies for Other Services Managed by Full Stack Disaster Recovery 및 OCI IAM policies를 참조하십시오.

작업 2: 두 영역에서 DRPG(DR 보호 그룹) 만들기

이 응용 프로그램 스택에 대한 보호 그룹이 아직 없으면 영역 1 및 영역 2에서 DR 보호 그룹을 만듭니다.

작업 2.1: 영역 1에 보호 그룹 생성

그림 2.1과 같이 OCI 콘솔로 이동하여 DR Protection Groups로 이동합니다.
1. OCI 지역 컨텍스트가 Region 1(Dubai)로 설정되어 있는지 확인합니다.
2. 이전 및 재해 복구를 누릅니다.
3. DR Protection Groups를 누릅니다.
그림 2.1: DR 보호 그룹으로 이동합니다.
그림 2.2와 같이 지역 1에 기본 DRPG(DR 보호 그룹)를 만듭니다. 피어, 롤 및 멤버는 이후 단계에서 지정됩니다.
1. DRPG를 생성할 구획을 선택합니다.
2. DR 보호 그룹 생성을 눌러 대화상자를 엽니다.
3. DRPG에 의미 있는 이름을 사용합니다.
4. OCI Full Stack DR 로그에 대한 OCI Object Storage 버킷을 선택합니다.
5. Create를 누릅니다.
그림 2.2: 영역 1에서 DR 보호 그룹을 생성하는 데 필요한 매개변수

작업 2.2: 영역 2에 보호 그룹 생성

그림 2.3과 같이 OCI 콘솔로 이동하여 DR Protection Groups로 이동합니다.
1. OCI 지역 컨텍스트가 Region 2(Abu Dhabi)로 설정되었는지 확인합니다.
2. 이전 및 재해 복구를 누릅니다.
3. DR Protection Groups를 누릅니다.
그림 2.3: DR 보호 그룹으로 이동합니다.
그림 2.4와 같이 영역 2에 기본 DRPG(DR 보호 그룹)를 만듭니다. 피어, 롤 및 멤버는 이후 단계에서 지정됩니다.
1. DRPG를 생성할 구획을 선택합니다.
2. DR 보호 그룹 생성을 눌러 대화상자를 엽니다.
3. DRPG에 의미 있는 이름을 사용합니다.
4. OCI Full Stack DR 로그에 대한 OCI Object Storage 버킷을 선택합니다.
5. Create를 누릅니다.
그림 2.4: 영역 2에서 DR 보호 그룹을 생성하는 데 필요한 매개변수

작업 2.3: 영역 1 및 영역 2의 보호 그룹 연관

각 영역의 DRPG를 서로의 피어로 연관시키고 primary 및 standby의 피어 롤을 지정합니다. 기본 및 대기 롤은 DR 작업/DR 계획 실행의 일부로 OCI Full Stack DR에 의해 자동으로 변경되므로 언제든지 수동으로 롤을 관리할 필요가 없습니다.

DR 보호 그룹 세부 정보 페이지로 이동합니다.
1. OCI 지역 컨텍스트가 Region 1(Dubai)로 설정되었는지 확인합니다.
2. 연결을 눌러 프로세스를 시작합니다.
그림: DRPG 연관 시작
다음 그림과 같이 매개변수를 입력합니다.
1. 역할: 기본 역할을 선택합니다. OCI Full Stack DR은 대기 롤을 리전 2에 자동으로 지정합니다.
2. 피어 영역: 다른 DRPG가 생성된 영역 2(아부다비)를 선택합니다.
3. 피어 DR 보호 그룹: 생성된 피어 DRPG를 선택합니다.
4. 연계를 누릅니다.
그림: DRPG를 연결하는 데 필요한 매개변수

OCI Full Stack DR은 연관이 완료된 후 다음 이미지와 같이 표시됩니다.

현재 주요 피어 DRPG는 두바이 (지역 1)입니다.
현재 대기 피어 DRPG는 아부다비(지역 2)입니다.

그림: 개별 DRPG 관점에서 피어 관계 표시

컨텍스트/뷰가 다음 이미지와 같이 모든 DR 보호 그룹을 보여주는 전역적 관점에서 볼 때마다 동일한 정보를 찾을 수 있습니다.

현재 주요 피어 DRPG는 두바이 (지역 1)입니다.
현재 대기 피어 DRPG는 아부다비(지역 2)입니다.

그림: 전역 DRPG 관점에서 피어 관계 표시

작업 3: DR 보호 그룹에 구성원 추가

이 작업에서는 다음 OCI 리소스를 지역 1의 기본 DRPG에 추가합니다.

WordPress 애플리케이션을 호스팅하는 두 컴퓨트 인스턴스가 이동 VM으로 추가됩니다. 또한 고급 옵션의 파일 시스템 섹션이 제대로 구성되었는지 확인합니다.
WordPress 애플리케이션 컴퓨트 노드의 부트 볼륨을 포함하는 볼륨 그룹입니다.
WordPress 콘텐츠를 포함하는 OCI File Storage입니다.
기본 로드 밸런서입니다.

작업 3.1: 영역 1의 DRPG에 멤버 추가

다음 이미지와 같이 영역 1에서 DRPG를 선택합니다.
1. OCI 지역 컨텍스트가 Region 1(Dubai)인지 확인합니다.
2. 영역 1에서 DRPG를 선택합니다.
3. 멤버를 선택합니다.
4. 구성원 추가를 눌러 프로세스를 시작합니다.
그림: 영역 1의 DR 보호 그룹에 멤버를 추가하는 방법
WordPress 애플리케이션 VM에 대한 컴퓨트 인스턴스를 추가합니다.
1. DR 계획에 대한 경고를 수락합니다.
2. 컴퓨트를 멤버 리소스 유형으로 입력합니다.
3. WordPress 애플리케이션을 호스팅하는 컴퓨트 인스턴스를 선택합니다.
4. 이동 인스턴스를 선택합니다.
5. 복구 중 영역 2의 VNIC에 지정할 VCN 및 서브넷을 선택하려면 VNIC 매핑 추가를 누릅니다.
6. 고급 옵션 표시를 누릅니다.
7. 설정에서 결함 도메인 유지를 선택합니다.
8. 파일 시스템에서 다음 이미지에 표시된 대로 설정에 따라 익스포트 매핑 섹션을 완료합니다.
그림: WordPress 애플리케이션 VM을 추가하는 데 필요한 매개변수

그림: 영역 2에서 VNIC를 매핑하는 데 필요한 매개변수

그림: 고급 옵션, 결함 도메인 유지

그림: 고급 옵션, 파일 시스템 매핑

그림: 영역 1의 DRPG에 컴퓨트 인스턴스가 추가됨

주: WordPress 애플리케이션 VM의 모든 컴퓨트 인스턴스에 대해 이전 하위 단계를 반복합니다.

그림: 영역 1의 DRPG에 두 개의 컴퓨트 인스턴스가 추가됨
WordPress 애플리케이션 VM의 부트 볼륨을 포함하는 블록 볼륨 그룹을 추가합니다.
1. DR 계획에 대한 경고를 수락합니다.
2. 볼륨 그룹을 멤버 리소스 유형으로 선택합니다.
3. 볼륨 그룹을 포함하는 올바른 컴파트먼트가 선택되었는지 확인하고 볼륨 그룹을 선택하십시오.
그림: WordPress 컴퓨트에 대한 볼륨 그룹을 추가하는 데 필요한 매개변수

그림: WordPress 컴퓨트의 볼륨 그룹이 영역 1의 DRPG에 추가됨
WordPress 콘텐츠를 포함하는 OCI File Storage를 추가합니다.
1. DR 계획에 대한 경고를 수락합니다.
2. 파일 시스템을 리소스 유형 멤버로 선택합니다.
3. 파일 시스템을 포함하는 올바른 컴파트먼트가 선택되었는지 확인하고 파일 시스템을 선택하십시오.
4. 영역 2에서 사용할 대상 가용성 도메인을 선택합니다.
5. 이 파일 시스템에 대한 소스 익스포트 경로를 선택합니다. 이 내보내기 경로는 파일 시스템을 복원한 후 대상 지역 2에 생성됩니다.
6. 복원된 파일 시스템의 내보내기를 만드는 데 사용된 영역 2에서 대상 마운트 대상을 선택합니다.
그림: WordPress 콘텐츠에 대한 파일 시스템을 추가하는 데 필요한 매개변수

그림: WordPress 컨텐츠에 대한 파일 시스템 영역 1의 DRPG에 추가됨
OCI 로드 밸런서를 추가합니다.

이 예에서는 로드 밸런서를 지역 1의 DRPG 멤버로 추가합니다.
1. DR 계획에 대한 경고를 수락합니다.
2. 로드 밸런서를 리소스 유형 멤버로 선택합니다.
3. 로드 밸런서에 대한 올바른 구획이 선택되었는지 확인하고 추가할 로드 밸런서를 선택합니다.
4. 영역 2에서 사용할 대상 로드 밸런서를 선택합니다.
5. 소스 백엔드 집합을 선택합니다. WordPress 애플리케이션 VM에서 사용되는 백엔드 집합입니다. OCI 로드 밸런서는 여러 애플리케이션 간에 공유할 수 있으며 여러 개의 백엔드 집합이 구성되어 있을 수 있습니다. DR 전환 중에는 여기에 지정된 백엔드 집합만 해당 구성이 대기 영역으로 이동됩니다.
6. 대상 백엔드 집합을 선택합니다. 이는 영역 2에서 생성된 빈 백엔드 집합입니다.
그림: 로드 밸런서 추가에 필요한 매개변수

그림: 로드 밸런서가 영역 1의 DRPG에 추가됨

작업 3.2: 영역 2의 DRPG에 멤버 추가

다음 이미지와 같이 영역 2에서 DRPG를 선택합니다.
1. OCI 지역 컨텍스트가 Region 1(Abu Dhabi)인지 확인합니다.
2. 영역 2에서 DRPG를 선택합니다.
3. 멤버를 선택합니다.
4. 구성원 추가를 눌러 프로세스를 시작합니다.
그림: 영역 2의 DR 보호 그룹에 멤버를 추가하는 방법
OCI 로드 밸런서를 추가합니다.

이 예에서는 로드 밸런서를 지역 2의 DRPG 멤버로 추가합니다.
1. DR 계획에 대한 경고를 수락합니다.
2. 로드 밸런서를 리소스 유형 멤버로 선택합니다.
3. 로드 밸런서에 대해 올바른 컴파트먼트가 선택되었는지 확인하고 추가할 로드 밸런서를 선택하십시오.
4. 영역 1에서 사용할 대상 로드 밸런서를 선택합니다.
5. 소스 백엔드 집합을 선택합니다. WordPress 애플리케이션 VM에서 사용되는 백엔드 집합입니다. OCI 로드 밸런서는 여러 애플리케이션 간에 공유할 수 있으며 여러 개의 백엔드 집합이 구성되어 있을 수 있습니다. DR 전환 중에는 여기에 지정된 백엔드 집합만 해당 구성이 대기 영역으로 이동됩니다.
6. 대상 백엔드 집합을 선택합니다. 이 백엔드 집합은 영역 2에서 생성됩니다.
그림: 로드 밸런서 추가에 필요한 매개변수

그림: 로드 밸런서가 영역 2의 DRPG에 추가됨

작업 4: 영역 2에서 기본 DR 계획 생성

이 작업에서는 지역 2(아부다비)의 대기 DR 보호 그룹과 연관된 초기 전환 및 페일오버 계획을 만듭니다.

이러한 계획의 목적은 작업 로드를 기본 영역(지역 1)에서 대기 영역(지역 2)으로 원활하게 전환하는 것입니다. DR 작업의 일부로 두 영역 모두에서 DR 보호 그룹의 역할이 자동으로 전환됩니다. 즉, 영역 1의 보호 그룹이 대기 그룹이 되고 영역 2의 보호 그룹이 페일오버 또는 스위치오버 후 기본 역할을 맡습니다.

OCI Full Stack DR은 이전 작업 중 추가된 멤버 리소스에서 파생된 내장 단계로 해당 계획을 미리 채웁니다. 이 계획은 나중에 복구 프로세스 중 Oracle HeatWave MySQL과 관련된 작업을 관리하도록 사용자정의됩니다.

전환 계획은 항상 대기 롤을 보유하는 보호 그룹 내에 생성됩니다. 지역 2 (Abu Dhabi)는 현재 대기 보호 그룹이기 때문에 우리는 그곳에서 계획을 세우기 시작할 것입니다.

작업 4.1: DR 계획 생성

지역 2(아부다비)에서 DRPG를 선택하여 기본 계획 생성
1. OCI 지역 컨텍스트가 Region 2(Abu Dhabi)인지 확인합니다.
2. 영역 2에서 대기 DRPG를 선택합니다.
3. 플랜을 선택합니다.
4. 계획 생성을 눌러 프로세스를 시작합니다.
그림: 영역 2에서 기본 DR 계획 생성을 시작하는 방법
switchover 계획을 생성합니다.
1. 전환 계획에 대해 간단하지만 의미 있는 이름을 입력합니다. 이름은 가능한 한 짧아야하지만 위기 동안 혼란과 인간의 실수를 줄이는 데 도움이되는 한 눈에 이해하기 쉽습니다.
2. 계획 유형을 전환(계획)으로 선택합니다.
그림: DR 전환 계획을 생성하는 데 필요한 매개변수
페일오버 계획을 만듭니다.

다음 이미지와 같이 동일한 프로세스에 따라 기본 페일오버 계획을 만듭니다.
1. 복구 계획의 이름을 간단하지만 의미 있는 이름으로 입력합니다. 이름은 가능한 한 짧아야하지만 위기 동안 혼란과 인간의 실수를 줄이는 데 도움이되는 한 눈에 이해하기 쉽습니다.
2. 계획 유형을 페일오버(계획되지 않음)로 선택합니다.
그림: DR 페일오버 계획을 만드는 데 필요한 매개변수

이제 영역 2의 대기 DR 보호 그룹에는 다음 이미지와 같이 두 개의 DR 계획이 있어야 합니다. 리전 1에서 리전 2로 워크로드 전환을 처리합니다. 나중에 수행할 작업에서 영역 1에서 작업 로드를 영역 2에서 영역 1로 다시 전환하기 위한 유사한 계획을 생성합니다.

플랜-생성-auh-completed.png
그림: 더 이상 진행하기 전에 영역 2에 존재해야 하는 두 가지 기본 DR 계획 표시

작업 5: 영역 2의 Switchover Plan 커스터마이즈

작업 4에서 생성된 기본 DR 계획에는 OCI Full Stack DR에 내장되어 있으며 Oracle HeatWave MySQL과 관련된 복구 작업을 관리할 수 있는 단계가 포함되어 있지 않은 복구 작업에 대해 미리 채워진 단계가 포함됩니다. 이 작업에서는 사용자 정의 DR 계획 그룹 및 전환 중 수행해야 하는 작업을 관리하는 단계를 추가하는 방법에 대해 설명합니다.

데이터 일관성을 보장하기 위해 애플리케이션 VM을 정상적으로 종료한 후 데이터베이스 백업을 생성합니다.
리던던시 및 재해 복구를 위해 최신 데이터베이스 백업을 원격 OCI 리전 2로 전송합니다.
리전 2에서 가장 최근의 데이터베이스 백업을 복원하여 전환할 환경을 준비합니다.
전용 데이터베이스 DNS 레코드를 업데이트하여 애플리케이션 VM이 지역 2의 데이터베이스에 원활하게 연결할 수 있도록 합니다.
Region 1에서 소스 MySQL 데이터베이스를 종료합니다.

작업 5.1: 전환 계획 선택

작업 4에서 생성된 전환 계획으로 이동합니다.

그림: 영역 2에서 switchover 계획을 커스터마이즈하는 방법

작업 5.2: (선택사항) 아티팩트를 종료하는 DR 계획 그룹 사용

다음 그림과 같이 전환 계획에는 기본적으로 사용 안함으로 설정되는 세 개의 계획 그룹이 있습니다. 테스트 중 아티팩트가 삭제되지 않고 테스트 단계 중 문제가 발생할 경우 실행 가능한 백업 복사본이 그대로 유지되도록 보장하기 위해 이러한 계획 그룹이 사용 안함으로 설정됩니다.

그러나 이러한 세 계획 그룹은 이후 DR 작업에 더 이상 필요하지 않은 아티팩트를 종료(삭제)하도록 설계되었습니다. 이러한 계획 그룹을 사용으로 설정하지 않으면 두 영역 간에 스위치오버를 수행할 때 시간이 지남에 따라 사용되지 않은 아티팩트가 계속 누적됩니다. 이로 인해 어떤 컴퓨트 인스턴스, OCI File Storage 및 볼륨 그룹이 활성 상태여야 하는지 혼동될 수 있습니다.

선택적으로, 이제 이러한 계획 그룹을 사용으로 설정하면 운용 단계로 이동하기 전에 불필요한 아티팩트를 수동으로 정리할 필요가 없습니다. 이 사전 예방적 단계는 운영으로의 전환을 간소화하고 보다 깨끗하고 관리하기 쉬운 환경을 유지할 수 있습니다.

그림: 기본적으로 사용 안함으로 설정된 계획 그룹

계획 그룹을 사용으로 설정하려면 계획 그룹 이름 오른쪽에 있는 컨텍스트 메뉴에서 모든 단계 사용을 선택합니다.

그림: 파일 시스템 종료를 사용으로 설정하는 방법

그림: Enable을 눌러 검증합니다.

그림: 컴퓨트 인스턴스 종료를 사용으로 설정하는 방법

그림: Enable을 눌러 검증합니다.

그림: 종료 볼륨 그룹을 사용으로 설정하는 방법

그림: Enable을 눌러 검증합니다.

작업 5.3: DR 계획 그룹 재정렬

로드 밸런서 백엔드 집합을 업데이트하기 전에 영역 2로 이동된 새 VM에 파일 시스템을 마운트해야 합니다. 이렇게 하면 응용 프로그램이 필요한 저장소 리소스에 제대로 액세스할 수 있으므로 전환 프로세스 중 원활하게 전환할 수 있습니다.

플랜-custom-so-auh-reorder-initial.png
그림: 초기 전환 계획 순서 및 순서 재지정 시작 방법을 보여주는 스크린샷

플랜-custom-so-auh-reorder-start.png
그림: 순서 재지정 시작

로드 밸런서 - 대상 백엔드 집합 업데이트 전에 파일 시스템 - 컴퓨트 인스턴스에 마운트를 이동합니다.
변경사항 저장을 누릅니다.

플랜-custom-so-auh-reorder-final.png
그림: 최종 전환 계획 순서

작업 5.4: 사용자 정의 스크립트를 실행할 계획 그룹 생성

먼저 사용자 정의 DR 계획 그룹을 추가하여 MySQL Backup/Restore DR 프로세스의 특정 요구에 맞게 DR 워크플로우를 조정합니다.

이러한 계획 그룹은 영역 1의 WordPress VM1에서 필요한 스크립트를 호출하며 WordPress 애플리케이션 VM을 시작하기 전에 DR 워크플로우에 배치되어야 합니다. 이렇게 하면 애플리케이션 VM이 온라인으로 전환되기 전에 MySQL 데이터베이스가 완전히 복원되고 작동합니다.

미리 채워진 스위치오버 계획에 MySQL Database 백업 생성, MySQL Database 백업 복사, MySQL Database 백업 복원, MySQL Database DNS 업데이트 및 MySQL Database 소스 종료 사용자정의 계획을 추가해야 합니다.

사용자정의 계획 그룹을 추가하여 MySQL 데이터베이스 백업을 생성합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Create MySQL DB Backup를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 컴퓨트 인스턴스 - 실행 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 백업을 생성할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 MySQL DB 백업 생성

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Create MySQL DB Backup를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 생성 추가를 생성하는 매개변수 MySQL DB 백업

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL DB 백업 생성
MySQL 데이터베이스 백업을 복사할 사용자정의 계획 그룹을 추가합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Copy MySQL DB Backup를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 MySQL DB 백업 생성 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 백업을 복사할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 MySQL DB 백업 복사

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Copy MySQL DB Backup를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 복사본 MySQL DB 백업을 추가하는 매개변수

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL DB 백업 복사
사용자정의 계획 그룹을 추가하여 MySQL 데이터베이스 백업을 복원합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Restore MySQL DB Backup를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 MySQL DB 백업 복사 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 백업을 복원할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 MySQL DB 백업 복원

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Restore MySQL DB Backup를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 복원을 추가하는 매개변수 MySQL DB 백업

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL DB 백업 복원
사용자정의 계획 그룹을 추가하여 MySQL 데이터베이스 DNS를 업데이트합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Update MySQL DB DNS를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 MySQL DB 백업 복원 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 DNS를 업데이트할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 업데이트 MySQL DB DNS

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Update MySQL DB DNS를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 업데이트를 추가하는 매개변수 MySQL DB DNS

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL DB DNS 업데이트
사용자정의 계획 그룹을 추가하여 MySQL 소스 데이터베이스를 종료합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Terminate MySQL DB Source를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 파일 시스템 - DR 보호 그룹에서 제거 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 소스를 종료할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 MySQL 소스 DB 종료

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Terminate MySQL Source DB를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 종료를 추가하는 매개변수 MySQL 소스 DB

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL 소스 DB 종료
(선택 사항) 사용자정의 계획 그룹을 추가하여 WordPress 애플리케이션을 정지합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Application - Stop를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 로드 밸런서 - 소스 백엔드 집합 업데이트 뒤에 사용자 정의 계획 그룹을 끝에 삽입합니다.
4. 단계 추가를 눌러 응용 프로그램을 정지할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 애플리케이션을 생성하는 매개변수 - 중지

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Application - Stop - VM1를 사용합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/fsdrscripts/wdp_stop.sh.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 애플리케이션을 생성하는 매개변수 - 정지 - VM1

단계 추가를 눌러 VM2에서 애플리케이션을 정지할 두번째 단계를 추가합니다.

그림: 단계 응용 프로그램 추가 - 중지 - VM2

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Application - Stop - VM2를 사용합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM2에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM2인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/fsdrscripts/wdp_stop.sh.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 애플리케이션을 생성하는 매개변수 - 정지 - VM2

추가를 누릅니다.

그림: 계획 그룹 애플리케이션 추가 - 중지
(선택 사항) 사용자정의 계획 그룹을 추가하여 WordPress 애플리케이션을 시작합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Application - Start를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 다음 이후 추가를 선택하여 기본 제공 계획 그룹 파일 시스템 - 컴퓨트 인스턴스에 마운트 뒤에 사용자 정의 계획 그룹을 끝에 삽입합니다.
4. 단계 추가를 눌러 응용 프로그램을 시작할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 애플리케이션 생성 매개변수 - 시작

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Application - Start - VM1를 사용합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 경우 스크립트는 지역 1의 WordPress 애플리케이션 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/fsdrscripts/wdp_start.sh.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 응용 프로그램을 생성하는 매개변수 - 시작 - VM1

단계 추가를 눌러 VM2에서 애플리케이션을 시작하는 두번째 단계를 추가합니다.

그림: 단계 응용 프로그램 추가 - 시작 - VM2

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Application - Start - VM2를 사용합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 경우 스크립트는 지역 1의 WordPress 애플리케이션 VM2에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM2인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/fsdrscripts/wdp_start.sh.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 응용 프로그램을 생성하는 매개변수 - 시작 - VM2

추가를 누릅니다.

그림: 계획 그룹 추가 애플리케이션 - 시작

전환 계획의 사용자정의가 성공적으로 완료되었습니다.

플랜-custom-so-auh-complete.png

작업 6: 영역 2의 Failover 계획 커스터마이즈

이 작업에서는 사용자 정의 DR 계획 그룹 및 페일오버 중 수행해야 하는 작업을 관리하는 단계를 추가합니다.

리전 2에서 가장 최근의 데이터베이스 백업을 복원하여 전환할 환경을 준비합니다.
전용 데이터베이스 DNS 레코드를 업데이트하여 애플리케이션 VM이 지역 2의 데이터베이스에 원활하게 연결할 수 있도록 합니다.

작업 6.1: 복구 계획 선택

작업 4에서 만든 페일오버 계획으로 이동합니다.

그림: 영역 2의 페일오버 계획 사용자 정의를 시작하는 방법

작업 6.2: 영역 2에서 사용자 정의 스크립트를 실행할 계획 그룹 생성

먼저 사용자 정의 DR 계획 그룹을 추가하여 MySQL Backup/Restore DR 프로세스의 특정 요구에 맞게 DR 워크플로우를 조정합니다.

이러한 계획 그룹은 WordPress 애플리케이션 VM에서 필요한 스크립트를 호출하며 WordPress 애플리케이션 VM을 재시작하기 전에 DR 워크플로우에 배치되어야 합니다. 이렇게 하면 애플리케이션 VM이 온라인으로 전환되기 전에 MySQL 데이터베이스가 완전히 복원되고 작동합니다.

미리 채워진 페일오버 계획에 Restore MySQL Database Backup 및 Update MySQL Database DNS 사용자 정의 계획을 추가해야 합니다.

사용자정의 계획 그룹을 추가하여 MySQL 데이터베이스 백업을 복원합니다.
1. 시작하려면 그룹 추가를 누르십시오.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Restore MySQL DB Backup를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 컴퓨트 인스턴스 - 실행 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 백업을 복원할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 MySQL DB 백업 복원

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Restore MySQL DB Backup를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 복원을 추가하는 매개변수 MySQL DB 백업

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL DB 백업 복원
사용자정의 계획 그룹을 추가하여 MySQL 데이터베이스 DNS를 업데이트합니다.
1. 시작하려면 그룹 추가를 누르십시오.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Update MySQL DB DNS를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 MySQL DB 백업 복원 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 MySQL 데이터베이스 DNS를 업데이트할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 생성을 위한 매개변수 업데이트 MySQL DB DNS

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Update MySQL DB DNS를 사용합니다. 계획 그룹 이름과 동일합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예에서는 스크립트가 지역 1의 WordPress 애플리케이션 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 업데이트 추가를 생성하는 매개변수 MySQL DB DNS

추가를 누릅니다.

그림: 계획 그룹 추가 MySQL DB DNS 업데이트
(선택 사항) 사용자정의 계획 그룹을 추가하여 WordPress 애플리케이션을 재시작합니다.
1. 그룹 추가를 누릅니다.
2. 단순하지만 설명적인 계획 그룹 이름을 입력합니다. 이 예에서는 Application - Restart를 사용합니다.
3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 예에서는 다음 뒤에 추가를 선택하여 기본 제공 계획 그룹 파일 시스템 - 컴퓨트 인스턴스에 마운트 뒤에 사용자 정의 계획 그룹을 삽입합니다.
4. 단계 추가를 눌러 응용 프로그램을 시작할 스크립트를 지정할 수 있는 대화상자를 엽니다.
그림: 계획 그룹 애플리케이션을 생성하는 매개변수 - 재시작

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Application - Restart - VM1를 사용합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM1에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM1인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/fsdrscripts/wdp_restart.sh.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 응용 프로그램을 생성하는 매개변수 - 재시작 - VM1

단계 추가를 눌러 VM2에서 애플리케이션을 재시작하는 두번째 단계를 추가합니다.

그림: 단계 응용 프로그램 추가 - 다시 시작 - VM2

계획 그룹 추가 단계에서 다음 정보를 입력합니다.
1. 간단하지만 설명적인 단계 이름을 입력합니다. 이 예에서는 Application - Start - VM2를 사용합니다.
2. 이 단계가 실행될 인스턴스가 포함된 영역을 선택하십시오. 이 예제에서 스크립트는 영역 1의 WordPress 응용 프로그램 VM2에서 실행됩니다.
3. Run local script를 선택합니다.
4. 영역 1에서 WordPress 애플리케이션 VM2인 대상 인스턴스를 선택합니다.
5. 스크립트 매개변수에 매개변수와 함께 스크립트의 전체 경로를 입력합니다. 예: /home/opc/fsdrscripts/wdp_restart.sh.
6. 사용자로 실행에 opc을 입력합니다.
7. 단계 추가를 누릅니다.
그림: 단계 응용 프로그램을 생성하는 매개변수 - 재시작 - VM2

추가를 누릅니다.

그림: 계획 그룹 추가 응용 프로그램 - 다시 시작

페일오버 계획 사용자 정의가 성공적으로 완료되었습니다.

플랜-custom-fo-auh-complete.png

작업 7: 영역 2에서 사전 검사 실행

switchover 및 failover DR 계획이 모두 대기 영역 2에서 성공적으로 생성되었습니다. 이러한 계획을 통해 OCI Full Stack DR은 워크로드를 리전 1에서 리전 2로 전환할 수 있습니다. 후속 작업에는 전환 계획과 페일오버 계획에 대한 사전 검사를 실행하여 준비 상태를 보장하고 전환 프로세스를 검증하는 작업이 포함됩니다.

작업 7.1: 전환 계획에 대한 사전 검사 시작

스위치오버 DR 계획에 대한 사전 검사를 실행합니다.

지역 컨텍스트가 standby Region 2로 설정되어 있는지 확인합니다.
영역 2에서 올바른 DR 보호 그룹이 선택되었는지 확인하고, 대기 역할이어야 합니다.
전환 계획 이름을 누릅니다.
사전 검사 실행을 누릅니다.

그림: 전환 계획의 사전 검사를 실행하는 방법 표시

그림: 전환 계획의 완료된 사전 검사 표시

작업 7.2: 페일오버 계획에 대한 사전 검사 시작

페일오버 DR 계획에 대한 사전 검사를 실행합니다.

영역 컨텍스트가 대기 영역 2로 설정되었는지 확인하십시오.
영역 2에서 올바른 DR 보호 그룹이 선택되었는지 확인하고, 대기 역할이어야 합니다.
페일오버 계획 이름을 누릅니다.
사전 검사 실행을 누릅니다.

그림: 페일오버 계획의 사전 검사를 실행하는 방법 표시

그림: 페일오버 계획의 완료된 사전 검사 표시

작업 8: 영역 2에서 Switchover Plan 실행

switchover DR 계획을 실행하여 Oracle HeatWave MySQL을 사용하여 WordPress 애플리케이션을 영역 1에서 영역 2로 전환하는 프로세스를 시작합니다.

지역 컨텍스트가 standby Region 2로 설정되어 있는지 확인합니다.
영역 2에서 올바른 DR 보호 그룹이 선택되었는지 확인하고, 대기 역할이어야 합니다.
전환 계획 이름을 누릅니다.
계획 실행을 누릅니다.

이 작업은 영역 2에서 switchover 계획을 실행합니다.

태스크 7에서 이미 실행되었으므로 사전 검사를 사용으로 설정을 선택 해제합니다.
시작하려면 DR 계획 실행을 누릅니다.

전체보기 begin.png
그림: 전환 계획 실행 방법 표시

progress.png에서 exec-so-auh-in-
그림: 전환 계획 진행 중 표시

전체 작업 로드가 Region 1에서 Region 2로 완전히 전환될 때까지 switchover 계획을 모니터합니다.

대략 52분 안에 switchover 계획의 실행이 성공적으로 완료되었습니다.

complete.png에서 exec-so-auh-in-
그림: 완료된 전환 계획 실행을 보여줍니다.

그림: 완료된 전환 계획 실행을 보여줍니다.

작업 9: 영역 1에서 DR 계획 생성 및 사용자 정의

OCI Full Stack DR의 스위치오버가 성공적으로 완료됨에 따라 이제 리전 2가 기본 리전의 역할을 맡았고, 리전 1은 대기 리전으로 전환되었습니다.

작업 1에서 8에 설명된 것과 동일한 접근 방식을 따르고, 이제 대기 피어 영역으로 사용되는 영역 1의 DR 보호 그룹 내에서 전환 및 복구 계획을 생성하고 사용자 정의합니다.

플랜 만들기-dxb.png
그림: 영역 1에서 생성된 계획을 보여주는 스크린샷

계획-소-사용자 정의-dxb.png
그림: 영역 1의 전환 계획을 보여주는 스크린샷

그림: 영역 1의 페일오버 계획을 보여주는 스크린샷

다음 단계

자세한 내용은 관련 링크 섹션의 OCI Full Stack DR 및 Oracle HeatWave MySQL 설명서를 참조하십시오.

Oracle Cloud Infrastructure(OCI) 전체 스택 재해 복구
Oracle HeatWave MySQL
OCI 전체 스택 재해 복구
HeatWave MySQL
#full-stack-dr 슬랙 채널 참여

확인

작성자 - Antoun Moubarak(OCI 전문가를 위한 하이퍼스케일러)
제공자 - Suraj Ramesh(OCI Full Stack DR 제품 관리자)

추가 학습 자원

docs.oracle.com/learn에서 다른 실습을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 Oracle Learning Explorer가 되려면 education.oracle.com/learning-explorer을 방문하십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.

제목 및 저작권 정보

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24413-01

January 2025

Oracle and/or its affiliates.