Management Summary
Die Bestandsflotte umfasst zehn Bare-Metal-Server mit zusammen rund 140 CPU-Kernen, etwa 1,3 TB RAM und mehreren Terabyte Datenbankvolumen. In Summe halten die fünf datenbanktragenden Server rund 2.891 GB logisches Datenvolumen.
Entscheidend für das Sizing sind zwei Hebel, die die Datenmenge drastisch reduzieren. Erstens: Von rund 557 Tenants sind nur 153 aktiv (Login, Versand oder Job innerhalb des letzten Jahres) — rund 73 % können entfallen. Zweitens: Das logische Volumen aus information_schema überzeichnet den realen Plattenbedarf um etwa das 1,7-fache (auf Server 03 verifiziert: 1.106 GB logisch vs. 656 GB real). Auf realer Plattenbasis schrumpft das Migrationsziel damit auf ~550 GB (aktive Tenants inkl. kompletter Statistik) bzw. ~240 GB für die reinen Kerndaten.
Hinzu kommt ein operativer Treiber: alle zehn Server laufen auf abgekündigten Betriebssystemen (Debian 8/9, Ubuntu 16.04/18.04). Ein DB-Server läuft seit über acht Jahren ohne Reboot — also ohne Kernel-Patches. Das verschärft die Dringlichkeit der Migration unabhängig von der reinen Kapazitätsfrage.
Start mit fünf OpenStack-VMs (~34 vCPU / ~168 GB RAM / ~2,55 TB SSD + ~1 TB Backup-Objektspeicher): 2× All-in-one-LAMP (App+DB), 2× KumoMTA und 1× Monitoring. Phasenstart mit je einem Knoten möglich (18 vCPU / 88 GB / ~1,4 TB). Der primäre Hebel ist RAM (Buffer-Pool), nicht die vCPU-Zahl — die aktuelle Pilot-VM mit 4 vCPU / 8 GB ist als Produktiv-DB zu klein.
Untersuchungsumfang
Ziel der Analyse ist die vollständige Inventarisierung der alten sendeffect/IEM-Infrastruktur (Hardware sowie Datenbank- und Migrations-Footprint), um sie der neuen VM-Umgebung gegenüberzustellen und den initialen Ressourcenbedarf für die Datenmigration zu schätzen. Alle Bestandsserver werden nach der Migration außer Betrieb genommen. Die Hostnamen folgen dem Schema 11335-NN.root.easyname.cloud; Zugangsdaten unterscheiden sich pro Server.
| Tier | Server | Rolle | DB-Analyse | Status |
|---|---|---|---|---|
| Datenbank | 03 | reine DB | vollständig | HW + DB erfasst |
| 05 | reine DB | vollständig | HW + DB erfasst | |
| 07 | gemischt (Web + DB) | vollständig | HW + DB erfasst | |
| 08 | gemischt (Web + DB) | vollständig | HW + DB erfasst | |
| 12 | gemischt (Web + DB) | vollständig | HW + DB erfasst | |
| Web | 02 | nur Web | keine DB | HW erfasst |
| 04 | nur Web | keine DB | HW erfasst | |
| Versand (MTA) | 06 | PowerMTA-Relay | n/a | aktiv, im Scope |
| 10 | PowerMTA-Relay | n/a | aktiv, im Scope | |
| 13 | PowerMTA-Relay (laststärkster) | n/a | aktiv, im Scope | |
| Aux | 09 | se2ifo / ifo-Institut (Custom) | ~1,4 GB | im Scope (Sonderfall) |
Außerhalb des Scope: Server 11 (einzelne, fremde Kundenwebsite) und 01 (bereits abgebaut). Die Server unterscheiden sich stark in Spezifikation, Alter und Größe — sie wurden einzeln erfasst und nicht voneinander hochgerechnet.
Methodik & Zählweise
Tenancy-Modell: Tenant = künftige Instanz
Jede sendlx_<N>-Datenbank entspricht einer IEM-Installation (ein vHost sf<N>.sendsfx.com) mit vielen Nutzern. Entscheidend: jede Nutzerzeile (userid/ownerid) ist selbst ein Tenant. In der neuen Umgebung wird jeder dieser Nutzer zu einer eigenen Instanz (eigene DB + Webroot). Die Zahl der neuen Instanzen richtet sich also nach der Zahl der aktiven Nutzer, nicht nach der Zahl der alten Datenbanken.
Aktiv-Regel (vereinbart)
Ein Nutzer gilt als aktiv, wenn er innerhalb des letzten Jahres eingeloggt war ODER versendet ODER einen Job ausgeführt hat. Login allein reicht nicht — die API versendet auch ohne Login. Signale: users.lastloggedin, MAX(stats_newsletters.starttime) je Absender und MAX(jobs.jobtime) je Owner.
data_length + index_length aus information_schema überzeichnet den tatsächlichen Plattenbedarf. Auf Server 03 verifiziert: 1.106 GB logisch gegenüber 656 GB real per df (~1,7×) — Ursache sind aufgeblähte Index-Statistiken bei Compact-Tabellen, keine Kompression. Alle GB-Angaben in diesem Bericht sind, sofern nicht anders vermerkt, logische Obergrenzen; real auf Platte ≈ 0,6×. Die KEEP-Prozentsätze sind Verhältnisse und davon unberührt. Ein Dump-and-Reload nach MariaDB landet nahe der realen Plattenbasis.
Sizing-Ansatz (bewusst „leichtgewichtig")
- Pro-DB-/Tabellen-Größen über information_schema.tables (sofort verfügbar) — echte Zeilenzahlen via COUNT(*), da table_rows stark unterschätzt.
- Subscriber-Zuordnung zum Owner über list_subscribers ⋈ lists gruppiert nach Owner — jeder Subscriber gehört genau einem Owner.
- Statistik-Zuordnung ohne Scan der großen Tabellen: stats_newsletters trägt Pro-Kampagnen-Rollups; KEEP-Anteil daraus auf die realen Tabellengrößen anwenden.
Sicher aus der Migration ausschließbar
Bounce-Logs (list_subscriber_bounces_misc), Arbeits-/Temp-Tabellen (*_temp, aaa_*) und rekonstruierbare Suppression-Hashes (hashblacklist_*, list_subscriber_md5/sha*). Die Frage der Statistik-Aufbewahrung (komplette Historie vs. rollierendes Fenster) ist die größte verbleibende Stellschraube und in Abschnitt 10 als offener Punkt geführt.
Datenbank-Tier im Detail
Jeder DB-Server wurde einzeln erfasst. Pro Server zeigen wir das Hardware-Profil, die Datenbank-Eckdaten und die vier Migrationsszenarien (jeweils logische GB). Die Balken sind je Server relativ zum „Alles"-Szenario skaliert.
Datenhaltung durch aktive Nutzer: Hier halten die aktiven Nutzer die Daten — der Inaktiv-Filter spart nur ~33 GB. Dominanter Hebel ist das Statistik-Fenster (~109 GB komplette Historie vs. ~10 GB nur ≤1 Jahr). Dominiert von sendlx_27 (~263 GB, 99 % aktiv) und sendlx_6 (~157 GB). Vollständig verwerfbar: sendlx_25 und sendlx_26 (vorher verifizieren).
Stärkste Reduktion über den Inaktiv-Filter: der Inaktiv-Filter dominiert (Kern 64,5 → ~4 GB). Große Instanzen sind quasi tot (sendlx_2 39 M Subscriber @ 0,1 % aktiv; sendlx_4 und 21 vollständig inaktiv). Echter Migrationsinhalt ≈ 110 GB; ein Dump-and-Reload gewinnt zusätzlich ~137 GB Fragmentierung zurück.
Uptime 3.031 Tage (~8,3 Jahre) — seit acht Jahren keine Kernel-Patches oder Reboots. Erhebliches Betriebs- und Sicherheitsrisiko, das die Migration zusätzlich begründet. Die 2,2 TB belegt auf / sind zu ~1,9 TB nicht datenbankbezogen (für den Operator zu klären, nicht migrationsrelevant).
Charakteristik: Größter Hebel ist hier das Verwerfen der Historie (436 → 121 GB), gefolgt von inaktiven Tenants (121 → 57 GB). Nur 3,4 % aller Opens sind jünger als ein Jahr. Borderline-Fälle vor dem Verwerfen prüfen: sf36 (0 aktiv, 15 GB Opens) und sf32/senddigital (Aktiv-Stichtag um nur 4 Tage verfehlt).
Dringlich: Last ~33 bei 32 Threads zur deutschen Versand-Hauptzeit (19:00 CEST) und nur noch 108 GB freie Platte. Starker Kandidat für eine frühe Migration. Lesson learned: die Opens-Proxy-Schätzung (~142 GB) überzeichnete den exakten Kern-KEEP (~103 GB) — Kerntabellen müssen über die Subscriber-Ebene attribuiert werden, nicht über den Absender-/Opens-Proxy.
Stark fragmentiert: 228 GB von 545 GB sind freier (reklamierbarer) Platz — ein Dump-and-Reload nach MariaDB gewinnt diese zurück. Dominiert von sendlx_200 (202 M Subscriber, 13 aktive Tenants). Inaktiv: sendlx_969 (24 Nutzer, 0 aktiv, 17 GB Opens verwerfbar).
Flotten-Rollup — alle fünf DB-Server
Alle fünf Server sind exakt vermessen (keine Proxys mehr). Die Tabelle zeigt logische information_schema-GB; die reale Plattenbasis liegt bei ~0,6× (siehe Lesehilfe in Abschnitt 03).
| Server | Volle DBs | Kern aktiv | + Stats ≤1 J. | + alle Stats | Tenants aktiv |
|---|---|---|---|---|---|
| 03 | 1.106 | 337 | 347 | 446 | 37 |
| 05 | 184 | 4 | 5 | 17 | 15 |
| 07 | 436 | 57 | 60 | 93 | 27 |
| 08 | 620 | 103 | 112 | 220 | 37 |
| 12 | 545 | 111 | 120 | 138 | 37 |
| Summe (logisch) | ~2.891 | ~612 | ~644 | ~914 | 153 |
| ≈ real auf Platte | ~1,7 TB | ~240 | ~385 | ~550 | — |
Das Migrationsziel ist serverabhängig: 07 und 05 schrumpfen massiv über inaktive Nutzer, 03 kaum (dort halten aktive Nutzer die Daten — nur das Statistik-Fenster hilft). Selbst auf realer Plattenbasis liegt der aktive Kern bei ~240 GB über drei der fünf DB-Server. Daraus folgt: die neue Umgebung braucht mehrere TB-fähige VMs — die aktuelle Pilot-VM mit nur 100 GB Disk ist ausdrücklich ein Pilot, nicht die Zielkapazität.
Web-Tier
Diese beiden Server halten keine Datenbanken; erfasst wurde die Hardware für ein vollständiges Bild der Alt-Flotte. Über ihre Webroots wurde zudem die Zuordnung der reinen DB-Server bestätigt (10.254.25.71 = Server 03, 10.254.25.46 = Server 05).
Sehr alte CPU (Nehalem-EP). Last ~11 von 16 — geschäftiger Web-Tier.
Kürzlich rebootet (Uptime 14 Tage), aktuell im Leerlauf (Last ~0,45).
Versand-Tier: PowerMTA → KumoMTA
Das Versand-Tier wird anders dimensioniert als das DB-Tier: Treiber sind die Spitzen-Versandrate, die Verbindungs-Concurrency, die Anzahl Versand-IPs sowie der (kleine) Live-Spool und die Log-/Accounting-Aufbewahrung. Die drei Bounce-Log-NFS-Shares, die die Web/DB-Boxen einhängen, sind die MTAs selbst — es gibt keine separate Bounce-Infrastruktur.
| Server | Hardware | PMTA | Versand-IPs | Peak out/h | /data belegt |
|---|---|---|---|---|---|
| 06 | DL360 Gen9 · 20C/40T · 64 GB · Ubuntu 16.04 | v4.0r17 | 1.832 | ~333K | 238 GB |
| 10 | DL360p Gen8 · 24C/48T · 64 GB · Debian 9 | v5.0r9 | 386 | ~349K | 176 GB |
| 13 | DL360 Gen9 · 24C/48T · 128 GB · Ubuntu 18.04 | v5.0r9 | 1.691 | ~802K | 858 GB |
| Summe | ~68C/136T · ~256 GB RAM | — | ~3.909 | ~1,48M | ~1,27 TB |
Server 13 ist der laststärkste (pmtad ~69 % CPU, ~2,95 Mrd. ausgehende Nachrichten Lifetime). Alle drei laufen auf EOL-Betriebssystemen — teils mit 230–473 Tagen Uptime, um den Versand nicht zu unterbrechen.
Die aggregierte Spitzenlast von ~1,48 Mio. Nachrichten/Stunde (~410/s) ist für KumoMTA (Rust/async) moderat — Rohleistung ist nicht der Engpass. Der schwierige Teil sind die ~3.909 Versand-IPs (IP-Pools, Reputations-Kontinuität, Warmup) sowie Spool und Queue. KumoMTA kann alle drei vermutlich auf weniger/kleinere Knoten konsolidieren; dimensioniert wird nach IP-Anzahl, Concurrency, Spool-Disk und Log-Aufbewahrung — nicht nach CPU. Der Live-Spool ist klein (GB-Bereich); /data ist überwiegend Accounting-/Bounce-Log-Historie.
Sonderfälle
- Server 09 (se2ifo / ifo-Institut) — im Scope: sendeffect-eigene Custom-Integration für den Kunden ifo-Institut (Newsletter/Presse). Datenbanken zusammen ~1,4 GB, aktiv. Webroot 2,9 GB, davon 2,6 GB verwerfbare Errorlogs — die eigentliche App ist klein. Kein sendlx_-Tenant, keine MTA. Als kleiner Custom-/Sondermigrations-Posten zu behandeln (mit dem ifo-Kunden abstimmen).
- Server 11 — außerhalb des Scope: eine einzelne, fremde Kundenwebsite (~5 MB). Keine sendeffect-Produktinfrastruktur.
- Server 01 — entfällt: bereits vor längerer Zeit außer Betrieb genommen.
Zielumgebung & Übersetzung Alt→Neu
Pilot-VM sendeffect-01 (Dogado / group.one OpenStack)
OpenStack Nova / KVM auf AMD EPYC-Rome (Zen 2), 4 vCPU, 8 GiB RAM (kein Swap), 100 GB Disk (vda, ext4, ~92 GB frei), Ubuntu 24.04 / MariaDB 11.8.8 / PHP 8.5. Achtung: innodb_buffer_pool_size steht auf dem Default von 128 MB (ungetunt). Diese VM ist ausdrücklich nur ein Pilot.
Übersetzung der Rechenleistung
- Das alte DB-Tier bietet ~76 physische Kerne / 152 Threads über fünf Boxen und ~1 TB RAM — ist aber meist im Leerlauf (typische Last 3–10/Box, nur 08 im Peak gesättigt).
- Neue EPYC-Rome-Kerne sind je Thread ~1,5–2× schneller als die alten Xeons → die aktive Last bildet sich auf deutlich weniger moderne vCPUs ab. vCPUs sind nicht der Engpass.
- Die IEM-Versandlast ist RAM- und IO-gebunden (Subscriber-Listen-Scans, Stats-Inserts), nicht CPU-gebunden ⇒ der Buffer-Pool (RAM) ist die primäre Stellschraube; auf das heiße Working-Set dimensionieren.
Warum dann massiv weniger RAM?
Das ist der wichtigste Punkt für die Buchung — und auf den ersten Blick wirkt er widersprüchlich, weil die alten Boxen zusammen ~1 TB RAM hatten. Entscheidend ist, wofür dieser Speicher diente: Jede der fünf alten DB-Boxen betrieb einen InnoDB-Buffer-Pool von 128 GiB — zusammen rund 640 GiB. Diese Pools waren pauschal groß konfiguriert und hielten die historischen Daten aller ~557 Tenants vor, von denen 73 % inaktiv sind und faktisch nie abgefragt werden.
In der neuen Umgebung muss der Buffer-Pool nur das heiße Working-Set der 153 aktiven Tenants cachen (aktiver Kern ~240 GB auf Platte, davon zu jedem Zeitpunkt nur ein Bruchteil wirklich „heiß") — nicht die gesamte historische Datenmenge. Damit genügen ~80–90 GB Buffer-Pool über zwei App+DB-VMs (je ~40–45 GB), eingebettet in 128 GB RAM.
Rund 7× weniger Buffer-Pool — getrieben durch (1) den Wegfall von 73 % der Tenants, (2) die Dimensionierung auf das heiße Working-Set statt auf die Gesamtdatenmenge und (3) den Wegfall der pauschal überdimensionierten Alt-Konfiguration. RAM bleibt damit der primäre Hebel, der absolute Bedarf ist aber dramatisch kleiner, als die alte TB-Zahl vermuten lässt.
Empfehlung: alle Statistik-Historie migrieren (Open-/Click-Daten sind wertvoll; ein zeilenweises Recency-Filtern auf 100M+-Zeilen-Tabellen ist aufwendiger als das schlichte Mitnehmen). Planungsbasis = „aktiv + alle Stats" ≈ ~914 GB logisch / ~550 GB auf Platte. Inaktive Tenants nicht vorab löschen — stattdessen großzügigen Puffer einplanen, um sie aufzunehmen. Die endgültige keep/drop-Entscheidung ist pro Tenant zu treffen und blockiert das Sizing nicht.
Empfehlung: OpenStack-Buchung
Architektur = mehrmandantenfähiges All-in-one-LAMP pro VM (Apache + PHP-FPM + MariaDB, eine DB pro Tenant). Übersetzung: alte Flotte ~140 Kerne / ~1,3 TB RAM über 10 Bare-Metal-Boxen → neu braucht deutlich weniger, weil 73 % der Tenants entfallen, EPYC-Kerne stärker sind, KumoMTA effizienter als PowerMTA arbeitet und Dump-and-Reload Fragmentierung beseitigt.
| Rolle | VMs | je VM | Zwischensumme |
|---|---|---|---|
| App+DB (All-in-one LAMP) | 2 | 8 vCPU / 64 GB / 750 GB SSD | 16 vCPU / 128 GB / 1,5 TB |
| KumoMTA (PMTA-Ersatz) | 2 | 8 vCPU / 16 GB / ~400 GB SSD · 10 GbE | 16 vCPU / 32 GB / ~800 GB |
| Monitoring (Prometheus/Grafana) | 1 | 2 vCPU / 8 GB / 250 GB | 2 vCPU / 8 GB / 250 GB |
| Compute gesamt | 5 | — | ~34 vCPU / ~168 GB / ~2,55 TB SSD |
| Backups (Objektspeicher, keine VM) | — | — | ~1 TB |
Begründung je Rolle
- App+DB (RAM ist der Regler): fasst ~550 GB aktiv + alle Stats plus ~40 GB Webroots plus Puffer; Buffer-Pool ~40–45 GB/VM (⚠ Pilot steht auf 128 MB Default — auf ~70 % des RAM tunen). ~75 Tenants/VM. Bei schlechter Cache-Hit-Rate RAM erhöhen / Knoten hinzufügen.
- KumoMTA (gegen Kumo-Hardwareguide validiert): 8 vCPU/16 GB liegt zwischen „moderat" und „seriöser Startpunkt" → ausreichend für ~410 msg/s. Dedizierter SSD/NVMe-Spool (~300 GB) auf separater Mount-Ebene von den Logs; IOPS > Kapazität; 10 GbE. 2 Knoten für HA, Patch/Reboot ohne Mail-Stillstand und IP-Pool-/Reputations-Segmentierung über ~3.909 IPs.
- Monitoring: schlank starten mit nur 2 vCores / 8 GB / 250 GB (Prometheus + Grafana + Alertmanager) — das spart initial 2 Kerne gegenüber einer 4-vCore-Auslegung. Erst auf 4/16/500 erhöhen, wenn Loki dazukommt (KumoMTA-/Apache-Logs sind volumenstark — der eigentliche Disk-/RAM-Treiber).
Phasenstart: je 1× App+DB, KumoMTA und Monitoring = 18 vCPU / 88 GB / ~1,4 TB (Monitoring lean mit 2 vCores → 2 Kerne weniger als bei 4-vCore-Auslegung). Die zweiten App+DB- und KumoMTA-Knoten kommen mit dem Migrationsfortschritt dazu (elastisch). Disk wächst live (Cinder-Volume erweitern, kein Downtime) — wachsende Daten (DB-Datadir, MTA-Spool, Monitoring) auf separate Cinder-Volumes legen. vCPU/RAM-Resize = Flavor-Resize mit kurzem Reboot; hinter dem 2-Knoten-HA-Paar einzeln durchführbar → keine nutzerseitige Downtime. Vor dem Rest die Buffer-Pool-Hit-Rate / IO an der ersten großen Tenant-Migration validieren (Prinzip „groß zuerst migrieren").
Resilienz & Hochverfügbarkeit
Ein Produktionsvorfall während der Analyse macht greifbar, warum die neue Architektur — eine DB pro Tenant, eigener PHP-FPM-Pool je Tenant — nicht nur sauberer, sondern deutlich ausfallsicherer ist, und welche Maßnahmen das absichern.
Ein korrupter InnoDB-Index auf sendlx_6.subscribers_data (Server 03, Percona 5.6) brachte die Datenbank in einen Crash-Loop. Der logische Restore des Hosters (mysqldump) lief zum Zeitpunkt der Prüfung bereits über 5 Stunden und war erst zu ~50–60 % fertig — die vollständige Wiederherstellung hätte also noch einmal etwa so lange gebraucht. Die ganze Zeit über hielt er eine Schreibsperre auf der 40-GB-Tabelle. Weil die Alt-Infrastruktur eine geteilte DB (sendlx_6 = viele Tenants) und einen geteilten PHP-FPM-Pool auf dem Web-Knoten 02 nutzte, legte diese eine korrupte Tabelle sämtliche Sites auf 02 lahm (sf12/14/15/16 — inkl. ganz anderer DBs). Zusätzlich zeigte sich, dass die alte Replikation still verstummt war (der Slave-SQL-Thread auf 03 war Stunden zuvor an einem Fehler gestorben) — also kein Failover.
Warum die neue Architektur das entschärft
- Eine DB pro Tenant: eine korrupte Tabelle betrifft nur die DB dieses einen Tenants — Tabellen und Sperren anderer Tenants bleiben unberührt.
- Eigener PHP-FPM-Pool je Tenant (eigener User/Socket): ein Tenant, der auf seine DB blockiert, kann die Worker anderer Tenants nicht aushungern. Das ist die eigentliche Behebung der Tenant-übergreifenden Kaskade vom 19.06.
- Kleinere, frische Tabellen (Dump-and-Reload, modernes Row-Format + full_crc32-Prüfsummen): schnelleres Erkennen, Reparieren und Wiederherstellen.
- Kleinerer Blast-Radius: von „alle Tenants des Web-Knotens, über mehrere DB-Server hinweg" → „höchstens die Tenants einer VM, meist nur der betroffene".
Tenants auf derselben VM teilen sich einen mariadbd-Prozess. Isolierte Tabellenkorruption sperrt zwar keine anderen Tenants — aber eine Korruption, die die Engine in einen Crash-Loop zwingt, nimmt alle DBs dieser VM bis zur Wiederherstellung mit. Gegenmaßnahmen: Replikation/HA (Instanz wegswitchen) und Tenants nicht zu dicht pro VM packen. Echte Pro-Tenant-mariadbd-Instanzen würden selbst Engine-Crashes isolieren — vermutlich Overkill.
Empfohlene Resilienz-Maßnahmen
- Funktionierende Replikation oder Galera — und überwachen. Die Alt-Infrastruktur hatte Replikation, die still ausfiel → kein Failover im Vorfall. Ein gesunder Replica/Cluster macht aus einer mehrstündigen Wiederherstellung ein Failover von Sekunden. Auf Replication-Lag/-Stopp alarmieren.
- Physische Backups (Mariabackup), nicht nur logische Dumps. Die lange Wiederherstellungsdauer entstand, weil ein logischer Restore jede Zeile neu einfügt und alle Indizes neu aufbaut. Ein Mariabackup-Restore entspricht eher einer Dateikopie und ist bei großen Datenmengen dramatisch schneller. Beides vorhalten (physisch = schneller Full-Restore; logische Pro-Tenant-Dumps = Granularität/Portabilität) + Binlogs für PITR.
- Frühe Erkennung / Alerting (Aufgabe der Monitoring-VM): MariaDB-Error-Log nach Loki schicken und auf InnoDB: … corrupt/Prüfsummenfehler alarmieren, damit es vor dem Crash-Loop auffällt. Periodisches mysqlcheck/CHECK TABLE (oder der nächtliche logische Dump, der jede Zeile liest) deckt Korruption proaktiv auf.
- Redundantes Volume-Backend bei Dogado bestätigen (Ceph/SAN mit Replikation). Echte InnoDB-Korruption ist meist Storage-/Hardware-bedingt, kein DB-Versions-Bug — modernes redundantes Storage ist der größte einzelne Risikoreduzierer, mehr noch als MariaDB 11.8 selbst (das aber hilft: gepflegt, ~10 Jahre InnoDB-Fixes ggü. EOL 5.6/5.7).
Risiken & nächste Schritte
Alle zehn Server laufen auf abgekündigten Betriebssystemen (Debian 8/9, Ubuntu 16.04/18.04). Spitzenrisiko: Server 05 mit ~8,3 Jahren Uptime ohne Kernel-Patch. Das ist ein eigenständiger, kapazitätsunabhängiger Grund, die Migration nicht zu verzögern.
Offene Entscheidungen
- Statistik-Aufbewahrung: komplette Historie vs. rollierendes Fenster — die größte verbleibende Stellschraube. Aktuelle Planungsempfehlung: alle Stats migrieren (siehe Abschnitt 08).
- Keep/Drop je Tenant: die endgültige Entscheidung erfordert Kontakt mit jedem Kunden auf jeder Instanz (zurückgestellt; blockiert das Sizing nicht, da inaktive Tenants über Puffer aufgefangen werden).
- Borderline-/inaktive Instanzen vor dem Verwerfen verifizieren: u. a. sf36, sf32/senddigital (07), sendlx_25/26 (03), sendlx_969 (12).
- se2ifo/ifo: Custom-Migration mit dem ifo-Kunden abstimmen.
Nächste Schritte
- Per-VM-Tenant-Packing-Plan finalisieren: 153 aktive Tenants (+ Puffer für inaktive) auf die neuen VMs verteilen, sobald die Ziel-VM-Spezifikation (Disk/RAM/Kerne) feststeht.
- CPU-/RAM-Hotplug auf der öffentlichen OpenStack-Plattform mit Dogado klären (Default oft deaktiviert → Resize via Reboot).
- Erste große Tenant-Migration als Validierungslauf (Cache-Hit-Rate, IO-Wait, CPU) vor Buchung der restlichen Knoten.
- Buffer-Pool der App+DB-VMs auf ~70 % des RAM tunen (Pilot steht auf 128 MB Default).