메트로 가상 데이터 센터(MVDC): 액티브-액티브 이중화 데이터 센터 완벽 가이드

IT 산업이 지속적으로 성장하면서 정보 시스템은 통신, 금융, 의료, 전자상거래, 물류, 정부 등 다양한 분야에서 그 중요성이 날로 커지고 있습니다. 정보 시스템의 서비스 중단은 경제적 손실과 핵심 데이터 유실을 초래할 뿐만 아니라 시장에서의 브랜드 이미지에도 심각한 타격을 줄 수 있습니다. 따라서 서비스 연속성 확보는 정보 시스템 구축에 있어 필수적인 요소이며, 현재는 주로 프로덕션 데이터의 복제본을 저장하는 재해 복구(Disaster Recovery, DR) 센터를 구축하는 방식으로 서비스 연속성을 강화하고 있습니다.

개요

기존의 전통적인 DR 솔루션에서는 하나의 프로덕션 데이터 센터(DC)마다 하나의 DR 센터를 배치합니다. DR 센터는 프로덕션 DC에 단시간 내 복구가 불가능한 재해가 발생하여 서비스가 중단되기 전까지는 서비스 접근을 제공하지 않습니다. 이러한 구조 때문에 DR 센터는 다음과 같은 문제점에 직면하게 됩니다.

프로덕션 센터에 정전, 화재, 홍수, 지진 등의 재해가 발생하면 수동 작업으로 DR 센터에 서비스를 전환해야 하며, 전문적인 복구 조치와 디버깅도 추가로 필요합니다. 이 과정에서 장기간의 서비스 중단과 서비스 불연속이 발생할 수 있습니다.
DR 센터는 평소 서비스를 제공하지 않고 대부분 유휴 상태로 머물러 자원 활용률이 낮아집니다.

이러한 한계를 극복하고 고객의 요구사항인 효율적인 자원 활용, 부하 분산, 두 데이터 센터 간 자동 전환을 충족하기 위해 Oracle®은 엔드투엔드 액티브-액티브 DC 솔루션을 출시했습니다. 이 솔루션은 두 개의 DC가 동시에 운영되면서 서비스 부하를 분산 처리하여 전체 서비스 능력과 자원 활용률을 향상시킵니다. 또한 장애 발생 시나 단일 DC 장애 상황에서도 서비스 인지 없이 자동으로 페일오버를 수행하며, RPO(Recovery Point Objective) 0과 RTO(Recovery Time Objective) 0을 실현합니다. 참고로 RTO는 애플리케이션 시스템과 배포 방식에 따라 달라질 수 있습니다.

현재 스토리지 업계에는 두 가지 가용성 모드가 존재합니다.

액티브-패시브(AP) 또는 액티브-스탠바이
액티브-액티브(AA) 또는 메트로 가상 데이터 센터(MVDC)

데이터베이스 계층의 핵심 구성 요소

데이터베이스(DB)는 무손실 옵션을 갖춘 액티브-스탠바이 모드로 구성해야 하며, 다음 항목들이 핵심 구성 요소입니다.

Oracle Data Guard Broker: Data Guard 구성을 자동화하고 중앙 집중화하여 복잡한 역할 변경 작업을 단일 명령어로 스위치오버 또는 페일오버할 수 있게 지원합니다.
Flashback Database: DB를 되감거나 되돌릴 수 있는 기능을 제공하며, 플래시백 로그 정보를 플래시 복구 영역에 저장합니다.
Fast-Start Failover(FSFO): 무손실 페일오버를 가능하게 합니다. FSFO는 스탠바이 DB가 프라이머리 DB와 동기화된 상태일 때만 트리거됩니다.
Observer: Data Guard 명령줄 인터페이스인 dgmgrl에 통합된 독립 프로세스로, 장애 조건 발생 여부를 판단하기 위해 프라이머리 및 스탠바이 DB의 상태를 감시합니다.

Data Guard 구성

다음 이미지는 Data Guard 구성을 보여줍니다.

메트로 가상 데이터 센터(MVDC): 액티브-액티브 이중화 데이터 센터 완벽 가이드

이미지 출처: https://neeraj-dba.blogspot.com/2011/10/dataguard-broker-and-its-benefits_05.html

프라이머리 DB에서는 LGWR(Log Writer) 프로세스가 리두(redo) 데이터를 하나 이상의 LNSn(Log Network Server) 프로세스에 전달하고, LNSn 프로세스는 여러 원격 목적지로 네트워크 I/O를 병렬로 시작합니다. 모든 LGWR SYNC 목적지에서 해당 트랜잭션 복구에 필요한 리두 데이터를 수신하기 전까지는 프라이머리 데이터베이스에서 트랜잭션이 커밋되지 않습니다.

스탠바이 DB에서는 RFS(Remote File Server)가 네트워크를 통해 LGWR 프로세스로부터 리두 데이터를 수신하고, 이를 스탠바이 리두 로그 파일에 기록합니다.

최대 가용성 아키텍처

최대 가용성을 위한 아키텍처를 설계할 때는 다운타임의 잠재적 원인과 계획되지 않은 다운타임 및 계획된 다운타임의 분류 기준을 함께 고려해야 합니다.

계획되지 않은 다운타임에는 다음 항목들에 대한 예기치 않은 중단이 포함됩니다.

서버 가용성: 하드웨어 또는 소프트웨어 결함으로 DB 서버를 호스팅하는 하나 이상의 머신에 예기치 않은 장애가 발생하더라도 DB 서비스에 대한 접근이 끊기지 않도록 보장해야 합니다. Oracle RAC(Real Application Clusters)는 이러한 장애에 대해 가장 효과적인 보호 기능을 제공합니다.
데이터 가용성: 비즈니스 핵심 데이터의 유실, 손상, 오염 같은 데이터 장애에 대비하려면 어떤 상황에서도 데이터에 접근할 수 있도록 계획을 수립해야 합니다.

계획된 다운타임에는 다음과 같은 예정된 접근 중단이 포함됩니다.

시스템 변경
데이터 변경
애플리케이션 변경

MVDC를 위한 스위치오버 테스트 시나리오

스위치오버(Switchover)는 Data Guard 구성에서 프라이머리 DB와 스탠바이 DB가 서로 역할을 교환하는 통제된 계획 작업입니다. 스위치오버 후에도 각 데이터베이스는 새로운 역할로 Data Guard 구성에 계속 참여합니다.

스위치오버 프로세스

스위치오버는 다음 순서로 진행됩니다.

기존 프라이머리 DB가 스탠바이 역할로 전환됩니다.
기존 스탠바이 DB가 프라이머리 역할로 전환됩니다.

스위치오버를 수행하면 Data Guard Broker가 다음 작업들을 자동으로 처리합니다.

프라이머리 DB와 대상 스탠바이 DB가 온라인 상태이며 오류가 없는지 검증합니다.
프라이머리 및 스탠바이 DB 양쪽에서 RAC 구성의 인스턴스 중 하나를 제외한 나머지를 모두 종료합니다.
프라이머리와 스탠바이 DB의 역할을 교환합니다. Broker는 먼저 기존 프라이머리 DB를 스탠바이 역할로 변환한 뒤, 대상 스탠바이 DB를 프라이머리 역할로 전환합니다. 또한 Broker 구성 파일을 갱신하여 역할 변경 사항을 기록함으로써 재시작 후에도 각 DB가 올바른 역할로 운영되도록 보장합니다.
새로운 스탠바이(구 프라이머리) DB를 재시작하고 Redo Apply 프로세스를 시작하여 새 프라이머리 DB의 리두 데이터를 적용합니다. RAC DB인 경우, 스위치오버 전에 종료했던 인스턴스들을 다시 시작합니다.
새로운 프라이머리 DB를 재시작하고, 열어서 리두 전송 서비스를 시작하여 스탠바이 DB로 리두 데이터를 전송합니다. RAC DB인 경우, 스위치오버 전에 종료했던 인스턴스들을 다시 시작합니다.

스위치오버 전:

이미지 출처: https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615

스위치오버 후:

이미지 출처: https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615

스위치오버 수행 절차

스위치오버를 수행하려면 다음 단계를 실행합니다.

애플리케이션이 완전히 종료되었고 데이터베이스에 접속한 사용자가 없는지 확인합니다.
스위치오버 시작 최소 30분 전에 양쪽 DC에서 실행 중인 아카이브 UTL 스크립트를 비활성화합니다. 테스트가 완료되고 DB가 선호 위치에서 운영되면 해당 유틸리티 스크립트의 주석을 다시 해제합니다.

현재 프라이머리 DB에서 다음 SQL 쿼리를 실행합니다.

SELECT * FROM DBA_JOBS_RUNNING; (sys 소유의 작업이 실행 중이어서는 안 됩니다)
SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED FROM DBA_SCHEDULER_JOBS WHERE ENABLED='TRUE' AND OWNER <> 'SYS';
    (Data Guard Broker는 sys 소유의 작업을 종료하지 않습니다.)

job_queue_processes와 aq_tm_processes를 0으로 설정합니다. 스위치오버 테스트 완료 후 원래 값으로 되돌려야 하므로 원래 값을 기록해 둡니다.
프라이머리 DB에서 실행 중인 emagent를 중지합니다.

현재 프라이머리 DB에서 다음 SQL 쿼리를 실행합니다.

 SELECT sid, username, status, program, inst_id FROM gv$session
 WHERE username is not null and status='ACTIVE' order by inst_id;
     (활성 연결 수를 검증합니다. 활성 연결이 많으면 스위치오버에 더 많은 시간이 소요될 수 있습니다.)

sys로 접속한 모든 sqlplus 세션에서 로그아웃합니다.

현재 프라이머리 DB에서 다음 SQL 쿼리를 실행합니다.

 set linesize to 132
 col value format a35
 SELECT inst_id,name,value from gv$parameter
 WHERE name in ('job_queue_processes','aq_tm_processes');
     (job_queue_processes와 aq_tm_processes 값이 0인지 확인하고 검증합니다.)

다음 명령어로 Data Guard 구성을 검증합니다.

DGMGRL> show configuration verbose

** STATUS가 success로 표시되어야 합니다. status가 "success"가 아니면 진행하지 마십시오.

CRS(Cluster Ready Services) 상태를 확인하여 모든 리소스가 온라인으로 등록되어 있는지 점검합니다. 이 과정에서 Broker는 DB 마운트 및 종료 작업을 CRS에 위임하기 때문입니다.
프라이머리 DB에서 몇 개의 로그를 스위치오버하고 스탠바이 DB에 적용되었는지 확인합니다.
진행하기 전에 스위치오버를 수행하고 DRC 로그와 alert 로그에서 장애 여부를 모니터링합니다. 다음 명령어는 기존 프라이머리를 스탠바이로 변환한 후 기존 스탠바이를 프라이머리로 변환합니다.
```
DGMGRL> switchover to ‘DDMPROD_STANDBY’;
```
스위치오버가 완료되면 로그 전송 및 로그 적용 서비스가 정상적으로 작동 중인지 확인합니다.

MVDC를 위한 페일오버 테스트 시나리오

페일오버(Failover)는 프라이머리 DB(RAC 프라이머리 DB의 모든 인스턴스)에 장애가 발생했을 때 스탠바이 DB가 프라이머리 역할을 인수하도록 전환되는 것을 말합니다. 페일오버는 다음과 같은 경우에 수행됩니다.

프라이머리 DB에 치명적인 장애가 발생하여 단기간 내 복구가 불가능한 경우
Observer와 스탠바이 DB가 모두 프라이머리 DB와의 네트워크 연결을 잃었고, 스탠바이 DB가 동기화(synchronized) 상태임을 확인한 경우

페일오버 시나리오

다음과 같은 DB 조건에서 Fast-Start Failover가 트리거됩니다.

프라이머리 사이트 장애
프라이머리 DB 조건, 구체적으로는 다음과 같습니다.
인스턴스 장애
RAC 환경에서 마지막 생존 인스턴스의 장애
마지막 가용 인스턴스의 shutdown abort
I/O 오류로 인한 데이터 파일 오프라인(오프라인 데이터 파일로 인한 페일오버 수행 시 임계값은 무시됩니다)

네트워크 관련 조건은 프라이머리와 Observer 간 링크, 그리고 프라이머리와 대상 스탠바이 DB 간 링크가 모두 다운된 경우에만 페일오버를 유발할 수 있습니다. Observer가 구성이 동기화 상태임을 확인하려면 Observer와 스탠바이 간 연결이 필요합니다.

이미지 출처: https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615

결론

MVDC는 효율적인 자원 활용, 부하 분산, 고가용성, 두 데이터 센터 간 자동 전환을 실현합니다. 두 DC가 동시에 운영(액티브-액티브)되면서 서비스 부하를 분산하고 전체 서비스 능력을 향상시킵니다. 또한 재해 복구 페일오버나 업그레이드/유지보수를 위한 전환 시 데이터베이스 간 전환에 필요한 사람의 개입을 크게 줄여줍니다.

의견이나 질문이 있다면 피드백 탭을 이용해 주세요.

전문가의 관리 및 구성 서비스로 환경 최적화하기

Rackspace의 애플리케이션 서비스 (RAS) 전문가들은 폭넓은 애플리케이션 포트폴리오 전반에서 다음과 같은 전문 및 관리형 서비스를 제공합니다.

e커머스 및 디지털 경험 플랫폼
ERP(Enterprise Resource Planning)
비즈니스 인텔리전스(BI)
Salesforce CRM(Customer Relationship Management)
데이터베이스
이메일 호스팅 및 생산성 도구

Rackspace가 제공하는 것:

편향 없는 전문성: 즉각적인 가치를 창출하는 역량에 집중하여 현대화 여정을 단순화하고 안내합니다.
Fanatical Experience™: '프로세스 우선, 기술 차후(Process first. Technology second.®)' 접근 방식과 전담 기술 지원을 결합하여 포괄적인 솔루션을 제공합니다.
독보적인 포트폴리오: 광범위한 클라우드 경험을 바탕으로 올바른 클라우드에 적합한 기술을 선택하고 배포할 수 있도록 지원합니다.
애자일한 서비스 제공: 고객의 여정 어느 단계에서든 함께하며 고객의 성공과 우리의 성공을 일치시킵니다.

지금 바로 채팅으로 시작해 보세요.