장애 조치(failover) 그룹 개요 및 모범 사례 - Azure SQL Managed Instance

적용 대상: Azure SQL Managed Instance

• Azure SQL Database
• Azure SQL Managed Instance

장애 조치(failover) 그룹 기능을 사용하면 관리형 인스턴스의 모든 사용자 데이터베이스를 다른 Azure 지역으로 복제 및 장애 조치(failover)를 관리할 수 있습니다. 이 문서에서는 Azure SQL Managed Instance에서 사용하기 위한 모범 사례 및 권장 사항과 함께, 장애 조치(failover) 그룹 기능의 개요를 제공합니다.

이 기능을 사용하려면 먼저 Azure SQL Managed Instance에 대한 장애 조치(failover) 그룹 구성을 검토합니다.

개요

장애 조치(failover) 그룹 기능을 사용하면 관리형 인스턴스의 사용자 데이터베이스를 다른 Azure 지역의 관리형 인스턴스로 복제 및 장애 조치(failover)하는 작업을 관리할 수 있습니다. 장애 조치(failover) 그룹은 지역 복제된 데이터베이스의 배포 및 관리를 대규모로 간소화하도록 설계되었습니다.

자세한 내용은 Azure SQL Managed Instance 고가용성을 참조하세요. 지역 장애 조치(failover) RPO 및 RTO에 대한 자세한 내용은 비즈니스 연속성 개요를 참조하세요.

엔드포인트 리디렉션

장애 조치(failover) 그룹은 지역 장애 조치(failover) 중에 변경되지 않는 읽기-쓰기 및 읽기 전용 수신기 엔드포인트를 제공합니다. 연결이 자동으로 현재 기본으로 라우팅되기 때문에 지리적 장애 조치(failover) 후에 애플리케이션에 대한 연결 문자열을 변경할 필요가 없습니다. 지역 장애 조치(failover)는 그룹의 모든 보조 데이터베이스를 주 역할로 전환합니다. 지역 장애 조치(failover)가 완료되면 엔드포인트를 새 지역으로 리디렉션하도록 DNS 레코드가 자동으로 업데이트됩니다.

읽기 전용 워크로드 오프로드

주 데이터베이스에 대한 트래픽을 줄이기 위해 장애 조치(failover) 그룹의 보조 데이터베이스를 사용하여 읽기 전용 워크로드를 오프로드할 수도 있습니다. 읽기 전용 수신기를 사용하여 읽기 전용 트래픽을 읽기 가능한 보조 데이터베이스로 보냅니다.

애플리케이션 복구

완전한 비즈니스 연속성을 달성하기 위해 지역 데이터베이스 중복성을 추가하는 것은 솔루션의 일부일 뿐입니다. 치명적인 오류 후 애플리케이션(서비스) 엔드투엔드 복구에는 서비스 및 모든 종속성 서비스를 구성하는 모든 구성 요소의 복구가 필요합니다. 이러한 구성 요소의 예에는 클라이언트 소프트웨어(예: 사용자 지정 JavaScript를 사용한 브라우저), 웹 프런트 엔드, 스토리지 및 DNS가 포함됩니다. 모든 구성 요소는 동일한 오류에 탄력적이며 애플리케이션의 RTO(복구 시간 목표) 내에서 사용할 수 있는 것이 중요합니다. 따라서 모든 종속성 서비스를 확인하고 제고하는 보장 사항 및 기능을 이해해야 합니다. 그런 다음 의존하는 서비스 장애 조치 중 서비스 기능을 확인하도록 적절한 단계를 수행해야 합니다.

장애 조치(failover) 정책

장애 조치(failover) 그룹은 다음과 같은 두 개의 장애 조치(failover) 정책을 지원합니다.

• 고객 관리(권장) - 고객이 장애 조치(failover) 그룹의 하나 이상의 데이터베이스에 영향을 미치는 예기치 않은 중단을 발견하면 그룹의 장애 조치(failover)를 수행할 수 있습니다. PowerShell, Azure CLI 또는 Rest API와 같은 명령줄 도구를 사용하는 경우 고객 관리 장애 조치(failover) 정책 값은 manual입니다.
• Microsoft 관리 - 주 지역에 영향을 주는 광범위한 중단이 발생하는 경우 Microsoft는 장애 조치(failover) 정책을 Microsoft 관리로 구성된 영향을 받은 모든 장애 조치(failover) 그룹의 장애 조치(failover)를 시작합니다. Microsoft 관리 장애 조치(failover)는 개별 장애 조치(failover) 그룹 또는 하위 지역의 장애 조치(failover) 그룹의 하위 집합에 대해서는 시작되지 않습니다. PowerShell, Azure CLI 또는 Rest API와 같은 명령줄 도구를 사용하는 경우, Microsoft 관리 장애 조치(failover) 정책 값은 automatic입니다.

각 장애 조치(failover) 정책에는 다음 테이블에서 요약한 대로 장애 조치(failover) 범위 및 데이터 손실에 대한 고유한 사용 사례 집합과 해당 기대 사항이 있습니다.

장애 조치(failover) 정책	장애 조치(failover) 범위	사용 사례	잠재적 데이터 손실
고객 관리형 (권장)	장애 조치(failover) 그룹	장애 조치(failover) 그룹에서 하나 이상의 데이터베이스가 가동 중단의 영향을 받아 사용할 수 없게 됩니다. 장애 조치(failover)를 선택할 수 있습니다.	예
Microsoft 관리	지역의 모든 장애 조치(failover) 그룹	데이터 센터, 가용성 영역 또는 지역의 광범위한 가동 중단으로 인해 데이터베이스를 사용할 수 없게 되며 Microsoft Azure SQL 서비스 팀은 강제 장애 조치(failover)를 트리거하기로 결정합니다. 애플리케이션은 1시간 이상의 RTO(가동 중지 시간)를 허용하고 재해 복구 책임을 Microsoft에 위임하려는 경우에만 이 옵션을 사용합니다.	예

고객 관리형

드물지만 기본 제공 가용성 또는 고가용성만으로 가동 중단을 완화하지 못하고, 데이터베이스를 사용하는 애플리케이션의 SLA(서비스 수준 약정)에서 허용하지 않는 시간 동안 장애 조치(failover) 그룹의 데이터베이스를 사용하지 못하는 경우가 있습니다. 일부 데이터베이스에만 영향을 미치는 지역화된 문제로 인해 데이터베이스를 사용할 수 없거나 데이터 센터, 가용성 영역 또는 지역 수준에 존재할 수 있습니다. 이러한 경우에서 비즈니스 연속성을 복원하기 위해 강제 장애 조치(failover)를 시작할 수 있습니다.

장애 조치(failover) 정책을 고객 관리형으로 설정하는 것이 좋습니다. 장애 조치(failover)를 시작하고 비즈니스 연속성을 복원할 시기를 제어할 수 있기 때문입니다. 장애 조치(failover) 그룹에 있는 하나 이상의 데이터베이스에 영향을 주는 예기치 않은 가동 중단이 발견되면 장애 조치(failover)를 시작할 수 있습니다.

Microsoft 관리

Microsoft 관리 장애 조치(failover) 정책을 통해 재해 복구 책임이 Azure SQL 서비스로 위임됩니다. Azure SQL 서비스가 강제 장애 조치(failover)를 시작하려면 다음 조건을 충족해야 합니다.

• 자연 재해 이벤트, 구성 변경, 소프트웨어 버그 또는 하드웨어 구성 요소 장애 및 해당 지역의 많은 데이터베이스로 인한 데이터 센터, 가용성 영역 또는 지역 수준 가동 중단이 영향을 받습니다.
• 유예 기간이 만료되었습니다. 가동 중단 규모와 완화 정도를 확인하려면 사람이 작업해야 하므로 유예 기간을 1시간 미만으로 설정할 수 없습니다.

이러한 조건이 충족되면 Azure SQL 서비스는 장애 조치(failover) 정책이 Microsoft 관리로 설정된 지역의 모든 장애 조치(failover) 그룹에 대해 강제 장애 조치(failover)를 시작합니다.

Important

고객 관리 장애 조치(failover) 정책을 사용하여 재해 복구 계획을 테스트하고 구현하세요. 극단적인 상황에서만 Microsoft에서 실행할 수 있는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요. Microsoft 관리 장애 조치(failover) 정책이 Microsoft 관리로 설정된 지역의 모든 장애 조치(failover) 그룹에 대해 Microsoft 관리 장애 조치(failover)가 시작됩니다. 개별 장애 조치(failover) 그룹에 대해 시작할 수 없습니다. 장애 조치(failover) 그룹을 선택적으로 장애 조치(failover)하는 기능이 필요한 경우 고객 관리 장애 조치(failover) 정책을 사용합니다.

다음 경우에만 Microsoft 관리로 장애 조치(failover) 정책을 설정합니다.

• 재해 복구 책임을 Azure SQL 서비스에 위임하려고 합니다.
• 애플리케이션에서 데이터베이스를 1시간 이상 사용할 수 없는 상황을 허용합니다.
• 강제 장애 조치(failover)의 실제 시간이 크게 달라질 수 있으므로 유예 기간이 만료된 후 일정 시간 동안 강제 장애 조치(failover)를 트리거할 수 있습니다.
• 장애 조치(failover) 그룹에 있는 모든 데이터베이스는 영역 중복 구성 또는 가용성 상태와 관계없이 장애 조치(failover)가 허용됩니다. 영역 중복을 위해 구성된 데이터베이스는 영역 오류에 대한 복원력을 지원하고 가동 중단의 영향을 받지 않을 수 있지만, Microsoft 관리 장애 조치(failover) 정책을 통해 장애 조치(failover) 그룹에 속한 경우에도 장애 조치(failover)됩니다.
• 애플리케이션에서 사용하는 다른 Azure 서비스 또는 구성 요소에 대한 애플리케이션의 종속성을 고려하지 않고 장애 조치(failover) 그룹의 데이터베이스를 강제 장애 조치(failover)할 수 있으며, 이로 인해 애플리케이션의 성능이 저하되거나 사용 불가능하게 될 수 있습니다.
• 강제 장애 조치(failover)의 정확한 시간을 제어할 수 없고 보조 데이터베이스의 동기화 상태를 무시하므로 알 수 없는 양의 데이터 손실이 발생할 수 있습니다.
• 모든 지역 복제 관계 및 장애 조치(failover) 그룹의 모든 주 및 보조 데이터베이스에서 서비스 계층, 컴퓨팅 계층(프로비전 또는 서버리스) 및 컴퓨팅 크기(DTU 또는 vCore)는 동일합니다. 모든 데이터베이스의 SLO(서비스 수준 목표)가 일치하지 않는 경우 장애 조치(failover) 정책은 결국 Azure SQL 서비스에 의해 Microsoft 관리에서 고객 관리로 업데이트됩니다.

Microsoft에서 장애 조치(failover)를 트리거하면 Azure SQL 장애 조치(failover) 그룹 장애 조치(failover) 작업 이름 항목이 Azure Monitor 활동 로그에 추가됩니다. 이 항목은 리소스 아래에 장애 조치(failover) 그룹 이름을 포함하고 이벤트 시작 위치에서는 Microsoft에서 장애 조치(failover)를 시작했음을 나타내기 위해 단일 하이픈(-)이 표시됩니다. 이 정보는 Azure Portal에서 새 주 서버 또는 인스턴스의 활동 로그 페이지에서도 찾을 수 있습니다.

용어 및 기능

• FOG(장애 조치 그룹)

  장애 조치(failover) 그룹을 사용하면 주 지역 중단으로 인해 기본 관리되는 인스턴스를 사용할 수 없게 될 경우 관리되는 인스턴스 내의 모든 사용자 데이터베이스를 다른 Azure 지역으로 하나의 단위로서 장애 조치(failover)할 수 있습니다. SQL Managed Instance의 장애 조치(failover) 그룹에는 인스턴스 내의 모든 사용자 데이터베이스가 포함되므로 한 인스턴스에 하나의 장애 조치(failover) 그룹만 구성할 수 있습니다.

  중요

  장애 조치 그룹의 이름은 .database.windows.net 도메인에서 전역적으로 고유해야 합니다.

• 주

  장애 조치(failover) 그룹의 주 데이터베이스를 호스트하는 관리되는 인스턴스입니다.

• 보조

  장애 조치(failover) 그룹의 보조 데이터베이스를 호스트하는 관리되는 인스턴스입니다. 보조는 주 데이터베이스와 동일한 Azure 지역에 있을 수 없습니다.

  Important

  메모리 내 OLTP 개체가 데이터베이스에 포함된 경우 메모리 내 OLTP 개체는 항상 메모리에서 상주하기 때문에 주 및 보조 지역 복제본 인스턴스에서 서비스 계층이 일치해야 합니다. 지역 복제 인스턴스의 서비스 계층이 낮아 메모리 부족 문제가 발생할 수 있습니다. 이 경우 보조 복제본에서 데이터베이스를 복구하지 못하여 보조 데이터베이스를 지역 보조 데이터베이스의 메모리 내 OLTP 개체와 함께 사용할 수 없습니다. 이로 인해 장애 조치(failover)도 실패할 수 있습니다. 이를 방지하려면 지역 보조 인스턴스의 서비스 계층이 주 인스턴스의 서비스 계층과 일치해야 합니다. 서비스 계층 업그레이드는 데이터 크기 작업일 수 있으며 완료하는 데 시간이 걸릴 수 있습니다.

• 장애 조치(failover)(데이터 손실 없음)

  장애 조치(failover)는 보조 역할이 주 역할로 전환되기 전에 주 데이터베이스와 보조 데이터베이스 간에 전체 데이터 동기화를 수행합니다. 이렇게 하면 데이터 손실이 발생하지 않습니다. 장애 조치(failover)는 주 위치에 액세스할 수 있는 경우에만 가능합니다. 장애 조치(failover)는 다음과 같은 시나리오에서 사용합니다.

  • 데이터 손실이 허용되지 않을 때 프로덕션에서 DR(재해 복구) 연습 수행
  • 워크로드를 다른 지역으로 재배치
  • 가동 중단이 완화된 후 워크로드를 주 지역으로 반환(장애 복구(failback))

• 강제 장애 조치(failover)(데이터 손실 가능성)

  강제 장애 조치(failover)는 주 역할에서 최근 변경 내용이 전파될 때까지 기다리지 않고 즉시 보조 역할을 주 역할로 전환합니다. 이 작업으로 인해 데이터가 손실될 수 있습니다. 강제 장애 조치(failover)는 주 역할에 액세스할 수 없을 때 가동 중단 중에 복구 방법으로 사용됩니다. 중단이 완화되면 이전 주 데이터베이스는 자동으로 다시 연결되고 새로운 보조 데이터베이스가 됩니다. 장애 조치(failover)를 실행하여 장애 복구하고, 복제본을 원래 주 역할 및 보조 역할로 되돌릴 수 있습니다.

• 데이터 손실이 있는 유예 기간

  데이터가 비동기 복제를 사용하여 보조 위치에 복제되므로 Microsoft 관리 장애 조치(failover) 정책을 사용하는 그룹의 강제 장애 조치(failover) 시 데이터가 손실될 수 있습니다. 애플리케이션의 데이터 손실 허용 오차를 반영하도록 장애 조치(failover) 정책을 사용자 지정할 수 있습니다. GracePeriodWithDataLossHours를 구성하면 데이터 손실을 초래할 수 있는 강제 장애 조치(failover)가 시작될 때까지 Azure SQL 서비스가 대기하는 시간을 제어할 수 있습니다.

• DNS 영역

  새 SQL Managed Instance를 만들 때 자동으로 생성되는 고유 ID입니다. 이 인스턴스의 다중 도메인(SAN) 인증서는 같은 DNS 영역의 인스턴스에 대한 클라이언트 연결을 인증하기 위해 프로비저닝됩니다. 같은 장애 조치 그룹의 관리되는 두 인스턴스는 DNS 영역을 공유해야 합니다.

• 장애 조치 그룹 읽기-쓰기 수신기

  현재 주 지역을 가리키는 DNS CNAME 레코드입니다. 장애 조치(failover) 그룹을 만들 때 자동으로 생성되며 장애 조치(failover) 후에 주 지역이 변경될 때 읽기-쓰기 워크로드가 주 데이터베이스에 투명하게 다시 연결할 수 있습니다. SQL Managed Instance에 장애 조치 그룹이 생성되면 리스너 URL의 DNS CNAME 레코드는 <fog-name>.<zone_id>.database.windows.net으로 구성됩니다.

• 장애 조치 그룹 읽기 전용 수신기

  현재 보조 지역을 가리키는 DNS CNAME 레코드입니다. 장애 조치(failover) 그룹을 만들 때 자동으로 생성되며 장애 조치(failover) 후에 보조 지역이 변경될 때 읽기 전용 SQL 워크로드가 보조 데이터베이스에 투명하게 연결할 수 있습니다. SQL Managed Instance에 장애 조치 그룹이 생성되면 리스너 URL의 DNS CNAME 레코드는 <fog-name>.secondary.<zone_id>.database.windows.net으로 구성됩니다. 기본적으로 읽기 전용 수신기의 장애 조치(failover)는 보조 위치가 오프라인 상태일 때 주 위치의 성능에 영향을 주지 않도록 하기 위해 사용하지 않도록 설정됩니다. 그러나 보조 서버가 복구될 때까지 읽기 전용 세션이 연결할 수 없음을 의미합니다. 읽기 전용 세션의 가동 중지 시간을 허용할 수 없고 주 데이터베이스의 성능이 잠재적으로 저하되더라도 읽기 전용 및 읽기/쓰기 트래픽 둘 다에 주 데이터베이스를 사용할 수 있으면, AllowReadOnlyFailoverToPrimary 속성을 구성하여 읽기 전용 수신기에 장애 조치를 사용하도록 설정할 수 있습니다. 이 경우, 보조 데이터베이스를 사용할 수 없으면 읽기 전용 트래픽이 주 데이터베이스로 자동으로 리디렉션됩니다.

  참고 항목

  AllowReadOnlyFailoverToPrimary 속성은 Microsoft 관리 장애 조치(failover) 정책이 사용되고 강제 장애 조치(failover)가 트리거된 경우에만 적용됩니다. 이 경우 속성이 True로 설정되면 새로운 주 데이터베이스에서 읽기/쓰기 및 읽기 전용 세션을 모두 제공합니다.

장애 조치(failover) 그룹 아키텍처

장애 조치(failover) 그룹은 주 인스턴스에서 구성되어야 하며 다른 Azure 지역의 보조 인스턴스에 연결됩니다. 인스턴스의 모든 사용자 데이터베이스가 보조 인스턴스에 복제됩니다. master 및 msdb와 같은 시스템 데이터베이스는 복제되지 않습니다.

다음 다이어그램은 관리형 인스턴스와 장애 조치(failover) 그룹을 사용하는 지역 중복 클라우드 애플리케이션의 일반적인 구성을 보여줍니다.

애플리케이션에서 SQL Managed Instance를 데이터 계층으로 사용하는 경우 비즈니스 연속성을 위해 설계할 때 이 문서에 설명된 일반 지침 및 모범 사례를 따릅니다.

지역 보조 인스턴스 만들기

장애 조치 다음에 주 SQL Managed Instance에 대한 무중단 연결을 보장하려면 주 인스턴스와 보조 인스턴스가 모두 같은 DNS 영역에 있어야 합니다. 같은 다중 도메인(SAN) 인증서를 사용하여 장애 조치(failover) 그룹의 두 인스턴스 중 하나에 대한 클라이언트 연결을 인증할 수 있습니다. 애플리케이션이 프로덕션 배포에 사용할 준비가 되면 다른 지역에 보조 SQL Managed Instance를 만들고 주 SQL Managed Instance와 DNS 영역을 공유하는지 확인합니다. 만드는 중에 선택적 매개 변수를 지정하여 이 작업을 수행할 수 있습니다. PowerShell 또는 REST API를 사용하는 경우 선택적 매개 변수의 이름은 DNSZonePartner입니다. Azure Portal에서 해당하는 선택적 필드의 이름은 기본 Managed Instance입니다.

중요

서브넷에 만든 첫 번째 관리되는 인스턴스에 따라 같은 서브넷에 있는 모든 후속 인스턴스의 DNS 영역이 결정됩니다. 즉, 같은 서브넷의 두 인스턴스는 서로 다른 DNS 영역에 속할 수 없습니다.

주 인스턴스와 같은 DNS 영역에서 보조 SQL Managed Instance를 생성하는 방법에 대한 자세한 내용은 Azure SQL Managed Instance에 대한 장애 조치(failover) 그룹 구성을 참조하세요.

쌍을 이루는 지역 사용

성능 상의 이유로 두 관리형 인스턴스를 쌍을 이루는 지역에 배포합니다. 쌍을 이루는 지역의 SQL Managed Instance 장애 조치(failover) 그룹은 페어링되지 않은 지역에 비해 성능이 향상됩니다.

Azure SQL Managed Instance는 보통 Azure 쌍을 이루는 지역이 동시에 배포되지 않는 안전한 배포 사례를 따릅니다. 그러나 먼저 업그레이드할 지역을 예측할 수 없으므로 배포 순서가 보장되지 않습니다. 경우에 따라 주 인스턴스가 먼저 업그레이드되기도 하고 보조 인스턴스가 먼저 업그레이드되기도 합니다.

Azure SQL Managed Instance가 장애 조치(failover) 그룹의 일부이고 그룹의 인스턴스가 Azure 쌍을 이루는 지역에 없는 경우 주 데이터베이스와 보조 데이터베이스에 대해 다른 유지 관리 기간 일정을 선택합니다. 예를 들어 지역 보조 데이터베이스의 유지 관리 기간은 평일로, 지역 주 데이터베이스의 유지 관리 기간은 주말로 선택합니다.

인스턴스 간 지역 복제 트래픽 흐름 사용 및 최적화

중단 없는 지역 복제 트래픽 흐름에 대해 기본 인스턴스와 보조 인스턴스를 호스팅하는 가상 네트워크 서브넷 간의 연결을 설정하고 유지 관리해야 합니다. 네트워크 토폴로지 및 정책에 따라 선택할 수 있는 인스턴스 간에 연결을 제공하는 방법은 여러 가지입니다.

• 전역 가상 네트워크 피어링
• VPN 게이트웨이
• Azure ExpressRoute

장애 조치 그룹의 두 인스턴스 간에 연결을 설정할 때 글로벌 VNet 피어링(가상 네트워크 피어링)을 사용하면 좋습니다. Microsoft 백본 인프라를 사용하여 피어링된 가상 네트워크 사이에 대기 시간이 짧고 대역폭이 높은 프라이빗 연결을 제공합니다. 피어링된 가상 네트워크 간의 통신에 공용 인터넷, 게이트웨이, 또는 추가 암호화가 필요하지 않습니다.

초기 시드

관리되는 인스턴스 간에 장애 조치(failover) 그룹을 설정하는 경우 데이터 복제가 시작되기 전에 초기 시드 단계가 있습니다. 초기 시드 단계는 가장 길고 비용이 많이 드는 작업입니다. 초기 시드가 완료되면 데이터가 동기화되고 후속 데이터 변경 내용만 복제됩니다. 초기 시드가 완료되는 데 걸리는 시간은 데이터 크기, 복제된 데이터베이스 수, 주 데이터베이스의 워크로드 강도 및 주로 연결 설정 방법에 따라 달라지는 주 인스턴스와 보조 인스턴스를 호스트하는 가상 네트워크 간의 연결 속도에 따라 달라집니다. 정상적인 상황에서 권장되는 글로벌 가상 네트워크 피어링을 사용하여 연결이 설정된 경우 시드 속도는 SQL Managed Instance 시간당 최대 360GB입니다. 시드는 사용자 데이터베이스의 일괄 처리에 대해 병렬로 수행됩니다(모든 데이터베이스가 동시에 수행되는 것은 아닙니다). 인스턴스에 호스트되는 데이터베이스가 많은 경우 일괄 처리가 여러 번 필요할 수 있습니다.

두 인스턴스 간의 링크 속도가 필요한 속도보다 느리면 시드 시간에 큰 영향을 받을 수 있습니다. 명시된 시드 속도, 데이터베이스 수, 총 데이터 크기 및 링크 속도를 사용하여 데이터 복제가 시작되기 전에 초기 시드 단계에 걸리는 시간을 추정할 수 있습니다. 예를 들어, 단일 100GB 데이터베이스의 경우 링크가 시간당 84GB를 푸시할 수 있고 시드되는 다른 데이터베이스가 없으면 초기 시드 단계에 약 1.2시간이 걸립니다. 링크가 시간당 10GB만 전송할 수 있으면 100GB 데이터베이스를 시드하는 데 약 10시간이 걸립니다. 복제할 데이터베이스가 여러 개 있으면 시드가 병렬로 실행됩니다. 느린 링크 속도와 결합되는 경우, 특히 모든 데이터베이스의 데이터 병렬 시드가 사용 가능한 링크 대역폭을 초과하면 초기 시드 단계가 상당히 오래 걸릴 수 있습니다.

Important

속도가 매우 낮거나 사용량이 많은 링크로 인해 초기 시드 단계가 며칠이 걸리는 경우 장애 조치(failover) 그룹을 만드는 시간이 초과할 수 있습니다. 생성 프로세스는 6일 후에 자동으로 취소됩니다.

지역 보조 인스턴스로 지역 장애 조치(failover) 관리

장애 조치(failover) 그룹은 주 관리형 인스턴스에서 이루어지는 모든 데이터베이스의 지역 장애 조치(failover)를 관리합니다. 그룹을 만들면 인스턴스의 각 데이터베이스가 자동으로 지역 보조 인스턴스에 지역 복제됩니다. 장애 조치(failover) 그룹을 사용하여 데이터베이스 일부의 부분 장애 조치(failover)를 시작할 수 없습니다.

중요

주 관리되는 인스턴스에서 데이터베이스를 제거하면 지역 보조 관리되는 인스턴스에서도 자동으로 삭제됩니다.

읽기-쓰기 수신기 사용(주 MI)

읽기-쓰기 워크로드의 경우 서버 이름으로 <fog-name>.zone_id.database.windows.net을 사용합니다. 연결은 자동으로 주 인스턴스에 연결됩니다. 이 이름은 장애 조치(failover) 후에 변경되지 않습니다. 지역 장애 조치(failover) 시에는 DNS 레코드가 업데이트되므로 클라이언트 DNS 캐시를 새로 고친 후에만 새 클라이언트 연결이 새로운 주 데이터베이스로 라우팅됩니다. 보조 인스턴스는 주 인스턴스와 DNS 영역을 공유하므로 클라이언트 애플리케이션이 같은 서버 쪽 SAN 인증서를 사용하여 다시 연결할 수 있습니다. 기존 클라이언트 연결을 종료한 다음 다시 만들어 새 주 데이터베이스로 라우팅해야 합니다. 읽기 쓰기 수신기 및 읽기 전용 수신기는 관리형 인스턴스에 대한 퍼블릭 엔드포인트를 통해 도달할 수 없습니다.

읽기 전용 수신기 사용(보조 MI)

데이터 대기 시간을 허용하는 논리적으로 격리된 읽기 전용 워크로드가 있는 경우 지역 보조 데이터베이스에서 이러한 워크로드를 실행할 수 있습니다. 지역 보조 데이터베이스에 직접 연결하려면 서버 이름으로 <fog-name>.secondary.<zone_id>.database.windows.net을 사용합니다.

중요 비즈니스용 계층에서 SQL Managed Instance는 연결 문자열의 ApplicationIntent=ReadOnly 매개 변수를 사용하여 읽기 전용 쿼리 워크로드를 오프로드하도록 읽기 전용 복제본 사용을 지원합니다. 지역 복제된 보조 데이터베이스를 구성한 경우 이 기능을 사용하여 주 위치 또는 지역 복제된 위치에 있는 읽기 전용 복제본에 연결할 수 있습니다.

• 주 위치의 읽기 전용 복제본에 연결하려면 ApplicationIntent=ReadOnly와 <fog-name>.<zone_id>.database.windows.net을 사용합니다.
• 보조 위치의 읽기 전용 복제본에 연결하려면 ApplicationIntent=ReadOnly와 <fog-name>.secondary.<zone_id>.database.windows.net을 사용합니다.

읽기 쓰기 수신기 및 읽기 전용 수신기는 관리되는 인스턴스에 대한 퍼블릭 엔드포인트를 통해 도달할 수 없습니다.

장애 조치(failover) 후 잠재적인 성능 저하

일반적인 Azure 애플리케이션은 여러 Azure 서비스를 사용하며 여러 구성 요소로 구성됩니다. 그룹의 지역 장애 조치(failover)는 Azure SQL 구성 요소의 상태에 따라서만 트리거됩니다. 주 지역의 다른 Azure 서비스는 중단의 영향을 받지 않을 수 있으며 해당 구성 요소는 해당 지역에서 계속 사용할 수 있습니다. 주 데이터베이스가 보조 지역으로 전환되면 종속된 구성 요소 사이의 대기 시간이 늘어날 수 있습니다. 더 길어진 지역 간 대기 시간이 애플리케이션 성능에 영향을 미치지 않도록 보조 지역에 있는 모든 애플리케이션 구성 요소의 중복성을 보장하고 데이터베이스와 함께 애플리케이션 구성 요소를 장애 조치합니다.

강제 장애 조치(failover) 후 데이터 손실 가능성

주 지역에서 중단이 발생하는 경우 최근 트랜잭션이 지역 보조 데이터베이스에 복제되지 않았을 수 있으며 강제 장애 조치(failover)가 수행되면 데이터가 손실될 수 있습니다.

DNS 업데이트

읽기/쓰기 수신기의 DNS 업데이트는 장애 조치(failover)가 시작된 후 즉시 발생합니다. 이 작업으로 인해 데이터가 손실되지 않습니다. 그러나 일반적인 조건에서 데이터베이스 역할을 전환하는 데 최대 5분 정도 걸릴 수 있습니다. 완료될 때까지 새로운 주 인스턴스의 일부 데이터베이스는 계속 읽기 전용입니다. PowerShell을 사용하여 장애 조치를 시작하는 경우 주 복제본 역할을 전환하는 작업은 동기식입니다. Azure Portal을 사용하여 시작하는 경우 UI에 완료 상태가 표시됩니다. REST API를 사용하여 시작하는 경우, 표준 Azure Resource Manager의 폴링 메커니즘을 사용하여 완료되었는지 모니터링합니다.

중요

지역 장애 조치(failover)를 유발한 중단이 완화된 후에는 수동 계획된 장애 조치(failover)를 사용하여 기본 위치를 다시 원래 위치로 다시 이동합니다.

라이선스가 없는 DR 복제본으로 비용 절감

DR(재해 복구)에만 사용할 보조 관리형 인스턴스를 구성하여 SQL Server 라이선스 비용을 절감할 수 있습니다. 이를 설정하려면 Azure SQL Managed Instance에 대한 라이선스가 필요 없는 대기 복제본(replica) 구성을 참조하세요.

보조 인스턴스가 읽기 워크로드에 사용되지 않는 한, Microsoft는 주 인스턴스와 일치하는 무료 vCore를 제공합니다. 보조 인스턴스에서 사용한 컴퓨팅 및 스토리지에 대한 요금은 계속 청구됩니다. 장애 조치 그룹은 하나의 복제본만 지원합니다. 이 복제본은 읽기 가능한 복제본이거나 DR 전용 복제본으로 지정되어야 합니다.

시스템 데이터베이스의 개체에 종속된 시나리오 사용

시스템 데이터베이스는 장애 조치(failover) 그룹의 보조 인스턴스에 복제되지 않습니다. 시스템 데이터베이스의 개체에 따라 달라지는 시나리오를 지원하려면 보조 인스턴스에서 동일한 개체를 만들고 주 인스턴스와 동기화 상태를 유지해야 합니다.

예를 들어 보조 인스턴스에서 같은 로그인을 사용하려는 경우 같은 SID를 사용하여 해당 로그인을 만들어야 합니다.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

자세한 내용은 로그인 및 에이전트 작업의 복제를 참조하세요.

인스턴스 속성 및 보존 정책 인스턴스 동기화

장애 조치(failover) 그룹의 인스턴스는 별도의 Azure 리소스로 남아 있으며, 주 인스턴스 구성의 변경 내용은 보조 인스턴스에 자동으로 복제되지 않습니다. 모든 관련 변경을 주 인스턴스와 보조 인스턴스 모두에서 수행해야 합니다. 예를 들어 주 인스턴스에서 백업 스토리지 중복 또는 장기 백업 보존 정책을 변경하는 경우 보조 인스턴스에서도 변경해야 합니다.

인스턴스 스케일링

주 인스턴스 및 보조 인스턴스를 동일한 서비스 계층 내의 다른 컴퓨팅 크기 또는 다른 서비스 계층으로 스케일 업하거나 스케일 다운할 수 있습니다. 동일한 서비스 계층 내에서 스케일 업할 때에는 지역 보조 위치부터 스케일 업한 다음, 주 위치를 스케일 업하는 것이 좋습니다. 동일한 서비스 계층 내에서 스케일 다운할 때에는 역순으로 합니다. 주 위치부터 스케일 다운한 다음, 보조 위치를 스케일 다운합니다. 인스턴스를 다른 서비스 계층으로 크기 조정할 때에는 이 권장 사항이 강제 적용됩니다. 작업 시퀀스는 스토리지뿐만 아니라 서비스 계층 및 vCore를 확장할 경우 적용됩니다.

이 순서는 더 낮은 SKU의 지역 보조 데이터베이스가 오버로드되어 업그레이드 또는 다운그레이드 프로세스 중에 다시 시딩해야 하는 문제를 방지하기 위해 특히 권장됩니다.

Important

• 장애 조치(failover) 그룹 내 인스턴스의 경우 서비스 계층을 차세대 범용 계층에서 또는 차세대 범용 계층으로 변경하는 작업은 지원되지 않습니다. 두 복제본(replica) 중 하나라도 수정하기 전에 먼저 장애 조치(failover) 그룹을 삭제한 다음, 변경 내용을 적용한 후 장애 조치(failover) 그룹을 다시 만들어야 합니다.
• 연결된 장애 조치(failover) 그룹 수신기를 사용하여 크기를 조정하는 인스턴스의 접근성에 영향을 미칠 수 있는 알려진 문제가 있습니다.

중요한 데이터 손실 방지

광역 네트워크의 높은 대기 시간으로 인해 지역 복제에는 비동기 복제 메커니즘이 사용됩니다. 비동기 복제를 사용하면 주 데이터베이스에서 오류가 발생할 때 데이터가 손실될 가능성이 있습니다. 중요한 트랜잭션을 데이터 손실로부터 보호하려면 애플리케이션 개발자는 트랜잭션을 커밋한 후 즉시 sp_wait_for_database_copy_sync 시스템 프로시저를 호출하면 됩니다. sp_wait_for_database_copy_sync를 호출하면 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그로 전송되어 강화될 때까지 호출 스레드가 차단됩니다. 그러나 전송된 트랜잭션이 보조 데이터베이스에서 재생(다시 실행)될 때까지 기다리지는 않습니다. sp_wait_for_database_copy_sync의 범위는 특정 지역 복제 링크로 한정됩니다. 주 데이터베이스에 대한 연결 권한이 있는 모든 사용자는 이 프로시저를 호출할 수 있습니다.

사용자가 시작한 계획된 지역 장애 조치 중에 데이터 손실을 방지하기 위해 자동으로 복제하고 동기 복제를 일시적으로 변경한 다음, 장애 조치를 수행합니다. 그런 다음, 지역에서 장애 조치가 완료된 후 복제가 비동기 모드로 돌아갑니다.

참고 항목

sp_wait_for_database_copy_sync는 특정 트랜잭션의 지역 장애 조치(failover) 후 데이터 손실을 방지하지만, 읽기 액세스에 대한 전체 동기화를 보장하지는 않습니다. sp_wait_for_database_copy_sync 프로시저를 호출하면 상당한 지연이 발생할 수 있으며, 호출 당시 주 데이터베이스에서 아직 전송되지 않은 트랜잭션 로그의 크기에 따라 지연 시간이 달라집니다.

장애 조치(failover) 그룹 상태

장애 조치(failover) 그룹은 데이터 복제의 현재 상태를 설명하는 상태를 보고합니다.

• 시드 중 - 장애 조치(failover) 그룹을 만든 후 모든 사용자 데이터베이스가 보조 인스턴스에서 초기화될 때까지 초기 시드가 수행됩니다. 사용자 데이터베이스가 아직 보조 인스턴스에 복사되지 않았으므로 장애 조치(failover) 그룹이 시드 상태에 있는 동안 장애 조치(failover) 프로세스를 시작할 수 없습니다.
• 동기화 중 - 장애 조치(failover) 그룹의 일반적인 상태. 이는 주 인스턴스의 데이터 변경 내용이 보조 인스턴스에 비동기적으로 복제되는 중임을 의미합니다. 이 상태는 데이터가 매 순간 완전히 동기화된다는 것을 보장하지 않습니다. 장애 조치(failover) 그룹의 인스턴스 간 복제 프로세스의 비동기 특성으로 인해 주 데이터베이스에서 보조 데이터베이스로 여전히 복제되는 데이터 변경 내용이 있을 수 있습니다. 장애 조치(failover) 그룹이 동기화 상태인 동안 자동 및 수동 장애 조치(failover)를 모두 시작할 수 있습니다.
• 장애 조치(failover) 진행 중 - 이 상태는 자동으로 또는 수동으로 시작된 장애 조치(failover) 프로세스가 진행 중임을 나타냅니다. 장애 조치(failover) 그룹이 이 상태에 있는 동안 장애 조치(failover) 그룹 또는 추가 장애 조치(failover)에 대한 변경 작업을 시작할 수 없습니다.

장애 복구(Failback)

장애 조치(failover) 그룹이 Microsoft 관리 장애 조치(failover) 정책으로 구성된 경우 정의된 유예 기간에 따라 재해 시나리오 중에 지역 보조 서버로 강제 장애 조치(failover)가 시작됩니다. 이전 주 위치로의 장애 복구(failback)는 수동으로 시작해야 합니다.

기능 상호 운용성

Backup

전체 백업은 다음 시나리오에서 수행됩니다.

• 장애 조치(failover) 그룹을 만들 때 초기 시드가 시작되기 전에.
• 장애 조치(failover) 후.

전체 백업은 건너뛰거나 연기할 수 없는 데이터 작업의 크기로, 완료하는 데 다소 시간이 걸릴 수 있습니다. 완료하는 데 걸리는 시간은 데이터 크기, 데이터베이스 수 및 주 데이터베이스의 워크로드 강도에 따라 달라집니다. 전체 백업은 초기 시드를 눈에 띄게 지연할 수 있으며 장애 조치(failover) 직후 새 인스턴스에서 장애 조치(failover) 작업을 지연시키거나 방지할 수 있습니다.

로그 재생 서비스

LRS(Log Replay Service)를 사용하여 Azure SQL Managed Instance로 마이그레이션된 데이터베이스는 컷오버 단계가 실행될 때까지 장애 조치(failover) 그룹에 추가할 수 없습니다. LRS를 사용하여 마이그레이션된 데이터베이스는 중단될 때까지 복원 상태에 있으며 복원 상태의 데이터베이스는 장애 조치(failover) 그룹에 추가할 수 없습니다. 복원 중인 상태의 데이터베이스를 사용하여 장애 조치(failover) 그룹을 만들려고 시도하면 데이터베이스 복원이 완료될 때까지 장애 조치(failover) 그룹 만들기가 지연됩니다.

트랜잭션 복제

장애 조치(failover) 그룹에 있는 인스턴스에서 트랜잭션 복제 사용이 지원됩니다. 그러나 장애 조치(failover) 그룹에 SQL Managed Instance를 추가하기 전에 복제를 구성하면 장애 조치(failover) 그룹을 생성하기 시작하면 복제가 일시 중지되고 복제 모니터는 Replicated transactions are waiting for the next log backup or for mirroring partner to catch up 상태를 표시합니다. 장애 조치(failover) 그룹이 생성되면 복제가 다시 시작됩니다.

게시자 또는 배포자 SQL Managed Instance가 장애 조치(failover) 그룹에 있는 경우, 장애 조치(failover)가 발생한 후 SQL Managed Instance 관리자가 모든 게시를 이전 주 데이터베이스에서 정리하고 새로운 주 데이터베이스에서 다시 구성해야 합니다. 이 시나리오에서 필요한 활동의 단계는 트랜잭션 복제 가이드를 검토하세요.

권한 및 제한 사항

장애 조치 그룹을 구성하기 전에 권한 및 제한 사항 목록을 검토하세요.

프로그래밍 방식으로 장애 조치(failover) 그룹 관리

Azure PowerShell, Azure CLI 및 REST API를 사용하여 프로그래밍 방식으로 장애 조치(failover) 그룹을 관리할 수도 있습니다. 자세한 내용은 장애 조치(failover) 그룹 구성을 검토하세요.

재해 복구 훈련

DR 훈련을 수행하는 권장 방법은 자습서(테스트 장애 조치(failover))에 따라 수동 계획된 장애조치를 사용하는 것입니다.

강제 장애 조치(failover) 작업은 데이터 손실에 대한 가드레일을 제공하지 않기 때문에 이를 사용하여 훈련을 수행하는 것은 권장되지 않습니다. 그럼에도 불구하고 강제 장애 조치(failover)를 시작하기 전에 다음 조건이 충족되도록 하여 데이터 손실 없는 강제 장애 조치(failover)를 수행할 수 있습니다.

• 기본 Managed Instance에서 워크로드가 중지되었습니다.
• 모든 장기 실행 트랜잭션이 완료되었습니다.
• 기본 Managed Instance에 대한 모든 클라이언트 연결이 해제되었습니다.
• 장애 조치(failover) 그룹 상태가 '동기화 중'입니다.

두 Managed Instance가 역할을 전환했고, 필요에 따라 새 기본 Managed Instance에 대한 연결을 설정하고 읽기-쓰기 워크로드를 시작하기 전에 장애 조치(failover) 그룹 상태가 '장애 조치(failover) 진행 중'에서 '동기화 중'으로 전환되었는지 확인하세요.

원래 Managed Instance 역할에 대한 데이터 손실 없는 장애 복구(failback)를 수행하려면 강제 장애 조치(failover) 대신 수동 계획된 장애조치 사용하는 것이 좋습니다. 강제 장애 복구(failback)를 진행하려면 다음을 수행합니다.

• 데이터 손실 없는 장애 조치(failover)와 동일한 단계를 수행합니다.
• 이전 기본 Managed Instance에서 미해결 자동 백업 작업이 완료될 때까지 기다려야 하므로 초기 강제 장애 조치(failover)가 완료된 직후 강제 장애 복구(failback)가 실행될 경우 장애 복구(failback) 실행 시간이 더 길어질 것으로 예상됩니다.

관련 콘텐츠

• 장애 조치(failover) 그룹 구성
• PowerShell을 사용하여 장애 조치(failover) 그룹에 관리형 인스턴스 추가
• Azure SQL Managed Instance에 대한 라이선스가 필요 없는 대기 복제본(replica) 구성
• Azure SQL Managed Instance를 사용한 비즈니스 연속성 개요
• Azure SQL Managed Instance의 자동화된 백업
• Azure SQL Managed Instance 백업에서 데이터베이스 복원