Wahl der Hardware für einen Docker-Server

Erwartest du denn, dass deine RAM-Auslastung weiter steigt? Bspw. dadurch, dass mehr Nutzer auf dem System unterwegs sein werden? Wenn es um Kosteneffizienz geht und du da nicht viel erwartest, könnte es auch eine Option sein, SWAP zu konfigurieren und mit der hohen Auslastung (oder anders gesagt "effizienten Nutzung") zu leben. Ich habe so mal über Jahre einen Monitoring-Stack betrieben, der auf dem Papier deutlich mehr Ressourcen wollte, dann im Betrieb aber trotz Nutzung des SWAP einwandfrei funktioniert hat.

Ansonsten zur Server-Auswahl: Hast du bewusst die ARM-Server nicht mit aufgenommen? Mein größter Docker-Host ist ein VPS 1000 ARM G11 BSS24 (6 vCores, 8 GB RAM, 512 GB SSD) und bin mit der Leistung sehr zufrieden. Nahezu alle Maintainer von Docker-Images bauen auch für ARM64 und für die Randerscheinungen kann man QEMU sehr einfach konfigurieren und nutzen.

Wie ist denn dein derzeitiges Docker-Setup? Hintergrund der Frage: Ich habe jetzt schon öfter Server gewechselt und nach meiner Erfahrung ist der Umzug ein Kinderspiel und schnell gemacht - zumindest in meinem Setup. Ich würde mich daher gegen die teurere Option entscheiden, wenn "zukunftssicher" das einzige Argument ist.

Meine Rahmenbedigungen zum Vergleich:

• Downtimes von wenigen Stunden sind kein Problem
• Im Host-System ist nur Monitoring und Docker installiert, alles andere läuft in Docker-Containern
• Pro Anwendung gibt es ein Compose-File
• Persistente Daten werden ausschließlich per Bind-Mount im Host-System abgelegt

Ein Umzug von Server A nach Server B benötigt demnach

• Shutdown der Services auf A
• Anpassung der DNS-Einträge (das verursacht den größten Teil der Downtime)
• Kopieren der Anwendungsdaten mit rsync von A nach B
• Starten der Services auf B

Zitat von Bud

bei meinem Docker-Server habe ich leider auf das falsche Pferd gesetzt: Mein aktueller VPS 500 G11s stößt beim Arbeitsspeicher bereits an seine Grenzen. Da sich die CPU, wie im beigefügten Screenshot zu sehen, ohnehin langweilt, bin ich nun auf der Suche nach einer passenden Alternative.

Schau dir auch mal die Legende zum Grafen mit dem Arbeitsspeicher genauer an. Denn nicht immer wird auf dem Grafen angezeigt, dass der RAM auch tatsächlich mit Daten gefüllt ist.

Sofern auch SWAP auf dem Server eingerichtet ist, was auch zu empfehlen ist, solltest du dir in diesem Zusammenhang auch mal den Grafen des SWAP´s genauer anschauen.

SWAP wird meistens für Anwendungen zum Auslagern von deren Inhalten genutzt, wenn dessen Daten über einen längeren Zeitraum nicht genutzt werden, aber sehr kurzfristig wieder in den RAM geladen, sobald deren Daten wieder benötigt werden.

Vielleicht lohn sich ja auch ein Umstieg auf Podman.

Wenn du auf die Docker spezifischen Features nicht angewiesen bist, kannst du mir ja mal ein paar Container/Images nennen, vielleicht habe ich die selber am laufen.

Ich könnte dir dann ein paar Werte durchgeben.

Für mich als Blinden in Sachen Docker sieht das so aus:

• RAM stößt eventuell anseine Grenzen
• CPU reicht lockerst
• Netzwerk- und File-IO reicht locker

Es geht also - zumindest derzeit - "nur" um RAM.

Ich kann da andreas.nur zustimmen. Schau dir genauer an, womit das RAM belegt ist. Wenn da das halbe Filesystem drin liegt, dann ist das harmlos, das ist notfalls sehr schnell wieder freigegeben. Wie heißt es bei Munin auch so schön zu Erklärung von "unused" RAM: "Wasted memory. Memory that is not used for anything at all."

SWAP würde ich auch empfehlen, als erste Maßnahme. Und dann mal schauen, wie sich die RAM-Auslastung verändert, insbesondere auch, was da ausgelagert wird. Da deine CPUs sowieso rumidlen, wäre vielleicht auch ZRAM eine Idee, kann auch in Verbindung mit SWAP benutzt werden. Die Idee ist einfach, mehr Daten im RAM zu halten, wenn auch im komprimierter Form, was natürlich etwas Performance kosten und die CPU belasten wird. Da deine vCores aber eh wenig zu tun haben bleibt eigentlich nur der Performance-Verlust beim Lesen und Schreiben des RAM.

Falls doch ein Upgrade des Servers notwendig ist, würde ich die preisgünstigste Alternative mit der gewünschten RAM-Größe nehmen. Zumal ein weiterer Umzug irgendwann später wohl nicht so fuchtbar aufwändig ist, und manches doch gelegentlich mal von netcup durch neuere Hardware ersetzt wird, auch wenn das derzeit unpopulär zu sein scheint.

Aus reiner Neugier, weil ich gerade an meinem VPS 500 G11s rumüberlege, was läuft denn derzeit alles darauf? Ich habe da jetzt gerade mal ISPMail ausprobiert, hat prima funktioniert. Aber das wird sicher nicht der dauerhafte Zweck des Servers sein, ich wollte es nur mal ausprobieren. Schliesslich habe ich dafür derzeit den VPS 1000 ARM G11 im Einsatz. Da würde ich im Zweifel dann eher den ARM auf ISPMail und eventuell ISPMail Admin umbauen, oder ihn einfach weiter so verwenden wie er ist (Keyhelp).

Was betreibst du denn mithilfe von Docker? Docker alloziert zusätzlichen Overhead und da es in Go geschrieben wurde, benötigt ist ohnehin etwas mehr RAM, bis dann mal deren GC einsetzt (Grund warum ich Go meide) - Vielleicht lässt es sich auch ohne Docker betreiben, um für etwas mehr Puffer zu sorgen, sollte die Leistung dadurch beeinträchtigt werden (Nicht die Welt aber ohne Docker könnten dadurch vielleicht ~200 MB frei werden, je nach was genau du machst und wie viele Container zu betreibst)

Vielleicht wird von dem was du betreibst RAM alloziert, um diesen sicher und direkt zur Verfügung zu haben? Vielleicht wird gar nicht das verwendet, was du da als Verbrauch siehst? (Mögliche Einstellungssache?)

Ich glaube, es fehlt hier an Details zu deinem Nutzen ...

// EDIT
Bei der geringen Auslastung, würde ich mir mal ggfs. zRAM anschauen und den Speicher möglichst komprimieren, dadurch lässt sich einiges mehr an Daten zwischenspeichern und die CPU kann auch mal genutzt werden

Bud Man kann auch Container mit Ressourcenbegrenzungen versehen und damit besser steuern was wie viel verwenden darf:

    deploy:
     resources:
       limits:
         cpus: "1.0"
         memory: 1G

im Docker Compose File limitiert auf 1 CPU Kern und 1GB Ram (es gehen auch "1.5" CPU Kerne).

Zitat von TBT

Bud Man kann auch Container mit Ressourcenbegrenzungen versehen und damit besser steuern was wie viel verwenden darf:

    deploy:
     resources:
       limits:
         cpus: "1.0"
         memory: 1G

im Docker Compose File limitiert auf 1 CPU Kern und 1GB Ram (es gehen auch "1.5" CPU Kerne).

Da muss man teilweise doppelt überlegen ob das eine gute Idee für die jeweilige Anwedung ist. Nicht jedes Image schert sich um Limits über cgroup. Im schlechtesten Fall schießt es dir den Container einfach ab anstelle in einem Limit zu verbleiben.
Sofern die Anwendung sowas unterstützt ist es eigentlich immer besser solche Limits direkt der Anwendung mitzuteilen (Startparameter, Konfiguration,...)

Da hast Du sicher Recht, aber besser ist es Limits für einen Container vorzugeben und dann stürzt notfalls der Container wegen zu wenig RAM ab als dass der ganze Server aufgrund zu wenig RAM in Mitleidenschaft gezogen wird.