Speicherleistung richtig dimensionieren: So finden Sie die perfekte Balance aus Performance, Kosten und Zukunftssicherheit

Wenn Storage-Projekte scheitern, liegt es selten an „zu wenig Speicherplatz“. Häufiger ist es die falsch eingeschätzte Speicherleistung: Anwendungen reagieren träge, Datenbanken warten auf I/O, Virtual-Desktop-Umgebungen brechen zu Stoßzeiten ein oder Backups laufen länger als das Wartungsfenster. Gleichzeitig kostet Überdimensionierung bares Geld – nicht nur bei Hardware, sondern auch bei Strom, Kühlung, Rackspace und Betrieb.

In diesem Beitrag erfahren Sie, wie Sie Speicherleistung richtig dimensionieren, ohne sich in Herstellerangaben zu verlieren. Wir betrachten die entscheidenden Kennzahlen (IOPS, Latenz, Durchsatz), zeigen typische Workload-Profile, erklären Mess- und Prognosemethoden und geben eine klare Vorgehensweise an die Hand – angepasst an die Praxis in Deutschland und Österreich (z. B. Fokus auf Energieeffizienz, Datenschutz, klare SLAs und planbare Betriebskosten).

Warum „Performance pro Terabyte“ der entscheidende Blickwinkel ist

Kapazität ist leicht zu verstehen: 50 TB sind 50 TB. Leistung dagegen ist abhängig von vielen Variablen: Blockgröße, Read/Write-Mix, Queue Depth, Cache-Strategien, RAID/Erasure Coding, Netzwerk, Protokolle (iSCSI, FC, NVMe-oF), Virtualisierungsschicht und sogar dem Schreibverhalten des Dateisystems.

Wer die Speicherleistung dimensioniert, sollte deshalb nicht nur fragen: „Wie viel TB brauchen wir?“, sondern:

• Wie viele I/O-Operationen pro Sekunde müssen dauerhaft und in Peaks verarbeitet werden?
• Welche Latenz ist für die Anwendung akzeptabel (z. B. < 1 ms, < 5 ms, < 20 ms)?
• Welcher Durchsatz (MB/s oder GB/s) wird bei sequentiellen Workloads benötigt?
• Welche Zukunftsreserve (Wachstum, neue Anwendungen, Compliance-Auflagen) ist realistisch?

Grundlagen: Die drei Säulen der Speicherleistung

1) IOPS: Das Maß für „Transaktionsfähigkeit“

IOPS (Input/Output Operations per Second) beschreiben, wie viele Lese-/Schreiboperationen ein System pro Sekunde abwickeln kann. IOPS sind besonders wichtig für:

• OLTP-Datenbanken (z. B. SQL Server, PostgreSQL, Oracle)
• Virtualisierung (VMware vSphere, Hyper-V, Proxmox)
• VDI (z. B. Login VSI-Szenarien, Boot-Storms)
• Fileservices mit vielen kleinen Dateien (Engineering, Medienproduktion, Software-Repos)

Wichtig: IOPS ohne Kontext sind wenig aussagekräftig. Entscheidend ist die Blockgröße (z. B. 4K, 8K, 64K) und der Read/Write-Mix.

2) Latenz: Der wichtigste KPI für Nutzerzufriedenheit

Die Latenz ist oft der beste Indikator für „gefühlte Performance“. Schon bei ausreichenden IOPS kann eine zu hohe Latenz zu Zeitouts oder langen Antwortzeiten führen. Für viele produktive Systeme gilt:

• Datenbanken / VMs: möglichst im einstelligen Millisekundenbereich
• VDI: besonders empfindlich bei Login- und Boot-Phasen
• Backup/Archiv: Latenz weniger kritisch, Durchsatz wichtiger

Beachten Sie: Latenz ist nicht nur „Speicher“. Netzwerk, Host-HBA/NIC, Multipathing, CPU-Contention und Storage-Controller-Auslastung wirken direkt mit.

3) Durchsatz (MB/s oder GB/s): Der Schlüssel für sequentielle Workloads

Durchsatz ist entscheidend für große, zusammenhängende Datenströme, z. B.:

• Backup & Restore (insbesondere Full Backups)
• Video-/Medien-Workflows
• HPC/Analytics, Datenpipelines
• Replikation und Datenmigration

Hier ist häufig das Netzwerk (10/25/40/100 GbE oder Fibre Channel) der limitierende Faktor. Eine solide Dimensionierung berücksichtigt daher End-to-End: vom Application-Host bis zum Medium.

Workload-Profile verstehen: Typische Muster in der Praxis

Virtualisierung (Server-VMs)

Virtualisierte Umgebungen erzeugen gemischte Lasten: viele zufällige I/Os, unterschiedliche Blockgrößen und teils starke Peaks (Patchdays, Reboots, Batchprozesse). Entscheidend ist, die „Noisy Neighbor“-Effekte zu vermeiden und Reserven für Wachstum einzuplanen.

• Typisch: 60–80% Read, 20–40% Write (stark abhängig von Applikationen)
• Blockgrößen: häufig 4K–16K
• Risiko: Storage-Queueing → Latenz steigt → VM-Performance sinkt

Datenbanken (OLTP vs. OLAP)

OLTP-Workloads sind latenz- und IOPS-getrieben, OLAP/Reporting eher throughput-orientiert. In der Praxis laufen beide oft auf derselben Plattform – was die Anforderung an QoS oder Tiering erhöht.

• OLTP: viele kleine Writes, Log-Dateien, hohe Sensitivität gegenüber Latenz
• OLAP: große Scans, sequentielle Reads, hoher Durchsatz

VDI und „Boot Storms“

VDI ist berüchtigt für Lastspitzen: morgens beim Login, nach Wartungsfenstern oder bei großflächigen Updates. Wer die Speicherleistung richtig plant, berücksichtigt Peak-IOPS und Mechanismen wie Dedup/Kompression, Golden Images, Cache und ggf. Write-Buffering.

Backup, Archiv und Compliance-Storage

In Deutschland und Österreich spielen Aufbewahrungsfristen, Datenschutz (DSGVO), Revisionssicherheit und planbare Kosten eine große Rolle. Für Backups sind oft Durchsatz und Kapazität wichtiger als Latenz. Dennoch kann eine zu geringe Leistung die Backup-Fenster sprengen – und damit das Risiko erhöhen.

Methodik: In 7 Schritten zur passenden Dimensionierung

Schritt 1: Ziele und Service-Level festlegen

Definieren Sie messbare Ziele statt „schnell“ oder „performant“:

• Latenz-Ziel pro Workload (z. B. 95. Perzentil)
• IOPS dauerhaft und Peak
• Durchsatz (z. B. Restore-Zeitfenster)
• RPO/RTO (Recovery Point/Time Objective)
• Verfügbarkeit (z. B. 99,9% vs. 99,99%)

Gerade im DACH-Raum hilft eine klare SLA-Definition, intern Budget zu begründen und extern (Systemhaus, Hersteller) Angebote vergleichbar zu machen.

Schritt 2: Ist-Zustand messen (nicht raten)

Erfassen Sie reale Metriken über mindestens 1–2 Wochen (besser 4 Wochen), inklusive Monatsabschluss, Batchfenster, Patchdays. Typische Quellen:

• VMware vCenter (Datastore-Latenz, IOPS, Throughput)
• Windows PerfMon (Avg. Disk sec/Read, Queue Length)
• Linux (iostat, sar, blktrace, nvme-cli)
• Storage-Array-Analytics (Controller-Auslastung, Cache-Hit, Port-Auslastung)
• Backup-Software (Job-Durchsatz, Dedupe-Ratio, Restore-Zeiten)

Erheben Sie dabei immer: Blockgröße, Read/Write-Anteil und Peak-Zeiten. Ohne diese Parameter sind IOPS-Zahlen kaum verwertbar.

Schritt 3: Workloads klassifizieren und trennen (wenn nötig)

Eine der wirksamsten Maßnahmen ist organisatorische und technische Trennung:

• kritische DB-Volumes getrennt von Fileshares
• VDI getrennt von produktiven Server-VMs
• Backup-Ziele getrennt von Primärstorage

Alternativ: QoS/Performance-Limits und Prioritäten nutzen, falls die Plattform das unterstützt.

Schritt 4: Kapazität, Effizienz und Overheads realistisch rechnen

Zur Dimensionierung gehört immer auch der „unsichtbare“ Kapazitätsverbrauch:

• RAID/Erasure Coding Overhead
• Snapshots (Wachstum und Performance-Effekt)
• Replikation (lokal/remote)
• Spare-Kapazität für Rebuilds und Performance-Stabilität
• Dateisystem-/VMFS-Overhead

In vielen Projekten ist nicht die Rohkapazität knapp, sondern die nutzbare Kapazität bei garantierter Leistung. Planen Sie bewusst „Headroom“ ein – sowohl für Kapazität als auch für Performance.

Schritt 5: Performance-Modell erstellen (IOPS, Latenz, Durchsatz)

Erstellen Sie pro Workload ein vereinfachtes Modell:

• Baseline: Durchschnitts-IOPS / Durchsatz
• Peak: 95./99. Perzentil oder definierte Peak-Szenarien
• Blockgröße: z. B. 8K random
• Read/Write: z. B. 70/30
• Latenz-Ziel: z. B. < 2 ms bei Peak

Für eine erste Abschätzung kann man IOPS und Blockgröße in Durchsatz umrechnen:

Durchsatz (MB/s) ≈ IOPS × Blockgröße (KB) / 1024

Beispiel: 20.000 IOPS bei 8 KB → ca. 156 MB/s. Das wirkt „wenig“, zeigt aber, warum random I/O eher IOPS- als throughput-limitiert ist.

Schritt 6: Architektur auswählen (All-Flash, Hybrid, Object, NVMe)

Die Architektur beeinflusst sowohl Performance als auch Kosten massiv:

• All-Flash (SSD/NVMe): sehr niedrige Latenz, hohe IOPS, ideal für VMs/DB/VDI
• Hybrid: günstiger pro TB, aber riskanter bei random I/O und Peaks
• Object Storage (S3-kompatibel): skalierbar und kosteneffizient für Archive/Backups, nicht für latenzkritische Transaktionen
• NVMe-oF: hohe Performance, aber Netzwerk und Know-how müssen passen

Für viele Unternehmen in Deutschland/Österreich ist ein zweistufiges Modell sinnvoll: performanter Primärstorage (All-Flash) plus kosteneffizientes Sekundärziel (Object/Backup-Storage) – inklusive klarer Datenlebenszyklen.

Schritt 7: Zukunftssicherheit planen (Wachstum, Security, Betrieb)

Zukunftssicher heißt nicht „maximal kaufen“, sondern skalierbar und beherrschbar bleiben:

• Scale-up vs. Scale-out: Wie wächst Leistung im Verhältnis zur Kapazität?
• Upgrades ohne Downtime: Controller, Software, Medien
• Security by design: Verschlüsselung, MFA, Immutable Backups (WORM), Ransomware-Schutz
• Energieeffizienz: Leistungsaufnahme pro TB und pro IOPS, besonders relevant bei steigenden Energiekosten
• Monitoring: Trendanalysen statt Feuerwehreinsätze

Typische Fehler bei der Dimensionierung – und wie Sie sie vermeiden

Fehler 1: Hersteller-IOPS blind übernehmen

Marketingwerte basieren oft auf idealen Bedingungen: 100% Read, 4K, hohe Queue Depth, komprimierbare Daten, warmes Cache. In realen Umgebungen sind die Bedingungen anders. Verlangen Sie:

• Messwerte für Ihr Profil (Blockgröße, Mix, Latenz bei Last)
• Perzentile statt Durchschnittslatenzen
• Konfigurationstransparenz (RAID, Cache, Netz)

Fehler 2: Nur die Durchschnittslast planen

Durchschnittswerte verschleiern Peaks. Planen Sie für Peak-Phasen (z. B. 95./99. Perzentil) und definieren Sie, wie lange Peaks toleriert werden dürfen. Gerade VDI oder Batchverarbeitung sind peak-dominant.

Fehler 3: Netzwerk und Hosts nicht mitdimensionieren

Ein schnelles All-Flash-Array bringt wenig, wenn:

• nur 10 GbE mit hoher Auslastung vorhanden ist
• Multipathing falsch konfiguriert ist
• Host-Queue-Depth limitiert
• CPU/RAM knapp sind und I/O warten

Dimensionieren Sie End-to-End und testen Sie mit realistischen Pfaden.

Fehler 4: Datenreduktion (Dedupe/Kompression) als „garantiert“ annehmen

Datenreduktion hängt stark von Datenarten ab (VMs, Office-Daten vs. verschlüsselte/komprimierte Medien). Rechnen Sie konservativ und prüfen Sie, ob Datenreduktion Performance kostet oder im Gegenteil durch weniger Schreibvolumen hilft.

Kosten richtig bewerten: TCO statt nur Anschaffungspreis

Die perfekte Balance aus Performance und Kosten erreichen Sie, wenn Sie Total Cost of Ownership (TCO) betrachten:

• CAPEX: Hardware, Lizenzen, Implementierung
• OPEX: Wartung, Support, Strom, Kühlung, Betrieb
• Risiko-Kosten: Downtime, Produktivitätsverlust, SLA-Strafen
• Opportunitätskosten: verzögerte Projekte wegen Performance-Engpässen

In DACH-Organisationen sind außerdem häufig relevant:

• Planbare Wartungsverträge und deutschsprachiger Support
• Lieferfähigkeit und Ersatzteilstrategie
• Datenschutz & Standortanforderungen (z. B. Datenhaltung in DE/AT)
• Energiekennzahlen (kWh/Jahr, Abwärme) als Teil von ESG-Zielen

Praxisleitfaden: So erstellen Sie ein belastbares Sizing-Dokument

Inhalte, die in keinem Sizing fehlen sollten

• Use Cases (VMs, DB, Files, Backup, Analytics)
• Messdaten (Zeitraum, Tools, Perzentile)
• Leistungsziele (IOPS/Latenz/Throughput)
• Kapazitätsrechnung (roh/nutzbar inkl. Overheads)
• Wachstumsannahmen (12/24/36 Monate)
• RPO/RTO und Schutzkonzept (Snapshots, Replication, Backup)
• Architekturentscheidung (Protokolle, Netzwerk, Redundanz)
• Risiken & Annahmen (z. B. Datenreduktion nicht garantiert)

Checkliste: Fragen für Workshops mit Fachbereichen

• Welche Anwendungen sind geschäftskritisch und welche nur „wichtig“?
• Gibt es Stoßzeiten (Schichtwechsel, Monatsabschluss, Kampagnen)?
• Wie sehen Wachstumspläne aus (neue Standorte, mehr User, neue Tools)?
• Welche Restore-Zeiten werden erwartet (auch bei großen Datenmengen)?
• Welche Compliance-Anforderungen gelten (Aufbewahrung, Unveränderbarkeit, Audit)?

Dimensionierung nach Szenarien: Beispiele aus der Praxis

Szenario A: Mittelständisches Unternehmen (DE/AT) mit Virtualisierung und Fileservices

Ausgangslage: 150 VMs, steigende Latenzen am Montagmorgen, Fileshares wachsen, Backups laufen in die Arbeitszeit.

Vorgehen:

• Messung: Datastore-Latenz und IOPS über 4 Wochen
• Trennung: Backup-Ziel auf separates System/Object Storage
• Primär: All-Flash mit klaren Latenz-SLAs, QoS für „laute“ VMs
• Netz: Upgrade auf 25 GbE, Multipathing-Check

Ergebnis: Weniger Latenzspitzen, stabilere VM-Performance, Backups wieder im Fenster – ohne übermäßig Kapazität zu kaufen.

Szenario B: Datenbank-lastige Umgebung mit striktem RTO

Ausgangslage: OLTP-System, hohe Transaktionsrate, RTO < 1 Stunde, Audit-Anforderungen.

Vorgehen:

• IOPS/Latency-Targets auf 99. Perzentil definieren
• Log-Volumes separat behandeln (Write-lastig)
• Replikation und regelmäßige Restore-Tests einplanen
• Immutable Backups für Ransomware-Resilienz

Szenario C: Backup & Archiv mit Fokus auf Kosten und Compliance

Ausgangslage: Stark wachsende Datenmengen, lange Aufbewahrung, DSGVO, Kostenkontrolle.

Vorgehen:

• Durchsatz-Ziele für Backup und Restore definieren
• Objektbasierte Ablage mit Lifecycle Policies (Warm/Cold)
• WORM/Immutability aktivieren, getrennte Admin-Rollen
• Monitoring der Restore-Zeiten (nicht nur Backup-Erfolg)

Technische Stellhebel: So holen Sie mehr Leistung aus dem Budget

Tiering und Datenlebenszyklus

Nicht alle Daten brauchen Top-Performance. Mit Tiering (automatisch oder per Policy) können Sie „heiße“ Daten auf schnellen Medien halten und „kalte“ Daten kostengünstig ablegen. Wichtig ist ein transparenter Mechanismus, damit Performance nicht unvorhersehbar schwankt.

Caching richtig nutzen

Caches können Reads beschleunigen, bei Write-Back-Konzepten auch Writes. Entscheidend ist, ob Ihr Workload cache-freundlich ist (wiederholte Zugriffe) oder eher „streaming“ (Cache bringt wenig).

RAID/Erasure Coding und Write Penalty

Redundanz kostet Leistung – insbesondere bei Writes. Berücksichtigen Sie die Write Penalty je nach Schutzverfahren. Moderne All-Flash-Systeme reduzieren den Effekt, aber er verschwindet nicht. Planen Sie Write-lastige Workloads (Logs, VDI) konservativer.

Snapshots und Klone

Snapshots sind großartig für schnelle Rollbacks, aber sie können Performance beeinflussen (z. B. bei langen Snapshot-Ketten). Regeln Sie:

• maximale Snapshot-Dauer
• Aufbewahrungsrichtlinien
• Snapshot-Sprawl vermeiden

Validierung: Testen, bevor Sie kaufen oder migrieren

Eine belastbare Dimensionierung kombiniert Messdaten und Tests:

• Proof of Concept mit repräsentativen Daten und Last
• Load-Tests (synthetisch + realistisch)
• Failover-Tests (Controller/Link-Ausfall) → Performance unter Störung
• Restore-Tests (entscheidend für RTO)

Beste Praxis: Nicht nur „Max-IOPS“ testen, sondern Latenz bei definierter Last und typische Peak-Szenarien.

Monitoring & kontinuierliche Optimierung

Dimensionierung ist kein einmaliges Projekt. Anwendungen ändern sich, Daten wachsen, Updates verändern I/O-Profile. Etablieren Sie:

• Trendanalysen (Kapazität und Performance)
• Alarmierung auf Latenz-Perzentile statt nur „Array down“
• Regelmäßige Review-Termine mit Fachbereichen
• Dokumentierte Änderungen (z. B. neue VMs, neue Datenbanken)

Fazit: Balance entsteht durch Messung, Profiling und klare Ziele

Wer Speicherleistung richtig dimensionieren will, braucht einen strukturierten Prozess: Service-Level definieren, Ist-Daten messen, Workloads profilieren, Overheads einrechnen und Architekturentscheidungen End-to-End treffen. So vermeiden Sie sowohl teure Überdimensionierung als auch riskante Engpässe – und erhalten eine Lösung, die in Deutschland und Österreich nicht nur performant, sondern auch kosteneffizient, energie- und betriebseffizient sowie zukunftssicher ist.

Kurz-Check für Ihr nächstes Projekt:

• Haben Sie Peaks (95./99. Perzentil) gemessen?
• Sind Latenz-Ziele je Workload definiert?
• Ist das Netzwerk mitdimensioniert?
• Haben Sie Overheads (RAID, Snapshots, Replizierung) realistisch kalkuliert?
• Gibt es einen Plan für Wachstum und Security (Immutable Backups, Rollen, Monitoring)?