Weitere Virtualisierungsthemen

Kommentieren Drucken
Teil 8 von 19 aus der Serie "Virtualisierungstechniken"

Bevor wir technisch tiefer in das zentrale Thema „VM-Kommunikation“ einsteigen, fassen wir in dieser Folge eine Reihe von Themen zusammen, die vor allem zeigen, wie sich die Grundidee der Virtualisierung auch auf andere Bereiche ausdehnen lässt, nämlich Desktop-Virtualisierung, Applikations-Virtualisierung, SOA und Cloud Computing. Sie sind alle sehr neu, werden von Interessenten als strategisch besonders wichtig herausgestellt, haben aber auch deutliche Risiken und Nebenwirkungen.

Desktop-Virtualisierung

Die Desktop-Virtualisierung greift ein Thema auf, was es eigentlich schon länger gibt, nämlich den Thin Client. Man geht dabei davon aus, dass die Programme, die heute auf einem Desktop laufen, in Zukunft besser auf einem entsprechend virtualisierten Server aufgehoben sind. Es gibt verschiedene Hersteller, die das aufgreifen. Bild 1 zeigt das Konzept.

Im Grunde genommen ist der bekannte Terminal-Server von Citrix ein Vorläufer in dieser Hinsicht, es kann durchaus Anwendungen geben, bei denen es Sinn macht, sie nicht der Gefährdung des Betriebs auf lokalen PCs auszusetzen. Diese Diskussion ist alt, wir kennen die Argumente und wir wissen auch, wie es meist ausgegangen ist. Früher hat man gerne ein Kostenargument genommen, den Herstellern ist es aber nie gelungen, Thin Clients zu bauen, die nach Hinzufügung der notwendigen Infrastruktur wirklich billiger waren. Außerdem gab es immer Probleme damit, dass man auf bestimmte Funktionen, die man eigentlich am PC immer hat, in einem solchen Zusammenhang verzichten muss.

Bei der aktuellen Diskussion tauchen genau diese Probleme wieder auf. Die 1:1-Abbildung von lokalen Desktops auf virtuelle Desktops macht nicht immer Sinn. Wir haben nach wie vor den Bedarf für eine lokale Betriebssystemlizenz und die Diskussion über profilgesteuerte Erzeugung der virtuellen Desktops geht wieder los.

Die bisher dominierenden Technologien (Citrix) waren Bandbreiten-optimiert. Dem lag eine Orientierung an langsamen WAN-Verbindungen zugrunde. So konnten sie bei entsprechendem Bedarfsprofil eingeschränkter Standard-Funktionalität, wie man das z. B. bei Banken und Versicherungen, aber auch im Handel oder bei Behörden findet, wo letztlich lediglich Formulare ausgefüllt werden müssen, zu einer erheblichen Kosten-Optimierung beitragen. Auf dieser Basis gibt es aber keine hohe Grafik-Leistung, das Ganze ist nicht CAD, Video oder UC-geeignet. Schließlich macht genau das alte Problem der Integration lokaler Geräte mit Techniken wie USB oder Firewire oder der Einsatz von Smartcards weiter Kopfschmerzen.

Die Konsequenzen sind eigentlich klar. Desktop-Virtualisierung ist gut geeignet für standardisierte Arbeitsplätze (Sachbearbeitung) mit einer hohen Zahl von Arbeitsplätzen, aber geringem Grad an gleichzeitiger Nutzung (letztlich „geerbte“ SNA-Umgebungen, Zugriff auf Applikationen, die nicht zur Standard-Installation gehören und Umgebungen mit hohem Sicherheits-Bedarf

Weniger gut geeignet ist das Konzept für CAD und Design-Arbeitsplätze und für Umgebungen mit intensiven Realzeitanwendungen wie Video, Flash oder UC, es sei denn man ist bereit, den Preis auf der Netzwerkseite zu bezahlen: 100 Mbit/s pro Desktop müssten es schon mindestens sein.

Applikations-Virtualisierung

Applikations-Virtualisierung ist ein sozusagen goldener Mittelweg: Clients und virtualisierte Server bleiben so wie sie sind, für bestimmte Anwendungen wird aber geeignet differenziert, wobei es verschiedene Varianten gibt:

  • Applikation läuft auf dem Server, nur das Frontend wird visualisiert.
  • Applikation wird zum Client gestreamt, läuft also auf dem Client. Gestreamt wird der nur Code, der auch gebraucht wird.
  • Applikation läuft komplett auf dem Client, aber in einer komplett gekapselten Laufzeitumgebung mit einer Registry und DLLs.

Die Vorteile liegen dabei auf der Hand:

  • Parallelbetrieb inkompatibler Versionen,
  • Betrieb ohne lokale Installation,
  • hoher Grad an Abschirmung: komplett gekapselt,
  • Daten bleiben zentral.

Wir können den hohen möglichen Nutzen dieser Konstruktion an einem einzigen Anwendungsbeispiel zeigen. Ein hochrangiger Mitarbeiter eines Unternehmens reist viel. Dabei nimmt er sein Notebook mit, um von irgendeinem Hotel aus auf sensible Unternehmensdaten zuzugreifen, weil er z. B. eine schnelle Entscheidung treffen muss. Dabei entstehen folgende Probleme:

  • Das Notebook ist ein besseres Modell und daher Diebstahl-gefährdet.
  • Die Verbindung zum Unternehmen ist hochgradig unsicher.

Da das Problemfeld schon länger existiert, gibt es natürlich Lösungen. So kann man z. B. das Notebook mit Sicherheitsmechanismen einschließlich der vollständigen Verschlüsselung vollstopfen. Ich habe aber selbst schon erlebt, wie ein betreffender Besitzer verzweifelt versucht hat, an seine Daten und eine Verbindung zu kommen, ihn das Notebook aber nicht ließ, weil er eines aus der Fülle der Passwörter vergessen hatte. Wird das Notebook aber entwendet, ist nicht wirklich sicherzustellen, dass ein Interessent mit genügend Zeit und Hilfsmitteln doch an sensible Daten kommt. Man kann eigentlich dann nur hoffen, dass es ein Dieb ist, der nur ein Notebook zum billigen Weiterverkauf sucht. Es ist keine gute Idee, die Sicherheit sensibler Unternehmensdaten einer Kombination aus Hoffnung und Zufall zu überlassen.

Applikations-Virtualisierung schafft hier neue Möglichkeiten für elegante Lösungen. Der Mitarbeiter muss eine Verbindung zu seinem Unternehmensnetz haben. Dann muss er sich mittels z. B. einer Smartcard-unterstützten Lösung identifizieren. Ist das alles erfolgreich, lädt der Unternehmensserver eine spezialisierte Verschlüsselungssoftware für die Kommunikation und eine virtualisierte Front-End-Software für die Benutzung der Anwendung, auf der die interessierenden Daten sind, auf das Notebook. Hat der Mitarbeiter dann an Daten gesehen, was er sehen wollte, werden die geladenen Anwendungen samt der Datenanzeige von seinem Notebook wieder spurlos verschwinden. Die Daten waren nie auf dem Notebook, sondern sind die ganze Zeit in der geschützten Umgebung des Unternehmens geblieben.

Eine Vorform davon kennen Sie alle: gute Lösungen für Electronic Banking.

Man hat natürlich auch auf der Server-Seite eine Menge zusätzlicher konstruktiver Möglichkeiten. So kann man durch die Virtualisierung dafür sorgen, dass jede Anwendung ihre eigene geschützte Laufzeitumgebung bekommt (erinnern Sie sich: das IST ja grade die technische Realisierung der Virtualisierung) und somit von anderen Anwendungen und dem zugrunde liegenden Betriebssystem isoliert ist.

Der Phantasie sind hier eigentlich keine Grenzen gesetzt und wir werden in Zukunft viele individuelle Lösungen in dieser Hinsicht sehen.

Service Oriented Architecture SOA

Clients, Server, Betriebssysteme, Virtualisierung, Netze, Applikationen, Verteilung von Applikationen sowie Sicherheits- und Verwaltungskomponenten und alles, was ich jetzt noch vergessen habe, stellen ein zwar extrem flexibles, aber auch weitläufiges und unübersichtliches Universum für die Realisierung von Geschäftsprozessen dar. Schon sein Beginn der Datenverarbeitung versucht man, hier entlang der Geschäftsprozesse eine Kombination von Lösungen zu finden, die am Ende genau das erzielen, was man möchte: die Unterstützung des Geschäftsprozesses.

Das Ziel von SOA ist die gezielte Abdeckung des Service-/IT-Bedarfs wichtiger Geschäftsprozesse unter Berücksichtigung von Aspekten wie

  • Wiederbenutzung, Granularität/Modularität, Redundanz-Freiheit
  • Leichte Änder-/Erweiterbarkeit
  • Vereinfachtes Schnittstellen-Design
  • Flexible und leicht wartbare Software-Architektur
  • Langzeit-stabile Domainen-Schnittstellen

Man möchte eine Standard-Basis schaffen. Das ist bei zurzeit bei circa 56 Arbeitsgruppen schwierig. Auch die kurze Lebensdauer von Webtechnologien und OpenSource kann dabei zum Problem werden.

Die Service-Orientierung wird zum fundamentalen Designprinzip Kernprozesse werden Top-down herunter gebrochen und auf Basis-Services abgebildet (Business und IT-Ressourcen werden somit verbunden). Die Summe der so ermittelten Basis-Services wird optimiert und eine nicht redundante Service-Struktur erstellt. Services werden in Domainen erbracht, wobei die interne Struktur einer Domain verborgen ist und nur der erbrachte Service bekannt ist. Die Services sind grundsätzlich Plattform- und Hersteller-neutral und man kann sie Standort-übergreifend anzubieten (distributed ownership domains). Schließlich sind Services nicht an eine bestimmte Technologie gebunden, die Service-Orientierung ist entscheidend, die Technologien können beliebig sein, z. B. RPC, DCOM, SOAP, WDSL.

Bild 2 zeigt die so entstehende Grundstruktur (nach dem Vortrag von Dr. Suppan auf dem ComConsult Netzwerk-Redesign Forum 2009).

Natürlich gibt es auch här wieder eine Reihe von Problemen. An erster Stelle steht dabei ein komplexes Design. Der Wunsch nach Schaffung redundanzfreier Services setzen voraus, dass alle relevanten Geschäftsprozesse gleichzeitig analysiert werden. Dadurch entsteht der Bedarf nach speziellen Design-Tools auch zur dauerhaften Pflege der Prozessbeschreibungen, zum Beispiel ARIS.

An zweiter Stelle stehen Illusionen, z. B. die, dass alles glatt und einfach werden würde. SOA verschiebt einen erheblichen Teil der Komplexität in die Domainen und die Art des Schnittstellen-Designs.

Das wiederum führt zu Problemen in der Performance. Jede Form von Ping-Pong führt dazu, dass die Kommunikationszeit im Verhältnis zur Rechenzeit dominiert, damit kann die komplette Anwendung unbrauchbar werden. Die typischen Performance-Probleme von Datenbanken ausgelöst durch Full Table Scans, allgemein Suchvorgänge bzw. Zugriff auf unklare Daten, gelten auch hier.

Dennoch muss man sagen, dass SOA und Virtualisierung zusammen gesehen eine Architektur bilden. Sie realisieren die natürlichen Bausteine für

  • dynamische Lastverteilung,
  • Skalierbarkeit,
  • Hochverfügbarkeit,
  • Plattformneutralität.

Es ist wichtig, die mögliche Tragweite dieser Entwicklung zu verstehen, um die Bedeutung der bestehenden Engpässe einschätzen zu können

I/O und Kommunikation sind der zentrale Engpass

Die “Vision” kann mit aktueller Technik nicht mit hoher Transaktions-Leistung funktionieren, die Antwortzeitverluste in der Kommunikation zwischen virtuellen Maschinen und SOA-Domains sind zu hoch, aber aufgrund der fulminanten Technologie-Entwicklung kann sich so etwas sehr schnell ändern.

Cloud-Computing

Cloud-Computing ist ein momentan arg strapazierter Begriff. Die Werbung möchte wieder glauben machen, dass Cloud Computing alle jetzigen und zukünftigen Probleme leicht löst und dabei äußerst geringe Kosten verursacht.

Dem Prinzip nach ist Cloud Computing nichts weiter als die systematische Möglichkeit der Nutzung von Diensten und Anwendungen, die über das Internet bereit gestellt werden.

Zentrale Elemente des ursprünglich von Sun Microsystems entwickelten Konzeptes sind AJAX (Asynchronous Javascript) und XML. Die Einbindung von Remote Scripts erfolgt per XMLHttpRequest (XHR). Das ermöglicht die Kommunikation mit einem Server im Hintergrund ohne den aktuellen Zustand der Webseite zu beeinflussen.

Script-Ergebnisse können synchron oder asynchron sein, Teile einer Webseite können verändert werden ohne dass die gesamte Webseite neu aufgebaut werden muss. Das ist nützlich für die Einblendung von Detailinformationen (z.B: Fernsehprogramm), den Wechsel von Bildern oder Grafiken, Chat und Ratings.

Das Konzept hat eine Reihe charmanter Vorteile. Webseiten können mit Funktionalität angereichert werden und erreichen einen höheren Nutzwert bzw. Nutzungserfolg, weil die Nutzung intuitiver wird, “form follows function” kann besser umgesetzt werden. Information und Interaktion können elegant verknüpft werden.

Einfache, aber wichtige Unternehmensanwendungen können zentral bereit gestellt werden

  • E-Mail, Kalender
  • Tasklisten, Projektmanagement
  • Kollaboration

Wobei alle Mitarbeiter auf identischen und zeitaktuellen Informationen arbeiten können.

Cloud Computing ist sicherlich eine schöne Möglichkeit zur Realisierung der Unterstützung virtueller Teams, wie das Bild 3 zeigt.

Bild 4 zeigt nochmal die Kernkonzepte, während Bild 5 einen typischen Teamspace darstellt.

Das Ganze ist aber nicht umsonst zu haben. Cloud Computing stellt eine Reihe von Anforderungen an den Client. Zunächst muss man mit einem erweiterten Medien-Einsatz rechnen, z. B. Unterstützung von HD-Technologie offline und online (720p) und effizienteres Abspielen verschiedener Medienströme (CSS Animation, Microsoft Silverlight).

Das bedeutet die Notwendigkeit einer verbesserten Unterstützung von Cloud-Computing im Browser. Der Browser dient als Laufzeit-Umgebung für Anwendungen und man braucht eine höhere Performance für JavaScript-Anwendungen (circa viermal mehr)

Dazu kommen einige notwendige Hardware-Änderungen. Bei der Rechenleistung brauchen wir uns eigentlich keine Sorgen zu machen: 4-Core wird Standard und für Power-Anwender kam Mitte 2009 eine neue Xeon-Generation. USB 3.0 hat eine erheblich gesteigerte Leistung: 5 Gigabit/s erlauben z. B. die Kopie von 27 GB HD-Video in 70 Sekunden (sofern die Festplatte das kann).

Der Ansatz des Internet-basierenden Cloud Computings ist vergleichsweise harmlos und überschaubar und man wird sehen, ob sich das irgendwie durchsetzt, momentan ist es aber ein beliebter Marketing-Begriff.

Spannender ist die Ausweitung der Funktionalität einerseits und das Umdenken von einer Umgebung, die man nicht selbst steuern kann (Internet) zu einer Umgebung, die man selbst hat und sehr wohl steuern kann: das eigene RZ. Das führt zum Begriff der „Lokalen Cloud“ und verspricht die Unterstützung eines weiten denkbaren Bereichs von Anwendungen unter Realisierung von Hochverfügbarkeit, Sicherheit und Skalierbarkeit.

Es gibt auch die wohlfundierte Meinung, dass Cloud Computing einfach nur ein überstrapazierter Werbebegriff ohne wirkliche Substanz und ohne nachweisbaren Nutzen ist. Z. B. versuchen bestimmte Anbieter, den Kunden die Verlagerung von Daten in eine von den Anbietern betriebene Cloud schmackhaft zu machen. Rechnet man aber alles genau durch, ergeben sich abgesehen von allgemeinen Problemen wie Vertrauen und Datenschutz auch handfeste wirtschaftliche Nachteile, die mit nichts zu rechtfertigen sind. So etwas passiert immer dann, wenn eine z. B. für einen Privatkunden interessante Lösung (wie z. B. das Auslagern größerer Foto- oder Video-Archive auf einen langsamen, preiswerten externen Speicher via Internet) auf einmal auf die Bedarfe eines Unternehmens hochgeblendet wird. Sagen Sie z. B. mal der Fa. SAP, sie wollten demnächst alle unternehmenskritischen ERP-Daten auf einen beliebigen externen Speicher auslagern. Sie können sich das Ausmaß der Begeisterung kaum vorstellen.

Mit einer tieferen Diskussion des Themas Cloud Computing würden wir das Thema dieser Serie verfehlen und verweisen deshalb auf die aktuelle Studie von Dr. Jürgen Suppan.

« Teil 7: Virtualisierung und SpeichertechnologieTeil 9: vSphere und Zwischenfazit »


zugeordnete Kategorien: Virtualisierung
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.