Server richtig dimensionieren: Kapazitätsplanung statt Bauchgefühl

Die Frage nach der passenden Servergröße taucht in jedem Projekt auf, meist früher als die belastbaren Daten dazu. Entschieden wird dann nach Erfahrung, nach dem, was beim letzten Mal funktioniert hat, oder nach dem Angebot, das gerade auf dem Tisch liegt. Das Ergebnis ist in beide Richtungen teuer: zu klein bedeutet Störungen im Lastfall, zu groß bedeutet laufende Kosten für Ressourcen, die nie gebraucht werden. Dieser Beitrag beschreibt, wie Sie Kapazität anhand von Messwerten statt Annahmen festlegen.

Warum Sizing so oft daneben liegt

Der häufigste Fehler ist die Fixierung auf eine einzige Kennzahl. Ein Server wird nach CPU-Kernen ausgewählt, obwohl die Anwendung an der Speicherbandbreite oder an der Latenz des Storage hängt. Umgekehrt wird viel RAM gekauft, weil Arbeitsspeicher gut messbar ist, während die Datenbank an zu wenigen IOPS erstickt.

Der zweite Fehler ist die Verwechslung von Durchschnitt und Spitze. Eine durchschnittliche CPU-Auslastung von 20 Prozent sagt nichts darüber aus, was beim Monatsabschluss, beim Import großer Datenmengen oder beim nächtlichen Backup passiert. Kapazität wird nicht für den Mittelwert geplant, sondern für die Lastspitzen, die geschäftlich relevant sind.

Der dritte Fehler liegt im Zeithorizont. Wer nur den heutigen Bedarf abbildet, plant eine Migration gleich mit ein. Wer fünf Jahre Wachstum vorab bezahlt, finanziert Leerlauf.

Die vier Größen, die wirklich zählen

CPU

Entscheidend ist nicht die Anzahl der Kerne, sondern ob die Last parallelisierbar ist. Ein PHP-Webserver mit vielen gleichzeitigen Requests profitiert von zusätzlichen Kernen. Ein einzelner langlaufender Importjob profitiert von höherer Taktfrequenz und schnellerem Single-Thread-Durchsatz. Achten Sie außerdem auf die Load-Average-Werte im Verhältnis zur Kernzahl und auf die Zeit, die Prozesse im Status iowait verbringen. Hoher iowait bei niedriger CPU-Auslastung ist ein Storage-Problem, kein CPU-Problem.

Arbeitsspeicher

RAM ist die Ressource, deren Mangel am schnellsten eskaliert. Solange genug frei ist, läuft alles; wenn der Puffer kippt, greift der OOM-Killer oder das System beginnt zu swappen, und die Antwortzeiten brechen ein. Planen Sie RAM nicht nach dem belegten Speicher, sondern nach belegtem Speicher plus Page Cache, der tatsächlich gebraucht wird. Datenbanken sind hier der kritische Fall: Passt der aktive Datenbestand in den Cache, sind die Zugriffszeiten gut. Passt er knapp nicht mehr hinein, verschiebt sich die Last schlagartig auf das Storage.

Storage und IOPS

Kapazität in Gigabyte ist der einfache Teil. Interessant sind Durchsatz, IOPS und vor allem die Latenz. Viele Anwendungen fühlen sich langsam an, obwohl weder CPU noch RAM ausgelastet sind, weil jeder Datenbankzugriff auf das Storage wartet. Prüfen Sie außerdem das Verhältnis von Lese- zu Schreiboperationen und ob die Zugriffe zufällig oder sequenziell erfolgen. Für datenbanklastige Systeme ist die Storage-Latenz meist die Größe, die über die gefühlte Performance entscheidet, nicht die Anzahl der CPU-Kerne.

Netzwerk

Bandbreite wird selten zum Engpass, Latenz schon. Wenn Anwendung und Datenbank auf getrennten Systemen laufen und jeder Seitenaufruf Dutzende Queries absetzt, summieren sich kleine Verzögerungen. Relevant sind außerdem Backup-Fenster: Ein tägliches Vollbackup über eine knapp bemessene Anbindung kann den regulären Betrieb spürbar stören.

Messen statt schätzen

Jede Kapazitätsplanung beginnt mit einer Baseline. Ohne historische Daten über mindestens einen vollständigen Geschäftszyklus bleibt jede Zahl geraten. Sammeln Sie über Wochen hinweg, idealerweise über einen Monatsabschluss oder eine Saisonspitze hinweg, mindestens folgende Werte:

• CPU-Auslastung und iowait, als Spitzenwert und als Perzentil, nicht nur als Mittelwert
• belegter Arbeitsspeicher, Page Cache und Swap-Nutzung
• IOPS, Durchsatz und Latenz je Datenträger
• Antwortzeiten der Anwendung aus Sicht des Nutzers
• Anzahl gleichzeitiger Sessions oder Verbindungen

Der letzte Punkt ist der wichtigste und wird am häufigsten vergessen. Technische Auslastung allein sagt wenig. Erst der Bezug zur Geschäftsgröße macht Planung möglich: Wie viel CPU-Zeit kostet eine Bestellung, ein Nutzer, ein Dokument? Wenn Sie diesen Zusammenhang kennen, können Sie Wachstum rechnen statt schätzen.

Reserve sinnvoll bemessen

Ein System, das im Normalbetrieb bereits am Limit läuft, hat keine Reserve für Updates, Backups, Reindizierungen oder einen fehlerhaften Deployment-Stand. Als Orientierung sollte im Tagesbetrieb bei Spitzenlast noch spürbar Luft bleiben, bei CPU und RAM gleichermaßen.

Diese Reserve ist kein Puffer gegen Wachstum, sondern gegen Unregelmäßigkeiten. Wachstum planen Sie zusätzlich und zeitlich begrenzt: lieber für die nächsten zwölf bis achtzehn Monate dimensionieren und dann bewusst nachsteuern, als Kapazität für Jahre vorab zu bezahlen.

Vertikal oder horizontal wachsen

Vertikales Wachstum bedeutet mehr Ressourcen für dieselbe Maschine. Das ist einfach, oft mit kurzem Neustart machbar und für die meisten Anwendungen der richtige erste Schritt. Die Grenze ist technisch und wirtschaftlich: Ab einer gewissen Größe steigen die Kosten überproportional, und ein einzelnes System bleibt ein einzelner Ausfallpunkt.

Horizontales Wachstum bedeutet mehr Instanzen. Das setzt voraus, dass die Anwendung zustandslos arbeitet oder Sitzungen zentral ablegt, und es bringt Lastverteilung, Deployment und Datenhaltung als zusätzliche Themen mit. Eine Datenbank horizontal zu skalieren ist deutlich aufwendiger als einen Webserver zu vervielfachen.

Die nüchterne Empfehlung lautet daher: vertikal skalieren, solange es trägt, und die horizontale Variante dort vorbereiten, wo sie absehbar gebraucht wird. Eine Architektur, die beides offenhält, ist mehr wert als eine, die früh auf Verteilung setzt, ohne sie zu brauchen.

Überprovisionierung ist kein sicherer Weg

Großzügig dimensionieren wirkt wie die risikofreie Entscheidung, hat aber zwei Nebenwirkungen. Erstens laufen die Kosten dauerhaft mit, auch in Monaten ohne Last. Zweitens verdeckt reichlich Hardware Probleme, die eigentlich in der Anwendung liegen. Eine fehlende Datenbankindizierung oder ein Query, der bei jedem Seitenaufruf die halbe Tabelle liest, fällt auf einem überdimensionierten Server lange nicht auf und wird mit der Datenmenge irgendwann doch zum Problem. Optimierung vor Vergrößerung ist deshalb in vielen Fällen die wirtschaftlichere Reihenfolge.

Ein praktikables Vorgehen

1. Metriken erheben und über einen vollständigen Geschäftszyklus beobachten.
2. Den Engpass benennen, bevor etwas bestellt wird. Genau eine Ressource ist in der Regel limitierend.
3. Prüfen, ob der Engpass durch Konfiguration oder Code zu beheben ist.
4. Kapazität für Spitzenlast plus Betriebsreserve festlegen, nicht für den Durchschnitt.
5. Einen Zeitpunkt definieren, zu dem das Sizing erneut überprüft wird.
6. Schwellwerte im Monitoring so setzen, dass Wachstum auffällt, bevor es zur Störung wird.

Kapazitätsplanung ist damit keine einmalige Entscheidung beim Bestellen, sondern ein wiederkehrender Abgleich zwischen Messwerten und Bedarf. Wer diesen Abgleich regelmäßig macht, erkennt Engpässe Wochen vor dem Ausfall und kann in Ruhe handeln, statt unter Druck zu skalieren.