Os Grupos de Disponibilidade Always On do SQL Server são a tecnologia mais recente da Microsoft para atender às necessidades de alta disponibilidade e recuperação de desastres das organizações que usam o SQL Server. Uma grande vantagem do AlwaysOn é a capacidade de lidar com HA e DR em uma implementação. Experimentamos os seguintes principais benefícios do AlwaysOn:
Podemos agrupar bancos de dados relacionados como parte de um único Grupo de Disponibilidade e fazer failover deles juntos, caso seja necessário. Isso é especialmente útil para aplicativos que dependem de mais de um banco de dados, como Microsoft Office SharePoint, Microsoft Lync e Sage.
Quando comparado às instâncias de cluster de failover do SQL Server, descobrimos que o armazenamento como um único ponto de falha foi eliminado, pois cada instância que constitui uma réplica é atribuído seu próprio armazenamento.
Com AlwaysOn, é possível configurar HA e DR de uma só vez. Isso é obtido criando clusters de failover do Windows de vários sites como as bases de sua configuração AlwaysOn. Executar uma alternância de função ao usar AlwaysOn é significativamente mais simples do que fazê-lo ao usar o envio de logs de transações.
Objetos de Computador
O Active Directory (AD) é um assunto extenso e não entraremos em detalhes neste artigo. Como você pode imaginar, o Active Directory é o serviço de diretório da Microsoft. Em termos de rede de computadores, um serviço de diretório é um recurso que nos permite registrar, identificar e gerenciar todos os objetos dentro de uma rede de forma centralizada. As entradas nos serviços de diretório mapeiam os nomes dos dispositivos de rede para os endereços IP correspondentes e outras propriedades no diretório. Os objetos mais comuns em um serviço de diretório (e no AD da Microsoft) são Usuários e Computadores. Assim como cada usuário no domínio pode ser registrado e gerenciado no Active Directory, todos os computadores no domínio também podem ser gerenciados no Active Directory. Assim como se espera que cada usuário tenha uma conta exclusiva no Active Directory, cada computador também tem.
No Active Directory, nem todos os objetos de computador são mapeados para um computador físico. Um objeto de computador pode representar um computador físico (estação de trabalho ou servidor), mas também pode representar algo que age como um computador, como o nome representativo de um cluster do Windows ou o nome virtual de um serviço de cluster (função). Essas representações também são exclusivas no Active Directory, assim como os nomes de computador comuns.
CNOs e VNOs no WSFC
Quando você instala um Windows Failover Cluster, o instalador cria uma entidade no Active Directory chamada Computer Name Object (CNO). Este CNO é a entidade primária criada no Active Directory para o cluster e representa o “Nome do Servidor” de todo o cluster. Subsequentemente, outros objetos conhecidos como Virtual Name Objects são criados pelo CNO ao realizar atividades como a criação de Funções de Cluster, Grupos de Disponibilidade, ou Ouvintes do Grupo de Disponibilidade . Esses CNOs e VNOs têm endereços IP associados a eles. Você pode especificar esses endereços ao instalar o cluster ou criar uma nova função de cluster ou um ouvinte. Para cada cluster, função e ouvinte que você cria, você precisa de um nome de computador exclusivo e um endereço IP exclusivo. A Fig. 1 mostra a etapa durante a qual você especifica o Cluster Name Object e seu endereço IP ao configurar um cluster.
Os nomes que você usa ao configurar um cluster são completamente arbitrários. Eles só precisam ser únicos. No entanto, é aconselhável seguir as convenções de nomenclatura de sua organização para computadores comuns ao criar CNOs ou VNOs – isso ajuda a manter o gerenciamento mais fácil. Também faz sentido usar um bloco específico de endereços IP que cobrirá todas as necessidades de endereçamento de todo o cluster – o CNO e todos os VNOs (funções) que você pretende criar.
Fig. 1 Mapeamento de nome para endereço em um cluster
As principais permissões de domínio
O DBA ou administrador do sistema que executa uma instalação de cluster deve ter permissão para Criar objetos de computador no domínio do Active Directory. Por sua vez, depois de criar o objeto de nome de computador, o administrador do domínio deve conceder as seguintes permissões ao objeto de nome de computador para que as funções (que resultam em objetos de nome virtual) possam ser criadas com êxito no cluster:
Criar objetos de computador
Ler todas as propriedades
Sem essas permissões, é provável que você receba mensagens de erro semelhantes à abaixo ao tentar criar uma função (no caso de AlwaysOn FCI ) ou um Ouvinte (no caso de AlwaysOn AG ):
Erro durante a instalação do MS SQL Server Cluster:
O recurso de nome de rede do cluster 'SQL Network Name (EUK-SCCM-01)' falhou ao criar seu objeto de computador associado no domínio 'domainname.com' pelo seguinte motivo:Não foi possível criar uma conta de computador.
O texto do código de erro associado é:Acesso negado.
Esta mensagem de erro é observada no Visualizador de Eventos, pois o SQL Server não estaria acessível neste momento. Você também poderá ver isso se navegar até os arquivos SQL Error Log na pasta LOG que fica no diretório de instalação do SQL Server. A frase-chave é “Acesso negado ”.
Outros requisitos
Devo mencionar o conceito de um controlador de domínio. Um controlador de domínio, ou mais precisamente, um conjunto de controladores de domínio fornece serviços importantes para o Active Directory, como registrar objetos e autenticar usuários e computadores. Para configurar com êxito um cluster ou um AlwaysOn Listener, um controlador de domínio deve ser acessível a partir do computador em que você está executando a configuração. Isso significa que a comunicação do computador com o controlador de domínio deve ser aberta em um intervalo de portas TCP e UDP. A Microsoft documenta isso em detalhes neste artigo . Isso pode ser um dado na maioria dos casos, mas ao solucionar problemas de conectividade, ajuda saber o que é realmente necessário.
Em um artigo anterior , também mencionei que é necessário conceder permissões ao CNO de um cluster ao configurar um Quorum de Compartilhamento de Arquivos.
Fig. 2 Permissões em um compartilhamento de arquivos
Uma observação sobre a resolução de nomes
Sendo objetos de computador, CNOs e VNOs dependem do Domain Name Service para resolver o nome indicado ao instalar o cluster, criar uma função ou criar um AlwaysOn Listener. Normalmente, os clientes recebem esses nomes de computador para estabelecer uma conexão com o cluster. Em outras palavras, o endereço IP é transparente para eles, simplificando a configuração do cliente e abstraindo os failovers dos usuários finais.
Fig. 3 Propriedades do ouvinte AG para ouvinte com dois endereços IP
Em um artigo anterior, mencionei um caso em que esse cenário pode causar problemas. Em nosso cluster de vários sites, tínhamos um ouvinte para nosso Grupo de Disponibilidade AlwaysOn. Este ouvinte foi configurado para resolver dois endereços IP. Isso é necessário para um cluster de vários sites abrangendo várias sub-redes. Em tal configuração, o servidor de nomes retornará ambos os endereços IP mapeados para o ouvinte ao emitir um nslookup verifique (veja a Fig. 4). No entanto, ao conectar, você pode acessar apenas um desses endereços IP por vez. O Cluster Manager mostrará o outro endereço IP como Offline (ver Fig. 5).
Fig. 4 Propriedades do ouvinte AG para ouvinte com dois endereços IP
Fig. 5 Propriedades para função de cluster com dois endereços IP em sub-redes separadas
Isso é normal. Se houver um failover para o site alternativo, o servidor DNS começará a resolver o endereço IP alternativo após alguns minutos. A implicação disso é que a comunicação dos clientes com o site alternativo deve ser possível. A Fig. 6 e a Fig. 7 destacam isso ainda mais.
Fig. 6 Caminho de comunicação com a réplica primária em Dakar
Vamos dar uma boa olhada no caminho que os pacotes percorrerão dos computadores clientes para o cluster. Quando a Réplica Primária está em Dakar, o nome do Listener SQL-SVR-LNR é resolvido para o endereço IP 192.168.1.20 e o WFCS, por sua vez, direciona a solicitação ao servidor 192.168.1.22 (observe que este servidor também possui seu próprio nome do computador). No caso de um failover para Nairobi, temos o caminho de comunicação passando por 192.168.2.20 e depois para 192.168.2.22. A implicação é que, para uma experiência perfeita do cliente, todos os clientes em todos os data centers devem ter a comunicação permitida em todos os firewalls envolvidos usando a porta 1433.
Fig. 7 Caminho de comunicação com a réplica primária em Nairobi
Conclusão
Embora o Windows Failover Clustering, o Active Directory e o Domain Name Service possam estar fora da função do Administrador de Banco de Dados, vale a pena ter uma compreensão básica de como essas tecnologias funcionam para poder criar e solucionar problemas do AlwaysOn Instâncias de cluster de failover e grupos de disponibilidade AlwaysOn. Algumas organizações têm uma estrita separação de funções entre administradores de sistema e administradores de banco de dados, mas quando esse não for o caso, o administrador de banco de dados precisa ser capaz de entender esses conceitos do Windows para ter sucesso como DBA.
Referências
Visão geral dos grupos de disponibilidade AlwaysOn
Agrupamento de failover do Windows com SQL Server
Visão geral do serviço e requisitos de porta de rede para Windows
Administrando objetos de computador
