Udostępnij przez

Podejścia architektoniczne dla sieci w rozwiązaniach wielodostępnych

Wszystkie rozwiązania wdrożone na platformie Azure wymagają pewnej formy sieci. Sposób interakcji z usługami sieciowymi platformy Azure zależy od projektu i obciążenia rozwiązania. Ten artykuł zawiera zagadnienia i wskazówki dotyczące aspektów sieci wielodostępnych rozwiązań na platformie Azure. Zawiera on informacje o składnikach sieci niższego poziomu, takich jak sieci wirtualne, i rozszerza się na podejścia wyższego poziomu i warstwy aplikacji.

Uwaga / Notatka

Platforma Azure jest środowiskiem wielodostępnym, podobnie jak wiele składników sieci. Nie musisz rozumieć szczegółów dotyczących projektowania własnego rozwiązania, ale możesz dowiedzieć się więcej o tym, jak platforma Azure izoluje ruch sieciowy od ruchu innych klientów.

Kluczowe zagadnienia i wymagania

Usługi infrastruktury i platformy

Zagadnienia dotyczące składnika sieci zależą od kategorii używanych usług.

Usługi infrastruktury

W przypadku korzystania z usług infrastruktury, takich jak maszyny wirtualne lub usługa Azure Kubernetes Service (AKS), rozważ i zaprojektuj sieci wirtualne, które stanowią podstawę łączności usług. Należy również wziąć pod uwagę inne warstwy zabezpieczeń i izolacji, które należy uwzględnić w projekcie. Unikaj polegania wyłącznie na kontrolkach warstwy sieciowej.

Usługi platformowe

W przypadku korzystania z usług platformy Azure, takich jak Azure App Service, Azure Cosmos DB lub Azure SQL Database, architektura określa wymagane usługi sieciowe.

Aby odizolować usługi platformy od Internetu, użyj sieci wirtualnej. W zależności od używanych usług możesz pracować z prywatnymi punktami końcowymi lub zasobami zintegrowanymi z siecią wirtualną, takimi jak usługa Azure Application Gateway. Możesz również udostępnić usługi platformy za pośrednictwem ich publicznych adresów IP i korzystać z własnych zabezpieczeń usług, takich jak zapory i mechanizmy kontroli tożsamości. W takich sytuacjach może nie być konieczne wdrożenie i skonfigurowanie własnej sieci wirtualnej.

Zdecyduj, czy używać sieci wirtualnych dla usług platformy na podstawie następujących czynników:

  • Wymagania dotyczące zgodności: Może być konieczne spełnienie określonego standardu zgodności. Niektóre standardy wymagają skonfigurowania środowiska platformy Azure w określony sposób, na przykład przy użyciu określonych mechanizmów kontroli sieci. Aby uzyskać więcej informacji, zobacz Metody architektury zapewniania ładu i zgodności w rozwiązaniach wielodostępnych.

  • Wymagania dzierżaw: Nawet jeśli organizacja nie ma zdefiniowanych wymagań dotyczących izolacji lub kontrolek warstwy sieciowej, dzierżawcy mogą. Jasno zrozumieć, jak dzierżawcy planują uzyskiwać dostęp do rozwiązania i czy mają jakiekolwiek założenia dotyczące projektu sieci.

  • Złożoność: Sieci wirtualne wprowadzają złożoność. Upewnij się, że twój zespół jasno rozumie zasady związane z unikaniem wdrażania niezabezpieczonego środowiska.

Upewnij się, że rozumiesz implikacje korzystania z sieci prywatnej.

Ustawianie rozmiaru podsieci

W przypadku konieczności wdrożenia sieci wirtualnej należy dokładnie rozważyć rozmiar i przestrzeń adresową całej sieci wirtualnej, w tym podsieci.

Dowiedz się, jak planujesz wdrożyć zasoby platformy Azure w sieciach wirtualnych i liczbę adresów IP używanych przez każdy zasób. W przypadku wdrażania węzłów obliczeniowych specyficznych dla dzierżawy, serwerów baz danych lub innych zasobów utwórz podsieci wystarczająco duże dla oczekiwanego wzrostu dzierżawy i skalowania automatycznego zasobów w poziomie.

Podobnie podczas pracy z usługami zarządzanymi zrozumieć sposób korzystania z adresów IP. Na przykład w przypadku korzystania z usługi AKS z interfejsem azure Container Networking Interface (CNI) liczba adresów IP używanych z podsieci zależy od czynników, takich jak liczba węzłów, sposób skalowania w poziomie i procesu wdrażania usługi. W przypadku korzystania z usług App Service i Azure Functions z integracją sieci wirtualnej liczba użytych adresów IP zależy od liczby wystąpień planu.

Zapoznaj się ze wskazówkami dotyczącymi segmentacji podsieci podczas planowania podsieci.

Dostęp publiczny lub prywatny

Zastanów się, czy dzierżawcy muszą uzyskiwać dostęp do usług za pośrednictwem Internetu, czy za pośrednictwem prywatnych adresów IP.

Aby zabezpieczyć usługę na potrzeby dostępu internetowego (publicznego), użyj reguł zapory, dozwolonych adresów IP i listy dozwolonych adresów IP, udostępnionych wpisów tajnych i kluczy oraz kontrolek opartych na tożsamościach.

Aby umożliwić dzierżawcom łączenie się z usługą przy użyciu prywatnych adresów IP, rozważ użycie usługi Azure Private Link lub komunikacji równorzędnej między dzierżawami sieci wirtualnych. W przypadku niektórych ograniczonych scenariuszy możesz również rozważyć użycie usługi Azure ExpressRoute lub usługi Azure VPN Gateway w celu umożliwienia prywatnego dostępu do rozwiązania. Zazwyczaj takie podejście ma sens tylko wtedy, gdy masz kilka dzierżaw i wdrażasz dedykowane sieci wirtualne dla każdej dzierżawy.

Dostęp do punktów końcowych najemców

Zastanów się, czy musisz wysyłać dane do punktów końcowych w sieciach dzierżaw, wewnątrz platformy Azure lub poza nimi. Możesz na przykład wywołać element webhook dostarczony przez klienta lub wysłać komunikaty w czasie rzeczywistym do systemów dzierżawy.

Jeśli musisz wysyłać dane do punktów końcowych dzierżaw, rozważ następujące typowe podejścia:

  • Inicjuj połączenia z Twojego rozwiązania do punktów końcowych najemców przez internet. Zastanów się, czy połączenia muszą pochodzić ze statycznego adresu IP. W zależności od używanych usług platformy Azure może być konieczne użycie translatora adresów sieciowych (NAT), wdrażając usługę Azure NAT Gateway, zaporę lub moduł równoważenia obciążenia.

  • Wdróż agenta , aby umożliwić łączność między usługami hostowanymi na platformie Azure i sieciami klientów, niezależnie od ich lokalizacji.

  • Rozważ użycie usługi, takiej jak Azure Event Grid, potencjalnie z domenami zdarzeń, na potrzeby obsługi komunikatów jednokierunkowych.

Podejścia i wzorce do rozważenia

W tej sekcji opisano niektóre kluczowe podejścia sieciowe do rozważenia w rozwiązaniu wielodostępnym. Rozpoczyna się od podejścia niższego poziomu dla podstawowych składników sieci, a następnie opisuje podejścia dotyczące protokołu HTTP i innych zagadnień dotyczących warstwy aplikacji.

Sieci wirtualne specyficzne dla dzierżawy z wybranymi przez dostawcę usług adresami IP

W niektórych scenariuszach należy uruchamiać dedykowane zasoby połączone z siecią wirtualną na platformie Azure w imieniu dzierżawy. Możesz na przykład uruchomić maszynę wirtualną dla każdej dzierżawy lub użyć prywatnych punktów końcowych w celu uzyskania dostępu do baz danych specyficznych dla dzierżawy.

Rozważ wdrożenie sieci wirtualnej dla każdej dzierżawy przy użyciu przestrzeni adresowej IP, którą kontrolujesz. Takie podejście umożliwia komunikację równorzędną między sieciami wirtualnymi we własnych celach, takich jak ustanowienie topologii piasty i szprych w celu centralnego kontrolowania ruchu przychodzącego i wychodzącego.

Unikaj używania wybranych przez dostawcę usług adresów IP, jeśli dzierżawcy muszą łączyć się bezpośrednio z utworzoną siecią wirtualną, na przykład za pomocą komunikacji równorzędnej sieci wirtualnych. Wybrana przestrzeń adresowa prawdopodobnie powoduje konflikt z istniejącymi przestrzeniami adresowymi.

Sieci wirtualne specyficzne dla dzierżawy z wybranymi przez dzierżawę adresami IP

Jeśli dzierżawcy muszą łączyć własne sieci wirtualne z siecią wirtualną zarządzaną w ich imieniu, rozważ wdrożenie sieci wirtualnych specyficznych dla dzierżawy przy użyciu przestrzeni adresowej IP wybranej przez dzierżawę. Ta konfiguracja umożliwia każdej dzierżawie zapewnienie, że zakresy adresów IP w sieci wirtualnej systemu nie nakładają się na własne sieci wirtualne, co umożliwia zgodność z komunikacją równorzędną.

Jednak takie podejście prawdopodobnie uniemożliwia komunikację równorzędną sieci wirtualnych dzierżawców razem lub wdrożenie topologii piasty i szprych. Równorzędne sieci wirtualne nie mogą używać nakładających się zakresów adresów IP, a gdy dzierżawcy wybierają własne zakresy adresów IP, prawdopodobnie będą wybierać zakresy nakładające się na siebie.

Topologia piasty i szprych

Topologia sieci wirtualnej piasty i szprych umożliwia komunikację równorzędną scentralizowanej sieci wirtualnej koncentratora z wieloma sieciami wirtualnymi szprych. Możesz centralnie kontrolować ruch przychodzący i wychodzący dla sieci wirtualnych i kontrolować, czy zasoby w sieci wirtualnej każdej szprychy mogą komunikować się ze sobą. Każda sieć wirtualna szprych może również uzyskiwać dostęp do składników udostępnionych, takich jak Azure Firewall, i może korzystać z usług takich jak Azure DDoS Protection.

Jeśli używasz topologii piasty i szprych, zaplanuj limity, takie jak maksymalna liczba równorzędnych sieci wirtualnych. Nie używaj nakładających się przestrzeni adresowych dla sieci wirtualnej każdej dzierżawy.

Rozważ użycie topologii piasty i szprych podczas wdrażania sieci wirtualnych specyficznych dla dzierżawy, które używają wybranych adresów IP. Sieć wirtualna każdej dzierżawy staje się szprychą i może współdzielić wspólne zasoby w sieci wirtualnej piasty. Można również użyć topologii piasty i szprych podczas skalowania zasobów udostępnionych w wielu sieciach wirtualnych lub w przypadku korzystania ze wzorca sygnatur wdrażania.

Wskazówka

Jeśli rozwiązanie obejmuje wiele regionów geograficznych, wdróż oddzielne centra i zasoby koncentratora w każdym regionie, aby zapobiec przekraczaniu wielu regionów świadczenia usługi Azure. Ta praktyka wiąże się z wyższym kosztem zasobów, ale zmniejsza opóźnienie żądań i zmniejsza globalne opłaty za komunikację równorzędną.

Statyczne adresy IP

Zastanów się, czy dzierżawcy potrzebują twojej usługi, aby używać statycznych publicznych adresów IP dla ruchu przychodzącego, ruchu wychodzącego lub obu tych adresów. Różne usługi platformy Azure umożliwiają statyczne adresy IP na różne sposoby.

Podczas pracy z maszynami wirtualnymi i innymi składnikami infrastruktury rozważ użycie modułu równoważenia obciążenia lub zapory dla przychodzącego i wychodzącego statycznego adresowania IP. Rozważ użycie usługi Azure NAT Gateway do kontrolowania adresu IP ruchu wychodzącego. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące usługi Azure NAT Gateway dotyczące wielodostępności.

Podczas pracy z usługami platformy określona usługa, której używasz, określa sposób kontrolowania adresów IP. Może być konieczne skonfigurowanie zasobu w określony sposób, na przykład przez wdrożenie zasobu takiego jak maszyna wirtualna w sieci wirtualnej, a następnie użycie bramy translatora adresów sieciowych lub zapory. Możesz też zażądać bieżącego zestawu adresów IP używanych przez usługę dla ruchu wychodzącego. Na przykład usługa App Service udostępnia interfejs API i interfejs internetowy umożliwiający uzyskanie bieżących wychodzących adresów IP dla aplikacji.

Agenci

Aby umożliwić dzierżawcom odbieranie komunikatów inicjowanych przez rozwiązanie lub uzyskiwanie dostępu do danych w sieciach dzierżaw, rozważ udostępnienie agenta, nazywanego czasem bramą lokalną, które wdrażają w sieci. Takie podejście może pracować, czy sieci dzierżawców znajdują się na platformie Azure, u innego dostawcy usług w chmurze, czy w środowisku lokalnym.

Agent inicjuje połączenie wychodzące z określonym punktem końcowym i jego kontrolą. Utrzymuje długotrwałe połączenia przy życiu lub sporadycznie sonduje. Rozważ użycie usługi Azure Relay do ustanawiania połączeń z agenta do usługi i zarządzania nimi. Po nawiązaniu połączenia agent uwierzytelnia się i dodaje pewne informacje o identyfikatorze klienta, dzięki czemu usługa może mapować połączenie z poprawnym klientem.

Przedstawiciele zazwyczaj upraszczają konfigurację zabezpieczeń dla dzierżawców. Otwieranie portów przychodzących, szczególnie w środowisku lokalnym, może być skomplikowane i ryzykowne. Agent eliminuje konieczność podejmowania tego ryzyka przez dzierżawców.

Usługi firmy Microsoft, które zapewniają agentom łączność z sieciami dzierżawców, obejmują następujące przykłady:

Usługa Private Link zapewnia prywatną łączność ze środowiska platformy Azure dzierżawy do rozwiązania. Dzierżawcy mogą również używać usługi Private Link z własną siecią wirtualną, aby uzyskać dostęp do usługi ze środowiska lokalnego. Platforma Azure bezpiecznie kieruje ruch do usługi przy użyciu prywatnych adresów IP.

Aby uzyskać więcej informacji, zobacz Multitenancy and Private Link (Obsługa wielu dzierżaw i usługa Private Link).

Nazwy domen, poddomeny i TLS

Podczas pracy z nazwami domen i protokołem TLS (Transport Layer Security) w rozwiązaniu wielodostępnym zapoznaj się z kluczowymi zagadnieniami.

Wzorce routingu bramy i offloadingu bramy

Wzorzec routingu bramy i wzorzec odciążania bramy obejmują wdrożenie zwrotnego serwera proxy lub bramy warstwy 7. Bramy zapewniają podstawowe usługi dla aplikacji wielodostępnej, w tym następujące możliwości:

  • Kierowanie żądań do zapleczy specyficznych dla dzierżawy lub sygnatur wdrożenia
  • Obsługa nazw domen specyficznych dla dzierżawy i certyfikatów TLS
  • Sprawdzanie żądań zagrożeń bezpieczeństwa przy użyciu zapory aplikacji internetowej (WAF)
  • Buforowanie odpowiedzi w celu zwiększenia wydajności

Platforma Azure oferuje kilka usług, które umożliwiają osiągnięcie niektórych lub wszystkich tych celów, w tym usług Azure Front Door, Application Gateway i Azure API Management. Możesz również wdrożyć własne rozwiązanie niestandardowe przy użyciu oprogramowania, takiego jak NGINX lub HAProxy.

Jeśli planujesz wdrożenie bramy dla rozwiązania, dobrym rozwiązaniem jest najpierw utworzenie kompletnego prototypu. Uwzględnij wszystkie wymagane funkcje i sprawdź, czy składniki aplikacji działają zgodnie z oczekiwaniami. Należy również zrozumieć, jak składnik bramy jest skalowany w celu obsługi ruchu i wzrostu dzierżawy.

Wzorzec hostingu zawartości statycznej

Wzorzec hostingu zawartości statycznej obsługuje zawartość internetową z natywnej dla chmury usługi magazynu i używa sieci dostarczania zawartości do buforowania zawartości.

Możesz użyć usługi Azure Front Door lub innej sieci dostarczania zawartości dla statycznych składników rozwiązania, takich jak jednostronicowe aplikacje JavaScript i zawartości statycznej, takiej jak pliki obrazów i dokumenty.

W zależności od projektu rozwiązania może być również możliwe buforowanie plików lub danych specyficznych dla dzierżawy w sieci dostarczania zawartości, takich jak odpowiedzi interfejsu API w formacie JSON. Ta praktyka może pomóc zwiększyć wydajność i skalowalność rozwiązania. Upewnij się, że dane specyficzne dla dzierżawy pozostają wystarczająco odizolowane, aby zapobiec wyciekowi danych między dzierżawami. Rozważ sposób usuwania zawartości specyficznej dla najemcy z pamięci podręcznej, na przykład podczas aktualizowania danych lub wdrażania nowej wersji aplikacji. Uwzględniając identyfikator dzierżawy w ścieżce adresu URL, można określić, czy przeczyszczasz określony plik, wszystkie pliki powiązane z określoną dzierżawą lub wszystkie pliki dla wszystkich dzierżaw.

Antywzorce, których należy unikać

Nie można zaplanować łączności z siecią wirtualną

Wdrażanie zasobów w sieciach wirtualnych zapewnia znaczącą kontrolę nad przepływem ruchu przez składniki rozwiązania. Jednak integracja sieci wirtualnej wprowadza również większą złożoność, koszt i inne czynniki, które należy wziąć pod uwagę, zwłaszcza w przypadku składników paaS (platform as a service).

Przetestuj i zaplanuj strategię sieci, aby zidentyfikować wszelkie problemy przed wdrożeniem go w środowisku produkcyjnym.

Nie planuje limitów

Platforma Azure wymusza wiele limitów wpływających na zasoby sieciowe. Te limity obejmują limity zasobów platformy Azure oraz podstawowe limity protokołu i platformy. Na przykład podczas tworzenia wielodostępnego rozwiązania o dużej skali w usługach platformy, takich jak App Service i Azure Functions, może być konieczne rozważenie liczby połączeń protokołu TCP (Transmission Control Protocol) i portów SNAT (Source Network Address Translation). Podczas pracy z maszynami wirtualnymi i modułami równoważenia obciążenia należy również wziąć pod uwagę ograniczenia dotyczące reguł ruchu wychodzącego i portów SNAT.

Małe podsieci

Rozmiar każdej podsieci w celu obsługi liczby zasobów lub wystąpień zasobów, które mają zostać wdrożone, szczególnie w miarę skalowania. Podczas pracy z zasobami PaaS dowiedz się, jak konfiguracja i skala zasobu wpływają na liczbę adresów IP wymaganych w jej podsieci.

Niewłaściwa segmentacja sieci

Jeśli twoje rozwiązanie wymaga sieci wirtualnych, rozważ sposób konfigurowania segmentacji sieci w celu kontrolowania ruchu przychodzącego i wychodzącego (znanego jako ruch północno-południowy), a także ruchu w ramach rozwiązania (znanego jako ruch wschód-zachód). Zdecyduj, czy dzierżawcy powinni mieć własne sieci wirtualne, czy też należy wdrożyć udostępnione zasoby w udostępnionych sieciach wirtualnych. Zmiana podejścia może być trudna, dlatego należy dokładnie rozważyć wszystkie wymagania przed wybraniem podejścia, które działa dla przyszłych celów rozwoju.

Poleganie tylko na mechanizmach kontroli zabezpieczeń warstwy sieciowej

W nowoczesnych rozwiązaniach należy połączyć zabezpieczenia warstwy sieciowej z innymi mechanizmami kontroli zabezpieczeń. Nie należy polegać tylko na zaporach ani segmentacji sieci. Takie podejście jest czasami nazywane siecią zerową zaufania. Użyj kontrolek opartych na tożsamościach, aby zweryfikować klienta, obiekt wywołujący lub użytkownika w każdej warstwie rozwiązania. Rozważ użycie usług, które umożliwiają dodawanie dodatkowych warstw ochrony. Dostępne opcje zależą od używanych usług platformy Azure. W usłudze AKS rozważ użycie siatki usług na potrzeby wzajemnego uwierzytelniania TLS i stosowanie zasad sieci w celu kontrolowania ruchu east-west. W usłudze App Service rozważ użycie wbudowanej obsługi uwierzytelniania i autoryzacji oraz ograniczeń dostępu.

Ponowne zapisywanie nagłówków hostów bez testowania

Jeśli używasz wzorca odciążania bramy, możesz rozważyć ponowne zapisywanie Host nagłówka żądań HTTP. Takie rozwiązanie może uprościć konfigurację usługi aplikacji internetowej zaplecza, odciążając domenę niestandardową i zarządzanie protokołem TLS do bramy.

Jednak Host ponowne zapisywanie nagłówków może powodować problemy z niektórymi usługami zaplecza. Jeśli aplikacja wystawia przekierowania HTTP lub pliki cookie, niezgodność nazw hostów może przerwać działanie aplikacji. W szczególności ten problem może wystąpić, gdy korzystasz z usług zaplecza, które działają w infrastrukturze wielodostępnej, takiej jak App Service i Azure Functions. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące zachowywania nazw hostów.

Przetestuj zachowanie aplikacji przy użyciu konfiguracji bramy, która ma być używana.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

  • John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure

Inni współautorzy:

  • Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure
  • Joshua Waddell | Starszy Inżynier Klienta, FastTrack for Azure

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

  • Last updated on