Configurar o Pacemaker no Red Hat Enterprise Linux no Azure

  • Artigo

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:

Instalação do Cluster

Diagram that shows an overview of Pacemaker on RHEL.

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.

  1. [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.

  2. [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

  3. [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.

  4. 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

  5. [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

  6. [A] Altere a senha para a hacluster mesma senha.

    sudo passwd hacluster

  7. [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

  8. [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

  9. [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

  10. [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.

  11. [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 a priority-fencing-delay propriedade de cluster, não precisará defini-la pcmk_delay_max . Mas se a versão do Pacemaker for menor que 2.0.4-6.el8, você precisará definir a pcmk_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.

  1. [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

  2. [1] Configure os recursos no Pacemaker.

    #Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true

  3. [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.

  4. [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

  5. [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

  6. Tire o cluster do Pacemaker do modo de manutenção.

    sudo pcs property set maintenance-mode=false

  7. 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_kdumpde 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_kdumpde 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:

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.

  1. [A] Verifique se kdump está ativo e configurado.

    systemctl is-active kdump
# Expected result
# active

  2. [A] Instale o agente de isolamento fence_kdump.

    yum install fence-agents-kdump

  3. [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

  4. [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

  5. [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

  6. [A] Verifique se o arquivo de initramfs imagem contém os fence_kdump arquivos e hosts . 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

  7. [A] Execute a fence_kdump_nodes configuração para evitar fence_kdump falhas com um tempo limite para /etc/kdump.conf algumas kexec-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 o kdump 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

  8. 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