VMware vSAN vs. Microsoft Storage Spaces Direct

Zwei Wege, ein Ziel

Hyperkonvergente Infrastrukturen und Software-definierte Rechenzentren haben den Hype-Zyklus passiert und mittlerweile einen festen Platz in Unternehmen eingenommen. Es ist daher logisch, dass die beiden größten Virtualisierungshersteller VMware und Microsoft mit eigenen hyperkonvergenten Angeboten um Kunden buhlen. Wir stellen VMware vSAN und Microsoft Storage Spaces Direct gegenüber und bieten eine Orientierungshilfe im Feature- und Lizenzdschungel.
Die Datenmengen in Unternehmen wachsen unaufhaltsam. Zunehmend wichtig wird daher das intelligente Aufbewahren und Bereitstellen der Informationen. Im Juni-Heft ... (mehr)

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021