„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
Vor wenigen Tagen ist der Message Analyzer 1.1, der Nachfolger des Microsoft Network Monitors (Netmon), erschienen. Die neue Version bringt –obwohl es nur ein kleines Update ist– eine Fülle an neuen Funktionen: Improved performance, More Built-in Assets, Multiple Remote Capture, New Session Workflow, MOF/WPP ETL, TLS/SSL Decryption, Aliases, Time Improvement, Sequence Expression Updates, Updated Parsers, Updated Call Stack, ResponseTime etc.
Bei Windows Server 2008 wurde eine Funktion namens File Share Scoping implementiert, die es verhindert, dass Dateifreigaben über unterschiedliche Zugriffspunkte (Client Access Point – CAP) erreichbar ist. So war es in der Vergangenheit möglich über den Namen des lokalen Knotens, die IP Adresse des Knotens auf eine Freigabe zuzugreifen, allerdings immer nur auf dem aktiven Knoten. Waren die Ressourcen auf Grund eines Failovers auf den anderen Knoten geschwenkt, dann lief der Zugriff über den UNC Pfad oder die IP in’s Leere. Dieses Verhalten wurde eben ab Windows Server 2008 entfernt, um den unerwünschten Effekt zu verhindern.
Folgende KB Artikel sollte man regelmäßig überprüfen nach aktuellen, empfohlenen Hotfixes für Windows Server Failover Cluster: