Vor einigen Jahren hatte ich auf der EMC World die Gelegenheit, Chuck Hollis und einige andere VMware-Mitarbeiter zu treffen, um über ihre Idee zu sprechen. Sie wollten ungenutzte lokale Speicherressourcen innerhalb eines ESX-Hosts verwenden. Anstatt nur das ESX-Boot-Image darauf zu speichern, wollten sie die Ressource für virtuelle Maschinen im gesamten ESX-Cluster nutzbar machen. Wir diskutierten über ein scheinbar geclustertes Dateisystem, das Daten über ESX-Hosts hinweg schützen könnte. Ich merkte an, dass herkömmliche Festplatten langsam sind, und sie sprachen über den Einsatz von SSDs zur Beschleunigung der E/A-Operationen. Es war eine interessante Idee, und ich war gespannt, ob daraus jemals etwas werden würde. Wie Sie vielleicht schon vermutet haben, ist daraus etwas geworden: Virtual SAN. Die erste Version von VSAN hat mich zwar interessiert, aber ehrlich gesagt etwas enttäuscht. Nun, ein Jahr nach der allgemeinen Verfügbarkeit, hat VSAN mit dem neuesten Update auf VSAN 6.0 einen großen Sprung nach vorn gemacht.
Natürlich ist VSAN 6.0 besser, schneller und größer. In Übereinstimmung mit vSphere 6.0 können VMDKs bis zu 62 TB groß sein und bis zu 64 Hosts im Cluster haben. Die Anzahl der virtuellen Maschinen auf einem Knoten hat sich von 100 auf 200 verdoppelt, mit einem Maximum von 6,400 pro Cluster. Mehr Knoten bedeuten mehr Kapazität und mehr Leistung. Durch die Verwendung von 4-TB-Laufwerken liegt die Grenze bei etwa 9 Petabyte Rohkapazität.
VSAN 6.0 führt ein neues speicherrichtlinienbasiertes Verwaltungsmodell ein, das Richtlinien auf VM-Ebene und nicht auf dem gesamten Datenspeicher ermöglicht. Dadurch kann jede VM ihre eigenen Einstellungen für Dinge wie Verfügbarkeit, Leistung und Thin Provisioning haben. Dies sind dynamische Einstellungen. Wenn eine VM also plötzlich zusätzlichen Schutz benötigt, passt sich das VSAN an. Im Vergleich zu früheren Versionen ist dieser neue Ansatz viel einfacher und ermöglicht eine detailliertere Steuerung.
In der Vergangenheit wurde VSAN in einer Hybridkonfiguration mit herkömmlichen Magnetlaufwerken als Kapazitätsspeicher und Flash als Lese-Cache zur Beschleunigung der Leistung betrieben. Um die höchste Leistung zu erzielen, wurde eine All-Flash-Konfiguration eingeführt. Um die Kosten dieser Option niedrig zu halten, übernimmt ein kostengünstiges MLC-Laufwerk die Rolle der Kapazität. VSAN erfordert weiterhin eine Caching-Ebene, jedoch nicht aus Leistungsgründen. Stattdessen geht es darum, die Schreiblast auf der Kapazitätsschicht zu minimieren und deren Lebensdauer zu verlängern. Es ist wichtig, den Schreibcharakter der Arbeitslast zu berücksichtigen.

Um den Nutzen von Blade-Servern zu verbessern, verfügt VSAN 6.0 jetzt über eine High-Density-Direct-Attached-Storage-Option. Ich halte dies nicht für eine gute Option, da VMware immer noch empfiehlt, dass alle Server in einem VSAN-Cluster die gleiche Speicherkonfiguration haben. Die Verwendung so vieler externer JBOD-Gehäuse beansprucht eine beträchtliche Menge an Platz im Blade-Chassis, sodass dies eine sehr teure Lösung sein könnte.

VSAN 6.0 ist jetzt Rack-fähig. Durch die Erstellung von Fehlerdomänen, die mindestens drei Racks darstellen, wird VSAN intelligent genug, um Daten über diese Racks zu verteilen. Dies trägt zum Schutz vor Stromausfällen, Problemen mit dem Speichercontroller und Netzwerkausfällen bei.
Was ist die nächste Schlagzeile? Könnte die nächste Version von VSAN in Verbindung mit einem externen Speicherarray verwendet werden? Tatsächlich hat Chuck Hollis vor mehr als einem Jahr in seinem Blog darüber gesprochen. Wird der nächste Schritt, da wir nun über eine erweiterte Fehlerdomäne verfügen, ein erweiterter VSAN-Cluster sein? Ich kann mir eine Zukunft vorstellen, in der VSAN zur Vereinfachung der Notfallwiederherstellung auf vCloud Air ausgeweitet wird. In VSAN 6.0 fehlt jegliche Art von Datenreduktionstechnologie und anderen fortschrittlichen Datendiensten. Die jüngsten Entwicklungen bei VSAN 6.0 machen deutlich, dass VMware stark in die Technologie investiert. Ich freue mich darauf, was die nächste Veröffentlichung bringen wird.
Über den Autor
Mark May ist Storage-Ingenieur in Cincinnati, Ohio. Er arbeitet seit über 15 Jahren im Bereich Enterprise Storage und Backup. Er ist EMC Elect, Cisco Champion und begeisterter Technologieexperte. In seiner Freizeit hilft er anderen gerne dabei, die Feinheiten der sich ständig wandelnden Storage-Branche zu verstehen. Man findet ihn online an verschiedenen Stellen, am ehesten jedoch auf seinem persönlichen Blog und auf Twitter unter @cincystorage.




Amazon