Warum PVS nie das Problem war – es fehlten die Werkzeuge

pvs vs mcs

Ich sage es gleich zu Beginn: Citrix Provisioning war nie die schwächere Technologie. Die Branche ist trotzdem in Scharen zu MCS gewandert – nicht weil PVS schlechter war, sondern weil es keine vernünftigen Werkzeuge dafür gab. Diese Lücke habe ich über Jahre in Projekten gesehen, und irgendwann habe ich beschlossen, sie zu schließen. Das Ergebnis heißt PVS Forge.

Es begann bei einem Kunden mit meheren Master Targets

Der konkrete Auslöser war ein Kunde, bei dem regelmäßig von mehreren Master Targets min. monatlich frische vDisk erstellt werden mussten. Das war schon damals eine undankbare, wiederkehrende Handarbeit. Ich habe es seinerzeit mit einem eigenen Skript halbwegs automatisiert – aber eben nur halbwegs. Der Sync auf die anderen Server war noch nicht automatisch dabei, und vieles blieb Fleißarbeit.

Es blieb nicht bei diesem einen Kunden. Bei weiteren sah ich dasselbe Muster, nur schmerzhafter: Diese taten sich mit dem Imaging schwer. Images, die stehen blieben. Bootprobleme. Der ganze Rattenschwanz an Details, der beim vDisk-Imaging danebengehen kann. Was auf dem Papier ein simpler Vorgang ist, wurde im Alltag zur Fehlerquelle und zum Zeitfresser.

Und dann dasselbe Muster in ganz groß

Vor rund eineinhalb bis zwei Jahren kam ein Fall dazu, der die Sache noch deutlicher machte – diesmal im großen Maßstab. Ein Kunde mit mehreren Tausend Workern und einer zweistelligen Zahl an PVS-Servern hatte massive Leistungsprobleme. Die Ursache lag nicht in PVS selbst, sondern in der Architektur: Ein zentraler Shared Storage war zum Flaschenhals geworden.

Die Lösung war der Umstieg auf lokale Storages pro PVS-Server – technisch die richtige Antwort, denn das löste die Performance-Engpässe. Aber sie erzeugte prompt das nächste Problem: Wenn jede vDisk auf jedem Server lokal liegen muss, wird die Synchronisierung über all diese Stores zur eigentlichen Herausforderung. Und genau hier zeigt sich das Muster wieder: PVS skaliert hervorragend – mehrere Tausend Worker über eine zweistellige Serverzahl sind der beste Beweis dafür. Was fehlte, war das Werkzeug, um den Betrieb dieser Skalierung beherrschbar zu machen. Auch dieser Fall ist direkt in PVS Forge eingeflossen.

Das eigentliche, unsichtbare Problem: der Lifecycle

Je länger ich in diesen Projekten steckte, desto klarer wurde mir, dass das Imaging nur die sichtbare Hälfte ist. Die unsichtbare Hälfte ist die Versionierung – und die ist mindestens genauso schmerzhaft. Was wurde wann in welche vDisk-Version geändert? Welcher Stand liegt wo? Diese Fragen beantwortet weder PVS noch MCS von sich aus.

Und ja – das ist ausdrücklich kein reines PVS-Problem. Auch bei MCS ist der Lifecycle eines Golden Image genauso wenig nachvollziehbar. Der gesamte Lebenszyklus einer vDisk oder eines Golden Image wird schlicht nirgends abgebildet. Man verlässt sich auf Notizen, auf Erinnerung, auf das Bauchgefühl des Administrators. Für eine Technologie, die produktive Arbeitsplätze bereitstellt, ist das erstaunlich blind.

Warum die Branche zu MCS ging – und warum das ein Werkzeugproblem war

Ich bin seit jeher ein PVS-Verfechter. Ich habe die Technologie bei vielen Kunden eingeführt und ihnen ihre Stärken nähergebracht: das eine Image, netzwerkbasiert an beliebig viele Targets gestreamt, hypervisor-unabhängig.

Und trotzdem habe ich miterlebt, wie es nach und nach zu MCS abwanderte. Der Grund war fast nie „PVS kann das nicht“. Der Grund war: Das Imaging bei MCS wirkte einfacher, die Verteilung ging leichter von der Hand. Kurz – für MCS gab es brauchbare, integrierte Abläufe, und für PVS fehlten sie. Es war ein Werkzeugproblem, kein Technologieproblem.

Genau da setzt mein Gedanke an: Wenn PVS nur die Werkzeuge fehlten, dann muss man eben diese Werkzeuge bauen. Werkzeuge, die das Imaging so einfach machen wie bei MCS – oder einfacher. Und wenn das gelingt, dann ist PVS als Serversystem zusammen mit einem guten Werkzeug nicht die zweitbeste, sondern die ideale Lösung.

PVS Forge: die fehlende Werkzeugschicht

PVS Forge ist genau diese Werkzeugschicht. Es nimmt das Imaging und macht daraus wenige Schritte: Anmeldedaten hinterlegen, Master Target aus dem Active Directory suchen, Store wählen, starten. Den Rest – vDisk-Erstellung, Neustart des Master Targets, Abmelden offener Sitzungen, Synchronisierung auf alle PVS-Server, Import – erledigt das Werkzeug. Der Ablauf ist jedes Mal identisch und macht deshalb jedes Mal dieselben, nämlich keine, Fehler.

Gerade die Synchronisierung ist dabei mehr als ein Nebenschauplatz. Wer aus Performance-Gründen auf lokale Storages pro Server setzt – so wie der Kunde mit den Leistungsproblemen – braucht einen verlässlichen, nachvollziehbaren Weg, jede vDisk auf jeden Server zu bringen. Genau das übernimmt PVS Forge, statt es dem Administrator und einer Sammlung von Skripten zu überlassen.

Und es schließt die zweite, unsichtbare Lücke: den Lifecycle. PVS Forge macht sichtbar, welche Version wo liegt und was sich zwischen zwei Ständen einer vDisk geändert hat – bis hinunter zur installierten Software. Das ist die Nachvollziehbarkeit, die ich jahrelang vermisst habe. Dazu kommt das eingebaute Praxiswissen aus all diesen Projekten: die vielen Kleinigkeiten rund um Sealing, DNS und Boot, über die erfahrene Administratoren sonst stolpern.

Und dann kam Proxmox

Erst an dieser Stelle – und bewusst erst hier – kommt das Thema Hypervisor ins Spiel, das aktuell viele umtreibt. Denn es verstärkt mein Argument, es begründet es nicht.

MCS ist stark vom Hypervisor abhängig. Es braucht dessen API, und wenn mit MCS etwas nicht stimmt, ist das Troubleshooting oft mühsam. Sobald ein Unternehmen aber auf einen Hypervisor wechselt, den MCS nicht unterstützt – Proxmox ist das aktuelle Beispiel – steht man mit MCS schlicht an. PVS dagegen streamt über das Netzwerk und ist hypervisor-agnostisch. Die Technologie, die viele schon abgeschrieben hatten, ist damit plötzlich der sichere Hafen einer Migration.

Das ist für mich der Beweis der ursprünglichen These: PVS war nie das Problem. Es brauchte nur die richtigen Werkzeuge, um seine Stärken auch im Alltag auszuspielen. Und ausgerechnet jetzt, wo sich die Hypervisor-Landschaft bewegt, zahlt sich das aus.

Fazit

PVS Forge ist nicht aus einer Marktlücke am Reißbrett entstanden, sondern aus konkreten Kundenprojekten und aus einer Überzeugung: dass eine ausgezeichnete Technologie nicht an sich selbst gescheitert ist, sondern an fehlenden Werkzeugen. Diese Werkzeuge liefere ich jetzt nach. Wer PVS betreibt – oder wer angesichts der Hypervisor-Frage neu darüber nachdenkt – findet damit eine Antwort, die den Alltag tatsächlich einfacher macht.


PVS Forge ist mein kommerzielles Werkzeug für die Automatisierung, Versionierung und das Monitoring von Citrix Provisioning. Alle Details, eine kostenlose Testversion und die technische Dokumentation finden Sie unter www.pvs-forge.com.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen