© pixelputze, Photocase.com

Bis zu 8 GBit/s liefert ein per Fibre Channel verkabeltes SAN. Damit ein Linux-Host dabei nicht den Bach runtergeht, will der Host-Bus-Adapter gut ausgewählt und konfiguriert sein. Ein Bericht aus der Praxis.

Da Rechenzentren und ähnlich große IT-Landschaften zu Linux\’ natürlichem Lebensraum zählen, müssen damit ausgerüstete Server auch innige Kontakte zu Storage Area Networks halten. Alle Hosts im SAN besitzen Zugriff auf ein oder mehrere Storage Arrays, die Verbindung erfolgt entweder Filesystem-basiert per NAS oder Block-basiert via I-SCSI oder Fibre Channel (FC). Am weitesten verbreitet ist die FC-Architektur, in den kleineren und mittleren Segmenten gewinnt I-SCSI aber an Bedeutung.

Das SAN vereinfacht dem Admin das Verwalten des Speicherplatzes. Er kann einem Host sehr schnell mehr Speicherplatz zuweisen und auf vielfältige Weise die Daten des Storage-Systems migrieren, klonen, replizieren oder an andere Standorte spiegeln (Desaster Recovery). Mehrere Server, auch als Cluster, dürfen gleichzeitig auf denselben Speicherplatz zugreifen. Fibre Channel [1] überträgt derzeit maximal 8 GBit/s, am verbreitetsten sind aber 4-GBit/s-Komponenten.

Um auf ein Fibre-Channel-SAN zuzugreifen, benötigt ein Host einen Host-Bus-Adapter, kurz HBA, je nach Host-Hardware als PCI-X- oder PCI-Express-Version. In großen Umgebungen sind HBAs von Emulex [2] und Qlogic [3] der Stand der Dinge (Abbildung 1). Viele Serverproduzenten verkaufen mit ihren Produkten OEM-HBAs beider Hersteller. Auch für die FC-Switches gibt es nur wenige Firmen, die wichtigsten: Cisco, Qlogic und Brocade. Den Vierten im Bunde, McData, hat vor einiger Zeit Brocade übernommen. Wie bei den HBAs leiten sich von Brocade-Switches viele OEM-Produkt ab.

Abbildung 1: Die Hersteller Emulex und Qlogic beherrschen bei Fibre Channel den Adapter-Markt. Links das Modell LPe 12000, rechts QLE 2462.

Abbildung 1: Die Hersteller Emulex und Qlogic beherrschen bei Fibre Channel den Adapter-Markt. Links das Modell LPe 12000, rechts QLE 2462.

Das einfachste SAN besteht aus einem Fibre-Channel-Switch, einem Storage-Array mit Controller und den angeschlossenem Hosts mit je einem HBA. Dieses Setup taucht in der Praxis aber nicht auf, da es mehrere Single Points of Failure aufweist. Sobald der FC-Switch oder der Storage-Controller im Array ausfällt, ist\’s mit dem Zugriff auf die Daten Essig.

Firmware-Praxis

Darum besteht ein SAN im Rechenzentrum aus mindestens zwei unabhängigen FC-Switches (Fabrics), einem Storage-Array mit redundanten Storage-Controllern und mindestens zwei HBAs pro Host, jeweils verbunden mit einem Switch. Hier darf eine Komponente ausfallen, ohne dass die Hosts den Zugriff auf ihren Speicherplatz verlieren.

Damit dies im Fehlerfall sicher funktioniert, sollte der Admin beim Anschluss eines Linux-Host einiges beachten, beispielsweise, dass die HBA-Firmware auf einem von Storage- und SAN-Herstellern zertifizierten Stand ist. Die Firmen stellen dazu Dokumente und Kompatibilitätsmatrizen zur Verfügung. Auf den Websites von Emulex und Qlogic liegt zudem dedizierte Firmware zum Flashen der HBAs nach Storage-Herstellern geordnet.

Die Firmware besteht aus einer Komponente für den Normalbetrieb und einem Boot-Bios. Dessen bedarf es nur, wenn der Host über die HBAs vom Storage-Array booten soll. Das Flashen der HBA-Firmware erfolgt entweder über die gute alte DOS-Bootdiskette oder über dedizierte Management-Tools vom Hersteller.

Welchen Treiber nehmen?

Wie bei der Firmware sollte auch der Linux-Treiber auf einem vom Storage-Anbieter zertifizierten Stand sein. Einige Hersteller liefern speziell für ihre Systeme optimierte Treiber aus, andere haben die enthaltenen Standardtreiber der kommerziellen Enterprise-Distributionen wie RHEL oder SLES zertifiziert. Auf den HBA-Herstellerseiten sind die Download-Möglichkeiten wieder nach Storage-Vendors geordnet oder es gibt Links zu den Anbietern.

Meist liegen die Treiber als RPM-Pakete vor. Vor ihrer Installation oder einem Treiber-Upgrade sollte der Admin die aktiven Treiber mit »modprobe -r HBA-Treiber« entladen. Je nach Hersteller muss er nach dem Einspielen des Pakets die Dateien »modprobe.conf« und »modprobe.conf.local«, eventuell auch »/etc/sysconfig/kernel«, anpassen und eine neue Ramdisk erzeugen. Manche Treiberpakete enthalten auch Installer, die den ganzen Vorgang automatisieren, zum Beispiel Emulex das Skript »lpfc-install«.

Neben Treibern bedienen Emulex und Qlogic den Admin mit Management-Utilities – als CLI (HB Anyware CLI und SAN Surfer CLI) und als GUI (HB Anyware und SAN Surfer). Qlogic biete noch weitere Tools an, als besonders nützlich erweist sich das Qlogic FC HBA LUN Scan Utility [4]. Es scannt nach neu zugewiesenen Devices, ohne den HBA-Treiber ent- und neu laden zu müssen.

Immer das Neueste

Wer einen neuen Host an ein SAN anschließt, sollte sich zur Gewohnheit machen, bei Firmware und Treibern stets die neueste zertifizierte Version für seine Distribution einzusetzen. Eine offiziell unterstützte Konfiguration zu betreiben, stellt den Zugriff auf den Herstellersupport des Array und der Switches sicher. Die Anbieter von Enterprise-Linux-Distributionen arbeiten mit den Storage-Herstellern zusammen. Wenn sie Treiber updaten, (re-)zertifizieren die Storage-Anbieter diese meist nach kurzer Zeit.

Als letztes Glied der Kette bleibt trotzdem der Admin für den Zustand seiner Systeme verantwortlich: Wenn er Arrays mehrerer Hersteller betreibt und einem Host Speicher auf verschiedenen Systemen zuweist, kann es zu Kollisionen kommen. Hier sollte er schon vorab den Herstellersupport einschalten, um einen gemeinsamen Nenner zu finden, der Funktion und Supportanspruch sicherstellt.

Im nächsten Schritt steht die Überprüfung der HBA-Treibereinstellungen an: Die wichtigsten sind Topologie, Geschwindigkeit und Timeouts. Hier ist es von Vorteil, die Empfehlungen des Storage-Herstellers zu kennen. Einige Parameter – speziell die Timeout-Settings – sind davon abhängig, ob die Anbindung zum Storage redundant ist oder nicht (siehe Kasten “Typische Fehlersituationen”). Bei Qlogic lassen sich sehr viele Parameter schon im NVRAM des HBA per Bios-Menü konfigurieren. Bei Emulex-HBAs ist für die 7.x-Treiber die »lpfc.conf« zu editieren, für neue 8.x-Treiber die »modprobe.conf.local«. Danach bringt der Admin die Ramdisk auf den neuen Stand, damit Linux die Änderungen übernimmt.

Redundanzen verwalten

Je nachdem, ob der Host ein- oder mehrpfadig am SAN hängt, kommt die Multipath- oder Failover-Software zum Zug: die native Linux-Multipath-Software DM-MPIO [5], eine Third-Party-Applikation wie Veritas DMP [6] oder ein auf das eigene Storage optimiertes proprietäres Tool des Herstellers. Bei Qlogic-Treiber ist bereits eine Failover-Behandlung integriert, sie hat jedoch die redundanten Pfade schon für das Betriebssystem maskiert, was sie inkompatibel mit allen anderen Failover-Lösungen macht. Wer darum das Qlogic-interne Failover nicht nutzt, sollte es im HBA-Bios deaktivieren, ansonsten beißt sich jede anderen Multipathing-Software die Zähne aus.

Damit die Hosts das SAN nutzen dürfen, muss natürlich auch das Storage entsprechend konfiguriert sein, also welcher HBA mit welchen Port des Storage-Array kommunizieren darf (Zoneing) und mit welchem Speicher (Lun Masking). Hierbei unterstützen wieder die Management-Tools der HBA-Hersteller den Admin, da sie einen schnellen Überblick über den Zustand des HBA liefern: Mit welcher Geschwindigkeit er sich zum SAN verbunden hat und an welche Ports. (jk)