Kompatibilitätsprobleme mit Windows-Server-Desktops aus der Cloud

Mit Desktops auf Basis von Windows Server lassen sich Lizenzprobleme vermeiden. Mitunter leiden dann aber Anwendungen unter Kompatibilitätsproblemen.

Eine Möglichkeit, Microsofts Lizenzeinschränkungen mit virtuellen Windows-Desktops zu umgehen, besteht in der Verwendung eigener Windows-Lizenzen in Verbindung mit einem DaaS-Provider (Desktop as a Service). Die Herausforderung für den DaaS-Anbieter besteht dann aber darin, dass er diese Lizenzen nur nutzen darf, wenn er dem Kunden dedizierte Server zuweist.

Dieser Ansatz ist attraktiv, wenn Unternehmen bereits über Lizenzverträge mit Microsoft verfügen, und natürlich besonders vorteilhaft für alle Firmen mit Rabatten für karitative Einrichtungen oder für Bildungszwecke. Auf derselben Hardware darf der DaaS-Anbieter dann aber keine virtuellen Maschinen (VMs) anderer Kunden betreiben.

Damit ist natürlich einer der großen Vorteile von Cloud-Computing ad absurdum geführt: Multimandanten-Ressourcenpools. Die zugewiesene Hardware für nur einen Kunden bildet einen vergleichsweise kleinen Pool, so dass der Anbieter mehr dafür wird verlangen wird als im Fall geteilter Hardware. Da dieser Pool durch eine begrenzte Anzahl von Hardware- und Rechenressourcen definiert wird, ist auch seine Elastizität eingeschränkt.

Bei einer Verdoppelung der aktiven Nutzer wird der Anbieter vermutlich zusätzliche Hardware bereitstellen müssen, was zu einer Verzögerung führen dürfte. Einer der Vorteile von DaaS ist aber gerade die jederzeitige Skalierbarkeit, die in einem solchen Fall nicht gegeben ist. Elastizität umfasst nicht nur eine Mehrleistung bei Mehrbedarf, sondern auch eine Reduzierung der Ressourcennutzung bei reduziertem Bedarf. Hat der Anbieter aber erst einmal Hardware speziell für die Desktop-Bereitstellung eines Unternehmens angeschafft, so wird er womöglich darauf drängen, dass die Bezahlung auch auf Basis dieser Hardware anstatt auf Basis des tatsächlichen Ressourcenbedarfs erfolgt.

Eine weitere Option ist die Unterbringung von Servern im Data Center des Providers, auch bekannt als Colocation. Der Anbieter stellt dabei die Server-Racks mit Stromversorgung und Internetanschluss zur Verfügung, der Kunde bringt darin dann seine eigene Hardware unter und kümmert sich um die Betriebsbereitschaft. Colocation entspricht natürlich nicht direkt DaaS, könnte Unternehmen aber bei der Nutzung eigener Windows-Lizenzen einige der von DaaS erhofften Vorteile bringen.

Auch diese Option bietet allerdings keine Multimandanten-Pools oder Elastizität, immerhin aber eine wesentlich höhere Autarkie, da Unternehmen die zentralen Komponenten selbst stellen. Als Eigentümer der Hardware sind sie vor sogenannten „Noisy Neighbours“ geschützt – andere Kunden des Anbieters können Ihre Rechenressourcen nicht belasten.

Windows-Desktop oder Windows-Server-Desktops?

Aus Gründen der Wirtschaftlichkeit versuchen DaaS-Anbieter natürlich, ihre Desktop-VMs in großen Multimandanten-Pools zu betreiben. Das erfordert die Nutzung von Server-Betriebssystemen, die über das Microsofts Service Provider License Agreement (SPLA) lizenziert werden. Glücklicherweise hat Microsoft vor einer Reihe von Jahren entschieden, die Codebasis der Server- und Desktop-Versionen von Windows zu vereinheitlichen. Aus diesem Grund kann ein Windows Server 2008 so konfiguriert werden, dass er nahezu identisch wie ein Windows-7-Desktop arbeitet. Dasselbe gilt für Windows Server 2012 und Windows 8. Viele DaaS-Anbieter bieten gesonderte Windows-Server-VMs für die Nutzer ihrer Dienste an. Clevere DaaS-Anbieter überarbeiten sogar die visuellen Elemente des Windows Servers, um ihn wie eine Desktop-Version von Windows erscheinen zu lassen.

Mit dem Wissen, dass Server- und Desktop-Versionen von Windows dieselbe Codebasis teilen, sollte man davon ausgehen können, dass Windows-Anwendungen auf beiden Systemen problemlos laufen. Das ist jedoch nicht uneingeschränkt der Fall. Die große Mehrheit aller Windows-Anwendungen läuft auf einem Windows-Server-System ebenso problemlos wie auf einem Windows-Desktop-System. Nahezu jede Anwendung, die in Anlehnung an Microsoft-Standards geschrieben wurde, einschließlich Microsoft Office, läuft auch auf Windows Server.

Allerdings wird nicht jede Anwendung in Anlehnung an Microsoft-Standards geschrieben. Das kann schon bei der Installation der Software Probleme bereiten, die dann unter Umständen verweigert wird, wenn die Installationsroutine ein Server-Betriebssystem entdeckt. Eine weitere Problemquelle sind vorausgesetzte Komponenten, die auf Windows-Desktop-Systemen üblicherweise installiert sind, bei Standardinstallationen von Windows Server hingegen fehlen. Ein Beispiel hierfür wäre die auf Servern üblicherweise fehlende Unterstützung von Scannern.

Solche Probleme sind normalerweise durchaus lösbar, Installationsroutinen kann man Desktop-Betriebssystemen vorgaukeln und Komponenten lassen sich nachinstallieren. Trotzdem wird die Sache damit komplizierter.

Besondere Herausforderungen liegen mitunter in sehr alten oder speziell für ein Unternehmen erstellten Anwendungen. Ein großer Teil dieser speziell angepassten Software läuft ohne Probleme auf Windows-Server-Betriebssystemen, spätestens wenn dieser sich als Windows-Desktop-System ausgibt. Es gibt jedoch auch Software, die unter Preisdruck in geringstmöglicher Zeit und ohne Planung zukünftiger Anforderungen erstellt wurde.

Die meisten DaaS-Desktops verwenden 64-Bit-Betriebssysteme, die große Mengen an Hauptspeicher unterstützen und aktuellen Anwendungen exzellente Leistungen ermöglichen. Allerdings sind 16-Bit-Programme auf 64-Bit-Systemen nicht ausführbar. Jede Anwendung, die innerhalb der letzten 15 Jahre erstellt wurde, wird in aller Regel 32-Bit-basiert sein und ist somit prinzipiell auf einem 64-Bit-System lauffähig. Setzten Unternehmen aber noch auf 16-Bit-Programme, so ist es nun an der Zeit, an deren Modernisierung oder Ersatz zu denken.

RDSH-Desktops für DaaS nutzen

Wer die Bereitstellung von Windows-Desktops schon länger verfolgt, der erinnert sich vermutlich noch an Application Service Provider, die die Desktop-Bereitstellung auf Basis von Windows Terminal Server einschließt. Das ist bis heute ein absolut praktikables DaaS-Modell. Statt jedem Nutzer ein Windows-Server-Betriebssystem bereitzustellen, können dank der RDSH-Rolle (Remote Desktop Session Host) die Desktop-Sessions mehrerer Benutzer auf einem einzigen Windows Server gehostet werden. Die gemeinsame Nutzung eines RDSH-Servers durch mehrere Angestellte erfordert auf Seiten des DaaS-Anbieters weniger Hardware, was zu geringeren Kosten führen sollte als die Verwendung dedizierter VMs.

Andererseits bietet ein RDSH weniger Isolation zwischen seinen Nutzern. Alle Nutzer eines RDSHs teilen sich dessen Systemlaufwerk und Anwendungen. Und auch unter den Nutzern eines RDSHs können „Noisy Neighbours“ sein. Ein einziges (wenngleich sehr komplexes) Excel-Arbeitsblatt kann einen kompletten RDSH-Server in die Knie zwingen. Auch die Anwendungskompatibilität gehört zu den Schwachstellen eines RDSH.

Die meisten Anwendungen laufen, wie gesagt bei Einhaltung der Microsoft-Standards, in dieser Umgebung recht problemlos. Es gibt aber auch Anwendungen, die nur solange auf einem Windows Server als Desktop-System laufen, bis ein anderer Nutzer dieselbe Anwendung in seiner eigenen Remote-Desktop-Session starten will. Dabei handelt es sich dann meist um sehr spezielle LOB-Anwendungen (Line of Business), die nur von wenigen Unternehmen genutzt werden.

In solchen Fällen kann man aber meist direkt mit dem Hersteller der Software Kontakt aufnehmen um herauszufinden, ob dieser andere Kunden kennt, die seine Software mit einem RDSH einsetzen. Es gibt sogar Anwendungen, die extra für RDSHs über einen gesonderten Installationsmodus oder sogar komplett eigene Installationssoftware verfügen. Anwendungen auf einem RDSH zu verwenden mag also etwas anspruchsvoller sein, lässt sich aber meist irgendwie realisieren.

Möglicherweise benötigen Sie mehrere DaaS-Ansätze, um Ihren Anforderungen vollständig gerecht zu werden. Einigen Nutzern ist am besten mit Windows-Server-Desktops in Multimandanten-Pools geholfen, während andere mit kostengünstigeren RDSH-Desktops auskommen können. Möglicherweise reicht aber auch eine eigene Virtual-Desktop-Infrastruktur in Colocation bei einem Cloudanbieter. Einige dieser Optionen wären sicher einfacher, wenn Microsoft seine Desktop-Betriebssysteme im Rahmen der SPLA-Lizenzierung anbieten würde. Das meiste jedoch wäre kein bisschen unterschiedlich – bestenfalls ein wenig günstiger.

Multimandantenfähigkeit in der Cloud

Der ökonomische Schlüssel der Clouddienste liegt in der Bereithaltung großer Ressourcen-Pools, die von einer bestimmten Anzahl Kunden gemeinsam genutzt werden. Um die Kosten möglichst niedrig zu halten, möchten Cloudanbieter diese Pools natürlich so groß wie irgend möglich gestalten. Normalerweise sind sie erheblich größer als der Bedarf eines Durchschnittskunden, so dass mehrere Kunden sich einen einzigen Pool teilen.

Die Isolation von Kundenressourcen innerhalb eines Pools ist eine der Kernfunktionalitäten eines jeden Clouddienstes. Sicherheitsorientierte Isolierung – das Verbergen der Kundeninformationen vor anderen Kunden – genießt für gewöhnlich die höchste Priorität. 

Eine weitere Art der Isolierung bezieht sich auf Leistung und „Noisy Neighbours“. Als „lauter Nachbar“ wird ein anderer Kunde bezeichnet, der gerade dann auf gemeinsam genutzte Ressourcen (inklusive CPU, Hauptspeicher, Laufwerke oder Netzwerk) zugreift, wenn die eigenen Desktops unter einem Ressourcenengpass und einhergehenden Leistungseinbußen leiden. Als Faustregel kann man für höhere Preise auch eine bessere Isolation erwarten.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im August 2015 aktualisiert

Erfahren Sie mehr über Cloud Computing

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close