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!