다음을 통해 공유


Azure DNS의 안정성

이 문서에는 Azure DNS에 대한 지역 간 재해 복구 및 비즈니스 연속성 지원에 대한 자세한 정보가 포함되어 있습니다.

지역 간 재해 복구 및 비즈니스 연속성

DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.

DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 공유 책임 모델에서 Microsoft는 기준 인프라 및 플랫폼 서비스를 사용할 수 있도록 보장합니다. 동시에 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 다른 활성화된 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우 자신의 워크로드에 적합한 재해 복구 계획을 설정할 책임이 있습니다. Azure PaaS(Platform as a Service) 제품에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공하며, 서비스별 기능을 사용하여 빠른 복구를 지원하여 DR 계획을 개발하는 데 도움이 될 수 있습니다.

재해 복구를 위한 Azure DNS 장애 조치(failover) 솔루션은 표준 DNS 메커니즘을 사용하여 백업 사이트로 장애 조치(failover)합니다. Azure DNS를 통한 수동 옵션은 수동 대기 또는 파일럿 라이트 접근 방식과 함께 사용할 경우 가장 잘 작동합니다.

DNS 서버가 장애 조치(failover) 또는 재해 영역 외부에 있으므로 가동 중지 시간에서 격리됩니다. 운영자가 재해 중에 네트워크에 연결되어 있고 전환할 수 있는 한 간단한 장애 조치(failover) 시나리오를 설계할 수 있습니다. 솔루션이 스크립팅되는 경우에는 스크립트를 실행하는 서버나 서비스도 프로덕션 환경에 영향을 미치는 문제로부터 격리되어 있는지 확인해야 합니다. 또한 영역의 TTL이 낮으면 장기간 확인자 캐싱이 방지되어 고객이 RTO 내 사이트에 액세스할 수 있습니다. 수동 대기 및 파일럿 라이트의 경우, 일부 사전 준비 및 기타 관리 활동이 필요할 수 있으므로 전환하기 전에 충분한 시간을 제공해야 합니다.

참고 항목

Azure 프라이빗 DNS 영역은 가상 네트워크를 명시적으로 피어링하지 않고도 Azure 지역 전체의 가상 네트워크 간의 DNS 확인을 지원합니다. 그러나 모든 가상 네트워크는 프라이빗 DNS 영역에 연결되어야 합니다.

Azure Portal을 사용하여 Azure 프라이빗 DNS 영역을 만드는 방법을 알아보려면 빠른 시작: Azure Portal을 사용하여 Azure 프라이빗 DNS 영역 만들기를 참조하세요.

Azure Portal을 사용하여 Azure DNS Private Resolver를 만들려면 빠른 시작: Azure Portal을 사용하여 Azure DNS Private Resolver 만들기를 참조하세요.

다중 지역 지리의 재해 복구

재해 복구 아키텍처 설정에는 두 가지 기술적인 측면이 있습니다.

  • 배포 메커니즘을 사용하여 주 및 대기 환경 간에 인스턴스, 데이터 및 구성 복제. 이러한 형식의 재해 복구는 기본적으로 Azure Site Recovery를 통해 수행할 수 있습니다. Veritas 또는 NetApp과 같은 Microsoft Azure 파트너 어플라이언스/서비스를 통해 Azure Site Recovery 설명서를 참조하세요.

  • 주 사이트에서 대기 사이트로 네트워크/웹 트래픽을 전환하는 솔루션 개발. 이러한 형식의 재해 복구는 Azure DNS, Azure Traffic Manager(DNS) 또는 타사 전역 부하 분산 장치를 통해 수행할 수 있습니다.

이 문서에서는 특히 Azure DNS 재해 복구 계획에 중점을 둡니다.

재해 복구 및 중단 검색 설정

재해 복구를 위한 Azure DNS 수동 장애 조치(failover) 솔루션은 표준 DNS 메커니즘을 사용하여 백업 사이트로 장애 조치(failover)합니다. Azure DNS를 통한 수동 옵션은 수동 대기 또는 표시등 방법과 함께 사용할 경우 가장 잘 작동합니다.

Diagram of manual failover using Azure DNS.

‘그림 - Azure DNS를 사용한 수동 장애 조치(failover)’

솔루션에 대한 가정은 다음과 같습니다.

  • 기본 및 보조 엔드포인트에는 자주 변경되지 않는 정적 IP가 있습니다. 주 사이트의 IP가 100.168.124.44이고 보조 사이트의 IP가 100.168.124.43이라고 가정해 보겠습니다.
  • Azure DNS 영역은 주 사이트와 보조 사이트에 모두 있습니다. 주 사이트의 엔드포인트는 prod.contoso.com이고 백업 사이트의 엔드포인트는 dr.contoso.com이라고 가정해 보겠습니다. www.contoso.com이라고 하는 기본 애플리케이션에 대한 DNS 레코드도 있습니다.
  • TTL은 조직에서 설정된 RTO SLA 수준 이하입니다. 예를 들어, 기업에서 애플리케이션 재해 응답의 RTO를 60분으로 설정하는 경우, TTL은 60분 미만이어야 하고 낮을수록 더 좋습니다. 다음과 같이 수동 장애 조치(failover)에 대한 Azure DNS를 설정할 수 있습니다.
    • DNS 영역 만들기
    • DNS 영역 레코드 만들기
    • CNAME 레코드 업데이트
  1. 다음과 같이 DNS 영역을 만듭니다(예: www.contoso.com).

    Screenshot of creating a DNS zone in Azure.

    ‘그림 - Azure에서 DNS 영역 만들기’

  2. 이 영역 내에서 다음과 같이 세 개의 레코드를 만듭니다(예 - www.contoso.com, prod.contoso.com 및 dr.consoto.com).

    Screenshot of creating DNS zone records.

    ‘그림 - Azure에서 DNS 영역 레코드 만들기’

    이 시나리오에서 사이트 www.contoso.com은 명시된 RTO보다 훨씬 낮은 30분의 TTL을 포함하고 프로덕션 사이트 prod.contoso.com을 가리키고 있습니다. 이 구성은 정상적인 비즈니스 작업 중에 이루어집니다. prod.contoso.com 및 dr.contoso.com의 TTL은 300초 또는 5분으로 설정되었습니다. Azure Monitor 또는 Azure App Insights와 같은 Azure 모니터링 서비스 또는 Dynatrace와 같은 파트너 모니터링 솔루션을 사용할 수 있습니다. 애플리케이션 또는 가상 인프라 수준의 오류를 모니터링하거나 검색할 수 있는 자체 개발 솔루션을 사용할 수도 있습니다.

  3. 오류가 감지되면 다음과 같이 레코드 값을 dr.contoso.com으로 변경합니다.

    Screenshot of updating CNAME record.

    ‘그림 - Azure에서 CNAME 레코드 업데이트’

    대부분의 확인자가 캐시된 영역 파일을 새로 고치는 30분 내에 www.contoso.com에 대한 쿼리는 dr.contoso.com으로 리디렉션됩니다. 다음 Azure CLI 명령을 실행하여 CNAME 값을 변경할 수도 있습니다.

      az network dns record-set cname set-record \
      --resource-group 123 \
      --zone-name contoso.com \
      --record-set-name www \
      --cname dr.contoso.com
    

    이 단계는 수동으로 또는 자동화를 통해 실행할 수 있습니다. 콘솔 또는 Azure CLI를 통해 수동으로 수행할 수 있습니다. Azure SDK 및 API를 사용하여 수동 개입이 필요하지 않도록 CNAME 업데이트를 자동화할 수 있습니다. 자동화는 Azure 함수를 통해, 타사 모니터링 애플리케이션 내에서 또는 온-프레미스에서도 빌드할 수 있습니다.

다음 단계