Enterprise-NAS-Speichersystem

Test: Hewlett-Packard StorageWorks X9000 IBRIX

14.10.2011 von Thomas Steudten
Hewlett-Packard bietet mit der Serie StorageWorks X9000 NAS-Systeme für den Enterprise-Einsatz an. Das Speichersystem verwaltet Daten im Petabyte-Bereich. Ob neben der hohen Kapazität auch die Features und Administration der X9000 überzeugen, zeigt unser Test.

In großen Rechenzentren dominieren vorwiegend skalierbare und hochverfügbare SAN-Architekturen, die ihren Speicherplatz über schnelle und verzögerungsarme Anbindungen wie FiberChannel und Infiniband den Systemen zur Verfügung stellen. Aber auch Speichersysteme, die über ein IP-Netzwerk eingebunden werden, haben berechtigte Anwendungsgebiete.

Speicherplatz im SAN kann blockbasiert zwar durch Maskierung auf den SAN-Switches und dem Speichersystem gezielt zugewiesen werden, aber eine parallele Nutzung eines Dateisystems mit Zugriff auf die gleichen Daten durch mehrere Client-Systeme bedarf der gezielten Steuerung (Cluster-Dateisysteme). Möchte man die Zugriffssteuerung auf das Dateisystem vom Client weghaben und zusätzlich auch noch die redundanten Host-Bus-Adapter und -Converter für einige tausend parallel rechnende Systeme einsparen, dann kommen performante Netzwerkspeicher (NAS) mit Standardprotokollen zum Einsatz.

Der Fokus liegt hier gerade auf der Möglichkeit, gemeinsame Daten in einem Dateisystem vielen tausend Rechnern ohne Performance-Einschränkungen und Spezialhardware verfügbar zu machen. Mit unserem Testsystem Hewlett-Packard StorageWorks X9720 IBRIX überprüfen wir, wie sich das NAS in der Praxis bewährt

Produktportfolio: NAS und SAN von HP

Betrachten wir nachfolgend den Bereich SAN- und NAS-Speicher-Systeme der Firma Hewlett-Packard. Das Storage-Portfolio im SAN-Bereich umfasst im Low-Budget-Segment das Simple-Unified Storage (iSCSI, NAS) und geht über die MSA2000- und EVA8400- bis hin zur XP24000-Serie. EVA steht bei HP für Enterprise Virtual Array, MSA ist die Abkürzung für Modular Smart Array.

Liegen die Stärken beim EVA in der Virtualisierung, im "Stripe-Everything" auf Logical Unit Ebene (LUN), mit Business-Copy und Continuous Access (CA), fokussiert sich HP mit dem Fusion-Dateisystem "IBRIX" auf verteilte, performante Cluster-Dateisysteme.

HP StorageWorks Arrays: die SAN-Speicherfamilie vom Entry- bis zum Enterprise Level.
Foto: Hewlett Packard

Die aktuelle EVA8400 mit den HSV450-Controllern und bis zu 22 GByte Cache bietet in den M6412-Disk-Enclosures Platz für 324 Disks (FC oder FATA und limitiert auch SSD) mit 4 Gbit/s End-to-End.

HPs StorageWorks-X9000-NAS-Serie

Im Bereich NAS-Appliances stellt die X9000-Serie das Enterprise-Segment dar. Das X9320-Speichersystem wird von HP als Performance-Speicher klassifiziert und bietet 21 bis 192 TByte mit 96 SAS- oder SATA-Festplatten an Speicherplatz mit RAID 1,5, und 6. Transferraten von bis zu 500 MByte/s schreibend und bis zu 1 GByte/s lesend sollen pro Appliance möglich sein. Werden mehr Appliances hinzugefügt, sollen die Transferraten nahezu linear skalieren.

NAS-Appliances: die X-Serie von HP vom kleinen Low-Budget-NAS zum Enterprise-X9000-System.
Foto: Hewlett Packard

Als "Extreme Storage" mit Fokus auf Kosten und Kapazität statt auf Performance wird die X9720er-Serie-Appliance von HP platziert. Bestückt mit 1- oder 2-TByte-Festplatten bietet das Cabinet Raum für acht Kapazitätsblöcke. Die Basiskonfiguration besteht aus einem X9700c Array Controller mit zwölf Disks und einem X9700cx JBOD mit 70 Disks. Die Kapazität beginnt also mit den 82 Disks bei 82 TByte. Sie skaliert dann pro Block bei Verwendung von 2-TByte-HDDs mit 164 TByte auf maximal 1312 PByte. Pro Cabinet kommt auch immer noch ein c-Class BladeChassis für drei bis 16 Half-Size Blades hinzu, wobei jedes System-Blade parallel über SAS-Switches auf die Speicherblöcke zugreifen kann und ein autonomes Linux-Betriebssystem installiert hat.

X9000er-Auswahl: Oben in der Bildmitte sehen Sie das X9320-NAS, links steht die X9720 und unten das Gateway X9300.
Foto: Hewlett Packard

Nummer drei in dieser X9000-Familie ist das X9300-Gateway, das die Möglichkeit bietet, DAS- oder SAN-Speicher in den Single-Namespace des NAS zu integrieren.

IBRIX

Mit der Übernahme der Firma Ibrix Inc Mitte 2009 hat Hewlett-Packard mit der StorageWorks-Serie X9000 ein verteiltes Netzwerkdateisystem mit dem Namen "Ibrix Fusion Filesystem" im Angebot. Dessen Stärken sind im Wesentlichen:

Bei den klassischen Netzwerkdateisystemen greifen mehrere Clients auf den gleichen Dateiserver zu, und dort kommt es oft zu Performance-Engpässen.

Filesystem: Das Ibrix-Fusion-Dateisystem erlaubt eine angepasste und performante Datenablage für unstrukturierte Daten.
Foto: Hewlett Packard

Single-Namespace

Ein Ibrix-Fusion-Dateisystem setzt sich aus vielen physikalischen Dateisystemen zusammen. Jedes lokale Dateisystem wird von nur einem Dateiserverprozess bedient. Als Schicht zwischen den Dateiservern und den auf das Dateisystem zugreifenden Clients werden diese lokalen Dateisysteme den Clients virtuell als ein Single-Namespace dargestellt, der über NFS oder CIFS angesprochen wird. Dies vereinfacht das Management, Kapazität und Performance skalieren beide mit der Anzahl an Dateiservern.

Aufbauend auf einem Speicher-Pool (SAN, DAS), der Datenverlust durch Ausfälle der Festplatten über die bewährten RAID-Level (1, 5, 6) verhindert, setzt das Ibrix-Dateisystem auf dem bekannten Logic-Volume-Management (LVM) auf und wird unter Linux (x64) betrieben (aktuell im Testsystem Red Hat Enterprise Linux Server release 5.3 "Tikanga" mit Kernel 2.6.18-128-el5).

Den lokalen Speicher-Pool im Testsystem bildet ein X9720. Darüber hinaus lässt sich über einen Gateway-Server (X9300) - das sind Systeme mit redundanten Host-Bus-Adaptern (HBA) - auch Speicher im SAN für das Fusion-Dateisystem als Single-Namespace einbinden. Mittlerweile sind die Gateway-Systeme nicht mehr dediziert für diese Aufgabe vorgesehen, sondern übernehmen auch die Funktion eines Segmentservers.

Das Ibrix-Dateisystem besteht aus dedizierten Servern mit Linux als Betriebssystem. Hierzu zählen die sogenannten Segmentserver, die je ein Segment eines Single-Namespaces (= virtuelles Dateisystem) des Dateisystems bedienen, und der Fusion-Manager (FS), der über den Cluster-Verbund als zentrale Instanz wacht. Alle Segment-Server sind über redundante Netzwerkverbindungen über 1GE oder 10GE untereinander verbunden. Über dieses Netz werden sowohl Cluster-Daten als auch Dateisystem-Nutzdaten transportiert. Es besteht ebenso die Möglichkeit, dafür separate Netzwerke aufzubauen. Aufgrund der Übernahme von Ibrix Inc. durch HP gibt es unterschiedliche Formulierungen im Ibrix-Dateisystem-Kontext. File Serving Nodes sind Segment-server. Und ein X9000 Client besteht aus einem Linux/Windows-System.

Die Softwarelösung wird seitens HP im Packet mit aktuellen Blade- und Storage-Arrays angeboten.

Client-Anbindung

Für die Client-Anbindung stehen die standardisierten Netzwerkprotokolle CIFS, SMB1.0 und NFSv3 zur Verfügung. SMB2.0 soll in einer neueren Version unterstützt werden. Ob NFSv4 künftig verfügbar sein wird, ist noch offen.

Daneben erlaubt der IBRIX-/X9000-SW-Client (aktuell nur unter Windows-Betriebssystemen verfügbar) eine proprietäre Anbindung über einen Treiber, der ein Ibrix-Dateisystem als lokale Festplatte einbindet. Die dazu notwendigen Informationen holt sich der Client vom Fusion-Manager; dessen Adresse muss vorher bekannt sein (registriert). Die Verbindung hält ein Serviceprozess im Hintergrund aufrecht.

Ein System spricht den CIFS-Share oder den NFS-Server über eine relozierbare Cluster-IP-Adresse beziehungsweise einen dazu passenden Host-Namen an.

Segment-Server

Auf den Segment-Servern identifiziert sich ein aktives Ibrix-Dateisystem über den Dateisystemtyp "ibrix":

# mount

> data1 on /data1 type ibrix (rw,fsname=data1,segbits=38)

Für diese Funktionalität ist ein Kernel-Modul "ibrix" geladen:

# modinfo /lib/modules/2.6.18-128.el5/kernel/fs/ibrix/ibrix.ko

filename: /lib/modules/2.6.18-128.el5/kernel/fs/ibrix/ibrix.ko

license: COM

description: Ibrix distributed segmented FS

author: Ibrix, Inc.

srcversion: 5A8BBADE3A9710D2B2FF71E

depends: sunrpc

vermagic: 2.6.18-128.el5 SMP mod_unload gcc-4.1

Da der SMB-Server Samba als Single-Prozess in die Jahre gekommen ist und damit auf Mehrprozessorsystemen nicht gut skaliert, kommt bei Ibrix der Likewise-CIFS-Server zum Einsatz. Likewise wurde von Grund auf multithreaded programmiert und skaliert besser. Vor allem ermöglicht Likewise eine Parallelverarbeitung, wo der Single-Samba-Prozess (Netzwerk- und Filesystem-I/O) blockieren würde.

Benutzeroberfläche und Kommandozeile

Neben einer klassischen Java-basierten Webbenutzeroberfläche, die sowohl den Internet Explorer (7/8) als auch Firefox 3.5/3.6 unterstützen soll, stehen Tools im Pfad /usr/local/ibrix/bin (= Variable $IBRIXHOME/bin) für die Kommandozeile bereit. Viele Ibrix-Befehle nutzen den Präfix "ibrix_", die symbolische Links auf das Wrapper-Shellskript "ibrix_cli_cmd" sind, das ebenfalls eine Java-Umgebung nutzt. Konfigurationen finden sich im Verzeichnis "/etc/ibrix".

Administration: Nach dem Anmelden auf der X9000er-Konsole lassen sich wesentliche Aufgaben hier erledigen.
Foto: Hewlett Packard

Über den Redhat-Package-Manager (RPM) lassen sich die für Ibrix notwendigen Pakete installieren. Als Beispiel:

Redhat-Package-Manager

Paket

Version

Funktion

IbrixCommon

5.4.1047

Gemeinsame Bibliothekmodule und Utilities

IbrixFS

5.4.1051-2.6.18.128.el5

Kernel-Komponenten für das Mounten des Ibrix-Dateisystems

IbrixFusionManager

5.4.1047-1

FusionManager Komponenten

ibrix_install_data

1-1.ibrix

Setup Skripte als Ibrix-Appliance

ibrix_install_packages

1-1.ibrix

Setup-Skripte als Ibrix-Appliance

ibrix_install_tools

1-1.ibrix

Setup-Skripte als Ibrix-Appliance

IbrixServer

5.4.1047-1

Ibrix-Segmentserver

ibrix_statstools

5.4.1047-1

Statistics & Reporting

name_eths

0.4-el5.1.ibrix

Ethernet-Device-Nummerierung

Likewise-cifs

5.4.1.43212-107346

CIFS Server

Seit Juli 2010 ist 5.4.1 die aktuell verfügbare Version. Der Kommandozeilenbefehl "ibrix_top" liefert im Default-Modus einen sich aktualisierenden Status über aktive Ibrix-Dateisysteme, die Anzahl der Segmente, die Dateisystemauslastung, aktive Prozesse und über die Netzwerk-Interfaces. Die Host-Seite (2) zeigt I/O-Performance-Daten der aktiven Segmentserver und Client-Systeme. Die Nutzung der Segmente im Detail zeigen die Segment- und Allsegment-Seiten (3+4). Analog dazu Seite 5, eine I/O-Übersicht auf OS-Blocklevel, das heißt sd und mpath devices unter Linux.

Shell-Befehl: Die installierte Ibrix-Version lässt sich auch über das Kommando "ibrix_version -l" auf dem FusionManager-System ermitteln.

Funktionsweise Ibrix-Dateisystem

Das Ibrix-Fusion-Dateisystem besteht zunächst aus einer Vielzahl von Block-Devices. Im Logical-Volume-Manager-Kontext sind diese auch als Physical-Volume (PV) benannt.

Auf der Kommandozeile lassen sich die PVs und Volume-Group (VG und Logical Volumes (LV) anzeigen, wie Sie in folgender Galerie sehen:

Bildergalerie: Ibrix-Dateisystem
Ibrix-DateisystemDateisystem
Die Physical-Volumes (PV) können mittels der Option „-l“ gelistet werden. Alle normalen PVs beginnen mit dem Buchstaben „d“, gespiegelte mit dem Buchstaben „m“ für Mirror. Angehängt daran folgt eine fortlaufende Zahl. Die Spalten ab „RAID_Type“ bis zum Ende werden in dieser Version nicht genutzt. „ibrix_pv –a“ sucht nach neuen PVs und „-d“ löscht diese als PV wieder. Im Gegensatz zum LVM Pendant „pvs“ agiert das ibrix-Kommando auf allen Segment- bzw. Dateiservern im Verbund und bindet verfügbaren Speicher im Cluster ein.
Ibrix-Dateisystem
Aus den PVs wird dann eine Volume-Group (VG) gebildet, die aber im IBRIX-Kontext nicht wirklich genutzt wird.
Ibrix-Dateisystem
Und aus den VGs, dann die so genannten Logical-Volumes (LV). Diese entsprechen in der IBRIX-Syntax den Segmenten, aus denen sich das IBRIX-Dateisystem letztendlich zusammensetzt. Normalerweise würde man nun pro Logical-Volume ein Dateisystem anlegen und dieses lokal einhängen (LVM). Das IBRIX-Dateisystem legt jedoch das Dateisystem über alle angegebenen LVs an und vergibt die Hoheit über diese LVs bzw. Segmente per Round-Robin pro Segment an die Server, wenn keine andere Option dazu angegeben wurde. So wird per Default eine Lastverteilung erreicht und Hotspots werden so gut wie möglich vermieden. Ein Verzeichniseintrag (=mount point) für das neue Dateisystem auf allen Servern ist notwendig, bevor es dort eingehängt werden kann.
Ibrix-Dateisystem
Nach dem Systemstart werden auf den Segment-Servern die nachfolgenden Startup-Skripte ausgeführt, die die notwendigen Prozesse starten: ibrix_fusionmanager, ibrix_server, ibrix_statsagent, ibrix_statsmanager und ibrix_statsserver. Das neue Dateisystem “Test” basierend auf den LVs ilv1..4 wird neu angelegt und im Modus “lesend/schreibend” im Verzeichnis “/Test” auf allen Servern eingehängt.

Ibrix-File-System im Detail

Das Ibrix-Dateisystem weist folgende Hauptmerkmale auf:

Ibrix kann als 32- oder als 64-Bit Dateisystem angelegt werden, wobei im 32-Bit-Modus sowohl 32- als auch 64-Bit-Applikationen unterstützt werden. Eine Migration ohne Datenverlust kann einmalig von 32 auf 64 Bit erfolgen, und Letzteres erlaubt eine unbegrenzte Anzahl an Segmenten. Entscheidet man sich aber für ein 32-Bit-Dateisystem, dann ist die Anzahl der Segmente pro Dateisystem begrenzt (15, 31, 63, 127, 255). Die Ausgabe "Compatible?:Yes" beim Aufruf von "ibrix_fs -i" zeigt den 32-Bit-Modus an.

Dateisystem-Assistenz: Über den GUI Wizard lässt sich ein neues Dateisystem mit diversen Optionen anlegen.
Foto: Hewlett Packard

Die Access Control Lists (ACL) von Windows-Clients werden im Ibrix-Dateisystem genau verwaltet, ebenso die Posux ACL unter Linux. Eine Konversation zwischen beiden erfolgt aber nicht, das heißt, jede Umgebung hat die für sie typischen Zugriffsrechte, die jeweils angepasst werden müssen.

Ein Dateisystem kann wie beschrieben aus mehr als einem Segment bestehen. Das erste Segment (1) ist das Root-Segment. Wenn ein Dateisystem auf allen Systemen eingehängt wird, muss das erste angeführte System die Kontrolle über das Root-Segment haben, das heißt, dieses ist der aktuelle Besitzer darüber. Ein Dateisystem kann nur gelesen (RO - default) oder auch geschrieben werden (RW). Welcher Modus aktiv ist, kann beim "ibrix_mount -o RW|RO" spezifiziert werden.

Dem Root-Segment kommt eine besondere Bedeutung zu, da dort auch notwendige Daten über das Dateisystem vermerkt werden und das globale "lost+found" vorgehalten wird. "ibrix_fsck" verschiebt "verlorene" Dateisystemblöcke vom lokalen "lost+found" zum globalen. Während des Datei-Checks wird ein Flag "INFSCK" gesetzt, das gegebenenfalls manuell zurückgesetzt werden muss (Option -C).

Tiering

Eine weitere Eigenschaft des Ibrix-Dateisystems ist die Möglichkeit, Dateien automatisch im Dateisystem zu verschieben. Das Tiering genannte Modell entspricht in etwa dem des Hierarchical Storage Management (HSM) und erlaubt beispielsweise einen Tier mit mindestens einem Segment mit langsamen oder Low-End-PVs.

Dateien, auf die oft zugegriffen wird, können so im schnellen Tier gehalten werden, andere weniger genutzte Daten automatisiert in einem langsamen Tier - aber immer im gleichen Dateisystem.

Schnell oder langsam: Mit Tiers können Dateien im gleichen Dateisystem unterschiedlichen Speichertypen zugewiesen werden.
Foto: Hewlett Packard

Dateibezogene Regeln können sich auf die nachfolgenden Attribute beziehen:

"ibrix_tier" und "ibrix_migration" sind die Tools im Tiering-Bereich. Pro Dateisystem kann lediglich eine Tiering-Operation aktiv sein. Eine Wiederaufnahme nach einem Fehler oder nach einem Stopp ist nicht möglich, ebenso wenig eine Ausführung zeitgleich mit dem Rebalance- oder Replikationsprozess. Zudem hat auch der Replikationsvorgang Vorrang und stoppt eine laufende Tiering-Migration. Ein Beispiel für einen Tiering-Aufruf sehen Sie im nachfolgenden Bild.

Tiering-Beispiel: Kommandozeilenbefehl für das Tiering mit Ibrix.

Um Quotas (Größenlimits) zu definieren und für das Dateisystem zu aktivieren, ist dieses zu deaktivieren (umount). Das Deaktivieren der Quota-Überwachung ist dagegen in beiden Dateisystemzuständen möglich:

# ibrix_edquota .. für Benutzer- und Gruppen-Quota

# ibrix_fs_ops .. für Verzeichnis-Quota

Für die Quota-Überwachung ist der Monitorprozess "ibrix_quotamonitor" verantwortlich.

High-Availability

Im täglichen Betrieb sind die Segmente der Dateisysteme gemäß der Systemleistung der Server definiert verteilt worden. Fällt nun aber ein Segmentserver aus, so sind diese Segmente erst einmal nicht mehr verfügbar. Für diesen Fall ist pro Segment und pro Server immer ein Stand-by- oder auch Backup-Server definiert.

Drei Ausfall-Levels sind definiert:

Check: Der Status aller Segmentserver kann mit dem Befehl "ibrix_health -l" eruiert werden.

Ibrix-Replikation

Mittels der automatisierten Replikation können bis zu sechs Kopien von Dateien oder Verzeichnissen kreiert werden, sobald eine Datei erzeugt wird. Ein unterer und oberer Schwellenwert für die Zahl der Kopien definieren die Arbeitsweise der Replikation:

Die Replikationsregeln können jederzeit angepasst werden, jedoch sind dann die Kopien erstmalig manuell für das Dateisystem anzulegen. Neben dieser lokalen Replikation (Kopie) gibt es noch die Möglichkeit der Continuous File Replikation (CFR) zu einem anderen Cluster (Remote Replication). Dazu wird der Prozess "ibrcfrworkerd" mit der Konfiguration unter "/etc/ibrix/engine/ibcfrworkerd.conf" als Hintergrundprozess (daemon) gestartet. Die dazugehörigen Jobs werden mit "ibrix_cfgjob" verwaltet. "-o" beispielsweise synchronisiert beide Seiten erneut.

Fusion-Manager

Der Fusion-Manager ist die zentrale Managementkomponent,.und diese ist immer auf nur einem System aktiv.

Bildergalerie: Ibrix Fusion Manager
HP StorageWorks X9000 - Fusion Manager
Welche Manager sind registriert?
HP StorageWorks X9000 - Fusion Manager
Welcher ist aktiv?
HP StorageWorks X9000 - Fusion Manager
Der aktive Manager lässt sich in den Wartungsmodus versetzen. Damit wird ein anderes System zum aktiven Manager.

Fazit

An sich sollte die HP StorageWorks X9720 Ibrix eine stabile und skalierbare Lösung mit einem Single Namespace und hoher Verfügbarkeit sein, doch sie erfüllt die Erwartungen nicht so recht. Veraltete Softwarepakete und eine Replikation, die mehr schlecht als recht funktioniert, tragen ihren Teil zum Gesamtbild bei.

Access-Based-Enumeration (ABE), also das Ausblenden von Verzeichnissen durch den Server, wenn keine Leserechte existieren, ist noch nicht implementiert. Auch sind Quota-Richtlinien und Access-Control-Lists (ACL) noch nicht ganz praxisnah umgesetzt worden. Eine unterbrochene oder modifizierte Replikation bedarf manueller Eingriffe, um wieder einen stabilen Zustand zu erhalten. Gesetzte Quota-Limits lassen sich speziell für Verzeichnisse nicht auf dem X9000-Client abfragen, obwohl diese zur Anwendung kommen.

Optimiert scheint IBRIX eher für den parallelen, unbeschränkten Zugriff durch den gleichen Nutzer auf einer hohen Zahl an Systemen auf das gleiche Dateisystem mit vielen hundert Petabyte an Daten. Beispiele hierfür sind das Berechnen von Animationssequenzen oder schnelles Speichern und langfristiges Archivieren von großen Datenmengen, wie sie von bildgebenden Geräten in der Medizin (3-D-CT, MRT) benötigt werden. Dort ist die Datenmenge vom CT von 60 auf 900 MByte beim 64+ slice gewachsen. Dies wird auch in Zukunft so sein, denn in 18Monaten verdoppelt sich die notwendige Datenmenge stets. (cvi)