Hoge beschikbaarheid van IBM Db2 LUW op Azure-VM's op SUSE Linux Enterprise Server met Pacemaker
IBM Db2 voor Linux, UNIX en Windows (LUW) in de HADR-configuratie (hoge beschikbaarheid en herstel na noodgevallen) bestaat uit één knooppunt waarop een primaire database-exemplaar en ten minste één knooppunt wordt uitgevoerd waarop een secundair database-exemplaar wordt uitgevoerd. Wijzigingen in het primaire database-exemplaar worden synchroon of asynchroon gerepliceerd naar een secundair database-exemplaar, afhankelijk van uw configuratie.
Notitie
Dit artikel bevat verwijzingen naar termen die Microsoft niet meer gebruikt. Wanneer deze voorwaarden uit de software worden verwijderd, worden deze uit dit artikel verwijderd.
In dit artikel wordt beschreven hoe u de virtuele Azure-machines (VM's) implementeert en configureert, het clusterframework installeert en de IBM Db2 LUW installeert met HADR-configuratie.
Het artikel bevat geen informatie over het installeren en configureren van IBM Db2 LUW met HADR- of SAP-software-installatie. Om u te helpen deze taken uit te voeren, bieden we verwijzingen naar SAP- en IBM-installatiehandleidingen. Dit artikel is gericht op onderdelen die specifiek zijn voor de Azure-omgeving.
De ondersteunde IBM Db2-versies zijn 10.5 en hoger, zoals beschreven in SAP Note 1928533.
Raadpleeg de volgende SAP-notities en -documentatie voordat u begint met de installatie:
| SAP-notitie | Beschrijving |
|---|---|
| 1928533 | SAP-toepassingen in Azure: ondersteunde producten en Typen Azure-VM's |
| 2015553 | SAP op Azure: ondersteuningsvereisten |
| 2178632 | Metrische gegevens voor sleutelbewaking voor SAP in Azure |
| 2191498 | SAP op Linux met Azure: Verbeterde bewaking |
| 2243692 | Linux op Azure -VM (IaaS): problemen met SAP-licenties |
| 1984787 | SUSE LINUX Enterprise Server 12: Installatieopmerkingen |
| 1999351 | Problemen met verbeterde Azure-bewaking voor SAP oplossen |
| 2233094 | DB6: SAP-toepassingen in Azure die gebruikmaken van IBM Db2 voor Linux, UNIX en Windows - aanvullende informatie |
| 1612105 | DB6: Veelgestelde vragen over Db2 met HADR |
Overzicht
Om hoge beschikbaarheid te bereiken, wordt IBM Db2 LUW met HADR geïnstalleerd op ten minste twee virtuele Azure-machines, die worden geïmplementeerd in een virtuele-machineschaalset met flexibele indeling in beschikbaarheidszones of in een beschikbaarheidsset.
In de volgende afbeeldingen ziet u een installatie van twee Azure-VM's van de databaseserver. Beide azure-VM's van de databaseserver hebben hun eigen opslag gekoppeld en worden uitgevoerd. In HADR heeft één database-exemplaar in een van de Virtuele Azure-machines de rol van het primaire exemplaar. Alle clients zijn verbonden met dit primaire exemplaar. Alle wijzigingen in databasetransacties worden lokaal bewaard in het Db2-transactielogboek. Omdat de transactielogboekrecords lokaal worden bewaard, worden de records via TCP/IP overgebracht naar het database-exemplaar op de tweede databaseserver, de stand-byserver of het stand-by-exemplaar. Het stand-by-exemplaar werkt de lokale database bij door de overgedragen transactielogboekrecords door te sturen. Op deze manier wordt de stand-byserver gesynchroniseerd met de primaire server.
HADR is alleen een replicatiefunctionaliteit. Het heeft geen foutdetectie en geen automatische overname- of failoverfaciliteiten. Een overname of overdracht naar de stand-byserver moet handmatig worden gestart door een databasebeheerder. Als u automatische overname en foutdetectie wilt bereiken, kunt u de clusteringfunctie van Linux Pacemaker gebruiken. Pacemaker bewaakt de twee databaseserverexemplaren. Wanneer het exemplaar van de primaire databaseserver vastloopt, start Pacemaker een automatische HADR-overname door de stand-byserver. Pacemaker zorgt er ook voor dat het virtuele IP-adres wordt toegewezen aan de nieuwe primaire server.
Als u SAP-toepassingsservers verbinding wilt laten maken met de primaire database, hebt u een virtuele hostnaam en een virtueel IP-adres nodig. Na een failover maken de SAP-toepassingsservers verbinding met het nieuwe primaire database-exemplaar. In een Azure-omgeving is een Azure Load Balancer vereist om een virtueel IP-adres te gebruiken op de manier die vereist is voor HADR van IBM Db2.
Om u te helpen volledig te begrijpen hoe IBM Db2 LUW met HADR en Pacemaker in een maximaal beschikbare SAP-systeeminstallatie past, geeft de volgende afbeelding een overzicht van een maximaal beschikbare installatie van een SAP-systeem op basis van IBM Db2-database. Dit artikel bevat alleen betrekking op IBM Db2, maar bevat verwijzingen naar andere artikelen over het instellen van andere onderdelen van een SAP-systeem.
Overzicht op hoog niveau van de vereiste stappen
Als u een IBM Db2-configuratie wilt implementeren, moet u deze stappen uitvoeren:
- Plan uw omgeving.
- Implementeer de VM's.
- Werk SUSE Linux bij en configureer bestandssystemen.
- Pacemaker installeren en configureren.
- Installeer maximaal beschikbare NFS.
- ASCS /ERS installeren op een afzonderlijk cluster.
- Installeer de IBM Db2-database met de optie Distributed/High Availability (SWPM).
- Installeer en maak een secundair databaseknooppunt en -exemplaar en configureer HADR.
- Controleer of HADR werkt.
- Pas de Pacemaker-configuratie toe om IBM Db2 te beheren.
- Azure Load Balancer configureren.
- Installeer primaire en dialoogvenstertoepassingsservers.
- Controleer en pas de configuratie van SAP-toepassingsservers aan.
- Voer failover- en overnametests uit.
Azure-infrastructuur plannen voor het hosten van IBM Db2 LUW met HADR
Voltooi het planningsproces voordat u de implementatie uitvoert. Planning bouwt de basis voor het implementeren van een configuratie van Db2 met HADR in Azure. Belangrijke elementen die deel moeten uitmaken van de planning voor IMB Db2 LUW (databaseonderdeel van sap-omgeving) worden vermeld in de volgende tabel:
| Onderwerp | Korte beschrijving |
|---|---|
| Azure-resourcegroepen definiëren | Resourcegroepen waarin u VM, virtueel netwerk, Azure Load Balancer en andere resources implementeert. Kan bestaand of nieuw zijn. |
| Definitie van virtueel netwerk/subnet | Waar VM's voor IBM Db2 en Azure Load Balancer worden geïmplementeerd. Kan bestaand of nieuw zijn gemaakt. |
| Virtuele machines waarop IBM Db2 LUW wordt gehost | VM-grootte, opslag, netwerken, IP-adres. |
| Naam van virtuele host en virtueel IP-adres voor IBM Db2-database | Het virtuele IP-adres of de hostnaam die wordt gebruikt voor de verbinding van SAP-toepassingsservers. db-virt-hostname, db-virt-ip. |
| Azure-fencing | Azure-fencing of SBD-fencing (sterk aanbevolen). Methode om gesplitste hersensituaties te voorkomen. |
| SBD-VM | Grootte van virtuele SBD-machines, opslag, netwerk. |
| Azure-belastingsverdeling | Gebruik van standard (aanbevolen), testpoort voor db2-database (onze aanbeveling 62500) testpoort. |
| Naamomzetting | Hoe naamomzetting werkt in de omgeving. DNS-service wordt ten zeerste aanbevolen. Het bestand met lokale hosts kan worden gebruikt. |
Zie Pacemaker instellen op SUSE Linux Enterprise Server in Azure voor meer informatie over Linux Pacemaker in Azure.
Belangrijk
Voor Db2-versies 11.5.6 en hoger raden we u ten zeerste aan geïntegreerde oplossing te gebruiken met Pacemaker van IBM.
Implementatie in SUSE Linux
De resourceagent voor IBM Db2 LUW is opgenomen in SUSE Linux Enterprise Server voor SAP-toepassingen. Voor de installatie die in dit document wordt beschreven, moet u SUSE Linux Server voor SAP-toepassingen gebruiken. Azure Marketplace bevat een installatiekopieën voor SUSE Enterprise Server voor SAP Applications 12 die u kunt gebruiken om nieuwe virtuele Azure-machines te implementeren. Houd rekening met de verschillende ondersteunings- of servicemodellen die door SUSE worden aangeboden via Azure Marketplace wanneer u een VM-installatiekopieën kiest in Azure VM Marketplace.
Hosts: DNS-updates
Maak een lijst met alle hostnamen, inclusief namen van virtuele hosts, en werk uw DNS-servers bij om het juiste IP-adres in te schakelen voor hostnaamomzetting. Als er geen DNS-server bestaat of u geen DNS-vermeldingen kunt bijwerken en maken, moet u de lokale hostbestanden gebruiken van de afzonderlijke VM's die deelnemen aan dit scenario. Als u vermeldingen voor hostbestanden gebruikt, moet u ervoor zorgen dat de vermeldingen worden toegepast op alle VM's in de SAP-systeemomgeving. We raden u echter aan uw DNS te gebruiken dat in het ideale voorbeeld wordt uitgebreid naar Azure
Handmatige implementatie
Zorg ervoor dat het geselecteerde besturingssysteem wordt ondersteund door IBM/SAP voor IBM Db2 LUW. De lijst met ondersteunde besturingssysteemversies voor Azure-VM's en Db2-releases is beschikbaar in SAP Note 1928533. De lijst met besturingssysteemreleases per afzonderlijke Db2-release is beschikbaar in de SAP Product Availability Matrix. We raden ten zeerste aan om minimaal SLES 12 SP4 te gebruiken vanwege prestatieverbeteringen in azure in deze of latere SUSE Linux-versies.
- Maak of selecteer een resourcegroep.
- Maak of selecteer een virtueel netwerk en subnet.
- Kies een geschikt implementatietype voor virtuele SAP-machines. Meestal een virtuele-machineschaalset met flexibele indeling.
- Virtuele machine 1 maken.
- Gebruik SLES voor SAP-installatiekopieën in Azure Marketplace.
- Selecteer de schaalset, beschikbaarheidszone of beschikbaarheidsset die u in stap 3 hebt gemaakt.
- Virtuele machine 2 maken.
- Gebruik SLES voor SAP-installatiekopieën in Azure Marketplace.
- Selecteer de schaalset, beschikbaarheidszone of beschikbaarheidsset die in stap 3 is gemaakt (niet dezelfde zone als in stap 4).
- Voeg gegevensschijven toe aan de VM's en controleer vervolgens de aanbeveling van een bestandssysteeminstallatie in het artikel IBM Db2 Azure Virtual Machines DBMS-implementatie voor SAP-werkbelasting.
De IBM Db2 LUW- en SAP-omgeving installeren
Raadpleeg de volgende documentatie voordat u begint met de installatie van een SAP-omgeving op basis van IBM Db2 LUW:
- Azure-documentatie
- SAP-documentatie
- IBM-documentatie
Koppelingen naar deze documentatie vindt u in de inleidende sectie van dit artikel.
Raadpleeg de SAP-installatiehandleidingen over het installeren van netWeaver-toepassingen op IBM Db2 LUW.
U vindt de handleidingen in de SAP Help-portal met behulp van de ZOEKfunctie voor SAP-installatiehandleiding.
U kunt het aantal weergegeven hulplijnen in de portal verminderen door de volgende filters in te stellen:
- Ik wil: 'Een nieuw systeem installeren'
- Mijn database: "IBM Db2 voor Linux, Unix en Windows"
- Aanvullende filters voor SAP NetWeaver-versies, stackconfiguratie of besturingssysteem
Installatiehints voor het instellen van IBM Db2 LUW met HADR
Het primaire IBM Db2 LUW-database-exemplaar instellen:
- Gebruik de optie voor hoge beschikbaarheid of gedistribueerde beschikbaarheid.
- Installeer het SAP ASCS/ERS- en Database-exemplaar.
- Maak een back-up van de zojuist geïnstalleerde database.
Belangrijk
Noteer de databasecommunicatiepoort die is ingesteld tijdens de installatie. Het moet hetzelfde poortnummer zijn voor beide database-exemplaren 
Voer de volgende stappen uit om de stand-bydatabaseserver in te stellen met behulp van de sap-homogene systeemkopieprocedure:
Selecteer de optie Systeemkopiekopie doelsystemen>gedistribueerd database-exemplaar>.>
Als kopieermethode selecteert u Homogeen systeem , zodat u een back-up kunt gebruiken om een back-up te herstellen op het stand-byserverexemplaar.
Wanneer u de afsluitstap bereikt om de database te herstellen voor homogene systeemkopie, sluit u het installatieprogramma af. Herstel de database vanuit een back-up van de primaire host. Alle volgende installatiefasen zijn al uitgevoerd op de primaire databaseserver.
HADR instellen voor IBM Db2.
Notitie
Voor installatie en configuratie die specifiek is voor Azure en Pacemaker: Tijdens de installatieprocedure via SAP Software Provisioning Manager is er een expliciete vraag over hoge beschikbaarheid voor IBM Db2 LUW:
- Selecteer IBM Db2 pureScale niet.
- Selecteer IBM Automation System Automation voor Multiplatforms niet installeren.
- Selecteer geen clusterconfiguratiebestanden genereren.
Wanneer u een SBD-apparaat gebruikt voor Linux Pacemaker, stelt u de volgende Db2 HADR-parameters in:
- HADR-peervensterduur (seconden) (HADR_PEER_WINDOW) = 300
- HADR-time-outwaarde (HADR_TIMEOUT) = 60
Wanneer u een Azure Pacemaker-fencingagent gebruikt, stelt u de volgende parameters in:
- HADR-peervensterduur (seconden) (HADR_PEER_WINDOW) = 900
- HADR-time-outwaarde (HADR_TIMEOUT) = 60
We raden de voorgaande parameters aan op basis van de eerste failover-/overnametests. Het is verplicht dat u test op de juiste functionaliteit van failover en overname met deze parameterinstellingen. Omdat afzonderlijke configuraties kunnen variëren, kunnen de parameters mogelijk worden aangepast.
Belangrijk
Specifiek voor IBM Db2 met HADR-configuratie met normale opstartfunctie: het secundaire of stand-bydatabase-exemplaar moet actief zijn voordat u het primaire database-exemplaar kunt starten.
Voor demonstratiedoeleinden en de procedures die in dit artikel worden beschreven, is de database-SID PTR.
IBM Db2 HADR-controle
Nadat u HADR hebt geconfigureerd en de status PEER en CONNECTED is op de primaire en stand-byknooppunten, voert u de volgende controle uit:
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
Azure Load Balancer configureren
Tijdens de VM-configuratie hebt u de mogelijkheid om een load balancer te maken of te selecteren in de sectie Netwerken. Volg de onderstaande stappen om een standard load balancer in te stellen voor het instellen van een database met hoge beschikbaarheid.
Volg de stappen in Load Balancer maken om een standaard load balancer in te stellen voor een SAP-systeem met hoge beschikbaarheid met behulp van Azure Portal. Houd rekening met de volgende punten tijdens de installatie van de load balancer:
- Front-end-IP-configuratie: maak een front-end-IP-adres. Selecteer dezelfde virtuele netwerk- en subnetnaam als uw virtuele databasemachines.
- Back-endpool: maak een back-endpool en voeg database-VM's toe.
- Regels voor inkomend verkeer: maak een taakverdelingsregel. Volg dezelfde stappen voor beide taakverdelingsregels.
- Front-end-IP-adres: Selecteer een front-end-IP-adres.
- Back-endpool: Selecteer een back-endpool.
- Poorten voor hoge beschikbaarheid: selecteer deze optie.
- Protocol: selecteer TCP.
- Statustest: maak een statustest met de volgende details:
- Protocol: selecteer TCP.
- Poort: bijvoorbeeld 625<instance-no.>.
- Interval: Voer 5 in.
- Testdrempel: voer 2 in.
- Time-out voor inactiviteit (minuten): voer 30 in.
- Zwevend IP-adres inschakelen: selecteer deze optie.
Notitie
De configuratie-eigenschap numberOfProbesvan de statustest, ook wel bekend als drempelwaarde voor beschadigde status in de portal, wordt niet gerespecteerd. Als u het aantal geslaagde of mislukte opeenvolgende tests wilt bepalen, stelt u de eigenschap probeThreshold in op 2. Het is momenteel niet mogelijk om deze eigenschap in te stellen met behulp van Azure Portal, dus gebruik de Azure CLI of de PowerShell-opdracht.
Notitie
Wanneer VM's zonder openbare IP-adressen worden geplaatst in de back-endpool van een intern exemplaar (geen openbaar IP-adres) van Standard Azure Load Balancer, is er geen uitgaande internetverbinding, tenzij er meer configuratie wordt uitgevoerd om routering naar openbare eindpunten toe te staan. Zie Openbare eindpuntconnectiviteit voor VM's met behulp van Azure Standard Load Balancer in scenario's met hoge beschikbaarheid van SAP voor meer informatie over het bereiken van uitgaande connectiviteit.
Belangrijk
Schakel TCP-tijdstempels niet in op Azure-VM's die achter Azure Load Balancer worden geplaatst. Als u TCP-tijdstempels inschakelt, kunnen de statustests mislukken. Stel de parameter in net.ipv4.tcp_timestamps op 0. Zie Statustests van Load Balancer voor meer informatie.
Het Pacemaker-cluster maken
Zie Pacemaker instellen op SUSE Linux Enterprise Server in Azure als u een eenvoudig Pacemaker-cluster voor deze IBM Db2-server wilt maken.
Db2 Pacemaker-configuratie
Wanneer u Pacemaker gebruikt voor automatische failover in het geval van een storing in een knooppunt, moet u uw Db2-exemplaren en Pacemaker dienovereenkomstig configureren. In deze sectie wordt dit type configuratie beschreven.
De volgende items worden voorafgegaan door:
- [A]: Van toepassing op alle knooppunten
- [1]: Alleen van toepassing op knooppunt 1
- [2]: Alleen van toepassing op knooppunt 2
[A] Vereisten voor Pacemaker-configuratie:
- Sluit beide databaseservers af met de databasedatabase2-sid<> van de gebruiker met db2stop.
- Wijzig de shell-omgeving voor db2-sidgebruiker<> in /bin/ksh. We raden u aan om het hulpprogramma Yast te gebruiken.
Pacemaker-configuratie
Belangrijk
Recente tests hebben situaties ontdekt waarin Netcat niet meer reageert op aanvragen vanwege achterstand en de beperking van het verwerken van slechts één verbinding. De netcat-resource luistert niet meer naar de Azure Load Balancer-aanvragen en het zwevende IP-adres is niet meer beschikbaar. Voor bestaande Pacemaker-clusters raden we in het verleden aan netcat te vervangen door socat. Momenteel wordt u aangeraden azure-lb-resourceagent te gebruiken, die deel uitmaakt van pakketresource-agents, met de volgende pakketversievereisten:
- Voor SLES 12 SP4/SP5 moet de versie ten minste resource-agents-4.3.018.a7fb5035-3.30.1 zijn.
- Voor SLES 15/15 SP1 moet de versie ten minste resource-agents-4.3.0184.6ee15eb2-4.13.1 zijn.
Houd er rekening mee dat voor de wijziging korte downtime is vereist.
Als voor bestaande Pacemaker-clusters de configuratie al is gewijzigd om socat te gebruiken, zoals beschreven in Azure Load-Balancer Detection Hardening, hoeft u niet onmiddellijk over te schakelen naar de azure-lb-resourceagent.
[1] IBM Db2 HADR-specifieke Pacemaker-configuratie:
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true[1] IBM Db2-resources maken:
# 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[1] Start IBM Db2-resources:
Pacemaker uit de onderhoudsmodus zetten.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property maintenance-mode=false[1] Zorg ervoor dat de clusterstatus in orde is en of alle resources zijn gestart. Het is niet belangrijk op welk knooppunt de resources worden uitgevoerd.
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 ]
Belangrijk
U moet het Geclusterde Db2-exemplaar van Pacemaker beheren met behulp van Pacemaker-hulpprogramma's. Als u db2-opdrachten zoals db2stop gebruikt, detecteert Pacemaker de actie als een fout in de resource. Als u onderhoud uitvoert, kunt u de knooppunten of resources in de onderhoudsmodus plaatsen. Pacemaker onderbreekt bewakingsbronnen en u kunt vervolgens normale db2-beheeropdrachten gebruiken.
Wijzigingen aanbrengen in SAP-profielen om virtueel IP-adres te gebruiken voor verbinding
Als u verbinding wilt maken met het primaire exemplaar van de HADR-configuratie, moet de SAP-toepassingslaag het virtuele IP-adres gebruiken dat u hebt gedefinieerd en geconfigureerd voor de Azure Load Balancer. De volgende wijzigingen zijn vereist:
/sapmnt/<SID>/profile/DEFAULT. PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/<SID>/global/db6/db2cli.ini
Hostname=db-virt-hostname
Primaire en dialoogvenstertoepassingsservers installeren
Wanneer u primaire en dialoogvenstertoepassingsservers installeert voor een Db2 HADR-configuratie, gebruikt u de naam van de virtuele host die u hebt gekozen voor de configuratie.
Als u de installatie hebt uitgevoerd voordat u de Db2 HADR-configuratie hebt gemaakt, moet u de wijzigingen aanbrengen zoals beschreven in de voorgaande sectie en als volgt voor SAP Java-stacks.
JDBC-URL-controle voor ABAP+Java- of Java-stacksystemen
Gebruik het hulpprogramma J2EE-configuratie om de JDBC-URL te controleren of bij te werken. Omdat het hulpprogramma J2EE Config een grafisch hulpprogramma is, moet u de X-server hebben geïnstalleerd:
Meld u aan bij de primaire toepassingsserver van het J2EE-exemplaar en voer het volgende uit:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shKies in het linkerframe beveiligingsarchief.
Kies in het juiste frame de sleutel jdbc/pool/<SAPSID>/URL.
Wijzig de hostnaam in de JDBC-URL in de naam van de virtuele host.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Selecteer Toevoegen.
Als u de wijzigingen wilt opslaan, selecteert u het schijfpictogram linksboven.
Sluit het configuratieprogramma.
Start het Java-exemplaar opnieuw op.
Logboekarchivering configureren voor HADR-installatie
Als u de db2-logboekarchivering voor HADR-installatie wilt configureren, raden we u aan zowel de primaire als de stand-bydatabase te configureren voor het automatisch ophalen van logboeken vanaf alle archieflocaties voor logboeken. Zowel de primaire als de stand-bydatabase moet logboekarchiefbestanden kunnen ophalen van alle logboekarchieflocaties waarnaar een van de database-exemplaren logboekbestanden kan archiveren.
De logboekarchivering wordt alleen uitgevoerd door de primaire database. Als u de HADR-rollen van de databaseservers wijzigt of als er een fout optreedt, is de nieuwe primaire database verantwoordelijk voor logboekarchivering. Als u meerdere archieflocaties voor logboeken hebt ingesteld, worden uw logboeken mogelijk tweemaal gearchiveerd. In het geval van een lokale of externe inhaalactie moet u mogelijk ook handmatig de gearchiveerde logboeken van de oude primaire server kopiëren naar de actieve logboeklocatie van de nieuwe primaire server.
U wordt aangeraden een gemeenschappelijke NFS-share te configureren waarin logboeken van beide knooppunten worden geschreven. De NFS-share moet maximaal beschikbaar zijn.
U kunt bestaande maximaal beschikbare NFS-shares gebruiken voor transporten of een profielmap. Zie voor meer informatie:
- Hoge beschikbaarheid voor NFS op Azure-VM's op SUSE Linux Enterprise Server.
- Hoge beschikbaarheid voor SAP NetWeaver op Azure-VM's op SUSE Linux Enterprise Server met Azure NetApp Files voor SAP-toepassingen.
- Azure NetApp Files (om NFS-shares te maken).
De clusterinstallatie testen
In deze sectie wordt beschreven hoe u de db2 HADR-installatie kunt testen. Bij elke test wordt ervan uitgegaan dat u bent aangemeld als gebruikershoofdmap en dat de primaire IBM Db2 wordt uitgevoerd op de virtuele machine azibmdb01 .
De initiële status voor alle testcases wordt hier uitgelegd: (crm_mon -r- of crm-status)
- crm-status is een momentopname van de Pacemaker-status tijdens de uitvoering.
- crm_mon -r is continue uitvoer van de Pacemaker-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): 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 ]
De oorspronkelijke status in een SAP-systeem wordt beschreven in Transaction DBACOCKPIT > Configuration > Overview, zoals wordt weergegeven in de volgende afbeelding:
Testovername van IBM Db2
Belangrijk
Voordat u de test start, moet u ervoor zorgen dat:
Pacemaker heeft geen mislukte acties (crm-status).
Er zijn geen locatiebeperkingen (resten van migratietest).
De IBM Db2 HADR-synchronisatie werkt. Controleren met database2-sid<van gebruiker>
db2pd -hadr -db <DBSID>
Migreer het knooppunt waarop de primaire Db2-database wordt uitgevoerd door de volgende opdracht uit te voeren:
crm resource migrate msl_Db2_db2ptr_PTR azibmdb02
Nadat de migratie is voltooid, ziet de crm-statusuitvoer er als volgt uit:
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 ]
De oorspronkelijke status in een SAP-systeem wordt beschreven in Transaction DBACOCKPIT > Configuration > Overview, zoals wordt weergegeven in de volgende afbeelding:
Bij resourcemigratie met 'crm-resourcemigratie' worden locatiebeperkingen gemaakt. Locatiebeperkingen moeten worden verwijderd. Als locatiebeperkingen niet worden verwijderd, kan de resource geen failback uitvoeren of kunt u ongewenste overnames ervaren.
De resource terug migreren naar azibmdb01 en de locatiebeperkingen wissen
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- crm-resource migreren <res_name><host>: locatiebeperkingen maken en problemen met overname kunnen veroorzaken
- crm-resource wissen <res_name>: Locatiebeperkingen wissen
- crm-resource opschonen <res_name>: wist alle fouten van de resource
SBD-fencing testen
In dit geval testen we SBD-fencing, wat we raden u aan te doen wanneer u SUSE Linux gebruikt.
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
Het clusterknooppunt azibmdb01 moet opnieuw worden opgestart. De primaire HADR-rol van IBM Db2 wordt verplaatst naar azibmdb02. Wanneer azibmdb01 weer online is, wordt het Db2-exemplaar verplaatst in de rol van een secundair database-exemplaar.
Als de Pacemaker-service niet automatisch wordt gestart op de opnieuw opgestarte voormalige primaire server, moet u deze handmatig starten met:
sudo service pacemaker start
Een handmatige overname testen
U kunt een handmatige overname testen door de Pacemaker-service te stoppen op het azibmdb01-knooppunt :
service pacemaker stop
status op azibmdb02
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 ]
Na de failover kunt u de service opnieuw starten op azibmdb01.
service pacemaker start
Het Db2-proces beëindigen op het knooppunt waarop de primaire HADR-database wordt uitgevoerd
#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
Het Db2-exemplaar mislukt en Pacemaker rapporteert de volgende status:
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
Pacemaker start het primaire database-exemplaar db2 opnieuw op hetzelfde knooppunt of voert een failover uit naar het knooppunt waarop het secundaire database-exemplaar wordt uitgevoerd en er wordt een fout gerapporteerd.
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
Het Db2-proces beëindigen op het knooppunt waarop het secundaire database-exemplaar wordt uitgevoerd
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Het knooppunt wordt niet vermeld en er is een fout gerapporteerd
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
Het Db2-exemplaar wordt opnieuw opgestart in de secundaire rol die het eerder had toegewezen.
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
Db stoppen via db2stop force op het knooppunt waarop het primaire HADR-database-exemplaar wordt uitgevoerd
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 ]
Als user db2<sid> execute command db2stop force:
azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force
Fout gedetecteerd
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
Het db2 HADR secundaire database-exemplaar is gepromoveerd naar de primaire rol.
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
Crash-VM met opnieuw opstarten op het knooppunt waarop het primaire HADR-database-exemplaar wordt uitgevoerd
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker bevordert het secundaire exemplaar naar de rol van het primaire exemplaar. Het oude primaire exemplaar wordt verplaatst naar de secundaire rol nadat de virtuele machine is hersteld en alle services zijn volledig hersteld nadat de VM opnieuw is opgestart.
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 ]
Crash de VIRTUELE machine waarop het primaire HADR-database-exemplaar wordt uitgevoerd met 'stoppen'
#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger
In dat geval detecteert Pacemaker dat het knooppunt waarop het primaire database-exemplaar wordt uitgevoerd, niet reageert.
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 ]
De volgende stap is om te controleren op een Split brain situatie. Nadat het overlevende knooppunt heeft vastgesteld dat het knooppunt dat het primaire database-exemplaar voor het laatst heeft uitgevoerd, is uitgeschakeld, wordt een failover van resources uitgevoerd.
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 ]
In het geval van een 'stopzetting' van het knooppunt moet het mislukte knooppunt opnieuw worden opgestart via Azure Management-hulpprogramma's (in De Azure-portal, PowerShell of de Azure CLI). Nadat het mislukte knooppunt weer online is, wordt het Db2-exemplaar gestart in de secundaire rol.
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 ]