Ajuste de tamaño y rendimiento de la base de datos

Artículo
07/10/2024

El ajuste de tamaño de la base de datos es la clave para comprender el rendimiento de System Center - Orchestrator. Los servidores de runbook, 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 de cómo administrarlos.

Dado que runbook Designer se comunica con la base de datos de Orchestrator (a través del servidor de administración), el rendimiento deficiente de la base de datos impedirá esa comunicación.

La experiencia del operador orchestrator se basa en dos componentes: la consola de orquestación y el servicio web. La consola de orquestación 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 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.

Además, aunque la consola de orquestación depende del servicio web, también tiene lógica única para su función como interfaz de usuario y 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 de 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 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 sobre todos los tipos de datos de registro, consulte Registros de Orchestrator.

Tipo de datos de registro	Ubicación en Runbook Designer	¿Administrado por purga de registro?
Registros de runbook	Pestañas Registro e Historial de registros	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 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 la 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 la plataforma y el código de dominio.

Los datos de registro generados para una actividad determinada pueden contener elementos de datos que son de un solo valor o multivalor. Cada actividad genera un único registro de datos de valor único. El código de dominio puede generar varios registros de datos de varios valores y, por tanto, es responsable de determinar lo que hace la actividad con los datos publicados comunes que ha recibido de las actividades anteriores.

Básicamente, los runbooks de Orchestrator están diseñados para pasar datos entre elementos discretos del código de dominio. Además, el código de dominio puede generar opcionalmente datos publicados específicos de la actividad.

Todos los runbooks tienen una similitud básica en que ejecutan actividades que constan de código de dominio y código de plataforma, recorren flujos de trabajo y se bifurcan. La bifurcación es 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 este subproceso encuentra una actividad de runbook cuyos vínculos requieren una rama, se crean subprocesos adicionales, uno para cada rama. Cada subproceso toma como entrada los datos publicados comunes de la actividad que creó la rama. Estos datos se correlacionan con 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 más que la bifurcación generada por la bifurcación. Esto se debe a que el código de dominio puede generar grandes cantidades de datos publicados específicos de la actividad.

Opciones de registro

La pestaña Registro de propiedades de un runbook permite almacenar opcionalmente entradas de registro. El término registro predeterminado hace referencia a tener ninguna de las dos opciones de datos publicadas seleccionadas, que equivale a 524 bytes generados para cada actividad. Las opciones de registro proporcionan 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 para cada actividad.
Datos publicados específicos de la actividad

Conjunto de datos específicos de la actividad que se crea opcionalmente mediante código de dominio.

Esta opción de registro genera 6082 bytes además de los bytes registrados por actividades específicas.

Sugerencia

Esta opción se selecciona principalmente con fines de depuración. Deje desactivado para limitar el crecimiento del registro.

La configuración de las opciones de registro puede afectar significativamente al rendimiento y aumentar el crecimiento de la base de datos. Considere el escenario en el que se ejecuta la misma actividad de runbook dos veces, primero con el registro de datos en el nivel predeterminado (no hay opciones de datos publicadas seleccionadas) y, a continuación, establezca con los datos publicados comunes seleccionados. El código de dominio debe tardar la misma cantidad de tiempo en completarse. Sin embargo, el código de la plataforma tardará más tiempo en ejecutarse porque tiene que admitir 12 veces la cantidad de 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 runbook Designer están configuradas para proporcionar la mejor experiencia de usuario para una implementación de Orchestrator lista para usar. El cambio de estos valores puede cambiar las características de rendimiento del entorno y debe implementarse gradual y alta marca de agua 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 Purgar registros de runbook.

Creación de pruebas comparativas de rendimiento

Para crear un runbook simple 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 Compare Values 10 000 veces. Comparar valores es una actividad simple cuyo código de dominio es mínimo. Este runbook se puede invocar en varias circunstancias para caracterizar el rendimiento general de un entorno en tiempo de ejecución de Orchestrator determinado.

Para crear un runbook que se pueda usar para realizar pruebas comparativas de su entorno de Orchestrator

Cree un runbook.
Agregue una actividad Comparar valores 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 derecho en la actividad y seleccione Bucle.
Active la casilla Habilitar y escriba el número 0 (cero) para Retraso 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 Proteger para guardar los cambios en la base de datos de Orchestrator.

Este runbook se puede usar para experimentar con diferentes configuraciones de Orchestrator. Por ejemplo, puede crear los runbooks de pruebas comparativas para determinar el rendimiento de cuatro servidores de Runbook implementados en diferentes centros de datos.

Centro de datos	Configuración del registro	Tiempo de ejecución del 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	3686	369	4.5
Ubicación 3	Registro predeterminado	2457	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	2654	265	3.2

Observe la disminución significativa del rendimiento de la plataforma causada por el registro de datos publicados comunes. El peor escenario parece ser el registro de datos publicados comunes en la ubicación 2. En la superficie, esto 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 el código de dominio. Los entornos de ejecución de código de dominio pueden ser más largos. Por ejemplo, la actividad Crear máquina virtual a partir de plantilla en el paquete de integración de Virtual Machine Manager puede ejecutarse durante varios minutos a medida que 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 del registro	Tiempo de ejecución del 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	3686	93.9%	6.1%
Ubicación 3	Registro predeterminado	2457	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	2654	95.6%	4,4 %

Una imagen más clara comienza a surgir de los datos. El escenario en el que el registro de datos publicados comunes está habilitado en location 2 sigue siendo el peor rendimiento. Sin embargo, el código de la plataforma y el registro solo tienen en cuenta el 6 % del tiempo de ejecución total. Aunque se trata de una cifra significativa, el escenario de mejor caso es del 1,4 %. Básicamente, el tiempo invertido en el código de dominio en el ejemplo supera mucho el tiempo empleado en ejecutar el código de la plataforma. Para poner esto en perspectiva, si pudiera eliminar completamente los costos de código de la plataforma, solo vería mejoras de 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 en función de lo que se le diga al código de dominio. 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 redes diferentes 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.

Determinar el crecimiento de la base de datos

El administrador de bases de datos de la base de datos de Orchestrator puede usar las siguientes directrices para determinar la estrategia de crecimiento de archivos de base de datos:

En general, los archivos de base de datos no aumentarán el tamaño con cada invocación de un runbook. Los archivos aumentarán cuando los datos contenidos dentro de ellos alcancen una determinada marca de agua alta configurada por el administrador de bases de datos, en cuyo momento el archivo se expandirá generalmente.
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 predeterminada.
- 6082 bytes
  
  Nivel de registro de datos publicado común.
- 6082 bytes + datos registrados por actividad
  
  Nivel de registro de datos publicado específico de la actividad.
De forma predeterminada, Orchestrator purga todos los registros más recientes de 500 registros para cada runbook por la noche a las 2:00 a. m. Para determinar el almacenamiento necesario para cada invocación del runbook, multiplique el almacenamiento necesario para cada invocación del runbook en 500. Si cambia la configuración purga de registro, multiplique cada invocación por el número estimado de invocaciones por día, semana o mes según sea necesario.

En la tabla siguiente se muestran las estimaciones de crecimiento y rendimiento de las configuraciones de nivel de registro.

Nivel de registro	Factor de crecimiento de la base de datos	Factor de rendimiento	Recomendado para producción
Valor predeterminado	1	1	Sí
Datos publicados comunes	11.6x	2,5x	Uso limitado con planeamiento
Datos publicados específicos de la actividad	Mayor que 11,6x	Mayor que 2,5x	No

Ejemplos

Ejemplo 1

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

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

Con el ajuste de tamaño de la base de datos descrito anteriormente, puede calcular los requisitos de almacenamiento de los runbooks.

Nombre del runbook	Bytes por invocación	Almacenamiento en MB Purga de registros predeterminada (500 invocaciones)	Invocaciones por mes	Almacenamiento en MB Un mes (No la purga predeterminada del registro)	% del almacenamiento de base de datos después de 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	El 83 %
		Total: 76,7 MB		Total: 839,3 MB

En este ejemplo se muestra claramente la importancia de tomar decisiones sólidas para el registro de datos. Runbook 4 contiene solo ocho actividades, pero cuando se configura en el nivel registro de datos publicados comunes, consume la mayoría del almacenamiento de la base de datos debido a la alta frecuencia de invocación. En función de estos resultados, puede que prefiera reducir el nivel de registro de Runbook 4 a la configuración de registro predeterminada.

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 del runbook	Número de actividades	Nivel de registro	Invocaciones por día
Runbook 1	50	Valor predeterminado	100
Runbook 2	25	Valor predeterminado	50
Runbook 3	12	Datos publicados comunes	24
Runbook 4	8	Valor predeterminado	500

La actualización de las cifras de almacenamiento de la configuración actualizada genera resultados significativamente diferentes.

Nombre del runbook	Bytes por invocación	Almacenamiento en MB Purga de registros predeterminada (500 invocaciones)	Invocaciones por mes	Almacenamiento en MB Un mes (No la purga predeterminada del registro)	% del almacenamiento de base de datos después de 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

Use las instrucciones siguientes para administrar el tamaño y el rendimiento 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 que se ejecutan varias veces puede dar lugar a más registro de datos que una ejecución de runbook mayor 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 comprensión de cuánto tiempo dedican los runbooks a ejecutar código de dominio en comparación con el código de plataforma en ejecución.
Calcule los costos 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.

Consulte también

Registros del orquestador.
Arquitectura de Orchestrator.

Compartir a través de