Störung eines Mailservers am 14./15.07.2016

In der Nacht vom 13. zum 14.07.2016 kam es nach routinemäßigen Wartungsarbeiten an einem unserer Mailserver zu umfangreichen Störungen, die wir leider erst nach etwa 36 Stunden vollständig beheben konnten. Wir möchten in diesem Beitrag auf einige Fragen unserer Kunden eingehen und die Hintergründe des Ausfalls erläutern. Für die mit der Störung verbundenen Unannehmlichkeiten bitten wir vielmals um Entschuldigung.

Was ist passiert?

Am 13.07. haben wir um 23 Uhr die IMAP-Software eines unserer Mailserver auf eine neue Version aktualisiert. Andere Mailserver nutzten die neue Version bereits ohne Probleme, daher war nicht mit Schwierigkeiten zu rechnen.

Auf diesem Server kam es jedoch einige Stunden nach der Aktualisierung zu ebenso massiven wie unerklärlichen Performance-Problemen: Sobald der Server mehr als 1.500 IMAP-Verbindungen hatte, stieg die Serverlast extrem an und der Server reagierte nicht mehr. Dies führte zu erfolglosen Verbindungsversuchen, Timeouts und Verbindungsabbrüchen.

Das Update konnte nicht mehr rückgängig gemacht werden, da nach der Aktualisierung an allen Postfächern Änderungen durchgeführt wurden, die nicht abwärtskompatibel sind. Wir waren daher gezwungen, die Fehlerursache so schnell wie möglich zu finden und zu beheben. In den folgenden 36 Stunden bis zur Behebung des Fehlers haben unsere Mitarbeiter ununterbrochen daran gearbeitet. Zunächst vermuteten wir als Fehlerursache einen Engpass im Speichersystem, daher entschlossen wir uns, den betroffenen Mailserver von Festplatten auf schnellere SSDs umzurüsten. Da mehrere Terabyte an Daten kopiert werden mussten, hat es bis in die Nacht des folgenden Tages gedauert, bis der Server wieder online gehen konnte. Leider zeigte diese Maßnahme keinerlei Wirkung.

Am Ende stellte sich das Problem als ein Programmierfehler in der zentralen Postfachdatenbank der von uns eingesetzten Mailserver-Software Cyrus heraus. Perfiderweise manifestiert sich der Fehler nur unter bestimmten Bedingungen so dramatisch wie in unserem Fall. Am 15.7. gegen 13:30 führten wir Maßnahmen zur Umgehung des Fehlers durch, die das Problem erfolgreich behoben haben. Der Fehler wurde anschließend an die Entwickler der IMAP-Serversoftware kommuniziert und umgehend behoben. Durch die schnellen SSDs im Server ist der E-Mail-Zugriff nun schneller als je zuvor.

Zu keinem Zeitpunkt sind E-Mails verloren gegangen. In der Zeit, in der der Server nicht erreichbar war, wurden eingehende E-Mails auf anderen Servern zwischengespeichert und später zugestellt. Einige Kunden berichten davon, dass während der Störung gesendete E-Mails nicht als Kopie im Ordner „Gesendet“ abgelegt wurden. Dies kann tatsächlich durch die Überlastung passiert sein. Wenn Sie Informationen benötigen, ob eine bestimmte E-Mail tatsächlich verschickt wurde, können wir dies für einige Tage in unseren Logdateien nachvollziehen. Bitte kontaktieren Sie in diesem Fall unsere Kundenbetreuung.

Wozu die neue Version?

Wir haben das Update vorgenommen, um Probleme mit der automatischen Erkennung von Standard-Ordnern unter Microsoft Outlook zu beheben. Die von uns nun verwendete Version 2.5.8 ist die neunte stabile Veröffentlichung in der 2.5.x Serie.  In dieser Software, die seit über einem Jahr (2.5.0 wurde am 03.03.2015 veröffentlicht) weltweit produktiv im Einsatz ist, haben wir keine Fehler solchen Ausmaßes mehr erwartet und in unseren Tests auch nicht erkennen können.

Welche Dienste genau waren betroffen?

Bei dem betroffenen Server handelt es sich um eines von mehreren „Mail-Backends“. Dies sind Server, auf denen die E-Mails unserer Kunden als Dateien gespeichert sind. Diese Server sind nicht direkt von außen erreichbar. Es gibt MX-Server, die E-Mails von fremden Mailservern annehmen und auf dem Mail-Backend ablegen. Der Abruf der E-Mails erfolgt dann über Dienste wie POP3 und IMAP, die überwiegend lesend auf die Mail-Backends zugreifen. Da wir mehrere Mail-Backends betreiben, waren von der Störung nur Domains betroffen, die auf diesem Backend eingerichtet waren. Viele Kunden waren irritiert, dass sie Probleme beim Abruf der E-Mails von einer Domain hatten, E-Mails von einer anderen Domain aber problemlos abgerufen werden konnten. Nach außen sieht es so aus, als wären „imap.variomedia.de“ bzw. „pop3.variomedia.de“ nur ein Server, tatsächlich ist es jedoch ein sogenannter Proxy, der die Verbindungen an das für das jeweilige Postfach zuständige Backend weiterleitet.

Wie wurden Kunden über die Störung informiert?

Die einzige realistische Option, alle Kunden im Fall einer solchen Störung aktiv zu informieren, wäre eine E-Mail gewesen. Gerade die betroffenen Kunden hätten die E-Mail aufgrund der Störung aber gar nicht abrufen können. Besonders aufgrund solcher Zusammenhänge nutzen wir für die Meldung von Problemen oder Ausfällen unseren Twitter-Feed, der auch ohne Twitter-Account öffentlich aufrufbar ist. Über beide Tage hinweg haben wir hier aktuell über den Stand der Dinge berichtet und auch viele Fragen von Kunden beantworten können. Nicht gelungen ist es uns, alle Anrufe anzunehmen; dafür waren es einfach zu viele Kunden, die völlig berechtigt wissen wollten, wann der E-Mail-Abruf wieder zuverlässig funktioniert.

Entschuldigung!

Wir sind uns bewusst, dass E-Mails ein wichtiger Pfeiler des privaten und geschäftlichen Lebens sind und ein längerer Ausfall für unsere betroffenen Kunden sehr schmerzvoll ist. Dafür bitten wir in aller Form um Entschuldigung.

Update vom 16.07.2016, 16:45 Uhr: Ergänzung zur Frage, ob E-Mails verloren gegangen sind hinzugefügt.

15 Replies to “Störung eines Mailservers am 14./15.07.2016”

  1. Vielen Dank für die ausführlichen Infos!
    Als Admin kann ich die Überraschung nachvollziehen:
    Es kommt nicht selten anders als man denkt. 😉
    Vielen Dank für die schnelle Arbeit und weiter so!

  2. Hallo Variomedia,

    natürlich ist eine so lange Störung eines Mailservers für uns als Kunden eine ärgerliche Geschichte. So weit ich das von außen beurteilen kann haben Sie aber eigentlich alles richtig gemacht. Ich kenne es aus eigener Erfahrung, dass Software, die lange und breit anderswo problemlos im Einsatz ist, in einem ganz bestimmten Setting dann auf einmal massive Probleme macht. Das kann passieren. Und dann finde ich es vorbildlich, wie Sie kommunizieren: Neuigkeiten per Twitter, anschließend eine transparente Kommunikation per Blog, am Ende eine Entschuldigung. Chapeau und danke für den Einsatz.

  3. Besten Dank für Ihre offene Kommunikation

    Zwei Dinge möchte ich anmerken:

    1. Twitter-Feed: Ich habe auf Ihrer Homepage nachgeschaut und keine Service-Status-Seite gefunden. Ich habe kein Problem damit, wenn eine solche auf Twitter verweist, aber ich würde da schon einen Link erwarten.

    2. Wenn die Serverlast bei über 1500 Verbindungen extrem ansteigt, würde ich primär die CPU oder das Netzwerk (zu viel Kommunikation mit den Clients) als Aufrüst-Kandidaten sehen, nicht aber den Storage. Vielleicht hatten Sie gute Gründe für Ihren Verdacht, die mir aus Ihrem Post nicht klar wurden…

    1. Vielen Dank für Ihre Vorschläge! Der Twitter-Feed ist unten links auf unserer Webseite verlinkt, allerdings nicht explizit als Status-Seite. Wir nehmen diesen Hinweis gerne auf und werden einen solchen Link unterbringen.

      Die Ursache lag leider nicht eine Überlastung der Server-CPUs oder der Netzwerk-Inferfaces, dann hätten wir den Fehler sofort erkannt und schnell behoben. Ab einer bestimmten Anzahl von IMAP- und POP3-Verbindungen kam es zu einem Deadlock beim Zugriff auf die zentrale Postfachdatenbank, die einzelnen Server-Prozesse blockierten sich dann gegenseitig und es konnten keine E-Mails mehr abgerufen werden. Für uns sah es zunächst so aus, als läge die Ursache in einem zu langsamen Speichersystem, da die Prozesse beim Datei-Zugriff blockierten, daher der Umzug auf SSDs. Letztendlich lag die Fehlerursache bei zu vielen unbeabsichtigten Memory Mapped File I/O Operationen beim Zugriff auf eine Datenbank-Datei. Den Entwicklern unserer IMAP-Software war dieser Fehler bisher nicht aufgefallen, weil er nur unter bestimmten Bedingungen so extrem auftritt wie bei uns.

  4. Hallo VM-Team,
    unter den gegebenen Umständen habt ihr alles richtig gemacht.
    Super Kommunikation, ich war stets auf dem Laufenden.
    Vielen Dank für den Einsatz!

  5. Von mir auch vielen Dank für die ausführliche Kommunikation. Ich bin selbst Programmiererin und kann sehr gut nachvollziehen, wie nervenaufreibend das für alle Mitarbeiter gewesen sein muss.

  6. Liebes VM Team,
    professionelles Handling der Situation und transparente Kommunikation. Das wünsche ich mir auch von anderen Providern. Die sollten sich mal ein Beispiel nehmen ;).
    Der Tipp mit dem Servicestatus auf der VM Hauptseite ist super und ich unterstütze das.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.