Configurar o Pacemaker no Red Hat Enterprise Linux no Azure
Este artigo descreve como configurar um cluster Pacemaker básico no Red Hat Enterprise Server (RHEL). As instruções abrangem RHEL 7, RHEL 8 e RHEL 9.
Pré-requisitos
Primeiro, leia os seguintes documentos e Notas SAP:
- A Nota SAP 1928533, que tem:
- Uma lista de tamanhos de máquina virtual (VM) do Azure com suporte para a implantação de software SAP.
- Informações importantes sobre capacidade para tamanhos de VM do Azure.
- O software SAP suportado e as combinações de sistema operacional (SO) e banco de dados.
- A versão do kernel do SAP necessária para Windows e Linux no Microsoft Azure.
- A Nota SAP 2015553 lista pré-requisitos para implantações de software SAP com suporte do SAP no Azure.
- O SAP Note 2002167 recomenda as configurações do sistema operacional para o Red Hat Enterprise Linux.
- O SAP Note 3108316 recomenda as configurações do sistema operacional para o Red Hat Enterprise Linux 9.x.
- A Nota SAP 2009879 tem diretrizes SAP HANA para Red Hat Enterprise Linux.
- A SAP Note 3108302 tem as diretrizes do SAP HANA para Red Hat Enterprise Linux 9.x.
- A Nota SAP 2178632 contém informações detalhadas sobre todas as métricas de monitoramentos relatadas para o 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 1999351 tem mais informações de solução de problemas para a Extensão de Monitoramento Avançado do Azure para SAP.
- WIKI da comunidade do SAP tem todas as Notas SAP necessárias para Linux.
- 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)
- Implantação de Máquinas Virtuais do Azure do DBMS para SAP no Linux
- Replicação do sistema SAP HANA no cluster Pacemaker
- Documentação geral do RHEL:
- Documentação do RHEL específica do Azure:
- Políticas de suporte para clusters de alta disponibilidade RHEL - Máquinas virtuais do Microsoft Azure como membros do cluster
- Instalando e configurando um Cluster de alta disponibilidade do Red Hat Enterprise Linux 7.4 (e posterior) no Microsoft Azure
- Considerações na adoção do RHEL 8 - Alta disponibilidade e clusters
- Configurar o SAP S/4HANA ASCS/ERS com o ENSA2 (Servidor de Enfileiramento Autônomo 2) no Pacemaker no RHEL 7.6
- RHEL para ofertas SAP no Azure
Instalação do Cluster
Observação
A Red Hat não oferece suporte a um cão de guarda emulado por software. A Red Hat não dá suporte a SBD em plataformas de nuvem. Para obter mais informações, consulte Políticas de suporte para clusters de alta disponibilidade RHEL - sbd e fence_sbd.
O único mecanismo de vedação com suporte para clusters RHEL do Pacemaker no Azure é um agente de cerca do Azure.
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
As diferenças nos comandos ou na configuração entre o RHEL 7 e o RHEL 8/RHEL 9 são marcadas no documento.
[A] Registrar. Esta etapa é opcional. Se você estiver usando imagens habilitadas para RHEL SAP HA, esta etapa não será necessária.
Por exemplo, se você estiver implantando no RHEL 7, registre sua VM e anexe-a a um pool que contenha repositórios para o RHEL 7.
sudo subscription-manager register # List the available pools sudo subscription-manager list --available --matches '*SAP*' sudo subscription-manager attach --pool=<pool id>
Quando você anexa um pool a uma imagem RHEL paga conforme o uso do Azure Marketplace, você é efetivamente cobrado duas vezes pelo uso do RHEL. Você é cobrado uma vez pela imagem de pagamento conforme o uso e uma vez pelo direito RHEL no pool que você anexa. Para mitigar essa situação, o Azure agora fornece imagens RHEL traga sua própria assinatura. Para saber mais, confira Imagens do Azure do tipo Traga Sua Própria Assinatura do Red Hat Enterprise Linux.
[A] Habilitar RHEL para os repositórios do SAP. Esta etapa é opcional. Se você estiver usando imagens habilitadas para RHEL SAP HA, esta etapa não será necessária.
Para instalar os pacotes necessários no RHEL 7, habilite os seguintes repositórios:
sudo subscription-manager repos --disable "*" sudo subscription-manager repos --enable=rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms
[A] Instale o complemento RHEL HA.
sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat
Importante
Recomendamos as seguintes versões do agente de cerca do Azure (ou posterior) para que os clientes se beneficiem de um tempo de failover mais rápido, se uma parada de recurso falhar ou os nós de cluster não puderem mais se comunicar uns com os outros:
O RHEL 7.7 ou superior usa a versão mais recente disponível do pacote fence-agents.
RHEL 7.6: fence-agents-4.2.1-11.el7_6.8
RHEL 7.5: fence-agents-4.0.11-86.el7_5.8
RHEL 7.4: fence-agents-4.0.11-66.el7_4.12
Para obter mais informações, consulte VM do Azure em execução como um membro de cluster de alta disponibilidade do RHEL leva muito tempo para ser cercada ou a vedação falha/tempo limite antes que a VM seja encerrada.
Importante
Recomendamos as seguintes versões do agente de cerca do Azure (ou posterior) para clientes que desejam usar identidades gerenciadas para recursos do Azure em vez de nomes de entidade de serviço para o agente de cerca:
RHEL 8.4: agentes de cerca-4.2.1-54.el8.
RHEL 8.2: fence-agents-4.2.1-41.el8_2.4
RHEL 8.1: fence-agents-4.2.1-30.el8_1.4
RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.
Importante
No RHEL 9, recomendamos as seguintes versões de pacote (ou posteriores) para evitar problemas com o agente de cerca do Azure:
agentes de cerca-4.10.0-20.el9_0.7
agentes de cerca-comum-4.10.0-20.el9_0.6
ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm
Verifique a versão do agente de isolamento do Azure. Se necessário, atualize-o para a versão mínima necessária ou posterior.
# Check the version of the Azure Fence Agent sudo yum info fence-agents-azure-arm
Importante
Se você precisar atualizar o agente de cerca do Azure e se estiver usando uma função personalizada, atualize a função personalizada para incluir a ação powerOff. Para obter mais informações, consulte Criar uma função personalizada para o agente de cerca.
Se você estiver implantando no RHEL 9, instale também os agentes de recursos para implantação na nuvem.
sudo yum install -y resource-agents-cloud
[A] Configurar a resolução de nome do host.
Você pode 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.Importante
Se você estiver usando nomes de host na configuração do cluster, é vital ter uma resolução de nome de host confiável. A comunicação do cluster falhará se os nomes não estiverem disponíveis, o que pode levar a atrasos de failover de cluster.
O benefício de usar
/etc/hosts
é que seu cluster se torna independente do DNS, o que também pode ser um ponto único de falhas.sudo vi /etc/hosts
Insira as seguintes linhas até
/etc/hosts
. Altere o endereço IP e o nome do host para corresponder ao seu ambiente.# IP address of the first cluster node 10.0.0.6 prod-cl1-0 # IP address of the second cluster node 10.0.0.7 prod-cl1-1
[A] Altere a senha para a
hacluster
mesma senha.sudo passwd hacluster
[A] Adicione regras de firewall para o Pacemaker.
Adicione as seguintes regras de firewall para todas as comunicações de cluster entre os nós do cluster.
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --add-service=high-availability
[A] Habilite os serviços básicos de cluster.
Execute os seguintes comandos para habilitar o serviço Pacemaker e iniciá-lo.
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service
[1] Criar um cluster de marcapasso.
Execute os seguintes comandos para autenticar os nós e criar o cluster. Defina o token como 30000 para permitir a manutenção de preservação da memória. Para obter mais informações, confira este artigo para Linux.
Se você estiver criando um cluster no RHEL 7.x, use os seguintes comandos:
sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000 sudo pcs cluster start --all
Se você estiver criando um cluster no RHEL 8.x/RHEL 9.x, use os seguintes comandos:
sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000 sudo pcs cluster start --all
Verifique o status do cluster executando o seguinte comando:
# Run the following command until the status of both nodes is online sudo pcs status # Cluster name: nw1-azr # WARNING: no stonith devices and stonith-enabled is not false # Stack: corosync # Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum # Last updated: Fri Aug 17 09:18:24 2018 # Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1 # # 2 nodes configured # 0 resources configured # # Online: [ prod-cl1-0 prod-cl1-1 ] # # No resources # # Daemon Status: # corosync: active/disabled # pacemaker: active/disabled # pcsd: active/enabled
[A] Definir os votos esperados.
# Check the quorum votes pcs quorum status # If the quorum votes are not set to 2, execute the next command sudo pcs quorum expected-votes 2
Dica
Se você estiver criando um cluster de vários nós, ou seja, um cluster com mais de dois nós, não defina os votos como 2.
[1] Permitir ações de vedação simultâneas.
sudo pcs property set concurrent-fencing=true
Criar um dispositivo de vedação
O dispositivo de vedação usa uma identidade gerenciada para o recurso do Azure ou uma entidade de serviço para autorizar no Azure.
Para criar uma MSI (identidade gerenciada), crie uma identidade gerenciada atribuída pelo sistema para cada VM no cluster. Se já existir uma identidade gerenciada atribuída pelo sistema, ela será usada. Não use identidades gerenciadas atribuídas pelo usuário com o Pacemaker no momento. Um dispositivo de cerca, baseado na identidade gerenciada, é suportado no RHEL 7.9 e no RHEL 8.x/RHEL 9.x.
[1] Criar uma função personalizada para o agente de isolamento
A identidade gerenciada e a entidade de serviço não têm permissões para acessar seus recursos do Azure por padrão. Você precisa conceder à identidade gerenciada ou à entidade de serviço permissões para iniciar e parar (desligar) todas as VMs do cluster. Se você ainda não tiver criado a função personalizada, poderá criá-la usando o PowerShell ou a CLI do Azure.
Use o seguinte conteúdo para o arquivo de entrada. Você precisa adaptar o conteúdo às suas assinaturas, ou seja, substituir xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
e yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
pelos IDs da sua assinatura. Se você tiver apenas uma assinatura, remova a segunda entrada no AssignableScopes
.
{
"Name": "Linux Fence Agent Role",
"description": "Allows to power-off and start virtual machines",
"assignableScopes": [
"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
],
"actions": [
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
[A] Atribuir a função personalizada
Use identidade gerenciada ou entidade de serviço.
Atribua a função Linux Fence Agent Role
personalizada criada na última seção a cada identidade gerenciada das VMs de cluster. Cada identidade gerenciada atribuída pelo sistema da VM precisa da função atribuída para o recurso de cada VM de cluster. Para obter mais informações, confira Atribuir o acesso de uma identidade gerenciada a um recurso usando o portal do Azure. Verifique se a atribuição de função de identidade gerenciada de cada VM contém todas as VMs de cluster.
Importante
Lembre-se de que a atribuição e a remoção de autorização com identidades gerenciadas podem ser adiadas até que sejam efetivadas.
[1] Criar os dispositivos de isolamento
Depois de editar as permissões para as VMs, você pode configurar os dispositivos de vedação no cluster.
sudo pcs property set stonith-timeout=900
Observação
A opção pcmk_host_map
só será necessária no comando se os nomes de host RHEL e os nomes de VM do Azure não forem idênticos. Especifique o mapeamento no formato nome do host: vm-name.
Consulte a seção em negrito no comando. Para obter mais informações, consulte Que formato devo usar para especificar mapeamentos de nó para dispositivos de vedação no pcmk_host_map?.
Para RHEL 7.x, use o seguinte comando para configurar o dispositivo fence:
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600
Para RHEL 8.x/9.x, use o seguinte comando para configurar o dispositivo de cerca:
# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600
# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600
Se você estiver usando um dispositivo de vedação com base na configuração da entidade de serviço, leia Alterar de SPN para MSI para clusters do Pacemaker usando a cerca do Azure e saiba como converter para configuração de identidade gerenciada.
Dica
- Para evitar corridas de cerca em um cluster de marcapasso de dois nós, você pode configurar a propriedade do
priority-fencing-delay
cluster. Essa propriedade introduz um atraso adicional no isolamento de um nó que tem uma prioridade total de recursos mais alta quando ocorre um cenário de split-brain. Para obter mais informações, confira O Pacemaker pode isolar o nó de cluster com o menor número de recursos em execução?. - A propriedade
priority-fencing-delay
é aplicável para Pacemaker versão 2.0.4-6.el8 ou superior e em um cluster de dois nós. Se você configurar apriority-fencing-delay
propriedade de cluster, não precisará defini-lapcmk_delay_max
. Mas se a versão do Pacemaker for menor que 2.0.4-6.el8, você precisará definir apcmk_delay_max
propriedade. - Para obter instruções sobre como definir a propriedade de
priority-fencing-delay
cluster, consulte os respectivos documentos SAP ASCS/ERS e SAP HANA scale-up HA.
As operações de monitoramento e limitação são desserializadas. Como resultado, se houver uma operação de monitoramento em execução mais longa e um evento de vedação simultâneo, não haverá atraso no failover do cluster porque a operação de monitoramento já está em execução.
[1] Habilitar o uso de um dispositivo de isolamento
sudo pcs property set stonith-enabled=true
Dica
O agente de cerca do Azure requer conectividade de saída para pontos de extremidade públicos. Para obter mais informações junto com possíveis soluções, consulte Conectividade de ponto de extremidade público para VMs usando ILB padrão.
Configurar o Pacemaker para eventos agendados do Azure
O Azure oferece eventos agendados. Os eventos agendados são enviados por meio do serviço de metadados e dão tempo para que o aplicativo se prepare para esses eventos.
O agente azure-events-az
de recursos do Pacemaker monitora eventos agendados do Azure. Se os eventos forem detectados e o agente de recursos determinar que outro nó de cluster está disponível, ele definirá um atributo de integridade do cluster.
Quando o atributo de integridade do cluster é definido para um nó, a restrição de local é acionada e todos os recursos com nomes que não começam com são migrados para fora do nó com health-
o evento agendado. Depois que o nó de cluster afetado estiver livre de recursos de cluster em execução, o evento agendado será reconhecido e poderá executar sua ação, como uma reinicialização.
[A] Verifique se o pacote do
azure-events-az
agente já está instalado e atualizado.RHEL 8.x: sudo dnf info resource-agents RHEL 9.x: sudo dnf info resource-agents-cloud
Requisitos mínimos de versão:
- RHEL 8.4:
resource-agents-4.1.1-90.13
- RHEL 8.6:
resource-agents-4.9.0-16.9
- RHEL 8.8:
resource-agents-4.9.0-40.1
- RHEL 9.0:
resource-agents-cloud-4.10.0-9.6
- RHEL 9.2 e mais recente:
resource-agents-cloud-4.10.0-34.1
- RHEL 8.4:
[1] Configure os recursos no Pacemaker.
#Place the cluster in maintenance mode sudo pcs property set maintenance-mode=true
[1] Defina a estratégia e a restrição do nó de integridade do cluster do Pacemaker.
sudo pcs property set node-health-strategy=custom sudo pcs constraint location 'regexp%!health-.*' \ rule score-attribute='#health-azure' \ defined '#uname'
Importante
Não defina nenhum outro recurso no cluster começando com
health-
além dos recursos descritos nas próximas etapas.[1] Defina o valor inicial dos atributos do cluster. Executar para cada nó de cluster e para ambientes de expansão, incluindo VM de criador majoritário.
sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0 sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0
[1] Configure os recursos no Pacemaker. Certifique-se de que os recursos comecem com
health-azure
.sudo pcs resource create health-azure-events \ ocf:heartbeat:azure-events-az op monitor interval=10s sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true
Tire o cluster do Pacemaker do modo de manutenção.
sudo pcs property set maintenance-mode=false
Limpe quaisquer erros durante a ativação e verifique se os recursos foram iniciados com êxito em todos os
health-azure-events
nós do cluster.sudo pcs resource cleanup
A execução da primeira consulta para eventos agendados pode levar até dois minutos. O teste de marcapasso com eventos agendados pode usar ações de reinicialização ou reimplantação para as VMs de cluster. Para saber mais, confira Eventos agendados.
Configuração opcional de isolamento
Dica
Esta seção só é aplicável se você quiser configurar o dispositivo fence_kdump
de vedação especial.
Se você precisar coletar informações de diagnóstico na VM, talvez seja útil configurar outro dispositivo de vedação com base no agente fence_kdump
de cerca. O fence_kdump
agente pode detectar que um nó entrou na recuperação de falha do kdump e pode permitir que o serviço de recuperação de falhas seja concluído antes que outros métodos de vedação sejam chamados. Observe que fence_kdump
isso não substitui os mecanismos de cerca tradicionais, como o agente de cerca do Azure, quando você estiver usando VMs do Azure.
Importante
Lembre-se de que, quando fence_kdump
configurado como um dispositivo de vedação de primeiro nível, ele introduz atrasos nas operações de vedação e, respectivamente, atrasos no failover de recursos do aplicativo.
Se um despejo de memória for detectado com êxito, a vedação será adiada até que o serviço de recuperação de falhas seja concluído. Se o nó com falha estiver inacessível ou se não responder, o cercamento será atrasado pelo tempo determinado, pelo número configurado de iterações e pelo fence_kdump
tempo limite. Para obter mais informações, consulte Como configurar fence_kdump em um cluster do Red Hat Pacemaker?.
O tempo limite proposto fence_kdump
pode precisar ser adaptado ao ambiente específico.
Recomendamos que você configure fence_kdump
o cercamento somente quando necessário para coletar diagnósticos dentro da VM e sempre em combinação com métodos de cerca tradicionais, como o agente de cerca do Azure.
Os seguintes artigos da Base de Dados de Conhecimento Red Hat contêm informações importantes sobre como configurar fence_kdump
a cerca:
- Consulte Como configurar fence_kdump em um cluster do Red Hat Pacemaker?.
- Consulte Como configurar/gerenciar níveis de vedação em um cluster RHEL com o Pacemaker.
- Consulte fence_kdump falha com "tempo limite após X segundos" em um cluster RHEL 6 ou 7 HA com kexec-tools anteriores à 2.0.14.
- Para obter informações sobre como alterar o tempo limite padrão, consulte Como configurar o kdump para uso com o complemento RHEL 6, 7, 8 HA?.
- Para obter informações sobre como reduzir o atraso de failover ao usar
fence_kdump
o , consulte Posso reduzir o atraso esperado de failover ao adicionar fence_kdump configuração?.
Execute as etapas opcionais a seguir para adicionar fence_kdump
como uma configuração de vedação de primeiro nível, além da configuração do agente de cerca do Azure.
[A] Verifique se
kdump
está ativo e configurado.systemctl is-active kdump # Expected result # active
[A] Instale o agente de isolamento
fence_kdump
.yum install fence-agents-kdump
[1] Crie um
fence_kdump
dispositivo de vedação no cluster.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30
[1] Configure os níveis de vedação para que o mecanismo de vedação seja ativado
fence_kdump
primeiro.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" pcs stonith level add 1 prod-cl1-0 rsc_st_kdump pcs stonith level add 1 prod-cl1-1 rsc_st_kdump pcs stonith level add 2 prod-cl1-0 rsc_st_azure pcs stonith level add 2 prod-cl1-1 rsc_st_azure # Check the fencing level configuration pcs stonith level # Example output # Target: prod-cl1-0 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure # Target: prod-cl1-1 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure
[A] Permitir que as portas necessárias passem
fence_kdump
pelo firewall.firewall-cmd --add-port=7410/udp firewall-cmd --add-port=7410/udp --permanent
[A] Verifique se o arquivo de
initramfs
imagem contém osfence_kdump
arquivos ehosts
. Para obter mais informações, consulte Como configurar fence_kdump em um cluster do Red Hat Pacemaker?.lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts" # Example output # -rw-r--r-- 1 root root 208 Jun 7 21:42 etc/hosts # -rwxr-xr-x 1 root root 15560 Jun 17 14:59 usr/libexec/fence_kdump_send
[A] Execute a
fence_kdump_nodes
configuração para evitarfence_kdump
falhas com um tempo limite para/etc/kdump.conf
algumaskexec-tools
versões. Para obter mais informações, consulte fence_kdump tempo limite quando fence_kdump_nodes não é especificado com kexec-tools versão 2.0.15 ou posterior e fence_kdump falha com "tempo limite após X segundos" em um cluster RHEL 6 ou 7 High Availability com versões kexec-tools anteriores à 2.0.14. O exemplo de configuração para um cluster de dois nós é apresentado aqui. Depois de fazer uma alteração no/etc/kdump.conf
, a imagem kdump deve ser regenerada. Para regenerar, reinicie okdump
serviço.vi /etc/kdump.conf # On node prod-cl1-0 make sure the following line is added fence_kdump_nodes prod-cl1-1 # On node prod-cl1-1 make sure the following line is added fence_kdump_nodes prod-cl1-0 # Restart the service on each node systemctl restart kdump
Teste a configuração causando falha em um nó. Para obter mais informações, consulte Como configurar fence_kdump em um cluster do Red Hat Pacemaker?.
Importante
Se o cluster já estiver em uso produtivo, planeje o teste de acordo, pois travar um nó tem um impacto no aplicativo.
echo c > /proc/sysrq-trigger
Próximas etapas
- Confira Planejamento e implementação de Máquinas Virtuais do Azure para o SAP.
- Confira Implantação de máquinas virtuais do Azure para SAP.
- Confira Implantação do DBMS de Máquinas Virtuais do Azure para SAP.
- Para saber como estabelecer HA e planejar a recuperação de desastres do SAP HANA em VMs do Azure, consulte Alta disponibilidade do SAP HANA em máquinas virtuais do Azure.