Hög tillgänglighet för IBM Db2 LUW på virtuella Azure-datorer på Red Hat Enterprise Linux Server
IBM Db2 för Linux, UNIX och Windows (LUW) i hadr-konfiguration (hög tillgänglighet och haveriberedskap) består av en nod som kör en primär databasinstans och minst en nod som kör en sekundär databasinstans. Ändringar i den primära databasinstansen replikeras till en sekundär databasinstans synkront eller asynkront, beroende på din konfiguration.
Kommentar
Den här artikeln innehåller referenser till termer som Microsoft inte längre använder. När dessa villkor tas bort från programvaran tar vi bort dem från den här artikeln.
I den här artikeln beskrivs hur du distribuerar och konfigurerar virtuella Azure-datorer (VM), installerar klusterramverket och installerar IBM Db2 LUW med HADR-konfiguration.
Artikeln beskriver inte hur du installerar och konfigurerar IBM Db2 LUW med INSTALLATION av HADR- eller SAP-programvara. För att hjälpa dig att utföra dessa uppgifter tillhandahåller vi referenser till SAP- och IBM-installationshandböcker. Den här artikeln fokuserar på delar som är specifika för Azure-miljön.
IBM Db2-versionerna som stöds är 10.5 och senare, vilket beskrivs i SAP-1928533.
Innan du påbörjar en installation kan du läsa följande SAP-anteckningar och dokumentation:
| SAP-anteckning | beskrivning |
|---|---|
| 1928533 | SAP-program i Azure: Produkter som stöds och typer av virtuella Azure-datorer |
| 2015553 | SAP på Azure: Supportkrav |
| 2178632 | Viktiga övervakningsmått för SAP i Azure |
| 2191498 | SAP på Linux med Azure: Förbättrad övervakning |
| 2243692 | Virtuell Linux-dator på Azure (IaaS): SAP-licensproblem |
| 2002167 | Red Hat Enterprise Linux 7.x: Installation och uppgradering |
| 2694118 | Red Hat Enterprise Linux HA-tillägg på Azure |
| 1999351 | Felsöka förbättrad Azure-övervakning för SAP |
| 2233094 | DB6: SAP-program i Azure som använder IBM Db2 för Linux, UNIX och Windows – ytterligare information |
| 1612105 | DB6: Vanliga frågor och svar om Db2 med HADR |
Översikt
För att uppnå hög tillgänglighet installeras IBM Db2 LUW med HADR på minst två virtuella Azure-datorer, som distribueras i en VM-skalningsuppsättning med flexibel orkestrering mellan tillgänglighetszoner eller i en tillgänglighetsuppsättning.
Följande grafik visar en konfiguration av två virtuella Azure-datorer på databasservern. Båda de virtuella Azure-datorerna på databasservern har sitt eget lagringsutrymme anslutet och är igång. I HADR har en databasinstans på en av de virtuella Azure-datorerna rollen som den primära instansen. Alla klienter är anslutna till den primära instansen. Alla ändringar i databastransaktioner sparas lokalt i db2-transaktionsloggen. Eftersom transaktionsloggposterna sparas lokalt överförs posterna via TCP/IP till databasinstansen på den andra databasservern, väntelägesservern eller väntelägesinstansen. Standby-instansen uppdaterar den lokala databasen genom att vidarebefordra de överförda transaktionsloggposterna. På så sätt hålls väntelägesservern synkroniserad med den primära servern.
HADR är bara en replikeringsfunktion. Den har ingen felidentifiering och inga automatiska uppköps- eller redundansanläggningar. Ett övertagande eller en överföring till väntelägesservern måste initieras manuellt av en databasadministratör. Om du vill uppnå ett automatiskt övertagande och felidentifiering kan du använda Linux Pacemaker-klustringsfunktionen. Pacemaker övervakar de två databasserverinstanserna. När den primära databasserverinstansen kraschar initierar Pacemaker ett automatiskt HADR-övertagande av väntelägesservern. Pacemaker säkerställer också att den virtuella IP-adressen tilldelas till den nya primära servern.
För att SAP-programservrar ska kunna ansluta till den primära databasen behöver du ett virtuellt värdnamn och en virtuell IP-adress. Efter en redundansväxling ansluter SAP-programservrarna till en ny primär databasinstans. I en Azure-miljö krävs en Azure-lastbalanserare för att använda en virtuell IP-adress på det sätt som krävs för HADR för IBM Db2.
För att hjälpa dig att förstå hur IBM Db2 LUW med HADR och Pacemaker passar in i en SAP-systemkonfiguration med hög tillgänglighet, visar följande bild en översikt över en högtillgänglig installation av ett SAP-system baserat på IBM Db2-databasen. Den här artikeln beskriver endast IBM Db2, men innehåller referenser till andra artiklar om hur du konfigurerar andra komponenter i ett SAP-system.
Översikt på hög nivå över de steg som krävs
Om du vill distribuera en IBM Db2-konfiguration måste du följa dessa steg:
- Planera din miljö.
- Distribuera de virtuella datorerna.
- Uppdatera RHEL Linux och konfigurera filsystem.
- Installera och konfigurera Pacemaker.
- Konfigurera glusterfs-kluster eller Azure NetApp Files
- Installera ASCS/ERS i ett separat kluster.
- Installera IBM Db2-databasen med alternativet Distribuerad/Hög tillgänglighet (SWPM).
- Installera och skapa en sekundär databasnod och instans och konfigurera HADR.
- Bekräfta att HADR fungerar.
- Använd Pacemaker-konfigurationen för att styra IBM Db2.
- Konfigurera Azure Load Balancer.
- Installera primära programservrar och dialogprogramservrar.
- Kontrollera och anpassa konfigurationen av SAP-programservrar.
- Utför redundans- och uppköpstester.
Planera Azure-infrastruktur för att vara värd för IBM Db2 LUW med HADR
Slutför planeringsprocessen innan du kör distributionen. Planering bygger grunden för att distribuera en konfiguration av Db2 med HADR i Azure. Viktiga element som måste ingå i planeringen för IMB Db2 LUW (databasdelen av SAP-miljön) visas i följande tabell:
| Område | Kort beskrivning |
|---|---|
| Definiera Azure-resursgrupper | Resursgrupper där du distribuerar virtuell dator, virtuellt nätverk, Azure Load Balancer och andra resurser. Kan vara befintlig eller ny. |
| Definition av virtuellt nätverk/undernät | Där virtuella datorer för IBM Db2 och Azure Load Balancer distribueras. Kan vara befintlig eller nyskapade. |
| Virtuella datorer som är värdar för IBM Db2 LUW | VM-storlek, lagring, nätverk, IP-adress. |
| Virtuellt värdnamn och virtuell IP-adress för IBM Db2-databas | Den virtuella IP-adressen eller värdnamnet används för anslutning av SAP-programservrar. db-virt-hostname, db-virt-ip. |
| Azure-fäktning | Metod för att undvika delade hjärnsituationer förhindras. |
| Azure Load Balancer | Användning av Standard (rekommenderas), avsökningsport för Db2-databas (vår rekommendation 62500) avsökningsport. |
| Namnmatchning | Så här fungerar namnmatchning i miljön. DNS-tjänsten rekommenderas starkt. Lokala värdfiler kan användas. |
Mer information om Linux Pacemaker i Azure finns i Konfigurera Pacemaker på Red Hat Enterprise Linux i Azure.
Viktigt!
För Db2-versionerna 11.5.6 och senare rekommenderar vi starkt integrerad lösning med pacemaker från IBM.
Distribution på Red Hat Enterprise Linux
Resursagenten för IBM Db2 LUW ingår i Red Hat Enterprise Linux Server HA Addon. För den konfiguration som beskrivs i det här dokumentet bör du använda Red Hat Enterprise Linux för SAP. Azure Marketplace innehåller en avbildning för Red Hat Enterprise Linux 7.4 för SAP eller senare som du kan använda för att distribuera nya virtuella Azure-datorer. Tänk på de olika support- eller tjänstmodeller som erbjuds av Red Hat via Azure Marketplace när du väljer en VM-avbildning på Azure VM Marketplace.
Värdar: DNS-uppdateringar
Skapa en lista över alla värdnamn, inklusive virtuella värdnamn, och uppdatera DNS-servrarna för att aktivera rätt IP-adress för värdnamnsmatchning. Om det inte finns någon DNS-server eller om du inte kan uppdatera och skapa DNS-poster måste du använda de lokala värdfilerna för de enskilda virtuella datorer som deltar i det här scenariot. Om du använder poster för värdfiler kontrollerar du att posterna tillämpas på alla virtuella datorer i SAP-systemmiljön. Vi rekommenderar dock att du använder din DNS som helst utökas till Azure
Manuell distribution
Kontrollera att det valda operativsystemet stöds av IBM/SAP för IBM Db2 LUW. Listan över operativsystemversioner som stöds för virtuella Azure-datorer och Db2-versioner finns i SAP-1928533. Listan över OS-versioner av enskilda Db2-versioner är tillgänglig i SAP-produkttillgänglighetsmatrisen. Vi rekommenderar starkt ett minimum av Red Hat Enterprise Linux 7.4 för SAP på grund av Azure-relaterade prestandaförbättringar i den här eller senare Red Hat Enterprise Linux-versioner.
- Skapa eller välj en resursgrupp.
- Skapa eller välj ett virtuellt nätverk och undernät.
- Välj en lämplig distributionstyp för virtuella SAP-datorer. Vanligtvis en VM-skalningsuppsättning med flexibel orkestrering.
- Skapa virtuell dator 1.
- Använd Red Hat Enterprise Linux för SAP-avbildning på Azure Marketplace.
- Välj skalningsuppsättningen, tillgänglighetszonen eller tillgänglighetsuppsättningen som skapades i steg 3.
- Skapa virtuell dator 2.
- Använd Red Hat Enterprise Linux för SAP-avbildning på Azure Marketplace.
- Välj skalningsuppsättningen, tillgänglighetszonen eller tillgänglighetsuppsättningen som skapades i steg 3 (inte samma zon som i steg 4).
- Lägg till datadiskar till de virtuella datorerna och kontrollera sedan rekommendationen för en filsystemkonfiguration i artikeln IBM Db2 Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning.
Installera IBM Db2 LUW- och SAP-miljön
Innan du påbörjar installationen av en SAP-miljö baserad på IBM Db2 LUW läser du följande dokumentation:
- Azure-dokumentation.
- SAP-dokumentation.
- IBM-dokumentation.
Länkar till den här dokumentationen finns i introduktionsavsnittet i den här artikeln.
Kontrollera SAP-installationshandböckerna om hur du installerar NetWeaver-baserade program på IBM Db2 LUW. Du hittar guiderna på SAP-hjälpportalen med hjälp av SAP-installationsguiden Finder.
Du kan minska antalet guider som visas i portalen genom att ange följande filter:
- Jag vill: Installera ett nytt system.
- Min databas: IBM Db2 för Linux, Unix och Windows.
- Ytterligare filter för SAP NetWeaver-versioner, stackkonfiguration eller operativsystem.
Red Hat-brandväggsregler
Red Hat Enterprise Linux har brandvägg aktiverat som standard.
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
Installationstips för att konfigurera IBM Db2 LUW med HADR
Så här konfigurerar du den primära IBM Db2 LUW-databasinstansen:
- Använd alternativet hög tillgänglighet eller distribuerad.
- Installera SAP ASCS/ERS- och Database-instansen.
- Gör en säkerhetskopia av den nyligen installerade databasen.
Viktigt!
Skriv ned den databaskommunikationsport som anges under installationen. Det måste vara samma portnummer för båda databasinstanserna.
IBM Db2 HADR-inställningar för Azure
När du använder en Azure Pacemaker-fäktningsagent anger du följande parametrar:
- VARAKTIGHET för HADR-peerfönster (sekunder) (HADR_PEER_WINDOW) = 240
- HADR-timeoutvärde (HADR_TIMEOUT) = 45
Vi rekommenderar föregående parametrar baserat på inledande redundans-/uppköpstestning. Det är obligatoriskt att du testar för korrekt funktionalitet för redundans och övertagande med dessa parameterinställningar. Eftersom enskilda konfigurationer kan variera kan parametrarna kräva justering.
Kommentar
Specifikt för IBM Db2 med HADR-konfiguration med normal start: Den sekundära eller väntelägesdatabasinstansen måste vara igång innan du kan starta den primära databasinstansen.
Kommentar
För installation och konfiguration som är specifik för Azure och Pacemaker: Under installationsproceduren via SAP Software Provisioning Manager finns det en uttrycklig fråga om hög tillgänglighet för IBM Db2 LUW:
- Välj inte IBM Db2 pureScale.
- Välj inte Installera IBM Tivoli System Automation för multiplatforms.
- Välj inte Generera klusterkonfigurationsfiler.
Utför följande steg för att konfigurera väntelägesdatabasservern med hjälp av sap homogen systemkopieringsprocedur:
- Välj alternativet >Systemkopiering Målsystem>Distribuerad>databasinstans.
- Som kopieringsmetod väljer du Homogent system så att du kan använda säkerhetskopiering för att återställa en säkerhetskopia på väntelägesserverinstansen.
- När du når avslutssteget för att återställa databasen för homogen systemkopiering avslutar du installationsprogrammet. Återställ databasen från en säkerhetskopia av den primära värden. Alla efterföljande installationsfaser har redan körts på den primära databasservern.
Red Hat-brandväggsregler för DB2 HADR
Lägg till brandväggsregler för att tillåta trafik till DB2 och mellan DB2 för HADR att fungera:
- Databaskommunikationsport. Om du använder partitioner lägger du också till dessa portar.
- HADR-port (värdet för DB2-parametern HADR_LOCAL_SVC).
- Azure-avsökningsport.
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
IBM Db2 HADR-kontroll
I demonstrationssyfte och de procedurer som beskrivs i den här artikeln är databas-SID ID2.
När du har konfigurerat HADR och statusen är PEER och ANSLUTEN på de primära noderna och väntelägesnoderna utför du följande kontroll:
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
Konfigurera Azure Load Balancer
Under konfigurationen av den virtuella datorn kan du skapa eller välja att avsluta lastbalanseraren i nätverksavsnittet. Följ stegen nedan om du vill konfigurera standardlastbalanserare för installation av DB2-databas med hög tillgänglighet.
Följ stegen i Skapa lastbalanserare för att konfigurera en standardlastbalanserare för ett SAP-system med hög tillgänglighet med hjälp av Azure-portalen. Tänk på följande under installationen av lastbalanseraren:
- IP-konfiguration för klientdelen: Skapa en klientdels-IP-adress. Välj samma virtuella nätverk och undernätsnamn som dina virtuella databasdatorer.
- Serverdelspool: Skapa en serverdelspool och lägg till virtuella databasdatorer.
- Regler för inkommande trafik: Skapa en belastningsutjämningsregel. Följ samma steg för båda belastningsutjämningsreglerna.
- Klientdels-IP-adress: Välj en klientdels-IP-adress.
- Serverdelspool: Välj en serverdelspool.
- Portar med hög tillgänglighet: Välj det här alternativet.
- Protokoll: Välj TCP.
- Hälsoavsökning: Skapa en hälsoavsökning med följande information:
- Protokoll: Välj TCP.
- Port: Till exempel 625<instans-no.>.
- Intervall: Ange 5.
- Tröskelvärde för avsökning: Ange 2.
- Tidsgräns för inaktivitet (minuter): Ange 30.
- Aktivera flytande IP: Välj det här alternativet.
Kommentar
Konfigurationsegenskapen numberOfProbesför hälsoavsökningen , även kallad Tröskelvärde för fel i portalen, respekteras inte. Om du vill kontrollera antalet lyckade eller misslyckade efterföljande avsökningar anger du egenskapen probeThreshold till 2. Det går för närvarande inte att ange den här egenskapen med hjälp av Azure-portalen, så använd antingen Azure CLI eller PowerShell-kommandot .
Viktigt!
Flytande IP stöds inte på en sekundär IP-konfiguration för nätverkskort i belastningsutjämningsscenarier. Mer information finns i Begränsningar för Azure Load Balancer. Om du behöver en annan IP-adress för den virtuella datorn distribuerar du ett andra nätverkskort.
Kommentar
När virtuella datorer utan offentliga IP-adresser placeras i serverdelspoolen för en intern (ingen offentlig IP-adress) instans av Standard Azure Load Balancer, finns det ingen utgående Internetanslutning om inte mer konfiguration utförs för att tillåta routning till offentliga slutpunkter. Mer information om hur du uppnår utgående anslutning finns i Offentlig slutpunktsanslutning för virtuella datorer som använder Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet.
Viktigt!
Aktivera inte TCP-tidsstämplar på virtuella Azure-datorer som placeras bakom Azure Load Balancer. Om du aktiverar TCP-tidsstämplar kan hälsoavsökningarna misslyckas. Ange parametern net.ipv4.tcp_timestamps till 0. Mer information finns i Load Balancer-hälsoavsökningar.
[A] Lägg till brandväggsregel för avsökningsport:
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
Skapa Pacemaker-klustret
Information om hur du skapar ett grundläggande Pacemaker-kluster för den här IBM Db2-servern finns i Konfigurera Pacemaker på Red Hat Enterprise Linux i Azure.
Db2 Pacemaker-konfiguration
När du använder Pacemaker för automatisk redundans vid ett nodfel måste du konfigurera dina Db2-instanser och Pacemaker i enlighet med detta. I det här avsnittet beskrivs den här typen av konfiguration.
Följande objekt är prefix med antingen:
- [A]: Gäller för alla noder
- [1]: Gäller endast för nod 1
- [2]: Gäller endast för nod 2
[A] Krav för pacemakerkonfiguration:
Stäng av båda databasservrarna med user db2<sid> med db2stop.
Ändra shell-miljön för db2-sidanvändaren<> till /bin/ksh:
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Pacemakerkonfiguration
[1] IBM Db2 HADR-specifik Pacemaker-konfiguration:
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[1] Skapa IBM Db2-resurser:
Om du skapar ett kluster på RHEL 7.x måste du uppdatera paketresursagenter till version
resource-agents-4.1.1-61.el7_9.15eller högre. Använd följande kommandon för att skapa klusterresurserna:# 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_ID2Om du skapar ett kluster på RHEL 8.x måste du uppdatera paketresursagenter till version
resource-agents-4.1.1-93.el8eller högre. Mer information finns i Red Hat KBA-resursdb2med HADR misslyckas med att höja upp med tillståndetPRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. Använd följande kommandon för att skapa klusterresurserna:# 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] Starta IBM Db2-resurser:
Sätt pacemakern ur underhållsläge.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo pcs property set maintenance-mode=false[1] Kontrollera att klusterstatusen är OK och att alla resurser har startats. Det är inte viktigt vilken nod resurserna körs på.
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
Viktigt!
Du måste hantera Pacemaker-klustrad Db2-instans med hjälp av Pacemaker-verktyg. Om du använder db2-kommandon som db2stop identifierar Pacemaker åtgärden som ett resursfel. Om du utför underhåll kan du placera noderna eller resurserna i underhållsläge. Pacemaker pausar övervakningsresurser och du kan sedan använda vanliga db2-administrationskommandon.
Göra ändringar i SAP-profiler för att använda virtuell IP-adress för anslutning
För att ansluta till den primära instansen av HADR-konfigurationen måste SAP-programlagret använda den virtuella IP-adress som du har definierat och konfigurerat för Azure Load Balancer. Följande ändringar krävs:
/sapmnt/<SID>/profile/DEFAULT. PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/<SID>/global/db6/db2cli.ini
Hostname=db-virt-hostname
Installera primära programservrar och dialogprogramservrar
När du installerar primära programservrar och dialogprogramservrar mot en DB2 HADR-konfiguration använder du det virtuella värdnamnet som du valde för konfigurationen.
Om du utförde installationen innan du skapade DB2 HADR-konfigurationen gör du ändringarna enligt beskrivningen i föregående avsnitt och på följande sätt för SAP Java-stackar.
JDBC-URL-kontroll för ABAP+Java- eller Java-stacksystem
Använd J2EE Config-verktyget för att kontrollera eller uppdatera JDBC-URL:en. Eftersom J2EE Config-verktyget är ett grafiskt verktyg måste du ha X-servern installerad:
Logga in på den primära programservern för J2EE-instansen och kör:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shI den vänstra ramen väljer du Säkerhetsarkiv.
I den högra ramen väljer du nyckeln
jdbc/pool/\<SAPSID>/url.Ändra värdnamnet i JDBC-URL:en till det virtuella värdnamnet.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Markera Lägga till.
Spara ändringarna genom att välja diskikonen längst upp till vänster.
Stäng konfigurationsverktyget.
Starta om Java-instansen.
Konfigurera loggarkivering för HADR-konfiguration
För att konfigurera Db2-loggarkivering för HADR-installation rekommenderar vi att du konfigurerar både den primära databasen och väntelägesdatabasen så att den har automatisk logghämtningsfunktion från alla loggarkivplatser. Både den primära databasen och väntelägesdatabasen måste kunna hämta loggarkivfiler från alla loggarkivplatser som någon av databasinstanserna kan arkivera loggfiler till.
Loggarkiveringen utförs endast av den primära databasen. Om du ändrar HADR-rollerna för databasservrarna eller om ett fel inträffar ansvarar den nya primära databasen för loggarkivering. Om du har konfigurerat flera loggarkivplatser kan dina loggar arkiveras två gånger. I händelse av en lokal eller fjärranslutning kan du också behöva kopiera de arkiverade loggarna manuellt från den gamla primära servern till den nya primära serverns aktiva loggplats.
Vi rekommenderar att du konfigurerar en vanlig NFS-resurs eller GlusterFS, där loggar skrivs från båda noderna. NFS-resursen eller GlusterFS måste ha hög tillgänglighet.
Du kan använda befintliga NFS-resurser med hög tillgänglighet eller GlusterFS för transporter eller en profilkatalog. Mer information finns i:
- GlusterFS på virtuella Azure-datorer på Red Hat Enterprise Linux för SAP NetWeaver.
- Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer i Red Hat Enterprise Linux med Azure NetApp Files för SAP-program.
- Azure NetApp Files (för att skapa NFS-resurser).
Testa klusterkonfigurationen
I det här avsnittet beskrivs hur du kan testa din DB2 HADR-konfiguration. Varje test förutsätter att IBM Db2-primär körs på den virtuella datorn az-idb01 . Användare med sudo-privilegier eller rot (rekommenderas inte) måste användas.
Den inledande statusen för alla testfall förklaras här: (crm_mon -r eller pcs status)
- pcs-status är en ögonblicksbild av Pacemaker-status vid körning.
- crm_mon -r är kontinuerliga utdata av pacemakerstatus.
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
Den ursprungliga statusen i ett SAP-system dokumenteras i Översikt över transaktions-DBACOCKPIT-konfiguration >> , som du ser i följande bild:
Testa övertagandet av IBM Db2
Viktigt!
Innan du börjar testet kontrollerar du att:
Pacemaker har inga misslyckade åtgärder (pcs-status).
Det finns inga platsbegränsningar (rester av migreringstestet).
IBM Db2 HADR-synkroniseringen fungerar. Kontrollera med användaren db2<sid>.
db2pd -hadr -db <DBSID>
Migrera noden som kör den primära Db2-databasen genom att köra följande kommando:
# 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
När migreringen är klar ser crm-statusutdata ut så här:
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
Den ursprungliga statusen i ett SAP-system dokumenteras i Översikt över transaktions-DBACOCKPIT-konfiguration >> , som du ser i följande bild:
Resursmigrering med "pcs resource move" skapar platsbegränsningar. Platsbegränsningar i det här fallet förhindrar att IBM Db2-instansen körs på az-idb01. Om platsbegränsningar inte tas bort kan resursen inte återställas.
Ta bort platsbegränsningen och väntelägesnoden startas på 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
Och klusterstatusen ändras till:
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
Migrera resursen tillbaka till az-idb01 och rensa platsbegränsningarna
# 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
- På RHEL 7.x –
pcs resource move <resource_name> <host>: Skapar platsbegränsningar och kan orsaka problem med övertagande - På RHEL 8.x –
pcs resource move <resource_name> --master: Skapar platsbegränsningar och kan orsaka problem med övertagande pcs resource clear <resource_name>: Rensar platsbegränsningarpcs resource cleanup <resource_name>: Rensar alla fel i resursen
Testa ett manuellt övertagande
Du kan testa ett manuellt övertagande genom att stoppa Pacemaker-tjänsten på noden az-idb01 :
systemctl stop pacemaker
status på 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
Efter redundansväxlingen kan du starta tjänsten igen på az-idb01.
systemctl start pacemaker
Avsluta Db2-processen på noden som kör DEN primära HADR-databasen
#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
Db2-instansen kommer att misslyckas och Pacemaker flyttar huvudnoden och rapporterar följande 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 startar om den primära Db2-databasinstansen på samma nod, eller så redundansväxlar den över till noden som kör den sekundära databasinstansen och ett fel rapporteras.
Avsluta Db2-processen på noden som kör den sekundära databasinstansen
[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
Noden hamnar i fel angivet och fel rapporteras.
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
Db2-instansen startas om i den sekundära roll som den hade tilldelats tidigare.
Stoppa DB via db2stop force på noden som kör den primära HADR-databasinstansen
När användaren db2<sid> kör kommandot db2stop force:
az-idb01:db2ptr> db2stop force
Fel har identifierats:
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
Db2 HADR-instansen för den sekundära databasen befordrades till den primära rollen.
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
Krascha den virtuella dator som kör den primära HADR-databasinstansen med "stopp"
#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger
I så fall identifierar Pacemaker att noden som kör den primära databasinstansen inte svarar.
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
Nästa steg är att söka efter en delad hjärnsituation . När den överlevande noden har fastställt att noden som senast körde den primära databasinstansen är nere körs en redundansväxling av resurser.
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
I händelse av en kernel-panik startas den misslyckade noden om av fäktningsagenten. När den misslyckade noden är online igen måste du starta pacemakerklustret genom att
sudo pcs cluster start
den startar Db2-instansen till den sekundära rollen.
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