Richtlinien für die Azure NetApp Files-Netzwerkplanung
Die Planung der Netzwerkarchitektur ist ein Schlüsselelement beim Entwerfen von Anwendungsinfrastrukturen. Dieser Artikel hilft Ihnen, eine effektive Netzwerkarchitektur für Ihre Workloads zu entwickeln, um von den umfangreichen Möglichkeiten von Azure NetApp Files zu profitieren.
Azure NetApp Files-Volumes sind so konzipiert, dass sie in einem speziellen Subnetz, das als delegiertes Subnetz bezeichnet wird, innerhalb Ihrer Azure Virtual Network-Instanz enthalten sind. Daher können Sie bei Bedarf direkt aus Azure per Peering des virtuellen Netzwerks (VNet) oder aus der lokalen Umgebung über ein Gateway für virtuelle Netzwerke (ExpressRoute oder VPN Gateway) auf die Volumes zugreifen. Das Subnetz ist Azure NetApp Files dediziert zugeordnet, und es besteht keine Verbindung mit dem Internet.
Die Option zum Festlegen von Standardnetzwerkfunktionen für neue Volumes und zum Ändern von Netzwerkfunktionen für vorhandene Volumes wird in allen Azure NetApp Files-Regionen unterstützt.
Konfigurierbare Netzwerkfeatures
Sie können neue Volumes erstellen oder vorhandene Volumes ändern, um Netzwerkfeatures vom Typ Standard oder Basic zu verwenden. Weitere Informationen finden Sie unter Konfigurieren von Netzwerkfeatures für ein Azure NetApp Files-Volume.
Standard
Bei Auswahl dieser Einstellung können Sie höhere Grenzwerte für IP-Adressen und VNET-Standardfeatures nutzen, z. B. Netzwerksicherheitsgruppen und benutzerdefinierte Routen in delegierten Subnetzen, sowie zusätzliche Konnektivitätsmuster (wie in diesem Artikel beschrieben).Grundlegend
Bei Auswahl dieser Einstellung können Sie bestimmte Konnektivitätsmuster und einen eingeschränkten IP-Adressbereich nutzen. Dies ist im Abschnitt Überlegungen beschrieben. Bei dieser Einstellung gelten alle Einschränkungen.
Überlegungen
Zum Planen eines Azure NetApp Files-Netzwerks müssen Sie zunächst verschiedene Aspekte verstehen.
Einschränkungen
In der folgenden Tabelle ist beschrieben, was für die einzelnen Konfigurationen der Netzwerkfeatures jeweils unterstützt wird:
| Features | Standard-Netzwerkfeatures | Basic-Netzwerkfeatures |
|---|---|---|
| Anzahl verwendeter IP-Adressen innerhalb eines VNet (einschließlich VNets mit sofortigem Peering), die auf Volumes in einem VNet mit Azure NetApp Files-Hosting zugreifen | Gleiche Standardgrenzwerte wie virtuelle Computer (VMs) | 1.000 |
| Delegierte Azure NetApp Files-Subnetze pro VNet | 1 | 1 |
| Netzwerksicherheitsgruppen (NSGs) in delegierten Azure NetApp Files-Subnetzen | Ja | Nein |
| Benutzerdefinierte Routen (User-Defined Routes, UDRs) in delegierten Azure NetApp Files-Subnetzen | Ja | Nein |
| Verbindung mit privaten Endpunkten | Ja* | Nein |
| Verbindung mit Dienstendpunkten | Ja | Nein |
| Azure-Richtlinien (z. B. benutzerdefinierte Benennungsrichtlinien) für die Azure NetApp Files-Schnittstelle | Nein | Nein |
| Lastenausgleichsmodule für Azure NetApp Files-Datenverkehr | Nein | Nein |
| VNET mit dualem Stapel (IPv4 und IPv6) | Ohne (nur IPv4 wird unterstützt) |
Ohne (nur IPv4 wird unterstützt) |
| Datenverkehr, der über NVA von peered VNet weitergeleitet wird | Ja | Nein |
* Das Anwenden von Azure-Netzwerksicherheitsgruppen im Subnetz der privaten Verbindung auf Azure Key Vault wird für von Kunden verwaltete Azure NetApp Files-Schlüssel nicht unterstützt. Netzwerksicherheitsgruppen wirken sich nicht auf die Konnektivität mit Private Link aus, es sei denn, die Netzwerkrichtlinie für private Endpunkte ist im Subnetz aktiviert. Es wird empfohlen, diese Option deaktiviert zu lassen.
Unterstützte Netzwerktopologien
In der folgenden Tabelle sind die Netzwerktopologien beschrieben, die von den einzelnen Konfigurationen der Netzwerkfeatures von Azure NetApp Files unterstützt werden.
| Topologien | Standard-Netzwerkfeatures | Basic-Netzwerkfeatures |
|---|---|---|
| Verbindung mit Volume in einem lokalen VNET | Ja | Ja |
| Verbindung mit Volume in einem mittels Peering verknüpften VNET (in derselben Region) | Ja | Ja |
| Verbindung mit Volume in einem mittels Peering verknüpften VNET (regionsübergreifend oder globales Peering) | Ja* | Nein |
| Verbindung mit einem Volume über ExpressRoute-Gateway | Ja | Ja |
| ExpressRoute (ER) FastPath | Ja | Nein |
| Verbindung einer lokalen Umgebung mit einem Volume in einem Spoke-VNet über ExpressRoute-Gateway und VNet-Peering mit Gatewaytransit | Ja | Ja |
| Verbindung einer lokalen Umgebung mit einem Volume in einem Spoke-VNet über VPN-Gateway | Ja | Ja |
| Verbindung einer lokalen Umgebung mit einem Volume in einem Spoke-VNet über VPN-Gateway und VNet-Peering mit Gatewaytransit | Ja | Ja |
| Verbindung über Aktiv/Passiv-VPN-Gateways | Ja | Ja |
| Verbindung über Aktiv/Aktiv-VPN-Gateways | Ja | Nein |
| Verbindung über zonenredundante Aktiv/Aktiv-Gateways | Ja | Nein |
| Verbindung über zonenredundante Aktiv/Passiv-Gateways | Ja | Ja |
| Verbindung über Virtual WAN (vWAN) | Ja | Nein |
* Mit dieser Option fällt eine Gebühr für ein- und ausgehenden Datenverkehr an, der eine Verbindung für das Peering virtueller Netzwerke verwendet. Weitere Informationen finden Sie unter Virtual Network – Preise. Weitere Informationen finden Sie unter Peering virtueller Netzwerke.
Virtuelles Netzwerk für Azure NetApp Files-Volumes
In diesem Abschnitt werden Konzepte erläutert, die Ihnen bei der Planung virtueller Netzwerke helfen.
Virtuelle Azure-Netzwerke
Bevor Sie ein Azure NetApp Files-Volume bereitstellen, müssen Sie ein virtuelles Azure-Netzwerk (VNet) erstellen oder eines verwenden, das bereits im selben Abonnement vorhanden ist. Das VNET definiert die Netzwerkgrenze des Volumes. Weitere Informationen zum Erstellen virtueller Netzwerke finden Sie in der Azure Virtual Network-Dokumentation.
Subnetze
Subnetze unterteilen das virtuelle Netzwerk in getrennte Adressräume, die von den darin enthaltenen Azure-Ressourcen verwendet werden können. Azure NetApp Files-Volumes sind in einem speziellen Subnetz enthalten, das als delegiertes Subnetz bezeichnet wird.
Bei der Subnetzdelegierung erhält der Azure NetApp Files-Dienst explizite Berechtigungen, um dienstspezifische Ressourcen im Subnetz zu erstellen. Bei der Bereitstellung des Diensts wird ein eindeutiger Bezeichner verwendet. In diesem Fall wird eine Netzwerkschnittstelle erstellt, um die Verbindung mit Azure NetApp Files zu ermöglichen.
Wenn Sie ein neues VNET verwenden, können Sie ein Subnetz erstellen und das Subnetz an Azure NetApp Files delegieren, indem Sie den Anweisungen unter Delegieren eines Subnetz an Azure NetApp Files folgen. Sie können außerdem ein bestehendes leeres Subnetz delegieren, das noch nicht an andere Dienste delegiert ist.
Wenn das VNet per Peering mit einem anderen VNet verknüpft ist, können Sie den VNET-Adressraum nicht erweitern. Aus diesem Grund muss das neue delegierte Subnetz innerhalb des VNET-Adressraums eingerichtet werden. Wenn Sie den Adressraum erweitern möchten, müssen Sie das VNET-Peering löschen, ehe Sie den Adressraum erweitern.
Wichtig
Stellen Sie sicher, dass die Größe des Adressraums des VNet für Azure NetApp-Dateien größer als das delegierte Subnetz ist.
Wenn das delegierte Subnetz z. B. "/24" lautet, muss der VNet-Adressraum, der das Subnetz enthält, "/23" oder "größer" sein. Nichtkompatibilität mit dieser Richtlinie kann zu unerwarteten Problemen in einigen Datenverkehrsmustern führen: Datenverkehr, der eine Hub-and-Spoke-Topologie durchläuft, die Azure NetApp-Dateien über eine virtuelle Netzwerk-Appliance erreicht, funktioniert nicht ordnungsgemäß. Darüber hinaus kann diese Konfiguration zu Fehlern beim Erstellen von SMB- und CIFS (Common Internet File System)-Volumes führen, wenn sie versuchen, DNS über die Hub-and-Spoke-Netzwerktopologie zu erreichen.
Es wird auch empfohlen, die Größe des delegierten Subnetzes mindestens /25 für SAP-Workloads und /26 für andere Workloadszenarien zu haben.
Benutzerdefinierte Routen (UDRs) und Netzwerksicherheitsgruppen (NSGs)
Wenn das Subnetz über eine Kombination aus Volumes mit den Standard- und Basic-Netzwerkfeatures verfügt, gelten die auf die delegierten Subnetze angewendeten benutzerdefinierten Routen (UDRs) und Netzwerksicherheitsgruppen (NSGs) nur für die Volumes mit den Standard-Netzwerkfeatures.
Hinweis
Die Zuordnung von NSGs auf Netzwerkschnittstellenebene wird für die Azure NetApp Files-Netzwerkschnittstellen nicht unterstützt.
Das Konfigurieren von UDRs in den Subnetzen der Quell-VM mit dem Adresspräfix des delegierten Subnetzes und „NVA“ als nächstem Hop wird für Volumes mit Basic-Netzwerkfeatures nicht unterstützt. Eine Einstellung dieser Art führt zu Konnektivitätsproblemen.
Hinweis
Um aus einem lokalen Netzwerk über ein VNet-Gateway (ExpressRoute oder VPN) und eine Firewall auf ein Azure NetApp Files-Volume zuzugreifen, konfigurieren Sie dem VNet-Gateway zugewiesene Routingtabelle so, dass die /32 IPv4-Adresse des aufgelisteten Azure NetApp Files-Volumes eingeschlossen und auf die Firewall als nächster Hop verwiesen wird. Wenn Sie einen aggregierten Adressraum verwenden, der die IP-Adresse des Azure NetApp Files-Volumes enthält, wird der Azure NetApp Files-Datenverkehr nicht an die Firewall weitergeleitet.
Hinweis
Wenn Sie eine Routingtabelle (UDR-Route) konfigurieren möchten, um das Routing von Paketen durch ein virtuelles Netzwerkgerät oder eine Firewall zu steuern, die an ein Azure NetApp Files-Standardvolumen von einer Quelle im selben VNet oder einem VNet mit Peering gerichtet ist, muss das UDR-Präfix spezifischer oder gleich der delegierten Subnetzgröße des Azure NetApp Files-Volumens sein. Wenn das UDR-Präfix weniger spezifisch als die delegierte Subnetzgröße ist, ist es nicht effektiv.
Wenn Ihr delegiertes Subnetz beispielsweise x.x.x.x/24 lautet, müssen Sie Ihren UDR auf x.x.x.x/24 (gleich) oder x.x.x.x/32 (spezifischer) konfigurieren. Wenn Sie die UDR-Route auf x.x.x.x/16 konfigurieren, können nicht definierte Verhaltensweisen wie asymmetrisches Routing zu einem Netzwerkabbruch in der Firewall führen.
Native Azure-Umgebungen
Das folgende Diagramm veranschaulicht eine native Azure-Umgebung:
Lokales VNET
Ein einfaches Szenario ist das Erstellen oder Verbinden mit einem Azure NetApp Files-Volume auf einem virtuellen Computer im selben VNET. Für VNet 2 im Diagramm wird Volume 1 in einem delegierten Subnetz erstellt und kann auf VM 1 im Standardsubnetz eingebunden werden.
VNet-Peering
Wenn Sie andere VNets in derselben Region haben, die Zugriff auf die Ressourcen des jeweils anderen benötigen, können die VNets über das Peering virtueller Netzwerke verbunden werden, um über die Azure-Infrastruktur eine sichere Verbindung zu ermöglichen.
Sehen Sie sich VNET 2 und VNET 3 im obigen Diagramm an. Wenn VM 1 eine Verbindung mit VM 2 oder Volume 2 herstellen muss oder VM 2 eine Verbindung mit VM 1 oder Volume 1 herstellen muss, müssen Sie VNET-Peering zwischen VNET 2 und VNET 3 aktivieren.
Ein weiteres Beispiel ist ein Szenario, bei dem VNet 1 per Peering mit VNet 2 und VNet 2 per Peering mit VNet 3 in der gleichen Region verknüpft ist. Die Ressourcen in VNet 1 können eine Verbindung mit Ressourcen in VNet 2 herstellen, aber sie können keine Verbindung mit Ressourcen in VNet 3 herstellen – es sei denn, VNet 1 und VNet 3 werden mittels Peering verknüpft.
Im obigen Diagramm kann VM 3 zwar eine Verbindung mit Volume 1 herstellen, VM 4 jedoch keine Verbindung mit Volume 2. Der Grund dafür ist, dass die Spoke-VNets nicht per Peering verknüpft sind und Transitrouting über VNET-Peering nicht unterstützt wird.
Globales oder regionsübergreifendes VNet-Peering
Im folgenden Diagramm wird eine native Azure-Umgebung mit regionsübergreifendem VNet-Peering dargestellt.
Mit den Standardnetzwerkfeatures können VMs über globale oder regionsübergreifende VNet-Peerings eine Verbindung mit Volumes in einer anderen Region herstellen. Im obigen Diagramm wird der Konfiguration im lokalen VNet-Peering-Abschnitt eine zweite Region hinzugefügt. Für VNet 4 in diesem Diagramm wird ein Azure NetApp Files-Volume in einem delegierten Subnetz erstellt, das auf VM5 im Anwendungsnetz bereitgestellt werden kann.
Im Diagramm kann VM2 in Region 1 eine Verbindung mit Volume 3 in Region 2 herstellen. VM5 in Region 2 kann eine Verbindung mit Volume 2 in Region 1 über ein VNet-Peering zwischen Region 1 und Region 2 herstellen.
Hybridumgebungen
Das folgende Diagramm veranschaulicht eine Hybridumgebung:
Im Hybridszenario benötigen Anwendungen aus lokalen Datencentern Zugriff auf die Ressourcen in Azure. Dies ist der Fall, wenn Sie Ihr Rechenzentrum auf Azure ausweiten oder für die Notfallwiederherstellung native Azure-Dienste nutzen möchten. Unter Planungsoptionen für VPN Gateway finden Sie Informationen dazu, wie Sie mehrere lokale Ressourcen über ein Site-to-Site-VPN oder eine ExpressRoute-Verbindung mit Ressourcen in Azure verbinden.
In einer hybriden Hub-Spoke-Topologie fungiert das Hub-VNET in Azure als zentraler Verbindungspunkt für Ihr lokales Netzwerk. Die Spokes sind VNETs, die per Peering mit dem Hub verknüpft sind und zur Isolierung von Workloads verwendet werden können.
Abhängig von der Konfiguration können Sie lokale Ressourcen mit Ressourcen im Hub und auf den Spokes verbinden.
In der oben dargestellten Topologie ist das lokale Netzwerk mit einem Hub-VNET in Azure verbunden, und es gibt zwei Spoke-VNETs in derselben Region, die per Peering mit dem Hub-VNet verbunden sind. In diesem Szenario werden folgende Verbindungsoptionen für Azure NetApp Files-Volumes unterstützt:
- Lokale Ressourcen auf VM 1 und VM 2 können sich über ein Site-to-Site-VPN oder eine ExpressRoute-Verbindung mit Volume 1 im Hub verbinden.
- Lokale Ressourcen auf VM 1 und VM 2 können über ein Site-to-Site-VPN oder regionales VNET-Peering eine Verbindung mit Volume 2 oder 3 herstellen.
- VM 3 im Hub-VNET kann sich mit Volume 2 in Spoke-VNET 1 und Volume 3 in Spoke-VNET 2 verbinden.
- VM 4 in Spoke-VNET 1 und VM 5 in Spoke-VNET 2 können sich mit Volume 1 im Hub-VNET verbinden.
- VM 4 im Spoke-VNET 1 kann keine Verbindung mit Volume 3 im Spoke-VNET 2 herstellen. Auch VM 5 im Spoke-VNET 2 kann keine Verbindung mit Volume 2 im Spoke-VNET 1 herstellen. Der Grund dafür ist, dass die Spoke-VNets nicht per Peering verknüpft sind und Transitrouting über VNET-Peering nicht unterstützt wird.
- Wenn es im Spoke-VNet ebenfalls ein Gateway gibt, geht die Konnektivität mit dem ANF-Volume von einer lokalen Ressource über die Verbindung über das Gateway im Hub in der obigen Architektur verloren. Entwurfsgemäß würde das Gateway im Spoke-VNet bevorzugt, sodass nur Computer, die eine Verbindung über dieses Gateway herstellen, eine Verbindung mit dem ANF-Volume herstellen können.
Nächste Schritte
- Delegieren eines Subnetzes für Azure NetApp Files
- Konfigurieren von Netzwerkfeatures für ein Azure NetApp Files-Volume
- Peering in virtuellen Netzwerken
- Konfigurieren von Virtual WAN für Azure NetApp Files
- Azure NetApp Files-Speicher mit kalter Zugriffsebene
- Verwalten des Azure NetApp Files-Speichers mit kalter Zugriffsebene