Riktlinjer för Azure NetApp Files-nätverksplanering

Planering av nätverksarkitektur är en viktig del i utformningen av en programinfrastruktur. Den här artikeln hjälper dig att utforma en effektiv nätverksarkitektur för dina arbetsbelastningar för att dra nytta av de omfattande funktionerna i Azure NetApp Files.

Azure NetApp Files-volymer är utformade för att finnas i ett särskilt undernät som kallas ett delegerat undernät i ditt virtuella Azure-nätverk. Därför kan du komma åt volymerna direkt från Azure via VNet-peering eller lokalt via en virtuell nätverksgateway (ExpressRoute eller VPN Gateway). Undernätet är dedikerat till Azure NetApp Files och det finns ingen anslutning till Internet.

Alternativet att ange Standard-nätverksfunktioner på nya volymer och ändra nätverksfunktioner för befintliga volymer stöds i alla Azure NetApp Files-aktiverade regioner.

Konfigurerbara nätverksfunktioner

I regioner som stöds kan du skapa nya volymer eller ändra befintliga volymer så att de använder Standard- eller Basic-nätverksfunktioner. I regioner där standardnätverksfunktionerna inte stöds använder volymen standardinställningarna för grundläggande nätverksfunktioner. Mer information finns i Konfigurera nätverksfunktioner.

  • Standard
    Om du väljer den här inställningen kan du använda högre IP-gränser och standardfunktioner för virtuella nätverk, till exempel nätverkssäkerhetsgrupper och användardefinierade vägar i delegerade undernät, samt ytterligare anslutningsmönster som anges i den här artikeln.

  • Grundläggande
    Om du väljer den här inställningen kan du använda selektiva anslutningsmönster och begränsad IP-skalning enligt beskrivningen i avsnittet Överväganden . Alla begränsningar gäller i den här inställningen.

Att tänka på

Du bör förstå några saker när du planerar för Azure NetApp Files-nätverket.

Krav

I följande tabell beskrivs vad som stöds för varje konfiguration av nätverksfunktioner:

Funktioner Standardnätverksfunktioner Grundläggande nätverksfunktioner
Antal IP-adresser i ett virtuellt nätverk (inklusive direkt peerkopplade virtuella nätverk) som har åtkomst till volymer i ett Azure NetApp Files som är värd för VNet Samma standardgränser som virtuella datorer 1000
Azure NetApp Files delegerade undernät per VNet 1 1
Nätverkssäkerhetsgrupper (NSG:er) i Azure NetApp Files delegerade undernät Ja Nej
Användardefinierade vägar (UDR) på azure NetApp Files-delegerade undernät Ja Nej
Anslut ivitet för Privata slutpunkter Ja* Nej
Anslut ivitet för Tjänstslutpunkter Ja Nej
Azure-principer (till exempel anpassade namngivningsprinciper) i Azure NetApp Files-gränssnittet Nej Nej
Lastbalanserare för Azure NetApp Files-trafik Nej Nej
Virtuellt nätverk med dubbla staplar (IPv4 och IPv6) Nej
(Endast IPv4 stöds)
Nej
(Endast IPv4 stöds)
Trafik som dirigeras via NVA från peer-kopplat VNet Ja Nej

* Användning av Azure-nätverkssäkerhetsgrupper i det privata länkundernätet till Azure Key Vault stöds inte för kundhanterade Azure NetApp Files-nycklar. Nätverkssäkerhetsgrupper påverkar inte anslutningen till Private Link om inte principen för privat slutpunktsnätverk är aktiverad i undernätet. Vi rekommenderar att du håller det här alternativet inaktiverat.

Nätverkstopologier som stöds

I följande tabell beskrivs de nätverkstopologier som stöds av varje nätverksfunktionskonfiguration av Azure NetApp Files.

Topologier Standardnätverksfunktioner Grundläggande nätverksfunktioner
Anslut volym i ett lokalt virtuellt nätverk Ja Ja
Anslut till volym i ett peer-kopplat virtuellt nätverk (samma region) Ja Ja
Anslut till volym i ett peer-kopplat virtuellt nätverk (korsregion eller global peering) Ja* Nej
Anslut till en volym via ExpressRoute-gateway Ja Ja
ExpressRoute (ER) FastPath Ja Nej
Anslut ivity from on-premises to a volume in a spoke VNet over ExpressRoute gateway and VNet peering with gateway transit Ja Ja
Anslut ivity from on-premises to a volume in a spoke VNet over VPN gateway Ja Ja
Anslut ivity from on-premises to a volume in a spoke VNet over VPN gateway and VNet peering with gateway transit Ja Ja
Anslut ivitet över aktiva/passiva VPN-gatewayer Ja Ja
Anslut ivity over Active/Active VPN gateways Ja Nej
Anslut ivity over Active/Active Zone Redundant gateways Ja Nej
Anslut ivity over Active/Passive Zone Redundant gateways Ja Ja
Anslut ivity over Virtual WAN (VWAN) Ja Nej

* Det här alternativet medför en avgift för inkommande och utgående trafik som använder en peering-anslutning för virtuella nätverk. Mer information finns i Priser för virtuellt nätverk. Mer allmän information finns i Peering för virtuella nätverk.

Virtuella nätverk för Azure NetApp Files-volymer

I det här avsnittet beskrivs begrepp som hjälper dig med planering av virtuella nätverk.

Virtuella Azure-nätverk

Innan du etablerar en Azure NetApp Files-volym måste du skapa ett virtuellt Azure-nätverk (VNet) eller använda ett som redan finns i samma prenumeration. Det virtuella nätverket definierar volymens nätverksgräns. Mer information om hur du skapar virtuella nätverk finns i dokumentationen för Azure Virtual Network.

Undernät

Undernät segmentera det virtuella nätverket i separata adressutrymmen som kan användas av Azure-resurserna i dem. Azure NetApp Files-volymer finns i ett specialundernät som kallas för ett delegerat undernät.

Delegering av undernät ger uttryckliga behörigheter till Azure NetApp Files-tjänsten för att skapa tjänstspecifika resurser i undernätet. Den använder en unik identifierare för att distribuera tjänsten. I det här fallet skapas ett nätverksgränssnitt för att aktivera anslutning till Azure NetApp Files.

Om du använder ett nytt virtuellt nätverk kan du skapa ett undernät och delegera undernätet till Azure NetApp Files genom att följa anvisningarna i Delegera ett undernät till Azure NetApp Files. Du kan också delegera ett befintligt tomt undernät som inte delegeras till andra tjänster.

Om det virtuella nätverket är peerkopplat med ett annat VNet kan du inte utöka adressutrymmet för det virtuella nätverket. Därför måste det nya delegerade undernätet skapas i det virtuella nätverkets adressutrymme. Om du behöver utöka adressutrymmet måste du ta bort VNet-peering innan du expanderar adressutrymmet.

Viktigt!

Kontrollera att adressutrymmets storlek för det virtuella Azure NetApp Files-nätverket är större än dess delegerade undernät.

Om det delegerade undernätet till exempel är /24 måste det virtuella nätverkets adressutrymme som innehåller undernätet vara /23 eller större. Inkompatibilitet med den här riktlinjen kan leda till oväntade problem i vissa trafikmönster: trafik som passerar en hub-and-spoke-topologi som når Azure NetApp Files via en virtuell nätverksinstallation fungerar inte korrekt. Dessutom kan den här konfigurationen resultera i fel när du skapar SMB- och CIFS-volymer om de försöker nå DNS via nätverkstopologin hub-and-spoke.

Vi rekommenderar också att storleken på det delegerade undernätet är minst /25 för SAP-arbetsbelastningar och /26 för andra arbetsbelastningsscenarier.

UDF:er och NSG:er

Om undernätet har en kombination av volymer med standard- och basicnätverksfunktionerna gäller användardefinierade vägar (UDR) och nätverkssäkerhetsgrupper (NSG:er) som tillämpas på de delegerade undernäten endast för volymerna med standardnätverksfunktionerna.

Kommentar

Det går inte att associera NSG:er på nätverksgränssnittsnivå för Azure NetApp Files-nätverksgränssnitten.

Det går inte att konfigurera UDR på undernäten för den virtuella källdatorn med adressprefixet för delegerat undernät och nästa hopp som NVA för volymer med grundläggande nätverksfunktioner. En sådan inställning resulterar i anslutningsproblem.

Kommentar

Om du vill komma åt en Azure NetApp Files-volym från ett lokalt nätverk via en VNet-gateway (ExpressRoute eller VPN) och en brandvägg konfigurerar du routningstabellen som tilldelats den virtuella nätverksgatewayen så att den /32 innehåller IPv4-adressen för Azure NetApp Files-volymen som anges och pekar på brandväggen som nästa hopp. Om du använder ett aggregerat adressutrymme som innehåller Azure NetApp Files-volymens IP-adress vidarebefordras inte Azure NetApp Files-trafiken till brandväggen.

Kommentar

Om du vill konfigurera en UDR-väg i det virtuella virtuella datornätverket måste UDR-prefixet vara mer specifikt eller lika med den delegerade undernätsstorleken för Azure NetApp Files-volymen för att kunna styra routningen av paket som är avsedda för en regionalT VNet-peered Azure NetApp Files-standardvolym. Om UDR-prefixet är större än den delegerade undernätsstorleken är det inte effektivt.

Inbyggda Azure-miljöer

Följande diagram illustrerar en Azure-intern miljö:

Diagram som visar konfigurationen av den inbyggda Azure-miljön.

Lokalt virtuellt nätverk

Ett grundläggande scenario är att skapa eller ansluta till en Azure NetApp Files-volym från en virtuell dator i samma virtuella nätverk. För VNet 2 i diagrammet skapas volym 1 i ett delegerat undernät och kan monteras på VM 1 i standardundernätet.

VNet-peering

Om du har andra virtuella nätverk i samma region som behöver åtkomst till varandras resurser kan de virtuella nätverken anslutas med VNet-peering för att aktivera säker anslutning via Azure-infrastrukturen.

Överväg VNet 2 och VNet 3 i diagrammet ovan. Om vm 1 behöver ansluta till vm 2 eller volym 2, eller om vm 2 behöver ansluta till vm 1 eller volym 1, måste du aktivera VNet-peering mellan VNet 2 och VNet 3.

Tänk dig också ett scenario där VNet 1 är peerkopplat med VNet 2 och VNet 2 peerkopplas med VNet 3 i samma region. Resurserna från VNet 1 kan ansluta till resurser i VNet 2 men kan inte ansluta till resurser i VNet 3 om inte VNet 1 och VNet 3 är peer-kopplade.

I diagrammet ovan, även om VM 3 kan ansluta till volym 1, kan vm 4 inte ansluta till volym 2. Anledningen till detta är att de virtuella ekernätverken inte är peer-kopplade och att överföringsroutning inte stöds via VNet-peering.

Global eller regionöverskridande VNet-peering

Följande diagram illustrerar en Azure-intern miljö med VNet-peering mellan regioner.

Diagram som visar konfigurationen av den inbyggda Azure-miljön med VNet-peering mellan regioner.

Med standardnätverksfunktioner kan virtuella datorer ansluta till volymer i en annan region via global eller regionöverskridande VNet-peering. Diagrammet ovan lägger till en andra region i konfigurationen i det lokala VNet-peeringavsnittet. För VNet 4 i det här diagrammet skapas en Azure NetApp Files-volym i ett delegerat undernät och kan monteras på VM5 i programundernätet.

I diagrammet kan VM2 i region 1 ansluta till volym 3 i region 2. VM5 i region 2 kan ansluta till volym 2 i region 1 via VNet-peering mellan region 1 och region 2.

Hybridmiljöer

Följande diagram illustrerar en hybridmiljö:

Diagram som visar hybridnätverksmiljön.

I hybridscenariot behöver program från lokala datacenter åtkomst till resurserna i Azure. Detta gäller oavsett om du vill utöka ditt datacenter till Azure eller om du vill använda inbyggda Azure-tjänster eller för haveriberedskap. Se Planeringsalternativ för VPN Gateway för information om hur du ansluter flera resurser lokalt till resurser i Azure via ett plats-till-plats-VPN eller en ExpressRoute.

I en hybridhubb-ekertopologi fungerar det virtuella hubbnätverket i Azure som en central anslutningspunkt till ditt lokala nätverk. Ekrarna är virtuella nätverk som är peerkopplade med hubben och de kan användas för att isolera arbetsbelastningar.

Beroende på konfigurationen kan du ansluta lokala resurser till resurser i hubben och ekrarna.

I topologin som illustreras ovan är det lokala nätverket anslutet till ett virtuellt hubbnätverk i Azure och det finns två virtuella ekernätverk i samma region som är peerkopplade med det virtuella hubbnätverket. I det här scenariot är de anslutningsalternativ som stöds för Azure NetApp Files-volymer följande:

  • Lokala resurser VM 1 och VM 2 kan ansluta till volym 1 i hubben via en plats-till-plats-VPN- eller ExpressRoute-krets.
  • Lokala resurser VM 1 och VM 2 kan ansluta till volym 2 eller volym 3 via en plats-till-plats-VPN och regional VNet-peering.
  • VM 3 i det virtuella hubbnätverket kan ansluta till volym 2 i eker-VNet 1 och Volym 3 i eker-VNet 2.
  • VM 4 från eker-VNet 1 och VM 5 från eker-VNet 2 kan ansluta till volym 1 i det virtuella hubbnätverket.
  • Vm 4 i eker-VNet 1 kan inte ansluta till volym 3 i eker-VNet 2. Vm 5 i eker-VNet2 kan inte heller ansluta till volym 2 i eker-VNet 1. Så är fallet eftersom de virtuella ekernätverken inte är peer-kopplade och överföringsdirigering inte stöds via VNet-peering.
  • I arkitekturen ovan går anslutningen till ANF-volymen från lokal anslutning via gatewayen i hubben förlorad om det finns en gateway i det virtuella ekernätverket. Enligt design skulle gatewayen i det virtuella ekernätverket prioriteras, så att endast datorer som ansluter via den gatewayen kan ansluta till ANF-volymen.

Nästa steg