Share via

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

  • Článek

Kromě nasazení různých vrstev architektury SAP ve skupinách dostupnosti Azure je možné azure Zóny dostupnosti použít i pro nasazení úloh SAP. 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. Tato mapa vám ukáže, které oblasti poskytují nebo se oznamují, aby poskytovaly 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 vrstvy DBMS 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 SAP DBMS, 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é problémy s napájením, chlazením nebo sítěmi, které mají vliv na datacetery zóny jako celku. 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 DBMS, kde chráníme dva virtuální počítače podle skupiny 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ři možné) 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í datové moduly zóny jako celku. 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 DBMS, 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:

  • Maximální latence odezvy sítě mezi Azure Zóny dostupnosti je uvedená v dokumentech 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.
  • Zóny dostupnosti nejsou ideálním řešením zotavení po havárii. Přírodní katastrofy můžou způsobit rozsáhlé škody ve světových oblastech, včetně těžkých škod na energetické infrastruktuře. Vzdálenosti mezi různými zónami nemusí být dostatečně velké, aby představovaly správné řešení zotavení po havárii.
  • Latence sítě napříč Zóny dostupnosti není stejná ve všech oblastech Azure. V některých případech můžete nasadit a spustit aplikační vrstvu SAP napříč různými zónami, protože latence sítě z jedné zóny do aktivního virtuálního počítače DBMS je přijatelná. V některých oblastech Azure ale latence mezi aktivním virtuálním počítačem DBMS a instancí aplikace SAP nemusí být při nasazení v různých zónách přijatelná pro obchodní procesy SAP. V těchto případech musí být architektura nasazení odlišná, s aktivní/aktivní architekturou pro aplikaci nebo aktivní/pasivní architekturou, kde latence sítě napříč zónami je příliš vysoká.
  • 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 DBMS, které potřebují synchronní replikaci. Čím vyšší je latence sítě, tím pravděpodobnější je, že ovlivňuje škálovatelnost vaší úlohy.
    • 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í DBMS a podobným virtuálním počítačem v jiné zóně. S tím, jak tento rozdíl roste, 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 DBMS nebo v jiné zóně.

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í vrstvy SAP DBMS 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.

Ideální kombinace Zóny dostupnosti

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 systémem ASCS/SCS a dvojice virtuálních počítačů, na kterých běží vrstva DBMS, se distribuují mezi dvě zóny. Početvirtuálních Pokud dojde k převzetí služeb při selhání DBMS nebo 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í virtuální počítač DBMS a instance aplikace. Tato architektura je upřednostňovanou architekturou pro nasazení napříč zónami.
  • Aktivní/pasivní: Dvojice virtuálních počítačů se systémem ASCS/SCS a dvojice virtuálních počítačů, na kterých běží vrstva DBMS, se distribuují mezi dvě zóny. Počet virtuálních počítačů, 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í instanci ASCS/SCS a DBMS. Tuto architekturu nasazení použijete v případě, že latence sítě napříč různými zónami je příliš vysoká, aby se spustila aplikační vrstva distribuovaná napříč zónami. Místo toho musí aplikační vrstva SAP běžet ve stejné zóně jako aktivní instance ASCS/SCS nebo DBMS. Pokud virtuální počítač ASCS/SCS nebo DBMS 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. V některých oblastech Azure je tato architektura jedinou realizovatelnou architekturou, pokud chcete použít Zóny dostupnosti. Pokud nemůžete přijmout potenciální dopad převzetí služeb při selhání virtuálních počítačů ASCS/SCS nebo DBMS do sekundární zóny, možná budete lépe zůstat u nasazení skupiny dostupnosti.

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 instanci DBMS 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 virtuálním počítačům DBMS ve dvou zónách DBMS, které jste vybrali.
  • Používejte niping jako měřicí nástroj. Tento nástroj je popsaný v poznámkách k podpoře SAP #500235 a #1100926. 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 DBMS.
  • 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.)

Při rozhodování také vezměte v úvahu doporučení týkající se latence sítě SAP, jak je uvedeno v poznámce SAP #1100926.

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 poskytnou 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á frontue replikace, se nasadí mezi dvěma zónami. Totéž platí pro vrstvu DBMS, která se nasadí ve stejných zónách jako 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 přijatelná pro vaši úlohu a synchronní replikaci DBMS. 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 není příliš velký.

Povaha architektury SAP spočívá v tom, že pokud ji nenakonfigurujete jinak, můžou se uživatelé a dávkové úlohy spouštět v různých instancích aplikace. Vedlejším účinkem tohoto faktu s aktivním/aktivním nasazením je, že dávkové úlohy můžou být spouštěny všemi instancemi aplikace SAP nezávisle na tom, jestli se tyto úlohy spouštějí ve stejné zóně s aktivním DBMS, 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ě napříč zónami, 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 DBMS 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.

Oblasti Azure, ve kterých by takové aktivní/aktivní nasazení mohlo být možné bez významných rozdílů v době běhu a propustnosti v rámci aplikační vrstvy nasazené v různých Zóny dostupnosti, například:

  • Austrálie – východ (dvě ze tří zón)
  • Brazílie – jih (všechny tři zóny)
  • Indie – střed (všechny tři zóny)
  • USA – střed (všechny tři zóny)
  • Východní Asie (všechny tři zóny)
  • USA – východ (dvě ze tří zón)
  • USA – východ2 (všechny tři zóny)
  • Německo – středozápad (všechny tři zóny)
  • Izrael – střed (všechny tři zóny)
  • Itálie – sever (dvě ze tří zón)
  • Korea – střed (všechny tři zóny)
  • Polsko – střed (všechny tři zóny)
  • Katar – střed (všechny tři zóny)
  • Severní Evropa (všechny tři zóny)
  • Norsko – východ (dvě ze tří zón)
  • Jižní Afrika – sever (dva ze tří)
  • USA – středojiž (všechny tři zóny)
  • Jihovýchodní Asie (všechny tři zóny)
  • Švédsko – střed (všechny tři zóny)
  • Švýcarsko – sever (všechny tři zóny)
  • Spojené arabské emiráty – sever (všechny tři zóny)
  • Velká Británie – jih (dvě ze tří zón)
  • Západní Evropa (dvě ze tří zón)
  • USA – západ2 (všechny tři zóny)
  • USA – západ3 (všechny tři zóny)

Uvedený seznam oblastí vám jako zákazník neodlehčí při testování úloh, abyste se rozhodli, jestli je možné použít architekturu aktivního/aktivního nasazení.

Oblasti Azure, kde nemusí být možná architektura aktivního nebo aktivního nasazení SAP napříč zónami, například:

  • Střední Kanada
  • Francie – střed
  • Japonsko – východ

I když pro jednotlivé úlohy může fungovat. Proto byste měli otestovat, než se rozhodnete pro architekturu. Azure neustále pracuje na zlepšení kvality a latence svých sítí. Měření prováděná roky zpět nemusí odrážet aktuální podmínky.

V závislosti na tom, co jste ochotni tolerovat rozdíly v době běhu, by se mohly kvalifikovat i jiné oblasti, které nejsou uvedené.

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

Active/Active zone deployment

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 vrstvu DBMS 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í ve vrstvě SAP Central Services a DBMS musíte použít SKU Standard Azure Load Balancer. Load Balancer úrovně Basic nebude fungovat napříč zónami.
  • 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 Storage, Úložiště SSD úrovně Ultra nebo ANF nepodporují žádný typ replikace úložiště napříč zónami. U nasazení DBMS spoléháme na databázové metody pro replikaci dat napříč zónami.
  • 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.
  • Pokud chcete dosáhnout konzistence doby běhu pro důležité obchodní procesy, můžete se pokusit určité dávkové úlohy a uživatele směrovat na instance aplikací, které jsou v zóně s aktivní instancí DBMS pomocí skupin dávkových serverů 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 vrstvou SAP DBMS 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 přijatelný rozdíl mezi latencí sítě v jedné zóně a latencí síťového provozu mezi zónami, 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é nasadíte úplnou aplikační vrstvu a kde se pokusíte spustit aktivní DBMS i instanci SAP Central Services. Při takové konfiguraci je potřeba zajistit, abyste neměli extrémní časové variace běhu v závislosti na tom, jestli úloha běží v zóně s aktivní instancí DBMS nebo ne, v obchodních transakcích a dávkových úlohách.

Oblasti Azure, kde může být tento typ architektury nasazení napříč různými zónami vhodnější:

  • Střední Kanada
  • Francie – střed
  • Japonsko – východ
  • Norsko – východ
  • Jižní Afrika – sever

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

Active/Passive zone deployment

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. Někteří zákazníci stále používají zóny pro kombinovanou konfiguraci vysoké dostupnosti a zotavení po havárii, 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:

Doporučujeme použít konfiguraci, jako je tato, pouze za určitých okolností. Můžete ho například použít, když data nemůžou opustit oblast Azure z důvodů zabezpečení nebo dodržování předpisů.

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 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í instance DBMS a 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 DBMS, 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í ve vrstvě SAP Central Services a DBMS musíte použít SKU Standard Azure Load Balancer. Load Balancer úrovně Basic nebude fungovat napříč zónami.
  • 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 Storage, Úložiště SSD úrovně Ultra nebo ANF nepodporují žádný typ replikace úložiště napříč zónami. U nasazení DBMS spoléháme na databázové metody pro replikaci dat napříč zónami.
  • 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: