Ten artykuł jest częścią serii, która opiera się na kompleksowej architekturze linii bazowej czatu usługi Azure OpenAI Service. Zapoznaj się z architekturą punktu odniesienia, aby zrozumieć zmiany, które należy wprowadzić podczas wdrażania architektury w subskrypcji strefy docelowej aplikacji platformy Azure.
W tym artykule opisano architekturę generowanego obciążenia sztucznej inteligencji, które wdraża tę samą aplikację czatu bazowego, ale korzysta z zasobów spoza zakresu zespołu roboczego. Te zasoby są współużytkowane przez inne zespoły ds. obciążeń i są centralnie zarządzane przez zespoły platform organizacji. Zasoby udostępnione obejmują zasoby sieciowe służące do łączenia się z lokalizacjami lokalnymi lub z nich, zasobami zarządzania dostępem do tożsamości i zasadami. Te wskazówki dotyczą organizacji korzystających ze stref docelowych platformy Azure w celu zapewnienia spójnego ładu i wydajności kosztów.
Usługa Azure AI Foundry ma koncepcję centrów i projektów. Potencjalną implementacją strefy docelowej może być zaimplementowanie centrum jako scentralizowanego zasobu i projektów jako delegowanych zasobów obciążenia. Ta architektura nie zawiera wskazówek dotyczących tego podejścia. Zamiast tego ta architektura koncentruje się na obciążeniu jako właściciel wystąpienia usługi Azure AI Foundry.
Jako właściciel obciążenia możesz odciążyć zarządzanie zasobami udostępnionymi zespołom platformy, aby skoncentrować się na wysiłkach programistycznych obciążeń. W tym artykule przedstawiono perspektywę zespołu roboczego. Określono zalecenia dla zespołu platformy.
Ważne
Co to są strefy docelowe platformy Azure?
Strefy docelowe platformy Azure przedstawiają dwa obszary zużycia chmury w organizacji. Strefa docelowa aplikacji to subskrypcja platformy Azure, w której działa obciążenie. Strefa docelowa aplikacji jest połączona z udostępnionymi zasobami platformy organizacji. Za pośrednictwem tego połączenia strefa docelowa ma dostęp do infrastruktury obsługującej obciążenie, takie jak sieć, zarządzanie dostępem do tożsamości, zasady i monitorowanie. Strefa docelowa platformy to kolekcja różnych subskrypcji, którymi może zarządzać wiele zespołów platformy. Każda subskrypcja ma określoną funkcję. Na przykład subskrypcja łączności zapewnia scentralizowane rozpoznawanie systemu nazw domen (DNS), łączność między lokalizacjami i wirtualne urządzenia sieciowe (WUS), które są dostępne dla zespołów platformy do użycia.
Zalecamy zapoznanie się ze strefami docelowymi platformy Azure, ich zasadami projektowania i obszarami projektowania, aby ułatwić wdrożenie tej architektury.
Układ artykułu
Architektura | Decyzje projektowe | Podejście azure Well-Architected Framework |
---|---|---|
▪ Diagram architektury ▪ Zasoby obciążenia ▪ Zasoby federacyjne |
▪ Konfiguracja subskrypcji ▪ Liczyć ▪ Sieci ▪ Dostęp analityka danych ▪ Monitorowanie zasobów ▪ Nadzór organizacyjny ▪ Zarządzanie zmianami |
▪ Niezawodność ▪ Bezpieczeństwo ▪ Optymalizacja kosztów ▪ Doskonałość operacyjna ▪ Wydajność |
Napiwek
Implementacja referencyjna czatu usługi Azure OpenAI pokazuje najlepsze rozwiązania opisane w tym artykule. Przed podjęciem i wdrożeniem decyzji projektowych zapoznaj się z tym wskazówkami.
Architektura
Diagram architektury podzielony na dwie główne sekcje. Niebieska sekcja jest oznaczona etykietą subskrypcja strefy docelowej aplikacji. Dolna sekcja jest żółta i ma etykietę subskrypcja strefy docelowej platformy. Górne pole zawiera zarówno zasoby utworzone przez obciążenie, jak i zasoby subskrypcji. Zasoby obciążenia składają się z usługi Application Gateway i zapory aplikacji internetowej, usługi App Service i jej podsieci integracji, prywatnych punktów końcowych dla rozwiązań typu platforma jako usługa (PaaS), takich jak Azure Storage, Azure Key Vault, Azure AI Search, Azure OpenAI Service i Container Registry. Zasoby obciążenia mają również obszar roboczy usługi Azure AI Foundry i zasoby monitorowania. aplikacja systemu Azure Service pokazuje trzy wystąpienia, z których każda jest w innej strefie platformy Azure. Subskrypcja platformy zawiera sieć wirtualną koncentratora, usługę Azure Firewall, usługę Azure Bastion oraz szarą bramę sieci VPN i usługę ExpressRoute. Istnieje komunikacja równorzędna sieci wirtualnych między siecią wirtualną w strefie docelowej aplikacji a siecią wirtualną koncentratora.
Pobierz plik programu Visio z tą architekturą.
Składniki
Wszystkie architektury strefy docelowej platformy Azure mają separację własności między zespołem platformy a zespołem obciążenia, nazywanym demokratyzacją subskrypcji. Architekci aplikacji, analitycy danych i zespoły DevOps muszą mieć silne zrozumienie tej odpowiedzialności, aby wiedzieć, co jest pod ich bezpośrednim wpływem lub kontrolą, a co nie.
Podobnie jak większość implementacji strefy docelowej aplikacji, zespół obciążenia jest głównie odpowiedzialny za konfigurację, zarządzanie i wdrażanie składników obciążenia, w tym wszystkie usługi sztucznej inteligencji używane w tej architekturze.
Zasoby należące do zespołu obciążeń
Następujące zasoby pozostają w większości niezmienione z architektury punktu odniesienia.
Azure OpenAI to usługa zarządzana, która zapewnia dostęp interfejsu API REST do modeli językowych usługi Azure OpenAI, w tym modeli GPT-4, GPT-3.5 Turbo i osadzania.
W zależności od tego, jak centrum doskonałości w organizacji zdecydowało się ograniczyć dostęp do wdrożeń modeli sztucznej inteligencji, zespół ds. obciążeń może nie być właścicielem tego zasobu, ale zamiast tego zespół musi korzystać ze scentralizowanych zasobów sztucznej inteligencji. W takim przypadku wszystkie użycie modelu zwykle przepływa przez bramę udostępnioną przez zespół ds. platformy sztucznej inteligencji. W tym artykule przyjęto założenie, że usługa Azure OpenAI jest zasobem należącym do obciążenia. Jeśli tak nie jest, ten zasób lub brama do tego zasobu staje się zależnością obciążenia. Zespół platformy zapewnia niezawodną łączność sieciową z interfejsami API.
azure AI Foundry to platforma, której można użyć do tworzenia, testowania i wdrażania rozwiązań sztucznej inteligencji. Usługa AI Foundry jest używana w tej architekturze do kompilowania, testowania i wdrażania przepływu monitu logiki aranżacji dla aplikacji do czatu. W tej architekturze usługa Azure AI Foundry zapewnia zarządzaną sieć wirtualną na potrzeby zabezpieczeń sieci. Aby uzyskać więcej informacji, zobacz sekcję dotyczącą sieci, aby uzyskać więcej informacji.
zarządzane punkty końcowe online są używane jako punkt końcowy platformy jako usługa (PaaS) dla aplikacji interfejsu użytkownika czatu, która wywołuje przepływy monitów hostowane przez usługę Azure AI Foundry.
usługa aplikacja systemu Azure służy do hostowania przykładowej aplikacji internetowej dla interfejsu użytkownika czatu. W tej architekturze można również użyć tej usługi do hostowania konteneryzowanego przepływu monitu w celu uzyskania większej kontroli nad środowiskiem hostingu, które uruchamia przepływ monitów. Usługa App Service ma trzy wystąpienia, z których każda jest w innej strefie platformy Azure.
Wyszukiwanie sztucznej inteligencji to wspólna usługa używana w przepływach za aplikacjami do czatu. Za pomocą funkcji wyszukiwania sztucznej inteligencji można pobrać indeksowane dane, które są istotne dla zapytań użytkowników.
Usługa Azure Storage służy do utrwalania plików źródłowych przepływu monitów na potrzeby tworzenia monitów dotyczących przepływu.
Usługa Azure Container Registry służy do przechowywania przepływów spakowanych jako obrazy kontenerów.
aplikacja systemu Azure Gateway jest używana jako zwrotny serwer proxy do kierowania żądań użytkowników do interfejsu użytkownika czatu hostowanego w usłudze App Service. Wybrana jednostka SKU jest również używana do hostowania zapory aplikacji internetowej platformy Azure w celu ochrony aplikacji frontonu przed potencjalnie złośliwym ruchem.
Usługa Key Vault służy do przechowywania wpisów tajnych aplikacji i certyfikatów.
Usługa Azure Monitor, dzienniki usługi Azure Monitor i usługa Application Insights służą do zbierania, przechowywania i wizualizowania danych z obserwacji.
Usługa Azure Policy służy do stosowania zasad specyficznych dla obciążenia w celu ułatwienia zarządzania, zabezpieczania i stosowania kontrolek na dużą skalę.
Zespół ds. obciążeń utrzymuje następujące zasoby:
Podsieci sieci wirtualnej szprych i sieciowe grupy zabezpieczeń umieszczone w tych podsieciach w celu utrzymania segmentacji i sterowania przepływem ruchu.
Prywatne punkty końcowe w celu zabezpieczenia łączności z rozwiązaniami PaaS.
Zasoby należące do zespołu platformy
Zespół platformy jest właścicielem i utrzymuje te scentralizowane zasoby. W tej architekturze przyjęto założenie, że te zasoby są wstępnie aprowidowane i są uwzględniane w zależnościach.
Usługa Azure Firewall w sieci piasty służy do kierowania, inspekcji i ograniczania ruchu wychodzącego. Ruch wychodzący obciążenia przechodzi do Internetu, miejsc docelowych obejmujących wiele lokalizacji lub do innych stref docelowych aplikacji.
Zmiana z punktu odniesienia: ten składnik jest nowy w tej architekturze. Usługa Azure Firewall nie jest opłacalna ani praktyczna dla każdego zespołu ds. obciążeń w celu zarządzania własnym wystąpieniem.
azure Bastion w sieci piasty zapewnia bezpieczny dostęp operacyjny do składników obciążenia, a także umożliwia dostęp do składników usługi Azure AI Foundry.
Zmiana z punktu odniesienia: zespół ds. obciążeń jest właścicielem tego składnika w architekturze punktu odniesienia.
Sieć wirtualna szprychy to miejsce, w którym jest wdrażane obciążenie.
Zmiana z punktu odniesienia: zespół ds. obciążeń jest właścicielem tej sieci w architekturze punktu odniesienia.
Trasy zdefiniowane przez użytkownika są używane do wymuszania tunelowania do sieci piasty.
Zmiana z punktu odniesienia: ten składnik jest nowy w tej architekturze.
Ograniczenia ładu oparte na usłudze Azure Policy i
DeployIfNotExists
zasady (DINE) są częścią subskrypcji obciążenia. Te zasady można zastosować na poziomie grupy zarządzania należącej do zespołu platformy lub zastosować je bezpośrednio do subskrypcji obciążenia.Zmiana z punktu odniesienia: te zasady są nowe w tej architekturze.
Prywatne strefy DNS platformy Azure hostuje
A
rekordy dla prywatnych punktów końcowych. Aby uzyskać więcej informacji, zobacz Integracja usługi Private Link i DNS na dużą skalę.Zmiana z punktu odniesienia: ten składnik jest przenoszony do centrum i jest zarządzany przez platformę.
Usługa rozpoznawania nazw DNS dla sieci wirtualnych szprych i stacji roboczych obejmujących wiele lokalizacji. Ta usługa zwykle przyjmuje postać usługi Azure Firewall jako serwera proxy DNS lub prywatnego rozpoznawania nazw usługi Azure DNS. W tej architekturze ta usługa rozpoznaje rekordy DNS prywatnego punktu końcowego dla wszystkich żądań DNS pochodzących z szprychy.
Usługa Azure DDoS Protection służy do ochrony publicznych adresów IP przed atakami rozproszonymi.
Zmiana z punktu odniesienia: zespół ds. obciążeń kupuje usługę DDoS Protection w architekturze punktu odniesienia.
Ważne
Strefy docelowe platformy Azure udostępniają niektóre z powyższych zasobów w ramach subskrypcji strefy docelowej platformy, a subskrypcja obciążenia udostępnia inne zasoby. Wiele zasobów jest częścią subskrypcji łączności. Subskrypcja ma również więcej zasobów, takich jak usługa Azure ExpressRoute, usługa Azure VPN Gateway i prywatny program rozpoznawania nazw DNS. Te zasoby zapewniają dostęp do wielu lokalizacji i rozpoznawanie nazw. Zarządzanie tymi zasobami wykracza poza zakres tego artykułu.
Konfiguracja subskrypcji
W kontekście strefy docelowej zespół ds. obciążeń, który implementuje tę architekturę, musi poinformować zespół platformy o określonych wymaganiach. Zespół platformy musi następnie przekazać swoje wymagania zespołowi ds. obciążeń.
Na przykład zespół ds. obciążeń musi zawierać szczegółowe informacje o przestrzeni sieciowej wymaganej przez obciążenie, aby zespół platformy mógł przydzielić niezbędne zasoby. Twój zespół określa wymagania, a zespół platformy określa adresy IP do przypisania w sieci wirtualnej.
Zespół ds. platformy przypisuje odpowiednią grupę zarządzania w oparciu o krytyczne znaczenie biznesowe i wymagania techniczne obciążenia. Przykładem może być uwidocznienie obciążenia w Internecie, tak jak w tej architekturze. Zespół ds. platformy ustanawia ład, konfigurując i implementując grupy zarządzania. Zespół ds. obciążeń musi zaprojektować i obsługiwać obciążenie w ramach ograniczeń ładu. Aby uzyskać więcej informacji na temat typowych różnic w grupach zarządzania, zobacz Dostosowywanie architektury strefy docelowej platformy Azure.
Ostatecznie zespół ds. platformy konfiguruje subskrypcję dla tej architektury. Poniższe sekcje zawierają wskazówki dotyczące początkowej konfiguracji subskrypcji w odniesieniu do tej architektury.
Wymagania i realizacja obciążenia
W przypadku tej architektury zespół ds. obciążeń i zespół platformy muszą współpracować nad kilkoma tematami: przypisaniem grupy zarządzania, w tym skojarzonym ładem usługi Azure Policy i konfiguracją sieci. Przygotuj listę kontrolną wymagań, aby zainicjować dyskusję i negocjacje z zespołem platformy. Ta lista kontrolna służy jako przykład w kontekście tej architektury.
Temat | Wymaganie dotyczące obciążenia dla tej architektury | |
---|---|---|
☐ | Liczba sieci wirtualnych szprych i ich rozmiar. Zespół platformy musi znać liczbę szprych, ponieważ tworzą i konfigurują sieć wirtualną i tworzą szprychę przez komunikację równorzędną z centralnym koncentratorem. Muszą również upewnić się, że sieć jest wystarczająco duża, aby pomieścić przyszły wzrost. | Wymagana jest tylko jedna dedykowana sieć wirtualna szprychy. Wszystkie zasoby są wdrażane w tej sieci. Zażądaj ciągłej przestrzeni adresowej /22, aby działała w pełnej skali lub uwzględniła sytuacje, takie jak wdrożenia równoległe. Większość wymagań dotyczących adresów IP jest napędzanych przez: — Wymagania usługi Application Gateway dotyczące rozmiaru podsieci (stały rozmiar). - Prywatne punkty końcowe z pojedynczymi adresami IP dla usług PaaS (stały rozmiar). — Rozmiar podsieci dla agentów kompilacji (stały rozmiar). - Niebieskie/zielone wdrożenia obliczeń przepływu monitu (zmienny rozmiar). |
☐ | Region wdrażania. Zespół ds. platformy używa tych informacji, aby upewnić się, że ma centrum wdrożone w tym samym regionie co zasoby obciążenia. | Dostępność jest ograniczona w przypadku azure OpenAI w niektórych regionach. Przekaż wybrany region. Ponadto przekaż region lub regiony, w których wdrażane są bazowe zasoby obliczeniowe. Wybrane regiony powinny obsługiwać strefy dostępności. |
☐ | Typ, wolumin i wzorzec ruchu. Zespół platformy używa tych informacji do określania wymagań dotyczących ruchu przychodzącego i wychodzącego zasobów udostępnionych używanych przez obciążenie. | Podaj informacje o: — Jak użytkownicy powinni korzystać z tego obciążenia. — Jak to obciążenie zużywa otaczające zasoby. - Skonfigurowany protokół transportu. - Wzorzec ruchu oraz oczekiwany szczyt i poza godzinami szczytu. Jeśli oczekujesz dużej liczby równoczesnych połączeń z Internetem (czatty) i kiedy oczekujesz, że obciążenie będzie generować minimalny ruch sieciowy (szum w tle). |
☐ | Konfiguracja zapory. Zespół platformy używa tych informacji do ustawiania reguł zezwalania na legalny ruch wychodzący. | Poinformuj zespół platformy o konkretnych informacjach związanych z ruchem, który opuszcza sieć szprych. — Agent kompilacji i maszyny przesiadkowe wymagają regularnego stosowania poprawek systemu operacyjnego. — Obliczenia wysyłają dane telemetryczne systemu operacyjnego. — W alternatywnym podejściu kod przepływu monitu hostowany przez usługę App Service wymaga dostępu do Internetu. |
☐ | Ruch przychodzący z wyspecjalizowanych ról. Zespół ds. platformy używa tych informacji, aby umożliwić określonym rolom uzyskiwanie dostępu do obciążenia podczas implementowania odpowiedniej segmentacji. | We współpracy z zespołem ds. platformy określ najlepszy sposób zezwalania na autoryzowany dostęp: — Analitycy danych mogą uzyskiwać dostęp do portalu azure AI Foundry ze stacji roboczych w połączeniach sieci firmowych. — Operatorzy dostępu do warstwy obliczeniowej za pośrednictwem serwera przesiadkowego zarządzanego przez zespół ds. obciążeń. |
☐ | Publiczny dostęp do Internetu do obciążenia. Zespół platformy używa tych informacji do oceny ryzyka, która kieruje decyzjami dotyczącymi następujących kwestii: — Umieszczanie obciążenia w grupie zarządzania z odpowiednimi zabezpieczeniami. — Ochrona przed atakami DDoS dla publicznego adresu IP zgłoszonego przez zespół obciążenia. - Wystawianie certyfikatów protokołu Transport Layer Security (TLS) i zarządzanie nimi. |
Poinformuj zespół platformy o profilu ruchu przychodzącego: — Ruch źródłowy z Internetu jest przeznaczony dla publicznego adresu IP w usłudze Application Gateway. - W pełni kwalifikowane nazwy domen (FQDN) skojarzone z publicznym adresem IP na potrzeby zamówień certyfikatów TLS. |
☐ | Użycie prywatnego punktu końcowego. Zespół platformy używa tych informacji do konfigurowania stref usługi Azure Prywatna strefa DNS dla tych punktów końcowych i upewnij się, że zapora w sieci piasty może wykonywać rozpoznawanie nazw DNS. | Poinformuj zespół platformy o wszystkich zasobach korzystających z prywatnych punktów końcowych, takich jak: - Wyszukiwanie sztucznej inteligencji — Container Registry — Key Vault — Azure OpenAI — Konta magazynu Jasne zrozumienie sposobu obsługi rozpoznawania nazw DNS w centrum oraz obowiązków zespołu ds. obciążeń dotyczących zarządzania prywatnymi rekordami strefy DNS. |
☐ | Scentralizowane zasoby sztucznej inteligencji. Zespół platformy musi mieć świadomość oczekiwanego użycia modelu i platformy hostingu, ponieważ zespół platformy używa tych informacji do ustanawiania sieci w dowolnych scentralizowanych zasobach sztucznej inteligencji ustanowionych w organizacji. Organizacje tworzą własne unikatowe plany wdrażania i zapewniania ładu w zakresie sztucznej inteligencji, które będą ograniczone przez zespoły ds. obciążeń. | Poinformuj zespół platformy o wszystkich zasobach sztucznej inteligencji i uczenia maszynowego, które mają być używane. W tej architekturze te usługi to: — Azure OpenAI — Azure AI Foundry Masz jasne informacje o tym, jakie scentralizowane usługi sztucznej inteligencji są wymagane do użycia i co zależy od tych ofert oznacza dla obciążenia. |
Ważne
Zalecamy sprzedaż abonamentów proces dla zespołu platformy, który obejmuje szereg pytań przeznaczonych do przechwytywania informacji od zespołu ds. obciążeń. Te pytania mogą się różnić od jednej organizacji do innej, ale celem jest zebranie wymagań dotyczących implementacji subskrypcji. Aby uzyskać więcej informacji, zobacz Subskrypcja vending.
Compute
Obliczenia hostujące przepływ monitu i interfejs użytkownika czatu pozostają takie same jak architektura punktu odniesienia.
Organizacja może narzucić wymagania zespołowi ds. obciążeń, który wymusza korzystanie z określonego środowiska uruchomieniowego usługi Azure AI Foundry. Na przykład może być wymagane unikanie automatycznych środowisk uruchomieniowych lub środowisk uruchomieniowych wystąpień obliczeniowych, a zamiast tego faworyzuje hosta kontenera przepływu monitu, który spełnia wymagania dotyczące zgodności, zabezpieczeń i możliwości obserwacji.
Ład organizacji może dodać więcej wymagań dotyczących konserwacji obrazu podstawowego kontenera i śledzenia pakietów zależności niż wymagania dotyczące obciążenia. Zespoły obciążeń muszą zapewnić, że środowisko uruchomieniowe obciążenia, kod wdrożony w nim i jego operacje są zgodne z tymi standardami organizacyjnymi.
Alternatywne podejście do hostowania kodu przepływu monitu
Zamiast hostować kod przepływu monitu w środowisku uruchomieniowym usługi Azure AI Foundry, możesz go hostować w usłudze App Service. W tym podejściu ruch wychodzący jest kontrolowany w porównaniu z zarządzaną siecią wirtualną usługi Azure AI Foundry. Sama logika nie zmienia się, ale wystąpienia usługi App Service wymagają dostępu do Internetu.
Sieć
W architekturze bazowej obciążenie jest aprowidowane w jednej sieci wirtualnej.
Zmiana z punktu odniesienia: obciążenie jest efektywnie dzielone na dwie sieci wirtualne. Jedna sieć jest dla składników obciążenia, a jedna z nich służy do kontrolowania łączności internetowej i hybrydowej. Zespół platformy określa, w jaki sposób sieć wirtualna obciążenia integruje się z większą architekturą sieciową organizacji, która jest zwykle z topologią piasty i szprych.
Ten diagram architektury ma niebieskie pole w górnej etykiecie subskrypcji strefy docelowej aplikacji zawierającej sieć wirtualną będącej szprychą. W sieci wirtualnej znajduje się pięć pól. Pola mają etykietę snet-appGateway, snet-agents, snet-jumpbox, snet-appServicePlan i snet-privateEndpoints. Każda podsieć ma logo sieciowej grupy zabezpieczeń, a wszystkie, ale podsieć snet-appGateway ma trasę zdefiniowaną przez użytkownika z komunikatem To hub. Ruch przychodzący z użytkowników lokalnych i lokalnych wskazuje bramę aplikacji. Użytkownik analityka danych jest połączony z bramą sieci VPN lub usługą ExpressRoute w dolnej części diagramu z etykietą subskrypcja łączności. Subskrypcja łączności zawiera prywatne strefy DNS dla usługi Private Link, prywatnego rozpoznawania nazw DNS i ochrony przed atakami DDoS. Sieć wirtualna koncentratora zawarta w subskrypcji łączności i sieci wirtualnej będącej szprychą są połączone z linią oznaczoną komunikacją równorzędną sieci wirtualnych. W sieci wirtualnej będącej szprychą znajduje się tekst, który odczytuje system DNS udostępniany przez centrum.
Pobierz plik programu Visio z tą architekturą.
Sieć wirtualna koncentratora: regionalne centrum zawierające scentralizowane i często współużytkowane usługi komunikujące się z zasobami obciążenia w tym samym regionie. Centrum znajduje się w subskrypcji łączności. Zespół platformy jest właścicielem zasobów w tej sieci.
Sieć wirtualna szprych: W tej architekturze pojedyncza sieć wirtualna z architektury bazowej zasadniczo staje się siecią szprych. Sieć wirtualna jest równorzędna do sieci koncentratora przez zespół platformy. Zespół platformy jest właścicielem tej sieci szprych, jej komunikacji równorzędnej i konfiguracji DNS oraz zarządza nią. Ta sieć zawiera wiele zasobów obciążenia. Zespół ds. obciążeń jest właścicielem zasobów w tej sieci, w tym jej podsieci.
Ze względu na podział zarządzania i własności upewnij się, że jasno przekażesz wymagania dotyczące obciążenia zespołowi platformy.
Ważne
W przypadku zespołu platformy: o ile nie jest to wymagane specjalnie przez obciążenie, nie należy bezpośrednio łączyć sieci szprych z inną siecią wirtualną będącej szprychą. Ta praktyka chroni cele segmentacji obciążenia. Jeśli zespoły strefy docelowej aplikacji nie mają połączenia krzyżowego z własnymi prywatnymi punktami końcowymi, zespół powinien ułatwić wszystkie przechodnie połączenia sieci wirtualnej. Dobrze zrozumieć zasoby używane przez to obciążenie, które są zarządzane przez zespoły poza zakresem tego zespołu roboczego. Na przykład zapoznaj się z łącznością sieciową między przepływem monitu a bazą danych wektorów zarządzaną przez inny zespół.
Podsieci sieci wirtualnej
W sieci wirtualnej będącej szprychą zespół obciążenia tworzy i przydziela podsieci, które są zgodne z wymaganiami obciążenia. Umieszczanie kontrolek w celu ograniczenia ruchu w podsieciach i wychodzących z tej podsieci pomaga zapewnić segmentację. Ta architektura nie dodaje żadnych podsieci poza tymi podsieciami opisanymi w architekturze punktu odniesienia. Architektura sieci nie wymaga AzureBastionSubnet
już podsieci, ponieważ zespół platformy hostuje tę usługę w swoich subskrypcjach.
Podczas wdrażania obciążenia w strefie docelowej platformy Azure nadal trzeba zaimplementować lokalne mechanizmy kontroli sieci. Organizacje mogą nakładać dalsze ograniczenia sieci w celu ochrony przed eksfiltracją danych i zapewnić widoczność centralnego centrum operacji zabezpieczeń (SOC) i zespołu ds. sieci IT.
Ruch przychodzący
Przepływ ruchu przychodzącego pozostaje taki sam jak architektura punktu odniesienia.
Twój zespół ds. obciążeń jest odpowiedzialny za wszelkie zasoby związane z publicznym wejściem do Internetu do obciążenia. Na przykład w tej architekturze usługa Application Gateway i jej publiczny adres IP są umieszczane w sieci szprychy, a nie w sieci piasty. Niektóre organizacje mogą umieszczać zasoby z ruchem przychodzącym w subskrypcji łączności przy użyciu scentralizowanej sieci obwodowej (nazywanej również strefą DMZ, strefą zdemilitaryzowaną i podsiecią ekranowaną). Integracja z tą konkretną topologią jest poza zakresem tego artykułu.
Alternatywne podejście do sprawdzania ruchu przychodzącego
Ta architektura nie używa usługi Azure Firewall do sprawdzania ruchu przychodzącego. Czasami nadzór organizacyjny wymaga takiego podejścia. Zespoły platformy obsługują implementację, aby zapewnić zespołom obciążeń dodatkową warstwę wykrywania nieautoryzowanego dostępu i zapobiegania blokowaniu niepożądanego ruchu przychodzącego. Ta architektura wymaga większej liczby konfiguracji trasy zdefiniowanej przez użytkownika, aby obsługiwać tę topologię. Aby uzyskać więcej informacji na temat tego podejścia, zobacz Zero Trust network for web applications with Azure Firewall and Application Gateway (Sieć Zero Trust dla aplikacji internetowych za pomocą usługi Azure Firewall i usługi Application Gateway).
Konfiguracja DNS
W architekturze bazowej usługa Azure DNS jest używana bezpośrednio przez wszystkie składniki rozpoznawania nazw DNS.
Zmiana z punktu odniesienia: usługa DNS jest zwykle delegowana do co najmniej jednego serwera DNS w centrum. Po utworzeniu sieci wirtualnej dla tej architektury właściwości DNS w sieci wirtualnej powinny być już odpowiednio ustawione. Usługa DNS jest uważana za nieprzezroczystą dla zespołu obciążenia.
Składniki obciążenia w tej architekturze są konfigurowane przy użyciu systemu DNS w następujący sposób.
Składnik | Konfiguracja DNS |
---|---|
Application Gateway | Dziedziczone z sieci wirtualnej. |
App Service (interfejs użytkownika czatu) | Dziedziczone z sieci wirtualnej. |
App Service (przepływ monitu) | Dziedziczone z sieci wirtualnej. |
Wyszukiwanie sztucznej inteligencji | Nie można zastąpić, używa usługi Azure DNS. |
Zasoby obliczeniowe bezserwerowe usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna, nie można zastąpić i używa usługi Azure DNS. Ta architektura korzysta z tego podejścia. ▪ Integracja sieci wirtualnej dziedziczona z sieci wirtualnej. |
Klaster obliczeniowy usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna, nie można zastąpić i używa usługi Azure DNS. Ta architektura korzysta z tego podejścia. ▪ Integracja sieci wirtualnej dziedziczona z sieci wirtualnej. |
Automatyczne środowisko uruchomieniowe usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna, nie można zastąpić, używa usługi Azure DNS. ▪ Integracja sieci wirtualnej dziedziczona z sieci wirtualnej. Ta architektura nie używa automatycznego środowiska uruchomieniowego. |
Wystąpienie obliczeniowe usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna, nie można zastąpić, używa usługi Azure DNS. Ta architektura korzysta z tego podejścia. ▪ Integracja sieci wirtualnej dziedziczona z sieci wirtualnej. |
Azure OpenAI | Nie można zastąpić, używa usługi Azure DNS. |
Pole skokowe | Dziedziczone z sieci wirtualnej. |
Kompilowanie agentów | Dziedziczone z sieci wirtualnej. |
Nie skonfigurowano żadnych ustawień DNS dla pozostałych składników architektury, ponieważ nie ma komunikacji wychodzącej z tych usług. Dla tych składników nie jest wymagane rozpoznawanie nazw DNS.
Wiele z tych składników wymaga odpowiednich rekordów DNS na serwerach DNS centrum, aby rozwiązać wiele prywatnych punktów końcowych tego obciążenia. Aby uzyskać więcej informacji, zobacz Strefy usługi Azure Prywatna strefa DNS. W przypadku składników, w których nie można przeprowadzić rozpoznawania nazw DNS opartego na centrum, występują następujące ograniczenia:
Zespół platformy nie może rejestrować żądań DNS, co może być wymaganiem zespołu ds. zabezpieczeń organizacji.
Rozpoznawanie uwidocznionych usług Azure Private Link w strefie docelowej lub innych strefach docelowych aplikacji może być niemożliwe. Niektóre usługi, takie jak obliczenia usługi Azure AI Foundry, działają zgodnie z tym ograniczeniem za pomocą funkcji specyficznych dla usługi.
Zalecamy zapoznanie się ze sposobem zarządzania systemem DNS przez zespół platformy. Aby uzyskać więcej informacji, zobacz Integracja usługi Private Link i DNS na dużą skalę. W przypadku dodawania funkcji składników, które są bezpośrednio zależne od usługi Azure DNS, można wprowadzić złożoność w topologii DNS udostępnianej przez platformę. Możesz przeprojektować składniki lub negocjować wyjątki, aby zminimalizować złożoność.
Ruch wychodzący
W architekturze bazowej kontrola ruchu wychodzącego z Internetu jest dostępna tylko za pośrednictwem konfiguracji sieci w centrum Azure AI Foundry i usłudze App Service w połączeniu z użyciem sieciowych grup zabezpieczeń w różnych podsieciach.
Zmiana z punktu odniesienia: kontrolki ruchu wychodzącego są dodatkowo rozszerzone. Cały ruch, który opuszcza sieć wirtualną szprychy, jest przekierowywany przez sieć koncentratora równorzędnego za pośrednictwem zapory ruchu wychodzącego. Ruch pochodzący z zarządzanej sieci wirtualnej dla obliczeń usługi Azure AI Foundry nie podlega tej trasie ruchu wychodzącego.
Górna sekcja tego diagramu architektury jest oznaczona etykietą subskrypcja strefy docelowej aplikacji i zawiera pole sieci wirtualnej szprychy i pole usługi Azure AI Foundry. Pole Azure AI Foundry zawiera prywatne punkty końcowe dla usługi Storage, Container Registry, AI Search i Azure OpenAI. Pole sieci wirtualnej szprych zawiera pięć podsieci: snet-appGateway, snet-agents, snet-jumpbox, snet-appServicePlan i snet-privateEndpoints. Wszystkie podsieci, z wyjątkiem aplikacji snet-appGateway, mają linię przerywaną prowadzącą z nich do usługi Azure Firewall, która znajduje się w dolnym polu. Dolne pole ma etykietę "Subskrypcja łączności". Usługa Azure Firewall ma ten sam styl, który wskazuje internet jako chmurę. Pole Azure AI Foundry ma taki sam styl linii przerywanej, który wskazuje również z niej do chmury internetowej. W górnym polu znajduje się napis Where possible all workload-originated, internet-bound traffic flows through the hub due to the 0.0.0.0/0 UDR (Gdzie to możliwe, cały ruch związany z internetem przepływa przez centrum ze względu na trasę zdefiniowaną przez użytkownika 0.0.0.0/0). Sieć wirtualna piasty w dolnym polu i sieć wirtualna szprychy w górnym polu są połączone z wierszem odczytującym komunikację równorzędną sieci wirtualnych.
Pobierz plik programu Visio z tą architekturą.
Komunikacja klienta z prywatnymi punktami końcowymi dla usługi Container Registry, Key Vault, Azure OpenAI i innych pozostaje taka sama jak architektura punktu odniesienia. Ta ścieżka zostanie pominięta na powyższym diagramie w celu zwięzłości.
Kierowanie ruchu internetowego do zapory
Trasa jest dołączona do wszystkich możliwych podsieci w sieci szprych, która kieruje cały ruch kierowany do Internetu (0.0.0.0/0) najpierw do usługi Azure Firewall centrum.
Składnik | Mechanizm wymuszania ruchu internetowego przez centrum |
---|---|
Application Gateway | Brak. Ruch związany z Internetem pochodzący z tej usługi nie może być wymuszany za pośrednictwem zapory zespołu platformy. |
App Service (interfejs użytkownika czatu) |
Włączono regionalną integrację sieci wirtualnej. VnetRouteAllEnabled jest włączona. |
App Service (przepływ monitu) |
Włączono regionalną integrację sieci wirtualnej. VnetRouteAllEnabled jest włączona. |
Wyszukiwanie sztucznej inteligencji | Brak. Ruch pochodzący z tej usługi nie może być wymuszany przez zaporę. Ta architektura nie korzysta z umiejętności. |
Zasoby obliczeniowe bezserwerowe usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna: ruch związany z Internetem pochodzący z tej usługi nie może być wymuszany przez zaporę zespołu platformy. Ta architektura korzysta z tego podejścia. ▪ Integracja z siecią wirtualną: używa trasy zdefiniowanej przez użytkownika zastosowanej do podsieci zawierającej klaster obliczeniowy. |
Klaster obliczeniowy usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna: ruch związany z Internetem pochodzący z tej usługi nie może być wymuszany przez zaporę zespołu platformy. Ta architektura korzysta z tego podejścia. ▪ Integracja z siecią wirtualną: używa trasy zdefiniowanej przez użytkownika zastosowanej do podsieci zawierającej klaster obliczeniowy. |
Automatyczne środowisko uruchomieniowe usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna: ruch związany z Internetem pochodzący z tej usługi nie może być wymuszany przez zaporę zespołu platformy. ▪ Integracja z siecią wirtualną: używa trasy zdefiniowanej przez użytkownika zastosowanej do podsieci zawierającej klaster obliczeniowy. Ta architektura nie używa automatycznego środowiska uruchomieniowego. |
Wystąpienie obliczeniowe usługi Azure AI Foundry | ▪ Zarządzana sieć wirtualna: ruch związany z Internetem pochodzący z tej usługi nie może być wymuszany przez zaporę zespołu platformy. Ta architektura korzysta z tego podejścia. ▪ Integracja z siecią wirtualną: używa trasy zdefiniowanej przez użytkownika zastosowanej do podsieci zawierającej klaster obliczeniowy. |
Azure OpenAI | Brak. Ruch pochodzący z tej usługi, na przykład za pośrednictwem funkcji danych , nie może być wymuszany przez zaporę. Ta architektura nie używa żadnej z tych funkcji. |
Pole skokowe | Używa trasy zdefiniowanej przez użytkownika zastosowanej do serwera snet-jumpbox. |
Kompilowanie agentów | Używa trasy zdefiniowanej przez użytkownika zastosowanej do agentów snet-agents. |
Nie skonfigurowano żadnych ustawień wymuszonego tunelu dla składników, które pozostają w architekturze, ponieważ żadna komunikacja wychodząca nie jest wykonywana z tych usług.
W przypadku składników lub funkcji składników, w których ruch wychodzący za pośrednictwem routingu koncentratora nie jest możliwy, zespół obciążenia musi dostosować się do wymagań organizacyjnych dotyczących tego ruchu. Użyj kontrolek wyrównywujących, przeprojektuj obciążenie, aby wykluczyć te funkcje lub wyszukać formalne wyjątki. Obciążenia są ostatecznie odpowiedzialne za łagodzenie eksfiltracji i nadużywania danych.
Zastosuj dostępną przez platformę trasę internetową do wszystkich podsieci, nawet jeśli podsieć nie ma ruchu wychodzącego. Takie podejście gwarantuje, że wszelkie nieoczekiwane wdrożenia w tej podsieci są poddawane rutynowym filtrowaniu ruchu wychodzącego. Upewnij się, że podsieci zawierające prywatne punkty końcowe mają włączone zasady sieciowe na potrzeby pełnego routingu i kontroli sieciowej grupy zabezpieczeń.
Po zastosowaniu tej konfiguracji trasy do architektury wszystkie połączenia wychodzące z usługi App Service, centrum Azure AI Foundry i jego projektów lub wszelkie inne usługi pochodzące z sieci wirtualnej obciążenia są analizowane i kontrolowane.
Prywatne strefy DNS platformy Azure
Architektury korzystające z prywatnych punktów końcowych dla ruchu east-west w ramach obciążenia wymagają rekordów strefy DNS w skonfigurowanym dostawcy DNS. Ta architektura wymaga prawidłowego działania wielu rekordów strefy DNS: Key Vault, Azure OpenAI i nie tylko w celu obsługi usługi Private Link.
Zmiana z punktu odniesienia: zespół obciążenia jest bezpośrednio odpowiedzialny za prywatne strefy DNS w architekturze punktu odniesienia. W architekturze strefy docelowej zespół platformy zwykle utrzymuje prywatne strefy DNS. Mogą używać innej technologii, ale w przypadku tej architektury są to prywatne rekordy strefy DNS. Zespół ds. obciążeń musi jasno zrozumieć wymagania i oczekiwania zespołu platformy dotyczące zarządzania tymi prywatnymi rekordami strefy DNS.
W tej architekturze zespół platformy musi zapewnić niezawodne i terminowe hostowanie DNS dla następujących punktów końcowych usługi Private Link:
- Wyszukiwanie sztucznej inteligencji
- Azure OpenAI
- Container Registry
- Key Vault
- Konta magazynu
Analityk danych i monituj o dostęp do autorystyki przepływu
Podobnie jak architektura punktu odniesienia , publiczny dostęp przychodzący do portalu usługi Azure AI Foundry i inne środowiska oparte na przeglądarce są wyłączone. Architektura punktu odniesienia wdraża serwer przesiadkowy w celu udostępnienia przeglądarki źródłowego adresu IP z sieci wirtualnej, która jest używana przez różne role obciążenia.
Gdy obciążenie jest połączone ze strefą docelową platformy Azure, więcej opcji jest dostępnych dla twojego zespołu na potrzeby tego dostępu. Skontaktuj się z zespołem ds. platformy, aby sprawdzić, czy prywatny dostęp do różnych studiów sztucznej inteligencji opartych na przeglądarce można osiągnąć bez konieczności zarządzania maszyną wirtualną i zarządzania nią. Ten dostęp można uzyskać za pośrednictwem przechodniego dostępu z już ustanowionego połączenia usługi ExpressRoute lub bramy sieci VPN. Natywny dostęp oparty na stacjach roboczych wymaga routingu obejmującego wiele lokalizacji i rozpoznawania nazw DNS, co może pomóc zespołowi platformy. Ustaw to wymaganie w żądaniu sprzedaż abonamentów.
Zapewnienie natywnego dostępu opartego na stacjach roboczych do tych portali jest zwiększeniem produktywności w punkcie odniesienia i może być prostsze w obsłudze niż pola przesiadkowe maszyn wirtualnych.
Rola skoku
Posiadanie skoku w tej architekturze jest cenne, ale nie dla celów środowiska uruchomieniowego, sztucznej inteligencji lub uczenia maszynowego. Serwer przesiadkowy może rozwiązywać problemy z routingiem DNS i sieci, ponieważ zapewnia dostęp do sieci wewnętrznej do innych składników niedostępnych zewnętrznie.
W architekturze bazowej usługa Azure Bastion uzyskuje dostęp do serwera przesiadkowego zarządzanego przez zespół ds. obciążeń.
W tej architekturze usługa Azure Bastion jest wdrażana w ramach subskrypcji łączności jako współużytkowany zasób regionalny zarządzany przez zespół platformy. Aby zademonstrować ten przypadek użycia w tej architekturze, usługa Azure Bastion znajduje się w subskrypcji łączności i nie jest już wdrażana przez zespół ds. obciążeń.
Maszyna wirtualna używana jako serwer przesiadkowy musi spełniać wymagania organizacyjne dotyczące maszyn wirtualnych. Te wymagania mogą obejmować elementy, takie jak tożsamości firmowe w usłudze Microsoft Entra ID, określone obrazy podstawowe i schematy stosowania poprawek.
Monitorowanie zasobów
Platforma strefy docelowej platformy Azure zapewnia współużytkowane zasoby umożliwiające obserwowanie w ramach subskrypcji zarządzania. Zalecamy jednak aprowizowanie własnych zasobów monitorowania w celu ułatwienia odpowiedzialności za własność obciążenia. Takie podejście jest zgodne z architekturą punktu odniesienia.
Zespół ds. obciążeń aprowizuje zasoby monitorowania, w tym:
Usługa Application Insights jako usługa zarządzania wydajnością aplikacji (APM) dla zespołu ds. obciążeń. Ta funkcja jest skonfigurowana w interfejsie użytkownika czatu i w kodzie przepływu monitu.
Obszar roboczy Dzienniki usługi Azure Monitor jako ujednolicony ujście dla wszystkich dzienników i metryk zbieranych z zasobów platformy Azure należących do obciążenia.
Podobnie jak w przypadku planu bazowego, wszystkie zasoby są skonfigurowane do wysyłania dzienników Diagnostyka Azure do obszaru roboczego Dzienniki usługi Azure Monitor, który zespół obciążeń aprowizuje jako część wdrożenia infrastruktury jako kodu (IaC) zasobów. Może być również konieczne wysłanie dzienników do centralnego obszaru roboczego dzienników usługi Azure Monitor. W strefach docelowych platformy Azure ten obszar roboczy jest zwykle w subskrypcji zarządzania.
Zespół platformy może również mieć procesy wpływające na zasoby strefy docelowej aplikacji. Mogą na przykład używać zasad DINE do konfigurowania diagnostyki i wysyłania dzienników do scentralizowanych subskrypcji zarządzania. Mogą też używać monitora alertów bazowych zastosowanych za pomocą zasad. Ważne jest, aby upewnić się, że implementacja nie ogranicza dodatkowych przepływów dziennika i alertów.
Azure Policy
Architektura linii bazowej zaleca niektóre ogólne zasady, aby ułatwić zarządzanie obciążeniem. Podczas wdrażania tej architektury w strefie docelowej aplikacji nie trzeba dodawać ani usuwać żadnych innych zasad. Kontynuuj stosowanie zasad do subskrypcji, grup zasobów lub zasobów, które ułatwiają wymuszanie ładu i zwiększanie bezpieczeństwa tego obciążenia.
Przed wdrożeniem obciążenia należy oczekiwać, że subskrypcja strefy docelowej aplikacji będzie już stosowana. Niektóre zasady pomagają ładowi organizacyjnemu przez inspekcję lub blokowanie określonych konfiguracji we wdrożeniach. Oto kilka przykładowych zasad, które mogą prowadzić do złożoności wdrażania obciążeń:
Zasady: "Wpisy tajne [w usłudze Key Vault] powinny mieć określony maksymalny okres ważności".
Komplikacja: Usługa Azure AI Foundry zarządza wpisami tajnymi w usłudze Key Vault obciążenia, a te wpisy tajne nie mają ustawionej daty wygaśnięcia.
Zasady: "Obszary robocze usługi Machine Learning powinny być szyfrowane przy użyciu klucza zarządzanego przez klienta".
Komplikacja: Ta architektura nie jest przeznaczona wyłącznie do obsługi kluczy zarządzanych przez klienta. Można go jednak rozszerzyć, aby ich używać.
Zasady: "Obszary robocze usługi Azure Machine Learning powinny umożliwić trybowi V1LegacyMode obsługę zgodności z poprzednimi wersjami izolacji sieci".
Komplikacja: Ta architektura nie wymaga zgodności z poprzednimi wersjami izolacji sieci".
Zasady: "Obszary robocze usługi Azure Machine Learning powinny używać tożsamości zarządzanej przypisanej przez użytkownika".
Komplikacja: Ta architektura używa przypisanej przez system tożsamości zarządzanej do korzystania z przypisań ról zarządzanych przez system.
Zespoły platform mogą stosować zasady DINE do obsługi wdrożeń automatycznych w subskrypcji strefy docelowej aplikacji. Z góry uwzględnij i przetestuj ograniczenia inicjowane przez platformę oraz zmiany w szablonach IaC. Jeśli zespół platformy korzysta z zasad platformy Azure, które powodują konflikt z wymaganiami aplikacji, możesz wynegocjować rozwiązanie z zespołem platformy.
Zarządzanie zmianami w czasie
Usługi i operacje udostępniane przez platformę są uznawane za zależności zewnętrzne w tej architekturze. Zespół platformy nadal stosuje zmiany, dołączanie stref docelowych i stosowanie kontroli kosztów. Zespół platformy obsługujący organizację może nie określać priorytetów poszczególnych obciążeń. Zmiany tych zależności, takie jak modyfikacje zapory, mogą mieć wpływ na wiele obciążeń.
Zespoły ds. obciążeń i platform muszą komunikować się w wydajny i terminowy sposób, aby zarządzać wszystkimi zależnościami zewnętrznymi. Ważne jest, aby wcześniej testować zmiany, aby nie wpływały negatywnie na obciążenia.
Zmiany platformy wpływające na to obciążenie
W tej architekturze zespół platformy zarządza następującymi zasobami. Zmiany w tych zasobach mogą potencjalnie wpływać na niezawodność, zabezpieczenia, operacje i cele wydajności obciążenia. Ważne jest, aby ocenić te zmiany, zanim zespół platformy zaimplementuje je, aby określić, jak wpływają one na obciążenie.
Zasady platformy Azure: zmiany zasad platformy Azure mogą mieć wpływ na zasoby obciążeń i ich zależności. Na przykład mogą istnieć bezpośrednie zmiany zasad lub przenoszenie strefy docelowej do nowej hierarchii grup zarządzania. Te zmiany mogą pozostać niezauważone, dopóki nie zostanie wprowadzone nowe wdrożenie, dlatego ważne jest, aby dokładnie je przetestować.
Przykład: zasady nie zezwalają już na wdrażanie wystąpień usługi Azure OpenAI obsługujących dostęp do klucza interfejsu API.
Reguły zapory: modyfikacje reguł zapory mogą mieć wpływ na sieć wirtualną obciążenia lub reguły, które mają zastosowanie szeroko we wszystkich ruchach. Te modyfikacje mogą spowodować zablokowanie ruchu, a nawet niepowodzeń procesów dyskretnych. Te potencjalne problemy dotyczą zarówno zapory ruchu wychodzącego, jak i reguł sieciowej grupy zabezpieczeń stosowanej przez usługę Azure Virtual Network Manager.
Przykład: Zablokowane serwery aktualizacji dostawcy prowadzą do niepowodzenia aktualizacji systemu operacyjnego na serwerze przesiadkowym lub agentów kompilacji.
Routing w sieci piasty: zmiany w przejściowym charakterze routingu w centrum mogą potencjalnie wpłynąć na funkcjonalność obciążenia, jeśli obciążenie zależy od routingu do innych sieci wirtualnych.
Przykład: uniemożliwia przepływowi monitowania o dostęp do magazynu wektorów obsługiwanego przez inny zespół lub zespoły nauki o danych z uzyskiwania dostępu do środowisk opartych na przeglądarce w portalach sztucznej inteligencji ze stacji roboczych.
Host usługi Azure Bastion: zmiany dostępności lub konfiguracji hosta usługi Azure Bastion.
Przykład: uniemożliwia dostęp do pól przesiadkowych i maszyn wirtualnych agenta kompilacji.
Zmiany obciążenia wpływające na platformę
Poniższe przykłady to zmiany obciążenia w tej architekturze, które należy przekazać zespołowi platformy. Ważne jest, aby zespół platformy weryfikował niezawodność, zabezpieczenia, operacje i cele wydajności usługi platformy przed ich wprowadzeniem.
Ruch wychodzący sieci: monitoruj znaczny wzrost ruchu wychodzącego sieci, aby zapobiec utracie hałaśliwego sąsiada na urządzeniach sieciowych. Ten problem może potencjalnie mieć wpływ na cele wydajności lub niezawodności innych obciążeń. Ta architektura jest głównie samodzielna i prawdopodobnie nie spowoduje znaczącej zmiany wzorców ruchu wychodzącego.
Dostęp publiczny: zmiany w publicznym dostępie do składników obciążenia mogą wymagać dalszego testowania. Zespół platformy może przenieść obciążenie do innej grupy zarządzania.
Przykład: jeśli w tej architekturze usuniesz publiczny adres IP z usługi Application Gateway i wprowadzisz tylko wewnętrzną aplikację, narażenie obciążenia na zmiany w Internecie. Innym przykładem jest to, że portale sztucznej inteligencji oparte na przeglądarce zostaną zmienione tak, aby uwidoczniły się w Internecie, co nie jest zalecane.
Ocena krytycznej działalności biznesowej: jeśli istnieją zmiany umów dotyczących poziomu usług (SLA) obciążenia, może być konieczne nowe podejście współpracy między zespołami platformy i obciążeń.
Przykład: Obciążenie może przejść od niskiego do wysokiego poziomu w krytycznym stopniu dzięki zwiększonemu wdrożeniu i powodzeniu obciążeń.
Niezawodność
Ta architektura jest zgodna z gwarancjami niezawodności w architekturze punktu odniesienia. Nie ma nowych zagadnień dotyczących niezawodności podstawowych składników obciążenia.
Cele dotyczące niezawodności
Maksymalny możliwy cel poziomu usług złożonych (SLO) dla tej architektury jest niższy niż podstawowy cel poziomu usług złożonych (SLO) ze względu na nowe składniki, takie jak kontrola sieci ruchu wychodzącego. Te składniki, wspólne w środowiskach strefy docelowej, nie są unikatowe dla tej architektury. Cel slo jest podobnie zmniejszony, jeśli zespół obciążenia bezpośrednio kontroluje te usługi platformy Azure.
Zależności krytyczne
Wyświetl wszystkie funkcje wykonywane przez obciążenie w strefie docelowej platformy i aplikacji jako zależności. Plany reagowania na zdarzenia wymagają, aby zespół ds. obciążeń wiedział o punkcie i metodzie informacji kontaktowych dotyczących tych zależności. Uwzględnij również te zależności w analizie trybu awarii obciążenia (FMA).
W przypadku tej architektury należy wziąć pod uwagę następujące zależności obciążenia:
Zapora ruchu wychodzącego: scentralizowana zapora ruchu wychodzącego współużytkowana przez wiele obciążeń przechodzi zmiany niepowiązane z obciążeniem.
Rozpoznawanie nazw DNS: ta architektura korzysta z systemu DNS udostępnianego przez zespół platformy zamiast bezpośredniego łączenia się z usługą Azure DNS. Oznacza to, że terminowe aktualizacje rekordów DNS dla prywatnych punktów końcowych i dostępności usług DNS są nowymi zależnościami.
Zasady DINE: zasady DINE dla prywatnych stref DNS usługi Azure DNS lub innych zależności udostępnianych przez platformę są najlepszym rozwiązaniem, bez umowy SLA podczas ich stosowania. Na przykład opóźnienie konfiguracji DNS dla prywatnych punktów końcowych tej architektury może spowodować opóźnienia w gotowości interfejsu użytkownika czatu do obsługi ruchu lub monitowania przepływu z kończenia zapytań.
Zasady grupy zarządzania: spójne zasady między środowiskami mają kluczowe znaczenie dla niezawodności. Upewnij się, że środowiska przedprodukcyjne są podobne do środowisk produkcyjnych, aby zapewnić dokładne testowanie i zapobiec odchyleniu specyficznym dla środowiska, które mogą blokować wdrożenie lub skalę. Aby uzyskać więcej informacji, zobacz Zarządzanie środowiskami projektowymi aplikacji w strefach docelowych platformy Azure.
Wiele z tych zagadnień może istnieć bez stref docelowych platformy Azure, ale zespoły ds. obciążeń i platform muszą wspólnie rozwiązywać te problemy, aby zapewnić spełnienie wymagań. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące przeprowadzania analizy trybu awarii.
Zabezpieczenia
Zalecenia opisane w poniższych sekcjach są oparte na liście kontrolnej przeglądu projektu zabezpieczeń w strukturze Well-Architected Framework.
Kontrola ruchu przychodzącego
Izoluj obciążenie od innych szprych obciążeń w organizacji przy użyciu sieciowych grup zabezpieczeń w podsieciach i nieprzejrzałych mechanizmów kontroli lub natury w centrum regionalnym. Konstruowanie kompleksowych sieciowych grup zabezpieczeń, które zezwalają tylko na wymagania dotyczące sieci przychodzącej aplikacji i jej infrastruktury. Zalecamy, aby nie polegać wyłącznie na nieprzejaśnianiu sieci koncentratora w celu zapewnienia bezpieczeństwa.
Zespół platformy implementuje zasady platformy Azure na potrzeby zabezpieczeń. Na przykład zasady mogą mieć pewność, że usługa Application Gateway ma zaporę aplikacji internetowej ustawioną na tryb odmowy, co ogranicza liczbę publicznych adresów IP dostępnych dla twojej subskrypcji. Oprócz tych zasad zespół ds. obciążeń powinien wdrożyć więcej zasad skoncentrowanych na obciążeniach, które wzmacniają stan zabezpieczeń ruchu przychodzącego.
W poniższej tabeli przedstawiono przykłady kontrolek ruchu przychodzącego w tej architekturze.
Źródło | Purpose | Kontrola obciążenia | Kontrolka platformy |
---|---|---|---|
Internet | Przepływy ruchu aplikacji | Lejki wszystkie żądania obciążeń za pośrednictwem sieciowej grupy zabezpieczeń, zapory aplikacji internetowej i reguł routingu przed zezwoleniem na przejście ruchu publicznego do ruchu prywatnego dla interfejsu użytkownika czatu. | Brak |
Internet | Dostęp do portalu usługi Azure AI Foundry | Odmów całej konfiguracji na poziomie usługi. | Brak |
Internet | Dostęp do płaszczyzny danych do wszystkich, ale usługi Application Gateway | Odmów całej sieciowej grupie zabezpieczeń i konfiguracji na poziomie usługi. | Brak |
Azure Bastion | Dostęp do serwera Przesiadkowego i agenta kompilacji | Sieciowa grupa zabezpieczeń w podsieci serwera przesiadkowego, która blokuje cały ruch do portów dostępu zdalnego, chyba że jest ona źródłowa z wyznaczonej podsieci usługi Azure Bastion | Brak |
Między środowiskami lokalnymi | Dostęp do portalu usługi Azure AI Foundry | Odmów wszystkim. Jeśli serwer przesiadkowy nie jest używany, zezwalaj tylko stacjom roboczym z autoryzowanych podsieci na dostęp analityka danych. | Routing nietransitive lub usługa Azure Firewall, jeśli jest używany koncentrator zabezpieczony w usłudze Azure Virtual WAN |
Inne szprychy | Brak | Zablokowane za pośrednictwem reguł sieciowej grupy zabezpieczeń. | Routing nieprzejeżający lub usługa Azure Firewall, jeśli jest używany koncentrator zabezpieczony w wirtualnej sieci WAN |
Kontrola ruchu wychodzącego
Zastosuj reguły sieciowej grupy zabezpieczeń, które wyrażają wymagane wymagania dotyczące łączności wychodzącej rozwiązania i odrzucają wszystkie inne elementy. Nie należy polegać tylko na kontrolkach sieci piasty. Jako operator obciążenia ponosisz odpowiedzialność za zatrzymanie niepożądanego ruchu wychodzącego tak blisko źródła, jak to możliwe.
Będąc właścicielem podsieci obciążenia w sieci wirtualnej, zespół platformy prawdopodobnie utworzył reguły zapory, aby w szczególności reprezentować przechwycone wymagania w ramach procesu sprzedaż abonamentów. Upewnij się, że zmiany w podsieciach i umieszczaniu zasobów w okresie istnienia architektury są nadal zgodne z oryginalnym żądaniem. Skontaktuj się z zespołem ds. sieci, aby zapewnić ciągłość kontroli ruchu wychodzącego o najmniejszym dostępie.
W poniższej tabeli przedstawiono przykłady ruchu wychodzącego w tej architekturze.
Punkt końcowy | Purpose | Kontrola obciążenia | Kontrolka platformy |
---|---|---|---|
Publiczne źródła internetowe | Przepływ monitów może wymagać wyszukiwania w Internecie w celu uzupełnienia żądania usługi Azure OpenAI | Sieciowa grupa zabezpieczeń w podsieci hosta kontenera przepływu monitu lub konfiguracja sieci wirtualnej zarządzanej przez usługę Azure AI | Zasiłek dla reguły sieciowej zapory dla tej samej kontrolki obciążenia |
Płaszczyzna danych usługi Azure OpenAI | Przepływ monitu o hostowanie zasobów obliczeniowych wywołuje ten interfejs API w celu obsługi monitów | TCP/443 do podsieci prywatnego punktu końcowego z podsieci zawierającej przepływ monitu | Brak |
Key Vault | Aby uzyskać dostęp do wpisów tajnych z poziomu interfejsu użytkownika czatu lub hosta przepływu monitu | TCP/443 do podsieci prywatnego punktu końcowego zawierającego usługę Key Vault | Brak |
W przypadku ruchu, który opuszcza sieć wirtualną tej architektury, kontrolki są najlepiej implementowane na poziomie obciążenia za pośrednictwem sieciowych grup zabezpieczeń i na poziomie platformy za pośrednictwem zapory sieciowej koncentratora. Sieciowe grupy zabezpieczeń zapewniają początkowe, szerokie reguły ruchu sieciowego, które są dodatkowo zawężone przez określone reguły zapory w sieci piasty platformy w celu zapewnienia dodatkowych zabezpieczeń. Nie ma oczekiwań, że ruch między portalem usługi Azure AI Foundry a kontem magazynu w tej architekturze powinien być kierowany przez centrum.
Ochrona przed atakami DDoS
Określ, kto powinien zastosować plan usługi DDoS Protection, który obejmuje wszystkie publiczne adresy IP rozwiązania. Zespół platformy może używać planów ochrony adresów IP lub użyć usługi Azure Policy do wymuszania planów ochrony sieci wirtualnej. Ta architektura powinna mieć pokrycie, ponieważ obejmuje publiczny adres IP dla ruchu przychodzącego z Internetu. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące sieci i łączności.
Zarządzanie tożsamościami i dostępem
Jeśli nie jest to wymagane w inny sposób przez automatyzację ładu zespołu platformy, nie ma żadnych oczekiwań co do dodatkowych wymagań dotyczących autoryzacji w tej architekturze ze względu na zaangażowanie zespołu platformy. Kontrola dostępu oparta na rolach (RBAC) na platformie Azure powinna nadal spełniać zasadę najniższych uprawnień, która udziela ograniczonego dostępu tylko tym, którzy jej potrzebują i tylko wtedy, gdy jest to konieczne. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące zarządzania tożsamościami i dostępem.
Certyfikaty i szyfrowanie
Zespół ds. obciążeń zwykle uzyskuje certyfikat TLS dla publicznego adresu IP w usłudze Application Gateway w tej architekturze. Skontaktuj się z zespołem ds. platformy, aby dowiedzieć się, jak procesy zaopatrzenia certyfikatów i zarządzania powinny być zgodne z oczekiwaniami organizacji.
Wszystkie usługi magazynu danych w tej architekturze obsługują klucze szyfrowania zarządzane przez firmę Microsoft lub przez klientów. Użyj kluczy szyfrowania zarządzanych przez klienta, jeśli projekt obciążenia lub organizacja wymaga większej kontroli. Same strefy docelowe platformy Azure nie nakazują jednego ani drugiego.
Optymalizacja kosztów
W przypadku zasobów obciążeń wszystkie strategie optymalizacji kosztów w architekturze bazowej mają również zastosowanie do tej architektury.
Ta architektura znacznie korzysta z zasobów platformy docelowej platformy Azure. Nawet jeśli używasz tych zasobów za pośrednictwem modelu obciążenia zwrotnego, dodatkowe zabezpieczenia i łączność między lokalizacjami są bardziej ekonomiczne niż samodzielne zarządzanie tymi zasobami. Skorzystaj z innych scentralizowanych ofert od zespołu platformy, aby rozszerzyć te korzyści na obciążenie bez naruszania celu SLO, celu czasu odzyskiwania (RTO) lub celu punktu odzyskiwania (RPO).
Doskonałość operacyjna
Zespół ds. obciążeń jest nadal odpowiedzialny za wszystkie zagadnienia dotyczące doskonałości operacyjnej omówione w architekturze bazowej, takie jak monitorowanie, GenAIOps, zapewnianie jakości i bezpieczne praktyki wdrażania.
Korelowanie danych z wielu ujściów
Dzienniki i metryki obciążenia oraz jego składniki infrastruktury są przechowywane w obszarze roboczym Dzienniki usługi Azure Monitor obciążenia. Jednak dzienniki i metryki ze scentralizowanych usług, takich jak Azure Firewall, private resolver i Azure Bastion, są często przechowywane w centralnym obszarze roboczym dzienników usługi Azure Monitor. Korelacja danych z wielu ujść może być złożonym zadaniem.
Skorelowane dane są często używane podczas reagowania na zdarzenia. Upewnij się, że element Runbook klasyfikacji dla tej architektury rozwiązuje tę sytuację i uwzględnia punkty organizacyjne kontaktu, jeśli problem wykracza poza zasoby obciążenia. Administratorzy obciążeń mogą wymagać pomocy od administratorów platformy w celu skorelowania wpisów dziennika z sieci, zabezpieczeń lub innych usług platformy w przedsiębiorstwie.
Ważne
W przypadku zespołu platformy: jeśli to możliwe, udziel kontroli dostępu opartej na rolach w celu wykonywania zapytań i odczytywania ujść dzienników dla odpowiednich zasobów platformy. Włącz dzienniki zapory dla ocen reguł sieci i aplikacji oraz serwera proxy DNS. Zespoły aplikacji mogą używać tych informacji do rozwiązywania problemów z zadaniami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące monitorowania i wykrywania zagrożeń.
Kompilowanie agentów
Wiele usług w tej architekturze korzysta z prywatnych punktów końcowych. Podobnie jak w przypadku architektury bazowej, ten projekt potencjalnie sprawia, że agenci kompilacji muszą spełnić wymagania tej architektury. Bezpieczne i niezawodne wdrażanie agentów kompilacji jest obowiązkiem zespołu ds. obciążeń bez udziału zespołu platformy. Upewnij się jednak, że zarządzanie agentami kompilacji jest zgodne z organizacją. Na przykład użyj obrazów systemu operacyjnego zatwierdzonego przez platformę, harmonogramów poprawek, raportowania zgodności i metod uwierzytelniania użytkowników.
Efektywność wydajności
Zagadnienia dotyczące wydajności opisane w architekturze punktu odniesienia dotyczą również tej architektury. Zespół ds. obciążeń zachowuje kontrolę nad zasobami używanymi w przepływach zapotrzebowania, a nie nad zespołem platformy. Skalowanie hosta interfejsu użytkownika czatu, hosta przepływu monitów, modeli językowych i innych zgodnie z ograniczeniami obciążenia i kosztów. W zależności od ostatecznej implementacji architektury należy wziąć pod uwagę następujące czynniki podczas mierzenia wydajności względem celów wydajności.
- Ruch wychodzący i opóźnienie obejmujące wiele lokalizacji
- Ograniczenia jednostek SKU wynikające z utrzymania ładu w zakresie kosztów
Wdrażanie tego scenariusza
Wdrożenie strefy docelowej dla tej architektury referencyjnej jest dostępne w usłudze GitHub.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Autorzy zabezpieczeń:
- Chad Kittel | Wzorce i praktyki platformy Azure — Microsoft
- Freddy Ayala | Architekt rozwiązań w chmurze firmy Microsoft
- Bilal Amjad | Architekt rozwiązań w chmurze firmy Microsoft
Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następny krok
Zapoznaj się ze szczegółami współpracy i technicznymi udostępnionymi między zespołami ds. obciążeń i zespołami platformy.