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
16 Antworten auf „Profitbricks: "Live Vertical Scaling" und die Krux mit der Parallelität“
Profitbricks: „Live Vertical Scaling“ und die Krux mit der Parallelität – http://t.co/ZfIOdYBX
#Profitbricks: „Live Vertical Scaling“ und die Krux mit der #Parallelität – http://t.co/V56TaGh1 #CloudComputing #Cloud #IaaS
Profitbricks: “Live Vertical Scaling” und die Krux mit der Parallelität http://t.co/rEFFz4zI
clouduser.de : Profitbricks: “Live Vertical Scaling” und die Krux mit der Parallelität: Ich hatte über Pr… http://t.co/KHaim8JS #Cloud
Profitbricks: “Live Vertical Scaling” und die Krux mit der Parallelität: Ich hatte über Profitbricks, direkt nac… http://t.co/ylK54RCo
Profitbricks: “Live Vertical Scaling ” und die Krux mit der Parallelität http://t.co/fXlsH2xL
RT @Wyse_DACH: Profitbricks: “Live Vertical Scaling ” und die Krux mit der Parallelität http://t.co/fXlsH2xL
RT @Wyse_DACH: Profitbricks: “Live Vertical Scaling ” und die Krux mit der Parallelität http://t.co/fXlsH2xL
RT @Wyse_DACH: Profitbricks: “Live Vertical Scaling ” und die Krux mit der Parallelität http://t.co/fXlsH2xL
Ich habe den Verdacht das der Autor nicht wirklich verstanden hat worum es geht, oder Profitbricks schlechter machen will, als es ist.
1. clouduser.de schreibt „Eine Anwendung muss mehrere Cores unterstützen“: Kann mir mal einer ein Beispiel nennen für eine single threaded Serverumgebung? Ob das jetzt (My)SQL, PHP, Apache, Tomcat oder node.js ist, die alle laufen schon immer auf mehreren Cores. Das Argument ist für mich in 90% der Fälle an den Haaren herbeigezogen.
2. Profitbricks schreibt: “Bei anderen IaaS-Anbietern muss der Nutzer seine Server erst herunter fahren“ clouduser.de schreibt: „Das ist falsch.“: Wenn ich einen SQL Server am laufen habe und ich brauche mehr Leistung, muß ich entweder runterfahren, größere Instanz buchen, wieder hochfahren, oder ich muß Replikation einsetzen und meine Software so haben dass ich im laufenden Betrieb Master und Slave wechseln kann. Mach das mal ganz ohne Downtime. Das ist nicht trivial. Es geht, aber es ist nicht trivial. Das Argument von Profitbricks ist also öfters gültig, als das trockene „Das ist falsch.“ suggeriert.
3. clouduser.de schreibt „Profitbricks nennt hier als Beispiel definitiv keine IaaS Cloud-Anbieter. Denn das geschilderte Szenario darf im Cloud Computing so überhaupt nicht auftreten!“: Das hier ist ein Satz, an dem ich glaube feststellen zu können das der Autor keine Ahnung hat wovon er redet. Bei Amazon AWS ist es ganz genau so, dass ich (komplexe) Software brauche, die sich darum kümmert das meine Anwendung weiterläuft, obwohl ich gerade einen Server herunterfahre und einen anderen hochfahre.
4. clouduser.de schreibt „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.“: Hallo? Das ist überall so außer vielleicht bei einer IBM AS/400. Wenn bei Amazon AWS die physikalische Maschine abraucht, erleben die virtuellen Instanzen genau so einen hard reset wie bei Profitbricks.
Insgesamt ist der Artikel stark tendenziös geschrieben und gefällt mir überhaupt nicht, weil er meinen Erfahrungen stark widerspricht.
Lieber Ansgar,
Profitbricks schreibt: “Bei anderen IaaS-Anbietern muss der Nutzer seine Server erst herunter fahren” clouduser.de schreibt: “Das ist falsch.”: Wenn ich einen SQL Server am laufen habe und ich brauche mehr Leistung, muß ich entweder runterfahren, größere Instanz buchen, wieder hochfahren, oder ich muß Replikation einsetzen und meine Software so haben dass ich im laufenden Betrieb Master und Slave wechseln kann. Mach das mal ganz ohne Downtime. Das ist nicht trivial. Es geht, aber es ist nicht trivial. Das Argument von Profitbricks ist also öfters gültig, als das trockene “Das ist falsch.” suggeriert.
– – – – – – –
Richtig, das ist nicht trivial und wenn Du die vielen weiteren Artikel auf CloudUser ließt, wirst Du sehen, dass ich immer wieder darüber schreibe und darauf hinweise, wie komplex es ist, ein IaaS-Angebot zu nutzen.
– – – – – – –
clouduser.de schreibt “Profitbricks nennt hier als Beispiel definitiv keine IaaS Cloud-Anbieter. Denn das geschilderte Szenario darf im Cloud Computing so überhaupt nicht auftreten!”: Das hier ist ein Satz, an dem ich glaube feststellen zu können das der Autor keine Ahnung hat wovon er redet. Bei Amazon AWS ist es ganz genau so, dass ich (komplexe) Software brauche, die sich darum kümmert das meine Anwendung weiterläuft, obwohl ich gerade einen Server herunterfahre und einen anderen hochfahre.
– – – – – – –
Siehe meine obere Antwort. Du hast nämlich vollkommen recht damit, dass man für die Cloud entwickeln muss und die eigene Software dafür zu sorgen hat, dass die virtuellen Maschinen auf AWS hoch- und herunterfahren. Noch einmal, ließ bitte weitere Artikel hier auf CloudUser, bevor Du mein Wissen in Frage stellst.
– – – – – – –
clouduser.de schreibt “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.”: Hallo? Das ist überall so außer vielleicht bei einer IBM AS/400. Wenn bei Amazon AWS die physikalische Maschine abraucht, erleben die virtuellen Instanzen genau so einen hard reset wie bei Profitbricks.
– – – – – – –
Und genau deswegen solltest Du z.B. bei AWS ja auch mehrere Regionen und Availability Zones nutzen und die Software so entwickeln, dass die das managen (siehe z.B. Netflix Chaos Monkey) kann.
… oder man skaliert einfach im live Betrieb die (oder den) Server hoch und entwickelt das Produkt mit dem man Geld verdient, statt „für die Cloud“.
Wenn ich mir anschaue was Netflix für einen Mörderaufwand betreibt um den Unzulänglichkeiten von AWS aus dem Weg zu gehen (erst Chaosmonkey, jetzt Chaosgorilla und das ist ja nur ein kleiner Teil ihrer Strategie), dann weiß ich das ich das nicht machen will. Für Netflix wird sich das sicher lohnen, sonst würden sie es nicht machen. Aber ich kann mir nur wenige Firmen vorstellen, die sich die Manpower leisten können nicht nur ihre Software zu entwickeln, die mehr Serverleistung braucht als man bei jedem beliebigen Hoster mieten kann, sondern sich auch noch wochenlang in AWS einzuarbeiten.
Ich betreibe seit Jahren (mittlerweile) 17 dedicated Server, erst bei Hetzner, dann Hosteurope, momentan Manitu. Das lässt sich manuell gerade noch so handhaben, aber es ist ein Aufwand. Wenn ich mir die Preise bei AWS anschaue, stellen sich mir die Haare zu Berge. Außerdem habe ich noch einen Haufen APIs zu lernen, muß mich um Auto-Failover kümmern, Multi-Zone, Multi-Region, was alles den Preis, Aufwand und Komplexität meiner Anwendungen erheblich steigert.
Oder ich gehe einfach zu Profitbricks, teile meine Server nach logischen Einheiten ein und habe maßgeschneidert genau die Leistung, die ich an jedem Server brauche. Wenn mir der DB Server von Anwendung 1 zu lahm wird, packe ich im Live Betrieb mehr RAM und/oder CPU rein, fertig.
An meiner Software ändert sich überhaupt nichts. Ich habe kein Failover, keine Replikation, nur mein Produkt.
Das ist natürlich eine ganz andere Dienstleistung als AWS. Aber jeder der Heute dedicated Server betreibt, wäre verrückt alles in die „Cloud“ zu verschieben, wenn er eigentlich einfach nur mehr Leistung braucht.
Das hätte der Artikel ruhig anerkennen können. Stattdessen hat er Kleinigkeiten aufgebauscht und falsche Vergleiche gezogen.
@Ansgar Hofmann: So klar wie Sie hat die Leistungsunterschiede bisher niemand auf den Punkt gebracht. Herzlichen Dank dafür!
@René Büst: Kritische Debatten sehen wir als konstruktive Kraft, die alle Beteiligten voran bringt. Deshalb ein Vorschlag an Sie und andere Interessierte: Sie testen ProfitBricks‘ vertikale und horizontale Skalierung bei Gelegenheit kostenlos für 14 Tage aus und dann reden wir.
Kommt halt drauf an, was man haben will.
Ich habe früher selbst ca. 20 Domains auf Consumer-Hardware (als HA-Cluster) gehostet, die sind derzeit bei Hetzner.
Beruflich administriere ich ca. 400 Domains, die auf einem HA-Cluster (HA/Pacemaker/DRBD/XEN) auf ca. ein Dutzend virtuelle Maschinen verteilt sind. Das ist vermutlich mit den Bedürfnissen von Ansgar Hofmann vergleichbar.
Alles, was ich in Wirklichkeit brauche, sind laufende Linux (Debian) Server, die mich mit Hardware-Ausfällen verschonen. Wenn es irgendwo einen Engpass gibt, dann reicht es in meiner Zielgruppe, vertikal zu skalieren – also CPU, Speicher oder Disk-Storage dazufügen. In meiner derzeitigen Lösung muss ich dafür die jeweilige VM rebooten (20 Sekunden bis 2 Minuten Ausfall, bis die Services wieder auf Geschwindigkeit sind).
Nachdem das vorwiegend typische Netz-Anwendungen unter Linux sind (MySql, Apache, PHP, Perl, Postfix), sehe ich in der vertikalen Skalierung keinen Nachteil, sondern eher einen Vorteil.
Horizontale Skalierung kann man bei Profitbricks ebenfalls betreiben, wenn auch möglicherweise nicht komfortabel, dynamisch, ausfallsicher genug.
Diese horizontale Ausfallsicherheit (z.B. Anwendung hat eine Endlosschleife, müllt den Speicher oder Platte zu) braucht man unter einem normal konfigurierten Linux-System allerdings kaum. Jedenfalls kann ich mich an kein Einfrieren oder dergleichen in den letzten Jahren erinnern. Bei Windows kommt das allerdings häufig und bei OSX regelmässig vor.
Hallo Herr Hofmann,
melden Sie sich mal bitte bei mir.
Beste Grüße,
Ilker Yildiz
[…] und konkrete Fragen zu stellen. Ich habe ProfitBricks in zwei Artikeln Nummer eins hier und Nummer zwei hier in der Vergangenheit bereits kritisch begutachtet. Zum einen, weil ich einfach nicht auf […]