VDI aus der Cloud

06.04.2018 / Markus Schaub / Referent

aus Netzwerk Insider Ausgabe April 2018

Virtuelle Desktop-Umgebungen sind nun wirklich nichts Neues. Schon lange gibt es Terminal-Serverdienste für unterschiedliche Anforderungen: sei es die Remote-Administration des eigentlichen Servers oder das Streaming von einzelnen, zentral gehosteten Anwendungen.

Manch einer hält sie sogar in Zeiten von mobilen Apps und Webanwendungen wie Office 365 oder G-Suite für eine aussterbende Art. Andere wiederum sehen sie als wichtigen Baustein für eine vollständig „cloudifizierte“ IT mit dummen Clients der Marke Chrome OS und Co. „Cloud“ ist für diesen Artikel das Stichwort, denn in der Tat beobachten wir, dass immer mehr Anwendungen in die Cloud verlagert werden und es zudem Kunden gibt, die bei der Planung neuer Standorte, eigene Rechenzentren gar nicht mehr berücksichtigen. Das sind aber nur zwei Beispiele, warum es interessant sein kann, virtuelle Desktops nicht selbst zu hosten, sondern ihren Betrieb in die Cloud zu verlagern. Dabei gibt es nicht nur verschiedene Angebote der Cloud Provider, sondern auch Anforderungen wie ausreichend Bandbreite, die kundenseitig erfüllt werden müssen. Dieser Artikel zeigt exemplarisch auf, welche Stärken aber auch Schwächen eine VDI-Struktur in der Cloud mit sich bringt und welche Voraussetzungen vorhanden sein müssen.

Dazu werden die zwei Varianten „Virtual Desktop“ und „Application Streaming“ anhand der AWS Implementierung vorgestellt und verglichen. Das Augenmerk liegt dabei auf den infrastrukturellen Voraussetzungen. Die Verwaltung der virtuellen Umgebungen und der Software würde den Rahmen eines einzelnen Artikels weit übersteigen.

Desktop

Virtuelle Desktops heißen “WorkSpaces” bei AWS.

Wer glaubt, bei WorkSpaces handelt es sich nur um das Starten eines virtuellen Rechners und der Verbindung per Browser dorthin, täuscht sich. Bevor man die eigentlichen virtuellen Desktops aufsetzen kann, sind einige Vorbereitungen notwendig: Netzwerke müssen angelegt, Zugiffsbeschränkungen und Freigaben vorbereitet sowie der spätere Internet-Access der WorkSpaces, so denn gewünscht, sichergestellt werden.

Voraussetzung: Netzwerk
Zunächst sollte man prüfen, ob die Virtual Private Cloud (VPC), in der die WorkSpaces laufen sollen, die notwendigen Voraussetzungen erfüllt und wenn nicht, diese einpflegen. Dabei geht es konkret um drei Punkte: Netzwerk-Design, Internet-Access und Sicherheit/Zugriffbeschränkung.

Die virtuellen Desktops werden netzwerktechnisch später Subnetzen zugeordnet werden. Um ihnen bei Bedarf im weiteren Verlauf Zugriff auf das Internet zu gewähren, gibt es drei Varianten:

NAT
Dynamische IP
Manuelle IP

Empfohlen wird NAT. Für eine Handvoll oder gar nur einen einzelnen WorkSpace wäre das natürlich übertrieben, jedoch macht es durchaus Sinn, eine ganze Farm von WorkSpaces via NAT mit dem Internet zu verbinden, da so IPv4 Adressen eingespart werden. Also genau so, wie es bei realen Desktops im Unternehmen auch gehandhabt würde. Grundsätzlich ist auch IPv6 möglich, jedoch gibt es da noch (?) Beschränkungen was die Ausstattungsvarianten der Virtuellen Desktops angeht: die beiden leistungsfähigsten Bundles „Performance“ und „Graphics“ unterstützen keine automatische IPv6-Zuweisung.

Abbildung 1 zeigt, wie das Design mittels NAT-Gateway aussieht. Die in der Abbildung dargestellten Tabellen entsprechen den Routingtabellen der Subnetze: während die WorkSpaces das NAT-Gateway als Default Gateway eingestellt haben, nutzt das Default Gateway selbst natürlich das Internet Gateway des VPC.

Abbildung 1: WorkSpaces Design mit NAT

Gemäß der Sicherheitsmaxim „Microsegmentierung“ legt man als nächstes die Access-Listen und Security Groups für die WorkSpaces an. Dabei müssen eine Reihe von Ports geöffnet werden, damit die verschiedenen Remote-Zugänge funktionieren. Der Remote-Client benötigt für das PCoIP den Port 4172 für UDP und TCP, für den Webzugang braucht man die UDP (!) und TCP Ports 80 und 443. Hinzu kommt noch inbound der TCP Port 8200 für das Management und UDP Port 55002 für PCoIP Streaming.

Zu diesen Sicherheitsregeln, die nur für die Verwaltung und den Zugriff auf die WorkSpaces benötigt werden, kommen natürlich noch sämtliche Sicherheitsregeln, die man für andere Systemdienste innerhalb der Subnetze benötigt (bspw. für das Active Directory, bzw. den AD-Connector, DNS, NTP, etc.). Außerdem muss man ggf. Ports für die Anwendungen freigeben, die später auf den virtuellen Desktops laufen.

Abbildung 2 zeigt ein Beispiel für eine ausgehende Access-Liste. Man kann schon an diesem minimalistischen Beispiel sehen, dass das sehr schnell sehr unübersichtlich werden kann. Insbesondere wenn man sowohl mit Access-Listen als auch mit Security Groups arbeitet. Eine aktuelle und übersichtliche Dokumentation ist hier Pflicht!

Abbildung 2: Beispiel für eine ausgehende ACL für WorkSpaces

Will man die Sicherheit weiter erhöhen, so kann man den Zugriff auf die WorkSpaces einschränken. Per Default ist der Zugriff von allen Geräten mittels Client aus möglich, der Zugriff über Webbrowser hingegen nicht. Das kann jedoch leicht auf bestimmte Clients eingeschränkt werden. Insb. ist es ratsam, Tablets und erst recht Smartphones auszuschließen, da die meisten Windows Anwendungen dafür nicht geeignet sind. Das spart dann jede Menge Nerven beim Support. Ein wirklicher Sicherheitsgewinn ist das jedoch noch nicht. Der nächste Schritt ist die Arbeit mit Zertifikaten: man kann den Zugriff auf die WorkSpaces so beschränken, dass der Client beim Verbindungsaufbau ein gültiges, bekanntes Zertifikat vorweisen muss, dessen Gegenpart zuvor im Directory hinterlegt wurde. So kann man sicherstellen, dass nur „zertifizierte“ Clients Zugriff auf die eigenen WorkSpaces haben. Insbesondere für mobile User, bei denen eine Zugriffsbeschränkung über die IP Adressen mittels Access-Listen oder Security Group nicht möglich ist, ist das eine gute Alternative.

Voraussetzung: Directory Service
Wer Workspaces betreiben möchte, muss die späteren User der virtuellen Desktops in einem Active Directory speichern und dort deren Zugriffsrechte verwalten. Hat man für AWS noch keine AD-Funktionalitäten konfiguriert, muss man das zwingend tun, bevor man mit den WorkSpaces beginnen kann. Dafür stehen einem mehrere Varianten zur Verfügung:

„Microsoft AD“
Damit meint Amazon ein bei AWS gehostetes AD.
„AD Connector“
Wer ein eigenes, on-premise AD betreibt, kann dieses mit der AWS Cloud verknüpfen und so seine User im eigenen RZ pflegen.
„Cross trust“
In diesem Fall betreibt man zwei Microsoft AD, eines on-premise, eines in der Cloud. Zwischen beiden kann dann ein Vertrauensverhältnis etabliert werden, so dass man letztlich wieder die lokalen User für die WorkSpaces nutzen kann.
„Simple AD“
Hinter „Simple AD“ verbirgt sich ein Microsoft kompatibles AD, das jedoch auf Samba 4 gehostet wird. Dieses läuft dann ebenso wie das Microsoft AD in der AWS Cloud.

Vorteil des Simple AD ist, dass es kostengünstiger ist, der Nachteil ist, dass es zur Zeit in Frankfurt nicht zur Verfügung steht.

Wer WorkSpaces zunächst einmal ausprobieren möchte, ohne großen Aufwand in das AD zu stecken, sollte die Simple AD Variante nutzen. Innerhalb der EU kann man das Stand heute allerdings nur in der Region Irland. Die Performance dürfte auch für den Realbetrieb in den meisten Fällen völlig ok sein. Unsere eigene Erfahrung ist, dass das für Tests allemal ausreicht.

Legt man seinen ersten WorkSpace an, so hat man die Option Quick und Advanced. Wie schon in einem anderen Artikel zum Thema Netzwerkdesign in der Cloud erwähnt, sollte man keinesfalls auf den Gedanken kommen, die Quick Variante zu nutzen, die ist nämlich wirklich „dirty“. Egal ob man schon eigene Subnetze, VPCs oder ein AD eingerichtet hat, bei Quick wird all das nochmal angelegt. Damit braucht man nachher viel Zeit, um all das wieder los zu werden, außerdem zahlt man für den Nutzungszeitraum doppelt: für das Test AD und für das bereits in Betrieb genommene.

Wer also noch kein AD oder AD Verküpfung für AWS angelegt hat, sollte damit beginnen, ein Simple-AD anzulegen. Um ein AD erfolgreich in Betrieb zu nehmen, benötigt man mindestens zwei Subnetze jeweils in einer anderen Availability Zone. Auch diese Subnetze sollte man, falls nicht bereits vorhanden, besser vorher bereits angelegt haben. Die User kann man später noch hinzufügen.

Anlegen der WorkSpaces
Ist alles vorbereitet, kann man seinen ersten WorkSpace anlegen: zunächst wählt man das AD aus, dem der virtuelle Client zugeordnet werden soll. Anschließend bestimmt man einen oder mehrere User als Nutzer des Clients. Dabei ist es sowohl möglich neue User anzulegen als auch bestehende aus dem AD-Verzeichnis auszuwählen. Danach wählt man das Betriebssystem des Clients und dessen virtuelle Hardwareumgebung aus. Zur Verfügung stehen Stand heute nur die Betriebssysteme Windows 7 und Windows 10. Windows 8 sucht man vergebens, ebenso wie Linux. Bei der virtuellen Hardwareumgebung werden verschiedene Klassen unterschieden:

Standard
2 virtuelle CPUs, 4 GB RAM, 80 GB Root-Partition, 50 GB User-Partition
Value
1 virtuelle CPUs, 2 GB RAM, 80 GB Root-Partition, 10 GB User-Partition
Performance
2 virtuelle CPUs, 7.5 GB RAM, 80 GB Root-Partition, 100 GB User-Partition
Graphic
8 virtuelle CPUs, 15 GB RAM, 1 GPU, 4 GB Videospeicher, 100 GB Root-Partition, 100 GB User-Partition
Power
4 virtuelle CPUs, 16 GB RAM, 175 GB Root-Partition, 100 GB User-Partition

Die Preise reichen von 8 USD pro Monat zzgl. 0,23 USD pro Stunde für die kleinste „Value“ Variante bis hin zu 23 USD pro Monat zzgl. 1,97 USD pro Stunde für die Graphikvariante. Die Preise gelten für Dublin, in Frankfurt ist die Monatsgebühr jeweils 1 USD höher und auch die Nutzungsgebühr pro Stunde ist einige Cent teurer. Wem der Root- oder User-Speicherplatz nicht reicht, kann diesen erhöhen – kostenpflichtig versteht sich.

Neben dem Betriebssystem und der Hardware kann man bei Bedarf auch gleich noch ein Microsoft Office mit installieren lassen.

Als Nächstes legt man den „Running Mode“ fest. Es stehen zwei zur Auswahl:

AlwaysOn
Das bedeutet, dass der Client jederzeit sofort zur Verfügung steht.
AutoStop
In diesem Modus wird der Client nach einiger Zeit Nicht-Benutzung heruntergefahren und erst bei Bedarf wieder neu gestartet. Die Zeit zwischen letzter Nutzung und Herunterfahren gibt man beim Anlegen des WorkSpaces vor. Möglich sind dabei Zeiten zwischen einer Stunde und zwei Tagen, allerdings können nur volle Stunden definiert werden.

Die Vor- und Nachteile beider Running Modes liegen auf der Hand. Bei AlwaysOn können die User ohne Zeitverzug auf die Ressourcen des WorkSpaces zugreifen. Das sorgt für glückliche User, allerdings auch für hohe Kosten, da die Nutzungskosten durchgehend gezahlt werden müssen. AutoStop hat den Vorteil, dass die Betriebskosten deutlich niedriger sind, allerdings muss der Nutzer darauf warten, dass das System erstmal bootet, bevor er auf die Ressourcen zugreifen kann. Der Start eines virtuellen Deskops dauert durchaus mehrere Minuten.

Zuletzt legt man fest, ob die Festplattenpartition verschlüsselt werden sollen oder nicht. Für den Fall, dass das gewünscht ist, gibt man den Schlüssel an, der genutzt werden soll und ob das sowohl für die User- als auch für die Root-Partition oder nur für eine der beiden gelten soll.

Nun kann der WorkSpace initialisiert werden.

Clients
Dem User stehen anschließend verschiedene Zugangsmöglichkeiten zur Verfügung. Für die Betriebssysteme Windows, Mac OS und Chromebook sowie den Tablets iPad, Android und wenig überraschend auch dem Fire Tablet stehen Clients zur Verfügung. Diese lädt man herunter und installiert sie auf den jeweiligen Systemen. Zusätzlich gibt es noch die Option eines Zugriffs über einen Web-Browser. Welche Clients man zulassen möchte, kann man einstellen. Das gilt auch für den Web-Browser-Zugriff, der per default Einstellung zunächst nicht möglich ist.

Als Client kommen neben den von Amazon bereit gestellten Client-Anwendungen alle PCoIP-Clients infrage. Amazon stellt eine Liste kompatibler Geräte zur Verfügung. Es wird jedoch empfohlen diese vor Anschaffung zu testen.

Interessant ist die Auflösung, die sich mit den Clients erreichen lässt:

Bis zu zwei 4K Monitore (3840 x 2160) oder
Bis zu vier Full-HD Monitore (1920 x 1200)

Dabei ist allerdings zu beachten, dass diese hohe Auflösung nur mit den Power Paketen zu realisieren ist. Ferner steigt natürlich der Bandbreitenbedarf pro Arbeitsplatz je größer die Auflösung ist. Dazu später mehr.

Unternehmensfirewall
Bevor man die User nun aber wirklich einladen kann, muss man noch eine ganze Reihe von Sicherheitseinstellungen auf der Firewall vornehmen.

Zum einen wären da die entsprechenden Portfreigaben. Die Ports entsprechen dabei denen, die zuvor für die Access-Listen und Security Groups für das AWS Netz schon genannt wurden.

Jedoch können die sich je nach Zugangsvariante unterscheiden: die Workspace-Clients benötigen erheblich mehr an Firewall Regeln als es der Browser Zugriff tut. Das muss man je nach eigener Firewall beachten. Arbeitet man bspw. mit einer Next Generation Firewall, die User identifizieren kann, müssen für die User die richtigen Regeln definiert werden. Grundsätzlich liegt der Unterschied darin, dass der Client für das Streaming PCoIP als Protokoll nutzen. PC over IP (kurz PCoIP) streamt bevorzugt über UDP 4172, es kann aber als Backup auch TCP. Wie dem auch sei, dieser Port muss auf jeden Fall bei Nutzung des Clients frei gegeben werden. Wer diese Freigabe weiter einschränken will, kann im AWS Administration Guide nachlesen, welche IP-Adressen und welche DNS-Namen für welche Dienste freigegeben werden müssen, damit der Zugriff funktioniert. Diese sind naturgemäß für die verschiedenen AWS-Regionen unterschiedlich.

Doch auch der Zugriff über Web-Browser gestaltet sich nicht unkompliziert. Zunächst einmal werden nur Chrome und Firefox unterstützt und diese verhalten sich auch noch unterschiedlich: für den Web-Access werden die Ports 53 (DNS) sowie 80 und 443 benötigt. Für das DNS kann natürlich wie gehabt der Firmen-DNS-Server genutzt werden, so dass dafür keine Firewall-Regeln erforderlich werden. Spannender werden die Ports 80 für http und 443 für https, denn der Streaming-Server möchte statt wie gewohnt TCP lieber UDP nutzen. Falls UDP nicht funktioniert, steht grundsätzlich TCP zur Verfügung. Das funktioniert zwar mit Chrome, jedoch nicht mit Firefox. Für letzteren gilt, entweder klappt die Verbindung mittels UDP oder es geht gar nichts. Nun ist http bzw. https über UDP aber ausgesprochen ungewöhnlich und die meisten Firewalls werden es blockieren.

Bandbreiten und Roudtrip
Wesentlich für das Usererlebnis sind die Verbindungsparameter Delay und Bandbreite. AWS gibt an, dass die Roundtrip-Zeit für ein ungetrübtes Virtual-Desktop-Erlebnis unter 100ms bleiben sollte; zwischen 100 und 250ms wäre arbeiten zwar möglich, aber die Performance würde darunter leiden. Darüber hinaus sollte man es besser bleiben lassen. Auf Basis dieser Roudtrip-Zeit gibt Amazon an, dass die maximale Entfernung zwischen dem Rechenzentrum von AWS und dem Client 3600km nicht überschreiten sollte.

Abbildung 3: Bandbreitenbedarf WorkSpace Client

Schwieriger wird es bei der Frage, wieviel Bandbreite pro Client benötigt wird. Das genutzte PCoIP-Protokoll für den Remote-Zugriff ist grundsätzlich dynamisch, insbesondere wenn nichts passiert, wird auch wenig übertragen. Da Bilder übertragen werden, spielt die Anzahl und Größe der Bildschirme auf Seite des Clients natürlich eine Rolle. Entsprechend findet man bei AWS keine konkreten Angaben über die Bandbreite.

Abbildung 3 zeigt eine Wiresharkaufzeichnung einer laufenden WorkSpace-Verbindung mittels Client. Gestreamt wurde auf einen Monitor mit einer Auflösung von 1920×1080. In den ersten 120 Sekunden wurde im Internet gesurft, dabei wurde bewusst eine Bilddatenbank aufgerufen, so dass sich möglichst viele Pixel in kurzer Zeit ändern. Wie man sehen kann, übersteigt der Bedarf 600kByte/s nicht, was immerhin 4,8 Mbit/s für einfaches Surfen in HD sind. Nach ca. 2 Minuten wurde dann ein Video auf youtube gestartet. Man erkennt leicht den sprunghaften Anstieg auf knapp 3,6 Mbytes/s, das sind dann schon satte 28,8 Mbit/s für einen einzelnen User mit einem Standard-Monitor.

Abbildung 4: Direkter Zugriff auf dasselbe youtube Video

Zum Vergleich zeigt Abbildung 4 den Bandbreiten-Bedarf, wenn man auf demselben Monitor das Video direkt von youtube streamt. Man sieht sehr schön den progressiven Download, denn nach 75sec ist das komplette Video heruntergeladen, gestoppt wurde Wireshark, nachdem es vollständig durchgelaufen war. Der Download hat eine Geschwindigkeit von 700 kByte/s, also 5,6 Mbit/s. Zudem läuft er nur für ca. die Hälfte der Wiedergabezeit. Er hätte bei schlechterer Verbindung also problemlos gestreckt werden können, ohne dass der User etwas davon gemerkt hätte.

Bedenkt man, dass bis zu 4 Full-HD bzw. 2 Ultra-HD Monitore in Verbindung mit dem Cient genutzt werden können, summiert sich je nach Anwendung ein riesiger Bandbreitenbedarf für einen einzelnen User auf. Andererseits zeigt das Beispiel in Abbildung 3 aber auch, dass der Bedarf stark davon abhängt, was ein User gerade macht. Eine verlässliche Aussage für den Bedarf pro User ist somit seriös nicht möglich. Wer WorkSpaces betreiben will, sollte diese nur sukzessive Ausrollen und dabei ständig die Auslastung der Verbindung überwachen.

Application Streaming

Neben dem Streamen der gesamten Desktop Umgebung bietet AWS an, nur bestimmte Anwendungen in der Cloud zu hosten und den Anwendern als Stream zur Verfügung zu stellen. Der von Amazon dafür gewählte Name ist „AppStream 2.0“. Die dabei genutzte Technik ähnelt dem Desktop Streaming naturbedingt, jedoch gibt es sowohl im Betrieb wie auch bei den Voraussetzungen signifikante Unterschiede.

Voraussetzung: Netzwerk
Anders als bei den Workspaces gibt es bei AppStream nur die Browser-Variante. Entsprechend fallen die notwendigen Konfigurationen für das Netzwerk schlichter aus.

Da nur Bowser als Clients genutzt werden können, reicht es, wenn die Inbound Access-Listen und Security Groups http (80) und https (443) für den Zugriff aus dem Internet zulassen.

Für das Management und AWS Interne Streamingverbindungen müssen auch noch die Inbound Ports 8300 und 8443 frei gegeben werden. Diese Freigaben können und sollten auf das Netz 198.19.0.0/16 beschränkt werden, so dass sie aus dem Internet nicht erreicht werden können.

Weitere Portfreigaben werden notwendig, wenn man statt mit den lokalen Usern einen Directory Service nutzt. In diesem Fall entsprechen die notwendigen Freigaben denen, die auch bei den WorkSpaces vorgenommen werden müssen.

Für den Zugriff benötigt man natürlich öffentliche IP Adressen, dafür stehen zwei Möglichkeiten zur Verfügung:

Zugriff über das Public Subnet
In diesem Fall wird über das so genannte Pubic Subnet eines VPC auf die Anwendungsserver zugegriffen. Die User nutzen dafür eine URL, die man beim Anlegen der AppStreams generiert.
NAT
Alternativ kann auch bei den AppStreams mit einem NAT Gateway gearbeitet werden. Auch in diesem Fall erfolgt aus Sicht des Users der Zugriff über die URL.

Entscheidend für die Frage, ob man das NAT Gateway oder lieber das Public Subnet nimmt, ist also nicht der Zugriff für die User, sondern ob man bereits ein NAT Gateway hat oder nicht und wie viele AppStreams man aufsetzen möchte.

Zusätzlich benötigt man mindestens ein Private Subnet. Man kann aber auch zwei in unterschiedlichen Availability Zonen nutzen, wie es bei den WorkSpaces Pflicht war.

Voraussetzung: Directory Service / Userhandling
User, die auf die bereitgestellten Anwendungen zugreifen wollen, müssen sich natürlich zuvor identifizieren. Dafür kann ein Directory Service, wie das Active Directory, durchaus genutzt werden, aber anders als bei den WorkSpaces ist ein Directory nicht zwingend erforderlich. Alternativ können die User auch an derselben Stelle angelegt werden, wo auch die anderen Konfigurationen des AppStream vorgenommen werden. Diese Userdaten stehen dann aber nur für das AppStream zur Verfügung und müssen dort auch gepflegt werden. Wer also ein Directory betreibt oder in Zukunft betreiben möchte, sollte von vornherein lieber auch bei den gestreamten Apps damit arbeiten, sonst haben die User zumindest sehr bald andere Passwörter für das Streamen als für die Anmeldung am Active Directory.

Den Usern werden „Stacks“ zugeordnet, wobei ein User durchaus mehreren Stacks zugeordnet sein kann und ein Stack von mehreren Usern genutzt werden kann. Dazu gleich mehr.

Anlegen der Umgebung
Um AppStream 2.0 zu verstehen, muss man die drei Elemente kennen, aus denen es sich zusammensetzt:

Images
Ein Image ist das Abbild einer Arbeitsumgebung. Wichtig ist es zu verstehen, dass es sich dabei um eine Datei handelt, ähnlich einer nicht gestarteten Virtuellen Maschine. AWS bietet eine Reihe von Basis-Images an, auf denen man aufsetzt. Bei allen Images ist das Betriebssystem Windows Server 2012 R2. Keines der Basis-Images stellt von sich aus Anwendungen zur Verfügung. Das muss man später selbst erledigen. Neben den „Base“ Images werden verschiedene „Graphics“ Images angeboten, die für verschiedene Anforderungen optimiert sind („Desktop“, „Pro“ und „Design“) und auf unterschiedlicher Hardware laufen. Wenn man AppStream für Graphikanwendungen nutzen will, wird man nicht umhinkommen, zu testen, welches Image für einen das Beste ist. Erste Hinweise dafür findet man in der FAQ bei AWS.Um ein eigenes Image inkl. der später angebotenen Anwendungen zu generieren, nutzt man ein Tool namens Image Builder, das man über die AWS Console erreicht. Zunächst wählt man ein vorhandenes Image als Basis aus. Das kann ein AWS Image sein oder auch eines, das man selbst in der Vergangenheit schon einmal erzeugt hat. Im nächsten Schritt wählt man die Hardware aus, auf der das Image gestartet werden soll. Dabei ist die angebotene Hardware abhängig vom ausgewählten Image. So unterscheiden sich die unterschiedlichen Graphik-Images z.B. in der GPU. Somit verbleiben Anzahl der virtuellen CPUs und das RAM als auswählbare Parameter. Zusätzlich bekommt das Image noch einen Namen und man ordnet ihm User bzw. einen Directory Service sowie den VPC und das Subnetz zu. Danach wird das Image erstellt. Wichtig ist zu verstehen, dass die zugeordneten Subnetze nur für die Generierung und Konfiguration des Images genutzt werden, nicht für den späteren Betrieb. Dasselbe gilt für die CPU und RAM Auswahl.

Damit hat man noch keine Anwendungen installiert oder gar frei gegeben. Das geschieht, nachdem das eigene Image fertig ist und man es gestartet hat. Dann kann man sich über den Image Builder mittels „Connect“ auf die Desktop-Umgebung des Images verbinden.

Die Anwendungen, die man später freigeben möchte, kann man nun installieren. Dazu kann man die Installationsdateien mittels Upload Funktion vom eigenen Rechner in das temporäre Verzeichnis des Server hochladen oder die Anwendung aus dem Internet herunterladen.

Auf dem Desktop des Virtuellen Servers findet man die Anwendung „Image Assistant“. Diese nutzt man, um auf dem System installierte Anwendungen für das Streamen frei zu geben. Abbildung 5 zeigt den Startbildschirm des „Image Assistant“.

Abbildung 5: Hinzufügen frei gegebner Anwendungen bei AppStream 2.0

Wenn man fertig ist, beendet man den Image Builder und es wird ein aktualisiertes Image mit den installierten Anwendungen und Freigaben erstellt.
Fleets
Basierend auf dem erstellten Image kann man nun eine Fleet erzeugen. Eine Fleet ist die Umgebung, in der die Virtuellen Systeme laufen. Um verschiedene Umgebungen anbieten zu können, bekommen diese beim Anlegen zunächst einen Namen. Dann ordnet man der Flotte das zu nutzende Image zu. Hier legt man die virtuellen Server Parameter fest, also Anzahl CPU und verfügbares RAM, die später dem User zur Verfügung stehen.Wie bei den WorkSpaces gibt es auch bei den AppStreams zwei Betriebsmodi: „On-Demand“ und „Always-On“. Der Unterschied ist derselbe wie beiden WorkSpaces, wobei „On-Demand“ dem „AutoStop“ der WorkSpaces entspricht. Mit dem Unterschied, dass der Start der Anwendungen schneller ist als der der Desktop Umgebung. AWS gibt dafür ca. 2 Minuten an, was unseren Tests entspricht. Daneben können weitere Parameter festgelegt werden.

Am Spannendesten ist dabei die Skalierbarkeit: man legt fest, wie viele Instanzen es mindestens und wie viele es höchstens geben darf. Zudem legt man fest, wann wie viele weitere gestartet werden, solange die Höchstgrenze noch nicht überschritten ist, bzw. bei welchen Parametern laufende Instanzen beendet werden, solange die Untergrenze nicht unterschritten wird. Um das zu verstehen, muss man sich nochmal bewusst machen, dass AppStreamen nichts anderes ist, als ein Terminal Server, nur zeigt er statt des gesamten Desktops nur einzelne Anwendungen. Deswegen kann eine Instanz mehrere User bedienen. Was man festlegt, ist ab welcher Auslastung der Instanz eine weitere für neue User gestartet werden soll.

Abschließend werden die Flotten dann noch ein oder zwei Subnetzen zugeordnet und festgelegt, ob die Instanzen Internet Access haben oder nicht.

Nachdem die Flotte angelegt wurde, kann man ihr auch noch eine Security Group zuordnen.
Stacks
Als letzten Schritt legt man dann die Stacks an. Ein Stack ist der Rahmen, in dem eine Fleet arbeitet. So legt man die URL fest, zu der die User umgeleitet werden, wenn sie die Sitzungen beenden und man kann eine Feedback URL festlegen, wenn man das den Usern anbieten möchte. Außerdem kann man das Branding auf das Firmen-CI anpassen, eine eigene URL für den Zugriff festlegen und ein Favicon hochladen.Wirklich spannend an der Konfiguration der Stacks ist jedoch, dass hier eine Verknüpfung zum S3 hergestellt werden kann. Diese erzeugt für jeden User ein S3 Verzeichnis, das beim Start jeweils mit dem Home-Directory des Users verlinkt wird. So kann jeder Nutzer seine Daten dort speichern und in späteren Sitzungen auf diese wieder zugreifen. Unabhängig von der Instanz, auf die er gerade zugreift. Wenn man den Zugriff erlaubt, können die User über das S3 auch Dateien unabhängig vom AppStream hoch- und runterladen.

Hat man alles vorbereitet, kann man die User den Stacks zuordnen. Wenn man das getan hat, bekommen die User eine E-Mail mit ihren Userdaten zugesendet.

Abbildung 6 zeit die beiden Login-Bildschirme: zunächst muss sich der User authentifizieren, anschließend kann er die Anwendung auswählen, die er starten möchte.

Abbildung 6: Login bei AppStream

Clients
Als Client kommt jeder moderne Web-browser infrage, solange er HTML5 unterstützt. Es gibt also keine Einschränkung auf Firefox und Chrome, wie das bei den WorkSpaces der Fall war.

Allerdings steht auch kein Client zur Verfügung. Naturbedingt bedient ein Browser
(-Tab) immer nur einen Monitor und selbst den nicht in beliebiger Größe. Stand heute ist die maximale Auflösung auf 2560×1440 Pixel beschränkt, das ist besser als Full-HD, aber 4k2k ist das auch noch nicht. Selbst diese Auflösung steht nur für Graphics Design-, Graphics Pro- und Graphics Desktop-Instanzen zur Verfügung.

Unternehmensfirewall
Ebenso wie bei den Netzwerk-Einstellungen sind auch die Anpassungen auf der Unternehmensfirewall einfacher. Wer mit reinen Portfiltern arbeitet, muss nur die Ports für http (80) und https (443) freigeben. Etwas komplizierter wird es bei den Next Generation Firewalls, dort muss man ggf. den entsprechenden Amazon Dienst, für die berechtigte User frei geben. Ist das geschehen, steht dem Zugang zu den Apps in der Cloud nichts mehr im Wege. Spezielle Portfreigaben für das Streaming-Protokoll sind nicht notwendig.

Als Streaming Protokoll wird nicht PCoIP, sondern NICE DVC genutzt. Dabei wird H.264 über https gestreamt. Zudem wird die Qualität der Netzverbindung dabei überwacht und die Codierung entsprechend angepasst. Jeder, der schon mal netflix oder ähnliches genutzt hat, kennt dieses Verhalten.

Bandbreite und Roundtrip
Wie für die WorkSpaces nennt Amazon auch für AppStreaming eine maximale Entfernung von 3600km zwischen Client und Server. Ansonsten übersteigt das Delay ein erträgliches Maß. Eigene Test in dem Zusammenhang haben gezeigt, dass das durchaus ein Problem ist. Getestet wurde dabei mit einem Fotobearbeitungsprogramm, da man damit große Flächen gleichzeitig ändern kann und so nahezu der gesamte Bildschirm neu übertragen werden muss. Der Serverstandort war Irland, getestet wurde in Deutschland und Neuseeland. Zugegeben, viel extremer geht kaum noch. Das Ergebnis war eindeutig: während sich die Anwendung in Deutschland nahezu genauso verhielt, als hätte man sie auf dem eigenen Rechner installiert, war die Bedienung in Neuseeland kaum mehr möglich.

Die Anforderung an Entfernung und Bandbreite sollte also auf jeden Fall beachtet werden. Insbesondere wenn man WorkSpaces oder AppStream einsetzt, eine höhere Mobilität und Flexibilität zu erreichen.

Was die Bandbreite angeht, so lohnt ein Blick auf den Unterschied von PCoIP und NICE DVC. Darum haben wir dasselbe youtube Video wie bei den WorkSpaces auch noch mit dem Firefox über AppStream ablaufen lassen und mit Wireshark die Bandbreite ermittelt.

Abbildung 7 zeigt den ermittelten Bandbreitenbedarf. In der Spitze sieht man hier einen Durchsatz von ca. 950.000 Bytes/s also 7,6 Mbit/s. Verglichen mit Workspaces ist das dramatisch weniger, liegt aber immer noch über dem direkten Zugriff. Die subjektive Qualität aller Varianten ist durchaus gut, wenngleich sie bei WorkSpaces trotz des höheren Durchsatzes noch die Schlechteste war.

Abbildung 7: Bandbreitenbedarf von AppStream 2.0 bei youtube Video

Fazit

Ein Verzicht auf eine eigene Virtuelle Desktop Infrastruktur und das völlige Auslagern selbiger in die Cloud ist aus Sicht des Autors heute nur in sehr wenigen Fällen möglich. Der Bandbreiten-Hunger sowohl des Application Streamings, erst recht aber der WorkSpaces übersteigt jedes erträgliche Maß. Gerade das Video-Beispiel zeigt, dass nicht nur die oft zitierten High-Performance-Arbeitsplätze mit CAD- und Video-Anwendungen problematisch sind. Da nicht die Komplexität der Anwendung, sondern die Geschwindigkeit der Bildänderungen die notwendige Bandbreite bestimmen, ist bereits ein normales Surfverhalten ein Problem. Wie oft sind heute in „normalen“ Webseiten Videos eingebunden, die automatisch bei Aufruf einer Seite starten.

Sinnvoll ist der Einsatz also nur, um bestimmte Anwendungen in die Cloud zu verlagern, nicht aber den gesamten Desktop mit allen Anwendungen eines x-beliebigen Users. Ob man dabei auf virtuelle Desktops oder auf das Streaming einzelner Anwendungen setzt, ist von verschiedenen Faktoren abhängig. Grundsätzlich gilt: während die WorkSpaces mit einem ganzen Bundle an Sicherheitsfunktionen aufwarten können, glänzt AppStreaming durch seine Einfachheit. Die Frage, welches Verfahren man wählt, liegt also in den eigenen Anforderungen.

Die Cloud macht immer dann Sinn, wenn die Zugriffe von verteilten Standorten, mobilen Usern oder HomeOffices aus kommen. Die Einschränkung hier liegt in den 3600km. Mobile User, die gerne zu anderen Kontinenten reisen, können so also nicht bedient werden.

Last but not least gilt, dass beide kein Ersatz für native Webanwendungen sind. Wenn es selbige gibt, wie beispielsweise Office 365, so macht es keinen Sinn, diese zuvor auf einen virtuellen Desktop zu bringen. In dem Zusammenhang sei nochmals auf das youtube Beispiel hingewiesen, das schön zeigt, wie man aus 5,6 Mbit/s progressiv Download 28,8 Mbit/s Streaming bei den WorkSpaces macht.

VDI aus der Cloud

Kontakt

Services

Rechtliches

VDI aus der Cloud

Teile diesen Eintrag

Kontakt

Services

Rechtliches