Considérations relatives à la continuité d’activité et reprise d’activité (BCDR) pour Azure OpenAI Service

Azure OpenAI est disponible dans plusieurs régions. Lorsque vous créez une ressource Azure OpenAI, vous spécifiez une région. Ensuite, 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 qu’il bascule vers une autre région ou qu’il répartisse la charge de travail entre deux régions ou plus. Les deux approches nécessitent au moins deux ressources Azure OpenAI dans différentes régions. Cet article fournit des recommandations générales sur l’implémentation de la continuité d’activité et de la récupération d’urgence (BCDR) pour vos applications Azure OpenAI.

Par défaut, le service Azure OpenAI fournit un contrat SLA par défaut. Bien que la résilience par défaut puisse être suffisante pour de nombreuses applications, les applications nécessitant un degré élevé de résilience et de continuité de l’activité doivent prendre des mesures supplémentaires pour renforcer davantage leur infrastructure de modèle.

et standard

Remarque

Il est préférable d’utiliser des déploiements Global Standard, si vous le pouvez. 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 Azure OpenAI Service 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. Le service Azure OpenAI alloue un quota au niveau de l’abonnement et de la région, afin qu’il puisse vivre dans le même abonnement sans impact sur le quota.

3. Vous devez disposer d’un déploiement pour chaque modèle que vous prévoyez d’utiliser déployé sur la ressource Azure OpenAI Service dans votre région Azure préférée. Vous devez également 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 Azure OpenAI Service 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 la limite d’Azure OpenAI Service, Azure OpenAI Service optimise le routage et le traitement sur le calcul disponible 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 s’appuient sur le même pool de capacités de zone qui s’appuie sur toutes les régions disponibles de la zone. Le déploiement secondaire protège contre l’inaccessibilité du point de terminaison Azure OpenAI principal.
   • Utilisez une passerelle IA générative qui prend en charge l’équilibrage de charge et le modèle disjoncteur tel que Gestion des API devant les points de terminaison d’Azure OpenAI Service afin que les interruptions pendant une panne régionale soient réduites à la consommation d’applications.
   • 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 12/04/2024) qui sert de pool d’entreprises de PTU. Vous pouvez utiliser Gestion des API 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 Entreprise comme une ressource de « paiement à l’utilisation privée » qui protège contre le problème des voisins bruyants qui peut se produire sur les déploiements Standard lorsque la demande de service est élevée. Votre organisation bénéficiera d’un accès garanti et dédié à un pool de capacités qui n’est disponible que pour vous et donc indépendant des pics de demande des 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 approvisionnés sont soutenus par des contrats SLA de latence qui les rendent préférables aux déploiements Standard (paiement à l’utilisation) 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 l’accès à votre déploiement PTU et à votre 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 de leur propre déploiement approvisionné 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’avantage supplémentaire de cette architecture est qu’elle vous permet d’empiler des déploiements Standard avec des déploiements approvisionnés afin de pouvoir définir 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 paiement à l’utilisation pour les pics de trafic.

Prise en charge de l’infrastructure

L’infrastructure qui prend en charge l’architecture Azure OpenAI doit être prise en compte dans les conceptions. Les composants d’infrastructure impliqués dans l’architecture varient selon que les applications consomment le service 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, comme BPC ou AWS, consomment le service via le réseau principal public Microsoft.

Conception pour la consommation par le biais du réseau principal public Microsoft

Les organisations qui consomment le service par le biais du réseau principal public 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), cela peut être fait en déployant des instances APIM distinctes dans plusieurs régions ou en utilisant la fonctionnalité de passerelle multi-région d’APIM.

2. Un équilibreur de charge de serveur global public 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 la défaillance d’une région Azure. Les composants sous-jacents en charge de la connectivité hybride sont constitués de l’infrastructure réseau locale de l’organisation et de Microsoft ExpressRoute ou d’un 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), cela peut être fait en déployant des instances APIM distinctes dans plusieurs régions ou en utilisant la fonctionnalité de passerelle multi-région d’APIM.
3. Les points de terminaison privés Azure Private Link doivent être déployés pour chaque instance d’Azure OpenAI Service dans chaque région Azure. Pour le DNS privé Azure, une approche de DNS fractionnée peut être utilisée si toutes les applications accèdent à Azure OpenAI Service par le biais de la passerelle IA générative pour fournir une protection supplémentaire contre une panne régionale. Si ce n’est pas le cas, les enregistrements DNS privés doivent être modifiés manuellement en cas de perte d’une région Azure.
4. Un équilibreur de charge de serveur global privé 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 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. Au lieu d’un équilibreur de charge de serveur global, les organisations peuvent obtenir un modèle actif/passif par le biais du basculement de l’enregistrement DNS pour la passerelle IA générative.