Vysoká dostupnost IBM Db2 LUW na virtuálních počítačích Azure na SUSE Linux Enterprise Serveru s pacemakerem
IBM Db2 for Linux, 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 a alespoň jeden uzel, 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 |
| 1984787 | SUSE LINUX Enterprise Server 12: Poznámky k instalaci |
| 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, 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 této 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 SUSE Linux a nakonfigurujte systémy souborů.
- Nainstalujte a nakonfigurujte Pacemaker.
- Nainstalujte systém souborů NFS s vysokou dostupností.
- 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, který se používá pro připojení aplikačních serverů SAP. db-virt-hostname, db-virt-ip. |
| Ohraničení Azure | Šermování Azure nebo šermování SBD (důrazně doporučeno). Metoda, aby se zabránilo rozdělení mozku situace. |
| Virtuální počítač SBD | Velikost virtuálního počítače SBD, úložiště, síť. |
| 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 na SUSE Linux Enterprise Serveru 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 SUSE Linuxu
Agent prostředků pro IBM Db2 LUW je součástí SUSE Linux Enterprise Serveru pro aplikace SAP. Pro nastavení, které je popsáno v tomto dokumentu, musíte použít SUSE Linux Server pro aplikace SAP. Azure Marketplace obsahuje image pro SUSE Enterprise Server for SAP Applications 12, 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í SUSE 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. Důrazně doporučujeme minimálně SLES 12 SP4 kvůli vylepšením výkonu souvisejícím s Azure v této nebo novějších verzích SUSE Linux.
- 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žití SLES 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žití SLES 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 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: "Install a new system" (Nainstalovat 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
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í se jednat o stejné číslo portu pro obě instance databáze. 
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.
Nastavení HADR pro IBM Db2
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.
Při použití zařízení SBD pro Linux Pacemaker nastavte následující parametry DB2 HADR:
- Doba trvání okna partnerského uzlu HADR (sekundy) (HADR_PEER_WINDOW) = 300
- Hodnota časového limitu HADR (HADR_TIMEOUT) = 60
Pokud používáte agenta fencingu Azure Pacemaker, nastavte následující parametry:
- Doba trvání okna partnerského uzlu HADR (sekundy) (HADR_PEER_WINDOW) = 900
- Hodnota časového limitu HADR (HADR_TIMEOUT) = 60
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.
Důležité
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.
Pro demonstrační účely a postupy popsané v tomto článku je identifikátor SID databáze PTR.
Kontrola IBM Db2 HADR
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 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
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.
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.
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 na SUSE Linux Enterprise Serveru 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] Požadavky na konfiguraci 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. Doporučujeme použít nástroj Yast.
Konfigurace Pacemakeru
Důležité
Nedávné testování odhalilo situace, kdy netcat přestane reagovat na požadavky kvůli backlogu a jeho omezení zpracování pouze jednoho připojení. Prostředek netcat přestane naslouchat požadavkům azure Load Balanceru a plovoucí IP adresa přestane být k dispozici. Pro stávající clustery Pacemaker doporučujeme v minulosti nahradit netcat socat. V současné době doporučujeme používat agenta prostředků azure-lb, který je součástí agentů prostředků balíčku s následujícími požadavky na verzi balíčku:
- Pro SLES 12 SP4/SP5 musí být verze alespoň resource-agents-4.3.018.a7fb5035-3.30.1.
- Pro SLES 15/15 SP1 musí být verze alespoň resource-agents-4.3.0184.6ee15eb2-4.13.1.
Upozorňujeme, že změna bude vyžadovat krátký výpadek.
Pokud už konfigurace pro existující clustery Pacemaker změnila na použití socat, jak je popsáno v posílení zabezpečení detekce Nástroje pro vyrovnávání zatížení Azure, není nutné okamžitě přepnout na agenta prostředků azure-lb.
[1] Konfigurace Pacemakeru specifická pro IBM Db2 HADR:
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true[1] Vytvoření prostředků IBM Db2:
# 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] Zahájení zdrojů IBM Db2:
Vypněte Pacemaker z režimu údržby.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property 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 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 ]
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 zásobníku ABAP+Java nebo Java
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, kde se protokoly zapisují z obou uzlů. Sdílená složka NFS musí být vysoce dostupná.
Existující sdílené složky NFS s vysokou dostupností můžete použít pro přenosy nebo adresář profilu. Další informace naleznete v tématu:
- Vysoká dostupnost systému souborů NFS na virtuálních počítačích Azure na serveru SUSE Linux Enterprise Server.
- Vysoká dostupnost pro SAP NetWeaver na virtuálních počítačích Azure na SUSE Linux Enterprise Serveru 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 jste přihlášeni jako uživatel root a primární server IBM Db2 běží na virtuálním počítači azibmdb01 .
Počáteční stav všech testovacích případů je vysvětlen zde: (crm_mon -r nebo stav crm)
- Stav crm je snímek stavu Pacemakeru v době provádění.
- crm_mon -r je průběžný výstup stavu Pacemakeru.
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 ]
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 crm).
Neexistují žádná omezení umístění (zbývající migrace testu migrace).
Synchronizace HADR IBM Db2 funguje. Kontrola 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:
crm resource migrate msl_Db2_db2ptr_PTR azibmdb02
Po dokončení migrace bude výstup stavu crm vypadat takto:
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 ]
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í migrace prostředků crm vytváří omezení umístění. Omezení umístění by se měla odstranit. Pokud se omezení umístění neodstraní, prostředek nemůže navrátit služby po obnovení nebo můžete zaznamenat nežádoucí převzetí služeb.
Migrace prostředku zpět na azibmdb01 a vymazání omezení umístění
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- Migrace <prostředků crm res_name><hostitele>: Vytvoří omezení umístění a může způsobit problémy s převzetím
- Vymazání <res_name> prostředku crm: Vymaže omezení umístění
- res_name vyčištění <>prostředků crm: Vymaže všechny chyby prostředku.
Testování šermování SBD
V tomto případě otestujeme šermování SBD, které doporučujeme provést při použití SUSE Linuxu.
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
Uzel clusteru azibmdb01 by se měl restartovat. Primární role HADR IBM Db2 se přesune do azibmdb02. Když je azibmdb01 opět online, instance Db2 se přesune do role sekundární instance databáze.
Pokud se služba Pacemaker nespustí automaticky na restartování bývalé primární, nezapomeňte ji spustit ručně pomocí:
sudo service pacemaker start
Testování ručního převzetí
Ruční převzetí můžete otestovat zastavením služby Pacemaker na uzlu azibmdb01 :
service pacemaker stop
stav na 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 ]
Po převzetí služeb při selhání můžete službu spustit znovu na azibmdb01.
service pacemaker start
Ukončete proces Db2 na uzlu, na kterém běží primární databáze HADR.
#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
Instance Db2 selže a Pacemaker oznámí následující stav:
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 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.
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
Ukončete proces Db2 na uzlu, na kterém běží sekundární instance databáze.
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Uzel se dostane do stavu selhání a zobrazí se zpráva o chybě.
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
Instance Db2 se restartuje v sekundární roli, kterou předtím přiřadila.
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
Zastavení databáze prostřednictvím db2stop force na uzlu, na kterém běží primární instance databáze HADR
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 ]
Jako sid user db2<sid> execute command db2stop force:
azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force
Zjistilo se selhání
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
Sekundární instance databáze DB2 HADR byla povýšena do primární role.
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
Selhání virtuálního počítače s restartováním na uzlu, na kterém běží primární instance databáze HADR
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker podporuje sekundární instanci na roli primární instance. Stará primární instance se po restartování virtuálního počítače přesune do sekundární role a všechny služby se plně obnoví.
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 ]
Selhání virtuálního počítače, na kterém běží primární instance databáze HADR, se "zastavením"
#Linux kernel panic - halts OS
azibmdb01:~ # 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 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 ]
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: [ 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 ]
V případě zastavení uzlu se musí uzel, který selhal, restartovat prostřednictvím nástrojů pro správu Azure (na webu Azure Portal, PowerShellu nebo Azure CLI). Jakmile je uzel, který selhal, znovu online, spustí instanci Db2 do sekundární role.
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 ]