Netzwerklatenzstatistiken

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.

Auf Host-Transportknoten können folgende Netzwerklatenzstatistiken gemessen werden:

• pNIC zu vNIC
• vNIC zu pNIC
• vNIC zu vNIC
• VTEP zu VTEP

In NSX gelten für die Messung von Latenzstatistiken folgende Einschränkungen:

• Die Messung der Netzwerklatenz auf der Data Plane wird nur für ESXi-Host-Transportknoten unterstützt.
• 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 Latenz von vNIC zu pNIC, pNIC zu vNIC oder vNIC zu vNIC.
• 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.
• Die Latenzmessung wird auf der Datenverarbeitungseinheit (DPU) nicht unterstützt.

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.

Hinweis:

• Der netopa-Agent kann die Statistiken zur Netzwerklatenz nur in Aria Operations for Networks exportieren. Andere Collector-Tools werden derzeit nicht unterstützt.
• Für VTEP-Statistiken ist Aria Operations for Networks 5.0 oder höher erforderlich. Für die pNIC- und vNIC-Statistiken ist Aria Operations for Networks 5.3 oder höher erforderlich.
• Auf ESXi-Hosts können Sie die Messung von Netzwerklatenzstatistiken ausschließlich über die NSX-REST APIs konfigurieren.

Sie können Netzwerklatenzstatistiken sowohl für eigenständige ESXi-Hosts als auch für ESXi-Hosts messen, die Teil des VMware vCenter-Clusters sind. Aria Operations for Networks unterstützt jedoch die Erfassung von Latenzstatistiken nur von durch vCenter verwalteten ESXi-Hosts und nicht von eigenständigen ESXi-Hosts.

Latenz von pNIC zu vNIC und 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

Dabei gilt:

• 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.

Die Netzwerklatenz von vNIC zu vNIC wird wie folgt berechnet:

• 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.

Hinweis: NSX berechnet die Latenz von vNIC zu vNIC zwischen Hosts direkt anhand der Zeitstempel in den GENEVE-gekapselten Paketen. Die pNIC-Latenzmessung auf dem Host und die Latenz von VTEP zu VTEP müssen nicht aktiviert werden. Die pNIC-zu-vNIC-, vNIC-zu-pNIC- und VTEP-zu-VTEP-Statistiken sind unabhängig von der vNIC-zu-vNIC-Statistik.

Statistiken zur vNIC-zu-vNIC-Latenz werden im folgenden Format in den externen Collector exportiert:

VIF1, VIF2, Max, Min, Avg

Dabei gilt:

• 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 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.