Ein Server für alles — die Rechnung geht nicht auf

Bevor ich in diesem Jahr an meinem Aufbau etwas ändere, wollte ich einmal ehrlich aufschreiben, was eigentlich läuft. Nicht aus Ordnungsliebe — sondern weil ich gemerkt habe, dass ich es selbst nicht mehr vollständig sagen konnte.

Die Bestandsaufnahme

Auf einer Maschine, gewachsen seit 2020:

Was daran sofort auffällt: Es gibt kein Verfahren. Jeder Dienst wurde so betrieben, wie es zum Zeitpunkt seiner Entstehung naheliegend war. Vier laufen über einen Prozessmanager, einer als Systemdienst, einer als Container. Für jeden gibt es einen anderen Weg, ihn neu zu starten, zu aktualisieren oder Protokolle zu lesen.

Die konkreten Probleme

Ressourcen sind nicht abgegrenzt. Alle Prozesse teilen sich denselben Arbeitsspeicher. Wenn ein Bau Speicher braucht, nimmt er ihn allen anderen weg. Genau das ist mir zweimal passiert.

Ein Update betrifft alles. Eine neue Node-Version bedeutet: alle Anwendungen gleichzeitig, oder eine Umgebung, in der mehrere Versionen nebeneinander liegen.

Ausfälle greifen ineinander. Ein voller Datenträger legt alles lahm.

Ich kann nichts gefahrlos ausprobieren. Es gibt keine Testumgebung. Was ich probieren will, probiere ich neben dem, was läuft.

Der Zugriff ist alles oder nichts. Wer auf die Maschine kommt, kommt an alles. Es gibt keine Abstufung.

Was ich mir angeschaut habe

Mehrere kleine Server. Sauber getrennt, jeder Dienst für sich. Nachteil: mehr Verwaltung, mehr Kosten, und die Datenbank liegt dann nicht mehr neben den Anwendungen, was bei einer Datei-basierten Datenbank ein echtes Problem ist.

Alles in Container auf derselben Maschine. Grenzen für Speicher und Rechenzeit, einheitliches Verfahren, saubere Abhängigkeiten. Nachteil: Aufwand für den Umbau, und die Frage, wie die Datei-Datenbank für mehrere Container erreichbar bleibt.

Ein Panel darüber. Eine Oberfläche, die Container verwaltet — Start, Stopp, Protokolle, Ressourcengrenzen, Dateizugriff, Sicherungen. Ich kenne solche Panels aus der Spielserver-Welt und fand die Idee immer schon interessant für andere Dienste.

Alles so lassen und nur aufräumen. Die ehrliche Option, die man immer mitprüfen sollte.

Was ich vorhabe

Die Entscheidung ist noch nicht endgültig, aber die Richtung steht: eine leistungsfähigere Maschine, alles in Container, ein Panel darüber.

Die Gründe, in der Reihenfolge ihrer Wichtigkeit:

Erstens: Grenzen. Jeder Dienst bekommt einen festen Rahmen für Speicher und Rechenzeit. Ein Bau kann dann nicht mehr alles andere mitreißen.

Zweitens: Ein Verfahren für alle. Ein Dienst wird gestartet, gestoppt, aktualisiert und gesichert — immer gleich, egal was darin läuft.

Drittens: Ausprobieren wird möglich. Eine zweite Instanz von etwas neben der ersten, mit eigener Datenbank, ohne Angst.

Viertens: Zugriff abstufen. Ich kann jemandem Zugang zu einem Dienst geben, ohne ihm die Maschine zu geben.

Die Rechnung, die ich aufgemacht habe

Bevor ich mich entschieden habe, habe ich die Kosten grob gegenübergestellt — nicht in Euro, sondern in Aufwand.

Alles lassen: null Umzugsaufwand. Dafür bleiben alle beschriebenen Probleme, und jedes neue System vergrößert sie.

Mehrere kleine Server: saubere Trennung, mehr laufende Kosten, mehr Verwaltung, und das Problem, dass Anwendungen und Datenbank nicht mehr auf derselben Maschine liegen.

Eine größere Maschine mit Containern: ein Umzug, danach ein einheitliches Verfahren. Grenzen pro Dienst. Testumgebungen möglich.

Die dritte Variante gewinnt für meinen Fall aus einem Grund, der auf den ersten Blick wie ein Nachteil aussieht: Alles bleibt auf einer Maschine. Das ist keine Hochverfügbarkeit — aber ich hatte auch vorher keine, und ich brauche sie für ein Nebenprojekt nicht.

Was ich gewinne, ist Abgrenzung innerhalb einer Maschine. Was ich bewusst nicht gewinne, ist Ausfallsicherheit über Maschinen hinweg. Diese Unterscheidung sauber zu benennen, hat die Entscheidung leicht gemacht.

Was ich vor dem Umzug aufgeschrieben habe

Ich habe mir angewöhnt, vor größeren Umbauten eine Seite mit vier Punkten zu schreiben. Für diesen Umzug lautete sie:

Was muss danach funktionieren? Eine Liste der Dienste mit der jeweiligen Prüfung — nicht „läuft", sondern was ich konkret aufrufe.

Was darf verloren gehen? Nichts. Also: welche Daten gibt es, wo liegen sie, wie werden sie mitgenommen.

Wie lange darf es dauern? Für die sichtbaren Dienste unter einer Stunde. Das bestimmt die Reihenfolge.

Wie komme ich zurück? Alter Server bleibt vier Wochen unangetastet, Namensauflösung ist der Umschalter.

Diese vier Fragen haben mich mehr gekostet als der halbe Umzug — und sie sind der Grund, warum er später ohne Überraschung lief.

Was ich vorher klären muss

• Wie kommen mehrere Container an dieselbe Datenbankdatei? Ein gemeinsames Verzeichnis funktioniert, aber die Sperrsemantik über Container hinweg will ich vorher verstanden haben.
• Wie sehen Sicherungen aus, wenn alles in Volumes liegt?
• Was ist der Rückweg? Wenn der neue Aufbau nicht funktioniert, muss ich innerhalb einer Stunde zurückkönnen. Das heißt: alter Server bleibt eine Weile stehen.
• Wie lange ist die Ausfallzeit? Die Antwort bestimmt, ob ich das an einem Werktagabend mache oder nachts.

Diese vier Fragen zu beantworten ist die Arbeit der nächsten Wochen. Der Umzug selbst wird vermutlich der kleinere Teil sein — das ist bei solchen Sachen fast immer so.