Los grupos de disponibilidad AlwaysOn de SQL Server son la última tecnología de Microsoft para abordar las necesidades de alta disponibilidad y recuperación ante desastres de las organizaciones que utilizan SQL Server. Una gran ventaja de AlwaysOn es la capacidad de abordar HA y DR en una sola implementación. Los beneficios clave de AlwaysOn que hemos experimentado son los siguientes:
Podemos agrupar bases de datos relacionadas como parte de un solo grupo de disponibilidad y hacer que se recuperen juntas en caso de tal necesidad. Esto es especialmente útil para aplicaciones que dependen de más de una base de datos, como Microsoft Office SharePoint, Microsoft Lync o Sage.
En comparación con las instancias de clúster de conmutación por error de SQL Server, encontramos que se ha eliminado el almacenamiento como único punto de falla, ya que cada instancia que constituye una réplica tiene asignado su propio almacenamiento.
Con AlwaysOn, es posible configurar HA y DR al mismo tiempo. Esto se logra mediante la creación de clústeres de conmutación por error de Windows de varios sitios como base de su configuración de AlwaysOn. Realizar un cambio de rol cuando se usa AlwaysOn es significativamente más simple que hacerlo cuando se usa el envío de registros de transacciones.
La dependencia de WSFC
Al usar SQL Server AlwaysOn AG para alta disponibilidad y recuperación ante desastres, primero debe configurar un clúster de conmutación por error de Windows. Los AG de AlwaysOn dependen de WFCS para administrar el AG de AlwaysOn como una función que se compone de recursos de clúster como el nombre del grupo de disponibilidad, el nombre del recurso compartido de archivos, el nombre del agente de escucha y una dirección IP.
Fig. 1 AlwaysOn AG como recurso de clúster
Quórum
Quórum es el número mínimo de votos necesarios para obtener una mayoría en un clúster de conmutación por error. El quórum determina cuántos errores de nodo puede soportar el clúster. A través de la red privada en el puerto 3343, todos los nodos del clúster comunican el estado de salud y la información de supervisión de recursos. En caso de falla, los votos muestran qué nodos tienen el estado "Activo" y en qué nodos deben conectarse los recursos.
Desde Windows Server 2012, la cantidad máxima de nodos de clúster admitidos es dieciséis. Sin embargo, en la mayoría de los entornos con los que estoy familiarizado, los clústeres de dos nodos son comunes. Un clúster de dos nodos plantea un pequeño problema en términos de lograr el quórum, ya que cada nodo tiene un voto y si hay un problema con la comunicación entre los dos, cada uno puede asumir que el otro no está en buen estado. Esto se llama un escenario de cerebro dividido. Los escenarios de cerebro dividido son la razón para configurar un desempate, como un disco o un archivo compartido.
Si tiene un número impar de nodos, no es necesario configurar un desempate. La configuración de quórum dinámico y el testigo dinámico se introdujeron en Windows Server 2012 y Windows Server 2012 R2, respectivamente. Con la ayuda de estas tecnologías, Windows redistribuye automáticamente los votos en un clúster para que la cantidad de nodos en un clúster no importe al establecer un Quórum. El voto de un nodo de clúster se elimina configurando la propiedad de clúster "NodeWeight" en 0. Estas funciones están habilitadas de forma predeterminada.
Fig. 2 Obtener todas las propiedades del clúster mediante PowerShell
Fig. 3 votos asignados en un clúster de dos nodos
Uso de PowerShell
El comando Get-Cluster de PowerShell se puede usar para verificar la configuración de quórum en un clúster de Windows. La Fig. 4 muestra cómo comprobar todas las propiedades del clúster relacionadas con el quórum en un clúster y la Fig. 5 muestra las propiedades del Testigo de recursos compartidos de archivos. Hay muchos otros comandos de PowerShell para verificar y administrar clústeres de Windows.
Get-Cluster | Format-List –Property *Quorum*
Fig. 4 Comando de PowerShell para comprobar las propiedades relacionadas con el quórum
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Fig. 5 Comando de PowerShell para comprobar los detalles de las propiedades del testigo del recurso compartido de archivos
Modos de quórum
El clúster de conmutación por error de Windows Server permite configurar hasta cuatro modos. Los modos de quórum son esencialmente opciones que elige para determinar cómo el clúster manejará las fallas de los nodos.
1. Mayoría de nodos
Este modo de quórum puede soportar fallas de hasta (n/2)-1 nodos. Se recomienda para clústeres con un número impar de nodos. Por ejemplo, en un clúster de cinco nodos, se necesitaría una falla en dos nodos para provocar una falla en el clúster.
2. Mayoría de nodos y discos
Puede soportar fallas de hasta la mitad de la cantidad de nodos del clúster siempre que el disco testigo (también llamado disco de quórum) permanezca en línea.
3. Mayoría de recursos compartidos de archivos y nodos
Este modo de quórum puede admitir fallas de hasta la mitad de la cantidad de nodos del clúster, siempre que el recurso compartido de archivos permanezca accesible. A partir de Windows Server 2012 R2, Microsoft recomienda que siempre se configure un testigo (disco o recurso compartido de archivos) al crear un clúster.
4. Sin Mayoría
Este es un modo de solo disco. Este modo puede admitir fallas en todos los nodos, excepto en uno, siempre que el disco esté en línea. No se recomienda este modo ya que el disco se convierte en un único punto de falla.
Sugerencias para configurar la mayoría de recursos compartidos de archivos y nodos
Los grupos de disponibilidad AlwaysOn solo admiten dos de esos modos de quórum:mayoría de nodos y mayoría de recursos compartidos de archivos y nodos. Al crear un clúster de grupo de disponibilidad AlwaysOn de SQL Server, hay algunos puntos que el DBA debe tener en cuenta:
1. Uso de servidores físicos
Al configurar un clúster de dos nodos para AlwaysOn, sus nodos deben residir en diferentes bastidores físicos. El servidor que aloja su recurso compartido de archivos debe residir en un tercer bastidor.
2. Uso de servidores virtuales
Al configurar un clúster de dos nodos para AlwaysOn, sus máquinas virtuales deben residir en hosts separados. La máquina virtual que aloja su recurso compartido de archivos debe residir en un tercer host.
3. Agrupación en clústeres de varios sitios
Al configurar un clúster de varios nodos para AlwaysOn en todos los centros de datos, en un escenario ideal, el servidor de archivos que aloja su recurso compartido de archivos debe residir en un tercer centro de datos.
4. Permisos para compartir archivos
El objeto de nombre de clúster debe tener permisos en el recurso compartido de archivos utilizado como testigo de quórum. Sin esto, normalmente experimentaría errores al intentar configurar Quorum Witness.
Fig. 6 Permisos para compartir archivos
5. Configuración en línea
Los modos de quórum se pueden configurar mientras el clúster está en línea. Por lo tanto, en caso de que el servidor de archivos compartidos falle o deba volver a configurarse, asegúrese de reconfigurarlo rápidamente para garantizar que no haya fallas inesperadas, especialmente en un clúster de dos nodos.
Un caso de uso real
El diagrama de la Fig. 7 muestra un clúster AG AlwaysOn multisitio real. Es un clúster de cuatro nodos con dos nodos en un sitio y otros dos en un sitio DR remoto. El servidor de archivos que aloja el recurso compartido de archivos que se utiliza como desempate se aloja en un tercer centro de datos. En el presente caso, el servidor de archivos reside en la misma ciudad que el centro de datos principal, pero si puede permitírselo, sería ideal tener el servidor de archivos en otra ciudad. La comunicación entre las tres partes debe ser de buena calidad para evitar falsos positivos.
Por ejemplo, en nuestra implementación inicial de este clúster, usamos "Replicación síncrona con conmutación por error automática" en los sitios Live y DR. En más de una ocasión experimentamos una falla en la comunicación que desencadenó una conmutación por error automática al sitio DR y expuso una falla en nuestra configuración. Esto hizo que el nombre del Listener se resolviera en las direcciones IP asociadas en el sitio DR y los clientes ya no podían conectarse porque la comunicación con esta nueva dirección IP no estaba permitida en los firewalls de la red. Simplemente volvimos al sitio principal para mitigar el problema y cambiamos la configuración a "Replicación asincrónica con conmutación por error manual" para los nodos que residen en los centros de datos. Planeamos cubrir el aspecto de la resolución de nombres en nuestro próximo artículo "AlwaysOn".
Fig. 7 Un caso de uso real
Conclusión
La función de grupos de disponibilidad AlwaysOn se introdujo en SQL Server 2012 y es la última tecnología de Microsoft para abordar las necesidades de alta disponibilidad y recuperación ante desastres. La configuración de los grupos de disponibilidad AlwaysOn depende en gran medida del servicio de clúster de conmutación por error de Windows. Los clústeres de conmutación por error, a su vez, dependen mucho de la configuración correcta del quórum. Al crear AlwaysOn en clústeres de sitios múltiples, la latencia entre sus nodos en los diferentes sitios y el recurso compartido de archivos utilizado como árbitro es realmente importante. Asegúrese de que su configuración de quórum esté siempre en óptimas condiciones para evitar comportamientos inesperados con los grupos de disponibilidad.
Referencias
Descripción general de los grupos de disponibilidad AlwaysOn
Clústeres de conmutación por error de Windows con SQL Server
Documentación de PowerShell
Comprensión del quórum del clúster de conmutación por error de Windows Server
