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

Wechseln der Cluster IPs

In der letzten Zeit wurde ich desöfteren gefragt: Wie aufwändig ist es eigentlich IP Adressen im Cluster zu wechseln?
Das kommt auf die Applikation an, die der Cluster hostet 😉

Bei einem reinen File & Printcluster ist das Vorgehen an sich trivial:
1. Verbinden der Clusterverwaltung mit LPC
2. Wechseln der IPs nach KB Artikel 230356:
» http://support.microsoft.com/kb/230356/en-us
3. Nachdem Ändern der IPs ist je Node ein Reboot nötig

Für einen SQL Server 7.0/2000/2005 gelten folgende Besonderheiten:
» http://support.microsoft.com/kb/241828/en-us

Für Exchange Server gilt folgender TechNet Artikel:
» http://technet.microsoft.com/(…)EXCHG.65%29.aspx

Um einen Cluster nicht nur in einen anderen IP Bereich zu verschieben, sondern in eine andere Domäne umzuziehen, ist dieses Vorgehen anzuraten:
» http://support.microsoft.com/kb/269196/en-us

MS selbst empfiehlt die beschrieben Schritte nicht für eine Produktivumgebung.
Meiner Erfahrung nach klappt das bei einem reinen File & Print-Cluster problemlos. Bei einem Applikations-Cluster mit geclusterteten Anwendungen, die auf eine Domäne angewiesen sind, ist ein Neu-Aufsetzen des Clusters eher ratsam und meistens auch schneller erledigt…

Hinweis: Wichtig ist bei Änderungen an Netzwerkverbindungseinstellungen ein Ansprechen des Clusters mit Hilfe der Clusterverwaltung ohne RPC (Remote Procedure Call), sondern via LPC (Local Procedure Call), also dem schlichten Punkt: „.“ im Verbindungsdialog:
» https://www.cluadmin.de/index.php?p=375

Folgende KB Artikel helfen bei spezifischen Fehlern, die auftreten können beim Wechseln der IP oder des Subnets:
» Changing the IP Address May Result in Failover
» Cluster Does Not Start After You Change the Subnet Mask

Stay tuned,
N.Own

Adminrechte für die Clusterverwaltung

Für den Zugriff auf die Clusterverwaltung eines Windows Server 2003 Failover Clusters benötigt man administrative Rechte.

Standardmäßig ist in der Clusterverwaltung die lokale Gruppe der Administratoren auf dem Cluster mit Vollzugriff eingerichtet (Reiter – Sicherheit/Security).

Hier kann einem Benutzer oder einer Benutzergruppe das administrative Recht ‚Vollzugriff‘ vergeben werden:

Clusterverwaltung Sicherheitseinstellungen

Clusterverwaltung Sicherheitseinstellungen

Clusterverwaltung Sicherheitseinstellungen

Siehe: » http://technet.microsoft.com/en-us/library/(…).aspx

Eine Einschränkung auf Bereiche innerhalb der Clusterverwaltung oder Rechte für einzelne Aktionen ist nicht möglich – ein Admin ist ein Admin.

Ab Windows Server 2008 R2 wird es eine » Read-Only API geben, um einen rein lesenden Zugriff auf die Clusterverwaltung zu implementieren.

Stay tuned,
N.Own

Single Instance Store im Cluster – Teil 2

Es gibt inzwischen einen KB Artikel zum Thema Single Instance Store auf einem Cluster – danke an H.V. für den Hinweis. In einem früheren Artikel habe ich bereits die Besonderheiten beim Einsatz von SIS auf einem Cluster Volume angesprochen, nun gibt es in einem aktuellen KB Artikel die Empfehlung den Groveler über ein VBS Skript (Sisclusr.vbs) einzubinden:

» KB 947266: Single Instance Store on a Cluster (sisclusr.vbs)

Das Skript wird über den Ressourcentyp ‚Generic Script‘ in der Cluster Verwaltung angelegt, ähnlich wie das bei dem Skript clusweb.vbs zum Clustern eines IIS der Fall ist.

Single Instance Store ist ein feature, daß ursprünglich aus dem Exchange Umfeld kommt und zur Datendeduplizierung verwendet wird. Es bietet einem echte Deduplizierung von File System Daten über Pointer, den sog. SIS Links: So wird eine Datei immer nur einmal auf einem Volume abgelegt, die Kopien zeigen via SIS Links auf diese originäre Datei.

Für den Einsatz von Single Instance Store benötigt man einen Windows Storage Server oder Windows Unified Data Storage Server.

Weiterführende Informationen zu dem Thema Single Instance Store bietet das SIS Technical White Paper (Word DOC).

Stay tuned,
N.Own

Welches Quorum Model ist das passende?

Es gibt auf » MCSEboard.de immer wieder Fragen zu den Quorum Typen, die mit einem Windows Server Failover Cluster realisierbar sind. Mit Windows Server 2003 wurde ein neues Quorum Model eingeführt: Majority Node Set (MNS) und auch für Windows Server 2003 SP1 zog mit » File Share Witness ein neues cluster feature ein.

Mit Einführung von Windows Server 2008 wurden wieder neue Quorum Typen eingeführt, so daß es mittlerweile vier Quorum Models zur Auswahl gibt:

» Node Majority
» Node and Disk Majority
» Node and File Share Majority
» No Majority: Disk Only

Die neuen Typen verfolgen einen Vote-basierten Ansatz, bei dem eine Mehrheit an Stimmen den Ausschlag geben. Einige Quorum Typen sind für den Einsatz von Clustern mit gerader Anzahl an Nodes geeignet, andere zur Verwendung bei einer ungeraden Anzahl an Nodes. Auch die Storage spielt eine Rolle: Falls keine Shared Storage eingesetzt wird, sind nur zwei der Quorum Models sinnvoll. Als drittes Kriterium nennt Microsoft Multi-Site Cluster, ehemals Geo-Cluster.

Node Majority
Dieses Quorum Model bietet sich an für den Einsatz einer ungerade Anzahl an Nodes. Die Cluster- und Quorumdaten werden auf den lokalen Disks der einzelnen Nodes vorgehalten. Da die Daten auf den jeweiligen Nodes direkt abgelegt werden, hat jeder Node eine Voting Stimme – damit muss eine Mehrheit der Nodes online sein (N/2 + 1).
Daher ist es nicht sinnvoll diesen Quorum Typ bei gerader Anzahl an Nodes auszuwählen. Es wird keine Shared Storage vorausgesetzt.

Node and Disk Majority
Der Quorum Typ Node and Disk Majority wird für eine gerade Anzahl an Nodes empfohlen, da die Cluster Konfiguration zusätzlich noch auf einer Witness Disk abgelegt wird – im Gegensatz zu einer reinen File Share Witness. Damit erhält man für die Witness Disk eine weitere Voting Stimme.
Solange die Witness Disk online bleibt, kann die Hälfte der Nodes ausfallen (N/2). Dieses Quorum Model wird bei einer gerade Anzahl an Nodes standardmäßig ausgewählt, eine Shared Storage ist Voraussetzung.

Node and File Share Majority
Dieser Quorum Typ ist sehr ähnlich zu „Node and Disk Majority“, mit dem Unterschied, daß keine Disk als Voting Stimme zum Einsatz kommt, sondern eine beliebige Freigabe auf einem Server. Die Cluster Konfiguration wird dabei nicht auf dem File Share abgelegt – nur die Information darüber, welcher Node eine aktuelle Version bereithält. Falls ein Node bei einem Two Node Cluster ausfällt und der aktive keine aktuelle Daten bereithält, bleibt der Cluster offline.
Da die beiden Knoten einen identische Datenbestand aufweisen müssen für einen fehlerfreien Betrieb des Clusters, kann es bei diesem Typ zu einer „Partition in Time“, sprich: Inkonsistenzen, kommen.
Daher ist dieses Quorum Model nur in Einzelfällen einzusetzen.

No Majority: Disk Only
Der vierte Quorum Typ ist der bei Windows 2000 Server und Windows Server 2003 favorisierte und erfordert eine Shared Storage. Es können N-1 Nodes ausfallen.
Da die Storage ein SPoF darstellt, ist dieses Quorum Model inzwischen überholt: Mit Windows Server 2008 wird beim Einsatz einer Shared Storage ein Quorum vom Typ „Node and Disk Majority“ empfohlen.

Folgende TechNet Artikel bieten weiterführende Informationen:
» Understanding Quorum Configurations in a Failover Cluster
» Additional Information About Quorum Modes
» Guide: Configuring the Quorum in a Failover Cluster
» Details of How Quorum Works in a Failover Cluster

Die Wahl des Quorums will wohl überlegt sein, dabei sind die Artikel sehr hilfreich.

Stay tuned,
N.Own

Hotfix und Service Pack Installation

Wie patcht man einen Cluster oder wie installiert man ein Service Pack auf einem Cluster? In der Regel geht man genauso vor, wie auf einem Single Server. Man sollte allerdings darauf achten, zuerst den passiven Node zu patchen und ggf. zu booten. Vor der Installation eines Hotfix oder eines Service Packs auf dem aktiven Node sind die Ressourcen auf den passiven, bereits aktualisierten, Node zu verschieben.

Generell sollte man folgende Hotfixe unterscheiden:
» Security Patche (mit und ohne Reboot)
» Service Packs
» Exchange Hotfixe

Security Patche mit Reboot können wie bei einem alleinstehenden Server via WSUS verteilt werden, ein Reboot über die entsprechende GPO ist kein Problem, solange ein Zeitversatz für die Nodes eingerechnet wird. Idealerweise booten die DCs und die einzelnen Nodes zu unterschiedlichen Zeiten. Das betrifft auch Security Patche ohne Reboot.
Genauso wie bei Single Servern sollte man Patche immer in einer Testumgebung bzw. Testservern vorab installieren, um Imkompabilitäten und Probleme mit Treibern, Anti-Viren-Software oder weiterer Drittanbietersoftware auszuschließen.

Um ein Service Pack auf einem Cluster zu installieren, sollte man den Knoten anhalten, bevor man das Setup aufruft (Pause Node). Das Prozedere ist im folgenden KB Artikel detailliert beschrieben:

» http://support.microsoft.com/kb/174799/en-us

Die Service Pack Installation ist wie bei einem Patch abwechselnd möglich, man verfährt hier wie bei einem Rolling Upgrade. Sollte eine Installation tatsächlich nicht klappen, hat man bei einem Cluster noch den aktiven Node und kann ohne Downtime mittels eines Restores des passiven, defekten Nodes wieder zum ursprünglichen Stand zurückkehren.

Eine Besonderheit stellen Exchange 2003 Hotfixe und Service Packs dar, diese können i.d.R. nicht installiert werden, solange der Cluster Service noch läuft.
Man geht zur Installation ähnlich vor wie bei einem regulären Cluster, abgesehen davon, daß vor einem Aufruf des Setups der Cluster Dienst auf dem passiven Node gestoppt wird. Eine Downtime ist dafür ebenso nicht nötig. Im folgenden KB Artikel sind die einzelnen Schritte ausführlich beschrieben (Sektion ‚Clustered server‘):

» http://support.microsoft.com/kb/328839/en-us

Solange man die KB Artikel beherzigt und die Punkte Schritt für Schritt abarbeitet, geht einem die Installation von Service Packs oder Exchange Hotfixes auf einem Cluster recht einfach von der Hand.

Der Vorteil eines Clustersystems ist die Gewissheit zu jedem Zeitpunkt noch einen aktiven, funktionierenden Node online zu haben und der Wegfall des Zeitdrucks, den eine Downtime auf einem Single Server mit sich bringt.

Stay tuned,
N.Own

Move/Migration einer DHCP Datenbank

Um eine DHCP Server Datenbank von einem Cluster zu einem anderen Cluster zu migrieren, ist der Kommandozeilenbefehl netsh sehr hilfreich:

» http://support.microsoft.com/kb/325473/en-us

Bei einer Migration von W2K auf W2K3 ist eine andere Syntax notwendig als von W2K3 auf W2K3.

So stößt man einen Export unter Windows 2000 Server an:

C:>netsh dhcp dump >dhcptext_bak.txt

Dieser Befehl erzeugt eine lesbare Textdatei, die mittels folgendem Befehl wieder einlesbar ist:

C:>netsh exec dhcptext_bak.txt

Zu Beachten ist bei einem Dump, daß die Textdatei die IP Adresse des Servers mehrfach enthält. Dazu muss ggf. die Textdatei geändert werden, um die korrekte IP des neuen Servers wiederzuspiegeln.
Dies ist unter Windows Server 2003 nicht mehr nötig, da hier kein dump erfolgen sollte, sondern ein export.

So führt man ein Export unter Windows Server 2003 aus:

C:>netsh dhcp server export dhcp_bak.txt all

Der Import wird mit folgendem Kommando auf dem Zielserver ausgelöst:

C:>netsh dhcp server import dhcp_bak.txt all

Im Gegensatz zu netsh dhcp dump enthält ein netsh dhcp export nicht die fixe IP des DHCP Servers. Es sind also keine manuellen Eingriffe in die erzeugte Backupdatei nötig, daher ist ein export immer einem dump vorzuziehen.

Um sich alle authorisierten DHCP Server einer Domäne anzeigen zu lassen kann ebenfalls netsh genutzt werden:

C:>netsh dhcp show server

Siehe dazu KB303351:
» http://support.microsoft.com/kb/303351/en-us

Update: Folgender Artikel von Ralf Schnell kann ich empfehlen, um die Verfügbarkeit eines DHCP-Servers zu planen:
» https://blogs.technet.microsoft.com/(…)hochverfgbarkeit-fr-dhcp-optionen-fr-windows-server/