2-Node VSAN Cluster aufbauen

Meinem letzten Artikel über Hyperconverged Storages kann man ja durchaus entnehmen, dass ich doch ein kleiner Fan solcher Technologien bin. (Jürgen würde jetzt wahrscheinlich wieder sagen, ich sei generell leicht zu begeistern 😀 )). Egal.

Ich möchte in diesem Artikel die 2-Node Cluster Thematik etwas beleuchten.

Es gibt des Öfteren die Anforderung auch in Branch Offices eine Serverinfrastruktur bereitzustellen. Aufgrund von Budgetdruck und anderen diversen Gründen weichen diese Branch Offices sehr oft von den eigentlichen Verfügbarkeitsanforderungen ab. Knackpunkt ist hier meist das Shared Storage, welches schlussendlich öfters nicht platziert wird.

Seit längerem liebäugel ich mit einer Hyperconverged Lösung für solche Standorte. Einfach Server mit lokalen Disks in die Niederlassung stellen und ein Distributed Storage aufbauen. Viele Lösungen benötigen dafür 3 Nodes und eine entsprechende Lizenzierung. Seit vSphere 6.0U2, bzw. VSAN 6.2 ist das jetzt aber anders. Es wurde ein 2-Node Cluster eingeführt, welcher durch eine dritte virtuelle Witness-Node ergänzt wird. Die Witness-Node kann dabei im HQ betrieben werden. Dh. das Setup sieht etwas anders aus:

vsan_2_node_cluster_topologyDie virtuelle Witness kommt als “Nested ESX”. Eine Lizenz wird dafür nicht benötigt.

Wo wir schon bei Lizenzierung sind: Der 2-Node Cluster kann mit jeder VSAN-Lizenz betrieben werden. Mehr Lizenz-Informationen gibt es im License-Guide.

Wie wird so ein Cluster konfiguriert?

Gleich vorab – es ist irgendwie erschreckend einfach 🙂

Im Cluster muss zunächst das VSAN Feature aktiviert werden:

VSAN_6.2_2_Node_Cluster-0012

In den FaultDomain Settings, wählen wir den 2-Node Cluster aus:

VSAN_6.2_2_Node_Cluster-0013

Die Nodes werden mit den verfügbaren VSAN aktivierten VMKernel-Interfaces aufgelistet:

VSAN_6.2_2_Node_Cluster-0014

Alle verfügbaren Disks der jeweiligen Hosts werden aufgelistet. Wir wählen aus, welche wir als Cache- bzw. Capacity-Disks verwenden wollen:

VSAN_6.2_2_Node_Cluster-0015

Wir müssen jetzt die Witness-Node auswählen. Virtuelle Witness-Nodes kommen als Virtuelle Appliance und sind eigentlich “Nested ESXi-Hosts”.

VSAN_6.2_2_Node_Cluster-0016

Die virtuelle Witness muss ebenfalls mit einer Disk-Group ausgestattet werden. Dafür stehen je eine emulierte SSD und eine HDD zur Verfügung. Der ESX-Host benötigt keinen SSD-Datastore.

VSAN_6.2_2_Node_Cluster-0017

Wir prüfen die Zusammenfassung und erstellen mit “Finish” unseren VSAN Cluster:

VSAN_6.2_2_Node_Cluster-0018

Das war seitens Basissetup schon alles. 🙂 Einen Überblick über unseren “2-Node Stretch-Cluster” gibt es hier:

VSAN_6.2_2_Node_Cluster-0019

Warnings beheben

Per Default ist der Performance Service nicht gestartet, wodurch eine Warnung im Monitoring auftaucht. Das sollten wir beheben:

VSAN_6.2_2_Node_Cluster-0020

Unter Cluster > Manage > Health and Performance gibt es die “Performance Service”-Section. Ein Klick auf “Edit” öffnet die umfangreichen Optionen :-). Dort einfach “Turn On” auswählen und das Fenster mit “OK” schließen. Der Dienst wird gestartet und die Warnung sollte sich von selbst erledigen (zur Sicherheit nochmal den “Retest”-Button betätigen).

VSAN_6.2_2_Node_Cluster-0021

VSAN_6.2_2_Node_Cluster-0022

VSAN_6.2_2_Node_Cluster-0023

VSAN_6.2_2_Node_Cluster-0024

Und das war es auch schon. Der Datastore steht ab sofort zur Verfügung:

VSAN_6.2_2_Node_Cluster-0025

Fast schon zu einfach, oder? 🙂

Wie man jetzt VMs auf diese Datastores bringt, kommt im nächsten Artikel. Dieser ist inzwischen erschienen und ist hier zu finden: VM Provisionierung im VSAN-Datastore

 

Bis dahin…

10 thoughts on “2-Node VSAN Cluster aufbauen”

  1. Hi,
    ich habe es nun auch geschafft unter ESXi 6.5 ein vSAN 2-Node Cluster zum laufen zu bringen. Dieser ist bisher so eingerichtet das alles über die onBoard 1 GB LAN Anschluß geht. Traffic zu den VMs, Management und vSAN. Das ist natürlich nicht so ideal. Daher würde ich gerne den vSAN Verkehr über 2 x 10 GB Lankarten und Crossover Kabel leiten. Wie konfiguriere ich diese nun ganz konkret damit das funktioniert?

    1. Hallo,
      Danke für deinen Kommentar. Du kannst das über die VM Kernel Settings steuern.
      In deinem Fall müsstet du einen eigenen vSwitch für deine beiden 10g Adapter erstellen und darauf das VM Kernel-Interface mit der vSAN Capability anlegen.

      In einem Direct Connected VSAN Cluster musst du jedoch noch beachten, dass die Witness-Node nicht über den VSAN-enabled’en VMkernel Adapter laufen kann (keine Route). Deshalb musst du noch einem anderen VMkernel Interface beibringen, dass der Witness-Traffic darüber laufen soll. Das kannst du via SSH konfigurieren. Der Befehl lautet “esxcli vsan network ip add -i vmk0 -T witness”
      Damit definierst du, dass der Witness-Traffic immer vom vmk0 gemanaged wird.

      Viel Erfolg.

      Liebe Grüße
      Falk

      LG Falk

  2. Hi Falk,

    danke für die Antwort. Das deckt sich mit dem was ich unter http://vsphere-land.com/news/whats-new-in-vmware-vsan-6-5.html dazu gefunden habe. Als Jemand der von VMware nur rudimentere Kentnisse hat finde ich es sehr schade das VMWare dieses Feature groß bewirbt aber es nicht schafft es dann komplett über die GUI/Webclient konfigurieren zu lassen. Klar stellt sich dann die Frage warum sich jemand wie ich überhaupt an solche Themen herantraut aber das ist eine andere Geschichte 🙂

  3. Andere Frage: Begrenzt der Speed der vSAN Verbindung die Zugriffsgeschwindigkeit auf das vSAN? Also konkret hatte in meiner Konfiguration max. 100 MBit wenn ich in einer VM mal einen HDD Benchmark laufen ließ. Stimmt meine Vermutung das dort die 1 GB LAN Verbindung der Engpass ist? Würde also die 10 GB LAN Verbindung an dieser Stelle mehr Speed zulassen? Z. B. wenn Cache und Kapazitätsspace beides SSDs sind oder das Cache Device eine richtig schnell NVMe PCIe SSD ist?

    1. Hallo Arne,
      entschuldige die späte Antwort. Ich war beruflich sehr viel unterwegs.
      Du liegst genau richtig, dein Flaschenhals ist hier definitiv die 1GE Verbindung. Man sagt hier auch: “1GE läuft, 10GE rennt. :-)”
      Sobald du in der Storage Policy auf zumindest +1 gehst, werden die Daten immer auf mehreren Nodes abgelegt und dann bremst dich dein 1GE Netzwerk.

      Liebe Grüße
      Falk

  4. Mein vSAN läuft ja nun und so stellen sich mir Folgefragen:

    Auf den beiden ESXi Servern mit jeweils 16 GB RAM die den Cluster bilden sind im Leerlauf ohne jede VM schon ~ 6,1 GB vRAM belegt. Offenbar allein durch das vSAN. Als ich einmal testweise 32 GB RAM eingesteckt habe stieg die Belegung auf ~ 9 GB vRAM…

    Wovon hängt der vRam Verbrauch vom vSAN ab? Vorhandenes RAM absolut? Freies RAM? Größe des Cache Devices? Größe des Kapazitätsdevices? Alles zusammen? Dazu habe ich bisher nichts gefunden. Wenn man einen fetten 512 GB RAM Server hätte dann würde mich so ein “Kleinram” wohl nicht interessieren, leider muss ich mich mit 16 GB oder max. 32 GB Ram begnügen und da interessiert mich das ganze sehr.

    Ich bin noch nicht dazu gekommen auszuprobieren was passiert wenn ich auf den vSAN ESXi Host nun soviele VMs starte das das vRAM knapp wird. Ob sich dann vSAN auch mit weniger Ram begnügt oder nicht, wenn ja was das für Auswirkungen auf z. B, die vSAN Performance hat etc…

    Aber vielleicht hast Du da ja schon Antworten?

    1. Hallo Arne,

      der Overhead berechnet sich aus der Zusammenstellung der Diskgroups. Ganz gut beschrieben ist das hier:
      https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2113954

      Du hast da mit dem Sizing nicht Unrecht. Mit 16GB Memory kommt man leider nicht sonderlich weit. Dieser Artikel ist dazu auch ganz interessant:
      https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2106708
      Darin ganz speziell dieses Zitat:
      The memory requirements for vSAN depend on the number of disk groups and devices that are managed by the ESXi hypervisor. Each host should contain a minimum of 32 GB of memory to accommodate for the maximum number of 5 disk groups and maximum number of 7 capacity devices per disk group.

      Das bestätigt noch einmal deine Aussage bzgl. des “Kleinkrams”. Wir bauen aktuell auch zwei VSAN Cluster mit 3 und 5 Hosts. Diese sind alle mit 384GB Memory ausgestattet. Da fällt das wirklich nicht so auf. Ich werde aber auf dein Posting hin mal genau ein Auge auf den Memory Overhead werfen.

      Liebe Grüße
      Falk

  5. Hallo Falk, ich habe jetzt ein 3-Node vSAN Cluster eingerichtet. Die “Billiglösung” mit dem 2 Node vSAN hab ich nicht realisiert. Erstmal in jedem der drei ESXi Hosts: 1x 4 TB HDD und 1x 250 GB SSD als Cache. Dazu eine exklusive 10 GBit LAnVerbindung für das vSAN über einen 10 GB Switch. Nun dachte ich eigentlich das vSAN würde rennen…. Solange ich nur eine Test VM laufen lasse sieht es auch noch ok aus. ~ 600 MB/s lesen ist ungefähr das was die SSDs auch so schaffen und 200 MB/s schreiben ist zwar weniger als erhofft aber besser als 100 MB/s über 1 GB Lan. Aber nun kommts: Sobald das vSAN wirklich was zu tun bekommt geht gar nichts mehr. Überlastungsalarm geht an etc. Quasi unbenutzbar. Passend dazu habe ich diesen Artikel entdeckt: https://communities.vmware.com/thread/522431 Die drei Cache SSDs würde ich austauschen wenns anders nicht geht aber dafür müßte ich erstmal ganz sicher wissen ob eine andere SATA SSD wirklich die Lösung sein kann? Eine SAS wie in dem Artikel kann ich nicht anschließen. Was für Cache Devices setzt Du denn ein?

    1. Hallo Arne,
      entschuldige die späte Antwort, ich war gerade auf Urlaub.
      Unseren letzten Cluster haben wir mit einer VSAN Ready Node von HP realisiert. Darin waren SSD-SAS Drives verbaut. Im VSAN TCO and Sizing Calculator ist diese Disk als “400GB SSD-SAS Mix Use 12G” aufgeführt.
      Ich schaue nächste Woche mal noch in der BoM nach was das genau für eine Disk war. Ich bin aktuell noch immer auf Urlaub.

      Liebe Grüße
      Falk

Schreibe einen Kommentar

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.