In einem Netzwerk kann die Latenz an mehreren Endpunkten im Datenpfad zunehmen. Als Netzwerkadministrator müssen Sie die Latenz eines Netzwerks überwachen können, um Leistungsengpässe im Netzwerk zu diagnostizieren und zu beheben.
- pNIC zu vNIC
- vNIC zu pNIC
- vNIC zu vNIC
- VTEP zu VTEP
- Die Messung der Netzwerklatenz auf der Data Plane wird nur für ESXi-Host-Transportknoten unterstützt.
- KVM-Hosts und Edge-Transportknoten werden nicht unterstützt.
- In VLAN-Segmenten wird die Netzwerklatenz nur gemessen, wenn beide vNICs zu VMs auf demselben ESXi-Host gehören.
- Wenn die VMs an getrennte Segmente angehängt sind, wird die Netzwerklatenz nur dann gemessen, wenn der Datenverkehr über die Instanz des verteilten Routers (DR) an die ESXi-Host-Transportknoten weitergeleitet wird. Wenn der Datenverkehr über die DR-Instanz an die Edge-Transportknoten weitergeleitet wird, wird die Netzwerklatenz nicht gemessen.
- Der erweiterte Netzwerk-Stack (ENS) unterstützt keine vNIC-zu-pNIC-, pNIC-zu-vNIC- und vNIC-zu-vNIC-Latenz.
- Eine Latenzmessung wird nicht unterstützt, wenn mithilfe von Partnerdienst-VMs ein horizontaler Netzwerkdatenverkehrsschutz konfiguriert ist. An den Ports von Dienst-VMs (SVMs) und Gast-VMs ist die Latenzüberwachung deaktiviert.
Sie können die Latenzdaten in externe Tools für die Überwachung der Netzwerkleistung exportieren und Analysen durchführen. Diese externen Überwachungstools werden auch als Collectors bezeichnet. Mit einem Collector können Sie mehr Netzwerksichtbarkeit erzielen, die Netzwerkleistung optimieren und Endpoints im Datenpfad ermitteln, die eine signifikante Latenz im Netzwerk verursachen.
Nachdem die Hosts zur Messung der Netzwerklatenzstatistiken konfiguriert wurden, fragt der Netopa-Agent (Network Operations Agent) regelmäßig die Data Plane auf den Hosts ab. Wenn Latenzdaten verfügbar sind, exportiert der Agent die Daten in vorkonfigurierten Intervallen in die externen Collectors.
- Der Netopa-Agent kann die Statistiken zur Netzwerklatenz ausschließlich in vRealize Network Insight (vRNI) exportieren. Andere Collector-Tools werden derzeit nicht unterstützt.
- Auf ESXi-Hosts können Sie die Messung von Netzwerklatenzstatistiken ausschließlich über die NSX-REST APIs konfigurieren.
In der folgenden Support-Matrix sind die Transportknoten und Collectors aufgeführt, die für einzelne Netzwerklatenzstatistiken unterstützt werden.
| Netzwerklatenzstatistiken | Ab NSX-T Data Center Version | Unterstützte Transportknoten | Unterstützte Collectors | Kommentare |
|---|---|---|---|---|
| VTEP zu VTEP |
2.5 |
ESXi-Hosts |
vRNI 5.0 oder höher |
|
| pNIC zu vNIC vNIC zu pNIC vNIC zu vNIC |
3.0 |
ESXi-Hosts |
vRNI 5.3 oder höher |
Das Exportieren von Statistiken in vRNI 5.3 oder höher wird ab NSX-T 3.0.2 unterstützt. |
Sie können Netzwerklatenzstatistiken sowohl für eigenständige ESXi-Hosts als auch für ESXi-Hosts messen, die Teil des vCenter Server-Clusters sind. Netzwerklatenzstatistiken von ausschließlich von vCenter verwalteten ESXi-Hosts können jedoch in vRNI exportiert werden. Das Erfassen von Latenzstatistiken von eigenständigen ESXi-Hosts, die nicht von vCenter Server verwaltet werden, wird von vRNI nicht unterstützt.
Latenz von pNIC zu vNIC und von vNIC zu pNIC
Wenn auf einem Host-Transportknoten die pNIC-Latenzmessung aktiviert ist, wird für jede vNIC auf dem Host-Transportknoten die Latenz von vNIC zu pNIC und von pNIC zu vNIC berechnet.
Statistiken zur pNIC-zu-vNIC- und vNIC-zu-pNIC-Latenz werden im folgenden Format in den externen Collector exportiert:
Endpoint1, Endpoint2, Max, Min, Avg- Endpoint1, Endpoint2 sind entweder die ID der virtuellen Schnittstelle (VIF-ID) oder der Name des physischen Adapters auf einem ESXi-Host (vmnic).
- Max, Min und Avg stehen für den maximalen, minimalen und durchschnittlichen Latenzwert in Mikrosekunden zwischen den beiden Endpoints.
Latenz von vNIC zu vNIC
Diese Latenz gibt die Zeit an, die das Datenpaket von der Quell-vNIC bis zur Ziel-vNIC entweder auf demselben ESXi-Host oder auf unterschiedlichen ESXi-Hosts benötigt. Wenn sich die vNICs auf unterschiedlichen ESXi-Hosts befinden, wird im Overlay-Tunnel zwischen den Hosts ausschließlich das GENEVE-Kapselungsprotokoll unterstützt.
- Wenn sich die Quell-VNIC1 auf VM1 und die Ziel-VNIC2 auf VM2 auf demselben Host befinden, wird für jede Strecke eine Single-Trip-Latenz berechnet und in den Collector exportiert. Das heißt, dass die Latenz für jeden Weg von VNIC1 zu VNIC2 und von VNIC2 zu VNIC1 separat berechnet wird.
- Wenn sich die Quell-VNIC1 auf VM1 und die Ziel-VNIC2 auf VM2 auf verschiedenen Hosts befinden, wird die Latenz für den gesamten Roundtrip berechnet und in den Collector exportiert. Wenn kein umgekehrter Datenverkehr von VNIC2 zu VNIC1 vorhanden ist, wird keine Netzwerklatenz in den Collector exportiert.
Statistiken zur vNIC-zu-vNIC-Latenz werden im folgenden Format in den externen Collector exportiert:
VIF1, VIF2, Max, Min, Avg- VIF1, VIF2 sind die virtuellen Schnittstellen oder die vNICs.
- Max, Min und Avg stehen für den maximalen, minimalen und durchschnittlichen Latenzwert in Mikrosekunden zwischen den beiden vNICs.
VTEP-zu-VTEP-Latenz
Diese Latenz gibt die Zeit für den gesamten Roundtrip an, den das Datenpaket von der Quell-VTEP zur Ziel-VTEP benötigt hat. Um die Latenz von VTEP zu VTEP zu messen, müssen Sie die Latenz im Transportzonenprofil aktivieren.
Für die Berechnung der VTEP-zu-VTEP-Latenz zwischen ESXi-Hosts wird das BFD-Protokoll verwendet. NSX-T Data Center erweitert das BFD-Protokoll um Zeitstempel in der Nutzlast, um die Berechnung der Latenz zwischen den VTEPs zu ermöglichen. BFD-Pakete werden in regelmäßigen Abständen in den einzelnen Tunneln zwischen den Hosts übertragen, um die VTEP-zu-VTEP-Latenz zu berechnen.
