Server-Upgrade oder Skalierung? Wann du Hardware erweitern musst

Ein Server, der seinen Job macht, ist unsichtbar. Doch sobald Webseiten Timeouts werfen, Datenbank-Abfragen hängen oder der SSH-Login zur Geduldsprobe wird, schrillen bei dir als Admin die Alarmglocken. Die reflexartige Reaktion ist oft: „Wir brauchen mehr Blech!“ Doch ist Hardware-Skalierung immer die richtige Antwort? Oft liegen die Probleme tiefer – im Code, in der Datenbank-Konfiguration oder in der Architektur.

In diesem Artikel analysieren wir, wie du echte Engpässe (Bottlenecks) von bloßen Konfigurationsfehlern unterscheidest, wann Scale-Up (Vertikal) oder Scale-Out (Horizontal) die richtige Strategie ist und wie du deine Kapazitätsplanung proaktiv gestaltest.

Skalierung ist nicht gleich Skalierung

Bevor wir Hardware kaufen, müssen wir die Richtung bestimmen. „Skalierbarkeit“ bedeutet technisch gesehen, Ressourcen an Workloads anzupassen, ohne die Architektur ändern zu müssen. Man unterscheidet zwei fundamentale Strategien:

1. Vertikale Skalierung (Scale-Up)

Das Prinzip „Größerer Hammer“. Du nimmst den bestehenden Server und verpasst ihm mehr Ressourcen (CPU, RAM, NVMe).

• Ideal für: Monolithische Datenbanken (SQL), Legacy-Anwendungen, die nicht clusterfähig sind.
• Limit: Irgendwann ist der größte verfügbare Server am Markt erreicht (oder das Budget gesprengt).

2. Horizontale Skalierung (Scale-Out)

Das Prinzip „Mehr Arbeiter“. Statt eines großen Servers nutzt du viele kleine Instanzen, die sich die Last teilen (Cluster).

• Ideal für: Webserver, Stateless Applications, Microservices, Container (Kubernetes).
• Limit: Die Komplexität steigt (Load Balancer, Daten-Synchronisation, Netzwerklatenz).

Erste Warnsignale: Wie erkennt man Engpässe?

Bevor du das Budget für neue Hardware freigibst, musst du beweisen, dass die aktuelle Hardware tatsächlich das Problem ist. Ein subjektives „Der Server fühlt sich langsam an“ reicht hier nicht. Vielmehr musst du tief in die System-Metriken eintauchen, um echte Flaschenhälse (Bottlenecks) von bloßen Konfigurationsfehlern zu unterscheiden. Ein Blick auf htop ist ein guter Anfang, aber oft nicht detailliert genug.

Hier sind die vier Hauptverdächtigen und wie du sie analysierst:

1. CPU: Usage vs. Load Average

Viele Admins machen den Fehler, nur auf die CPU-Auslastung in Prozent zu schauen. Eine CPU bei 90 % ist nicht zwangsläufig ein Problem – sie wird vielleicht einfach nur effizient genutzt (z. B. beim Video-Encoding).

• Der wahre Indikator: Load Average. Die Load Average (zu sehen via uptime oder top) zeigt an, wie viele Prozesse gerade auf die CPU warten oder von ihr verarbeitet werden.
  • Faustregel: Eine Load von 1.0 bedeutet, dass ein CPU-Kern voll ausgelastet ist.
  • Das Warnsignal: Wenn die Load Average dauerhaft die Anzahl der verfügbaren CPU-Kerne überschreitet (z. B. Load 6.0 auf einer 4-Core-Maschine), stauen sich die Prozesse (CPU Wait). Das System wird träge, die Latenz steigt.
• Sonderfall Virtualisierung: Achte auf den Wert %steal (st). Ist dieser hoch, langweilt sich deine VM zwar vielleicht, aber der physische Host darunter ist überlastet und gibt dir keine Rechenzeit.

2. RAM: Caching vs. Swapping

Arbeitsspeicher ist oft die am meisten missverstandene Ressource. Unter Linux gilt der Grundsatz: „Freier RAM ist verschwendeter RAM“. Das Betriebssystem nutzt ungenutzten Speicher aggressiv als Page Cache für das Dateisystem, um Festplattenzugriffe zu minimieren.

• Der wahre Indikator: Swapping & Paging. Ignoriere den Wert „Free Memory“. Achte stattdessen auf „Available“. Kritisch wird es erst, wenn der Server anfängt zu swappen.
  • Das Warnsignal: Wenn Prozesse aktiv in den Swap-Bereich (auf die langsame Festplatte) ausgelagert werden müssen, bricht die Performance massiv ein. Du erkennst das an einer hohen Aktivität des Kernels (Prozess kswapd verbraucht viel CPU) und hohen Werten bei si (swap in) und so (swap out) im Tool vmstat.
  • Worst Case: Der OOM Killer (Out of Memory Killer) schlägt zu und beendet wahllos wichtige Prozesse (wie den Datenbank-Dienst), um das System vor dem Absturz zu retten.

3. Storage I/O: IOPS vs. Durchsatz

Oft wird die CPU beschuldigt, obwohl die Festplatte der eigentliche Übeltäter ist. Gerade Datenbanken erzeugen oft keine hohe Datenrate (MB/s), aber extrem viele kleine Lese-/Schreibzugriffe (IOPS).

• Der wahre Indikator: I/O Wait (%wa). Diesen Wert findest du in top oder iostat. Ein hoher iowait-Wert bedeutet: Die CPU dreht Däumchen und wartet darauf, dass die Festplatte Daten liefert.
  • Das Warnsignal: Wenn deine CPU-Last niedrig ist (User/System %), aber die „Wait“-Zeit hoch, ist dein Storage zu langsam.
  • Die Lösung: Hier hilft kein CPU-Upgrade. Du benötigst Disks mit geringerer Latenz (Wechsel von HDD/SATA-SSD auf NVMe) oder mehr IOPS. Prüfe mit iotop, welcher Prozess gerade die Platte „hämmert“.

4. Netzwerk: Bandbreite vs. Limits

Ein Netzwerk-Engpass muss nicht heißen, dass die 1 Gbit/s-Leitung voll ist. Oft sind es logische Grenzen oder Paketraten, die limitieren.

• Der wahre Indikator: Dropped Packets & Conntrack.
  • Sättigung: Prüfe mit iftop oder nload, ob du das physikalische Limit des Interfaces erreichst.
  • Paketrate (PPS): Ein DDoS-Angriff oder fehlerhafte Anwendungen können Millionen kleiner Pakete senden, die die CPU der Netzwerkkarte überfordern, obwohl die Bandbreite noch Luft hätte.
  • State Limits: Ein häufiger, stiller Tod für Webserver ist eine volle Conntrack Table in der Firewall. Wenn das System keine neuen Verbindungen mehr tracken kann (dmesg prüfen: „table full, dropping packet“), ist der Server von außen nicht mehr erreichbar, obwohl die Hardware entspannt wirkt.

Checkliste vor dem Kauf: Liegt es wirklich an der Hardware?

Nichts ist peinlicher (und teurer), als das Budget für einen doppelt so großen Server freizugeben, nur um festzustellen, dass die Applikation danach exakt genauso langsam ist wie vorher. In der Praxis sind schätzungsweise 70 % aller Performance-Probleme nicht auf fehlende Hardware, sondern auf ineffiziente Software oder Konfiguration zurückzuführen.

Bevor du skalierst, arbeite diese „Health-Check“-Liste gnadenlos ab:

[ ] 1. Der Datenbank-Check: Indizes & Slow Queries

Die Datenbank ist der häufigste Flaschenhals. Ein einziger schlechter SQL-Query kann selbst einen 64-Core-Server in die Knie zwingen.

• Indizes prüfen: Werden WHERE-, JOIN– und ORDER BY-Klauseln von Indizes abgedeckt? Ein Full Table Scan bei Millionen von Zeilen ist der Tod für jede I/O-Performance.
• Slow Query Log: Aktiviere das Logging für langsame Abfragen (z. B. > 1 Sekunde). Oft sind es Queries, die unnötig viele Daten laden (SELECT *) oder N+1 Probleme bei der Nutzung von ORMs (Object-Relational Mappers).
• Explain Plan: Nutze EXPLAIN vor deinem SQL-Statement, um zu sehen, ob die Datenbank den Index auch wirklich nutzt.

[ ] 2. Die Caching-Strategie: Berechne nichts doppelt

Der schnellste Request ist der, der den Webserver gar nicht erst erreicht. Caching ist fast immer billiger als CPU-Leistung.

• Applikations-Cache: Werden teure Datenbank-Ergebnisse (z. B. „Top 10 Produkte“) in Redis oder Memcached zwischengespeichert?
• OpCode-Cache: Ist bei PHP der Opcache aktiviert und groß genug, damit Skripte nicht bei jedem Aufruf neu kompiliert werden müssen?
• HTTP-Cache: Nutzt du Varnish oder Nginx-Caching für statische Assets oder ganze HTML-Seiten? Ein Reverse Proxy kann Tausende Requests pro Sekunde ausliefern, während dein Backend-Server bei 50 Requests kapituliert.

[ ] 3. Code-Profiling & APM: Der Blick unter die Haube

Manchmal ist der Code selbst das Problem.

• Memory Leaks: Steigt der RAM-Verbrauch eines Prozesses über Tage hinweg stetig an, bis er abstürzt? Dann hast du ein Speicherleck, das auch 1 TB RAM irgendwann füllen wird.
• Ineffiziente Schleifen: Werden Daten in verschachtelten Schleifen verarbeitet, was die CPU unnötig belastet (O(n²) Komplexität)?
• Blockierende I/O: Wartet dein Code synchron auf die Antwort einer externen API (z. B. Payment-Gateway), während der User wartet? Nutze asynchrone Jobs (Queues) für solche Aufgaben. Tools wie New Relic oder Datadog helfen hier beim „Application Performance Monitoring“ (APM).

[ ] 4. OS- & Server-Config: Die Handbremse lösen

Standard-Konfigurationen sind auf Sicherheit und Kompatibilität ausgelegt, nicht auf Hochlast.

• File Descriptors (Open Files): Unter Linux ist „alles eine Datei“ (auch Netzwerk-Sockets). Das Standard-Limit (oft 1024) ist für Webserver viel zu niedrig. Prüfe ulimit -n und erhöhe es bei Bedarf.
• Worker-Limits: Sind Apache (MaxRequestWorkers) oder PHP-FPM (pm.max_children) so konfiguriert, dass sie die verfügbare Hardware nutzen? Wenn der Pool zu klein ist, warten User, obwohl die CPU noch Luft hätte. Ist er zu groß, droht Swapping.
• KeepAlive: Ist die TCP-KeepAlive-Zeit korrekt eingestellt, um den Overhead beim Verbindungsaufbau zu reduzieren?

Fazit: Erst wenn du überall hier einen Haken setzen kannst und die Last immer noch zu hoch ist – dann (und nur dann) ist Hardware der nächste logische Schritt.

Entscheidung: Wann welcher Weg?

Die Wahl zwischen Scale-Up und Scale-Out ist selten eine Geschmacksfrage, sondern wird meist durch die Architektur der Anwendung diktiert. Hier sind zwei klassische Szenarien, die dir im Alltag begegnen werden:

Szenario A: Der Datenbank-Server (Stateful) keucht

Relationale Datenbanken (MySQL, PostgreSQL, MSSQL) sind von Natur aus „Stateful“. Sie lieben Konsistenz (ACID) und hassen Latenz zwischen Speicher und Rechenwerk. Wenn hier die Performance einbricht, ist Scale-Up (Vertikal) fast immer der erste, kosteneffizienteste und stabilste Schritt.

• Der RAM-Faktor: Datenbank-Performance steht und fällt mit dem Caching. Ziel ist es, den gesamten Index (und idealerweise die „Hot Data“) im RAM zu halten (z. B. im InnoDB Buffer Pool). Muss die DB für Index-Lookups auf die Platte zugreifen, steigt die Latenz um den Faktor 1.000.
  • Strategie: Maximiere den RAM und die CPU-Cores. Wechsle bei Storage-Engpässen von SATA-SSD auf NVMe, um die IOPS drastisch zu erhöhen.
• Die Scale-Out-Option (Read Replicas): Wenn ein einzelner „Monster-Server“ nicht mehr reicht, kannst du horizontal skalieren, aber es ist komplex.
  • Master-Slave: Du stellst dem Schreib-Server (Master) mehrere Lese-Server (Slaves/Replicas) zur Seite. Deine Applikation muss aber intelligent genug sein, Schreiboperationen an den Master und Leseoperationen an die Replicas zu senden.
  • Sharding: Das Aufteilen der Daten auf völlig getrennte Server ist die letzte Ausbaustufe („Königsklasse“), bringt aber massiven administrativen Overhead mit sich.

Szenario B: Der Webshop / Frontend (Stateless) ist langsam

Webserver (Nginx, Apache) oder Applikationsserver (PHP-FPM, Node.js, Python) verarbeiten Anfragen idealerweise „Stateless“. Das bedeutet: Sie speichern keinen Status lokal auf der Festplatte. Ob Request A auf Server 1 und Request B auf Server 2 landet, ist egal. Hier ist Scale-Out (Horizontal) Pflicht.

• Der Load Balancer als Dirigent: Du stellst einfach einen zweiten, dritten oder zehnten Server daneben. Ein Load Balancer (z. B. HAProxy, F5 oder Cloud-LBs) verteilt die eingehenden Anfragen.
  • Strategie: Halte die einzelnen Server („Nodes“) klein. Viele kleine Server sind oft ausfallsicherer als zwei riesige.
• Herausforderung Sessions: Achtung bei User-Sessions (Warenkörbe, Logins). Wenn diese lokal im RAM des Webservers liegen, verliert der User seinen Warenkorb, wenn der Load Balancer ihn auf den Nachbar-Server schickt.
  • Lösung: Nutze einen externen Session-Store (z. B. Redis oder Memcached) oder konfiguriere „Session Stickiness“ am Load Balancer.
• Vorteil High Availability (HA): Scale-Out liefert Redundanz „gratis“ mit. Fällt ein Server aus (Hardware-Defekt, Patching), nimmt der Load Balancer ihn aus der Rotation, und der Traffic fließt nahtlos auf die verbleibenden Knoten weiter.

Modernes Skalieren: Container, Cloud & Orchestrierung

In modernen Umgebungen schraubt niemand mehr Gehäuse auf, um RAM-Riegel nachzustecken. Infrastruktur wird heute als Code definiert (IaC), und Skalierung passiert dynamisch via API.

1. Auto-Scaling in der Cloud (VM-basiert)

Hyperscaler wie AWS (Auto Scaling Groups) oder Azure (Virtual Machine Scale Sets) haben das Konzept der Elastizität demokratisiert. Du definierst keine fixe Serveranzahl mehr, sondern ein Regelwerk:

• Die Regel: „Wenn die durchschnittliche CPU-Last aller Webserver länger als 5 Minuten über 70 % liegt, starte zwei neue Instanzen.“
• Scale-In (Wichtig für die Kosten): „Wenn die Last unter 30 % fällt, beende die überzähligen Instanzen.“
• Nutzen: Deine Infrastruktur „atmet“ mit dem Geschäftsgang. Du zahlst für die Lastspitze am Black Friday, aber nicht für die Stille am Sonntagmorgen.

2. Kubernetes (K8s) & Container-Orchestrierung

Kubernetes treibt die Skalierung auf die Spitze, indem es Anwendungen in Container (Pods) verpackt und diese auf einem Cluster aus Servern (Nodes) verteilt. K8s bietet gleich zwei Dimensionen der Skalierung:

• HPA (Horizontal Pod Autoscaler): Kubernetes prüft im Sekundentakt die Metriken deiner Applikation. Steigen die Requests an deinen Microservice, startet K8s sofort neue Pods – oft in Sekundenbruchteilen, da Container viel schneller starten als ganze VMs.
• Cluster Autoscaler: Was passiert, wenn alle Server im Cluster voll mit Containern sind? Der Cluster Autoscaler bestellt automatisch beim Cloud-Provider neue virtuelle Maschinen (Nodes), fügt sie dem Cluster hinzu und schafft so physischen Platz für weitere Container.

Dieser Grad an Automatisierung erfordert zwar initial mehr Konfigurationsaufwand (Stichwort: Komplexität), ist aber für moderne, hochverfügbare Anwendungen der Goldstandard.

Fazit: Agieren statt Reagieren

Server-Skalierbarkeit ist kein einmaliges Event, sondern ein fortlaufender Prozess. Wer erst aufrüstet, wenn der Server bereits steht, hat oft schon Geld und das Vertrauen der Nutzer verloren.

Behalte diese drei Grundregeln im Kopf:

• Monitore richtig: Kenne deine Baseline. Du musst wissen, was „normaler“ Traffic ist, um Anomalien sofort zu erkennen.
• Optimiere erst: Software vor Hardware. Ein fehlender Datenbank-Index oder ein Memory Leak lässt sich auf Dauer nicht mit noch mehr RAM erschlagen.
• Plane Puffer ein: Eine CPU sollte im Regelbetrieb nicht dauerhaft über 70 % laufen. Nur so hast du Reserven, um Spikes durch Marketing-Kampagnen oder Backups abzufedern.

Ob du dich für den einfachen Weg (Scale-Up) oder den flexiblen Weg (Scale-Out) entscheidest, hängt am Ende von deiner Architektur ab. Wichtig ist nur: Identifiziere deinen Flaschenhals präzise, bevor du ihn beseitigst. So bleibst du den steigenden Erwartungen deiner Nutzer immer einen Schritt voraus.

weitere Links

This post is also available in: Deutsch English