Wenn man mit einer oder mehreren VMware-Workstation unter Linux hantiert, ist man froh über einen guten I/O. Gestern hat mich jemand in diesem Zusammenhang auf meine Erfahrungen mit 3ware-Controllern angesprochen.
Pauschal konnte und kann ich darauf nicht antworten – man müsste für eine solide Einschätzung systematische Vergleiche mit anderen Controllern durchführen. Dazu fehlen mir im Moment schlicht die Ressourcen. Es gibt aber interessaante Diskussionen im Internet. Ich empfehle den folgenden Beitrag
http://makarevitch.org/rant/raid/
Siehe auch die dortigen Links mit wirklich interessanten Statements und Erfahrungen zu 3ware-Controllern unter Linux. Hochinteressant finde ich vor allem die Vergleiche mit SW-Raid-Konfigurationen unter Linux, die mich ab und zu doch an meinen Investitionen in HW-Raid für Desktops zweifeln lassen.
Dennoch und aus dem Bauch heraus: Meine Erfahrungen sind im Mittel nicht schlecht, aber gerade mit laufenden VMware-Workstations wird der Platten I/O auf meine Opensuse Kisten bisweilen für kurze Momente zu einem echten, spürbaren Engpass. Zumindest, wenn man sich nicht ein wenig um die (begrenzten) Einstellmöglichkeiten des Controllers und auch des Linux-Systems kümmert.
Aufgefallen ist mir in der Praxis auch, dass auf meinen Opensuse-Systemen mit Quadcore-Prozessoren unter Last irgendwie immer (oder vor allem) der erste Core hohe WAIT I/O-Werte aufweist. Ich gehe mal davon aus, dass die 3ware-Treiber in Kombination mit dem Kernel den Controllerzugriff und den Datentransfer über genau einen Core handhaben. Auch dazu gibt es Hinweise in einschlägigen Diskussionen im Internet.
Der von mir auf den Desktop-Systemen verwendete Controller “9650SE-4LPML” ist ferner nicht ein System, bei dem man die Performance über große Raid-Stapel mit 12 oder 24 Platten hochziehen könnte. Mit 4 Platten sind die Möglichkeiten halt begrenzt.
Also fängt man an, ein wenig herumzuprobieren und vor ein paar Monaten habe ich tatsächlich mal ein wenig Zeit investiert, um mir mit “Bonnie++” verschiedene Konfigurationen anzusehen. Allerdings nur mit EXT3/Ext4 als Filesystem. Wenn ich auf dieser Basis Empfehlungen geben sollte, dann wären es folgende:
1) 4 Platten – Raid 10
2) Wenn man es sich leisten kann : Eher kein LVM einsetzen.
3) Controller-Parameter: Read-Cache auf “Intelligent” setzen und Write-Cache aktivieren (Battery Unit zur Vermeidung von Datenverlusten/Inkonsistenzen einkalkulieren). StorSave auf “Balance” oder “Performance” setzen. Verwendung von “Queuing” (NTQ Feature der Platten, wenn vorhanden) anschalten.
(Zum Einstellen von Controller-Eigenschaften kann man übrigens gut das übersichtliche “3DM2” benutzen.)
4) Linux-Einstellungen – z.B. für ein Raid-Device, das unter “/dev/sda” anzusprechen ist:
echo “512” > /sys/block/sda/queue/nr_requests
und danach (!):
blockdev −−setra 16384 /dev/sda
5) VMware-Workstation (konfiguriert für 2 CPU-Cores eines Quad-Core-Systems):
Zuweisung des “vmware-vmx”-Prozesses an zwei andere Prozessor-Cores als den ersten, auf dem zumeist der I/O kontrolliert wird. Also z.B.:
taskset -pc 2,3 <pid des vmware-vmx-Prozesses>
Testet man die Performance unter diesen Bedingungen etwa mit zwei Raid 1 Units, die bei mir unter Linux als “/dev/sda” und “/dev/sdb” erscheinen, so erhält man mit Bonnie++ recht gute Werte für sequentielles Lesen und Schreiben (ca. 10% unter den theroretischen Maximalwerten der Platten). Aber es lohnt sich, auch andere Parameter-Werte – vor allem für blockdev – unter Linux auszuprobieren. Hier konnte ich durchaus messbare Unterschiede feststellen. Hat man gute Werte gefunden, hinterlegt man sich die Einstellungen in einem kleine Startup-Script.
Der Wechsel auf Raid 10 führt dann nochmals zu einer signifikanten Steigerung der I/O-Werte.
Mit unterschiedlichen Schedulern habe ich auch rumgespielt. Irgendwie erschienen mir die Unterschiede aber nicht so signifikant zu sein.
Ich hoffe, ein paar von den Hinweisen helfen auch anderen weiter.