Systemstart, Anmeldung, Streaming: Was der PVS-Lastausgleich tatsächlich entscheidet

Drei Phasen, drei Regelwerke

UDP 6910 ist die Ursache für drei weit verbreitete Missverständnisse: bezüglich Portbereiche, bezüglich der Kapazität und bezüglich der Frage, was der PVS-Lastausgleich tatsächlich ausgleicht. Der Prozess umfasst drei Phasen mit unterschiedlichen Regeln:

• „Boot“ entscheidet, wen das Ziel abfragt.
• Die Anmeldung erfolgt über einen einzigen Handshake, der über alles entscheidet.
• Das Streaming bleibt bis zur nächsten Wiederverbindung unverändert.

Phase 1: Boot

Das Ziel erfährt aus seinem Bootstrap, wen es kontaktieren muss, und nicht vom PVS-Server. Der Bootstrap enthält bis zu vier Einträge, von denen jeder über eine eigene IP-Adresse und einen eigenen Port verfügt (Bootserver1_Ip, Bootserver1_Port, …).

• PXE/TFTP: Das Zielgerät ruft bei jedem Systemstart das Boot-Image ab, sodass Änderungen bereits beim nächsten Start wirksam werden.
• BDM: Die Konfiguration ist im Boot-Medium gespeichert. Änderungen auf dem Server werden nicht an das Zielgerät weitergeleitet, daher muss das Medium neu erstellt werden.

Phase 2: Login

• Die Anmeldung erfolgt in einem einzigen Datenaustausch: einer 28-Byte-Anfrage und einer 28-Byte-Antwort.
• Die Antwort enthält bereits den Streaming-Server, den Port und die vDisk.
• Der ausgewählte Server empfängt keine Pakete auf dem Anmeldeport. Es findet kein Hand-off statt.

Die Lastverteilung wird einmalig bei der Anmeldung festgelegt. Da PVS-Streaming über UDP erfolgt, „wechselt“ das Ziel nicht den Port. Es leitet einfach den gesamten Ein- und Ausgang an den in der Antwort angegebenen Port weiter. Eine einzige „StreamProcess.exe“-Instanz überwacht alle Ports des Bereichs, wobei jeder Port einem eigenen Thread-Pool zugeordnet ist.

6910 ist nicht der Login-Port. Der erste Port des Bereichs ist

6910 ist lediglich der Standard-Anfangswert des Bereichs (Netzwerk → Erster Port / Letzter Port). Bezogen auf diesen ersten Port:

• 1. Port: Anmeldung, im Empfangsmodus, keine Geräte angeschlossen
• 2. Port: im Empfangsmodus, keine Geräte angeschlossen
• 3. Port: nicht im Empfangsmodus
• 4. Port und höher: Streaming

Bei den Geräten 6910–6930 beginnt die Nummerierung bei 6913, sodass 18 Ports mit jeweils 8 Threads verbleiben – das sind 144 Plätze, auf denen der PVS-Server die Geräte platzieren kann.

144 Plätze, aber niemand kann garantieren, wer wo sitzt

Citrix beziffert diese Konfiguration auf 250 Geräte auf 2 CPUs bzw. 1,74 Geräte pro Platz. Dabei handelt es sich um eine bewusste Überbelegung: 8 Threads auf 2 CPUs entsprechen einem Verhältnis von 1:4, was laut Citrix unterstützt wird. Da die Geräte die meiste Zeit im Leerlauf sind, waren die Plätze nie als Nutzerplätze gedacht.

Aber 144 Steckplätze auf 18 Anschlüssen bedeuten 8 Geräte pro Anschluss, und diese Rechnung geht nicht auf. Es handelt sich um einen Durchschnittswert, nicht um eine Zuordnung.

Die Geräte sind nicht gleichmäßig auf die Ports verteilt. Der Port wird bei der Anmeldung ausgewählt, ohne dass berücksichtigt wird, wie stark die Ports derzeit ausgelastet sind, und es erfolgt anschließend keine Korrektur, da die Zuweisung bis zur nächsten Neuverbindung bestehen bleibt.

Hier ein konkretes Beispiel: Ein PVS-Server mit 207 Geräten, der mit 1,44 Geräten pro Steckplatz deutlich innerhalb des Referenzwerts liegt:

• am stärksten ausgelasteter Port: 18 Geräte, 2,25 pro Thread
• Geringste Anzahl an Ports: 7 Geräte, 0,88 pro Thread

Der am stärksten ausgelastete Port liegt über dem Citrix-Referenzwert, während der Server insgesamt darunter liegt. Der Durchschnittswert deutet darauf hin, dass der Server einwandfrei funktioniert. Der Port, der Anfragen beantworten muss, sagt etwas anderes aus, und es könnte sein, dass gerade dieser Port eher zu Wiederholungsversuchen führt.

Wie groß diese Spanne ist, hängt vom jeweiligen Betrieb ab. Entscheidend ist, dass es sie überhaupt gibt und dass keine Kapazitätsangabe sie Ihnen verdeutlichen kann.

Phase 3: Streaming

Die gesamte E/A läuft über einen Port auf einem Server und wird ausschließlich vom Thread-Pool dieses Ports (standardmäßig 8) bedient. Ist der Pool ausgelastet, werden Anfragen in eine Warteschlange gestellt. Benachbarte Ports bieten keine Abhilfe, und Wiederholungsversuche werden an denselben Port weitergeleitet.

• „Ports × Threads“ ist eine Begrenzung der Parallelität pro Port, keine Begrenzung der Verbindungen.
• Ein verbundenes Gerät wechselt niemals den Server oder den Port. Ein neuer Server bleibt leer, und ein überlasteter Server wird nicht entlastet.
• Bei jeder neuen Anmeldung werden Server und Port neu zugewiesen.

Die Ausnahme: Rebalance

Vorher   DEV-1 -> PVS-A : 6923      DEV-2 -> PVS-A : 6922
Invoke-PvsRebalanceDevices -ServerName PVS-A
Nacher    DEV-1 -> PVS-A : 6921      DEV-2 -> PVS-B : 6920

DEV-2 wurde ohne Neustart auf einen anderen Server verschoben. DEV-1 blieb auf demselben Server, erhielt jedoch einen neuen Port. Die Anzahl der anschließenden Wiederholungsversuche war vernachlässigbar. Da es sich bei diesem Beispiel um Geräte im Leerlauf handelte, lässt sich daraus nicht ableiten, wie sich eine Lastverteilung unter Auslastung verhält.

Drei Einstellungen, eine Standardeinstellung

Sobald Sie wissen, dass diese Streuung vorliegt, können Sie dagegen vorgehen. Ports, Threads pro Port und CPUs sind alle in den Servereigenschaften zu finden, und alle drei beeinflussen das gleiche Bild:

• Durch mehr Ports werden die Geräte auf mehr Warteschlangen verteilt.
• Eine höhere Anzahl von Threads pro Port verkürzt die Warteschlange, die sich gerade überfüllt.
• Mehr CPUs bieten beides.

Das Verhältnis von 1:4, das hinter den 8 Threads auf 2 CPUs steht, ist ein Standardwert und keine Obergrenze. Ein Server mit weitaus mehr Kernen kann deutlich mehr Threads pro Port verarbeiten und bleibt dennoch deutlich innerhalb dieses Verhältnisses. Die meisten tun dies jedoch nicht, da der Wert einmal festgelegt wurde und es nie einen Grund gab, ihn zu überdenken.

Verwendete Tools

• PVS RAM Health Check
• PVS Forge Health Advisor