Conmutación por error para la continuidad empresarial y la recuperación ante desastres
Para maximizar el tiempo de actividad, planee con antelación la continuidad empresarial y prepare todo lo necesario para la recuperación ante desastres con Azure Machine Learning.
Microsoft se esfuerza por garantizar que los servicios de Azure siempre estén disponibles. Sin embargo, es posible que se produzcan interrupciones no planeadas en el servicio. Se recomienda disponer de un plan de recuperación ante desastres para abordar las interrupciones de servicio en regiones. En este artículo aprenderá a:
- Planear una implementación multirregional de Azure Machine Learning y los recursos asociados.
- Maximice las posibilidades de recuperar registros, cuadernos, imágenes de Docker y otros metadatos.
- Diseñar la alta disponibilidad para su solución.
- Iniciar una conmutación por error a otra región.
Importante
El servicio Azure Machine Learning no proporciona por sí mismo conmutación automática por error ni recuperación ante desastres. La copia de seguridad y la restauración de metadatos del área de trabajo, como el historial de ejecución, no está disponible.
En caso de que haya eliminado el área de trabajo o los componentes correspondientes por accidente, en este artículo también se proporcionan las opciones de recuperación que se admiten actualmente.
Descripción de los servicios de Azure para Azure Machine Learning
Azure Machine Learning depende de varios servicios de Azure. Algunos de estos servicios se aprovisionan en la suscripción. El usuario es responsable de la configuración de alta disponibilidad de estos servicios. Otros servicios se crean en una suscripción de Microsoft y son administrados por Microsoft.
Los servicios de Azure incluyen:
Infraestructura de Azure Machine Learning: Un entorno administrado por Microsoft para el área de trabajo de Azure Machine Learning.
Recursos asociados: recursos aprovisionados en la suscripción durante la creación del área de trabajo de Azure Machine Learning. Estos recursos incluyen Azure Storage, Azure Key Vault, Azure Container Registry y Application Insights.
- El almacenamiento predeterminado tiene datos como el modelo, los datos del registro de entrenamiento y las referencias a los recursos de datos.
- Key Vault tiene credenciales para Azure Storage, Container Registry y almacenes de datos.
- Container Registry tiene una imagen de Docker para entornos de aprendizaje e inferencia.
- Application Insights se usa para la supervisión de Azure Machine Learning.
Recursos de proceso: recursos creados después de la implementación del área de trabajo. Por ejemplo, puede crear una instancia de proceso o un clúster de proceso para entrenar un modelo de Machine Learning.
- Instancia de proceso y clúster de proceso: Entornos de desarrollo de modelos administrado por Microsoft.
- Otros recursos: Los recursos de computación que se pueden asociar a Azure Machine Learning, como Azure Kubernetes Service (AKS), Azure Databricks, Azure Container Instances y Azure HDInsight. El usuario es responsable de la configuración de alta disponibilidad de estos recursos.
Otros almacenes de datos: Azure Machine Learning puede montar otros almacenes de datos, como Azure Storage y Azure Data Lake Storage para los datos de entrenamiento. Estos almacenes de datos se aprovisionan en la suscripción. El usuario es responsable de la configuración de las opciones de alta disponibilidad. Para ver otras opciones del almacén de datos, consulte Creación de almacenes de datos.
En la tabla siguiente se muestran los servicios de Azure administrados por Microsoft y los administrados por el usuario. También se indican los servicios de alta disponibilidad, de forma predeterminada.
Servicio | Administrado por | Alta disponibilidad de forma predeterminada |
---|---|---|
Infraestructura de Azure Machine Learning | Microsoft | |
Recursos asociados | ||
Azure Storage | Los | |
Key Vault | Los | ✓ |
Container Registry | Los | |
Application Insights | Los | N/D |
Recursos de proceso | ||
Instancia de proceso | Microsoft | |
Clúster de proceso | Microsoft | |
Otros recursos de proceso, como AKS, Azure Databricks, Container Instances, HDInsight |
Usted | |
Otros almacenes de datos, como Azure Storage, SQL Database, Azure Database for PostgreSQL, Azure Database for MySQL, Sistema de archivos de Azure Databricks |
Usted |
En el resto de este artículo se describen las acciones que el usuario tiene que realizar para que cada uno de estos servicios sea de alta disponibilidad.
Planeamiento de la implementación multirregional
Una implementación multirregional se basa en la creación de Azure Machine Learning y otros recursos (infraestructura) en dos regiones de Azure. Si se produce una interrupción en una región, se puede cambiar a la otra. Cuando se plantee dónde implementar sus recursos, tenga en cuenta lo siguiente:
Disponibilidad regional: si es posible, use una región en la misma área geográfica, no necesariamente la más cercana. Para comprobar la disponibilidad por región para Azure Machine Learning, consulte los productos de Azure disponibles por región.
Regiones emparejadas de Azure: coordinan las actualizaciones de la plataforma y priorizan las iniciativas de recuperación según las necesidades. Sin embargo, no todas las regiones admiten regiones emparejadas. Para más información, consulte Regiones emparejadas de Azure.
Disponibilidad del servicio: determine si la disponibilidad de los recursos utilizados por la solución debe ser activa/activa, activa/en espera o activa/pasiva.
- activa/activa: ambas regiones están activas al mismo tiempo y una de ellas se puede empezar a usar inmediatamente.
- activa/en espera: la región primaria está activa y la secundaria tiene recursos críticos (por ejemplo, modelos implementados) preparados para iniciarse. Los recursos no críticos tendrían que implementarse manualmente en la región secundaria.
- activa/pasiva: la región primaria está activa y la región secundaria tiene el servicio Azure Machine Learning y otros recursos implementados, junto con los datos necesarios. Recursos como los modelos, las implementaciones de modelos o las canalizaciones tendrían que implementarse manualmente.
Sugerencia
En función de los requisitos de su empresa, puede optar por tratar de forma diferente los recursos de Azure Machine Learning. Por ejemplo, es posible que desee usar la configuración activa/activa para los modelos implementados (inferencia) y la configuración activa/pasiva para los experimentos (entrenamiento).
Azure Machine Learning se agrega a otros servicios. Algunos servicios se pueden configurar para la replicación en otras regiones. Otros servicios se deben crear manualmente en varias regiones. En la tabla siguiente se proporciona una lista de servicios responsables de la replicación y una descripción de la configuración:
Servicio de Azure | Replicación geográfica | Configuración |
---|---|---|
Área de trabajo de Machine Learning | Usted | Cree un área de trabajo en las regiones seleccionadas. |
Proceso de Machine Learning | Usted | Cree los recursos de proceso en las regiones seleccionadas. En el caso de los recursos de proceso escalables de forma dinámica, asegúrese de que ambas regiones proporcionen una cuota de proceso suficiente en relación con sus necesidades. |
Registro de Machine Learning | Usted | Cree el registro en varias regiones. |
Key Vault | Microsoft | Use la misma instancia de Key Vault con el área de trabajo y los recursos de Azure Machine Learning en ambas regiones. Key Vault conmuta por error de forma automática en una región secundaria. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault. |
Container Registry | Microsoft | Configure la instancia de Container Registry para que replique geográficamente los registros en la región emparejada para Azure Machine Learning. Use la misma versión para ambas instancias de área de trabajo. Para más información, consulte Replicación geográfica en Azure Container Registry. |
Cuenta de almacenamiento | Usted | Azure Machine Learning no admite la conmutación por error en la cuenta de almacenamiento predeterminada por medio del almacenamiento con redundancia geográfica (GRS), el almacenamiento con redundancia de zona geográfica (GZRS), el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) o el almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS). Cree una cuenta de almacenamiento separada para el almacenamiento predeterminado de cada área de trabajo. Cree servicios o cuentas de almacenamiento separadas para otro almacenamiento de datos. Para más información, vea Redundancia de Azure Storage. |
Application Insights | Los | Cree una instancia de Application Insights para el área de trabajo en ambas regiones. Para ajustar el período de retención de datos y los detalles consulte Recopilación, retención y almacenamiento de datos en Application Insights. |
Para acelerar la recuperación y el reinicio en la región secundaria, se recomiendan los siguientes procedimientos de desarrollo:
- Utilice plantillas de Azure Resource Manager. Las plantillas generan "infraestructura como código" y permiten implementar rápidamente servicios en ambas regiones.
- Para evitar el desvío entre las dos regiones, actualice las canalizaciones de integración e implementación continuas para que se implementen en ambas regiones.
- Cuando automatice las implementaciones, incluya la configuración de los recursos de proceso asociados al área de trabajo, como Azure Kubernetes Service.
- Cree asignaciones de rol para los usuarios de ambas regiones.
- Cree recursos de red, como las redes virtuales y los puntos de conexión privados de Azure, para ambas regiones. Asegúrese de que los usuarios tengan acceso a ambos entornos de red. Por ejemplo, las configuraciones de VPN y DNS para ambas redes virtuales.
Servicios de proceso y de datos
En función de cuáles sean sus necesidades, podrá tener más servicios de proceso o de datos para que Azure Machine Learning los utilice. Por ejemplo, puede usar Azure Kubernetes Services o Azure SQL Database. Use la siguiente información para aprender a configurar estos servicios con fines de alta disponibilidad.
Recursos de proceso
- Azure Kubernetes Service: consulte Procedimientos recomendados para continuidad empresarial y recuperación ante desastres en Azure Kubernetes Service (AKS) y Creación de un clúster de Azure Kubernetes Service (AKS) que use zonas de disponibilidad. Si el clúster de AKS se creó en el Estudio de Azure Machine Learning, el SDK o la CLI, no se admite alta disponibilidad entre regiones.
- Azure Databricks: consulte Recuperación ante desastres regional para clústeres de Azure Databricks.
- Container Instances. Un orquestador es responsable de la conmutación por error. Consulte Azure Container Instances y orquestadores de contenedores.
- HDInsight: consulte Servicios de alta disponibilidad admitidos en Azure HDInsight.
Servicios de datos
- Contenedor de Azure Blob Storage, Azure Files y Data Lake Storage Gen2: consulte Redundancia de Azure Storage.
- Data Lake Storage Gen1: Consulte Guía de alta disponibilidad y recuperación ante desastres para Data Lake Storage Gen1.
Sugerencia
Si proporciona su propia clave administrada por el cliente para implementar el área de trabajo de Azure Machine Learning, Azure Cosmos DB también se aprovisiona dentro de la suscripción. En ese caso, es responsable de configurar la configuración de alta disponibilidad. Consulte Alta disponibilidad con Azure Cosmos DB.
Diseño para lograr alta disponibilidad
Zonas de disponibilidad
Algunos servicios de Azure admiten zonas de disponibilidad. En el caso de las regiones que admiten zonas de disponibilidad, si una zona deja de funcionar cualquier pausa de carga de trabajo y se deben guardar los datos. Sin embargo, los datos no están disponibles para actualizarse hasta que la zona vuelva a estar en línea.
Para obtener más información, consulte Servicio de zona de disponibilidad y compatibilidad regional.
Implementación de componentes críticos en varias regiones
Determine el nivel de continuidad empresarial que tiene como objetivo. El nivel puede diferir entre los componentes de la solución. Por ejemplo, tal vez desee usar una configuración activa/activa para las canalizaciones de producción o las implementaciones de modelos, y una configuración activa/inactiva con fines de experimentación.
Administración de datos de entrenamiento en un almacenamiento aislado
Al mantener el almacenamiento de datos aislado del almacenamiento predeterminado que el área de trabajo usa para los registros, podrá hacer lo siguiente:
- Adjuntar las mismas instancias de almacenamiento que los almacenes de datos a las áreas de trabajo principal y secundaria.
- Aplicar la replicación geográfica a las cuentas de almacenamiento de datos y maximizar el tiempo de actividad.
Administración de recursos de aprendizaje automático como código
Nota
La copia de seguridad y la restauración de metadatos del área de trabajo, como el historial de ejecución, los modelos y los entornos no están disponibles. La especificación de recursos y configuraciones como código mediante especificaciones de YAML le ayudará a volver a crear recursos entre áreas de trabajo en caso de desastre.
Los trabajos de Azure Machine Learning se definen mediante una especificación de trabajo. Esta especificación incluye dependencias de artefactos de entrada que se administran en un nivel de instancia de área de trabajo, incluidos los entornos y el proceso. Para el envío de trabajos e implementaciones de varias regiones, se recomiendan los procedimientos siguientes:
Administre localmente el código base, con ayuda de un repositorio de Git.
- Exporte cuadernos relevantes desde Estudio de Azure Machine Learning.
- Exporte canalizaciones que se crearon como código en Estudio.
Administre las configuraciones como código.
- Evite las referencias codificadas de forma rígida al área de trabajo. En su lugar, configure una referencia a la instancia del área de trabajo mediante un archivo de configuración y utilice MLClient.from_config() para inicializar el área de trabajo.
- Use Dockerfile si tiene imágenes personalizadas de Docker.
Inicio de una conmutación por error
Continuación del trabajo en el área de trabajo de conmutación por error
Cuando el área de trabajo principal deja de estar disponible, puede cambiar al área de trabajo secundaria con fines de experimentación y desarrollo. Azure Machine Learning no envía automáticamente trabajos al área de trabajo secundaria si se produce una interrupción. Actualice la configuración del código para que apunte al nuevo recurso de área de trabajo. Se recomienda evitar la codificación rígida de las referencias al área de trabajo. En su lugar, use un archivo de configuración del área de trabajo para minimizar los pasos manuales del usuario para cambiar las áreas de trabajo. Asegúrese de actualizar también cualquier automatización, como las canalizaciones de integración e implementación continuas, en la nueva área de trabajo.
Azure Machine Learning no puede sincronizar ni recuperar artefactos o metadatos entre instancias de área de trabajo. En función de la estrategia de implementación de la aplicación, es posible que tenga que mover artefactos o volver a crear entradas de experimentación, como los recursos de datos, en el área de trabajo de conmutación por error para continuar con el envío del trabajo. Si ha configurado los recursos de las áreas de trabajo principal y secundaria para que compartan recursos asociados con la replicación geográfica habilitada, puede que algunos objetos estén disponibles directamente en el área de trabajo de conmutación por error. Este es el caso, por ejemplo, si ambas áreas de trabajo comparten las mismas imágenes de Docker, almacenes de datos configurados y recursos de Azure Key Vault. En el diagrama siguiente se muestra una configuración en la que dos áreas de trabajo comparten las mismas imágenes (1), almacenes de datos (2) y recursos de Key Vault (3).
Nota:
Cualquier trabajo que se esté ejecutando cuando se produzca una interrupción del servicio no pasarán automáticamente al área de trabajo secundaria. Además es poco probable que los trabajos se reanuden y finalicen correctamente en el área de trabajo principal una vez resuelta la interrupción. En su lugar, los trabajos se deben volver a enviar, ya sea en el área de trabajo secundaria o en la principal (una vez resuelta la interrupción).
Movilidad de artefactos entre áreas de trabajo
En función del enfoque de recuperación, es posible que tenga que copiar artefactos entre las áreas de trabajo para continuar con el trabajo. Actualmente, la movilidad de artefactos entre áreas de trabajo es limitada. Se recomienda administrar los artefactos como código siempre que sea posible para que se puedan volver a crear en la instancia de conmutación por error.
Los artefactos siguientes se pueden exportar e importar entre áreas de trabajo mediante la extensión de la CLI de Azure para el aprendizaje automático:
Sugerencia
- Las salidas de trabajos se almacenan en la cuenta de almacenamiento predeterminada asociada a un área de trabajo. Aunque las salidas de trabajo pueden quedar inaccesibles desde la interfaz de usuario de Studio en caso de una interrupción del servicio, se puede acceder directamente a los datos a través de la cuenta de almacenamiento. Para obtener más información sobre cómo trabajar con datos almacenados en blobs, consulte Creación, descarga y enumeración de blobs mediante la CLI de Azure.
Opciones de recuperación
Eliminación del área de trabajo
Si eliminó accidentalmente el área de trabajo, es posible que pueda recuperarla. Para ver los pasos de recuperación, consulta Recuperación de datos del área de trabajo tras una eliminación accidental con la eliminación temporal.
Incluso si el área de trabajo no se puede recuperar, es posible que pueda recuperar los cuadernos del recurso de almacenamiento de Azure asociado al área de trabajo si sigue estos pasos:
- En Azure Portal, vaya a la cuenta de almacenamiento vinculada al área de trabajo de Azure Machine Learning que se eliminó.
- En la sección Almacenamiento de datos que aparece a la izquierda, seleccione Recursos compartidos de archivos.
- Los cuadernos se encuentran en el recurso compartido de archivos con el nombre que contiene el identificador del área de trabajo.
Pasos siguientes
Para obtener información sobre las implementaciones de infraestructura repetibles con Azure Machine Learning, use una plantilla de Bicep o una plantilla de Terraform.