Precision Time Protocol (PTP) in VMware Guests

Mit der Ankündigung von VMware vSphere 7 und damit ESXi 7.0, soll mit diesem Release nun die hochgenaue Zeitsynchronisierung der virtuellen Maschinen über PTP möglich sein.

Leider war zu diesem Zeitpunkt noch keine Dokumentation zu vSphere 7 publiziert, so dass ich beschloss einen Praxistest durchzuführen.

Host Time-Keeping

Bisher war NTP das einzige Zeitprotokoll, das ESXi unterstützte. Mit ESXi 7 steht nun auch PTP zur Verfügung. Die Genauigkeit von NTP ist ausreichend um über die gesamte IT-Infrastruktur eine annähernd genaue Zeit zu verteilen, die für viele Bereiche der IT eine wichtige Rolle spielt (z. B. Logging, Kerberos, Locking, uvm.).

Es gibt jedoch Applikationen, die eine weitaus genauere Zeit benötigen, so spielen beispielsweise Mikrosekunden im Finanztrading durchaus eine massive Rolle.

Mit der Hostsynchrionisierung via PTP ist es nun möglich der VM zum Startzeitpunkt eine weitaus genauere Zeit mitzugeben. Damit diese Zeit auch weiterhin genau bleibt, führt die VM-Hardware Version 17 das „Precision Clock“ Device ein, welches der VM einen hochgenauen Oszillator bereitstellt.

Hardware Version 17

Mit vSphere 7 erstellte VMs haben die virtuelle Hardware Version 17. Diese Version führt das o. g. „Precision Clock“ Device ein.

Zu diesem Zeitpunkt standen lediglich Promotion-Videos und – Texte zur Verfügung, die das PTP-Feature bewarben. In diese Texte und Videos habe ich wohl zu viele Funktionen interpreteiert. Nach meinem Verständnis sollte die VM in die Lage versetzt werden, sich per PTP zu synchronisieren. Damit dies bestmöglich funktioniert, benötigt die VM Zugriff auf das PTP-Timestamping der physischen Netzwerkkarte.

Nach meiner Interpretation hatte es VMware geschafft, das Hardware-Timestamping der Netzwerkkarte so zu virtualisieren, dass die VM dieses Feature nutzen kann. Hier wurde ich allerdings eines besseren belehrt.

VM-Hardware Version 17 – Precision Clock Device

Hardware-Timestamping

Um PTP optimal nutzen zu können, muss die physische Netzwerkkarte miteinbezogen werden. Diese erlaubt das Hardware-Timestamping direkt beim Senden oder Empfangen des PTP-Pakets. Diese Eigenschaft ist wichtig, denn damit wird der Transport durch die verschiedenen Layer vom bzw. hin zum PTP-Daemon aus der Gleichung genommen, welcher schließlich auch Zeit in Anspruch nimmt aber nicht messbar ist.

Meine erste Annahme war, wenn dies ein virtueller Netzwerkadapter unter ESXi 7 unterstützt, dann VMXNET3. Es stellte sich aber heraus, dass weder Software- noch Hardware-Timestamping unterstützt wird.

# ethtool -T ens192
Time stamping parameters for ens192:
Capabilities:
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

Im Vergleich hierzu, stellt die altbekannte E1000 vNIC allerdings alles bereit, was wir benötigen.

# ethtool -T ens224
Time stamping parameters for ens224:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

Ein Starten des PTP-Dienstes mit Hardware-Timestamping verlief allerdings nicht erfolgreich.

ptp4l[1853]: [5425.502] selected /dev/ptp0 as PTP clock
kernel: e1000e 0000:13:00.0 ens224: Timesync Tx Control register not set as expected
ptp4l[1853]: [5425.529] driver rejected most general HWTSTAMP filter
ptp4l[1853]: [5425.529] ioctl SIOCSHWTSTAMP failed: Resource temporarily unavailable
ptp4l[1853]: [5425.535] port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1853]: [5425.536] port 0: INITIALIZING to LISTENING on INIT_COMPLETE

Schade. Da das Hardware-Timestamping unter ESXi 7 weder mit noch ohne Precision Clock Device funktionierte, gehe ich davon aus, dass dieses Device lediglich als hochgenauer Oszillator innerhalb der VM dient, aber keine weitere Funktionalität in Bezug auf die NIC-Virtualisierung bereitstellt. Hier habe ich wohl zu viel in das VMware-Marketing interpretiert.

Da nun aber die ganze Testinfratsruktur schon lief, beschloss ich ESXi 6.7 U3 mit ESXi 7.0 zu vergleichen und einen allgemeinen PTP-Test innerhalb der VMs zu starten.

Teil 1 davon war schnell erledigt, denn die vNIC Capabilities sind unter beiden ESXi-Versionen gleich und auch der PTP-Daemon verhielt sich identisch.

Also weiter zu Teil 2 – wie gut können VMs selbst PTP-Synchronisierungen durchführen?
Zuerst soll aber noch kurz besprochen werden, warum es notwendig ist, dass eine VM selbst die Zeit per PTP bezieht, wenn ESXi 7 diese doch nun direkt und hochgenau bereitstellen kann.

Die Zeit, die ESXi 7 hier bereitstellt ist die absolute Uhrzeit. Es gibt aber einige Applikationen, die PTP verwenden um sich auf eine Zeit zu synchronisieren, die nicht der absoluten Uhrzeit entspricht.

Voraussetzung für die Nutzung der ESXi-PTP-Zeit ist also, dass ESXi und Applikation innerhalb der VM die selbe Uhrzeit verwenden. Trifft dies nicht zu, muss die VM bzw. die Applikation innerhalb der VM selbst für ihre Synchronität sorgen.

Testszenarien

Grundsätzlich gibt es zwei verschiedene Arten der PTP-Synchronisation – wie oben schon beschrieben – nämlich per Software- oder Hardware-Timestamping.

Da mit vNIC (E1000) nur das Software-Timestamping möglich ist, wurden zwei Varianten getestet.

VM zu VM über vSwitch
VM zu VM über physischen Switch

Um einer VM die Möglichkeit zu geben, die physische Netzwerkkarte direkt und damit das Hardware-Timestamping zu nutzen, muss diese via PCI-Passthrough direkt einer VM zugewiesen werden.

Hier wurde schließlich Software- mit Hardware-Timestamping verglichen.

In den folgenden Graphen werden jeweils „Master Offset“ und „Path Delay“ dargestellt. Master Offset ist die Abweichung der Uhr zur Grand Master Clock. Primäres Ziel von PTP ist es, diesen Wert so gut wie möglich gegen 0 zu setzen (keine Abweichung).

Path Delay ist die Zeit, die der Transportweg zwischen den Uhren in Anspruch nimmt. Ein großer Wert hat nicht zwangsläufig eine schlechte Synchronität als Auswirkung, jedoch sollte die Varianz (Jitter) nahezu 0 sein. Ein hoher Jitter bewirkt zwangläufig starke Anpassungen und damit Ungenauigkeiten in der Synchronität.

Test 1 – VM-VM über vSwitch

In diesem Test verfügt jede VM über eine E1000 vNIC, die über den selben vSwitch verbunden sind.

Eindeutig zu erkennen ist ein starkes Schwanken des Offsets im Bereich von +/- 100 Mikrosekunden mit Spitzen im Bereich von 800 Mikrosekunden.

Test 2 – VM-VM über pSwitch

Das Szenario aus Test 2 wird so abgewandelt, dass der Traffic einen physischen Switch passieren muss. Hierzu wird jede VM einem eigenen vSwitch zugeordnet, welcher wiederum über eine pNIC zum physischen Switch verbindet.

Nach einer „Einpendelphase“ ist die Genauigkeit ähnlich Test 1, allerdings stieg das Path Delay im Vergleich zu Test 1 an.

Test 3 – VM-VM pNIC-Passthrough (Software)

In diesem Test verfügt jede VM über eine Passthrough-NIC des Hosts. PTP verwendet Software-Timestamping.

PTP-Sync VM-VM pNIC-Passthrough (Software)

Die Genauigkeit schwankt in diesem Test im Bereich +/- 40 Mikrosekunden. Das ist grob um Faktor 20 besser als in den Tests 1 und 2, trotz dass immer noch Software-Timestamping genutzt wird.

Test 4 – VM-VM pNIC-Passthrough (Hardware)

Dieser Test entspricht vom Aufbau Test 3, jedoch wird Hardware-Timestamping verwendet.

PTP-Sync VM-VM pNIC-Passthrough (Hardware)

Hier zu sehen nun ein ordentliches Ergebnis. Die Genauigkeit pendelt im Bereich von +/- 500 Nanosekunden und der Path Delay entspricht den Forwading-Zeiten eines physischen Ethernet-Switches bei Gigabit (4-7µs), die hier nun recht genau gemessen werden.

Nichtsdestotrotz sind in der Praxis mit PTP-Hardware noch deutlich genauere Lösungen realisierbar.

Tabellarische Messwerte zum Vergleich

(Alle Werte in Nanosekunden)

	Test 1 (vSwitch)	Test 2 (pSwitch)	Test 3 (Passthrough SW)	Test 4 (Passthrough HW)
Master Offset Min.	-151.407	-239.151	-49.642	-712
Master Offset Max.	870.420	830.397	96.045	652
Master Offset Median	-5.551	7.126,5	-2.519	4
Master Offset Mean	-56,186	22.810,333	144,047	0,646

Path Delay Min.	96.143	159.032	84.303	3.986
Path Delay Max.	155.250	238.823	118.855	4.344
Path Delay Median	127.744	205.048,5	100.595	4.154
Path Delay Mean	128.373,46	204.012,33	100.688,09	4.154,962

Fazit

Jede Art von Software-Timestamping (Test 1-3) ist für die meisten Applikationen, die eine hochgenaue PTP-Zeit verwenden, nicht geeignet. Nur Hardware-Timestamping erreicht eine gute Zeitsynchronität, was auf ESXi aber nur durch ein Passthrough-Device erreicht werden kann.
Basiert die PTP-Applikation auf der absoluten Uhrzeit, die auch ESXi via PTP beziehen kann, so eignet sich evtl. das Precision Device unter ESXi 7.