Storage Performance Test

Als Alternative zu IOmeter kann auch ein aktuelles Microsoft-Tool zum Einsatz kommen, das Performance-Tests von lokalen Festplatten und SSDs (DAS), LUNs einer SAN, Storage Spaces oder SMB Freigaben ermöglicht: » DiskSPD (https://aka.ms/DiskSpd)

Dabei läuft das Tool auf 32-Bit, 64-Bit und ARM Versionen von Windows sowohl auf physikalischen Servern als auch innerhalb einer VM. Das kommandozeilenbasierte DiskSPD („disk speed“) kann ähnlich wie IOmeter verteilte random I/Os erzeugen und messen, ebenso können eigene Workloads definiert werden.

DiskSpd ist open source (MIT License); das Projekt findet man auf GitHub:
» GitHub.com/Microsoft/Diskspd
Das Tool bietet eine Fülle von Möglichkeiten Parameter für einen Workload zu definieren. Weiterführende Informationen dazu findet man in der Dokumentation auf GitHub (» DOC und » PDF Format).

Im Gegensatz zu IOmeter, dessen Entwicklung seit 2006 weitgehend stagniert, und dem abgekündigten SQLIO wird DiskSPD derzeit aktiv weiterentwickelt und zeigt mit VMfleet auch Workloads für den kommenden Windows Server 2016. Diskspd läuft auch unter der Windows Server 2016 deployment option Nano Server.

Wer ein neues Storage-System in der eigenen Umgebung auf Herz und Nieren hinsichtlich Bandbreite, Durchsatz und IOPS mit verschiedenen Lastprofilen testen möchte, für den stellt DiskSPD eine gute Alternative zu IOmeter, IOzone oder Vdbench dar.

Stay tuned,
N.Own

Active Directory Abhängigkeiten

Windows Server Failover Cluster benötigen bisher ein Active Directory, da sie auf die Vorteile einer zentralen Benutzerverwaltung zurückgreifen – die Abhängigkeiten eines Clusters zu den Active Directory Domain Services (AD DS) haben sich allerdings über die letzten Versionen geändert.

Windows Server 2003 hat noch zwingend ein AD benötigt: Der Clusterdienst auf den jeweiligen Nodes wurden im Kontext eines Dienstekontos ausgeführt – dieses musste ein AD Konto sein.
Der sog. „Cluster Service Account“ (CSA) hat die Anlage der Netzwerknamen übernommen, die „Virtual Computer Objects“ (VCO, Computerkonten) hat der Dienst im Kontext des CSA angelegt und modifiziert. Über so ein Computerkonto wird eine durchgängige Kerberos Authentifizierung für virtuelle Netzwerknamen im einem Cluster z.B. für File Services erreicht. Dabei schreibt der Clusterdienst auch die passenden Attribute für das Computerkonto: ServicePrincipalName (SPN), DnsHostName und DisplayName.

Mit Windows Server 2008 wurde der CSA obsolet, damit vereinfachte sich das Setup und die Achillesferse eines Benutzerkontos mit zu wenig Rechten als potentieller Schwachpunkt für den Clusterbetrieb wurde abgeschafft. Der Clusterdienst läuft nun im Kontext von local system, das Cluster Name Object (CNO) legt fortan die Netzwerknamen an (VCO). Die VCOs bilden den „Client Access Point“ (CAP) für die Zugriffe der Benutzer auf den Cluster. Das CNO ist ebenfalls zuständig für die Kennwortänderungen der VCOs im Active Directory.

Mit Windows Server 2012 R2 ist wiederum ein Schritt in Richtung Unabhängigkeit von AD DS implementiert worden: Man kann nun einen Cluster weitgehend ohne AD betreiben (AD-detached cluster) und für den Bootvorgang eines Knoten (form/join Cluster) muss ein DC nicht mehr zwingend erreichbar sein (AD-less cluster bootstrapping). Für virtualisierte DCs auf einem Hyper-V Cluster ist das Zucker.

Active Directory-less Cluster Bootstrapping
» http://blogs.technet.com/(…)enhanced-integration-with-active-directory-ad.aspx
Ein wichtiges Feature, um Domain Controller weitestgehend virtualisieren zu können und dafür Hyper-V Failover Cluster zu nutzen. Das Henne-Ei-Problem, das ein Cluster nicht ohne AD starten kann und ein DC nicht ohne Cluster auf dem er virtualisiert wurde ist damit passé.

Active Directory-Detached Cluster (Active Directory-less Cluster)
» https://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_ADAg
Diese Option sollte auf Grund der Einschränkungen gut überlegt werden:
» https://technet.microsoft.com/en-us/library/dn265970.aspx
Auch ist diese Möglichkeit nicht für jede Anwendung geeignet, die auf einem Cluster laufen soll. Selbst wenn man eine weitgehende Loslösung von Abhängigkeiten zu einem Active Directory erreichen kann, sollte man sich immer überlegen zu welchem Zweck und für welche Anwendungsfälle.
Hier ist noch einiges im Fluß für vNext und es gibt Kundenwünsche und Bestrebungen z.B. SQL Server Cluster gänzlich ohne ein Active Directory zu betreiben.
Wie ist Eure Meinung dazu? Hinterlasst mir einen Kommentar… 😉

Stay tuned,
N.Own

Shared RAID Controller

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

Netzwerkeinstellungen auf einem Cluster

„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

File Share Scoping

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.
Leider führt das bei vielen Muktifunktionsgeräten (MuFu oder Multifunctional Printer/Peripheral MFP) dazu, dass diese nicht mehr auf eine geclusterte Dateiablage scannen können – viele dieser MuFus nutzen für die Ablage von Scandokumenten ‚rein die IP Adresse und können dazu nicht den Namen verwenden. Hier sind mir Probleme im Zusammenhang mit Ricoh, Xerox sowie Konica Minolta Multifunktionsgeräten bekannt. Es gibt hierfür keine Lösung außer der Hersteller des Geräts bietet eine bereinigte Firmware, die die Korrekte Adressierung einer Freigabe über einen UNC Pfad ermöglicht oder man aktualisiert den Cluster auf Windows Server 2012 oder neuer.
Für Xerox MFPs gibt es in diesem Artikel einen Beitrag, der auch das Verhalten beschreibt, mit einem Workaround:
» http://social.technet.microsoft.com(…)e44fef44-8742-449e-a829-1ccf61689342/

Das Thema File Share Scoping wird in diesem TechNet Blogartikel im Detail beschrieben:
» http://blogs.technet.com/b/askcore(…)
Für Windows Server 2012 oder neuer ist die Möglichkeit über eine SMB Alias Funktionalität wieder gegeben, so dass man über CNAMEs oder IPs auf einen Cluster Share zugreifen kann, siehe: » http://blogs.msdn.com/b/clustering/archive/2012/04/08/10291792.aspx

Stay tuned,
N.Own

Print Cluster Best Practices

Auf dem Microsoft Blog des AskPerf Teams ist kürzlich ein neuer Artikel zum Thema „Windows Print Cluster Best Practices for Windows Server 2003 to Windows Server 2008 R2“, den ich jedem Print Cluster Admin an’s Herz legen kann:

» http://blogs.technet.com/askperf/print-cluster(…)

Die Empfehlungen decken sich mit meinen Erfahrungen bei Print Clustern aus dem Artikel » Print Cluster 101

Beim Troubleshooten sollte man zuerst die o.g. Punkte prüfen, um sicherzugehen, daß nicht grundlegende Spooler Fehler im Cluster die Probleme verursachen.

Stay tuned,
N.Own