Wein, Virtualisierung und xVM
Ich erinnere mich an ein Gespräch, das ich vor einigen Jahren mit ein paar Kunden geführt habe. Wir unterhielten uns über Wein und Virtualisierung. (Eine nahezu perfekte Kombination, wenn Sie mich fragen.) Das Thema Wein kam deshalb auf, weil wir uns auf einer von Sun organisierten Veranstaltung in Napa Valley aufhielten, mitten im kalifornischen Weinbaugebiet. Und wir sprachen über Virtualisierung, weil die Anwesenden Experten für Rechenzentren waren und über zukünftige Entwicklungen diskutierten.
Sie alle verfügten über teure High-End-Rechenzentren und setzten sich mit gutem Recht zur Wehr, als man Ihnen vorwarf, Ihre Server zu verhätscheln. Schließlich trugen sie die Verantwortung für einige der kostspieligsten Systeme der Welt, die sich durch eine bemerkenswert hohe Zuverlässigkeit auszeichneten.
Sie hatten alle Bedenken hinsichtlich des aufkommenden Trends, Anwendungen in virtualisierten Grids einer vernetzen Infrastruktur auszuführen (der Begriff Cloud Computing war damals noch nicht angesagt, sonst hätte ihn einer der Teilnehmer mit Sicherheit benutzt).
Mit anderen Worten, eine virtuelle Maschine übernimmt nicht nur die Aufgabe, mehrere Betriebssysteme auszuführen (mithilfe eines Hypervisors, siehe weiter unten), sondern die Betriebssysteme können sich auch je nach Arbeitslast oder Zeitplan dynamisch ändern. Die traditionelle Vorgehensweise, dass Computer A unter dem Betriebssystem B läuft und Anwendung C ausführt, wird nun durch einen dynamischeren Ansatz verdrängt, bei dem Computer für dringende Aufgaben zu Verfügung stehen, und zwar unabhängig vom Betriebssystem oder der zugrunde liegenden Architektur. Bei hohem Betriebsaufkommen in einem Online-Shop werden zum Beispiel einfach mehr virtuelle Maschinen zur Transaktionsverarbeitung bereitgestellt, während sie nach Abebben des Kaufrausches wieder anderen Aufgaben/Betriebssystemen zugeführt werden. Auch Kapazitäten sind nicht mehr starr, sondern dynamisch.
Meine Gesprächspartner beschäftigten sich nicht hauptsächlich mit dem Thema Desktop-Virtualisierung, obwohl es in ihren Systemumgebungen unterschiedliche Desktop-Betriebssysteme gab. Nicht gleich fünf verschiedene wie bei mir (was wohl eher die Ausnahme darstellt), aber doch mehrere Windows-Generationen. Der Grund dafür ist, dass sie nicht über den Quellcode älterer Anwendungen verfügten und daher an alten Betriebssystemen (und damit auch alter Hardware) festhalten mussten. Mithilfe von Desktop-Virtualisierung können Benutzer jedoch mehrere Betriebssysteme parallel auf einem einzigen Rechner ausführen, wodurch Softwareaktualisierungen nicht mehr zwangsläufig an Hardware-Upgrades gebunden sind. (Sehr zur Freude von CIOs und Entwicklern.)
Doch zurück zum Rechenzentrum. Durch Virtualisierung lässt sich die Infrastruktur stark konsolidieren. Da Anwendungen nicht mehr an Hardware gebunden sind, können Administratoren Kapazitäten und neue Systemelemente sinnvoller planen und erwerben. Doch so spannend das für alle Beteiligten auch klingen mag, was macht man, wenn dabei etwas schief geht? Das Handtuch werfen? Die Einsparungen auf den Kopf hauen und seine Karriere an den Nagel hängen? Warum diese ganze Aufregung?
Lassen Sie mich kurz zusammenfassen: Unsere Kunden befürchteten, durch Virtualisierung die Kontrolle über ihre Rechner zu verlieren. Eine mühsam erarbeitete Kontrolle, die die Zuverlässigkeit ihrer Systeme gewährleistet. Es ist prinzipiell möglich, einen virtualisierten Mainframe oder E25K zu verhätscheln (und damit meine ich, einem einzelnen Rechner besondere Aufmerksamkeit zu schenken), doch im Falle einer Cloud gestaltet sich das nicht mehr ganz so einfach. Zudem lässt sich bei einer Cloud nicht so leicht herausfinden, warum sie langsam, fehleranfällig oder unzuverlässig ist. Fragen, die sich im Falle eines einzigen, großen Rechners weitaus einfacher beantworten ließen.
Als der Wein seine Wirkung zeigte, lehnten sich einige zurück and fingen an, von ihrer Vorstellung einer idealen Cloud-Umgebung zu sprechen (und wir machten uns eifrig Notizen). Zusammengefasst lauten ihre Wünsche wie folgt:
An zweiter Stelle stand der Wunsch nach extremer Skalierbarkeit. Alle waren der Ansicht, dass der Trend in Richtung horizontal skalierter Grids (viele kleine Systeme, ein so genanntes Scale-Out) durch das Konzept weniger großer Systeme (Scale-Up) verdrängt werden würde wie es meistens der Fall ist. Das wird bereits heute schon im Zuge der Mehrkern-Prozessoren deutlich, mit denen sich 16-, 32-, 64- oder sogar 128-Bit-Systeme auf einem einzigen Geräte erstellen lassen, die über Hochleistungs-Netzwerktechnologie miteinander verbunden werden.
Skalierbarkeit sorgt jedoch für einen hohen Verwaltungsaufwand. Es mag einen Riesenspaß machen, 16.000 virtualisierte Rechner zu besitzen (fast wie 16.000 Welpen), aber nur, solange man sich nicht um sie kümmern muss. Das größte Problem (und der größte Kostenfaktor) in einem umfangreichen Rechenzentrum ist nicht die eingesetzte Technologie, sondern die vielen Einzellösungen und das Personal, das für die Verwaltung des Ganzen nötig ist. Die Möglichkeit einer unkomplizierten Verwaltung musste daher von uns an oberste Stelle gesetzt werden, wobei wir gleichzeitig die extreme Skalierbarkeit (innerhalb von Netzwerken) nicht außer Acht lassen durften.
Gewünscht wurde zudem ein vielseitiger Ansatz, der unabhängig von Hardware und Betriebssystem ist. Also eine Lösung, die sich mit beliebiger Hardware einsetzen lässt, nicht nur mit Servern und Speichersystemen von Sun, sondern auch mit Geräten von Dell, IBM und HP. Und sie bestanden auf eine Lösung, die nicht nur mit Solaris, sondern auch mit Microsoft Windows und Linux kompatibel ist. Die im Idealfall nicht nur von Sun, sondern auch von Microsoft, Intel und AMD empfohlen und unterstützt wird.
Und zu guter Letzt wünschten sie sich Open Source. Nachdem sie in den vergangenen Jahren immer mehr Richtung Open Source Software tendierten und deren Zuverlässigkeit zu schätzen gelernt hatten, war niemand mehr dazu bereit, proprietäre Software in die grundlegendsten Schichten seines künftigen Rechenzentrums einzuführen. Einige wollten aus Sicherheitsgründen Einblick in den Code haben, andere wollten in der Lage sein, ihn für besondere Arbeitslasten oder Anforderungen individuell anzupassen.
Aufgrund dieses Feedbacks lag für einen Teilnehmer die Antwort auf der Hand: Warum nehmt ihr nicht einfach Solaris? Alle setzten Solaris in geschäftskritischen Umgebungen ein, alle schätzen seine Leistung, seine Möglichkeiten zur Fehlerdiagnose (mithilfe von DTrace)und die Fähigkeit der Skalierung für die weltweit größten Systeme. Die Antwort war nahezu perfekt, bis einer der Gesprächsteilnehmer einwandte: Aber was ist mit Windows-Kunden? Ich glaube nicht, dass sie Solaris einsetzen möchten. Die Marke Solaris war nicht mit dem Konzept der Betriebssystemunabhängigkeit vereinbar, und Neutralität stand nach wie vor im Mittelpunkt unserer Überlegungen. Aber wir wussten, dass unser umfangreiches Arsenal an OpenSolaris-Innovationen uns den Anfang erleichtern würde.
Das ist in groben Zügen der Hintergrund für unsere letzte Woche erfolgten Virtualisierungsankündigungen. Wir haben es uns zum Ziel gesetzt, die Probleme von Entwicklern und Rechenzentrumsbetreibern in heterogenen Umgebungen zu lösen. Wenn Sie unsere xVM-Angebote einmal näher betrachten, werden Sie feststellen, dass wir auf die obigen Anforderungen eingegangen sind. Die Integration von DTrace sorgt für umfangreiche Möglichkeiten zur Fehlerdiagnose. Dank der Skalierbarkeit unseres Kernels lassen sich selbst die größten Systeme der Welt virtualisieren. Unsere Kunden profitieren zudem von einer einfachen und übersichtlichen Benutzeroberfläche namens xVM OpsCenter zur Verwaltung von Clouds (weitere Informationen finden Sie hier), mit dem sich das Management und die Bereitstellung von Ressourcen sowohl in kleinen als auch großen Rechenzentren bewältigen lässt. Alles steht über Open Source (und kostenlose Downloads) zur Verfügung und wird von unseren Branchenpartnern unterstützt. In den Videos zur Markteinführung sehen Sie, dass xVM von Microsoft und Intel unterstützt wird (ja, Sie haben richtig gelesen, Microsoft unterstützt xVM). Des Weiteren haben wir ZFS integriert, um uns einen entscheidenden Vorsprung im Hinblick auf unser nächstes großes Ziel, der Virtualisierung von Speicher, zu verschaffen.Und warum der Name xVM? Wir wollten verdeutlichen, dass diese Technologie nicht nur auf Solaris (8, 9 und 10) ausgelegt ist, sondern auch der Virtualisierung von Microsoft Windows und Linux (Ubuntu, Red Hat und allen anderen Distributionen) dient. Kunden werden in die Lage versetzt, ihre Betriebssysteme und ihre Hardware-Infrastruktur zu konsolidieren und das Ganze mit xVM Ops Center zu verwalten und zu warten.
An dieser Stelle möchte ich mich bei meinen Gesprächspartnern bedanken, die an besagter Veranstaltung vor einigen Jahren teilgenommen hatten. Ganz herzlich möchte ich auch den Teams von Sun und unserer Partner-Community gratulieren, die an der Entwicklung von xVM gearbeitet haben.
Bei all den Feierlichkeiten rund um xVM sollten wir unsere nächste Veranstaltung vielleicht in der Champagne abhalten
Posted on 12:00AM Sep 14, 2008 |



















Für Global Sales and Services ist in Zukunft Peter Ryan verantwortlich. In seinen Zuständigkeitsbereich fällt die neue Vertriebsregion Emerging Markets mit Denis Heraud an der Spitze. Die Emerging-Markets-Region mit ihren schnell wachsenden Ländern (darunter auch BRICA) erhält den gleichen Stellenwert wie Nordamerika, Europa und Asien. Allein im letzten Quartal sind unsere Umsätze in den BRICA-Ländern zweistellig gewachsen. Wir möchten auf diesen Trend aufbauen, und deshalb haben wir das Unternehmen neu ausgerichtet, Ressourcen umgeschichtet und Führungspositionen neu besetzt. 









Wie Sie in der 
















