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

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

  • Cikk

A különböző SAP-architektúrarétegek azure-beli rendelkezésre állási zónákban való üzembe helyezése ajánlott architektúra az Azure-beli SAP számítási feladatok üzembe helyezéséhez. 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. A cikk felsorolja, hogy mely régiók biztosítják a rendelkezésre állási zónákat. A nagyobb SAP-számítási feladatok üzemeltetésére alkalmas Azure-régiók többsége rendelkezésre állási zónákat biztosít. Az új Azure-régiók már a kezdetektől rendelkezésre állási zónákat biztosítanak. Néhány régebbi régió már vagy folyamatban van a rendelkezésre állási zónákkal való utólagos méretezés során.

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

  • Az SAP-alkalmazásréteg, amely egy-néhány tucat virtuális gép (VM) 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 az adatbázisréteghez, hogy elfogadható ablakban tartsák a hálózati késést
  • Az SAP ASCS/SCS réteg, amely egyetlen meghibásodási pontot jelöl az SAP NetWeaver és az S/4HANA architektúrában. Á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
  • Az SAP-adatbázisré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 adatközpontját érintő energia-, hűtési vagy hálózatkezelési problémák. Rendelkezésre állási csoportoknál a virtuális gép és a lemezek között nincs kényszerített igazítás. Azt jelenti, hogy a lemezek az Azure-régió bármely adatközpontjában lehetnek, függetlenül a régió zonális szerkezetétől. 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. Kifejezetten az SAP ASCS-hez vagy az adatbázisréteghez, 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.
  • A virtuális gépek Azure-beli rendelkezésre állási zónákon keresztüli üzembe helyezésekor és a különböző zónák (legfeljebb három lehetséges) kiválasztásakor a virtuális gépeket a különböző fizikai helyeken helyezik üzembe, és ezzel védelmet nyújtanak az energia-, hűtési vagy hálózatkezelési problémák ellen, amelyek a zóna egészére hatással vannak. A virtuális gépek és a hozzájuk kapcsolódó lemezek szintén ugyanabban a rendelkezésre állási zónában vannak elhelyezve. 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 az adatbázisréteg számára, ahol általában két virtuális gépet tekintünk meg. Az SAP-alkalmazásréteg esetében, amely két virtuális gépnél drasztikusan több lehet, előfordulhat, hogy egy másik üzemi modellre kell visszaesnie (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. 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 egy 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ákról további információt a Régiók és a rendelkezésre állási zónák című dokumentum tartalmaz.
  • 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.
  • Ha a rendelkezésre állási zónákat kis távolságú dr. megoldásként használja, vegye figyelembe, hogy olyan természeti katasztrófákat tapasztaltunk, amelyek a világ különböző régióiban széles körű károkat okoztak, beleértve az energiainfrastruktúra súlyos és széles körű károsodását is. Előfordulhat, hogy a különböző zónák közötti távolság nem mindig elég nagy ahhoz, hogy kompenzálja az ilyen nagyobb természeti katasztrófákat.
  • A rendelkezésre állási zónák közötti hálózati késés nem azonos minden Azure-régióban. Még az Azure-régión belül is eltérő lehet a hálózat késése a különböző zónák között. Bár még a legrosszabb esetben is, a HANA rendszerreplikáláson vagy az SQL Server Always On-on alapuló szinkron replikáció az adatbázis szintjén a számítási feladat méretezhetőségének befolyásolása nélkül fog működni.
  • 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 adatbázispéldány között, amelyeknek szinkron replikációval kell rendelkezniük. A legnagyobb NetWeaver és S/4HANA rendszereknek a nagyobb hálózati késéssel rendelkező zónák közötti nagyon sikeres műveletei alapján (kevesebb mint 1,5 ezredmásodperc) ez a szempont figyelmen kívül hagyható
    • A zónán belüli SAP-párbeszédpanelpéldányt 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 zónán belül futnak-e az adatbázissal vagy egy másik zónában (lásd a cikk későbbi szakaszát).
  • Az Azure Rendelkezésre állási zónák hálózati késése még a legnagyobb zónákban is elég alacsony az SAP üzleti folyamatok futtatásához. Eddig csak néhány kivételes esetet láttunk, amikor az ügyfeleknek egyetlen adatközpont hálózati gerince alatt kellett áthelyezni az SAP-alkalmazásréteget és az adatbázisréteget.

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. Az AZURE-adatbázisréteg és a központi szolgáltatások zónák közötti üzembe helyezésének módja, valamint az SAP-alkalmazásréteg üzembe helyezése rendelkezésre állási csoportok használatával és a virtuális gépek közelségének elérése érdekében az Azure Proximity 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 ExpressRoute Gateway, a VPN Gateway és a Standard nyilvános IP-címek zonális verzióját kell üzembe helyeznie a kívánt zonális védelem eléréséhez.

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

Ha nem konfigurálja az üzleti folyamat hozzárendelését olyan SAP-funkciókkal, mint a bejelentkezési csoportok, az RFC-kiszolgálócsoportok, a Batch-kiszolgálócsoportok és hasonlók, az üzleti folyamatok az SAP-alkalmazásréteg különböző alkalmazáspéldányaiban végrehajthatók. Ennek a ténynek 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 az aktív adatbázispéldánysal ugyanabban a zónában futnak-e. 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 az adatbázispé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. Pusztán technikai szempontból az Azure-régión belüli Azure rendelkezésre állási zónák közötti hálózati késések a NetWeaver, az S/4HANA vagy más SAP-alkalmazások architektúráját használják. Önön, mint ügyfélen is lehetséges, hogy a bejelentkezési csoportok, az RFC-kiszolgálócsoportok, a Batch Server-csoportok és hasonlók SAP-fogalmaival mérsékelje ezeket a különbségeket, amikor a cikkben bemutatott üzembe helyezési fogalmak valamelyike mellett dönt.

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 az adatbázisréteget futtató virtuális gépek párja két zóna között oszlik el. Az SAP-alkalmazásréteget futtató virtuális gépek páros számban vannak üzembe helyezve ugyanazon a két zónán belül. Ha egy adatbázis vagy az 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 adatbázis virtuális gépe é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. Azokban az esetekben, amikor a zónák közötti hálózati késések nagyobb különbségeket okoznak az üzleti folyamatok végrehajtása során, használhat olyan funkciókat, mint az SAP Bejelentkezési csoportok, az RFC-kiszolgálócsoportok, a Batch Server-csoportok, és hasonló módon irányíthatja az üzleti folyamatok végrehajtását az aktív adatbázispéldánysal azonos zónában lévő párbeszédpanel-példányokra
  • Aktív/passzív: Az ASCS/SCS rendszerű virtuális gépek párja és az adatbázisré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 az egyik rendelkezésre állási zónában vannak üzembe helyezve. Az alkalmazásréteget ugyanabban a zónában futtatja, mint az aktív ASCS/SCS és adatbázispéldány. Ezt az üzembehelyezési architektúrát akkor használhatja, ha túl magasnak tartja a különböző zónák hálózati késését. És ezzel elviselhetetlen különbségeket okoz az üzleti folyamatok futtatókörnyezetében. Vagy ha a rendelkezésre állási zónák üzembe helyezését rövid távú dr. üzemelő példányként szeretné használni. zónákat. Ha egy ASCS/SCS vagy adatbázis virtuális gép átjut a másodlagos zónába, előfordulhat, hogy nagyobb hálózati késést tapasztal, és ezzel csökkenti az átviteli sebességet. 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.

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 az adatbázispé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 zónában lévő két adatbázis virtuális gépével szemben.
  • Használjon niping mérőeszközként. Ezt az eszközt az SAP támogatási megjegyzései #500235 és #1100926 ismertetik. A hálózati késés besorolását az SAP Megjegyzés #1100926 durva útmutatásként kezeli. A 0,7 ezredmásodpercnél nagyobb hálózati késések nem jelentik azt, hogy a rendszer nem fog technikailag működni, vagy hogy az üzleti folyamatok nem felelnek meg az egyes SLA-knak. A megjegyzés nem arra szolgál, hogy az SAP és/vagy a Microsoft által támogatott vagy nem támogatott elemet adja meg. Ö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:

  • Az adatbázisréteg ideális zónáinak meghatározása.
  • 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.)

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 ki kell derítenie az új előfizetés leképezését a régi előfizetéshez képest az Avzone-Mapping szkript eszközhöz.

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 van üzembe helyezve. Ugyanez igaz az adatbázisrétegre is, amely az SAP Central Service-hez hasonló zónákban van üzembe helyezve. A konfiguráció mérlegelésekor meg kell találnia a régióban található két rendelkezésre állási zónát, amelyek zónaközi hálózati késést kínálnak, amely elfogadható a számítási feladat számára. Azt is tudni szeretné, hogy a kiválasztott zónákon belüli hálózati késés és a zónák közötti hálózati késés elfogadható-e a számítási feladat számára.

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:

Aktív/aktív zóna üzembe helyezése

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 az adatbázisré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 Azure Közelségi elhelyezési csoportok című cikkben leírtak szerint az SAP-alkalmazásokkal való optimális hálózati késés érdekében.
  • Az SAP Central Services feladatátvevő fürtöinek és az adatbázisrétegnek a terheléselosztóihoz 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 ExpressRoute Gateway, a VPN Gateway és a Standard nyilvános IP-címek zonális verzióját kell üzembe helyeznie a kívánt zonális védelem eléréséhez.
  • 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 SSD v2, az Ultra SSD Storage vagy az Azure NetApp Files nem támogatja a zónák közötti szinkron tárreplikálást. Adatbázis-üzemelő példányok esetében adatbázis-módszerekre támaszkodunk az adatok zónák közötti replikálásához.
  • A rendelkezésre állási zónák közötti szinkron zonális replikációt támogató prémium SSD v1-et még nem tesztelték SAP-adatbázis-számítási feladattal. Ezért az Azure Premium SSD v1 zonális szinkron replikációját nem támogatottnak kell tekinteni az SAP-adatbázis-számítási feladatok esetében.
  • 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 SUSE 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ötegelt feladatokat és felhasználókat olyan alkalmazáspéldányokhoz irányítani, amelyek zónán belül vannak az aktív adatbázispéldánysal, SAP batch-kiszolgá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-adatbázisré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 olyan konfigurációt, amely csökkenti az SAP üzleti folyamatainak futásidejében jelentkező lehetséges eltérést, vagy ha rövid távú vészhelyreállítási konfigurációt szeretne üzembe helyezni, az SAP-alkalmazásréteg szempontjából aktív/passzív karakterrel rendelkező architektúrát helyezhet üzembe. 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 adatbázispéldányt é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ási idővel, attól függően, hogy egy feladat zónán belül fut-e az aktív adatbázispéldánysal, vagy sem, üzleti tranzakciókban és kötegelt feladatokban.

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

Aktív/passzív zóna üzembe helyezése

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 adatbázispéldányt és az 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 az adatbázispé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 az adatbázisrétegnek a terheléselosztóihoz 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 ExpressRoute Gateway, a VPN Gateway és a Standard nyilvános IP-címek zonális verzióját kell üzembe helyeznie a kívánt zonális védelem eléréséhez.
  • 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 SSD v2, az Ultra SSD Storage vagy az Azure NetApp Files nem támogatja a zónák közötti szinkron tárreplikálást. Adatbázis-üzemelő példányok esetében adatbázis-módszerekre támaszkodunk az adatok zónák közötti replikálásához.
  • A rendelkezésre állási zónák közötti szinkron zonális replikációt támogató prémium SSD v1-et még nem tesztelték SAP-adatbázis-számítási feladattal. Ezért az Azure Premium SSD v1 konfigurálható zonális szinkron replikációját nem kell támogatottnak tekinteni az SAP-adatbázis-számítási feladatok esetében.
  • 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 SUSE 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 (adatbázis szempontjábó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 (rövid távolságú DR), amely nulla helyreállításipont-célkitűzést (RPO) í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.

Feljegyzés

Ha a rendelkezésre állási zónákat kis távolságú dr. megoldásként használja, vegye figyelembe, hogy a világ különböző régióiban kiterjedt károkat okozó természeti katasztrófákat tapasztaltunk, beleértve az energiainfrastruktúra súlyos és széles körű károsodását. Előfordulhat, hogy a különböző zónák közötti távolság nem mindig elég nagy ahhoz, hogy kompenzálja az ilyen nagyobb természeti katasztrófákat.

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

Kombinált magas rendelkezésre állású dr. zónákban

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 próbálnia az aktív adatbázispéldányt és az 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 az adatbázispé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 az adatbázisrétegnek a terheléselosztóihoz 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 ExpressRoute Gateway, a VPN Gateway és a Standard nyilvános IP-címek zonális verzióját kell üzembe helyeznie a kívánt zonális védelem eléréséhez.
  • 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 SSD v2, az Ultra SSD Storage vagy az Azure NetApp Files nem támogatja a zónák közötti szinkron tárreplikálást. Adatbázis-üzemelő példányok esetében adatbázis-módszerekre támaszkodunk az adatok zónák közötti replikálásához.
  • A rendelkezésre állási zónák közötti szinkron zonális replikációt támogató prémium SSD v1-et még nem tesztelték SAP-adatbázis-számítási feladattal. Ezért az Azure Premium SSD v1 konfigurálható zonális szinkron replikációját nem kell támogatottnak tekinteni az SAP-adatbázis-számítási feladatok esetében.
  • 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 SUSE 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: