Sdílet prostřednictvím

Konfigurace úloh SAP s využitím služby Zóny dostupnosti Azure

Nasazení různých vrstev architektury SAP napříč azure Zóny dostupnosti je doporučenou architekturou pro nasazení úloh SAP v Azure. Zóna dostupnosti Azure je definována takto: "Jedinečná fyzická umístění v rámci oblasti. Každá zóna se skládá z jednoho nebo více datacenter vybavených nezávislým napájením, chlazením a sítěmi. Azure zóny dostupnosti nejsou k dispozici ve všech oblastech. V případě oblastí Azure, které poskytují Zóny dostupnosti, zkontrolujte mapu oblastí Azure. Článek uvádí, které oblasti poskytují Zóny dostupnosti. Většina oblastí Azure, které jsou vybavené k hostování větších úloh SAP, poskytuje Zóny dostupnosti. Nové oblasti Azure poskytují Zóny dostupnosti od začátku. Some of older regions were or are in the process getting retrofitted with Availability Zones.

Jako typická architektura SAP NetWeaver nebo S/4HANA je potřeba chránit tři různé vrstvy:

  • Aplikační vrstva SAP, která může být jedna až několik desítek virtuálních počítačů. Chcete minimalizovat možnost nasazení virtuálních počítačů na stejný hostitelský server. Chcete také, aby tyto virtuální počítače v přijatelné blízkosti databázové vrstvy zachovaly latenci sítě v přijatelném okně.
  • Vrstva SAP ASCS/SCS, která představuje jediný bod selhání v architektuře SAP NetWeaver a S/4HANA. You usually look at two VMs that you want to cover with a failover framework. Proto by se tyto virtuální počítače měly přidělovat v různých doménách selhání infrastruktury.
  • Vrstva databáze SAP, která představuje jediný bod selhání. In the usual cases, it consists out of two VMs that are covered by a failover framework. Proto by se tyto virtuální počítače měly přidělovat v různých doménách selhání infrastruktury. Výjimky představují škálovací nasazení SAP HANA, kde je možné použít více než dva virtuální počítače.

Hlavní rozdíly mezi nasazením důležitých virtuálních počítačů prostřednictvím skupin dostupnosti nebo Zóny dostupnosti jsou:

  • Nasazení sady dostupnosti znamená seřazení virtuálních počítačů v rámci sady v jedné zóně nebo datacentru (v závislosti na konkrétní oblasti). V důsledku toho není nasazení prostřednictvím sady dostupnosti chráněno před problémy s napájením, chlazením nebo sítěmi, které ovlivňují datacentra zóny jako celku. U dostupnostních skupin také neexistuje vynucené sladění mezi virtuálním počítačem a jeho disky. To znamená, že disky můžou být v libovolném datacentru oblasti Azure, nezávisle na zónové struktuře oblasti. Výhodou je, že virtuální počítače jsou sladěny s aktualizačními a selhávacími doménami v rámci této zóny nebo datacentra. Konkrétně pro vrstvu SAP ASCS nebo databázovou vrstvu, kde chráníme dva virtuální počítače v rámci každé sady dostupnosti, zarovnání s doménami poruch zabraňuje umístění obou virtuálních počítačů na stejný hostitelský hardware.
  • Při nasazování virtuálních počítačů prostřednictvím Azure Zóny dostupnosti a výběru různých zón (maximálně tří možných) nasadíte virtuální počítače napříč různými fyzickými umístěními a tím se zvýší ochrana před napájením, chlazením nebo sítěmi, které ovlivňují datacentra zóny jako celku. Virtuální počítače a jejich související disky se také společně přidělují do stejné zóny dostupnosti. Když ale nasadíte více než jeden virtuální počítač stejné řady virtuálních počítačů do stejné zóny dostupnosti, neexistuje žádná ochrana před těmito virtuálními počítači na stejném hostiteli nebo stejné doméně selhání. V důsledku toho je nasazení prostřednictvím zón dostupnosti ideální pro vrstvu SAP ASCS a databáze, kde obvykle počítáme se dvěma virtuálními počítači. U aplikační vrstvy SAP, která může být výrazně větší než dva virtuální počítače, možná budete muset přejít zpět na jiný model nasazení (viz později).

Your motivation for a deployment across Azure Availability Zones should be that you, on top of covering failure of a single critical VM or ability to reduce downtime for software patching within a critical, want to protect from larger infrastructure issues that might affect the availability of one or multiple Azure datacenters.

Jako další funkci nasazení odolnosti azure zavedla škálovací sady virtuálních počítačů s flexibilní orchestrací pro úlohy SAP. Škálovací sada virtuálních počítačů poskytuje logické seskupení virtuálních počítačů spravovaných platformou. Flexibilní orchestrace škálovací sady virtuálních počítačů nabízí možnost vytvořit škálovací sadu v rámci oblasti nebo ji rozšířit napříč zónami dostupnosti. On creating, the flexible scale set within a region with platformFaultDomainCount>1 (FD>1), the VMs deployed in the scale set would be distributed across a specified number of fault domains in the same region. Na druhou stranu by vytvoření flexibilní škálovací sady napříč zónami dostupnosti pomocí platformyFaultDomainCount=1 (FD=1) distribuovalo virtuální počítače napříč různými zónami a škálovací sada také distribuovala virtuální počítače mezi různé domény selhání v rámci každé zóny na základě maximálního úsilí. Pro úlohy SAP se podporuje pouze flexibilní škálovací sada s FD=1. Výhodou použití flexibilních škálovacích sad s FD=1 pro nasazení napříč zónami místo tradičního nasazení zóny dostupnosti je, že virtuální počítače nasazené se škálovací sadou by se distribuovaly napříč různými doménami selhání v rámci zóny co nejlépe. Další informace najdete v průvodci nasazením flexibilní škálovací sady pro úlohy SAP.

Důležité informace o nasazení napříč Zóny dostupnosti

Při použití Zóny dostupnosti zvažte následující skutečnosti:

  • Další informace o zónách dostupnosti Azure najdete v dokumentu Oblasti a zóny dostupnosti.
  • Latence zpáteční cesty v síti nemusí nutně znamenat skutečnou zeměpisnou vzdálenost datových center tvořících různé zóny. Latence odezvy sítě je také ovlivněna propojením kabelu a směrováním kabelů mezi těmito různými datovými centry.
  • If you use Availability Zones as small distance DR solution, keep in mind that we experienced natural disasters causing widespread damage in different regions of the world, including heavy and widespread damage to power infrastructures. Vzdálenosti mezi různými zónami nemusí být vždy dostatečně velké, aby vyrovnaly takové větší přírodní katastrofy.
  • Latence sítě napříč Zóny dostupnosti není stejná ve všech oblastech Azure. I v rámci oblasti Azure se latence sítě mezi různými zónami můžou lišit. I když i v nejhorším případě bude synchronní replikace na úrovni databáze založená na replikaci systému HANA nebo sql Serveru AlwaysOn fungovat, aniž by to mělo vliv na škálovatelnost úlohy.
  • Při rozhodování, kde použít Zóny dostupnosti, založte své rozhodnutí na latenci sítě mezi zónami. Latence sítě hraje důležitou roli ve dvou oblastech:
    • Latence mezi dvěma instancemi databáze, které potřebují synchronní replikaci. Na základě velmi úspěšných operací největších systémů NetWeaver a S/4HANA mezi zónami s vyšší latencí sítě (méně než 1,5 milisekund) je možné tuto skutečnost zanedbávat.
    • Rozdíl v latenci sítě mezi virtuálním počítačem s instancí dialogového okna SAP v zóně s aktivní instancí databáze a podobným virtuálním počítačem v jiné zóně. S tím, jak se tento rozdíl zvyšuje, vliv na dobu běhu obchodních procesů a dávkových úloh také roste, závisí na tom, jestli běží v zóně s databází nebo v jiné zóně (viz dále v tomto článku).
  • Síťová latence s Azure Zónami dostupnosti je i v těch největších zónách dostatečně nízká pro provozování obchodních procesů SAP. Zatím jsme viděli jen několik výjimečných případů, kdy zákazníci potřebovali umístit aplikační vrstvu SAP a databázovou vrstvu pod jednu síťovou páteř datacentra.

Když nasadíte virtuální počítače Azure napříč Zóny dostupnosti a vytvoříte řešení převzetí služeb při selhání ve stejné oblasti Azure, platí některá omezení:

  • Při nasazování do Zón dostupnosti Azure musíte použít Azure Spravované disky.
  • The mapping of zone enumerations to the physical zones is fixed on an Azure subscription basis. Pokud k nasazení systémů SAP používáte různá předplatná, musíte definovat ideální zóny pro každé předplatné. Pokud chcete porovnat logické mapování různých předplatných, zvažte skript Avzone-Mapping.
  • Nemůžete nasadit sady dostupnosti Azure v zóně dostupnosti Azure, pokud nepoužijete skupinu umístění blízkosti Azure. Způsob, jak můžete nasadit databázovou vrstvu SAP a centrální služby napříč zónami a zároveň nasadit aplikační vrstvu SAP pomocí sad dostupnosti a přitom dosáhnout těsné blízkosti virtuálních počítačů, je popsán v článku Skupiny přiblížení Azure pro optimální latenci sítě s aplikacemi SAP. Pokud nepoužíváte skupiny pro umístění podle blízkosti Azure, musíte si vybrat jeden z rámců nasazení pro virtuální počítače.
  • Azure Basic Load Balancer nelze použít k vytváření řešení clusterů pro převzetí služeb při selhání založených na Windows Server Failover Clustering nebo Linux Pacemaker. Místo toho musíte použít Azure Standard Load Balancer SKU.
  • Abyste získali požadovanou zónovou ochranu, musíte nasadit zónovou verzi brány ExpressRoute, brány VPN Gateway a standardní veřejné IP adresy.

Ideální kombinace Zóny dostupnosti

Pokud nenakonfigurujete přiřazení obchodního procesu pomocí funkcí SAP, jako jsou přihlašovací skupiny, skupiny serverů RFC, skupiny dávkových serverů a podobné, je možné obchodní procesy spouštět v různých instancích aplikace napříč aplikační vrstvou SAP. Vedlejším účinkem této skutečnosti je, že dávkové úlohy mohou být spouštěny všemi instancemi aplikace SAP nezávisle na tom, zda se tyto úlohy spouští ve stejné zóně s aktivní instancí databáze nebo ne. Pokud je rozdíl v latenci sítě mezi zónami rozdílů malý v porovnání s latencí sítě v rámci zóny, nemusí být rozdíl v časech spuštění dávkových úloh významný. Čím větší je ale rozdíl latence sítě v rámci zóny ve srovnání s provozem sítě v zóně, může to mít vliv na dobu běhu dávkových úloh, pokud se úloha spustila v zóně, ve které není instance databáze aktivní. Je na vás jako zákazník, abyste se rozhodli, jaké přijatelné rozdíly v době běhu jsou. And with that what the tolerable network latency for cross zones traffic is for your workload. Čistě z technického hlediska síťové latence mezi Zónami dostupnosti Azure v rámci jedné oblasti Azure vyhovují architektuře NetWeaver, S/4HANA nebo jiných aplikací SAP. Je také na vás jako zákazník, který může tyto rozdíly zmírnit pomocí konceptů SAP přihlašovacích skupin, skupin serverů RFC, skupin batch serveru a podobných, když se rozhodnete pro některý z konceptů nasazení, které představujeme v tomto článku.

Pokud chcete nasadit systém SAP NetWeaver nebo S/4HANA napříč zónami, můžete nasadit dva způsoby architektury:

  • Aktivní/aktivní: Dvojice virtuálních počítačů se spuštěnou službou ASCS/SCS a dvojice virtuálních počítačů, na kterých běží vrstva databáze, se distribuují mezi dvě zóny. Virtuální počítače, na kterých běží aplikační vrstva SAP, se nasazují rovnoměrně přes dvě stejné zóny. If a database or ASCS/SCS VM is failing over, some of the open and active transactions might be rolled back. Uživatelé ale zůstávají přihlášeni. Nezáleží na tom, ve kterých zónách běží aktivní databázový virtuální počítač a instance aplikace. Tato architektura je upřednostňovanou architekturou pro nasazení napříč zónami. V případech, kdy latence sítě mezi zónami způsobují při provádění obchodních procesů větší rozdíly, můžete použít funkce, jako jsou skupiny SAP Logon, skupiny serverů RFC, skupiny batch serveru a podobné směrování provádění obchodních procesů do konkrétních instancí dialogových oken, které jsou ve stejné zóně s aktivní instancí databáze.
  • Aktivní/pasivní: Dvojice virtuálních počítačů se spuštěnou službou ASCS/SCS a dvojice virtuálních počítačů, na kterých běží databázová vrstva, se distribuují mezi dvě zóny. Virtuální počítače, na kterých běží aplikační vrstva SAP, se nasadí do jednoho z Zóny dostupnosti. Aplikační vrstvu spustíte ve stejné zóně jako aktivní instance ASCS/SCS a databáze. Tuto architekturu nasazení můžete použít, pokud považujete latenci sítě napříč různými zónami za příliš vysokou. A to způsobuje nesnesitelné rozdíly v běhu vašich obchodních procesů. Or if you want to use Availability Zone deployments as Short Distance DR deployments. the zones. Pokud se virtuální počítač ASCS/SCS nebo databáze přesune do sekundární zóny, můžete zaznamenat vyšší latenci sítě a s tím i snížení propustnosti. And you're required to fail back the previously failed over VM as soon as possible to get back to the previous throughput levels. If a zonal outage occurs, the application layer needs to be failed over to the secondary zone. Aktivita, kterou uživatelé zaznamuli jako úplné vypnutí systému.

Než se tedy rozhodnete, jak používat Zóny dostupnosti, musíte určit:

  • Latence sítě mezi třemi zónami oblasti Azure. Znalost latence sítě mezi zónami oblasti vám umožní zvolit zóny s nejnižší latencí sítě v síťovém provozu mezi zónami.
  • Rozdíl mezi latencí mezi virtuálními počítači v jedné z vámi vybraných zón a latencí sítě mezi dvěma z vámi vybraných zón.
  • Určení, jestli jsou typy virtuálních počítačů, které potřebujete nasadit, dostupné ve dvou vybraných zónách. U některých skladových položek virtuálních počítačů můžete narazit na situace, kdy jsou některé skladové položky dostupné pouze ve dvou ze tří zón.

Latence sítě mezi zónami a v rámci zón

Pokud chcete zjistit latenci mezi různými zónami, musíte:

  • Deploy the VM SKU you want to use for your database instance in all three zones. Při provádění tohoto měření se ujistěte, že jsou povolené akcelerované síťové služby Azure. Akcelerované síťové služby jsou výchozím nastavením od několika let. Přesto zkontrolujte, jestli je povolená a funkční.
  • Až zjistíte dvě zóny s nejnižší latencí sítě, nasaďte další tři virtuální počítače typu virtuálního počítače, který chcete použít jako aplikační vrstvu virtuálního počítače ve třech zónách dostupnosti. Změřte latenci sítě vůči dvěma databázovým virtuálním počítačům ve dvou vybraných zónách.
  • Používejte niping jako měřicí nástroj. Tento nástroj je popsaný v poznámkách k podpoře SAP #500235 a #1100926. Berte klasifikaci latence sítě v SAP Note #1100926 jako hrubé pokyny. Latence sítě větší než 0,7 milisekund neznamená, že systém nebude fungovat technicky nebo že obchodní procesy nevyhovují vašim jednotlivým smlouvám SLA. Poznámka není určená k určení toho, co je podporováno nebo nepodporuje SAP nebo Microsoft. Zaměřte se na příkazy zdokumentované pro měření latence. Because ping doesn't work through the Azure Accelerated Networking code paths, we don't recommend that you use it.

Tyto testy nemusíte provádět ručně. Najdete zde test latence zóny dostupnosti v PowerShellu, který automatizuje popsané testy latence.

Na základě vašich měření a dostupnosti SKU virtuálních počítačů v Zónách dostupnosti je potřeba provedení některých rozhodnutí:

  • Definujte ideální zóny pro vrstvu databáze.
  • Určete, jestli chcete distribuovat aktivní aplikační vrstvu SAP mezi jednu, dvě nebo všechny tři zóny, na základě rozdílů latence sítě v zóně a napříč zónami.
  • Určete, jestli chcete nasadit aktivní/pasivní konfiguraci nebo aktivní/aktivní konfiguraci, a to z hlediska aplikace. (Tyto konfigurace jsou vysvětleny dále v tomto článku.)

Důležité

Měření a rozhodnutí, která provedete, platí pro předplatné Azure, které jste použili při měření. Pokud používáte jiné předplatné Azure, mapování výčtových zón se může lišit pro jiné předplatné Azure. V důsledku toho musíte měření zopakovat nebo zjistit mapování nového předplatného vzhledem ke starému předplatnému pomocí skriptu Avzone-Mapping.

Důležité

Očekává se, že měření popsaná výše poskytují různé výsledky v každé oblasti Azure, která podporuje Zóny dostupnosti. I když jsou požadavky na latenci sítě stejné, možná budete muset přijmout různé strategie nasazení v různých oblastech Azure, protože latence sítě mezi zónami se může lišit. V některých oblastech Azure se latence sítě mezi třemi různými zónami může výrazně lišit. V jiných oblastech může být latence sítě mezi třemi různými zónami jednotnější. Tvrzení, že latence v síti je vždy mezi 1 a 2 milisekundami, není správné. Latence sítě napříč Zóny dostupnosti v oblastech Azure se nedá generalizovat.

Active/Active deployment

Tato architektura nasazení se nazývá aktivní/aktivní, protože nasazujete aktivní aplikační servery SAP ve dvou nebo třech zónách. The SAP Central Services instance that uses enqueue replication are deployed between two zones. Totéž platí pro databázovou vrstvu, která se nasazuje napříč stejnými zónami jako služba SAP Central Service. Při zvažování této konfigurace potřebujete najít dvě Zóny dostupnosti ve vaší oblasti, které nabízejí latenci sítě mezi zónami, která je pro vaši úlohu přijatelná. Také chcete mít jistotu, že rozdíl mezi latencí sítě v rámci vybraných zón a latencí sítě mezi zónami je pro vaši úlohu přijatelný.

A simplified schema of an active/active deployment across two zones could look like this:

Active/Active zone deployment

Pro tuto konfiguraci platí následující aspekty:

Aktivní/pasivní nasazení

Pokud nemůžete najít konfiguraci, která snižuje potenciální rozdíl v době běhu obchodních procesů SAP, nebo pokud chcete nasadit konfiguraci zotavení po havárii na krátkou vzdálenost, můžete nasadit architekturu s aktivním/pasivním charakterem z pohledu aplikační vrstvy SAP. Definujete aktivní zónu, což je zóna, ve které nasazujete úplnou aplikační vrstvu a kde se pokusíte spustit jak aktivní instanci databáze, tak instanci SAP Central Services. U takové konfigurace je potřeba zajistit, abyste neměli extrémní variace doby běhu v závislosti na tom, jestli se úloha spouští v zóně s aktivní instancí databáze nebo ne, v obchodních transakcích a dávkových úlohách.

Základní rozložení architektury vypadá takto:

Nasazení aktivní/pasivní zóny

Pro tuto konfiguraci platí následující aspekty:

Kombinovaná vysoká dostupnost a konfigurace zotavení po havárii

Microsoft nesdílí žádné informace o geografických vzdálenostech mezi zařízeními, která hostují různé Zóny dostupnosti Azure v oblasti Azure. Still, some customers are using zones for a combined HA and DR configuration (short distance DR) that promises a recovery point objective (RPO) of zero. RPO (Recovery Point Objective) nula znamená, že byste neměli ztratit žádné potvrzené databázové transakce ani při zotavení po havárii.

Poznámka:

If you use Availability Zones as small distance DR solution, eep in mind that we experienced natural disasters causing widespread damage in different regions of the world, including heavy and widespread damage to power infrastructures. Vzdálenosti mezi různými zónami nemusí být vždy dostatečně velké, aby vyrovnaly takové větší přírodní katastrofy.

Tady je jeden příklad, jak by taková konfigurace mohla vypadat:

Combined high-availability DR in zones

Pro tuto konfiguraci platí následující aspekty:

  • Buď předpokládáte, že mezi zařízeními hostujícími zónu dostupnosti existuje značná vzdálenost. Nebo jste nuceni zůstat v určité oblasti Azure. Skupiny dostupnosti nelze nasadit v zónách dostupnosti Azure. K kompenzaci toho můžete použít skupiny umístění bezkontaktní komunikace Azure, jak je uvedeno v článku Skupiny umístění bezkontaktní komunikace Azure pro zajištění optimální latence sítě s aplikacemi SAP.
  • Pokud používáte tuto architekturu, musíte pečlivě monitorovat stav a pokusit se zachovat aktivní instanci databáze a instance SAP Central Services ve stejné zóně jako nasazená aplikační vrstva. If there was a failover of SAP Central Service or the database instance, you want to make sure that you can manually fail back into the zone with the SAP application layer deployed as quickly as possible.
  • Na virtuálních počítačích, na kterých běží aktivní instance aplikace pro kontrolu kvality, byste měli mít předinstalované produkční instance aplikací.
  • V případě zónového selhání vypněte instance aplikace pro kontrolu kvality a místo toho spusťte produkční instance. Aby to fungovalo, musíte pro instance aplikací použít virtuální názvy.
  • For the load balancers of the failover clusters of SAP Central Services and the database layer, you need to use the Standard SKU Azure Load Balancer. Základní Load Balancer nefunguje napříč zónami.
  • Abyste získali požadovanou zónovou ochranu, musíte nasadit zónovou verzi brány ExpressRoute, brány VPN Gateway a standardní veřejné IP adresy.
  • Virtuální síť Azure, kterou jste nasadili pro hostování systému SAP společně s jejími podsítěmi, se roztáhne napříč zónami. Pro každou zónu nepotřebujete samostatné virtuální sítě.
  • Pro všechny virtuální počítače, které nasadíte, musíte použít Azure Spravované disky. Nespravované disky nejsou podporované pro zónová nasazení.
  • Azure Premium SSD v2, Ultra SSD Storage ani Azure NetApp Files nepodporují žádnou synchronní replikaci úložiště napříč zónami. U databázových nasazení spoléháme na databázové metody, které replikují data napříč zónami.
  • Ssd úrovně Premium v1, která podporuje synchronní zónovou replikaci napříč Zóny dostupnosti nebyla testována s databázovými úlohami SAP. Proto je potřeba konfigurovatelnou zónovou synchronní replikaci Azure Premium SSD v1 považovat za nepodporovaná pro databázové úlohy SAP.
  • Pro sdílené složky SMB a NFS založené na službě Azure Premium Files se nabízí zónová redundance s synchronní replikací. V tomto dokumentu zkontrolujte dostupnost ZRS pro Azure Premium Files v oblasti, do které chcete nasadit. The usage of zonal replicated NFS and SMB shares is fully supported with SAP application layer deployments and high availability failover clusters for NetWeaver or S/4HANA centrals services. Dokumenty, které se týkají těchto případů:
  • Třetí zóna se používá k hostování zařízení SBD, pokud vytvoříte cluster SUSE Linux Pacemaker a místo agenta Azure Fencing používáte zařízení SBD.

Další kroky

Tady je několik dalších kroků pro nasazení v rámci Azure Zón dostupnosti:

  • Last updated on