Setup für Ceph

[aPollO]

Guten Tag,

ich möchte gerne ein Cluster aufbauen. Aktuell hab ich nur ein Single Node Setup. Problem ist natürlich, sobald etwas an dieser einen Hardware ist bin ich offline. Mein Ziel wäre es daher die Verfügbarkeit zu erhöhen Richtung HA. Mit einem kurzzeitigen Ausfall kann ich Leben, aber ich möchte mein System gerne so, dass ich binnen kurzer Zeit wieder voll verfügbar bin.

Aktueller Node:

• Supermicro Strato 2900 (Supermicro X10DRi)
• 2x Intel Xeon E5-2630 v3 (8-Core)
• 128GB regist. ECC DDR4 PC2133 (es sind 8x8 und 4x16GB verbaut)
• Onboard NIC
• Adaptec 81605ZQ
• RAID5 6x600GB SAS 2 10.000rpm als Storage für VMs
• RAID5 3x1TB Samsung 860 Evo als Storage für VMs
• RAID1 2x240 Samsung 845DC als Cache für das RAID5
• RIAD1 2x250GB Samsung 860 Evo fürs System

So natürlich ist das jetzt nicht optimal, vor allem da die beiden RAID5 jeweils als physical volume ein und der selben volume group zugewiesen sind (diejenigen die jetzt Haarausfall bekommen, bitte weitergehen).

Ich möchte jetzt gerne min. mal 2 neue Nodes kaufen und das von vorne herein mit vernünftiger Hardware planen. Sodass ich dann erstmal mit dem einen vorhandenen und den zwei neuen Nodes auf ein 3 Node Setup komme. ggf. muss ich dazu auch den ersten noch umbauen.

Meine Vorstellung geht in Richtung

• Strato 2940-X2HF5
• 2 x Intel Xeon 4216, 2.1 GHz 16-Core
• 128GB RAM
• 1GbE Onboard NIC für Management und Admin
• 10GbE NIC für Cluster Kommunikation
• vernünftigen HBA, weiß noch nicht so recht was
• 2 x System SSD, Software RAID 1, 6G/s
• 6 x 1TB Datacenter SSD, 6G/s

Ich plane also mit 6TB größe für das Ceph Cluster.

Darauf laufen sollen ~40 VMs (auf dem einen Node sind es derzeit 33). Ich habe insgesamt ca. 100 VMs wovon aber ein großer Teil nur bei Bedarf hochgefahren wird. Meine Anforderung wäre also eher gute I/O-Performance und viel RAM und nicht so CPU lastiges Zeugs. Ich weiß aber nicht wieviel Ceph dann schon an CPU und Memory schluckt.

RAM Auslastung bin ich derzeit schon recht am Limit mit ~85% Auslastung. Das soll auf jeden Fall wieder weniger werden, wenn ich 2 weitere Nodes mit jeweils auch 128GB Habe wird das ja aber auf sicher so sein. Vor allem wenn ich nur Nodes dazu schieben muss wenn es eng wird.

Ich bin echt recht unerfahren was sie die Hardwareauswahl angeht und bin mir nicht sicher ob ich da mit Kanonen auf Spatzen schieße. Wenn ich mir das Performance Dahsboard anschaue, was ich mal angehängt habe, dann ist mein Bottlneck ja echt nur der RAM. CPU und I/O sind eher mäßig ausgelastet. Sollte ich vielleicht eine kleinere CPU wählen und auf SAS HDDs statt SSDs setzen?

Hoffentlich kann Jemand was damit anfangen und mir einen Tipp geben. Wäre auf jeden Fall sehr verbunden.

 

[Alwin]

Schau mal in den Thread rein. Dort ist auch das Paper aus 2018 verlinkt.
https://forum.proxmox.com/threads/proxmox-ve-ceph-benchmark-2020-09-hyper-converged-with-nvme.76516/

Ansonsten kann ich noch unsere und Ceph's docku empfehlen.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html
https://docs.ceph.com/en/latest/start/hardware-recommendations/

 

[aPollO]

Schau mal in den Thread rein. Dort ist auch das Paper aus 2018 verlinkt.
https://forum.proxmox.com/threads/proxmox-ve-ceph-benchmark-2020-09-hyper-converged-with-nvme.76516/

Ansonsten kann ich noch unsere und Ceph's docku empfehlen.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html
https://docs.ceph.com/en/latest/start/hardware-recommendations/

Vielen Dank,

ja die unteren beiden Links hab ich mir schon angeschaut. Das Papier mit den Benchmarks tatsächlich noch nicht. Ich hol mir jetzt mal ein paar Angebote ein mit den Infos und schaue mal was ins Budget passt.

 

[aPollO]

Ich hab mir jetzt was zusammen gestellt. Vielleicht will das noch mal Jemand anschauen und beurteilen. Aber ich denke anhand der Infos die ich mir angeschaut habe, bin ich da hoffentlich auf nem guten Pfad.

• 2x Intel Xeon Silber 4214R (12 Kerner, 2,4Ghz)
• 128 GB regist. ECC RAM PC2933 (4x32)
• Supermicro X11DPi-N (Intel C622) Mainbaord
• als SATA Controller den On-Board (SATA 3, 14-Kanal)
• 2x 240GB Samsung PM883 fürs System
• 2x 3,84 TB Samsung PM1773 NVMe U.2 für Storage
• 1. Onboard Gigabit NIC für Management/Admin
• 2. Onboard Gigabit NIC für Cluster Kommnikation
• Intel XL710QDA2 Dual 40 Gbit Controller über PCIe mit 40G QSFP+ Modulen für Ceph

Gibt's da grobe Fehler oder hab ich irgendwas nicht bedacht? Nachdem ich mir die Benchmarks angeschaut habe, glaube ich wird das super performen für meine Bedürfnisse.

 

[Alwin]

2x Intel Xeon Silber 4214R (12 Kerner, 2,4Ghz)

Persönlich würde ich auf einen Epyc setzen. Höherer Base-Takt und mehr PCIe Lanes. Beides good für hyper-konvergente Setups. Auch ist mit NUMA und den beiden Sockets, das Latenz optimieren schwerer. Da es durchaus sein kann, dass das Netzwerk und die NVMe nicht auf der selben Node oder Socket stecken.

• Intel XL710QDA2 Dual 40 Gbit Controller über PCIe mit 40G QSFP+ Modulen für Ceph

Zum einen zu langsam und zum zweiten zu wenig Bandbreite. Wenn die PM1733 auch nur die hälfte beim Lesen schaft, dann sind das ~29 Gb/s. Und es kann parallel gelesen werden. Lieber in mindestens 25 GbE investieren. Die hat auch die niedriger Latenz, da 40 GbE, 4x10 sind.

Der Client Traffic ist nicht aufgeführt, wo würde dieser laufen?

 

[aPollO]

Hallo Alwin,

danke für das Feedback. Finde es sehr stark, dass du mir hier gut mit Empfehlungen hilft, vor allem da ein Single-CPU System auch noch weniger Subskription Gebühren für euch bedeuten würde. Das mit der Latenz und den unterschiedlichen PCIe Lanes leuchtet mir aber natürlich ein. Das mit dem Netzwerk Controller hab ich tatsächlich nicht weiter hinterfragt, 40G klang für mich besser als 25G.

Ich werde nochmal schauen eine zweite Basis mit AMD zusammen zu stellen und mir da ein Angebot einzuholen. Preislich liegt das Setup von oben voll im Rahmen.

Der Client Traffic ist nicht aufgeführt, wo würde dieser laufen?

Oh natürlich, der würde auch über das Management/Admin NIC laufen. Das ist in der Tat recht wenig Traffic im Vergleich zu der Hardware. Hauptsächlich geht es da um Remote-Desktop Verbindung via RDP und Spice/noVNC und um Geräteanbindungen im mit Volumen KByte Bereich pro Tag. Außerdem einige Webserver inkl. entsprechender Anwendung und Datenbanken. Aber nichts hoch performantes. Also keine tausenden User oder hohe Aufrufe, daher auch die geringe CPU Last schätze ich mal. Das ganze Netzwerk in dem Rack des Clusters wäre eh nur mit 1G an die Außenwelt angebunden bzw. mit 20G an unser Office. Denke daher damit kommen wir klar alles über das eine NIC zu machen.

 

[Alwin]

danke für das Feedback. Finde es sehr stark, dass du mir hier gut mit Empfehlungen hilft, vor allem da ein Single-CPU System auch noch weniger Subskription Gebühren für euch bedeuten würde.

Es ist ja auch nicht geholfen, wenn wir den Sachverhalt NACH dem Kauf im Enterprise Support erörtern.

Oh natürlich, der würde auch über das Management/Admin NIC laufen. Das ist in der Tat recht wenig Traffic im Vergleich zu der Hardware. Hauptsächlich geht es da um Remote-Desktop Verbindung via RDP und Spice/noVNC und um Geräteanbindungen im mit Volumen KByte Bereich pro Tag. Außerdem einige Webserver inkl. entsprechender Anwendung und Datenbanken. Aber nichts hoch performantes. Also keine tausenden User oder hohe Aufrufe, daher auch die geringe CPU Last schätze ich mal. Das ganze Netzwerk in dem Rack des Clusters wäre eh nur mit 1G an die Außenwelt angebunden bzw. mit 20G an unser Office. Denke daher damit kommen wir klar alles über das eine NIC zu machen.

Naja, nicht zu unterschätzen. Backup und Live Migration laufen da auch über das Management Netz. Da würde sich sicherlich eine weitere 10/25 GbE Karte rentieren. Speziell bei der Live Migration, da dort der RAM gesynced werden muss und bei großen VMs (viele Änderungen im RAM) sollte das schon mindesten 10 GbE sein, um fertig zu werden.

 

[aPollO]

So der Vollständigkeit halber dann jetzt das Setup was so wohl bestellt wird:

• Supermicro H12SSL-NT Mainboard
• 1 x AMD Epyc 7402P 24 Kerner mit 2.8Ghz
• 128GB reg. ECC RAM mit 3200MHz
• 2 x 240GB PM883 von Samsung
• 2 x 3.84TB Samsung PM1733 NVMe U.2
• Onboard SATA Controller mit 8 Kanälen
• Onboard NVMe U.2 Controller mit 2 Knälen
• das Onboard NIC ist Dual 10 GbE
• zusätzlich für Ceph Intel XXV710DA2 Dual 25GbE Controller

Bin sehr gespannt das ganze dann in Aktion zu sehen und hoffe das keine groben Schnitzer bei sind

 

[ph0x]

Überleg dir, ob du für das System nicht lieber die SM883 verwendest, die dürfte mit dem Proxmox-typischen hochfrequenten Schreiben kleiner Dateien besser klarkommen als die PM883.

 

[Alwin]

zusätzlich für Ceph Intel XXV710DA2 Dual 25GbE Controller

Wo läuft den das Corosync im neuen Setup? Ich hoffe du hast da noch 1 GbE in der Tasche, da ich annehme, die 10 GbE sind auch in einem Bond.

 

[aPollO]

Wo läuft den das Corosync im neuen Setup? Ich hoffe du hast da noch 1 GbE in der Tasche, da ich annehme, die 10 GbE sind auch in einem Bond.

Ich weiß ihr empfehlt in den Docs auch eine dedizierte NIC für den cluster traffic. Reicht da 1GbE?

Am liebsten würde ich das 10GbE als meshed Netzwerk aufbauen und auf einen seperaten 10GbE Switch verzichten. Dann brauche ich auf jeden Fall sowieso noch ein dediziertes 1GbE NIC für den Traffic nach draußen. Wäre das denn denkbar? Also 2x25GbE für Ceph, 2x10GbE für Migration und Co., 1x 1GbE für Corosync und 1x1GbE für Traffic ins Netz? Oder ist das blödsinn?

 

[Alwin]

Ich weiß ihr empfehlt in den Docs auch eine dedizierte NIC für den cluster traffic. Reicht da 1GbE?

Ja eh, darum schreib ich's ja. Die Latenz ist ausreichend gering bei 1 GbE.

Am liebsten würde ich das 10GbE als meshed Netzwerk aufbauen und auf einen seperaten 10GbE Switch verzichten. Dann brauche ich auf jeden Fall sowieso noch ein dediziertes 1GbE NIC für den Traffic nach draußen. Wäre das denn denkbar? Also 2x25GbE für Ceph, 2x10GbE für Migration und Co., 1x 1GbE für Corosync und 1x1GbE für Traffic ins Netz? Oder ist das blödsinn?

Na welche Links möchtest du redundant aufbauen? Ich nehme mal an, der Client Traffic möchte auch gerne redundant sein. Wäre ja auch blöd, wenn der Switch ausfällt und dann niemand mehr die Services benutzen kann, obwohl das Cluster an sich einwandfrei läuft.

 

[aPollO]

Na welche Links möchtest du redundant aufbauen? Ich nehme mal an, der Client Traffic möchte auch gerne redundant sein. Wäre ja auch blöd, wenn der Switch ausfällt und dann niemand mehr die Services benutzen kann, obwohl das Cluster an sich einwandfrei läuft.

Tatsächlich hätte ich das Netzwerk erstmal nicht redundant ausgelegt. Das würde vielleicht später noch kommen. Derzeit gibts an den Switch nur eine Fiber, sodass wenn der Switch ausfällt eh alles duster wäre. Das ganze ist aber nicht sooooo tragisch, da alles in einem Datacenter steht wo jederzeit ein Techniker kurz den Switch wechseln kann, was ja in relativ kurzer Zeit zu machen ist.
Die VMs alle aus einem Backup auf einen anderen Node einzuspielen, weil man mit lokalem Storage arbeitet ist da denk ich wesentlich langwieriger beim Ausfall eines Nodes.

Aber ja Ziel wäre es schon in der mittelfristigen Zukunft alles redundant zu haben. Ich denke daher wäre es am schlausten jetzt direkt die benötigten NICs einzubauen, auch wenn man noch nicht alle belegt.

 

[Ingo S]

Manchmal hilft es, sich für die verschiedenen Anforderungsebenen eine Grafik aufzuzeichnen.

• Wie soll das Corosync Netzwerk aufgebaut sein
• Wie soll das Cep Netz aufgebaut sein
• Wie soll der Cluster mit der Welt Kommunizieren
• Welche Ceph-Pools sollen auf welchen Datenträgern liegen
• Wie viel Speicher brauche ich auf diesen Pools und welche Anforderungen gibt es (IO, Durchsatz etc)

Es kann sehr teuer und kompliziert werden, wenn man nachträglich feststellt, das die Cluster Struktur an einer Stelle nicht so ist wie man sich das vorgestellt hat, oder eine kritische Anforderung übersehen wurde.

 

[aPollO]

Altes Thema. Ich hab inzwischen meine Hardware die auch schon grundlegend läuft. Daher wollte ich hier einfach mal ein Status Update liefern für mich und die Nachtwelt wie ich das ganze jetzt aufgebaut habe.


Das Netzwerk

Für Ceph ist nach dem Vorbild im Wiki als Mesh Netzwerk entstanden Full Mesh Network for Ceph Server. Hier kommen pro Server je zwei 25G NICs zum Einsatz.
Das Cluster Netzwerk ist nach dem selben Design gestaltet. Wobei ich hier insgesamt vier Ringe definiert habe wovon das Ceph netzwerk der letzte ist und das dedizierte Cluster Netzwerk der erste.

#######
# Ceph network 25G Fibre
#######
                    +-----------------+
                    |      Node1      |
                    +-----------------+
                    |enp1s0f0|enp1s0f1|
                    +--+------------+-+
                       |            |
        +--------+     |            |    +--------+
+-------+enp1s0f0+-----------+      +----+enp1s0f0+-------+
| Node3 +--------+     |     |           +--------+ Node2 |
+-------+enp1s0f1+-----+     +-----------+enp1s0f1+-------+
        +--------+                       +--------+
        

Node01
    inet 10.15.15.50/24 scope global enp1s0f0
    inet 10.15.15.50/24 scope global enp1s0f1
    
Node02
    inet 10.15.15.51/24 scope global enp1s0f0
    inet 10.15.15.51/24 scope global enp1s0f1

Node03
    inet 10.15.15.52/24 scope global enp1s0f0
    inet 10.15.15.52/24 scope global enp1s0f1

#######
# Cluster network 1G Copper
#######
                    +-------------------+
                    |       Node1       |
                    +-------------------+
                    |enp68s0f0|enp68s0f1|
                    +--+--------------+-+
                        |            |
        +---------+     |            |    +---------+
+-------+enp68s0f0+-----------+      +----+enp68s0f0+-------+
| Node3 +---------+     |     |           +---------+ Node2 |
+-------+enp68s0f1+-----+     +-----------+enp68s0f1+-------+
        +---------+                       +---------+
        

Node01
    inet 10.14.14.50/24 scope global enp68s0f0
    inet 10.14.14.50/24 scope global enp68s0f1
    
Node02
    inet 10.14.14.51/24 scope global enp68s0f0
    inet 10.14.14.51/24 scope global enp68s0f1

Node03
    inet 10.14.14.52/24 scope global enp68s0f0
    inet 10.14.14.52/24 scope global enp68s0f1

Der Zugriff auf die Web-GUI, Monitoring und Aussenanbindung der VMs in die übrige Welt passiert über dieses 10G Netzwerk. Hier gibt es 10.10.10.0/24 für Management, Anbindung der VMs ins LAN u.s.w. und auch diverse VLANs für VMs in anderen Subnetzen. Das 10.10.30.0/24 ist nur für Backups. Hier läuft der Traffic der Backup Software auf den Clients als auch das Proxmox Backup drüber. Beides jeweils getrennt auf verschiedenen NICs und Switches. Ich könnte aber im Fehlerfall relativ leicht beide Netze auf ein NIC oder ein Switch umziehen.

#######
# Management network 10G Copper
#######


+---------------+       +---------------+       +---------------+
|     Node01    |       |     Node02    |       |     Node03    |
+---------------+       +---------------+       +---------------+
| vmbr0 | vmbr1 |       | vmbr0 | vmbr1 |       | vmbr0 | vmbr1 |
+---------------+       +---------------+       +---------------+
|eno1np0|eno2np1|       |eno1np0|eno2np1|       |eno1np0|eno2np1|
+---+-------+---+       +---+-------+---+       +---+-------+---+
    |       |               |       |               |       |
    |       |            +--|-------|---------------+       |   
    |       |            |  |       |                       |
    |       +----------------------------+       +----------+ 
    |                    |  |       |    |       |
    +------------+   -------+       +----|---+   |
                 |   |   |               |   |   |
              +--+---+---+-+          +--+---+---+-+
              |  Switch 1  |          |  Switch 2  |
              +------------+          +------------+

Node01
    inet 10.10.10.11/24 scope global vmbr0
    inet 10.10.30.11/24 scope global vmbr1
    
Node02
    inet 10.10.10.12/24 scope global vmbr0
    inet 10.10.30.12/24 scope global vmbr1

Node03
    inet 10.10.10.12/24 scope global vmbr0
    inet 10.10.30.12/24 scope global vmbr1

Ceph Storage

Die SSDs sind ausschließlich für Ceph. Das System und der lokale Storage liegt auf Samsung SM883 mit 240GB. Weiß noch nicht ob ich da ein MDADM Raid draus mache oder BTRFS. Aber egal es geht um Ceph.

# Pro Server je 2x
NVMe Model:      Samsung PM1733 U.2 SSD
Grösse:          3.49 TiB
 
+---------------+       +---------------+       +---------------+
|     Node01    |       |     Node02    |       |     Node03    |
+---------------+       +---------------+       +---------------+
| nvme0 | nvme1 |       | nvme0 | nvme1 |       | nvme0 | nvme1 |
+---------------+       +---------------+       +---------------+
| osd.0 | osd.1 |       | osd.2 | osd.3 |       | osd.4 | osd.5 |
+---------------+       +---------------+       +---------------+

Ich habe derzeit einen Pool mit Size 3 (min. 2) mit PGs 128. Ich weiß nicht ob es sinnvoll ist noch mehr Pool anzulegen. Derzeit sehe ich da noch kein Usecase noch mehr Pools anzulegen aber vielleicht kommt das noch. Ich hab also insgesamt ~21TB Platz wovon ich theoretisch ~7TB für VMs nutzen kann.

Schnell scheints bisher auch zu sein. Das ist gemessen aus einer VM (ohne andere laufende VMs)

dev/sda:
 Timing O_DIRECT cached reads:   3454 MB in  2.00 seconds = 1726.77 MB/sec
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Timing O_DIRECT disk reads: 2720 MB in  3.00 seconds = 906.49 MB/sec

Benchmarks

Zum Schluss noch ein paar Zahlen

root@node01 ~ # rados bench -p pool0 10 write --no-cleanup
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 10 seconds or 0 objects
Object prefix: benchmark_data_node01_99879
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      16       547       531   2123.87      2124   0.0273965   0.0297859
    2      16      1093      1077   2153.81      2184   0.0325728   0.0294959
    3      16      1651      1635   2179.78      2232   0.0300456   0.0292923
    4      16      2205      2189   2188.75      2216   0.0199497   0.0291435
    5      16      2707      2691   2152.52      2008   0.0428279    0.029605
    6      16      3251      3235   2156.39      2176   0.0273715   0.0296179
    7      16      3793      3777      2158      2168   0.0363006   0.0295639
    8      16      4353      4337   2168.21      2240   0.0304778   0.0294561
    9      16      4924      4908   2181.04      2284   0.0201252   0.0292684
   10      16      5476      5460   2183.71      2208   0.0263645   0.0292791
Total time run:         10.0246
Total writes made:      5476
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     2185.02
Stddev Bandwidth:       75.9649
Max bandwidth (MB/sec): 2284
Min bandwidth (MB/sec): 2008
Average IOPS:           546
Stddev IOPS:            18.9912
Max IOPS:               571
Min IOPS:               502
Average Latency(s):     0.0292616
Stddev Latency(s):      0.0106732
Max latency(s):         0.0815818
Min latency(s):         0.00856472


root@node01 ~ # rados bench -p pool0 10 rand
hints = 1
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      15       578       563   2251.43      2252    0.017055    0.027506
    2      16      1113      1097    2193.6      2136   0.0738126   0.0283508
    3      16      1661      1645      2193      2192   0.0809692   0.0284216
    4      16      2217      2201   2200.69      2224   0.0187021   0.0284125
    5      16      2794      2778   2222.11      2308  0.00552757   0.0281513
    6      16      3322      3306   2203.72      2112   0.0823468   0.0284435
    7      16      3848      3832   2189.44      2104   0.0702253   0.0287089
    8      16      4378      4362   2180.73      2120   0.0701237   0.0288366
    9      15      4903      4888   2172.13      2104   0.0358011   0.0288974
   10      16      5440      5424    2169.3      2144  0.00636421    0.028975
Total time run:       10.05
Total reads made:     5440
Read size:            4194304
Object size:          4194304
Bandwidth (MB/sec):   2165.18
Average IOPS:         541
Stddev IOPS:          17.7901
Max IOPS:             577
Min IOPS:             526
Average Latency(s):   0.0290348
Max latency(s):       0.1332
Min latency(s):       0.00221967


root@node01 ~ # rados bench -p pool0 10 seq
hints = 1
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      16       549       533   2131.71      2132  0.00304874   0.0287066
    2      16      1115      1099    2197.7      2264   0.0293499   0.0284801
    3      16      1659      1643   2190.39      2176  0.00534458   0.0283948
    4      16      2182      2166   2165.73      2092    0.137089   0.0288472
    5      16      2679      2663   2130.14      1988   0.0900982   0.0293366
    6      16      3223      3207   2137.75      2176  0.00455966   0.0292599
    7      15      3764      3749   2142.04      2168   0.0850453   0.0292922
    8      16      4300      4284   2141.76      2140   0.0285191   0.0293248
    9      16      4871      4855   2157.54      2284   0.0455043   0.0291581
   10      15      5420      5405   2161.76      2200  0.00832433   0.0290461
Total time run:       10.0389
Total reads made:     5420
Read size:            4194304
Object size:          4194304
Bandwidth (MB/sec):   2159.59
Average IOPS:         539
Stddev IOPS:          21.0357
Max IOPS:             571
Min IOPS:             497
Average Latency(s):   0.0291092
Max latency(s):       0.156685
Min latency(s):       0.00304874

Vielleicht schaut sich das ja Jemand an und gibt mal seine Meinung zu den Pools ab oder ob sonst noch irgendwo ein grober Fallstrick lauert. Ich denke für meine Zwecke ist das super geeignet. Aber da es derzeit noch nicht produktiv ist kann ich noch keine Erfahrung geben. IP-Adressen und Co die relevant sind habe ich natürlich pseudonymisiert.