En este artículo vamos a hablar de dos configuraciones importantes para el funcionamiento óptimo de un grupo de disponibilidad AlwaysOn en SQL Server: el session timeout y el health check. Estas configuraciones nos permiten controlar cómo y cuándo se produce un balanceo (failover) automático entre los nodos del grupo, y cómo se determina el estado de salud de cada réplica. Si quieres saber más sobre qué es un AlwaysOn y cómo configurarlo, te recomendamos que leas nuestro artículo sobre ello aquí.
Consideraciones de salud de nuestro AlwaysOn
SQL Server pone a nuestra disposición distintas configuraciones sobre el balanceo de nuestro AlwaysOn. Por un lado podemos definir el tiempo que una transacción puede tardar en replicarse antes de considerar que hay un problema con esa réplica y por otro podremos definir el tiempo que tiene que pasar una réplica en un estado crítico para sacarla del grupo de disponibilidad y balancear o detener la replicación. Además podremos definir varios niveles de criticidad admisibles para considerar este escenario.
¿Qué es el session timeout de AlwaysOn?
El session timeout o tiempo de espera de sesión es el tiempo máximo que una sesión puede estar inactiva antes de que nuestro AlwaysOn determine que esa réplica no está accesible. Esto puede ocurrir cuando hay una interrupción en la comunicación entre el cliente y el servidor, o cuando el servidor está muy ocupado y no puede atender las solicitudes del cliente. Esta propiedad se define por cada réplica y representa el tiempo que puede esperar un ping entre ella misma y el nodo principal del clúster.
El valor por defecto del session timeout para un AlwaysOn es de 10 segundos, pero se puede modificar mediante la propiedad “Connection Timeout” de la cadena de conexión, o mediante la propiedad “SessionTimeout” del grupo de disponibilidad (Availability Group) en PowerShell. El valor mínimo es de 5 segundos, y el máximo es de 65535 segundos. Microsoft no recomienda un tiempo inferior a 10 segundos ya que podríamos sufrir falsos positivos cuando un sistema saturado no devuelva el ping a tiempo. Por otra parte, un tiempo muy alto puede provocarnos errores de inconsistencia de datos ya que aunque la réplica secundaria no esté respondiendo, si estamos dentro de ese umbral definido, SQL no va a actuar como si hubiera un error y va a seguir intentando insertar datos.
¿Qué es el health check de AlwaysOn?
El health check es el proceso por el cual el WSFC comprueba el estado de salud de cada réplica del grupo de disponibilidad. El health check se basa en una serie de criterios que evalúan el rendimiento y la disponibilidad de cada réplica, tales como:
- El tiempo de respuesta del servidor
- El tiempo de recuperación de la base de datos
- El número de errores graves
- El tamaño del registro de transacciones
- El tiempo de sincronización entre las réplicas
Cada criterio tiene un umbral asociado que determina si la réplica está en un estado saludable, advertencia o crítico. Si una réplica primaria pasa a un estado crítico, se produce un failover automático a la réplica secundaria con mayor prioridad. Si una réplica secundaria pasa a un estado crítico, se excluye del grupo de disponibilidad hasta que se recupere.
Mecanismo Is-Alive
Por defecto se hará un chequeo de la salud de las réplicas cada 5 segundos. Sin embargo, el health check tiene un timeout de 15 segundos por defecto. Esto es porque durante ese tiempo se realizan 3 comprobaciones y si no se obtiene una respuesta positiva antes de 3 erróneas se considera a esa réplica en estado crítico. Nosotros, podremos modificar el tiempo máximo de timeout mediante la propiedad “HealthCheckTimeout” del grupo de disponibilidad (Availability Group) en PowerShell. El valor mínimo es de 3 segundos, y el máximo es de 9999 segundos. Durante este tiempo se harán varios chequeos de salud de las réplicas y solo se notificará el error si no se recupera antes del tiempo de espera establecido.
Niveles de error admisibles
Como hemos comentado al principio, WSFC contempla hasta 5 niveles de error que podemos configurar siendo uno el más permisivo y 5 el más “paranoico”. En nuestro caso, nuestro AlwaysOn solo considerará una réplica en fallo si cumple con los criterios del nivel establecido o los de los niveles anteriores.
- OnServerDown: El nivel uno de error solo considera una réplica en fallo en caso de caída del sistema operativo. No se comprueba nada más.
- OnServerUnresponsive: Este segundo nivel, considera un estado crítico en caso de que no se produzca una respuesta al procedimiento de chequeo de salud sp_server_diagnostics.
- OnCriticalServerError: Este tercer nivel es el por defecto cuando creamos un clúster y considera un estado crítico, además de los dos anteriores, si uno de los componentes del servidor está reportando un error. Por ejemplo un error de sector defectuoso en un disco.
- OnModerateServerError: Este nivel considera una réplica en estado crítico si uno de los componentes de registro del servidor tiene un error. Por ejemplo varios DUMP de memoria consecutivos.
- OnAnyQualifiedFailureConitions: Este es el nivel más paranoico y considera una réplica en estado crítico ante cualquier error de SQL Server como podría ser un deadlock.
Conclusión
En este artículo hemos visto qué son el session timeout y el health check, y cómo influyen en el comportamiento de un grupo de disponibilidad AlwaysOn en SQL Server. Hemos aprendido cómo modificar estas configuraciones según nuestras necesidades, y cómo afectan al failover automático y a la continuidad del servicio. Esperamos que te haya resultado útil e interesante, y te invitamos a que nos sigas leyendo en nuestro blog www.soydba.es, donde encontrarás más artículos sobre SQL Server y otros temas relacionados con la administración de bases de datos.
Espero que este artículo te haya sido útil. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
