Cloud Computing: Private managed Cloud – die ideale Lösung? – Gastbeitrag von Stefan Rühl
Im ersten Teil seines Gastbeitrages über Cloud Computing beschäftigte sich Stefan Rühl mit der Frage “Was ist Cloud Computing?“. Im zweiten Teil ging es um “Dedicated Hosting oder virtualisierte Lösung?” Der dritte Teil beschäftigt sich mit der Frage “Private managed Cloud – die ideale Lösung?”
“Private managed Cloud – die ideale Lösung? Wie in den vorherigen Artikeln beschrieben, hat jede Lösung Vor- und Nachteile. Das wesentliche Problem besteht jedoch darin, dass keine Kundengruppe, also weder die Start-ups, die high performer noch die technisch Versierten, in den geschilderten Ansätzen eine dauerhafte Lösung findet. Es ist zu beobachten, dass Gründer, welche Ihr Start-up selbst oder mit VC Hilfe finanzieren, am Anfang bei unmanaged hosting Anbietern oder in einer Amazon Umgebung starten, da die Kosten hier sehr niedrig sind. Kommt die Plattform dann unter Last, steht ein Umzug, meist zu einem manged hosting Anbieter an, da hier, neben hoher Qualität und Professionalität auch individuelle Beratung stattfindet. Dieser Umzug findet dann in einer Zeit statt, wo die Plattform neben Spitzenlasten auch weiter ausgebaut werden muss. Somit ist solch ein Umzug extrem unternehmenskritisch anzusehen.
Kommt es zu längeren Downtimes, kann dieses das Ende für das Portal bedeuten. Ergo wird in dieser Phase zu recht auf Erfahrung, Support und Kompetenz des Anbieters geachtet. Das böse Erwachen kommt dann, wenn sich die Plattform von der Last her stabilisiert hat, Peaks nicht mehr so extrem sind bzw. die Last durch weiterentwickelte Programmierung oder sinkende Userzahlen sinkt. Dann stehen Teile der Plattform / Server ungenutzt im Rack und verbrennen jeden Monat Kapital. Ein Blick in den Vertrag mit dem Hostingdienstleister zeigt dann meist noch eine Restvertragslaufzeit von über einem Jahr und mehr. Hier soll kein schwarzer Peter in Richting der Dienstleister geschoben werden. Diese müssen ja die Hardware anschaffen, die RZs ausbauen, deren Anbindung weiter erhöhen und Fachpersonal vorhalten.
Würden Sie einem Kunden vor Ablauf der Vertragszeit eine Reduzierung der Plattform ermöglichen, so würde die Kalkulation für das Projekt schnell in die roten Zahlen rutschen. Das Problem liegt im System des dedizierten Hostings.
Ein Ausweg bietet die private managed cloud. Der Kunde bekommt via Laufzeitvertrag eine dedizierte und gemanagte Serverplattform inkl. aller benötigten Systeme und Dienstleistungen. Hinzu kommt eine auf den Servern installierte Virtualisierungsschicht. Auf dieser werden die benötigten Instanzen (virtuelle Server) installiert und mit entsprechendem OS betrieben. Bis hierher ist also alles identisch – bis auf die Virtualisierung. Und genau hier kommt das Thema Peak ins Spiel. Die Plattform wird nicht für diese gebaut, sondern lediglich für den Normalbetrieb. Die temporär entstehenden Mehranforderungen (Peaks) werden auf eine andere Plattform ausgelagert. Entweder der Dienstleister bietet diesen Dienst selbst an, oder es werden z.B. bei Amazon kurzzeitig Ressourcen genutzt. Hier ist, wie bereits erwähnt, darauf zu achten, dass die VMs mit dem System des Auslagerungscarriers harmonisieren (VM ./. open nebula…). Natürlich müssen die Themen Latenzzeiten, Timing und Legal vorher geklärt sein.
Nur stellt sich die Frage, warum die Kernplattform und die Peakplattform getrennt sein müssen.
Aus dieser Betrachtung heraus ergibt sich die Notwendigkeit, einen anderen Ansatz zu fahren. Ein solcher kann nur in einer dynamischen Gesamtlösung liegen. Der Kunde muss die Möglichkeit haben, sowohl up- als auch down zu sizen und Services einzukaufen, wenn er diese benötigt. Auch muss eine einfache und betriebsunkritische Migration zwischen kostengünstigem hosting und dediziertem managed Services möglich sein. Auch muss eine Lösung für Peaks bedacht werden und das gesamte System muss mit individuellen SLAs ummantelt werden.
Die Lösung der DYNAMIC CLOUD besteht in 4 verschiedenen Systemen, welche in jeder Variante miteinander vermischbar sind. Grundlage dieses Systems ist eine einheitliche Serverhardware, auf der VMware oder open nebula als Virtualisierungsschicht arbeitet. Somit können die Instanzen ohne größere Aufwendungen in die einzelnen Segmente verschoben werden. Begleitet wird dieses System durch eine Storagelösung, welche die verschiedensten Anbindungsarten (iSCSI, FC) und verschiedene Plattentypen (FC, SATA, SSD) anbietet.
Server
Wichtig bei diesem Design ist eine homogene Hardware um die Serviceaufwendungen so weit wie möglich automatisieren zu können. Allerdings ist es notwendig, verschiedene Serverklassen zu implementieren. So kann ältere Hardware in der shared unmanaged & peak cloud eingesetzt werden. In der dedicated managed cloud hingegen werden mittlere und high end server (blades) eingesetzt und im dedicated hosting wird individuell nach Kundenvorgabe installiert (jedoch Hardware nur vom Hauslieferanten… HP, IBM…). Im Rechenzentrum gestaltet sich eine solche Lösung als permanentes Befüllen der Racks. Es gibt nicht mehr den Schrank x für Kunde y. Es werden maximal noch einzelne Areale für die einzelnen 3 Dienste aufgebaut – wobei auch das nicht notwendig ist. Es ist also auch notwendig, dass die Prozesse im RZ völlig neu überdacht werden… und nicht nur diese!
Storage
Dem Storage kommt gerade in einer Cloud Umgebung eine wesentliche Rolle hinzu. Grundsätzlich muss hier für die verschiedenen Anforderungsprofile unterschieden werden. So ist die Anforderung an einen Storage für Datenbanken eine gänzlich andere, als für Videos oder kleine Dateien.
Datenbanken
Es ist durchaus sinnvoll, die Datenbanken nicht auf einem lokalen Server abzulegen, sondern auf einem zentralen Storage. So ist z.B. beim Ausfall eines Servers die Datenbank physikalisch nicht betroffen. Der Dienst wird einfach vom DB Slave übernommen. Auch kann die Datenbank dynamisch im Storage wachsen. Eine besondere Beachtung muss beim Datenbankstorage jedoch der IO Performance geschenkt werden. Ist diese zu niedrig, kann die Datenbank nicht performen. Dieser Bottelneck ist häufig bei wachsenden Portalen zu beobachten.
Da sich die IO Leistung eines Storage mit der Anzahl der Festplatten, welche zu einem Aggregat zusammengeschaltet sind erhöht (ca. 175 IOps je FibreChannel HD), ergibt sich die Problematik, dass für eine benötigte IO Performance möglicherweise wesentlich mehr Festplatten genutzt werden müssen, als Diskspace benötigt wird.
Bei diesem Thema ist es wichtig, den Bedarf des Marktes in die Gestaltung eines Filers mit einzubeziehen. Viele transaktionsbezogene Web 2.0 Portale haben im Grundrauschen eine IO Anforderung im Schreibmodus von 5-6000 IOps. In den Peakzeiten (kurz nach Ausstrahlung eines TV Spots oder beim Verkauf limitierter, exklusiver Artikel mit eine festen Startzeit) kommen jedoch für einige Sekunden oder maximal wenige Minuten, Größenordnungen von über 20.000 IOps zum tragen. Und hier liegt das Problem für viele Kunden. Verwenden Sie ein Storagesystem, welches nur 6.000 IOps verarbeiten kann, so wird die Plattform i.d.R. gut laufen. Jede Werbeaktion wird jedoch zum Zusammenbruch des Portals führen und Kunden davon abhalten, hier wieder einzukaufen.
Dem Kunden bleiben 2 Möglichkeiten, dieses Problem zu lösen:
Dedizierter Storage
Hier muss der Kunde nach folgender Formel seinen Storage konfigurieren:
20.000 IOps / 175 IOps je Spindel = 115 x 300TB je Spindel = 34,5 TB
Da der Kunde i.d.R mit seinen Datenbanken nicht mehr als 1 TB Storage benötigt, ist dieses ein extrem teurer Weg. Er rechnet sich nur, wenn das Businessmodell des Kunden diese IO Performance zu 100% erfordert und eine Unterschreitung eine Gefahr für das Geschäftsmodell darstellt.
Natürlich kann über eine anderweitige Verwendung der nicht benötigten 33,5 TB nachgedacht werden. Z.B. eine Weitervermarktung an Kunden oder innerhalb eines Cloud Verbandes.
In der Regel wird der Kunde eher folgende Lösung in Betracht ziehen:
Shared Storage
Mehrere Carrier bieten heute unter dem Namen Shared Storage kostengünstigen Storage mit hoher IO Performance an. Der Kunde kann mit kleinen Mengen an Storage starten und diesen jederzeit erweitern. Der Unterschied zum Dedicated Storage besteht aber darin, dass mehrere Kunden auf diesem System arbeiten, welche IO Performance von weit über 25.000 IOps haben. Haben die Kunden zu verschiedenen Zeiten Ihre Peaks und wird der Filer nicht zu voll belegt, so hat jeder Kunde zu jeder Zeit eine ausgezeichnete Performance zu einem günstigen Preis. Es liegt in der Verantwortung und der Sorgfaltspflicht des Carrieres, den Filer so zu managen, dass er nicht im Peak überbucht wird. Dieses notwendige „verschenkte“ Portfolio muss natürlich mit eingepreist werden.
Wann entstehen Peaks?
Meist kommt die Last durch TV Spots oder zeitlimitierte Sonderaktionen oder TOP Produkte mit extrem kleiner Verfügbarkeit oder hoher Exklusivität. Die Wahrscheinlichkeit, dass z.B. TV Spots mehrerer Kunden zeitgleich laufen oder Aktionen zur gleichen Zeit starten, ist ebenfalls gering, da Marketingstrategen hier genau aufpassen, dass dieses nicht passiert.
Natürlich kann es passieren, dass ein Kunde mit vielen Datenbanken eine solche Last erzeugt, dass der gesamte Filer und somit alle anderen Kunden betroffen sind. Hier muss der Carrier darauf achten, dass Kunden ab einer bestimmten Größe diese Filer wieder verlassen und auf dedizierte Systeme wechseln. Jedoch wird dieser Kunde ohnehin ein dediziertes System anstreben, da ab einer Größe von 4-5 TB ein dediziertes System kostengünstiger wird als ein shared Storage.
Für den Carrier ist bei der Überlegung zum Einsatz eines shared Storage als erstes das Design zu überlegen. Hier muss entschieden werden, ob ein System maximales IO haben soll, oder mehrere Aggregate im unteren Segment angeboten werden sollen. Hierzu ein Beispiel:
Ein Filer besteht aus 10 Shelfs mit je 14x 300GB Festplatten. Wird dieses System zu einem Aggregat zusammengeschaltet, so verfügt dieses System über
10 Shelfs x 14 Platten x 300GB = 42 TB und 10 Shelfs x 14 Platten x 175 IOps je Platte = 24.500 IOps
Auf diesem System werden für jeden Kunden LUNs eingerichtet, die alle die maximale Leistung nutzen können (natürlich unter der Betrachtung, dass 2 Kunden mit exakt zeitgleichem Peak nur je die Hälfte der Leistung ziehen können).
Wird der Filer in z.B. 5 Aggregate zerteilt, die je einem Kunden zugewiesen werden, hat jedes Aggregat 8.4 TB (unkritisch) und nur 12.250 IOps. Dieser Wert ist für Datenbankpeaks i.d.R. nicht ausreichend und somit für DBs nicht verkaufbar.
Wie dieses Beispiel deutlich zeigt, ist die Konfiguration eines Filers wie auch die Auswahl entscheidend, ob ein attraktives Produkt entsteht, oder ein Datengrab.
In diesem Beispiel bin ich lediglich auf das Thema Datenbank eingegangen. Weiterhin ist zu überlegen, wie das Design für große Mengen von Kleinstdaten, für Fotos oder für Videos aussehen muss. Auch ist das Thema backup und Datenvorhaltung hier mit einzubeziehen.
Diese Überlegungen führen dann zu verschiedenen Designs und verschiedenen Herstellern. So findet man bei der Firma NetApp ein großes Portfolio vom kleinen Filer bis zum großen Cluster – von SATA Systemen bis zu FC Lösungen. Geht es um absolute High Performance, dann sind Systeme, wie z.B. HDS in Betracht zu ziehen.
Aus diesen Punkten ist zu ersehen, dass es nicht DEN einzig richtigen Storage gibt. Der Einsatzzweck bestimmt das Design und somit auch die Kosten eines Storagesystems. Folgende Fragen sollten vor der Auswahl gestellt werden:
Sollte der Storage für Datenbankanwendungen sein?
Wie viele IOps werden für schreiben / lesen benötigt
Wie ist die Anbindung an die Datenbankserver realisiert? FC, SATA, SAS… Performance?
Ist ein Backup notwendig? Wie häufig? Welche Speicherintervalle? Archivierungszeiten?
Wie ist das Restore Konzept?
Müssen alle Daten in einem schnellen Storage gelagert werden?
Können Teile der Daten in einen langsameren Storage ausgelagert werden?
Amazon S3 Storage
In der letzten Zeit hat der shared Storage von Amazon viel Interesse erweckt. Auf den ersten Blick erscheinen die 0,15 USD je GB je Monat sehr günstig. Hinzu kommt natürlich das backup und, dieser Punkt wird leider oft vergessen, Kosten für den in/out Traffic sowie die Requests.
Für kleine Lösungen, bei denen auch die Server in einer Amazon Cloud stehen, kann sich dieses Modell noch rechnen. Ab einem Datenvolumen von mehr als 3 TB netto ist dieses System sowohl aus Kostensicht, als auch aus Performancegründen zu hinterfragen. Wichtig sind hier auch Themen wie Service Level Agreements und Pönalen. Beides wird bei Amazon nicht zufriedenstellend beantwortet.
Nächste Woche: “Virtualisierungsschicht”
Tipp: Weitere Artikel zum Thema Cloud Computing gibt es in unserem Special
Zur Person
Stefan Ruehl ist seit fast 20 Jahren im IT-Sales für verschiedene Carrier tätig und hat in dieser Zeit einige der bedeutendsten Web 2.0-Portale in Deutschland beraten und begleitet. In den vergangenen Jahren hat er viele Gespräche mit CIOs, CTOs und CEOs zum Thema Cloud Computing und dessen Vorteile und Risiken geführt. In diesen Gesprächen zeigte sich immer deutlicher, dass die große Herausforderung im Cloud Computing weniger technische, rechtliche oder kaufmännische sind, sondern vielmehr die Vernetzung und Gestaltung von Unternehmensprozessen mit der „Produktion“ und die Annahme neuer Rollensituationen der Mitarbeiter – also eine Top Management-Aufgabe.