영업: 1-800-867-1380

Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구

업데이트 날짜: 2014년 6월

SQL Server이(가) 포함된 Microsoft Azure VM(가상 컴퓨터)은 HADR(고가용성 및 재해 복구) 데이터베이스 솔루션의 비용을 낮추는 데 도움이 될 수 있습니다. 대부분의 SQL Server HADR 솔루션은 Azure 가상 컴퓨터에서 Azure 전용 및 하이브리드 솔루션으로 지원됩니다. Azure 전용 솔루션의 경우 전체 HADR 시스템은 Azure에서 실행됩니다. 하이브리드 구성의 경우 솔루션의 일부는 Azure에서 실행되고 솔루션의 다른 부분은 조직의 온-프레미스에서 실행됩니다. Azure 환경의 융통성 덕분에 SQL Server 데이터베이스 시스템의 예산과 HADR 요구 사항을 충족하기 위해 Azure(으)로 부분적으로 이동하거나 완전히 이동할 수 있습니다.

원하는 경우 데이터베이스 시스템에 SLA(서비스 수준 계약)에 필요한 HADR 기능이 있는지를 확인할 수 있습니다. Azure에서 클라우드 서비스에 대한 서비스 복구 및 가상 컴퓨터에 대한 오류 복구 검색과 같은 고가용성 메커니즘을 제공한다는 사실 자체가 원하는 SLA를 보장하는 것은 아닙니다. 이러한 메커니즘은 VM의 고가용성을 보호하지만 VM 내부에서 실행 중인 SQL Server의 고가용성은 보호하지 않습니다. VM이 온라인 상태이고 정상적으로 작동하는 동안 SQL Server 인스턴스에서 장애가 발생할 수 있습니다. 또한 Azure에서 제공하는 고가용성 메커니즘에서도 소프트웨어 또는 하드웨어 오류의 복구나 운영 체제 업그레이드와 같은 이벤트 때문에 VM의 가동이 중지될 수 있습니다.

또한 지리적 복제라고도 하는 기능으로 구현되는 Azure의 GRS(지역 중복 저장소)는 데이터베이스에 적합한 재해 복구 솔루션이 아닐 수 있습니다. 지리적 복제는 비동기적으로 데이터를 전송하므로 재해 발생 시 최신 업데이트가 손실될 수 있습니다. 지리적 복제 제한과 관련된 자세한 내용은 지리적 복제가 각기 다른 디스크에 있는 데이터 및 로그 파일에 대해 지원되지 않음 섹션을 참조하세요.

Azure에서 지원되는 SQL Server HADR 기술은 다음과 같습니다.

위의 기능을 결합하여 고가용성 및 재해 복구 기능을 갖춘 SQL Server 솔루션을 구현할 수 있습니다. 사용하는 기술에 따라 하이브리드 배포에 Azure 가상 네트워크와 함께 VPN 터널이 필요할 수 있습니다. 아래의 섹션들에서는 몇 가지 예제 배포 아키텍처를 보여 줍니다.

AlwaysOn 가용성 그룹 또는 데이터베이스 미러링을 사용하여 Azure에서 SQL Server 데이터베이스의 고가용성 솔루션을 구현할 수 있습니다.

 

기술 예제 아키텍처

AlwaysOn 가용성 그룹

모든 가용성 복제본이 고가용성을 위해 동일 영역 내의 Azure VM에서 실행됩니다. WSFC(Windows Server 장애 조치(Failover) 클러스터링)에 Active Directory 도메인이 필요하기 때문에 SQL Server 가상 컴퓨터뿐만 아니라 도메인 컨트롤러를 구성해야 합니다.

자세한 내용은 자습서: Azure의 AlwaysOn 가용성 그룹(GUI)를 참조하십시오.

데이터베이스 미러링

주 서버, 미러 서버 및 미러링 모니터 서버가 고가용성을 위해 동일한 Azure 데이터 센터에서 모두 실행됩니다. 도메인 컨트롤러를 사용하여 배포할 수 있습니다.

서버 인증서를 대신 사용하여 도메인 컨트롤러 없이 동일한 데이터베이스 미러링 구성을 배포할 수도 있습니다.

자세한 내용은 자습서: Azure에서 고가용성을 위한 데이터베이스 미러링를 참조하십시오.

AlwaysOn 가용성 그룹, 데이터베이스 미러링이나 저장소 Blob을 사용한 백업 및 복원을 통해 Azure에서 SQL Server 데이터베이스의 재해 복구 솔루션을 구현할 수 있습니다.

 

기술 예제 아키텍처

AlwaysOn 가용성 그룹

재해 복구를 위해 Azure VM의 여러 데이터 센터에서 실행 중인 가용성 복제본입니다. 이 영역 간 솔루션은 전체 사이트 중단이 발생하지 않도록 방지합니다.

영역 내에서 모든 복제본은 동일한 클라우드 서비스 및 동일한 VNet 내에 있어야 합니다. 각 영역에는 별도의 VNet이 있으므로 이러한 솔루션에는 VNet간 연결이 필요합니다. 자세한 내용은 VNet간 연결 구성을 참조하세요.

데이터베이스 미러링

주 서버 및 미러와 서버가 재해 복구를 위해 서로 다른 데이터 센터에서 실행됩니다. Active Directory 도메인이 여러 데이터 센터에 걸쳐 있을 수 없기 때문에 서버 인증서를 사용하여 배포해야 합니다.

자세한 내용은 자습서: Azure에서 재해 복구를 위한 데이터베이스 미러링를 참조하십시오.

Azure Blob 저장소 서비스를 사용한 백업 및 복원

프로덕션 데이터베이스가 재해 복구를 위해 다른 데이터 센터에 있는 Blob 저장소에 직접 백업됩니다.

자세한 내용은 Azure 가상 컴퓨터에서 SQL Server의 백업 및 복원를 참조하십시오.

AlwaysOn 가용성 그룹, 데이터베이스 미러링, 로그 전달, Azure Blob 저장소를 사용한 백업 및 복원을 통해 하이브리드 IT 환경에서 SQL Server 데이터베이스의 재해 복구 솔루션을 구현할 수 있습니다.

 

기술 예제 아키텍처

AlwaysOn 가용성 그룹

사이트 간 재해 복구를 위해 일부 가용성 복제본이 Azure VM에서 실행되고 다른 복제본이 온-프레미스로 실행됩니다. 프로덕션 사이트는 온-프레미스에 있거나 Azure 데이터 센터에 있을 수 있습니다.

모든 가용성 복제본이 동일한 WSFC 클러스터에 있어야 하기 때문에 WSFC 클러스터가 두 네트워크에 걸쳐 있어야 합니다(다중 서브넷 WSFC 클러스터). 이 구성에는 Azure와 온-프레미스 네트워크 간에 VPN 연결이 필요합니다.

데이터베이스의 성공적인 재해 복구를 위해 재해 복구 사이트에서 복제본 도메인 컨트롤러도 설치해야 합니다.

자세한 내용은 Tutorial: AlwaysOn Availability Groups in Hybrid IT를 참조하십시오.

데이터베이스 미러링

  • 서버 인증서를 사용한 사이트 간 재해 복구를 위해 한 파트너가 Azure VM에서 실행되고 다른 파트너가 온-프레미스로 실행됩니다. 파트너가 동일한 Active Directory 도메인에 있을 필요가 없으며 VPN 연결이 필요하지 않습니다.



    자세한 내용은 자습서: 하이브리드 IT에서 재해 복구를 위한 데이터베이스 미러링를 참조하십시오.

  • 사이트 간 재해 복구를 위해 한 파트너가 Azure VM에서 실행되고 다른 파트너가 동일한 Active Directory 도메인에서 온-프레미스로 실행됩니다. Azure 가상 네트워크와 온-프레미스 네트워크 간의 VPN 연결이 필요합니다.

    데이터베이스의 성공적인 재해 복구를 위해 재해 복구 사이트에서 복제본 도메인 컨트롤러도 설치해야 합니다.

로그 전달

사이트 간 재해 복구를 위해 한 서버가 Azure VM에서 실행되고 다른 서버가 온-프레미스로 실행됩니다. 로그 전달은 Windows 파일 공유를 전제 조건으로 하므로 Azure 가상 네트워크와 온-프레미스 네트워크 간의 VPN 연결이 필요합니다.

데이터베이스의 성공적인 재해 복구를 위해 재해 복구 사이트에서 복제본 도메인 컨트롤러도 설치해야 합니다.

자세한 내용은 자습서: 하이브리드 IT에서 재해 복구를 위한 로그 전달를 참조하십시오.

Azure Blob 저장소 서비스를 사용한 백업 및 복원

온-프레미스 프로덕션 데이터베이스가 재해 복구를 위해 Azure Blob 저장소에 직접 백업됩니다.

자세한 내용은 Azure 가상 컴퓨터에서 SQL Server의 백업 및 복원를 참조하십시오.

Azure VM, 저장소 및 네트워킹은 가상화되지 않은 온-프레미스 IT 인프라와 다른 작업 특성을 갖고 있습니다. Azure에서 HADR SQL Server 솔루션을 성공적으로 구현하려면 이러한 차이점을 이해하고 이를 고려하여 솔루션을 디자인해야 합니다.

Azure의 가용성 집합을 통해 고가용성 노드를 별도의 FD(오류 도메인) 및 UD(업데이트 도메인)에 배치할 수 있습니다. Azure VM이 동일한 가용성 집합에 배치되려면 동일한 클라우드 서비스에서 Azure VM을 배포해야 합니다. 동일한 클라우드 서비스의 노드만 동일한 가용성 집합에 참가할 수 있습니다. 자세한 내용은 가상 컴퓨터의 가용성 관리를 참조하십시오.

Azure에서 RFC 규격이 아닌 DHCP 서비스가 있으면 클러스터 네트워크 이름이 중복 IP 주소(예: 클러스터 노드 중 하나와 같은 IP 주소)에 할당되기 때문에 특정 WSFC 클러스터 구성을 만들지 못하게 될 수 있습니다. 이는 WSFC 기능을 전제 조건으로 하는 AlwaysOn 가용성 그룹을 구현할 때 문제가 됩니다.

2-노드 클러스터를 만들고 온라인 상태로 만드는 시나리오를 살펴보면 다음과 같습니다.

  1. 클러스터가 온라인 상태로 된 다음 NODE1이 클러스터 네트워크 이름에 대해 동적으로 할당된 IP 주소를 요청합니다.

  2. DHCP 서비스는 요청이 NODE1 자체에서 오는 것으로 인식하므로 NODE1의 자체 IP 주소가 아닌 IP 주소는 DHCP 서비스에서 제공하지 않습니다.

  3. Windows에서는 중복 주소가 NODE1과 클러스터 네트워크 이름에 할당되었음을 감지하며 기본 클러스터 그룹은 온라인 상태가 되지 못합니다.

  4. 기본 클러스터 그룹은 NODE2로 이동합니다. NODE2는 NODE1의 IP 주소를 클러스터 IP 주소로 처리하고 기본 클러스터 그룹을 온라인 상태로 만듭니다.

  5. NODE2가 NODE1과 연결을 설정하려고 할 때 NODE1로 향하는 패킷은 NODE2가 NODE1의 IP 주소를 NODE2 자신으로 확인하기 때문에 NODE2를 떠나지 않습니다. NODE2는 NODE1과 연결을 설정할 수 없으며 쿼럼을 손실하고 클러스터를 종료합니다.

  6. 한편 NODE1은 NODE2로 패킷을 보낼 수 있지만 NODE2는 회신할 수 없습니다. NODE1은 쿼럼을 손실하고 클러스터를 종료합니다.

이러한 시나리오를 통해 클러스터 네트워크 이름을 온라인 상태로 만들기 위해 사용되지 않는 고정 IP 주소(169.254.1.1과 같은 링크 로컬 IP 주소)를 클러스터 네트워크 이름에 할당하는 것을 방지할 수 있습니다. 이 프로세스를 단순화하려면 Azure에서 AlwaysOn 가용성 그룹에 대해 Windows 장애 조치(Failover) 클러스터 구성을 참조하십시오.

AlwaysOn 가용성 그룹에 대한 다음 자습서에서는 여러 가지 시나리오에서 가용성 그룹을 구성하는 방법을 보여 줍니다.

가용성 그룹 수신기는 Windows Server 2008 R2, Windows Server 2012 및 Windows Server 2012 R2를 실행하는 Azure VM에서 지원됩니다. 가용성 그룹 노드인 Azure VM에서 DSR(Direct Server Return)이 설정된 부하 분산 끝점을 사용하여 이러한 지원이 이루어집니다. Azure에서 실행 중인 클라이언트 응용 프로그램과 온-프레미스로 실행되는 클라이언트 응용 프로그램 모두가 작동하려면 수신기에 대한 특수 구성 단계를 따라야 합니다. 수신기 설정에 대한 지침은 자습서: AlwaysOn 가용성 그룹을 위한 수신기 구성을 참조하세요.

서비스 인스턴스에 직접 연결하여 각 가용성 복제본에 개별적으로 연결할 수 있습니다. 또한 AlwaysOn 가용성 그룹이 데이터베이스 미러링 클라이언트와 호환되므로 가용성 복제본이 다음과 같이 데이터베이스 미러링과 유사하게 구성되어 있는 한 데이터베이스 미러링 파트너처럼 가용성 복제본에 연결할 수 있습니다.

  • 주 복제본 한 개와 보조 복제본 한 개

  • 보조 복제본이 읽을 수 없는 것으로 구성됨(읽을 수 있는 보조 옵션이 아니요로 설정됨)

다음은 ADO.NET 또는 SQL Server Native Client를 사용하는 이 데이터베이스 미러링과 유사한 구성에 해당하는 클라이언트 연결 문자열의 예입니다.

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

클라이언트 연결에 대한 자세한 내용은 다음을 참조하십시오.

온-프레미스 네트워크와 Azure 간의 네트워크 대기 시간이 길어질 수 있다는 가정 하에 HADR 솔루션을 배포해야 합니다. Azure에 복제본을 배포할 때 동기화 모드에는 동기 커밋 대신 비동기 커밋을 사용해야 합니다. 온-프레미스와 Azure에서 데이터베이스 미러링 서버를 배포하는 경우에는 보호 우선 모드 대신 성능 우선 모드를 사용합니다.

Azure 디스크의 지리적 복제는 동일한 데이터베이스의 데이터 파일과 로그 파일이 각기 다른 디스크에 저장되도록 지원하지 않습니다. GRS는 각 디스크의 변경 내용을 독립적이고 비동기적으로 복제합니다. 이 메커니즘은 단일 디스크 내의 지리적으로 복제된 복사본에서 쓰기 순서를 보장하지만 여러 디스크의 지리적으로 복제된 복사본들에서는 쓰기 순서를 보장하지 않습니다. 데이터 파일과 로그 파일을 각기 다른 디스크에 저장하도록 데이터베이스를 구성하는 경우 재해 후 복구된 디스크에는 로그 파일보다 최신인 데이터 파일의 복사본이 포함될 수 있으며 이 경우 SQL Server의 미리 쓰기 로그와 트랜잭션의 ACID 속성이 손상됩니다. 저장소 계정에 대한 지리적 복제를 사용하지 않도록 설정하는 옵션이 없는 경우 동일한 디스크에 지정된 데이터베이스의 데이터 파일과 로그 파일을 모두 유지해야 합니다. 데이터베이스의 크기 때문에 디스크를 두 개 이상 사용해야 하는 경우 데이터 중복성을 보장하기 위해 위에 나와 있는 재해 복구 솔루션 중 하나를 배포해야 합니다.

참고 항목

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2014 Microsoft