Configurar o cluster de disco compartilhado SLES para o SQL Server
Aplica-se a:
SQL Server – Linux
Este guia fornece instruções sobre como criar um cluster de disco compartilhado de dois nós para o SQL Server no SLES (SUSE Linux Enterprise Server). A camada de clustering baseia-se no HAE (Extensão de Alta Disponibilidade) do SUSE criado com base no Pacemaker.
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 SP2.
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 abaixo descrevem como esses servidores serão configurados.
Instalar e configurar o sistema operacional em cada nó de cluster
A primeira etapa é configurar o sistema operacional nos nós de cluster. Para esse 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
Instalar e configurar o SQL Server em ambos os nós. Para obter instruções detalhadas, confira Instalar o SQL Server em Linux.
Designe um nó como primário e o outro como secundário para fins de configuração. Use esses termos para seguir este guia.
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-serverObservaçã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. Como é uma conta local, a identidade dela não é compartilhada entre os nós. Portanto, você precisa copiar a chave de criptografia do nó primário para cada nó secundário, de modo que cada conta mssql local possa acessá-la para descriptografar a Chave Mestra do Servidor.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-serverConecte-se ao banco de dados
masterdo SQL Server com a conta “sa” e execute o seguinte:USE [master] GO CREATE LOGIN [<loginName>] with PASSWORD= N'<loginPassword>' GRANT VIEW SERVER STATE TO <loginName>No nó primário, interrompa e desabilite o SQL Server.
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 showDefina 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/hostnameusando o 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 de cluster devem ser capazes de acessar um ao outro via SSH. Ferramentas como hb_report ou crm_report (para solução de problemas) e Gerenciador de histórico do Hawk exigem acesso SSH sem senha entre os nós, caso contrário, eles podem apenas coletar dados do nó atual. Caso você use uma porta SSH não padrão, use a opção -X (confira a página de manual). Por exemplo, se a porta SSH é 3479, invoque um 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á os arquivos de banco de dados para esse armazenamento.
Configurar o armazenamento compartilhado e mover arquivos de banco de dados
Há várias de soluções para fornecer armazenamento compartilhado. Este passo a passo demonstra como configurar o armazenamento compartilhado com o NFS. Recomendamos o seguimento das melhores práticas e usar o 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, verifique que você tenha o modelo de risco do sistema antes de usá-lo 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 de arquivos de banco de dados do SQL Server para que ele aponte para a localização de armazenamento compartilhado, salve os arquivos de banco de dados em uma localização temporária para poder copiá-los posteriormente no compartilhamento:
Somente no nó primário, salve os arquivos de banco de dados em uma localização temporária. O script a seguir, cria um 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/* exitConfigure o cliente NFS em todos os nós de cluster:
Observação
É recomendável seguir as melhores práticas e as recomendações do SUSE referentes ao armazenamento NFS altamente disponível: Armazenamento NFS altamente disponível com DRBD e Pacemaker.
Verifique 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. Eles não podem ser executados ao mesmo tempo, porque tentarão acessar os arquivos de dados simultaneamente (para evitar a inicialização acidental do 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 por nós diferentes). 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
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 '<loginPassword>' >> /var/opt/mssql/secrets/passwd sudo chown root:root /var/opt/mssql/secrets/passwd sudo chmod 600 /var/opt/mssql/secrets/passwdTodos os nós de cluster devem ser capazes de acessar um ao outro via SSH. Ferramentas como hb_report ou crm_report (para solução de problemas) e Gerenciador de histórico do Hawk exigem acesso SSH sem senha entre os nós, caso contrário, eles podem apenas coletar dados do nó atual. No caso de você usar uma porta SSH não padrão, use a opção -X (consulte a página do manual). Por exemplo, se a porta SSH é 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.
Instalar a extensão de Alta Disponibilidade. Para instalar a extensão, siga as etapas no artigo do SUSE a seguir:
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-haConfigure 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 statusEle deve mostrar que esse único nó, SLES1, está configurado.
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ê tiver adicionado um segundo nó, a saída será semelhante ao seguinte:
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 de cluster de IP virtual que é configurado durante a configuração do cluster inicial de um nó.
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. Há duas configurações que você precisa personalizar.
- 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 é o tempo durante o qual você espera que o SQL Server coloque o banco de dados
masteronline.
Atualize os valores com base no script a seguir para o seu ambiente. Faça a execução 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ó do 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
Os exemplos a seguir mostram os resultados de quando o Pacemaker iniciou com êxito um recurso de cluster.
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 sejam configurados para fazer failover (ou migrar) automaticamente para outros nós do cluster no caso de uma falha de hardware ou de software, você também poderá mover manualmente um recurso para outro nó no cluster usando a GUI do Pacemaker ou a linha de comando.
Use o comando migrate para essa tarefa. Por exemplo, para migrar o recurso SQL para um nó de cluster chamado SLES2, execute:
crm resource
migrate mssqlha SLES2
Conteúdo relacionado
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários