Ein Großbrand in einem IBM-Rechenzentrum in Almere (Nähe Amsterdam, Niederlande), am 7. Mai 2026, hatte nicht nur zur Folge, dass der E-Mail-Dienst turboSMTP, sondern auch die Dienste von Cisco (Cloud Email Security) offline waren. Ich hatte über diese Ausfälle berichtet. Im Nachgang bin ich dann auch auf die Information gestoßen, dass Kunden der IBM-Cloud in Probleme gerieten, weil Dienste ausgefallen waren. Erstaunlich, wurde "Cloud" doch mal mit Redundanz und was weiß ich verkauft.
Rückblick auf das Feuer in IBM-Rechenzentrum in Almere
Ein Blog-Leser hatte mich auf den Großbrand in Almere (Niederlande) hingewiesen und auf den Beitrag Zeer grote brand bij datacenter Rondebeltweg verlinkt. In einem von IBM betriebenen Rechenzentrum am Rondebeltweg in Almere war am Donnerstagmorgen gegen 08:30 Uhr ein Brand ausgebrochen. Die Feuerwehr stufte den Einsatz auf einen Großbrand hoch.
Beim Brand kam es zu starker Rauchentwicklung und der Betrieb des Rechenzentrums musste eingestellt werden. Das hatte zur Folge, dass der E-Mail-Dienst turboSMTP für mehrere Stunden komplett ausgefallen ist (siehe (serversmtp.com) sind down (7.5.2026) – Brand in Rechenzentrum). Auch die Dienste von Cisco (Cloud Email Security) waren betroffen, wie ich im Beitrag Rechenzentrums-Brand in Almere (NL): Cisco auch betroffen (7.5.2026) berichtete.
IBM-Cloud-Kunden waren ebenfalls betroffen
Im Nachgang habe ich vorige Woche bei The Register im Artikel IBM Cloud evaporates as datacenter loses power gelesen, dass auch Kunden, die Dienste in der IBM-Cloud gebucht hatten, in die Röhre schauten. Das europäische Rechenzentrum war aufgrund eines Stromausfalls mehrere Stunden lang offline, so dass es mit der IBM Cloud ebenfalls einige Probleme gab.
Ein Leser meldete sich bei The Register und teilte mit, dass die IBM Cloud am 7. Mai 2026 mindestens vier Stunden lang offline war. Der Leser schrieb, dass das komplette AMS3-Rechenzentrum der IBM Cloud für mindestens vier Stunden offline war. Sev-1-Tickets seien mehrere Stunden lang unbeantwortet geblieben. Informationen wurden erst auf direkte Nachfrage beim Kundenbetreuer bereitgestellt.
Die IBM Cloud-Statusseite zeigte während dieser Zeit jedoch keine Probleme an. The Register merkt an, dass StatusGator, ein Dienst zur Überwachung von Cloud-Diensten, einen Ausfall der IBM-Cloud anzeigte. Es war von mindestens 10 Nutzern ein "Service down" gemeldet worden, wobei die letzte Meldung über einen Ausfall um 23:25 Uhr UTC des Tages protokolliert wurde.
Massive Auswirkungen auf niederländische Kunden
The Stack hat zum 8. Mai 2026 den Artikel Data centre fire knocks IBM's cloud service offline veröffentlicht und dann laufend aktualisiert. Laut diesem Bericht sorgte der Brand auch für erhebliche IT-Probleme bei niederländischen Organisationen und Firmen. So gab es beim nationalen Statistikamt der Niederlande, CBS, Ausfälle.
Die Universität Utrecht schloss einen Großteil ihrer Einrichtungen wegen erheblichen Problemen mit dem Netzwerk, den Anwendungen und der Website der Uni. Eine lokale Wasserbehörde der Niederlande bestätigte ebenfalls Ausfälle der IT durch den Brand.
Die niederländische Handelskammer (KVK) meldete am 7. Mai ebenfalls ein Problem mit ihren Diensten, hatte das Problem jedoch noch am selben Nachmittag behoben, schreibt The Stack. Das Transportunternehmen Transdev meldete ebenfalls Probleme mit seinen Kommunikationssystemen.
Laut lokalen niederländischen Medien waren auch mehrere Krankenhäuser und Hausarztpraxen von Ausfällen betroffen. Das Flevo-Krankenhaus in Almere bestätigte laut The Stack, dass seine Systeme teilweise über den NorthC-Standort liefen. Deren IT konnte jedoch die Auswirkungen des Ausfalls begrenzen.
Interessant ist, dass die nicht in den Niederlanden angesiedelte britisch-französische Fährgesellschaft Brittany Ferries einen "Brand in einem IBM-Rechenzentrum" als Grund für Probleme mit fehlendem Zugriff auf ihr Reservierungssystem nannte. Kunden konnten während der Störung keine Buchungen vornehmen oder ändern.
Fun Fact: Jemand schrieb auf reddit.com, dass der 7. Mai 2026 der letzte Tag ihrer Rechenzentrumsmigration gewesen sei. Der Betreiber des alten Rechenzentrum hatte mit nur acht Monaten Kündigungsfrist mitgeteilt, dass dieses Data Center geschlossen wird. Jemand betrieb dort 350 Racks, und am besagten Tag war nach monatelanger harter Arbeit der Umzug der letzten Racks in das neue IBM-Rechenzentrum dran – und dann fackelt diese am Morgan ab – schlechtes Karma?
Der Artikel hier gibt an, dass die zur Wiederaufnahme des Rechenzentrumsbetriebs erforderlichen Notreparaturen bis zu 72 Stunden dauern werden.
Was stimmt nicht mit der Cloud?
Nur mal laut nachgedacht: Ein simples kleines Feuer in einem Rechenzentrum in Holland bewirkt, dass eine Menge Organisationen und Unternehmen massiv in ihrer IT beeinträchtigt wurden. 2.500 km weiter östlich tobt ein Krieg, bei dem ständig Infrastruktur zerstört wird. Auch im Nahen Osten sorgt der Iran-Konflikt für zerstörte Rechenzentren mit einhergehenden IT-Einschränkungen. Aber im Grunde herrscht derzeit diesbezüglich doch noch "Sonnenschein" in Westeuropa. Wenn also ein kleiner Brand bereits solche Auswirkungen hat, wie soll das im Konfliktfall funktionieren? Sieht so aus, dass diese ganze Cloud-Welle massive Abhängigkeiten mit vielen Single-Point-of-Failure geschaffen hat. Oder wie seht ihr das so?
MVP: 2013 – 2016
"Sieht so aus, dass diese ganze Cloud-Welle massive Abhängigkeiten mit vielen Single-Point-of-Failure geschaffen hat. Oder wie seht ihr das so?"
sehe ich nur bedingt so. Wer glaubt, Cloud Systeme seinen in jedem Fall verteile standortunabhängige Systeme der irrt. Gerade bei den kleineren Cloud-Diensten. Aber auch ein Unternehmen, dass seine IT zentral On-Prem verwaltet, ist nicht besser dran. Dort ist dann das lokale RZ der Single-point-of-Failure. Insofern muss man das relativieren.
"Insofern muss man das relativieren."
Das mag richtig sein. Aber es stellt sich doch zuvorderst die Frage, will man autark sein (entsprechende Backupmöglichkeiten vorausgesetzt, verringern das geschilderte Risiko) oder sich in – nicht kontrollierbare – Abhängigkeiten begeben.
Gesamtwirtschaftlich gesehen ist die Gefahr der Clouds m.M. ein nicht akzeptables Risiko, erst recht, wenn man auch die weltweiten Gefahren mit ins Kalkül einbezieht.
Da stimme ich absolut zu.
Wir fahren mit lokalem RZ und Terra Cloud Backup + lokales Backup.
Im Notfall (eigenes RZ fackelt ab) kann man die Backups in der Cloud direkt in dem IAAS-bereich der Cloud hochziehen und kann dort weitermachen als wäre nie etwas gewesen^^
10/10 Service und gute Applikation der Cloud Vorteile
Cloud ist nicht ein "unakzeptables Risiko", schlechtes Managment & Planung ist nicht akzeptable ¯\_(ツ)_/¯
Klar, man bekommt, was man bezahlt. Aber als nicht allzu tief in den Details steckender Kunde gehe ich (sofern nichts gegenteiliges kommuniziert wird), dass nicht nur (halbwegs aktuelle) Backups an einem geografisch getrennten Ort gelagert werden, sondern dass auch ein Redundanzsystem mit aktuellen Daten zur Verfügung steht, das bei einem Ausfall kurzfristig in Betrieb genommen werden kann. Ich erwarte, dass der Cloud- oder SaS-Anbieter sich selbstständig darum kümmert, und das gemäß dem Stand der Technik umsetzt, ohne dass ich ihm seinen Job erklären muss. Wenn wir das als kleiner Mittelständler mit ca. 120 Leuten insgesamt und ca. 20 PC-Arbeitsplätzen mit unserem eigenen kleinen On-Premises Server so etwas haben, erwarte ich das von einem Cloud-Anbieter erst recht. Dafür gehe ich in die Cloud, damit ich mir um so etwas "keine Gedanken mehr machen muss". Und ja, ich weiß, dass das in der Realität oft anders ist. Aber das wäre die Erwartung, mit der ich als "durchschnittlich informierter Kunde" an die Sache herangehe.
Erwartungen aus Marketingmaterial vs. Realität im Kleingedruckten. Wer Cloud bucht, sollte genau lesen, sehr genau.
Ich weiß. Hier geht die Realität leider seht weit an dem vorbei, was man als "Firmen-Endkunde" erwartet und erwarten sollte…
Als Standard würde ich Redundanzsysteme und Backups nicht automatisch voraussetzen. Das ist ja keine automatisch zugesicherte Eigenschaft des Konzeptes "Cloud". Hier heißt es bestehende Verträge genau zu lesen und bei Neuverträgen die Themen Redundanz und Backup-Konzept genau zu regeln. Das ist meine Meinung als Informationssicherheitsbeauftragter. Und wenn ich weiterdenke, dann sollte man diese bestellten Leistungen auch hin und wieder zumindest stichprobenartig kontrollieren.
Im Artikel steht öfters, das Rechenzentrum würde von IBM betrieben – im verlinkten Artikel https://www.techzine.eu/news/infrastructure/141170/northc-recovery-of-dutch-data-center-will-take-up-to-72-hours/ steht aber auch, dass es das NorthC-Rechenzentrum in Almere ist, vgl. auch https://www.northcdatacenters.com/de/northc-datacenters/almere/
Stimmt – mir ist aber aktuell nicht so ganz klar, wie stark IBM da involviert ist – ich habe in diversen Berichten den Hinweis auf "IBM-Rechenzentrum" gefunden.
Hostett IBM nicht auch Teile der deutschen Telematik-Infrastruktur im Gesundheitswesen?
Die haben m.W. für einige Krankenkassen die ePA-Speicherung übernommen – der andere Anbieter ist Bitmarck – die Telekom will nun als Dritter im Bunde einsteigen.
> Dort ist dann das lokale RZ der Single-point-of-Failure. Insofern muss man das relativieren.
Die Relativierung darauf ist: Mag sein, dass wenn bei Dr. Müller-Beinbruch die Praxis-IT ausfällt, das wirklich ärgerlich für die Beinbruchsche Praxis und deren Patienten ist, für die Praxis von Dr. Zahnstein ist das allerdings völlig egal, wenn beide nicht verbunden sind. Cloud baut aber einen SPOF für ganze Systeme / Gesellschaften und wenn beide Praxen in eine "Gesundheits-Cloud" müssen (und die auch noch avanti diletanti gebaut wurde), dann gibt es ein systemisches und kein lokales Risiko mehr.
Letztlich ist es auch das, was Elsberg in Blackout beschrieben hat: Fällt im Haus der Strom aus, meh, ist halt dumm für die Leute, aber dann gibt es halt Wein für alle und man macht gemeinsam die Kühlschränke leer. Schaltet man aber zentral für ganze Länder oder Landstriche ab, haben plötzlich alle im System ein Problem.
Und seien wir doch ehrlich: Es geht nicht um "Stabilität", sondern um Kosten. Ja, RZ sind kosteneffizienter als jedem seine Systeme nach Hause zu stellen. Aber sie sind eben auch wirkeffizienter im negativen Sinne wenn sie ausfallen.
Spekulation Anfang.
Ein Rechenzentrum soll geschlossen werden und dann brennt es dort, wirklich "sehr seltsam".
Spekulation Ende.
Nur, dass das Rechenzentrum das abgeschalten wurde nicht das war in dem es gebrannt hat.
Cloud = vServer bzw. Root Server.
Aber um dumme Entscheider über den Tisch ziehen zu können, müssen es einfache Wörter sein. Siehe KI oder Passkey.
Aus Raider wird Twix….
Cisco hat heute wieder Ihre in Amsterdam gehosteten CES-Systeme hochgefahren. Zumindest bei Cisco waren keine Racks/Server zerstört, sondern nur die Stromversorgung. Das CISCO-Ausfallkonzept hat – zumindest bei uns – tadellos funktioniert.
M365 ist redundant aufgebaut, das läuft sogar mit chinesischen Hackern robust durch (oder wegen?)
Redundanz im Rechenzentrum bekommt man nur, wenn man auch Redundanz bucht (und der Anbieter das gescheit macht).
Genau deshalb brauchen wir stark dezentrale resiliente Clouds so wie es die ICP Blockchain leisten kann. Dort kann man alles vollkommen auf der Blockchain hosten, vielfach redundant und sogar auf bestimmte Regionen und Subnets eingrenzen, wenn man zB seine Daten nur in der EU hosten möchte. Und da gibt's dann auch keinen Akteur wie ein Hyperscaler der Mal eben einfach das Datacenter "abdrehen" könnte.
extrem interessantes Projekt, was uns vor Allem in Zukunft vor etlichen Herausforderungen auch im Bereich Infrastruktur Cybersecurity Threats (durch AI oder Quantum Computer) unterstützen kann.
Solange man nicht jegliche Hardware inklusive Netzwerktechnik inklusive aller Chips selbst entwickelt hat, wird es immer jemanden geben, der die nicht selbstgebaute Hardware "abdrehen" kann. Dann nutzt auch eine Blockchain nichts.
das ist so nicht korrekt, Mal abgesehen davon, dass dieses Abschalten von Hardware noch eher theoretischer Natur ist oder hast du einen konkreten Beweis dafür?
Egal, worauf ich hinaus will, für die Nodes und Netzwerke gibt es von ICP zwar Hardware Requirements aber keine Vendor Requirements, es können also diverse Vendors zum Einsatz kommen.
und das "Abschalten" bezog sich auf realistischere Aktionen wie ein Datacenter Brand (jetzt hier bei IBM) oder zB ein Raketenangriff (wie beim Iran). Die Blockchain Technologie hilft hier nicht, das stimmt, stellt "nur" die Integrität sicher.
Das Protokoll von ICP sorgt aber für die nötige Möglichkeit der Verteilung und Diversifikation, und das aber nun auch als Werkzeug den kleinen Unternehmen und Bürgern zur Verfügung stellt und kann zumindest in dem Punkt locker mit den Hyperscalern mithalten, wenn nicht sogar noch überlegen ist.
und die Chefs bei uns gucken uns komisch an, wenn wir Systeme hausintern und redundant an zwei Standorten laufen lassen wollen, anstelle das in irgendeiner Cloud zu hosten…