Aus aktuellem Anlass ein kurzer Abriss zur Fabric Adressierung. Jeder der sich mit Fibre-Channel SANs beschäftigt kennt die ewig langen World Wide Port bzw. World Wide Node Names (WWPN und WWNN). Unterschied: Jeder Port eines Devices hat einen World Wide Port Name. Aber jedes Device hat nur einen World Wide Node Name. Damit stellt das Protokoll sicher, dass es anhand von WWPN und WWNN Devices mit mehreren Host Ports erkennt. In der Praxis etwas schwammig... Nun hat jeder sicherlich schon mal die 24 Bit langen Fabric Adressen gesehen, z.B. 0x10001. Über diese werden die Frames in einer Fabric adressiert. Diese Adresse setzt sich aus drei Bestandteilen zusammen:

• Domain
• Area
• Port

Domain entspricht der Domain ID eines Switches. Die Area ist der Port am Switch, Port ist in einer Switched Fabric i.d.R. 0, kann bei FL-Ports aber auch anders sein. Über die Fabric Adresse bekommen wir also einen eindeutigen Pfad. Diese Fabric Adresse fließt bei vielen Betriebssystemen mit in die SCSI Adressierung, den Hardwarepfad ein. Demzufolge kann eine niedrige Fibre-Channel Adresse auch zu einer höheren Position im Pfad führen. Und aus genau dem Grund, sollte man nachträglich auch nichts umstecken - dann ändert sich auch die Fibre-Channel Adresse und damit der Pfad. Kann problemlos sein, kann aber auch Ärger machen. Und deswegen Tapes, nach Möglichkeit am Switch mit der niedrigsten ID, am niedrigsten Port.

EDIT: Wegen vieler Mails mit Anfragen der Hinweis auf zwei ältere Beiträge von mir. Passen zum Thema und sind sicherlich auch interessant.

The do's and don'ts of zoning
FSPF - Fabric Shortest Path First

SSD Benutzer sollen, der Lebensdauer der SSD zuliebe, die Windows Search abschalten. Ich habe eine SSD und hatte die Windows Search auch brav deaktiviert, aber irgendwie kann ich dann doch nicht darauf verzichten. Ich bin aber erst jetzt dahinter gekommen, warum die Windows Suche keine PDF Dokumente indiziert, obwohl PDF als Dateityp in den Indexoptionen eingetragen ist. Der Grund ist ein fehlender iFilter für PDF. Dieser wird zwar vom Adobe Reader mitgeliefert, aber wer ein 64 Bit OS benutzt, muss sich den passenden iFilter separat herunterladen. Nach der Installation klappt des dann auch mit dem Indizieren von PDF Dokumenten. Bei Adobe kann man sich den iFilter hier herunterladen. Einziger Wermutstropfen: Man muss den Index neu erstellen lassen. Sollte aber bei einer SSD nicht allzu lange dauern. ;)

Mittlerweile bekomme ich regelmäßig Anfragen über mein Blog, ob ich mir mal dieses oder jendes Problem ansehen könnte. Der geringste Teil davon wird wirklich zu einem Auftrag, meist ist das Problem nach ein paar Mails gelöst oder es geht einfach nur um ein wenig Feedback oder Input. Nun war ich am vergangenen Freitag in den Niederlanden. Im November bekam ich eine Anfrage von einem Leser, dem in seiner DataCore Umgebung immer wieder einzelne Pfade zwischen VMware ESX und DataCore Storage Servern weggebochen sind. Das Problem trat bereits unter DataCore SANmelody 3 auf, blieb aber auch nach einer Migration auf DataCore SANsymphony-V bestehen. Nach einem Upgrade von vSphere 4 auf vSphere 5 verschlimmerte sich das Problem. Nun flogen zwar keine Pfade mehr weg, dafür gab es im laufenden Betrieb immer wieder extrem hohe IO-Latenzen. Wir reden hier nicht von 100ms, sondern die Latenzen gingen hoch bis auf mehrere tausend Millisekunden. Das Problem trat innerhalb weniger Stunden auf, sobald die Round-Robin Pathing Policy unter VMware ESXi aktiviert wurde. Beim Einsatz der Fixed Path Policy tat der Fehler nicht auf.  VMware, DataCore, Qlogic und der Lieferant der Umgebung waren in den Fall eingebunden. Sicherlich keine einfache Sache, wenn soviele Hersteller eingebunden sind, und der Fehler irgendwo zu suchen ist. Es wurden auch im Verlauf des Supportfalls zwar Dinge entdeckt, aber einen echten Root-Cause konnte keiner identifizieren. Die Umgebung war relativ einfach, keine exotischen Dinge: Wortmann Server (Intel Barebone), Qlogic FC-Switches und FC-HBAs, Xyratex FC-Storage im Backend (bauen z.B. die Disk Enclosures für HP 3PAR). Die DataCore Implementierung war nach Lehrbuch (HBAs für Frontend, Backend und Mirror etc.) und war von DataCore abgenommen worden. Trotzdem gab es seit September 2011 keine Besserung und keine Identifikation des Root-Cause. Nun war ich am Freitag vor Ort. Ich hatte vorher schon häufig Kontakt Kunden, daher kannte ich die Umgebung in groben Zügen. Nach einem kurzen Blick über den Rest der Umgebung war ich mir sehr sicher, dass das Zoning das Problem war. Mehrere Initiator und Targets in einer Zone. Das gesamte Frontend-Zoning bestand aus zwei Zonen. Backend sah auch nicht anders aus. Bei sowas habe ich immer ein ganz schlechtes Gefühl und ich hatte selber schon Probleme mit dieser Form des Zonings. Wir haben dann gemeinsam das Zoning auf ein "Single Initiator, Single Target Zoning" umgebaut. Freitagabend hat der Kunde die VMware ESXi Server wieder auf Round Robin umgestellt. Bis heute läuft die Umgebung problemlos. Es war also mit extrem hoher Wahrscheinlichkeit ein nicht optimales Zoning.

Es ist ein schönes Beispiel dafür, welche Auswirkungen ein suboptimales Zoning auf die Stabilität und Performance eines FC-SAN haben kann. Daher sollte man hier immer folgende Dinge beachten:

• Single Initiator, Single Target Zonen bilden. Also immer nur ein HBA und ein Storage Hostport in einer Zone.
• Disk und Tape niemals in einer Zone mischen
• Tapes immer an den Switch mit der niedrigsten Domain ID am niedrigsten Port

Beachtet man diese drei grundsätzlichen Regeln, erspart man sich mit extrem hoher Wahrscheinlichkeit eine Menge komischer Probleme. In größeren Umgebungen kommen sicherlich noch weitere beachtenswerte Punkte hinzu, aber für kleine Dual-Fabric SANs reichen diese drei Hinweise meist aus. Ich weiß das es in der Literatur häufig anders beschrieben wird. Ich finde auch immer wieder Umgebung in denen KEIN Zoning implementiert ist (sehr kleine FC-Umgebungen, ein Storage, zwei oder drei Hosts). Egal was die Hersteller sagen: Zoning ist Pflicht. Immer!

Ich liebe Blade-Server. Sie sind ein wunderbares Stück Technik. Gerade mit ein paar Spielereien wie HP VirtualConnect o.ä. lassen sich auch große Serverinstallationen einfach verwalten. Selbst bei kleinen Installationen ist so ein "Datacenter in a Rack" echt nice. Ein Rack, ein C3000, ein paar Blades, etwas VMware und eine P4000 und schon geht die Post ab. Aber zwei Dinge machen wir immer Angst: Der Stromverbrauch pro Rack und der Lärm. Ich sitze ca. 15m von zwei BL620c G7 entfernt, getrennt durch zwei Wände. Ich sitze in einem Büro, die Blades stehen im RZ. Und ich höre sie... Okay, nur beim Einschalten, klingt aber schon echt spektakulär.

Bereits im November konntem eine Kollegen und ich mit einer HP 3PAR F200 rumspielen. Am Donnerstag kam das Demosystem erneut zu uns in Haus und wir konnten das gesamte Wochenende damit rumspielen. Die Maschine ist zwar noch ein paar Tage bei uns, aber an einem Wochenende schafft man doch mehr, als an ein paar Abenden. Wir haben die Zeit für ein technischen Training und diverse Tests genutzt. Avnet hat uns für den Zeitraum ein Case mit

• HP 3PAR F200 (16x 300 GB FC, 8x 1 TB NL)
• HP 3PAR Service Processor
• HP ProLiant DL360 G6 Management Server
• HP SN6000 Fibre Channel Switch
  

zur Verfügung gestellt. Aus eigenem Bestand kamen noch zwei HP ProLiant DL160 G6 samt FC-HBAs, sowie ein HP ProCurve 2510-24G hinzu. Genug Material um meine Kollegen zum einen in Sachen HP 3PAR Basics und Administration fit zu machen, zum anderen um Tests mit VMware vSphere 4.1 und 5.0 (Upgrade vSphere, Storage DRS, Zusammenspiel mit 3PAR vCenter Plugin, 3PAR Dynamic Optimization, VAAI etc.) durchzuführen. Man hat ja nicht allzu oft die Gelegenheit wirklich gnadenlos rumzuprobieren. :) Die Performance der F200 war beeindruckend. Wirklich erstaunlich, was man aus der Kiste rausquetschen kann.

Mit dem Patchbundle b621 hat HP die HP StoreOnce Technologie auch bei HP Data Protector integriert. Was bedeutet das? Mit der Einführung von StoreOnce in HP Data Protector gibt es ein neues Device: "Backup To Disk". Die "altbekannte" File Library gibt es aber immer noch, nur nutzt diese nicht die neue StoreOnce Technologie. Kunden die eine bestehende Advanced Backup to Disk Lizenz haben, können nach der Installation von DP 6.20 samt Patchbundle b621 die neue Technik nutzen. Es entstehen keine weiteren Kosten.

Es wird zwischen Deduplication System und Gateway unterschieden. Ein Deduplication System ist jede Maschine, welche die StoreOnce Komponente installiert bekommen hat. Diese Maschine stellt den sog. Store bereit, also den Bereich, wo die deduplizierten Daten liegen. Dieser Host übernimmt die Deduplizierung. Obwohl es sich bei einer StoreOnce Library auch um ein B2D Device handelt, kann dieses von mehr als einem Media Agent angesprochen werden. Die altbekannte Limitation auf einen Stream pro Media Agent entfällt damit. Und hier kommen dann die Gateways ins Spiel. Ein Gateway ist ein Host mit einem Media Agent. Die Gateways sind also die File Writer, welche die Daten in das Deduplication System schreiben. Hier kann ich auch mehrere Gateways anlegen um zu skalieren. Um maximalen Nutzen aus der Deduplizierung zu ziehen, startet ein Disk Agent nur einen Stream zu einem Media Agent. Vorher konnte man über die Concurrency die Anzahl der Streams von einem Disk Agent zu einem Media Agent steuern. Das geht nun nicht mehr. Zwar können mehrere Disk Agents gleichzeitig ein Gateway nutzen, aber eben nur ein Stream pro Disk Agent. An dieser Stelle noch mal der Hinweis: Die Deduplizierung geschieht auf dem Deduplication System. Nicht auf dem Storage (z.B. lokale Platten oder Storage in einem SAN) und nicht auf dem Media Agent. Dedup auf dem Media Agent wird im nächsten DP Release unterstützt. Damit kann ich dann bereits auf dem Client deduplizieren und die deduplizierten Daten werden übertragen. Hier kommt auch eine der Stärken von StoreOnce zum tragen: Es ist ressourcenschonender als die vergleichbaren Techniken von CommVault oder Symantec. Laut HP braucht StoreOnce ca. 300 MB RAM für bis zu 1 TB deduplizierter Daten. CommVault braucht 4 GB für bis zu 4 TB, und dann 1 GB RAM pro weitere 1 TB Daten. Da die Daten von HP kommen, würde ich sie mit Vorsicht genießen. ;)