Spuštění SAP NetWeaver ve Windows v Azure

tato referenční architektura ukazuje sadu osvědčených postupů pro provozování SAP NetWeaver v prostředí Windows v Azure s vysokou dostupností. Databáze je AnyDB, termín SAP pro libovolný podporovaný systém správy databáze (DBMS) Kromě SAP HANA.

první diagram znázorňuje SAP NetWeaver v prostředí Windows ve scénáři skupiny dostupnosti. Architektura pro zlepšení výkonu používá Azure NetApp Files pro vrstvu sdílených souborů a skupinu umístění blízkosti.

stáhněte soubor Visio , který zobrazuje tuto architekturu.

druhý diagram znázorňuje SAP NetWeaver v prostředí Windows. Zóny dostupnosti se používají pro zlepšení odolnosti:

stáhněte soubor Visio , který zobrazuje tuto architekturu.

Architektura

Tato referenční architektura popisuje produkční systém. Je nasazená s konkrétními velikostmi virtuálních počítačů, které se dají změnit tak, aby vyhovovala potřebám vaší organizace. Dá se snížit na jeden virtuální počítač. Rozložení sítě je výrazně zjednodušené, aby se ukázaly hlavní objekty architektury. Není určena k popisu celé podnikové sítě.

Tyto součásti jsou povinné:

Virtuální sítě. Služba azure Virtual Network mezi sebou spojuje prostředky Azure s vyšším zabezpečením. V této architektuře se virtuální síť připojuje k místnímu prostředí prostřednictvím brány virtuální privátní sítě (VPN) nasazené v centru topologie hvězdicové topologie. Paprsek je virtuální síť, která se používá pro aplikace SAP a databázové vrstvy.

Partnerský vztah virtuální sítě. Tato architektura používá síťovou topologii hvězdicové sítě s několika virtuálními sítěmi, které jsou propojeny s partnerským vztahem. Tato topologie zajišťuje segmentaci sítě a izolaci pro služby nasazené v Azure. Partnerský vztah umožňuje transparentní připojení mezi partnerskými virtuálními sítěmi přes páteřní síť Microsoft. Při nasazení v rámci jedné oblasti se nejedná o snížení výkonu. Virtuální síť je rozdělená na samostatné podsítě pro každou aplikaci vrstev (SAP NetWeaver), databázi a sdílené služby (jako JumpBox a Active Directory).

Virtuální počítače. Tato architektura používá virtuální počítače pro vrstvu aplikace a databázi, které jsou seskupené takto:

• SAP NetWeaver. aplikační vrstva používá Windows virtuálních počítačů ke spouštění služeb sap Central Services a sap application servers. virtuální počítače, které spouštějí centrální služby, se nakonfigurují jako cluster s podporou převzetí služeb při selhání Windows serveru pro zajištění vysoké dostupnosti. jsou podporovány nástrojem Windows Scale-Out souborový Server s Prostory úložiště přímým přístupem nebo sdílenými disky Azure.

• AnyDB. databázová vrstva spouští AnyDB jako databázi, například Microsoft SQL Server, Oracle nebo IBM Db2.

• Pole se seznamem (označuje se také jako hostitel bastionu). Správci používají tento vylepšený virtuální počítač zabezpečení pro připojení k ostatním virtuálním počítačům. Obvykle se jedná o součást sdílených služeb, jako jsou řadiče domény a služby zálohování. Pokud jsou jediné služby používané pro správu serveru Secure Shell protokolu (SSH) a protokol RDP (Remote Desktop Protocol) (RDP), je hostitel Azure bastionu alternativou. pokud však použijete jiné nástroje pro správu, jako je například SQL Server Management Studio nebo SAP Front-end, použijte tradiční, nasazené pole s odkazem.

• Windows Server Active Directory řadiče domény. Řadiče domény se používají ke správě identit všech virtuálních počítačů a uživatelů v doméně.

Nástroje pro vyrovnávání zatížení. Nástroje pro vyrovnávání zatížení se používají k distribuci provozu do virtuálních počítačů v podsíti aplikační vrstvy. pro zajištění vysoké dostupnosti použijte integrovaného webového dispečera SAP, Azure Load Balancernebo síťová zařízení. Vaše volba závisí na typu přenosu (například grafické uživatelské rozhraní HTTP nebo SAP) nebo na požadované síťové služby, jako je například ukončení SSL (Secure Sockets Layer) (SSL).

Skupiny dostupnosti. Virtuální počítače pro všechny fondy a clustery (webový dispečer, aplikační servery SAP, centrální služby a databáze) se seskupují do samostatných skupin dostupnosti. Alespoň dva virtuální počítače jsou zřízeny na jednu roli. Skupiny dostupnosti zvyšují dostupnost aplikací a virtuálních počítačů. Díky distribuci instancí rolí na víc hostitelů to dělají prostřednictvím správy chyb hostitelských systémů nebo událostí údržby. Alternativou je použití zóny dostupnosti ke zlepšení dostupnosti úloh, jak je popsáno dále v tomto článku.

Zóna – redundantní brána. Brány Azure ExpressRoute nebo VPN Gateway se dají nasadit mezi zónami a chránit před selháními zón. Podívejte se na téma – redundantní brány virtuální sítě pro pochopení rozdílů mezi nasazením oblastí a redundantním nasazením v zóně.

Skupina umístění blízkosti. Tato logická skupina umístí omezení na virtuální počítače nasazené ve skupině dostupnosti nebo v sadě škálování virtuálního počítače. Skupina umístění blízkosti upřednostňuje společné umístění, což znamená, že virtuální počítače jsou ve stejném datovém centru pro minimalizaci latence aplikace.

Skupiny zabezpečení sítě. Pokud chcete ve virtuální síti omezit provoz příchozích, odchozích a vnitřních podsítí, vytvořte skupiny zabezpečení sítě.

Skupiny zabezpečení aplikací. Pokud chcete definovat podrobné zásady zabezpečení sítě založené na úlohách, které se zacentrují na aplikace, místo explicitních IP adres použijte skupiny zabezpečení aplikací . Umožňují seskupit virtuální počítače podle názvu a pomáhat zabezpečit aplikace filtrováním provozu z důvěryhodných segmentů vaší sítě.

Brány. Brána spojuje jedinečné sítě a rozšiřuje vaši místní síť do virtuální sítě Azure. Doporučujeme používat ExpressRoute k vytváření privátních připojení, která nejdou přes veřejný Internet, ale můžete také použít připojení typu site-to-site . Pokud chcete snížit latenci nebo zvýšit propustnost, zvažte ExpressRoute Global REACH a ExpressRoute FastPath, jak je popsáno dále v tomto článku.

Azure Storage. Azure Storage poskytuje trvalost dat pro virtuální počítač ve formě virtuálního pevného disku (VHD). Doporučujeme Azure Managed disks.

Doporučení

Tato architektura popisuje malé nasazení na úrovni v produkčním prostředí. Vaše nasazení se bude lišit v závislosti na vašich obchodních požadavcích, takže tato doporučení je vhodné použít jako výchozí bod.

Virtuální počítače

V části fondy a clustery aplikačního serveru upravte počet virtuálních počítačů podle vašich požadavků. Průvodce plánováním a implementací pro Azure Virtual Machines obsahuje podrobnosti o spuštění SAP NetWeaver na virtuálních počítačích.

Podrobnosti o podpoře SAP pro typy virtuálních počítačů Azure a metriky propustnosti (SAP) najdete v tématu SAP note 1928533. (K přístupu k poznámkám SAP potřebujete účet služby SAP Marketplace.)

Webový dispečer SAP (SWD)

Komponenta webového dispečera se používá jako nástroj pro vyrovnávání zatížení pro přenos dat SAP mezi aplikační servery SAP. pro zajištění vysoké dostupnosti pro komponentu webového dispečera Azure Load Balancer použít k implementaci clusteru s podporou převzetí služeb při selhání SWDs nebo nastavení paralelního SWD. Podrobný popis řešení najdete v tématu Vysoká dostupnost webového dispečera SAP .

Fond aplikačních serverů

transakce SAP SMLG se běžně používá ke správě přihlašovacích skupin pro jazyk ABAP aplikační servery a k vyrovnávání zatížení uživatelů přihlášení. K vyrovnávání zatížení uživatelů přihlašování také využívají jiné transakce, jako je SM61 pro skupiny Batch serveru a RZ12 pro skupiny RFC. Tyto transakce využívají funkci Vyrovnávání zatížení v rámci serveru zpráv centrální služby SAP k distribuci příchozích relací nebo úloh mezi fondem aplikačních serverů SAP pro SAP GUI a data RFC.

Cluster služby SAP Central Services

Tato referenční architektura spouští centrální služby na virtuálních počítačích v aplikační vrstvě. Centrální služby jsou potenciální selhání v jednom bodě (SPOF), když se nasadí na jeden virtuální počítač. K implementaci řešení s vysokou dostupností použijte buď cluster sdílení souborů, nebo cluster sdíleného disku.

U clusterů sdílených souborů existuje několik možností. Doporučujeme používat sdílené složky Azure Files jako plně spravované sdílené složky protokolu SMB nebo NFS, nativní pro Cloud. Alternativa k souborům Azure je Azure NetApp Files, která poskytuje vysoce výkonné sdílené složky systému souborů NFS a SMB.

sdílenou složku s vysokou dostupností můžete v instancích centrálních služeb implementovat taky pomocí služby WSFC s Souborový server se škálováním na více systémů a funkcí Prostory úložiště Direct v Windows Server 2016 a novějším. toto řešení také podporuje Windows clusterů pomocí sdílené složky, kterou obsluhuje Scale-Out souborový Server jako sdílený svazek clusteru (CSV).

pokud upřednostňujete použití sdílených disků, doporučujeme použít sdílené disky Azure k nastavení clusteru s podporou převzetí služeb při selhání Windows serveru pro cluster služby SAP Central Services.

K dispozici jsou také produkty třetích stran, jako je například " DataKeeper Cluster Edition " z technologie Corp. Tento doplněk replikuje obsah z nezávislých disků připojených k uzlům clusteru ASCS a pak tyto disky prezentuje softwaru clusteru jako CSV.

Microsoft podporuje více instancí ASCS s různými idy systému (SID) nasazených v jednom clusteru Windows přes několik sdílených složek, které nabízí stejný Souborový server se škálováním na více systémů cluster. Tato konfigurace vám pomůže snížit náklady na infrastrukturu.

V případě dělení sítě s clustery používá clusterový software hlasy k rozhodnutí, který segment sítě a jeho přidružené služby budou sloužit jako mozek nyní fragmentového clusteru. Windows nabízí řadu modelů kvora. Toto řešení používá službu Azure Cloud Witness, protože je jednodušší a poskytuje větší dostupnost než witness výpočetní uzel. Další alternativou k poskytnutí hlasu kvora clusteru je určující sdílená sdílená složky Azure.

V nasazení Azure se aplikační servery připojují k vysoce dostupným centrálním službám prostřednictvím názvů virtuálních hostitelů služeb ASCS nebo ERS. Tyto názvy hostitelů jsou přiřazeny ke konfiguraci front-endových IP adres clusteru nástroje pro vyrovnávání zatížení. Azure Load Balancer podporuje více front-endových IP adres, takže virtuální IP adresy služby ASCS i ERS je možné ohraničit na jeden nástroj pro vyrovnávání zatížení.

Skupiny dostupnosti

Skupiny dostupnosti distribuují servery do různých fyzických infrastruktur a skupin aktualizací, aby se zlepšila dostupnost služeb. Pokud chcete splnit smlouvy o úrovni služeb(SLA),umístěte virtuální počítače, které mají stejnou roli, do skupiny dostupnosti. To pomáhá chránit před plánovanými a neplánovanými výpadky způsobenými údržbou infrastruktury Azure nebo způsobenými chybami hardwaru. Pokud chcete získat vyšší sla, musíte mít dva nebo více virtuálních počítačů na jednu sadu dostupnosti.

Všechny virtuální počítače v sadě musí mít stejnou roli. Nesměšujte servery různých rolí ve stejné skupině dostupnosti. Neumiscovat například uzel ASCS do stejné skupiny dostupnosti s aplikačními servery.

Skupiny dostupnosti Azure můžete nasadit v Zóny dostupnosti Azure, když použijete skupinu umístění bezkontaktní blízkosti.

Sítě

Tato architektura používá topologii centra s paprsky. Centrální virtuální síť funguje jako centrální bod připojení k místní síti. Paprsky jsou virtuální sítě, které jsou v partnerském vztahu s centrem a izoluje úlohy SAP. Přenosy mezi místním datacentrem a centrem proudí přes připojení brány.

Síťové karty

Síťové karty umožňují veškeré komunikace mezi virtuálními počítači ve virtuální síti. Tradiční místní nasazení SAP implementují několik síťových rozhraní na jeden počítač, aby se provoz správy od obchodních přenosů odchýlí.

V Azure je virtuální síť softwarově definovaná síť, která odesílá veškerý provoz přes stejné síťové prostředky infrastruktury. Z důvodů výkonu proto není nutné používat více síťových rozhraní. Pokud ale vaše organizace potřebuje oddělení provozu, můžete nasadit několik síťových rozhraní na jeden virtuální počítač a připojit každou síťovou kartu k jiné podsíti. Pak můžete pomocí skupin zabezpečení sítě vynutit různé zásady řízení přístupu.

Síťových rozhraní Azure podporují více IP. Tato podpora odpovídá doporučenému postupu SAP pro používání názvů virtuálních hostitelů pro instalace. Úplnou osnovu najdete v poznámkové poznámce SAP 962955. (Pro přístup k poznámkám SAP potřebujete účet SAP Service Marketplace.)

Podsítě a skupiny zabezpečení sítě

Tato architektura rozděluje adresní prostor virtuální sítě do podsítí. Každou podsíť můžete přidružit ke skupině zabezpečení sítě, která definuje zásady přístupu pro podsíť. Umístěte aplikační servery do samostatné podsítě. Díky tomu je můžete snadněji zabezpečit tím, že místo jednotlivých serverů spravujete zásady zabezpečení podsítě.

Pokud je skupina zabezpečení sítě přidružená k podsíti, vztahuje se na všechny servery v podsíti a nabízí přesnou kontrolu nad servery. K jejich nastavení můžete použít Azure Portal, PowerShellnebo Azure CLI.

ExpressRoute Global Reach

Pokud vaše síťové prostředí zahrnuje dvě nebo více připojení ExpressRoute, ExpressRoute Global Reach vám může pomoct snížit latenci a segmenty směrování sítě. Tato technologie je partnerský vztah směrování protokolu BGP nastavený mezi dvěma nebo více připojeními ExpressRoute pro přemostění dvou domén směrování ExpressRoute. Global Reach snižuje latenci v případě, že síťový provoz přecházuje více než jedno připojení ExpressRoute. V současné době je k dispozici pouze pro privátní peering v okruhech ExpressRoute.

V tuto chvíli neexistují žádné seznamy řízení přístupu k síti (ACL) ani jiné atributy, které lze změnit v Global Reach. Proto se všechny trasy získané daným okruhem ExpressRoute (z místního prostředí a Azure) inzerují přes partnerský vztah okruhu do druhého okruhu ExpressRoute. Doporučujeme vytvořit místní filtrování síťového provozu, abyste omezili přístup k prostředkům.

ExpressRoute FastPath

FastPath, Microsoft Edge Exchange označované také jako Microsoft Edge Exchange (MSEE) v2, implementuje MSEE v vstupním bodě sítě Azure. Omezuje segmenty směrování v síti pro většinu datových paketů.

Pro všechna nová připojení ExpressRoute k Azure je výchozí konfigurace FastPath. Pokud chcete aktivovat FastPath, kontaktujte podpora Azure okruhy ExpressRoute.

FastPath nepodporuje peering virtuálních sítí. Pokud jsou v partnerském vztahu jiné virtuální sítě s druhou, která je připojená k ExpressRoute, síťový provoz z vaší místní sítě do jiných paprskových virtuálních sítí se bude dál odesílat do brány virtuální sítě. Alternativním řešením je přímé připojení všech virtuálních sítí k okruhu ExpressRoute.

Nástroje pro vyrovnávání zatížení

SAP Web Dispatcher zpracovává vyrovnávání zatížení provozu HTTP(S) do fondu aplikačních serverů SAP. Tento softwarový nástroj pro vyrovnávání zatížení poskytuje služby aplikační vrstvy (v síťovém modelu ISO se označuje jako vrstva 7), které mohou provádět ukončení protokolu SSL a další funkce snižování zátěže.

Azure Load Balancer je služba vrstvy síťového přenosu (vrstva 4), která vyvažuje provoz pomocí hodnoty hash řazené kolekce 5 členů z datových proudů. (Hodnota hash je založená na zdrojové IP adrese, zdrojovém portu, cílové IP adrese, cílovém portu a typu protokolu.) V nasazeních SAP v Azure se Load Balancer v nastaveních clusteru ke směrování provozu do primární instance služby nebo do uzlu, který je v pořádku, pokud dojde k chybě.

Doporučujeme používat Azure Standard Load Balancer pro všechny scénáře SAP. Pokud virtuální počítače v back-end fondu vyžadují veřejné odchozí připojení nebo pokud se používají v nasazení zóny Azure, standardní nástroje pro vyrovnávání zatížení ve výchozím nastavení vyžadují po zabezpečení více konfigurací. Nepovolí odchozí připojení, pokud ho explicitně nenakonfigurujete.

Pro přenosy z klientů SAP GUI, kteří se připojují k serveru SAP prostřednictvím protokolu DIAG nebo RFC (Remote Function Calls), server zpráv centrálních služeb vyvažuje zatížení prostřednictvím skupin přihlášení aplikačního serveruSAP. Nepotřebujete další nástroj pro vyrovnávání zatížení.

Azure Storage

Některé organizace používají pro své aplikační servery standardní úložiště. Spravované disky úrovně Standard se nepodporují. Viz poznámka SAP 1928533. (Vyžaduje se účet SAP Service Marketplace.) Ve všech případech doporučujeme používat spravované disky Azure úrovně Premium. Všimněte si, že nedávná aktualizace SAP 2015553 nezahrnuje použití úložiště HDD úrovně Standard a SSD úrovně Standard pro několik konkrétních případů použití.

Aplikační servery ne hostí obchodní data. Můžete tak také použít menší disky P4 a P6 Premium, které vám pomůžou minimalizovat náklady. To vám také umožní využít výhod smlouvy SLA pro virtuální počítače s jednou instancí, pokud máte centrální instalaci zásobníku SAP.

Pro scénáře s vysokou dostupností jsou sdílené disky Azure dostupné na Premium SSD a SSD úrovně Ultra spravovaných discích Azure. Sdílené disky Azure můžete používat s Windows Serverem, SUSE Linuxem Enterprise Serverem 15 SP1 a novějším a SUSE Linux Enterprise Server for SAP.

Azure Storage k zachování kvora se zařízením ve vzdálené oblasti Azure mimo primární oblast, kde se cluster nachází, používá také cloudová určující disková funkce.

Pro úložiště záloh dat doporučujeme studené a archivní úrovně přístupu Azure. Tyto úrovně úložiště poskytují cenově výhodný způsob, jak ukládat dlouhodobá data, která se často přistupují.

Disky úrovně Ultra výrazně snižují latenci disku a využívají důležité výkonové aplikace, jako jsou databázové servery SAP. Porovnejte možnosti blokového úložiště v Azure.

Pro vysoce dostupné a vysoce výkonné sdílené úložiště dat použijte Azure NetApp Files. Tato technologie je zvláště užitečná pro databázovou vrstvu, pokud používáte Oraclea také pro hostování aplikačních dat.

Otázky výkonu

Aplikační servery SAP neustále komunikují s databázovými servery. Pro aplikace s kritickým výkonem, které běží na databázových platformách, povolte Akcelerátor zápisu pro svazek protokolu. To může zlepšit latenci zápisu do protokolu. Akcelerátor zápisu je k dispozici pro virtuální počítače řady M. Pokud chcete optimalizovat komunikaci mezi servery, použijte akcelerované síťové služby. Akcelerované síťové služby jsou dostupné jenom pro podporované řady virtuálních počítače, včetně D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 a Ms/Mms. Další informace najdete v tématu Maximalizovat výkon virtuálního počítače pomocí akcelerovaných síťových služeb.

Běžné postupy optimalizace výkonu svazku úložiště platí pro rozložení úložiště Azure, aby se dosáhlo vysokého propustnosti vstupně-výstupních operací za iOPS a šířky pásma disku. Můžete například zkombinovat několik disků a vytvořit prokládané diskové svazky, abyste zlepšili výkon V/V. Povolení mezipaměti pro čtení v úložišti obsahu, která se nemění často, zvyšuje rychlost načítání dat.

Disky Úrovně Ultra jsou teď dostupné pro aplikace náročné na V/V. Tam, kde jsou k dispozici, doporučujeme je používat v Akcelerátor zápisu Premium Storage. Metriky výkonu, jako jsou IOPS a MB/s, můžete jednotlivě zvýšit nebo snížit, aniž byste se muset restartovat.

Pro SAP v Azure, plánování a implementace azure Virtual Machines pro SAP NetWeaver poskytuje vynikající rady k optimalizaci úložiště Azure pro úlohy SAP na SQL Server.

Nedoporučujeme umístění žádného síťového virtuálního zařízení (síťové virtuální zařízení) mezi aplikací a vrstvami databáze pro žádný zásobník aplikace SAP. Tento postup přináší významnou dobu zpracování datových paketů, což vede k nepřijatelnému výkonu aplikace.

Skupiny umístění bezkontaktní komunikace

Některé aplikace SAP vyžadují častou komunikaci s databází. Fyzická blízkost aplikace a databázových vrstev má vliv na latenci sítě, což může negativně ovlivnit výkon aplikace.

K optimalizaci latence sítě můžete použít skupiny umístění pro Proximity, které nastavují logické omezení u virtuálních počítačů nasazených ve skupinách dostupnosti. Skupiny umístění pro Proximity mají přednost před škálovatelností, dostupností nebo náklady. Můžou významně zlepšit uživatelské prostředí pro většinu aplikací SAP. Skripty jsou k dispozici na GitHub.

Zóny dostupnosti

Zóny dostupnosti umožňují nasazení virtuálních počítačů napříč zónami. To znamená, fyzicky oddělené umístění v konkrétní oblasti Azure. Jejich účelem je zlepšit dostupnost služby, ale zvažte výkon při nasazení prostředků se zónami.

Správci potřebují Vymazat profil latence sítě mezi všemi zónami cílové oblasti, aby mohli určit umístění prostředku s minimální latencí mezi zónami. Chcete-li vytvořit tento profil, nasaďte v každé zóně malý virtuální počítač pro testování. Doporučené nástroje pro tyto testy zahrnují PsPing a Iperf. Po dokončení testů odeberte virtuální počítače, které jste použili pro testování.

Aspekty zabezpečení

V případě aplikační vrstvy SAP nabízí Azure široké spektrum velikostí virtuálních počítačů pro horizontální navýšení a zmenšení velikosti. Seznam s přehledem najdete v tématu SAP note 1928533-aplikace SAP v Azure: podporované produkty a typy virtuálních počítačů Azure. (K přístupu k poznámkám SAP potřebujete účet služby SAP Marketplace.)

Můžete škálovat aplikační servery SAP a clustery centrálních služeb nahoru, dolů nebo ven přidáním dalších instancí. Databáze AnyDB se může škálovat nahoru a dolů, ale bez horizontálního navýšení kapacity. Kontejner databáze SAP pro AnyDB nepodporuje horizontálního dělení.

Aspekty dostupnosti

Redundance prostředků je obecný motiv v řešeních infrastruktury s vysokou dostupností. Pro podniky, které mají méně přísné virtuální počítače Azure s jednou instancí a disky Premium, nabízí smlouvu SLA pro provozuschopnost. Když nasadíte redundantní prostředky do skupiny dostupnosti nebo napříč Zóny dostupnosti, je dostupnost služby vyšší.

V této distribuované instalaci aplikace SAP se základní instalace replikuje, aby se dosáhlo vysoké dostupnosti. Pro každou vrstvu architektury se návrh vysoké dostupnosti liší.

Webový dispečer na úrovni aplikačních serverů

Komponenta webového dispečera se používá jako nástroj pro vyrovnávání zatížení pro přenos dat SAP mezi aplikační servery SAP. aby bylo možné dosáhnout vysoké dostupnosti webového dispečera SAP, Azure Load Balancer implementuje buď cluster s podporou převzetí služeb při selhání, nebo nastavení paralelního webového dispečera.

V případě internetové komunikace doporučujeme samostatné řešení v hraniční síti (známé také jako DMZ), aby se vyhovělo problémům se zabezpečením.

Embedded Web Dispatcher na ASCS je speciální možnost. Měli byste vzít v úvahu správné určení velikosti z důvodu dalších úloh na ASCS.

Centrální služby na úrovni aplikačních serverů

vysoká dostupnost centrálních služeb je implementovaná pomocí clusteru služby Windows Server s podporou převzetí služeb při selhání (WSFC). Když je úložiště clusteru pro cluster s podporou převzetí služeb při selhání nasazené v Azure, můžete ho nakonfigurovat dvěma způsoby: jako clusterový sdílený svazek nebo jako sdílenou složku.

Doporučujeme používat soubory Azure jako plně spravované sdílené složky protokolu SMB nebo NFS nativní pro Cloud. Alternativa k souborům Azure je Azure NetApp Files, která poskytuje vysoce výkonné sdílené složky systému souborů NFS a SMB s vysokým výkonem.

Služba WSFC podporuje použití sdílených složek obsluhovaných souborový server se škálováním na více systémů jako úložiště clusteru. Scale-Out souborový Server poskytuje odolné sdílené soubory, které můžete použít jako sdílený svazek clusteru (CSV) pro cluster Windows. Cluster souborových serverů Scale-Out můžete sdílet mezi několik instancí služby SAP Central Services.

V době psaní tohoto textu se Scale-Out souborový server používá jenom pro návrh vysoké dostupnosti v rámci jedné zóny Azure. (Nasazení mezi zónami se nepodporuje.) V případě zotavení po havárii služba Azure Site Recovery podporuje replikaci celého clusteru souborových serverů Scale-Out do vzdálené oblasti.

Existují dva způsoby, jak nastavit clustery se sdílenými disky v Azure. nejdřív doporučujeme použít sdílené disky Azure k nastavení clusteru s podporou převzetí služeb při selhání Windows serveru pro cluster služby SAP Central Services.

Alternativně můžete použít s datakeep na:

• Replikujte obsah nezávislých disků připojených k uzlům clusteru.
• Vyabstrakcte jednotky jako sdílený svazek clusteru pro správce clusteru.

Podrobné informace o implementaci najdete v tématu věnovaném clusteringu SAP ASCS v Azure.

Díky zavedení Standard Load Balancer Azure teď můžete jednoduše povolit port vysoké dostupnosti. To vám umožní vyhnout se konfiguraci pravidel vyrovnávání zatížení pro mnoho portů SAP. I když nakonfigurujete nástroje pro vyrovnávání zatížení obecně, ať už místně nebo v Azure, povolte funkci přímého serveru (označovanou taky jako plovoucí IP adresa nebo DSR). Tím umožníte, aby serverové odpovědi nepoužívaly Nástroj pro vyrovnávání zatížení. Toto přímé připojení udržuje Nástroj pro vyrovnávání zatížení v cestě k přenosu dat kritickým bodem. Pro clustery SAP ASCS a databáze doporučujeme povolit DSR.

Aplikační služby na úrovni aplikačních serverů

Vysokou dostupnost aplikačních serverů SAP se dosahuje provozem vyrovnávání zatížení v rámci fondu aplikačních serverů.

Databázová vrstva

V této referenční architektuře jsme předpokládali, že zdrojová databáze je spuštěná na AnyDB. to znamená, že DBMS jako SQL Server, SAP pomocného mechanismu, IBM Db2 nebo Oracle. Funkce nativní replikace této databázové vrstvy poskytuje buď ruční nebo automatické převzetí služeb při selhání mezi replikovanými uzly.

Podrobnosti o implementaci konkrétních databázových systémů najdete v tématu nasazení Azure Virtual Machines DBMS pro SAP NetWeaver.

Virtuální počítače nasazené napříč Zóny dostupnosti

Zóny dostupnosti jsou logické konstrukce navržené ke zlepšení dostupnosti úloh a ochraně aplikačních služeb a virtuálních počítačů proti výpadkům datového centra. Virtuální počítače v jedné zóně se považují za, jako kdyby byly v jedné aktualizaci nebo doméně selhání. Když vyberete možnost prostředí pro nasazení, jsou virtuální počítače ve stejné zóně distribuované do selhání a upgradovat domény na základě optimálního úsilí.

V oblastech Azure , které podporují tuto funkci, jsou k dispozici alespoň tři zóny. Ale maximální vzdálenost mezi datovými centry v těchto zónách není zaručena. Pro nasazení vícevrstvého systému SAP mezi zónami potřebujete znát latenci sítě v rámci zóny a v rámci cílových zón. Musíte také zjistit, jak citlivá vaše nasazené aplikace budou latence sítě.

Při rozhodování o nasazení prostředků mezi Zóny dostupnosti Vezměte v úvahu tyto informace :

• Latence mezi virtuálními počítači v jedné zóně.

• Latence mezi virtuálními počítači ve vybraných zónách.

• Dostupnost stejných služeb Azure (typů virtuálních počítačů) ve vybraných zónách.

Příklad aktivního/neaktivního nasazení

V tomto ukázkovém nasazení se stav aktivní/pasivní odkazuje na stav služby aplikace v rámci zón. V aplikační vrstvě jsou všechny čtyři aktivní aplikační servery systému SAP v zóně 1. Další sada čtyř pasivních aplikačních serverů je integrovaná v zóně 2, ale vypnutá. Budou aktivovány pouze v případě potřeby.

Clustery se dvěma uzly pro centrální služby a databázové služby se roztáhnou ve dvou zónách. Pokud se zóna 1 nezdaří, služby centrální služby a databázové služby se spustí v zóně 2. Aktivují se pasivní aplikační servery v zóně 2. Všechny komponenty tohoto systému SAP teď společně umístěného ve stejné zóně, přičemž latence sítě se minimalizuje.

Příklad aktivního/aktivního nasazení

V aktivním/aktivním nasazení jsou dvě sady aplikačních serverů postavené napříč dvěma zónami. V rámci každé zóny jsou dva aplikační servery v každé sadě serverů neaktivní (vypnuté). V důsledku toho jsou během normálního provozu v obou zónách aktivní aplikační servery.

Centrální služby a databázové služby běží v zóně 1. Aplikační servery v zóně 2 můžou mít delší latenci sítě, když se připojují k centrálním službám a databázovým službám z důvodu fyzické vzdálenosti mezi zónami.

Pokud zóna 1 přejde do offline režimu, centrální služby a databázové služby se převezmou na zónu 2. Můžete přepnout neaktivní aplikační servery do online režimu a poskytnout tak úplnou kapacitu pro zpracování aplikací.

Aspekty zotavení po havárii

Každá úroveň v zásobníku aplikace SAP používá jinou strategii zotavení po havárii.

Aplikační servery – vrstva

Aplikační servery SAP neobsahují obchodní data. V Azure je jednoduchá strategie zotavení po havárii potřeba vytvořit aplikační servery SAP v sekundární oblasti a pak je vypnout. Pokud na primárním aplikačním serveru existují změny konfigurace nebo aktualizace jádra, je nutné použít stejné změny u virtuálních počítačů v sekundární oblasti. Například zkopírujte spustitelné soubory jádra SAP do virtuálních počítačů DR.

Pro automatickou replikaci aplikačních serverů do sekundární oblasti doporučujeme Azure Site Recovery. Azure Site Recovery můžete použít také k nastavení zotavení po havárii pro nasazení aplikace s více vrstvami SAP NetWeaver .

Centrální služby

Tato součást zásobníku aplikace SAP neuchovává obchodní data. V případě ochrany DR proveďte replikaci obsahu/sapmnt do úsporného virtuálního počítače v oblasti zotavení po havárii nebo použijte Azure Site Recovery k replikaci clusteru centrálních služeb a clusteru Scale-Out souborového serveru. Alternativně můžete pomocí Site Recovery replikovat cluster centrálních služeb pomocí s použitím s datakeeps disks.

Můžete vytvořit virtuální počítač v oblasti zotavení po havárii pro replikaci role a obsahu centrální služby. Jediným obsahem z primárního uzlu centrální služby, který se má synchronizovat, je/sapmnt sdílená složka. Pokud se změny konfigurace nebo aktualizace jádra provádějí na primárních serverech centrálních služeb, musíte změny na virtuálním počítači zopakovat v oblasti zotavení po havárii. podrobnosti o procesu sestavení, kopírování a testování převzetí služeb při selhání této metody replikace získáte stažením SAP NetWeaver: vytvoření řešení pro zotavení po havárii založeného na technologii Hyper-V a Microsoft Azure. Viz "4,3. která je věnovaná vrstvě SAP SPOF (ASCS).

při implementaci vysoké dostupnosti pro centrální služby pomocí Scale-Out souborového serveru nebo s, Site Recovery podporuje replikaci a obnovení clusteru centrálních služeb i clusteru Scale-Out souborového serveru/Storageho prostoru s přímým přístupem. Můžete taky replikovat a obnovovat cluster centrálních služeb pomocí s použitím s DataKeeper disky.

Databázová vrstva

Pro zotavení po havárii se doporučuje používat integrovanou technologii replikace databáze. pro SQL Server například doporučujeme používat skupiny dostupnosti Always On k vytvoření repliky ve vzdálené oblasti a asynchronní replikaci transakcí pomocí ručního převzetí služeb při selhání. Asynchronní replikace zabraňuje vlivu na výkon interaktivních úloh v primární lokalitě. Pokud používáte ruční převzetí služeb při selhání, můžete posoudit dopad na zotavení po havárii a rozhodnout se, jestli je provoz z webu DR odůvodněný.

Pokud pro úložiště databáze používáte Azure NetApp Files, můžete k replikaci dat do sekundární oblasti použít replikaci mezi jednotlivými oblastmi . Tato funkce je aktuálně ve verzi Preview, proto Vyhodnoťte, jestli splňuje vaše požadavky na produkční úlohy.

DR pro sdílené služby

Mnohé IT služby, jako jsou například odkazy pro správu, cloudové adresářové služby, zálohování a monitorovací služby, jsou sdíleny všemi vašimi nasazenými cloudými prostředky. Sdílené služby se replikují do oblasti zotavení po havárii pomocí libovolného způsobu poskytování služeb.

Automatizované zotavení po havárii s Azure Site Recovery

Chcete-li použít Azure Site Recovery k automatickému vytvoření plně replikované provozní lokality původní konfigurace, je nutné spustit přizpůsobené skripty nasazení. Site Recovery například nejdřív nasadí virtuální počítače do skupin dostupnosti. Potom spustí vlastní skripty, aby připojily existující (předem sestavený) Nástroj pro vyrovnávání zatížení, ve kterém je již fond back-end definován, do síťové karty virtuálních počítačů s podporou převzetí služeb při selhání. Příklad vlastního skriptu Site Recovery Automation Runbooky je k dispozici v GitHub.

Požadavky na správu a provoz

Backup

Databáze jsou kritické úlohy, které vyžadují nízký cíl bodu obnovení (RPO) a dlouhodobé uchovávání.

• pro SAP na SQL Server je jedním z přístupů použití Azure Backup k zálohování SQL Server databází, které běží na virtuálních počítačích. další možností je použít pro zálohování SQL Server souborů databáze snímky souborů Azure .

• informace o sap v Oracle/Windows najdete v části zálohování/obnovení v nasazení Azure VM DBMS pro SAP.

• Další databáze najdete v doporučeních pro zálohování vašeho poskytovatele databáze. pokud databáze podporuje službu Windows služba Stínová kopie svazku (VSS), pak zálohy konzistentní s aplikací pomocí snímků služby stínová kopie svazku (vss)

Správa identit

Použití centralizovaného systému správy identit k řízení přístupu k prostředkům na všech úrovních:

• Poskytnutí přístupu k prostředkům Azure pomocí řízení přístupu na základě role Azure (RBAC).

• udělte přístup k virtuálním počítačům Azure pomocí protokolu ldap (Lightweight Directory access Protocol), Azure Active Directory, Kerberos nebo jiného systému.

Podporuje přístup v rámci samotných aplikací pomocí služeb, které poskytuje SAP. Nebo použijte OAuth 2,0 a Azure Active Directory.

Monitorování

Azure monitor poskytuje propracované nástroje pro shromažďování a analýzu telemetrie. Tyto nástroje vám pomůžou maximalizovat výkon a dostupnost svých cloudových a místních prostředků a aplikací. (Azure Monitor nyní zahrnuje Log Analytics a Application Insights.) Azure Monitor můžete použít k monitorování anomálií infrastruktury a aplikací, správcům výstrah a automatizaci reakcí na předdefinované podmínky.

Pokud chcete zajistit sledování prostředků a výkonu služby pro SAP na základě protokolu SAP, použijte Rozšířené monitorování Azure SAP . Toto rozšíření předává statistiky monitorování Azure do aplikace SAP pro zajištění monitorování operačního systému a funkcí DBA Cockpit. Ke spuštění SAP v Azure se vyžaduje rozšířené monitorování SAP. Podrobnosti najdete v tématu SAP note 2191498, "SAP v systému Linux s Azure: rozšířené monitorování". (K přístupu k poznámkám SAP potřebujete účet služby SAP Marketplace.)

Azure Monitor pro řešení SAP je budoucím směrem pro komplexní řešení monitorování pro SAP NetWeaver v Azure. Toto řešení je momentálně ve verzi Preview a je k dispozici pouze v omezené sadě oblastí. Měli byste pečlivě vyhodnotit, jestli splňuje vaše požadavky.

Azure Monitor pro řešení SAP poskytuje komplexní počáteční sadu metrik a telemetrie pro monitorování. definice metriky se ukládají jako SQL dotazy ve formátu JSON. Můžete je změnit tak, aby splňovaly vaše požadavky. Počáteční sadu metrik můžete získat na GitHub.

Důležité informace o zabezpečení

SAP má vlastní modul pro správu uživatelů (UME) k řízení přístupu a autorizací na základě role v rámci aplikace a databází SAP. Podrobné pokyny k zabezpečení aplikací najdete v tématu Průvodce zabezpečením SAP NetWeaver.

Pro další zabezpečení sítě zvažte použití hraniční sítě , která používá síťové virtuální zařízení (síťové virtuální zařízení) k vytvoření brány firewall před podsítí pro webový dispečer.

Můžete nasadit síťové virtuální zařízení pro filtrování provozu mezi virtuálními sítěmi, ale neumísťujte ho mezi aplikaci SAP a databázi. Také ověřte pravidla směrování nakonfigurovaná v podsíti a zabraňte směrování provozu do síťové virtuální zařízení s jednou instancí. To může vést k výpadkům údržby a selháním sítě nebo clusterovaných uzlů.

V případě zabezpečení infrastruktury se data zašifrují při přenosu a v klidovém stavu. Část "doporučení zabezpečení" v Azure Virtual Machines plánování a implementace pro SAP NetWeaver řeší zabezpečení sítě. Tento článek také určuje síťové porty, které je třeba otevřít na branách firewall, aby bylo možné komunikovat s aplikacemi.

k šifrování Windows disků virtuálních počítačů můžete použít Azure Disk Encryption . pomocí funkce BitLocker serveru Windows poskytuje šifrování svazku pro operační systém a datové disky. Řešení taky funguje s Azure Key Vault, které vám pomůžou řídit a spravovat šifrovací klíče a tajné klíče disku v předplatném trezoru klíčů. Neaktivní uložená data na discích virtuálních počítačů jsou v úložišti Azure zašifrovaná.

u šifrování po dobu neaktivních dat SQL Server transparentní šifrování dat (TDE) šifruje datové soubory SQL Server, Azure SQL Database a Azure SQL Data Warehouse. další informace najdete v tématu SQL Server nasazení Azure Virtual Machines DBMS pro SAP NetWeaver.

Stejně jako vždycky nezapomeňte spravovat aktualizace zabezpečení a opravy, aby se chránily vaše informační prostředky. Zvažte použití uceleného přístupu k této úloze.

Důležité informace o nákladech

K odhadu nákladů použijte cenovou kalkulačku Azure.

Další informace najdete v části věnované nákladům v tématu Dobře navržená architektura Microsoft Azure.

Pokud vaše úloha vyžaduje více paměti a méně procesorů, zvažte použití jedné z omezení velikosti virtuálních počítačů s vCPU , abyste snížili náklady na licencování softwaru, které jsou založené na vCPU.

Virtuální počítače

Tato architektura používá virtuální počítače pro aplikační vrstvu a databázovou vrstvu. vrstva sap NetWeaver využívá Windows virtuálních počítačů ke spouštění služeb a aplikací SAP. databázová vrstva spouští AnyDB jako databázi, jako je SQL Server, Oracle nebo IBM DB2. Virtuální počítače se také používají jako pole pro odkazy pro správu.

K dispozici je několik možností platby pro virtuální počítače obecně:

• Pro úlohy, které neobsahují předvídatelný čas na dokončení nebo spotřebu prostředků, zvažte možnost průběžných plateb.

• Zvažte použití Azure reservations , pokud se můžete pořídit pomocí virtuálního počítače po dobu jednoho nebo tří let. Rezervace virtuálních počítačů můžou snížit náklady ve srovnání s cenami průběžných plateb až do výše 72 procent.

Pomocí Azure Spot Virtual Machines můžete spouštět úlohy, které se dají přerušit a nevyžadují dokončení v rámci předem stanoveného časového rámce nebo smlouvy SLA. Azure nasadí virtuální počítače s přímým nasazením, když je dostupná kapacita a vyřadí je v případě, že potřebuje kapacitu zpátky. Náklady spojené s přímými virtuálními počítači jsou nižší. Zvažte možnost vystavení virtuálních počítačů pro tyto úlohy:

• Vysoce výkonné výpočetní scénáře, úlohy dávkového zpracování nebo aplikace pro vizuální vykreslování.
• Testovací prostředí, včetně úloh průběžná integrace a průběžného doručování.
• Rozsáhlé bezstavové aplikace.

Pokud potřebujete větší kontrolu nad událostmi údržby nebo izolací hardwaru, a to buď pro výkon, nebo dodržování předpisů, zvažte nasazení virtuálních počítačů na vyhrazené hostitele.

Virtuální počítače a skupiny dostupnosti

Pro všechny fondy a clustery (webový dispečer, aplikační servery SAP, centrální služby a databáze) jsou virtuální počítače seskupené do samostatných skupin dostupnosti. Skupinu dostupnosti máte k dispozici bez poplatků. Platíte jenom za každou vytvořenou instanci virtuálního počítače.

Pokud nasazujete zatížení napříč Zóny dostupnosti, skupiny dostupnosti se nevyžadují.

Azure Load Balancer

v tomto scénáři Azure Load Balancer slouží k distribuci provozu do virtuálních počítačů v podsíti aplikační vrstvy.

Účtuje se vám jenom počet nakonfigurovaných nakonfigurovaných pravidel vyrovnávání zatížení a odchozích pravidel. Pravidla příchozího překladu adres (NAT) jsou zdarma. Pokud nejsou nakonfigurovaná žádná pravidla, neúčtují se vám žádné hodinové poplatky za Standard Load Balancer.

ExpressRoute

V této architektuře je ExpressRoute síťovou službou, která slouží k vytváření privátních připojení mezi místní sítí a virtuálními sítěmi Azure.

Všechny příchozí přenosy dat jsou bezplatné. Veškerý přenos odchozích dat se účtuje na základě předem stanovené sazby. Další informace najdete v tématu ceny služby Azure ExpressRoute .

Komunity

Komunity dokážou zodpovědět dotazy a pomáhají zajistit úspěšné nasazení. Vezměte v úvahu tyto prostředky:

• Spuštění aplikací SAP na blogu platformy Microsoftu

• Podpora komunity Azure

• Community SAP

• Stack Overflow pro SAP

Související prostředky

Další informace a příklady úloh SAP, které používají některé z těchto technologií, najdete v těchto článcích:

• Plánování a implementace služby Azure Virtual Machines pro SAP NetWeaver

• Použití Azure k hostování a spouštění scénářů pro úlohy SAP

• Provozování produkčních úloh SAP pomocí Oracle Database v Azure

• Prostředí pro vývoj a testování pro úlohy SAP v Azure