Sdílet prostřednictvím

Podporované scénáře pro úlohy SAP na virtuálních počítačích Azure

  • Článek

Návrh architektury systémů SAP NetWeaver, Business one Hybris nebo S/4HANA v Azure otevírá mnoho různých příležitostí pro různé architektury a nástroje, které se dají použít k zajištění škálovatelného, efektivního a vysoce dostupného nasazení. I když závisí na používaném operačním systému nebo DBMS, existují omezení. Ne všechny scénáře, které jsou podporovány místně, se v Azure podporují stejným způsobem. Tento dokument povede k podporovaným konfiguracím bez vysoké dostupnosti a konfiguracím a architekturám s vysokou dostupností a výhradně s využitím virtuálních počítačů Azure.

Poznámka:

Služba HANA Large Instance je v režimu západu slunce a už nepřijímá nové zákazníky. Zajištění jednotek pro stávající zákazníky s velkými instancemi HANA je stále možné. Alternativy najdete v nabídkách certifikovaných virtuálních počítačů Azure HANA v hardwarovém adresáři HANA. V případě scénářů, které byly a stále podporované pro stávající zákazníky velké instance HANA s velkými instancemi HANA, najdete v článku Podporované scénáře pro velké instance HANA.

Obecná omezení platformy

Azure má kromě tzv. nativních virtuálních počítačů Azure, které se nabízejí jako služba první strany, různé platformy. Velké instance HANA, které jsou v režimu západu slunce, je jednou z těchto platforem. Azure VMware Services je další z těchto služeb první strany. SAP obecně nepodporuje služby Azure VMware pro hostování úloh SAP. Další podrobnosti o podpoře VMware na různých platformách najdete v poznámkách k podpoře SAP #2138865 – aplikace SAP v cloudu VMware: Podporované produkty a konfigurace virtuálních počítačů.

Kromě místní Active Directory nabízí Azure spravovanou službu Active Directory SaaS se službou Microsoft Entra Domain Services (tradiční AD spravovanou společností Microsoft) a ID Microsoft Entra. Komponenty SAP hostované v operačním systému Windows se často spoléhají na využití služby Windows Active Directory. V tomto případě je tradiční služba Active Directory hostovaná místně vámi nebo službou Microsoft Entra Domain Services (stále probíhá testování). Tyto komponenty SAP ale nemůžou fungovat s nativním ID Microsoft Entra. Důvodem je, že mezi službou Active Directory ve své místní podobě nebo jejím formulářem SaaS (Microsoft Entra Domain Services) a nativním ID Služby Microsoft Entra existují stále větší mezery ve funkcích. Tato závislost je důvodem, proč účty Microsoft Entra nejsou podporované pro aplikace založené na SAP NetWeaver a S/4 HANA v operačním systému Windows. V takových scénářích je potřeba použít tradiční účty Active Directory.

Služba AD Podporované aplikace založené na SAP NetWeaver a S/4 HANA v operačním systému Windows
Místní služba Windows Active Directory Podporováno
Microsoft Entra Domain Services Podporováno
Microsoft Entra ID Nepodporováno

Výše uvedené pokyny neovlivňují použití účtů Microsoft Entra pro scénáře jednotného přihlašování (SSO) s aplikacemi SAP.

Konfigurace 2 vrstvy

Konfigurace SAP 2 vrstvy se považuje za sestavenou z kombinované vrstvy SAP DBMS a aplikační vrstvy, která běží na stejném serveru nebo jednotce virtuálního počítače. Druhá úroveň se považuje za vrstvu uživatelského rozhraní. V případě 2vrstvé konfigurace sdílí dbMS a aplikační vrstva SAP prostředky virtuálního počítače Azure. V důsledku toho je potřeba nakonfigurovat různé komponenty způsobem, který tyto komponenty nekonkurují prostředkům. Musíte být také opatrní, abyste nepřepsali prostředky virtuálního počítače. Tato konfigurace neposkytuje žádnou vysokou dostupnost nad rámec smluv o úrovni služeb Azure různých součástí Azure.

Grafické znázornění takové konfigurace může vypadat takto:

Jednoduchá konfigurace 2 vrstvy

Tyto konfigurace jsou podporovány v systémech Windows, Red Hat, SUSE a Oracle Linux pro systémy DBMS systému SQL Server, Oracle, Db2, maxDB a SAP ASE pro produkční a neprodukční případy. Sap HANA jako DBMS podporuje takový scénář, jak je uvedeno v poznámce SAP #1953429. Zatím žádná distribuce Linuxu neposkytla dostatečnou dokumentaci k zajištění vysoké dostupnosti pro nastavení a provoz clusteru Pacemaker v takové konfiguraci. V důsledku toho se takový typ konfigurací podporuje v Azure jenom pro neprodukční případy, které nevyžadují cluster s podporou převzetí služeb při selhání s vysokou dostupností.

U všech kombinací operačního systému nebo DBMS podporovaných v Azure se tento typ konfigurace podporuje. Je však nutné nastavit konfiguraci DBMS a komponent SAP způsobem, který komponenty DBMS a SAP nekonkurují prostředkům paměti a procesoru a které překračují fyzické dostupné prostředky. To je potřeba provést omezením paměti, kterou může dbMS přidělit. Musíte také omezit rozšířenou paměť SAP na instance aplikací. Potřebujete také monitorovat celkovou spotřebu procesoru virtuálního počítače, abyste měli jistotu, že komponenty ne maximují prostředky procesoru.

Poznámka:

Pro produkční systémy SAP doporučujeme další konfigurace vysoké dostupnosti a případného zotavení po havárii, jak je popsáno dále v tomto dokumentu.

3vrstvé konfigurace

V takových konfiguracích oddělíte aplikační vrstvu SAP a vrstvu DBMS do různých virtuálních počítačů. Obvykle to uděláte z větších systémů a z důvodů větší flexibility prostředků aplikační vrstvy SAP. V nejjednodušším nastavení neexistuje žádná vysoká dostupnost nad rámec smluv o úrovni služeb Azure různých součástí Azure.

Grafické znázornění vypadá takto:

Diagram znázorňující jednoduchou 3vrstvou konfiguraci

Tento typ konfigurace je podporován v systémech Windows, Red Hat, SUSE a Oracle Linux pro systémy DBMS systému SQL Server, Oracle, Db2, SAP HANA, maxDB a SAP ASE pro produkční a neprodukční případy. Abychom zjednodušili zjednodušení, nerozlišili jsme mezi instancemi dialogových oken SAP Central Services a SAP ve vrstvě aplikace SAP. V této jednoduché 3vrstvé konfiguraci by pro centrální služby SAP neexistovala žádná ochrana s vysokou dostupností.

Poznámka:

Pro produkční systémy SAP doporučujeme další konfigurace vysoké dostupnosti a případného zotavení po havárii, jak je popsáno dále v tomto dokumentu.

Více instancí DBMS na virtuální počítač

V tomto typu konfigurace hostujete více instancí DBMS na virtuální počítač Azure. Motivací může být méně operačních systémů, které je potřeba udržovat a s tím snížit náklady. Další motivací je větší flexibilita a vyšší efektivita sdílením prostředků většího virtuálního počítače nebo jednotky velké instance HANA mezi několika instancemi DBMS. Zatím se tyto konfigurace zobrazovaly převážně pro neprodukční systémy.

Konfigurace podobná této konfiguraci by mohla vypadat takto:

Několik instancí DBMS v jedné jednotce

Tento typ nasazení DBMS je podporován pro:

Spuštění více databázových instancí na jednom hostiteli, musíte zajistit, aby různé instance nekokurily prostředkům a překročily tak limity fyzických prostředků virtuálního počítače. To platí zejména pro paměť, ve které potřebujete limitovat paměť, kterou může přidělit každý z instancí sdílejících virtuální počítač. To může být také pravdivé pro prostředky procesoru, které mohou různé instance databáze využívat. Všechny uvedené databázové systémy mají konfigurace, které umožňují omezit přidělení paměti a prostředky procesoru na úrovni instance. Aby bylo možné zajistit podporu takové konfigurace pro virtuální počítače Azure, očekává se, že disky nebo svazky používané pro data a soubory protokolů nebo opětovného protokolování databází spravovaných různými instancemi jsou oddělené. Jinými slovy data nebo soubory protokolů nebo opětovného protokolování databází spravovaných jinou instancí DBMS nemají sdílet stejné disky nebo svazky.

Poznámka:

Pro produkční systémy SAP doporučujeme další konfigurace vysoké dostupnosti a případného zotavení po havárii, jak je popsáno dále v tomto dokumentu. Virtuální počítače s více instancemi DBMS nejsou podporovány s konfiguracemi vysoké dostupnosti popsanými dále v tomto dokumentu.

Více instancí dialogového okna SAP na jednom virtuálním počítači

V mnoha případech se na holé servery nebo dokonce na virtuálních počítačích běžících v privátních cloudech nasadilo několik instancí dialogových oken. Důvodem takových konfigurací bylo přizpůsobení určitých instancí dialogových oken SAP určitým úlohám, obchodním funkcím nebo typům úloh. Důvodem, proč tyto instance izolovat do samostatných virtuálních počítačů, bylo úsilí o údržbu a provoz operačního systému. Nebo v mnoha případech náklady v případě, že hostitel nebo operátor virtuálního počítače žádá o měsíční poplatek za provozovaný a spravovaný virtuální počítač. V Azure je scénář hostování několika instancí dialogových oken SAP v rámci jednoho virtuálního počítače podporovaný pro produkční a neprodukční účely v operačních systémech Windows, Red Hat, SUSE a Oracle Linux. Parametr jádra SAP PHYS_MEMSIZE dostupný v jádrech Windows a moderních linuxových jádrech by se měl nastavit, pokud na jednom virtuálním počítači běží více instancí aplikačního serveru SAP. Doporučuje se také omezit rozšíření rozšířené paměti SAP v operačních systémech, jako je Windows, kde se implementuje automatický růst rozšířené paměti SAP. To lze provést pomocí parametru em/max_size_MBprofilu SAP .

Ve 3vrstvé konfiguraci, kde se v rámci virtuálních počítačů Azure spouští více instancí dialogových oken SAP, může vypadat takto:

Diagram znázorňující 3vrstvou konfiguraci, ve které se v rámci virtuálních počítačů Azure spouští více instancí dialogových oken SAP

Abychom zjednodušili zjednodušení, nerozlišili jsme mezi instancemi dialogových oken SAP Central Services a SAP ve vrstvě aplikace SAP. V této jednoduché 3vrstvé konfiguraci by pro centrální služby SAP neexistovala žádná ochrana s vysokou dostupností. U produkčních systémů se nedoporučuje nechat službu SAP Central Services nechráněnou. Podrobnosti o takzvaných konfiguracích s více identifikátory SID týkající se instancí SAP Central Instance a vysoké dostupnosti těchto konfigurací s více identifikátory SID najdete v dalších částech tohoto dokumentu.

Ochrana s vysokou dostupností pro vrstvu SAP DBMS

Při nasazování produkčních systémů SAP je potřeba zvážit aktivní pohotovostní typ konfigurací s vysokou dostupností. Zvlášť u SAP HANA, kdy je potřeba data načíst do paměti, aby bylo možné získat úplný výkon a škálovatelnost zpět, není opravy služeb Azure ideální mírou pro vysokou dostupnost.

Microsoft obecně podporuje pouze konfigurace s vysokou dostupností a softwarové balíčky popsané ve scénářích úloh SAP. Stejný příkaz si můžete přečíst v poznámce SAP #1928533. Microsoft nebude poskytovat podporu pro další softwarové architektury třetích stran s vysokou dostupností, které Microsoft nedokumentuje s úlohou SAP. Vtakovýchch Výjimky budou zmíněny v tomto článku.

Microsoft obecně podporuje omezenou sadu konfigurací vysoké dostupnosti na virtuálních počítačích Azure nebo jednotkách HANA Large Instances.

Pro virtuální počítače Azure se na úrovni DBMS podporují následující konfigurace vysoké dostupnosti:

Důležité

Pro žádný z výše popsaných scénářů podporujeme konfigurace více instancí DBMS na jednom virtuálním počítači. Znamená to, že v každém z těchto případů lze na virtuální počítač nasadit pouze jednu instanci databáze a chránit ji pomocí popsaných metod vysoké dostupnosti. Ochrana více instancí DBMS v rámci stejného clusteru s podporou převzetí služeb při selhání systému Windows nebo Pacemaker není v tuto chvíli podporována. Oracle Data Guard je také podporován pouze pro jednotlivé instance pro jednotlivé případy nasazení virtuálních počítačů.

Různé databázové systémy umožňují hostování více databází v jedné instanci DBMS. Stejně jako u SAP HANA je možné hostovat více databází v několika kontejnerech databáze (MDC). V případech, kdy tyto konfigurace s více databázemi pracují v rámci jednoho prostředku clusteru s podporou převzetí služeb při selhání, jsou tyto konfigurace podporované. Konfigurace, které nejsou podporované, jsou případy, kdy se vyžaduje více prostředků clusteru. Pokud jde o konfigurace, ve kterých byste definovali více skupin dostupnosti SQL Serveru, v rámci jedné instance SQL Serveru.

Konfigurace vysoké dostupnosti DBMS

Komponenty, jako je Nástroj pro vyrovnávání zatížení Azure, můžou nebo nemusí být součástí architektury řešení závislé na dbMS nebo operačních systémech.

Konkrétně pro maxDB se konfigurace úložiště musí lišit. U maxDB musí být soubory dat a protokolů umístěné ve sdíleném úložišti pro konfigurace s vysokou dostupností. Pro zajištění vysoké dostupnosti se podporuje pouze pro maxDB, sdílené úložiště. Pro všechny ostatní dbMS jsou samostatné zásobníky úložiště na uzel jedinou podporovanou konfigurací disků.

Existují i další architektury s vysokou dostupností, o kterých se také ví, že běží v Microsoft Azure. Microsoft však tyto architektury neotestoval. Pokud chcete vytvořit konfiguraci vysoké dostupnosti s těmito architekturami, musíte spolupracovat s poskytovatelem tohoto softwaru, aby:

  • Vývoj architektury nasazení
  • Nasazení architektury
  • Podpora architektury

Důležité

Microsoft Azure Marketplace nabízí celou řadu měkkých zařízení, která poskytují řešení úložiště nad nativním úložištěm Azure. Tato měkká zařízení je možné použít k vytvoření sdílených složek NFS, které by teoreticky mohly být použity v nasazeních se škálováním na více systémů SAP HANA, kde je vyžadován pohotovostní uzel. Vzhledem k různým důvodům není žádná z těchto zařízení v úložišti podporovaná pro žádná z nasazení DBMS od Microsoftu a SAP v Azure. Nasazení DBMS ve sdílených složkách SMB se v tomto okamžiku vůbec nepodporuje. Nasazení DBMS ve sdílených složkách NFS je omezená na sdílené složky NFS 4.1 ve službě Azure NetApp Files.

Vysoká dostupnost pro centrální službu SAP

SAP Central Services je druhým kritickým bodem selhání vaší konfigurace SAP. V důsledku toho byste tyto procesy centrálních služeb museli chránit také. Nabídka podporovaná a zdokumentovaná pro úlohy SAP čte například:

U uvedených řešení potřebujete vztah podpory se siOSem, abyste produkt podporovali Datakeeper a aby se s SIOSem zapojili přímo v případě, že dojde k problémům. V závislosti na způsobu licencování operačního systému Windows, Red Hat a/nebo SUSE můžete také potřebovat smlouvu o podpoře u svého poskytovatele operačního systému, aby měla plnou podporu uvedených konfigurací s vysokou dostupností.

Konfigurace se může zobrazit i takto:

Konfigurace DBMS a ASCS HA

Na pravé straně grafiky se zobrazí vysoce dostupné služby SAP Central Services. Kromě toho, že služby SAP Central jsou chráněné architekturou clusteru s podporou převzetí služeb při selhání, která může převzít služby při selhání ve scénářích selhání. Pro vysoce dostupnou sdílenou složku NFS nebo SMB nebo sdílený disk s Windows je potřeba zajistit dostupnost sapmntu a globálního adresáře přenosu nezávisle na existenci jednoho virtuálního počítače. Další některá řešení, jako je clusterový server s podporou převzetí služeb při selhání s Windows a Pacemaker, vyžadují nástroj pro vyrovnávání zatížení Azure, který bude směrovat nebo přesměrovat provoz na uzel, který je v pořádku.

V zobrazeném seznamu se o operačním systému Oracle Linux nezmíní. Oracle Linux nepodporuje Pacemaker jako architekturu clusteru. Pokud chcete nasadit systém SAP v Oracle Linuxu a potřebujete architekturu s vysokou dostupností pro Oracle Linux, musíte spolupracovat s dodavateli třetích stran. Jedním z dodavatelů je SIOS se svou sadou ochrany pro Linux, kterou podporuje SAP v Azure. Další informace najdete v poznámkě SAP #1662610 – podrobnosti podpory pro SIOS Protection Suite pro Linux .

Podporované úložiště ve scénářích SAP Central Services uvedených výše

Vzhledem k tomu, že pouze podmnožina typů úložiště Azure poskytuje vysoce dostupné sdílené složky NFS nebo SMB, které jsou kvalitní pro použití v našich scénářích clusteru SAP Central Services, seznam podporovaných typů úložiště

  • Server clusteru s windows s podporou převzetí služeb při selhání se souborovým serverem se škálováním na více systémů windows je možné nasadit na všechny nativní typy úložiště Azure s výjimkou Azure NetApp Files. Doporučujeme ale používat Premium Storage kvůli špičkovým smlouvám o úrovni služeb v propustnosti a IOPS.
  • Server clusteru s windows s podporou převzetí služeb při selhání s protokolem SMB v Azure NetApp Files se podporuje ve službě Azure NetApp Files. Sdílené složky SMB hostované ve službách Azure Premium File jsou podporované i v tomto scénáři. Azure Standard Files se nepodporuje.
  • Server clusteru s windows s podporou převzetí služeb při selhání se sdíleným diskem založeným na SYSTÉMU SIOS Datakeeper je možné nasadit ve všech nativních typech úložiště Azure s výjimkou Azure NetApp Files. Doporučujeme ale používat Premium Storage kvůli špičkovým smlouvám o úrovni služeb v propustnosti a IOPS.
  • Podporuje se SUSE nebo Red Hat Pacemaker využívající sdílené složky NFS ve službě Azure NetApp Files.
  • SUSE nebo Red Hat Pacemaker s využitím sdílených složek NFS ve službě Azure Premium Files s podporou LRS nebo ZRS Azure Standard Files se nepodporuje.
  • SUSE Pacemaker s využitím drdb konfigurace mezi dvěma virtuálními počítači se podporuje pomocí nativních typů úložiště Azure s výjimkou Azure NetApp Files. Doporučujeme ale používat některou ze služeb první strany se službou Azure Premium Files nebo Azure NetApp Files.
  • Red Hat Pacemaker, který používá glusterfs k poskytování sdílené složky NFS, se podporuje pomocí nativních typů úložiště Azure s výjimkou Azure NetApp Files. Doporučujeme ale používat některou ze služeb první strany se službou Azure Premium Files nebo Azure NetApp Files.

Důležité

Microsoft Azure Marketplace nabízí celou řadu měkkých zařízení, která poskytují řešení úložiště nad nativním úložištěm Azure. Tato zařízení úložiště je možné použít k vytvoření sdílených složek NFS nebo SMB, které by teoreticky mohly být použity i v clusterovaných clusterech SAP Central Services s podporou převzetí služeb při selhání. Microsoft tato řešení přímo nepodporuje pro úlohy SAP. Pokud se rozhodnete takové řešení použít k vytvoření sdílené složky NFS nebo SMB, musí podpora konfigurace centrální služby SAP poskytovat třetí strana, která vlastní software v softwarovém zařízení úložiště.

Clustery s podporou převzetí služeb při selhání s více SID SAP Central Services

Aby se snížil počet virtuálních počítačů, které jsou potřeba ve velkých prostředích SAP, sap umožňuje spouštět instance SAP Central Services několika různých systémů SAP v konfiguraci clusteru s podporou převzetí služeb při selhání. Představte si případy, kdy máte 30 nebo více produkčních systémů NetWeaver nebo S/4HANA. Bez clusteringu s více identifikátory SID by tyto konfigurace vyžadovaly 60 nebo více virtuálních počítačů v 30 nebo více konfiguracích clusterů s podporou převzetí služeb při selhání systému Windows nebo Pacemaker. Nasazení několika centrálních služeb SAP na dva uzly v konfiguraci clusteru s podporou převzetí služeb při selhání může výrazně snížit počet virtuálních počítačů. Nasazení několika instancí služeb SAP Central v konfiguraci clusteru s jedním dvěma uzly má ale také určité nevýhody. Problémy související s jedním virtuálním počítačem v konfiguraci clusteru platí pro více systémů SAP. Údržba hostovaného operačního systému spuštěného v konfiguraci clusteru vyžaduje větší koordinaci, protože ovlivňuje více produkčních systémů SAP. Nástroje, jako je SAP LaMa, nepodporují clustering s více identifikátory SID v procesu klonování systému.

V Azure se pro operační systém Windows s ENSA1 a ENSA2 podporuje konfigurace clusteru s více identifikátory SID. Doporučení není kombinovat starší architekturu služby Replikace enqueue (ENSA1) s novou architekturou (ENSA2) v jednom clusteru s více identifikátory SID. Podrobnosti o takové architektuře jsou popsané v článcích

Pro SUSE se podporuje také cluster s více sid založený na Pacemakeru. Zatím je konfigurace podporovaná pro:

  • Maximálně pět instancí SAP ASCS/SCS
  • Stará architektura serveru replikace fronty (ENSA1)
  • Konfigurace clusteru Pacemaker se dvěma uzly

Konfigurace je zdokumentovaná ve vysoké dostupnosti pro SAP NetWeaver na virtuálních počítačích Azure na SUSE Linux Enterprise Serveru pro aplikace SAP s více identifikátory SID.

Cluster s více identifikátory SID se schématem serveru replikace enqueue vypadá takto:

Diagram znázorňující cluster s více identifikátory SID se serverem replikace Enqueue

Scénáře horizontálního navýšení kapacity SAP HANA

Scénáře škálování SAP HANA na více instancí se podporují pro podmnožinu certifikovaných virtuálních počítačů Azure HANA, jak je uvedeno v hardwarovém adresáři SAP HANA. Všechny virtuální počítače označené jako Ano ve sloupci Clustering je možné použít pro horizontální navýšení kapacity OLAP nebo S/4HANA. Konfigurace bez pohotovostního režimu jsou podporovány s typy azure Storage:

  • Azure Premium Storage v1, včetně akcelerátoru zápisu Azure pro svazek /hana/log
  • Azure Premium Storage v2
  • Ultra disk
  • Azure NetApp Files

Konfigurace horizontálního navýšení kapacity SAP HANA pro OLAP nebo S/4HANA s pohotovostními uzly se podporují výhradně se sdíleným systémem souborů NFS hostovaným ve službě Azure NetApp Files.

Další informace o přesných konfiguracích úložiště s pohotovostním uzlem nebo bez uzlu najdete v článcích:

Scénář zotavení po havárii

Existují různé scénáře zotavení po havárii, které jsou podporované. Architektury zotavení po havárii definujeme jako architektury, které by měly kompenzovat kompletní oblast Azure, která se v mřížce odrazí. To znamená, že pro spuštění prostředí SAP potřebujeme cíl zotavení po havárii do jiné oblasti Azure. Metody a konfigurace oddělujeme ve vrstvě DBMS a jiné vrstvě než DBMS.

Vrstva DBMS

Pro vrstvu DBMS se podporují konfigurace využívající nativní mechanismy replikace DBMS, jako je AlwaysOn, Oracle Data Guard, Db2 HADR, SAP ASE Always-On nebo Replikace systému HANA. Je povinné, aby stream replikace v takových případech byl asynchronní, nikoli synchronní, jako v typických scénářích s vysokou dostupností, které jsou nasazené v jedné oblasti Azure. Typický příklad takové podporované konfigurace zotavení po havárii DBMS je popsaný v článku Dostupnost SAP HANA napříč oblastmi Azure. Druhý obrázek v této části popisuje scénář s HANA jako příklad. V takovém scénáři je možné nasadit všechny hlavní databáze podporované pro aplikace SAP.

Podporuje se použití menšího virtuálního počítače jako cílové instance v oblasti zotavení po havárii, protože tento virtuální počítač nezíská plný provoz úloh. Při tom je potřeba mít na paměti následující aspekty:

  • Menší typy virtuálních počítačů neumožňují, aby se připojilo více disků než menších virtuálních počítačů.
  • Menší virtuální počítače mají menší propustnost sítě a úložiště.
  • Změna velikosti napříč rodinami virtuálních počítačů může být problém, když se různé virtuální počítače shromažďují v jedné skupině dostupnosti Azure nebo kdy by se změna velikosti měla provést mezi rodinou M-Series a řadou virtuálních počítačů Mv2.
  • Využití procesoru a paměti pro instanci databáze, která dokáže přijímat stream změn s minimálním zpožděním a dostatečným počtem prostředků procesoru a paměti pro použití těchto změn s minimálním zpožděním na data

Další podrobnosti o omezeních různých velikostí virtuálních počítačů najdete na stránce velikosti virtuálních počítačů .

Další podporovanou metodou nasazení cíle zotavení po havárii je mít druhou instanci DBMS nainstalovanou na virtuálním počítači, na kterém běží neprodukční instance DBMS neprodukční instance SAP. To může být trochu náročnější, protože potřebujete zjistit, co se týče paměti, prostředků procesoru, šířky pásma sítě a šířky pásma úložiště pro konkrétní cílové instance, které by měly fungovat jako hlavní instance ve scénáři zotavení po havárii. Zejména v HANA důrazně doporučujeme nakonfigurovat instanci, která funguje jako cíl zotavení po havárii na sdíleném hostiteli, aby se data nenačetla do cílové instance zotavení po havárii.

Poznámka:

Použití služby Azure Site Recovery nebylo testováno pro nasazení DBMS v rámci úlohy SAP. V tomto okamžiku se proto nepodporuje pro vrstvu DBMS systémů SAP. Jiné metody replikace od Microsoftu a SAP, které tu nejsou uvedené, nejsou podporované. Použití softwaru třetí strany pro replikaci vrstvy DBMS systémů SAP mezi různými oblastmi Azure musí být podporováno dodavatelem softwaru a nebude podporováno prostřednictvím kanálů podpory Microsoftu a SAP.

Vrstva bez DBMS

V případě aplikační vrstvy SAP a případných sdílených složek nebo umístění úložiště, které jsou potřeba, používají zákazníci tyto dva hlavní scénáře:

  • Cíle zotavení po havárii v druhé oblasti Azure se nepoužívají pro produkční ani neprodukční účely. V tomto scénáři se virtuální počítače, které fungují jako cíl zotavení po havárii, ideálně nenasazují a image a změny imagí produkční aplikační vrstvy SAP se replikují do oblasti zotavení po havárii. Funkce, které můžou takovou úlohu provést, je Azure Site Recovery. Azure Site Recovery podporuje podobný scénář replikace z Azure do Azure.
  • Cíle zotavení po havárii jsou virtuální počítače, které se ve skutečnosti používají neprodukčními systémy. Celá krajina SAP je rozložená do dvou různých oblastí Azure s produkčními systémy obvykle v jedné oblasti a neprodukční systémy v jiné oblasti. V mnoha zákaznických nasazeních má zákazník neprodukční systém, který je ekvivalentní produkčnímu systému. Zákazník má předinstalované produkční instance aplikací v neprodukčních systémech aplikační vrstvy. V případě převzetí služeb při selhání se neprodukční instance vypnou, virtuální názvy produkčních virtuálních počítačů se přesunou do neprodukčních virtuálních počítačů (po přiřazení nových IP adres v DNS) a předinstalované produkční instance se spustí.

Clustery SAP Central Services

Clustery SAP Central Services, které používají sdílené disky (Windows), sdílené složky SMB (Windows) nebo sdílené složky NFS, jsou trochu obtížnější replikovat. Na straně Windows je možná řešení replikace úložiště systému Windows. V Linuxu je rsync realizovatelné řešení. Replikace služby Azure NetApp Files mezi oblastmi je také realizovatelné řešení.

Nepodporovaný scénář

Existuje seznam scénářů, které nejsou podporované pro úlohy SAP v architekturách Azure. Nepodporované znamená, že SAP a Microsoft nemůžou poskytovat podporu těchto konfigurací a musí se odložit na případnou zapojenou třetí stranu, která poskytla software k vytvoření takových architektur. Dvě z těchto kategorií:

  • Zařízení s měkkým úložištěm: Na trhu jsou různé úložné měkké spotřebiče. Někteří dodavatelé nabízejí vlastní dokumentaci, jak používat svá softwarová zařízení úložiště v Azure související se softwarem SAP. Podporu konfigurací nebo nasazení, která zahrnují taková zařízení úložiště, musí být poskytována dodavatelem úložného soft zařízení. Tento fakt se také projevuje v poznámkě k podpoře SAP #2015553
  • Architektury s vysokou dostupností: Pro úlohy SAP v Azure se podporují jenom architektury Pacemaker a cluster s podporou převzetí služeb při selhání Windows Serveru. Jak už jsme zmínili dříve, řešení SIOS Datakeeper je popsáno a zdokumentované Microsoftem. Komponenty SIOS však musí být podporovány prostřednictvím SYSTÉMU SIOS Datakeeper jako dodavatel, který tyto komponenty poskytuje. SAP také uvádí další certifikované architektury vysoké dostupnosti v různých poznámkách k SAP. Některé z nich byly certifikovány také dodavatelem třetích stran pro Azure. Nicméně, podpora konfigurací používajících tyto produkty musí být poskytována dodavatelem produktu. Různí dodavatelé mají různé integrace do procesů podpory SAP. Než se rozhodnete produkt používat s konfiguracemi SAP nasazenými v Azure, měli byste objasnit, jaký proces podpory je pro konkrétního dodavatele nejvhodnější.
  • Sdílené diskové clustery, ve kterých se soubory databáze nacházejí na sdílených discích, se nepodporují s výjimkou maxDB. U všech ostatních databází je podporovaným řešením mít samostatná umístění úložiště místo sdílené složky SMB nebo NFS nebo sdíleného disku pro konfiguraci scénářů s vysokou dostupností.

Další scénáře, které nejsou podporované, jsou například:

  • Scénáře nasazení, které představují větší latenci sítě mezi aplikační vrstvou SAP a vrstvou SAP DBMS, jako je NetWeaver, S/4HANA a např. Hybris To zahrnuje:
    • Nasazení jedné z úrovní v místním prostředí, zatímco druhá vrstva je nasazená v Azure
    • Nasazení aplikační vrstvy SAP systému v jiné oblasti Azure, než je úroveň DBMS
    • Nasazení jedné vrstvy v datacentrech, která jsou společně umístěná do Azure a druhé vrstvy v Azure, s výjimkou případů, kdy takový model architektury poskytuje nativní služba Azure
    • Nasazení síťových virtuálních zařízení mezi aplikační vrstvou SAP a vrstvou DBMS
    • Použití úložiště hostovaného ve společném umístění datacentra do datacentra Azure pro vrstvu SAP DBMS nebo globální adresář přenosu SAP
    • Nasazení těchto dvou vrstev se dvěma různými dodavateli cloudu Například nasazení vrstvy DBMS v infrastruktuře Oracle Cloud Infrastructure a aplikační vrstvě v Azure
  • Konfigurace clusteru Pacemaker pro více instancí HANA
  • Konfigurace clusteru Windows se sdílenými disky prostřednictvím SOFS nebo SMB v ANF pro databáze SAP podporované ve Windows. Místo toho doporučujeme používat nativní replikaci vysoké dostupnosti konkrétních databází a používat samostatné zásobníky úložiště.
  • Nasazení databází SAP podporovaných v Linuxu s databázovými soubory umístěnými ve sdílených složkách NFS nad ANF s výjimkou SAP HANA, Oracle v Oracle Linuxu a Db2 v Suse a Red Hatu
  • Nasazení Oracle DBMS na jakýkoli jiný hostovaný operační systém než Windows a Oracle Linux. Viz také poznámku k podpoře SAP #2039619

Scénáře, které jsme neprotestovali, a proto nemáme zkušenosti se seznamem, například:

  • Azure Site Recovery replikuje virtuální počítače vrstvy DBMS. Proto doporučujeme pro potenciální konfiguraci zotavení po havárii použít nativní funkce asynchronní replikace databáze.

Další kroky

Přečtěte si další kroky v plánování a implementaci služby Azure Virtual Machines pro SAP NetWeaver.