Udostępnij za pośrednictwem


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

Regionalna dystrybucja zasobów w architekturze referencyjnej o znaczeniu krytycznym wymaga niezawodnej infrastruktury sieciowej.

Zalecany jest projekt globalnie rozproszony, w którym usługi platformy Azure łączą się w celu zapewnienia aplikacji o wysokiej dostępności. Globalny moduł równoważenia obciążenia połączony z sygnaturami regionalnymi zapewnia gwarancję dzięki niezawodnej łączności.

Sygnatury regionalne są jednostką, która można wdrożyć w architekturze. Możliwość szybkiego wdrażania nowej sygnatury zapewnia skalowalność i obsługuje wysoką dostępność. Znaczki odzwierciedlają izolowany projekt sieci wirtualnej . Ruch krzyżowy nie jest zalecany. Komunikacja równorzędna sieci wirtualnych lub połączenia sieci VPN z innymi sygnaturami nie są wymagane.

Architektura celowo definiuje sygnatury regionalne jako krótkotrwałe. Globalny stan infrastruktury jest przechowywany w zasobach globalnych.

Globalny moduł równoważenia obciążenia jest wymagany do kierowania ruchu na sprawne instancje i świadczenia usług bezpieczeństwa. Musi mieć pewne możliwości.

  • Kontrola zdrowia jest wymagana, aby równoważnik obciążenia mógł sprawdzić stan zdrowia źródła przed przekierowaniem ruchu.

  • Rozkład ruchu ważonego.

Opcjonalnie powinno być możliwe wykonywanie buforowania na brzegu. Ponadto należy zapewnić pewne zabezpieczenia dla ruchu przychodzącego przy użyciu zapory aplikacji internetowej (WAF).

Diagram sieci dla architektury referencyjnej.

Pobierz plik programu Visio tej architektury.

Napływ ruchu

Aplikacja zdefiniowana w architekturze ma dostęp do Internetu i ma kilka wymagań:

  • Rozwiązanie routingu, które jest globalne i może dystrybuować ruch między niezależnymi sygnaturami regionalnymi.

  • Małe opóźnienia w sprawdzaniu kondycji i możliwość zatrzymania wysyłania ruchu do sygnatur w złej kondycji.

  • Zapobieganie złośliwym atakom na krawędzi.

  • Zapewnianie możliwości buforowania na krawędzi.

Punkt wejścia dla całego ruchu w projekcie odbywa się za pośrednictwem usługi Azure Front Door. Usługa Front Door to globalny moduł równoważenia obciążenia, który kieruje ruch HTTP(S) do zarejestrowanych zapleczy/źródeł. Usługa Front Door używa sond monitorujących kondycję, które wysyłają żądania do identyfikatora URI w każdym zapleczu serwerowym/originie. W implementacji referencyjnej identyfikator URI nazywany jest usługą zdrowotną. Służba zdrowia reklamuje zdrowie znaczka. Usługa Front Door używa odpowiedzi w celu określenia kondycji pojedynczej sygnatury i kierowania ruchu do sygnatur w dobrej kondycji, które mogą obsługiwać żądania aplikacji.

Integracja usługi Azure Front Door z usługą Azure Monitor zapewnia niemal w czasie rzeczywistym monitorowanie ruchu, zabezpieczeń, sukcesów i niepowodzeń oraz alertów.

Zapora aplikacji internetowej platformy Azure zintegrowana z usługą Azure Front Door służy do zapobiegania atakom na brzegu sieci przed wejściem do sieci.

Diagram ruchu przychodzącego sieci dla architektury referencyjnej.

Izolowana sieć wirtualna — interfejs API

Interfejs API w ramach architektury używa sieci wirtualnych Azure jako granicy izolacji ruchu. Składniki w jednej sieci wirtualnej nie mogą komunikować się bezpośrednio ze składnikami w innej sieci wirtualnej.

Standardowa zewnętrzna usługa Azure Load Balancer dystrybuuje żądania do platformy aplikacji. Sprawdza, czy ruch docierający do modułu równoważenia obciążenia został kierowany za pośrednictwem usługi Azure Front Door, zapewniając, że zapora aplikacji internetowej platformy Azure sprawdza cały ruch.

Agenci kompilacji używane na potrzeby operacji i wdrażania architektury muszą mieć możliwość dotarcia do izolowanej sieci. Sieć izolowana można otworzyć, aby umożliwić agentom komunikację. Alternatywnie można wdrożyć własnych agentów w sieci wirtualnej.

Wymagane jest monitorowanie przepływności sieci, wydajność poszczególnych składników i kondycja aplikacji.

Zależność komunikacji platformy aplikacji

Platforma aplikacji używana z poszczególnymi pieczęciami w infrastrukturze ma następujące wymagania dotyczące komunikacji:

  • Platforma aplikacji musi mieć możliwość bezpiecznego komunikowania się z usługami PaaS firmy Microsoft.

  • Platforma aplikacji musi mieć możliwość bezpiecznego komunikowania się z innymi usługami w razie potrzeby.

Zdefiniowana architektura używa usługi Azure Key Vault do przechowywania wpisów tajnych, takich jak parametry połączenia i klucze interfejsu API, w celu bezpiecznego komunikowania się przez Internet z usługami PaaS platformy Azure. Istnieje ryzyko ujawnienia platformy aplikacji przez Internet na potrzeby tej komunikacji. Zaleca się zwiększenie zabezpieczeń i monitorowania publicznych punktów końcowych, ponieważ tajne informacje mogą zostać naruszone.

Diagram zależności komunikacji platformy aplikacji.

Zagadnienia dotyczące rozszerzonej sieci

W tej sekcji omówiono zalety i wady alternatywne podejścia do projektowania sieci. Alternatywne zagadnienia dotyczące sieci i korzystanie z prywatnych punktów końcowych platformy Azure skupia się na poniższych sekcjach.

Podsieci i sieciowe grupy zabezpieczeń

Podsieci w sieciach wirtualnych mogą służyć do segmentowania ruchu w projekcie. Izolacja podsieci oddziela zasoby dla różnych funkcji.

Sieciowe grupy zabezpieczeń mogą służyć do kontrolowania ruchu dozwolonego w podsieci i poza nimi. Reguły używane w sieciowych grupach zabezpieczeń mogą służyć do ograniczania ruchu na podstawie adresu IP, portu i protokołu w celu blokowania niechcianego ruchu do podsieci.

Prywatne punkty końcowe — Wejście

Wersja Premium usługi Front Door obsługuje korzystanie z prywatnych punktów końcowych platformy Azure. Prywatne punkty końcowe udostępniają usługę Azure na prywatny adres IP w sieci wirtualnej. Połączenia są bezpiecznie i prywatnie realizowane między usługami bez konieczności kierowania ruchu do publicznych punktów dostępu.

Usługa Azure Front Door Premium i prywatne punkty końcowe Azure umożliwiają w pełni prywatne klastry obliczeniowe w poszczególnych oddziałach. Ruch jest w pełni zablokowany dla wszystkich usług PaaS platformy Azure.

Korzystanie z prywatnych punktów końcowych zwiększa bezpieczeństwo projektu. Jednak wprowadza kolejny punkt awarii. Publiczne punkty końcowe uwidocznione w sygnaturach aplikacji nie są już potrzebne i nie mogą być już dostępne i narażone na możliwy atak DDoS.

Zwiększone bezpieczeństwo musi być ważone w porównaniu ze zwiększonym nakładem pracy, kosztem i złożonością niezawodności.

Do wdrożenia znaczników należy użyć własnych agentów kompilacji. Zarządzanie tymi agentami wiąże się z obciążeniem konserwacyjnym.

Diagram ruchu przychodzącego sieci dla architektury referencyjnej z prywatnymi punktami końcowymi.

Prywatne punkty końcowe — platforma aplikacji

Prywatne punkty końcowe są obsługiwane dla wszystkich usług PaaS platformy Azure używanych w tym projekcie. W przypadku prywatnych punktów końcowych skonfigurowanych dla platformy aplikacji cała komunikacja będzie podróżować przez sieć wirtualną sygnatury.

Publiczne punkty końcowe poszczególnych usług PaaS platformy Azure można skonfigurować tak, aby nie zezwalały na dostęp publiczny. Ten proces izoluje zasoby od ataków publicznych, które mogą spowodować przestój i ograniczanie przepustowości, które mają wpływ na niezawodność i dostępność.

Do wdrożenia sygnatury należy używać własnych agentów kompilacji tak samo jak poprzednio. Zarządzanie tymi agentami wiąże się z obciążeniem konserwacyjnym.

Diagram zależności komunikacji platformy aplikacji z prywatnymi punktami końcowymi.

Następne kroki

Wdróż implementację referencyjną, aby uzyskać pełną wiedzę na temat zasobów i ich konfiguracji używanej w tej architekturze.

Implementacja: Mission-Critical Online