VMware unterstützt bei der Storage-Anbindung traditionellen blockbasierten SAN-Storage mit Fibre Channel, FCoE und/oder iSCSI sowie File-basierten Storage via NFS 3 und 4.1 (ab vSphere 6). Da vSphere von Haus einen komplett eigenen Storage-Stack mit eigenen Multipathing- und Path-Selection-Plugins mitbringt, der auf Wunsch auch Hersteller-Plugins unterstützt, steht dem Aufbau einer professionellen Storage-Fabric nichts im Wege. Oft stellt sich dabei die Frage nach der Größe der Datastores, bzw. LUNs im Backend sowie nach der Anzahl an Datastores, um sämtliche VMs aufnehmen zu können.
Egal ob man nun traditionellen SAN-Storage der führenden Storage-Hersteller oder softwaredefinierten hyperkonvergenten Storage (Datacore, Nutanix, Simplivity, Starwind & Co oder eine Open-Source-SDN-Lösung) anbindet, kommt beim Storage-Design häufig die Frage auf, viele virtuelle Maschinen (also VMDK-Dateien) man auf einer LUN unterbringen kann und soll. Eine pauschale Empfehlung vom VMware gibt es dazu nämlich nicht, weil sich die Frage pauschal nicht eindeutig beantworten lässt. Ich empfehle in meinen vSphere-Kursen, das Problem aus mindestens 4 Perspektiven zu betrachten.
Von allen Seiten
Sieht man mal ganz von der Frage ab, dass die Anzahl an VMs, die die eigene Storage-Landschaft hinsichtlich der „Packungsdichte“ (VMware empfiehlt Virtualisierungsraten von 4 bis 8) auf den Hosts überhaupt maximal aufnehmen kann, ist sind beim Sizing der Datastores, bzw. der LUN-Größen am Backend stets folgende Punkte zu berücksichtigen:
1. Die LUN ist bei traditionellem Storage immer der begrenzende Faktor für die „Eigenschaften“ des Datastores, also VMs mit unterschiedlichen Workload-Charakteristiken gehören zunächst nicht auf die gleiche LUN.
2. Andererseits profitieren möglicherweise VMs von VMDKs auf der gleichen LUN, wenn deren Workloads miteinander im Zusammenhang stehen.
3. Ferner ist die Anzahl verfügbarer LUNs (Pfade) pro Host begrenzt. Bis ESXi 6 sind 256, ab ESXi 6,5 512 LUNs erlaubt, wobei jeder Pfad extra zählt. Ist also jede LUN z. B. über 4 Pfade erreichbar, reduziert sich die Zahl nutzbarer LUNs auf 64. Gibt es dann noch Datastores mit mehreren Extents, reduziert sich die Anzahl nutzbarer LUNs weiter. Ist aber die Anzahl der hinsichtlich der Konsolidierungsrate nutzbarer VMs deutlich größer, führt schon kein Weg daran vorbei, mehrere VMs auf einer LUN unterzubringen.
4. Bei der Auswahl der LUN-Charakteristik ist außerdem zu berücksichtigen, ob das das Storage-Aarray VMwares „vSphere Storage APIs Array Integration“ (VAAI) unterstützt und z. B. Storage-Operationen wie „Clone Blocks/Full Copy /XCOPY“, „ATS“ (Atomic Test & Set) zur Vermeidung von SCSI Reservations, „Zero Blocks/Same Writer“ oder Thin-Provisioning auf das Storage-System offloaden kann. Seit ESX 5.1 kann der ESXi-Host übrigens Informationen zum Storage-Back-end senden, welche Blöcke im Datastore nicht mehr mit VMs-Daten belegt sind, etwa weil eine VM beispielsweise gelöscht oder migriert wurde. Seit vSphere 6,5 kann das so genannte Reclaiming im Zusammenhang mit VMFS 6 sogar automatisch erfolgen. Es ist also z. B. nicht sinnvoll, VMs mit VMware-Thin-Provisiong auf vom Storage thin provisionierte LUNs zu platzieren, um nur ein Beispiel zu nennen.
Damit aber nicht genug. Die Anzahl pro LUN sinnvoller VMs wird noch durch weitere diffizilere Eigenschaften begrenzt. So beschränkt z. B. auch die IO-Queue innerhalb von VMware die Anzahl der VMs pro Datastore. So besitzt jeder ESXi-Host eine Queue-Tiefe von 32 Kommandos pro VMFS-Datastore.
Hat der Storage z. B. eine durchschnittliche Latenz von 5ms für alle IOs, so lassen sich die theoretisch maximal möglichen IOPS berechnen, bevor der Server zusätzliche Latenzen durch ein Überlaufen der Queue erfährt: 1 (host) * 32 (Kommandos pro Queue) * 1000 ms/5ms = durchschnittliche Latenz = 6400 IOPS. Mit 6400 IOPS könnte man dann z. B. 10 sehr aktive VMs mit je 640 IOPS pro VM auf den Datastore packen. Der Wert berechnet sich stets pro ESX Host. Verteilt man also seine VMs gleichmäßig auf die ESX Server, kann man aus Performance-Sicht natürlich deutlich mehr als 10 VMs auf einen Datastore legen.