Možnosti konfigurace pro minimalizaci latence sítě pomocí aplikací SAP

  • Článek

Důležité

V listopadu 2021 jsme provedli významné změny způsobu použití skupin umístění bezkontaktní komunikace s úlohami SAP v zónových nasazeních.

Aplikace SAP založené na architektuře SAP NetWeaver nebo SAP S/4HANA jsou citlivé na latenci sítě mezi aplikační vrstvou SAP a databázovou vrstvou SAP. Tato citlivost je výsledkem většiny obchodní logiky běžící v aplikační vrstvě. Vzhledem k tomu, že aplikační vrstva SAP spouští obchodní logiku, vydává dotazy na databázovou vrstvu s vysokou frekvencí, a to rychlostí tisíců nebo desítek tisíc za sekundu. Ve většině případů je povaha těchto dotazů jednoduchá. Často je možné je spustit na databázové vrstvě v 500 mikrosekundách nebo méně.

Doba strávená v síti odeslání takového dotazu z aplikační vrstvy do databázové vrstvy a přijetí výsledku odeslaného zpět má významný dopad na dobu potřebnou ke spouštění obchodních procesů. Tato citlivost na latenci sítě je důvodem, proč můžete chtít dosáhnout určité minimální latence sítě v projektech nasazení SAP. Viz SAP Note #1100926 – nejčastější dotazy: Výkon sítě s pokyny ke klasifikaci latence sítě.

V mnoha oblastech Azure se počet datacenter zvýšil. Zákazníci, zejména pro systémy SAP vysoké verze, používají současně více speciálních rodin virtuálních počítačů, jako je řada Mv2 nebo Mv3 a novější. Tyto typy virtuálních počítačů Azure nejsou vždy dostupné v každém datacentru, která shromažďují do oblasti Azure. Tato fakta můžou vytvářet příležitosti k optimalizaci latence sítě mezi aplikační vrstvou SAP a vrstvou SAP DBMS.

Azure poskytuje různé možnosti nasazení pro úlohy SAP. Pro zvolený typ nasazení máte v případě potřeby možnosti optimalizovat latenci sítě. Podrobné informace o jednotlivých možnostech jsou podrobně popsány v následujících částech tohoto článku:

Skupiny umístění bezkontaktní komunikace

Skupiny umístění bezkontaktní komunikace umožňují seskupování různých typů virtuálních počítačů v rámci jedné páteře sítě, což zajišťuje optimální nízkou latenci sítě mezi nimi. Při nasazení prvního virtuálního počítače ve skupině umístění bezkontaktní komunikace se tento virtuální počítač připojí ke konkrétní síťové páteři. Stejně jako všechny ostatní virtuální počítače, které se nasadí do stejné skupiny umístění bezkontaktní komunikace, se tyto virtuální počítače seskupí pod stejnou síťovou páteří. Vzhledem k tomu, že tento výhled zní, používání konstrukce zavádí určitá omezení a nástrahy také:

  • Nemůžete předpokládat, že všechny typy virtuálních počítačů Azure jsou dostupné v každém a všech datových centrech Azure nebo v každé a každé síťové páteři. V důsledku toho může být kombinace různých typů virtuálních počítačů v jedné skupině umístění bezkontaktní komunikace vážně omezená. K těmto omezením dochází, protože hostitelský hardware potřebný ke spuštění určitého typu virtuálního počítače nemusí být v datacentru nebo pod páteří sítě, ke kterému byla přiřazena skupina umístění bezkontaktní komunikace.
  • Při změně velikosti částí virtuálních počítačů, které jsou v jedné skupině umístění bezkontaktní komunikace, nemůžete automaticky předpokládat, že ve všech případech je nový typ virtuálního počítače dostupný ve stejném datacentru nebo pod páteří sítě, ke které byla přiřazena skupina umístění bezkontaktní komunikace.
  • Vzhledem k tomu, že Azure vyřadí hardware z provozu, může některé virtuální počítače skupiny umístění bezkontaktní komunikace vynutit do jiného datacentra Azure nebo jiné síťové páteře. Podrobnosti týkající se tohoto případu najdete v dokumentu skupiny umístění bezkontaktní komunikace.

Důležité

V důsledku potenciálních omezení by se měly používat pouze skupiny umístění bezkontaktní komunikace:

  • V případě potřeby v určitých scénářích (viz později)
  • Pokud je latence sítě mezi aplikační vrstvou a vrstvou DBMS příliš vysoká a ovlivňuje zatížení.
  • Pouze na členitosti jednoho systému SAP, a ne pro celou systémovou krajinu nebo kompletní prostředí SAP
  • Způsobem, jak zachovat různé typy virtuálních počítačů a počet virtuálních počítačů ve skupině umístění bezkontaktní komunikace na minimum

Scénáře, ve kterých je možné skupiny umístění bezkontaktní komunikace použít k optimalizaci latence sítě:

  • Chcete nasadit důležité prostředky úlohy SAP napříč různými zónami dostupnosti a na druhou stranu potřebujete virtuální počítače aplikační vrstvy, které se mají rozložit do různých domén selhání pomocí skupin dostupnosti v jednotlivých zónách. V tomto případě, jak je popsáno dále v dokumentu, skupiny umístění bezkontaktní komunikace jsou potřeba připevnění.
  • Úlohy SAP nasadíte se skupinami dostupnosti. Kde se databázová vrstva SAP seskupí do tří různých skupin dostupnosti aplikační vrstvy SAP a virtuálních počítačů ASCS/SCS. V takovém případě chcete zajistit, aby skupiny dostupnosti nebyly rozloženy do celé oblasti Azure, protože to může záviset na oblasti Azure, což by mohlo mít za následek latenci sítě, která by mohla mít negativní dopad na úlohy SAP.
  • Skupiny umístění bezkontaktní komunikace se používají k seskupení virtuálních počítačů, abyste dosáhli nejnižší možné latence sítě mezi službami hostovanými na virtuálních počítačích. Například latence v rámci samotné zóny dostupnosti nesplňuje požadavky aplikace.

Pokud jde o scénář nasazení č. 2, v mnoha oblastech, zejména v oblastech bez zón dostupnosti a většiny oblastí se zónami dostupnosti, latence sítě nezávislá na tom, kde je oblast virtuálních počítačů přijatelná. I když některé oblasti Azure nemůžou poskytovat dostatečně dobré prostředí, aniž by se tyto tři různé skupiny dostupnosti sloučí bez použití skupin umístění bezkontaktní komunikace.

Co jsou skupiny umístění bezkontaktní komunikace?

Skupina umístění bezkontaktní komunikace Azure je logická konstrukce. Když je definována skupina umístění bezkontaktní komunikace, je svázaná s oblastí Azure a skupinou prostředků Azure. Při nasazení virtuálních počítačů se na skupinu umístění bezkontaktní komunikace odkazuje:

  • První virtuální počítač Azure nasazený v páteři sítě s mnoha výpočetními jednotkami Azure a nízkou latencí sítě. Taková síťová páteř často odpovídá jednomu datacentru Azure. První virtuální počítač si můžete představit jako "virtuální počítač oboru", který je nasazený do jednotky škálování výpočetních prostředků na základě algoritmů přidělování Azure, které se nakonec zkombinují s parametry nasazení.
  • Všechny další nasazené virtuální počítače, které odkazují na skupinu umístění bezkontaktní komunikace, se nasadí pod stejnou síťovou páteří jako první virtuální počítač.

Poznámka:

Pokud není nasazen žádný hardware hostitele, který by mohl spustit konkrétní typ virtuálního počítače pod páteří sítě, kde byl první virtuální počítač umístěný, nasazení požadovaného typu virtuálního počítače nebude úspěšné. Zobrazí se zpráva o selhání přidělení, která značí, že virtuální počítač není možné podporovat v rámci hraniční skupiny umístění bezkontaktní komunikace.

Pokud chcete snížit riziko výše uvedeného, doporučujeme při vytváření skupiny umístění bezkontaktní komunikace použít možnost záměru. Možnost záměru umožňuje vypsat typy virtuálních počítačů, které chcete zahrnout do skupiny umístění bezkontaktní komunikace. Tento seznam typů virtuálních počítačů se použije k vyhledání nejlepšího datacentra, které je hostitelem těchto typů virtuálních počítačů. Pokud se takové datové centrum najde, vytvoří se PPG a bude vymezeno pro datacentrum, které splňuje požadavky skladové položky virtuálního počítače. Pokud se nenajde žádné takové datové centrum, vytvoření skupiny umístění bezkontaktní komunikace se nezdaří. Další informace najdete v dokumentaci PPG – pomocí záměru určit velikosti virtuálních počítačů. Mějte na paměti, že skutečné situace kapacity se nevezmou v úvahu v kontrolách aktivovaných možností záměru. V důsledku toho stále může dojít k chybám přidělení, které jsou kořenové v nedostatečné kapacitě k dispozici.

Jedna skupina prostředků Azure může mít přiřazených více skupin umístění bezkontaktní komunikace. Skupinu umístění bezkontaktní komunikace je ale možné přiřadit pouze k jedné skupině prostředků Azure.

Další informace a příklady nasazení skupin umístění bezkontaktní komunikace najdete v dostupné dokumentaci.

Skupiny umístění bezkontaktní komunikace se zónovými nasazeními

Je důležité zajistit přiměřeně nízkou latenci sítě mezi aplikační vrstvou SAP a vrstvou DBMS. Ve většiněpřípadůch V případě omezené sady scénářů nemusí samotné zónové nasazení splňovat požadavky na latenci aplikace. Takové situace vyžadují co nejblíže umístění virtuálního počítače a umožňují přiměřeně nízkou latenci sítě, pro takový systém SAP je možné definovat skupinu umístění bezkontaktní komunikace Azure.

Vyhněte se sdružování několika produkčních nebo neprodukčních systémů SAP do jedné skupiny umístění bezkontaktní komunikace. Vyhněte se sadám systémů SAP, protože čím více systémů seskupíte do skupiny umístění bezkontaktní komunikace, tím větší je pravděpodobnost:

  • Potřebujete typ virtuálního počítače, který není dostupný pod páteří sítě, ke které byla přiřazena skupina umístění bezkontaktní komunikace.
  • Pokud potřebujete v průběhu času rozšířit počet virtuálních počítačů do skupiny umístění bezkontaktní komunikace, prostředky jiných virtuálních počítačů, jako jsou virtuální počítače řady M-Series, můžou být nakonec nevyplněné.

Na základě mnoha vylepšení nasazených Microsoftem do oblastí Azure za účelem snížení latence sítě v rámci zóny dostupnosti Azure vypadá postup nasazení při používání skupin umístění bezkontaktní komunikace pro zónová nasazení takto:

Nové skupiny umístění bezkontaktní komunikace se zónami

Rozdíl oproti doporučením, které jsme zatím poskytli, je, že databázové virtuální počítače ve dvou zónách už nejsou součástí skupin umístění bezkontaktní komunikace. Skupiny umístění bezkontaktní komunikace na každou zónu jsou nyní vymezeny nasazením virtuálního počítače, na kterém běží instance SAP ASCS/SCS. To také znamená, že pro oblasti, ve kterých jsou zóny dostupnosti shromažďovány několika datovými centry, instancí ASCS/SCS a aplikační vrstva by mohla běžet pod jednou síťovou páteří a databázové virtuální počítače by mohly běžet pod jinou páteří sítě. I když došlo k vylepšení sítě, latence sítě mezi aplikační vrstvou SAP a vrstvou DBMS by stále měla být dostatečná pro dostatečně dobrý výkon a propustnost. Výhodou této nové konfigurace je větší flexibilita při změně velikosti virtuálních počítačů nebo přechod na nové typy virtuálních počítačů s vrstvou DBMS nebo aplikační vrstvou systému SAP.

Pro zvláštní případ použití služby Azure NetApp Files (ANF) pro prostředí DBMS a související nové funkce skupiny svazků aplikací Azure NetApp Files pro SAP HANA a její nutnost pro skupiny umístění bezkontaktní komunikace zkontrolujte dokument svazků NFS v4.1 ve službě Azure NetApp Files pro SAP HANA.

Skupiny umístění bezkontaktní komunikace s nasazeními skupiny dostupnosti

V tomto případě je účelem použití skupin umístění bezkontaktní komunikace ke kolaci virtuálních počítačů nasazených prostřednictvím různých skupin dostupnosti. V tomto scénáři použití nepoužíváte řízené nasazení napříč různými zónami dostupnosti v oblasti. Místo toho chcete nasadit systém SAP pomocí skupin dostupnosti. V důsledku toho máte alespoň sadu dostupnosti pro virtuální počítače DBMS, ASCS/SCS a virtuální počítače aplikační vrstvy. Vzhledem k tomu, že v době nasazení virtuálního počítače nemůžete určit sadu dostupnosti A zónu dostupnosti, nemůžete řídit, kde se budou virtuální počítače v různých skupinách dostupnosti přidělovat. To může vést k tomu, že latence sítě mezi různými virtuálními počítači může být příliš vysoká, aby poskytovala dostatečně dobrý výkon. Výsledná architektura by tedy vypadala takto:

Skupiny umístění bezkontaktní komunikace pomocí AvSets

V tomto obrázku by byla jedna skupina umístění bezkontaktní komunikace přiřazena jednomu systému SAP. Tato skupina PPG se přiřadí ke třem skupinám dostupnosti. Skupina umístění bezkontaktní komunikace je pak vymezena nasazením virtuálních počítačů první databázové vrstvy do skupiny dostupnosti DBMS. Toto doporučení architektury kompletuje všechny virtuální počítače pod stejnou síťovou páteří. Představuje omezení uvedená dříve v tomto článku. Proto by se měla řídce používat architektura skupiny umístění bezkontaktní komunikace.

Kombinování skupin dostupnosti a zón dostupnosti se skupinami umístění bezkontaktní komunikace

Jedním z problémů při používání zón dostupnosti pro nasazení systému SAP je, že nemůžete nasadit aplikační vrstvu SAP pomocí skupin dostupnosti v rámci konkrétní zóny dostupnosti. Chcete, aby se aplikační vrstva SAP nasadila ve stejných zónách jako virtuální počítače SAP ASCS/SCS. Odkazování na zónu dostupnosti a sadu dostupnosti při nasazování jednoho virtuálního počítače zatím není možné. Stačí ale nasadit virtuální počítač s pokynem k zóně dostupnosti, ztratíte možnost zajistit, aby se virtuální počítače aplikační vrstvy rozprostřely mezi různé aktualizační a neúspěšné domény.

Pomocí skupin umístění bezkontaktní komunikace můžete toto omezení obejít. Tady je posloupnost nasazení:

  • Vytvořte skupinu umístění bezkontaktní komunikace.
  • Nasaďte virtuální počítač ukotvení, který se doporučuje jako virtuální počítač ASCS/SCS, odkazováním na zónu dostupnosti.
  • Vytvořte skupinu dostupnosti, která odkazuje na skupinu umístění bezkontaktní komunikace Azure. (Viz příkaz dále v tomto článku.)
  • Nasaďte virtuální počítače aplikační vrstvy odkazem na skupinu dostupnosti a skupinu umístění bezkontaktní komunikace.

Důležité

Je důležité vědět, že disky virtuálních počítačů aplikační vrstvy nejsou zaručené, že se přidělují ve stejné zóně dostupnosti jako virtuální počítače směrované na používání skupiny umístění bezkontaktní komunikace. Výsledkem nasazení uvedeného v dalších krocích může být, že virtuální počítače se přidělují ve stejné páteři sítě a se stejnou zónou dostupnosti jako ukotvený virtuální počítač. Disky rektivní (základní virtuální pevný disk a připojené disky azure block storage) se ale nemusí přidělovat pod stejnou síťovou páteří nebo dokonce stejnou zónou dostupnosti. Místo toho je možné disky těchto virtuálních počítačů přidělit v libovolném datacentru konkrétní oblasti. I když se disky ukotveného virtuálního počítače nasazeného definováním zóny nasadí do stejné zóny jako nasazený virtuální počítač.

Místo nasazení prvního virtuálního počítače, jak je znázorněno v předchozí části, při nasazování virtuálního počítače odkazujete na zónu dostupnosti a skupinu umístění bezkontaktní komunikace:

New-AzVm -ResourceGroupName "ppgexercise" -Name "centralserviceszone1" -Location "westus2" -OpenPorts 80,3389 -Zone "1" -ProximityPlacementGroup "collocate" -Size "Standard_E8s_v4"

Úspěšné nasazení tohoto virtuálního počítače by hostovalo instanci ASCS/SCS systému SAP v jedné zóně dostupnosti. V tomto případě se virtuální počítač a základní virtuální pevný disk virtuálního počítače a potenciálně připojené disky blokového úložiště Azure přidělují ve stejné zóně dostupnosti. Rozsah skupiny umístění bezkontaktní komunikace je pevně nastaven na jeden ze síťových páteří v zóně dostupnosti, kterou jste definovali.

V dalším kroku musíte vytvořit skupiny dostupnosti, které chcete použít pro aplikační vrstvu systému SAP.

Definujte a vytvořte skupinu umístění bezkontaktní komunikace. Příkaz pro vytvoření skupiny dostupnosti vyžaduje další odkaz na ID skupiny umístění bezkontaktní komunikace (ne název). ID skupiny umístění bezkontaktní komunikace můžete získat pomocí tohoto příkazu:

Get-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate"

Při vytváření skupiny dostupnosti je potřeba zvážit další parametry při používání spravovaných disků (výchozí nastavení, pokud není zadáno jinak) a skupin umístění bezkontaktní komunikace:

New-AzAvailabilitySet -ResourceGroupName "ppgexercise" -Name "ppgavset" -Location "westus2" -ProximityPlacementGroupId "/subscriptions/my very long ppg id string" -sku "aligned" -PlatformUpdateDomainCount 3 -PlatformFaultDomainCount 2

V ideálním případě byste měli použít tři domény selhání. Počet podporovaných domén selhání se ale může lišit v jednotlivých oblastech. V tomto případě je maximální možný počet domén selhání pro konkrétní oblasti dva. Pokud chcete nasadit virtuální počítače aplikační vrstvy, musíte přidat odkaz na název skupiny dostupnosti a název skupiny umístění bezkontaktní komunikace, jak je znázorněno tady:

New-AzVm -ResourceGroupName "ppgexercise" -Name "appinstance1" -Location "westus2" -OpenPorts 80,3389 -AvailabilitySetName "myppgavset" -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"

Poznámka:

Disky virtuálních počítačů nasazených do výše uvedené skupiny dostupnosti se nevynucují přidělovat ve stejné zóně dostupnosti jako virtuální počítač. I když jste dosáhli toho, že se virtuální počítače aplikační vrstvy rozdělují mezi různé domény selhání ve stejné síťové páteři jako je přidělený ukotvený virtuální počítač, disky, i když se přidělují i v různých doménách selhání v různých umístěních v širokém rozsahu oblasti.

Výsledkem tohoto nasazení je:

  • Centrální služby pro váš systém SAP, který se nachází v konkrétní zóně dostupnosti.
  • Aplikační vrstva SAP, která se nachází prostřednictvím skupin dostupnosti ve stejné síťové páteři jako virtuální počítač nebo virtuální počítače SAP Central Services (ASCS/SCS).

Poznámka:

Vzhledem k tomu, že nasadíte jeden virtuální počítač DBMS a ASCS/SCS do jedné zóny a druhý virtuální počítač DBMS a ASCS/SCS do jiné zóny, abyste vytvořili konfiguraci vysoké dostupnosti, budete pro každou zónu potřebovat jinou skupinu umístění bezkontaktní komunikace. Totéž platí pro libovolnou sadu dostupnosti, kterou používáte.

Změna konfigurace skupin umístění bezkontaktní komunikace existujícího systému

Pokud jste doposud implementovali skupiny umístění bezkontaktní komunikace a chcete upravit novou konfiguraci, můžete to provést pomocí metod popsaných v těchto článcích:

Tyto příkazy můžete použít také v případech, kdy dochází k chybám přidělení v případech, kdy nemůžete přejít na nový typ virtuálního počítače s existujícím virtuálním počítačem ve skupině umístění bezkontaktní komunikace.

Škálovací sada virtuálních počítačů s flexibilní orchestrací

Pokud se chcete vyhnout omezením spojeným se skupinou umístění bezkontaktní komunikace, doporučujeme nasadit úlohy SAP napříč zónami dostupnosti pomocí flexibilní škálovací sady s FD=1. Tato strategie nasazení zajišťuje, že virtuální počítače nasazené v každé zóně nejsou omezené na jedno datové centrum nebo síťovou páteř a všechny systémové komponenty SAP, jako jsou databáze, ASCS/ERS a aplikační vrstva, jsou vymezeny v rámci zóny. S rozsahem všech systémových komponent SAP na úrovni zón musí být latence sítě mezi různými komponentami jednoho systému SAP dostatečná k zajištění uspokojivého výkonu a propustnosti. Klíčovou výhodou této nové možnosti nasazení s flexibilní škálovací sadou s FD=1 je, že poskytuje větší flexibilitu při změně velikosti virtuálních počítačů nebo přepnutí na nové typy virtuálních počítačů pro všechny vrstvy systému SAP. Škálovací sada by také přidělovala virtuální počítače napříč několika doménami selhání v jedné zóně, což je ideální pro spouštění více virtuálních počítačů aplikační vrstvy v každé zóně. Další informace najdete v tématu Škálovací sada virtuálních počítačů pro dokument úlohy SAP.

Nasazení úloh SAP v flexibilní škálovací sadě

V neprodukčním nebo mimoprodukčním prostředí je možné nasadit všechny systémové komponenty SAP, včetně databáze, ASCS a aplikační vrstvy, v jedné zóně pomocí flexibilní škálovací sady s FD=1.

Tato část obsahuje podrobnosti o dříve doporučených možnostech nasazení pro optimalizaci latence sítě pro SAP. S novými funkcemi a růstem Azure v průběhu času by se podrobnosti v této části měly používat pouze ve výjimečných případech.

Skupiny umístění bezkontaktní komunikace pro celý systém SAP s nasazením zón

Použití skupiny umístění bezkontaktní komunikace, které jsme zatím doporučili, vypadá jako v tomto obrázku.

Diagram starých skupin umístění bezkontaktní komunikace se zónami

Skupinu umístění bezkontaktní komunikace (PPG) vytvoříte v každé ze dvou zón dostupnosti, do které jste nasadili systém SAP. Všechny virtuální počítače konkrétní zóny jsou součástí individuální skupiny umístění bezkontaktní komunikace dané zóny. V každé zóně začnete nasazením virtuálního počítače DBMS, abyste mohli nastavit obor PPG, a pak virtuální počítač ASCS nasadit do stejné zóny a PPG. Ve třetím kroku vytvoříte skupinu dostupnosti Azure, přiřadíte skupinu dostupnosti k vymezené skupině PPG a nasadíte do ní aplikační vrstvu SAP. Výhodou této konfigurace bylo, že všechny komponenty jsou pěkně zarovnané pod stejnou síťovou páteří. Velkou nevýhodou je, že vaše flexibilita při změně velikosti virtuálních počítačů může být omezená.

Na základě mnoha vylepšení nasazených Microsoftem do oblastí Azure za účelem snížení latence sítě v rámci zóny dostupnosti Azure existuje aktuální pokyny k nasazení zón v tomto článku.

Skupiny umístění bezkontaktní komunikace a velké instance HANA

Pokud některé z vašich systémů SAP spoléhají na velké instance HANA pro databázovou vrstvu, můžete zaznamenat významná vylepšení latence sítě mezi jednotkou velké instance HANA a virtuálními počítači Azure při používání jednotek HANA Large Instances nasazených v řádcích revize 4 nebo razítkech. Jedním z vylepšení je, že jednotky velkých instancí HANA, které se nasazují, nasazují se skupinou umístění bezkontaktní komunikace. Tuto skupinu umístění bezkontaktní komunikace můžete použít k nasazení virtuálních počítačů aplikační vrstvy. V důsledku toho se tyto virtuální počítače nasadí ve stejném datacentru, které hostuje vaši jednotku HANA Large Instances.

Pokud chcete zjistit, jestli je jednotka velké instance HANA nasazená v razítku nebo řádku revize 4, projděte si článek Azure HANA Large Instances control prostřednictvím webu Azure Portal. V přehledu atributů jednotky velké instance HANA můžete také určit název skupiny umístění bezkontaktní komunikace, protože byla vytvořena při nasazení jednotky velké instance HANA. Název, který se zobrazí v přehledu atributů, je název skupiny umístění bezkontaktní komunikace, do které byste měli nasadit virtuální počítače aplikační vrstvy.

V porovnání se systémy SAP, které používají jenom virtuální počítače Azure, máte při použití velkých instancí HANA menší flexibilitu při rozhodování o tom, kolik skupin prostředků Azure se má použít. Všechny jednotky velkých instancí HANA tenanta velkých instancí HANA jsou seskupené do jedné skupiny prostředků, jak je popsáno v tomto článku. Pokud nenasadíte do různých tenantů oddělení, například produkčních a neprodukčních systémů nebo jiných systémů, nasadí se všechny jednotky velkých instancí HANA v jednom tenantovi HANA Large Instances. Tento tenant má relaci 1:1 se skupinou prostředků. Pro každou z jednotlivých jednotek se ale definuje samostatná skupina umístění bezkontaktní komunikace.

V důsledku toho se vztahy mezi skupinami prostředků Azure a skupinami umístění bezkontaktní komunikace pro jednoho tenanta zobrazí takto:

Diagram skupin umístění bezkontaktní komunikace a velkých instancí HANA

Další kroky

Projděte si dokumentaci: