Share via


Acerca de la implementación del módulo de almacenamiento de datos

 

Publicado: julio de 2016

Se aplica a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

La implementación del módulo del almacenamiento de datos de System Center 2012 – Service Manager se inicia cuando el servidor de administración de Service Manager se registra en un Servidor de administración del almacenamiento de datos. Las secciones siguientes describen los componentes, las funciones y la programación del módulo.

Sincronización del módulo de administración

La sincronización del módulo de administración es el proceso mediante el cual el almacenamiento de datos detecta qué clases y relaciones existen en los sistemas de origen. Este proceso también se conoce como MPSync. Para cada módulo de administración que define una clase o relación, el almacenamiento de datos crea módulos de trabajo de extracción para recuperar los datos de esa clase o relación del origen correspondiente. Dichos módulos de administración y sus trabajos asociados se sincronizan entre los sistemas.

Sólo los módulos de administración sellados, y sus datos correspondientes, se sincronizan en el almacenamiento de datos. Si altera un módulo de administración, debe aumentar el número de versión y no puede realizar ningún cambio que pudiese provocar errores; de lo contrario, se produciría un error en la importación del módulo de administración. Por ejemplo, no puede quitar clases, propiedades ni relaciones. Del mismo modo, no puede cambiar los tipos de datos en formas no compatibles. Por ejemplo, no puede modificar ninguna propiedad de cadena para que se convierta en una propiedad numérica.

De forma predeterminada, el trabajo de MPSync de Orchestration se ejecuta cada 30 minutos.

Es posible que varios orígenes hagan referencia al mismo módulo de administración. La versión en el sistema de origen debe ser la misma versión o una versión superior a la del almacenamiento de datos, de lo contrario se producirá un error de registro.

Puede quitar módulos de administración del almacenamiento de datos. Sin embargo, tenga presente los siguientes puntos:

  1. Al quitar módulos de administración no se eliminan los datos del almacenamiento de datos como se hace en la base de datos de Service Manager ; en su lugar, se anula la vista de la base de datos a la que tienen acceso los usuarios.

  2. Si vuelve a importar un módulo de administración después de haber quitado el módulo de administración correspondiente, los datos históricos se exponen de nuevo.

    Nota


    Sólo los módulos de administración sellados se sincronizan desde Service Manager con el almacenamiento de datos. Una excepción son los elementos de lista, también conocidos como enumeraciones. Los grupos o las colas se sincronizan con el almacenamiento de datos, independientemente de si están en un módulo de administración sellado o no sellado. Para obtener más información sobre cómo sellar un módulo de administración, consulte la entrada de blog Sealing Management Packs (Cómo sellar un módulo de administración).

Los módulos de administración que se importan desde Service Manager son específicos de Service Managery específicos del almacenamiento de datos. Los módulos de administración de Service Manager proporcionan información sobre la estructura de la base de datos de Service Manager y los módulos de administración del almacenamiento de datos controlan la estructura y los procesos de las bases de datos del almacenamiento de datos.

Implementación de informes

Con el proceso de sincronización del módulo de administración se importan los módulos de administración desde Service Managery se define cómo dichos módulos de administración dan forma a la estructura, mueven los datos y copian informes por el almacenamiento de datos e informes. Una vez sincronizados dichos módulos de administración entre Service Manager y el almacenamiento de datos, se recuperan los datos y se implementan los informes para que los usuarios los puedan consumir.

De forma secuencial, la implementación de informes se produce en el proceso siguiente:

  1. Una vez que todos los módulos de administración identificados se han sincronizado con el almacenamiento de datos, la sincronización del módulo de administración activa el flujo de trabajo de implementación del informe.

  2. Dado que la base de datos DWStagingandConfig es el destino final de los módulos de administración que se han sincronizado, el flujo de trabajo de implementación consulta la base de datos DWStagingandConfig para comprobar si hay informes nuevos o modificados que implementar, o informes que quitar.

  3. A continuación, el flujo de trabajo de implementación publica todos los informes nuevos o actualizados en el servidor de SQL Server Reporting Services (SSRS) a través de los servicios web SSRS.

  4. SSRS almacena los informes y los metadatos adecuados.

  5. El flujo de trabajo de implementación de esquema se activa mediante la sincronización del módulo de administración.

  6. Una vez más, se recupera la información que provoca los cambios de esquema de la base de datos DWStagingandConfig, de acuerdo con los módulos de administración recién sincronizados que provocan los cambios.

  7. Los cambios de esquema se implementan en la base de datos DWRepository.

  8. Los cambios necesarios de extracción, transformación y carga (ETL) de los módulos se realizan en la base de datos DWStagingandConfig.

Los módulos de administración que contienen solo información específica de Service Managerno hacen que se ejecuten las actividades de implementación. Sólo se desencadenan para los nuevos elementos del almacenamiento de datos y específicos de informes.

Información acerca de los procesos ETL

Una vez implementados el esquema del almacenamiento de datos y los informes, la base de datos DWDataMart se llena con datos reales para fines informativos. Esto se realiza mediante los procesos ETL. Cada uno de estos tres procesos tiene su propia finalidad específica:

  • Extracción se ha diseñado específicamente para el procesamiento de grandes volúmenes de datos de varios orígenes y permite mover datos a un área creada para procesar los datos.

  • Transformación se ha diseñado para la optimización de operaciones complejas de lógica e integración. En este proceso se produce la mayor parte del trabajo ETL.

  • Carga se ha diseñado para transferir a su destino los datos ya procesados de forma masiva.

Una de las razones principales de tener tres bases de datos diferentes es poder optimizar el entorno de hardware más fácilmente. En entornos de gran volumen, las bases de datos DWStagingandConfig y DWRepository deben estar en hardware de equipo que esté optimizado para E/S de lectura y escritura. Sin embargo, el hardware de equipo que hospeda la base de datos de DWDatamart se debe optimizar para E/S de lectura. Teniendo en cuenta esa diferencia, puede separar la DWDatamart en otro servidor o unidad distinto de las bases de datos DWStagingandConfig y DWRepository. Sin embargo, las bases de datos DWStagingandConfig y DWRepository deben permanecer en el mismo servidor.

En un nivel alto, ETL tiene lugar en los procesos descritos en las secciones siguientes. Si planea la creación de módulos de administración que se usen para informes personalizados, probablemente necesitará saber más acerca de estos procesos con detalle. Para obtener más información acerca de los procesos ETL, consulte Authoring Guide for System Center 2012 - Service Manager (Guía de creación para System Center 2012 - Service Manager).

Extracción

El proceso de extracción se inicia en un intervalo programado. Mediante el proceso de extracción se recuperan los datos sin procesar del almacén del sistema de procesamiento de transacciones en línea (OLTP) que, en este caso, es la base de datos de Service Manager .

  1. El proceso de extracción busca en Service Manager las diferencias de datos que se han acumulado desde la última vez que se ejecutó el proceso de extracción.

  2. Los nuevos datos sin procesar se escriben en la base de datos DWStagingandConfig de la misma forma básica que en la base de datos de Service Manager .

Transformación

El proceso de transformación se inicia en un intervalo programado. La transformación es el proceso que traslada los datos sin procesar de la base de datos DWStagingandConfig. También realiza cualquier tarea de limpieza, nuevo formato y agregación necesarias para modificar los datos sin procesar en el formato final para la generación de informes. Estos datos transformados se escriben en la base de datos DWRepository.

Carga

El proceso de carga se inicia en un intervalo programado. El proceso de carga busca los datos en la base de datos DWRepository. Los datos transformados de DWRepository se insertan en la base de datos DWDatamart. DWDatamart es la base de datos que se utiliza para todas las necesidades de informes del usuario final.