Drücke "Enter", um den Text zu überspringen.

Schlagwort: Failover

Azure – Account Failover für Storage Accounts in der Preview

Wie Microsoft in seinem Blog-Artikel angekündigt hat, ist das „Account Failover“ Feature für den Storage Account nun in der Public Preview. Aber worum handelt es sich hier überhaupt?

Schon seit Längerem bieten Storage Accounts die Möglichkeit, die Daten georedundant vorzuhalten. Dabei werden in den Optionen ZRS, GRS und RA-GRS (und neuerdings auch GZRS) die Daten (die am primären Speicherort schon 3-fach vorgehalten werden) in ein anderes Azure Rechenzentrum in der selben Region (ZRS) oder in einer anderen Region gespiegelt. Dies geschieht allerdings asynchron, d.h., bei einem Ausfall in der Ursprungsregion kann es sein, dass nicht alle Daten vollständig gespiegelt worden, somit kann es zu Datenverlust kommen.

Schreibe einen Kommentar...

Windows Server 2012 R2: Einrichten eines Failover-Clusters am Beispiel Hyper-V

Ein Failover-Cluster ist eine gute Sache: Er sorgt für Hochverfügbarkeit! Damit lassen sich diverse Dienste geclustert betreiben. Mehrere Server teilen sich eine Aufgabe und die dazugehörige Last. Fällt nun einer der beteiligten sogenannten “Knoten” aus, so übernehmen die verbliebenen die Aufgabe sofort automatisch. Damit lässt sich beispielsweise auch Hyper-V bzw. die darauf laufenden virtuellen Maschinen gegen einen Ausfall absichern.

Für eine Minimal-Konfiguration werden benötigt:

  • Ein Domänencontroller
  • Zwei weitere Server als Mitglied der Domäne
  • Zentraler Speicher

Für den zentralen Speicher kämen die beiden SAN-Technologien iSCSI und FiberChannel in Frage. Optional geht seit Server 2012 auch SMB3.0 (“Scale Out File Server”). Für eine Testumgebung ist iSCSI sehr gut geeignet. Wie man ein iSCSI-Target einrichtet und den dazugehörigen Initiator nutzt habe ich in einem meiner letzten Blogartikel beschrieben (Windows Server 2012 R2: iSCSI Target und Initiator einrichten).

Der Domänencontroller sowie die beiden Member-Server laufen unter Windows Server 2012 R2.

Es werden 2 iSCSI-Targets benötigt, eines mit min. 512MB Speicher, das zweite mit ausreichend Speicher für die vorgesehenen VMs und deren VHD(X)-Dateien, in meinem Fall 40GB. Die beiden Targets müssen bereits auf beiden Knoten eingebunden sein, die beiden Datenträger online geschaltet worden sein, initialisiert und formatiert (ohne Laufwerksbuchstaben).

Weiterhin muss das Netzwerk sauber konfiguriert sein. Für eine Testumgebung reicht es, wenn die beiden Hosts über genau eine Netzwerkverbindung verfügen. Dort muss das selbe Subnetz eingerichtet sein, ebenso ein passender DNS-Server und ein Gateway. Für Produktivzwecke empfehlen sich deutlich mehr Netzwerkverbindungen, z.B. eine dedizierte für den Heartbeat (Link zwischen den Knoten), eine für die Anbindung an das Storage, eine für die Verwaltung, eine für die Anbindung an das reguläre Netzwerk und so weiter und so fort.

Als nächstes muss auf allen künftigen Knoten das Feature “Failoverclustering” installiert werden. Dazu werden auch die Verwaltungstools angeboten, die zumindest auf einem System installiert sein müssen, um den Cluster einrichten zu können:

Wenn die Installation auf beiden/allen künftigen Knoten abgeschlossen ist kann der “Failovercluster-Manager” gestartet werden, z.B. über “Tools” im Servermanager:

Dort wird durch einen Rechtsklick auf das Wort “Failovercluster-Manager” im Baum links mittels “Cluster erstellen…” der Prozess begonnen:

In den ersten Schritten sind die künftigen Knoten auszuwählen:

 

Danach folgt eine Abfrage bezüglich des “Konfigurationsvalidierungstests”. Dabei werden die beteiligten Server “auf Herz und Nieren geprüft”. Dieser Test dauert ca. 10 Minuten. Man könnte ihn abschalten – verzichtet dann auber auf den Support durch Microsoft und wertvoll Hinweise zur Konfiguration. Nicht zuletzt kann der Test einem auch Fehler aufzeigen, die man bei der Vorbereitung übersehen hat. Ich würde ihn also immer laufen lassen…

Am Ende des Tests wird einem das Ergebnis angeboten (“Bericht anzeigen”):

In diesem Fall liegt nur eine Warnung vor: Es gibt nur eine Netzwerkverbindung!

Nun muss noch ein Name für den Cluster sowie eine entsprechende IP-Adresse bestimmt werden. Außerdem kann man auswählen, dass der gesamte verfügbare Speicher dem Cluster hinzugefügt werden soll:

Danach beginnt die eigentliche Bildung des Clusters. Ist diese abgeschlossen, kann die Clusterkonfiguration verändert werden bzw. der Cluster mit Rollen ausgestattet werden. Dabei ist zum einen die Netzwerkkonfiguration zu prüfen: Wenn es einen dedizierten Link zwischen den Hosts geben soll, so ist bei dieser Netzwerkkonfiguration der Haken “Clients das Herstellen einer Verbindung…” zu entfernen. Weiterhin muss das zweite iSCSI-Target noch als “Cluster Shared Volume” (CSV) bzw. al “freigegebenes Clutservolume” hinzugefügt werden. Das sorgt dafür, dass dieses “Laufwerk” auf allen Clutserknoten unter C:\ClusterStorage eingebunden wird und dort genutzt werden kann (z.B. für die VMs und VHDs)

Abschließend können nun VMs im Cluster erzeugt werden. Dabei ist darauf zu achten, das alle relevanten Daten unter C:\ClusterStorage liegen!

Wenn die VM fertig konfiguriert ist und läuft, dann kann man ganz einfach die Funktionsfähigkeit des Clusters testen und einen einfachen Ausfall simulieren: Man zieht einfach das Netzwerkkabel aus dem Host heraus, auf dem die VM aktuell ausgeführt wird. Dann sollte sie in kurzer Zeit auf dem verbliebenen Host neu gestartet werden und dann kurz darauf wieder regulär zur Verfügung stehen!

Schreibe einen Kommentar...

Walk-Through: DHCP-Failover mit Windows Server 2012

Der Windows Server 2012 bringt eine Funktion mit sich, auf die man bisher nur über die Umwege eines Clusters und den damit verbundenen höheren Anforderungen (Server 2008 Enterprise-Edition, shared Storage, …) nutzen konnte. Die Rede ist von DHCP-Failover, welches im Windows Server unabhängig von der verwendeten Edition und vollkommen ohne Cluster genutzt werden kann. Notwendig sind lediglich zwei Windows Server 2012 mit aktivierter DHCP-Server-Rolle. Auf einem der beiden Server sollte bereits ein Bereich (“Scope”) eingerichtet sein, beide Server müssen im AD autorisiert sein.

Im Folgenden möchte ich die Einrichtung des Failovers im Modus “Load-Sharing” erläutern und Schritt für Schritt mit Bildern darstellen. Neben diesem Modus, welcher sich insbesondere dann eignet, wenn die beiden Server in der selben physischen Lokation stehen, steht als zweite Option die Variante “Hot Standby” zur Verfügung. Dieser Modus eignet sich z.B. dann, wenn im Fehlerfall ein DHCP-Server von einem anderen Standort den Standort des ausgefallenen DHCP-Servers versorgen soll.

Eine potentielle Fehlerquelle beim Einrichten der Failover-Beziehung ist die Zeit. Diese muss auf beiden Partnern synchron sein. Eine Abweichung von mehr als 60 Sekunden sorgt beim Einrichten für einen kritischen Fehler. Diese Tolleranz darf auch im täglichen Betrieb nicht überschritten werden.

Nun zur eigentlichen Anleitung:

Bereits vorbereitet sind hier zwei installierte DHCP-Server “SRV1” und “SRV2”, welche beide bereits im AD autorisiert sind. Auf dem ersten Server “SRV1” wurde bereits ein Bereich für das Subnetz 192.168.200.0/24 angelegt:

Das Failover erfolgt immer Bereichs-weise und kann durch einen Rechtsklick auf den gewünschten Bereich eingerichtet werden:

Im ersten Schritt des sich nun öffnenden Assistenten werden nochmal die bzw. der DHCP-Bereich abgefragt, welcher im Failover-Betrieb verwendet werden soll:

Im zweiten Schritte muss der Partnerserver bestimmt werden. Dabei fällt auf, dass pro Bereich nur ein Partner-Server zulässig ist. Wenn es bereits früher eine Failover-Beziehung zwischen den beiden gewählten Servern gab, so könnte man diese wieder “reaktivieren”:

Im nächsten Schritt sind die weiteren Parameter der Failover-Beziehung festzulegen:

Hierbei können festgelegt werden:

  • Der Name der Beziehung – ist eigentlich klar
  • Die “Maximale Clientvorlaufzeit” (Maximum Client Lead Time)
    • Dieser Wert gibt die vorübergehende Lease-Dauer an, die für Leases gilt, welche im Failover-Fall (“Partner down”) vom Partner-Server vergeben werden; nach dem diese Zeit verstrichen ist, übernimmt der Partnerserver den Bereich vollständig. Standardwert ist eine Stunde, kann aber z.B. auch auf 0 gesetzt werden
  • Modus
    • “Lastenausgleich” oder “Hot Standby” wie bereits oben beschrieben
    • Beim Lastenausgleich-Modus kann die Verteilung der Last auf die beiden Server festgelegt werden; Standard ist 50/50
    • Beim Modus “Hot Standby” ist hier stattdessen festzulegen, welche Rolle der Partnerserver übernimmt (“Aktiv” oder “Standby”) sowie der Anteil der für den Standby-Server reservierten Adressen (Standard: 5%). Dieser Anteil wird während der “Maximalen Clientvorlaufzeit” verwendet, bis der Standby-Server die volle Kontrolle übernommen hat
  • Intervall für Zustands-Switchover
    • Hier kann man festlegen, wie viel Zeit nach einem Wechsel in den Zustand “Communication interrupted” (Verbindung zwischen den beiden Partnern unterbrochen) vergehen soll, ehe zum Zustand “Partner down” übergegangen werden soll; standardmäßig ist dieser automatische Übergange abgeschalten, so dass der Administrator den Zustand “Partner down” händisch einleiten muss
  • Nachrichtenauthentifizierung aktivieren
    • Wenn diese Option eingeschalten ist, werden die Kommunikationen zwischen den beiden Partnern mit Hilfe von SHA-256 verschlüsselt. Zusätzlich wird eine Authentifizierung auf Basis von SHA-2 durchgeführt, um sicherzustellen, das kein unberechtigter Dritter Daten abfängt oder einschleust.
    • Wenn diese Option aktiviert ist, muss in der untersten Eingabezeile ein “Gemeinsamer geheimer Schlüssel” festgelegt werden, welcher vom Assistenten an beide Server gesendet wird und später nirgendwo erneut eingegeben werden muss

Als letzter Schritt folgt eine Zusammenfassung der gesetzten Einstellungen:

Nach einem Klick auf “Fertig stellen” wird die Failover-Beziehung eingerichtet und zum Schluss erscheint eine Erfolgs-Meldung:

Wenn man nun die GUI des DHCP-Tools aktualisiert, kann man beim SRV2 ebenso den bereits auf dem SRV1 eingerichteten Bereich sehen, in dem auch alle bereits vergebenen Leases und Reservierungen vorhanden sind:

Die Eigenschaften der verschiedenen Failover-Beziehungen lassen sich nachträglich in den Eigenschaften des jeweiligen Protokolls (“IPv4” bzw. “IPv6”) einsehen und ändern:

Für die Failover-Konfiguration ist im DHCP-Standard ein Austausch der Leases vorgesehen – nicht aber eine stetige Synchronisierung der Konfigurationen. Da aber beide Server einer Failover-Beziehung identisch konfiguriert sein sollten, ist nach einer Konfigurationsänderung ein Abgleich nötig:

Dabei kann entweder nur der gewählte Bereich abgeglichen werden (“Bereich replizieren…”) oder aber alle Bereiche, die in dieser Failover-Beziehung existieren (“Beziehung replizieren…”)

Wenn nun einer der beiden Kommunikationspartner ausgefallen ist, so wird dies durch Symbolik im DHCP-Manager angezeigt und ist auch in den Eigenschaften des Protokolles zu sehen:

Außerdem wird ein Eintrag im Ereignisprotokoll mit der ID 20252 angelegt:

In den Eigenschaften der Failover-Beziehung kann nun der Zustand von “Datenübertragung unterbrochen” auf “Partner nicht verfügbar” manuell geändert werden:

Ist der ausgefallene Server wieder verfügbar, geht die Verbindung in den Zustand “Wiederherstellen (warten)” über:

2 Comments