Aracılığıyla paylaş

Azure Kullanılabilirlik Alanlarıyla SAP iş yükü yapılandırmaları

Farklı SAP mimarisi katmanlarının Azure Kullanılabilirlik Alanları dağıtımı, Azure'da SAP iş yükü dağıtımları için önerilen mimaridir. Azure Kullanılabilirlik Alanı şu şekilde tanımlanır: "Bölge içindeki benzersiz fiziksel konumlar. Her bölge bağımsız güç, soğutma ve ağ ile donatılmış bir veya daha fazla veri merkezinden oluşur". Azure Kullanılabilirlik Alanları tüm bölgelerde kullanılamaz. Kullanılabilirlik Alanları sağlayan Azure bölgeleri için Azure bölge haritasına bakın. Makalede, hangi bölgelerin Kullanılabilirlik Alanları sağladığı listelenir. Daha büyük SAP iş yükünü barındıracak şekilde donatılmış Azure bölgelerinin çoğu Kullanılabilirlik Alanları sağlar. Yeni Azure bölgeleri başlangıçtan itibaren Kullanılabilirlik Alanları sağlar. Bazı eski bölgeler yeniden yapılandırılmak üzere Kullanılabilirlik Alanları ile donatıldı veya bu süreçte yer alıyor.

Tipik SAP NetWeaver veya S/4HANA mimarisinden itibaren üç farklı katmanı korumanız gerekir:

  • Bir ila birkaç düzine Sanal Makine (VM) içerebilen SAP uygulama katmanı. VM'lerin aynı konak sunucusuna dağıtılma olasılığını en aza indirmek istiyorsunuz. Ayrıca bu VM'lerin veritabanı katmanına kabul edilebilir bir yakınlıkta olmasını ve ağ gecikmesini kabul edilebilir bir pencerede tutmasını istiyorsunuz
  • SAP NetWeaver ve S/4HANA mimarisinde tek bir hata noktasını temsil eden SAP ASCS/SCS katmanı. Genellikle yük devretme çerçevesiyle ele almak istediğiniz iki VM'ye bakarsınız. Bu nedenle, bu VM'ler farklı altyapı hata etki alanlarında ayrılmalıdır
  • Sap veritabanı katmanı, tek bir hata noktasını da temsil eder. Her zamanki durumlarda, yük devretme çerçevesi kapsamındaki iki VM'den oluşur. Bu nedenle, bu VM'ler farklı altyapı hata etki alanlarında ayrılmalıdır. İkiden fazla VM'nin kullanıldığı yerlerde SAP HANA ölçeklendirme dağıtımları özel durumlardır.

Kritik VM'lerinizi kullanılabilirlik kümeleri veya Kullanılabilirlik Alanları aracılığıyla dağıtma arasındaki başlıca farklar şunlardır:

  • Kullanılabilirlik kümesiyle dağıtım, küme içindeki VM'leri tek bir bölgede veya veri merkezinde (belirli bir bölge için ne geçerli olursa olsun) sıralamaktır. Sonuç olarak kullanılabilirlik kümesi aracılığıyla yapılan dağıtım, bölgenin tamamının veri merkezlerini etkileyen güç, soğutma veya ağ sorunlarıyla korunmaz. Kullanılabilirlik kümelerinde vm ile diskleri arasında zorlamalı hizalama da yoktur. Diğer bir deyişle diskler, bölgenin bölgesel yapısından bağımsız olarak Azure bölgesinin herhangi bir veri merkezinde olabilir. Olumlu bir yönü, Sanal Makineler (VM'ler) bu bölge ya da veri merkezi içindeki güncelleme ve hata alanlarıyla uyumlu olacak şekilde hizalanır. Özellikle, SAP ASCS veya veritabanı katmanında kullanılabilirlik kümesi başına iki VM'yi koruduğumuzda, hata etki alanlarıyla yapılan hizalama, her iki VM'nin aynı konak donanımında yer almasını önler.
  • Azure Kullanılabilirlik Alanları aracılığıyla ve farklı bölgeleri (en fazla üç farklı bölge) seçerek VM'leri dağıtma işlemi, VM'leri farklı fiziksel konumlara yayacak ve bununla birlikte, bölgenin kapsamına giren güç, soğutma veya ağ sorunlarından koruma sağlar. VM'ler ve ilgili diskler de aynı Kullanılabilirlik Alanında birlikte bulunur. Ancak, aynı VM ailesinden birden fazla VM'yi aynı Erişilebilirlik Bölgesine dağıttığınızda, bu VM'lerin aynı ana bilgisayarda veya aynı hata etki alanında bulunmasına karşı bir koruma yoktur. Sonuç olarak, Kullanılabilirlik Alanları aracılığıyla dağıtım, SAP ASCS ve veritabanı katmanı için idealdir ve burada genellikle ikişer VM kullanılır. İkiden fazla VM'den fazla olabilen SAP uygulama katmanı için farklı bir dağıtım modeline geri dönmeniz gerekebilir (daha sonrasına bakın).

Azure Kullanılabilirlik Alanları genelinde dağıtım yapma motivasyonunuz, tek bir kritik VM hatasının yanı sıra, kritik bir sanal makinede yazılım güncellemeleri için kapalı kalma süresini azaltmanın ötesinde, bir veya birden fazla Azure veri merkezinin kullanılabilirliğini etkileyebilecek daha büyük altyapı sorunlarına karşı korunmak olmalıdır.

Azure, başka bir dayanıklılık dağıtımı işlevi olarak SAP iş yükü için esnek düzenlemeye sahip Sanal makine ölçek kümelerini kullanıma sunar. Sanal makine ölçek kümesi, platform tarafından yönetilen sanal makinelerin mantıksal gruplandırmalarını sağlar. Sanal makine ölçek kümesinin esnek düzenlemesi, ölçek kümesini bir bölge içinde oluşturma veya kullanılabilirlik alanlarına yayma seçeneği sağlar. Oluşturma sırasında platformFaultDomainCount>1 (FD>1) içeren bir bölgede yer alan esnek ölçek kümesinde, dağıtılan VM'ler aynı bölgedeki belirtilen sayıda hata etki alanına dağıtılacaktır. Öte yandan platformFaultDomainCount=1 (FD=1) ile kullanılabilirlik alanları arasında esnek ölçek kümesi oluşturmak sanal makineleri farklı bölgelere dağıtacak ve ölçek kümesi de vm'leri her bölge içindeki farklı hata etki alanları arasında en iyi çaba temelinde dağıtacaktı. SAP iş yükü için yalnızca FD=1 ile esnek ölçek kümesi desteklenir. FD=1 ile esnek ölçek kümelerini kullanmanın avantajı, geleneksel kullanılabilirlik alanı dağıtımına kıyasla, ölçek kümesiyle dağıtılan VM'lerin, bölge içindeki farklı hata etki alanlarına mümkün olan en iyi şekilde dağıtılmasıdır. Daha fazla bilgi için SAP iş yükü için esnek ölçek kümesinin dağıtım kılavuzu'na bakın.

Kullanılabilirlik Alanları arasında dağıtmayla ilgili dikkat edilmesi gerekenler

Kullanılabilirlik Alanları kullanırken aşağıdakileri göz önünde bulundurun:

  • Azure Kullanılabilirlik Alanları hakkında daha fazla bilgi, Bölgeler ve kullanılabilirlik alanları belgesinde sunulmuştur.
  • Deneyimli ağ gidiş dönüş gecikmesi, farklı bölgeleri oluşturan veri merkezlerinin gerçek coğrafi uzaklığı için mutlaka bir gösterge değildir. Ağ gidiş dönüş gecikmesi, kablo bağlantıları ve kabloların bu farklı veri merkezleri arasında yönlendirilmesinden de etkilenir.
  • Kullanılabilirlik Alanları küçük mesafeli DR çözümü olarak kullanıyorsanız, güç altyapılarında ağır ve yaygın hasarlar da dahil olmak üzere dünyanın farklı bölgelerinde yaygın hasara neden olan doğal afetlerle karşılaştığımızı unutmayın. Çeşitli bölgeler arasındaki mesafeler her zaman bu kadar büyük doğal afetleri telafi edecek kadar büyük olmayabilir.
  • Kullanılabilirlik Alanları genelinde ağ gecikme süresi tüm Azure bölgelerinde aynı değildir. Azure bölgesinde bile farklı bölgeler arasındaki ağ gecikme süreleri farklılık gösterebilir. En kötü durumda bile, HANA Sistem Çoğaltması veya SQL Server Always On temelinde veritabanı düzeyinde zaman uyumlu çoğaltma, iş yükünün ölçeklenebilirliğini etkilemeden çalışır.
  • Kullanılabilirlik Alanları nerede kullanacağınıza karar verirken, kararınızı bölgeler arasındaki ağ gecikme süresine dayandırın. Ağ gecikme süresi iki alanda önemli bir rol oynar:
    • Zaman uyumlu çoğaltmaya sahip olması gereken iki veritabanı örneği arasındaki gecikme süresi. Bölgeler arası ağ gecikme süreleri daha yüksek olan (ancak 1,5 milisaniyeden az) en büyük NetWeaver ve S/4HANA sistemlerinin çok başarılı işlemlerine dayanarak, bu durum göz ardı edilebilir.
    • Aynı bölgede aktif veritabanı örneği ile SAP diyalog örneği çalıştıran bir VM ile başka bir bölgede benzer bir VM arasındaki ağ gecikme süresi farkı. Bu fark arttıkça, iş süreçlerinin ve toplu işlerin çalışma süresi üzerindeki etkisi de veritabanıyla bölge içinde mi yoksa farklı bir bölgede mi çalıştırılmalarına bağlı olarak artar (bu makalenin devamında bakın).
  • En büyük bölgelerde bile Azure Kullanılabilirlik Alanları ile ağ gecikme süresi SAP iş süreçlerini çalıştırmak için yeterince düşüktür. Şu ana kadar müşterilerin SAP uygulama katmanını ve veritabanı katmanını tek bir veri merkezi ağ omurgası altında birlikte kullanmaları gereken olağanüstü durumlardan yalnızca birkaçını gördük.

Azure VM'lerini Kullanılabilirlik Alanları dağıttığınızda ve aynı Azure bölgesinde yük devretme çözümleri kurduğunuzda bazı kısıtlamalar uygulanır:

  • Azure Kullanılabilirlik Alanları'a dağıtım yaparken Azure Yönetilen Diskler kullanmanız gerekir.
  • Bölge numaralandırmalarının fiziksel bölgelere eşlenmesi Azure aboneliği temelinde sabitlenir. SAP sistemlerinizi dağıtmak için farklı abonelikler kullanıyorsanız, her abonelik için ideal bölgeleri tanımlamanız gerekir. Farklı aboneliklerinizin mantıksal eşlemesini karşılaştırmak istiyorsanız Avzone Eşleme betiğini göz önünde bulundurun.
  • Azure YakınLık Yerleştirme Grubunu kullanmadığınız sürece Azure kullanılabilirlik kümelerini bir Azure Kullanılabilirlik Alanı içinde dağıtamazsınız. SAP veritabanı katmanını ve merkezi hizmetleri bölgeler arasında dağıtma ve aynı zamanda kullanılabilirlik kümelerini kullanarak SAP uygulama katmanını dağıtma ve yine de VM'lere yakınlık elde etme yöntemi, SAP uygulamalarıyla en iyi ağ gecikme süresi için Azure YakınLık Yerleştirme Grupları makalesinde belgelenmiştir. Azure yakınlık yerleştirme gruplarını kullanmıyorsanız, sanal makineler için dağıtım çerçevesi olarak birini veya diğerini seçmeniz gerekir.
  • Azure Basic Load Balancer kullanarak Windows Server Yük Devretme Kümelemesi veya Linux Pacemaker'ı temel alan yük devretme kümesi çözümleri oluşturamazsınız. Bunun yerine Azure Standart Load Balancer SKU'yu kullanmanız gerekir.
  • İstediğiniz bölgesel korumayı elde etmek için ExpressRoute Gateway, VPN Gateway ve Standart Genel IP adreslerinin bölgesel sürümünü dağıtmanız gerekir.

İdeal Kullanılabilirlik Alanları birleşimi

İş süreci atamasını Oturum Açma Grupları, RFC Sunucu Grupları, Batch Sunucu Grupları ve benzeri SAP işlevleriyle yapılandırmadığınız sürece, iş süreçleri SAP uygulama katmanınızdaki farklı uygulama örneklerinde yürütülebilir. Bu gerçeğin yan etkisi, toplu işlerin etkin veritabanı örneğiyle aynı bölgede çalıştırılıp çalıştırılmaması konusunda bağımsız olarak tüm SAP uygulama örnekleri tarafından yürütülebileceğidir. Fark bölgeleri arasındaki ağ gecikme süresi farkı, bir bölge içindeki ağ gecikme süresiyle karşılaştırıldığında küçükse, toplu işlerin çalışma sürelerindeki fark önemli olmayabilir. Ancak, bölge genelinde ağ trafiğine kıyasla bir bölge içindeki ağ gecikme süresi farkı ne kadar büyükse, iş veritabanı örneğinin etkin olmadığı bir bölgede yürütülürse toplu işlerin çalışma süresi daha fazla etkilenebilir. Çalışma süresindeki kabul edilebilir farklılıkların ne olduğu müşteri olarak sizindir. Bu nedenle bölgeler arası trafik için toleranslı ağ gecikme süresi iş yükünüz için de geçerli. Yalnızca teknik açıdan bakıldığında, Azure bölgesindeki Azure Kullanılabilirlik Alanları arasındaki ağ gecikme süreleri NetWeaver, S/4HANA veya diğer SAP uygulamalarının mimarisi için geçerlidir. Ayrıca, bu makalede sunduğumuz dağıtım kavramlarından birini tercih ettiğinizde Oturum Açma Grupları, RFC Sunucu Grupları, Batch Sunucu Grupları ve benzeri SAP kavramlarını kullanarak bu tür farkları azaltma potansiyeline sahip bir müşteri olarak size aittir.

Bölgeler arasında bir SAP NetWeaver veya S/4HANA sistemi dağıtmak istiyorsanız dağıtabileceğiniz iki mimari deseni vardır:

  • Etkin/etkin: ASCS/SCS çalıştıran vm çifti ve veritabanı katmanını çalıştıran VM çifti iki bölgeye dağıtılır. SAP uygulama katmanını çalıştıran VM'ler, aynı iki bölgeye eşit sayıda dağıtılır. Bir veritabanı veya ASCS/SCS VM başka bir sunucuya devrediliyorsa, açık ve etkin işlemlerden bazıları geri alınabilir. Ancak kullanıcılar oturum açmış durumda kalır. Etkin veritabanı VM'sinin ve uygulama örneklerinin hangi bölgelerde çalıştığı önemli değildir. Bu mimari, farklı bölgelere dağıtım gerçekleştirmek için tercih edilen mimaridir. İş süreçlerini yürütürken bölgeler arasındaki ağ gecikme sürelerinin daha büyük farklılıklara neden olduğu durumlarda, iş süreçlerinin yürütülmesini etkin veritabanı örneğiyle aynı bölgede bulunan belirli iletişim kutusu örneklerine yönlendirmek için SAP Oturum Açma Grupları, RFC Sunucu Grupları, Batch Sunucu Grupları gibi işlevleri kullanabilirsiniz
  • Etkin/pasif: ASCS/SCS çalıştıran vm çifti ve veritabanı katmanını çalıştıran VM çifti iki bölgeye dağıtılır. SAP uygulama katmanını çalıştıran VM'ler Kullanılabilirlik Alanları birine dağıtılır. Uygulama katmanını etkin ASCS/SCS ve veritabanı örneğiyle aynı bölgede çalıştırırsınız. Farklı bölgelerdeki ağ gecikme süresini çok yüksek olarak düşünüyorsanız bu dağıtım mimarisini kullanabilirsiniz. Bu da iş süreçlerinizin işleyiş süresinde katlanılamaz farklılıklara neden olur. Veya Kullanılabilirlik Alanı dağıtımlarını Kısa Mesafe DR dağıtımları olarak kullanmak istiyorsanız. bölgeler. ASCS/SCS veya veritabanı VM'si ikincil bölgeye geçerse, daha yüksek ağ gecikme süresi ve bunun sonucunda verimlilikte bir azalma ile karşılaşabilirsiniz. Önceki aktarım hızı düzeylerine geri dönebilmek için, daha önce devrettiğiniz VM'yi mümkün olan en kısa sürede geri yüklemeniz gerekir. Bölgesel bir kesinti oluşursa, uygulama katmanının ikincil bölgeye aktarılması gerekir. Kullanıcıların tam sistem kapatma olarak deneyimlediği bir etkinlik.

Bu nedenle Kullanılabilirlik Alanları nasıl kullanacağınıza karar vermeden önce şunları belirlemeniz gerekir:

  • Azure bölgesinin üç bölgesi arasındaki ağ gecikme süresi. Bir bölgenin bölgeleri arasındaki ağ gecikme süresini bilmek, bölgeler arası ağ trafiğinde en az ağ gecikme süresine sahip bölgeleri seçmenize olanak tanır.
  • Seçtiğiniz bölgelerden biri içindeki VM'lerden VM'ye gecikme süresi ile seçtiğiniz iki bölge arasında ağ gecikme süresi arasındaki fark.
  • Dağıtmanız gereken VM türlerinin seçtiğiniz iki bölgede kullanılabilir olup olmadığını belirleme. Bazı VM SKU'larında, bazı SKU'ların üç bölgeden yalnızca ikisinde kullanılabildiği durumlarla karşılaşabilirsiniz.

Bölgeler arasındaki ve içindeki ağ gecikme süresi

Farklı bölgeler arasındaki gecikme süresini belirlemek için şunları yapmanız gerekir:

  • Veritabanı örneğiniz için kullanmak istediğiniz VM SKU'yu üç bölgede de dağıtın. Bu ölçümü aldığınızda Azure Hızlandırılmış Ağ'ın etkinleştirildiğinden emin olun. Hızlandırılmış Ağ, birkaç yıldan bu yana varsayılan ayardır. Bununla birlikte, etkinleştirilip etkinleştirilmediğini ve çalışıp çalışmadığını denetleyin
  • En az ağ gecikmesine sahip iki bölgeyi bulduğunuzda, üç Kullanılabilirlik Alanına uygulama katmanı VM olarak kullanmak istediğiniz VM SKU'sunun üç VM'sini daha dağıtın. Seçtiğiniz iki bölgede yer alan iki veritabanı VM'sine göre ağ gecikme süresini ölçün.
  • Ölçüm aracı olarak kullanın niping . SAP'nin bu aracı SAP destek notları #500235 ve #1100926 açıklanmıştır. SAP Note #1100926'daki ağ gecikmesi sınıflandırmasını kaba kılavuz olarak değerlendirin. 0,7 milisaniyeden büyük ağ gecikme süreleri, sistemin teknik olarak çalışmayacağını veya iş süreçlerinin tek tek SLA'larınızı karşılamadığını ifade etmiyor. Not, SAP ve/veya Microsoft tarafından desteklenen veya desteklenmeyenleri belirtmek için tasarlanmamıştır. Gecikme süresi ölçümleri için belgelenen komutlara odaklanın. Ping, Azure Hızlandırılmış Ağ kodu yollarında çalışmadığından, bunu kullanmanızı önermeyiz.

Bu testleri el ile yapmanız gerekmez. Açıklanan gecikme testlerini otomatik hale getiren bir PowerShell yordamı Kullanılabilirlik Alanı Gecikme Testi bulabilirsiniz.

Ölçümlerinize ve vm SKU'larınızın Kullanılabilirlik Alanları kullanılabilirliğine bağlı olarak bazı kararlar vermeniz gerekir:

  • Veritabanı katmanı için ideal bölgeleri tanımlayın.
  • Bölge içindeki ağ gecikme süresi farklarına göre, etkin SAP uygulama katmanınızı bir, iki veya üç bölge arasında dağıtmak isteyip istemediğinizi belirleyin.
  • Uygulama açısından etkin/pasif yapılandırmayı mı yoksa etkin/etkin yapılandırmayı mı dağıtmak istediğinizi belirleyin. (Bu yapılandırmalar bu makalenin ilerleyen bölümlerinde açıklanmıştır.)

Önemli

Yaptığınız ölçümler ve kararlar, ölçümleri alırken kullandığınız Azure aboneliği için geçerlidir. Başka bir Azure aboneliği kullanıyorsanız, numaralandırılmış bölgelerin eşlemesi başka bir Azure aboneliği için farklı olabilir. Sonuç olarak, ölçümleri tekrarlamanız veya Avzone-Mapping betiği aracını kullanarak eski aboneliğe göre yeni aboneliğin eşlemesini bulmanız gerekir.

Önemli

Daha önce açıklanan ölçümlerin Kullanılabilirlik Alanları destekleyen her Azure bölgesinde farklı sonuçlar sağlaması beklenir. Ağ gecikme süresi gereksinimleriniz aynı olsa bile, bölgeler arasındaki ağ gecikme süresi farklı olabileceğinden farklı Azure bölgelerinde farklı dağıtım stratejilerini benimsemeniz gerekebilir. Bazı Azure bölgelerinde, üç farklı bölge arasındaki ağ gecikme süresi büyük ölçüde farklı olabilir. Diğer bölgelerde, üç farklı bölge arasındaki ağ gecikme süresi daha tekdüzen olabilir. Her zaman 1 ile 2 milisaniye arasında bir ağ gecikme süresi olduğu iddiası doğru değildir. Azure bölgelerindeki Kullanılabilirlik Alanları ağ gecikme süresi genelleştirilemez.

Aktif/Aktif dağıtım

Etkin SAP uygulama sunucularınızı iki veya üç bölgeye dağıttığınızdan bu dağıtım mimarisi etkin/etkin olarak adlandırılır. Sıra çoğaltma kullanan SAP Central Services örneği iki bölge arasında dağıtılır. Sap Central Service ile aynı bölgelere dağıtılan veritabanı katmanı için de aynı durum geçerlidir. Bu yapılandırmayı değerlendirirken, bölgenizde iş yükünüz için kabul edilebilir bölgeler arası ağ gecikme süresi sunan iki Kullanılabilirlik Alanları bulmanız gerekir. Ayrıca seçtiğiniz bölgelerdeki ağ gecikme süresi ile bölgeler arası ağ gecikme süresi arasındaki deltanın iş yükünüz için kabul edilebilir olduğundan emin olmak istiyorsunuz.

Etkin/etkin dağıtımın iki bölgede basitleştirilmiş bir şeması şöyle görünebilir:

Etkin/Etkin bölge konuşlandırma

Bu yapılandırma için aşağıdaki önemli noktalar geçerlidir:

Etkin/Pasif dağıtım

SAP iş süreçlerinin çalışma zamanında olası deltayı azaltan bir yapılandırma bulamazsanız veya kısa mesafeli olağanüstü durum kurtarma yapılandırması dağıtmak istiyorsanız, SAP uygulama katmanı bakış açısından etkin/pasif karaktere sahip bir mimari dağıtabilirsiniz. Tam uygulama katmanını dağıttığınız ve hem etkin veritabanı örneğini hem de SAP Central Services örneğini çalıştırmayı denediğiniz etkin bir bölge tanımlarsınız. Böyle bir yapılandırmada, iş süreçlerinde ve toplu işlemlerde, bir işin etkin veritabanı örneğiyle aynı bölgede çalışıp çalışmadığına bağlı olarak aşırı çalışma süresi varyasyonları yaşamamak için emin olmanız gerekir.

Mimarinin temel düzeni şöyle görünür:

Etkin/Pasif bölge dağıtımı

Bu yapılandırma için aşağıdaki önemli noktalar geçerlidir:

Birleştirilmiş yüksek kullanılabilirlik ve olağanüstü durum kurtarma yapılandırması

Microsoft, bir Azure bölgesinde farklı Azure Kullanılabilirlik Alanları barındıran tesisler arasındaki coğrafi mesafeler hakkında hiçbir bilgi paylaşmaz. Yine de bazı müşteriler, sıfır kurtarma noktası hedefi (RPO) vaat eden birleştirilmiş HA ve DR yapılandırması (kısa mesafe DR) için bölgeleri kullanıyor. Sıfır RPO değeri, olağanüstü durum kurtarma durumlarında bile kaydedilmiş veritabanı işlemlerini kaybetmemeniz gerektiği anlamına gelir.

Not

Kullanılabilirlik Alanları küçük mesafeli DR çözümü olarak kullanıyorsanız, güç altyapılarında ağır ve yaygın hasarlar da dahil olmak üzere dünyanın farklı bölgelerinde yaygın hasara neden olan doğal afetlerle karşılaştığımızı unutmayın. Çeşitli bölgeler arasındaki mesafeler her zaman bu kadar büyük doğal afetleri telafi edecek kadar büyük olmayabilir.

Bu tür bir yapılandırmanın nasıl görünebileceğine bir örnek aşağıda verilmişti:

Bölgelerde birleştirilmiş yüksek kullanılabilirlik DR'sı

Bu yapılandırma için aşağıdaki önemli noktalar geçerlidir:

Sonraki adımlar

Azure Kullanılabilirlik Alanları'da dağıtmaya yönelik bazı sonraki adımlar şunlardır: