Archiv der Kategorie: Failover Cluster

Cluster Validation mit 2008 R2

★ von

Cluster Validation wurde in der Version 2008 R2 weiter ausgebaut. Validation Tests sind eine gute Möglichkeit, um schnell und vor allem einfach herauszufinden, ob die Hardware- und Softwarekomponenten die Voraussetzungen für Failover Clustering erfüllen.

Windows Server 2008 R2 bietet nun durch die Validierung der Cluster Konfiguration zusätzlich die Möglichkeit einen laufenden Cluster hinsichtlich der getroffenen Einstellungen zu überprüfen.
Es können damit also nicht nur die Voraussetzungen vor einer Installation geprüft, sondern auch die aktuellen Settings der Ressourcen, Volumes, und des Quorums etc. – ideal zum Troubleshooting und für Dokumentationszwecke.

Validation Reports bestehen aus *.mht Dateien, die man mit einem Webbrowser öffnen kann.

Weiterführende Informationen zu den Validation Reports unter 2008 R2 im Detail:
http://technet.microsoft.com/en-us/library/cc726064.aspx

Aktuell umfasst die R2 Failover Cluster Validation die folgenden Punkte: Inventory tests, Storage tests, Network tests, System Configuration tests, Cluster Configuration tests

Stay tuned,
N.Own

Exchange 2010 DAG: Database Availability Groups

★ von

Mit dem Erscheinen von » Exchange 2010 Anfang des Monats häufen sich die Fragen ‚rund um das Exchange Clustering und den neuen Exchange DAG („Database Availability Groups“).

Mit den Database Availability Groups wurde die Exchange Architektur hinsichlich Clustering weiterhin verbessert, die Installation und Verwendung der Failover Cluster Komponenten geschieht nun weitestgehend im Hintergrund, ebenso die Konfiguration.

Wie steht es um die bisherigen und neuen Cluster Möglichkeiten?
Die schlechte Nachricht: LCR („Local Continuous Replication“) und SCR („Single Copy Cluster“) sind mit Exchange 2010 passé.

Die gute Nachricht: Exchange Hochverfügbarkeit wird einfacher, CCR („Cluster Continuous Replication“) und SCR („Standby Continuous Replication“) wurden konsequent fortgeführt und zu DAG zusammengefasst.

Das Limit für DAG liegt bei 16 Exchange Nodes, die über verschiedene Sites verteilt sein dürfen.

Welche Quorum Modelle werden verwendet?
Database Availability Groups verwendet nach wie vor ein Subset von Windows Server Failover Cluster Komponenten und bietet folgende Quorum Möglichkeiten:
Node Majority
Bei einer ungeraden Anzahl an Servern (Nodes) kommt dieses Model zur Verwendung. Eine Mehrheit an Votes ist über die Nodes gegeben.
Node & File Share Majority
Bei einer geraden Anzahl an Nodes wird ein File Share Witness eingerichtet, damit eine Mehrheit an Votes besteht.
Die Auswahl des passenden Quorum Models geschieht ebenfalls im Hintergrund.

Weitere Informationen zu den Failover Cluster Quorum Modellen:
» https://www.cluadmin.de/index.php?p=500

Weiterführende Informationen zu den Exchange 2010 Database Availability Groups:
» http://technet.microsoft.com/en-us/library/dd298065.aspx

Exchange 2010 bringt interessante Möglichkeiten zum Thema Hochverfügbarkeit mit und vereinfacht den Einsatz von Exchange Clustering immens.

Stay tuned,
N.Own

Adminrechte für die Clusterverwaltung

★ von

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

Printer Driver Isolation

★ von

Windows Server 2008 R2 bringt ein neues Feature mit, das Print Cluster Administratoren zu schätzen wissen werden: Printer Driver Isolation – Sandboxing für Druckertreiber.

Damit ist es möglich einzelne Druckertreiber in eigenen Prozessen laufen zu lassen, ohne das der Spooler bei Absturz dieser davon betroffen ist. Die Druckjobs sowie andere Druckprozesse bleiben davon ebenfalls unberührt.

Es gibt dazu drei Modi, die für einzelne Druckertreiber ausgewählt werden können:

  • None
  • Shared
  • Isolated

None entspricht der Einstellung unter Windows Server 2003: Der Druckertreiber läuft im Kontext des Spoolers. Im Shared Modus laufen die Druckertreiber unabhängig vom Spooler Prozess in einem eigenen Prozess (PrintIsolationHost.exe), die Treiber teilen sich einen Host Prozess.
Im Isolated Modus können einzelne Druckertreiber in eigenen Prozessen ausgeführt werden – sowohl unabhängig vom Spooler als auch von den Host Prozessen der anderen Druckertreiber. Letzteres bietet sich für vor allem für problembehaftete Druckertreiber mit bekannten Problemen an.

Printer Driver Isolation

Mittels Printer Driver Isolation unter R2 kann ein fehlerhafter Druckertreiber nicht mehr die Verfügbarkeit des Print Clusters an sich beeinträchtigen.

Siehe auch:
» http://msdn.microsoft.com/en-us/library/dd568151.aspx

Stay tuned,
N.Own

PRINTBRM löst PrintMig ab

★ von

align=Der Print Migrator war das Tool der Wahl zum Backup & Restore sowie zur Migration von Druckern auf Windows Servern und Windows Print Clustern.

Unter Windows Server 2008 / 2008 R2 gibt es ein neues Tool neben der PMC GUI, das sich für diese Zwecke anbietet: PrintBRM.exe (Print Backup Restore Manager).

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

Es wird im Gegensatz zum PrintMig unter x64 Systemen supported:

Weiterführende Informationen zu PrintBRM sind u.a. hier zu finden.

» AskPerf: Why PrintMig 3.1 is Retired

» AskPer: PRINTBRM and the Configuration File

Wie erwähnt kann auch der Printer Migration Wizard der Print Management Console (PMC) über die GUI genutzt werden. PrintBRM kann über den Switch -c parametrisiert und zB. für eine regelmäßige Sicherung mittels Script genutzt werden.

Stay tuned,
N.Own