이 참조 아키텍처는 가용성 및 강력한 재해 복구 인프라를 달성하기 위해 N 계층 애플리케이션 여러 Azure Stack Hub 지역에서 실행하기 위한 검증된 사례 집합을 보여 줍니다. 이 문서에서 Traffic Manager는 고가용성을 달성하는 데 사용되지만, Traffic Manager가 사용자 환경에서 선호되는 선택이 아닌 경우 고가용성 부하 분산 장치 쌍을 대체할 수도 있습니다.
메모
아래 아키텍처에서 사용되는 Traffic Manager는 Azure에서 구성해야 하며 Traffic Manager 프로필을 구성하는 데 사용되는 엔드포인트는 공개적으로 라우팅 가능한 IP여야 합니다.
건축학
이 아키텍처는 SQL Server N 계층 애플리케이션에 표시된 아키텍처를 기반으로 합니다.
Azure N 계층 애플리케이션
주요 및 보조 지역. 두 지역을 사용하여 더 높은 가용성을 얻을 수 있습니다. 하나는 주 지역입니다. 다른 지역은 장애 조치(failover)를 위한 것입니다.
Azure Traffic Manager. Traffic Manager 들어오는 요청을 지역 중 하나로 라우팅합니다. 정상 작업 중에는 요청을 주 지역으로 라우팅합니다. 해당 지역을 사용할 수 없게 되면 Traffic Manager는 보조 지역으로 장애 조치(fail over)를 수행합니다. 자세한 내용은 Traffic Manager 구성 섹션을 참조하세요.
리소스 그룹들. 주 지역인 보조 지역에 대해 별도의 리소스 그룹 만듭니다. 이렇게 하면 각 지역을 단일 리소스 컬렉션으로 관리할 수 있는 유연성이 있습니다. 예를 들어 다른 지역을 삭제하지 않고 한 지역을 다시 배포할 수 있습니다. 쿼리를 실행하여 애플리케이션에 대한 모든 리소스를 나열할 수 있도록 리소스 그룹을 연결합니다.
가상 네트워크. 각 지역에 대해 별도의 가상 네트워크를 만듭니다. 주소 공간이 겹치지 않도록 합니다.
SQL Server Always On 가용성 그룹. SQL Server를 사용하는 경우 고가용성을 위해 SQL Always On 가용성 그룹 것이 좋습니다. 두 지역의 SQL Server 인스턴스를 포함하는 단일 가용성 그룹을 만듭니다.
VNET에서 VNET으로의 VPN 연결. Azure Stack Hub에서 VNET 피어링을 아직 사용할 수 없으므로 VNET 간 VPN 연결을 사용하여 두 VNET을 연결합니다. 자세한 내용은 Azure Stack Hub 에서 VNET 간 연결을 참조하세요.
권장 사항
다중 지역 아키텍처는 단일 지역에 배포하는 것보다 더 높은 가용성을 제공할 수 있습니다. 지역 장애가 주 지역에 영향을 미치는 경우, Traffic Manager를 사용하여 보조 지역으로 전환할 수 있습니다. 이 아키텍처는 애플리케이션의 개별 하위 시스템이 실패하는 경우에도 도움이 될 수 있습니다.
여러 지역에서 고가용성을 달성하기 위한 몇 가지 일반적인 방법이 있습니다.
활성/수동을 포함한 핫 스탠바이. 트래픽은 한 지역으로 이동하고 다른 지역은 활성 대기 상태에서 대기합니다. 활성 대기는 보조 지역의 VM이 항상 할당되고 실행됨을 의미합니다.
활성/수동 시스템은 콜드 대기 시스템과 함께 사용됩니다. 트래픽은 한 지역으로 이동하고 다른 지역은 콜드 대기 상태에서 대기합니다. 콜드 대기(Cold Standby)는 장애 조치가 필요할 때까지 보조 지역의 VM이 할당되지 않음을 의미합니다. 이 방법은 실행하는 데 비용이 적게 들지만 일반적으로 실패하는 동안 온라인 상태가 되는 데 시간이 더 오래 걸립니다.
활성/활성. 두 지역 모두 활성 상태이며 요청 간에 부하가 분산됩니다. 한 영역을 사용할 수 없게 되면 회전에서 제거됩니다.
이 참조 아키텍처는 Hot Standby 구성의 활성/수동 모드를 사용하여 장애 조치(failover)를 위해 Traffic Manager를 사용합니다. 핫 대기용으로 적은 수의 VM을 배포한 다음 필요에 따라 스케일 아웃할 수 있습니다.
Traffic Manager 구성
Traffic Manager를 구성할 때 다음 사항을 고려합니다.
라우팅. Traffic Manager는 여러 라우팅 알고리즘 를 지원합니다. 이 문서에 설명된 시나리오의 경우 우선 순위 라우팅(이전의 장애 조치(failover) 라우팅이라고 함)을 사용합니다. 이 설정을 사용하면 주 지역에 연결할 수 없는 한 Traffic Manager는 모든 요청을 주 지역으로 보냅니다. 이 시점에서 자동으로 보조 지역으로 장애 조치(fail over)됩니다. 장애 조치 라우팅 방법을 구성을 참조하세요.
건강 프로브 . Traffic Manager는 HTTP(또는 HTTPS) 프로브 사용하여 각 지역의 가용성을 모니터링합니다. 프로브는 지정된 URL 경로에 대한 HTTP 200 응답을 확인합니다. 모범 사례로 애플리케이션의 전반적인 상태를 보고하는 엔드포인트를 만들고 상태 프로브에 이 엔드포인트를 사용합니다. 그렇지 않으면 애플리케이션의 중요한 부분이 실제로 실패할 때 프로브가 정상 엔드포인트를 보고할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴참조하세요.
Traffic Manager가 장애 복구 중일 때, 클라이언트가 애플리케이션에 연결할 수 없는 시간이 있습니다. 기간은 다음 요인의 영향을 받습니다.
상태 프로브는 주 지역에 연결할 수 없게 되었음을 감지해야 합니다.
DNS 서버는 DNS TTL(Time-to-Live)에 따라 달라지는 IP 주소에 대해 캐시된 DNS 레코드를 업데이트해야 합니다. 기본 TTL은 300초(5분)이지만 Traffic Manager 프로필을 만들 때 이 값을 구성할 수 있습니다.
자세한 내용은 Traffic Manager 모니터링 참조하세요.
Traffic Manager가 장애 전환되는 경우, 자동 복구를 구현하기보다는 수동 복구를 수행하는 것이 좋습니다. 그렇지 않으면 애플리케이션이 지역 간에 앞뒤로 대칭 이동되는 상황을 만들 수 있습니다. 장애 복구하기 전에 모든 애플리케이션 하위 시스템이 정상인지 확인합니다.
Traffic Manager는 기본 설정으로 자동 장애 복구됩니다. 이를 방지하려면 장애 조치(failover) 이벤트 후 주 지역의 우선 순위를 수동으로 낮춥다. 예를 들어 주 지역이 우선 순위 1이고 보조 지역이 우선 순위 2라고 가정합니다. 장애 조치(failover) 후 기본 지역을 우선 순위 3으로 설정하여 자동 장애 복구(failback)를 방지합니다. 전환할 준비가 되면 다시 우선 순위를 1로 업데이트합니다.
다음 Azure CLI 명령은 우선 순위를 업데이트합니다.
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type externalEndpoints --priority 3
장애 복구 준비가 될 때까지 또 다른 방법으로 엔드포인트를 일시적으로 비활성화하는 것입니다.
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type externalEndpoints --endpoint-status Disabled
장애 조치(failover)의 원인에 따라 지역 내에서 리소스를 다시 배포해야 할 수 있습니다. 장애 복구하기 전에 운영 준비 테스트를 수행합니다. 테스트는 다음과 같은 사항을 확인해야 합니다.
VM이 올바르게 구성됩니다. (필요한 모든 소프트웨어가 설치되고 IIS가 실행되고 있습니다.)
애플리케이션 하위 시스템은 정상입니다.
기능 테스트. 예를 들어 데이터베이스 계층은 웹 계층에서 연결할 수 있습니다.
SQL Server Always On 가용성 그룹 구성
Windows Server 2016 이전에는 SQL Server Always On 가용성 그룹에 도메인 컨트롤러가 필요하며 가용성 그룹의 모든 노드는 동일한 AD(Active Directory) 도메인에 있어야 합니다.
가용성 그룹을 구성하려면 다음을 수행합니다.
최소한 각 지역에 두 개의 도메인 컨트롤러를 배치합니다.
각 도메인 컨트롤러에 고정 IP 주소를 제공합니다.
VPN 만들어 두 가상 네트워크 간의 통신을 사용하도록 설정합니다.
각 가상 네트워크에 대해 도메인 컨트롤러의 IP 주소(두 지역 모두)를 DNS 서버 목록에 추가합니다. 다음 CLI 명령을 사용할 수 있습니다. 자세한 내용은 DNS 서버 변경 을 참조하세요.
az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"두 지역의 SQL Server 인스턴스를 포함하는 WSFC(Windows Server 장애 조치(failover) 클러스터링) 클러스터를 만듭니다.
주 지역과 보조 지역 모두에서 SQL Server 인스턴스를 포함하는 SQL Server Always On 가용성 그룹을 만듭니다. 단계는 'Always On Availability Group'을 원격 Azure 데이터센터(PowerShell)로 확장하는 방법을 참조하십시오.
주 복제본을 주 영역에 배치합니다.
주 지역에 하나 이상의 보조 복제본을 배치합니다. 동기 커밋 및 자동 장애 조치(failover)를 사용하도록 구성합니다.
보조 지역에 하나 이상의 보조 복제본을 배치합니다. 성능상의 이유로 비동기 커밋을 사용하도록 구성합니다. 그렇지 않으면 모든 T-SQL 트랜잭션이 네트워크를 통해 보조 지역으로 왕복할 때까지 기다려야 합니다.
메모
비동기 커밋 복제본은 자동 장애 조치를 지원하지 않습니다.
가용성 고려 사항
복잡한 N 계층 앱을 사용하면 보조 지역에서 전체 애플리케이션을 복제할 필요가 없습니다. 대신 비즈니스 연속성을 지원하는 데 필요한 중요한 하위 시스템을 복제할 수 있습니다.
Traffic Manager는 시스템에서 가능한 오류 지점입니다. Traffic Manager 서비스가 실패하면 클라이언트는 가동 중지 시간 동안 애플리케이션에 액세스할 수 없습니다. Traffic Manager SLA 검토하고 Traffic Manager만 사용하면 고가용성을 위한 비즈니스 요구 사항을 충족하는지 확인합니다. 그렇지 않은 경우 다른 트래픽 관리 솔루션을 장애 복구(failback)로 추가하는 것이 좋습니다. Azure Traffic Manager 서비스가 실패하면 DNS의 CNAME 레코드를 변경하여 다른 트래픽 관리 서비스를 가리킵니다. (이 단계는 수동으로 수행해야 하며 DNS 변경 내용이 전파될 때까지 애플리케이션을 사용할 수 없습니다.)
SQL Server 클러스터의 경우 고려해야 할 두 가지 장애 조치(failover) 시나리오가 있습니다.
주 지역의 모든 SQL Server 데이터베이스 복제본이 실패합니다. 예를 들어 지역 가동 중단 중에 발생할 수 있습니다. 이 경우 Traffic Manager가 프런트 엔드에서 자동으로 장애 조치(failover)되는 경우에도 가용성 그룹을 수동으로 장애 조치(failover)해야 합니다. SQL Server 2016에서 SQL Server Management Studio, Transact-SQL 또는 PowerShell을 사용하여 강제 장애 조치(failover)를 수행하는 방법을 설명하는 SQL Server 가용성 그룹강제 수동 장애 조치 수행의 단계를 따릅니다.
경고
강제 장애 조치(failover)를 사용하면 데이터가 손실될 위험이 있습니다. 주 지역이 다시 온라인 상태가 되면 데이터베이스의 스냅샷을 만들고 tablediff 사용하여 차이점을 찾습니다.
Traffic Manager는 보조 지역으로 장애 조치하지만 주 SQL Server 데이터베이스 복제본은 여전히 사용할 수 있습니다. 예를 들어 프런트 엔드 계층은 SQL Server VM에 영향을 주지 않고 실패할 수 있습니다. 이 경우 인터넷 트래픽은 보조 지역으로 라우팅되며 해당 지역은 주 복제본에 계속 연결할 수 있습니다. 그러나 SQL Server 연결이 지역 간에 진행되므로 대기 시간이 증가합니다. 이 경우 다음과 같이 수동 장애 조치(failover)를 수행해야 합니다.
보조 지역의 SQL Server 데이터베이스 복제본을 동기 커밋으로 일시적으로 전환합니다. 이렇게 하면 장애 조치(failover) 중에 데이터 손실이 발생하지 않습니다.
해당 복제본으로 장애 조치 전환(failover)합니다.
주 지역으로 복구할 때 비동기 커밋 설정을 원래대로 복원하십시오.
관리 효율성 고려 사항
배포를 업데이트할 때 한 번에 하나의 지역을 업데이트하여 애플리케이션의 잘못된 구성 또는 오류로 인한 전역 오류 가능성을 줄입니다.
오류에 대한 시스템의 복원력을 테스트합니다. 테스트할 몇 가지 일반적인 오류 시나리오는 다음과 같습니다.
VM 인스턴스를 종료합니다.
CPU 및 메모리와 같은 리소스를 압박합니다.
네트워크 연결 끊기/지연
충돌 프로세스.
인증서를 만료합니다.
하드웨어 오류를 시뮬레이션합니다.
도메인 컨트롤러에서 DNS 서비스를 종료합니다.
복구 시간을 측정하고 비즈니스 요구 사항을 충족하는지 확인합니다. 실패 모드의 조합도 테스트합니다.
다음 단계
- Azure 클라우드 패턴에 대한 자세한 내용은 클라우드 디자인 패턴참조하세요.