VMware vSAN vs. Microsoft Storage Spaces Direct

Die herkömmliche Topologie eines virtualisierten Rechenzentrums sieht einen zentralen Storage vor, auf den mehrere Hosts zugreifen, die selbst nur Betriebssystem-Festplatten beinhalten oder gar von USB-Sticks oder vom zentralen SAN-Storage booten. Je nach Budget und Bedeutung verfügt der zentrale Storage über eine eingebaute Redundanz oder sogar Georedundanz. Marktübliche Serversysteme, die meistens als Virtualisierungs-Hosts dienen, haben jedoch den lokalen Festplattenspeicher nach wie vor fest in ihrem Design verankert. In den frühen Jahren der Virtualisierung kamen häufig Server als Virtualisierungs-Hosts zum Einsatz, die ursprünglich für einen anderen Zweck angeschafft worden waren und über große lokale Festplatten-Arrays verfügten.

Aus diesen Umständen ist bereits früh im Virtualisierungszeitalter die Idee entstanden, lokale Festplatten der Hosts als Storage für die VMs zu nutzen, ohne auf die Mobilität und Hochverfügbarkeit der VMs verzichten zu müssen. Die ersten Versuche wie die vSphere-Storage-Appliance von VMware oder die Virtual-Storage-Appliance von HP gingen in die gleiche Richtung: Auf jedem Host lief eine Storage-VM, deren Festplatten in den lokalen Datastores lagen. Die VMs bildeten einen Cluster und glichen die Festplatteninhalte über das Netzwerk ab. Der resultierende Speicherpool wurde an die Hosts mit Standardprotokollen wie iSCSI oder NFS zurückpräsentiert.

Die ersten Gehversuche zeigten allerdings schnell, dass der hohe Protokoll-Overhead und die meist eigenständige, vom Hypervisor entkoppelte Verwaltung der virtuellen Storage-Appliances die erhofften Vorteile wieder zunichtemachen. Um dem Konzept zum Erfolg zu verhelfen, mussten der Storage und der Hypervisor also enger zusammenrücken. Das hyperkonvergente Storage- und Virtualisierungscluster war geboren.

So funktioniert der hyperkonvergente Storage

In hyperkonvergenten

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.