Configuración de una red dedicada para la comunicación del grupo de disponibilidad

Los grupos de disponibilidad AlwaysOn de SQL Server 2012 requieren un extremo de creación de reflejo de la base de datos para cada instancia de SQL Server que hospedará una réplica del grupo de disponibilidad o una sesión de creación de reflejo de la base de datos. Este punto de conexión de la instancia de SQL Server luego se comparte con una o más réplicas del grupo de disponibilidad o sesiones de creación de reflejo de la base de datos y es el mecanismo de comunicación entre la réplica principal y las réplicas secundarias asociadas.

Según las cargas de trabajo de modificación de datos en la réplica principal, los requisitos de rendimiento de mensajería del grupo de disponibilidad pueden no ser triviales. Esta actividad también es sensible al tráfico de la actividad del grupo de no disponibilidad concurrente. Si el rendimiento se ve afectado por el ancho de banda degradado y el tráfico simultáneo, puede considerar aislar el tráfico del grupo de disponibilidad en su propio adaptador de red dedicado para cada instancia de SQL Server que hospeda una réplica de disponibilidad. Esta publicación describirá este proceso y también describirá brevemente lo que podría esperar ver en un escenario de rendimiento degradado.

Para este artículo, estoy usando un clúster de conmutación por error de servidor de Windows (WSFC) invitado virtual de cinco nodos. Cada nodo del WSFC tiene su propia instancia de SQL Server independiente que usa almacenamiento local no compartido. Cada nodo también tiene un adaptador de red virtual independiente para la comunicación pública, un adaptador de red virtual para la comunicación WSFC y un adaptador de red virtual que dedicaremos a la comunicación del grupo de disponibilidad. A los efectos de esta publicación, nos centraremos en la información necesaria para los adaptadores de red dedicados del grupo de disponibilidad en cada nodo:

Configurar un grupo de disponibilidad usando una NIC dedicada es casi idéntico a un proceso de NIC compartido, solo que para "vincular" el grupo de disponibilidad a una NIC específica, primero tengo que designar la LISTENER_IP argumento en CREATE ENDPOINT comando, utilizando las direcciones IP antes mencionadas para mis NIC dedicadas. A continuación, se muestra la creación de cada punto de conexión en los cinco nodos de 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...

Después de crear estos extremos asociados con la NIC dedicada, el resto de mis pasos para configurar la topología del grupo de disponibilidad no son diferentes a los de un escenario de NIC compartida.

Después de crear mi grupo de disponibilidad, si empiezo a impulsar la carga de modificación de datos en las bases de datos de disponibilidad de la réplica principal, puedo ver rápidamente que el tráfico de comunicación del grupo de disponibilidad fluye en la NIC dedicada usando el Administrador de tareas en la pestaña de redes (la primera sección es el rendimiento para el NIC del grupo de disponibilidad dedicado):

Y también puedo realizar un seguimiento de las estadísticas utilizando varios contadores de rendimiento. En la siguiente imagen, Inetl[R] PRO_1000 MT Network Connection _2 es ​​mi NIC de grupo de disponibilidad dedicada y tiene la mayor parte del tráfico de NIC en comparación con las otras dos NIC:

Ahora, tener una NIC dedicada para el tráfico del grupo de disponibilidad puede ser una forma de aislar la actividad y, en teoría, mejorar el rendimiento, pero si su NIC dedicada no tiene suficiente ancho de banda, como es de esperar, el rendimiento se verá afectado y el estado de la topología del grupo de disponibilidad se degradará.

Por ejemplo, cambié el NIC del grupo de disponibilidad dedicado en la réplica principal a un ancho de banda de transferencia saliente de 28,8 Kbps para ver qué sucedía. No hace falta decir que no fue bueno. El rendimiento de la NIC del grupo de disponibilidad se redujo significativamente:

En unos segundos, el estado de las diversas réplicas se degradó y un par de ellas pasaron a un estado de "no sincronización":

Aumenté la NIC dedicada en la réplica principal a 64 Kbps y, después de unos segundos, también hubo un pico de recuperación inicial:

Si bien las cosas mejoraron, observé desconexiones periódicas y advertencias de salud en esta configuración de rendimiento de NIC inferior:

¿Qué pasa con las estadísticas de espera asociadas en la réplica principal?

Cuando había mucho ancho de banda en la NIC dedicada y todas las réplicas de disponibilidad estaban en buen estado, vi la siguiente distribución durante mis cargas de datos durante un período de 2 minutos:

HADR_WORK_QUEUE representa un subproceso de trabajador de fondo esperado que espera un nuevo trabajo. HADR_LOGCAPTURE_WAIT representa otra espera esperada para que los nuevos registros estén disponibles y, según Books Online, se espera si el análisis del registro se detecta o se lee desde el disco.

Cuando reduje el rendimiento de la NIC lo suficiente para que el grupo de disponibilidad tuviera un estado incorrecto, la distribución del tipo de espera fue la siguiente:

Ahora vemos un nuevo tipo de espera principal, HADR_NOTIFICATION_DEQUEUE . Este es uno de esos tipos de espera "solo para uso interno" según lo definido por Books Online, que representa una tarea en segundo plano que procesa las notificaciones de WSFC. Lo que es interesante es que este tipo de espera no apunta directamente a un problema y, sin embargo, las pruebas muestran que este tipo de espera se eleva a la cima en asociación con el rendimiento de mensajería del grupo de disponibilidad degradado.

Por lo tanto, el resultado final es que aislar la actividad de su grupo de disponibilidad en una NIC dedicada puede ser beneficioso si proporciona un rendimiento de red con suficiente ancho de banda. Sin embargo, si no puede garantizar un buen ancho de banda incluso utilizando una red dedicada, el estado de la topología de su grupo de disponibilidad se verá afectado.