Partilhar via


Configurar o cluster de disco compartilhado SLES para SQL Server

Aplica-se a:SQL Server em 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 agrupamento é baseada no SUSE High Availability Extension (HAE) construído sobre Pacemaker.

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 12 SP5.

Pré-requisitos

Para concluir o seguinte cenário de ponta a ponta, você precisa de duas máquinas para implantar o cluster de dois nós e outro servidor para configurar o compartilhamento NFS. As etapas abaixo descrevem como esses servidores serão configurados.

Instalar e configurar o sistema operacional em cada nó do cluster

A primeira etapa é configurar o sistema operacional nos nós do cluster. Para este passo a passo, use o SLES com uma assinatura válida para o complemento 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, consulte Diretrizes de instalação do SQL Server no Linux.

  2. Designe um nó como primário e o outro como secundário, para fins de configuração. Utilize estes termos para seguir este guia.

  3. No nó secundário, pare e desabilite o SQL Server. O exemplo a seguir para e desabilita o SQL Server:

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

    Observação

    No momento da instalação, uma 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. Por ser uma conta local, a sua identidade não é compartilhada entre nodos. Portanto, você precisa copiar a chave de criptografia do nó primário para cada nó secundário para que cada conta mssql local possa acessá-la para descriptografar a Chave Mestra do Servidor.

  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 conta sa e execute o seguinte:

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

    Atenção

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

  5. No nó primário, pare e desative o SQL Server.

  6. Siga os passos na documentação do SUSE para configurar e atualizar o ficheiro hosts para cada nó de cluster. O ficheiro hosts deve incluir o endereço IP e o nome de cada nó de cluster.

    Para verificares o endereço IP do nó atual, executa:

    sudo ip addr show
    

    Defina o nome do computador em cada nó. Dê a cada nó um nome exclusivo com 15 caracteres ou menos. Defina o nome do computador, adicionando-o ao /etc/hostname através do 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 ser capazes de acessar uns aos outros via SSH. Ferramentas como hb_report ou crm_report (para resolução de problemas) e o Explorador de Histórico do Hawk exigem acesso SSH sem senha entre os nós; caso contrário, elas só conseguem coletar dados do nó atual. Caso você use 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, consulte 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 armazenamento compartilhado e mover arquivos de banco de dados

Existem várias soluções para fornecer armazenamento compartilhado. Este passo a passo demonstra a configuração do armazenamento compartilhado com NFS. Recomendamos seguir as práticas recomendadas e usar 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, certifique-se de modelar a ameaça do seu sistema antes de colocá-lo em produção.

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

Configurar um servidor NFS

Para configurar um servidor NFS, consulte as seguintes etapas na documentação do SUSE: Configurando o Servidor NFS.

Configurar todos os nós de cluster para se conectarem ao armazenamento compartilhado 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 posteriormente no compartilhamento:

  1. Apenas no nó primário, guarde os arquivos de base de dados numa 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. Como o SQL Server é executado como mssql de usuário local, você precisa garantir que, após a transferência de dados para o compartilhamento montado, o usuário local tenha acesso de leitura e 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 do cluster:

    Observação

    Você deve seguir as melhores práticas e recomendações da SUSE em relação ao armazenamento NFS altamente disponível: Armazenamento NFS Altamente Disponível com DRBD e Pacemaker.

  2. Valide se o SQL Server é iniciado com êxito com o novo caminho de arquivo. Faça isso em cada nó. Neste ponto, apenas um nó deve executar o SQL Server por vez. Ambos não podem ser executados ao mesmo tempo porque ambos tentarão acessar os arquivos de dados simultaneamente (para evitar iniciar acidentalmente o SQL Server em ambos os nós, use um recurso de cluster do Sistema de Arquivos para garantir que o compartilhamento não seja montado duas vezes pelos nós diferentes). Os comandos a seguir iniciam o SQL Server, verificam o status e param o SQL Server.

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

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

Instalar e configurar o Pacemaker em cada nó do cluster

  1. Em ambos os nós do cluster, crie um arquivo para armazenar o nome de usuário e a senha do SQL Server para o logon do Pacemaker. O comando a seguir cria e preenche esse 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
    

    Atenção

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

  2. Todos os nós de cluster devem ser capazes de acessar uns aos outros via SSH. Ferramentas como hb_report ou crm_report (para resolução de problemas) e o History Explorer do Hawk requerem acesso SSH sem necessidade de senha entre os nós, caso contrário, só conseguem recolher dados do nó atual. Caso você use uma porta SSH não padrão, use a opção -X (consulte a página do manual). 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 e recomendações do sistema na documentação do SUSE.

  3. Instale a extensão de alta disponibilidade. Para instalar a extensão, siga as etapas no seguinte artigo da SUSE:

    Início Rápido de Instalação e Configuração

  4. Instale o agente de recursos 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 nó único em funcionamento ao configurar o primeiro nó, SLES1. Siga as instruções no artigo da SUSE, Configurando o primeiro nó.

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

    crm status
    

    Deve mostrar que um nó, SLES1, está configurado.

  6. Adicionar nós a um cluster existente. Em seguida, junte o nó SLES2 ao cluster. Siga as instruções no artigo da SUSE, Adição do Segundo Nó.

    Quando terminar, verifique o estado do cluster com estado do crm. Se tiver adicionado com sucesso um segundo nó, a saída será semelhante à seguinte:

    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 IP virtual que é configurado durante a configuração inicial do cluster.

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

Configurar os recursos de cluster para o SQL Server

As etapas a seguir explicam como configurar o recurso de cluster para o SQL Server. Há duas configurações que você precisa personalizar.

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

Atualize os valores do script a seguir para seu ambiente. Execute 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 que a configuração for confirmada, o SQL Server será iniciado no mesmo nó que o recurso IP virtual.

Para obter mais informações, consulte Configurando e gerenciando 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 foi iniciado com êxito como 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 seus recursos de cluster, consulte o seguinte artigo da SUSE: Managing Cluster Resources

Comutação Manual

Embora os recursos estejam configurados para realizar uma alternância automática (ou migração) para outros nós do cluster em caso de falha de hardware ou software, pode-se também mover manualmente um recurso para outro nó no cluster usando a interface gráfica do utilizador do Pacemaker ou a linha de comando.

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

crm resource
migrate mssqlha SLES2