Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL Server - Linux
Este artigo explica os conceitos relacionados às instâncias de cluster de failover (FCI) do SQL Server no Linux.
Para criar uma FCI do SQL Server no Linux, consulte Configurar instância de cluster de failover - SQL Server no Linux (RHEL)
A camada de agrupamento
No Red Hat Enterprise Linux (RHEL), a camada de clustering é baseada no complemento HA do Red Hat Enterprise Linux (RHEL).
Observação
O acesso ao complemento e à documentação do Red Hat HA requer uma assinatura.
No SUSE Linux Enterprise Server (SLES), a camada de clustering é baseada no SUSE Linux Enterprise High Availability Extension (HAE).
Para obter mais informações sobre configuração de cluster, opções do agente de recursos, gerenciamento, práticas recomendadas e recomendações, consulte SUSE Linux Enterprise High Availability Extension 15.
Tanto o complemento RHEL HA quanto o SUSE HAE são construídos no Pacemaker.
Como mostra o diagrama a seguir, o armazenamento é apresentado para dois servidores. Os componentes de clustering - Corosync e Pacemaker - coordenam as comunicações e a gestão de recursos. Um dos servidores tem a conexão ativa com os recursos de armazenamento e o SQL Server. Quando o Pacemaker deteta uma falha, os componentes de agrupamento são responsáveis por mover os recursos para o outro nó.
A integração do SQL Server com o Pacemaker no Linux não é tão acoplada quanto com o WSFC no Windows. O SQL Server não tem conhecimento sobre a presença do cluster. Toda a orquestração é gerida externamente e o serviço é controlado como uma instância independente pelo Pacemaker. Além disso, o nome da rede virtual é específico do WSFC, que não tem equivalente no Pacemaker. Espera-se que @@SERVERNAME e sys.servers retornem o nome do nó, enquanto o cluster DMVs sys.dm_os_cluster_nodes e sys.dm_os_cluster_properties não retornem nenhum registo. Para usar uma cadeia de conexão que aponta para um nome de servidor de cadeia de caracteres e não usar o IP, eles precisam registrar em seu servidor DNS o IP usado para criar o recurso IP virtual (conforme explicado nas seções a seguir) com o nome do servidor escolhido.
Número de instâncias e nós
Uma diferença importante com o SQL Server no Linux é que só pode haver uma instalação do SQL Server por servidor Linux. Essa instalação é chamada de instância. Ao contrário do Windows Server, que suporta até 25 FCIs por cluster de failover do Windows Server (WSFC), uma FCI baseada em Linux terá apenas uma única instância. Essa instância única também é uma instância padrão; não há nenhum conceito de uma instância nomeada no Linux.
Um cluster Pacemaker só pode ter até 16 nós quando o Corosync está envolvido, portanto, uma única FCI pode abranger até 16 servidores. Uma FCI implementada com o Standard Edition do SQL Server oferece suporte a até dois nós de um cluster, mesmo que o cluster Pacemaker tenha o máximo de 16 nós.
Em uma FCI do SQL Server, a instância do SQL Server está ativa em um nó ou outro.
Endereço IP e nome
Em um cluster Linux Pacemaker, cada FCI do SQL Server precisa de seu próprio endereço IP e nome exclusivos. Se a configuração FCI abranger várias sub-redes, será necessário um endereço IP por sub-rede. O nome exclusivo e o(s) endereço(s) IP(s) são usados para acessar a FCI para que os aplicativos e usuários finais não precisem saber qual servidor subjacente do cluster Pacemaker.
O nome da FCI no DNS deve ser o mesmo que o nome do recurso FCI que é criado no cluster Pacemaker. Tanto o nome como o endereço IP devem ser registados no DNS.
Armazenamento compartilhado
Todas as FCIs, sejam elas Linux ou Windows Server, requerem alguma forma de armazenamento compartilhado. Esse armazenamento é apresentado a todos os servidores que podem hospedar a FCI, mas apenas um único servidor pode usar o armazenamento para a FCI a qualquer momento. As opções disponíveis para armazenamento compartilhado no Linux são:
- iSCSI
- Sistema de arquivos de rede (NFS)
- Bloco de Mensagens do Servidor (SMB) No Windows Server, há opções ligeiramente diferentes. Uma opção atualmente sem suporte para FCIs baseadas em Linux é a capacidade de usar um disco local para o nó do
tempdb, que é o espaço de trabalho temporário do SQL Server.
Em uma configuração que abrange vários locais, o que é armazenado em um data center deve ser sincronizado com o outro. No caso de um failover, a FCI é capaz de ficar online e o armazenamento é percebido como igual. Conseguir isso requer algum método externo para replicação de armazenamento, seja por meio do hardware de armazenamento subjacente ou de algum utilitário baseado em software.
Observação
Para o SQL Server, implantações baseadas em Linux usando discos apresentados diretamente a um servidor devem ser formatadas com XFS ou ext4. Outros sistemas de arquivos não são suportados no momento. Quaisquer alterações serão refletidas aqui.
O processo de apresentação do armazenamento compartilhado é o mesmo para os diferentes métodos suportados:
- Configurar o armazenamento compartilhado
- Monte o armazenamento como uma pasta para os servidores que servirão como nós do cluster Pacemaker para a FCI
- Se necessário, mova os bancos de dados do sistema SQL Server para o armazenamento compartilhado
- Teste se o SQL Server funciona a partir de cada servidor conectado ao armazenamento compartilhado
Uma grande diferença com o SQL Server no Linux é que, embora você possa configurar os dados do usuário padrão e o local do arquivo de log, os bancos de dados do sistema sempre devem existir em /var/opt/mssql/data. No Windows Server, você tem a capacidade de mover os bancos de dados do sistema, incluindo tempdb. Esse fato influencia a forma como o armazenamento compartilhado é configurado para uma FCI.
Os caminhos padrão para bancos de dados que não são do sistema podem ser alterados usando o mssql-conf utilitário. Para obter informações sobre como alterar os padrões, altere os dados padrão ou o local do diretório de log. Você também pode armazenar dados e transações do SQL Server em outros locais, desde que eles tenham a segurança adequada, mesmo que não seja um local padrão; a localização teria de ser indicada.