vSphere Clustering, High Availability und Disaster Recovery
Jörn Clausen
joern.clausen@uni-bielefeld.de
Übersicht
Überblick/Erinnerung: VMware vSphere
Clustering
High Availability
Stretched-Cluster-Architektur
VMware vSphere
siehe
RBG-Seminar WS 2008/2009
Struktur ähnlich, vor allem neue Namen
Hypervisor ESX nicht weitergeführt, nur noch ESXi
Verwaltung durch vCenter Server
vCenter Server unter Windows oder als Linux-basierte Appliance
Fat Client: vSphere Client
Alternative: vSphere Web Client – basiert auf Adobe Flash
neue Storage-APIs:
VAAI (VMware vSphere API for Array Integration)
VASA (VMware vStorage APIs for Storage Awareness)
einfacher vSphere-Cluster
Funktionen
VMotion
Verlagerung von (laufender) VM zwischen zwei ESXi-Hosts
gleiche Umgebung auf Quelle und Ziel (CPU, Netzwerk, Storage, ...)
dediziertes VMotion-Netzwerk
Storage VMotion
Verlagerung von virtuellen Festplatten und Metadaten einer (laufenden) VM
Verbindung aller ESXi-Hosts mit allen Storage-Volumes
Dynamic Resource Scheduler (DRS)
Lastausgleich im Cluster durch VMotion
Empfehlung oder automatischer Betrieb
Storage DRS
Lastausgleich auf den Storage-Volumes
berücksichtigt sowohl Platzbedarf als auch I/O-Anforderungen
vSphere High Availability
schützt virtuelle Maschinen beim Ausfall von ESXi-Hosts
Detektion der ausgefallenen ESXi-Hosts
ggf. Neustart der ausgefallenen virtuellen Maschinen
kein kontinuierlicher Betrieb, aber minimaler Service-Ausfall
keine besonderen Anforderungen an Dienst: muss selbststartend sein
Probleme: kein echter Ausfall sondern
Isolation
Partitionierung
Split Brain
Lösung: mehrere unabhängige Signalwege
Komponenten von vSphere High Availabity
Fault Domain Manager (FDM), ersetzt Automated Availability Manager (AAM)
automatische Wahl eines Masters, alle anderen ESXi-Hosts Slaves
Heartbeats zwischen Master und Slaves, wenn möglich über mehrere Netze
ICMP Echo zum default gateway
Storage Heartbeat
Funktionsweise von vSphere High Availability
Ausfall: kein Heartbeat und Storage Heartbeat durch ESXi-Host
Master startet virtuelle Maschinen neu
falls Master ausgefallen: vorher Wahl eines neuen Masters
Isolation: ESXi-Host vom Management-Netz getrennt, kein Heartbeat, Storage Heartbeat funktioniert
VMs werden ggf. heruntergefahren
Master startet VMs eventuell neu
Partitionierung: ein oder mehrere ESXi-Hosts vom Master getrennt, default gateway erreichbar
Wahl eines neuen Masters in der Partition
VMs laufen weiter
VMs werden nur dann neu gestartet, wenn sicher ist, dass sie vorher heruntergefahren/ausgeschaltet wurden
Storage Heartbeat verhindert Split Brain
konvergierte Netze erhöhen Gefahr von Split Brain
Disaster Recovery
Schutz vor Ausfall eines ganzen RZ-Standorts
zwei mögliche Ansätze:
Ausweich-Standort
Stretched Cluster
schon länger Produkt von VMware: vCenter Site Recovery Manager
relativ neues Konzept von VMware: vSphere Metro Storage Cluster
vCenter Site Recovery Manager
Replikation des gesamten vSphere-Clusters in zweiten Standort
gesamte Hardware muss dort vorhanden sein, ggf. kleiner dimensioniert
regelmäßige asynchrone Replikation von Storage und Konfiguration
Fail-Over "auf Knopfdruck"
Tests durch Isolation jederzeit möglich
Entfernung zwischen den Standorten nahezu beliebig
typisches Szenario USA: Ost- und Westküste
war für uns (HRZ) nie Option: 24/7 Service bei 8/5 Operating
Stretched Cluster
Aufteilung der ESXi-Hosts auf zwei Standorte relativ leicht
Latenz bei VMotion limitierender Faktor, maximal einige 10–100 Kilometer
Problem: Storage an jedem Standort, Replikation
zwei Varianten:
uniform host access configuration: Jeder ESXi-Host hat Zugriff auf kompletten Speicher
nonuniform host access configuration: ESXi-Host hat Zugriff nur auf lokalen Speicher
uniform host access configuration
Beispiele:
NetApp MetroCluster
EMC VPLEX
IBM SAN Volume Controler (SVC)
FalconStor IPStor/NSS
FalconStor IPStor im HRZ
asymmetrische Anbindung historisch
Latenz durch Umweg vernachlässigbar
nonuniform host access am Beispiel Hitachi HAM
High Availability Manager (HAM) aktiviert im Fail-Over-Fall inaktive Festplatten-Kopie im anderen Standort
Hitachi Dynamic Link Manager (HDLM) verwendet neuen Pfad
Fail-Back nicht automatisiert
Quorum-Volume verhindert Split Brain
Literatur
VMware vSphere 5.1 Clustering Deepdive (Duncan Epping, Frank Denneman)
http://www.yellow-bricks.com/publications/
VMware vSphere Metro Storage Cluster Case Study
http://www.vmware.com/resources/techresources/10299
Implementing vSphere Metro Storage Cluster using Hitachi Storage Cluster
http://kb.vmware.com/kb/2039406
Deploy VMware vSphere Metro Storage Cluster on Hitachi Virtual Storage Platform
http://www.hds.com/assets/pdf/deploy-vmware-vsphere-metro-storage-cluster-on-hitachi-vsp.pdf
vSphere 5.x support with NetApp MetroCluster
http://kb.vmware.com/kb/2031038