Schlagwort-Archive: Migrate

Rolling Upgrade is back

★ von

Ein Rolling Upgrade unter Nutzung gemischter Betriebssystemversionen im gleichen Cluster ist für Migrationszwecke sehr praktisch. So erlaubte Windows Server 2003 eine gemischte OS-Version unter den Knoten eines Clusters, was es einem ermöglichte Knoten mit Windows 2000 Server und Windows Server 2003 im gleichen Cluster zu betreiben.
Das Vorgehen war denkbar einfach: Failover aller Ressourcen auf einen Clusterknoten, pausieren des nun passiven Knoten und anschließende Aktualisierung der Windowsversion. Danach das Pausieren des passiven Knotens aufheben und Failover der Ressourcengruppen auf den vormals passiven Knoten, nun kann der vormals aktive Knoten pausiert und aktualisiert werden. Nach einer anschließenden Entfernung der Pausierung hat man das Upgrade seiner Clusterknoten erledigt.
Das Szenario ergibt natürlich nur Sinn, um den Cluster auf einfache Weise auf 2003 zu aktualisieren: Ein Betriebsszenario mit gemischten Knoten wird niemand ernsthaft für längere Zeit betreiben wollen.

Was ist der Vorteil des Ganzen? Nun, man vermeidet eine längere Downtime und spart sich Hardware und das ist bei einem Cluster meistens eine teure Angelegenheit, wenn man die LUNs auf der Shared Storage berücksichtigt.
Leider gab es die Möglichkeit ein „Cluster Operating System Rolling Upgrade“ zu nutzen bei Windows Server 2008 (R2) und Windows Server 2012 (R2) nicht mehr – die Komponenten erlagen einem starken Wandel bei der Architektur und haben das Szenario schlichtweg nicht mehr unterstützt.

Welche Versionen unterstützen ein Cluster OS Mixed Mode, um ein Rolling Upgrade zu realisieren?
Rolling Upgrade Matrix - © 2016 N.Own
Microsoft hat erkannt, dass das Feature für Kunden und IT-Dienstleister eine enorme Erleichterung bei einem Upgrade darstellt und wird das Feature mit Windows Server 2016 wieder einführen. Eine Migration von Windows Server 2012 R2 zu Windows Server 2016 wird also wieder weitestgehend unterbrechungsfrei möglich sein:

» https://technet.microsoft.com/en-us/library/dn850430.aspx

Mit der Wiedereinführung dieses Features wird eine Planung und Durchführung eines OS-Upgrade der an einem Cluster beteiligten Serverknoten wesentlich vereinfacht. Eine Migration von Windows Server 2012 R2 zu Windows Server 2016 erlaubt damit die Nutzung derselben Hardware.

Stay tuned,
N.Own

Wechseln der Cluster IPs

★ von

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

Migrationspfade zu Windows Server 2008 R2

★ von

Windows Server 2008 R2 ist nun RTM. Die ersten Upgradeprojekte werden lanciert und nun stellt sich die Frage: Welche Möglichkeiten stehen einem zur Verfügung, um bestimmte Anwendungen, Dienste und Rollen auf einen R2 Cluster zu migrieren?

In den meisten Fällen hilft einem der Cluster Migration Wizard.
Folgender aktuelle TechNet Artikel zeigt die Möglichkeiten aufgeschlüsselt nach Diensten und Applikationen im Detail:
» http://technet.microsoft.com/(…)ee791924.aspx

Es werden neben den gängigen Diensten wie File, Print, DHCP etc. auch Applikationen wie SQL & Exchange betrachtet.

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/