Compartilhar via


Configurar o cluster de disco compartilhado SLES para o SQL Server

Aplica-se a:SQL Server no Linux

Este guia fornece instruções para criar um cluster de disco compartilhado de dois nós para o SQL Server no SUSE Linux Enterprise Server (SLES). A camada de clustering baseia-se no HAE (Extensão de Alta Disponibilidade) do SUSE criado com base no Pacemaker.

Observação

A partir do SQL Server 2025 (17.x), não há suporte para SLES (SUSE Linux Enterprise Server).

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

Pré-requisitos

Para concluir o cenário de ponta a ponta a seguir, você precisará de dois computadores para implantar o cluster de dois nós e outro servidor para configurar o compartilhamento NFS. 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. Para este passo a passo, use o SLES com uma assinatura válida para o complemento de HA.

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

  1. Instale e configure o SQL Server em ambos 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 o outro como secundário para fins de configuração. Use esses termos para seguir este guia.

  3. No nó secundário, interrompa e desabilite o SQL Server. O seguinte exemplo interrompe e desabilita o SQL Server:

    sudo systemctl stop mssql-server
    sudo systemctl disable mssql-server
    

    Observação

    No momento da instalação, uma SMK (chave mestra) do servidor é gerada para a instância do SQL Server e colocada em /var/opt/mssql/secrets/machine-key. No Linux, o SQL Server sempre é executado como uma conta local chamada mssql. Como é uma conta local, a identidade dela não é compartilhada entre os nós. Você deve copiar a chave de criptografia do nó primário para cada nó secundário para que cada conta local mssql possa acessá-la para descriptografar o SMK.

  4. No nó primário, crie um logon do SQL Server para o Pacemaker e conceda a permissão de logon para executar sp_server_diagnostics. O Pacemaker usa essa conta para verificar qual nó está executando o SQL Server.

    sudo systemctl start mssql-server
    

    Conecte-se ao banco de dados do SQL Server master com a sa conta e execute o seguinte script:

    USE [master];
    GO
    
    CREATE LOGIN [<loginName>] with PASSWORD = N'<password>';
    GRANT VIEW SERVER STATE TO <loginName>;
    

    Cuidado

    Sua senha deve seguir a política de senha padrão do SQL Server. Por padrão, a senha precisa ter pelo menos oito caracteres e conter caracteres de três dos seguintes quatro conjuntos: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As senhas podem ter até 128 caracteres. Use senhas longas e complexas.

  5. No nó primário, interrompa e desabilite o SQL Server.

  6. Siga as instruções descritas na documentação do SUSE para configurar e atualizar o arquivo de hosts para cada nó de cluster. O arquivo hosts precisa incluir o endereço IP e o nome de cada nó de cluster.

    Para verificar o endereço IP da execução do nó atual:

    sudo ip addr show
    

    Defina o nome do computador em cada nó. Dê a cada nó um nome exclusivo que tenha 15 caracteres ou menos. Defina o nome do computador adicionando-o a /etc/hostname usando o YAST ou manualmente.

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

    127.0.0.1      localhost
    10.128.18.128  SLES1
    10.128.16.77   SLES2
    

    Todos os nós de cluster devem ter acesso SSH sem senha uns aos outros. Caso contrário, ferramentas como hb_report, crm_report e o Explorador de Histórico do Hawk podem coletar dados somente do nó local. Se você usar uma porta SSH não padrão, use a opção -X (consulte Outros Requisitos e Recomendações). Por exemplo, se a porta SSH for 3479, invoque crm_report com:

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

    Para obter mais informações, confira o Guia de administração.

Na próxima seção, você configurará o armazenamento compartilhado e moverá seus arquivos de banco de dados para esse armazenamento.

Configurar o armazenamento compartilhado e mover arquivos de banco de dados

Você pode usar várias soluções para fornecer armazenamento compartilhado. Este passo a passo demonstra como configurar o armazenamento compartilhado com o NFS. Siga as práticas recomendadas e use Kerberos para proteger o NFS:

Se você não seguir essas diretrizes, qualquer pessoa que possa acessar sua rede e falsificar o endereço IP de um nó SQL poderá acessar seus arquivos de dados. Como sempre, execute a modelagem de ameaças em seu sistema antes de usá-la em produção.

Outra opção de armazenamento é usar o compartilhamento de arquivo SMB:

Configurar um servidor NFS

Para configurar um servidor NFS, confira as seguintes etapas na documentação do SUSE: Configurar o servidor NFS.

Configurar todos os nós de cluster para se conectar ao armazenamento compartilhado do NFS

Antes de configurar o NFS do cliente para montar o caminho dos arquivos de banco de dados do SQL Server para apontar para o local de armazenamento compartilhado, salve os arquivos de banco de dados em um local temporário para poder copiá-los mais tarde para o compartilhamento:

  1. Somente no nó primário, salve os arquivos de banco de dados em uma localização temporária. O script a seguir cria um novo diretório temporário, copia os arquivos de banco de dados para o novo diretório e remove os arquivos de banco de dados antigos. Enquanto o SQL Server é executado como o usuário local mssql, você precisa verificar se, após a transferência de dados para o compartilhamento montado, o usuário local tem acesso de leitura/gravação ao compartilhamento.

    su mssql
    mkdir /var/opt/mssql/tmp
    cp /var/opt/mssql/data/* /var/opt/mssql/tmp
    rm /var/opt/mssql/data/*
    exit
    

    Configure o cliente NFS em todos os nós de cluster:

    Observação

    Para obter as melhores práticas e recomendações do SUSE em relação ao armazenamento NFS altamente disponível, consulte Armazenamento NFS altamente disponível com DRBD e Pacemaker.

  2. Em cada nó, valide se o SQL Server começa com êxito com o novo caminho de arquivo. Neste ponto, somente um nó deve executar o SQL Server de cada vez. Ambos não podem ser executados ao mesmo tempo porque ambos tentam acessar os arquivos de dados simultaneamente.

    Para impedir que o SQL Server comece em ambos os nós, use um recurso de cluster do Sistema de Arquivos para garantir que o compartilhamento seja montado por apenas um nó de cada vez.

    Os comandos a seguir iniciam o SQL Server, verificam o status e, em seguida, interrompem o SQL Server.

    sudo systemctl start mssql-server
    sudo systemctl status mssql-server
    sudo systemctl stop mssql-server
    

Nesse ponto, ambas as instâncias do SQL Server são configuradas para serem executadas com os arquivos de banco de dados no armazenamento compartilhado. A próxima etapa é configurar o SQL Server para o Pacemaker.

Instalar e configurar o Pacemaker em cada nó de cluster

  1. Em ambos os nós de cluster, crie um arquivo para armazenar o nome de usuário do SQL Server e a senha para o logon do Pacemaker. O comando a seguir cria e popula este arquivo:

    sudo touch /var/opt/mssql/secrets/passwd
    sudo echo '<loginName>' >> /var/opt/mssql/secrets/passwd
    sudo echo '<password>' >> /var/opt/mssql/secrets/passwd
    sudo chown root:root /var/opt/mssql/secrets/passwd
    sudo chmod 600 /var/opt/mssql/secrets/passwd
    

    Cuidado

    Sua senha deve seguir a política de senha padrão do SQL Server. Por padrão, a senha precisa ter pelo menos oito caracteres e conter caracteres de três dos seguintes quatro conjuntos: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As senhas podem ter até 128 caracteres. Use senhas longas e complexas.

  2. Todos os nós de cluster devem acessar uns aos outros por meio do SSH. Ferramentas como hb_report ou crm_report (para solução de problemas) e o Explorador de Histórico do Hawk exigem acesso SSH sem senha entre os nós. Caso contrário, eles só poderão coletar dados do nó atual. Se você usar uma porta SSH não padrão, use a opção -X (consulte a página man). Por exemplo, se a porta SSH for 3479, invoque um hb_report com:

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

    Para obter mais informações, consulte Requisitos de sistema e as recomendações na documentação do SUSE.

  3. Instalar a extensão de Alta Disponibilidade. Para instalar a extensão, siga as etapas no artigo do SUSE a seguir:

    Início rápido de instalação e configuração

  4. Instalar o agente do recurso FCI para SQL Server. Execute os seguintes comandos em ambos os nós:

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/12/mssql-server-2017.repo
    sudo zypper --gpg-auto-import-keys refresh
    sudo zypper install mssql-server-ha
    
  5. Configure automaticamente o primeiro nó. A próxima etapa é configurar um cluster de um nó em execução por meio da configuração do primeiro nó, SLES1. Siga as instruções no artigo sobre o SUSE Configurar o primeiro nó.

    Quando terminar, verifique o status do cluster com crm status:

    crm status
    

    Ele mostra que um nó, SLES1, está configurado.

  6. Adicionar nós a um cluster existente. Em seguida, adicione o nó SLES2 ao cluster. Siga as instruções no artigo sobre o SUSE Adicionar o segundo nó.

    Quando terminar, verifique o status do cluster com crm status. Se você conseguir adicionar um segundo nó, a saída será semelhante ao exemplo a seguir:

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

    Observação

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

  7. Procedimentos de remoção. Se você precisar remover um nó do cluster, use o script de inicialização ha-cluster-remove. Para obter mais informações, consulte visão geral dos Scripts de inicialização.

Configurar os recursos de cluster para o SQL Server

As etapas a seguir explicam como configurar o recurso de cluster para o SQL Server. Personalize as duas seguintes configurações:

  • Nome de recurso do SQL Server: um nome para o recurso clusterizado do SQL Server.
  • O valor de tempo limite é o tempo que o cluster aguarda enquanto um recurso é colocado online. Para o SQL Server, esse valor representa o tempo que você espera que o SQL Server leve para colocar o master banco de dados online.

Atualize os valores no script a seguir para seu ambiente. Execute o script em um nó para configurar e iniciar o serviço clusterizado.

sudo crm configure
primitive <sqlServerResourceName> ocf:mssql:fci op start timeout=<timeout_in_seconds>
colocation <constraintName> inf: <virtualIPResourceName> <sqlServerResourceName>
show
commit
exit

Por exemplo, o script a seguir cria um recurso clusterizado do SQL Server chamado mssqlha.

sudo crm configure
primitive mssqlha ocf:mssql:fci op start timeout=60s
colocation admin_addr_mssqlha inf: admin_addr mssqlha
show
commit
exit

Depois de confirmar a configuração, o SQL Server será iniciado no mesmo nó que o recurso de IP virtual.

Para obter mais informações, confira Como configurar e gerenciar recursos de cluster (linha de comando).

Verifique se o SQL Server foi iniciado

Para verificar se o SQL Server foi iniciado, execute o comando crm status:

crm status

O exemplo a seguir mostra os resultados quando o Pacemaker é iniciado com êxito como um recurso clusterizado.

2 nodes configured
2 resources configured

Online: [ SLES1 SLES2 ]

Full list of resources:

 admin_addr     (ocf::heartbeat:IPaddr2):       Started SLES1
 mssqlha        (ocf::mssql:fci):       Started SLES1

Gerenciar recursos de cluster

Para gerenciar os recursos de cluster, confira o seguinte artigo sobre o SUSE: Gerenciar recursos de cluster

Failover manual

Embora os recursos estejam configurados para fazer failover ou migrar automaticamente para outros nós de cluster em falha de hardware ou software, você também pode movê-los manualmente usando a GUI do Pacemaker ou a linha de comando.

Use o migrate comando para esta tarefa. Por exemplo, para migrar o recurso SQL para um nó de cluster chamado SLES2, execute:

crm resource
migrate mssqlha SLES2