SAP számításifeladat-konfigurációk az Azure Availability Zones szolgáltatással

  • Cikk

Az Azure rendelkezésre állási csoportjaiban a különböző SAP-architektúrarétegek üzembe helyezésén kívül az Azure Rendelkezésre állási zónák az SAP számítási feladatok üzembe helyezéséhez is használhatók. Az Azure rendelkezésre állási zónája a következő: "Egyedi fizikai helyek egy régión belül. Minden zóna egy vagy több, független energiaellátással, hűtéssel és hálózatkezeléssel felszerelt adatközpontból áll." Az Azure rendelkezésre állási zónák nem minden régióban érhetők el. A rendelkezésre állási zónákat biztosító Azure-régiók esetében tekintse meg az Azure régiótérképét. Ez a térkép megmutatja, hogy mely régiók biztosítják vagy jelentik be a rendelkezésre állási zónákat.

Az SAP NetWeaver vagy az S/4HANA tipikus architektúrája szerint három különböző réteget kell védenie:

  • SAP-alkalmazásréteg, amely egy-néhány tucat virtuális gép lehet. Minimalizálni szeretné annak az esélyét, hogy a virtuális gépek ugyanazon a gazdagépkiszolgálón lesznek üzembe helyezve. Azt is szeretné, hogy ezek a virtuális gépek elfogadható közelségben legyenek a DBMS-réteghez, hogy elfogadható ablakban tartsák a hálózati késést
  • SAP ASCS/SCS réteg, amely az SAP NetWeaver és az S/4HANA architektúra egyetlen meghibásodási pontját képviseli. Általában két olyan virtuális gépet tekinthet meg, amelyeket feladatátvételi keretrendszerrel szeretne lefedni. Ezért ezeket a virtuális gépeket különböző infrastruktúra-tartalék tartományokban kell lefoglalni
  • SAP DBMS-réteg, amely egyetlen meghibásodási pontot is jelöl. A szokásos esetekben a feladatátvételi keretrendszer által lefedett két virtuális gépből áll. Ezért ezeket a virtuális gépeket különböző infrastruktúra-tartalék tartományokban kell lefoglalni. Kivételt képeznek az SAP HANA kibővíthető üzembe helyezései, amelyekben kétnál több virtuális gép használható

A kritikus virtuális gépek rendelkezésre állási csoportokon vagy rendelkezésre állási zónákon keresztül történő üzembe helyezése közötti fő különbségek a következők:

  • A rendelkezésre állási csoportokkal való üzembe helyezés a készleten belüli virtuális gépeket egyetlen zónában vagy adatközpontban helyezi el (bármi is legyen az adott régióra érvényes). Ennek eredményeképpen a rendelkezésre állási csoporton keresztüli üzembe helyezést nem védik a zóna egészének adatcetereit érintő energia-, hűtési vagy hálózatkezelési problémák. A plusz oldalon a virtuális gépek igazodnak az adott zónán vagy adatközponton belüli frissítési és tartalék tartományokhoz. Különösen az SAP ASCS- vagy DBMS-réteg esetében, ahol rendelkezésre állási csoportonként két virtuális gépet védünk, a tartalék tartományokhoz való igazítás megakadályozza, hogy mindkét virtuális gép ugyanazon a gazdagéphardveren végződjön.
  • Ha virtuális gépeket helyez üzembe az Azure rendelkezésre állási zónákon keresztül, és különböző zónákat választ (legfeljebb három lehetséges), a virtuális gépeket a különböző fizikai helyeken fogja üzembe helyezni, és ezzel védelmet nyújt az energia-, hűtési vagy hálózatkezelési problémák ellen, amelyek a zóna egészét érintő adatceter(ek)et érintik. Mivel azonban ugyanabban a virtuálisgép-családban több virtuális gépet helyez üzembe ugyanabban a rendelkezésre állási zónában, nincs védelem azokkal a virtuális gépekkel kapcsolatban, amelyek ugyanazon gazdagépen vagy tartalék tartományban végződnek. Ennek eredményeképpen a rendelkezésre állási zónákon keresztüli üzembe helyezés ideális az SAP ASCS- és DBMS-réteghez, ahol általában két virtuális gépet tekintünk meg. A két virtuális gépnél drasztikusan több SAP-alkalmazásréteg esetében előfordulhat, hogy vissza kell esnie egy másik üzemi modellre (lásd később)

Az azure-beli rendelkezésre állási zónákban való üzembe helyezés motivációja az, hogy Ön az egyetlen kritikus virtuális gép meghibásodása vagy a szoftverjavítások állásidejének csökkentésén felül védelmet szeretne nyújtani az olyan nagyobb infrastruktúra-problémák ellen, amelyek egy vagy több Azure-adatközpont rendelkezésre állását befolyásolhatják.

Egy másik rugalmassági üzembehelyezési funkcióként az Azure bevezette a virtuálisgép-méretezési csoportokat rugalmas vezényléssel az SAP-számítási feladatokhoz. A virtuálisgép-méretezési csoport a platform által felügyelt virtuális gépek logikai csoportosítását biztosítja. A virtuálisgép-méretezési csoport rugalmas vezénylése lehetővé teszi a méretezési csoport régión belüli létrehozását, vagy a rendelkezésre állási zónák közötti skálázást. A létrehozáskor a rugalmas méretezési csoport egy régióban a PlatformFaultDomainCount>1 (FD>1) használatával, a méretezési csoportban üzembe helyezett virtuális gépek adott számú tartalék tartomány között lesznek elosztva ugyanabban a régióban. Másrészt a rugalmas méretezési csoport rendelkezésre állási zónák közötti létrehozása a PlatformFaultDomainCount=1 (FD=1) használatával elosztja a virtuális gépeket különböző zónák között, és a méretezési csoport az egyes zónákban lévő virtuális gépeket is a lehető legjobb erőfeszítéssel osztja el. AZ SAP-számítási feladatok esetében csak az FD=1 rugalmas méretezési csoport támogatott. A rugalmas méretezési csoportok és az FD=1 együttes használatának előnye a zónák közötti üzembe helyezéshez, a hagyományos rendelkezésre állási zónák helyett az, hogy a méretezési csoporttal üzembe helyezett virtuális gépek a lehető legjobb munkamennyiséggel oszlanak el a zónán belüli különböző tartalék tartományok között. További információkért tekintse meg az SAP számítási feladataihoz készült rugalmas méretezési csoport üzembehelyezési útmutatóját.

A rendelkezésre állási zónák közötti üzembe helyezés szempontjai

A rendelkezésre állási zónák használatakor vegye figyelembe a következőket:

  • Az Azure Rendelkezésre állási zónák közötti maximális hálózati kerekítési késés a dokumentumrégiókban és a rendelkezésre állási zónákban van megosztva.
  • A tapasztalt hálózati kerekítési késés nem feltétlenül jelzi a különböző zónákat alkotó adatközpontok valós földrajzi távolságát. A hálózati lekerekítés késését a kábelösszekötők és a kábelek e különböző adatközpontok közötti útválasztása is befolyásolja.
  • A rendelkezésre állási zónák nem ideális dr. megoldás. A természeti katasztrófák széles körű károkat okozhatnak a világ régióiban, beleértve az energiainfrastruktúra súlyos károsodását is. Előfordulhat, hogy a különböző zónák közötti távolságok nem elég nagyok ahhoz, hogy megfelelő DR-megoldást alkotjanak.
  • A rendelkezésre állási zónák közötti hálózati késés nem azonos minden Azure-régióban. Bizonyos esetekben az SAP-alkalmazásréteget különböző zónákban is üzembe helyezheti és futtathatja, mivel az egy zónából az aktív DBMS virtuális gépre irányuló hálózati késés elfogadható. Egyes Azure-régiókban azonban előfordulhat, hogy az aktív DBMS virtuális gép és az SAP-alkalmazáspéldány közötti késés, amikor különböző zónákban vannak üzembe helyezve, nem feltétlenül elfogadható az SAP üzleti folyamatai számára. Ezekben az esetekben az üzembehelyezési architektúrának eltérőnek kell lennie az alkalmazás aktív/aktív architektúrájával, vagy egy aktív/passzív architektúrával, ahol a zónák közötti hálózati késés túl magas.
  • Amikor eldönti, hogy hol használja a rendelkezésre állási zónákat, a döntést a zónák közötti hálózati késésre alapozhatja. A hálózati késés két területen játszik fontos szerepet:
    • Késés a két dbMS-példány között, amelyeknek szinkron replikációra van szükségük. Minél nagyobb a hálózati késés, annál valószínűbb, hogy befolyásolja a számítási feladat méretezhetőségét.
    • Az SAP-párbeszédpanel-példányt zónában futtató virtuális gép és egy másik zónában lévő hasonló virtuális gép közötti hálózati késés különbsége. A különbség növekedésével az üzleti folyamatok és a kötegelt feladatok futási idejére gyakorolt hatás is nő, attól függően, hogy a dbMS-sel vagy egy másik zónában futnak-e zónán belül.

Amikor Azure-beli virtuális gépeket helyez üzembe a rendelkezésre állási zónákban, és feladatátvételi megoldásokat hoz létre ugyanazon az Azure-régión belül, bizonyos korlátozások érvényesek:

  • Az Azure-beli rendelkezésre állási zónákban való üzembe helyezéskor Azure Managed Diskst kell használnia.
  • A zóna-enumerálások fizikai zónákhoz való leképezése Azure-előfizetési alapon van rögzítve. Ha különböző előfizetéseket használ az SAP-rendszerek üzembe helyezéséhez, minden előfizetéshez meg kell határoznia az ideális zónákat. Ha össze szeretné hasonlítani a különböző előfizetések logikai leképezését, vegye figyelembe az Avzone-Mapping szkriptet
  • Az Azure rendelkezésre állási zónán belül csak akkor helyezhet üzembe Azure rendelkezésre állási csoportokat, ha az Azure Proximity Placement Groupot használja. Azt, hogy hogyan helyezheti üzembe az SAP DBMS-réteget és a központi szolgáltatásokat a zónák között, és hogyan helyezheti üzembe az SAP-alkalmazásréteget rendelkezésre állási csoportok használatával, és hogyan érheti el a virtuális gépek közelségét, az Azure Közelségi elhelyezési csoportok az SAP-alkalmazásokkal való optimális hálózati késés érdekében című cikkben található. Ha nem azure-beli közelségi elhelyezési csoportokat használ, ki kell választania az egyiket vagy a másikat a virtuális gépek üzembehelyezési keretrendszereként.
  • Az Azure Basic Load Balancerrel nem hozhat létre feladatátvevőfürt-megoldásokat a Windows Server feladatátvételi fürtszolgáltatás vagy a Linux Pacemaker használatával. Ehelyett az Azure Standard Load Balancer termékváltozatot kell használnia.

Az ideális rendelkezésre állási zónák kombinációja

Ha egy SAP NetWeaver vagy S/4HANA rendszert szeretne üzembe helyezni zónák között, két architektúramintát helyezhet üzembe:

  • Aktív/aktív: Az ASCS/SCS rendszerű virtuális gépek párja és a DBMS-réteget futtató virtuális gépek párja két zónában oszlik el. Az SAP-alkalmazásréteget futtató virtuális gépek száma egyenletes számban van üzembe helyezve ugyanazon a két zónán belül. Ha egy DBMS vagy ASCS/SCS virtuális gép feladatátvétele meghiúsul, előfordulhat, hogy a nyitott és aktív tranzakciók némelyike vissza lesz állítva. A felhasználók azonban továbbra is bejelentkezve maradnak. Nem igazán számít, hogy az aktív DBMS virtuális gép és az alkalmazáspéldányok mely zónákban futnak. Ez az architektúra a zónák közötti üzembe helyezés előnyben részesített architektúrája.
  • Aktív/passzív: Az ASCS/SCS rendszerű virtuális gépek párja és a DBMS-réteget futtató virtuális gépek párja két zónában oszlik el. Az SAP-alkalmazásréteget futtató virtuális gépek száma az egyik rendelkezésre állási zónában van üzembe helyezve. Az alkalmazásréteget ugyanabban a zónában futtatja, mint az aktív ASCS/SCS és DBMS-példány. Ezt az üzembehelyezési architektúrát akkor használja, ha a különböző zónák hálózati késése túl magas a zónák között elosztott alkalmazásréteg futtatásához. Ehelyett az SAP-alkalmazásrétegnek ugyanabban a zónában kell futnia, mint az aktív ASCS/SCS és/vagy DBMS-példány. Ha egy ASCS-/SCS- vagy DBMS-virtuális gép a másodlagos zónába lép át, nagyobb hálózati késéssel és az átviteli sebesség csökkentésével szembesülhet. A korábban feladatátvételi virtuális gépet a lehető leghamarabb vissza kell adnia, hogy visszatérjen az előző átviteli sebességszintre. Ha zónakimaradás történik, az alkalmazásréteget át kell adni a másodlagos zónába. Olyan tevékenység, amelyet a felhasználók teljes rendszerleállításként tapasztalnak. Néhány Azure-régióban ez az architektúra az egyetlen működőképes architektúra, ha rendelkezésre állási zónákat szeretne használni. Ha nem tudja elfogadni az ASCS/SCS vagy a DBMS virtuális gépek másodlagos zónába történő feladatátvételének lehetséges hatását, akkor jobb lehet, ha a rendelkezésre állási csoport üzemelő példányainál marad

Ezért mielőtt eldöntené a rendelkezésre állási zónák használatát, meg kell határoznia a következőt:

  • Az Azure-régió három zónája közötti hálózati késés. A régió zónái közötti hálózati késés ismerete lehetővé teszi, hogy a zónák közötti hálózati forgalomban a legkisebb hálózati késéssel rendelkező zónákat válassza ki.
  • A különbség a virtuális gépek közötti késés között az egyik zónán belül, az Ön által választott zónában és a hálózati késés között az Ön által választott két zónában.
  • Annak meghatározása, hogy az üzembe helyezni kívánt virtuálisgép-típusok elérhetők-e a kiválasztott két zónában. Egyes virtuálisgép-termékváltozatok esetén előfordulhat, hogy egyes termékváltozatok a három zóna közül csak kettőben érhetők el.

Hálózati késés zónák között és azon belül

A különböző zónák közötti késés meghatározásához a következőkre van szükség:

  • Helyezze üzembe a DBMS-példányhoz használni kívánt virtuálisgép-termékváltozatot mindhárom zónában. A mérés során győződjön meg arról, hogy az Azure Gyorsított hálózatkezelés engedélyezve van. Néhány év óta a gyorsított hálózatkezelés az alapértelmezett beállítás. Ennek ellenére ellenőrizze, hogy engedélyezve van-e és működik-e
  • Ha a legkisebb hálózati késéssel rendelkező két zónát találja, helyezzen üzembe a virtuálisgép-termékváltozat további három virtuális gépét, amelyeket alkalmazásréteg virtuális gépként szeretne használni a három rendelkezésre állási zónában. Mérje meg a hálózati késést a kiválasztott két DBMS-zónában lévő két DBMS virtuális géppel szemben.
  • Használjon niping mérőeszközként. Ezt az eszközt az SAP támogatási megjegyzései #500235 és #1100926 ismertetik. Összpontosítson a késési mérésekhez dokumentált parancsokra. Mivel a pingelés nem működik az Azure Gyorsított hálózatkezelési kód elérési útjai között, nem javasoljuk, hogy használja.

Ezeket a teszteket nem kell manuálisan elvégeznie. Egy PowerShell-eljárás rendelkezésre állási zónájának késési tesztje automatizálja a leírt késési teszteket.

A mérések és a virtuálisgép-termékváltozatok rendelkezésre állása alapján a rendelkezésre állási zónákban meg kell hoznia néhány döntést:

  • Adja meg a DBMS-réteg ideális zónáit.
  • Határozza meg, hogy el szeretné-e osztani az aktív SAP-alkalmazásréteget egy, két vagy mind a három zónában a zónák közötti hálózati késés és a zónák közötti különbségek alapján.
  • Határozza meg, hogy egy alkalmazás szempontjából aktív/passzív vagy aktív/aktív konfigurációt szeretne-e üzembe helyezni. (Ezeket a konfigurációkat a cikk későbbi részében ismertetjük.)

Ezen döntések meghozatalakor vegye figyelembe az SAP hálózati késési ajánlásait is, ahogyan az AZ SAP megjegyzésében #1100926 is szerepel.

Fontos

A mérések során használt Azure-előfizetésre vonatkozó mérések és döntések érvényesek. Ha másik Azure-előfizetést használ, az enumerált zónák leképezése eltérő lehet egy másik Azure-előfizetés esetében. Ennek eredményeképpen meg kell ismételnie a méréseket, vagy meg kell találnia az új előfizetés leképezését a régi előfizetéshez az Avzone-Mapping szkript eszközre.

Fontos

A korábban ismertetett mérések várhatóan eltérő eredményeket adnak minden olyan Azure-régióban, amely támogatja a rendelkezésre állási zónákat. Még ha a hálózati késési követelmények is azonosak, előfordulhat, hogy különböző üzembehelyezési stratégiákat kell alkalmaznia különböző Azure-régiókban, mert a zónák közötti hálózati késés eltérő lehet. Egyes Azure-régiókban a három különböző zóna hálózati késése jelentősen eltérő lehet. Más régiókban a három különböző zóna hálózati késése egységesebb lehet. Az az állítás, hogy a hálózati késés mindig 1 és 2 ezredmásodperc között van, nem helyes. Az Azure-régiók rendelkezésre állási zónái közötti hálózati késés nem általánosítható.

Aktív/aktív üzembe helyezés

Ezt az üzembehelyezési architektúrát azért nevezzük aktív/aktívnak, mert az aktív SAP-alkalmazáskiszolgálókat két vagy három zónában helyezi üzembe. Az enqueue replikációt használó SAP Central Services-példány két zóna között lesz üzembe helyezve. Ugyanez igaz a DBMS-rétegre is, amely az SAP Central Service-hez hasonló zónákban lesz üzembe helyezve. A konfiguráció mérlegelésekor meg kell találnia a régió két rendelkezésre állási zónáját, amelyek zónaközi hálózati késést biztosítanak, amely elfogadható a számítási feladathoz és a szinkron DBMS-replikációhoz. Azt is meg kell győződnie, hogy a kiválasztott zónákon belüli hálózati késés és a zónaközi hálózati késés közötti eltérés nem túl nagy.

Az SAP-architektúra jellege az, hogy ha nem konfigurálja másképp, a felhasználók és a kötegelt feladatok végrehajthatók a különböző alkalmazáspéldányokban. Ennek a ténynek az aktív/aktív üzembe helyezéssel az a mellékhatása, hogy a kötegelt feladatokat bármely SAP-alkalmazáspéldány végrehajthatja, függetlenül attól, hogy azok ugyanabban a zónában futnak-e az aktív DBMS-sel, vagy sem. Ha a különbségzónák közötti hálózati késés különbsége kicsi a zónán belüli hálózati késéshez képest, előfordulhat, hogy a kötegelt feladatok futási idejének különbsége nem lesz jelentős. Minél nagyobb a hálózati késés különbsége egy zónán belül a zóna hálózati forgalmához képest, annál nagyobb hatással lehet a kötegelt feladatok futási ideje, ha a feladatot olyan zónában hajtották végre, ahol a DBMS-példány nem aktív. Önön, mint ügyfélen múlik, hogy milyen elfogadható különbségek vannak a futási idő tekintetében. És ezzel együtt a zónák közötti forgalom elviselhető hálózati késése a számítási feladat számára.

Olyan Azure-régiók, ahol egy ilyen aktív/aktív üzembe helyezés anélkül lehetséges, hogy a különböző rendelkezésre állási zónákban üzembe helyezett alkalmazásrétegen belül jelentős különbség lenne a futási idő és az átviteli sebesség között, például:

  • Kelet-Ausztrália (a három zóna közül kettő)
  • Dél-Brazília (mindhárom zóna)
  • Közép-India (mindhárom zóna)
  • USA középső régiója (mindhárom zóna)
  • Kelet-Ázsia (mindhárom zóna)
  • USA keleti régiója (a három zóna közül kettő)
  • USA2 keleti régiója (mindhárom zóna)
  • Németország nyugati középső régiója (mindhárom zóna)
  • Izrael középső régiója (mindhárom zóna)
  • Észak-Olaszország (a három zóna közül kettő)
  • Korea középső régiója (mindhárom zóna)
  • Lengyelország középső régiója (mindhárom zóna)
  • Qatar Central (mindhárom zóna)
  • Észak-Európa (mindhárom zóna)
  • Kelet-Norvégia (a három zóna közül kettő)
  • Észak-Dél-Afrika (a három közül kettő)
  • USA déli középső régiója (mindhárom zóna)
  • Délkelet-Ázsia (mindhárom zóna)
  • Svédország középső régiója (mindhárom zóna)
  • Észak-Svájc (mindhárom zóna)
  • Egyesült Arab Emírségek északi régiója (mindhárom zóna)
  • Egyesült Királyság déli régiója (a három zóna közül kettő)
  • Nyugat-Európa (a három zóna közül kettő)
  • USA2 nyugati régiója (mindhárom zóna)
  • USA3 nyugati régiója (mindhárom zóna)

A megadott régiólista nem könnyíti meg Önt, hogy ügyfélként tesztelje a számítási feladatát, hogy eldöntse, lehetséges-e aktív/aktív üzembe helyezési architektúra.

Olyan Azure-régiók, ahol az aktív/aktív SAP üzembehelyezési architektúra nem lehetséges a zónák között, például:

  • Canada Central
  • France Central
  • Japan East

Bár az egyes számítási feladatok esetében ez működni fog. Ezért az architektúra kiválasztása előtt tesztelnie kell. Az Azure folyamatosan dolgozik a hálózatok minőségének és késésének javításán. Előfordulhat, hogy az évekkel ezelőtt végzett mérések már nem tükrözik az aktuális körülményeket.

Attól függően, hogy mit szeretne tolerálni a futásidejű különbségektől, más, nem felsorolt régiók is jogosultak lehetnek.

Egy aktív/aktív üzembe helyezés egyszerűsített sémája két zónában a következőképpen nézhet ki:

Active/Active zone deployment

A konfigurációra a következő szempontok vonatkoznak:

  • Az Azure Közelségi elhelyezési csoport használata esetén az Azure rendelkezésre állási zónákat az összes virtuális gép tartalék tartományaként kezeli, mivel a rendelkezésre állási csoportok nem helyezhetők üzembe az Azure rendelkezésre állási zónákban.
  • Ha a DBMS-réteghez és a központi szolgáltatásokhoz tartozó zónatelepítéseket szeretné kombinálni, de azure-beli rendelkezésre állási csoportokat szeretne használni az alkalmazásréteghez, az Azure közelségi csoportjait kell használnia az SAP-alkalmazásokkal való optimális hálózati késés érdekében az Azure Közelségi elhelyezési csoportok című cikkben leírtak szerint.
  • Az SAP Central Services feladatátvevő fürtöinek és a DBMS-réteg terheléselosztóinak az Azure Load Balancer standard termékváltozatát kell használnia. Az alapszintű Load Balancer nem működik a zónák között.
  • Az SAP-rendszer üzemeltetésére üzembe helyezett Azure-beli virtuális hálózat és annak alhálózatai zónákra terjednek ki. Nincs szükség külön virtuális hálózatokra és alhálózatokra az egyes zónákhoz.
  • Az összes üzembe helyezendő virtuális géphez Azure Managed Disks-t kell használnia. A nem felügyelt lemezek nem támogatottak a zónatelepítésekhez.
  • Az Azure Premium Storage, az Ultra SSD Storage vagy az ANF nem támogatja a zónák közötti tárreplikálást. A DBMS-üzemelő példányok esetében adatbázis-módszerekre támaszkodunk az adatok zónák közötti replikálásához
  • Az Azure Premium Fileson alapuló SMB- és NFS-megosztások esetében a szinkron replikációval rendelkező zonális redundancia érhető el. Ebben a dokumentumban ellenőrizheti, hogy rendelkezésre áll-e a ZRS az Azure Premium Fileshoz abban a régióban, amelyben üzembe szeretne helyezni. A zonális replikált NFS- és SMB-megosztások használatát teljes mértékben támogatja az SAP-alkalmazásréteg üzembe helyezése, valamint a NetWeaver vagy az S/4HANA központi szolgáltatások magas rendelkezésre állású feladatátvevő fürtjei. Az alábbi eseteket lefedő dokumentumok a következők:
  • A harmadik zóna az SBD-eszköz üzemeltetésére szolgál, ha su Standard kiadás Linux Pacemaker-fürtöt hoz létre, és az Azure Fencing Agent helyett SBD-eszközöket használ. Vagy további alkalmazáspéldányok esetén.
  • A kritikus üzleti folyamatok futásidejének konzisztenciájának elérése érdekében megpróbálhat bizonyos kötegfeladatokat és felhasználókat olyan alkalmazáspéldányokhoz irányítani, amelyek zónán belül vannak az aktív DBMS-példánnyal, SAP-kötegkiszolgáló-csoportokkal, SAP-bejelentkezési csoportokkal vagy RFC-csoportokkal. A zónaszintű feladatátvételi folyamat során azonban manuálisan kell áthelyeznie ezeket a csoportokat olyan virtuális gépeken futó példányokra, amelyek zónán belül vannak az aktív DB virtuális géppel.
  • Előfordulhat, hogy az egyes zónákban alvó párbeszédpanelpéldányokat szeretne üzembe helyezni.

Fontos

Ebben az aktív/aktív forgatókönyvben a zónák közötti forgalom díjai érvényesek. Tekintse meg a dokumentum sávszélesség-díjszabásának részleteit. Az SAP-alkalmazásréteg és az SAP DBMS-réteg közötti adatátvitel meglehetősen intenzív. Ezért az aktív/aktív forgatókönyv hozzájárulhat a költségekhez.

Aktív/passzív üzembe helyezés

Ha nem talál elfogadható eltérést az egy zónán belüli hálózati késés és a zónák közötti hálózati forgalom késése között, üzembe helyezhet egy olyan architektúrát, amely aktív/passzív karaktert használ az SAP-alkalmazásréteg szempontjából. Meghatároz egy aktív zónát, amely az a zóna, ahol a teljes alkalmazásréteget üzembe helyezi, és ahol az aktív DBMS-t és az SAP Central Services-példányt is megkísérli futtatni. Ilyen konfiguráció esetén meg kell győződnie arról, hogy nem rendelkezik szélsőséges futásidő-eltérésekkel attól függően, hogy egy feladat zónán belül fut-e az aktív DBMS-példánysal, vagy sem, üzleti tranzakciókban és kötegelt feladatokban.

Az Azure-régiók, ahol az ilyen típusú üzembehelyezési architektúra előnyösebb lehet a különböző zónákban:

  • Canada Central
  • France Central
  • Japan East
  • Norway East
  • South Africa North

Az architektúra alapszintű elrendezése így néz ki:

Active/Passive zone deployment

A konfigurációra a következő szempontok vonatkoznak:

  • A rendelkezésre állási csoportok nem helyezhetők üzembe az Azure Rendelkezésre állási zónákban. A mérséklés érdekében az Azure közelségi elhelyezési csoportjait az Azure Közelségi elhelyezési csoportok című cikkben leírtak szerint használhatja az SAP-alkalmazások optimális hálózati késéséhez.
  • Az architektúra használatakor szorosan figyelnie kell az állapotot, és meg kell próbálnia az aktív DBMS- és SAP Central Services-példányokat ugyanabban a zónában tartani, mint az üzembe helyezett alkalmazásréteg. Ha az SAP Central Service vagy a DBMS-példány feladatátvétele történt, győződjön meg arról, hogy a lehető leggyorsabban üzembe helyezett SAP-alkalmazásréteggel manuálisan vissza tud-e menni a zónába.
  • Az SAP Central Services feladatátvevő fürtöinek és a DBMS-réteg terheléselosztóinak az Azure Load Balancer standard termékváltozatát kell használnia. Az alapszintű Load Balancer nem működik a zónák között.
  • Az SAP-rendszer üzemeltetésére üzembe helyezett Azure-beli virtuális hálózat és annak alhálózatai zónákra terjednek ki. Nincs szükség külön virtuális hálózatokra az egyes zónákhoz.
  • Az összes üzembe helyezendő virtuális géphez Azure Managed Disks-t kell használnia. A nem felügyelt lemezek nem támogatottak a zónatelepítésekhez.
  • Az Azure Premium Storage, az Ultra SSD Storage vagy az ANF nem támogatja a zónák közötti tárreplikálást. A DBMS-üzemelő példányok esetében adatbázis-módszerekre támaszkodunk az adatok zónák közötti replikálásához
  • Az Azure Premium Fileson alapuló SMB- és NFS-megosztások esetében a szinkron replikációval rendelkező zonális redundancia érhető el. Ebben a dokumentumban ellenőrizheti, hogy rendelkezésre áll-e a ZRS az Azure Premium Fileshoz abban a régióban, amelyben üzembe szeretne helyezni. A zonális replikált NFS- és SMB-megosztások használatát teljes mértékben támogatja az SAP-alkalmazásréteg üzembe helyezése, valamint a NetWeaver vagy az S/4HANA központi szolgáltatások magas rendelkezésre állású feladatátvevő fürtjei. Az alábbi eseteket lefedő dokumentumok a következők:
  • A harmadik zóna az SBD-eszköz üzemeltetésére szolgál, ha su Standard kiadás Linux Pacemaker-fürtöt hoz létre, és az Azure Fencing Agent helyett SBD-eszközöket használ. Vagy további alkalmazáspéldányok esetén.
  • Alvó virtuális gépeket kell üzembe helyeznie a passzív zónában (DBMS-szempontból), hogy zónahiba esetén elindíthassa az alkalmazáserőforrásokat. Egy másik lehetőség az Azure Site Recovery használata, amely képes az aktív virtuális gépeket a zónák közötti alvó virtuális gépekre replikálni.
  • Érdemes olyan automatizálásba fektetnie, amely lehetővé teszi, hogy automatikusan elindítsa az SAP-alkalmazásréteget a második zónában, ha zónakimaradás történik.

Magas rendelkezésre állás és vészhelyreállítás együttes konfigurálása

A Microsoft nem oszt meg semmilyen információt a különböző Azure-rendelkezésre állási zónákat üzemeltető létesítmények közötti földrajzi távolságokról egy Azure-régióban. Egyes ügyfelek azonban zónákat használnak egy kombinált HA- és DR-konfigurációhoz, amely nulla helyreállításipont-célkitűzést (RPO- t) ígér. A nulla RPO azt jelenti, hogy még vészhelyreállítási esetekben sem szabad elveszítenie a véglegesített adatbázis-tranzakciókat.

Megjegyzés:

Javasoljuk, hogy csak bizonyos körülmények között használjon ehhez hasonló konfigurációt. Használhatja például, ha az adatok biztonsági vagy megfelelőségi okokból nem hagyhatják el az Azure-régiót.

Íme egy példa az ilyen konfigurációk megjelenésére:

Combined high-availability DR in zones

A konfigurációra a következő szempontok vonatkoznak:

  • Vagy feltételezi, hogy jelentős távolság van a rendelkezésre állási zónát üzemeltető létesítmények között, vagy egy bizonyos Azure-régióban kell maradnia. A rendelkezésre állási csoportok nem helyezhetők üzembe az Azure Rendelkezésre állási zónákban. Ennek kompenzálása érdekében az Azure közelségi elhelyezési csoportjait az Azure Proximity Placement Groups című cikkben leírtak szerint használhatja az SAP-alkalmazások optimális hálózati késéséhez.
  • Az architektúra használatakor szorosan figyelnie kell az állapotot, és meg kell kísérelnie az aktív DBMS- és SAP Central Services-példányokat ugyanabban a zónában, mint az üzembe helyezett alkalmazásréteg. Ha az SAP Central Service vagy a DBMS-példány feladatátvétele történt, győződjön meg arról, hogy a lehető leggyorsabban üzembe helyezett SAP-alkalmazásréteggel manuálisan vissza tud-e menni a zónába.
  • Az aktív minőségbiztosítási alkalmazáspéldányokat futtató virtuális gépeken előre telepítve kell lennie az éles alkalmazáspéldányoknak.
  • Zonális hiba esetén állítsa le a minőségbiztosítási alkalmazáspéldányokat, és indítsa el helyette az éles példányokat. A működéshez virtuális neveket kell használnia az alkalmazáspéldányokhoz.
  • Az SAP Central Services feladatátvevő fürtöinek és a DBMS-réteg terheléselosztóinak az Azure Load Balancer standard termékváltozatát kell használnia. Az alapszintű Load Balancer nem működik a zónák között.
  • Az SAP-rendszer üzemeltetésére üzembe helyezett Azure-beli virtuális hálózat és annak alhálózatai zónákra terjednek ki. Nincs szükség külön virtuális hálózatokra az egyes zónákhoz.
  • Az összes üzembe helyezendő virtuális géphez Azure Managed Disks-t kell használnia. A nem felügyelt lemezek nem támogatottak a zónatelepítésekhez.
  • Az Azure Premium Storage, az Ultra SSD Storage vagy az ANF nem támogatja a zónák közötti tárreplikálást. A DBMS-üzemelő példányok esetében adatbázis-módszerekre támaszkodunk az adatok zónák közötti replikálásához
  • Az Azure Premium Fileson alapuló SMB- és NFS-megosztások esetében a szinkron replikációval rendelkező zonális redundancia érhető el. Ebben a dokumentumban ellenőrizheti, hogy rendelkezésre áll-e a ZRS az Azure Premium Fileshoz abban a régióban, amelyben üzembe szeretne helyezni. A zonális replikált NFS- és SMB-megosztások használatát teljes mértékben támogatja az SAP-alkalmazásréteg üzembe helyezése, valamint a NetWeaver vagy az S/4HANA központi szolgáltatások magas rendelkezésre állású feladatátvevő fürtjei. Az alábbi eseteket lefedő dokumentumok a következők:
  • A harmadik zóna az SBD-eszköz üzemeltetésére szolgál, ha su Standard kiadás Linux Pacemaker-fürtöt hoz létre, és az Azure Fencing Agent helyett SBD-eszközöket használ.

Következő lépések

Íme néhány következő lépés az Azure rendelkezésre állási zónákban való üzembe helyezéshez: