Speicher-Benchmarks für Virtualisierungshosts

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 12.03.2020 12:12:41

Hallo zusammen,

ich bin aktuell dabei, die Leistung verschiedener Speicher-Konfigurationen(HDD,SSD) im Rahmen von Virtualisierung zu testen. Als Virtualisierungsplattform habe ich mir Proxmox VE mit KVM ausgesucht. Die Anwendung ist hierbei hauptsächlich das Webumfeld, also Webserver, MySQL- und Postgres-Datenbanken und serververarbeitete Programmiersprachen.(Java, PHP, Python, ...). Das ganze möchte ich von der Geschwindigkeit her testen.

Vielleicht kann man daraus auch einen Pro-Linux-Artikel machen, wenn die Arbeit tatsächlich einen Nutzen darstellen sollte und brauchbare Ergebnisse liefert.

Abgrenzung

Wenn hochperformante Datenbanken benötigt werden, dann kommen hier geplant dedizierte Server zum Einsatz, die speziell darauf ausgelegt sind. Nichts desto trotz werden auf der Umgebung einige Datenbanken betrieben.

Was natürlich interessant ist, in dem Zusammenhang, ist Ceph. Da man dafür aber mindestens(!) mal eine 10 GBit Vernetzung braucht und am besten durchgängig auch SSDs, ist das eher eine hochpreisige Angelegenheit. Wenn man das Budget dafür hat, dann wäre das mit Sicherheit meine 1. Wahl, auch weil man dann gleich einen redundanten, netzwerkfähigen Speicher hat. Ich habe auch einen Proxmox-Hyperconverged Cluster in meiner Verwaltung mit integriertem Ceph. Der lässt sich auch wirklich gut verwalten und bringt auch die Leistung, die man sich so erwartet - natürlich zum entsprechenden Preis. Aufgrund des Preises wird hier Ceph nicht berücksichtigt.

Falls Sich einer denken mag: SSDs sind doch gar nicht so teuer: Das gilt vielleicht für einfache Consumer-Modelle(z. B. 500 GB m.2 SSD für ~50 EUR. Gesamte Schreibkapazität während der Produktlebenszeit z. B. 300 TB). Eine Server-SSD, die auch wirklich wesentlich länger betrieben werden kann ist deutlich teuerer(z. B. Intel Optane DC4800X PCIe mit 375 GB für ~1100 EUR. Gesamte Schreibkapazität während der Produktlebenszeit: 20.5 PB).

Kriterien der Speicherkonfiguration

Bzgl. der Speicherkonfiguration möchte ich folgende Bereiche testen:
  • verschiedene Dateisysteme
  • LVM
  • Transparente Kompression(zfs/btrfs)
  • Thin Provisioning(zfs/lvm)
  • SSD-Caching(bcache,zfs(l2arc+zil))
  • Festplattenverbünde(RAID5(raidz)/RAID10(striped mirror))
  • Performance auf dem Hostsystem und in der virtuellen Maschine
Meine Fragen an Euch

Ich will aus der Geschichte keine Doktorarbeit machen und den Aufwand also in Grenzen halten. D. h. ich werde verzichte darauf, mich Wochen in die einzelnen Themen einzuarbeiten und nehme das, was bei mir an Wissen und Erfahrung bereits da ist und hoffe auf Unterstützung der Experten hier.

Auf was sollte ich bei speziellen Technologien achten, um die grössten Performancebremsen zu vermeiden? Meiner Einschätzung nach lesen hier einige Spezialisten mit was z. B. btrfs und zfs angeht und ich hoffe, dass ich bei Wissenslücken bzw. Konfigurationsfehlern hier Hilfen erhalte.

Bei zfs kenne ich mittlerweile die folgenden wesentlichen wichtigen Kriterien:
  • Blockgrösse muss entsprechend der Hardware gesetzt sein(ashift)
  • Für das Caching sollte ausreichend RAM zur Verfügung stehen
  • Ab einem Füllgrad von >= 80% verringert sich die Performance deutlich
  • Nicht gleichmässig gefüllte VDEVs verringern die Performance(Direktes ausbalancieren nur explizit durch export/import möglich).
Bei btrfs achte ich darauf...
  • nur stabile Features zu verwenden(Wenn RAID5 dann Linux-SW-RAID 5+btrfs-single und nicht btrfs-raid5)
Konkretes Vorgehen

Konkret werde ich fio benutzen um verschiedene Tests auf den verschiedenen Speicherkonfigurationen zu benutzen. Dazu werden jeweils einzelne Dateisysteme, RAID-Arrays, LVM-Konfigurationen, ... erstellt und anschliessend werden da die Tests drauf gefahren.

Aktuelle Hardwareumgebung, die noch erweitert wird ist:

Code: Alles auswählen

# inxi -v2 -C -D -M -R -m

System:    Host: pvetest Kernel: 5.3.10-1-pve x86_64 bits: 64 Console: tty 1 Distro: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop Mobo: Intel model: DQ67SW v: AAG12527-309 serial: BQSW133004FE BIOS: Intel 
           v: SWQ6710H.86A.0067.2014.0313.1347 date: 03/13/2014 
Memory:    RAM: total: 15.55 GiB used: 825.5 MiB (5.2%) 
           Array-1: capacity: 32 GiB slots: 4 EC: None 
           Device-1: Channel A DIMM 0 size: 4 GiB speed: 1333 MT/s 
           Device-2: Channel A DIMM 1 size: 4 GiB speed: 1333 MT/s 
           Device-3: Channel B DIMM 0 size: 4 GiB speed: 1333 MT/s 
           Device-4: Channel B DIMM 1 size: 4 GiB speed: 1333 MT/s 
CPU:       Topology: Quad Core model: Intel Core i7-2600 bits: 64 type: MT MCP L2 cache: 8192 KiB 
           Speed: 3675 MHz min/max: 1600/3800 MHz Core speeds (MHz): 1: 3664 2: 3480 3: 3592 4: 3684 5: 2381 6: 2475 7: 3595 
           8: 3034 
Network:   Device-1: Intel 82579LM Gigabit Network driver: e1000e 
Drives:    Local Storage: total: 3.97 TiB used: 13.43 GiB (0.3%) 
           ID-1: /dev/sda model: N/A size: 930.99 GiB  <--- SAS HDD
           ID-2: /dev/sdb model: 1 size: 930.99 GiB <--- SAS HDD
           ID-3: /dev/sdc model: 2 size: 930.99 GiB <--- SAS HDD
           ID-4: /dev/sdd model: 3 size: 930.99 GiB <--- SAS HDD
           ID-5: /dev/sde vendor: Intel model: SSDSC2MH120A2 size: 111.79 GiB <--- OS
           ID-6: /dev/sdf vendor: Samsung model: SSD 850 EVO M.2 250GB size: 232.89 GiB <--- later: Cachedisk
RAID:      Hardware-1: Intel SATA Controller [RAID mode] driver: ahci 
           Hardware-2: Adaptec AAC-RAID driver: aacraid 
           
# modinfo zfs
filename:       /lib/modules/5.3.10-1-pve/zfs/zfs.ko
version:        0.8.2-pve2
license:        CDDL
author:         OpenZFS on Linux
Scripte, die die einzelnen Konfigurationen erzeugen sind derzeit hier:

https://github.com/megabert/storage-benchmarks
Zuletzt geändert von heisenberg am 12.03.2020 12:37:59, insgesamt 7-mal geändert.

Benutzeravatar
bluestar
Beiträge: 2418
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Dateisystembenchmarks für Virtualisierungshosts

Beitrag von bluestar » 12.03.2020 12:17:42

Falls ich darf, so würde ich gerne ein paar Gedanken/Testcases beitragen wollen:
* ZFS mit SSD Cache
* Linux in KVM
* Linux in Container

Ich hoffe auf interessante Ergebnisse von dir und danke schon einmal vorab für die Mühe :hail:

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Dateisystembenchmarks für Virtualisierungshosts

Beitrag von heisenberg » 12.03.2020 12:20:34

ZFS mit SSD Cache
Habe ich mit eingeplant und in der obigen Beschreibung ergänzt.
Linux in KVM
Das ist der Hauptzweck meines Tests.
Linux in Container
Ist mir aktuell egal. Habe ich keinen Produktiveinsatz für. Ich schreib's mal auf die Liste. Vielleicht ist der Aufwand das mitzutesten nicht so gross.

Frage nach Unterstützung mit gnuplot

Falls jemand Lust hat beizutragen, würde ich mich auch freuen, wenn mir jemand bei dem gnuplot thread hier helfen könnte...

viewtopic.php?f=34&t=176674&p=1232264#p1232264

Die horizontale Variante finde ich doch viel gefälliger.

Benutzeravatar
hikaru
Moderator
Beiträge: 13896
Registriert: 09.04.2008 12:48:59

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von hikaru » 12.03.2020 12:54:35

heisenberg hat geschrieben: ↑ zum Beitrag ↑
12.03.2020 12:12:41
[*] Ab einem Füllgrad von >= 80% verringert sich die Performance deutlich
Das gilt nicht nur für ZFS ;) :
viewtopic.php?f=13&t=173317

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von Lord_Carlos » 12.03.2020 13:32:02

Der ZFS schreib cache (ZIL SLOG) bringt nur was bei sync writes. Also z.B. NFS shares.
Und das auch meistens nur wenn du richtig schnell schreibst. Ist eher so ein nisschen ding.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 12.03.2020 13:49:02

Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
12.03.2020 13:32:02
Der ZFS schreib cache (ZIL SLOG) bringt nur was bei sync writes. Also z.B. NFS shares.
Und das auch meistens nur wenn du richtig schnell schreibst. Ist eher so ein nisschen ding.
OOOKKKK. Das ist also für die Füß im normalen Betrieb? D. h. die meissten und normalen Schreibvorgänge(Ich ändere eine Datei auf der Platte, Mein CMS schreibt eine Datei in mein Webservercacheverzeichnis; Meine Datenbank führt ein Update/Insert aus.(DB-Write müsste doch synchron erfolgen, weil man doch möchte, dass die Daten auch tatsächlich geschrieben wurde, sobald die Transaktion bestätigt wird?)) profitieren davon gar nicht?

Habe gerade noch interessantes Dokument zum Thema ZIL/SLOG gefunden:
https://pure.mpg.de/rest/items/item_240 ... 25/content

Das PDF ist wirklich exzellent. Es ist eine Bachelor Arbeit von Markus Then mit dem Titel:
"ZFS unter Linux - Evaluierung und Optimierung" vom 17.6.2016.

Direkte für mich wichtige Erkenntnisse:
  • ssd als cache und zil bringt keine Leistungssteigerung
  • Die logische Blockgrösse sollte nicht zu klein gewählt werden.
  • Bei dem Einsatz von transparenter Kompression bewirkt die Erhöhung der Blockgrössen deutlich das Kompressionsverhältnis
  • Deduplizierung von ungeeigneten Daten verschlechtert die Performance deutlich.(Und braucht bekanntlich Unmengen an RAM).
  • L2ARC bringt eine gute Verbesserung der Leseleistung.
  • VDEVs sollten max. 8 Festplatten haben.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 12.03.2020 19:57:06

Hier mal ein paar erste Ergebnisse. Es gibt zwischen den einzelnen Läufen interessanterweise nicht unerhebliche Abweichungen, wobei aber das grobe Bild gleich zu bleiben scheint. Die verschiedenen Farben stehen für verschiedene Durchläufe.

Der eine fehlende Balken von btrfs bei sequential read ist ausserhalb des manuell eingestellten Bereiches. Er ist 201.7 MB.

Die zfs-Tests kommen erst am Ende.

Bild
Bild
Bild
Bild
Bild
Bild
Bild
Bild
Zuletzt geändert von heisenberg am 13.03.2020 15:34:38, insgesamt 2-mal geändert.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 13.03.2020 12:26:23

13.3. 12:30

Die Bilder und JSON-Ergebnisdaten liegen unter http://www.megabert.de/downloads/benchmarks/ und werden regelmässig aktualisiert bzw. ergänzt.

Beim nächsten Lauf wird noch echo 3 >/proc/sys/vm/drop_caches und die fio-Option --refill_buffers gesetzt, so dass eventuelle Caching Effekte eliminiert werden. Ausserdem habe ich die Grösse der Testdatei auf 30G angehoben und damit auf ca. das doppelte des Arbeitsspeichers.

wanne
Moderator
Beiträge: 7547
Registriert: 24.05.2010 12:39:42

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von wanne » 13.03.2020 13:46:36

Ich will aus der Geschichte keine Doktorarbeit machen und den Aufwand also in Grenzen halten.
Ernsthaft: Von jemand bei dem das doch einen größeren Teil seiner Master-Arbeit eingenommen hat: Dann lass es sein! Wirklich. Da ist mein voller ernst. Was du machst ist kontraproduktiv.

Hier ein bisschen der Grund warum:
So ganz grundsätzlich. Wichtig bei Storage ist vor allem dein Anwendungsszenario. Der unterschied beim Durchsatz zwischen einem single-Threadded sequential read aufm Dateisystem und realen Anwendungen in VMs übers Netzwerk sind üblicherweise so 2 bis 4 Größenordnungen. Das ist der relevante Teil und der bei dem du unterscheide einfährst da gibt es was zu holen.
Die paar % die du da holst und nur bei jedem 1000 read relevant sind sind verschwendete Zeit.
Deswegen: Bitte male wenigstens Brüche/Unterbrechungen in deine Achsen wenn du nicht bei 0 anfängst. Im allgemeinen halte ich aber das für problematisch (Siehe hier: https://peltiertech.com/broken-y-axis-in-excel-chart/ ) Der Mensch kann der Psychologie einfach nicht entkommen. – Egal wie gut du weißt, dass diese Banken alle etwa gleich groß sind die erwecken den Eindruck, als ob da ein Unterschied sei, der da nicht ist. Die unterscheide zwischen deinen Ergebnissen liegen weit unter der Genauigkeit deiner Messung.
Kurz der Punkt an dem du gerade optimierst ist für sich gesehen irrelevant für das große ganze.

Nochmal grundsätzlich: Single-Threadded Sequential reads sind ne Größe die für 99% der Andwendungen irrelevant sind. Vor allem im Web. Einzig beim Streaming hat sie eine gewisse Berechtigung. Ganz im Gegenteil ist eine tolle Sequential read performence meistens konträr zu den zielen für ein performantes Speichersystem. (Große Blockgrößen machen schnelle sequential writes aber langsamere kleine, die viel häufiger sind. Ineligente Caches bremsen die Latenz sind aber sehr hilfreich für die üblichen Patterns.)
Wenn du dein Ceph mit einem Lustre auf einem 10GbE-HDD-Storagenetwork benchmarkst wirst du bei sequential reads keinen unterschied oder halt Prozente in irgend eine Richtung feststellen. Deine HPC-Omics-Python-Anwendung wird aber vermutlich um den Faktor 10-50 langsamer laufen, weil die Latenz von Cehp halt beschissen ist.
Im allgemeinen gilt: Schneidet ein Storagesystem bei einem Test zu gut ab, ist das eher ein schlechtes Zeichen dafür, dass da zu einseitig auf einen Parameter optimiert ist. Deine Optimierungen auf solche Laborszenarien sind als nicht nur nicht produktiv sondern sogar eher kontraproduktiv.

Deswegen hier ein paar Tipps, wenn du das Benchmark richtig machen willst.
  • Wichtigster Punkt: Teste mit realen Anwendungen die möglichst ähnlich zu denen sind die am Ende laufen.
  • Teste parallelisiert. (Dein Usecase wird es am Ende auch sein.) Wenn auf 10 Websiten in 2VMs von 100 leuten zugegriffen wird, ist das ein ganz anderes Stenario wie wenn ein tester 1000 mal auf reload klickt.
  • Teste im realen Setup. (Mit VM und Netzwerk.)
So schön es wäre jede Komponente für sich Testen geht nicht. Egal welchen Test du weg lässt es wird das Ergebnis um Größenordnungen mehr verändern als die unterschied zwichen deinen Setups. Das dreht das Ergebnis vollständig und unvorhersehbar.

Tipps wenn du dein Storage-Netzwerk schnell bekommen willst (ohne Benchmarks):
  • Achte vor allem auf RDMA. Es ist der Punkt der dir am Ende am meisten Performance holen kann.
  • Finetuning ist am besten in der Virtualisierungsumgebung aufgehoben. Da ist am meisten drin wenn man da an ein Parametern schraubt. Die Dateisysteme selber sind über Jahrzehnte optimiert da ist wenig zu holen. (Esseiden du weißt, dass du einen exremen speziellen Fall hast. Wenn du z.B. oft ls o.ä machst willst du eventuell btrfs nehmen etc.)
  • Auf blocklevel arbeitende Netzwerkprotokolle (iSCSI) sind erfahrungsgemäß deutlich performante als welche die auf Dateien oder Objekten arbeiten (S3, NFS...)
  • Optimiere an der Anwendung statt an der Umgebung PHP-fpm vs. mod-php macht mehr aus als ext4 vs. xfs
  • Nimm keinen Intel Core für einen Storage-Knoten. Im Notfall: Hole dir nen alten Xeon.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 13.03.2020 16:05:18

Hallo Wanne,

auf Deine Beteilligung habe ich gewartet. Sie ist auch in etwa exakt so ausgefallen, wie ich das vermutet habe. Ebenso habe ich erwartet, dass Du hilfreiche Hinweise gibst, wie ich die Tests verbessern kann - was auch eingetreten ist. Danke dafür!

Was ich hilfreich fand, ist das hier:
Teste parallelisiert. (Dein Usecase wird es am Ende auch sein.) Wenn auf 10 Websiten in 2VMs von 100 leuten zugegriffen wird, ist das ein ganz anderes Stenario wie wenn ein tester 1000 mal auf reload klickt.
Ich gehe mal davon aus dass, Du meinst dass ich damit tatsächliche Lasten(z. B. webserver-requests) parallelisiert testen soll?

Ebenso finde ich es hilfreich, was Du zum Thema Netzwerk geschrieben hast, auch wenn das nicht mein Fokus ist aktuell.

Was die Aussage "Es ist nicht sinnvoll einen einzigen Leseprozess zu testen" betrifft, da bin ich bei Dir. Das war jetzt einfach mal ein Test unter vielen. Vielleicht auch, um einfach mal was zu sehen. Ich habe nicht die Vorstellung, dass das irgendwie nützlich ist für das Zielsystem.

Den Wertebereich der obigen Grafiken habe ich angepasst, dass es nun bei 0 anfängt. Ich habe oben nun die Zusatzläufe der RAID-10 Tests entfernt und statt dessen die vom RAID-5 dazu gepackt.
(Große Blockgrößen machen schnelle sequential writes aber langsamere kleine, die viel häufiger sind. Ineligente Caches bremsen die Latenz sind aber sehr hilfreich für die üblichen Patterns.)
Die "üblichen Patterns". Meinst Du damit es erhöht die Geschwindigkeit der üblichen eingesetzten Anwendungen wie: "Webserver" "Datenbank" "Java"

Und auch wenn der wahlfreie Schreibtest mit 1M-Blöcken noch so irrellevant sein mag, dann finde ich doch trotzdem sehr interessant, wenn der RAID-5 Test da nur auf ein Drittel der Werte kommt. Für mich sind das auf jeden Fall wo ich näher hinschauen bzw. weiter testen möchte.

Auf meiner Liste stehen damit jetzt auch parallelisierte Tests mit fio später. Tests mit realen Anwendugen finden später statt.

Ansonsten muss ich mich jetzt erst einmal davon erholen, davon, dass mir jemand gesagt, hat, dass das, was ich tue "kontraproduktiv" ist und dass ich es sein wirklich lassen soll, was mich etwas entmutigt hat. Falls Du weitere Anmerkungen hast, die werde ich dann vielleicht erst ein 1-2 Wochen später bearbeiten. Trotzdem Danke!

wanne
Moderator
Beiträge: 7547
Registriert: 24.05.2010 12:39:42

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von wanne » 13.03.2020 19:59:36

heisenberg hat geschrieben: ↑ zum Beitrag ↑
13.03.2020 16:05:18
Ich gehe mal davon aus dass, Du meinst dass ich damit tatsächliche Lasten(z. B. webserver-requests) parallelisiert testen soll?
Ja.
Und auch wenn der wahlfreie Schreibtest mit 1M-Blöcken noch so irrellevant sein mag, dann finde ich doch trotzdem sehr interessant, wenn der RAID-5 Test da nur auf ein Drittel der Werte kommt.
Na, dass RAID-5 net toll für die Performance ist, kannst du dir merken. Die Frage ist, wie relevant das ist.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
13.03.2020 16:05:18
Die "üblichen Patterns". Meinst Du damit es erhöht die Geschwindigkeit der üblichen eingesetzten Anwendungen wie: "Webserver" "Datenbank" "Java"
Ja vor allem. Und eben auch übers Netzwerk und durch die VM.
Z.B. bei deinem Fall: Wenn dein SW-RAID5-write so stinken lahm ist, dann vermutlich weil der Singlecorspeed von dem i7-2600 da am Ende ist. Wenn du aber eh nur 10GbE dran hängt und du immer mit mindestens zweimal parallel schreibst interessiert dich das nicht mehr. Ein core ist dann schnell genug um die Performance von dem was dein Netzwerk hergibt zu schreiben. Relevanter ist wenn du kein RDMA machst auf einmal wie dick der Busspeed von dem Ding ist und dann schneidet da dein RAID10 mit dem zweite copy plötzlich schlechter ab. (Im Linux-Kernel ist da kein 2. Copy drin und außerdem hast du mit 20GB/s da ordentlich Platz für viele Copys wo anders vielleicht schon in sofern ist die annahme in dem Fall falsch. Aber zumindest eliminiert es den vorherigen Effekt des langsamen RAID5.) Wenn du aber kein tcp-offloading machst ist dein Prozessor eventuell aber sowieso total an der Decke weil er mit tcp entpacken beschäftigt ist. Und plötzlich ist die Rechenleistung von den 4 Kernen das bottleneck und du hast doch wieder ein Problem mit dem rechenintensiven RAID5 weil das dein tcp entpacken ausbremst...
Auf meiner Liste stehen damit jetzt auch parallelisierte Tests mit fio später.
Und mach die Bechmarks mit deutlich kleinen Blocksizes (Die meisten Transaktionen sind <4k).
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 15.03.2020 20:29:36

wanne hat geschrieben: ↑ zum Beitrag ↑
13.03.2020 19:59:36
Na, dass RAID-5 net toll für die Performance ist, kannst du dir merken. Die Frage ist, wie relevant das ist.
Na, dass ist ja gerade der Punkt. Gehört habe ich viel. Es gesehen/getestet zu haben ist etwas anderes.
Auf meiner Liste stehen damit jetzt auch parallelisierte Tests mit fio später.
Und mach die Bechmarks mit deutlich kleinen Blocksizes (Die meisten Transaktionen sind <4k).
Meine Blocksizes in den Tests sind 4k, 64k und 1M. Kleiner als 4k macht wohl kaum Sinn, nachdem die Defaults der Dateisysteme da ja alle wahrscheinlich nicht drunter gehen - vermutlich aus gutem Grund.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 16.03.2020 15:25:36

Die erste Runde ist jetzt durch. Jetzt läuft parallel die 2. Runde mit den obigen neuen Einstellungen. Auch wenn man viel Meßungenauigkeit zugrunde legt, dann finde ich doch trotzdem die Ergebnisse interessant. Die erste Runde ist noch mit nur einem worker thread. Schwankungen der Werte sind auch deutlich zu sehen. Das Gesamtbild bleibt aber deutlich gleich. Ich habe die Werte genommen, mit den eher kleineren Unterschieden.

raid-10 zfs meint dass hier:

Code: Alles auswählen

zpool status

        NAME        STATE     READ WRITE CKSUM
        somepool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            data01  ONLINE       0     0     0
            data02  ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            data03  ONLINE       0     0     0
            data04  ONLINE       0     0     0
Hier mal ein paar Ergebnisse bzgl. der RAIDs:

RAID: random read iops

Code: Alles auswählen

raid5.ext4.random_read.bs_4k.lvm.run_5.json                                        139
raid5.ext4.random_read.bs_4k.raid5.run_5.json                                      147
raid10btr_native.btrfs.random_read.bs_4k.raid10btr_run_5.json                      149
raid10.btrfs.random_read.bs_4k.raid10.run_5.json                                   150
raid10.btrfs.random_read.bs_4k.lvm.run_5.json                                      151
raid10.ext3.random_read.bs_4k.lvm.run_5.json                                       154
raid10.ext4.random_read.bs_4k.lvm.run_5.json                                       154
raid10.ext3.random_read.bs_4k.raid10.run_5.json                                    157
raid5.btrfs.random_read.bs_4k.lvm.run_5.json                                       157
raid10.ext4.random_read.bs_4k.raid10.run_5.json                                    158
raid5.btrfs.random_read.bs_4k.raid5.run_5.json                                     159
raid5.ext3.random_read.bs_4k.lvm.run_5.json                                        160
raid5.ext3.random_read.bs_4k.raid5.run_5.json                                      160
raid10.zfs.random_read.bs_4k.raid10.run_5.json                                     315
raid10.zfs.random_read.bs_4k.compressed.run_5.json                                 356
raidz.zfs.random_read.bs_4k.run_5.json                                             379
raidz.zfs.random_read.bs_4k.compressed.run_5.json                                  383
RAID: random write iops

Code: Alles auswählen

raid5.btrfs.random_write.bs_4k.raid5.run_1.json                                     64
raid5.btrfs.random_write.bs_4k.lvm.run_1.json                                       65
raid5.ext4.random_write.bs_4k.lvm.run_1.json                                        67
raid5.ext4.random_write.bs_4k.raid5.run_1.json                                      68
raid5.ext3.random_write.bs_4k.lvm.run_1.json                                        78
raid5.ext3.random_write.bs_4k.raid5.run_1.json                                      78
raid10.btrfs.random_write.bs_4k.lvm.run_1.json                                     311
raid10.btrfs.random_write.bs_4k.raid10.run_1.json                                  313
raid10btr_native.btrfs.random_write.bs_4k.raid10btr_run_1.json                     395
raid10.ext4.random_write.bs_4k.raid10.run_1.json                                   465
raid10.ext4.random_write.bs_4k.lvm.run_1.json                                      471
raid10.ext3.random_write.bs_4k.lvm.run_1.json                                      559
raid10.ext3.random_write.bs_4k.raid10.run_1.json                                   570
raid10.zfs.random_write.bs_4k.raid10.run_1.json                                    671
raidz.zfs.random_write.bs_4k.run_1.json                                            704
raid10.zfs.random_write.bs_4k.compressed.run_1.json                               2137
raidz.zfs.random_write.bs_4k.compressed.run_1.json                                2512
RAID: Seq. write (aka unnützer showcase) KB/s

Code: Alles auswählen

raid5.btrfs.seq_write.bs_1M.lvm.run_1.json                                       63088
raid5.btrfs.seq_write.bs_1M.raid5.run_1.json                                     63716
raid5.ext4.seq_write.bs_1M.lvm.run_1.json                                        68732
raid5.ext4.seq_write.bs_1M.raid5.run_1.json                                      70874
raid5.ext3.seq_write.bs_1M.lvm.run_1.json                                        73033
raid5.ext3.seq_write.bs_1M.raid5.run_1.json                                      73329
raid10.zfs.seq_write.bs_1M.compressed.run_1.json                                197587
raid10.zfs.seq_write.bs_1M.raid10.run_1.json                                    202224
raid10.btrfs.seq_write.bs_1M.lvm.run_1.json                                     211278
raid10.btrfs.seq_write.bs_1M.raid10.run_1.json                                  217614
raid10.ext3.seq_write.bs_1M.lvm.run_1.json                                      221382
raid10.ext3.seq_write.bs_1M.raid10.run_1.json                                   225781
raid10btr_native.btrfs.seq_write.bs_1M.raid10btr_run_1.json                     244794
raid10.ext4.seq_write.bs_1M.raid10.run_1.json                                   254144
raid10.ext4.seq_write.bs_1M.lvm.run_1.json                                      254237
raidz.zfs.seq_write.bs_1M.compressed.run_1.json                                 258104
raidz.zfs.seq_write.bs_1M.run_1.json                                            276822
RAID: Seq. read (aka unnützer showcase) KB/s

Code: Alles auswählen

raid10.zfs.seq_read.bs_1M.compressed.run_1.json                                 267917
raid10.zfs.seq_read.bs_1M.raid10.run_1.json                                     287920
raid5.ext3.seq_read.bs_1M.raid5.run_1.json                                      291303
raid5.ext4.seq_read.bs_1M.raid5.run_1.json                                      294709
raid10btr_native.btrfs.seq_read.bs_1M.raid10btr_run_1.json                      298280
raid10.btrfs.seq_read.bs_1M.raid10.run_1.json                                   310551
raid10.btrfs.seq_read.bs_1M.lvm.run_1.json                                      317500
raid10.ext3.seq_read.bs_1M.raid10.run_1.json                                    319551
raid5.btrfs.seq_read.bs_1M.raid5.run_1.json                                     319678
raid10.ext3.seq_read.bs_1M.lvm.run_1.json                                       327557
raidz.zfs.seq_read.bs_1M.run_1.json                                             329564
raid5.ext4.seq_read.bs_1M.lvm.run_1.json                                        330541
raid5.ext3.seq_read.bs_1M.lvm.run_1.json                                        335769
raidz.zfs.seq_read.bs_1M.compressed.run_1.json                                  350659
raid10.ext4.seq_read.bs_1M.lvm.run_1.json                                       354560
raid10.ext4.seq_read.bs_1M.raid10.run_1.json                                    355618
raid5.btrfs.seq_read.bs_1M.lvm.run_1.json                                       383868
RAID: Random read 4K Blocksize KB/s

Code: Alles auswählen

raid10btr_native.btrfs.random_read.bs_4k.raid10btr_run_3.json                      579
raid5.ext4.random_read.bs_4k.lvm.run_3.json                                        585
raid10.btrfs.random_read.bs_4k.lvm.run_3.json                                      601
raid5.ext4.random_read.bs_4k.raid5.run_3.json                                      602
raid10.btrfs.random_read.bs_4k.raid10.run_3.json                                   603
raid10.ext4.random_read.bs_4k.lvm.run_3.json                                       618
raid10.ext3.random_read.bs_4k.lvm.run_3.json                                       621
raid10.ext3.random_read.bs_4k.raid10.run_3.json                                    625
raid10.ext4.random_read.bs_4k.raid10.run_3.json                                    629
raid5.btrfs.random_read.bs_4k.lvm.run_3.json                                       629
raid5.btrfs.random_read.bs_4k.raid5.run_3.json                                     633
raid5.ext3.random_read.bs_4k.lvm.run_3.json                                        633
raid5.ext3.random_read.bs_4k.raid5.run_3.json                                      633
raidz.zfs.random_read.bs_4k.compressed.run_3.json                                 1595
raidz.zfs.random_read.bs_4k.run_3.json                                            1635
raid10.zfs.random_read.bs_4k.raid10.run_3.json                                    1746
raid10.zfs.random_read.bs_4k.compressed.run_3.json                                1893
RAID: Random write 4K Blocksize KB/s

Code: Alles auswählen

raid5.btrfs.random_write.bs_4k.raid5.run_1.json                                    257
raid5.btrfs.random_write.bs_4k.lvm.run_1.json                                      258
raid5.ext4.random_write.bs_4k.lvm.run_1.json                                       268
raid5.ext4.random_write.bs_4k.raid5.run_1.json                                     270
raid5.ext3.random_write.bs_4k.lvm.run_1.json                                       312
raid5.ext3.random_write.bs_4k.raid5.run_1.json                                     312
raid10.btrfs.random_write.bs_4k.lvm.run_1.json                                    1245
raid10.btrfs.random_write.bs_4k.raid10.run_1.json                                 1250
raid10btr_native.btrfs.random_write.bs_4k.raid10btr_run_1.json                    1581
raid10.ext4.random_write.bs_4k.raid10.run_1.json                                  1858
raid10.ext4.random_write.bs_4k.lvm.run_1.json                                     1884
raid10.ext3.random_write.bs_4k.lvm.run_1.json                                     2234
raid10.ext3.random_write.bs_4k.raid10.run_1.json                                  2279
raid10.zfs.random_write.bs_4k.raid10.run_1.json                                   2683
raidz.zfs.random_write.bs_4k.run_1.json                                           2814
raid10.zfs.random_write.bs_4k.compressed.run_1.json                               8546
raidz.zfs.random_write.bs_4k.compressed.run_1.json                               10049

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 17.03.2020 15:20:48

wanne hat geschrieben:Nimm keinen Intel Core für einen Storage-Knoten. Im Notfall: Hole dir nen alten Xeon.
Kannst Du das näher erläutern?

wanne
Moderator
Beiträge: 7547
Registriert: 24.05.2010 12:39:42

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von wanne » 17.03.2020 15:57:27

heisenberg hat geschrieben: ↑ zum Beitrag ↑
17.03.2020 15:20:48
Kannst Du das näher erläutern?
Erfahrung. Speicherintensives Zeug mögen die Intel-Cores nicht. Ich nehme an, dass das an den weniger Memory-Lanes liegt. Das ist wie die AMDs keine IPC ab können.
Na, dass ist ja gerade der Punkt. Gehört habe ich viel. Es gesehen/getestet zu haben ist etwas anderes.
Wie gesagt: Das ding ist halt vor allem, dass ich mich gegen die Schlussfolgerung stäube. Ein RAID10 ist dafür deutlich teurer. – Die frage ist was es dir bringt. Sobald dein Bottleneck wo anders hängt ist es Geld zum Fenster raus geschmissen.
Ich finde eigentlich dass gerade heute RIAD5 oder 6 wieder attraktiver sind. Die CPU kann oft vergleichsweise billig durch zwei ersetzt werden (z.B. durch zwei kleinere Storageknoten statt einem großen). Alternativ bist du meistens besser beraten, wenn du das Geld, dass du durch mehr Netto vom Brutto sparst in bessere Netzwerkkarten investierst.
Wie gesagt: Kann dein Netzwerk tcp-offloading und RDMA entlastet das dein CPU extrem massiv. Dann kannst du dir eventuell dafür ein CPU-Intensiveres RAID6 leisten und Platten sparen.

Während es bei CPU-Software-Optimierungen meist wirklich schneller vs. langsamer gibt, sind bei Storrage fast alle Optimierungen Verschiebungen von A nach B. Ob das sinnvoll ist, hängt vor allem davon ab, ob dein Bottleneck bei A oder B liegt.
Wie gesagt: Das beste Beispiel finde ich stripe-Sizes: Je größer desto schneller werden Sequential reads aber desto langsamer kurze random-Reads. Für RAID0 (bzw. RAID10) gilt dann Optimum für sequential ist unendlich Optimum für random ist 1. (Also ein RAID1 statt 10.) Es gibt da kein objektives Optimum. Wo das Liegt ist einzig und alleine Abhängig davon wie sich deine Zugriffe verteilen.
Meine Blocksizes in den Tests sind 4k, 64k und 1M. Kleiner als 4k macht wohl kaum Sinn, nachdem die Defaults der Dateisysteme da ja alle wahrscheinlich nicht drunter gehen - vermutlich aus gutem Grund.
Das heißt nicht, dass da massiv kleinere von oben kommen. Z.B. steckt das ext4 oft deutlich besser weg als ext3 indem es mehrere Daten in einen Block haut. So führt ein write auf einem ext4 zu deutlich weniger writes auf der Platte als ext3. Testest du nur mit mehr als 4k hat es keine Chance mehr zu optimieren.
Ähnliches gilt für Readahead-Features. Dateisysteme die wie ZFS gut dabei sind vorherzusagen was als nächstes gelesen wird, können diese Stärke bei deinen Tests nicht ausspielen. Bei vollständig random ist nichts vorherzusagen. Bei vollständig sequentiell bekommt das jeder noch so doofe Algorithmus hin.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 17.03.2020 17:37:37

wanne hat geschrieben:Ein RAID10 ist dafür deutlich teurer.
Auch wenn mein Budget nicht so wirklich dicke ist, würde ich sagen dass Festplattenplatz jetzt da doch eher nicht so der Faktor ist. Eine 4 TB Platte ist preislich jetzt gar nicht mal so der Unterschied zu einer 8 TB Platte. Ich selber bin jetzt eher so mit Kleinsystemen(5-50 TB) unterwegs. Da reissen grosse Mengen an RAM und moderne many-core-CPUs schon deutlich grössere Löcher in den Geldbeutel.(Mein Ziel ist lokales Storage! D. h. eine CPU für Virtualisierung und Storage) Deswegen bin ich der Meinung dass die 50% Redundanz von RAID-10 da jetzt nicht so die Rolle spielen. Ein RAID-6 hat natürlich eine schöne höhere Robustheit(2 Festplatten).

Auf der anderen Seite hast Du natürlich Recht: Wenn ich die Wahnsinns-Schreibperformance halt einfach nicht brauche, was spricht gegen RAID-5?

Im Übrigen:

Vielen Dank für Deine konkreten Ausführungen! Sehr hilfreich für mich und wahrscheinlich auch für Andere. Wenn die Bewertung da wegbliebe(Das ist alles total kontraproduktiv!) und nur die Argumente da sind, dann kommt vermutlich jeder zu ähnlichen Schlüssen. Ich selbst finde es wesentlich angenehmer und ohne Fremdwertung bleibt mir meine Motivation erhalten!

wanne
Moderator
Beiträge: 7547
Registriert: 24.05.2010 12:39:42

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von wanne » 18.03.2020 17:36:11

heisenberg hat geschrieben: ↑ zum Beitrag ↑
17.03.2020 17:37:37
Ich selber bin jetzt eher so mit Kleinsystemen(5-50 TB) unterwegs.
[…]
Mein Ziel ist lokales Storage! D. h. eine CPU für Virtualisierung und Storage) Deswegen bin ich der Meinung dass die 50% Redundanz von RAID-10 da jetzt nicht so die Rolle spielen. Ein RAID-6 hat natürlich eine schöne höhere Robustheit(2 Festplatten).
OK. Da habe ich jetzt vielleicht ein bisschen falsche Vorstellungen gehabt. Da macht das ganze schon deutlich mehr Sinn. Da wird das ganze deutlich relevanter. Trotzdem würde ich eher auch ein Benchmark setzen, dass durch MySQL oder so läuft.
Daneben kann man am KVM für solche Setups ne menge rumoptimieren oder verschlimmbessern.
Daneben bringt es viel die Intel-Security-Patches nicht einzuspielen/abschalten/Kernel ohne verwenden. Auf der anderen Seite sind sie aber genau für solche Setups relevant. Für einen Virtualisierten Webserver willst du die schon haben.
Ein RAID-6 hat natürlich eine schöne höhere Robustheit(2 Festplatten).
[…]
Wenn ich die Wahnsinns-Schreibperformance halt einfach nicht brauche, was spricht gegen RAID-5?
Raid 5 ist für mich so ne Sache. Ich hab so oft platten beim rebuild gestorben ist... Problem bei einem Raid-5 ist halt, dass der fürs rebuild alle Platten vollständig lesen muss – Entsprechend groß ist die Wahrscheinlichkeit, dass da eine bei drauf geht.
Auf der anderen Seite ist die Kosteneinsparung verlockend. Privat habe ich das gerne weil die Daten entweder unwichtig sind oder ein Backup haben. Beruflich, wo man HA haben wil ist das eine andere Sache.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
heisenberg
Beiträge: 4123
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von heisenberg » 18.03.2020 17:53:18

Raid 5 ist für mich so ne Sache. Ich hab so oft gesehen, dass eine der platten beim rebuild gestorben ist...
Ich muss sagen, dass ich da bis auf einen Fall eigentlich immer gut gefahren bin mit einem entsprechenden Monitoring bei einem Gesamt-Pool von ca. 100 Platten(Natürlich sehr wenige RAID-5). Der eine erste Fall war letzte Woche und war mehr oder weniger selbst verschuldet, durch diese Arbeitsweise in diesem Fall:
Was? Die Platte zickt rum? Die können wir nochmal entfernen und wiede reinnehmen, das kann die ab.
Und jetzt waren 2 Platten teildefekt und mit Glück konnte das Dateisystem mit Daten - aber auch nur in einem undefinierten Konsistenzzustand - wiederhergestellt werden. Da überlege ich schon, ob ich bei bestimmten Systemen lieber 2-Platten-Redundanz nehme.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Speicher-Benchmarks für Virtualisierungshosts

Beitrag von Lord_Carlos » 18.03.2020 22:06:23

wanne hat geschrieben: ↑ zum Beitrag ↑
18.03.2020 17:36:11
Ich hab so oft platten beim rebuild gestorben ist...
Wenn ich fragen darf, hattest du regelmaessige scrubs an?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Antworten