Startseite > Netzwerke & IT-Infrastruktur > Hochverfügbare Windows-Server

Migration von WS2003 auf WS2012 R2, Teil 2

Hochverfügbare Windows-Server

6. Juli 2015, 6:00 Uhr | Christoph Lange/wg

Seit Windows 2003 hat Microsoft das Failover Clustering stark ausgebaut. Zu den wichtigsten Neuerungen zählen die Einführung des Hyper-V-Servers, die Availability Groups für MS SQL und Exchange sowie der neue Scale-out File Server. Dieser kann in Verbindung mit den Storage Spaces Speicherkapazitäten über kostengünstige JBOD-Arrays (Just a Bunch of Disks) hochverfügbar bereitstellen.

Für Unternehmen, die noch Failover Cluster mit Windows Server 2003 (WS2003) betreiben, bietet Windows Server 2012 R2 (WS2012 R2) zahlreiche neue Hochverfügbarkeitsfunktionen. Die vielen zusätzlichen Features haben eine Kehrseite: Eine direkte Migration von WS2003 auf WS2012 R2 ist mit dem Cluster Migration Wizard von Microsoft nicht möglich. Um mit dem WS2012-R2-Wizard Cluster-Ressourcen migrieren zu können, müssen die Quellsysteme mindestens über WS 2008 R2 SP1 verfügen. Für eine Migration auf WS2012 ist WS 2008 SP2 Mindestvoraussetzung.
Die Ablösung eines WS2003-Clusters durch einen WS2102-R2-Cluster ist also nur durch einen Parallelaufbau der neuen Systeme machbar. Dies bietet den Vorteil, dass man die neue Umgebung ohne Zeitdruck installieren, konfigurieren und testen kann. Zudem ist ein einfacher Fallback auf die alten Systeme möglich, falls es bei der Umstellung der geclusterten Anwendungen zu gravierenden Problemen kommen sollte.
Auf welchem Weg sich die auf einem WS2003-Cluster laufenden Anwendungen migrieren lassen, hängt von der jeweiligen Applikation ab. MS-SQL-Datenbanken zum Beispiel verfügen über verschiedene Export- und Importfunktionen, Gleiches gilt für Exchange. Die Upgrade-Pfade für die jeweiligen Anwendungen sind in der Regel auf den Herstellerwebseiten zu finden. In Teil 3 der LANline Best-Practice-Reihe werden wir die Migration von File- und Application-Servern genauer beleuchten.
Der aktuelle Beitrag konzentriert sich darauf, wie sich die wichtigsten Hochverfügbarkeitsfunktionen von WS2012 R2 im Zusammenspiel mit Hyper-V-Servern einrichten und nutzen lassen. Hierzu zählen auch die neuen Storage Spaces, mit denen sich anstelle von Fibre-Channel- oder iSCSI-Speichersystemen direkt an die Cluster Nodes angeschlossene kostengünstige JBOD-Arrays als hochverfügbarer Cluster-Speicher nutzen lassen. Auf das Network Load Balancing (NLB), das mehrere Server zu einem Lastenausgleichs-Cluster zusammenschaltet, gehen wir hier nicht näher ein.

Quorum-Funktionen bei WS2003
Bei Windows 2003 Failover Clustern handelt es sich immer um sogenannte Shared-Nothing-Cluster. Dies bedeutet, dass immer nur ein Cluster Node den exklusiven Zugriff auf eine Speicherressource und die darauf laufenden Anwendungen hat. Der oder die anderen Cluster Nodes treten erst dann in Aktion, wenn die Cluster-Ressource auf dem aktiven Node offline geht, zum Beispiel weil der Server mit einem Bluescreen hängen geblieben ist. In diesem Fall übernimmt einer der anderen noch verfügbaren Knoten die Cluster-Ressourcen und bringt sie wieder online.
Um das Verhalten in Failover-Situationen steuern zu können, benötigt ein Windows 2003 Cluster zwingend eine Quorum-Disk. Das Quorum speichert die Cluster-Konfigurationsdatenbank auf einer geclusterten Disk in der Datei quolog.log. Hier steht, welcher Node derzeit der aktive ist. Wenn die Kommunikation zwischen zwei Cluster Nodes, zum Beispiel aufgrund einer Netzwerkstörung, nicht mehr möglich ist und eine Split-Brain-Situation eintritt, bleibt der Knoten aktiv, der die Quorum-Disk hält. Der andere wird von den Cluster-Aktivitäten ausgeschlossen, bis wieder eine Kommunikation zwischen den Nodes möglich ist.
Mit Windows 2003 hat Microsoft für Cluster mit drei oder mehr Knoten als Alternative zum Standard-Quorum das Majority Node Set Quorum eingeführt. Dabei wird die Quorum-Datenbank auf jedem Cluster Node lokal gespeichert. Diese Quorum-Variante ermöglicht es, Cluster Nodes auch über größere Entfernungen miteinander zu verbinden, da die Quorum-Datenbank nicht auf einem gemeinsam genutzten SAN-Speichersystem liegen muss.

Neue Quorum- und Availability-Optionen
Bereits mit WS2008 hat Microsoft als Quorom-Mechanismus eine neue Voting-Funktion eingeführt, bei der ein Cluster Node, eine Disk-Ressource oder ein File Share über eine eigene Stimme verfügen können. Beim Modus "Node Majority" verfügt jeder Cluster über eine Stimme und der Cluster kommt online, sobald eine Mehrheit der Nodes online ist. Mit "Node and Disk Majority" erhält zusätzlich eine Cluster-Disk eine Stimme (Disk Witness). Mit "Node and File Share Majority" erhält zusätzlich ein File Share eine Stimme (File Share Witness). Auch das alte Quorum-Verfahren lässt sich mit "No Majority: Disk Only" noch nutzen. Mit WS2012 R2 hat Microsoft ein dynamisches Witness-Quorum eingeführt, das immer konfiguriert sein sollte. Damit entscheidet der Cluster abhängig vom aktuellen Zustand der Nodes automatisch, ob das Witness-Quorum zum Zuge kommt oder deaktiviert wird.
Um MSSQL-Datenbanken hochverfügbar bereitzustellen, kommt oft ein Failover-Cluster zum Einsatz, bei dem ein Node die aktive Datenbank hält und der zweite Node nur dann einspringt, wenn auf dem ersten Node eine Fehlersituation auftritt. Mit SQL Server 2012 hat Microsoft die Always On Availability Groups eingeführt, die mit einem anderen technischen Konzept vor Ausfällen schützen. Die beteiligten SQL-Server benötigen zwar nach wie vor die Rolle Failover Cluster, um den virtuellen Netzwerknamen, die zugehörige IP-Adresse und die Replikas zu verwalten. Die SQL-Datenbanken werden aber nicht mehr als eigene Cluster-Ressourcengruppen angelegt, sondern durch eine Replikation der SQL-Datenbanken geschützt. Die Daten müssen dabei nicht zwingend auf einem Shared-Storage-System liegen. Eine Availability Group kann mehrere Datenbanken umfassen, die zu einer primären Replika und bis zu acht sekundären Replikas repliziert werden.
Für eine hochverfügbare Bereitstellung von Exchange-Servern hat Microsoft mit Exchange 2010 die Database Availability Groups (DAG) eingeführt. Sie ersetzen die von Exchange 2007 genutzten Replikationsverfahren. Der DAG-Mechanismus verteilt die Datenbanken eines Exchange-Servers und die zugehörigen Transaction Logs auf alle Cluster Nodes. In der maximalen Schutzeinstellung werden alle Datenbanken des ersten Exchange-Servers auf jeden Knoten im Cluster repliziert. Der Administrator kann anschließend steuern, auf welchem Server die jeweilige Datenbank aktiv ist.

Hyper-V-Server mit Failover Clustering
Server-Virtualisierung setzen mittlerweile Unternehmen jeder Größenordnung als Standardtechnik ein. Microsoft hat den anfänglich großen Rückstand gegenüber VMware kontinuierlich verkleinert; der im aktuellen WS2012 R2 enthaltene Hyper-V-Server konnte die Lücke zu VMware in den meisten Bereichen schließen.
Um virtuelle Maschinen (VMs) hochverfügbar bereitstellen zu können, hat Microsoft den Hyper-V-Server eng in das Failover Clustering integriert. Bei der Konfiguration einer hochverfügbaren Hyper-V-Lösung installiert der Administrator zunächst auf allen künftigen Cluster Nodes mithilfe des Rollenassistenten die Hyper-V-Rolle. Anschließend fügt er auf dem ersten Server die Failover-Cluster-Rolle hinzu und richtet mithilfe des Cluster-Assistenten den Cluster ein. Dabei werden die Hyper-V-Funktionen automatisch in den Failover Cluster integriert. Sobald der erste Cluster Node online ist, kann der Administrator die weiteren Nodes nacheinander hinzufügen.
Die mit WS 2008 R2 eingeführten Cluster Shared Volumes (CSVs) haben die Abhängigkeit zwischen den VMs und ihren Speicherorten deutlich reduziert. Bei WS2008 war der Failover einer VM nur auf der Ebene einer kompletten LUN möglich, weil immer nur ein einziger Hyper-V-Host auf eine LUN zugreifen durfte. Auf ein CSV können nun alle Cluster Nodes zugreifen, sodass ein Failover einer VM keine Auswirkungen mehr auf die anderen auf derselben LUN gespeicherten VMs hat. Auf Virtual Machine Manager (VMM) für die Verwaltung größerer Hyper-V-Umgebungen gehen wir hier aus Platzgründen nicht näher ein.
Um die Hochverfügbarkeitsfunktion von Hyper-V für einen virtuellen Gast zu aktivieren, fügt der Administrator die VM im Failover Cluster Manager als neue Ressource hinzu. Dies stellt sicher, dass die VM bei einem Ausfall des physischen Hyper-V-Hosts, auf dem sie gerade läuft, automatisch auf einem der anderen Hosts des Clusters neu gestartet wird.

Storage Spaces
Eine der interessantesten neuen Cluster-Funktionen ist der mit WS2012 eingeführte Scale-out File Cluster in Verbindung mit den ebenfalls neuen Storage Spaces. Der Scale-out File Cluster verwendet das SMB-3-Protokoll, um einem Hyper-V-Cluster die Speicherressourcen als Fileshare bereitzustellen. Die neuen SMB-3-Funktionen Remote Direct Memory Access (RDMA) und Multi-Channel sorgen für hohe Performance, indem sie Zugriffe auf die Shares mit RDMA-fähigen Netzwerkkarten und mit auf alle Cluster Nodes verteilten parallelen SMB-3-Sessions stark beschleunigen. Beim Ausfall eines Knotens sorgt das SMB-3-Protokoll für eine reibungslose Übergabe der offenen Sessions an einen anderen. Um die RDMA-Funktionen nutzen zu können, sind spezielle Netzwerkadapter erforderlich.
Die Storage Spaces sind eine Speicher-Virtualisierungsschicht, mit der sich per SAS-Verbindung direkt an zwei Cluster Nodes angeschlossene JBOD-Arrays als hochverfügbares Storage-System nutzen lassen. Voraussetzung sind JBOD-Arrays mit SCSI-Enclosure-Service-Modul und Enclosure-Awareness-Funktion, die in der Lage sind, beim Ausfall eines Arrays die Datenzugriffe automatisch auf die auf einem anderen Array liegenden gespiegelten Daten umzuleiten. Storage Spaces unterstützen abhängig von der Anzahl der JBOD-Arrays die Verfügbarkeits-Level Dual Parity, Zwei-Wege-Spiegel oder Drei-Wege-Spiegel. Die Tiered-Storage-Funktion der Storage Spaces soll hohe Performance ermöglichen. Sie verschiebt häufig genutzte Daten automatisch auf schnelle SSD-Laufwerke. Als Faustregel für den Mix aus SSDs und SAS- oder SATA-HDDs gibt Microsoft ein Verhältnis von 1:4 an. Eine Liste der von Storage Spaces offiziell unterstützten JBOD-Arrays findet sich auf der Microsoft Hardware Compatibility List (HCL) unter der Adresse windowsservercatalog.com.
Um die Storage Spaces nutzen zu können, konfiguriert der Administrator im Failover Cluster Manager zunächst einen Storage Pool und legt dann darin die virtuellen Storage Spaces Disks an. Diese Disks werden zu Cluster Shared Volumes umgewandelt, die die SMB-3-Fileshares bereitstellen, auf denen die VMs gespeichert werden. Bei Umgebungen mit einer größeren Anzahl an physischen Platten empfiehlt Microsoft, diese auf mehrere Storage Pools zu verteilen. Denn mit der Anzahl der Platten pro Pool steigt die Zeitspanne, die für einen Failover eines Disk Pools auf einen anderen Cluster Node benötigt wird.
Microsoft hat das Failover Clustering seit Windows 2003 um zahlreiche nützliche Funktionen erweitert. Der mit WS2008 eingeführte und inzwischen stark verbesserte Hyper-V-Server bietet auf Basis von WS2012 R2 eine leistungsfähige, hochverfügbare Virtualisierungsplattform. Für einige Unternehmen, die WS2003-Cluster ablösen müssen, dürften die Verfügbarkeiten, die mit einer in einem Hyper-V-Cluster laufenden VM erreichbar sind, die SLA-Anforderungen bereits abdecken. Für leistungshungrige Anwendungen wie Exchange- oder MS-SQL-Datenbanken bieten die auf physischen WS2012-R2-Clustern aufsetzenden Availability Groups eine flexibel konfigurierbare Hochverfügbarkeitslösung. Kostengünstigen Speicher in Form von ausfallsicheren JBOD-Arrays kann der Scale-out File Server in Verbindung mit den Storage Spaces bereitstellen. Dies ist insbesondere für kleinere Unternehmen eine interessante Alternative.