Ich hatte über Profitbricks, direkt nach deren Go-Live im Mai, geschrieben. Dabei ist das Unternehmen nicht unbedingt gut bei weggekommen. Denn ein „Infrastructure-as-a-Service (IaaS) der nächsten Generation“ konnte ich da noch nicht erkennen. Eine grafische Bedienoberfläche, freie Vernetzungsstrukturen durch echte Isolation des Kundennetzwerks im virtuellen Rechenzentrum, vermaschte redundante Vernetzung mit Infiniband, maßgeschneiderte Server und ein hochredundanter Storage, zeugen unter dem besagten Titel von mehr Marketingexpertise als großer Innovation. Ich habe mir das Angebot einmal genauer angeschaut und bin positiv überrascht. Insbesondere die Funktion „Live Vertical Scaling“ überzeugt. Allerdings steckt der Teufel im Detail.

Scale Up vs. Scale Out

Skalierbarkeit bedeutet, dass die Leistung eines Systems durch das Hinzufügen weiterer Ressourcen wie ganzer Rechnersysteme oder granularer Einheiten wie CPU und Arbeitsspeicher erhöht wird. Das System kann dann mit zunehmender beanspruchter Leistung linear mitwachsen. So lassen sich z.B. plötzliche Lastspitzen begegnen unter denen das System nicht zusammenbricht. Unterschieden wird dabei zwischen dem Scale Up und dem Scale Out.

Scale Up

Während eines Scale Up, auch vertikale Skalierung genannt, wird die Leistung des Systems gesteigert, indem weitere granulare Ressource zu einem Rechnersystem hinzugefügt werden. Dabei kann es sich um Speicherplatz, CPUs oder Arbeitsspeicher handeln. Man kann auch sagen, ein einzelner Rechner wird mit weiteren bzw. Leistungsstärkeren Komponenten aufgerüstet.

Scale Out

Ein Scale Out, horizontale Skalierung, steigert die Leistung eines Systems, indem weitere vollständige Rechner zu dem Gesamtsystem hinzugefügt werden. Man kann sich das Szenario auch so vorstellen, dass man sich einen Cluster von Rechnern aufbaut, über den skaliert wird, indem der Cluster immer um die benötigte Anzahl an Rechnern erweitert wird.

Live Vertical Scaling

Ich weise immer darauf hin, dass Anwendungen für die Eigenschaften einer Cloud entwickelt werden müssen. Also mit der Infrastruktur parallel mitwachsen müssen, wenn sich die Last verändert und weitere virtuelle Ressourcen automatisch hinzugefügt werden müssen.

Profitbricks hat nun das „Live Vertical Scaling“ vorgestellt und geht anders als bspw. die Amazon Web Services (AWS), Rackspace oder Windows Azure den Weg der vertikalen Skalierung. Die anderen drei genannten Anbieter setzen hingegen auf die horizontale Skalierung. Profitbricks beschreibt seine Lösung wie folgt:

Das Besondere dabei: Das System, beispielsweise ein Server, kann auf diese Art quasi unabhängig von der verwendeten Software und ohne deren Modifikation beschleunigt werden. Ideal ist dies beispielsweise für LAMP (Linux, Apache, MySQL, PHP)-Systeme, da MySQL ohne Anpassung die neuen Ressourcen erkennt und ohne Neustart vom Mehr profitiert.

Grundsätzlich hat Profitbricks recht. Nicht jede Software ist so implementiert, insbesondere die Legacy Anwendungen, dass sie skalierbar sind. Das hängt damit zusammen, dass diese Anwendungen nicht für den parallelen Betrieb auf mehreren Systemen entwickelt wurden. Für eine vertikale Skalierung ist, bis zu einem gewissen Grad, keine parallele Entwicklung notwendig, d.h. im Prinzip muss der Programmcode in diesem Fall nicht mehr angefasst werden, um die Leistung zu erhöhen.

Die Probleme stecken im Detail

Aber, der Teufel steckt im Detail.

Parallelität der Softwarearchitektur

Eine Anwendung muss mehrere Cores unterstützen, um die Leistungsfähigkeit des Rechners auszunutzen. Diese Problematik viel auf, als Intel seine Core 2 Duo Prozessoren auf den Markt brachte. Die Rechner verfügten zwar über zwei CPU-Kerne, die alten Anwendungen unterstützen aber nur einen. Der Vorteil eines zweiten CPU-Kerns war somit dahin. Das bedeutet, dass eine Anwendung auch auf die vertikale Skalierung vorbereitet werden muss. Was nützt es, wenn der Server bis zu 48 CPU-Kerne unterstützt, die Anwendung aber lediglich einen einzigen nutzen kann.

Die Software muss also, trotz vertikaler Skalierung, parallelisiert werden. Denn die Leistungssteigerung hängt effektiv mit dem Parallelisierungsgrad der Anwendung und dem Betriebssystem zusammen. Das Betriebssystem sorgt für das Verteilen der Prozesse und Anwendungen auf die jeweiligen Kerne. Die Anwendung muss für den Betrieb auf mehreren Prozessen zudem so parallelisiert werden, dass einzelne Threads dabei gleichzeitig auf mehreren Prozessoren laufen.

Profitbricks schreibt: „Bei anderen IaaS-Anbietern muss der Nutzer seine Server erst herunter fahren, dann die neuen Ressourcen buchen und die Systeme anschließend neustarten. Selbst im besten Fall kommt es hierbei zu einem Ausfall der Server von einigen Minuten, so dass derartige Modifikationen ohne Live Vertical Scaling nur in den Nachtstunden machbar sind.“

Das ist falsch. Bei AWS, Rackspace als auch Windows Azure lassen sich die Systeme per API/ Skripte steuern. Es können also weitere Ressourcen per Scale Out ohne Unterbrechungen hinzugefügt werden. Soll eine virtuelle Ressource ausgetauscht werden, lassen sich zunächst automatisch neue Ressourcen hinzufügen und anschließend die nicht mehr gewollten herunterfahren. Und das alles ohne Ausfallzeit.

Profitbricks nennt hier als Beispiel definitiv keine IaaS Cloud-Anbieter. Denn das geschilderte Szenario darf im Cloud Computing so überhaupt nicht auftreten!

Was ist mit Design for Failure?

Profibricks schreibt zwar, „Stehen auf dem physischen Server, auf dem eine bestimmte Kunden-VM läuft, nicht genügend Ressourcen bereit, um den per DCD gewünschten Wert zu erfüllen, verschiebt der von ProfitBricks verwendete Hypervisor die virtuelle Maschine automatisch auf einen anderen Server. Dies passiert, ohne die jeweils in der VM laufenden Anwendungen negativ zu beeinflussen.“

Aber wie verhält es sich, wenn der darunterliegende physikalische Host oder die virtuelle Maschine, auf der sich die Anwendung befindet ausfällt? Da sich die Anwendung lediglich auf einem einzigen System befindet und nicht über mehrere Systeme verteilt läuft, wäre ein Ausfall die Folge.

Interessante Lösung, aber…

„Live Vertical Scaling“ ist auf jedenfall eine interessante Lösung. Profitbricks versucht Infrastructure-as-a-Service (IaaS) für Anwender benutzerfreundlicher zu machen, womit sie auf dem richtigen Weg sind. Denn für die meisten IaaS-Angebote sind noch zu viele Expertenkenntnisse notwendig und manuelle Arbeit erforderlich. Einfache Automatisierung und Convenience sind die Schlagworte. Aber wie ich beschrieben habe, steckt der Teufel im Detail. Man sollte sich also zunächst über seine eigenen Bedürfnisse und die der Anwendung im Klaren sein, bevor man sich für die vertikale Skalierung entscheidet.

Bildquelle: http://krishnasblog.com