SQL Server

Los mejores consejos para el clúster de SQL Server

Tom Moreau

Resumen:

• Ejecución de SQL Server en un clúster
• Requisitos de hardware y software
• Clúster de un nodo
• Opciones de alta rentabilidad

Un clúster de servidor permite conectar varios servidores físicos, o nodos, que funcionan como asociados de conmutación por error entre sí. La redundancia que proporciona un clúster se traduce en más tiempo productivo para sus operaciones

críticas. He implementado un buen número de clústeres en mis 13 años de trabajo con SQL Server™ y cada uno de ellos presentó un grupo de problemas único. Esta experiencia me ha permitido recopilar varias sugerencias que pueden ayudarle a que sus esfuerzos por usar el clúster sean más sencillos y eficaces.

Los clústeres de servidor aprovechan las capacidades integradas de clúster de Enterprise Edition de la familia Windows Server®. De hecho, con fines de implementación de clústeres, Windows Server 2003 es con diferencia mejor que Windows 2000 Advanced Server. Para maximizar las prestaciones que obtendrá de los clústeres, necesitará el hardware adecuado y, para ello, tendrá que realizar algunos gastos. No basta con añadir un par de servidores con un disco compartido y no puede depender del hecho de que algunos componentes individuales aparezcan o no en Windows® Catalog (anteriormente conocido como Lista de compatibilidad de hardware). Todo el sistema en su conjunto debe aparecer en Windows Catalog. Pero no se preocupe, existen algunas soluciones de clúster rentables y aprobadas. En la figura 1 se muestra una configuración típica de clúster.

Figura 1** Un clúster típico **(Hacer clic en la imagen para ampliarla)

Por supuesto, el hardware no constituye la única consideración que debe tener en cuenta en sus cavilaciones sobre el clúster; además, también necesita elegir la edición correcta de SQL Server 2005. La edición Enterprise Edition permite el uso de clústeres y presenta otras características útiles, como la capacidad de aprovechar más las CPU, las vistas particionadas actualizables y distribuidas, el trasvase de registros integrado y el uso automático de vistas indizadas. Si ya dispone de una licencia de Enterprise Edition, considere el clúster, tenga o no los servidores necesarios (entre dos y ocho) para crear un clúster tradicional (en breve hablaremos de los clústeres de un nodo). Si dispone de SQL Server 2005 Standard Edition, puede instalar un clúster de dos nodos.

Las ediciones Windows Server 2003 Enterprise y Datacenter se suministran con el clúster integrado. Lo único que tiene que hacer es ejecutar el Administrador de clústeres para configurarlo. Puede añadir todos los nodos al mismo tiempo o de uno en uno. De forma parecida, cuando instale SQL Server, podrá elegir si desea instalar un servidor no agrupado individual o una instancia virtual en un clúster. Si elige instalar una instancia virtual, podrá instalar en todos los nodos del clúster, sólo en algunos o incluso en uno solo.

Finalmente, para alcanzar el objetivo real de alta disponibilidad de clústeres, necesita contar con personas cualificadas y con unos procedimientos muy ensayados por si surgen problemas. Aunque el clúster ofrece una buena garantía ante los errores de hardware, no puede impedir los errores de usuario, como los que pudiera causar un administrador de base de datos muerto de sueño en mitad de la noche.

Clústeres de un nodo

Aunque lo único que necesite por el momento sea un único servidor, considere la creación de un clúster de un nodo. Esto le permitirá actualizar a un clúster más adelante sin tener que volver a crearlo. Sólo tiene que asegurarse de que el hardware que elige se encuentra en la sección de clúster de Windows Catalog.

La decisión de añadir un nodo más adelante no tiene que deberse exclusivamente a motivos de alta disponibilidad. Piense en lo que puede ocurrir si descubre que su servidor no tiene la capacidad necesaria. Esto se traduce en una migración, un proceso que conlleva tiempo y esfuerzo. Si tiene un clúster de un nodo, la migración es más fácil con un tiempo de inactividad mucho menor. Agregue el nodo nuevo al clúster, agregue los binarios y los Service Packs de SQL Server al nodo nuevo y, a continuación, lleve a cabo una conmutación por error en el nodo nuevo. Seguidamente, agregue cualquier actualización posterior a los Service Packs y, por último, expulse el nodo antiguo. El tiempo de inactividad comprende únicamente el tiempo que se tarda en llevar a cabo la conmutación por error y agregar las actualizaciones (si las hay).

Adición de nodos

Puesto que todos los nodos de un clúster deben ser idénticos, querrá actuar cuanto antes para conseguir este nodo extra, en lugar de dejarlo para más tarde. Si espera demasiado tiempo, el nodo podría dejar de fabricarse. En un proyecto, tuve que reconstruir un nodo en un clúster de SQL Server 2000. Hice que la administración de red/SO se encargara de la compilación básica del equipo y, a continuación, intervine para volver a añadirla al clúster y prepararla para su funcionamiento como nodo de SQL Server. Todo fue bien, hasta que realicé una conmutación por error en el nodo nuevo. Muy a mi pesar, dio errores enseguida. En resumen, aunque había preparado un documento detallado sobre la creación de un clúster nuevo, incluida la adición de las cuentas de servicio de clúster y de servicio de SQL Server a ambos nodos, el documento no se había seguido de forma explícita. El equipo de administración no agregó estas cuentas de servicio al nodo reconstruido, por lo que ya no existían los privilegios que tenían antes de la reconstrucción.

Tardé bastante tiempo en localizar este error. Un día se me ocurrió mirar en la pertenencia a grupos local. En cuanto agregué las dos cuentas, la conmutación por error se llevó a cabo sin problemas. Entonces llegué a una conclusión. La reconstrucción de un nodo es algo que no se hace a menudo y, cuando se hace, suele ser por una emergencia. Aunque había confeccionado un documento, no se utilizó. Podríamos haber automatizado la parte de seguridad al escribir sencillamente una secuencia de comandos breve que agregara estas dos cuentas y que realizara otras personalizaciones necesarias. No obstante, las cosas han mejorado en SQL Server 2005. El instalador requiere que se establezcan los grupos de nivel de dominio para las cuentas de servicio de SQL Server.

Por supuesto, esto me hizo reflexionar de nuevo. Se pueden crear secuencias de comandos que invoquen CLUSTER.EXE para agregar el nodo a su clúster Microsoft ® Cluster Server (MSCS). Lo único que tiene que hacer es incluir el nombre del nodo en la secuencia de comandos y esta se encargará del resto. En una emergencia, la automatización es su mejor aliado.

Clústeres N + 1

A veces, el motivo de agregar un nodo a un clúster no es la sustitución de un nodo. Es posible que quiera agregar más instancias de SQL Server al clúster y cada una de ellas necesitará recursos de disco independientes. Aunque es posible ejecutar varias instancias en un solo nodo, todas compartirán la CPU y la RAM, y eso podría dar lugar a un rendimiento pobre. La situación ideal es que en cada nodo se ejecute únicamente una instancia. ¿Cómo se puede garantizar esto al realizar la conmutación por error? Es sencillo: la respuesta es que un nodo no contiene servicios en ejecución, mientras que cada uno del resto de los nodos ejecuta una instancia de SQL Server. En realidad, esa es la definición de un clúster N + 1: N instancias que se ejecutan en N + 1 nodos. El nodo extra es la copia de seguridad.

Actualización de SQL Server

La actualización de una instancia en clúster de SQL Server no está pensada para corazones débiles. Está en clúster por un motivo: necesita tiempo de actividad. No obstante, SQL Server 2005 ofrece varias mejoras que podrá utilizar para continuar con el proceso de actualización sin demasiado tiempo de inactividad.

¿Qué opciones tiene? Examinemos en primer lugar la solución más costosa: la creación de un clúster completamente nuevo, lo que implica servidores nuevos y, quizás, una red de área de almacenamiento (SAN) también nueva. Lo más probable es que pueda utilizar los conmutadores existentes de la red, pero eso es todo. Obviamente, este enfoque no resulta barato pero tiene sus ventajas. El nuevo hardware ofrece normalmente un rendimiento mucho mejor que el antiguo, gracias al aumento constante de la capacidad de disco y la velocidad. De esta forma, sólo con el hardware nuevo conseguirá un aumento considerable del rendimiento. Incluso puede que quiera alquilar su equipo para que siempre esté a la última.

Una vez que tenga el hardware necesario, podrá crear su nuevo SQL Server virtual en esta instalación, copiar sus bases de datos de producción y, a continuación, ejercitar el sistema nuevo, dejando el tiempo suficiente para eliminar los errores antes del momento del traslado. Sólo tiene que asegurarse de incluir en secuencias de comandos los inicios de sesión del servidor existente. Consulte support.microsoft.com/kb/246133. Otra buena idea es actualizar su secuencia de comandos de compilación de inicio de sesión, en caso de que se produzcan errores muy graves.

Para minimizar el tiempo de inactividad, lo más probable es que tenga que utilizar el trasvase de registros, a menos que sus bases de datos sean muy pequeñas y disponga de un período de tiempo en el que no hay usuarios conectados. Puede trasvasar los registros hasta justo antes del traslado. A continuación, expulse a los usuarios, corte y trasvase el registro final y, por último, haga que la aplicación señale a la nueva instancia. Revise la sección siguiente sobre la creación de reflejos de bases de datos para descubrir una alternativa interesante al trasvase de registros. Si utiliza alias DNS, probablemente no le haga falta que las aplicaciones señalen a la nueva instancia. En su lugar, solo tendrá que actualizar el alias DNS. Este enfoque tiene la ventaja de que si ya ha realizado parte de la migración y tiene que volver al original, al menos dispondrá del original.

Puede tomar una ruta menos costosa, pero que requiere más planeación por adelantado. Un clúster puede admitir más de una instancia de SQL Server, pero cada instancia debe tener sus propios recursos de disco. De modo que cuando esté destripando su SAN, reserve un LUN para una actualización futura. Para realizar la actualización, instale los binarios de SQL Server en este recurso de disco. Puede ejercitar el sistema y, cuando esté preparado, apague el SQL Server actual, traslade los recursos de disco del antiguo grupo SQL Server, actualice las dependencias y ponga en línea la instancia nueva de SQL Server. Adjunte las bases de datos de la instancia antigua, y ya está. Ha realizado copias de seguridad de todo por adelantado, ¿verdad?

Este enfoque es el menos costoso y conlleva cierto riesgo. Si algo sale mal, no podrá separar las bases de datos de la instancia nueva y volverlas a colocar. Sólo podrá restaurarlas a partir de copias de seguridad, y esto puede implicar un tiempo de inactividad considerable.

Una alternativa es colocar dos instancias de SQL Server en su SAN, siempre que tenga espacio suficiente. Restaure las copias de seguridad de producción (y el trasvase de registros) en la nueva instancia, y continúe con el procedimiento que he descrito anteriormente. Sin embargo, ahora dispone de un comodín. Cuando termine la migración, podrá liberar los recursos de SAN de la instancia antigua. El costo será únicamente el precio de los discos adicionales.

Equilibrio de carga

Empecemos por desacreditar un concepto erróneo muy común. Los clústeres de MSCS se utilizan para obtener una disponibilidad alta, pero no para equilibrar la carga. Además, SQL Server no incluye ninguna capacidad automática de equilibrio de carga. Tendrá que equilibrar la carga mediante el diseño físico de la aplicación. ¿Qué significa eso?

Cuando una tabla aumenta de tamaño, es lógico esperar que se produzca cierta reducción en el rendimiento, especialmente cuando se llevan a cabo búsquedas en ella. Cuando alcanza los millones o los miles de millones de filas, la solución tradicional ha sido utilizar vistas particionadas, que se confeccionan a partir de tablas con esquemas idénticos agrupadas mediante UNION ALL. Además, se emplean restricciones CHECK para diferenciar las tablas miembro y, de esta forma, se evita la duplicación de datos en la vista particionada. Si la columna que se utiliza en la restricción CHECK forma también parte de la clave principal, la vista podrá actualizarse.

Si las tablas miembro se encuentran en sus propios grupos de archivos, puede que obtenga un mayor rendimiento del disco si los archivos de estos grupos se encuentran en unidades físicas separadas. Las tablas pueden estar incluso en bases de datos separadas. Sin embargo, en SQL Server 2005, siempre que los datos se encuentren en la misma base de datos, podrá utilizar la partición de tablas, que resulta mucho más fácil de implementar.

Pero supongamos que ha hecho todo lo que ha podido con la partición de tablas o con las vistas particionadas (locales) y el rendimiento sigue siendo bajo. Si tiene SQL Server 2000 o SQL Server 2005, puede utilizar las vistas particionadas distribuidas. La diferencia principal es que las tablas miembro pueden residir en instancias diferentes de SQL Server, y estas instancias se pueden instalar en un clúster N + 1. ¿Por qué es esta una buena idea? Si alguna tabla miembro pierde la conexión en una vista particionada, toda la vista se quedará sin conexión. Al incluir estos miembros como parte de un clúster, dispondrá de la confiabilidad que necesita para asumir los problemas de rendimiento y proporcionar equilibrio de carga.

¿Necesita realmente un clúster?

Es posible que tenga algunos servidores de reserva sin utilizar y que ninguno aparezca en la sección de clústeres de Windows Catalog. Es una lástima tener que salir a comprar nuevos servidores que admitan un clúster cuando dispone de estos otros.

La creación de reflejos de bases de datos puede ser una alternativa atractiva al clúster. La creación de reflejos conlleva tres elementos: una instancia que alberga la base de datos reflejada se denomina "principal"; el servidor de copia de seguridad se denomina "reflejo", y, si desea que la conmutación por error sea automática, es necesario un tercer servidor, denominado "testigo". En resumen, una transacción en una base de datos de la instancia principal se vuelve a ejecutar en el reflejo. Si la instancia principal se interrumpe, la base de datos puede conmutar por error en el reflejo, de manera automática si tiene un testigo. Debe configurar la creación de reflejos con cada una de las bases de datos de aplicaciones y no puede reflejar las bases de datos de sistema.

El reflejo es una instancia separada de SQL Server, a diferencia de lo que ocurre con un clúster, y su ubicación puede encontrarse a miles de kilómetros. Sus cachés se llenan con la actividad de actualización que se produce como resultado de las transacciones duplicadas de la instancia principal. Por supuesto, dé por sentado que la única actividad del reflejo es la recepción de las transacciones reflejadas de la instancia principal. La conmutación por error es normalmente más rápida que en un clúster, puesto que SQL Server ya se ejecuta en el reflejo. Dado que las memorias cachés están al menos parcialmente cebadas, el rendimiento inicial no es tan lento como podría serlo en un escenario de clústeres. Además, tenga en cuenta que cuando una base de datos reflejada conmuta por error, las funciones de la instancia principal y del reflejo se invierten.

La desventaja de la creación de reflejos de bases de datos es que se necesita el doble de la capacidad total en disco que con un clúster. Necesitará también una mayor potencia de CPU, si desea utilizar el modo sincrónico sin pérdida de datos. A lo dicho, una disponibilidad alta no resulta barata.

Un enfoque combinado

Puesto que un reflejo puede encontrarse en una ubicación bastante remota con respecto a la instancia principal, constituye una buena opción para los planes de recuperación de desastres (DR). Su clúster puede ser la primera línea de defensa pero, ¿qué ocurre si utiliza tanto los clústeres como la creación de reflejos? En una conmutación por error de clústeres, si tiene un testigo como parte de la configuración de creación de reflejos, el reflejo se convertirá en la instancia principal, mientras el servidor SQL Server en clúster se conecta en línea. Sin embargo, tenga en cuenta que la conmutación por error de la nueva instancia principal no se realiza de manera automática en el nuevo reflejo (en clúster). En consecuencia, es mejor no permitir la conmutación por error automática en las bases de datos reflejadas cuando se utilicen junto con un clúster.

DR no es la única razón por la que querrá utilizar la creación de reflejos; también es útil si tiene que aplicar un Service Pack o una revisión a su instancia principal, en cuyo caso puede realizar manualmente la conmutación por error en el reflejo. Al aplicar el Service Pack o la revisión, el servidor principal antiguo se queda sin conexión temporalmente y las transacciones realizadas que se producen en la nueva instancia principal se colocan en la cola, a la espera de ser devueltas al reflejo nuevo (instancia principal antigua). Una vez que se termina la instalación del Service Pack o de la revisión, tendrá lugar la sincronización y, al final, los dos servidores quedarán completamente sincronizados. Ahora, puede intercambiar las funciones de la instancia principal y el reflejo. El tiempo de inactividad ha abarcado únicamente los pocos segundos de llevar a cabo la conmutación por error y por recuperación. Puede utilizar este enfoque para migrar su SQL Server a otro equipo. Pero no realice la conmutación por recuperación.

Los servidores virtuales aportan flexibilidad.

La virtualización permite ejecutar uno o más sistemas operativos al mismo tiempo en un único servidor físico. El software de virtualización añade otra capa de capacidades al concepto de clúster porque permite agrupar el software. En consecuencia, si el servidor en el que se ejecuta el host presenta errores, entonces este, junto con sus SO invitados, conmutarán por error a un nodo de copia de seguridad. Esta podría ser una forma muy sencilla de migrar un servidor invitado. Además, el SO invitado no necesita ser compatible con clústeres. De esta forma, podría ejecutar SQL Server Workgroup Edition en un sistema operativo Windows Server 2003 invitado, que se ejecute en un clúster en Microsoft Virtual Server 2005. Indirectamente, lo que ha hecho es agrupar Workgroup Edition (consulte la figura 2).

Figura 2** Uso de un servidor virtual **(Hacer clic en la imagen para ampliarla)

Todo bajo control

Si es el encargado de una implementación de SQL Server, necesita saber que el servidor siempre va a estar disponible. El clúster de servidor ayuda a garantizar que sea así. En este artículo se ofrecen algunas sugerencias aprendidas con mucho trabajo para ayudarle a empezar. Encontrará más información útil en la barra lateral "Recursos sobre clúster".

Recursos sobre clúster

Para obtener más información sobre los métodos aquí utilizados y sobre los diversos productos que necesita para configurar su clúster de SQL Server, consulte los siguientes recursos:

• SQL Server 2005 Failover Clustering (en inglés)
• SQL Server 2000 Failover Clustering (en inglés)
• Windows Server 2003 R2 Enterprise Edition–Cluster Server (en inglés)
• Microsoft Cluster Server Administrator’s Guide (en inglés)
• Microsoft Virtual Server 2005 R2 (en inglés)

Tom Moreaucuenta con una licenciatura y un doctorado y las certificaciones MCSE y MCDBA. Es consultor independiente especializado en la administración, diseño e implementación de bases de datos de SQL Server. Vive en Toronto, Canadá. Tom lleva utilizando SQL Server desde 1993 y recibió el galardón MVP en 2001. Ha escrito más de 100 artículos y es coautor de un libro sobre SQL Server. Gracias al MVP de SQL Server Geoff Hiten por su útil aportación.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.