Azure Virtual Machines plánování a implementace pro SAP NetWeaver

Microsoft Azure umožňuje společnostem získat výpočetní prostředky a prostředky úložiště v minimálním čase bez zdlouhavých cyklů nákupu. Služba Azure Virtual Machine umožňuje společnostem nasazovat klasické aplikace, jako jsou aplikace založené na SAP NetWeaveru, do Azure a rozšiřovat jejich spolehlivost a dostupnost, aniž by v místním prostředí bylo k dispozici další prostředky. Azure Virtual Machine Services také podporuje připojení mezi místními sítěmi, které společnostem umožňuje aktivně integrovat Azure Virtual Machines do místních domén, privátních cloudů a prostředí systému SAP. Tento dokument white paper popisuje základy virtuálního počítače Microsoft Azure a obsahuje průvodce aspekty plánování a implementace pro instalace SAP NetWeaver v Azure. Jako takový by měl být dokument, který si můžete přečíst před zahájením skutečných nasazení SAP NetWeaveru v Azure. Dokument doplňuje dokumentaci k instalaci SAP a poznámky SAP, které představují primární prostředky pro instalace a nasazení softwaru SAP na dané platformě.

Souhrn

Cloud computing je široce používaný pojem, který v IT odvětví získává čím víc a více jeho důležitosti, od malých společností až po velké a mezinárodní společnosti.

Microsoft Azure je Cloud Services platforma od Microsoftu, která nabízí široké spektrum nových možností. Zákazníci jsou teď schopní rychle zřovat a zřídit aplikace jako službu v cloudu, takže nejsou omezeni technickými omezeními nebo omezeními rozpočtů. Místo toho, aby investovali čas a rozpočet do hardwarové infrastruktury, se společnosti mohou zaměřit na aplikace, obchodní procesy a její výhody pro zákazníky a uživatele.

Pomocí služeb Microsoft Azure pro virtuální počítače nabízí společnost Microsoft komplexní platformu infrastruktury jako služby (IaaS). Služba Azure Virtual Machines teď v rámci IaaS podporuje aplikace využívající SAP NetWeaver. Tento dokument white paper popisuje, jak naplánovat a implementovat aplikace založené na SAP NetWeaver Microsoft Azure jako platformu podle výběru.

Dokument se zaměřuje na dva hlavní aspekty:

• První část popisuje dva podporované vzory nasazení pro aplikace založené na SAP NetWeaveru v Azure. Popisuje také obecné zpracování Azure s vědomím nasazení SAP.
• Druhá část podrobně popisuje implementaci různých scénářů popsaných v první části.

Další zdroje najdete v kapitole Zdroje informací v tomto dokumentu.

Definice předem

V celém dokumentu používáme následující termíny:

• IaaS: Infrastruktura jako služba
• PaaS: Platforma jako služba
• SaaS: Software jako služba
• Součást SAP: Jednotlivá aplikace SAP, jako je ECC, BW, Solution Manager nebo S/4HANA. Komponenty SAP mohou být založené na tradičních technologiích jazyk ABAP nebo Javě nebo na jiných aplikacích než NetWeaver, jako jsou obchodní objekty.
• Prostředí SAP: Jedna nebo více komponent SAP logicky seskupených pro provádění obchodních funkcí, jako je vývoj, qas, trénování, dr. nebo produkce.
• Sap Landscape (Prostředí SAP): Tento termín se vztahuje k celým prostředkům SAP v it oblasti zákazníka. Prostředí SAP zahrnuje všechna produkční i neprodukní prostředí.
• SYSTÉM SAP: Kombinace vrstvy DBMS a aplikační vrstvy, jako je například vývojový systém SAP ERP, SAP BW testovací systém, produkční systém SAP CRM atd. V nasazeních Azure není podporováno rozdělení těchto dvou vrstev mezi místní vrstvu a Azure. Znamená, že systém SAP je buď nasazený místně, nebo je nasazený v Azure. Různé systémy prostředí SAP ale můžete nasadit do Azure nebo místně. Můžete například nasadit vývojové a testovací systémy SAP CRM v Azure, ale produkční systém SAP CRM místně.
• Multi-premises nebo hybrid: Popisuje scénář, kdy se virtuální počítače nasadí do předplatného Azure, které má připojení site-to-site, multi-site nebo ExpressRoute mezi místními datacently a Azure. V běžné dokumentaci k Azure se tyto druhy nasazení popisují také jako scénáře pro různé místní prostředí nebo hybridní scénáře. Důvodem připojení je rozšíření místních domén, místní Active Directory/OpenLDAP a místního DNS do Azure. Místní prostředí se rozšiřuje na prostředky Azure předplatného. S tímto rozšířením mohou být virtuální počítače součástí místní domény. Uživatelé domény místní domény mají přístup k serverům a mohou na těchto virtuálních počítači (jako jsou služby DBMS) spouštět služby. Komunikace a překlad názvů mezi místními virtuálními počítači a virtuálními počítači nasazených v Azure je možný. Jedná se o nejběžnější a téměř exkluzivní případ nasazení prostředků SAP do Azure. Další informace najdete v tomto článku a v tomto článku.
• Rozšíření pro monitorování Azure, rozšířené monitorování a rozšíření Azure pro SAP: Popište jednu a stejnou položku. Popisuje rozšíření virtuálního počítače, které musíte nasadit, abyste agentovi hostitele SAP poskytovali základní data o infrastruktuře Azure. Sap v poznámkách k SAPu se může označovat jako Rozšíření monitorování nebo Rozšířené monitorování. V Azure na něj odkazujeme jako na rozšíření Azure pro SAP.

Zdroje informací

Vstupní bod dokumentace k úlohám SAP v Azure najdete v článku Začínáme s SAP v Azure počítači. Od tohoto vstupního bodu najdete mnoho článků, které se vztahují k tématům:

• SAP NetWeaver a Business One v Azure
• Průvodci SAP DBMS pro různé systémy DBMS v Azure
• Vysoká dostupnost a zotavení po havárii pro úlohy SAP v Azure
• Konkrétní pokyny pro spouštění SAP HANA v Azure
• Pokyny týkající se velkých instancí Azure HANA pro SAP HANA DBMS

Následující poznámky SAP se vztahují k tématu SAP v Azure:

Přečtěte si také wikiweb SCN, který obsahuje všechny poznámky SAP pro Linux.

Obecná výchozí omezení a maximální omezení předplatných Azure najdete v tomto článku.

Možné scénáře

SAP se často zobrazuje jako jedna z nejdůležitějších aplikací v podnicích. Architektura a operace těchto aplikací jsou většinou složité a je důležité zajistit, aby byly splněny požadavky na dostupnost a výkon.

Proto podniky musí pečlivě zvážit, který poskytovatel cloudu si zvolí pro provozování těchto důležitých podnikových procesů. Azure je ideální veřejná cloudová platforma pro důležité podnikové aplikace a obchodní procesy SAP. Téměř všechny stávající systémy SAP NetWeaver a S/4HANA je možné v Azure ještě dnes hostovat v rámci celé řady infrastruktury Azure. Azure poskytuje virtuální počítače s mnoha terabajty paměti a více než 200 procesorů. Mimo to, že Azure nabízí velké instance Hana, což umožňuje nasazení Hana s možností horizontálního navýšení kapacity až na 24 tb a SAP HANA nasazení se škálováním na více instancí až na 120 TB. Jedna může dnes zastavovat, že téměř všechny místní scénáře SAP lze spustit také v Azure.

Hrubý popis scénářů a některých nepodporovaných scénářů najdete v tématu věnovaném scénářům dokumentace SAP na virtuálních počítačích Azure, které se podporují.

Tyto scénáře a některé z podmínek, které se jmenovaly jako nepodporované, najdete v odkazované dokumentaci v průběhu plánování a vývoje vaší architektury, kterou chcete nasadit do Azure.

Celkový společný vzor nasazení je scénář pro více míst, jako je zobrazený

Důvodem pro mnoho zákazníků, jak použít model nasazení mezi různými místy, je to, že je nejdůležitější pro všechny aplikace, aby se do Azure rozšířily místně do Azure pomocí Azure ExpressRoute a považovaly Azure za virtuální datové centrum. Vzhledem k přesunu dalších prostředků do Azure se zvýší infrastruktura nasazená v Azure a síťová infrastruktura a místní prostředky se tím sníží. Vše transparentní pro uživatele a aplikace.

Aby bylo možné úspěšně nasadit systémy SAP do Azure IaaS nebo IaaS, je důležité porozumět významným rozdílům mezi nabídkami tradičních outsourcingů nebo hostitelů a IaaS nabídkami. Vzhledem k tomu, že tradiční hostitel nebo modul pro odsourceky připraví infrastrukturu (síť, úložiště a typ serveru) na zatížení, které chce zákazník hostovat, je místo toho úkolem zákazníka nebo partnera, aby charakterizoval zatížení a zvolili správné komponenty Azure pro nasazení virtuálních počítačů, úložišť a sítě pro nasazení IaaS.

Aby bylo možné shromažďovat data pro plánování nasazení do Azure, je důležité:

• Vyhodnotit, které produkty SAP se podporují na virtuálních počítačích Azure
• Vyhodnoťte, jaké konkrétní verze operačních systémů jsou pro tyto produkty SAP podporované konkrétními virtuálními počítači Azure
• Vyhodnocení podporovaných verzí systému DBMS pro produkty SAP s konkrétními virtuálními počítači Azure
• Vyhodnoťte, jestli některé z požadovaných verzí operačního systému/DBMS vyžadují, abyste mohli provést podporu pro vydání SAP, upgrade balíčku a upgrady jádra, aby se získala podporovaná konfigurace.
• Vyhodnoťte, jestli potřebujete přesunout do různých operačních systémů, abyste mohli nasadit v Azure.

Podrobnosti o podporovaných součástech SAP v Azure, podporované jednotky infrastruktury Azure a související verze operačních systémů a vydání DBMS jsou vysvětleny v článku o tom, jaký software SAP je podporován pro nasazení Azure. Výsledky získané při vyhodnocování platných vydání SAP, operačních systémů a systémů DBMS mají velký dopad na úsilí o přesun systémů SAP do Azure. Výsledkem tohoto vyhodnocení je definování toho, jestli v případech, kdy je potřeba upgradované verze SAP nebo změny operačních systémů, mohlo dojít k výraznému přípravnému úsilí.

Oblasti Azure

Služby Azure od Microsoftu se shromažďují v oblastech Azure. Oblast Azure je jedna nebo kolekce z datových center, která obsahují hardware a infrastrukturu, která běží a hostuje různé služby Azure. Tato infrastruktura zahrnuje velký počet uzlů, které fungují jako výpočetní uzly nebo uzly úložiště, nebo spouštějí síťové funkce.

Seznam různých oblastí Azure najdete v tématu geografické oblasti Azure. Ne všechny oblasti Azure nabízejí stejné služby. Závisí na produktu SAP, který chcete spustit, a na operačním systému a DBMS, které se k němu vztahují. můžete tak skončit v situaci, kdy určitá oblast nenabízí požadované typy virtuálních počítačů. To platí zejména pro spuštěné SAP HANA, kde obvykle potřebujete virtuální počítače řady virtuálních počítačů M/Mv2. Tyto rodiny virtuálních počítačů se nasazují jenom v podmnožině oblastí. Můžete zjistit, co přesně přesný virtuální počítač, typy, typy úložiště Azure nebo jiné služby Azure jsou k dispozici v rámci kterých oblastí s technickou dostupností produktů v jednotlivýchoblastech. Při zahájení plánování a splnění určitých oblastí jako primární oblasti a nakonec sekundární oblasti je třeba nejprve prozkoumat, zda jsou v těchto oblastech k dispozici nezbytné služby.

Zóny dostupnosti

Některé oblasti Azure implementovaly koncept nazvaný Zóny dostupnosti. Zóny dostupnosti jsou fyzicky samostatná umístění v oblasti Azure. Každou zónu dostupnosti tvoří jedno nebo několik datových center vybavených nezávislým napájením, chlazením a sítí. Například nasazení dvou virtuálních počítačů do dvou Zóny dostupnosti Azure a implementace architektury s vysokou dostupností pro váš systém SAP DBMS nebo centrální služby SAP vám nabízí nejlepší smlouvu SLA v Azure. Pro tuto konkrétní smlouvu SLA pro virtuální počítač v Azure se podívejte na nejnovější verzi SLA virtuálního počítače. Vzhledem k tomu, že se oblasti Azure vyvinuly a v posledních letech rychle rozšířily, topologie oblastí Azure, počet fyzických Datacenter, vzdálenost mezi těmito datacentry a vzdálenost mezi Zóny dostupnosti Azure se může lišit. A s tím, že latence sítě.

Princip Zóny dostupnosti se nevztahuje na službu HANA velkých instancí Hana. Smlouvy o úrovni služeb pro velké instance HANA najdete v článku o smlouvě SLA pro SAP HANA ve velkých instancích Azure

Domény selhání

Domény selhání reprezentují fyzickou jednotku selhání, úzce souvisí s fyzickou infrastrukturou obsaženou v datových centrech, zatímco fyzické okno nebo stojan se dá považovat za doménu selhání, protože mezi nimi není žádné přímé mapování 1:1.

když nasadíte více Virtual Machines jako součást jednoho systému SAP v Microsoft Azure služeb virtuálních počítačů, můžete ovlivnit kontroler prostředků infrastruktury Azure za účelem nasazení vaší aplikace do různých domén selhání, a tím i splnění vyšších požadavků sla dostupnosti. ale distribuce domén selhání přes jednotku škálování Azure (kolekce stovek výpočetních uzlů nebo Storagech uzlů a sítí) nebo přiřazení virtuálních počítačů do konkrétní domény selhání je něco, co nemusíte mít přímý ovládací prvek. Aby bylo možné nasměrovat řadič Azure Fabric tak, aby nasadil sadu virtuálních počítačů do různých domén selhání, musíte k virtuálním počítačům přiřadit skupinu dostupnosti Azure v době nasazení. Další informace o skupinách dostupnosti Azure najdete v části skupiny dostupnosti Azure v tomto dokumentu.

Upgradovat domény

Upgradovací domény reprezentují logickou jednotku, která pomáhá určit, jak se aktualizuje virtuální počítač v rámci systému SAP, který se skládá z instancí SAP spuštěných ve více virtuálních počítačích. když dojde k upgradu, Microsoft Azure projde procesem aktualizace těchto domén upgradu o jednu po jednom. Rozšíříte-li virtuální počítače v době nasazení v různých upgradovacích doménách, můžete chránit systém SAP částečně před potenciálním výpadkem. Aby mohl Azure nasazovat virtuální počítače systému SAP v různých upgradovacích doménách, je potřeba nastavit konkrétní atribut v době nasazení každého virtuálního počítače. Podobně jako u domén selhání je jednotka škálování Azure rozdělená do několika upgradovacích domén. Aby bylo možné nasměrovat řadič Azure Fabric na nasazení sady virtuálních počítačů v různých upgradovacích doménách, musíte k virtuálním počítačům v době nasazení přiřadit skupinu dostupnosti Azure. Další informace o skupinách dostupnosti Azure najdete níže v kapitole věnovaném sadám dostupnosti Azure .

Skupiny dostupnosti Azure

Azure Virtual Machines v rámci jedné skupiny dostupnosti Azure distribuuje kontroler prostředků infrastruktury Azure v různých doménách selhání a upgradu. Účelem distribuce v různých doménách selhání a upgradu je zabránit vypnutí všech virtuálních počítačů systému SAP v případě údržby infrastruktury nebo selhání v rámci jedné domény selhání. Ve výchozím nastavení nejsou virtuální počítače součástí skupiny dostupnosti. Účast na virtuálním počítači ve skupině dostupnosti je definována v okamžiku nasazení nebo později v důsledku opětovné konfigurace a opětovného nasazení virtuálního počítače.

Další informace o konceptu skupin dostupnosti Azure a způsobu, jakým se skupiny dostupnosti vztahují k doménám selhání a upgradu, najdete v tomto článku.

Při definování skupin dostupnosti a pokusu o kombinaci různých virtuálních počítačů různých rodin virtuálních počítačů v rámci jedné skupiny dostupnosti dojde k problémům, které vám zabrání v zahrnutí určitého typu virtuálního počítače do této skupiny dostupnosti. Důvodem je, že skupina dostupnosti je svázána s jednotkou škálování, která obsahuje určitý typ výpočetních hostitelů. A určitý typ výpočetního hostitele může spouštět jenom určité typy rodin virtuálních počítačů. Pokud třeba vytvoříte skupinu dostupnosti a nasadíte první virtuální počítač do skupiny dostupnosti a zvolíte typ virtuálního počítače Esv3 a potom se pokusíte nasadit jako druhý virtuální počítač pro virtuální počítač řady M, bude se vám v druhém přidělení zamítnout. Důvodem je, že virtuální počítače Esv3 Family neběží na stejném hostitelském hardwaru jako virtuální počítače řady M. K tomuto problému může dojít při pokusu o změnu velikosti virtuálních počítačů a pokus o přesun virtuálního počítače z rodiny Esv3 na typ virtuálního počítače řady M. V případě změny velikosti na rodinu virtuálních počítačů, které se nedají hostovat na stejném hostitelském hardwaru, musíte vypnout všechny virtuální počítače ve skupině dostupnosti a změnit jejich velikost, aby bylo možné je spustit na jiném typu hostitelského počítače. SLA virtuálních počítačů, které jsou nasazené v rámci skupiny dostupnosti, najdete v článku SLA virtuálního počítače.

Zásady skupiny dostupnosti a související aktualizace a doména selhání se nevztahují na službu HANA pro velké instance služby Hana. Smlouvy o úrovni služeb pro velké instance HANA najdete v článku věnovaném smlouvě SLA pro SAP HANA ve velkých instancích Azure.

Spárované oblasti Azure

Azure nabízí páry oblastí Azure, kde je povolená replikace určitých dat mezi těmito páry pevné oblasti. Párování oblastí je popsáno v článku provozní kontinuita a zotavení po havárii (BCDR): spárované oblasti Azure. Jak je popsáno v článku, replikace dat je vázaná na typy úložiště Azure, které se dají nakonfigurovat k replikaci do spárované oblasti. přečtěte si také článek Storage redundance v sekundární oblasti. Typy úložišť, které povolují takovou replikaci, jsou typy úložiště, které nejsou vhodné pro úlohy DBMS. Vzhledem k tomu, že použitelnost replikace úložiště Azure je omezená na úložiště objektů BLOB v Azure (například pro účely zálohování) nebo jiné scénáře úložiště s vysokou latencí. Při kontrole spárovaných oblastí a služeb, které chcete použít jako primární nebo sekundární oblast, se může stát, že v spárované oblasti nejsou k dispozici typy služeb Azure a/nebo virtuálních počítačů, které chcete použít ve vaší primární oblasti. Případně se můžete setkat s situací, kdy spárované oblasti Azure není přijatelné z důvodů dodržování předpisů. V takových případech je nutné použít nepárové oblasti jako sekundární nebo oblast zotavení po havárii. V takovém případě se budete muset postarat o replikaci některých částí dat, která by Azure replikoval sami. Příklad replikace služby Active Directory a DNS do vaší oblasti zotavení po havárii je popsán v článku Nastavení zotavení po havárii pro službu Active Directory a DNS .

Služby virtuálních počítačů Azure

Azure nabízí širokou škálu virtuálních počítačů, které můžete vybrat k nasazení. Nemusíte mít k dispozici žádné další technologie a nákupy infrastruktury. Nabídka služby virtuálního počítače Azure zjednodušuje údržbu a provozní aplikace tím, že poskytuje výpočetní prostředky a úložiště na vyžádání pro hostování, škálování a správu webových aplikací a připojených aplikací. Správa infrastruktury je automatizovaná s platformou, která je navržená pro vysokou dostupnost a dynamické škálování, aby odpovídala potřebám využití s možností několika různých cenových modelů.

S virtuálními počítači Azure vám Microsoft umožňuje nasazovat vlastní serverové image do Azure jako instance IaaS. Nebo si můžete vybrat z bohatých imagí operačních systémů s možnostmi použití z Azure Marketplace.

Z provozní perspektivy služba virtuálního počítače Azure nabízí podobné prostředí jako virtuální počítače nasazené místně. Zodpovídáte za správu, operace a také opravy konkrétního operačního systému, který běží na virtuálním počítači Azure a jeho aplikacích v daném virtuálním počítači. Společnost Microsoft neposkytuje žádné další služby nad rámec hostování tohoto virtuálního počítače v infrastruktuře Azure (infrastruktura jako služba – IaaS). Pro úlohy SAP, které jste jako nasazení zákazníka, nemá společnost Microsoft žádné nabídky mimo nabídky IaaS.

Microsoft Azure platforma je víceklientské platforma. V důsledku toho jsou úložiště, sítě a výpočetní prostředky, které hostují virtuální počítače Azure, s několika výjimkami sdíleny mezi klienty. Inteligentní omezení a logika kvót se používají k tomu, aby jeden tenant neovlivnil výkon jiného tenanta (s vysokou úrovní jednosměrového souseda) drasticky. Zejména pro certifikaci platformy Azure pro SAP HANA musí společnost Microsoft prokázat izolaci prostředků v případech, kdy je možné pravidelně spouštět více virtuálních počítačů na stejném hostiteli s SAP. I když se logika v Azure snaží zachovat odchylky v případě malých, vysoce sdílených platforem, což má za následek větší odchylky při dostupnosti prostředků nebo šířky pásma, než se zákazníci můžou setkat s jejich místními nasazeními. Pravděpodobnost, že systém SAP v Azure může vyskytnout větší odchylky než v místním systému, je potřeba vzít v úvahu.

Virtuální počítače Azure pro úlohu SAP

Pro úlohy SAP jsme výběr omezili na různé rodiny virtuálních počítačů, které jsou vhodné pro úlohy SAP a SAP HANA úlohy. Způsob, jakým najdete správný typ virtuálního počítače a jeho schopnost pracovat prostřednictvím úlohy SAP, je popsán v dokumentu, který software SAP podporuje pro nasazení Azure.

Mimo výběr čistě podporovaných typů virtuálních počítačů musíte také ověřit, jestli jsou tyto typy virtuálních počítačů dostupné v konkrétní oblasti založené na dostupných produktech v jednotlivých oblastech. Ale důležitější je, že je potřeba vyhodnotit, jestli:

• Prostředky procesoru a paměti různých typů virtuálních počítačů
• Šířka pásma IOPS různých typů virtuálních počítačů
• Síťové možnosti různých typů virtuálních počítačů
• Počet disků, které lze připojit
• Možnost využít určité typy úložiště Azure

podle potřeby. většinu těchto dat najdete tady (Linux) a tady (Windows) pro konkrétní typ virtuálního počítače.

V případě cenového modelu máte několik různých cenových možností, jako jsou:

• Průběžné platby
• Rezervovaný jeden rok
• Rezervované tři roky
• Spotové ceny

ceny každé z různých nabídek s různými nabídkami služeb v rámci operačních systémů a různých oblastí jsou k dispozici na webu Linux Virtual Machines ceny a Windows Virtual Machines ceny. Podrobnosti a flexibilitu za jeden rok a tři roky rezervované instance najdete v těchto článcích:

• Co jsou rezervace Azure?
• Flexibilita velikosti virtuálních počítačů s rezervovanými instancemi virtuálních počítačů
• Jak se na virtuální počítače uplatňuje sleva za rezervaci Azure

Další informace o cenách na místě najdete v článku Virtual Machines na místě Azure. Ceny stejného typu virtuálního počítače se taky můžou lišit mezi různými oblastmi Azure. Pro některé zákazníky je vhodné provést nasazení do levnější oblasti Azure.

Azure navíc nabízí koncepty vyhrazeného hostitele. Koncept vyhrazeného hostitele nabízí větší kontrolu nad cykly oprav, které provádí Azure. Můžete si čas opravit podle vašich vlastních plánů. Tato nabídka je konkrétně zaměřená na zákazníky s úlohou, která nemusí následovat po běžném cyklu úlohy. Pokud si chcete přečíst koncepty nabídek vyhrazených hostitelů Azure, přečtěte si článek vyhrazený hostitel Azure. Použití této nabídky je podporováno pro úlohy SAP a používá se několika zákazníky SAP, kteří chtějí mít větší kontrolu nad opravou infrastruktury a s případnými plány údržby společnosti Microsoft. Další informace o tom, jak Microsoft udržuje a opraví infrastrukturu Azure, která je hostitelem virtuálních počítačů, najdete v článku údržba virtuálních počítačů v Azure.

Generace 1 a generace 2 – virtuální počítače

Hypervisor Microsoftu dokáže zvládnout dvě různé generace virtuálních počítačů. Tyto formáty se nazývají generace 1 a generace 2. generace 2 byla představena v roce 2012 s Windows Server 2012 hypervisorem. Azure se spustil s použitím virtuálních počítačů 1. generace. Při nasazení virtuálních počítačů Azure stále používá výchozí formát 1. generace. Mezitím můžete nasadit i formáty virtuálních počítačů 2. generace. Podpora virtuálních počítačů 2. generace v Azure obsahuje seznam rodin virtuálních počítačů Azure, které se dají nasadit jako virtuální počítač 2. generace. Tento článek obsahuje taky důležité funkční rozdíly virtuálních počítačů generace 2, které můžou běžet na privátním cloudu Hyper-V a v Azure. Důležitější Tento článek také obsahuje seznam funkčních rozdílů mezi virtuálními počítači 1. generace a virtuálními počítači 2. generace, které jsou spuštěny v Azure.

Přesunutí stávajícího virtuálního počítače z jedné generace do druhé generace není možné. Pokud chcete změnit generaci virtuálního počítače, musíte nasadit nový virtuální počítač pro generaci, který si přejete, a znovu nainstalovat software, který používáte ve virtuálním počítači generace. Tato změna má vliv jenom na základní image virtuálního pevného disku virtuálního počítače a nemá žádný vliv na datové disky nebo připojené sdílené složky systému souborů NFS ani SMB. Datové disky, NFS nebo sdílené složky SMB, které byly původně přiřazeny, například na virtuálním počítači generace 1.

Storage: Microsoft Azure Storage a datových disků

Microsoft Azure Virtual Machines využívá jiné typy úložišť. Při implementaci SAP na službách virtuálních počítačů Azure je důležité pochopit rozdíly mezi těmito dvěma hlavními typy úložiště:

• Netrvalé a stálé úložiště.
• Trvalé úložiště.

Virtuální počítače Azure po nasazení virtuálního počítače nabízejí netrvalé disky. V případě restartování virtuálního počítače se vymaže veškerý obsah na těchto jednotkách. Proto je vzhledem k tomu, že datové soubory a soubory protokolů a opětovného provedení databáze by měly být v žádném případě umístěny na těchto netrvalých jednotkách. Existují výjimky pro některé databáze, kde tyto netrvalé jednotky můžou být vhodné pro databáze tempdb a dočasné tabulkové prostory. Ale nepoužívejte tyto jednotky pro virtuální počítače řady A-Series, protože tyto jednotky, které nejsou trvalé, jsou v rámci této rodiny virtuálních počítačů omezené v propustnosti. další podrobnosti najdete v článku principy dočasné jednotky na Windows virtuálních počítačích v Azure .

Windows

D:\ jednotky na virtuálním počítači Azure je netrvalá jednotka, na které se zálohují některé místní disky na výpočetním uzlu Azure. Protože není trvale trvalé, znamená to, že všechny změny provedené v obsahu D:\ Při restartu virtuálního počítače dojde ke ztrátě jednotky. Podle "jakýchkoli změn", jako jsou uložené soubory, adresáře vytvořené, nainstalované aplikace atd.

Linux

Virtuální počítače se systémem Linux automaticky připojují jednotku na/mnt/Resource, která je netrvalou jednotkou zajištěnou místními disky na výpočetním uzlu Azure. Protože není trvale trvalé, znamená to, že všechny změny provedené v obsahu v/mnt/Resource budou při restartování virtuálního počítače ztraceny. O jakékoli změny, jako jsou uložené soubory, adresáře, které se nainstalují, aplikace atd.

Účty úložiště Azure

při nasazování služeb nebo virtuálních počítačů v Azure jsou nasazení vhd a image virtuálních počítačů uspořádány v jednotkách s názvem Azure Storage účty. Účty úložiště Azure mají omezení buď v IOPS, propustnosti, nebo velikosti, které může obsahovat. V předchozích omezeních, která jsou popsána v následujících případech:

• Cíle škálovatelnosti pro účty úložiště úrovně Standard
• Cíle škálovatelnosti pro účty úložiště objektů blob stránky úrovně Premium

hraje důležitou roli při plánování nasazení SAP v Azure. Bylo na vás, abyste mohli spravovat počet trvalých disků v rámci účtu úložiště. Je potřeba spravovat účty úložiště a nakonec vytvořit nové účty úložiště a vytvořit tak další trvalé disky.

V posledních letech se zavedení služby Azure Managed disk z těchto úloh zbavuje. Doporučení pro nasazení SAP je využít Azure Managed disks místo správy účtů Azure Storage sami. Služba Azure Managed disks bude distribuovat disky napříč různými účty úložiště, takže nebudou překročeny limity jednotlivých účtů úložiště.

V rámci účtu úložiště máte typ konceptu s názvem Containers, který se dá použít k seskupení určitých disků do konkrétních kontejnerů.

V rámci Azure se název disku/virtuálního pevného disku řídí následujícím připojením k pojmenování, které musí v Azure zadat jedinečný název VHD:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Výše uvedený řetězec musí jednoznačně identifikovat disk nebo virtuální pevný disk, který je uložený v Azure Storage.

Typy trvalého úložiště Azure

Azure nabízí celou řadu možností trvalého úložiště, které se dají použít pro úlohy SAP a specifické komponenty zásobníku SAP. Další podrobnosti najdete v dokumentu Úložiště Azure pro úlohy SAP.

Microsoft Azure Sítí

Microsoft Azure poskytuje síťovou infrastrukturu, která umožňuje mapování všech scénářů, které chceme realizovat pomocí softwaru SAP. Možnosti jsou:

• Přístup z vnějšku, přímo k virtuálním Terminál Windows služby nebo ssh/VNC
• Přístup ke službám a konkrétním portům používaným aplikacemi v rámci virtuálních počítače
• Interní komunikace a překlad názvů mezi skupinou virtuálních počítače nasazených jako virtuální počítače Azure
• Připojení mezi různými umístěními mezi místní sítí zákazníka a sítí Azure
• Připojení mezi oblastmi Azure nebo datovými cáty mezi lokalitami Azure

Další informace najdete tady: https://azure.microsoft.com/documentation/services/virtual-network/

Existuje mnoho různých možností konfigurace překladu IP adres a názvů v Azure. K dispozici je také Azure DNS, kterou můžete použít místo nastavování vlastního serveru DNS. Další informace najdete v tomto článku a na této stránce.

V případě scénářů mezi místními nebo hybridními prostředími spoléháme na skutečnost, že místní služba AD, OpenLDAP nebo DNS byla rozšířena prostřednictvím sítě VPN nebo privátního připojení k Azure. V některých scénářích, jak je zde uvedené, může být nutné mít v Azure nainstalovanou repliku AD/OpenLDAP.

Vzhledem k tomu, že síť a překlad názvů jsou důležitou součástí nasazení databáze pro systém SAP, je tento koncept podrobněji popsán v Příručce pro nasazení DBMS.

Virtuální sítě Azure

Vytvořením služby Azure Virtual Network můžete definovat rozsah adres privátních IP adres přidělených funkcemi Azure DHCP. Ve scénářích mezi místními prostředími je definovaný rozsah IP adres stále přidělován pomocí DHCP v Azure. Překlad názvů domén se ale provádí místně (za předpokladu, že jsou virtuální počítače součástí místní domény), a proto může překládá adresy nad rámec různých Azure Cloud Services.

Každý virtuální počítač v Azure musí být připojený k virtuálnímu Virtual Network.

Další podrobnosti najdete v tomto článku a na této stránce.

Adresa MAC virtuální síťové karty se může změnit, například po změně velikosti a hostování operačního systému Windows nebo Linux vezme novou síťovou kartu a v tomto případě automaticky použije DHCP k přiřazení IP adres a ADRES DNS.

Statické přiřazení IP adresy

Virtuálním počítačům v rámci služby Azure Virtual Network je možné přiřadit pevné nebo Virtual Network. Spuštění virtuálních Virtual Network v Azure Virtual Network možnost využít tuto funkci v případě potřeby nebo v některých scénářích. Přiřazení IP adresy zůstává platné po celou dobu existence virtuálního počítače bez ohledu na to, jestli je virtuální počítač spuštěný nebo vypnutý. V důsledku toho musíte při definování rozsahu IP adres pro virtuální počítače vzít v úvahu celkový počet virtuálních počítačů (spuštěných a zastavených virtuálních Virtual Network. IP adresa zůstane přiřazená buď do odstranění virtuálního počítače a jeho síťového rozhraní, nebo do doby, než se IP adresa znovu deřadí. Další informace najdete v tomto článku.

Sekundární IP adresy pro virtualizaci názvu hostitele SAP

Každá síťová karta virtuálního počítače Azure může mít přiřazených několik IP adres. Tuto sekundární IP adresu je možné použít pro virtuální názvy hostitelů SAP, které se v případě potřeby mapují na záznam DNS A/PTR. Sekundární IP adresy musí být přiřazeny ke konfiguraci IP adres virtuálních zařízení Azure podle tohoto článku a také musí být nakonfigurované v rámci operačního systému, protože sekundární IP adresy se nepřiřazuje prostřednictvím protokolu DHCP. Každá sekundární IP adresa musí být ze stejné podsítě, ke které je vázaná síť vNIC. Použití Azure Load Balancer IP adresy se nepodporuje jako sekundární pro sekundární konfigurace IP adres, jako jsou clustery Pacemaker. V tomto případě IP adresa virtuálního hostitele SAP Load Balancer virtuálních hostitelů SAP. Obecné pokyny k používání názvů virtuálních hostitelů 962955 poznámku #A0 pro SAP.

Více síťových karta na virtuální počítač

Pro virtuální počítač Azure můžete definovat několik karet virtuálního síťového rozhraní (vNIC). Díky možnosti mít více virtuálních síťových adaptérů můžete začít nastavovat oddělení síťového provozu, kde se například klientský provoz směruje přes jeden virtuální síťový adaptér a back-endový provoz se směruje přes druhý virtuální síťový adaptér. V závislosti na typu virtuálního počítače existují různá omezení počtu virtuálních nic, které může virtuální počítač přiřadit. Přesné podrobnosti, funkce a omezení najdete v těchto článcích:

• Vytvoření virtuálního Windows s několika síťovými kartami
• Vytvoření virtuálního počítače s Linuxem s několika síťovými kartami
• Nasazení virtuálních počítače s více síťovými rozhraními pomocí šablony
• Nasazení virtuálních počítače s více síťovými rozhraními pomocí PowerShellu
• Nasazení virtuálních počítače s více síťovými rozhraními pomocí Azure CLI

Připojení site-to-site

Mezi místními sítěmi jsou virtuální počítače Azure a místní počítače propojené transparentním a trvalým připojením VPN. Očekává se, že se stane nejběžnějším vzorem nasazení SAP v Azure. Předpokladem je, že provozní postupy a procesy s instancemi SAP v Azure by měly fungovat transparentně. To znamená, že byste měli být schopni tisknout z těchto systémů a používat SAP Transport Management System (TMS) k přenosu změn z vývojového systému v Azure do testovacího systému, který je nasazený místně. Další dokumentaci týkající se site-to-site najdete v tomto článku.

Zařízení Tunnel VPN

Pokud chcete vytvořit připojení typu Site-to-Site (místní datové centrum k data centru Azure), musíte buď získat a nakonfigurovat zařízení VPN, nebo použít službu Směrování a vzdálený přístup (RRAS), která byla zavedena jako softwarová komponenta s Windows Server 2012.

• Vytvoření virtuální sítě s připojením site-to-site VPN pomocí PowerShellu
• Informace o zařízeních VPN pro připojení typu Site-to-Site ke službě VPN Gateway
• Nejčastější dotazy k branám VPN

Na obrázku výše uvedená dvě předplatná Azure mají rezervované podrozsahy IP adres pro použití ve virtuálních sítích v Azure. Připojení z místní sítě k Azure se nasa navázat prostřednictvím sítě VPN.

Point-to-site VPN

Vpn point-to-site vyžaduje, aby se každý klientský počítač připojil k Azure pomocí vlastní sítě VPN. Ve scénářích SAP se díváme na to, že připojení point-to-site není praktické. Proto nejsou uvedeny žádné další odkazy na připojení VPN typu point-to-site.

Další informace najdete tady.

• Konfigurace připojení typu Point-to-Site k virtuální síti pomocí webu Azure Portal
• Konfigurace připojení Point-to-Site k virtuální síti pomocí prostředí PowerShell

Síť VPN pro více lokalit

Azure také v současné době nabízí možnost vytvořit připojení VPN s více weby pro jedno předplatné Azure. Dříve bylo jedno předplatné omezené na jedno site-to-site VPN připojení. Toto omezení se pro jedno předplatné odešelo díky připojením VPN typu Multi-Site. Díky tomu je možné využít více než jednu oblast Azure pro konkrétní předplatné prostřednictvím konfigurací mezi místními sítěmi.

Další dokumentaci najdete v tomto článku.

Připojení mezi virtuálními sítěmi

Pomocí sítě VPN s více weby musíte nakonfigurovat samostatnou službu Azure Virtual Network v každé z oblastí. Často se ale stává, že softwarové komponenty v různých oblastech by spolu měly komunikovat. V ideálním případě by se tato komunikace neměla směrovat z jedné oblasti Azure do místního prostředí a z této oblasti do jiné oblasti Azure. Pro zástupce Nabízí Azure možnost nakonfigurovat připojení z jedné služby Azure Virtual Network v jedné oblasti do jiné azure Virtual Network hostované v jiné oblasti. Tato funkce se nazývá připojení VNet-to-VNet. Další podrobnosti o této funkci najdete tady: https://azure.microsoft.com/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/ .

Privátní připojení k Azure ExpressRoute

Microsoft Azure ExpressRoute umožňuje vytvářet privátní připojení mezi datovými cly Azure a místní infrastrukturou zákazníka nebo v prostředí ve spolupráci. ExpressRoute nabízejí zprostředkovatelé SÍTĚ VPN MPLS (přepnutí paketů) nebo jiní poskytovatelé síťových služeb. Připojení ExpressRoute se nepřenášejí prostřednictvím veřejného internetu. Připojení ExpressRoute nabízejí vyšší zabezpečení, větší spolehlivost prostřednictvím více paralelních okruhů, vyšší rychlost a nižší latenci než typická připojení přes internet.

Další podrobnosti o Azure ExpressRoute a nabídkách najdete tady:

• https://azure.microsoft.com/documentation/services/expressroute/
• https://azure.microsoft.com/pricing/details/expressroute/
• https://azure.microsoft.com/documentation/articles/expressroute-faqs/

ExpressRoute umožňuje více předplatných Azure prostřednictvím jednoho okruhu ExpressRoute, jak je zde dokumentované.

• https://azure.microsoft.com/documentation/articles/expressroute-howto-linkvnet-arm/
• https://azure.microsoft.com/documentation/articles/expressroute-howto-circuit-arm/

Vynucené tunelování v případě mezi místními prostředími

U virtuálních počítačů, které se připojují k místním doménám prostřednictvím připojení site-to-site, point-to-site nebo ExpressRoute, musíte zajistit, aby se nastavení internetového proxy serveru nasadilo také pro všechny uživatele na těchto virtuálních počítači. Ve výchozím nastavení by software spuštěný na těchto virtuálních nebo uživatelích, kteří používají prohlížeč pro přístup k internetu, nebyl přes proxy server společnosti, ale mohl by se připojovat přímo přes Azure k internetu. Ani nastavení proxy serveru ale není 100% řešení pro řízení provozu přes proxy server společnosti, protože za kontrolu proxy serveru zodpovídá software a služby. Pokud to dělá software spuštěný na virtuálním počítači nebo pokud správce manipuluje s nastavením, můžete provoz na internet znovu objet přímo přes Azure na internet.

Abyste se takovému přímému připojení k internetu vyhnuli, můžete nakonfigurovat vynucené tunelování s připojením site-to-site mezi místním prostředím a Azure. Podrobný popis funkce vynuceného tunelování se zveřejňuje tady. https://azure.microsoft.com/documentation/articles/vpn-gateway-forced-tunneling-rm/

Vynucené tunelování pomocí ExpressRoute je povoleno zákazníky, kteří si vyberou výchozí trasu prostřednictvím relací partnerských vztahů protokolu BGP ExpressRoute.

Shrnutí sítí Azure

Tato kapitola obsahuje mnoho důležitých bodů o sítích Azure. Tady je souhrn hlavních bodů:

• Virtuální sítě Azure umožňují do nasazení Azure umístit síťovou strukturu. Virtuální sítě je možné izolovat vzájemně nebo pomocí skupin zabezpečení sítě mezi virtuální sítě je možné řídit provoz.
• Virtuální sítě Azure je možné využít k přiřazení rozsahů IP adres k virtuálním počítačům nebo přiřazení pevných IP adres k virtuálním počítačům.
• Pokud chcete nastavit připojení typu Site-to-site nebo Point-to-site, musíte nejdřív vytvořit Virtual Network Azure.
• Po nasazení virtuálního počítače už nebude možné změnit Virtual Network přiřazeného k VIRTUÁLNÍmu počítači.

Kvóty ve službách virtuálních počítačů Azure

Musíme mít jasné informace o tom, že infrastruktura úložiště a sítě je sdílená mezi virtuálními počítači s různými službami v infrastruktuře Azure. Stejně jako v zákaznických datových centrech dochází k nadměrnému zajišťování některých prostředků infrastruktury v určité míře. Microsoft Azure platforma používá disk, procesor, síť a další kvóty k omezení spotřeby prostředků a zachování konzistentního a deterministického výkonu. Různé typy virtuálních počítačů (A5, A6 atd.) mají různé kvóty pro počet disků, procesor, paměť RAM a síť.

Při plánování a velikosti SAP v řešeních Azure je třeba zvážit kvóty pro jednotlivé velikosti virtuálních počítačů. Kvóty virtuálních počítačů jsou popsané tady (Linux) a tady (Windows).

Popsané kvóty reprezentují teoretické maximální hodnoty. Limit počtu vstupně-výstupních operací na disk lze dosáhnout pomocí malých vstupně-výstupních operací (8 KB), ale možná se nedosáhne s velkým I/v operačním systémem (1 MB). Limit IOPS se vynutil v členitosti na jeden disk.

Vzhledem k tomu, že se rozhodnete, jestli systém SAP zapadá do služeb virtuálních počítačů Azure a jeho schopností nebo jestli je potřeba nakonfigurovat jiný systém, aby se mohl nasadit systém v Azure, je možné použít následující rozhodovací strom:

1. Nejdůležitější informace, které je třeba začít používat, jsou požadavkem SAP pro daný systém SAP. Požadavky SAP musí být odděleny na součást systému DBMS a část aplikace SAP, i když je systém SAP již nasazen místně v konfiguraci 2. úrovně. V případě stávajících systémů se v závislosti na stávajících srovnávacích testech SAP dají určit nebo odhadnout i body SAP týkající se často používaného hardwaru. Výsledky najdete na stránce o srovnávacích testech standardní aplikace SAP . U nově nasazených systémů SAP byste se měli dodávat prostřednictvím cvičení změny velikosti, které by mělo určovat požadavky systému SAP.
2. U stávajících systémů je třeba změřit vstupně-výstupní operace a vstupně-výstupní operace za sekundu na serveru DBMS. U nově plánovaných systémů by se při uplatnění změny velikosti pro nový systém měl také na straně systému DBMS poskytnout hrubou představu o požadavcích na vstupně-výstupní operace. Pokud si nejste jistí, nakonec je potřeba provést zkoušku konceptu.
3. Porovnání požadavku SAP pro server DBMS s protokoly SAP můžou poskytnout různé typy virtuálních počítačů Azure. Informace o protokolech SAP různých typů virtuálních počítačů Azure jsou zdokumentovány v části SAP Note 1928533. Fokus by měl být nejprve na virtuálním počítači DBMS, protože databázová vrstva je vrstva v systému SAP NetWeaver, která se ve většině nasazení Nehorizontální škálovat. Naproti tomu může být horizontální navýšení kapacity aplikační vrstvy SAP. Pokud žádný z podporovaných typů virtuálních počítačů Azure nemůže doručovat požadované SAP, zatížení plánovaného systému SAP nejde v Azure spustit. Musíte buď nasadit systém místně, nebo potřebujete změnit svazek zatížení systému.
4. jak je uvedeno tady (Linux) a tady (Windows), Azure vynutilo kvótu IOPS za disku nezávisle na tom, jestli používáte standardní Storage nebo Premium Storage. V závislosti na typu virtuálního počítače se počet datových disků, které se dají připojit, liší. V důsledku toho můžete vypočítat maximální počet vstupně-výstupních operací, které je možné dosáhnout u každého z různých typů virtuálních počítačů. V závislosti na rozložení souboru databáze můžete disky proniknout, aby se v hostovaném operačním systému staly jedním svazkem. Pokud ale aktuální svazek IOPS nasazeného systému SAP překračuje vypočtené limity pro největší typ virtuálního počítače Azure a pokud nemůžete kompenzovat větší množství paměti, může být zatížení systému SAP vážně ovlivněno. V takových případech můžete narazit na místo, kde byste neměli nasazovat systém na Azure.
5. Zvláště v systémech SAP, které jsou nasazené místně v konfiguracích dvou vrstev, je pravděpodobné, že systém může být potřeba nakonfigurovat v Azure v konfiguraci s 3 vrstvami. V tomto kroku je potřeba ověřit, jestli je v aplikační vrstvě SAP nějaká součást, kterou nejde škálovat a které se nevejdou do prostředků procesoru a paměti, které nabízí jiný typ virtuálních počítačů Azure. Pokud taková součást skutečně existuje, systém SAP a její zatížení se nedají nasadit do Azure. Pokud ale můžete škálovat komponenty aplikace SAP na více virtuálních počítačů Azure, je možné systém nasadit do Azure.

Pokud se komponenty aplikační vrstvy DBMS a SAP dají spustit ve virtuálních počítačích Azure, musí být definovaná konfigurace s ohledem na:

• Počet virtuálních počítačů Azure
• Typy virtuálních počítačů pro jednotlivé součásti
• Počet virtuálních pevných disků v systému DBMS, které poskytují dostatek IOPS

Správa prostředků Azure

portál Azure

Azure Portal je jedno ze tří rozhraní pro správu nasazení virtuálních počítačů Azure. Základní úlohy správy, jako je nasazení virtuálních počítačů z imagí, je možné provádět prostřednictvím Azure Portal. kromě toho vytváření Storagech účtů, virtuálních sítí a dalších komponent Azure také provádí úlohy, které Azure Portal mohou dobře zvládnout. Nicméně funkce, jako je nahrání virtuálních pevných disků z místního prostředí do Azure nebo kopírování VHD v rámci Azure, jsou úkoly, které vyžadují nástroje nebo správu třetích stran prostřednictvím PowerShellu nebo rozhraní příkazového řádku.

Úlohy správy a konfigurace pro instanci virtuálního počítače jsou možné v rámci Azure Portal.

Kromě restartování a vypnutí virtuálního počítače můžete také připojit, odpojit a vytvořit datové disky pro instanci virtuálního počítače, zachytit instance pro přípravu bitové kopie a nakonfigurovat velikost instance virtuálního počítače.

Azure Portal poskytuje základní funkce pro nasazení a konfiguraci virtuálních počítačů a mnoho dalších služeb Azure. Netýká se však Azure Portal všech dostupných funkcí. V Azure Portal není možné provádět úlohy, jako například:

• Nahrávají se virtuální pevné disky do Azure.
• Kopírování virtuálních počítačů

správa prostřednictvím rutin Microsoft Azure PowerShell

Windows PowerShell je výkonné a rozšiřitelné rozhraní, které zákazníci, kteří nasazují větší počty systémů v Azure, široce přijali. Po instalaci rutin PowerShellu na stolní počítač, přenosný počítač nebo na vyhrazenou stanici pro správu je možné rutiny prostředí PowerShell spustit vzdáleně.

v tomto článkuse dozvíte, jak povolit místní pracovní plochu nebo přenosný počítač pro použití rutin Azure PowerShell a jak je nakonfigurovat pro použití s předplatnými Azure.

podrobnější postup, jak nainstalovat, aktualizovat a nakonfigurovat Azure PowerShell rutiny, najdete v tématu instalace Azure PowerShell modulu. Díky tomu, že prostředí pro zákazníky bylo ještě daleko, bylo to, že PowerShell je určitě výkonnějším nástrojem pro nasazení virtuálních počítačů a vytvoření vlastních kroků v nasazení virtuálních počítačů. Všichni zákazníci, kteří používají instance SAP v Azure, používají rutiny prostředí PowerShell k dodávání úloh správy, které provádějí v Azure Portal, nebo dokonce používají rutiny prostředí PowerShell výhradně ke správě jejich nasazení v Azure. vzhledem k tomu, že rutiny specifické pro Azure sdílejí stejné konvence vytváření názvů jako rutiny s více než 2000 Windows, je snadné úlohu, kterou správci Windows využít k těmto rutinám.

Viz příklad zde: https://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx

Nasazení rozšíření Azure pro SAP (viz kapitola Azure Extension for SAP v tomto dokumentu) je možné jenom prostřednictvím PowerShellu nebo rozhraní příkazového řádku. Proto je nutné nastavit a nakonfigurovat prostředí PowerShell nebo rozhraní příkazového řádku při nasazení nebo správě systému SAP NetWeaver v Azure.

Jelikož Azure poskytuje další funkce, přidají se nové rutiny PowerShellu, které vyžadují aktualizaci rutin. Proto má smysl kontrolovat web Azure Download alespoň jednou měsíčně https://azure.microsoft.com/downloads/ pro novou verzi rutin. Nová verze je nainstalovaná nad starší verzí.

obecný seznam příkazů powershellu souvisejících s Azure najdete tady: Azure PowerShell dokumentaci.

správa prostřednictvím příkazů rozhraní příkazového řádku Microsoft Azure

Pro zákazníky, kteří používají Linux a chtějí spravovat Azure Resources PowerShell, nemusí být možnost. Microsoft jako alternativu nabízí rozhraní příkazového řádku Azure. Rozhraní příkazového řádku Azure nabízí sadu open source příkazů pro různé platformy pro práci s platformou Azure. Rozhraní příkazového řádku Azure CLI poskytuje mnoho stejných funkcí, jaké se nacházejí v Azure Portal.

Informace o instalaci, konfiguraci a způsobu použití příkazů rozhraní příkazového řádku k provádění úkolů Azure najdete v tématu.

• Instalace Azure Classic CLI
• Instalace rozhraní příkazového řádku Azure CLI 2,0
• Nasazení a správa virtuálních počítačů pomocí šablon Azure Resource Manager a Azure CLI
• použití rozhraní příkazového řádku Azure classic pro Mac, Linux a Windows s Azure Resource Manager

První postup plánování nasazení

Prvním krokem při plánování nasazení není vyhledání virtuálních počítačů, které jsou dostupné pro běh SAP. Prvním krokem může být časově náročné, ale nejdůležitější je spolupracovat s týmy pro dodržování předpisů a zabezpečení ve vaší společnosti na základě toho, jaké jsou podmínky hranice pro nasazení, který typ úlohy SAP nebo obchodní proces do veřejného cloudu. Pokud vaše společnost nasadila jiný software před do Azure, může být tento proces snadný. Pokud je vaše společnost na začátku cesty větší, můžou být potřebné větší diskuze, aby bylo možné zjistit podmínky hranic, podmínky zabezpečení, které umožňují hostování určitých dat SAP a obchodních procesů SAP ve veřejném cloudu.

Jako užitečnou nápovědu můžete Ukázat na nabídky dodržování předpisů Microsoftu , které nabízí seznam dodržování předpisů, které může společnost Microsoft poskytnout.

Další oblasti otázek, jako je šifrování dat pro neaktivní nebo jiné šifrování ve službě Azure, jsou popsány v části Přehled šifrování Azure.

Podceňují skutečnou tuto fázi projektu ve vašem plánování. Jenom v případě, že k tomuto tématu máte smlouvu a pravidla, musíte přejít na další krok, což je plánování síťové architektury, kterou nasazujete v Azure.

Různé způsoby nasazení virtuálních počítačů pro SAP v Azure

V této kapitole se seznámíte s různými způsoby nasazení virtuálního počítače v Azure. Další přípravné postupy, stejně jako práce s virtuálními disky a virtuálními počítače v Azure, jsou kryty v této kapitole.

Nasazení virtuálních počítače pro SAP

Microsoft Azure nabízí několik způsobů nasazení virtuálních počítačů a přidružených disků. Proto je důležité porozumět rozdílům, protože příprava virtuálních počítače se může lišit v závislosti na metodě nasazení. Obecně se podíváme na následující scénáře:

Přesun virtuálního počítače z místního prostředí do Azure s neobecněnizovaným diskem

Plánujete přesunout konkrétní systém SAP z místního prostředí do Azure. Můžete to udělat tak, že nahrajete virtuální pevný disk, který obsahuje operační systém, binární soubory SAP a binární soubory DBMS a virtuální pevné disky s daty a soubory protokolu DBMS do Azure. Na rozdíl od scénáře č. 2níže si na virtuálním počítači Azure zachováte uživatelské účty SAP SID, SAP a název hostitele tak, jak byly nakonfigurované v místním prostředí. Zobecnění image proto není nutné. V kapitolách Příprava na přesun virtuálního počítače z místního prostředí do Azure s neobecněnizovaným diskem tohoto dokumentu najdete informace o místních přípravných krocích a nahrání neobecněných virtuálních počítače nebo virtuálních pevných disků do Azure. Podrobný postup nasazení takové image v Azure najdete v kapitole Scénář 3: Přesun virtuálního počítače z místního prostředí pomocí ne generalizovaného virtuálního pevného disku Azure se SAP.

Další možností, kterou v tomto průvodci nebudeme podrobně probírat, je použití Azure Site Recovery k replikaci aplikačních serverů SAP NetWeaver a centrálních služeb SAP NetWeaver do Azure. Nedoporučujeme používat pro databázovou vrstvu Azure Site Recovery raději používat mechanismy replikace specifické pro databázi, jako je replikace systému HANA. Další informace najdete v kapitole Ochrana SAP příručky Informace o zotavení po havárii pro místní aplikace.

Nasazení virtuálního počítače s imagemi specifickými pro zákazníka

Vzhledem ke konkrétním požadavkům na opravy verze operačního systému nebo DBMS nemusí zadané image v Azure Marketplace vašim potřebám. Proto možná budete muset vytvořit virtuální počítač pomocí vlastní privátní image virtuálního počítače s operačním systémem nebo DBMS, kterou pak můžete nasadit několikrát později. Pokud chcete takovou privátní image připravit na duplikaci, je třeba zvážit následující položky:

Windows

Další podrobnosti najdete v článku o generalizovaném virtuálním pevném disku Windows a jeho použití k vytvoření nových virtuálních počítače v Azure. Nastavení služby Windows (například sid Windows název hostitele) musí být na místním virtuálním počítači abstrahované nebo generalizované pomocí příkazu sysprep. Upload

Linux

Postupujte podle kroků popsaných v těchto článcích pro SUSE, Red Hatnebo Oracle Linuxa připravte virtuální pevný disk k nahrání do Azure.

Pokud jste už na místním virtuálním počítači nainstalovali obsah SAP (zejména pro 2vrstvé systémy), můžete nastavení systému SAP po nasazení virtuálního počítače Azure upravit pomocí postupu přejmenování instance podporovaného správcem SAP Software Provisioning Manageru (SAP Note 1619720). Další informace najdete v kapitolách Příprava na nasazení virtuálního počítače s imagemi specifickými pro zákazníka pro SAP a Nahrání virtuálního pevného disku z místního prostředí do Azure tohoto dokumentu pro místní přípravné kroky a nahrání generalizovaného virtuálního počítače do Azure. Podrobný postup nasazení takové image v Azure najdete v kapitole Scénář 2: Nasazení virtuálního počítače s vlastní i image pro SAP v průvodci nasazením.

Nasazení virtuálního počítače mimo Azure Marketplace

K nasazení virtuálního počítače byste chtěli použít image virtuálního počítače od Microsoftu nebo Azure Marketplace třetí strany. Po nasazení virtuálního počítače v Azure budete postupovat podle stejných pokynů a nástrojů pro instalaci softwaru SAP nebo DBMS do virtuálního počítače jako v místním prostředí. Podrobnější popis nasazení najdete v kapitole Scénář 1: Nasazení virtuálního počítače mimo Azure Marketplace pro SAP v průvodci nasazením.

Příprava virtuálních počítače se SAP pro Azure

Než nahrajete virtuální počítače do Azure, musíte se ujistit, že virtuální počítače a virtuální disky splňují určité požadavky. V závislosti na použité metodě nasazení existují malé rozdíly.

Příprava na přesun virtuálního počítače z místního prostředí do Azure s neobecněnizovaným diskem

Běžnou metodou nasazení je přesun existujícího virtuálního počítače, na kterém běží systém SAP z místního prostředí do Azure. Tento virtuální počítač a systém SAP ve virtuálním počítači by měly běžet jenom v Azure s použitím stejného názvu hostitele a pravděpodobně stejného SAP SID. V takovém případě by se hostovaný operační systém virtuálního počítače neměl pro více nasazení generalizovat. Pokud se místní síť rozšířila do Azure, je možné v rámci virtuálního počítače použít i stejné doménové účty jako ty, které se používaly dříve v místním prostředí.

Požadavky při přípravě vlastního disku virtuálního počítače Azure:

• Původně měl virtuální pevný disk obsahující operační systém maximální velikost pouze 127 GB. Toto omezení bylo na konci března 2015 eliminováno. Virtuální pevný disk obsahující operační systém teď může mít velikost až 1 TB, stejně jako jakýkoli Azure Storage virtuální pevný disk.
• Musí být v pevném formátu VHD. Dynamické virtuální nebo virtuální disky ve formátu VHDx se v Azure zatím nepodporují. Dynamické virtuální pevné disky se při nahrání virtuálního pevného disku pomocí rutin PowerShellu nebo rozhraní příkazového řádku převedou na statické virtuální pevné disky.
• Virtuální pevné disky, které jsou připojené k virtuálnímu počítače a měly by být znovu připojeny v Azure k virtuálnímu počítače, musí být také ve formátu pevného virtuálního pevného disku. Informace o omezení velikosti datových disků si můžete přečíst v tomto článku. Dynamické virtuální pevné disky se při nahrání virtuálního pevného disku pomocí rutin PowerShellu nebo rozhraní příkazového řádku převedou na statické virtuální pevné disky.
• Přidejte další místní účet s oprávněními správce, který může používat podpora Microsoftu nebo který se může přiřadit jako kontext pro služby a aplikace, ve kterých se mají spouštět, dokud se virtuální počítač nenasadí a nebude možné používat vhodnější uživatele.
• Přidejte další místní účty, které můžou být potřeba pro konkrétní scénář nasazení.

Windows

V tomto scénáři se k nahrání a nasazení virtuálního počítače do Azure nevyžaduje generalizace (sysprep) virtuálního počítače. Ujistěte se, že je jednotka D:\ se nepoužít. Nastavte automatické připojení disku pro připojené disky, jak je popsáno v kapitole Nastavení automatického připojení pro připojené disky v tomto dokumentu.

Linux

V tomto scénáři se k nahrání a nasazení virtuálního počítače v Azure nevyžaduje generalizace virtuálního počítače (waagent -deprovision). Ujistěte se, že se používá /mnt/resource a že všechny disky jsou připojené přes uuid. U disku s operačním systémem se ujistěte, že položka bootloaderu odráží také připojení založené na uuid.

Příprava na nasazení virtuálního počítače s imagemi specifickými pro zákazníka pro SAP

Soubory VHD, které obsahují zobecněný operační systém, se ukládají v kontejnerech Azure Storage účty nebo jako image spravovaných disků. Z takové image můžete nasadit nový virtuální počítač tak, že v souborech šablony nasazení budete odkazovat na image virtuálního pevného disku nebo spravovaného disku jako na zdroj, jak je popsáno v kapitole Scénář 2: Nasazení virtuálního počítače s vlastní i image pro SAP v průvodci nasazením.

Požadavky při přípravě vlastní image virtuálního počítače Azure:

• Původně měl virtuální pevný disk obsahující operační systém maximální velikost pouze 127 GB. Toto omezení bylo na konci března 2015 eliminováno. Virtuální pevný disk obsahující operační systém teď může mít velikost až 1 TB, stejně jako jakýkoli Azure Storage virtuální pevný disk.
• Musí být v pevném formátu VHD. Dynamické virtuální nebo virtuální disky ve formátu VHDx se v Azure zatím nepodporují. Dynamické virtuální pevné disky se při nahrání virtuálního pevného disku pomocí rutin PowerShellu nebo rozhraní příkazového řádku převedou na statické virtuální pevné disky.
• Virtuální pevné disky, které jsou připojené k virtuálnímu počítače a měly by být znovu připojeny v Azure k virtuálnímu počítače, musí být také ve formátu pevného virtuálního pevného disku. Informace o omezení velikosti datových disků si můžete přečíst v tomto článku. Dynamické virtuální pevné disky se při nahrání virtuálního pevného disku pomocí rutin PowerShellu nebo rozhraní příkazového řádku převedou na statické virtuální pevné disky.
• Přidejte další místní účty, které můžou být potřeba pro konkrétní scénář nasazení.
• Pokud image obsahuje instalaci SAP NetWeaveru a přejmenování názvu hostitele z původního názvu v okamžiku nasazení Azure je pravděpodobné, doporučujeme do šablony zkopírovat nejnovější verze DVD SAP Software Provisioning Manageru. To vám umožní snadno použít funkci přejmenování poskytovanou sap k přizpůsobení změně názvu hostitele a/nebo změně SID systému SAP v rámci nasazené image virtuálního počítače, jakmile se začne nová kopie.

Windows

Ujistěte se, že je jednotka D:\ se pro připojené disky nepoužít možnost Nastavit automatické připojení disku, jak je popsáno v kapitole Nastavení automatického připojení pro připojené disky v tomto dokumentu.

Linux

Ujistěte se, že se používá /mnt/resource a že všechny disky jsou připojené přes uuid. U disku s operačním systémem se ujistěte, že položka bootloaderu odráží také připojení založené na uuid.

• V této šabloně je možné předem nainstalovat grafické uživatelské rozhraní SAP (pro účely správy a nastavení).
• Je možné nainstalovat další software potřebný k úspěšnému spuštění virtuálních počítače v různých scénářích, pokud tento software může fungovat s přejmenování virtuálního počítače.

Pokud je virtuální počítač dostatečně obecný a nakonec nezávislý na účtech nebo uživatelích, kteří nejsou k dispozici v cílovém scénáři nasazení Azure, provede se poslední přípravný krok generalizace takové image.

Generalizace virtuálního počítače

Windows

Posledním krokem je přihlášení k virtuálnímu počítače pomocí účtu správce. Otevřete příkazové Windows jako správce. Přejděte do složky %windir%\windows\system32\sysprep a spusťte sysprep.exe. Zobrazí se malé okno. Je důležité zaškrtnutá možnost Generalizovat (výchozí možnost není zaškrtnutá) a změnit možnost Vypnout z výchozí možnosti Restartovat na Vypnout. Tento postup předpokládá, že se proces sysprep provádí místně v hostova operačním systému virtuálního počítače. Pokud chcete tento postup provést s virtuálním počítači, který už běží v Azure, postupujte podle kroků popsaných v tomto článku.

Linux

Jak zachytit virtuální počítač s Linuxem a použít ho jako šablonu Resource Manageru

Přenos virtuálních počítačů a virtuálních pevných disků mezi místními počítači do Azure

vzhledem k tomu, že nahrávání imagí virtuálních počítačů a disků do Azure není možné prostřednictvím Azure Portal, je nutné použít rutiny Azure PowerShell nebo rozhraní příkazového řádku. Další možností je použití nástroje ' AzCopy '. Tento nástroj může kopírovat virtuální pevné disky mezi místními počítači a Azure (v obou směrech). Také může kopírovat virtuální pevné disky mezi oblastmi Azure. Další informace najdete v této dokumentaci ke stažení a použití AzCopy.

Třetí alternativou by bylo použití různých nástrojů orientovaných na grafické rozhraní (GUI) třetích stran. Ujistěte se však, že tyto nástroje podporují objekty blob stránky Azure. Pro náš účel musíme použít Azure Page BLOB Store (rozdíly jsou popsány v tématu Principy objektů blob bloku, doplňovacích objektů BLOB a objektů blob stránky. Nástroje, které poskytuje Azure, jsou také efektivní při komprimaci virtuálních počítačů a virtuálních pevných disků, které je potřeba nahrát. To je důležité, protože tato Efektivita komprese zkracuje dobu nahrávání (která se v závislosti na připojení k Internetu z místního zařízení a cíle Azure Deployment Target) omezuje. Je to spravedlivý předpoklad, že nahrání virtuálního počítače nebo virtuálního pevného disku z Evropského umístění do datacenter Azure Datacenter bude trvat déle než nahrávání stejných virtuálních počítačů a virtuálních pevných disků do evropských datových center Azure.

Nahrání virtuálního pevného disku z místního prostředí do Azure

Pokud chcete nahrát existující virtuální počítač nebo virtuální pevný disk z místní sítě, třeba virtuální počítač nebo virtuální pevný disk musí splňovat požadavky uvedené v kapitole Příprava na přesun virtuálního počítače z místního prostředí do Azure pomocí nezobecněného disku tohoto dokumentu.

Takový virtuální počítač se nemusí zobecnit a je možné ho nahrát ve stavu a tvar po vypnutí na straně místního prostředí. Totéž platí pro další virtuální pevné disky, které neobsahují žádný operační systém.

Nahrání virtuálního pevného disku a jeho zpřístupnění na disku Azure

V tomto případě chceme nahrát VHD, a to buď s operačním systémem, nebo bez něj, a připojit ho k virtuálnímu počítači jako datový disk nebo ho použít jako disk s operačním systémem. Toto je proces s více kroky

PowerShell

• přihlaste se k předplatnému pomocí Připojení – AzAccount
• Nastavte předplatné kontextu pomocí set-AzContext a parametrů SubscriptionId nebo Subscription – viz set-AzContext .
• Upload VHD pomocí add-AzVhd k účtu Azure Storage – viz Add-AzVhd .
• Volitelné Vytvoření spravovaného disku z VHD pomocí New-AzDisk – viz New-AzDisk
• Nastavte disk s operačním systémem nové konfigurace virtuálního počítače na VHD nebo spravovaný disk pomocí set-AzVMOSDisk – viz set-AzVMOSDisk .
• Vytvoření nového virtuálního počítače z konfigurace virtuálního počítače pomocí New-AzVM -See New-AzVM
• Přidání datového disku k novému virtuálnímu počítači pomocí Add-AzVMDataDisk -viz Add-AzVMDataDisk

Azure CLI

• Přihlaste se ke svému předplatnému pomocí AZ Login
• Vyberte své předplatné pomocí AZ Account set--Subscription <subscription name or id >
• Upload VHD příkazem az storage blob Upload – viz použití Azure CLI s Azure Storage.
• Volitelné Vytvoření spravovaného disku z disku VHD pomocí AZ disk Create -viz AZ disk.
• Vytvořte nový virtuální počítač, který určuje nahraný virtuální pevný disk nebo spravovaný disk jako disk s operačním systémem pomocí AZ VM Create a Parameter --Attach-OS-disk
• Přidání datového disku k novému virtuálnímu počítači pomocí AZ VM disk Attach a Parameter --New

Šablona

• Upload VHD pomocí powershellu nebo rozhraní příkazového řádku Azure
• Volitelné Vytvoření spravovaného disku z VHD pomocí PowerShellu, rozhraní příkazového řádku Azure nebo Azure Portal
• Nasaďte virtuální počítač se šablonou JSON odkazující na virtuální pevný disk, jak je znázorněno v tomto příkladu šablony JSON , nebo pomocí Managed disks, jak je znázorněno v tomto příkladu šablony JSON.

Nasazení image virtuálního počítače

Pokud chcete nahrát existující virtuální počítač nebo virtuální pevný disk z místní sítě, aby ho bylo možné použít jako image virtuálního počítače Azure, třeba virtuální počítač nebo virtuální pevný disk musí splňovat požadavky uvedené v kapitole Příprava pro nasazení virtuálního počítače pomocí image pro SAP tohoto dokumentu specifické pro zákazníka .

• použití nástroje sysprep při Windows nebo waagent zrušení zřízení na platformě Linux k generalizaci virtuálního počítače – viz technické informace o nástroji sysprep pro Windows nebo jak zachytit virtuální počítač se systémem linux pro použití jako šablona Správce prostředků pro linux.
• přihlaste se k předplatnému pomocí Připojení – AzAccount
• Nastavte předplatné kontextu pomocí set-AzContext a parametrů SubscriptionId nebo Subscription – viz set-AzContext .
• Upload VHD pomocí add-AzVhd k účtu Azure Storage – viz Add-AzVhd .
• Volitelné Vytvoření image spravovaného disku z VHD pomocí New-AzImage – viz New-AzImage
• Nastavte disk s operačním systémem nové konfigurace virtuálního počítače na
  • VHD s set-AzVMOSDisk-SourceImageUri-CreateOption fromImage -viz set-AzVMOSDisk
  • Sada imagí spravovaného disku – AzVMSourceImage – viz set-AzVMSourceImage
• Vytvoření nového virtuálního počítače z konfigurace virtuálního počítače pomocí New-AzVM -See New-AzVM

Azure CLI

• použití nástroje sysprep při Windows nebo waagent zrušení zřízení na platformě Linux k generalizaci virtuálního počítače – viz technické informace o nástroji sysprep pro Windows nebo jak zachytit virtuální počítač se systémem linux pro použití jako šablona Správce prostředků pro linux.
• Přihlaste se ke svému předplatnému pomocí AZ Login
• Vyberte své předplatné pomocí AZ Account set--Subscription <subscription name or id >
• Upload VHD příkazem az storage blob Upload – viz použití Azure CLI s Azure Storage.
• Volitelné Vytvořte image spravovaného disku z virtuálního pevného disku pomocí AZ image Create -viz AZ image.
• Vytvoření nového virtuálního počítače s nahraným virtuálním pevným diskem nebo imagí spravovaného disku jako disku s operačním systémem pomocí AZ VM Create a parametr --Image

Šablona

• použití nástroje sysprep při Windows nebo waagent zrušení zřízení na platformě Linux k generalizaci virtuálního počítače – viz technické informace o nástroji sysprep pro Windows nebo jak zachytit virtuální počítač se systémem linux pro použití jako šablona Správce prostředků pro linux.
• Upload VHD pomocí powershellu nebo rozhraní příkazového řádku Azure
• Volitelné Vytvoření bitové kopie spravovaného disku z VHD pomocí PowerShellu, rozhraní příkazového řádku Azure nebo Azure Portal
• Nasaďte virtuální počítač se šablonou JSON odkazující na VHD s imagí, jak je znázorněno v tomto příkladu šablony JSON , nebo pomocí Image spravovaného disku, jak je znázorněno v tomto příkladu šablony JSON.

Stahování VHD nebo Managed Disks do místního prostředí

Infrastruktura Azure jako služba není jednosměrná ulice, která dokáže nahrávat jenom virtuální pevné disky a systémy SAP. Systémy SAP můžete přesunout z Azure zpátky do místního světa.

V době stahování VHD nebo Managed Disks nejde aktivovat. I když stahujete disky, které jsou připojené k virtuálním počítačům, musí být virtuální počítač vypnutý a navrácený. Pokud chcete stáhnout jenom obsah databáze, v takovém případě by se měla použít k nastavení nového systému v místním prostředí, a pokud je to přijatelné během doby stahování a nastavení nového systému, který může systém v Azure stále fungovat, můžete se vyhnout dlouhému výpadku tím, že provedete komprimaci komprimované databáze na disk a stačí stáhnout tento disk místo toho, abyste stáhli operační systém. základní virtuální počítač.

PowerShell

• Stahuje se spravovaný disk. nejdřív potřebujete získat přístup k základnímu objektu BLOB spravovaného disku. Pak můžete původní objekt BLOB zkopírovat do nového účtu úložiště a stáhnout objekt BLOB z tohoto účtu úložiště.

  $access = Grant-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name> -Access Read -DurationInSecond 3600
  $key = (Get-AzStorageAccountKey -ResourceGroupName <resource group> -Name <storage account name>)[0].Value
  $destContext = (New-AzStorageContext -StorageAccountName <storage account name -StorageAccountKey $key)
  Start-AzStorageBlobCopy -AbsoluteUri $access.AccessSAS -DestContainer <container name> -DestBlob <blob name> -DestContext $destContext
  # Wait for blob copy to finish
  Get-AzStorageBlobCopyState -Container <container name> -Blob <blob name> -Context $destContext
  Save-AzVhd -SourceUri <blob in new storage account> -LocalFilePath <local file path> -StorageKey $key
  # Wait for download to finish
  Revoke-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name>
  

• Stažení virtuálního pevného disku po zastavení systému SAP a vypnutí virtuálního počítače můžete použít rutinu PowerShellu Save-AzVhd na místním cíli a stáhnout disky VHD zpátky do místního světa. abyste to mohli udělat, potřebujete adresu URL virtuálního pevného disku, který najdete v části "úložiště" Azure Portal (musí přejít na účet Storage a kontejneru úložiště, ve kterém byl virtuální pevný disk vytvořen), a potřebujete znát, kam se má vhd zkopírovat.

  Pak můžete použít příkaz definováním parametru SourceUri jako adresy URL disku VHD ke stažení a LocalFilePath jako fyzického umístění virtuálního pevného disku (včetně jeho názvu). Příkaz by mohl vypadat takto:

  Save-AzVhd -ResourceGroupName <resource group name of storage account> -SourceUri http://<storage account name>.blob.core.windows.net/<container name>/sapidedata.vhd -LocalFilePath E:\Azure_downloads\sapidesdata.vhd
  

  Další podrobnosti o rutině Save-AzVhd najdete v tématu Save-AzVhd.

Azure CLI

• Stahuje se spravovaný disk. nejdřív potřebujete získat přístup k základnímu objektu BLOB spravovaného disku. Pak můžete původní objekt BLOB zkopírovat do nového účtu úložiště a stáhnout objekt BLOB z tohoto účtu úložiště.

  az disk grant-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --duration-in-seconds 3600
  az storage blob download --sas-token "<sas token>" --account-name <account name> --container-name <container name> --name <blob name> --file <local file>
  az disk revoke-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>"
  

• Stažení virtuálního pevného disku po zastavení systému SAP a vypnutí virtuálního počítače můžete použít příkaz Azure CLI _azure storage blob download_ na místním cíli a stáhnout tak disky VHD zpátky do místního světa. abyste to mohli udělat, potřebujete název a kontejner VHD, který najdete v sekci Storage Azure Portal (musíte přejít na účet Storage a kontejneru úložiště, ve kterém byl virtuální pevný disk vytvořen), a potřebujete znát, kam se má vhd zkopírovat.

  Pak můžete použít příkaz definováním objektů BLOB parametrů a kontejneru VHD ke stažení a cíle jako fyzického cílového umístění virtuálního pevného disku (včetně jeho názvu). Příkaz by mohl vypadat takto:

  az storage blob download --name <name of the VHD to download> --container-name <container of the VHD to download> --account-name <storage account name of the VHD to download> --account-key <storage account key> --file <destination of the VHD to download>
  

Přenos virtuálních počítačů a disků v rámci Azure

Kopírování systémů SAP v Azure

Systém SAP nebo dokonce vyhrazený server DBMS, který podporuje aplikační vrstvu SAP, se nejspíš skládá z několika disků, které obsahují buď operační systém, binární soubory nebo data a soubory protokolů databáze SAP. Funkce Azure pro kopírování disků ani funkce Azure pro ukládání disků na místní disk má mechanismus synchronizace, který se konzistentně zaznamená na více discích. Proto se stav kopírovaných nebo uložených disků i v případě, že jsou připojené ke stejnému virtuálnímu počítači, liší. To znamená, že v konkrétním případě mají různá data a soubory protokolu obsažené na různých discích, databáze na konci by byla nekonzistentní.

Závěr: aby bylo možné kopírovat nebo ukládat disky, které jsou součástí konfigurace systému SAP, je nutné zastavit systém SAP a také vypnout nasazený virtuální počítač. Jenom potom můžete zkopírovat nebo stáhnout sadu disků, abyste buď vytvořili kopii systému SAP v Azure, nebo v místním prostředí.

datové disky se dají ukládat jako soubory VHD v účtu Azure Storage a dají se přímo připojit k virtuálnímu počítači nebo použít jako image. V takovém případě se virtuální pevný disk před připojením k virtuálnímu počítači zkopíruje do jiného umístění. Úplný název souboru VHD v Azure musí být v rámci Azure jedinečný. Jak už bylo zmíněno dříve, název je druh názvu se třemi částmi, který vypadá nějak takto:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Datové disky je také možné Managed Disks. V takovém případě se ke vytvoření nového spravovaného disku před připojením k virtuálnímu počítači používá spravovaný disk. Název spravovaného disku musí být v rámci skupiny prostředků jedinečný.

PowerShell

pomocí rutin Azure PowerShell můžete zkopírovat VHD, jak je znázorněno v tomto článku. Pokud chcete vytvořit nový spravovaný disk, použijte New-AzDiskConfig a New-AzDisk, jak je znázorněno v následujícím příkladu.

$config = New-AzDiskConfig -CreateOption Copy -SourceUri "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" -Location <location>
New-AzDisk -ResourceGroupName <resource group name> -DiskName <disk name> -Disk $config

Azure CLI

Ke zkopírování virtuálního pevného disku můžete použít Azure CLI. Pokud chcete vytvořit nový spravovaný disk, použijte příkaz az disk create, jak je znázorněno v následujícím příkladu.

az disk create --source "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --name <disk name> --resource-group <resource group name> --location <location>

Azure Storage nástroje

• https://storageexplorer.com/

Professional edice průzkumníků Azure Storage najdete tady:

• https://www.cerebrata.com/
• https://clumsyleaf.com/products/cloudxplorer

Kopie samotného virtuálního pevného disku v rámci účtu úložiště je proces, který trvá jen několik sekund (podobně jako hardware sítě SAN vytváří snímky s opožděnou kopií a kopírováním při zápisu). Jakmile budete mít kopii souboru VHD, můžete ho připojit k virtuálnímu počítači nebo ho použít jako image k připojení kopií virtuálního pevného disku k virtuálním počítačům.

PowerShell

# attach a vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -VhdUri <path to vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -ManagedDiskId <managed disk id> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a copy of the vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name <disk name> -VhdUri <new path of vhd> -SourceImageUri <path to image vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption fromImage
$vm | Update-AzVM

# attach a copy of the managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$diskConfig = New-AzDiskConfig -Location $vm.Location -CreateOption Copy -SourceUri <source managed disk id>
$disk = New-AzDisk -DiskName <disk name> -Disk $diskConfig -ResourceGroupName <resource group name>
$vm = Add-AzVMDataDisk -VM $vm -Caching <caching option> -Lun <lun, for example 0> -CreateOption attach -ManagedDiskId $disk.Id
$vm | Update-AzVM

Azure CLI

# attach a vhd to a vm
az vm unmanaged-disk attach --resource-group <resource group name> --vm-name <vm name> --vhd-uri <path to vhd>

# attach a managed disk to a vm
az vm disk attach --resource-group <resource group name> --vm-name <vm name> --disk <managed disk id>

# attach a copy of the vhd to a vm
# this scenario is currently not possible with Azure CLI. A workaround is to manually copy the vhd to the destination.

# attach a copy of a managed disk to a vm
az disk create --name <new disk name> --resource-group <resource group name> --location <location of target virtual machine> --source <source managed disk id>
az vm disk attach --disk <new disk name or managed disk id> --resource-group <resource group name> --vm-name <vm name> --caching <caching option> --lun <lun, for example 0>

Kopírování disků mezi Azure Storage účty

Tuto úlohu nelze provést v Azure Portal. Můžete použít Azure PowerShell, Azure CLI nebo prohlížeč úložiště třetí strany. Rutiny PowerShellu nebo příkazy rozhraní příkazového řádku mohou vytvářet a spravovat objekty blob, které zahrnují možnost asynchronně kopírovat objekty blob mezi účty Storage a napříč oblastmi v rámci předplatného Azure.

PowerShell

Virtuální disky můžete také kopírovat mezi předplatným. Další informace najdete v tomto článku.

Základní tok logiky rutiny PowerShellu vypadá takhle:

• Vytvoření kontextu účtu úložiště pro zdrojový účet úložiště pomocí příkazu New-AzStorageContext – viz New-AzStorageContext
• Vytvoření kontextu účtu úložiště pro cílový účet úložiště pomocí příkazu New-AzStorageContext – viz New-AzStorageContext
• Spusťte kopírování pomocí .

Start-AzStorageBlobCopy -SrcBlob <source blob name> -SrcContainer <source container name> -SrcContext <variable containing context of source storage account> -DestBlob <target blob name> -DestContainer <target container name> -DestContext <variable containing context of target storage account>

• Zkontrolujte stav kopírování ve smyčce pomocí .

Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>

• Připojte nový virtuální pevný disk k virtuálnímu počítači, jak je popsáno výše.

Příklady najdete v tomto článku.

Azure CLI

• Spusťte kopírování pomocí .

az storage blob copy start --source-blob <source blob name> --source-container <source container name> --source-account-name <source storage account name> --source-account-key <source storage account key> --destination-container <target container name> --destination-blob <target blob name> --account-name <target storage account name> --account-key <target storage account name>

• Zkontrolujte stav, jestli je kopie stále ve smyčce.

az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>

• Připojte nový virtuální pevný disk k virtuálnímu počítači, jak je popsáno výše.

Zpracování disků

Struktura virtuálních a diskových disků pro nasazení SAP

V ideálním případě by mělo být zpracování struktury virtuálního počítače a přidružených disků jednoduché. V místních instalacích vyvinuli zákazníci mnoho způsobů strukturování instalace serveru.

• Jeden základní disk, který obsahuje operační systém a všechny binární soubory DBMS nebo SAP. Od března 2015 může mít tento disk velikost až 1 TB místo dřívějších omezení, která ho omezovala na 127 GB.
• Jeden nebo více disků, které obsahují soubor protokolu DBMS databáze SAP a soubor protokolu v oblasti dočasného úložiště DBMS (pokud to DBMS podporuje). Pokud jsou požadavky na IOPS protokolu databáze vysoké, musíte prokládané disky, abyste dosáhli požadovaného objemu IOPS.
• Počet disků obsahujících jeden nebo dva databázové soubory databáze SAP a také dočasné datové soubory DBMS (pokud to DBMS podporuje).

Windows

U mnoha zákazníků jsme viděli konfigurace, kdy například binární soubory SAP a DBMS nebyly v adresáři c:\ nainstalované. disk s nainstalovaným operačním systémem. K tomu došlo z různých důvodů, ale když jsme se vrátili ke kořeni, obvykle to bylo kvůli tomu, že disky byly malé a upgrady operačního systému potřebovaly další místo před 10–15 lety. Obě podmínky se v těchto dnech už příliš často neakusují. Today the c:\ disk lze mapovat na disky nebo virtuální počítače s velkými svazky. Aby nasazení byla ve své struktuře jednoduchá, doporučujeme postupovat podle následujícího vzoru nasazení pro systémy SAP NetWeaver v Azure.

Stránkovací Windows operačního systému by měl být na jednotce D: (trvalý disk).

Linux

Linuxový stránkovací soubor umístěte do umístění /mnt /mnt/resource v Linuxu, jak je popsáno v tomto článku. Odkládací soubor je možné nakonfigurovat v konfiguračním souboru linuxového agenta /etc/waagent.conf. Přidejte nebo změňte následující nastavení:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Pokud chcete aktivovat změny, musíte restartovat agenta pro Linux pomocí .

sudo service waagent restart

Další podrobnosti 1597355 doporučené velikosti odkládacího souboru najdete v poznámkách k SAP.

Počet disků použitých pro datové soubory DBMS a typ disků Azure Storage na kterých jsou tyto disky hostované, by měly být určeny požadavky na IOPS a požadovanou latencí. Přesné kvóty jsou popsané v tomto článku (Linux) a v tomto článku (Windows).

Zkušenosti s nasazeními SAP za poslední dva roky nás naučily některé lekce, které můžeme shrnout takto:

• Provoz IOPS do různých datových souborů není vždy stejný, protože stávající systémy zákazníků můžou mít datové soubory s různou velikostí, které představují jejich databáze SAP. V důsledku toho se ukázalo, že je lepší použít konfiguraci RAID na více discích k umístění datových souborů LUN, které jsou z nich vytesané. Došlo k situacím, zejména u služby Azure Standard Storage, kdy rychlost IOPS oproti transakčnímu protokolu DBMS načítá kvótu jednoho disku. V takových scénářích se doporučuje Premium Storage nebo alternativně agregovat více standardních disků Storage se softwarovým pruhem.

Windows

• Osvědčené postupy z hlediska výkonu pro SQL Server na Azure Virtual Machines

Linux

• Konfigurace softwarového pole RAID v Linuxu
• Konfigurace LVM na virtuálním počítači s Linuxem v Azure

• Premium Storage výrazně vyšší výkon, zejména u důležitých zápisů do transakčního protokolu. U scénářů SAP, u které se očekává, že budou dodávat produkční prostředí, jako je výkon, se důrazně doporučuje použít VM-Series, které mohou využívat Azure Premium Storage.

Mějte na paměti, že disk, který obsahuje operační systém, a jak doporučujeme, binární soubory SAP a databáze (základní virtuální počítač) už nejsou omezené na 127 GB. Teď může mít velikost až 1 TB. Mělo by to být dost místa k tomu, aby se uchová všechny potřebné soubory, například protokoly dávkových úloh SAP.

Další návrhy a další podrobnosti, konkrétně pro virtuální počítače DBMS, najdete v průvodci nasazením DBMS.

Zpracování disků

Ve většině scénářů je k nasazení databáze SAP do virtuálního počítače potřeba vytvořit další disky. O aspektech počtu disků jsme mluvili v kapitole Struktura virtuálních počítačů a disků pro nasazení SAP v tomto dokumentu. Virtuální Azure Portal umožňuje připojit a odpojit disky po nasazení základního virtuálního počítače. Disky je možné připojit nebo odpojit, když je virtuální počítač v provozu i když je zastavený. Při připojování disku nástroj Azure Portal připojení prázdného disku nebo existujícího disku, který v tuto chvíli není připojený k jinému virtuálnímu počítače.

Poznámka: Disky je možné v daném okamžiku připojit pouze k jednomu virtuálnímu počítači.

Během nasazování nového virtuálního počítače se můžete rozhodnout, jestli chcete použít Spravované disky nebo umístit disky na Azure Storage účty. Pokud chcete použít Premium Storage, doporučujeme použít Spravované disky.

Dále se musíte rozhodnout, jestli chcete vytvořit nový a prázdný disk, nebo jestli chcete vybrat existující disk, který jste předtím nahráli a který by se měl připojit k virtuálnímu počítače.

DŮLEŽITÉ: NECHCETE používat hostování Ukládání do mezipaměti s Azure Standard Storage. Předvolbu Mezipaměti hostitele byste měli ponechat na výchozích hodnotách NONE. V případě azure Premium Storage byste měli funkci Čtení povolit Ukládání do mezipaměti, pokud se charakteristiky V/V většinou čtou jako typický V/V provoz datových souborů databáze. V případě souboru transakčního protokolu databáze se nedoporučuje ukládání do mezipaměti.

Windows

Postup připojení datového disku v Azure Portal

Pokud jsou disky připojené, musíte se přihlásit k virtuálnímu počítači a otevřít Windows Disk Manager. Pokud automatické připojení není povolené podle doporučení v kapitole Nastavení automatického připojení pro připojenédisky, musí se nově připojený svazek online a inicializovat.

Linux

Pokud jsou disky připojené, musíte se přihlásit k virtuálnímu počítači a inicializovat disky, jak je popsáno v tomto článku.

Pokud je nový disk prázdný, musíte ho také naformátovat. Pro formátování, zejména pro soubory protokolů a dat DBMS, platí stejná doporučení jako pro nasazení DBMS na hojná počítače.

Účet Azure Storage neposkytuje nekonečné prostředky z hlediska objemu vstupně-výstupních operací, IOPS a objemu dat. To obvykle nejvíce ovlivňuje virtuální počítače DBMS. pro každý virtuální počítač může být nejvhodnější použít samostatný účet Storage, pokud máte více virtuálních počítačů s vysokým počtem vstupně-výstupních operací k nasazení, aby bylo možné zůstat v rámci limitu Azure Storageho svazku účtu. v opačném případě potřebujete zjistit, jak můžete vyrovnávat tyto virtuální počítače mezi různými Storage účty, aniž byste museli zastavovat limit každého účtu s jedním Storage. Další podrobnosti jsou popsány v Průvodci nasazením systému DBMS. Měli byste taky zachovat tato omezení pro virtuální počítače s čistým aplikačním serverem SAP nebo jiné virtuální počítače, což může vyžadovat další virtuální pevné disky. Tato omezení neplatí při použití spravovaného disku. pokud plánujete použít Premium Storage, doporučujeme použít spravovaný Disk.

dalším tématem, které je relevantní pro účty Storage, je to, jestli se virtuální pevné disky v účtu Storage dostávají geograficky replikované. geografická replikace je povolená nebo zakázaná na úrovni účtu Storage, a ne na úrovni virtuálního počítače. pokud je geografická replikace povolená, virtuální pevné disky v rámci Storage účtu se replikují do jiného datového centra Azure v rámci stejné oblasti. Před tím, než se rozhodnete, je třeba zvážit následující omezení:

Geografická replikace Azure funguje lokálně na každém virtuálním pevném disku virtuálního počítače a nereplikuje vstupně-výstupních prostředí v chronologickém pořadí napříč více virtuálními pevnými disky ve virtuálním počítači. Proto se virtuální pevný disk, který představuje základní virtuální počítač, a všechny další virtuální pevné disky připojené k virtuálnímu počítači replikují nezávisle na sobě. To znamená, že nedochází k žádné synchronizaci mezi změnami v různých virtuálních pevných discích. Skutečnost, že I/o se replikují nezávisle na pořadí, ve kterém jsou zapsána, znamená, že geografická replikace není hodnotou pro databázové servery, které mají své databáze distribuovány přes více virtuálních pevných disků. Kromě systému DBMS můžou existovat také další aplikace, ve kterých procesy napisují nebo zpracovávají data na různých virtuálních pevných discích a tam, kde je důležité zachovat pořadí změn. V takovém případě by se geografická replikace v Azure neměla povolit. závisí na tom, jestli potřebujete nebo chcete geografickou replikaci pro sadu virtuálních počítačů, ale ne pro jinou sadu. virtuální počítače a jejich související virtuální pevné disky je už možné kategorizovat do různých Storage účtů, které mají povolenou nebo zakázanou geografickou replikaci.

Nastavení automatického připojení pro připojené disky

Windows

U virtuálních počítačů, které se vytvářejí z vlastních imagí nebo disků, je nutné zaškrtnout a případně nastavit parametr automount. Nastavením tohoto parametru povolíte virtuálnímu počítači po restartování nebo opětovném nasazení v Azure a automaticky připojí připojené nebo připojené jednotky. Parametr je nastaven pro bitové kopie poskytnuté společností Microsoft v Azure Marketplace.

Pokud chcete nastavit automount, Projděte si dokumentaci ke spustitelnému souboru příkazového řádku diskpart.exe tady:

• Možnosti Command-Line DiskPart
• Automaticky připojit

okno příkazového řádku Windows by se mělo otevřít jako správce.

pokud jsou disky připojené, musíte se přihlásit k virtuálnímu počítači, abyste mohli otevřít správce Windows disků. Pokud není v kapitole Nastavení automatického připojení pro připojené diskypovolené automount jako doporučené, musí být nově připojený svazek >online a inicializovaný.

Linux

Je potřeba inicializovat nově připojený prázdný disk, jak je popsáno v tomto článku. Také je potřeba přidat do adresáři/etc/fstab. nové disky.

Konečné nasazení

Poslední nasazení a přesný postup, zejména nasazení rozšíření Azure pro SAP, najdete v Průvodci nasazením.

Přístup k systémům SAP běžícím v rámci virtuálních počítačů Azure

Pro scénáře, kdy se chcete připojit k těmto systémům SAP na veřejném Internetu pomocí grafického uživatelského rozhraní SAP, je nutné použít následující postupy.

Později v dokumentu se podíváme na další hlavní scénář, který se připojuje k systémům SAP v různých nasazeních, která mají připojení typu Site-to-Site (tunel VPN) nebo připojení Azure ExpressRoute mezi místními systémy a systémy Azure.

Vzdálený přístup k systémům SAP

V Azure Resource Manager neexistují žádné výchozí koncové body, které by již v bývalém modelu Classic nevypadaly. Všechny porty Azure Resource Manager virtuálního počítače jsou otevřené, dokud:

1. Pro podsíť nebo síťové rozhraní není definovaná žádná skupina zabezpečení sítě. Síťový provoz do virtuálních počítačů Azure je možné zabezpečit prostřednictvím volání "skupiny zabezpečení sítě". Další informace najdete v článku Skupina zabezpečení sítě.
2. pro síťové rozhraní není definovaná žádná Azure Load Balancer.

Podívejte se na rozdíl architektury mezi klasickým modelem a ARM, jak je popsáno v tomto článku.

Konfigurace systému SAP a připojení grafického uživatelského rozhraní SAP přes Internet

V tomto článku najdete popis podrobností k tomuto tématu: připojení k grafickému rozhraní SAP se zavřelo při připojování k systému SAP v Azure .

změna Nastavení brány Firewall na virtuálním počítači

Je možné, že bude nutné nakonfigurovat bránu firewall na virtuálních počítačích, aby umožňovala příchozí provoz do systému SAP.

Windows

ve výchozím nastavení je brána Firewall Windows v rámci virtuálního počítače nasazeného v Azure zapnutá. Nyní je třeba umožnit otevření portu SAP, jinak se grafické uživatelské rozhraní SAP nebude moci připojit. Použijte následující postup:

• otevřete ovládací panely \ systém a zabezpečení \ Windows Firewall pro pokročilé Nastavení.
• Nyní klikněte pravým tlačítkem na příchozí pravidla a zvolte nové pravidlo.
• V následujícím průvodci se zvolilo vytvoření nového pravidla portu .
• V dalším kroku průvodce ponechte nastavení na TCP a zadejte číslo portu, který chcete otevřít. Vzhledem k tomu, že naše ID instance SAP je 00, trvala 3200. Pokud má vaše instance jiné číslo instance, je nutné otevřít port, který jste definovali dříve v závislosti na číslu instance.
• V další části Průvodce musíte opustit položku Povolení připojení zaškrtnuto.
• V dalším kroku průvodce potřebujete definovat, jestli se pravidlo vztahuje k doméně, soukromé a veřejné síti. Podle potřeby je upravte. Pokud se ale připojujete pomocí grafického uživatelského rozhraní SAP z vnějšku přes veřejnou síť, musíte použít pravidlo pro veřejnou síť.
• V posledním kroku průvodce pojmenujte pravidlo a uložte ho stisknutím tlačítka Dokončit.

Pravidlo se okamžitě projeví.

Linux

Image Linux v Azure Marketplace ve výchozím nastavení nepovolí bránu firewall softwaru iptables a připojení k vašemu systému SAP by mělo fungovat. Pokud jste povolili softwaru iptables nebo jinou bránu firewall, přečtěte si dokumentaci k softwaru iptables nebo použitou bránu firewall, která povolí příchozí provoz TCP na portu 32xx (kde XX je systémové číslo vašeho systému SAP).

Doporučení zabezpečení

Grafické rozhraní SAP se nepřipojuje okamžitě k žádné instanci SAP (port 32xx), která je spuštěná, ale nejdřív se připojuje přes port otevřený k procesu serveru zpráv SAP (port 36xx). V minulosti byl stejný port použit serverem zpráv pro interní komunikaci s instancemi aplikace. Aby místní aplikační servery nechtěně komunikovaly se serverem zpráv v Azure, je možné změnit interní komunikační porty. Důrazně doporučujeme změnit interní komunikaci mezi serverem zpráv SAP a jeho instancemi aplikace na jiné číslo portu v systémech, které byly naklonovány z místních systémů, jako je klon vývoje pro testování projektu atd. Dá se to udělat s výchozím parametrem profilu:

rdisp/msserv_internal

jak je popsáno v Nastavení zabezpečení pro Server zpráv SAP

Jeden virtuální počítač se scénářem Ukázky/školení SAP NetWeaver

V tomto scénáři implementujeme Typický scénář školení/ukázkový systém, ve kterém je kompletní scénář školení/ukázky obsažený v jednom virtuálním počítači. Předpokládáme, že se nasazení provádí prostřednictvím šablon imagí virtuálních počítačů. Předpokládáme také, že více těchto virtuálních počítačů ukázek a školení je potřeba nasadit s virtuálními počítači se stejným názvem. Všechny školicí systémy nemají připojení k místním prostředkům a jsou naopak pro hybridní nasazení.

Předpokladem je, že jste vytvořili image virtuálního počítače, jak je popsáno v některých částech kapitoly Příprava virtuálních počítačů pomocí SAP pro Azure v tomto dokumentu.

Sekvence událostí pro implementaci scénáře vypadá takto:

PowerShell

• Vytvořit novou skupinu prostředků pro každé školení/ukázku na šířku

$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"

• Pokud nechcete používat Managed Disks, vytvořte nový účet úložiště.

$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"

• Vytvořte novou virtuální síť pro každé školení nebo ukázku na šířku, abyste mohli povolit použití stejného názvu hostitele a IP adresy. Virtuální síť je chráněná skupinou zabezpečení sítě, která umožňuje přístup ke vzdálené ploše a portu 22 pro SSH jenom přes přenosy přes port 3389.

# Create a new Virtual Network
$rdpRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGRDP -Protocol * -SourcePortRange * -DestinationPortRange 3389 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 100
$sshRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGSSH -Protocol * -SourcePortRange * -DestinationPortRange 22 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 101
$nsg = New-AzNetworkSecurityGroup -Name SAPERPDemoNSG -ResourceGroupName $rgName -Location  "North Europe" -SecurityRules $rdpRule,$sshRule

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix  10.0.1.0/24 -NetworkSecurityGroup $nsg
$vnet = New-AzVirtualNetwork -Name SAPERPDemoVNet -ResourceGroupName $rgName -Location "North Europe"  -AddressPrefix 10.0.1.0/24 -Subnet $subnetConfig

• Vytvořte novou veřejnou IP adresu, kterou je možné použít pro přístup k virtuálnímu počítači z Internetu.

# Create a public IP address with a DNS name
$pip = New-AzPublicIpAddress -Name SAPERPDemoPIP -ResourceGroupName $rgName -Location "North Europe" -DomainNameLabel $rgName.ToLower() -AllocationMethod Dynamic

• Vytvořit nové síťové rozhraní pro virtuální počítač

# Create a new Network Interface
$nic = New-AzNetworkInterface -Name SAPERPDemoNIC -ResourceGroupName $rgName -Location "North Europe" -Subnet $vnet.Subnets[0] -PublicIpAddress $pip

• Vytvoří virtuální počítač. Pro tento scénář bude mít každý virtuální počítač stejný název. Identifikátor SID SAP instancí SAP NetWeaver v těchto virtuálních počítačích bude stejný i nadále. V rámci skupiny prostředků Azure musí být název virtuálního počítače jedinečný, ale v různých skupinách prostředků Azure můžete spustit virtuální počítače se stejným názvem. výchozí účet správce Windows nebo root pro Linux není platný. Proto je nutné definovat nové uživatelské jméno správce společně s heslem. Velikost virtuálního počítače musí být taky definovaná.

#####
# Create a new virtual machine with an official image from the Azure Marketplace
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

# select image
$vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2012-R2-Datacenter" -Version "latest"
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "SUSE" -Offer "SLES-SAP" -Skus "12-SP1" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "RedHat" -Offer "RHEL" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "Oracle" -Offer "Oracle-Linux" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$diskName="osfromimage"
$osDiskUri=$account.PrimaryEndpoints.Blob.ToString() + "vhds/" + $diskName  + ".vhd"

$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Windows
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Linux
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a Managed Disk Image
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMSourceImage -VM $vmconfig -Id <Id of Managed Disk Image>
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

• Volitelně přidejte další disky a obnovte potřebný obsah. Všechny názvy objektů BLOB (adresy URL objektů BLOB) musí být v rámci Azure jedinečné.

# Optional: Attach additional VHD data disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
$dataDiskUri = $account.PrimaryEndpoints.Blob.ToString() + "vhds/datadisk.vhd"
Add-AzVMDataDisk -VM $vm -Name datadisk -VhdUri $dataDiskUri -DiskSizeInGB 1023 -CreateOption empty | Update-AzVM

# Optional: Attach additional Managed Disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
Add-AzVMDataDisk -VM $vm -Name datadisk -DiskSizeInGB 1023 -CreateOption empty -Lun 0 | Update-AzVM

Rozhraní příkazového řádku

V systému Linux lze použít následující vzorový kód. v případě Windows použijte prostředí PowerShell, jak je popsáno výše, nebo v příkladu přizpůsobte použití% rgName% místo $rgName a nastavení proměnné prostředí pomocí Windows sady příkazů.

• Vytvořit novou skupinu prostředků pro každé školení/ukázku na šířku

rgName=SAPERPDemo1
rgNameLower=saperpdemo1
az group create --name $rgName --location "North Europe"

• Vytvoření nového účtu úložiště

az storage account create --resource-group $rgName --location "North Europe" --kind Storage --sku Standard_LRS --name $rgNameLower

• Vytvořte novou virtuální síť pro každé školení nebo ukázku na šířku, abyste mohli povolit použití stejného názvu hostitele a IP adresy. Virtuální síť je chráněná skupinou zabezpečení sítě, která umožňuje přístup ke vzdálené ploše a portu 22 pro SSH jenom přes přenosy přes port 3389.

az network nsg create --resource-group $rgName --location "North Europe" --name SAPERPDemoNSG
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGRDP --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 3389 --access Allow --priority 100 --direction Inbound
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGSSH --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 22 --access Allow --priority 101 --direction Inbound

az network vnet create --resource-group $rgName --name SAPERPDemoVNet --location "North Europe" --address-prefixes 10.0.1.0/24
az network vnet subnet create --resource-group $rgName --vnet-name SAPERPDemoVNet --name Subnet1 --address-prefix 10.0.1.0/24 --network-security-group SAPERPDemoNSG

• Vytvořte novou veřejnou IP adresu, kterou je možné použít pro přístup k virtuálnímu počítači z Internetu.

az network public-ip create --resource-group $rgName --name SAPERPDemoPIP --location "North Europe" --dns-name $rgNameLower --allocation-method Dynamic

• Vytvořit nové síťové rozhraní pro virtuální počítač

az network nic create --resource-group $rgName --location "North Europe" --name SAPERPDemoNIC --public-ip-address SAPERPDemoPIP --subnet Subnet1 --vnet-name SAPERPDemoVNet

• Vytvoří virtuální počítač. Pro tento scénář bude mít každý virtuální počítač stejný název. Identifikátor SID SAP instancí SAP NetWeaver v těchto virtuálních počítačích bude stejný i nadále. V rámci skupiny prostředků Azure musí být název virtuálního počítače jedinečný, ale v různých skupinách prostředků Azure můžete spustit virtuální počítače se stejným názvem. výchozí účet správce Windows nebo root pro Linux není platný. Proto je nutné definovat nové uživatelské jméno správce společně s heslem. Velikost virtuálního počítače musí být taky definovaná.

#####
# Create virtual machines using storage accounts
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password

#####
# Create virtual machines using Managed Disks
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Windows --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Linux --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd> --authentication-type password

#####
# Create a new virtual machine with a Managed Disk Image
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id> --authentication-type password

• Volitelně přidejte další disky a obnovte potřebný obsah. Všechny názvy objektů BLOB (adresy URL objektů BLOB) musí být v rámci Azure jedinečné.

# Optional: Attach additional VHD data disks
az vm unmanaged-disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --vhd-uri https://$rgNameLower.blob.core.windows.net/vhds/data.vhd  --new

# Optional: Attach additional Managed Disks
az vm disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --disk datadisk --new

Template (Šablona)

Ukázkové šablony můžete použít v úložišti Azure-Rychlé šablony na GitHub.

• Jednoduchý virtuální počítač se systémem Linux
• jednoduchý Windows virtuální počítač
• Virtuální počítač z Image

Implementace sady virtuálních počítačů, které komunikují v rámci Azure

Tento nehybridní scénář je typický scénář pro školení a demonstrační účely, kde je software představující scénář ukázky/školení rozložený na více virtuálních počítačů. Různé komponenty nainstalované v různých virtuálních počítačích potřebují vzájemně komunikovat. V tomto scénáři se v takovém případě nevyžaduje žádná místní síťová komunikace ani scénář mezi místními sítěmi.

Tento scénář je rozšířením instalace popsané v kapitole jeden virtuální počítač se scénářem Ukázky/školení SAP NetWeaver v tomto dokumentu. V takovém případě se do existující skupiny prostředků přidá víc virtuálních počítačů. V následujícím příkladu se školení na šířku skládá z virtuálního počítače SAP ASCS/SCS, virtuálního počítače se systémem DBMS a instance aplikačního serveru SAP.

Než sestavíte tento scénář, musíte se zamyslet nad základními nastaveními, která už ve scénáři využijete.

Skupina prostředků a pojmenování virtuálních počítačů

Všechny názvy skupin prostředků musí být jedinečné. Vytvořte si vlastní schéma pojmenování prostředků, jako je například <rg-name> přípona.

Název virtuálního počítače musí být v rámci skupiny prostředků jedinečný.

Nastavení sítě pro komunikaci mezi různými virtuálními počítači

Aby se zabránilo kolizím názvů pomocí klonů se stejným školením nebo demonstrační krajinou, je třeba vytvořit Virtual Network Azure pro všechny na šířku. Překlad názvů DNS bude poskytovat Azure, nebo můžete nakonfigurovat vlastní server DNS mimo Azure (tady se nezabývá popsáním). V tomto scénáři nemůžeme nakonfigurovat vlastní DNS. U všech virtuálních počítačů v rámci jedné služby Azure Virtual Network bude povolená komunikace prostřednictvím názvů hostitelů.

Důvody pro oddělení školení nebo ukázkové krajiny pro virtuální sítě a nikoli jenom skupiny prostředků:

• Nastavení SAP na šířku vyžaduje vlastní AD/OpenLDAP a server domény musí být součástí každé z krajiny.
• Nastavení SAP na šířku jako má komponenty, které potřebují pracovat s pevnými IP adresami.

Další podrobnosti o virtuálních sítích Azure a jejich definování najdete v tomto článku.

Nasazení virtuálních počítačů SAP s připojením k podnikové síti (mezi místními sítěmi)

Spustíte prostředí SAP na šířku a chcete rozdělit nasazení mezi holé servery DBMS, místní virtualizovaná prostředí pro vrstvy aplikací a menší 2 úrovně nakonfigurované systémy SAP a Azure IaaS. Základním předpokladem je, že systémy SAP v rámci jedné technologie SAP na šířku potřebují vzájemně komunikovat a s mnoha dalšími softwarovými součástmi, které jsou nasazené ve společnosti, nezávisle na jejich formuláři nasazení. Pro koncového uživatele, který se připojuje s grafickým rozhraním SAP nebo jinými rozhraními, by neměly být zavedeny žádné rozdíly ve formuláři nasazení. Tyto podmínky můžou být splněné jenom v případě, že máme místní služby Active Directory/OpenLDAP a DNS, které se rozšiřují na systémy Azure prostřednictvím připojení typu Site-to-site/Multi-Site nebo privátní připojení, jako je Azure ExpressRoute.

Scénář technologie SAP na šířku

Scénář mezi různými místy nebo hybridním scénářem může být zhruba popsaný jako na obrázku níže:

Minimálním požadavkem je použití zabezpečených komunikačních protokolů, jako je protokol SSL/TLS pro přístup z prohlížeče nebo připojení k síti VPN pro přístup k systému do služeb Azure. Předpokladem je, že společnosti zpracovávají připojení VPN mezi podnikovou sítí a Azure odlišně. Některé společnosti můžou prázdné porty otevřít na všech těchto portech. Některé jiné společnosti můžou být přesné v tom, které porty potřebují otevřít atd.

V tabulce níže jsou uvedeny typické komunikační porty SAP. V podstatě stačí otevřít port brány SAP.

*) NN = číslo instance SAP

• *) SID = SAP-System-ID

Podrobnější informace o portech vyžadovaných pro různé produkty nebo služby SAP podle produktů SAP najdete tady https://scn.sap.com/docs/DOC-17124 . V tomto dokumentu byste měli být schopni otevřít vyhrazené porty v zařízení VPN, které jsou nezbytné pro konkrétní produkty a scénáře SAP.

Další bezpečnostní opatření při nasazení virtuálních počítačů v takovém scénáři by mohla být vytvoření skupiny zabezpečení sítě pro definování pravidel přístupu.

Tisk na tiskárně místní sítě z instance SAP v Azure

Tisk přes protokol TCP/IP ve scénáři mezi místními sítěmi

Nastavení místních tiskáren založených na protokolu TCP/IP na VIRTUÁLNÍm počítači Azure je stejné jako ve vaší podnikové síti, a to za předpokladu, že máte navázáno tunelování VPN typu Site-to-site nebo ExpressRoute připojení.

Windows

Použijte následující postup:

• Některé síťové tiskárny se dodávají s Průvodcem konfigurací, který usnadňuje nastavení tiskárny ve virtuálním počítači Azure. Pokud se s tiskárnou nedistribuuje žádný software průvodce, ručním způsobem nastavení tiskárny je vytvoření nového portu tiskárny TCP/IP.
• Otevření Ovládacích panelů – > zařízení a tiskáren – > přidání tiskárny
• Vyberte možnost Přidat tiskárnu pomocí adresy protokolu TCP/IP nebo názvu hostitele.
• Zadejte IP adresu tiskárny.
• Port tiskárny Standard 9100
• V případě potřeby nainstalujte vhodný ovladač tiskárny ručně.

Linux

• podobně jako u Windows stačí postupovat podle standardního postupu instalace síťové tiskárny.
• Stačí postupovat podle pokynů pro veřejné Linux pro SUSE nebo Red Hat a Oracle Linux o tom, jak přidat tiskárnu.

Tiskárna založená na hostiteli přes SMB (sdílená tiskárna) ve scénáři mezi místními místy

Tiskárny založené na hostitelích nejsou návrhem kompatibilním se sítí. Tiskárnu založenou na hostiteli ale můžete sdílet mezi počítači v síti, pokud je tiskárna připojená k počítači, na kterém je zapnutý. Připojení firemní síť buď na lokalitu, nebo ExpressRoute a sdílejte místní tiskárnu. Protokol SMB používá namísto služby DNS jako názvových služeb rozhraní NetBIOS. Název hostitele pro rozhraní NetBIOS se může lišit od názvu hostitele DNS. Standardním případem je, že název hostitele rozhraní NetBIOS a název hostitele DNS jsou identické. Doména DNS nesmysluje v oboru názvů NetBIOS. Proto se v názvovém prostoru NetBIOS nesmí používat plně kvalifikovaný název hostitele DNS, který se skládá z názvu hostitele DNS a domény DNS.

Sdílená složka tiskárny je v síti identifikována jedinečným názvem:

• Název hostitele pro hostitele SMB (vždy potřeba)
• Název sdílené složky (vždy je potřeba).
• Název domény, Pokud sdílená tiskárna není ve stejné doméně jako systém SAP.
• Kromě toho může být vyžadováno uživatelské jméno a heslo pro přístup ke sdílení tiskárny.

Postup:

Windows

Sdílejte místní tiskárnu. na virtuálním počítači Azure otevřete Windows Explorer a zadejte název sdílené složky tiskárny. Průvodce instalací tiskárny vás provede procesem instalace.

Linux

Tady jsou některé příklady dokumentace týkající se konfigurace síťových tiskáren v systému Linux nebo včetně kapitoly týkající se tisku v systému Linux. Bude fungovat stejným způsobem jako virtuální počítač Azure Linux, pokud je virtuální počítač součástí sítě VPN:

• SLES https://en.opensuse.org/SDB:Printing_via_SMB_(Samba)_Share_or_Windows_Share
• RHEL nebo Oracle Linux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Starting_Print_Settings_Config

Tiskárna USB (přesměrování tiskárny)

V Azure schopnost vzdálené plochy poskytovat uživatelům přístup k místním zařízením tiskáren ve vzdálené relaci není k dispozici.

Windows

další podrobnosti o tisku pomocí Windows najdete tady: https://technet.microsoft.com/library/jj590748.aspx .

Integrace systémů SAP Azure do systému pro opravy a přenosové systémy (TMS) ve více místech

Systém SAP Change and Transporting (TMS) musí být nakonfigurovaný tak, aby vyexportovali a importoval požadavky na přenos napříč systémy na šířku. Předpokládáme, že vývojové instance systému SAP (DEV) se nacházejí v Azure, zatímco služba zabezpečování kvality (QA) a produktivní systémy (PRD) jsou místní. Dále předpokládáme, že existuje centrální adresář pro přenos.

Konfigurace domény přenosu

Nakonfigurujte svou doménu přenosu v systému, který jste označili jako transportní řadič domény, jak je popsáno v tématu Konfigurace přenosového řadiče domény. Vytvoří se systémový uživatel TMSADM a bude vygenerován požadovaný cíl RFC. Tato připojení RFC můžete kontrolovat pomocí SM59 transakce. V rámci vaší domény přenosu musí být povoleno rozlišení názvu hostitele.

Postup:

• V našem scénáři jsme se rozhodli, že místní systém QAS bude řadičem domény CTS. Zavolejte STMS transakce. Zobrazí se dialogové okno organizace TMS. Zobrazí se dialogové okno Konfigurovat doménu přenosu. (Toto dialogové okno se zobrazí pouze v případě, že jste ještě nenakonfigurovali doménu přenosu.)
• zajistěte, aby byl automaticky vytvořený uživatel TMSADM autorizovaný (SM59-> jazyk ABAP Connection-> TMSADM@E61.DOMAIN_E61 -> details-> Utilities (M) – > autorizační Test). Úvodní obrazovka transakčního STMS by měla Ukázat, že tento systém SAP teď funguje jako řadič domény přenosu, jak je znázorněno zde:

Zahrnutí systémů SAP v doméně přenosu

Sekvence zahrnutí systému SAP v doméně přenosu vypadá takto:

• V systému pro vývoj v Azure se přečtěte do přenosového systému (klient 000) a zavolejte STMS transakce. V dialogovém okně vyberte jinou konfiguraci a pokračujte zahrnutým systémem v doméně. Zadejte řadič domény jako cílového hostitele (včetně systémů SAP v doméně přenosu). Systém nyní čeká na zahrnutí v doméně přenosu.
• Z bezpečnostních důvodů pak musíte přejít zpět na řadič domény a žádost potvrdit. Vyberte Přehled systému a schvalte čekající systém. Pak potvrďte výzvu a konfigurace bude distribuována.

Tento systém SAP teď obsahuje informace potřebné pro všechny ostatní systémy SAP v doméně přenosu. Data o novém systému SAP se ve stejnou dobu odesílají do všech ostatních systémů SAP a systém SAP se zadává do přenosového profilu programu řízení přenosů. Ověřte, jestli jsou dokumenty RFC a přístup k adresáři přenosu práce v doméně.

Pokračujte v konfiguraci přenosového systému obvyklým způsobem, jak je popsáno v dokumentaci pro změnu a přenos systému.

Postup:

• Ujistěte se, že je váš STMS místní konfigurace správně nakonfigurovaný.
• Ujistěte se, že se název hostitele přenosového řadiče domény dá vyřešit vaším virtuálním počítačem v Azure a naopak.
• Volání transakce STMS-> jiný konfigurační > systém zahrnuje v doméně.
• Potvrďte připojení v místním systému TMS.
• Konfigurujte trasy přenosů, skupiny a vrstvy obvyklým způsobem.

V případě propojení mezi místními prostředími mezi lokalitami může být latence mezi místními a Azure pořád značná. Pokud budeme postupovat podle sekvence přenosů objektů pomocí vývojových a testovacích systémů do produkčního prostředí, nebo si myslíte, že se bude používat přenosové a podpůrné balíčky v různých systémech, zjistíte, že závisí na umístění centrálního transportního adresáře, ale u některých systémů dojde ke vysoké latenci při čtení nebo zápisu dat do centrálního adresáře přenosu. Tato situace je podobná konfiguracím SAP na šířku, kde jsou různé systémy rozloženy prostřednictvím různých datových center s významnou vzdáleností mezi datovými centry.

Aby bylo možné tuto latenci obejít a tyto systémy budou rychle fungovat při čtení nebo zápisu do nebo z adresáře přenosu, můžete nastavit dvě STMS dopravních domén (jeden pro místní a druhý se systémy v Azure a propojit domény přenosu. Podívejte se na tuto dokumentaci, která vysvětluje principy tohoto konceptu v tématu SAP TMS.

Postup:

• Nastavení domény pro přenos v každém umístění (místně a Azure) pomocí TRANSAKČNÍho STMS
• Propojte domény s propojením domény a potvrďte propojení mezi těmito dvěma doménami.
• Distribuujte konfiguraci do odkazovaného systému.

Přenos RFC mezi instancemi SAP umístěnými v Azure a místním prostředím (mezi místními počítači)

Data RFC mezi systémy, které jsou místní a v Azure, musí fungovat. Pro nastavení transakce volání připojení SM59 ve zdrojovém systému, ve kterém potřebujete definovat připojení RFC k cílovému systému. Konfigurace je podobná standardnímu nastavení připojení RFC.

Předpokládáme, že ve scénáři mezi místními počítači jsou virtuální počítače, které spouštějí systémy SAP, které musí vzájemně komunikovat, ve stejné doméně. Proto se nastavení připojení RFC mezi systémy SAP neliší od kroků instalace a vstupů v místních scénářích.

Přístup k místním sdíleným složkám z instancí SAP, které se nacházejí v Azure, nebo naopak

Instance SAP umístěné v Azure potřebují přístup ke sdíleným složkám, které se nacházejí v podnikových podnicích. Kromě toho musí místní instance SAP přistupovat ke sdíleným složkám, které se nacházejí v Azure. Pokud chcete sdílené složky povolit, musíte nakonfigurovat možnosti oprávnění a sdílení v místním systému. Nezapomeňte otevřít porty na připojení VPN nebo ExpressRoute mezi Azure a vaším datovým centrem.

Možnosti podpory

Rozšíření Azure pro SAP

Aby bylo možné podávat určitou část informací o infrastruktuře Azure pro důležité systémy SAP do instancí agenta hostitele SAP instalovaných na virtuálních počítačích, musí být pro nasazené virtuální počítače nainstalovaná přípona Azure (VM) pro SAP. Vzhledem k tomu, že požadavky podle SAP byly specifické pro aplikace SAP, společnost Microsoft se rozhodla, že do Azure neimplementuje obecně implementaci požadovaných funkcí, ale ponechá zákazníkům, aby nasadili potřebné rozšíření a konfigurace virtuálního počítače na jejich Virtual Machines spuštěné v Azure. Nicméně Správa nasazení a životního cyklu rozšíření virtuálního počítače Azure pro SAP bude většinou automatizovaná Azure.

Návrh řešení

Řešení vyvinuté za účelem povolení agenta hostitele SAP získání požadovaných informací vychází z architektury agenta virtuálního počítače Azure a architektury rozšíření. Cílem agenta virtuálního počítače Azure a rozhraní rozšíření je dovolit instalaci softwarových aplikací, které jsou k dispozici v galerii rozšíření virtuálních počítačů Azure v rámci virtuálního počítače. Principem tohoto pojmu je povolení (v případech, jako je rozšíření Azure pro SAP), nasazení zvláštních funkcí do virtuálního počítače a konfigurace takového softwaru v době nasazení.

Agent virtuálního počítače azure, který umožňuje manipulaci s konkrétními rozšířeními virtuálních počítačů azure v rámci virtuálního počítače, se ve výchozím nastavení vloží do Windows virtuálních počítačů při vytváření virtuálních počítačů v Azure Portal. V případě SUSE, Red Hat nebo Oracle Linux je agent virtuálního počítače už součástí Azure Marketplace image. V případě, že jeden z nich nahraje virtuální počítač Linux z místního prostředí do Azure, musí být agent virtuálního počítače nainstalovaný ručně.

Základní stavební bloky řešení, které poskytují informace o infrastruktuře Azure pro hostitele SAP v Azure, vypadají takto:

Jak je znázorněno na obrázku blokový diagram výše, jedna část řešení je hostována v imagi virtuálního počítače Azure a v galerii rozšíření Azure, což je globálně replikované úložiště spravované operacemi Azure. Je zodpovědností společného týmu SAP/MS pracujícího na implementaci SAP pro Azure pro práci s operacemi Azure pro publikování nových verzí rozšíření Azure pro SAP.

když nasadíte nový virtuální počítač Windows, do virtuálního počítače se automaticky přidá Agent virtuálního počítače Azure. Funkce tohoto agenta slouží k koordinaci načítání a konfigurace rozšíření Azure pro virtuální počítače. V případě virtuálních počítačů se systémem Linux je agent virtuálního počítače Azure již součástí bitové kopie Azure Marketplace operačního systému.

Existuje však krok, který je stále potřeba provést zákazníkem. Toto je povolení a konfigurace shromažďování výkonu. Proces související s konfigurací je automatizovaný pomocí skriptu PowerShellu nebo příkazu CLI. skript powershellu se dá stáhnout do centra skriptů Microsoft Azure, jak je popsáno v průvodci nasazením.

Celková architektura rozšíření Azure pro SAP vypadá takto:

Přesný postup a podrobné pokyny k používání těchto rutin PowerShellu nebo příkazu CLI během nasazení najdete v pokynech uvedených v Průvodci nasazením.

Integrace Azure umístěné instance SAP do SAProuter

Instance SAP běžící v Azure musí být dostupné i z SAProuter.

SAProuter umožňuje komunikaci TCP/IP mezi zúčastněnými systémy, pokud není k dispozici žádné přímé připojení IP. Díky tomu je zajištěno, že žádné koncové spojení mezi komunikačními partnery není nutné na úrovni sítě. SAProuter ve výchozím nastavení naslouchá na portu 3299. Pokud chcete spojit instance SAP prostřednictvím SAProuter, musíte zadat řetězec SAProuter a název hostitele s jakýmkoli pokusem o připojení.

SAP NetWeaver jako Java

zatím byl zaměření dokumentu SAP NetWeaver v obecné verzi nebo v zásobníku sap NetWeaver jazyk ABAP. V této malé části jsou uvedeny konkrétní předpoklady pro sadu SAP Java Stack. jednou z nejdůležitějších aplikací založených na systému sap NetWeaver Java je Enterprise Portal sap. jiné aplikace založené na sap NetWeaver, jako je sap PI a sap Solution Manager, používají rozhraní sap NetWeaver jazyk ABAP i balíčky Java. Proto je potřeba vzít v úvahu také konkrétní aspekty týkající se nástroje SAP NetWeaver Java Stack.

Enterprise Portal SAP

Nastavení portálu SAP na virtuálním počítači Azure se neliší od instalace v místním prostředí, pokud nasazujete ve scénářích mezi místními místy. Vzhledem k tomu, že se DNS provádí v místním prostředí, můžete nastavení portů jednotlivých instancí provést místně. doporučení a omezení popsaná v tomto dokumentu se zatím vztahují na aplikaci, jako je sap Enterprise Portal, nebo v části obecná sada pro sap NetWeaver Java.

speciálním scénářem nasazení některými zákazníky je přímá angažovanost Enterprise Portal SAP k internetu, zatímco je hostitel virtuálního počítače připojený k podnikové síti prostřednictvím tunelového připojení VPN typu site-to-site nebo ExpressRoute. V takovém případě je nutné se ujistit, že konkrétní porty jsou otevřené a nejsou blokované bránou firewall nebo skupinou zabezpečení sítě.

Počáteční identifikátor URI portálu je http (s): <Portalserver>:5XX00/irj, kde je port vytvořený pomocí SAP v https://help.sap.com/saphelp_nw70ehp1/helpdata/de/a2/f9d7fed2adc340ab462ae159d19509/frameset.htm .

pokud chcete přizpůsobit adresu URL a porty Enterprise Portal SAP, podívejte se na tuto dokumentaci:

• Změnit adresu URL portálu
• Změna výchozích čísel portů, čísel portů portálu

Vysoká dostupnost (HA) a zotavení po havárii (DR) pro SAP NetWeaver běžící na Azure Virtual Machines

Definice terminologií

Termín vysoké dostupnosti (ha) se obecně týká sady technologií, která minimalizuje přerušení provozu tím, že poskytuje provozní kontinuitu IT služeb prostřednictvím redundantních, odolných nebo převzetí služeb při selhání v rámci stejného datového centra. V našem případě v rámci jedné oblasti Azure.

Zotavení po havárii (Dr) se taky zaměřuje na minimalizaci přerušení služeb IT a jejich obnovení, ale napříč různými datovými centry, které jsou obvykle umístěné stovky kilometrů. V našem případě obvykle mezi různými oblastmi Azure v rámci stejné geopolitické oblasti nebo vámi vytvořeným jako zákazníkem.

Přehled vysoké dostupnosti

Diskuzi o vysoké dostupnosti SAP v Azure můžeme rozdělit do dvou částí:

• Infrastruktura Azure s vysokou dostupností, například ha pro výpočetní prostředky (virtuální počítače), síť, úložiště atd. a její výhody při zvyšování dostupnosti aplikace SAP.
• Vysoká dostupnost aplikace SAP, například ha softwarových komponent SAP:
  • Aplikační servery SAP
  • Instance SAP ASCS/SCS
  • Server DB

a jak se dá kombinovat s infrastrukturou Azure na vysokou dostupnost.

Při vysoké dostupnosti SAP v Azure jsou některé rozdíly v porovnání s vysokou dostupností v místním fyzickém nebo virtuálním prostředí. Následující dokument od SAP popisuje standardní konfigurace SAP s vysokou dostupností ve virtualizovaných prostředích na Windows: https://scn.sap.com/docs/DOC-44415 . Neexistuje žádná konfigurace SAP-HA integrovaná s sapinst pro Linux, stejně jako pro Windows. Informace o SAP HA v místním prostředí pro Linux najdete tady: https://scn.sap.com/docs/DOC-8541 .

Vysoká dostupnost infrastruktury Azure

V současné době platí jedna z virtuálních počítačů SLA 99,9%. Pokud chcete zjistit, jak může vypadat dostupnost jednoho virtuálního počítače, můžete si vytvořit produkt z různých dostupných SLA Azure: https://azure.microsoft.com/support/legal/sla/ .

Základem pro výpočet je 30 dní za měsíc nebo 43200 minut. Proto 0,05% výpadků odpovídá 21,6 minut. V obvyklých případech bude dostupnost různých služeb vynásobena následujícím způsobem:

(Služba dostupnosti #1/100) * (služba dostupnosti #2/100) * (služba dostupnosti #3/100)

Jako

(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 nebo Celková dostupnost 99,75%.

Vysoká dostupnost virtuálního počítače (VM)

Existují dva typy událostí platformy Azure, které mohou ovlivnit dostupnost virtuálních počítačů: plánovaná údržba a neplánovaná údržba.

• Plánované události údržby jsou pravidelné aktualizace od Microsoftu k základní platformě Azure za účelem zlepšení celkové spolehlivosti, výkonu a zabezpečení infrastruktury platformy, na které běží vaše virtuální počítače.
• Neplánované události údržby nastávají v případě, že dojde k nějakému selhání hardwaru nebo základní fyzické infrastruktury, na které stojí virtuální počítač. To může zahrnovat selhání místní sítě, selhání místního disku nebo další selhání na úrovni racku. Když se takové selhání detekuje, platforma Azure automaticky migruje virtuální počítač z nesprávného fyzického serveru, který hostuje váš virtuální počítač, na dobrý fyzický server. Takové události se vyskytují jen vzácně, ale také můžou způsobit restartování vašeho virtuálního počítače.

další podrobnosti najdete v tématu dostupnost Windows virtuálních počítačů v azure a dostupnosti virtuálních počítačů se systémem Linux v azure.

Azure Storage Redundance

data ve vašem účtu Microsoft Azure Storage se vždycky replikují, aby se zajistila odolnost a vysoká dostupnost, a to na základě Azure Storage smlouvy SLA, a to i v případě přechodných selhání hardwaru.

vzhledem k tomu, že Azure Storage udržuje tři image dat ve výchozím nastavení, není nutné, aby se RAID5 nebo RAID1 na více discích Azure.

další podrobnosti najdete v tématu Azure Storage redundance.

Využití restartování virtuálních počítačů infrastruktury Azure k dosažení vyšší dostupnosti aplikací SAP

pokud se rozhodnete nepoužívat funkce, jako je Windows Server Failover clustering (WSFC) nebo Pacemaker v systému Linux (aktuálně se podporuje jenom pro SLES 12 a novější), používá se Restart virtuálního počítače azure k ochraně systému SAP proti plánovanému a neplánovanému výpadku infrastruktury fyzického serveru azure a celkové základní platformy azure.

Dalším důležitým prvkem infrastruktury pro vysokou dostupnost je úložiště. například Azure Storage SLA je 99,9% dostupnost. pokud jeden z nich nasadí všechny virtuální počítače s disky do jednoho Azure Storage účtu, potenciální Azure Storage nedostupnost způsobí nedostupnost všech virtuálních počítačů, které jsou umístěné v daném Azure Storage účtu, a také všechny součásti SAP běžící v těchto virtuálních počítačích.

místo vložení všech virtuálních počítačů do jednoho jediného Azure Storage účtu můžete pro každý virtuální počítač použít taky vyhrazené účty úložiště a tímto způsobem zvýšit dostupnost všech virtuálních počítačů a aplikací SAP pomocí víc nezávislých Azure Storage účtů.

Služby Azure Managed disks se automaticky umístí do domény selhání virtuálního počítače, ke kterému jsou připojené. Pokud nasadíte dva virtuální počítače do skupiny dostupnosti a použijete Managed Disks, platforma se postará o distribuci Managed Disks do různých domén selhání. Pokud máte v plánu používat Premium Storage, důrazně doporučujeme použít také možnost Spravovat disky.

Ukázková architektura systému SAP NetWeaver, který používá hašování infrastruktury Azure a účty úložiště, by mohla vypadat takhle:

Ukázková architektura systému SAP NetWeaver, který využívá hašování infrastruktury Azure a Spravované disky by mohla vypadat takhle:

U důležitých komponent SAP jsme zatím dosáhli následujících:

• Vysoká dostupnost aplikačních serverů SAP (AS)

  Instance aplikačního serveru SAP jsou redundantní komponenty. Každá instance SAP AS je nasazená na vlastním virtuálním počítači, který běží v jiné doméně Selhání a upgrade Azure (viz kapitoly Domény selhání a Upgradované domény). To je zajištěno pomocí skupiny dostupnosti Azure (viz kapitolu Skupiny dostupnosti Azure). Potenciální plánovaná nebo neplánovaná nedostupnost domény selhání nebo upgradu Azure způsobí nedostupnost omezeného počtu virtuálních počítače s jejich instancemi SAP AS.

  Každá instance SAP AS je umístěná ve vlastním účtu Azure Storage – potenciální nedostupnost jednoho účtu Azure Storage způsobí nedostupnost pouze jednoho virtuálního počítače s jeho instancí SAP AS. Je však třeba mít na paměti, že v rámci jednoho předplatného Azure Azure Storage omezení počtu účtů. Pokud chcete zajistit automatické spuštění instance (A)SCS po restartování virtuálního počítače, nezapomeňte nastavit parametr automatického spuštění v profilu spuštění instance (A)SCS popsaném v kapitole Použití automatického startu pro instance SAP. Další podrobnosti najdete také v kapitole Vysoká dostupnost aplikačních serverů SAP.

  I když použijete Spravované disky, jsou tyto disky také uložené v účtu Azure Storage a mohou být nedostupné v případě výpadku úložiště.

• Vyšší Dostupnost instance SAP (A)SCS

  Tady používáme k ochraně virtuálního počítače pomocí nainstalované instance SAP (A)SCS restart virtuálního počítače Azure. V případě plánovaného nebo neplánovaných výpadků serverů Azure se virtuální počítače restartují na jiném dostupném serveru. Jak už bylo zmíněno dříve, restartování virtuálního počítače Azure primárně chrání virtuální počítače a APLIKACE, v tomto případě instanci (A)SCS. Po restartování virtuálního počítače se budeme k instanci SAP (A)SCS dostat nepřímo vyšší dostupností. Pokud chcete zajistit automatické spuštění instance (A)SCS po restartování virtuálního počítače, nezapomeňte nastavit parametr automatického spuštění v profilu spuštění instance (A)SCS popsaném v kapitole Použití automatického startu pro instance SAP. To znamená, že instance (A)SCS jako jediný bod selhání (SPOF) spuštěná na jednom virtuálním počítači bude determinativním faktorem pro dostupnost celé oblasti SAP.

• Vyšší Dostupnost serveru DBMS

  Podobně jako v případě použití instance SAP (A)SCS využíváme k ochraně virtuálního počítače pomocí nainstalovaného softwaru DBMS restartování virtuálního počítače Azure a prostřednictvím restartování virtuálního počítače dosahujeme vyšší dostupnosti softwaru DBMS. DBMS běžící na jednom virtuálním počítači je také spof a je to determinativní faktor pro dostupnost celé oblasti SAP.

Vysoká dostupnost aplikací SAP v Azure IaaS

K dosažení plné vysoké dostupnosti systému SAP potřebujeme chránit všechny důležité systémové komponenty SAP, například redundantní aplikační servery SAP, a jedinečné komponenty (například kritický bod selhání), jako je instance SAP (A)SCS a DBMS.

Vysoká dostupnost pro aplikační servery SAP

U aplikačních serverů nebo instancí dialogového okna SAP není nutné přemýšlet o konkrétním řešení vysoké dostupnosti. Vysoké dostupnosti se dosahuje redundancí a tím je dostatek na různých virtuálních počítačích. Všechny by měly být umístěné ve stejné skupině dostupnosti Azure, aby se zabránilo tomu, že by se virtuální počítače mohly během plánované údržby aktualizovat ve stejnou dobu. Základní funkce, která vychází z různých upgradů a domén selhání v rámci jednotky škálování Azure, byla již zavedena v kapitole Upgradovací domény. Skupiny dostupnosti Azure byly představeny v kapitole Skupiny dostupnosti Azure v tomto dokumentu.

Neexistuje žádný neomezený počet domén selhání a upgradů, které může použít sada dostupnosti Azure v rámci jednotky škálování Azure. To znamená, že umístění několika virtuálních počítače do jedné skupiny dostupnosti dříve nebo později skončí ve stejné chybě nebo upgradování domény.

Nasazování několika instancí aplikačního serveru SAP do vyhrazených virtuálních počítače a za předpokladu, že máme pět upgradovaných domén, se na konci objeví následující obrázek. Skutečný maximální počet domén selhání a aktualizačních domén ve skupině dostupnosti se může v budoucnu změnit:

Vysoká dostupnost pro centrální služby SAP v Azure

Informace o architektuře vysoké dostupnosti centrálních služeb SAP v Azure najdete v článku Architektura a scénáře vysoké dostupnosti pro SAP NetWeaver jako vstupní informace. Článek odkazuje na podrobnější popisy konkrétních operačních systémů.

Vysoká dostupnost pro instanci databáze SAP

Typické nastavení vysoké dostupnosti SAP DBMS je založené na dvou virtuálních počítači DBMS, kde se k replikaci dat z aktivní instance DBMS do druhého virtuálního počítače do pasivní instance DBMS používá funkce vysoké dostupnosti DBMS.

Funkce vysoké dostupnosti a zotavení po havárii pro DBMS obecně i specifické DBMS jsou popsané v průvodci nasazením DBMS.

Komplexní vysoká dostupnost pro kompletní systém SAP

Tady jsou dva příklady kompletní architektury SAP NetWeaver HA v Azure – jeden pro Windows a jeden pro Linux.

Pouze nespravované disky: Při nasazování mnoha systémů SAP může být potřeba poněkud ohrozit koncepty, které jsou vysvětlené níže. Počet nasazených virtuálních počítačů překračuje limit maximálního počtu účtů Storage na předplatné. V takových případech je potřeba virtuální virtuální počítače kombinovat v rámci jednoho Storage počítače. Obvykle byste k tomu měli kombinaci virtuálních řešení VHD virtuálních počítače aplikační vrstvy SAP z různých systémů SAP. Také jsme v jednom z nich zkombinovat různé virtuální Azure Storage DBMS různých systémů SAP. Zachování limitů IOPS Azure Storage účtů na paměti ( https://azure.microsoft.com/documentation/articles/storage-scalability-targets )

HA on Windows

Pro systém SAP NetWeaver se používají následující konstruktory Azure, které minimalizují dopad problémů s infrastrukturou a opravami hostitele:

• Kompletní systém je nasazený v Azure (povinné – vrstva DBMS, instance (A)SCS a kompletní aplikační vrstva musí běžet ve stejném umístění).
• Celý systém běží v rámci jednoho předplatného Azure (povinné).
• Celý systém běží v rámci jedné služby Azure Virtual Network (povinné).
• Rozdělení virtuálních počítačů jednoho systému SAP do tří sad dostupnosti je možné i v případě, že všechny virtuální počítače patří do stejné Virtual Network.
• Každá vrstva (například DBMS, ASCS, aplikační servery) musí používat vyhrazenou sadu dostupnosti.
• Všechny virtuální počítače s instancemi DBMS jednoho systému SAP jsou v jedné skupině dostupnosti. Předpokládáme, že existuje více než jeden virtuální počítač s instancemi DBMS na systém, protože se používají nativní funkce vysoké dostupnosti DBMS, jako je SQL Server AlwaysOn nebo Oracle Data Guard.
• Všechny virtuální počítače s instancemi DBMS používají vlastní účet úložiště. Data a soubory protokolů DBMS se replikují z jednoho účtu úložiště do jiného účtu úložiště pomocí funkcí vysoké dostupnosti DBMS, které synchronizují data. Nedostupnost jednoho účtu úložiště způsobí nedostupnost jednoho SQL Windows clusteru, ale ne celou SQL Server službu.
• Všechny virtuální počítače s instancí (A)SCS jednoho systému SAP jsou v jedné skupině dostupnosti. Uvnitř Windows je nakonfigurovaný cluster s podporou převzetí služeb při selhání serveru (WSFC), který chrání instanci (A)SCS.
• Všechny virtuální počítače se spuštěnou instancí (A)SCS používají vlastní účet úložiště. (A) Soubory instancí SCS a globální složka SAP se replikují z jednoho účtu úložiště do jiného účtu úložiště pomocí replikace SIOS DataKeeper. Nedostupnost jednoho účtu úložiště způsobí nedostupnost jednoho (A)SCS Windows clusteru, ale ne celé služby (A)SCS.
• VŠECHNY virtuální počítače, které představují vrstvu aplikačního serveru SAP, jsou ve třetí skupině dostupnosti.
• Všechny virtuální počítače s aplikačními servery SAP používají vlastní účet úložiště. Nedostupnost jednoho účtu úložiště způsobí nedostupnost jednoho aplikačního serveru SAP, kde budou dál běžet další aplikační servery SAP.

Na následujícím obrázku je znázorněna stejná krajina pomocí Spravované disky.

HA v Linuxu

Architektura SAP HA v Linuxu v Azure je v podstatě stejná jako u Windows popsaných výše. Seznam podporovaných [řešení 1928533] dostupnosti najdete v poznámkové dokumentaci k SAP.

Použití automatického startu pro instance SAP

SAP nabízela funkci pro spuštění instancí SAP hned po spuštění operačního systému v rámci virtuálního počítače. Přesné kroky byly zdokumentovány v článku znalostní báze SAP 1909114. SAP už ale toto nastavení nedoporučuje používat, protože neexistuje žádná kontrola nad pořadím restartování instancí za předpokladu, že došlo k ovlivnění více než jednoho virtuálního počítače nebo spuštění několika instancí na virtuální počítač. Za předpokladu, že se jedná o typický scénář Azure jedné instance aplikačního serveru SAP ve virtuálním počítače a případ restartování jednoho virtuálního počítače, není automatické spuštění kritické a je možné ho povolit přidáním tohoto parametru:

Autostart = 1

Do počátečního profilu instance SAP jazyk ABAP nebo Java.

Další informace týkající se automatického startu pro instance SAP najdete tady:

• Spuštění/zastavení SAP společně s start/zastavením unixového serveru
• Spouštění a zastavování agentů pro správu SAP NetWeaver
• Povolení automatického spuštění databáze HANA

Větší 3vrstvé systémy SAP

High-Availability aspekty 3vrstvých konfigurací SAP jsme už probírali v předchozích částech. Ale co systémy, ve kterých jsou požadavky na server DBMS příliš velké na to, aby se našly v Azure, ale aplikační vrstvu SAP je možné nasadit do Azure?

Umístění konfigurací pro 3 vrstvy SAP

Pro rozdělení samotné aplikační vrstvy nebo aplikace a DBMS mezi místními prostředími a Azure se nepodporuje. Systém SAP je buď zcela nasazený místně nebo v Azure. Také se nepodporuje, aby některé aplikační servery běžely v místním prostředí a jiné v Azure. To je výchozí bod diskuze. Nepodporujeme také komponenty DBMS systému SAP a vrstvy aplikačního serveru SAP nasazené ve dvou různých oblastech Azure. Například DBMS v Západní USA a aplikační vrstva SAP v Střed USA. Důvodem pro nepodporu takových konfigurací je citlivost na latenci architektury SAP NetWeaver.

Nicméně v průběhu minulého roku se partneři pro datacentrum vyvinuli ve společném umístění do oblastí Azure. Tato spoluumístění jsou často v blízké blízkosti fyzických datových center Azure v oblasti Azure. Krátká vzdálenost a spojení prostředků ve společném umístění až po ExpressRoute do Azure může způsobit latenci, která je kratší než 2 milisekundy. V takových případech je možné najít vrstvu DBMS (včetně sítě SAN úložiště/NAS) v takovém společném umístění a aplikační vrstvě SAP v Azure. Velké instance Hana

Offline zálohování systémů SAP

V závislosti na zvolené konfiguraci SAP (2 vrstva nebo 3 vrstva) může být potřeba zálohovat. Obsah samotného virtuálního počítače je navíc k zálohování databáze. Očekává se, že zálohy související se systémem DBMS budou provedeny s metodami databáze. Podrobný popis pro různé databáze najdete v příručce pro DBMS. Na druhé straně lze data SAP zálohovat v režimu offline (včetně obsahu databáze), jak je popsáno v této části nebo online, jak je popsáno v následující části.

Zálohování offline by v podstatě vyžadovalo vypnutí virtuálního počítače prostřednictvím Azure Portal a kopii základního disku virtuálního počítače a všech připojených disků k virtuálnímu počítači. Tím se zachová bitová kopie tohoto virtuálního počítače a jeho přidruženého disku v časovém bodě. doporučuje se zkopírovat zálohy do jiného účtu Azure Storage. proto platí postup popsaný v kapitole kopírování disků mezi Azure Storagemi účty tohoto dokumentu.

obnovení tohoto stavu by představovalo odstranění základního virtuálního počítače i původní disky základního virtuálního počítače a připojených disků, kopírování uložených disků do původního účtu Storage nebo skupiny prostředků pro spravované disky a následného opětovného nasazení systému. Tento článek ukazuje příklad skriptu tohoto procesu v prostředí PowerShell: https://www.westerndevs.com/_/azure-snapshots/

Nezapomeňte nainstalovat novou licenci SAP od obnovení zálohy virtuálního počítače, jak je popsáno výše. vytvoří nový hardwarový klíč.

Online zálohování systému SAP

Zálohování systému DBMS se provádí pomocí metod specifických pro systém DBMS, jak je popsáno v příručce pro systém DBMS.

Další virtuální počítače v rámci systému SAP se dají zálohovat pomocí funkce zálohování virtuálních počítačů Azure. Zálohování virtuálního počítače Azure je standardní metoda pro zálohování kompletního virtuálního počítače v Azure. Azure Backup ukládá zálohy v Azure a umožňuje obnovení virtuálního počítače znovu.

Web Azure jako DR pro produkci SAP krajiny

od Mid 2014, rozšíření k různým součástem technologie Hyper-V, System Center a azure umožňují použití azure jako webu DR pro virtuální počítače, které jsou na místním počítači založené na technologii hyper-v.

Blog s podrobnostmi o nasazení tohoto řešení najdete tady: ochrana řešení SAP pomocí Azure Site Recovery.

Shrnutí pro vysokou dostupnost pro systémy SAP

Klíčové body vysoké dostupnosti pro systémy SAP v Azure jsou:

• V tomto okamžiku nemůžete jediný bod selhání protokolu SAP zabezpečit přesně stejným způsobem, jako se dá provést v místních nasazeních. Důvodem je to, že clustery sdílených disků se ještě nedají v Azure sestavit bez použití softwaru třetí strany.
• Pro vrstvu DBMS je potřeba použít funkce DBMS, které nezávisí na technologii sdíleného disku clusteru. Podrobnosti jsou popsány v příručce pro DBMS.
• Abyste minimalizovali dopad problémů v rámci domén selhání v infrastruktuře Azure nebo údržbě hostitele, měli byste použít skupiny dostupnosti Azure:
  • Doporučuje se mít pro vrstvu aplikace SAP jednu skupinu dostupnosti.
  • Doporučuje se mít pro vrstvu DBMS systému SAP samostatnou skupinu dostupnosti.
  • Nedoporučuje se použít stejnou skupinu dostupnosti pro virtuální počítače s různými systémy SAP.
  • doporučuje se použít Premium Managed Disks.
• Pro účely zálohování vrstvy SAP DBMS si Projděte příručku pro DBMS.
• Zálohování instancí dialogových oken SAP má malý smysl, protože je obvykle rychlejší pro opětovné nasazení jednoduchých instancí dialogových oken.
• zálohování virtuálního počítače, který obsahuje globální adresář systému SAP a má všechny profily různých instancí, má smysl a měl by se provádět program Windows Zálohování nebo, například tar v systému Linux. vzhledem k tomu, že existují rozdíly mezi Windows serverem 2008 (r2) a Windows Server 2012 (r2), které usnadňují zálohování pomocí novějších verzí Windows serveru, doporučujeme spustit Windows Server 2012 (R2) jako Windows hostovaný operační systém.

Další kroky

Přečtěte si články:

• Nasazení Azure Virtual Machines pro SAP NetWeaver
• Důvody pro nasazení Azure Virtual Machines DBMS pro úlohy SAP
• Konfigurace infrastruktury SAP HANA a operace v Azure