Sdílet prostřednictvím

Vysoká dostupnost IBM DB2 LUW ve virtuálních počítačích Azure na linuxovém serveru Red Hat Enterprise

  • Článek

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
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, UNIX a Windows – další informace
1612105 DB6: Nejčastější dotazy k Db2 s HADR
Dokumentace
Wikiweb komunity SAP: Obsahuje všechny požadované poznámky SAP pro Linux.
Plánování a implementace virtuálních počítačů Azure pro SAP v Linuxu
Nasazení služby Azure Virtual Machines pro SAP v Linuxu (tento článek)
Průvodce nasazením systému pro správu databází (DBMS) služby Azure Virtual Machines pro SAP v Linuxu
Kontrolní seznam úloh SAP v Azure pro plánování a nasazení
Přehled doplňku s vysokou dostupností pro Red Hat Enterprise Linux 7
Správa doplňků s vysokou dostupností
Referenční informace k doplňku s vysokou dostupností
Zásady podpory pro clustery s vysokou dostupností RHEL – Virtuální počítače Microsoft Azure jako členy clusteru
Instalace a konfigurace clusteru s vysokou dostupností Red Hat Enterprise Linux 7.4 (a novější) v Microsoft Azure
Nasazení DBMS DBMS pro IBM Db2 Azure Virtual Machines pro úlohy SAP
IBM Db2 HADR 11.1
IBM Db2 HADR 10.5
Zásady podpory pro clustery s vysokou dostupností RHEL – správa IBM Db2 pro Linux, Unix a Windows v clusteru

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.

Přehled vysoké dostupnosti IBM Db2

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.

Přehled kompletního prostředí IBM DB2 s vysokou dostupností

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.

  1. Vytvořte nebo vyberte skupinu prostředků.
  2. Vytvořte nebo vyberte virtuální síť a podsíť.
  3. 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.
  4. Vytvoření virtuálního počítače 1
    1. Použijte Red Hat Enterprise Linux pro image SAP na Azure Marketplace.
    2. Vyberte škálovací sadu, zónu dostupnosti nebo sadu dostupnosti vytvořenou v kroku 3.
  5. Vytvoření virtuálního počítače 2
    1. Použijte Red Hat Enterprise Linux pro image SAP na Azure Marketplace.
    2. Vyberte škálovací sadu, zónu dostupnosti nebo sadu dostupnosti vytvořenou v kroku 3 (ne stejnou zónu jako v kroku 4).
  6. 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. Definice portu SAP SWPM

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. SAP SWPM – možnosti vysoké dostupnosti DB2

Pokud chcete nastavit pohotovostní databázový server pomocí homogenní procedury kopírování systému SAP, proveďte tyto kroky:

  1. Vyberte možnost> Kopírování systému Cílové systémy>Distribuované>databáze instance.
  2. Jako metodu kopírování vyberte homogenní systém , abyste mohli zálohu obnovit v pohotovostní instanci serveru.
  3. 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:

  1. 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.
  2. Back-endový fond: Vytvořte back-endový fond a přidejte databázové virtuální počítače.
  3. 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.

[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. [1] Konfigurace Pacemakeru specifická pro IBM Db2 HADR:

    # Put Pacemaker into maintenance mode
sudo pcs property set maintenance-mode=true

  2. [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.15 nebo 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 resource
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_ID2

    Pokud vytváříte cluster na RHEL 8.x, nezapomeňte aktualizovat agenty prostředků balíčku na verzi resource-agents-4.1.1-93.el8 nebo vyšší. Podrobnosti naleznete v tématu Prostředek Red Hat KBA db2 s HADR selže povýšení se stavem PRIMARY/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 resource
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

  3. [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

  4. [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 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:

  1. Přihlaste se k primárnímu aplikačnímu serveru instance J2EE a spusťte:

    sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh

  2. V levém rámečku zvolte úložiště zabezpečení.

  3. V pravém rámečku zvolte klíč jdbc/pool/\<SAPSID>/url.

  4. Změňte název hostitele v adrese URL JDBC na název virtuálního hostitele.

    jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0

  5. Vyberte Přidat.

  6. Pokud chcete uložit změny, vyberte ikonu disku v levém horním rohu.

  7. Zavřete konfigurační nástroj.

  8. 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:

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:

DBACockpit – Před migrací

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:

DBACockpit – Po migraci

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

DBACockpit – Odebrání omezení umístění

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

Další kroky