Richtlijnen voor Azure NetApp Files-netwerkplanning
Netwerkarchitectuurplanning is een belangrijk element van het ontwerpen van elke toepassingsinfrastructuur. Dit artikel helpt u bij het ontwerpen van een effectieve netwerkarchitectuur voor uw workloads om te profiteren van de uitgebreide mogelijkheden van Azure NetApp Files.
Azure NetApp Files-volumes zijn ontworpen om te worden opgenomen in een subnet voor speciale doeleinden, een gedelegeerd subnet in uw Virtuele Azure-netwerk. Daarom hebt u rechtstreeks toegang tot de volumes vanuit Azure via VNet-peering (virtual network) of on-premises via een virtuele netwerkgateway (ExpressRoute of VPN Gateway). Het subnet is toegewezen aan Azure NetApp Files en er is geen verbinding met internet.
De optie voor het instellen van standaardnetwerkfuncties op nieuwe volumes en het wijzigen van netwerkfuncties voor bestaande volumes wordt ondersteund in alle azure NetApp Files-regio's.
Configureerbare netwerkfuncties
In ondersteunde regio's kunt u nieuwe volumes maken of bestaande volumes wijzigen om standaard- of basisnetwerkfuncties te gebruiken. In regio's waar de standaardnetwerkfuncties niet worden ondersteund, wordt het volume standaard ingesteld op het gebruik van de basisnetwerkfuncties. Zie Netwerkfuncties configureren voor meer informatie.
Standaard
Als u deze instelling selecteert, worden hogere IP-limieten en standaard-VNet-functies zoals netwerkbeveiligingsgroepen en door de gebruiker gedefinieerde routes voor gedelegeerde subnetten en aanvullende verbindingspatronen ingeschakeld, zoals aangegeven in dit artikel.Basic
Als u deze instelling selecteert, worden selectieve verbindingspatronen en beperkte IP-schaal ingeschakeld, zoals vermeld in de sectie Overwegingen . Alle beperkingen zijn van toepassing op deze instelling.
Overwegingen
U moet enkele overwegingen begrijpen wanneer u een Azure NetApp Files-netwerk plant.
Beperkingen
In de volgende tabel wordt beschreven wat wordt ondersteund voor elke configuratie van netwerkfuncties:
| Functies | Standaardnetwerkfuncties | Basisnetwerkfuncties |
|---|---|---|
| Aantal IP-adressen in een VNet (inclusief onmiddellijk gekoppelde VNets) die toegang hebben tot volumes in een Azure NetApp Files die als host fungeren voor VNet | Dezelfde standaardlimieten als virtuele machines (VM's) | 1000 |
| Gedelegeerde Azure NetApp Files-subnetten per VNet | 1 | 1 |
| Netwerkbeveiligingsgroepen (NSG's) in gedelegeerde subnetten van Azure NetApp Files | Ja | Nr. |
| Door de gebruiker gedefinieerde routes (UDR's) in gedelegeerde subnetten van Azure NetApp Files | Ja | Nr. |
| Connectiviteit met privé-eindpunten | Ja* | Nee |
| Connectiviteit met service-eindpunten | Ja | Nr. |
| Azure-beleid (bijvoorbeeld aangepaste naamgevingsbeleid) in de Interface van Azure NetApp Files | Nee | Nr. |
| Load balancers voor Azure NetApp Files-verkeer | Nee | Nr. |
| VNet met dubbele stack (IPv4 en IPv6) | Nee (IPv4 wordt alleen ondersteund) |
Nee (IPv4 wordt alleen ondersteund) |
| Verkeer dat wordt gerouteerd via NVA vanuit een gekoppeld VNet | Ja | Nr. |
* Het toepassen van Azure-netwerkbeveiligingsgroepen op het subnet private link op Azure Key Vault wordt niet ondersteund voor door de klant beheerde Azure NetApp Files-sleutels. Netwerkbeveiligingsgroepen hebben geen invloed op de connectiviteit met Private Link, tenzij netwerkbeleid voor privé-eindpunten is ingeschakeld op het subnet. Het is raadzaam deze optie uitgeschakeld te houden.
Ondersteunde netwerktopologieën
In de volgende tabel worden de netwerktopologieën beschreven die worden ondersteund door elke netwerkfunctiesconfiguratie van Azure NetApp Files.
| Topologieën | Standaardnetwerkfuncties | Basisnetwerkfuncties |
|---|---|---|
| Connectiviteit met volume in een lokaal VNet | Ja | Ja |
| Connectiviteit met volume in een gekoppeld VNet (dezelfde regio) | Ja | Ja |
| Connectiviteit met volume in een gekoppeld VNet (meerdere regio's of wereldwijde peering) | Ja* | Nee |
| Connectiviteit met een volume via ExpressRoute-gateway | Ja | Ja |
| ExpressRoute (ER) FastPath | Ja | Nr. |
| Connectiviteit van on-premises naar een volume in een spoke-VNet via ExpressRoute-gateway en VNet-peering met gatewayoverdracht | Ja | Ja |
| Connectiviteit van on-premises naar een volume in een spoke-VNet via VPN-gateway | Ja | Ja |
| Connectiviteit van on-premises naar een volume in een spoke-VNet via VPN-gateway en VNet-peering met gatewayoverdracht | Ja | Ja |
| Connectiviteit via actieve/passieve VPN-gateways | Ja | Ja |
| Connectiviteit via Active/Active VPN-gateways | Ja | Nr. |
| Connectiviteit via actieve/actieve zone-redundante gateways | Ja | Nr. |
| Connectiviteit via actieve/passieve zone-redundante gateways | Ja | Ja |
| Connectiviteit via Virtual WAN (VWAN) | Ja | Nr. |
* Met deze optie worden kosten in rekening gebracht voor inkomend en uitgaand verkeer dat gebruikmaakt van een peeringverbinding voor een virtueel netwerk. Zie Prijzen voor Virtual Network voor meer informatie. Zie Peering voor virtuele netwerken voor meer algemene informatie.
Virtueel netwerk voor Azure NetApp Files-volumes
In deze sectie worden concepten uitgelegd die u helpen bij het plannen van virtuele netwerken.
Virtuele netwerken van Azure
Voordat u een Azure NetApp Files-volume inricht, moet u een virtueel Azure-netwerk (VNet) maken of een netwerk gebruiken dat al bestaat in hetzelfde abonnement. Het VNet definieert de netwerkgrens van het volume. Zie de documentatie van Azure Virtual Network voor meer informatie over het maken van virtuele netwerken.
Subnetten
Subnetten segmenteren het virtuele netwerk in afzonderlijke adresruimten die kunnen worden gebruikt door de Azure-resources erin. Azure NetApp Files-volumes bevinden zich in een speciaal subnet dat een gedelegeerd subnet wordt genoemd.
Subnetdelegering geeft expliciete machtigingen voor de Azure NetApp Files-service om servicespecifieke resources in het subnet te maken. Er wordt een unieke id gebruikt voor het implementeren van de service. In dit geval wordt er een netwerkinterface gemaakt om connectiviteit met Azure NetApp Files mogelijk te maken.
Als u een nieuw VNet gebruikt, kunt u een subnet maken en het subnet delegeren naar Azure NetApp Files door de instructies te volgen in Een subnet delegeren aan Azure NetApp Files. U kunt ook een bestaand leeg subnet delegeren dat niet is gedelegeerd aan andere services.
Als het VNet is gekoppeld aan een ander VNet, kunt u de VNet-adresruimte niet uitbreiden. Daarom moet het nieuwe gedelegeerde subnet worden gemaakt binnen de VNet-adresruimte. Als u de adresruimte wilt uitbreiden, moet u de VNet-peering verwijderen voordat u de adresruimte uitbreidt.
Belangrijk
Zorg ervoor dat de adresruimte van het Azure NetApp Files-VNet groter is dan het gedelegeerde subnet.
Als het gedelegeerde subnet bijvoorbeeld /24 is, moet de VNet-adresruimte met het subnet /23 of groter zijn. Niet-naleving van deze richtlijn kan leiden tot onverwachte problemen in sommige verkeerspatronen: verkeer dat een hub-and-spoke-topologie doorkruist die Azure NetApp Files bereikt via een virtueel netwerkapparaat werkt niet goed. Daarnaast kan deze configuratie leiden tot fouten bij het maken van SMB- en CIFS-volumes (Common Internet File System) als ze proberen DNS te bereiken via hub-and-spoke-netwerktopologie.
Het wordt ook aanbevolen dat de grootte van het gedelegeerde subnet ten minste /25 is voor SAP-workloads en /26 voor andere workloadscenario's.
Door de gebruiker gedefinieerde routes (UDR's) en netwerkbeveiligingsgroepen (NSG's)
Als het subnet een combinatie van volumes heeft met de standaard- en basisnetwerkfuncties, zijn door de gebruiker gedefinieerde routes (UDR's) en netwerkbeveiligingsgroepen (NSG's) die zijn toegepast op de gedelegeerde subnetten alleen van toepassing op de volumes met de standaardnetwerkfuncties.
Notitie
Het koppelen van NSG's op netwerkinterfaceniveau wordt niet ondersteund voor de Netwerkinterfaces van Azure NetApp Files.
UDR's configureren op de bron-VM-subnetten met het adresvoorvoegsel van gedelegeerd subnet en volgende hop omdat NVA niet wordt ondersteund voor volumes met de basisnetwerkfuncties. Een dergelijke instelling leidt tot verbindingsproblemen.
Notitie
Als u toegang wilt krijgen tot een Azure NetApp Files-volume vanuit een on-premises netwerk via een VNet-gateway (ExpressRoute of VPN) en firewall, configureert u de routetabel die is toegewezen aan de VNet-gateway om het /32 IPv4-adres van het Azure NetApp Files-volume op te nemen dat wordt vermeld en verwijst u naar de firewall als de volgende hop. Als u een geaggregeerde adresruimte gebruikt die het IP-adres van het Azure NetApp Files-volume bevat, wordt het Verkeer van Azure NetApp Files niet doorgestuurd naar de firewall.
Notitie
Als u een UDR-route wilt configureren in het VNet van de VIRTUELE machine, moet het UDR-voorvoegsel specifieker of gelijk zijn aan de toegewezen subnetgrootte van het Azure NetApp Files-volume dat is bestemd voor een regionaal VNet-peeringvolume. Als het UDR-voorvoegsel groter is dan de grootte van het gedelegeerde subnet, is het niet effectief.
Systeemeigen Azure-omgevingen
In het volgende diagram ziet u een systeemeigen Azure-omgeving:
Lokaal VNet
Een basisscenario is het maken of verbinden met een Azure NetApp Files-volume vanaf een virtuele machine in hetzelfde VNet. Voor VNet 2 in het diagram wordt volume 1 gemaakt in een gedelegeerd subnet en kan worden gekoppeld op VM 1 in het standaardsubnet.
VNet-peering
Als u andere VNets in dezelfde regio hebt die toegang nodig hebben tot elkaars resources, kunnen de VNets worden verbonden met behulp van VNet-peering om beveiligde connectiviteit mogelijk te maken via de Azure-infrastructuur.
Overweeg VNet 2 en VNet 3 in het bovenstaande diagram. Als VM 1 verbinding moet maken met VM 2 of volume 2, of als VM 2 verbinding moet maken met VM 1 of volume 1, moet u VNet-peering tussen VNet 2 en VNet 3 inschakelen.
Overweeg ook een scenario waarin VNet 1 is gekoppeld aan VNet 2 en VNet 2 is gekoppeld aan VNet 3 in dezelfde regio. De resources van VNet 1 kunnen verbinding maken met resources in VNet 2, maar kunnen geen verbinding maken met resources in VNet 3, tenzij VNet 1 en VNet 3 zijn gekoppeld.
In het bovenstaande diagram, hoewel VM 3 verbinding kan maken met volume 1, kan VM 4 geen verbinding maken met volume 2. De reden hiervoor is dat de spoke-VNets niet zijn gekoppeld en dat transitroutering niet wordt ondersteund via VNet-peering.
Wereldwijde VNet-peering of VNet-peering tussen regio's
In het volgende diagram ziet u een systeemeigen Azure-omgeving met VNet-peering tussen regio's.
Met standaardnetwerkfuncties kunnen VM's verbinding maken met volumes in een andere regio via wereldwijde of VNet-peering tussen regio's. In het bovenstaande diagram wordt een tweede regio toegevoegd aan de configuratie in de sectie lokale VNet-peering. Voor VNet 4 in dit diagram wordt een Azure NetApp Files-volume gemaakt in een gedelegeerd subnet en kan worden gekoppeld op VM5 in het subnet van de toepassing.
In het diagram kan VM2 in regio 1 verbinding maken met volume 3 in regio 2. VM5 in regio 2 kan verbinding maken met volume 2 in regio 1 via VNet-peering tussen regio 1 en regio 2.
Hybride omgevingen
In het volgende diagram ziet u een hybride omgeving:
In het hybride scenario hebben toepassingen van on-premises datacenters toegang nodig tot de resources in Azure. Dit is het geval of u uw datacenter wilt uitbreiden naar Azure of dat u systeemeigen Azure-services of voor herstel na noodgevallen wilt gebruiken. Zie planningsopties voor VPN Gateway voor informatie over het on-premises verbinden van meerdere resources met resources in Azure via een site-naar-site-VPN of een ExpressRoute.
In een hybride stertopologie fungeert het hub-VNet in Azure als een centraal punt van connectiviteit met uw on-premises netwerk. De spokes zijn VNets die zijn gekoppeld aan de hub en kunnen worden gebruikt om workloads te isoleren.
Afhankelijk van de configuratie kunt u on-premises resources verbinden met resources in de hub en de spokes.
In de bovenstaande topologie is het on-premises netwerk verbonden met een hub-VNet in Azure en zijn er twee spoke-VNets in dezelfde regio die zijn gekoppeld aan het hub-VNet. In dit scenario zijn de connectiviteitsopties die worden ondersteund voor Azure NetApp Files-volumes als volgt:
- On-premises resources VM 1 en VM 2 kunnen verbinding maken met volume 1 in de hub via een site-naar-site-VPN- of ExpressRoute-circuit.
- On-premises resources VM 1 en VM 2 kunnen verbinding maken met volume 2 of volume 3 via een site-naar-site-VPN en regionale VNet-peering.
- VM 3 in het hub-VNet kan verbinding maken met Volume 2 in spoke VNet 1 en Volume 3 in spoke VNet 2.
- VM 4 van spoke VNet 1 en VM 5 van spoke VNet 2 kan verbinding maken met Volume 1 in het hub-VNet.
- VM 4 in spoke VNet 1 kan geen verbinding maken met volume 3 in spoke VNet 2. Vm 5 in spoke VNet2 kan ook geen verbinding maken met volume 2 in spoke-VNet 1. Dit is het geval omdat de spoke-VNets niet zijn gekoppeld en transitroutering niet wordt ondersteund via VNet-peering.
- In de bovenstaande architectuur als er ook een gateway in het spoke-VNet aanwezig is, gaat de verbinding met het ANF-volume van on-premises verbinding via de gateway in de hub verloren. Standaard wordt de voorkeur gegeven aan de gateway in het spoke-VNet, zodat alleen computers die verbinding maken via die gateway verbinding kunnen maken met het ANF-volume.