Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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 (virtuellt nätverk) 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
Du kan skapa nya volymer eller ändra befintliga volymer så att de använder Standard - eller Basic-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.
Begränsningar
Viktigt!
Ökningar av routningsgränsen för grundläggande nätverksfunktioner godkänns inte längre efter den 30 maj 2025. För att undvika problem med routningsbegränsning bör du ändra dina volymer så att de använder standardnätverksfunktioner.
I följande tabell beskrivs vad som stöds för varje konfiguration av nätverksfunktioner:
| Egenskaper | Standardnätverksfunktioner | Grundläggande nätverksfunktioner |
|---|---|---|
| Antal IP-adresser i ett virtuellt nätverk (inklusive direkt anslutna virtuella nätverk) som har åtkomst till volymer i ett Azure NetApp Files-värdnätverk. | Samma standardgränser som virtuella datorer | 1 000 |
| Azure NetApp Files delegerade subnät per VNet | 1 | 1 |
| Nätverkssäkerhetsgrupper (NSG:er) i Azure NetApp Files delegerade undernät | Ja | Nej |
| NSG-stöd för privata slutpunkter | Ja | Nej |
| Användardefinierade vägar (UDR) på azure NetApp Files-delegerade undernät | Ja | Nej |
| Anslutning till privata slutpunkter | Ja | Nej |
| Anslutning till 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 sammankopplat VNet | Ja | Nej |
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 |
|---|---|---|
| Anslutning till volymen i ett lokalt virtuellt nätverk | Ja | Ja |
| Anslutning till volym i ett peerat virtuellt nätverk (i samma region) | Ja | Ja |
| Anslutning till volym i ett peer-kopplat virtuellt nätverk (peer-koppling över regioner eller globalt) | Ja* | Nej |
| Anslutning till en volym via ExpressRoute-gateway | Ja | Ja |
| ExpressRoute (ER) FastPath | Ja | Nej |
| Anslutning från lokala miljöer till en volym i ett underordnat VNet via ExpressRoute-gateway och VNet-peering med gateway-transit | Ja | Ja |
| Anslutning från en lokal miljö till en volym i ett Spoke VNet via en VPN-gateway | Ja | Ja |
| Anslutning från lokal miljö till en volym i ett stjärn-VNet via VPN-gateway och VNet-peering med gatewayövergång | Ja | Ja |
| Anslutning via aktiva/passiva VPN-gatewayer | Ja | Ja |
| Anslutning via aktiva/aktiva VPN-gatewayer | Ja | Nej |
| Anslutning via aktiva/aktiva zonredundanta gatewayer | Ja | Nej |
| Anslutning via aktiva/passiva zonredundanta gatewayer | Ja | Ja |
| Anslutning via 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 är delegerat 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.
Anmärkning
Vi rekommenderar att storleken på det delegerade undernätet är minst /25 för SAP-arbetsbelastningar och /26 för andra arbetsbelastningsscenarier.
Användardefinierade vägar (UDR) och nätverkssäkerhetsgrupper (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.
Anmärkning
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:er på källdatorns virtuella undernät med adressprefixet för delegerat undernät och NVA som nästa hopp för volymer med grundläggande nätverksfunktioner. En sådan inställning resulterar i anslutningsproblem.
Anmärkning
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.
Anmärkning
Om du vill konfigurera en routningstabell (UDR-väg) för att styra routningen av paket via en virtuell nätverksinstallation eller brandvägg som är avsedd för en Azure NetApp Files-standardvolym från en källa i samma virtuella nätverk eller ett peer-kopplat VNet, måste UDR-prefixet vara mer specifikt eller lika med den delegerade undernätsstorleken för Azure NetApp Files-volymen. Om UDR-prefixet är mindre specifikt än den delegerade undernätsstorleken är det inte effektivt.
Om ditt delegerade undernät till exempel är x.x.x.x/24måste du konfigurera din UDR till x.x.x.x/24 (lika) eller x.x.x.x/32 (mer specifik). Om du konfigurerar UDR-vägen till x.x.x.x/16kan odefinierade beteenden som asymmetrisk routning orsaka ett nätverksfall i brandväggen.
Inbyggda Azure-miljöer
Följande diagram illustrerar en Azure-intern miljö:
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.
Nätverkskoppling (VNet-peering)
Om du har andra virtuella nätverk i samma region som krä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.
Globala eller regionöverskridande VNet-nätverkskopplingar
Följande diagram illustrerar en Azure-intern miljö 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ö:
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 hybrid hub-spoke-topologi fungerar det virtuella hubbnätverket i Azure som en central anslutningspunkt till ditt lokala nätverk. Ekrarna är virtuella nätverk som är sammankopplade med hubben och de kan användas för att isolera arbetslaster.
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 hubnätverk i Azure, och det finns två sticknätverk i samma region som är ihopkopplade med hubnä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 ekernätverk 1 och Volym 3 i ekernätverk 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 spoke-VNet 1 kan inte ansluta till Volym 3 i spoke-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, om det även finns en gateway i det virtuella ekernätverket, kommer anslutningen från lokala resurser till ANF-volymer via gatewayen i hubben att förloras. Enligt design skulle gatewayen i spoke VNet prioriteras, så att endast datorer som ansluter via den gatewayen kan ansluta till ANF-volymen.