Yüksek kullanılabilirlik için birden fazla Azure bölgesinde bir web uygulamasını çalıştırmaRun a web application in multiple Azure regions for high availability

Bu başvuru mimarisinde, yüksek kullanılabilirlik sağlamak üzere bir Azure App Service uygulamasını birden çok bölgede nasıl kullanabileceğiniz açıklanmaktadır.This reference architecture shows how to run an Azure App Service application in multiple regions to achieve high availability.

Yüksek kullanılabilirliğe sahip web uygulaması için başvuru mimarisi

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

MimariArchitecture

Bu mimari için Bir web uygulamasında ölçeklenebilirliği geliştirme makalesinde gösterilen mimari temel alınmıştır.This architecture builds on the one shown in Improve scalability in a web application. Temel farklılıklar şunlardır:The main differences are:

  • Birincil ve ikincil bölgeler.Primary and secondary regions. Bu mimari yüksek kullanılabilirlik elde etmek için iki bölge kullanır.This architecture uses two regions to achieve higher availability. Uygulama her bir bölgeye dağıtılır.The application is deployed to each region. Normal işlemler sırasında ağ trafiği birincil bölgeye yönlendirilir.During normal operations, network traffic is routed to the primary region. Birincil bölge kullanılamaz duruma gelirse trafik, ikincil bölgeye yönlendirilir.If the primary region becomes unavailable, traffic is routed to the secondary region.
  • Azure DNS.Azure DNS. Azure DNS, DNS etki alanları için Microsoft Azure altyapısı kullanılarak ad çözümlemesi olanağı sağlayan bir hizmettir.Azure DNS is a hosting service for DNS domains, providing name resolution using Microsoft Azure infrastructure. Etki alanlarınızı Azure'da barındırarak DNS kayıtlarınızı diğer Azure hizmetlerinde kullandığınız kimlik bilgileri, API’ler, araçlar ve faturalarla yönetebilirsiniz.By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services.
  • Azure Traffic Manager.Azure Traffic Manager. Traffic Manager, gelen istekleri birincil bölgeye yönlendirir.Traffic Manager routes incoming requests to the primary region. Bu bölgede çalışan uygulama kullanılamaz duruma gelirse Traffic Manager, yükü ikincil bölgeye devreder.If the application running that region becomes unavailable, Traffic Manager fails over to the secondary region.
  • SQL Veritabanı ve Cosmo DB için Coğrafi çoğaltma.Geo-replication of SQL Database and Cosmos DB.

Ç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.

ÖnerilerRecommendations

Gereksinimleriniz, burada açıklanan mimariden farklı olabilir.Your requirements might differ from the architecture described here. Bu bölümdeki önerileri bir başlangıç noktası olarak kullanın.Use the recommendations in this section as a starting point.

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, Doğu ABD 2 ve Orta ABD) seçim yapın.In general, choose regions from the same regional pair (for example, East US 2 and Central US). 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.
  • Çoğu durumda, veri yerleşikliğinin karşılanması için çiftler aynı coğrafyada yer alır.In most cases, regional 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.However, make sure that both regions support all of the Azure services needed for your application. Bkz. Bölgelere göre hizmetler.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): Eşleştirilmiş Azure Bölgeleri.For more information about regional pairs, see Business continuity and disaster recovery (BCDR): Azure Paired Regions.

Kaynak gruplarıResource groups

Birincil bölge, ikincil bölge ve Traffic Manager’ı ayrı kaynak gruplarına yerleştirmeyi göz önünde bulundurun.Consider placing the primary region, secondary region, and Traffic Manager into separate resource groups. Bu, her bir bölgeye dağıtılan kaynakları tek bir koleksiyon olarak yönetmenize olanak sağlar.This lets you manage the resources deployed to each region as a single collection.

Traffic Manager yapılandırmasıTraffic Manager configuration

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, bu bölge için uç nokta 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 endpoint for that 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 uç noktanın kullanılabilirliğini izlemek için HTTP (veya HTTPS) araştırmasını kullanır.Traffic Manager uses an HTTP (or HTTPS) probe to monitor the availability of each endpoint. Araştırma Traffic Manager’a ikincil bölgeye yük devretmeye yönelik bir başarılı/başarısız testi uygular.The probe gives Traffic Manager a pass/fail test for failing over to the secondary region. Belirtilen URL yoluna bir istek göndererek çalışır.It works by sending a request to a specified URL path. Bir zaman aşımı dönemi içinde 200 olmayan bir yanıt alırsa araştırma başarısız olur.If it gets a non-200 response within a timeout period, the probe fails. Dört başarısız istekten sonra, Traffic Manager uç noktayı düzeyi düşürülmüş olarak işaretler ve diğer uç noktaya yük devreder.After four failed requests, Traffic Manager marks the endpoint as degraded and fails over to the other endpoint. Ayrıntılar için bkz. Traffic Manager uç nokta izleme ve yük devretme.For details, see Traffic Manager endpoint monitoring and failover.

En iyi uygulama olarak, uygulamanın genel durumunu raporlayan bir sistem durumu araştırma uç noktası oluşturun ve durum yoklaması için bu uç noktayı kullanın.As a best practice, create a health probe endpoint that reports the overall health of the application and use this endpoint for the health probe. Uç nokta App Service uygulamaları, depolama kuyruğu ve SQL Veritabanı gibi kritik bağımlılıkları kontrol etmelidir.The endpoint should check critical dependencies such as the App Service apps, storage queue, and SQL Database. 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.

Diğer taraftan, sistem durumu araştırmasını düşük öncelikli hizmetleri kontrol etmek için kullanmayın.On the other hand, don't use the health probe to check lower priority services. Örneğin, bir e-posta hizmeti devre dışı kalırsa uygulama ikinci bir sağlayıcıya geçebilir veya e-postaları daha sonradan gönderebilir.For example, if an email service goes down the application can switch to a second provider or just send emails later. Bu, uygulamanın yük devretmesi için yeterince yüksek bir öncelik değildir.This is not a high enough priority to cause the application to fail over. Daha fazla bilgi için sistem durumu uç nokta izleme düzeni.For more information, see the Health Endpoint Monitoring pattern.

SQL VeritabanıSQL Database

Farklı bir bölgede okunabilir ikincil bir çoğaltma oluşturmak için Etkin Coğrafi Çoğaltma’yı kullanın.Use Active Geo-Replication to create a readable secondary replica in a different region. En fazla dört okunabilir ikincil çoğaltma olabilir.You can have up to four readable secondary replicas. Birincil veritabanınız başarısız olursa veya çevrimdışı yapılması gerekiyorsa, ikincil bir veritabanına yük devredin.Fail over to a secondary database if your primary database fails or needs to be taken offline. Etkin Coğrafi Çoğaltma herhangi bir elastik veritabanı havuzundaki herhangi bir veritabanı için yapılandırılabilir.Active Geo-Replication can be configured for any database in any elastic database pool.

Cosmos DBCosmos DB

Cosmos DB çok yöneticili (birden çok yazma bölgeleri) ile bölgeler arasında coğrafi çoğaltmayı destekler.Cosmos DB supports geo-replication across regions with multi-master (multiple write regions). Alternatif olarak, tek bir bölge yazılabilir bölge ve diğer salt okunur çoğaltmalar olarak belirleyebilirsiniz.Alternatively, you can designate one region as the writable region and the others as read-only replicas. Bölgesel bir kesinti varsa, farklı bir bölgeyi yazma bölgesi olarak seçerek yük devredebilirsiniz.If there is a regional outage, you can fail over by selecting another region to be the write region. İstemci SDK’sı yazma isteklerini otomatik olarak geçerli yazma bölgesine gönderir, bu nedenle bir yük devretmeden sonra istemci yapılandırmasını güncelleştirmeniz gerekmez.The client SDK automatically sends write requests to the current write region, so you don't need to update the client configuration after a failover. Daha fazla bilgi için Azure Cosmos DB ile genel veri dağıtım.For more information, see Global data distribution with Azure Cosmos DB.

Not

Tüm çoğaltmalar aynı kaynak grubuna aittir.All of the replicas belong to the same resource group.

DepolamaStorage

Azure Depolama için, okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) kullanın.For Azure Storage, use read-access geo-redundant storage (RA-GRS). RA-GRS depolaması ile, veriler ikincil bir bölgeye çoğaltılır.With RA-GRS storage, the data is replicated to a secondary region. İkincil bölgedeki verilere ayrı bir uç nokta üzerinden salt okunur erişiminiz vardır.You have read-only access to the data in the secondary region through a separate endpoint. Bölgesel bir kesinti veya olağanüstü bir durum varsa, Azure Depolama ekibi ikincil bölgeye coğrafi olarak yük devretme gerçekleştirmeye karar verebilir.If there is a regional outage or disaster, the Azure Storage team might decide to perform a geo-failover to the secondary region. Bu yük devretme için herhangi bir müşteri eylemi gerekli değildir.There is no customer action required for this failover.

Kuyruk depolama için, ikincil bölgede bir yedek kuyruk oluşturun.For Queue storage, create a backup queue in the secondary region. Yük devretme sırasında, uygulama birincil bölge tekrar kullanılabilir olana kadar yedek kuyruğu kullanabilir.During failover, the app can use the backup queue until the primary region becomes available again. Bu şekilde, uygulama yine de yeni istekleri işleyebilir.That way, the application can still process new requests.

Kullanılabilirlik dikkat edilmesi gerekenler - Traffic ManagerAvailability considerations - Traffic Manager

Birincil bölge kullanılamaz hale gelirse Traffic Manager otomatik olarak yük devreder.Traffic Manager automatically fails over if the primary region becomes unavailable. 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 veri merkezinde ulaşılamaz hale geldiğini algılamalıdır.The health probe must detect that the primary datacenter has become unreachable.
  • Etki alanı adı hizmeti (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.Domain name service (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 sistemde olası bir hata noktasıdır.Traffic Manager is a possible failure point in the system. Hizmet başarısız olursa istemciler, kapalı kalma süresinde uygulamanıza erişemez.If the service fails, clients cannot access your application during the downtime. Traffic Manager hizmet düzeyi sözleşmesini (SLA) 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 service level agreement (SLA) and determine whether using Traffic Manager alone meets your business requirements for high availability. Aksi durumda, bir geri dönüş 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 fallback. Azure Traffic Manager hizmeti başarısız olursa, DNS’teki kurallı ad (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 canonical name (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.

Kullanılabilirlik dikkat edilmesi gerekenler - SQL veritabanıAvailability Considerations - SQL Database

SQL Veritabanı için kurtarma noktası hedefi (RPO) ve tahmini kurtarma noktası süresi (ERT) Azure SQL Veritabanı'nda iş sürekliliğine genel bakış bölümünde belgelenmiştir.The recovery point objective (RPO) and estimated recovery time (ERT) for SQL Database are documented in Overview of business continuity with Azure SQL Database.

Kullanılabilirlik dikkat edilmesi gerekenler - depolamaAvailability Considerations - Storage

RA-GRS depolaması dayanıklı depolama sağlar ancak bir kesinti sırasında olabilecekleri anlamak önemlidir:RA-GRS storage provides durable storage, but it's important to understand what can happen during an outage:

  • Bir depolama kesintisi yaşanırsa, verilere yazma erişimine sahip olmadığınız bir dönem bulunur.If a storage outage occurs, there will be a period of time when you don't have write-access to the data. Kesinti sırasında ikincil uç noktadan verileri okumaya devam edebilirsiniz.You can still read from the secondary endpoint during the outage.

  • Birincil konumu etkileyen bölgesel bir kesinti veya olağanüstü bir durum varsa ve veriler kurtarılamıyorsa, Azure Depolama ekibi ikincil bölgeye coğrafi olarak yük devretme gerçekleştirmeye karar verebilir.If a regional outage or disaster affects the primary location and the data there cannot be recovered, the Azure Storage team may decide to perform a geo-failover to the secondary region.

  • İkincil bölgeye veri çoğaltma işlemi zaman uyumsuz olarak gerçekleştirilir.Data replication to the secondary region is performed asynchronously. Bu nedenle, bir coğrafi olarak yük devretme gerçekleştirilirse, birincil bölgeden verilerin kurtarılamaması durumunda bazı veriler kaybolabilir.Therefore, if a geo-failover is performed, some data loss is possible if the data can't be recovered from the primary region.

  • Ağ kesintisi gibi geçici hatalar bir depolama yük devretme işlemini tetiklemez.Transient failures, such as a network outage, will not trigger a storage failover. Uygulamanızı geçici hatalara karşı dayanıklı olarak tasarlayın.Design your application to be resilient to transient failures. Olası risk azaltmaları:Possible mitigations:

    • İkinci bölgeden okuyun.Read from the secondary region.
    • Yeni yazma işlemleri (örneğin kuyruk iletilerine) için geçici olarak başka bir depolama hesabına geçin.Temporarily switch to another storage account for new write operations (for example, to queue messages).
    • İkincil bölgeden verileri başka bir depolama hesabına kopyalayın.Copy data from the secondary region to another storage account.
    • Sistem yeniden çalışana kadar azaltılmış işlev sağlayın.Provide reduced functionality until the system fails back.

Daha fazla bilgi için bkz. Azure Depolama kesintisi oluşursa yapmanız gerekenler.For more information, see What to do if an Azure Storage outage occurs.

Yönetilebilirlik dikkat edilmesi gerekenler - Traffic ManagerManageability Considerations - Traffic Manager

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.

Aşağıdaki komutlar önceliği güncelleştirir.The following commands update the priority.

PowerShellPowerShell

$endpoint = Get-AzureRmTrafficManagerEndpoint -Name <endpoint> -ProfileName <profile> -ResourceGroupName <resource-group> -Type AzureEndpoints
$endpoint.Priority = 3
Set-AzureRmTrafficManagerEndpoint -TrafficManagerEndpoint $endpoint

Daha fazla bilgi için bkz. Azure Traffic Manager Cmdlet’leri.For more information, see Azure Traffic Manager Cmdlets.

Azure CLIAzure CLI

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

Yönetilebilirlik dikkat edilmesi gerekenler - SQL veritabanıManageability Considerations - SQL Database

Birincil veritabanı başarısız olursa, el ile ikincil veritabanına yük devretme gerçekleştirin.If the primary database fails, perform a manual failover to the secondary database. Bkz. Bir Azure SQL Veritabanını geri yükleme veya ikincil veritabanına yük devretme.See Restore an Azure SQL Database or failover to a secondary. Siz yük devredene kadar ikincil veritabanı salt okunur durumda kalır.The secondary database remains read-only until you fail over.