SAP iş yükü için olağanüstü durum kurtarmaya genel bakış ve altyapı yönergeleri

Makale
06/19/2023

Azure'da kritik iş uygulamaları çalıştıran birçok kuruluş hem Yüksek Kullanılabilirlik (HA) hem de Olağanüstü Durum Kurtarma (DR) stratejisini ayarlar. Yüksek kullanılabilirlik amacı, temel sistem altyapısındaki tek hata noktalarını ortadan kaldırarak iş sistemlerinin SLA'sını artırmaktır. Yüksek Kullanılabilirlik teknolojileri planlanmamış altyapı hatasının etkisini azaltır ve planlı bakım konusunda yardımcı olur. Olağanüstü Durum Kurtarma, coğrafi olarak yaygın bir doğal veya insan kaynaklı olağanüstü durum sonrasında yaşamsal teknoloji altyapısının ve sistemlerinin kurtarılmasını veya devamını sağlayan ilkeler, araçlar ve yordamlar olarak tanımlanır.

Azure'da SAP iş yükü için yüksek kullanılabilirlik elde etmek için sanal makineler genellikle bir kullanılabilirlik kümesinde, kullanılabilirlik alanlarında veya esnek ölçek kümesinde dağıtılır ve uygulamaları bölge içindeki altyapı bakımlarından veya hatalarından korur. Ancak dağıtım, uygulamaları bölge içindeki yaygın olağanüstü durumlara karşı korumaz. Bu nedenle, uygulamaları bölgesel olağanüstü durumlardan korumak için, uygulamalar için olağanüstü durum kurtarma stratejisinin yerinde olması gerekir. Olağanüstü durum kurtarma, bir kuruluşun olağanüstü durumlara yanıt olarak kurtarma işlemlerini yürütmesine yardımcı olmak ve BT hizmetlerinin kesintiye uğramasını korumak veya en aza indirmek ve kurtarmayı desteklemek için tasarlanmış, belgelenmiş ve yapılandırılmış bir yaklaşımdır.

Bu belgede yapılandırılmış DR yaklaşımını uygulayarak SAP iş yüklerini büyük ölçekli felaketlere karşı korumayla ilgili ayrıntılar sağlanır. Bu belgedeki ayrıntılar, farklı Azure hizmetlerine ve SAP bileşenlerine dayalı olarak soyut bir düzeyde sunulur. Tam DR stratejisi ve SAP iş yükünüzün kurtarma sırası düzenli olarak test edilmeli, belgelenmeli ve ince ayarlanmalıdır. Ayrıca belge, SAP iş yükü için Azure'da Azure'a DR stratejisine odaklanır.

Genel olağanüstü durum kurtarma planıyla ilgili dikkat edilmesi gerekenler

Azure'daki SAP iş yükü, tipik bir SAP NetWeaver uygulamasının farklı katmanlarını (merkezi hizmetler, uygulama sunucuları, veritabanı sunucusu) dağıtmak için farklı Azure hizmetleriyle birlikte sanal makinelerde çalışır. Genel olarak, Azure'da çalışan BT ortamının tamamı için bir DR stratejisi planlanmalıdır. Bu, SAP dışı uygulamaları da hesaba katmak anlamına gelir. BAĞıMLı hizmetler veya varlıklar DR sitesinde kurtarılmazsa SAP sistemlerinde çalışan iş çözümü tam olarak çalışmayabilir. Bu nedenle, tüm bileşenleri ve sistemleri göz önünde bulundurarak iyi tanımlanmış kapsamlı bir DR planı oluşturmanız gerekir.

Azure'da DR için kuruluşlar yük devretmeyi tetikleyebilecek farklı senaryoları dikkate almalıdır.

SAP uygulaması veya iş süreci kullanılabilirliği.
Azure hizmetlerinin (sanal makineler, depolama, yük dengeleyici vb.) yaygın hata nedeniyle bir bölgede kullanılamaması.
Uygulamaya yönelik olası tehditler ve güvenlik açıkları (örneğin, Uygulama katmanı DDoS saldırısı)
İş uyumluluğu, DR stratejisini test etmek için operasyonel görevler gerektiriyordu (örneğin, uyumluluk açısından her yıl dr hata alıştırması gerçekleştirilecek).

Farklı senaryolarda kurtarma hedefine ulaşmak için kuruluşun iş gereksinimlerine göre iş yükleri için Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO) ana hatlarını belirlemesi gerekir. RTO, genellikle saat, dakika veya saniye cinsinden ölçülen uygulamanın çalışmama süresini açıklar. RPO ise normal işlemlerin sürdürülmesi için işletme tarafından kaybedilmesi kabul edilebilir işlem verilerinin miktarını açıklar. dr stratejinizi en iyi şekilde tasarlamanıza yardımcı olacağından, işletmenizin RTO ve RPO'sunun tanımlanması çok önemlidir. SAP iş yükünde yer alan bileşenler (işlem, depolama, veritabanı vb.) farklı teknikler (Azure yerel hizmetleri, yerel VERITABANı çoğaltma teknolojisi, özel betikler) kullanılarak DR bölgesine çoğaltılır. Her teknik, dr stratejisi tasarlarken dikkate alınması gereken farklı RPO sağlar. Azure'da, SAP iş yüklerinizin RTO ve RPO'larını karşılamanıza yardımcı olabilecek Azure Site Recovery, Azure Backup gibi Azure yerel hizmetlerinden bazılarını kullanabilirsiniz. RTO ve RPO'nuzla en uygun şekilde hizalamak için Azure Site Recovery ve Azure Backup SLA'sına bakın.

Azure'da olağanüstü durum kurtarma için tasarımda dikkat edilmesi gerekenler

Azure'da olağanüstü durum kurtarma çözümü tasarlarken dikkate alınması gereken farklı öğeler vardır. Şirket içi olağanüstü durum kurtarma çözümleri tasarlamak için düşünülen ilkeler ve kavramlar Azure için de geçerlidir. Ancak Azure'da bölge seçimi, olağanüstü durum kurtarma için tasarım stratejisinin önemli bir parçasıdır. Bu nedenle Azure'da DR bölgesini seçerken aşağıdaki noktaları göz önünde bulundurun.

İş veya mevzuat uyumluluğu gereksinimleri, birincil ve olağanüstü durum kurtarma sitesi arasında bir mesafe gereksinimi belirtebilir. Mesafe gereksinimi, daha geniş bir coğrafyada bir doğal afet yaşanması durumunda kullanılabilirlik sağlamaya yardımcı olur. Böyle bir durumda, bir kuruluş olağanüstü durum kurtarma sitesi olarak başka bir Azure bölgesi seçebilir. Azure bölgeleri genellikle Birleşik Devletler gibi yüzlerce, hatta binlerce kilometre olabilecek büyük bir mesafeyle ayrılır. Uzaklık nedeniyle ağ gidiş dönüş gecikmesi daha yüksek olur ve bu da daha yüksek RPO'ya neden olabilir.
Azure'da şirket içi metro DR stratejilerini taklit etmek isteyen müşteriler olağanüstü durum kurtarma için kullanılabilirlik alanlarını kullanabilir. Ancak coğrafi olarak yaygın bir doğal afet olduğunda alanlar arası DR stratejisi dayanıklılık gereksiniminden düşebilir.
Azure'da her bölge aynı coğrafyadaki başka bir bölgeyle eşleştirilir (Güney Brezilya hariç). Bu yaklaşım, kaynakların bölge genelinde platform tarafından çoğaltılmasını sağlar. Eşleştirilmiş bölge seçmenin avantajı bölge çiftleri belgesinde bulunabilir. Bir kuruluş Azure eşleştirilmiş bölgelerini kullanmayı seçtiğinde SAP iş yükü için birkaç ek noktanın göz önünde bulundurulması gerekir:
- Tüm Azure hizmetleri eşleştirilmiş bölgede bölgeler arası çoğaltma sunmaz.
- Eşleştirilmiş Azure bölgelerindeki Azure hizmetleri ve özellikleri simetrik olmayabilir. Örneğin, Azure NetApp Files, Birincil bölgede bulunan M Serisi gibi VM SKU'ları eşleştirilmiş bölgede kullanılamayabilir. Azure ürün veya hizmetlerinin bir bölgede kullanılabilir olup olmadığını denetlemek için bkz . Bölgeye Göre Azure Ürünleri.
- GRS seçeneği, verileri eşleştirilmiş bölgeye çoğaltan standart depolama türüne sahip depolama hesabı için kullanılabilir. Ancak standart depolama, SAP DBMS veya sanal veri diskleri için uygun değildir.
- Desteklenen çözümleri yedeklemek için kullanılan Azure yedekleme hizmeti, yedeklemeleri yalnızca eşleştirilmiş bölgeler arasında çoğaltabilir. 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 robocopy ve diğer üçüncü taraf yazılımların birleşimini kullanın.

SAP iş yükü dağıtımına başvurma

Bir DR bölgesi tanımladıktan sonra, birincil bölgede yapılandırdığınız Azure çekirdek hizmetlerinin (ağ, işlem, depolama gibi) kullanılabilir olması ve DR bölgesinde yapılandırılabilmesi önemlidir. Kuruluşun SAP iş yükü için bir DR dağıtım düzeni geliştirmesi gerekir. Dağıtım düzeni değişir ve kuruluşun gereksinimlerine uygun olmalıdır.

Üretim SAP iş yükünü birincil bölgenize ve üretim dışı iş yükünü olağanüstü durum kurtarma bölgesine dağıtın.
Tüm SAP iş yükünü (üretim ve üretim dışı) birincil bölgenize dağıtın. Olağanüstü durum kurtarma bölgesi yalnızca yük devretme olduğunda kullanılır.

Aşağıdaki başvuru mimarisinde Azure üzerinde çalışan tipik SAP NetWeaver sistemi ve birincil bölgede yüksek kullanılabilirlik gösterilmektedir. Aşağıda gösterilen ikincil site, bir olağanüstü durum olayından sonra SAP sistemlerinin geri yükleneceği olağanüstü durum kurtarma sitesidir. Hem birincil hem de olağanüstü durum kurtarma bölgeleri aynı aboneliğin parçasıdır. SAP iş yükü için DR elde etmek için, uygulamanın kullandığı farklı Azure hizmetleriyle birlikte her SAP katmanı için kurtarma stratejisini tanımlamanız gerekir.

Kuruluşlar, bt alanlarının tamamı için bir DR stratejisi planlamalı ve tasarlamalıdır. Genellikle üretim ortamında çalışan SAP sistemleri Active Directory, DNS, üçüncü taraf uygulaması gibi farklı hizmetler ve arabirimlerle tümleştirilir. Bu nedenle olağanüstü durum kurtarma planlamanıza SAP olmayan sistemleri ve diğer hizmetleri de dahil etmeniz gerekir. Bu belge SAP uygulamaları için kurtarma planlamasına odaklanır. Ancak, dr planlamasının boyutunu ve kapsamını gereksinimlerinize uyacak şekilde genişletebilirsiniz.

SAP iş yükü için DR çözümünün altyapı bileşenleri

Azure'da çalışan sap iş yükü, bir iş çözümünü çalıştırmak için farklı altyapı bileşenleri kullanır. Bu tür bir çözüm için DR'yi planlamak için birincil bölgede yapılandırılan tüm altyapı bileşenlerinin kullanılabilir olması ve DR bölgesinde de yapılandırılabilmesi önemlidir. Azure'da SAP iş yükü için DR çözümü tasarlanırken aşağıdaki altyapı bileşenleri dikkate alınmalıdır.

Ağ
İşlem
Depolama

Ağ

ExpressRoute , bir bağlantı sağlayıcısının yardımıyla özel bir bağlantı üzerinden şirket içi ağınızı Microsoft bulutuna genişletir. Olağanüstü durum kurtarma mimarisi tasarlarken, coğrafi olarak yedekli ExpressRoute bağlantı hattı kullanarak sağlam bir arka uç ağ bağlantısı oluşturmak gerekir. Şirket içinden birincil bölgeye en az bir ExpressRoute bağlantı hattı ayarlamanız tavsiye edilir. Ve diğerlerinin olağanüstü durum kurtarma bölgesine bağlanması gerekir. ExpressRoute için olağanüstü durum kurtarma tasarlamaya yönelik farklı senaryoları açıklayan Olağanüstü durum kurtarma için Azure ExpressRoute'u Tasarlama makalesine bakın.

Dekont

Azure ExpressRoute'un yedeği olarak siteden siteye (S2S) VPN ayarlamayı göz önünde bulundurun. Daha fazla bilgi için bkz . Azure ExpressRoute Özel Eşlemesi için yedek olarak S2S VPN kullanma.
Sanal ağ ve alt ağlar bir bölgedeki tüm kullanılabilirlik alanlarına yayılmıştır. İki bölgede DR için olağanüstü durum kurtarma bölgesinde ayrı sanal ağlar ve alt ağlar yapılandırmanız gerekir. DR bölgesindeki ağ kurulumu hakkında daha fazla bilgi edinmek için Azure VM olağanüstü durum kurtarmada ağ hakkında bölümüne bakın.
Azure Standart Load Balancer, SAP sistemlerinizin yüksek kullanılabilirlik tasarımı için ağ öğeleri sağlar. Kümelenmiş sistemler için Standart Load Balancer, ASCS/SCS örnekleri ve VM'lerde çalışan veritabanları gibi küme hizmeti için sanal IP adresini sağlar. DR sitesinde yüksek oranda kullanılabilir SAP sistemini çalıştırmak için ayrı bir yük dengeleyici oluşturulmalıdır ve küme yapılandırması buna göre ayarlanmalıdır.
Azure Uygulaması lication Gateway bir web trafiği yük dengeleyicidir. Web Uygulaması Güvenlik Duvarı işlevselliğiyle, iyileştirilmiş güvenlikle web uygulamalarını İnternet'e kullanıma sunmanın en uygun hizmetidir. Azure Uygulaması lication Gateway, yapılandırmaya bağlı olarak genel (internet) veya özel istemcilere ya da her ikisine de hizmet verebilir. Yük devretmeden sonra DR bölgesinde benzer gelen HTTP'ler trafiğini kabul etmek için DR bölgesinde ayrı bir Azure Uygulaması lication Gateway yapılandırılmalıdır.
Ağ bileşenleri (sanal ağ, güvenlik duvarı vb.) DR bölgesinde ayrı olarak oluşturulduğundan, DR bölgesindeki SAP iş yükünün DNS güncelleştirmesi, güvenlik duvarı vb. ağ değişikliklerine uyarlandığından emin olmanız gerekir.
Her iki bölgede de sanal ağlar bağımsızdır ve ikisi arasında iletişim kurmak için iki bölge arasında sanal ağ eşlemesini etkinleştirmeniz gerekir.

Sanal makineler

Azure'da, tek bir SAP sisteminin farklı bileşenleri farklı SKU türlerine sahip sanal makinelerde çalışır. DR için, Azure VM'lerinde çalışan bir uygulamanın (SAP NetWeaver ve SAP olmayan) korunması, Azure Site Recovery kullanarak bileşenleri başka bir Azure bölgesine veya bölgesine çoğaltarak etkinleştirilebilir. Azure Site Recovery ile Azure VM'leri birincilden olağanüstü durum kurtarma sitesine sürekli olarak çoğaltılır. Seçilen Azure DR bölgesine bağlı olarak, VM SKU türü DR sitesinde kullanılamayabilir. Gerekli VM SKU türlerinin Azure DRregion'da da kullanılabilir olduğundan emin olmanız gerekir. Gerekli VM ailesi SKU türünün kullanılabilir olup olmadığını görmek için Bölgeye Göre Azure Ürünleri'ne bakın.

Önemli

SAP sistemi FD=1 ile esnek ölçek kümesiyle yapılandırılmışsa, olağanüstü durum kurtarma için Azure Site Recovery'yi ayarlamak için PowerShell kullanmanız gerekir. Şu anda, ölçek kümesinde dağıtılan VM'ler için olağanüstü durum kurtarmayı yapılandırmak için kullanılabilen tek yöntemdir.
Azure sanal makinelerinde çalışan veritabanları için, verileri olağanüstü durum kurtarma sitesine eşitlemek için yerel veritabanı çoğaltma teknolojisinin kullanılması önerilir. Veritabanlarının üzerinde çalıştığı büyük VM'ler tüm bölgelerde kullanılamayabilir. Olağanüstü durum kurtarma için kullanılabilirlik alanları kullanıyorsanız, ilgili VM SKU'larının olağanüstü durum kurtarma sitenizin bölgesinde kullanılabilir olup olmadığını denetlemeniz gerekir.

Dekont

Veritabanı tutarlılığını garanti etmediğinden ve veri değişim sıklığı sınırlaması olduğundan veritabanları için Azure Site Recovery kullanılması önerilmiyor.
Üretim uygulamaları her zaman birincil bölgede çalışırken, yedek örnekler genellikle Azure maliyetlerini ekonomik hale getirmek için kullanılır. Ayrılmış örnekleri kullanıyorsanız, DR sitesi için uygun maliyetli olmayabilecek 1 yıllık veya 3 yıllık bir dönem taahhüdüne kaydolmanız gerekir. Ayrıca Azure Site Recovery'nin ayarlanması, yük devretme sırasında gerekli VM SKU'sunun kapasitesini garanti etmez. VM SKU kapasitesinin kullanılabilir olduğundan emin olmak için isteğe bağlı kapasite rezervasyonunu etkinleştirme seçeneğini göz önünde bulundurabilirsiniz. Bir Azure bölgesinde veya Azure kullanılabilirlik alanında işlem kapasitesini herhangi bir süre için taahhütte bulunmadan ayırır. Azure Site Recovery, isteğe bağlı kapasite rezervasyonuyla tümleşiktir. Bu tümleştirmeyle, DR sitesinde işlem kapasitesini ayırmak ve yük devretmelerinizi garanti etmek için Azure Site Recovery ile kapasite ayırmanın gücünü kullanabilirsiniz. Daha fazla bilgi için isteğe bağlı kapasite rezervasyon sınırlamaları ve kısıtlamaları'nı okuyun.
Azure aboneliğinde VM aileleri (örneğin, Mv2 ailesi) ve diğer kaynaklar için kotalar vardır. Bazen kuruluşlar DR için farklı Azure aboneliği kullanmak ister. Her aboneliğin (birincil ve DR) her VM ailesi için farklı kotaları atanmış olabilir. DR sitesi için kullanılan aboneliğin yeterli işlem kotası olduğundan emin olun.

Depolama

DR ayarlamak üzere bir VM için Azure Site Recovery etkinleştirildiğinde, VM'lere bağlı işletim sistemi ve yerel veri diskleri DR sitesine çoğaltılır. Çoğaltma sırasında VM disk yazma işlemleri kaynak bölgedeki bir önbellek depolama hesabına gönderilir. Veriler oradan hedef bölgeye gönderilir ve kurtarma noktaları verilerden oluşturulur. DR sırasında bir VM'ye yük devreddiğinizde, hedef bölgedeki VM'yi geri yüklemek için bir kurtarma noktası kullanılır. Ancak Azure Site Recovery, Azure'da kullanılabilen tüm depolama türlerini desteklemez. Daha fazla bilgi için bkz . Depolama alanları için Azure Site Recovery destek matrisi.

VM'lere eklenen Azure yönetilen veri disklerine ek olarak, SAP uygulamasını Azure'da çalıştırmak için farklı Azure yerel depolama çözümleri kullanılır. Azure'da kullanılabilen tüm depolama hizmetleri Azure Site Recovery ile desteklenmediğinden, her Azure depolama çözümü için DR yaklaşımı farklı olabilir. Sap iş yükü için genellikle kullanılan depolama türünün listesi aşağıdadır.

Depolama türü	DR stratejisi önerisi
Yönetilen disk	Azure Site Recovery
Azure dosyalarında NFS (LRS veya ZRS)	İki site arasında verileri çoğaltmak için özel betik (örneğin, rsync)
Azure NetApp Files'da NFS	Azure NetApp Files birimlerinin bölgeler arası çoğaltmalarını kullanma
Azure paylaşılan diski (LRS veya ZRS)	verileri iki site arasında çoğaltmak için özel çözüm
Azure dosyalarında SMB (LRS veya ZRS)	İki site arasında dosya kopyalamak için RoboCopy kullanma
Azure NetApp Files'da SMB	Azure NetApp Files birimlerinin bölgeler arası çoğaltmalarını kullanma

NFS kümesi gibi özel yerleşik depolama çözümleri için uygun DR stratejisinin geçerli olduğundan emin olmanız gerekir.
Farklı yerel Azure depolama hizmetleri (Azure Dosyalar, Azure NetApp Files, Azure Paylaşılan Disk gibi) tüm bölgelerde kullanılamayabilir. Yük devretmeden sonra DR bölgesinde benzer SAP kurulumuna sahip olmak için ilgili depolama hizmetinin DR sitesinde sunulduğundan emin olun. Daha fazla bilgi için Bölgeye Göre Azure Ürünleri'ne bakın.
Olağanüstü durum kurtarma için kullanılabilirlik alanlarını kullanıyorsanız aşağıdaki noktaları göz önünde bulundurun:
- Azure NetApp Files özelliği henüz bölge tanımaz. Şu anda Azure NetApp Files özelliği bir Azure bölgesindeki tüm Kullanılabilirlik alanlarına dağıtılmamaktadır. Bu nedenle, Dr stratejiniz için seçilen kullanılabilirlik alanında Azure NetApp Files hizmeti kullanılamayabilir.
- Azure NetApp Dosya birimlerinin bölgeler arası çoğaltması bölgeler arasında değil yalnızca sabit bölge çiftlerinde kullanılabilir.
Depolama alanınızı Active Directory tümleştirmesi ile yapılandırdıysanız, DR site depolama hesabında da benzer bir kurulum yapılmalıdır.
Azure paylaşılan diskleri, küme düğümü iletişim ve yazma kilitlemeyi işleyen Windows Server Yük Devretme Kümesi (WSFC) gibi bir küme yazılımı gerektirir. Bu nedenle, Azure paylaşılan diski için DR stratejisine sahip olmak için, DR sitesinde küme yazılımı tarafından yönetilen paylaşılan diske de sahip olmanız gerekir. Ardından betiği kullanarak birincil bölgedeki bir kümeye bağlı paylaşılan diskten DR bölgesindeki başka bir kümeye bağlı olan paylaşılan diske veri kopyalayabilirsiniz.