Auf unseren Technologietagen war es zu erleben: Das RAID-System SATABeast der Firma Nexsan.
Die Nexsan Corporation ist eine amerikanische Firma mit Hauptsitz in Los Angeles und wurde 1999 gegründet. Niederlassungen gibt es auch in Europa (U.K.), Canada und China. Im deutschen Vertrieb ist Cristie Data Products eine gute Adresse. Cristie hat als Teilnehmer an unseren Technologietagen das System auch zur Verfügung gestellt.
Bei dem SATABeast handelt es sich um ein active/active RAID-System, das sowohl iSCSI als auch FibreChannel beherrscht. Jeder Controller hat bis zu 2 GB Cache und verfügt über 2 Ports mit 4Gb. Bei unserem Testsystem waren dann auch 2 Controller (Vollausbau) mit je 2GB Cache eingebaut.
Das Besondere an diesem System ist neben der AutoMAID-Technologie (Details dazu s. u.) die enorme Packungsdichte. So finden 42 Standard 3,5" Festplatten in nur 4 Höheneinheiten Platz. Es werden ausschließlich SATA-Platten verbaut, eine Größenbegrenzung für die einzubauenden Platten gibt Nexsan nicht an. Im Testsystem waren 42 Hitachi Ultrastar (7200 rpm) Festplatten mit je 1 TB Kapazität verbaut.
Kurz die wichtigsten Merkmale des Nexsan SATABeast:
Welchen Eindruck das System sonst hinterlassen hat, nachfolgend in aller Kürze:
Für den Einbau des SATABeasts werden, wie bereits erwähnt, 4 Höheneinheiten im Rack benötigt. Grundsätzlich macht das Metallgehäuse einen sehr soliden Eindruck. Leicht abbrechende Plastikteile (Blenden, Türen etc.) sind nicht aufgefallen. Die Plastikfrontblende mit ihrem etwas futuristischen Aussehen ist sicher Geschmackssache. Dort eingebaut sind drei nach innen pustende 12cm-Lüfter die zwar ordentlich Lärm (jedoch ohne anstrengende Obertöne) machen, aber bei der Anzahl von Platten natürlich notwendig sind. Genau hinter der Frontblende sind dann auch die Slots für die Platten zu finden.
Die Frontblende ist im Übrigen nach unten klappbar (gesichert durch eine kleine Gas-Feder). Vorher sind jedoch zwei Schrauben (hinter den Ohren befindlich) zu lösen.
Die übersichtliche Rückseite bietet folgende Schnittstellen bzw. Module:
Man kann gut erkennen, dass sämtliche über die Rückseite zugänglichen Komponenten ohne Werkzeuge ausgetauscht werden können.
Zum Austausch von Platten muss die obere Abdeckung des Gehäuses entfernt werden, was leider nicht ohne Werkzeug möglich ist. Hinter den Rack-Ohren sitzt auf jeder Seite eine Kreuzschlitz-Schraube, die gelöst werden muss. Erst dann kann die Frontblende heruntergeklappt werden. Es wäre super, wenn man anstelle der Kreuzschlitzschrauben eine andere Lösung fände, zumal dies die einzigen Schrauben am SATABeast sind, die mit Werkzeug gelöst werden müssen.
Nach Lösen der Schrauben muss das obere Abdeckblech nach vorn gezogen werden. Dies ging bei unserer Testmaschine sehr schwer, meistens waren 2 Personen notwendig und man hat stets ein wenig Sorge, sich verletzen zu können. Hier sollte dringend nachgebessert werden.
Für das Wechseln von Platten hat Nexsan ein Spezial-Werkzeug zum Herausziehen beigelegt. Da die Platten mit dazu passenden Schienen ausgestattet sind, funktionert das sehr gut. Alle anderen Komponenten (ausser den Platten) lassen sich - wie mittlerweile bei solchen Systemen üblich - ohne Werkzeug tauschen (RAID-Controller, Netzteil und
Für die Administration des SATABeasts hat Nexsan ein unauffälliges, funktionales Web-Interface bereitgestellt. Neben einer Übersicht, in der eventuelle Ausfälle sofort erkannt werden, ist es natürlich möglich, RAID-Sets zu bauen (übrigens inkl. Online-Modus), Volumes/LUNs anzulegen bzw. zu löschen usw.
Alle Parameter des RAID-Systems können bequem geändert bzw. administriert werden. Allerdings kann das Anlegen vieler LUNs schon langwierig sein, was wiederum zu Fehlern einlädt. Gleiches gilt für das Volume-Mapping.
Dessen ungeachtet tut das Web-Interface, was es soll. Es gibt deutlich schlechtere Lösungen.
Über die serielle Schnittstelle bietet Nexsan so etwas wie eine ASCII-Variante des Web-Interfaces an, das mittels Tastatureingaben bedient wird (siehe Bild bei Fazit). Ein einfaches CLI wäre wahrscheinlich praktischer gewesen, insbesondere für Massenverarbeitung. Bei der Verwendung als Backup-RAID im OSL Storage Cluster tun es aber auch wenige LUNs - insgesamt also ein zu verschmerzender Nachteil.
Es können maximal 42 SATA Platten eingebaut werden. Jeder dieser Platten wird einzeln über einen eigenen Kanal angesprochen. Zudem können laut Nexsan alle am Markt vorhandenen SATA-Platten verwendet werden. Soll die AutoMAID-Technologie verwendet werden, ergeben sich jedoch Einschränkungen bei der Wahl der Platten. Nach aktuellem Kenntnisstand können nur Hitachi Platten von allen drei MAID-Stufen profitieren. Doch dazu weiter unten mehr.
In unserem Testsystem wurden 42 Hitachi Ultrastar Platten verwendet (Kapazität 1 TB) und von Nexsan mit 4 RAID-Sets und 2 Hot-Spares vorkonfiguriert.
Für unsere Tests haben wir zusätzlich 8 RAID-Sets (RAID-Level 5) mit je 5 Platten und 32 kB Stripe-Size gebaut. Des weiteren testeten wir eine Konfiguration aus 3 RAID-5-Sets mit je 13 Platten und 128 kB Stripe-Size. Das initiale Aufsetzen der RAID-Sets dauerte etwa 40 Stunden.
Das Nexsan SATABeast unterstützt diverse Controller- bzw. Failover-Modi, die hier nur kurz vorgestellt werden sollen.
Die gute Nachricht für OSL Storage Cluster-Anwender: Dort wo eine hostbasierte Multipfadlösung benötigt wird,
kann natürlich auf den im Basispaket integrierten leistungsfähigen Multipfad zurückgegriffen werden,
der mit FC-Controllern und Host-IO-Stack eigener Wahl betrieben werden kann (Solaris 7-10).
Die Integration der LUNs in Solaris verlief völlig problemlos. Der Host war dabei sowohl direkt als auch via Switches (natürlich nicht gleichzeitig) angeschlossen.
Die Volumes sind für den Storage Cluster sofort sichtbar (aber natürlich noch "foreign"):
root@big-5 # devtab -lvvv
Running with clustername: beast
Building device table: ok
/dev/rdsk/c3t5000402001FC42E0d1s1 | C1_P1 | unknown | | NEXSAN | SATABeast | Gh61 | 61F1337C42E0 | 61F1337C42E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c2t5000402301FC42E0d2s1 | C0_P0 | unknown | | NEXSAN | SATABeast | Gh61 | 61F1334642E0 | 61F1334642E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c3t5000402001FC42E0d3s1 | C1_P1 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13CA142E0 | 61F13CA142E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c2t5000402301FC42E0d4s1 | C0_P0 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13C9A42E0 | 61F13C9A42E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c3t5000402001FC42E0d5s1 | C1_P1 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13CF742E0 | 61F13CF742E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c2t5000402301FC42E0d6s1 | C0_P0 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13CD242E0 | 61F13CD242E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c3t5000402001FC42E0d7s1 | C1_P1 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13CCE42E0 | 61F13CCE42E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c2t5000402301FC42E0d8s1 | C0_P0 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13C2A42E0 | 61F13C2A42E00000000402FC000142E0 | 1953124 MB | foreign | pi |
/dev/rdsk/c3t5000402001FC42E0d9s1 | C1_P1 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13C0D42E0 | 61F13C0D42E00000000402FC000142E0 | 976562 MB | foreign | pi |
/dev/rdsk/c2t5000402301FC42E0d0s1 | C0_P0 | unknown | | NEXSAN | SATABeast | Gh61 | 61F13DCD42E0 | 61F13DCD42E00000000402FC000142E0 | 1907 MB | foreign | pi |
Ein Eintrag in die Datei "/etc/dvsc/scancfg" ist nicht notwendig, das SATABeast wird automatisch vom OSL Storage Cluster erkannt.
Nach der CCF-Initialisierung und der Inventarisierung der LUNs als Physical Volumes stellt sich die Ausgabe des "devtab" wie folgt dar:
root@big-5 # devtab -lvv
Running with clustername: beast
Building device table: ok
/dev/rdsk/c2t5000402301FC42E0d1s1 | C1_P1 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun1 | default |
/dev/rdsk/c3t5000402001FC42E0d2s1 | C0_P0 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun2 | default |
/dev/rdsk/c2t5000402301FC42E0d3s1 | C1_P1 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun3 | default |
/dev/rdsk/c3t5000402001FC42E0d4s1 | C0_P0 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun4 | default |
/dev/rdsk/c2t5000402301FC42E0d5s1 | C1_P1 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun5 | default |
/dev/rdsk/c3t5000402001FC42E0d6s1 | C0_P0 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun6 | default |
/dev/rdsk/c2t5000402301FC42E0d7s1 | C1_P1 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun7 | default |
/dev/rdsk/c3t5000402001FC42E0d8s1 | C0_P0 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun8 | default |
/dev/rdsk/c2t5000402301FC42E0d9s1 | C1_P1 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | lun9_stripe | default |
/dev/rdsk/c3t5000402001FC42E0d0s1 | C0_P0 | sunEFI | | NEXSAN | SATABeast | native | pv | 0 | beast | ccf_beast | dvsys |
Die entsprechende Ausgabe von "pvadmin -lvv":
root@big-5 # pvadmin -lvv
0 ccf_beast (ok) 3888828 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c3t5000402001FC42E0d0s1
0 lun1 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c2t5000402301FC42E0d1s1
0 lun2 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c3t5000402001FC42E0d2s1
0 lun3 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c2t5000402301FC42E0d3s1
0 lun4 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c3t5000402001FC42E0d4s1
0 lun5 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c2t5000402301FC42E0d5s1
0 lun6 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c3t5000402001FC42E0d6s1
0 lun7 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c2t5000402301FC42E0d7s1
0 lun8 (ok) 3999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c3t5000402001FC42E0d8s1
0 lun9_stripe (ok) 1999982524 blocks over 1 path(s)
>[ 1] (ok) /dev/rdsk/c2t5000402301FC42E0d9s1
Wie unschwer zu erkennen ist, existierte nur ein Pfad zu den LUNs. Dies lag an dem verwendeten Failover-Modus und dem Direkt-Anschluss. Zusätzlich wurde eine Pfadpräferenz eingerichtet: Alle geraden LUNs wurden über Controller 3 und alle ungeraden über Controller 2 angesprochen. Durch diesen Kniff war es nun möglich, bei entsprechender Verteilung der OSL Universen bzw. der unterschiedlichen AVs, die maximale IO-Leistung (insofern möglich mit 2 Controllern) zu erreichen. Doch dazu mehr im nächsten Abschnitt.
Ergebnis: Die Integration des SATABeasts in Solaris und den OSL Storage Cluster verlief ohne Probleme.
Wir haben diverse Messungen mit verschiedenen RAID-5-Set Größen (also Anzahl der Disks/Set) durchgeführt und die geweckten Erwartungen (800 MB/s laut "Hochglanzbroschüre") konnten fast erfüllt werden. Klar war, dass erst mit hinreichend großen RAID-Sets richtig Freude hinsichtlich der Durchsätze aufkommt. Bei Verteilung der RAID-Sets auf die Host-Controller konnten wir mit 13-Platten-RAID-Sets (RAID-5) immerhin 685 MB/s lesen und etwa 670 MB/s schreiben. Diese Werte sind durchaus praxistauglich und entstanden beim parallelen Lesen/Schreiben von bzw. auf 120 Application Volumes, die gleichmäß über die 2 HBAs des Hosts (und damit auch über die RAID-Sets der verschiedenen RAID-Controller des SATABeasts) verteilt waren.
Die enorme Leistung des SATABeast kann also bestätigt werden. Wird jetzt die rekordverdächtige Packungsdichte und die AutoMAID-Technologie mit in die Betrachtungen einbezogen, bleibt ein nachhaltig positiver Eindruck, der das SATABeast als Backup-RAID geradezu prädestiniert.
Die MAID-Technologie (MAID - Massive Array of Idle Disks) bietet eine aktive Drehzahlsteuerung der Festplatten in Leerlaufzeiten. Dies bedeutet, dass nicht benötigte Disks in einem MAID-fähigen RAID-System entweder gedrosselt werden oder auch einen kompletten Spin-Down erfahren. Ein einfaches Parken der Schreib-/Leseköpfe ist ebenso möglich. Das SATABeast beherrscht diese Technologie und kann entsprechend konfiguriert werden. Leider ist MAID nicht standardisiert, so dass nicht alle Plattenhersteller diese Features für Ihre Disks anbieten.
Nexsan unterstützt alle vorhandenen MAID-Stufen (Quelle Cristie):
Momentan unterstützen nur wenige Platten-Hersteller (z.B. Hitachi) alle drei Stufen. Zudem gibt es auch nur wenige RAID-Systeme die diese Technologie überhaupt nutzen. Insbesondere für Backup-RAID-Systeme macht die Verwendung durchaus Sinn, da so in Leerlauf-Zeiten die nicht genutzten Platten deutlich weniger Energie verbrauchen. Inwieweit das den Platten schadet, wird die Zukunft zeigen. Allerdings haben SATA-Platten nicht die von schnellen SAS-Platten bekannten Anlaufschwierigkeiten, wenn sie komplett angehalten wurden.
Das Nexsan SATABeast konnte überzeugen. Die sehr guten Durchsätze, die hohe Packungsdichte und das MAID-Feature sind perfekt auf die Nutzung als Backup-RAID-System abgestimmt. Rein technisch ist das System gut gelungen.
Natürlich kann auch bei diesem System noch etwas verbessert werden: Trotz des insgesamt gut gelösten Web-GUIs (es funktionierte auf Anhieb mit allen Browsern) wünscht sich der Unix-Anwender für das Anlegen von vielen Volumes und den dazugehörigen Host-Mappings natürlich schon ein solides CLI. Windows-Anwender sind Klick-Orgien möglicherweise gewöhnt und stören sich weniger an diesem Manko. Das ASCII-Interface am seriellen Port bietet zumindest auch ohne Browser Zugriff auf alle Einstellungen und wird mittels Tastatur bedient (Pfeil-Tasten). Ein Öffnen des Gehäuses ohne Schraubendreher würde die Servicefreundlichkeit nochmals verbessern. Ansonsten ist die Verarbeitung sehr robust, wenn auch auf den Transport des Systems im Vollausbau verzichtet werden sollte, da die Platten direkt auf der Platine aufliegen und diese beim Transport brechen könnte. Die Platten sollten also für Transporte ausgebaut werden. Positiv fiel auf, dass es egal ist, welche Platte wo gesteckt wird. Die RAID-Sets bleiben erhalten.
Insgesamt auf den ersten und zweiten Blick - auch wenn wir natürlich keine vollumfänglichen Integrationstests gefahren haben - ein gelungenes System, das speziell in Kombination mit OSL Storage Cluster sicher auch gehobenen Anforderungen entsprechen kann