Overwegingen voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR) met Azure OpenAI in Azure AI Foundry-modellen

Azure OpenAI is beschikbaar in meerdere regio's. Wanneer u een Azure OpenAI-resource maakt, geeft u een regio op. Vanaf dat jaar blijven uw resource en alle bijbehorende bewerkingen gekoppeld aan die Azure-serverregio.

Het is zeldzaam, maar niet onmogelijk, om een netwerkprobleem te krijgen dat een hele regio raakt. Als uw service altijd beschikbaar moet zijn, moet u deze ontwerpen voor failover in een andere regio of de workload splitsen tussen twee of meer regio's. Voor beide benaderingen zijn ten minste twee Azure OpenAI-resources in verschillende regio's vereist. Dit artikel bevat algemene aanbevelingen voor het implementeren van BCDR (Business Continuity and Disaster Recovery) voor uw Azure OpenAI-toepassingen.

Azure OpenAI biedt standaard een standaard-SLA. Hoewel de standaardtolerantie voldoende kan zijn voor veel toepassingen, moeten toepassingen die hoge mate van tolerantie en bedrijfscontinuïteit vereisen, extra stappen uitvoeren om hun modelinfrastructuur verder te versterken.

Standaardimplementaties

Opmerking

Als u Global Standard-implementaties kunt gebruiken, moet u deze in plaats daarvan gebruiken. Implementaties van gegevenszones zijn de beste optie voor organisaties die gegevensverwerking volledig binnen een geografische grens vereisen.

1. Voor standaardimplementaties wordt standaard de implementatie van de gegevenszone (VS/EU-opties) gebruikt.

2. U moet twee Azure OpenAI-resources implementeren in het Azure-abonnement. De ene resource moet worden geïmplementeerd in uw voorkeursregio en de andere resource moet worden geïmplementeerd in uw secundaire/failoverregio. De Azure OpenAI wijst quota toe op abonnements- en regioniveau, zodat ze in hetzelfde abonnement kunnen wonen zonder dat dit van invloed is op het quotum.

3. U moet één implementatie hebben voor elk model dat u wilt gebruiken voor de Azure OpenAI-resource in uw favoriete Azure-regio. U moet deze modelimplementaties dupliceren in de secundaire/failoverregio. Wijs het volledige quotum toe dat beschikbaar is in uw standaardimplementatie aan elk van deze eindpunten. Dit biedt de hoogste doorvoersnelheid in vergelijking met het splitsen van quotum voor meerdere implementaties.

4. Selecteer de implementatieregio op basis van uw netwerktopologie. U kunt een Azure OpenAI-resource implementeren in elke ondersteunde regio en vervolgens een privé-eindpunt maken voor die resource in uw voorkeursregio.

   • Eenmaal binnen de grenzen van Azure OpenAI optimaliseert Azure OpenAI de routering en verwerking via beschikbare rekenkracht in de gegevenszone.
   • Het gebruik van gegevenszones is efficiënter en eenvoudiger dan zelfbeheerde taakverdeling voor meerdere regionale implementaties.

5. Als er sprake is van een regionale storing waarbij de implementatie een onbruikbare status heeft, kunt u de andere implementatie in de secundaire/passieve regio binnen hetzelfde abonnement gebruiken.

   • Omdat zowel de primaire als de secundaire implementatie zone-implementaties zone-implementaties zijn, trekken ze uit dezelfde zonecapaciteitspool die afkomstig is van alle beschikbare regio's in de zone. De secundaire implementatie beschermt tegen het primaire Azure OpenAI-eindpunt dat onbereikbaar is.
   • Gebruik een Generative AI Gateway die ondersteuning biedt voor load balancing en circuit breaker patroon, zoals API Management voor de Azure OpenAI-eindpunten, zodat verstoringen tijdens een regionale storing minimaal zijn voor de applicaties die het gebruiken.
   • Als het quotum binnen een bepaald abonnement is uitgeput, kan een nieuw abonnement op dezelfde manier worden geïmplementeerd als hierboven en het eindpunt dat is geïmplementeerd achter de Generatieve AI-gateway.

Ingerichte implementaties

Een Enterprise PTU-pool maken

1. Voor ingerichte implementaties raden we u aan één PTU-implementatie van de gegevenszone (beschikbaar 12/04/2024) te hebben die fungeert als een ondernemingspool van PTU. U kunt API Management gebruiken om verkeer van meerdere toepassingen te beheren om doorvoerlimieten, logboekregistratie, prioriteit en failoverlogica in te stellen.
   • U kunt de Enterprise PTU Pool beschouwen als een voorziening voor een 'privé standaard implementatie' die beschermt tegen het probleem van luidruchtige buren dat kan optreden bij standaardimplementaties wanneer de servicevraag hoog is. Uw organisatie heeft gegarandeerde, toegewezen toegang tot een pool van capaciteit die alleen voor u beschikbaar is en dus onafhankelijk van vraagpieken van andere klanten.
   • Dit geeft u de controle over welke toepassingen de latentie eerst verhogen, zodat u prioriteit kunt geven aan verkeer naar uw bedrijfskritieke toepassingen.
   • Ingerichte implementaties worden ondersteund door latentie-SLA's die de voorkeur geven aan standaardimplementaties voor latentiegevoelige workloads.
   • Enterprise PTU-implementatie maakt ook hogere gebruikssnelheden mogelijk, omdat verkeer wordt afgevlakt tussen toepassingsworkloads, terwijl afzonderlijke workloads meestal gevoeliger zijn voor pieken.
2. Uw primaire Enterprise PTU-implementatie moet zich in een andere regio bevinden dan de primaire standaardzone-implementatie. Dit is zo dat als er sprake is van een regionale storing, u niet tegelijkertijd toegang verliest tot zowel uw PTU-implementatie als de standaardzone-implementatie.

Toegewezen PTU-implementatie van workload

1. Bepaalde workloads moeten mogelijk een eigen ingerichte implementatie hebben. Zo ja, dan kunt u een toegewezen PTU-implementatie voor die toepassing maken.
2. De implementaties van workloads en PTU-pools van ondernemingen moeten bescherming bieden tegen regionale storingen. U kunt dit doen door de PTU-workloadgroep in regio A en de enterprise PTU-pool in regio B te plaatsen.
3. Voor deze implementatie moet eerst een failover worden uitgevoerd naar de Enterprise PTU-pool en vervolgens naar de Standard-implementatie. Dit impliceert dat wanneer het gebruik van de PTU-implementatie van de workload hoger is dan 100%, aanvragen nog steeds worden verwerkt door PTU-eindpunten, waardoor een SLA met een hogere latentie voor die toepassing wordt ingeschakeld.

Het extra voordeel van deze architectuur is dat u standaardimplementaties kunt stapelen met ingerichte implementaties, zodat u kunt inbellen bij het gewenste prestatie- en tolerantieniveau. Hierdoor kunt u PTU gebruiken voor uw basislijnvraag voor workloads en gebruikmaken van een standaardimplementatie voor pieken in het verkeer.

Ondersteunende infrastructuur

De infrastructuur die ondersteuning biedt voor de Azure OpenAI-architectuur, moet worden overwogen in ontwerpen. De infrastructuuronderdelen die betrokken zijn bij de architectuur variëren, afhankelijk van of de toepassingen azure OpenAI via internet of via een particulier netwerk gebruiken. In de architectuur die in dit artikel wordt besproken, wordt ervan uitgegaan dat de organisatie een Generatieve AI-gateway heeft geïmplementeerd. Organisaties met een volwassen Azure-footprint en hybride connectiviteit moeten de service gebruiken via een privénetwerk, terwijl organisaties zonder hybride connectiviteit, of met toepassingen in een andere cloud, zoals GCP of AWS, de service gebruiken via de openbare backbone van Microsoft.

Ontwerpen voor verbruik via de openbare Backbone van Microsoft

Organisaties die de service gebruiken via de openbare backbone van Microsoft, moeten rekening houden met de volgende ontwerpelementen:

1. De Generatieve AI-gateway moet worden geïmplementeerd op een manier die ervoor zorgt dat deze beschikbaar is in het geval van een regionale storing in Azure. Als u APIM (Azure API Management) gebruikt, kunt u dit doen door afzonderlijke APIM-exemplaren in meerdere regio's te implementeren of door de functie gateway voor meerdere regio's van APIM te gebruiken.

2. Een openbare globale server load balancer moet worden gebruikt om taken te verdelen over de meerdere Generatieve AI Gateway-exemplaren op een actieve/actieve of actieve/passieve manier. Azure FrontDoor kan worden gebruikt om aan deze rol te voldoen, afhankelijk van de vereisten van de organisatie.

Ontwerpen voor verbruik via het privénetwerk

Organisaties die de service via een particulier netwerk gebruiken, moeten rekening houden met de volgende ontwerpelementen:

1. Hybride connectiviteit moet worden geïmplementeerd op een manier die wordt beschermd tegen het mislukken van een Azure-regio. De onderliggende onderdelen die hybride connectiviteit ondersteunen, bestaan uit de on-premises netwerkinfrastructuur van de organisatie en Microsoft ExpressRoute of VPN.
2. De Generatieve AI-gateway moet worden geïmplementeerd op een manier die ervoor zorgt dat deze beschikbaar is in het geval van een regionale storing in Azure. Als u APIM (Azure API Management) gebruikt, kunt u dit doen door afzonderlijke APIM-exemplaren in meerdere regio's te implementeren of door de functie gateway voor meerdere regio's van APIM te gebruiken.
3. Privé-eindpunten van Azure Private Link moeten worden geïmplementeerd voor elk Azure OpenAI-exemplaar in elke Azure-regio. Voor Privé-DNS van Azure kan een split-brain DNS-benadering worden gebruikt als alle toepassingstoegang tot de Azure OpenAI wordt uitgevoerd via de Generatieve AI-gateway om extra bescherming te bieden tegen een regionale fout. Als dat niet het geval is, moeten Privé-DNS records handmatig worden gewijzigd in geval van verlies van een Azure-regio.
4. Een load balancer van een privé-globale server moet worden gebruikt om de load balancer te verdelen over de meerdere Generatieve AI Gateway-exemplaren op een actieve/actieve of actieve/passieve manier. Azure heeft geen systeemeigen service voor globale server load balancer voor workloads waarvoor een privé-DNS-omzetting is vereist. Raadpleeg deze onofficiële handleiding voor aanvullende achtergrondinformatie over dit onderwerp: https://github.com/adstuart/azure-crossregion-private-lb. In plaats van een globale server load balancer kunnen organisaties een actief/passief patroon bereiken door de DNS-record voor de Generatieve AI-gateway in te schakelen.