Alta disponibilidad y resistencia para proyectos de Microsoft Foundry y servicios de agente (clásico)

Visualización actual:Versión - Cambio a la versión del nuevo portal de Foundry

Planee con antelación para mantener la continuidad empresarial y prepararse para la recuperación ante desastres con Microsoft Foundry.

Microsoft se esfuerza por asegurarse de que los servicios de Azure estén siempre disponibles. Sin embargo, pueden producirse interrupciones de servicio no planeadas. Este artículo le guía a través de la configuración de implementaciones multirregionales, el endurecimiento de los recursos de infraestructura, el diseño de la resiliencia de la implementación de modelos y la preparación de procedimientos de conmutación por error para proyectos de Foundry y Agent Services.

Requisitos previos

• Una suscripción Azure. Si no tiene una, cree una cuenta gratuita.
• Una cuenta y un proyecto de Microsoft Foundry. Para obtener más información, consulte el inicio rápido de Microsoft Foundry.
• CLI de Azure instalado (opcional, para aplicar bloqueos de recursos a través de la línea de comandos).
• Roles adecuados de RBAC:
  • Propietario o colaborador en el grupo de recursos para implementar y configurar recursos.
  • Administrador de acceso de usuario para asignar roles de RBAC a identidades administradas.
  • Operador de Cosmos DB para la configuración de Azure Cosmos DB.
  • Search Service Contributor para la configuración de Búsqueda de Azure AI.
  • Storage Account Contributor para la configuración de Azure Storage.

Identificación de servicios de Azure para Foundry

Foundry es un servicio nativo Azure con menos dependencias implícitas que el modelo de área de trabajo anterior. Los proyectos de Foundry pueden adjuntar recursos basados en patrones de carga de trabajo, como la recuperación, orquestación, supervisión e integración. Trate los recursos adjuntos como opcionales a menos que la carga de trabajo las requiera.

Las categorías de servicio incluyen:

• Infraestructura de plataforma (gestionada por Microsoft): componentes del servicio de metadatos de proyecto y del plano de control gestionados por Microsoft regionalmente.
• Recursos de integración y carga de trabajoopcionales (administrados por el cliente): Azure Storage, Azure Key Vault, Azure Container Registry (ACR), Application Insights, Azure Logic Apps, Azure Functions, Búsqueda de Azure AI, Azure Cosmos DB, Azure Event Grid, SharePoint, Microsoft Purview (conexión explícita) y otros destinos de conexión.
• Connections: objetos de configuración que hacen referencia a servicios Azure o SaaS externos. Usted es responsable de la configuración de alta disponibilidad de ellos.

Ninguno de estos recursos opcionales, como Key Vault, Storage, ACR y Application Insights, son dependencias difíciles del propio modelo de recursos foundry, aunque la solución podría requerirlos. Diseñe por carga de trabajo y evite asumir un conjunto obligatorio fijo.

En el resto de este artículo se explica cómo hacer que cada componente sea de alta disponibilidad.

Prevención de desastres y pérdida de datos

La prevención es la defensa principal contra interrupciones. Aplique estas recomendaciones para reducir la probabilidad de incidentes y la resistencia de diseño en la carga de trabajo. Para obtener más información, consulte Diseño para resistencia.

Impedir la eliminación de recursos

Para evitar la mayoría de las eliminaciones accidentales, aplique bloqueos de eliminación a los recursos críticos. Los bloqueos protegen contra la eliminación a nivel de recurso, pero no a las operaciones en el plano de datos. Aplicar bloqueos de eliminación a estos recursos.

En la tabla siguiente se describen las protecciones y limitaciones de cada recurso:

Para obtener resistencia en profundidad, combine bloqueos de recursos con el efecto Azure Policy denyAction para bloquear las solicitudes de eliminación del proveedor de recursos. Este enfoque en capas refuerza la protección independientemente de las funcionalidades de recuperación de cada recurso.

El siguiente comando CLI de Azure aplica un bloqueo de eliminación a una cuenta de Foundry:

az lock create \
  --name "FoundryAccountLock" \
  --lock-type CanNotDelete \
  --resource-group "<your-resource-group>" \
  --resource-name "<your-foundry-account>" \
  --resource-type "Microsoft.CognitiveServices/accounts"

Para comprobar que se aplicó el bloqueo:

az lock list --resource-group "<your-resource-group>" --output table

La salida esperada muestra el nombre de bloqueo y el tipo de los recursos.

Referencia:az lock create

Implementación del acceso con privilegios mínimos

Utilizar el control de acceso basado en roles (RBAC) de Azure para limitar el acceso a los planos de control y datos. Conceda solo los permisos necesarios y audítelos periódicamente.

En producción, no conceda permisos de eliminación permanente en estos recursos a ningún principal. Para el acceso a los almacenes de estado en el plano de datos, solo la identidad administrada del proyecto debe tener permisos constantes de escritura.

También puede destruir los datos a través de las API REST del servicio de agente. Los roles de IA integrados, como Usuario de Azure AI, pueden eliminar datos operativos a través de estas API o el portal de Foundry. Los accidentes o el abuso de estas API pueden crear necesidades de recuperación. Ningún rol de IA integrado es de solo lectura para estas operaciones del plano de datos. Para obtener más información, consulte la referencia de la API REST de Fundición de IA de Azure. Cree roles personalizados para limitar el acceso a estas Microsoft.CognitiveServices/*/write acciones de datos.

Implementación del principio de responsabilidad única

Dedique su cuenta de Azure Cosmos DB, su servicio de Búsqueda de Azure AI y su cuenta de Azure Storage exclusivamente al servicio de agente de IA de la carga de trabajo. Compartir estos recursos con otras cuentas de Foundry o componentes de carga de trabajo aumenta el riesgo a través de superficies de permisos más amplias y un radio de explosión mayor. Las operaciones no relacionadas de una carga de trabajo nunca deben quitar o dañar el estado del agente en otra carga de trabajo. Esta separación también le permite tomar decisiones de recuperación por carga de trabajo sin necesidad de adoptar un enfoque de todo o nada.

Uso de configuraciones con redundancia de zona

Use configuraciones con redundancia de zona para la cuenta de Azure Cosmos DB, el servicio Búsqueda de Azure AI y la cuenta de Azure Storage. Esta configuración protege contra errores de zona dentro de una región. Las configuraciones con redundancia de zona no protegen contra interrupciones regionales completas o errores de automatización o humanos. Los componentes hospedados por Microsoft del servicio de agentes son redundantes por zona.

Configuración de recursos para admitir la recuperación

Configure estos recursos antes de que se produzca un incidente. En los pasos de recuperación de esta guía se supone que ha aplicado la siguiente configuración.

Referencias:

• Azure Cosmos DB alta disponibilidad
• confiabilidad del servicio Búsqueda de Azure AI
• Azure Storage redundancia

Modos de implementación y implicaciones de recuperación

En Modo de implementación estándar, hospeda el estado del agente en sus propias cuentas de Azure Cosmos DB, Búsqueda de Azure AI y Azure Storage. Esta topología aumenta el riesgo de incidentes (por ejemplo, eliminación directa de datos), pero proporciona control sobre los procedimientos de recuperación. El modo básico proporciona casi ninguna capacidad de recuperación para la pérdida de recursos de origen humano o automatizado.

Uso de identidades administradas asignadas por el usuario

Cuando un componente usa una identidad administrada para acceder a una dependencia, conceda a esa identidad las asignaciones de roles necesarias. Con una identidad administrada asignada por el sistema, recrear el recurso defectuoso genera un nuevo identificador principal. A continuación, debe volver a aplicar todas las asignaciones de roles en cada dependencia y eliminar asignaciones huérfanas. Algunas dependencias pueden ser propiedad de otros equipos, lo que agrega coordinación y retraso durante la recuperación.

Una identidad administrada asignada por el usuario evita este esfuerzo. Después de restaurar el recurso con errores, vuelva a adjuntar la identidad administrada asignada por el usuario existente. Las asignaciones de roles existentes siguen siendo válidas.

Uso de técnicas de implementación repetibles

Defina la cuenta, los proyectos, el host de funcionalidad y las dependencias de la infraestructura como código (IaC), como Bicep o Terraform. Algunos pasos de recuperación requieren volver a implementar recursos exactamente como estaban. Trate IaC como la fuente de la verdad para reproducir rápidamente la configuración y las asignaciones de roles. Compile su iaC modular para que pueda implementar cada proyecto de forma independiente.

Hacer que los agentes sean reimplementables. En el caso de los agentes efímeros, el código de aplicación existente suele ser suficiente. En el caso de los agentes de larga duración, almacene sus definiciones JSON y los enlaces de conocimiento o herramientas en el control de código fuente y automatice la implementación a través de llamadas de canalización a las API de Foundry. Actualice automáticamente la configuración de cliente para los nuevos identificadores de agente. Este proceso rehidrata las definiciones de agente, los archivos de conocimiento y las conexiones de herramientas.

Evite los cambios sin seguimiento realizados directamente en el portal de Foundry o el portal de Azure. Los cambios de producción sin seguimiento hacen que la recuperación sea más lenta y propensa a errores.

Si aún opta por identidades asignadas por el sistema (contrariamente a la recomendación de usar identidades administradas asignadas por el usuario), diseñe la Infraestructura como Código (IaC) para recrear, en lugar de modificar, cada asignación de roles que haga referencia al ID principal del proyecto. El ID principal en las asignaciones de roles es inmutable y no se puede cambiar a un nuevo valor. Use una guid() expresión que incorpore el identificador principal para que una identidad regenerada genere un nombre de asignación de roles distinto.

El siguiente fragmento de código de Bicep muestra una plantilla mínima para Cosmos DB con copia de seguridad continua y un bloqueo de recursos. Amplíe esta plantilla con Búsqueda de Azure AI, Azure Storage (GZRS) y asignaciones de roles para la identidad administrada.

param location string = resourceGroup().location
param cosmosDbName string

resource cosmosDb 'Microsoft.DocumentDB/databaseAccounts@2024-05-15' = {
  name: cosmosDbName
  location: location
  properties: {
    databaseAccountOfferType: 'Standard'
    locations: [
      { locationName: location, failoverPriority: 0, isZoneRedundant: true }
    ]
    backupPolicy: {
      type: 'Continuous'
      continuousModeProperties: { tier: 'Continuous7Days' }
    }
  }
}

resource lock 'Microsoft.Authorization/locks@2020-05-01' = {
  name: '${cosmosDbName}-lock'
  scope: cosmosDb
  properties: {
    level: 'CanNotDelete'
    notes: 'Protect Cosmos DB from accidental deletion.'
  }
}

Minimizar el tratamiento de Búsqueda de Azure AI como almacén de datos principal

Búsqueda de Azure AI está diseñado para contener una representación derivada optimizada para consultas de contenido autorizado almacenado en otro lugar. No confíe en él como la única ubicación de los recursos de conocimiento. Durante la recuperación, debe ser capaz de reconstruir agentes que referencian conocimientos basados en archivos, ya sea en el entorno de producción o en el de recuperación.

Por lo general, los archivos cargados por el usuario adjuntos dentro de los subprocesos de conversación no se pueden recuperar porque no están registrados ni se conservan fuera del contexto del subproceso. Establezca las expectativas de que estos datos adjuntos son transitorios y se pierden en un desastre.

Copia de seguridad y restauración de datos del agente

La durabilidad del historial de subprocesos de conversación depende de los almacenes de estado subyacentes en el modo Estándar: la base de datos de Cosmos DB enterprise_memory, los índices de Búsqueda de Azure AI, y los blobs de almacenamiento para datos adjuntos. No hay ninguna característica integrada de exportación o importación con un solo clic para historiales de conversación completos.

Copia de seguridad de definiciones de agente

Almacene las definiciones JSON del agente y las referencias de origen de conocimiento en el control de código fuente. Use la API REST de Foundry para exportar periódicamente las configuraciones del agente:

1. Enumere los agentes mediante una llamada a la API de agentes para recuperar identificadores de agente, nombres, enlaces de herramientas y configuraciones de origen de conocimiento.
2. Guarde cada definición de agente como un archivo JSON en el sistema de control de versiones.
3. Incluya enlaces de herramientas, referencias a archivos de conocimiento y configuraciones de conexión junto con cada definición de agente.
4. Automatice este proceso en una canalización de CI/CD según una programación normal (por ejemplo, diaria o después de cada implementación).

Restaurar desde una copia de seguridad de Cosmos DB en un punto en el tiempo

Si la enterprise_memory base de datos o sus contenedores se eliminan accidentalmente:

1. Abra el portal Azure y vaya a la cuenta de Cosmos DB.
2. Seleccione Restauración a un momento dado y elija una marca de tiempo de restauración antes de que se haya producido la eliminación.
3. Especifique un nuevo nombre de cuenta de destino para los datos restaurados.
4. Una vez completada la restauración, actualice la conexión del servicio Foundry Agent para que apunte a la cuenta de Cosmos DB restaurada.
5. Compruebe la funcionalidad del agente mediante la ejecución de una conversación de prueba en el entorno restaurado.

También puede iniciar una restauración mediante el CLI de Azure:

az cosmosdb restore \
  --account-name <source-account-name> \
  --target-database-account-name <restored-account-name> \
  --restore-timestamp "2026-01-15T10:00:00Z" \
  --location <region> \
  --resource-group <resource-group>

Conservar los datos de cumplimiento

Conéctese a Microsoft Purview para conservar los metadatos de linaje y clasificación, incluso si se pierden los datos de subprocesos operativos. Esto garantiza que las funcionalidades de eDiscovery y auditoría sobrevivan a un desastre.

Reconstrucción de índices de Búsqueda de Azure AI

Si el servicio de Búsqueda de Azure AI se pierde o está dañado, recompile los índices de los orígenes de datos autoritativos:

1. Cree un nuevo servicio Búsqueda de Azure AI en la región de recuperación o use el servicio secundario que aprovisionó en la implementación multirregional.
2. Vuelva a crear definiciones de índice a partir de las plantillas de IaC o los archivos de esquema controlados por código fuente.
3. Vuelva a rellenar los índices mediante la ejecución de la canalización de ingesta de datos en los orígenes de datos originales (por ejemplo, Azure Blob Storage, Azure SQL Database o Cosmos DB).
4. Actualice las referencias del origen de conocimiento del agente para que apunten al nuevo punto de conexión del servicio de búsqueda.
5. Compruebe la integridad del índice ejecutando consultas de búsqueda representativas y comparando los resultados con las líneas base conocidas.

Planear la implementación multirregional

Una implementación multirregional se basa en la creación de recursos de Foundry y otra infraestructura en dos regiones de Azure. Si se produce una interrupción regional, cambie a la otra región. Cuando planee dónde implementar los recursos, tenga en cuenta lo siguiente:

• Disponibilidad regional: si es posible, use una región en el mismo área geográfica, no necesariamente la más cercana. Para comprobar la disponibilidad regional de Foundry, consulte Azure productos por región.

• Azure regiones emparejadas: las regiones emparejadas coordinan las actualizaciones de la plataforma y priorizan los esfuerzos de recuperación cuando sea necesario. Sin embargo, no todas las regiones están emparejadas. Para obtener más información, consulte regiones pares de Azure.

• Disponibilidad del servicio: decida si se debe usar caliente/caliente, caliente/templado, o caliente/frío para los recursos de la solución.

  • Caliente/caliente: ambas regiones están activas al mismo tiempo y ambas están listas para uso inmediato.
  • Caliente/cálido: la región primaria está activa. La región secundaria tiene recursos críticos (por ejemplo, modelos implementados) listos para iniciarse. Implemente recursos no críticos manualmente en la región secundaria.
  • Caliente/frío: la región primaria está activa. La región secundaria tiene Foundry y otros recursos implementados, junto con los datos necesarios. Implemente recursos como modelos, implementaciones de modelos y canalizaciones manualmente.

En la tabla siguiente se muestran los objetivos de recuperación aproximados para cada estrategia. Los valores reales dependen del tamaño de la implementación, los servicios en uso y la configuración de replicación de datos.

Foundry se basa en otros servicios. Algunos servicios se replican en otras regiones. Debe crear manualmente otros servicios en varias regiones. En la tabla siguiente se enumeran los servicios, que son responsables de la replicación y una introducción a la configuración:

Use estos procedimientos de desarrollo para habilitar la recuperación rápida y el reinicio en la región secundaria:

1. Use plantillas de Azure Resource Manager. Las plantillas son infraestructura como código y permiten implementar rápidamente servicios en ambas regiones.
2. Para evitar el desfase entre las dos regiones, actualice las canalizaciones de integración e implementación continuas para implementarlas en ambas regiones.
3. Cree asignaciones de roles para los usuarios de ambas regiones.
4. Cree recursos de red como Azure redes virtuales y puntos de conexión privados para ambas regiones. Asegúrese de que los usuarios pueden acceder a ambos entornos de red. Por ejemplo, configure VPN y DNS para ambas redes virtuales.

Diseño para alta disponibilidad

Configuración de zonas de disponibilidad

Algunos servicios Azure admiten zonas de disponibilidad. En regiones que admiten zonas de disponibilidad, si se produce un error en una sola zona, los servicios configurados para la redundancia de zona siguen funcionando. Los servicios que no tienen redundancia de zona pueden experimentar interrupciones. Los componentes hospedados por Microsoft del servicio de agentes son redundantes por zona. Compruebe que las dependencias administradas por el cliente (Cosmos DB, AI Search, Storage) también están configuradas para la redundancia de zona.

Infórmate más en servicios de soporte de zonas de disponibilidad.

Implementación de componentes críticos en varias regiones

Decida qué nivel de continuidad empresarial necesita. El nivel puede diferir entre los componentes de la solución. Por ejemplo, puede usar una configuración caliente/caliente para canalizaciones de producción o implementaciones de modelos, y caliente/frío para el desarrollo.

Foundry es un servicio regional que almacena datos en el lado del servicio y en una cuenta de almacenamiento de la suscripción. Si se produce un desastre regional, no se pueden recuperar los datos del servicio. Puede recuperar los datos que almacena el servicio en la cuenta de almacenamiento de la suscripción si está habilitada la redundancia de almacenamiento. Los datos del lado del servicio son principalmente metadatos como etiquetas, nombres de recursos y descripciones. Los datos de la cuenta de almacenamiento normalmente no son metadatos, como los datos cargados.

Para las conexiones que son esenciales para la continuidad empresarial:

1. Cree dos recursos independientes en dos regiones diferentes (por ejemplo, dos recursos de AI Services).
2. Cree dos conexiones de proyecto, una para cada recurso regional.
3. Compruebe que ambas conexiones están activas y accesibles desde la aplicación.
4. Implemente recursos para cualquier proyecto crítico para la empresa en ambas regiones.

Aislamiento del almacenamiento de grandes conjuntos de datos

Si conecta datos para personalizar la aplicación de IA, puede usar conjuntos de datos en Azure IA y fuera de Azure AI. El volumen del conjunto de datos puede ser grande, por lo que mantener estos datos en una cuenta de almacenamiento independiente para limitar el radio de explosión y simplificar la replicación.

1. Cree una cuenta de almacenamiento dedicada para los conjuntos de datos grandes, independientes del almacenamiento principal del proyecto.
2. Evalúe la estrategia de replicación de datos (LRS, GRS, GZRS) que tenga más sentido para los requisitos de recuperación.
3. En el portal de Foundry, cree una conexión a la cuenta de almacenamiento de datos. Si tiene varias instancias de Foundry en regiones diferentes, puede asociar la misma cuenta de almacenamiento. Las conexiones funcionan entre regiones.

Monitoreo para la detección temprana de interrupciones

Configure la supervisión y las alertas para que el equipo detecte la degradación regional antes de que afecte a las cargas de trabajo de producción:

1. Habilite alertas de Azure Service Health para todos los servicios de Azure en su carga de trabajo de Foundry. Service Health proporciona aviso previo del mantenimiento planeado y la advertencia temprana de interrupciones no planeadas.
2. Configurar alertas de estado de recursos para Cosmos DB, Azure OpenAI y cuentas de Storage para detectar fallos en los recursos individuales.
3. Configura las pruebas de disponibilidad de Application Insights para sondear continuamente los puntos de conexión del agente desde varias ubicaciones geográficas.
4. Defina grupos de acciones de alerta que notifiquen a su equipo de operaciones por correo electrónico, SMS o a través de su sistema de gestión de incidencias, de manera que las decisiones de conmutación se puedan tomar rápidamente.

Configuración de la resistencia de implementación de modelos

Las implementaciones de modelos de Azure OpenAI constituyen un componente crítico de la mayoría de las cargas de trabajo de Foundry. Diseñe la topología de implementación para lograr resistencia para que una restricción de capacidad o interrupción regional no desconecte la aplicación. En esta sección se tratan las estrategias de implementación estándar y aprovisionadas, los patrones de puerta de enlace de API y la infraestructura auxiliar que los vincula.

Configuración de implementaciones estándar

Las implementaciones estándar ofrecen la ruta de acceso más sencilla a la resistencia, ya que las opciones Zona de datos y Estándar global distribuyen automáticamente las solicitudes entre varias regiones.

Use el siguiente enfoque para las implementaciones estándar:

1. Por defecto, se debe configurar despliegues en la Zona de Datos (opciones de EE. UU. o UE).
2. Implemente dos recursos de Azure OpenAI en la misma suscripción de Azure. Coloca un recurso en tu región preferida y el otro en la región secundaria (de respaldo). Azure OpenAI asigna cuota al nivel de suscripción más región, por lo que ambos recursos pueden compartir una suscripción sin que se vea afectada la cuota.
3. Cree una implementación para cada modelo que planee usar en la región primaria y duplique esas implementaciones de modelos en la región secundaria. Asigne la cuota disponible completa en cada implementación estándar. La asignación completa proporciona un mayor rendimiento en comparación con la división de la cuota entre varias implementaciones.
4. Seleccione la región de implementación en función de la topología de red. Puede implementar un recurso de Azure OpenAI en cualquier región admitida y, a continuación, crear un punto de conexión privado para ese recurso en una región más cercana a la aplicación.
   • Una vez que el tráfico entra en el límite de Azure OpenAI, el servicio optimiza el enrutamiento y procesamiento a través de los recursos informáticos disponibles en la zona de datos.
   • El enrutamiento de zona de datos es más eficaz y sencillo que el equilibrio de carga autoadministrado en varias implementaciones regionales.
5. Si una interrupción regional hace que la implementación principal sea inaccesible, enrute el tráfico a la implementación secundaria en la región pasiva dentro de la misma suscripción.
   • Dado que tanto la principal como la secundaria son implementaciones de zona, se extraen del mismo grupo de capacidad de zona en todas las regiones disponibles de la zona. La implementación secundaria protege contra que el punto de conexión principal de Azure OpenAI no esté accesible.
   • Use una puerta de enlace de IA generativa que admita el balanceo de carga y el patrón de interruptor de circuito, como Azure API Management, delante de los puntos de conexión de Azure OpenAI para minimizar la interrupción durante una interrupción regional.
   • Si se agota la cuota de una suscripción determinada, implemente una nueva suscripción de la misma manera y coloque su punto de conexión detrás de Generative AI Gateway.

Configuración de implementaciones aprovisionadas

Las implementaciones de la unidad de rendimiento aprovisionada (PTU) garantizan una capacidad dedicada para cargas de trabajo críticas o sensibles a la latencia. Combine un grupo de PTU empresarial con implementaciones opcionales específicas de carga de trabajo para lograr máxima flexibilidad y resistencia.

Creación de un grupo de PTU empresarial

1. Para las implementaciones aprovisionadas, cree una única implementación de PTU de zona de datos que actúa como un grupo empresarial de PTU. Use Azure API Management para administrar el tráfico de varias aplicaciones y establecer límites de rendimiento, registro, prioridad y lógica de conmutación por error.
   • Piense en el grupo PTU de la empresa como una "implementación estándar privada" que protege contra el problema del vecino ruidoso. Cuando la demanda es alta en los despliegues estándar, su organización tiene acceso garantizado y dedicado a un conjunto de capacidad que solo usted puede utilizar.
   • Este enfoque le proporciona control sobre qué aplicaciones experimentan una mayor latencia en primer lugar, lo que le permite priorizar el tráfico a aplicaciones críticas.
   • Los SLA de latencia respaldan las implementaciones aprovisionadas que hacen que sean preferibles a las implementaciones estándar para cargas de trabajo sensibles a la latencia.
   • Las implementaciones de PTU empresarial también logran mayores tasas de uso porque el tráfico se suaviza entre cargas de trabajo de aplicación, mientras que las cargas de trabajo individuales tienden a generar más picos.
2. Coloque la implantación principal de PTU de la empresa en una región diferente que su implantación principal de la Zona Estándar. Si se produce una interrupción regional, no perderá el acceso a su despliegue de PTU y al despliegue de Zona Estándar simultáneamente.

Implementaciones de PTU dedicadas a cargas de trabajo

Es posible que algunas cargas de trabajo necesiten una implementación dedicada con aprovisionamiento exclusivo. Si es así, siga estas instrucciones:

1. Cree una implementación de PTU dedicada para esa aplicación.
2. Coloque el grupo de PTU de carga de trabajo en una región diferente del grupo de PTU empresarial para protegerse frente a fallos regionales. Por ejemplo, coloque el grupo de PTU de carga de trabajo en la región A y el grupo de PTU corporativo en la región B.
3. Configure la cadena de conmutación por error para que la implementación dedicada a la carga de trabajo conmute por error primero al grupo de PTU de empresa y, a continuación, a la implementación estándar. Cuando la utilización del despliegue de carga de trabajo PTU supera el 100%, los puntos de conexión de PTU siguen atendiendo las solicitudes, manteniendo un SLA con mayor latencia para esa aplicación.

El tráfico fluye desde la aplicación hacia el despliegue de PTU dedicado al trabajo de carga. Si ese despliegue está saturado (el uso supera el 100%), el tráfico se desborda al grupo PTU de la empresa. Si el pool empresarial no está disponible, el tráfico pasa a la implementación estándar.

Esta arquitectura también permite apilar implementaciones estándar con implementaciones aprovisionadas para que pueda equilibrar el rendimiento y la resistencia. Utilice PTU para su demanda base en las cargas de trabajo y las implementaciones estándar para los picos de tráfico.

PTU gestiona la demanda base entre cargas de trabajo, mientras que los despliegues estándar manejan picos de tráfico excediendo la capacidad provisionada.

Configurar un Generative AI Gateway

Un Generative AI Gateway es un proxy inverso, normalmente Azure API Management, que se encuentra delante de los puntos de conexión de OpenAI de Azure y proporciona:

• Equilibrio de carga a través de varios puntos de conexión de Azure OpenAI.
• Patrón de cortocircuito para detectar y enrutar automáticamente los puntos de conexión no saludables.
• Limitación de velocidad y regulación para proteger los backends contra los picos de tráfico.
• Registro centralizado y observabilidad en todos los puntos de conexión del modelo.
• Enrutamiento prioritario para que las aplicaciones críticas obtengan capacidad preferente en situaciones de contención.

Las organizaciones con una presencia madura en Azure y conectividad híbrida deben utilizar el servicio a través de una red privada. Las organizaciones sin conectividad híbrida o con aplicaciones en otra nube, como GCP o AWS, pueden consumir el servicio a través de la red troncal pública Microsoft.

Infraestructura de soporte para los puntos de conexión de modelos

La infraestructura que admite la arquitectura de implementación de OpenAI de Azure debe tenerse en cuenta en el diseño de resistencia. Los componentes específicos dependen de si las aplicaciones consumen Azure OpenAI a través de Internet o a través de una red privada.

Consumo a través de la red troncal pública de Microsoft

Las organizaciones que consumen el servicio a través de la Microsoft red troncal pública deben tener en cuenta estos elementos de diseño:

1. Implemente generative AI Gateway de una manera que garantice la disponibilidad durante una interrupción regional de Azure. Si usa Azure API Management, implemente instancias de APIM independientes en varias regiones o use la función de puerta de enlace multirregional.
2. Utilice un equilibrador de carga global pública de servidor para distribuir el tráfico entre varias instancias de puerta de enlace de Generative AI en una forma activa/activa o activa/pasiva. Azure Front Door puede cumplir este rol.

Azure Front Door distribuye el tráfico entre instancias de API Management en varias regiones. Cada instancia de Azure API Management (APIM) enruta las solicitudes a los endpoints de Azure OpenAI en su región, proporcionando conmutación automática por error cuando una región deja de estar disponible.

Consumo a través de redes privadas

Las organizaciones que consumen el servicio a través de una red privada deben tener en cuenta estos elementos de diseño:

1. Implemente la conectividad híbrida para que proteja contra el error de una región de Azure. Los componentes de conectividad híbrida incluyen la infraestructura de red local y Microsoft ExpressRoute o VPN.
2. Implemente el Gateway de IA generativa para asegurar la disponibilidad durante las interrupciones regionales. Si usa Azure API Management, implemente instancias de APIM independientes en varias regiones o use la función de puerta de enlace multirregional.
3. Implemente puntos de conexión privados de Azure Private Link para cada instancia de Azure OpenAI en cada región de Azure. Para el Azure DNS privado, utilice un enfoque de DNS "split-brain" si todo el tráfico de la aplicación fluye a través de la Puerta de Enlace de IA Generativa. Este enfoque proporciona protección adicional contra un error regional. Si se requiere acceso directo fuera de la puerta de enlace, actualice los registros DNS privado manualmente durante una pérdida de región de Azure.
4. Utilice un equilibrador de carga de servidor global privado para distribuir el tráfico entre las instancias de puerta de enlace de IA generativa de forma activa/activa o activa/pasiva. Azure no proporciona un equilibrador de carga de servidor global nativo para cargas de trabajo que requieren resolución DNS privada. En lugar de un equilibrador de carga de servidor global, las organizaciones pueden implementar un modelo activo/pasivo mediante el cambio de registros DNS para el punto de conexión de la puerta de enlace generativa de IA.

Iniciar un procedimiento de conmutación automática

Cambiar al proyecto de conmutación por error

Cuando el proyecto principal no está disponible, cambie al proyecto secundario:

1. Identifique el punto de conexión y los detalles de conexión del proyecto secundario en la documentación de implementación o configuración de IaC.

2. Actualice la configuración de la aplicación para que apunte al proyecto secundario. Use variables de entorno o configuración centralizada (como Azure App Configuration) en lugar de referencias de proyecto codificadas de forma rígida para que la conmutación de regiones solo requiera un cambio de configuración:

   • Actualice la dirección URL del punto de conexión del proyecto Foundry a la región secundaria.
   • Si usa el Generative AI Gateway, compruebe que el disyuntor ya ha enrutado el tráfico a los endpoints secundarios de Azure OpenAI.
   • Actualice todas las conexiones de servicio directo (Cosmos DB, AI Search, Storage) si no se comparten entre regiones.

   # Example: switch to secondary region endpoints
   export FOUNDRY_ENDPOINT="https://<secondary-project>.cognitiveservices.azure.com"
   export AZURE_OPENAI_ENDPOINT="https://<secondary-aoai>.openai.azure.com"
   

3. Compruebe la conectividad mediante la ejecución de una solicitud de prueba en el punto de conexión del proyecto secundario.

4. Vuelva a enviar los trabajos en curso, ya que los trabajos que se ejecutan durante una interrupción del servicio no pasan automáticamente al proyecto secundario.

Foundry no sincroniza ni recupera artefactos ni metadatos entre proyectos. Si configura los proyectos primario y secundario para compartir recursos asociados con la replicación geográfica activada, algunos objetos están disponibles en el proyecto de recuperación ante fallos. Por ejemplo, ambos proyectos comparten las mismas imágenes de Docker, datastores configurados y recursos de Azure Key Vault.

Verificar la preparación para la conmutación por error

Valide periódicamente que el entorno secundario pueda controlar las cargas de trabajo de producción. Realice estos pasos de comprobación según una programación normal (por ejemplo, trimestral):

1. Confirme que el proyecto Foundry de la región secundaria, los modelos implementados y las conexiones son actuales y coinciden con la configuración de la región primaria.
2. Ejecute un agente representativo o un trabajo de canalización en el proyecto secundario para comprobar la funcionalidad de un extremo a otro, incluido el acceso a Azure Cosmos DB, Búsqueda de Azure AI y Azure Storage.
3. Valide que todas las asignaciones de roles de RBAC para identidades administradas, usuarios y entidades de servicio estén en vigor en la región secundaria.
4. Pruebe la resolución DNS y la conectividad de red, incluidos los puntos de conexión privados y las rutas de acceso VPN, desde entornos de cliente a la región secundaria.
5. Documente las brechas y actualice las plantillas de IaC o las canalizaciones de implementación para cerrarlas antes del siguiente ciclo de revisión.

Recuperación de recursos eliminados

Si elimina un proyecto y sus recursos, algunos recursos admiten la eliminación temporal y se pueden recuperar. Los proyectos no admiten la eliminación temporal, por lo que no se pueden recuperar después de la eliminación. En la tabla siguiente se muestran los servicios que admiten la eliminación temporal.

Para recuperar otros recursos de Foundry (cuentas, proyectos) después de la eliminación o purga, consulte Recuperación o purga de recursos de Foundry eliminados.

Solución de problemas comunes

Contenido relacionado

• Los acuerdos de nivel de servicio de Azure
• Azure Cosmos DB alta disponibilidad
• confiabilidad del servicio Búsqueda de Azure AI
• Azure Storage redundancia
• Azure Key Vault disponibilidad y redundancia
• Recuperación o purga de recursos de Foundry eliminados
• Guía de la pasarela de IA generativa
• Azure API Management implementación en varias regiones
• Información general de Azure Front Door
• Diseño para alta disponibilidad con ExpressRoute