Kurznachricht: Der Filemanager, unser Web-FTP, ist nun auch über HTTPS erreichbar: https://filemanager.lima-city.de/

Jeder hasst Server-Ausfälle. Du hasst sie, und wir auch. Aber sie passieren. So auch heute, am 25.6.2014 für 6 Stunden und 30 Minuten. Und da wir an unserer Transparenz arbeiten, will ich erklären, was passiert ist und warum die Behebung so lange gedauert hat.

In diesem Blog-Post werde ich erklären:

1. wie das ganze zustande gekommen ist,
2. was wir daraus gelernt haben und was wir tun, damit das nicht noch einmal passiert und
3. was man bei lima-city für’s Geld bekommt und was wir in dem Bereich aktuell planen (und wir brauchen Deinen Input dafür!).

Die Ursache

Heute morgen um 6:56 fing alles an. Auf einem unserer Server, der als System für verschiedene VMs dient, ging der RAM zur Neige. 128GB stecken in dem Server, aber gereicht hat es nicht. Der Host sendete 20 Sekunden lang  Nachrichten an zwei VMs, dass sie sich bitte beenden sollen, sonst würde er das für sie tun. Genau das hat er dann auch getan, und zwar bei dem größten Bad Boy: dem Webspace. Um 6:57 wurde diese VM vom Host-System beendet. Ein bisher einmaliges Ereignis, das auch nicht vorauszusehen war.

Damit war erstmal Feierabend mit dem Webhosting. Ab diesem Moment liefen dann auch die Monitoring-Systeme an und verschickten munter Alarm-E-Mails. Leider war aber zu diesem Zeitpunkt kein Techniker anwesend, um diese zu lesen und zu handeln, aber es sollte noch schlimmer werden: Selbst als die ersten Admins gegen 7:00 erreichbar waren, stellten diese fest, dass es für diesen Fehlerfall gar keine Dokumentation gab. So blieb nichts anders übrig, als die Situation zu analysieren und zu warten, bis derjenige erreichbar ist, der weiß, was zu tun ist (Spoiler: das wäre dann ich). Ich aber hatte bis 4:00 am Server Wartungsarbeiten durchgeführt (die im Übrigen nichts mit dem Ausfall zu tun hatten) und habe Schlaf nachgeholt. Und als ich dann gegen 13:00 auf mein bis dahin lautlos gestelltes Handy guckte, war der Puls bei 180: Monitoring-Mails bis zum Ende seit 7:00 morgens. Das nenne ich mit dem falschen Fuß aufstehen.

Die Systeme wurden dann ganz schnell wieder gestartet und liefen gegen 13:31 wieder. Zwischen 14:49 und 14:52 haben wir noch eine Datenbank  neu synchronisiert. Die Webspaces zeigten in der Zeit den „Schluckauf“-Fehler.

Die Konsequenz

Was tun wir also, damit a) genau dieses Problem und b) ähnliche Probleme nicht wieder auftreten?

1. die RAM-Limits wurden angepasst, so dass die maximale Ausnutzung immer noch genügend freien RAM lässt
2. wir werden unsere Notfall-Dokumentation überarbeiten
3. wir suchen oder bauen Software-Tools, mit denen wir technischen Abläufe automatisieren können, sprich: Technisches Wissen in ausführbare Software umsetzen, die im Notfall nur ausgeführt werden muss

lima-city Webspace: was bekommt man für sein Geld?

Da nun auch die Aussage aufgetaucht ist „Bekomme ich etwas erstattet? Ich hab ja bezahlt, wie kann sowas angehen!“ möchte ich noch etwas erklären zum lima-city Webspace: Wir sind ein Anbieter von kostenlosem Webspace. Wir verkaufen zusätzlich Domains. Man sieht bereits: wir verkaufen Domains, wir verkaufen keinen Webspace. Wir geben für den Webspace auch keine Verfügbarkeitsgarantie. Wir stecken zwar viel Einsatz und Herzblut in die Qualität des Webspace, aber es ist eben auch nur begrenzt Geld und Arbeitszeit dafür vorhanden.

Die Frage deutet bereits darauf hin, dass viele Benutzer hier kritische Anwendungen laufen lassen und sich auch eine garantierte Verfügbarkeit wünschen. Die kann man allerdings auch nur für Geld bereitstellen. Und weil ich gerne bereit bin, Features einzuführen die gebraucht werden (und natürlich auch Geld bringen ;-)) habe ich eine Umfrage erstellt, damit wir herausfinden können, wie so ein Premium-Upgrade denn aussehen soll (und was es kosten darf!):

Umfrage zum Premium-Paket

Es wäre schön, wenn auch die User, die  kein solches Premium-Paket haben wollen, dort teilnehmen. Nur dann wissen wir, wie groß der Anteil der User ist, die das Premium-Paket haben wollen.

Ich könnte mir vorstellen, dass wir das Ganze auf die Beine stellen, wenn etwa 50 User zusammenkommen.

Ich freue mich auch auf viele konstruktive Kommentare. Und wenn jemand seinem Ärger freien Lauf lassen möchte: phillipp.roell (ät) trafficplex.de ist meine E-Mail-Adresse.

Die Hoster der Funpic.de AG Funpic und Ohost sind scheinbar dauerhaft offline. Die Vorstände der Funpic.de AG haben ihr Amt niedergelegt und es sind keine Webseiten mehr erreichbar. Wir berichten über die Situation, Neugkeiten und Hintergründe unter funpic-offline.de.

Für die bei lima-city gehosteten Domains haben wir bisher 2 DNS-Records gehabt, die die den E-Mail-Service referenziert haben: einen MX-Record der auf mail.domain.tld zeigt und einen A-Record mail.domain.tld.

Das wurde nun geändert, so dass nur noch ein Record erstellt wird: ein MX-Record, der auf mail.lima-city.de zeigt. Das hat zwei Gründe:

1. Das TLS-Zertifikat für SMTP-Mail ist für mail.lima-city.de ausgestellt. Ein Server, der über TLS (=SSL) mit mail.domain.tld verbinden würde bekäme eine Zertifikatswarnung, da sich die Hostnamen unterscheiden. Das ist nun nicht mehr der Fall, da mit mail.lima-city.de verbunden wird.
2. Da nur ein A-Record angelegt war gab es auch keine IPv6-Konnektivität. mail.lima-city.de ist aber auch via IPv6 erreichbar. Ein weiterer Schritt also zur vollen IPv6-Konnektivität 🙂

Für bestehende Domains wurde der MX-Record auch geändert, allerdings nur, sofern keine manuellen Änderungen am MX-Record UND an dem A-Record mail.domain.tld vorgenommen wurde. Der Record mail.domain.tld wurde für keine Domain gelöscht, da er für SMTP/IMAP/POP3 verwendet werden könnte.

Auf vielfachen Wunsch hin sind jetzt bei allen gekauften Domains die DNS Einträge direkt editierbar. Es ist nicht mehr nötig das A-Record Feature zu erwerben.

Diese Änderung betrifft sowohl neu gekaufte als auch bereits vorhanden Domains.

Den Editor findet man, wenn man in der bei einer gekauften Domain auf Details und dann Nameserver-Einträge ändern klickt.

Da wir immer wieder kleine und große Verbesserungen vornehmen haben wir nun mal wieder etwas größeres geändert: die Links sind nun nicht mehr standardmäßig unterstrichen sondern nur noch bei einem Hover – gleichzeitig ist die Farbe blau statt wie vorher grau.

Damit folgen wir vielen großen Webseiten: Wikipedia, Amazon, Youtube, heise, Yahoo, Twitter und vielen mehr, die ebenfalls auf diese Art der Typographie setzen.

Daneben haben wir noch ein paar Änderungen an ein paar Kontrast-Einstellungen vorgenommen die nicht wirklich auffallen sollten aber die Lesbarkeit erhöhen.

Als Webhoster kämpfen wir jeden Tag gegen das „böse“ Internet: die Webseiten unserer User werden per Bruteforce gehackt, Kontaktformulare werden für Spam-Versand missbraucht, Bots registrieren nutzlose Accounts oder kommentieren sinnlos Blog-Posts. Diese Bots schädigen unsere User und erzeugen bei ihnen und natürlich auch bei uns eine Menge Arbeit und nutzen kostbare Ressourcen.

Dem haben wir den Kampf angesagt und unserem Webspace eine Bot-Protection verpasst: Wir fragen für alle IPs die unseren Webspace besuchen aktuelle Blacklists ab und prüfen so, ob der „Besucher“ als Bot bekannt ist. Sofern es sich um einen Bot handelt blockieren wir die Anfragen mit der Bitte, sich an uns zu wenden um wieder freigeschaltet zu werden.

Wir leisten so einen Beitrag zur Sicherheit unserer User und zu einer Vermeidung von Ärger für alle Beteiligten :-).

Bei lima-city arbeiten wir ständig daran, die Webseiten unserer vielen User möglichst schnell auszuliefern.

Damit das auch noch bei der großen Menge an Usern vernünftig funktioniert setzen wir seit einiger Zeit den Cache „varnish“ ein, der die Antworten des Webservers, wie im Standard RFC2616 beschrieben, cached.

Dies bringt den Vorteil mit sich dass viele Anfragen, besonders Bilder, Javascript und CSS-Dateien beim zweiten Aufruf wesentlich schneller ausgeliefert werdem.

Das kann aber störend sein, wenn an der Webseite gerade etwas geändert wurde und dadurch die Änderungen nicht sofort durch einen Reload (mit F5) sichtbar werden. Aus diesem Grund gibt es in allen gängigen Browsern den Reload mit Strg+F5. Hier wird dem Server ein zusätzlicher HTTP-Header gesendet, der den Server anweist, den Cache zu aktualisieren (Pragma: co-cache oder Cache-Control: no-cache, eine genauere Übersicht dazu gibt es auf stackoverflow).

Also: wenn Änderungen nicht angezeigt werden: statt F5 einfach die Tasten Strg+F5 drücken und die Seite wird vollständig aktualisiert.

Am Dienstag, den 9.10.2013, haben wir gegen 15:30 auf einem unserer Virtualisierungshosts einige routinemäßige Software-Updates durchgeführt. Bei der Installation eines zusätzlichen Softwarepakets wurde ein Fehler ausgegeben und die Verbindung brach ab. Das System reagierte anschließend weder auf Verbindungsversuche noch auf Ping-Pakete. Nachdem auch die Remote-Konsole kein Bild zeigte, wurde das Host-System neu gestartet.

Nach dem Neustart wurden vor dem Start der Dienste die Paket-Installationen und -Updates beendet um keinen erneuten Ausfall zu provozieren.

Nachdem diese Arbeiten abgeschlossen waren wurden die Dienste nacheinander neu gestartet.

Aufgrund des RAID-Resyncs war die IO-Kapazität stark eingeschränkt, so dass die Dienste langsamer als gewohnt starteten. Gegen 16:30 waren alle Systeme bis auf den Mail-Server und die Webspaces wieder voll funktionsbereit.

Die Webspaces wurden vorerst nur eingeschänkt gestartet (die lima-city.de-Subdomains waren mit dem HTTP-Code 503 gesperrt), um die Caches vorzuwärmen. So waren zwar gekaufte und aufgeschaltete Domains verfügbar, nicht aber die Subdomains (*.lima-city.de). Alle Zugriffe wären mit einem „kalten“ Cache und der eingeschänkten IO-Kapazität zu viel gewesen und hätten alle Webspaces lahmgelegt. Über den restlichen Tag wurde sukzessive ein immer größerer Namensraum der Subdomains reaktiviert. Am späten Abend waren dann wieder alle Webspaces online.

Auch der Mail-Server zeigte, verursacht durch den Spam-Filter, erhöhte IO-Last, so dass dieser vorerst deaktiviert bleiben muss. Wir suchen hier noch eine Lösung (die Token-Datenbank für die statistische Bewertung der E-Mails ist mittlerweile zu groß geworden).

Wir entschuldigen uns für den Ausfall und bedanken uns für die Geduld.