Langsame Read Performance ME5024->PVE

[rebru]

Ich habe MLAG Setups schon mehrfach installiert und noch nie solche Fehler gesehen. Daher vermute ich ein Fehler irgendwo in der Konfiguration. Wo genau ist schwer zu sagen, da es viele Stellen gibt wo sich kleine Fehler einschleichen können.
VMware wäre nur vergleichbar, wenn man da Distributed Switches mit LACP genutzt hat. Sonst sieht das bei VMware im Backend ganz anders aus.

Antwort vom FS Support - DAC Kabel als Fehlerquelle - sie schicken mir jetzt Module (explizit für Mellanox und FS) und LWL Kabel um es zu testen. Sie meinten, das Problem liegt da. Kann ich zwar noch nicht richtig glauben, aber ja, einen Versuch ist es wert

Für iSCSI umd Multipath musst du zwei getrennte Netze mit verscheidenen IP Kreisen nutzen, aber das Konzept von 2 getrennten Fabrics sollte ja bekannt sein.

Aber das würde gleichzeitig bedeuten, falls ich einen Wechsel machen würde auf direkte Hostanbindung, dass dann natürlich jeweils ein Port an A und B Controller getrennte Netze haben müssten und das pro Port.
Sprich
ME A P0 -> Netz 1 > PX1 P0
ME B P0 -> Netz 2 > PX1 P1
ME A P1 -> Netz 3 > PX2 P0
ME B P1 -> Netz 4 > PX2 P1
.....

Der LACP für VM traffic kann auch mal gecheckt werden in dem du dir mal die bond Infos auf dem Host anschaust:
cat /proc/net/bonding/bond0

Kein LACP mehr konfiguriert ist jetzt ja nur noch ein normaler Bond (auch auf den Switches kein LACP mehr aktiv) - bei den VM's gehts mir nur um fault tolerance nicht aber um load balancing so dass ich nicht zwei Bridges habe und entsprechend jede VM in beide Bridges stellen muss.

 

[Falk R.]

Antwort vom FS Support - DAC Kabel als Fehlerquelle - sie schicken mir jetzt Module (explizit für Mellanox und FS) und LWL Kabel um es zu testen. Sie meinten, das Problem liegt da. Kann ich zwar noch nicht richtig glauben, aber ja, einen Versuch ist es wert

Glaube ich auch nicht wirklich, aber nichts ist unmöglich.

Aber das würde gleichzeitig bedeuten, falls ich einen Wechsel machen würde auf direkte Hostanbindung, dass dann natürlich jeweils ein Port an A und B Controller getrennte Netze haben müssten und das pro Port.
Sprich
ME A P0 -> Netz 1 > PX1 P0
ME B P0 -> Netz 2 > PX1 P1
ME A P1 -> Netz 3 > PX2 P0
ME B P1 -> Netz 4 > PX2 P1

Genau so MUSS ein Multipath Setup aussehen. Wird auch in den Hersteller Dokus so beschrieben. Einzige Ausnahme war die DELl Equalogic, aber die ist schon lange EOL.

Kein LACP mehr konfiguriert ist jetzt ja nur noch ein normaler Bond (auch auf den Switches kein LACP mehr aktiv) - bei den VM's gehts mir nur um fault tolerance nicht aber um load balancing so dass ich nicht zwei Bridges habe und entsprechend jede VM in beide Bridges stellen muss.

Ich glauibe hier gibt es ein paar Missverständnisse.
bond = zusammenfassen von Links
Die bond Settings sagen erst welches Protokoll genutzt wird, natürlich nutzt man da auch oft LACP. Kommt immer auf den Anwendungsfall an. Das simpelste Setup ist Active-Backup.

Zwei Bridges macht man eh nicht, außer man will Netze trennen. Für Fehlertolleranz oder Lastausgleich gibt es ja den bond welcher als Interface in der Bridge hinterlegt ist.

 

[rebru]

Genau so MUSS ein Multipath Setup aussehen. Wird auch in den Hersteller Dokus so beschrieben. Einzige Ausnahme war die DELl Equalogic, aber die ist schon lange EOL.

Ok - ja dann überlege ich mir das mal so zu lösen (hab ja noch freie SFP+ Ports und auch noch genügend Kabel). Weil ja, mit dem QSFP Bond würde das ja bedeuten, dass ich 8 IP's definieren müsste auf dem Bond, wenn ich alle Lanes des ME5024 ansprechen wollte?

Weil ich kann ja schon wechseln auf direkte Anbindung, aber dann kastriere ich ja die Geschwindigkeit auf die Hälfte bzw. sogar einen Viertel, wenn der Bond und die Lastverteilung sauber laufen würde.

Ich glauibe hier gibt es ein paar Missverständnisse.
bond = zusammenfassen von Links
Die bond Settings sagen erst welches Protokoll genutzt wird, natürlich nutzt man da auch oft LACP. Kommt immer auf den Anwendungsfall an. Das simpelste Setup ist Active-Backup.

Zwei Bridges macht man eh nicht, außer man will Netze trennen. Für Fehlertolleranz oder Lastausgleich gibt es ja den bond welcher als Interface in der Bridge hinterlegt ist.

Jein - sorry, zu unklar ausgdrückt - Bond kann ich ja mit LACP oder ohne machen - und ich will ihn eigentlich mit XOR laufen lassen - Im MOment ist er active/backup - aber ich hab gesehen, dass er diese Nacht schon wieder angefangen hat LinkUp/LinkUp zu melden - nur dieses Mal auf einem anderen Host (PXHV3).

Aber ja ich gucke jetzt mal was die neuen Module und Kabel bringen - nehme aber gleichzeitig noch die anderen Kabel mit (Für Direct Attach) und teste es dann gleich vor Ort, weil sonst kann ich danach nochmals 200km fahren.


Aber ich danke Dir schon mal bis hierhin für die vielen wertvollen Tipps!

 

[Falk R.]

Ok - ja dann überlege ich mir das mal so zu lösen (hab ja noch freie SFP+ Ports und auch noch genügend Kabel). Weil ja, mit dem QSFP Bond würde das ja bedeuten, dass ich 8 IP's definieren müsste auf dem Bond, wenn ich alle Lanes des ME5024 ansprechen wollte?

Guck mal hier:
https://forum.proxmox.com/threads/e...tion-bonds-bridges-gefragt.150601/post-696545

 

[rebru]

Man glaubt es kaum - per Zufall doch heute noch die Kabel erhalten mit den entsprechenden Modulen (Mellanox und FS) und war noch kurz im RZ - Lange Rede kurzer Sinn - jetzt hat das geplustere komplett aufgehört. XOR läuft sauber, ich kann Ports deaktivieren/aktivieren und es läuft einfach wie es soll.

Was lernt man daraus - nimm keine DAC Kabel - oder die Switches sind einfach queer und freuen sich jetzt über die pinken Kabel

 

[Falk R.]

Man glaubt es kaum - per Zufall doch heute noch die Kabel erhalten mit den entsprechenden Modulen (Mellanox und FS) und war noch kurz im RZ - Lange Rede kurzer Sinn - jetzt hat das geplustere komplett aufgehört. XOR läuft sauber, ich kann Ports deaktivieren/aktivieren und es läuft einfach wie es soll.

Was lernt man daraus - nimm keine DAC Kabel - oder die Switches sind einfach queer und freuen sich jetzt über die pinken Kabel

DAC ist nicht generell schlecht, ich setze ganz viel DAC ein.
XOR nutzt du jetzt aber nicht für iSCSI?

 

[rebru]

Dank @Falk R. hab ich das ISCSI nun komplett auf einem dedizierten Netzwerk, mit zwei verschiedenen Subnetzen. Das hat auch alles sauber funktioniert und ich kann jetzt Switches booten, ohne dass es mir gleich den ganzen Cluster um die Ohren haut bzw. die VM's dann Amok laufen (IO Error, FSCK Tests etc.) weil das Storage "weg" ist.

Was die Performance anbelangt (immer raw Disk moves)

Grundsätzliches: ISCSI hat 40Gbit Netzwerk (2 single Interfaces, für die beiden Fabrics), NFS hat 10Gbit Netzwerk (bond)

1. Disk Move local -> ISCSI: ~1.5GB/sec
2. Disk Move ISCSI -> local: ~200 MB/sec (genau das verstehe ich nicht)
3. Disk Move NFS -> ISCSI: ~1.5GB/sec
4. Disk Move ISCSI -> NFS: ~1.2GB/sec
5. Disk Move NFS -> local: ~0.8GB/sec
6. Disk Move local -> NFS: ~1.2GB/sec
7. dd schreiben mit LV gemountet auf dem Proxmox selbst: ~1.5GB/sec
8. dd innerhalb einer VM die auf dem ISCSI liegt: ~1.5GB/sec
9. dd innnerhabl einer VM die auf dem NFS liegt: ~1GB / sec
10. FIO schreiben auf das ISCSI mit bs=128 -> 2.5GB/sec
11. FIO lesen vom ISCSI mit bs=128 -> 2.5GB/sec
12. FIO schreiben auf local mit bs=128 -> ~4.5GB/sec
13. FIO lesen auf local mit bs=128 -> ~4.5GB/sec
14. Full Backup ziehen von einer Maschine die auf dem ISCSI liegt und auf NFS schreiben -> ~1.2GB/sec

Die Performane von einer Disk Migration von ISCSI zu lokal ist einfach unterirdisch und ich verstehe nicht warum - und das finde ich wohl auch nicht so schnell raus, was hier das Poblem ist. Interessanterweise ist auch ein Unterschied beim NFS zu bemerken - jedoch immer noch um Längen besser als jenes vom ISCSI - was meiner Meinung nach nicht sein dürfte, denn das NFS liegt auf einem Syno HA, ist also von der Hardware her kein Vergleich zum PowerVault 5024.

Quintessenz für mich - sollte ich jemals das ISCSI leer machen müssen, so doch lieber downtime der VM in Kauf nehmen, diese sichern und vom Backup zurückspielen - ist immer noch 10x schneller als eine Disk Migration.