Speicher für virtuelle Maschinen ist die gemeinsame Platte unter allen Gästen. Wenn das RAID langsam schreibt oder voll ist, werden Dateiserver, Datenbank und Domaincontroller gleichzeitig zäh, obwohl jede VM in ihrer eigenen Oberfläche „genug CPU“ zeigt. Die Auslegung beginnt deshalb beim Controller, bei der RAID-Stufe und beim freien Bereich, nicht bei der Summe der virtuellen Festplatten, die man dünn provisioniert übereinandergelegt hat.

Welche Plattenanordnung alle Maschinen gleichzeitig bremst

Thin Provisioning spart Platz, solange die Gäste ihn nicht wirklich belegen. In der Summe können die virtuellen Platten größer sein als der Datastore. Das ist so lange unsichtbar, bis ein Datenbanklog, ein Snapshot oder ein Windows-Update den Platz wirklich anfordert. Dann pausieren Maschinen, weil der Hypervisor keinen Block mehr schreiben kann. Thick Provisioning für die Datenbank und ein hartes Limit für den Rest sind oft ruhiger als ein Datastore, der nur auf dem Papier reicht.

RAID 5 oder 6 auf großen Festplatten ohne schnellen, batteriegepufferten Cache wird beim Schreiben langsam und beim Wiederaufbau nach einem Plattenausfall riskant lange. Für die Last mehrerer VMs sind SSD-Datastores oder ein RAID, das die Schreiblast der Datenbank nicht mit der Sicherung teilt, der normale Weg. Die Sicherung gehört auf ein anderes Gerät, idealerweise in einen anderen Brandabschnitt oder zumindest nicht in dasselbe Gehäuse als einzige Kopie. Ein zweiter Ordner auf demselben RAID ist kein zweites Gerät.

Getrennte Ziele, Freibereich und dünne Platten unter Kontrolle

  1. Last. Datenbank, Dateidienst und Sicherung werden als getrennte Schreiblasten gesehen. Was gleichzeitig in der Nacht läuft, darf nicht um dieselbe Spindel kämpfen.
  2. RAID. Stufe, Cache-Schutz und Wiederaufbauzeit werden vor dem Kauf benannt. SSD für produktive Maschinen ist der Normalfall, große Festplatten höchstens für kalte Archive.
  3. Provision. Dünn nur dort, wo jemand das Wachstum beobachtet. Datenbanken bekommen festen Platz. Die Summe der dünnen Platten wird gegen den echten Datastore gerechnet.
  4. Freibereich. Ein Teil des Datastores bleibt frei für Snapshots und Updates und wird überwacht. Die Meldung geht an eine Person, die reagieren kann.
  5. Ziel. Backup-Daten verlassen das Gehäuse. Controller-Modell und Firmware stehen in der Dokumentation neben dem Wiederanlauf.

Der Controller muss zur Plattform passen: bei ESXi zur Kompatibilitätsliste, bei ZFS unter Proxmox als durchgereichte Einzelplatten statt als bereits zusammengefasstes RAID. Ein Controller, den das Rettungssystem nicht sieht, verlängert den Ausfall um die Suche nach einem Treiber. Wir schreiben Modell und Firmware neben die Seriennummer, bevor der Host in den Betrieb geht.

Woran Projekte in der Praxis scheitern

  • Backup-Dateien auf demselben RAID ablegen wie die virtuellen Platten.
  • Thin Provisioning so weit übertreiben, dass die Summe der VMDKs oder VHDX den Datastore deutlich übersteigt, ohne Alarm.
  • RAID 5 auf großen, langsamen Platten für eine Datenbank wählen, weil eine Platte weniger „günstiger“ wirkt.
  • Den Cache des Controllers ohne Batterie oder Flash-Schutz als beschleunigt betrachten und beim Stromausfall Inkonsistenzen riskieren.

Beispiel aus dem Betriebsalltag

Ein Autohaus hatte drei VMs auf vier Festplatten im RAID 5, Thin Provisioning, dazu die Backup-Dateien auf einer Freigabe derselben Maschine. Vor dem Monatsabschluss wuchs das Datenbanklog, ein liegen gebliebener Snapshot kam dazu, und alle drei Maschinen stockten. Die Sicherung der Nacht war unvollständig, weil das Ziel selbst nicht mehr schreiben konnte. Wir haben die Produktivplatten auf SSD mit Freibereich umgestellt, das Backup auf ein NAS in einem anderen Raum gelegt und Thin Provisioning nur noch für den Dateiserver erlaubt. Die Datenbankplatte ist fest zugewiesen. Beim nächsten Abschluss blieb die Latenz unauffällig, und die Sicherung hatte ein Ziel, das nicht vom selben RAID abhing.

Kurze Entscheidungshilfe

  • Gibt es eine Alarmierung, bevor der Datastore voll ist?
  • Liegt das Backup auf anderer Hardware als die Produktivplatten?
  • Ist die Datenbank fest provisioniert oder zumindest mit überwachtem Wachstum?
  • Sind Controller, RAID-Stufe und Firmware dokumentiert?

Wenn Speicher für virtuelle Maschinen bei Ihnen ansteht, klären wir den Umfang unverbindlich: Virtualisierung. CPU- und RAM-Überbuchung Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.