Creación de un runbook de pruebas comparativas
Importante
Esta versión de Orchestrator ha llegado al final del soporte técnico. Se recomienda actualizar a Orchestrator 2022.
Tendrá que crear una prueba comparativa de rendimiento para optimizar el rendimiento del runbook de Orchestrator. Como parte de la creación del banco de pruebas, debe analizar las actividades del runbook.
Las actividades de runbook de Orchestrator se pueden considerar como tener dos tipos distintos de código: código de plataforma y código de dominio. El término código de dominio se utiliza para identificar al código de una actividad de Runbook normalmente no asociada con la plataforma de Orchestrator en sí (con importantes excepciones como, por ejemplo, Invoke Runbooky Junction, entre otras). Por ejemplo, la actividad estándar Invoke Web Service contendría código de plataforma de Orchestrator (la canalización de la actividad), así como código de dominio único para invocar un servicio web basado en SOAP. El código de la plataforma será muy similar para la mayoría de las actividades, ya que se basa en un marco común. Sin embargo, es posible que existan importantes variaciones en el código de dominio de las distintas actividades.
Registro de datos
El registro de datos tiene un impacto importante en el rendimiento del runbook. Para comprender el rendimiento, considere dos configuraciones de registro: registro predeterminado y registro de datos publicados comunes. El registro predeterminado genera aproximadamente 524 bytes de datos que se escriben en la base de datos de Orchestrator cada vez que se ejecuta una actividad. El registro de datos publicados comunes escribe aproximadamente 6082 bytes de datos (12 veces la cantidad del registro predeterminado). Hay una diferencia notable en el rendimiento entre estos niveles de registro.
Considere el escenario en el que la misma actividad de Runbook se ejecuta dos veces: una vez con el registro de datos predeterminado y otra con el registro de datos publicados comunes habilitado. El código de dominio tardará el mismo tiempo en completarse. Sin embargo, el código de la plataforma tardará más tiempo en ejecutarse con el registro de datos publicados comunes habilitado. En general, con los datos publicados comunes habilitados, el código de plataforma tiene que registrar una cantidad de datos 12 veces mayor que con el nivel de registro predeterminado.
Los valores de comparación de actividad estándar se pueden usar para crear pruebas comparativas de un entorno de Orchestrator.
Creación de un runbook que se puede usar para realizar pruebas comparativas del entorno de Orchestrator
Siga estos pasos para crear un runbook que se pueda usar para realizar pruebas comparativas del 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 simple Runbook de una única actividad ejecutará la actividad Comparar valores 10 000 veces. La actividadComparar 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.
Este Runbook puede utilizarse para probar diferentes configuraciones de Orchestrator. Por ejemplo, supongamos que desea 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 (segundos) | ms/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 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.
| Centro de datos | Configuración de registro | Tiempo de ejecución de código de plataforma (segundos) | % 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 de rendimiento de runbook en el intervalo de 1,4 % a 7,4 %.
Por supuesto, 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, así como al rendimiento del registro de datos de Orchestrator.
En resumen:
- Tenga cuidado a la hora de tomar decisiones sobre el registro de datos publicados.
- Considere las repercusiones que tendrá el registro de datos publicados comunes. Recuerde que el número de veces que se ejecutan las actividades determina el volumen de los datos registrados. Un Runbook con pocas actividades ejecutadas muchas 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 específicos de actividad en entornos de producció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.
- Utilice las técnicas descritas en este documento para mejorar la comprensión del rendimiento relativo de los distintos entornos de tiempo de ejecución. Identifique las oportunidades de mejora mediante comparaciones normalizadas de las mediciones.
Pasos siguientes
Obtenga instrucciones paso a paso para crear runbooks en Creación y prueba de un runbook de ejemplo.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de