Vysoká dostupnost IBM DB2 LUW ve virtuálních počítačích Azure na linuxovém serveru Red Hat Enterprise
IBM Db2 pro Linux, systém UNIX a Windows (LUW) v konfiguraci s vysokou dostupností a zotavením po havárii (HADR) se skládá z jednoho uzlu, na kterém běží primární instance databáze, aspoň jednoho uzlu, na kterém běží sekundární instance databáze. Změny primární instance databáze se replikují do sekundární instance databáze synchronně nebo asynchronně v závislosti na vaší konfiguraci.
Poznámka:
Tento článek obsahuje odkazy na termíny, které už Microsoft nepoužívá. Když se tyto podmínky odeberou ze softwaru, odebereme je z tohoto článku.
Tento článek popisuje, jak nasadit a nakonfigurovat virtuální počítače Azure, nainstalovat architekturu clusteru a nainstalovat IBM Db2 LUW s konfigurací HADR.
Článek se nezabývá instalací a konfigurací LUW IBM Db2 pomocí HADR nebo instalace softwaru SAP. Abychom vám pomohli s těmito úlohami, poskytujeme odkazy na příručky k instalaci SAP a IBM. Tento článek se zaměřuje na části specifické pro prostředí Azure.
Podporované verze IBM Db2 jsou 10.5 a novější, jak je uvedeno v poznámkách SAP 1928533.
Než začnete s instalací, projděte si následující poznámky a dokumentaci k SAP:
| POZNÁMKA K SAP | Popis |
|---|---|
| 1928533 | Aplikace SAP v Azure: Podporované produkty a typy virtuálních počítačů Azure |
| 2015553 | SAP v Azure: Požadavky na podporu |
| 2178632 | Klíčové metriky monitorování pro SAP v Azure |
| 2191498 | SAP v Linuxu s Azure: Rozšířené monitorování |
| 2243692 | Virtuální počítač s Linuxem v Azure (IaaS): Problémy s licencemi SAP |
| 2002167 | Red Hat Enterprise Linux 7.x: Instalace a upgrade |
| 2694118 | Doplněk Red Hat Enterprise Linux HA v Azure |
| 1999351 | Řešení potíží s vylepšeným monitorováním Azure pro SAP |
| 2233094 | DB6: Aplikace SAP v Azure, které používají IBM Db2 pro Linux, systém UNIX a Windows – další informace |
| 1612105 | DB6: Nejčastější dotazy k Db2 s HADR |
Přehled
Pro dosažení vysoké dostupnosti je IBM Db2 LUW s HADR nainstalovaný na alespoň dvou virtuálních počítačích Azure, které jsou nasazené ve škálovací sadě virtuálních počítačů s flexibilní orchestrací napříč zónami dostupnosti nebo ve skupině dostupnosti.
Následující grafika zobrazuje nastavení dvou virtuálních počítačů Azure s databázovým serverem. Oba databázové servery virtuální počítače Azure mají připojené vlastní úložiště a jsou spuštěné. V HADR má jedna instance databáze v jednom z virtuálních počítačů Azure roli primární instance. Všichni klienti jsou připojení k primární instanci. Všechny změny v databázových transakcích se uchovávají místně v transakčním protokolu Db2. Vzhledem k tomu, že se záznamy transakčního protokolu uchovávají místně, přenesou se záznamy přes protokol TCP/IP do instance databáze na druhém databázovém serveru, pohotovostním serveru nebo v pohotovostní instanci. Pohotovostní instance aktualizuje místní databázi tím, že posune záznamy přenesených transakčních protokolů. Tímto způsobem se pohotovostní server synchronizuje s primárním serverem.
HADR je pouze funkce replikace. Nemá žádnou detekci selhání a žádné automatické převzetí služeb při selhání ani zařízení pro převzetí služeb při selhání. Správce databáze musí ručně zahájit převzetí nebo přenos na pohotovostní server. Pokud chcete dosáhnout automatického převzetí a detekce selhání, můžete použít funkci clusteringu Pacemaker pro Linux. Pacemaker monitoruje dvě instance databázového serveru. Když dojde k chybovému ukončení instance primárního databázového serveru, pacemaker zahájí automatické převzetí HADR pohotovostním serverem. Pacemaker také zajišťuje, aby se virtuální IP adresa přiřadil novému primárnímu serveru.
Pokud chcete, aby se aplikační servery SAP připojily k primární databázi, potřebujete název virtuálního hostitele a virtuální IP adresu. Po převzetí služeb při selhání se aplikační servery SAP připojují k nové primární instanci databáze. V prostředí Azure se nástroj pro vyrovnávání zatížení Azure vyžaduje, aby používal virtuální IP adresu způsobem, který je nutný pro HADR IBM Db2.
Abychom vám pomohli plně pochopit, jak IBM Db2 LUW s HADR a Pacemakerem zapadá do nastavení systému SAP s vysokou dostupností, následující obrázek představuje přehled nastavení systému SAP založeného na databázi IBM Db2. Tento článek se zabývá pouze IBM Db2, ale poskytuje odkazy na další články o tom, jak nastavit další komponenty systému SAP.
Základní přehled požadovaných kroků
Pokud chcete nasadit konfiguraci IBM Db2, musíte postupovat takto:
- Naplánujte prostředí.
- Nasaďte virtuální počítače.
- Aktualizujte RHEL Linux a nakonfigurujte systémy souborů.
- Nainstalujte a nakonfigurujte Pacemaker.
- Nastavení clusteru glusterfs nebo Služby Azure NetApp Files
- Nainstalujte službu ASCS/ERS do samostatného clusteru.
- Nainstalujte databázi IBM Db2 s možností distribuované nebo vysoké dostupnosti (SWPM).
- Nainstalujte a vytvořte sekundární databázový uzel a instanci a nakonfigurujte HADR.
- Ověřte, že HADR funguje.
- Použijte konfiguraci Pacemaker pro řízení IBM Db2.
- Nakonfigurujte Azure Load Balancer.
- Nainstalujte primární a dialogové aplikační servery.
- Zkontrolujte a přizpůsobte konfiguraci aplikačních serverů SAP.
- Proveďte testy převzetí služeb při selhání a převzetí služeb při selhání.
Plánování infrastruktury Azure pro hostování IBM Db2 LUW s HADR
Před spuštěním nasazení dokončete proces plánování. Plánování vytvoří základ pro nasazení konfigurace Db2 pomocí HADR v Azure. Klíčové prvky, které musí být součástí plánování IMB Db2 LUW (databázová část prostředí SAP), jsou uvedeny v následující tabulce:
| Téma | Krátký popis |
|---|---|
| Definování skupin prostředků Azure | Skupiny prostředků, ve kterých nasazujete virtuální počítač, virtuální síť, Azure Load Balancer a další prostředky. Může být existující nebo nový. |
| Definice virtuální sítě nebo podsítě | Virtuální počítače pro IBM Db2 a Azure Load Balancer se nasazují. Může být existující nebo nově vytvořený. |
| Virtuální počítače hostující IBM Db2 LUW | Velikost virtuálního počítače, úložiště, sítě, IP adresa. |
| Název virtuálního hostitele a virtuální IP adresa pro databázi IBM Db2 | Virtuální IP adresa nebo název hostitele se používá pro připojení aplikačních serverů SAP. db-virt-hostname, db-virt-ip. |
| Ohraničení Azure | Metoda, aby se zabránilo rozdělení mozku situace je zabráněno. |
| Azure Load Balancer | Použití standardního (doporučeného) portu sondy pro databázi Db2 (naše doporučení 62500) probe-port. |
| Překlad adres IP | Jak funguje překlad názvů v prostředí. Důrazně se doporučuje služba DNS. Lze použít soubor místních hostitelů. |
Další informace o nástroji Pacemaker pro Linux v Azure najdete v tématu Nastavení Pacemakeru v Red Hat Enterprise Linuxu v Azure.
Důležité
Pro Db2 verze 11.5.6 a vyšší důrazně doporučujeme integrované řešení využívající Pacemaker od IBM.
Nasazení v Red Hat Enterprise Linuxu
Agent prostředků pro IBM Db2 LUW je součástí doplňku Pro ha serveru Red Hat Enterprise Linux Server. Pro nastavení popsané v tomto dokumentu byste měli použít Red Hat Enterprise Linux pro SAP. Azure Marketplace obsahuje image pro Red Hat Enterprise Linux 7.4 pro SAP nebo vyšší, kterou můžete použít k nasazení nových virtuálních počítačů Azure. Mějte na paměti různé modely podpory nebo služeb, které nabízí Red Hat prostřednictvím Azure Marketplace, když zvolíte image virtuálního počítače na Azure VM Marketplace.
Hostitelé: Aktualizace DNS
Vytvořte seznam všech názvů hostitelů, včetně názvů virtuálních hostitelů, a aktualizujte servery DNS tak, aby povolte správnou IP adresu překladu názvů hostitelů. Pokud server DNS neexistuje nebo nemůžete aktualizovat a vytvořit položky DNS, musíte použít místní hostitelské soubory jednotlivých virtuálních počítačů, které se v tomto scénáři účastní. Pokud používáte položky souborů hostitele, ujistěte se, že se položky použijí na všechny virtuální počítače v systémovém prostředí SAP. Doporučujeme ale použít DNS, které se ideálně rozšíří do Azure.
Ruční nasazení
Ujistěte se, že ibm/SAP pro IBM Db2 LUW podporuje vybraný operační systém. Seznam podporovaných verzí operačního systému pro virtuální počítače Azure a verze Db2 je k dispozici v poznámkovém 1928533 SAP. Seznam vydaných verzí operačního systému podle jednotlivých verzí Db2 je k dispozici v matici dostupnosti produktů SAP. Pro SAP důrazně doporučujeme minimálně Red Hat Enterprise Linux 7.4 kvůli vylepšení výkonu souvisejícím s Azure v této nebo novější verzi Red Hat Enterprise Linuxu.
- Vytvořte nebo vyberte skupinu prostředků.
- Vytvořte nebo vyberte virtuální síť a podsíť.
- Zvolte vhodný typ nasazení pro virtuální počítače SAP. Škálovací sada virtuálních počítačů se obvykle používá k flexibilní orchestraci.
- Vytvoření virtuálního počítače 1
- Použijte Red Hat Enterprise Linux pro image SAP na Azure Marketplace.
- Vyberte škálovací sadu, zónu dostupnosti nebo sadu dostupnosti vytvořenou v kroku 3.
- Vytvoření virtuálního počítače 2
- Použijte Red Hat Enterprise Linux pro image SAP na Azure Marketplace.
- Vyberte škálovací sadu, zónu dostupnosti nebo sadu dostupnosti vytvořenou v kroku 3 (ne stejnou zónu jako v kroku 4).
- Přidejte do virtuálních počítačů datové disky a pak zkontrolujte doporučení nastavení systému souborů v článku NASAZENÍ DBMS virtuálních počítačů Azure DBMS IBM Db2 pro úlohy SAP.
Instalace prostředí IBM Db2 LUW a SAP
Než začnete s instalací prostředí SAP založeného na IBM Db2 LUW, projděte si následující dokumentaci:
- Dokumentace k Azure
- Dokumentace k SAP
- Dokumentace IBM.
Odkazy na tuto dokumentaci najdete v úvodní části tohoto článku.
Projděte si instalační příručky SAP týkající se instalace aplikací založených na NetWeaveru na IBM Db2 LUW. Příručky najdete na portálu nápovědy SAP pomocí Finderu průvodce instalací SAP.
Počet průvodců zobrazených na portálu můžete snížit nastavením následujících filtrů:
- Chci: Nainstalujte nový systém.
- Moje databáze: IBM Db2 pro Linux, Unix a Windows.
- Další filtry pro verze SAP NetWeaver, konfiguraci zásobníku nebo operační systém
Pravidla brány firewall pro Red Hat
Red Hat Enterprise Linux má ve výchozím nastavení povolenou bránu firewall.
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
Pokyny k instalaci pro nastavení IBM Db2 LUW s HADR
Nastavení primární instance databáze IBM Db2 LUW:
- Použijte vysokou dostupnost nebo distribuovanou možnost.
- Nainstalujte instanci SAP ASCS/ERS a Database.
- Vytvořte zálohu nově nainstalované databáze.
Důležité
Poznamenejte si port pro komunikaci databáze, který je nastavený během instalace. Musí to být stejné číslo portu pro obě instance databáze.
Nastavení IBM Db2 HADR pro Azure
Pokud používáte agenta fencingu Azure Pacemaker, nastavte následující parametry:
- Doba trvání okna partnerského vztahu HADR (sekundy) (HADR_PEER_WINDOW) = 240
- Hodnota časového limitu HADR (HADR_TIMEOUT) = 45
Doporučujeme předchozí parametry založené na počátečním testování převzetí služeb při selhání nebo převzetí služeb při selhání. Je povinné otestovat správné funkce převzetí služeb při selhání a převzetí služeb při selhání pomocí těchto nastavení parametrů. Vzhledem k tomu, že se jednotlivé konfigurace mohou lišit, můžou parametry vyžadovat úpravu.
Poznámka:
Specifické pro IBM Db2 s konfigurací HADR s normálním spuštěním: Sekundární nebo pohotovostní instance databáze musí být spuštěná, abyste mohli spustit primární instanci databáze.
Poznámka:
Pro instalaci a konfiguraci, která je specifická pro Azure a Pacemaker: Během instalačního postupu prostřednictvím SAP Software Provisioning Manageru existuje explicitní otázka týkající se vysoké dostupnosti IBM Db2 LUW:
- Nevybírejte IBM Db2 pureScale.
- Nevybírejte možnost Instalovat IBM Tivoli System Automation pro multiplatformy.
- Nevybírejte možnost Generovat konfigurační soubory clusteru.
Pokud chcete nastavit pohotovostní databázový server pomocí homogenní procedury kopírování systému SAP, proveďte tyto kroky:
- Vyberte možnost> Kopírování systému Cílové systémy>Distribuované>databáze instance.
- Jako metodu kopírování vyberte homogenní systém , abyste mohli zálohu obnovit v pohotovostní instanci serveru.
- Po dosažení kroku ukončení obnovte databázi pro homogenní kopii systému, ukončete instalační program. Obnovte databázi ze zálohy primárního hostitele. Všechny následné fáze instalace už byly spuštěny na primárním databázovém serveru.
Pravidla firewallu Red Hat pro DB2 HADR
Přidejte pravidla brány firewall, která povolí provoz do DB2 a mezi DB2, aby HADR fungoval:
- Port pro komunikaci databáze. Pokud používáte oddíly, přidejte tyto porty také.
- Port HADR (hodnota parametru DB2 HADR_LOCAL_SVC).
- Port sondy Azure.
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
Kontrola IBM Db2 HADR
Pro demonstrační účely a postupy popsané v tomto článku je identifikátor SID databáze ID2.
Po nakonfigurování HADR a stavu PEER a CONNECTED na primárních a pohotovostních uzlech proveďte následující kontrolu:
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
Konfigurace služby Azure Load Balancer
Během konfigurace virtuálního počítače máte možnost vytvořit nebo vybrat ukončení nástroje pro vyrovnávání zatížení v části Sítě. Postupujte podle následujících kroků a nastavte standardní nástroj pro vyrovnávání zatížení pro nastavení databáze DB2 s vysokou dostupností.
Postupujte podle kroků v tématu Vytvoření nástroje pro vyrovnávání zatížení a nastavte standardní nástroj pro vyrovnávání zatížení pro systém SAP s vysokou dostupností pomocí webu Azure Portal. Při nastavování nástroje pro vyrovnávání zatížení zvažte následující body:
- Konfigurace front-endové IP adresy: Vytvořte front-endovou IP adresu. Vyberte stejnou virtuální síť a název podsítě jako vaše databázové virtuální počítače.
- Back-endový fond: Vytvořte back-endový fond a přidejte databázové virtuální počítače.
- Příchozí pravidla: Vytvořte pravidlo vyrovnávání zatížení. U obou pravidel vyrovnávání zatížení postupujte stejně.
- IP adresa front-endu: Vyberte front-endovou IP adresu.
- Back-endový fond: Vyberte back-endový fond.
- Porty s vysokou dostupností: Tuto možnost vyberte.
- Protokol: Vyberte TCP.
- Sonda stavu: Vytvořte sondu stavu s následujícími podrobnostmi:
- Protokol: Vyberte TCP.
- Port: Například 625<instance-no.>.
- Interval: Zadejte 5.
- Prahová hodnota sondy: Zadejte 2.
- Časový limit nečinnosti (minuty):Zadejte 30.
- Povolit plovoucí IP adresu: Vyberte tuto možnost.
Poznámka:
Vlastnost numberOfProbeskonfigurace sondy stavu , jinak označovaná jako prahová hodnota není v pořádku na portálu, se nerespektuje. Chcete-li řídit počet úspěšných nebo neúspěšných po sobě jdoucích sond, nastavte vlastnost probeThreshold na 2hodnotu . V současné době není možné tuto vlastnost nastavit pomocí webu Azure Portal, takže použijte buď Azure CLI, nebo příkaz PowerShellu.
Důležité
Plovoucí IP adresa není podporovaná v konfiguraci sekundární IP adresy síťové karty ve scénářích vyrovnávání zatížení. Další informace najdete v tématu Omezení azure Load Balanceru. Pokud potřebujete další IP adresu pro virtuální počítač, nasaďte druhou síťovou kartu.
Poznámka:
Pokud jsou virtuální počítače bez veřejných IP adres umístěny do back-endového fondu interní instance (bez veřejné IP adresy) služby Azure Load Balancer úrovně Standard, neexistuje odchozí připojení k internetu, pokud se neprovádí další konfigurace umožňující směrování do veřejných koncových bodů. Další informace o tom, jak dosáhnout odchozího připojení, najdete v tématu Připojení k veřejnému koncovému bodu pro virtuální počítače využívající Azure Standard Load Balancer ve scénářích s vysokou dostupností SAP.
Důležité
Nepovolujte časové razítka PROTOKOLU TCP na virtuálních počítačích Azure umístěných za Azure Load Balancerem. Povolení časových razítek PROTOKOLU TCP může způsobit selhání sond stavu. Nastavte parametr net.ipv4.tcp_timestamps na 0. Další informace najdete v tématu Sondy stavu Load Balanceru.
[A] Přidání pravidla brány firewall pro port sondy:
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
Vytvoření clusteru Pacemaker
Pokud chcete vytvořit základní cluster Pacemaker pro tento server IBM Db2, přečtěte si téma Nastavení Pacemakeru v Red Hat Enterprise Linuxu v Azure.
Konfigurace Db2 Pacemaker
Pokud k automatickému převzetí služeb při selhání uzlu použijete Pacemaker, musíte odpovídajícím způsobem nakonfigurovat instance Db2 a Pacemaker. Tato část popisuje tento typ konfigurace.
Následující položky mají předponu:
- [A]: Platí pro všechny uzly.
- [1]: Platí pouze pro uzel 1.
- [2]: Platí pouze pro uzel 2.
[A] Předpoklad konfigurace Pacemakeru:
Vypněte oba databázové servery se sid> user db2<s db2stop.
Změňte prostředí prostředí pro uživatele db2<sid> na /bin/ksh:
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Konfigurace Pacemakeru
[1] Konfigurace Pacemakeru specifická pro IBM Db2 HADR:
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[1] Vytvoření prostředků IBM Db2:
Pokud vytváříte cluster na RHEL 7.x, nezapomeňte aktualizovat agenty prostředků na verzi
resource-agents-4.1.1-61.el7_9.15nebo vyšší. K vytvoření prostředků clusteru použijte následující příkazy:# 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_ID2Pokud vytváříte cluster na RHEL 8.x, nezapomeňte aktualizovat agenty prostředků balíčku na verzi
resource-agents-4.1.1-93.el8nebo vyšší. Podrobnosti naleznete v tématu Prostředek Red Hat KBAdb2s HADR selže povýšení se stavemPRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. K vytvoření prostředků clusteru použijte následující příkazy:# 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] Zahájení zdrojů IBM Db2:
Vypněte Pacemaker z režimu údržby.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo pcs property set maintenance-mode=false[1] Ujistěte se, že je stav clusteru v pořádku a že jsou spuštěné všechny prostředky. Není důležité, na kterém uzlu jsou prostředky spuštěné.
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
Důležité
Clusterovanou instanci Db2 Pacemaker musíte spravovat pomocí nástrojů Pacemaker. Pokud používáte příkazy db2, jako je db2stop, Pacemaker zjistí akci jako selhání prostředku. Pokud provádíte údržbu, můžete uzly nebo prostředky umístit do režimu údržby. Pacemaker pozastaví monitorovací prostředky a pak můžete použít normální příkazy pro správu db2.
Provedení změn profilů SAP pro použití virtuální IP adresy pro připojení
Pokud se chcete připojit k primární instanci konfigurace HADR, musí aplikační vrstva SAP používat virtuální IP adresu, kterou jste definovali a nakonfigurovali pro Azure Load Balancer. Jsou vyžadovány následující změny:
/sapmnt/SID>/<profile/DEFAULT. PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/SID>/<global/db6/db2cli.ini
Hostname=db-virt-hostname
Instalace primárních a dialogových aplikačních serverů
Při instalaci primárních a dialogových aplikačních serverů proti konfiguraci Db2 HADR použijte název virtuálního hostitele, který jste vybrali pro konfiguraci.
Pokud jste instalaci provedli před vytvořením konfigurace DB2 HADR, proveďte změny, jak je popsáno v předchozí části, a postupujte následovně pro zásobníky SAP Java.
kontrola adresy URL JDBC pro systémy jazyk ABAP+Java nebo Java Stack
Pomocí nástroje Konfigurace J2EE zkontrolujte nebo aktualizujte adresu URL JDBC. Vzhledem k tomu, že nástroj J2EE Config je grafický nástroj, musíte mít nainstalovaný X server:
Přihlaste se k primárnímu aplikačnímu serveru instance J2EE a spusťte:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shV levém rámečku zvolte úložiště zabezpečení.
V pravém rámečku zvolte klíč
jdbc/pool/\<SAPSID>/url.Změňte název hostitele v adrese URL JDBC na název virtuálního hostitele.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Vyberte Přidat.
Pokud chcete uložit změny, vyberte ikonu disku v levém horním rohu.
Zavřete konfigurační nástroj.
Restartujte instanci Javy.
Konfigurace archivace protokolů pro nastavení HADR
Pokud chcete nakonfigurovat archivaci protokolů Db2 pro instalaci HADR, doporučujeme nakonfigurovat primární i pohotovostní databázi tak, aby měla možnost automatického načítání protokolů ze všech umístění archivu protokolů. Primární i pohotovostní databáze musí být schopná načíst soubory archivu protokolu ze všech umístění archivu protokolů, do kterých může archivovat jeden z instancí databáze.
Archivace protokolů provádí pouze primární databáze. Pokud změníte role HADR databázových serverů nebo dojde-li k selhání, je nová primární databáze zodpovědná za archivaci protokolů. Pokud jste nastavili několik umístění archivu protokolů, může se protokoly archivovat dvakrát. V případě místního nebo vzdáleného zachytávání možná budete muset archivované protokoly z původního primárního serveru zkopírovat ručně do aktivního umístění protokolu nového primárního serveru.
Doporučujeme nakonfigurovat společnou sdílenou složku NFS nebo GlusterFS, kde se protokoly zapisují z obou uzlů. Sdílená složka NFS nebo GlusterFS musí být vysoce dostupná.
Existující sdílené složky NFS s vysokou dostupností nebo GlusterFS můžete použít pro přenosy nebo adresář profilu. Další informace naleznete v tématu:
- GlusterFS na virtuálních počítačích Azure v Red Hat Enterprise Linuxu pro SAP NetWeaver
- Vysoká dostupnost pro SAP NetWeaver na virtuálních počítačích Azure ve službě Red Hat Enterprise Linux s Azure NetApp Files pro aplikace SAP
- Azure NetApp Files (pro vytvoření sdílených složek NFS)
Otestování nastavení clusteru
Tato část popisuje, jak můžete otestovat nastavení DB2 HADR. Každý test předpokládá, že primární server IBM Db2 běží na virtuálním počítači az-idb01 . Je nutné použít uživatele s oprávněními sudo nebo kořenem (nedoporučuje se).
Počáteční stav všech testovacích případů je vysvětlen tady: (crm_mon -r nebo pcs status)
- Pcs status is a snapshot of Pacemaker status at execution time.
- crm_mon -r je průběžný výstup stavu Pacemakeru.
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
Původní stav v systému SAP je zdokumentovaný v přehledu konfigurace > Transaction DBACOCKPIT>, jak je znázorněno na následujícím obrázku:
Testovací převzetí IBM Db2
Důležité
Před zahájením testu se ujistěte, že:
Pacemaker nemá žádné neúspěšné akce (stav pcs).
Neexistují žádná omezení umístění (zbývající migrace testu).
Synchronizace HADR IBM Db2 funguje. Zkontrolujte identifikátor sid> db2<uživatele.
db2pd -hadr -db <DBSID>
Spuštěním následujícího příkazu migrujte uzel, na kterém běží primární databáze Db2:
# 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
Po dokončení migrace bude výstup stavu crm vypadat takto:
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
Původní stav v systému SAP je zdokumentovaný v přehledu konfigurace > Transaction DBACOCKPIT>, jak je znázorněno na následujícím obrázku:
Migrace prostředků pomocí přesunu prostředků pcs vytváří omezení umístění. Omezení umístění v tomto případě brání spuštění instance IBM Db2 na az-idb01. Pokud se omezení umístění neodstraní, prostředek nemůže navrátit služby po obnovení.
Odebrání omezení umístění a pohotovostního uzlu by se spustilo v 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
A stav clusteru se změní na:
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
Migrace prostředku zpět do az-idb01 a vymazání omezení umístění
# 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
- RHEL 7.x -
pcs resource move <resource_name> <host>: Vytvoří omezení umístění a může způsobit problémy s převzetím - RHEL 8.x -
pcs resource move <resource_name> --master: Vytvoří omezení umístění a může způsobit problémy s převzetím pcs resource clear <resource_name>: Vymaže omezení umístění.pcs resource cleanup <resource_name>: Vymaže všechny chyby prostředku.
Testování ručního převzetí
Ruční převzetí můžete otestovat zastavením služby Pacemaker na uzlu az-idb01 :
systemctl stop pacemaker
stav na 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
Po převzetí služeb při selhání můžete službu spustit znovu na az-idb01.
systemctl start pacemaker
Ukončete proces Db2 na uzlu, na kterém běží primární databáze HADR.
#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
Instance Db2 selže a Pacemaker přesune hlavní uzel a oznámí následující stav:
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 restartuje primární instanci databáze Db2 na stejném uzlu nebo převezme služby při selhání uzlu, na kterém běží sekundární instance databáze, a zobrazí se chyba.
Ukončete proces Db2 na uzlu, na kterém běží sekundární instance databáze.
[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
Uzel se dostane do stavu selhání a zobrazí se zpráva o chybě.
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
Instance Db2 se restartuje v sekundární roli, kterou předtím přiřadila.
Zastavení databáze prostřednictvím db2stop force na uzlu, na kterém běží primární instance databáze HADR
Jako sid user db2<sid> execute command db2stop force:
az-idb01:db2ptr> db2stop force
Zjistilo se selhání:
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
Sekundární instance databáze DB2 HADR byla povýšena do primární role.
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
Selhání virtuálního počítače, na kterém běží primární instance databáze HADR, se "zastavením"
#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger
V takovém případě Pacemaker zjistí, že uzel, na kterém běží primární instance databáze, nereaguje.
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
Dalším krokem je kontrola situace rozděleného mozku . Poté, co přeživší uzel zjistil, že uzel, který naposledy spustil primární instanci databáze, je spuštěno převzetí služeb při selhání prostředků.
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
V případě panice jádra se uzel, který selhal, restartuje agenta dělení. Jakmile se uzel, který selhal, vrátí do online režimu, musíte spustit cluster pacemakeru.
sudo pcs cluster start
spustí instanci Db2 do sekundární role.
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