Udostępnij za pośrednictwem

Wytyczne dotyczące planowania sieciowego dla Azure NetApp Files

Planowanie architektury sieciowej to kluczowy element projektowania każdej infrastruktury aplikacyjnej. Ten artykuł pomoże Ci zaprojektować efektywną architekturę sieciową dla Twoich obciążeń, aby skorzystać z bogatych możliwości Azure NetApp Files.

Woluminy usługi Azure NetApp Files zostały zaprojektowane tak, aby znajdowały się w podsieci specjalnej o nazwie delegowanej podsieci w ramach usługi Azure Virtual Network. W związku z tym możesz uzyskać dostęp do woluminów bezpośrednio z poziomu Azure przez peering wirtualnej sieci (VNet) lub z lokalizacji lokalnej przez Bramę Sieci Wirtualnej (ExpressRoute lub Brama VPN). Podsieć jest dedykowana dla Azure NetApp Files i nie ma połączenia z Internetem.

Opcja ustawienia standardowych funkcji sieciowych w nowych woluminach oraz modyfikacji funkcji sieciowych dla istniejących woluminów jest obsługiwana we wszystkich regionach z włączonymi plikami Azure NetApp Files.

Konfigurowalne funkcje sieciowe

Możesz utworzyć nowe woluminy lub zmodyfikować istniejące woluminy, aby używać funkcji sieci w warstwie Standardowa lub Podstawowa . Aby uzyskać więcej informacji, zobacz Konfigurowanie funkcji sieciowych.

  • Norma
    Wybranie tego ustawienia umożliwia wyższe limity adresów IP i standardowe funkcje sieci wirtualnej, takie jak sieciowe grupy zabezpieczeń i trasy zdefiniowane przez użytkownika w delegowanych podsieciach oraz dodatkowe wzorce łączności, jak wskazano w tym artykule.

  • Podstawowy
    Wybranie tego ustawienia umożliwia selektywne wzorce łączności i ograniczoną skalę adresów IP, jak wspomniano w sekcji Zagadnienia . Wszystkie ograniczenia mają zastosowanie w tym ustawieniu.

Rozważania

Podczas planowania sieci usługi Azure NetApp Files należy zapoznać się z kilkoma zagadnieniami.

Ograniczenia

Ważne

Zwiększenie limitu tras dla podstawowych funkcji sieciowych nie zostanie już zatwierdzone po 30 maja 2025 r. Aby uniknąć problemów z limitem tras, należy zmodyfikować woluminy do korzystania ze standardowych funkcji sieciowych.

Poniższa tabela opisuje, co jest obsługiwane dla każdej konfiguracji funkcji sieciowych:

Funkcje Standardowe funkcje sieciowe Podstawowe funkcje sieciowe
Liczba adresów IP w VNet (w tym bezpośrednio połączonych VNet) uzyskujących dostęp do woluminów w VNet, który hostuje Azure NetApp Files. Te same limity standardowe co maszyny wirtualne 1000
Delegowane podsieci usługi Azure NetApp Files dla sieci wirtualnej 1 1
Sieciowe grupy zabezpieczeń w podsieciach delegowanych usługi Azure NetApp Files Tak Nie
Obsługa NSG dla prywatnych punktów końcowych Tak Nie
Trasy zdefiniowane przez użytkownika (UDR) w podsieciach delegowanych usługi Azure NetApp Files Tak Nie
Łączność z prywatnymi punktami końcowymi Tak Nie
Łączność z punktami końcowymi usługi Tak Nie
Zasady platformy Azure (na przykład niestandardowe zasady nazewnictwa) w interfejsie usługi Azure NetApp Files Nie Nie
Równoważenie obciążenia dla ruchu Azure NetApp Files Nie Nie
Sieć VNet z podwójnym stosem (IPv4 i IPv6) Nie
(Obsługiwane tylko protokół IPv4)		 Nie
(Obsługiwane tylko protokół IPv4)
Ruch trasowany przez NVA z peered VNet Tak Nie

Obsługiwane topologie sieciowe

W poniższej tabeli opisano topologie sieci obsługiwane przez każdą konfigurację funkcji sieciowych usługi Azure NetApp Files.

Topologie Standardowe funkcje sieciowe Podstawowe funkcje sieciowe
Łączność z woluminem w lokalnej sieci VNet Tak Tak
Łączność z woluminem w połączonej sieci VNet (ten sam region) Tak Tak
Łączność do woluminu w połączonym VNet (między regionami lub globalne połączenie) Tak* Nie
Łączenie z woluminem przez bramę ExpressRoute Tak Tak
ExpressRoute (ER) FastPath Tak Nie
Łączność z lokalnej infrastruktury do zasobu w sieci VNet typu spoke przez bramę ExpressRoute i peering VNet z tranzytem bramowym. Tak Tak
Łączność od instalacji lokalnej do woluminu w VNet typu spoke przez bramę VPN Tak Tak
Łączność z lokalnego środowiska do woluminu w sieci VNet w strukturze typu szprycha przez bramę VPN oraz komunikacja równorzędna sieci VNet z tranzytem przez bramę. Tak Tak
Łączność przez aktywne/pasywne bramy VPN Tak Tak
Łączność przez Aktywne/Aktywne bramki VPN Tak Nie
Łączność przez aktywny/aktywny strefowy redundantne bramy Tak Nie
Łączność przez bramy redundantnych stref aktywnych/pasywnych Tak Tak
Łączność za pośrednictwem usługi Virtual WAN (VWAN) Tak Nie

* Ta opcja wiąże się z opłatą za ruch przychodzący i wychodzący, który korzysta z połączenia peerowego sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Cennik usługi Virtual Network. Aby uzyskać więcej ogólnych informacji, zobacz Peering sieci wirtualnych.

Sieć wirtualna dla woluminów Azure NetApp Files

Ta sekcja wyjaśnia pojęcia, które pomogą Ci w planowaniu sieci wirtualnej.

Azure sieci wirtualne

Przed zaopatrzeniem woluminu Azure NetApp Files, należy utworzyć sieć wirtualną Azure (VNet) lub użyć już istniejącej w ramach tej samej subskrypcji. VNet definiuje granicę sieci woluminu. Aby uzyskać więcej informacji na temat tworzenia sieci wirtualnych, zobacz dokumentację usługi Azure Virtual Network.

Podsieci

Podsieci segmentują sieć wirtualną na odrębne przestrzenie adresowe, które są użyteczne dla zasobów Azure znajdujących się w nich. Woluminy usługi Azure NetApp Files znajdują się w podsieci specjalnej o nazwie podsieci delegowanej.

Delegowanie podsieci daje wyraźne uprawnienia usłudze Azure NetApp Files do tworzenia zasobów specyficznych dla usług w podsieci. Wykorzystuje unikalny identyfikator do wdrażania usługi. W takim przypadku jest tworzony interfejs sieciowy umożliwiający łączność z usługą Azure NetApp Files.

Jeśli używasz nowej sieci wirtualnej, możesz utworzyć podsieć i delegować podsieć do usługi Azure NetApp Files, postępując zgodnie z instrukcjami w temacie Delegowanie podsieci do usługi Azure NetApp Files. Możesz także przekazać istniejącą pustą podsieć, która nie jest przypisana do innych usług.

Jeśli sieć wirtualna jest połączona równorzędnie z inną siecią wirtualną, nie można rozszerzyć przestrzeni adresowej sieci wirtualnej. Z tego powodu nowa podsieć delegowana musi zostać utworzona w ramach przestrzeni adresowej VNet. Jeśli musisz rozszerzyć adresację, musisz usunąć peering VNet przed rozwinięciem adresacji.

Uwaga

Zaleca się, aby rozmiar delegowanej podsieci był co najmniej /25 dla obciążeń SAP i /26 w przypadku innych scenariuszy obciążeń.

Trasy zdefiniowane przez użytkownika i sieciowe grupy zabezpieczeń

Jeśli podsieć ma kombinację woluminów z funkcjami sieciowymi w warstwie Standardowa i Podstawowa, trasy zdefiniowane przez użytkownika i sieciowe grupy zabezpieczeń zastosowane w podsieciach delegowanych będą dotyczyć tylko woluminów z funkcjami sieciowymi w warstwie Standardowa.

Uwaga

Kojarzenie grup zabezpieczeń sieciowych (NSG) na poziomie interfejsu sieciowego nie jest obsługiwane dla interfejsów sieciowych usługi Azure NetApp Files.

Konfigurowanie UDR w źródłowych podsieciach maszyn wirtualnych z prefiksem adresów delegowanej podsieci i z następnym przeskokiem jako NVA nie jest obsługiwane dla woluminów z podstawowymi funkcjami sieciowymi. Takie ustawienie spowoduje problemy z łącznością.

Uwaga

Aby uzyskać dostęp do woluminu Azure NetApp Files z sieci lokalnej za pomocą bramy VNet (ExpressRoute lub VPN) i zapory sieciowej, skonfiguruj tabelę routingu przypisaną do bramy VNet tak, aby zawierała wymieniony adres IPv4 woluminu Azure NetApp Files oraz wskazywała zaporę jako następny punkt przeskoku. Użycie zagregowanej przestrzeni adresowej zawierającej adres IP woluminu usługi Azure NetApp Files nie przekazuje ruchu usługi Azure NetApp Files do zapory.

Uwaga

Jeśli chcesz skonfigurować tabelę tras (trasa zdefiniowana przez użytkownika) w celu kontrolowania routingu pakietów za pośrednictwem wirtualnego urządzenia sieciowego lub zapory przeznaczonej do standardowego woluminu usługi Azure NetApp Files ze źródła w tej samej sieci wirtualnej lub równorzędnej sieci wirtualnej, prefiks trasy zdefiniowanej przez użytkownika musi być bardziej szczegółowy lub równy rozmiarowi delegowanej podsieci woluminu usługi Azure NetApp Files. Jeśli prefiks UDR jest mniej specyficzny niż delegowany rozmiar podsieci, nie jest skuteczny.

Jeśli na przykład delegowana podsieć to x.x.x.x/24, musisz skonfigurować TDZP na x.x.x.x/24 (równą) lub x.x.x.x/32 (bardziej szczegółową). Jeśli skonfigurujesz trasę UDR jako x.x.x.x/16, nieokreślone zachowania, takie jak asymetryczne routowanie, mogą spowodować przerwanie sieci na zaporze ogniowej.

Środowiska natywne platformy Azure

Następujący diagram ilustruje środowisko natywne dla Azure.

Diagram przedstawiający konfigurację środowiska natywnego platformy Azure.

Lokalny VNet

Podstawowy scenariusz polega na utworzeniu lub połączeniu się z woluminem Azure NetApp Files z maszyny wirtualnej (VM) w tej samej sieci VNet. Dla VNet 2 na diagramie, Wolumen 1 jest tworzony w przypisanej podsieci i może być zamontowany na VM 1 w domyślnej podsieci.

Peering sieci VNet

Jeśli masz inne sieci wirtualne w tym samym regionie, które wymagają dostępu do zasobów nawzajem, sieci wirtualne mogą być połączone ze sobą za pomocą VNet peering, aby umożliwić bezpieczną łączność za pośrednictwem infrastruktury Azure.

Rozważ VNet 2 i VNet 3 w przedstawionym powyżej diagramie. Jeśli VM 1 musi połączyć się z VM 2 lub Volume 2, albo jeśli VM 2 musi połączyć się z VM 1 lub Volume 1, to należy włączyć równorzędne połączenie VNet pomiędzy VNet 2 a VNet 3.

Dodatkowo, rozważ scenariusz, w którym VNet 1 jest sparowany z VNet 2, a VNet 2 jest sparowany z VNet 3 w tym samym regionie. Zasoby z VNet 1 mogą łączyć się z zasobami w VNet 2, ale nie mogą łączyć się z zasobami w VNet 3, chyba że VNet 1 i VNet 3 są sparowane.

Na powyższym diagramie maszyna wirtualna 3 może nawiązać połączenie z woluminem 1, ale maszyna wirtualna 4 nie może nawiązać połączenia z woluminem 2. Przyczyną tego jest to, że sieci wirtualne typu spoke nie są połączone, a routing tranzytowy nie jest obsługiwany za pośrednictwem "peering VNet".

Globalne lub międzyregionalne peering sieci wirtualnych

Na poniższym diagramie przedstawiono środowisko natywne Azure z połączeniami równorzędnymi VNet między regionami.

Diagram przedstawiający konfigurację środowiska natywnego Azure z peeringiem sieci wirtualnych między regionami.

Dzięki funkcjom sieciowym Standard maszyny wirtualne mogą łączyć się z woluminami w innym regionie za pośrednictwem globalnego lub międzyregionalnego peeringu VNet. Powyższy diagram dodaje drugi region do konfiguracji w sekcji lokalnego peeringu sieci wirtualnych. Dla VNet 4 na tym diagramie, wolumen Azure NetApp Files jest tworzony w wydzielonej podsieci i może być zamontowany na VM5 w podsieci aplikacyjnej.

Na schemacie maszyna wirtualna VM2 w regionie 1 może łączyć się z woluminem 3 w regionie 2. Maszyna wirtualna VM5 w regionie 2 może łączyć się z woluminem 2 w regionie 1 za pośrednictwem VNet peeringu między regionem 1 i regionem 2.

Środowiska hybrydowe

Poniższy diagram ilustruje środowisko hybrydowe:

Diagram przedstawiający środowisko sieci hybrydowej.

W scenariuszu hybrydowym, aplikacje z lokalnych centrów danych potrzebują dostępu do zasobów w Azure. Niezależnie od tego, czy chcesz rozszerzyć swoje centrum danych na Azure, czy skorzystać z natywnych usług Azure, czy też do celów odzyskiwania po awarii, zasada pozostaje taka sama. Zobacz Opcje planowania usługi VPN Gateway , aby uzyskać informacje na temat łączenia wielu zasobów lokalnych z zasobami na platformie Azure za pośrednictwem sieci VPN typu lokacja-lokacja lub usługi ExpressRoute.

W hybrydowej topologii gwiazda-szprycha, sieć węzła centralnego VNet w Azure działa jako centralny punkt łączności z siecią lokalną. Szprychy to VNets połączone z koncentratorem i mogą być używane do izolowania obciążeń.

W zależności od konfiguracji, możesz połączyć zasoby lokalne z zasobami w centralnym węźle sieci i w gałęziach.

W przedstawionej powyżej topologii, sieć lokalna jest połączona z centralną siecią VNet na platformie Azure, a w tym samym regionie znajdują się 2 sieci VNet typu spoke, które są powiązane z centralną siecią VNet. W tym scenariuszu obsługiwane opcje łączności dla wolumenów Azure NetApp Files są następujące:

  • Zasoby lokalne VM 1 i VM 2 mogą połączyć się z Volumem 1 w hubie za pośrednictwem VPN typu site-to-site lub za pomocą połączenia ExpressRoute.
  • Zasoby lokalne VM 1 i VM 2 mogą się łączyć z Woluminem 2 lub Woluminem 3 poprzez VPN typu site-to-site oraz regionalne peering VNet.
  • VM 3 w sieci VNet koncentratora może łączyć się z Wolumenem 2 w sieci VNet 1 szprychy i Wolumenem 3 w sieci VNet 2 szprychy.
  • VM 4 z przyporządkowanej sieci VNet 1 oraz VM 5 z przyporządkowanej sieci VNet 2 mogą łączyć się z Woluminem 1 w centralnej sieci VNet.
  • VM 4 w sieci VNet 1 nie może połączyć się z woluminem 3 w sieci VNet 2. Ponadto VM 5 w sieci szkieletowej VNet2 nie może połączyć się z Volume 2 w sieci szkieletowej VNet1. Dzieje się tak, ponieważ sieci wirtualne typu spoke nie są połączone, a routing tranzytowy nie jest obsługiwany przez peering sieci wirtualnych.
  • W powyższej architekturze, jeśli w sieci VNet spoke również znajduje się brama, połączenie do wolumenu ANF z lokalnego środowiska łączącego się przez bramę w centrum zostanie utracone. Z założenia preferencja będzie przyznawana bramce w sieci VNet typu spoke, więc tylko maszyny łączące się przez tę bramkę mogą uzyskać dostęp do wolumenu ANF.

Następne kroki