Az IBM Db2 LUW magas rendelkezésre állása Azure-beli virtuális gépeken Red Hat Enterprise Linux Serveren

Az IBM Db2 for Linux, UNIX és Windows (LUW) magas rendelkezésre állású és vészhelyreállítási (HADR) konfigurációban egy elsődleges adatbázispéldányt futtató csomópontból és legalább egy másodlagos adatbázispéldányt futtató csomópontból áll. Az elsődleges adatbázispéldány módosításai szinkronizálva vagy aszinkron módon replikálódnak egy másodlagos adatbázispéldányra a konfigurációtól függően.

Feljegyzés

Ez a cikk a Microsoft által már nem használt kifejezésekre mutató hivatkozásokat tartalmaz. Ha ezeket a feltételeket eltávolítja a szoftverből, eltávolítjuk őket ebből a cikkből.

Ez a cikk az Azure-beli virtuális gépek (VM-ek) üzembe helyezését és konfigurálását, a fürt keretrendszerének telepítését és az IBM Db2 LUW HADR-konfigurációval történő telepítését ismerteti.

A cikk nem ismerteti, hogyan telepíthető és konfigurálható az IBM Db2 LUW HADR- vagy SAP-szoftvertelepítéssel. A feladatok elvégzéséhez az SAP és az IBM telepítési kézikönyveire mutató hivatkozásokat biztosítunk. Ez a cikk az Azure-környezetre jellemző részekre összpontosít.

A támogatott IBM Db2-verziók 10.5-ös és újabb verziók, az SAP megjegyzésében 1928533.

A telepítés megkezdése előtt tekintse meg az alábbi SAP-megjegyzéseket és dokumentációt:

SAP-megjegyzés	Leírás
1928533	SAP-alkalmazások az Azure-ban: Támogatott termékek és Azure-beli virtuálisgép-típusok
2015553	SAP az Azure-ban: Támogatási előfeltételek
2178632	Az Azure-beli SAP fő monitorozási metrikái
2191498	SAP Linuxon az Azure-ral: Továbbfejlesztett monitorozás
2243692	Azure-beli Linux (IaaS) rendszerű virtuális gép: SAP-licenccel kapcsolatos problémák
2002167	Red Hat Enterprise Linux 7.x: Telepítés és frissítés
2694118	Red Hat Enterprise Linux HA bővítmény az Azure-ban
1999351	Az SAP továbbfejlesztett Azure-monitorozásának hibaelhárítása
2233094	DB6: SAP-alkalmazások az Azure-ban, amelyek az IBM Db2-t használják Linuxhoz, UNIX-hez és Windowshoz – további információk
1612105	DB6: Gyakori kérdések a DB2-ről a HADR-vel

Dokumentáció
SAP Community Wiki: Rendelkezik a Linuxhoz szükséges SAP-megjegyzésekkel
Azure-beli virtuális gépek tervezése és implementálása linuxos SAP-hez – útmutató
Azure Virtual Machines üzembe helyezése Linuxon futó SAP-hoz (ez a cikk)
Azure Virtual Machines adatbázis-kezelő rendszer (DBMS) üzembe helyezése linuxos SAP-hez – útmutató
SAP-számítási feladatok az Azure tervezési és üzembe helyezési ellenőrzőlistáján
A Red Hat Enterprise Linux 7 magas rendelkezésre állású bővítményének áttekintése
Magas rendelkezésre állású bővítmény Rendszergazda istration
Magas rendelkezésre állású bővítmény referenciája
Magas rendelkezésre állású RHEL-fürtök támogatási szabályzatai – Microsoft Azure-beli virtuális gépek fürttagként
Red Hat Enterprise Linux 7.4 (és újabb) magas rendelkezésre állású fürt telepítése és konfigurálása a Microsoft Azure-ban
IBM Db2 Azure Virtual Machines DBMS üzembe helyezése SAP-számítási feladathoz
IBM Db2 HADR 11.1
IBM Db2 HADR 10.5
Támogatási szabályzat magas rendelkezésre állású RHEL-fürtökhöz – Ibm Db2 kezelése Linuxhoz, Unixhoz és Windowshoz fürtön

Áttekintés

A magas rendelkezésre állás érdekében az IBM DB2 LUW és a HADR legalább két Azure-beli virtuális gépre van telepítve, amelyek egy rugalmas vezénylést biztosító virtuálisgép-méretezési csoportban vannak üzembe helyezve a rendelkezésre állási zónákban vagy egy rendelkezésre állási csoportban.

Az alábbi ábrán két adatbázis-kiszolgáló azure-beli virtuális gépének beállítása látható. Mindkét adatbázis-kiszolgáló azure-beli virtuális gép saját tárolóval rendelkezik, és működik. A HADR-ben az azure-beli virtuális gépek egyikének egy adatbázispéldánya rendelkezik az elsődleges példány szerepkörével. Minden ügyfél csatlakozik az elsődleges példányhoz. Az adatbázis-tranzakciók minden módosítása helyben marad meg a Db2 tranzakciónaplóban. Mivel a tranzakciónapló rekordjai helyileg vannak megőrzve, a rekordok TCP/IP-címen keresztül kerülnek át a második adatbázis-kiszolgálón, a készenléti kiszolgálón vagy a készenléti példányon található adatbázispéldányra. A készenléti példány az átvitt tranzakciónapló-rekordok továbbításával frissíti a helyi adatbázist. Ily módon a készenléti kiszolgáló szinkronban marad az elsődleges kiszolgálóval.

A HADR csak replikációs funkció. Nincs hibaészlelése, és nincs automatikus átvétele vagy feladatátvételi létesítménye. Az átvételt vagy a készenléti kiszolgálóra történő átvitelt manuálisan kell kezdeményeznie egy adatbázis-rendszergazdának. Az automatikus átvétel és hibaészlelés eléréséhez használhatja a Linux Pacemaker fürtszolgáltatást. A Pacemaker figyeli a két adatbázis-kiszolgálópéldányt. Amikor az elsődleges adatbázis-kiszolgáló példánya összeomlik, a Pacemaker automatikus HADR-átvételt kezdeményez a készenléti kiszolgálótól. A Pacemaker azt is biztosítja, hogy a virtuális IP-cím hozzá legyen rendelve az új elsődleges kiszolgálóhoz.

Ahhoz, hogy az SAP-alkalmazáskiszolgálók csatlakozzanak az elsődleges adatbázishoz, szüksége van egy virtuális gazdagép nevére és egy virtuális IP-címre. A feladatátvétel után az SAP-alkalmazáskiszolgálók új elsődleges adatbázispéldányhoz csatlakoznak. Azure-környezetben az Azure-terheléselosztónak az IBM Db2 HADR-éhez szükséges módon kell virtuális IP-címet használnia.

Az alábbi kép áttekintést nyújt az IBM Db2-adatbázison alapuló SAP-rendszerek ibm db2-adatbázison alapuló magas rendelkezésre állású beállításáról, hogy teljes mértékben megértse, hogyan illeszkedik a HADR és a Pacemaker által biztosított IBM Db2 LUW egy magas rendelkezésre állású SAP-rendszerbeállításba. Ez a cikk csak az IBM Db2-t ismerteti, de hivatkozásokat tartalmaz az SAP-rendszerek egyéb összetevőinek beállításáról szóló egyéb cikkekre.

A szükséges lépések magas szintű áttekintése

Ibm Db2-konfiguráció üzembe helyezéséhez kövesse az alábbi lépéseket:

• Tervezze meg a környezetet.
• Telepítse a virtuális gépeket.
• Frissítse a RHEL Linuxot, és konfigurálja a fájlrendszereket.
• Telepítse és konfigurálja a Pacemakert.
• A glusterfs-fürt vagy az Azure NetApp Files beállítása
• Telepítse az ASCS/ERS-t egy külön fürtre.
• Telepítse az IBM Db2-adatbázist az Elosztott/Magas rendelkezésre állás lehetőséggel (SWPM).
• Telepítsen és hozzon létre egy másodlagos adatbáziscsomópontot és -példányt, és konfigurálja a HADR-t.
• Ellenőrizze, hogy a HADR működik-e.
• Alkalmazza a Pacemaker konfigurációját az IBM Db2 vezérléséhez.
• Az Azure Load Balancer konfigurálása.
• Telepítse az elsődleges és a párbeszédpaneles alkalmazáskiszolgálót.
• Ellenőrizze és igazítsa az SAP-alkalmazáskiszolgálók konfigurációját.
• Feladatátvételi és átvételi tesztek végrehajtása.

Az Azure-infrastruktúra megtervezése az IBM Db2 LUW hadr használatával történő üzemeltetéséhez

Az üzembe helyezés végrehajtása előtt végezze el a tervezési folyamatot. A tervezés alapja a Db2 konfigurációjának üzembe helyezése a HADR-vel az Azure-ban. Az IMB Db2 LUW (az SAP-környezet adatbázisrésze) tervezésének részét képező főbb elemeket az alábbi táblázat sorolja fel:

Téma	Rövid leírás
Azure-erőforráscsoportok definiálása	Erőforráscsoportok, ahol virtuális gépet, virtuális hálózatot, Azure Load Balancert és egyéb erőforrásokat helyez üzembe. Lehet meglévő vagy új.
Virtuális hálózat / alhálózat definíciója	Ahol az IBM Db2 és az Azure Load Balancer virtuális gépei üzembe vannak helyezve. Lehet meglévő vagy újonnan létrehozott.
IBM Db2 LUW-t futtató virtuális gépek	Virtuális gép mérete, tárhely, hálózatkezelés, IP-cím.
Virtuális gazdagép neve és virtuális IP-címe IBM Db2-adatbázishoz	A virtuális IP-címet vagy a gazdagépnevet használja az SAP-alkalmazáskiszolgálók csatlakoztatásához. db-virt-hostname, db-virt-ip.
Azure-kerítés	Módszer, hogy elkerüljék felosztott agyi helyzetek megelőzhető.
Azure Load Balancer	Standard (ajánlott) mintavételi port használata a Db2-adatbázishoz (a 62500-ra vonatkozó javaslatunk) mintavételi port.
Névfeloldás	A névfeloldás működése a környezetben. A DNS-szolgáltatás erősen ajánlott. A helyi gazdagépfájl használható.

További információ az Azure-beli Linux Pacemakerről: Pacemaker beállítása Red Hat Enterprise Linuxon az Azure-ban.

Fontos

A Db2 11.5.6-os és újabb verzióihoz erősen ajánljuk az IBM Pacemakerrel integrált megoldást.

• Integrált megoldás a Pacemakerrel
• Alternatív vagy további konfigurációk érhetők el a Microsoft Azure-ban

Üzembe helyezés a Red Hat Enterprise Linuxon

Az IBM Db2 LUW erőforrás-ügynöke a Red Hat Enterprise Linux Server HA Addon része. A dokumentumban ismertetett beállításhoz az SAP-hoz készült Red Hat Enterprise Linuxot kell használnia. Az Azure Marketplace tartalmaz egy rendszerképet az SAP-hoz készült Red Hat Enterprise Linux 7.4-hez vagy újabb verzióhoz, amellyel új Azure-beli virtuális gépeket helyezhet üzembe. Vegye figyelembe a Red Hat által az Azure Marketplace-en keresztül kínált különböző támogatási vagy szolgáltatási modelleket, amikor az Azure-beli virtuálisgép-piactéren kiválaszt egy virtuálisgép-rendszerképet.

Gazdagépek: DNS-frissítések

Készítsen listát az összes gazdagépnévről, beleértve a virtuális gazdagépneveket is, és frissítse a DNS-kiszolgálókat, hogy a megfelelő IP-címet engedélyezze a gazdagépnév feloldásához. Ha egy DNS-kiszolgáló nem létezik, vagy nem tudja frissíteni és létrehozni a DNS-bejegyzéseket, az ebben a forgatókönyvben részt vevő egyes virtuális gépek helyi gazdagépfájljait kell használnia. Ha gazdagépfájl-bejegyzéseket használ, győződjön meg arról, hogy a bejegyzések az SAP rendszerkörnyezet összes virtuális gépére érvényesek. Javasoljuk azonban, hogy olyan DNS-t használjon, amely ideális esetben kiterjed az Azure-ra

Manuális üzembe helyezés

Győződjön meg arról, hogy a kiválasztott operációs rendszert az IBM/SAP támogatja az IBM Db2 LUW-hoz. Az Azure-beli virtuális gépek és db2-kiadások támogatott operációsrendszer-verzióinak listája az SAP megjegyzésében 1928533 érhető el. Az egyes DB2-kiadások operációsrendszer-kiadásainak listája elérhető az SAP termék rendelkezésre állási mátrixában. A Red Hat Enterprise Linux ezen vagy újabb verzióiban az Azure-hoz kapcsolódó teljesítménybeli fejlesztések miatt erősen javasoljuk a Red Hat Enterprise Linux 7.4-et az SAP-hoz.

1. Hozzon létre vagy válasszon ki egy erőforráscsoportot.
2. Hozzon létre vagy válasszon ki egy virtuális hálózatot és alhálózatot.
3. Válasszon egy megfelelő üzembe helyezési típust az SAP virtuális gépekhez. Általában egy rugalmas vezénylésű virtuálisgép-méretezési csoport.
4. Virtuális gép létrehozása 1.
   1. Használja a Red Hat Enterprise Linux for SAP rendszerképet az Azure Marketplace-en.
   2. Válassza ki a 3. lépésben létrehozott méretezési csoportot, rendelkezésre állási zónát vagy rendelkezésre állási csoportot.
5. Virtuális gép létrehozása 2.
   1. Használja a Red Hat Enterprise Linux for SAP rendszerképet az Azure Marketplace-en.
   2. Válassza ki a 3. lépésben létrehozott méretezési csoportot, rendelkezésre állási zónát vagy rendelkezésre állási csoportot (nem ugyanaz a zóna, mint a 4. lépésben).
6. Adjon hozzá adatlemezeket a virtuális gépekhez, majd tekintse meg az IBM DB2 Azure Virtual Machines DBMS sap-számítási feladathoz készült üzembe helyezéséről szóló cikkben található fájlrendszer-beállítás javaslatát.

Az IBM Db2 LUW- és SAP-környezet telepítése

Mielőtt elkezdené az IBM Db2 LUW-n alapuló SAP-környezet telepítését, tekintse át a következő dokumentációt:

• Az Azure dokumentációja.
• SAP-dokumentáció.
• IBM-dokumentáció.

A dokumentációra mutató hivatkozásokat a cikk bevezető szakaszában találja.

Tekintse meg a NetWeaver-alapú alkalmazások IBM Db2 LUW-ra való telepítésével kapcsolatos SAP telepítési kézikönyveket. Az útmutatókat az SAP súgóportálján találja az SAP telepítési útmutató keresőjének használatával.

A portálon megjelenő segédvonalak számát az alábbi szűrők beállításával csökkentheti:

• Szeretnék: Telepítsen egy új rendszert.
• Saját adatbázis: IBM Db2 Linuxhoz, Unixhoz és Windowshoz.
• További szűrők az SAP NetWeaver-verziókhoz, a veremkonfigurációhoz vagy az operációs rendszerhez.

Red Hat tűzfalszabályok

A Red Hat Enterprise Linux alapértelmezés szerint engedélyezve van a tűzfallal.

#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp

Telepítési tippek az IBM Db2 LUW hadr-val való beállításához

Az elsődleges IBM Db2 LUW-adatbázispéldány beállítása:

• Használja a magas rendelkezésre állást vagy az elosztott beállítást.
• Telepítse az SAP ASCS/ERS és az adatbázispéldányt.
• Készítsen biztonsági másolatot az újonnan telepített adatbázisról.

Fontos

Írja le a telepítés során beállított "Adatbázis-kommunikációs portot". Mindkét adatbázispéldány esetében ugyanazzal a portszámmal kell rendelkeznie.

IBM Db2 HADR-beállítások az Azure-hoz

Ha Azure Pacemaker-kerítésügynököt használ, állítsa be a következő paramétereket:

• HADR társablak időtartama (másodperc) (HADR_P Enterprise kiadás R_WINDOW) = 240
• HADR időtúllépési érték (HADR_TIMEOUT) = 45

Az előző paramétereket a kezdeti feladatátvételi/átvételi tesztelés alapján javasoljuk. Kötelező tesztelni a feladatátvétel és az átvétel megfelelő működését ezekkel a paraméterbeállításokkal. Mivel az egyes konfigurációk eltérőek lehetnek, előfordulhat, hogy a paraméterek kiigazítást igényelnek.

Feljegyzés

Jellemző az IBM Db2-hez, amely normál indítású HADR-konfigurációval rendelkezik: A másodlagos vagy készenléti adatbázispéldánynak futnia kell, mielőtt elindíthatja az elsődleges adatbázispéldányt.

Feljegyzés

Az Azure-ra és a Pacemakerre jellemző telepítéshez és konfigurációhoz: Az SAP Software Provisioning Manageren keresztüli telepítési eljárás során explicit kérdés merül fel az IBM Db2 LUW magas rendelkezésre állásával kapcsolatban:

• Ne válassza az IBM Db2 pureScale lehetőséget.
• Ne válassza az IBM Tivoli System Automation telepítése multiplatformokhoz lehetőséget.
• Ne válassza a Fürtkonfigurációs fájlok létrehozása lehetőséget.

Ha a készenléti adatbázis-kiszolgálót az SAP homogén rendszermásolási eljárásával szeretné beállítani, hajtsa végre az alábbi lépéseket:

1. Válassza a Rendszer másolása lehetőséget> A Célrendszerek>elosztott>adatbázis példánya lehetőséget.
2. Másolási módszerként válassza a Homogén rendszer lehetőséget, hogy a biztonsági mentés használatával visszaállíthassa a biztonsági mentést a készenléti kiszolgáló példányán.
3. Amikor eléri a kilépési lépést az adatbázis homogén rendszermásoláshoz való visszaállításához, lépjen ki a telepítőből. Állítsa vissza az adatbázist az elsődleges gazdagép biztonsági másolatából. Az összes későbbi telepítési fázis már végrehajtásra került az elsődleges adatbázis-kiszolgálón.

Red Hat tűzfalszabályok a DB2 HADR-hez

Adjon hozzá tűzfalszabályokat, amelyek lehetővé teszik a DB2 és a DB2 közötti forgalmat a HADR működéséhez:

• Adatbázis-kommunikációs port. Partíciók használata esetén ezeket a portokat is vegye fel.
• HADR-port (a DB2 paraméter értéke HADR_LOCAL_SVC).
• Azure-mintavételi port.

sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload

IBM Db2 HADR-ellenőrzés

Bemutató célokra és az ebben a cikkben ismertetett eljárások esetében az adatbázis SID azonosítója 2.

Miután konfigurálta a HADR-t, és az állapot P Enterprise kiadás R és CONNECTED az elsődleges és készenléti csomópontokon, hajtsa végre a következő ellenőrzést:

Execute command as db2<sid> db2pd -hadr -db <SID>

#Primary output:
Database Member 0 -- Database ID2 -- Active -- Up 1 days 15:45:23 -- Date 2019-06-25-10.55.25.349375

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = az-idb01
                     PRIMARY_INSTANCE = db2id2
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = az-idb02
                     STANDBY_INSTANCE = db2id2
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.076494 (1561460105)
          HEARTBEAT_INTERVAL(seconds) = 7
                     HEARTBEAT_MISSED = 5
                   HEARTBEAT_EXPECTED = 52
                HADR_TIMEOUT(seconds) = 30
        TIME_SINCE_LAST_RECV(seconds) = 5
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
                  LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
                  HADR_LOG_GAP(bytes) = 132242668
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
                     STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
              STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
         STANDBY_RECV_BUF_SIZE(pages) = 2048
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 1000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 300
                      PEER_WINDOW_END = 06/25/2019 11:12:03.000000 (1561461123)
             READS_ON_STANDBY_ENABLED = N


#Secondary output:
Database Member 0 -- Database ID2 -- Standby -- Up 1 days 15:45:18 -- Date 2019-06-25-10.56.19.820474

                            HADR_ROLE = STANDBY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 0
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = az-idb01
                     PRIMARY_INSTANCE = db2id2
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = az-idb02
                     STANDBY_INSTANCE = db2id2
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.078116 (1561460105)
          HEARTBEAT_INTERVAL(seconds) = 7
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 10
                HADR_TIMEOUT(seconds) = 30
        TIME_SINCE_LAST_RECV(seconds) = 1
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
                  LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
                     STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
              STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
         STANDBY_RECV_BUF_SIZE(pages) = 2048
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 1000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 1000
                      PEER_WINDOW_END = 06/25/2019 11:12:59.000000 (1561461179)
             READS_ON_STANDBY_ENABLED = N

Az Azure Load Balancer konfigurálása

A virtuális gép konfigurálása során lehetősége van a terheléselosztó hálózatkezelési szakaszának létrehozására vagy kilépésére. Az alábbi lépéseket követve állítsa be a standard terheléselosztót a DB2-adatbázis magas rendelkezésre állású beállításához.

Azure Portal

Kövesse a Terheléselosztó létrehozása című témakörben leírt lépéseket egy standard terheléselosztó beállításához egy magas rendelkezésre állású SAP-rendszerhez az Azure Portal használatával. A terheléselosztó beállítása során vegye figyelembe a következő pontokat:

1. Előtérbeli IP-konfiguráció: Előtérbeli IP-cím létrehozása. Válassza ki ugyanazt a virtuális hálózatot és alhálózatnevet, mint az adatbázis virtuális gépei.
2. Háttérkészlet: Hozzon létre egy háttérkészletet, és vegyen fel adatbázis virtuális gépeket.
3. Bejövő szabályok: Terheléselosztási szabály létrehozása. Kövesse ugyanazokat a lépéseket mindkét terheléselosztási szabály esetében.
   • Előtérbeli IP-cím: Válasszon egy előtérbeli IP-címet.
   • Háttérkészlet: Válasszon egy háttérkészletet.
   • Magas rendelkezésre állású portok: Válassza ezt a lehetőséget.
   • Protokoll: Válassza ki a TCP-t.
   • Állapotadat-mintavétel: Hozzon létre egy állapotmintát a következő részletekkel:
     • Protokoll: Válassza ki a TCP-t.
     • Port: Például 625<példányszám>.
     • Intervallum: Adja meg az 5 értéket.
     • Mintavétel küszöbértéke: Adja meg a 2 értéket.
   • Tétlen időtúllépés (perc):: Adja meg a 30-at.
   • Lebegő IP-cím engedélyezése: Válassza ezt a lehetőséget.

Feljegyzés

Az állapotadat-mintavétel konfigurációs tulajdonsága numberOfProbes( más néven nem megfelelő állapot küszöbértéke a portálon) nem lesz tiszteletben tartva. A sikeres vagy sikertelen egymást követő mintavételek számának szabályozásához állítsa a tulajdonságot probeThreshold a következőre 2: . Ezt a tulajdonságot jelenleg nem lehet beállítani az Azure Portal használatával, ezért használja az Azure CLI-t vagy a PowerShell-parancsot .

Azure CLI

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

Kibontás a teljes CLI-kód megtekintéséhez

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

PowerShell

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

Kibontás a teljes PowerShell-kód megtekintéséhez

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

Fontos

A lebegő IP-cím nem támogatott a hálózati adapter másodlagos IP-konfigurációjában terheléselosztási forgatókönyvekben. További információkért tekintse meg az Azure Load Balancer korlátait. Ha másik IP-címre van szüksége a virtuális géphez, helyezzen üzembe egy második hálózati adaptert.

Feljegyzés

Ha a nyilvános IP-címekkel nem rendelkező virtuális gépek a Standard Azure Load Balancer egy belső (nyilvános IP-cím nélküli) példányának háttérkészletébe kerülnek, nincs kimenő internetkapcsolat, kivéve, ha több konfigurációt hajt végre a nyilvános végpontok felé történő útválasztás engedélyezéséhez. A kimenő kapcsolatok elérésével kapcsolatos további információkért tekintse meg az Azure Standard Load Balancert használó virtuális gépek nyilvános végpontkapcsolatait az SAP magas rendelkezésre állású forgatókönyveiben.

Fontos

Ne engedélyezze a TCP-időbélyegeket az Azure Load Balancer mögött elhelyezett Azure-beli virtuális gépeken. A TCP-időbélyegek engedélyezése az állapotminták sikertelenségéhez vezethet. Állítsa be a paramétert a következőre net.ipv4.tcp_timestamps0: . További információt a Load Balancer állapottesztjeiben talál.

[A] Tűzfalszabály hozzáadása mintavételi porthoz:

sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload

A Pacemaker-fürt létrehozása

Ha alapszintű Pacemaker-fürtöt szeretne létrehozni ehhez az IBM Db2-kiszolgálóhoz, olvassa el a Pacemaker beállítása Red Hat Enterprise Linuxon az Azure-ban című témakört.

A Db2 Pacemaker konfigurációja

Ha csomóponthiba esetén a Pacemakert használja az automatikus feladatátvételhez, ennek megfelelően kell konfigurálnia a Db2-példányokat és a Pacemakert. Ez a szakasz az ilyen típusú konfigurációt ismerteti.

A következő elemek előtagja a következő:

• [A]: Minden csomópontra alkalmazható
• [1]: Csak az 1. csomópontra alkalmazható
• [2]: Csak a 2. csomópontra alkalmazható

[A] A Pacemaker konfigurációjának előfeltétele:

• Állítsa le mindkét adatbázis-kiszolgálót a db2stop felhasználói adatbázis-azonosítóval<>.

• Módosítsa a rendszerhéj-környezetet a db2<sid-felhasználóhoz> a /bin/ksh fájlra:

  # Install korn shell:
  sudo yum install ksh
  # Change users shell:
  sudo usermod -s /bin/ksh db2<sid>
  

Pacemaker-konfiguráció

1. [1] IBM Db2 HADR-specifikus Pacemaker-konfiguráció:

   # Put Pacemaker into maintenance mode
   sudo pcs property set maintenance-mode=true
   

2. [1] IBM Db2-erőforrások létrehozása:

   Ha fürtöt hoz létre az RHEL 7.x-en, győződjön meg arról, hogy a csomag erőforrás-ügynökeit verzióra vagy újabb verzióra resource-agents-4.1.1-61.el7_9.15 frissíti. A fürterőforrások létrehozásához használja az alábbi parancsokat:

   # Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' master meta notify=true resource-stickiness=5000
   
   #Configure resource stickiness and correct cluster notifications for master resoruce
   sudo pcs resource update Db2_HADR_ID2-master meta notify=true resource-stickiness=5000
   
   # Configure virtual IP - same as Azure Load Balancer IP
   sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40'
   
   # Configure probe port for Azure load Balancer
   sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500
   
   #Create a group for ip and Azure loadbalancer probe port
   sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2
   
   #Create colocation constrain - keep Db2 HADR Master and Group on same node
   sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-master
   
   #Create start order constrain
   sudo pcs constraint order promote Db2_HADR_ID2-master then g_ipnc_db2id2_ID2
   

   Ha fürtöt hoz létre az RHEL 8.x-en, győződjön meg arról, hogy a csomag erőforrás-ügynökeit verzióra vagy újabb verzióra resource-agents-4.1.1-93.el8 frissíti. További részletekért lásd: Red Hat KBA-erőforrás db2 HADR-rel való előléptetése sikertelen állapottal PRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. A fürterőforrások létrehozásához használja az alábbi parancsokat:

   # Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' promotable meta notify=true resource-stickiness=5000
   
   #Configure resource stickiness and correct cluster notifications for master resoruce
   sudo pcs resource update Db2_HADR_ID2-clone meta notify=true resource-stickiness=5000
   
   # Configure virtual IP - same as Azure Load Balancer IP
   sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40'
   
   # Configure probe port for Azure load Balancer
   sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500
   
   #Create a group for ip and Azure loadbalancer probe port
   sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2
   
   #Create colocation constrain - keep Db2 HADR Master and Group on same node
   sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-clone
   
   #Create start order constrain
   sudo pcs constraint order promote Db2_HADR_ID2-clone then g_ipnc_db2id2_ID2
   

3. [1] Ibm Db2-erőforrások indítása:

   A Pacemakert ki kell állítani a karbantartási módból.

   # Put Pacemaker out of maintenance-mode - that start IBM Db2
   sudo pcs property set maintenance-mode=false
   

4. [1] Győződjön meg arról, hogy a fürt állapota rendben van, és az összes erőforrás el van indítva. Nem fontos, hogy melyik csomóponton futnak az erőforrások.

   sudo pcs status
   2 nodes configured
   5 resources configured
   
   Online: [ az-idb01 az-idb02 ]
   
   Full list of resources:
   
   rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
   Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
        Masters: [ az-idb01 ]
        Slaves: [ az-idb02 ]
   Resource Group: g_ipnc_db2id2_ID2
        vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
        nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01
   
   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled
   

Fontos

A Pacemaker fürtözött Db2-példányát Pacemaker-eszközökkel kell kezelnie. Ha olyan DB2-parancsokat használ, mint a db2stop, a Pacemaker erőforráshibaként észleli a műveletet. Ha karbantartást végez, a csomópontokat vagy erőforrásokat karbantartási módban helyezheti el. A Pacemaker felfüggeszti az erőforrások monitorozását, és használhatja a normál DB2 felügyeleti parancsokat.

Az SAP-profilok módosítása a virtuális IP-cím kapcsolathoz való használatához

A HADR-konfiguráció elsődleges példányához való csatlakozáshoz az SAP-alkalmazásrétegnek az Azure Load Balancerhez definiált és konfigurált virtuális IP-címet kell használnia. A következő módosítások szükségesek:

/sapmnt/<SID>/profile/DEFAULT. PFL

SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname

/sapmnt/<SID>/global/db6/db2cli.ini

Hostname=db-virt-hostname

Elsődleges és párbeszédpaneles alkalmazáskiszolgálók telepítése

Amikor elsődleges és párbeszédpaneles alkalmazáskiszolgálót telepít egy Db2 HADR-konfigurációra, használja a konfigurációhoz kiválasztott virtuális gazdagépnevet.

Ha a telepítést a Db2 HADR-konfiguráció létrehozása előtt hajtotta végre, végezze el a módosításokat az előző szakaszban leírtak szerint, az SAP Java-veremek esetében pedig az alábbiak szerint.

ABAP+Java vagy Java veremrendszerek JDBC URL-ellenőrzése

A J2 Enterprise kiadás Config eszközzel ellenőrizze vagy frissítse a JDBC URL-címét. Mivel a J2 Enterprise kiadás konfigurációs eszköz grafikus eszköz, telepítenie kell az X-kiszolgálót:

1. Jelentkezzen be a J2 Enterprise kiadás-példány elsődleges alkalmazáskiszolgálójára, és hajtsa végre:

   sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh
   

2. A bal oldali keretben válassza a biztonsági tárolót.

3. A jobb oldali keretben válassza ki a kulcsot jdbc/pool/\<SAPSID>/url.

4. Módosítsa a gazdagép nevét a JDBC URL-címében a virtuális gazdagép nevére.

   jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0
   

5. Válassza a Hozzáadás lehetőséget.

6. A módosítások mentéséhez válassza a lemez ikont a bal felső sarokban.

7. Zárja be a konfigurációs eszközt.

8. Indítsa újra a Java-példányt.

Naplóarchiválás konfigurálása HADR-beállításhoz

A HADR beállításához szükséges Db2-naplóarchiválás konfigurálásához azt javasoljuk, hogy az elsődleges és a készenléti adatbázist is úgy konfigurálja, hogy minden naplóarchívum helyről automatikus naplólekérési képességgel rendelkezzen. Mind az elsődleges, mind a készenléti adatbázisnak képesnek kell lennie a naplóarchívumfájlok lekérésére az összes olyan naplóarchívum-helyről, amelyre az adatbázispéldányok bármelyike archiválhatja a naplófájlokat.

A naplóarchiválást csak az elsődleges adatbázis végzi. Ha módosítja az adatbázis-kiszolgálók HADR-szerepköreit, vagy hiba történik, az új elsődleges adatbázis felelős a naplóarchiválásért. Ha több naplóarchívum-helyet állított be, előfordulhat, hogy a naplók kétszer lesznek archiválva. Helyi vagy távoli felzárkózás esetén előfordulhat, hogy manuálisan kell átmásolnia az archivált naplókat a régi elsődleges kiszolgálóról az új elsődleges kiszolgáló aktív naplóhelyére.

Javasoljuk, hogy konfiguráljon egy közös NFS-megosztást vagy GlusterFS-t, ahol a naplók mindkét csomópontról íródnak. Az NFS-megosztásnak vagy a GlusterFS-nek magas rendelkezésre állásúnak kell lennie.

Meglévő magas rendelkezésre állású NFS-megosztásokat vagy GlusterFS-t használhat átvitelekhez vagy profilkönyvtárakhoz. További információkért lásd:

• GlusterFS Azure-beli virtuális gépeken az SAP NetWeaverhez készült Red Hat Enterprise Linux rendszeren.
• Az SAP NetWeaver magas rendelkezésre állása Azure-beli virtuális gépeken Red Hat Enterprise Linux rendszeren az Azure NetApp Files for SAP Applications használatával.
• Azure NetApp Files (NFS-megosztások létrehozásához).

A fürt beállításának tesztelése

Ez a szakasz azt ismerteti, hogyan tesztelheti a Db2 HADR-beállításokat. Minden teszt feltételezi, hogy az IBM Db2 elsődleges verziója az az-idb01 virtuális gépen fut. A sudo jogosultságokkal vagy gyökérrel rendelkező felhasználót (nem ajánlott) használni kell.

Az összes teszteset kezdeti állapotát itt ismertetheti: (crm_mon -r vagy pcs állapot)

• a pcs állapota a Pacemaker állapotának pillanatképe a végrehajtási időpontban.
• crm_mon -r a Pacemaker állapotának folyamatos kimenete.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Egy SAP-rendszerben az eredeti állapot dokumentálva van a Transaction DBACOCKPIT > konfigurációjának > áttekintésében, ahogyan az a következő képen látható:

Az IBM Db2 átvételének tesztelése

Fontos

A teszt megkezdése előtt győződjön meg arról, hogy:

• A Pacemaker nem rendelkezik sikertelen műveletekkel (pcs status).

• Nincsenek helykorlátozások (a migrálási teszt hátrahagyása).

• Az IBM Db2 HADR szinkronizálása működik. Ellenőrizze a felhasználói db2<biztonsági azonosítót>.

  db2pd -hadr -db <DBSID>
  

Az elsődleges Db2-adatbázist futtató csomópont áttelepítése a következő parancs végrehajtásával:

# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master

A migrálás befejezése után a CRM állapotkimenete a következőképpen néz ki:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Egy SAP-rendszerben az eredeti állapot dokumentálva van a Transaction DBACOCKPIT > konfigurációjának > áttekintésében, ahogyan az a következő képen látható:

A "pcs resource move" erőforrás-áthelyezéssel történő erőforrás-migrálás helykorlátozásokat hoz létre. Ebben az esetben a helykorlátozások megakadályozzák az IBM Db2-példány futtatását az az-idb01 rendszeren. Ha a helymegkötések nem törlődnek, az erőforrás nem tud feladat-visszavételt végrehajtani.

A helykorlát és a készenléti csomópont eltávolítása az az-idb01 rendszeren indulna el.

# On RHEL 7.x
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource clear Db2_HADR_ID2-clone

A fürt állapota a következőre módosul:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

 rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
 Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
 Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Az erőforrás migrálása az az-idb01-be , és a helykorlátozások törlése

# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master az-idb01
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
sudo pcs resource clear Db2_HADR_ID2-clone

• RHEL 7.x rendszeren – pcs resource move <resource_name> <host>: Helykorlátozásokat hoz létre, és problémákat okozhat az átvétellel kapcsolatban
• RHEL 8.x rendszeren – pcs resource move <resource_name> --master: Helymegkötéseket hoz létre, és problémákat okozhat az átvétellel kapcsolatban
• pcs resource clear <resource_name>: Helykorlátozások törlése
• pcs resource cleanup <resource_name>: Törli az erőforrás összes hibáját

Manuális átvétel tesztelése

A manuális átvétel teszteléséhez leállíthatja a Pacemaker szolgáltatást az az-idb01 csomóponton:

systemctl stop pacemaker

az-ibdb02 állapota

2 nodes configured
5 resources configured

Node az-idb01: pending
Online: [ az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

A feladatátvétel után újra elindíthatja a szolgáltatást az az-idb01-en.

systemctl start  pacemaker

A HADR elsődleges adatbázist futtató csomóponton lévő Db2-folyamat leállítása

#Kill main db2 process - db2sysc
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 34598

A Db2-példány sikertelen lesz, és a Pacemaker áthelyezi a fő csomópontot és a következő állapotot jelenti:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=49, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 09:57:35 2019', queued=0ms, exec=362ms

A Pacemaker újraindítja a db2 elsődleges adatbázispéldányt ugyanazon a csomóponton, vagy a másodlagos adatbázispéldányt futtató csomóponton meghiúsul, és hibaüzenet jelenik meg.

A másodlagos adatbázispéldányt futtató csomópont db2-folyamatának leállítása

[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2id2    23144  23142  2 09:53 ?        00:00:13 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 23144

A csomópont sikertelen lesz, és hibajelentést kap.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

Failed Actions:
* Db2_HADR_ID2_monitor_20000 on az-idb02 'not running' (7): call=144, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 10:02:09 2019', queued=0ms, exec=0ms

A db2-példány újraindul a korábban hozzárendelt másodlagos szerepkörben.

Adatbázis leállítása a HADR elsődleges adatbázispéldányt futtató csomóponton a DB2stop-erőn keresztül

Felhasználó db2<sid-ként> hajtsa végre a db2stop force parancsot:

az-idb01:db2ptr> db2stop force

Hiba észlelhető:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Slaves: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Stopped
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Stopped

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms

A db2 HADR másodlagos adatbázispéldány elő lett léptetve az elsődleges szerepkörbe.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms

A HADR elsődleges adatbázispéldányát futtató virtuális gép összeomlása "leállással"

#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger

Ilyen esetben a Pacemaker észleli, hogy az elsődleges adatbázispéldányt futtató csomópont nem válaszol.

2 nodes configured
5 resources configured

Node az-idb01: UNCLEAN (online)
Online: [ az-idb02 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

A következő lépés a split agy helyzetének ellenőrzése. Miután a túlélő csomópont megállapította, hogy az elsődleges adatbázispéldányt utoljára futtató csomópont leállt, a rendszer végrehajtja az erőforrások feladatátvételét.

2 nodes configured
5 resources configured

Online: [ az-idb02 ]
OFFLINE: [ az-idb01 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Kernelhiba esetén a meghiúsult csomópontot a kerítésügynök újraindítja. A sikertelen csomópont online állapotba helyezése után a pacemaker-fürtöt a következővel kell elindítania:

sudo pcs cluster start

a db2-példányt a másodlagos szerepkörbe indítja.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Következő lépések

• Magas rendelkezésre állású architektúra és forgatókönyvek az SAP NetWeaverhez
• Pacemaker beállítása Red Hat Enterprise Linuxon az Azure-ban