Überlegungen zur Geschäftskontinuität und Notfallwiederherstellung (BCDR) mit Azure OpenAI in Microsoft Foundry-Modellen

Hinweis

Dieses Dokument bezieht sich auf das Microsoft Foundry(klassische) Portal.

🔍 Zeigen Sie die Microsoft Foundry-Dokumentation (neu) an, um mehr über das neue Portal zu erfahren.

Azure OpenAI ist in mehreren Regionen verfügbar. Wenn Sie eine Azure OpenAI-Ressource erstellen, geben Sie eine Region an. Anschließend bleiben Ihre Ressource und alle zugehörigen Vorgänge mit dieser Azure-Serverregion verknüpft.

Es ist selten, aber nicht unmöglich, dass ein Netzwerkproblem auftritt, das eine ganze Region betrifft. Wenn Ihr Dienst immer verfügbar sein muss, sollten Sie ihn so entwerfen, dass er ein Failover in eine andere Region ausführt oder die Workload zwischen mehreren Regionen aufgeteilt wird. Beide Ansätze erfordern mindestens zwei Azure OpenAI-Ressourcen in verschiedenen Regionen. Dieser Artikel enthält allgemeine Empfehlungen zur Implementierung von Business Continuity & Disaster Recovery (BCDR) für Ihre Azure OpenAI-Anwendungen.

Standardmäßig stellt Azure OpenAI einen Standardvertrag zum Servicelevel bereit. Obwohl die Standardresilienz für viele Anwendungen ausreichend sein kann, sollten Anwendungen, die hohe Resilienzgrade erfordern, zusätzliche Schritte unternehmen, um ihre Modellinfrastruktur weiter zu stärken.

Standard-Bereitstellung

Hinweis

Wenn Sie globale Standardbereitstellungen verwenden können, sollten Sie stattdessen diese verwenden. Datenzonenbereitstellungen sind die nächstbeste Option für Organisationen, bei denen die Datenverarbeitung vollständig innerhalb einer geografischen Grenze erfolgen muss.

1. Für Standardbereitstellungen wird standardmäßig die Datenzonenbereitstellung verwendet (US-/EU-Optionen).

2. Sie sollten zwei Azure OpenAI-Ressourcen im Azure-Abonnement bereitstellen. Eine Ressource sollte in Ihrer bevorzugten Region bereitgestellt werden, und die andere sollte in Ihrer sekundären Region/Failoverregion bereitgestellt werden. Azure OpenAI weist das Kontingent auf Abonnement- und Regionsebene zu, sodass die Ressourcen in demselben Abonnement ohne Auswirkungen auf das Kontingent vorhanden sein können.

3. Sie sollten über eine Bereitstellung für jedes Modell verfügen, das Sie für die Azure OpenAI-Ressource in Ihrer bevorzugten Azure-Region bereitstellen möchten, und Sie sollten diese Modellbereitstellungen in der sekundären/Failoverregion duplizieren. Weisen Sie jedem dieser Endpunkte das vollständige Kontingent zu, das in Ihrer Standardbereitstellung verfügbar ist. Dies bietet die höchste Durchsatzrate im Vergleich mit dem Aufteilen des Kontingents über mehrere Bereitstellungen.

4. Wählen Sie die Bereitstellungsregion basierend auf Ihrer Netzwerktopologie aus. Sie können eine Azure OpenAI-Ressource für jede unterstützte Region bereitstellen und dann einen privaten Endpunkt für diese Ressource in Ihrer bevorzugten Region erstellen.

   • Sobald Sie sich innerhalb der Grenzen von Azure OpenAI befinden, optimiert Azure OpenAI das Routing und die Verarbeitung durch die verfügbaren Rechenressourcen in der Datenzone.
   • Die Verwendung von Datenzonen ist effizienter und einfacher als der selbstverwaltete Lastenausgleich über mehrere regionale Bereitstellungen hinweg.

5. Wenn ein regionaler Ausfall auftritt, bei dem sich die Bereitstellung in einem nicht verwendbaren Zustand befindet, können Sie die andere Bereitstellung in der sekundären/passiven Region innerhalb desselben Abonnements verwenden.

   • Da sowohl die primären als auch die sekundären Bereitstellungen Zonenbereitstellungen sind, greifen sie auf denselben Zonenkapazitätspool zu, der aus allen verfügbaren Regionen in der Zone stammt. Die sekundäre Bereitstellung schützt davor, dass der primäre Azure OpenAI-Endpunkt nicht erreichbar ist.
   • Verwenden Sie ein generatives KI-Gateway, das Lastenausgleichs- und Trennschalter-Muster wie API Management vor den Azure OpenAI-Endpunkten unterstützt, sodass Unterbrechungen während eines regionalen Ausfalls auf verarbeitende Anwendungen begrenzt werden.
   • Wenn das Kontingent innerhalb eines bestimmten Abonnements erschöpft ist, kann ein neues Abonnement auf die gleiche Weise bereitgestellt werden wie oben, und sein Endpunkt wird hinter dem generativen KI-Gateway bereitgestellt.

Bereitgestellte Bereitstellungen

Erstellen eines Enterprise-PTU-Pools

1. Für bereitgestellte Implementierungen empfehlen wir, eine einzelne Datenzonen-PTU-Bereitstellung (verfügbar am 4. Dezember 2024) zu verwenden, der als Pool von PTU für das Unternehmen fungiert. Mit dem API Management können Sie Datenverkehr aus mehreren Anwendungen verwalten, um Durchsatzgrenzwerte, Protokollierung, Priorität und Failoverlogik festzulegen.
   • Stellen Sie sich diesen Enterprise-PTU-Pool als eine eigene Standardbereitstellungsressource vor, die vor dem Problem mit lauten Nachbarn schützt, das bei Standardbereitstellungen bei hoher Servicenachfrage auftreten kann. Ihre Organisation hat garantierten, dedizierten Zugriff auf einen Kapazitätspool, der nur Ihnen zur Verfügung steht und daher unabhängig von Nachfragespitzen von anderen Kunden ist.
   • Auf diese Weise können Sie steuern, bei welchen Anwendungen sich eine höhere Latenz zuerst bemerkbar macht. So können Sie dem Datenverkehr Ihrer unternehmenskritischen Anwendungen eine höhere Priorität einräumen.
   • Bereitgestellte Bereitstellungen werden von Latenz-SLAs unterstützt, deshalb sind sie bei latenzempfindlichen Workloads den Standardbereitstellungen vorzuziehen.
   • Die Enterprise-PTU-Bereitstellung ermöglicht auch höhere Auslastungsraten, da der Datenverkehr über Anwendungsworkloads verteilt wird, während einzelne Workloads tendenziell anfälliger für Spitzen sind.
2. Ihre primäre Enterprise-PTU-Bereitstellung sollte sich in einer anderen Region befinden als Ihre primäre Standardzonenbereitstellung. Mit dieser Konfiguration verlieren Sie bei einem regionalen Ausfall nicht gleichzeitig den Zugriff auf Ihre PTU-Bereitstellung und die Standardzonenbereitstellung.

Dedizierte PTU-Bereitstellung für eine Workload

1. Bestimmte Workloads müssen möglicherweise über eine eigene dedizierte Bereitstellung verfügen. In diesem Fall können Sie eine dedizierte PTU-Bereitstellung für diese Anwendung erstellen.
2. Die Workload- und Enterprise-PTU-Pool-Bereitstellungen sollten vor regionalen Ausfällen schützen. Dazu können Sie beispielsweise den PTU-Workload-Pool in Region A und den Enterprise-PTU-Pool in Region B platzieren.
3. Bei dieser Bereitstellung sollte zuerst ein Failover zum Enterprise-PTU-Pool und dann zur Standardbereitstellung erfolgen. Dies impliziert Folgendes: Wenn die Auslastung der Workload-PTU-Bereitstellung 100 % überschreitet, werden Anforderungen weiterhin von PTU-Endpunkten verarbeitet, wodurch für diese Anwendung eine SLA mit höherer Latenz ermöglicht wird.

Der andere Vorteil dieser Architektur besteht darin, dass Sie Standardbereitstellungen mit bereitgestellten Bereitstellungen stapeln können, sodass Sie sich in Ihr bevorzugtes Leistungs- und Resilienzniveau einwählen können. Auf diese Weise können Sie PTU für die Grundnachfrage über Workloads hinweg verwenden und die nutzungsbasierte Standardbereitstellung für Spitzen im Datenverkehr nutzen.

BCDR für Agenten

Zur Unterstützung der Dienstresilienz basiert der Agents-Dienst auf Kunden-bereitgestellten Cosmos DB-Konten. Dadurch wird sichergestellt, dass Ihr Agentenstatus beibehalten und wiederhergestellt werden kann, bei einem regionalen Ausfall.

1. Als Azure Standard-Kunde stellen Sie Ihr eigenes Einzelmandanten-Cosmos DB-Konto bereit und verwalten es.
2. Der gesamte Agentstatus wird in Ihrem Cosmos DB gespeichert. Sicherung und Wiederherstellung basieren auf den systemeigenen Funktionen von Cosmos DB, die Sie steuern.
3. Wenn die primäre Region nicht verfügbar ist, wird der Agent automatisch in der sekundären Region verfügbar, indem eine Verbindung mit demselben Cosmos DB-Konto hergestellt wird. Da alle Geschichte in Cosmos DB erhalten bleibt, kann der Agent den Betrieb mit minimalen Unterbrechungen fortsetzen.

Wir empfehlen Kunden, ihr Cosmos DB-Konto bereitzustellen und zu verwalten und sicherzustellen, dass geeignete Sicherungs- und Wiederherstellungsrichtlinien konfiguriert sind. Dadurch wird eine nahtlose Kontinuität sichergestellt, wenn die primäre Region nicht verfügbar ist.

Unterstützende Infrastruktur

Die Infrastruktur, die die Azure OpenAI-Architektur unterstützt, muss in Entwürfen berücksichtigt werden. Die an der Architektur beteiligten Infrastrukturkomponenten variieren je nachdem, ob die Anwendungen Azure OpenAI über das Internet oder über ein privates Netzwerk nutzen. Die in diesem Artikel erläuterte Architektur setzt voraus, dass die Organisation ein generatives KI-Gateway implementiert hat. Organisationen mit einem ausgereiften Azure-Speicherbedarf und Hybridkonnektivität sollten den Dienst über ein privates Netzwerk nutzen, während Organisationen ohne Hybridkonnektivität oder mit Anwendungen in einer anderen Cloud wie GCP oder AWS den Dienst über den öffentlichen Microsoft-Backbone nutzen.

Entwerfen für die Nutzung über den öffentlichen Microsoft-Backbone

Organisationen, die den Dienst über den öffentlichen Microsoft-Backbone nutzen, sollten die folgenden Entwurfselemente berücksichtigen:

1. Das generative AI-Gateway sollte so bereitgestellt werden, dass sichergestellt wird, dass es verfügbar ist, wenn ein regionaler Azure-Ausfall vorhanden ist. Wenn Sie APIM (Azure API Management) verwenden, können Sie dies tun, indem Sie separate APIM-Instanzen in mehreren Regionen bereitstellen oder das Feature für das Gateway mit mehreren Regionen von APIM verwenden.

2. Ein öffentlicher globaler Serverlastenausgleich sollte zum Lastenausgleich über mehrere generative KI-Gatewayinstanzen hinweg verwendet werden, entweder aktiv/aktiv oder aktiv/passiv. Je nach den Anforderungen der Organisation kann Azure FrontDoor verwendet werden, um diese Rolle zu erfüllen.

Entwerfen für die Nutzung über das private Netzwerk

Organisationen, die den Dienst über ein privates Netzwerk nutzen, sollten die folgenden Entwurfselemente berücksichtigen:

1. Hybridkonnektivität sollte so bereitgestellt werden, dass sie vor dem Ausfall einer Azure-Region schützt. Die zugrunde liegenden Komponenten, die die Hybridkonnektivität unterstützen, bestehen aus der lokalen Netzwerkinfrastruktur der Organisation und Microsoft ExpressRoute oder VPN.
2. Das generative KI-Gateway sollte so bereitgestellt werden, dass sichergestellt wird, dass es im Falle eines regionalen Azure-Ausfalls verfügbar ist. Bei Verwendung von APIM (Azure API Management) kann dies durch Bereitstellen separater APIM-Instanzen in mehreren Regionen oder mithilfe der Gateway-Funktion für mehrere Regionen von APIM erreicht werden.
3. Private Azure-Links-Endpunkte sollten für jede Azure OpenAI-Instanz in jeder Azure-Region bereitgestellt werden. Für Azure Private DNS kann ein Split-Brain-DNS-Ansatz verwendet werden, wenn der gesamte Anwendungszugriff auf azure OpenAI über das generative AI-Gateway erfolgt, um zusätzlichen Schutz vor einem regionalen Fehler zu gewährleisten. Wenn dies nicht der Fall ist, müssen private DNS-Einträge im Falle eines Verlusts einer Azure-Region manuell geändert werden.
4. Ein privater globaler Serverlastenausgleich sollte zum Lastenausgleich über mehrere generative KI-Gatewayinstanzen hinweg verwendet werden, entweder aktiv/aktiv oder aktiv/passiv. Azure hat keinen nativen Dienst für den globalen Serverlastenausgleich für Workloads, die eine Auflösung von privatem DNS erfordern. Weitere Informationen zu diesem Thema finden Sie in diesem inoffiziellen Leitfaden: https://github.com/adstuart/azure-crossregion-private-lb. Anstelle eines globalen Serverlastenausgleichs können Organisationen ein aktives/passives Muster durch Umschalten des DNS-Eintrags für das generative AI-Gateway erreichen.