Speichersoftware: IPStor 6:
Network-Computing-Test: Storage-Software IPStor 6 von Falconstor

von Andreas Stolzenberger (ast@nwc.de), bre

Share
20.11.2008

Die Speichersoftware von Falconstor virtualisiert nicht nur LUNs. Spiegel, Repliken und ein CDP-Modul (Continous Data Protection) sorgen für die Datensicherheit.

Viele teure FC-Speichersysteme liefern neben roher Kapazität diverse Management-Tools. Dazu zählen synchrone und asynchrone LUN-Spiegel, Snapshots und Features wie Thin- Provisioning.

Allerdings implementiert jeder Hersteller eigene Features, ohne zu anderen Geräten kompatibel zu arbeiten und günstige Speichersysteme lassen etliche Dienste vermissen.

Je nach Einsatzart empfiehlt es sich daher, die Speichermanagement-Features an eine externe Appliance auszulagern. Von Falconstor [1]stammt die Storage-Management-Lösung »IP-Stor« in der Version 6. Das Programm virtualisiert Speicherressourcen im FC- und iSCSI-SAN. Es beherrscht Snapshots, Spiegelung, Replikation und Thin-Provisioning.

Die Software setzt auf einem 64-Bit-Redhat [2]- oder Centos [3]-5-Server auf. Für den FC-Target-Betrieb benötigt Falconstor 2- oder 4-GBit/s-Adapter von Qlogic [4]. Das Installationsprogramm entfernt die mit Linux gelieferten FC-Treiber und setzt an deren Stelle herstellereigene ein, welche den Target-Mode beherrschen.

Installation schnell erledigt

Die Installation beansprucht lediglich ein paar Minuten. Anschließend kann der Verwalter das System über ein Java-Gui von seiner Arbeitsstation aus administrieren.

Die Installation erfasst alle verfügbaren Speicherquellen. Das können lokale SCSI-Laufwerke und -Arrays als auch FC-LUNs sein. Da Redhat/Centos-Linux einen iSCSI-Initiator mitbringt, lassen sich auch iSCSI-LUNs verwenden.

Der Administrator reserviert die gewünschten Ressourcen und weist sie Speicherpools zu. Innerhalb dieser Pools entstehen dann virtuelle LUNs, auf welche die verbundenen Server via iSCSI- oder FC-SAN zugreifen. Auf Wunsch setzt IP-Stor dabei Thin-Provisioning ein.

Anders als bei den Konkurrenzlösungen San-Melody und San-Symphony von Datacore [5]gibt es bei Falconstor keinen RAM-Cache. Die Appliance reicht die Speicheranfragen direkt an die Laufwerke des Pools durch. Der Hersteller will so eine höhere Sicherheit erreichen, weil es bei Ausfällen des IP-Stor-Servers so zu minimalen Datenverlusten kommt. Somit arbeitet die Lösung in etwa auf dem Geschwindigkeitsniveau des dahintergeschalteten Storage-Systems.

Um die Zugriffe dennoch ein wenig zu beschleunigen, offeriert IP-Stor eine Funktion namens »Safe-Cache«. Dabei kann der Verwalter einen Teil einer sehr schnellen Platte als Cache-Disk deklarieren und einer LUN zuweisen, um Schreibzugriffe zu beschleunigen.

Zudem gibt es ein »Hot-Zone«-Feature. Es legt einen Read-Ahead-Cache auf einer schnellen Disk an oder verbessert die Geschwindigkeit sequentieller Zugriffe.

Zudem offeriert IP-Stor diverse Sicherheitsfunktionen. Ein »Mirror« spiegelt eine LUN in einen anderen Backend-Pool oder auf eine andere physische Disk des Backend-Pools.

Die Replikation gleicht die Blöcke einer LUN asynchron mit einem zweiten IP-Stor-Server ab. Damit lassen sich Plattendaten auch über große Entfernungen und vergleichsweise langsame Leitungen sichern. Große Unternehmen können LUNs von Filialen mit Hilfe dieser Technik in das zentrale Rechenzentrum spiegeln. Zwei IP-Stor-Appliances arbeiten als Failover-Verband und sorgen für Redundanz.

Die Basis aller weiterer Sicherheitsfeatures ist die Snapshot-Funktion. Diese kann der Administrator manuell erstellen oder zu vorgegebenen Zeiten von einem Scheduler anlegen lassen.

Das CDP-Feature (Continuous-Data-Protection) erstellt in vorgegebenen Intervallen solche »Time-Marks«. Eine Policy legt fest, wie viele Time-Marks das System aufbewahrt, bevor es die ältesten löscht. Zu jedem Time-Mark kann der Verwalter einen Time-View erstellen und diesen als LUN einem SAN-Client zuweisen.

Auch kann der Administrator ein direktes Abbild eines Time-Marks auf ein Blockdevice schreiben (per dd). So lassen sich Image-Backups wichtiger LUNs beispielsweise auf Tape auslagern. Etliche Speicher-Features lassen sich miteinander kombinieren. Nicht nur LUNs dürfen einen Mirror besitzen, auch Snapshots lassen sich spiegeln.

Testumgebung

Im Labor setzt Network Computing IP-Stor auf zwei Thomas-Krenn-Servern mit je einem Pentium-D-Prozessor 3,2 GHz, 2 GByte RAM und einem Dual-Port 2-GBit/s-FC-Host-Bus-Adapter 2342 von Qlogic ein. Die interne S-ATA-Platte nimmt lediglich das Betriebssystem auf.

Ein Port des Qlogic-2342 dient als Initiator und spricht die Disk-Subsysteme im Backend an. Dort arbeiten ein Maxdata SU-1202 (siehe Test in NetworkComputing 6/2008 [6] ) sowie ein Open-E-DSS-Speichersubsystem Marke Eigenbau.

Der zweite Qlogic-Port arbeitet als Target, über den die SAN-Clients ihre virtualisierten LUNs erhalten. Zudem betreibt der Rechner auf einem der zwei 1-GBit/s-LAN-Interfaces ein iSCSI-Target. Diesen Port nutzen Testmaschinen ohne FC-Anbindung.

Da die 1-HE-Server mit nur zwei PCI-X-Slots keinen Platz für einen zweiten FC-Adapter lassen, welcher als Standby-Port für das Failover-Feature vonnöten wäre, verzichtet Network Computing auf den Test des Redundanzmechanismus.

Nach dem zügigen Setup spielt Network Computing einige vom Hersteller mitgelieferte Patches ein und startet die Systeme neu.

Die Verwaltung der IP-Stor-Appliance erfolgt über ein Java-GUI. Das Programm offeriert viel Übersicht, beansprucht jedoch viel Raum auf dem Schirm. Immer wieder finden sich kleinere Fehler, wie falsche Maßangaben für GByte und MByte, die aber den Betrieb nicht stören.

IP-Stor erhält Zugriff zu den zuvor konfigurierten FC-LUNs. Zudem richtet das Laborteam den iSCSI-Initiator ein. Im Labor arbeiten zwei iSCSI-Speichersysteme von Equallogic. Von diesen erhalten die IP-Stor-Rechner LUNs im Backend. Somit kann IP-Stor auch als iSCSI-to-iSCSI- oder gar FC-to-iSCSI-Virtualisierer arbeiten. Im Test arbeitet die iSCSI-LUN des Backends als Snapshot-Speicher.

Hohe Performance

Simple Performancetests im 2-GBit/s-FC-SAN bescheinigen der Storage-Appliance sehr geringe Verluste. Der direkte Zugriff auf das Maxdata SU1202 liefert nahezu die selben Durchsatzwerte wie bei einem zwischengeschalteten IP-Stor (zwischen 180 und 200 MByte/s). Lediglich bei LUNs mit Thin-Provisioning fallen leichte Aussetzer auf, wenn die Appliance Blöcke nachlegen muss.

Die CDP-Option über zeitgesteuerte Snapshots ist zwar schnell konfiguriert, arbeitet jedoch in der Rohform nicht ohne Fehler. Im Test kann Network Computing einzelne Time-Views nicht auf ein Testsystem mounten.

Wie bei so vielen anderen Speichersystemen spricht sich der Snapshot-Mechanismus zunächst nicht mit dem Dateisystem des Clients ab. Befindet sich das Dateisystem zum Zeitpunkt des Snapshots in einem inkonsistenten Zustand, ist der Snapshot ganz oder teilweise unbrauchbar.

Falconstor liefert daher passende Client-Agenten mit, die sich nicht nur mit dem Betriebs- und Dateisystem verständigen, sondern sich auch gleich in Applikationen wie Oracle oder Exchange integrieren. Somit kann der Anwender die Snapshots von der Applikation aus anstoßen.

Diese wählt hierfür einen Zeitpunkt aus, in dem sich die Programmdaten und Dateisysteme in einem eindeutigen, konsistenten Zustand befinden und alle Caches geleert wurden.

Fazit

IP-Stor liefert eine Fülle mächtiger Storage-Funktionen für Ausfallsicherheit und Speichermanagement. Eine passende Appliance verwandelt jedes noch so simple Speichersystem in ein funktionsreiches Storage-Subsystem. Neuerdings vertreibt H3C [7] komplette Midrange-Speichersysteme mit IP-Stor als Betriebssystem.

Das Mangement-GUI offeriert eine übersichtliche Baumdarstellung, versteckt einzelne Dienste jedoch an unerwarteten Positionen im Baum.

[1] http://www.falconstor.com
[2] http://www.redhat.com
[3] http://www.centos.org
[4] http://www.qlogic.com
[5] http://www.datacore.com
[6] network-computing-test-fibre-channel-storage-systeme-fuer-einsteiger/
[7] http://www.h3c.com

Verwandte Artikel