Wysoka dostępność systemu IBM Db2 LUW na maszynach wirtualnych platformy Azure w systemie SUSE Linux Enterprise Server z programem Pacemaker

Usługa IBM Db2 dla systemów Linux, UNIX i Windows (LUW) w konfiguracji wysokiej dostępności i odzyskiwania po awarii (HADR) składa się z jednego węzła, który uruchamia główne wystąpienie bazy danych, a co najmniej jeden węzeł uruchamia drugorzędne wystąpienie bazy danych. Zmiany w podstawowej instancji bazy danych są replikowane do drugorzędnej instancji bazy danych synchronicznie lub asynchronicznie, w zależności od Twojej konfiguracji.

W tym artykule opisano sposób wdrażania i konfigurowania maszyn wirtualnych platformy Azure, instalowania struktury klastra i instalowania bazy danych IBM Db2 LUW przy użyciu konfiguracji usługi HADR.

W tym artykule nie opisano sposobu instalowania i konfigurowania systemu IBM Db2 LUW z instalacją oprogramowania HADR lub SAP. Aby ułatwić wykonywanie tych zadań, udostępniamy odwołania do podręczników instalacji oprogramowania SAP i IBM. Ten artykuł koncentruje się na częściach specyficznych dla środowiska platformy Azure.

Obsługiwane wersje IBM Db2 to wersja 10.5 lub nowsza, jak opisano w notatce SAP 1928533.

Przed rozpoczęciem instalacji zapoznaj się z następującymi uwagami i dokumentacją oprogramowania SAP:

Overview

Aby uzyskać wysoką dostępność, system IBM Db2 LUW z usługą HADR jest instalowany na co najmniej dwóch maszynach wirtualnych platformy Azure, które są wdrażane w zestawie skalowania maszyn wirtualnych z elastyczną aranżacją w różnych strefach dostępności lub w zestawie dostępności.

Poniższa grafika przedstawia konfigurację dwóch maszyn wirtualnych platformy Azure serwera bazy danych. Obie maszyny wirtualne serwera bazy danych platformy Azure mają dołączony własny magazyn i są uruchomione. W usłudze HADR jedno wystąpienie bazy danych na jednej z maszyn wirtualnych platformy Azure ma rolę wystąpienia podstawowego. Wszyscy klienci są połączeni z tą główną instancją. Wszystkie zmiany transakcji bazy danych są utrwalane lokalnie w dzienniku transakcji db2. Ponieważ rekordy dziennika transakcji są utrwalane lokalnie, rekordy są przesyłane za pośrednictwem protokołu TCP/IP do wystąpienia bazy danych na drugim serwerze bazy danych, serwerze rezerwowym lub wystąpieniu rezerwowym. Wystąpienie rezerwowe aktualizuje lokalną bazę danych przez przeniesienie przeniesionych rekordów dziennika transakcji. W ten sposób serwer rezerwowy jest synchronizowany z serwerem podstawowym.

USŁUGA HADR jest tylko funkcją replikacji. Nie ma wykrywania błędów i nie ma automatycznych funkcji przejęcia ani trybu failover. Przejęcie lub przeniesienie na serwer rezerwowy musi zostać zainicjowane ręcznie przez administratora bazy danych. Aby osiągnąć automatyczne przejęcie i wykrywanie błędów, możesz skorzystać z funkcjonalności klastrowania Pacemaker w systemie Linux. Program Pacemaker monitoruje dwa wystąpienia baz danych na serwerze. W przypadku awarii wystąpienia podstawowego serwera bazy danych program Pacemaker inicjuje automatyczne przejęcie usługi HADR przez serwer rezerwowy. Program Pacemaker zapewnia również przypisanie wirtualnego adresu IP do nowego serwera podstawowego.

Aby serwery aplikacji SAP łączyły się z podstawową bazą danych, potrzebna jest nazwa hosta wirtualnego i wirtualny adres IP. Po przejściu w tryb failover serwery aplikacji SAP łączą się z nowym podstawowym wystąpieniem bazy danych. W środowisku platformy Azure moduł równoważenia obciążenia platformy Azure jest wymagany do używania wirtualnego adresu IP w sposób wymagany dla usługi HADR firmy IBM Db2.

Aby w pełni zrozumieć, jak system IBM Db2 LUW z usługami HADR i Pacemaker pasuje do konfiguracji systemu SAP o wysokiej dostępności, na poniższej ilustracji przedstawiono omówienie konfiguracji systemu SAP o wysokiej dostępności opartej na bazie danych IBM Db2. W tym artykule opisano tylko ibm Db2, ale zawiera on odwołania do innych artykułów dotyczących konfigurowania innych składników systemu SAP.

Ogólne omówienie wymaganych kroków

Aby wdrożyć konfigurację ibm Db2, należy wykonać następujące kroki:

• Planowanie środowiska.
• Wdrażanie maszyn wirtualnych.
• Zaktualizuj system SUSE Linux i skonfiguruj systemy plików.
• Instalowanie i konfigurowanie programu Pacemaker.
• Zainstaluj system plików NFS o wysokiej dostępności.
• Zainstaluj usługę ASCS/ERS w oddzielnym klastrze.
• Zainstaluj bazę danych IBM Db2 z opcją rozproszonej/wysokiej dostępności (SWPM).
• Zainstaluj i utwórz pomocniczy węzeł oraz wystąpienie bazy danych, a następnie skonfiguruj usługę HADR.
• Upewnij się, że usługa HADR działa.
• Zastosuj konfigurację programu Pacemaker, aby kontrolować ibm Db2.
• Konfigurowanie usługi Azure Load Balancer.
• Zainstaluj podstawowe i serwery aplikacji dialogowych.
• Sprawdź i dostosuj konfigurację serwerów aplikacji SAP.
• Przeprowadź testy przejścia w tryb failover i przejęcia.

Planowanie infrastruktury platformy Azure na potrzeby hostowania systemu IBM Db2 LUW za pomocą usługi HADR

Przed wykonaniem wdrożenia ukończ proces planowania. Planowanie tworzy podstawy wdrażania konfiguracji bazy danych Db2 z usługą HADR na platformie Azure. Kluczowe elementy, które muszą być częścią planowania usługi IMB Db2 LUW (część bazy danych środowiska SAP) są wymienione w poniższej tabeli:

Aby uzyskać więcej informacji na temat programu Pacemaker systemu Linux na platformie Azure, zobacz Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server na platformie Azure.

Wdrażanie w systemie SUSE Linux

Agent zasobów dla systemu IBM Db2 LUW jest zawarty w systemie SUSE Linux Enterprise Server for SAP Applications. W przypadku konfiguracji opisanej w tym dokumencie należy użyć systemu SUSE Linux Server for SAP Applications. Witryna Azure Marketplace zawiera obraz programu SUSE Enterprise Server for SAP Applications 12, którego można użyć do wdrożenia nowych maszyn wirtualnych platformy Azure. Należy pamiętać o różnych modelach pomocy technicznej lub usług oferowanych przez platformę SUSE za pośrednictwem witryny Azure Marketplace podczas wybierania obrazu maszyny wirtualnej w witrynie Azure VM Marketplace.

Hosty: aktualizacje DNS

Utwórz listę wszystkich nazw hostów, w tym nazw hostów wirtualnych, i zaktualizuj serwery DNS, aby umożliwić prawidłowe rozpoznawanie nazw hostów na adresy IP. Jeśli serwer DNS nie istnieje lub nie możesz zaktualizować i utworzyć wpisów DNS, musisz użyć lokalnych plików hosta poszczególnych maszyn wirtualnych uczestniczących w tym scenariuszu. Jeśli używasz wpisów plików hosta, upewnij się, że wpisy są stosowane do wszystkich maszyn wirtualnych w środowisku systemu SAP. Zalecamy jednak użycie usługi DNS, która w idealnym przypadku rozciąga się na platformę Azure

Wdrażanie ręczne

Upewnij się, że wybrany system operacyjny jest obsługiwany przez firmę IBM/SAP dla systemu IBM Db2 LUW. Lista obsługiwanych wersji systemu operacyjnego dla maszyn wirtualnych platformy Azure i wersji Db2 jest dostępna w uwagach sap 1928533. Lista wydań systemu operacyjnego według poszczególnych wersji db2 jest dostępna w macierzy dostępności produktów SAP. Zdecydowanie zalecamy co najmniej system SLES 12 z dodatkiem SP4 ze względu na ulepszenia wydajności związane z platformą Azure w tej lub nowszej wersji systemu SUSE Linux.

1. Utwórz lub wybierz grupę zasobów.
2. Utwórz lub wybierz sieć wirtualną i podsieć.
3. Wybierz odpowiedni typ wdrożenia dla maszyn wirtualnych SAP. Zazwyczaj zestaw skalowania maszyn wirtualnych z elastyczną aranżacją.
4. Utwórz maszynę wirtualną 1.
   1. Użyj protokołu SLES dla obrazu SAP w witrynie Azure Marketplace.
   2. Wybierz zestaw skalowania, strefę dostępności lub zestaw dostępności utworzony w kroku 3.
5. Utwórz maszynę wirtualną 2.
   1. Użyj protokołu SLES dla obrazu SAP w witrynie Azure Marketplace.
   2. Wybierz zestaw skalowania, strefę dostępności lub zestaw dostępności utworzony w kroku 3 (nie tę samą strefę co w kroku 4).
6. Dodaj dyski danych do maszyn wirtualnych, a następnie sprawdź zalecenie konfiguracji systemu plików w artykule IBM Db2 Azure Virtual Machines DBMS deployment for SAP workload (Wdrażanie programu DBMS maszyn wirtualnych platformy AZURE w usłudze IBM Db2 Azure Virtual Machines dla obciążenia SAP).

Instalowanie środowiska IBM Db2 LUW i SAP

Przed rozpoczęciem instalacji środowiska SAP opartego na systemie IBM Db2 LUW zapoznaj się z następującą dokumentacją:

• Dokumentacja platformy Azure
• Dokumentacja oprogramowania SAP
• Dokumentacja firmy IBM

Linki do tej dokumentacji znajdują się w sekcji wprowadzającej tego artykułu.

Zapoznaj się z podręcznikami instalacji oprogramowania SAP dotyczącymi instalowania aplikacji opartych na oprogramowaniu NetWeaver w systemie IBM Db2 LUW.

Przewodniki można znaleźć w portalu pomocy sap, korzystając z narzędzia SAP Installation Guide Finder.

Liczbę przewodników wyświetlanych w portalu można zmniejszyć, ustawiając następujące filtry:

• Chcę: "Zainstaluj nowy system"
• Moja baza danych: "IBM Db2 for Linux, Unix i Windows"
• Dodatkowe filtry dla wersji oprogramowania SAP NetWeaver, konfiguracji stosu lub systemu operacyjnego

Wskazówki dotyczące instalacji IBM Db2 LUW z funkcją HADR

Aby skonfigurować podstawowe wystąpienie bazy danych IBM Db2 LUW:

• Skorzystaj z opcji wysokiej dostępności lub opcji rozproszonej.
• Zainstaluj wystąpienie SAP ASCS/ERS i bazy danych.
• Utwórz kopię zapasową nowo zainstalowanej bazy danych.

Aby skonfigurować serwer bazy danych rezerwowej przy użyciu procedury kopiowania homogenicznego systemu SAP, wykonaj następujące kroki:

1. Wybierz opcję Kopiowanie systemu>systemów docelowych>rozproszona>instancja bazy danych.

2. Jako metodę kopiowania wybierz opcję Homogeniczny system, aby móc użyć kopii zapasowej do przywrócenia danych na zrezerwowanym wystąpieniu serwera.

3. Po ukończeniu etapu przywracania bazy danych dla jednorodnej kopii systemu, wyjdź z instalatora. Przywróć bazę danych z kopii zapasowej hosta podstawowego. Wszystkie kolejne fazy instalacji zostały już wykonane na podstawowym serwerze bazy danych.

4. Konfigurowanie usługi HADR dla ibm Db2.

   Note

   W przypadku instalacji i konfiguracji specyficznej dla platformy Azure i programu Pacemaker: podczas procedury instalacji za pośrednictwem programu SAP Software Provisioning Manager istnieje jawne pytanie dotyczące wysokiej dostępności systemu IBM Db2 LUW:

   • Nie wybieraj IBM Db2 pureScale.
   • Nie wybieraj opcji Zainstaluj IBM Tivoli System Automation dla wielu platform.
   • Nie wybieraj pozycji Generuj pliki konfiguracji klastra.

W przypadku korzystania z urządzenia SBD dla programu Linux Pacemaker ustaw następujące parametry usługi HADR Db2:

• Czas trwania okna partnera usługi HADR (w sekundach) (HADR_PEER_WINDOW) = 300
• Wartość limitu czasu usługi HADR (HADR_TIMEOUT) = 60

W przypadku korzystania z agenta ogrodzenia usługi Azure Pacemaker ustaw następujące parametry:

• Czas trwania okna równorzędnego usługi HADR (w sekundach) (HADR_PEER_WINDOW) = 900
• Wartość limitu czasu usługi HADR (HADR_TIMEOUT) = 60

Zalecamy poprzednie parametry na podstawie początkowego testowania trybu failover/przejęcia. Wymagane jest przetestowanie prawidłowej funkcjonalności failover i takeover przy użyciu tych parametrów. Ponieważ poszczególne konfiguracje mogą się różnić, parametry mogą wymagać dostosowania.

W celach demonstracyjnych i procedurach opisanych w tym artykule identyfikator SID bazy danych to PTR.

Sprawdzanie usługi HADR IBM Db2

Po skonfigurowaniu usługi HADR i gdy stan tych węzłów to PEER i CONNECTED na węzłach głównych i rezerwowych, wykonaj następujące sprawdzanie:

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

Konfigurowanie modułu Azure Load Balancer

Podczas konfigurowania maszyny wirtualnej masz możliwość utworzenia nowego lub wybrania istniejącego modułu równoważenia obciążenia w sekcji sieciowej. Wykonaj poniższe kroki, aby skonfigurować standardowy moduł równoważenia obciążenia na potrzeby konfiguracji bazy danych DB2 o wysokiej dostępności.

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

Tworzenie klastra Pacemaker

Aby utworzyć podstawowy klaster Pacemaker dla tego serwera IBM Db2, zobacz Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server na platformie Azure.

Konfiguracja programu Pacemaker Db2

Jeśli używasz Pacemaker do automatycznego przełączania awaryjnego w przypadku awarii węzła, należy odpowiednio skonfigurować instancje Db2 i Pacemaker. W tej sekcji opisano ten typ konfiguracji.

Następujące elementy są poprzedzone prefiksem:

• [A]: Dotyczy wszystkich węzłów
• [1]: Dotyczy tylko węzła 1
• [2]: Dotyczy tylko węzła 2

[A] Wymagania wstępne dotyczące konfiguracji programu Pacemaker:

• Zamknij oba serwery baz danych jako użytkownik db2<sid> przy użyciu db2stop.
• Zmień środowisko powłoki dla użytkownika db2<sid> na /bin/ksh. Zalecamy użycie narzędzia Yast.

Konfiguracja programu Pacemaker

1. [1] Konfiguracja narzędzia Pacemaker specyficznego dla usługi HADR firmy IBM Db2:

   # Put Pacemaker into maintenance mode
   sudo crm configure property maintenance-mode=true
   

2. [1] Tworzenie zasobów 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
   

3. [1] Uruchamianie zasobów IBM Db2:

   Wyjmij program Pacemaker z trybu konserwacji.

   # Put Pacemaker out of maintenance-mode - that start IBM Db2
   sudo crm configure property maintenance-mode=false
   

4. [1] Upewnij się, że stan klastra jest prawidłowy i że wszystkie zasoby są uruchomione. Nie jest ważne, na którym węźle pracują zasoby.

   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 ]
   

Wprowadzanie zmian w profilach SAP w celu używania wirtualnego adresu IP na potrzeby połączenia

Aby nawiązać połączenie z podstawowym wystąpieniem konfiguracji HADR, warstwa aplikacji SAP musi używać adresu IP wirtualnego zdefiniowanego i skonfigurowanego dla Azure Load Balancer. Wymagane są następujące zmiany:

/sapmnt/<SID>/profile/DEFAULT.PFL

SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname

/sapmnt/<SID>/global/db6/db2cli.ini

Hostname=db-virt-hostname

Instalowanie serwerów aplikacji podstawowych i dialogowych

Podczas instalowania serwerów aplikacyjnych głównych i dialogowych w odniesieniu do konfiguracji Db2 HADR użyj nazwy hosta wirtualnego wybranej dla konfiguracji.

Jeśli instalacja została wykonana przed utworzeniem konfiguracji db2 HADR, wprowadź zmiany zgodnie z opisem w poprzedniej sekcji i w następujący sposób dla stosów SAP Java.

Sprawdzanie adresu URL JDBC w systemach stosu ABAP+Java lub Java

Użyj narzędzia J2EE Config, aby sprawdzić lub zaktualizować adres URL JDBC. Ponieważ narzędzie Config J2EE jest narzędziem graficznym, musisz mieć zainstalowany serwer X:

1. Zaloguj się do głównego serwera aplikacyjnego instancji J2EE i wykonaj:

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

2. W lewej ramce wybierz security store.

3. W prawej ramce wybierz klucz jdbc/pool/<SAPSID>/url.

4. Zmień nazwę hosta w adresie URL JDBC na nazwę hosta wirtualnego.

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

5. Wybierz Dodaj.

6. Aby zapisać zmiany, wybierz ikonę dysku w lewym górnym rogu.

7. Zamknij narzędzie konfiguracji.

8. Uruchom ponownie instancję Java.

Konfigurowanie archiwizowania dzienników dla konfiguracji usługi HADR

Aby skonfigurować archiwizowanie dzienników db2 dla konfiguracji usługi HADR, zalecamy skonfigurowanie zarówno podstawowej, jak i rezerwowej bazy danych w celu automatycznego pobierania dzienników ze wszystkich lokalizacji archiwum dzienników. Zarówno podstawowa, jak i rezerwowa baza danych musi mieć możliwość pobierania plików archiwum dziennika ze wszystkich lokalizacji archiwum dziennika, do których jeden z wystąpień bazy danych może archiwizować pliki dziennika.

Archiwizacja dziennika jest wykonywana tylko przez podstawową bazę danych. Jeśli zmienisz role usługi HADR serwerów baz danych lub wystąpi awaria, nowa podstawowa baza danych jest odpowiedzialna za archiwizowanie dzienników. Jeśli skonfigurowano wiele lokalizacji archiwum dzienników, dzienniki mogą być archiwizowane dwa razy. W przypadku lokalnego lub zdalnego nadrobienia zaległości może być również konieczne ręczne skopiowanie zarchiwizowanych dzienników ze starego serwera podstawowego do aktywnej lokalizacji dziennika nowego serwera podstawowego.

Zalecamy skonfigurowanie wspólnego udziału NFS, w którym dzienniki są zapisywane z obu węzłów. Udział NFS musi być wysoce dostępny.

Istniejące udziały NFS o wysokiej dostępności można wykorzystać do transportów lub jako katalog profilu. Aby uzyskać więcej informacji, zobacz:

• Wysoka dostępność systemu plików NFS na maszynach wirtualnych platformy Azure na serwerze SUSE Linux Enterprise Server.
• Wysoka dostępność oprogramowania SAP NetWeaver na maszynach wirtualnych platformy Azure na serwerze SUSE Linux Enterprise Server z usługą Azure NetApp Files for SAP Applications.
• Azure NetApp Files (w celu utworzenia udziałów NFS).

Testowanie konfiguracji klastra

W tej sekcji opisano sposób testowania konfiguracji usługi HADR db2. Każdy test zakłada, że użytkownik jest zalogowany jako użytkownik główny , a podstawowa baza danych IBM Db2 jest uruchomiona na maszynie wirtualnej azibmdb01 .

Początkowy stan wszystkich przypadków testowych jest opisany tutaj: (crm_mon -r lub crm status)

• Status CRM to fotografia stanu programu Pacemaker w momencie wykonywania.
• crm_mon -r zapewnia ciągłe wyświetlanie stanu Pacemaker.

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 ]

Oryginalny stan w systemie SAP jest udokumentowany w transakcji DBACOCKPIT > Configuration > Overview, jak pokazano na poniższej ilustracji:

Testowe przejęcie IBM Db2

Przeprowadź migrację węzła, w którym działa podstawowa baza danych Db2, wykonując następujące polecenie:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

Po zakończeniu migracji dane wyjściowe stanu crm wyglądają następująco:

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 ]

Oryginalny stan w systemie SAP jest udokumentowany w temacie Transaction DBACOCKPIT Configuration Overview (Omówienie konfiguracji > DBACOCKPIT > transakcji), jak pokazano na poniższej ilustracji:

Migracja zasobów przy użyciu polecenia "crm resource migrate" powoduje utworzenie ograniczeń lokalizacyjnych. Należy usunąć ograniczenia lokalizacji. Jeśli ograniczenia lokalizacji nie zostaną usunięte, zasób nie może powrócić do poprzedniego stanu operacyjnego lub może wystąpić niepożądane przejęcia kontroli.

Przeprowadź migrację zasobu z powrotem do bazy danych azibmdb01 i wyczyść ograniczenia lokalizacji

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR

• Migracja zasobów CRM <res_name><host>: tworzy ograniczenia lokalizacji i może powodować problemy z przejęciem sterowania
• czyść zasób crm <res_name>: usuwa ograniczenia lokalizacji
• czyszczenie zasobów crm <res_name>: czyści wszystkie błędy zasobu

Testowanie ogrodzenia SBD

W takim przypadku testujemy ogrodzenie SBD, które zalecamy w przypadku korzystania z systemu SUSE Linux.

azibmdb01:~ # ps -ef|grep sbd
root       2374      1  0 Feb05 ?        00:00:17 sbd: inquisitor
root       2378   2374  0 Feb05 ?        00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root       2379   2374  0 Feb05 ?        00:01:51 sbd: watcher: Pacemaker
root       2380   2374  0 Feb05 ?        00:00:18 sbd: watcher: Cluster

azibmdb01:~ # kill -9 2374

Należy ponownie uruchomić węzeł klastra azibmdb01 . Podstawowa rola HADR ibm Db2 zostanie przeniesiona do azibmdb02. Gdy azibmdb01 będzie znowu online, wystąpienie Db2 zostanie przeniesione do roli pomocniczego wystąpienia bazy danych.

Jeśli usługa Pacemaker nie uruchamia się automatycznie po ponownym uruchomieniu wcześniejszego głównego serwera, pamiętaj, aby uruchomić ją ręcznie za pomocą:

sudo service pacemaker start

Testowanie ręcznego przejęcia

Ręczne przejęcie można przetestować, zatrzymując usługę Pacemaker na węźle azibmdb01:

service pacemaker stop

stan 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 przełączeniu awaryjnym możesz ponownie uruchomić usługę na azibmdb01.

service pacemaker start

Zabij proces Db2 w węźle, w ramach którego jest uruchamiana podstawowa baza danych 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

Instancja Db2 ulegnie awarii, a program Pacemaker zgłosi następujący stan:

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

Program Pacemaker ponownie uruchamia podstawowe wystąpienie bazy danych Db2 w tym samym węźle lub przechodzi w tryb failover do węzła, w którym uruchomiono wystąpienie pomocniczej bazy danych, a zgłaszany jest błąd.

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

Zabij proces Db2 w węźle, w ramach którego uruchomiono wystąpienie pomocniczej bazy danych

azibmdb02:~ # ps -ef|grep db2s
db2ptr    65250  65248  0 Feb11 ?        00:09:27 db2sysc 0

azibmdb02:~ # kill -9

Węzeł przechodzi w stan błędu i zgłoszono błąd.

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

Wystąpienie bazy danych Db2 zostanie uruchomione ponownie w roli pomocniczej, do której przypisano wcześniej.

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

Zatrzymaj bazę danych za pomocą polecenia db2stop force na węźle, na którym działa podstawowe wystąpienie bazy danych 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 użytkownik db2<sid> wykonaj polecenie db2stop force:

azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force

Wykryto błąd

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

Instancja zapasowej bazy danych Db2 HADR została awansowana do roli podstawowej.

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

Zawieszenie się maszyny wirtualnej z ponownym uruchomieniem na węźle, który uruchamia podstawowe wystąpienie bazy danych HADR

#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger

Program Pacemaker promuje instancję pomocniczą do roli instancji podstawowej. Stare wystąpienie podstawowe przejdzie do roli pomocniczej po pełnym przywróceniu maszyny wirtualnej i wszystkich usług po ponownym uruchomieniu maszyny wirtualnej.

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 ]

Zawiesz maszynę wirtualną, która uruchamia główne wystąpienie bazy danych HADR, używając 'halt'.

#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger

W takim przypadku program Pacemaker wykrywa, że węzeł z działającą instancją podstawowej bazy danych nie odpowiada.

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 ]

Następnym krokiem jest sprawdzenie sytuacji podzielonego mózgu . Po ustaleniu, że węzeł, który ostatni raz uruchomił wystąpienie podstawowej bazy danych, jest niedostępny, wykonywana jest procedura awaryjnego przełączania zasobów.

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 ]

W przypadku zatrzymania węzła należy ponownie uruchomić węzeł, który uległ awarii za pośrednictwem narzędzi usługi Azure Management (w witrynie Azure Portal, programie PowerShell lub interfejsie wiersza polecenia platformy Azure). Po ponownym uruchomieniu węzła, który uległ awarii, instancja Db2 jest uruchamiana w roli pomocniczej.

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 ]

Dalsze kroki

• Architektura i scenariusze wysokiej dostępności dla oprogramowania SAP NetWeaver
• Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server w ramach platformy Azure