RAID-Best Practices für VMware: VMware RAID-Best Practices und Speicherdesign

Die richtige RAID-Konfiguration ist für VMware ESXi echt wichtig. RAID beeinflusst, wie schnell deine virtuellen Maschinen laufen, wie sicher deine Daten sind und wie einfach du nach Festplattenausfällen wieder alles zum Laufen bringst. Nicht alle RAID-Level sind gleich: Manche setzen auf Geschwindigkeit, andere auf Redundanz und wieder andere versuchen, beides unter einen Hut zu bringen.

In diesem Artikel wird erklärt, welche RAID-Optionen für VMware am besten geeignet sind, welche Kompromisse zu erwarten sind und wie Sie die RAID-Level an Ihre Arbeitslast anpassen können.

Zusammenfassung: Wie sich RAID auf die Stabilität und Leistung von VMware auswirkt

1. 1. Die Leistung von VMware hängt von vorhersehbarer Latenz ab, nicht von Spitzen-Durchsatz. ESXi-Workloads brauchen konstante Reaktionszeiten; Spitzen oder Verzögerungen machen Cluster schneller instabil, als die reine Bandbreite das ausgleichen kann.
2. 2. Die Wahl des RAID-Levels wirkt sich direkt auf das Verhalten der VM aus.

• Schlechte RAID-Levels lösen bei hoher I/O-Auslastung VM-Stun-Ereignisse aus.
• Sie verlangsamen Snapshot-Vorgänge und beeinträchtigen so die Sicherung und Wiederherstellung.
• Sie verlängern die Wiederherstellungszeiten und setzen Cluster dem Risiko von kaskadierenden Festplattenausfällen aus.

1. 3. Falsches RAID zerstört Cluster schneller als CPU- oder RAM-Engpässe. Rechenengpässe sind behebbar, instabile Speicher nicht. RAID ist die Grundlage für die Stabilität von VMware.

Wie VMware ESXi Speicher tatsächlich nutzt

Zufällige I/O, keine sequenziellen Workloads

• VMFS erzeugt gemischte zufällige Lese- und Schreibvorgänge.

Das Virtual Machine File System (VMFS) von VMware ist dafür ausgelegt, mehrere VMs gleichzeitig zu hosten. Jede VM sendet ihre eigenen unabhängigen I/O-Anforderungen, die sich zu einem sehr zufälligen Muster zusammenfügen. Im Gegensatz zu herkömmlichen Workloads, die sequenzielle Lese-/Schreibvorgänge streamen, sieht der ESXi-Speicher fragmentierte Zugriffe über viele kleine Blöcke hinweg.

• Snapshots vervielfachen die Schreibverstärkung.

Wenn Snapshots aktiv sind, wird jeder Schreibvorgang durch die Copy-on-Write-Logik umgeleitet. Das heißt, ein einzelner Schreibvorgang einer VM kann mehrere Backend-Operationen auslösen: Aktualisierung von Metadaten, Schreiben neuer Blöcke und Beibehalten alter Blöcke. Je mehr Snapshots du stapelst, desto stärker ist die Amplifikation, was die Latenz erhöht und Parity-RAID belastet.

• Datenbanken und VDI belasten Paritäts-RAID.

Datenbank-Workloads und Virtual Desktop Infrastructure (VDI)-Umgebungen erzeugen ständig kleine zufällige Schreibvorgänge. Bei RAID 5/6 erfordert jeder Schreibvorgang eine Paritätsberechnung und mehrere Festplattenoperationen. Dieser Overhead macht Paritäts-RAID zu einem Engpass, der zu unvorhersehbaren Verzögerungen und einer verminderten Reaktionsfähigkeit der VMs führt.

Warum Latenzkonsistenz wichtiger ist als IOPS

• Die ESXi-Planung hängt von der Reaktionszeit des Speichers ab.

Der CPU-Scheduler von VMware erwartet, dass der Speicher innerhalb vorhersehbarer Zeiträume reagiert. Wenn die Festplattenlatenz stark ansteigt, stoppt der Hypervisor die Ausführung der VM, was zu Pausen oder „Stun“-Ereignissen führt. Selbst hohe IOPS-Werte helfen nicht, wenn die Latenz ungleichmäßig ist.

• RAID-Wiederherstellungen verursachen Latenzspitzen, die zu VM-Pausen führen.

Wenn eine Festplatte ausfällt, überfluten RAID-Wiederherstellungen das Array mit Paritätsberechnungen und Hintergrund-E/A. Dies konkurriert mit dem VM-Datenverkehr und führt zu unvorhersehbaren Verzögerungen. Bei Paritäts-RAID können Wiederherstellungen Stunden oder Tage dauern, während denen Latenzspitzen wiederholt die VM-Planung stören. Das Ergebnis: VM-Einfrieren, fehlgeschlagene Snapshots und Cluster-Instabilität.

VMware ESXi-Workloads sind zufällig, latenzempfindlich und snapshotintensiv. RAID-Level, die auf Parität basieren (RAID 5/6), haben unter diesen Bedingungen Probleme, während spiegelbasierte oder Stripe-Mirror-Designs (RAID 1, RAID 10) die vorhersehbare Latenz bieten, die VMware braucht.

Beste RAID-Konfiguration für VMware nach Workload-Typ

Allzweck-Virtualisierungshosts

RAID 10 als Basisstandard.

Bei gemischten Workloads bietet RAID 10 die ausgewogenste Kombination aus Leistung, Wiederherstellungssicherheit und vorhersehbarer Latenz.

Warum RAID 10 hier funktioniert:

• Striping verbessert den Durchsatz für leseintensive VMs.
• Spiegelung sorgt für schnelle Wiederherstellungen und minimiert Ausfallzeiten nach Festplattenausfällen.
• Die Latenz bleibt konstant, wodurch VM-Stun-Ereignisse vermieden werden, die bei Parity-RAID häufig auftreten.

RAID 10 sollte die Standardwahl für allgemeine ESXi-Cluster sein, bei denen die Vielfalt der Workloads vor allem Stabilität erfordert.

Datenbanken und transaktionsintensive VMs

Nur RAID 10.

Datenbanken und Transaktionssysteme erzeugen viele zufällige Schreibvorgänge. RAID 5/6 führt einen Paritäts-Overhead ein, der Commit-Vorgänge und die Verarbeitung von Snapshots verlangsamt.

Warum Paritäts-RAID hier nicht gut funktioniert:

• Jeder Schreibvorgang erfordert mehrere Festplattenoperationen für die Paritätsberechnung.
• Die Konsolidierung von Snapshots wird unter Paritäts-RAID extrem langsam.
• Latenzspitzen stören die Transaktionskonsistenz und die VM-Planung.

RAID 10 beseitigt Paritätsverluste und sorgt für zuverlässige Leistung bei geschäftskritischen Transaktions-Workloads.

VDI- und hochdichte VM-Umgebungen

RAID 10 oder RAID 6 mit großem Cache und SSD-Tiering.

VDI-Boot-Storms und hochdichte VM-Aktivitäten erzeugen massive zufällige E/A-Vorgänge. RAID 10 bleibt die sicherste Option, aber RAID 6 kann in Kombination mit Caching der Enterprise-Klasse und SSD-Beschleunigung ebenfalls eine praktikable Lösung sein.

Anforderungen für RAID 6 in VDI:

• Großer Schreibcache, um zufällige Schreibvorgänge zu absorbieren.
• SSD-Tiering, um häufig verwendete Daten auszulagern und den Paritäts-Overhead zu reduzieren.
• Batteriegepufferter Cache-Schutz, um Datenverlust bei Stromausfällen zu verhindern.

RAID 10 ist die bevorzugte Option, aber RAID 6 kann in kostensensiblen Bereitstellungen akzeptabel sein, wenn Cache und SSD-Tiering ordnungsgemäß implementiert sind.

RAID-Level für VMware ESXi: Was funktioniert und was nicht

RAID 10 – die sicherste Wahl von VMware

• Schnelle Wiederherstellung. Gespiegelte Paare ermöglichen eine schnelle Wiederherstellung nach einem Festplattenausfall und minimieren so Ausfallzeiten.
• Vorhersehbare Latenz. Striping verteilt die E/A-Vorgänge auf mehrere Festplatten, während die Spiegelung Paritäts-Overhead vermeidet und so konsistente Antwortzeiten gewährleistet.
• Übersteht Festplattenausfälle während der Auslastung. RAID 10 kann mehrere Festplattenausfälle (einen pro Spiegelungssatz) tolerieren, ohne dass der Datenspeicher zusammenbricht, sodass VMs auch unter Belastung stabil bleiben.
• Fazit: RAID 10 ist der Goldstandard für VMware ESXi und bietet ein ausgewogenes Verhältnis zwischen Leistung, Ausfallsicherheit und Zuverlässigkeit.

RAID 5 – nur in bestimmten Szenarien akzeptabel

• Leselastige Workloads. RAID 5 kann eine ordentliche Leistung liefern, wenn die Workloads hauptsächlich aus Lesevorgängen mit minimalen zufälligen Schreibvorgängen bestehen.
• Flash-gestützte Controller. Schreib-Caching kann Paritätsverluste kaschieren, aber nur mit Controllern der Enterprise-Klasse.
• Geringe Anzahl von VMs. Bei begrenzter Parallelität kann RAID 5 praktikabel sein, aber bei einer schnellen Skalierung werden seine Schwächen deutlich.
• Fazit: RAID 5 ist ein Kompromiss. Verwende es nur für leichte, leseintensive Workloads, bei denen die Kosteneinsparungen die Risiken überwiegen.

RAID 6 – Kapazität vor Leistung

• Archiv-VMs. Geeignet für Cold Storage oder selten genutzte virtuelle Maschinen.
• Backup-Repositorys. Eignet sich für sekundäre Datenspeicher, bei denen der Durchsatz weniger wichtig ist als die Kapazität.
• Lange Wiederherstellungszeiten erhöhen das Risiko. Doppelte Parität schützt vor zwei Festplattenausfällen, aber die Wiederherstellung ist langsam und Latenzspitzen können VMs lahmlegen.
• Fazit: Bei RAID 6 geht es um die Maximierung des Speicherplatzes, nicht um die Leistung. Vermeiden Sie es für Produktions-Workloads mit hoher E/A-Auslastung.

RAID 0 – niemals für ESXi-Datenspeicher

• Keine Fehlertoleranz. RAID 0 bietet Geschwindigkeit, aber keine Redundanz.
• Ein einziger Festplattenausfall zerstört VMFS. Ein ausgefallenes Laufwerk löscht den gesamten Datenspeicher und damit alle VMs.
• Fazit: RAID 0 ist für VMware ESXi nicht okay. Es passt nur in Testlabors, wo Datenverlust nicht wichtig ist.

RAID-Wiederherstellungsverhalten und VMware-Risiko

Warum RAID-Wiederherstellungen VMware-Cluster stören

• Latenzspitzen führen zu VM-Stun.

Während eines Wiederaufbaus sind die Festplatten mit Hintergrund-E/A ausgelastet. VMware ESXi ist auf vorhersehbare Latenzzeiten angewiesen. Wenn die Antwortzeiten steigen, pausiert der Hypervisor die VMs, was zu Stun-Ereignissen und Leistungseinbußen führt.

• Snapshots können fehlschlagen.

Die Erstellung und Konsolidierung von Snapshots erfordert eine konstante Schreibleistung. Der Overhead beim Wiederaufbau stört diese Vorgänge und führt zu Snapshot-Fehlern oder verlängerten Konsolidierungszeiten, die sich auf Backup- und Wiederherstellungs-Workflows auswirken.

• HA-Ereignisse nehmen zu.

VMware High Availability (HA) sieht längere VM-Pausen als Fehler an. Latenzspitzen während des Neuaufbaus können unnötige HA-Neustarts auslösen, was die Instabilität im gesamten Cluster noch verstärkt.

Entwerfen Sie Regeln, um Wiederherstellungen zu überstehen

• Begrenzen Sie die Festplattengröße.

Große Festplatten verlängern die Wiederherstellungszeiten und erhöhen das Risiko. Kleinere Festplatten der Enterprise-Klasse verkürzen die Wiederherstellungsdauer und minimieren das Risiko.

• Bevorzugen Sie spiegelbasiertes RAID.

RAID 10 und RAID 1 werden im Vergleich zu Parity-RAID schneller und mit geringeren Latenzauswirkungen neu aufgebaut. Durch Spiegelung werden Paritätsberechnungen vermieden, sodass die Latenz während der Wiederherstellung vorhersehbar bleibt.

• Halte Hot Spares bereit.

Automatische Wiederherstellungen auf Hot Spares verkürzen die Zeit, die Arrays im degradierten Modus verbringen. Dies verringert das Risiko eines zweiten Festplattenausfalls und stabilisiert VMware-Workloads während der Wiederherstellung.

RAID-Fehlkonfigurationen, die zu Datenverlusten führen

Häufige Fehler in der Praxis

• RAID 5 mit großen SATA-Festplatten.

Die Verwendung von RAID 5 mit SATA-Laufwerken mit mehreren Terabyte führt zu unzumutbar langen Wiederherstellungszeiten. Die Wahrscheinlichkeit eines zweiten Festplattenausfalls während einer Wiederherstellung ist hoch, was oft zum vollständigen Verlust des Arrays führt.

• RAID 6 unter hoher Schreiblast.

RAID 6 schützt zwar vor zwei Festplattenausfällen, aber sein Paritäts-Overhead bricht bei anhaltenden zufälligen Schreibvorgängen zusammen. In VMware-Umgebungen führt das zu Latenzspitzen, VM-Stun-Ereignissen und schließlich zu einer Beschädigung des Datenspeichers.

• Erweiterung von Arrays ohne Backups.

Das Hinzufügen von Festplatten oder das Erweitern von RAID-Gruppen ohne verifizierte Sicherung birgt Risiken. Controller-Fehler oder Unterbrechungen des Wiederaufbaus während der Erweiterung können VMFS-Volumes sofort zerstören.

Szenarien für VMFS-Beschädigungen

• Stromausfall während des Wiederaufbaus.

Wenn während des Wiederaufbaus der Strom ausfällt, führen unvollständige Paritätsberechnungen zu einem inkonsistenten Zustand des Arrays. VMFS-Metadaten sind besonders anfällig, was zu einer nicht behebbaren Beschädigung führt.

• Fehler in der Controller-Firmware.

Veraltete oder instabile RAID-Controller-Firmware kann Wiederherstellungen oder Paritätsschreibvorgänge falsch ausführen. Diese stillen Fehler zeigen sich oft erst lange nach dem ursprünglichen Ereignis als VMFS-Beschädigung.

• Unvollständiger Festplattenaustausch.

Wenn eine defekte Festplatte falsch ausgetauscht wird – oder mit nicht passender Firmware/Geometrie –, kann das den RAID-Controller verwirren. Das führt zu unvollständigen Wiederherstellungen, fehlerhafter Parität und beschädigten VMware-Datenspeichern.

Überlegungen zu VMware-RAID-Ausfällen und -Wiederherstellungen

Wenn VMware VMFS nicht mehr mounten kann

• Beschädigte RAID-Metadaten.

Wenn RAID-Metadaten beschädigt sind oder verloren gehen, kann der Controller VMware kein konsistentes Array mehr bereitstellen. VMFS-Volumes sind dann nicht mehr zugänglich, selbst wenn die meisten Festplatten intakt sind.

• Inkonsistentes Stripe-Layout.

Falsch ausgerichtete oder teilweise neu aufgebaute Stripe-Sets verwirren die Speicherschicht von VMware. ESXi erwartet eine vorhersehbare Blockzuordnung. Wenn die Stripes inkonsistent sind, kann VMFS nicht gemountet werden und der Datenzugriff schlägt fehl.

• Teilweise Wiederherstellungsschäden.

Unterbrochene oder unvollständige Wiederherstellungen lassen Arrays in einem beeinträchtigten Zustand zurück. VMware sieht das als beschädigten Speicher und verhindert das Mounten von VMFS, was zu dauerhaftem Datenverlust führen kann.

RAID Recovery-Optionen

• RAID-Rekonstruktion auf Softwareebene vor der physischen Reparatur.

Spezielle Tools können RAID-Arrays logisch rekonstruieren und dabei Controller-Fehler umgehen. Das ist oft sicherer, als zuerst Hardware-Reparaturen zu versuchen.

• Beispiel: DiskInternals RAID Recovery.

Tools wie DiskInternals können RAID-Parameter erkennen, Arrays virtuell wiederherstellen und VMFS-Volumes wiederherstellen, ohne die Quellfestplatten zu verändern.

• Manuelle Erkennung von RAID-Parametern.

Wenn Metadaten verloren gegangen sind, müssen die RAID-Parameter (Stripe-Größe, Reihenfolge, Paritätslayout) manuell ermittelt werden. Eine korrekte Erkennung ermöglicht die virtuelle Rekonstruktion des Arrays.

• VMFS Recovery.

Sobald das RAID rekonstruiert ist, können VMFS-Strukturen gescannt und wiederhergestellt werden. So kann man auf Dateien der virtuellen Maschine zugreifen, auch wenn das ursprüngliche Array nicht mehr funktioniert.

• Schreibgeschützter Betrieb auf Quellfestplatten.

Die Wiederherstellung sollte immer im schreibgeschützten Modus durchgeführt werden, um weitere Beschädigungen zu vermeiden. Quellfestplatten müssen unberührt bleiben, bis die Daten sicher extrahiert wurden.

Checkliste zum RAID-Design für VMware-Administratoren

Vor der Bereitstellung

• Definiere das I/O-Profil der Arbeitslast.

Stell fest, ob die Workloads zufällig oder sequenziell, leseintensiv oder schreibintensiv sind. So stellst du sicher, dass die RAID-Auswahl den tatsächlichen Anforderungen von VMware entspricht.

• Wähle RAID wegen der Sicherheit beim Wiederherstellen, nicht wegen der Kapazität.

Priorisieren Sie vorhersehbare Wiederherstellungen und Latenzstabilität gegenüber der Maximierung des nutzbaren Speicherplatzes. RAID 10 sollte die Standardbasis für ESXi sein.

• Überprüfe den Cache-Schutz des Controllers.

Stell sicher, dass der Schreibcache batteriegepuffert oder flashgeschützt ist. Ohne Cache-Schutz besteht bei Parity-RAID die Gefahr von Datenverlusten bei Stromausfällen.

Vor der Produktion

• Teste Szenarien mit Festplattenausfällen.

Simuliere den Verlust von Laufwerken und schau dir an, wie sich der Wiederaufbau auf die Latenz der VM auswirkt. Stell sicher, dass die Workloads auch unter verschlechterten Bedingungen stabil bleiben.

• Überprüfe die Wiederherstellung von Backups.

Mach vollständige Wiederherstellungstests aus Backups, um die Wiederherstellungspfade zu überprüfen. RAID allein ist kein Ersatz für eine überprüfte Backup-Integrität.

• Dokumentiere das RAID-Layout.

Halte die Stripe-Größe, die Reihenfolge der Festplatten und die Controller-Einstellungen fest. Die Dokumentation beschleunigt die Wiederherstellung bei einem Controller-Ausfall oder einer Array-Rekonstruktion.