Archiv der Kategorie: Windows Server 2016

Cluster Fault Domains & Site Awareness

★ von

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

Microsoft Patchday 2016 – Revamped

★ von

Mit Launch von Windows Server 2016 Ende September wurde der Patchday wie angekündigt für die Windows Server Edition, Windows 10 als auch für Windows 7 und 8.1 umgestellt:

Zum einen wurde das Verfahren umgestellt, zum anderen auch das Intervall.
Beim Verfahren wurde von den bisherigen Einzel-Patches auf kumulative Updates umgestellt, daß heißt jedes monolithische Update enthält alle Korrekturen der letzten Monate.

Die Intervalle bieten wie bisher jeden zweiten Dienstag im Monat Security-Updates — jeden vierten Dienstag sollen davon unabhängig Quality-Updates erscheinen. Wie beschrieben enthalten alle Rollup-Pakete ebenfalls die bisherigen Updates unabhängig von der Patch-Klassifizierung.
Die erste und dritte Woche kann für out-of-band Updates genutzt werden, hier wird der jeweilige Dienstag als regulärer Slot eingeführt.

Das bedeutet, man benötigt auf einem frisch installiertem System lediglich ein aktuelles Rollup-Paket und ist damit auf dem neuesten Stand.

Folgende Tabelle zeigt den geänderten Rhythmus:
Patchday 2016 - © 2016 N.Own

Wenn zukünftig von Update „12B“ gesprochen wird, ist damit der bekannte Patchday am zweiten Dienstag eines Monats gemeint, die Zahl 12 verweist auf den Monat Dezember eines Jahres.
Das Update 12D wäre ein Quality-Patch in der vierten Woche im Monat Dezember.

Das bedeutet zusammengefasst:

  • Patchday Updates & Hotfixes sind zukünftig kumulativ
  • Trennung von Security- und Quality-Updates
  • Anpassung für Out-Of-Band-Updates (OOB)
  • Einführung von 4 Slots je Monat
  • Keine „private hotfixes“ mehr (Quick Fix Engineering – QFE)

Bleibt abzuwarten, ob sich das neue Verfahren mit den geänderten Modalitäten in der Praxis bewährt.

Stay tuned,
N.Own

Storage Performance Test

★ von

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

Node Fairness – Lastenausgleich

★ von

Seit geraumer Zeit gibt es verstärkt die Nachfrage nach einem Pendant für System Center Virtual Machine Manager (SCVMM) Dynamic Optimization in Umgebungen ohne VMM. Mit Windows Server 2016 wird es für die dynamische Verteilung von virtuellen Maschinen ein Boardmittel geben: Node Fairness bzw. Virtual Machine Load Balancing.

Failover Cluster Node Fairness soll den Effekt verhindern, dass nach einer Wartung oder einem Neustart eines Servers und damit einhergehender Live Migration die VMs nicht mehr paritätisch auf allen Knoten eines Clusters verteilt sind. Bei einem 4-Knoten Cluster kommt es zum Beispiel nach dem Reboot eines Knoten dazu, dass dieser keine Ressourcen mehr bereitstellt und nur noch passiv am Cluster teilnimmt – hier wäre eine gleichmäßige Verteilung der Ressourcen wünschenswert und genau darum kümmert sich Node Fairness.

Metrik
Dabei wird die RAM- und CPU-Auslastung eines Knoten berechnet. Die Parameter für ein Overcommitment fließen entsprechend in die Bewertung für den automatischen Lastenausgleich ein. Entsprechend einer Priorität des Knotens mit der höchsten Last werden die VMs auf die weiteren Knoten im Cluster verteilt, deren Auslastung geringer ist.
Auf den Mechanismus kann man über die PowerShell Einfluss nehmen: Mit „AutoBalancerMode“ bestimmt man, ob und wann das Feature zum Einsatz kommen soll und „AutoBalancerLevel“ regelt den Schwellwert in drei Stufen, ab wann ein Host anfängt VMs zu verschieben.
Den Modus kann man ebenfalls über einen GUI-Dialog namens „Balancer“ in den Eigenschaften eines Clusters konfigurieren.

Siehe: » https://blogs.msdn.microsoft.com/(…)node-fairness-in-windows-server-2016

Scale-Out
Bei dem Scale-Out eines Hyper-V Clusters können Knoten in den Verbund aufgenommen werden, die danach -automatisiert dank Node Fairness- über Live Migration ohne Downtime mit VMs betankt werden. Auch das stellt ein mögliches Szenario unter Nutzung dieses neuen Windows Server 2016 Features dar.

Eine automatische Verteilung von virtuellen Maschinen basierend auf der Auslastung der an einem Cluster teilnehmenden Hyper-V Hosts bietet im Windows Server Umfeld einen echten Mehrwert: Der Cluster wird insgesamt besser ausgelastet und die Mechanismen dazu greifen im Hintergrund ohne Benutzerinteraktion ein.

Siehe » https://blogs.technet.microsoft.com/(…)whats-new-in-failover-clustering

Credits gehen an MVP Aidan Finn, der das Feature auf Uservoice angeregt hat:
» https://windowsserver.uservoice.com/(…)vm-placement-without-system-center

Windows Server Failover Cluster Node Fairness kann ab Windows Server 2016 TP5 getestet werden.

Stay tuned,
N.Own

Heads-Up: Migration FRS zu DFS-R

★ von

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