Migration Performance

[Falk R.]

Hallo zusammen,

gibt es irgendwo eine Limitierung des Migrationsprozess?
Ich habe derzeit aktuelle Hardware zum testen, da sind Intel 810 - 100GBit NICs drin. Ich kann mit iperf die 100GBit auch voll auslasten, aber bei Migrationen gehen da genau 1,13 GiB/s drüber (also 10 GBit).
Kann ich irgendwo etwas einstellen oder nachschauen?

Viele Grüße
Falk

 

[Falk R.]

Ich habe auch mal eine ZFS Replikation einer VM eingerichtet, auch da max. 10GBit Durchsatz auf der NIC. Disks langweilen sich aber noch.

 

[itNGO]

Welche CPU im HOST?
Welche Speicherriegel/Geschwindigkeit?
iPERF ist ein synthetic Benchmark..... das sagt ja nur sehr bedingt etwas über das tatsächlich erreichbare aus....

 

[itNGO]

Und mach doch mal 2 oder 4 Migrationen parallel..... summieren die auf 10GBit oder kommulieren die auf 35 bis 40GBit?

 

[Falk R.]

Hi, im Host sind je 2x Xeon Gold 6346.
Die Hosts hatte ich vorher bei einem anderen Test mit Centos und NVMe over TCP benutzt, da konnte ich die 2x 100GBit beim Storagezugriff voll auslasten.
Das mit den Migrationen teste ich nachher gleich mal.

 

[Falk R.]

Mit zwei gleichen Migrationen verdoppelt sich die Bandbreite fast (1,9x). Also ist das scheinbar pro Prozess limitiert.
Kann man das eventuell etwas aufbohren?

 

[itNGO]

Hi, im Host sind je 2x Xeon Gold 6346.
Die Hosts hatte ich vorher bei einem anderen Test mit Centos und NVMe over TCP benutzt, da konnte ich die 2x 100GBit beim Storagezugriff voll auslasten.
Das mit den Migrationen teste ich nachher gleich mal.

Äpfel und Birnen.....
aber rein Technisch kann die Hardware es.... zumindest das ist doch schon mal gut zu wissen....

 

[itNGO]

Mit zwei gleichen Migrationen verdoppelt sich die Bandbreite fast (1,9x). Also ist das scheinbar pro Prozess limitiert.
Kann man das eventuell etwas aufbohren?

Das eher ne Frage von Single-Thread-Leistung und die ist bei den Gold 6346 eher moderat bis unterirdisch....
Du kannst ein bisschen in der sysctl.conf rumspielen, das mag noch irgendwas zwischen 5 und 25% bringen....

#Controls the default maxmimum size of a presage queue
kernel.msgmax = 65536

#ZFS Anpassungen
vfs.zfs.write_limit_override=1073741824

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296

# Ceph Networking Optimizations
net.core.rmem_default = 56623104
net.core.rmem_max = 56623104
net.core.wmem_default = 56623104
net.core.wmem_max = 56623104

net.core.somaxconn = 40000
net.core.netdev_max_backlog = 300000

net.ipv4.tcp_max_tw_buckets = 10000
#net.ipv4.tcp_tw_recyc1e = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_mtu_probing=1
net.ipv4.tcp_rmem = 4096 87380 56623104
net.ipv4.tcp_wmem = 4096 65536 56623104
net.core.somaxconn = 5000
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_tw_buckets = 262144
net.core.optmem_max = 4194304
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_adv_win_scale = 1
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_ecn = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_fin_timeout = 10
net.core.netdev_budget = 600
net.ipv4.tcp_fastopen = 3

kernel.pid_max = 4194303
vm.zone_reclaim_mode = 0
vm.swappiness = 10
vm.min_free_kbytes = 513690 # assuming 64GB of RAM total
vm.dirty_ratio = 40
vm.vfs_cache_pressure = 1000
vm.dirty_ratio = 20
net.netfilter.nf_conntrack_max = 10000000
net.nf_conntrack_max = 10000000
vm.dirty_background_ratio = 3
fs.file-max = 524288

 

[Falk R.]

Hi, der Punkt "vfs.zfs.write_limit_override" klingt interessant, nur leider finde ich keine gute Dokumentaton dazu. Meistens steht da nur, dass der Wert zum Sysstem passen muss, aber nicht wie man den Wert ermittelt.

Bei Migrationen bin ich vermutlich zu verwöhnt von vSphere7, da geht das inzwischen multi Thread und man kann da inzwischen auch 100GBit auslasten. Dann warte ich mal, bis ich Hardware mit guten CPUs in die Finger bekomme.

 

[itNGO]

Hi, der Punkt "vfs.zfs.write_limit_override" klingt interessant, nur leider finde ich keine gute Dokumentaton dazu. Meistens steht da nur, dass der Wert zum Sysstem passen muss, aber nicht wie man den Wert ermittelt.

Bei Migrationen bin ich vermutlich zu verwöhnt von vSphere7, da geht das inzwischen multi Thread und man kann da inzwischen auch 100GBit auslasten. Dann warte ich mal, bis ich Hardware mit guten CPUs in die Finger bekomme.

Der Wert "vfs.zfs.write_limit_override" sollte in einem ZFS Redundanten Pool nicht größer sein als das, was der SSD-Cache, der durch einen Capacitor gestützt wird, halten kann X Anzahl SSDs im POOL abzüglich Redundanzen.

Also Beispiel 4x1GB Cache SSD im RAID 10 = 2GB write_limit_override... Dann passiert auch nichts wenn du den Stecker ziehst....

Einige Beschreibungen sagen das es "Dirty-Cache" ist.... also Cache der noch nicht "sicher" ist... sowas gibt es meiner Erfahrung nach aber in ZFS gar nicht wirklich. Stünde auch im völligen Widerspruch zu dem was ZFS sein will und warum es so extrem wichtig ist Enterprise SSDs zu benutzen.
ZFS redet nun mal gerne mit den SSDs/Platten....

 

[itNGO]

Bei Migrationen bin ich vermutlich zu verwöhnt von vSphere7, da geht das inzwischen multi Thread und man kann da inzwischen auch 100GBit auslasten. Dann warte ich mal, bis ich Hardware mit guten CPUs in die Finger bekomme.

Ab 2750 im SingleThreadPassMark wird das langsam "spannend"...
https://www.cpubenchmark.net/singleThread.html#server-thread

Ab 3000 werden es dann so round about 20GBit..... Oder man wartet bis auch Proxmox/KVM Multithread-Migrationen im Code haben..... maybe.... some day....

 

[Falk R.]

Also noch mal auf Epyc testen.

 

[t.lamprecht]

Ab 3000 werden es dann so round about 20GBit..... Oder man wartet bis auch Proxmox/KVM Multithread-Migrationen im Code haben..... maybe.... some day....

Na ja, da gäbe es theoretisch schon was, nennt sich bei QEMU multifd und wurde bei PVE hauptsächlich außen vor gelassen da es erst ab so 10G+/25G+ Sinn ergibt, meist auch dann nur ohne Verschlüsselung's Layer, bisher nicht wirklich als Problem/Wunsch auftrat und die Komplexität auch leicht erhöht - da 100G immer beliebter wird und sich es hier User auch wünschen, rentiert es sich wohl das nochmal anzuschauen und falls es sich als stabil genug erweist auch opt-in einzubauen.

 

[Falk R.]

Na ja, da gäbe es theoretisch schon was, nennt sich bei QEMU multifd und wurde bei PVE hauptsächlich außen vor gelassen da es erst ab 10G+/25G+ überhaupt Sinn ergibt, meist auch nur ohne Verschlüsselung's Layer, bisher nicht wirklich als Problem/Wunsch auftrat die Komplexität auch leicht erhöht - da 100G immer beliebter wird und sich es hier User auch wünschen, rentiert es sich wohl das nochmal anzuschauen und falls es sich als stabil genug erweist auch opt-in einzubauen.

Verschlüsseln will ich den Traffic eh nicht, da der normalerweise in ein eigenes VLAN kommt.

 

[itNGO]

Verschlüsseln will ich den Traffic eh nicht, da der normalerweise in ein eigenes VLAN kommt.

Im Hosting ist das durchaus ein Thema und auch zwingend durch entsprechende Anforderungen erforderlich.
Selbst wenn alles durch VLANs getrennt wird.... Ein VLAN-Breakthrough ist in 5 Minuten gemacht, selbst wenn der Switch den Port nicht mal als TAGGED erlaubt, da ist "leider" leicht durchkommen.

Daher im Multi-Tenant.... IMMER verschlüsselt..... Im KMU mag man das "noch" vernachlässigen...

 

[Falk R.]

Im Hosting ist das durchaus ein Thema und auch zwingend durch entsprechende Anforderungen erforderlich.
Selbst wenn alles durch VLANs getrennt wird.... Ein VLAN-Breakthrough ist in 5 Minuten gemacht, selbst wenn der Switch den Port nicht mal als TAGGED erlaubt, da ist "leider" leicht durchkommen.

Daher im Multi-Tenant.... IMMER verschlüsselt..... Im KMU mag man das "noch" vernachlässigen...

Also per VLAN Hopping mit doppelt getaggten Paketen kannst du was in das VLAN einschleusen, aber ich hab keine Ahnung wie Jemand damit meinen Migrationstraffic mitlesen will, wenn es aus dem VLAN keinen Weg zurück gibt, da es nicht geroutet wird.
Du kannst mich gern eines besseren belehren, aber von selbst komme ich nicht drauf, wie das gehen soll.

 

[itNGO]

Also per VLAN Hopping mit doppelt getaggten Paketen kannst du was in das VLAN einschleusen, aber ich hab keine Ahnung wie Jemand damit meinen Migrationstraffic mitlesen will, wenn es aus dem VLAN keinen Weg zurück gibt, da es nicht geroutet wird.
Du kannst mich gern eines besseren belehren, aber von selbst komme ich nicht drauf, wie das gehen soll.

Nein ich auch nicht. Aber nur weil wir es nicht wissen/verstehen darf sowas im Multi-Tenant trotzdem nicht unverschlüsselt sein.
Irgendwann kommt immer jemand, der es dann eben doch kann.... ;-)