Archiv des Autors: 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

Scripten mit cluster.exe

★ von

Cluster.exe erlaubt es einem Cluster per Batch zu scripten. Folgender Befehl liest zB. den Status einer Clustergruppe aus und zeigt an, auf welchem Node diese aktiv ist:

cluster CLUSTER01 group CLUSTERGRUPPE01 /status

Folgender Befehl listet alle verfügbaren Nodes eines Clusters und zeigt an, in welchen Status sich die Nodes befinden:

cluster CLUSTER01 node /status

Aber auch Node-spezifische Informationen kann man auslesen, zB. den Service Pack Level der Nodes:

cluster CLUSTER01 node /prop|find /i "CSDVersion"

Der Befehl cluster.exe arbeitet sehr schnell, dies kommt einem beim Administrieren einer großen Anzahl an Clustern zugute. In meinen Tests dauert ein Auslesen solcher Informationen auf über 80 Two-Node Clustern unter einer Minute bis maximal 2 Minuten – je nach Netz: Ideal zum schnellen Auslesen des aktuellen Status von mehreren Clustern.

Das Ändern einer Cluster Konfiguration ist ebenso möglich. Folgender Befehl ändert den ‚Bevorzugten Besitzer’/’Preferred Owner‘ einer Cluster-Gruppe:

cluster CLUSTER01 group CLUSTERGROUP01 /SetOwners:CLUSTERNODE02

Grundsätzlich ist jede Aktion, die über die GUI konfigurierbar ist, auch über die Kommandozeile mittels cluster.exe durchführbar.

Diese Befehle können natürlich auch in einer Schleife genutzt werden:
@echo %date% %time%: Starting
for /f %%i in (clusserver.txt) do cluster %%i group %%i /stat >> groupstat.txt 2>&1
@echo %date% %time%: Finished

Das Code-beispiel sollte in einer .BAT oder .CMD Datei separat abgespeichert werden. Die Datei clusserver.txt listet die Clusternamen untereinander, die FOR Schleife arbeitet einen Namen nach dem anderen ab und speichert die Ausgabe (STDOUT und STDERR) in die Datei groupstat.txt.

Referenz:
http://technet.microsoft.com/en-us/library/cc779044.aspx

Stay tuned,
N.Own