Cluster Fault Domains & Site Awareness

Mit Windows Server 2016 werden zwei neue Optionen eingeführt, die einen Betrieb von Failover Clustern in Rechenzentren vereinfachen und bereichern: Site Awareness und Fault Domain Awareness.

Site Awareness und Fault Domain Awareness
Cluster Knoten in einem Clusterverbund, die örtlich verteilt betrieben werden, sei es in verschiedenen Brandabschnitten, Räumen, Gebäuden oder Städten, können nun über Bordmittel entsprechend konfiguriert werden.
So können bei einem 4-Knoten-Cluster zwei der Knoten einer Örtlichkeit „A“ (Site) zugewiesen werden, die zwei verbleibenden der Örtlichkeit (Site) „B“.

Falls eines der beiden RZs oder Räume lediglich passive Standby-Knoten als Hot Standby Server beherbergen soll, so kann dem Rechnung getragen werden: Mittels „Preferred Site“ kann konfiguriert werden, dass es eine primary Site gibt, die die Ressourcen bevorzugt hosten soll. Dies kann per Powershell Kommando „(Get-Cluster).PreferredSite“ definiert werden und stellt sicher, dass der Cluster nach einer geplanten Wartung wieder alle Ressourcen an der bevorzugten Site betreibt. Dies betrifft auch das Quorum, das bevorzugt an der primären Site gehostet wird.

Der Cluster erhält damit auch ein Mittel, um zu erkennen, ob eine Site verfügbar oder in Gänze ausgefallen ist.

Rack und Blade Server Awareness
Die Entitäten Node, Chassis, Rack und Site sind konfigurierbar.
Damit kann man auch von einer Rack Awareness sprechen – selbst Chassis sind definierbar: Das ist vor allem für den Einsatz von Blade Servern sinnvoll, bei denen mehrere Clusterknoten in demselben Chassis laufen und eine Verteilung auf mehrere Chassis gewünscht ist.

Bei Bedarf kann auch eine absichtliche Verteilung von Ressourcen-Gruppen desselben Clusters auf zwei unterschiedliche Sites erreicht werden – dies erfolgt ebenfalls mittels PowerShell, hier lautet das passende Kommando „(Get-ClusterGroup -Name {RessourcenGruppeA}).PreferredSite“.

Folgende Regeln hält dabei ein Cluster ein:
– Bei einem Fehler bzw. Ausfall eines Knotens in Site A wird zuerst versucht die Ressourcen auf einen weiteren Knoten derselben Site zu schwenken. Dies betrifft auch geplante Aktionen wie ein Node Drain, auch hier werden Knoten derselben Site bevorzugt genutzt.
– Bei einem Fehler bzw. Ausfall einer VM auf einem Hyper-V Cluster wird zuerst versucht die VM auf einen Knoten zu schwenken, der derselben Site wie die Storage angehört.

Die Site Awareness wird über sogenannte Fault Domains realisiert, daher lautet der Name für dieses neue Windows Server 2016 feature: Fault Domain Awareness.

Im Prinzip erhält damit ein Windows Cluster über einfach zu konfigurierende Mittel eine gewisses Maß an Eigenintelligenz, um zu entscheiden, wann Ressourcen im gleichen Brandabschnitt, Raum oder RZ verfügbar gehalten werden sollen und an welcher Stelle ein geordneter Schwenk zu einer weiteren Örtlichkeit sinnvoll ist.

Cosmos Darwin hat das Feature hier vorgestellt:
https://technet.microsoft.com/(…)/fault-domains

Dieses Feature macht ein Clustern von Blade Servern erst sinnvoll.

Eine echte Bereicherung für den stabilen Betrieb von Stretched-, Metro- oder Geo-Clustern.

Stay tuned,
N.Own

Windows Server 2016 ist RTM!

Kurzmitteilung

Am gestrigen Montag nachmittag (26.09.16) war es wie angekündigt soweit: Windows Server 2016 ist fertig – die RTM Version ist pünktlich zur „Ignite“ erschienen:

» https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/

Die Evaluation-Version ist bereits als Download online, für die Allgemeinheit wird der neue Server 2016 ab Mitte Oktober verfügbar sein.

//Update 12.10.2016: Heute hat Windows Server 2016 General Availability (GA) erreicht – somit ist der Download auf MSDN verfügbar.

Stay tuned,
N.Own

Storage Performance Test

Als Alternative zu IOmeter kann auch ein aktuelles Microsoft-Tool zum Einsatz kommen, das Performance-Tests von lokalen Festplatten und SSDs (DAS), LUNs einer SAN, Storage Spaces oder SMB Freigaben ermöglicht: » DiskSPD (https://aka.ms/DiskSpd)

Dabei läuft das Tool auf 32-Bit, 64-Bit und ARM Versionen von Windows sowohl auf physikalischen Servern als auch innerhalb einer VM. Das kommandozeilenbasierte DiskSPD („disk speed“) kann ähnlich wie IOmeter verteilte random I/Os erzeugen und messen, ebenso können eigene Workloads definiert werden.

DiskSpd ist open source (MIT License); das Projekt findet man auf GitHub:
» GitHub.com/Microsoft/Diskspd
Das Tool bietet eine Fülle von Möglichkeiten Parameter für einen Workload zu definieren. Weiterführende Informationen dazu findet man in der Dokumentation auf GitHub (» DOC und » PDF Format).

Im Gegensatz zu IOmeter, dessen Entwicklung seit 2006 weitgehend stagniert, und dem abgekündigten SQLIO wird DiskSPD derzeit aktiv weiterentwickelt und zeigt mit VMfleet auch Workloads für den kommenden Windows Server 2016. Diskspd läuft auch unter der Windows Server 2016 deployment option Nano Server.

Wer ein neues Storage-System in der eigenen Umgebung auf Herz und Nieren hinsichtlich Bandbreite, Durchsatz und IOPS mit verschiedenen Lastprofilen testen möchte, für den stellt DiskSPD eine gute Alternative zu IOmeter, IOzone oder Vdbench dar.

Stay tuned,
N.Own

Heads-Up: Migration FRS zu DFS-R

Dieser Beitrag ist der Erste aus der Serie „Heads Up!“, die Themen bespricht, die beachtenswert sind für einen Windows Server oder Windows Server Failover Cluster Betrieb.
Sinn und Zweck soll es sein Euch einen Hinweis und eine Empfehlung an die Hand zu geben, nicht in eine bereits allgemein bekannte Falle zu geraten.

In dieser Folge aus der Reihe „Heads Up!“ geht es um einen Mechanismus, der seine Tätigkeit in einer Active Directory Domäne im Hintergrund erledigt und meist wenig Beachtung findet: Der File Replication Service (FRS).
Der Dienst verrichtet die wichtige Aufgabe Gruppenrichtlinien (Sysvol) sowie Skripte (Netlogon) auf alle Domänen Controller innerhalb einer Domäne zu replizieren, um diese für die Clients an der jeweiligen AD Site zur Verfügung zu stellen.
Dabei hat der FRS Dienst die ehemalige „LAN Manager Replication“ (LMRepl) beerbt: Für die, die das noch unter Windows NT 3.x/NT 4 kennen:
https://technet.microsoft.com/en-us/library/cc962213.aspx

Heads Up: Der FRS ist seit Windows Server 2012 abgekündigt (deprecated) und es wurde schon mit Erscheinen der Windows Version eine Empfehlung abgegeben auf DFS-R zu migrieren.
Nachdem ich schon einige Windows Server 2012 Umgebungen gesehen habe, in denen FRS immer noch seinen Dienst verrichtet und die nächste Major Version in Form von Windows Server 2016 vor der Tür steht, sollte man bald der Empfehlung nachkommen und seine Domäne „Windows vNext Ready“ gestalten.

Der geschätzte Microsoft Mitarbeiter Ned Pyle hat das im Jahr 2014 aufgegriffen und einen detaillierten Aktionsplan für Umsteiger geschrieben:
Ned Pyle’s Streamlined Migration of FRS to DFSR SYSVOL
http://blogs.technet.com/(…)streamlined-migration-of-frs-to-dfsr(…)

Prüft Eure Umgebung, die Gesamtstrukturebene sowie die Domänenebene und wenn alle Voraussetzungen erfüllt sind: „Bye, bye FRS – Hello DFS-R“ 🙂

Stay tuned,
N.Own

Weiterführende Links:
[1] https://blogs.technet.microsoft.com/filecab/2014/06/25/the-end-is-nigh-for-frs/
[2] https://technet.microsoft.com/de-de/library/dn303411.aspx
[3] https://technet.microsoft.com/de-de/library/mt163897.aspx#BKMK_FRSDeprecation
[4] https://technet.microsoft.com/library/dd640019(v=ws.10).aspx

Windows Updates – GDR & LDR

Für Windows Updates gibt es eine Unterscheidung bei der sogenannten „Service Branch“ hinsichtlich der allgemeinen Verfügbarkeit (General Distribution Release – GDR) und einer eingeschränkten Verteilung (Limited Distribution Release – LDR).
GDR Updates sind in der Regel security updates sowie reguläre updates wie feature packs oder rollups. LDR updates finden Verbreitung unter den Hotfixes und Quick Fix Engineering (QFE) updates und sind zugeschnitten auf ein bestimmtes Kundenszenario, diese sind weniger ausgiebig getestet und sollten auch nur in bestimmten Fällen installiert werden.
Diese Art von Updates ist mit folgendem Passus in den jeweiligen KB Artikeln markiert:

„Dieser Hotfix soll nur der Behebung des Problems dienen, das in diesem Artikel beschrieben wird. Verwenden Sie diesen Hotfix nur auf Systemen, bei denen dieses spezielle Problem auftritt.“

„A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem.“

Dieser Hinweis sollte ernst genommen werden, der Hotfix sollte dann nicht auf bloßen Verdacht eingespielt werden – außer der Fehlerfall tritt in der Umgebung auf, man wurde vom Support darauf hingewiesen ihn einzuspielen oder der Hotfix ist gelistet in einem KB Artikel mit dem Titel „Empfohlene Updates für…“ (Recommended Hotfixes).
Service Pack Dateien gehören beispielsweise generell immer der General Distribution Release an.

Doch was bedeutet die Service Branch?
Typischerweise erhält man GDR Updates über den Windows Update Kanal, LDR Updates erhält man in der Regel vom Microsoft Support oder über den Download eines KB Artikels zu einem Fehlerfall.
Hinweis dazu: GDR Dateien können sich in einem LDR Hotfix befinden, aber nicht umgekehrt.

Siehe dazu:
http://blogs.msdn.com/(…)difference-between-general-distribution-and-limited-distribution-releases.aspx
http://blogs.technet.com/b/mrsnrub/archive/2009/05/14/gdr-qfe-ldr-wth.aspx

Wichtig ist, dass man sich der Service Branch eines Updates bewusst ist.
Wie erkennt man welcher Service Branch die Dateien meines Systems angehören?
https://blogs.technet.microsoft.com/(…)gdr-oder-ldr-hotfix-version-qfe/

Mit Windows 8.1 respektive Windows Server 2012 R2 hat sich das Blatt gewendet, es gibt nur noch eine einheitliche Branch für alle Updates.
Das ist eine positive Entwicklung, da man sich nun bei der Verwendung eines Hotfixes keine Gedanken mehr machen muss auf einer Installation mit GDR Service Branch Dateien über ein Update eine LDR Service Branch Hotfix einzuspielen.
Da mit dem Alter einer Windows Server Installation immer mehr Updates und ggf. auch Hotfixes auf einem System landen, sollte man darauf achten, was man auf einem Windows Server 2008 R2 oder älter einspielt – vor allem, wenn es sich um kritische Systeme wie Failover Cluster handelt.
Wie beschrieben durchlaufen GDR Updates einen wesentlich härteren Testparcours als LDR Updates.

Stay tuned,
N.Own

Isolated & Quarantined Nodes

Es gibt zwei neue Failover Cluster States mit der Einführung von Windows Server 2016: Isolated und Quarantined.
Was ist ein Knoten, der isoliert oder unter Quarantäne in einem Cluster steht?

Zuerst ist anzumerken, dass es sich um zwei unterschiedliche States handelt, die eine fehlerhafte Intra-cluster Kommunikation widerspiegeln.

Der Zustand eines Knotens im isolierten Status sagt aus, dass der Knoten nicht mehr aktiv am Cluster teilnimmt. Das kann auftreten, wenn ein Knoten die übrigen Clusterknoten nicht mehr erreicht und zuvor eine oder mehrere VMs gehostet hat. Der Zustand wird in der Failover Cluster Console angezeigt und ist nun keine unbehandelte Ausnahme mehr.
Der Clusterdienst reagiert entsprechend und nimmt einen Knoten gegebenenfalls selbstständig in den Status „isolated“.
Es werden keine Ressourcengruppen mehr auf diesen Knoten verschoben, so dass der Knoten nicht mehr aktiv an einem Cluster teilnimmt.

Ein Knoten, der unter Quarantäne steht, kommt in diesen Status, wenn er z.B. drei mal innerhalb einer Stunde den Cluster unsauber verlassen hat. Es wird davon ausgegangen, dass der Knoten ein Hardware- oder sonstiges Problem hat, das ihn zwar teilweise funktional lässt, aber dennoch persistente Fehler zeigt.
Ein sogenannter „dirty node“ wird dadurch für 2 Stunden aus der Mitgliedschaft zu einem Cluster ausgeschlossen („quarantined“); die gehosteten VMs werden im laufenden Betrieb auf einen aktiven Knoten verschoben.
Dieser Status wird ebenfalls in der Console angezeigt und von einem Clusterdienst selbstständig erkannt und ausgelöst. Er kann als Folge des Zustands der Isolation eines Knotens auftreten.

Weiterhin gibt es einen neuen State, der den Ressourcentyp einer virtuellen Maschine (VM) betrifft: Unmonitored.
Dabei kann eine VM in den Unmonitored Status übergehen, wenn der Cluster den Zustand der VM auf Grund von Fehlern auf einem Knoten nicht mehr überwacht. Auch diesem Zustand wird Rechnung getragen und zur Anzeige in der Failover Cluster Console gebracht.
Dieser Status kann als Folge eines isolierten Knotens auftreten, auf dem die VM dann als „unmonitored“ markiert wird.

Hier der Microsoft Blog Artikel, mit dem die neuen Funktionen angekündigt werden:
» https://blogs.msdn.microsoft.com/(…)virtual-machine-compute-resiliency(…)

Es sind dort auch Parameter beschrieben, mit denen die Funktionen im Detail auf die eigene Umgebung angepasst werden können. Die Konfiguration kann per PowerShell durchgeführt werden und betrifft vor allem Schwell- und Timeout-Werte.

Die neuen, erweiterten Failover Cluster States von Windows Server 2016 helfen letztendlich die Stabilität des Clusters einzuschätzen und zu erhöhen, vormals unbehandelte Fehler werden auf diese Weise automatisch erkannt und angezeigt. Ebenso werden unsaubere Knoten automatisch für einen gewissen Zeitraum ausgeschlossen.
Das erhöht die Belastbarkeit eines Clusters und vermeidet unschöne Folgefehler, Microsoft spricht hier von „Virtual Machine Compute Resiliency“ – also von einer höheren Elastizität für vorübergehende Fehler eines Knotens.

Stay tuned,
N.Own

Active Directory Abhängigkeiten

Windows Server Failover Cluster benötigen bisher ein Active Directory, da sie auf die Vorteile einer zentralen Benutzerverwaltung zurückgreifen – die Abhängigkeiten eines Clusters zu den Active Directory Domain Services (AD DS) haben sich allerdings über die letzten Versionen geändert.

Windows Server 2003 hat noch zwingend ein AD benötigt: Der Clusterdienst auf den jeweiligen Nodes wurden im Kontext eines Dienstekontos ausgeführt – dieses musste ein AD Konto sein.
Der sog. „Cluster Service Account“ (CSA) hat die Anlage der Netzwerknamen übernommen, die „Virtual Computer Objects“ (VCO, Computerkonten) hat der Dienst im Kontext des CSA angelegt und modifiziert. Über so ein Computerkonto wird eine durchgängige Kerberos Authentifizierung für virtuelle Netzwerknamen im einem Cluster z.B. für File Services erreicht. Dabei schreibt der Clusterdienst auch die passenden Attribute für das Computerkonto: ServicePrincipalName (SPN), DnsHostName und DisplayName.

Mit Windows Server 2008 wurde der CSA obsolet, damit vereinfachte sich das Setup und die Achillesferse eines Benutzerkontos mit zu wenig Rechten als potentieller Schwachpunkt für den Clusterbetrieb wurde abgeschafft. Der Clusterdienst läuft nun im Kontext von local system, das Cluster Name Object (CNO) legt fortan die Netzwerknamen an (VCO). Die VCOs bilden den „Client Access Point“ (CAP) für die Zugriffe der Benutzer auf den Cluster. Das CNO ist ebenfalls zuständig für die Kennwortänderungen der VCOs im Active Directory.

Mit Windows Server 2012 R2 ist wiederum ein Schritt in Richtung Unabhängigkeit von AD DS implementiert worden: Man kann nun einen Cluster weitgehend ohne AD betreiben (AD-detached cluster) und für den Bootvorgang eines Knoten (form/join Cluster) muss ein DC nicht mehr zwingend erreichbar sein (AD-less cluster bootstrapping). Für virtualisierte DCs auf einem Hyper-V Cluster ist das Zucker.

Active Directory-less Cluster Bootstrapping
» http://blogs.technet.com/(…)enhanced-integration-with-active-directory-ad.aspx
Ein wichtiges Feature, um Domain Controller weitestgehend virtualisieren zu können und dafür Hyper-V Failover Cluster zu nutzen. Das Henne-Ei-Problem, das ein Cluster nicht ohne AD starten kann und ein DC nicht ohne Cluster auf dem er virtualisiert wurde ist damit passé.

Active Directory-Detached Cluster (Active Directory-less Cluster)
» https://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_ADAg
Diese Option sollte auf Grund der Einschränkungen gut überlegt werden:
» https://technet.microsoft.com/en-us/library/dn265970.aspx
Auch ist diese Möglichkeit nicht für jede Anwendung geeignet, die auf einem Cluster laufen soll. Selbst wenn man eine weitgehende Loslösung von Abhängigkeiten zu einem Active Directory erreichen kann, sollte man sich immer überlegen zu welchem Zweck und für welche Anwendungsfälle.
Hier ist noch einiges im Fluß für vNext und es gibt Kundenwünsche und Bestrebungen z.B. SQL Server Cluster gänzlich ohne ein Active Directory zu betreiben.
Wie ist Eure Meinung dazu? Hinterlasst mir einen Kommentar… 😉

Stay tuned,
N.Own