Im Test: Stormagic SvSAN 6.3
Hochverfügbare vSAN-Lösung
Fortsetzung des Artikels von Teil 1
HA-Storage einrichten
Herzstück der SvSAN-Lösung sind die VSA-VMs, die auf jedem Hypervisor laufen und die lokalen Datendisks mit den Pendants des zweiten Cluster-Hosts synchron spiegeln. Wir installierten die VSA-VMs über das vCenter-Plugin auf der lokalen Disk der beiden Test-Server, auf der auch die ESXi-Installation lag. Anschließend erstellten wir zudem die optionale Witness-VM.
Für die Anbindung der zu spiegelnden lokalen Datendisks stellt der VSA-Setup-Wizard mehrere Möglichkeiten zur Verfügung. Die beste Performance bietet das Raw Device Mapping (RDM), das die physischen Disks direkt mit der VSA-VM verbindet. Alternativ lassen sich auch vorhandene Datastores verwenden, die zuvor mit den physischen Disks auf dem ESXi-Host angelegt wurden. Unter den Advanced Options finden sich weitere Menüpunkte, um die Disks als JBOD oder Raid-1 zu konfigurieren.
Wir richteten die zwei HDD- und SSD-Disks jeweils als eigenen Raid-1-Verbund ein. Die beiden Raid-1-Storage-Pools wurden anschließend von den SvSAN-VMs zwischen den beiden ESXi-Servern gespiegelt, damit bei einem Server-Ausfall die VMs auf der Spiegelkopie weiterlaufen können.
Konfiguration als iSCSI-Target
SvSAN stellt den hochverfügbaren gespiegelten Storage per iSCSI bereit. Deshalb muss der Systemverwalter auf den ESXi-Hosts iSCSI aktivieren und einen eigenen VMKernel-Port und vSwitch für den iSCSI-Software-HBA anlegen. Für die VSA-VMs empfiehlt Stormagic, einen zweiten Netzwerkadapter für eine redundante iSCSI-Anbindung hinzuzufügen.
Wenn neue Datastores über das vCenter-Plugin konfiguriert werden, legt der SvSAN-Wizard die Volumes automatisch als iSCSI-Target an, fügt sie auf den ESX-Hosts in der iSCSI-Konfiguration hinzu und erzeugt im vCenter die Datastores. Den HDD-Datastore ließen wir auf diese Weise automatisch vom Plugin einrichten. Den SSD-Datastore erstellten wir dagegen über die Web-GUI der VSA-VMs. Dort mussten wir die iSCSI-Initiatoren der ESXi-Hosts manuell hinzufügen, damit das iSCSI-Target für die Server sichtbar wurde. Anschließend konnten wir das SSD-Volume im vCenter erfolgreich als neuen Datastore hinzufügen.
Mit dem Plugin lassen sich auch bereits vorhandene VSA-Datastores vergrößern. Vom HDD-Raid-1-Volume hatten wir im ersten Schritt nur 300 GByte der 1-TByte-Disk als neues Volume konfiguriert. Wir wählten im Plugin diesen Datastore und erhöhten seine Speicherkapazität mit Hilfe der Grow-Funktion um 400 GByte. Um die Hochverfügbarkeitsfunktionen von SvSAN zu testen, installierten wir auf den gespiegelten VSA-Datastores zwei Windows-VMs und eine Linux-VM. Die drei VMs verteilten wir so auf den HDD- und SSD-Datastore und die beiden ESXi-Hosts, dass die Linux-VM und eine Windows-VM auf dem HDD-Datastore lagen. Diese Windows-VM lief auf dem ersten und die Linux-VM auf dem zweiten ESXi-Host. Die dritte VM lag auf dem SSD-Datastore und lief auf dem zweiten ESXi-Host.
Wir führten einen harten Ausfalltest durch, indem wir den ersten ESXi-Host über das iDRAC-Board des Dell-Servers per Power-Off-Befehl ausschalteten. Die SvSAN-Software schwenkte die Storage-Anbindung sofort auf die Spiegelkopie des zweiten ESXi-Hosts und die auf dem HDD-Datastore liegende Linux-VM lief unterbrechungsfrei weiter. Die auf dem ersten ESXi-Host laufende Windows-VM des HDD-Datastore wurde automatisch vom zweiten ESXi-Host neu gestartet und stand nach kurzer Zeit wieder zur Verfügung. Die dritte VM, die auf dem zweiten ESXi-Host lief und den SSD-Datastore nutzte, hätte eigentlich unterbrechungsfrei weiterlaufen müssen, wurde aber im vCenter als Inaccessible angezeigt.
Wie sich nach kurzer Suche herausstellte, hatten wir bei der manuellen Konfiguration des SSD-iSCSI-Targets versäumt, auf den ESXi-Hosts bei den iSCSI-Target-Settings die IP-Adressen von beiden VSA-VMs hinzuzufügen. Es fehlte die IP der zweiten VSA-VM, sodass der SSD-Datastore beim Ausschalten des ersten ESXi-Hosts und der ersten VSA-VM offline ging, weil der zweite ESXi-Host mit seiner VSA-VM nicht per iSCSI auf den SSD-Datastore zugreifen konnte.
Den HDD-Datastore hatten wir mit dem SvSAN-Plugin-Wizard erstellt, der alle iSCSI-Settings vollständig eingerichtet hatte. Nachdem wir die iSCSI-Konfiguration korrigiert hatten, führten wir denselben Test nochmals durch, und diesmal lief die Windows-VM des SSD-Datastores unterbrechungsfrei weiter.
Bei einem weiteren Ausfalltest hatten wir übersehen, dass die Witness-VM auf dem ausgeschalteten ESXi-Host lief und wir sie versehentlich auf einem lokalen nicht gespiegelten Datastore platziert hatten. Dadurch war der Zugriff auf die von SvSAN verwalteten Datastores nicht mehr möglich, und es erschien die Fehlermeldung, dass die iSCSI-Targets offline genommen wurden, weil das Witness-Quorum verloren gegangen ist.
Nachdem wir den ESXi-Host wieder eingeschaltet hatten und damit auch die Witness-VM wieder verfügbar war, sind alle SvSAN-Datastores und die darauf liegenden VMs automatisch wieder online gekommen. Anschließend migrierten wir die Witness-VM auf einen anderen Datastore.
- Hochverfügbare vSAN-Lösung
- HA-Storage einrichten
- Fazit
Lesen Sie mehr zum Thema
