Ler em inglês

Partilhar via


Configurar um cluster do Pacemaker para grupos de disponibilidade do SQL Server

Aplica-se a: SQL Server – Linux

Este artigo descreve como criar um cluster de três nós no Linux usando o Pacemaker e como adicionar um grupo de disponibilidade criado anteriormente como um recurso no cluster. Para alta disponibilidade, um grupo de disponibilidade em Linux exige três nós – consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Nota

Comunicação livre de desvio

Este artigo contém referências ao termo subordinado, um termo que a Microsoft considera ofensivo quando usado neste contexto. O termo aparece neste artigo porque ele atualmente aparece no software. Quando o termo for removido do software, também o removeremos do artigo.

O SQL Server não é tão totalmente integrado ao Pacemaker no Linux quanto ao WSFC (clustering de failover do Windows Server). Uma instância do SQL Server não reconhece o cluster, e toda a orquestração é feita de fora para dentro. O Pacemaker fornece orquestração de recursos de cluster. Além disso, o nome da rede virtual é específico do clustering de failover do Windows Server. Não há um equivalente no Pacemaker. As DMVs (exibições de gerenciamento dinâmico) do grupo de disponibilidade que consultam as informações do cluster retornam linhas vazias em clusters do Pacemaker. Para criar um ouvinte de reconexão transparente após o failover, registre manualmente o nome do ouvinte em DNS com o IP usado para criar o recurso de IP virtual.

Você ainda poderá criar um ouvinte para usá-lo para reconexão transparente após o failover, mas será necessário registrar manualmente o nome do ouvinte no servidor DNS com o IP usado para criar o recurso de IP virtual (conforme explicado nas seções a seguir).

As seções a seguir descrevem as etapas necessárias para configurar um cluster do Pacemaker e adicionar um grupo de disponibilidade como um recurso no cluster para alta disponibilidade a cada distribuição do Linux com suporte.

A camada de clustering baseia-se no HAE (Extensão de Alta Disponibilidade) do SUSE criado com base no Pacemaker.

Para obter mais informações sobre configuração de cluster, opções do agente de recursos, gerenciamento, melhores práticas e recomendações, confira Extensão de alta disponibilidade do SUSE Linux Enterprise.

Roteiro

O procedimento para criação de um grupo de disponibilidade para alta disponibilidade é distinto em servidores Linux e em um cluster de failover do Windows Server. A lista a seguir descreve as etapas de alto nível:

  1. Configurar o SQL Server nos nós de cluster.

  2. Criar o grupo de disponibilidade.

  3. Configurar um gerenciador de recursos de cluster, como o Pacemaker. Essas instruções estão contidas neste artigo.

    A maneira de configurar um gerenciador de recursos de cluster depende da distribuição específica do Linux.

    Importante

    Os ambientes de produção exigem um agente de isolamento para alta disponibilidade. Os exemplos neste artigo não usam agentes de isolamento. Eles se destinam apenas a teste e validação.

    Um cluster do Linux usa o isolamento para retornar o cluster a um estado conhecido. A maneira de configurar o isolamento depende da distribuição e do ambiente. Atualmente, o isolamento não está disponível em alguns ambientes de nuvem. Para obter mais informações, confira Extensão de alta disponibilidade do SUSE Linux Enterprise Server.

  4. Adicionar o grupo de disponibilidade como um recurso no cluster

Pré-requisitos

Para concluir o cenário de ponta a ponta a seguir, você precisará de três computadores para implantar o cluster de três nós. As etapas a seguir descrevem como configurar esses servidores.

Instalar e configurar o sistema operacional em cada nó de cluster

A primeira etapa é configurar o sistema operacional nos nós de cluster. Nesta etapa, use o SLES 12 SP3 com uma assinatura válida para executar o complemento de HA.

Instalar e configurar o serviço SQL Server em cada nó de cluster

  1. Instalar e configurar o serviço SQL Server em todos os nós. Para obter instruções detalhadas, confira Diretrizes de instalação para o SQL Server no Linux.

  2. Designe um nó como primário e outros nós como secundários. Use esses termos em todo este guia.

  3. Verifique se os nós que farão parte do cluster podem se comunicar entre si.

    O exemplo a seguir mostra /etc/hosts com adições para três nós chamados SLES1, SLES2 e SLES3.

    127.0.0.1   localhost
    10.128.16.33 SLES1
    10.128.16.77 SLES2
    10.128.16.22 SLES3
    

    Todos os nós de cluster precisam conseguir acessar um ao outro via SSH. Ferramentas como hb_report ou crm_report (para solução de problemas) e Gerenciador de Histórico do Hawk exigem acesso SSH sem senha entre os nós, caso contrário, elas só podem coletar dados do nó atual. Caso você use uma porta SSH não padrão, use a opção -X (confira a página man). Por exemplo, se a porta SSH for 3479, invoque um crm_report com:

    sudo crm_report -X "-p 3479" [...]
    

    Para obter mais informações, confira a seção Diversos – Guia de Administração do SLES.

Criar um logon do SQL Server para o Pacemaker

  1. Em todas as instâncias do SQL Server, crie um logon de servidor para o Pacemaker.

    O Transact-SQL a seguir cria um logon:

    USE [master]
    GO
    CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
    
    ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
    

    No momento da criação do grupo de disponibilidade, o usuário do Pacemaker precisará das permissões ALTER, CONTROL e VIEW DEFINITION no grupo de disponibilidade, após ele ser criado mas antes que os nós sejam adicionados a ele.

  2. Em todas as instâncias do SQL Server, salve as credenciais para o logon do SQL Server.

    echo 'pacemakerLogin' >> ~/pacemaker-passwd
    echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
    sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
    sudo chown root:root /var/opt/mssql/secrets/passwd
    sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
    

Configurar um conjunto de disponibilidade

Em servidores Linux, configure o grupo de disponibilidade e, em seguida, configure os recursos de cluster. Para configurar o grupo de disponibilidade, confira Configurar um grupo de disponibilidade Always On do SQL Server para alta disponibilidade no Linux

Instalar e configurar o Pacemaker em cada nó de cluster

  1. Instalar a extensão de Alta Disponibilidade

    Para usar como referência, confira Como instalar o SUSE Linux Enterprise Server e a Extensão de Alta Disponibilidade.

  2. Instale o pacote do agente de recursos do SQL Server em ambos os nós.

    sudo zypper install mssql-server-ha
    

Configurar o primeiro nó

Veja as Instruções de instalação do SLES.

  1. Entre como root no computador físico ou na máquina virtual que deseja usar como o nó de cluster.

  2. Inicie o script de inicialização executando:

    sudo ha-cluster-init
    

    Se o NTP não tiver sido configurado para ser iniciado no momento da inicialização, uma mensagem será exibida.

    Se você decidir continuar mesmo assim, o script vai gerar chaves para o acesso SSH automaticamente e a ferramenta de sincronização Csync2 e iniciará os serviços necessários para ambos.

  3. Para configurar a camada de comunicação do cluster (Corosync):

    1. Insira um endereço de rede para associação. Por padrão, o script propõe o endereço de rede eth0. Como alternativa, insira outro endereço de rede, por exemplo, o endereço bond0.

    2. Insira um endereço multicast. O script propõe um endereço aleatório que pode ser usado como padrão.

    3. Insira uma porta multicast. O script propõe 5405 como o padrão.

    4. Para configurar SBD (), insira um caminho persistente para a partição do dispositivo de bloqueio que você deseja usar para o SBD. O caminho precisa ser consistente em todos os nós no cluster. Por fim, o script iniciará o serviço Pacemaker para colocar o cluster de um nó online e habilitará a interface de gerenciamento da Web Hawk2. A URL a ser usada para o Hawk2 é exibida na tela.

  4. Para obter detalhes sobre o processo de instalação, confira /var/log/sleha-bootstrap.log. Agora você tem um cluster de um nó em execução. Verifique o status do cluster com crm status:

    sudo crm status
    

    Você também poderá ver a configuração do cluster com crm configure show xml ou crm configure show.

  5. O procedimento de inicialização cria um usuário do Linux chamado hacluster com a senha linux. Substitua a senha padrão por uma segura assim que possível:

    sudo passwd hacluster
    

Adicionar nós ao cluster existente

Se você tiver um cluster em execução com um ou mais nós, adicione mais nós de cluster com o script de inicialização ha-cluster-join. O script precisa apenas ter acesso a um nó de cluster existente e concluirá a configuração básica no computador atual automaticamente. Use as seguintes etapas:

Se você tiver configurado os nós de cluster existentes com o módulo de cluster YaST, verifique se os seguintes pré-requisitos são atendidos antes de executar ha-cluster-join:

  • O usuário raiz nos nós existentes tem chaves SSH em vigor para o logon sem senha.
  • Csync2 está configurado nos nós existentes. Para obter mais informações, confira Como configurar o Csync2 com o YaST.
  1. Entre como root no computador físico ou na máquina virtual que deverá ingressar no cluster.

  2. Inicie o script de inicialização executando:

    sudo ha-cluster-join
    

    Se o NTP não tiver sido configurado para ser iniciado no momento da inicialização, uma mensagem será exibida.

  3. Caso decida continuar mesmo assim, você precisará inserir o endereço IP de um nó existente. Insira o endereço IP.

  4. Caso ainda não tenha configurado um acesso SSH sem senha entre os dois computadores, você também precisará fornecer a senha raiz do nó existente.

    Depois que você fizer logon no nó especificado, o script copiará a configuração do Corosync, configurará o SSH e Csync2 e colocará o computador atual online como o novo nó de cluster. Além disso, ele iniciará o serviço necessário para o Hawk. Se você tiver configurado o armazenamento compartilhado com OCFS2, ele também criará automaticamente o diretório de ponto de montagem para o sistema de arquivos do OCFS2.

  5. Repita as etapas anteriores para todos os computadores que deseja adicionar ao cluster.

  6. Para obter detalhes sobre o processo, confira /var/log/ha-cluster-bootstrap.log.

  7. Verifique o status do cluster com sudo crm status. Se você tiver adicionado um segundo nó, a saída será semelhante ao seguinte:

    sudo crm status
    

    Você verá uma saída semelhante ao exemplo a seguir.

    3 nodes configured
    1 resource configured
    Online: [ SLES1 SLES2 SLES3]
    Full list of resources:
    admin_addr     (ocf::heartbeat:IPaddr2):       Started node1
    

    Nota

    admin_addr é o recurso de cluster de IP virtual que é definido durante a configuração inicial do cluster de um nó.

Depois de adicionar todos os nós, verifique se você precisa ajustar a no-quorum-policy nas opções globais de cluster. Isso é especialmente importante para clusters de dois nós.

Defina a propriedade de cluster cluster-recheck-interval

cluster-recheck-interval indica o intervalo de sondagem segundo o qual o cluster verifica se há alterações nos parâmetros do recurso, restrições ou outras opções de cluster. Se uma réplica ficar inativa, o cluster tentará reiniciar a réplica em um intervalo associado ao valor failure-timeout e ao valor cluster-recheck-interval. Por exemplo, se failure-timeout for definido como 60 segundos e cluster-recheck-interval for definido como 120 segundos, será realizada uma tentativa de reinicialização em um intervalo superior a 60 segundos, mas inferior a 120 segundos. Recomendamos que você defina o tempo limite de falha como 60 segundos e cluster-recheck-interval com um valor superior a 60 segundos. Não é recomendável definir cluster-recheck-interval com um valor menor.

Para atualizar o valor da propriedade para 2 minutes, execute:

crm configure property cluster-recheck-interval=2min

Se você já tem um recurso de grupo de disponibilidade gerenciado por um cluster do Pacemaker, o pacote do Pacemaker 1.1.18-11.el7 apresenta uma alteração de comportamento para a configuração de cluster start-failure-is-fatal quando o valor dela é false. Essa alteração afeta o fluxo de trabalho de failover. Se uma réplica primária apresentar uma interrupção, o cluster deverá fazer failover para uma das réplicas secundárias disponíveis. Em vez disso, os usuários observarão que o cluster continuará tentando iniciar a réplica primária com falha. Se a primária nunca ficar online (devido a uma interrupção permanente), o cluster nunca fará failover para outra réplica secundária disponível. Devido a essa alteração, a configuração recomendada anteriormente para definir start-failure-is-fatal não é mais válida, e a configuração precisa ser revertida para o valor padrão de true.

Além disso, o recurso do AG precisa ser atualizado para incluir a propriedade failure-timeout.

Para atualizar o valor da propriedade para true, execute:

crm configure property start-failure-is-fatal=true

Atualize a propriedade do recurso do AG existente failure-timeout para a execução de 60s (substitua ag1 pelo nome do recurso de grupo de disponibilidade):

crm configure edit ag1

No editor de texto, adicione meta failure-timeout=60s depois de qualquer param e antes de qualquer op.

Para obter mais informações sobre as propriedades de cluster do Pacemaker, confira Como configurar recursos de cluster.

Considerações sobre NICs (adaptadores de rede) múltiplas

Ao configurar a alta disponibilidade com servidores que têm várias NICs, siga estas sugestões:

  • Verifique se o arquivo hosts está configurado para que os endereços IP do servidor para as várias NICs sejam resolvidos para o nome do host do servidor do Linux em cada nó.

  • Durante a configuração do cluster por meio do Pacemaker, o uso do nome do host dos servidores configura o Corosync para definir a configuração para todas as NICs. Queremos apenas a comunicação entre o Pacemaker e o Corosync em uma só NIC. Depois que o cluster do Pacemaker for configurado, modifique a configuração no arquivo corosync.conf e atualize o endereço IP da NIC dedicada que você deseja usar para a comunicação entre o Pacemaker e o Corosync.

  • O <hostname> especificado no arquivo corosync.conf deve ser o mesmo que a saída fornecida ao fazer uma pesquisa inversa (ping -a <ip_address>) e deve ser o nome curto configurado no host. Verifique se o arquivo hosts também representa o endereço IP adequado para a resolução de nomes.

As alterações no exemplo de arquivo corosync.conf são realçadas abaixo:

  nodelist {
    node {
        ring0_addr: <ip_address_of_node1_NIC1>
        name: <hostname_of_node1>
        nodeid: 1
    }
    node {
        ring0_addr: <ip_address_of_node2_NIC1>
        name: <hostname_of_node2>
        nodeid: 2
    }
    node {
        ring0_addr: <ip_address_of_node3_NIC1>
        name: <hostname_of_node3>
        nodeid: 3
    }
  }

Configurar um dispositivo de isolamento

Os fornecedores de cluster do Pacemaker exigem o isolamento de um nó com falha usando um dispositivo de isolamento definido para uma configuração de cluster compatível. Quando o gerenciador de recursos de cluster não pode determinar o estado de um nó ou de um recurso em um nó, o isolamento traz o cluster para um estado conhecido novamente.

O isolamento de recurso garante, principalmente, que não haja dados corrompidos durante uma interrupção ao configurar um recurso. Você pode usar o isolamento no nível do recurso, por exemplo, com o DRBD (Dispositivo de Bloco Replicado Distribuído) para marcar o disco em um nó como desatualizado quando o link de comunicação ficar inativo.

O isolamento no nível do nó garante que um nó não execute nenhum recurso. Isso é feito pela redefinição do nó, e a implementação do Pacemaker é chamada STONITH. O Pacemaker dá suporte a uma grande variedade de dispositivos de isolamento, como no-break ou adaptadores de rede de gerenciamento para servidores.

Para obter mais informações, consulte:

No momento da inicialização do cluster, o isolamento será desabilitado se nenhuma configuração for detectada. Ele poderá ser habilitado mais tarde pela execução do seguinte comando:

sudo crm configure property stonith-enabled=true

Importante

A ação de desabilitar o isolamento é somente para fins de teste. Caso pretenda usar o Pacemaker em um ambiente de produção, você deve planejar uma implementação do isolamento, dependendo do seu ambiente, e mantê-lo habilitado. O SUSE não fornece agentes de isolamento para nenhum ambiente de nuvem (incluindo o Azure) ou o Hyper-V. Consequentemente, o fornecedor de cluster não é compatível com a execução de clusters de produção nesses ambientes. Estamos trabalhando em uma solução para essa lacuna que estará disponível em versões futuras.

Configurar os recursos de cluster para o SQL Server

Veja o Guia de administração do SLES.

Habilitar o Pacemaker

Habilite o Pacemaker para que ele seja iniciado automaticamente.

Execute o comando a seguir em cada nó do cluster.

systemctl enable pacemaker

Criar recurso do grupo de disponibilidade

O comando a seguir cria e configura o recurso de grupo de disponibilidade para três réplicas do grupo de disponibilidade [ag1]. As operações e os tempos limite do monitor precisam ser especificados explicitamente no SLES com base no fato de que os tempos limite são altamente dependentes da carga de trabalho e precisam ser ajustados cuidadosamente para cada implantação. Execute o comando em um dos nós do cluster:

  1. Execute crm configure para abrir o prompt do CRM:

    sudo crm configure
    
  2. No prompt do CRM, execute o comando a seguir para configurar as propriedades do recurso.

    primitive ag_cluster \
       ocf:mssql:ag \
       params ag_name="ag1" \
       meta failure-timeout=60s \
       op start timeout=60s \
       op stop timeout=60s \
       op promote timeout=60s \
       op demote timeout=10s \
       op monitor timeout=60s interval=10s \
       op monitor timeout=60s interval=11s role="Master" \
       op monitor timeout=60s interval=12s role="Slave" \
       op notify timeout=60s
    ms ms-ag_cluster ag_cluster \
       meta master-max="1" master-node-max="1" clone-max="3" \
      clone-node-max="1" notify="true" \
    commit
    

Nota

Ao criar o recurso e, depois, periodicamente, o agente de recurso do Pacemaker define automaticamente o valor do REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT com base na configuração do grupo de disponibilidade. Por exemplo, se o grupo de disponibilidade tem três réplicas síncronas, o agente definirá REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1. Para obter detalhes e mais opções de configuração, consulte Alta disponibilidade e proteção de dados para as configurações de grupo de disponibilidade.

Criar recurso de IP virtual

Caso não tenha criado o recurso de IP virtual quando executou ha-cluster-init, crie esse recurso agora. O comando a seguir cria um recurso de IP virtual. Substitua <**0.0.0.0**> por um endereço disponível na rede e <**24**> pelo número de bits na máscara de sub-rede CIDR. Execução em um nó.

crm configure \
primitive admin_addr \
   ocf:heartbeat:IPaddr2 \
   params ip=<**0.0.0.0**> \
      cidr_netmask=<**24**>

Adicionar restrição de colocalização

Quase todas as decisões em um cluster do Pacemaker, como escolher o local em que um recurso deve ser executado, são feitas pela comparação de pontuações. As pontuações são calculadas por recurso e o gerenciador de recursos de cluster escolhe o nó com a pontuação mais alta para um recurso específico. (Se um nó tiver uma pontuação negativa para um recurso, o recurso não poderá ser executado nesse nó). Podemos manipular as decisões do cluster com restrições. As restrições têm uma pontuação. Se uma restrição tiver uma pontuação menor que INFINITY, ela será apenas uma recomendação. Uma pontuação INFINITY significa que ela é obrigatória. Queremos garantir que o primário do grupo de disponibilidade e o recurso de IP virtual sejam executados no mesmo host e, portanto, definimos uma restrição de colocalização com uma pontuação igual a INFINITY.

Para definir a restrição de colocação para o IP virtual ser executado no mesmo nó primário, execute o seguinte comando em um nó:

crm configure
colocation vip_on_master inf: \
    admin_addr ms-ag_cluster:Master
commit

Adicionar restrição de ordenação

A restrição de colocalização tem uma restrição de ordenação implícita. Ela move o recurso de IP virtual antes de mover o recurso de grupo de disponibilidade. Por padrão, a sequência de eventos é:

  1. O usuário emite resource migrate ao grupo de disponibilidade primário do node1 para o node2.
  2. O recurso de IP virtual é interrompido no nó 1.
  3. O recurso de IP virtual é iniciado no nó 2. Neste ponto, o endereço IP aponta temporariamente para o nó 2, enquanto o nó 2 ainda é um secundário de pré-failover.
  4. O mestre do grupo de disponibilidade no nó 1 é rebaixado.
  5. O grupo de disponibilidade no nó 2 é promovido a mestre.

Para impedir que o endereço IP aponte temporariamente para o nó com o secundário de pré-failover, adicione uma restrição de ordenação.
Para adicionar uma restrição de ordenação, execute o comando a seguir em um nó:

sudo crm configure \
   order ag_first inf: ms-ag_cluster:promote admin_addr:start

Importante

Depois de configurar o cluster e adicionar o grupo de disponibilidade como um recurso de cluster, você não poderá usar o Transact-SQL para fazer failover dos recursos de grupo de disponibilidade. Os recursos de cluster do SQL Server em Linux não são acoplados tão firmemente com o sistema operacional como são em um WSFC (cluster de failover do Windows Server). O serviço SQL Server não reconhece a presença do cluster. Toda a orquestração é feita por meio das ferramentas de gerenciamento de cluster. No SLES, use crm.

Faça failover manualmente do grupo de disponibilidade com crm. Não inicie o failover com o Transact-SQL. Para obter mais informações, confira Failover.

Para saber mais, veja: