Fehlertoleranz, Lastoptimierung und iSCSI-Targets

Anbieter zum Thema

DataCore Software GmbH

FAST LTA GmbH

Impossible Cloud GmbH

Adaptive Load Balancing sorgt für Durchsatz

Im Rahmen unseres Tests setzten wir auf „Adaptive Load Balancing“. Hierbei werden mehrere physische Netzwerkinterfaces zu einem logischen Anschluss zusammengefasst. Im Test koppelten wir alle vier Netzwerkinterface zu einer einzigen Verbindung. Diese vier Interfaces erhalten dann alle eine gemeinsame IP-Adresse zugewiesen. Das soll für einen maximalen Durchsatz sorgen. Laut Hersteller lassen sich dabei folgende Wert erreichen.

Beim Einsatz der zwölf Festplatten in verschiedenen Speicherpoolgrößen (z. B. 1 x 12, 2 x 6 od. 3 x 4 Platten/Pool) im RAID 5 und unter der Voraussetzung, dass vier Netzwerkkarten per Adaptive Load Balancing gebündelt werden, sollten folgenden maximalen Werte gelten:

• CIFS-Schreibgeschwindigkeit (sequentiell): ca. 300 MB/s (bei 2 x 6 Platten im RAID 5)
• CIFS-Lesezugriffe: ca. 410 MB/s (bei 2x6 Platten im RAID 5)
• Bei zufällig verteilten Zugriffen sollten 420 IOPS zu erzielen sein (3 x 4 Platten im RAID 5)

Bei der Anbindung via iSCSI sollten im Schreibmodus (sequentiell) ca. 270 MB/s (2 x 6 Platten) zu erzielen sein. iSCSI-Lesen wiederum soll 410 MB/s (2 x 6 Platten) ermöglichen. Bei den zufällig verteilten Zugriffen via iSCSI gab der Hersteller ca. 510 IOPS (1 x 12 Platten) an.

Generell ist es so, dass CIFS-Zugriffe im Vergleich zu iSCSI einen höherer Schreibdurchsatz ermöglicht. Bei den Lesezugriffen gibt es kaum Unterschiede zwischen iSCSI und CIFS. iSCSI hat allerdings Vorteile bei zufällig verteilten Zugriffen. Ferner gilt: RAID 5 hat einen höheren Schreibdurchsatz als RAID 6, beim Lesen gibt es nur geringe Unterschiede (außer bei „kleineren“ RAID-Gruppen mit sechs oder acht Festplatten). Der Durchsatz sinkt außerdem systembedingt bei RAID 10.

Praxistest der Zugriffe

Im Rahmen unseres Tests wollten wir diese Werte prüfen. Als Testtool setzten wir, wie auch der Hersteller, auf IOmeter. Als Clientsystem kamen Windows-7–Rechner zum Einsatz, die jeweils mit 1-Gigabit-Interfaces ausgestattet waren. IOmeter meldete bei 32 Kilobyte Blockgröße einen Maximaldurchsatz von circa 120 Megabyte. Das war weitaus weniger als die vor Hersteller erwähnten 410 Megabyte.

Die Ursache für die Differenz war schnell gefunden: Über ein Gigabit-Interface können auch nur annähernd 120 Megabyte transferiert werden. Um keine störenden Einflüsse durch das Betriebssystem zu erhalten, entschieden wir uns, die Lasterhöhung nicht über das jeweils zweite Rechnerinterface vorzunehmen. Stattdessen nahmen wir zwei weitere Windows-7-System in Betrieb und führten parallele Zugriffe von nunmehr drei getrennten Systemen aus.

Auch hierbei zeigte sich nur ein marginaler Leistungseinbruch auf etwa 110 Megabyte auf jedem der drei Clientsysteme. Da 3 x 120 Megabyte bereits 360 Megabyte Gesamtdurchsatz ergeben und der Einbruch, wie erwähnt, nur gering war, sahen wir keinen Grund, an der 410-Megabyte-Angabe des Herstellers zu zweifeln. Es zeigt sich im Rahmen der Tests auch, dass dieser Durchsatz natürlich nur bei den größten Blockgrößen zu erzielen ist. IOMeter unterstützt maximal 32 Kilobyte.

Anbindung via iSCSI

Das StorCenter kann via CIFS oder iSCSI angebunden werden. Für die Windows-NAS-Integration setzt man in der Regel auf CIFS. Im nächsten Schritt koppelten wir das Speichersystem via iSCSI an einen VMware-ESX-Rechner. Der Einsatz eines iSCSI-Speichers benötigt immer zwei Komponenten: das iSCSI-Target und den iSCSI-Initiator. Das Target wird durch das Speichersystem realisiert. Der Initiator ist der Nutzer des iSCSI-Speichers. Der Zugriff des Initiators auf den Target erfolgt über eine TCP/IP-Strecke. Damit können der Speicher und sein Konsument beliebig weit voneinander entfernt stehen. Aus Gründen des Zugriffsgeschwindigkeit und der Latenzzeit wird man aber Initiator und Target nicht zu weit voneinander trennen.

Weiter mit: Einrichten des Targets

(ID:2049974)