Exchange 2007 CCR und SCR

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:

Eine Cluster Continuous Replication Architektur (C) microsoft.com

© 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

Longhorn Beta – Focus on Clustering

Das Longhorn Server Beta Programm der Februar CTP ist angelaufen – aus CluAdmin.exe wird CluAdmin.msc.

Zum Vergrößern anklicken...     Zum Vergrößern anklicken...

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

Update / Featureupgrade – QFE KB921181

Ende Dezember hat MS einen sehr interessanten Hotfix für W2K3 SP1 Cluster veröffentlicht, der mehr ist als ein bloßer Hotfix:

» KB 921181: „An update is available that adds a file share witness feature and a configurable cluster heartbeats feature to Windows Server 2003 Service Pack 1-based server clusters“

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

NASDAQ setzt auf Windows Cluster & SQL Server 2005

Eine recht interessante Fallstudie ist zur Zeit auf microsoft.com online: An der größten elektronischen Börse NASDAQ werden >64 000 Transaktionen pro Sekunde ausgeführt.
Dazu kommen 2 Windows Cluster a 4 Nodes zum Einsatz, um five nines zu realisieren – also eine Uptime von 99,999%.

Auch wenn die Zahl beeindruckend erscheint – in einem realen IT Umfeld mit Endanwendern ist sie eher akademischer Natur, siehe u.a.: Myth of the nines. Trotzdem beeindruckende Werte, keine Frage.

Die NASDAQ Cluster setzen MS SQL Server 2005 ein und basieren auf DELL PowerEdge 6850 Nodes.

MS Kundenreferenzblatt:
» http://download.microsoft.com/…Nasdaq_D_Final_02086.pdf

Nettes Setup 😉

Stay tuned,
N.Own

Windows Server Catalog – Cluster Solutions

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.

Windows Server Catalog - Cluster Solutions

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.

» Aktueller KB Artikel 309395

Also: Am besten zu zertifizierter Hardware greifen und man fängt Ärger und Downtimes bereits im Vorfeld ab.

Stay tuned, 😉
N.Own