Compartir a través de

Consideraciones sobre continuidad empresarial y recuperación ante desastres (BCDR) con Azure OpenAI Service

  • Artículo

Azure OpenAI está disponible en varias regiones. Cuando se crea un recurso Azure OpenAI, se especifica una región. A partir de ese momento, su recurso y todas sus operaciones permanecerán asociados a esa región de servidores Azure.

No suele ser habitual, aunque tampoco imposible, encontrar un problema de red que afecte a toda una región. Si su servicio tiene que estar siempre disponible, debe diseñarlo para que pueda conmutar por error a otra región o dividir la carga de trabajo entre dos o más regiones. Ambos enfoques requieren al menos dos cuentas de Azure OpenAI en diferentes regiones. En este artículo se proporcionan recomendaciones generales sobre cómo implementar la continuidad empresarial y recuperación ante desastres (BCDR) para las aplicaciones de Azure OpenAI.

De forma predeterminada, el Azure OpenAI Service proporciona un contrato de nivel de servicio predeterminado. Aunque la resistencia predeterminada puede ser suficiente para muchas aplicaciones, las aplicaciones que requieren altos grados de resistencia y continuidad empresarial deben seguir pasos adicionales para reforzar aún más su infraestructura del modelo.

frente a estándar

Nota:

Si puede usar implementaciones estándar globales, debe usarlas en su lugar. Las implementaciones de zona de datos son la siguiente mejor opción para las organizaciones que requieren que el procesamiento de datos se produzca completamente dentro de un límite geográfico.

  1. En Implementaciones estándar, el valor predeterminado es implementación de zona de datos (opciones de EE. UU./Europa).

  2. Debe implementar dos recursos de Azure OpenAI Service en la suscripción de Azure. Se debe implementar un recurso en la región preferida y el otro debe implementarse en la región de conmutación por error o secundaria. El Azure OpenAI Service asigna cuota a nivel de suscripción + región, de modo que puedan coexistir en la misma suscripción sin impacto en la cuota.

  3. Debe tener una implementación para cada modelo que planee usar en el recurso de Azure OpenAI Service en la región de Azure preferida y debe duplicar estas implementaciones de modelo en la región de conmutación por error o secundaria. Asigne la cuota completa disponible en su implementación estándar a cada uno de estos puntos finales. Esto proporciona la velocidad de rendimiento más alta 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 del Azure OpenAI Service en cualquier región admitida y, a continuación, crear un punto de conexión privado para ese recurso en su región preferida.

    • Una vez dentro del límite del Azure OpenAI Service, el Azure OpenAI Service optimiza el enrutamiento y el procesamiento en el proceso disponible en la zona de datos.
    • El uso de zonas de datos es más eficaz y sencillo que el equilibrio de carga autoadministrado entre varias implementaciones regionales.

  5. Si hay una interrupción regional en la que la implementación está en un estado inutilizable, puede usar la otra implementación en la región secundaria o pasiva dentro de la misma suscripción.

    • Dado que las implementaciones principales y secundarias son implementaciones de zona, se extraen del mismo grupo de capacidad de zona que se extrae de todas las regiones disponibles de la zona. La implementación secundaria protege contra el punto de conexión principal de Azure OpenAI que no es accesible.
    • Utilice una puerta de enlace de IA generativa que admita el equilibrio de carga y el patrón de disyuntor, como API Management, frente a los puntos de conexión del Azure OpenAI Service, de modo que se minimicen las interrupciones durante una interrupción regional para las aplicaciones que las consumen.
    • Si se agota la cuota dentro de una suscripción determinada, se puede implementar una nueva suscripción de la misma manera que se indicó anteriormente y su punto final se puede implementar detrás de la puerta de enlace de IA generativa.

Implementaciones aprovisionadas

Crear un grupo de PTU empresariales

  1. Para implementaciones aprovisionadas, recomendamos tener una única implementación de PTU de Data Zone (disponible el 04/12/2024) que funcione como un grupo empresarial de PTU. Puede utilizar API Management para administrar el tráfico de múltiples aplicaciones y establecer límites de rendimiento, registro, prioridad y lógica de conmutación por error.
    • Piense en este grupo de PTU empresariales como un recurso de “pago por uso privado” que protege contra el problema de vecinos ruidosos que puede ocurrir en implementaciones estándar cuando la demanda de servicio es alta. Su organización tendrá garantizado el acceso dedicado a un grupo de capacidad que solo está disponible para usted y, por tanto, independientemente de los picos de demanda de otros clientes.
    • Esto le proporciona control sobre qué aplicaciones experimentan aumentos en la latencia en primer lugar, lo que le permite priorizar el tráfico a las aplicaciones críticas.
    • Las implementaciones aprovisionadas están respaldadas por acuerdos de nivel de servicio de latencia que hacen que sean preferibles a las implementaciones estándar (de pago por uso) para cargas de trabajo sensibles a la latencia.
    • La implementación de PTU empresarial también permite tasas de utilización más altas ya que el tráfico se suaviza en las cargas de trabajo de las aplicaciones, mientras que las cargas de trabajo individuales tienden a ser más propensas a picos.
  2. Su implementación principal de PTU empresarial debe estar en una región diferente a su implementación principal de la zona estándar. Esto es así que, si se produce una interrupción regional, no se pierde el acceso a la implementación de PTU y a la implementación de zona estándar al mismo tiempo.

Implementación de PTU dedicada de carga de trabajo

  1. Es posible que algunas cargas de trabajo necesiten tener su propia implementación aprovisionada dedicada. Si es así, puede crear una implementación de PTU dedicada para esa aplicación.
  2. Las implementaciones de grupo de PTU de empresa y carga de trabajo deben protegerse frente a errores regionales. Para ello, coloque el grupo de PTU de carga de trabajo en la región A y el grupo de PTU de empresa en la región B.
  3. Esta implementación debe conmutar por error primero al grupo de PTU de empresa y, a continuación, a la implementación estándar. Esto implica que, cuando el uso de la implementación de PTU de carga de trabajo supera el 100 %, los puntos de conexión de PTU seguirán aprovisionando solicitudes, lo que permite un Acuerdo de Nivel de Servicio de mayor latencia para esa aplicación.

Diagrama de arquitectura de recuperación ante desastres.

La ventaja adicional de esta arquitectura es que permite apilar implementaciones estándar con implementaciones aprovisionadas para que pueda marcar en el nivel preferido de rendimiento y resistencia. Esto le permite usar PTU para la demanda de línea base en las cargas de trabajo y aprovechar el pago por uso para los picos de tráfico.

Diagrama de escalado aprovisionado.

Infraestructura auxiliar

La infraestructura que admite la arquitectura de Azure OpenAI debe tenerse en cuenta en los diseños. Los componentes de infraestructura implicados en la arquitectura varían en función de si las aplicaciones consumen el Azure OpenAI Service a través de Internet o a través de una red privada. En la arquitectura que se describe en este artículo se supone que la organización ha implementado una puerta de enlace de IA generativa. Las organizaciones con una superficie de Azure madura y conectividad híbrida deben consumir el servicio a través de una red privada, mientras que las organizaciones sin conectividad híbrida o con aplicaciones en otra nube, como GCP o AWS, consumirán el servicio a través de la red troncal pública de Microsoft.

Diseño para el consumo a través de la red troncal pública de Microsoft

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

  1. La instancia de puerta de enlace de IA generativa debe implementarse de forma que garantice que está disponible en caso de una interrupción regional de Azure. Si usa APIM (Azure API Management), esto se puede hacer mediante la implementación de instancias de APIM independientes en varias regiones o mediante la característica de puerta de enlace de varias regiones de APIM.

  2. Se debe utilizar un balanceador de carga de servidor global público para equilibrar la carga entre las múltiples instancias de la puerta de enlace de IA generativa de manera activa/activa o activa/pasiva. Azure FrontDoor se puede usar para cumplir este rol en función de los requisitos de la organización.

Diagrama de arquitectura de conmutación por error.

Diseño para el consumo a través de las redes privadas

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

  1. La conectividad híbrida debe implementarse de forma que proteja contra el error de una región de Azure. Los componentes de esquematización que admiten la conectividad híbrida constan de la infraestructura de red local de la organización y Microsoft ExpressRoute o VPN.
  2. La instancia de puerta de enlace de IA generativa debe implementarse de forma que garantice que está disponible en caso de una interrupción regional de Azure. Si usa APIM (Azure API Management), esto se puede hacer mediante la implementación de instancias de APIM independientes en varias regiones o mediante la característica de puerta de enlace de varias regiones de APIM.
  3. Los puntos de conexión privados de Azure Private Link deben implementarse para cada instancia del Azure OpenAI Service en cada región de Azure. Para Azure Private DNS, se puede utilizar un enfoque de DNS de cerebro dividido si todo el acceso de la aplicación al Azure OpenAI Service se realiza a través de la puerta de enlace de IA generativa para brindar protección adicional contra una falla regional. Si no es así, los registros DNS privados deberán modificarse manualmente en caso de pérdida de una región de Azure.
  4. Se debe utilizar un balanceador de carga de servidor global privado para equilibrar la carga entre las múltiples instancias de la puerta de enlace de IA generativa de manera activa/activa o activa/pasiva. Azure no tiene un servicio nativo para el equilibrador de carga de servidor global para cargas de trabajo que requieren resolución DNS privada. Para obtener información adicional sobre este tema, puede consultar esta guía no oficial: https://github.com/adstuart/azure-crossregion-private-lb. En lugar de un equilibrador de carga de servidor global, las organizaciones pueden lograr un patrón activo/pasivo alternando el registro DNS para la puerta de enlace de IA generativa.