Im Vergleich: Compellent vs. 3Par
Dell und Hewlett-Packard haben jeweils ein voll virtualisiertes Speichersystem im Portfolio. Aber was genau steckt im »Inserv« und was kann das »Storage Center«? Die Redaktion von virtualisierungs-guide.de hat beide Ansätze gegenübergestellt.
Von Max Lessel
In einer spektakulären Bieterschlacht (siehe Blog auf speicherguide.de) hatten sich Hewlett-Packard und Dell um den Speicherhersteller 3PAR gezankt. Gewonnen hatte HP, wenn auch zu einem hohen Preis von 2,4 Milliarden US-Dollar. Kurz darauf übernahm Dell dann Compellent (speicherguide.de berichtete). Was macht diese beiden Speichersysteme nun so besonders, dass HP seine eigene »EVA«-Architektur ins Abseits stellt und Dell seinem langjährigen Partner EMC die Freundschaft kündigt?
Beide Systeme sind virtualisierte SAN-Arrays, doch diese Klassifikation lässt sich sehr weit dehnen. Ein jedes SAN-Speichersystem ist irgendwie virtualisierend, schließlich erstellt es virtuelle LUNs aus großen RAID-Arrays. Die Architekturen von 3Par und Compellent sind in diesem Punkt jedoch so weit voraus, dass die »klassischen« RAID-Grüppchen von EMC und LSI dagegen wie eine zusammengewürfelte Handvoll USB-Sticks aussehen. Beide Systeme arbeiten mit Frontends, die 1- und 10-GBit/s-iSCSI sowie 8-Gbit/s-FC offerieren.
3Par »Inserv«
Ein 3Par-Speichersystem besteht, wie ein klassisches SAN-Array, aus Controllern und per FC angebundenen Disk-Shelves. Die kleinere »F-Serie« setzt dabei noch auf 19-Zoll-Standard-Komponenten wie handelsübliche Rack-Shelves mit 16 Disks. Die große »T-Serie« setzt spezielle Disk-Container ein. Jeweils vier Disks passen auf ein Tray und deren zehn stecken in einem Disk-Shelf. Die F-Serie unterstützt zwei bis vier, die T-Serie bis zu acht Controller. Alle Controller kommunizieren über ein passives Backplane miteinander, jeweils zwei Controller arbeiten als gespiegeltes Pärchen. Eine Art Master-Controller gibt es hier nicht und die LUNs »gehören« auch nicht einem speziellen Controller, der sie nur im Fehlerfalle abgibt. Als Cluster kann jeder Controller jederzeit mit jeder LUN arbeiten.
Für die Plattenverwaltung hat sich 3Par etwas Besonderes einfallen lassen, was vor allem die Geschwindigkeit des Arrays antreibt. Das System verwaltet Volume-Groups, innerhalb derer dann die LUNs für die angebundenen Initiatoren stehen. Die Volume-Group gibt den RAID-Level vor, der bei 3Par entweder auf 10, 50 oder 60 basiert. Allerdings erzeugt 3Par keine RAID-Gruppen mit kompletten Disks, sondern nutzt so genannte »Chunklets«.
Jede Disk zerteilt das System in Scheibchen zu 256 MByte. Einen Teil dieser Chunklets reserviert 3Par als Spare. Die eigentliche RAID-Gruppe erstreckt sich über tausende Chunklets auf verschiedenen Disks und Shelves, wobei die Parity immer in kleineren Gruppen bleibt. Bei RAID 5 beispielsweise kommen auf drei bis acht Daten-Chunklets jeweils ein Parity-Chunklet. Der Verwalter kann parallel Gruppen mit RAID 10, 50 und RAID 60 anlegen, welche sich über dieselben Disks und Trays verteilen. Durch das so genannte »Wide Striping« erreicht 3Par eine enorm hohe Geschwindigkeit, da sich jede Volume-Group über alle verfügbaren Spindeln einer Plattenklasse erstreckt. Die Parity-Verteilung ist dabei so gewählt, dass selbst ein komplettes Shelf mit 40 Platten ohne Datenverlust ausfallen kann.
Auf Basis der so erstellten RAID-Gruppen kann der Administrator nun seine LUNs erstellen und den Hosts zuweisen. 3Par offeriert dafür natürlich alle »üblichen Verdächtigen« der High-Level-SAN-Features wie Thin-Provisioning (mit Re-Thinning), Snapshots, Replikation und was man sonst so benötigt. Auch liegen die LUNs nicht starr auf einer RAID-Gruppe. Mittels Auto-Tiering verteilt das System die LUNs auf mehrere Gruppen mit verschiedenen Disk-Typen. Der heiße Bereich einer Platte kann dabei auf SAS- oder SSD-Chunklets, die weniger oft verwendeten Bereiche auch auf SATA-Chunklets liegen.
Als besonderes Extra liefert 3Par virtualisierte Storage-Arrays. Der Hauptverwalter kann das System in viele kleine virtuelle RAIDs zerlegen und deren Ressourcen lokalen Administratoren zuweisen. Diese sehen ihr eigenes begrenztes Speichersystem, welches der Hauptverwalter in Sachen Kapazität und Geschwindigkeit limitieren kann.
Pro 3Par
Das System ist auf Grund der Architektur enorm schnell. Die Controller können in der T-Serie bis zu 96 GByte Daten-Cache aufweisen und die IOPs verteilen sich auf alle Platten einer Geschwindigkeitsklasse. Virtuelle SANs erlauben das Accounting der Ressourcen auf verschiedene angebundene Unternehmen und Abteilungen. 3Par bezeichnet das als »Utility Computing« und zielt damit besonders auf große Cloud-Lösungen.
Contra 3Par
Die Architektur von 3Par spielt ihr Können erst in relativ großen Umgebungen mit 160 Festplatten und mehr aus. Den Preis der hohen Verfügbarkeit zahlt der Verwalter mit einer geringen Nettokapazität. Je nach Anzahl der Disks und Shelves bleiben lediglich zwischen 40 und 60 Prozent vom Brutto übrig.
Compellent »Storage Center«
Das Compellent »Storage Center« verfolgt einen vollständig modularen Ansatz. Es gibt Controller und Shelves, wobei letztere entweder FC-, SAS- oder SATA-Laufwerke beherbergen. Die Shelves enthalten zwölf, 16 oder 24 Platten - je nach Typ und Formfaktor. Als Backplane kann der Verwalter zwischen FC und SAS wählen, aber auch beide gemischt betreiben. Das Storage-Center unterscheidet bis zu drei Geschwindigkeitsklassen: Tier 1 bis 3. Das langsame »T3« belegen in der Regel SATA-Laufwerke, das schnelle »T1« entweder 15k-SAS-Platten oder SSDs. Das Grundkonzept von Compellent ist, möglichst nur die aktiven Datenbereiche auf teuren schnellen Laufwerken zu lagern und den wenig aktiven Rest auf den günstigen und großen SATA-Platten zu speichern. Laut Hersteller kann ein Storage-Center bis zu 1.000 Platten beherbergen und acht Controller betreiben. Einen Mesh-Cluster wie bei 3Par beherrscht Compellent nicht.
Ein klassisches Disk-RAID gibt es auch bei Compellent nicht mehr. Das Storage Center zerlegt alle Daten in 2-KByte-Blöcke und verteilt diese mit einem blockbasierten RAID-Algorithmus über alle Disks eines Tiers. Als RAID-Level stehen 10, 5-5, 5-9, 6-6 und 6-10 zur Verfügung. Die zweite Zahl bei RAID 5 und 6 gibt dabei die Zahl der Blöcke pro Stripe an: Ein RAID-6-10-Verband sichert folglich pro acht 2k-Blöcke zwei Parity-Blöcke. Durch die Blockorientierung kann ein einzelnes Tier gemischt jeden RAID-Level enthalten.
Zu jeder LUN gibt es eine so genannte Storage-Policy. Darin hinterlegt der Verwalter, welche RAID-Level die LUNs in welcher Reihenfolge belegen. Üblicherweise beginnt eine LUN mit RAID 10 auf Tier 1 und endet mit RAID 5-9 oder 6-10 auf SATA. Die Logik des Storage Centers kümmert sich dabei darum, dass die selten verwendeten Blöcke einer LUN über die Zeit auf das langsame Tier mit effizienterem RAID-Algorithmus wandern, während die aktiven Daten auf schnellen Laufwerken vorgehalten werden. Der Verwalter kann die Policy einzelner LUNs oder von Gruppen jederzeit ändern.
Auch das Compellent Storage Center basiert auf Thin-Provisioning und liefert alle üblichen SAN-Funktionen von Snapshots über Klonen und Spiegel bis hin zum dynamischen Provisioning (Re-Thinning), das freigewordene Blöcke aus den LUNs entfernt.
Pro Compellent
Das Compellent Storage Center ist modular erweiterbar. Eine kleine Konfiguration kann schon mit einem Controller und 24 Disks in zwei Tiers beginnen. Im Laufe der Zeit kann das System ohne Datenverlust auf 1.000 Disks mit acht Controllern anwachsen. Einen kompletten Systemtausch gibt es nicht, da sich jede Komponente im laufenden Betrieb tauschen lässt. Die Compellent-Architektur verwaltet die Plattenkapazitäten sehr effizient, wodurch der Anwender zwischen 50 und 80 Prozent Netto vom Brutto erhält.
Contra Compellent
Aktuell kann Compellent keinen Controller-Cluster für größere Systeme vorweisen. Die aktuelle Software-Version basiert auf 32 Bit und verwaltet daher nur vier GByte Cache pro Controller, wovon nur 512 MByte als Write-Cache arbeiten. Eine 64-Bit-Version der Firmware ist erst gegen Ende 2011 verfügbar.
3Par contra Compellent
Ab 160 Platten und vier Controllern kann die 3Par-Architektur voll punkten. Hier kommt die enorme Performance des Controller-Clusters ebenso zum Tragen wie die Funktionen für virtualisierte Subsysteme mit eigener Administration.