Azure Uygulaması Hizmetinde Güvenilirlik
Bu makalede, Azure Uygulaması Hizmeti'nde güvenilirlik desteği açıklanır ve hem kullanılabilirlik alanları hem de bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği ile bölgesel dayanıklılık ele alınmaktadır. Azure'daki güvenilirlik ilkelerine daha ayrıntılı bir genel bakış için bkz . Azure güvenilirliği.
Azure Uygulaması Hizmeti, web uygulamalarını, REST API'lerini ve mobil arka uçları barındırmaya yönelik HTTP tabanlı bir hizmettir ve aşağıdakiler gibi Microsoft Azure'ın gücünü uygulamanıza ekler:
- Güvenlik
- Yük dengeleme
- Otomatik ölçeklendirme
- Otomatik yönetim
Azure Uygulaması Hizmetinin uygulama iş yükünüzün güvenilirliğini ve dayanıklılığını nasıl artırabileceğini keşfetmek için bkz. App Service neden kullanılır?
Güvenilirlik önerileri
Bu bölüm dayanıklılık ve kullanılabilirlik elde etmek için öneriler içerir. Her öneri iki kategoriden birine ayrılır:
Sistem durumu öğeleri , Yapılandırma öğeleri ve Azure Kaynak yapılandırma ayarları, diğer hizmetlere bağımlılıklar gibi Azure İş Yükünüzü oluşturan ana bileşenlerin düzgün çalışması gibi alanları kapsar.
Risk öğeleri kullanılabilirlik ve kurtarma gereksinimleri, test, izleme, dağıtım gibi alanları ve çözümlenmemiş bırakılırsa ortamdaki sorun olasılığını artıran diğer öğeleri kapsar.
Güvenilirlik önerileri öncelik matrisi
Her öneri aşağıdaki öncelik matrisi uyarınca işaretlenir:
| Görsel | Öncelik | Açıklama |
|---|---|---|
|
Yüksek | Anında düzeltme gerekiyor. |
|
Orta | 3-6 ay içinde düzeltin. |
|
Düşük | Gözden geçirilmesi gerekiyor. |
Güvenilirlik önerileri özeti
Yüksek kullanılabilirlik
ASP-1 - Alanlar arası yedekli App Service planlarını dağıtma
İş açısından kritik iş yüklerinizin dayanıklılığını ve güvenilirliğini artırmak için yeni App Service Planlarınızı alanlar arası yedeklilik ile dağıtmanız önerilir. Kullanılabilirlik alanı desteğine yeniden dağıtma adımlarını izleyin, yeni App Services Planı'nda WebApp'inizi yeniden dağıtacak şekilde işlem hatlarınızı yapılandırın ve ardından yeni siteye yük devretmek için Mavi-Yeşil dağıtım yaklaşımını kullanın.
Uygulamalarınızı birden çok kullanılabilirlik alanına dağıtarak, veri merkezi düzeyinde bir hata durumunda bile uygulamalarının devam etmesini sağlayabilirsiniz. Azure Uygulaması Hizmeti'nde kullanılabilirlik alanı desteği hakkında daha fazla bilgi için bkz. Kullanılabilirlik alanı desteği.
// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A
resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"
Dayanıklılık
ASP-2 -Kullanılabilirlik alanlarını destekleyen bir App Service planı kullanma
Kullanılabilirlik alanı desteği yalnızca belirli App Service planlarında kullanılabilir. Kullanılabilirlik alanlarını kullanmak için hangi plana ihtiyacınız olduğunu görmek için bkz . Kullanılabilirlik alanı önkoşulları.
// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
tolower(sku_tier) !contains "premium" and
tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)
ASP-4 - Üretim ve test için ayrı App Service planları oluşturma
İş açısından kritik iş yüklerinizin dayanıklılığını ve güvenilirliğini artırmak için mevcut App Service planlarınızı ve App Service Ortamı kullanılabilirlik alanı desteğine geçirmeniz gerekir. Uygulamalarınızı birden çok kullanılabilirlik alanına dağıtarak, veri merkezi düzeyinde bir hata durumunda bile uygulamalarının devam etmesini sağlayabilirsiniz. Azure Uygulaması Hizmeti'nde kullanılabilirlik alanı desteği hakkında daha fazla bilgi için bkz. Kullanılabilirlik alanı desteği.
Ölçeklenebilirlik
ASP-3 - Sık sık ölçeği artırmaktan veya küçültmekten kaçının
Azure Uygulaması Hizmeti örneklerinizin ölçeğini sık sık artırmaktan veya küçültmekten kaçınmanız önerilir. Bunun yerine, tipik iş yükünüzü işleyebilen uygun bir katman ve örnek boyutu seçin ve trafik hacmindeki değişikliklere uyum sağlamak için örneklerin ölçeğini genişletin. Ölçeği artırma veya azaltma, uygulama yeniden başlatmayı tetikleyebilir ve bu da hizmet kesintilerine neden olabilir.
ASP-5 - Hizmet istekleri için yeterli kaynakların kullanılabilir olduğundan emin olmak için Otomatik Ölçeklendirme/Otomatik ölçeklendirmeyi etkinleştirin
Gelen istekleri işlemek için yeterli kaynağın kullanılabilir olduğundan emin olmak için Azure Uygulaması Hizmetiniz için otomatik ölçeklendirmeyi/otomatik ölçeklendirmeyi etkinleştirmeniz önerilir. Otomatik ölçeklendirme kural tabanlı ölçeklendirmedir, otomatik ölçeklendirme ise HTTP trafiğine göre otomatik olarak içeri ve dışarı ölçeklendirme gerçekleştirir. Daha fazla bilgi için bkz. Azure Uygulaması Hizmetinde otomatik ölçeklendirme veya Azure'da otomatik ölçeklendirmeyi kullanmaya başlama.
// under-development
Kullanılabilirlik alanı desteği
Azure kullanılabilirlik alanları, her Azure bölgesindeki en az üç fiziksel ayrı veri merkezi grubudur. Her bölgedeki veri merkezleri bağımsız güç, soğutma ve ağ altyapısı ile donatılmıştır. Yerel bölge hatası durumunda kullanılabilirlik alanları, bir bölge etkileniyorsa, bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik kalan iki bölge tarafından desteklenecek şekilde tasarlanmıştır.
Hatalar, yazılım ve donanım arızalarından deprem, sel ve yangın gibi olaylara kadar değişebilir. Azure hizmetlerinin yedekliliği ve mantıksal yalıtımı ile hatalara dayanıklılık elde edilir. Azure'daki kullanılabilirlik alanları hakkında daha ayrıntılı bilgi için bkz . Bölgeler ve kullanılabilirlik alanları.
Azure kullanılabilirlik alanlarının etkinleştirildiği hizmetler, doğru güvenilirlik ve esneklik düzeyini sağlayacak şekilde tasarlanmıştır. Bunlar iki şekilde yapılandırılabilir. Alanlar arasında otomatik çoğaltma ile alanlar arası yedekli veya belirli bir bölgeye sabitlenmiş örneklerle bölgesel olabilir. Bu yaklaşımları da birleştirebilirsiniz. Bölgesel ve alanlar arası yedekli mimari hakkında daha fazla bilgi için bkz. kullanılabilirlik alanlarını ve bölgelerini kullanmak için Öneriler.
Azure Uygulaması Hizmeti, iş açısından kritik iş yükleriniz için dayanıklılık ve güvenilirlik elde etmeye yardımcı olmak için kullanılabilirlik alanları (AZ) arasında dağıtılabilir. Bu mimari bölge yedekliliği olarak da bilinir.
App Service'i alanlar arası yedekli olarak yapılandırdığınızda platform, Azure Uygulaması Hizmeti planının örneklerini seçilen bölgedeki üç bölgeye otomatik olarak yayar.
Alanlar arası yedekli dağıtımla yayılan örnek, uygulama ölçeği daraltılıp genişletilirken bile aşağıdaki kuralların içinde belirlenir:
- En düşük App Service Planı örnek sayısı üç'tür.
- Üçten büyük bir kapasite belirtirseniz ve örnek sayısı üçe bölünebiliyorsa, örnekler eşit olarak yayılır.
- 3*N'nin ötesindeki tüm örnek sayıları kalan bir veya iki bölgeye yayılır.
Kullanılabilirlik alanı desteği, App Service planının bir özelliğidir. App Service planları, App Service Ortamı v3 kullanılarak yönetilen çok kiracılı ortamda veya ayrılmış ortamda oluşturulabilir. v3 App Service Ortamı hakkında daha fazla bilgi edinmek için bkz. App Service Ortamı v3'e genel bakış.
Alanlar arası yedekli olacak şekilde yapılandırılmamış Uygulama Hizmetleri için, VM örnekleri bölgeye dayanıklı değildir ve bu bölgedeki herhangi bir bölgede kesinti sırasında kapalı kalma süresiyle karşılaşabilir.
Kurumsal dağıtım mimarisi hakkında bilgi için bkz. App Service Ortamı kullanarak yüksek kullanılabilirlik kurumsal dağıtımı.
Önkoşullar
Kullanılabilirlik alanlarını etkinleştirmeye yönelik geçerli gereksinimler/sınırlamalar şunlardır:
Hem Windows hem de Linux desteklenir.
Kullanılabilirlik alanları yalnızca yeni App Service ayak izinde desteklenir. Desteklenen bölgelerden birini kullanıyor olsanız bile, kaynak grubunuz için kullanılabilirlik alanları desteklenmiyorsa bir hata alırsınız. İş yüklerinizin kullanılabilirlik alanlarını destekleyen bir damgaya sahip olduğundan emin olmak için yeni bir kaynak grubu, App Service planı ve App Service oluşturmanız gerekebilir.
App Services planınız, kullanılabilirlik alanlarını destekleyen aşağıdaki planlardan biri olmalıdır:
- App Service Premium v2 veya Premium v3 planlarını kullanan çok kiracılı bir ortamda.
- Yalıtılmış v2 App Service planlarıyla kullanılan App Service Ortamı v3 kullanan ayrılmış bir ortamda.
Ayrılmış ortamlar için App Service Ortamı v3 olmalıdır.
Önemli
v2 ve v1 App Service Ortamı 31 Ağustos 2024 tarihinde kullanımdan kaldırılacaktır. App Service Ortamı v3'ün kullanımı daha kolaydır ve daha güçlü bir altyapı üzerinde çalışır. App Service Ortamı v3 hakkında daha fazla bilgi edinmek için bkz. App Service Ortamı genel bakış. Şu anda App Service Ortamı v2 veya v1 kullanıyorsanız ve v3'e yükseltmek istiyorsanız, yeni sürüme geçmek için lütfen bu makaledeki adımları izleyin.
Üç bölgenin en düşük örnek sayısı zorlanır. Üçten az örnek sayısı belirtirseniz platform arka planda bu minimum sayıyı zorlar.
Kullanılabilirlik alanları yalnızca yeni bir App Service planı oluşturulurken belirtilebilir. Önceden var olan bir App Service planı kullanılabilirlik alanlarını kullanacak şekilde dönüştürülemez.
Aşağıdaki bölgeler, çok kiracılı ortamlarda çalışan Azure Uygulaması Hizmetlerini destekler:
- Doğu Avustralya
- Güney Brezilya
- Orta Kanada
- Orta Hindistan
- Central US
- Doğu Asya
- Doğu ABD
- Doğu ABD 2
- Orta Fransa
- Orta Batı Almanya
- Doğu Japonya
- Güney Kore - Orta
- Kuzey Avrupa
- Doğu Norveç
- Polonya Merkezi
- Katar Merkezi
- Güney Afrika - Kuzey
- Orta Güney ABD
- Güneydoğu Asya
- Orta İsveç
- Kuzey İsviçre
- Kuzey BAE
- Güney Birleşik Krallık
- West Europe
- Batı ABD 2
- Batı ABD 3
- 21Vianet tarafından sağlanan Microsoft Azure - Çin Kuzey 3
- Azure Kamu - US Gov Virginia
App Service Ortamı v3 için hangi bölgelerin kullanılabilirlik alanlarını desteklediğini görmek için bkz. Bölgeler.
Kullanılabilirlik alanı etkin bir kaynak oluşturma
Çok kiracılı alanlar arası yedekli app service dağıtmak için
Azure CLI kullanarak kullanılabilirlik alanlarını etkinleştirmek için App Service planınızı oluştururken parametresini ekleyin --zone-redundant . Kapasiteyi belirtmek için parametresini --number-of-workers de ekleyebilirsiniz. Kapasite belirtmezseniz platform varsayılan olarak üç olur. Kapasite, iş yükü gereksinimine göre ayarlanmalıdır ancak üçten az olmamalıdır. Kapasiteyi seçmek için iyi bir kural, uygulama için yeterli örneklerin, örneğin bir bölgesini kaybetmenin beklenen yükü işlemek için yeterli kapasite bırakmasını sağlamaktır.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
İpucu
Örnek kapasitesine karar vermek için aşağıdaki hesaplamayı kullanabilirsiniz:
Platform VM'leri üç bölgeye yaydığından ve en az bir bölgenin hatasını hesaba katmak gerektiğinden, en yüksek iş yükü örneği sayısını bir faktörle çarpın/(zones-1) veya 3/2. Örneğin, tipik tepe iş yükünüz dört örnek gerektiriyorsa altı örnek sağlamalısınız: (2/3 * 6 örnek) = 4 örnek.
Ayrılmış bir ortam kullanarak alanlar arası yedekli App Service dağıtma
Yalıtılmış v2 planında App Service Ortamı v3 oluşturmayı öğrenmek için bkz. App Service Ortamı oluşturma.
Sorun giderme
| Hata iletisi | Açıklama | Öneri |
|---|---|---|
| 'RG-NAME' kaynak grubu için alanlar arası yedeklilik kullanılamıyor. Lütfen 'ASP-NAME' uygulama hizmeti planını yeni bir kaynak grubuna dağıtın. | Kullanılabilirlik alanları yalnızca yeni App Service ayak izinde desteklenir. Desteklenen bölgelerden birini kullanıyor olsanız bile, kaynak grubunuz için kullanılabilirlik alanları desteklenmiyorsa bir hata alırsınız. | İş yüklerinizin kullanılabilirlik alanlarını destekleyen bir damgaya bindiğinden emin olmak için yeni bir kaynak grubu, App Service planı ve App Service oluşturun. |
Hataya dayanıklılık
Kullanılabilirlik alanı hatasına hazırlanmak için, çözümün 1/3 kapasite kaybına dayanadığından ve bölge genelinde kesintiler sırasında performansı düşürmeden çalışmaya devam ettiğinden emin olmak için fazla hizmet kapasitesi sağlamanız gerekir. Platform VM'leri üç bölgeye yaydığından ve en az bir bölgenin hatasını hesaba katmak gerektiğinden, en yüksek iş yükü örneği sayısını bir faktörle çarpın/(zones-1) veya 3/2. Örneğin, tipik tepe iş yükünüz dört örnek gerektiriyorsa altı örnek sağlamalısınız: (2/3 * 6 örnek) = 4 örnek.
Bölge azaltma deneyimi
Trafik tüm kullanılabilir App Service örneklerinize yönlendirilir. Bir bölgenin kapanması durumunda App Service platformu kayıp örnekleri algılar ve yeni yeni örnekleri otomatik olarak bulmaya çalışır ve gerektiğinde trafiği yayar. Otomatik ölçeklendirmeyi yapılandırdıysanız ve daha fazla örnek gerektiğine karar verirse, otomatik ölçeklendirme App Service'e daha fazla örnek ekleme isteği de verir. Otomatik ölçeklendirme davranışının App Service platform davranışından bağımsız olduğunu ve otomatik ölçeklendirme örneği sayısı belirtiminizin üç katı olması gerekmediğini unutmayın.
Not
Bölge aşağı senaryosunda ek örneklere yönelik isteklerin başarılı olacağı garanti edilmez. Kayıp örneklerin geri doldurulması en iyi çaba temelinde gerçekleşir. Önerilen çözüm, sonraki bölümde açıklandığı gibi App Service planlarınızı bir bölgeyi kaybetmeyi hesaba katacak şekilde oluşturmak ve yapılandırmaktır.
Kullanılabilirlik alanlarının etkinleştirildiği bir App Service planında dağıtılan uygulamalar, aynı bölgedeki diğer bölgelerde kesinti yaşansa bile çalışmaya ve trafiğe hizmet etmeye devam eder. Ancak App Service planı ölçeklendirme, uygulama oluşturma, uygulama yapılandırması ve uygulama yayımlama gibi çalışma zamanı olmayan davranışların diğer Kullanılabilirlik Alanları kesintiden etkilenmesi mümkündür. App Service planları için alanlar arası yedeklilik yalnızca dağıtılan uygulamalar için sürekli çalışma süresi sağlar.
App Service platformu örnekleri alanlar arası yedekli bir App Service planına ayırdığında, temel alınan Azure Sanal Makine Ölçek Kümeleri tarafından sunulan en iyi efor bölgesi dengelemesini kullanır. Her bölge aynı sayıda VM'ye veya App Service planı tarafından kullanılan diğer tüm bölgelerde +/- bir VM'ye sahipse App Service planı "dengeli" olur.
Kullanılabilirlik alanı geçişi
Mevcut App Service örneklerini veya ortam kaynaklarını kullanılabilirlik dışı bölge desteğinden kullanılabilirlik alanı desteğine geçiremezsiniz. Kullanılabilirlik alanları için destek almak için kullanılabilirlik alanlarının etkinleştirildiği kaynaklarınızı oluşturmanız gerekir.
Fiyatlandırma
Kullanılabilirlik alanlarını etkinleştirmenin ek bir maliyeti yoktur. Alanlar arası yedekli App Service fiyatlandırması, tek bölgeli App Service ile aynıdır. App Service planı SKU'nuza, belirttiğiniz kapasiteye ve otomatik ölçeklendirme ölçütlerinize göre ölçeklendirildiğiniz tüm örneklere göre ücretlendirilirsiniz. Kullanılabilirlik alanlarını etkinleştirir ancak üçten küçük bir kapasite belirtirseniz platform en az üç örnek sayısını zorlar ve bu üç örnek için sizden ücret alır. App Service Ortamı v3 fiyatlandırma bilgileri için bkz. Fiyatlandırma.
Bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği
Olağanüstü durum kurtarma (DR), kapalı kalma süresi ve veri kaybına neden olan doğal afetler veya başarısız dağıtımlar gibi yüksek etkili olaylardan kurtarmayla ilgilidir. Nedeni ne olursa olsun, olağanüstü durum için en iyi çözüm iyi tanımlanmış ve test edilmiş bir DR planı ve DR'yi etkin bir şekilde destekleyen bir uygulama tasarımıdır. Olağanüstü durum kurtarma planınızı oluşturmaya başlamadan önce bkz. Olağanüstü durum kurtarma stratejisi tasarlamaya yönelik Öneriler.
DR söz konusu olduğunda, Microsoft paylaşılan sorumluluk modelini kullanır. Paylaşılan bir sorumluluk modelinde Microsoft, temel altyapı ve platform hizmetlerinin kullanılabilir olmasını sağlar. Aynı zamanda, birçok Azure hizmeti verileri otomatik olarak çoğaltmaz veya başarısız olan bir bölgeden geri dönerek başka bir etkin bölgeye çapraz çoğaltma yapamaz. Bu hizmetler için iş yükünüz için uygun bir olağanüstü durum kurtarma planı ayarlamak sizin sorumluluğunuzdadır. Hizmet olarak Azure platformu (PaaS) tekliflerinde çalışan hizmetlerin çoğu, DR'yi desteklemek için özellikler ve yönergeler sağlar ve DR planınızı geliştirmeye yardımcı olmak üzere hızlı kurtarmayı desteklemek için hizmete özgü özellikleri kullanabilirsiniz.
Bu bölüm, App Service'e dağıtılan web uygulamaları için bazı yaygın stratejileri kapsar.
App Service'te bir web uygulaması oluşturduğunuzda ve kaynak oluşturma sırasında bir Azure bölgesi seçtiğinizde, bu tek bölgeli bir uygulamadır. Bölge olağanüstü durum sırasında kullanılamaz duruma geldiğinde uygulamanız da kullanılamaz duruma gelir. Çok bölgeli coğrafya mimarisini kullanarak ikincil bir Azure bölgesinde aynı dağıtımı oluşturursanız, uygulamanız tek bölgeli olağanüstü duruma daha az duyarlı hale gelir ve bu da iş sürekliliğini garanti eder. Bölgeler arasında herhangi bir veri çoğaltması, son uygulama durumunuzu kurtarmanıza olanak tanır.
BT için, iş sürekliliği planları büyük ölçüde Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO) tarafından yönlendirilir. RTO ve RPO hakkında daha fazla bilgi için bkz . Kurtarma hedefleri.
Normalde, RTO çevresinde SLA'nın korunması bölgesel olağanüstü durumlar için pratik değildir ve genellikle olağanüstü durum kurtarma stratejinizi yalnızca RPO çevresinde tasarlarsınız (örneğin, kesintiyi en aza indirmeye değil verileri kurtarmaya odaklanın). Ancak Azure ile yalnızca pratik değildir, aynı zamanda otomatik coğrafi yük devretme işlemleri için App Service'i dağıtmak da kolay olabilir. Bu, hem RTO hem de RPO ile ilgilenerek uygulamalarınızı olağanüstü durumlara karşı daha fazla denetlemenize olanak tanır.
İstediğiniz RTO ve RPO ölçümlerine bağlı olarak, hem App Service çok kiracılı hem de App Service Ortamı için yaygın olarak üç olağanüstü durum kurtarma mimarisi kullanılır. Her mimari aşağıdaki tabloda açıklanmıştır:
| Metric | Etkin-Etkin | Aktif-Pasif | Pasif/Soğuk |
|---|---|---|---|
| KSH | Gerçek zamanlı veya saniye | Dakika | Saat Sayısı |
| KNH | Gerçek zamanlı veya saniye | Dakika | Saat Sayısı |
| Maliyet | $$$ | $$ | $ |
| Senaryolar | Görev açısından kritik uygulamalar | Yüksek öncelikli uygulamalar | Düşük öncelikli uygulamalar |
| Çok bölgeli kullanıcı trafiğine hizmet verme olanağı | Yes | Evet/belki | Hayır |
| Kod dağıtımı | Tercih edilen CI/CD işlem hatları | Tercih edilen CI/CD işlem hatları | Yedekleme ve geri yükleme |
| Kapalı kalma süresinde yeni App Service kaynakları oluşturma | Gerekli değil | Gerekli değil | Zorunlu |
Not
Uygulamanız büyük olasılıkla Azure SQL Veritabanı ve Azure Depolama hesapları gibi Azure'daki diğer veri hizmetlerine bağlıdır. Bu bağımlı Azure Hizmetlerinin her biri için de olağanüstü durum kurtarma stratejileri geliştirmeniz önerilir. SQL Veritabanı için bkz. Azure SQL Veritabanı için etkin coğrafi çoğaltma. Azure Depolama için bkz. Azure Depolama yedekliliği.
Çok bölgeli coğrafyada olağanüstü durum kurtarma
Web uygulamalarınızın içeriğini ve yapılandırmalarını, App service yedekleme ve geri yükleme gibi etkin-etkin veya etkin-pasif bir mimaride Azure bölgeleri arasında çoğaltmanın birden çok yolu vardır. Ancak, yedekleme ve geri yükleme belirli bir noktaya anlık görüntüler oluşturur ve sonunda bölgeler arasında web uygulaması sürüm oluşturma zorluklarına yol açar. Geri yükleme ve geri yükleme kılavuzu ile diaster kurtarma kılavuzu karşılaştırması için aşağıdaki tabloya bakın:
Yedekleme ve geri yükleme ile olağanüstü durum kurtarma karşılaştırması
| Platform | Yedekleme ve geri yükleme kılavuzu | Olağanüstü durum kurtarma kılavuzu |
|---|---|---|
| App Service Web Apps (Ücretsiz ve Paylaşılan Fiyatlandırma Katmanı) |
Ücretsiz veya Paylaşılan katmanına dağıtılan web uygulamalarınız varsa ve bu web uygulamaları için Yedekleme ve Geri Yükleme özelliklerine erişmeniz gerekiyorsa, ölçeği Temel katmana veya daha yüksek bir katmana büyütün . | Bölgesel bir olağanüstü durum sırasında App Service kaynaklarını farklı bir Azure bölgesinde yeniden çevrimiçi yapın. 31 Mart 2025'ten itibaren App Service uygulamaları, bölge genelindeki hatadan kurtarma makalesinde açıklandığı gibi Bir Azure bölgesindeki olağanüstü durum sırasında olağanüstü durum kurtarma moduna yerleştirilmeyecektir. Bölgesel bir olağanüstü durum sırasında kapalı kalma süresini ve veri kaybını önlemek için yaygın olarak kullanılan olağanüstü durum kurtarma tekniklerinin uygulanması önerilir. |
| App Service Web Apps (Temel\Standart\Premium Fiyatlandırma Katmanı) |
Azure Uygulaması Hizmeti'nde isteğe bağlı özel yedeklemeler yapabilir veya otomatik yedeklemeleri kullanabilirsiniz. Yeni bir uygulamaya veya yuvaya geri yükleyerek mevcut bir uygulamanın üzerine yazarak yedeklemeyi geri yükleyebilirsiniz. Daha fazla bilgi için bkz. uygulamanızı Azure Uygulaması Hizmetinde yedekleme ve geri yükleme. |
Bölgesel bir olağanüstü durum sırasında App Service kaynaklarını farklı bir Azure bölgesinde yeniden çevrimiçi duruma getirmeyle ilgili güncel yönergeler, Bölge genelindeki hatadan kurtarma - Azure Uygulaması Hizmeti'nde kullanılabilir. 31 Mart 2025'ten itibaren Azure Uygulaması Service web uygulamaları, bölge genelindeki hatadan kurtarma makalesinde açıklandığı gibi Azure bölgesindeki bir olağanüstü durum sırasında olağanüstü durum kurtarma moduna alınmayacak. Bölgesel bir olağanüstü durum söz konusu olduğunda web uygulamalarınızda işlevsellik veya veri kaybını önlemek için yaygın olarak kullanılan olağanüstü durum kurtarma tekniklerini uygulamanızı öneririz. |
| App Service Ortamı (V2 ve V3) | Azure Uygulaması Hizmet Ortamı'nda isteğe bağlı özel yedeklemeler yapabilir veya otomatik yedeklemeleri kullanabilirsiniz. Otomatik yedeklemeler, başka bir ASE'de değil, aynı ASE içindeki bir hedef uygulamaya geri yüklenebilir. Özel yedeklemeler başka bir ASE'deki hedef uygulamaya geri yüklenebilir (örneğin, V2 ASE'den V3 ASE'ye). Yedeklemeler, kaynak uygulamayla aynı işletim sistemi platformundaki hedef uygulamaya geri yüklenebilir. Daha fazla ayrıntı için bkz. uygulamanızı Azure Uygulaması Hizmetinde yedekleme ve geri yükleme. |
Yaygın olarak kullanılan olağanüstü durum kurtarma tekniklerini kullanarak App Service Ortamı dağıtılan web uygulamaları için olağanüstü durum kurtarma yönergeleri uygulamanızı öneririz. |
| Azure İşlevleri (Ayrılmış) | Azure İşlevleri isteğe bağlı özel yedeklemeler yapabilir veya otomatik yedeklemeleri kullanabilirsiniz. Yeni bir uygulamaya veya yuvaya geri yükleyerek mevcut bir uygulamanın üzerine yazarak yedeklemeyi geri yükleyebilirsiniz. Daha fazla bilgi için bkz. uygulamanızı Azure Uygulaması Hizmetinde yedekleme ve geri yükleme. |
Bölgesel bir olağanüstü durum sırasında Azure İşlevleri uygulama (ayrılmış) kaynaklarının farklı bir Azure bölgesinde yeniden çevrimiçi duruma getirilmesiyle ilgili güncel yönergeler, Bölge genelindeki hatadan kurtarma - Azure Uygulaması Hizmeti'nde kullanılabilir. 31 Mart 2025'ten itibaren App Service uygulamaları, bölge genelindeki hatadan kurtarma makalesinde açıklandığı gibi Bir Azure bölgesindeki olağanüstü durum sırasında olağanüstü durum kurtarma moduna yerleştirilmeyecektir. Bunun yerine Azure İşlevleri coğrafi olağanüstü durum kurtarma uygulayın. Ayrıca ayrılmış Azure İşlevleri için yaygın olarak kullanılan olağanüstü durum kurtarma tekniklerine de başvurabilirsiniz. |
| Azure İşlevleri Tüketimi ve Premium | Tüketim ve premium planlara dağıtılan Azure işlevleri, özel ve otomatik yedeklemelere erişim sağlamaz. İşlev uygulamasının içeriği bir Azure depolama hesabında yer alır. Depolama hesabınızın kesinti sırasında kullanılabilirlik ve dayanıklılık hedeflerini karşıladığından emin olmak için Azure Depolama yedeklilik seçeneklerini kullanın. İşlevlerinizi Azure portalındaki düzenleyiciyi kullanarak oluşturduysanız, mevcut işlev uygulaması projenizi .zip dosyası olarak da indirebilirsiniz. |
Azure İşlevleri coğrafi olağanüstü durum kurtarma ve güvenilirlik uygulamanızı kesinlikle öneririz. |
Yedekleme ve geri yükleme yöntemlerinin sınırlamalarını önlemek için CI/CD işlem hatlarınızı her iki Azure bölgesine de kod dağıtacak şekilde yapılandırın. Azure Pipelines veya GitHub Actions kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz. Azure Uygulaması Hizmetine sürekli dağıtım.
Kesinti algılama, bildirim ve yönetim
Olağanüstü durum sırasında zamanında bildirim almak üzere web uygulamalarınız için izleme ve uyarılar ayarlamanız önerilir. Daha fazla bilgi için bkz. Uygulama Analizler kullanılabilirlik testleri.
Azure'daki uygulama kaynaklarınızı yönetmek için kod olarak altyapı (IaC) mekanizmasını kullanın. Birden çok bölgede karmaşık bir dağıtımda, bölgeleri bağımsız olarak yönetmek ve yapılandırmanın bölgeler arasında güvenilir bir şekilde eşitlenmesini sağlamak için tahmin edilebilir, test edilebilir ve yinelenebilir bir işlem gerekir. Azure Resource Manager şablonları veya Terraform gibi bir IaC aracı düşünün.
Olağanüstü durum kurtarma ve kesinti algılamayı ayarlama
Çok bölgeli bir coğrafyada olağanüstü durum kurtarma için hazırlanmak için etkin-etkin veya etkin-pasif mimari kullanabilirsiniz.
Etkin-Etkin mimari
Etkin-etkin olağanüstü durum kurtarma mimarisinde, aynı web uygulamaları iki ayrı bölgeye dağıtılır ve Azure Front door trafiği her iki etkin bölgeye yönlendirmek için kullanılır.
Bu örnek mimariyle:
- Aynı App Service uygulamaları, fiyatlandırma katmanı ve örnek sayısı dahil olmak üzere iki ayrı bölgeye dağıtılır.
- Doğrudan App Service uygulamalarına yönelik genel trafik engellenir.
- Azure Front Door, trafiği her iki etkin bölgeye yönlendirmek için kullanılır.
- Olağanüstü durum sırasında bölgelerden biri çevrimdışı olur ve Azure Front Door trafiği yalnızca çevrimiçi kalan bölgeye yönlendirir. Böyle bir coğrafi yük devretme sırasında RTO sıfıra yakındır.
- Uygulama dosyaları bir CI/CD çözümüyle her iki web uygulamasına da dağıtılmalıdır. Bu, RPO'yu neredeyse sıfır olmasını sağlar.
- Uygulamanız dosya sistemini etkin bir şekilde değiştirirse, RPO'yu simge durumuna küçültmenin en iyi yolu doğrudan web uygulamasının /home içerik paylaşımına yazmak yerine yalnızca bağlı bir Azure Depolama paylaşımına yazmaktır. Ardından, yaklaşık 15 dakikalık RPO'ya sahip olan bağlı paylaşımınız için Azure Depolama yedeklilik özelliklerini (GZRS veya GRS) kullanın.
App Service'te web uygulamanız için etkin-etkin mimari oluşturma adımları aşağıdaki gibi özetlenmiştir:
İki farklı Azure bölgesinde iki App Service planı oluşturun. İki App Service planını aynı şekilde yapılandırın.
Her App Service planında bir tane ile web uygulamanızın iki örneğini oluşturun.
Şu şekilde bir Azure Front Door profili oluşturun:
- Bir uç nokta.
- Her biri 1 öncelikli iki kaynak grubu. Eşit öncelik, Azure Front Door'a trafiği her iki bölgeye de eşit olarak yönlendirmesini (dolayısıyla etkin-etkin) bildirir.
- Bir yol.
Ağ trafiğini yalnızca Azure Front Door örneğinden web uygulamalarıyla sınırlayın.
Veritabanları, depolama hesapları ve kimlik doğrulama sağlayıcıları gibi diğer tüm arka uç Azure hizmetini ayarlayın ve yapılandırın.
Sürekli dağıtım ile her iki web uygulamasına da kod dağıtın.
Öğretici: Azure Uygulaması Hizmeti'nde yüksek oranda kullanılabilir çok bölgeli bir uygulama oluşturmak, etkin-pasif mimariyi nasıl ayarlayabileceğinizi gösterir. En az değişiklikle aynı adımlar (Azure Front Door'taki kaynak grubundaki her iki kaynak için de önceliği "1" olarak ayarlamak) size etkin-etkin bir mimari sağlar.
Etkin-pasif mimari
Bu olağanüstü durum kurtarma yaklaşımında, aynı web uygulamaları iki ayrı bölgeye dağıtılır ve Azure Front door trafiği yalnızca bir bölgeye ( etkin bölge) yönlendirmek için kullanılır.
Bu örnek mimariyle:
Aynı App Service uygulamaları iki ayrı bölgeye dağıtılır.
Doğrudan App Service uygulamalarına yönelik genel trafik engellenir.
Azure Front Door, trafiği birincil bölgeye yönlendirmek için kullanılır.
Maliyetten tasarruf etmek için ikincil App Service planı daha az örneğe sahip olacak ve/veya daha düşük fiyatlandırma katmanında olacak şekilde yapılandırılır. Üç olası yaklaşım vardır:
Tercih Edilen İkincil App Service planı, aynı sayıda veya daha az örnek içeren birincil ile aynı fiyatlandırma katmanına sahiptir. Bu yaklaşım, iki App Service planı için hem özellik hem de VM boyutlandırmasında eşlik sağlar. Coğrafi yük devretme sırasındaki RTO yalnızca örneklerin ölçeğini genişletme süresine bağlıdır.
Daha az tercih edilen İkincil App Service planı aynı fiyatlandırma katmanı türüne (PremiumV3 gibi) sahiptir, ancak daha az örnek içeren daha küçük VM boyutlandırmaya sahiptir. Örneğin, birincil bölge P3V3 katmanında, ikincil bölge ise P1V3 katmanında olabilir. Bu yaklaşım, iki App Service planı için özellik eşliğini sağlamaya devam eder, ancak ikincil bölge etkin bölge olduğunda boyut eşliği eksikliği el ile ölçeği artırmayı gerektirebilir. Coğrafi yük devretme sırasında RTO, örneklerin ölçeğini artırma ve ölçeği genişletme süresine bağlıdır.
En az tercih edilen İkincil App Service planı, birincil ve daha az örneklerden farklı bir fiyatlandırma katmanına sahiptir. Örneğin, birincil bölge P3V3 katmanında, ikincil bölge ise S1 katmanında olabilir. İkincil App Service planının, çalıştırmak için uygulamanızın ihtiyaç duyduğu tüm özelliklere sahip olduğundan emin olun. İkisi arasındaki özellik kullanılabilirliği farklılıkları, web uygulaması kurtarma işleminizde gecikmelere neden olabilir. Coğrafi yük devretme sırasında RTO, örneklerin ölçeğini artırma ve ölçeği genişletme süresine bağlıdır.
Otomatik ölçeklendirme, etkin bölgenin devre dışı olması durumunda ikincil bölgede yapılandırılır. Hem etkin hem de pasif bölgelerde benzer otomatik ölçeklendirme kurallarına sahip olmanız önerilir.
Olağanüstü durum sırasında birincil bölge etkin değildir ve ikincil bölge trafik almaya başlar ve etkin bölge olur.
İkincil bölge etkinleştirildikten sonra ağ yükü, ikincil web uygulamasının ölçeğini genişletmek için önceden yapılandırılmış otomatik ölçeklendirme kurallarını tetikler.
Etkin bölge olarak çalıştırmak için gerekli özelliklere sahip değilse ikincil bölge için fiyatlandırma katmanının ölçeğini el ile artırmanız gerekebilir. Örneğin, otomatik ölçeklendirme için Standart katman veya üzeri gerekir.
Birincil bölge yeniden etkin olduğunda, Azure Front Door trafiği otomatik olarak bu bölgeye yönlendirir ve mimari önceki gibi etkin-pasif duruma döner.
Uygulama dosyaları bir CI/CD çözümüyle her iki web uygulamasına da dağıtılmalıdır. Bu, RPO'yu neredeyse sıfır olmasını sağlar.
Uygulamanız dosya sistemini etkin bir şekilde değiştirirse, RPO'yu simge durumuna küçültmenin en iyi yolu doğrudan web uygulamasının /home içerik paylaşımına yazmak yerine yalnızca bağlı bir Azure Depolama paylaşımına yazmaktır. Ardından, yaklaşık 15 dakikalık RPO'ya sahip olan bağlı paylaşımınız için Azure Depolama yedeklilik özelliklerini (GZRS veya GRS) kullanın.
App Service'te web uygulamanız için etkin-pasif mimari oluşturma adımları aşağıdaki gibi özetlenmiştir:
- İki farklı Azure bölgesinde iki App Service planı oluşturun. İkincil App Service planı, daha önce bahsedilen yaklaşımlardan biri kullanılarak sağlanabilir.
- İkincil App Service planı için otomatik ölçeklendirme kurallarını yapılandırarak birincil bölge etkin olmadığında birincil ile aynı örnek sayısına ölçeklendirilmesini sağlayın.
- Her App Service planında bir tane ile web uygulamanızın iki örneğini oluşturun.
- Şu şekilde bir Azure Front Door profili oluşturun:
- Bir uç nokta.
- Birincil bölge için önceliği 1 olan bir kaynak grubu.
- İkincil bölge için önceliği 2 olan ikinci bir çıkış noktası grubu. Öncelik farkı, Azure Front Door'a çevrimiçi olduğunda birincil bölgeyi (dolayısıyla etkin-pasif) tercih etmesini söyler.
- Bir yol.
- Ağ trafiğini yalnızca Azure Front Door örneğinden web uygulamalarıyla sınırlayın.
- Veritabanları, depolama hesapları ve kimlik doğrulama sağlayıcıları gibi diğer tüm arka uç Azure hizmetini ayarlayın ve yapılandırın.
- Sürekli dağıtım ile her iki web uygulamasına da kod dağıtın.
Öğretici: Azure Uygulaması Hizmeti'nde yüksek oranda kullanılabilir çok bölgeli bir uygulama oluşturmak, etkin-pasif mimariyi nasıl ayarlayabileceğinizi gösterir.
Pasif-soğuk mimari
Başka bir bölgede bulunan bir Azure Depolama hesabında web uygulamalarınızın düzenli yedeklemelerini oluşturmak ve korumak için pasif/soğuk mimari kullanın.
Bu örnek mimariyle:
Tek bir web uygulaması tek bir bölgeye dağıtılır.
Web uygulaması düzenli olarak aynı bölgedeki bir Azure Depolama hesabına yedekleniyor.
Yedeklemelerinizin bölgeler arası çoğaltması, Azure depolama hesabındaki veri yedekliliği yapılandırmasına bağlıdır. Mümkünse Azure Depolama hesabınızı GZRS olarak ayarlamanız gerekir. GZRS hem bölge içinde zaman uyumlu bölge yedekliliği hem de ikincil bölgede zaman uyumsuzluk sunar. GZRS kullanılamıyorsa hesabı GRS olarak yapılandırın. Hem GZRS hem de GRS yaklaşık 15 dakikalık bir RPO'ya sahiptir.
Depolama hesabının birincil bölgesi kullanılamaz duruma geldiğinde yedekleri alabildiğinizden emin olmak için ikincil bölgeye salt okunur erişimi etkinleştirin (depolama hesabını sırasıyla RA-GZRS veya RA-GRS yapın). Uygulamalarınızı coğrafi yedeklilikten yararlanacak şekilde tasarlama hakkında daha fazla bilgi için bkz . Yüksek oranda kullanılabilir uygulamalar tasarlamak için coğrafi yedekliliği kullanma.
Web uygulamasının bölgesindeki bir olağanüstü durum sırasında, azure Depolama hesabından (büyük olasılıkla okuma erişimine sahip ikincil bölgeden) yedekleri kullanarak tüm gerekli App Service bağımlı kaynaklarını el ile dağıtmanız gerekir. RTO saat veya gün olabilir.
RTO'yu en aza indirmek için, web uygulaması yedeklemenizi başka bir Azure Bölgesine geri yüklemek için gereken tüm adımların ana hatlarını içeren kapsamlı bir playbook'unuz olması kesinlikle önerilir.
App Service'te web uygulamanız için pasif soğuk bölge oluşturma adımları aşağıdaki gibi özetlenir:
Web uygulamanızla aynı bölgede bir Azure depolama hesabı oluşturun. Standart performans katmanı'nı seçin ve coğrafi olarak yedeklilik'i Coğrafi olarak yedekli depolama (GRS) veya Coğrafi Alanlar arası yedekli depolama (GZRS) olarak seçin.
RA-GRS veya RA-GZRS'yi etkinleştirin (ikincil bölge için okuma erişimi).
Web uygulamanız için özel yedeklemeyi yapılandırın. Web uygulaması yedeklemeleriniz için saatlik gibi bir zamanlama ayarlamaya karar vekleyebilirsiniz.
Web uygulaması yedekleme dosyalarının depolama hesabınızın ikincil bölgesine alınabildiğini doğrulayın.
İpucu
Azure Front Door'un yanı sıra Azure Traffic Manager gibi diğer yük dengeleme seçeneklerini de sağlar. Çeşitli seçeneklerin karşılaştırması için bkz . Yük dengeleme seçenekleri - Azure Mimari Merkezi.
Tek bölgeli coğrafyada olağanüstü durum kurtarma
Web uygulamanızın bölgesinde GZRS veya GRS depolama alanı yoksa veya bölgesel çiftlerden biri olmayan bir Azure bölgesindeyseniz, benzer bir mimari oluşturmak için alanlar arası yedekli depolama (ZRS) veya yerel olarak yedekli depolama (LRS) kullanmanız gerekir. Örneğin, depolama hesabı için el ile aşağıdaki gibi ikincil bir bölge oluşturabilirsiniz:
GRS ve GZRS olmadan pasif-soğuk bölge oluşturma adımları aşağıdaki gibi özetlenir:
Web uygulamanızın aynı bölgesinde bir Azure depolama hesabı oluşturun. Standart performans katmanı'nı seçin ve alanlar arası yedekli depolama (ZRS) olarak yedeklilik'i seçin.
Web uygulamanız için özel yedeklemeyi yapılandırın. Web uygulaması yedeklemeleriniz için saatlik gibi bir zamanlama ayarlamaya karar vekleyebilirsiniz.
Web uygulaması yedekleme dosyalarının depolama hesabınızın ikincil bölgesine alınabildiğini doğrulayın.
Farklı bir bölgede ikinci bir Azure depolama hesabı oluşturun. Standart performans katmanı'nı seçin ve yerel olarak yedekli depolama (LRS) olarak yedeklilik'i seçin.
AzCopy gibi bir araç kullanarak özel yedeklemenizi (Zip, XML ve günlük dosyaları) birincil bölgeden ikincil depolama alanına çoğaltın. Örneğin:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Çoğaltma betiğinizi bir zamanlamaya göre çalıştırmak için bir PowerShell İş Akışı runbook'u ile Azure Otomasyonu kullanabilirsiniz. Çoğaltma zamanlamasının web uygulaması yedeklemelerine benzer bir zamanlama izlediğinden emin olun.