이 문서에서는 Google Cloud에서 재해 복구를 설계 및 구현하는 설계자와 기술 책임자를 위한 Microsoft SQL Server 재해 복구(DR) 전략을 소개합니다.
데이터베이스는 하드웨어 또는 네트워크 장애와 같은 다양한 이유로 인해 사용할 수 없게 될 수 있습니다. 장애 발생 시 연속적인 데이터베이스 액세스를 제공하기 위해 기본 데이터베이스의 복제본인 보조 데이터베이스가 유지보수됩니다. 보조 데이터베이스를 다른 위치에 두면 기본 데이터베이스를 사용할 수 없을 때 보조 데이터베이스를 사용할 가능성이 높아집니다.
기본 데이터베이스를 사용할 수 없게 되면 업무상 중요한 앱이 보조 데이터베이스에 연결되어 가장 최근에 알려진 일관된 데이터 상태에서 계속 작동하여 다운타임이 거의 또는 전혀 없이 사용자에게 서비스를 제공합니다.
기본 데이터베이스에 장애가 발생할 경우 보조 데이터베이스를 사용할 수 있게 만드는 프로세스를 데이터베이스 재해 복구(DR)라고 합니다. 보조 데이터베이스는 기본 데이터베이스의 가동 중지 상태를 복구합니다. 보조 데이터베이스는 기본 데이터베이스를 사용할 수 없을 때 기본 데이터베이스와 똑같은 일관된 상태를 유지하거나, 기본 데이터베이스에서 최소한의 최근 트랜잭션만 누락된 상태이면 좋습니다.
데이터베이스 DR은 기업 고객에게 필수적인 기능입니다. 주 목적은 업무상 중요한 앱의 비즈니스 연속성을 유지하는 것입니다. 예를 들어 업무상 중요한 앱은 수익(전자상거래)을 창출하거나, 지속적으로 신뢰할 수 있는 서비스(항공편 또는 발전소 관리)를 제공하거나, 생명 유지 기능(환자 모니터링)을 지원합니다. 이러한 모든 예에서 가장 중요한 것은 업무상 중요한 앱을 계속 사용할 수 있도록 하는 것입니다.
대부분의 데이터베이스 관리 시스템은 Microsoft SQL Server를 포함한 재해 복구 기능을 제공합니다. 이 아키텍처 문서에서는 SQL Server에서 제공하는 DR 기능을 Google Cloud의 컨텍스트에서 구현하는 방법을 설명합니다.
용어
다음 섹션에서는이 문서 전체에서 사용되는 용어를 설명합니다.
일반적인 DR 아키텍처
다음 다이어그램은 일반적인 DR 아키텍처 토폴로지를 보여줍니다.
위의 다이어그램에서 앱은 보조 데이터베이스가 대기하는 동안 기본 데이터베이스에 액세스하고 기본 데이터베이스의 상태를 미러링합니다. 클라이언트가 Google Cloud에서 실행되는 앱에 액세스합니다.
기본 데이터베이스를 사용할 수 없게 되면 데이터베이스 관리자 또는 운영팀이 재해 복구 프로세스를 시작해야 합니다. 데이터베이스 재해 복구가 시작되면 앱이 보조 데이터베이스에 다시 연결됩니다. 앱이 연결되면 클라이언트에 다시 서비스를 제공할 수 있습니다. 이상적인 상황에서는 보조 데이터베이스에서 가능한 한 빨리 앱을 사용할 수 있으므로 클라이언트가 서비스 중단을 경험하지 못할 수도 있습니다. 한 가지 대안은 재해 복구를 시작하는 대신 기본 데이터베이스가 다시 액세스 가능할 때까지 기다리는 것입니다. 예를 들어 재해가 간헐적으로 발생하는 경우 장애 조치보다 문제를 해결하는 것이 더 빠를 수도 있습니다.
기본 및 보조 데이터베이스
기본 데이터베이스는 1개 이상의 앱이 액세스하므로 앱의 상태 관리를 위한 지속성 서비스를 제공합니다. 보조 데이터베이스는 기본 데이터베이스와 관련이 있으며 기본 데이터베이스의 복제본을 포함합니다. 보조 데이터베이스의 콘텐츠가 어느 시점에서든 기본 데이터베이스의 콘텐츠와 정확하게 일치하는 것이 좋습니다. 대부분의 경우 보조 데이터베이스는 기본 데이터베이스의 트랜잭션 변경내용을 적용하는 동안 발생하는 지연 시간으로 인해 기본 데이터베이스보다 지연됩니다. 데이터베이스 기술에 따라 여러 보조 데이터베이스를 기본 데이터베이스와 연결할 수 있습니다. SQL Server는 여러 보조 데이터베이스와 기본 데이터베이스의 연결을 지원합니다.
재해 복구
기본 데이터베이스를 사용할 수 없게 되면 DR은 보조 데이터베이스의 역할을 기본 데이터베이스로 변경합니다. 보조 데이터베이스가 여러 개 있는 경우 해당 데이터베이스 중 1개를 수동으로 또는 선호하는 장애 조치 목록을 기준으로 선택합니다. 앱은 새 기본 데이터베이스에 다시 연결하여 상태에 계속 액세스해야 합니다. 새 기본 데이터베이스가 이전 기본 데이터베이스의 마지막으로 알려진 상태와 동기화되지 않은 경우 앱은 과거 상태에서 시작됩니다(flashback이라고도 함).
모든 기본 데이터베이스에 보조 데이터베이스가 항상 1개 이상 있어야 합니다. 재해 복구 후 향후 재해 복구 시나리오를 처리할 수 있도록 새로운 보조 데이터베이스가 설정되어 있는지 확인하세요.
장애 조치, 전환, 대체
기본 데이터베이스와 보조 데이터베이스 간의 역할을 변경하는 시나리오는 여러 가지가 있습니다.
- 장애 조치: 보조 데이터베이스의 역할을 새 기본 데이터베이스로 변경하고 모든 앱을 새 기본 데이터베이스로 연결하는 프로세스입니다. 장애 조치는 기본 데이터베이스를 사용할 수 없게 될 경우에 트리거되므로 의도되지 않은 프로세스입니다. 장애 조치가 자동 또는 수동으로 트리거되도록 구성할 수 있습니다.
- 전환: 장애 조치와 달리 기본 데이터베이스에서 보조 데이터베이스(새 기본 데이터베이스)로의 전환은 초기 테스트 및 예약된 유지보수를 위해 의도적으로 트리거됩니다. 정기적인 전환으로 DR 시스템을 테스트하여 재해 복구의 지속적인 신뢰성을 보장하세요.
- 대체: 대체는 전환 프로스세스와 반대입니다. 기본 데이터베이스가 복구된 후 새 기본 데이터베이스가 보조 데이터베이스가 됩니다. 대체는 장애 조치 또는 전환이 시작되기 전의 상태를 다시 설정하기 위해 의도적으로 트리거됩니다. 꼭 필요하지는 않지만 지역 또는 가용 리소스와 같은 재해 복구 요구사항에 따라 수행할 수 있습니다.
Google Cloud 영역 및 리전
데이터베이스와 같은 리소스는 Google Cloud 영역 및 리전에 위치하며, 각 영역은 리전 하나에 속합니다. 영역은 단일 장애점 도메인입니다. 1개 리전의 여러 영역에 고가용성 및 내결함성 리소스를 배포하는 것이 좋습니다.
전체 리전의 서비스 중단 방지를 위해 재해 복구를 위한 다중 리전 전략을 수립하세요. 예를 들어 기본 데이터베이스가 한 리전에 있고 해당 보조 데이터베이스가 다른 리전에 있는 경우가 있습니다.
활성 모드: 활성-수동 및 활성-활성
기본 데이터베이스는 읽기 및 쓰기 작업(DML 작업)을 위해 열려 있는 데이터베이스이므로 데이터베이스에 액세스하는 앱이 데이터베이스의 상태를 관리할 수 있습니다. 기본 데이터베이스를 활성 데이터베이스라고 합니다. 해당 보조 데이터베이스는 기본 데이터베이스를 복제하기 때문에 수동이지만 어떤 앱에서도 상태 변경 작업에 사용할 수 없습니다. 장애 조치 또는 전환 후에는 보조 데이터베이스가 새 기본 데이터베이스가 되고 활성 데이터베이스가 됩니다.
데이터베이스 기술이 활성-활성 모드라고 하는 이 기능을 지원하는 경우 기본 데이터베이스와 보조 데이터베이스가 모두 활성 데이터베이스가 될 수 있습니다. 이 경우 두 데이터베이스를 모두 상태 관리에 사용할 수 있으므로 앱을 다른 앱과 연결할 수 있습니다. 활성-활성 모드의 재해 복구는 활성 데이터베이스 중 하나만 사용할 수 없게 될 경우 장애 조치가 필요하지 않습니다. 한 활성 데이터베이스를 사용할 수 없으면 다른 활성 데이터베이스를 계속 사용할 수 있습니다. 활성-활성 모드는 SQL Server에서 지원하지 않으므로 이 문서에서 다루지 않습니다.
대기 모드: 상시 대기, 웜 대기, 수동 대기, 대기 없음
기본 데이터베이스가 활성 데이터베이스가 되려면 기본 데이터베이스가 실행 중이어야 하며 DML 문을 실행할 수 있어야 합니다. 보조 데이터베이스는 실행 중일 필요가 없으며 종료할 수 있습니다. 기본 데이터베이스가 실행되고 있지 않으면 새 기본 데이터베이스의 역할을 할당하기 전에 먼저 실행 상태로 전환해야 하기 때문에 재해 복구 시간이 늘어납니다.
보조 데이터베이스를 설정하는 방법은 여러 가지입니다.
- 상시 대기: 보조 데이터베이스가 실행 중이고 클라이언트에 연결할 준비가 되었습니다. 기본 데이터베이스의 확인 가능한 최신 변경내용이 발생하는 즉시 항상 보조 데이터베이스에 적용됩니다.
- 웜 대기: 보조 데이터베이스가 실행 중이지만 기본 데이터베이스의 모든 변경내용이 아직 반드시 적용되지는 않습니다.
- 수동 대기: 보조 데이터베이스가 실행되고 있지 않습니다. 먼저 보조 데이터베이스를 시작한 후 확인 가능한 최신 상태로 동기화해야 합니다.
- 대기 없음: 기본 데이터베이스의 모든 변경내용이 적용되기 전에 먼저 데이터베이스 소프트웨어를 설치하고 시작해야 합니다. 이 모드는 필요하지 않을 때 리소스를 소비하지 않기 때문에 비용이 가장 적게 드는 모드이지만 다른 모드와 비교할 때 새 기본 데이터베이스가 되는 데 가장 오랜 시간이 걸립니다.
DR 전략
다음 섹션에서는 Microsoft SQL Server가 지원하는 DR 전략을 설명합니다.
복구 전략 요소
데이터베이스 재해 복구 전략을 선택하거나 구현할 때 고려해야 할 몇 가지 주요 요소가 있습니다. 각 요소에는 스펙트럼이 있으며 재해 복구 전략의 행동 및 기대치는 스펙트럼상의 지점 선택에 따라 달라집니다. 주요 요소는 다음과 같습니다.
- 복구 지점 목표(RPO). 주요 이슈로 인해 앱에서 데이터가 손실될 수 있는 최대 허용 기간입니다. 이 요소는 데이터가 사용되는 방식에 따라 다릅니다. RPO는 기본 데이터베이스를 사용할 수 없게 된 때부터 경과한 기간(초, 분 또는 시간)으로 표현되거나 식별 가능한 처리 상태(마지막 전체 백업 또는 마지막 증분 백업)로 표현될 수 있습니다. RPO가 어떻게 지정되든 재해 복구 전략은 RPO 요구사항을 충족할 수 있도록 특정 조치를 구현해야 합니다. 가장 까다로운 경우는 기본 데이터베이스에서 보조 데이터베이스로의 손실이 전혀 발생하지 않아야 하는 최종 커밋된 트랜잭션입니다.
- 복구 시간 목표(RTO). 앱이 오프라인 상태가 될 수 있는 최대 허용 기간입니다. 이 값은 일반적으로 더 큰 서비스수준계약의 일부로 정의됩니다. RTO는 일반적으로 기본 데이터베이스를 사용할 수 없게 된 때부터 경과한 기간으로 표현됩니다. 예를 들어 앱은 5분 이내에 완전히 작동해야 합니다. 가장 까다로운 경우는 앱 사용자가 재해 복구가 발생한 사실을 알아채지 못하도록 즉시 복구해야 하는 경우입니다.
- 단일 장애점 도메인. 특정 리전이 재해 복구 요구사항에 적합한 단일 장애점 도메인으로 간주되는지 여부는 사용자가 판단해야 합니다. 특정 리전이 단일 장애점 도메인인 경우 재해 복구를 설정하여 2개 이상의 리전이 실제 설정에 포함되도록 해야 합니다. 기본 데이터베이스가 포함된 리전에 장애가 발생하면 다른 리전의 보조 데이터베이스가 새 기본 데이터베이스가 됩니다. 단일 장애점 도메인이 영역으로 간주될 경우 단일 리전 내의 여러 영역에 재해 복구를 설정할 수 있습니다. 영역에 장애가 발생하면 재해 복구 시 두 번째 영역이 사용되고 해당 영역에서 새 기본 데이터베이스를 사용할 수 있게 됩니다.
이러한 주요 요소를 결정하는 것은 비용과 품질 중에 선택하는 것과 같습니다. RTO 및 RPO가 낮을수록 더 많은 활성 리소스가 사용되므로 재난 복구 솔루션의 비용이 증가합니다. 다음 섹션에서는 Microsoft SQL Server 데이터베이스의 컨텍스트에서 요소의 지점을 나타내는 여러 대체 DR 전략을 설명합니다.
SQL Server용 DR 전략
재해 복구 전략을 구현하는 데 사용할 수 있는 가용성 기능에 대한 설명은 비즈니스 연속성 및 데이터베이스 복구 - SQL Server를 참조하세요.
예비 과정
SQL Server는 Windows와 Linux 모두에서 실행됩니다. 그러나 모든 가용성 기능을 Linux에서 사용할 수 있는 것은 아닙니다. SQL Server는 여러 버전이 있지만 모든 버전에서 모든 가용성 기능을 사용할 수 있는 것은 아닙니다.
SQL Server는 인스턴스를 데이터베이스와 구별합니다. 인스턴스는 SQL Server 소프트웨어를 실행하고, 데이터베이스는 SQL Server 인스턴스에서 관리하는 데이터 집합입니다.
Always On 가용성 그룹
Always On 가용성 그룹은 데이터베이스 수준의 보호 기능을 제공합니다. 가용성 그룹에는 여러 개의 복제본이 있습니다. 1개 복제본이 읽기 및 쓰기 액세스 권한을 가진 기본 복제본이며 나머지 복제본은 읽기 액세스를 제공할 수 있는 보조 복제본입니다. 각 데이터베이스 복제본은 독립형 SQL Server 인스턴스에서 관리합니다. 가용성 그룹에는 1개 이상의 데이터베이스가 포함될 수 있습니다. 가용성 그룹에 포함될 수 있는 데이터베이스 수와 지원되는 보조 복제본 수는 SQL Server 버전에 따라 다릅니다. 가용성 그룹의 모든 데이터베이스에는 동일한 수명 주기 변경이 동시에 적용됩니다. 기본 데이터베이스만 쓰기 액세스를 지원하기 때문에 가용성 그룹은 활성-수동 모드를 구현합니다.
장애 조치가 발생하면 보조 복제본이 새로운 기본 복제본이 됩니다. 가용성 그룹에는 독립형 SQL Server 인스턴스가 포함되어 있으므로 트랜잭션 로그에 캡처된 모든 작업을 복제본에서 사용할 수 있습니다. 트랜잭션 로그에 캡처되지 않은 변경내용은 수동으로 동기화해야 합니다(예: SQL Server 인스턴스 수준 로그인 또는 SQL Server 에이전트 작업). 데이터베이스 수준 보호 및 SQL Server 인스턴스 보호를 제공하려면 장애 조치 클러스터 인스턴스(FCI)를 설정해야 합니다. 이 배포 아키텍처는 나중에 Always On 장애 조치 클러스터 인스턴스 섹션에서 설명합니다.
리스너를 사용하여 역할 변경으로부터 앱을 보호할 수 있습니다. 리스너는 앱이 가용성 그룹에 연결하도록 지원합니다. 앱은 어느 시점에서는 어떤 SQL Server 인스턴스가 기본 데이터베이스 또는 보조 복제본을 관리하는지 알지 못합니다. 리스너를 사용하려면 비즈니스 연속성 및 데이터베이스 복구 - SQL Server에 설명된 대로 업데이트가 적용된 .NET 3.5 또는 4.0 이상의 버전을 사용해야 합니다.
가용성 그룹은 기본 추상화 계층을 사용하여 기능을 제공합니다. 가용성 그룹은 SQL Server의 Windows Server 장애 조치(Failover) 클러스터링에 설명된 대로 Windows Server 장애 조치 클러스터(WSFC)에서 실행됩니다. SQL Server 인스턴스를 실행하는 모든 노드는 동일한 WSFC의 일부여야 합니다.
트랜잭션은 기본 데이터베이스에서 모든 보조 복제본으로 전송됩니다. 트랜잭션 전송 모드에는 동기 및 비동기라는 두 가지 전송 모드가 있습니다. 한 모드 또는 다른 모드를 사용하도록 각 복제본을 독립적으로 구성할 수 있습니다. 동기 전송 모드에서는 기본 데이터베이스의 트랜잭션이 동기적으로 연결된 모든 보조 복제본에서 성공해야만 성공한 것으로 간주됩니다. 비동기 모드에서는 기본 데이터베이스의 트랜잭션이 모든 보조 복제본에 적용되지 않았더라도 성공한 것으로 간주될 수 있습니다.
전송 모드 선택에 따라 가능한 RTO, RPO, 대기 모드가 달라집니다. 예를 들어 트랜잭션이 동기 모드에서 모든 복제본에 전송되면 모든 복제본의 상태가 똑같아집니다. 모든 복제본이 완전히 동기화되므로 가장 까다로운 RPO(가장 최근의 트랜잭션)를 구현할 수 있습니다. 보조 복제본이 상시 대기 상태이므로 기본 데이터베이스로 즉시 사용할 수 있습니다.
장애 조치는 자동 또는 수동으로 이루어질 수 있습니다. 모든 복제본이 완전히 동기화되면 자동 장애 조치가 가능합니다. 앞의 예에서는 모든 복제본이 항상 완전히 동기화되므로 이 작업이 가능합니다.
다음 그림은 단일 리전의 Always On 가용성 그룹을 보여줍니다.
가용성 그룹은 영역을 확장하는 사각형으로 표시됩니다. 모든 데이터베이스가 동일한 가용성 그룹에 속하는 것을 설명하기 위한 것입니다. 가용성 그룹은 클라우드 리소스가 아니며 따라서 노드 또는 다른 유형의 리소스에 구현되지 않습니다.
Always On 장애 조치 클러스터 인스턴스
노드 오류를 방지하기 위해 독립형 SQL Server 인스턴스 대신 장애 조치 클러스터 인스턴스(FCI)를 사용할 수 있습니다. SQL Server 인스턴스를 실행하여 데이터베이스(기본 또는 보조)를 관리하는 노드가 여러 개 있습니다. 데이터베이스를 관리하는 노드는 장애 조치 클러스터를 형성합니다. 클러스터의 한 노드는 SQL Server 인스턴스를 실행하고 다른 노드는 SQL Server 인스턴스를 실행하지 않습니다. SQL Server 인스턴스를 실행하는 노드에 장애가 발생하면 클러스터의 다른 노드가 SQL Server 인스턴스를 시작하여 데이터베이스 관리를 인계합니다(노드 장애 조치). SQL Server 인스턴스를 자동으로 시작하는 이 프로세스는 고가용성 기능을 제공합니다.
FCI 클러스터는 단일 장치로 표시되고, 클러스터에 액세스하는 클라이언트는 단기간 동안 사용할 수 없는 경우를 제외하고는 노드 간의 장애 조치를 볼 수 없습니다. 노드 장애 조치가 발생할 때는 데이터 손실이 없습니다. 장애가 발생한 SQL Server 인스턴스 내에서 실행되는 모든 항목은 동일한 클러스터의 다른 SQL Server 인스턴스로 이동됩니다. 예를 들어 SQL Server 에이전트 작업 또는 연결된 서버는 다른 인스턴스로 이동됩니다.
서로 다른 Google Cloud 영역에 FCI 클러스터 노드를 설정할 수 있습니다. 이 아키텍처는 노드 장애뿐만 아니라 영역 장애에도 높은 가용성을 제공합니다. 이 전략의 배포 예는 DR 배포 옵션 섹션에서 설명합니다.
여러 노드가 동일한 데이터베이스를 관리하고 데이터베이스를 공유하더라도 FCI 클러스터의 노드 간에 공통 스토리지는 필요하지 않습니다. SQL Server는 S2D(Storage Spaces Direct) 기능을 사용하여 전용 노드 디스크의 데이터베이스를 관리합니다. 자세한 내용은 SQL Server 장애 조치 클러스터 인스턴스 구성을 참조하세요.
독립형 SQL Server 인스턴스 대신 FCI를 사용하는 Always On 가용성 그룹이라는 이전 섹션의 예가 다음 그림에 나와 있습니다. 각 FCI에는 데이터베이스를 관리하는 활성 SQL Server 인스턴스가 1개 있습니다.
FCI는 가용성 그룹의 경우와 마찬가지로 직사각형으로 표현되었습니다. 이는 모든 노드가 동일한 FCI에 속하는 것을 설명하기 위함입니다. FCI는 클라우드 리소스가 아니므로 노드 또는 다른 유형의 리소스에 구현되지 않습니다.
자세한 설명은 Always On 장애 조치 클러스터 인스턴스(SQL Server)를 참조하세요.
분산 가용성 그룹
분산 가용성 그룹은 특별한 유형의 가용성 그룹입니다. 분산 가용성 그룹은 2개의 가용성 그룹으로 나뉩니다. 하나는 기본 가용성 그룹 역할을 하고 다른 하나는 보조 가용성 그룹 역할을 합니다. 분산 가용성 그룹은 동기 및 비동기 모드의 트랜잭션을 기본 가용성 그룹에서 보조 가용성 그룹으로 전달할 수 있습니다.
각 가용성 그룹에는 고유한 기본 데이터베이스가 있지만 활성-활성 배포가 아닙니다. 기본 가용성 그룹의 기본 데이터베이스만 쓰기 작업을 수신할 수 있습니다. 보조 가용성 그룹의 기본 데이터베이스를 전달자라고 합니다. 전달자는 기본 가용성 그룹에서 트랜잭션을 수신하고 이를 보조 가용성 그룹의 보조 데이터베이스로 전달합니다. 기본 가용성 그룹에서 보조 가용성 그룹으로 장애 조치가 수행되면 새로운 기본 가용성 그룹의 기본 데이터베이스가 쓰기 작업을 위한 액세스를 지원합니다.
기본 및 보조 가용성 그룹은 동일한 위치에 있을 필요가 없으며 동일한 운영체제에 있지 않아도 됩니다. 그러나 각 가용성 그룹에는 리스너가 설치되어 있어야 합니다. 분산 가용성 그룹 자체에는 리스너가 없습니다. 분산 가용성 그룹에서는 두 가용성 그룹이 동일한 WSFC에 있지 않아도 됩니다. 분산 가용성 그룹을 작동시키는 데 필요한 모든 기능이 SQL Server 기능에 포함되어 있으며 기본 구성요소를 추가로 설치할 필요가 없습니다.
분산 가용성 그룹은 정확히 가용성 그룹 두 개에 걸쳐 있습니다. 가용성 그룹은 2개의 분산 가용성 그룹에 속할 수 있습니다. 따라서 여러 토폴로지를 지원합니다. 하나는 여러 위치의 가용성 그룹 간에 적용되는 데이지 체이닝(daisy chaining) 토폴로지입니다. 또 다른 토폴로지는 기본 가용성 그룹이 2개의 서로 다른 분산 가용성 그룹의 일부인 트리형 토폴로지입니다.
분산 가용성 그룹은 운영체제에 재해 복구를 구현하는 주요 방법입니다. 예를 들어 Windows에서 기본 가용성 그룹을 설정하고 Linux에서 두 번째 가용성 그룹을 구성할 수 있습니다. 두 가용성 그룹은 모두 분산 가용성 그룹을 형성합니다.
다음 다이어그램은 분산 가용성 그룹에 속하는 가용성 그룹 2개를 보여줍니다.
가용성 그룹 1은 기본 가용성 그룹이고 가용성 그룹 2는 보조 가용성 그룹입니다.
분산 가용성 그룹은 FCI의 경우와 마찬가지로 직사각형으로 표현되었습니다. 모든 가용성 그룹이 동일한 분산 가용성 그룹에 속하는 것을 설명하기 위한 것입니다. 분산 가용성 그룹은 가용성 그룹과 마찬가지로 클라우드 리소스가 아니며 따라서 노드 또는 다른 유형의 리소스에 구현되지 않습니다.
자세한 내용은 분산 가용성 그룹을 참조하세요.
로그 전달
트랜잭션 로그 전달은 RTO 및 RPO가 엄격하지 않은 경우(RTO가 낮거나 최근 RPO인 경우) SQL Server 가용성 기능입니다. 기본 데이터베이스와 보조 데이터베이스의 상태가 불일치하는 부분이 매우 많기 때문입니다. 트랜잭션 로그 파일에는 많은 상태 변경내용이 포함되기 때문에 상태 측면에서 불일치가 더 많습니다. 또한 트랜잭션 로그 파일이 비동기적으로 전송되고 전체적으로 보조 데이터베이스에 적용되어야 하므로 지연 시간 측면에서 불일치가 더 많아집니다.
트랜잭션 로그 파일은 기본 데이터베이스에 의해 생성되고 Cloud Storage 등으로 백업됩니다. 모든 트랜잭션 로그 파일은 모든 보조 데이터베이스에 복사되고 적용됩니다. 보조 데이터베이스는 기본 데이터베이스보다 지연되므로 웜 대기 모드 상태입니다. 손실 없는 완벽한 동기화를 설정하려면 트랜잭션 로그에 캡처되지 않은 객체와 변경내용을 보조 데이터베이스에 수동으로 적용해야 합니다.
SQL Server 에이전트는 트랜잭션 로그를 생성, 복사, 적용하는 전반적인 프로세스를 자동화합니다. 로그 전달은 각 데이터베이스에 개별적으로 설정해야 합니다. 가용성 그룹이 2개 이상의 데이터베이스를 관리하는 경우 여러 로그 전달 프로세스를 설정해야 합니다.
재해 복구 프로세스는 자동으로 지원되지 않으므로 장애가 발생할 경우 수동으로 재해 복구 프로세스를 시작해야 합니다. 또한 클라이언트 액세스는 기본 데이터베이스 및 보조 데이터베이스에서 리스너에 의해 추상화되지 않습니다. 장애 조치 시 클라이언트는 재해 복구 후 새 기본 데이터베이스에 연결하여 특정 데이터베이스의 역할을 보조 역할에서 새로운 기본 역할로 직접 변경할 수 있어야 합니다. SQL Server 인스턴스와 별개로 추상화를 구축할 수 있습니다. 예를 들어 유동 IP 주소 관련 권장사항에 설명된 대로 유동 IP 주소를 구축할 수 있습니다.
로그 전달은 부분적으로 수동 프로세스이므로 변경내용이 즉시 적용되는 가용성 그룹 및 분산 가용성 그룹과 달리 복사된 로그 파일이 보조 데이터베이스에 적용되는 작업을 의도적으로 지연할 수 있습니다. 가능한 사용 사례는 데이터 수정 오류가 해결될 때까지 기본 데이터베이스의 데이터 수정 오류가 보조 데이터베이스에 적용되지 않도록 방지하는 것입니다. 이 경우 아직 데이터 수정 오류가 적용되지 않은 보조 데이터베이스가 데이터 수정 오류가 해결될 때까지 기본 데이터베이스가 될 수 있습니다. 그 후에는 정상적인 처리를 재개할 수 있습니다.
분산 가용성 그룹의 경우와 마찬가지로, 기본 데이터베이스가 Linux에서 실행 중이고 보조 데이터베이스가 Linux 및 Windows에서 실행되는 경우 등에 로그 전달을 사용하여 크로스 플랫폼 솔루션을 제공할 수 있습니다.
다음 다이어그램은 로그 전달을 사용하는 크로스 플랫폼 배포를 보여줍니다. 이 토폴로지의 분산 가용성 그룹과 같은 리전에는 공통 구성이 없습니다.
가용성 그룹은 별도의 리전에 있으며, 하나는 Linux에서, 다른 하나는 Windows에서 실행됩니다.
SQL Server 로그 전달에 대한 자세한 내용은 로그 전달 정보(SQL Server)를 참조하세요.
SQL Server 가용성 기능 결합
SQL Server 가용성 기능을 다양한 조합으로 배포할 수 있습니다. 예를 들어 앞의 사용 사례에서는 로그 전달이 여러 운영체제에 설치된 여러 가용성 그룹과 함께 사용되었습니다.
SQL Server 가용성 기능의 가능한 조합 목록은 다음과 같습니다.
- 동일한 운영체제에 설치된 가용성 그룹 간에 로그 전달을 사용합니다.
- SQL Server 독립형 인스턴스만 사용하는 보조 가용성 그룹이 있는 FCI를 사용하는 기본 가용성 그룹을 만듭니다.
- 주변 리전 간 분산 가용성 그룹을 사용하고 여러 대륙에 위치한 리전에 로그 전달을 사용합니다.
이는 SQL Server 가용성 기능의 가능한 조합 중 일부일 뿐입니다.
SQL Server 가용성 기능이 제공하는 유연성 덕분에 명시된 요구사항에 따라 재해 복구 전략을 미세 조정할 수 있습니다.
SQL Server 복제
SQL Server 복제는 일반적으로 가용성 기능으로 간주되지 않지만 이 섹션에서는 재해 복구에 이 기능을 사용하는 방법을 간략하게 설명합니다.
복제 기능은 데이터베이스의 복제본 생성 및 유지보수를 지원합니다. 다양한 유형의 SQL Server 에이전트가 공동작업하여 변경내용을 캡처하고 캡처된 변경내용을 전송하며 해당 변경내용을 복제본에 적용합니다. 이 프로세스는 비동기적이며, 복제본은 일반적으로 데이터베이스를 복제하는 것보다 다양한 정도로 지연됩니다.
예를 들어 프로덕션 데이터베이스의 복제본이 있을 수 있습니다. 재해 복구 측면에서 프로덕션 데이터베이스는 기본 데이터베이스이고 복제본은 보조 데이터베이스입니다. SQL Server 복제 기능은 재해 복구 컨텍스트에서 데이터베이스가 다른 역할을 맡는다는 것을 모릅니다. 따라서 복제에는 재해 복구 프로세스를 지원하는 작업(예: 역할 변경)이 없습니다. 재해 복구 프로세스는 SQL Server 기능과 별도로 구현되어야 하며 클라이언트 액세스 추상화가 없기 때문에 구현 조직에 의해 실행되어야 합니다.
백업 파일 전달
백업 파일 전달은 또 다른 재해 복구 구현 전략입니다. 보조 데이터베이스를 설정하고 지속적으로 업데이트하는 표준 접근법은 기본 데이터베이스의 초기 전체 백업과 이후의 증분 백업을 수행하는 것입니다. 모든 증분 백업은 보조 데이터베이스에 올바른 순서로 적용됩니다. 이 접근법은 증분 백업 빈도 및 백업 파일 저장 위치(글로벌 위치 또는 위치 간에 실제로 복사됨)에 따라 다양하게 변형할 수 있습니다.
이 전략은 기본 데이터베이스에서 보조 데이터베이스로 상태 변경내용을 복제할 때 SQL Server 가용성 기능을 사용하지 않습니다. 로그 전달 시 사용되는 SQL Server 에이전트를 사용하지 않습니다.
자세한 내용은 예: 백업 및 복원 DR 전략 관련 섹션을 참조하세요.
복제 및 백업 파일 전달 방식을 이전 섹션에서 설명한 복제 방법과 비교하면 재해 복구 프로세스가 SQL Server 기능 집합 외부에서 별도로 구현된다는 공통점이 있습니다. 캡처된 변경내용을 전달하는 기능의 경우 SQL Server 에이전트는 이 기능을 자동으로 구현하므로 SQL Server 복제가 더 편리합니다.
데이터베이스 수명 주기와 앱 수명 주기 간의 상호작용에 대한 참고 사항
데이터베이스 장애 조치는 데이터베이스에 액세스하는 앱과 완전히 별개로 이루어지는 것이 아닙니다. 원칙적으로 두 가지 장애 시나리오가 있습니다.
첫째, 데이터베이스가 장애 조치되는 동안 앱이 계속 작동합니다. 기본 데이터베이스를 사용할 수 없게 된 시점부터 새 기본 데이터베이스가 작동하게 된 시점까지 앱이 데이터베이스에 전혀 액세스할 수 없습니다. 기존 연결이 실패하고 새 연결이 설정되지 않습니다. 이 시간 동안 앱은 최소한 데이터베이스 액세스가 필요한 기능에 대한 서비스를 클라이언트에 제공할 수 없습니다. 앱은 정상적인 처리를 재개할 수 있도록 새 기본 데이터베이스를 사용할 수 있는 시기를 인식해야 합니다.
앱은 데이터베이스 외부(예: 기본 메모리 캐시)에 상태가 저장될 수 있습니다. 앱은 캐시가 새 기본 데이터베이스와 일관성이 있는지(동기화되었는지) 확인합니다. 장애 조치 중에 트랜잭션이 전혀 손실되지 않으면 추가 유지보수 없이도 캐시가 일관성을 유지할 수 있습니다. 그러나 장애 조치 중 트랜잭션(데이터) 손실이 발생하면 캐시가 새 기본 데이터베이스와 일관성을 유지할 수 있습니다. 예를 들어 데이터베이스의 일부 데이터가 큐의 메시지 또는 파일 시스템에 있는 파일의 일부인 경우 공유 상태에도 이와 유사한 설명을 적용할 수 있습니다. 이러한 데이터 일관성 측면은 데이터베이스 재해 복구와 직접 관련이 없기 때문에 이 문서에서 다루지 않습니다.
둘째, 기본 데이터베이스를 사용할 수 없게 됨과 동시에 1개 이상의 앱을 사용할 수 없게 될 수 있습니다. 예를 들어 특정 리전이 오프라인 상태가 되면 해당 리전에서 실행 중인 애플리케이션 시스템은 동일한 리전의 기본 데이터베이스처럼 사용할 수 없게 됩니다. 이 경우 기본 데이터베이스 시스템뿐만 아니라 앱도 복구되어야 합니다. 데이터베이스 재해 복구 프로세스와 함께 유사한 앱 복구 프로세스를 시작해야 합니다. 복구된 앱은 새로운 기본 데이터베이스에 연결되고 재구성되어야 합니다(예: 유동 IP 주소). 앱 복구는 이 문서에서 다루지 않습니다.
백업 및 복구와 재해 복구의 관계
데이터베이스 백업은 데이터베이스 재해 복구와 독립적이며 양립할 수 없습니다. 데이터베이스 백업의 목적은 데이터베이스가 손실되거나 손상된 경우 또는 앱 오류나 버그로 인해 이전 상태를 복구해야 하는 경우 등에 일관된 상태를 복원할 수 있도록 하는 것입니다.
다음 섹션에서는 데이터베이스 재해 복구를 구현하는 하나의 메커니즘으로 백업을 사용하는 방법을 설명합니다. 이 시나리오에서는 보조 데이터베이스를 복원할 수 있도록 백업 파일을 보조 데이터베이스의 위치로 복사합니다. 그러나 백업 파일이 재해 복구의 기본 요건은 아닙니다. 가용성 기능에 대한 이전 설명에 옵션이 제시되어 있습니다.
고가용성 및 재해 복구
고가용성 및 재해 복구는 데이터베이스 가용성 솔루션을 제공한다는 공통점이 있습니다. 기본 데이터베이스를 사용할 수 없게 되면 보조 데이터베이스는 일관성 있고 사용 가능한 새로운 기본 데이터베이스가 됩니다.
고가용성과 재해 복구의 차이점은 단일 장애점 도메인입니다. 고가용성은 단일 영역이나 노드에서 장애가 발생한 경우 등에 한 리전 내의 서비스 중단을 해결합니다. 고가용성 솔루션은 동일한 리전의 다른 영역에 있는 새로운 기본 데이터베이스를 제공합니다. 또한 고가용성은 데이터베이스 장애뿐만 아니라 노드 장애도 해결합니다. SQL Server 인스턴스를 실행 중인 노드에 장애가 발생하면 새 SQL Server 인스턴스를 실행 중인 새 노드를 사용할 수 있게 됩니다(Always On 장애 조치 클러스터 인스턴스의 설명 참조).
재해 복구에는 2개 이상의 리전이 필요합니다. 전체 리전을 사용할 수 없게 된 경우를 위해서입니다. 재해 복구는 다른 리전에 있는 새로운 기본 데이터베이스를 제공할 수 있습니다.
SQL Server 고가용성 기능은 고가용성 및 재해 복구 솔루션을 동시에 지원합니다. 단일 가용성 그룹은 리전 내 영역뿐만 아니라 리전 자체에도 만들 수 있습니다. 가용성 그룹에는 고가용성을 처리하는 장애 조치 클러스터 인스턴스가 포함되어 있습니다.
SQL Server는 고가용성 및 영역 장애를 위해 한 리전 내에 가용성 그룹을 설정하고 리전 간 로그 전달과 이를 결합하여 재해 복구를 처리할 수 있습니다.
DR 배포 옵션
다음 섹션에서는 지금까지 논의된 것 외에 몇 가지 가능한 재해 복구 토폴로지를 보여줍니다. 이러한 토폴로지는 서로 다른 RPO 및 RTO 요구사항을 충족시킵니다. 이 목록에는 일부만 나와 있습니다.
리전 간 DR 및 HA
이 배포는 3개 영역으로 구성된 리전 내에 있는 FCI가 포함된 가용성 그룹의 변형입니다. 이 시나리오에서는 영역이 단일 장애점 도메인으로 간주됩니다.
앞서 설명한 배포와 비교하면, 각 FCI가 3개 노드로 구성되며, 각 노드가 다른 영역에서 실행됩니다. 이 설정의 이점은 1개 또는 2개 영역에 장애가 발생해도 재해 복구 프로세스가 필요 없다는 점입니다.
다음 다이어그램에서는 이 설정을 보여줍니다.
FCI는 모든 영역에 걸쳐 있으며, 각 FCI에서는 해당 데이터베이스에 액세스하는 SQL Server 인스턴스가 하나씩 실행됩니다. 각 FCI에는 실행되지 않는 SQL Server 인스턴스가 두 개 더 있습니다. 이러한 인스턴스는 영역에 장애가 발생할 경우 시작할 수 있습니다. 각 데이터베이스는 특정 FCI에 있는 모든 노드의 디스크를 사용하므로 데이터베이스가 여러 영역에 걸쳐 표시됩니다. 앱은 명확성을 위해 표시되지 않습니다.
리전 간 DR: 여러 리전에 걸친 가용성 그룹
이 시나리오에서 가용성 그룹은 Windows Server 장애 조치 클러스터에서 실행되며 두 리전에 걸쳐 있습니다. 리전은 단일 장애점 도메인으로 간주됩니다.
다음 다이어그램에서는 이 설정을 보여줍니다.
잠재적인 지연 시간 문제를 해결하기 위해 리전 R1의 복제본은 동기 트랜잭션 전파를 사용하도록 구성하고, 리전 R2의 복제본은 비동기 트랜잭션 전파를 사용하도록 구성할 수 있습니다.
리전 간 DR: 백업 파일 전송
이 시나리오에서는 백업 파일 전송을 사용합니다. 두 리전의 두 가용성 그룹이 연결됩니다. 각 가용성 그룹에는 동기적으로 트랜잭션을 수신하는 복제본이 있으므로 각 리전의 보조 복제본은 상시 대기로 구성됩니다.
다음 다이어그램에서는 이 설정을 보여줍니다.
그러나 두 가용성 그룹은 백업 파일 전송으로 연결됩니다. 가용성 그룹 AG1은 기본 가용성 그룹이고 가용성 그룹 AG2는 보조 가용성 그룹입니다. 보조 가용성 그룹에 백업 파일이 제공되면 백업 파일이 적용됩니다. 이 시나리오에 대한 자세한 설명은 예: 백업 및 복원 DR 전략 섹션을 참조하세요.
이중 위치 및 삼중 위치 토폴로지
데이터베이스가 2개만 있고, 기본 데이터베이스와 보조 데이터베이스가 각각 별도의 리전에 있는 경우 장애 조치 후 새 기본 데이터베이스가 실행되고 새 보조 데이터베이스가 준비되는 동안 보호되지 않는 기간이 있습니다. 보조 데이터베이스가 아직 실행되지 않은 상태에서 새 기본 데이터베이스를 사용할 수 없게 되면 새로운 기본 데이터베이스가 설정되었을 때만 복구되는 하드 다운타임이 발생합니다. 가용성 그룹에도 동일한 내용이 적용됩니다.
다른 보조 데이터베이스 또는 가용성 그룹을 실행하는 세 번째 위치가 있으면 장애 조치 후 보호되지 않은 기간이 발생하지 않습니다. 이 설정은 데이터 손실이 발생하지 않도록 2개의 보조 데이터베이스 중 1개가 보조 데이터베이스로 유지되고 새 기본 데이터베이스에 다시 할당되도록 해야 합니다. 마찬가지로, 가용성 그룹에도 동일한 내용이 적용됩니다.
DR 수명 주기
선택한 재해 복구 솔루션과 상관없이 적용되는 일반적인 수명 주기 단계가 있습니다.
실제 재해 복구 상황에서는 모든 관계자(앱 소유자, 운영 그룹, 데이터베이스 관리자)가 있어야 하며 재해 복구 관리에 적극적으로 참여해야 합니다. 관계자는 결정권자(진행자라고도 함)와 기준이 되는 결정 프로세스를 결정해야 합니다. 또한 관계자는 용어 및 커뮤니케이션 방법에 동의해야 합니다.
장애 조치 프로세스 시작 결정
장애 조치가 자동으로 시작되지 않으면 관계자가 장애 조치를 시작하기로 결정해야 합니다. 다양한 관계자는 장애 조치를 시작하기로 결정할 때 결정에 긴밀히 협조해야 합니다.
장애 조치 프로세스의 시작 여부는 여러 요인에 따라 달라지는데, 주로 기본 데이터베이스를 사용할 수 없게 된 근본 원인에 따라 달라집니다.
재해 복구 프로세스가 기본 데이터베이스의 가동 중지 상태를 해결하는 데 예상보다 오래 걸리면 장애 조치가 유해할 수 있습니다. 먼저 기본 데이터베이스를 복원하는 것이 가능한 옵션인지 평가해야 합니다.
재해 복구 전략을 테스트하는 것이 더 좋고, 더 빠르게 구현될수록 결정 단계에서 불확실성이 줄어들기 때문에 장애 조치 프로세스를 시작하기가 더 쉬워집니다.
장애 조치 프로세스 실행
장애 조치 프로세스는 정기적으로 테스트하는 것이 이상적이므로 다양한 관계자에게 잘 알려져 있습니다.
결정권자는 수행되는 모든 단계와 예상치 못한 모든 문제를 인지하고 있어야 합니다. 결정권자는 장애 조치 프로세스를 주도하며 관계자는 결정권자를 지원합니다.
사후 분석 및 장애 조치 프로세스 개선을 위해 활동 지속 시간, 발생한 문제, 장애 조치 프로세스 단계의 혼동 등의 통계 자료를 보관해야 합니다.
보호 미지원
보조 데이터베이스가 하나만 있는 경우 새 기본 데이터베이스가 사용 가능해지고 작동하는 시점부터 새 보조 데이터베이스가 설정될 때까지 DR 보호가 지원되지 않습니다. 이 시간 동안 데이터베이스의 가동이 중지되면 다른 데이터베이스로의 장애 복구가 불가능하기 때문에 하드 다운타임이 발생할 수 있습니다. 이러한 상황이 발생하면 다른 기본 데이터베이스를 설정해야 하며 RPA는 사용 가능한 백업을 기반으로 재구성할 수 있는 마지막 지점입니다.
재해 복구 전략이 항상 보호를 지원하도록 설정되지 않은 경우, 모든 관계자는 이러한 보호 미지원 기간 동안 설정 또는 환경 구성 변경 시 추가 예방 조치를 취해야 한다는 사실을 알고 있어야 합니다.
새 보조 데이터베이스가 가동되어 실행될 때까지 새 기본 데이터베이스에 대한 앱 액세스가 지연되는 경우 보호되지 않는 시간을 피할 수 있습니다. 기본 데이터베이스의 변경내용이 적용되는 즉시 앱에서 기본 데이터베이스에 액세스할 수 있습니다. 이 접근법은 앱이 DR로 보호받지 못하는 시간을 방지하지만 재해 복구 프로세스 완료를 지연시킵니다.
분할 브레인 상황 방지
DML 작업을 실행하여 앱이 기본 데이터베이스와 보조 데이터베이스에 동시에 액세스할 수 없도록 하는 것이 중요합니다. 이 상황에서는 기본 데이터베이스와 보조 데이터베이스에 있는 동일한 데이터 항목의 데이터 값이 불일치할 경우 데이터 불일치가 발생합니다(분할 브레인). 이 아키텍처는 기본 데이터베이스를 사용할 수 없게 되었는데 기본 데이터베이스가 계속 실행되고 쓰기 작업을 수신할 수 있는 경우에 특히 중요합니다. 간헐적인 네트워크 파티션 나누기로 인해 사용 중지가 발생하는 경우 파티션 나누기가 언제든지 중지될 수 있으며 앱이 다시 액세스할 수 있습니다. 이때 장애 조치 프로세스가 발생하면 이전 기본 데이터베이스의 변경내용이 손실되거나 일부 앱이 새 기본 데이터베이스에서 작동하기 시작하고 다른 일부 앱은 이전 기본 데이터베이스에 계속 액세스할 수 있습니다.
장애 조치 프로세스 중에는 모든 데이터베이스에 대한 모든 앱 액세스가 차단되므로 어떤 데이터베이스에서도 상태 변경이 발생하지 않습니다. 장애 조치 후에 쓰기 작업에 사용할 수 있는 데이터베이스는 새 기본 데이터베이스 하나뿐입니다.
완료 선언
장애 조치 프로세스가 완료되면 결정권자는 모든 관계자에게 프로세스가 완료되었음을 명시적으로 알려야 합니다. 완료 후에 나타나는 모든 문제는 별도의 이슈로 처리해야 하며, 이는 더 이상 장애 조치 프로세스의 일부가 아니라 일반 처리 과정의 일부입니다. 문제는 장애 조치 프로세스의 문제 또는 독립적인 문제로 인해 발생한 것일 수 있습니다. 그러나 장애 조치 프로세스가 완료된 후 문제를 해결하는 방법은 장애 조치 프로세스 실행 중에 문제를 해결하는 방법과 다를 수 있습니다.
사후 분석 및 보고서
나중에 참조하거나 장애 조치 프로세스를 개선하기 위해 사후 분석을 즉시 수행하여 중요한 측면, 결과, 작업 항목을 기록합니다.
재해 복구 이벤트, 근본 원인, 수행된 모든 작업이 요약된 보고서를 작성합니다. 규제 요구사항을 구현하는 경우 이 보고서가 필수적일 수 있습니다.
DR 테스트 및 검증
재해 복구는 일반적인 일상 업무의 일부가 아니므로 DR 솔루션을 정기적으로 테스트하여 실제로 필요할 때 적절히 작동하도록 해야 합니다.
테스트 빈도는 작동 요구사항에 따라 다르며 데이터베이스, 앱, 기업에 따라 다릅니다. 또한 네트워크 구성 변경 및 인프라 구성요소 업데이트와 같은 환경 변경내용이 발생하면 선택된 재해 복구 솔루션이 의존하는 시스템에 변경내용이 적용되는지 확인하는 재해 복구 테스트가 실행되어야 합니다. 변경내용으로 인해 재해 복구 솔루션이 실패하거나 재해 복구 프로세스를 조정해야 할 수 있습니다.
전환 프로세스를 시작하여 수동으로 테스트하거나 Chaos engineering에 설명된 대로 카오스 엔지니어링 방식을 사용하여 자동으로 테스트할 수 있습니다. 수동 테스트 결과 현저한 다운타임이 예상되는 경우 비즈니스 영향을 최소화할 수 있습니다.
테스트에서 중요한 부분은 잘 정의된 통계를 수집하는 것입니다. 고려해야 할 몇 가지 중요한 통계는 다음과 같습니다.
- 실제 복구 시간: 실제 복구 시간을 측정하고 RTO와 비교합니다.
- 실제 복구 지점: 실제 복구 지점을 관찰하고 RPO와 비교합니다.
- 장애 감지 소요 시간: DBA 또는 운영팀이 장애 조치의 필요성을 인지하는 데 걸린 시간입니다.
- 복구 시작 소요 시간: 장애가 감지된 후 장애 조치 프로세스를 시작하는 데 걸린 시간입니다.
- 신뢰성: 장애 조치 프로세스를 얼마나 엄수했나요? 아니면 장애 조치 프로세스를 위반할 수밖에 없었나요? 예기치 못한 문제가 발생하여 조사하느라 복구 전략을 변경해야 했나요?
수집된 통계에 따라 RPO 및 RTO 기대치에 더 잘 부합되도록 장애 조치 프로세스를 조정하거나 개선해야 할 수 있습니다.
예: 백업 및 복원 DR 전략
다음 섹션에서는 백업 및 재해 복구 전략의 예를 대략적으로 설명합니다. 이 시나리오에서는 DR 백업 및 복원 전략을 지정하는 데 필요한 노력을 보여주고, 보다 자동화된 환경에서는 보이지 않는 측면을 논의하기 위해 SQL Server 가용성 기능 사용을 최소화합니다.
사용 사례
기본 Always On 가용성 그룹은 리전 R1에 위치하며 작동 가능합니다. 보조 Always On 가용성 그룹은 리전 간 추가 보호를 위해 리전 R2에 추가되며 장애 조치 또는 전환 대상으로 사용할 수 있습니다.
전략
재해 복구 전략은 데이터베이스 백업을 기반으로 합니다. 초기 전체 백업이 수행된 다음 후속 차등 백업이 수행됩니다. 백업이 생성되면 보조 Always On 가용성 그룹에 적용됩니다. 모든 백업은 Cloud Storage 버킷에 저장됩니다.
이 예에서는 장애 조치 완료 후 R1의 새로운 보조 Always On 가용성 그룹이 작동할 때까지 R2의 새로운 기본 Always On 가용성 그룹이 제한된 시간 동안 활성화되고 보호되지 않아도 됩니다.
각 리전의 상시 설정 가용성 그룹이 프로덕션 Always On 가용성 그룹의 역할을 하도록 동등한 자격을 부여받기 때문에 대체 작업을 수행할 필요가 없습니다.
RTO 및 RPO
이 예에서 RPO는 최대 60분으로 정의되므로 60분마다 차등 백업이 수행됩니다.
RTO는 일정 시간으로 명시적으로 설정되지는 않지만 가능한 한 최소화해야 합니다. 즉각적인 적용이 가장 좋습니다. 보조 가용성 그룹은 상시 대기로 설정되어야 합니다. 상시 대기의 경우 모든 백업이 즉시 적용되므로 백업 적용 시 장애 조치가 지연되지 않습니다.
대략적인 DR 전략
다음 섹션에서는 DR 전략을 대략적으로 설명합니다. 필수 단계를 중점적으로 설명하기 위해 간결하게 작성되었습니다.
초기 설정
- 리전 R2에서 보조 Always On 가용성 그룹을 만듭니다.
- 보조 가용성 그룹에 대한 앱 액세스를 차단하여 분할 브레인 상황이 의도치 않게 발생하지 않도록 합니다.
- R1에 있는 Always On 가용성 그룹의 초기 전체 백업과 R1에 있는 Always On 가용성 그룹의 후속 시간별 차등 백업을 포함하는 Cloud Storage에 백업 파일 버킷 B1을 만듭니다. 보조 가용성 그룹에 백업을 적용하는 프로세스가 올바른 순서를 추론할 수 있도록 올바른 차등 백업 순서를 설정해야 합니다. 한 가지 접근법은 다양한 파일 이름의 일부로 날짜와 시간에 기반을 둔 정확한 시간 순서를 설정하는 명명 규칙입니다.
전략 실행
- 리전 R2의 보조 Always On 가용성 그룹에 전체 백업을 적용합니다.
- 차등 백업을 사용할 수 있게 되면 R2의 보조 Always On 가용성 그룹에 즉시 적용합니다. RTO를 처리하려면 즉각적인 적용이 필요합니다.
- 초기 전체 백업 및 모든 증분 백업이 적용되면 보조 Always On 가용성 그룹이 준비됩니다.
- 기본 가용성 그룹에서 보조 가용성 그룹으로의 전환을 수행하여 DR 전략을 테스트합니다. 테스트 중에 하나 이상의 증분 백업을 사용할 수 있어야 합니다.
장애 조치 또는 전환 사례
R2에서 필수 단계는 다음과 같습니다.
- R2의 보조 Always On 가용성 그룹에 최신 차등 백업이 적용되었는지 확인합니다.
- R2를 새로운 기본 Always On 가용성 그룹으로 지정합니다.
- 새 버킷 B2를 만들고. 전체 백업을 기준으로 삼고, 앱이 액세스할 수 있도록 새로운 기본 가용성 그룹을 열어둡니다.
- 차등 백업을 시작합니다.
R1에서 필수 단계는 다음과 같습니다.
- 버킷 B1은 더 이상 필요하지 않으므로 삭제합니다.
- R1의 Always On 가용성 그룹을 새로운 보조 가용성 그룹으로 다시 사용할 수 있게 되면 앱 액세스를 차단하고 데이터베이스에서 모든 데이터를 삭제하거나 데이터베이스를 초기 상태(빈 상태)로 재설정합니다(새로 만들지 않아도 될 경우).
- R2의 새 기본 Always On 가용성 그룹에서 전체 백업을 적용하고 차등 백업이 생성되어 버킷 B2에 저장되는 즉시 계속 적용합니다.
가능한 개선책
DR 전략에 대한 한 가지 가능한 개선책은 장애 조치 또는 전환 후 전체 백업을 수행하지 않으면서 새로운 보조 가용성 그룹을 신속하게 설정하는 것입니다. 단일 전체 백업 및 후속 차등 백업 대신 매주 전체 백업을 수행하고 해당 주에 대한 전체 백업과 그 이후의 모든 차등 백업을 포함하는 주간 버킷을 만듭니다. 새로운 기본 가용성 그룹은 장애 조치 후에만(전체 백업 후에는 안 됨) 차등 백업을 만들고 이를 버킷에 추가해야 합니다. 새로운 보조 가용성 그룹은 현재 주 버킷의 모든 백업을 적용하기만 합니다. 이 주간 접근법을 사용하는 경우 오래된 백업을 삭제하려면 정리 또는 삭제 전략을 구현해야 합니다.
또 다른 개선책은 새로운 보조 가용성 그룹이 이전에 기본 가용성 그룹이었다는 사실에서 착안한 것입니다. SQL Server 데이터베이스를 지정 시간으로 복원(전체 복구 모델)에 설명된 대로 데이터베이스가 존재하고 다시 사용할 수 있게 된 후 작동할 경우 마지막 차등 백업으로의 point in time recovery는 마지막 전체 백업으로 데이터베이스를 완전히 복원할 필요가 없습니다. 이 시나리오는 새로운 기본 가용성 그룹이 보호되지 않는 시간과 노력을 줄여줍니다.
프로덕션 권장사항
이 솔루션은 Always On 가용성 그룹의 SQL Server 인스턴스가 독립형인지, 아니면 FCI 인스턴스인지를 지정하지 않습니다. 사용할 인스턴스 유형은 구현 전에 결정해야 합니다.
장애 조치 후 새로운 보조 Always On 가용성 그룹이 작동할 때까지 DR이 보호되지 않는 시간이 있습니다. 세 번째 리전에 세 번째 Always On 가용성 그룹을 설정해야 합니다.
또한 모니터링을 구현하여 장애나 오류가 감지되는지 확인해야 합니다. 모니터링은 이 문서에서 다루지 않지만 효과적인 재해 복구 솔루션에 필수적입니다.
다음 단계
- SQL Server AlwaysOn 가용성 그룹 구성
- Compute Engine에 다중 서브넷 SQL Server 2016 Always On 가용성 그룹 배포
- SQL Server 장애 조치 클러스터 인스턴스 구성
- Windows Server 장애 조치 클러스터링 실행
- .NET 앱에 Cloud Logging, Cloud Monitoring, Error Reporting을 사용 설정하는 방법
- Cloud Monitoring 에이전트 설치
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴보세요. Cloud 아키텍처 센터를 살펴보세요.