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

  • Článek
  • 18 min ke čtení

Kromě nasazení různých vrstev architektury SAP ve skupině dostupnosti Azure je možné nedávno představené Zóny dostupnosti Azure použít také pro nasazení úloh SAP. Zóna dostupnosti Azure se definuje takto: Jedinečná fyzická umístění v rámci oblasti. Každá zóna se nachází v jednom nebo více datových centrech vybavených nezávislým napájením, chlazením a sítí. Zóny dostupnosti Azure nejsou k dispozici ve všech oblastech. V případě oblastí Azure, které Zóny dostupnosti, zkontrolujte mapu oblastí Azure. Tato mapa vám ukáže, které oblasti poskytují nebo které jsou oznámeny pro Zóny dostupnosti.

Od typické architektury SAP NetWeaver nebo S/4HANA potřebujete chránit tři různé vrstvy:

  • Aplikační vrstva SAP, což může být jeden až několik desítek virtuálních počítače. Chcete minimalizovat šanci, že se virtuální počítače nasadí na stejný hostitelský server. Chcete také, aby tyto virtuální počítače byly v přijatelné blízkosti vrstvy DBMS a udržely tak latenci sítě v přijatelném intervalu.
  • Vrstva SAP ASCS/SCS, která představuje jediný bod selhání v architektuře SAP NetWeaver a S/4HANA. Obvykle se podíváte na dva virtuální počítače, které chcete pokrýt architekturou převzetí služeb při selhání. Proto by tyto virtuální počítače měly být přiděleny v různých doménách selhání infrastruktury a aktualizačních doménách.
  • Vrstva SAP DBMS, která představuje také jediný bod selhání. V obvyklých případech se skládá ze dvou virtuálních počítače, které jsou pokryté architekturou převzetí služeb při selhání. Proto by tyto virtuální počítače měly být přiděleny v různých doménách selhání infrastruktury a aktualizačních doménách. Výjimky jsou SAP HANA nasazení s horizontálním navýšením velikosti, 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 skupiny dostupnosti nebo Zóny dostupnosti:

  • Nasazení s pomocí skupiny dostupnosti je ideální pro virtuální počítače v rámci sady v jedné zóně nebo datacentru (bez ohledu na to, co se vztahuje na konkrétní oblast). V důsledku toho není nasazení prostřednictvím skupiny dostupnosti chráněno problémy s napájením, chlazením nebo sítí, které ovlivňují 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 na jednu sadu dostupnosti, brání zarovnání s doménami selhání a aktualizačních domén, aby oba virtuální počítače skončily na stejném hostitelském hardwaru.
  • Nasazení virtuálních Zóny dostupnosti Azure přes Zóny dostupnosti Azure a výběr různých zón (zatím maximálně tři možné) nasadí virtuální počítače napříč různými fyzickými umístěními a tím se přidá dodatečná ochrana před problémy s napájením, chlazením nebo sítí, které ovlivňují datacetery zóny jako celek. Když ale do stejné zóny dostupnosti nasadíte více než jeden virtuální počítač stejné skupiny virtuálních počítače, neexistuje žádná ochrana před tím, než tyto virtuální počítače skončí na stejném hostiteli. 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, se možná budete muset vrátit k jinému modelu nasazení (viz později).

Vaší motivací pro nasazení napříč Zóny dostupnosti Azure by mělo být to, že chcete chránit před většími problémy s infrastrukturou, které můžou mít vliv na dostupnost jednoho nebo několika datacenter Azure, a měli byste řešit selhání jednoho důležitého virtuálního počítače nebo schopnost omezit výpadky při opravách softwaru v rámci kritického systému.

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

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

  • Neexistují žádné záruky týkající se vzdálenosti mezi různými Zóny dostupnosti v rámci oblasti Azure.
  • Zóny dostupnosti nejsou ideální řešení pro dr. Přírodní katastrofy mohou způsobit rozsáhlá poškození ve světě, včetně vážného poškození napájecích infrastruktur. Vzdálenosti mezi různými zónami nemusí být dostatečně velké, aby mohly představovat správné řešení pro řešení pro zajištění dostupnosti.
  • Latence sítě napříč Zóny dostupnosti ve všech oblastech Azure není stejná. 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če DBMS a instancí aplikace SAP při nasazení v různých zónách nemusí být pro obchodní procesy SAP přijatelná. V těchto případech se architektura nasazení musí lišit s architekturou aktivní/aktivní pro aplikaci nebo architekturou aktivní/pasivní, kde je latence sítě mezi zónami příliš vysoká.
  • Při rozhodování o tom, Zóny dostupnosti použít, založit 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ěji ovlivní škálovatelnost vaší úlohy.
    • Rozdíl v latenci sítě mezi virtuálním počítači se spuštěnou 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 se tento rozdíl zvyšuje, se také zvyšuje vliv na dobu běhu obchodních procesů a dávkových úloh v závislosti na tom, jestli běží v zóně s DBMS nebo v jiné zóně.

Při nasazování virtuálních Zóny dostupnosti azure a navázání řešení převzetí služeb při selhání ve stejné oblasti Azure platí některá omezení:

  • Při nasazování do Spravované disky musíte použít Azure Zóny dostupnosti Azure.
  • Mapování výčtů zón na fyzické zóny je pevně dané na základě předplatného Azure. Pokud k nasazení systémů SAP používáte různá předplatná, musíte pro každé předplatné definovat ideální zóny.
  • Skupiny dostupnosti Azure nemůžete nasadit v rámci zóny dostupnosti Azure, pokud nepou použijete skupinu umístění bezkontaktní ochrany Azure. Způsob nasazení vrstvy SAP DBMS a centrálních služeb napříč zónami a současně nasazení aplikační vrstvy SAP pomocí skupin dostupnosti a dosažení těsné blízkosti virtuálních počítačů je zdokumentovaný v článku Skupiny umístění bezkontaktní instalace Azure pro optimální latenci sítě s aplikacemi SAP. Pokud skupiny umístění bezkontaktní ochrany Azure nevyubíráte, musíte jednu nebo druhou zvolit jako rámec nasazení pro virtuální počítače.
  • K vytváření řešení clusteru s podporou převzetí služeb při selhání na základě clusteringu s Load Balancer podporou převzetí služeb při selhání Windows serveru nebo Pacemakeru s Linuxem nemůžete použít službu Azure Basic. Místo toho musíte použít SKU Azure Standard Load Balancer.

Ideální kombinace Zóny dostupnosti prostředí

Pokud chcete nasadit systém SAP NetWeaver nebo S/4HANA napříč zónami, můžete nasadit dvě základní architektury:

  • Aktivní/aktivní: Dvojice virtuálních počítačů se systémem ASCS/SCS a dvojice virtuálních počítačů, na které běží vrstva DBMS, se distribuují napříč dvěma zónami. Počet virtuálních počítače, na které běží aplikační vrstva SAP, se nasadí do rovnoměrně napříč stejnými dvěma zónami. Pokud u virtuálního počítače DBMS nebo ASCS/SCS dochází k selhání, můžou se některé otevřené a aktivní transakce vrátit zpět. Uživatelé jsou ale přihlášení. Ve skutečnosti nezáleží na tom, ve které z zón 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é běží vrstva DBMS, se distribuují napříč dvěma zónami. Počet virtuálních počítače s aplikační vrstvou 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, pokud je latence sítě v různých zónách příliš vysoká na to, aby bylo možné spustit aplikační vrstvu distribuovanou 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 dojde k selhání virtuálního počítače ASCS/SCS nebo DBMS sekundární zónou, může dojít k vyšší latenci sítě a snížení propustnosti. A abyste se vrátili k předchozím úrovním propustnosti, musíte po obnovení vrátit virtuální počítač, který dříve přešel při selhání. Pokud dojde k zónálnímu výpadku, aplikační vrstvu je potřeba přenechát služby při selhání do sekundární zóny. Aktivita, se kterou se uživatelé mohou pocházet jako s úplným vypnutím systému. V některých oblastech Azure je tato architektura jedinou životaschopnou architekturou, pokud chcete použít Zóny dostupnosti. Pokud nemůžete přijmout potenciální dopad selhání virtuálních počítačů ASCS/SCS nebo DBMS do sekundární zóny, může být lepší zůstat v nasazeních 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 v rámci jedné z zón podle vašeho výběru a latencí sítě napříč dvěma zónami podle vašeho výběru.
  • Určení, jestli jsou typy virtuálních počítače, které potřebujete nasadit, dostupné ve dvou vybraných zónách. S některými virtuálními počítače, zejména s virtuálními počítače řady M-Series, můžete narazit na situace, kdy jsou některé SKU dostupné jen ve dvou ze tří zón.

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

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

  • Nasaďte SKU 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 je povolená akcelerovaná síť Azure.
  • Když najdete dvě zóny s nejnižší latencí sítě, nasaďte další tři virtuální počítače ze SKU virtuálního počítače, které chcete použít jako virtuální počítač aplikační vrstvy, napříč těmito třemi Zóny dostupnosti. Změřte latenci sítě u dvou virtuálních počítače DBMS ve dvou vybraných zónách DBMS.
  • Použijte niping jako měřící nástroj. Tento nástroj ze systému SAP je popsaný v poznámkách k podpoře SAP #500235 a #1100926. Zaměřte se na příkazy zdokumentované pro měření latence. Vzhledem k tomu, ž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ě. Můžete najít postup PowerShellu Test latence zóny dostupnosti, který automatizuje popsané testy latence.

Na základě měření a dostupnosti skladových měr virtuálních Zóny dostupnosti musíte udělat několik rozhodnutí:

  • Definujte ideální zóny pro vrstvu DBMS.
  • Na základě rozdílů mezi latencí sítě v zóně a mezi zónami určete, jestli chcete distribuovat aktivní aplikační vrstvu SAP mezi jednu, dvě nebo všechny tři zóny.
  • Zjistěte, jestli chcete nasadit konfiguraci aktivní/pasivní nebo konfiguraci aktivní/aktivní z pohledu aplikace. (Tyto konfigurace jsou vysvětleny dále v tomto článku.)

Při těchto rozhodnutích také vezměte v úvahu doporučení SAP k latenci sítě, jak je zdokumentované v poznámkách k SAP #1100926.

Důležité

Provedená měření a rozhodnutí jsou platná pro předplatné Azure, které jste použili při měření. Pokud používáte jiné předplatné Azure, musíte měření zopakovat. Mapování výčtu zón se může pro jiné předplatné Azure lišit.

Důležité

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

Aktivní/aktivní nasazení

Tato architektura nasazení se nazývá aktivní/aktivní, protože vaše aktivní aplikační servery SAP nasazujete ve dvou nebo třech zónách. Instance služby SAP Central Services, která využívá replikaci do fronty, bude nasazena mezi dvěma zónami. Totéž platí pro vrstvu DBMS, která bude nasazena ve stejných zónách jako centrální služba SAP. 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, což je přijatelné pro vaše zatížení a synchronní replikaci DBMS. Také si přejete 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í moc velký.

Povaha architektury SAP je taková, pokud ji nenastavíte jinak, uživatelé a dávkové úlohy mohou být spuštěny v různých instancích aplikace. Vedlejším účinkem tohoto faktu s aktivním/aktivním nasazením je, že dávkové úlohy mohou být provedeny všemi instancemi aplikace SAP nezávisle na tom, zda jsou spouštěny ve stejné zóně s aktivním systémem DBMS nebo nikoli. Pokud rozdíl v latenci sítě mezi zónami rozdílů je malý v porovnání s latencí sítě v rámci zóny, rozdíl v době běhu dávkových úloh nemusí být významný. Čím větší rozdíl latence sítě v rámci zóny v porovnání s přenosem sítě v zóně je, může být ovlivněna i doba běhu dávkových úloh, pokud se úloha spustila v zóně, kde není aktivní instance systému DBMS. Je na vás jako zákazník, abyste se rozhodli, jaké jsou přijatelné rozdíly v době běhu. A s tím, co je přípustná latence sítě pro provoz mezi zónami.

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

  • Západní USA 2 (všechny tři zóny)
  • Východní USA 2 (všechny tři zóny)
  • Střed USA (všechny tři zóny)
  • Severní Evropa (všechny tři zóny)
  • Západní Evropa (dvě ze tří zón)
  • Východní USA (dvě ze tří zón)
  • Střed USA – jih (dvě ze tří zón)
  • Velká Británie – jih (dvě ze tří zón)
  • Southeast Asia

Oblasti Azure, ve kterých se tato architektura nasazení SAP mezi zónami nedoporučuje:

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

V závislosti na tom, co jste ochotni tolerovat za běhu, se liší i jiné oblasti, které zde nejsou uvedené.

Zjednodušené schéma aktivního/aktivního nasazení ve dvou zónách může vypadat takto:

Nasazení aktivní/aktivní zóny

Pro tuto konfiguraci platí následující požadavky:

Důležité

V tomto aktivním nebo aktivním scénáři se další poplatky za šířku pásma oznamují od společnosti Microsoft od 04/01/2020. Podívejte se na Podrobnosti o cenách šířky pásmadokumentu. Přenos dat mezi aplikační vrstvou SAP a vrstvou SAP DBMS je poměrně náročný. Scénář aktivní/aktivní může proto přispívat k nákladům poměrně o bit. Pokud chcete získat přesné náklady, zachovejte kontrolu tohoto článku.

Aktivní/pasivní nasazení

Pokud nemůžete najít přijatelný rozdíl mezi latencí sítě v rámci jedné zóny a latencí síťového provozu mezi zónami, můžete nasadit architekturu s aktivním/pasivním znakem z bodu aplikační vrstvy SAP. Definujete aktivní zónu, což je zóna, do které nasazujete kompletní vrstvu aplikace a kde se pokusíte spustit jak aktivní systém DBMS, tak i službu SAP Central Services. Tato konfigurace vyžaduje, abyste měli jistotu, že nemáte extrémní dobu běhu, a to 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, ve kterých může být vhodnější tento typ architektury nasazení v různých zónách:

  • Austrálie – východ
  • Brazílie – jih
  • Německo – středozápad
  • Jižní Afrika – sever
  • Francie – střed
  • Střední Kanada
  • Japonsko – východ

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

Aktivní/pasivní nasazení zóny

Pro tuto konfiguraci platí následující požadavky:

  • Skupiny dostupnosti nejde nasadit v Zóny dostupnosti Azure. Abyste to mohli kompenzovat, můžete použít skupiny umístění v blízkosti Azure, jak je popsáno v článku skupiny umístění blízkosti Azure pro optimální latenci sítě s aplikacemi SAP.

  • Když použijete tuto architekturu, musíte monitorovat stav těsně a pokusit se zachovat instance Active DBMS a služby SAP Central Services ve stejné zóně jako nasazená aplikační vrstva. V případě převzetí služeb při selhání centrální služby SAP nebo systému DBMS se ujistěte, že můžete ručně navrátit služby po obnovení do zóny s aplikační vrstvou SAP nasazenou co nejrychleji.

  • Pro nástroje pro vyrovnávání zatížení clusterů s podporou převzetí služeb při selhání v centrálních službách SAP a ve vrstvě DBMS musíte použít standardní SKU Azure Load Balancer. Základní Load Balancer nebudou v různých zónách fungovat.

  • Virtuální síť Azure, kterou jste nasadili pro hostování systému SAP, spolu s jejími podsítěmi, je roztažena v různých zónách. Pro každou zónu nepotřebujete samostatné virtuální sítě.

  • U všech virtuálních počítačů, které nasazujete, je potřeba použít Azure Managed disks. Nespravované disky nejsou podporované pro nasazení v prostředích.

  • služba Azure Premium Storage, úložiště SSD úrovně Ultranebo ANF nepodporuje žádný typ replikace úložiště napříč zónami. Aplikace (DBMS nebo SAP Central Services) musí replikovat důležitá data.

  • totéž platí pro sdílený adresář sapmnt, což je sdílený disk (Windows), sdílená složka CIFS (Windows) nebo sdílená složka systému souborů NFS (Linux). Je potřeba použít technologii, která replikuje tyto sdílené disky nebo sdílené složky mezi zónami. Podporují se tyto technologie:

    v současné době řešení, které používá souborový Server Microsoft Scale-Out, popsané v části příprava infrastruktury Azure pro sap high availability pomocí clusteru Windows s podporou převzetí služeb při selhání a sdílení souborů pro instance sap ASCS/SCS, není v zónách podporováno.

  • Třetí zóna se používá k hostování zařízení SBD v případě, že vytvoříte cluster SUSE Linux Pacemaker a místo agenta Azure oplocení použijete zařízení SBD. Nebo pro další instance aplikace.

  • Měli byste nasadit neaktivní virtuální počítače v pasivní zóně (ze zobrazení bod DBMS), abyste mohli spustit prostředky aplikace pro případ selhání zóny.

    • Azure Site Recovery aktuálně nedokáže replikovat aktivní virtuální počítače na neaktivní virtuální počítače mezi zónami.

  • Měli byste investovat do automatizace, která umožňuje automaticky spustit vrstvu aplikace SAP ve druhé zóně, pokud dojde k výpadku oblasti.

Kombinovaná konfigurace vysoké dostupnosti a zotavení po havárii

Společnost Microsoft nesdílí žádné informace o geografických vzdálenostech mezi zařízeními, která jsou hostitelem různých Zóny dostupnosti Azure v oblasti Azure. Přesto někteří zákazníci používají zóny pro kombinovanou konfiguraci HA a zotavení po havárii, která příslibů cíl bodu obnovení (RPO) nula. RPO s hodnotou nula znamená, že byste neměli přijít o žádné potvrzené databázové transakce i v případě zotavení po havárii.

Poznámka

Doporučujeme, abyste používali konfiguraci, jako je to jenom 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 příklad toho, jak by tato konfigurace mohla vypadat:

Kombinovaná vysoká dostupnost DR v zónách

Pro tuto konfiguraci platí následující požadavky:

  • Za předpokladu, že mezi zařízeními, která hostuje zónu dostupnosti, nebo v určité oblasti Azure máte významnou vzdálenost. Skupiny dostupnosti nejde nasadit v Zóny dostupnosti Azure. Abyste to mohli kompenzovat, můžete použít skupiny umístění v blízkosti Azure, jak je popsáno v článku skupiny umístění blízkosti Azure pro optimální latenci sítě s aplikacemi SAP.

  • Když použijete tuto architekturu, musíte monitorovat stav těsně a pokusit se zachovat instance Active DBMS a služby SAP Central Services ve stejné zóně jako nasazená aplikační vrstva. V případě převzetí služeb při selhání centrální služby SAP nebo systému DBMS se ujistěte, že můžete ručně navrátit služby po obnovení do zóny s aplikační vrstvou SAP nasazenou co nejrychleji.

  • Na virtuálních počítačích, na kterých běží aktivní instance aplikace QA, byste měli mít předem nainstalované instance produkčních aplikací.

  • V případě selhání v rámečku, vypněte instance aplikace QA a místo toho spusťte instance v produkčním prostředí. K provedení této práce je nutné použít virtuální názvy pro instance aplikace.

  • Pro nástroje pro vyrovnávání zatížení clusterů s podporou převzetí služeb při selhání v centrálních službách SAP a ve vrstvě DBMS musíte použít standardní SKU Azure Load Balancer. Základní Load Balancer nebudou v různých zónách fungovat.

  • Virtuální síť Azure, kterou jste nasadili pro hostování systému SAP, spolu s jejími podsítěmi, je roztažena v různých zónách. Pro každou zónu nepotřebujete samostatné virtuální sítě.

  • U všech virtuálních počítačů, které nasazujete, je potřeba použít Azure Managed disks. Nespravované disky nejsou podporované pro nasazení v prostředích.

  • služba Azure Premium Storage a úložiště SSD úrovně Ultra nepodporují žádný typ replikace úložiště mezi zónami. Aplikace (DBMS nebo SAP Central Services) musí replikovat důležitá data.

  • totéž platí pro sdílený adresář sapmnt, což je sdílený disk (Windows), sdílená složka CIFS (Windows) nebo sdílená složka systému souborů NFS (Linux). Je potřeba použít technologii, která replikuje tyto sdílené disky nebo sdílené složky mezi zónami. Podporují se tyto technologie:

    v současné době řešení, které používá souborový Server Microsoft Scale-Out, popsané v části příprava infrastruktury Azure pro sap high availability pomocí clusteru Windows s podporou převzetí služeb při selhání a sdílení souborů pro instance sap ASCS/SCS, není v zónách podporováno.

  • Třetí zóna se používá k hostování zařízení SBD v případě, že vytvoříte cluster SUSE Linux Pacemaker a místo agenta Azure oplocení použijete zařízení SBD.

Další kroky

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