vSAN 8 Update 2 – Neuerungen auf technischer Ebene

Anfang des Monats hatte ich die Gelegenheit, am VMware Exclusive Blogger Early Access Program teilzunehmen. Hier teilen VMware-Experten Neuigkeiten und kommende Funktionen für Produkte vor dem eigentlichen Veröffentlichungsdatum.
Ich möchte an dieser Stelle Pete Kohler und John Nicholson für das Feature-Briefing zum Release von vSAN 8 Update 2 danken. Mein weiterer Dank gilt Heather Haley vom globalen Kommunikationsteam von VMware und Corey Romero für die Unterstützung bei der Umsetzung.

[Dieser Blogpost unterlag einer Sperre bis zum 22. August 5:00 PDT (14:00 CEST)]

VMware vSAN 8 Update 2 bietet eine Reihe von neuen Funktionen und Verbesserungen in Bezug auf Flexibilität, Leistung und Benutzerfreundlichkeit.

Neue ESA Features auf einen Blick

  • vSAN ESA storage-only Cluster mit vSAN Max
  • VMware Cloud Foundation Support für vSAN ESA in VCF 5.1
  • vSAN File Services ab sofort auch in vSAN ESA verfügbar
  • Neue ESA Ready Node Konfigurationen für kleine Umgebungen
  • Unterstützung für eine neue Klasse leseintensiver Speichergeräte
  • Automatische korrektur der Speicherrrichtlinien
  • ESA Prescriptive Device Claim
  • Verbesserungen bei Stretched- and 2-Knoten-Clustern
  • Bis zu 500 VMs pro Host (im Vergleich zu bisher 200)

vSAN Max

Source: VMware

Eine der wichtigsten neuen Funktionen in vSAN 8 Update 2 ist die Möglichkeit, Rechen- und Speicherfunktionen vollständig zu trennen, indem reine Storage-Cluster erstellt werden. Diese Funktion wird vSAN Max genannt. Jetzt werdet Ihr vielleicht sagen: “Hey, Moment mal! Haben wir das nicht schon mit vSAN Mesh gemacht?” Die Antwort ist ‘ja’ und ‘nein’. Das Prinzip ist in der Tat ähnlich. Man baut einen vSAN-Cluster mit einer großen Speicherkapazität auf und stellt den vSAN-Datenspeicher einem oder mehreren Client-Clustern zur Verfügung. Neu ist, dass es nun reine Rechencluster (compute-only) ohne lokale Festplattengeräte und reine Speichercluster (storage-only) ohne Produktions-VMs geben kann. Neu ist auch, dass vSAN Max von vSAN-Clustern und vSphere-Clustern(!) genutzt werden kann. Diese so genannten compute-only vSphere-Cluster verfügen über ein Minimum an vSAN-Funktionalität, die es ihnen ermöglicht, vSAN Max-Speicher zu nutzen. Zum Einbinden eines vSAN Max-Datenspeichers ist kein Legacy-Protokoll wie z.B. iSCSI oder NFS erforderlich.

Configure vSAN Compute Cluster
Source: VMware

Ein vSAN Max ist ein dedizierter Speichercluster, der eine einseitige oder eine gestreckte (stretched) Konfiguration haben kann. Bei der Erstellung eines neuen Clusters stehen 3 Optionen zur Auswahl:

  1. vSAN HCI – Das ist ein herkömmlicher vSAN Cluster
  2. vSAN Compute Cluster – A vSphere-Cluster mit einem Minimum an vSAN-Funktionalität, um vSAN-Max Datenspeicher zu konsumieren.
  3. vSAN Max – Ein reiner Speichercluster, der selbst keine VMs betreibt.
New vSAN Cluster Options
Source: VMware

vSAN Max Lizensierung

Bestehende vSAN-Editionen (Standard, Advanced, Enterprise) werden kein vSAN Max umfassen. Es wird ein neues Lizenzierungsmodell pro TiB (240 Byte) geben, welches auf Speicherkapazität und nicht auf Hosts oder Sockets basiert.

vSAN Max Spezifikationen, Anforderungen und Einschränkungen

  • Minimum 6 Knoten pro Cluster mit mindestens 150 TiB pro Knoten
  • bis zu 360 TB pro Knoten
  • bis zu 24 Knoten pro Cluster
  • bis zu 8.6 PB Kapazität pro Cluster
  • nur ESA – OSA wird nicht unterstützt
  • vSAN Max zertifizierte ReadyNodes sind erforderlich
  • nur Greenfield Bereitstellungen – es gibt keinen Migrationspfad von anderen vSAN-Versionen
  • single sided oder stretched Cluster

vSAN Max Anwendungsszenarien

“Warum sollte ich dieses neue Angebot in Betracht ziehen?”

Der häufigste Anwendungsfall sind wohl die Lizenzbedingungen von Drittanbietern, bei der die Zahl der CPU-Sockel-Lizenzen so gering wie möglich gehalten werden soll, während gleichzeitig die Anwendung eine große Datenspeicherkapazität benötigt. Bei einem Standard vSAN-Ansatz müsste die Anzahl der Hosts skaliert werden, um die benötigte Speicherkapazität zu erhalten. Dadurch steigen die Anzahl der Sockets und damit die Lizenzkosten für Drittanbieter.
Ein zweiter Anwendungsfall könnten Einschränkungen beim Formfaktor sein, wenn die Anzahl der möglichen Festplattengeräte pro Host sehr begrenzt ist. In diesem Fall bietet sich die Verwendung von vSAN Max als primärer Speicher für Blade-Systeme an.
Darüber hinaus lässt sich vSAN Max auch als zentrale Shared-Storage-Lösung für das gesamte Rechenzentrum nutzen. Durch schrittweises Hinzufügen weiterer Knoten zu vSAN Max lässt sich ein solcher zentraler Datenspeicher problemlos skalieren, ohne dass man sich um die Lizenzierung von Hosts oder Sockets kümmern muss. Das Lizenzierungsmodell richtet sich nach der Kapazität.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert