ICC: Unkalkulierbare Antwortzeiten
Aus der Serie: Wie kann man sich Cloud Computing mieß reden?
Oder positiver formuliert: Welche Risiken gibt es beim Cloud Computing zu bewerten?
Eines dieser Risiken sind unkalkulierbare Antwortzeiten. Ich stelle es hier mal am Beispiel IaaS dar. SaaS und PaaS sind ähnlich, dort sind die Verfahren und Schlussfolgerungen leicht abweichend.
In virtualisierten Umgebungen hat man generell das Problem, dass man einen Mittelweg finden muss zwischen verdammt flott antwortenden, aber total unterbeschäftigten Rechnern, und so weit überbelegten Rechnern, dass nichts mehr geht.
Es ist klar, dass ein Cloud-Betreiber eine möglichst hohe durchschnittliche Auslastung seiner Rechner wünscht, bei gleichzeitig möglichst wenigen Last-Peaks, welche man mit entsprechenden Leistungsreserven abfedern muss. Diese Aufgabe nennt man neudeutsch “Capacity Management”, vereinfacht ausgedrückt ist es das überwachen, dass genügend Last auf den Kisten ist, und trotzdem keine abraucht.
Doch wozu gibt es Methoden, mit denen man mal schnell eine VM von einer auf eine andere physische Maschine schieben kann? Dann sollte das Kapazitätsmanagement doch kein Problem sein.
Das Problem dabei sind aber die Merkmale dieser Methoden, die einem zum Verlagern von Last zwischen Maschinen zu Verfügung stehen. Da gibt es kräftig beworbene Verfahren, die eine Maschine im laufenden Betrieb umziehen. Davon gibt’s auch schicke Demovideos, und da merkt nie jemand was.
<Satiere>Ist ja auch klar. Oder würden Sie einen Leistungseinbruch bemerken, wenn ein Kamerateam Sie vor einem ausgeschalteten Monitor oder einem Standbild filmt und der Kerl mit den Textkarten auch keinen Leistungseinbruch vermerkt hat? Wie auch, als Schauspieler…<Satiere>
Alle diese hot-migration-Methoden arbeiten nach einem ähnlichen Grundverfahren: Die virtuellen Maschinen liegen auf shared storage, zwischen zwei Hosts werden zunächst der Inhalt der Arbeitsspeicher der VM ‘rüberkopiert. Dann werden inkrementell Updates des Arbeitsspeichers gemacht, bis es nur noch wenige Pages gibt, die sehr häufig geändert werden. Dann wird geschwenkt, die VM wird auf dem zweiten Host ab jetzt betrieben, die wenigen übrigen Pages werden umgezogen. Der User merkt davon bestenfalls ein Ruckeln der Maus.
Es ist klar – solch eine Migration ist technisch aufwändig: Viel IO auf beiden Maschinen, Mehrbelastung durch Kopiervorgänge. Nicht gerade das, was man machen sollte, wenn die Maschine eh schon am Anschlag läuft. Also kann man mit diesen Verfahren zwar Kapazitätsmanagement betreiben, aber nur lange bevor man in den Engpass läuft. Proaktives Management ist gefragt.
(Bei Monty Python würde jetzt ein Rudel nordfinnischer Unternehmensberater auf die Bühne hüpfen, was von APO brüllen und dann von einer urplötzlich auftauchenden Herde Bisons plattgemacht werden. Leider habe ich kein derartiges Video gefunden, welches ich hier hätte einbauen können.)
“Proaktivität” und “Leistungsbedarf” sind eine wünschenswerte Kombination, und in virtualisierten Umgebungen, bei denen man jede VM als Betreiber gut kennt, ist Proaktivität sogar bequem zu erreichen. Man weiss einfach, dass Container A (ERP-Dialoginstanz für die Leute im indischen Callcenter, im Gebrauch von 6:00 bis 16:00 Uhr) und Container B (Webshop-Instanz für Nordamerika, in Gebrauch v.A. von 14:00 bis 5:00 Uhr) gut zusammen passen, weil man Erfahrungswerte, Lastprofile und Applikationskenntnis hat.
Bei Cloud-Umgebungen ist das nicht so: Die VMs kommen und gehen ständig, manche sind kurz aufpoppende einmalige Riesenlasten, andere machen praktisch nie was, dritte widerum sind absolut nicht vorhersagbar, weil dort ein Programmierer seinen privaten Ideen fröhnt, immer wenn er irgendwo am Flughafen Zeit hat und auf seinen Flug warten muss. Man hat also unter Umständen weder verlässliche Vergangensheitdaten noch prognostizierbare Muster. Und zu allem Überfluss hat man extreme Elastizität versprochen.
Was soll man als Cloud Provider machen? Gleich den Strick holen?
Nee, die Lösung ist viel einfacher: Es darf den Kunden einfach nicht stören, wenn die Maschine halt man auf einmal ein wenig stockt, kurz durch die Gegend geschwenkt werden muss und deswegen mal – weil hot migration so aufwändig – nur warm migirert wird (also alle Operationen im Hypervisor anhalten, Speicher verschieben, weitermachen). Das resultiert in zwei Dingen:
- Man verspricht dem Kunden besser nicht zu viel Verfügbarkeit. 98% klingt nicht schlecht, und wenn man die Messmethode modifiziert, ist das auch mit wenig Aufwand zu erreichen.
- Man verspricht dem Kunden keine festen Antwortzeiten, am besten nicht mal Grenzwerte.
Daraus ergibt sich für den Endkunden ein Problem: Wenn man sich auf eine Antwort aus der Cloud verlässt, ist man verlassen.
Oder positiv formuliert: Betreiben Sie keine zeitkritischen Applikationen in der Cloud, wenn der Betreiber ihnen keine feste Antwortzeit zusichert. Bei IaaS stehen Ihre Chance dafür zur Zeit nicht gut, bei SaaS aber schon sehr viel besser!
Lex von der Leyen: Begründung des Abstimmungsverhaltens – heute ….
Update wegen Write once read everywhere: Eine wortgleiche Erklärung haben sehr viele SPDler abgegeben:
Bei Elke Ferner habe ich die Erklärung aber zuerst gefunden. Daher ist sie hier der Aufhänger.
Ende des Updates.
Das Bild von Elke Ferner gehört zu den Gesichtern, die einem in Saarbrücken regelmäßig den letzten Nerv rauben. Mit einem mildtätig-überlegenem Lächeln, einer zur Partei passenden Coloration und nichtssagenden Parolen wirbt die Dame um Stimmen, damit sie weiterhin in Berlin (aka. 1 Stunde Flug von Saarbrücken enfernt) saarländische Interessen vertritt.
Dazu gehört sie laut abgeordnetenwatch.de diversen Ausschüssen an, die mit ihrer beruflichen Kompetenz, dem Programmieren, nichts zu tun haben.
Von Elke Ferner gab’s eine Erklärung ihres Abstimmungsverhaltens gemäß §31 der Geschäftsordnung des Bundestags. Mit einer solchen Erklärung dürfen Abgeordnete begründen, warum sie wie gestimmt haben, falls sie es notwendig halten. Dabei gilt: Fasse Dich kurz!
Die Erklärung ist im Internet zu finden. Dort schreibt Frau Ferner:
Schließlich bleibt bei der Abwägung der Zustimmung zu diesem Gesetz auch der Umstand zu berücksichtigen, dass die entsprechende Sperrinfrastruktur aufgrund der abgeschlossenen Verträge zwischen BKA und Internetprovidern bereits aufgebaut wird. Diese Verträge beinhalten keinen hinreichenden Grundrechtsschutz und verfahrensrechtliche Sicherungen und sind deshalb höchst problematisch. Ich sehe es als meine Pflicht als Abgeordnete an, sol-
che weitgehenden, intransparenten und verfassungsrechtlich schlicht unzulässige Verträgen zu Lasten Dritter durch eine gesetzliche Grundlage abzuschwächen und ihre negative Wirkung zu reduzieren.
Ob folgende Interpretation des Absatzes unzulässig ist?
- Die Sperrinfrastruktur wurde laut Frau Ferner bereits während der Beratung des Gesetzes implementiert.
- Grundlage dafür waren verfassungsrechlich unzulässige Verträge zu Lasten Dritter.
- Sie sieht es als ihre Pflich an, den armen Vertragspartner die Arbeit zu legalisieren, anstatt die Dritten zu schützen, deren Verfassungsrechte verletzt werden.
Das ist nur meine Interpretation. Sollte diese Interpretation korrekt sein, würde ich gerne die Meinung eines Strafrechtlers hören.
links for 2009-06-23
-
Die Pressemitteilungen des Bundesverfassungsgerichts als Twitterfeed.
ICC: Lizenzmodell für Software
Nachdem es mittlerweile klar ist, dass viele Infrastructure as a Service als das Synonym für das “eigentliche” Cloud Computing ansehen (und dabei die interessanten Varianten SaaS und PaaS ignorieren), muss man sich mit einigen Besonderheiten dieses Modells vertraut machen.
Zunächst vereinfacht ausgedrückt: Man hat einen virtuellen Rechner mit bestimmten zugesicherten Eigentschaften. Man hat nicht die geringste Ahnung, was für einen CPU-Typ man unter der Virtualisierungsschicht findet, ja man weiss nicht mal, was für eine Virtualisierungsschicht da als Basis für die eigene Maschine dient. Je nach “Verbrauch” wird abgerechnet, fertig.
Gut, auf solch einer virtuellen Kiste setzt man seien Webshop auf und stellt sich dann die Frage:
“Wie viele Oracle-10g-Enterprise-Edition- oder Standard-Edition-Lizenzen braucht diese Maschine (1) und ist das ganze supportet(2)?”
Zu Frage 1: Keine Ahnung. Fragen Sie Ihren Oracle-Software-Vertriebsbeauftragten. Dessen normales Berechnungsmodell mit CPUs, Sockeln und Cores samt zugehörigen Core-Faktoren läuft ins Leere. Wenn er keine Lösung findet, können sie den virtuellen Rechner nicht mit einer Lizenz ausstatten.
Zu Frage 2: Aller Wahrscheinlichkeit ist das Ganze unsupported: Oracle lässt nur seine eigene OracleVM sowie Solaris Container als Virtualisierungstechnologie zu. Bei anderen Virtualisierungslösungen gibt’s keinen Support oder man behält sich das Recht vor, dass der Fehler auf nicht-virtualisierter Hardware reproduziert werden muss.
Vor solchen Problemen steht man nicht nur, wenn man die Datenbank von Oracle nutzen möchte. Auf Software wie Mathematik-Programme oder manche Betriebssysteme werden pro CPU oder pro Core lizenziert. Was soll man mit solcher Software in der Cloud machen? Vorsichtshalber für eine 8-Prozessoren-Quadcore-Maschine wie die M4600M2 eine Lizenz erwerben, und hoffen dass der Cloud-Anbieter nicht irgendwo eine 16-CPU-x86-Maschine auftreibt? Oder doch auf eigener Hardware rechnen?
Oder andere Software verwenden, die Cloud-tauglich ist? Aus rechtlicher Perspektive mag dies eine Option sein, doch aus applikatorischer nicht immer.
Zusammenfassend wird es letztlich drei Alternativen geben:
1. Die Softwarehersteller bewegen sich – eine durchaus wahrscheinliche Alternative: Mit speziellen Lizenzangeboten für Cloud Computing, eventuell mit Freigaben für bestimmte IaaS-Produkte, werden sich die Hersteller diesen Markt erschließen können. Vor allem bieten sich dann neue Lizenzmodelle, die sich an den verbrauchsabhängigen Modellen der IaaS-Anbieter orientieren. Eine Datenbank könnte pro Transaktion oder pro verwaltetem Gigabyte berechnet werden, Betriebssysteme nach produktiver Uptime.
2. Die IaaS-Anbieter bewegen sich: Mit zugesicherten maximal zu verfügungstehenden CPUs und Cores, unter zu Hilfenahme von supporteter Virtualisierungstechnologie. Man macht somit die Cloud ein wenig unelastischer, doch lässt man so auch “alte” Lizenzmodelle zu.
3. IaaS bleibt solchen Anwendungen verschlossen, man bezieht sie als SaaS: Warum selbst die Datenbank betreiben, wenn man sie als Service zukaufen kann? Sofern der Preis in Orndung ist und die Bandbreite ausreicht, wäre auch dieser Schritt denkbar.
Somit bleibt der Markt für Softwarelizenzen im Cloud Computing interessant. Neue Lizenzmodelle werden Software Cloud-tauglich machen und SaaS wird heute noch lokale Software auslagern. Kurzfristig könnte auch die zweite Alternative zum Tragen kommen, langfristig werden Kopplungen an Kerne oder CPUs verschwinden, auch weil Anwender irgendwann gar nicht mehr wahrnehmen können, auf welcher Sorte CPU sie gerade unterwegs sind.
links for 2009-06-16
-
Above the Clouds: A Berkeley View of Cloud Computing