SAP iş yükü için olağanüstü durum kurtarmaya genel bakış ve altyapı yönergeleri
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ın yük devretmeyi tetikleyebilecek farklı senaryoları dikkate alması gerekir.
- 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 olabilir 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çerse 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ırılan 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ının ayarlanması ve diğerinin olağanüstü durum kurtarma bölgesine bağlanması tavsiye edilir. 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.
Not
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 HTTPs trafiğini kabul etmek için DR bölgesinde ayrı bir Azure Uygulaması lication Ağ Geçidi 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.
Not
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
BIR VM'nin DR'yi ayarlaması için Azure Site Recovery etkinleştirildiğinde, VM'lere bağlı yerel yönetilen diskler DR bölgesine ç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.
Azure paylaşılan diski ile Windows üzerinde çalışan SAP sistemi için Azure Paylaşılan Disk ile Azure Site Recovery (önizleme) kullanabilirsiniz. Özellik genel önizleme aşamasında olduğundan, en kritik SAP üretim iş yükleri için senaryonun uygulanmasını önermiyoruz. Azure Paylaşılan Disk için desteklenen senaryolar hakkında daha fazla bilgi için bkz . Azure VM'de paylaşılan diskler için destek matrisi olağanüstü durum kurtarma (önizleme)
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 Disk (LRS veya ZRS) Azure Paylaşılan Disk ile Azure Site Recovery (önizlemede) 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 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.
Azure Dosyalar için alanlar arası yedeklilik depolama (ZRS) ve birincil bölgenizde Azure Paylaşılan Disk kullanıyorsanız ve DR bölgesinde de aynı ZRS yedekliliği seçeneğini korumak istiyorsanız bkz. [Premium dosya paylaşımları ZRS desteği](Azure Dosyalar premium dosya paylaşımları için alanlar arası yedekli depolama (ZRS) desteği | Microsoft Learn) ve Azure bölgelerinde ZRS desteği için yönetilen diskler için ZRS belgesi.
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.