El software de BMC, Remedy (vesión 8.1 actualmente), se usa como herramienta de ticketing en multitud de clientes, tanto para la gestión de incidencias (BMC Remedy Incident Management), como para las peticiones (BMC Remedy Change Management).

 

Con la incorporación del DCIM, en lo que se refiere a la apertura de incidencias por parte de BEM no cambiaría en nada, puesto que es con el software de BEM que se abren incidencias o tickets, según los estados de los elementos monitorizados.

 

Los tickets asociados a las peticiones pueden ser aprobados y validados en Remedy y realizar en éste su seguimiento. Una parte de estas peticiones estarán relacionadas directamente con el CPD, como por ejemplo la petición de una nueva plataforma de procesamiento, la ampliación de una cabina, la instalación de unas líneas de comunicaciones y switches, etc.

Estas peticiones por tanto, estarán registradas en Remedy y por tanto pueden traspasarse al DCIM para la ejecución de los trabajos. Como el DCIM es la herramienta que sugiere la posición más adecuada de un equipo (por ejemplo en qué rack es más conveniente instalar un servidor), será el DCIM la plataforma en la que se trabaje el detalle preciso de los trabajos a realizar (conectar el puerto x de un servidor con el puerto y concreto de un switch, etc.). Desde el DCIM se elabora la orden de trabajo asociada al ticket que solicita instalar nuevos equipos. En el DCIM se pueden crear tareas detalladas asociadas a esta orden de trabajo. Evitamos de esta manera mantener información de bajo nivel (puertos concretos, posiciones de U, cableados, etc.) de los trabajos en Remedy, pero dado que guardamos información de la relación entre los elementos de ambas plataformas siempre podríamos encontrar los detalles de los trabajos relacionados con cualquier petición.

 

 

La plataforma DCIM de Schneider dispone de un módulo estandarizado de integración con BMC Remedy para la gestión de tickets relacionados con el CPD. Esta integración está incluida en la solución. Para implementar ésta integración es necesario establecer una regla que permita discriminar dentro de Remedy aquellos tickets que tengan como objeto actividades del CPD.

 

Queremos señalar que el DCO de StruxureWare se puede relacionar con Remedy Change Management System.

 

Una vez establecida la relación, se permite desde el DCO, abrir órdenes de trabajo que van a parar a Remedy y también hacer un seguimiento de las órdenes de trabajo de Remedy desde el DCO, tal como se muestra en la imagen siguiente:

 

 

Como se puede observar en la imagen de la ventana de configuración de la integración, las órdenes de trabajo a las que se les hace seguimiento responden a un filtro que ha de corresponder con tickets en Remedy relacionados con el DCO y para el User Group del DC.

 

 

Los Centros de Datos pueden tener su propio sistema SCADA o un sistema inteligente de Networking o un sistema estándar de gestión ITIL. A los clientes, por tanto, les interesa que el DCIM se integre con las herramientas instaladas y de uso estándar en la compañía. Software Greenhouse, por ser una empresa de software especializada en la optimización de la gestión del Data Center, presta los servicios de integración con los aplicativos existentes.

 

A continuación, algunos ejemplos de integraciones realizadas:

 

Links de interés (material de Schneider Electric):

 

 

La detección de eventos se realiza a través del sistema de monitorización de la plataforma DCIM llamado DataCenter Expert (DCE) que constituye la base de captura de datos de la infraestructura.

 

En nuestra herramienta (DCE) de detección de eventos definimos los niveles y condiciones de detección de eventos, distinguiendo avisos, alertas, y situaciones críticas de la infraestructura.

 

Las alertas se envían al sistema Data Center Operation a través de la conexión interna de la plataforma donde se contextualizan en el modelo virtual del CPD. También se puede integrar con otros sistemas a través de la funcionalidad de integración “Enterprise”.

 

Esta integración envía los eventos a través de traps SNMP. Las traps enviadas al sistema central de gestión de eventos (event manager) se interpretan a través de la MIB que describe los eventos (powernet.mib). Ante cualquier cambio en el protocolo, o en los tipos de alertas Schneider Electric actualizará el MIB y los traps que genera el DCE.

 

Para alcanzar el nivel de integración con la CMDB que existe en los eventos del cliente, será necesario incorporar los elementos de configuración (Ci) de la infraestructura que puedan generar eventos a través de la monitorización.

 

La integración con la CMDB terminará de asegurar que los Cis definidos en los eventos que llegan al BEM, sean los mismos y estén claramente identificados en la plataforma DCO. De este modo, cuando exista una alarma y los operadores necesiten entender el contexto el evento podrán acudir a la plataforma DCO. En DCO el operador podrá identificar los Cis afectados de forma unívoca en todas las plataformas (BEM, CMDB, DCO y DCE), añadiendo consistencia a la información y a los procesos y disminuyendo la probabilidad de errores humanos.

 

La integración del DCIM con la CMDB es un elemento fundamental de consistencia de la información importante para evitar la duplicidad de informaciones o la inconsistencia y las dificultades para ubicar los activos.

 

La solución propuesta es un desarrollo sobre la plataforma de integración embebida en la plataforma DCIM. Esta plataforma es un motor de ETL (Extract, Transform, Load) sobre el que se desarrollará la lógica de movimiento de datos entre las plataformas. A alto nivel el proceso de desarrollo de la integración se esquematiza en el siguiente diagrama:

 

 

El DCIM gestiona la configuración de toda la infraestructura de IT y de Facilities:

 

En función de los objetivos y procesos de negocio, el cliente determinará qué tipo de dispositivos se integrarán y si fuera necesario definirá los elementos adicionales dentro de la CMDB, en caso de que no estuvieran definidos previamente.

 

Esas relaciones de ubicación y localización de los elementos (CI’s de la CMDB) en el CPD, las aportaría el DCIM por las interfaces con la CMDB. El cliente debe decidir el nivel de detalle al que se debe llegar. Desde el DCIM (DCO) se puede alimentar la CMDB con toda la información de rutas de interconexiones de red, dependencias eléctricas o redundancias.

 

Con la incorporación del DCIM hay que considerar que hay equipos, como los servidores, que tienen una información propia del DCIM y que puede transferirse a la CMDB, información técnica e información relacionada con la localización del equipo en el CPD: por ejemplo, en qué posición está el servidor dentro del rack X y cuántas U’s ocupa. Para este caso, se deduce que hay información que tiene la CMDB de un dispositivo, y otra que proviene del DCIM, por lo que las interfaces deben de ser bidireccionales.

 

Una vez definida la configuración del DCO y bien establecidos los Workflows de despliegue de equipos, reemplazo, baja y actualizaciones se concretarán los atributos y acciones que se deberán plasmar en los archivos de interface de la ETL.

 

El esquema de integración entre dos herramientas concretas depende del interface de ofrecido por cada proveedor. El ejemplo a continuación muestra la integración cuando las dos herramientas utilizan para la transformación y transporte de datos el ETL Pentaho:

 

Como podemos ver en la imagen hay dos flujos de datos, uno desde el DCIM a la CMDB y otro desde la CMDB al DCIM. Cada plataforma se convertirá en sistema maestro de algunos de los campos de la base de datos federada constituida por la información combinada de ambos sistemas.

 

Basado en las características comunes de los registros entre ambos sistemas se generará una asociación automática entre los registros de ambos sistemas. Una nomenclatura bien gestionada permite mantener la consistencia de la información. El modelo federado se mantiene en el DCIM empleando la funcionalidad de asociación de dispositivos de sistemas externos.