Sdílet prostřednictvím

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

  • Článek

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 dostupné 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. Některé starší oblasti byly nebo jsou v procesu zpětně vybaveny Zóny dostupnosti.

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. Obvykle se díváte na dva virtuální počítače, které chcete pokrýt architekturou převzetí služeb při selhání. 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í. V obvyklých případech se skládá ze dvou virtuálních počítačů, na které se vztahuje architektura převzetí služeb při selhání. 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 jsou nasazení se škálováním na více instancí 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í se sadou dostupnosti se zabývá virtuálními počítači v rámci sady v jedné zóně nebo datacentru (to platí pro konkrétní oblast). V důsledku toho není nasazení prostřednictvím skupiny dostupnosti chráněné napájením, chlazením nebo sítěmi, které mají vliv na datacentra zóny jako celku. U skupin dostupnosti také neexistuje vynucené zarovná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. Na straně plus jsou virtuální počítače v souladu s aktualizačními doménami a doménami selhání v rámci této zóny nebo datacentra. Konkrétně pro vrstvu SAP ASCS nebo databáze, kde chráníme dva virtuální počítače na každou sadu dostupnosti, zarovnání s doménami selhání brání tomu, aby oba virtuální počítače skončily na stejném hostitelském hardwaru.
  • 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óny dostupnosti ideální pro vrstvu SAP ASCS a databáze, kde se obvykle podíváme na dva virtuální počítače. 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).

Vaší motivací pro nasazení napříč Azure Zóny dostupnosti by mělo být to, že kromě selhání jednoho kritického virtuálního počítače nebo schopnosti snížit prostoje pro opravy softwaru v rámci kritického prostředí chcete chránit před většími problémy s infrastrukturou, které by mohly ovlivnit dostupnost jednoho nebo několika datových center Azure.

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. Při vytváření se flexibilní škálovací sada v rámci oblasti s platformOuFaultDomainCount>1 (FD>1) distribuuje virtuální počítače nasazené ve škálovací sadě napříč zadaným počtem domén selhání ve stejné oblasti. 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 Azure Zóny dostupnosti najdete v dokumentu Oblasti a zóny dostupnosti.
  • Latence odezvy sítě nemusí nutně značit skutečnou zeměpisnou vzdálenost datových center, která tvoří 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.
  • Pokud používáte Zóny dostupnosti jako řešení zotavení po havárii v malé vzdálenosti, mějte na paměti, že jsme zaznamenali přírodní katastrofy, které způsobují rozsáhlé škody v různých oblastech světa, včetně těžkého a rozšířeného poškození energetické infrastruktury. Vzdálenosti mezi různýmizónami
  • 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).
  • Latence sítě s Azure Zóny dostupnosti, a to i v největších zónách, je dostatečně nízká pro spouště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 společně přidělit aplikační vrstvu SAP a databázovou vrstvu pod jednou síťovou sítí 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 Azure Zóny dostupnosti musíte použít Azure Spravované disky.
  • Mapování výčtů zóny na fyzické zóny je pevné na základě předplatného Azure. 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.
  • Skupiny dostupnosti Azure nemůžete nasadit v rámci zóny dostupnosti Azure, pokud nepoužíváte skupinu umístění bezkontaktní komunikace Azure. Způsob nasazení databázové vrstvy SAP a centrálních služeb napříč zónami a zároveň nasazení aplikační vrstvy SAP pomocí skupin dostupnosti a dosažení těsné blízkosti virtuálních počítačů je popsané v článku Skupiny umístění bezkontaktní komunikace Azure pro optimální latenci sítě s aplikacemi SAP. Pokud nepoužíváte skupiny umístění bezkontaktní komunikace Azure, musíte zvolit jednu nebo druhou jako architekturu nasazení pro virtuální počítače.
  • Azure Basic Load Balancer nemůžete použít k vytváření řešení clusteru s podporou převzetí služeb při selhání na základě clusteringu s podporou převzetí služeb při selhání Windows Serveru nebo Linux Pacemakeru. Místo toho musíte použít skladovou položku Azure Standard Load Balancer.
  • Abyste získali požadovanou zónovou ochranu, musíte nasadit zónovou verzi brány ExpressRoute, služby 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. A s tím, jaká je tolerovatelná latence sítě pro přenos mezi zónami, je určená pro vaši úlohu. Čistě z technického hlediska fungují latence sítě mezi Azure Zóny dostupnosti v rámci oblasti Azure pro architekturu 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í v sudých číslech ve stejných dvou zónách. Pokud dojde k převzetí služeb při selhání databáze nebo virtuálního počítače ASCS/SCS, můžou se některé otevřené a aktivní transakce vrátit zpět. 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 s tím, že způsobují tolerovatelné rozdíly v modulu runtime vašich obchodních procesů. Nebo pokud chcete použít nasazení zóny dostupnosti jako nasazení zotavení po havárii s krátkou vzdáleností. zóny. Pokud služba ASCS/SCS nebo databázového virtuálního počítače převezme služby při selhání sekundární zóně, může dojít k vyšší latenci sítě a snížení propustnosti. A pokud se chcete vrátit k předchozím úrovním propustnosti, musíte provést navrácení služeb po obnovení virtuálního počítače, který dříve převzal služby při selhání. Pokud dojde k výpadku zón, aplikační vrstva musí převzít služby při selhání sekundární zóně. 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 a virtuálními počítači v jedné ze zón podle vašeho výběru a latencí sítě mezi dvěma zónami podle vašeho výběru.
  • 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:

  • Nasaďte skladovou položku virtuálního počítače, kterou chcete použít pro vaši instanci databáze ve všech třech zónách. 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í.
  • Když zjistíte dvě zóny s nejnižší latencí sítě, nasaďte další tři virtuální počítače skladové položky virtuálního počítače, které chcete použít jako virtuální počítač aplikační vrstvy napříč třemi Zóny 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. Zacházejte s klasifikací latence sítě v SAP Note #1100926 jako s hrubými 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. Protože příkaz ping nefunguje prostřednictvím cest kódu akcelerovaných síťových služeb Azure, nedoporučujeme ho používat.

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ě měření a dostupnosti skladových položek virtuálních počítačů v Zóny dostupnosti je potřeba provést některá 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 je potřeba zopakovat měření nebo zjistit mapování nové reality předplatného na staré předplatné, a to 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 sítě mezi 1 a 2 milisekundami je vždy správná. Latence sítě napříč Zóny dostupnosti v oblastech Azure se nedá generalizovat.

Aktivní/aktivní nasazení

Tato architektura nasazení se nazývá aktivní/aktivní, protože nasazujete aktivní aplikační servery SAP ve dvou nebo třech zónách. Instance SAP Central Services, která používá replikaci fronty, se nasadí mezi dvěma zónami. 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ý.

Zjednodušené schéma aktivního/aktivního nasazení napříč dvěma zónami může vypadat takto:

Nasazení aktivní/aktivní zóny

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

  • Pokud nepoužíváte skupinu umístění bezkontaktní komunikace Azure, považujete azure Zóny dostupnosti za domény selhání pro všechny virtuální počítače, protože ve službě Azure Zóny dostupnosti nejde nasadit skupiny dostupnosti.
  • Pokud chcete kombinovat zónová nasazení pro databázovou vrstvu a centrální služby, ale chcete použít skupiny dostupnosti Azure pro aplikační vrstvu, musíte použít skupiny bezkontaktní komunikace Azure, jak je popsáno v článku Skupiny umístění bezkontaktní komunikace Azure pro optimální latenci sítě s aplikacemi SAP.
  • Pro nástroje pro vyrovnávání zatížení clusterů s podporou převzetí služeb při selhání služby SAP Central Services a databázové vrstvy musíte použít SKU Standard Azure Load Balancer. Load Balancer úrovně Basic nefunguje napříč zónami.
  • Abyste získali požadovanou zónovou ochranu, musíte nasadit zónovou verzi brány ExpressRoute, služby 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ě a podsí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 zvážit zónovou synchronní replikaci Azure Premium SSD v1 jako 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. Využití zónových replikovaných sdílených složek NFS a SMB je plně podporováno nasazeními aplikační vrstvy SAP a clustery s podporou převzetí služeb při selhání s vysokou dostupností pro centrální služby NetWeaver nebo S/4HANA. 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. Nebo pro více instancí aplikace.
  • Chcete-li dosáhnout konzistence doby běhu pro důležité obchodní procesy, můžete zkusit směrovat určité dávkové úlohy a uživatele na instance aplikací, které jsou v zóně s aktivní instancí databáze pomocí skupin serverů batch SAP, skupin přihlášení SAP nebo skupin RFC. V procesu zónového převzetí služeb při selhání byste ale tyto skupiny museli ručně přesunout do instancí spuštěných na virtuálních počítačích, které jsou v zóně s aktivním dbovým virtuálním počítačem.
  • V každé z zón můžete chtít nasadit neaktivní instance dialogových oken.

Důležité

V tomto scénáři aktivní/aktivní se použijí poplatky za provoz mezi zónami. Projděte si podrobnosti o cenách šířky pásma dokumentu. Přenos dat mezi aplikační vrstvou SAP a databázovými vrstvami SAP je poměrně náročný. Proto může aktivní/aktivní scénář přispět k nákladům.

Aktivní/pasivní nasazení

Pokud nemůžete najít konfiguraci, která snižuje potenciální rozdíl v modulu runtime obchodních procesů SAP nebo pokud chcete nasadit konfiguraci zotavení po havárii na krátkou vzdálenost, můžete nasadit architekturu, která má aktivní/pasivní znak z hlediska 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:

  • Skupiny dostupnosti nejde nasadit v Azure Zóny dostupnosti. Ke zmírnění 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. Pokud došlo k převzetí služeb při selhání služby SAP Central Service nebo instance databáze, chcete se ujistit, že můžete ručně navrátit služby po obnovení do zóny s nasazenou aplikační vrstvou SAP co nejrychleji.
  • Pro nástroje pro vyrovnávání zatížení clusterů s podporou převzetí služeb při selhání služby SAP Central Services a databázové vrstvy musíte použít SKU Standard Azure Load Balancer. Load Balancer úrovně Basic nefunguje napříč zónami.
  • Abyste získali požadovanou zónovou ochranu, musíte nasadit zónovou verzi brány ExpressRoute, služby 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. Využití zónových replikovaných sdílených složek NFS a SMB je plně podporováno nasazeními aplikační vrstvy SAP a clustery s podporou převzetí služeb při selhání s vysokou dostupností pro centrální služby NetWeaver nebo S/4HANA. 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. Nebo pro další instance aplikace.
  • Neaktivní virtuální počítače byste měli nasadit v pasivní zóně (z hlediska databáze), abyste mohli spustit prostředky aplikace pro případ selhání zóny. Další možností může být použití Azure Site Recovery, které dokáže replikovat aktivní virtuální počítače do neaktivních virtuálních počítačů mezi zónami.
  • Měli byste investovat do automatizace, která vám umožní automaticky spustit aplikační vrstvu SAP v druhé zóně, pokud dojde k výpadku zón.

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. Někteří zákazníci stále používají zóny pro kombinovanou konfiguraci vysoké dostupnosti a zotavení po havárii (zotavení po havárii v krátké vzdálenosti), která slibuje cíl bodu obnovení (RPO) nuly. Cíl bodu obnovení nuly znamená, že byste neměli ztratit žádné potvrzené databázové transakce ani v případech zotavení po havárii.

Poznámka:

Pokud používáte Zóny dostupnosti jako řešení zotavení po havárii v malé vzdálenosti, mějte na paměti, že jsme zaznamenali přírodní katastrofy, které způsobují rozsáhlé škody v odvozných oblastech světa, včetně těžkého a rozšířeného poškození energetické infrastruktury. Vzdálenosti mezi různýmizónami

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

Kombinované zotavení po havárii s vysokou dostupností v zónách

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 nejde nasadit v Azure Zóny dostupnosti. 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. Pokud došlo k převzetí služeb při selhání služby SAP Central Service nebo instance databáze, chcete se ujistit, že můžete ručně navrátit služby po obnovení do zóny s nasazenou aplikační vrstvou SAP co nejrychleji.
  • 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.
  • Pro nástroje pro vyrovnávání zatížení clusterů s podporou převzetí služeb při selhání služby SAP Central Services a databázové vrstvy musíte použít SKU Standard Azure Load Balancer. Load Balancer úrovně Basic nefunguje napříč zónami.
  • Abyste získali požadovanou zónovou ochranu, musíte nasadit zónovou verzi brány ExpressRoute, služby 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. Využití zónových replikovaných sdílených složek NFS a SMB je plně podporováno nasazeními aplikační vrstvy SAP a clustery s podporou převzetí služeb při selhání s vysokou dostupností pro centrální služby NetWeaver nebo S/4HANA. 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í napříč azure Zóny dostupnosti: