SAP Geçişi için iş Sürekliliği ve Olağanüstü Durum Kurtarma (Microsoft Azure)

                                     SAP Geçişi için iş Sürekliliği ve Olağanüstü Durum Kurtarma
Bu makalede BCDR için Azure giriş bölgesi tasarım alanında tanımlanan bazı önemli noktalar ve öneriler ele alınmaktadır. Bu makale, SAP platformunu destekleyen tüm giriş bölgelerindeki benzersiz kısıtlamaları anlamanıza yardımcı olur. Ancak SAP görev açısından kritik bir platform olduğundan, Azure giriş bölgesi tasarım alanlarıyla ilgili yönergelere başvurmanız ve bunları tasarımınıza eklemeniz gerekir.
Senaryo ve Kapsam
Kuruluşunuzun veya kuruluşunuzun, uygulama iş yüklerinin kendi gereksinimlerini karşılamasına yardımcı olacak platform düzeyinde özellikler tasarlaması gerekir. Kuruluşun en kritik iş süreçlerini çalıştıran SAP uygulamaları şunları gerektirir:
• Hizmet/iş süreci kullanılabilirliği.
• Hata veya olağanüstü durum senaryoları sırasında kurtarma süresi hedefleri (GPO’lar). Örneğin, SAP sisteminin bir bileşeniyle sınırlı bir hata senaryosu veya bir veri merkezini veya Azure bölgesini etkileyen yaygın bir hata görebilirsiniz.
• SAP sisteminin bir bileşeniyle sınırlı bir hata senaryosu veya veri merkezini ya da Azure bölgesini etkileyen yaygın bir hata için kurtarma noktası hedefleri (RPO’lar).
• İşletimsel ve yaşam döngüsü yönetim görevleri ve hata senaryoları için doldurulan teknoloji. Bu yönetim görevleri konuk işletim sistemlerine ve veritabanı yönetim sistemlerine düzeltme eki uygulama, SAP sistemlerini kopyalama ve yenilemeyi içerir.
Mimariniz, şirket içi iş sürekliliği ve olağanüstü durum kurtarma (BCDR) senaryolarını ele almak için birçok ilkeyi ve görevi dikkate almalıdır. Bu ilkeler ve görevler Azure’da da geçerlidir. Temel fark, Azure’ın bir konak hatasını telafi etmek için kuruluşunuzdan daha fazla donanım kapasitesine sahip olmasıdır. En büyük Azure VM’lerini başka bir sunucuda yeniden başlatacak şekilde ayarlayarak bile hizmet iyileştirmesi yapabilirsiniz. Azure dağıtımlarınızı şirket içi dağıtımlarınızla aynı koşulları kullanacak şekilde ayarlayın. Şirket içi sistemleri veya çıplak donanımları otomatik yük devretme kümesi yapılandırmalarını kullanarak dağıttıysanız, bunları Azure’da da aynı şekilde dağıtın.
Bu makale, kurumsal ölçekli bir SAP senaryosu için BCDR’nin aşağıdaki yönlerini kapsar:
• Azure bölgesinde yüksek kullanılabilirlik.
• Yedekleme ve geri yükleme konusunda dikkat edilmesi gerekenler.
• Bölgeler arası ve bölgesel olağanüstü durum kurtarma karar ölçütleri.
Azure bölgesinde yüksek kullanılabilirlik
SAP kurumsal senaryosu için azure bölgesinde yüksek kullanılabilirlik için tasarımla ilgili önemli noktaları ve önerileri gözden geçirin.
Yüksek kullanılabilirlik için tasarım konuları
Yüksek kullanılabilirlik ile, SAP yazılımının tek hata noktası için kullanılabilirlik sağlamaktır, örneğin:
• Veritabanı yönetim sistemleri.
• Uygulamada ABAP SAP ASCS/SCS gibi tek hata noktaları. Örnek olarak SAP NetWeaver ve SAP S/4HANA mimarisi verilebilir.
• SAP Web Dispatcher gibi diğer araçlar.
Diğer senaryolarda, kullanılabilirliği altyapı veya yazılım hatalarıyla kısıtlamayın. VM’lerdeki, DBMS’deki veya SAP yazılımındaki işletim sistemine düzeltme eki uygulama gibi tüm gerekli yaşam döngüsü yönetim görevlerine kullanılabilirlik uygulayın. Planlı kapalı kalma süresi ve yaşam döngüsü yönetimi görevleri sırasında meydana gelebilecek kesintileri en aza indirmek için planlanmamış hizmet kesintilerine karşı koruma sağlayan yaygın araçları kullanın.
SAP ve SAP veritabanları otomatik yük devretme kümelerini destekler. Windows’da, Windows Server Yük Devretme Kümelemesi özelliği yük devretmeyi destekler. Linux’ta Linux Pacemaker veya SIOS Protection Suite veya Veritas InfoScale gibi üçüncü taraf araçlar yük devretmeyi destekler. Azure ile yalnızca kendi veri merkezinizde bir alt küme yüksek kullanılabilirlik yapılandırması dağıtabilirsiniz.
Azure’ın SAP’yi nasıl desteklediği hakkında daha fazla bilgi edinmek için Bkz. Azure VM’lerinde SAP iş yükü için desteklenen senaryolar ve SAP HANA için desteklenen senaryolar Sap için Azure’ın desteklediği özellikler hakkında daha fazla bilgi edinmek için büyük örnekler.
DBMS katmanı için ortak mimari deseni, veritabanlarını aynı anda ve birincil ve ikincil VM’lerin kullandığından farklı depolama yığınlarıyla çoğaltmaktır. Azure, birincil ve ikincil VM’nin DBMS verileri için depolama alanını paylaştığı mimarileri desteklemez. İşlem ve yineleme günlüklerini de Azure desteği. Yol gösteren ilke, Ağ Dosya Sistemi (NFS) paylaşımlarını temel alsalar bile iki bağımsız depolama yığını kullanmaktır. Ancak bu yaklaşım, şirket içi ile mümkün olanlarla karşılaştırıldığında temel sınırlamadır.
Azure, NFS veya Sunucu İleti Bloğu paylaşımını desteklediği için başka seçenekler de sağlar. ASCS/SCS bileşenleri ve belirli yüksek kullanılabilirlik senaryoları için Windows’ta Azure paylaşılan diski kullanabilirsiniz. YÜK devretme kümelerinizi SAP uygulama katmanı bileşenleri ve DBMS katmanı için ayrı olarak ayarlayın. Azure, SAP uygulama katmanı bileşenlerini ve DBMS katmanını tek bir yük devretme kümesinde birleştiren yüksek kullanılabilirlik mimarilerini desteklemez.
SAP uygulama katmanı bileşenleri ve DBMS katmanı için çoğu yük devretme kümesi için sanal IP adresi gerekir. Yaygın bir özel durum Oracle Data Guard’dır. Sanal IP adresi gerektirmez. Azure Load Balancer diğer tüm durumlar için sanal IP adresini işlemelidir. Tasarım ilkesi olarak, küme yapılandırması başına bir Load Balancer kullanın. Yük dengeleyicinin standart sürümünü kullanmanızı öneririz. Daha fazla bilgi için bkz. SAP yüksek kullanılabilirlik senaryolarında Azure Standart Load Balancer kullanan sanal makineler için genel uç nokta bağlantısı.
Daha fazla bilgi ve seçenek için SAP NetWeaver için yüksek kullanılabilirlik mimarisini ve senaryolarını keşfedin.
Azure kullanılabilirlik kümeleri ile kullanılabilirlik alanları karşılaştırması
Yüksek kullanılabilirlik altyapınızı dağıtmadan önce ve seçtiğiniz bölgeye bağlı olarak Azure kullanılabilirlik kümesi veya kullanılabilirlik alanı üzerinden dağıtım yapmayı seçin. Kullanılabilirlik kümesiyle dağıtılan VM’ler için temel farklar şunlardır:
• VM’ler farklı kullanılabilirlik alanlarına yayılmaz.
• Konak kümede dağıtılan ilk VM tarafından tanımlandığından, tek bir kullanılabilirlik kümesi aracılığıyla dağıtabileceğiniz VM’lerin türü kısıtlanır. Örnek bir sonuç, M serisi ve E serisi VM’leri tek bir kullanılabilirlik kümesinde birleştiremeyeceğinizdir.
Yüksek kullanılabilirlik mimarinizi farklı kullanılabilirlik alanlarına dağıtmanın avantajlarından biri, VM’ler için hizmet düzeyi sözleşmenizin (SLA) daha yüksek olmasıdır. Ayrıntılar için Bkz. Azure VM SLA’ları. Azure bölgesine bağlı olarak, VM’ler arasındaki ağ trafiğinde farklı ağ gecikmesi koşulları bulabilirsiniz. Farklı kullanılabilirlik alanları arasında SAP iş yükü dağıtımları hakkında daha fazla bilgi için Azure kullanılabilirlik alanlarıyla SAP iş yükü yapılandırmalarını okuyun.
Yüksek kullanılabilirlik için tasarım önerileri
• Azure, uygulama altyapı SLA’larınızı karşılamanıza yardımcı olacak çeşitli seçenekler sunar. Üç SAP bileşeni için de aynı seçeneği belirlemeniz gerekir: merkezi hizmetler, uygulama sunucusu ve veritabanı.
o Tek bir VM SLA’sı yüzde 99,9 sunar.
o Kullanılabilirlik kümesi dağıtımı yüzde 99,95 sunar.
o Kullanılabilirlik alanları yüzde 99,99 sunar.
• Kullanılabilirlik kümesi dağıtımında, sap sisteminin her bileşeninin kendi kullanılabilirlik kümesinde olması gerekir. SAP merkezi hizmetleri, veritabanı ve uygulama VM’leri kullanılabilirlik kümelerinde gruplandırılmalıdır.
• Kullanılabilirlik kümesi dağıtımında Azure yakınlık yerleştirme gruplarını kullanırken, üç SAP bileşeninin de (merkezi hizmetler, uygulama sunucusu ve veritabanı) aynı yakınlık yerleştirme grubunda olması gerekir.
• SAP SID başına bir yakınlık yerleştirme grubu kullanın. Gruplar kullanılabilirlik alanlarına veya Azure bölgelerine yayılmaz.
• Kullanılabilirlik alanları dağıtımında Azure yakınlık yerleştirme gruplarını kullanırken, iki SAP bileşeni (merkezi hizmetler ve uygulama sunucusu) aynı yakınlık yerleştirme grubunda olmalıdır. İki bölgede yer alan veritabanı VM’leri artık yakınlık yerleştirme gruplarının bir parçası değildir. Bölge başına yakınlık yerleştirme gruplarının kapsamı artık SAP ASCS/SCS örneklerini çalıştıran VM’nin dağıtımıyla belirlenmiştir. Bu yeni yapılandırmanın avantajı, VM’leri yeniden boyutlandırma konusunda daha fazla esnekliğe sahip olmanızdır. DBMS katmanı veya SAP sisteminin uygulama katmanı ile yeni VM türlerine geçmek de daha kolaydır.
• Azure şu anda aynı Linux Pacemaker kümesinde ASCS ve veritabanı yüksek kullanılabilirliğini birleştirmeyi desteklemez; bunları tek tek kümelere ayırın. Ancak beş adede kadar merkezi hizmet kümesini bir çift VM’de birleştirebilirsiniz.
• ASCS ve veritabanı kümelerinin önünde bir Standart Load Balancer SKU kullanın.
• Tüm üretim sistemleri premium yönetilen SSD’lerde çalışmalı ve Azure NetApp Files veya Ultra Disk Depolama kullanmalıdır. En azından daha iyi performans ve en iyi SLA elde etmek için işletim sistemi diski Premium katman olmalıdır.
• Yüksek kullanılabilirlik çiftindeki her iki VM de bir kullanılabilirlik kümesinde dağıtılmalıdır veya kullanılabilirlik alanları aynı boyutta olmalı ve aynı depolama yapılandırmasına sahip olmalıdır.
• Veritabanını yüksek kullanılabilirlik çiftinde eşitlemek için yerel veritabanı çoğaltma teknolojisi kullanılmalıdır.
• Sap central-services kümelerini farklı işletim sistemlerinde çalıştırmak için aşağıdaki hizmetlerden biri seçilmelidir:
o SUSE Linux Enterprise Server Pacemaker kümesi: En fazla üç STONITH blok cihazını (SBD) veya Azure Fence Agent’ı destekler.
o Red Hat Enterprise Linux Pacemaker kümesi: SBD henüz desteklenmiyor; yalnızca Azure Fence Aracısı desteklenir.
o Windows kümesi
o SAP sertifikalı üçüncü taraf küme yazılımı.
• Merkezi hizmetler ve veritabanı kümeleri belgelerinde önerilen küme zaman aşımı parametrelerini ayarlamanız gerekir.
SAP İş Yükleri için Depolama
Depolama için Tasarım Konuları:
• SAP iş yükünüz için dayanıklılık tasarımı, kullanılabilir doğru depolama seçeneklerinin seçilmesini içerir. Azure depolamadaki SAP İş Yükleri için tasarım, gecikme süresini en düşük düzeyde tutmak ve aktarım hızını en üst düzeye çıkarmak için tasarlanmıştır. Belirli uygulamanızı ve aşağıdaki kılavuzun AZURE uygulamasında SAP’niz için mimari kararlar almanıza nasıl yardımcı olabileceğini göz önünde bulundurmanız gerekir. Sap iş yükleri ve SAP bileşenleriyle farklı depolama türlerini ve bunların yeteneklerini ve kullanılabilirliğini anlamak için lütfen SAP İş Yükü için Azure Depolama Türleri’ni okuyun.
• Azure’da SAP HANA yalnızca SAP tarafından onaylanan depolama türlerinde çalıştırılmalıdır. Yazma Hızlandırıcısı’nı etkinleştirme ve uygun olduğunda Premium depolamayı seçme dahil olmak üzere belirli birimlerin belirli disk yapılandırmalarında çalıştırılması gerektiğini lütfen unutmayın. Dikkat edilmesi gereken bir diğer nokta, seçilen depolamada çalıştırılacak dosya sisteminin makinede çalışacak DBMS ile uyumlu olması gerektiğidir. SAP HANA için farklı depolama yapılandırma türlerini anlamak için daha fazla bilgi için sap HANA için Depolama Yapılandırmaları makalesini okuyun.
• Azure’da SAP İş Yüklerini çalıştırırken NFS paylaşımları için bir seçenek Azure NetApp Files kullanmaktır. ANF’nin kendi aktarım hızı ve boyutlandırma konuları vardır. SAP sanal makinesi için Azure NetApp Files ile ilgili bilgilere bakın.
Yedekleme/Geri yükleme
Yedekleme ve Geri yükleme için tasarım önerileri
• SAP uygulama sunucusunu ve merkezi hizmetler VM’lerini yedeklemek için Azure Backup kullanabilirsiniz.
• 8 TB’a kadar HANA dağıtımları için SAP HANA yedeklemesi kullanabilirsiniz. Daha fazla bilgi için Azure VM’lerinde SAP HANA veritabanlarını yedeklemeye yönelik destek matrisini inceleyin.
• RTO’nuza uygun olup olmadığını doğrulamak için yedekleme ve kurtarma sürelerini test edin.
• İdeal olarak, özellikle büyük veritabanlarında yedeklemelerinizi Azure’dan şirket içi yedekleme altyapınıza çekmekten kaçının. Bu seçenek, ExpressRoute bağlantı hatlarının ne kadar bant genişliği tükettiğine bağlıdır.
Yedekleme ve Geri yükleme
SAP kurumsal senaryosunda yedekleme ve geri yükleme için tasarımla ilgili önemli noktaları ve önerileri gözden geçirin.
Yedekleme ve Geri yükleme için tasarım konuları
Yedekleme ve geri yükleme genellikle üretim SAP iş yükü için yeterli yüksek kullanılabilirlik işlevselliği olarak kabul edilmese de, bu teknoloji diğer çeşitli alanları kapsar. SAP uygulamalarını kullanan çoğu şirketin, yedeklemelerin uzun yıllar boyunca depolanmasını gerektiren uyumluluk düzenlemelerine uyması gerekir. Ayrıca bir yedeğin olması ve ondan geri yüklenebilmesinin gerekli olduğu başka koşullar ve senaryolar da vardır. Sap uygulamalarını dağıtmak için en iyi yedekleme ve geri yükleme yöntemlerini zaten oluşturup izlediğiniz varsayımı şudur:
• Üretim veritabanlarınız için herhangi bir noktada ve RTO’nuzu karşılayan bir zaman diliminde belirli bir noktada kurtarma gerçekleştirin. Belirli bir noktaya kurtarma genellikle DBMS katmanında veya SAP aracılığıyla verileri silme gibi işleç hatalarını içerir.
• Uyumluluk düzenlemelerini karşılamak için uzun vadeli yedeklemelerinizi tutmak için bir mağaza tutun.
• SAP sistemini kopyalamak ve yedekleri başka bir sunucuya veya VM’ye geri yüklemek için veritabanı yedeklemelerini kullanın.
• Üretim dışı sistemleri yenilemek için veritabanı yedeklerindeki üretim veritabanı verilerini kullanın.
• SAP uygulama sunucularını ve VM’leri, diskleri veya VM anlık görüntülerini yedekleyin.
Şirket içi ortamı yedekleyip geri yüklerken bu özellikleri Azure’daki SAP sistemlerine getirmeniz gerekir.
Geçerli çözümünüzden memnunsanız, yedekleme satıcınızın Azure dağıtımlarını desteklediğini veya Azure’da hizmet olarak yazılım (SaaS) çözümü ayarlayıp ayarlamadıklarını denetleyin.
Azure, VM anlık görüntülerini alan ve akış SQL Server ile SAP HANA yedeklemelerini yöneten bir yedekleme SaaS hizmeti Azure Backup sunar. SAP HANA veritabanlarınızı depolamak için Azure NetApp Files kullanıyorsanız, HANA ile tutarlı depolama anlık görüntülerini temel alarak yedeklemeler çalıştırabilirsiniz.
Yedekleme ve Geri yükleme için tasarım önerileri
• SAP uygulama sunucusunu ve merkezi hizmetler VM’lerini yedeklemek için Azure Backup kullanabilirsiniz.
• 8 TB’a kadar HANA dağıtımları için SAP HANA yedeklemesi kullanabilirsiniz. Daha fazla bilgi için Azure VM’lerinde SAP HANA veritabanlarını yedeklemeye yönelik destek matrisini inceleyin.
• RTO’nuza uygun olup olmadığını doğrulamak için yedekleme ve kurtarma sürelerini test edin.
• İdeal olarak, özellikle büyük veritabanlarında yedeklemelerinizi Azure’dan şirket içi yedekleme altyapınıza çekmekten kaçının. Bu seçenek, ExpressRoute bağlantı hatlarının ne kadar bant genişliği tükettiğine bağlıdır.
Olağanüstü durum kurtarma
SAP kurumsal senaryosunda olağanüstü durum kurtarma için tasarımla ilgili önemli noktaları ve önerileri gözden geçirin.
Olağanüstü durum kurtarma için tasarımda dikkat edilmesi gerekenler
Azure bölge haritası 60’ın üzerinde Azure bölgesini gösterir ve hepsi aynı hizmetleri çalıştırmaz. Daha büyük SAP yazılım dağıtımlarında ve özellikle SAP HANA kullananlarda, Azure M serisi ve/veya Mv2 serisi VM’ler sunan Azure bölgelerini arayın. Azure Depolama ayrıca farklı bölgeleri eşleştirerek depolama türlerinin daha küçük bir alt kümesini başka bir bölgeye çoğaltır. Daha fazla bilgi için bkz. Eşleştirilmiş Azure bölgelerine genel bakış.
SAP iş yükleri için Azure bölgelerini eşleştirmenin başlıca zorlukları şunlardır:
• Çiftler her zaman M serisi veya Mv2 serisi VM hizmetleriyle tutarlı değildir. SAP sistemlerini dağıtan birçok müşteri Eşleştirilmiş Azure bölgelerini takip etmez. Bunun yerine, gerekli VM ailelerinin hizmet kullanılabilirliğini izler.
• Standart depolamayı eşleştirilmiş bölgeler arasında çoğaltabilirsiniz, ancak veritabanlarınızı veya sanal sabit disklerinizi depolamak için standart depolama kullanamazsınız. Yedeklemeleri yalnızca kullandığınız eşleştirilmiş bölgeler arasında çoğaltabilirsiniz. Diğer tüm verileriniz için SQL Server Always On, SAP HANA Sistem Çoğaltma ve diğer hizmetler gibi yerel DBMS özellikleriyle kendi çoğaltmalarınızı çalıştırın. SAP uygulama katmanı için Azure Site Recovery rsync veya robocopyve diğer üçüncü taraf yazılımlarının birleşimini kullanın.
Azure bölgelerinizi tanımladıktan sonra kuruluşunuzun şu dağıtım desenlerinden birini seçmesi gerekir:
• Üretim sistemlerini birincil bölgenize dağıtıp dağıtmayacağınız.
• Üretim dışı SAP sistemlerini olağanüstü durum kurtarma bölgesine dağıtın.
• Ya da tüm SAP sistemlerini birincil bölgede gruplandıran bir mimari kullanacaksanız. Bu yapılandırma, olağanüstü durum kurtarma bölgesinin yalnızca olağanüstü durum kurtarma bölgeleri için kullanılmasını sağlar.
Geçerli SAP müşteri dağıtım düzeni, müşterilerin çoğunun çalışan SAP sistemleri için her iki bölgeyi de kullandığını gösterir. üretim sistemlerinin tam kopyalarını iş regresyon test sistemleri olarak çalıştıran müşteriler genellikle SAP ürün hattının iş regresyon test sistemini olağanüstü durum kurtarma hedefi olarak kullanmayı planlar.
En az iki Azure bölgesinden hangisinin olağanüstü durum kurtarma bölgesi olması gerektiğini belirlemek için bir diğer önemli tasarım faktörü de Azure’a bağlanan birden çok Azure ExpressRoute bağlantı hattınız olmasıdır. En az bir ExpressRoute bağlantı hattının birincil Azure bölgesine bağlanması gerekir. Diğerlerinin de olağanüstü durum kurtarma bölgesine bağlanması gerekir. Bu mimari türü sizi farklı bir coğrafi bölgedeki Azure ağına bağlar ve bir felaket başka bir Azure bölgesini etkilerse bağlantınızı korur.
Bazı müşteriler, aynı Azure bölgesinde olağanüstü durum kurtarma ile yüksek kullanılabilirliği gruplandıran yüksek kullanılabilirlik ve olağanüstü durum kurtarma mimarisini birlikte kullanır. Ancak olağanüstü durum kurtarma ile yüksek kullanılabilirliği gruplandırma ideal değildir. Azure kullanılabilirlik alanları bu mimariyi destekler. Bir Azure bölgesi içindeki kullanılabilirlik alanları arasındaki uzaklık iki farklı Azure bölgesi arasındaki mesafe kadar büyük olmadığından, doğal bir afet oluştuğu bölgedeki mimariyi tehlikeye atabilir. Müşteriler şu nedenlerden dolayı bu mimariyi seçer:
• Üretim dağıtımı ile olağanüstü durum kurtarma hedefi arasındaki daha küçük mesafeleri destekleyen yapılandırmalarla yeterli uyumluluk.
• Veri hakimiyeti özellikleri.
• Jeopolitik faktörler.
Olağanüstü durum kurtarma bölgenizi seçerken dikkate alınması gereken bir diğer faktör de olağanüstü durum kurtarma sitesine yük devretme için RPO ve RTO’dur. Üretim ve olağanüstü durum kurtarma bölgeleri arasındaki mesafe ne kadar büyükse ağ gecikme süresi de o kadar büyük olur. Farklı Azure bölgeleri arasında zaman uyumsuz olarak çoğaltmanız mümkün olsa da, daha küçük veya daha büyük bir ağ gecikmesi, çoğaltabildiğiniz aktarım hızını ve RPO hedefini etkileyebilir. Genellikle yüksek kullanılabilirlik ve olağanüstü durum kurtarma mimarisini kullanarak kurtarma noktası hedeflerinizi (RPO) en aza indirebilirsiniz. Ancak bu yapılandırma, büyük ölçekli ve doğal afetlerden daha yüksek bir risk oluşturur.
Olağanüstü durum kurtarma için tasarım önerileri
• Birincil sanal ağ için sınıfsız etki alanları arası yönlendirme (CIDR), olağanüstü durum kurtarma sitesinin sanal CIDR’siyle çakışmamalı veya çakışmamalıdır.
• Şirket içinden birincil ve ikincil Azure olağanüstü durum kurtarma bölgesine ExpressRoute bağlantıları ayarlayın.
• ExpressRoute’u kullanmanın bir alternatifi, şirket içinden birincil ve ikincil Azure olağanüstü durum kurtarma bölgesine VPN bağlantıları ayarlamaktır.
• Bir uygulama sunucusunu olağanüstü durum kurtarma sitesine çoğaltmak için Site Recovery kullanın. Site Recovery ayrıca merkezi hizmetler kümesi VM’lerini olağanüstü durum kurtarma sitesine çoğaltmaya da yardımcı olur. Olağanüstü durum kurtarmayı çağırdığınızda, olağanüstü durum kurtarma sitesinde Linux Pacemaker kümesini yeniden yapılandırmanız gerekir. Örneğin, VIP veya SBD’yi değiştirirsiniz.
• Birincil bölge ile olağanüstü durum kurtarma bölgesi arasında dosya birimlerini eşitlemek için Azure NetApp Files bölgeler arası çoğaltmayı kullanın (şu anda genel önizlemede).
• Verileri Azure Site Recovery yerine olağanüstü durum kurtarma sitesine eşitlemek için yerel veritabanı çoğaltmasını kullanın.
• Birincil ve olağanüstü durum kurtarma sanal ağlarını eşler. Örneğin, HANA Sistem Çoğaltması için bir SAP HANA DB sanal ağının olağanüstü durum kurtarma sitesinin SAP HANA DB sanal ağıyla eşlenmesi gerekir.
• SAP dağıtımlarınız için Azure NetApp Files depolama kullanıyorsanız, en azından Premium katmanında iki farklı bölgede iki Azure NetApp Files hesabı oluşturun.