Was ist passiert?
Am vergangenen Donnerstag, den 28.02.2013, kam es ab 18:00 Uhr zu einem Teilausfall unseres zentralen Storage-Systems. Rund 50% aller Server sowie weitere Dienste wie das my.cyon und das Webmail waren infolge dessen nicht mehr erreichbar. Die Störung konnte am darauffolgenden Morgen, den 01.03.2013, gegen 11:30 Uhr wieder behoben werden.
Auch wenn eine Verfügbarkeit von 100% in der realen Welt nicht existiert, gibt es für uns kaum etwas Schlimmeres, als eine solche Störung. Wir wissen, wie verheerend ein solcher Ausfall für unsere Kunden sein kann und entsprechend setzten wir unsere ganze Kraft ein, um das Problem raschestmöglich zu lösen.
In diesem Bericht möchten wir nebst dem technischen Hintergrund und den getroffenen Massnahmen auch auf häufige Fragen eingehen, die uns zum Ausfall erreicht haben.
Der technische Hintergrund
Grundsätzlich ist bei unserer Infrastruktur alles redundant ausgelegt, was redundant ausgelegt werden kann. Redundanz bedeutet, dass ein Ausfall einer bestimmten Komponente durch eine zweite Komponente aufgefangen wird. So verfügen wir beispielsweise über zwei getrennte (und USV-gestützte) Stromkreise, zwei Zuleitungen ins Internet, zwei Router, mehrere Switches, mehrere Netzteile etc.
Auch die vom Teilausfall betroffene Komponente, der zentrale Storage, ist redundant ausgelegt. Unsere Server speichern Daten nicht auf lokal verbaute Festplatten, sondern legen diese (über ebenfalls redundante Verkabelung) auf externe Festplatten ab, also auf ebengenannten Storage. Folgende Animation zeigt vereinfacht, was bei einem Ausfall eines sogenannten Controllers geschieht:
1. Normalbetrieb
2. Störung auf Controller A
3. Controller B übernimmt den Betrieb ohne Unterbruch
Dieser Failover hat sowohl bei den intensiven Tests vor Inbetriebnahme und auch schon im Livebetrieb tadellos funktioniert.
Am 28. Februar klappte das Ganze allerdings nicht wie gewünscht: Der ausfallende Controller A hat das Dateisystem beschädigt, weshalb Controller B nicht einspringen konnte:
1. Normalbetrieb
2. Störung auf Controller A
3. Dateisystem wird beschädigt
4. Controller B kann den Betrieb nicht übernehmen
Was tun wir, damit sich dieses Problem nicht wiederholt?
Zum aktuellen Zeitpunkt ist noch unklar, warum a) Controller A ausgefallen ist und b) warum dabei auch noch das Dateisystem beschädigt wurde. Der Fall ist beim Hersteller weiterhin in Abklärung.
Im Sinne einer zeitnahen Information zum Ausfall veröffentlichen wir diesen Bericht trotzdem schon heute und werden an dieser Stelle ein Update einfügen, sobald weitere Informationen vorliegen.
Update vom 17.05.2013: Gemäss dem Hersteller ist die Ursache weiterhin nicht restlos geklärt, da wir bislang die weltweit einzigen Kunden (!) sind, bei denen dieser Fehler aufgetreten ist. Daraus ergeben sich nur wenig Daten, die zur Problemanalyse verwendet werden können.
Häufige Fragen
Uns haben rund um die Panne eine Vielzahl an Fragen erreicht, welche wir gerne auch öffentlich beantworten:
Warum betreiben Sie die gesamte Infrastruktur nicht gespiegelt in einem zweiten Datacenter, damit man bei einem Ausfall einfach umschalten kann?
Dafür gibt es vor allem zwei Gründe:
- Es gibt keine Garantie, dass die Verfügbarkeit besser wird, wenn man einen zweiten Standort betreibt. Ein solches Setup erhöht auch die Komplexität und eröffnet neue potentielle Fehlerquellen. Als Beispiel kann Gmail herhalten: Die Infrastruktur ist über mehrere Rechenzentren verteilt und trotzdem ist die Uptime nicht bei 100%. Ein anderes aktuelles Beispiel ist Cloudflare: dieser Dienst soll die Verfügbarkeit von Websites erhöhen, ist über 23 Rechenzentren verteilt und hatte dennoch letzte Woche einen (wenn auch relativ kurzen) Ausfall (Quelle).
- Das Kosten-/Nutzenverhältnis ist ungenügend. Die Kosten für die hinteren Kommastellen bei der Verfügbarkeit nehmen exponentiell zu und müssen in einem vernünftigen Verhältnis zum Preis unserer Dienstleistung stehen.
Weiter wäre es nicht so, dass sich die Kosten für die doppelte Hardware “nur” verzweifachen, es kämen noch grosse Beträge für die Synchronisation zwischen den Standorten und das zusätzlich benötigte Engineering hinzu.
Trotz unseres Ausfalls von letzter Woche ist unsere Verfügbarkeit immer noch sehr hoch.
Die ungeplante Downtime aller Webserver beträgt in den letzten zwölf Monaten vor dem Ausfall weniger als eine Stunde, die Verfügbarkeit liegt also bei über 99.98%. Mit dem Ausfall sinkt dieser Wert auf den betroffenen Servern um 0.2% womit im Mittel ein Wert von über 99.88% resultiert.
Warum schalten Sie auf meiner Website keine Informationsseite auf, damit meine Besucher über den Ausfall informiert werden?
Das ist eine gute Idee und sofern unser Netzwerk noch funktioniert, technisch auch machbar. Ein Projekt zur Umsetzung ist bereits in Arbeit und kommt nach Fertigstellung auf unseren Notfall-Plan.
Ich wollte mit Ihnen persönlich über den Ausfall sprechen, doch es kam nur eine aufgezeichnete Nachricht, die über den Ausfall informiert. Warum?
Uns erreichen in einer solchen Situation hunderte Anrufe, wir würden also ein ganzes Heer benötigen, um alle persönlich zu beantworten. Besser als ein Besetzt-Zeichen ist aus unserer Sicht eine aufgezeichnete Nachricht mit Informationen zum aktuellen Stand.
Wie macht cyon eigentlich Backups?
Wir betreiben einen zweiten Storage, der sich räumlich getrennt in einer anderen Brandschutzzone befindet. Darauf werden mindestens einmal täglich alle Daten des primären Storage kopiert und wir behalten mehrere Versionen dieser Backups auf.
Warum spielen Sie nicht einfach ein Backup zurück?
Dafür gibt es zwei Gründe:
- Auch wenn das letzte Backup erst ein paar Minuten alt wäre, befinden sich auf dem primären Storage bereits wieder neuere Daten. Diese würden beim Zurückspielen eines Backups verloren gehen. Besonders unglücklich ist dies bei E-Mails: Geht in dieser Spanne eine E-Mail ein, die vor dem Einspielen eines Backups vom Empfänger nicht gelesen wurde, wird weder er noch der Absender jemals etwas davon erfahren.
- Das Einspielen eines Backups ist nicht innert ein paar Minuten erledigt, es müssen dabei sehr grosse Datenmengen kopiert werden.
Unser Backup ist also vor allem eine “Lebensversicherung”, wenn die Daten auf dem primären Storage unwiederbringlich verloren gehen sollten. Daten von gestern sind immer noch besser, als gar keine Daten.
Der Erhalt der Daten auf dem primären Storage hat aber immer höchste Priorität und die Wahrscheinlichkeit eines Verlustes ist dank vielen Redundanzen sehr klein.
Ich verliere viel Geld durch den Ausfall, dafür möchte ich eine Entschädigung.
Uns ist es völlig bewusst, dass unsere Kunden eine 100%ige Erreichbarkeit wünschen und wir arbeiten Tag für Tag daran, diesem Ziel möglichst nahe zu kommen. In diesem Geschäftsfeld ist die Erreichbarkeit schliesslich einer der wichtigsten Kennzahlen, mit denen jeder Hoster zu punkten versucht. Dass eine 100%ige Erreichbarkeit in der Praxis jedoch nicht existiert, ist leider eine Realität, mit der sich die gesamte Industrie abfinden muss.
Eine entsprechende 100%ige Garantie auf Verfügbarkeit können wir also aus Gründen der Machbarkeit nicht anbieten. Leider folgt daraus auch, dass wir auf Entschädigungsforderungen nicht eintreten können. Seien Sie aber versichert, dass uns die Erreichbarkeit unserer Dienste im eigenen Interesse sehr am Herzen liegt.
Wie sieht es eigentlich bei Ihnen im Büro während einem solchen Ausfall aus?
Das kommt immer etwas auf die Situation an. Findet der Ausfall während der Bürozeiten statt, herrscht eine etwas gedrückte, aber fokussierte und konzentrierte Atmosphäre. Jeder weiss wo er anpacken kann und wir geben all unsere Kräfte.
Da sich Pannen jedoch nicht an Öffnungszeiten halten, wird die Technik ab und an auch aus dem Bett gerissen. Es wird jeweils die Lage beurteilt und nach Notwendigkeit werden weitere Teammitglieder beigezogen, in unserem internen Chat ist dann Hochbetrieb.
Nicht selten rückt die Technik auch ins Rechenzentrum aus, um den “Brand” vor Ort zu löschen, falls dies ferngesteuert nicht möglich ist.
Besonders gefreut haben uns während des Ausfalls die auch zahlreichen positiven und ermutigenden Kommentare unserer Kunden – das ist in einer solchen Situation eine willkommene Unterstützung und zauberte manch Lächeln auf sonst müde Gesichter.
Zum Abschluss möchten wir uns erneut bei allen Betroffenen in aller Form entschuldigen. Vorfälle wie dieser bedeuten für uns das schlimmstmögliche Szenario und gehören sicherlich nicht zur Erfahrung, welche wir unseren Kunden je zumuten möchten.
Für Fragen und Anmerkungen, sei es via Kommentarfunktion als auch über die weiteren Kanäle, haben wir wie immer offene Augen und Ohren.
The .swiss business plan is designed to avoid any future necessity to increase registry price in real terms. The fundamental principle is prudence: starting from conservative price levels and gradually lowering them. This method ensures sufficient financial reserves, favors optimal allocation of domain names, helps prevent misuse and supports an orderly registration process.
