Considérations relatives à la continuité d’activité et à la récupération d’urgence (BCDR) avec Azure OpenAI dans Microsoft Modèles Foundry (classique)

S'applique uniquement à :Portail Foundry (classique). Cet article n’est pas disponible pour le nouveau portail Foundry. En savoir plus sur le nouveau portail.

Note

Les liens de cet article peuvent ouvrir du contenu dans la nouvelle documentation Microsoft Foundry au lieu de la documentation Foundry (classique) que vous affichez maintenant.

Azure OpenAI est disponible dans plusieurs régions. Lorsque vous créez une ressource OpenAI Azure, vous spécifiez une région. À partir de là, votre ressource et toutes ses opérations restent associées à cette région de serveur Azure.

Il est rare, mais pas impossible, de rencontrer un problème réseau qui touche une région entière. Si votre service doit toujours être disponible, vous devez le concevoir pour basculer vers une autre région ou fractionner la charge de travail entre deux ou plusieurs régions. Les deux approches nécessitent au moins deux ressources OpenAI Azure dans différentes régions. Cet article fournit des recommandations générales sur la façon d’implémenter la continuité d’activité et la récupération d’urgence (BCDR) pour vos applications OpenAI Azure.

Par défaut, l'Azure OpenAI fournit un contrat de niveau de service par défaut. Bien que la fiabilité par défaut soit suffisante pour de nombreuses applications, les applications nécessitant des degrés élevés de continuité d’activité doivent prendre des mesures supplémentaires pour renforcer davantage leur infrastructure de modèle.

et standard

Note

Si vous pouvez utiliser des déploiements Global Standard, vous devez les utiliser à la place. Les déploiements de Zone de données constituent la meilleure option pour les organisations nécessitant que le traitement des données se déroule entièrement dans une limite géographique.

1. Pour les déploiements Standard, la valeur par défaut est le déploiement de Zone de données (options États-Unis/Europe).

2. Vous devez déployer deux ressources OpenAI Azure dans l’abonnement Azure. Une ressource doit être déployée dans votre région préférée et l’autre doit être déployée dans votre région secondaire/de basculement. Azure OpenAI alloue le quota au niveau de l’abonnement et de la région, de sorte qu'il peut coexister dans le même abonnement sans impact sur le quota.

3. Vous devez disposer d’un déploiement pour chaque modèle que vous envisagez d’utiliser sur la ressource OpenAI Azure dans votre région de Azure préférée et vous devez dupliquer ces déploiements de modèles dans la région secondaire/de basculement. Allouez le quota complet disponible dans votre déploiement Standard à chacun de ces points de terminaison. Cela offre le taux de débit le plus élevé par rapport au fractionnement du quota entre plusieurs déploiements.

4. Sélectionnez la région de déploiement en fonction de la topologie de votre réseau. Vous pouvez déployer une ressource OpenAI Azure dans n’importe quelle région prise en charge, puis créer un point de terminaison privé pour cette ressource dans votre région préférée.

   • Une fois dans le périmètre Azure OpenAI, Azure OpenAI optimise le routage et le traitement sur les ressources de calcul disponibles dans la zone de données.
   • L’utilisation de zones de données est plus efficace et plus simple que l’équilibrage de charge auto-managé sur plusieurs déploiements régionaux.

5. S’il existe une panne régionale où le déploiement est dans un état inutilisable, vous pouvez utiliser l’autre déploiement dans la région secondaire/passive au sein du même abonnement.

   • Étant donné que les déploiements principaux et secondaires sont des déploiements de zone, ils proviennent du même pool de capacités de zone qui tire de toutes les régions disponibles dans la zone. Le déploiement secondaire protège contre le fait que le point de terminaison principal Azure OpenAI soit injoignable.
   • Utilisez une passerelle d’IA générative prenant en charge l’équilibrage de charge et le mécanisme de coupure automatique (circuit breaker), telle qu’API Management, en amont des points de terminaison Azure OpenAI, afin de minimiser l’impact d’une panne régionale sur les applications consommatrices.
   • Si le quota au sein d’un abonnement donné est épuisé, un nouvel abonnement peut être déployé de la même manière que ci-dessus et son point de terminaison déployé derrière la passerelle IA générative.

Déploiements approvisionnés

Créer un pool PTU Entreprise

1. Pour les déploiements approvisionnés, nous vous recommandons d’avoir un déploiement PTU de zone de données unique (disponible le 4 décembre 2024) qui sert de pool d’entreprises de PTU. Vous pouvez utiliser API Management pour gérer le trafic à partir de plusieurs applications pour définir des limites de débit, la journalisation, la priorité et la logique de basculement.
   • Considérez ce pool PTU d’entreprise comme une ressource « Déploiement standard privé » qui protège contre le problème des voisins bruyants qui peuvent se produire sur les déploiements Standard lorsque la demande de service est élevée. Votre organisation disposera d'un accès garanti et dédié à un pool de capacité qui n'est disponible que pour vous et est donc indépendant des pointes de demande provenant d'autres clients.
   • Cela vous permet de contrôler quelles applications subissent en premier une augmentation de latence, vous permettant ainsi de prioriser le trafic vers vos applications critiques.
   • Les déploiements provisionnés sont soutenus par des contrats SLA de latence qui les rendent préférables aux déploiements standard pour les charges de travail sensibles à la latence.
   • Le déploiement PTU Entreprise permet également d’augmenter les taux d’utilisation, car le trafic est lissé dans les charges de travail d’application, tandis que les charges de travail individuelles ont tendance à être plus sujettes aux pics.
2. Votre déploiement PTU Entreprise principal doit se trouver dans une région différente de celle de votre déploiement de zone Standard principal. C'est pourquoi, s'il existe une panne régionale, vous ne perdez pas accès à votre déploiement PTU et au déploiement de zone standard en même temps.

Déploiement PTU dédié à la charge de travail

1. Certaines charges de travail peuvent avoir besoin d’avoir leur propre déploiement provisionné dédié. Si c’est le cas, vous pouvez créer un déploiement PTU dédié pour cette application.
2. Les déploiements de pool PTU d’entreprise et de charge de travail doivent protéger contre les pannes régionales. Pour ce faire, vous pouvez placer le pool PTU de charge de travail dans la région A et le pool DTU d’entreprise dans la région B.
3. Ce déploiement doit d’abord basculer vers le pool DTU Entreprise, puis vers le déploiement Standard. Cela implique que lorsque l’utilisation du déploiement PTU de la charge de travail dépasse 100 %, les requêtes sont toujours mises en service par les points de terminaison PTU, ce qui permet un contrat SLA de latence plus élevé pour cette application.

L’autre avantage de cette architecture est qu’elle vous permet d'empiler des déploiements standard avec des déploiements provisionnés afin de pouvoir ajuster votre niveau de performance et de résilience préféré. Cela vous permet d’utiliser les PTU pour votre demande de référence entre les charges de travail et de tirer profit du déploiement standard pour les pics de trafic.

BCDR pour les agents

Pour prendre en charge la fiabilité du service, le service Agents s’appuie sur les comptes Cosmos DB approvisionnés par le client. Cela garantit que l’état de votre agent peut être conservé et récupéré en cas de panne régionale.

1. En tant que client Azure Standard, vous approvisionnez et gérez votre propre compte Cosmos DB monolocataire.
2. L'état de l'agent est stocké dans votre Cosmos DB. La sauvegarde et la récupération s’appuient sur les fonctionnalités natives de Cosmos DB, que vous contrôlez.
3. Si la région primaire devient indisponible, l’agent devient automatiquement disponible dans la région secondaire en se connectant au même compte Cosmos DB. Étant donné que tous les historiques sont conservés dans Cosmos DB, l’agent peut continuer à fonctionner avec une interruption minimale.

Nous recommandons aux clients de provisionner et de gérer leur compte Cosmos DB et de s’assurer que les stratégies de sauvegarde et de récupération appropriées sont configurées. Cela garantit une continuité transparente si la région primaire devient indisponible.

Prise en charge de l’infrastructure

L’infrastructure qui prend en charge l’architecture OpenAI Azure doit être prise en compte dans les conceptions. Les composants d’infrastructure impliqués dans l’architecture varient selon que les applications consomment le Azure OpenAI sur Internet ou sur un réseau privé. L’architecture décrite dans cet article part du principe que l’organisation a implémenté une passerelle IA générative. Les organisations disposant d’une empreinte Azure mature et d’une connectivité hybride doivent consommer le service par le biais d’un réseau privé, tandis que les organisations sans connectivité hybride, ou avec des applications dans un autre cloud tel que GCP ou AWS, consomment le service via le Microsoft principal public.

Conception pour l'utilisation via l'infrastructure publique principale de Microsoft

Les organisations qui consomment le service par le biais de l’infrastructure principale publique Microsoft doivent prendre en compte les éléments de conception suivants :

1. La passerelle IA Générative doit être déployée de manière à ce qu'elle soit disponible en cas de panne régionale Azure. Si vous utilisez APIM (Gestion des API Azure), vous pouvez le faire en déployant des instances APIM distinctes dans plusieurs régions ou en utilisant la fonctionnalité de passerelle multirégion d'APIM.

2. Un serveur global public load balancer doit être utilisé pour équilibrer la charge sur plusieurs instances de passerelle IA Générative de manière active/active ou active/passive. Azure FrontDoor peut être utilisé pour remplir ce rôle en fonction des exigences de l’organisation.

Conception pour la consommation via la mise en réseau privée

Les organisations qui consomment le service via un réseau privé doivent prendre en compte les éléments de conception suivants :

1. La connectivité hybride doit être déployée de manière à ce qu’elle protège contre l’échec d’une région Azure. Les composants sous-jacentes prenant en charge la connectivité hybride se composent de l’infrastructure réseau locale de l’organisation et de Microsoft ExpressRoute ou VPN.
2. La passerelle IA Générative doit être déployée de manière à ce qu'elle soit disponible en cas de panne régionale Azure. Si vous utilisez APIM (Gestion des API Azure), vous pouvez le faire en déployant des instances APIM distinctes dans plusieurs régions ou en utilisant la fonctionnalité de passerelle multirégion d’APIM.
3. Les points de terminaison privés Azure Private Link doivent être déployés pour chaque instance d'Azure OpenAI dans chaque région Azure. Pour Azure DNS privé, une approche DNS fractionnée peut être utilisée si l’accès à l’application à l’Azure OpenAI est effectué par le biais de la passerelle d’IA Générative pour fournir une protection supplémentaire contre une défaillance régionale. Si ce n’est pas le cas, DNS privé enregistrements doivent être modifiés manuellement en cas de perte d’une région Azure.
4. Un répartiteur de charge global privé doit être utilisé pour équilibrer la charge entre les multiples instances de passerelle d'IA générative, que ce soit en mode actif/actif ou actif/passif. Azure n'a pas de service natif pour l'équilibreur de charge de serveur global pour les charges de travail nécessitant une résolution DNS privée. Pour plus d’informations sur ce sujet, vous pouvez consulter ce guide non officiel : https://github.com/adstuart/azure-crossregion-private-lb. À défaut d’un équilibreur de charge global, les entreprises peuvent mettre en place un modèle actif/passif en modifiant l’enregistrement DNS de la passerelle d’IA générative.