Pacemaker para grupos de disponibilidade e instâncias de cluster de failover no Linux

Aplica-se a: SQL Server no Linux

A partir do SQL Server 2017 (14.x), o SQL Server é suportado tanto para Linux como para Windows. Tal como as implementações do SQL Server para Windows, as bases de dados e instâncias do SQL Server precisam de estar altamente disponíveis no Linux. Este artigo cobre a informação básica para compreender o Pacemaker com Corosync, bem como planeá-lo e implementá-lo para configurações do SQL Server.

Noções básicas sobre o complemento/extensão HA

Todas as distribuições atualmente suportadas fornecem um complemento/extensão de alta disponibilidade, que é baseado na pilha de clusters do Pacemaker. Esta pilha incorpora dois componentes-chave: Pacemaker e Corosync. Todos os componentes da pilha são:

• Marcapasso. O componente de clustering principal que coordena as coisas entre as máquinas clusterizadas.
• Corossync. Uma estrutura e um conjunto de APIs que fornece coisas como quórum, a capacidade de reiniciar processos com falha e assim por diante.
• libQB. Fornece funcionalidades como registo de atividades.
• Agente de recursos. Funcionalidade específica fornecida para que uma aplicação possa integrar-se com o Pacemaker.
• Agente de cercas. Scripts/funcionalidades que ajudam a isolar nós e lidar com eles se estiverem tendo problemas.

Esta solução é em alguns aspetos semelhante, mas em muitos aspetos diferente, da implementação de configurações em cluster usando o Windows. No Windows, o método de alta disponibilidade de clustering, chamado cluster de failover do Windows Server (WSFC), está integrado no sistema operativo, e a funcionalidade que permite a criação de um WSFC, clustering de failover, está desativada por defeito. No Windows, AGs e FCIs são construídos sobre um WSFC e partilham uma integração estreita devido à DLL de recursos específica fornecida pelo SQL Server. Esta solução firmemente acoplada é possível em geral porque é tudo de um único fornecedor.

No Linux, embora cada distribuição suportada tenha o Pacemaker disponível, cada distribuição pode personalizar e ter implementações e versões ligeiramente diferentes. Algumas das diferenças serão refletidas nas instruções deste artigo. A camada de clustering é open source, por isso, embora venha com as distribuições, não está integrada de forma tão estreita como um WSFC no Windows. É por isso que Microsoft fornece mssql-server-ha, para que SQL Server e a stack Pacemaker possam proporcionar uma experiência próxima, mas não exatamente igual, para AGs e FCIs como em Windows.

Para obter documentação completa sobre o Pacemaker, incluindo uma explicação detalhada e aprofundada do que cada parte representa, acompanhadas de informações de referência completas, para RHEL e SLES:

• RHEL
• SLES
• Ubuntu

Para obter mais informações sobre toda a pilha, consulte também a página de documentação oficial do Pacemaker no site do ClusterLabs.

Conceitos e terminologia do pacemaker

Esta seção documenta os conceitos e a terminologia comuns para uma implementação de Pacemaker.

Node

Um nó é um servidor que participa do cluster. Um cluster Pacemaker suporta nativamente até 16 nós. Este número pode ser ultrapassado se o Corosync não estiver a correr em nós adicionais, mas o Corosync é necessário para o SQL Server. Portanto, o número máximo de nós que um cluster pode ter para qualquer configuração baseada em SQL Server é 16; este é o limite do Pacemaker, e nada tem a ver com limitações máximas para AGs ou FCIs impostas pelo SQL Server.

Recurso

Tanto um WSFC como um cluster Pacemaker têm o conceito de um recurso. Um recurso é uma funcionalidade específica que é executada no contexto do cluster, como um disco ou um endereço IP. Por exemplo, sob o Pacemaker, podem ser criados os recursos FCI e AG. Isto não é muito diferente do que é feito num WSFC, onde se vê um recurso SQL Server para um recurso FCI ou AG ao configurar um AG, mas não é exatamente igual devido às diferenças subjacentes na forma como o SQL Server se integra com o Pacemaker.

O Pacemaker tem recursos padrão e recursos clonados. Os recursos de clonagem são aqueles que são executados simultaneamente em todos os nós. Um exemplo seria um endereço IP executado em vários nós para fins de balanceamento de carga. Qualquer recurso que seja criado para FCIs usa um recurso padrão, já que apenas um nó pode hospedar uma FCI a qualquer momento.

Quando um AG é criado, ele requer uma forma especializada de um recurso de clone chamado recurso de vários estados. Embora um AG tenha apenas uma réplica primária, o próprio AG está sendo executado em todos os nós nos quais está configurado para trabalhar e pode potencialmente permitir coisas como acesso somente leitura. Por se tratar de um uso "em tempo real" do nó, os recursos têm o conceito de dois estados: Promovido (anteriormente Mestre) e Despromovido (anteriormente Escravo). Para obter mais informações, consulte Recursos de vários estados: recursos com vários modos.

Grupos/conjuntos de recursos

Semelhante às funções em um WSFC, um cluster Pacemaker tem o conceito de um grupo de recursos. Um grupo de recursos (chamado de conjunto no SLES) é uma coleção de recursos que funcionam juntos e podem fazer failover de um nó para outro como uma única unidade. Os grupos de recursos não podem conter recursos configurados como Promovidos ou Não promovidos; portanto, eles não podem ser usados para AGs. Embora um grupo de recursos possa ser usado para FCIs, geralmente não é uma configuração recomendada.

Restrições

Os WSFCs têm vários parâmetros para recursos e coisas como dependências, que informam o WSFC de uma relação pai/filho entre dois recursos diferentes. Uma dependência é apenas uma regra que diz ao WSFC qual recurso precisa estar online primeiro.

Um cluster Pacemaker não tem o conceito de dependências, mas há restrições. Existem três tipos de restrições: colocação, localização e ordenação.

• Uma restrição de alocação conjunta impõe se dois recursos devem ou não ser executados no mesmo nó.
• Uma restrição de local informa ao cluster do Pacemaker onde um recurso pode (ou não) ser executado.
• Uma restrição de ordenação informa ao cluster do Pacemaker a ordem na qual os recursos devem ser iniciados.

Quórum, agentes de vedação e STONITH

O quórum em Pacemaker é semelhante a um WSFC em conceito. O objetivo do mecanismo de quórum de um cluster é garantir que ele permaneça ativo e funcionando. Tanto um WSFC quanto os complementos HA para as distribuições Linux têm o conceito de votação, onde cada nó conta para o quórum. Você quer a maioria dos votos a favor, caso contrário, no pior cenário possível, o cluster será encerrado.

Ao contrário de um WSFC, não há recurso de testemunhas para trabalhar com quórum. Tal como um WSFC, o objetivo é garantir que o número de votantes se mantenha ímpar. A configuração do quórum tem considerações diferentes para AGs do que FCIs.

Os WSFCs monitoram o status dos nós participantes e os manipulam quando ocorre um problema. Versões posteriores dos WSFCs oferecem funcionalidades como colocar em quarentena um nó que está comportando-se de forma inadequada ou indisponível (o nó está desligado, a comunicação de rede está inativa, etc.). No lado do Linux, este tipo de funcionalidade é fornecido por um fence agent. O conceito é por vezes referido como esgrima. No entanto, esses agentes de cerca são específicos para a implantação e geralmente fornecidos por fornecedores de hardware e alguns fornecedores de software, como aqueles que fornecem hipervisores. Por exemplo, o VMware fornece um agente de cerca que pode ser usado para VMs Linux virtualizadas usando o vSphere.

Quórum e esgrima se ligam a outro conceito chamado STONITH, ou Atire o Outro Nó na Cabeça. STONITH é necessário para ter um cluster Pacemaker suportado em todas as distribuições Linux. Para mais informações, consulte Bloqueio em um Red Hat High Availability Cluster (RHEL).

corosync.conf

O corosync.conf arquivo contém a configuração do cluster. Ele está localizado em /etc/corosync. No decurso de operações normais do dia-a-dia, este ficheiro nunca deverá ter de ser editado se o cluster estiver configurado corretamente.

Local do log do cluster

Os locais de log para clusters Pacemaker diferem dependendo da distribuição.

• RHEL e SLES: /var/log/cluster/corosync.log
• Ubuntu: /var/log/corosync/corosync.log

Para alterar o local padrão de registo, modifique corosync.conf.

Planear Pacemaker clusters para SQL Server

Esta seção discute os pontos importantes de planejamento para um cluster Pacemaker.

Virtualize clusters Pacemaker baseados em Linux para SQL Server

A utilização de máquinas virtuais para implementar implementações de SQL Server baseadas em Linux para AGs e FCIs está abrangida pelas mesmas regras que para os seus equivalentes baseados em Windows. Existe um conjunto base de regras para suportabilidade de implementações de SQL Server virtualizadas fornecidas pela Microsoft na política de suporte para produtos Microsoft SQL Server que estão a correr num ambiente de virtualização de hardware. Diferentes hipervisores, como o Hyper-V da Microsoft e o ESXi da VMware, podem ter variações diferentes além disso, devido às diferenças nas próprias plataformas.

Quando se trata de AGs e FCIs em um ambiente de virtualização, certifique-se de que a antiafinidade esteja configurada para os nós de um determinado cluster Pacemaker. Quando configuradas para alta disponibilidade numa configuração AG ou FCI, as VMs que hospedam o SQL Server nunca devem estar a correr no mesmo host hipervisor. Por exemplo, se uma FCI de dois nós for implantada, precisaria haver pelo menos três hosts de hipervisor para que haja algum lugar para uma das VMs que hospedam um nó ir no caso de uma falha de host, especialmente se estiver usando recursos como Live Migration ou vMotion.

Para consultar a documentação do Hyper-V, veja Utilização de Clustering de Convidados para Alta Disponibilidade

Rede

Ao contrário de um WSFC, o Pacemaker não requer um nome dedicado ou pelo menos um endereço IP dedicado para o cluster do Pacemaker em si. AGs e FCIs exigirão endereços IP (consulte a documentação de cada um para obter mais informações), mas não nomes, já que não há recurso de nome de rede. O SLES permite a configuração de um endereço IP para fins de administração, mas não é necessário, como pode ser visto em Criar o cluster Pacemaker.

Como um WSFC, o Pacemaker preferiria redes redundantes, ou seja, placas de rede distintas (NICs ou pNICs para físicas) com endereços IP individuais. Em termos de configuração do cluster, cada endereço IP teria o que é conhecido como seu próprio anel. No entanto, como acontece com WSFCs hoje, muitas implementações são virtualizadas ou na nuvem pública, onde há apenas uma única NIC virtualizada (vNIC) apresentada ao servidor. Se todas as pNICs e vNICs estiverem conectadas ao mesmo switch físico ou virtual, não haverá redundância verdadeira na camada de rede, portanto, configurar várias NICs é um pouco ilusório para a máquina virtual. A redundância de rede geralmente é incorporada ao hipervisor para implantações virtualizadas e é definitivamente incorporada à nuvem pública.

Uma diferença com várias NICs e Pacemaker em relação a um WSFC é que o Pacemaker permite vários endereços IP na mesma sub-rede, enquanto um WSFC não. Para obter mais informações sobre várias sub-redes e clusters Linux, consulte o artigo Configurar grupos de disponibilidade Always On e instâncias de clusters de failover de várias sub-redes.

Quorum e STONITH

A configuração e os requisitos de quórum estão relacionados com implementações específicas do SQL Server para AG ou FCI.

STONITH é necessário para um cluster de Pacemaker suportado. Use a documentação da distribuição para configurar o STONITH. Encontram-se exemplos de Isolamento baseado em armazenamento para SLES. Há também um agente STONITH para VMware vCenter para soluções baseadas em ESXI. Para obter mais informações, consulte Stonith Plugin Agent for VMware VM VCenter SOAP Fencing (Unofficial).

Interoperabilidade

Esta seção documenta como um cluster baseado em Linux pode interagir com um WSFC ou com outras distribuições do Linux.

WSFC

Atualmente, não há uma maneira direta de um WSFC e um cluster Pacemaker trabalharem juntos. Isso significa que não há como criar uma AG ou FCI que funcione em um WSFC e Pacemaker. No entanto, há duas soluções de interoperabilidade, ambas concebidas para AGs. A única maneira de uma FCI participar de uma configuração de plataforma cruzada é se ela estiver participando como uma instância em um destes dois cenários:

• Um AG sem tipo de cluster. Para mais informações, consulte a documentação dos grupos de disponibilidade do Windows .
• Um AG distribuído, que é um tipo especial de grupo de disponibilidade, permite que dois AGs diferentes sejam configurados, cada um como um grupo de disponibilidade próprio. Para obter mais informações sobre AGs distribuídos, consulte a documentação Grupos de disponibilidade distribuídos.

Outras distribuições Linux

No Linux, todos os nós de um cluster Pacemaker devem estar na mesma distribuição. Por exemplo, isso significa que um nó RHEL não pode fazer parte de um cluster Pacemaker que tenha um nó SLES. A principal razão para isso foi declarada anteriormente: as distribuições podem ter versões e funcionalidades diferentes, então as coisas não poderiam funcionar corretamente. Misturar distribuições tem a mesma história que misturar WSFCs e Linux: use None ou AGs distribuídos.

Conteúdo relacionado

• Implante um cluster Pacemaker para SQL Server em Linux
• Configure um cluster Pacemaker para grupos de disponibilidade SQL Server