Alta disponibilidade do IBM Db2 LUW nas VMs do Azure no SUSE Linux Enterprise Server com o Pacemaker

O IBM Db2 para Linux, UNIX e Windows (LUW) na configuração de HADR (alta disponibilidade e recuperação de desastres) consiste em um nó que executa uma instância do banco de dados primário e m pelo menos um nó que executa uma instância do banco de dados secundário. As alterações na instância do banco de dados primário são replicadas para uma instância de banco de dados secundário de modo síncrono ou assíncrono, dependendo da sua configuração.

Este artigo descreve como implantar e configurar as VMs (máquinas virtuais) do Azure, instalar a estrutura de cluster e instalar o IBM Db2 LUW com a configuração da HADR.

O artigo não aborda como instalar e configurar o IBM Db2 LUW com HADR ou a instalação do software SAP. Para ajudar você a realizar essas tarefas, fornecemos referências aos manuais de instalação do SAP e da IBM. Este artigo se concentra em partes específicas ao ambiente do Azure.

As versões do IBM Db2 com suporte são 10.5 e posteriores, conforme documentado na nota do SAP 1928533.

Antes de iniciar uma instalação, confira as seguintes notas e documentação do SAP:

Visão geral

Para obter alta disponibilidade, o IBM Db2 LUW com HADR é instalado em pelo menos duas máquinas virtuais do Azure, que são implantadas em um conjunto de escala de máquina virtual com orquestração flexível em zonas de disponibilidade ou em um conjunto de disponibilidade.

Os gráficos a seguir exibem uma configuração de duas VMs do Azure do servidor de banco de dados. Ambas as VMs do Azure do servidor de banco de dados têm o próprio armazenamento anexado e estão em execução. Na HADR, uma instância de banco de dados em uma das VMs do Azure tem a função da instância primária. Todos os clientes estão conectados a esta instância primária. Todas as alterações nas transações de banco de dados são persistidas localmente no log de transações do Db2. Como os registros de log de transações são persistidos localmente, os registros são transferidos via TCP/IP para a instância do banco de dados no segundo servidor de banco de dados, no servidor em espera ou na instância em espera. A instância em espera atualiza o banco de dados local efetuando roll forward dos registros de log de transações transferidos. Dessa forma, o servidor em espera é mantido em sincronia com o servidor primário.

A HADR é apenas uma funcionalidade de replicação. Ele não tem detecção de falha e nenhum recurso automático de failover ou tomada de controle. Uma tomada de controle ou transferência para o servidor em espera precisa ser iniciada manualmente por um administrador de banco de dados. Para obter uma detecção automática de falha e tomada de controle, você pode usar o recurso de clustering do Linux Pacemaker. O Pacemaker monitora as duas instâncias de servidor de banco de dados. Quando a instância do servidor de banco de dados primário falha, o Pacemaker inicia uma tomada de controle de HADR automática com o servidor em espera. O Pacemaker também garante que o endereço IP virtual seja atribuído ao novo servidor primário.

Para que os servidores de aplicativos SAP se conectem ao banco de dados primário, você precisará de um nome do host virtual e de um endereço IP virtual. Após um failover, os servidores de aplicativos SAP se conectam à nova instância de banco de dados primária. Em um ambiente do Azure, um balanceador de carga do Azure precisa usar um endereço IP virtual da maneira exigida para a HADR do IBM Db2.

Para ajudar você a entender totalmente como o IBM Db2 LUW com HADR e o Pacemaker se encaixa em uma configuração de sistema SAP altamente disponível, a imagem a seguir apresenta uma visão geral de uma configuração altamente disponível de um sistema SAP com base no banco de dados IBM Db2. Este artigo aborda apenas o IBM Db2, mas faz referência a outros artigos que abordam como configurar outros componentes de um sistema SAP.

Visão geral de alto nível das etapas necessárias

Para implantar uma configuração do IBM Db2, você precisa seguir estas etapas:

• Planeje o seu ambiente.
• Implante as VMs.
• Atualize o SUSE Linux e configure os sistemas de arquivos.
• Instale e configure o Pacemaker.
• Instale o NFS altamente disponível.
• Instale o ASCS/ERS em um cluster separado.
• Instale o banco de dados IBM Db2 com a opção Distribuído/Alta Disponibilidade (SWPM) selecionada.
• Instale e crie um nó de banco de dados secundário e uma instância e configure a HADR.
• Confirme se a HADR está funcionando.
• Aplique a configuração do Pacemaker para controlar o IBM Db2.
• Configure o Azure Load Balancer.
• Instale os servidores de aplicativo primário e de diálogo.
• Verifique e adapte a configuração dos servidores de aplicativos SAP.
• Execute testes de failover e de tomada de controle.

Planejar a infraestrutura do Azure para hospedar o IBM Db2 LUW com HADR

Conclua o processo de planejamento antes de executar a implantação. O planejamento cria a base para implantar uma configuração do Db2 com HADR no Azure. Os elementos principais que precisam fazer parte do planejamento do IMB Db2 LUW (parte do banco de dados do ambiente SAP) estão listados na seguinte tabela:

Para obter mais informações sobre o Linux Pacemaker no Azure, confira Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure.

Implantação no SUSE Linux

O agente de recursos para IBM Db2 LUW está incluído no SUSE Linux Enterprise Server for SAP Applications. Na configuração descrita neste documento, você precisa usar o SUSE Linux Server for SAP Applications. O Azure Marketplace contém uma imagem para SUSE Enterprise Server for SAP Applications 12 que você pode usar para implantar novas máquinas virtuais do Azure. Lembre-se dos vários modelos de suporte ou de serviço que são oferecidos pelo SUSE por meio do Azure Marketplace ao escolher uma imagem de VM no Marketplace da VM do Azure.

Hosts: atualizações de DNS

Faça uma lista de todos os nomes de host, incluindo nomes de host virtuais, e atualize os seus servidores DNS para habilitar o endereço IP apropriado para a resolução de nome de host. Se um servidor DNS não existir ou se não for possível atualizar e criar entradas DNS, será necessário usar os arquivos de host locais das VMs individuais que participam desse cenário. Se você estiver usando entradas de arquivos de host, verifique se as entradas são aplicadas a todas as VMs no ambiente do sistema SAP. No entanto, é recomendável que você use o DNS que, idealmente, inclua o Azure

Implantação manual

Verifique se o sistema operacional selecionado tem suporte no IBM/SAP para IBM Db2 LUW. A lista de versões do sistema operacional com suporte para VMs do Azure e versões do Db2 está disponível na nota do SAP 1928533. A lista de versões do sistema operacional por versão individual do Db2 está disponível na Matriz de Disponibilidade de Produto SAP. É altamente recomendável no mínimo a versão SLES 12 SP4 devido a aprimoramentos de desempenho relacionadas ao Azure nessa ou em versões posteriores do SUSE Linux.

1. Crie ou selecione um grupo de recursos.
2. Crie ou selecione uma rede virtual e uma sub-rede.
3. Escolha um tipo de implantação adequado para máquinas virtuais SAP. Normalmente, um conjunto de dimensionamento de máquinas virtuais com orquestração flexível.
4. Crie a Máquina Virtual 1.
   1. Use a imagem do SLES for SAP no Azure Marketplace.
   2. Selecione o conjunto de escala e zona de disponibilidade ou o conjunto de disponibilidade criado na etapa 3.
5. Crie a Máquina Virtual 2.
   1. Use a imagem do SLES for SAP no Azure Marketplace.
   2. Selecione o conjunto de dimensionamento, a zona de disponibilidade ou o conjunto de disponibilidade criado na etapa 3 (não a mesma zona da etapa 4).
6. Adicione discos de dados às VMs e verifique a recomendação de uma configuração do sistema de arquivos no artigo Implantação do DBMS de Máquinas Virtuais do Azure do IBM Db2 para carga de trabalho do SAP.

Instalar o IBM Db2 LUW e o ambiente SAP

Antes de iniciar a instalação de um ambiente SAP baseado no IBM Db2 LUW, examine a seguinte documentação:

• Documentação do Azure
• Documentação do SAP
• Documentação da IBM

Os links para essa documentação são fornecidos na seção introdutória deste artigo.

Verifique os manuais de instalação do SAP para saber como instalar os aplicativos baseados no NetWeaver no IBM Db2 LUW.

Você pode encontrar os guias no portal de Ajuda do SAP usando o Localizador de Guia de Instalação do SAP.

Você pode reduzir o número de guias exibidos no portal definindo os seguintes filtros:

• Desejo: "Instalar um novo sistema"
• Meu banco de dados: "IBM Db2 para Linux, Unix e Windows"
• Filtros adicionais para as versões do SAP NetWeaver, configuração de pilha ou sistema operacional

Dicas de instalação para configurar o IBM Db2 LUW com HADR

Para configurar a instância do banco de dados do IBM Db2 LUW primário:

• Use a opção alta disponibilidade ou distribuída.
• Instale o ASCS/ERS do SAP e a instância do banco de dados.
• Faça um backup do banco de dados recém-instalado.

Para configurar o servidor de banco de dados em espera usando o procedimento de cópia do sistema homogêneo do SAP, execute estas etapas:

1. Selecione a opção Cópia do sistema>Sistemas de destino>Distribuído>Instância do banco de dados.

2. Como um método de cópia, selecione Sistema Homogêneo para que você possa usar o backup para restaurar um backup na instância do servidor em espera.

3. Quando você chegar à etapa de saída para restaurar o banco de dados para a cópia homogênea do sistema, saia do instalador. Restaure o banco de dados de um backup do host primário. Todas as fases de instalação subsequentes já foram executadas no servidor de banco de dados primário.

4. Configure a HADR para IBM Db2.

   Observação

   Para realizar a instalação e a configuração específicas do Azure e do Pacemaker: durante o procedimento de instalação por meio do SAP Software Provisioning Manager, há uma pergunta explícita sobre a alta disponibilidade do IBM Db2 LUW:

   • Não selecione IBM Db2 pureScale.
   • Não selecione Instalar o IBM Tivoli System Automation for Multiplatforms.
   • Não selecione Gerar arquivos de configuração de cluster.

Ao usar um dispositivo SBD para o Linux Pacemaker, defina os seguintes parâmetros do Db2 HADR:

• Duração da janela de emparelhamento de HADR (segundos) (HADR_PEER_WINDOW) = 300
• Valor de tempo limite da HADR (HADR_TIMEOUT) = 60

Ao usar um agente de isolamento do Azure Pacemaker, defina os seguintes parâmetros:

• Duração da janela de emparelhamento de HADR (segundos) (HADR_PEER_WINDOW) = 900
• Valor de tempo limite da HADR (HADR_TIMEOUT) = 60

Recomendamos os parâmetros anteriores com base no teste inicial de failover/tomada de controle. É obrigatório que você teste a funcionalidade adequada do failover e da tomada de controle com essas configurações de parâmetros. Como as configurações individuais podem variar, os parâmetros podem precisar de ajuste.

Para fins de demonstração e para os procedimentos descritos neste artigo, o SID do banco de dados é PTR.

Verificação do IBM Db2 HADR

Depois de configurar a HADR e o status for PEER e CONNECTED nos nós primário e em espera, execute a seguinte verificação:

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

Configurar o Azure Load Balancer

Durante a configuração da VM, você tem a opção de criar ou selecionar o balanceador de carga existente na seção de rede. Siga as etapas abaixo para configurar o balanceador de carga padrão para a configuração de alta disponibilidade do banco de dados 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

Criar o cluster do Pacemaker

Para criar um cluster do Pacemaker básico neste servidor IBM Db2, confira Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure.

Configuração do Db2 Pacemaker

Ao usar o Pacemaker para failover automático caso haja uma falha de nó, você precisa configurar também as suas instâncias do Db2 e do Pacemaker. Esta seção descreve esse tipo de configuração.

Os seguintes itens são prefixados com:

• [A] : aplicável a todos os nós
• [1] : Aplicável somente ao nó 1
• [2] : aplicável somente ao nó 2

[A] : pré-requisitos para a configuração do Pacemaker:

• Desligue ambos os servidores de banco de dados com o usuário db2<sid> usando db2stop.
• Altere o ambiente do shell do usuário db2<sid> para /bin/ksh. Recomendamos o uso da ferramenta Yast.

Configuração do Pacemaker

1. [1] Configuração de Pacemaker específica para o IBM Db2 HADR:

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

2. [1] Criar recursos do 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] Iniciar recursos do IBM Db2:

   Remova o Pacemaker do modo de manutenção.

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

4. [1] Verifique se o status do cluster está correto e se todos os recursos foram iniciados. Não é importante saber em qual nó os recursos estão sendo executados.

   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 ]
   

Fazer alterações nos perfis do SAP para usar o IP virtual para conexão

Para se conectar à instância primária da configuração de HADR, a camada do aplicativo SAP precisa usar o endereço IP virtual que você definiu e configurou no Azure Load Balancer. As seguintes alterações são exigidas:

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

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

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

Hostname=db-virt-hostname

Instalar os servidores de aplicativo primário e de diálogo

Ao instalar servidores de aplicativos primários e de diálogo em uma configuração do Db2 HADR, use o nome do host virtual escolhido para a configuração.

Se você executou a instalação antes de criar a configuração do Db2 HADR, faça as alterações conforme descrito na seção anterior e da seguinte maneira para as pilhas Java do SAP.

Verificação de URL do JDBC de sistemas de pilha Java ou ABAP+Java

Use a ferramenta de Configuração do J2EE para verificar ou atualizar a URL do JDBC. Como a ferramenta de Configuração do J2EE é uma ferramenta gráfica, você precisa ter o servidor X instalado:

1. Entre no servidor de aplicativos primário da instância do J2EE e execute:

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

2. No quadro à esquerda, selecione repositório de segurança.

3. No quadro à direita, selecione a chave jdbc/pool/<SAPSID>/url.

4. Altere o nome do host na URL do JDBC para o nome do host virtual.

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

5. Selecione Adicionar.

6. Para salvar as suas alterações, selecione o ícone de disco no canto superior esquerdo.

7. Feche a ferramenta de configuração.

8. Reinicie a instância do Java.

Configurar o arquivamento de log para a instalação da HADR

Para configurar o arquivamento de log do Db2 para a instalação da HADR, recomendamos que você configure que os bancos de dados primário e em espera tenham a capacidade de recuperação de log automática de todas as localizações de arquivos de log. Os bancos de dados primário e em espera precisam ser capazes de recuperar arquivos de log de todas as localizações de arquivos de log para os quais qualquer uma das instâncias do banco de dados pode arquivar arquivos de log.

O arquivamento de log é executado somente pelo banco de dados primário. Se você alterar as funções de HADR dos servidores de banco de dados ou se ocorrer uma falha, o novo banco de dados primário será responsável pelo arquivamento de log. Se você tiver configurado várias localizações de arquivos de log, os logs poderão ser arquivados duas vezes. Caso haja uma atualização local ou remota, você também pode precisar copiar manualmente os logs arquivados do servidor primário antigo para a localização de log ativo do novo servidor primário.

É recomendável configurar um compartilhamento NFS comum em que os logs são gravados usando ambos os nós. O compartilhamento NFS precisa estar altamente disponível.

Você pode usar compartilhamentos NFS altamente disponíveis existentes para transportes ou um diretório de perfil. Para saber mais, veja:

• Alta disponibilidade para NFS em VMs do Azure no SUSE Linux Enterprise Server.
• Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com Azure NetApp Files para aplicativos SAP.
• Azure NetApp Files (para criar compartilhamentos NFS).

Testar a configuração do cluster

Esta seção descreve como é possível testar a configuração do Db2 HADR. Cada teste pressupõe que você esteja conectado como usuário root e que o IBM Db2 primário esteja em execução na máquina virtual azibmdb01.

O status inicial de todos os casos de teste é explicado aqui: (crm_mon -r or crm status)

• crm status é um instantâneo do status do Pacemaker em tempo de execução.
• crm_mon -r é a saída contínua do status do marcapasso.

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 ]

O status original em um sistema SAP é documentado em Transação DBACOCKPIT > Configuração > Visão geral, como mostrado na seguinte imagem:

Testar tomada de controle do IBM Db2

Migre o nó que está executando o banco de dados Db2 primário executando o seguinte comando:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

Depois que a migração for concluída, a saída do crm status será parecida com esta:

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 ]

O status original em um sistema SAP é documentado em Transação DBACOCKPIT > Configuração > Visão geral, como mostrado na seguinte imagem:

A migração de recursos com "crm resource migrate" cria restrições de localização. As restrições de localização devem ser excluídas. Se as restrições de localização não forem excluídas, o recurso não poderá falhar ou você poderá enfrentar aquisições indesejadas.

Migre o recurso de volta para azibmdb01 e desmarque as restrições de localização

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR

• crm resource migrate <res_name><host>: cria restrições de localização e pode causar problemas com a tomada de controle
• crm resource clear <res_name>: limpa restrições de local
• crm resource cleanup <res_name>:limpa todos os erros do recurso

Testar isolamento de SBD

Nesse caso, testamos o isolamento de SBD, que recomendamos que você faça ao usar o 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

O nó de cluster azibmdb01 deve ser reiniciado. A função HADR primária do IBM Db2 será movida para azibmdb02. Quando o azibmdb01 estiver online novamente, a instância do Db2 será movida na função de uma instância de banco de dados secundária.

Se o serviço Pacemaker não iniciar automaticamente no primário reinicializado anterior, verifique se ele foi iniciado manualmente com:

sudo service pacemaker start

Testar uma tomada de controle manual

Você pode testar uma tomada de controle manual interrompendo o serviço Pacemaker no nó azibmdb01:

service pacemaker stop

status no 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 ]

Após o failover, você pode iniciar o serviço novamente em azibmdb01.

service pacemaker start

Encerrar o processo do Db2 no nó que executa o banco de dados primário de 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

Isso fará com que a instância do Db2 falhe e o pacemaker relate o seguinte status:

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

O Pacemaker reinicia a instância de banco de dados primária do Db2 no mesmo nó ou faz failover para o nó que está executando a instância de banco de dados secundária e um erro é relatado.

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

Encerrar o processo do Db2 no nó que executa a instância de banco de dados secundário

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

azibmdb02:~ # kill -9

O nó entra no estado com falha e um erro é reportado

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

A instância do Db2 é reiniciada na função secundária que foi atribuída anteriormente.

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

Pare o BD por meio de "db2stop force" no nó que executa a instância do banco de dados primário de 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 ]

Como usuário db2<sid>, execute o comando db2stop force:

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

Falha detectada

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

A instância do banco de dados secundário do Db2 HADR foi promovida para a função primária.

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

Falha na VM com reinicialização no nó que executa a instância do banco de dados primário de HADR

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

O Pacemaker promove a instância secundária para a função de instância primária. A antiga instância primária passará para a função secundária depois que a VM e todos os serviços forem totalmente restaurados após a reinicialização da VM.

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 ]

Cause uma falha na VM que executa a instância do banco de dados primário de HADR com "halt"

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

Nesse caso, o Pacemaker detecta que o nó que está executando a instância primária do banco de dados não está respondendo.

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 ]

A próxima etapa é verificar uma situação de Divisão de atenção. Depois que o nó sobrevivente determinar que o nó executado pela última vez a instância do banco de dados primário está inativo, será executado um failover dos recursos.

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 ]

Caso haja uma "parada" do nó, o nó com falha precisa ser reiniciado por meio das ferramentas de Gerenciamento do Azure (no portal do Azure, no PowerShell ou na CLI do Azure). Depois que o nó com falha estiver online novamente, ele iniciará a instância do Db2 na função secundária.

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 ]

Próximas etapas

• Arquitetura de alta disponibilidade e cenários para SAP NetWeaver
• Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure