Storage für VMware sollte vor allem niedrige und möglichst konstante Latenzen, hohe I/O-Leistung, Ausfallsicherheit, effiziente Snapshots und eine gute Integration in die Virtualisierungsplattform bieten. Dabei kommt es nicht allein auf maximale IOPS an. Entscheidend ist, wie sich das Storage-System unter gemischter Last verhält. Viele virtuelle Maschinen erzeugen gleichzeitig unterschiedliche Lese- und Schreibzugriffe. Dadurch entsteht ein komplexes I/O-Profil.
Für Enterprise-Umgebungen sind deshalb insbesondere diese Punkte relevant:
Everpure FlashArray ist eine All-Flash-Storage-Plattform, die für solche konsolidierten Enterprise-Workloads eingesetzt werden kann. Welche Architektur sinnvoll ist, hängt jedoch von Workload, Verfügbarkeitsanforderungen, VMware-Version, Netzwerk und gewünschtem Betriebsmodell ab.
Warum Virtualisierung besondere Anforderungen an Storage stellt
Virtualisierung bündelt die Storage-Zugriffe vieler unterschiedlicher Systeme auf einer gemeinsamen Infrastruktur. Genau das unterscheidet eine VMware-Umgebung von einem klassischen Server, der auf dedizierten Storage zugreift. Auf einem VMware-vSphere-Cluster können zahlreiche virtuelle Maschinen gleichzeitig aktiv sein. Eine VM betreibt beispielsweise eine Datenbank. Eine andere stellt Dateien bereit. Weitere VMs führen Anwendungen, Verzeichnisdienste oder andere Unternehmensdienste aus. Für das Storage-System erscheinen diese Zugriffe gleichzeitig.
Die Folge: Der Storage muss nicht nur eine einzelne Anwendung bedienen. Er muss viele unterschiedliche I/O-Muster parallel verarbeiten und Lastspitzen abfangen können. Deshalb sollten Unternehmen bei der Storage-Auswahl für VMware nicht nur auf Kapazität oder theoretische IOPS-Werte achten. Relevant sind unter anderem:
Die konkrete Dimensionierung sollte auf den tatsächlichen Workloads basieren.
Virtuelle Maschinen erzeugen sehr unterschiedliche Storage-Lasten, obwohl sie denselben Datastore verwenden können.
Eine Datenbank kann viele kleine zufällige Schreibvorgänge erzeugen. Ein Fileserver verarbeitet möglicherweise größere sequenzielle Transfers. Gleichzeitig startet eine weitere VM, während auf einer anderen ein Backup oder eine Anwendung mit hoher I/O-Aktivität läuft.
Der Hypervisor führt diese Zugriffe auf der Storage-Infrastruktur zusammen. Dadurch können aus mehreren vergleichsweise übersichtlichen Workloads komplexe gemischte I/O-Muster entstehen. Für die Storage-Planung bedeutet das: Durchschnittswerte reichen häufig nicht aus. Neben Kapazität und durchschnittlichen IOPS sollten insbesondere Spitzenlasten, Read-/Write-Verhältnis, Blockgrößen, Latenzanforderungen und Wachstumsprognosen betrachtet werden. Auch sogenannte „Noisy Neighbors“ sind relevant. Damit sind Workloads gemeint, die zeitweise besonders viele Ressourcen beanspruchen und dadurch andere virtuelle Maschinen beeinflussen können.
Als I/O-Blender wird der Effekt bezeichnet, dass die I/O-Ströme vieler virtueller Maschinen durch den Hypervisor zusammengeführt werden und am Storage als stark gemischter Workload ankommen.
Eine einzelne Anwendung kann beispielsweise überwiegend sequenzielle Zugriffe erzeugen. Werden die Zugriffe vieler Anwendungen zusammengeführt, kann daraus auf Storage-Ebene ein wesentlich stärker randomisiertes Muster entstehen. Der Begriff wird bereits seit vielen Jahren im Zusammenhang mit Servervirtualisierung verwendet. Auch VMware hat das Konzept in früheren technischen Veröffentlichungen aufgegriffen. Für klassische Festplattensysteme war dieses Verhalten besonders problematisch. Mechanische Festplatten benötigen für zufällige Zugriffe physische Kopfbewegungen und erreichen dabei deutlich weniger I/O-Operationen als bei sequenziellen Zugriffen.
Flash-Storage besitzt diese mechanische Einschränkung nicht. Das bedeutet jedoch nicht, dass jedes All-Flash-System automatisch für jede VMware-Umgebung geeignet ist. Controller, Protokolle, Storage-Netzwerk, Queue-Verhalten und Datenservices beeinflussen ebenfalls die erreichbare Performance und Latenz.
Bei einem VMware-Storage-Projekt sollten wir deshalb nicht nur fragen: „Wie viele IOPS schafft das Storage-System?“
Wichtiger sind Fragen wie:
Erst aus diesen Informationen lässt sich eine belastbare Storage-Architektur ableiten.
Storage für VMware sollte auch unter hoher und gemischter Last möglichst konstante Antwortzeiten liefern.
Eine pauschale Latenzgrenze, die für jede VMware-Umgebung gilt, gibt es nicht. Die Anforderungen hängen von den Anwendungen innerhalb der virtuellen Maschinen ab. Ein Archivserver stellt andere Anforderungen als eine transaktionsintensive Datenbank. Deshalb sollte nicht nur die durchschnittliche Latenz betrachtet werden. Relevant sind auch Lastspitzen und die Frage, ob sich Antwortzeiten bei hoher Auslastung deutlich verschlechtern.
Wichtige Messgrößen sind:
| Kennzahl | Bedeutung |
| IOPS | Anzahl der I/O-Operationen pro Sekunde |
| Latenz | Zeit zwischen I/O-Anfrage und Antwort |
| Durchsatz | Übertragene Datenmenge pro Zeiteinheit |
| Read-/Write-Verhältnis | Verhältnis zwischen Lese- und Schreibzugriffen |
| Blockgröße | Größe der einzelnen I/O-Operationen |
| Queue Depth | Anzahl gleichzeitig wartender I/O-Anfragen |
Diese Werte müssen gemeinsam betrachtet werden. Eine hohe IOPS-Zahl allein sagt beispielsweise wenig darüber aus, welche Antwortzeiten unter produktiver Last erreicht werden.
Enterprise Storage für VMware muss Ausfälle einzelner Komponenten abfangen und sollte geplante Wartungsarbeiten möglichst ohne Unterbrechung der Workloads ermöglichen.
Das beginnt bei grundlegender Redundanz. Dazu gehören beispielsweise redundante Controller, Netzwerkpfade, Switches und Stromversorgungen. Everpure beschreibt FlashArray als Architektur mit redundanten Komponenten und für unterbrechungsfreie Upgrades ausgelegten Controller-Konzepten. Für FlashArray//X nennt der Hersteller eine Verfügbarkeit von bis zu 99,9999 Prozent. Dabei handelt es sich um eine Herstellerangabe, die nicht automatisch der tatsächlich erreichten Verfügbarkeit einer gesamten VMware-Infrastruktur entspricht.
Denn die Verfügbarkeit einer virtuellen Maschine hängt nicht nur vom Storage ab. Auch ESXi-Hosts, SAN beziehungsweise Ethernet-Netzwerk, Stromversorgung, vCenter-Komponenten und die Anwendung selbst gehören zur Gesamtarchitektur.
Für höhere Anforderungen an Business Continuity bietet Everpure mit ActiveCluster synchrone Replikation zwischen FlashArray-Systemen. Nach Herstellerangaben ermöglicht ActiveCluster ein RPO von null. RPO steht für Recovery Point Objective und beschreibt, wie viel Datenverlust im Störungsfall akzeptiert werden kann. Bei synchroner Replikation werden bestätigte Schreibvorgänge auf beide beteiligten Systeme geschrieben.
Everpure nennt außerdem die Unterstützung von VMware vSphere Metro Storage Cluster für entsprechende Stretched-Cluster-Szenarien. Eine solche Architektur muss allerdings sorgfältig geplant werden. Insbesondere Netzwerkverbindungen, Latenz zwischen den Standorten, Failure Domains, Quorum beziehungsweise Mediator und das gewünschte Failover-Verhalten müssen zum Business-Continuity-Konzept passen.
Storage-Snapshots können die Wiederherstellung virtueller Umgebungen erheblich beschleunigen, ersetzen aber kein vollständiges Backup- und Disaster-Recovery-Konzept.
Snapshots speichern einen definierten Zustand von Daten. Moderne Storage-Systeme können solche Zustände auf Array-Ebene sehr effizient abbilden. Everpure beschreibt FlashArray-Snapshots als metadata-basierte und platzsparende Snapshots. FlashArray//X unterstützt außerdem SafeMode Snapshots, die vor unerwünschtem Löschen geschützt werden können.
Für VMware-Umgebungen ergeben sich daraus verschiedene Einsatzmöglichkeiten:
Wichtig ist die Unterscheidung zwischen Crash-Konsistenz und Anwendungskonsistenz. Ein Storage-Snapshot allein garantiert nicht automatisch, dass eine innerhalb der VM laufende Datenbank oder Anwendung einen konsistenten Zustand besitzt. Für geschäftskritische Systeme sollten Snapshot-, Backup- und Applikationsmechanismen deshalb aufeinander abgestimmt werden.
Virtualisierte Umgebungen enthalten häufig ähnliche oder identische Datenblöcke und können deshalb von Deduplizierung, Komprimierung und Thin Provisioning profitieren.
Viele VMs basieren beispielsweise auf demselben Betriebssystem oder auf vergleichbaren Templates. Deduplizierung erkennt identische Datenblöcke und speichert sie nicht mehrfach. Komprimierung reduziert den Platzbedarf komprimierbarer Daten. Thin Provisioning stellt virtuelle Kapazität bereit, ohne diese vollständig physisch reservieren zu müssen. FlashArray führt diese Verfahren inline aus. Everpure nennt Deduplizierung, Komprimierung und Thin Provisioning als globale Datenreduktionsmechanismen der Plattform.
Wie hoch die tatsächlich erreichbare Datenreduktion ist, hängt jedoch stark vom Datenbestand ab. Bereits komprimierte oder verschlüsselte Daten lassen sich beispielsweise deutlich schlechter reduzieren als viele gleichartige Betriebssystem-Images. Deshalb sollten wir für eine konkrete Kapazitätsplanung nicht mit einem pauschalen Reduktionsfaktor rechnen. Entscheidend sind die vorhandenen Daten und Workloads.
FlashArray kombiniert All-Flash-Storage mit Datenservices, VMware-Integration, Automatisierung und Funktionen für Hochverfügbarkeit und Wiederherstellung.
Damit adressiert die Plattform mehrere Anforderungen, die bei konsolidierten VMware-Umgebungen relevant sind.
Dazu gehören unter anderem:
FlashArray kann damit sowohl klassische VMFS-Datastores als auch (abhängig von der jeweiligen Plattform- und Produktversion) NFS-basierte VMware-Datastores bereitstellen. Everpure positioniert NFS inzwischen auch für VMware Cloud Foundation als Möglichkeit, Compute und externe Storage-Ressourcen voneinander zu entkoppeln.
Welche Variante sinnvoll ist, sollte anhand der bestehenden VMware-Architektur, des verwendeten Netzwerkes und der betrieblichen Anforderungen entschieden werden.
Für neue VMware-Projekte ist diese Frage 2026 besonders relevant.
VMFS und NFS sind weiterhin wichtige Storage-Optionen für VMware. vVols sollten dagegen bei neuen Architekturentscheidungen mit Blick auf den angekündigten Lifecycle nicht mehr unkritisch als Zukunftsmodell eingeplant werden.
VMware Virtual Volumes, kurz vVols, ermöglichten eine stärkere Zuordnung von Storage-Funktionen zu einzelnen virtuellen Maschinen. Pure Storage hat diese Technologie über Jahre eng unterstützt. Die Rahmenbedingungen haben sich inzwischen geändert. Nach Angaben von Everpure bleiben vVols bei VMware vSphere 8.0 und VMware Cloud Foundation 9.0 unterstützt. VMware hat jedoch die Einstellung der Technologie angekündigt. Everpure empfiehlt deshalb, für zukünftige VMware-Versionen Alternativen wie VMFS oder NFS einzuplanen. Bestehende vVol-Umgebungen müssen deshalb nicht kurzfristig abgeschaltet werden. Bei neuen Storage-Architekturen sollte der angekündigte Lifecycle jedoch berücksichtigt werden.
Storage für große VMware-Umgebungen sollte sich automatisieren lassen und möglichst gut in die vorhandenen Management-Prozesse integrieren.
Je mehr VMs und Datastores betrieben werden, desto wichtiger werden standardisierte Abläufe. Everpure bietet hierfür unter anderem ein vSphere Client Plugin für FlashArray. Darüber lassen sich bestimmte Storage-Aufgaben direkt aus dem vSphere Client heraus durchführen. Dazu gehören beispielsweise das Erstellen, Erweitern und Löschen von Datastores sowie bestimmte Snapshot-Operationen.
Zusätzlich stellt FlashArray REST-APIs bereit. Die aktuelle API-Dokumentation enthält unter anderem Schnittstellen für Kapazitäts-, Performance- und Storage-Objekte. Das ist insbesondere für größere Infrastrukturen relevant. Wiederkehrende Aufgaben können automatisiert und in bestehende Infrastructure-as-Code- oder Betriebsprozesse integriert werden. Dadurch sinkt die Abhängigkeit von manuellen Eingriffen.
Storage für Virtualisierung sollte nicht nur für die aktuelle VM-Zahl dimensioniert werden, sondern Reserven für steigende Kapazität und I/O-Last besitzen.
Mehr VMs bedeuten nicht automatisch proportional mehr Storage-Last. Eine zusätzliche Datenbank-VM kann mehr I/O erzeugen als viele kleine Infrastrukturserver zusammen. Deshalb ist die reine VM-Anzahl für eine Storage-Dimensionierung nur begrenzt aussagekräftig. Sinnvoller ist es, Wachstum in mehreren Dimensionen zu betrachten:
Auch die Skalierung von Compute und Storage sollte bewusst betrachtet werden. Bei externem Shared Storage können Compute-Ressourcen und Storage-Kapazität grundsätzlich unabhängig voneinander erweitert werden. Das kann für Umgebungen interessant sein, bei denen CPU-, RAM- und Storage-Bedarf unterschiedlich schnell wachsen.
Eine typische Enterprise-Architektur kann aus einem VMware-vSphere-Cluster mit mehreren ESXi-Hosts und einem redundant angebundenen FlashArray bestehen.
Ein vereinfachtes Beispiel:
Compute-Ebene
Mehrere VMware-ESXi-Hosts bilden einen vSphere-Cluster. Die Hosts stellen CPU und Arbeitsspeicher für die virtuellen Maschinen bereit.
Storage-Netzwerk
Die ESXi-Hosts werden redundant mit der Storage-Infrastruktur verbunden. Je nach Architektur können beispielsweise Fibre Channel, iSCSI, NVMe-basierte Protokolle oder NFS eingesetzt werden. Welche Protokolle in einer konkreten Kombination unterstützt werden, muss anhand der eingesetzten VMware-, FlashArray- und Netzwerkversionen geprüft werden.
Storage-Ebene
FlashArray stellt die benötigten Datastores bereit. Für eine neue VMware-Architektur kommen insbesondere VMFS oder NFS infrage. Bestehende vVol-Installationen sollten unter Berücksichtigung des angekündigten vVol-Lifecycles bewertet werden.
Datenschutz und Wiederherstellung
Snapshots können kurze Recovery-Zyklen unterstützen. Ein separates Backup bleibt für eine belastbare Datensicherungsstrategie erforderlich. Bei höheren Business-Continuity-Anforderungen kann ein zweites FlashArray an einem weiteren Standort über ActiveCluster synchron eingebunden werden.
Management
VMware-Administratoren können über das FlashArray-Plugin bestimmte Storage-Funktionen direkt aus dem vSphere Client nutzen. Pure1 und die FlashArray-Schnittstellen ergänzen Monitoring und Automatisierung.
Eine Referenzarchitektur ist immer nur ein Ausgangspunkt. Vor einer konkreten Storage-Entscheidung analysieren wir deshalb insbesondere:
Auf dieser Basis lässt sich entscheiden, welche FlashArray-Konfiguration und welche VMware-Anbindung technisch sinnvoll sind.
Als Concat unterstützen wir Sie dabei von der Bestandsaufnahme über Architektur und Dimensionierung bis zur Migration. Entscheidend ist dabei nicht, möglichst viel Storage bereitzustellen. Ziel ist eine Architektur, deren Performance, Kapazität und Verfügbarkeit zu den tatsächlichen Workloads passen.
Storage für VMware muss vor allem mit konsolidierten und wechselnden I/O-Lasten umgehen können. Hohe IOPS allein reichen als Auswahlkriterium nicht aus. Entscheidend sind konstante Latenz, Verfügbarkeit, Wiederherstellung, Skalierbarkeit und eine sinnvolle Integration in die Virtualisierungsumgebung. Everpure FlashArray adressiert diese Anforderungen mit All-Flash-Storage, Datenreduktion, Snapshots, Replikation, VMware-Integration und Automatisierung.
Für neue VMware-Architekturen sollte außerdem der aktuelle Wandel im VMware-Ökosystem berücksichtigt werden. Insbesondere der angekündigte Ausstieg aus vVols macht es notwendig, Storage- und Datastore-Strategien langfristig zu planen. Die passende Architektur ergibt sich deshalb nicht allein aus der Anzahl der VMs. Sie sollte auf realen I/O-Daten, Verfügbarkeitszielen, Backup-Anforderungen, VMware-Versionen und dem erwarteten Wachstum basieren.
Für VMware eignet sich Storage, der niedrige und möglichst konstante Latenzen, ausreichende IOPS und Bandbreite sowie hohe Verfügbarkeit bietet. Zusätzlich sind effiziente Snapshots, Datenreduktion, Monitoring und VMware-Integration für Enterprise-Umgebungen relevant. All-Flash-Systeme wie Everpure FlashArray sind für solche konsolidierten Workloads ausgelegt.
Storage für Virtualisierung muss viele unterschiedliche I/O-Profile gleichzeitig verarbeiten können. Wichtig sind deshalb nicht nur maximale IOPS, sondern insbesondere Latenz unter Last, Durchsatz, Redundanz, Wiederherstellbarkeit und Skalierbarkeit.
Der I/O-Blender beschreibt die Vermischung der Storage-Zugriffe vieler virtueller Maschinen. Der Hypervisor führt unterschiedliche Lese- und Schreibzugriffe zusammen. Dadurch entsteht auf dem Storage ein komplexer und häufig stärker randomisierter I/O-Workload.
All-Flash-Storage kann insbesondere bei vielen parallelen und zufälligen I/O-Zugriffen Vorteile bieten, da Flash keine mechanischen Zugriffszeiten wie Festplatten besitzt. Die tatsächliche Performance hängt jedoch zusätzlich von Storage-Architektur, Netzwerk, Protokoll und Workload ab.
Bestehende vVol-Umgebungen können abhängig von der eingesetzten VMware-Version weiterhin betrieben werden. Für neue langfristige Architekturen sollte jedoch berücksichtigt werden, dass VMware den Ausstieg aus vVols angekündigt hat. Everpure nennt VMFS und NFS als Alternativen für zukünftige VMware-Umgebungen.
Nein. Storage-Snapshots sind eine zusätzliche Ebene für schnelle Wiederherstellung, ersetzen aber kein eigenständiges Backup-Konzept. Für geschäftskritische Systeme sollten Snapshots, Backups, Replikation und gegebenenfalls anwendungskonsistente Sicherungsverfahren gemeinsam geplant werden.
Datenreduktion kann in VMware-Umgebungen besonders relevant sein, weil viele virtuelle Maschinen ähnliche Daten enthalten. FlashArray verwendet dafür unter anderem Inline-Deduplizierung, Komprimierung und Thin Provisioning. Die tatsächlich erreichbare Reduktion hängt vom jeweiligen Datenbestand ab.
ActiveCluster kommt infrage, wenn geschäftskritische VMware-Workloads synchron zwischen zwei FlashArray-Systemen geschützt werden sollen. Everpure gibt für ActiveCluster ein RPO von null an und unterstützt entsprechende VMware-vSphere-Metro-Storage-Cluster-Szenarien. Die technische Eignung hängt insbesondere von Standort-, Netzwerk- und Latenzanforderungen ab.
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von Turnstile laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen