Partilhar via

Noções básicas de disponibilidade do SQL Server para implantações do Linux

  • Artigo

Aplica-se a: SQL Server – Linux

Começando com o SQL Server 2017 (14.x), o SQL Server é compatível no Linux e no Windows. Como as implantações do SQL Server baseadas no Windows, os bancos de dados e as instâncias do SQL Server precisam estar altamente disponíveis no Linux. Este artigo aborda os aspectos técnicos do planejamento e da implantação de instâncias e bancos de dados do SQL Server baseados no Linux altamente disponíveis, bem como algumas das diferenças das instalações baseadas no Windows. Como o SQL Server pode ser novo para profissionais do Linux, e o Linux pode ser novo para profissionais do SQL Server, às vezes, o artigo apresenta conceitos que podem ser familiares para alguns e desconhecidos para outros.

Opções de disponibilidade do SQL Server para implantações do Linux

Além de backup e restauração, os mesmos três recursos de disponibilidade estão disponíveis no Linux como nas implantações baseadas no Windows:

No Windows, as FCIs exigem sempre um WSFC (cluster de failover do Windows Server) subjacente. Dependendo do cenário de implantação, um AG geralmente exige um WSFC subjacente, com a exceção sendo a nova variante None no SQL Server 2017 (14.x). Um WSFC não existe no Linux. A implementação de clustering no Linux é discutida em Pacemaker para grupos de disponibilidade e instâncias de cluster de failover no Linux.

Um rápido manual do Linux

Embora algumas instalações do Linux possam ser realizadas com uma interface, a maioria não pode. Isso significa que quase tudo na camada do sistema operacional é feito por meio da linha de comando. O termo comum para essa linha de comando no mundo Linux é um shell de Bash.

No Linux, muitos comandos precisam ser executados com privilégios elevados, como muitas ações que precisam ser feitas no Windows Server como administrador. Há dois métodos principais a serem executados com privilégios elevados:

  1. Execute no contexto do usuário apropriado. Para alterar para outro usuário, use o comando su. Se su for executado por conta própria sem um nome de usuário, desde que você saiba a senha, agora você estará em um shell como root.

  2. A maneira mais comum e segura de executar ações é usar sudo antes de executar qualquer coisa. Muitos dos exemplos neste artigo usam sudo.

Alguns comandos comuns, cada um com vários comutadores e opções que podem ser pesquisados online:

  • cd – alterar o diretório
  • chmod – alterar as permissões de um arquivo ou diretório
  • chown – alterar as propriedade de um arquivo ou diretório
  • ls – mostrar o conteúdo de um diretório
  • mkdir – criar uma pasta (diretório) em uma unidade
  • mv – mover um arquivo de uma localização para outra
  • ps – mostrar todos os processos de trabalho
  • rm – excluir um arquivo localmente em um servidor
  • rmdir – excluir uma pasta (diretório)
  • systemctl – iniciar, parar ou habilitar serviços
  • Comandos do editor de texto. No Linux, há várias opções de editor de texto, como vi e emacs.

Tarefas comuns de configurações de disponibilidade do SQL Server no Linux

Esta seção aborda as tarefas comuns a todas as implantações do SQL Server baseadas no Linux.

Verifique se os arquivos podem ser copiados

Copiar arquivos de um servidor para outro é uma tarefa que qualquer pessoa que use o SQL Server no Linux deve ser capaz de fazer. Essa tarefa é muito importante para as configurações do AG.

Aspectos como problemas de permissão podem existir no Linux e em instalações baseadas no Windows. No entanto, aqueles familiarizados com a cópia de servidor para servidor no Windows podem não saber como isso ele é feito no Linux. Um método comum é usar o utilitário scp de linha de comando, que representa a cópia segura. Nos bastidores, scp o usa o OpenSSH. SSH significa Secure Shell. Dependendo da distribuição do Linux, o OpenSSH pode não estar instalado. Se não estiver, o OpenSSH precisará ser instalado primeiro. Para obter mais informações sobre como configurar o OpenSSH, confira as informações nos links a seguir para cada distribuição:

Ao usar scp, você deverá fornecer as credenciais do servidor se ele não for a origem ou o destino. Por exemplo, usando

scp MyAGCert.cer username@servername:/folder/subfolder

copia o arquivo MyAGCert.cer para a pasta especificada no outro servidor. Você deve ter permissões e, possivelmente, a propriedade do arquivo para copiá-lo. Portanto, chown também pode precisar ser empregado antes da cópia. De modo semelhante, no lado de recebimento, o usuário certo precisa de acesso para manipular o arquivo. Por exemplo, para restaurar esse arquivo de certificado, o usuário mssql deve ser capaz de acessá-lo.

Samba, que é a variante do Linux do protocolo SMB, também pode ser usado para criar compartilhamentos acessados por caminhos UNC, como \\SERVERNAME\SHARE. Para obter mais informações sobre como configurar Samba, confira as informações nos links a seguir para cada distribuição:

Os compartilhamentos SMB baseados no Windows também podem ser usados; os compartilhamentos SMB não precisam ser baseados no Linux, desde que a parte do cliente do Samba esteja configurada corretamente no servidor Linux que hospeda SQL Server e o compartilhamento tenha o acesso certo. Para aqueles em um ambiente misto, essa seria uma maneira de usar a infraestrutura existente para implantações do SQL Server baseadas no Linux.

Um aspecto importante é que a versão do Samba implantada deve estar em conformidade com SMB 3.0. Quando o suporte a SMB foi adicionado no SQL Server 2012 (11.x), ele exigia que todos os compartilhamentos fossem compatíveis com o SMB 3.0. Se estiver usando o Samba para o compartilhamento, e não para o Windows Server, o compartilhamento baseado no Samba deverá usar o Samba 4.0 ou posterior e, idealmente, 4.3 ou posterior, que é compatível com o SMB 3.1.1. Uma boa fonte de informações sobre SMB e Linux é SMB3 in Samba.

Por fim, o uso de um compartilhamento NFS (Network File System) é uma opção. Usar o NFS não é uma opção em implantações do SQL Server baseadas no Windows e só pode ser usado para implantações baseadas no Linux.

Configurar o firewall

Semelhantes ao Windows, as distribuições do Linux têm um firewall interno. Se a sua empresa estiver usando um firewall externo para os servidores, a desabilitação dos firewalls no Linux poderá ser aceitável. No entanto, independentemente de onde o firewall está habilitado, as portas precisam estar abertas. A tabela a seguir documenta as portas comuns necessárias para implantações do SQL Server altamente disponíveis no Linux.

Número da porta Type Descrição
111 TCP/UDP NFS – rpcbind/sunrpc
135 TCP Samba (se usado) – Mapeador de pontos de extremidade
137 UDP Samba (se usado) – Serviço de nome NetBIOS
138 UDP Samba (se usado) – Datagrama NetBIOS
139 TCP Samba (se usado) – Sessão NetBIOS
445 TCP Samba (se usado) – SMB sobre TCP
1433 TCP SQL Server – porta padrão; se desejar, pode mudar com mssql-conf set network.tcpport <portnumber>
2049 TCP, UDP NFS (se usado)
2224 TCP Pacemaker – usado por pcsd
3121 TCP Pacemaker – Obrigatório se houver nós remotos do Pacemaker
3260 TCP Iniciador iSCSI (se usado) – Pode ser alterado em /etc/iscsi/iscsid.config (RHEL), mas deve corresponder à porta do destino iSCSI
5022 TCP SQL Server – porta padrão usada para um ponto de extremidade do AG; pode ser alterada ao criar o ponto de extremidade
5403 TCP Pacemaker
5404 UDP Pacemaker – Exigido por Corosync se estiver usando o UDP multicast
5405 UDP Pacemaker – Exigido por Corosync
21064 TCP Pacemaker – Exigido pelos recursos que usam a DLM
Variável TCP Porta do ponto de extremidade do AG; o padrão é 5022
Variável TCP NFS – porta para LOCKD_TCPPORT (encontrada em /etc/sysconfig/nfs no RHEL)
Variável UDP NFS – porta para LOCKD_UDPPORT (encontrada em /etc/sysconfig/nfs no RHEL)
Variável TCP/UDP NFS – porta para MOUNTD_PORT (encontrada em /etc/sysconfig/nfs no RHEL)
Variável TCP/UDP NFS – porta para STATD_PORT (encontrada em /etc/sysconfig/nfs no RHEL)

Para portas adicionais que podem ser usadas pelo Samba, confira Uso de porta do Samba.

Por outro lado, o nome do serviço no Linux também pode ser adicionado como uma exceção, em vez da porta; por exemplo, high-availability para Pacemaker. Confira sua distribuição para obter os nomes se essa for a direção que você deseja buscar. Por exemplo, no RHEL, o comando a ser adicionado no Pacemaker é

sudo firewall-cmd --permanent --add-service=high-availability

Documentação do firewall

Instalar pacotes do SQL Server para disponibilidade

Em uma instalação do SQL Server baseada no Windows, alguns componentes são instalados mesmo em uma instalação básica do mecanismo, enquanto outros não são. No Linux, somente o mecanismo do SQL Server é instalado como parte do processo de instalação. Tudo o mais é opcional. Para instâncias do SQL Server altamente disponíveis no Linux, dois pacotes devem ser instalados com o SQL Server:

  • SQL Server Agent (mssql-server-agent)
  • o pacote de HA (alta disponibilidade) (mssql-server-ha)

Embora o SQL Server Agent seja tecnicamente opcional, ele é o agendador do SQL Server para trabalhos e é exigido pelo envio de logs, de modo que a instalação é recomendada.

No SQL Server 2017 (14.x) com CU 4 e versões posteriores, o SQL Server Agent está incluído no pacote do mecanismo de banco de dados, mas você ainda precisa habilitá-lo. Em instalações baseadas no Windows, o SQL Server Agent não é opcional.

Observação

Para os iniciantes no SQL Server, o SQL Server Agent é o agendador de trabalho interno do SQL Server. Você pode agendar ações como backups e outras manutenções do SQL Server. Ao contrário de uma instalação do SQL Server baseada no Windows, em que o SQL Server Agent é um serviço completamente diferente, no Linux, o SQL Server Agent é executado no contexto do próprio SQL Server.

Quando AGs ou FCIs são configurados em uma configuração baseada no Windows, eles têm reconhecimento de cluster. O reconhecimento de cluster significa que o SQL Server tem DLLs de recurso específicas que um WSFC conhece (sqagtres.dll e sqsrvres.dll para FCIs, hadrres.dll para AGs) e são usadas pelo WSFC para garantir que a funcionalidade clusterizada do SQL Server esteja ativa, em execução e funcionando corretamente. Como o clustering é externo não apenas ao SQL Server como ao próprio Linux, a Microsoft teve de codificar o equivalente a uma DLL de recurso para implantações de FCI e AG baseadas no Linux. Esse é o pacote mssql-server-ha, também conhecido como agente de recurso do SQL Server para o Pacemaker. Para instalar o pacote mssql-server-ha, confira Implantar um cluster do Pacemaker para o SQL Server no Linux.

Os outros pacotes opcionais para o SQL Server no Linux, Pesquisa de Texto Completo do SQL Server (mssql-server-fts) e SQL Server Integration Services (mssql-server-is), não são necessários para alta disponibilidade, seja para uma FCI ou um AG.

Parceiros de alta disponibilidade e recuperação de desastre do SQL Server

Para fornecer alta disponibilidade e recuperação de desastres para seus serviços do SQL Server, escolha entre as várias ferramentas do setor. Esta seção destaca empresas parceiras da Microsoft com soluções de recuperação de desastres e disponibilidade alta com suporte ao Microsoft SQL Server.

Partner (parceiro) Descrição
DH2i DxEnterprise é software de Disponibilidade Inteligente para Windows, Linux e Docker que ajuda você a alcançar o tempo de inatividade planejado ou não planejado praticamente nulo, permite grande economia nos custos, simplifica drasticamente o gerenciamento e permite uma consolidação física e lógica.

- Implantar grupos de disponibilidade com o DH2i DxEnterprise no Kubernetes
- Tutorial: configurar um grupo de disponibilidade Always On de três nós com o DH2i DxEnterprise
HPE Serviceguard O HPE SGLX oferece opções de monitoramento e recuperação sensíveis ao contexto para a Instância de Cluster de Failover e os Grupos de Disponibilidade Always On. Maximize o tempo de atividade com HPE SGLX sem comprometer a integridade de dados e o desempenho.

- Tutorial: configurar um grupo de disponibilidade Always On de três nós com o HPE Serviceguard para Linux.
Pacemaker O Pacemaker é um gerenciador de recursos de cluster de alta disponibilidade de código aberto. Com o Corosync, um sistema de comunicação de grupo de código aberto, o Pacemaker pode detectar falhas de componentes e orquestrar os procedimentos de failover necessários para minimizar interrupções nos aplicativos.

- Pacemaker para Grupos de Disponibilidade e instâncias de cluster de failover no Linux
- Implantar um cluster do Pacemaker para o SQL Server em Linux

Conteúdo relacionado