Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Automation es un servicio que ejecuta tareas de administración en su nombre. Puede definir scripts, denominados runbooks, que desea ejecutar y Azure Automation proporciona la infraestructura para ejecutar esos scripts. Este artículo se centra en la automatización de procesos, que es la funcionalidad principal del servicio. Los trabajadores de runbooks híbridos, que se ejecutan en infraestructura administrada por el cliente, quedan fuera del alcance de este artículo.
Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.
En este artículo se describe cómo hacer que Azure Automation sea resistente a diversas interrupciones y problemas potenciales, incluidos errores transitorios, interrupciones de zonas de disponibilidad, interrupciones regionales y mantenimiento del servicio. También se describen las opciones de copia de seguridad y restauración, así como información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Automation.
Recomendaciones de implementación de producción para la confiabilidad
Para cargas de trabajo de producción que usan la automatización de procesos, siga estas recomendaciones:
Controle los errores transitorios que se producen cuando los runbooks interactúan con Azure servicios y API mediante la adición de la lógica de reintento adecuada a los scripts.
Diseña tus runbooks para que sean resistentes a las interrupciones. Use puntos de control para mantener el progreso entre los reinicios del trabajo y, si necesita almacenar el estado, use el almacenamiento externo.
Introducción a la arquitectura de confiabilidad
En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.
Arquitectura lógica
Al implementar Azure Automation, se crea una cuenta de automation, que es un contenedor lógico para los recursos que ejecutan la automatización.
- Runbooks, que representan el trabajo que se va a realizar. Los runbooks textuales son scripts escritos en PowerShell o Python. Los runbooks gráficos se crean mediante un editor gráfico.
- Recursos que comparten runbooks, incluidos módulos, conexiones, credenciales, certificados y variables.
- Recursos que inician la ejecución de los runbooks, incluidas las programaciones y los observadores.
Para obtener más información sobre estos recursos, consulte Ejecución de runbooks en Azure Automation.
En este artículo se tratan la confiabilidad y resistencia de estas funcionalidades, que forman parte de la automatización de procesos en Azure Automation.
Arquitectura física
Los runbooks se ejecutan en una infraestructura informática. Existen dos modelos de implementación para la automatización de procesos:
Trabajos en la nube (Microsoft administrados): de forma predeterminada, los runbooks se ejecutan en la infraestructura de nube proporcionada por Microsoft. Microsoft es responsable de la alta disponibilidad y administración de esta infraestructura. Al enviar un trabajo de runbook, Azure Automation asigna un trabajo en la nube desde su grupo de recursos de proceso disponibles, ejecuta el runbook y, a continuación, devuelve el recurso al grupo.
A veces, es posible que los trabajos en la nube se interrumpan mientras se ejecutan. Diseñe los runbooks en la suposición de que un trabajo podría reiniciarse en una infraestructura diferente y que los datos escritos en el almacenamiento temporal en la instancia anterior ya no son accesibles.
Hybrid Runbook Workers: Opcionalmente, puede configurar su propia infraestructura de proceso (máquinas virtuales en Azure, otras nubes o locales) para ejecutar runbooks. Cuando utilice trabajadores de runbooks híbridos, es su responsabilidad configurarlos para que cumplan sus requisitos de fiabilidad. Los trabajadores de runbooks híbridos quedan fuera del alcance de este artículo.
Resistencia a errores transitorios
Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.
Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.
Eres responsable de escribir guías operativas que gestionen errores transitorios en los servicios y las API con los que interactúan. En el caso de los runbooks textuales, implemente la lógica de reintento mediante bucles y control de errores. Para obtener instrucciones y ejemplos, consulte Control de errores transitorios en un script dependiente del tiempo. En el caso de los runbooks gráficos, configure el comportamiento de reintento para las actividades de su flujo de trabajo. Para obtener detalles sobre la configuración, consulte Reintentar una actividad en runbooks gráficos.
El mantenimiento de la infraestructura u otros eventos de la plataforma pueden interrumpir los trabajos de los runbooks. Diseñe los runbooks para controlar estas interrupciones:
Implementar puntos de control. En el caso de los runbooks de flujos de trabajo de PowerShell, utiliza puntos de control para guardar el progreso en momentos clave del flujo de trabajo. Si un trabajo se interrumpe y se reinicia, puede reanudarse desde el último punto de control en lugar de volver a empezar. Para obtener más información, consulte Uso de puntos de control en un flujo de trabajo.
Comprenda los límites de las tareas. Los trabajos en la nube tienen límites de uso equitativo en cuanto a la duración de la ejecución. Para obtener más información sobre los límites de ejecución de los trabajos y cómo se aplican, consulta Ejecución de runbooks.
Almacenar el estado persistente externamente. Los trabajos no mantienen el estado entre ejecuciones. Si se interrumpe un trabajo y se reinicia en otra instancia, es posible que se pierda algo escrito en el almacenamiento temporal por la primera ejecución. Si necesita conservar los datos entre ejecuciones de trabajo, almacénelo en almacenamiento externo, como Azure Blob Storage o una base de datos.
Resistencia a errores de zona de disponibilidad
Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.
En las regiones admitidas, las cuentas de Automation y los trabajos en la nube tienen redundancia de zona, lo que significa que el servicio distribuye los recursos entre varias zonas de disponibilidad. Microsoft habilita automáticamente la redundancia de zona y no requiere ninguna configuración.
Requisitos
Compatibilidad regional: Al implementar una cuenta de automatización en una de las siguientes regiones, pasa a tener redundancia de zona automáticamente:
| Americas | Europe | Oriente Medio | Africa | Asia Pacífico |
|---|---|---|---|---|
| Brazil South | France Central | Israel Central | Norte de Sudáfrica | Australia East |
| Canada Central | Centro-oeste de Alemania | Qatar Central | Central India | |
| Central US | Norte de Italia | Norte de China 3 | ||
| Este de EE. UU. | Norte de Europa | East Asia | ||
| Este de EE. UU. 2 | Norway East | Japan East | ||
| Centro-sur de EE. UU. | Poland Central | Korea Central | ||
| Gobierno de EE.UU. de Virginia | Sweden Central | Southeast Asia | ||
| Oeste de EE. UU. 2 | UK South | |||
| Oeste de EE. UU. 3 | West Europe |
Para obtener la lista actual de regiones admitidas, consulte Compatibilidad con zonas de disponibilidad para Azure Automation.
Costo
No hay ningún cargo adicional por la redundancia de zona. En el caso de la automatización de procesos, la facturación se basa en el tiempo que se ejecutan los trabajos y los observadores. Para obtener más información, consulte precios de Azure Automation.
Configurar soporte de zonas de disponibilidad
Cuando se crea una cuenta de automatización en una región compatible, esta es automáticamente redundante por zona. No se puede deshabilitar la redundancia de zona. Para obtener más información, consulte Compatibilidad con zonas de disponibilidad para Azure Automation.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué cabe esperar cuando la cuenta de automatización es redundante por zona y todas las zonas de disponibilidad de la región están operativas.
Operación entre zonas: Las operaciones de administración de cuentas de Automation y los trabajos en la nube se distribuyen automáticamente entre zonas de disponibilidad en la región. Una solicitud o un trabajo pueden ser atendidos por cualquier instancia de cualquier zona de disponibilidad.
Replicación de datos entre zonas: La configuración de la cuenta de Automation, los scripts de runbook y otros recursos que se implementan en la cuenta de Automation se replican sincrónicamente en varias zonas de disponibilidad.
Comportamiento durante un fallo de zona
En esta sección se describe qué cabe esperar cuando su cuenta de automatización es redundante por zona y se produce una interrupción en una de las zonas de disponibilidad de la región.
- Detección y respuesta: La plataforma Azure Automation es responsable de detectar un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de la zona.
- Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: Cualquier ejecución de trabajo en curso en la zona que no funciona correctamente podría interrumpirse. Azure Automation inicia automáticamente una nueva ejecución de un trabajo utilizando infraestructura de zonas en buen estado. Diseñe los runbooks para que sean resistentes a errores transitorios e interrupciones para que puedan reiniciarse de forma segura.
Pérdida de datos prevista: Las ejecuciones de trabajos no conservan el estado, por lo que no se espera que un error de zona provoque la pérdida de datos de los trabajos en curso. Si un trabajo necesita almacenar los datos que puede usar para recuperarse de la interrupción, como puntos de control, almacene esa información en un servicio de almacenamiento en la nube persistente, como Azure Storage o una base de datos.
La configuración de la cuenta de Automation y los datos de runbook se replican entre zonas y permanecen accesibles incluso cuando una zona no está disponible.
Tiempo de inactividad esperado: Durante una interrupción de zona, la cuenta de Automation puede experimentar una breve interrupción mientras el servicio detecta el error y redistribuye la carga de trabajo a zonas correctas.
Redistribución: El servicio reequilibra automáticamente la capacidad entre las zonas restantes que funcionan correctamente. Las nuevas ejecuciones de trabajos, los observadores y las programaciones continúan ejecutándose en la infraestructura de las zonas que funcionan correctamente. La recuperación no depende de que la zona que ha fallado vuelva a estar operativa.
Recuperación de zona
Cuando una zona con error vuelve al servicio, Azure Automation vuelve a reinsertarla automáticamente en la rotación de zona. No se requiere ninguna acción de usted. El servicio supervisa el estado de la zona y redistribuye la carga de trabajo en todas las zonas a medida que se reanudan las operaciones normales.
Prueba de fallos de zona
Azure Automation administra el enrutamiento del tráfico, la conmutación por error y la recuperación de zona para los recursos con redundancia de zona. No es necesario iniciar ninguna acción ni validar los procesos ante fallos de la zona de disponibilidad. Ponga a prueba sus manuales de procedimientos para confirmar que resisten las interrupciones.
Resistencia a errores en toda la región
Azure Automation es un servicio de una sola región. Si la región deja de estar disponible, la cuenta de Automation tampoco está disponible.
Soluciones personalizadas de varias regiones para la resistencia
Puede implementar cuentas de Automation independientes en varias regiones y cambiar entre ellas cuando sea necesario. Usted es responsable de desplegar las cuentas en cada región, configurarlas de forma adecuada, distribuir las solicitudes entre las cuentas y gestionar la conmutación por error si una región no está disponible. Para obtener información detallada sobre los enfoques que puede tener en cuenta, consulte Recuperación ante desastres para Azure Automation.
Copias de seguridad y restauración
Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.
Azure Automation no proporciona copias de seguridad integradas para la configuración de la cuenta de Automation ni para el contenido del runbook. Mantenga sus propias copias fuera del servicio para que pueda volver a implementarlas si es necesario.
Utiliza infraestructura como código (IaC) para la configuración de la cuenta de automatización. Defina cuentas de automatización y recursos relacionados en archivos de Bicep, plantillas de ARM o Terraform. Almacene las plantillas en el control de versiones y use su pipeline de implementación para recrear el entorno en la misma región o en otra. Incluya certificados, variables, programaciones y referencias de credenciales en sus artefactos y procesos de despliegue. Almacene secretos en servicios como Azure Key Vault en lugar de insertar valores directamente en el código de runbook.
Almacene los scripts del runbook en un sistema de control de código fuente. Mantenga el origen de PowerShell y Python runbooks en un sistema de control de código fuente como Git. Utiliza el control de versiones, la creación de ramas y la revisión de solicitudes de incorporación de cambios para proteger la calidad de los scripts y permitir la reversión a versiones que se sabe que funcionan correctamente.
Haga una copia de seguridad del estado desde el almacén de datos correspondiente. Los trabajos no conservan el estado. Si necesita mantener registros de trabajos detallados o cualquier otro dato que generen los runbooks, almacénelo en otro servicio de almacenamiento o base de datos de Azure y realice una copia de seguridad desde allí.
Resistencia a la eliminación accidental
Si elimina accidentalmente una cuenta de Automation, es posible que pueda restaurarla dentro de un período de tiempo limitado. Para más información, consulte Restauración de una cuenta de Automation eliminada.
Resistencia al mantenimiento del servicio
Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se prevé ningún tiempo de inactividad durante las operaciones de mantenimiento, a menos que se te haya informado a través de el mantenimiento planificado de Azure Service Health.
Acuerdo de nivel de servicio
El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.