Rendimiento y tamaño de la base de datos

Artículo
07/18/2023

Importante

Esta versión de Orchestrator ha llegado al final del soporte técnico. Se recomienda actualizar a Orchestrator 2022.

El ajuste de tamaño de la base de datos es la clave para comprender el rendimiento de System Center - 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. Los problemas con las implementaciones de Orchestrator pueden surgir de una comprensión incompleta de los tipos de datos de la base de datos y cómo administrarlos.

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 orchestrator se basa en dos componentes: la consola de orquestación 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. Por lo tanto, el servicio web y la consola de orquestación 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 un nivel alto, 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 son un problema en el contexto del crecimiento de la base de datos porque los requisitos de almacenamiento para este tipo de datos son pequeños.

Datos de registro

Orchestrator crea diferentes tipos de datos de registro, todos los cuales se pueden ver y administrar en el runbook Designer. Los requisitos de almacenamiento de estos datos pueden variar en tamaño y pueden ser grandes.

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 seguimientos de auditoría y seguimiento. Para obtener más información acerca de los tipos de datos de registro, vea Orchestrator Logs.

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

Código de plataforma y código de dominio

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

Código de plataforma

Este es el código común compartido por la mayoría de las actividades y se usa para ejecutar tareas comunes realizadas por las actividades de Orchestrator. El código de plataforma genera datos publicados comunes.
Código de dominio

Ejecuta varias tareas específicas para las acciones de cada actividad, que normalmente no están asociadas a la propia plataforma de Orchestrator. Potencialmente, puede haber una gran variación 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, 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, consulte Opciones de registro 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 especificadas para la característica Purga de registros en el Designer runbook están configuradas para proporcionar la mejor experiencia de usuario para una implementación de Orchestrator lista para usar. Cambiar estos valores puede cambiar las características de rendimiento del entorno y debe implementarse gradualmente y con una marca de agua alta para que se pueda evaluar el efecto del cambio.

Para obtener más información sobre la purga automática y manual de registros, consulte purga de registros de runbook de purga.

Creación de puntos de referencia de rendimiento

Para crear un runbook sencillo para probar el crecimiento del registro, puede usar los valores de comparación de actividad estándar para crear pruebas comparativas de un entorno de Orchestrator.

El procedimiento siguiente crea un runbook que ejecuta una actividad Comparar valores 10 000 veces. Comparar valores es una actividad sencilla cuyo código de dominio es mínimo. Este runbook se puede invocar en varias 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

Cree un Runbook nuevo.
Agregue una actividad Compare Values desde la paleta Actividad estándar. Haga doble clic en la actividad para configurarla.
Seleccione la pestaña General y configure esta actividad para comparar cadenas (el valor predeterminado).
Seleccione la pestaña Detalles , escriba el valor STRING en el cuadro Prueba y seleccione está vacío.
Seleccione Finalizar para guardar las actualizaciones en la actividad.
Haga clic con el botón secundario en la actividad y seleccione Bucle.
Active la casilla Habilitar y escriba el número 0 (cero) para Intervalo entre intentos.
Seleccione la pestaña Salir .
Cambie la condición de salida predeterminada. Seleccione Comparar valores, active la casilla Mostrar datos publicados comunes y seleccione Bucle: Número de intentos. Seleccione Aceptar para guardar este cambio.
Seleccione el valor de la condición de salida actualizada y escriba el número 10000 (diez mil). Seleccione Aceptar para guardar este cambio.
Seleccione Finalizar para guardar estas actualizaciones.
Seleccione Check In para guardar los cambios 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.

Centro de datos	Configuración de registro	Tiempo de ejecución de código de plataforma (milisegundos)	Milisegundos por actividad	Factor de escala
Ubicación 1	registro predeterminado	819	82	1,0 (referencia)
Ubicación 1	Registro de datos publicados comunes	2012	201	2.5
Ubicación 2	registro predeterminado	1229	123	1.5
Ubicación 2	Registro de datos publicados comunes	3.686	369	4.5.
Ubicación 3	registro predeterminado	2.457	426	3.0
Ubicación 3	Registro de datos publicados comunes	4422	442	5.4
Ubicación 4	registro predeterminado	1474	147	1.8
Ubicación 4	Registro de datos publicados comunes	2.654	265	3.2

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 entornos de ejecución de código de dominio pueden ser más largos. 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. Al expandir el ejemplo anterior, considere los costos de código de la plataforma en una actividad de runbook que tarda 1 minuto en ejecutarse (1 minuto = 60 000 milisegundos) independientemente de la ubicación.

Centro de datos	Configuración de registro	Tiempo de ejecución de código de plataforma (milisegundos)	% de código de dominio	% de código de plataforma
Ubicación 1	registro predeterminado	819	98,6%	1,4%
Ubicación 1	Registro de datos publicados comunes	2012	96,7%	3,3%
Ubicación 2	registro predeterminado	1229	98,0%	2,0%
Ubicación 2	Registro de datos publicados comunes	3.686	93,9%	6,1%
Ubicación 3	registro predeterminado	2.457	95,9%	4,1%
Ubicación 3	Registro de datos publicados comunes	4422	92,6%	7,4%
Ubicación 4	registro predeterminado	1474	97,5%	2,5%
Ubicación 4	Registro de datos publicados comunes	2.654	95,6%	4,4 %

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. Para poner esto en perspectiva, si pudiera eliminar completamente los costos de código de la plataforma, solo vería mejoras en el rendimiento del runbook en el intervalo de 1,4 % a 7,4 %.

La mayoría de los escenarios reales serán diferentes. El comportamiento de la actividad puede cambiar dependiendo de lo que se indique al código de dominio que debe realizar. Por ejemplo, una actividad Clonar máquina virtual de plantilla puede tardar un minuto en clonar una máquina virtual de la plantilla de servidor A, pero tardar 5 minutos en clonar una máquina virtual de la plantilla de servidor B. Además, los servidores de Runbook pueden residir en diferentes redes con características de rendimiento diferentes, lo que puede afectar potencialmente al rendimiento del código de dominio y al rendimiento del registro de datos de Orchestrator.

Determinación del crecimiento de la base de datos

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, los archivos de base de datos no aumentarán de tamaño con cada invocación de un 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, se debe contar individualmente, que se debe tener en cuenta cuando las características de bucle pueden hacer que una sola 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 según el nivel de registro seleccionado. Estos 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.

Nivel de registro	Factor de crecimiento de la base de datos	Factor de rendimiento	Opción recomendada para la producción
Default	1	1	Sí
Datos publicados comunes	11,6 x	2,5 x	Uso limitado con la planeación
Datos publicados según la actividad	Mayor que 11,6 x	Mayor que 2,5 x	No

Ejemplos

Ejemplo 1

En la tabla siguiente se describen las consideraciones de tamaño de la base de datos para una implementación de Orchestrator.

Nombre de Runbook	Número de actividades	Nivel de registro	Invocaciones por día
Runbook 1	50	Default	100
Runbook 2	25	Default	50
Runbook 3	12	Datos publicados comunes	24
Runbook 4	8	Datos publicados comunes	500

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

Nombre de Runbook	Bytes por invocación	Almacenamiento en MB Purga de registro predeterminada (500 invocaciones)	Invocaciones por mes	Almacenamiento en MB Un mes (purga de registro distinta de la predeterminada)	% de almacenamiento de la base de datos tras 30 días
Runbook 1	26.200	12.5	3,000	74.5	9%
Runbook 2	13.100	6.2	1500	18,7	2 %
Runbook 3	72.984	34,8	720	50,1	6 %
Runbook 4	48.656	23,2	15,000	696,0	83 %
		Total: 76,7 MB		Total: 839,3 MB

Este ejemplo muestra claramente la importancia de tomar decisiones acertadas en lo referente al registro de datos. Runbook 4 contiene solo ocho actividades, pero cuando se configuran en el nivel registro de datos publicados comunes, consume la mayor parte del almacenamiento en la base de datos debido a la alta frecuencia de invocación. En función de estos resultados, es posible que prefiera reducir el nivel de registro de Runbook 4 a la configuración de registro predeterminado.

Ejemplo 2

En la tabla siguiente se describen las consideraciones de ajuste de tamaño de la base de datos para otra implementación de Orchestrator.

Nombre de Runbook	Número de actividades	Nivel de registro	Invocaciones por día
Runbook 1	50	Default	100
Runbook 2	25	Default	50
Runbook 3	12	Datos publicados comunes	24
Runbook 4	8	Valor predeterminado	500

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

Nombre de Runbook	Bytes por invocación	Almacenamiento en MB Purga de registro predeterminada (500 invocaciones)	Invocaciones por mes	Almacenamiento en MB Un mes (purga de registro distinta de la predeterminada)	% de almacenamiento de la base de datos tras 30 días
Runbook 1	26.200	12.5	3,000	74.5	37 %
Runbook 2	13.100	6.2	1500	18,7	9%
Runbook 3	72.984	34,8	720	50,1	25 %
Runbook 4	4.192	2.0	15,000	60,0	29%
		Total: 55,5 MB		Total: 203,3 MB

Aunque hay poco cambio en la configuración de registro predeterminada (500 entradas de registro por runbook), los requisitos de almacenamiento de 30 días han cambiado considerablemente. Claramente, el costo de almacenamiento del uso del registro de datos publicados comunes para Runbook 4 debe tenerse en cuenta cuidadosamente, ya que este cambio da como resultado una reducción del 76 % en los requisitos de almacenamiento de bases de datos durante 30 días de datos.

Resumen

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 pequeño con algunas actividades ejecutadas varias veces puede dar lugar a que un runbook de mayor tamaño ejecute un número menor de veces.
No habilite el registro de datos publicados específicos de la actividad en entornos de producción y solo se debe usar 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.