Hoge beschikbaarheid van IBM Db2 LUW in Azure-VM's in Red Hat Enterprise Linux Server
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 |
| 2002167 | Red Hat Enterprise Linux 7.x: installatie en upgrade |
| 2694118 | Red Hat Enterprise Linux HA-invoegtoepassing in Azure |
| 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 het 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 RHEL Linux bij en configureer bestandssystemen.
- Pacemaker installeren en configureren.
- Glusterfs-cluster of Azure NetApp Files instellen
- 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 | De virtuele IP- of hostnaam wordt gebruikt voor de verbinding van SAP-toepassingsservers. db-virt-hostname, db-virt-ip. |
| Azure-fencing | Methode om gesplitste hersensituaties te voorkomen, wordt voorkomen. |
| 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 Red Hat Enterprise Linux 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 Red Hat Enterprise Linux
De resourceagent voor IBM Db2 LUW is opgenomen in de Red Hat Enterprise Linux Server HA-invoegtoepassing. Voor de installatie die in dit document wordt beschreven, moet u Red Hat Enterprise Linux voor SAP gebruiken. Azure Marketplace bevat een installatiekopie voor Red Hat Enterprise Linux 7.4 voor SAP of hoger die u kunt gebruiken om nieuwe virtuele Azure-machines te implementeren. Houd rekening met de verschillende ondersteunings- of servicemodellen die door Red Hat worden aangeboden via Azure Marketplace wanneer u een VM-installatiekopie 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 Red Hat Enterprise Linux 7.4 voor SAP te gebruiken vanwege prestatieverbeteringen in deze of latere Red Hat Enterprise 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 Red Hat Enterprise Linux voor SAP-installatiekopie in Azure Marketplace.
- Selecteer de schaalset, beschikbaarheidszone of beschikbaarheidsset die u in stap 3 hebt gemaakt.
- Virtuele machine 2 maken.
- Gebruik Red Hat Enterprise Linux voor SAP-installatiekopie 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:
- Documentatie voor Azure.
- 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.
Red Hat-firewallregels
Red Hat Enterprise Linux heeft standaard firewall ingeschakeld.
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
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.
IBM Db2 HADR-instellingen voor Azure
Wanneer u een Azure Pacemaker-fencingagent gebruikt, stelt u de volgende parameters in:
- HADR-peervensterduur (seconden) (HADR_PEER_WINDOW) = 240
- HADR-time-outwaarde (HADR_TIMEOUT) = 45
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.
Notitie
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.
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.
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.
Red Hat-firewallregels voor DB2 HADR
Voeg firewallregels toe om verkeer naar DB2 en tussen DB2 voor HADR te laten werken:
- Poort voor databasecommunicatie. Als u partities gebruikt, voegt u deze poorten ook toe.
- HADR-poort (waarde van DB2-parameter HADR_LOCAL_SVC).
- Azure-testpoort.
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
IBM Db2 HADR-controle
Voor demonstratiedoeleinden en de procedures die in dit artikel worden beschreven, is de database-SID ID2.
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 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
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.
[A] Firewallregel toevoegen voor testpoort:
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
Het Pacemaker-cluster maken
Zie Pacemaker instellen op Red Hat Enterprise Linux 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] Vereiste 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:
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Pacemaker-configuratie
[1] IBM Db2 HADR-specifieke Pacemaker-configuratie:
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[1] IBM Db2-resources maken:
Als u een cluster bouwt op RHEL 7.x, moet u pakketresourceagents bijwerken naar versie
resource-agents-4.1.1-61.el7_9.15of hoger. Gebruik de volgende opdrachten om de clusterbronnen te maken:# 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_ID2Als u een cluster op RHEL 8.x bouwt, moet u pakketresourceagents bijwerken naar versie
resource-agents-4.1.1-93.el8of hoger. Zie Red Hat KBA-resourcedb2met HADR mislukt voor meer informatie.PRIMARY/REMOTE_CATCHUP_PENDING/CONNECTEDGebruik de volgende opdrachten om de clusterbronnen te maken:# 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[1] Start IBM Db2-resources:
Pacemaker uit de onderhoudsmodus zetten.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo pcs property set 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 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
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 op basis van 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 of GlusterFS te configureren, waarbij logboeken van beide knooppunten worden geschreven. De NFS-share of GlusterFS moet maximaal beschikbaar zijn.
U kunt bestaande maximaal beschikbare NFS-shares of GlusterFS gebruiken voor transporten of een profielmap. Zie voor meer informatie:
- GlusterFS op Virtuele Azure-machines in Red Hat Enterprise Linux voor SAP NetWeaver.
- Hoge beschikbaarheid voor SAP NetWeaver op Azure-VM's in Red Hat Enterprise Linux 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 IBM Db2 primary wordt uitgevoerd op de virtuele machine az-idb01 . Gebruiker met sudo-bevoegdheden of root (niet aanbevolen) moet worden gebruikt.
De initiële status voor alle testcases wordt hier uitgelegd: (crm_mon -r- of pcs-status)
- Pcs-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: [ 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
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 (pcs-status).
Er zijn geen locatiebeperkingen (resten van migratietest).
De IBM Db2 HADR-synchronisatie werkt. Neem contact op met de database2-sid<> van de gebruiker.
db2pd -hadr -db <DBSID>
Migreer het knooppunt waarop de primaire Db2-database wordt uitgevoerd door de volgende opdracht uit te voeren:
# 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
Nadat de migratie is voltooid, ziet de crm-statusuitvoer er als volgt uit:
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
De oorspronkelijke status in een SAP-systeem wordt beschreven in Transaction DBACOCKPIT > Configuration > Overview, zoals wordt weergegeven in de volgende afbeelding:
Bij resourcemigratie met 'pcs-resource verplaatsen' worden locatiebeperkingen gemaakt. Locatiebeperkingen in dit geval verhinderen het uitvoeren van IBM Db2-exemplaar op az-idb01. Als locatiebeperkingen niet worden verwijderd, kan de resource geen failback uitvoeren.
Verwijder de locatiebeperking en het stand-byknooppunt worden gestart op az-idb01.
# On RHEL 7.x
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource clear Db2_HADR_ID2-clone
En de status van het cluster wordt gewijzigd in:
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
De resource terug migreren naar az-idb01 en de locatiebeperkingen wissen
# 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
- Op RHEL 7.x :
pcs resource move <resource_name> <host>Hiermee worden locatiebeperkingen gemaakt en kunnen problemen met overname worden veroorzaakt - Op RHEL 8.x :
pcs resource move <resource_name> --masterHiermee worden locatiebeperkingen gemaakt en kunnen problemen met overname worden veroorzaakt pcs resource clear <resource_name>: Hiermee worden locatiebeperkingen gewistpcs resource cleanup <resource_name>: wist alle fouten van de resource
Een handmatige overname testen
U kunt een handmatige overname testen door de Pacemaker-service te stoppen op az-idb01 node:
systemctl stop pacemaker
status op az-ibdb02
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
Na de failover kunt u de service opnieuw starten op az-idb01.
systemctl start pacemaker
Het Db2-proces beëindigen op het knooppunt waarop de primaire HADR-database wordt uitgevoerd
#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
Het Db2-exemplaar mislukt en Pacemaker verplaatst het hoofdknooppunt en rapporteert de volgende 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-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
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.
Het Db2-proces beëindigen op het knooppunt waarop het secundaire database-exemplaar wordt uitgevoerd
[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
Het knooppunt wordt mislukt vermeld en er is een fout gerapporteerd.
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
Het Db2-exemplaar wordt opnieuw opgestart in de secundaire rol die het eerder had toegewezen.
Db stoppen via db2stop force op het knooppunt waarop het primaire HADR-database-exemplaar wordt uitgevoerd
Als user db2<sid> execute command db2stop force:
az-idb01:db2ptr> db2stop force
Fout gedetecteerd:
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
Het db2 HADR secundaire database-exemplaar is gepromoveerd naar de primaire rol.
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
Crash de VIRTUELE machine waarop het primaire HADR-database-exemplaar wordt uitgevoerd met 'stoppen'
#Linux kernel panic.
sudo 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 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
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: [ 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
In het geval van een kernel-paniek wordt het mislukte knooppunt opnieuw opgestart door de fencing-agent. Nadat het mislukte knooppunt weer online is, moet u het pacemaker-cluster starten door
sudo pcs cluster start
hiermee wordt het Db2-exemplaar gestart in de secundaire rol.
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