Sieć i łączność dla obciążeń o znaczeniu krytycznym na platformie Azure

Sieć jest podstawowym obszarem aplikacji o znaczeniu krytycznym, biorąc pod uwagę zalecane globalnie rozproszone aktywne-aktywne podejście projektowe.

W tym obszarze projektowania przedstawiono różne tematy topologii sieci na poziomie aplikacji, biorąc pod uwagę wymaganą łączność i nadmiarowe zarządzanie ruchem. W szczególności podkreśla krytyczne zagadnienia i zalecenia mające na celu informowanie o projektowaniu bezpiecznej i skalowalnej globalnej topologii sieci dla aplikacji o znaczeniu krytycznym.

Ważne

Ten artykuł jest częścią serii obciążeń o kluczowym znaczeniu dla architektury platformy Azure. Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tego, co to jest obciążenie o znaczeniu krytycznym?

Globalny routing ruchu

Użycie wielu aktywnych sygnatur wdrażania regionalnego wymaga globalnej usługi routingu w celu dystrybucji ruchu do każdej aktywnej sygnatury.

Usługi Azure Front Door, Azure Traffic Manager i Azure usługa Load Balancer w warstwie Standardowa zapewniają wymagane możliwości routingu do zarządzania ruchem globalnym w aplikacji z wieloma regionami.

Alternatywnie można rozważyć technologie routingu globalnego innych firm. Te opcje można niemal bezproblemowo zamienić, aby zastąpić lub rozszerzyć korzystanie z natywnych usług routingu globalnego platformy Azure. Popularne opcje obejmują technologie routingu przez dostawców sieci CDN.

W tej sekcji opisano kluczowe różnice w usługach routingu platformy Azure w celu zdefiniowania sposobu użycia poszczególnych usług do optymalizacji różnych scenariuszy.

Uwagi dotyczące projektowania

• Usługa routingu powiązana z jednym regionem reprezentuje pojedynczy punkt awarii i znaczne ryzyko w odniesieniu do regionalnych awarii.

• Jeśli obciążenie aplikacji obejmuje kontrolę klienta, na przykład w przypadku aplikacji klienckich mobilnych lub klasycznych, możliwe jest zapewnienie nadmiarowości usług w ramach logiki routingu klienta.

  • Wiele globalnych technologii routingu, takich jak Azure Front Door i Azure Traffic Manager, można uznać za równoległe w celu zapewnienia nadmiarowości, z klientami skonfigurowanymi do przełączania w tryb failover do alternatywnej technologii po spełnieniu pewnych warunków awarii. Wprowadzenie wielu globalnych usług routingu wprowadza znaczące złożoności związane z buforowaniem krawędzi i funkcjami zapory aplikacji internetowej oraz zarządzanie certyfikatami na potrzeby odciążania protokołu SSL i walidacji aplikacji dla ścieżek ruchu przychodzącego.
  • Można również rozważyć technologie innych firm, zapewniając globalną odporność routingu na wszystkie poziomy błędów platformy Azure.

• Różnica między możliwościami usługi Azure Front Door i Traffic Manager oznacza, że jeśli obie technologie są rozmieszczone obok siebie w celu zapewnienia nadmiarowości, wymagana byłaby inna ścieżka ruchu przychodzącego lub zmiany projektu w celu zapewnienia spójnego i akceptowalnego poziomu usługi.

• Usługi Azure Front Door i Azure Traffic Manager to globalnie rozproszone usługi z wbudowaną nadmiarowością i dostępnością w wielu regionach.

  • Hipotetyczne scenariusze awarii na dużą skalę, aby zagrozić globalnej dostępności tych odpornych usług routingu, stanowią szersze zagrożenie dla aplikacji pod względem kaskadowych i skorelowanych błędów.
    • Scenariusze awarii tej skali są przyczyną tylko współużytkowanych podstawowych usług, takich jak Azure DNS lub Microsoft Entra ID, które służą jako globalne zależności platformy dla prawie wszystkich usług platformy Azure. Jeśli zastosowano nadmiarową technologię platformy Azure, prawdopodobnie usługa pomocnicza będzie również niedostępna lub obniżona wydajność usługi.
    • Globalne scenariusze awarii usługi routingu są bardzo prawdopodobne, aby znacząco wpłynąć na wiele innych usług używanych w przypadku kluczowych składników aplikacji za pośrednictwem zależności międzyusługowych. Nawet jeśli jest używana technologia innej firmy, aplikacja prawdopodobnie będzie w złej kondycji ze względu na szerszy wpływ problemu, co oznacza, że routing do punktów końcowych aplikacji na platformie Azure zapewnia niewielką wartość.

• Globalna nadmiarowość usługi routingu zapewnia ograniczenie ryzyka dla bardzo małej liczby hipotetycznych scenariuszy awarii, w których wpływ globalnej awarii jest ograniczony do samej usługi routingu.

  Aby zapewnić szerszą nadmiarowość w globalnych scenariuszach awarii, można rozważyć wielochmurowe podejście do wdrażania aktywne-aktywne. Wielochmurowe podejście do wdrażania aktywne-aktywne wprowadza znaczne złożoność operacyjną, co stanowi znaczne ryzyko odporności, prawdopodobnie znacznie przewyższa hipotetyczne ryzyko awarii globalnej.

• W scenariuszach, w których kontrola klienta nie jest możliwa, należy podjąć zależność w jednej globalnej usłudze routingu, aby zapewnić ujednolicony punkt wejścia dla wszystkich aktywnych regionów wdrażania.

  • W przypadku użycia w izolacji reprezentują one pojedynczy punkt awarii na poziomie usługi ze względu na zależności globalne, mimo że zapewniana jest wbudowana nadmiarowość i dostępność w wielu regionach.
  • Umowa SLA zapewniana przez wybraną globalną usługę routingu reprezentuje maksymalną możliwą do osiągnięcia złożoną umowę SLA, niezależnie od liczby regionów wdrażania, które są brane pod uwagę.

• Jeśli kontrola klienta nie jest możliwa, można rozważyć środki zaradcze operacyjne w celu zdefiniowania procesu migracji do pomocniczej globalnej usługi routingu, jeśli globalna awaria wyłączy usługę podstawową. Migracja z jednej globalnej usługi routingu do innej jest zazwyczaj długotrwałym procesem trwającym kilka godzin, szczególnie w przypadku, gdy rozważana jest propagacja DNS.

• Niektóre usługi routingu globalnego innych firm zapewniają umowę SLA w 100%. Jednak historyczna i osiągalna umowa SLA zapewniana przez te usługi jest zazwyczaj niższa niż 100%.

  • Chociaż usługi te zapewniają odszkodowania finansowe za niedostępność, nie ma znaczenia, gdy wpływ niedostępności jest istotny, na przykład w przypadku scenariuszy o znaczeniu krytycznym dla bezpieczeństwa, w których życie ludzkie jest ostatecznie zagrożone. Nadmiarowość technologii lub wystarczające środki zaradcze operacyjne powinny zatem być brane pod uwagę nawet wtedy, gdy reklamowana umowa SLA legalna wynosi 100%.

Azure Front Door

• Usługa Azure Front Door zapewnia globalne równoważenie obciążenia HTTP/S i zoptymalizowaną łączność przy użyciu protokołu Anycast z podzielonym protokołem TCP w celu skorzystania z globalnej sieci szkieletowej firmy Microsoft.

  • Dla każdego z punktów końcowych zaplecza jest utrzymywanych wiele połączeń.
  • Przychodzące żądania klienta są najpierw przerywane w węźle krawędzi znajdującym się najbliżej klienta źródłowego.
  • Po każdej wymaganej inspekcji ruchu żądania są przekazywane przez sieć szkieletową firmy Microsoft do odpowiedniego zaplecza przy użyciu istniejących połączeń lub obsługiwane z wewnętrznej pamięci podręcznej węzła brzegowego.
  • Takie podejście jest wydajne w przypadku rozprzestrzeniania dużych ilości ruchu na połączeniach zaplecza.

• Udostępnia wbudowaną pamięć podręczną, która obsługuje zawartość statyczną z węzłów brzegowych. W wielu przypadkach użycia może to również wyeliminować potrzebę dedykowanej sieci dostarczania zawartości (CDN).

• Zapora aplikacji internetowej platformy Azure może być używana w usłudze Azure Front Door i ponieważ jest wdrażana w lokalizacjach brzegowych sieci platformy Azure na całym świecie, każde przychodzące żądanie dostarczone przez usługę Front Door jest sprawdzane na brzegu sieci.

• Usługa Azure Front Door chroni punkty końcowe aplikacji przed atakami DDoS przy użyciu usługi Azure DDoS Protection w warstwie Podstawowa. Usługa Azure DDoS w warstwie Standardowa oferuje dodatkowe i bardziej zaawansowane funkcje ochrony i wykrywania oraz można je dodać jako dodatkową warstwę do usługi Azure Front Door.

• Usługa Azure Front Door oferuje w pełni zarządzaną usługę certyfikatów. Włącza zabezpieczenia połączeń TLS dla punktów końcowych bez konieczności zarządzania cyklem życia certyfikatu.

• Usługa Azure Front Door Premium obsługuje prywatne punkty końcowe, umożliwiając przepływ ruchu z Internetu bezpośrednio do sieci wirtualnych platformy Azure. Wyeliminowałoby to konieczność używania publicznych adresów IP w sieci wirtualnej do udostępniania zapleczy za pośrednictwem usługi Azure Front Door Premium.

• Usługa Azure Front Door opiera się na sondach kondycji i punktach końcowych kondycji zaplecza (adresach URL), które są wywoływane na podstawie interwału w celu zwrócenia kodu stanu HTTP odzwierciedlającego, czy zaplecze działa normalnie, a odpowiedź HTTP 200 (OK) odzwierciedla stan dobrej kondycji. Gdy tylko zaplecze odzwierciedla stan złej kondycji, z perspektywy określonego węzła brzegowego węzeł brzegowy przestanie wysyłać tam żądania. W złej kondycji zaplecza są zatem niewidocznie usuwane z obiegu ruchu bez opóźnień.

• Obsługuje tylko protokoły HTTP/S.

• Zapora aplikacji internetowej usługi Azure Front Door i zapora aplikacji internetowej usługi Application Gateway udostępniają nieco inny zestaw funkcji, choć obsługują wbudowane i niestandardowe reguły i można je ustawić tak, aby działały w trybie wykrywania lub w trybie zapobiegania.

• Przestrzeń adresów IP zaplecza usługi Front Door może ulec zmianie, ale firma Microsoft zapewni integrację z zakresami adresów IP platformy Azure i tagami usługi. Istnieje możliwość subskrybowania zakresów adresów IP platformy Azure i tagów usługi w celu otrzymywania powiadomień o wszelkich zmianach lub aktualizacjach.

• Usługa Azure Front Door obsługuje różne konfiguracje dystrybucji obciążenia:

  • Oparte na opóźnieniach: ustawienie domyślne, które kieruje ruch do "najbliższego" zaplecza z klienta; na podstawie opóźnienia żądania.
  • Oparte na priorytetach: przydatne w przypadku konfiguracji aktywne-pasywne, gdzie ruch musi być zawsze wysyłany do podstawowego zaplecza, chyba że jest niedostępny.
  • Ważone: dotyczy wdrożeń kanarowych, w których określony procent ruchu jest wysyłany do określonego zaplecza. Jeśli wiele zapleczy ma przypisane te same wagi, jest używany routing oparty na opóźnieniach.

• Domyślnie usługa Azure Front Door używa routingu opartego na opóźnieniach, które mogą prowadzić do sytuacji, w których niektóre zaplecza uzyskują o wiele więcej ruchu przychodzącego niż inne, w zależności od tego, skąd pochodzą klienci.

• Jeśli szereg żądań klientów musi być obsługiwany przez to samo zaplecze, koligacja sesji można skonfigurować na frontonie. Używa pliku cookie po stronie klienta do wysyłania kolejnych żądań do tego samego zaplecza co pierwsze żądanie, pod warunkiem, że zaplecze jest nadal dostępne.

Azure Traffic Manager

• Azure Traffic Manager to usługa przekierowania DNS.

  • Rzeczywisty ładunek żądania nie jest przetwarzany, ale zamiast tego usługa Traffic Manager zwraca nazwę DNS jednego z zapleczy puli na podstawie skonfigurowanych reguł dla wybranej metody routingu ruchu.
  • Nazwa DNS zaplecza jest następnie rozpoznawana jako końcowy adres IP, który jest następnie bezpośrednio wywoływany przez klienta.

• Odpowiedź DNS jest buforowana i ponownie wykorzystywana przez klienta dla określonego okresu czasu wygaśnięcia (TTL), a żądania wysyłane w tym okresie będą kierowane bezpośrednio do punktu końcowego zaplecza bez interakcji z usługą Traffic Manager. Eliminuje dodatkowy krok łączności, który zapewnia korzyści związane z kosztami w porównaniu z usługą Front Door.

• Ponieważ żądanie jest wykonywane bezpośrednio od klienta do usługi zaplecza, można korzystać z dowolnego protokołu obsługiwanego przez zaplecze.

• Podobnie jak w przypadku usługi Azure Front Door, usługa Azure Traffic Manager korzysta również z sond kondycji, aby dowiedzieć się, czy zaplecze jest w dobrej kondycji i działa normalnie. Jeśli zostanie zwrócona inna wartość lub nic nie zostanie zwrócone, usługa routingu rozpozna bieżące problemy i zatrzyma kierowanie żądań do tego konkretnego zaplecza.

  • Jednak w przeciwieństwie do usługi Azure Front Door usunięcie zaplecza w złej kondycji nie jest natychmiastowe, ponieważ klienci będą nadal tworzyć połączenia z zapleczem w złej kondycji, dopóki czas wygaśnięcia dns nie wygaśnie, a nowy punkt końcowy zaplecza zostanie zażądany z usługi Traffic Manager.
  • Ponadto nawet po wygaśnięciu czasu wygaśnięcia nie ma gwarancji, że publiczne serwery DNS będą honorować tę wartość, więc propagacja DNS może trwać znacznie dłużej. Oznacza to, że ruch może być nadal wysyłany do punktu końcowego w złej kondycji przez trwały okres.

Azure usługa Load Balancer w warstwie Standardowa

Ważne

Usługa Load Balancer w warstwie Standardowa między regionami jest dostępna w wersji zapoznawczej z ograniczeniami technicznymi. Ta opcja nie jest zalecana w przypadku obciążeń o znaczeniu krytycznym.

Zalecenia dotyczące projektowania

• Usługa Azure Front Door jest podstawową globalną usługą routingu ruchu dla scenariuszy HTTP/S. Usługa Azure Front Door jest zdecydowanie opowiadana za obciążeniami HTTP/S, ponieważ zapewnia zoptymalizowany routing ruchu, przezroczysty tryb failover, prywatne punkty końcowe zaplecza (z jednostkami SKU Premium), buforowanie brzegowe i integrację z zaporą aplikacji internetowej (WAF).

• W przypadku scenariuszy aplikacji, w których jest możliwa kontrola klienta, zastosuj logikę routingu po stronie klienta, aby rozważyć scenariusze trybu failover, w których podstawowa globalna technologia routingu kończy się niepowodzeniem. Co najmniej dwie globalne technologie routingu powinny być umieszczone równolegle w celu zapewnienia dodatkowej nadmiarowości, jeśli umowa SLA pojedynczej usługi nie jest wystarczająca. Logika klienta jest wymagana do kierowania do nadmiarowej technologii w przypadku awarii usługi globalnej.

  • Należy użyć dwóch odrębnych adresów URL, z jednym zastosowanym do każdej z różnych globalnych usług routingu, aby uprościć ogólne środowisko zarządzania certyfikatami i logikę routingu dla trybu failover.
  • Określanie priorytetów użycia technologii routingu innych firm jako pomocniczej usługi trybu failover, ponieważ ograniczy to największą liczbę globalnych scenariuszy awarii i możliwości oferowanych przez wiodących w branży dostawców usługi CDN umożliwi spójne podejście projektowe.
  • Należy również wziąć pod uwagę bezpośredni routing do pojedynczej sygnatury regionalnej, a nie oddzielnej usługi routingu. Chociaż spowoduje to obniżony poziom usług, reprezentuje znacznie prostsze podejście projektowe.

Ten obraz przedstawia nadmiarową konfigurację globalnego modułu równoważenia obciążenia z trybem failover klienta przy użyciu usługi Azure Front Door jako podstawowego globalnego modułu równoważenia obciążenia.

Ważne

Aby naprawdę ograniczyć ryzyko globalnych awarii na platformie Azure, należy rozważyć wielochmurowe podejście do wdrażania aktywne-aktywne, z aktywnymi sygnaturami wdrażania hostowanymi przez co najmniej dwóch dostawców chmury i nadmiarowymi technologiami routingu innych firm używanymi do routingu globalnego.

Platformę Azure można skutecznie zintegrować z innymi platformami w chmurze. Zdecydowanie zaleca się jednak, aby nie stosować podejścia wielochmurowego, ponieważ wprowadza znaczącą złożoność operacyjną, z różnymi definicjami sygnatur wdrożenia i reprezentacjami kondycji operacyjnej na różnych platformach w chmurze. Ta złożoność z kolei wprowadza wiele zagrożeń odporności w ramach normalnego działania aplikacji, co znacznie przewyższa hipotetyczne ryzyko awarii globalnej platformy.

• Mimo że nie jest to zalecane, w przypadku obciążeń HTTP korzystających z usługi Azure Traffic Manager w celu zapewnienia nadmiarowości routingu globalnego w usłudze Azure Front Door rozważ odciążenie zapory aplikacji internetowej (WAF) do usługi Application Gateway w celu zapewnienia akceptowalnego ruchu przepływającego przez usługę Azure Front Door.
  • Spowoduje to wprowadzenie dodatkowego punktu awarii do standardowej ścieżki ruchu przychodzącego, dodatkowego składnika ścieżki krytycznej do zarządzania i skalowania, a także spowoduje naliczenie dodatkowych kosztów w celu zapewnienia globalnej wysokiej dostępności. Znacznie uprości to jednak scenariusz awarii, zapewniając spójność między akceptowalnymi i nie do przyjęcia ścieżkami ruchu przychodzącego za pośrednictwem usług Azure Front Door i Azure Traffic Manager, zarówno pod względem wykonywania zapory aplikacji internetowej, jak i prywatnych punktów końcowych aplikacji.
  • Utrata buforowania krawędzi w scenariuszu awarii będzie mieć wpływ na ogólną wydajność i musi być zgodna z akceptowalnym poziomem usług lub podejściem ograniczającym projekt. Aby zapewnić spójny poziom usług, rozważ odciążenie buforowania brzegowego do dostawcy usługi CDN innej firmy dla obu ścieżek.

Zaleca się rozważenie globalnej usługi routingu innej firmy zamiast dwóch globalnych usług routingu platformy Azure. Zapewnia to maksymalny poziom ograniczania błędów i bardziej proste podejście projektowe, ponieważ większość wiodących w branży dostawców usługi CDN oferuje możliwości brzegowe w dużej mierze zgodne z tym oferowanym przez usługę Azure Front Door.

Azure Front Door

• Użyj usługi certyfikatu zarządzanego usługi Azure Front Door, aby włączyć połączenia TLS i usunąć konieczność zarządzania cyklami życia certyfikatów.

• Zapora aplikacji internetowej (WAF) usługi Azure Front Door umożliwia ochronę na brzegu sieci Web przed typowymi programami wykorzystującymi luki i lukami w zabezpieczeniach, takimi jak wstrzyknięcie kodu SQL.

• Użyj wbudowanej pamięci podręcznej usługi Azure Front Door, aby obsługiwać zawartość statyczną z węzłów brzegowych.

  • W większości przypadków eliminuje to również potrzebę dedykowanej usługi Content Delivery Network (CDN).

• Skonfiguruj punkty ruchu przychodzącego platformy aplikacji w celu zweryfikowania żądań przychodzących za pomocą filtrowania opartego na nagłówku przy użyciu identyfikatora X-Azure-FDID , aby upewnić się, że cały ruch przepływa przez skonfigurowane wystąpienie usługi Front Door. Rozważ również skonfigurowanie funkcji ACLing adresów IP przy użyciu tagów usługi Front Door w celu zweryfikowania ruchu pochodzącego z przestrzeni adresowej IP zaplecza usługi Azure Front Door i usług infrastruktury platformy Azure. Zapewni to przepływ ruchu przez usługę Azure Front Door na poziomie usługi, ale filtrowanie oparte na nagłówku będzie nadal wymagane w celu zapewnienia użycia skonfigurowanego wystąpienia usługi Front Door.

• Zdefiniuj niestandardowy punkt końcowy kondycji PROTOKOŁU TCP w celu zweryfikowania krytycznych zależności podrzędnych w ramach regionalnej sygnatury wdrożenia, w tym replik platformy danych, takich jak usługa Azure Cosmos DB w przykładzie dostarczonym przez podstawową implementację referencyjną. Jeśli co najmniej jedna zależność stanie się w złej kondycji, sonda kondycji powinna to odzwierciedlić w odpowiedzi zwróconej, aby cała sygnatura regionalna mogła zostać wyjęta z obiegu.

• Upewnij się, że odpowiedzi sondy kondycji są rejestrowane i pozyskiwane wszystkie dane operacyjne uwidocznione przez usługę Azure Front Door w globalnym obszarze roboczym usługi Log Analytics, aby ułatwić ujednolicone ujście danych i pojedynczy widok operacyjny w całej aplikacji.

• O ile obciążenie nie jest bardzo wrażliwe na opóźnienia, równomierne rozłożenie ruchu we wszystkich uznanych sygnaturach regionalnych w celu najbardziej efektywnego używania wdrożonych zasobów.

  • Aby to osiągnąć, ustaw parametr "Opóźnienie poufności (dodatkowe opóźnienie)" na wartość, która jest wystarczająco wysoka, aby zaspokoić różnice opóźnień między różnymi regionami zaplecza. Upewnij się, że tolerancja, która jest akceptowalna dla obciążenia aplikacji w odniesieniu do ogólnego opóźnienia żądań klienta.

• Nie włączaj koligacji sesji, chyba że jest ona wymagana przez aplikację, ponieważ może mieć negatywny wpływ na równowagę rozkładu ruchu. W przypadku w pełni bezstanowej aplikacji, jeśli jest przestrzegane zalecane podejście do projektowania aplikacji o znaczeniu krytycznym, każde żądanie może zostać obsłużone przez dowolne z wdrożeń regionalnych.

Azure Traffic Manager

• Użyj usługi Traffic Manager dla scenariuszy innych niż HTTP/S jako zamiennik usługi Azure Front Door. Różnice w możliwościach będą prowadzić do różnych decyzji projektowych dotyczących możliwości pamięci podręcznej i zapory aplikacji internetowej oraz zarządzania certyfikatami TLS.

• Możliwości zapory aplikacji internetowej należy wziąć pod uwagę w każdym regionie dla ścieżki ruchu przychodzącego usługi Traffic Manager przy użyciu bramy aplikacja systemu Azure.

• Skonfiguruj odpowiednio niską wartość czasu wygaśnięcia, aby zoptymalizować czas wymagany do usunięcia punktu końcowego zaplecza w złej kondycji z obiegu w przypadku, gdy zaplecze stanie się w złej kondycji.

• Podobnie jak w przypadku usługi Azure Front Door, należy zdefiniować niestandardowy punkt końcowy kondycji TCP w celu zweryfikowania krytycznych zależności podrzędnych w ramach regionalnej sygnatury wdrożenia, która powinna zostać odzwierciedlona w odpowiedzi dostarczonej przez punkty końcowe kondycji.

  Jednak w przypadku usługi Traffic Manager należy wziąć pod uwagę dodatkowe zagadnienia dotyczące regionalnego przełączania w tryb failover na poziomie usługi. takich jak "legging psa", aby zminimalizować potencjalne opóźnienie związane z usunięciem zaplecza w złej kondycji z powodu błędów zależności, szczególnie jeśli nie jest możliwe ustawienie niskiego czasu wygaśnięcia dla rekordów DNS.

• Należy wziąć pod uwagę dostawców sieci CDN innych firm w celu osiągnięcia buforowania brzegowego w przypadku korzystania z usługi Azure Traffic Manager jako podstawowej globalnej usługi routingu. W przypadku, gdy funkcje zapory aplikacji internetowej brzegowej są również oferowane przez usługę innej firmy, należy rozważyć uproszczenie ścieżki ruchu przychodzącego i potencjalnie usunięcie potrzeby usługi Application Gateway.

Usługi dostarczania aplikacji

Ścieżka ruchu przychodzącego sieci dla aplikacji o znaczeniu krytycznym musi również uwzględniać usługi dostarczania aplikacji, aby zapewnić bezpieczny, niezawodny i skalowalny ruch przychodzący.

Ta sekcja opiera się na globalnych zaleceniach dotyczących routingu, eksplorując kluczowe możliwości dostarczania aplikacji, biorąc pod uwagę odpowiednie usługi, takie jak Azure usługa Load Balancer w warstwie Standardowa, aplikacja systemu Azure Gateway i Azure API Management.

Uwagi dotyczące projektowania

• Szyfrowanie TLS ma kluczowe znaczenie dla zapewnienia integralności ruchu przychodzącego użytkownika do aplikacji o znaczeniu krytycznym, a odciążanie protokołu TLS jest stosowane tylko w punkcie ruchu przychodzącego sygnatury w celu odszyfrowania ruchu przychodzącego. Odciążanie protokołu TLS wymaga klucza prywatnego certyfikatu TLS do odszyfrowania ruchu.

• Zapora aplikacji internetowej zapewnia ochronę przed typowymi programami wykorzystującymi luki w zabezpieczeniach i lukami w zabezpieczeniach, takimi jak wstrzyknięcie kodu SQL lub wykonywanie skryptów między witrynami, i jest niezbędne do osiągnięcia maksymalnych aspiracji dotyczących niezawodności aplikacji o kluczowym znaczeniu.

• Zapora aplikacji internetowej platformy Azure zapewnia wbudowaną ochronę przed 10 najlepszymi lukami w zabezpieczeniach OWASP przy użyciu zarządzanych zestawów reguł.

  • Reguły niestandardowe można również dodać w celu rozszerzenia zarządzanego zestawu reguł.
  • Zapora aplikacji internetowej platformy Azure może być włączona w usłudze Azure Front Door, aplikacja systemu Azure Gateway lub Azure CDN (obecnie w publicznej wersji zapoznawczej).
    • Funkcje oferowane w poszczególnych usługach różnią się nieco. Na przykład zapora aplikacji internetowej usługi Azure Front Door zapewnia ograniczanie szybkości, filtrowanie geograficzne i ochronę botów, które nie są jeszcze oferowane w zaporze aplikacji internetowej usługi Application Gateway. Wszystkie one obsługują jednak zarówno wbudowane, jak i niestandardowe reguły i można je ustawić tak, aby działały w trybie wykrywania lub trybie zapobiegania.
    • Plan zapory aplikacji internetowej platformy Azure zapewni spójny zestaw funkcji zapory aplikacji internetowej we wszystkich integracjach usług.

• Technologie zapory aplikacji internetowej innych firm, takie jak urządzenia WUS i zaawansowane kontrolery ruchu przychodzącego w ramach platformy Kubernetes, mogą być również brane pod uwagę w celu zapewnienia wymaganej ochrony przed lukami w zabezpieczeniach.

• Optymalna konfiguracja zapory aplikacji internetowej zwykle wymaga precyzyjnego dostrajania, niezależnie od używanej technologii.

  Azure Front Door

• Usługa Azure Front Door akceptuje tylko ruch HTTP i HTTPS i będzie przetwarzać żądania tylko ze znanym Host nagłówkiem. To blokowanie protokołu pomaga ograniczyć rozprzestrzenianie się ataków wolumetrycznych między protokołami i portami, a także wzmacnianie systemu DNS i ataki zatruwania TCP.

• Usługa Azure Front Door to globalny zasób platformy Azure, więc konfiguracja jest wdrażana globalnie we wszystkich lokalizacjach brzegowych.

  • Konfigurację zasobów można dystrybuować na dużą skalę, aby obsługiwać setki tysięcy żądań na sekundę.
  • Aktualizacje do konfiguracji, w tym tras i pul zaplecza, są bezproblemowe i nie spowodują żadnych przestojów podczas wdrażania.

• Usługa Azure Front Door udostępnia zarówno w pełni zarządzaną usługę certyfikatów, jak i metodę "bring-your-own-certificate" dla certyfikatów SSL przeznaczonych dla klienta. Usługa w pełni zarządzanego certyfikatu zapewnia uproszczone podejście operacyjne i pomaga zmniejszyć złożoność całego projektu, wykonując zarządzanie certyfikatami w jednym obszarze rozwiązania.

• Usługa Azure Front Door automatycznie obraca "zarządzane" certyfikaty co najmniej 60 dni przed wygaśnięciem certyfikatu w celu ochrony przed wygasłym ryzykiem certyfikatu. Jeśli są używane certyfikaty zarządzane samodzielnie, zaktualizowane certyfikaty powinny być wdrażane nie później niż 24 godziny przed wygaśnięciem istniejącego certyfikatu, w przeciwnym razie klienci mogą otrzymywać wygasłe błędy certyfikatu.

• Aktualizacje certyfikatów spowodują tylko przestój, jeśli usługa Azure Front Door zostanie przełączona między "Zarządzany" i "Użyj własnego certyfikatu".

• Usługa Azure Front Door jest domyślnie chroniona przez usługę Azure DDoS Protection w warstwie Podstawowa, która jest domyślnie zintegrowana z usługą Front Door. Zapewnia to zawsze włączone monitorowanie ruchu, ograniczanie ryzyka w czasie rzeczywistym, a także chroni przed typowymi powodziami zapytań DNS warstwy 7 lub atakami w warstwie 3/4 wolumetrycznymi.

  • Te zabezpieczenia pomagają zachować dostępność usługi Azure Front Door nawet w przypadku ataku DDoS. Ataki typu "rozproszona odmowa usługi" (DDoS) mogą spowodować niedostępność docelowego zasobu przez przeciążanie go nielegalnym ruchem.

• Usługa Azure Front Door udostępnia również funkcje zapory aplikacji internetowej na poziomie ruchu globalnego, a zapora aplikacji internetowej usługi Application Gateway musi być udostępniana w ramach każdej regionalnej sygnatury wdrożenia. Możliwości obejmują zestawy reguł zapory w celu ochrony przed typowymi atakami, filtrowaniem geograficznym, blokowaniem adresów, ograniczaniem szybkości i dopasowywaniem podpisów.

  Azure Load Balancer

• Jednostka SKU usługi Azure Load Balancer w warstwie Podstawowa nie jest wspierana przez umowę SLA i ma kilka ograniczeń możliwości w porównaniu do jednostki SKU w warstwie Standardowa.

Zalecenia dotyczące projektowania

• Przeprowadź odciążanie protokołu TLS w możliwie najkrótszym miejscu, aby zachować bezpieczeństwo przy jednoczesnym uproszczeniu cyklu życia zarządzania certyfikatami.

• Użyj szyfrowanych połączeń (np. HTTPS) z punktu, w którym następuje odciążanie protokołu TLS do rzeczywistych zapleczy aplikacji. Punkty końcowe aplikacji nie będą widoczne dla użytkowników końcowych, więc domeny zarządzane przez platformę Azure, takie jak azurewebsites.net lub cloudapp.net, mogą być używane z certyfikatami zarządzanymi.

• W przypadku ruchu HTTP(S) upewnij się, że funkcje zapory aplikacji internetowej są stosowane w ścieżce ruchu przychodzącego dla wszystkich publicznie uwidocznionych punktów końcowych.

• Włącz funkcje zapory aplikacji internetowej w jednej lokalizacji usługi, globalnie z usługą Azure Front Door lub regionalnie z usługą aplikacja systemu Azure Gateway, ponieważ upraszcza to dostosowywanie konfiguracji i optymalizuje wydajność i koszty.

  Skonfiguruj zaporę aplikacji internetowej w trybie zapobiegania, aby bezpośrednio blokować ataki. Używaj zapory aplikacji internetowej tylko w trybie wykrywania (tj. rejestrowania, ale nie blokowania podejrzanych żądań), gdy kara za wydajność trybu zapobiegania jest zbyt wysoka. Implikowane dodatkowe ryzyko musi być w pełni zrozumiałe i dostosowane do konkretnych wymagań scenariusza obciążenia.

• Określanie priorytetów użycia zapory aplikacji internetowej usługi Azure Front Door, ponieważ zapewnia ona najbogatszy zestaw funkcji natywnych dla platformy Azure i stosuje zabezpieczenia na brzegu globalnym, co upraszcza ogólny projekt i zwiększa wydajność.

• Usługa Azure API Management jest używana tylko w przypadku uwidaczniania dużej liczby interfejsów API klientom zewnętrznym lub innym zespołom aplikacji.

• Użyj jednostki SKU usługi Azure usługa Load Balancer w warstwie Standardowa dla dowolnego scenariusza dystrybucji ruchu wewnętrznego w ramach obciążeń mikrosusługowych.

  • Zapewnia umowę SLA na 99,99% podczas wdrażania w Strefy dostępności.
  • Zapewnia krytyczne możliwości, takie jak diagnostyka lub reguły ruchu wychodzącego.

• Użyj usługi Azure DDoS Network Protection, aby ułatwić ochronę publicznych punktów końcowych hostowanych w każdej sieci wirtualnej aplikacji.

Buforowanie i dostarczanie zawartości statycznej

Specjalne traktowanie zawartości statycznej, takiej jak obrazy, JavaScript, CSS i inne pliki, może mieć znaczący wpływ na ogólne środowisko użytkownika, a także ogólny koszt rozwiązania. Buforowanie zawartość statyczną na brzegu sieci może przyspieszyć czas ładowania klienta, co skutkuje lepszym środowiskiem użytkownika, a także zmniejszyć koszty ruchu, operacji odczytu i mocy obliczeniowej w zaangażowanych usługach zaplecza.

Uwagi dotyczące projektowania

• Nie cała zawartość udostępniana przez Internet jest generowana dynamicznie. Aplikacje obsługują zarówno zasoby statyczne (obrazy, JavaScript, CSS, pliki lokalizacji itp.) i zawartość dynamiczną.
• Obciążenia z często używanymi zawartościami statycznymi znacznie korzystają z buforowania, ponieważ zmniejsza obciążenie usług zaplecza i zmniejsza opóźnienie dostępu do zawartości dla użytkowników końcowych.
• Buforowanie można zaimplementować natywnie na platformie Azure przy użyciu usługi Azure Front Door lub Azure Content Delivery Network (CDN).
  • Usługa Azure Front Door udostępnia natywne funkcje buforowania brzegowego platformy Azure i funkcje routingu, aby podzielić zawartość statyczną i dynamiczną.
    • Tworząc odpowiednie reguły routingu w usłudze Azure Front Door, /static/* ruch może być niewidocznie przekierowywany do zawartości statycznej.
  • Bardziej złożone scenariusze buforowania można zaimplementować przy użyciu usługi Azure CDN w celu ustanowienia w pełni funkcjonalnej sieci dostarczania zawartości dla znaczących woluminów zawartości statycznej.
    • Usługa Azure CDN będzie prawdopodobnie bardziej opłacalna, ale nie zapewnia tych samych zaawansowanych funkcji routingu i zapory aplikacji internetowej (WAF), które są zalecane w przypadku innych obszarów projektowania aplikacji. Zapewnia jednak dalszą elastyczność integracji z podobnymi usługami z rozwiązań innych firm, takich jak Akamai i Verizon.
  • Podczas porównywania usług Azure Front Door i Azure CDN należy zbadać następujące czynniki decyzyjne:
    • Można wykonać wymagane reguły buforowania przy użyciu aparatu reguł.
    • Rozmiar przechowywanej zawartości i skojarzony koszt.
    • Cena miesięcznie za wykonanie aparatu reguł (opłata za żądanie w usłudze Azure Front Door).
    • Wymagania dotyczące ruchu wychodzącego (cena różni się od miejsca docelowego).

Zalecenia dotyczące projektowania

• Generowana zawartość statyczna, taka jak rozmiary kopii plików obrazów, które nigdy lub rzadko się zmieniają, mogą również korzystać z buforowania. Buforowanie można skonfigurować na podstawie parametrów adresu URL i o różnym czasie trwania buforowania.
• Oddzielenie dostarczania zawartości statycznej i dynamicznej do użytkowników i dostarczanie odpowiedniej zawartości z pamięci podręcznej w celu zmniejszenia obciążenia usług zaplecza optymalizują wydajność dla użytkowników końcowych.
• Biorąc pod uwagę silne zalecenie (obszar projektowania sieci i łączności ) do korzystania z usługi Azure Front Door na potrzeby routingu globalnego i zapory aplikacji internetowej (WAF), zaleca się nadanie priorytetowi korzystania z funkcji buforowania usługi Azure Front Door, chyba że istnieją luki.

Integracja sieci wirtualnej

Aplikacja o znaczeniu krytycznym zwykle obejmuje wymagania dotyczące integracji z innymi aplikacjami lub systemami zależnymi, które mogą być hostowane na platformie Azure, w innej chmurze publicznej lub lokalnych centrach danych. Tę integrację aplikacji można przeprowadzić przy użyciu publicznych punktów końcowych i Internetu lub sieci prywatnych za pośrednictwem integracji na poziomie sieci. Ostatecznie metoda, za pomocą której można osiągnąć integrację aplikacji, będzie miała znaczący wpływ na bezpieczeństwo, wydajność i niezawodność rozwiązania oraz zdecydowanie wpływa na decyzje projektowe w innych obszarach projektowania.

Aplikację o krytycznym znaczeniu można wdrożyć w ramach jednej z trzech nadrzędnych konfiguracji sieci, co określa, jak można przeprowadzić integrację aplikacji na poziomie sieci.

1. Aplikacja publiczna bez łączności z siecią firmową.
2. Aplikacja publiczna z łącznością sieciową firmową.
3. Aplikacja prywatna z łącznością sieciową firmową.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure konfiguracja 1. należy wdrożyć w strefie docelowej online, natomiast zarówno 2) jak i 3) należy wdrożyć w obrębie domeny corp. Połączenie ed Landing Zone w celu ułatwienia integracji na poziomie sieci.

W tej sekcji opisano te scenariusze integracji sieci, warstwy w odpowiednim wykorzystaniu sieci wirtualnych platformy Azure i otaczających usług sieciowych platformy Azure w celu zapewnienia optymalnego spełnienia wymagań dotyczących integracji.

Zagadnienia dotyczące projektowania

Brak sieci wirtualnych

• Najprostszym podejściem projektowym jest nie wdrożenie aplikacji w sieci wirtualnej.

  • Połączenie ivity między wszystkimi uznanymi usługami platformy Azure zostaną udostępnione całkowicie za pośrednictwem publicznych punktów końcowych i sieci szkieletowej platformy Microsoft Azure. Połączenie ivity między publicznymi punktami końcowymi hostowanymi na platformie Azure będzie przechodzić tylko przez sieć szkieletową firmy Microsoft i nie będzie przechodzić przez publiczny Internet.
  • Połączenie ivity do wszystkich systemów zewnętrznych spoza platformy Azure będzie zapewniany przez publiczny Internet.

• Takie podejście projektowe stosuje "tożsamość jako obwód zabezpieczeń", aby zapewnić kontrolę dostępu między różnymi składnikami usługi i rozwiązaniem zależnym. Może to być akceptowalne rozwiązanie dla scenariuszy, które są mniej wrażliwe na zabezpieczenia. Wszystkie usługi aplikacji i zależności są dostępne za pośrednictwem publicznego punktu końcowego, co pozostawia je podatne na dodatkowe wektory ataków zorientowane na uzyskanie nieautoryzowanego dostępu.

• Takie podejście projektowe nie dotyczy również wszystkich usług platformy Azure, ponieważ wiele usług, takich jak usługa AKS, ma twarde wymaganie dla podstawowej sieci wirtualnej.

Izolowane sieci wirtualne

• Aby ograniczyć ryzyko związane z niepotrzebnymi publicznymi punktami końcowymi, aplikację można wdrożyć w autonomicznej sieci, która nie jest połączona z innymi sieciami.

• Przychodzące żądania klientów nadal wymagają publicznego punktu końcowego, aby był uwidoczniony w Internecie, jednak wszystkie kolejne połączenia mogą znajdować się w sieci wirtualnej przy użyciu prywatnych punktów końcowych. W przypadku korzystania z usługi Azure Front Door Premium można kierować bezpośrednio z węzłów brzegowych do prywatnych punktów końcowych aplikacji.

• Podczas gdy prywatna łączność między składnikami aplikacji będzie odbywać się za pośrednictwem sieci wirtualnych, wszystkie połączenia z zależnościami zewnętrznymi nadal będą polegać na publicznych punktach końcowych.

  • Połączenie ivity do usług platformy Azure można ustanowić z prywatnymi punktami końcowymi, jeśli są obsługiwane. Jeśli istnieją inne zależności zewnętrzne na platformie Azure, takie jak inna aplikacja podrzędna, łączność będzie dostarczana za pośrednictwem publicznych punktów końcowych i sieci szkieletowej platformy Microsoft Azure.
  • Połączenie do wszystkich systemów zewnętrznych spoza platformy Azure byłyby udostępniane przez publiczny Internet.

• W przypadku scenariuszy, w których nie ma wymagań dotyczących integracji sieci dla zależności zewnętrznych, wdrożenie rozwiązania w izolowanym środowisku sieciowym zapewnia maksymalną elastyczność projektowania. Brak ograniczeń adresowania i routingu skojarzonych z szerszą integracją sieci.

• Azure Bastion to w pełni zarządzana przez platformę usługa PaaS, którą można wdrożyć w sieci wirtualnej i zapewnia bezpieczną łączność RDP/SSH z maszynami wirtualnymi platformy Azure. Podczas nawiązywania połączenia za pośrednictwem usługi Azure Bastion maszyny wirtualne nie potrzebują publicznego adresu IP.

• Korzystanie z sieci wirtualnych aplikacji wprowadza znaczne złożoność wdrażania w potokach ciągłej integracji/ciągłego wdrażania, ponieważ zarówno płaszczyzna danych, jak i dostęp płaszczyzny sterowania do zasobów hostowanych w sieciach prywatnych jest wymagany do ułatwienia wdrożeń aplikacji.

  • Należy ustanowić bezpieczną ścieżkę sieci prywatnej, aby umożliwić narzędziom ciągłej integracji/ciągłego wdrażania wykonywanie wymaganych akcji.
  • Prywatni agenci kompilacji mogą być wdrażani w sieciach wirtualnych aplikacji, aby uzyskać dostęp serwera proxy do zasobów zabezpieczonych przez sieć wirtualną.

Połączenie sieci wirtualne

• W scenariuszach z wymaganiami dotyczącymi integracji z siecią zewnętrzną sieci wirtualne mogą być połączone z innymi sieciami wirtualnymi na platformie Azure, u innego dostawcy usług w chmurze lub sieciami lokalnymi przy użyciu różnych opcji łączności. Na przykład niektóre scenariusze aplikacji mogą rozważyć integrację na poziomie aplikacji z innymi aplikacjami biznesowymi hostowanymi prywatnie w lokalnej sieci firmowej.

• Projekt sieci aplikacji musi być zgodny z szerszą architekturą sieci, szczególnie dotyczącymi tematów, takich jak adresowanie i routing.

• Nakładające się przestrzenie adresów IP w różnych regionach platformy Azure lub sieciach lokalnych spowodują powstanie głównej rywalizacji po rozważeniu integracji sieci.

  • Zasób sieci wirtualnej można zaktualizować w celu rozważenia dodatkowej przestrzeni adresowej, jednak gdy przestrzeń adresowa sieci wirtualnej równorzędnej zmieni synchronizację łącza komunikacji równorzędnej, co tymczasowo wyłączy komunikację równorzędną.
  • Platforma Azure rezerwuje pięć adresów IP w każdej podsieci, które należy wziąć pod uwagę podczas określania odpowiednich rozmiarów sieci wirtualnych aplikacji i uwzględnionych podsieci.
  • Niektóre usługi platformy Azure wymagają dedykowanych podsieci, takich jak Azure Bastion, Azure Firewall lub Azure Virtual Network Gateway. Rozmiar tych podsieci usług jest bardzo ważny, ponieważ powinny być wystarczająco duże, aby obsługiwać wszystkie bieżące wystąpienia usługi, biorąc pod uwagę przyszłe wymagania dotyczące skalowania, ale nie tak duże, aby niepotrzebnie marnować adresy.

• Gdy wymagana jest integracja sieci lokalnej lub między chmurami, platforma Azure oferuje dwa różne rozwiązania umożliwiające nawiązanie bezpiecznego połączenia.

  • Obwód usługi ExpressRoute może mieć rozmiar, aby zapewnić przepustowość do 100 Gb/s.
  • Rozmiar wirtualnej sieci prywatnej (VPN) może zapewnić zagregowaną przepustowość do 10 Gb/s w sieciach piasty i szprych oraz maksymalnie 20 Gb/s w usłudze Azure Virtual WAN.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure należy pamiętać, że każda wymagana łączność z sieciami lokalnymi powinna być zapewniana przez implementację strefy docelowej. Projekt może używać usługi ExpressRoute i innych sieci wirtualnych na platformie Azure przy użyciu wirtualnej sieci WAN lub sieci piasty i szprych.

• Włączenie dodatkowych ścieżek sieciowych i zasobów wprowadza dodatkowe zagadnienia dotyczące niezawodności i działania aplikacji w celu zapewnienia utrzymania kondycji.

Zalecenia dotyczące projektowania

• Zalecane jest, aby rozwiązania o znaczeniu krytycznym zostały wdrożone w sieciach wirtualnych platformy Azure, jeśli to możliwe, aby usunąć niepotrzebne publiczne punkty końcowe, ograniczając obszar ataków aplikacji w celu zmaksymalizowania bezpieczeństwa i niezawodności.

  • Używanie prywatnych punktów końcowych do łączności z usługami platformy Azure. Punkty końcowe usługi można rozważyć w przypadku usług, które obsługują usługę Private Link, pod warunkiem, że ryzyko eksfiltracji danych jest akceptowalne lub ograniczane za pomocą alternatywnych mechanizmów kontroli.

• W przypadku scenariuszy aplikacji, które nie wymagają łączności z siecią firmową, należy traktować wszystkie sieci wirtualne jako efemeryczne zasoby, które są zastępowane po przeprowadzeniu nowego wdrożenia regionalnego.

• Podczas nawiązywania połączenia z innymi sieciami platformy Azure lub sieciami lokalnymi sieci wirtualne aplikacji nie powinny być traktowane jako efemeryczne, ponieważ powoduje to znaczne komplikacje, gdy dotyczy to komunikacji równorzędnej sieci wirtualnych i zasobów bramy sieci wirtualnej. Wszystkie odpowiednie zasoby aplikacji w sieci wirtualnej powinny być nadal efemeryczne, a równoległe podsieci używane do ułatwiania niebieskich zielonych wdrożeń zaktualizowanych regionalnych sygnatur wdrażania.

• W scenariuszach, w których łączność sieci firmowa jest wymagana w celu ułatwienia integracji aplikacji za pośrednictwem sieci prywatnych, upewnij się, że przestrzeń adresowa IPv4 używana w sieciach wirtualnych aplikacji regionalnych nie nakłada się na inne połączone sieci i ma prawidłowy rozmiar, aby ułatwić wymaganą skalę bez konieczności aktualizowania zasobu sieci wirtualnej i ponoszenia przestojów.

  • Zdecydowanie zaleca się używanie tylko adresów IP z alokacji adresów dla prywatnego Internetu (RFC 1918).
    • W przypadku środowisk z ograniczoną dostępnością prywatnych adresów IP (RFC 1918) rozważ użycie protokołu IPv6.
    • Jeśli wymagane jest użycie publicznego adresu IP, upewnij się, że są używane tylko bloki adresów należących do firmy.
  • Dopasuj plany organizacji dotyczące adresowania IP na platformie Azure, aby zapewnić, że przestrzeń adresów IP sieci aplikacji nie nakłada się na inne sieci w lokalizacjach lokalnych lub regionach świadczenia usługi Azure.
  • Nie twórz niepotrzebnie dużych sieci wirtualnych aplikacji, aby upewnić się, że przestrzeń adresowa IP nie jest marnowana.

• Określanie priorytetów użycia usługi Azure CNI na potrzeby integracji sieci usługi AKS, ponieważ obsługuje ona bogatszy zestaw funkcji.

  • Rozważ rozwiązanie Kubenet w scenariuszach z ograniczonymi dostępnymi adresami IP, aby dopasować aplikację do ograniczonej przestrzeni adresowej.

  • Określanie priorytetów użycia wtyczki sieciowej usługi Azure CNI na potrzeby integracji sieci usługi AKS i rozważ użycie rozwiązania Kubenet w scenariuszach z ograniczonym zakresem dostępnych adresów IP. Aby uzyskać więcej informacji, zobacz Zasady sieci mikrosegmentacji i platformy Kubernetes.

• W przypadku scenariuszy wymagających integracji z siecią lokalną należy określić priorytety użycia usługi Express Route w celu zapewnienia bezpiecznej i skalowalnej łączności.

  • Upewnij się, że poziom niezawodności zastosowany do usługi Express Route lub sieci VPN w pełni spełnia wymagania aplikacji.
  • Należy wziąć pod uwagę wiele ścieżek sieciowych w celu zapewnienia dodatkowej nadmiarowości, jeśli jest to wymagane, takich jak połączone obwody usługi ExpressRoute lub użycie sieci VPN jako mechanizmu łączności trybu failover.

• Upewnij się, że wszystkie składniki na krytycznych ścieżkach sieciowych są zgodne z wymaganiami dotyczącymi niezawodności i dostępności skojarzonych przepływów użytkowników, niezależnie od tego, czy zarządzanie tymi ścieżkami i skojarzonym składnikiem jest dostarczane przez zespół aplikacji centralnych zespołów IT.

  Uwaga

  Podczas wdrażania w strefie docelowej platformy Azure i integracji z szerszą topologią sieci organizacji należy wziąć pod uwagę wskazówki dotyczące sieci, aby upewnić się, że podstawowa sieć jest zgodna z najlepszymi rozwiązaniami firmy Microsoft.

• Użyj usługi Azure Bastion lub proxied prywatnych połączeń, aby uzyskać dostęp do płaszczyzny danych zasobów platformy Azure lub wykonywać operacje zarządzania.

Internetowy ruch wychodzący

Ruch wychodzący z Internetu jest podstawowym wymaganiem sieciowym aplikacji o znaczeniu krytycznym w celu ułatwienia komunikacji zewnętrznej w kontekście:

1. Bezpośrednia interakcja użytkownika aplikacji.
2. Integracja aplikacji z zależnościami zewnętrznymi poza platformą Azure.
3. Dostęp do zależności zewnętrznych wymaganych przez usługi platformy Azure używane przez aplikację.

W tej sekcji opisano, jak można osiągnąć ruch wychodzący z Internetu przy jednoczesnym zapewnieniu utrzymania bezpieczeństwa, niezawodności i zrównoważonej wydajności, podkreślając kluczowe wymagania dotyczące ruchu wychodzącego dla usług zalecanych w kontekście o znaczeniu krytycznym.

Zagadnienia dotyczące projektowania

• Wiele usług platformy Azure wymaga dostępu do publicznych punktów końcowych, aby różne funkcje płaszczyzny zarządzania i sterowania działały zgodnie z oczekiwaniami.

• Platforma Azure udostępnia różne metody bezpośredniej łączności wychodzącej z Internetu, takie jak brama translatora adresów sieciowych platformy Azure lub usługa Azure Load Balancer, dla maszyn wirtualnych lub wystąpień obliczeniowych w sieci wirtualnej.

• Gdy ruch z wewnątrz sieci wirtualnej przemieszcza się do Internetu, musi nastąpić translacja adresów sieciowych (NAT). Jest to operacja obliczeniowa wykonywana w stosie sieciowym, która może mieć wpływ na wydajność systemu.

• Jeśli translator adresów sieciowych odbywa się na małą skalę, wpływ na wydajność powinien być niewielki, jednak w przypadku wystąpienia dużej liczby żądań wychodzących mogą wystąpić problemy z siecią. Te problemy zwykle występują w postaci wyczerpania portów translatora adresów sieciowych (lub SNAT).

• W środowisku wielodostępnym, takim jak usługa aplikacja systemu Azure, istnieje ograniczona liczba portów wychodzących dostępnych dla każdego wystąpienia. Jeśli te porty nie zostaną uruchomione, nie można zainicjować nowych połączeń wychodzących. Ten problem można rozwiązać, zmniejszając liczbę przechodzenia przez sieć prywatną/publiczną lub korzystając z bardziej skalowalnego rozwiązania NAT, takiego jak brama translatora adresów sieciowych platformy Azure.

• Oprócz ograniczeń translatora adresów sieciowych ruch wychodzący może również podlegać wymaganym inspekcjom zabezpieczeń.

  • Usługa Azure Firewall zapewnia odpowiednie możliwości zabezpieczeń w celu zabezpieczenia ruchu wychodzącego sieci.

  • Za pomocą usługi Azure Firewall (lub równoważnego urządzenia WUS) można zabezpieczyć wymagania dotyczące ruchu wychodzącego kubernetes, zapewniając szczegółową kontrolę nad przepływami ruchu wychodzącego.

• Duże ilości ruchu wychodzącego z Internetu będą naliczać opłaty za transfer danych.

Brama translatora adresów sieciowych platformy Azure

• Usługa Azure NAT Gateway obsługuje 64 000 połączeń dla protokołów TCP i UDP na przypisany wychodzący adres IP.

  • Do jednej bramy translatora adresów sieciowych można przypisać maksymalnie 16 adresów IP.
  • Domyślny limit czasu bezczynności protokołu TCP to 4 minuty. Jeśli limit czasu bezczynności zostanie zmieniony na wyższą wartość, przepływy będą przechowywane dłużej, co zwiększy presję na spis portów SNAT.

• Brama translatora adresów sieciowych nie może zapewnić gotowej izolacji strefowej. Aby uzyskać nadmiarowość strefową, podsieć zawierająca zasoby strefowe musi być wyrównana do odpowiednich strefowych bram translatora adresów sieciowych.

Zalecenia dotyczące projektowania

• Zminimalizuj liczbę wychodzących połączeń internetowych, ponieważ będzie to miało wpływ na wydajność translatora adresów sieciowych.

  • Jeśli wymagana jest duża liczba połączeń powiązanych z Internetem, rozważ użycie bramy translatora adresów sieciowych platformy Azure do wyodrębnienia przepływów ruchu wychodzącego.

• Użyj usługi Azure Firewall, gdzie istnieją wymagania dotyczące kontrolowania i sprawdzania ruchu wychodzącego z Internetu.

  • Upewnij się, że usługa Azure Firewall nie jest używana do sprawdzania ruchu między usługami platformy Azure.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure rozważ użycie podstawowego zasobu usługi Azure Firewall (lub równoważnego urządzenia WUS). Jeśli zależność zostanie podjęta na centralnym zasobie platformy dla ruchu wychodzącego z Internetu, poziom niezawodności tego zasobu i skojarzonej ścieżki sieciowej powinien być ściśle zgodny z wymaganiami aplikacji. Dane operacyjne z zasobu powinny być również udostępniane aplikacji w celu informowania o potencjalnych działaniach operacyjnych w scenariuszach awarii.

Jeśli istnieją wymagania o dużej skali związane z ruchem wychodzącym, należy wziąć pod uwagę dedykowany zasób usługi Azure Firewall dla aplikacji o krytycznym znaczeniu, aby ograniczyć ryzyko związane z używaniem centralnie współużytkowanego zasobu, takiego jak hałaśliwe scenariusze sąsiadów.

• Podczas wdrażania w środowisku usługi Virtual WAN należy wziąć pod uwagę menedżera zapory, aby zapewnić scentralizowane zarządzanie wystąpieniami dedykowanej aplikacji usługi Azure Firewall w celu zapewnienia, że stan zabezpieczeń organizacji jest obserwowany za pośrednictwem globalnych zasad zapory.
• Upewnij się, że przyrostowe zasady zapory są delegowane do zespołów ds. zabezpieczeń aplikacji za pośrednictwem kontroli dostępu opartej na rolach, aby zapewnić autonomię zasad aplikacji.

Połączenie ivity między strefami i między regionami

Chociaż projekt aplikacji zdecydowanie opowiada się za niezależnymi regionalnymi sygnaturami wdrażania, wiele scenariuszy aplikacji może nadal wymagać integracji sieci między składnikami aplikacji wdrożonych w różnych strefach lub regionach platformy Azure, nawet jeśli tylko w warunkach obniżonej wydajności usługi. Metoda, za pomocą której osiągana jest komunikacja między strefami i między regionami, ma znaczący wpływ na ogólną wydajność i niezawodność, które zostaną zbadane w ramach zagadnień i zaleceń w tej sekcji.

Zagadnienia dotyczące projektowania

• Podejście projektowe aplikacji dla aplikacji o znaczeniu krytycznym popiera użycie niezależnych wdrożeń regionalnych z nadmiarowością strefową stosowaną na wszystkich poziomach składników w jednym regionie.

• Strefa dostępności (AZ) to fizycznie oddzielna lokalizacja centrum danych w regionie świadczenia usługi Azure, zapewniając izolację błędów fizycznych i logicznych do poziomu pojedynczego centrum danych.

  W przypadku komunikacji między strefami gwarantowane jest opóźnienie rundy mniejsze niż 2 ms. Strefy będą miały niewielką wariancję opóźnienia, biorąc pod uwagę różne odległości i ścieżki światłowodowe między strefami.

• Łączność w strefie dostępności zależy od cech regionalnych, dlatego ruch wjeżdżający do regionu za pośrednictwem lokalizacji brzegowej może wymagać kierowania między strefami w celu dotarcia do miejsca docelowego. Spowoduje to dodanie opóźnienia ~1ms-2ms w przypadku routingu między strefami i ograniczeń "prędkości światła", ale powinno to mieć tylko łożysko dla obciążeń hiperwrażliwych.

• Strefy dostępności są traktowane jako jednostki logiczne w kontekście pojedynczej subskrypcji, więc różne subskrypcje mogą mieć inne mapowanie strefowe dla tego samego regionu. Na przykład strefa 1 w subskrypcji A może odpowiadać temu samemu fizycznemu centrum danych co strefa 2 w subskrypcji B.

• W przypadku scenariuszy aplikacji, które są bardzo rozmowne między składnikami aplikacji, rozłożenie warstw aplikacji między strefami może powodować znaczne opóźnienia i zwiększone koszty. Można temu zapobiec w projekcie, ograniczając sygnaturę wdrożenia do jednej strefy i wdrażając wiele sygnatur w różnych strefach.

• Komunikacja między różnymi regionami świadczenia usługi Azure wiąże się z większymi opłatami za transfer danych na GB przepustowości.

  • Odpowiedni współczynnik transferu danych zależy od kontynentu rozważanych regionów świadczenia usługi Azure.
  • Opłaty za przechodzenie na kontynenty danych są znacznie wyższe.

• Metody łączności usługi Express Route i sieci VPN mogą być również używane do bezpośredniego łączenia różnych regionów platformy Azure w przypadku niektórych scenariuszy, a nawet różnych platform w chmurze.

• W przypadku usług komunikacji usługi Private Link można używać do bezpośredniej komunikacji przy użyciu prywatnych punktów końcowych.

• Ruch może być przypięty do włosów za pośrednictwem obwodów usługi Express Route używanych do łączności lokalnej w celu ułatwienia routingu między sieciami wirtualnymi w regionie świadczenia usługi Azure i w różnych regionach świadczenia usługi Azure w ramach tej samej lokalizacji geograficznej.

  • Przypinanie ruchu przez usługę Express Route spowoduje obejście kosztów transferu danych związanych z komunikacją równorzędną sieci wirtualnych, dzięki czemu może służyć jako sposób optymalizacji kosztów.
  • Takie podejście wymaga dodatkowych przeskoków sieciowych na potrzeby integracji aplikacji na platformie Azure, co wprowadza ryzyko związane z opóźnieniami i niezawodnością. Rozszerza rolę usługi Express Route i skojarzonych składników bramy z platformy Azure/środowiska lokalnego, aby obejmować również łączność platformy Azure/platformy Azure.

• Gdy wymagane jest opóźnienie podrzędne między usługami, grupy umieszczania w pobliżu mogą być używane, gdy są obsługiwane przez usługi.

Zalecenia dotyczące projektowania

• Komunikacja równorzędna sieci wirtualnych umożliwia łączenie sieci w regionie i w różnych regionach. Zdecydowanie zaleca się unikanie przypinania włosów w usłudze Express Route.

• Użyj usługi Private Link, aby nawiązać komunikację bezpośrednio między usługami w tym samym regionie lub między regionami (usługa w regionie A komunikuje się z usługą w regionie B.

• W przypadku obciążeń aplikacji, które są bardzo rozmowne między składnikami, rozważ ograniczenie sygnatury wdrożenia do jednej strefy i wdrożenie wielu sygnatur w różnych strefach. Dzięki temu nadmiarowość strefowa jest utrzymywana na poziomie hermetyzowanego sygnatury wdrożenia, a nie pojedynczego składnika aplikacji.

• Jeśli to możliwe, traktuj każdą sygnaturę wdrożenia jako niezależną i odłączoną od innych sygnatur.

  • Użyj technologii platformy danych, aby zsynchronizować stan między regionami, a nie osiągnąć spójności na poziomie aplikacji z bezpośrednimi ścieżkami sieciowymi.
  • Unikaj ruchu "legginsowania psów" między różnymi regionami, chyba że jest to konieczne, nawet w scenariuszu awarii. Użyj globalnych usług routingu i end-to-end sond kondycji, aby w przypadku awarii pojedynczej krytycznej warstwy składników zamiast kierować ruch na poziomie wadliwego składnika do innego regionu.

• W przypadku scenariuszy aplikacji poufnych z opóźnieniem należy określić priorytety użycia stref z regionalnymi bramami sieci w celu zoptymalizowania opóźnienia sieci dla ścieżek przychodzących.

Mikrosegmentacja i zasady sieci platformy Kubernetes

Mikrosegmentacja to wzorzec projektowania zabezpieczeń sieci używany do izolowania i zabezpieczania poszczególnych obciążeń aplikacji, z zasadami stosowanymi w celu ograniczenia ruchu sieciowego między obciążeniami opartymi na modelu Zero Trust. Zwykle stosuje się je w celu zmniejszenia obszaru ataków sieciowych, zwiększenia ograniczania naruszeń i wzmocnienia zabezpieczeń za pomocą mechanizmów kontroli sieci na poziomie aplikacji opartych na zasadach.

Aplikacja o znaczeniu krytycznym może wymuszać zabezpieczenia sieci na poziomie aplikacji przy użyciu sieciowych grup zabezpieczeń (NSG) na poziomie podsieci lub interfejsu sieciowego, list kontroli dostępu do usług (ACL) i zasad sieciowych podczas korzystania z usługi Azure Kubernetes Service (AKS).

W tej sekcji opisano optymalne wykorzystanie tych możliwości, udostępniając kluczowe zagadnienia i zalecenia dotyczące osiągnięcia mikrosegmentacji na poziomie aplikacji.

Zagadnienia dotyczące projektowania

• Usługę AKS można wdrożyć w dwóch różnych modelach sieciowych:

  • Sieć Kubenet: węzły usługi AKS są zintegrowane w istniejącej sieci wirtualnej, ale zasobniki istnieją w sieci nakładki wirtualnej w każdym węźle. Ruch między zasobnikami w różnych węzłach jest kierowany przez serwer kube-proxy.
  • Sieć usługi Azure Container Networking Interface (CNI): klaster usługi AKS jest zintegrowany w istniejącej sieci wirtualnej i jej węzłach, zasobnikach i usługach odebranych adresów IP z tej samej sieci wirtualnej, do których są dołączone węzły klastra. Jest to istotne w przypadku różnych scenariuszy sieci wymagających bezpośredniej łączności z zasobników i do zasobników. Różne pule węzłów można wdrożyć w różnych podsieciach.

  Uwaga

  Usługa Azure CNI wymaga większej przestrzeni adresów IP w porównaniu z platformą Kubenet. Wymagane jest właściwe planowanie i ustalanie rozmiaru sieci. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją usługi Azure CNI.

• Domyślnie zasobniki nie są odizolowane i akceptują ruch z dowolnego źródła i mogą wysyłać ruch do dowolnego miejsca docelowego; zasobnik może komunikować się ze wszystkimi innymi zasobnikami w danym klastrze Kubernetes; Platforma Kubernetes nie zapewnia żadnej izolacji na poziomie sieci i nie izoluje przestrzeni nazw na poziomie klastra.

• Komunikację między zasobnikami i przestrzeniami nazw można odizolować przy użyciu zasad sieciowych. Zasady sieciowe to specyfikacja platformy Kubernetes, która definiuje zasady dostępu do komunikacji między zasobnikami. Korzystając z zasad sieciowych, można zdefiniować uporządkowany zestaw reguł w celu kontrolowania sposobu wysyłania/odbierania ruchu i stosowania do kolekcji zasobników pasujących do co najmniej jednego selektora etykiet.

  • Usługa AKS obsługuje dwie wtyczki implementujące zasady sieciowe, platformę Azure i kalifornię. Obie wtyczki używają tabel IPTable systemu Linux do wymuszania określonych zasad. Aby uzyskać więcej informacji, zobacz Różnice między zasadami platformy Azure i Calico oraz ich możliwościami .
  • Zasady sieciowe nie powodują konfliktu, ponieważ są one addytywne.
  • Aby przepływ sieciowy między dwoma zasobnikami był dozwolony, zasady ruchu wychodzącego w zasobniku źródłowym i zasady ruchu przychodzącego na zasobniku docelowym muszą zezwalać na ruch.
  • Funkcję zasad sieciowych można włączyć tylko w czasie tworzenia wystąpienia klastra. Nie można włączyć zasad sieciowych w istniejącym klastrze usługi AKS.
  • Dostarczanie zasad sieci jest spójne niezależnie od tego, czy platforma Azure czy Calico jest używana.
  • Calico udostępnia bogatszy zestaw funkcji, w tym obsługę węzłów systemu Windows i obsługuje usługę Azure CNI, a także platformę Kubenet.

• Usługa AKS obsługuje tworzenie różnych pul węzłów w celu oddzielenia różnych obciążeń przy użyciu węzłów z różnymi cechami sprzętowymi i programowymi, takimi jak węzły z możliwościami procesora GPU i bez nich.

  • Korzystanie z pul węzłów nie zapewnia żadnej izolacji na poziomie sieci.
  • Pule węzłów mogą używać różnych podsieci w tej samej sieci wirtualnej. Sieciowe grupy zabezpieczeń można stosować na poziomie podsieci w celu zaimplementowania mikrosegmentacji między pulami węzłów.

Zalecenia dotyczące projektowania

• Skonfiguruj sieciową grupę zabezpieczeń we wszystkich rozważanych podsieciach, aby zapewnić listę ACL adresów IP w celu zabezpieczenia ścieżek ruchu przychodzącego i izolowania składników aplikacji na podstawie modelu Zero Trust.

  • Użyj tagów usługi Front Door w sieciowych grupach zabezpieczeń we wszystkich podsieciach zawierających zaplecza aplikacji zdefiniowane w usłudze Azure Front Door, ponieważ spowoduje to zweryfikowanie ruchu pochodzącego z prawidłowej przestrzeni adresowej ip zaplecza usługi Azure Front Door. Zapewni to przepływ ruchu przez usługę Azure Front Door na poziomie usługi, ale filtrowanie oparte na nagłówku będzie nadal wymagane w celu zapewnienia użycia określonego wystąpienia usługi Front Door, a także ograniczenia ryzyka zabezpieczeń "fałszowania adresów IP".

  • Publiczny ruch internetowy powinien być wyłączony na portach RDP i SSH we wszystkich odpowiednich sieciowych grupach zabezpieczeń.

  • Określanie priorytetów użycia wtyczki sieciowej usługi Azure CNI i rozważ użycie usługi Kubenet w scenariuszach z ograniczonym zakresem dostępnych adresów IP w celu dopasowania aplikacji do ograniczonej przestrzeni adresowej.

    • Usługa AKS obsługuje korzystanie zarówno z usług Azure CNI, jak i Kubenet. Ten wybór sieci jest wybierany w czasie wdrażania.
    • Wtyczka sieci azure CNI jest bardziej niezawodną i skalowalną wtyczką sieciową i jest zalecana w większości scenariuszy.
    • Platforma Kubenet jest bardziej uproszczoną wtyczką sieciową i jest zalecana w scenariuszach z ograniczonym zakresem dostępnych adresów IP.
    • Aby uzyskać więcej informacji, zobacz Azure CNI .

• Funkcja zasad sieciowych na platformie Kubernetes powinna służyć do definiowania reguł ruchu przychodzącego i wychodzącego między zasobnikami w klastrze. Zdefiniuj szczegółowe zasady sieci, aby ograniczyć i ograniczyć komunikację między zasobnikami.

  • Włącz zasady sieciowe dla usługi Azure Kubernetes Service w czasie wdrażania.
  • Określanie priorytetów użycia Calico , ponieważ zapewnia on bogatszy zestaw funkcji z szerszym wdrożeniem społeczności i wsparciem.

Następny krok

Zapoznaj się z zagadnieniami dotyczącymi kwantyfikacji i obserwowania kondycji aplikacji.

Modelowanie i obserwowanie kondycji