EC2: Insufficient capacity.

Gestern erst habe ich über die Illusion unendlich verfügbarer Rechenkapazitäten geschrieben und bereits heute stelle ich fest, dass es sich tatsächlich nur um eine Illusion handelt. Für einen Kunden wollte ich neue EC2-Instanzen starten, erhielt aber bereits beim starten der dritten Instanz die Fehlermeldung:

Server.InsufficientInstanceCapacity: Insufficient capacity.

(Starten wollte ich m1.large-Instanzen in der Verfügbarkeitszone eu-west-1b. Andere Instanztypen habe ich nicht getestet und da bereits bestehende EBS-Devices an die Instanzen gebunden werden mussten, konnte ich auch nicht einfach die Verfügbarkeitszone wechseln; zumindest nicht ohne den Umweg über Snapshots zu nehmen).

Eine Stunde später waren dann wieder ausreichend Kapazitäten zum Starten neuer Instanzen vorhanden. Schön ist das nicht. Vielleicht sollten wir in Zukunft bei Lasttests überprüfen, wie sich das Verteilen der Applikation über mehrere Verfügbarkeitszonen hinweg auf die Performance auswirkt.

Und noch etwas war merkwürdig: Die ersten Pings der Instanzen untereinander schlugen jeweils fehl. Alle Instanzen liefen zu diesem Zeitpunkt bereits seit einigen Minuten und hatten zur Initialisierung bereits eine große Menge Daten aus dem Netz geladen. Da lief wohl heute in Irland nicht alles so reibungslos ab, wie es eigentlich sollte.

In Einwurf veröffentlicht | Kommentare geschlossen

Quality of Service bei AWS EC2?

Nachdem einer unserer Kunden darauf hinwies, dass seine Website in wenigen Minuten prominent auf Spiegel Online verlinkt wird, habe ich durch zusätzliche EC2-Instanzen die Zahl der Applikationsserver erst verdoppelt und anschließend, als der Ansturm dann doch etwas größer ausfiel als erwartet, verdreifacht. Prinzipiell lief das recht reibungslos (der Kunde ist seitdem zumindest überzeugt, das der Wechsel zu AWS die richtige Entscheidung war), allerdings fiel auf, dass, als das System bereits unter Last war, das Initialisieren der Instanzen sehr lange dauerte. Hierbei werden automatisch einige Tools per apt-get installiert und der Download aus dem Debian-Repository war extrem langsam.

Die anderen Instanzen standen zu diesem Zeitpunkt ja bereits unter Last, aber das sollte doch keine Auswirkungen auf neu gestartete und noch nicht im Cluster eingebundene Instanzen haben. (Die ping-Zeiten deuteten nicht darauf hin, dass physikalisch dieselbe Hardware genutzt wurde.)

Gibt es, zumindest was die Bandbreite angeht, bei AWS eine Art Quality of Service? Für dieses Projekt nutzen wir übrigens ausschließlich Instanzen vom Typ m1.large.

In Allgemein veröffentlicht | Kommentare geschlossen

Problemkind Sicherheit

Auf Kundenseite bestehen die größten Vorbehalte gegen Cloud Computing in der Angst, sensible Daten in die Wolke auszulagern. Im eigenen Rechenzentrum oder dem Speicherplatz eines dedizierten Servers glaubt man die Daten in Sicherheit und unter Kontrolle. Cloud-basierte Systeme hingegen erhöhen zwar die Flexibilität, aber eben auch die Komplexität, da man sich nun verstärkt um Sicherheit kümmern (planen, monitoren, steuern) muss.

Aber ist das wirklich so? Oder hat man bisher eher zu wenig Aufwand in die Sicherheit der eigenen Daten gesteckt?

Auch im Firmeneigenen Netz können Daten gestohlen oder Schadprogramme eingeschleust werden. Nur das hier viel weniger über Verschlüsselung, Anonymisierung, Löschen nicht mehr benötigter Daten, etc. nachgedacht wird. Bei lokal verwalteten Daten ist es sogar wesentlich einfacher, diese auch zu nutzen, da sie der Angreifer viel besser in einen Context stellen kann.

Sind die Daten in Projekten mit Cloud-basiertem Hosting vielleicht sogar sicherer, einfach nur, weil man nun (proaktiv) über Sicherheit nachdenkt?

Ich glaube auch nicht, dass Cloud-Anbieter den Nutzer mit eigenen Sicherheitslösungen unterstützen sollten, da sich hierdurch nur eine weitere Abhängigkeit zum Anbieter (Vendor Lock in) ergibt. Eigene Lösungen können zudem besser auf die jeweilige Anwendung abgestimmt werden.

Es ist also fraglich, ob der Cloud-basierte Ansatz tatsächlich eine geringere Datensicherheit bietet. Vielmehr ist zu erwarten, dass die Kunden verstärkt in die Planung und Umsetzung von Sicherheitslösungen investieren.

In Einwurf veröffentlicht | Getaggt | Kommentare geschlossen

Crowdsourcing – Chancen und Risiken

Wenn ich hier über Cloud Computing spreche, meine ich zumeist IaaS Angebote wie z.B. Amazons EC2. Daneben gibt es natürlich noch viele andere Möglichkeiten, Dienste aus der Wolke zu nutzen – bis hin zum Crowdsourcing. Der einzige Unterschied hierbei ist, dass nicht computing power, sondern brainpower in Anspruch genommen wird.

In seinem Vortrag „Minds for Sale“ (YoutubeFolien) beschäftigt sich Jonathan Zittrain mit verschiedenen Crowdsourcing Lösungen und den damit verbundenen Chancen und Risiken.

Zu Beginn seines Vortrags beschreibt er Crowdsourcing Lösungen, die starke Parallelen zum Cloud Computing aufweisen, z.B. LiveOps, einem Anbieter von Call Center Kapazitäten. Daraufhin legt er seinen Fokus auf jene Nutzer (brainpower Ressourcen), die letztlich die Arbeiten ausführen (er nennt es „cloud labor“) und kategorisiert die Dienste aus deren Sicht. Angefangen von komplexen (teils wissenschaftlichen) Aufgabenstellungen (z.B. InnoCentive), über simple Tasks für wenige Cent (z.B. Amazon Mechanical Turk) bis hin zu Aufgaben, die von den Nutzern praktisch kostenlos übernommen werden (z.B. ESP Game oder Google Flu Trends).

All diese Dinge scheinen auf den ersten Blick nur positive Aspekte zu haben. Zittrain weist allerdings auf fehlende Arbeitsrechte (Arbeitszeit, Kinderarbeit, Überwachung, Kündigung), moralisch fragwürdige (z.B. Subvert and Profit) und zweifelhafte Angebote (z.B. Internet Eyes) hin. Generell hat der Nutzer selten die Möglichkeit, etwas über die Auftraggeber und die Folgen seiner Arbeit zu erfahren. Gleichzeitig sieht Zittrain die Gefahr, dass sich unser Verhalten durch diese Dienste ändert (z.B. wenn Empfehlungen im privaten Kreis von der Aussicht auf Einnahmen aus Crowdsourcing Projekten beeinflußt werden).

Jonathan Zittrain hat zu diesem Thema weiterhin einen Artikel für Newsweek verfasst.

In Fundstück veröffentlicht | Getaggt | Kommentare geschlossen

Jeff Jarvis on privacy

Der amerikanische Journalist Jeff Jarvis amüsiert sich in einem Blogartikel über die deutsche Eigenart, zwar nackt in eine Sauna zu gehen, sich aber gleichzeitig gegen Nacktscanner am Flughafen zu wehren.

Zusammen mit anderen Belegen für die deutsche Datenschutzparanoia (Ablehnung von Google Streetview und Google Analytics, Probleme beim veröffentlichen persönlicher Informationen, z.B. dem Einkommen, etc.) zeigt sich hier sehr schön die unterschiedliche Einstellung zum Umgang mit privaten Daten, über die ich gestern geschrieben hatte.

Und um auf den Saune/Nacktscanner-Vergleich zurückzukommen: natürlich ist es ein Unterschied, ob ich selbstbestimmt in eine Sauna gehe (zur Not mit Handtuch) oder ob ich zur Abgabe persönlicher Informationen gezwungen werde und keine Kontrolle habe, wie diese verwendet werden.

Aber scheinbar ist das Erstaunen über unsere Haltung auf der anderen Seite ebenso groß.

[via]

In Fundstück veröffentlicht | Kommentare geschlossen

Europa vs. USA

Prinzipiell sind Cloud Computing Angebote nicht ortsgebunden. Sie werden einfach konsumiert, unabhängig davon, wo sich die zugrundeliegende Hardware physisch befindet. Gesetze hingegen kennen sehr wohl Ländergrenzen. Daher führen Diskussionen über Cloud Computing irgendwann unweigerlich zum Thema: welchem Schutz unterliegen meine Daten?

Die Herangehensweise an dieses Thema ist in Europa im Vergleich zu den USA eine völlig andere. Setzt man in Europa und speziell in Deutschland auf klare gesetzliche Regeln im Umgang mit personenbezogenen Daten, liegt in den USA die Verantwortung des Schutzes der dieser Daten viel mehr in der Hand eines jeden einzelnen.

Während das Bundesdatenschutzgesetz immer wieder novelliert wird, haben die USA ein ziemlich altes „Datenschutzgesetz“ (Electronic Communications Privacy Act, von 1986). Teilweise wird ein solcher Schutz sogar aus dem 4. Zusatzartikel zur Verfassung der Vereinigten Staaten abgeleitet. Der Gesetzgeber setzt eher auf Transparenz (z.B. Truth in Lending Act) und Eigenverantwortung. Die führenden Cloud Anbieter (mit meist amerikanischem Ursprung) drängen daher auf eine Annäherung der gesetzlichen Regelungen. Ob dies mittelfristig passieren wird, ist allerdings (auch vor dem Hintergrund der gestrigen Ablehnung des SWIFT-Abkommens durch das europäische Parlament) sehr fraglich.

Pauschal würde ich gar nicht beurteilen wollen, welcher Ansatz denn nun der bessere ist (man kann die Sorge um die Sicherheit von Daten nicht nur dem Gesetzgeber überlassen). Probleme ergeben sich aber vor allem dann, wenn man als Nutzer von Cloud Angeboten selbst gesetzliche Auflagen erfüllen muss. Insofern ist es von Vorteil, dass viele Cloud Computing Angebote doch nicht so ortsungebunden sind und man z.B. explizit Rechenkapazität und Speicherplatz in einem europäischen Rechenzentrum nutzen kann.

In Analyse veröffentlicht | Getaggt | Kommentare geschlossen

Motivation der Cloud Anbieter

Gerade wieder lese ich, dass vor allem für Amazon und Google der Hauptgrund, Cloud-basierte Lösungen anzubieten, darin liegt, die Ressourcen der eigenen Rechenzentren besser auszunutzen. Aber ist das wirklich der ursprüngliche Grund? Ist Cloud Computing lediglich ein Abfallprodukt riesiger Rechenzentren?

Beide Firmen bieten besonders erfolgreich möglichst einfach zu handhabende Dienste im Internet an. Gleichzeitig waren sie durch schnelles Wachstum frühzeitig gezwungen, die ebenfalls schnell wachsende Hartwarelandschaft in ihren Rechenzentren kontrollierbar zu halten. Da dabei angeblich hauptsächlich Standardtechnik zum Einsatz kam, mussten eigene Abstraktionsschichten geschaffen und Virtualisierungslösungen entsprechend angepasst werden. Diese Erfahrungen führten zu einer hohen Kompetenz im Aufbau von Rechenzentren.

Ich denke also, dass eher die besondere Hosting-Expertise in Verbindung mit dem Streben nach vielfältigen und möglichst einfach zu bedienenden Diensten die Geburtsstunde der Cloud Computing Angebote von Amazon und Google waren.

In Analyse veröffentlicht | Getaggt , | Kommentare geschlossen

Kapazitätsprobleme bei Amazon?

Habe ich in meinem letzten Beitrag noch die optimale Auslastung in den Amazon Rechenzentren angezweifelt, mehren sich nun Hinweise, dass man bei Amazon sehr wohl an der Auslastungsgrenze fährt – und darüber hinaus.

Alan Williamson von aw2.0, einer Firma, die für ihre Kunden Projekte bei verschiedenen Cloud Anbietern betreut, äußerte vor kurzem in einem Blogbeitrag den Verdacht, dass die Anzahl der zur Verfügung gestellten Instanzen die tatsächliche Leistungsfähigkeit des dahinter stehenden Rechenzentrums übersteigt. Lasten viele Kunden ihre CPUs voll aus oder produzieren besonders viel Netzwerktraffic, wirkt sich das negativ auf benachbarte Instanzen aus. Oft muss Williamson Instanzen so oft neustarten, bis für diese ein etwas „ruhigerer“ Slot gefunden wurde. Um die Performance auf dem gleichen Niveau zu halten, muss er immer öfter auf den nächsthöheren Instanztyp wechseln.

Das ist vielleicht auch eine Erklärung für Ungenauigkeiten, die mir bei einigen Lasttests aufgefallen sind. Entsprachen die Ergebnisse meiner Tests auf dedizierten Servern immer ziemlich genau dem späteren Verhalten der Server unter einer bestimmten Last, wichen die Ergebnisse einiger Tests auf EC2-Instanzen doch etwas vom tatsächlichen Lastverhalten ab. Die fraglichen Tests liefen immer Nachts und zumeist am Wochenende, wenn die Auslastung im Rechenzentrum etwas günstiger sein sollte. Unter der Woche war die Applikation dann merklich langsamer.

Auch war auffällig, dass die kleinsten Instanzen (m1.small) teilweise viel schlechter auf hohe Last reagieren, als es ihre zugesicherten Leistungsparameter vermuten ließen (daher nutzen wir diesen Instanztypen mittlerweile auch ausschließlich für Testclients). Dies könnte ebenfalls ein Indiz dafür sein, dass Amazon bei Kapazitätsproblemen zuerst beginnt, die Leistung der „kleineren“ Instanzen zu drosseln.

Das entspricht aber noch lange nicht den von Alan Williamson beobachteten Phänomen. Auch nutzen wir ausschließlich das Rechenzentrum in Europa; dort mag die Auslastung völlig anders als in den USA sein. Alles in allem eine Problematik, die man im Auge behalten muss. Bei den nächsten Lasttests werde ich mal gezielt auf solche Effekte achten.

In Analyse veröffentlicht | Getaggt | Kommentare geschlossen

Grünes Cloud Computing?

Ein häufig pro Cloud Computing angeführtes Argument basiert auf der Annahme, dass die bessere Auslastung der Rechenkapazität zu einem kleineren Serverpark, insgesamt geringeren Energieverbrauch, geringeren CO2-Ausstoß, etc.  führt. Ist Cloud Computing also die ideale Lösung auf dem Weg zu Green-IT?

Natürlich ist der Gedanke reizvoll: Dank Virtualisierung können ungenutzte Kapazitäten anderen Kunden zu Verfügung gestellt und Server, welche die meiste Zeit brach liegen, besser ausgelastet werden. Es müssen weniger Server betrieben werden, der Energieverbrauch wird verringert, die Kosten sinken, die Kunden freuen sich und gut für die Umwelt ist das allemal.

Nur den Beweis der höheren Auslastung bei Cloud Computing Anbietern bleiben alle schuldig. Ich habe bisher keine Zahlen (vor allem der führenden Anbieter) dazu gesehen. Ich denke, dass eine ganze Reihe von Gründen dagegen sprechen:

  • Die durch höhere Auslastung erreichte Kostenersparnis könnte als Preissenkung an die Kunden weitergeben werden. Tatsächlich sind Cloud Computing Lösungen aber wesentlich teurer als z.B. klassische Root-Server. (Achtung, Apfel/Birnen-Vergleich! Es geht mir nur um die Größenordnung.) Der Server, auf dem z.B. dieses Blog läuft, kostet bei der Firma Hetzner € 49 im Monat. Für einen vergeichbaren Server auf AWS EC2 Basis müsste ich (beim aktuell günstigen Dollarkurs) über € 260 zahlen. Der Vorteil von Cloud Computing ist die bedarfsgerechte Abrechnung, nicht der günstigere Preis.
  • Oft wird darauf verwiesen, dass die Nutzer von Cloud-basiertem Hosting unterschiedliche Peakzeiten, z.B. in den Wochen vor Weihnachten, haben und der Cloud Anbieter so weniger Kapazitäten vorhalten muss. Allerdings scheinen sich diese Peakzeiten zu ähneln, zumindest habe ich außer der Vorweihnachtszeit (und Pizzaservices am Superbowl-Wochenende) noch keine anderen Beispiele gehört. Klar, in der restlichen Zeit des Jahres werden einfach nur andere Seiten angesurft, deren Anbieter werden aber nicht wie die großen Online-Shops gleich ihre Serverkapazitäten erhöhen.
  • Der Cloud Anbieter muss also nicht nur diese allgemeinen Peakzeiten abdecken, sondern hat dazu auch noch das Problem der schlechteren Planbarkeit im Vergleich zum klassischen Hosting mit langfristigen Verträgen. Die vorzuhaltenden Reserven sind im Cloud Computing also wesentlich höher. Evtl. schalten die Anbieter hierfür in schwachen Zeiten Teile des Rechenzentrums ab, allerdings gibt es auch hierfür keine Belege und würde auch nur den Energieverbrauch aber nicht den anzuschaffenden Serverpark reduzieren.

Könnte es nicht sogar sein, dass Cloud Computing Anreize schafft, mehr Dienste auf Server auszulagern? Neue Dienste zu entwickeln, die ohne Cloud gar nicht möglich wären? Oder kurzfristig die Kapazität an Stellen zu erhöhen, wo man früher einfach Performanceprobleme durch zu hohe Last in Kauf genommen hätte? So dass die möglichen Einsparungen durch eine verbesserte Auslastung von den für neue Dienste zusätzlich benötigten Kapazitäten mehr als ausgeglichen werden.

Eine Möglichkeit, Peaks zu umgehen und die Last der einzelnen Dienste besser zu verteilen, könnten Auktionsbasierte Abrechnungsmodelle wie  z.B. Amazons Spot Instances sein. Aktuell liegen die Preise aber immer ziemlich genau im Bereich einer Reserved Instance und ich kann keine steuernden Effekte erkennen. Darüber hinaus gilt auch hier: Informationen darüber, wieviele Instanzen tatsächlich über diese Plattform verkauft werden, gibt es nicht.

Solange also keine Zahlen zur Auslastung der Rechenzentren von Cloud Computing Anbietern vorliegen und solange nicht klar ist, in welchem Maße Cloud-basierte Lösungen klassisches Hosting ersetzen (und nicht einfach neue Dienste schaffen), kann man nicht von einer besseren Ökobilanz des Cloud Computings sprechen.

In Einwurf veröffentlicht | Getaggt | Kommentare geschlossen