PVS Failover graceful - eine Netzwerk Betrachtung

Table of contents

Das Setup

In unserer Umgebung gibt es folgende Komponenten:

• Citrix Provisioning Server (Version 2206):
  • ctxpvs1 (192.168.0.30)
  • ctxpvs2 (192.168.0.31)
• Target Device:
  • ctxvda1master (192.168.0.103)

Failover Prozess

Wir möchten uns den Failover Prozess anschauen von einem Target Device von einem PVS Server auf den anderen PVS Server.
Um den Failover zu simulieren, werden wir das Service Citrix PVS Stream Service via services.msc stoppen.

Voraussetzungen

Generelle Informationen finden sich auf: PVS HA - docs.citrix.com.

Für ein erfolgreiches Failover ist das folgende notwendig:

• Die vDisk muss genau die gleiche auf den PVS Server sein (unterschiedliche Zeitstempel sind schon problematisch)
• Die vDisk in der PVS console muss gesetzt sein auf Use the load balancing algorithm.
  • Best Effort ist auch kein Problem und erlaubt Failover präferiert innerhalb Subnet Grenzen. Fixed verbietet Failover über Subnet Grenzen. Referenz: CTX138933
• Die PVS Servers und das Target Device müssen sich netzwerktechnisch erreichen.

Für die Netzwerk Konnektivität können wir uns die Port Matrix von Citrix ansehen.

Failover

In dem Test Lab ist das Target Device (ctxvda1master - 192.168.0.103) verbunden mit dem PVS Server (ctxpvs2 - 192.168.0.31). Wir stoppen das Service Citrix PVS Stream Service und wenn der Failover passieren sollte, passiert nichts. Das Target Device hängt.

Troubleshooting

PVS ist ein Produkt das am Netzwerk stattfindet, es macht also Sinn ein Netzwerk Trace zu machen. Ein Weg das zu machen ist der folgende (für Server 2019 und höher):

network tracing: 
pktmon start --capture
{reproduzieren des Problems}
pktmon stop
pktmon etl2pcap PktMon.etl --out PktMon.pcapng

Theoretisch könnte ein CDF Trace auch sinnvoll sein. Aber Citrix stellt keine Public Symbols für StreamProcess.exe (aber für SoapServer.exe!) zur Verfügung. Ein CDF Trace von SoapServer.exe ist ziemlich sicher nicht hilfreich.

Wie funktioniert es?

Um das Problem zu troubleshooten, müssen wir wissen was/wie kommuniziert. Die Port Matrix Referenz zeigt die folgende Kommunikationstabelle zwischen Target Device und Provisioning Server:

In der Standard Konfiguration (die geändert werden kann), werden die UDP Ports 6910-6930 verwenden für den “content streaming” (also der Inhalt einer vDisk auf das Target Device). Aber es gibt noch die Ports 6901, 6902 und 6905. Ich weiß von keiner öffentlich verfügbaren Dokumentation die beschreibt wofür die Ports genau sind.

Analyse

Die normale Streaming Aktivität von der vDisk auf das Target Device sieht im Netzwerktrace wie folgt aus:

ctxpvs2 sendet Daten über den Port 6930 auf das Target Device mit dem Port 6905. Der Port 6905 am Target Device ist das Service das die vDisk Daten verarbeitet.

Was eigentlich passiert am ctxpvs1 (der PVS Server worauf das Target Device “failovern” sollte):

Die Ports 6903 und 6895 werden verwendet, der Port 6895 ist in der Port Matrix angegeben unter “Inter-server communication”. Das war also die Kommunikation zwischen den beiden PVS Server.

Wenn wir uns den Netzwerkverkehr vom ctxpvs2 ansehen, sehen wir folgenden bezüglich dem Failover:

Das Paket 9013 ist das letzte Paket was als “normales” Streaming Paket gesendet wird. Nach diesem Paket, sehen wir einen neuen UDP Stream wo der PVS Server das Target Device auf den Port 6902 kontaktieren möchte. Dieser Port ist geblockt am Target Device, da es nicht in der Port Matrix spezifiziert ist.

Wir sehen auch Pakete auf dem Target Device:

Es gibt keine Antwort auf das Request vom Target Device.
Es sieht so aus, als würde ctxpvs2 zum Target Device ctxvda1master sagen möchte: “Mein Citrix PVS Stream Service ist gestopped, bitte failover zu einem anderen PVS Server”.

Wenn der Port 6902 erlaubt ist auf der Target Device Firewall, sieht der Netzwerk Trace wie folgt aus:

Und wieder sehen wir ein UDP Paket von ctxpvs2 zu ctxvda1master auf den Port 6902 - aber dieses mal mit einem wichtigen Unterschied. Das Target Device verbindet sich nun auf den anderen PVS Server (ctxpvs1) auf den Port 6910. Anschließend sehen wir mehr Kommunikation zwischen ctxvda1master (Port 6901) und ctxpvs1 (Port 6930). Und zum Schluss sehen wir im Netzwerk Trace noch das bekannte Pattern zwischen den Ports 6905 und 6930.

Warte mal, der Failover funktioniert für mich …

Offensichtlich fehlt in der Port Matrix die korrekte Spezifikation was notwendig ist für einen “graceful failover”. Aber die meisten, die die Target Device Software installieren werden keine Probleme haben. Warum? Weil das Setup erzeugt Firewall Regeln automatisch mit:

Zusammenfassung

Zusammenfassend, basieren auf der oben angeführte Analyse, lässt sich sagen dass die Firewall am Target Device den Port 6902 unbedingt benötigt für einen “graceful failover”.
Das Target Device Setup erzeugt die Firewall Regeln.
Aber leider fehlt diese Information in der Citrix Dokumentation.
Zusätzlich gibt es die Informationen in den System Requirements, dass der Port 6901 erlaubt sein muss. Diese Voraussetzung wird weder durch das Setup automatisiert gesetzt (via Firewall Regeln) noch ist es in der Port Matrix spezifiziert.

Vermutlich ist es ein guter Weg alle beschriebenen Ports (6901, 6902, 6905) zwischen PVS Server und Target Device zu öffnen.

Ich habe vor über einem Jahr darüber getwittered - aber seit dem wurde die Port Matrix noch immer nicht adaptiert. Ich habe nun das Szenario nachgebaut mit der letzten Version um zu prüfen ob das Verhalten noch immer so ist.

Abschließend möchte ich noch ergänzen, dass das nicht der einzige Failover Mechanismus sein kann. Wir haben uns den “graceful failover” angesehen, aber wenn der PVS Server von einem Moment auf den anderen stirbt, kann die oben angeführte Kommunikation gar nicht mehr stattfinden. Es gibt also offensichtlich einen “Plan B”. Das wäre ein Thema für einen anderen Blogbeitrag.

Happy troubleshooting.