Wenn wir mit Kunden über VDI im Allgemeinen und Unidesk (das fast allen Connection Brokern und VDI-Protokollen sehr offen gegenüber steht) im Speziellen sprechen, werden wir oft gefragt, welches Remoteprotokoll "das Beste" für VDI ist.
Nun hat jeder Vorlieben, kennt bestimmte Tools und hat sie in der Vergangenheit vielleicht benutzt - daher ist es verständlich, dass in Bezug auf VDI solche Fragen auftauchen. Die Frage "was am Besten" ist, hängt jedoch eher davon ab, wie die ideale Situation in Ihrer speziellen Umgebung tatsächlich aussehen soll.
Grundsätzliche Fragen
Wir möchten an dieser Stelle auf einige grundlegende Fragen eingehen, die immer am Anfang gestellt werden sollten, um den Benutzern das bestmögliche VDI-Erlebnis zu liefern.
Durch die Antworten erhalten Sie die entsprechenden Indizien für eine Auswahl des richtigen Remoteprotokolls:
Benutzen die Anwender mehrere Monitore pro Arbeitsplatz?
Wird HD-Audio und -Video benötigt? Und wenn, wie viele Kanäle beziehungsweise welche Auflösung?
Müssen zusätzliche Geräte am Endgerät unterstützt werden wie externe Festplatten, Drucker, Scanner, Webcams, DVD-Brenner oder ähnliches?
Muss Sicherheit durch Verschlüsselung gewährleistet werden?
Mit der ersten Frage soll herausgefunden werden, welche Gesamtauflösung zum Endgerät übertragen beziehungsweise auf dem Endgerät berechnet werden muss, und wie sich das auf die benötigte Bandbreite auswirkt. Die meisten modernen Remoteprotokolle unterstützen zwei Monitore - durch Verbesserungen können manche Hersteller mittlerweile bis zu vier Monitore ansteuern. Dabei bedarf es teilweise besonderer Konfigurationen oder etwas Tuning, um das Ergebnis annehmbar für die Benutzer zu machen.
Sobald die Audio- und Videoanforderungen bekannt sind, sollte geprüft werden, ob für bestimmte Programme zusätzliche Bandbreite benötigt wird. Wenn Sie zum Beispiel eine Diktiersoftware, die vier Stereokanäle mit jeweils 16kHz benötigt, oder Unified Communication Systeme wie Microsoft Lync mitsamt Webcam benutzen wollen, sollten Sie sich die Anforderungen dieser Programme gezielt anschauen.
Ebenfalls genau sollte auf die Anforderungen bei bestimmten Endgeräten geachtet werden: Müssen bestimmte Benutzer Dateien kopieren, mit Peripheriegeräten scannen, lokale Drucker oder USB-Geräte benutzt werden? Das genaue vorherige Hinschauen erspart dem IT-Support unter Umständen jede Menge Ärger und Aufwand. Wenn das Peripheriegerät nämlich nur mit USB 3.0-Unterstützung läuft, sollten Sie auf ein Remoteprotokoll setzen, welches das auch unterstützt.
Endgeräte
Wo wir gerade bei den Endgeräten sind: Es ist nicht verkehrt, sich zu diesem Zeitpunkt darüber Gedanken zu machen, wie die Endgeräte in Zukunft aussehen sollen. Üblicherweise werden in Verbindung mit VDI gerne „Zero Clients“ eingesetzt, die ein minimales (kaum zu managendes) OS besitzen, so dass der zukünftige Aufwand gegen Null geht. Wenn Sie lieber die alten PC weiterverwenden (etwa mit Stratodesk) oder Thin Clients benutzen möchten, sollten Sie sich Gedanken darüber machen, wie oft und mit welchen Zeitaufwand Maintenance notwendig ist.
Grundsätzlich wird bei den meisten Remoteprotokollen der Datenverkehr zunächst nicht verschlüsselt. Ist das allerdings erforderlich, sollten die Kosten für etwaige, zusätzliche Hardware oder virtuelle Appliances bedacht werden. Auch hier können durch notwendige Updates Kosten durch Maintenance-Zeitfenster entstehen. So oder so: Sie werden vermutlich einige Versuche benötigen, um das Protokoll so zu gestalten, dass alle Anwender damit zufrieden sind.
Die Platzhirsche
Jetzt nehmen wir uns die drei populärsten Remoteprotokolle vor und schauen, wie diese sich auf ein VDI-Projekt auswirken: HDX (Citrix), RemoteFX (Microsoft) und PCoIP (Teradici/VMWare).
TCP vs. UDP
Es soll hier jetzt nicht das gesamte OSI-Modell aufgedröselt werden, aber diese Basics sind wichtig, um herauszufinden, was „am Besten“ für das Projekt ist. Um „Flow Control“, „Error Detection“, „Error Recovery“ und „Data Delivery“ zu verwirklichen, nutzen Remoteprotokolle den Transport Layer 4. Die zwei benutzten Protokolle im Layer 4 sind TCP und UDP. Der Hauptunterschied liegt darin, dass TCP von jedermann als besonders zuverlässig erachtet wird, UDP jedoch nicht. Verkürzt dargestellt ist TCP zuverlässig, weil Computer es nicht sind oder es nicht sein können. Jedesmal wenn ein Programm Daten verschickt, werden diese Pakete in Gruppen zusammengefasst und eine Empfangsbestätigung ("ACK" - kurz für "acknowledment") zum Sender zurückgeschickt, um diesen wissen zu lassen, dass alle Pakete der Gruppe angekommen sind. Wenn der Sender keine ACK einer Paketgruppe zurückbekommt, wird die Paketgruppe noch einmal losgeschickt (Retransmit). Und das genau ist der Grund, warum TCP als besonders zuverlässig gilt. Diese Zuverlässigkeit wird allerdings mit einem ordentlichen Overhead (durch mehrere ACK und Retransmits) bezahlt. UDP dagegen sendet kein ACK. Das irritiert manche Administoren, weil die ACK ihnen genau die Sicherheit vermittelt, dass die Daten bei den Usern ankommen. Die Frage sei erlaubt: Ist es wirklich das, was Sie benötigen?
Stellen Sie sich vor, Sie möchten ein PDF oder Word-Dokument übertragen: Die Datei muss auf beiden Seiten exakt die gleiche sein, denn sonst könnten Sie auf der Empfängerseite die Datei nicht öffnen. Sie benötigen mithin primär Zuverlässigkeit. Wenn Sie hingegen ein Video anschauen, müssen die Daten möglichst schnell ankommen – und das kann UDP ziemlich gut. Sie wollen nämlich keine stotternden Filmszenen oder verzerrte Sounds. Das kann aber passieren, wenn TCP benutzt wird.
Historie
Zu Beginn des Internets gab es Beschränkungen bei der Anzahl der Monitore, die ein Benutzer haben konnte :-). Citrix' HDX baut auf dem ICA-Protokoll auf, welches 1990 auf den Markt kam (zu dieser Zeit gab es zum Beispiel noch kein Adobe Flash). Citrix hat das ICA-Protokoll bis heute immer weiter entwickelt und neue Funktionen hinzugefügt. Calista Technologies wurde 2008 von Microsoft gekauft, um bei RDP benötigte Funktionen wie die Unterstützung von DirectX, USB-Weiterleitung und Beschleunigung bei WAN-Verbindungen einzuführen. Teradici entwickelte PCoIP 2004, und VMWare lizensiert das Protokoll seit 2008. Da PCoIP erst vor verhältnismäßig kurzer Zeit entwickelt wurde, war das Hauptziel eine möglichst sichere Remoteverbindung herzustellen (auch wenn die Sicherheit einen zusätzlichen Overhead erzeugt).
Aktuell
2015 gibt es zwischen allen - zumindest im LAN-Bereich - keine nennenswerten Unterschiede mehr (sofern nicht mehr als vier Monitore pro Session benötigt werden). Die Frage ist eher, wie hoch Ihr Aufwand werden darf. Denn um die Benutzer-Sessions richtig zu unterstützen, sollten Sie sich für jedes Remoteprotokoll das vorhandene Netzwerk ganz genau anschauen. Jedes Protokoll wird in Hinblick auf Paketgrößen, Priorisierung und Sicherheit angepasst werden müssen, damit die Benutzer eine akzeptable Performance geliefert bekommen.
Licht und Schatten
Grundsätzlich ist eine Verschlüsselung in HDX und RemoteFX nicht eingebaut. Wenn Sie aus dem Banken- oder Behördenbereich kommen, könnte dies eine Anforderung für Ihr VDI-Projekt sein. Geräte wie der NetScaler Gateway von Citrix oder Ciscos WAAS helfen hier. Bitte beachten: Wenn Sie solche Geräte einsetzen, sollten sich entweder Ihre Mitarbeiter einarbeiten dürfen oder Sie beauftragen externe Consultants (was das Projekt etwas verteuern dürfte). In den allermeisten Szenarien werden solche Geräte redundant ausgelegt, so dass eine Ausfallsicherheit besteht und damit auch Firmware/OS-Updates ohne Downtime eingespielt werden können. Die meisten Admins stellen fest, dass die Geräte relative schnell konfiguriert und einsetzbar sind – nahe an einer “out of box” Implementierung.
Bei HDX und RemoteFX gibt es grundsätzlich standardisierte Monitorauflösungen. Daher sollten die Bildschirme der Endgeräte richtig konfiguriert sein. Um Monitorfunktionen wie EDID nutzen zu können, müssen eventuell Anpassungen im ThinClient oder im VDI-OS erfolgen. Die Frame-Raten sind ebenfalls zu beachten und Sie werden möglicherweise nicht über 1080p hinauskommen, ohne die Benutzererfahrung zu trüben.
Diejenigen die PCoIP benutzen, tun dies zumeist wegen der eingebauten Sicherheit. Aber auch hier muss jede Menge getestet werden, um das vorhandene Netzwerk korrekt für LAN- oder WAN-Verbindungen zu tunen. „Quality of Service“-Regeln und Priorisierungen sind sehr hier wichtig, damit der Tunnel groß genug für Video, Audio und USB-Redirection ist. Aus diesem Grund findet man normalerweise nur über USB 1.1 verbundene Geräte in PCoIP Sessions. Dies ist wichtig zu wissen, denn wenn zum Beispiel Webcams mit Microsoft Lync benutzt werden sollen, muss sichergestellt sein, dass diese auch mit USB 1.1 funktionieren. PCoIP sendet zudem standardmäßig eine 1080p-Auflösung – was jedoch im Vergleich zu anderen Protokollen bei WAN-Verbindungen eher ein Hindernis sein kann. (Hier ist Citrix gerade bei hohen Latenzen (>250ms) immer noch kaum zu toppen.)
Jedes Protokoll hat seine Stärken und Schwächen wenn es um Mediaformate wie DirectX, Flash, H.264 oder MPEG geht. Sie sollten herausfinden, welches Programm welche Anforderungen hat und dies unbedingt in die Entscheidung für ein Protokoll mit einbeziehen.
Testen, testen, testen
Wie bei allen Neuerungen sollten alle anfänglichen Anforderungen getestet und möglichst alle zukünftigen Anforderungen identifiziert werden, damit die Benutzer die Änderungen gerne akzeptieren und das Ganze auch für alle Anforderungen skaliert. Denken Sie daran zu testen, Benchmarks zu notieren und noch einmal zu testen. Verfolgen/Notieren Sie den Arbeitsaufwand für die Konfiguration, das Tuning und für die Maintenance aufmerksam.
Wenn Sie alle aufgezeigten Punkte durchgehen, sollten Sie Tendenzen für das ein oder andere Protokoll erkennen.
Wir helfen gerne bei der Auswahl – sprechen Sie uns einfach unverbindlich an.
Ihr
Gordon Kirstein