[[Startseite|← Zurück zur Startseite]] # Server und Virtualisierung Ein Server, sechs Gastsysteme: Haussteuerung, Dokumentenarchiv, Funkanbindung, Blog-Redaktion und zwei weitere Dienste. Dazu ein zweiter, normalerweise ausgeschalteter Server als Notfallweg. **Virtuelle Maschine oder Container?** Eine vollständige virtuelle Maschine bekommt nur, wer ein eigenes Betriebssystem mitbringt – die Haussteuerung etwa, die als geschlossenes System ausgeliefert wird. Alles andere läuft als Container: derselbe Kern, deutlich weniger Arbeitsspeicher. Der Unterschied ist im Alltag spürbar, wenn ein Dienst mit einem halben Gigabyte auskommt statt mit vier. ## Eine Migration, die messbar war Die Haussteuerung schrieb spürbar träge. Statt zu vermuten, wurde **gemessen** – über vierzehn Stunden Laufzeit: | Befund | Wert | |---|---| | Verhältnis Schreib- zu Lesevorgängen | **8,6 : 1** – ein klar schreiblastiger Betrieb | | Durchschnittliche Schreiblatenz | ~6,4 ms | | **Latenz beim Festschreiben auf die Platte** | **~9,45 ms** | Neun Millisekunden sind für eine SSD ungewöhnlich viel. Die Ursache lag nicht am Gast, sondern an der Nachbarschaft: Andere Dienste teilten sich denselben Speicherpool, verschärft durch neu eingeführte Snapshot-Ketten. Die schnellere Platte im selben Gerät lag bei **null Prozent Auslastung**. Der Umzug lief im laufenden Betrieb: Sicherungsstand als Rückfallebene geprüft, Snapshot-Ketten aufgelöst, dann 150 GB per Spiegelung übertragen. **Rund acht Minuten, ohne Unterbrechung** – die Haussteuerung war durchgehend erreichbar. **Ehrlich dazu:** Die Nachmessung der Latenz steht bis heute aus. Die Auslastungszahlen belegen den Umzug, aber nicht, dass er das Problem gelöst hat. Das ist als offener Punkt vermerkt. ## Was die Praxis gelehrt hat **Ein Fehler, der sich nur im Protokoll zeigte.** Der stündliche Snapshot der Haussteuerung scheiterte regelmäßig – während einer laufenden Sicherung ist das System gesperrt. Sichtbar wurde es nirgends: keine Meldung, keine Mail. Erst der Blick ins Protokoll zeigte **28 Fehlversuche**. Die Laufzeiten erklärten das Muster: An einem Tag war die Sicherung nach 28 Minuten fertig, am nächsten nach 78. Nur im zweiten Fall kollidierte sie. Behoben wurde es **nicht** durch Verschieben der Sicherung, sondern durch Streichen eines einzelnen Snapshot-Laufs. Begründung: Statt fünfzehn entstehen täglich vierzehn Snapshots – bei sechs aufbewahrten Ständen ändert das an der Abdeckung nichts. Die einfachere Änderung war auch die risikoärmere. **Fest verdrahtete Kennungen brechen genau dann, wenn niemand daran denkt.** Ein Wartungsskript hatte die Kennung der Haussteuerung fest eingetragen. Als diese umzog, lief das Skript ins Leere. Seitdem **erkennt es das System selbst**, indem es alle laufenden Gäste abfragt und prüft, wer sich als Haussteuerung meldet. Dasselbe Verfahren wurde in ein zweites Skript übernommen, das die Haussteuerung ausnehmen muss. **Was eine Sicherung des Gastes nicht enthält.** Der wichtigste Punkt für einen Wiederaufbau, und der am leichtesten übersehene: Eine Container-Sicherung enthält den Container – nicht das, was am Wirtssystem eingerichtet wurde. Dafür gibt es eine ausdrückliche Liste: eingebundene Netzlaufwerke, ein Eintrag zur Namensauflösung, zwei Wartungsskripte, fünf Systemdienste, zwei Zugangsdateien. Alles von Hand nachzuziehen, wenn der Server einmal neu aufgebaut werden muss. Wer diese Liste erst im Ernstfall zusammensucht, verliert Stunden – und merkt manches erst, wenn es fehlt. **Abgeschaltete Dienste brauchen eine Entscheidung.** Zwei Dienste wurden stillgelegt. Statt sie weiterlaufen zu lassen oder ersatzlos zu löschen, wurde ihre jüngste Sicherung **gegen die automatische Aufräumfrist geschützt**. Die Dienste sind weg, ihr Zustand ist erhalten. Ohne diesen Schritt hätte die Aufbewahrungsregel sie nach wenigen Tagen mitentsorgt. ## Wenn Zahlen eine Beschaffung begründen Der Speicherbedarf für einen bestimmten Vorgang überstieg wiederholt die Möglichkeiten des Geräts. Statt Hardware nach Gefühl zu kaufen, wurde während eines echten Großvorgangs gemessen – und dabei zeigte sich, dass **zwei verschiedene Anforderungen** dahinterstecken: - Der eine Vorgang ist **speichergebunden** – er fordert alles in einem Zug an und scheitert am Arbeitsspeicher. - Der andere ist **rechengebunden** – der Speicher blieb halb leer, aber die Verarbeitung lag dauerhaft am Anschlag eines Prozessorkerns. Beide Anforderungen sind berechtigt, aber aus unterschiedlichen Gründen. Ohne diese Trennung hätte man das Falsche verstärkt. Bemerkenswert war die Marktrecherche danach: Die Wunschvorstellung – acht echte Kerne bei sehr niedriger Leistungsaufnahme – gibt es praktisch nicht. Aktuelle sparsame Prozessoren mischen starke und effiziente Kerne. Die Anforderung wurde daraufhin **angepasst statt stur gehalten**. Beschafft ist bis heute nichts. Das Anforderungsprofil steht, jede Zeile mit Begründung. ## Woran wir gerade arbeiten - **Eine stark schwankende Sicherungslaufzeit**: einmal 84 Minuten, einmal 379. Die Ursache ist ungeklärt, und der lange Lauf blockiert nebenbei mehrere Snapshots - Nachmessung der Latenz nach dem Plattenumzug - Ein vorbereiteter Netzwerk-Wächter liegt fertig da, ist aber nicht eingeplant ## Was wir daraus mitnehmen Die Aufgabe ist selten, etwas zum Laufen zu bringen. Sie besteht darin, **zu merken, wenn etwas nicht mehr läuft** – und das gelingt nur, wenn man ins Protokoll sieht, statt darauf zu warten, dass sich ein Fehler von selbst meldet. Achtundzwanzig Fehlversuche hatten niemanden gestört, weil sie niemandem aufgefallen waren. --- *Stand: 27.07.2026* --- [[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]