Lieber Dr. InSider, unser neues VDI verschlingt das ganze SAN - muss ich mir das bieten lassen?

Liebe VDI-Eltern, sicher wäre eine Aufnahme oder zumindest durchdachte Vorberechnung des Bedarfs an Storage-IOs besser gewesen, aber da nun die Dinge sind, wie sie sind, und man VDIs schlecht zurückgeben kann, ist der Griff zum Portemonnaie für mehr Storage-IOs schmerzhaft, aber notwendig. Ihr habt aber dabei zumindest verschiedene Optionen:
- eine Peer-Lösung mit Disk-bestückten ESX-Hosts und Floating Desktop-Pools für VDI
- VDI und virtuelle Server auf dem gleichen SAN, welches jedoch ausgebaut werden muss.
- VDI und virtuelle Server auf dem gleichen SAN, allerdings über verschiedene Diskgruppen getrennt
- VDI und virtuelle Server auf verschiedenen SANs
 
Durch eine dieser Massnahmen ist der notwendig gewordene Mehrbedarf an Storage-IO-Ressourcen zu decken. Wenn man mal die innovative, jedoch an gewisse Bedingungen verknüpfte erste Lösung beiseite lässt, bleiben die SAN-spezifischen Lösungen. Was gibt uns nun die Garantie, dass die virtuellen Server ihre Leistung genauso erhalten wie VDI?
Ein bislang kaum beachtetes Feature bei vSphere ist das sogenannte Storage IO Control (SIOC), welches mit 4.1 eingeführt wurde (http://www.vmware.com/files/pdf/techpaper/VMW-Whats-New-vSphere41-Storage.pdf).
Dabei geht es um die Thematik, wie man Storage-IOs - also die Leistung, welche VMs aus dem SAN herausholen können - steuern und ggf. garantieren kann. Wenn dies in der Praxis überhaupt adressiert wurde, dann oftmals so, indem man dedizierte Diskgruppen direkt auf dem SAN konfiguriert hat. Dies zieht allerdings die Nachteile mit sich, dass das theoretische Maximum an Storage-IOs geringer wird und man weniger Diskkapazitäten zur Verfügung hat. Mit SIOC ist dieser Weg nicht mehr a priori notwendig. vSphere 4.1 erlaubt, die IOs pro VM zu steuern. Dadurch kann z.B. eingestellt werden, dass virtuelle Server mehr Storage-Leistung abrufen dürfen, als andere. Um dies zu ermöglichen, müssen zwei Voraussetzungen erfüllt werden:
1. Es braucht vSphere Enterprise Plus-Lizenzen für die ESX-Hosts. Es zeigt sich, dass immer wie mehr technische Features von Partnerherstellern und VMware selber (z.B. Distributed vSwitches, Antivirenlösungen, welche auf VMSafe aufbauen, Host-Profiles) die höchste Lizenzierungsart bedingen. Dies ist auch für SIOC der Fall.
2. Das SAN muss SIOC unterstützen. Die Unterstützung an sich ist oftmals nicht das Problem, sondern die notwendigen Firmware-Updates, die sich durch die ganze Storage-Fabric durchziehen und damit die Planung von Wartungsfenster bedingen.
 
Sind die Voraussetzungen geschaffen, kann pro Datastore Storage IO Control eingeschaltet werden. Der ESXi/ESX-Host beginnt danach die Latenzzeit zu überwachen. Überschreitet die Latenzzeit den einstellbaren Grenzwert, gilt der Datastore als gesättigt, sodass alle darauf liegende VMs im Verhältnis zu den pro VM einstellbaren Storage-Shares (default: 1000) versorgt werden. Weniger hoch zu priorisierende VMs können dabei zusätzlich noch mit einem IO-Maximumwert limitiert werden. Um zu veranschaulichen, wie SIOC funktioniert, hat VMware einen Film auf YouTube bereitgestellt:
http://www.youtube.com/watch?v=nTKdKhmP5KE&feature=player_embedded
 
Fazit: Ressourcen zu teilen, ohne dass die Verbraucher merken, dass diese nur im begrenzten Masse zur Verfügung stehen, ist eine der wichtigsten, aber oftmals unbewusst durchgeführten Aufgaben von IT-Admins. Hat man chronisch zu wenig Ressourcen, bleibt einem nichts anderes übrig, als diese aufzustocken. In den anderen Fällen kann ab vSphere 4.1 Storage IO Control helfen, die Ressourcensteuerung auch auf Storage-IO-Ebene vorzunehmen. Durch das, dass bei VDI SIOC direkt mitbeinhaltet ist - dank den Enterprise Plus-Lizenzen in den VMware View-Bundles - wird zusätzlich auch das Budget geschont.