DR 방법 선택

블록 볼륨 백업 및 복원

백업의 기본 목적은 비즈니스 연속성, 재해 복구 및 장기 아카이브를 지원하는 것입니다.

다음은 블록 볼륨 백업의 일반적인 사용 사례입니다.

동일한 볼륨의 복사본을 여러 개 만드는 중입니다. 백업은 동일한 데이터를 포함해야 하는 볼륨이 많은 인스턴스가 필요할 때 유용합니다.
나중에 새 볼륨으로 복원할 수 있는 스냅샷을 만듭니다.
기본 볼륨에 문제가 발생할 경우 신뢰할 수 있는 데이터 복사본이 있는지 확인합니다.

백업 계획과 목표를 정의할 때 다음 요인을 고려하십시오.

빈도: 데이터 백업 빈도입니다.
복구 시간: 백업이 복원되고 해당 백업을 사용하는 응용 프로그램이 액세스할 수 있을 때까지 기다릴 수 있는 시간입니다. 백업 생성 시간은 백업되는 데이터의 크기 및 마지막 백업 이후 변경된 데이터의 양과 같은 여러 요인에 따라 달라집니다.
저장된 백업 수: 사용할 수 있도록 유지해야 하는 백업 수 및 더 이상 필요하지 않은 백업에 대한 삭제 일정.

백업을 생성하고 복원할 때는 다음과 같은 최적의 방법을 고려하십시오.

백업을 만들기 전에 데이터가 일관성이 있는지 확인하고, 파일 시스템을 동기화하고, 가능한 경우 파일 시스템을 마운트 해제하고, 애플리케이션 데이터를 저장합니다. 디스크의 데이터만 백업됩니다. 백업을 만들 때 백업 상태가 REQUEST_RECEIVED에서 CREATING로 변경된 후 볼륨에 데이터 쓰기를 재개할 수 있습니다. 백업이 진행 중인 동안에는 백업 중인 볼륨을 삭제할 수 없습니다.
복원된 볼륨을 원래 볼륨이 연결된 컴퓨트 인스턴스에 연결하려는 경우 일부 운영체제는 동일한 볼륨 복원을 지원하지 않습니다. 이 제약 조건을 극복하려면 볼륨을 복원하기 전에 분할 영역 ID를 변경하십시오. 운영 체제의 분할 영역 ID를 변경하는 단계는 운영 체제에 따라 다릅니다. 컴퓨트 인스턴스의 운영체제에 대한 설명서를 참조하십시오.
백업이 성공적으로 생성되었는지 확인할 때까지 원래 볼륨을 삭제하지 마십시오.

애플리케이션이 둘 이상의 컴퓨트 인스턴스에 걸쳐 있는 볼륨을 여러 개 사용하는 경우 볼륨 그룹 백업을 사용하십시오. 볼륨 그룹은 여러 인스턴스에서 여러 볼륨을 사용하는 애플리케이션에 대해 백업 및 복제본을 생성하는 프로세스를 간소화합니다. 다음 다이어그램과 같이 볼륨 그룹 백업에서 전체 볼륨 그룹을 복원할 수 있습니다.

다음은 volume-backup-restore.png에 대한 설명입니다.

volume-backup-restore.png 그림에 대한 설명

파일럿 라이트 작성

pilot light라는 용어는 항상 켜져 있으며 집의 온도 센서에 의해 트리거될 때 히터를 빠르게 다시 시작하는 데 사용할 수 있는 전통적인 가스 구동 히터의 작은 불꽃을 나타냅니다. DR 컨텍스트에서 파일럿 표시등은 DR 사이트에 배치되고 최신 응용 프로그램 구성 및 중요 데이터를 포함하는 응용 프로그램의 중요한 핵심 구성 요소로 구성됩니다. 그런 다음 이러한 핵심 파일럿 라이트 구성 요소를 사용하여 재해 발생 시 운용 크기의 환경을 복원할 수 있습니다.

다음은 DR 사이트에서 파일럿 표시등의 중요한 구성 요소입니다.

데이터베이스 계층
Oracle Cloud Infrastructure Database 서비스를 사용하면 프로덕션 크기 리소스를 사용으로 설정하지 않고도 DR 사이트(가용성 도메인, 영역 또는 둘 다)에 전체 데이터베이스를 프로비전할 수 있습니다. DR이 활성화되면 데이터베이스 서버를 다시 시작하지 않고 서비스에 대한 단일 REST API 호출을 통해 더 많은 리소스를 사용으로 설정할 수 있습니다.
응용 프로그램 계층
모든 최신 구성을 포함하는 DR 사이트(가용성 도메인, 영역 또는 둘 다)에 하나의 응용 프로그램 서버만 배치합니다. Oracle Cloud Infrastructure의 사용자정의 이미지 기능을 사용하여 OS 및 애플리케이션을 주기적으로 백업한 다음 이러한 이미지를 사용하여 DR 사이트가 활성화될 때 새 서버를 프로비전할 수 있습니다.

예를 들어, 프로덕션 사이트에 8개의 응용 프로그램 서버가 포함된 경우 DR 사이트에 하나의 응용 프로그램 서버만 배치하고 rsync 또는 다른 도구를 사용하여 기본 사이트와 동기화된 상태로 유지합니다. DR이 활성화될 때 나머지 7개 서버를 프로비전하는 데 사용할 수 있는 DR 사이트의 이 서버에서 사용자 정의 이미지를 매일 만듭니다.
네트워킹 계층
DR 사이트의 파일럿 라이트에서 다음 Oracle Cloud Infrastructure 기능 및 서비스 사용
- IP 주소(전용 및 공용)
- DNS 서비스
- 로드 균형 조정 서비스

활성 대기 사용

활성 대기(마운트된 대기 데이터베이스와 비교)는 데이터베이스를 복구하는 동안 읽기 전용으로 열린 대기 데이터베이스입니다. 활성 대기 데이터베이스에는 Active Data Guard 기능 및 라이센스가 필요합니다.

Active Data Guard를 통해 물리적 대기 데이터베이스를 읽기 및 보고에 활용하여 기본 데이터베이스의 잠재적 작업 로드를 줄일 수 있습니다. Active Data Guard는 물리적 데이터 손상의 자동 블록 복구를 통해 포괄적인 데이터 보호를 제공하고 손실된 쓰기 및 논리적 블록 손상과 같은 다른 유형의 데이터 손상을 검사합니다. 마운트된 standby database를 사용하면 물리적 블록 손상의 자동 블록 복구를 제외한 많은 데이터 보호 이점을 활용할 수도 있습니다. RTO(복구 시간) 및 RPO(데이터 손실)는 열려 있는 읽기 전용 여부에 관계없이 모든 대기 데이터베이스로 Failover할 때 매우 낮습니다.

DR 방법을 선택할 때 대칭 또는 비대칭 리소스를 사용할지 고려합니다.

대칭 리소스: 역할 전환 시 애플리케이션 및 데이터베이스 성능이 유사하거나 동일하도록 대기 시스템이 기본 시스템과 대칭되도록 하는 것이 좋습니다. 또한 대기 데이터베이스에 운용 작업 로드를 따라잡을 충분한 리소스가 있으므로 재해 발생 시 데이터 손실이 최소화됩니다. 활성 대기 데이터베이스 또는 Active Data Guard 옵션으로 배치된 경우 DR 보호를 제공하는 동안 대기 데이터베이스가 읽기 전용으로 열립니다. 이렇게 하면 보고 및 질의를 오프로드할 수 있습니다.
비대칭 리소스: 이 구조는 대기 환경의 축소 구성입니다. Active Data Guard를 사용하는 경우에도 대기 데이터베이스를 읽기 전용으로 사용하면 작업을 대기 데이터베이스로 오프로드하는 것과 동일한 이점이 있습니다. 하지만 페일오버 후 기본 시스템과 일치하도록 시스템을 확장하지 않으면 성능이 동일하지 않을 수 있습니다.

비대칭 또는 작은 대기 시스템의 경우 비용이 적게 들지만 컴퓨팅, CPU 및 메모리를 적게 사용하면 비용이 절감될 수 있습니다. 장단점은 역할 전환 또는 페일오버 이벤트 이후입니다. 이전 기본 시스템과 일치하도록 확장(확장)하거나 성능 저하 또는 기능 저하를 수락해야 합니다.

콜드 대기 사용

콜드 대기라는 용어는 기본 환경의 중복 복제본이 DR 사이트에 배포되는 DR 시나리오를 설명하는 데 사용됩니다. 콜드 대기 환경은 기본 시스템이 실패하는 경우에만 활성화됩니다. 이렇게 하면 프로덕션 연속성에 스위치오버에 대해 잘 정의된 활성화 시간이 제공됩니다.

Oracle Cloud Infrastructure는 이러한 환경을 유지 관리하는 비용을 최소로 유지하는 콜드 대기 환경의 자동(프로그래밍) 배포를 지원합니다. DR 사이트에서 사용하는 활성 리소스 및 영구 스토리지에만 비용이 청구됩니다.