vSAN ermöglicht Ihnen das Untersuchen und Beheben von unterschiedlichen Arten von Problemen, die aus einem falsch konfigurierten vSAN-Netzwerk resultieren.
vSAN-Vorgänge hängen von der Netzwerkkonfiguration, der Zuverlässigkeit und der Leistung ab. Viele Support-Anfragen stammen aus einer falschen Netzwerkkonfiguration oder resultieren aus einem nicht erwartungsgemäß funktionierenden Netzwerk.
Verwenden Sie den vSAN-Integritätsdienst zur Behebung von Netzwerkproblemen. Netzwerkintegritätsprüfungen können Sie in Abhängigkeit von den Ergebnissen der Integritätsprüfung an einen entsprechenden Knowledgebase-Artikel verweisen. Der Knowledgebase-Artikel enthält Anweisungen zur Lösung des Netzwerkproblems.
Netzwerkintegritätsprüfungen
Der Integritätsdienst enthält eine Kategorie für Netzwerkintegritätsprüfungen.
Jede Integritätsprüfung verfügt über den Link AskVMware. Wenn eine Integritätsprüfung fehlschlägt, klicken Sie auf AskVMware, und lesen Sie den zugehörigen VMware-Knowledgebase-Artikel, um weitere Einzelheiten und Anleitungen zur Behebung des Problems zu erhalten.
- vSAN: Basis-(Unicast)-Konnektivitätsprüfung. Diese Prüfung überprüft, ob die IP-Konnektivität für alle ESXi-Hosts im vSAN-Cluster vorhanden ist, indem ein Ping-Vorgang für die einzelnen ESXi-Hosts im vSAN-Netzwerk von jedem anderen ESXi-Host durchgeführt wird.
- vMotion: vMotion: Basis-(Unicast)-Konnektivitätsprüfung. Diese Prüfung überprüft, ob die IP-Konnektivität zwischen allen ESXi-Hosts im vSAN-Cluster vorhanden ist, für die vMotion konfiguriert ist. Jeder ESXi-Host im vMotion-Netzwerk führt für alle anderen ESXi-Hosts einen Ping-Vorgang aus.
- Für alle Hosts ist vSAN-vmknic konfiguriert. Diese Prüfung stellt sicher, dass jeder ESXi-Host im vSAN-Cluster über eine VMkernel-Netzwerkkarte verfügt, die für vSAN-Datenverkehr konfiguriert ist.
- Alle Hosts weisen dieselben Multicast-Einstellungen auf. Durch diese Überprüfung wird sichergestellt, dass alle Hosts über eine ordnungsgemäß konfigurierte Multicast-Adresse verfügen.
- Alle Hosts nutzen dieselben Subnetze. Mit dieser Prüfung wird überprüft, ob alle ESXi-Hosts in einem vSAN-Cluster so konfiguriert wurden, dass sich alle vSAN VMkernel-Netzwerkkarten im selben IP-Subnetz befinden.
- Von VC getrennte Hosts. Mit dieser Prüfung wird sichergestellt, dass vCenter Server über eine aktive Verbindung zu allen ESXi-Hosts im vSAN-Cluster verfügt.
- Hosts mit Konnektivitätsproblemen. Diese Prüfung bezieht sich auf Situationen, in denen vCenter Server den Host zwar als verbunden auflistet, API-Aufrufe von vCenter zum Host jedoch fehlschlagen. Sie kann Konnektivitätsprobleme zwischen einem Host und vCenter Server hervorheben.
- Netzwerklatenz. Diese Prüfung führt eine Netzwerklatenzprüfung für vSAN-Hosts durch. Wenn der Schwellenwert 100 ms überschreitet, wird eine Warnung angezeigt. Wenn der Schwellenwert für die Latenz 200 ms überschreitet, wird ein Fehler ausgelöst.
- vMotion: MTU-Prüfung (Ping mit großem Paket). Diese Prüfung ergänzt die einfache vMotion-Ping-Konnektivitätsprüfung. Die maximale Übertragungseinheitsgröße wird erhöht, um die Netzwerkleistung zu verbessern. Falsch konfigurierte MTUs werden möglicherweise nicht als Netzwerkkonfigurationsproblem angezeigt, sie können jedoch Leistungsprobleme verursachen.
- vSAN-Clusterpartition. Diese Integritätsprüfung untersucht den Cluster, um zu prüfen, wie viele Partitionen vorhanden sind. Es wird ein Fehler angezeigt, wenn es mehrere Partitionen im vSAN-Cluster gibt.
- Multicast-Überprüfung basierend auf anderen Prüfungen. Diese Integritätsprüfung aggregiert Daten aus allen Netzwerkintegritätsprüfungen. Wenn diese Prüfung fehlschlägt, bedeutet dies, dass Multicast wahrscheinlich die Hauptursache einer Netzwerkpartition ist.
Befehle zum Überprüfen des Netzwerks
Wenn das vSAN-Netzwerk konfiguriert wurde, überprüfen Sie mit diesen Befehlen seinen Status. Sie können überprüfen, welcher VMkernel-Adapter (vmknic) für vSAN verwendet wird und welche Attribute darin enthalten sind.
Verwenden Sie ESXCLI-und RVC-Befehle, um zu überprüfen, ob das Netzwerk vollständig funktionstüchtig ist und um Netzwerkprobleme mit vSAN zu beheben.
Sie können sicherstellen, dass die für das vSAN-Netzwerk verwendete vmknic einheitlich auf allen Hosts ordnungsgemäß konfiguriert ist, überprüfen, ob Multicast funktionsfähig ist, und sicherstellen, dass die Hosts, die Teil des vSAN-Clusters sind, erfolgreich miteinander kommunizieren können.
esxcli vsan network list
Mit diesem Befehl können Sie die vom vSAN-Netzwerk verwendete VMkernel-Schnittstelle identifizieren.
Die folgende Ausgabe zeigt, dass das vSAN-Netzwerk vmk2 verwendet. Dieser Befehl funktioniert weiterhin, selbst wenn vSAN auf dem Cluster deaktiviert wurde und die Hosts nicht mehr Teil von vSAN sind.
Die Agentengruppen-Multicast- und Master-Gruppen-Multicast-Überprüfung ist ebenfalls wichtig.
[root@esxi-dell-m:~] esxcli vsan network list Interface VmkNic Name: vmk1 IP Protocol: IP Interface UUID: 32efc758-9ca0-57b9-c7e3-246e962c24d0 Agent Group Multicast Address: 224.2.3.4 Agent Group IPv6 Multicast Address: ff19::2:3:4 Agent Group Multicast Port: 23451 Master Group Multicast Address: 224.1.2.3 Master Group IPv6 Multicast Address: ff19::1:2:3 Master Group Multicast Port: 12345 Host Unicast Channel Bound Port: 12321 Multicast TTL: 5 Traffic Type: vsan
Dabei werden nützliche Informationen bereitgestellt, z. B. welche VMkernel-Schnittstelle für vSAN-Datenverkehr verwendet wird. In diesem Fall ist dies vmk1. Es werden jedoch auch die Multicast-Adressen angezeigt. Diese Informationen werden möglicherweise auch dann angezeigt, wenn der Cluster im Unicast-Modus ausgeführt wird. Dort gibt es die Multicast-Adresse und den Port der Gruppe. Port 23451 wird für das Taktsignal verwendet, das vom Primären jede Sekunde gesendet wird und auf jedem anderen Host im Cluster sichtbar ist. Port 12345 wird für die CMMDS-Updates zwischen dem Primären und der Sicherung verwendet.
esxcli network ip interface list
Mit diesem Befehl können Sie Elemente wie vSwitch oder Distributed Switch überprüfen.
Verwenden Sie diesen Befehl, um zu überprüfen, mit welchem vSwitch oder Distributed Switch eine Verbindung vorliegt. Zudem können Sie die MTU-Größe überprüfen, was hilfreich sein kann, wenn Jumbo-Frames in der Umgebung konfiguriert wurden. In diesem Fall gilt für MTU der Standardwert 1500.
[root@esxi-dell-m:~] esxcli network ip interface list vmk0 Name: vmk0 <<truncated>> vmk1 Name: vmk1 MAC Address: 00:50:56:69:96:f0 Enabled: true Portset: DvsPortset-0 Portgroup: N/A Netstack Instance: defaultTcpipStack VDS Name: vDS VDS UUID: 50 1e 5b ad e3 b4 af 25-18 f3 1c 4c fa 98 3d bb VDS Port: 16 VDS Connection: 1123658315 Opaque Network ID: N/A Opaque Network Type: N/A External ID: N/A MTU: 9000 TSO MSS: 65535 Port ID: 50331814
Die maximale Übertragungseinheitsgröße wird als 9000 angezeigt, daher ist dieser VMkernel-Port für Jumbo-Frames konfiguriert, für die ein MTU-Wert von etwa 9.000 erforderlich ist. VMware gibt keine Empfehlung zur Verwendung von Jumbo-Frames. Jumbo-Frames werden jedoch für die Verwendung mit vSAN unterstützt.
esxcli network ip interface ipv4 get –i vmk2
Dieser Befehl zeigt Informationen wie IP-Adresse und Netzmaske der vSAN VMkernel-Schnittstelle an.
Mit diesen Informationen kann ein Administrator nun mit anderen in der Befehlszeile verfügbaren Befehlen überprüfen, ob das vSAN-Netzwerk ordnungsgemäß funktioniert.
[root@esxi-dell-m:~] esxcli network ip interface ipv4 get -i vmk1 Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type Gateway DHCP DNS ---- ------------ ------------- -------------- ------------ ------- -------- vmk1 172.40.0.9 255.255.255.0 172.40.0.255 STATIC 0.0.0.0 false
vmkping
Der vmkping-Befehl überprüft, ob alle anderen ESXi-Hosts im Netzwerk auf Ihre Ping-Anforderungen reagieren.
~ # vmkping -I vmk2 172.32.0.3 -s 1472 -d PING 172.32.0.3 (172.32.0.3): 56 data bytes 64 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.186 ms 64 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=2.690 ms 64 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.139 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.139/1.005/2.690 ms
Obwohl die Multicast-Funktionalität nicht überprüft wird, kann er dabei helfen, einen nicht autorisierten ESXi-Host mit Netzwerkproblemen zu identifizieren. Sie können auch die Antwortzeiten überprüfen, um festzustellen, ob eine abnormale Latenz im vSAN-Netzwerk vorliegt.
Wenn Jumbo-Frames konfiguriert sind, meldet dieser Befehl keine Probleme, falls die Größe der Jumbo-Frame-MTU nicht korrekt ist. Standardmäßig verwendet dieser Befehl eine MTU-Größe von 1500. Wenn überprüft werden muss, ob die Jumbo-Frames End-to-End erfolgreich arbeiten, verwenden Sie vmkping mit einer größeren Paketgrößenoption (-s) wie folgt:
~ # vmkping -I vmk2 172.32.0.3 -s 8972 -d PING 172.32.0.3 (172.32.0.3): 8972 data bytes 9008 bytes from 172.32.0.3: icmp_seq=0 ttl=64 time=0.554 ms 9008 bytes from 172.32.0.3: icmp_seq=1 ttl=64 time=0.638 ms 9008 bytes from 172.32.0.3: icmp_seq=2 ttl=64 time=0.533 ms --- 172.32.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.533/0.575/0.638 ms ~ #
Sie sollten dem vmkping-Befehl -d hinzufügen, um zu testen, ob Pakete ohne Fragmentierung gesendet werden können.
esxcli network ip neighbor list
Mit diesem Befehl können Sie überprüfen, ob sich alle vSAN-Hosts im selben Netzwerksegment befinden.
In dieser Konfiguration haben wir einen Cluster mit vier Hosts, und dieser Befehl gibt die ARP-Einträge (Address Resolution Protocol) der anderen drei Hosts zurück, einschließlich ihrer IP-Adressen und deren vmknic (vSAN ist für die Verwendung von vmk1 auf allen Hosts in diesem Cluster konfiguriert).
[root@esxi-dell-m:~] esxcli network ip neighbor list -i vmk1 Neighbor Mac Address Vmknic Expiry State Type ----------- ----------------- ------ ------- ----- ------- 172.40.0.12 00:50:56:61:ce:22 vmk1 164 sec Unknown 172.40.0.10 00:50:56:67:1d:b2 vmk1 338 sec Unknown 172.40.0.11 00:50:56:6c:fe:c5 vmk1 162 sec Unknown [root@esxi-dell-m:~]
esxcli network diag ping
Mit diesem Befehl erfolgt eine Prüfung auf Duplikate im Netzwerk sowie Roundtrip-Zeiten.
Um noch mehr Details zur vSAN-Netzwerkkonnektivität zwischen den verschiedenen Hosts zu erhalten, stellt ESXCLI einen leistungsstarken Netzwerkdiagnosebefehl bereit. Hier ist ein Beispiel für eine solche Ausgabe, wobei sich die VMkernel-Schnittstelle auf vmk1 befindet und die vSAN Remote-Netzwerk-IP eines anderen Hosts im Netzwerk 172.40.0.10 ist.
[root@esxi-dell-m:~] esxcli network diag ping -I vmk1 -H 172.40.0.10
Trace:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 0
TTL: 64
Round-trip Time: 1864 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 1
TTL: 64
Round-trip Time: 1834 us
Dup: false
Detail:
Received Bytes: 64
Host: 172.40.0.10
ICMP Seq: 2
TTL: 64
Round-trip Time: 1824 us
Dup: false
Detail:
Summary:
Host Addr: 172.40.0.10
Transmitted: 3
Recieved: 3
Duplicated: 0
Packet Lost: 0
Round-trip Min: 1824 us
Round-trip Avg: 1840 us
Round-trip Max: 1864 us
[root@esxi-dell-m:~]
vsan.lldpnetmap
Dieser RVC-Befehl zeigt Uplink-Portinformationen an.
Wenn in der Umgebung nicht-Cisco-Switches mit aktiviertem LLDP (Verbindungsschichterkennungsprotokoll) vorhanden sind, gibt es einen RVC-Befehl zum Anzeigen von Informationen zum Uplink <-> Switch <-> Switch-Port. Weitere Informationen zu RVC finden Sie im RVC-Befehlshandbuch.
Dies hilft Ihnen bei der Ermittlung, welche Hosts an welche Switches angehängt werden, wenn der vSAN-Cluster mehrere Switches umfasst. Es kann dabei helfen, ein Problem auf einen bestimmten Switch zu isolieren, wenn nur eine Teilmenge der Hosts im Cluster betroffen ist.
> vsan.lldpnetmap 02013-08-15 19:34:18 -0700: This operation will take 30-60 seconds ...+---------------+---------------------------+| Host | LLDP info |+---------------+---------------------------+| 10.143.188.54 | w2r13-vsan-x650-2: vmnic7 || | w2r13-vsan-x650-1: vmnic5 |+---------------+---------------------------+
Diese Vorgehensweise ist nur bei Switches verfügbar, die LLDP unterstützen. Melden Sie sich zum Konfigurieren der Funktion bei dem Switch an und führen Sie die folgenden Schritte aus:
switch# config t Switch(Config)# feature lldp
So überprüfen Sie, ob LLDP aktiviert ist:
switch(config)#do show running-config lldp
LLDP arbeitet standardmäßig im Sende- und Empfangsmodus. Überprüfen Sie die Einstellungen Ihrer vDS-Eigenschaften, wenn die Informationen zum physischen Switch nicht erkannt werden. Standardmäßig wird vDS mit dem Discovery-Protokoll erstellt, das auf CDP (Cisco Discovery Protocol) festgelegt ist. Um dies zu ändern, legen Sie das Erkennungsprotokoll auf LLDP fest, und legen Sie den Vorgang auf dem vDS auf beide fest.
Überprüfen der Multicast-Kommunikation
Multicast-Konfigurationen können Probleme bei der anfänglichen vSAN-Bereitstellung verursachen.
Eine der einfachsten Überprüfungsmöglichkeiten, ob Multicast in Ihrer vSAN-Umgebung ordnungsgemäß funktioniert, ist die Verwendung des Befehls tcpdump-uw. Dieser Befehl ist über die Befehlszeile der ESXi-Hosts verfügbar.
Dieser Befehl tcpdump-uw zeigt an, ob der Primäre Multicast-Pakete ordnungsgemäß sendet (Port- und IP-Informationen) und ob alle anderen Hosts im Cluster diese empfangen.
Auf dem Primären zeigt dieser Befehl die Pakete an, die an die Multicast-Adresse gesendet werden. Auf allen anderen Hosts sind dieselben Pakete sichtbar (vom Primären bis zur Multicast-Adresse). Wenn Sie nicht angezeigt werden, funktioniert Multicast nicht ordnungsgemäß. Führen Sie den hier angezeigten Befehl tcpdump-uw auf einem beliebigen Host im Cluster aus. Daraufhin werden die Taktsignale des Primären angezeigt. In diesem Fall befindet sich der Primäre unter IP-Adresse 172.32.0.2. Das -v- für die Ausführlichkeit ist optional.
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 96 bytes 11:04:21.800575 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 34917, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:22.252369 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15011, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:22.262099 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3359, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200 11:04:22.324496 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 20914, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200 11:04:22.800782 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 35010, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200 11:04:23.252390 IP truncated-ip - 234 bytes missing! (tos 0x0, ttl 5, id 15083, offset 0, flags [none], proto UDP (17), length 316) 172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288 11:04:23.262141 IP truncated-ip - 146 bytes missing! (tos 0x0, ttl 5, id 3442, offset 0, flags [none], proto UDP (17), length 228) 172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
Diese Ausgabe scheint etwas verwirrend zu sein. Sie besagt jedoch lediglich, dass die hier gezeigte Ausgabe angibt, dass die vier Hosts im Cluster ein Taktsignal vom Primären erhalten. Dieser Befehl tcpdump-uw muss auf jedem Host ausgeführt werden, um sicherzustellen, dass alle das Taktsignal empfangen. Dadurch wird sichergestellt, dass der Primäre die Taktsignale sendet und alle anderen Hosts im Cluster sie empfangen, was darauf hinweist, dass Multicast funktioniert.
Wenn einige der vSAN-Hosts nicht in der Lage sind, die Ein-Sekunden-Taktsignale vom Primären abzurufen, muss der Netzwerkadministrator die Multicast-Konfiguration der Switches überprüfen.
Um die lästige Meldung IP abgeschnitten – 146 Byte fehlen! zu vermeiden, verwenden Sie die Option –s0 für denselben Befehl, um das Abschneiden der Pakete zu beenden:
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast -v -s0
tcpdump-uw: listening on vmk2, link-type EN10MB (Ethernet), capture size 65535 bytes
11:18:29.823622 IP (tos 0x0, ttl 5, id 56621, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
11:18:30.251078 IP (tos 0x0, ttl 5, id 52095, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.3.41220 > 224.2.3.4.23451: UDP, length 200
11:18:30.267177 IP (tos 0x0, ttl 5, id 8228, offset 0, flags [none], proto UDP (17), length 316)
172.32.0.2.38170 > 224.2.3.4.23451: UDP, length 288
11:18:30.336480 IP (tos 0x0, ttl 5, id 28606, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.5.60460 > 224.1.2.3.12345: UDP, length 200
11:18:30.823669 IP (tos 0x0, ttl 5, id 56679, offset 0, flags [none], proto UDP (17), length 228)
172.32.0.4.44824 > 224.1.2.3.12345: UDP, length 200
Der Befehl tcpdump steht im Zusammenhang mit der IGMP-Mitgliedschaft (Internet-Gruppenverwaltungsprotokoll). Hosts (und Netzwerkgeräte) verwenden IGMP zum Einrichten der Multicast-Gruppenmitgliedschaft.
Jeder ESXi-Host im vSAN-Cluster sendet reguläre IGMP-Mitgliedschaftsberichte (Beitritt).
Der Befehl tcpdump zeigt IGMP-Mitgliederberichte von einem Host an:
[root@esxi-dell-m:~] tcpdump-uw -i vmk1 igmp tcpdump-uw: verbose output suppressed, use -v or -vv for full protocol decode listening on vmk1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:49:23.134458 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s) 15:50:22.994461 IP 172.40.0.9 > igmp.mcast.net: igmp v3 report, 1 group record(s)
In der Ausgabe werden IGMP v3-Berichte angezeigt, die darauf hinweisen, dass der ESXi-Host regelmäßig seine Mitgliedschaft aktualisiert. Wenn ein Netzwerkadministrator Zweifel daran hat, ob vSAN ESXi-Hosts IGMP korrekt ausführen, kann zur Überprüfung dieser Befehl auf jedem ESXi-Host im Cluster ausgeführt und diese Nachverfolgung angezeigt werden.
Wenn Sie per Multicast kommunizieren, verwenden Sie IGMP v3.
In der Tat kann der folgende Befehl verwendet werden, um den Multicast- und IGMP-Datenverkehr gleichzeitig zu betrachten:
[root@esxi-hp-02:~] tcpdump-uw -i vmk2 multicast or igmp -v -s0
Ein häufiges Problem ist, dass der vSAN-Cluster über mehrere physische Switches hinweg konfiguriert ist und Multicast zwar auf einem Switch, aber nicht Switch-übergreifend aktiviert wurde. In diesem Fall ist der Cluster mit zwei ESXi-Hosts in einer Partition und einem anderen ESXi-Host (verbunden mit dem anderen Switch) nicht in der Lage, diesem Cluster beizutreten. Stattdessen bildet er einen eigenen vSAN-Cluster in einer anderen Partition. Der zuvor gezeigte Befehl vsan.lldpnetmap kann bei der Ermittlung der Netzwerkkonfiguration und der mit den einzelnen Switches verbundenen Hosts helfen.
Während sich ein vSAN-Cluster bildet, gibt es Indikatoren, die darauf hindeuten, dass Multicast ein Problem sein kann.
Gehen wir davon aus, dass die Checkliste für Subnetz, VLAN, MTU befolgt wurde und jeder Host im Cluster für jeden anderen Host im Cluster einen vmkping-Vorgang ausführen kann.
Wenn beim Erstellen des Clusters ein Multicast-Problem auftritt, ist ein häufig auftretendes Symptom, dass jeder ESXi-Host seinen eigenen vSAN-Cluster mit sich selbst als Primärer bildet. Wenn jeder Host über eine eindeutige Netzwerkpartitions-ID verfügt, schlägt dieses Symptom vor, dass zwischen den Hosts kein Multicast vorhanden ist.
Wenn jedoch eine Teilmenge der ESXi-Hosts einen Cluster bildet und eine andere Teilmenge einen anderen Cluster bildet und beide Teilmengen jeweils über eindeutige Partitionen mit eigenem Primären, eigener Sicherung und möglicherweise sogar eigenen Agent-Hosts verfügen, ist Multicast zwar für den Switch aktiviert, jedoch nicht Switch-übergreifend. vSAN zeigt Hosts auf dem ersten physischen Switch an, die eine eigene Cluster-Partition bilden, und Hosts auf dem zweiten physischen Switch, die eine eigene Cluster-Partition mit jeweils einem eigenen Primären bilden. Wenn Sie überprüfen können, mit welchen Switches die Hosts im Cluster eine Verbindung herstellen und Hosts in einem Cluster mit demselben Switch verbunden sind, ist dies wahrscheinlich das Problem.
Überprüfen der vSAN-Netzwerkleistung
Stellen Sie sicher, dass eine ausreichende Bandbreite zwischen ihren ESXi-Hosts vorhanden ist. Dieses Tool kann Sie dabei unterstützen, zu testen, ob Ihr vSAN-Netzwerk optimal funktioniert.
Um die Leistung des vSAN-Netzwerks zu überprüfen, können Sie das iperf-Tool verwenden, um die maximale TCP-Bandbreite und-Latenz zu messen. Es befindet sich unter /usr/lib/vmware/vsan/bin/iperf.copy.. Führen Sie es mit -–help aus, um die verschiedenen Optionen anzuzeigen. Verwenden Sie dieses Tool, um die Netzwerkbandbreite und Latenz zwischen ESXi-Hosts zu überprüfen, die an einem vSAN-Cluster beteiligt sind.
Im VMware Knowledgebase-Artikel 2001003 finden Sie Informationen zum Einrichten und Testen.
Dies ist besonders nützlich, wenn ein vSAN-Cluster in Betrieb genommen wird. Die Ausführung von iperf-Tests für das vSAN-Netzwerk, wenn sich der Cluster bereits in der Produktion befindet, kann die Leistung der auf dem Cluster ausgeführten virtuellen Maschinen beeinträchtigen.
Überprüfen der vSAN-Netzwerkgrenzwerte
Mithilfe des Befehls vsan.check.limits wird sichergestellt, dass keiner der vSAN-Schwellenwerte verletzt wird.
> ls 0 / 1 vcsa-04.rainpole.com/ > cd 1 /vcsa-04.rainpole.com> ls 0 Datacenter (datacenter) /vcsa-04.rainpole.com> cd 0 /vcsa-04.rainpole.com/Datacenter> ls 0 storage/ 1 computers [host]/ 2 networks [network]/ 3 datastores [datastore]/ 4 vms [vm]/ /vcsa-04.rainpole.com/Datacenter> cd 1 /vcsa-04.rainpole.com/Datacenter/computers> ls 0 Cluster (cluster): cpu 155 GHz, memory 400 GB 1 esxi-dell-e.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 2 esxi-dell-f.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 3 esxi-dell-g.rainpole.com (standalone): cpu 38 GHz, memory 123 GB 4 esxi-dell-h.rainpole.com (standalone): cpu 38 GHz, memory 123 GB /vcsa-04.rainpole.com/Datacenter/computers> vsan.check_limits 0 2017-03-14 16:09:32 +0000: Querying limit stats from all hosts ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-m.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-n.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-o.rainpole.com (may take a moment) ... 2017-03-14 16:09:34 +0000: Fetching vSAN disk info from esxi-dell-p.rainpole.com (may take a moment) ... 2017-03-14 16:09:39 +0000: Done fetching vSAN disk infos +--------------------------+--------------------+-----------------------------------------------------------------+ | Host | RDT | Disks | +--------------------------+--------------------+-----------------------------------------------------------------+ | esxi-dell-m.rainpole.com | Assocs: 1309/45000 | Components: 485/9000 | | | Sockets: 89/10000 | naa.500a075113019b33: 0% Components: 0/0 | | | Clients: 136 | naa.500a075113019b37: 40% Components: 81/47661 | | | Owners: 138 | t10.ATA_____Micron_P420m2DMTFDGAR1T4MAX_____ 0% Components: 0/0 | | | | naa.500a075113019b41: 37% Components: 80/47661 | | | | naa.500a07511301a1eb: 38% Components: 81/47661 | | | | naa.500a075113019b39: 39% Components: 79/47661 | | | | naa.500a07511301a1ec: 41% Components: 79/47661 | <<truncated>>
Aus Sicht des Netzwerks sind die RDT-Zuordnungen (Assocs) und die Socket-Anzahl wichtig. Es gibt 45.000 Zuordnungen pro Host in vSAN 6.0 und höher. Eine RDT-Zuordnung wird verwendet, um den Peer-to-Peer-Netzwerkstatus innerhalb von vSAN zu verfolgen. vSAN wird so dimensioniert, dass die RDT-Zuordnungen nie erschöpft sind. vSAN schränkt auch die Anzahl der zu verwendenden TCP-Sockets ein, und vSAN wird so dimensioniert, dass die Zuteilung von TCP-Sockets nie erschöpft. Es gilt ein Grenzwert von 10.000 Sockets pro Host.
Ein vSAN-Client stellt den Zugriff des Objekts im vSAN-Cluster dar. Der Client stellt in der Regel eine virtuelle Maschine dar, die auf einem Host ausgeführt wird. Der Client und das Objekt befinden sich möglicherweise nicht auf demselben Host. Es gibt keinen fest definierten Grenzwert, aber diese Metrik wird angezeigt, um zu verstehen, wie Clients auf Hosts verteilt sind.
Es gibt nur einen vSAN-Besitzer für ein bestimmtes vSAN-Objekt, das in der Regel mit dem vSAN-Client zusammen vorliegt, der auf dieses Objekt zugreift. vSAN-Besitzer koordinieren den gesamten Zugriff auf das vSAN-Objekt und implementieren Funktionalitäten wie Spiegelung und Striping. Es gibt keinen fest definierten Grenzwert, aber diese Metrik wird angezeigt, um zu verstehen, wie Besitzer auf Hosts verteilt sind.
