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.
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.
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.
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:
-
Single Namespace bis 16 PByte
-
Skalierbare Bandbreite und Applikation-Performance
-
Zero Downtime
-
Paralleler Zugriff für Tausende Systeme
-
Optimiert für unstrukturierte Daten
Bei den klassischen Netzwerkdateisystemen greifen mehrere Clients auf den gleichen Dateiserver zu, und dort kommt es oft zu Performance-Engpässen.
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".
Über den Redhat-Package-Manager (RPM) lassen sich die für Ibrix notwendigen Pakete installieren. Als Beispiel:
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.
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:
Ibrix-File-System im Detail
Das Ibrix-Dateisystem weist folgende Hauptmerkmale auf:
-
Verteiltes Dateisystem
-
32- oder 64-Bit-Modus
-
Quota-fähig (aktiv nur: offline): Benutzer, Gruppe und Verzeichnis
-
Tier-fähig
-
Nur-Lese fähig
-
Ohne Unterbruch vergrößerbar
-
Windows- und Posix-ACL - nterstützt
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.
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.
Dateibezogene Regeln können sich auf die nachfolgenden Attribute beziehen:
-
Zeitstempel der Datei (change/ create, modification, access)
-
Dateigröße
-
Dateityp (nur Datei)
-
Dateiname (Bsp: *.jpg)
-
User- oder Gruppen-ID (uid, gid: numerisch oder Text)
"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.
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:
-
Server-Level - fällt ein Segmentserver aus, übernimmt dessen Backup-Server dessen Segmentmanagementaufgaben.
-
Segment-Level - alle Segmente, für die dieser Server der Besitzer war, werden an den Stand-by-Server für das Segment transferiert.
-
Netzwerk-Interface Level - die IP-Adresse des ausgefallenen Netzwerk-Interfaces wird auf ein Stand-by-Interface transferiert.
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:
-
Anzahl Kopien größer Minimum: Original ist schreib- und lesbar.
-
Fehlt ein Original, sind die Kopien so lange "nur-lesbar", bis eine neue Vorlage verfügbar ist und die Zahl der Kopien größer ist als das Minimum.
-
Ist die Anzahl der Kopien geringer als das Minimum, ist das Original "nur-lesbar", bis die Zahl der Kopien wieder das Minimum erreicht hat.
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.
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)