Referenzarchitektur des Azure AI Foundry-Chats in einer Azure-Zielzone
Dieser Artikel ist Teil einer Reihe, die auf der Referenzarchitektur des Baseline AI Foundry-Chats basiert. Überprüfen Sie die Basisarchitektur, damit Sie die erforderlichen Anpassungen identifizieren können, bevor Sie sie in einem Azure-Anwendungslandzonenabonnement bereitstellen.
In diesem Artikel wird eine generative KI-Workloadarchitektur beschrieben, die die geplante Chatanwendung bereitstellt, aber Ressourcen verwendet, die sich außerhalb des Umfangs des Workloadteams befinden. Plattformteams verwalten die Ressourcen zentral, und mehrere Arbeitsauslastungsteams verwenden sie. Zu den freigegebenen Ressourcen gehören Netzwerkressourcen für standortübergreifende Verbindungen, Identitätszugriffsverwaltungssysteme und Richtlinien. Dieser Leitfaden hilft Organisationen, die Azure-Landezonen verwenden, eine konsistente Governance und Kosteneffizienz zu gewährleisten.
Azure AI Foundry verwendet Konten und Projekte zur Organisation der KI-Entwicklung und -Bereitstellung. Eine Implementierung der Zielzone kann z. B. ein Konto als zentrale Ressource auf Unternehmensgruppenebene und Projekte als delegierte Ressource für jede Arbeitsauslastung in dieser Geschäftsgruppe verwenden. Aufgrund von Ressourcenorganisationsfaktoren und Kostenzuordnungseinschränkungen empfehlen wir diese Topologie nicht, und dieser Artikel enthält keine Anleitungen dazu. Stattdessen behandelt diese Architektur die Workload als Besitzer der Azure AI Foundry-Instanz, die der empfohlene Ansatz ist.
Als Workloadbesitzer delegieren Sie die gemeinsame Ressourcenverwaltung an Plattformteams, sodass Sie sich auf die Arbeitsauslastungsentwicklung konzentrieren können. In diesem Artikel wird die Perspektive des Workloadteams erläutert und Empfehlungen für das Plattformteam angegeben.
Von Bedeutung
Was sind Azure-Zielzonen?
Azure-Landezonen teilen den Cloudbedarf Ihrer Organisation in zwei Schlüsselbereiche auf:
Eine Anwendungslandzone ist ein Azure-Abonnement, in dem eine Workload ausgeführt wird. Eine Anwendungszielzone stellt eine Verbindung mit den freigegebenen Plattformressourcen Ihrer Organisation bereit. Diese Verbindung bietet der Zielzone Zugriff auf die Infrastruktur, die die Workload unterstützt, z. B. Netzwerk, Identitätszugriffsverwaltung, Richtlinien und Überwachung.
Eine Plattform-Zielzone ist eine Sammlung verschiedener Abonnements, die von mehreren Plattformteams verwaltet werden können. Jedes Abonnement hat eine bestimmte Funktion. Ein Konnektivitätsabonnement bietet z. B. eine zentralisierte DNS-Auflösung (Domain Name System), eine standortübergreifende Konnektivität und virtuelle Netzwerkgeräte (NETWORK Virtual Appliances, NVAs) für Plattformteams.
Um Ihnen bei der Implementierung dieser Architektur zu helfen, verstehen Sie Azure-Landezonen, deren Designprinzipien und ihre Entwurfsbereiche.
Artikel-Layout
| Architektur | Entwurfsentscheidungen | Ansatz für ein Azure Well-Architected Framework |
|---|---|---|
| ▪ Architekturdiagramm ▪ Workloadressourcen ▪ Verbundressourcen |
▪ Abonnementeinrichtung ▪ Netzwerk ▪ Zugang für Datenwissenschaftler ▪ Überwachen von Ressourcen ▪ Organisations-Governance ▪ Change Management |
▪ Zuverlässigkeit ▪ Sicherheit ▪ Kostenoptimierung ▪ Erstklassige Betriebsprozesse ▪ Leistungseffizienz |
Tipp
Die Grundlegende Referenzimplementierung des Azure AI Foundry Agent Service-Chats veranschaulicht die in diesem Artikel beschriebenen bewährten Methoden. Überprüfen Und testen Sie diese Bereitstellungsressourcen, bevor Sie Ihre Entwurfsentscheidungen auswählen und implementieren.
Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Komponenten
Alle Azure-Zielzonenarchitekturen trennen den Besitz zwischen dem Plattformteam und dem Workload-Team, das als Abonnementdemokratisierung bezeichnet wird. Anwendungsarchitekten, Data Scientists und DevOps-Teams müssen diese Abteilung klar verstehen, um zu bestimmen, was unter ihren direkten Einfluss oder ihre Kontrolle fällt und was nicht.
Wie bei den meisten Implementierungen der Anwendungslandzone verwaltet das Workloadteam in erster Linie die Konfiguration, Bereitstellung und Überwachung von Workloadkomponenten, einschließlich der KI-Dienste in dieser Architektur.
Eigene Ressourcen des Workloadteams
Die folgenden Ressourcen bleiben gegenüber der Baselinearchitektur weitgehend unverändert.
Azure AI Foundry-Konten und Projekte ermöglichen es dem Workloadteam, generative KI-Modelle als Dienst zu hosten, die Inhaltssicherheit zu implementieren und workloadspezifische Verbindungen zu Wissensquellen und Tools einzurichten.
Wenn das AI Center of Excellence Ihrer Organisation den Zugriff auf KI-Modellbereitstellungen beschränkt, hostet das Workloadteam möglicherweise keine Modelle in Projekten und Konten. Stattdessen müssen sie möglicherweise zentrale KI-Ressourcen verwenden. In diesem Szenario fließt der gesamte Modellverbrauch in der Regel über ein Gateway, das Ihr KI-Plattformteam bereitstellt.
In diesem Artikel wird davon ausgegangen, dass in diesem Szenario generative KI-Modelle Arbeitsauslastungsressourcen sind. Andernfalls wird der Modellhost oder ein Gateway zu den Modellen zu einer Workloadabhängigkeit. Das Plattformteam muss eine zuverlässige Netzwerkkonnektivität mit den APIs gewährleisten.
Der Foundry Agent Service behandelt Modellabhängigkeiten auf eine bestimmte Weise, sodass Herausforderungen auftreten können, wenn Sie zentral gehostete Modelle nutzen. Möglicherweise müssen Sie einen alternativen Orchestrator verwenden.
Der Foundry Agent Service stellt die Orchestrierungsebene für Chatinteraktionen bereit. Er hostt und verwaltet den Chat-Agent, der Benutzeranforderungen verarbeitet.
Verwenden Sie das Standard-Agent-Setup in dieser Architektur. Verbinden Sie Ihren Agent mit einem dedizierten Subnetz in Ihrem virtuellen Speichennetzwerk, und leiten Sie den Datenverkehr über Ihr Konnektivitätsabonnement weiter.
Das Workload-Team stellt dedizierte Azure-Ressourcen für den Agentstatus, den Chatverlauf und die Dateispeicherung zur. Diese Ressourcen sind Azure Cosmos DB für NoSQL, Azure Storage und Azure AI Search. Ihre Foundry Agent Service-Instanz verwaltet diese Ressourcen und ihre Daten ausschließlich. Andere Anwendungskomponenten in Ihrer Workload oder anderen Workloads in Ihrer Organisation sollten sie nicht verwenden.
Azure App Service hostt die Webanwendung, die die Chat-Benutzeroberfläche enthält. Der App-Dienst verfügt über drei Instanzen in verschiedenen Azure-Zonen.
Ein Azure Storage-Konto hostet den Code der Webanwendung als ZIP-Datei, die innerhalb von App Service bereitgestellt wird.
AI Search ruft relevante indizierte Daten für Anwendungsbenutzerabfragen ab. DIE KI-Suche dient als Workload-Wissensspeicher für das Muster der abrufen erweiterten Generation. Dieses Muster extrahiert eine entsprechende Abfrage aus einer Eingabeaufforderung, fragt AI Search ab und verwendet die Ergebnisse als Grundlage für ein generatives KI-Foundation-Modell.
Das Azure-Anwendungsgateway dient als Reverseproxy zum Weiterleiten von Benutzeranforderungen an die chat-UI, die in App Service gehostet wird. Die ausgewählte SKU hostt auch eine Azure-Webanwendungsfirewall, um die Front-End-Anwendung vor potenziell schädlichem Datenverkehr zu schützen.
Azure Key Vault speichert das TLS-Zertifikat (Transport Layer Security) des Anwendungsgateways.
Azure Monitor, Azure Monitor-Protokolle und Application Insights sammeln, speichern und visualisieren Observability-Daten.
Azure-Richtlinie wendet workloadspezifische Richtlinien an, um Steuerelemente im Großen und Umfang zu steuern, zu sichern und anzuwenden.
Das Workloadteam verwaltet auch die folgenden Ressourcen:
Speichen virtual network subnets and the network security groups (NSGs) on those subnets maintain segmentation and control traffic flow.
Private Endpunkte sichern die Konnektivität mit Plattform as a Service (PaaS)-Lösungen.
Ressourcen im Besitz des Plattformteams
Das Plattformteam besitzt und verwaltet die folgenden zentralen Ressourcen. Bei dieser Architektur wird davon ausgegangen, dass diese Ressourcen vorab bereitgestellt und als Abhängigkeiten behandelt werden.
Azure Firewall in der Hub-Netzwerkrouten , überprüft und schränkt den Ausgehenden Datenverkehr ein, der von der Workload stammt, einschließlich Agentdatenverkehr. Der ausgehende Workload-Datenverkehr geht ins Internet, zu standortübergreifenden Zielen oder zu anderen Anwendungs-Zielzonen.
Änderung von der Basislinie: In der Basisarchitektur besitzt das Workloadteam diese Komponente. In dieser Architektur verwaltet das Plattformteam sie unter dem Konnektivitätsabonnement.
Azure Bastion im Hubnetzwerk bietet sicheren betriebsbereiten Zugriff auf Workloadkomponenten und ermöglicht den Zugriff auf Azure AI Foundry-Komponenten.
Änderung von der Basislinie: In der Basisarchitektur besitzt das Workloadteam diese Komponente.
Das virtuelle Spoke-Netzwerk ist der Ort, an dem die Workload bereitgestellt wird.
Änderung von der Basislinie: In der Basisarchitektur besitzt das Workloadteam dieses Netzwerk.
Benutzerdefinierte Routen (USER-Defined Routes, UDRs) erzwingen Tunneling in das Hubnetzwerk.
Änderung von der Basislinie: In der Basisarchitektur besitzt das Workloadteam dieses Netzwerk.
Richtlinienbasierte Azure-Governanceeinschränkungen und
DeployIfNotExists(DINE)-Richtlinien gelten für das Workload-Abonnement. Sie können diese Richtlinien auf Der Ebene der plattformeigenen Verwaltungsgruppe oder direkt auf das Abonnement der Workload anwenden.Veränderung gegenüber dem Ausgangswert: Diese Maßnahmen sind neu in dieser Architektur. Das Plattformteam wendet Richtlinien an, die Ihre Arbeitsauslastung einschränken. Einige Richtlinien können vorhandene Workloadeinschränkungen duplizieren oder neue Einschränkungen einführen.
Hosteinträge für private Azure-DNS-Zonen
Afür private Endpunkte. Weitere Informationen finden Sie unter Azure Private Link und DNS-Integration im großen Maßstab.Änderung von der Basislinie: In der Basisarchitektur besitzt das Workloadteam dieses Netzwerk. In dieser Architektur verwaltet das Plattformteam diese Komponente unter dem Konnektivitätsabonnement.
Der DNS-Auflösungsdienst unterstützt virtuelle Speichennetzwerke und standortübergreifende Arbeitsstationen. Dieser Dienst verwendet in der Regel Azure Firewall als DNS-Proxy oder Azure DNS Private Resolver. In dieser Architektur löst der Dienst private Endpunkt-DNS-Einträge für alle DNS-Anforderungen des Speichens auf. DNS Private Resolver und verknüpfte Rulesets sind die empfohlene Methode für das Plattformteam, um diese Anforderungen an die Architekturauflösung aufgrund der DNS-Auflösungsmerkmale des Foundry Agent Service zu aktivieren.
Azure DDoS Protection schützt öffentliche IP-Adressen vor verteilten Angriffen.
Änderung von der Basislinie: In der Basisarchitektur kauft das Workloadteam DDoS Protection.
Von Bedeutung
Azure-Zielzonen stellen einige der vorherigen Ressourcen als Teil der Plattform-Landingzone-Abonnements bereit. Ihr Workload-Abonnement bietet weitere Ressourcen. Viele dieser Ressourcen befinden sich im Konnektivitätsabonnement, das auch Azure ExpressRoute, Azure VPN-Gateway und DNS Private Resolver umfasst. Diese Ressourcen ermöglichen den standortübergreifenden Zugriff und die Namensauflösung. Die Verwaltung dieser Ressourcen liegt außerhalb des Umfangs dieses Artikels.
Abonnementeinrichtung
Das Workloadteam muss das Plattformteam über bestimmte Anforderungen an die Zielzone informieren, um diese Architektur zu implementieren. Und das Plattformteam muss seine Anforderungen an das Workload-Team übermitteln.
Das Workloadteam muss z. B. detaillierte Informationen zum erforderlichen Netzwerkraum bereitstellen. Das Plattformteam verwendet diese Informationen, um die erforderlichen Ressourcen zuzuordnen. Das Workloadteam definiert die Anforderungen, und das Plattformteam weist die entsprechenden IP-Adressen innerhalb des virtuellen Netzwerks zu.
Das Plattformteam weist eine Verwaltungsgruppe basierend auf der Geschäftskritischenität und technischen Anforderungen der Workload zu. Wenn z. B. die Workload für das Internet verfügbar gemacht wird, wie diese Architektur, wählt das Plattformteam eine entsprechende Verwaltungsgruppe aus. Zum Einrichten der Governance konfiguriert und implementiert das Plattformteam auch Verwaltungsgruppen. Das Workloadteam muss die Workload innerhalb der Einschränkungen dieser Governance entwerfen und betreiben. Weitere Informationen zu typischen Unterscheidungen von Verwaltungsgruppen finden Sie unter "Anpassen der Azure-Zielzonenarchitektur".
Das Plattformteam richtet das Abonnement für diese Architektur ein. In den folgenden Abschnitten finden Sie Anleitungen zum anfänglichen Abonnementsetup.
Anforderungen an die Arbeitsbelastung und deren Bewältigung
Das Workload-Team und das Plattformteam müssen an Details wie Verwaltungsgruppenzuweisung, Azure-Richtliniengovernance und Netzwerkeinrichtung zusammenarbeiten. Erstellen Sie eine Checkliste der Anforderungen, um die Diskussion und Verhandlung mit dem Plattformteam zu beginnen. Die folgende Checkliste dient als Beispiel.
| Überlegungen zum Entwurf | Arbeitslastanforderungen für diese Architektur | |
|---|---|---|
| ☐ | Die Anzahl der virtuellen Speichennetzwerke und deren Größe: Das Plattformteam erstellt und konfiguriert das virtuelle Netzwerk und übergibt es dann an den regionalen Hub, um es als Speichen festzulegen. Sie müssen auch sicherstellen, dass das Netzwerk zukünftiges Arbeitsauslastungswachstum aufnehmen kann. Um diese Aufgaben effektiv auszuführen, müssen sie die Anzahl der benötigten Speichen kennen. | Stellen Sie alle Ressourcen in einem einzigen dedizierten virtuellen Speichennetzwerk bereit. Fordern Sie /22 zusammenhängenden Adressraum an, um Vorgänge und Szenarien wie parallele Bereitstellungen in vollem Umfang zu unterstützen. Die folgenden Faktoren bestimmen die meisten IP-Adressanforderungen: – Anforderungen des Application Gateways an die Subnetzgröße (feste Größe). – Private Endpunkte mit einzelnen IP-Adressen für PaaS-Dienste (feste Größe). – Die Subnetzgröße für Build-Agenten (feste Größe). – Der Gießerei-Agent-Dienst erfordert ein Subnetz innerhalb eines /24 Präfixes. |
| ☐ | Präfixe für virtuelle Netzwerke: In der Regel weist das Plattformteam IP-Adressen basierend auf vorhandenen Konventionen, Vermeidung von Überlappungen mit Peered-Netzwerken und Verfügbarkeit im IP-Adressverwaltungssystem (IPAM) zu. | Das Subnetz für die Agentintegration muss ein Adresspräfix verwenden, das mit 172. oder 192. z 192.168.45.1/24. B. beginnt. Eine Laufzeiteinschränkung im Findry Agent Service-Funktionshost erzwingt diese Anforderung. Der Foundry Agent Service unterstützt keine Subnetze, die verwendet werden 10.. Bitten Sie Ihr Plattformteam, einen Speichen mit einem gültigen Adresspräfix für Ihr Agent-Subnetz bereitzustellen. |
| ☐ | Bereitstellungsregion: Das Plattformteam muss einen Hub in derselben Region wie die Workloadressourcen bereitstellen. | Kommunizieren Sie die ausgewählte Region für die Workload und die Regionen für zugrunde liegende Computeressourcen. Stellen Sie sicher, dass die Regionen Verfügbarkeitszonen unterstützen. Azure OpenAI in Foundry Models hat eine begrenzte regionale Verfügbarkeit. |
| ☐ | Typ, Volume und Muster des Datenverkehrs: Das Plattformteam muss die Eingangs- und Ausgangsanforderungen der gemeinsam genutzten Ressourcen Ihrer Workload ermitteln. | Geben Sie Informationen zu den folgenden Faktoren an: - Wie die Benutzer diesen Workload nutzen sollten. - Wie diese Arbeitslast die Ressourcen der Umgebung beansprucht. - Das konfigurierte Transportprotokoll. - Das Datenverkehrsaufkommen und die erwarteten Haupt- und Nebenverkehrszeiten. Kommunizieren Sie, wenn Sie eine hohe Anzahl gleichzeitiger Verbindungen mit dem Internet (Chatty) erwarten und wenn Sie erwarten, dass die Workload minimalen Netzwerkdatenverkehr (Hintergrundgeräusche) generiert. |
| ☐ | Firewallkonfiguration: Das Plattformteam muss Regeln festlegen, um legitimen Datenverkehr zuzulassen. | Teilen Sie Details über ausgehenden Datenverkehr aus dem Speichennetzwerk, einschließlich Agentdatenverkehr. Build-Agent- und Sprungfeldcomputer benötigen regelmäßige Betriebssystempatching. Agents müssen möglicherweise mit Internet-Erdungsquellen, Tools oder anderen Agents interagieren, die außerhalb der Workload gehostet werden. |
| ☐ | Eingehender Datenverkehr von spezialisierten Rollen: Das Plattformteam muss die angegebenen Rollen mit Netzwerkzugriff auf die Workload bereitstellen und die richtige Segmentierung implementieren. | Arbeiten Sie mit dem Plattformteam zusammen, um die beste Methode zu ermitteln, um autorisierten Zugriff für die folgenden Rollen zuzulassen: - Data Scientists und Entwickler, die von ihren Arbeitsstationen aus auf das Azure AI Foundry-Portal zugreifen, in Unternehmensnetzwerkverbindungen – Operatoren, die über ein workloadverwaltetes Sprungfeld auf die Computeebene zugreifen |
| ☐ |
Zugriff auf das öffentliche Internet auf die Workload: Das Plattformteam verwendet diese Informationen für die Risikobewertung, die mehrere Entscheidungen steuert: - Die Platzierung der Arbeitsauslastung in einer Managementgruppe mit entsprechenden Schutzschienen - Verteilter Denial-of-Service(DDoS)-Schutz für die öffentliche IP-Adresse, die vom Workloadteam gemeldet wird - TLS-Zertifikatbeschaffung und -verwaltung |
Informieren Sie das Plattformteam über das Profil des eingehenden Datenverkehrs: – Internet-Quelldatenverkehr, der auf die öffentliche IP-Adresse auf dem Anwendungsgateway ausgerichtet ist - Vollqualifizierte Domänennamen (FQDNs), die der öffentlichen IP-Adresse für die Beschaffung von TLS-Zertifikaten zugeordnet sind |
| ☐ | Nutzung privater Endpunkte: Das Plattformteam muss azure private DNS-Zonen für die privaten Endpunkte einrichten und sicherstellen, dass die Firewall im Hubnetzwerk die DNS-Auflösung ordnungsgemäß ausführt. | Informieren Sie das Plattformteam über alle Ressourcen, die private Endpunkte verwenden, einschließlich der folgenden Ressourcen: - KI-Suche - Azure Cosmos DB für NoSQL - Schlüsseltresor – Azure AI Foundry - Speicherkonten Verstehen Sie, wie der Hub die DNS-Auflösung verarbeitet, und definieren Sie die Verantwortlichkeiten des Workloadteams für die Verwaltung privater DNS-Zoneneinträge und der Verknüpfung von DNS Private Resolver-Regeln. |
| ☐ |
Zentrale KI-Ressourcen: Das Plattformteam muss die erwartete Nutzung von Modellen und Hostingplattformen verstehen. Sie verwenden diese Informationen, um Netzwerke für zentralisierte KI-Ressourcen in Ihrer Organisation einzurichten. Jede Organisation definiert eigene KI-Einführungs- und Governancepläne, und das Workloadteam muss innerhalb dieser Einschränkungen arbeiten. |
Informieren Sie das Plattformteam über KI- und Machine Learning-Ressourcen, die Sie verwenden möchten. Diese Architektur verwendet Azure AI Foundry, Foundry Agent Service und generative Foundation-Modelle, die in Azure AI Foundry gehostet werden. Verstehen Sie eindeutig, welche zentralisierten KI-Dienste Sie verwenden müssen und wie sich diese Abhängigkeiten auf Ihre Workload auswirken. |
Von Bedeutung
Das Plattformteam sollte einem Abonnementverkaufsprozess folgen, der eine strukturierte Gruppe von Fragen verwendet, um Informationen aus dem Workloadteam zu sammeln. Diese Fragen können in allen Organisationen variieren, aber das Ziel besteht darin, die erforderlichen Eingaben zu sammeln, um Abonnements effektiv zu implementieren. Weitere Informationen finden Sie unter Abonnementverkauf.
Berechnen
Die Orchestrierungsebene und das Hosten der Chat-UI bleiben identisch mit der Basisarchitektur.
Vernetzung
In der Baselinearchitektur wird die Workload in einem einzigen virtuellen Netzwerk bereitgestellt.
Änderung von der Basislinie: Diese Architektur teilt die Arbeitsauslastung über zwei virtuelle Netzwerke auf. Eine Netzwerkhost-Workload-Komponenten. Das andere Netzwerk verwaltet Internet- und Hybridkonnektivität. Das Plattformteam bestimmt, wie das virtuelle Netzwerk der Workload in die größere Netzwerkarchitektur der Organisation integriert wird, was normalerweise einer Hub-Spoke-Topologie folgt.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Virtuelles Hubnetzwerk: Dieses virtuelle Netzwerk dient als regionaler Hub, der zentralisierte und häufig gemeinsam genutzte Dienste enthält, die mit Workloadressourcen in derselben Region kommunizieren. Der Hub befindet sich im Konnektivitätsabonnement. Das Plattformteam ist Eigentümer der Ressourcen in diesem Netz.
Virtuelles Speichennetzwerk: In dieser Architektur wird das einzelne virtuelle Netzwerk aus der Basisarchitektur im Wesentlichen zum virtuellen Speichennetzwerk. Das Plattformteam peers dieses Speichennetzwerk mit dem Hubnetzwerk. Sie besitzen und verwalten das Speichennetzwerk, einschließlich ihrer Peering- und DNS-Konfiguration. Das Workloadteam besitzt die Ressourcen in diesem Netzwerk, einschließlich seiner Subnetze. Dieses Netz enthält viele der Arbeitsressourcen.
Aufgrund dieser Abteilung des Managements und des Besitzes muss das Workloadteam die Anforderungen der Workload deutlich an das Plattformteam übermitteln.
Von Bedeutung
Für das Plattformteam: Peeren Sie das Speichennetzwerk nicht direkt mit einem anderen Speichennetzwerk, es sei denn, die Workload erfordert sie ausdrücklich. Dieses Vorgehen schützt die Segmentierungsziele der Workload. Ihr Team muss alle transitiven virtuellen Netzwerkverbindungen erleichtern. Wenn Anwendungszielzonenteams ihre Netzwerke jedoch direkt über selbstverwaltete private Endpunkte verbinden, verwaltet Ihr Team diese Verbindungen nicht.
Verstehen, welche Arbeitsauslastungsressourcen externe Teams verwalten. Verstehen Sie beispielsweise die Netzwerkkonnektivität zwischen den Chat-Agents und einer geerdeten Kontextvektordatenbank, die ein anderes Team verwaltet.
Subnetze des virtuellen Netzwerks
Im virtuellen Speichennetzwerk erstellen und zuordnen Sie die Subnetze basierend auf den Workloadanforderungen. Um eine Segmentierung bereitzustellen, wenden Sie Steuerelemente an, die den Datenverkehr in und aus den Subnetzen einschränken. Diese Architektur fügt keine Subnetze über die Subnetze in der Basisarchitektur hinaus hinzu. Die Netzwerkarchitektur erfordert jedoch nicht mehr die AzureBastionSubnet Oder AzureFirewallSubnet Subnetze, da das Plattformteam diese Funktion wahrscheinlich in ihren Abonnements hostet.
Sie müssen immer noch lokale Netzwerkkontrollen implementieren, wenn Sie Ihren Workload in einer Azure Zielzone bereitstellen. Möglicherweise erzwingt Ihre Organisation weitere Netzwerkeinschränkungen, um die Datenexfiltration zu schützen und die Sichtbarkeit des zentralen Sicherheitsbetriebszentrums und des IT-Netzwerkteams sicherzustellen.
Eingehender Datenverkehr
Der Eingehende Datenverkehrsfluss bleibt identisch mit der Basisarchitektur.
Sie verwalten Ressourcen im Zusammenhang mit dem öffentlichen Internet, die in den Workload eingehen. In dieser Architektur befinden sich beispielsweise Das Anwendungsgateway und seine öffentliche IP-Adresse im Speichennetzwerk und nicht im Hubnetzwerk. Einige Organisationen platzieren eingehende Ressourcen in einem Konnektivitätsabonnement mithilfe eines zentralen Umkreisnetzwerks (auch als DMZ, demilitarisierte Zone und abgeschirmte Subnetzimplementierung bezeichnet). Die Integration mit dieser spezifischen Topologie liegt außerhalb des Umfangs dieses Artikels.
Alternativer Ansatz zur Überprüfung des eingehenden Datenverkehrs
Diese Architektur verwendet keine Azure Firewall, um eingehenden Datenverkehr zu prüfen, aber manchmal ist die Organisationsgovernance erforderlich. In diesen Fällen unterstützt das Plattformteam die Implementierung, um Workloadteams eine zusätzliche Ebene der Angriffserkennung und -prävention bereitzustellen. Diese Ebene hilft, unerwünschten eingehenden Datenverkehr zu blockieren. Um diese Topologie zu unterstützen, erfordert diese Architektur mehr UDR-Konfigurationen. Weitere Informationen finden Sie unter Zero Trust-Netzwerk für Webanwendungen mit Azure Firewall und Anwendungsgateway.
DNS-Konfiguration
In der Basisarchitektur verwenden alle Komponenten Azure DNS direkt für die DNS-Auflösung.
Änderung von der Basislinie: In dieser Architektur führen in der Regel mindestens ein DNS-Server im Hub DNS-Auflösung aus. Wenn das virtuelle Netzwerk erstellt wird, sollten die DNS-Eigenschaften im virtuellen Netzwerk bereits entsprechend festgelegt werden. Das Workloadteam muss die Implementierungsdetails des DNS-Diensts nicht verstehen.
Diese Architektur konfiguriert die Workloadkomponenten mit DNS auf folgende Weise.
| Komponente | DNS-Konfiguration |
|---|---|
| Anwendungs-Gateway | Geerbt von virtuellem Netzwerk |
| App Service (Chat UI) | Geerbt von virtuellem Netzwerk |
| KI-Suche | Kann nicht außer Kraft gesetzt werden, verwendet Azure DNS |
| Azure AI Foundry | Kann nicht außer Kraft gesetzt werden, verwendet Azure DNS |
| Gießerei-Agentendienst | Kann nicht außer Kraft gesetzt werden, verwendet Azure DNS |
| Azure Cosmos DB (ein Microsoft-Datenbankdienst) | Kann nicht außer Kraft gesetzt werden, verwendet Azure DNS |
| Jumpbox | Geerbt von virtuellem Netzwerk |
| Build-Agents | Geerbt von virtuellem Netzwerk |
Diese Architektur konfiguriert keine DNS-Einstellungen für Komponenten, die keine ausgehende Kommunikation initiieren. Für diese Komponenten ist keine DNS-Auflösung erforderlich.
Viele Komponenten in dieser Architektur basieren auf DNS-Einträgen, die auf den DNS-Servern des Hubs gehostet werden, um die privaten Endpunkte dieser Workload aufzulösen. Weitere Informationen finden Sie unter Azure private DNS-Zonen.
Wenn die hubbasierte DNS-Auflösung nicht möglich ist, bestehen diese Komponenten den folgenden Einschränkungen:
Das Plattformteam kann keine DNS-Anforderungen protokollieren, was möglicherweise gegen eine Anforderung eines Organisationssicherheitsteams verstößt.
Das Auflösen privater Link-verfügbar gemachter Dienste in Ihrer Zielzone oder anderen Anwendungslandzonen ist möglicherweise unmöglich.
Wir empfehlen Ihnen, sich damit vertraut zu machen, wie das Plattformteam DNS verwaltet. Weitere Informationen finden Sie unter Private Link und DNS-Integration im großen Stil. Wenn Sie Komponentenfunktionen hinzufügen, die direkt von Azure DNS abhängen, können Sie Komplexitäten in die von der Plattform bereitgestellte DNS-Topologie einführen. Sie können Komponenten umgestalten oder Ausnahmen aushandeln, um die Komplexität zu minimieren.
Ausgehender Datenverkehr
In der Basisarchitektur werden alle Datenverkehrsrouten über die Azure-Firewall an das Internet weitergeleitet.
Änderung von der Basislinie: In dieser Architektur stellt die Plattform einen UDR bereit, der auf eine Azure Firewall-Instanz verweist, die sie hosten soll. Wenden Sie diesen UDR auf dieselben Subnetze in der Basisarchitektur an.
Der gesamte Datenverkehr, der das virtuelle Speichennetzwerk verlässt, einschließlich Datenverkehr aus dem Subnetz für die Agentintegration, wird über eine Ausgehende Firewall über das Peered Hub-Netzwerk umgeleitet.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Die Ost-West-Clientkommunikation mit den privaten Endpunkten für Key Vault, Azure AI Foundry und andere Dienste bleibt identisch mit der Basisarchitektur. Das vorangehende Diagramm enthält diesen Pfad nicht.
Internetverkehr an die Firewall weiterleiten
Alle Subnetze im Speichennetzwerk enthalten eine Route, die den gesamten internetgebundenen Datenverkehr oder 0.0.0.0/0 Datenverkehr an die Azure Firewall-Instanz des Hubs leitet.
| Komponente | Mechanismus zur Erzwingung des Internetverkehrs durch den Hub |
|---|---|
| Anwendungs-Gateway | Keiner. Internetgebundener Datenverkehr, der von diesem Dienst stammt, kann nicht durch die Firewall des Plattformteams erzwungen werden. |
| App Service (Chat UI) | Die regionale Integration des virtuellen Netzwerks und die Einstellung "vnetRouteAllEnabled " sind aktiviert. |
| KI-Suche | Keiner. Der von diesem Dienst ausgehende Datenverkehr kann nicht durch eine Firewall geschleust werden. Diese Architektur nutzt keine Skills. |
| Gießerei-Agentendienst | Ein UDR, der auf das Subnetz "snet-agentsEgress" angewendet wird. |
| Sprungfelder | Ein UDR, der auf das Snet-Jumpbox-Subnetz angewendet wird. |
| Build-Agents | Ein UDR, der auf das Snet-Agents-Subnetz angewendet wird. |
Diese Architektur konfiguriert kein Erzwingen des Tunnelings für Komponenten, die keine ausgehende Kommunikation initiieren.
Für Komponenten oder Features, die den Datenverkehr nicht über den Hub weiterleiten können, muss Ihr Workloadteam die Anforderungen der Organisation erfüllen. Um diese Anforderungen zu erfüllen, verwenden Sie Ausgleichssteuerelemente, entwerfen Sie die Workload neu, um nicht unterstützte Features auszuschließen oder formale Ausnahmen anzufordern. Sie sind dafür verantwortlich, Datenexfiltration und Missbrauch zu mildern.
Wenden Sie die von der Plattform bereitgestellte Internetroute auf alle Subnetze an, auch wenn Sie nicht erwarten, dass das Subnetz ausgehenden Datenverkehr hat. Mit diesem Ansatz wird sichergestellt, dass unerwartete Bereitstellungen in diesem Subnetz routinebasierte Ausgangsfilterung durchlaufen. Aktivieren Sie für Subnetze, die private Endpunkte enthalten, Netzwerkrichtlinien, um das vollständige Routing und die NSG-Steuerung zu unterstützen.
Diese Routenkonfiguration stellt sicher, dass alle ausgehenden Verbindungen von App Service, Azure AI Foundry und seinen Projekten sowie alle anderen Dienste, die aus dem virtuellen Netzwerk der Workload stammen, überprüft und gesteuert werden.
Azure Private-DNS-Zonen
Workloads, die private Endpunkte für ost-west-Datenverkehr verwenden, erfordern DNS-Zoneneinträge im konfigurierten DNS-Anbieter. Zur Unterstützung von Private Link basiert diese Architektur auf vielen DNS-Zoneneinträgen für Dienste wie Key Vault, Azure AI Foundry und Azure Storage.
Änderung von der Basislinie: In der Basisarchitektur verwaltet das Workloadteam direkt die privaten DNS-Zonen. In dieser Architektur verwaltet das Plattformteam in der Regel private DNS-Zonen. Das Workloadteam muss die Anforderungen und Erwartungen des Plattformteams für die Verwaltung der privaten DNS-Zoneneinträge klar verstehen. Das Plattformteam kann andere Technologien anstelle privater DNS-Zoneneinträge verwenden.
In dieser Architektur muss das Plattformteam DNS für die folgenden Azure AI Foundry FQDN-API-Endpunkte einrichten:
privatelink.services.ai.azure.comprivatelink.openai.azure.comprivatelink.cognitiveservices.azure.com
Das Plattformteam muss auch DNS für die folgenden FQDNs einrichten, die Foundry Agent Service-Abhängigkeiten sind:
privatelink.search.windows.netprivatelink.blob.core.windows.netprivatelink.documents.azure.com
Von Bedeutung
Die DNS-Auflösung muss ordnungsgemäß innerhalb der speichen virtual funktionieren, bevor Sie den Funktionshost für den Foundry Agent Service und während des Betriebs des Foundry Agent Service bereitstellen. Die Foundry Agent Service-Funktion verwendet die DNS-Konfiguration Ihres virtuellen Speichennetzwerks nicht. Daher wird empfohlen, dass Ihr Plattformteam ein Regelsatz für die privaten DNS-Zonen der Workload in DNS Private Resolver konfiguriert und diese Regeln mit Ihrer Anwendungslandzone verknüpft.
Bevor Sie Azure AI Foundry und seine Agentfunktion bereitstellen, müssen Sie warten, bis die Abhängigkeiten des Foundry Agent Service vollständig für ihre privaten Endpunkte innerhalb des Speichennetzwerks aufgelöst werden können. Diese Anforderung ist besonders wichtig, wenn DINE-Richtlinien Updates für PRIVATE DNS-Zonen behandeln. Wenn Sie versuchen, die Foundry Agent Service-Funktion bereitzustellen, bevor die privaten DNS-Einträge innerhalb Ihres Subnetzes aufgelöst werden können, schlägt die Bereitstellung fehl.
Das Plattformteam muss auch die privaten DNS-Zonen für andere Workloadabhängigkeiten in dieser Architektur hosten:
privatelink.vaultcore.azure.netprivatelink.azurewebsites.net
Datenwissenschaftler und Agent-Entwicklerzugriff
Wie bei der Basisarchitektur deaktiviert diese Architektur den öffentlichen Eingangszugriff auf das Azure AI Foundry-Portal und andere browserbasierte Erfahrungen. Die Basisarchitektur stellt ein Sprungfeld bereit, um einen Browser mit einer Quell-IP-Adresse aus dem virtuellen Netzwerk bereitzustellen, die von verschiedenen Workloadrollen verwendet wird.
Wenn Ihre Workload eine Verbindung mit einer Azure-Zielzone herstellt, erhält Ihr Team mehr Zugriffsoptionen. Arbeiten Sie mit dem Plattformteam zusammen, um festzustellen, ob Sie privaten Zugriff auf verschiedene browserbasierte Azure AI Foundry-Portale erhalten können, ohne einen virtuellen Computer (VM) zu verwalten und zu verwalten. Dieser Zugriff kann durch transitives Routing von einer vorhandenen ExpressRoute- oder VPN-Gatewayverbindung möglich sein.
Der native arbeitsplatzbasierte Zugriff erfordert ein standortübergreifendes Routing und eine DNS-Auflösung, die das Plattformteam bereitstellen kann. Schließen Sie diese Anforderung in Ihre Abonnementverkaufsanfrage ein.
Die Bereitstellung nativer arbeitsstationbasierter Zugriff auf diese Portale verbessert die Produktivität und vereinfacht die Wartung im Vergleich zur Verwaltung von VM-Sprungfeldern.
Die Rolle des Sprungkastens
Das Sprungfeld in dieser Architektur bietet Wert für die operative Unterstützung, nicht für Laufzeitzwecke oder KI- und Machine Learning-Entwicklung. Die Jumpbox kann DNS- und Netzwerk-Routing-Probleme beheben, da sie einen internen Netzwerkzugang zu sonst nicht zugänglichen Komponenten bietet.
In der Basisarchitektur greift Azure Bastion auf das Sprungfeld zu, das Sie verwalten.
In dieser Architektur wird Azure Bastion im Konnektivitätsabonnement als gemeinsam genutzte regionale Ressource bereitgestellt, die das Plattformteam verwaltet. Um diesen Anwendungsfall in dieser Architektur zu veranschaulichen, befindet sich Azure Bastion im Konnektivitätsabonnement, und Ihr Team stellt ihn nicht bereit.
Der virtuelle Computer, der als Sprungfeld dient, muss den Organisationsanforderungen für virtuelle Computer entsprechen. Zu diesen Anforderungen gehören z. B. Unternehmensidentitäten in Microsoft Entra ID, spezifische Basis-Images und Patching-Regelungen.
Überwachen von Ressourcen
Die Azure-Zielzonenplattform stellt freigegebene Ressourcen für Einblicke im Rahmen des Verwaltungsabonnements bereit. Es wird jedoch empfohlen, Ihre eigenen Überwachungsressourcen bereitzustellen, um die Verantwortlichkeiten der Workload zu vereinfachen. Dieser Ansatz richtet sich an die Basisarchitektur.
Sie stellen die folgenden Überwachungsressourcen bereit:
Application Insights dient als APM-Dienst (Application Performance Management) für Ihr Team. Sie konfigurieren diesen Dienst in der Chat-UI, dem Foundry Agent Service und den Modellen.
Der Azure Monitor Logs-Arbeitsbereich dient als einheitliche Spüle für alle Protokolle und Metriken aus Ressourcen im Besitz der Workload.
Ähnlich wie bei der Basisarchitektur müssen alle Ressourcen Azure-Diagnoseprotokolle an den Arbeitsbereich "Azure Monitor Logs" senden, den Ihr Team vorgibt. Diese Konfiguration ist Teil der Infrastruktur als Codebereitstellung (IaC) der Ressourcen. Möglicherweise müssen Sie auch Protokolle an einen zentralen Arbeitsbereich für Azure Monitor Logs senden. In Azure-Zielzonen befindet sich dieser Arbeitsbereich in der Regel im Verwaltungsabonnement.
Das Plattformteam verfügt möglicherweise über weitere Prozesse, die sich auf Ressourcen in der Anwendungslandungszone auswirken. Sie können z. B. DINE-Richtlinien verwenden, um Diagnosen zu konfigurieren und Protokolle an zentralisierte Verwaltungsabonnements zu senden. Sie können auch Die Baseline-Warnungen von Azure Monitor über eine Richtlinie anwenden. Stellen Sie sicher, dass Ihre Implementierung diese zusätzlichen Protokollierungs- und Warnungsflüsse nicht blockiert.
Azure-Richtlinie
Die Basisarchitektur empfiehlt allgemeine Richtlinien , um die Arbeitsauslastung zu steuern. Wenn Sie diese Architektur in einer Zielzone einer Anwendung bereitstellen, müssen Sie keine zusätzlichen Richtlinien hinzufügen oder entfernen. Um die Governance zu erzwingen und die Sicherheit dieser Workload zu verbessern, wenden Sie weiterhin Richtlinien auf Ihr Abonnement, Ihre Ressourcengruppen oder Ressourcen an.
Erwarten Sie, dass das Abonnement der Anwendungszielzone über vorhandene Richtlinien verfügt, auch bevor Sie die Workload bereitstellen. Einige Richtlinien unterstützen die Unternehmensführung, indem sie bestimmte Konfigurationen in Bereitstellungen überprüfen oder blockieren.
Die folgenden Beispielrichtlinien können zu Komplexitäten der Workloadbereitstellung führen:
Richtlinie:Geheime Schlüssel [im Schlüsseltresor] sollten den angegebenen maximalen Gültigkeitszeitraum aufweisen.
Komplikation: Azure AI Foundry kann Geheimnisse im Zusammenhang mit Wissen und Toolverbindungen in einem verbundenen Key Vault speichern. Diese geheimen Schlüssel haben kein Ablaufdatum, das vom Dienst festgelegt ist. Die Basisarchitektur verwendet diese Arten von Verbindungen nicht, Sie können die Architektur jedoch erweitern, um sie zu unterstützen.
Richtlinie:KI-Suchdienste sollten vom Kunden verwaltete Schlüssel verwenden, um ruhende Daten zu verschlüsseln.
Komplikation: Diese Architektur erfordert keine vom Kunden verwalteten Schlüssel. Sie können die Architektur jedoch erweitern, um sie zu unterstützen.
Policy:AI Foundry-Modelle sollten keine Vorschau sein.
Komplikation: Möglicherweise arbeiten Sie in der Entwicklung mit einem Vorschaumodell, das Sie erwarten, dass sie zum Zeitpunkt der Aktivierung der Agent-Funktion in Ihrer Produktionsauslastung allgemein verfügbar ist.
Plattformteams können DINE-Richtlinien anwenden, um automatische Bereitstellungen in einem Anwendungs-Zielzonen-Abonnement zu verwalten. Integrieren und testen Sie die von der Plattform initiierten Einschränkungen und Änderungen präventiv in Ihre IaC-Vorlagen. Wenn das Plattformteam Azure-Richtlinien verwendet, die mit den Anforderungen der Anwendung in Konflikt geraten, können Sie eine Lösung aushandeln.
Änderungen im Laufe der Zeit verwalten
In dieser Architektur dienen von der Plattform bereitgestellte Dienste und Vorgänge als externe Abhängigkeiten. Das Plattformteam arbeitet weiter an der Umsetzung von Änderungen, an der Einrichtung von Zielzonen und an der Kostenkontrolle. Das Plattformteam priorisiert möglicherweise keine einzelnen Workloads. Änderungen an diesen Abhängigkeiten, z. B. Firewall-Änderungen, können sich auf mehrere Workloads auswirken.
Sie müssen mit Plattformteams effizient und zeitnah kommunizieren, um alle externen Abhängigkeiten zu verwalten. Es ist wichtig, die Änderungen vorher zu testen, damit sie sich nicht negativ auf die Arbeitslast auswirken.
Plattformänderungen, die sich auf die Workload auswirken
In dieser Architektur verwaltet das Plattformteam die folgenden Ressourcen. Änderungen an diesen Ressourcen können sich potenziell auf die Zuverlässigkeit, Sicherheit, den Betrieb und die Leistungsziele der Workload auswirken. Bewerten Sie diese Änderungen, bevor das Plattformteam sie implementiert, um zu bestimmen, wie sie sich auf die Arbeitsauslastung auswirken.
Azure-Richtlinien: Änderungen an Azure-Richtlinien können sich auf Workload-Ressourcen und deren Abhängigkeiten auswirken. Diese Änderungen können direkte Richtlinienaktualisierungen oder die Bewegung der Zielzone in eine neue Verwaltungsgruppenhierarchie umfassen. Diese Änderungen können bis zu einer neuen Bereitstellung unbemerkt bleiben, sodass Sie sie gründlich testen müssen.
Beispiel: Eine Richtlinie lässt die Bereitstellung von Azure Cosmos DB-Instanzen, die vom Kunden verwaltete Schlüsselverschlüsselung erfordern, nicht mehr zu, und Ihre Architektur verwendet die von Microsoft verwaltete Schlüsselverschlüsselung.
Firewallregeln: Änderungen an Firewallregeln können sich auf das virtuelle Netzwerk der Workload oder auf Regeln auswirken, die allgemein für den gesamten Datenverkehr gelten. Diese Änderungen können zu blockiertem Datenverkehr und sogar zu stillen Prozessausfällen führen. Diese potenziellen Probleme gelten sowohl für die Egress-Firewall als auch für die von Azure Virtual Network Manager angewandten NSG-Regeln.
Beispiel: Blockierter Datenverkehr zu Bing-APIs führt zu fehlgeschlagenen Agent-Toolaufrufen für Internet-Grounding-Daten.
Routing im Hubnetzwerk: Änderungen in der transitiven Art des Routings im Hub können sich möglicherweise auf die Workload-Funktionalität auswirken, wenn eine Workload vom Routing zu anderen virtuellen Netzwerken abhängt.
Beispiel: Eine Routingänderung verhindert, dass Azure AI Foundry-Agents auf einen Vektorspeicher zugreifen, der von einem anderen Team betrieben wird, oder verhindert, dass Data Science-Teams von ihren Arbeitsstationen aus auf das KI Foundry-Portal zugreifen.
Azure Bastion Host: Änderungen an der Verfügbarkeit oder Konfiguration des Azure Bastion-Hosts.
Beispiel: Eine Konfigurationsänderung verhindert den Zugriff auf Sprungfelder und Build-Agent-VMs.
Workloadänderungen mit Auswirkungen auf die Plattform
In den folgenden Beispielen werden Workloadänderungen beschrieben, die Sie mit dem Plattformteam kommunizieren sollten. Das Plattformteam muss die Zuverlässigkeit, Sicherheit, Vorgänge und Leistungsziele des Plattformdiensts anhand Ihrer neuen Änderungen überprüfen, bevor sie wirksam werden.
Netzwerkausgang: Überwachen Sie jeden signifikanten Anstieg des Netzwerkausgangs, um zu verhindern, dass die Arbeitslast zu einem Noisy-Neighbor-Effekt auf Netzwerkgeräten wird. Dieses Problem kann sich möglicherweise auf die Leistungs- oder Zuverlässigkeitsziele anderer Workloads auswirken. Diese Architektur ist größtenteils eigenständig und ist unwahrscheinlich, dass eine erhebliche Änderung der Ausgehenden Datenverkehrsmuster auftreten kann.
Öffentlicher Zugriff: Änderungen am öffentlichen Zugriff für Workloadkomponenten erfordern möglicherweise zusätzliche Tests. Das Plattformteam kann die Arbeitsauslastung in eine andere Verwaltungsgruppe verschieben.
Beispiel: Wenn Sie in dieser Architektur die öffentliche IP-Adresse aus dem Application Gateway entfernen und diese Anwendung nur noch intern nutzen, ändert sich die Exposition des Workloads gegenüber dem Internet. Ein weiteres Beispiel ist die Veröffentlichung der browserbasierten KI-Portale im Internet, die wir nicht empfehlen.
Bewertung der Unternehmenskritischen Bewertung: Änderungen an den Vereinbarungen auf Serviceebene (Service Level Agreements, SLAs) der Workload erfordern möglicherweise einen neuen Ansatz für die Zusammenarbeit zwischen plattform- und Workloadteams.
Beispiel: Ihre Arbeitsauslastung kann aufgrund einer erhöhten Akzeptanz und des Erfolgs von geringem zu hohem Unternehmen kritisch übergehen.
Team für Unternehmensarchitektur
Einige Organisationen verfügen über ein Unternehmensarchitekturteam, das den Entwurf Ihrer Arbeitsauslastung und deren Architektur beeinflussen kann. Dieses Team versteht die KI-Einführungsstrategie des Unternehmens sowie die Prinzipien und Empfehlungen in den AI-Workloads im Azure-Design . Arbeiten Sie mit diesem Team zusammen, um sicherzustellen, dass diese Chatarbeitsauslastung szenariospezifische Ziele erfüllt und mit der Organisationsstrategie und -empfehlungen übereinstimmt.
Überlegungen
Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.
Zuverlässigkeit
Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.
Diese Architektur behält die Zuverlässigkeitsgarantien in der Basisarchitektur bei. Es werden keine neuen Zuverlässigkeitsüberlegungen für die Kernworkloadkomponenten eingeführt.
Kritische Abhängigkeiten
Behandeln Sie alle Funktionen, die die Workload in der Plattform und der Anwendungs-Zielzone als Abhängigkeiten ausführt. Verwalten Sie Vorfallreaktionspläne, die Kontaktmethoden und Eskalationspfade für jede Abhängigkeit enthalten. Schließen Sie diese Abhängigkeiten in die Fehlermodusanalyse (FMA) der Workload ein.
Berücksichtigen Sie die folgenden Workloadabhängigkeiten und Beispielszenarien, die auftreten können:
Ausgangsfirewall: Die zentrale Ausgangsfirewall unterliegt Änderungen, die sich nicht auf die Arbeitsauslastung bezieht. Mehrere Workloads teilen die Firewall.
DNS-Auflösung: Diese Architektur verwendet DNS, das vom Plattformteam für die meisten Ressourcen bereitgestellt wird, kombiniert mit Azure DNS und verknüpften DNS Private Resolver-Rulesets für foundry Agent Service. Die Arbeitsauslastung hängt daher von rechtzeitigen Aktualisierungen von DNS-Einträgen für private Endpunkte und die Verfügbarkeit von DNS-Diensten ab.
DINE-Richtlinien: DINE-Richtlinien für private Azure-DNS-Zonen oder andere plattformbezogene Abhängigkeiten funktionieren auf best-effort-Basis und enthalten keine SLA. Beispielsweise kann eine Verzögerung bei der DNS-Konfiguration für die privaten Endpunkte dieser Architektur verhindern, dass die Chat-UI datenverkehrsbereit wird oder die Agents daran hindern, Foundry Agent Service-Abfragen abzuschließen.
Verwaltungsgruppenrichtlinien: Konsistente Richtlinien zwischen Umgebungen unterstützen Zuverlässigkeit. Stellen Sie sicher, dass Vorproduktionsumgebungen mit Produktionsumgebungen übereinstimmen, um genaue Tests bereitzustellen und umgebungsspezifische Abweichungen zu verhindern, die eine Bereitstellung oder Skalierung blockieren können. Weitere Informationen finden Sie unter Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.
Viele dieser Überlegungen können ohne Azure-Landungszonen vorhanden sein. Sie müssen mit Plattformteams zusammenarbeiten, um diese Probleme zu beheben und sicherzustellen, dass Sie alle Anforderungen erfüllen. Weitere Informationen finden Sie unter Identifizieren von Abhängigkeiten.
Sicherheit
Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.
Kontrolle des eingehenden Datenverkehrs
Um Ihre Arbeitsauslastung von anderen Workload-Speichen in Ihrer Organisation zu isolieren, wenden Sie NSGs auf Ihre Subnetze an, und verwenden Sie die nichttransitive Natur oder Steuerelemente im regionalen Hub. Erstellen Sie umfassende NSGs, die nur die eingehenden Netzwerkanforderungen Ihrer Anwendung und ihrer Infrastruktur zulassen. Wir empfehlen, dass Sie sich aus Sicherheitsgründen nicht ausschließlich auf die nichttransitive Art des Hubnetzwerks verlassen.
Das Plattformteam setzt Azure Sicherheitsrichtlinien um. Eine Richtlinie könnte beispielsweise sicherstellen, dass Application Gateway eine Web Application Firewall hat, die auf Deny Mode eingestellt ist, wodurch die Anzahl der öffentlichen IP-Adressen, die für Ihr Abonnement verfügbar sind, eingeschränkt wird. Zusätzlich zu diesen Richtlinien sollten Sie mehr workloadorientierte Richtlinien bereitstellen, die den Eingehenden Sicherheitsstatus verstärken.
Die folgende Tabelle enthält Beispiele für Eingangssteuerelemente in dieser Architektur.
| Quelle | Zweck | Workload-Steuerung | Plattformsteuerung |
|---|---|---|---|
| Internet | Datenverkehrsströme der Anwendung | Trichter aller Workloadanforderungen über eine NSG, eine Webanwendungsfirewall und Routingregeln, bevor der öffentliche Datenverkehr auf den privaten Datenverkehr für die Chatbenutzeroberfläche umgestellt werden kann. | Nichts |
| Internet | Zugriff auf azure AI Foundry-Portal und REST-API-Zugriff auf Datenebene | Allen Zugriff über die Konfiguration auf Dienstebene verweigern. | Nichts |
| Internet | Datenebenenzugriff auf alle Dienste mit Ausnahme des Anwendungsgateways | Allen Zugriff über NSG-Regeln und Konfiguration auf Dienstebene verweigern. | Nichts |
| Azure Bastion | Zugriff auf Jump Box und Build Agent | Wenden Sie eine NSG auf das Sprungfeld-Subnetz an, das den gesamten Datenverkehr an Remotezugriffsports blockiert, es sei denn, die Quelle ist das vom Plattform festgelegte Azure Bastion-Subnetz. | Nichts |
| Standortübergreifendes | Zugriff auf azure AI Foundry-Portal und REST-API-Zugriff auf Datenebene | Allen Zugriff verweigern. Wenn Sie das Sprungfeld nicht verwenden, erlauben Sie den Zugriff nur von Arbeitsstationen in autorisierten Subnetzen für Data Scientists. | Erzwingen eines nichttransitiven Routings oder Verwenden der Azure Firewall in einem durch Azure Virtual WAN gesicherten Hub |
| Andere Spokes | Nichts | Durch NSG-Regeln blockiert. | Erzwingen eines nichttransitiven Routings oder Verwenden der Azure Firewall in einem durch virtuelles WAN gesicherten Hub |
Kontrolle des ausgehenden Datenverkehrs
Wenden Sie NSG-Regeln an, die die erforderlichen ausgehenden Konnektivitätsanforderungen Ihrer Lösung ausdrücken, und lehnen Sie alles andere ab. Verlassen Sie sich nicht nur auf die Hubnetzwerksteuerelemente. Als Workload-Operator müssen Sie unerwünschten Ausgehenden Datenverkehr so nah an der Quelle wie möglich beenden.
Sie besitzen die Subnetze Ihrer Workload innerhalb des virtuellen Netzwerks, aber das Plattformteam hat wahrscheinlich Firewallregeln erstellt, um ihre erfassten Anforderungen im Rahmen Ihres Abonnementverkaufsprozesses speziell darzustellen. Stellen Sie sicher, dass Änderungen an Subnetzen und Ressourcenplatzierungen während der Lebensdauer Ihrer Architektur mit Ihrer ursprünglichen Anforderung kompatibel bleiben. Arbeiten Sie mit Ihrem Netzwerkteam zusammen, um die Kontinuität der Least-Access-Egress-Kontrolle sicherzustellen.
Die folgende Tabelle zeigt Beispiele für Ausgangssteuerelemente in dieser Architektur.
| Endpunkt | Zweck | Workload-Steuerung | Plattformsteuerung |
|---|---|---|---|
| Öffentliche Internetquellen | Ihr Agent erfordert möglicherweise eine Internetsuche, um eine Azure OpenAI in Foundry Models-Anforderung zu ernennen. | Anwenden von NSGs auf das Agentintegrationssubnetz | Anwenden von Firewallanwendungsregeln für externe Wissensspeicher und -tools |
| Azure AI Foundry-Datenebene | Die Chat-UI interagiert mit dem Chat-Agent | Tcp/443 aus dem App Service-Integrationssubnetz in das private Azure AI Foundry-Subnetz zulassen | Nichts |
| Azure Cosmos DB (ein Microsoft-Datenbankdienst) | So greifen Sie über den Foundry Agent Service auf die Speicherdatenbank zu | Zulassen von TCP für jeden Port zum privaten Azure Cosmos DB-Endpunkt-Subnetz | Nichts |
Für Datenverkehr, der das virtuelle Netzwerk der Workload verlässt, wendet diese Architektur Steuerelemente auf Arbeitsauslastungsebene über NSGs und auf Plattformebene über eine Hub-Netzwerkfirewall an. Die NSGs stellen anfängliche, allgemeine Regeln für den Netzwerkdatenverkehr bereit. Im Hub der Plattform wendet die Firewall spezifischere Regeln für zusätzliche Sicherheit an.
Diese Architektur erfordert keinen Ost-West-Datenverkehr zwischen internen Komponenten, z. B. Foundry Agent Service und dessen abhängiger KI-Suchinstanz, um über das Hubnetzwerk zu leiten.
DDoS-Schutz
Ermitteln Sie, wer den DDoS-Schutzplan anwenden soll, der die öffentlichen IP-Adressen Ihrer Lösung abdeckt. Das Plattformteam verwendet möglicherweise IP-Adressschutzpläne, oder sie verwenden Azure-Richtlinie zum Erzwingen von Plänen zum Schutz virtueller Netzwerke. Für diese Architektur ist eine DDoS-Schutzabdeckung erforderlich, da sie über eine öffentliche IP-Adresse für den Ausgang aus dem Internet verfügt. Weitere Informationen finden Sie unter Empfehlungen für Netzwerk und Konnektivität.
Identitäts- und Zugriffsverwaltung
Sofern die Governanceautomatisierung des Plattformteams keine zusätzlichen Kontrollen erfordert, führt diese Architektur aufgrund der Beteiligung des Plattformteams keine neuen Autorisierungsanforderungen ein. Die rollenbasierte Zugriffssteuerung (Azure Role-Based Access Control, RBAC) sollte weiterhin das Prinzip der geringsten Rechte erfüllen, das nur personen, die sie benötigen, und nur bei Bedarf eingeschränkten Zugriff gewährt. Weitere Informationen finden Sie unter Empfehlungen für die Identitäts- und Zugriffsverwaltung.
Zertifikate und Verschlüsselung
Ihr Team beschafft in der Regel das TLS-Zertifikat für die öffentliche IP-Adresse auf dem Anwendungsgateway. Arbeiten Sie mit dem Plattformteam zusammen, um zu verstehen, wie die Beschaffungs- und Verwaltungsprozesse von Zertifikaten den organisatorischen Erwartungen entsprechen sollten.
Alle Datenspeicherdienste in dieser Architektur unterstützen von Microsoft verwaltete oder vom Kunden verwaltete Verschlüsselungsschlüssel. Verwenden Sie vom Kunden verwaltete Verschlüsselungsschlüssel, wenn Ihr Workload-Design oder Ihre Organisation mehr Kontrolle erfordert. Azure-Landezonen selbst haben keine bestimmte Methode.
Kostenoptimierung
Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.
Alle Kostenoptimierungsstrategien in der Basisarchitektur gelten für die Workloadressourcen in dieser Architektur.
Diese Architektur profitiert stark von den Ressourcen der Azure Zielzone Plattform. Beispielsweise wechseln Ressourcen wie Azure Firewall und DDoS Protection von Workload zu Plattformressourcen. Selbst wenn Sie diese Ressourcen über ein Chargebackmodell verwenden, sind die zusätzlichen Sicherheits- und standortübergreifenden Verbindungen kostengünstiger als die selbstverwaltende Verwaltung dieser Ressourcen. Nutzen Sie andere zentralisierte Angebote Ihres Plattformteams, um diese Vorteile auf Ihre Arbeitsauslastung zu erweitern, ohne sein Ziel, das Ziel der Wiederherstellungszeit oder das Ziel des Wiederherstellungspunkts zu beeinträchtigen.
Von Bedeutung
Versuchen Sie nicht, Die Kosten zu optimieren, indem Sie Azure AI Foundry-Abhängigkeiten als Plattformressourcen konsolidieren. Diese Dienste müssen Arbeitsauslastungsressourcen bleiben.
Operative Exzellenz
„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Checkliste für die Designüberprüfung zur betrieblichen Exzellenz.
Sie bleiben für alle überlegungen zur betrieblichen Exzellenz aus der Basisarchitektur verantwortlich. Zu diesen Zuständigkeiten gehören Überwachung, GenAIOps, Qualitätssicherung und sichere Bereitstellungspraktiken.
Daten aus mehreren Senken korrelieren
Der Azure Monitor Logs-Arbeitsbereich der Workload speichert die Protokolle und Metriken der Workload und seine Infrastrukturkomponenten. Ein zentraler Azure Monitor Logs-Arbeitsbereich speichert jedoch häufig Protokolle und Metriken aus zentralisierten Diensten, z. B. Azure Firewall, DNS Private Resolver und Azure Bastion. Das Korrelieren von Daten aus mehreren Senken kann eine komplexe Aufgabe sein.
Korrelierte Daten unterstützen die Reaktion auf Vorfälle. Das Triage-Runbook für diese Architektur sollte diese Situation beheben und Organisationskontaktinformationen enthalten, wenn das Problem über Arbeitsauslastungsressourcen hinausgeht. Workload-Administratoren benötigen möglicherweise Unterstützung von Plattformadministratoren, um Protokolleinträge aus Unternehmensnetzwerk-, Sicherheits- oder anderen Plattformdiensten zu korrelieren.
Von Bedeutung
Für das Plattformteam: Gewähren Sie nach Möglichkeit RBAC-Berechtigungen zum Abfragen und Lesen von Protokollen für relevante Plattformressourcen. Aktivieren Sie Firewall-Protokolle für die Auswertung von Netzwerk- und Anwendungsregeln und DNS-Proxy. Die Anwendungsteams können diese Informationen zur Fehlerbehebung nutzen. Weitere Informationen finden Sie unter Empfehlungen zur Überwachung und Erkennung von Bedrohungen.
Build-Agents
Viele Dienste in dieser Architektur verwenden private Endpunkte. Ähnlich wie bei der Basisarchitektur erfordert dieses Design möglicherweise Build-Agents. Ihr Team stellt die Build-Agents sicher und zuverlässig bereit. Das Plattformteam ist nicht an diesem Prozess beteiligt.
Stellen Sie sicher, dass die Build-Agent-Verwaltung den Organisationsstandards entspricht. Diese Standards können die Verwendung von plattformbestimmten Betriebssystemimages, Patchingzeitplänen, Complianceberichten und Benutzerauthentifizierungsmethoden umfassen.
Leistungseffizienz
Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Workload, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.
Die Überlegungen zur Leistungseffizienz in der Basisarchitektur gelten auch für diese Architektur. Ihr Team behält die Kontrolle über die Ressourcen in den Anwendungsflüssen, nicht über das Plattformteam. Skalieren Sie den Chat-UI-Host, Sprachmodelle und andere Komponenten entsprechend der Workload und Kosteneinschränkungen. Berücksichtigen Sie abhängig von der endgültigen Implementierung Ihrer Architektur die folgenden Faktoren, wenn Sie ihre Leistung anhand von Leistungszielen messen:
- Ausgehende und standortübergreifende Latenzzeiten
- SKU-Einschränkungen durch Kosteneinschränkungsgovernance
Bereitstellen dieses Szenarios
Stellen Sie eine Implementierung der Zielzone dieser Referenzarchitektur bereit.
Beitragende
Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.
Hauptautoren:
- Bilal Amjad | Microsoft Cloud Solution Architect
- Freddy Ayala | Microsoft Cloud Solution Architect
- Chad Kittel | Principal Software Engineer – Azure Patterns & Practices
Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.
Nächster Schritt
Erfahren Sie, wie Sie mit dem Plattformteam an technischen Details zusammenarbeiten.
Zugehörige Ressource
- Eine Well-Architected Framework-Perspektive auf AI-Workloads in Azure