When The Power Goes Out at Google

Auf Royal Pingdom hat Guy Rosen 5 Gründe aufgelistet, warum das absoluter Unfug ist:

1. Eigene Server haben auch Ausfälle.
2. Es ist nur GMail.
3. Es ist trotzdem noch bequemer.
4. Es ist trotzdem noch kosteneffizienter.
5. Wer 100% Verfügbarkeit benötigt, braucht ein Backup.

Hier das Original mit Begründung zu den einzelnen Punkten: 5 reasons Gmail’s fail is not the end of cloud computing

Kritk wurde in diesem Zusammenhang an der unpersönlichen Art, mit der Google den Vorfall handhabt, laut. Es wird in diesem Zusammenhang immer deutlicher, dass die Kunden den direkten Dialog mit Unternehmen suchen. Im oftmals gelobten Echtzeit Web dementsprechend natürlich auch in Echtzeit. Eine Herausforderung der sich gerade die Unternehmen stellen müssen die hauptsächlich mit dem Internet bestens vertraute Nutzer haben. Wozu eine Cloud Hosting Plattform wohl zählen dürfte.

Gestern Abend hatte Amazon EC2 in den USA einen kleinen Ausfall zu vermelden. Wie dsa AWS Service Health Dashboard zu berichten weiss, beruhte der Ausfall auf einem Blitzeinschlag und einen damit verbunden Stromausfall in einem Teil der Racks in einer Availability Zone. Offensichtlich war da wohl Gewitter in der Amazon Cloud. Nachdem ich mir dieses offensichtlich Wortspiel nicht verkneifen konnte verweise ich noch auf das AWS Service Healt Dashboard für weitere Details zum Ausfall.

Bildquelle: cc George Donnelly

Alle Details zum Vorfall und zur Gutschrift hat DataCenterKnowledge

Die IT-Welt kannte gestern ja quasi kein anderes Thema als die Übernahme und dementsprechend groß war wohl auch der Andrang auf die Oracle Seiten. Diesem hielten die Server und das CMS nicht stand und kapitulierten. Oracle schaffte es dann eine statische HTML Seite mit der Bitte die Hotline anzurufen online zu stellen.

Wieso das jetzt besser skalieren sollte als die Information im Web erschliesst sich mir jedenfalls nicht. Damit bin ich auch offensichtlich nicht der einzige, denn Adriaan Bloem von CMSwatch schrieb: “it’s like a fail whale, with Jonah failing inside” in Anspielung auf den Scherz, Oracle hätte SUN nur gekauft um zu schauen ob Twitter den Tweetsturm überlebt.

Oracles CMS hat ihn jedenfalls nicht überlebt und die Mitarbeiter an der Hotline werden ihren Spaß gehabt haben. Mit Cloud Computing wäre das nicht passiert?

via Software as services

Bildquelle: Flickr cc ronin691

Was war der Grund?

Das Blog wird auf einem Server von Server4You gehostet. Dieser, so stellten wir gestern um ca. 15 Uhr fest war nicht erreichbar. Daraufhin versuchten wir den üblichen Reboot über das Adminpanel und als dieser Erfolglos blieb das Rettungssystem. Ebenfalls ohne Erfolg.

Ein Anruf bei der Hotline sollte Abhilfe schaffen. Zuerst musste ich mich allerdings von dem Mitarbeiter auf unhöflichste Art und Weise anfahren lassen, ich hätte die falsche Hotline angerufen. Letzendlich liess er sich dann dazu herab mir die richtige Nummer zu nennen fügte aber alsbald hinzu, dass sei ausschliesslich eine Ticketannahme.

Was dies bedeutet wurde mir einen Anruf später bewusst, es nahm tatsächlich jemand das Telefon ab und machte nichts weiter als ein Ticket zu erstellen in das er reinschrieb, dass ich angerufen  habe. Ansonsten sagte man mir, der Server sei in einer Stunde wieder erreichbar. Weitere Informationen was denn los sei und was jetzt unternommen werde waren nicht in Erfahrung zu bringen.

Kurze Zeit später war der Server dann im Rettungssystem gebootet. Das normale System war von außen nicht zu erreichen. Die üblichen verdächtigen in solchen Fällen, Firewall und Netzwerkkarte wurden auch alsbald überprüft. Firewall und Netzwerkkarte wiesen aber auf den ersten Blick keine Probleme auf. Nach einiger Zeit stellten wir fest, dass sich die MAC-Adresse geändert hatte. Also die UDEV Regel angepasst und neu gestartet. Wieder war kein Server erreichbar.

Mach mehreren Stunden suchen stellt sich dann heraus, es war Hardware getauscht worden. Zwar erneut ein Motherboard mit Nvidia Chipsatz, jedoch offensichtlich eine andere Version der Hardware. Der Debian Etch 2.6.18 Kernel hatte zwar das notwendige “forcedeth” Modul dabei, jedoch unterstützte dieses die neue Hardware noch nicht. Ein Update auf eine neuere Kernelversion behob dieses Problem dann auch.

Es dauerte alleine 3-4 Stunden um dieses Problem zu finden. Vergeudete Stunden, die wir, hätte man uns Seitens Server4You kurze eine E-Mail geschickt: “In ihrem Server ist das Motherboard ausgetauscht worden. MfG …”, hätten für sinnvollere Dinge verwenden können. Z.B. unser eigenes Produkt weiterentwickeln.

Laut Support ist es für Server4You aber unmöglich den Kunden über einen Hardwaretausch zu benachrichtigen. Ich erwarte ja nichtmal, dass die selbe Hardware verbaut wird. Bei einem Lowcost-Server bestehend aus Consumerhardware auch nur schwer möglich. Aber eine Benachrichtigung, dass etwas getauscht wurde muss möglich sein.

Dies ist einer der Gründe, warum ich der Ansicht bin, dass Startups sich nicht dadurch behindern sollten eigene Server zu administrieren. Nur leider kostet ordentliche Hardware mit ordentlichem Support auch ordentlich Geld. Cloud-Hosting allerdings bietet Ausfallsicherheit durch redundante Komponenten und keinerlei eigenen Administrationsaufwand. Für mich ganz klar die bessere Alternative.

Der beste Support ist nämlich immernoch der, den man nicht benötigt weil alles einfach funktioniert.

Die Kündigung für den Server4You Server geht jedenfalls morgen in die Post. Zwar sind wir durch die lästige Mindestlaufzeit noch einige Monate gebunden, aber zumindest wird durch die Kündigung jemand darauf aufmerksam, dass wir nicht zufrieden sind. Eine Beschwerde-Mail an den Support hat lediglich bewirkt, dass der bereits wieder verfügbare Server ohne, dass darum gebeten wurde ins Rettungssystem gebootet wurde. Was das Blog erneut Offline nahm. Das kommt wohl dabei raus, wenn der Support bei Server4You eigenständig denkt…

Bildquelle: Flickr Qfamily

Bildquelle: Media Temple

Durch Ausfälle zweier Netzwerkspeicher waren ca. 3000 Accounts des Cloud Hosting Anbieters Media Temple für ungefähr 38 Stunden nicht erreichbar. Media Temple erläutert die Hintergründe zum Ausfall in einem Bericht und verspricht den betroffenen Kunden Gutschriften im Wert von 100.000 Euro.

Laut Bericht kam es zu dem Ausfall auf Grund eines korrupten Datenspeichers. Zwar war dieser redundant ausgelegt, aber auch der zweite Controller quittierte wenige Minuten nach dem ersten seinen Dienst und dies führte dann zu einem Totalausfall des Datenspeichers für Cluster2. Insgesamt befanden sich auf dem System nach Media Temple angaben 80 Millionen Dateien mit einer Gesamtgröße von 2,9 Terabyte. Die Media Temple Techniker benötigten ca. 2 Stunden um Zugriff auf den Datenbestand zu erhalten und konnten dann mit der Überprüfung des Dateisystems beginnen. Entsprechend der Datenmenge benötigte dieser Vorgang einige Zeit.

Während des Ausfalls machten die Kunden auf Twitter und in Blogs ihrem Unmut lautstark luft. Insbesondere missfiehl den Kunden die zaghafte Informationspolitik. Media Temple hat dies mitlerweile eingestanden und gelobt Besserung. Während des Ausfalls seien die Techniker mit der Behebung beschäftigt gewesen und hätten deshalb nicht die nötigen Informationen zur Veröffentlichung weitergeben können.

In der Hitze des Gefechts erscheint dies auf den ersten Blick verständlich. Auf den zweiten Blick darf man aber fragen wieso es in einem großen Unternehmen niemanden gibt der dafür zuständig ist die Kunden bei Ausfällen zu informieren. Es würde ja reichen wenn sich jemand zu den Technikern stellt und zuhört…

via Datacenter Knowledge

Imap Zugriff soll zwar weiter möglich gewesen sein, aber das Webfrontend verweigerte seinen Dienst. Laut Google dauerte der Ausfall zweieinhalb Stunden. Acacio Cruz seines Zeichens Gmail Site Reliability Manager bei Google erklärte den Ausfall im Offiziellen Gmail Blog.

Laut Cruz führten planmässige Wartungsarbeiten in einem der europäischen Rechenzentren zu einem Ausfall dieses Rechenzentrums. An sich sollte dies nicht weiter problematisch sein, da die Anfragen der Nutzer jederzeit von einem der anderen Rechenzentren beantwortet werden können. Zu den Wartungsarbeiten gesellte sich allerdings ein Fehler in einer neuen Funktion die dafür sorgt, dass die Nutzerdaten geografisch nah bei den Besitzern gespeichert werden. Dieser Code war fehlerhaft und führte zur Überlastung eines weiteren europäischen Rechenzentrums. Was dann durch eine Art Dominoeffekt auch noch andere Rechenzentren in Mitleidenschaft zog.

Mitlerweile ist Googlemail wieder erreichbar und der fehlerhafte Code gefunden und beseitigt.

Was zeigt uns dieser Ausfall? Selbst in den besten Familien hat Quelltext Fehler. Ausfälle lassen sich nicht völlig vermeiden. Perfektion kann es nicht geben, man kann lediglich versuchen nah ran zu kommen. Einen Rückschluss auf die Zuverlässigkeit von Software as a service an sich, kann man aus diesem Ausfall jedenfalls nicht ziehen. Bei einer internen E-Maillösung hätten Wartungsarbeiten das System ohnehin lahmgelegt. Ein Ausweichen auf ein anderes Rechenzentrum wäre wohl nur bei sehr großen Konzernen möglich gewesen.

Dass dieses Ausweichen jetzt nicht geklappt hat ist natürlich ärgerlich, aber im Endeffekt sollte jeder Verständnis dafür aufbringen können, dass Technik ab und an dazu tendiert auszufallen.