Megosztás a következőn keresztül:

SAP HANA infrastruktúrakonfigurációk és -műveletek az Azure-ban

  • Cikk

Ez a dokumentum útmutatást nyújt az Azure-infrastruktúra konfigurálásához és az Azure natív virtuális gépeken (virtuális gépeken) üzembe helyezett SAP HANA-rendszerek üzemeltetéséhez. A dokumentum az SAP HANA vertikális felskálázásának konfigurációs adatait is tartalmazza az M128s virtuálisgép-termékváltozathoz. Ez a dokumentum nem a szabványos SAP-dokumentáció cseréjére szolgál, amely az alábbi tartalmakat tartalmazza:

Előfeltételek

Az útmutató használatához alapvető ismeretekre van szüksége az alábbi Azure-összetevőkről:

Ha többet szeretne megtudni az SAP NetWeaverről és az Azure egyéb SAP-összetevőiről, tekintse meg az Azure-beli SAP-t az Azure dokumentációjának azure-beli szakaszában.

Alapszintű beállítási szempontok

Az alábbi szakaszok az SAP HANA-rendszerek Azure-beli virtuális gépeken való üzembe helyezésének alapvető beállítási szempontjait ismertetik.

Csatlakozás Azure-beli virtuális gépekhez

Az Azure-beli virtuális gépek tervezési útmutatójában leírtak szerint az Azure-beli virtuális gépekhez való csatlakozásnak két alapvető módja van:

  • Csatlakozás az interneten és a nyilvános végpontokon egy jump virtuális gépen vagy az SAP HANA-t futtató virtuális gépen.
  • Csatlakozás VPN-en vagy Azure ExpressRoute-on keresztül.

Az éles helyzetekben a helyek közötti kapcsolat VPN-en vagy ExpressRoute-on keresztül szükséges. Ez a kapcsolattípus olyan nem éles forgatókönyvekhez is szükséges, amelyek olyan éles forgatókönyvekbe kerülnek, ahol SAP-szoftvereket használnak. Az alábbi képen egy példa látható a helyek közötti kapcsolatra:

Helyek közötti kapcsolat

Azure-beli virtuálisgép-típusok kiválasztása

Az SAP felsorolja, hogy mely Azure-beli virtuálisgép-típusokat használhatja éles forgatókönyvekhez. Nem éles forgatókönyvek esetén a natív Azure-beli virtuálisgép-típusok szélesebb választéka érhető el.

Feljegyzés

Nem éles forgatókönyvek esetén használja az SAP megjegyzés #1928533 című megjegyzésben felsorolt virtuálisgép-típusokat. Az Azure-beli virtuális gépek éles környezetben való használatához ellenőrizze, hogy az SAP HANA-minősített virtuális gépek szerepelnek-e az SAP által közzétett minősített IaaS-platformok listájában.

A virtuális gépek üzembe helyezése az Azure-ban a következőkkel:

  • Azure Portal.
  • Azure PowerShell-parancsmagok.
  • Az Azure CLI.

Az SAP Cloud platformon keresztül teljes körűen telepített SAP HANA-platformot is üzembe helyezhet az Azure-beli virtuálisgép-szolgáltatásokon. A telepítési folyamatot az SAP S/4HANA vagy a BW/4HANA üzembe helyezése az Azure-ban ismerteti.

Fontos

A M208xx_v2 virtuális gépek használatához körültekintően kell kiválasztania a Linux rendszerképet. További információ: Memóriaoptimalizált virtuálisgép-méretek.

Tárolókonfiguráció az SAP HANA-hoz

Az AZURE-beli SAP HANA-val használható tárolási konfigurációk és tárolási típusok esetén olvassa el az SAP HANA Azure-beli virtuálisgép-tárolókonfigurációit tartalmazó dokumentumot

Azure-beli virtuális hálózatok beállítása

Ha helyek közötti kapcsolattal rendelkezik az Azure-ba VPN-en vagy ExpressRoute-on keresztül, rendelkeznie kell legalább egy Olyan Azure-beli virtuális hálózattal, amely virtuális átjárón keresztül csatlakozik a VPN- vagy ExpressRoute-kapcsolatcsoporthoz. Egyszerű üzembe helyezés esetén a virtuális átjáró az SAP HANA-példányokat is üzemeltető Azure-beli virtuális hálózat (VNet) alhálózatán helyezhető üzembe. Az SAP HANA telepítéséhez további két alhálózatot kell létrehoznia az Azure-beli virtuális hálózaton belül. Egy alhálózat üzemelteti a virtuális gépeket az SAP HANA-példányok futtatásához. A másik alhálózat jumpbox- vagy felügyeleti virtuális gépeket futtat az SAP HANA Studio, más felügyeleti szoftverek vagy az alkalmazásszoftver üzemeltetéséhez.

Fontos

A funkciókon kívül, de teljesítménybeli okokból még fontosabb, nem támogatott az Azure Network Virtual Appliance konfigurálása az SAP-alkalmazás és az SAP NetWeaver, Hybris vagy S/4HANA-alapú SAP-rendszer DBMS-rétege közötti kommunikációs útvonalon. Az SAP-alkalmazásréteg és a DBMS-réteg közötti kommunikációnak közvetlennek kell lennie. A korlátozás nem tartalmazza az Azure ASG- és NSG-szabályokat mindaddig, amíg ezek az ASG- és NSG-szabályok lehetővé teszik a közvetlen kommunikációt. A további forgatókönyvek, amelyekben az NVA-k nem támogatottak, a linuxos Pacemaker-fürtcsomópontok és SBD-eszközök közötti kommunikációs útvonalakon találhatók, amint azt az SAP NetWeaver magas rendelkezésre állása az Azure-beli virtuális gépeken a SUSE Linux Enterprise Serveren sap-alkalmazásokhoz. Vagy az Azure-beli virtuális gépek és a Windows Server SOFS közötti kommunikációs útvonalakon, amelyeket egy SAP ASCS/SCS-példány fürtben az Azure-beli fájlmegosztás használatával állított be egy Windows-feladatátvevő fürtön. A kommunikációs útvonalak NVA-jai könnyedén megduplázhatják a hálózati késést két kommunikációs partner között, korlátozhatják az SAP-alkalmazásréteg és a DBMS-réteg közötti kritikus útvonalak átviteli sebességét. Az ügyfelekkel megfigyelt egyes esetekben az NVA-k a Pacemaker Linux-fürtöinek meghiúsulását okozhatják olyan esetekben, amikor a Linux Pacemaker-fürtcsomópontok közötti kommunikációnak NVA-n keresztül kell kommunikálnia az SBD-eszközével.

Fontos

A NEM támogatott másik kialakítás az SAP-alkalmazásréteg és a DBMS-réteg elkülönítése különböző Azure-beli virtuális hálózatokra, amelyek nincsenek egymással társviszonyban. Javasoljuk, hogy az SAP-alkalmazásréteget és a DBMS-réteget alhálózatok használatával különítse el egy Azure-beli virtuális hálózaton belül ahelyett, hogy különböző Azure-beli virtuális hálózatokat használna. Ha úgy dönt, hogy nem követi a javaslatot, és ehelyett elkülöníti a két réteget különböző virtuális hálózatokra, a két virtuális hálózatot társviszonyban kell tartani. Vegye figyelembe, hogy két társviszonyban álló Azure-beli virtuális hálózat közötti hálózati forgalom átviteli költségekkel jár. Az SAP-alkalmazásréteg és a DBMS-réteg között sok terabájtnyi adatmennyiség jelentős költségek halmozódhatnak fel, ha az SAP-alkalmazásréteg és a DBMS-réteg két társviszonyban lévő Azure-beli virtuális hálózat között van elkülönítve.

Ha jumpbox- vagy felügyeleti virtuális gépeket helyezett üzembe egy külön alhálózatban, több virtuális hálózati adaptert (vNIC-t) is definiálhat a HANA virtuális géphez, és mindegyik virtuális hálózati adapter különböző alhálózathoz van rendelve. Ha több virtuális hálózati adapterrel rendelkezik, szükség esetén beállíthatja a hálózati forgalom elkülönítését. Az ügyfélforgalom például az elsődleges virtuális hálózati adapteren keresztül irányítható, a rendszergazdai forgalom pedig egy második virtuális hálózati adapteren keresztül lesz irányítva.
Emellett statikus privát IP-címeket is hozzárendelhet, amelyek mindkét virtuális hálózati adapterhez üzembe vannak helyezve.

Feljegyzés

Statikus IP-címeket kell hozzárendelnie az Azure-eszközökkel az egyes virtuális hálózati adapterekhez. A vendég operációs rendszeren belüli statikus IP-címeket nem szabad vNIC-hez rendelni. Egyes Azure-szolgáltatások, például az Azure Backup Service arra a tényre támaszkodnak, hogy legalább az elsődleges virtuális hálózati adapter DHCP-ra van állítva, és nem statikus IP-címekre. Lásd még az Azure-beli virtuális gépek biztonsági mentésének hibaelhárítása című dokumentumot. Ha több statikus IP-címet kell hozzárendelnie egy virtuális géphez, több virtuális hálózati adaptert kell hozzárendelnie egy virtuális géphez.

A tartós üzemelő példányok esetében azonban létre kell hoznia egy virtuális adatközpont-hálózati architektúrát az Azure-ban. Ez az architektúra azt javasolja, hogy külön azure-beli virtuális hálózattal külön Azure-beli virtuális hálózattal különítse el a helyszíni hálózathoz csatlakozó Azure VNet-átjárót. Ennek a különálló virtuális hálózatnak kell üzemeltetnie a helyszíni vagy az internet felé irányuló összes forgalmat. Ezzel a módszerrel szoftvereket helyezhet üzembe az Azure-beli virtuális adatközpontba belépő adatforgalom naplózásához és naplózásához ebben a különálló központi virtuális hálózatban. Tehát egy virtuális hálózattal rendelkezik, amely az Azure-üzemelő példány bejövő és kimenő forgalmához kapcsolódó összes szoftvert és konfigurációt üzemelteti.

Az Azure Virtual Datacenter: A Network Perspective, az Azure Virtual Datacenter és a Nagyvállalati vezérlősík című cikkek további információt nyújtanak a virtuális adatközpont megközelítéséről és a kapcsolódó Azure-beli virtuális hálózatok kialakításáról.

Feljegyzés

A központi virtuális hálózat és a küllős virtuális hálózat közötti forgalom azure-beli virtuális hálózatok közötti társviszony-létesítéssel további költségekkel jár. Ezen költségek alapján érdemes lehet kompromisszumot kötnie a szigorú központ- és küllős hálózattervezés, valamint a küllőkhöz csatlakozó Több Azure ExpressRoute-átjáró futtatása között a virtuális hálózatok közötti társviszony megkerülése érdekében. Az Azure ExpressRoute-átjárók azonban további költségeket is bevezetnek. A hálózati forgalom naplózásához, naplózásához és figyeléséhez használt külső szoftverekkel kapcsolatos további költségek is felmerülhetnek. A virtuális hálózatok közötti társviszony-létesítésen keresztüli adatcsere költségeitől, valamint a további Azure ExpressRoute-átjárók és további szoftverlicencek által létrehozott költségektől függően dönthet úgy, hogy a virtuális hálózatok helyett alhálózatokat használ elválasztó egységként egy virtuális hálózaton belül.

Az IP-címek hozzárendelésének különböző módszereiről az Azure IP-címtípusait és kiosztási módszereit ismertető cikkben olvashat.

Az SAP HANA-t futtató virtuális gépek esetében statikus IP-címeket kell hozzárendelni. Ennek oka, hogy a HANA néhány konfigurációs attribútuma hivatkozik az IP-címekre.

Az Azure Hálózati biztonsági csoportok (NSG-k) az SAP HANA-példányra vagy a jumpboxra irányított forgalom irányítására szolgálnak. Az NSG-k és végül az alkalmazásbiztonsági csoportok az SAP HANA alhálózathoz és a Felügyeleti alhálózathoz vannak társítva.

Ha helyek közötti kapcsolat nélkül szeretné üzembe helyezni az SAP HANA-t az Azure-ban, akkor is védeni szeretné az SAP HANA-példányt a nyilvános internetről, és el szeretné rejteni egy előremutató proxy mögött. Ebben az alapforgatókönyvben az üzembe helyezés az Azure beépített DNS-szolgáltatásaira támaszkodik a gazdagépnevek feloldásához. Egy összetettebb környezetben, ahol nyilvános IP-címeket használnak, az Azure beépített DNS-szolgáltatásai különösen fontosak. Az Azure NSG-k és az Azure NVA-k segítségével vezérelheti és figyelheti az útválasztást az internetről az Azure-beli Azure VNet-architektúrába. Az alábbi képen egy durva séma látható az SAP HANA központi és küllős virtuális hálózatok architektúrájában helyek közötti kapcsolat nélkül történő üzembe helyezéséhez:

Durva üzembehelyezési séma az SAP HANA-hoz helyek közötti kapcsolat nélkül

A magas rendelkezésre állású hálózati virtuális berendezések üzembe helyezése című cikkben további leírást talál arról, hogyan vezérelheti és figyelheti az Azure NVA-kat az internetről a küllős virtuális hálózat architektúrája nélkül.

Óraforrás beállításai Az Azure-beli virtuális gépeken

Az SAP HANA megbízható és pontos időzítési információkat igényel az optimális teljesítmény érdekében. Az Azure-hipervizoron futó Azure-beli virtuális gépek hagyományosan csak a Hyper-V TSC-oldalt használták alapértelmezett óraforrásként. A hardverek, a gazdagép operációs rendszerének és a Linux-vendég operációs rendszer kerneleinek technológiai fejlődése lehetővé tette az "Invariant TSC" óraforrásként való biztosítását néhány Azure-beli virtuálisgép-termékváltozaton.

A Hyper-V TSC-oldal (hyperv_clocksource_tsc_page) az összes Azure-beli virtuális gépen támogatott óraforrásként. Ha a mögöttes hardver, a hipervizor és a vendég operációs rendszer linuxos kernelje támogatja az Invariant TSC-t, tsc elérhető és támogatott óraforrásként lesz elérhető és támogatott az Azure-beli virtuális gépeken futó vendég operációs rendszerben.

Azure-infrastruktúra konfigurálása az SAP HANA vertikális felskálázásához

Az OLAP- vagy S/4HANA-méretezéshez minősített Azure-beli virtuálisgép-típusok megkereséséhez tekintse meg az SAP HANA hardverkönyvtárát. A "Fürtözés" oszlopban lévő pipa a vertikális felskálázás támogatását jelzi. Az alkalmazás típusa azt jelzi, hogy támogatott-e az OLAP vertikális felskálázása vagy az S/4HANA vertikális felskálázása. A vertikális felskálázásban minősített csomópontokkal kapcsolatos részletekért tekintse át az SAP HANA hardverkönyvtárában felsorolt adott virtuálisgép-termékváltozat bejegyzését.

A vertikális felskálázási konfigurációk Azure-beli virtuális gépeken való üzembe helyezéséhez szükséges minimális operációsrendszer-kiadások, tekintse meg az SAP HANA hardverkönyvtárában felsorolt konkrét virtuálisgép-termékváltozat bejegyzéseinek részleteit. Az n-csomópontos OLAP vertikális felskálázási konfigurációban egy csomópont működik fő csomópontként. A többi csomópont a minősítési korlátig feldolgozó csomópontként működik. A több készenléti csomópont nem számít bele a minősített csomópontok számába

Feljegyzés

Az SAP HANA azure-beli virtuálisgép-kibővített üzembe helyezése készenléti csomóponttal csak az Azure NetApp Files storage használatával lehetséges. Nincs más SAP HANA-tanúsítvánnyal rendelkező Azure Storage, amely lehetővé teszi az SAP HANA készenléti csomópontok konfigurálását

A /hana/shared esetében az Azure NetApp Files vagy az Azure Files használatát javasoljuk.

Az Azure NetApp Filesban üzembe helyezett, kibővített konfigurációban /hana/shared lévő egyetlen csomópont tipikus alapszintű kialakítása a következőképpen néz ki:

Diagram, amely egy vertikális felskálázási konfigurációban lévő egyetlen csomópont tipikus alaptervét mutatja be.

A virtuálisgép-csomópont alapkonfigurációja az SAP HANA vertikális felskálázásához a következőképpen néz ki:

  • A /hana/shared esetében az Azure NetApp Files vagy az Azure Files natív NFS szolgáltatását használja.
  • Az összes többi lemezkötet nincs megosztva a különböző csomópontok között, és nem az NFS-en alapulnak. A nem megosztott /hana/adatokkal és /hana/naplókkal rendelkező, kibővített HANA-telepítések telepítési konfigurációit és lépéseit a dokumentum későbbi részében találja. A használható HANA-tanúsítvánnyal rendelkező tárolók esetében tekintse meg az SAP HANA Azure-beli virtuális gépek tárolókonfigurációiról szóló cikket.

A kötetek vagy lemezek méretezéséhez ellenőriznie kell az SAP HANA TDI tárolási követelményeit, hogy a szükséges méret a feldolgozó csomópontok számától függ. A dokumentum kiad egy képletet, amelyre alkalmaznia kell a kötet szükséges kapacitásának lekéréséhez

A kibővített SAP HANA virtuális gép egyetlen csomópontkonfigurációjának ábráin a többi tervezési feltétel a virtuális hálózat, vagy jobb az alhálózati konfiguráció. Az SAP erősen javasolja az ügyfél/alkalmazás elkülönítését a HANA-csomópontok közötti kommunikációtól. Ahogy a ábrán látható, ez a cél úgy érhető el, hogy két különböző virtuális hálózati adapter van csatlakoztatva a virtuális géphez. Mindkét virtuális hálózati adapter különböző alhálózatokban található, két különböző IP-címmel rendelkezik. Ezután útválasztási szabályokkal vezérelheti a forgalom áramlását NSG-k vagy felhasználó által megadott útvonalak használatával.

Különösen az Azure-ban nincsenek eszközök és módszerek a szolgáltatásminőség és a kvóták meghatározott virtuális hálózati adaptereken való kikényszerítésére. Ennek eredményeképpen az ügyfél-/alkalmazásoldali és csomóponton belüli kommunikáció elkülönítése nem teremt lehetőséget az egyik adatfolyam rangsorolására a másikon. Ehelyett az elkülönítés a kiskálázott konfigurációk csomóponton belüli kommunikációjának védelmében továbbra is a biztonság mértéke marad.

Feljegyzés

Az SAP javasolja a hálózati forgalom elkülönítését az ügyfél-/alkalmazásoldalra és a csomóponton belüli forgalomra a jelen dokumentumban leírtak szerint. Ezért javasoljuk, hogy az architektúra az utolsó ábrán látható módon legyen üzembe helyezve. A javaslattól eltérő követelményekért forduljon a biztonsági és megfelelőségi csapathoz

Hálózati szempontból a minimálisan szükséges hálózati architektúra a következőképpen nézne ki:

Egyetlen csomópont vertikális felskálázási alapjai

Az SAP HANA kibővíthető n Azure-beli telepítése

A kibővített SAP-konfiguráció telepítése során a következőket kell elvégeznie:

  • Új vagy meglévő Azure VNet-infrastruktúra üzembe helyezése
  • Az új virtuális gépek üzembe helyezése az Azure Managed Premium Storage, ultralemezkötetek és/vagy NFS-kötetek használatával az ANF alapján
    • Módosítsa a hálózati útválasztást, hogy például a virtuális gépek közötti csomóponton belüli kommunikáció ne NVA-n keresztül legyen irányítva.
  • Telepítse az SAP HANA fő csomópontot.
  • Az SAP HANA fő csomópont konfigurációs paramétereinek adaptálása
  • Folytassa az SAP HANA-feldolgozó csomópontok telepítésével

Az SAP HANA telepítése a kibővített konfigurációban

Az Azure-beli virtuálisgép-infrastruktúra üzembe helyezése és az összes egyéb előkészületek elvégzése után az alábbi lépésekben telepítenie kell az SAP HANA kibővített konfigurációit:

  • Az SAP HANA fő csomópontjának telepítése az SAP dokumentációjának megfelelően
  • Ha az Azure Premium Storage vagy az Ultra disk Storage szolgáltatást nem megosztott lemezekkel /hana/data /hana/loghasználja, adja hozzá a paramétert basepath_shared = no a global.ini fájlhoz. Ez a paraméter lehetővé teszi az SAP HANA számára, hogy a csomópontok közötti megosztás /hana/data és /hana/log kötetek nélkül futtassa a vertikális felskálázást. A részleteket az SAP Megjegyzés #2080991 tartalmazza. Ha A /hana/data és /hana/log ANF-alapú NFS-köteteket használ, nem kell ezt a módosítást elvégeznie
  • A global.ini paraméter végleges módosítása után indítsa újra az SAP HANA-példányt
  • További feldolgozó csomópontok hozzáadása. További információ: Gazdagépek hozzáadása a parancssori felület használatával. Adja meg az SAP HANA csomópontok közötti kommunikációjának belső hálózatát a telepítés során vagy azt követően, például a helyi hdblcm használatával. Részletesebb dokumentációt az SAP Note #2183363 című témakörben talál.

Az SAP HANA kibővített rendszer készenléti csomóponttal való beállításához tekintse meg a SUSE Linux telepítési utasításait vagy a Red Hat üzembe helyezési utasításait.

SAP HANA Dynamic Tiering 2.0 Azure-beli virtuális gépekhez

Az Azure M sorozatú virtuális gépeken futó SAP HANA-tanúsítványok mellett az SAP HANA Dynamic Tiering 2.0 a Microsoft Azure-ban is támogatott. További információ: A DT 2.0 dokumentációjának hivatkozásai. Nincs különbség a termék telepítésében vagy üzemeltetésében. Az SAP HANA-pilótafülkét például egy Azure-beli virtuális gépen belül telepítheti. Az Azure hivatalos támogatásához azonban a következő szakaszban ismertetett kötelező követelmények vonatkoznak. A cikk során a "DT 2.0" rövidítés lesz használva a 2.0-s dinamikus rétegzés teljes neve helyett.

Az SAP HANA Dynamic Tiering 2.0-t az SAP BW vagy az S4HANA nem támogatja. A fő használati esetek jelenleg natív HANA-alkalmazások.

Áttekintés

Az alábbi kép áttekintést nyújt a DT 2.0 Microsoft Azure-beli támogatásáról. A hivatalos minősítésnek való megfeleléshez kötelező követelményeknek kell megfelelnie:

  • A DT 2.0-t egy dedikált Azure-beli virtuális gépen kell telepíteni. Előfordulhat, hogy nem ugyanazon a virtuális gépen fut, amelyen az SAP HANA fut
  • Az SAP HANA és a DT 2.0 virtuális gépeket ugyanabban az Azure-beli virtuális hálózaton kell üzembe helyezni
  • Az SAP HANA- és DT 2.0-s virtuális gépeket az Azure gyorsított hálózatkezelésének engedélyezésével kell üzembe helyezni
  • A DT 2.0 virtuális gépek tárolási típusának Azure Premium Storage-nak kell lennie
  • Több Azure-lemezt kell csatlakoztatni a DT 2.0 virtuális géphez
  • Szoftveres raid/csíkos kötetet kell létrehozni (akár lvm-en, akár mdadm-en keresztül) az Azure-lemezek csíkozásával

További részletek a következő szakaszokban lesznek ismertetve.

AZ SAP HANA DT 2.0 architektúrája – áttekintés

Dedikált Azure-beli virtuális gép SAP HANA DT 2.0-hoz

Az Azure IaaS-ben a DT 2.0 csak dedikált virtuális gépen támogatott. A DT 2.0 nem futtatható ugyanazon az Azure-beli virtuális gépen, amelyen a HANA-példány fut. Kezdetben két virtuálisgép-típus használható az SAP HANA DT 2.0 futtatásához:

  • M64-32ms
  • E32sv3

További információ a virtuális gép típusának leírásáról: Azure-beli virtuálisgép-méretek – Memória

Tekintettel a DT 2.0 alapgondolatára, amely a "meleg" adatok kiszervezéséről szól a költségek csökkentése érdekében, érdemes a megfelelő virtuálisgép-méreteket használni. A lehetséges kombinációkra vonatkozóan azonban nincs szigorú szabály. Ez az adott ügyfél számítási feladatától függ.

Ajánlott konfigurációk:

SAP HANA virtuális gép típusa DT 2.0 virtuális gép típusa
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Az SAP HANA-tanúsítvánnyal rendelkező M sorozatú virtuális gépek és a támogatott DT 2.0 virtuális gépek (M64-32ms és E32sv3) összes kombinációja lehetséges.

Azure-hálózatkezelés és SAP HANA DT 2.0

A DT 2.0 dedikált virtuális gépen való telepítéséhez hálózati átviteli sebesség szükséges a DT 2.0 virtuális gép és a legalább 10 Gb-os SAP HANA virtuális gép között. Ezért kötelező minden virtuális gépet ugyanabban az Azure-beli virtuális hálózatban elhelyezni, és engedélyezni az Azure gyorsított hálózatkezelését.

További információ az Azure gyorsított hálózatkezeléséről : Azure-beli virtuális gép létrehozása gyorsított hálózatkezeléssel az Azure CLI használatával

Virtuálisgép-tároló az SAP HANA DT 2.0-hoz

A DT 2.0 ajánlott eljárásainak útmutatása szerint a lemez IO-átviteli sebességének fizikai magonként legalább 50 MB/s-nak kell lennie.

A DT 2.0-s verzióban támogatott két Azure-beli virtuálisgép-típus specifikációi szerint a virtuális gép maximális lemez I/O-átviteli sebességkorlátja a következőképpen néz ki:

  • E32sv3: 768 MB/s (nem csatlakoztatott), ami fizikai magonként 48 MB/s arányt jelent
  • M64-32 ms: 1000 MB/s (nem csatlakoztatott), ami fizikai magonként 62,5 MB/s arányt jelent

Több Azure-lemezt kell csatlakoztatni a DT 2.0 virtuális géphez, és létre kell hoznia egy szoftveres raidet (csíkozást) az operációs rendszer szintjén, hogy elérje a virtuális gépenkénti maximális lemezteljesítmény-korlátot. Egyetlen Azure-lemez nem tudja biztosítani az átviteli sebességet a maximális virtuálisgép-korlát eléréséhez ebben a tekintetben. Az Azure Premium Storage kötelező a DT 2.0 futtatásához.

A méretkövetelményektől függően különböző lehetőségek állnak rendelkezésre a virtuális gép maximális átviteli sebességének eléréséhez. Az alábbi lehetséges adatkötet-lemezkonfigurációk minden DT 2.0-s virtuálisgép-típushoz a virtuális gép felső átviteli sebességkorlátjának eléréséhez szükségesek. Az E32sv3 virtuális gépet a kisebb számítási feladatok belépési szintjének kell tekinteni. Ha kiderül, hogy nem elég gyors, szükség lehet a virtuális gép M64-32ms méretre való átméretezésére. Mivel az M64-32ms virtuális gép sok memóriával rendelkezik, előfordulhat, hogy az IO-terhelés nem éri el a korlátot, különösen az olvasásigényes számítási feladatok esetében. Ezért a csíkkészlet kevesebb lemeze elegendő lehet az ügyfélspecifikus számítási feladattól függően. A biztonságos oldalon azonban az alábbi lemezkonfigurációk lettek kiválasztva, hogy garantálják a maximális átviteli sebességet:

Virtuális gép termékváltozata Lemezkonfiguráció 1 Lemezkonfiguráció 2 Lemezkonfiguráció 3 Lemezkonfiguráció 4 Lemezkonfiguráció 5
M64-32ms 4 x P50 –> 16 TB 4 x P40 –> 8 TB 5 x P30 –> 5 TB 7 x P20 –> 3,5 TB 8 x P15 –> 2 TB
E32sv3 3 x P50 –> 12 TB 3 x P40 –> 6 TB 4 x P30 –> 4 TB 5 x P20 –> 2,5 TB 6 x P15 –> 1,5 TB

Különösen abban az esetben, ha a számítási feladat írásvédett, növelheti az IO-teljesítményt, hogy bekapcsolja az Azure-gazdagyorsítótár "írásvédett" funkcióját az adatbázisszoftver adatköteteihez ajánlott módon. Míg a tranzakciónaplóhoz az Azure-gazdalemez gyorsítótárának "nincs" értékűnek kell lennie.

A naplókötet méretét illetően az ajánlott kiindulópont az adatméret 15%-a heurisztikus. A naplókötet létrehozása a költségektől és az átviteli sebesség követelményeitől függően különböző Azure-lemeztípusok használatával valósítható meg. A naplókötethez magas I/O-átviteli sebesség szükséges.

Az M64-32ms típusú virtuális gép használatakor kötelező engedélyezni az Írásgyorsítót. Az Azure Write Accelerator optimális lemezírási késést biztosít a tranzakciónaplóhoz (csak M sorozat esetén érhető el). Vannak olyan elemek, amelyeket figyelembe kell venni, például a virtuálisgép-típusonkénti lemezek maximális számát. Az Írásgyorsítóval kapcsolatos részletek az Azure Write Accelerator oldalán találhatók

Íme néhány példa a naplókötet méretezésére:

adatkötet mérete és lemeztípusa naplókötet és lemeztípus konfigurációja 1 naplókötet és lemeztípus konfigurációja 2
4 x P50 –> 16 TB 5 x P20 –> 2,5 TB 3 x P30 –> 3 TB
6 x P15 –> 1,5 TB 4 x P6 –> 256 GB 1 x P15 –> 256 GB

Az SAP HANA vertikális felskálázásához hasonlóan a /hana/shared könyvtárat is meg kell osztani az SAP HANA virtuális gép és a DT 2.0 virtuális gép között. A magas rendelkezésre állású NFS-kiszolgálóként működő, dedikált virtuális gépek használatával végzett SAP HANA-méretezés architektúrája ajánlott. Megosztott biztonsági mentési kötet biztosításához az azonos kialakítás használható. De az ügyfélen múlik, hogy szükség lenne-e a HA-ra, vagy elegendő egy dedikált virtuális gépet használni, amely elegendő tárkapacitással rendelkezik a biztonsági mentési kiszolgálóként való működéshez.

Az SAP HANA Azure-beli virtuális gépeken való üzembe helyezésének műveletei

A következő szakaszok az SAP HANA-rendszerek Azure-beli virtuális gépeken való üzembe helyezésével kapcsolatos néhány műveletet ismertetik.

Műveletek biztonsági mentése és visszaállítása Azure-beli virtuális gépeken

Az alábbi dokumentumok az SAP HANA-telepítés biztonsági mentését és visszaállítását ismertetik:

SAP HANA-t tartalmazó virtuális gépek indítása és újraindítása

Az Azure nyilvános felhő egyik kiemelkedő funkciója, hogy csak a számítási percekért kell fizetnie. Ha például egy SAP HANA-t futtató virtuális gépet állít le, a rendszer csak az adott idő alatt felmerülő tárolási költségekért számít fel díjat. Egy másik funkció akkor érhető el, ha statikus IP-címeket ad meg a virtuális gépekhez a kezdeti üzembe helyezés során. Ha sap HANA-val rendelkező virtuális gépet indít újra, a virtuális gép a korábbi IP-címeivel újraindul.

A SAProuter használata az SAP távoli támogatásához

Ha helyek közötti kapcsolat van a helyszíni helyek és az Azure között, és SAP-összetevőket futtat, akkor valószínűleg már futtatja az SAProutert. Ebben az esetben végezze el a következő elemeket a távoli támogatáshoz:

  • A SAProuter konfigurációban az SAP HANA-t üzemeltető virtuális gép privát és statikus IP-címének karbantartása.
  • Konfigurálja a HANA virtuális gépet futtató alhálózat NSG-jének konfigurálását a 3299-ben lévő TCP/IP-porton keresztüli forgalom engedélyezéséhez.

Ha az interneten keresztül csatlakozik az Azure-hoz, és nem rendelkezik SAP-útválasztóval a virtuális géphez az SAP HANA-val, akkor telepítenie kell az összetevőt. Telepítse a SAProutert egy külön virtuális gépre a Felügyeleti alhálózaton. Az alábbi képen egy durva séma látható az SAP HANA helyek közötti kapcsolat nélküli és SAProuterrel való üzembe helyezéséhez:

Durva üzembehelyezési séma az SAP HANA-hoz helyek közötti kapcsolat és SAProuter nélkül

A SAProutert ne a Jumpbox virtuális gépre, hanem egy külön virtuális gépre telepítse. A különálló virtuális gépnek statikus IP-címmel kell rendelkeznie. Ha az SAP által üzemeltetett SAProuterhez szeretné csatlakoztatni a SAProutert, forduljon az SAP-hoz egy IP-címért. (Az SAP által üzemeltetett SAProuter a virtuális gépre telepített SAProuter-példány megfelelője.) A SAProuter-példány konfigurálásához használja az SAP IP-címét. A konfigurációs beállításokban az egyetlen szükséges port a 3299-s TCP-port.

A távoli támogatási kapcsolatok SAProuteren keresztüli beállításával és fenntartásával kapcsolatos további információkért tekintse meg az SAP dokumentációját.

Magas rendelkezésre állás az SAP HANA-val natív Azure-beli virtuális gépeken

Ha SUSE Linux Enterprise Servert vagy Red Hat-t futtat, létrehozhat egy Pacemaker-fürtöt kerítéseszközökkel. Az eszközökkel olyan SAP HANA-konfigurációt állíthat be, amely szinkron replikációt használ a HANA rendszerreplikálással és az automatikus feladatátvétellel. További információt a "következő lépések" szakaszban talál.

Következő lépések

A felsorolt cikkek megismerése