Pacemaker para grupos de disponibilidade e instâncias de cluster de failover no Linux
Aplica-se a: 
SQL Server – Linux
Começando com o SQL Server 2017 (14.x), o SQL Server é compatível no Linux e no Windows. Como as implantações do SQL Server baseadas no Windows, os bancos de dados e as 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 planejar e implantá-lo em configurações do SQL Server.
Noções básicas de complemento/extensão de HA
Todas as distribuições com suporte no momento enviam um complemento/extensão de alta disponibilidade, que se baseia na pilha de clustering do Pacemaker. Essa pilha incorpora dois componentes principais: Pacemaker e Corosync. Todos os componentes da pilha são:
- Pacemaker. O componente de clustering principal, que coordena itens entre as máquinas clusterizadas.
- Corosync. Uma estrutura e um conjunto de APIs que fornecem itens como quorum, a capacidade de reiniciar processos com falha e assim por diante.
- libQB. Fornece itens como registro em log.
- Agente de recursos. Funcionalidade específica fornecida para que um aplicativo possa ser integrado ao Pacemaker.
- Agente de isolamento. Scripts/funcionalidade que ajudam a isolar nós e lidar com eles se estiverem tendo problemas.
Observação
A pilha de cluster é normalmente conhecida como Pacemaker no mundo Linux.
Essa solução é, de alguma forma, semelhante à implantação de configurações clusterizadas usando o Windows, mas diferente de várias maneiras. No Windows, a forma de disponibilidade de clustering, chamada de WSFC (cluster de failover do Windows Server), é incorporada ao sistema operacional e o recurso que permite a criação de um WSFC, clustering de failover, é desabilitado por padrão. No Windows, os AGs e as FCIs são criados sobre um WSFC e compartilham uma forte integração devido à DLL de recurso específica fornecida pelo SQL Server. Essa solução totalmente acoplada é possível, de modo geral, por ser toda de um único fornecedor.
No Linux, embora cada distribuição com suporte 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 neste artigo. A camada de clustering é de software livre. Por isso, embora seja fornecida com as distribuições, ela não é totalmente integrada da mesma maneira que um WSFC no Windows. Por esse motivo, a Microsoft fornece mssql-server-ha, de modo que o SQL Server e a pilha do Pacemaker possam fornecer quase, mas não exatamente, a mesma experiência para AGs e FCIs como no Windows.
Para obter a documentação completa sobre o Pacemaker, incluindo uma explicação mais detalhada de tudo, com informações de referência completa, para RHEL e SLES:
O Ubuntu não tem um guia para a disponibilidade.
Para obter mais informações sobre a pilha inteira, confira 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 de uma implementação do Pacemaker.
Nó
Um nó é um servidor que participa do cluster. Um cluster do Pacemaker dá suporte nativo a até 16 nós. Esse número poderá ser excedido se Corosync não estiver em execução em nós adicionais, mas ele for exigido para 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; esse é 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
Um WSFC e um cluster do 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, no Pacemaker, os recursos de FCI e AG podem ser criados. Isso não é diferente do que é feito em um WSFC, no qual você vê um recurso do SQL Server para um recurso de FCI ou um AG ao configurar um AG, mas não é exatamente o mesmo devido às diferenças subjacentes em como o SQL Server integra-se ao Pacemaker.
O Pacemaker tem recursos padrão e de clone. Os recursos de clone são aqueles executados simultaneamente em todos os nós. Um exemplo seria um endereço IP que é executado em vários nós para fins de balanceamento de carga. Qualquer recurso criado para FCIs usa um recurso padrão, já que apenas um nó pode hospedar uma FCI em um determinado momento.
Observação
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.
Quando um AG é criado, ele requer uma forma especializada de um recurso de clone chamado de recurso de vários estados. Embora um AG tenha apenas uma réplica primária, o AG em si está em execução em todos os nós em que está configurado para trabalhar e pode, potencialmente, permitir ações como o acesso somente leitura. Como esse é um uso "dinâmico" do nó, os recursos têm o conceito de dois estados: Promovido (anteriormente chamado de Mestre) e Não promovido (anteriormente chamado de Subordinado). Para obter mais informações, confira Recursos de vários estados: recursos que têm vários modos.
Grupos/conjuntos de recursos
Semelhante às funções em um WSFC, um cluster do 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 só unidade. Grupos de recursos não podem conter recursos configurados como Promovido ou Não promovido. Portanto, eles não podem ser usados para AGs. Embora um grupo de recursos possa ser usado para FCIs, esta geralmente não é uma configuração recomendada.
Restrições
WSFCs têm vários parâmetros para recursos e dependências, que dizem ao WSFC de uma relação pai/filho entre dois recursos diferentes. Uma dependência é apenas uma regra que informa ao WSFC qual recurso precisa estar online primeiro.
Um cluster do Pacemaker não tem o conceito de dependências, mas há restrições. Há três tipos de restrições: colocação, localização e ordenação.
- Uma restrição de colocação impõe se dois recursos devem ou não ser executados no mesmo nó.
- Uma restrição de localização informa ao cluster do Pacemaker onde um recurso pode (ou não pode) ser executado.
- Uma restrição de ordenação informa ao cluster do Pacemaker a ordem em que os recursos devem iniciar.
Observação
Restrições de colocação não são necessárias para recursos em um grupo de recursos, pois todas elas são vistas como uma única unidade.
Quorum, agentes de isolamento e STONITH
O Quorum no Pacemaker é semelhante a um WSFC em conceito. A finalidade total de um mecanismo de quorum do cluster é garantir que o cluster permaneça ativo e em execução. Tanto o WSFC quanto os complementos de HA para as distribuições do Linux têm o conceito de votação, em que cada nó conta para o quorum. Você quer a maioria dos votos, caso contrário, em um cenário desfavorável, o cluster será desligado.
Ao contrário de um WSFC, não há nenhum recurso de testemunha para trabalhar com o quorum. Como um WSFC, a meta é manter o número de eleitores ímpares. A configuração de quorum tem considerações diferentes para AGs e FCIs.
WSFCs monitoram o status dos nós participantes e os manipulam quando ocorre um problema. As versões posteriores do WSFCs oferecem recursos como colocar em quarentena um nó que está inadequado ou não disponível (o nó não está ativado, a comunicação de rede está inoperante etc.). No lado do Linux, esse tipo de funcionalidade é fornecido por um agente de isolamento. Às, vezes, o conceito é chamado de isolamento. No entanto, esses agentes de isolamento são específicos para a implantação e, em geral, fornecidos por fornecedores de hardware e alguns fornecedores de software, como aqueles que fornecem hipervisores. Por exemplo, a VMware fornece um agente de isolamento que pode ser usado para VMs Linux virtualizadas usando vSphere.
O quorum e o isolamento vinculam-se a outro conceito chamado STONITH, Shoot the Other Node in the Head. STONITH é necessário para ter um cluster do Pacemaker com suporte em todas as distribuições do Linux. Para obter mais informações, confira Isolamento em um cluster de alta disponibilidade da Red Hat (RHEL).
corosync.conf
O arquivo corosync.conf contém a configuração do cluster. Ele está localizado em /etc/corosync. No decorrer das operações normais do dia a dia, esse arquivo nunca deverá ser editado se o cluster estiver configurado corretamente.
Localização do log do cluster
Os locais de log para clusters do Pacemaker diferem dependendo da distribuição.
- RHEL e SLES:
/var/log/cluster/corosync.log - Ubuntu:
/var/log/corosync/corosync.log
Para alterar a localização padrão do registro em log, modifique corosync.conf.
Planejar clusters do Pacemaker para o SQL Server
Esta seção aborda os pontos de planejamento importantes para um cluster do Pacemaker.
Virtualize clusters do Pacemaker baseados no Linux para o SQL Server
O uso de máquinas virtuais para implantar implantações do SQL Server baseadas no Linux para AGs e FCIs é coberto pelas mesmas regras que as de suas contrapartes baseadas no Windows. Há um conjunto básico de regras para oferecer capacidade de suporte a implantações de SQL Server virtualizadas fornecidas pela Microsoft na Política de suporte para produtos do Microsoft SQL Server que estão em execução em um ambiente de virtualização de hardware. Hipervisores diferentes, como o Hyper-V da Microsoft e o ESXi da VMware, podem ter variações diferentes sobre isso, devido a diferenças nas próprias plataformas.
Quando se trata de AGs e FCIs em virtualização, verifique se a antiafinidade está definida para os nós de um determinado cluster do Pacemaker. Quando configuradas para alta disponibilidade em uma configuração de AG ou FCI, as VMs que hospedam o SQL Server nunca devem estar em execução no mesmo host de hipervisor. Por exemplo, se uma FCI de dois nós for implantada, serão necessários pelo menos três hosts de hipervisor para que haja algum lugar para que uma das VMs que hospeda um nó continue no caso de uma falha de host, especialmente se estiver usando recursos como Migração ao Vivo ou vMotion.
Para obter a documentação do Hyper-V, consulte Como Usar o Clustering de Convidado 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 próprio cluster do Pacemaker. 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á nenhum recurso de nome da 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 do Pacemaker.
Como um WSFC, o Pacemaker preferiria a rede redundante, o que significa que placas de rede distintas (NICs ou pNICs para físico) com endereços IP individuais. Em termos da configuração do cluster, cada endereço IP teria o que é conhecido como seu próprio anel. No entanto, assim como com o WSFCs hoje, muitas implementações são virtualizadas ou na nuvem pública em que há apenas uma vNIC (NIC virtualizada única) apresentada ao servidor. Se todas as pNICs e vNICs estiverem conectadas ao mesmo comutador virtual ou físico, não haverá nenhuma redundância real na camada de rede. Portanto, configurar várias NICs é um pouco de uma ilusão 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 o Pacemaker versus um WSFC é que o Pacemaker permite vários endereços IP na mesma sub-rede, enquanto um WSFC não permite. Para obter mais informações sobre várias sub-redes e clusters do Linux, confira o artigo Configurar grupos de disponibilidade Always On de várias sub-redes e instâncias de cluster de failover.
Quorum e STONITH
A configuração de quorum e os requisitos estão relacionados a implantações específicas do AG ou da FCI do SQL Server.
STONITH é necessário para um cluster do Pacemaker com suporte. Use a documentação da distribuição para configurar o STONITH. Um exemplo está no Isolamento baseado em armazenamento para SLES. Também há um agente STONITH para soluções baseadas no VMware vCenter para ESXI. Para obter mais informações, confira Agente do plug-in Stonith para isolamento SOAP do VMware VM VCenter (não oficial).
Interoperabilidade
Esta seção documenta como um cluster baseado no Linux pode interagir com um WSFC ou com outras distribuições do Linux.
WSFC
Atualmente, não há maneira direta para um WSFC e um cluster do Pacemaker funcionarem juntos. Isso significa que não há como criar um AG ou uma FCI que funcione em um WSFC e em um Pacemaker. No entanto, há duas soluções de interoperabilidade, ambas projetadas para AGs. A única maneira de uma FCI poder participar de uma configuração multiplataforma será se ela estiver participando como uma instância em um destes dois cenários:
- Um AG com um tipo de cluster Nenhum. Para obter mais informações, confira a documentação dos grupos de disponibilidade do Windows.
- Um AG distribuído, que é um tipo especial de grupo de disponibilidade que permite que dois AGs diferentes sejam configurados como seu próprio grupo de disponibilidade. Para obter mais informações sobre AGs distribuídos, confira a documentação Grupos de disponibilidade distribuídos.
Outras distribuições do Linux
No Linux, todos os nós de um cluster do Pacemaker devem estar na mesma distribuição. Por exemplo, isso significa que um nó RHEL não pode fazer parte de um cluster do Pacemaker que tem um nó SLES. O principal motivo para isso foi declarado anteriormente: as distribuições podem ter diferentes versões e funcionalidades. Portanto, as ações não podiam funcionar corretamente. A combinação de distribuições tem a mesma história que a combinação de WSFCs e Linux: use Nenhum ou AGs distribuídos.