Eine der folgenreichsten Architekturentscheidungen beim Aufbau einer Citrix-Provisioning-Umgebung ist die Frage, wo die vDisks eigentlich liegen: auf einem zentralen SMB-Share im Netzwerk — oder lokal auf den PVS-Servern selbst. In der Praxis greifen viele Kunden zum Netzwerk-Share, weil er auf den ersten Blick einfacher und sparsamer wirkt. Technisch ist das in den allermeisten Fällen die schlechtere Wahl. Dieser Artikel erklärt, warum — und wie sich die Nachteile lokaler Volumes mit PVS Forge auflösen lassen.
Warum lokale Volumes technisch überlegen sind
Der entscheidende Punkt ist simpel: Beim lokalen Volume liegt kein Netzwerk zwischen dem Streaming-Dienst und der vDisk. Es gibt keinen SMB-Layer, keine Netzwerk-Latenz, keine Abhängigkeit von der Auslegung eines Fileservers. Der PVS-Server liest die Blöcke direkt vom lokalen Storage und streamt sie an die Targets.
Sobald ein SMB-Share ins Spiel kommt, holt man sich eine ganze Kette potenzieller Engpässe ins Haus — und jeden einzelnen davon muss man aktiv beherrschen, damit die Streaming-Performance stimmt.
Die SMB-Problematik im Detail
Damit ein Netzwerk-Share überhaupt mit lokalem Storage konkurrieren kann, müssen mehrere Dinge zusammenpassen:
- CPU-Auslegung des PVS-Servers. SMB-Durchsatz hängt unmittelbar an verfügbarer CPU-Leistung. Ist der Server zu knapp dimensioniert, limitiert die CPU den Durchsatz, lange bevor das Netzwerk oder der Storage an seine Grenzen kommt.
- Receive Side Scaling (RSS). Ohne aktives und korrekt konfiguriertes RSS wird der gesamte Netzwerk-Interrupt-Verkehr auf einen einzigen CPU-Core gebündelt. Dieser eine Core wird zum Flaschenhals, während die übrigen Kerne im Leerlauf liegen. Erst RSS verteilt die Netzwerklast auf mehrere Cores und erschließt den vollen Durchsatz der NIC. RSS muss dafür nicht nur vorhanden, sondern auf Adapter- und Betriebssystemebene tatsächlich aktiv und sinnvoll auf die verfügbaren Kerne gemappt sein — andernfalls verschenkt man genau den Durchsatz, den man für sauberes Streaming braucht.
Wichtig — und das ist ein Punkt, den viele Kunden nicht auf dem Schirm haben: Klassisches RSS greift bei physischen Servern. PVS-Server laufen heute aber nahezu zu hundert Prozent virtuell, und dort ist nicht RSS, sondern vRSS (Virtual RSS) der entscheidende Hebel. Microsoft hat vRSS bereits mit Windows Server 2012 eingeführt, um genau dieses Problem in virtuellen Maschinen zu lösen: die Verteilung des Netzwerkverkehrs einer VM auf mehrere virtuelle Prozessoren. Ohne aktives vRSS landet man auch in der VM wieder beim Single-Core-Bottleneck — egal wie viele vCPUs zugewiesen sind. Wer einen virtuellen PVS-Server über einen SMB-Share streamen lässt, muss vRSS also kennen und aktiv konfigurieren, sonst bleibt der Durchsatz unnötig limitiert.
Das sind keine „Nice to have“-Tuning-Schräubchen. Es sind Voraussetzungen, ohne die ein SMB-basierter Aufbau die optimale Geschwindigkeit und den nötigen Durchsatz schlicht nicht erreicht. Beim lokalen Volume entfällt dieser gesamte Themenkomplex ersatzlos.
DFS: ein verbreiteter, aber gefährlicher Sonderweg
Der eine oder andere greift zusätzlich zu DFS-Shares — und das sollte man nicht tun. Das Problem liegt in den Zeitstempeln: Wird eine vDisk auf das DFS kopiert, kann das Replikat auf dem zweiten Server einen minimal abweichenden Zeitstempel erhalten. Ein PVS-Server, der diese Abweichung sieht, stuft die vDisk dann als nicht synchron ein — und startet sie auf diesem Server schlicht nicht. Solange der Administrator nicht explizit in der PVS-Konsole nachschaut, ob die vDisk auf beiden Servern als synchron und passend gemeldet wird, bleibt das unbemerkt: Im Ergebnis steht die vDisk nur auf einem der beiden Server zur Verfügung. Eine echte Problematik, die in der Praxis schwer zu diagnostizieren ist — denn auf den ersten Blick „liegt die Disk ja auf beiden Servern“.
Warum Kunden trotzdem vor lokalen Volumes zurückschrecken
Wenn lokale Volumes technisch so klar überlegen sind — warum greifen dann so viele zum Netzwerk-Share? Es gibt im Wesentlichen zwei Gründe.
Grund 1: PVS synchronisiert vDisks nicht selbst
Das ist die eigentliche Achillesferse. PVS bringt keinerlei integrierte Funktion mit, um die erzeugten vDisks über alle PVS-Server hinweg zu synchronisieren. Wer lokale Volumes nutzt, muss dafür sorgen, dass jede neue vDisk und jede neue Version auf jedem PVS-Server identisch vorliegt — sonst streamt nicht jeder Server den gleichen Stand.
Draußen kursieren dafür einzelne Skripte und selbstgebaute Script-Bundles. Aber es gibt nichts, was im Produkt integriert sicherstellt, dass die vDisks automatisch und zuverlässig synchron gehalten werden. Genau dieser manuelle, fehleranfällige Aufwand schreckt viele ab — und treibt sie zurück zum zentralen Share, wo es eben nur eine Kopie gibt.
Grund 2: Mehrfacher Storage-Bedarf
Der zweite Grund ist der Speicherbedarf. Ein zentraler Share mit einem Terabyte ist genau das: ein Terabyte. Will man denselben Bestand lokal vorhalten, muss er auf jedem PVS-Server liegen — bei den üblichen mindestens zwei PVS-Servern also zweimal, sprich zwei Terabyte für denselben Inhalt.
Dieser Mehrbedarf ist real und sollte ehrlich eingeplant werden. Allerdings relativiert er sich angesichts heutiger Storage-Dimensionen erheblich: Volumes mit ein, drei oder vier Terabyte sind längst nichts Ungewöhnliches mehr, sondern fast schon alltäglich. Der Storage-Aufpreis ist in den meisten Umgebungen der deutlich kleinere Preis — gemessen an dem, was man auf der Performance-Seite gewinnt.
Was auf dem Spiel steht: Streaming-Performance
Die Netzwerk-Abhängigkeit eines SMB-Shares trifft viele Kunden hart: Performance-Einbrüche im Streaming, Systeme, die zäh und langsam wirken — schlicht, weil die Daten nicht schnell genug nachkommen. Gerade unter Last, etwa bei Boot-Storms am Morgen, wird der Netzwerkpfad zum limitierenden Faktor.
Lokale Volumes zeigen hier ihre Überlegenheit am deutlichsten: voller, ungebremster Zugriff auf den Storage, keine Netzwerk- oder SMB-Variablen dazwischen, maximaler Durchsatz beim Streamen der Blöcke.
Und genau hier lässt sich noch eine zweite Stellschraube nutzen: die Art des Storages. Viele Unternehmen haben in ihren Storage-Systemen heute SSDs im Einsatz, und der Unterschied zwischen langsamen und schnellen Platten ist beim Streaming unmittelbar spürbar. Für die Volumes der PVS-Server bietet es sich daher an, gezielt SSD-Storage zu wählen — denn beim PVS-Streaming dominiert der lesende Zugriff, und genau dort spielen SSDs ihre Stärke aus. Das Resultat ist ein optimaler, schneller Lesedurchsatz und damit ein entsprechend schnelles, stabiles Streaming an die Targets.
Hier greift PVS Forge ein
Der mit Abstand wichtigste Grund gegen lokale Volumes — die fehlende Synchronisation — fällt mit PVS Forge weg. PVS Forge übernimmt die Synchronisation der vDisks automatisch auf alle PVS-Server. Kein selbstgestricktes Skript, kein manuelles Kopieren, kein Risiko, dass ein Server einen veralteten Stand streamt. Jede neue vDisk und jede neue Version wird zuverlässig farmweit verteilt.
Damit verschiebt sich die Abwägung grundlegend: Der einzige verbleibende „Nachteil“ lokaler Volumes ist der höhere Storage-Bedarf — und der ist bei heutigen Volume-Größen gut zu verkraften und ehrlich planbar. Der eigentliche Showstopper, die Synchronisation, ist gelöst.
Fazit
Technisch ist die Sache eindeutig: Lokale Volumes am PVS-Server sind die überlegene Variante. Kein Netzwerk, keine SMB-Abhängigkeiten, keine CPU- und RSS-Tuning-Pflicht, keine DFS-Sync-Fallen — dafür voller Durchsatz und stabiles Streaming auch unter Last. Die beiden Gründe, die Kunden bislang davon abgehalten haben, waren die fehlende Synchronisation und der mehrfache Storage-Bedarf. Den ersten löst PVS Forge vollständig durch automatische, farmweite vDisk-Synchronisation; der zweite ist bei heutigen Storage-Größen kein ernsthaftes Hindernis mehr.
Die klare Empfehlung lautet: lokale Volumes — und PVS Forge macht sie endlich ohne Kompromisse praktikabel.
German 
English