content/blogposts/2024-02-07-outage.md

@@ -0,0 +1,63 @@
++++
+title = "Incident 07.02.2024"
+date = "2024-02-07"
++++
+
+In der Nacht von Dienstag auf Mittwoch (06.02.24 - 07.02.24) ist in der Wurzner Straße der Strom ausgefallen und hat uns eine ungeplante Downtime geschenkt.
+
+Unser Kernnetz, sowie die Kundenanschlusse, sind nach dem Stromausfall von selbst wieder hochgefahren.
+
+Allerdings mussten wir bei beiden Hosting-Servern manuell eingreifen und bis in die Mittagsstunden des Folgetages Entstörungen durchführen.
+
+---
+
+## Verlauf
+
+* 2024.02.06 23:30 CET: Stromausfall
+    * gesamter Ausfall unserer Infrastruktur
+* 2024.02.07 00:20 CET: Stromausfall beendet
+    * Kundenanschlüsse stehen wieder zur Verfügung
+* 2024.02.07 11:00 CET: _hyper01_ und _sol_ unlocked
+    * _hyper01_: Kunden VMs wieder online
+    * _sol_: bootet ohne Netzwerkkonnektivität - Reverse-Proxies und interne VMs weiterhin offline
+* 2024.02.07 14:30 CET: _sol_ entstört
+    * Reverse-Proxies und interne VMs wieder Verfügbar
+
+Seit 2024.02.07 14:30 CET ist das Reudnetz wieder uneingeschränkt online.
+
+---
+
+## Entstörung _sol_
+
+_sol_ ist nach dem Freischalten der `full-disk-encryption` ohne Netzwerkkonnektivität gebootet.
+Eine fehlkonfigurierte Boot-Partiton hat einen veralteten Linux-Kernel gebootet für den das OS keine Kernel-Module mehr bereitgestellt hat.
+
+Durch die fehlenden Module konnte _sol_ seinen Netzwerk-Stack nicht konfigurieren da hierfür (unteranderem) das `bonding` Modul für 802.3ad (LACP) benötigt wird.
+
+_sol_ konnte über das IPMI entstört werden.
+
+Der Grund für die defekte Boot-Partiton war eine Wartung im Juni 2023.
+Beim Austausch der HDDs in _sol_ gegen SSDs wurde die Bootpartition per `dd` kopiert.
+Durch die gleichen FS/UU-IDs hat der Kernel das /boot auf der SSD gemountet, welches nicht in der Firmware als Boot-Device hinterlegt war.
+Somit haben sich das Boot-Device und die eigentliche /boot-Partition immer weiter voneinander entfernt.
+
+## Full-Disk-Encryption
+
+Die Festplattenverschlüsselung von _hyper01_ und _sol_ musste manuell durch einen admin freigeschaltet werden.
+
+Das ist 11 Stunden nach Ende des Stromausfalls passiert.
+
+## PDU issues _hyper01_
+
+Aufgrund von Netzteilproblemen ist _hyper01_ nicht automatisch gestartet.
+Weder die Betätigung des `power-buttons`, noch das IPMI konnten den Server starten.
+
+
+Aus Energieeffiziengründen wird _hyper01_ nur mit einem Netzteil betrieben.
+Der Wechsel auf das Ersatznetzteil hat dem Server dann zum Starten verholfen.
+
+---
+
+## Reflektion
+
+In den folgenden Pläna werden wir erarbeiten an welchen Stellen wir Verbessrungen erzielen können um diese Form von Ausfall zu verhindern.