VMware vSphere HA – vSphere Metro Storage Cluster (vMSC) mit DataCore SANsymphony

In diesem Beitrag wird auf Basis der VMware Dokumentation zu vMSC die Konfiguration mit DataCore SANsymphony beschrieben.

VMware vSphere Metro Storage Cluster (vMSC) Recommended Practices:
https://core.vmware.com/resource/vmware-vsphere-metro-storage-cluster-recommended-practices


Allgemein basiert eine Hochverfügbarkeit auf Redundanzen der beteiligten Ebenen. Die unterste logische Ebene ist der Speicher. Bei VMware wird in diesem Kontext der Speicher in zwei verschiedenen Kategorien unterteilt – Uniform und Non-Uniform.


Der bereitgestellte Speicher von DataCore SANsymphony ist ein
Non-Uniform typischer Speicher. Diese Einstufung ergibt sich aus der Funktionsweise der SANsymphony. Technisch besteht die Möglichkeit auf einem VMFS Datastore gleichzeitig über alle Knoten des SANs zuzugreifen.

 

Die hier beschriebene Architektur und Einstellung der vSphere HA Logik berücksichtigt zwei voneinander getrennt Standorte mit redundanten Verbindungen untereinander. Einfachheitshalber betrachte ich zwei (2) ESXi Server und zwei (2) DataCore SANsymphony Knoten. Eine Skalierung der Umgebung ist möglich und ist sehr oft im Einsatz.

 

Der Aufbau und die Anbindung an das SAN wird via iSCSI oder FC durchgeführt. Eine mehrpfadige Anbindung wird vorausgesetzt. Die benötigten Einstellungen eines ESXi Server sind im DataCore FAQ 1556 beschrieben – https://datacore.custhelp.com/app/answers/detail/a_id/1556/kw/1556

 

In einer vSphere HA Konfiguration sind verschiedene Einstellmöglichkeiten gegeben. Diese Möglichkeiten sind mit den vorher definierten Zielen der Hochverfügbarkeit in Einklang zu bringen. In der Praxis zeigt sich sehr oft, dass es verschiedene Anforderungen an die Funktion gibt.

 

Der Speicher ist im Konzept des vSphere HA eine wichtige Komponente. Die Redundanz muss gegeben sein und diese wird regelmäßig geprüft und dokumentiert. Hierzu werden auch die Heartbeat (HB) Datastores verwendet. Der springende Punkt ist, dass im Alltag der geringe Mehraufwand der erweiterten Konfiguration gescheut wird und damit eine Fehlerquelle mit Ansage entsteht.

Konfiguration:

Die Lösung ist recht einfach. Es werden 4 dedizierte HB Datastores benötigt. Um diese 4 HB Datastores im vCenter konfigurieren zu können, benötigen wir eine erweiterte Einstellung (das.heartbeatDsPerHost).

AdvancedOption_heartbeatDsPerHost

 

In der SANsymphony werden dazu 4 single vDisks zur Verfügung gestellt. Jeweils 2 davon werden aus einem Rechenzentrum an alle Mitglieder des vSphere HA Clusters präsentiert. Damit ist immer sichergestellt, dass die örtlichen ESXi Server ausreichend HB Datastores zur Verfügung haben.

Single vDisk

4x single vDisks

 

An dieser Stelle muss hervorgehoben werden, dass es eine Abweichung zum vMSC Guide gibt. Es wird für diese Konstellation empfohlen, ausschließlich die dafür zur Verfügung gestellten HB Datastores zu verwenden.

Heartbeat Datastores - dediziert

 

Nachdem das Thema Heartbeat Datastores behandelt ist, gehen wir auf die Platzierung der VM in Abhängigkeit zum Rechenzentrum und VMFS Datastore ein.

Die typischen VMFS Datastores werden über synchron gespiegelte vDisks abgebildet. Damit ist sichergestellt, dass die Produktionsdaten immer und gleichzeitig in beiden Rechenzentren zur Verfügung stehen.
Störungen in der Architektur gilt es zu kompensieren. Im Alltag haben wir es mit unterschiedlichen Situationen zu tun. Wir werden im ersten Schritt die Grundlagen betrachten. In einem weiteren Beitrag gehen ich auf unterschiedliche Störungsbilder und die dazu passenden Lösungen ein.

Empfohlene Zuordnung der Resourcen:

VMware empfiehlt die Site-Host-Storage Affinity.
Kurz gesagt: wenn VMs im gleichen Datastore online sind, sollen sie auf ESXi Server im gleichen Rechenzentrum registriert sein. Oder anders formuliert: verteilt eure VMs nicht kreuz und quer über alle ESXi Hosts und VMFS Datastores in völliger Unabhängigkeit von den lokalen Ressourcen. Dies kann man sehr einfach mit DRS Regeln umsetzen. Sollte kein DRS zur Verfügung stehen, ist über ein sinnvolles Namensschema und paar Zeilen eines Skriptes die Umsetzung möglich.

Fazit:

Zusammenfassend kann man festhalten, dass diese grundlegenden Einstellungen in vielen Situationen Folgestörungen vermeiden. Im Falle einer Störung im Sinne eines Redundanzausfalles ist die Wiederherstellung des hochverfügbaren Betriebsmodus stark vereinfacht und beschleunigt. Unabhängig von der Bezeichnung „Metro“ sind die beschriebenen Einstellungen vorteilhaft und gültig.
Folgt man den Empfehlungen von VMware, ergeben sich auch im
Backupkonzept  weitere Vorteile und Synergieeffekte.

Kommentar absenden

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