A vészhelyreállítás áttekintése és az SAP számítási feladataira vonatkozó infrastruktúra-irányelvek
Az Azure-ban kritikus üzleti alkalmazásokat futtató szervezetek közül sokan magas rendelkezésre állási (HA) és vészhelyreállítási (DR) stratégiát is beállítanak. A magas rendelkezésre állás célja az üzleti rendszerek SLA-jának növelése az alapul szolgáló rendszerinfrastruktúra egyetlen meghibásodási pontjának megszüntetésével. A magas rendelkezésre állású technológiák csökkentik a nem tervezett infrastruktúra meghibásodásának hatását, és segítenek a tervezett karbantartásban. A vészhelyreállítás olyan szabályzatok, eszközök és eljárások, amelyek lehetővé teszik a létfontosságú technológiai infrastruktúra és rendszerek helyreállítását vagy folytatását egy földrajzilag széles körben elterjedt természeti vagy emberi katasztrófa után.
Az AZURE-beli SAP-számítási feladatok magas rendelkezésre állásának elérése érdekében a virtuális gépek általában rendelkezésre állási csoportokban, rendelkezésre állási zónákban vagy rugalmas méretezési csoportokban vannak üzembe helyezve, hogy megvédjék az alkalmazásokat az infrastruktúra karbantartásával vagy meghibásodásával szemben a régión belül. Az üzembe helyezés azonban nem védi az alkalmazásokat a régión belüli gyakori katasztrófáktól. Az alkalmazások regionális katasztrófáktól való védelme érdekében szükség van az alkalmazások vészhelyreállítási stratégiájára. A vészhelyreállítás dokumentált és strukturált megközelítés, amelynek célja, hogy segítse a szervezetet a helyreállítási folyamatok katasztrófa esetén történő végrehajtásában, valamint az informatikai szolgáltatások megszakadásának védelme vagy minimalizálása, valamint a helyreállítás elősegítése érdekében.
Ez a dokumentum részletesen ismerteti az SAP számítási feladatainak a nagy léptékű katasztrófa elleni védelmét strukturált DR-megközelítés implementálásával. A dokumentum részletei absztrakt szinten jelennek meg, különböző Azure-szolgáltatások és SAP-összetevők alapján. Az SAP-számítási feladat pontos DR-stratégiáját és helyreállítási sorrendjét rendszeresen tesztelni, dokumentálni és finomhangolni kell. A dokumentum emellett az AZURE-ból Azure-ba irányuló DR-stratégiára összpontosít az SAP számítási feladataihoz.
A vészhelyreállítási terv általános szempontjai
Az Azure-beli SAP számítási feladatok különböző Azure-szolgáltatásokkal kombinálva futnak virtuális gépeken egy tipikus SAP NetWeaver-alkalmazás különböző rétegeinek (központi szolgáltatások, alkalmazáskiszolgálók, adatbázis-kiszolgáló) üzembe helyezéséhez. Általánosságban elmondható, hogy az Azure-ban futó teljes it-környezethez dr.dr.stratégiát kell megtervezni, ami azt jelenti, hogy a nem SAP-alkalmazásokat is figyelembe kell venni. Előfordulhat, hogy az SAP-rendszerekben futó üzleti megoldás nem fut egészben, ha a függő szolgáltatások vagy eszközök nem lesznek helyreállítva a dr. helyen. Ezért létre kell hoznia egy jól meghatározott átfogó DR-tervet, amely figyelembe veszi az összes összetevőt és rendszert.
Az Azure-beli DR esetében a szervezeteknek különböző forgatókönyveket kell figyelembe venniük, amelyek feladatátvételt válthatnak ki.
- SAP-alkalmazás vagy üzleti folyamat rendelkezésre állása.
- Az Azure-szolgáltatások (például virtuális gépek, tárolás, terheléselosztó stb.) széles körű meghibásodás miatt nem érhetőek el egy régióban.
- Az alkalmazás potenciális fenyegetései és biztonsági rései (például az alkalmazásréteg DDoS-támadása)
- Az üzleti megfelelőséghez üzemeltetési feladatokra volt szükség a DR-stratégia teszteléséhez (például a dr. hibagyakorlatot minden évben el kell végezni a megfelelőségnek megfelelően).
A különböző forgatókönyvek helyreállítási céljának eléréséhez a szervezetnek az üzleti követelmények alapján meg kell vázolnia a helyreállítási időkorlátot (RTO) és a helyreállítási pont célkitűzését (RPO). Az RTO azt írja le, hogy az alkalmazás mennyi időt vehet le, általában órákban, percekben vagy másodpercekben mérve. Míg az RPO azt a tranzakciós adatot írja le, amelyet az üzleti vállalkozás a szokásos műveletek folytatása érdekében veszteni tud. A vállalat RTO-jának és RPO-jának azonosítása kulcsfontosságú, mivel ez segít a DR-stratégia optimális kialakításában. Az SAP számítási feladataiban részt vevő összetevőket (számítás, tárolás, adatbázis stb.) a rendszer különböző technikákkal replikálja a DR-régióba (natív Azure-szolgáltatások, natív adatbázis-replikációs technológia, egyéni szkriptek). Minden technika különböző RPO-t biztosít, amelyeket figyelembe kell venni a DR-stratégia tervezésekor. Az Azure-ban használhat néhány natív Azure-szolgáltatást, például az Azure Site Recoveryt, az Azure Backupot, amely segíthet az SAP-számítási feladatok RTO-jának és RPO-jának teljesítésében. Tekintse meg az Azure Site Recovery és az Azure Backup SLA-ját, hogy optimálisan igazodjon az RTO-hoz és az RPO-hoz.
Az Azure-ra vonatkozó vészhelyreállítás tervezési szempontja
Az Azure-ra vonatkozó vészhelyreállítási megoldás tervezésekor különböző szempontokat kell figyelembe venni. A helyszíni vészhelyreállítási megoldások tervezésének alapelvei és fogalmai az Azure-ra is érvényesek. Az Azure-ban azonban a régió kiválasztása kulcsfontosságú szerepet játszik a vészhelyreállítás tervezési stratégiájában. Ezért tartsa szem előtt az alábbi szempontokat az Azure-beli DR-régió kiválasztásakor.
Az üzleti vagy jogszabályi megfelelőségi követelmények meghatározhatnak egy távolsági követelményt az elsődleges és a vészhelyreállítási hely között. A távolsági követelmények segítenek a rendelkezésre állás biztosításában, ha egy természeti katasztrófa egy szélesebb földrajzi helyen fordul elő. Ilyen esetben a szervezet választhat egy másik Azure-régiót vészhelyreállítási helyként. Az Azure-régiókat gyakran nagy távolság választja el egymástól, ami akár több száz vagy akár több ezer kilométer is lehet, mint a Egyesült Államok. A távolság miatt a hálózati kerekítés késése nagyobb lesz, ami magasabb RPO-t eredményezhet.
Azok az ügyfelek, akik az Azure-beli helyszíni metró-dr. stratégiájukat szeretnék utánozni, rendelkezésre állási zónákat használhatnak vészhelyreállításhoz. A zónák közötti dr. stratégia azonban nem feltétlenül felel meg a rugalmassági követelményeknek, ha földrajzilag széles körben elterjedt természeti katasztrófa áll fenn.
Az Azure-ban minden régió egy másik régióval van párosítva ugyanazon a földrajzi területen belül (kivéve Dél-Brazília). Ez a megközelítés lehetővé teszi a platform által biztosított erőforrások régiónkénti replikálását. A párosított régió kiválasztásának előnye a régiópárok dokumentumában található. Ha egy szervezet úgy dönt, hogy azure-beli párosított régiókat használ, több további pontot is figyelembe kell venni egy SAP-számítási feladathoz:
Nem minden Azure-szolgáltatás kínál régiók közötti replikációt a párosított régióban.
Előfordulhat, hogy a párosított Azure-régiókban az Azure-szolgáltatások és -szolgáltatások nem szimmetrikusak. Előfordulhat például, hogy az Azure NetApp Files, az elsődleges régióban elérhető M-sorozathoz hasonló virtuálisgép-termékváltozatok nem érhetők el a párosított régióban. Annak ellenőrzéséhez, hogy az Azure-termék vagy -szolgáltatások elérhetők-e egy régióban, tekintse meg az Azure Termékek régiónként című témakört.
A GRS lehetőség olyan standard típusú tárfiókhoz érhető el, amely az adatokat a párosított régióba replikálja. A standard tároló azonban nem alkalmas SAP DBMS-hez vagy virtuális adatlemezekhez.
A támogatott megoldások biztonsági mentéséhez használt Azure backup szolgáltatás csak párosított régiók között képes replikálni a biztonsági másolatokat. Minden más adat esetében futtassa a saját replikációit natív DBMS-funkciókkal, például az SQL Server Always On szolgáltatással, az SAP HANA rendszerreplikálásával és más szolgáltatásokkal. Használja az Azure Site Recovery, az rsync vagy a robocopy és más külső szoftverek kombinációját az SAP-alkalmazásréteghez.
Az SAP számítási feladatok üzembe helyezésének referencia-leírása
A DR-régió azonosítása után fontos, hogy az elsődleges régióban konfigurált Azure Core-szolgáltatások (például hálózat, számítás, tárolás) szélessége elérhető legyen, és konfigurálható legyen a DR régióban. A szervezetnek ki kell dolgoznia egy dr. üzembehelyezési mintát az SAP számítási feladataihoz. Az üzembehelyezési minta változó, és igazodnia kell a szervezet igényeihez.
- Éles SAP-számítási feladat üzembe helyezése az elsődleges régióban és nem éles számítási feladat vészhelyreállítási régióban.
- Helyezze üzembe az összes SAP-számítási feladatot (éles és nem éles) az elsődleges régióban. A vészhelyreállítási régió csak feladatátvétel esetén használható.
Az alábbi referenciaarchitektúra az Azure-ban futó tipikus SAP NetWeaver rendszert, valamint az elsődleges régió magas rendelkezésre állását mutatja be. Az alábbiakban látható másodlagos hely az a vészhelyreállítási hely, ahol az SAP-rendszerek egy katasztrófaesemény után lesznek visszaállítva. Az elsődleges és a vészhelyreállítási régió is ugyanahhoz az előfizetéshez tartozik. Az SAP számítási feladataihoz szükséges DR eléréséhez azonosítania kell az egyes SAP-rétegek helyreállítási stratégiáját, valamint az alkalmazás által használt különböző Azure-szolgáltatásokat.
A szervezeteknek a teljes informatikai környezethez tervezniük és tervezniük kell egy DR-stratégiát. Az éles környezetben futó SAP-rendszerek általában különböző szolgáltatásokkal és interfészekkel integrálva vannak, például az Active Directoryval, a DNS-sel, a külső alkalmazásokkal stb. Ezért a vészhelyreállítási tervezésbe bele kell foglalnia a nem SAP-rendszereket és más szolgáltatásokat is. Ez a dokumentum az SAP-alkalmazások helyreállítási tervezésével foglalkozik. A függő összetevők dr. tervezésének méretét és hatókörét azonban kibővítheti a követelményeknek megfelelően.
A DR-megoldás infrastruktúra-összetevői az SAP számítási feladataihoz
Az Azure-ban futó SAP-számítási feladatok különböző infrastruktúra-összetevőket használnak egy üzleti megoldás futtatásához. Az ilyen megoldáshoz szükséges DR megtervezéséhez elengedhetetlen, hogy az elsődleges régióban konfigurált összes infrastruktúra-összetevő elérhető legyen, és a DR régióban is konfigurálható legyen. Az AZURE-beli SAP számítási feladatokhoz készült DR-megoldás tervezésekor az alábbi infrastruktúra-összetevőket kell figyelembe venni.
- Network
- Compute
- Storage
Network
Az ExpressRoute egy kapcsolatszolgáltató segítségével privát kapcsolaton keresztül terjeszti ki a helyszíni hálózatot a Microsoft-felhőbe. A vészhelyreállítási architektúra tervezésekor figyelembe kell venni egy robusztus háttérhálózati kapcsolatot georedundáns ExpressRoute-kapcsolatcsoport használatával. Javasoljuk, hogy legalább egy ExpressRoute-kapcsolatcsoportot állítson be a helyszínről az elsődleges régióba. A másiknak pedig csatlakoznia kell a vészhelyreállítási régióhoz. Tekintse meg az Azure ExpressRoute vészhelyreállításhoz való tervezéséről szóló cikket, amely az ExpressRoute vészhelyreállításának különböző forgatókönyveit ismerteti.
Megjegyzés:
Fontolja meg a helyek közötti (S2S) VPN beállítását az Azure ExpressRoute biztonsági mentéseként. További információ: Az S2S VPN használata biztonsági másolatként az Azure ExpressRoute privát társviszony-létesítéshez.
A virtuális hálózat és az alhálózatok a régió összes rendelkezésre állási zónájában kiterjednek. Két régióra kiterjedő dr. vészhelyreállítási régióban külön virtuális hálózatokat és alhálózatokat kell konfigurálni. Az Azure-beli virtuális gépek vészhelyreállításának hálózatkezelésével kapcsolatos további információkért tekintse meg a dr. régió hálózatkezelési beállítását.
Az Azure Standard Load Balancer hálózati elemeket biztosít az SAP-rendszerek magas rendelkezésre állású kialakításához. Fürtözött rendszerek esetén a Standard Load Balancer biztosítja a fürtszolgáltatás virtuális IP-címét, például az ASCS/SCS-példányokat és a virtuális gépeken futó adatbázisokat. Ha magas rendelkezésre állású SAP-rendszert szeretne futtatni a dr. helyen, létre kell hozni egy külön terheléselosztót, és ennek megfelelően módosítani kell a fürtkonfigurációt.
Azure-alkalmazás átjáró egy webes forgalom terheléselosztója. A webalkalmazási tűzfal funkciójával a webalkalmazások jobb biztonságú, jól használható szolgáltatásával az internetre is elérhetővé teheti a webalkalmazásokat. Azure-alkalmazás Átjáró a konfigurációtól függően nyilvános (internetes) vagy magánügyfeleket, vagy mindkettőt képes kiszolgálni. A feladatátvételt követően a DR régióhoz hasonló bejövő HTTP-forgalom elfogadásához külön Azure-alkalmazás átjárót kell konfigurálni a DR régióban.
Mivel a hálózati összetevők (például virtuális hálózat, tűzfal stb.) külön jönnek létre a DR régióban, meg kell győződnie arról, hogy a DR régió SAP-számítási feladatai igazodnak az olyan hálózati változásokhoz, mint a DNS-frissítés, a tűzfal stb.
Mindkét régióban a virtuális hálózatok függetlenek, és a kettő közötti kommunikáció létrehozásához engedélyeznie kell a virtuális hálózatok közötti társviszonyt a két régió között.
Virtual machines (Virtuális gépek)
Az Azure-ban egyetlen SAP-rendszer különböző összetevői futnak különböző termékváltozatú virtuális gépeken. Dr esetén az Azure-beli virtuális gépeken futó alkalmazások (SAP NetWeaver és nem SAP) védelme az Azure Site Recoveryt használó összetevők egy másik Azure-régióba vagy zónába történő replikálásával engedélyezhető. Az Azure Site Recovery használatával az Azure-beli virtuális gépek folyamatosan replikálódnak az elsődlegesről a vészhelyreállítási helyre. A kiválasztott Azure DR-régiótól függően előfordulhat, hogy a virtuálisgép-termékváltozat típusa nem érhető el a DR-webhelyen. Győződjön meg arról, hogy a szükséges virtuálisgép-termékváltozat-típusok elérhetők az Azure DRregionban is. Ellenőrizze az Azure-termékek régiónkénti ellenőrzését, hogy elérhető-e a szükséges virtuálisgép-család termékváltozata.
Fontos
Ha az SAP-rendszer rugalmas méretezési csoporttal van konfigurálva az FD=1 használatával, akkor a PowerShell használatával kell beállítania az Azure Site Recoveryt vészhelyreállításhoz. Jelenleg ez az egyetlen elérhető módszer a méretezési csoportban üzembe helyezett virtuális gépek vészhelyreállításának konfigurálására.
Az Azure-beli virtuális gépeken futó adatbázisok esetében ajánlott natív adatbázis-replikációs technológiával szinkronizálni az adatokat a vészhelyreállítási helyre. Előfordulhat, hogy azok a nagy virtuális gépek, amelyeken az adatbázisok futnak, nem minden régióban érhetők el. Ha rendelkezésre állási zónákat használ vészhelyreállításhoz, ellenőrizze, hogy a megfelelő virtuálisgép-termékváltozatok elérhetők-e a vészhelyreállítási hely zónájában.
Megjegyzés:
Nem ajánlott az Azure Site Recovery használata adatbázisokhoz, mivel nem garantálja a DB konzisztenciáját, és adatváltozási korlátozásokkal rendelkezik.
Ha az éles alkalmazások mindig az elsődleges régióban futnak, a tartalék példányok általában az Azure-költségek takarékosságára szolgálnak. Fenntartott példányok használata esetén 1 vagy 3 éves időszakra kell regisztrálnia, amely nem feltétlenül költséghatékony a DR-webhelyek esetében. Az Azure Site Recovery beállítása nem garantálja a szükséges virtuálisgép-termékváltozat kapacitását a feladatátvétel során. Annak érdekében, hogy a virtuálisgép-termékváltozat kapacitása elérhető legyen, megfontolhat egy lehetőséget az igény szerinti kapacitásfoglalás engedélyezésére. A számítási kapacitást egy Azure-régióban vagy egy Azure rendelkezésre állási zónában fenntartja a kötelezettségvállalás nélküli időtartamig. Az Azure Site Recovery integrálva van az igény szerinti kapacitásfoglalással. Ezzel az integrációval az Azure Site Recovery kapacitásfoglalási funkciójával lefoglalhatja a számítási kapacitást a DR-helyen, és garantálhatja a feladatátvételeket. További információkért olvassa el az igény szerinti kapacitásfoglalás korlátozásait és korlátozásait.
Egy Azure-előfizetés kvótákat biztosít a virtuálisgép-családokhoz (például Mv2-családhoz) és más erőforrásokhoz. Előfordulhat, hogy a szervezetek különböző Azure-előfizetést szeretnének használni a DR-hez. Minden előfizetéshez (elsődleges és DR) különböző kvóták rendelhetők hozzá minden virtuálisgép-családhoz. Győződjön meg arról, hogy a DR-webhelyhez használt előfizetés elegendő számítási kvótával rendelkezik.
Storage
Ha engedélyezi az Azure Site Recoveryt egy virtuális gép számára a DR beállításához, a virtuális gépekhez csatolt operációs rendszer és helyi adatlemezek replikálódnak a DR-helyre. A replikáció során a rendszer elküldi a virtuálisgép-lemez írásait a forrásrégió gyorsítótár-tárfiókjába. A rendszer onnan küld adatokat a célrégióba, és helyreállítási pontok jönnek létre az adatokból. Ha feladatátvételt ad át egy virtuális gépnek a DR során, a rendszer egy helyreállítási ponttal állítja vissza a virtuális gépet a célrégióban. Az Azure Site Recovery azonban nem támogatja az Azure-ban elérhető összes tárolótípust. További információkért tekintse meg az Azure Site Recovery tárolási támogatási mátrixát.
A virtuális gépekhez csatlakoztatott Azure-beli felügyelt adatlemezek mellett különböző natív Azure-tárolási megoldásokkal futtathatók az SAP-alkalmazások az Azure-ban. Az egyes Azure Storage-megoldások dr. megközelítése eltérő lehet, mivel az Azure-ban elérhető tárolási szolgáltatások nem támogatottak az Azure Site Recoveryben. Az alábbiakban felsoroljuk az SAP számítási feladataihoz általában használt tárolási típusokat.
Storage type DR-stratégiajavaslat Felügyelt lemez Azure Site Recovery NFS Azure-fájlokon (LRS vagy ZRS) Egyéni szkript az adatok két hely közötti replikálásához (például rsync) NFS az Azure NetApp Fileson Azure NetApp Files-kötetek régiók közötti replikációjának használata Azure megosztott lemez (LRS vagy ZRS) Egyéni megoldás az adatok két hely közötti replikálására SMB Azure-fájlokon (LRS vagy ZRS) Fájlok másolása két webhely között a RoboCopy használatával SMB az Azure NetApp Fileson Azure NetApp Files-kötetek régiók közötti replikációjának használata Az egyéni beépített tárolási megoldások, például az NFS-fürt esetében meg kell győződnie arról, hogy a megfelelő DR-stratégia van érvényben.
Előfordulhat, hogy a különböző natív Azure Storage-szolgáltatások (például az Azure Files, az Azure NetApp Files és az Azure Shared Disk) nem minden régióban érhetők el. Ahhoz, hogy a feladatátvételt követően hasonló SAP-beállítás legyen a DR-régióban, győződjön meg arról, hogy a megfelelő tárolási szolgáltatást a dr. helyen kínálják. További információkért tekintse meg az Azure-termékek régiónkénti adatait.
Ha rendelkezésre állási zónákat használ vészhelyreállításhoz, vegye figyelembe a következő szempontokat:
- Az Azure NetApp Files szolgáltatás még nem ismeri a zónákat. Az Azure NetApp Files szolgáltatás jelenleg nem üzemel egy Azure-régió összes rendelkezésre állási zónájában. Előfordulhat tehát, hogy az Azure NetApp Files szolgáltatás nem érhető el a dr. stratégiához választott rendelkezésre állási zónában.
- Az Azure NetApp-fájlkötetek régiók közötti replikációja csak rögzített régiópárokban érhető el, zónákban nem.
Ha a tárolót Active Directory-integrációval konfigurálta, hasonló beállítást kell elvégeznie a DR-hely tárfiókján is.
Az Azure megosztott lemezeihez olyan fürtszoftverre van szükség, mint a Windows Server Feladatátvevő fürt (WSFC), amely kezeli a fürtcsomópont-kommunikációt és az írási zárolást. Ahhoz, hogy az Azure-beli megosztott lemezek dr. stratégiája elérhető legyen, a megosztott lemezt a fürtszoftverek is felügyelik a dr. helyen. Ezután szkripttel adatokat másolhat az elsődleges régióban lévő fürthöz csatolt megosztott lemezről a DR régió egy másik fürthöz csatolt megosztott lemezére.