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?

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 kullanma önerileri.

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
  • Orta İsrail
  • Kuzey İtalya
  • Doğu Japonya
  • Güney Kore - Orta
  • Meksika Orta
  • Kuzey Avrupa
  • Doğu Norveç
  • Polonya Merkezi
  • Katar Merkezi
  • Güney Afrika - Kuzey
  • Orta Güney ABD
  • Güneydoğu Asya
  • İspanya Orta
  • 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

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

"resources": [
  {
    "type": "Microsoft.Web/serverfarms",
    "apiVersion": "2018-02-01",
    "name": "your-appserviceplan-name-here",
    "location": "West US 3",
    "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "size": "P1v3",
        "family": "Pv3",
        "capacity": 3
    },
    "kind": "app",
    "properties": {
        "zoneRedundant": true
    }
  }
]

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

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.

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

App Service Premium v2 veya Premium v3 planlarını kullanan çok kiracılı ortamlar için, App Service planınızda üç veya daha fazla örneğiniz olduğu sürece kullanılabilirlik alanlarını etkinleştirmenin ek bir maliyeti yoktur. 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 kullanılabilirlik alanları için farklı bir fiyatlandırma modeline sahiptir. 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 tasarlama önerileri.

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:

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

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 . Application Insights 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 en aza indirmenin 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:

1. İki farklı Azure bölgesinde iki App Service planı oluşturun. İki App Service planını aynı şekilde yapılandırın.

2. Her App Service planında bir tane ile web uygulamanızın iki örneğini oluşturun.

3. Ş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.

4. Ağ trafiğini yalnızca Azure Front Door örneğinden web uygulamalarıyla sınırlayın.

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

6. 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 en aza indirmenin 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:

1. İ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.
2. İ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.
3. Her App Service planında bir tane ile web uygulamanızın iki örneğini oluşturun.
4. Ş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.
5. Ağ trafiğini yalnızca Azure Front Door örneğinden web uygulamalarıyla sınırlayın.
6. 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.
7. 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ı aynı bölgedeki bir Azure Depolama hesabına düzenli olarak 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, büyük olasılıkla okuma erişimi olan ikincil bölgeden azure depolama hesabından yedeklemeleri kullanarak gerekli tüm 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:

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

2. RA-GRS veya RA-GZRS'yi etkinleştirin (ikincil bölge için okuma erişimi).

3. Web uygulamanız için özel yedeklemeyi yapılandırın. Web uygulaması yedeklemeleriniz için saatlik gibi bir zamanlama ayarlamaya karar vekleyebilirsiniz.

4. Web uygulaması yedekleme dosyalarının depolama hesabınızın ikincil bölgesine alınabildiğini doğrulayın.

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:

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

2. Web uygulamanız için özel yedeklemeyi yapılandırın. Web uygulaması yedeklemeleriniz için saatlik gibi bir zamanlama ayarlamaya karar vekleyebilirsiniz.

3. Web uygulaması yedekleme dosyalarının depolama hesabınızın ikincil bölgesine alınabildiğini doğrulayın.

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

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

Sonraki adımlar

• Öğretici: Azure Uygulaması Hizmetinde yüksek oranda kullanılabilir çok bölgeli uygulama oluşturma
• Azure'da güvenilirlik