Microsoft SQL Server Clustering es el término utilizado para describir una colección de dos o más servidores físicos (nodos), conectados a través de una LAN, cada uno de los cuales aloja una instancia de servidor SQL y tiene el mismo acceso al almacenamiento compartido. La agrupación de servidores SQL proporciona alta disponibilidad y protección contra desastres cada vez que falla un servidor que aloja la instancia de SQL Server.
Si está en un servidor independiente, una falla de hardware puede detener sus operaciones. Sin embargo, con la agrupación en clústeres, si un nodo tiene problemas, puede conmutar por error automáticamente a otro nodo, con un tiempo de inactividad mínimo, y permitir que los usuarios sigan trabajando mientras TI trabaja para resolver el problema. Cuando el servidor principal está reparado, puede revertir rápidamente las operaciones.
En comparación con el uso de un servidor independiente, la agrupación en clústeres de SQL Server también puede limitar el tiempo de inactividad al aplicar actualizaciones y parches de seguridad.
Si bien la agrupación en clústeres de SQL Server proporciona alta disponibilidad y minimiza el tiempo de inactividad del sistema, la agrupación en clústeres de SQL Server no mejorará el rendimiento de los servidores o las aplicaciones. Para mejorar el rendimiento, debe actualizar la potencia informática de los servidores.
¿Qué son los clusters?
Un clúster de Microsoft SQL Server no es más que una colección de dos o más servidores físicos con acceso idéntico al almacenamiento compartido que proporciona los recursos de disco necesarios para almacenar los archivos de la base de datos.
Estos servidores se denominan «nodos». Cada uno de los nodos se comunica entre sí a través de una red privada, enviando una señal de latido entre ellos. Si un nodo no comunica su latido al otro nodo en el clúster, el nodo secundario se hará cargo de cualquier servicio dependiente que esté ejecutando el nodo que perdió la comunicación. Este proceso se conoce como «conmutación por error».
Una conmutación por error puede ocurrir de forma automática (el latido de un servidor deja de comunicarse) o manualmente. Una conmutación por error manual es beneficiosa en el caso de que se requieran parches o alguna otra forma de mantenimiento en el nivel del servidor físico.
Por lo general, implementaría la agrupación en clústeres para garantizar que, si alguna vez encuentra una falla de hardware en el servidor físico que aloja su instancia de SQL, sus bases de datos seguirán estando disponibles para las aplicaciones dependientes y sus usuarios.
A diferencia de otras tecnologías de agrupación en clústeres que se implementan para mejorar el rendimiento o aumentar la potencia de procesamiento a través del equilibrio de carga, los clústeres de SQL están diseñados para proporcionar bases de datos de alta disponibilidad; eliminando el tiempo de inactividad asociado con fallas de hardware.
Este concepto arquitectónico se conoce como «Clustering de alta disponibilidad» o «Clustering HA» para abreviar. El servicio o los grupos de servicios alojados en un nodo en clúster se denominan, respectivamente, recursos y grupos de recursos. Dado que estos recursos deben estar disponibles para todos los nodos de un clúster, deben residir en una matriz de discos compartidos en forma de disco SAN-NAS. Cada grupo de recursos se asignará a una unidad lógica alojada físicamente en la matriz de discos compartidos y también tendrá su propia dirección IP y nombre de red asociados.
¿Cómo es el proceso de instalación?
El proceso de instalación de SQL Server detecta cuándo se intenta realizar una instalación en un nodo agrupado y le preguntará si desea configurar la instancia de SQL como agrupada o no. Si continúa con la creación de una instancia en clúster de SQL Server, la instancia se hospedará en un servidor «virtual». Los recursos, como los datos y los archivos de registro, se crearán en el disco SAN-NAS compartido para SQL Server, el Agente SQL Server y la indexación de texto completo.
Si se selecciona en el proceso de instalación, Notification Services y Analysis Services también son compatibles con clústeres en SQL Server 2005. Por el contrario, los archivos de programa asociados para la instancia se instalarán en las unidades locales de cada uno de los nodos en clúster de forma y registro idénticos. los valores se establecen de forma idéntica en todos los nodos agrupados.
Dado que el servidor «virtual» reside únicamente en la SAN, puede ser «propiedad» de cualquiera de los nodos que permita. Cada uno de los nodos puede ejecutar estos recursos de manera idéntica porque cada nodo/servidor físico tiene los archivos de programa y la configuración de registro idéntica necesaria para ejecutar la instancia de SQL.
Además, los usuarios ignoran la fluidez subyacente del servidor. Se conectan a él como lo harían con cualquier otro servidor físico: por nombre de servidor (nombre de servidor virtual en este caso) si es la instancia predeterminada o por nombre de servidor virtual\nombre de instancia si es una instancia con nombre.
Esta es la clave para la conectividad de la aplicación. Dado que la instancia de SQL simplemente cambia de propiedad durante una conmutación por error, no es necesario volver a codificar las cadenas de conexión en las que se basan las aplicaciones para conectarse a sus bases de datos; el servidor físico puede dejar de estar disponible, pero el servidor virtual persiste después de la conmutación por error.
¿Cómo se denominan a los clusters?
Los clústeres a menudo se denominan Activo/Activo o Activo/Pasivo. Tal como cabría esperar por el nombre, en un clúster Activo/Activo habrá dos o más nodos, cada uno con una instancia de Microsoft SQL Server. Si un nodo falla, la instancia que posee se conmutaría por error al otro nodo, corriendo junto a la otra instancia (y compitiendo por los recursos).
Una arquitectura Activa/Pasiva requiere que, sin importar cuántos nodos compongan el clúster, al menos un nodo no sea propietario de una instancia de SQL Server. Es «pasivo» y solo existe para aceptar una conmutación por error de un nodo que aloja una instancia de SQL en caso de una conmutación por error.
Las políticas actuales de licencias de Microsoft requieren que solo obtenga una licencia para los nodos activos que ejecutan Microsoft SQL Server. El nodo pasivo no necesita licencia.
¿Qué son los nodos? ¿Cuántos se necesitan?
La tecnología actual de agrupación en clústeres de Windows 2003 y Microsoft SQL Server 2005 Enterprise Edition permite combinar hasta ocho nodos en un solo clúster. El lanzamiento de Windows 2008 y Microsoft SQL Server 2008 Enterprise Edition traerá consigo la capacidad de duplicar eso a dieciséis nodos. (Está limitado a dos nodos si utiliza SQL Server Standard Edition).
Finalmente, ¿convienen o no los clusters?
Si bien la agrupación en clústeres lo protege de fallas de hardware relacionadas con el servidor que aloja la instancia de SQL Server, no lo protege de fallas de medios. A diferencia de la replicación, la creación de reflejo de la base de datos o el trasvase de registros, solo hay una única copia de su base de datos. Si el SAN-NAS encuentra una falla, no solo podría incurrir en tiempo de inactividad, sino también en la pérdida de datos.
Se recomienda que incorpore la redundancia de su SAN-NAS o la creación de reflejo de la base de datos con su configuración de agrupamiento para protegerlo de fallas en los medios. Los costos de hardware y licencias pueden ser altos.
En un modelo de agrupación en clúster activo/pasivo, comprará hardware que espera no tener que usar nunca. La construcción del clúster es más compleja que la configuración de un servidor independiente. Sin embargo, la construcción física del clúster está fuera del alcance de esta discusión.
Otras soluciones de server clusters
Hay otras soluciones de agrupación en clústeres de SQL Server disponibles en el mercado. Algunas de las soluciones de agrupación en clústeres de SQL Server más populares son ofrecidas por Microsoft e incluyen:
- Grupos de disponibilidad básicos de SQL Server
- Grupos de disponibilidad siempre activos de SQL Server
- Instancias de clúster de conmutación por error de SQL Server con almacenamiento compartido
Los grupos de disponibilidad básicos de SQL Server se ejecutan en Windows y admiten un máximo de un clúster de dos nodos. Funciona como una solución de espejo de base de datos. Si bien la agrupación en clústeres y la duplicación son métodos para mejorar la alta disponibilidad, la duplicación solo permite la conmutación por error de la base de datos.
Si tiene otros servicios, archivos y otros recursos fuera de SQL que necesita después de una conmutación por error, o si tiene varias bases de datos que deben permanecer juntas, la agrupación en clústeres es la mejor solución.
SQL Server Always On Availability Groups se ejecuta tanto en Windows como en Linux y, según Microsoft, «proporciona una alternativa de nivel empresarial a la creación de reflejo de la base de datos». Requiere la costosa SQL Server Enterprise Edition.
Puede ahorrar hasta un 70 por ciento en los costos de licencias de software y obtener funciones de agrupación en clústeres de clase empresarial mediante el uso de SQL Server Standard Edition.
Las instancias de clúster de conmutación por error de SQL Server con almacenamiento compartido se ejecutan en Windows y Linux. Es una solución de sitio único y requiere una SAN. Desafortunadamente, las SAN son costosas de comprar y mantener, requieren experiencia administrativa en SAN y son un único punto de falla. Una SAN también puede afectar negativamente el rendimiento de la base de datos.
