VDI und UC – Herausforderungen und mögliche Lösungen

Einführung in VDI

Die Idee hinter der Nutzung von VDI ist einfach: zentrale Bereitstellung von Applikationen sowie Ressourcen für die Ausführung der bereitgestellten Applikationen. Dadurch reduziert sich der Bedarf an Hardware beim Nutzer. Vorherrschend sind Lösungen von VMware (VMware Horizon), Citrix („XenApp und XenDesktop) sowie Microsoft Azure (Remote Desktops). Oftmals kommen herstellerspezifische Hypervisoren zum Einsatz, auf denen die Applikationen oder der gesamte Arbeitsplatz eines Nutzers bereitgestellt werden.

Bei der Virtualisierung von Arbeitsplätzen, insbesondere bei UCC-Anwendungen, bieten die genannten Hersteller jeweils die Möglichkeit, entweder einen oder mehrere vollständige Desktops oder einzelne Anwendungen für jeden Nutzer zu virtualisieren.

Im Falle der Desktopvirtualisierung verfügt jeder Nutzer über eine vollständige virtuelle Maschine, die jeweils dediziert durch den jeweiligen Nutzer genutzt wird. Dies stellt sicher, dass entsprechende Leistungsreserven für anspruchsvolle Anwendungen zur Verfügung stehen, reduziert allerdings durch den entstehenden Overhead die Ressourceneffizienz. Als Alternative zu individuellen, nur für jeweils einen bestimmten Nutzer zugängliche Desktops können auch mehrere identische Desktops genutzt werden, die je nach konkretem Bedarf auf die Nutzer verteilt werden. Die erste Methode ermöglicht einen individuelleren Desktop für die Nutzer, bedeutet jedoch in den meisten Fällen einen höheren Bedarf an Storage-Ressourcen während letztere speziell mit Bezug auf die Wartung der Desktops wesentlich weniger Aufwand erzeugt. Dabei ist allerdings zu beachten, dass keine Nutzerdaten innerhalb der virtuellen Maschine gespeichert werden sollten, und alle persönlichen Anpassungen und sonstige Daten über einen zentralen Storage gespeichert werden müssen.

Bei der Nutzung von Applikationsvirtualisierung werden die Applikationen mehrerer Nutzer auf demselben Rechner bzw. in derselben virtuellen Maschine ausgeführt. Der Nutzer sieht in diesem Fall auf seinem Client nur das Fenster seiner Applikation. Diese Art der Bereitstellung führt in der Regel zu einer besseren Nutzung der vorhandenen Ressourcen. Allerdings kann eine zu große Anzahl Nutzer pro System hier zu einer Beeinträchtigung der Nutzererfahrung für alle Nutzer führen.

Die Abbildung 1 zeigt eine beispielhafte VDI-Architektur auf Basis von VMware-Produkten. Hierbei sind sowohl die Bereitstellung von Desktops als auch einzelner Applikationen dargestellt.

Die Abbildung 2 zeigt eine vereinfachte Darstellung der Architektur des Herstellers Citrix.

Die verschiedenen VDI-Lösungen haben trotz jeweils unterschiedlicher Architektur eine Gemeinsamkeit: Die Verarbeitung und Speicherung von Daten erfolgt in der Regel auf zentralen Servern, und zum Nutzer hin wird die Applikation gestreamt. Hierbei kommen je nach Hersteller-Lösung verschiedene Protokolle zum Einsatz:

• Microsoft Azure Virtual Desktop: Remote Desktop Protocol (RDP), siehe [3]

  Der Zugriff auf virtuelle Desktops kann auf verschiedene Art und Weise realisiert werden: über die Azure Virtual Desktop Store-App für Windows, über die Remotedesktop-App für Windows, über den Webclient sowie über Clients für mobile Endgeräte. Diese verschiedenen Clients bieten zwar im Großen und Ganzen ähnliche Funktionen, es können insbesondere Peripherie-Geräte des Clients wie Maus, Tastatur, Kamera und Mikrofone auch für den virtuellen Desktop genutzt werden. Jedoch gibt es auch einige Unterschiede (siehe hierzu [4]). So ist beispielsweise eine Teams-Optimierung für Azure Virtual Desktop lediglich für die Azure-Virtual-Desktop-Store-App sowie für den macOS-Client verfügbar.

  Eine Verschlüsselung der Verbindung ist mittels SSL/TLS möglich. Diese Verschlüsselung ist zwar mittlerweile standardmäßig aktiviert, jedoch kann zum Teil noch eine unzureichende Verschlüsselung via „RDP Security“ genutzt werden. Hierbei werden sämtliche privaten Schlüssel mit dem gleichen, öffentlich bekannten Microsoft-Schlüssel signiert, was Angreifern leichtes Spiel bietet.

• Citrix: Independent Computing Architecture (ICA), siehe [5]

  Der Zugriff auf virtuelle Desktops sowie Applikationen erfolgt über die Citrix-Workspace-App, welche für Windows-, Linux- und MAC-basierte Systeme sowie mobile Betriebssysteme zur Verfügung steht. Die Kommunikation zwischen der Workspace-App und den virtualisierten Apps bzw. Desktops erfolgt innerhalb des ICA-Protokolls über verschiedene virtuelle Kanäle. Diese können neben Informationen zur Anzeige der Applikationen auch Audio- und Videodaten enthalten. Darüber hinaus können USB-Ports des Clients, auf dem die Workspace-App ausgeführt wird, verwendet werden.

  Zur Verschlüsselung kann SecureICA genutzt werden (siehe [6]). Hierbei werden die Sitzungsdaten mit einer Basis-Verschlüsselung abgesichert. Es erfolgt jedoch keine Authentifizierung, hierfür muss SecureICA mit TLS-Verschlüsselung kombiniert werden.

• VMware: Blast Extreme, PC over IP (PCoIP) und RDP, siehe [7] und [8]

  Der Zugriff auf virtuelle Desktops erfolgt über den „VMware Horizon Client“, der für Windows-, Linux- und MAC-basierte Systeme sowie mobile Betriebssysteme zur Verfügung steht. Für die Übertragung der Daten können die oben genannten Protokolle verwendet werden, wobei es je nach Gerät Einschränkungen der zur Verfügung stehenden Protokolle gibt. So ist Blast Extreme insbesondere für den Zugriff auf Linux-Desktops sowie mobile Cloud-Anwendungen geeignet. PCoIP kann höhere Latenzen oder eine Verringerung der Bandbreite kompensieren und so sicherstellen, dass die Netzwerkbedingungen keine signifikanten Einschränkungen für die Nutzer darstellen.

  Eine Verschlüsselung der Kommunikation ist mit allen drei Protokollen mittels AES-256 möglich.

Ein wichtiger Punkt bei der Bereitstellung von virtuellen Desktops ist neben den Hardware-Ressourcen wie Speicher, CPU und RAM die benötigte Bandbreite für jeden Nutzer. Diese hängt sehr stark von der genutzten Applikation und der Anzahl sowie der Auflösung der verwendeten Monitore ab. Für einfache Office-Arbeit reicht in der Regel 0,5 Mbit/s, für regelmäßige Videokonferenzen werden hingegen 30 Mbit/s empfohlen.

Insbesondere im Banken- und Versicherungsumfeld ist die Bereitstellung von Desktops und Anwendungen über zentrale VDI-Infrastrukturen weit verbreitet. Dies trifft beispielsweise auf Datenbanken und Spezialanwendungen zur Berechnung von Versicherungsprämien oder zur Abwicklung von Versicherungsfällen zu. In diesem Zusammenhang werden oft auch Office-Anwendungen zentral bereitgestellt. Für solche Anwendungen ist die Nutzung von VDI-Mechanismen für die Nutzer mit keinen nennenswerten Einschränkungen verbunden. Anders sieht es hingegen bei UC-Anwendungen aus, insbesondere bei der Durchführung von Videokonferenzen. Hier gibt es einige Herausforderungen, die im Folgenden weiter betrachtet werden.

Herausforderungen bei VDI und Echtzeitkommunikation

Die für den Zugriff auf die Applikationen und virtualisierten Desktops verwendeten Protokolle sind in der Regel nicht für den Einsatz von Echtzeitkommunikation ausgelegt. Vielmehr sind die Protokolle so gestaltet, dass das Streaming der Anwendungen möglichst wenig Bandbreite benötigt. Doch gerade Videokonferenzen bzw. die Übertragung von Videodaten allgemein benötigen wesentlich höhere Bandbreiten als reine Office-Anwendungen. Damit besteht ein Konflikt zwischen einem bandbreitenoptimierten Übertragungsprotokoll und dem unter Umständen hohen Bedarf an Bandbreite durch die UC-Anwendung.

Ein weiteres Problem ist die Nutzung lokaler Hardware und Peripherie-Geräte. In der Regel werden Kamera und ein Headset über Schnittstellen wie USB oder Bluetooth an den Client angebunden. Dort, wo bei der klassischen Bereitstellung von Anwendungen ein direkter Zugriff auf solche Peripherie möglich ist, muss dies bei VDI-Clients zunächst entsprechend eingerichtet werden. Gegebenenfalls ist auch der Zugriff auf die USB-Schnittstelle aus Sicherheitsgründen eingeschränkt, sodass die einwandfreie Funktionsweise der angeschlossenen Geräte nicht sichergestellt werden kann.

Darüber hinaus tritt bei der Nutzung von UC-Clients über eine VDI das sogenannte Hairpinning-Problem auf: Die Medienströme werden in der zentralen Infrastruktur verarbeitet und mithilfe der VDI-Protokolle zu den Clients übertragen. Das bedeutet, dass die Medienströme (sprich die Audio- und Videodaten) vollständig über die LAN-Infrastruktur von den Clients bis zur VDI und zurück laufen müssen (siehe Abbildung 3). Damit werden die Medienströme nicht auf direktem Weg zwischen den beiden Clients übertragen, sondern erzeugen eine hohe Auslastung im internen Netzwerk.

Lösungsoption 1: Entkopplung der Medienströme

Als Ausweg aus dem Hairpinning-Problem kann eine Auskopplung der Medienströme erreicht werden (siehe Abbildung 4). Hierbei werden die Medienströme auf dem kürzesten Weg zwischen den beiden Clients übertragen, wie es auch bei einer klassischen Bereitstellung von UC-Clients der Fall wäre.

Hierzu muss der Client jedoch lokal die Medienströme verarbeiten können. Dies kann durch entsprechende Erweiterungen und Plug-ins erreicht werden.

• Citrix HDX

  Mit der HDX-Technologie können zur Unterstützung von Multimedia-Anwendungen sowohl die serverseitige als auch die clientseitige Wiedergabe von Multimedia-Inhalten verbessert werden. Bei der serverseitigen Wiedergabe von Multimedia-Inhalten werden die Audio- und Videoinhalte auf den zentralen Servern verarbeitet und mithilfe des ICA-Protokolls komprimiert an die Citrix-Workspace-App übertragen. Die Videoverarbeitung erfordert entsprechende Hardware-Ressourcen in der VDI und wird oft auf dedizierter Hardware durchgeführt.

  

  Abbildung 4: Auskopplung der Medienströme

  Bei der clientseitigen Wiedergabe werden die Audio- und Videodaten hingegen von den jeweiligen Clients verarbeitet. Hierbei kann insbesondere die HDX-Webcam-Videokomprimierung genutzt werden, bei der die Videodaten direkt mit H.264 codiert und anschließend über einen virtuellen Kanal, der speziell für die komprimierten Videodaten verwendet wird, übertragen werden (siehe [10]). Damit diese Optimierung genutzt werden kann, muss der Client sowie die Hardware einige Voraussetzungen wie eine hardwarecodierungsfähige Webcam bzw. Kamera erfüllen.

  Sofern die HDX-Webcam-Videokomprimierung nicht genutzt werden kann, ist eine weitere Möglichkeit zur Nutzung von USB-Peripherie die generische HDX-USB-Umleitung für Plug&Play-Geräte. Hierbei wird der USB-Stack so virtualisiert, dass sämtliche Geräte, die an den lokalen Client angeschossen werden, sich so verhalten, als wären sie am VDI-Desktop angeschlossen. Somit übernimmt der virtualisierte Desktop die vollständige Verarbeitung, es erfolgt keine Verarbeitung auf den Clients selbst. Hierdurch wird jedoch wesentlich mehr Bandbreite benötigt, da die unkomprimierten Videodaten mithilfe des USB-Protokolls über das Netzwerk gesendet werden.

• VMware Real-Time Audio-Video (RTAV)

  Die Erweiterung VMware Real-Time Audio-Video (siehe [11]) ermöglicht ähnlich wie HDX eine lokale Verarbeitung der Audio- und Videodaten. Die lokal verarbeiteten Daten werden dann über die von VMware genutzten Übertragungsprotokolle zur Remote-Session übertragen, wobei auch hier die Bandbreite verglichen mit einer USB-Umleitung auf die virtuelle Maschine reduziert ist.

  RTAV ist zwar mit vielen Produkten wie Cisco Webex, Google Hangouts, Microsoft Teams und weiteren Lösungen kompatibel, jedoch sollte die korrekte Funktionsweise im konkreten Setting geprüft werden.

• Microsoft Media-Umleitung in Azure Virtual Desktop

  Auch Microsoft bietet eine Multimedia-Umleitung (multimedia redirection, mmr) an (siehe [12]). Allerdings beschränkt sich ihre Funktion derzeit nur auf das Abspielen von Videodaten, für Anrufe ist die Funktionalität noch im Preview-Modus. Zudem ist die Optimierung der Audio-Datenströme lediglich für WebRTC-basierte Lösungen verfügbar. Die Abbildung 5 zeigt die Funktionsweise der Multimedia-Umleitung.

Lösungsoption 2: Nutzung lokaler Clients

Als weiterer Ausweg wird oft der UC-Client direkt auf dem Client ausgeführt und nicht innerhalb der VDI. Dies ist jedoch nur dann möglich, wenn der Client die Hardware-Anforderungen für die UC-Anwendungen erfüllt. Insbesondere bei einigen Thin Clients, die lediglich als Betrachtungsgeräte fungieren, ist die Hardware-Ausstattung nicht für eine vollumfängliche Nutzung der UC-Dienste ausgelegt. Während reine Audio-Übertragungen meist noch ohne nennenswerte Einschränkungen möglich sind, bereitet die Nutzung von Video-Diensten größere Probleme oder ist aufgrund fehlender Hardwareunterstützung gar nicht erst möglich. Doch auch wenn der UC-Client direkt auf dem Client ausgeführt wird, kann es Einschränkungen in der Nutzung geben. So kann eine Integration in Anwendungen, die über die VDI ausgeführt werden, gegebenenfalls nicht möglich sein. Das bedeutet, dass Nutzer, die eine Kommunikation aus einer Office-Anwendung oder aus einem Outlook-Client heraus starten wollen, die innerhalb der VDI bereitgestellt werden, den Namen oder die Nummer des Kommunikationspartners in den UC-Client, der direkt auf dem Client ausgeführt wird, umständlich eingeben müssen. Ein Copy-and-Paste wird in vielen Fällen aus Sicherheitsgründen unterbunden, sodass diese Möglichkeit nicht genutzt werden kann, und dadurch die Einwahldaten zu Konferenzen beispielsweise händisch in den UC-Client eingegeben werden müssen.

Im Wesentlichen spaltet die Nutzung lokaler UC-Clients und weiterer Anwendungen, die über eine VDI zur Verfügung gestellt werden, die Arbeitsumgebung der Nutzer in zwei Welten. Um diese Welten miteinander zu verbinden, gibt es bei einigen UC-Lösungen (beispielsweise innovaphone, siehe [13]) die Möglichkeit, einen UC-Client sowohl auf dem lokalen Client als auch in der VDI zu implementieren, die dann über entsprechende Schnittstellen verbunden werden. So kann der UC-Client innerhalb der VDI-Umgebung den lokal installierten UC-Client steuern. Der Nutzer kann somit einen Einladungslink aus einem E-Mail-Programm direkt innerhalb der VDI-Umgebung anklicken und muss diesen nicht umständlich in den lokal installierten Client bringen. Dies setzt jedoch voraus, dass der UC-Client einwandfrei auf dem lokalen Client installiert werden kann und dort die notwendigen Ressourcen vorhanden sind.

Für Thin Clients, die aufgrund der reduzierten Hardware-Ausstattung keine lokale Installation eines UC-Clients ermöglichen, kann zumindest für die Audio-Kommunikation ein Tischtelefon genutzt werden. Das Tischtelefon ist mit eigener Hardware ausgestattet, sodass die Medienströme nicht innerhalb der VDI verarbeitet werden müssen. Um trotzdem UC-Funktionen wie Chat und Computer Telephony Integration (CTI) nutzen zu können, kann innerhalb der VDI ein UC-Client installiert werden, der diese Funktionen sowie eine Steuerung des Tischtelefons bereitstellt. Hiermit kann jedoch keine Video-Kommunikation umgesetzt werden.

Fazit

Die virtualisierte Bereitstellung von Applikationen oder gar einem gesamten Desktop ist auch heute noch weit verbreitet. Einerseits werden vielfach spezielle Thin Clients eingesetzt, die lediglich zur Betrachtung der Inhalte dienen. Andererseits werden auch klassische Windows-basierte PCs und Laptops genutzt, die über entsprechende Anwendungen einen Zugriff auf die virtualisierten Applikationen ermöglichen. Eine Bereitstellung von UC-Diensten über eine VDI-Infrastruktur steht zum Teil im Widerspruch zu den von gängigen VDI-Lösungen eingesetzten Protokollen. Zwar gibt es hier vielfach Ergänzungen, die die Verarbeitung von Audio- und Videodatenströmen aus der virtuellen Infrastruktur herauslösen und lokal auf dem Client erlauben. Ebenso kann ein UC-Client auch lokal auf dem genutzten Client ausgeführt werden. Beides stellt jedoch für Thin Clients, die aufgrund fehlender Ressourcen dazu nicht in der Lage sind, eine besondere Herausforderung dar. Als Lösung bleibt hier vielfach lediglich die Nutzung von Tischtelefonen, die über virtualisierte UC-Clients gesteuert werden können.

Allerdings sind die Erweiterungen der VDI-Lösungen, wie Citrix HDX, VMware RTAV und Microsoft Multimedia-Redirect, kein Allheilmittel. Gerade die videobasierte Kommunikation kann aufgrund der notwendigen Bandbreite zwischen VDI-Client und VDI-Servern oft nicht in ausreichender Qualität zur Verfügung gestellt werden. Eine reine Audio-Kommunikation benötigt hier wesentlich weniger Bandbreite und kann auch bei virtualisierten UC-Clients in guter Qualität genutzt werden. Jedoch ist die ordnungsgemäße Funktionsweise der Erweiterungen auch abhängig von der genutzten UC-Lösung und sollte vor einer flächendeckenden Einführung zunächst ausführlich getestet werden. Insbesondere die Anbindung von USB-basierter Peripherie wie Kamera und Headset sollte direkt am Client geschehen und nicht über ein Redirect in der virtuellen Umgebung realisiert werden.

Verweise

[1] https://techzone.vmware.com/resource/horizon-architecture#components
[2] https://docs.citrix.com/de-de/xenapp-and-xendesktop/7-15-ltsr/technical-overview
[3] https://learn.microsoft.com/de-de/troubleshoot/windows-server/remote/understanding-remote-desktop-protocol
[4] https://learn.microsoft.com/de-de/azure/virtual-desktop/compare-remote-desktop-clients
[5] https://www.heise.de/hintergrund/Remote-Desktop-via-RDP-Was-genau-ist-das-und-wieso-ist-das-boese-2-4-4700646.html
[6] https://docs.citrix.com/de-de/citrix-virtual-apps-desktops/technical-overview/virtual-channels.html
[7] https://docs.citrix.com/de-de/citrix-virtual-apps-desktops/policies/reference/ica-policy-settings/security-policy-settings.html
[8] https://docs.vmware.com/de/VMware-Horizon-7/7.13/horizon-installation/GUID-E2FFCC1F-B14A-4A4E-A36C-994EACC542B6.html
[9] https://docs.vmware.com/de/VMware-Horizon-7/7.13/horizon-architecture-planning/GUID-F64BAD49-78A0-44FE-97EA-76A56FD022D6.html
[10] https://docs.citrix.com/de-de/citrix-virtual-apps-desktops/multimedia/webcam-compression
[11] https://docs.vmware.com/en/VMware-Horizon/2306/horizon-remote-desktop-features/GUID-D6FD6AD1-D326-4387-A6F0-152C7D844AA0.html
[12] https://learn.microsoft.com/en-us/azure/virtual-desktop/multimedia-redirection-intro
[13] https://wiki.innovaphone.com/index.php?title=Howto:Softwarephone_and_terminal_server_enviroment_or_thin_clients