Yüksek kullanılabilirlik için birden çok Azure bölgesinde N katmanlı bir uygulama çalıştırmaRun an N-tier application in multiple Azure regions for high availability

Bu başvuru mimarisi, kullanılabilirlik ve sağlam bir olağanüstü durum kurtarma altyapısı elde etmek için birden çok Azure bölgesinde N katmanlı bir uygulamayı çalıştırmaya yönelik kanıtlanmış bir dizi yöntem gösterir.This reference architecture shows a set of proven practices for running an N-tier application in multiple Azure regions, in order to achieve availability and a robust disaster recovery infrastructure.

Azure N katmanlı uygulamaları için yüksek oranda kullanılabilir ağ mimarisi"

Bu mimarinin bir Visio dosyasını indirin.Download a Visio file of this architecture.

MimariArchitecture

Bu mimari gösterilen bir derleme SQL Server ile N katmanlı uygulama.This architecture builds on the one shown in N-tier application with SQL Server.

  • Birincil ve ikincil bölgeler.Primary and secondary regions. Yüksek kullanılabilirlik elde etmek için iki bölge kullanın.Use two regions to achieve higher availability. Bunlardan biri, birincil bölgedir.One is the primary region. Diğeri yük devretme bölgesidir.The other region is for failover.

  • Azure Traffic Manager.Azure Traffic Manager. Traffic Manager, gelen istekleri bölgelerden birine yönlendirir.Traffic Manager routes incoming requests to one of the regions. Normal işlemler sırasında, istekleri birincil bölgeye yönlendirir.During normal operations, it routes requests to the primary region. Bu bölge kullanılamaz duruma gelirse Traffic Manager, yükü ikincil bölgeye devreder.If that region becomes unavailable, Traffic Manager fails over to the secondary region. Daha fazla bilgi için bkz. Traffic Manager yapılandırması.For more information, see the section Traffic Manager configuration.

  • Kaynak grupları.Resource groups. Birincil bölge, ikincil bölge ve Traffic Manager için ayrı kaynak grupları oluşturun.Create separate resource groups for the primary region, the secondary region, and for Traffic Manager. Bu size her bölgeyi tek bir kaynak koleksiyonu olarak yönetme esnekliği sağlar.This gives you the flexibility to manage each region as a single collection of resources. Örneğin, bir bölgeyi devre dışı bırakmadan diğer bölgeyi yeniden dağıtabilirsiniz.For example, you could redeploy one region, without taking down the other one. Uygulamaya ilişkin tüm kaynakları listelemek üzere sorgu çalıştırabilmek için kaynak gruplarını bağlayın.Link the resource groups, so that you can run a query to list all the resources for the application.

  • Sanal Ağlar.VNets. Her bölge için ayrı bir Sanal Ağ oluşturun.Create a separate VNet for each region. Adres alanlarının çakışmadığından emin olun.Make sure the address spaces do not overlap.

  • SQL Server Always On Kullanılabilirlik Grubu.SQL Server Always On Availability Group. SQL Server kullanıyorsanız yüksek kullanılabilirlik için SQL Server Always On Kullanılabilirlik Grupları önerilir.If you are using SQL Server, we recommend SQL Always On Availability Groups for high availability. Her iki bölgedeki SQL Server örneklerini içeren tek bir kullanılabilirlik grubu oluşturun.Create a single availability group that includes the SQL Server instances in both regions.

    Not

    Ayrıca, bulut hizmet olarak ilişkisel bir veritabanı sağlayan Azure SQL Veritabanı’nı da göz önünde bulundurun.Also consider Azure SQL Database, which provides a relational database as a cloud service. SQL Veritabanı kullanırsanız yük devretme grubu yapılandırmanız veya yük devretmeyi yönetmeniz gerekmez.With SQL Database, you don't need to configure an availability group or manage failover.

  • VPN Ağ Geçitleri.VPN Gateways. Her sanal ağda bir VPN ağ geçidi oluşturun ve iki sanal ağ arasında ağ trafiğini etkinleştirmek için Sanal Ağdan Sanal Ağa bağlantı yapılandırın.Create a VPN gateway in each VNet, and configure a VNet-to-VNet connection, to enable network traffic between the two VNets. Bu, SQL Always On Kullanılabilirlik Grupları için gereklidir.This is required for the SQL Always On Availability Group.

ÖnerilerRecommendations

Çok bölgeli bir mimari, tek bir bölgeye dağıtmaya göre daha yüksek kullanılabilirlik sağlayabilir.A multi-region architecture can provide higher availability than deploying to a single region. Birinci bölge bölgesel bir kesintiden etkileniyorsa, ikinci bölgeye yük devretmek için Traffic Manager kullanabilirsiniz.If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region. Mimari ayrıca tek başına bir alt sistem veya uygulama başarısız olursa da yardımcı olabilir.This architecture can also help if an individual subsystem of the application fails.

Bölgeler arasında yüksek kullanılabilirlik sağlamak için birkaç genel yaklaşım bulunur:There are several general approaches to achieving high availability across regions:

  • Etkin bekleme ile aktif/pasif.Active/passive with hot standby. Trafik bir yöne doğru giderken diğerinin etkin beklemesi.Traffic goes to one region, while the other waits on hot standby. Etkin bekleme, ikinci bölgedeki VM’lerin her zaman ayrılmış ve çalışır olduğu anlamına gelir.Hot standby means the VMs in the secondary region are allocated and running at all times.
  • Etkin olmayan hazırda bekleme.Active/passive with cold standby. Trafik bir yöne doğru giderken diğerinin etkin olmayan hazırda beklemesi.Traffic goes to one region, while the other waits on cold standby. Etkin olmayan hazırda bekleme, ikinci bölgedeki VM’lere yük devretme için gerekli olana kadar bölge atanmayacağı anlamına gelir.Cold standby means the VMs in the secondary region are not allocated until needed for failover. Bu yaklaşımı çalıştırmak daha düşük maliyetlidir ancak bir hata sırasında tekrar çevrimiçi olması genellikle daha uzun sürer.This approach costs less to run, but will generally take longer to come online during a failure.
  • Etkin/etkin.Active/active. İki bölge de etkin ve aralarında yük dengelemesi yapılıyor.Both regions are active, and requests are load balanced between them. Bir bölge kullanılamaz duruma gelirse, döndürme dışına alınır.If one region becomes unavailable, it is taken out of rotation.

Bu başvuru mimarisi, yük devretme için Traffic Manager’ı kullanarak etkin bekleme ile aktif/pasif durumuna odaklanır.This reference architecture focuses on active/passive with hot standby, using Traffic Manager for failover. Etkin bekleme için az sayıda VM dağıtıp sonra ölçeği gerektiği şekilde genişletebileceğinizi unutmayın.Note that you could deploy a small number of VMs for hot standby and then scale out as needed.

Bölgesel eşleştirmeRegional pairing

Her Azure bölgesi aynı coğrafyadaki başka bir bölgeyle eşleştirilir.Each Azure region is paired with another region within the same geography. Genel olarak, bölgeler için aynı bölge çiftinden (örneğin, ABD Doğu 2 ve ABD Orta) seçim yapın.In general, choose regions from the same regional pair (for example, East US 2 and US Central). Bunu yapmanın avantajları şunları içerir:Benefits of doing so include:

  • Geniş kapsamlı bir kesinti durumunda her çiftte en az bir bölgenin kurtarılmasına öncelik verilir.If there is a broad outage, recovery of at least one region out of every pair is prioritized.
  • Olası kapalı kalma süresini en aza indirmek için, planlı Azure sistem güncelleştirmeleri bölge çiftlerine tek tek uygulanır.Planned Azure system updates are rolled out to paired regions sequentially, to minimize possible downtime.
  • Veri yerleşikliğinin karşılanması için çiftler aynı coğrafyada yer alır.Pairs reside within the same geography, to meet data residency requirements.

Ancak uygulamanız için gereken tüm Azure hizmetlerinin her iki bölge tarafından da desteklendiğinden emin olun. (Bkz. Bölgeye göre hizmetler.)However, make sure that both regions support all of the Azure services needed for your application (see Services by region). Bölgesel çiftler hakkında daha fazla bilgi için bkz. iş sürekliliği ve olağanüstü durum kurtarma (BCDR): Azure eşleştirilmiş bölgeleri.For more information about regional pairs, see Business continuity and disaster recovery (BCDR): Azure Paired Regions.

Traffic Manager yapılandırmasıTraffic Manager configuration

Traffic Manager’ı yapılandırırken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when configuring Traffic Manager:

  • Yönlendirme.Routing. Traffic Manager çeşitli yönlendirme algoritmalarını destekler.Traffic Manager supports several routing algorithms. Bu makalede açıklanan senaryo için, öncelikli yönlendirmeyi (eski adıyla yük devretme yönlendirmesini) kullanın.For the scenario described in this article, use priority routing (formerly called failover routing). Bu ayar kullanıldığında, birincil bölge ulaşılamaz duruma gelmediği sürece Traffic Manager tüm istekleri birincil bölgeye gönderir.With this setting, Traffic Manager sends all requests to the primary region, unless the primary region becomes unreachable. Bu noktada, otomatik olarak ikinci bölgeye yük devredilir.At that point, it automatically fails over to the secondary region. Bkz. Yük devretme yönlendirme yöntemini yapılandırma.See Configure Failover routing method.
  • Sistem durumu araştırma.Health probe. Traffic Manager, her bölgenin kullanılabilirliğini izlemek için HTTP (veya HTTPS) yoklamasını kullanır.Traffic Manager uses an HTTP (or HTTPS) probe to monitor the availability of each region. Yoklama, belirtilen bir URL yolu için bir HTTP 200 yanıtının alınıp alınmadığını denetler.The probe checks for an HTTP 200 response for a specified URL path. En iyi uygulama olarak, uygulamanın genel durumunu raporlayan bir uç nokta oluşturun ve durum yoklaması için bu uç noktayı kullanın.As a best practice, create an endpoint that reports the overall health of the application, and use this endpoint for the health probe. Aksi takdirde, gerçekte uygulamanın kritik bölümleri başarısız olduğu halde araştırma uç noktanın sistem durumunun iyi olduğunu raporlayabilir.Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing. Daha fazla bilgi için sistem durumu uç nokta izleme düzeni.For more information, see Health Endpoint Monitoring pattern.

Traffic Manager yük devrettiğinde istemcilerin uygulamaya ulaşamadığı bir zaman dilimi olur.When Traffic Manager fails over there is a period of time when clients cannot reach the application. Bu süre aşağıdaki faktörlerden etkilenir:The duration is affected by the following factors:

  • Durum yoklaması, birincil bölgenin ulaşılamaz hale geldiğini algılamalıdır.The health probe must detect that the primary region has become unreachable.
  • DNS sunucuları, önbelleğe alınan DNS kayıtlarını IP adresi için güncelleştirmelidir; bu, DNS yaşam süresine (TTL) bağlıdır.DNS servers must update the cached DNS records for the IP address, which depends on the DNS time-to-live (TTL). Varsayılan TTL 300 saniyedir (5 dakika), ancak Traffic Manager profilini oluştururken bu değeri yapılandırabilirsiniz.The default TTL is 300 seconds (5 minutes), but you can configure this value when you create the Traffic Manager profile.

Ayrıntılar için bkz. Traffic Manager İzleme Hakkında.For details, see About Traffic Manager Monitoring.

Traffic Manager yük devrederse, otomatik bir yeniden çalışma uygulamak yerine el ile bir yeniden çalışma gerçekleştirmenizi öneririz.If Traffic Manager fails over, we recommend performing a manual failback rather than implementing an automatic failback. Aksi takdirde, uygulamanın bölgeler arasında sürekli olarak geçiş yaptığı bir durum oluşturabilirsiniz.Otherwise, you can create a situation where the application flips back and forth between regions. Yeniden çalıştırmadan önce tüm uygulama alt sistemlerinin iyi durumda olduğunu doğrulayın.Verify that all application subsystems are healthy before failing back.

Traffic Manager’ın varsayılan olarak otomatik yeniden çalışma gerçekleştirdiğine dikkat edin.Note that Traffic Manager automatically fails back by default. Bunu önlemek için, bir yük devretme olayından sonra birinci bölgenin önceliğini el ile düşürün.To prevent this, manually lower the priority of the primary region after a failover event. Örneğin, birincil bölge öncelik 1 ve ikincil bölge öncelik 2 değerine sahip olsun.For example, suppose the primary region is priority 1 and the secondary is priority 2. Bir yük devretmeden sonra, otomatik yeniden çalışmayı önlemek için birincil bölgenin önceliğini 3 olarak ayarlayın.After a failover, set the primary region to priority 3, to prevent automatic failback. Geri geçiş yapmak için hazır olduğunuzda, önceliği 1 olarak güncelleştirin.When you are ready to switch back, update the priority to 1.

Şu Azure CLI komutu, önceliği güncelleştirir: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 azureEndpoints --priority 3

Diğer bir yöntem de ilk duruma döndürmeye hazır olana kadar uç noktayı devre dışı bırakmaktır: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 azureEndpoints --endpoint-status Disabled

Yük devretme nedenine bağlı olarak, bir bölgede kaynakları yeniden dağıtmanız gerekebilir.Depending on the cause of a failover, you might need to redeploy the resources within a region. İlk duruma döndürmeden önce bir işlemsel hazırlık testi gerçekleştirin.Before failing back, perform an operational readiness test. Test aşağıdaki gibi durumları doğrulamalıdır:The test should verify things like:

  • VM’lerin doğru şekilde yapılandırılmış olması.VMs are configured correctly. (Gerekli olan tüm yazılımların yüklenmiş olması, IIS’nin çalışıyor olması vb.)(All required software is installed, IIS is running, and so on.)
  • Uygulama alt sistemlerinin iyi durumda olması.Application subsystems are healthy.
  • İşlevsel test.Functional testing. (Örneğin, web katmanından veritabanı katmanına ulaşılabilmesi.)(For example, the database tier is reachable from the web tier.)

SQL Server Always On Kullanılabilirlik Grupları yapılandırmaConfigure SQL Server Always On Availability Groups

Windows Server 2016’dan önceki sürümlerde SQL Server Always On Kullanılabilirlik Grupları bir etki alanı denetleyicisi gerektirir ve kullanılabilirlik grubundaki tüm düğümler aynı Active Directory (AD) etki alanında olmalıdır.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.

Kullanılabilirlik grubunu yapılandırmak için:To configure the availability group:

  • Her bir bölgeye en az iki etki alanı denetleyicisi yerleştirin.At a minimum, place two domain controllers in each region.

  • Her etki alanı denetleyicisine statik bir IP adresi verin.Give each domain controller a static IP address.

  • Sanal ağlar arasındaki iletişimi etkinleştirmek için sanal ağdan sanal ağa bağlantı oluşturun.Create a VNet-to-VNet connection to enable communication between the VNets.

  • Her sanal ağ için her iki bölgedeki etki alanı denetleyicisinin IP adresini DNS sunucu listesine ekleyin.For each VNet, add the IP addresses of the domain controllers (from both regions) to the DNS server list. Aşağıdaki CLI komutunu kullanabilirsiniz.You can use the following CLI command. Daha fazla bilgi için değişiklik DNS sunucuları.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"
    
  • Her iki bölgedeki SQL Server örneklerini içeren bir Windows Server Yük Devretme Kümelemesi (WSFC) oluşturun.Create a Windows Server Failover Clustering (WSFC) cluster that includes the SQL Server instances in both regions.

  • Hem birincil hem de ikincil bölgedeki SQL Server örneklerini içeren bir SQL Server Always On Kullanılabilirlik Grubu oluşturun.Create a SQL Server Always On Availability Group that includes the SQL Server instances in both the primary and secondary regions. Adımlar için bkz. Always On Kullanılabilirlik Grubu’nu Uzak Azure Veri Merkezine Genişletme (PowerShell).See Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) for the steps.

    • Birincil çoğaltmayı birincil bölgeye yerleştirin.Put the primary replica in the primary region.

    • Birincil bölgeye bir veya daha fazla ikincil çoğaltma yerleştirin.Put one or more secondary replicas in the primary region. Bunları otomatik yük devretme ile zaman uyumlu yürütme kullanacak şekilde yapılandırın.Configure these to use synchronous commit with automatic failover.

    • İkincil bölgeye bir veya daha fazla ikincil çoğaltma yerleştirin.Put one or more secondary replicas in the secondary region. Bunları performans açısından iyi olan zaman uyumsuz yürütme kullanacak şekilde yapılandırın.Configure these to use asynchronous commit, for performance reasons. (Aksi takdirde, tüm T-SQL işlemlerinin ağ üzerinden ikincil bölgeye gidiş dönüş için beklemesi gerekir.)(Otherwise, all T-SQL transactions have to wait on a round trip over the network to the secondary region.)

      Not

      Zaman uyumsuz işleme çoğaltmaları otomatik yük devretmeyi desteklemez.Asynchronous commit replicas do not support automatic failover.

Kullanılabilirlik konusunda dikkat edilmesi gerekenlerAvailability considerations

Karmaşık N katmanlı bir uygulama ile ikincil bölgede tüm uygulamayı çoğaltmanız gerekmeyebilir.With a complex N-tier app, you may not need to replicate the entire application in the secondary region. Bunun yerine, yalnızca iş sürekliliğinin desteklenmesi için gerekli önemli bir alt sistemi çoğaltabilirsiniz.Instead, you might just replicate a critical subsystem that is needed to support business continuity.

Traffic Manager sistemde olası bir hata noktasıdır.Traffic Manager is a possible failure point in the system. Traffic Manager hizmeti başarısız olursa istemciler, kapalı kalma süresinde uygulamanıza erişemez.If the Traffic Manager service fails, clients cannot access your application during the downtime. Traffic Manager SLA’sını gözden geçirin ve yalnızca Traffic Manager kullanımıyla, yüksek kullanılabilirliğe ilişkin iş gereksinimlerinizin karşılanıp karşılanmadığını belirleyin.Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. Aksi durumda, yeniden çalıştırma çözümü olarak başka bir trafik yönetim çözümü eklemeyi göz önünde bulundurun.If not, consider adding another traffic management solution as a failback. Azure Traffic Manager hizmeti başarısız olursa, DNS’teki CNAME kayıtlarınızı diğer trafik yönetimi hizmetini gösterecek şekilde değiştirin.If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service. (Bu adımın el ile uygulanması gerekir ve uygulamanız DNS değişiklikleri yayılana kadar kullanılamaz.)(This step must be performed manually, and your application will be unavailable until the DNS changes are propagated.)

SQL Server kümesi için dikkate alınması gereken iki yük devretme senaryosu vardır:For the SQL Server cluster, there are two failover scenarios to consider:

  • Birincil bölgedeki tüm SQL Server veritabanı çoğaltmalarının başarısız olması.All of the SQL Server database replicas in the primary region fail. Örneğin, bölgesel bir kesinti sırasında bu durum meydana gelebilir.For example, this could happen during a regional outage. Bu durumda, Traffic Manager otomatik olarak ön uçta yük devretme gerçekleştirse bile kullanılabilirlik grubunun yükünü el ile devretmeniz gerekir.In that case, you must manually fail over the availability group, even though Traffic Manager automatically fails over on the front end. SQL Server 2016’da SQL Server Management Studio, Transact-SQL veya PowerShell kullanarak zorlamalı yük devretme gerçekleştirmeyi açıklayan SQL Server Kullanılabilirlik Grubunun Yükünü El ile Zorlamalı Olarak Devretme İşlemi Gerçekleştirme konusundaki adımları izleyin.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.

    Uyarı

    Zorlamalı yük devretme yönteminde veri kaybı riski vardır.With forced failover, there is a risk of data loss. Birincil bölge yeniden çevrimiçi olduğunda, veritabanının anlık görüntüsünü alın ve farkları bulmak için tablediff’i kullanın.Once the primary region is back online, take a snapshot of the database and use tablediff to find the differences.

  • Traffic Manager ikincil bölgeye yük devretme gerçekleştirir, ancak birincil SQL Server veritabanı çoğaltması kullanılabilir kalır.Traffic Manager fails over to the secondary region, but the primary SQL Server database replica is still available. Örneğin, ön uç katmanı SQL Server sanal makinelerini etkilemeden başarısız olabilir.For example, the front-end tier might fail, without affecting the SQL Server VMs. Bu durumda, İnternet trafiği ikincil bölgeye yönlendirilir ve bu bölge birincil çoğaltmaya bağlanmaya devam edebilir.In that case, Internet traffic is routed to the secondary region, and that region can still connect to the primary replica. Ancak, SQL Server bağlantıları bölgeler arasında gerçekleştiğinden gecikme süresi daha yüksek olur.However, there will be increased latency, because the SQL Server connections are going across regions. Bu durumda, aşağıdaki gibi el ile yük devretme gerçekleştirmeniz gerekir:In this situation, you should perform a manual failover as follows:

    1. İkincil bölgedeki bir SQL Server veritabanı çoğaltmasını geçici olarak zaman uyumlu işlemeye geçirin.Temporarily switch a SQL Server database replica in the secondary region to synchronous commit. Bu, yük devretme sırasında veri kaybı olmamasını sağlar.This ensures there won't be data loss during the failover.
    2. Bu çoğaltmaya yük devretme gerçekleştirin.Fail over to that replica.
    3. Birincil bölgede yeniden çalışmaya başladığınızda zaman uyumsuz işleme ayarını geri yükleyin.When you fail back to the primary region, restore the asynchronous commit setting.

Yönetilebilirlik konusunda dikkat edilmesi gerekenlerManageability considerations

Dağıtımınızı güncelleştirdiğinizde, yanlış bir yapılandırma veya uygulamadaki bir hata nedeniyle ortaya çıkabilecek genel hata riskini azaltmak için tek seferde bir uygulamayı güncelleştirin.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.

Sistemin hatalara karşı esnekliğini test edin.Test the resiliency of the system to failures. Test edebileceğiniz bazı yaygın hata senaryoları şunlardır:Here are some common failure scenarios to test:

  • VM örneklerini kapatın.Shut down VM instances.
  • CPU ve bellek gibi baskı kaynakları.Pressure resources such as CPU and memory.
  • Ağın bağlantısını kesin/ağı geciktirin.Disconnect/delay network.
  • İşlemlerde kilitlenme yaratın.Crash processes.
  • Sertifikaların süresinin dolmasını sağlayın.Expire certificates.
  • Donanım hatalarının benzetimini yapın.Simulate hardware faults.
  • Etki alanı denetleyicilerindeki DNS hizmetini kapatın.Shut down the DNS service on the domain controllers.

Kurtarma zamanlarını ölçün ve iş gereksinimlerinizin karşılandığını doğrulayın.Measure the recovery times and verify they meet your business requirements. Hata modlarının birleşimlerini de test edin.Test combinations of failure modes, as well.

Aşağıdaki gözden geçirmek isteyebilirsiniz Azure örnek senaryolar bazı teknolojiler kullanarak özel çözümler göstermektedir:You may wish to review the following Azure example scenarios that demonstrate specific solutions using some of the same technologies: