Consideraciones sobre el Proceso de Instalación en Cluster de SQL Server 2005 y Analysis Services 2005 (SSAS)

Un detalle peculiar de la instalación de SQL Server 2005 en Cluster y también de Analysis Services 2005 (SSAS) en Cluster, es que el proceso de instalación se ejecuta una única vez, y tras su ejecución, deja instalado el producto (SQL Server y/o Analysis Services) en todos los Nodos del Cluster, y además, deja configurado el producto para su ejecución en Cluster (es decir, deja creados todos los Recursos del Cluster, con sus dependencias, etc., y el Grupo de Recursos se queda OnLine, dando servicio).

Por ello, se realiza una única instalación (aunque SQL Server 2005 y/o Analysis Services 2005, quedará instalado en todos los Nodos del Cluster). De hecho, es indiferente desde que Nodo se realice la instalación. Yo personalmente, tomé como costumbre utilizar siempre el Nodo 1. No existe ninguna recomendación al respecto. Lo que ocurre, es que en su momento leí un artículo (que ahora no recuerdo, creo que era de SQL Server 2000, y que la fuente era MSDN o TechNet, pero es que hace varios años....) que recomendaba seriamente realizar ciertas operaciones desde el mismo Nodo desde el que se realizó la instalación, como por ejemplo, la instalación de un Service Pack (es decir, si instalamos desde el Nodo 1, cuando tengamos que instalar el Service Pack, lo hacemos desde el mismo Nodo). Cómo es algo fácil, y el cuerpo no está para sustos, tomé la costumbre. Cada uno es libre...

Este comportamiento del programa de instalación de SQL Server 2005 y Analysis Services 2005 (es decir, el hecho de realizar una única instalación para instalar todos los Nodos del Cluster), es completamente diferente a cómo funciona el programa de instalación de otros productos como Microsoft Exchange Server 2003. Por poner un ejemplo, en el caso de Exchange Server 2003, se debe realizar la instalación una vez en cada Nodo del Cluster (mientras que con SQL Server, se realiza la instalación una única vez para TODOS los Nodos del Cluster – al menos, en el caso de dos Nodos, ya que no lo he probado en Clusters con más de 2 Nodos – y mira que tengo ganas ;-), y además, es necesario configurar los Recursos y Grupo de Recursos manualmente (el programa de instalación de SQL Server 2005 y/o Analysis Services 2005, con dejarle creado e indicarle un Grupo de Recursos con un Recurso de tipo Disco Físico, realiza el resto de configuraciones, mientras que con Exchange Server 2003 es necesario también crear manualmente varios Recursos de Cluster). Para más información sobre la instalación en Cluster de Exchange Server 2003 (si resulta de interés), puede consultarse el artículo Instalación de Microsoft Exchange Server 2003 en Cluster (MSCS).

Es importante que cada Nodo del Cluster tenga suficiente memoria para poder llevar a cabo la instalación con éxito. En entornos de laboratorio con máquinas virtuales, me he encontrado con problemas al intentar montar SQL Server en máquinas con poca memoria (ej: 200MB). En principio, el proceso de instalación se inicia, pero no se consigue finalizar con éxito. En ocasiones, es necesario realizar una desinstalación manual (eliminar manualmente ficheros, directorios, ramas del registro de Windows, etc.) para poder volver a instalar con éxito, por lo tanto, para evitar problemas (aunque sólo sean máquinas virtuales), utilizar suficiente memoria para la instalación (al menos 500MB o 800MB en cada Nodo del Cluster).

Antes de empezar a instalar, recordar que es necesario:

• Un usuario con permisos elevados para realizar la instalación. Al menos, que tenga permisos de Administrador Local en ambos Nodos del Cluster, y que tenga permisos para conectarse de forma interactiva o por Terminal Server.
• Conocer lo Grupos y Usuarios (con su contraseña) de Directorio Activo que utilizaremos en la instalación de SQL Server 2005 y/o Analysis Services 2005 (SSAS), como se comentó antes en este mismo artículo.
• Conocer los servidores (Nodos) en los que se desea instalar el producto. Vale... esto es trivial, pero más de uno seguro que se ha encontrado que tiene que instalar un producto, y no le han dicho en qué máquina !!
• Los CDs, DVDs o imágenes ISO correspondientes, tanto de SQL Server 2005 (recordar que son 2 CDs ó 1 DVD), como del último Service Pack disponible (actualmente está disponible el Service Pack 2 de SQL Server 2005, y está a puntito de salir el Service Pack 3). Recordar utilizar los CDs o DVDs de la edición correcta (Enterprise, Standard, Workgroup, Developer), de la arquitectura correcta (x86, x64 ó IA64), y en el idioma correcto (un poco más adelante, hablamos sobre la elección del idioma).
• Decidir, al menos, las siguientes opciones de la instalación:
  • Rutas de instalación.
  • Nombres de Instancia. Este dato es muy importante, ya que el nombre de una instancia no se puede cambiar ni en Analysis Services 2005 (cuando está en Cluster) ni en SQL Server 2005, lo cual, implica tener que desinstalar y volver a instalar el producto, y si ya teníamos datos, tendremos que envolvernos en una pequeña migración (en cualquier caso, tan delicado como fácil de evitar). Además, se debe tener en cuenta que sólo es posible tener una única instancia por defecto (o ninguna, es decir, podemos utilizar instancias con nombre y no utilizar instancias por defecto, si es nuestro deseo). Si necesitamos dos instancias por defecto, deberemos instalar la segunda instancia en otro Cluster o en otro servidor.
  • Intercalación de las Instancias. En el caso de Analysis Services 2005, es posible cambiar la intercalación de una instancia de Analysis Services 2005. Sin embargo, en el caso de SQL Server 2005, recordar que NO se puede cambiar la intercalación de una base de datos. En caso de instalar SQL Server 2005 con un intercalación incorrecta (lo cual habrá instalado las bases de datos del sistema utilizando dicha intercalación), implica tener que reconstruir (REBUILD) las bases de datos del sistema, o bien, desinstalar y volver a instalar SQL Server 2005. Cualquiera de las opciones es delicada, por lo cual, mejor asegurarnos antes de la intercalación que deseamos. Es importante tener en cuenta que algunos productos, como por ejemplo SAP, requieren una intercalación determinada en SQL Server lo cual puede condicionar nuestra elección ;-) Para el presente Artículo, utilizaré la intercalación que suelo utilizar habitualmente (utilizaré la misma intercalación, en Analysis Services 2005 y en SQL Server 2005): Modern_Spanish_CI_AS, es decir, Modern_Spanish con Case Insensitive (insensible a mayúsculas y minúsculas, es decir, es lo mismo "casa" que "CASA" o "CasA") y Accent Sensitive (sensible a acentos, es decir, no es los mismo "este" que "esté").
  • Nombres de los Servidores Virtuales de Cluster y sus Direcciones IP asociadas.
  • Modo de Autenticación y contraseña de SA (si procede). Sólo aplica en el caso de SQL Server 2005. Podremos elegir entre dos métodos de Autenticación: Windows y Mixto (es decir, poder utilizar usuario de Windows/Directorio Activo y usuarios de SQL Server). El método más seguro y recomendable de autenticación es la Autenticación de Windows, ya que confía en Directorio Activo, con lo que se consigue el deseado Single-Sing-On (SSO), es decir, no tener que recordar una máldita contraseña más, y además es el método más seguro cara a que puedan obtenerse las contraseñas. Por el contrario, la Autenticación Mixta permite la utilización de usuarios de SQL Server, existiendo el riesgo de que se pueda obtener la password de los usuarios utilizando de SQL Server utilizando Sniffers de Red (ej: Microsoft Network Monitor, Wireshark, etc.) y además implica tener que recordar una contraseña más. Una vez más, nos podemos encontrar con productos que requieran la utilización de usuarios de SQL Server (lo que implica seleccionar el método de Autenticación Mixto), con lo que nuestra capacidad de decisión se vería bastante reducida ;-) En cualquier caso, si utilizamos Autenticación Mixta, por favor, utilizar una contraseña segura para SA y jamás dejar SA en blanco, y tampoco escribir la contraseña de SA dentro de código fuente (ej: Procedimientos Almacenados) que pueda ser inspeccionado por terceros. Este es uno de los problemas de seguridad más sencillos de evitar y relativamente frecuente.

Sobre la elección del idioma de instalación, mi recomendación (y quizás, la recomendación de la mayoría) es siempre instalar todo en inglés, tanto Sistema Operativo (ej: Windows Server 2003, Windows Server 2008, etc), como SQL Server 2005 y el resto de productos a instalar. Esto es debido a múltiples motivos, como la disponibilidad de software y parches (no todo el software y parches está en todos los idiomas - aunque siempre está inglés - , y además suele estar disponible antes en inglés que en otros idiomas), evitar errores de traducción en la documentación y en las propias pantallas del producto (o si no errores, traducciones poco claras), evitar conflictos con ficheros (ej: DLLs) compartidos por diferentes productos que puedan estar en diferentes idiomas, facilidad al solucionar problemas debido a que es más facil encontrar solución al buscar en Internet por un error en inglés que por el mismo error en cualquier otro idioma, etc.

También es importante que no exista ninguna sesión abierta en ninguno de los Nodos del Cluster durante la instalación de SQL Server (ni sesiones locales interactivas, ni sesiones remotas por Terminal, etc.). Esta recomendación es para evitar errores. Si abres una sesión en cada Nodo del Cluster (ej: por Terminal), y seguidamente intentas instalar el motor de base de datos en Cluster, la instalación será fallida. En las pruebas que hice en su día, parecía debido a que al iniciar el programa de instalación desde un Nodo, se crea un Job en el otro Nodo para instalar SQL Server de forma remota, de tal modo que parece que la ejecución del Job chocaba con la sesión abierta por Terminal Services, y por ello el proceso de instalación acaba de mala manera. Esto me ha ocurrido en varias ocasiones, tanto en entornos del laboratorio, como en la instalación de entornos reales de Producción.

Llegados a este punto, estamos preparados para iniciar nuestra deseada instalación, que cómo comenté, se realizará de forma separada para cada componente de SQL Server.