Udostępnij za pośrednictwem

Metody architektury dla sieci w rozwiązaniach wielodostępnych

  • Artykuł

Wszystkie rozwiązania wdrożone na platformie Azure wymagają pewnego rodzaju sieci. W zależności od projektu rozwiązania i obciążenia sposoby interakcji z usługami sieciowymi platformy Azure mogą się różnić. W tym artykule przedstawiono zagadnienia i wskazówki dotyczące aspektów sieci wielodostępnych rozwiązań na platformie Azure. Uwzględniamy informacje o składnikach sieci niższego poziomu, takich jak sieci wirtualne, za pomocą metod wyższego poziomu i warstwy aplikacji.

Uwaga

Sama platforma Azure jest środowiskiem wielodostępnym, a składniki sieciowe platformy Azure są zaprojektowane pod kątem wielodostępności. Chociaż nie jest wymagane zrozumienie szczegółów w celu zaprojektowania własnego rozwiązania, 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

Obawy dotyczące składników sieci różnią się w zależności od kategorii używanych usług.

Usługi infrastruktury

Za każdym razem, gdy korzystasz z usług infrastruktury, takich jak maszyny wirtualne lub usługa Azure Kubernetes Service, należy rozważyć i zaprojektować 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 platformy

Jeśli używasz usług platformy Azure, takich jak App Service, Azure Cosmos DB lub Azure SQL Database, określona używana architektura określi wymagane usługi sieciowe.

Jeśli musisz odizolować usługi platformy od Internetu, musisz użyć 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 Application Gateway. Możesz jednak 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ć potrzebna sieć wirtualna.

Decyzja o tym, czy używać sieci wirtualnych dla usług platformy, jest oparta na wielu wymaganiach, w tym na następujących czynnikach:

  • Wymagania dotyczące zgodności: może być konieczne spełnienie określonego standardu zgodności. Niektóre standardy wymagają skonfigurowania środowiska platformy Azure na określony sposób.
  • Wymagania dzierżaw: nawet jeśli Twoja organizacja nie ma określonych wymagań dotyczących izolacji lub kontrolek warstwy sieciowej, dzierżawcy mogą. Upewnij się, że masz wyraźną wiedzę na temat sposobu uzyskiwania dostępu do rozwiązania przez dzierżawców i czy mają jakiekolwiek założenia dotyczące projektu sieci.
  • Złożoność: zrozumienie i praca z sieciami wirtualnymi może być bardziej skomplikowane. Upewnij się, że twój zespół ma jasne informacje o zaangażowanych zasadach lub prawdopodobnie wdrożysz niezabezpieczone środowisko.

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

Ustalanie rozmiaru podsieci

Jeśli musisz wdrożyć sieć wirtualną, należy dokładnie rozważyć rozmiar i przestrzeń adresową całej sieci wirtualnej oraz podsieci w sieci wirtualnej.

Upewnij się, że wiesz, jak wdrożysz zasoby platformy Azure w sieciach wirtualnych, a liczba adresów IP zuż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 upewnij się, że utworzysz podsieci, które są wystarczająco duże dla oczekiwanego wzrostu dzierżawy i skalowania automatycznego zasobów w poziomie.

Podobnie podczas pracy z usługami zarządzanymi ważne jest, aby zrozumieć sposób korzystania z adresów IP. Na przykład w przypadku korzystania z usługi Azure Kubernetes Service z interfejsem azure Container Networking Interface (CNI) liczba adresów IP używanych z podsieci będzie oparta na czynnikach, takich jak liczba węzłów, sposób skalowania w poziomie i używany proces wdrażania usługi. W przypadku korzystania z usługi aplikacja systemu Azure i usługi Azure Functions z integracją z siecią wirtualną liczba użytych adresów IP jest oparta na liczbie 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 będą uzyskiwać dostęp do usług za pośrednictwem Internetu, czy za pośrednictwem prywatnych adresów IP.

W przypadku dostępu internetowego (publicznego) można użyć 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 zabezpieczyć usługę.

Jeśli musisz włączyć łączność z usługą przy użyciu prywatnych adresów IP, rozważ użycie usługi Azure Private Link Service 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 niewielką liczbę dzierżaw, a podczas wdrażania dedykowanych sieci wirtualnych dla każdej dzierżawy.

Dostęp do punktów końcowych dzierżaw

Zastanów się, czy musisz wysyłać dane do punktów końcowych w sieciach dzierżaw, w obrębie platformy Azure lub poza nimi. Na przykład czy konieczne będzie wywołanie elementu webhook dostarczonego przez klienta, czy też wysłanie komunikatów w czasie rzeczywistym do dzierżawy?

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

  • Zainicjuj połączenia z rozwiązania do punktów końcowych dzierżaw 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 wdrożenie bramy translatora adresów sieciowych, zapory lub modułu 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 tego, gdzie się znajdują.
  • W przypadku obsługi komunikatów jednokierunkowych rozważ użycie usługi, takiej jak Azure Event Grid, potencjalnie w połączeniu z domenami zdarzeń.

Podejścia i wzorce do rozważenia

W tej sekcji opisano niektóre kluczowe podejścia sieciowe, które można wziąć pod uwagę w rozwiązaniu wielodostępnym. Zaczynamy od opisania podejść niższego poziomu dla podstawowych składników sieci, a następnie postępuj zgodnie z metodami, które można wziąć pod uwagę w przypadku protokołu HTTP i innych problemów warstwy aplikacji.

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

W niektórych sytuacjach 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, na przykład w przypadku konieczności ustanowienia topologii piasty i szprych w celu centralnego kontrolowania ruchu przychodzącego i wychodzącego.

Jednak wybrane przez dostawcę usług adresy IP nie są odpowiednie, jeśli dzierżawcy muszą łączyć się bezpośrednio z utworzoną siecią wirtualną, na przykład za pomocą komunikacji równorzędnej sieci wirtualnych. Prawdopodobnie wybrana przestrzeń adresowa będzie niezgodna z ich własnymi 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 z wybraną przestrzenią adresową IP. Ten system 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. Korzystając z nienakładających się zakresów adresów IP, mogą zapewnić, że ich sieci są zgodne z komunikacją równorzędną.

Jednak takie podejście oznacza, że jest mało prawdopodobne, aby można było połączyć ze sobą sieci wirtualne dzierżawców lub przyjąć topologię piasty i szprych, ponieważ istnieje prawdopodobieństwo nakładania się zakresów adresów IP między sieciami wirtualnymi różnych dzierżaw.

Topologia gwiazdy

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

W przypadku korzystania z topologii piasty i szprych upewnij się, że planujesz obejście limitów, takich jak maksymalna liczba równorzędnych sieci wirtualnych, i upewnij się, że nie używasz nakładających się przestrzeni adresowych dla sieci wirtualnej każdej dzierżawy.

Topologia piasty i szprych może być przydatna podczas wdrażania sieci wirtualnych specyficznych dla dzierżawy z wybranymi adresami IP. Sieć wirtualna każdej dzierżawy staje się szprychą i może udostępniać 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 do celów skalowania lub w przypadku używania wzorca sygnatur wdrażania.

Napiwek

Jeśli rozwiązanie działa w wielu regionach geograficznych, zazwyczaj dobrym rozwiązaniem jest wdrożenie oddzielnych centrów i zasobów koncentratora w każdym regionie. Chociaż ta praktyka wiąże się z wyższym kosztem zasobów, pozwala uniknąć niepotrzebnego przechodzenia ruchu przez wiele regionów platformy Azure, co może zwiększyć opóźnienie żądań i spowodować naliczenie globalnych opłat 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 bramy translatora adresów sieciowych do kontrolowania adresu IP ruchu wychodzącego. Aby uzyskać więcej informacji na temat korzystania z bramy translatora adresów sieciowych w rozwiązaniu wielodostępnym, zobacz Zagadnienia dotyczące usługi Azure NAT Gateway dotyczące wielodostępności.

Podczas pracy z usługami platformy używana usługa określa, czy i jak można kontrolować adresy 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

Jeśli chcesz umożliwić dzierżawcom odbieranie komunikatów inicjowanych przez rozwiązanie lub jeśli musisz uzyskać dostęp do danych istniejących w sieciach własnych dzierżaw, rozważ udostępnienie agenta (nazywanego czasami bramą lokalną), który może zostać wdrożony 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 kontroluje go, a także okresowo utrzymuje długotrwałe połączenia lub sonduje sporadycznie. 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 zawiera pewne informacje o identyfikatorze dzierżawy, dzięki czemu usługa może mapować połączenie z poprawną dzierżawą.

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

Przykłady usługi firmy Microsoft, które zapewniają agentom łączność z sieciami dzierżaw:

Usługa Azure Private Link zapewnia łączność prywatną 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 na temat usługi Private Link i wielodostępności, zobacz Multitenancy i Azure Private Link.

Nazwy domen, poddomeny i TLS

Podczas pracy z nazwami domen i zabezpieczeniami warstwy transportu (TLS) w rozwiązaniu wielodostępnym należy wziąć pod uwagę szereg zagadnień. Zapoznaj się z zagadnieniami dotyczącymi wielodostępności i nazw domen.

Wzorce odciążania i routingu bramy

Wzorzec routingu bramy i wzorzec odciążania bramy obejmują wdrożenie zwrotnego serwera proxy lub bramy warstwy 7. Bramy są przydatne do dostarczania podstawowych usług dla aplikacji wielodostępnej, w tym następujących 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 udostępnia kilka usług, których można użyć do osiągnięcia niektórych lub wszystkich tych celów, w tym usług Azure Front Door, aplikacja systemu Azure 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 skompilowanie kompletnego prototypu zawierającego wszystkie potrzebne funkcje oraz sprawdzenie, czy składniki aplikacji będą nadal działać zgodnie z oczekiwaniami. Należy również zrozumieć, jak składnik bramy będzie skalowany w celu obsługi ruchu i wzrostu dzierżawy.

Wzorzec hostingu zawartości statycznej

Wzorzec hostingu zawartości statycznej obejmuje obsługę zawartości internetowej z natywnej dla chmury usługi magazynu oraz używanie sieci dostarczania zawartości (CDN) do buforowania zawartości.

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

W zależności od sposobu projektowania rozwiązania może być również możliwe buforowanie plików lub danych specyficznych dla dzierżawy w usłudze CDN, takich jak odpowiedzi interfejsu API w formacie JSON. Ta praktyka może pomóc w zwiększeniu wydajności i skalowalności rozwiązania, ale ważne jest, aby rozważyć, czy dane specyficzne dla dzierżawy są wystarczająco odizolowane, aby uniknąć wycieku danych między dzierżawami. Rozważ sposób przeczyszczania zawartości specyficznej dla dzierżawy 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.

Antywzorzecy, aby uniknąć

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

Wdrażając zasoby w sieciach wirtualnych, masz dużą kontrolę nad przepływem ruchu przez składniki rozwiązania. Jednak integracja z siecią wirtualną wprowadza również dodatkową złożoność, koszt i inne czynniki, które należy wziąć pod uwagę. Ten efekt jest szczególnie prawdziwy w przypadku składników platformy jako usługi (PaaS).

Ważne jest, aby przetestować i zaplanować strategię sieci, aby można było odkryć wszelkie problemy przed ich wdrożeniem w środowisku produkcyjnym.

Nie planuje limitów

Platforma Azure wymusza szereg 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 usługa aplikacja systemu Azure i usługa Azure Functions, może być konieczne rozważenie liczby połączeń TCP i portów SNAT. Podczas pracy z maszynami wirtualnymi i modułami równoważenia obciążenia należy również wziąć pod uwagę ograniczenia reguł ruchu wychodzącego i portów SNAT.

Małe podsieci

Ważne jest, aby wziąć pod uwagę rozmiar każdej podsieci, aby zezwolić na liczbę zasobów lub wystąpień zasobów, które zostaną wdrożone, zwłaszcza w miarę skalowania. Podczas pracy z zasobami platformy jako usługi (PaaS) upewnij się, że rozumiesz, w jaki sposób konfiguracja i skala zasobu będą mieć wpływ na liczbę adresów IP wymaganych w jej podsieci.

Niewłaściwa segmentacja sieci

Jeśli twoje rozwiązanie wymaga sieci wirtualnych, rozważ skonfigurowanie segmentacji sieci w celu umożliwienia kontrolowania przepływów ruchu przychodzącego i wychodzącego (północ-południe) oraz przepływów w ramach rozwiązania (wschód-zachód). Zdecyduj, czy dzierżawcy powinni mieć własne sieci wirtualne, czy też wdrożysz zasoby udostępnione w udostępnionych sieciach wirtualnych. Zmiana podejścia może być trudna, dlatego należy wziąć pod uwagę wszystkie wymagania, a następnie wybrać podejście, które będzie działać dla przyszłych celów wzrostu.

Poleganie tylko na mechanizmach kontroli zabezpieczeń warstwy sieciowej

W nowoczesnych rozwiązaniach ważne jest połączenie zabezpieczeń warstwy sieciowej z innymi mechanizmami kontroli zabezpieczeń i nie należy polegać tylko na zaporach lub segmentacji sieci. Jest to 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 zasad sieci w celu kontrolowania ruchu we wschodniej części zachodu. 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.

Host Jednak 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 same są wielodostępne, takie jak aplikacja systemu Azure Service, Azure Functions i Azure Spring Apps. Aby uzyskać więcej informacji, zobacz najlepsze rozwiązanie dotyczące zachowywania nazw hostów.

Upewnij się, że przetestujesz zachowanie aplikacji przy użyciu konfiguracji bramy, która ma być używana.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Inni współautorzy:

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

Następne kroki