Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługa Microsoft Foundry Agent Service obsługuje kilka opcji sieciowych — od w pełni publicznej konfiguracji na potrzeby szybkiego tworzenia prototypów po pełną izolację sieci w obrębie własnej sieci wirtualnej. Ten artykuł porównuje opcje, mapuje je na wspólne cele i wskazuje na szablon wdrożenia i przewodnik konfiguracji dla wybranej opcji.
Po wybraniu opcji postępuj zgodnie z połączonymi instrukcjami, aby je wdrożyć, a następnie zweryfikuj wdrożenie. Jeśli wystąpią problemy, skorzystaj z połączonych wskazówek dotyczących rozwiązywania problemów.
Domyślne zachowanie sieci
Podczas tworzenia zasobu usługi Foundry bez żadnej konfiguracji sieci uzyskasz w pełni publiczny punkt odniesienia:
- Ruch przychodzący: punkt końcowy Foundry jest dostępny za pośrednictwem publicznego Internetu. Każdy, kto dysponuje prawidłowymi poświadczeniami i adresem URL punktu końcowego, może uzyskać do niego dostęp.
- Ruch wychodzący: agenci uzyskują dostęp do danych i zasobów platformy Azure za pośrednictwem sieci publicznych i mogą uzyskać dostęp wyłącznie do punktów końcowych dostępnych z Internetu.
- Pamięć masowa: stan agenta domyślnie korzysta z pamięci masowej zarządzanej przez firmę Microsoft. W przypadku korzystania z własnego magazynu i innych zasobów Azure należy skonfigurować dostęp sieciowy do tych zasobów w ramach konfiguracji sieci.
Nic nie jest prywatne, dopóki nie wybierzesz jednej z opcji w następnej sekcji. Każda opcja zmienia stronę ruchu przychodzącego, stronę ruchu wychodzącego lub obie.
Opcje sieci
Konfiguracja sieci łączy dwie powiązane decyzje:
- Dostęp wychodzący (wychodzący): sposób, w jaki agenci docierają do danych i innych zasobów Azure. Ta decyzja określa podstawowy model izolacji: pozostaw ruch wychodzący jako publiczny lub ogranicz go do sieci wirtualnej, tak aby ruch pozostawał w sieci prywatnej. Sieć wirtualna może być siecią, którą samodzielnie dostarczasz i zarządzasz (BYO virtual network), albo siecią zarządzaną przez firmę Microsoft.
- Dostęp przychodzący: które sieci mogą uzyskiwać dostęp do punktu końcowego rozwiązania Foundry. Publiczny (opcjonalnie ograniczony do wybranych adresów IP) lub prywatny za pośrednictwem prywatnego punktu końcowego.
Te dwie decyzje są połączone. W przypadku izolowania ruchu wychodzącego w sieci wirtualnej dostęp przychodzący do punktu końcowego rozwiązania Foundry przechodzi również przez prywatny punkt końcowy, ponieważ zasoby w tej sieci wirtualnej docierają do punktu końcowego za pośrednictwem sieci prywatnej. Zacznij od modelu ruchu wychodzącego, ponieważ wybór określa izolację i dostępne opcje ruchu przychodzącego. W poniższej tabeli przedstawiono trzy modele ruchu wychodzącego i dostępne opcje dla ruchu przychodzącego.
| Model ruchu wyjściowego | Opcje ruchu przychodzącego | Najlepsze dla |
|---|---|---|
| Publiczne wyjście | Publiczny (opcjonalnie wybrane adresy IP) lub prywatny punkt końcowy w sieci wirtualnej | Brak izolacji ruchu wychodzącego. Do tworzenia prototypów i testów używaj publicznego punktu wejścia albo prywatnego punktu końcowego, aby ograniczyć, kto może wywoływać usługę, przy zachowaniu publicznego ruchu wychodzącego. |
| Sieć wirtualna BYO | Prywatny punkt końcowy w sieci wirtualnej | Pełna izolacja, gdzie kontrolujesz zakresy adresów IP, połączenia peeringowe i routing. Agenty są wdrażane do delegowanej i zarządzanej przez Ciebie podsieci. |
| Zarządzana sieć wirtualna | Prywatny punkt końcowy w sieci wirtualnej | Pełna izolacja bez zarządzania zakresami adresów IP lub w przypadku nakładania się przestrzeni adresowej IP. Agenci działają w sieci wirtualnej zarządzanej Microsoft. |
W przypadku publicznego ruchu wychodzącego dodanie prywatnego punktu końcowego zabezpiecza tylko ścieżkę przychodzącą: wywołujący uzyskują prywatny dostęp do punktu końcowego Foundry, ale ruch wychodzący agenta nie jest izolowany.
Za pomocą sieci wirtualnej BYO możesz korzystać z własnych zasobów danych lub korzystać z zasobów danych zarządzanych przez platformę. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące własnej sieci wirtualnej.
Note
Izolacja sieci ma zastosowanie na poziomie konta i projektu Foundry. Obejmuje hostowanych agentów, agentów opartych na promptach oraz inne zasoby Foundry na koncie. Dwa typy agentów używają zasobów sieciowych inaczej w ramach izolowanej konfiguracji. Aby uzyskać szczegółowe informacje, zobacz Dogłębne omówienie sieci usługi Foundry Agent Service.
Opcje sieci według scenariusza
W poniższej tabeli przedstawiono mapowanie typowych celów na zalecaną opcję i szablon wdrożenia. Szablony infrastruktury jako kodu znajdują się w repozytorium konfiguracji infrastruktury dla przykładów usługi Foundry (Bicep, z odpowiednikiem w Terraformie).
| Twój cel | Zalecana opcja | Wdróż za pomocą |
|---|---|---|
| Najszybsza droga do działającego agenta, bez izolacji | Publiczny, zarządzany przez firmę Microsoft magazyn danych | Wdrażanie pierwszego hostowanego agenta — Szybki start (interfejs wiersza polecenia dewelopera Azure lub program VS Code) |
| Przechowywanie danych agenta we własnych zasobach Azure bez izolacji | Publiczny, własny magazyn danych (standardowy) | 41-standard-agent-setup |
| Ogranicz, kto może wywoływać punkt końcowy; publiczny ruch wychodzący jest akceptowalny | Publiczny ruch wychodzący z prywatnym punktem końcowym | 10-private-network-basic |
| Pełna izolacja bez publicznego ruchu wychodzącego, masz pełną kontrolę nad siecią i chcesz używać własnych zasobów danych | Sieć wirtualna BYO z własnymi zasobami danych (standard zabezpieczony sieciowo) | 15-private-network-standard-agent-setup |
| Pełna izolacja bez publicznego ruchu wychodzącego— kontrolujesz sieć, ale nie chcesz zarządzać zasobami danych | Sieć wirtualna BYO z zasobami danych zarządzanymi przez platformę | 11-private-network-basic-vnet |
| Pełna izolacja, ale nie możesz zarządzać zakresami adresów IP lub Twoja przestrzeń adresów IP nakłada się na inną | Zarządzana sieć wirtualna | 18-managed-virtual-network |
| Pełna izolacja za bramą interfejsu API | Sieć wirtualna BYO z Azure API Management | 16-private-network-standard-agent-apim-setup |
| Uzyskuj dostęp do zasobów lokalnych za pomocą agentów | Sieć wirtualna BYO plus sieć VPN lub ExpressRoute |
15-private-network-standard-agent-setup plus Dostęp do zasobów lokalnych |
Pełny katalog szablonów oraz informacje o tym, co każdy z nich wdraża, znajdziesz w pliku README dotyczącym konfiguracji infrastruktury.
Wymagania dotyczące własnej sieci wirtualnej
Zarówno sieć wirtualna BYO, jak i zarządzana sieć wirtualna zapewniają pełną izolację. Różnica polega na tym, kto zarządza siecią: w przypadku zarządzanej sieci wirtualnej Microsoft zajmuje się za Ciebie wymaganiami opisanymi w tej sekcji. Wybierz sieć wirtualną BYO, jeśli chcesz mieć pełną kontrolę nad siecią, którą już zarządzasz — własnymi zakresami adresów IP, zaporą, komunikacją równorzędną i routingiem.
Po wybraniu sieci wirtualnej BYO należy zaplanować te wymagania przed wdrożeniem. Instrukcje konfiguracji i szczegółowe omówienie obejmują je w całości.
- Dedykowana, delegowana podsieć. Deleguj podsieć do
Microsoft.App/environments. Podsieć nie może być udostępniana więcej niż jednemu zasobowi Foundry. Dostosuj rozmiar do oczekiwanej skali; zobacz Zaplanuj rozmiar podsieci. - Wyłącznie przestrzeń adresowa RFC 1918. Użyj
10.0.0.0/8,172.16.0.0/12lub192.168.0.0/16. Zakresy publiczne i CGNAT nie są obsługiwane. Zakresy klasy A (10.x) są dostępne tylko w niektórych regionach. - Wybór zasobów danych. W przypadku sieci wirtualnej BYO można wybrać sposób udostępniania zasobów danych agenta (Azure Storage, Wyszukiwanie AI platformy Azure i Azure Cosmos DB):
- Zasoby danych zarządzane przez platformę. Używaj wielodostępnych, zarządzanych przez platformę zasobów danych, aby nie wprowadzać ani konfigurować własnych. Wybierz tę opcję, gdy agenci nie potrzebują zasobów danych zarządzanych przez klienta , na przykład wielu scenariuszy hostowanych agentów lub gdy chcesz uniknąć planowania pojemności dla zasobów, takich jak Azure Cosmos DB. Ta opcja eliminuje konieczność konfigurowania zasobów danych, których nie używasz.
- Korzystanie z własnych zasobów danych. Użyj własnych usług Azure Storage, Wyszukiwanie AI platformy Azure i Azure Cosmos DB, aby wszystkie dane agentów pozostawały w Twojej dzierżawie. Wybierz tę opcję, jeśli potrzebujesz danych agenta w zasobach, których jesteś właścicielem i którymi zarządzasz.
- Prywatne punkty końcowe i prywatne strefy DNS dla konta Foundry oraz dla każdego zasobu danych, który dodajesz, aby rozpoznawanie nazw odbywało się w obrębie sieci wirtualnej.
- Ten sam region dla zasobu Foundry i sieci wirtualnej. Inne zasoby mogą znajdować się w różnych regionach, co ma wpływ na koszty między regionami.
Ważna
Ustaw konfigurację sieci wirtualnej podczas tworzenia konta usługi Foundry. Wstrzyknięcie sieci jest częścią procesu tworzenia zasobu i nie można go dodać do istniejącego konta. Konfiguracja sieci ma zastosowanie podczas tworzenia pierwszego hostowanego agenta i nie można później zmienić iniekcji sieci. Aby przejść do innej konfiguracji sieci, utwórz nowe projekty. Konfiguracja ma zastosowanie na poziomie konta, więc obejmuje zarówno hostowanych, jak i monitowanych agentów. Przed utworzeniem konta zdecyduj się na sieć wirtualną BYO.
Aby zapoznać się z diagramem topologii opcji BYO Virtual Network — delegowanej podsieci, mikromaszyn wirtualnych hostowanego agenta i prywatnych punktów końcowych zasobów danych — zobacz Szczegółowe informacje o sieci usługi Foundry Agent Service.
Wsparcie dla narzędzi z izolacją sieci
Nie wszystkie narzędzia agenta obsługują izolację sieci. Niektóre narzędzia nie są obsługiwane za siecią wirtualną, a niektóre docierają do miejsca docelowego za pośrednictwem publicznego Internetu, a nie sieci prywatnej. Przed zatwierdzeniem konfiguracji izolowanej sprawdź narzędzia agenta z izolacją sieci , aby upewnić się, że narzędzia używane przez agentów są obsługiwane.
Planowanie rozmiaru podsieci
Podsieć musi mieć co najmniej /27 i nie można zmienić jej rozmiaru po jej przypisaniu, dlatego należy dobrać jej rozmiar do przewidywanej skali. Wszystkie projekty na koncie Foundry korzystają ze wspólnej podsieci, dlatego uwzględnij łączne wykorzystanie wszystkich projektów, agentów i równoczesnych sesji na koncie. Azure rezerwuje pięć adresów IP w każdej podsieci do użytku wewnętrznego.
- Hostowani agenci działają w dedykowanej maszynie wirtualnej mikro z własnym interfejsem sieciowym, więc każdy z nich korzysta z adresu IP z podsieci. Użycie adresów IP jest skalowane z liczbą projektów, hostowanymi agentami w każdym projekcie i ich współbieżnymi sesjami. Nowe poprawki używają również adresów IP tymczasowo podczas wdrażania, gdy stare i nowe poprawki są uruchamiane równolegle.
- Agenty promptów nie zużywają osobnego adresu IP na każdą wersję. Korzystają z małej, statycznej puli adresów IP (do około 10 na projekt), niezależnie od tego, ilu agentów promptów lub wersji używasz.
| Rozmiar podsieci | Recommendation |
|---|---|
| /24 | Zalecane do zastosowań produkcyjnych w przypadku hostowanych agentów. Pozostawia możliwość skalowania hostowanych agentów w projektach, obsługi współbieżnych sesji i absorbowania uaktualnień w miejscu. |
| /27 | Minimalna obsługiwana wartość. Sprawdza się w środowisku produkcyjnym przy uruchamianiu agentów promptów lub w przypadku mniejszych wdrożeń agentów hostowanych. Pozostawia mniejszy zapas do skalowania hostowanych agentów i obsługi współbieżnych sesji. |
Informacje na temat modelu alokacji IP, limitów równoczesnych sesji i obliczeń dotyczących doboru rozmiaru można znaleźć w artykule Szczegółowe omówienie sieci usługi Foundry Agent Service.
Agenci hostowani a agenci oparti na promptach
Opcja sieci ma zastosowanie do całego konta usługi Foundry, ale dwa typy agentów używają zasobów sieciowych inaczej, zgodnie z opisem w temacie Planowanie rozmiaru podsieci. Oba typy docierają do zasobów za pośrednictwem prywatnych punktów końcowych w sieci wirtualnej.
Następne kroki
- Wdróż opcję przy użyciu instrukcji konfiguracji lub szablonu z tabeli.
- Zweryfikuj wdrożenie: potwierdź delegowanie podsieci, że dostęp publiczny jest wyłączony i czy punkty końcowe rozpoznają prywatne adresy IP z wewnątrz sieci wirtualnej. Zobacz Weryfikowanie wdrożenia.
- Rozwiąż wszelkie błędy wdrożenia lub łączności za pomocą przewodnika rozwiązywania problemów.