1
0
Fork 0
forked from reudnetz/website

blog: add post for 2024.02.07 incident

This commit is contained in:
Gregor Michels 2024-02-07 18:41:35 +01:00
parent 615b9a40f8
commit 5b10ecde65

View file

@ -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.