Share via

Az IBM Db2 LUW magas rendelkezésre állása Azure-beli virtuális gépeken su Standard kiadás Linux Enterprise Serveren a Pacemakerrel

  • Cikk

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
1984787 SU Standard kiadás Linux Enterprise Server 12: Telepítési megjegyzések
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
SU Standard kiadás Linux Enterprise Server for SAP Applications 12 SP4 – ajánlott eljárások útmutatói
SU Standard kiadás Linux Enterprise High Availability Extension 12 SP4
IBM Db2 Azure Virtual Machines DBMS üzembe helyezése SAP-számítási feladathoz
IBM Db2 HADR 11.1
IBM Db2 HADR R 10.5

Á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 ehhez az elsődleges példányhoz csatlakozik. 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.

IBM Db2 high availability overview

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.

IBM DB2 high availability full environment overview

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 SU Standard kiadás Linuxot, és konfigurálja a fájlrendszereket.
  • Telepítse és konfigurálja a Pacemakert.
  • Telepítse a magas rendelkezésre állású NFS-t.
  • 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 Az SAP-alkalmazáskiszolgálók kapcsolatához használt virtuális IP-cím vagy gazdagépnév. db-virt-hostname, db-virt-ip.
Azure-kerítés Azure-kerítés vagy SBD-kerítés (erősen ajánlott). Módszer az agy felosztásának elkerülésére.
SBD virtuális gép SBD virtuális gép mérete, tároló, hálózat.
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 su Standard kiadás Linux Enterprise Serveren 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.

Üzembe helyezés SU-n Standard kiadás Linuxon

Az IBM Db2 LUW erőforrás-ügynöke a SU Standard kiadás Linux Enterprise Server for SAP Applications része. A dokumentumban ismertetett beállításhoz az SAP-alkalmazásokhoz készült SU Standard kiadás Linux Servert kell használnia. Az Azure Marketplace tartalmaz egy rendszerképet az SAP Applications 12-hez készült SU Standard kiadás Enterprise Serverhez, amellyel új Azure-beli virtuális gépeket helyezhet üzembe. Vegye figyelembe az SU által kínált különböző támogatási vagy szolgáltatási modelleket Standard kiadás az Azure Marketplace-en keresztül, 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. Javasoljuk, hogy legalább SLES 12 SP4-et használjon az Azure-hoz kapcsolódó teljesítménybeli fejlesztések miatt ebben a vagy újabb SU Standard kiadás Linux-verziókban.

  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. Az SLES használata SAP-rendszerképhez 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. Az SLES használata SAP-rendszerképhez 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:

  • Azure-dokumentáció
  • SAP-dokumentáció
  • AZ IBM dokumentációja

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:

  • A következőt szeretném tenni: "Új rendszer telepítése"
  • 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

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 portszámának azonosnak kell lennie SAP SWPM Port Definition

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.

  4. A HADR beállítása az IBM Db2-hez.

    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 SBD-eszközt használ Linux Pacemakerhez, állítsa be a következő DB2 HADR-paramétereket:

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

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) = 900
  • HADR időtúllépési érték (HADR_TIMEOUT) = 60

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.

Fontos

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.

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

IBM Db2 HADR-ellenőrzés

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 PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
# 
#                             HADR_ROLE = PRIMARY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 1
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6137
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 13
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#        STANDBY_RECV_REPLAY_GAP(bytes) = 0
#                      PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#                      STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
#              READS_ON_STANDBY_ENABLED = N

#Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
# 
#                             HADR_ROLE = STANDBY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 0
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6186
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 5
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#        STANDBY_RECV_REPLAY_GAP(bytes) = 155
#                      PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#                      STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
#              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.

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 .

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 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 SU Standard kiadás Linux Enterprise Serveren 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ételei:

  • Állítsa le mindkét adatbázis-kiszolgálót a db2stop felhasználói adatbázis-azonosítóval<>.
  • Módosítsa a db2<sid-felhasználó> rendszerhéj-környezetét a /bin/ksh fájlra. Javasoljuk, hogy használja a Yast eszközt.

Pacemaker-konfiguráció

Fontos

A legutóbbi tesztelés olyan helyzeteket tárt fel, amikor a netcat nem válaszol a kérelmekre a hátralék miatt, és csak egy kapcsolat kezelésére vonatkozó korlátozása miatt. A netcat-erőforrás nem figyeli az Azure Load Balancer-kérelmeket, és a lebegő IP-cím elérhetetlenné válik. A meglévő Pacemaker-fürtök esetében azt javasoljuk, hogy a netcatet cserélje le a socatre. Jelenleg az azure-lb erőforrásügynök használatát javasoljuk, amely a csomagerőforrás-ügynökök része, és a következő csomagverzió-követelményekkel:

  • Az SLES 12 SP4/SP5 esetén a verziónak legalább resource-agents-4.3.018.a7fb5035-3.30.1 verziónak kell lennie.
  • Az SLES 15/15 SP1 esetén a verziónak legalább resource-agents-4.3.0184.6ee15eb2-4.13.1 verziónak kell lennie.

Vegye figyelembe, hogy a módosítás rövid állásidőt igényel.
Meglévő Pacemaker-fürtök esetében, ha a konfigurációt már módosították az Azure Load-Balancer Detection Hardeningben leírt socat használatára, nincs szükség arra, hogy azonnal átváltson az Azure-lb erőforrás-ügynökre.

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

    # Put Pacemaker into maintenance mode
sudo crm configure property maintenance-mode=true

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

    # Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \
        params instance="db2ptr" dblist="PTR" \
        op start interval="0" timeout="130" \
        op stop interval="0" timeout="120" \
        op promote interval="0" timeout="120" \
        op demote interval="0" timeout="120" \
        op monitor interval="30" timeout="60" \
        op monitor interval="31" role="Master" timeout="60"

# Configure virtual IP - same as Azure Load Balancer IP
sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \
        op monitor interval="10s" timeout="20s" \
        params ip="10.100.0.10"

# Configure probe port for Azure load Balancer
sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \
        op monitor timeout=20s interval=10

sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR

sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \
        meta target-role="Started" notify="true"

sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master

sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

  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 crm configure property 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 crm status

# 2 nodes configured
# 5 resources configured

# Online: [ azibmdb01 azibmdb02 ]

# Full list of resources:

# stonith-sbd    (stonith:external/sbd): Started azibmdb02
# Resource Group: g_ip_db2ptr_PTR
#      rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
#      rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
# Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
#      Masters: [ azibmdb02 ]
#      Slaves: [ azibmdb01 ]

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 jdbc/pool/<SAPSID>/url kulcsot.

  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, ahol a naplók mindkét csomópontról íródnak. Az NFS-megosztásnak magas rendelkezésre állásúnak kell lennie.

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

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 azt feltételezi, hogy felhasználógyökérként van bejelentkezve, és az IBM DB2 elsődleges az azibmdb01 virtuális gépen fut.

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

  • A CRM-állapot a Pacemaker végrehajtási idejének pillanatképe.
  • crm_mon -r a Pacemaker állapotának folyamatos kimenete.
2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   Promoting azibmdb01
     Slaves: [ azibmdb02 ]

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ó:

DBACockpit - Pre Migration

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 (crm állapota).

  • 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:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

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: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

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ó:

DBACockpit - Post Migration

A "crm-erőforrás migrálásával" történő erőforrás-migrálás helykorlátozásokat hoz létre. A helykorlátozásokat törölni kell. Ha a helykorlátozások nem törlődnek, az erőforrás nem tud feladat-visszavételt végrehajtani, vagy nem kívánt átvételt tapasztalhat.

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

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
  • crm-erőforrás migrálása <res_name<>gazdagép>: Helykorlátozásokat hoz létre, és problémákat okozhat az átvétellel kapcsolatban
  • crm-erőforrás törlése <res_name>: Helykorlátozások törlése
  • crm-erőforrás-törlési <res_name>: Törli az erőforrás összes hibáját

SBD-kerítés tesztelése

Ebben az esetben teszteljük az SBD-kerítést, amelyet a SU Standard kiadás Linux használatakor javasoljuk.

azibmdb01:~ # ps -ef|grep sbd
root       2374      1  0 Feb05 ?        00:00:17 sbd: inquisitor
root       2378   2374  0 Feb05 ?        00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root       2379   2374  0 Feb05 ?        00:01:51 sbd: watcher: Pacemaker
root       2380   2374  0 Feb05 ?        00:00:18 sbd: watcher: Cluster

azibmdb01:~ # kill -9 2374

Az azibmdb01 fürtcsomópontot újra kell indítani. Az IBM Db2 elsődleges HADR-szerepköre át lesz helyezve az azibmdb02-be. Amikor azibmdb01 újra online állapotba kerül, a Db2-példány egy másodlagos adatbázispéldány szerepkörében fog mozogni.

Ha a Pacemaker szolgáltatás nem indul el automatikusan az újraindult korábbi elsődlegesen, mindenképpen indítsa el manuálisan a következővel:

sudo service pacemaker start

Manuális átvétel tesztelése

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

service pacemaker stop

azibmdb02 állapota

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

A feladatátvétel után újra elindíthatja a szolgáltatást az azibmdb01 rendszeren.

service pacemaker start

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

#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0

azibmdb01:~ # kill -9 34598

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Slaves: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

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.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

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

azibmdb02:~ # ps -ef|grep db2s
db2ptr    65250  65248  0 Feb11 ?        00:09:27 db2sysc 0

azibmdb02:~ # kill -9

A csomópont hibásan lesz jelezve, és hiba jelentve

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb02
     Masters: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

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

azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force

Hiba észlelhető

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb01
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms

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

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms

A HADR elsődleges adatbázispéldányt futtató csomópont újraindításával összeomlik a virtuális gép

#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger

A Pacemaker előlépteti a másodlagos példányt az elsődleges példány szerepkörére. A régi elsődleges példány a virtuális gép után a másodlagos szerepkörbe kerül, és a virtuális gép újraindítása után az összes szolgáltatás teljesen vissza lesz állítva.

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

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

#Linux kernel panic - halts OS
azibmdb01:~ # 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 azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

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: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

A csomópont "leállása" esetén a sikertelen csomópontot újra kell indítani az Azure Management eszközeivel (az Azure Portalon, a PowerShellben vagy az Azure CLI-ben). Miután a sikertelen csomópont újra online állapotba került, a db2-példányt a másodlagos szerepkörbe indítja.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
 Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
 Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

Következő lépések