iSCSI, FCoE und MSCS: Tipps zur Cluster-Konfiguration mit vSphere

iSCSI, FCoE, MSCS und Affinitätsregeln: vSphere Cluster stellen in virtuellen Umgebungen die Verfügbarkeit sicher, müssen aber gut geplant werden.

Der Fokus moderner Datacenter entwickelt sich weg vom Thema Disaster Recovery und hin zum Aspekt der Verfügbarkeit....

Statt inkonsistente, beschädigte oder unzugängliche Daten zurückgewinnen zu wollen, konzentrieren Unternehmen sich heute also auf Technologien, die auch beim Auftreten von Problemen die Verfügbarkeit der Applikationen gewährleisten sollen. Virtuelle Datacenter setzen daher Cluster ein, um Rechnerpools bereitzustellen, innerhalb derer virtuelle Maschinen (VMs) bei Problemen einfach neu gestartet werden können.

Das Clustering stellt allerdings einige neue Herausforderungen an ein virtuelles Datacenter. IT-Fachleute sollten daher ein gutes Verständnis für die Auswirkungen des Clusterings auf Systemanforderungen, Speichernetzwerke, Hypervisor, Betriebssystem und Konfigurationseinstellungen entwickeln.

vSphere: ab Version 5.5 mit eingebauten iSCSI und FCoE

Mit VMware vSphere in Version 5.5 wurde der VMware-Hypervisor um iSCSI und Fibre Channel over Ethernet (FCoE) erweitert, die als Protokolle das Server-Clustering unterstützen. Dabei gelten jedoch einige Deployment-Regeln und Einschränkungen, die IT-Planer berücksichtigen müssen.

So unterstützt beispielsweise iSCSI drei grundlegende Server-Cluster-Konfigurationen: Cluster across Boxes (CAB), Cluster in Box (CIB) und N+1. Ein Cluster kann sowohl Software- wie auch Hardware-iSCSI-Initiatoren gleichzeitig nutzen (auch bekannt als Mixed-Mode-iSCSI). Dabei kommen Software-basierende iSCSI-Speicheradapter oder iSCSI-Hardwareadapter etwa von QLogic, Emulex und Broadcomm zum Einsatz.

Allerdings müssen sämtliche Knoten des Clusters dieselbe Version von ESXi ausführen und dasselbe Speicherprotokoll nutzen. Nicht möglich ist beispielsweise ein Cluster, in dem ein Server ESX 5.1 mit iSCSI und ein weiterer Server ESX 5.5 mit FCoE verwendet. Konsistente Hardware- und Softwareausstattungen sind für geclusterte Server also enorm wichtig.

FCoE unterstützt dank verschiedener Software- und Hardware-FCoE-Adapter auch CAB-, CIB- und N+1-Cluster, kann jedoch keine Mischung aus CIB- und CAB-Clustern bieten. Anders als bei iSCSI fehlt eine Unterstützung für Mixed-Mode-Initiatoren, weshalb nicht ein Server einen Software-FCoE-Initiator und ein weiterer Server einen Hardware-FCoE-Initiator nutzen kann. 

Alle Server in einem Cluster müssen denselben FCoE-Initiator verwenden. Auch Protokolle und Hypervisoren können mit FCoE nicht gemischt werden. Beispielsweise muss jeder Server-Knoten dieselbe Version von ESXi und dasselbe Speicherprotokoll nutzen (Fibre Channel und FCoE können in demselben Cluster nicht beide eingesetzt werden).

Clustering-Alternativen für Microsoft-Umgebungen

VMware vSphere stellt für Microsoft-basierte Data Center verschiedene Clustering-Optionen zur Verfügung (die meisten davon beziehen sich allerdings auf Enterprise-Standardapplikationen). Zwei der primären Ansätze unterstützen beispielsweise generisches Server-Clustering auf Basis von Microsoft Cluster Server (MSCS) und Shared Storage, sowie zum zweiten auch Clustering für das Netzwerk-Load-Balancing. IT-Planer können MSCS für hochverfügbare Deployments verwenden und Lastverteilung dort einsetzen, wo der Netzwerkverkehr unvorhersehbar oder anspruchsvoll ist.

Ebenso unterstützt vSphere Clustering-Optionen für SQL. Konventionelles Clustering kann die Performance verbessern, während die Unterstützung der „Always-On“-Verfügbarkeit den bevorzugten Ansatz für geschäftskritische SQL-Deployments darstellt.

Schließlich unterstützt vSphere auch Clustering-Optionen für Microsoft Exchange. Ein einfacher Single-Copy-Cluster stellt einen geclusterten Mailbox-Server bereit, dessen Daten dank Shared Storage mehr als nur ein Server an demselben Speicherort verwalten kann. 

Fortlaufende Cluster-Replikation hilft Exchange-Umgebungen dabei, singuläre Ausfälle zu vermeiden und bietet rasche Widerherstellungsmöglichkeiten mit Failover und Replikation. Das Clustering funktioniert auch für Exchange-Datenbankverfügbarkeitsgruppen, die auf Clustering und Verfügbarkeit von Exchange-Mailboxservern abzielen.

Der Einsatz von Affinitäts- und Anti-Affinitätsregeln

Wenngleich die Mobilität von Workloads einer der vitalsten Vorteile der Virtualisierung ist, kann eben diese Mobilität auch zu erheblichen Problemen führen, wenn Workloads als Reaktion auf eine hochverfügbare oder DRS-Aktivität (Distributed Resource Scheduler) einem (oder auch mehreren) Servern zugewiesen werden sollen. 

Verwaltungswerkzeuge wie DRS verwenden Affinitätsregeln, die vorschreiben können, welche VMs auf einem Server zu halten sind, sowie Anti-Affinitätsregeln, die eine gemeinsame Servernutzung bestimmter VMs untersagen können. IT-Planer sollten Affinitäts- und Anti-Affinitätsregeln einsetzen, um Beziehungen zwischen Workloads auf und über Server-Knoten eines Clusters hinweg zu unterhalten.

Nehmen Sie beispielsweise an, dass eine Anzahl von MSCS-VMs auf demselben Server als CIBs konfiguriert sind. Es wäre wenig wünschenswert, würde ein Failover eine VM auf andere als einen bestimmten Server-Knoten im Cluster verschieben. Affinitätsregeln können also eingesetzt werden, um dafür zu sorgen, dass alle dieser VMs im Fehlerfall auf denselben Server verlagert werden.

Auf der anderen Seite wäre es ebenso unerwünscht, wenn VMs, die über mehrere Server hinweg als CABs konfiguriert sind, im Fehlerfall auf einen einzigen Server im Cluster zurückfallen würden. In einem solchen Fall können Anti-Affinitätsregeln genutzt werden, um die Verlagerung dieser VMs auf identische Server-Knoten zu verhindern.

Clustering ist anspruchsvoll in Implementierung und Wartung

Seien Sie sich darüber im Klaren, dass Clustering-Technologien anspruchsvoll in Implementierung und Wartung sind. Clustering setzt eine sorgsame Interoperabilität zwischen den zu schützenden Applikationsversionen, der Version des Hypervisors, der Betriebssystemversionen und der Enterprise-Speicherlösung voraus.

Bevor eine Cluster-Umgebung in Produktion genommen wird, bedarf es zwingend einer detaillierten Auswertung von Architektur und Verhaltensweise des Clusters. Ebenso entscheidend ist es, das Cluster-Verhalten nach jeder Änderung an Applikationen, Hypervisor, Betriebssystemkomponenten oder Speicher zu testen und neu auszuwerten, um unbeabsichtigte Auswirkungen auf Geschäftsabläufe zu verhindern.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im März 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über VMware

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close