NexentaStor Allgemeine Informationen

Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird. Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

Dieser Artikel beschreibt Allgemeines rund um NexentaStor und den dahinter stehenden Storageansatz. NexentaStor basiert im Kern zur Zeit noch (Stand Mai 2012) auf OpenSolaris (Aktuelle Versionsinformationen zu NexentaStor). Grundlegende Vorteile hat das System durch die Verwendung des Dateisystem ZFS von Sun Microsystems. Aufgrund dessen können nachfolgende Informationen auch auf ZFS übertragen werden.

NexentaStor Poolaufbau

Im Gegensatz zu klassischen Systemen verwendet NexentaStor den Ansatz des pooled Storage. Das heisst, dass nicht einzelne Raidgruppen gebildet werden, aus denen Speicherplatz bezogen wird, sondern mehrere Raidgruppen (=Toplevel vDev) in einem Pool zusammengefasst werden.

Dies hat den Vorteil, dass man weitere Raidgruppen hinzufügen kann und dadurch im laufenden Betrieb sowohl die Kapazität als auch die Geschwindigkeit des gesamten Systems erhöht wird.

In etwa ist dies vergleichbar mit einem Raid 10 / 50 / 60 Ansatz.

Grundsätzlich spricht man in der Terminologie von

vDev = entspricht einer Festplatte, SSD oder allgemein einer Speichereinheit (kann bei ZFS bspw. auch eine Datei sein!)
Toplevel vDev = Logischer Container, der vDevs beinhaltet und mit einer Redundanzoption ausgestattet werden kann:
- Mirror (2-/3-Wege Spiegel)
- RaidZ-1 - Einfache Parität
- RaidZ-2 - Zweifache Parität
- RaidZ-3 - Dreifache Parität
Pool = Beinhaltet mehrere Toplevel vDevs und bildet den nutzbaren Speicherbereich ab

Caching Mechanismen

ARC (=Adaptive Replacement Cache)

Dieser Bereich ist fast vollständig mit dem Arbeitsspeicher gleichzusetzen und fungiert als allgemeiner Cache. Für den lesenden Bereich teilt sich dieser noch in MRU (=Most recently used) und MFU (= Most frequently used) auf. Diese Bereiche passen sich aufgrund von intelligentem Prefetching dynamisch an.

L2ARC (Level 2 ARC)

Im System wird dieses Gerät über "cache" hinzugefügt. Dabei handelt es sich, wie der Name schon sagt, um eine Erweiterung des ARC, also des RAMs. Passen Daten nicht mehr in den RAM, "fallen" sie in den L2ARC (siehe Ghosts in memstat). Mit richtiger Dimensionierung (Working Set) kann das System alle Leseoperationen aus dem RAM bzw. dem L2ARC bedienen.

sLOG (oft fälschlicherweise als ZIL bezeichnet) = separates LOG Gerät

Wenn das System mit sehr vielen synchronen IO-Operationen konfrontiert ist, kann ein sLOG die Performance signifikant erhöhen. Dieses Gerät ist idealerweise sehr klein und dabei sehr schnell und mit einem Mechanismus zum Schutz der Daten bei einem Stromausfall ausgestattet. Ein sLOG kann eine SSD oder auch eine Festplatte sein. Spiegelung des sLOG ist möglich.

Beispiel Mirror Pool

Eckdaten für Testsystem - Sie möchten NexentaStor testen?

Um NexentaStor entsprechend testen zu können, sollte die Konfiguration folgende Eckdaten erfüllen

4 Kerne
Mindestens 48GB RAM (NexentaStor verwendet als primären Schreib- und Lese-Cache RAM)
Kein Raidcontroller - idealerweise Host Bus Adapter (IT Firmware - Initiator Target), der die HDDs nur an das OS durchreicht
Mindestens 8-10 vDevs = 1 Pool (siehe auch https://en.wikipedia.org/wiki/ZFS unter Storage Pools)
- Für schreibintensive Workloads: Pool bestehend aus Mirrors + dediziertes LOG Device
- Für leseintensive Workloads: Pool bestehend aus RaidZ-2 + Level 2 ARC als Lesecache
Synchrone Deduplikation benötigt eine ausreichende RAM Größe, da die Deduplizierungsinformationen im RAM gehalten werden. Wichtige Faktoren sind Blockgröße, die gesamte Speicherkapazität und die Art der Anwendungsdaten, die zu deduplizieren sind.
Wenn Sie Deduplizierung einsetzen möchten, bitte verwenden Sie viel RAM (mind. 192 GB).

Weitere Informationen / Links

ZFS

ZFS (Dateisystem)

Autor: Florian Hettenbach