Os Grupos de Disponibilidade AlwaysOn do SQL Server 2012 exigem um ponto de extremidade de espelhamento de banco de dados para cada instância do SQL Server que hospedará uma réplica do grupo de disponibilidade e/ou sessão de espelhamento de banco de dados. Esse ponto de extremidade da instância do SQL Server é compartilhado por uma ou mais réplicas de grupo de disponibilidade e/ou sessões de espelhamento de banco de dados e é o mecanismo de comunicação entre a réplica primária e as réplicas secundárias associadas.
Dependendo das cargas de trabalho de modificação de dados na réplica primária, os requisitos de taxa de transferência de mensagens do grupo de disponibilidade podem não ser triviais. Essa atividade também é sensível ao tráfego da atividade simultânea do grupo de indisponibilidade. Se a taxa de transferência estiver sofrendo devido à largura de banda degradada e ao tráfego simultâneo, considere isolar o tráfego do grupo de disponibilidade para seu próprio adaptador de rede dedicado para cada instância do SQL Server que hospeda uma réplica de disponibilidade. Esta postagem descreverá esse processo e também descreverá brevemente o que você pode esperar ver em um cenário de taxa de transferência degradada.
Para este artigo, estou usando um convidado virtual de cinco nós do Windows Server Failover Cluster (WSFC). Cada nó no WSFC tem sua própria instância autônoma do SQL Server usando armazenamento local não compartilhado. Cada nó também tem um adaptador de rede virtual separado para comunicação pública, um adaptador de rede virtual para comunicação WSFC e um adaptador de rede virtual que dedicaremos à comunicação do grupo de disponibilidade. Para os fins desta postagem, focaremos nas informações necessárias para os adaptadores de rede dedicados do grupo de disponibilidade em cada nó:
| Nome do nó WSFC | Endereços TCP/IPv4 da NIC do Grupo de Disponibilidade |
|---|---|
| SQL2K12-SVR1 | 192.168.20.31 |
| SQL2K12-SVR2 | 192.168.20.32 |
| SQL2K12-SVR3 | 192.168.20.33 |
| SQL2K12-SVR4 | 192.168.20.34 |
| SQL2K12-SVR5 | 192.168.20.35 |
A configuração de um grupo de disponibilidade usando uma NIC dedicada é quase idêntica a um processo de NIC compartilhado, apenas para “vincular” o grupo de disponibilidade a uma NIC específica, primeiro preciso designar o
LISTENER_IP argumento no CREATE ENDPOINT comando, usando os endereços IP mencionados acima para minhas NICs dedicadas. Abaixo mostra a criação de cada endpoint nos cinco nós WSFC::CONNECT SQL2K12-SVR1
USE [master];
GO
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
USE [master];
GO
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
:CONNECT SQL2K12-SVR2
-- ...repeat for other 4 nodes... Depois de criar esses endpoints associados à NIC dedicada, o restante das minhas etapas na configuração da topologia do grupo de disponibilidade não é diferente de um cenário de NIC compartilhado.
Depois de criar meu grupo de disponibilidade, se eu começar a direcionar a carga de modificação de dados nos bancos de dados de disponibilidade da réplica primária, posso ver rapidamente que o tráfego de comunicação do grupo de disponibilidade está fluindo na NIC dedicada usando o Gerenciador de tarefas na guia de rede (a primeira seção é a taxa de transferência para a NIC do grupo de disponibilidade dedicado):
E também posso acompanhar as estatísticas usando vários contadores de desempenho. Na imagem abaixo, a conexão de rede Inetl[R] PRO_1000 MT _2 é minha placa de rede dedicada do grupo de disponibilidade e tem a maior parte do tráfego da placa de rede em comparação com as outras duas placas de rede:
Agora, ter uma NIC dedicada para tráfego de grupo de disponibilidade pode ser uma maneira de isolar a atividade e, teoricamente, melhorar o desempenho, mas se sua NIC dedicada tiver largura de banda insuficiente, como você pode esperar, o desempenho sofrerá e a integridade da topologia do grupo de disponibilidade será degradada.
Por exemplo, alterei a NIC do grupo de disponibilidade dedicado na réplica primária para uma largura de banda de transferência de saída de 28,8 Kbps para ver o que aconteceria. Escusado será dizer que não foi bom. A taxa de transferência da NIC do grupo de disponibilidade caiu significativamente:
Em alguns segundos, a integridade das várias réplicas se deteriorou, com algumas réplicas passando para um estado “não sincronizado”:
Aumentei a NIC dedicada na réplica primária para 64 Kbps e, após alguns segundos, também houve um pico inicial de recuperação:
Enquanto as coisas melhoraram, testemunhei desconexões periódicas e avisos de integridade nesta configuração de taxa de transferência de NIC mais baixa:
E as estatísticas de espera associadas na réplica primária?
Quando havia muita largura de banda na NIC dedicada e todas as réplicas de disponibilidade estavam em um estado íntegro, vi a seguinte distribuição durante meus carregamentos de dados em um período de 2 minutos:
HADR_WORK_QUEUE representa um thread de trabalho em segundo plano esperado aguardando novo trabalho. HADR_LOGCAPTURE_WAIT representa outra espera esperada para que novos registros de log fiquem disponíveis e, de acordo com os Manuais Online, é esperado se a verificação de log for detectada ou estiver lendo do disco. Quando reduzi a taxa de transferência da NIC o suficiente para colocar o grupo de disponibilidade em um estado não íntegro, a distribuição do tipo de espera foi a seguinte:
Agora vemos um novo tipo de espera superior,
HADR_NOTIFICATION_DEQUEUE . Este é um daqueles tipos de espera “somente para uso interno”, conforme definido pelos Manuais Online, representando uma tarefa em segundo plano que processa notificações do WSFC. O interessante é que esse tipo de espera não aponta diretamente para um problema e, no entanto, os testes mostram que esse tipo de espera chega ao topo em associação com a taxa de transferência de mensagens do grupo de disponibilidade degradada. Portanto, isolar a atividade do grupo de disponibilidade para uma NIC dedicada pode ser benéfico se você estiver fornecendo uma taxa de transferência de rede com largura de banda suficiente. No entanto, se você não puder garantir uma boa largura de banda mesmo usando uma rede dedicada, a integridade da topologia do seu grupo de disponibilidade será prejudicada.
