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 (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.
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 |
| 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 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 |
|---|---|---|
| Anslutning till volymen i ett lokalt virtuellt nätverk | Ja | Ja |
| Anslutning till volymen i ett peer-kopplat virtuellt nätverk (samma region) | Ja | Ja |
| Anslutning till volymen i ett peer-kopplat virtuellt nätverk (korsregion eller global peering) | Ja* | Nej |
| Anslutning till en volym via ExpressRoute-gateway | Ja | Ja |
| ExpressRoute (ER) FastPath | Ja | Nej |
| Anslutning från lokal till en volym i ett eker-VNet via ExpressRoute-gateway och VNet-peering med gatewayöverföring | Ja | Ja |
| Anslutning från lokal till en volym i ett eker-VNet via VPN-gateway | Ja | Ja |
| Anslutning från lokal till en volym i ett eker-VNet via VPN-gateway och VNet-peering med gatewayöverföring | 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 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 (Common Internet File System) 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.
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.
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ö:
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.
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 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.