In den frühen Morgenstunden des 27. August 2026 kam es bei Proton zu einem weitreichenden Ausfall, der die Dienste für eine Reihe von Benutzern beeinträchtigte. Die Hauptursache war ein Totalausfall des Kühlsystems in unserem Rechenzentrum in Frankfurt. Obwohl alle Systeme bei Proton redundant ausgelegt sind und wir über genügend Kapazität verfügen, um den Ausfall eines kompletten Rechenzentrums zu überstehen, gibt es einige wenige Szenarien, in denen das Failover länger dauern und zu Beeinträchtigungen für die Benutzer führen kann.

Hier ist eine Chronologie dessen, was passiert ist, welche Entscheidungen wir während des Vorfalls aus welchen Gründen getroffen haben und wie das Problem behoben wurde.

Chronologie

Kurz nach 23:00 Uhr (mitteleuropäischer Zeit) am Mittwoch, dem 26. August, trat im Hauptraum unseres Frankfurter Rechenzentrums ein Ausfall des Kühlsystems auf. Gegen 23:15 Uhr stieg die Temperatur in weniger als einer halben Stunde von ca. 21,8 °C (Solltemperatur) auf 51,9 °C an, wobei einige Messsonden eine Raumlufttemperatur von 60 °C meldeten. Als die Temperaturen stiegen, begannen Server und Netzwerkgeräte in der Einrichtung nach und nach auszufallen.

Die für Benutzer spürbare Störung begann gegen Mitternacht am 27. August, als die Ausfälle so weit eskalierten, dass die kritische Redundanz verloren ging. Dies geschah, als sowohl der primäre als auch der Backup-Netzwerk-Switch in einem kritischen Rack ausfielen – und dieses Rack enthielt unglücklicherweise mehrere primäre Datenbankkopien. Während fast alle Proton-Systeme redundant sind und ein Failover automatisch bzw. sofort durchführen, werden Failovers primärer Datenbanken nicht ohne menschliche Aufsicht automatisch durchgeführt.

Wir behalten diese Kontrolle bei, um sogenannte „Split-Brain“-Situationen zu vermeiden, bei denen eine vorübergehende Nichtverfügbarkeit einer primären Datenbank dazu führt, dass die Replikatkopien einige Aktualisierungen verpassen und asynchron werden, was später nur schwer wieder abgeglichen werden kann. Wenn ein Failover einer primären Datenbank erforderlich ist, sieht das Standardverfahren zudem aus Latenz- und Leistungsgründen ein Failover auf ein Replikat im selben Rechenzentrum vor. Aufgrund der spezifischen Art des Problems wäre dies jedoch unklug gewesen, da wir potenziell ein Failover auf ein System durchgeführt hätten, das ebenfalls ausfallen würde.

Die Entscheidungen

Zu diesem Zeitpunkt mussten die Bereitschaftstechniker von Proton unter extremem Druck einige folgenschwere Entscheidungen treffen.

  • Priorisieren sie es, den Dienst wieder online zu bringen, oder hat die Behebung des Kühlungsproblems und die Rettung der Hardware im Rechenzentrum Vorrang?
  • Sollten wir ein Failover auf Replikate im selben Gebäude in Frankfurt durchführen (schneller und weniger störend, aber möglicherweise nur eine vorübergehende Lösung, falls die Hitze nicht unter Kontrolle gebracht werden kann) oder ein Failover nach Zürich?
  • Führen wir ein Failover für alles durch oder nur für das, was im Moment ausgefallen ist? Wir haben Notfallpläne für den kompletten Ausfall eines Rechenzentrums, bei denen Failovers vollständig und größtenteils automatisch recht schnell ablaufen. Eine Situation jedoch, in der willkürlich Server nacheinander ausfallen, wird von unserer Failover-Logik nicht gut abgedeckt.

Letztendlich zwang uns der rasante Temperaturanstieg dazu, die Rettung der Hardware gegenüber der Wiederherstellung der Onlinedienste zu priorisieren. Das ist eine Entscheidung, die normalerweise nicht getroffen werden muss, da Kühlsysteme in der Regel redundant ausgelegt sind und ein vollständiger Ausfall der Kühlung sehr selten ist, sodass normalerweise genügend Zeit bleibt, bevor die Temperaturen kritisch werden. Verschärft wird das Problem durch den starken Anstieg der Serverleistungsdichte in den letzten Jahren infolge leistungsstärkerer CPUs und GPUs für KI. Infolgedessen wurde eine Situation, die früher 3 bis 4 Stunden bis zum kritischen Zustand gebraucht hätte, bereits nach 20 Minuten kritisch.

Das Bereitschaftsteam konzentrierte sich daher auf die Kommunikation mit dem Betriebsteam des Rechenzentrums vor Ort, um die Kühlung wiederherzustellen, während gleichzeitig so viele Server wie möglich heruntergefahren wurden, um sie zu schützen. Aufgrund des Mangels an Serverausrüstung infolge des anhaltenden KI-Booms wäre ein Großteil dieser Hardware – im Falle eines Verlusts – kurzfristig nicht ersetzbar gewesen. Ihre Rettung musste Priorität haben, selbst auf die Gefahr hin, dass sich die Ausfallzeit dadurch verlängert.

Bis 00:45 Uhr MESZ konnten wir die Kühlung wiederherstellen und die Temperaturen in der Anlage begannen zu sinken, woraufhin sich das Bereitschaftsteam auf die Wiederherstellung der Dienste konzentrierte. Zu diesem Zeitpunkt entschieden wir uns für ein Failover der primären Datenbanken nach Frankfurt, sofern noch ein Replikat aktiv war, und nach Zürich in den Fällen, in denen in Frankfurt kein Replikat mehr verfügbar war. So wollten wir verhindern, unsere Datenströme zu stark zu verändern und möglicherweise neue Instabilitäten zu schaffen. Diese Option wurde gewählt, da wir davon ausgingen, dass es nach der Wiederherstellung der Kühlung relativ einfach und schneller wäre, Frankfurt wieder online zu bringen, als nach Zürich umzuschalten.

Leider erwies sich dies nicht als der Fall. Während des Vorfalls erreichten viele Netzwerkkarten in der Frankfurter Infrastruktur eine Temperatur von 105 °C (die normale Betriebstemperatur liegt bei 45 °C), was einen speziellen Temperaturschutzmodus auslöst und dazu führt, dass die Netzwerkkarten bis zu einem Kaltstart des Systems deaktiviert werden. Unsere Sicherheitsrichtlinien schränken den Zugriff auf den Out-of-Band-Controller unserer Systeme ein, weshalb wir zusätzliches Personal aufwecken mussten, um bei der Wiederherstellung zu helfen.

Bis 01:30 Uhr MESZ konnten wir die meisten Dienste für die Mehrheit der Benutzer wieder online bringen. Einige weniger kritische Systeme wie Push-Benachrichtigungen oder die Zahlungsabwicklung wurden jedoch erst gegen 02:00 Uhr MESZ wiederhergestellt.

Wie wir bereits im ersten Vorfallbericht mitgeteilt haben, gingen keine E-Mails verloren, die Zustellung von E-Mails in beiden Richtungen verzögerte sich jedoch während des Vorfalls.

Obwohl die Dienste für die Benutzer wieder vollständig hergestellt waren, war die Nacht für unsere Ingenieure, insbesondere für das Datenbankteam, noch nicht vorbei. Unsere Infrastruktur befand sich in einem höchst ungewöhnlichen Zustand: Einige primäre Datenbanken liefen in Zürich, andere in Frankfurt, und mehrere von ihnen arbeiteten mit reduzierter Redundanz und/oder verringerter Leistung. Unser Team arbeitete die ganze Nacht durch, um die dringendsten dieser Probleme zu beheben, und die Arbeiten wurden am 27. August den ganzen Tag über fortgesetzt, um die volle Redundanz wiederherzustellen.

Obwohl wir fast die gesamte Infrastruktur retten konnten, erlitten einige Server leider den Hitzetod, und wir wissen noch nicht, ob der Hitzevorfall die Lebensdauer der verbleibenden Hardware beeinträchtigen wird.

Hauptursache und nächste Schritte

Eine anschließende Untersuchung am 27. August ergab, dass die Hauptursache für den Ausfall der Kühlung der Austausch von Luftfiltern an beiden redundanten Luftkompressoren war, die das Kühlsystem antreiben. Leider führte der Betreiber des Rechenzentrums diesen Eingriff mitten in der Nacht und ohne vorherige Ankündigung durch. Zudem versäumte er es, den Ausfall der Kühlung direkt zu melden, was unsere Reaktionszeit drastisch verkürzte. Wir arbeiten eng mit dem Betreiber zusammen, um eine Wiederholung eines solchen Vorfalls zu verhindern.

Es ist jedoch auch eine bekannte Einschränkung unserer derzeitigen Datenbankinfrastruktur, dass ein Ausfall dieser Art zu einem längeren Wiederherstellungsprozess als üblich führen kann. Die Reihe von Ereignissen, die zu diesem Vorfall führte, ist äußerst unwahrscheinlich – dennoch ist sie eingetreten.

Die Arbeiten zur Erhöhung der Datenbank-Resilienz, die zur Behebung dieses Fehlerzustands erforderlich sind, laufen bereits und sollen planmäßig bis Ende des Jahres abgeschlossen sein. Zusätzliche Infrastrukturkapazitäten, einschließlich neuer Rechenzentrumsflächen, werden derzeit ebenfalls in Betrieb genommen und dürften in den nächsten Wochen verfügbar sein, was unsere Abhängigkeit von einzelnen Standorten weiter verringern wird.

Leider ereignete sich dieser Vorfall, bevor diese Verbesserungen vollständig umgesetzt waren. Wir prüfen nun, an welchen Stellen wir die verbleibenden Arbeiten sicher beschleunigen können, während wir gleichzeitig die nötige Sorgfalt bei Änderungen an kritischer Datenbankinfrastruktur walten lassen.

Wir sind uns bewusst, dass unsere Benutzer von Proton ein sehr hohes Maß an Zuverlässigkeit erwarten, und dieser Vorfall unterstreicht, wie wichtig es ist, diese Arbeiten abzuschließen und unsere Resilienzstandards kontinuierlich weiter anzuheben. Wir entschuldigen uns nochmals uneingeschränkt bei allen Benutzern, die von dem Ausfall betroffen waren.