Es gilt die Empfehlung bei einem Raid5 eine ungeradzahlige Anzahl von Festplatten einzusetzen, so daß die Daten auf 4+1 verteilt werden. Somit habe ich mein raidz1 von 4 disks (mit ZIL) auf 5 disks (ohne ZIL) erweitert und hier sind die Ergebnisse, teils ernüchternd und mehr oder minder enttäuschend, aber auch teils imposant:
Sequential Output bei char etwa gleich, beim Block mehr als 50% Steigerung, beim Rewrite mehr als das Doppelte, idR immer einhergehend mit einer höheren CPU-Last, gerade bei letzterem hätte ich weniger Last erwartet… Beim Sequential Input char einen massiven Einbruch beim Block lesen…
Hier mal ein paar performance Messungen unter FreeBSD. Messungen sind ja alle sehr relativ, der eine mag das Andere, ich mag bonnie. Die Messungen fanden statt auf einem i5-6600, 32GB Ram und FreeBSD 12.2, bonnie++1,98. Filesystem ist ZFS. Der Cache ist 29GB groß, das ZIL 1GB.
Samsung SSD 950 PRO 512GB
Die 950 Pro wurde abgelöst – durch eine SanDisk Extreme Pro 1TB. Sie dürfte baugleich mit der WD Black Series sein, WD kaufte SanDisk vor längerem. Die performance Messungen fanden unter FreeBSD 13-Release statt.
SanDisk Extreme Pro 1TB
Raid1 mit 2x Seagate Barracuda 4TB
Bei der initialen Erstellung meines Raid1 bestehend aus 2 Seagate 4TB Festplatten des Typs ST4000DM004 hatte ich einfach den zpool create mit den raw-devices verwendet – und damit das sector 63 Problem:
Danach interessiert man sich dafür, wofür man sich die Arbeit gemacht hat und macht mal ein paar performance Messungen, angefangen mit einer Single-disk, über Zuschaltung von cache und zuletzt dem ZIL (log):
Interessant empfinde ich, daß ein Spiegel unter dem Strich erkennbar schlechtere Werte liefern kann, als die Single-disk – ausgenommen beim seq-output rewrite und seq-input-block. Ansonsten ist der Vergleich zwischen alter RAID1 und neuer ganz passabel – man sieht deutlich schlechtere Werte in der alten RAID1-config: seq. output Block 10MB/s zu 78MB/s, rewrite 8k3 zu 46m, seq Input Block 2.7g zu 229m??? ein schlechterer Wert dafür mit wesentlich weniger Last random seeks und allgemein weniger CPU-Last… und vor allem sieht man wesentlich geringere Latenzen -> hat sich also meiner Meinung nach gelohnt, also wird irgendwann später das Raid5 auch umgestellt!
Raid5 mit 4x Seagate IronWolf 6TB
Leider hatte ich auch bei der initialen Erstellung meines raidz1 Volumes (Raid5) aus 4x 6TB Festplatten (Seagate Ironwolf 5400rpm, ST6000VN001) nicht GPT zur Partitionierung verwendet, sondern die raw-devices direkt mit zpool angesprochen. Jetzt habe ich die Umstellung vorgenommen und vorher wie nachher bonnie++ Messungen vorgenommen (zpool in allen Fällen mit gleichen Daten gefüllt zu etwa 80%):
Signifikanteste Verbesserungen mit korrektem Blockalignment sieht man beim sequential Output: 244 zu 311MB/s, beim rewrite von 116 zu 169MB/s, beim sequential Input Block von 296 zu 502MB/s – interessanterweise hierbei überall mit mehr CPU-Last zu vorher (meine Theorie: Daten kommen logisch sauberer im alignment auf die Platte und somit sind schneller die Parity-Berechnungen erforderlich). Random seeks haben sich verbessert von ~138/sec zu ~173/sec. Weitere Verbesserungen zu sehen beim sequential create die Latenz hat sich von ~12,800µs auf ~1450µs verbessert und beim Random Create von 178ms zu ~1500µs.
Das sind so die signifikantesten Verbesserungen des RAID5 Stapels, welche sich beim benchmarking zeigen. Ich unterstelle, daß ich in der Praxis bestimmt nicht soviel merken werde. Mit der Umstellung ist aber ein mögliches Bottleneck beseitigt.
Die Werte mit ZIL als Verbesserung erachte ich als vernachlässigbar, in Relation zu der damit einhergehenden Gefahr eines Total-filesystem-Verlustes mit dem Hops-gehen eines ZILs. Dafür macht man kein RAID5, um Datenverlusten vorzubeugen. Also wird beim nächsten Umbau der Systemplatte der ZIL verschwinden.