Aracılığıyla paylaş

SAP geçişi için iş sürekliliği ve olağanüstü durum kurtarma

  • Makale

Bu makalede BCDR için Azure giriş bölgesi tasarım alanında tanımlanan bazı önemli noktalar ve öneriler ele alınmaktadır. Makale, SAP platformunu destekleyen tüm giriş bölgelerindeki benzersiz kısıtlamaları anlamanıza yardımcı olabilir. SAP görev açısından kritik bir platform olduğundan, bu belgenin Azure giriş bölgesi Tasarım alanları bölümünde sunulan diğer yönergelere de başvurmanız ve bunu tasarımınıza dahil etmelisiniz.

Senaryo ve kapsam

Mimarinizin şirket içi iş sürekliliği ve olağanüstü durum kurtarma (BCDR) senaryolarını ele alan ilkeleri içermesi gerekir. Bu ilkeler Azure'da da geçerlidir. Temel fark, Azure'ın konak hatasını telafi etmek için şirket içi ortamınızdan daha fazla donanım kapasitesine sahip olmasıdır. Başka bir sunucuda yeniden başlatacak şekilde ayarlayarak en büyük Azure VM'lerini bile otomatik olarak kurtarabilirsiniz. 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. Kuruluşun en kritik iş süreçlerini çalıştıran SAP uygulamaları şunları gerektirir:

  • Hizmet ve iş süreci kullanılabilirliği.
  • Hata veya olağanüstü durum senaryoları için kurtarma süresi hedefleri (GPO'lar).
  • Hata senaryoları için kurtarma noktası hedefleri (RPO'lar).
  • İşletimsel ve yaşam döngüsü yönetim görevleri ve hata senaryoları sırasında 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.

İpucu

SAP ortamınızdaki arketiplerin her biri için önceden yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR) çözümü üzerinde anlaşmaya varın. Tüm SAP bileşenlerinin uygun bir çözümle kapsandığından emin olun.

Azure'da HADR'yi en az bir yatay olarak erken yapılandırın ve orada çalışmaya devam edin. Bunun yapılması, ekiplerinize mevcut teknolojilerden farklı olabilecek ilgili teknolojiler hakkında deneyim edinme fırsatı verir. HADR'yi erken yapılandırmak, standart işletim yordamlarınızı (SOP) geliştirmenize ve geliştirmenize de yardımcı olabilir.

Sistem çalışır durumda olduğunda üretim iş yükleri için tam yüksek kullanılabilirlik, olağanüstü durum kurtarma ve yedekleme korumasına sahip olmak için plan yapı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 arasında karar verme ölçütleri.

Azure bölgesinde yüksek kullanılabilirlik

Aşağıdaki bölümlerde, SAP kurumsal senaryosu için azure bölgesinde yüksek kullanılabilirlik için tasarım konuları ve öneriler sağlanmaktadır.

Yüksek kullanılabilirlik için tasarım konuları

Yüksek kullanılabilirlik için odak, SAP yazılımının tek hata noktası için kullanılabilirlik sağlamaktır, örneğin:

  • Veritabanı yönetim sistemleri.
  • SAP ABAP ve ASCS + SCS gibi uygulamada 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'lerde, DBMS'de ve SAP yazılımında 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 işlemleri sırasında meydana gelebilecek kesintileri en aza indirmek için, sistemlerinizi planlanmamış hizmet kesintilerine karşı korumaya yardımcı olan 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 yük devretmeyi destekler. Linux'ta Linux Pacemaker veya SIOS Koruma Paketi ve Veritas InfoScale gibi üçüncü taraf araçlar yük devretmeyi destekler. Azure ile kendi veri merkezinizde yalnızca 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ükleri için desteklenen senaryolar ve SAP HANA Büyük Örnekleri için desteklenen senaryolar.

DBMS katmanı için ortak mimari deseni, veritabanlarını birincil ve ikincil VM'lerin kullandığından farklı depolama yığınlarıyla aynı anda çoğaltmaktır. Azure, birincil ve ikincil VM'lerin DBMS verileri için depolama alanını paylaştığı mimarileri desteklemez. İşlem veya 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. Bu yaklaşım, şirket içinde olabilecekleri Azure'da mümkün olanlarla karşılaştırdığınızda ana 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 disklerini kullanabilirsiniz. YÜK devretme kümelerinizi SAP uygulama katmanı bileşenleri ve DBMS katmanı için ayrı olarak ayarlayın. Azure şu anda SAP uygulama katmanı bileşenlerini ve DBMS katmanını tek bir yük devretme kümesinde birleştiren yüksek kullanılabilirlik mimarilerini desteklememektedir.

SAP uygulama katmanı bileşenleri ve DBMS katmanı için çoğu yük devretme kümesi için sanal IP adresi gerekir. Oracle Data Guard kullandığınızda sık karşılaşılan bir özel durumdur. Sanal IP adresi gerektirmez. Azure Load Balancer diğer tüm durumlar için sanal IP adresini işlemelidir. Tasarım ilkelerinden biri, küme yapılandırması başına bir yük dengeleyici kullanmaktır. 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 bkz. SAP NetWeaver için yüksek kullanılabilirlik mimarisi ve senaryoları.

Aşağıda, farklı yüksek kullanılabilirlik dağıtım seçenekleri için platform düzeyinde SLA'lar yer alır. Yönetilen hizmetleri sağlayan iş ortakları, uygulama düzeyinde SLA sağlar.

Katman HA senaryosu Platform SLA'sı
Katman 1 Kullanılabilirlik alanı %99,99
Katman 2 Kullanılabilirlik kümesi %99,95
Katman 3 Tek VM (kendi kendini düzeltme) %99,9

Daha fazla bilgi için sonraki bölüme bakın.

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ümesiyle mi yoksa kullanılabilirlik alanıyla mı dağıtılacağınızı belirleyin. 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 sonuçlardan biri, 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 bir avantajı, 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. Daha fazla bilgi için bkz. Azure kullanılabilirlik alanlarıyla SAP iş yükü yapılandırmaları.

Bölgesel dağıtım yaklaşımını seçerseniz, seçilen Azure bölgesi için, uygulama sunucusu ile veritabanı arasında ve iki veritabanı düğümü arasındaki bölgeler arası gecikme süresinin performans ve mimari tasarım seçenekleri üzerindeki etkilerini göz önünde bulundurun.

Uygulama sunucusu katmanı için etkin/pasif bir bölgesel dağıtım kullanıyorsanız (uygulama sunucularının aynı kullanılabilirlik alanındaki veritabanına bağlanması gerekir), veritabanı yük devretmesi varsa hızlı ve otomatik kurtarmayı etkinleştirmek için otomasyon ve soP oluşturun.

SAP çözümünüzde kullanılabilirlik alanlarını kullanıyorsanız, gerçek alanlar arası yedeklilik elde edebilmeniz için SAP ortamınızdaki diğer tüm Azure hizmetlerini ve altyapı bileşenlerini de alanlar arası yedeklilik için tasarlayabilirsiniz. Dikkate alınması gereken hizmetlere ve bileşenlere örnek olarak Azure ExpressRoute ağ geçitleri, Azure Load Balancer, Azure Dosyalar, Azure NetApp Files, ters ara sunucu, güvenlik duvarları, virüsten koruma ve yedekleme altyapısı verilebilir.

Yüksek kullanılabilirlik için tasarım önerileri

  • Azure, uygulamanızın altyapı SLA'larını 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ı. VM'ler, kullanılabilirlik kümeleri ve kullanılabilirlik alanları için SLA'lar hakkında bilgi için bkz. Sanal Makineler için SLA.

  • Vm'leri bir kullanılabilirlik kümesinde dağıttığınızda, hata ve güncelleştirme etki alanlarıyla hizalama, VM'lerin aynı konak donanımında olmasını önler ve bu da donanım hatalarına karşı koruma sağlar. VM'leri kullanılabilirlik alanları aracılığıyla dağıttığınızda ve farklı bölgeler kullandığınızda, VM'ler farklı fiziksel konumlarda oluşturulur. Bu yapılandırma, bir bütün olarak bölgenin veri merkezlerini etkileyen güç, soğutma veya ağ sorunlarına karşı ek koruma sağlar. Ancak yakınlık yerleştirme gruplarını kullanmadığınız sürece Azure kullanılabilirlik kümelerini bir Azure kullanılabilirlik alanı içinde dağıtamazsınız.

    Bölgesel dağıtım yaklaşımı seçerseniz SAP DBMS, merkezi hizmetler ve uygulama katmanları farklı kullanılabilirlik alanlarında çalışır. Ancak, her kullanılabilirlik alanı büyük olasılıkla birden çok uygulama sunucusuna sahip olacaktır. Bu senaryoda, her bölgedeki uygulama sunucuları hata etki alanlarından ve güncelleştirme etki alanlarından otomatik olarak yararlanmaz. SAP ile en iyi ağ gecikme süresi için Azure yakınlık yerleştirme gruplarında açıklandığı gibi kullanılabilirlik kümelerini kullanarak bu avantajları elde edebilirsiniz.

  • Kullanılabilirlik kümeleri oluşturduğunuzda, kullanılabilir en fazla hata etki alanı ve güncelleştirme etki alanı sayısını kullanın. Örneğin, bir kullanılabilirlik kümesinde ikiden fazla VM dağıtırsanız, Azure planlı bakımına ek olarak olası fiziksel donanım hatalarının, ağ kesintilerinin veya güç kesintilerinin etkisini sınırlamak için en fazla hata etki alanı sayısını (üç) ve yeterli güncelleştirme etki alanını kullanın. Varsayılan hata etki alanı sayısı ikidir ve daha sonra çevrimiçi olarak değiştiremezsiniz.

  • 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 kendi kullanılabilirlik kümelerinde olmalıdır.

  • Kullanılabilirlik kümesi dağıtımında Azure yakınlık yerleştirme gruplarını kullandığınızda, üç SAP bileşeninin de (merkezi hizmetler, uygulama sunucusu ve veritabanı) aynı yakınlık yerleştirme grubunda olması gerekir.

  • Yakınlık yerleştirme grupları kullanıyorsanız SAP SID başına bir tane 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ı kullandığınızda, 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ı SAP ASCS + SCS örneklerini çalıştıran VM dağıtımıyla belirlenmiştir. Bu yapılandırmanın avantajı, VM'leri yeniden boyutlandırma konusunda daha fazla esnekliğe sahip olmanızdır. AYRıCA DBMS katmanında veya SAP sisteminin uygulama katmanında yeni VM türlerine geçmek de daha kolaydır.

  • Azure şu anda tek bir Linux Pacemaker kümesinde ASCS ve veritabanı yüksek kullanılabilirliğini birleştirmeyi desteklemez. Bunları tek tek kümelere ayırın. Bir çift VM'de beş kadar merkezi hizmet kümesini birleştirebilirsiniz.

  • ASCS ve veritabanı kümelerinin önünde Standart Load Balancer SKU kullanın.

  • Premium yönetilen SSD'lerde tüm üretim sistemlerini çalıştırın ve Azure NetApp Files veya Ultra Disk Depolama kullanın. Daha iyi performans ve en iyi SLA elde edebilmeniz için en azından işletim sistemi diskinin Premium katmanında olması gerekir.

  • Her iki VM'yi de yüksek kullanılabilirlik çiftinde bir kullanılabilirlik kümesinde veya kullanılabilirlik alanlarında dağıtın. Bu VM'ler 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 teknolojisini kullanın.

  • İşletim sistemine bağlı olarak SAP merkezi hizmet kümelerini çalıştırmak için aşağıdaki hizmetlerden birini kullanın:

  • Merkezi hizmetler ve veritabanı kümeleri için belgelerde önerilen küme zaman aşımı parametrelerini ayarlayın.

SAP iş yükleri için depolama

  • Doğru depolama seçeneklerinin seçilmesi, SAP iş yükünüz için dayanıklılık tasarımının bir parçasıdır. Azure depolamadaki SAP iş yüklerine yönelik 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. 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 bulundurun. Çeşitli depolama türleri ve BUNLARıN SAP iş yükleri ve bileşenleriyle uyumluluğu hakkında bilgi için bkz. SAP iş yükleri için Azure Depolama türleri.

  • SAP HANA'yı Azure'da yalnızca SAP tarafından onaylanan depolama türlerinde çalıştırmanız gerekir. Belirli birimlerin uygun olduğunda belirli disk yapılandırmalarında çalıştırılması gerektiğini unutmayın. Bu yapılandırmalar, Yazma Hızlandırıcısı'nın etkinleştirilmesini ve Premium depolamanın kullanılmasını içerir. Ayrıca, depolamada çalışan dosya sisteminin makinede çalışan DBMS ile uyumlu olduğundan da emin olmanız gerekir. Daha fazla bilgi için bkz . SAP HANA için depolama yapılandırmaları.

  • VM'lere eklenen Azure yönetilen veri disklerine ek olarak, SAP uygulamalarını Azure'da çalıştırmak için çeşitli Azure yerel paylaşılan depolama çözümleri kullanılır. Azure'da kullanılabilen bazı depolama hizmetleri Azure Site Recovery tarafından desteklenmediğinden yüksek kullanılabilirlik yapılandırmanız farklı olabilir. Aşağıdaki depolama türleri genellikle SAP iş yükleri için kullanılır.

    Depolama türü Yüksek kullanılabilirlik yapılandırma desteği
    Azure paylaşılan diskleri (LRS veya ZRS) Windows Server Yük Devretme Kümesi. Yapılandırma ayrıntıları için bkz . Sap HA'yı Windows Server yük devretme kümelemesi ile tasarlama .
    Azure Dosyalar üzerinde NFS (LRS veya ZRS) Linux ortamlarında pacemaker tabanlı küme. NFS'nin farklı bölgelerde kullanılabilirliğini denetlemeyi unutmayın..
    Azure NetApp Files üzerinde NFS Linux ortamlarında pacemaker tabanlı küme. Daha fazla bilgi için bkz. SAP sanal makineleri için Azure NetApp Files.
    Azure Dosyalar SMB (LRS veya ZRS) Windows Server Yük Devretme Kümesi. Yapılandırma ayrıntıları için bkz. SAP uygulamaları için Azure Dosyalar Premium SMB ile Windows'da Azure VM'lerinde SAP NetWeaver için yüksek kullanılabilirlik.
    Azure NetApp Files SMB Windows Server Yük Devretme Kümesi. Yapılandırma ayrıntıları için bkz. SAP uygulamaları için Azure NetApp Files (SMB) ile Windows'da Azure VM'lerinde SAP NetWeaver için yüksek kullanılabilirlik.

  • Azure'da SAP iş yüklerini çalıştırmak için Azure'da yerel paylaşılan depolama hizmetleri yerine, Depolama Alanları Doğrudan ile geleneksel NFS kümelerini (DRBD çoğaltmasına dayalı), GlusterFS'yi veya Küme Paylaşılan Birimi'ni kullanabilirsiniz. Bu seçenekler özellikle Azure yerel paylaşılan depolama hizmetleri hedeflenen Azure bölgesinde kullanılamadığında veya hedef mimariyi desteklemediğinde yararlıdır. Depolama hizmeti kullanılabilirliği hakkında bilgi için bkz. Bölgeye göre Azure ürünleri.

  • Azure'da SAP iş yükleri için kullanılabilen depolama seçenekleri hakkında bilgi edinmek için bkz. Olağanüstü durum kurtarmayı ayarlamaya yönelik depolama önerileri ve yönergeleri.

Yedekleme ve geri yükleme

Aşağıdaki bölümlerde, sap senaryosunda yedekleme ve geri yükleme için tasarımla ilgili önemli noktalar ve öneriler açıklanmaktadır.

Yedekleme ve geri yükleme genellikle üretim SAP iş yükü için yeterli bir yüksek kullanılabilirlik çözümü olarak kabul edilmese de, teknoloji başka avantajlar sağlar. SAP uygulamalarını kullanan çoğu şirketin, uzun yıllar boyunca yedeklemelerin depolanmasını gerektiren uyumluluk düzenlemelerine uyması gerekir. Ayrıca bir yedeğin olması ve diğer senaryolarda bu yedekten geri yüklenebilmesi de önemlidir. Sap uygulamaları için en iyi yedekleme ve geri yükleme yöntemlerini zaten oluşturduğunuz ve izlediğiniz varsayımı vardır; bu da şunları yapabileceğiniz anlamına gelir:

  • Üretim veritabanlarınız için herhangi bir noktada, RTO'nuzu karşılayan bir zaman diliminde belirli bir noktaya kurtarma gerçekleştirin. Belirli bir noktaya kurtarma genellikle DBMS katmanında veya SAP aracılığıyla verileri silme gibi işleç hatalarına karşı koruma sağlar.

  • 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ı destekleyip desteklemediğini veya Azure için bir hizmet olarak yazılım (SaaS) çözümü olup olmadığı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 sağlar. SAP HANA veritabanlarınızı depolamak için Azure NetApp Files kullanırsanız, HANA ile tutarlı depolama anlık görüntülerini temel alan yedeklemeler çalıştırabilirsiniz.

Yedekleme ve geri yükleme için tasarım önerileri

  • SAP uygulama sunucusunu ve merkezi hizmet 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 bkz. Azure VM'lerinde SAP HANA veritabanlarını yedeklemeye yönelik destek matrisi.

  • IaaS yedekleme çözümü kullanıyorsanız, yedekleme altyapısını boyutlandırarak tüm üretim boyutundaki sistemleri aynı anda veya gerçek yaşam senaryosunda olduğu gibi, beklenen zaman çerçeveleri içinde ve ağ, güvenlik vb. bakımından bir üretim kurulumu veya benzer bir kurulum kullanarak yedekleyebildiğinden emin olun.

  • Bir olağanüstü durumdan sonra tüm sistemleri aynı anda geri yüklemek için RTO gereksinimlerinizi karşıladıklarını doğrulamak için yedekleme ve kurtarma sürelerini test edin.

  • İdeal olarak, özellikle büyük veritabanları için yedeklemelerinizi Azure'dan şirket içi yedekleme altyapınıza çekmekten kaçının. Bunun yapılması ExpressRoute bağlantı hatlarının ne kadar bant genişliği kullandığını etkiler.

  • Performans testi planının bir parçası olarak yedekleme ve kurtarma araçlarını yük testi yapın.

Olağanüstü durum kurtarma

Aşağıdaki bölümlerde, sap senaryosunda olağanüstü durum kurtarma için tasarımla ilgili önemli noktalar ve öneriler açıklanmaktadır.

Olağanüstü durum kurtarma için tasarım konuları

Azure bölge haritası 65'ten fazla Azure bölgesi gösterir ve bunların tümü aynı hizmetleri çalıştırmaz. Özellikle SAP HANA kullanan daha büyük SAP yazılım dağıtımları için, Azure M serisi veya Mv2 serisi VM'ler sunan Azure bölgelerini arayın. Azure Depolama, depolama türlerinin daha küçük bir alt kümesini başka bir bölgeye çoğaltmak için farklı bölgeleri de eşleştirmektedir. 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 kuruluş, Eşleştirilmiş Azure bölgelerini kullanmaz. Bunun yerine, gerekli VM türlerinin kullanılabilirliğine bağlı olarak bölgeleri seçer.

  • 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 veya SAP HANA Sistem Çoğaltması gibi yerel DBMS özelliklerini kullanarak çoğaltmanızı çalıştırın. SAP uygulama katmanı için Site Recovery rsync veya robocopyve diğer üçüncü taraf yazılımların birleşimini kullanın.

  • Bir olağanüstü durum oluşursa, bir Azure bölgesindeki etkilenen birden çok müşteri ilgili eşleştirilmiş DR bölgesine yük devretmek ister. Bu durum, DR bölgesindeki atıl VM'leri ortaya çıkarmak için kaynakların rekabetine yol açar. Geçici çözüm, üretim dışı sistemleri DR bölgesinde çalıştırmak ve üretim sistemlerinin DR çoğaltmalarını barındırmak için aynı kaynakları kullanmaktır. DR bölgesindeki Azure altyapılarının bu çift amaçlı kullanımı, kaynak kapasitesi kısıtlamalarını önlemenize yardımcı olur.

Dikkat edilmesi gereken bir diğer önemli nokta da olağanüstü durum bölgesinde gerekli işletim kapasitesinin güvenliğini sağlamaktır. Bir olağanüstü durum oluşursa, SAP uygulamasını minimum BT kapasitesiyle ve kritik insan kaynakları tarafından yalnızca birincil bölgedeki normal işlemi kurtarmak için çalışırken minimum bir süre çalıştırmanız gerekebilir. Bunun için DR bölgesinde en az BT altyapısına sahip olmanız gerekir.

Azure bölgelerinizi tanımladıktan sonra bir dağıtım düzeni seçmeniz gerekir:

  • Üretim sistemlerini birincil bölgenize dağıtacak mısınız?
  • Üretim dışı SAP sistemlerini olağanüstü durum kurtarma bölgesine dağıtacak mısınız?
  • Tüm SAP sistemlerini birincil bölgede gruplandıran bir mimari kullanacak mısınız? Bu yapılandırma, olağanüstü durum kurtarma bölgesinin yalnızca olağanüstü durum kurtarma için kullanılmasını sağlar.

Çoğu kuruluş, SAP sistemlerini çalıştırmak için her iki bölgeyi de kullanır. Üretim sistemlerinin tam kopyalarını iş regresyon test sistemleri olarak çalıştıran kuruluşlar genellikle SAP ürün hattının iş regresyon test sistemini olağanüstü durum kurtarma hedefi olarak kullanmayı planlar.

Bir olağanüstü durum kurtarma bölgesi seçtiğinizde, Bu bölgeye ExpressRoute bağlantısına sahip olduğunuzdan emin olun. Azure'a bağlanan birden çok ExpressRoute bağlantı hattınız varsa, bu bağlantı hatlarından en az birinin birincil Azure bölgesine bağlanması gerekir. Diğerlerinin olağanüstü durum kurtarma bölgesine bağlanması gerekir. Bu mimari türü sizi farklı bir coğrafi/jeopolitik alanda Azure ağına bağlar ve bir felaket Azure bölgelerinden birini etkilerse bağlantınızın korunmasına yardımcı olur.

Bazı kuruluşlar, 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 Azure bölgesi arasındaki mesafe kadar büyük olmadığından, doğal bir afet meydana geldiği bölgedeki uygulama hizmetlerini tehlikeye atabilir. SAP uygulama sunucuları ile veritabanı sunucuları arasındaki gecikme süresini de göz önünde bulundurmanız gerekir. SAP Not 1100926 başına, 0,3 ms'den küçük veya buna eşit bir gidiş dönüş süresi iyi bir değerdir ve 0,7 ms'den küçük veya buna eşit bir süre orta değerdir. Bu nedenle, yüksek gecikme süresine sahip bölgelerde SAP uygulama sunucularının ve veritabanı sunucularının her zaman aynı bölgede çalıştığından emin olmak için işletimsel yordamların mevcut olması gerekir. Kuruluşlar bu mimariyi aşağıdaki nedenlerle seçer:

  • Üretim dağıtımı ile olağanüstü durum kurtarma hedefi arasındaki daha küçük mesafeleri destekleyen yapılandırmalarla uyumluluk yeterlidir.
  • Veri hakimiyeti bir faktördür.
  • Jeopolitik faktörler söz konusu.
  • Bu, bazen büyük etki yarıçapı olan doğal felaketler için ikincil bölgeye yedekleme aktarımıyla birlikte bölgesel hataları destekleyen düşük maliyetli bir seçenektir.

Olağanüstü durum kurtarma bölgenizi seçtiğinizde dikkate almanız 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ük olursa ağ gecikme süresi de o kadar yüksek olur. Azure bölgeleri arasında zaman uyumsuz olarak çoğaltsanız da, ağ gecikme süresi çoğaltabileceğiniz aktarım hızını ve RPO hedefini etkileyebilir. RPO'nuzu genellikle birleştirilmiş yüksek kullanılabilirlik ve olağanüstü durum kurtarma mimarisi kullanarak en aza indirebilirsiniz. Ancak bu yapılandırma büyük ölçekli 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önlendirmenin (CIDR) olağanüstü durum kurtarma sitesinin sanal CIDR'siyle çakışmadığından veya çakışmadığından emin olun.
  • Şirket içinden birincil ve ikincil Azure olağanüstü durum kurtarma bölgelerine ExpressRoute bağlantıları ayarlayın.
  • ExpressRoute'u kullanmaya alternatif olarak, şirket içinden birincil ve ikincil Azure olağanüstü durum kurtarma bölgelerine VPN bağlantıları ayarlamayı göz önünde bulundurun.
  • Bir uygulama sunucusunu olağanüstü durum kurtarma sitesine çoğaltmak için Site Recovery kullanın. Site Recovery, merkezi hizmetler kümesi VM'lerini olağanüstü durum kurtarma sitesine çoğaltmanıza da yardımcı olabilir. 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ştirmeniz, corosync.conf dosyasını çalıştırmanız vb. gerekir.
  • DR bölgesindeki verilerin şifresini çözebilmeniz için sertifikalar, gizli diziler veya anahtarlar gibi anahtar kasası içeriklerini bölgeler arasında çoğaltın.
  • 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 olağanüstü durum kurtarma sitesine eşitlemek için Site Recovery yerine yerel veritabanı çoğaltması 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 bölgede iki Azure NetApp Files hesabı oluşturun.
  • Sistemleri, uygulama performansına göre iş önemlerine ve yakınlık bağımlılıklarına göre gruplandırmayı göz önünde bulundurun. Bölgesel bir kesintinin iş etkisini en aza indirmek için her grubu eşleştirilmiş bölge yapısında ayrı bir bölgeye dağıtın. Örneğin, iki farklı iş birimine hizmet veren iki kritik ECC sistemi, bölgesel bir kesintinin etkisini en aza indirmek için Güney Birleşik Krallık ve Batı Birleşik Krallık'ta dağıtılabilir.

Sonraki adımlar

Azure'da SAP için dağıtım seçenekleri