SAP HANA rendelkezésre állása egy Azure-régión belül
Ez a cikk az SAP HANA több rendelkezésre állási forgatókönyvét ismerteti egy Azure-régión belül. Az Azure számos régióval rendelkezik, amelyek világszerte elterjedtek. Az Azure-régiók listájáért tekintse meg az Azure-régiókat. Az SAP HANA egy Azure-régióban lévő virtuális gépeken való üzembe helyezéséhez a Microsoft egyetlen virtuális gép üzembe helyezését kínálja HANA-példánnyal. A nagyobb rendelkezésre állás érdekében két HANA-példánysal rendelkező két virtuális gépet helyezhet üzembe egy rugalmas méretezési csoporttal FD=1,rendelkezésre állási zónákkal vagy rendelkezésre állási csoporttal, amely HANA-rendszerreplikációs szolgáltatást használ a rendelkezésre álláshoz.
A rendelkezésre állási zónákat biztosító Azure-régiók több adatközpontból állnak, amelyek mindegyike saját energiaforrással, hűtéssel és hálózati infrastruktúrával rendelkezik. A különböző zónák egyetlen Azure-régión belüli felajánlásának célja, hogy lehetővé tegye az alkalmazások üzembe helyezését két vagy három rendelkezésre állási zónában. Az alkalmazás üzembe helyezésének zónák közötti elosztásával az adott Azure rendelkezésre állási zóna infrastruktúráját érintő energia- vagy hálózatkezelési problémák nem zavarják meg teljesen az alkalmazás funkcióit az Azure-régióban. Bár előfordulhat, hogy néhány kisebb kapacitás, például egy zónában a virtuális gépek potenciális elvesztése, a fennmaradó zónákban lévő virtuális gépek zavartalanul működnek. Ha két HANA-példányt szeretne beállítani a különböző zónákra kiterjedő különálló virtuális gépeken, akkor lehetősége van virtuális gépek üzembe helyezésére az FD=1 rugalmas méretezési csoporttal vagy a rendelkezésre állási zónák üzembe helyezési lehetőségével.
A régión belüli nagyobb rendelkezésre állás érdekében ajánlott két virtuális gépet üzembe helyezni két HANA-példánysal egy rendelkezésre állási csoport használatával. Az Azure Rendelkezésre állási csoport egy logikai csoportosítási képesség, amely biztosítja, hogy a rendelkezésre állási csoportban konfigurált virtuálisgép-erőforrások egymástól hibamentesen legyenek elkülönítve, amikor egy Azure-adatközpontban vannak üzembe helyezve. Az Azure biztosítja, hogy a rendelkezésre állási csoportba helyezett virtuális gépek több fizikai kiszolgálón, számítási rackszekrényen, tárolási egységben és hálózati kapcsolón fussanak. Egyes Azure-dokumentációkban ezt a konfigurációt különböző frissítési és tartalék tartományokban való elhelyezésnek nevezzük. Ezek az elhelyezések általában egy Azure-adatközpontban találhatók. Feltételezve, hogy az áramforrással és a hálózatokkal kapcsolatos problémák hatással lennének az üzembe helyezendő adatközpontra, az egy Azure-régióban lévő összes kapacitásra hatással lenne.
Az Azure rendelkezésre állási zónákat képviselő adatközpontok elhelyezése kompromisszumot jelent a különböző zónákban üzembe helyezett szolgáltatások közötti elfogadható hálózati késés és az adatközpontok közötti távolság között. A természeti katasztrófák ideális esetben nem befolyásolják a régió összes rendelkezésre állási zónájának energiaellátását, hálózati kínálatát és infrastruktúráját. A monumentális természeti katasztrófák azonban azt mutatják, hogy a rendelkezésre állási zónák nem mindig biztosítják a kívánt rendelkezésre állást egy régión belül. Gondoljon a Maria hurrikánra, amely 2017. szeptember 20-án érte el Puerto Rico szigetét. A hurrikán gyakorlatilag majdnem 100 százalékos áramkimaradást okozott a 90 mérföld széles szigeten.
Egy virtuális gép forgatókönyve
Egy virtuálisgép-forgatókönyvben azure-beli virtuális gépet hoz létre az SAP HANA-példányhoz. Az Azure Premium Storage használatával üzemeltetheti az operációsrendszer-lemezt és az összes adatlemezt. Az Azure 99,9 százalékos üzemidejű SLA-ja és a többi Azure-összetevő SLA-ja elegendő ahhoz, hogy az ügyfelek számára rendelkezésre álló SLA-kat teljesítsen. Ebben a forgatókönyvben nem kell azure-beli rendelkezésre állási csoportot használnia a DBMS-réteget futtató virtuális gépekhez. Ebben a forgatókönyvben két különböző funkcióra támaszkodhat:
- Azure-beli virtuális gép automatikus újraindítása (más néven Azure-szolgáltatásjavítás)
- AZ SAP HANA automatikus újraindítása
Az Azure-beli virtuális gépek automatikus újraindítása vagy szolgáltatásjavítása az Azure-ban két szinten működik:
- Az Azure-kiszolgáló gazdagépe ellenőrzi a kiszolgáló gazdagépén üzemeltetett virtuális gép állapotát.
- Az Azure Fabric-vezérlő figyeli a kiszolgáló gazdagépének állapotát és rendelkezésre állását.
Az állapot-ellenőrzési funkció figyeli az Azure Server-gazdagépen üzemeltetett összes virtuális gép állapotát. Ha egy virtuális gép nem kifogástalan állapotba kerül, a virtuális gép újraindítását az Azure-gazdaügynök kezdeményezheti, amely ellenőrzi a virtuális gép állapotát. A hálóvezérlő számos különböző paraméter ellenőrzésével ellenőrzi a gazdagép állapotát, amelyek a gazdagép hardverével kapcsolatos problémákat jelezhetnek. Emellett ellenőrzi a gazdagép hálózati elérhetőségét is. A gazdagép problémáinak jelzése a következő eseményekhez vezethet:
- Ha a gazdagép rossz állapotot jelez, a gazdagép újraindítása és a gazdagépen futó virtuális gépek újraindítása aktiválódik.
- Ha a gazdagép a sikeres újraindítás után nem kifogástalan állapotban van, a rendszer újra üzembe helyezi az eredetileg nem kifogástalan csomóponton lévő virtuális gépeket egy kifogástalan gazdagépkiszolgálóra. Ebben az esetben az eredeti gazdagép nem kifogástalan állapotúként van megjelölve. A rendszer nem fogja használni a további üzembe helyezésekhez, amíg el nem törli vagy ki nem cseréli.
- Ha a nem megfelelő gazdagépnek problémái vannak az újraindítási folyamat során, a rendszer azonnal újraindítja a virtuális gépeket egy kifogástalan állapotú gazdagépen.
Az Azure által biztosított gazdagép- és virtuálisgép-monitorozással a gazdagépekkel kapcsolatos problémákat tapasztaló Azure-beli virtuális gépek automatikusan újraindulnak egy kifogástalan Állapotú Azure-gazdagépen.
Fontos
Az Azure szolgáltatásjavítás nem indítja újra a Linux rendszerű virtuális gépeket, ahol a vendég operációs rendszer kernel pánikállapotban van. A gyakran használt Linux-kiadások alapértelmezett beállításai nem indítják újra automatikusan a virtuális gépeket vagy a kiszolgálót, ahol a Linux kernel pánikállapotban van. Ehelyett az alapértelmezett azt tervezi, hogy az operációs rendszer kernel pánikállapotban marad, hogy képes legyen egy kernel-hibakeresőt csatlakoztatni az elemzéshez. Az Azure tiszteletben tartja ezt a viselkedést azáltal, hogy nem indítja újra automatikusan a virtuális gépet a vendég operációs rendszerrel ilyen állapotban. Feltételezem, hogy az ilyen előfordulások rendkívül ritkák. Felülírhatja az alapértelmezett viselkedést a virtuális gép újraindításának engedélyezéséhez. Az alapértelmezett viselkedés módosításához engedélyezze a "kernel.panic" paramétert a /etc/sysctl.conf fájlban. A paraméterhez beállított idő másodpercben van megadva. Az ajánlott értékek általában 20–30 másodpercig várnak, mielőtt elindítanák az újraindítást ezen a paraméteren keresztül. További információ: sysctl.conf.
A második funkció, amelyre ebben a forgatókönyvben támaszkodik, az a tény, hogy az újraindított virtuális gépen futó HANA szolgáltatás automatikusan elindul a virtuális gép újraindítása után. A HANA szolgáltatás automatikus újraindítását a különböző HANA-szolgáltatások watchdog szolgáltatásaival állíthatja be.
Ezt az egy virtuálisgép-forgatókönyvet úgy javíthatja, hogy hideg feladatátvételi csomópontot ad hozzá egy SAP HANA-konfigurációhoz. Az SAP HANA dokumentációjában ezt a beállítást gazdagép automatikus lefailoverének nevezzük. Ennek a konfigurációnak van értelme egy olyan helyszíni üzembehelyezési helyzetben, amelyben a kiszolgáló hardvere korlátozott, és egy egykiszolgálós csomópontot ad meg az éles gazdagépek egy csoportjának gazdagép automatikus átadási csomópontjaként. Az Azure-ban azonban, ahol az Azure mögöttes infrastruktúrája megfelelő célkiszolgálót biztosít a virtuális gépek sikeres újraindításához, nincs értelme az SAP HANA-gazdagép automatikus üzembe helyezésének. Az Azure szolgáltatásjavítása miatt nincs olyan referenciaarchitektúra, amely készenléti csomópontot irányozna elő a HANA-gazdagép automatikus üzembe helyezéséhez.
Az SAP HANA vertikális felskálázási konfigurációinak különleges esete az Azure-ban
A készenléti csomóponton vagy a HANA-rendszerreplikációs szolgáltatáson alapuló magas rendelkezésre állású architektúrák a következő dokumentumokban találhatók. Ha a készenléti csomópontok vagy a HANA rendszerreplikációs magas rendelkezésre állása nem használható az SAP HANA kibővített konfigurációiban, az Azure-beli virtuális gépek szolgáltatásjavítási képességeitől és az SAP HANA-példány automatikus újraindításától függhet, ha a virtuális gép újra működik.
- RedHat Enterprise Linux
- SU Standard kiadás Linux Enterprise Server
Rendelkezésre állási forgatókönyvek két különböző virtuális géphez
A HANA-rendszer rendelkezésre állásának biztosítása érdekében egy adott régión belül két virtuális gépet konfigurálhat a régió rendelkezésre állási zónáiban vagy a régión belül. A cél elérése érdekében a virtuális gépeket rugalmas méretezési csoport, rendelkezésre állási zónák vagy rendelkezésre állási csoport üzembe helyezési lehetőségével konfigurálhatja. Az Azure alapbeállítása a következőképpen nézne ki:
A különböző SAP HANA-rendelkezésre állási forgatókönyvek szemléltetéséhez a diagram néhány rétege hiányzik. Az ábrán csak a virtuális gépeket, gazdagépeket, rendelkezésreállási csoportokat és Azure-régiókat ábrázoló rétegek láthatók. Az Azure Virtual Network-példányok, erőforráscsoportok és előfizetések nem játszanak szerepet az ebben a szakaszban ismertetett forgatókönyvekben.
Biztonsági másolatok replikálása egy második virtuális gépre
Az egyik leglánsabb beállítás a biztonsági másolatok használata. Előfordulhat például, hogy a tranzakciónapló biztonsági másolatai egy virtuális gépről egy másik Azure-beli virtuális gépre kerülnek. Kiválaszthatja az Azure Storage típusát. Ebben a beállításban Ön a felelős az első virtuális gépen a második virtuális gépre irányuló ütemezett biztonsági mentések másolatának szkripteléséért. Ha a második virtuálisgép-példányokat kell használnia, a teljes, növekményes/különbözeti és tranzakciónapló-biztonsági mentéseket a szükséges helyre kell visszaállítania.
Az architektúra a következőképpen néz ki:
Ez a beállítás nem alkalmas a helyreállítási időkorlát (RPO) és a helyreállítási idő célkitűzésének (RTO) elérésére. Az RTO-idők különösen a teljes adatbázis teljes visszaállításának szükségessége miatt szenvednének a másolt biztonsági másolatok használatával. Ez a beállítás azonban hasznos lehet a fő példányok nem szándékos adattörléséből való helyreállításhoz. Ezzel a beállítással bármikor visszaállíthatja egy adott időpontra, kinyerheti az adatokat, és importálhatja a törölt adatokat a főpéldányba. Ezért érdemes lehet biztonsági mentési másolási módszert használni más magas rendelkezésre állású funkciókkal kombinálva.
A biztonsági másolatok másolása közben előfordulhat, hogy az SAP HANA-példány által futtatott fő virtuális gépnél kisebb virtuális gépet is használhat. Ne feledje, hogy kisebb számú virtuális merevlemezt csatolhat kisebb virtuális gépekhez. Az egyes virtuálisgép-típusok korlátairól az Azure-beli Linux rendszerű virtuális gépek méreteiről olvashat.
SAP HANA rendszerreplikálás automatikus feladatátvétel nélkül
Az ebben a szakaszban ismertetett forgatókönyvek SAP HANA-rendszerreplikációs szolgáltatást használnak. Az SAP dokumentációját lásd : Rendszerreplikáció. Az automatikus feladatátvétel nélküli forgatókönyvek nem gyakoriak az egy Azure-régión belüli konfigurációk esetében. Az automatikus feladatátvétel nélküli konfigurációk, bár elkerülik a Pacemaker beállítását, manuálisan kell figyelnie és feladatátvételt végrehajtania. Mivel ez is igénybe veszi és erőfeszítéseket tesz, a legtöbb ügyfél inkább az Azure-szolgáltatások gyógyítására támaszkodik. Vannak olyan peremhálózati esetek, amikor ez a konfiguráció segíthet a hibaforgatókönyvekben. Vagy bizonyos esetekben előfordulhat, hogy az ügyfél nagyobb hatékonyságot szeretne elérni.
SAP HANA rendszerreplikálás automatikus feladatátvétel és adatok előzetes betöltése nélkül
Ebben a forgatókönyvben az SAP HANA rendszerreplikálásával szinkron módon helyezheti át az adatokat a 0-s RPO elérése érdekében. Másrészt elég hosszú RTO-jával rendelkezik ahhoz, hogy ne legyen szüksége feladatátvételre vagy a HANA-példány gyorsítótárába való előtöltésre. Ebben az esetben az alábbi műveletek végrehajtásával további gazdaságosság érhető el a konfigurációban:
- Futtasson egy másik SAP HANA-példányt a második virtuális gépen. A második virtuális gép SAP HANA-példánya a virtuális gép memóriájának nagy részét elfoglalja. A második virtuális gépre történő feladatátvétel esetén le kell állítania a futó SAP HANA-példányt, amely az adatokat teljes mértékben betölti a második virtuális gépbe, hogy a replikált adatok betölthetők legyenek a célként megadott HANA-példány gyorsítótárába a második virtuális gépen.
- Használjon kisebb virtuálisgép-méretet a második virtuális gépen. Feladatátvétel esetén a manuális feladatátvétel előtt van egy további lépése. Ebben a lépésben átméretezi a virtuális gépet a forrás virtuális gép méretére.
A forgatókönyv a következőképpen néz ki:
Megjegyzés:
Még akkor is legalább 64 GB memóriára van szüksége, ha nem használ előre betöltést a HANA rendszerreplikációs célban. A 64 GB-nál több memóriára is szüksége van ahhoz, hogy a soradattár adatai a célpéldány memóriájában maradjanak.
SAP HANA-rendszerreplikálás automatikus feladatátvétel nélkül és adatelőtöltéssel
Ebben a forgatókönyvben a második virtuális gép HANA-példányára replikált adatok előre betöltve lesznek. Ez kiküszöböli az adatok előzetes betöltésének két előnyét. Ebben az esetben nem futtathat másik SAP HANA-rendszert a második virtuális gépen. Kisebb virtuálisgép-méretet sem használhat. Ezért az ügyfelek ritkán implementálják ezt a forgatókönyvet.
SAP HANA rendszerreplikálás automatikus feladatátvétellel
Az egyik Azure-régióban a standard és leggyakoribb rendelkezésre állási konfigurációban két, Ha-csomagokkal Linuxot futtató Azure-beli virtuális gép rendelkezik feladatátvevő fürttel. A HA Linux-fürt az SLES-t vagy RHEL-t használó keretrendszeren Pacemaker alapul, példaként SLES-t fencing device vagy RHEL-thasznál.
SAP HANA-szempontból a rendszer szinkronizálja a használt replikációs módot, és automatikus feladatátvételt konfigurál. A második virtuális gépen az SAP HANA-példány gyakori készenléti csomópontként működik. A készenléti csomópont szinkron változásrekord-adatfolyamot kap az elsődleges SAP HANA-példánytól. Mivel az alkalmazás az elsődleges HANA-csomóponton köti le a tranzakciókat, az elsődleges HANA-csomópont megvárja az alkalmazás véglegesítését, amíg a másodlagos SAP HANA-csomópont meg nem erősíti, hogy megkapta a véglegesítési rekordot. Az SAP HANA két szinkron replikációs módot kínál. A két szinkron replikációs mód közötti különbségek részleteit és leírását az SAP-cikkben, az SAP HANA rendszerreplikációs módjai című cikkben találja.
Az általános konfiguráció a következőképpen néz ki:
Ezt a megoldást azért választhatja, mert lehetővé teszi az RPO=0 és az alacsony RTO elérését. Konfigurálja az SAP HANA-ügyfélkapcsolatot úgy, hogy az SAP HANA-ügyfelek a virtuális IP-cím használatával csatlakozzanak a HANA-rendszer replikációs konfigurációhoz. Egy ilyen konfiguráció nem igényli az alkalmazás újrakonfigurálását, ha feladatátvétel történik a másodlagos csomópontra. Ebben a forgatókönyvben az elsődleges és másodlagos virtuális gépek Azure-beli virtuálisgép-termékváltozatainak azonosnak kell lenniük.
Következő lépések
A konfigurációk Azure-ban történő beállításával kapcsolatos részletes útmutatásért lásd:
- SAP HANA-rendszerreplikálás beállítása Azure-beli virtuális gépeken
- Magas rendelkezésre állás az SAP HANA-hoz rendszerreplikációs szolgáltatással
További információ az SAP HANA Azure-régiók közötti elérhetőségéről: