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

Ayrıca, Azure kullanılabilirlik kümelerinde farklı SAP mimari katmanlarının dağıtımına ek olarak, daha önce sunulan Azure KULLANıLABILIRLIK ALANLARı SAP iş yükü dağıtımları için de kullanılabilir. Bir Azure kullanılabilirlik bölgesi: "bir bölge içinde benzersiz fiziksel konumlar olarak tanımlanır. 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ınıdenetleyin. Bu harita, Kullanılabilirlik Alanları sağlamak için hangi bölgelerin sunduğunu veya duyurduğunu gösterir.

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

• SAP uygulama katmanı, bir kaç düzine VM 'ye kadar olabilir. VM 'lerin aynı konak sunucusuna dağıtılması olasılığını en aza indirmek istiyorsunuz. Ayrıca, kabul edilebilir bir pencerede ağ gecikmesini korumak için bu VM 'Leri DBMS katmanına kabul edilebilir bir biçimde istiyorsunuz
• SAP NetWeaver ve S/4HANA mimarisinde tek bir başarısızlık noktasını temsil eden SAP yoks/SCS katmanı. Genellikle bir yük devretme çerçevesiyle birlikte kapsamak istediğiniz iki VM 'ye bakmanız gerekir. Bu nedenle, bu VM 'Ler farklı altyapı hatası ve güncelleştirme etki alanlarında ayrılmalıdır
• SAP DBMS katmanı, tek bir başarısızlık noktasını temsil eder. Her zamanki durumlarda, bir yük devretme çerçevesi kapsamındaki iki VM 'den oluşur. Bu nedenle, bu VM 'Ler farklı altyapı hatası ve güncelleştirme etki alanlarında ayrılmalıdır. Özel durumlar, ikiden fazla VM 'nin kullanılabileceği genişleme dağıtımlarıdır SAP HANA

Kritik sanal makinelerinizi kullanılabilirlik kümeleri veya Kullanılabilirlik Alanları aracılığıyla dağıtma arasındaki önemli farklılıklar şunlardır:

• Bir kullanılabilirlik kümesiyle dağıtmak, küme içindeki VM 'Leri tek bir bölgede veya veri merkezinde (belirli bölge için geçerli olan) yukarı yerleştirirler. Sonuç olarak, kullanılabilirlik kümesi üzerinden dağıtım, bölgenin bir bütün olarak veri serilerini etkileyen güç, soğutma veya ağ sorunları ile korunmaz. Artı tarafında VM 'Ler, bu bölgedeki veya veri merkezindeki güncelleştirme ve hata etki alanları ile hizalanır. Kullanılabilirlik kümesi başına iki VM 'yi koruduğumuz SAP yoks veya DBMS katmanı için, hata ve güncelleştirme etki alanlarına yönelik hizalama her iki VM 'nin de aynı konak donanımında sonlandırmasını önler
• VM 'Leri bir Azure Kullanılabilirlik Alanları ile dağıtma ve farklı bölgeler (şimdiye kadar en fazla mümkün olan en fazla) seçme, VM 'Leri farklı fiziksel konumlara dağıtmak ve bu sayede, bölgenin veri cılarını bir bütün olarak etkileyen güç, soğutma veya ağ sorunlarından ek koruma ekler. Ancak, aynı VM ailesinden birden fazla VM 'yi aynı Kullanılabilirlik alanına dağıtırken, bu VM 'lerden aynı konakta sonlanan bir koruma yoktur. Sonuç olarak, Kullanılabilirlik Alanları dağıtım, genellikle iki VM 'ye baktığımız SAP ASCS ve DBMS katmanı için idealdir. İki VM 'den büyük ölçüde daha fazla olabilecek SAP uygulama katmanı için, farklı bir dağıtım modeline geri dönebilmeniz gerekebilir (daha sonra bkz.)

Azure Kullanılabilirlik Alanları genelindeki bir dağıtıma ilişkin işlem, tek bir kritik VM 'nin hatasını kapsayan veya kritik bir süre içinde yazılım düzeltme eki uygulama için kapalı kalma süresini azaltma yeteneğinin bir veya birden çok Azure veri merkezinin kullanılabilirliğini etkileyebilecek daha büyük altyapı sorunlarından korunmak için yapmanız gerekir.

Kullanılabilirlik Alanları genelinde dağıtım konuları

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

• Bir Azure bölgesi içindeki çeşitli Kullanılabilirlik Alanları arasındaki uzaklıklarla ilgili garanti yoktur.
• Kullanılabilirlik Alanları ideal bir DR çözümü değildir. Doğal felaketler, uluslararası altyapılara ağır hasar da dahil olmak üzere dünya bölgelerinde yaygın olarak hasar verebilir. Çeşitli bölgeler arasındaki uzaklıklar doğru bir DR çözümü sağlayacak kadar büyük olmayabilir.
• Kullanılabilirlik Alanları arasındaki ağ gecikmesi tüm Azure bölgelerinde aynı değildir. Bazı durumlarda, bir bölgeden etkin DBMS VM 'sine yönelik ağ gecikmesi kabul edilebilir olduğundan SAP uygulama katmanını farklı bölgelerde dağıtabilir ve çalıştırabilirsiniz. Ancak bazı Azure bölgelerinde, farklı bölgelerde dağıtıldığında etkin DBMS sanal makinesi ve SAP uygulama örneği arasındaki gecikme süresi, SAP iş işlemlerinde kabul edilebilir olmayabilir. Bu durumlarda, dağıtım mimarisinin farklı olması gerekir, uygulama için etkin/etkin mimari veya çapraz bölge ağ gecikmesi çok yüksek olduğunda bir etkin/Pasif mimari.
• Kullanılabilirlik Alanları nerede kullanacağınızı saptarken, bölgeler arasındaki ağ gecikmesi üzerinde kararınızı temel alır. Ağ gecikmesi iki alanda önemli bir rol oynar:
  • Zaman uyumlu çoğaltmaya sahip olması gereken iki DBMS örneği arasındaki gecikme süresi. Ağ gecikmesi arttıkça, iş yükünüzün ölçeklenebilirliğini de etkiler.
  • Etkin DBMS örneğiyle bir SAP iletişim kutusu örneği çalıştıran bir VM ve başka bir bölgedeki 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 etki, DBMS ile veya farklı bir bölgede bölge içinde çalıştırıldıklarından bağımsız olarak da artar.

Azure VM 'lerini Kullanılabilirlik Alanları genelinde dağıtırken ve aynı Azure bölgesinde yük devretme çözümleri oluşturduğunuzda, bazı kısıtlamalar uygulanır:

• Azure Kullanılabilirlik Alanları ' a dağıtırken Azure yönetilen diskleri kullanmanız gerekir.
• Bölge Numaralandırmaların fiziksel bölgelere eşlenmesi, bir Azure aboneliği temelinde düzeltilmelidir. SAP sistemlerinizi dağıtmak için farklı abonelikler kullanıyorsanız, her abonelik için ideal bölgeleri tanımlamanız gerekir.
• Azure yakınlık yerleşimi grubunukullanmadığınız takdirde Azure kullanılabilirlik gruplarını bir Azure kullanılabilirlik bölgesi içinde dağıtamazsınız. SAP DBMS katmanını ve merkezi hizmetleri bölgelere dağıtmak ve aynı zamanda SAP uygulama katmanını kullanılabilirlik kümeleri kullanarak dağıtma ve yine de VM 'lerin yakınlığını elde etme yöntemi, SAP uygulamalarıyla en iyi ağ gecikme süresi Için Azure yakınlık yerleşimi gruplarımakalesinde belgelenmiştir. Azure yakınlık yerleşimi gruplarını kullanmıyorsanız, sanal makineler için bir dağıtım çerçevesi olarak bir veya diğerini seçmeniz gerekir.
• Windows sunucusu yük devretme kümelemesi veya Linux paceyapıcısı temelinde yük devretme kümesi çözümleri oluşturmak için Azure temel Load Balancer kullanamazsınız. Bunun yerine, Azure Standart Load Balancer SKU'sunu kullanmanız gerekir.

İdeal Kullanılabilirlik Alanları birleşimi

Bir SAP NetWeaver veya S/4HANA sistemini bölgeler arasında dağıtmak istiyorsanız, dağıtabileceğiniz iki ilke mimarisi vardır:

• Etkin/etkin: yoks/SCS çalıştıran VM 'lerin çifti ve DBMS katmanını çalıştıran VM 'lerin çifti iki bölgeye dağıtılır. SAP uygulama katmanını çalıştıran VM 'lerin sayısı, aynı iki bölge genelinde çift sayılara dağıtılır. Bir DBMS veya yoks/SCS sanal makinesi yük devrettikten sonra bazı açık ve etkin işlemler geri alınabilir. Ancak kullanıcılar oturum açtı. Etkin DBMS sanal makinesi ve uygulama örneklerinin hangi bölgelerden çalıştırıldıklarından emin değildir. Bu mimari, bölgeler arasında dağıtım için tercih edilen mimaridir.
• Etkin/Pasif: yoks/SCS çalıştıran VM 'lerin çifti ve DBMS katmanını çalıştıran VM 'lerin çifti iki bölgeye dağıtılır. SAP uygulama katmanını çalıştıran VM 'lerin sayısı Kullanılabilirlik Alanları birine dağıtılır. Uygulama katmanını, etkin yoks/SCS ve DBMS örneğiyle aynı bölgede çalıştırırsınız. Farklı bölgelerde ağ gecikmesi, bölgeler arasında dağıtılan uygulama katmanını çalıştırmak için çok yüksekse, bu dağıtım mimarisini kullanırsınız. Bunun yerine, SAP uygulama katmanının etkin yoks/SCS ve/veya DBMS örneğiyle aynı bölgede çalışması gerekir. Bir ASCS/SCS veya DBMS sanal makinesi ikincil bölgeye yük devreder, daha yüksek ağ gecikme süresi ve aktarım hızı azalmasıyla karşılaşabilirsiniz. Daha önce yük devretme düzeylerine geri dönmek için, daha önce yük devredilen VM 'yi mümkün olduğunca geri almanız gerekir. Bir bölgesel kesintisi oluşursa, uygulama katmanının yük devretilmesi için ikincil bölgeye yük devri gerekir. Kullanıcıların tüm sistem kapatması olarak deneyilecekleri bir etkinlik. Azure bölgelerinde bu mimari, Kullanılabilirlik Alanları kullanmak istediğinizde yalnızca önemli mimaridir. İkincil bölgeye yük devredilemeyen bir ASCS/SCS veya DBMS VM 'lerinin olası etkisini kabul edemeyebilirsiniz, kullanılabilirlik kümesi dağıtımlarıyla daha iyi olabilirsiniz

Bu nedenle Kullanılabilirlik Alanları kullanmaya karar vermeden önce şunları belirlemeniz gerekir:

• Bir Azure bölgesinin üç bölgesi arasındaki ağ gecikmesi. Bir bölgenin bölgeleri arasındaki ağ gecikmesini bilmeniz, bölgeler arası ağ trafiğinden en az ağ gecikme süresine sahip bölgeleri seçmenizi sağlar.
• Bir bölgede bulunan VM-VM gecikme süresi ve seçtiğiniz iki bölge arasındaki ağ gecikmesi arasındaki fark.
• Dağıtmanız gereken sanal makine türlerinin seçtiğiniz iki bölgede kullanılabilir olup olmadığını belirleme. Bazı VM 'Lerde, özellikle de a serisi VM 'lerle, bazı SKU 'Ların üç bölgenin yalnızca iki bölgede kullanılabildiği durumlarla karşılaşabilirsiniz.

Bölgeler arasında ve içinde ağ gecikmesi

Farklı bölgeler arasındaki gecikmeyi öğrenmek için şunları yapmanız gerekir:

• Her üç bölgede DBMS örneğiniz için kullanmak istediğiniz VM SKU 'sunu dağıtın. Bu ölçümü gerçekleştirdiğinizde Azure hızlandırılmış ağ 'ın etkinleştirildiğinden emin olun.
• En az ağ gecikmesi olan iki bölgeyi bulduğunuzda, üç Kullanılabilirlik Alanları üzerinde uygulama katmanı VM 'si olarak kullanmak istediğiniz VM SKU 'sunun başka üç VM 'sini dağıtın. Seçtiğiniz iki DBMS bölgesindeki iki DBMS sanal makinesi için ağ gecikmesini ölçün.
• niping Ölçüm aracı olarak kullanın. SAP 'nin bu aracı, SAP destek notları #500235 ve #1100926açıklanmaktadır. Gecikme süresi ölçümleri için belgelenen komutlara odaklanın. Ping , Azure hızlandırılmış ağ kodu yolları üzerinden çalışmadığından, bunu kullanmanızı önermiyoruz.

Bu testleri el ile gerçekleştirmeniz gerekmez. Açıklanan gecikme süresi testlerini otomatikleştiren bir PowerShell yordamı kullanılabilirlik bölgesi gecikme testi bulabilirsiniz.

Ölçümlerinizi ve Kullanılabilirlik Alanları sanal makine SKU 'larınızın kullanılabilirliğine göre, bazı kararlar vermeniz gerekir:

• DBMS katmanının ideal bölgelerini tanımlayın.
• Etkin SAP uygulama katmanınızı bir, iki veya üç bölgenin tamamında, bölgedeki ağ gecikme süresinin bölge genelinde farklılıklar temelinde dağıtmak isteyip istemediğinizi belirleme.
• Bir uygulama görünümünden etkin/Pasif bir yapılandırma ya da etkin/etkin bir yapılandırma dağıtmak istediğinizi belirleme. (Bu konfigürasyonlar Bu makalenin ilerleyen kısımlarında açıklanmaktadır.)

Bu kararları verirken SAP Note #1100926bölümünde belgelendiği gibi, hesap SAP 'nin ağ gecikmesi önerilerini de göz önünde bulabilirsiniz.

Etkin/Etkin dağıtım

Etkin SAP uygulama sunucularınızı iki veya üç bölgeye dağıtan bu dağıtım mimarisi etkin/etkin olarak adlandırılan bir mimaridir. Enqueue çoğaltma kullanan SAP Central Services örneği iki bölge arasında dağıtılır. Aynı durum, SAP Central Service ile aynı bölgelere dağıtılacak OLAN DBMS katmanı için de aynıdır. Bu yapılandırmayı göz önünde bulundurarak, Kullanılabilirlik Alanları iş yükünüz ve zaman uyumlu DBMS çoğaltmanız için kabul edilebilir olan bölgeler arası ağ gecikme süresi sunan iki farklı bölgeyi bulmanız gerekir. Ayrıca, seçtiğiniz bölgelerdeki ağ gecikmesi arasındaki deltanın ve bölgeler arası ağ gecikme süresinin çok büyük olduğundan emin olmak da gerekir.

SAP mimarisinin doğası gereği, bunu farklı yapılandırmadıkça kullanıcıların ve toplu işlerin farklı uygulama örneklerinde yürütülebilir olmasıdır. Bu gerçeğin etkin/etkin dağıtımla yan etkisi, toplu işlerin, bunların etkin DBMS ile aynı bölgede çalıştırıp çalıştırmama konusunda bağımsız olarak herhangi bir SAP uygulama örneği tarafından yürütülebilir olmasıdır. Fark bölgeleri arasındaki ağ gecikme süresi farkı, bir bölge içindeki ağ gecikme süresine kıyasla küçükse, toplu işlerin çalışma zamanları arasındaki fark önemli olmayacaktır. Ancak, bir bölge içindeki ağ gecikme süresi farkı bölge ağ trafiği arasında ne kadar büyük olursa, iş DBMS örneğinin etkin olduğu bir bölgede yürütülürse toplu işlerin çalışma süresi daha fazla etkilenebildi. Çalışma süresinde kabul edilebilir farkların ne olduğuna müşteri olarak karar vermek size bağlı. Ayrıca bölgeler arası trafiğin tolere edilebilir ağ gecikme süresi de bu şekildedir.

Farklı dağıtımlar arasında dağıtılan uygulama katmanında çalışma süresi ve aktarım hızı arasında büyük farklar olmadan böyle bir etkin/etkin dağıtımın mümkün Kullanılabilirlik Alanları Azure bölgeleri:

• Batı ABD2 (üç bölge de)
• Doğu ABD2 (üç bölge de)
• Orta ABD (üç bölge de)
• Kuzey Avrupa (üç bölge de)
• Batı Avrupa (üç bölgeden ikisi)
• Doğu ABD (üç bölgeden ikisi)
• Orta Güney ABD (üç bölgeden ikisi)
• Güney Birleşik Krallık (üç bölgeden ikisi)
• Güneydoğu Asya

Bölgeler arasında bu SAP dağıtım mimarisinin önerilmez olduğu Azure bölgeleri:

• Orta Fransa
• Güney Afrika - Kuzey
• Orta Kanada
• Doğu Japonya

Çalışma zamanı farklılıklarını kabul etmeye istekli olduğunuz sürece listede yer almayan diğer bölgeler de buna uygun olabilir.

İki bölge arasında etkin/etkin bir dağıtımın basitleştirilmiş şeması şöyle olabilir:

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

• Azure YakınLık Yerleştirme Grubu'Azure Kullanılabilirlik Alanlarıtüm VM'ler için hata ve güncelleştirme etki alanları olarak kabul edersiniz çünkü kullanılabilirlik kümeleri sanal Azure Kullanılabilirlik Alanları.
• DBMS katmanı ve merkezi hizmetler için bölge dağıtımlarını birleştirmek, ancak uygulama katmanı için Azure kullanılabilirlik kümelerini kullanmak istiyorsanız, SAP uygulamalarıyla en iyi ağ gecikme süresi için Azure Yakınlık Yerleştirme Grupları makalesinde açıklandığı gibi Azure yakınlık gruplarını kullanmalısınız.
• SAP Central Services ve DBMS katmanının yük devretme kümeleri için Standart SKU'Azure Load Balancer. Temel Load Balancer bölgeler arasında çalışmaz.
• SAP sistemini barındırmak için dağıtmış olduğunuz Azure sanal ağı, alt ağlarla birlikte bölgeler arasında esnetilmiş olur. Her bölge için ayrı sanal ağlara ihtiyacınız yok.
• Dağıtan tüm sanal makineler için AzureYönetilen Diskler. Bölge dağıtımları için, unmanaged diskler desteklenmiyor.
• Azure Premium Depolama, Ultra SSD depolamaalanı veya ANF, bölgeler arasında herhangi bir depolama çoğaltma türünü desteklemez. Uygulamanın (DBMS veya SAP Central Services) önemli verileri çoğaltması gerekir.
• Paylaşılan disk (Windows), CIFS paylaşımı (Windows) veya NFS paylaşımı (Linux) olan paylaşılan sapmnt dizini için de aynı durum aynıdır. Bu paylaşılan diskleri veya paylaşımları bölgeler arasında çoğaltan bir teknoloji kullanmalısınız. Bu teknolojiler de desteklemektedir:

  • Daha Windows, Azure'da küme paylaşılan diski kullanarak bir Windows yük devretme kümesinde SAP ASCS/SCSörneği kümeleme altında belgelenmiş şekilde SIOS DataKeeper kullanan bir küme çözümüdür.

  • SUSE Linux için, SUSE LinuxEnterprise Server üzerinde Azure VM'leri üzerinde NFS için yüksek kullanılabilirlik altında belgelenmiş olarak bir NFS paylaşımı.

    Şu anda, Sap ASCS/SCSörnekleri için bir Windows yük devretme kümesi ve dosya paylaşımı kullanarak Azure altyapısını SAP yüksek kullanılabilirliği için hazırlama makalesinde belgelenmiş şekilde Microsoft Scale-Out Dosya Sunucusu'nun kullandığı çözüm bölgeler arasında desteklenmemektedir.

• Bir SUSE Linux Pacemaker kümesi derlemeniz ve Azure Fencing Agent yerine SBD cihazları kullanıyorsanız SBD cihazı barındırmak için üçüncü bölge kullanılır. Veya ek uygulama örnekleri için.
• Kritik iş süreçleri için çalışma zamanı tutarlılığı elde etmek için, SAP batch sunucu gruplarını, SAP oturum açma gruplarını veya RFC gruplarını kullanarak belirli toplu işleri ve kullanıcıları etkin DBMS örneğiyle bölge içinde uygulama örneklerine yönlendirebilirsiniz. Ancak, bir bölge yük devretmesi durumunda, bu grupları etkin VERITABANı VM'sinde bölge içinde olan VM'lerde çalışan örneklere el ile taşımanız gerekir.
• Her bir bölgeye uykuda iletişim kutusu örnekleri dağıtmak istiyor olabilir.

Etkin/Pasif dağıtım

Bir bölge içindeki ağ gecikmesi ile bölgeler arası ağ trafiğinin gecikme süresi arasında kabul edilebilir bir delta bulamazsanız, SAP uygulama katmanı görünümünden etkin/pasif karaktere sahip bir mimari dağıtabilirsiniz. Tam uygulama katmanını dağıtan ve hem etkin DBMS'yi hem de SAP Central Services örneğini çalıştırmayı çalıştığınız bölge olan etkin bir bölge tanımlarsiniz. Bu tür bir yapılandırmayla, bir işin etkin DBMS örneğiyle bölgede çalıştırıp çalıştırmama durumuna bağlı olarak, iş işlemleri ve toplu işlerde aşırı çalışma süresi varyasyonları olmadığınızdan emin olun.

Farklı bölgeler arasında bu tür bir dağıtım mimarisinin tercih edilebilir olduğu Azure bölgeleri:

• Doğu Avustralya
• Güney Brezilya
• Orta Batı Almanya
• Güney Afrika - Kuzey
• Orta Fransa
• Orta Kanada
• Doğu Japonya

Mimarinin temel düzeni şöyledir:

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

• Kullanılabilirlik kümeleri bu kümelere Azure Kullanılabilirlik Alanları. Bunu telafi etmek için, SAP uygulamalarıyla en iyi ağ gecikme süresi için Azure YakınLık Yerleştirme Grupları makalesinde belgelenmiş olan Azure yakınlık yerleştirme gruplarını kullanabilirsiniz.

• Bu mimariyi kullanırken, durumu yakından izlemeli ve etkin DBMS ile SAP Central Services örneklerini dağıtılan uygulama katmanınız ile aynı bölgede tutmaya çalışmanız gerekir. SAP Central Service veya DBMS örneğinin yük devretmesi durumunda, SAP uygulama katmanının mümkün olan en hızlı şekilde dağıtılmasıyla bölgeye el ile yeniden çalışmanız gerekir.

• SAP Central Services ve DBMS katmanının yük devretme kümeleri için Standart SKU'Azure Load Balancer. Temel Load Balancer bölgeler arasında çalışmaz.

• SAP sistemini barındırmak için dağıtmış olduğunuz Azure sanal ağı, alt ağlarla birlikte bölgeler arasında esnetilmiş olur. Her bölge için ayrı sanal ağlara ihtiyacınız yok.

• Dağıtan tüm sanal makineler için AzureYönetilen Diskler. Bölge dağıtımları için, unmanaged diskler desteklenmiyor.

• Azure Premium Depolama, Ultra SSD depolamaalanı veya ANF, bölgeler arasında herhangi bir depolama çoğaltma türünü desteklemez. Uygulamanın (DBMS veya SAP Central Services) önemli verileri çoğaltması gerekir.

• Paylaşılan disk (Windows), CIFS paylaşımı (Windows) veya NFS paylaşımı (Linux) olan paylaşılan sapmnt dizini için de aynı durum aynıdır. Bu paylaşılan diskleri veya paylaşımları bölgeler arasında çoğaltan bir teknoloji kullanmalısınız. Bu teknolojiler de desteklemektedir:

  • Daha Windows, Azure'da küme paylaşılan diski kullanarak bir Windows yük devretme kümesinde SAP ASCS/SCSörneği kümeleme altında belgelenmiş şekilde SIOS DataKeeper kullanan bir küme çözümüdür.
  • SUSE Linux için, SUSE LinuxEnterprise Server üzerinde Azure VM'leri üzerinde NFS için yüksek kullanılabilirlik altında belgelenmiş olarak bir NFS paylaşımı.

  Şu anda, Sap ASCS/SCSörnekleri için bir Windows yük devretme kümesi ve dosya paylaşımı kullanarak Azure altyapısını SAP yüksek kullanılabilirliği için hazırlama makalesinde belgelenmiş şekilde Microsoft Scale-Out Dosya Sunucusu'nun kullandığı çözüm bölgeler arasında desteklenmemektedir.

• Bir SUSE Linux Pacemaker kümesi derlemeniz ve Azure Fencing Agent yerine SBD cihazları kullanıyorsanız SBD cihazı barındırmak için üçüncü bölge kullanılır. Veya ek uygulama örnekleri için.

• Pasif bölgede (DBMS bakış açısından) kesintiye neden olan VM'leri dağıtarak bölge hatası durumunda uygulama kaynaklarını başlatabilirsiniz.

  • Azure Site Recovery Şu anda, etkin VM 'leri bölgeler arasında etkin olmayan VM 'lere çoğaltamaz.

• Bir bölgesel kesintisi oluşursa, ikinci bölgede SAP uygulama katmanını otomatik olarak başlatabilmeniz için Otomasyon 'a yatırım yapmanız gerekir.

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

Microsoft, bir Azure bölgesindeki farklı Azure Kullanılabilirlik Alanları barındıran tesislerde coğrafi uzaklıklar hakkında herhangi bir bilgi paylaşmaz. Yine de bazı müşteriler, bir kurtarma noktası hedefini (RPO) içeren bir birleştirilmiş HA ve DR yapılandırması için bölgeleri kullanıyor. Sıfır RPO 'SU, olağanüstü durum kurtarma durumunda bile, tüm kaydedilmiş veritabanı işlemlerini kaybetmemeniz gerektiği anlamına gelir.

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

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

• Bir kullanılabilirlik bölgesini barındıran tesislerin arasında önemli bir mesafe olduğunu veya belirli bir Azure bölgesi içinde kalmaya zorladığınızı varsayalım. Kullanılabilirlik kümeleri Azure Kullanılabilirlik Alanları ' de dağıtılamaz. Bunu dengelemek için, SAP uygulamalarıyla en iyi ağ gecikme süresi Için Azure yakınlık yerleşimi gruplarımakalesinde belgelenen Azure yakınlık yerleşimi gruplarını kullanabilirsiniz.

• Bu mimariyi kullandığınızda, durumu yakından izlemeniz ve etkin DBMS ve SAP Merkezi Hizmetleri örneklerini dağıtılan uygulama katmanınız ile aynı bölgede tutmaya çalışmalısınız. SAP Merkezi hizmetinin veya DBMS örneğinin yük devretmesi durumunda, mümkün olduğunca hızlı bir şekilde dağıtılmış SAP uygulama katmanı ile bölgeye el ile yeniden oturum açmak istiyorsanız emin olmanız gerekir.

• Etkin QA uygulama örneklerini çalıştıran VM 'lerde önceden yüklenmiş üretim uygulaması örneklerinin olması gerekir.

• Bir bölgesel hata durumunda, qa uygulama örneklerini kapatın ve bunun yerine üretim örneklerini başlatın. Bu işi yapmak için uygulama örnekleri için sanal adlar kullanmanız gerekir.

• SAP Merkezi Hizmetleri ve DBMS katmanının yük devretme kümelerinin yük dengeleyiciler için Standart SKU Azure Load Balancerkullanmanız gerekir. Temel Load Balancer bölgeler arasında çalışmaz.

• SAP sistemini barındırmak için dağıttığınız Azure sanal ağı, alt ağları ile birlikte bölgeler arasında uzatılır. Her bölge için ayrı sanal ağlara gerek yoktur.

• Dağıttığınız tüm sanal makineler için Azure yönetilen disklerikullanmanız gerekir. Yönetilmeyen diskler, bölgesel dağıtımları için desteklenmez.

• Azure Premium Depolama ve Ultra SSD storage , bölgeler arasında herhangi bir tür depolama çoğaltmasını desteklemez. Uygulama (DBMS veya SAP Merkezi Hizmetler) önemli verileri çoğaltmalıdır.

• aynı, paylaşılan bir disk (Windows), cıfs paylaşım (Windows) veya NFS paylaşım (Linux) olan paylaşılan sapmnt dizini için de geçerlidir. Bu Paylaşılan diskleri veya paylaşımları bölgeler arasında çoğaltan bir teknoloji kullanmanız gerekir. Bu teknolojiler desteklenir:

  • Windows için, Azure 'da bir küme paylaşılan diski kullanarak bir Windows yük devretme kümesinde SAP ascs/SCS örneği üzerindebelgelendiği gibi, SIOS dataman kullanan bir küme çözümüdür.
  • SUSE Linux için, SUSE Linux Enterprise Server üzerinde Azure vm 'lerinde nfs için yüksek kullanılabilirlikmakalesinde belgelenen şekilde oluşturulmuş bir nfs paylaşımıdır.

  şu anda, bir Windows yük devretme kümesi ve sap ascs/SCS örnekleri için dosya paylaşma kullanarak sap yüksek kullanılabilirlik için Azure altyapısını hazırlamabölümünde belgelendiği gibi, Microsoft Scale-Out dosya sunucusu kullanan çözüm, bölgeler arasında desteklenmez.

• Üçüncü bölge, SUSE Linux Paceyapıcısı kümesi oluşturup Azure ayırma Aracısı yerine SBD cihazlarını kullanıyorsanız SBD cihazını barındırmak için kullanılır.

Sonraki adımlar

Azure Kullanılabilirlik Alanları arasında dağıtım için bazı sonraki adımlar aşağıda verilmiştir:

• Azure 'da küme paylaşılan diski kullanarak Windows yük devretme kümesinde SAP yoks/SCS örneği oluşturma
• sap ass/SCS örnekleri için Windows yük devretme kümesi ve dosya paylaşma kullanarak sap yüksek kullanılabilirlik için Azure altyapısını hazırlama