Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:SQL Server em Linux
Este guia fornece instruções para criar um cluster de discos partilhados de dois nós para SQL Server no SUSE Linux Enterprise Server (SLES). A camada de agrupamento é baseada no SUSE High Availability Extension (HAE) construído sobre Pacemaker.
Observação
A partir do SQL Server 2025 (17.x), o SUSE Linux Enterprise Server (SLES) não é suportado.
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 a seguir descrevem como configurar esses servidores.
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 tutorial, use o SLES com uma subscrição válida para o add-on HA.
Instalar e configurar o SQL Server em cada nó de cluster
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.
Designe um nó como primário e o outro como secundário, para fins de configuração. Utilize estes termos para seguir este guia.
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-serverObservação
No momento da configuração, uma chave mestra do servidor (SMK) é 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 chamadamssql. Por ser uma conta local, a sua identidade não é compartilhada entre nodos. Tens de copiar a chave de encriptação do nó primário para cada nó secundário para que cada conta localmssqlpossa aceder a ela e desencriptar o SMK.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-serverLigue-se à base de dados SQL Server
mastercom asaconta e execute o seguinte script: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.
No nó primário, pare e desative o SQL Server.
Siga os passos na documentação do SUSE para configurar e atualizar o ficheiro hosts para cada nó de cluster. O ficheiro
hostsdeve 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 showDefina 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/hostnameatravés do YAST ou manualmente .O exemplo a seguir mostra
/etc/hostscom adições para dois nós chamadosSLES1eSLES2.127.0.0.1 localhost 10.128.18.128 SLES1 10.128.16.77 SLES2Todos os nós do cluster devem ter acesso SSH sem palavra-passe uns aos outros. Caso contrário, ferramentas como
hb_report,crm_report, e o Explorador de História do Hawk só podem recolher dados do nó local. Se usar uma porta SSH não padrão, use a-Xopção (veja Outros Requisitos e Recomendações). Por exemplo, se a porta SSH for 3479, invoquecrm_reportcom:crm_report -X "-p 3479" [...]Para obter mais informações, consulte o Guia de Administração.
Na secção seguinte, configura o armazenamento partilhado e move os ficheiros da base de dados para esse armazenamento.
Configurar armazenamento compartilhado e mover arquivos de banco de dados
Pode usar várias soluções para fornecer armazenamento partilhado. Este passo a passo demonstra a configuração do armazenamento compartilhado com NFS. Siga as melhores práticas e use o Kerberos para garantir o NFS:
Se não seguires esta orientação, qualquer pessoa que possa aceder à tua rede e falsificar o endereço IP de um nó SQL pode aceder aos teus ficheiros de dados. Como sempre, faça modelação de ameaças no seu sistema antes de o usar em produção.
Outra opção de armazenamento é usar o compartilhamento de arquivos SMB:
- seção Samba do de documentação da SUSE
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 configurares o NFS do cliente para montar o caminho dos ficheiros de base de dados SQL Server para apontar para a localização partilhada, certifica-te de que guardas os ficheiros da base de dados numa localização temporária para os poderes copiar mais tarde para a partilha:
Apenas no nó primário, guarde os arquivos de base de dados numa localização temporária. O script seguinte cria um novo diretório temporário, copia os ficheiros da base de dados para o novo diretório e remove os ficheiros antigos da base de dados. Como o SQL Server é executado como usuário local
mssql, você precisa certificar-se de 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/* exitConfigure o cliente NFS em todos os nós do cluster:
Observação
Para as melhores práticas e recomendações do SUSE relativamente ao armazenamento NFS altamente disponível, consulte Armazenamento NFS Altamente Disponível com DRBD e Pacemaker.
Em cada nó, valide que o SQL Server inicia com sucesso com o novo caminho do ficheiro. Neste momento, apenas um nó deve executar o SQL Server de cada vez. Não podem correr ambos ao mesmo tempo porque tentam aceder aos ficheiros de dados simultaneamente.
Para evitar que o SQL Server inicie em ambos os nós, utilize um recurso de cluster de Sistema de Ficheiros para garantir que a partilha é montada apenas por um nó de cada vez.
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
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/passwdAtençã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.
Todos os nós do cluster devem aceder uns aos outros através de SSH. Ferramentas como
hb_reportoucrm_report(para resolução de problemas) e o History Explorer do Hawk requerem acesso SSH sem palavra-passe entre os nós. Caso contrário, só podem recolher dados do nó atual. Se usar uma porta SSH não padrão, use a-Xopção (vermanpágina). Por exemplo, se a sua porta SSH for 3479, invoque umhb_reportcom:crm_report -X "-p 3479" [...]Para obter mais informações, consulte Requisitos e recomendações do sistema na documentação do SUSE.
Instale a extensão de alta disponibilidade. Para instalar a extensão, siga as etapas no seguinte artigo da SUSE:
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-haConfigure 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 statusMostra que um nó, SLES1, está configurado.
Adicionar nós a um cluster existente. Em seguida, ligue 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 adicionares com sucesso um segundo nó, a saída é semelhante ao seguinte exemplo:
2 nodes configured 1 resource configured Online: [ SLES1 SLES2 ] Full list of resources: admin_addr (ocf::heartbeat:IPaddr2): Started SLES1Observação
admin_addr é o recurso virtual de IP do cluster que se configura durante a configuração inicial de um cluster de um único nó.
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. Personalize as seguintes duas definições:
- 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, este valor representa o tempo que se espera que o SQL Server demore para colocar a
masterbase de dados online.
Atualize os valores no script seguinte para o seu ambiente. Executa o script num 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 comprometeres a configuração, o SQL Server começa no mesmo nó do 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 seguinte mostra os resultados quando o Pacemaker arranca com sucesso como recurso agrupado.
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 fazer failover automático ou migrar para outros nós do cluster em caso de falha de hardware ou software, também pode movê-los manualmente usando a interface gráfica do Pacemaker ou a linha de comandos.
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