Hoy vamos a hablar de otra solución de alta disponibilidad de SQL Server, las instancias de conmutación por error o FCI. Al igual que los Always On, las FCI necesitan de un clúster de Windows (WSFC) para funcionar. Realmente, pocos parecidos más vamos a encontrar entre las 2 soluciones pero, no adelantemos acontecimientos, veamos en detalle cómo funcionan las FCI y luego ya la comparación con Always On.
¿Qué son las FCI?
Como hemos podido ver, las FCI son una solución de alta disponibilidad de SQL Server basada en WSFC. En esta solución tendremos varios servidores nodos de un clúster. Estos nodos compartirán un almacenamiento compartido donde se almacenarán todos los datos de las bases de datos. El servicio de SQL solo estará en ejecución en el nodo principal del clúster pudiendo balancear a otro nodo (y parando en el principal) en caso de error de hardware, software o mantenimiento programado. Como habrás podido deducir, se trata, por tanto, de una solución de alta disponibilidad a nivel de instancia y no de base de datos como el resto de las que hemos visto.
Elementos de una FCI
Como hemos visto, las FCI se componen de un grupo de dos o más servidores que forman parte de un WSFC. A estos miembros del clúster se les conoce como nodos. Los nodos de una FCI pueden tener diferente hardware pero deben tener la misma configuración de software para garantizar el éxito en caso de balanceo del servicio. Además de esto, el clúster tiene que tener una serie de configuraciones que vamos a detallar.
Grupo de recursos
Nuestra FCI se ejecutará dentro de un grupo de recursos de WSFC. Cada nodo del clúster tendrá una copia actualizada de las configuraciones y claves de registro almacenadas en el grupo de recursos. Sin embargo, solo el nodo activo pertenece al grupo de recursos y en caso de balanceo (automático o manual) esta propiedad pasará a otro nodo. El número máximo de nodos admitidos en una FCI dependerá de la versión de SQL Server. Además un mismo WSFC puede tener varios grupos de recursos con varias FCI.
Almacenamiento
Como hemos visto, el almacenamiento de nuestra FCI debe ser compartido entre los nodos, esto lo podemos lograr con unidades SAN o recursos compartidos SMB. Además, desde Windows Server 2016, también se admite el espacio de almacenamiento directo (S2D). El almacenamiento, al ser común, es nuestro SPOF (Single Point Of Failure) y debemos extremar la precaución sobre él. Os recomiendo soluciones especializadas de almacenamiento con redundancia.
Instalación de SQL Server
Cada uno de los nodos del clúster tendrá instalado SQL Server de manera similar a una instalación independiente con la peculiaridad de que los servicios no se inician de manera automática, sino que es el WSFC quien levanta el servicio del nodo principal y detiene los del resto de nodos.
Red
Nuestro grupo de recursos tendrá un nombre de red virtual (VNN por sus siglas en inglés). Este VNN será el punto de acceso a nuestra instancia de SQL Server y estará asignado al nodo primario del clúster. En caso de balanceo se asignará al nuevo nodo primario.
Además, si tenemos una FCI distribuida en varias subredes, necesitaremos de direcciones IP virtuales para cada subred. En caso de balanceo, el WSFC apuntará nuestro VNN a la IP virtual de esa subred de manera que los clientes puedan seguir conectando a la instancia de forma transparente.
Ventajas de las FCI
En este punto no vamos a decir nada nuevo pero si vamos a remarcar lo que son las ventajas de esta solución de alta disponibilidad frente a otras:
– Alta disponibilidad: si el nodo activo falla, el nodo pasivo asume el rol de nodo activo automáticamente y continúa prestando el servicio sin interrupciones. El tiempo de conmutación por error depende de varios factores, pero suele ser muy corto (de segundos a minutos).
– Escalabilidad: se pueden añadir más nodos al clúster para aumentar la capacidad de procesamiento y el rendimiento. Además, se pueden crear varias FCI en el mismo clúster para distribuir la carga de trabajo.
– Facilidad de administración: se puede administrar la FCI como una única instancia de SQL Server, sin importar en qué nodo se esté ejecutando. También se puede usar el Administrador de clústeres de conmutación por error para gestionar el clúster y sus recursos.
– Compatibilidad: se puede usar una FCI con cualquier edición de SQL Server (desde la 2008 hasta la 2019) y con cualquier sistema operativo Windows Server que soporte clústeres de conmutación por error (desde el 2008 R2 hasta el 2019).
Inconvenientes de las FCI
Como ya hemos visto, el principal inconveniente de esta solución es el uso compartido del almacenamiento, lo que genera un SPOF que debe ser controlado por el equipo de storage. Si no hay disponibilidad del almacenamiento nuestras FCI no funcionarán. Esto puede no ser un problema tan grave con el estado actual de las instalaciones, donde el almacenamiento recae en cabinas de discos especializadas y, aunque tengamos distintas máquinas virtuales cada una con un almacenamiento, usan la misma base. Tenéis que valorarlo en cada caso.
Sin embargo, este no es el único inconveniente de esta solución, otro de los más graves puede ser el tiempo de balanceo que, puede ir desde varios segundos a minutos y puede no encajar en nuestro RTO. Este tiempo de respuesta es debido al uso compartido de discos y como SQL hace uso de ellos y de las páginas las caché de buffer. Entraremos en esto con más detalle en otro artículo pero tenéis que saber que el balanceo de una FCI puede tardar lo que el nodo tarde en escribir en disco una todas las páginas desfasadas. Desde SQL Server 2012 SQL permite usar puntos de comprobación indirectos (Indirect Checkpoints) para limitar el número de páginas desfasadas que se mantienen en la caché de buffer y mitigar este problema,
FCI VS Always On
Con lo que hemos visto hasta ahora podemos ya marcar las diferencias entre ambas soluciones de alta disponibilidad de SQL Server basadas en WSFC. La principal diferencia, para mi, sería el uso de almacenamiento compartido frente al almacenamiento individual redundado en cada nodo. Esto es, entre otras cosas, porque mientras las FCI son una solución de alta disponibilidad a nivel instancia, Always On lo es a nivel base de datos. Las FCI son más fáciles de administrar y nos permite tratar la instancia como una instalación individual corriendo en el nodo activo mientras que en Always On tendremos que actuar en cada uno de los servidores. Sin embargo, el tiempo de balanceo es mayor en una FCI.
Otro aspecto clave que puede hacernos decidir por una solución u otra es la accesibilidad de las réplicas secundarias. Mientras que en una FCI solo uno de los nodos tiene el servicio en ejecución, en un Always On tendremos disponible una réplica secundaria para operaciones de lectura y copias de seguridad. Sin embargo, el coste en una FCI puede ser mucho menor al no requerir de una edición enterprise. Con una edición standard podremos tener hasta 2 nodos de FCI. Para más de 2 nodos si que necesitaremos una edición enterprise.
Conclusión
Como hemos visto las FCI son una gran solución de alta disponibilidad a un coste relativamente accesible. Nos protegen frente a todo tipo de fallos excepto los de almacenamiento. Además, son mucho más fáciles de administrar cuando tenemos muchos objetos a nivel de servidor como jobs o logins. En un Always On tendríamos que duplicar el trabajo de mantener los objetos a nivel instancia.
Por si esto fuera poco, además, nos permiten tener varias FCI en un mismo WSFC para optimizar la carga de trabajo a la vez que protegemos nuestros servicios de caídas. Es una solución común tener varios servidores en un WSFC cada uno con una FCI activa pero que todos los nodos puedan asumir las instancias del resto en caso de fallo.
[…] FCI o Instancias de clúster de conmutación por error (HA Parte 3) […]