¿Qué hacer cuando su clúster Always On pierde quórum?

Estaba revisando los procedimientos de DR de nuestra compañía y cuando busqué en línea soluciones para un quórum de pérdida de Always On Cluster, para comparar. Tenía tres páginas en los resultados de Google antes de encontrar la primera publicación de SE sobre el tema Agrupación frente a replicación transaccional frente a grupos de disponibilidad que solo toca ligeramente el tema del quórum perdido.

Si bien todos están de acuerdo en que el quórum perdedor es malo, y hay algunas sugerencias para disminuir el potencial, aún puede suceder. Estoy buscando una buena respuesta revisada por pares para el mejor camino hacia la recuperación de una pérdida de quórum de clúster Always On.

Los AG se basan en Windows Clustering. Se aplican los procedimientos de WSFC para pérdida de quórum.

• Recuperación ante desastres de WSFC mediante quórum forzado
• Forzar que un clúster de WSFC comience sin quórum

Una vez que se está ejecutando el WSFC, puede forzar AG, si es necesario. Realizar una conmutación por error manual forzada de un grupo de disponibilidad :

Después de forzar el quórum en el clúster WSFC (quórum forzado), debe forzar la conmutación por error de cada grupo de disponibilidad (con posible pérdida de datos). Se requiere forzar la conmutación por error porque el estado real de los valores del clúster WSFC podría haberse perdido. Sin embargo, puede evitar la pérdida de datos si puede forzar la conmutación por error en la instancia del servidor que alojaba la réplica que era la réplica principal antes de forzar el quórum o en una réplica secundaria que se sincronizó antes de forzar el quórum. Para obtener más información, consulte Posibles formas de evitar la pérdida de datos después de forzar el quórum .

¿Qué hacer cuando su clúster AlwaysOn pierde quórum?

He estado en esta situación, especialmente con la agrupación de varias subredes que abarca diferentes países (NY-LD-HK).

¿Cómo evitar la pérdida de quórum en un clúster de subredes múltiples?

• Cambie la configuración predeterminada del clúster a un estado de supervisión más relajado, especialmente la configuración de latido del clúster utilizando CrossSubnetDelay, o CrossSubnetThresholdpropiedad de esta revisión .
• AG usa WSFC que inturn usa un enfoque basado en quórum para determinar el estado del clúster. Asegúrese de elegir y configurar correctamente el quórum . Esta publicación de blog profundiza en la configuración de voto de quórum para AlwaysON

• Las cosas cambian en Windows Server 2016 con la introducción de clústeres conscientes del sitio y testigos de la nube .

  Los nodos en grupos extendidos ahora se pueden agrupar en función de su ubicación física (sitio). La conciencia del sitio del clúster mejora las operaciones clave durante el ciclo de vida del clúster, como el comportamiento de conmutación por error, las políticas de ubicación, los latidos entre los nodos y el comportamiento del quórum.

  Cloud Witness es un nuevo tipo de testigo de quórum de clúster de conmutación por error que aprovecha Microsoft Azure como punto de arbitraje. Utiliza Microsoft Azure Blob Storage para leer / escribir un archivo de blob que luego se usa como punto de arbitraje en caso de resolución de cerebro dividido.

¿Qué hacer cuando se pierde el quórum?

• Si el clúster se cae debido a una interrupción / desastre no planificado, se requiere intervención manual. Un administrador de Windows o un administrador de clúster tiene que forzar manualmente el quórum (vinculando de nuevo a la respuesta de @ Remus, ya que cubre este punto) y poner en línea los nodos supervivientes.

Como siempre, para hacer un análisis de causa raíz (RCA), reúna los registros del clúster de Windows, para AlwaysON RCA: use los registros de diagnóstico del clúster de conmutación por error de SQL Server . Estos archivos en el directorio de registro de SQL Server tienen el siguiente formato: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Una vez que estuve involucrado en una interrupción en la que nuestros servidores duplicados perdieron conectividad. Una de las cosas de las que debe preocuparse es asegurarse de que sus aplicaciones apunten a una sola instancia. En una interrupción de la red, puede tener todos los nodos de un clúster Always On activado, pero no puede comunicarse entre sí. Usted fuerza una conmutación por error a una secundaria y luego, mientras haya una interrupción, puede tener dos nodos primarios, ya que el primario original no sabrá sobre la conmutación por error forzada.

Dependiendo de la ubicación de sus servidores de aplicaciones, su configuración y su capacidad para llegar a un servidor SQL, entonces, en teoría, puede tener dos nodos creyendo que son primarios y que los datos cambian al mismo tiempo. Una vez que solucione los problemas de red y los nodos reanuden la conectividad, todos los datos modificados en el primario original se sobrescribirán desde el nodo donde se forzó la conmutación por error. Esto puede provocar la pérdida de datos críticos.

He visto esta situación una vez con SQL 2005 y la duplicación. Y decidimos no forzar el error y dejar que permanezca inalcanzable. La razón es que, en el peor de los casos, si tuviéramos que hacer una copia de seguridad y restaurar para reiniciar la duplicación, entonces sería un proceso de 2 días para nosotros con riesgos de que el registro de transacciones se llene y no pueda expandir el disco en el que se encontraba.