Disponibilità elevata di IBN DB2 LUW in macchine virtuali di Azure su Red Hat Enterprise Linux Server

IBM Db2 per Linux, UNIX e Windows (LUW) nella configurazione della disponibilità elevata e del ripristino di emergenza (HADR) è costituito da un nodo che esegue un'istanza di database primaria e almeno un nodo che esegue un'istanza di database secondaria. Le modifiche apportate all'istanza di database primaria vengono replicate in un'istanza di database secondaria in modo sincrono o asincrono, a seconda della configurazione.

Questo articolo descrive come distribuire e configurare le macchine virtuali di Azure, installare il framework del cluster e installare IBM Db2 LUW con la configurazione HADR.

L'articolo non illustra come installare e configurare IBM Db2 LUW con l'installazione di HADR o del software SAP. Per facilitare l'esecuzione di queste attività, vengono forniti riferimenti ai manuali di installazione di SAP e IBM. Questo articolo è incentrato su parti specifiche dell'ambiente Azure.

Le versioni di IBM Db2 supportate sono 10.5 e successive, come documentato nella nota SAP 1928533.

Prima di iniziare un'installazione, vedere le note e la documentazione SAP seguenti:

Panoramica

Per ottenere la disponibilità elevata, IBM Db2 LUW con HADR viene installato in almeno due macchine virtuali di Azure, distribuite in un set di scalabilità di macchine virtuali con orchestrazione flessibile tra le zone di disponibilità o in un set di disponibilità.

Nella grafica seguente viene mostrata una configurazione di due macchine virtuali di Azure del server di database. Entrambe le macchine virtuali di Azure del server di database hanno una propria risorsa di archiviazione collegata e sono attive e in esecuzione. In HADR, un'istanza di database in una delle macchine virtuali di Azure ha il ruolo di istanza primaria. Tutti i client sono connessi all’istanza primaria. Tutte le modifiche apportate alle transazioni del database vengono mantenute in locale nel log delle transazioni di Db2. Poiché i record del log delle transazioni sono persistenti in locale, vengono trasferiti tramite TCP/IP all'istanza di database nel secondo server di database, nel server di standby o nell'istanza di standby. L'istanza di standby aggiorna il database locale eseguendo il roll forward dei record del log delle transazioni trasferiti. In questo modo, il server standby resta sincronizzato con il server primario.

HADR è solo una funzionalità di replica. Non ha la funzione di rilevamento degli errori e né di acquisizione o failover automatici. Un'acquisizione o un trasferimento al server di standby deve essere avviato manualmente da un amministratore di database. Per ottenere le funzioni automatiche di rilevamento degli errori e acquisizione, è possibile usare la funzionalità di clustering di Linux Pacemaker. Pacemaker monitora le due istanze del server di database. Quando l'istanza del server di database primaria si arresta in modo anomalo, Pacemaker avvia un'acquisizione HADR automatica dal server di standby. Pacemaker garantisce anche che l'indirizzo IP virtuale sia assegnato al nuovo server primario.

Per fare in modo che i server applicazioni SAP si connettano al database primario, sono necessari un nome host virtuale e un indirizzo IP virtuale. Dopo un failover, i server applicazioni SAP si connettono alla nuova istanza di database primaria. In un ambiente Azure è necessario un servizio di bilanciamento del carico di Azure per usare un indirizzo IP virtuale nel modo richiesto da HADR di IBM Db2.

Per illustrare al meglio il modo in cui IBM Db2 LUW con HADR e Pacemaker si adatta a una configurazione del sistema SAP a disponibilità elevata, l'immagine seguente presenta una panoramica di una configurazione a disponibilità elevata di un sistema SAP basato sul database IBM Db2. Questo articolo illustra solo IBM Db2, ma fornisce riferimenti ad altri articoli su come configurare altri componenti di un sistema SAP.

Panoramica generale dei passaggi necessari

Per distribuire una configurazione di IBM Db2, è necessario seguire questa procedura:

• Pianificare l'ambiente.
• Distribuire le macchine virtuali.
• Aggiornare RHEL Linux e configurare i file system.
• Installare e configurare Pacemaker.
• Configurare cluster glusterfs o Azure NetApp Files
• Installare ASCS/ERS in un cluster separato.
• Installare il database IBM Db2 con l'opzione Distribuito/Disponibilità elevata (SWPM).
• Installare e creare un nodo e un'istanza di database secondari e configurare HADR.
• Verificare che HADR funzioni.
• Applicare la configurazione di Pacemaker per controllare IBM Db2.
• Configurare Azure Load Balancer.
• Installare i server applicazioni primari e con finestre di dialogo.
• Controllare e adattare la configurazione dei server applicazioni SAP.
• Eseguire test di failover e acquisizione.

Pianificare l'infrastruttura di Azure per l'hosting di IBM Db2 LUW con HADR

Completare il processo di pianificazione prima di eseguire la distribuzione. La pianificazione crea le basi per la distribuzione di una configurazione di Db2 con HADR in Azure. Gli elementi chiave che devono far parte della pianificazione per IMB Db2 LUW (database parte dell'ambiente SAP) sono elencati nella tabella seguente:

Per altre informazioni su Linux Pacemaker in Azure, vedere Configurazione di Pacemaker su Red Hat Enterprise Linux in Azure.

Distribuzione in Red Hat Enterprise Linux

L'agente di risorse per IBM Db2 LUW è incluso in Red Hat Enterprise Linux con componenti aggiuntivi a disponibilità elevata. Per la configurazione descritta in questo documento, è consigliabile usare Red Hat Enterprise Linux per SAP. Azure Marketplace contiene un'immagine per Red Hat Enterprise Linux 7.4 per SAP o versione successiva che è possibile usare per distribuire nuove macchine virtuali di Azure. Tenere presente i vari modelli di supporto o di servizio offerti da Red Hat tramite Azure Marketplace quando si sceglie un'immagine della macchina virtuale nel marketplace della macchina virtuale Azure.

Host: aggiornamenti del DNS

Creare un elenco di tutti i nomi host, inclusi i nomi host virtuali e aggiornare i server DNS per abilitare l'indirizzo IP corretto per la risoluzione dei nomi host. Se un server DNS non esiste o non è possibile aggiornare e creare voci DNS, è necessario usare i file host locali delle singole macchine virtuali che partecipano a questo scenario. Se si usano voci di file host, assicurarsi che le voci vengano applicate a tutte le macchine virtuali nell'ambiente del sistema SAP. È tuttavia consigliabile usare il DNS che, idealmente, si estende in Azure

Distribuzione manuale

Assicurarsi che il sistema operativo selezionato sia supportato da IBM/SAP per IBM Db2 LUW. L'elenco delle versioni del sistema operativo supportate per le macchine virtuali di Azure e le versioni di Db2 è disponibile nella nota SAP 1928533. L'elenco delle versioni del sistema operativo in base alla singola versione di Db2 è disponibile nel documento Product Availability Matrix di SAP. È consigliabile usare almeno Red Hat Enterprise Linux 7.4 per SAP a causa di miglioramenti delle prestazioni correlati ad Azure in questa o nelle versioni successive di Red Hat Enterprise Linux.

1. Creare o selezionare un gruppo di risorse.
2. Creare o selezionare una rete virtuale e una subnet.
3. Scegliere un tipo di distribuzione appropriato per le macchine virtuali SAP. In genere, un set di scalabilità di macchine virtuali con orchestrazione flessibile.
4. Creare la macchina virtuale 1.
   1. Usare l'immagine Red Hat Enterprise Linux per SAP in Azure Marketplace.
   2. Selezionare il set di scalabilità, la zona di disponibilità o il set di disponibilità creato nel passaggio 3.
5. Creare la macchina virtuale 2.
   1. Usare l'immagine Red Hat Enterprise Linux per SAP in Azure Marketplace.
   2. Selezionare il set di scalabilità, la zona di disponibilità o il set di disponibilità creato nel passaggio 3 (non la stessa zona del passaggio 4).
6. Aggiungere i dischi dati alle macchine virtuali e successivamente consultare le raccomandazioni sulla configurazione del file system nell'articolo Distribuzione DBMS per IBM Db2 di macchine virtuali di Azure per un carico di lavoro SAP.

Installare IBM Db2 LUW e l'ambiente SAP

Prima di avviare l'installazione di un ambiente SAP basato su IBM Db2 LUW, vedere la documentazione seguente:

• Documentazione di Azure.
• Documentazione SAP.
• Documentazione IBM.

I collegamenti a questa documentazione sono disponibili nella sezione introduttiva di questo articolo.

Controllare i manuali di installazione SAP sull'installazione di applicazioni basate su NetWeaver in IBM Db2 LUW. È possibile trovare le guide nel portale della guida SAP usando lo strumento di ricerca della guida all'installazione SAP.

È possibile ridurre il numero di guide visualizzate nel portale impostando i filtri seguenti:

• Voglio: installare un nuovo sistema.
• Database personale: IBM Db2 per Linux, Unix e Windows.
• Altri filtri per le versioni di SAP NetWeaver, la configurazione dello stack o il sistema operativo.

Regole del firewall Red Hat

Red Hat Enterprise Linux ha il firewall abilitato per impostazione predefinita.

#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp

Hint di installazione per la configurazione di IBM Db2 LUW con HADR

Per configurare l'istanza primaria del database IBM Db2 LUW:

• Usare l'opzione per High availability o Distributed.
• Installare SAP ASCS/ERS e l'istanza di database.
• Eseguire un backup del database appena installato.

Impostazioni di IBM Db2 HADR per Azure

Quando si usa un agente di isolamento Pacemaker per Azure, impostare i parametri seguenti:

• Durata della finestra HADR peer (secondi) (HADR_PEER_WINDOW) = 240
• Valore di timeout HADR (HADR_TIMEOUT) = 45

È consigliabile usare i parametri precedenti in base ai test iniziali di failover/acquisizione. È obbligatorio verificare che il failover e l'acquisizione funzionino correttamente con queste impostazioni dei parametri. Poiché le singole configurazioni possono variare, i parametri potrebbero richiedere modifiche.

Per configurare il server di database Standby usando la procedura di copia omogenea del sistema SAP, eseguire questi passaggi:

1. Selezionare l'opzione System copy >Target systems>Distributed>Database instance.
2. Come metodo di copia, selezionare Homogeneous System in modo da poter usare il backup per ripristinare un backup nell'istanza del server di standby.
3. Quando si raggiunge il passaggio di uscita per ripristinare il database per la copia di sistema omogenea, uscire dal programma di installazione. Ripristinare il database da un backup dell'host primario. Tutte le fasi di installazione successive sono già state eseguite nel server di database primario.

Regole del firewall Red Hat per DB2 HADR

Aggiungere regole del firewall per consentire il funzionamento del traffico verso DB2 e tra DB2 per HADR:

• Porta di comunicazione del database. Se si usano partizioni, aggiungere anche queste porte.
• Porta HADR (valore del parametro DB2 HADR_LOCAL_SVC).
• Porta probe di Azure.

sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload

Controllo di HADR IBM Db2

A scopo dimostrativo e per le procedure descritte in questo articolo, il SID del database è ID2.

Dopo aver configurato HADR e quando lo stato è PEER e CONNECTED nei nodi primario e di standby, eseguire il controllo seguente:

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

Configurare Azure Load Balancer

Durante la configurazione della macchina virtuale, è possibile creare o selezionare il servizio di bilanciamento del carico esistente nella sezione Rete. Seguire questa procedura per configurare il servizio di bilanciamento del carico standard per la configurazione a disponibilità elevata del database DB2.

# 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

[A] Aggiungere una regola del firewall per la porta probe:

sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload

Creare il cluster Pacemaker

Per creare un cluster Pacemaker di base per questo server IBM Db2, vedere Configurazione di Pacemaker su Red Hat Enterprise Linux in Azure.

Configurazione di Db2 Pacemaker

Quando si usa Pacemaker per il failover automatico in caso di errore del nodo, è necessario configurare di conseguenza le istanze di Db2 e Pacemaker. Questa sezione descrive questo tipo di configurazione.

Gli elementi seguenti sono preceduti da uno degli elementi seguenti:

• [A]: applicabile a tutti i nodi
• [1]: applicabile solo al nodo 1
• [1]: applicabile solo al nodo 2

[A] Prerequisito per la configurazione di Pacemaker:

• Arrestare entrambi i server di database con l'utente db2<sid> con db2stop.

• Modificare l'ambiente della shell per l'utente db2<sid> in /bin/ksh:

  # Install korn shell:
  sudo yum install ksh
  # Change users shell:
  sudo usermod -s /bin/ksh db2<sid>
  

Configurazione di Pacemaker

1. [1] Configurazione di Pacemaker specifica per IBM Db2 HADR:

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

2. [1] Creare risorse IBM Db2:

   Se si compila un cluster in RHEL 7.x, assicurarsi di aggiornare il pacchetto di agenti di risorse alla versione resource-agents-4.1.1-61.el7_9.15 o versione successiva. Usare i comandi seguenti per creare le risorse del cluster:

   # 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
   

   Se si compila un cluster in RHEL 8.x, assicurarsi di aggiornare il pacchetto di agenti di risorse alla versione resource-agents-4.1.1-93.el8 o versione successiva. Per informazioni dettagliate, vedere Red Hat KBA db2 risorsa con HADR non viene promosso con stato PRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. Usare i comandi seguenti per creare le risorse del cluster:

   # 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] Avviare le risorse IBM Db2:

   Mettere Pacemaker in modalità Fuori manutenzione.

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

4. [1] Assicurarsi che lo stato del cluster sia corretto e che tutte le risorse siano avviate. Non è importante il nodo su cui sono in esecuzione le risorse.

   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
   

Apportare modifiche ai profili SAP per usare l'indirizzo IP virtuale per la connessione

Per connettersi all'istanza primaria della configurazione HADR, il livello dell'applicazione SAP deve usare l'indirizzo IP virtuale definito e configurato per Azure Load Balancer. Sono necessarie le modifiche seguenti:

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

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

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

Hostname=db-virt-hostname

Installare i server applicazioni primari e con finestre di dialogo

Quando si installano server applicazioni primari e con finestre di dialogo in una configurazione Db2 HADR, usare il nome host virtuale scelto per la configurazione.

Se l'installazione è stata eseguita prima di creare la configurazione Db2 HADR, apportare le modifiche come descritto nella sezione precedente e come indicato di seguito per gli stack Java di SAP.

Controllo dell'URL JDBC per i sistemi stack ABAP+Java o Java

Usare lo strumento di configurazione J2EE per controllare o aggiornare l'URL JDBC. Poiché lo strumento di configurazione J2EE è uno strumento grafico, è necessario che sia installato il server X:

1. Accedere al server applicazioni primario dell'istanza di J2EE ed eseguire:

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

2. Nel riquadro sinistro scegliere archivio di sicurezza.

3. Nella cornice destra scegliere il tasto jdbc/pool/\<SAPSID>/url.

4. Modificare il nome host nell'URL JDBC impostando il nome host virtuale.

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

5. Selezionare Aggiungi.

6. Per salvare le modifiche, selezionare l'icona del disco in alto a sinistra.

7. Chiudere lo strumento di configurazione.

8. Riavviare l'istanza di Java.

Configurare l'archiviazione dei log per la configurazione di HADR

Per configurare l'archiviazione dei log Db2 per la configurazione di HADR, è consigliabile configurare sia il database primario che il database di standby in modo che dispongano della funzionalità di recupero automatico dei log da tutte le posizioni di archiviazione dei log. Sia il database primario che quello di standby devono essere in grado di recuperare i file di archivio dei log da tutte le posizioni di archiviazione dei log in cui una delle istanze di database potrebbe archiviare i file di log.

L'archiviazione dei log viene eseguita solo dal database primario. Se si modificano i ruoli HADR dei server di database o se si verifica un errore, il nuovo database primario è responsabile dell'archiviazione dei log. Se sono state configurate più posizioni di archiviazione dei log, i log potrebbero essere archiviati due volte. In caso di recupero locale o remoto, potrebbe anche essere necessario copiare manualmente i log archiviati dal server primario precedente nel percorso del log attivo del nuovo server primario.

È consigliabile configurare una condivisione NFS comune o GlusterFS, in cui i log vengono scritti da entrambi i nodi. La condivisione NFS o GlusterFS deve essere a disponibilità elevata.

È possibile usare le condivisioni NFS a disponibilità elevata o GlusterFS esistenti per i trasporti o per una directory del profilo. Per altre informazioni, vedi:

• GlusterFS in macchine virtuali di Azure in Red Hat Enterprise Linux per SAP NetWeaver.
• Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure su Red Hat Enterprise Linux con Azure NetApp Files per applicazioni SAP.
• Azure NetApp Files (per creare condivisioni NFS).

Testare la configurazione del cluster

Questa sezione descrive come testare la configurazione Db2 HADR. Ogni test presuppone che IBM Db2 primario sia in esecuzione nella macchina virtuale az-idb01. È necessario usare un utente con privilegi sudo o root (non consigliato).

Lo stato iniziale per tutti i test case è illustrato qui: (crm_mon -r o stato pcs)

• stato pcs è uno snapshot dello stato di Pacemaker in fase di esecuzione.
• crm_mon -r è l'output continuo dello stato di Pacemaker.

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

Lo stato originale in un sistema SAP è documentato in Transaction DBACOCKPIT > Configuration > Overview, come illustrato nell'immagine seguente:

Acquisizione di test di IBM Db2

Eseguire la migrazione del nodo che esegue il database Db2 primario eseguendo il comando seguente:

# 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

Al termine della migrazione, l'output di crm status è simile al seguente:

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

Lo stato originale in un sistema SAP è documentato in Transaction DBACOCKPIT > Configuration > Overview, come illustrato nell'immagine seguente:

La migrazione delle risorse con "pcs resource move" crea vincoli di posizione. In questo caso, i vincoli di posizione impediscono l'esecuzione dell'istanza IBM Db2 in az-idb01. Se i vincoli di posizione non vengono eliminati, la risorsa non può eseguire il failback.

Se si rimuove il vincolo di posizione, il nodo standby verrà avviato in 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

E lo stato del cluster cambia in:

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

Eseguire di nuovo la migrazione della risorsa in az-idb01 e cancellare i vincoli di posizione

# 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

• In RHEL 7.x - pcs resource move <resource_name> <host>: crea vincoli di posizione e può causare problemi con l'acquisizione
• In RHEL 8.x - pcs resource move <resource_name> --master: crea vincoli di posizione e può causare problemi con l'acquisizione
• pcs resource clear <resource_name>: cancella i vincoli delle località
• pcs resource cleanup <resource_name>: cancella tutti gli errori della risorsa

Testare un'acquisizione manuale

È possibile testare un'acquisizione manuale arrestando il servizio Pacemaker nel nodo az-idb01:

systemctl stop pacemaker

stato in 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

Dopo il failover, è possibile avviare nuovamente il servizio in az-idb01.

systemctl start  pacemaker

Terminare il processo Db2 nel nodo che esegue il database primario 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

L'istanza Db2 ha esito negativo e Pacemaker sposterà il nodo master e segnalerà lo stato seguente:

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 riavvia l'istanza di database primaria Db2 nello stesso nodo oppure esegue il failover nel nodo che esegue l'istanza di database secondaria e viene segnalato un errore.

Terminare il processo Db2 nel nodo che esegue l'istanza di database secondaria

[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

Il nodo si trova in uno stato di operazione non riuscita e viene segnalato un errore.

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

L'istanza Db2 viene riavviata nel ruolo secondario assegnato in precedenza.

Arrestare il database tramite db2stop force sul nodo che esegue l'istanza di database primario HADR

Come utente db2<sid> eseguire il comando db2stop force:

az-idb01:db2ptr> db2stop force

Errore rilevato:

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

L'istanza di database secondaria Db2 HADR è stata alzata di livello nel ruolo primario.

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

Arrestare in modo anomalo la macchina virtuale che esegue l'istanza di database primaria HADR con "halt"

#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger

In questo caso Pacemaker rileva che il nodo che esegue l'istanza di database primaria non risponde.

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

Il passaggio successivo consiste nel verificare la presenza di una situazione Split brain. Dopo che il nodo integro ha determinato che il nodo che ha eseguito per ultimo l'istanza di database primaria è inattivo, viene eseguito un failover delle risorse.

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

In caso di Kernel panic, il nodo guasto verrà riavviato dall'agente di isolamento. Dopo che il nodo non riuscito è di nuovo online, è necessario avviare il cluster pacemaker tramite

sudo pcs cluster start

avvia l'istanza Db2 nel ruolo secondario.

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

Passaggi successivi

• Architettura e scenari di disponibilità elevata per SAP NetWeaver
• Configurazione di Pacemaker in Red Hat Enterprise Linux in Azure