Alta disponibilidade do IBM Db2 LUW nas VMs do Azure no Red Hat Enterprise Linux Server
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.
Observação
Esse artigo contém referências a termos que a Microsoft não utiliza mais. Quando esses termos forem removidos do software, nós os removeremos deste artigo.
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:
| Nota do SAP | DESCRIÇÃO |
|---|---|
| 1928533 | Aplicativos SAP no Azure: produtos com suporte e tipos de VM do Azure |
| 2015553 | SAP no Azure: pré-requisitos de suporte |
| 2178632 | Métricas-chave de monitoramento para SAP no Azure |
| 2191498 | SAP no Linux com o Azure: monitoramento aprimorado |
| 2243692 | VM do Linux no Azure (IaaS): problemas na licença do SAP |
| 2002167 | Red Hat Enterprise Linux 7.x: Instalação e atualização |
| 2694118 | Complemento de HA do Red Hat Enterprise Linux no Azure |
| 1999351 | Solução de problemas de monitoramento aprimorado do Azure para SAP |
| 2233094 | DB6: aplicativos SAP no Azure que usam o IBM Db2 para Linux, UNIX e Windows – Informações adicionais |
| 1612105 | DB6: perguntas frequentes sobre Db2 com HADR |
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 à 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 RHEL Linux e configure os sistemas de arquivos.
- Instale e configure o Pacemaker.
- Configurar o cluster glusterfs ou os Azure NetApp files
- 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:
| Tópico | Descrição breve |
|---|---|
| Definir grupos de recursos do Azure | Grupos de recursos em que você implanta a VM, rede virtual, Azure Load Balancer e outros recursos. Pode ser existente ou novo. |
| Definição de sub-rede/rede virtual | Local em que as VMs para IBM Db2 e Azure Load Balancer estão sendo implantadas. Pode ser existente ou criado recentemente. |
| Máquinas virtuais que hospedam o IBM Db2 LUW | Tamanho da VM, armazenamento, rede, endereço IP. |
| Nome do host virtual e IP virtual para banco de dados IBM Db2 | O IP virtual ou o nome do host é usado para conexão dos servidores de aplicativos SAP. db-virt-hostname, db-virt-ip. |
| Isolamento do Azure | Método para evitar situações de atenção dividida. |
| Azure Load Balancer | Uso de Standard (recomendado), porta de teste para banco de dados Db2 (nossa recomendação 62500) probe-port. |
| Resolução de nomes | Como a resolução de nomes funciona no ambiente. O serviço DNS é altamente recomendado. O arquivo de hosts local pode ser usado. |
Para obter mais informações sobre o Linux Pacemaker no Azure, consulte Configurar o Pacemaker no Red Hat Enterprise Linux no Azure.
Importante
Para as versões Db2 11.5.6 e superiores, é altamente recomendável o uso de uma solução integrada usando o Pacemaker da IBM.
Implantação no Red Hat Enterprise Linux
O agente de recurso para o IBM DB2 LUW está incluído no complemento de alta disponibilidade do servidor Red Hat Enterprise Linux. Para a configuração descrita neste documento, você deve usar o Red Hat Enterprise Linux para SAP. O Azure Marketplace contém uma imagem do Red Hat Enterprise Linux 7.4 para SAP ou superior 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 pela Red Hat por meio do Azure Marketplace quando você escolhe 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 um mínimo de Red Hat Enterprise Linux 7.4 para SAP por causa das melhorias de desempenho relacionadas ao Azure nesta versão ou em versões posteriores do Red Hat Enterprise Linux.
- Crie ou selecione um grupo de recursos.
- Crie ou selecione uma rede virtual e uma sub-rede.
- 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.
- Crie a Máquina Virtual 1.
- Use o Red Hat Enterprise Linux para a imagem SAP no Azure Marketplace.
- Selecione o conjunto de dimensionamento, a zona de disponibilidade ou o conjunto de disponibilidade criado na etapa 3.
- Crie a Máquina Virtual 2.
- Use o Red Hat Enterprise Linux para a imagem SAP no Azure Marketplace.
- 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).
- 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:
- Eu quero: instalar um novo sistema.
- Meu banco de dados: IBM Db2 para Linux, Unix e Windows.
- Filtros adicionais para versões do SAP NetWeaver, configuração de pilha ou sistema operacional.
Regras de firewall do Red Hat
O Red Hat Enterprise Linux tem o firewall habilitado por padrão.
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
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.
Importante
Anote a "Porta de Comunicação do Banco de Dados" que foi configurada durante a instalação. É necessário que ambas as instâncias de banco de dados tenham o mesmo número de porta.
Configurações de HADR do IBM DB2 para o Azure
Ao usar um agente de isolamento do Azure Pacemaker, defina os seguintes parâmetros:
- Duração da janela do par de HADR (segundos) (HADR_PEER_WINDOW) = 240
- Valor de tempo limite da HADR (HADR_TIMEOUT) = 45
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.
Observação
Específico ao IBM Db2 com a configuração de HADR com inicialização normal: a instância de banco de dados secundária ou em espera precisa estar em execução para iniciar a instância do banco de dados primário.
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.
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:
- Selecione a opção Cópia do sistema>Sistemas de destino>Distribuído>Instância do banco de dados.
- 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.
- 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.
Regras de firewall do Red Hat para DB2 HADR
Adicione regras de firewall para permitir que o tráfego para DB2 e entre o DB2 para HADR funcione:
- Porta de comunicação do banco de dados. Se estiver usando partições, adicione essas portas também.
- Porta HADR (valor do parâmetro DB2 HADR_LOCAL_SVC).
- Porta da investigação do Azure.
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
Verificação do IBM Db2 HADR
Para fins de demonstração e para os procedimentos descritos neste artigo, o SID do banco de dados é ID2.
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 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
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.
Siga as etapas em Criar balanceador de carga para configurar um balanceador de carga padrão para um sistema SAP de alta disponibilidade usando o portal do Azure. Durante a configuração do balanceador de carga, considere os seguintes pontos:
- Configuração de IP front-end: Crie um IP front-end. Selecione a mesma rede virtual e nome de sub-rede das máquinas virtuais de banco de dados.
- Pool de back-end: Crie um pool de back-end e adicione VMs de banco de dados.
- Regras de entrada: Crie uma regra de balanceamento de carga. Siga as mesmas etapas para ambas as regras de balanceamento de carga.
- Endereço IP de front-end: Selecione um IP de front-end.
- Pool de back-end: selecione um pool de back-end.
- Portas de alta disponibilidade: selecione essa opção.
- Protocolo: selecione TCP.
- Sonda de integridade: crie uma sonda de integridade com os seguintes detalhes:
- Protocolo: selecione TCP.
- Porta: Por exemplo, 625<instância-não.>.
- Intervalo: Inserir 5.
- Limite de investigação: insira 2.
- Tempo limite de inatividade (minutos): Inserir 30.
- Habilitar IP Flutuante: Selecione essa opção.
Observação
A propriedade de configuração da investigação de integridade numberOfProbes, também conhecida como Limite não íntegro no portal, não é respeitada. Para controlar o número de análises consecutivas bem-sucedidas ou com falha, configure a propriedade probeThreshold para 2. Atualmente não é possível definir essa propriedade utilizando o portal do Azure, por isso utilize o CLI do Azure ou o comando PowerShell.
Observação
Quando VMs sem endereços IP públicos são colocados no pool de back-end de uma instância interna (sem endereço IP público) do Standard Azure Load Balancer, não há conectividade de saída com a Internet, a menos que seja realizada mais configuração para permitir o roteamento para pontos extremidade públicos. Para obter mais informações sobre como obter conectividade de saída, veja Conectividade de ponto final público para VMs usando o Azure Standard Load Balancer em cenários de alta disponibilidade SAP.
Importante
Não habilite carimbos de data/hora de TCP em VMs do Azure posicionadas de forma subjacente em relação ao Azure Load Balancer. Habilitar carimbos de data/hora TCP pode causar falha nas sondagens de integridade. Defina o parâmetro net.ipv4.tcp_timestampscomo 0. Para saber mais, confira Investigações de integridade do Load Balancer.
[A] Adicionar regra de firewall para a porta de investigação:
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
Criar o cluster do Pacemaker
Para criar um cluster do Pacemaker básico neste servidor IBM Db2, consulte Configurando o Pacemaker no Red Hat Enterprise Linux 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:
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Configuração do Pacemaker
[1] Configuração de Pacemaker específica para o IBM Db2 HADR:
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[1] Criar recursos do IBM Db2:
Se estiver criando um cluster no RHEL 7.x, atualize os agentes de recursos do pacote para a versão
resource-agents-4.1.1-61.el7_9.15ou superior. Use os seguintes comandos para criar os recursos de 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_ID2Se estiver criando um cluster no RHEL 8.x, atualize os agentes de recursos do pacote para a versão
resource-agents-4.1.1-93.el8ou superior. Para mais detalhes, consulte o recurso Red Hat KBAdb2quando a promoção com o estadoPRIMARY/REMOTE_CATCHUP_PENDING/CONNECTEDdo HADR falhar. Use os seguintes comandos para criar os recursos de 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[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 pcs property set maintenance-mode=false[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 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
Importante
Você precisa gerenciar a instância do Db2 clusterizado do Pacemaker usando as ferramentas do Pacemaker. Se você usar comandos do db2 como db2stop, o Pacemaker detectará a ação como uma falha de recurso. Se estiver executando a manutenção, você poderá colocar os nós ou recursos no modo de manutenção. O Pacemaker suspende os recursos de monitoramento e você pode usar os comandos normais de administração do db2.
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
Quando você instalar servidores de aplicativos primários e de diálogo em uma configuração Db2 HADR, use o nome do host virtual que você escolheu 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:
Entre no servidor de aplicativos primário da instância do J2EE e execute:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shNo quadro à esquerda, selecione repositório de segurança.
No quadro à direita, selecione a chave
jdbc/pool/\<SAPSID>/url.Altere o nome do host na URL do JDBC para o nome do host virtual.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Selecione Adicionar.
Para salvar as suas alterações, selecione o ícone de disco no canto superior esquerdo.
Feche a ferramenta de configuração.
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 ou GlusterFS, em que os logs são gravados usando ambos os nós. O compartilhamento NFS ou o GlusterFS precisa estar altamente disponível.
Você pode usar compartilhamentos NFS altamente disponíveis existentes ou o GlusterFS para transportes ou um diretório de perfil. Para obter mais informações, consulte:
- GlusterFS em VMs do Azure no Red Hat Enterprise Linux para SAP NetWeaver.
- Alta disponibilidade para o SAP NetWeaver em VMs do Azure no Red Hat Enterprise Linux com o 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 o IBM Db2 primário está em execução na máquina virtual az-idb01. O usuário com privilégios sudo ou root (não recomendado) deve ser usado.
O status inicial de todos os casos de teste é explicado aqui: (crm_mon -r ou pcs status)
- status de computadores é um instantâneo do status do Pacemaker no momento da execução.
- crm_mon -r é a saída contínua do status do 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
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
Importante
Antes de começar o teste, verifique se:
O Pacemaker não tem nenhuma ação com falha (pcs status).
Não há restrições de local (sobras do teste de migração).
A sincronização do IBM Db2 HADR está funcionando. Verifique com o usuário db2<sid>.
db2pd -hadr -db <DBSID>
Migre o nó que está executando o banco de dados Db2 primário executando o seguinte comando:
# 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
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: [ 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
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 "pcs resource move" cria restrições de localização. Nesse caso, as restrições de localização estão impedindo a execução da instância do IBM Db2 em az-idb01. Se as restrições de local não forem excluídas, o recurso não poderá fazer failback.
Remova a restrição de local e o nó de espera será iniciado no 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 o status do cluster mudará para:
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
Migre o recurso de volta para az-idb01 e desmarque as restrições de localização
# 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
- No RHEL 7.x -
pcs resource move <resource_name> <host>: cria restrições de local e pode causar problemas com a tomada de controle - No RHEL 8.x -
pcs resource move <resource_name> --master: cria restrições de local e pode causar problemas com a aquisição pcs resource clear <resource_name>: limpa as restrições de localpcs resource cleanup <resource_name>: limpa todos os erros do recurso
Testar uma tomada de controle manual
Você pode testar uma tomada de controle manual interrompendo o serviço Pacemaker no nó az-idb01:
systemctl stop pacemaker
status em 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
Após o failover, você pode iniciar o serviço novamente em az-idb01.
systemctl start pacemaker
Encerrar o processo do Db2 no nó que executa o banco de dados primário de 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
A instância do Db2 irá falhar e o Pacemaker moverá o nó mestre e relatará o seguinte 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-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
O Pacemaker reinicia a instância do banco de dados primário Db2 no mesmo nó ou faz o failover para o nó que está executando a instância de banco de dados secundário e um erro é relatado.
Encerrar o processo do Db2 no nó que executa a instância de banco de dados secundário
[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
O nó entra em estado de falha e o erro é relatado.
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
A instância do Db2 é reiniciada na função secundária que foi atribuída anteriormente.
Pare o BD por meio de "db2stop force" no nó que executa a instância do banco de dados primário de HADR
Como usuário db2<sid>, execute o comando db2stop force:
az-idb01:db2ptr> db2stop force
Falha detectada:
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
A instância do banco de dados secundário do Db2 HADR foi promovida para a função primária.
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
Cause uma falha na VM que executa a instância do banco de dados primário de HADR com "halt"
#Linux kernel panic.
sudo 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 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
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: [ 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
No caso de uma pane no k, o nó com falha será reiniciado pelo agente de isolamento. Depois que o nó com falha ficar online novamente, você deverá iniciar o cluster do Pacemaker
sudo pcs cluster start
iniciando a instância do Db2 na função secundária.
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