Alta disponibilidade do SAP HANA nas VMs do Azure no SUSE Linux Enterprise Server
Para desenvolvimento local, é possível usar a Replicação de Sistema do HANA ou usar o armazenamento compartilhado para estabelecer alta disponibilidade para SAP HANA. Em VMs (máquinas virtuais) do Azure, a Replicação de Sistema do HANA no Azure é atualmente a única função de alta disponibilidade com suporte. A replicação do SAP HANA consiste em um nó primário e, pelo menos, um nó secundário. As alterações nos dados do nó primário são replicadas no nó secundário de modo síncrono ou assíncrono.
Este artigo descreve como implantar e configurar as máquinas virtuais, instalar a estrutura de cluster e instalar e configurar a Replicação de Sistema do SAP HANA. Nas configurações de exemplo, são usados os comandos de instalação, o número da instância 03 a ID do Sistema do HANA HN1.
Primeiro, leia os seguintes documentos e Notas SAP:
- A Nota SAP 1928533, que tem:
- A lista de tamanhos de VM do Azure que têm suporte para a implantação de software SAP.
- Informações importantes sobre capacidade para tamanhos de VM do Azure.
- O software SAP e combinações de SO (sistema operacional) e banco de dados com suporte.
- A versão do kernel do SAP necessária para Windows e Linux no Microsoft Azure.
- A Nota SAP 2015553 lista os pré-requisitos para implantações de software SAP com suporte do SAP no Azure.
- A Nota SAP 2205917 tem configurações de SO recomendadas para SUSE Linux Enterprise Server para aplicativos SAP.
- A Nota SAP 1944799 tem Diretrizes SAP HANA para SUSE Linux Enterprise Server para aplicativos SAP.
- A Nota SAP 2178632 contém informações detalhadas sobre todas as métricas de monitoramento relatadas para SAP no Azure.
- A Nota SAP 2191498 tem a versão necessária do SAP Host Agent para Linux no Azure.
- A Nota SAP 2243692 tem informações sobre o licenciamento do SAP no Linux no Azure.
- A Nota SAP 1984787 tem informações gerais sobre o SUSE Linux Enterprise Server 12.
- A Nota SAP 1999351 tem informações de solução de problemas adicionais para a Extensão de Monitoramento Avançado do Azure para SAP.
- A Nota SAP 401162 contém informações sobre como evitar o "endereço já em uso" ao configurar a Replicação do Sistema HANA.
- WIKI da comunidade do SAP tem todas as Notas SAP necessárias para Linux.
- SAP HANA certificada IaaS plataformas
- Guia de Planejamento e implementação de Máquinas Virtuais do Azure para SAP no Linux.
- Implantação de Máquinas Virtuais do Azure para SAP no Linux (este artigo).
- Guia de Implantação de Máquinas Virtuais do Azure do DBMS para SAP no Linux.
- Guias de melhores práticas do SUSE Linux Enterprise Server for SAP Applications 12 SP3
- Configuração de uma infraestrutura otimizada de desempenho do SAP HANA SR (SLES para Aplicativos SAP 12 SP1). O guia contém todas as informações necessárias para configurar a Replicação de Sistema do SAP HANA para desenvolvimento local. Use este guia como uma linha de base.
- Configuração de uma infraestrutura otimizada para custo de SR do SAP HANA (SLES para aplicativos SAP 12 SP1)
Visão geral
Para obter a alta disponibilidade, o SAP HANA é instalada em duas máquinas virtuais. Os dados são replicados usando a Replicação de Sistema do HANA.
A configuração da Replicação de Sistema do SAP HANA usa um nome do host virtual dedicado e endereços IP virtuais. No Azure, um balanceador de carga é necessário para usar um endereço IP virtual. A configuração apresentada mostra um balanceador de carga com:
- Endereço IP do front-end: 10.0.0.13 para hn1-db
- Porta de Investigação: 62503
Implantar para Linux
O agente de recursos para HANA SAP está incluído no SUSE Linux Enterprise Server for SAP Applications. O Azure Marketplace contém uma imagem para SUSE Linux Enterprise Server for SAP Applications 12 que você pode usar para implantar novas máquinas virtuais.
Implantar com um modelo
É possível usar um dos modelos de início rápido que estão no GitHub para implantar todos os recursos necessários. O modelo implanta as máquinas virtuais, o balanceador de carga, o conjunto de disponibilidade, e assim por diante. Para implantar o modelo, siga estas etapas:
Abra o modelo de banco de dados ou o modelo convergido no portal do Azure. O modelo de banco de dados cria as regras de balanceamento de carga apenas para um banco de dados. O modelo convergido também cria as regras de balanceamento de carga para uma instância ASCS/SCS e ERS (somente Linux). Se você planeja instalar um sistema baseado no SAP NetWeaver e quer instalar a instância ASCS/SCS nas mesmas máquinas, use o modelo convergido.
Insira os parâmetros s seguir:
- ID do sistema SAP: Insira a ID do sistema SAP do sistema SAP que você deseja instalar. A ID é usada como um prefixo para os recursos que serão implantados.
- Tipo de pilha: (este parâmetro é aplicável somente quando você usa o modelo convergido.) Selecione o tipo de pilha do SAP NetWeaver.
- Tipo de SO: Selecione uma das distribuições do Linux. Para este exemplo, selecione SLES 12.
- Tipo de banco de dados: Selecionar HANA.
- Tamanho do Sistema SAP: Insira o número de SAPS que o novo sistema irá fornecer. Se não tiver certeza de quantos SAPS o sistema precisará, pergunte ao Parceiro de Tecnologia SAP ou ao Integrador de Sistemas.
- Disponibilidade do Sistema: Selecione HA.
- Nome de usuário do administrador e senha do administrador: um usuário é criado e pode ser usado para entrar no computador.
- Sub-rede nova ou existente: determina se uma nova rede virtual e sub-rede devem ser criadas ou se uma sub-rede existente é usada. Se já tiver uma rede virtual conectada à rede local, selecione Existente.
- ID da Sub-rede: Se você deseja implantar a VM em uma rede virtual existente em que você tem uma sub-rede definida para a qual a VM deve ser designada, nomeie a identificação dessa sub-rede específica. Geralmente, a ID é semelhante a /subscriptions/<ID da assinatura>/resourceGroups/<nome do grupo de recursos>/providers/Microsoft.Network/virtualNetworks/<nome da rede virtual>/subnets/<nome da sub-rede>.
Implantação manual
Importante
Selecione o sistema operacional SAP certificado para o SAP HANA nos tipos de VM específicos que você está usando. A lista de tipos de VM certificados do SAP HANA e suas versões do sistema operacional podem ser pesquisados em Plataformas de IaaS certificadas do SAP HANA. Clique nos detalhes do tipo de VM listado para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para o tipo de VM específico
Crie um grupos de recursos.
Crie uma rede virtual.
Crie um conjunto de disponibilidade.
- Defina o máximo de domínio de atualização.
Crie um balanceador de carga (interno). Recomenda-se o Standard Load Balancer. Selecione a rede virtual criada na etapa 2.
Crie a máquina virtual 1.
- Use uma imagem SLES4SAP na galeria do Azure que tem suporte para o SAP HANA no tipo de VM que você selecionou.
- Selecione o conjunto de disponibilidade criado na etapa 3.
Crie a máquina virtual 2.
- Use uma imagem SLES4SAP na galeria do Azure que tem suporte para o SAP HANA no tipo de VM que você selecionou.
- Selecione o conjunto de disponibilidade criado na etapa 3.
Adicione discos de dados.
Importante
Não há suporte para IP flutuante em uma configuração de IP de adaptador de rede secundário em cenários de balanceamento de carga. Confira Limitações do Azure Load Balancer para mais detalhes. Se você precisar de um endereço IP adicional para a VM, implante um segundo adaptador de rede.
Observação
Quando as VMs sem endereços IP públicos forem colocadas no pool de back-end do Standard Azure Load Balancer (sem endereço IP público), não haverá nenhuma conectividade de saída com a Internet se não houver configuração adicional a fim de permitir o roteamento para pontos de extremidade públicos. Para obter detalhes sobre como alcançar conectividade de saída, veja Conectividade de ponto de extremidade público para Máquinas Virtuais usando o Azure Standard Load Balancer em cenários de alta disponibilidade do SAP.
Para configurar o balanceador de carga padrão, siga estas etapas de configuração:
Primeiro, crie um pool de IP de front-end:
- Abra o balanceador de carga, selecione pool de front-end e selecione Adicionar.
- Insira o nome do novo pool de IP front-end (por exemplo, hana-frontend).
- Defina a Atribuição para Estático e insira o endereço IP (por exemplo, 10.0.0.13).
- Selecione OK.
- Depois que o novo pool de IP de front-end for criado, anote o endereço IP do pool.
Crie um único pool de back-end:
- Abra o balanceador de carga, selecione Pools de back-end e selecione Adicionar.
- Insira o nome do novo pool de back-end (por exemplo, hana-backend).
- Selecione NIC para Configuração do Pool de back-end.
- Selecione Adicionar uma máquina virtual.
- Selecione as máquinas virtuais do cluster do HANA.
- Selecione Adicionar.
- Selecione Salvar.
Em seguida, crie uma investigação de integridade:
- Abra o balanceador de carga, selecione investigações de integridade e selecione Adicionar.
- Insira o nome da nova investigação de integridade (por exemplo, hana-hp).
- Selecione TCP como o protocolo e porta 62503. Mantenha o valor do intervalo definido como 5.
- Selecione OK.
Em seguida, crie as regras de balanceamento de carga:
- Abra o balanceador de carga, selecione Regras de balanceamento de carga e selecione Adicionar.
- Insira o nome da nova regra do balanceador de carga (por exemplo hana-lb).
- Selecione o endereço IP de front-end, o pool de back-end e a investigação de integridade que você criou anteriormente (por exemplo, hana-frontend, hana-backend e hana-hp).
- Aumente o tempo limite de ociosidade para 30 minutos
- Selecione Portas de HA.
- Certifique-se de habilitar IP Flutuante.
- Selecione OK.
Para obter mais informações sobre as portas necessárias para o SAP HANA, leia o capítulo Conexões aos bancos de dados de locatário no guia Bancos de dados de locatário do SAP HANA ou Nota SAP 2388694.
Importante
Não habilite carimbos de data/hora de TCP em VMs do Azure posicionadas subjacentemente ao Azure Load Balancer. Habilitar carimbos de data/hora de TCP fará com que as investigações de integridade falhem. Defina o parâmetro net.ipv4.tcp_timestamps para 0. Para obter detalhes, veja Investigações de integridade do Load Balancer. Veja também a nota SAP 2382421.
Criar um cluster do Pacemaker
Siga as etapas em Configurar Pacemaker no SUSE Linux Enterprise Server no Azure para criar um cluster Pacemaker básico para esse servidor HANA. É possível usar o mesmo cluster do Pacemaker para SAP HANA e SAP NetWeaver (A)SCS.
Instalar SAP HANA
As etapas nesta seção usam os seguintes prefixos:
- [A] : A etapa se aplica a todos os nós.
- [1] : A etapa se aplica apenas ao nó 1.
- [2] : A etapa se aplica ao nó 2 do cluster do Pacemaker apenas.
[A] Configurar o layout de disco: discos sem formatação: Gerenciamento de volumes lógicos (LVM) .
É recomendável que você use o LVM para volumes que armazenam dados e arquivos de log. O exemplo a seguir assume que as máquinas virtuais tenham quatro discos de dados anexados que são usados para criar dois volumes.
Listar todos os discos disponíveis:
ls /dev/disk/azure/scsi1/lun*Saída de exemplo:
/dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 /dev/disk/azure/scsi1/lun2 /dev/disk/azure/scsi1/lun3Crie volumes físicos para todos os discos que você quer usar:
sudo pvcreate /dev/disk/azure/scsi1/lun0 sudo pvcreate /dev/disk/azure/scsi1/lun1 sudo pvcreate /dev/disk/azure/scsi1/lun2 sudo pvcreate /dev/disk/azure/scsi1/lun3Crie um grupo de volumes para os arquivos de dados. Use um grupo de volumes para os arquivos de log e outro para o diretório compartilhado do SAP HANA:
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2 sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3Criar os volumes lógicos. Um volume linear é criado quando você usa
lvcreatesem a opção-i. Sugerimos que você crie um volume distribuído para melhorar o desempenho de E/S e alinhe os tamanhos de distribuição aos valores documentados em Configurações de armazenamento de VM do SAP HANA. O argumento-ideve ser o número de volumes físicos subjacentes e o argumento-Ié o tamanho da distribuição. Neste documento, dois volumes físicos são usados para o volume de dados, portanto, o argumento da chave-ié definido com 2. O tamanho da distribuição para o volume de dados é de 256KiB. Um volume físico é usado para o volume do log, portanto, nenhuma opção-iou-Ié usada explicitamente para os comandos do volume do log.Importante
Use a opção
-ie defina-a para o número do volume físico subjacente quando você usar mais de um volume físico para cada volume de dados, log ou compartilhado. Use a opção-Ipara especificar o tamanho da distribuição, quando criar um volume distribuído.
Veja Configurações de armazenamento de VM do SAP HANA para ver as configurações de armazenamento recomendadas, incluindo tamanhos de distribuição e número de discos.sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1 sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1 sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1 sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_sharedCrie os diretórios de montagem e copie o UUID de todos os volumes lógicos:
sudo mkdir -p /hana/data/HN1 sudo mkdir -p /hana/log/HN1 sudo mkdir -p /hana/shared/HN1 # Write down the ID of /dev/vg_hana_data_HN1/hana_data, /dev/vg_hana_log_HN1/hana_log, and /dev/vg_hana_shared_HN1/hana_shared sudo blkidCrie entradas
fstabpara os três volumes lógicos:sudo vi /etc/fstabInsira a seguinte linha no arquivo
/etc/fstab:/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_HN1-hana_data> /hana/data/HN1 xfs defaults,nofail 0 2 /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_HN1-hana_log> /hana/log/HN1 xfs defaults,nofail 0 2 /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_HN1-hana_shared> /hana/shared/HN1 xfs defaults,nofail 0 2Monte os novos volumes:
sudo mount -a[A] Configurar o layout de disco: discos sem formatação: Discos simples.
Para sistemas de demonstração, você pode colocar os arquivos de log e dados do HANA em um disco. Crie uma partição em /dev/disk/azure/scsi1/lun0 e formate-a com xfs:
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0' sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1 # Write down the ID of /dev/disk/azure/scsi1/lun0-part1 sudo /sbin/blkid sudo vi /etc/fstabInsira esta linha no arquivo /etc/fstab:
/dev/disk/by-uuid/<UUID> /hana xfs defaults,nofail 0 2Crie o diretório de destino e monte o disco:
sudo mkdir /hana sudo mount -a[A] Configure a resolução do nome do host para todos os hosts.
É possível usar um servidor DNS ou modificar o arquivo /etc/hosts em todos os nós. Este exemplo mostra como usar o arquivo /etc/hosts. Substitua o endereço IP e o nome do host nos comandos a seguir:
sudo vi /etc/hostsInsira as seguintes linhas no arquivo /etc/hosts. Altere o endereço IP e o nome do host para corresponder ao ambiente:
10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1[A] Instale os pacotes de alta disponibilidade do SAP HANA:
sudo zypper install SAPHanaSR
Para instalar a Replicação de Sistema do SAP HANA, siga o capítulo 4 do guia Cenário otimizado para desempenho do SR do SAP HANA.
[A] Execute o programa hdblcm do DVD do HANA. Insira os valores a seguir no prompt:
- Escolha instalação: Insira 1.
- Selecione os componentes adicionais para instalação: Insira 1.
- Insira o caminho de instalação [/hana/shared]: Selecione Enter.
- Insira o Nome do Host Local: Selecione Enter.
- Você deseja adicionar outros hosts ao sistema? (s/n) [n]: Selecione Enter.
- Insira a ID do Sistema SAP HANA: Insira o SID do HANA, por exemplo: HN1.
- Insira o Número da Instância [00]: Insira o número de instância do HANA. Insira 03 se você usou o modelo do Azure ou seguiu a seção de implantação manual deste artigo.
- Selecione Modo de Banco de Dados/Inserir Índice [1]: Selecione Enter.
- Selecione o Uso do Sistema/Inserir Índice [4]: Selecione o valor de uso do sistema.
- Insira o Local dos Volumes de Dados [/hana/data/HN1]: Selecione Enter.
- Insira o Local dos Volumes de Log [/hana/log/HN1]: Selecione Enter.
- Restringir a alocação máxima de memória? [n]: Selecione Enter.
- Insira o Nome do Host do Certificado para o '...' [...]: Selecione Enter.
- Insira a Senha de Usuário do Agente do Host SAP (sapadm): Insira a senha de usuário do agente de host.
- Confirme a Senha de Usuário do Agente do Host SAP (sapadm): Insira a senha do usuário do agente de host novamente para confirmar.
- Insira a Senha do Administrador de Sistema (hdbadm): Insira a senha de administrador do sistema.
- Confirme a Senha do Administrador de Sistema (hdbadm): Insira a senha do usuário do agente administrador novamente para confirmar.
- Insira o Diretório Base do Administrador de Sistema [/usr/sap/HN1/home]: Selecione Enter.
- Insira o Shell de Logon do Administrador de Sistema [/bin/sh]: Selecione Enter.
- Insira a ID de Usuário do Administrador de Sistema [1001]: Selecione Enter.
- Insira a ID do Grupo de Usuários (sapsys) [79]: Selecione Enter.
- Insira a Senha de Usuário do Banco de Dados (SYSTEM): Senha de Usuário do Banco de Dados.
- Confirme a Senha de Usuário do Banco de Dados (SYSTEM): Insira a senha do usuário novamente para confirmar.
- Reiniciar o sistema após a reinicialização do computador? [n]: Selecione Enter.
- Deseja continuar? (s/n): Valide o resumo. Insira y para continuar.
[A] Atualize o Agente de Host do SAP.
Baixe o último arquivo do Agente de Host do SAP no Centro de Software do SAP e execute o comando a seguir para atualizar o agente. Substitua o caminho do arquivo para apontar para o arquivo que você baixou:
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
Configurar a replicação do Sistema SAP HANA 2.0
As etapas nesta seção usam os seguintes prefixos:
- [A] : A etapa se aplica a todos os nós.
- [1] : A etapa se aplica apenas ao nó 1.
- [2] : A etapa se aplica ao nó 2 do cluster do Pacemaker apenas.
[1] Crie o banco de dados de locatário.
Se você estiver usando o SAP HANA 2.0 ou o MDC, crie um banco de dados de locatário para o sistema SAP NetWeaver. Substitua NW1 pelo SID do sistema SAP.
Execute o seguinte comando como <hanasid>adm:
hdbsql -u SYSTEM -p "passwd" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "passwd"'[1] Configure a Replicação de Sistema no primeiro nó:
Faça backup dos bancos de dados como <hanasid>adm:
hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')" hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')" hdbsql -d NW1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"Copie os arquivos PKI do sistema para o site secundário:
scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/ scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/Crie o site primário:
hdbnsutil -sr_enable --name=SITE1[2] Configure a Replicação de Sistema no segundo nó:
Registre o segundo nó para iniciar a replicação de sistema. Execute o seguinte comando como <hanasid>adm:
sapcontrol -nr 03 -function StopWait 600 10 hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
Configurar a replicação do Sistema SAP HANA 1.0
As etapas nesta seção usam os seguintes prefixos:
- [A] : A etapa se aplica a todos os nós.
- [1] : A etapa se aplica apenas ao nó 1.
- [2] : A etapa se aplica ao nó 2 do cluster do Pacemaker apenas.
[1] Crie os usuários necessários.
Execute o comando a seguir como raiz. Certifique-se de substituir as cadeias em negrito (ID do Sistema HANA HN1 e o número da instância 03) pelos valores da sua instalação do SAP HANA:
PATH="$PATH:/usr/sap/HN1/HDB03/exe" hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"' hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync' hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'[A] Crie a entrada do repositório de chaves.
Execute o comando a seguir para criar uma nova entrada de repositório de chaves:
PATH="$PATH:/usr/sap/HN1/HDB03/exe" hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd[1] Faça backup do banco de dados.
Faça backup dos bancos de dados como raiz:
PATH="$PATH:/usr/sap/HN1/HDB03/exe" hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"Se você usar uma instalação de vários locatários, faça também backup do banco de dados do locatário:
hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"[1] Configure a Replicação de Sistema no primeiro nó.
Crie o site primário como <hanasid>adm:
su - hdbadm hdbnsutil -sr_enable –-name=SITE1[2] Configure a Replicação de Sistema no nó secundário.
Registre o site secundário como <hanasid>adm:
sapcontrol -nr 03 -function StopWait 600 10 hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
Implementar os ganchos do HANA SAPHanaSR e susChkSrv
Essa é uma etapa importante para otimizar a integração com o cluster e melhorar a detecção quando um failover de cluster for necessário. É altamente recomendável configurar o gancho do Python SAPHanaSR. Para o HANA 2.0 SP5 e superior, é recomendável implementar o SAPHanaSR, juntamente com o gancho susChkSrv.
SusChkSrv estende a funcionalidade do principal provedor de HA do SAPHanaSR. Ele atua na situação em que o processo do HANA hdbindexserver falha. Se apenas um processo falha, normalmente o HANA tenta reiniciá-lo. Reiniciar o processo indexserver pode levar muito tempo, durante o qual o banco de dados do HANA não responde.
Com susChkSrv implementado, uma ação imediata e configurável é executada, o que dispara um failover no período do tempo limite configurado em vez de aguardar o processo hdbindexserver para reiniciar no mesmo nó.
[A] Instale o "gancho de replicação do sistema" do HANA. O gancho precisa ser instalado em ambos os nós do banco de dados HANA.
Dica
O gancho Python SAPHanaSR só pode ser implementado para o HANA 2.0. O pacote SAPHanaSR deve ser pelo menos a versão 0.153.
O gancho Python susChkSrv requer o SAP HANA 2.0 SP5 e a versão do SAPHanaSR 0.161.1_BF ou superior precisa estar instalada.- Pare o HANA em ambos os nós. Execute como <sid>adm:
sapcontrol -nr 03 -function StopSystem- Ajuste
global.iniem cada nó de cluster. Se os requisitos para o gancho susChkSrv não forem atendidos, remova todo o bloco [ha_dr_provider_suschksrv] dos parâmetros abaixo.
Você pode ajustar o comportamento de susChkSrv com o parâmetro action_on_lost.
Os valores válidos são [ ignore | stop | kill | fence ].
# add to global.ini [ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /usr/share/SAPHanaSR execution_order = 1 [ha_dr_provider_suschksrv] provider = susChkSrv path = /usr/share/SAPHanaSR execution_order = 3 action_on_lost = fence [trace] ha_dr_saphanasr = info
A configuração que aponta para o local padrão /usr/share/SAPHanaSR traz o benefício de que o código do gancho Python é atualizado automaticamente por meio de atualizações do sistema operacional ou do pacote e é usado pelo HANA na próxima reinicialização. Com um caminho opcional, como /hana/shared/myHooks, você pode desacoplar as atualizações do sistema operacional com a versão do gancho usada.
- [A] O cluster requer a configuração de sudoers em cada nó de cluster para <sid>adm. Neste exemplo, isso é obtido com a criação de um novo arquivo. Execute o comando como
roote adapte os valores em negrito de hn1/HN1 com o SID correto.cat << EOF > /etc/sudoers.d/20-saphana # Needed for SAPHanaSR and susChkSrv Python hooks hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_* hniadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe EOF
Para obter mais detalhes sobre a implementação do gancho de replicação do sistema SAP HANA, confira Configurar provedores HANA HA/DR.
[A] Iniciar o SAP HANA em ambos os nós. Execute como <sid>adm.
sapcontrol -nr 03 -function StartSystem[1] Verifique a instalação do gancho. Execute como <sid>adm no site ativo de replicação do sistema HANA.
cdtrace awk '/ha_dr_SAPHanaSR.*crm_attribute/ \ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_* # Example output # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOKVerifique a instalação do gancho susChkSrv. Executar como <sid>adm em todas as VMs HANA
cdtrace egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc # Example output # 2022-11-03 18:06:21.116728 susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9 # 2022-11-03 18:06:27.613588 START: indexserver event looks like graceful tenant start # 2022-11-03 18:07:56.143766 START: indexserver event looks like graceful tenant start (indexserver started)
Crie os recursos de cluster do SAP HANA
Primeiro, crie a topologia HANA. Execute os seguintes comandos em um dos nós de cluster do Pacemaker:
sudo crm configure property maintenance-mode=true
# Replace the bold string with your instance number and HANA system ID
sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
operations \$id="rsc_sap2_HN1_HDB03-operations" \
op monitor interval="10" timeout="600" \
op start interval="0" timeout="600" \
op stop interval="0" timeout="300" \
params SID="HN1" InstanceNumber="03"
sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
meta clone-node-max="1" target-role="Started" interleave="true"
Em seguida, crie os recursos do HANA:
Importante
Testes recentes revelaram situações em que o netcat deixa de responder às solicitações devido à lista de pendências e à limitação dele de manipular apenas uma conexão. O recurso netcat deixa de escutar as solicitações do Azure Load Balancer e o IP flutuante fica não disponível.
Para os clusters existentes do Pacemaker, recomendamos a substituição do netcat pelo socat. No momento, é recomendável usar o agente de recursos do azure-lb, que faz parte do pacote resource-agents, com os seguintes requisitos de versão do pacote:
- Para o SLES 12 SP4/SP5, a versão deve ser pelo menos resource-agents-4.3.018.a7fb5035-3.30.1.
- Para o SLES 15/15 SP1, a versão deve ser pelo menos resource-agents-4.3.0184.6ee15eb2-4.13.1.
Observe que a alteração exigirá um breve tempo de inatividade.
Para clusters do Pacemaker existentes, se a configuração já foi alterada para usar socat conforme descrito em Proteção de Detecção do Azure Load Balancer, não há nenhum requisito para mudar imediatamente para o agente de recursos azure-lb.
Observação
Este artigo contém referências aos termos mestre e escravo, os quais a Microsoft não usa mais. Quando esses termos forem removidos do software, nós os removeremos deste artigo.
# Replace the bold string with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer.
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHana \
operations \$id="rsc_sap_HN1_HDB03-operations" \
op start interval="0" timeout="3600" \
op stop interval="0" timeout="3600" \
op promote interval="0" timeout="3600" \
op monitor interval="60" role="Master" timeout="700" \
op monitor interval="61" role="Slave" timeout="700" \
params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"
sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
meta notify="true" clone-max="2" clone-node-max="1" \
target-role="Started" interleave="true"
sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
meta target-role="Started" \
operations \$id="rsc_ip_HN1_HDB03-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.0.0.13"
sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
msl_SAPHana_HN1_HDB03:Master
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
msl_SAPHana_HN1_HDB03
# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_HN1_HDB03
sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000
Importante
Como uma prática recomendada, sugerimos que você só defina AUTOMATED_REGISTER como no, enquanto executa testes de failover completos, para evitar que a instância primária com falha seja registrada automaticamente como secundária. Depois que os testes de failover forem concluídos com êxito, defina AUTOMATED_REGISTER como yes, para que, após a aquisição, a replicação do sistema possa ser retomada automaticamente.
Certifique-se de que o status do cluster está correto e que todos os recursos foram iniciados. Não é importante saber em qual nó os recursos estão sendo executados.
sudo crm_mon -r
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
Configurar a replicação de sistema ativa/habilitada para leitura do HANA no cluster do Pacemaker
Começando com o SAP HANA 2.0 SPS 01, o SAP permite a configuração ativa/habilitada para leitura da replicação de sistema do SAP HANA, em que os sistemas secundários de replicação de sistema do SAP HANA podem ser usados ativamente para cargas de trabalho com uso intensivo de leitura. Para dar suporte a essa configuração em um cluster, um segundo endereço IP virtual é necessário. Isso permite que os clientes acessem o banco de dados secundário do SAP HANA habilitado para leitura. Para garantir que o site de replicação secundária ainda possa ser acessado após uma tomada de controle, o cluster precisa mover o endereço IP virtual com o secundário do recurso SAPHana.
Esta seção descreve as etapas adicionais necessárias para gerenciar a replicação de sistema ativa/habilitada para leitura do HANA em um cluster de alta disponibilidade do SUSE com um segundo IP virtual.
Antes de continuar, verifique se você configurou totalmente o cluster de alta disponibilidade do SUSE, gerenciando o banco de dados do SAP HANA conforme descrito nos segmentos acima da documentação.
Configuração adicional no Azure Load Balancer para configuração ativa/habilitada para leitura
Para continuar com as etapas adicionais sobre o provisionamento do segundo IP virtual, verifique se você configurou o Azure Load Balancer conforme descrito na seção Implantação manual.
Para o Standard Load Balancer, siga as etapas adicionais abaixo no mesmo balanceador de carga que você criou na seção anterior.
a. Crie um segundo pool de IPs de front-end:
- Abra o balanceador de carga, selecione pool de front-end e selecione Adicionar.
- Insira o nome do segundo pool de IPs de front-end (por exemplo, hana-secondaryIP).
- Defina a Atribuição como Estático e insira o endereço IP (por exemplo, 10.0.0.14).
- Selecione OK.
- Depois que o novo pool de IPs de front-end for criado, anote o endereço IP de front-endereço IP de front-end.
b. Em seguida, crie uma investigação de integridade:
- Abra o balanceador de carga, selecione investigações de integridade e selecione Adicionar.
- Insira o nome da nova investigação de integridade (por exemplo, hana-secondaryhp).
- Selecione TCP como o protocolo e a porta 62603. Mantenha o valor do Intervalo como 5 e o valor Limite não íntegro como 2.
- Selecione OK.
c. Em seguida, crie as regras de balanceamento de carga:
- Abra o balanceador de carga, selecione Regras de balanceamento de carga e selecione Adicionar.
- Insira o nome da nova regra do balanceador de carga (por exemplo hana-secondarylb).
- Selecione o endereço IP de front-end, o pool de back-end e a investigação de integridade que você criou anteriormente (por exemplo, hana-secondaryIP, hana-backend e hana-secondaryhp).
- Selecione Portas de HA.
- Aumente o tempo limite de ociosidade para 30 minutos.
- Certifique-se de habilitar IP Flutuante.
- Selecione OK.
Configurar a replicação de sistema ativa/habilitada para leitura do HANA
As etapas para configurar a replicação do sistema HANA são descritas na seção Configurar a replicação do sistema SAP HANA 2.0. Se você estiver implantando o cenário secundário habilitado para leitura, ao configurar a replicação do sistema no segundo nó, execute o seguinte comando como hanasidadm:
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess
Como adicionar um recurso de endereço IP virtual secundário para uma configuração ativa/habilitada para leitura
O segundo IP virtual e a restrição de colocação apropriada podem ser configurados com os seguintes comandos:
crm configure property maintenance-mode=true
crm configure primitive rsc_secip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
meta target-role="Started" \
operations \$id="rsc_secip_HN1_HDB03-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.0.0.14"
crm configure primitive rsc_secnc_HN1_HDB03 azure-lb port=62603 \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
crm configure group g_secip_HN1_HDB03 rsc_secip_HN1_HDB03 rsc_secnc_HN1_HDB03
crm configure colocation col_saphana_secip_HN1_HDB03 4000: g_secip_HN1_HDB03:Started \
msl_SAPHana_HN1_HDB03:Slave
crm configure property maintenance-mode=false
Certifique-se de que o status do cluster está correto e que todos os recursos foram iniciados. O segundo IP virtual será executado no site secundário junto com o recurso secundário SAPHana.
sudo crm_mon -r
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
# rsc_secip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
# rsc_secnc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Na próxima seção, você pode encontrar o conjunto típico de testes de failover a serem executados.
Lembre-se do comportamento do segundo IP virtual, ao testar um cluster HANA configurado com um secundário habilitado para leitura:
Quando você migra o recurso de cluster SAPHana_HN1_HDB03 para hn1-db-1, o segundo IP virtual será movido para o outro servidor hn1-db-0. Caso você tenha configurado AUTOMATED_REGISTER="false" e a replicação do sistema HANA não tenha sido registrada automaticamente, o segundo IP virtual é executado em hn1-db-0, pois o servidor está disponível e os serviços de cluster estão online.
Ao testar uma falha do servidor, os recursos do segundo IP virtual (rsc_secip_HN1_HDB03) e o recurso de porta do Azure Load Balancer (rsc_secnc_HN1_HDB03) serão executados no servidor primário junto com os recursos de IP virtual primários. Enquanto o servidor secundário está inativo, os aplicativos que estão conectados ao banco de dados HANA habilitado para leitura vão se conectar ao banco de dados HANA primário. O comportamento é esperado porque você não deseja que os aplicativos conectados ao banco de dados HANA habilitado para leitura fiquem inacessíveis enquanto o servidor secundário não estiver disponível.
Quando o servidor secundário estiver disponível e os serviços de cluster estiverem online, o segundo IP virtual e os recursos de porta serão movidos automaticamente para o servidor secundário, mesmo que a replicação do sistema HANA não possa ser registrada como secundária. Você precisa garantir que registrou o banco de dados secundário do HANA como habilitado para leitura antes de iniciar os serviços de cluster nesse servidor. Você pode configurar o recurso de cluster da instância do HANA para registrar automaticamente o secundário definindo o parâmetro AUTOMATED_REGISTER=true.
Durante o failover e o fallback, as conexões existentes para aplicativos, usando o segundo IP virtual para se conectar ao banco de dados do HANA, podem ser interrompidas.
Testar a configuração do cluster
Esta seção descreve como é possível testar a configuração. Todos os testes assumem que você é raiz e o mestre do SAP HANA está em execução na máquina virtual hn1-db-0.
Testar a migração
Antes de iniciar o teste, certifique-se de que o Pacemaker não tem nenhuma ação com falha (via crm_mon -r), não há restrições de locais inesperadas (por exemplo, sobras de um teste de migração) e que o HANA está em estado de sincronização, por exemplo, com SAPHanaSR-showAttr:
hn1-db-0:~ # SAPHanaSR-showAttr
Sites srHook
----------------
SITE2 SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts clone_state lpa_hn1_lpt node_state op_mode remoteHost roles score site srmode sync_state version vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED 1534159564 online logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150 SITE1 sync PRIM 2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED 30 online logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100 SITE2 sync SOK 2.00.030.00.1522209842 nws-hana-vm-1
É possível migrar o nó mestre do SAP HANA executando o comando a seguir:
crm resource move msl_SAPHana_HN1_HDB03 hn1-db-1 force
Se você definir AUTOMATED_REGISTER="false", essa sequência de comandos deverá migrar o nó mestre do SAP HANA e o grupo que contém o endereço IP virtual para hn1-db-1.
Quando a migração estiver concluída, a saída crm_mon -r será semelhante a esta
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms
O recurso do SAP HANA em hn1-db-0 falhará em ser iniciado como secundário. Nesse caso, configure a instância do HANA como secundária, executando este comando:
su - hn1adm
# Stop the HANA instance just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr 03 -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
A migração cria restrições de local que precisam ser excluídas novamente:
# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_HN1_HDB03
Também é necessário limpar o estado do recurso de nó secundário:
hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
Monitore o estado do recurso do HANA usando crm_mon -r. Depois que o HANA for iniciado em hn1-db-0, a saída deverá ser semelhante a esta
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Testar o agente de isolamento do Azure (não SBD)
É possível testar a configuração do agente de isolamento do Azure, desabilitando a interface de rede no nó hn1-db-0:
sudo ifdown eth0
A máquina virtual agora deverá reiniciar ou parar, dependendo da configuração do cluster.
Se você definir a configuração stonith-action como desativada, a máquina virtual será interrompida e os recursos migrados para a máquina virtual em execução.
Após iniciar a máquina virtual novamente, o recurso SAP HANA não será iniciado como secundário se você definir AUTOMATED_REGISTER="false". Nesse caso, configure a instância do HANA como secundária, executando este comando:
su - hn1adm
# Stop the HANA instance just in case it is running
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
Testar isolamento de SBD
É possível testar a configuração de SBD eliminando o processo de inquisidor.
hn1-db-0:~ # ps aux | grep sbd
root 1912 0.0 0.0 85420 11740 ? SL 12:25 0:00 sbd: inquisitor
root 1929 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root 1930 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root 1931 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root 1932 0.0 0.0 90524 16656 ? SL 12:25 0:00 sbd: watcher: Pacemaker
root 1933 0.0 0.0 102708 28260 ? SL 12:25 0:00 sbd: watcher: Cluster
root 13877 0.0 0.0 9292 1572 pts/0 S+ 12:27 0:00 grep sbd
hn1-db-0:~ # kill -9 1912
O nó de cluster hn1-db-0 deve ser reiniciado. O serviço Pacemaker pode não ser iniciado posteriormente. Certifique-se de iniciá-lo novamente.
Testar um failover manual
Você pode testar um failover manual, parando o serviço pacemaker no nó hn1-db-0:
service pacemaker stop
Após o failover, você pode iniciar o serviço novamente. Se você definir AUTOMATED_REGISTER="false", o recurso do SAP HANA no nó hn1-db-0 não será iniciado como secundário. Nesse caso, configure a instância do HANA como secundária, executando este comando:
service pacemaker start
su - hn1adm
# Stop the HANA instance just in case it is running
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
Testes de SUSE
Importante
Selecione o sistema operacional SAP certificado para o SAP HANA nos tipos de VM específicos que você está usando. A lista de tipos de VM certificados do SAP HANA e suas versões do sistema operacional podem ser pesquisados em Plataformas de IaaS certificadas do SAP HANA. Clique nos detalhes do tipo de VM listado para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para o tipo de VM específico
Execute todos os casos de teste listados no guia Cenário otimizado para desempenho do SR do SAP HANA ou Cenário otimizado para custo do SR do SAP HANA, dependendo do caso de uso. Os guias podem ser encontrados na página de melhores práticas do SLES para SAP.
Os testes a seguir são uma cópia das descrições de teste do guia de Cenário otimizado para desempenho do SR do SAP HANA do SUSE Linux Enterprise Server para Aplicativos SAP 12 SP1. Para uma versão atualizada, sempre leia também o próprio guia. Antes de iniciar o teste, sempre certifique-se de que o HANA está em sincronização e também que a configuração do Pacemaker está correta.
Nas descrições de teste a seguir, assumimos PREFER_SITE_TAKEOVER="true" e AUTOMATED_REGISTER="false". OBSERVAÇÃO: os testes a seguir foram projetados para serem executados em sequência e dependem do estado de saída dos testes anteriores.
TESTE 1: PARAR O BANCO DE DADOS PRIMÁRIO NO NÓ 1
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Execute os seguintes comandos como <hanasid>adm no nó hn1-db-0:
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stopO Pacemaker deve detectar a instância do HANA parada e o failover para o outro nó. Depois que o failover é concluído, a instância do HANA no nó hn1-db-0 é interrompida porque o Pacemaker não registra automaticamente o nó como secundário do HANA.
Execute os seguintes comandos para registrar o nó hn1-db-0 como secundário e limpar o recurso com falha.
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1 # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1TESTE 2: PARAR O BANCO DE DADOS PRIMÁRIO NO NÓ 2
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1Execute os seguintes comandos como <hanasid>adm no nó hn1-db-1:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stopO Pacemaker deve detectar a instância do HANA parada e o failover para o outro nó. Depois que o failover é concluído, a instância do HANA no nó hn1-db-1 é interrompida porque o Pacemaker não registra automaticamente o nó como secundário do HANA.
Execute os seguintes comandos para registrar o nó hn1-db-1 como secundário e limpar o recurso com falha.
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TESTE 3: BANCO DE DADOS PRIMÁRIO COM FALHA NO NÓ
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Execute os seguintes comandos como <hanasid>adm no nó hn1-db-0:
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9O Pacemaker deve detectar a instância do HANA encerrada e o failover para o outro nó. Depois que o failover é concluído, a instância do HANA no nó hn1-db-0 é interrompida porque o Pacemaker não registra automaticamente o nó como secundário do HANA.
Execute os seguintes comandos para registrar o nó hn1-db-0 como secundário e limpar o recurso com falha.
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1 # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1TESTE 4: BANCO DE DADOS PRIMÁRIO COM FALHA NO NÓ 2
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1Execute os seguintes comandos como <hanasid>adm no nó hn1-db-1:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9O Pacemaker deve detectar a instância do HANA encerrada e o failover para o outro nó. Depois que o failover é concluído, a instância do HANA no nó hn1-db-1 é interrompida porque o Pacemaker não registra automaticamente o nó como secundário do HANA.
Execute os seguintes comandos para registrar o nó hn1-db-1 como secundário e limpar o recurso com falha.
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TESTE 5: NÓ DO SITE PRIMÁRIO COM FALHA (NÓ 1)
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Execute os comandos a seguir como raiz no nó hn1-db-0:
hn1-db-0:~ # echo 'b' > /proc/sysrq-triggerO Pacemaker deve detectar o nó do cluster encerrado e isolar o nó. Depois que o nó for isolado, o Pacemaker disparará a tomada de controle da instância do HANA. Quando o nó isolado for reiniciado, o Pacemaker não iniciará automaticamente.
Execute os comandos a seguir para iniciar o Pacemaker, limpe as mensagens do SBD para o nó hn1-db-0, registre o nó hn1-db-0 como secundário e limpe o recurso com falha.
# run as root # list the SBD device(s) hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear hn1-db-0:~ # systemctl start pacemaker # run as <hanasid>adm hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1 # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1TESTE 6: NÓ DO SITE SECUNDÁRIO COM FALHA (NÓ 2)
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1Execute os comandos a seguir como raiz no nó hn1-db-1:
hn1-db-1:~ # echo 'b' > /proc/sysrq-triggerO Pacemaker deve detectar o nó do cluster encerrado e isolar o nó. Depois que o nó for isolado, o Pacemaker disparará a tomada de controle da instância do HANA. Quando o nó isolado for reiniciado, o Pacemaker não iniciará automaticamente.
Execute os comandos a seguir para iniciar o Pacemaker, limpe as mensagens do SBD para o nó hn1-db-1, registre o nó hn1-db-1 como secundário e limpe o recurso com falha.
# run as root # list the SBD device(s) hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear hn1-db-1:~ # systemctl start pacemaker # run as <hanasid>adm hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TESTE 7: PARAR BANCO DE DADOS SECUNDÁRIO NO NÓ 2
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Execute os seguintes comandos como <hanasid>adm no nó hn1-db-1:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stopO Pacemaker detectará a instância do HANA parada e marcará o recurso como com falha no nó hn1-db-1. O Pacemaker deverá reiniciar automaticamente a instância do HANA. Execute o seguinte comando para limpar o estado com falha.
# run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TESTE 8: BANCO DE DADOS SECUNDÁRIO COM FALHA NO NÓ 2
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Execute os seguintes comandos como <hanasid>adm no nó hn1-db-1:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9O Pacemaker detectará a instância do HANA encerrada e marcará o recurso como com falha no nó hn1-db-1. Execute o seguinte comando para limpar o estado com falha. Em seguida, o Pacemaker deverá reiniciar automaticamente a instância do HANA.
# run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TEST 9: NÓ DO SITE SECUNDÁRIO COM FALHA (NÓ 2) EXECUTANDO BANCO DE DADOS HANA SECUNDÁRIO
Estado do recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Execute os comandos a seguir como raiz no nó hn1-db-1:
hn1-db-1:~ # echo b > /proc/sysrq-triggerO Pacemaker deve detectar o nó do cluster encerrado e isolar o nó. Quando o nó isolado for reiniciado, o Pacemaker não iniciará automaticamente.
Execute os seguintes comandos para iniciar o Pacemaker, limpe as mensagens do SBD para o nó hn1-db-1 e limpe o recurso com falha.
# run as root # list the SBD device(s) hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear hn1-db-1:~ # systemctl start pacemaker hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Estado do recurso após o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0