Glanz und blinde Flecken im VMware Virtual SAN

Eigenheiten, Performance und Stabilität bei VMware vSAN

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Autor Thomas Drilling schaut sich VMware vSAN genau an und findet Hervorragendes, Komplexes und ein paar schadhafte Stellen.
Autor Thomas Drilling schaut sich VMware vSAN genau an und findet Hervorragendes, Komplexes und ein paar schadhafte Stellen. (Bild: © savfoto - stock.adob.com/ VMware)

Der Aufbau einer hyperkonvergenten IT-Umgebung gilt als komplexer, zeitaufwändiger und fehlerbehafteter Prozess. VMware stellt zwar mit „Virtual SAN“ eine leistungsfähige Software bereit, Objekt-Speicher für Virtual-Maschine-Workloads auf Enterprise-Level zu realisieren, ohne die passende Hardware bleiben die Chancen aber oft ungenutzt. So genannte vSAN-Ready-Nodes wie „Fujitsu Primeflex for VMware Virtual SAN“ können dazu entscheidend beitragen, die Performance zu verbessern.

VMware vSAN ist eine hyperkonvergente, softwaredefinierte Speicherplattform, die vollständig mit „VMware vSphere“ integriert ist. vSAN aggregiert lokal angehängte Festplatten von Hosts, die Mitglieder eines vSphere-Cluster sind, erstellt daraus eine verteilte, gemeinsam nutzbare Speicherlösung und ermöglicht ein schnelles Bereitstellen von Speicher innerhalb von VMware vCenter unmittelbar im Kontext der Erstellung und Bereitstellung virtueller Maschinen.

Zudem war vSAN das erste richtliniengesteuerte Speicherprodukt, das explizit für vSphere-Umgebungen entwickelt wurde. Im Rahmen der richtlinienbasierten Speicherverwaltung, gleicht vSAN kontinuierlich die Anforderungen virtueller Maschinen automatisch und dynamisch mit den zugrundeliegenden Speicherressourcen über das dedizierte vSAN-Netzwerk ab, was die Speicherbreitstellung und Verwaltung im Vergleich zu konventionellen Lösungen entscheidend vereinfacht.

VMware erobert den HCI-Markt

Beim Start der hyperkonvergenter Plattform von VMware im Jahr 2014 und war vSAN im Prinzip schon ein Nachzügler im seinerseits noch jungen HCI-Markt. Die damaligen und heutigen Marktführer Nutanix sowie Simplivity wurden 2009 gegründet, so dass der HCI-Markt beim Erscheinen von vSAN bereits von diesen Unternehmen dominiert wurde, inzwischen flankiert von dutzenden anderer Player, darunter auch „HPE-VSA“ (Lefthand), „Starwind“, „Datacore Hyperconverged Virtual SAN“ und Dell-EMC.

Für VMware gab es aber gute Gründe, in diesen Markt zu investieren. Trotz oder gerade wegen der Vielfalt und des Wettbewerbs in diesem Bereich war und ist HCI wohl der am schnellsten wachsende Speichermarkt. Dabei konzentrieren sich die HCI-Anbieter oft in erster Linie auf die Benutzerfreundlichkeit, damit kein dedizierter Speicheradministrator mehr benötigt wird und das Virtualisierungsteam die Kontrolle über den Speicher bekommt.

Dank des globalen Verkaufsapparats von VMware wurde vSAN nämlich trotz der etwas verspäteten Teilnahme an der HCI-Party von Kunden gut angenommen, dass VMware spätestens seit der vSAN-Version 6.5 hinsichtlich der gebotenen Funktonalität in Summe mit den anderen Akteuren gleichgezogen ist. Wohlbemerkt in Summe; denn vSAN bietet beziehungsweise erfüllt unter dem Strich zwar alle kritischen HCI-Merkmale, allerdings hinkt der Ansatz von VMware an einigen Stellen hinterherhinkt, stiehlt den Konkurrenten dafür aber in anderen Bereichen durchaus die Schau.

Die Besonderheit von VMware vSAN

Gemein hat VMware vSAN mit den anderen Herstellern neben dem HCI-Ansatz (das heißt lokale Speichergeräte in den ESXi-Hosts werden als Shared Storage für VMs verfügbar gemacht), das Software-Defined-Storage-Konzept. Die eigentliche Intelligenz des Speichers wird hierbei nicht durch Hardware, zum Beispiel RAID-Controller, erbracht, sondern durch einen Speichervirtualisierer.

Hierin liegt bei vSAN der entscheidende Unterschied zu Nutanix & Co; denn was lag für den Erfinder der software-basierten Compute-Virtualisierung näher, als sich auch an einem Speichervirtualisierer zu versuchen und diesen direkt in den Kernel zu verlagern? Zudem hat VMware mit „NSX“ im Bereich Netzwerkvirtualisierung ja seit geraumer Zeit ebenfalls einen tollen Lauf.

vSAN soll nicht als Virtual Storage Appliance (VSA) verstanden werden.
vSAN soll nicht als Virtual Storage Appliance (VSA) verstanden werden. (Bild: Thomas Drilling/ VMware)

Während alle anderen Hersteller eine Art Kontroll-VM bemühen, um lokalen Speicher der „ESXi“-Host über den in der VMs arbeitenden Speichervirtualisierer zu einem Speicherpool zu aggregieren, aus dem dann wieder virtuelle Disks „heraus geschnitzt“ und mehr oder weniger „klassisch“ auf den Hosts als LUNs präsentiert werden, geht VMware einen anderen Weg. Bei vSAN steht neben dem Kernel-basierten Storage-Virtualisierer der Host-Cluster im Zentrum des Konzeptes.

VMware umschreibt das so: „ vSAN fasst lokale oder direkt angeschlossene Kapazitätsgeräte eines ESXi-Host-Cluster zusammen und erstellt einen einzelnen Speicherpool, der von allen Hosts im vSAN-Cluster verwendet wird. Insofern ist vSAN in der Tat „keine“ Virtual Storage Appliance (VSA), wie VMware gerne mit Nachdruck betont.

Der Cluster im Mittelpunkt

Ein vSAN präsentiert also keine Block-Geräte (LUNs) auf Basis vom Speichervirtualisierer verwalteter virtueller Disks, sondern faßt alle lokalen Speichergeräte im Host-Cluster (der damit gleichzeitig als Storage-Cluster fungiert) zu einem Speicherpool zusammen, der ohne Anlegen etwaiger Dateisysteme direkt und nativ von VM-Objekten, wie VMDKs und VMX-Dateien genutzt wird. Das zugehörige logische Datastore-Objekt „vsan Datastore“ wird beim Erstellen des vSAN-Cluster automatisch erstellt.

Das Cluster-Konzept sorgt neben der vertikalen vor allem für eine einfache horizontale Skalierbarkeit des Speicher-Clusters und das Drei-Knoten-Konzept für die Minimal-Konfiguration kümmert sich um Ausfallsicherheit und Selbstheilungsfähigkeit. Dazu erstellt vSAN von jedem VMDK-Objekt per Default immer eine Replik. Von Haus aus realisiert also der Speichervirtualisierer von vSAN eine Art RAID1, was die Kapazitätsbetrachtung anbelangt.

Verfügt man über vier oder mehr Hosts im vSAN-Cluster und eine „Advanced“-Lizenz, kann man ab vSAN 6.2 auch RAID 5/6 mit einfachen oder doppelten Paritätsschutz als Failure-Tolerate-Policy verwenden. In diesem Sinne ist ein vSAN-Cluster eher mit „Ceph“-Storage vergleichbar und besitzt Eigenschaften eines Objektspeichers.

Hierbei ist es aber nicht so, dass ein ESXi-Host in einem Drei-Knoten- Cluster immer als Witness fungiert. Viele mehr ist für jedes einzelne VM-Objekt (VMKK, vSwap-Datei und mehr) die Platzierung als Original, Replik oder Witness eine Andere. Insofern ermöglich das vSAN-Konzept in einzigartiger Weise die Umsetzung von Speicherrichtlinien, der Dritten neben „SDN“ und „HCI“ für vSAN charakteristischen Eigenschaft.

Policy-Based Storage-Management (PBSM) setzt das Vorhandensein eines Storage-Providers voraus.
Policy-Based Storage-Management (PBSM) setzt das Vorhandensein eines Storage-Providers voraus. (Bild: Thomas Drilling/ VMware)

Policy-Based-Storage-Management

Mit Speicherrichtlinien können vSphere-Admins grob gesagt dafür sorgen, dass ein natives Virtual-Machine-Object stets auf einem Datastore zu liegen kommt, dessen Eigenschaften mit der der VM angehängten Speicherrichtlinie kompatibel sind. Richtig komfortabel funktioniert das allerdings nur, wenn der Storage „VMware vStorage APIs for Storage Awareness“ (VASA) unterstützt.

VVOL-Support erfordert mindestens VASA 2.0; aktuell gibt es VASA 3.0 für VVOLs v2.
VVOL-Support erfordert mindestens VASA 2.0; aktuell gibt es VASA 3.0 für VVOLs v2. (Bild: Thomas Drilling/VMwre)

VMware differenziert bei den unterstützten Speichertechnologien strickt zwischen „traditionell“ und „SDN“, wobei das SDN-Konzepte von VMware (VSAN und VVOLs) dazu einen solchen Satz von Anwendungsprogrammierschnittstellen (APIs) benötigen, der es einem vCenter ermöglicht, die Fähigkeiten des Speicher-Arrays zu erkennen oder dem Speichergerät die Möglichkeit gibt, seine Fähigkeiten zu präsentieren sowie die Anforderungen der ESXi-Seite „umzusetzen“.

Policy-Based Storage-Management (PBSM) setzt das Vorhandensein eines Storage-Providers voraus, der vom Storage-Hersteller geliefert wird und der die Kommunikation über die VASA-API erlaubt. Bei vSAN liefert VMware die betreffende Software selbst mit.

Bei der mitgelieferten Stand-vSAN-Policy ist etwa der Standard-Wert für die Anzahl der zu tolerierenden Fehler (Primary level of failueres to tolerate) =1.
Bei der mitgelieferten Stand-vSAN-Policy ist etwa der Standard-Wert für die Anzahl der zu tolerierenden Fehler (Primary level of failueres to tolerate) =1. (Bild: Zhomas Drilling/ VMware)

Was ist drin?

Da vSAN eine bidirektionale Kommunikation zwischen Storage und „vCenter“ voraussetzt, bedarf es bei vSAN mindestens der VASA-Spezifikation 1.5, die anlässlich der Veröffentlichung der ersten VSAN-Version 5.5 im Jahr 2014 ebenfalls freigegeben wurde. Storage-Provider für VVOLs dagegen muss der Storage-Hersteller liefern. VVOL-Support erfordert mindestens VASA 2.0; aktuell ist VASA 3.0 für VVOLs v2. Die entsprechende Software klinkt sich im Abschnitt „Speicheranbieter“ der vCenter-Konfiguration in das System ein.

Die Möglichkeiten, die das richtlinienbasierte Speicher-Management bietet, variieren also bei VVOLs von Hersteller zu Hersteller, während sie bei vSAN immer gleich sind, wenngleich von Version zu Version neue Möglichkeiten dazu kommen. Bei vSAN lassen sich alle unterstützten Richtlinientypen einer der Kategorien „Capacity“, „Availability“ oder „Performance“ zuordnen, oder sie „beeinflussen“ diese Attribute.

Bei der mitgelieferten Stand-vSAN-Policy ist zum Beispiel der Standard-Wert für die Anzahl der zu tolerierenden Fehler (Primary level of failueres to tolerate) =1 . Die Regel bezieht sich auf den möglichen Ausfall eines ESXi-Hosts, einer Disk-Group oder einer Disk. VSAN legt in diesem Fall eine zusätzliche Replik etwa des VMDK-Objektes an. Die Regel gehört in die Kategorie „Availability“ tangiert aber auch den Bereich „Capacity“.

Einsatz im Cluster

Das gilt jedenfalls dann, wenn das vSAN wie in der Default-Einstellung im RAID1-Modus arbeitet. Ändern lässt sich dies gegebenenfalls mit der vSAN-Policy „failure tolerance method“. „RAID 5 und 6 (Erasure Encoding) lässt sich allerdings nur einstellen, wenn man über eine „Advanced“-Lizenz verfügt.

Ebenfalls per Default 1 ist die Voreinstellung für „Number of disk stripes per object“, eine Regel die dem Bereich „Performance“ zuzuordnen ist und darüber entscheidet, auf wie viel Spindeln das jeweilige Onjekt effektiv „ge-stripe-ed“ wird. Ein höherer Wert führt zwar zu einer besseren Performance, verursacht aber auch eine höhere Usage von System Ressourcen (siehe: unten). Der mögliche Maximalwert ist 12 und hängt in der Praxis von der vorhandenen Zahl an Spindeln im Cluster ab.

Wenn ein Administrator über eine wenn man über eine „Advanced“-Lizenz verfügt, kann er auch „RAID 5 und 6 (Erasure Encoding) einstellen.
Wenn ein Administrator über eine wenn man über eine „Advanced“-Lizenz verfügt, kann er auch „RAID 5 und 6 (Erasure Encoding) einstellen. (Bild: Thomas Drilling/ VMware)

Auch die Regel „Flash read cache reservation (%)“ betrifft die „Performance“-Kategorie. Jeder vSAN-Knoten muss nämlich über mindestens eine SSD verfügen, die nicht zur Kapazität des vSAN-Clusters beiträgt, sondern allein zu Cache-Zwecken verwendet wird. Diese „Beschleuniger“-SSD muss rechnerisch mindestens 10 Prozent des gesamten Kapazität-Tiers abdecken.

Enterprise vSAN-Anwender nutzen heute aber in der Regel ohnehin All-Flash-Konfigurationen, die dann auch Features wie Depup und Kompression bieten. Bei der „Flash-Reservierung“ ist Voreinstellung 0 und der Maximalwert 100 Prozent, wobei vSAN hier angegebene Flash-Kapazität als Read-Cache für das ausgewählte VMDK-Objekt reserviert, prozentual zur logischen Größe der VMDK-Datei.

Zusatzfunktionen in der Enterprise-Edition

Jedoch steht hier reservierte Kapazität dann anderen Objekten nicht mehr zur Verfügung, daher die Voreinstellung, denn Objektspezifische Regel nutzt vSAN per Default 70 Prozent der vorhandenen Cache-SSD als Read Cache und zu 30 Prozent als Schreib-Cache. Bei einer All-Flash-Konfiguration wird die Regel nicht unterstützt.

Der Wert bei „Force provisioning seht per Default auf „No“. Mit „Yes“ würde das betreffende VM-Objekt auch dann provisioniert, wenn die Einstellungen in “Number of failures to tolerate”, “Number of disk stripes per object” oder “Flash read cache reservation” verletzt würde. Normalerweise überwacht vSAN aber kontinuierlich, dass die im Storage-Profil definierten Werte eingehalten werden. Beim Überschreiten eines Schwellwertes konfiguriert vSAN die betroffenen Datenbereiche der VM automatisch neu.

So sorgt „IOPS limit for object“ für die gewünschte Limitierung der IOPS für das betreffende Objekt. Die Berechnung basiert auf einer Default Base Size von 32 Kilobyte, das heißt: Ein 64-KB-I/O repräsentiert zwei I/O-Operationen, wobei bei der Kalkulation Read und Write äquivalent behandelt, Cache-Treffer aber nicht berücksichtigt werden. Überschreitet eine Disk den angegebenen Grenzwert, wird sie von vSAN automatisch „gedrosselt“. Diese Funktion wird allerdings nur in der Enterprise-Version unterstützt.

Das richtige Design

Ebenfalls auf der Haben-Seite von VMware Virtual SAN steht die extrem einfache Inbetriebnahme. Das vSAN-Kernel-Modul ist im ESXi-Kernel standardmäßig enthalten und muss nur über die vSAN-Lizenz lizenziert werden. Danach muss der Anwender lediglich auf jeden Host, der Mitglied des vSAN-Cluster werden soll, mindestens einen VM-Kernel-Adapter für den vSAN-Replikations-Traffic anlegen und schließlich das vSAN-Feature im Cluster aktivieren oder ein neues Cluster-Objekt für vSAN erzeugen und die gewünschten Hosts hineinziehen.

Stellt man das „Disk-Claiming“ auf Automatik (Default) schaut der vSAN-Konfigurations-Assistent, welche lokalen Disks für vSAN verwendet werden können und weist diese zu. Ist das erledigt, erhält der Admin automatisiert ein vSAN-Datastore-Objekt und die vSAN-Default-Storage-Policy.

Licht und Schatten von vSAN

Alles eitel Sonnenschein also? Nein. Wer die Berichterstattung um vSAN von der ersten Version 5.5 im Jahr 2014 bis vSAN 6.6 2017 verfolgt, stößt bei den frühen Versionen immer wieder auf Stabilitäts- und auch bei aktuellen Versionen mitunter auf Performance-Probleme. Hinzu kommt dass sich vSAN - ursprünglich geplant als Mid-Range-Storage für Branch-Offices in kleinen Unternehmen - von Version zu Version immer mehr zum Enterprise-Storage entwickelt hat, der sukzessive mehr Features erhalten hat, die ebenfalls sinnvoll konfiguriert sein wollen.

Zwar funktioniert eine einfache Basis-Konfiguration mit einem Drei-plus-x-Knoten-Cluster immer noch weitgehend automatisch, wer aber optimal vom PBSM profitieren und zudem die optimale Performance aus vSAN herauskitzeln will, muss aber peinlich genau auf die verwendete Hardware achten und beispielsweise auch das unterliegende Netzwerk-Design für den vSAN-Replikations-Traffic optimieren.

vSAN-Knoten kommunizieren im vSAN-Cluster über einen korrekt konfigurierten Multicast-Mode auf den physischen Switch - ab der Version 6.6 unterstützt vSAN auch Unicast - sozusagen permanent - miteinander und lagern fortwährend Objekt um, was mit ein prinzipbedingter Grund für die erzielbare Performance ist, die vSAN durch die zwingend zu verwendenden Cache-SSDs positiv zu beeinflussen sucht.

VMware stellt vSAN-Ready-Node-Spezifikationen zur Verfügung, damit Kunden die passende Hardware finden können.
VMware stellt vSAN-Ready-Node-Spezifikationen zur Verfügung, damit Kunden die passende Hardware finden können. (Bild: VMware)

Heikler Punkt: die Hardware

So kann es bei vSAN bei unpassenden Hardware-Komponenten oder nicht optimaler Detail-Konfiguration durchaus sein, dass die erzielte Performance nicht den Erwartungen entspricht. Ein Grund dafür ist, dass vSAN von vorne herein dazu konzipiert ist, als verteilter (Shared) Storage für ein gesamtes Host-Cluster zu arbeiten, auch wenn man inzwischen auch bei vSAN iSCSI-Targets einrichten und nach „außen präsentieren kann.

Wer daher gemäß traditioneller Denkweise mit LUN-basierten VMFS-datastored meint die Performance etwa dadurch verbessern zu können, möglichst wenige VMs mit ähnlicher Workload-Charakteristik oder gar nur eine VM im vSAN-Datastore zu nutzen, ist auf dem Holzweg. Möchte man vSAN für eine kleinere Anzahl genutzter VMs optimieren, ist es eher zu empfehlen, die Striping-Policy auf eine höhere Anzahl Spindeln zu stellen, um eine höhere Performance zu er zielen (siehe oben).

Performance Probleme mit vSAN

VSAN steht auch - vor allem bei den frühen Versionen - in dem Ruf, unzuverlässig zu sein, was allerdings im Detail häufig auf Treiber- und Firmware-Probleme zurück zu führen ist. Bei vSAN ist es - auch wenn der inzwischen eingebaute Kompatibilitätscheck, sowie der Health-Check überwiegend „grünes Licht“ geben - zwingend erforderlich, dass sämtliche Komponenten auf VMware Hardware-Kompatibilitätsliste stehen.

In VMware vSAN gibt es einen eingebauten Kompatibilitätscheck.
In VMware vSAN gibt es einen eingebauten Kompatibilitätscheck. (Bild: Thomas Drilling/ VMware)

Nur wenn sämtliche Komponenten eines vSAN-Setups ausnahmslos auf der HCL stehen, ist eine gute vSAN-Performance möglich, einschließlich der Firmware, denn VMware Kompatibilitätsliste adressiert für Hardware-Komponenten nicht nur Treiber, sondern auch die Firmware. Doch selbst wenn wirklich alle Komponenten auf der HCL stehen kann es noch zu Performance-Problemen kommen, etwa wenn die ausgesuchte Hardware nicht zum Design oder Workload passt.

Dazu müssen Administratoren wissen, wie und wo die Hardware die vSAN-Performance beeinflusst. Vier magnetische Kapazitäts-Disks mit je 10.000 RPM bringen bei vSAN mehr Performance als ein 4-Terabyte-Laufwerk mit 7.200 RPM. VMware betont im „vSAN-Design&Sizing-Guide“ selbst, dass die Verwendung von Low-End-Komponenten zu Performance-Problemen führt, auch wenn die Argumentationsstrategie für vSAN ausdrücklich die Verwendbarkeit von Commodity-Hardware anführt, etwa im Vergleich zum Austausch-Festplatten in Enterprise-SAN-Arrays.

Darüber hinaus ist die Auswahl der Platten oder besser SSDs nur ein Punkt im vSAN-Design, der Einfluss auf die Performance hat. Auch die Auswahl der physischen Switche und Netzwerk-Adapter, sowie das Design des VSAN-Netzwerks spielt eine wichtige Rolle.

vSAN-Ready-Nodes

Summa summarum ist der Aufbau einer hyper-konvergente Infrastruktur in Eigenregie ein komplexer Prozess, der nicht nur zeitaufwändig, sondern auch fehlerbehaftet ist. VMware selbst zielt aber aus gutem Grund nicht darauf ab, selbst zum Hardware-Hersteller zu mutieren, sieht man seit der Übernahme durch Dell mal von der „Dell EMC VxRail“-Appliance ab, unterstützt Hardware-Hersteller und Kunden aber mit seinen http://vsanreadynode.vmware.com/RN/RN vSAN-Ready-Node-Spezifikationen darin, die optimal passende vSAN-Abstimmung zu finden.

Noch weiter gehen vorgefertigte vSAN-Hardware-Appliances, wie sie inzwischen auch einige Hardware-Hersteller bieten, etwa die Thomas-Krenn AG.

VMware und Fujitsu

Auch der Server-Hersteller Fujitsu hat für ein schnelles Einrichten einer kompletten VMware vSAN-Umgebung ein breites Spektrum validierter Server-Konfigurationen („vSAN Ready Node“-Profile) mit vorinstallierter ESXi-Software im Portfolio, die in unmittelbar Zusammenarbeit mit VMware entwickelt wurden. Alle Konfigurationen erlauben eine über das Default-Setup hinausgehende Anpassung von vSAN an die individuellen Erfordernisse der zu speichernden Workloads. Allen gemein ist, dass die unterliegende Hardwareplattform „Primeflex“ auf Fujitsu x86-Servern basiert, die laut Aussage von Fujitsu zahlreiche Top-Positionen in den meisten VMware Benchmark-Kategorien aufweisen.

Fujitsu fungiert im Falle von VMware vSAN und Primeflex als zentrale Anlaufstelle für Hardware- und Software.
Fujitsu fungiert im Falle von VMware vSAN und Primeflex als zentrale Anlaufstelle für Hardware- und Software. (Bild: Fujitsu)

Mit einem Produkt wie „Primeflex for VMware vSAN“ profitieren IT-Unternehmen von einer deutlich schnelleren Bereitstellung für virtuelle Infrastrukturen in ihren Rechenzentren. Zudem ist Primeflex for VMware VSAN vollständig getestet und bietet Unternehmen die Möglichkeit, ihre Computing- und Storage-Umgebung auf granulare Weise vertikal oder horizontal (scale-up oder scale-out) auf maximal 64 Hosts für bis zu 6.400 VMs zu skalieren, eine Eigenschaft, die für ein vSAN charakteristisch ist.

Zum Vergrößern eines vSAN-Datastore genügt es, entweder eine (oder mehrere) Disk je Disk-Group - vSAN unterstützt von Haus aus bis zu fünf Disk-Groups pro Host mit je sieben Devices (1 SSD + 6 Kapazitäts-Disks) - hinzuzufügen oder den vSAN-Cluster durch Hinzufügen weitere Nodes horizontal zu skalieren.

Ein weiterer Vorteil für den Einsatz einer validierten Lösung a la Primeflex Virtual SAN besteht für Kunden darin, dass der Hersteller als zentrale Anlaufstelle für Hardware- und Software fungiert, was eine bessere Zusammenarbeit im Wartungsfall ermöglicht, die im Idealfall zu einer deutlich schnelleren Lösung von Problemen beiträgt.

Was meinen Sie zu diesem Thema?
Genau dann wird man mal sehen wie nutaNIX da stehen wird LOL. Mir ist es ein Rätzel warum dieses...  lesen
posted am 10.01.2018 um 12:10 von Unregistriert

Der Artikel ist doch von VMWare verfasst worden... bitte mal einen Performance-Vergleich vSAN und...  lesen
posted am 09.01.2018 um 11:55 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45075775 / SDDC- Fujitsu Content-Hub)

Weitere Informationen erhalten Sie in folgenden Themenbereichen:

Themenspecial: SDDC Themenbereich: Big Data Analytics Themenbereich: Data Management