Rendimiento y tamaño de la base de datos

Publicado: marzo de 2016

Se aplica a: System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator

El tamaño de la base de datos es un factor clave para comprender el rendimiento de System Center 2012 - Orchestrator. Los servidores de Runbooks, el servidor de administración y los componentes web dependen de la base de datos de Orchestrator para sus operaciones. Pueden producirse problemas en las implementaciones de Orchestrator si no se tienen conocimientos detallados acerca de los tipos de datos usados en la base de datos y su administración.

Puesto que Runbook Designer se comunica con la base de datos de Orchestrator (mediante el servidor de administración), un rendimiento bajo de la base de datos impedirá que se realice dicha comunicación.

La experiencia del operador de Orchestrator se basa en dos componentes: La Consola de Orchestration y el servicio web. La Consola de Orchestration es una aplicación basada en Silverlight que depende del servicio web para su conexión a la base de datos de Orchestrator. El servicio web es una aplicación de IIS que se conecta a la base de datos. En consecuencia, el servicio web y la Consola de Orchestration dependen del rendimiento de la base de datos de Orchestrator.

Asimismo, aunque la Consola de Orchestration depende del servicio web, también dispone de una lógica exclusiva a su función como interfaz de usuario con sus propias características de rendimiento.

Datos de configuración y datos de registro

En líneas generales, la base de datos de Orchestrator contiene dos tipos de datos:

• Datos de configuración

  La infraestructura de Orchestrator contiene datos de configuración. Estos datos no representan un problema en términos de crecimiento de la base de datos, ya que sus requisitos de almacenamiento son reducidos.

• Datos de registro

  Orchestrator genera diferentes tipos de datos de registro. Es posible visualizar y administrar estos datos en Runbook Designer. Los requisitos de almacenamiento de estos datos pueden variar en cuanto a su tamaño y ser elevados.

  En la tabla siguiente se enumeran los tipos de datos de registro que se pueden almacenar en la base de datos de Orchestrator.Orchestrator también almacena datos en archivos de registro independientes (fuera de la base de datos) para las trazas de auditoría y el seguimiento. Para obtener más información acerca de los tipos de datos de registro, vea Registros de Orchestrator.

  Tipos de datos de registro	Ubicación en Runbook Designer	Administrados por la purga del registro
  Registros de Runbook	Pestañas Registro e Historial de registro	Sí
  Eventos de actividad (plataforma)	Pestaña Eventos	No
  Historial de auditoría	Pestaña Historial de auditoría	No

Código de plataforma y código de dominio

Las actividades de Runbook de Orchestrator contienen dos tipos de código distintos:

• Código de plataforma

  Se trata de un código común compartido por la mayoría de las actividades que se utiliza para ejecutar las tareas comunes que realizan las actividades de Orchestrator. El código de plataforma genera datos publicados comunes.

• Código de dominio

  Ejecuta una amplia gama de tareas específicas para las acciones de cada actividad que normalmente no están asociadas a la plataforma de Orchestrator en sí misma. Pueden existir importantes diferencias entre el código de plataforma y el código de dominio.

  Los datos de registro generados para una actividad determinada pueden contener elementos de datos de valor único o múltiple. Todas las actividades producen un único registro de datos de valor único. El código de dominio puede producir varios registros de datos de valor múltiple. Por lo tanto, es responsable de determinar qué acciones realiza la actividad con los datos publicados comunes recibidos de actividades anteriores.

  En general, los Runbooks de Orchestrator están diseñados para pasar datos entre elementos discretos de código de dominio. Además, el código de dominio puede, de manera opcional, generar datos publicados según la actividad.

Todos los Runbooks tienen en común que ejecutan actividades que constan de código de dominio y código de plataforma, crean bucles de flujos de trabajo y crean bifurcaciones. La bifurcación se produce cuando un Runbook llama a otros Runbooks para realizar una tarea específica. Cuando se invoca un Runbook por primera vez, este consta de un único subproceso. Cuando dicho subproceso encuentra una actividad de Runbook cuyos vínculos requieren una bifurcación, se crean subprocesos adicionales, uno para cada bifurcación. Cada subproceso toma como entrada los datos publicados comunes de la actividad que creó la bifurcación. Dichos datos se correlacionan a las actividades anteriores del Runbook para actualizar los datos publicados comunes a los que se suscriben las actividades.

El código de dominio puede afectar al rendimiento de la base de datos en mayor medida que los múltiples subprocesos generados por la bifurcación. Esto se debe a que el código de dominio puede generar grandes cantidades de datos publicados según la actividad.

Opciones de registro

La pestaña Registro de las Propiedades de un Runbook permite almacenar, de manera opcional, las entradas de registro. El término registro predeterminado equivale a no tener seleccionada ninguna de las dos opciones de datos publicados, lo que indica que se generarán 524 bytes de datos para cada actividad. Las opciones de registro ofrecen dos categorías de datos publicados comunes:

• Datos publicados comunes

  Conjunto de elementos de datos comunes a todas las actividades. Para obtener una lista, vea la sección Opciones de registro de Runbook en Registros de Runbook.

  Esta opción de registro genera 6082 bytes de datos para cada actividad.

• Datos publicados según la actividad

  Conjunto de datos específico para la actividad que crea el código de dominio de manera opcional.

  Esta opción de registro genera 6082 bytes de datos además de los bytes que registran las actividades específicas.

  Sugerencia
  Esta opción suele activarse con fines de depuración. No active esta opción para limitar el crecimiento del registro.

La configuración de las opciones de registro puede influir en gran medida en el rendimiento y aumentar el tamaño de la base de datos. Considere el escenario en el que la misma actividad de Runbook se ejecuta dos veces: una vez con el registro de datos predeterminado (sin seleccionar ninguna opción de datos publicados) y otra con los datos publicados comunes seleccionados. El código de dominio tardará el mismo tiempo en completarse. Sin embargo, el código de plataforma tardará más tiempo en ejecutarse porque debe procesar una cantidad de datos 12 veces mayor con el registro de datos publicados comunes que con el registro predeterminado.

Purga de registros

Las opciones predeterminadas de la característica Purgar registro de Runbook Designer están configuradas para ofrecer la mejor experiencia de usuario en una implementación de Orchestrator lista para usarse. La modificación de estos valores puede cambiar las características de rendimiento del entorno, por lo que deben implementarse de forma gradual y controlada para que sea posible evaluar las repercusiones de todos los cambios.

Para obtener más información acerca de la purga automática y manual de los registros, vea la sección Purga de los registros de Runbook de Registros de Runbook.

Para crear un Runbook simple para probar el crecimiento del registro, puede utilizar la actividad estándar Comparar valores para crear puntos de referencia de un entorno de Orchestrator.

El procedimiento siguiente crea un Runbook simple que ejecuta la actividad Comparar valores unas 10 000 veces. La actividad Comparar valores es una actividad muy simple cuyo código de dominio es muy reducido. Puede invocar este Runbook en multitud de circunstancias para caracterizar el rendimiento general de un entorno de tiempo de ejecución de Orchestrator determinado.

Para crear un Runbook que pueda usarse como punto de referencia para su entorno de Orchestrator

1. Cree un Runbook nuevo.

2. Agregue una actividad Compare Values desde la paleta Actividad estándar. Haga doble clic en la actividad para configurarla.

3. Haga clic en la pestaña General y configure esta actividad para comparar cadenas (valor predeterminado).

4. Haga clic en la pestaña Detalles, escriba el valor STRING en el cuadro Prueba y seleccione está vacío.

5. Haga clic en Finalizar para guardar las actualizaciones realizadas en la actividad.

6. Haga clic con el botón secundario en la actividad y seleccione Bucle.

7. Active la casilla Habilitar y escriba el número 0 (cero) para Intervalo entre intentos.

8. Haga clic en la pestaña Salir.

9. Cambie la condición de salida predeterminada. Haga clic en Comparar valores, active la casilla Mostrar datos publicados comunes y seleccione Bucle: número de intentos. Haga clic en Aceptar para guardar este cambio.

10. Seleccione valor en la condición de salida actualizada y escriba el número 10000 (diez mil). Haga clic en Aceptar para guardar este cambio.

11. Haga clic en Finalizar para guardar estas actualizaciones.

12. Haga clic en Registrar para guardar los cambios realizados en la base de datos de Orchestrator.

Este Runbook puede utilizarse para probar diferentes configuraciones de Orchestrator. Por ejemplo, puede crear Runbooks de punto de referencia para determinar el rendimiento de cuatro servidores de Runbooks implementados en distintos centros de datos.

Tenga en cuenta la importante disminución del rendimiento de la plataforma provocada por el registro de los datos publicados comunes. El peor escenario parece ser el registro de los datos publicados comunes en la ubicación 2. Aparentemente, parece ser una conclusión clara y relevante.

Sin embargo, debe tenerse en cuenta que estas cifras reflejan la sobrecarga del código de la plataforma, no del código de dominio. Los tiempos de ejecución del código de dominio pueden ser mucho mayores. Por ejemplo, la ejecución de la actividad Crear VM desde plantilla del Paquete de integración de Virtual Machine Manager puede llevar varios minutos mientras se crea la máquina virtual. Analizando el ejemplo anterior con más detalle, veamos los costes de código de plataforma de una actividad de Runbook cuya ejecución lleva 1 minuto (1 minuto = 60 000 milisegundos) sin tener en cuenta la ubicación.

Estos datos parecen mostrar una imagen más clara. El escenario en el que está habilitado el registro de datos publicados comunes en la Ubicación 2 sigue siendo el que muestra peor rendimiento. Sin embargo, el código de plataforma y el registro solo representan el 6 % del tiempo de ejecución total. Aunque esta es una cifra importante, en el mejor de los escenarios representa un 1,4 %. En general, el tiempo empleado en el código de dominio en el ejemplo anterior supera con creces el tiempo invertido en la ejecución del código de plataforma. Analizando estos datos con perspectiva, si fuese posible eliminar los costes de código de plataforma, solo se apreciaría una mejora del rendimiento del Runbook entre un 1,4 y un 7,4 %.

La situación para la mayoría de los escenarios reales será diferente. El comportamiento de la actividad puede cambiar dependiendo de lo que se indique al código de dominio que debe realizar. Por ejemplo, la actividad Clonar VM desde plantilla puede tardar 1 minuto en clonar una máquina virtual desde la plantilla de servidor A, pero puede tardar 5 minutos en clonar una máquina virtual desde la plantilla de servidor B. Asimismo, es posible que los servidores de Runbooks residan en distintas redes con distintas características de rendimiento que pueden repercutir en el rendimiento del código de dominio y del registro de datos de Orchestrator.

El administrador de la base de datos de Orchestrator puede utilizar las directrices siguientes para determinar la estrategia de crecimiento del archivo de base de datos:

• En general, el tamaño de los archivos de base de datos no aumenta con cada invocación de Runbook. El tamaño de los archivos aumenta cuando los datos que contienen alcanzan un cierto límite máximo configurado por el administrador de la base de datos, momento en el que aumentará el tamaño del archivo.

• Cada vez que se ejecuta una actividad de Runbook, esta se cuenta de forma individual, aspecto que debe tenerse en cuenta al utilizar características de bucle, ya que puede provocar que una actividad se ejecute varias veces.

• Para determinar el almacenamiento necesario para cada invocación del Runbook, multiplique el número de actividades del Runbook por el número de bytes agregados a la base de datos en función del nivel de registro seleccionado. Los valores son los siguientes:

  • 524 bytes

    Configuración de registro predeterminado.

  • 6.082 bytes

    Nivel de registro de datos publicados comunes.

  • 6082 bytes + datos registrados por actividad

    Nivel de registro de datos publicados según la actividad.

• De forma predeterminada, Orchestrator purga todos los registros, excepto los 500 más recientes para cada Runbook cada noche a las 2:00. Para determinar el almacenamiento necesario para cada invocación del Runbook, multiplique el almacenamiento necesario para cada invocación del Runbook por 500. Si cambia la configuración de purga de registro, multiplique cada invocación por el número estimado de invocaciones por día, semana o mes según sea necesario.

La tabla siguiente muestra las estimaciones de rendimiento y crecimiento de las distintas configuraciones de registro.

Ejemplo 1

La tabla siguiente describe las consideraciones de tamaño de la base de datos para una implementación de Orchestrator.

Los tamaños de base de datos descritos anteriormente permiten estimar los requisitos de almacenamiento de los Runbooks.

Este ejemplo muestra claramente la importancia de tomar decisiones acertadas en lo referente al registro de datos. El Runbook 4 contiene solo ocho actividades, aunque cuando se configura con el nivel de registro de datos publicados comunes, consume la mayoría del almacenamiento de la base de datos debido a su elevada frecuencia de invocaciones. A la luz de estos resultados, es posible que prefiera reducir el nivel de registro del Runbook 4 a la configuración de registro predeterminado.

Ejemplo 2

La tabla siguiente describe las consideraciones de tamaño de la base de datos para otra implementación de Orchestrator.

Al volver a calcular las cifras de almacenamiento para la configuración actualizada se obtienen resultados muy distintos.

Aunque hay muy pocos cambios en la configuración de registro predeterminado (500 entradas de registro por Runbook), sí que se aprecian importantes cambios en los requisitos de almacenamiento para 30 días. Es necesario prestar atención al coste del almacenamiento del registro de datos publicados comunes en el Runbook 4, ya que este cambio supone una reducción del 76 % de los requisitos de almacenamiento de la base de datos para un periodo de 30 días.

Utilice las directrices siguientes para administrar el rendimiento y el tamaño de la base de datos:

• Habilite el registro de datos publicados comunes solo si es necesario.

• Recuerde que el número de veces que se ejecutan las actividades determina el volumen de los datos registrados. Un Runbook de tamaño reducido con pocas actividades ejecutadas varias veces puede implicar el registro de un volumen de datos mayor que un Runbook de gran tamaño que se ejecute pocas veces.

• No habilite el registro de datos publicados según la actividad en entornos de producción, ya que esta opción solo debe usarse con fines de depuración.

• Desarrolle una perspectiva del tiempo que emplearán los Runbooks en ejecutar el código de dominio en comparación con la ejecución del código de plataforma.

• Estime los costes de código de plataforma mediante las técnicas descritas en este documento. Utilice estas estimaciones como referencia para realizar mejoras en el rendimiento del Runbook.

• Identifique las oportunidades de mejora mediante comparaciones normalizadas de las mediciones.

Registros de Orchestrator
Registros de Runbook
Arquitectura de Orchestrator