Topologia sieci płaskiej z jednym obciążeniem

Sieć płaska to najprostsza topologia sieci Azure: jedna sieć wirtualna z wieloma podsieciami obsługującymi pojedyncze obciążenie. W tym artykule wyjaśniono, kiedy należy używać tego wzorca i jak go zaimplementować.

Co opisano w tym artykule

W tym artykule opisano najprostszą topologię sieci Azure: pojedynczą sieć wirtualną z wieloma podsieciami hostujących jedno obciążenie. Użyj tego wzorca, jeśli masz jedną aplikację zarządzaną przez jeden zespół i nie potrzebujesz usług udostępnionych, takich jak centralna zapora lub brama sieci VPN.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli:

  • Wdrażasz pierwsze obciążenie w Azure.
  • Jeden zespół jest właścicielem i obsługuje wszystkie zasoby.
  • Nie potrzebujesz udostępnionych usług sieciowych (zapory, bastionu, bramy) w wielu obciążeniach.
  • Potrzebujesz najprostszej sieci, która nadal zapewnia izolację i zabezpieczenia na poziomie podsieci.

Nacisk na lift-and-shift: Pojedyncza płaska sieć wirtualna z oddzielną podsiecią dla każdego komponentu jest często właściwym pierwszym krokiem przy ponownym hostowaniu jednego obciążenia roboczego w jednym regionie.

Priorytet modernizacji: Użyj płaskiej sieci na potrzeby wczesnego pilotażu PaaS lub jednego zmodernizowanego obciążenia roboczego i zaprojektuj jej podsieci tak, aby można ją było łatwo przekształcić w architekturę piasta-szprychy po dodaniu usług współdzielonych lub drugiego regionu.

Podejście wielochmurowe: Użyj płaskiej sieci wirtualnej jako jednego punktu zaczepienia w Azure podczas migracji między chmurami: najpierw przenieś obciążenie, a następnie zaplanuj jego przestrzeń adresową i segmentację, aby mogło dołączyć do hubu lub usługi Virtual WAN w miarę dojrzewania architektury.

Usługi i funkcje platformy Azure

Topologia sieci płaskiej korzysta z tych podstawowych usług Azure:

Service Rola w tej topologii
Azure Virtual Network Zapewnia prywatną, izolowaną przestrzeń adresową dla Twoich obciążeń. Sieć wirtualna jest ograniczona do jednego regionu Azure.
Podsieci i sieciowe grupy zabezpieczeń Podsieci oddzielają warstwy aplikacji. Sieciowe grupy zabezpieczeń filtrują ruch przychodzący i wychodzący na granicy każdej podsieci. NSG są mechanizmem stanowym: ruch zwrotny dla dozwolonych połączeń jest automatycznie dozwalany.
prywatna strefa DNS platformy Azure Zapewnia wewnętrzne rozpoznawanie nazw dla zasobów w sieci wirtualnej. Połącz strefę z włączoną funkcją automatycznego wyrejestrowania, aby maszyny wirtualne automatycznie pobierały rekordy DNS.
Podsieć bramy(opcjonalnie) Hostuje bramę sieci VPN lub usługi ExpressRoute, jeśli potrzebujesz jednego połączenia z siecią lokalną.

Jak wybrać: pozostać przy płaskiej strukturze czy przejść na model piasta–szprychy?

Poniższa tabela decyzyjna umożliwia określenie, czy topologia płaska jest odpowiednia dla danego środowiska, czy też zamiast tego należy zastosować topologię piasty i szprych.

Warunek Rekomendacja
Pojedyncze obciążenie, pojedynczy zespół, brak usług udostępnionych Pozostań płaski: ten artykuł ma zastosowanie
Drugie niezależne obciążenie wymaga własnej izolacji sieci Ukończenie topologii piasty i szprych
Potrzebujesz współdzielonej zapory, bramy VPN lub usługi Azure Bastion dla wielu obciążeń. Ukończenie topologii piasty i szprych
Zasady bezpieczeństwa muszą być centralnie zarządzane w wielu środowiskach roboczych Ukończenie topologii piasty i szprych

Tip

Jeśli przewidujesz dodanie drugiego obciążenia roboczego w ciągu 6–12 miesięcy, rozważ rozpoczęcie od architektury hub-and-spoke od samego początku. Narzut jest minimalny, ponieważ dodajesz tylko jedną dodatkową sieć wirtualną i połączenie peeringowe. Takie podejście pozwala uniknąć uciążliwej migracji na późniejszym etapie.

Uwagi dotyczące projektowania

Koncentracja na projektowaniu płaskiej sieci metodą „lift-and-shift”

  • Użyj jednej sieci wirtualnej z podsiecią dla każdego składnika aplikacji (internet, aplikacja, dane), aby zdublować typowy lokalny układ trójwarstwowy z minimalnym przeprojektowaniem.
  • Zastosuj sieciowe grupy zabezpieczeń (NSG) między podsieciami, aby odtworzyć istniejącą segmentację, i utrzymuj przestrzeń adresową zgodną z zakresami używanymi lokalnie, aby uniknąć nakładania się zakresów.
  • Pozostań przy płaskiej strukturze, gdy za obciążenie odpowiada jeden zespół i nie potrzebujesz współdzielonych usług zapory, bramy ani usługi Bastion.
  • Zaplanuj przejście na architekturę piasta–szprychy przed dodaniem drugiego obciążenia roboczego, aby usługi wspólne trafiły do piasty centralnej, zamiast wymagać późniejszego dostosowywania.

Nacisk na modernizację projektu płaskiej sieci

  • Użyj sieci płaskiej na potrzeby wczesnego pilotażu PaaS lub jednego zmodernizowanego obciążenia: umieść warstwy aplikacji w podsieciach i dotrzej do Azure PaaS za pośrednictwem prywatnych punktów końcowych w dedykowanej podsieci.
  • Zarezerwuj z wyprzedzeniem dedykowane podsieci dla usług platformowych, które planujesz dodać, takich jak Application Gateway i prywatne punkty końcowe, aby sieć mogła się rozwijać bez konieczności zmiany adresacji.
  • Zastosuj sieciowe grupy zabezpieczeń (NSG) i grupy zabezpieczeń aplikacji dla poszczególnych warstw, aby segmentacja była już wdrożona, jeśli obciążenie robocze później stanie się szprychą w architekturze piasta-szprycha.
  • Zachowaj przestrzeń adresową nienakładającą się z innymi regionami i sieciami wirtualnymi, aby umożliwić komunikację równorzędną lub stopniową w centrum później bez ponownego numerowania.

Skoncentrowanie się na projekcie sieci płaskiej między chmurami

  • Użyj płaskiej sieci VNet jako pojedynczego punktu obecności w platformie Azure podczas migracji między chmurami: najpierw wdroż obciążenie, a następnie podłącz łączność z koncentratora w miarę dojrzewania architektury.
  • Zaplanuj płaską przestrzeń adresową sieci VNet tak, aby uniknąć nakładania się z sieciami VPC w AWS i sieciami Google Cloud, dzięki czemu będzie można później dołączyć ją do routingu przez IPsec lub Interconnect bez translacji adresów.
  • Zachowaj segmentację warstwową za pomocą grup NSG, aby stan zabezpieczeń obciążenia został zachowany, gdy stanie się ono odgałęzieniem za zabezpieczonym koncentratorem Virtual WAN.
  • Standaryzacja nazewnictwa i tagowania podsieci w celu dopasowania ich do innych chmur, dzięki czemu obciążenie pozostaje łatwe do skorelowania podczas migracji i po jej zakończeniu.

Prerequisites

Przed zaimplementowanie tej topologii:

  • Subskrypcja Azure z uprawnieniami do tworzenia sieci wirtualnych i sieciowych grup zabezpieczeń.
  • Planowana przestrzeń adresowa IP. Przestrzeń adresowa /16 zapewnia 65 536 adresów, co jest typowym punktem wyjścia dla pojedynczego obciążenia. Azure rezerwuje 5 adresów na podsieć do użytku wewnętrznego. Aby uzyskać szczegółowe wskazówki, zobacz Planowanie adresowania IP.
  • Znajomość warstw Twojej aplikacji (na przykład internetowej, aplikacyjnej i danych), aby można było przypisać je do podsieci. Aby uzyskać wskazówki dotyczące projektowania podsieci, zobacz Projektowanie sieci wirtualnych i podsieci.

Układ sieci

Diagram przedstawiający płaską topologię sieci z podsieciami sieci Web, aplikacji i warstwy danych, z których każda jest chroniona przez sieciową grupę zabezpieczeń w ramach jednej sieci wirtualnej.

Topologia sieci płaskiej jest zgodna z tą strukturą:

  • Jedna sieć wirtualna z pojedynczą przestrzenią adresową (na przykład 10.0.0.0/16).
  • Wiele podsieci: jedna na warstwę aplikacji lub składnik:
    • Podsieć warstwy sieci Web (na przykład 10.0.1.0/24).
    • Podsieć warstwy aplikacji (na przykład 10.0.2.0/24).
    • Podsieć warstwy danych (na przykład 10.0.3.0/24).
    • Podsieć bramy (opcjonalnie, na przykład 10.0.255.0/27).
  • Sieciowe grupy zabezpieczeń (NSG) przypisane do każdej podsieci z regułami, które zezwalają tylko na ruch, którego potrzebuje każda warstwa.
  • Jedna prywatna strefa DNS połączona z siecią wirtualną z włączoną automatyczną rejestracją.

Note

Starannie zaplanuj zakresy adresów IP. Jeśli później przejdziesz na topologię typu piasta-szprychy, sieci wirtualne pełniące rolę szprych muszą mieć zakresy CIDR, które nie nakładają się na zakres piasty. Wybranie dobrze ustrukturyzowanego schematu adresów zapobiega teraz konfliktom podczas migracji.

Zagadnienia dotyczące zabezpieczeń

Zastosuj te rozwiązania w zakresie zabezpieczeń do sieci płaskiej:

  • Sieciowe grupy zabezpieczeń w każdej podsieci. Zacznij od domyślnej zasady blokowania całego ruchu przychodzącego i dodaj konkretne reguły zezwalające na uprawniony ruch między warstwami. Na przykład zezwól na protokół HTTPS z warstwy internetowej na warstwę aplikacji i zezwól usłudze SQL z warstwy aplikacji na warstwę danych.
  • Brak publicznych adresów IP bezpośrednio na maszynach wirtualnych. Uwidaczniaj usługi za pośrednictwem modułu równoważenia obciążenia lub usługi Application Gateway. Użyj Azure Bastion na potrzeby dostępu administracyjnego.
  • Prywatna strefa DNS do rozwiązania wewnętrznego. Prywatna strefa DNS strefy uniemożliwiają ujawnienie wewnętrznych nazw hostów za pośrednictwem publicznych zapytań DNS.
  • Izolacja podsieci bramy. W przypadku dodania bramy sieci VPN lub usługi ExpressRoute umieść ją w dedykowanej podsieci (o nazwie GatewaySubnet). Sieciowe grupy zabezpieczeń (NSG) w podsieci bramy nie są obsługiwane. Skojarzenie Grupy Zabezpieczeń Sieciowych (NSG) z tą podsiecią może spowodować, że brama do sieci wirtualnej przestanie działać zgodnie z oczekiwaniami.

Ważna

Po usunięciu reguły sieciowej grupy zabezpieczeń (NSG), która zezwala na połączenie, istniejące aktywne połączenia pozostają aktywne bez przerwy. Blokowane są tylko nowe połączenia zgodne z usuniętą regułą.

Poniższe artykuły zawierają bardziej szczegółowe wskazówki dotyczące powiązanych tematów:

Learn more

Aby uzyskać więcej informacji na temat usług Azure używanych w tej topologii, zobacz:

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Zaprojektuj topologię piasta-szprycha: Większość migracji metodą „lift-and-shift” szybko przestaje mieścić się w płaskiej sieci. Zaplanuj scentralizowane usługi wspólne od samego początku.

Kolejny etap procesu modernizacji:

Zaprojektuj topologię hub-and-spoke: Zmodernizowane obciążenia robocze z wieloma usługami, mechanizmami zabezpieczeń i zespołami wymagają topologii hub-and-spoke od samego początku.

Kolejny krok w Twojej wielochmurowej podróży:

Zaplanuj architekturę łączności między chmurami: Środowiska wielochmurowe wymagają architektury tranzytowej, a nie płaskich sieci. Zaprojektuj model łączności z wieloma chmurami.