Antes de empezar, creo que es interesante describir el entorno utilizado para las presentes pruebas. Se trata de una infraestructura de BusinessObjects Enterprise XI R2 formada por una única máquina, la cual ejecuta todos los servicios de Business Objects (CMS, Cache Server, Event Server, Job Server, etc.).
El frontal, es decir, el servidor Web en el que se ejecuta InfoView, es un servidor Microsoft Internet Information Server (IIS) con ASP.Net (recordar que Infoview se puede montar sobre Java o sobre ASP.Net).
La base de datos utilizada para el repositorio es SQL Server 2000 Enterprise (recordar que es posible utilizar otros motores de base de datos como MySQL, pero claro, yo conozco mejor SQL Server, que le voy a hacer ;-). Se trata de un servidor externo al servidor de BusinessObjects, en particular SQL Server 2000 está montado sobre un servidor Microsoft Cluster MSCS, con objetivo de dotar de alta disponibilidad a la base de datos. Para más información sobre Microsoft Cluster MSCS, es posible leer mi artículo Instalar y Configurar Microsoft Cluster (MSCS) en Windows Server 2003
Por supuesto, toda esta infraestructura forma parte del correspondiente dominio de Directorio Activo (recordar que Microsoft Cluster MSCS requiere de Directorio Activo).
El uso principal de este entorno, es el acceso a Infoview para la visualización de informes desarrollados con Crystal Reports XI, así como el acceso a cubos (bases de datos multidimensionales - MOLAP) a través de Olap Intelligence (antiguamente conocido como Crystal Analysis). No se utiliza Web Intelligence (WeBi para los amigos ;-) ni se utilizan los famosos Universos de BusinessObjects, aunque los informes de Crystal Reports con Parámetros Dinámicos (Dynamic Prompts) nos permiten sufrir de un modo equivalente ;-)
Resulta de gran importancia tener claro de qué elementos se necesita realizar las copias de seguridad, para poder recuperar nuestra infraestructura en caso de desastre. Los elementos que deberemos tener cubiertos en nuestras políticas de copia de seguridad son:
- La base de datos del Repositorio. El repositorio es una base de datos que contiene la definición de todos los objetos de BusinessObjects, como son los usuarios, los informes, las categorías, los permisos, etc. En nuestro caso de ejemplo, se trata de una base de datos SQL Server 2000, pero podría ser un motor de base de datos distinto, como ORACLE, DB2 ó MySQL.
- El Almacén de Ficheros (File Store). Todos los ficheros almacenados en BusinessObjects Enterprise, (ej: informes de Crystal Reports, instantáneas de los informes, documentos PDF, etc.) son almacenados en el sistema de ficheros, en particular bajo el directorio FileStore. Sin embargo, aunque su almacenamiento físico sea en el sistema de ficheros, es evidente que en el Repositorio queda definido una referencia al fichero físico del FileStore para cada objeto, entre otras cosas. Esto es necesario, debido a que bajo el directorio FileStore existe una jerarquía de directorios propietaria, es decir, si esperamos encontrarnos una jerarquía de ficheros en base a las carpetas de InfoView o en base a algún otro patrón conocido, descubriremos que NO es así y que existe una jerarquía de directorios de aspecto arbitrario.
Como vemos, para poder recuperar nuestro servidor BusinessObjects Enterprise XI, necesitamos poder recuperar tanto la base de datos como el sistema de ficheros (en particular, el directorio FileStore). Por ello, necesitaremos que ambas copias de seguridad (de base de datos y del directorio FileStore) estén en algún modo sincronizadas, esto es, que pertenezcan al mismo momento en el tiempo.
Todo lo dicho es cierto, sin embargo, en la mayoría de las instalaciones se realizan personalizaciones de BusinessObjects Enterprise, para ajustar el producto a las necesidades propias de cada situación. Resulta muy típico personalizar InfoView, principalmente:
- Modificar el código javascript para ajustar pequeños detalles funcionales de InfoView.
- Modificar páginas html para ajustar pequeños detalles funcionales, por ejemplo, reprogramando a través de la API de BusinessObjects.
- Agregar o modificar ficheros de imágenes, u otros recursos (ej: hojas de estilo CSS, etc.) típicos de las aplicaciones Web.
- Agregar ficheros ejecutables, que programados con Visual Studio utilizando la API de BusinessObjects, permitan realizar tareas administrativas, ya sea ejecutados bajo demanda, ejecutados de forma planificada (ej: a través del administrador de tareas de Windows, etc.).
Todas estas modificaciones, deben de ser tenidas en cuenta en nuestro plan de contingencias, ya que en función del escenario de desastre al que nos enfrentemos, deberemos ser capaz de aplicar y garantizar la implantación de dichos cambios para devolver el entorno a su estado de funcionamiento habitual.
Por ello, en caso de haber realizado modificaciones del producto (ej: modificar InfoView) es necesario incluir en nuestras políticas de copia de seguridad, al menos los elementos modificados, con el fin de poder garantizar su restauración en caso de desastre.
A continuación, se detallan los dos posibles escenarios de recuperación completa: sobre el mismo servidor (volviendo en consecuencia a una situación anterior), o sobre un nuevo servidor (sobre el que deberemos instalar BusinessObjects Enterprise XI).
Este escenario de recuperación corresponde con el caso en que tenemos un servidor BusinessObjects Enterprise XI funcionando correctamente, y deseamos volver a un momento anterior en el tiempo. Esta situación, se puede provocar por diferentes motivos, como por ejemplo por un paso a producción (o un paso entre entornos a un entorno previo de producción) poco exitoso, una manipulación poco agraciada del Repositorio, etc.
En cualquier caso, en este escenario se parte de la premisa de que los únicos elementos dañados son el Repositorio y/o el FileStore, manteniéndose en buen estado los propios ejecutables y binarios del producto, etc. Los pasos a seguir son los siguientes:
- Parar todos los servicios de BusinessObjects Enterprise. Esta tarea puede realizarse desde el Administrador de Configuración Central. Es recomendable parar el servicio CMS en último lugar. Si algún servicio no es capaz de detener, matar el proceso desde el administrador de tareas de Windows (esto no debería de ocurrir).
- Opcionalmente, renombrar el actual directorio FileStore. El motivo de esta acción es para garantizar la posibilidad de poder volver al momento actual. Por ello, del mismo modo es también opcional realizar una copia de seguridad de la base de datos de Repositorio.
- Recuperar la base de datos del Repositorio. En el caso de SQL Server, es recomendable poner la base de datos en estado OFFLINE para garantizar que nadie puede conectarse a dicha base de datos (recordar que la operación RESTORE DATABASE requiere de exclusividad).
- Recuperar el directorio FileStore. Recordar que debe de recuperarse al mismo momento en el tiempo al que se recupera el Repositorio.
- Iniciar todos los servicios de BusinessObjects Enterprise. Esta tarea puede realizarse desde el Administrador de Configuración Central. Primero se debe iniciar el servicio CMS, y después el resto de servicios de BusinessObjects Enterprise.
Realizados estos pasos, se habrá recuperado el servidor BusinessObjects Enterprise a un estado anterior en el tiempo. Es muy recomendable realizar alguna comprobación posterior, como por ejemplo, comprobar que existe algún usuario o algún informe reciente, o que NO existe algún usuario o informe eliminado posteriormente a la copia de seguridad, etc.
Este escenario de recuperación corresponde con el caso en que hemos perdido el servidor BusinessObjects Enterprise XI, ya sea debido a un problema hardware o software, y deseamos volver a un momento anterior en el tiempo.
En cualquier caso, en este escenario los daños no están localizados únicamente en el Repositorio y el FileStore, ya sea porque existen binarios del producto en mal estado, porque la máquina no arranca, porque se ha instalado un HotFix y se desea volver a un momento anterior, etc.
Este procedimiento, también puede utilizarse para realizar una migración a una nueva máquina, por ejemplo, para poder disfrutar de un hardware más potente.
Los pasos a seguir son los siguientes:
- Instalar en una nueva máquina BusinessObjects Enterprise XI R2. Suele ser recomendable utilizar el mismo nombre de máquina (nombre NetBIOS) y dirección IP. Si no se mantiene la dirección IP y se utiliza algún nombre de host o alias DNS, será necesario actualizarlo.
- Parar todos los servicios de BusinessObjects Enterprise. Esta tarea puede realizarse desde el Administrador de Configuración Central. Es recomendable parar el servicio CMS en último lugar. Si algún servicio no es capaz de detener, matar el proceso desde el administrador de tareas de Windows (esto no debería de ocurrir).
- Opcionalmente, renombrar el actual directorio FileStore. El motivo de esta acción es para garantizar la posibilidad de poder volver al momento actual. Por ello, del mismo modo es también opcional realizar una copia de seguridad de la base de datos de Repositorio.
- Recuperar la base de datos del Repositorio. En el caso de SQL Server, es recomendable poner la base de datos en estado OFFLINE para garantizar que nadie puede conectarse a dicha base de datos (recordar que la operación RESTORE DATABASE requiere de exclusividad).
- Recuperar el directorio FileStore. Recordar que debe de recuperarse al mismo momento en el tiempo al que se recupera el Repositorio.
- Recuperar las personalizaciones existentes en la instalación. Esto es, si existen páginas html modificadas, ficheros de hoja de estilo (CSS), código javascript, etc., también deberá restaurarse, con el fin de dejar el servidor BusinessObjects Enterprise correctamente operativo.
- Iniciar todos los servicios de BusinessObjects Enterprise. Esta tarea puede realizarse desde el Administrador de Configuración Central. Primero se debe iniciar el servicio CMS, y después el resto de servicios de BusinessObjects Enterprise.
Realizados estos pasos, se habrá recuperado el servidor BusinessObjects Enterprise a un estado anterior en el tiempo. Es muy recomendable realizar alguna comprobación posterior, como por ejemplo, comprobar que existe algún usuario o algún informe reciente, o que NO existe algún usuario o informe eliminado posteriormente a la copia de seguridad, comprobar que las personalizaciones de InfoView (en caso de existir) han sido aplicadas con éxito, etc.
Quizás el principal inconveniente de éste procedimiento esté en el primer paso, la instalación completa de BusinessObjects Enterprise, por el tiempo necesario. Cabe la posibilidad de mantener un servidor pre-instalado. Dicho servidor no puede mantener el mismo nombre de máquina (nombre NetBIOS), ya que esto no es posible (menos aún en un domino de Directorio Activo). En caso de utilizar un servidor pre-instalado, se deberá sustituir los dos primeros pasos anteriores, por los pasos siguientes:
- Sacar la máquina del dominio, cambiar el SID de la máquina (ej: con la utilidad NewSID de Systernals), cambiar el nombre la máquina (establecer el nombre de máquina, del servidor que queremos restaurar), agregar la máquina al dominio.
- Parar todos los servicios de BusinessObjects Enterprise. Esta tarea puede realizarse desde el Administrador de Configuración Central. Es recomendable parar el servicio CMS en último lugar. Si algún servicio no es capaz de detener, matar el proceso desde el administrador de tareas de Windows (esto no debería de ocurrir).
- Modificar la línea de comandos de todos los servicios de BusinessObjects Enterprise para utilizar el actual nombre de CMS. Esta tarea puede realizarse desde el Administrador de Configuración Central.
- Modificar en el registro de Windows las referencias al antiguo nombre de CMS por el nuevo nombre de CMS. Si se utiliza el nombre de CMS en alguna ruta de fichero, recordar modificar dicha ruta en el sistema de ficheros. Las ramas del registro de Windows que deberemos revisar son las siguientes:
- HKLM\SOFTWARE\Business Objects\Suite 11.0\CMS\Instances
- HKLM\SOFTWARE\Business Objects\Suite 11.0\Enterprise\CMSClusterMembers
- HKLM\SOFTWARE\Business Objects\Suite 11.0\Enterprise\UIControls
- HKLM\SOFTWARE\Business Objects\Suite 11.0\JobServer\Instances
- HKLM\SOFTWARE\Business Objects\Suite 11.0\PageServer\Instances
- HKLM\SOFTWARE\Business Objects\Suite 11.0\Report Aplication Server\Instances
- HKLM\SOFTWARE\Business Objects\Suite 11.0\Web Component Adapter
- HKLM\SOFTWARE\Business Objects\Suite 11.0\Web Component AdapterInstances
- HKLM\SOFTWARE\Business Objects\Suite 11.0\WebIntelligence Report Server\Instances
Los directorios del sistema de ficheros que deberemos comprobar son los siguientes: - X:\Archivos de programa\Business Objects\BusinessObjects Enterprise 11\Data\procSched\
- X:\Archivos de programa\Business Objects\BusinessObjects Enterprise 11\Data\
- Modificar el fichero de configuración Web.Config. En este fichero de configuración, se deben sustituir todas las ocurrencias del antiguo nombre de CMS por el nuevo nombre de CMS.
- Modificar la entrada ODBC utilizada para acceder a la base de datos del Repositorio, configurándola contra la base de datos de repositorio deseada (la base de datos del anterior CMS, es decir, del que estamos recuperando). Esta tarea puede realizarse desde el Administrador de Configuración Central y desde la herramienta administrativa Orígenes de Datos (ODBC).
En este Artículo he pretendido mostrar una forma en la que enfocar un Plan de Contingencias para mantener protegido y poder recuperar una infraestructura BusinessObjects Enterprise XI R2 y también la versión anterior, BusinessObjects Enterprise XI (sin el R2 ;-).
La solución que aquí presento, ha sido probada con éxito en entornos de Producción de BusinessObjects Enterprise XI y de BusinessObjects Enterprise XI R2, funcionando correctamente, y presentando unos tiempos de recuperación aceptables (claro está, que el tiempo de recuperación es proporcional al volumen de información a recuperar y al número de ficheros).
Aunque la infraestructura de laboratorio tomada para este artículo, está formada por un único servidor BusinessObjects Enterprise XI R2, es posible adaptar este plan de contingencias para una infraestructura con múltiples servidores BusinessObjects, en la que cada uno de los servidores puede estar ejecutando diferentes servicios (ej: CMS, JobServer, etc.).
Esta NO es la única forma de proteger una infraestructura BusinessObjects Enterprise, de hecho, si por ejemplo utilizamos máquinas virtuales (VMWare, Virtual Server 2005, Hyper-V, etc.), siempre es posible clonar las máquinas virtuales (quizás la solución más sencilla ;-).
El principal inconveniente que encuentro en el plan de recuperación que aquí presento, es que sólo se permite recuperaciones totales, esto es, no se permite una recuperación parcial de un único objeto o de todos los objetos de una categoría o carpeta de InfoView.
