Archiv der Kategorie: Failover Cluster

PowerShell löst cluster.exe ab

★ von

Windows Server 2008 R2, codename Windows 7 Server, wird das erste Windows Server Release sein, welches Failover Cluster PowerShell Commandlets bereitstellt.
Die PowerShell Befehle lösen cluster.exe als Scripting Schnittstelle ab. Cluster.exe wird zu Migrationszwecken noch in R2 enthalten sein, danach soll es entfernt werden.

Die PowerShell wird auch bei einem Server Core Cluster zur Verfügung stehen.
Auch NLB Cluster sind demnächst via PowerShell administrierbar.

Windows 7 ist momentan in der Betaphase, es wird bald eine Public Beta geben. PowerShell Scripting sowie Cluster Shared Volumes in Verbindung mit Hyper-V sind nur zwei der spannenden neuen Failover Cluster Features, für die sich der Umstieg auf Windows 7 Server sicherlich lohnt.

Quelle: http://blogs.msdn.com/clustering(…)9243367.aspx

Stay tuned,
N.Own

Move/Migration einer DHCP Datenbank

★ von

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/

Cluster Shared Volumes

★ von

Bis dato basierte Windows Server Failover Clustering (WSFC), ehemals MSCS, auf der Shared Nothing Architektur. Das bedeutet unter anderem, daß kein Volume gleichzeitig von zwei Nodes im Zugriff sein darf.

Das wird sich mit Windows Server 2008 R2, codename Windows 7 Server, ändern.
Das Feature dazu heißt:

Cluster Shared Volumes (CSV)

· Cluster Shared Volumes erlauben gleichzeitigen Zugriff auf CSV Disks von jedem Node aus

· Man spricht in dem Fall von „Distributed File Access for Hyper-V“

· Volumes werden nicht mehr dismounted und remounted

· VMs bleiben online während eines Failovers (!)

· Ein Coordinator Node hält die Disk Ressource und regelt den Zugriff auf die CSV Disk

· Single Name Space für den Zugriff auf die CSV Disk: %windir%\ClusterStorage\…

· Keine spezielle Storage, keine Agenteninstallation, kein neues Filesystem nötig

· Der File System mini-filter CSVFilter.sys ermöglicht die neue Funktionalität

· CSV in R2 wird nach derzeitigem Stand nur in Verbindung mit Hyper-V unterstützt

In Verbindung mit Hyper-V wird es dank CSV Disks sehr spannende Clustering-Möglichkeiten geben. So kann eine VM zwischen den Nodes in einem Windows Server 2008 R2 Cluster ohne Downtime verschoben werden. Der Failover geschieht ohne, daß der client dies bemerkt. Offene TCP Verbindungen werden dabei erhalten, es kommt zu keinem Abbruch der Verbindung oder einer Session.  Die ersten Demos sehen sehr vielversprechend aus.

Cluster Shared Volumes können über die GUI oder mit Hilfe der Powershell erstellt werden.

Stay tuned,
N.Own

Cluster Administrator ohne Verbindungsversuch starten

★ von

Standardmäßig verbindet sich die Clusterverwaltung auf einem Windows Server 2003 mit dem Cluster mit dem man sich zuletzt verbunden hat. Ist dieser nicht erreichbar oder nicht über RPC erreichbar, hat man noch die Möglichkeit sich über LPC zu verbinden – wenn man dazu die Chance hätte…

Folgenden „Ausweg“ gibt es dazu: Cluster Administrator mit dem Schalter -noreconnect aufrufen und dann über den Punkt: ‚.‘ direkt (LPC – Local Procedure Call) mit dem Node verbinden. Ist der lokale Knoten noch online bzw. verfügbar klappt das auch in den allermeisten Fällen:

cluadmin -noreconnect

Recht hilfreich, falls der RPC Dienst ein Problem hat oder der zuletzt verbundene Cluster nicht online ist und man trotzdem an die Clusterverwaltung gelangen will. Folgenden KB Artikel gibt es dazu von MS:

» Cluster Administrator Switches for Connecting to a Cluster

Stay tuned,
N.Own

IIS auf einem Windows Cluster?

★ von

Es gab unter Windows 2000 die Möglichkeit den Internet Information Service direkt zu clustern, diese Möglichkeit gibt es seit Windows Server 2003 nur noch über ein Generic Script. Die Cluster Ressource für den IIS wurde entfernt, da es generell geschickter ist eine Stateless Application über NLB redundant vorzuhalten:

» http://technet.microsoft.com/en-us/library/cc781308.aspx

Aus Kompatibilitätsgründen oder auch zu Migrationszwecken (Rolling Upgrade), besteht die Möglichkeit den IIS über die mitgelieferten Script clusweb.vbs (http, https) und clusftp.vbs (ftp) als ‚Generic Script’/’Allgemeines Script‘ Ressource einzurichten. Die IIS Einstellungen auf den Nodes müssen synchron gehalten werden, dazu gibt es das script iiscnfg.vbs[1][2]. Der Befehl IISSync steht mit Windows Server 2003 dazu nicht mehr zur Verfügung.
Das Vorgehen für Windows Server 2000 ist in KB Artikel 887417 beschrieben:

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

Dieses Vorgehen ist nur für Notlösungen, Migrationen oder Sonderfälle gedacht bei denen kurzfristig ein IIS zur Verfügung gestellt werden muss, produktiv sollte ein IIS wie gesagt auf einem NLB Cluster redundant gehalten werden.

Stay tuned,
N.Own