Cloud Computing – eine Verbesserung oder eine Verschlimmerung des Vier-Säulen-Problems?

Seit langem hält sich hartnäckig die Behauptung, dass die Performance von Applikationen auf den vier Säulen Arbeitsspeicher, CPU, Netzwerk und Speicher ruht. Sobald man eine davon ändert, entsteht bei den anderen Säulen ein Engpass.

Beispiele hierfür sind:

· Speicherverbrauch – hier übt die Einführung neuer Betriebssysteme einen großen Effekt aus, da sie viel Speicher in Anspruch nehmen

· CPU-Auslastung – bei jedem Betriebssystem bricht die Performance jenseits einer bestimmten magischen Linie drastisch ein

· Netzwerkdurchsatz – alle Applikationen müssen über das Netzwerk kommunizieren, Verzögerungen wirken sich also direkt auf die Leistung aus

· Speicher – IOPS (Input/Output Operations Per Second) sind entscheidend, wenn Daten auf die Platten geschrieben oder davon gelesen werden (oder das OS Daten vom Speicher hin-/zurückbewegt)

Die vier Säulen waren in der Vergangenheit recht einfach zu überwachen, die Beziehung untereinander war nämlich simpel: Behob man ein Problem an einer Säule, wirkte sich eine der anderen Säulen negativ auf die Performance von Applikationen aus. Zudem war der Zugang zur Hardware einfacher. Sogar in hochvirtualisierten Umgebungen konnten die Säulen auf dem Host- und Gast-Level betrachtet werden – da sowohl einzelne VMs wie auch das ganze System eine Rolle spielte.

Mit dem Umzug in die Cloud ist es schwieriger geworden, die vier Säulen zu kontrollieren (natürlich immer in Abhängigkeit vom Cloud-Anbieter und der Definition der Cloud). Ist man einer saloppen Ausdrucksweise nicht abgeneigt, kann man das Problem sicher wie folgt zusammenfassen: Wenn man plötzlich mit Blindheit geschlagen wird, ändert sich nicht, was sich vor einem befindet, sondern nur die eigene Wahrnehmungsfähigkeit.

In der PaaS-Welt stehen einem immer nur die Tools zur Verfügung, die der Service Provider anbietet. Man will am besten auch gar nicht darüber nachdenken, welchen Einfluss die Hostcomputer auf die eigene App haben, obwohl dieser selbstverständlich vorhanden ist. In einer IaaS-Welt hat man zwar etwas mehr Einblick, aber, wie andere schon gezeigt haben, weniger Kontrolle als im eigenen Rechenzentrum.

In einer SaaS-Welt, falls man das als Cloud verstehen möchte, hat man überhaupt keine Kontrolle und sehr wenig Einblick. Wenn eine App nur ungenügende Leistungen erbringt, muss man mit den Angestellten des Anbieters reden, damit sie (hoffentlich) das Problem lösen. Aber ist das Problem einer schlechten App-Performance der Cloud wirklich schlimmer als im eigenen Rechenzentrum? Ich glaube nicht. Man ist weiter weg von den Bits, aber die Probleme sind dieselben. In einem reinen, öffentlich verfügbaren Cloud Deployment hängt die Performance einer App fast ausschließlich vom Anbieter ab. Top-Tier Anbieter (Amazon fällt einem ein) können zum Glück schnell mittels Kopien die Last von der Anwendung nehmen. Das ist dem Trick ähnlich, der in hochvirtualisierten Umgebungen zur Anwendung kommt: Man startet eine weitere VM auf einem anderen Server und fügt Sie zum Load Balancing hinzu. Wenn die App schlecht programmiert ist, kauft man keine Server, um Instanzen zu hosten, sondern man kauft die Instanzen direkt.

Das hat Folgen für die IT. Die geringeren Vorlaufskosten einer ineffizienten App – egal bei welcher der vier Säulen sie die Ressourcen verschwendet – bedeuten, dass die IT eher ineffiziente Apps toleriert. Auch wenn dann langfristig gesehen die monatlichen Kosten viel höher sind als beim Kauf eines neuen Servers, einfach weil die Einmalinvestition zu Beginn geringer ist.

Es gibt viele Firmen, die Informationen über Cloud Deployment anbieten. Diese Infos helfen, wenn man mal wieder den Wald vor lauter Bäumen nicht sieht. F5 ist übrigens eine dieser Firmen.

Wissen zieht jedoch nicht automatisch Handlungen nach sich. Manche Informationen kann einem zudem nur der Cloud-Anbieter zur Verfügung stellen. Weiß man, wo die Engpässe sind, bekommt die IT-Abteilung wieder etwas Entscheidungskompetenz zurück. Wenn eine Applikation eine schlechte Performance abliefert, hilft den Verantwortlichen ein Blick auf das Geschehen (das umfasst Netzwerk-Bandbreite, VM CPU-Auslastung, VM IOPS, etc., aber nicht die Vorgänge auf der physikalischen Hardware), die OpEx-Kosten von Cloud-Computing einzudämmen.

Bei einer internen Cloud-Infrastruktur ist der Vorgang viel einfacher. Man hat wie vor der Migration in die Cloud Zugang zu allen Informationen. Generell läuft die Fehlersuche und -behebung ähnlich ab wie in hochvirtualisierten Umgebungen, es ist fast dasselbe Vorgehen. Bei Virtualisierung und interner (privater) Cloud-Infrastruktur will man die Ressourcen bestmöglich nutzen, also muss man hier genauer nach Engpässen und Problemen suchen. Performance-Schwierigkeiten betreffen einen stärker, weil man die Architektur zu verantworten hat. Umfangreiche Aufzeichnungen und Monitoring helfen in virtualisierten und Cloud-Umgebungen oft dabei, alle entstehenden Probleme zu bewältigen, vor allem in großen Rechenzentren mit vielen gleichzeitig laufenden Apps.

Die Performance von intern entwickelten Apps lässt sich übrigens steigern, indem man die Entwickler dahingehend schult, sich nicht wie ein Ressourcen-Vielfraß aufzuführen. Bei extern entwickelten Apps sollte man am besten nach Größenangaben fragen und diese überprüfen.

Manchmal ist die Cloud aber die richtige Wahl. Wenn Netzwerk-Bandbreite der primäre limitierende Faktor ist und Ihre Organisation die vermeintlichen Sicherheits- und Compliance-Risiken akzeptieren kann, ist die Cloud eine gute Lösung. In der Cloud ist Bandbreite überhaupt nicht oder nur durch Ihre Bereitschaft limitiert, einen monatlichen Scheck für den Verbrauch auszustellen. Dennoch ist es kein Upgrade des Internet-Anschlusses – so etwas kann richtig teuer werden. Nicht nur bei der Installation, sondern auch Monat für Monat danach.

Letzten Endes hilft nur der Rat, sich genau auf das zu konzentrieren, was man wirklich braucht. Verschaffen Sie sich die notwendige Sichtbarkeit und verschwenden Sie keine Gedanken daran, was Sie nicht brauchen!

Published Mar 01, 2013
Version 1.0

Was this article helpful?

No CommentsBe the first to comment