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

Aplica-se a:SQL Server em Linux

A partir do SQL Server 2017 (14.x), o SQL Server tem suporte no Linux e no Windows. Como as implantações do SQL Server baseadas no Windows, os bancos de dados e instâncias do SQL Server precisam estar altamente disponíveis no Linux. Este artigo aborda as informações básicas para entender o Pacemaker com Corosync e como planejá-lo e implantá-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 implantação de configurações clusterizadas usando o Windows. No Windows, a forma de clustering de alta disponibilidade, chamada de cluster de alta disponibilidade do Windows Server (WSFC), é incorporada ao sistema operativo e o recurso que permite a criação de um WSFC, clustering de alta disponibilidade, é desativado por padrão. No Windows, AGs e FCIs são criados sobre um WSFC e compartilham uma integração rígida devido à DLL de recurso específico 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 é de código aberto, portanto, embora seja fornecida com as distribuições, ela não está totalmente integrada da mesma forma que um WSFC está no Windows. É por isso que a Microsoft fornece mssql-server-ha, para que o SQL Server e a pilha Pacemaker possam fornecer uma experiência próxima, mas não exatamente a mesma, para AGs e FCIs como no 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 ser executado em nós adicionais, mas necessita-se do Corosync para o SQL Server. Portanto, o número máximo de nós que um cluster pode ter para qualquer configuração baseada no SQL Server é 16; este é o limite do Pacemaker e não tem nada a ver com as 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. Isso não é diferente do que é feito em um WSFC, onde você vê um recurso do SQL Server para um recurso FCI ou AG ao configurar um AG, mas não é exatamente o mesmo devido às diferenças subjacentes em como o SQL Server se integra ao 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.

Planejar clusters do Pacemaker para SQL Server

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

Virtualizar clusters Pacemaker baseados em Linux para SQL Server

O uso de máquinas virtuais para implantar implantações do SQL Server baseadas em Linux para AGs e FCIs é coberto pelas mesmas regras que para suas contrapartes baseadas no Windows. Há um conjunto básico de regras para a capacidade de suporte de implantações virtualizadas do SQL Server fornecidas pela Microsoft na política de suporte para produtos Microsoft SQL Server que estão sendo executados em um 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 a 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 em uma configuração AG ou FCI, as VMs que hospedam o SQL Server nunca devem ser executadas no mesmo host de 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 obter documentação Hyper-V, consulte Usando 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 do quórum estão relacionados a implantações AG ou FCI específicas do SQL Server.

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 obter 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

• Implantar um cluster Pacemaker para SQL Server no Linux
• Configurar um cluster do Pacemaker para grupos de disponibilidade do SQL Server