Hög tillgänglighet för IBM Db2 LUW på virtuella Azure-datorer på SUSE Linux Enterprise Server med Pacemaker
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 |
| 1984787 | SUSE LINUX Enterprise Server 12: Installationsanteckningar |
| 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 här 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 SUSE Linux och konfigurera filsystem.
- Installera och konfigurera Pacemaker.
- Installera NFS med hög tillgänglighet.
- 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 som används för anslutning av SAP-programservrar. db-virt-hostname, db-virt-ip. |
| Azure-fäktning | Azure-fäktning eller SBD-fäktning (rekommenderas starkt). Metod för att undvika kluvna hjärnsituationer. |
| Virtuell SBD-dator | Storlek på virtuella SBD-datorer, lagring, nätverk. |
| 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å SUSE Linux Enterprise Server i Azure.
Viktigt!
För Db2-versionerna 11.5.6 och senare rekommenderar vi starkt integrerad lösning med pacemaker från IBM.
Distribution i SUSE Linux
Resursagenten för IBM Db2 LUW ingår i SUSE Linux Enterprise Server för SAP-program. För den konfiguration som beskrivs i det här dokumentet måste du använda SUSE Linux Server för SAP-program. Azure Marketplace innehåller en avbildning för SUSE Enterprise Server för SAP-program 12 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 SUSE 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 minst SLES 12 SP4 på grund av Azure-relaterade prestandaförbättringar i den här eller senare SUSE 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 SLES 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 SLES 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
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 
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.
Konfigurera HADR för IBM Db2.
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.
När du använder en SBD-enhet för Linux Pacemaker anger du följande DB2 HADR-parametrar:
- VARAKTIGHET för HADR-peerfönster (sekunder) (HADR_PEER_WINDOW) = 300
- HADR-timeoutvärde (HADR_TIMEOUT) = 60
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) = 900
- HADR-timeoutvärde (HADR_TIMEOUT) = 60
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.
Viktigt!
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.
I demonstrationssyfte och de procedurer som beskrivs i den här artikeln är databas-SID PTR.
IBM Db2 HADR-kontroll
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 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
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.
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å SUSE Linux Enterprise Server 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] Förutsättningar för pacemakerkonfiguration:
- Stäng av båda databasservrarna med user db2<sid> med db2stop.
- Ändra gränssnittsmiljön för db2-sidanvändaren<> till /bin/ksh. Vi rekommenderar att du använder Yast-verktyget.
Pacemakerkonfiguration
Viktigt!
Nyligen genomförda tester visade situationer där netcat slutar svara på begäranden på grund av kvarvarande uppgifter och dess begränsning av att endast hantera en anslutning. Netcat-resursen slutar lyssna på Azure Load balancer-begäranden och den flytande IP-adressen blir otillgänglig. För befintliga Pacemaker-kluster rekommenderar vi tidigare att netcat ersätts med socat. För närvarande rekommenderar vi att du använder azure-lb-resursagenten, som ingår i paketresursagenter, med följande krav på paketversion:
- För SLES 12 SP4/SP5 måste versionen vara minst resource-agents-4.3.018.a7fb5035-3.30.1.
- För SLES 15/15 SP1 måste versionen vara minst resource-agents-4.3.0184.6ee15eb2-4.13.1.
Observera att ändringen kräver kort stilleståndstid.
För befintliga Pacemaker-kluster, om konfigurationen redan har ändrats för att använda socat enligt beskrivningen i Azure Load-Balancer Detection Hardening, finns det inget krav på att omedelbart växla till azure-lb-resursagenten.
[1] IBM Db2 HADR-specifik Pacemaker-konfiguration:
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true[1] Skapa IBM Db2-resurser:
# 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] Starta IBM Db2-resurser:
Sätt pacemakern ur underhållsläge.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property 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 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 ]
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 där loggar skrivs från båda noderna. NFS-resursen måste vara mycket tillgänglig.
Du kan använda befintliga NFS-resurser med hög tillgänglighet för transporter eller en profilkatalog. Mer information finns i:
- Hög tillgänglighet för NFS på virtuella Azure-datorer på SUSE Linux Enterprise Server.
- Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer på SUSE Linux Enterprise Server 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 du är inloggad som användarrot och att IBM Db2-primära körs på den virtuella datorn azibmdb01 .
Den inledande statusen för alla testfall förklaras här: (crm_mon -r- eller crm-status)
- crm-status är en ögonblicksbild av pacemakerstatus vid körning.
- crm_mon -r är kontinuerliga utdata av pacemakerstatus.
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 ]
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 (crm-status).
Det finns inga platsbegränsningar (rester av migreringstestet.
IBM Db2 HADR-synkroniseringen fungerar. Kontrollera med user db2<sid>
db2pd -hadr -db <DBSID>
Migrera noden som kör den primära Db2-databasen genom att köra följande kommando:
crm resource migrate msl_Db2_db2ptr_PTR azibmdb02
När migreringen är klar ser crm-statusutdata ut så här:
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 ]
Den ursprungliga statusen i ett SAP-system dokumenteras i Översikt över transaktions-DBACOCKPIT-konfiguration >> , som du ser i följande bild:
Resursmigrering med "crm resource migrate" skapar platsbegränsningar. Platsbegränsningar bör tas bort. Om platsbegränsningar inte tas bort kan resursen inte återställas eller så kan du uppleva oönskade uppköp.
Migrera resursen tillbaka till azibmdb01 och rensa platsbegränsningarna
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- crm-resursmigrering <res_name><värd>: Skapar platsbegränsningar och kan orsaka problem med övertagande
- crm resource clear <res_name>: Rensar platsbegränsningar
- crm-resursrensning <res_name>: Rensar alla fel i resursen
Testa SBD-fäktning
I det här fallet testar vi SBD-fäktning, vilket vi rekommenderar att du gör när du använder SUSE Linux.
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
Klusternoden azibmdb01 bör startas om. Den primära HADR-rollen för IBM Db2 kommer att flyttas till azibmdb02. När azibmdb01 är online igen flyttas Db2-instansen i rollen som en sekundär databasinstans.
Om Pacemaker-tjänsten inte startas automatiskt på den omstartade tidigare primära ska du starta den manuellt med:
sudo service pacemaker start
Testa ett manuellt övertagande
Du kan testa ett manuellt övertagande genom att stoppa Pacemaker-tjänsten på noden azibmdb01 :
service pacemaker stop
status på 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 ]
Efter redundansväxlingen kan du starta tjänsten igen på azibmdb01.
service pacemaker start
Avsluta Db2-processen på noden som kör DEN primära HADR-databasen
#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
Db2-instansen misslyckas och Pacemaker rapporterar följande 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 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.
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
Avsluta Db2-processen på noden som kör den sekundära databasinstansen
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Noden hamnar i fel angivet och fel rapporteras
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
Db2-instansen startas om i den sekundära roll som den hade tilldelats tidigare.
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
Stoppa DB via db2stop force på noden som kör den primära HADR-databasinstansen
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 ]
När användaren db2<sid> kör kommandot db2stop force:
azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force
Fel har identifierats
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
Db2 HADR-instansen för den sekundära databasen befordrades till den primära rollen.
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
Krasch-VM med omstart på noden som kör den primära HADR-databasinstansen
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker befordrar den sekundära instansen till den primära instansrollen. Den gamla primära instansen flyttas till den sekundära rollen efter att den virtuella datorn och alla tjänster har återställts helt efter omstarten av den virtuella datorn.
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 ]
Krascha den virtuella dator som kör den primära HADR-databasinstansen med "stopp"
#Linux kernel panic - halts OS
azibmdb01:~ # 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 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 ]
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: [ 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 ]
Om noden "stoppas" måste den misslyckade noden startas om via Azure Management-verktyg (i Azure-portalen, PowerShell eller Azure CLI). När den misslyckade noden är online igen startar den Db2-instansen till den sekundära rollen.
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 ]