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

64 lines
2.6 KiB
Markdown
Raw Normal View History

2024-02-07 18:41:35 +01:00
+++
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.
2024-02-08 10:33:12 +01:00
Unser Kernnetz, sowie die Kundenanschlüsse, sind nach dem Stromausfall von selbst wieder hochgefahren.
2024-02-07 18:41:35 +01:00
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
2024-02-08 10:33:12 +01:00
In den folgenden Pläna werden wir erarbeiten an welchen Stellen wir Verbesserungen erzielen können um diese Form von Ausfall zu verhindern.