Setup

Hardware

• Storage-System
  • DELL PowerVault MD3000i
    • 8x 1TB SATA HDDs
    • Dual-Controller mit jeweils 2x 1GB Ethernet
• Server-Hardware
  • DELL PowerEdge 2950
    • 2x Dual-Core XEON 2.0 Ghz, 10GB RAM
    • 2x Gigabit Ethernet Ports onboard (Broadcom) + Dual Gigabit-Netzwerk PCIe-Karte (Intel)
  • DELL PowerEdge 2950
    • 2x Dual-Core XEON 2.0 Ghz, 8GB RAM
    • 2x Gigabit Ethernet Ports onboard (Broadcom) + Dual Gigabit-Netzwerk PCIe-Karte (Intel)
• Netzwerk-Equipment
  • DELL PowerConnect 5448 (ISCSI)
    • 48x Gigabit Ethernet Ports
  • DELL PowerConnect 2724 (LAN)
    • 24x Gigabit Ethernet Ports

Der PowerEdge 860 (unter der MD3000i) und der dritte PowerEdge 2950 kam in diesem Test nicht zum Einsatz.

Software

Auf dem ersten PE2950-Server kommt Windows 2003 x64 Server SP1, auf dem zweiten CentOS 5.3 mit den neuesten DELL Storage-Treibern und Multipath-Software zum Einsatz, die nach DELL Installationsanleitungen eingerichtet wurden.

Konfiguration

Über alle 8 in der MD3000i verbaute 1GB-SATA-Festplatten wurde ein RAID-10 mit der Segmentgröße von 128kb erstellt. Jeweils 1GB große Volumes wurden per ISCSI für das Windows- und Linux-System erstellt und freigegeben.

Unter Windows 2003 Server wurde als "Loadbalancing Policy" RoundRobin konfiguriert, unter CentOS wurde zusätzlich noch mit "Last Queue Depth" getestet. In den Linux Ergebnistabellen sind die beiden LB Policys mit RR und QD gelistet.

Aufbau

Die 48 Gigabit-Ports des PC5448-Switches sind auf 2 VLANs aufgeteilt, um zwei von einander getrennte und dedizierte ISCSI-Netzwerke zu schaffen (siehe die Switches in der Skizze unter Punkt 2, die in diesem Fall als 2 virtuelle Switches per VLAN realisiert wurden). Die jeweils 2 Gigabit-Ports der beiden Controller des MD3000i sind über Kreuz mit den beiden VLANs des PC5448-Switches verbunden, so dass insgesamt 4 Pfade zum Storage-System bestehen (untere rote Leitungen in der Skizze). Auch die jeweils beiden Onboard Gigabit-Ports der zwei PE2950-Server (1) sind an diese beiden VLANs des PC5448-Switches angeschlossen (obere rote Leitungen in der Skizze).

Der PC2724-Switch bildet das LAN (5), an dem die Management-Ports des MD3000i (3) und jeweils ein Port der Intel Dual-Gigabit-Karte der beiden PE2950-Server angebunden sind (blaue Leitungen in der Skizze).

Netzwerkkabel: ISCSI {{ gelb, LAN }} grün, Management = grau

Windows: IOMeter

Profile

Folgende Test-Profile kamen in den IOMeter Tests zum Einsatz:

Beschreibung der Ergebnistabellen

Kurze Erläuterung der Spalten-Abkürzungen der IOMeter Ergebnis-Tabellen:

Spaltenbezeichnung	Beschreibung
IOMeter Test	Zum Einsatz kommendes IOMeter Profil, siehe oben
IOPS R	Read Input/Output operations Per Second
IOPS W	Write Input/Output operations Per Second
IOPS T	Total Input/Output operations Per Second
MB/s R	Lesedurchsatz (Blockgröße * IOPS R)
MB/s W	Schreibdurchsatz (Blockgröße * IOPS W)
MB/s T	Gesamtdurchsatz (MB/s R + W)
IO Rp R	Durchschnittliche Lesezugriffszeit in ms
IO Rp W	Durchschnittliche Schreibzugriffszeit in ms
IO Rp W	Durchschnittliche Zugriffszeit in ms
CPU %	Durchschnittliche CPU-Auslastung des Systems beim Test

Ergebnis: 1 Worker, 1 IO, Raw-Device

Im ersten Test wird mit einem Thread (1 Worker) und immer nur einem gleichzeitig offenen IO-Request (1 IO) auf einem Raw-Volume der MD3000i gelesen und geschrieben. Bei nicht parallelen Zugriffen zwischen 4 und 32k Größe hat das Storage-System wenige Möglichkeiten, den Vorteil von mehreren Spindeln (Festplatten) zu nutzen. Dennoch erzählt das System beim Random-Zugriff immerhin 144 IOPS, obwohl eine SATA-Festplatte in dieser Größe nur etwa 80 bis 90 IOPS erreichen kann (siehe Performance-Database von StorageReview). Enttäuschend dagegen ist der sequentielle Zugriff mit 32k Blöcken: Nur 43,7MB/s lesen ("max read") und 22,38MB/s schreiben ("max write"). Bei den Profilen "stream read" und "stream write" mit Blockgrößen von 64 bis 256k können immerhin 76MB/s Lesen und 45,9MB/s Schreiben erzielt werden, was u.a. durch das Striping der Daten im RAID über die verschiedenen Platten zu erklären ist. Die sehr geringen durchschnittlichen Schreibzugriffe (< 1ms) kommen u.a. durch den Schreibcache des Controllers zu stande.

Ergebnis: 1 Worker, 64 IOs, Raw-Device

Im zweiten Test werden die Performancewerte des Storages mit 64 gleichzeitig offenen IO-Request ermittelt, was einer üblichen Auslastung im produktiven Einsatz entspricht. Wir erhalten knapp 188,7 MB/s sequentielles Lesen, 82,5 MB/s sequentielles Schreiben (32k) und 665 IOPS bei Random-Zugriff (8k bei 70% read). Das sequentielle Lesen lastet die 4 XEON 2Ghz-CPU-Kerne fast zu einem Drittel aus.

Ergebnis: 4 Worker, 16 IOs, Raw-Device

Verteilt man die 64 gleichzeitigen IO-Zugriffe auf 4 Threads (Worker) mit jeweils 16 IO-Zugriffen knackt man beim sequentiellen Lesen die 200MB/s Marke und ist damit nach Abzug des Overheads schon ziemlich Nahe am Maximum von 2 x 1 Gigabit, mit dem die Server am ISCSI-Netzwerk angebunden sind. Auch beim sequentiellen Schreiben von 64 bis 256k ("stream write") werden Bestwerte im ganzen Test erreicht: 134 MB/s. Bei den Random-Zugriffen ändert sich nicht viel. Die CPU-Auslastung steigt durch die gleichzeitigen Zugriffe über die 4 Worker stark an.

Ergebnis: 1 Worker, 64 IOs, NTFS

Die Umstellung von Raw-Device auf ein NTFS-Dateisystem bewirkt in allen Test leicht schlechtere Werte. Die CPU-Last steigt vor allem beim sequentiellen Schreiben an (22% Steigerung im Vergleich zu Raw), bei Random-Zugriffen geringer (8%).

Ergebnis: 1 Worker, 64 IOs, NTFS mit 64k Clustergröße

Verwendet man bei NTFS eine Clustergröße von 64k fällt die CPU-Belastung vorallem beim Schreiben stark ab (bei sequentiellem Schreiben 71.5% geringere Belastung und damit sogar geringer als beim Raw-Zugriff). Dafür bricht der Random- und Reallife-Zugriff um etwa 6.5% ein.

Ergebnis: 1 Worker, 64 IOs, NTFS, Flow-Control aktiviert

Aktiviert man Flow-Control im Switch fällt die CPU-Belastung ähnlich wie bei 64k NTFS ab, die Performance bleibt sowohl bei sequentiellen als auch beim Random-Zugriff stabil (sie steigt sogar ein wenig). Mit Flow-Control lässt sich bei akzeptabler CPU-Auslastung also die beste Performance erzielen.

Ergebnis: 1 Worker, 64 IOs, NTFS, Jumbo-Frames aktiviert

Mit aktivierten Jumbo-Frames (MTU=9000) im Switch und den Netzwerkkarten im Server fällt das sequentielle Lesen mit 32k etwas ab (4,5%), steigt jedoch bei 64k - 256k ("stream read") stark an (26%). Random-Zugriffe fallen wiederrum mit 10% deutlich spürbar ab. Die Stärke der Jumbo-Frames-Konfiguration ist eindeutig die geringe CPU-Auslastung: 52% geringer bei sequentiellen Lesen, 130% geringer bei sequentiellen Schreiben und 13% geringer beim Random-Zugriff. Mit Jumbo-Frames lässt sich also bei guter Performance die geringste CPU-Auslastung erreichen.

Windows: ORION (Oracle I/O Calibration Tool)

Aufruf-Parameter

orion.exe -run normal -testname md3000i1 -num_disks 8 -cache_size 512 

Ergebnis: IOPS

Auf der Y-Achse werden die erreichten IOPS aufgeführt, die X-Achse gibt die Anzahl kleinerer IO-Zugriffe (4-8k) an und die farblich unterschiedlichen Kurven (1-40) die Anzahl der größeren IO-Zugriffe (128k). Ab 24 größeren Zugriffen steigt die IOPS nicht mehr stark an. Schon bei wenigen, kleineren IO-Zugriffen fällt die IOPS stark ab.

Im dreidimensionalen Chart sind die größeren IO-Zugriffe auf der Z-Achse aufgetragen.

[Datendatei: IOPS (xls)]

Ergebnis: Durchsatz

Unable to render embedded object: File (orion_mbps.png) not found.

In diesem Chart werden auf der X-Achse die Anzahl der größeren IO-Zugriffe dargestellt und mit den farblich unterschiedlichen Kurven (1-40) die Anzahl der kleineren IO-Zugriffe. Bei wenigen kleineren IO-Zugriffe (1-4) erreicht das System schon ab etwa 3-5 größeren IO-Zugriffe den maximalen Durchsatz. Bis 16 kleinere IO-Zugriffen fällt der Durchsatz recht stark ab, danach geringer.

[Datendatei: Durchsatz (xls)]

Ergebnis: Zugriffszeit

Unable to render embedded object: File (orion_latency.png) not found.

Auch in diesem Chart werden auf der X-Achse die Anzahl der größeren IO-Zugriffe dargestellt und mit den farblich unterschiedlichen Kurven (1-40) die Anzahl der kleineren IO-Zugriffe. Bis 9 größere IO-Zugriffe steigt die Zugriffszeit abhängig von der Anzahl der kleineren und größeren IO-Zugriffe recht linear an, danach flukturieren die Werte.

[Datendatei: Zugriffszeit (xls)]

Linux: dd

Ergebnis: Sequentielles Lesen

Zwischen den Loadbalancing Verfahren RoundRobin und Last Queue Depth sind in diesem Test keine Unterschiede zu bemerken. Bei größeren Blockgrößen fällt die Leserate etwas ab. Mit Jumbo-Frames steigt die Leserate um etwa 11%. Das Dateisystem XFS performt etwas schlechter beim sequentiellen Lesen als Ext3. Merkwürdigerweise konnte mit dem Raw-Device eine nur 45% geringere Leserate erzielt werden.

Ergebnis: Sequentielles Schreiben

Die Schreibrate bleibt unabhängig von der Blockgröße und von der MTU-Einstellung (Jumbo-Frames) recht konstant. Lediglich bei xfs und dem raw-Device konnte eine etwas geringe Schreibrate erzielt werden.

Linux: bonnie++

Beschreibung der Ergebnistabellen

Kurze Erläuterung der Spalten-Abkürzungen der bonnie++ Ergebnis-Tabellen:

Ergebnis

Im Gegensatz zu den Tests mit dd sind bei den bonnie++ Ergebnissen Unterschiede zwischen den beiden Loadbalancing Verfahren zu erkennen (bei ext3 bis 7%, bei xfs bis zu 14%). Die Aktivierung von Jumbo-Frames erzielt bessere Leseraten bei etwas schlechteren Schreibraten (Zeichenweise). Die höchsten Leseraten mit 115,5 MB/s und die geringste CPU-Auslastung konnten bei dem letzten ext3-Test mit Jumbo-Frames und folgenden TCP/IP Kernel-Anpassungen erreicht werden:

net.core.wmem_max=12582912
net.core.rmem_max=12582912
net.ipv4.tcp_rmem= 10240 87380 12582912
net.ipv4.tcp_wmem= 10240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.core.netdev_max_backlog = 5000