고가용성을 위해 여러 Azure Stack 허브 지역에서 N 계층 응용 프로그램 실행Run an N-tier application in multiple Azure Stack Hub regions for high availability

이 참조 아키텍처는 가용성 및 강력한 재해 복구 인프라를 실현 하기 위해 N 계층 응용 프로그램에서 여러 Azure Stack 허브 지역에 걸쳐 실행 되는 검증 된 사례 집합을 보여 줍니다.This reference architecture shows a set of proven practices for running across an N-tier application multiple Azure Stack Hub regions, in order to achieve availability and a robust disaster recovery infrastructure. 이 문서에서는 Traffic Manager를 사용 하 여 고가용성을 구현 하지만 Traffic Manager 사용자 환경에서 선호 하는 옵션이 아닌 경우 항상 사용 가능한 부하 분산 장치 쌍이에서 대체 될 수도 있습니다.In this document, Traffic Manager is used to achieve high availability, however if Traffic Manager is not a preferred choice in your environment, a pair of highly available load balancers could also be substituted in.

참고

아래 아키텍처에서 사용 되는 Traffic Manager은 Azure에서 구성 해야 하며, Traffic Manager 프로필을 구성 하는 데 사용 되는 끝점은 공개적으로 라우팅할 수 있는 Ip 여야 합니다.Please note the Traffic Manager used in the architecture below needs to be configured in Azure and the endpoints used to configure the Traffic Manager profile need to be publicly routable IPs.

ArchitectureArchitecture

이 아키텍처는 SQL Server를 통한 N 계층 애플리케이션에 나와 있는 아키텍처를 기반으로 합니다.This architecture builds on the one shown in N-tier application with SQL Server.

Azure N 계층 애플리케이션에 대해 고가용성 네트워크 아키텍처

  • 주 지역 및 보조 지역.Primary and secondary regions. 더 높은 가용성을 달성하기 위해 두 개의 지역을 사용합니다.Use two regions to achieve higher availability. 하나는 주 지역입니다.One is the primary region. 다른 하나는 장애 조치(failover)를 위한 지역입니다.The other region is for failover.

  • Azure Traffic Manager.Azure Traffic Manager. Traffic Manager는 들어오는 요청을 이 지역 중 하나에 라우팅합니다.Traffic Manager routes incoming requests to one of the regions. 정상 작동 중에는 요청을 주 지역으로 라우팅합니다.During normal operations, it routes requests to the primary region. 이 지역을 사용할 수 없게 되면 Traffic Manager가 보조 지역으로 장애 조치(failover)합니다.If that region becomes unavailable, Traffic Manager fails over to the secondary region. 자세한 내용은 Traffic Manager 구성 섹션을 참조하세요.For more information, see the section Traffic Manager configuration.

  • 리소스 그룹.Resource groups. 주 지역, 보조 지역에 대 한 별도의 리소스 그룹 을 만듭니다.Create separate resource groups for the primary region, the secondary region. 따라서 각 지역을 단일 리소스 모음으로 유연하게 관리할 수 있습니다.This gives you the flexibility to manage each region as a single collection of resources. 예를 들어 다른 지역으로 이동하지 않고 한 지역을 다시 배포할 수 있습니다.For example, you could redeploy one region, without taking down the other one. 리소스 그룹을 연결하므로 애플리케이션의 모든 리소스를 나열하는 쿼리를 실행할 수 있습니다.Link the resource groups, so that you can run a query to list all the resources for the application.

  • 가상 네트워크.Virtual networks. 각 지역에 대해 별도의 가상 네트워크를 만듭니다.Create a separate virtual network for each region. 주소 공간이 겹치지 않도록 합니다.Make sure the address spaces do not overlap.

  • Always On 가용성 그룹을 SQL Server 합니다.SQL Server Always On Availability Group. SQL Server를 사용하는 경우 고가용성을 위해 SQL Always On 가용성 그룹을 사용하는 것이 좋습니다.If you are using SQL Server, we recommend SQL Always On Availability Groups for high availability. 두 지역 모두에 SQL Server 인스턴스를 포함하는 단일 가용성 그룹을 만듭니다.Create a single availability group that includes the SQL Server instances in both regions.

  • VNET 간 VPN 연결 입니다.VNET to VNET VPN Connection. VNet 피어링을 Azure Stack 허브에서 아직 사용할 수 없으므로 두 개의 Vnet를 연결 하기 위해 VNET 간 VPN 연결을 사용 합니다.As VNET Peering is not yet available on Azure Stack Hub, use VNET to VNET VPN connection in order to connect the two VNETs. 자세한 내용은 Azure Stack 허브의 vnet 간 vnet을 참조 하세요.Please see VNET to VNET in Azure Stack Hub for more information.

권장 사항Recommendations

다중 지역 아키텍처는 단일 지역에 배포하는 것보다 더 높은 가용성을 제공할 수 있습니다.A multi-region architecture can provide higher availability than deploying to a single region. 지역 가동 중단이 주 지역에 영향을 주는 경우 Traffic Manager를 사용하여 보조 지역으로 장애 조치(failover)할 수 있습니다.If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region. 이 아키텍처는 애플리케이션의 개별 하위 시스템이 고장난 경우에도 도움이 될 수 있습니다.This architecture can also help if an individual subsystem of the application fails.

지역에서 고가용성을 달성하는 데 몇 가지 일반적인 접근 방식이 있습니다.There are several general approaches to achieving high availability across regions:

  • 활성/수동 (상시 대기)Active/passive with hot standby. 트래픽이 한 지역으로 이동하면 다른 하나가 상시 대기 상태에서 기다립니다.Traffic goes to one region, while the other waits on hot standby. 상시 대기는 항상 보조 지역의 VM이 할당되고 실행 중이라는 의미입니다.Hot standby means the VMs in the secondary region are allocated and running at all times.

  • 활성/수동 (콜드 대기)Active/passive with cold standby. 트래픽이 한 지역으로 이동하면 다른 하나가 수동 대기에서 기다립니다.Traffic goes to one region, while the other waits on cold standby. 수동 대기는 장애 조치(failover)에 필요할 때까지 보조 지역의 VM이 할당되지 않는다는 것입니다.Cold standby means the VMs in the secondary region are not allocated until needed for failover. 이 방법은 실행하는 데 비용이 덜 들지만, 일반적으로 실패 상태에 있을 때 온라인 상태가 되는 데 더 오래 시간이 걸립니다.This approach costs less to run, but will generally take longer to come online during a failure.

  • 활성/활성 입니다.Active/active. 두 지역 모두 활성화되어 있으며, 요청이 두 지역 사이에서 부하 분산됩니다.Both regions are active, and requests are load balanced between them. 한 지역을 사용할 수 없게 되면 회전이 중단됩니다.If one region becomes unavailable, it is taken out of rotation.

이 참조 아키텍처는 장애 조치(failover)를 위해 Traffic Manager를 사용하여 활성/수동(상시 대기)을 중점적으로 다룹니다.This reference architecture focuses on active/passive with hot standby, using Traffic Manager for failover. 상시 대기에 적은 수의 Vm을 배포 하 고 필요에 따라 확장할 수 있습니다.You could deploy a small number of VMs for hot standby and then scale out as needed.

Traffic Manager 구성Traffic Manager configuration

Traffic Manager를 구성할 때 다음 사항을 고려합니다.Consider the following points when configuring Traffic Manager:

  • 라우팅.Routing. Traffic Manager는 여러 라우팅 알고리즘을 지원합니다.Traffic Manager supports several routing algorithms. 이 문서에 설명된 시나리오는 우선 순위 라우팅(이전에는 장애 조치(failover) 라우팅이라고 함)을 사용합니다.For the scenario described in this article, use priority routing (formerly called failover routing). 이 설정을 사용하면 Traffic Manager가 주 지역에 연결할 수 없는 경우가 아닌 한 모든 요청을 주 지역으로 보냅니다.With this setting, Traffic Manager sends all requests to the primary region, unless the primary region becomes unreachable. 이때 자동으로 보조 지역으로 장애 조치(failover)됩니다.At that point, it automatically fails over to the secondary region. 장애 조치(failover) 라우팅 방법 구성을 참조하세요.See Configure Failover routing method.

  • 상태 프로브.Health probe. Traffic Manager는 HTTP(또는 HTTPS) 프로브를 사용하여 각 지역의 가용성을 모니터링합니다.Traffic Manager uses an HTTP (or HTTPS) probe to monitor the availability of each region. 프로브는 지정된 URL 경로에 대한 HTTP 200 응답을 확인합니다.The probe checks for an HTTP 200 response for a specified URL path. 애플리케이션의 전반적인 상태를 보고하고 이 엔드포인트를 상태 프로브에 사용하는 엔드포인트를 생성하는 것이 좋습니다.As a best practice, create an endpoint that reports the overall health of the application, and use this endpoint for the health probe. 그렇지 않으면 애플리케이션의 중요한 부분이 실제로 실패할 때 프로브에서 정상 엔드포인트를 보고할 수 있습니다.Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing. 자세한 내용은 상태 끝점 모니터링 패턴을 참조 하세요.For more information, see Health Endpoint Monitoring pattern.

Traffic Manager가 장애 조치(failover)할 때 클라이언트가 애플리케이션에 연결할 수 없는 기간이 있습니다.When Traffic Manager fails over there is a period of time when clients cannot reach the application. 그 기간은 다음과 같은 요인에 의해 영향을 받습니다.The duration is affected by the following factors:

  • 상태 프로브가 주 지역에 연결할 수 없는지 검색해야 합니다.The health probe must detect that the primary region has become unreachable.

  • DNS 서버가 DNS TTL(time-to-live)에 따라 IP 주소에 대해 캐시된 DNS 레코드를 업데이트해야 합니다.DNS servers must update the cached DNS records for the IP address, which depends on the DNS time-to-live (TTL). 기본 TTL은 300초(5분)이지만 Traffic Manager 프로필을 만들 때 이 값을 구성할 수 있습니다.The default TTL is 300 seconds (5 minutes), but you can configure this value when you create the Traffic Manager profile.

자세한 내용은 Traffic Manager 모니터링 정보를 참조하세요.For details, see About Traffic Manager Monitoring.

Traffic Manager가 장애 조치(failover)를 수행하는 경우 자동 장애 복구(failback)를 구현하기 보다는 수동 장애 복구(failback)를 수행하는 것이 좋습니다.If Traffic Manager fails over, we recommend performing a manual failback rather than implementing an automatic failback. 그렇지 않으면 애플리케이션이 지역 간에 앞뒤로 대칭 이동하는 상황이 발생할 수 있습니다.Otherwise, you can create a situation where the application flips back and forth between regions. 장애 복구(failback) 전에 모든 애플리케이션 하위 시스템이 정상 상태인지 확인합니다.Verify that all application subsystems are healthy before failing back.

Traffic Manager는 기본적으로 자동으로 장애를 복구(failback)합니다.Note that Traffic Manager automatically fails back by default. 이를 방지하려면 장애 조치(failover) 이벤트 후 수동으로 주 지역의 우선 순위를 낮춥니다.To prevent this, manually lower the priority of the primary region after a failover event. 예를 들어 주 지역의 우선 순위가 1이고 보조 지역의 우선 순위를 2로 가정합니다.For example, suppose the primary region is priority 1 and the secondary is priority 2. 장애 조치(failover) 후 자동 장애 복구(failback)를 방지하기 위해 주 지역의 우선 순위를 3으로 설정합니다.After a failover, set the primary region to priority 3, to prevent automatic failback. 전환할 준비가 되 면 우선 순위를 1로 업데이트 합니다.When you are ready to switch, back, update the priority to 1.

다음 Azure CLI 명령은 우선 순위를 업데이트합니다.The following Azure CLI command updates the priority:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --priority 3

또 다른 방법은 장애 복구(failback)할 준비가 될 때까지 엔드포인트를 일시적으로 사용하지 않도록 설정하는 것입니다.Another approach is to temporarily disable the endpoint until you are ready to fail back:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --endpoint-status Disabled

장애 조치(failover)의 원인에 따라 한 지역 내에서 리소스를 다시 배포해야 할 수 있습니다.Depending on the cause of a failover, you might need to redeploy the resources within a region. 장애 복구(failback) 전에 운영 준비 상태 테스트를 수행합니다.Before failing back, perform an operational readiness test. 이 테스트는 다음과 같은 사항을 확인해야 합니다.The test should verify things like:

  • VM이 올바르게 구성되어 있습니다.VMs are configured correctly. 필요한 모든 소프트웨어가 설치되어 있고, IIS가 실행 중인지 확인합니다.(All required software is installed, IIS is running, and so on.)

  • 애플리케이션 하위 시스템이 정상입니다.Application subsystems are healthy.

  • 기능을 테스트합니다.Functional testing. 예를 들어 웹 계층에서 데이터베이스 계층에 연결 가능한지 테스트합니다.(For example, the database tier is reachable from the web tier.)

SQL Server Always On 가용성 그룹 구성Configure SQL Server Always On Availability Groups

Windows Server 2016 이전 버전에서는 SQL Server Always On 가용성 그룹에 항상 도메인 컨트롤러가 필요하며, 가용성 그룹의 모든 노드가 동일한 AD(Active Directory) 도메인에 있어야 합니다.Prior to Windows Server 2016, SQL Server Always On Availability Groups require a domain controller, and all nodes in the availability group must be in the same Active Directory (AD) domain.

가용성 그룹을 구성하려면:To configure the availability group:

  • 최소한 두 개의 도메인 컨트롤러를 각 지역에 배치합니다.At a minimum, place two domain controllers in each region.

  • 각 도메인 컨트롤러에 고정 IP 주소를 지정합니다.Give each domain controller a static IP address.

  • 두 가상 네트워크 간의 통신을 가능 하 게 하는 VPN 을 만듭니다.Create VPN to enable communication between two virtual networks.

  • 각 가상 네트워크에 대해 두 지역의 도메인 컨트롤러 IP 주소를 DNS 서버 목록에 추가 합니다.For each virtual network, add the IP addresses of the domain controllers (from both regions) to the DNS server list. 다음 CLI 명령을 사용할 수 있습니다.You can use the following CLI command. 자세한 내용은 DNS 서버 변경을 참조하세요.For more information, see Change DNS servers.

    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) 클러스터링) 클러스터를 만듭니다.Create a Windows Server Failover Clustering (WSFC) cluster that includes the SQL Server instances in both regions.

  • 주 지역과 보조 지역 모두에서 SQL Server 인스턴스를 포함하는 SQL Server Always On 가용성 그룹을 만듭니다.Create a SQL Server Always On Availability Group that includes the SQL Server instances in both the primary and secondary regions. 단계는 Extending Always On Availability Group to Remote Azure Datacenter (PowerShell)(원격 Azure 데이터 센터에 Always On 가용성 그룹 확장(PowerShell))를 참조하세요.See Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) for the steps.

    • 주 지역에 주 복제본을 배치합니다.Put the primary replica in the primary region.

    • 주 지역에 하나 이상의 보조 복제본을 배치합니다.Put one or more secondary replicas in the primary region. 자동 장애 조치(failover)를 사용하는 동기 커밋을 사용하도록 구성합니다.Configure these to use synchronous commit with automatic failover.

    • 보조 지역에 보조 복제본을 하나 이상 배치합니다.Put one or more secondary replicas in the secondary region. 성능상의 이유로 비동기 커밋을 사용하도록 구성합니다.Configure these to use asynchronous commit, for performance reasons. (그렇지 않은 경우 모든 T-SQL 트랜잭션이 네트워크를 통해 보조 지역으로 왕복하는 동안 기다려야 합니다.)(Otherwise, all T-SQL transactions have to wait on a round trip over the network to the secondary region.)

참고

비동기 커밋 복제본은 자동 장애 조치 (failover)를 지원 하지 않습니다.Asynchronous commit replicas don't support automatic failover.

가용성 고려 사항Availability considerations

복잡한 N 계층 앱에서는 보조 지역에서 전체 애플리케이션을 복제하지 않아도 될 수 있습니다.With a complex N-tier app, you may not need to replicate the entire application in the secondary region. 대신 무중단 업무 방식을 지원하는 데 필요한 중요한 하위 시스템을 복제하기면 하면 됩니다.Instead, you might just replicate a critical subsystem that is needed to support business continuity.

Traffic Manager는 시스템에서 오류가 발생할 수 있는 지점입니다.Traffic Manager is a possible failure point in the system. Traffic Manager 서비스가 실패하면 클라이언트가 가동 중지 시간 동안 애플리케이션에 액세스할 수 없습니다.If the Traffic Manager service fails, clients cannot access your application during the downtime. Traffic Manager SLA를 검토하고 Traffic Manager만 사용하는 것이 고가용성을 위한 비즈니스 요구 사항을 충족하는지 확인합니다.Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. 그렇지 않은 경우 다른 트래픽 관리 솔루션을 장애 복구(Failback)로 추가합니다.If not, consider adding another traffic management solution as a failback. Azure Traffic Manager 서비스가 실패하면 다른 트래픽 관리 서비스를 가리키도록 DNS의 CNAME 레코드를 변경합니다.If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service. (이 단계는 수동으로 수행해야 하며 DNS 변경 사항이 전파될 때까지 애플리케이션을 사용할 수 없습니다.)(This step must be performed manually, and your application will be unavailable until the DNS changes are propagated.)

SQL Server 클러스터의 경우 다음과 같은 두 가지 장애 조치(failover) 시나리오를 고려해야 합니다.For the SQL Server cluster, there are two failover scenarios to consider:

  • 주 지역의 모든 SQL Server 데이터베이스 복제본이 실패합니다.All of the SQL Server database replicas in the primary region fail. 예를 들어 이 장애는 지역 가동 중단 중에 발생할 수 있습니다.For example, this could happen during a regional outage. 그런 경우 Traffic Manager가 자동으로 프런트 엔드에서 장애 조치(failover)하더라도 가용성 그룹을 수동으로 장애 조치(failover)해야 합니다.In that case, you must manually fail over the availability group, even though Traffic Manager automatically fails over on the front end. SQL Server 가용성 그룹의 강제 수동 장애 조치(failover) 수행의 단계를 따릅니다. SQL Server 2016에서 SQL Server Management Studio, Transact-SQL 또는 PowerShell을 사용하여 강제 장애 조치(failover)를 수행하는 방법을 설명합니다.Follow the steps in Perform a Forced Manual Failover of a SQL Server Availability Group, which describes how to perform a forced failover by using SQL Server Management Studio, Transact-SQL, or PowerShell in SQL Server 2016.

    경고

    강제 장애 조치(failover)를 사용하면 데이터가 손실될 위험이 있습니다.With forced failover, there is a risk of data loss. 주 지역이 다시 온라인 상태가 되면 데이터베이스의 스냅샷을 만들고 tablediff를 사용하여 차이점을 찾습니다.Once the primary region is back online, take a snapshot of the database and use tablediff to find the differences.

  • Traffic Manager는 보조 지역으로 장애 조치(failover)하지만 주 SQL Server 데이터베이스 복제본은 계속 사용할 수 있습니다.Traffic Manager fails over to the secondary region, but the primary SQL Server database replica is still available. 예를 들어 SQL Server VM에 영향을 주지 않고 프런트 엔드 계층이 실패할 수 있습니다.For example, the front-end tier might fail, without affecting the SQL Server VMs. 이 경우 인터넷 트래픽은 보조 지역으로 라우팅되며, 해당 지역은 여전히 주 복제본에 연결될 수 있습니다.In that case, Internet traffic is routed to the secondary region, and that region can still connect to the primary replica. 그러나 SQL Server 연결이 지역 간에 이루어지므로 대기 시간이 늘어납니다.However, there will be increased latency, because the SQL Server connections are going across regions. 이 경우 다음과 같이 수동 장애 조치(failover)를 수행해야 합니다.In this situation, you should perform a manual failover as follows:

    1. 보조 지역의 SQL Server 데이터베이스 복제본을 동기 커밋으로 임시 전환합니다.Temporarily switch a SQL Server database replica in the secondary region to synchronous commit. 그러면 장애 조치(failover) 중 데이터 손실이 발생하지 않습니다.This ensures there won't be data loss during the failover.

    2. 해당 복제본으로 장애 조치(failover)합니다.Fail over to that replica.

    3. 주 지역으로 다시 장애 복구(failback)하는 경우 비동기 커밋 설정을 복원합니다.When you fail back to the primary region, restore the asynchronous commit setting.

관리 효율성 고려 사항Manageability considerations

배포를 업데이트할 때는 한 번에 하나의 지역만 업데이트하여 잘못된 구성이나 애플리케이션의 오류로 인한 글로벌 오류 발생 가능성을 줄입니다.When you update your deployment, update one region at a time to reduce the chance of a global failure from an incorrect configuration or an error in the application.

장애에 대한 시스템의 복원력을 테스트합니다.Test the resiliency of the system to failures. 다음은 테스트에 자주 사용되는 몇 가지 일반적인 오류 시나리오입니다.Here are some common failure scenarios to test:

  • VM 인스턴스가 중단됩니다.Shut down VM instances.

  • CPU 및 메모리 같은 리소스 사용을 가중시킵니다.Pressure resources such as CPU and memory.

  • 네트워크 연결을 끊거나 지연시킵니다.Disconnect/delay network.

  • 프로세스가 충돌합니다.Crash processes.

  • 인증서가 만료됩니다.Expire certificates.

  • 하드웨어 오류를 시뮬레이트합니다.Simulate hardware faults.

  • 도메인 컨트롤러에서 DNS 서비스를 중단합니다.Shut down the DNS service on the domain controllers.

복구 시간을 측정하고 비즈니스 요구 사항이 충족되었는지 확인합니다.Measure the recovery times and verify they meet your business requirements. 오류 모드를 조합하여 테스트합니다.Test combinations of failure modes, as well.

다음 단계Next steps