Hochverfügbare Microsoft Hyper-V-Umgebungen Einführung

Transkript

1 Hochverfügbare Microsoft Hyper-V-Umgebungen Einführung Symon Perriman Vice President, 5nine Software

2 Inhalt Hochverfügbare Microsoft Hyper-V-Umgebungen Einführung Funktionsweise von Failover-Clustering...5 Implementierung eines Failover-Clusters...6 Auswahl der Host-SKU... 6 Installation von Rollen und Features... 8 Konfiguration von Active Directory... 9 Speicherkonfiguration... 9 Netzwerkkonfiguration Validierung eines Failover-Clusters Erstellen eines Failover-Clusters Erstellen eines Scale-out-Dateiservers Bereitstellung einer virtuellen Cluster-Maschine...15 Erstellen einer virtuellen Cluster-Maschine Hinzufügen einer vorhandenen virtuellen Maschine zu einem Cluster Migration einer virtuellen Maschine aus einem vorhandenen Cluster Erstellen eines Gast-Failover-Clusters Management einer virtuellen Cluster-Maschine...18 Gruppen virtueller Maschinen Priorität beim Starten virtueller Maschinen Platzierung von virtuellen Maschinen auf Hosts Offline-Einstellungen für virtuelle Maschinen Überwachen virtueller Maschinen Integritätsprüfungen für Cluster-Knoten Wartung der Knoten Clusterfähiges Aktualisieren Sicherheit von virtuellen Cluster-Maschinen Replikation von virtuellen Cluster-Maschinen Backup von virtuellen Cluster-Maschinen

3 Mobilität virtueller Maschinen...28 Schnellmigration Live-Migration Speichermigration Zusammenfassung Ressourcen...31 Informationen zum Autor...32 Über Veeam Software

4 Hochverfügbare Microsoft Hyper-V-Umgebungen Einführung Unternehmen müssen heutzutage ihren Geschäftsbetrieb rund um die Uhr aufrechterhalten. Damit Kunden nicht zur Konkurrenz abwandern, ist es wichtig, dass sie jederzeit auf Services zugreifen können. Auf dem globalen Markt von heute müssen Systeme ununterbrochen verfügbar sein nur so können Unternehmen mit ihren Mitbewerbern Schritt halten und die Zufriedenheit ihrer Anwender sicherstellen. Eine hohe Verfügbarkeit im Rechenzentrum lässt sich auf unterschiedliche Weise erzielen. Die gängigste und zugleich einfache Methode besteht darin, Servervirtualisierung mit Failover-Clustering zu kombinieren. Die Servervirtualisierung bringt zahlreiche Vorteile für die IT-Abteilung mit sich, unter anderem die Möglichkeit, unterschiedliche Systeme auf einem Host-Server zu konsolidieren. Dies ermöglicht eine bessere Ressourcenauslastung, eine Verringerung des Platzbedarfs und zugleich die Isolierung der verschiedenen Workloads auf den einzelnen virtuellen Maschinen (VMs). Durch die Trennung der Anwendungen auf den einzelnen VMs verringert sich das Risiko, dass eine ungesicherte oder ausgefallene Komponente andere Services beeinträchtigt. Zudem gibt es weniger Komponenten, auf denen Patches installiert werden müssen, wodurch sich Ausfallzeiten infolge eines Systemneustarts weiter verringern. Da VMs einfach geklont oder über eine Vorlage bereitgestellt werden können, lassen sich auf diese Weise die Implementierung vereinfachen, fehlerhafte Konfigurationen vermeiden und Systeme schnell erweitern. Virtualisierung ermöglicht außerdem das Verschieben von VMs auf einen anderen Host, ohne dass die auf der VM ausgeführte Anwendung unterbrochen wird. So können auf dem ursprünglichen Host Patches oder Aktualisierungen installiert werden. Virtualisierung ist eine entscheidende Komponente moderner Rechenzentren. Wichtige Voraussetzungen sind deshalb eine hochverfügbare Lösung, die den nötigen Schutz bietet und eine Wiederherstellung nach ungeplanten Ausfallzeiten ermöglicht, sowie ein einfacheres Management von geplanten Ausfallzeiten für Wartungsarbeiten. Es gibt verschiedene Lösungen, mit denen eine hohe VM-Verfügbarkeit erzielt werden kann. Am häufigsten eingesetzt werden Clustering, Lastenausgleich, Replikation und Backup. Für Backups stehen Lösungen wie Veeam Backup & Replication, System Center Data Protection Manager oder Windows Server Backup zur Verfügung, mit denen VM-Daten in regelmäßigen Abständen gesichert werden. Wird die virtuelle Festplatte der VM gelöscht oder beschädigt, so können diese Daten wiederhergestellt werden. Bei der Replikation werden die virtuelle Festplatte und die VM- Konfigurationsdatei an einen sekundären Speicherort kopiert. Bei einem Ausfall der primären VM wird dann die replizierte VM gestartet. Weit verbreitete Lösungen hierfür sind Veeam Backup & Replication und die Windows Server-Technologie Hyper-V-Replica. Mit einer Lösung für den Lastenausgleich, wie sie mit dem Netzwerklastenausgleich von Windows Server zur Verfügung steht, werden mehrere VMs identisch konfiguriert. Der Lastenausgleich sorgt dann für eine möglichst gleichmäßige Verteilung der Serviceanfragen auf die VMs. So verringert sich das Risiko einer Überlastung einzelner VMs. Durch Lastenausgleich lassen sich VM-Ausfallzeiten ganz einfach vermeiden, da die VMs bei laufendem Betrieb ausgewechselt und gewartet werden können. Der Lastenausgleich funktioniert jedoch nur für identische zustandslose VMs, auf denen keine freigegebenen oder zentralen Daten gespeichert sind, beispielsweise bei einem Website-Frontend. 4

5 Failover-Clustering ermöglicht eine optimale Hochverfügbarkeitslösung für VMs einschließlich schneller und automatischer Wiederherstellung, Zugriff auf freigegebene Daten und eine Wartung nahezu ohne Ausfallzeiten. Damit lässt sich eine hohe Verfügbarkeit für geplante Ausfallzeiten beispeilsweise für Wartungsarbeiten und Upgrades sowie für ungeplante Ausfallzeiten aufgrund von Sicherheitsbedrohungen, Stromausfällen oder auch Naturkatastrophen erzielen. In diesem Whitepaper werden die Szenarios, Designaspekte, Features und Best Practices vorgestellt, die einen unterbrechungsfreien Betrieb von Services auf den Virtualisierungs- und Clustering-Plattformen von Microsoft, Windows Server Hyper-V und Failover-Clustering, ermöglichen. Funktionsweise von Failover-Clustering Ein Failover-Cluster besteht aus einem komplexen verteilten System, das Interoperabilität zwischen der Anwendung, dem Betriebssystem, der VM, dem Virtualisierungs-Host, dem Speichersystem und den Netzwerkkomponenten voraussetzt. Die wichtigsten Anforderungen werden im Folgenden kurz beschrieben. Dabei wird auch darauf eingegangen, wie sie zu einer höheren VM-Verfügbarkeit beitragen. Umfassende Hardware-Redundanz: Eine Hochverfügbarkeitslösung setzt voraus, dass Sie alle Fehlerquellen eliminieren. Hierzu müssen Sie nicht nur mehrere Host-Server (sogenannte Cluster-Knoten) einrichten, sondern auch die Redundanz Ihrer Speicher-Fabric sicherstellen, indem Sie beispielsweise über MPIO (Multipfad-E/A) mehrere miteinander verbundene Pfade zum Speichersystem einrichten. Im Speichersystem selbst sollten Features wie RAID, Spiegelung und Backup eine möglichst hohe Verfügbarkeit sicherstellen. Es sollten mehrere Netzwerkpfade vorhanden sein und alle Netzwerkadapter sollten NIC-Teaming verwenden. Speicherung von Daten auf Speicherfreigaben, auf die alle Knoten zugreifen können: Da die in einem Cluster ausgeführte Anwendung auch bestimmte Daten freigeben muss (z. B. eine virtuelle Festplatte für eine VM oder eine Datenbank für einen SQL-Server), müssen diese Daten an einem zentralen Speicherort gespeichert werden, auf den alle Knoten Zugriff haben. So kann die Anwendung auf einem beliebigen Cluster-Knoten ausgeführt werden, ohne dass der Lese- und Schreibzugriff auf die zentral gespeicherten Daten eingeschränkt wird. Die Konfigurationseinstellungen des Clusters werden in der Registrierung gespeichert: Die Registrierung ist eine integrierte, hierarchische Datenbank von Windows Server zur Nachverfolgung von System- und Anwendungseinstellungen. Das Failover-Clustering speichert Informationen in der Registrierung, die für die Ausführung der Anwendung auf dem entsprechenden Knoten benötigt werden. Hierzu gehören: der Knoten, auf dem die Workload ausgeführt werden soll die Eigenschaften der VM oder Anwendung im Cluster (Name, IP-Adresse, Festplatten, Netzwerke usw.) der Zustand der einzelnen VMs oder Anwendungen im Cluster (online, offline, ausgefallen usw.) 5

6 Die Cluster-Registrierung wird auf allen Knoten repliziert: Um eine einheitliche Ausführung einer VM auf allen Knoten sicherzustellen, müssen auch die Einstellungen der Cluster-Registrierung auf allen Knoten konsistent sein. Hierfür sorgt ein im Hintergrund arbeitetender Cluster-Replikationsdienst, der Änderungen an den Eigenschaften oder dem Zustand der VM auf alle Knoten im Cluster kopiert. Die Cluster-Knoten überprüfen sich gegenseitig auf Integrität: Mit einem einfachen Test bestehend aus einer Anforderung und einer Antwort überprüft jeder Cluster-Knoten die Integrität der anderen Knoten. So wird sichergestellt, dass alle Knoten online sind und reagieren können. Wenn ein bestimmter Knoten zu viele Integritätsprüfungen nicht besteht, ermitteln die übrigen Knoten, ob dieser Knoten ausgefallen ist. Ist dies der Fall, werden die vor dem Ausfall aktiven Dienste neu gestartet. Neustart von Workloads im Cluster auf der Grundlage von Daten in der Cluster-Registrierung: Auch beim Ausfall eines Cluster-Knotens können alle anderen Knoten anhand der in der Registrierung replizierten Daten feststellen, welche VMs auf dem ausgefallenen Knoten gehostet wurden. Die funktionierenden Knoten starten auf der Grundlage dieser Informationen die VMs in dem Zustand neu, in dem sie sich vor dem Ausfall des Knotens befanden. Die VMs verfügen nach dem Neustart über dieselben Eigenschaften (Name, IP-Adresse, Festplatte usw.) und denselben Zustand (online, offline usw.) wie vor dem Ausfall. Sie greifen außerdem auf dieselben Daten auf dem freigegebenen Speicher zu. Im Prinzip wird bei diesem Vorgang auf dem funktionierenden Cluster-Knoten eine identische VM mit denselben Verbindungseinstellungen erstellt. Dienste oder Clients, die die VM vor dem Ausfall des Knotens genutzt haben, können eine Verbindung zu dieser neuen VM herstellen. Implementierung eines Failover-Clusters Da für einen Failover-Cluster zahlreiche Hardware- und Softwarekomponenten erforderlich sind, müssen bei der Implementierung verschiedene Aspekte berücksichtigt werden. Die meisten der folgenden administrativen Aufgaben werden über die Failover-Clustering-Konsole, den Failovercluster-Manager ausgeführt. Eine Ausführung über PowerShell ist jedoch ebenfalls möglich. Weitere Informationen zum Cluster-Management mit PowerShell finden Sie auf TechNet: Auswahl der Host-SKU Failover-Clustering wird von verschiedenen Versionen von Windows Server unterstützt. Die Funktionen sind in allen Versionen identisch. Die einzelnen SKUs unterscheiden sich jedoch in einigen Aspekten: Windows Server Datacenter Edition Diese SKU empfiehlt sich für virtualisierte Umgebungen, da sie die Ausführung einer unbegrenzten Anzahl von VMs ermöglicht, die Windows Server als Gastbetriebssystem nutzen. Wenn Sie eine Lizenz für den Host erwerben, können alle Windows Server-VMs auf dem Host diese Lizenz ebenfalls nutzen und über die automatische VM-Aktivierung sogar automatisch aktiviert werden. 6

7 Windows Server Standard Edition Diese SKU verfügt über eingeschränkte Virtualisierungsrechte und wird daher nicht für den Einsatz auf Microsoft Hyper-V-Hosts empfohlen. Eine Host-Lizenz kann lediglich für zwei weitere VMs mit Windows Server genutzt werden. Diese SKU wird in der Regel für Server verwendet, auf denen keine VMs gehostet werden, beispielsweise einen Domänencontroller oder SQL-Server. Hyper-V Server Diese SKU wurde für Microsoft Hyper-V-Hosts konzipiert, steht kostenlos zur Verfügung und kann für eine unbegrenzte Zeit genutzt werden. Als kostenlose Version soll sie zu einer stärkeren Verbreitung von Microsoft Hyper-V beitragen. Sie unterstützt dieselben Virtualisierungs- und Hochverfügbarkeitsfunktionen wie die anderen SKUs, verfügt jedoch nicht über eine grafische Oberfläche und lediglich über grundlegende Features für Virtualisierung, Speicher und Netzwerk. Andere Features und Rollen von Windows Server wie AD (Active Directory), DNS oder IIS sind darin nicht enthalten. Sie beinhaltet außerdem keine Lizenzen für die Ausführung von Windows Server im Gastbetriebssystem. Wird im Gastbetriebssystem Linux eingesetzt, steht jedoch mit dieser SKU eine nahezu kostenlose Hyper-V-Lösung zur Verfügung. Hyper-V Server kann hier heruntergeladen werden: aka.ms/hypervserver. Sowohl die Windows Server Datacenter Edition als auch die Standard Edition bieten die Wahl zwischen einer vollständigen Installation (mit grafischer Benutzeroberfläche) und einer Server Core- Installation (ohne grafische Benutzeroberfläche). Beide Optionen unterstützen alle Features von Microsoft Hyper-V und Failover-Clustering. Die Server Core-Installation empfiehlt sich für Hyper-V-Hosts, da sie aufgrund eines geringeren Angriffsrisikos und Wartungsaufwands eine höhere Verfügbarkeit bietet. Über eine vollständige Installation (mit grafischer Benutzeroberfläche) von Windows Server oder die Remoteserver-Verwaltungstools (aka.ms/rsat) ist das Managemet per Fernzugriff möglich. Server Core- Installationen können mit PowerShell auch lokal gemanagt werden. Sie können außerdem 5nine Manager von 5nine Software ( direkt als grafische Benutzeroberfläche hinzufügen. Windows 8 bietet ebenfalls Unterstützung für Microsoft Hyper-V, jedoch keine Enterprise-Features wie Live-Migration oder Failover-Clustering. Über den Windows-Client kann jedoch eine VM erstellt und anschließend exportiert und auf einen Hyper-V-Host importiert werden. Damit stehen alle Enterprise- Features zur Verfügung. 7

8 Installation von Rollen und Features Die Hyper-V-Rolle und das Feature Failover-Clustering müssen auf allen Cluster-Knoten installiert werden. Ab Windows Server 2012 ist es möglich, einen Cluster mit bis zu 64 Knoten und VMs zu erstellen. Dadurch kann die Installation von Rollen und Features über ein PowerShell-Skript erfolgen, mit dem auch andere Routineaufgaben für das Management von Hyper-V oder Failover-Clustering ausgeführt werden. Abbildung 1: Installation des Features Failover-Clustering 8

9 Konfiguration von Active Directory Für den Einsatz von Failover-Clustering benötigen Sie Active Directory, auch wenn es für Microsoft Hyper-V nicht erforderlich ist. Selbst wenn Sie die kostenlose Hyper-V Server-SKU für Ihre Cluster- Knoten nutzen möchten, benötigen Sie daher mindestens eine Vollversion von Windows Server mit AD in Ihrer Umgebung. Alle Cluster-Knoten müssen derselben AD-Domäne angehören, die mindestens die Domänenfunktionsebene Window Server 2003 aufweist. Die Cluster-Knoten müssen außerdem Mitgliedsserver sein, d. h. Sie können den Domänencontroller nicht direkt auf dem Host ausführen. Dies liegt daran, dass AD beim Starten von VMs und Workloads im Cluster für die Authentifizierung erforderlich ist. Wenn daher die Kommunikation auf dem Cluster-Knoten, auf dem der Domänencontroller gehostet wird, unterbrochen oder durch den Netzwerkverkehr im Cluster blockiert wird, kann der Knoten die Anwendung möglicherweise nicht starten. Nach Möglichkeit sollten außerdem alle Computerobjekte des Cluster-Knotens derselben Organisationseinheit angehören, sodass die Gruppenrichtlinie einheitlich auf alle Knoten angewendet werden kann. Wenn zum Schutz der VM-Daten vor physischem Diebstahl BitLocker aktiviert ist, muss auf dem Domänencontroller Windows Server 2012 R2 ausgeführt werden. Es besteht außerdem die Möglichkeit, den Domänencontroller auf einer dedizierten VM im Cluster auszuführen. Sie profitieren damit von denselben Vorteilen im Hinblick auf eine hohe Verfügbarkeit wie bei gewöhnlichen Cluster-VMs. Sie können zudem Cluster-Konten in AD vorkonfigurieren, damit auch Administratoren mit eingeschränkten Rechten Cluster oder VMs in einer schreibgeschützten Domänencontroller-Umgebung erstellen können. Dieses Thema würde den Rahmen dieses Whitepapers sprengen. Weitere Informationen finden Sie hier. Speicherkonfiguration Für das Failover-Clustering ist eine Speicherfreigabe erforderlich, damit alle Knoten auf die Daten zugreifen können. Hierfür können die meisten modernen SANs (Storage Area Networks) mit einem unterstützten Protokoll verwendet werden. Glücklicherweise verfügt das Failover-Clustering über ein integriertes, auf Best Practices basierendes Analystetool (Clustervalidierung), mit dem das ordnungsgemäße Funktionieren des Speichersystems überprüft wird. Sie können außerdem über den Windows Server-Katalog und das Microsoft Private Cloud Fast Track-Programm eine bereits getestete Lösung erwerben. Viele Kunden, die Microsoft Hyper-V einsetzen, entscheiden sich beim Kauf neuer Hardware für konvergierte Systeme, bei denen alle Cluster-Knoten, Speicher- und Netzwerkkomponenten in einem Rack kombiniert sind. Ein Beispiel hierfür ist die StarWind Hyper- Converged Platform, die Dell-Server und Speichersysteme von xbyte Technologies umfasst sowie das Speichermanagement auf Basis von StarWind Virtual SAN, ein zentrales Hyper-V- und Cluster- Management mit 5nine Manager und Backup mit Veeam Backup & Replication ermöglicht. 9

10 Es gibt drei Kategorien von Speichersystemen: SAN-Systeme mit einem Hostbusadapter (HBA) Diese Art von SAN-Systemen ist am weitesten verbreitet und umfasst unter anderem Fibre Channel und Serial-Attached SCSI (SAS). Fibre Channel ist in der Regel mit höheren Kosten verbunden, bietet aber eine schnellere Performance als SAS. SAN-Systeme mit Ethernet In den letzten Jahren hat sich die Netzwerkbandbreite deutlich erhöht, sodass mit Ethernet nun Geschwindigkeiten möglich sind, die zuvor nur mit HBA-basierten Speicher-Fabrics erzielt werden konnten. Dadurch können Ethernet-basierte Lösungen trotz der hierfür erforderlichen dedizierten NICs und Netzwerke wesentlich günstiger angeboten werden. Failover-Clustering unterstützt die beiden Protokolle iscsi und Fibre Channel over Ethernet (FCoE). SMB 3-Dateiserver Das SMB-Protokoll (Server Message Block) ist ein auf Microsoft ausgelegtes Netzwerkprotokoll der Anwendungsebene für die Freigabe von Dateien auf einem Dateiserver. Dateifreigaben wie \\EigeneFreigabe sind Verzeichnisse für Daten, auf die über verschiedene Server zugegriffen werden kann. Mit der Einführung von Windows Server 2012 bestand erstmals die Möglichkeit, die virtuelle Festplatte einer VM auf dieser Dateifreigabe zu speichern. Damit steht eine sehr kostengünstige Lösung für freigegebenen Speicher zur Verfügung, auf den alle Cluster-Knoten gleichzeitig zugreifen können. Ab Windows Server 2008 R2 unterstützt Failover-Clustering eine softwaredefinierte Festplattenvirtualisierungsebene, die als Freigegebenes Clustervolume (Cluster Shared Volume, CSV) bezeichnet wird. Damit können auf einer einzelnen LUN mehrere VMs gespeichert werden, die auf unterschiedlichen Cluster-Knoten ausgeführt werden. Bei der Implementierung von Failover-Clustering für VMs mit einem SAN empfiehlt es sich, CSV für alle freigegebenen Festplatten zu aktivieren, um das Speichermanagement durch die Konsolidierung zahlreicher VMs auf einer Festplatte zu vereinfachen. Bei herkömmlichen Cluster-Festplatten ist der gleichzeitige Zugriff mehrerer Knoten auf eine Festplatte nicht möglich, sodass jeder VM eine eigene LUN zugewiesen werden muss. Dadurch wird das Speichermanagement wesentlich komplexer. Netzwerkkonfiguration Eine wichtige Voraussetzung für eine hohe Verfügbarkeit ist die Optimierung der Cluster-Netzwerke, da diese für die Administration, den Zugriff auf VMs, Integritätsprüfungen, Live-Migrationen und beim Einsatz einer Ethernet-basierten Lösung oder von Microsoft Hyper-V über SMB häufig auch für das Speichern von Daten verwendet werden. Die Cluster-Knoten können sich in einem oder in verschiedenen Subnetzen befinden. Beim Erstellen eines Clusters oder Hinzufügen eines Netzwerks werden die Netzwerke automatisch konfiguriert. Sie müssen mit dem Hyper-V Manager identische virtuelle Netzwerke und Switches auf den einzelnen Cluster-Knoten erstellen, damit Ihre VMs eine Verbindung zu anderen Diensten herstellen können. Der Name dieser virtuellen Netzwerke muss auf allen Knoten im Cluster identisch sein, damit die VM über den Namen stets auf dasselbe Netzwerk zugreifen kann, und zwar unabhängig vom Host, auf dem die VM ausgeführt wird. 10

11 Um die Redundanz sicherzustellen, sind für alle Cluster mindestens zwei Netzwerke erforderlich. Fällt ein Netzwerk aus, wird der Verkehr über das sekundäre Netzwerk umgeleitet. Gemäß Best Practice sollte für jede Art von Netzwerkverkehr ein dediziertes Netzwerk mit mindestens 1 Gbit/s verwendet werden. Daher könnten bis zu fünf Netzwerke erforderlich sein: Netzwerk für den internen Cluster-Verkehr (erforderlich) Der Cluster benötigt dieses dedizierte Netzwerk für Integritätsprüfungen, die Aktualisierung der Cluster-Datenbankregistrierung nach einer Änderung und andere interne Kommunikationszwecke. Dieses Netzwerk sollte nicht für anderen Datenverkehr genutzt werden, da dies die Integritätsprüfungen innerhalb des Clusters beeinträchtigen könnte. Netzwerk für den Verkehr von Clients und Anwendungen (erforderlich) VMs werden meist nicht in einer isolierten Umgebung ausgeführt, da sie Dienste für anderen Anwendungen oder Clients bereitstellen. Deshalb müssen die Benutzer, die diese Anwendungen und Clients verwenden, über ein externes Netzwerk auf die VMs zugreifen. Aus Sicherheitsgründen muss dieser Verkehr vom internen Cluster-Verkehr getrennt werden, damit Denial-of-Service-Angriffe über dieses Netzwerk den internen Cluster-Verkehr nicht beeinträchtigen. Netzwerk für den Verkehr bei Live-Migrationen (dringend empfohlen) Wird eine VM bei laufendem Betrieb von einem Host auf einen anderen verschoben (Live-Migration), wird der Arbeitsspeicher der VM über eine Netzwerkverbindung auf den neuen Host kopiert. Dadurch nimmt der Netzwerkverkehr vorübergehend stark zu, da mehrere GB Daten möglichst schnell über das Netzwerk übertragen werden müssen. Die Einrichtung eines dedizierten Netzwerks für diesen Verkehr wird daher dringend empfohlen, damit der übrige Netzwerkverkehr nicht beeinträchtigt wird. Netzwerk für das Host-Management (empfohlen) Bei bestimmten Administrationsaufgaben müssen große Datenmengen über das Netzwerk übertragen werden. Hierzu gehören das Backup mit Veeam Backup & Replication, die Bereitstellung einer VM auf einem Host aus einer Bibliothek oder die VM-Replikation. Im Idealfall wird für diesen Verkehr ein dediziertes Netzwerk verwendet. Bei Bedarf kann dieser Verkehr jedoch auch über das Netzwerk für Live-Migrationen geleitet werden. 11

12 Netzwerk für das Speichern von Daten über Ethernet (für Ethernet-basierte Speichersysteme erforderlich) Wenn Sie für die Datenspeicherung iscsi, Fibre Channel over Ethernet oder einen SMB 3-Dateiserver verwenden, benötigen Sie für diese Daten eine dedizierte Netzwerkverbindung. Nur so können Sie sicherstellen, dass dieses Netzwerk über ausreichend Bandbreite verfügt, um die Anforderungen aller VMs auf diesem Host zu unterstützen. Wenn die VMs auf einem Host nicht schnell genug auf Daten zugreifen können, verringert sich ihre Performance. Abbildung 2: Konfiguration des Netzwerks für Live-Migrationen Bei der Erstellung des Clusters werden den einzelnen Netzwerken unterschiedliche Werte zugewiesen. Dies geschieht in der Reihenfolge, in der die einzelnen Netzwerkadapter erkannt werden. NICs, die Zugriff auf ein Standard-Gateway haben, werden für den Datenverkehr von Clients und Anwendungen reserviert, da der Cluster davon ausgeht, dass dieses Netzwerk über eine externe Verbindung verfügt. Der zugewiesene Wert wird als Netzwerkpriorität bezeichnet. Die unterschiedlichen Datenverkehrsmuster für die einzelnen Cluster-Netzwerke müssen mit PowerShell konfiguriert werden. Nähere Informationen zur Netzwerkkonfiguration finden Sie in diesem Blog. 12

13 Validierung eines Failover-Clusters Während der Erstellung eines Failover-Clusters können die einzelnen Komponenten getestet werden, um ein ordnungsgemäßes Funktionieren der Lösung sicherzustellen. Hierfür kommt das integrierte, auf Best Practices basierende Analysetool zum Einsatz, der sogenannte Überprüfungs-Assistent. Das Tool wird über den Failovercluster-Manager gestartet und führt verschiedene Tests zur Überprüfung der gesamten Lösung einschließlich Speicher und Netzwerk sowie der Konfiguration von Windows Server und Microsoft Hyper-V durch. Es dokumentiert außerdem die Einstellungen der Cluster-Knoten, was beim Support oder der Compliance hilfreich sein kann. Das Tool kann darüber hinaus auch zur Fehlerbehebung verwendet werden, indem Tests für den gesamten Cluster durchgeführt werden. Mit weiteren Tests wird sichergestellt, dass alle Workloads im Cluster für eine hohe Verfügbarkeit optimiert wurden. Die Testergebnisse werden auf einer xml-basierte Webseite dargestellt. Außerdem wird eine Kopie des Reports auf jedem Cluster-Knoten unter C:\Windows\Cluster\Reports gespeichert. Bei allen Tests erhalten Sie eine Meldung, ob Ihr Cluster den Test bestanden hat oder nicht. In manchen Fällen wird auch eine Warnung angezeigt, dass die Lösung zwar funktionsfähig ist, jedoch nicht nach Best Practices konfiguriert wurde. Damit ein Cluster vollständig von Microsoft unterstützt wird, muss er zwei Voraussetzungen erfüllen. Erstens muss der Cluster alle Überprüfungstests bestehen (Warnungen gelten ebenfalls als bestanden), zweitens müssen alle Hard- und Softwarekomponenten vom Hersteller für Windows Server zertifiziert sein. Da auf den einzelnen Cluster-Knoten jedoch unterschiedliche Hardware zum Einsatz kommen kann, empfiehlt es sich, die Cluster möglichst ähnlich zu konfigurieren, damit sich die VMs auf allen Knoten gleich verhalten. Abbildung 3: Testen der Konfiguration durch Überprüfung des Clusters 13

14 Erstellen eines Failover-Clusters Nach der Überprüfung der Hard- und Softwarekonfiguration kann der Cluster in wenigen Schritten erstellt werden. Hierfür kommt der Assistent Cluster erstellen zum Einsatz, der über den Failovercluster-Manager gestartet wird. Nachdem Sie festgelegt haben, welche Hyper-V-Hosts als Cluster-Knoten verwendet werden sollen, werden Sie aufgefordert, eine IP-Adresse und einen NetBIOS-Namen für den Cluster einzugeben. Wird ein DHCP-Server erkannt, weist dieser dem Cluster automatisch eine IPv4- oder IPv6-Adresse zu, die später geändert werden kann. Bei diesem Cluster- Namen handelt es sich um eine andere Cluster-Ressource, die auf einem beliebigen aktiven Knoten ausgeführt wird. Bei einem Ausfall dieses ersten Knotens erfolgt ein Failover auf einen anderen Knoten. So können Sie eine Verbindung zum Cluster herstellen, indem Sie lediglich den Cluster-Namen oder die IP-Adresse angeben. Sie müssen nicht wissen, welche Cluster-Knoten derzeit online sind. Erstellen eines Scale-out-Dateiservers Wenn Sie über einen SMB 3.0-Dateiserver auf die virtuelle Festplatte der VM zugreifen möchten, so benötigen Sie hierfür eine Dateifreigabe, die auf einem Dateiserver ausgeführt wird. Ist dieser Dateifreigabepfad zur virtuellen Festplatte (z. B. \\EigeneFreigabe\EigeneVM.vhdx) nicht verfügbar, kann die VM nicht auf die Festplatte zugreifen und funktioniert nicht ordnungsgemäß. Daher ist ein hochverfügbarer Zugriff auf diese Dateifreigabe wichtig. Zwar ist dies auch mit einem Failover-Cluster möglich, doch empfiehlt sich die Verwendung eines unabhängigen Clusters, da die Hardware des Hyper-V-Clusters für virtualisierte Umgebungen optimiert werden muss. Die Erstellung eines hochverfügbaren Dateiservers erfolgt über den Assistenten für hohe Verfügbarkeit, der über den Failovercluster-Manager gestartet wird. Diese Art von Dateiserver kann dennoch vorübergehende VM-Ausfälle verursachen, wenn der Knoten, auf dem die Dateifreigabe gehostet wird, nicht verfügbar ist und ein Failover erforderlich wird, da in diesem Fall auch die Dateifreigabe vorübergehend offline ist. Mit Windows Server 2012 wurde ein neuartiger Cluster-Dateiserver eingeführt, der sogenannte Scaleout-Dateiserver (SOFS). Damit kann mithilfe der CSV-Technologie der Dateifreigabepfad auf mehreren Knoten gleichzeitig erstellt werden. Dies hat zur Folge, dass mehrere Knoten ausfallen können, die VMs jedoch weiterhin auf ihre virtuellen Festplatten zugreifen und online bleiben können, solange auch ein Knoten mit einem Dateifreigabepfad online ist. Der Scale-out-Dateiserver ist nicht zwingend erforderlich, wird jedoch für eine möglichst hohe Verfügbarkeit Ihrer Cluster-VMs empfohlen. 14

15 Abbildung 4: Erstellung eines Scale-out-Dateiservers Bereitstellung einer virtuellen Cluster-Maschine Nach der Erstellung Ihres Failover-Clusters können Sie nun Ihre hochverfügbaren VMs bereitstellen. Abhängig davon, ob es sich um eine neue oder bereits vorhandene VM handelt, stehen hierfür im Failovercluster-Manager verschiedene Möglichkeiten zur Verfügung. Erstellen einer virtuellen Cluster-Maschine Das Erstellen einer VM in einem Cluster unterscheidet sich in einigen wenigen Punkten von der Erstellung anderer Cluster-Workloads, da hierfür nicht der Assistent für hohe Verfügbarkeit verwendet wird. Stattdessen kommt der Assistent für neue virtuelle Maschinen zum Einsatz, der mit dem entsprechenden Tool in Hyper-V Manager identisch ist. Damit steht eine konsistente Oberfläche bereit, unabhängig davon, ob Sie eine Cluster-VM oder eine eigenständige VM erstellen möchten. Der wesentliche Unterschied besteht darin, dass eine Cluster-VM auf freigegebenem Speicher gespeichert werden sollte, auf den alle Cluster-Knoten zugreifen können. Nach Abschluss des Assistenten für neue virtuelle Maschinen wird automatisch ein weiterer Assistent gestartet, mit dem die VM zum Cluster hinzugefügt wird. Sie müssen hierfür keine weiteren Informationen eingeben. Die VM wird dann im Offline-Status im Cluster angezeigt und Sie können vor ihrem Start weitere Einstellungen konfigurieren. Die Konfiguration erfolgt über dieselbe Oberfläche, die auch in Hyper-V Manager zur Verfügung steht. Sie können in einem Cluster beliebige Gastbetriebssysteme ausführen, die von Microsoft Hyper-V unterstützt werden. Eine aktuelle Liste der unterstützten Windows Server-, Windows- und Linux- Gastbetriebssysteme können Sie hier abrufen. 15

16 Abbildung 5: Erstellung einer hochverfügbaren virtuellen Maschine Hinzufügen einer vorhandenen virtuellen Maschine zu einem Cluster Wenn Sie eine bereits vorhandene VM als hochverfügbare VM konfigurieren möchten, muss sie zunächst auf einen der Cluster-Knoten verschoben werden. Dies kann durch eine Live-Migration, einen Export- und Importvorgang oder die Wiederherstellung der VM über ein Backup erfolgen. Entscheidend ist, dass die virtuelle Festplatte der VM auf freigegebenen Speicher verschoben wird, der vom Cluster verwaltet wird. Sobald die VM auf einem Cluster-Knoten gehostet wird, kann mit dem Assistenten für hohe Verfügbarkeit der VM-Ressourcentyp gewählt und die VM damit als hochverfügbar konfiguriert werden. Wenn Sie Veeam Backup & Replication einsetzen, können Sie die VM im Cluster wiederherstellen und umgehend als hochverfügbar konfigurieren. Die VM wird nun über den Failovercluster-Manager verwaltet. Bei einem Ausfall ist ein Failover auf andere Knoten möglich. Migration einer virtuellen Maschine aus einem vorhandenen Cluster Wenn in Ihrer Umgebung bereits Cluster-VMs vorhanden sind, können Sie diese in einen neuen Cluster migrieren. Hierfür wird der Assistent zum Kopieren von Clusterrollen verwendet, der über den Failovercluster-Manager gestartet wird. Nach dem Start des Assistenten über Ihren neuen Cluster geben Sie den Quellcluster an und wählen anschließend in einer Liste die VMs aus, die darauf ausgeführt werden. Sie haben die Möglichkeit, Clusterspeicher und Netzwerkpfade neu zuzuweisen. Nach Abschluss der Migration können Sie die VM im alten Cluster offline schalten und die migrierte VM im neuen Cluster online schalten. 16

17 Erstellen eines Gast-Failover-Clusters Sie können für Ihre virtualisierten Workloads eine noch höhere Verfügbarkeit erzielen, indem Sie einen neuen Cluster auf Basis virtueller Server anstatt physischer Server erstellen. Dieser Vorgang wird als Gast-Clustering bezeichnet. Auf diese Weise kann eine auf der VM ausgeführte Anwendung wie SQL Server hochverfügbar sein, damit ihr Betrieb bei einem Ausfall der Workload, einem Absturz der VM oder einer Aktualisierung bzw. Wartung des Gastbetriebssystems nicht beeinträchtigt wird. Hierzu wird die Workload auf einen anderen virtuellen Cluster-Knoten verschoben. Ein Gast-Cluster wird nach denselben Schritten konfiguriert wie ein physischer Failover-Cluster. Es gilt jedoch einige zusätzliche Aspekte zu berücksichtigen: Workload Anstatt eine VM als hochverfügbare VM zu konfigurieren, führen Sie ein Clustering einer anderen Anwendung durch, die im Gastbetriebssystem der VM ausgeführt wird. Für diese Workload sind spezielle Konfigurationseinstellungen erforderlich. HINWEIS: Eine VM kann nicht auf einer anderen VM ausgeführt werden (wird auch als geschachtelte Virtualisierung bezeichnet). Speicher Die VMs müssen freigegebenen Speicher nutzen, damit alle virtuellen Cluster-Knoten auf die Daten zugreifen können. Die VMs können nur zu Speicher mit virtualisiertem HBA oder Ethernet-basiertem Speicher eine Verbindung herstellen, da sie nicht mit einem physischen Speicheradapter verbunden werden können. Microsoft Hyper-V stellt einen virtualisierten Fibre Channel-HBA bereit, über den die VM eine Verbindung zu einem solchen Speicher herstellen kann. Es gibt jedoch für Microsoft Hyper-V keinen virtualisierten SAS-Adapter (Serial-Attached SCSI). Die VM kann außerdem über iscsi, Fibre Channel over Ethernet oder eine SMB 3.0-Dateifreigabe eine Verbindung zum Speicher herstellen. Shared VHDX-Freigabe Zur Vereinfachung des Speichermanagements für einen Gast-Cluster kann allen Cluster-Knoten Zugriff auf eine einzelne LUN mit mehreren VHDX-Dateien (virtuelle Festplatte) gewährt werden. Jede dieser Festplatten kann als Speicherfreigabe fungieren, auf der Daten des Gast- Clusters gespeichert werden, beispielsweise die Datenbank für den virtualisierten SQL-Server. Nähere Informationen zur Konfiguration von Shared VHDX-Freigaben stehen hier zur Verfügung. 17

18 Management einer virtuellen Cluster-Maschine Für einen Failover-Cluster stehen zahlreichen Managementoptionen zur Verfügung. In diesem Abschnitt werden die Optionen beschrieben, die für Microsoft Hyper-V-Cluster relevant sind. Gruppen virtueller Maschinen Die einzelnen Workloads in einem Cluster sind in Gruppen organisiert, die jeweils verschiedene abhängige Ressourcen beinhalten und stets gemeinsam auf einen anderen Cluster-Knoten verschoben werden. Eine Cluster-Gruppe für eine VM umfasst die VM, die Konfigurationsdatei der VM und ihre Festplatte auf einer Speicherfreigabe (entweder ein freigegebenes Clustervolume oder eine herkömmliche Cluster-Festplatte). Bei einer Migration oder einem Failover der VM auf einen anderen Knoten wechselt auch der Besitz der Konfigurationsdatei und der Festplatte auf diesen Knoten über. Abbildung 6: Management verschiedener virtueller Cluster-Maschinen 18

19 Priorität beim Starten virtueller Maschinen Für den Start von Cluster-VMs kann die Priorität Hoch, Mittel, Niedrig oder Kein automatischer Start festgelegt werden. Mit diesen vier Einstellungen können Sie die VMs unterschiedlichen Verwaltungsgruppen zuordnen. Wenn ein Vorgang für eine Gruppe von VMs durchgeführt werden muss, wird mit dieser Einstellung festgelegt, dass der Vorgang zunächst für die VMs mit hoher Priorität, dann für die VMs mittlerer und niedriger Priorität und zuletzt für die VMs ohne automatischen Start durchgeführt wird. Zu den Vorgängen, bei denen die Priorität berücksichtigt wird, zählen das Starten von VMs auf einem Knoten, die Live-Migration einer Gruppe von VMs und das sukzessive Entfernen von VMs von einem Knoten, auf dem Wartungsarbeiten vorgenommen werden müssen. Bei einem Absturz Ihres Clusters können Sie so sicherstellen, dass Ihre Infrastruktur oder unternehmenskritischen VMs umgehend neu gestartet werden, ohne dass es zu Ressourcenkonflikten mit weniger wichtigen VMs kommt. Manche Administratoren nutzen die Einstellungen für die VM-Priorität auch, um VMs unterschiedlichen Ebenen zuzuweisen. Beispielsweise könnten Sie den VMs für Ihre Backend-Datenbank eine hohe Priorität zuweisen, den VMs der mittleren Ebene eine mittlere Priorität und den Frontend-Web-VMs eine niedrige Priorität, sodass diese zuletzt gestartet werden. Zusätzlich könnten Sie eine Überbrückungszeit einstellen, damit die Backend-Dienste vollständig online sind, bevor Clients Zugriff auf das System erhalten. Die Einstellung Kein automatischer Start wirkt sich etwas anders aus, da VMs mit dieser Priorität nach einem Ausfall des Hosts nicht automatisch gestartet werden. So können zunächst wichtigere VMs wieder online geschaltet werden. Beachten Sie bitte, dass VMs mit der Einstellung Kein automatischer Start vom Cluster-Administrator manuell gestartet werden müssen. Abbildung 7: Festlegen der Priorität für den Start einer virtuellen Maschine 19

20 Platzierung von virtuellen Maschinen auf Hosts Beim Failover-Clustering unter Windows Server müssen die einzelnen Hosts nicht über identische Hardware verfügen. Sie müssen lediglich sicherstellen, dass die gesamte Lösung alle Cluster- Überprüfungstests besteht. Da manche Hosts unter Umständen leistungsstärker sind als andere oder mit unterschiedlicher Geschwindigkeit auf den Speicher zugreifen, können Sie festlegen, dass bestimmte VMs auf bestimmten Hosts ausgeführt werden. Mit der Einstellung Bevorzugte Besitzer können Sie bestimmen, auf welchem bzw. welchen Cluster- Knoten eine VM ausgeführt werden soll. Wenn Knoten mit diesen bevorzugten Besitzern online sind, wird die VM auf diesen Knoten gehostet. Ist kein Knoten mit den bevorzugten Besitzern online, wird die VM auf einen anderen aktiven Host verschoben. Die VM kann auf einem beliebigen Cluster-Knoten ausgeführt werden und zusätzliche Failover-Optionen bereitstellen, da standardmäßig keiner der Knoten als bevorzugter Besitzer festgelegt wurde. Abbildung 8: Konfiguration der bevorzugten Besitzer für eine Cluster-VM 20

21 Mit der Einstellung Mögliche Besitzer legen Sie fest, ob die VM überhaupt auf einem Knoten ausgeführt werden darf. Ist keiner der Knoten, der zu den möglichen Besitzern gehört, verfügbar, bleibt die VM offline und wartet, bis wieder ein entsprechender Knoten online ist. Standardmäßig sind alle Cluster-Knoten als mögliche Besitzer konfiguriert, d. h. die VM kann auf einem beliebigen Cluster- Knoten ausgeführt werden. So kann eine höhere Verfügbarkeit erzielt werden. Mit PowerShell oder System Center Virtual Machine Manager können Sie VMs einem Verfügbarkeitssatz zuweisen. Alle VMs in dieser Gruppe versuchen dann eigenständig, sich auf unterschiedliche Hosts zu verteilen und so eine höhere Verfügbarkeit sicherzustellen. Wenn Sie zwei oder mehr virtualisierte Domänencontroller verwenden, ist es ratsam, diese VMs einem Verfügbarkeitssatz hinzuzufügen, damit nicht alle auf demselben Host ausgeführt werden und einzelne Fehlerquelle vermieden werden. Neben der Gruppierung von VMs nach ihrer Rolle besteht ein typischer Anwendungsfall auch darin, alle Knoten aus demselben (virtualisierten) Gast-Cluster einem Verfügbarkeitssatz zuzuordnen. Die Gast-Cluster- Knoten werden dabei auf unterschiedliche physische Knoten verteilt. Fällt ein physischer Knoten aus, so hat dies nicht den Ausfall des gesamten Gast-Clusters zur Folge. Diese Einstellung können Sie mit PowerShell über die Eigenschaft AntiAffinityClassName vornehmen. Weitere Informationen zu diesem Thema finden Sie in diesem Blog. Eine weitere Einstellung für die Platzierung auf dem Host, die für Sie relevant sein könnte, ist die Einstellung Failback. Sie können damit festlegen, ob die VMs wieder auf dem ursprünglichen Host oder weiter auf dem neuen Host ausgeführt werden sollen, wenn der Knoten nach einem Ausfall wieder betriebsbereit ist. Zwar werden die VMs zur Vermeidung von Ausfallzeiten durch Live-Migration verschoben, doch erhöht sich durch ein Failback der Netzwerkverkehr während einer Live-Migration, weshalb die Einstellung standardmäßig deaktiviert ist. Offline-Einstellungen für virtuelle Maschinen Aufgrund ungeplanter Ausfallzeiten oder geplanter Wartungsmaßnahmen werden Cluster- Knoten gelegentlich offline geschaltet. Ist ein bevorstehender Ausfall bekannt, empfiehlt es sich, die VMs durch Live-Migration auf einen anderen Host zu verschieben, um Ausfallzeiten zu vermeiden. Bei einem ungeplanten Ausfall des Hosts, beispielsweise bei einem Stromausfall oder BlueScreen, werden die VMs abgeschaltet und abhängig von den Einstellungen für die Host-Platzierung auf einem anderen Cluster-Knoten oder auf demselben Knoten neu gestartet. Eine Rolle spielt in diesem Zusammenhang auch, ob als Priorität für die VM die Einstellung Kein automatischer Start gewählt wurde, da in diesem Fall nach einem Absturz des Hosts einer manueller Neustart der VM erforderlich wäre. Auf der Registerkarte Richtlinien werden unter den Eigenschaften verschiedene Einstellungen für den Neustart einer VM nach einem Ausfall angezeigt. In der Regel soll eine VM umgehend neu gestartet werden; Sie können jedoch auch einstellen, dass die VM erst nach einer gewissen Verzögerung neu gestartet wird, damit Sie eine Problemdiagnose vornehmen oder zunächst abhängige Dienste wieder neu starten können. 21

22 Auf der Registerkarte Einstellungen können Sie festlegen, wie eine VM heruntergefahren wird, wenn der Cluster die Ressource offline schaltet. Standardmäßig wird mit der Option Speichern der Arbeitsspeicher der VM mit einem Commit an die Festplatte übergeben. Es stehen außerdem die Optionen Herunterfahren, Herunterfahren erzwingen und Ausschalten zur Verfügung, mit denen die VM entweder kontrolliert heruntergefahren oder sofort ausgeschaltet wird. Überwachen virtueller Maschinen Ein Vorteil der Ausführung von Anwendungen in einem Cluster besteht darin, dass der Cluster eine Workload mit dem Mechanismus Heartbeat regelmäßig überprüft und neu startet, falls sie angehalten wurde, nicht mehr reagiert oder ausgefallen ist. Mit der Heartbeat-Überwachung von Hyper-V-VMs in einem Cluster können Sie mit einer zusätzlichen Integritätsprüfung sicherstellen, dass eine VM ordnungsgemäß funktioniert. Dabei wird überprüft, ob das Gastbetriebssystem möglicherweise nicht mehr reagiert oder eingefroren ist, selbst wenn die VM auf den ersten Blick ohne Einschränkungen funktioniert. In Windows Server 2012 R2 sind diese beiden Einstellungen standardmäßig aktiviert. In älteren Versionen mussten sie durch Anpassung der Eigenschaften der VM im Cluster konfiguriert werden. Abbildung 9: Konfiguration der Offline-Aktionen und Heartbeat-Einstellungen für eine Cluster-VM 22

23 Wenn Sie Zugriff auf das Gastbetriebssystem der VM mit Windows 8, Windows Server 2012 oder einer höheren Version haben, können Sie mit einer zusätzlichen Einstellung festlegen, dass alle im Gastbetriebssystem ausgeführten Windows-Dienste über den Cluster-Knoten überwacht werden können. So können Sie erweiterte Wiederherstellungsaktionen für diesen Dienst durchführen, dessen Ausfall andernfalls unter Umständen niemals erkannt worden wäre. Hierzu gehören das Neustarten des Dienstes oder der VM bzw. das Verschieben der VM auf einen anderen Host. Die VM-Überwachung muss sowohl auf dem Host als auch auf der VM konfiguriert werden. Die hierfür erforderlichen Schritte sind in diesem Blog dokumentiert. Integritätsprüfungen für Cluster-Knoten Nach der Bereitstellung müssen Sie testen, wie gut die VMs unter produktiven Bedingungen funktionieren, insbesondere wenn die Bandbreite in Ihren Netzwerken beschränkt ist. Mit einem einfachen Mechanismus, der aus einer Anforderung und einer Antwort besteht, führt der Cluster eine Integritätsprüfung für die Cluster-Knoten durch. Langsame Netzwerke könnten die Zuverlässigkeit der Knoten beeinträchtigen. Diese Einstellungen sind konfigurierbar. Ein Hyper-V-Cluster unterscheidet sich hinsichtlich dieser Einstellungen von anderen Cluster-Typen, bei denen alle fünf Sekunden eine Integritätsprüfung durchgeführt wird. In einem Hyper-V-Cluster werden Integritätsprüfungen alle zehn Sekunden für alle Knoten in einem Subnetz und alle 20 Sekunden für Knoten in anderen Subnetzten durchgeführt. Einmal pro Minute erfolgt eine gründlichere Integritätsprüfung. Reagiert ein Knoten mehrmals nacheinander nicht auf eine Integritätsprüfung, so gilt er als ausgefallen. Ursache hierfür könnte der Netzwerkverkehr sein, selbst wenn der Knoten eigentlich betriebsbereit ist. Die Standardeinstellungen sind für die meisten Cluster geeignet. Abhängig von der verfügbaren Bandbreite, der Anzahl der Netzwerke, der Entfernung zwischen den Knoten und dem Netzwerkverkehr sollten diese Einstellungen jedoch unbedingt unter produktiven Bedingungen getestet werden. Gegebenenfalls ist eine Anpassung der Integritätsprüfungen erforderlich. 23

24 Abbildung 10: Konfiguration der Integritätsprüfungen für Cluster-Knoten Wartung der Knoten Wenn Sie für einen Cluster-Knoten planmäßige Wartungsarbeiten durchführen müssen, können Sie mit einem einfachen Schritt eine Live-Migration aller VMs auf dem Knoten vornehmen. Wählen Sie den Knoten aus und wählen Sie anschließend die Option Anhalten und bei Bedarf Rollen ausgleichen. Beim Anhalten eines Knotens wird dieser in den Wartungsmodus versetzt, d. h. er wird nicht von anderen VMs als Failover-Knoten verwendet. Wenn Sie die Option Rollen ausgleichen wählen, führt der Cluster eine Live-Migration der VMs auf andere Cluster-Knoten durch. Ausschlaggebend ist dabei ihre Priorität. Um den Wartungsmodus eines Knotens zu beenden, wählen Sie den Knoten aus und wählen anschließend die Option Fortsetzen. Sie können außerdem mit der Option Failback für Rollen ausführen festlegen, dass eine Live-Migration der ursprünglich auf diesem Knoten gehosteten VMs durchgeführt wird. Die Eigenschaft DrainOnShutdown, die für den gesamten Cluster verwendet wird, ist standardmäßig aktiviert. Wenn ein Administrator einen Hyper-V-Host herunterfährt, verzögert sich das Herunterfahren, bis die Live-Migration der VMs von diesem Host auf andere Knoten (zuerst werden die VMs mit der Priorität Hoch migriert) abgeschlossen ist. Dadurch lassen sich Ausfallzeiten vermeiden, wenn ein Administrator versucht, einen Cluster-Knoten herunterzufahren, ohne zu wissen, dass darauf VMs ausgeführt werden. 24

25 Abbildung 11: Aktivieren des Wartungsmodus für einen Knoten Clusterfähiges Aktualisieren Die Software und Hardware Ihrer VMs muss durch das Einspielen von Patches stets auf dem neuesten Stand gehalten werden. Hierfür steht unter Windows Server 2012 die Funktion Clusterfähiges Aktualisieren zur Verfügung, die das regelmäßige Installieren von Patches sowohl auf dem physischen als auch auf dem (virtuellen) Gast-Cluster automatisiert. Die Funktion kann lokal oder per Fernzugriff ausgeführt werden und ermöglicht eine zentrale Verwaltung der Cluster-Aktualisierungen. Sie stellt eine Verbindung zu einem Windows Server Update Services-Server oder Windows Update her. Bei der Aktualisierung werden folgende Schritte ausgeführt: 1. Der Administrator erstellt eine Sammlung von Aktualisierungen, die sogenannte Baseline für den Cluster. 2. Die Funktion für das clusterfähige Aktualisieren gleicht die Aktualisierungen eines Knotens mit der Baseline ab und ermittelt so die Knoten, auf denen Patches installiert werden müssen. 3. Anschließend wird der Knoten mit den wenigstens Workloads ausgewählt, um den Betrieb so wenig wie möglich zu beeinträchtigen. Über die Option Anhalten wird der Knoten in den Wartungsmodus gesetzt und anschließend eine Live-Migration der VMs auf andere Knoten durchgeführt. 4. Nachdem alle VMs vom Knoten migriert wurden, werden die Aktualisierungen heruntergeladen und auf den Knoten angewendet. Dieser wird anschließend neu gestartet (falls erforderlich). 5. Sobald der Knoten nach dem Neustart wieder online ist, überprüft die Funktion, ob die Patches erfolgreich installiert wurden und der Cluster-Knoten ordnungsgemäß funktioniert. 6. Mit der Option Fortsetzen wird der Wartungsmodus beendet, sodass wieder neue VMs auf dem Knoten gehostet werden können. HINWEIS: Dieser Vorgang wird für alle Knoten im Cluster wiederholt. 25

26 Tritt dabei ein Fehler auf, wird das Installieren der Patches ausgesetzt und der Administrator benachrichtigt. Auf diese Weise wird sichergestellt, dass eine fehlerhafte Aktualisierung nicht auf alle Knoten im Cluster angewendet wird. Die Funktion für das clusterfähige Aktualisieren verfügt außerdem über einen Selbstaktualisierungsmodus, der die Ausführung der Funktion in dem Cluster ermöglicht, in dem gerade Patches installiert werden. So kann der Aktualisierungsdienst selbst auf andere Cluster- Knoten verschoben werden, sobald diese neu gestartet wurden, sodass keine spezielle Infrastruktur für die Installation von Patches erforderlich ist. Sicherheit von virtuellen Cluster-Maschinen Für den Schutz virtualisierter Umgebungen vor Viren, Schadsoftware und anderen Bedrohungen müssen andere Vorkehrungen getroffen werden als in herkömmlichen Rechenzentren, in denen die Hardware in der Regel statisch ist. In virtualisierten Umgebungen können durch Endpoint-Sicherung ganz einfach Agenten auf den Servern installiert und verwaltet werden. Virtualisierte Umgebungen erfordern ein anderes Sicherheitsmanagement als herkömmliche Rechenzentren, da virtuelle Maschinen, Festplatten und Netzwerke dynamisch sind und sich ständig ändern können. Meist ist es wenig praktisch, auf allen VMs Sicherheitsagenten zu installieren. 5nine Cloud Security stellt als einziger Anbieter eine agentenlose Antiviren-, Firewall- und Angriffserkennungslösung für Microsoft Hyper-V bereit. Diese Sicherheitssoftware filtert den ein- und ausgehenden Datenverkehr der VMs über eine Erweiterung zum virtuellen Switch. Damit ist optimaler Schutz bereits auf der Host-Ebene gewährleistet, bevor eine Bedrohung überhaupt bis zur VM durchdringt. Die Sicherheit wird somit zentral verwaltet und der VM-Nutzer muss sich nicht um die Aktualisierung oder Überprüfung des Gastbetriebssystems kümmern, unabhängig davon, ob es auf Windows Server, Windows oder Linux basiert. Weitere Informationen hierzu finden Sie auf der Website von 5nine Cloud Security. Replikation von virtuellen Cluster-Maschinen Mit Windows Server 2012 wurde eine neue Funktion für Microsoft Hyper-V eingeführt, die ein Disaster Recovery für Hyper-V-VMs ermöglicht, indem virtuelle Festplatten in einem anderen Rechenzentrum oder auch in Microsoft Azure repliziert werden. Die Funktion Hyper-V-Replikat muss für alle Server oder Cluster-Knoten aktiviert werden, die Host oder Zielsystem für eine replizierte VM sind. Sie können jede VM zu Replikationszwecken individuell konfigurieren und testen und anschließend alle 30 Sekunden, 5 Minuten oder 15 Minuten eine Kopie der Daten asynchron an das Zielsystem senden. Bei der Konfiguration des Hyper-V-Replikats auf einem Failover-Cluster wird hingegen eine neue Cluster-Workload erstellt, der sogenannte Hyper-V-Replikatbroker. Hierbei handelt es sich um eine hochverfügbare Version des Replikationsdienstes, d. h. das Replikationsmodul führt ein Failover zwischen den Cluster-Knoten durch, damit sichergestellt ist, dass die Daten auch tatsächlich repliziert werden. HINWEIS: Wenn Sie die Replikation auf einem Cluster konfigurieren, sollten Sie die virtuellen Festplatten nicht auf einer lokalen Festplatte, sondern auf einer Speicherfreigabe speichern. 26