Tag / Kategorie: 'Failover Cluster'
Gute Nachrichten: RocketDivision hat den Termin für die Longhorn Kompabilität ihres iSCSI Software Target “StarWind” pünktlichst eingehalten und vor einigen Tagen eine neue Version released:
» http://www.rocketdivision.com/wind.html
Der kostenlose Download einer Testversion ist möglich.
StarWind’s iSCSI Target ist nun für Longhorn Server verfügbar, leider ist damit noch kein Clustering möglich. Das soll mit einer weiteren Version kommen, die für Mai/Juni geplant ist.
Mit dem » Wegfall von Shared SCSI in LHS ist die Nutzung eines iSCSI Targets die attraktivste Möglichkeit Clustering in VMs zu testen.
Stay tuned,
N.Own
Typische third party File System Filtertreiber sind AntiVirus Treiber, Disk Quota Treiber oder Open File Agents. Jegliche Software, die einen Filtertreiber auf einem Cluster Node installiert, sollte für den Einsatz in einem Cluster vorgesehen sein (» KB250355). Ansonsten kann ein Filtertreiber, der zB. sein Handle auf ein Volume gar nicht oder nicht rechtzeitig freigibt, dazu führen, daß kein geordneter Failover mehr möglich ist.
Zu Troubleshootingzwecken ist es daher fallweise sinnvoll bestimmte Filtertreiber vorübergehend zu deaktivieren, um diese als Fehlerquelle auszuschließen und das Fehlerbild weiter einzugrenzen.
Welche Filtertreiber sind auf meinem Cluster installiert?
Viele Filtertreiber sind leicht über den Gerätemanager zu lokalisieren. Über “Ausgeblendete Geräte anzeigen” bzw. “Show hidden devices” sind die Treiber in der Sektion “Nicht-PNP-Treiber” bzw. “Non-Plug and Play Drivers” zu finden.
Der McAfee Filtertreiber trägt beispielsweise die Bezeichnung “NaiAv…”.
Über den Kommandozeilenbefehl devcon.exe erhält man diese Legacy Treiber auch angezeigt:
C:\>devcon listclass LegacyDriver
Ein Beispiel der Ausgabe: devcon_sample.txt
Devcon.exe ist in den Support Tools zu finden oder über einen Download bei Microsoft:
» http://support.microsoft.com/kb/311272/en-us
Der Clusterdienst benötigt für den Betrieb selbst zwei Kernel Filtertreiber: Den ClusDisk Treiber für den Storage Stack und ClusNet für den Network Stack.
Im Cluster » MPS Reporting Tool ist ein Kommandozeilenprogramm namens fltrfind.exe zu finden, daß einem alle Filtertreiber ausgeben soll. Leider liefert einem das Tool keine Infos zu File System Filtertreibern.
Um einen Filtertreiber zu deaktivieren, kann man den Gerätemanager verwenden oder über die Registry gehen. Die Treiber sind im Services Zweig zu finden:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Dort den betreffenden Treiber suchen und den Wert unter “Start” auf 0×4 setzen, welches ein SERVICE_DISABLED bedeutet.
Siehe auch » KB816071 dazu.
Stay tuned,
N.Own
Dr. Tom Moreau, MVP für SQL Server, hat in einem aktuellen TechNet Magazine Artikel vom März diesen Jahres seine Top Tips für SQL Server Clustering zusammengestellt.
Er gibt eine Übersicht der Möglichkeiten MS SQL Server 2005 zu clustern und zu spiegeln:
» Dr. Tom Moreau’s Top Tips for SQL Server Clustering
Dr. Tom Moreau ist seit 2001 MVP für Windows Server System – SQL Server.
Stay tuned,
N.Own
Es gibt zur Zeit einige Newsgroup Einträge zu dieser Fehlermeldung unter Longhorn Server: “Disk bus type does not support clustering“. Wieso kommt diese Meldung beim Aufsetzen eins Longhorn Failover Clusters?
Longhorn bietet keine Unterstützung mehr für Shared (Parallel) SCSI Device als Storage.
Lediglich Fibre Channel (FC), iSCSI und Serial Attached SCSI (SAS) Storage Devices werden unterstützt
Dies hat Elden Christensen, Program Manager bei Microsoft für Windows Failover Clustering, bereits auf der WinHEC 2006 in einer Powerpoint Präsentation verkündet:
PPT: » WinHEC 2006: Windows Server High Availability With Windows Server Longhorn Failover Clustering
(Dateiformat: Microsoft Powerpoint)
Momentan unterstützt aber zB. StarWind‘s iSCSI Target noch nicht Longhorn Server, dies wird für Anfang Q2 anvisiert.
Stay tuned,
N.Own
Kann man Cluster auch scripten? Aber klar – Neben der Möglichkeit den Cluster über die Kommandozeile via cluster.exe zu scripten gibt es die Möglichkeit per WMI auf den Cluster zuzugreifen.
Beim MS TechNet Script Center gibt es zwei Rubriken für Failover Cluster und Compute Cluster mit Beispielen:
» Sample scripts for managing Windows Cluster Server
» Sample scripts for managing and monitoring Windows Compute Cluster Server
Hier eine Übersicht der Cluster WMI Provider:
» The WMI provider for server clusters
Wer tiefer in die Cluster Programmierung einsteigen will und zB. eigene Cluster Ressourcen programmieren will oder eine Cluster-Aware Applikation findet hier Infos zur Cluster Server API:
Der dort angesprochene Cluster Automation Server ist in Longhorn Server deprecated und wird nicht mehr unterstützt.
Stay tuned,
N.Own
Ein aktueller Blogeintrag von Arlindo Alves [MSFT] spricht einige Neuerungen von Longhorn Clustering an:
• Verbesserte Clustervalidierung (Preinstall)
• Vereinfachtes Setup, automatisierbar
• Nutzung von VSS zur Sicherung der Cluster Konfiguration
• Event tracing anstatt cluster.log zur Vereinfachung des Troubleshootings
Siehe: » 10 Reasons to look at Windows Longhorn Part 7: Failover Clustering
Einiges davon habe ich in diesem Beitrag bereits angesprochen:
» http://www.cluadmin.de/failover…longhorn-p23/
Stay tuned,
N.Own
Ein kürzlich veröffentlichter Hotfix ermöglicht nun den Einsatz von GPT Disks in einem Cluster. Volumes mit mehr als 2 Terabyte sind nun auch im Cluster möglich.
Siehe: » A hotfix is available that adds support for GPT volumes… (KB 919117)
Um ein Volume vom Typ MBR auf GPT umzustellen, kann man den diskpart Befehl convert gpt nutzen.
Mehr dazu: » Change a MBR disk into a GPT disk
Voraussetzungen:
x86: Windows Server 2003 SP1/SP2, 32 Bit
IA64: Windows Server 2003 SP1/SP2 für Intel Itanium
x64: Windows Server 2003, 64 Bit
Stay tuned,
N.Own
Jetzt, da die » Longhorn Beta Februar CTP von sich reden macht, gibt es die ersten Tester, die einen Cluster mit Longhorn Core aufsetzen.Das geht – und sogar gut. 
Windows Server Core ist eine Möglichkeit Longhorn Server ohne GUI aufzusetzen.
Folgender Befehl leitet die Installation ein:
start /w ocsetup FailoverCluster-Core
Failover Cluster ist keine Server Rolle, sondern ein optional feature.
Stay tuned,
N.Own
Gestern ist das Service Pack 2 für Windows Server 2003 offiziell erschienen.
Es enthält auch eine Neuerung, die den Clusterdienst betrifft:
Falls der Cluster Service Account (CSA) nicht alle erforderlichen Rechte erhalten hat, wird ein Event 1239 ausgelöst, der weitere Informationen über das fehlende Recht trägt.
Siehe: » What’s New in Windows Server 2003 Service Pack 2
» Microsoft TechNet – Windows Server 2003 Service Pack 2
Der CSA sollte die Rechte halten wie in » KB 269229 beschrieben.
Event 1239 war bisher als Exchange Event (Quelle: MSExchangeIS, MSExchangeDS) bekannt.
Stay tuned,
N.Own
Es gibt eine aktualisierte Version des KB Artikels der empfohlenen Hotfixe für Server Clusters:
» Recommended hotfixes for W2K3 SP1 – Server Clusters (Rev. 8.0, 27.02.07)
Microsoft empfiehlt die Installation der Hotfixe auf dieser Liste.
Für Windows Server 2003 Cluster, auf denen noch nicht SP1 installiert ist, gibt es auch eine Liste:
» Recommended hotfixes for W2K3 – Server Clusters
Stay tuned,
N.Own
ClusPrep (Microsoft Cluster Configuration Validation Wizard) ist vor kurzem in der Version 1.0 erschienen.
Mit ClusPrep kann man Nodes vor der Installation des Clusterdienstes auf etwaige Probleme prüfen. Man kann es auch gegen vorhandene Clusternodes laufen lassen für Inventoryzwecke.
ClusPrep 1.0 läuft derzeit nur auf 32-Bit Maschinen und auch nur auf englischen Windows Server 2003 und Windows XP SP2 Systemen. ClusPrep läuft nicht unter Windows Vista.
Das Tool an sich gab es schon länger, nun ist eine neue Version erschienen.
Download: » Microsoft Cluster Configuration Validation Wizard (ClusPrep)
KB 933462: » Frequently asked questions about ClusPrep 1.0
Stay tuned,
N.Own
Diesmal nichts wirklich neues, ich greife CCR auf wegen der Meldung, daß voraussichtlich ab Exchange 2007 SP1 Standby Continuous Replication (SCR) als neues Feature verfügbar sein wird.
Aber erst der Reihe nach: Cluster Continuous Replication kombiniert die Exchange 2007 features asynchronous log shipping and replay und die Failover features eines Windows Clusters.
Wie sieht sowas aus? Hier ein Beispiel einer Exchange CCR Architektur im Überblick:
© by Microsoft
Bei diesem Modell wird keine Shared Storage verwendet, die ansonsten typisch für einen Windows Cluster ist.
CCR bietet Hochverfügbarkeit für Exchange Mailbox Server. Es wird dazu auf einem zweiten, passiven Node eine Kopie der Datenbank vorgehalten. MS spricht von einem “Exchange Server 2007 Clustered Mailbox Server (CMS)”.
Gegensätzlich zu CCR ist ein Exchange SCC (Single Copy Cluster), der eben eine Shared Storage zur gemeinsamen Datenhaltung nutzt.
TechNet Artikel mit weiterführenden Infos:
» Technet: Cluster Continuous Replication
Für Exchange 2007 SP1 ist geplant eine Standby Continuous Replication (SCR) einzuführen, die Replikation findet dann auf ein ungeclusterten Server in einem anderen Rechenzentrum statt.
Mehr dazu: » Exchange Team Blog: Talking Exchange 2007 SP1
Stay tuned,
N.Own
Das Longhorn Server Beta Programm der Februar CTP ist angelaufen – aus CluAdmin.exe wird CluAdmin.msc.
Am 21.02. begann die “Focus on Clustering” Woche im Longhorn Server Beta Programm.
Besonderes Augenmerk wurde diese Tage auf die Cluster Validierung (pre-install) gelegt. Ebenfalls neu: Cluster Rollen, wie zB. die File Server Role; Dissimilar Subnets, also Clusternodes in unterschiedlichen Subnetzen etc.
Stay tuned,
N.Own
Ende Dezember hat MS einen sehr interessanten Hotfix für W2K3 SP1 Cluster veröffentlicht, der mehr ist als ein bloßer Hotfix:
Neu ist die erweiterte Funktionalität des Majority Node Sets (MNS): File Share Witness
Dies bietet einem eine echte Alternative, um Split Brain Szenarios (=Downtime) und Partition-in-Time Szenarios (=Dateninkonsistenz) zu umgehen – beides unschöne Effekte.
Ein echtes Highlight sind die neuen Parameter, um den Heartbeat zu konfigurieren:
cluster cluster_name /priv HeartBeatLostInterfaceTicks=5:DWORD
cluster cluster_name /priv HeartBeatLostNodeTicks=10:DWORD
Man kann damit die Latenzgrenzen für Multi-Site Cluster, ehemals GeoCluster/Stretched Cluster, etwas entschärfen und somit das Failoververhalten bei erhöhten Latenzzeiten der private NIC.
Scheint so, als ob ein paar Longhorn Cluster Features nun auch 2K3 Servern zu Gute kommen. 
Stay tuned,
N.Own
Aufgrund des Vista Launch diese Woche kommt man nicht mehr über den Windows Catalog auf die Auswahl für Cluster zertifizierter Hardware, diese ist nun hier zu finden:
» Windows Server Catalog of Tested Products – Cluster Solutions
Aus der Windows HCL (2K) wurde der Windows Catalog (2K3) und nun der Windows Server Catalog.
Warum ist der Einsatz zertifizierter Hardware besonders wichtig für den Einsatz in einem Cluster?
Diese Frage taucht immer wieder im » www.MCSEboard.de auf.
Wer ernsthaft Cluster betreiben will, sollte nur zertifizierte Hardware einsetzen. In einem Cluster laufen zeitkritische Aktionen im Millisekunden Bereich ab, dabei spielen Latenzzeiten besonders der HBAs und der NICs eine Rolle.
Das betrifft nicht nur die Hardware sondern auch die entsprechenden Treiber.
Bei GeoClustern (“stretched Cluster”) muss zB. sichergestellt sein, daß die Latenz der NICs <500ms bleibt [1][2] – das gilt natürlich auch für klassische Cluster.
Zudem supportet MS PSS/GTSC Cluster, die nicht im Windows Catalog gelistet sind, nur bedingt.
Unabhängig davon gibt einem ein zertifiziertes System die Sicherheit, daß der Betrieb eines MS Failovers Clusters in Verbindung mit dieser Hardware von Spezialisten auf Herz und Nieren geprüft und getestet wurde.
Also: Am besten zu zertifizierter Hardware greifen und man fängt Ärger und Downtimes bereits im Vorfeld ab.
Stay tuned,
N.Own
Es gibt Neuigkeiten auf der MS Website zum Thema Failover Clustering mit Longhorn Server:
» Failover Clustering with Windows Server “Longhorn” (17.01.07)
Die Neuerungen im Überblick:
· Neues Cluster Validierungs Tool
· Verbesserungen bei Setup und Migration
· Verbesserungen der Cluster Verwaltung und beim Betrieb
· Verbesserungen bei der Architektur
· Verbesserungen im Umgang mit der Storage
· Verbesserungen bei der Netzwerkunterstützung und der Sicherheit
Die Neuerungen wurden bereits Anfang September in einem Dokument veröffentlicht, das TechNet Abonennten zur Verfügung steht:
What’s New in Failover Clusters
Datei: en_Whats_New_in_Failover_Clusters.doc
Stand: 2006-09-07 16:35:50 (UTC)
Die aktuelle o.g. MS Website entspricht dem Inhalt des Dokuments.
Details zu den einzelnen Punkten sind auf der o.g. MS Website zu finden, diese werde ich in einem späteren Beitrag beleuchten.
Stay tuned,
N.Own
Alle Operationen des Clusterdienstes werden in das cluster.log geschrieben, das einem einen hervorragenden Ansatz zu Troubleshootingzwecken bietet. Speicherort des cluster.log ist standardmäßig:
%SystemRoot%\Cluster\cluster.log
Der Clusterdienst schreibt ein sehr ausführliches Log, alle Operationen werden hier im Millisekundenbereich aufgezeichnet.
Daher ist der Zeitraum, den das cluster.log abdeckt meist im Minutenbereich – je nach Auslastung des Clusters.
Die Größe des Cluster Logs -nicht zu verwechseln mit dem Quorum Log- kann über eine Umgebungsvariable einfach angepasst werden, siehe:
» Change the size of the cluster diagnostic log
» How to turn on cluster logging in Microsoft Cluster Server (KB168801)
Standardwert ist 8 MB, eine Größe um die 32 MB ist praktikabel und bietet einem ein größeres Zeitfenster.
In späteren Einträgen gehe ich näher auf die Spezifika des Logs ein.
Die Zeitangaben im cluster.log sind übrigens in GMT.
Stay tuned,
N.Own
