Hace unos días, realizando un proyecto de Integration Services con BIDS (Business Intelligence Developement Studio), me surgió un problema un tanto extraño, había definido una variable de usuario y a la hora de utilizarla me indicaba que no existía. Tras revisar y comprobar que el nombre, tanto en la definición de variables como en el lugar donde lo estaba usando estaba escrito de forma idéntica, todo me parecía muy extraño, no lograba entender porqué no me reconocía dicha variable.
Tras investigar el problema me di cuenta que estaba utilizando la variable "User::Var1" en mi componente, pero lo que realmente había definido era la variable "Usuario::Var1", es decir, estaba usando un Namespace diferente en la definición de la variable y en el componente donde la estaba utilizando. ¿ Dónde estaba el problema ? pues en que habitualmente utilizo BIDS en inglés, donde el Namespace por defecto cuando se define una variable de usuario es "User", mientras que en esta ocasión estaba utilizando la versión en español del producto donde el Namespace por defecto es "Usuario". Como podéis comprobar, es una traducción desafortunada, es más, creo que es una traducción que nunca se debería haber hecho.
En principio me recordó la gran cantidad de problemas que ha ocasionado la traducción de las funciones de Excel, haciendo que una hoja de cálculo que utilice funciones de error si se abre con una versión en diferente idioma en el que se realizó. Por suerte aquí el problema es mucho más sencillo, con conocer este detalle lo podemos solucionar fácilmente, bien cambiando el nombre del Namespace en la definición de la variable, o bien utilizando el mismo Namespace que tiene dicha variable. En mi caso he optado, ya que estoy habituado a utilizar la versión en inglés del producto por cambiar el Namespace de todas las variables que defino a "User" en caso de que tenga que utilizar la versión en español, cosa que intento evitar J
Probablemente este es el punto más importante del proceso de configuración, ya que va a determinar la correcta ejecución de SSIS como servicio cluster. El disco compartido y la base de datos MSDB que va a usar SSIS deben estar especificadas correctamente para que SSIS pueda funcionar realmente con un servicio cluster.
Una vez SSIS ha sido incluído dentro de un grupo de recursos del cluster hay que configurar los ficheros de configuración y el almacenaje.
Cuadro 9 - Nuevo fichero MsDtsSrvr.ini.xml
Cuadro 10 - Nuevo valor de la clave del registro
Finalmente, hay que asegurar que la instalación de SSIS sobre el cluster está funcionando correctamente.
Cuadro 11 - SSIS ejecutándose en un cluster con los dos nodos levantados
Cuadro 12 - SSIS ejecutándose en un cluster con uno de los nodos caídos
Microsoft no provee por defecto una instalación de SSIS en cluster. Sin embargo, podemos conseguir que SSIS se ejecute como un servicio cluster añadiendo los elementos básicos (sistema de archivado, base de datos MSDB) de ejecución y configuración dentro de nuevos/existentes grupos de recursos de un cluster ya existente.
Microsoft dispone de información adicional en http://technet.microsoft.com/en-us/library/ms345193.aspx
Si se desea agregar el servicio SSIS al cluster de SQL Server, entonces se puede utilizar el mismo disco compartido incluido en el grupo de SQL o se puede agregar un disco específico para el almacenaje y la configuración de SSIS.
Se va a utilizar la misma dirección IP y nombre de red por lo que solo será necesario crear el recurso de Servicio Genérico siguiendo los pasos que se explicaron en el capítulo anterior.
Una vez ejecutados esos pasos, el grupo de SQL Server tendrá un aspecto similar al que aparece en el Cuadro 8.
Si se elige esta opción habrá que:
Una vez identificada la información anterior se puede proceder a la creación del grupo.
Cuadro 5 - Ventana de parámetros del servicio genérico
Cuadro 6 - Clave del registro
Durante varios capítulos vamos a explicar las distintas fases para la instalación y configuración de SSIS dentro de un entorno cluster.
La primera consideración que debemos tener en cuenta es que SSIS no es un servicio cluster, así que no puede ser tratado como un servicio cluster normal. Sin embargo, Microsoft proporciona un alternativa para instalar y para manejar SSIS en un entorno cluster.
Hay varias ventajas y desventajas a revisar antes de la creación SSIS como un servicio cluster. Pero el propósito de este artículo es explicar el proceso para instalarlo por lo que no vamos a desarrollar ninguna discusión sobre pros y contra.
Tenemos dos alternativas para instalar SSIS como parte de un entorno cluster, como un servicio del cluster por sí mismo o como parte del servicio cluster de SQL Server. En ambos casos, para tener más control en el proceso de instalación, la situación ideal sería haber instalado previamente el servicio cluster de SQL Server.
Para cualquiera de los casos, SSIS necesita ser instalado en cada nodo del cluster, o lo que es lo mismo, habrá que ejecutar el proceso de instalación tantas veces como nodos vayan a formar parte del servicio cluster de SSIS. El proceso de instalación de SSIS a seguir es el mismo que se sigue al instalarlo como servicio independiente en un servidor aislado. Una vez haya comenzado el proceso de la instalación, asegurarse de chequear únicamente la opción SSIS (todos los otros elementos habrían sido instalados como parte de la instalación cluster de SQL Server). Como se puede ver en el Cuadro 1, SSIS no muestra la opción para ser instalado como un failover cluster.
Cuadro 1 - Opción a seleccionar para instalar SSIS
En nuestro ejemplo tenemos un cluster llamado CTest compuesto de dos nodos (Romeo y Hamlet). En este cluster ya tenemos instalado el servicio cluster para SQL Server con el nombre Horacio.
Una vez hayamos instalado SSIS en Hamlet podremos conectar con él pero no con Romeo (Cuadro 2). Como indicamos antes, necesitamos instalarlo como si fueran servidores independientes. Pero hay una situación que podría hacernos pensar que SSIS se instala automáticamente como servicio cluster. Cuando SSIS se ha instalado en el nodo activo del cluster (Hamlet en este caso), si se intenta conectar a SSIS en CTest u Horacio, se conectará con éxito (Cuadro 3), sin embargo, si se apaga Hamlet convirtiendo Romeo en el nodo activo, la conexión de SSIS se perderá (Cuadro 4). Esto significa que SSIS no está trabajando aún como un servicio cluster.
Cuadro 2 - Conectividad disponible solo en el nodo instalado
Cuadro 3 - SSIS aparece disponible en la instancia del cluster
Cuadro 4 - SSIS no aparece disponible en la instancia del cluster
Una vez se ha instalado SSIS en ambos servidores podemos proceder a incluirlo como parte del cluster.
La dificultad del siguiente paso es determinar en qué grupo de recursos del cluster se va a añadir el servicio SSIS. Si decidimos fijarlo en el mismo grupo de SQL Server, entonces el servicio de SSIS será parte del cluster de SQL Server, pero si se decide incluirlo como recurso en un grupo nuevo o existente (pero diferente del grupo donde reside SQL Server) entonces SSIS será tratado como servicio cluster independiente del cluster de SQL Server.