Netzwerkkonfiguration
Änderungen vorschlagen
PDFs
Wenn Sie vSphere mit Systemen mit ONTAP verwenden, ist die Konfiguration von Netzwerkeinstellungen einfach und erfolgt ähnlich wie andere Netzwerkkonfigurationen.
Folgende Punkte sind dabei zu berücksichtigen:
-
Separater Storage-Netzwerk-Traffic aus anderen Netzwerken. Ein separates Netzwerk kann mithilfe eines dedizierten VLANs oder separater Switches für Storage eingerichtet werden. Falls im Storage-Netzwerk physische Pfade wie Uplinks geteilt werden, sind eventuell QoS oder zusätzliche Uplink-Ports erforderlich, um eine ausreichende Bandbreite sicherzustellen. Verbinden Sie Hosts nicht direkt mit Storage, es sei denn, Ihr Lösungsleitfaden fordert ausdrücklich darauf an. Verwenden Sie Switches mit redundanten Pfaden, und lassen Sie VMware HA ohne Eingriffe arbeiten.
-
Jumbo Frames sollten verwendet werden, wenn sie von Ihrem Netzwerk unterstützt werden. Vergewissern Sie sich bei ihrem Einsatz, dass sie auf allen Netzwerkgeräten, VLANs etc. Im Pfad zwischen Storage und dem ESXi Host gleich konfiguriert sind. Anderenfalls kann es zu Performance- oder Verbindungsproblemen kommen. Auf dem virtuellen ESXi Switch, dem VMkernel Port, sowie den physischen Ports oder den Interface Groups muss für jeden ONTAP Node auch jeweils dieselbe MTU festgelegt sein.
-
NetApp empfiehlt eine Deaktivierung der Netzwerk- Flusssteuerung nur an den Cluster-Interconnect-Ports innerhalb eines ONTAP Clusters. NetApp gibt im Hinblick auf Best Practices zur Flusskontrolle für die übrigen Netzwerkports, die für Daten-Traffic verwendet werden, keine weiteren Empfehlungen. Sie sollten diese Funktion nach Bedarf aktivieren oder deaktivieren. Weitere Informationen zur Flusssteuerung finden Sie unter "TR-4182".
-
Wenn ESXi und ONTAP Storage-Arrays mit Ethernet-Storage-Netzwerken verbunden werden, empfiehlt NetApp, die Ethernet-Ports, mit denen diese Systeme verbunden werden, mit der Cisco PortFast Funktion oder als Rapid Spanning Tree Protocol (RSTP)-Edge-Ports zu konfigurieren. NetApp empfiehlt die Aktivierung der Spanning Tree PortFast Trunk-Funktion in Umgebungen mit Verwendung der Cisco PortFast Funktion und 802.1Q VLAN-Trunking entweder für den ESXi Server oder für die ONTAP Storage-Arrays.
-
Für die Link-Aggregation empfiehlt NetApp die folgenden Best Practices:
-
Verwenden Sie Switches, die die Link-Aggregation von Ports in zwei separaten Switch-Chassis durch einen Ansatz mit einer Multi-Chassis-Link-Aggregationsgruppe wie Virtual PortChannel (vPC) von Cisco unterstützen.
-
Deaktivieren Sie LACP für mit ESXi verbundene Switch Ports, es sei denn, Sie verwenden dvSwitches ab 5.1 mit konfiguriertem LACP.
-
Erstellen Sie mit LACP Link-Aggregate für ONTAP Storage-Systeme mit dynamischen Multimode-Schnittstellengruppen mit IP-Hash.
-
Verwenden Sie eine IP-Hash-Teaming-Richtlinie für ESXi.
-
Die folgende Tabelle enthält eine Zusammenfassung der Netzwerkkonfigurationselemente sowie Angaben dazu, wo die Einstellungen angewendet werden.
| Element | ESXi | Switch | Knoten | SVM |
|---|---|---|---|---|
IP-Adresse |
VMkernel |
Nein** |
Nein** |
Ja. |
Link-Aggregation |
Virtueller Switch |
Ja. |
Ja. |
Nein* |
VLAN |
VMkernel und VM-Portgruppen |
Ja. |
Ja. |
Nein* |
Flusskontrolle |
NIC |
Ja. |
Ja. |
Nein* |
Spanning Tree |
Nein |
Ja. |
Nein |
Nein |
MTU (für Jumbo Frames) |
Virtueller Switch und VMkernel Port (9000) |
Ja (auf Maximalwert eingestellt) |
Ja (9000) |
Nein* |
Failover-Gruppen |
Nein |
Nein |
Ja (erstellen) |
Ja (auswählen) |
*SVM-LIFs werden mit Ports, Schnittstellengruppen oder VLAN-Schnittstellen verbunden, die über VLAN-, MTU- und andere Einstellungen verfügen. Diese Einstellungen werden jedoch nicht auf SVM-Ebene gemanagt.
**Diese Geräte haben eigene IP-Adressen für das Management, aber diese Adressen werden nicht im Zusammenhang mit ESXi Storage Networking verwendet.
SAN (FC, NVMe/FC, iSCSI, NVMe/TCP), RDM
ONTAP bietet Block-Storage der Enterprise-Klasse für VMware vSphere unter Verwendung des traditionellen iSCSI- und Fibre-Channel-Protokolls (FCP) sowie des hocheffizienten und performanten NVMe-of (Next-Generation Block-Protokoll), das sowohl NVMe/FC als auch NVMe/TCP unterstützt.
Detaillierte Best Practices zur Implementierung von Blockprotokollen für VM-Storage mit vSphere und ONTAP finden Sie unter "Datenspeicher und Protokolle – SAN"
NFS
Bei vSphere können Kunden mithilfe von NFS-Arrays der Enterprise-Klasse gleichzeitigen Zugriff auf Datastores auf allen Nodes in einem ESXi Cluster ermöglichen. Wie im Abschnitt erwähnt"Datenspeicher", gibt es bei der Verwendung von NFS mit vSphere einige Vorteile im Hinblick auf Benutzerfreundlichkeit, Storage-Effizienz und Sichtbarkeit.
Empfohlene Best Practices finden Sie in "Datenspeicher und Protokolle – NFS"
Direkte Netzwerkverbindung
Virtualisierungsadministratoren bevorzugen es mitunter, ihre Infrastrukturen zu vereinfachen, indem sie Netzwerk-Switches aus der Konfiguration entfernen. Dies ermöglicht die Erstellung einer stärker in sich geschlossenen Lösung mit weniger Komponenten und geringerem Platzbedarf im Rack. Es bestehen einige wichtige Einschränkungen, die vom verwendeten Protokoll abhängen.
Fibre Channel
Ab ONTAP 9.19.1 wird Direct-Connect FC sowohl mit herkömmlichem FC-SAN (SCSI) als auch mit NVMe/FC mit ausgewählten FC-Adaptern für Speichersysteme unterstützt. Die HBAs stellen eine standardmäßige Punkt-zu-Punkt-FC-Verbindung her.
Vor ONTAP 9.19.1 erfordern ONTAP Speichersysteme NPIV, was bedeutet, dass das Speichersystem mit einem FC Switch verbunden sein muss, der ebenfalls NPIV unterstützt.
ISCSI und NVMe/TCP
Ein Host, der iSCSI oder NVMe/TCP verwendet, kann direkt mit einem Storage-System verbunden werden und ordnungsgemäß ausgeführt werden. Der Grund dafür ist Pathing. Direkte Verbindungen zu zwei verschiedenen Storage Controllern ergeben zwei unabhängige Pfade für den Datenfluss. Der Verlust von Pfad, Port oder Controller verhindert nicht, dass der andere Pfad verwendet wird.
NFS
Direct-Connected NFS Storage kann genutzt werden, aber mit einer erheblichen Einschränkung - Failover funktioniert nicht ohne einen erheblichen Scripting-Aufwand, der in der Verantwortung des Kunden liegt.
Der Grund, warum ein unterbrechungsfreier Failover mit direkt verbundenem NFS-Storage kompliziert ist, ist das Routing auf dem lokalen Betriebssystem. Angenommen, ein Host hat eine IP-Adresse von 192.168.1.1/24 und ist direkt mit einem ONTAP-Controller mit einer IP-Adresse von 192.168.1.50/24 verbunden. Während eines Failovers kann diese 192.168.1.50-Adresse ein Failover auf den anderen Controller durchführen, und sie wird für den Host verfügbar sein. Wie erkennt der Host jedoch sein Vorhandensein? Die ursprüngliche 192.168.1.1-Adresse ist noch auf der Host-NIC vorhanden, die keine Verbindung mehr zu einem Betriebssystem herstellt. Der für 192.168.1.50 bestimmte Datenverkehr würde weiterhin an einen nicht funktionsfähigen Netzwerkport gesendet.
Die zweite OS-NIC könnte als 192.168.1.2 konfiguriert werden und wäre in der Lage, mit der übergewechselten Adresse 192.168.1.50 zu kommunizieren, aber die lokalen Routingtabellen hätten standardmäßig die Vorgabe, eine und nur eine Adresse für die Kommunikation mit dem Subnetz 192.168.1.0/24 zu verwenden. Ein Systemadministrator könnte ein Skripting-Framework erstellen, das einen Ausfall der Netzwerkverbindung erkennt und die lokalen Routingtabellen anpasst oder Schnittstellen aktiviert und deaktiviert. Das genaue Verfahren würde vom verwendeten Betriebssystem abhängen.
In der Praxis haben NetApp-Kunden NFS direkt verbunden, aber normalerweise nur für Workloads, bei denen IO-Pausen während Failover akzeptabel sind. Wenn harte Mounts verwendet werden, sollte es während solcher Pausen keine IO-Fehler geben. Die E/A-Vorgänge sollten so lange hängen bleiben, bis Dienste wiederhergestellt werden, entweder durch ein Failback oder durch einen manuellen Eingriff, um IP-Adressen zwischen NICs auf dem Host zu verschieben.