Archiv für den Monat: Oktober 2014

Shared RAID Controller

★ von

In Situationen, in denen man einen Failover Cluster unter Nutzung eines Shared RAID Controllers installieren möchte, wird es zu einer Fehlermeldung bei der Validierung kommen mit dem Hinweis:
„Disk bus type does not support clustering„.

Shared RAID Controller kommen vor allem bei Bladesystemen zum Einsatz, bei denen einzelne Knoten denselben Controller nutzen, um auf ein lokales Disksubsystem zuzugreifen. So kommt es zur oben genannten Fehlermeldung, obwohl oft eine Shared Storage im Chassis verbaut ist.
Dies kommt z.B. bei einer » Dell VRTX (Sprich: Vertex) vor, die dieses Jahr erschienen ist.

Eine Installation des Features Windows Server Failover Cluster ist dennoch möglich, dazu sollte vorher ein Registry-key namens AllowBusTypeRAID in den Parametern von ClusDisk gesetzt werden:

» http://support.microsoft.com/kb/2839292/en-us
» http://en.community.dell.com/techcenter/extras/w/wiki(…)

Stay tuned,
N.Own

vNext Windows Server Failover Clustering

★ von

Für die kürzlich erschienene Windows Server Technical Preview (Windows vNext) gibt es auch neue Features für das Clustering:

· Cluster Operating System Rolling Upgrade / Rolling Hyper-V Cluster Upgrade
· Storage Replica (SR)

Beide Features sind echte Perlen; Rolling Upgrades sind einigen von Windows Server 2003 bekannt und vereinfachen eine Cluster Migration immens, wenn die Hardware beibehalten werden soll.
So kann zum Beispiel ein 4-Knoten Cluster nach und nach auf die neue Betriebssystemversion gebracht werden indem ein Knoten freigeräumt, neu installiert und danach wieder dem Cluster hinzugefügt wird – alles ohne, dass man einen zweiten Cluster auf neuer Hardware vorhalten muss.
Nachdem alle Knoten eines Clusters auf der neuen Windows Server Version sind, gilt es noch den » ClusterFunctionalLevel mittels Update-ClusterFunctionalLevel anzuheben.

Mit Storage Replica unter Nutzung des Windows Features „Windows Volume Replication“ können Daten via SMB3 auf Blockebene (block-level) gespiegelt werden, entweder synchron oder asynchron und das unabhängig von der Storage-Hardware.
Diese Funktion vereinfacht den Aufbau von Geo-/Metro-Clustern (Stretch Clusters) immens, da man nun für viele Anwendungsfälle kein teures SAN-basiertes Mirroring benötigt.
Der verlinkte TechNet Artikel enthält einen Link zu einem » Storage Replica Guide (DOCX).

© Microsoft

SR benötigt jeweils ein Loglaufwerk je Datenlaufwerk, das repliziert werden soll. Ferner müssen die Datenlaufwerke GPT formatiert sein, beide Laufwerke (Quelle und Replikat) müssen eine identische Größe aufweisen, auf das Replikat kann nicht zugegriffen werden, zwischen Quelle und Replikat sollte eine Verbindung mit hoher Bandbreite (≥10GbE) und niedriger Latenz (≤5ms) bestehen. Siehe » Beitrag von Ned Pyle.
Man sollte dabei bedenken: SR ist kein Ersatz für DFSR.

Siehe: » http://technet.microsoft.com/en-us/library/dn765474.aspx

Was gibt es sonst neues in Windows Server vNext?
» http://technet.microsoft.com/en-us/library/dn765472.aspx

Windows Server 10 aka „vNext“ ist noch in einem sehr frühen Stadium, daher sind die Inhalte noch mit Vorsicht zu genießen und „subject to change“.
Beide Features sind sehr vielversprechend und liefern bereits jetzt gute Gründe sich mit der kommenden Version von Windows Server zu beschäftigen.

Stay tuned,
N.Own

Netzwerkeinstellungen auf einem Cluster

★ von

„Best Practice“ Empfehlungen sind nicht immer passend zu jeder Lösung, die man aufbauen kann. Im Falle von Hyper-V gibt es recht klare Richtlinien bzgl. der Netzwerkkonfiguration auf einem Cluster, die man berücksichtigen sollte:

  • Trennung und Isolation der Netzwerke nach Einsatzzweck: Management, Live Migrations, Storage, Client Access, Backup etc.
  • Anpassung der Adapter und Bindungen (Network Binding Order)
  • Anpassung der Quality of Service Policy hinsichtlich der Prioritäten ab W2K12

Siehe folgenden Artikel für Hyper-V Cluster:
» http://technet.microsoft.com/library/dn550728.aspx

Bei Nutzung von Cluster Shared Volumes (CSV) sollte man die Metric überprüfen, i.d.R. wählt der Cluster das passende CSV Netzwerk selbst aus – eine Kontrolle kann nicht schaden:
» http://technet.microsoft.com/en-us/library/ff182335%28WS.10%29.aspx

Für Exchange 2013 sowie 2010 Verfügbarkeitsgruppen (Database Availability Groups – DAG) gibt es jeweils einen Artikel:
Exchange 2013: » http://technet.microsoft.com/(…)exchg.150%29.aspx#Dat
Exchange 2010: » http://technet.microsoft.com/(…)exchg.141%29.aspx#Dat

Grundlegende Empfehlungen, die für jeden Cluster gelten, sind hier zu finden:
TechNet Blog: » http://blogs.technet.com/(…)configuring-windows-failover-cluster-networks.aspx
MSDN Channel 9: » http://channel9.msdn.com/Events/TechEd/(…)

Die Empfehlungen des Herstellers sollte man mindestens prüfen und idealerweise entsprechend umsetzen, außer es gibt triftige Gründe gewisse Einstellungen anders zu wählen für den eigenen Anwendungsfall.

Stay tuned,
N.Own