Prüfung und Neuerstellung eines fehlertoleranten Nginx+PHP-FPM+PostgreSQL-Stacks auf 2 VPS mit strengen SLOs

Ausgangssituation: Es gibt 2 VPS in Hetzner (Ubuntu 22.04) für B2B SaaS (Spitzenlast bis zu 800 gleichzeitige Benutzer, ~120 req/s). Jetzt läuft alles auf einem Server: Nginx, PHP-FPM, PostgreSQL 14, Redis, Cron, Mailversand. In Spitzenzeiten treten 502/504 auf, die Festplatte wird regelmäßig verstopft, Backups werden unregelmäßig durchgeführt, Updates werden manuell installiert. Der zweite VPS ist leer, wir wollen ihn für Fehlertoleranz und sichere Backups verwenden.

Technische Umgebung und Einschränkungen:
- Zugriff: SSH-Root zu beiden Servern, Domäne und DNS von Cloudflare
- Sie können den Anwendungscode und das Datenbankschema nicht ändern, nur Änderungen an der Betriebssystemkonfiguration und den Diensten sind zulässig
- Zulässiges Degradations-/Umschaltfenster in der Nacht – bis zu 10 Minuten, vollständige Nichtverfügbarkeit – nicht mehr als 2 Minuten
- Sie können keine zusätzlichen verwalteten Dienste kaufen, sondern nur die Funktionen von zwei VPS und Cloudflare
- Es ist notwendig, die Möglichkeit zu lassen, das System ohne Docker/Kubernetes zu warten (es ist erlaubt, Systemd- und Standardpakete zu verwenden)

Was muss in Etappen erledigt werden:
1) Diagnose von Leistungs- und Zuverlässigkeitsproblemen auf dem aktuellen Server – Analyse von Nginx/PHP-FPM/PostgreSQL-Protokollen, Lastengpässen, Festplattensubsystem, Systemd-Grenzwerten, Netzwerk, Zeitüberschreitungen, Keepalive-Einstellungen, Puffern, langsamen Abfragen
2) Neuzuweisung der Rollen auf 2 VPS:
- VPS-1 - Frontend: Nginx, PHP-FPM, Redis (bei lokalem Bedarf), cron
- VPS-2 – Datenbank und Backups: PostgreSQL + Replikation/Reservierung, Speicherung von Backups, minimale Dienste
3) Einrichten von PostgreSQL mit Schwerpunkt auf Stabilität – korrekte Speicherparameter/Autovacuum, WAL-Archivierung, Wachstumskontrolle, grundlegende Härtung, Latenzüberwachung
4) Backup- und Wiederherstellungstests – tägliches Basis-Backup + WAL (oder ein anderer sinnvoller Ansatz), Rotation, Verschlüsselung, Testwiederherstellung in einer separaten Datenbank/einem separaten Verzeichnis, Dokumentation des Wiederherstellungsvorgangs
5) Sicherheit und Betrieb:
- Firewall (ufw/nftables) mit den minimal erforderlichen Ports, die den Zugriff auf PostgreSQL einschränkt
- SSH-Härtung (Schlüssel, Sperrkennwörter, fail2ban oder ähnliches)
- Automatische Sicherheitsupdates (unbeaufsichtigte Upgrades) mit kontrolliertem Neustart
6) Beobachtbarkeit:
- Metriken und Warnungen: CPU-/RAM-/Festplattenlast, E/A-Wartezeit, Festplattenfülle, 5xx-Anzahl, Antwortzeit, Replikation/Verzögerung, Sicherungsjobs
- Prometheus node_exporter + einfache Alarmierung (zum Beispiel über Alertmanager/Telegram) oder ein anderer Stack ist erlaubt, jedoch ohne schwere Plattformen
7) Failover-Plan – Schritt-für-Schritt-Anleitung, wie Sie eine Anwendung innerhalb von Zeitlimits auf einen Backup-Server/eine Standby-Datenbank umstellen

Spezifisches Ergebnis:
- Zwei Server mit getrennten Rollen, einem dokumentierten Schema, konfigurierten Backups und bewährter Wiederherstellung
- Nginx/PHP-FPM/PostgreSQL-Konfigurationen und Systemd-Einheiten werden in einen Zustand gebracht, in dem sie reproduziert werden können (idealerweise über Ansible, aber nette Skripte + README sind auch akzeptabel)
- Eine separate Datei mit einer Karte der Ports/Zugänge und einer Liste der vorgenommenen Änderungen

Messbare Akzeptanzkriterien:
- Auf der Nginx-Seite beträgt der Anteil 5xx in 24 Stunden unter typischer Last – nicht mehr als 0,1 %
- P95-Antwortzeit basierend auf Nginx-Zugriffsprotokollen – nicht schlechter als der aktuelle Wert und eine Zielverbesserung von mindestens 20 % nach der Optimierung (wir legen die Basislinie zu Beginn der Arbeit fest)
- Die Backup-Kette läuft täglich, es werden mindestens 7 Wiederherstellungspunkte gespeichert und mindestens 1 Test-Restore mit Bericht wird abgeschlossen
- Im Falle einer künstlichen Nichtverfügbarkeit von VPS-1 oder VPS-2 gibt es einen Schaltvorgang, der innerhalb der Einschränkungen liegt (bis zu 2 Minuten völlige Nichtverfügbarkeit, bis zu 10 Minuten Abbau in der Nacht).
- Alle Dienste werden nach dem Neustart der Server automatisch wiederhergestellt, ohne dass manuelle Eingriffe erforderlich sind

Wichtig: Die Arbeit umfasst die Analyse und Verantwortung für Änderungen in der Produktion. Bevor Sie riskante Änderungen vornehmen, vereinbaren Sie einen Aktionsplan und ein Rollback.