Test: IBM-XIV-Storage-System
Speichersystem mit SATA-Platten
Das XIV-Speichersystem von IBM verwendet eine neuartige Architektur auf der Basis von SATA-Platten, die eine einfache Verwaltung und eine hohe Leistungsfähigkeit garantieren soll. Das System verteilt die auf ein logisches Volume geschriebenen Datenblöcke automatisch über alle Festplatten und erzielt dadurch eine hohe Performance sowie eine schnelle Datenwiederherstellung beim Ausfall einer Disk.Mit dem israelischen Startup-Unternehmen XIV hat IBM vor drei Jahren eine neuartige Speichersystemarchitektur zugekauft, die sich deutlich von traditionellen Disk Arrays unterscheidet. Das XIV-System verwendet SATA-II-Platten, die mit 7.200 Umdrehungen pro Minute laufen. Ein intelligenter Algorithmus verteilt die Daten auf alle Festplatten des Systems, wodurch sich trotz der vergleichsweise langsamen Platten eine sehr hohe I/O-Performance erzielen lässt. Laut IBM liegt die theoretische Grenze bei über 100.000 IOPS (Input/Output Operations Per Second). In der Praxis sollen mit einem voll ausgebautem System Maximalwerte von ungefähr 50.000 IOPS erreichbar sein. Für den Storage-Administrator vereinfacht die neue Architektur das Leben deutlich. Er muss sich über die Größen von RAID-Gruppen und das richtige RAID-Level keine Gedanken mehr machen, weil das XIV-System alle Daten automatisch auf alle Platten verteilt und dabei eine dem RAID-Level 10 vergleichbare Redundanz herstellt. Das XIV-System setzt sich aus so genannten Data-Modulen und "Interface"-Modulen zusammen. Jedes Datenmodul stellt zwölf Festplatten bereit. Die Interface-Module sind mit ebenso vielen Disks ausgestattet, enthalten aber zusätzlich die Schnittstellenkarten mit den Fibre-Channel-(FC-) und iSCSI-Ports für die Host-Anbindung. Die XIV-Einstiegskonfiguration mit drei Data- und drei Interface-Modulen unterstützt nur FC. iSCSI-Support ist ab einem System mit neun Modulen möglich. Die zwölf SATA-Festplatten der Module bieten jeweils eine Kapazität von 1 oder 2 TByte. Ein Array kann bis zu 15 Module mit insgesamt 180 Platten aufnehmen. Die nutzbare Speicherkapazität beträgt im Maximalausbau 79 TByte beziehungsweise mit 2-TByte-Disks 161 TByte pro Array. Das XIV-System lässt sich mit acht bis 24 FC-Ports (4 GBit/s) und vier bis sechs iSCSI-Ports (1 GBit/s) ausrüsten. Die Data-Module sind mit einer Intel-Quad-Core-CPU bestückt, die Interface-Module verfügen über zwei CPUs. Bei Verwendung von 1-TByte-Platten ist jedes Modul mit 8 GByte RAM ausgestattet, sodass im Vollausbau ein Cache von 120 GByte zur Verfügung steht. Mit 2-TByte-Platten ist doppelt so viel RAM vorhanden. Der bereits erwähnte intelligente Algorithmus, der das Herzstück des XIV-Systems bildet, verteilt die Daten in 1 MByte großen so genannten Partitionen über alle Festplatten des Disk Arrays. Dabei schreibt das System von jeder 1-MByte-Partition automatisch eine redundante Partition auf ein anderes Modul. Aufgrund dieser Redundanz kann ein komplettes Modul ausfallen, ohne dass Daten verloren gehen. Die Partitionstabelle hält das XIV-System sowohl im Hauptspeicher als auch auf den Platten der Module vor. Konfiguration der Testumgebung Der LANline-Test des XIV-Systems erfolgte in IBMs Test-Center in Mainz. Die Testumgebung setzte sich dabei aus zwei XIV-Systemen, einem IBM-Server Xseries 336 mit Windows 2003 und zwei VMware-ESX-Servern zusammen. Der Windows-Server war sowohl per FC als auch per iSCSI mit dem primären XIV-System verbunden, die ESX-Server waren per FC angebunden. Die Verwaltung der XIV-Systeme erfolgt über eine grafische Oberfläche, die übersichtlich gestaltet und einfach zu bedienen ist. Auf der obersten Ebene befindet sich die so genannte "System Group", über die sich mehrere XIV-Arrays von zentraler Stelle aus managen lassen. Im ersten Schritt legt der Administrator einen Storage Pool an und legt fest, ob er einen "regulären" oder einen "Thin Provisioning" Pool erstellen will. Letztere Bezeichnung ist etwas irreführend, weil das Thin Provisioning auch beim regulären Pool immer automatisch im Hintergrund läuft. Der Unterschied ist, dass das XIV-System bei einem regulären Pool die komplette Pool-Größe garantiert zur Verfügung stellt. Mit einem Thin Provisioning Pool hat der Administrator dagegen die Möglichkeit, den Servern mehr Speicher zuzuweisen, als tatsächlich vorhanden ist. Der Parameter "Snapshot Size" legt fest, wie viel Speicherkapazität das System für Snapshots reserviert. Das so genannte "Lock Behaviour" wiederum regelt das Verhalten, wenn ein Pool "vollläuft". Das System kann die Volumes dann entweder in den Read-Only-Modus versetzen oder sämtliche I/O-Operationen stoppen. Die Speicherkapazität reserviert oder allokiert das XIV-System standardmäßig in 17-GByte-Schritten. Jeder dieser Chunks besteht aus 16.000 der 1-MByte-Partitionen. Der Administrator kann für Volumes aber auch andere als die Standardgrößen wählen. Storage Pools lassen sich per Mausklick vergrößern und verkleinern. Zudem ist es möglich, Volumes zwischen Pools zu verschieben, ohne dass das Betriebssystem davon erfährt. Einfache und effiziente Speicherverwaltung Für den LANline-Test legten wir einen Thin Provisioning Pool mit 206 GByte Speicherkapazität an. In diesem Pool erstellten wir anschließend zwei Locical Units mit je 50 GByte Kapazität. Um eine LUN (Logical Unit Number) einem Server zuzuweisen, muss der Administrator zunächst auf dem XIV-System einen neuen Host oder eine neue Host Group anlegen. Letztere erleichtert beispielsweise die Verwaltung von ESX-Clustern, weil sich damit neue LUNs automatisch allen ESX-Servern der jeweiligen Host Group zuordnen lassen. Bevor die zwei neuen LUNs dem Windows-2003-Server per FC-Anbindung zugewiesen wurden, installierten wir auf dem Server den XIV-MPIO-Agenten (Multi-Path I/O), der für die redundante Anbindung über zwei FC-HBAs (Host Bus Adapters) erforderlich ist. Dieses Tool ist im Host Attachment Kit des XIV-Systems enthalten. Es erkennt automatisch alle vom Speichersystem zugewiesenen Volumes und zeigt den aktuellen Status der FC-Pfade an. Anschließend mappten wir die zwei LUNs auf den Windows-Server. Eine der beiden LUNs vergrößerten wir dann über die XIV-Management-Oberfläche von 50 auf 85 GByte und machten den zusätzlichen Speicherplatz auf dem Windows-Server per "diskpart extend"-Befehl nutzbar. Die Verkleinerung von LUNs ist auf dem XIV-System ebenfalls per Mausklick möglich. Das Mappen einer LUN per iSCSI funktionierte im Test ebenfalls ohne Probleme. Um das Zusammenspiel von XIV und VMware zu testen, erstellten wir für die zwei geclusterten ESX-Server eine neue LUN und wiesen diese der Cluster Host Group zu. Die LUN ließ sich anschließend über das VMware Virtual Center als neuer Datastore einbinden. Das XIV-Plugin für VMware fügt dem Virtual Center einen zusätzlichen Reiter hinzu, der unter anderem die LUN, die Größe der Logical Unit und den Datastore auflistet. IBM bietet zudem einen kostenlosen XIV-Agenten für den VMware Site Recovery Manager an, damit sich ein "Site Failover" transparent durchführen lässt. Anschließend testeten wir die Snapshot-Funktion des XIV-Systems, indem wir von einer LUN mit einem virtuellen Windows-Server einen Snapshot erzeugten. Diesen Snapshot mappten wir dann auf den ESX-Cluster und erstellten eine neue virtuelle Maschine, bei der wir den Snapshot als Datastore wählten und die Vdisk des virtuellen Servers selektierten. Danach ließ sich der virtuelle Windows-Server von der Snapshot-Kopie aus starten. Für die sofortige Reaktivierung von gelöschten Blöcken unterstützt das XIV-System eine Funktion namens "Instant Space Reclamation". Auf dem Disk Array läuft permanent ein Hintergrundprozess, der die Konsistenz der Daten überprüft und feststellt, ob ein Volume-Bereich nur noch Nullen enthält. Ist dies der Fall, gibt das System den Speicherplatz wieder frei. Schnelle "Redirect on Write"-Snapshots Das XIV-System verwendet für die Erstellung von Snapshots nicht das traditionelle "Copy on Write"-Verfahren, sondern eine "Redirect on Write"-Technik. Letztere überschreibt die geänderten Blöcke nicht, sondern schreibt die neuen Blöcke zusätzlich an einer anderen Stelle auf Platte. Dieses Verfahren bietet eine sehr gute Performance, insbesondere wenn mehrere Snapshot-Versionen vorrätig sein müssen. Bei einer Datenänderung ist immer nur ein Schreibvorgang für die neuen Blöcke erforderlich, während bei Copy on Write die Änderung in jeder Snapshot-Version durchzuführen wäre. Das XIV-System unterstützt pro Volume mehrere tausend Snapshots. Die für Snapshots nutzbare Speicherkapazität legt der Administrator im Voraus fest. Er kann zwischen "Thick" und "Thin" Snapshots wählen. Ein eigenes Volume ist für die Snapshots nicht erforderlich. Die 1-MByte-Partitionen eines Snapshots werden immer innerhalb desselben Moduls erzeugt, sodass eine hohe Verarbeitungsgeschwindigkeit sichergestellt ist. Im LANline-Test erstellten wir mehrere Snapshots. Dies dauerte jeweils nur wenige Millisekunden, da das System keine Daten kopiert, sondern nur die Pointer setzt. Auch der Restore der Snapshots erfolgte in Sekundenbruchteilen. Er kann optional aus dem Snapshot auch ein Duplikat im Thin-Format oder eine vollständige Kopie des Volumes erstellen, was zum Beispiel für Testzwecke oder für die Datensicherung nützlich ist. Das XIV-System bietet über Microsoft VSS (Virtual Shadow Copy Service) auch applikationskonsistente Snapshot-Unterstützung für MS Exchange, MS SQL, Oracle, DB2 und SAP. Mit so genannten "Consistency Groups" ist es zudem möglich, Snapshots von unterschiedlichen Servern in einer bestimmten Reihenfolge zu erstellen, um die Konsistenz von kritischen Anwendungen wie zum Beispiel Datenbanken sicherzustellen. Hochverfügbare Systemarchitektur Um eine hohe Verfügbarkeit zu gewährleisten, sind alle Komponenten des XIV-Systems redundant ausgelegt. Die Server sind in der Regel über zwei HBAs redundant mit dem Speichersystem verbunden. Der Cluster Support umfasst IBM Power-HA, Symantec Veritas Cluster Server, Microsoft Cluster Service sowie VMware Site Recovery Manager - jeweils inklusive Geo-Cluster-Ausführung. Um die Redundanz der Speichersystemanbindung zu testen, zogen wir an dem Windows-2003-Server von einem HBA das FC-Kabel ab, während der Server ein Video abspielte, das auf dem XIV-System gespeichert war. Es gab eine kurze Unterbrechung von etwa fünf Sekunden, bis der Windows-MPIO-Treiber den Pfadverlust erkannt hatte. Dann lief das Video von selbst weiter. Die Wiederherstellungsfähigkeiten des XIV-Systems testeten wir mit mehreren Ausfallszenarien. Zunächst entfernten wir eine Festplatte aus dem System, das daraufhin automatisch den Rebuild der betroffenen Daten gestartet hat. XIV benötigt keine dedizierten Hot-Spare-Platten, sondern reserviert im Gesamtsystem für Rebuilds eine Spare-Kapazität, die 15 Platten entspricht. Dadurch kann das System den gleichzeitigen Ausfall von einem kompletten Modul und drei weiteren Platten kompensieren. Die redundanten Informationen werden beim Rebuild wieder über alle noch verbliebenen Platten des Gesamtsystems verteilt. Dadurch geht die Wiederherstellung der redundanten Datenpartitionen sehr schnell vonstatten. Im LANline-Test ließ sich die Festplatte, auf der 750 GByte Daten gespeichert waren, innerhalb von sechs Minuten und 15 Sekunden wiederherstellen. Beim nächsten Test entfernten wir zwei Platten gleichzeitig aus demselben Modul. Der Rebuild von 1,5 TByte Daten dauerte 7,5 Minuten. Die Wiederherstellung der Daten von zwei Festplatten, die gleichzeitig aus zwei unterschiedlichen Modulen entfernt wurden, benötigte etwa acht Minuten. Zum Abschluss schalteten wir ein komplettes Modul aus. Der Rebuild der zwölf Festplatten mit etwa 9 TByte Daten hat 36 Minuten in Anspruch genommen. Für den Test der Spiegelungsfunktion des XIV-Systems legten wir auf dem sekundären XIV-Array einen neuen Storage Pool an. Anschließend richteten wir für drei Volumes den Spiegel ein, indem wir auf dem primären System den Haken bei "Create Slave" setzten und den Storage-Pool des sekundären XIV-Systems als Ziel angaben. Die Management-Software erstellte daraufhin auf dem zweiten System automatisch neue LUNs für die gespiegelten Volumes. Sobald dies erfolgt ist, lässt sich die Synchronisation starten. Um die Spiegelungsrichtung umzudrehen, genügt ein Mausklick auf "Switch Roles". Eine asynchrone Replikation zwischen zwei XIV-Systemen unterstützt die Lösung ebenfalls. Integrierte Datenmigration Mithilfe der integrierten Migrationsfunktion lassen sich Daten von Altsystemen im Hintergrund auf das XIV-Array übertragen. Dieses übernimmt für die Server eine Proxy-Funktion und stellt sich auf dem Altsystem als Linux-Server dar. Es ist lediglich eine kurze Down-Zeit erforderlich, um die HBAs auf das neue Speichersystem "umzuhängen". Anschließend greifen die Server über das XIV-System auf die Daten des Altsystems zu. Bei der Migration ist es auch möglich, Thick Volumes in Thin Volumes umzuwandeln. Um die Migrationsfunktion zu testen, legten wir auf dem XIV-System einen Data Pool an und wählten einen "Migration Pool" aus. Dabei ist zu entscheiden, ob neue Daten zunächst noch auf das Altsystem geschrieben oder gleich auf dem XIV-Array gespeichert werden, wobei Letzteres die bevorzugte Methode ist. Anschließend migrierten wir drei LUNs von einem Altsystem auf das XIV-Array. Die XIV-Management-Software legt die neuen Volumes automatisch mit derselben Größe an wie die alten LUNs. Für die Verwaltung der XIV-Benutzer unterstützt das System eine LDAP-Integration. Alle über die grafische Oberfläche ausgeführten Aktionen zeichnet zudem ein Javascript-Generator auf. Mithilfe dieser Befehle lassen sich sehr einfach Skripte aufbauen, um die XIV-Funktionen über das Command-Line-Interface auszuführen. Die Reportfunktion des Systems wiederum liefert Statistiken zur Auslastung der Interfaces und der Volumes sowie zu zahlreichen weiteren Parametern. Die Daten lassen sich für ein Accounting im CSV-Format exportieren und können über einen Zeitraum von bis zu einem Jahr kontinuierlich erfasst werden. Die Performance-Überwachung in Echtzeit ist mit dem Tool XIV-Top möglich. Bei Fehlfunktionen kann das System den Administrator per E?Mail, SNMP oder SMS benachrichtigen. Zudem zählt eine "Call Home"-Funktion zum Standardlieferumfang, die schwerwiegende Fehler automatisch an den IBM-Support meldet. Fazit Das XIV-System ist im Vergleich zu traditionellen Disk Arrays sehr einfach zu verwalten. Zum einen muss sich der Administrator keine Gedanken mehr über die Einrichtung von RAID-Gruppen und RAID-Leveln machen, weil das System die Daten der logischen Volumes automatisch über alle Platten verteilt. Zum anderen ist die grafische Oberfläche übersichtlich strukturiert und einfach zu bedienen. Für ein SATA-System erreicht das XIV-Array eine hohe Performance und bietet bei Plattenausfällen sehr kurze Datenwiederherstellungszeiten. Funktionen für ein effizientes Speicher-Management wie leistungsfähige Snapshots, Thin Provisioning und Thin Reclamation runden den positiven Gesamteindruck ab. Für kleinere Unternehmen könnte sich allerdings der relativ hohe Einstiegspreis als Hürde erweisen. Der IBM-Listenpreis liegt bei etwa 500.000 Euro. Info: IBM Deutschland Tel.: 0800/7843977 Web: www.ibm.com/systems/de/storage/disk/xiv
Lesen Sie mehr zum Thema
