Langsame Read Performance ME5024->PVE

[waltar]

Ahja, vergaß Breakout und SAS HBA (die ja fast nichts kosten ... oder bei HPE immer Raid-ctrl dafür).
Und Raid10 pro Ctrl. oder 2x Raid10 im virtual mode an A und B standby ?
Mmh, 5 (irgendwann ggf. x später) pve a sag mal 30 vm/lxc und dann noch mit iscsi und dann mal ein Problem ...,
ich bin ja lieber für den idiotensicheren nfs Weg, kannst 4 NFS Server (aus dem pve Pool) haben, und beliebig viele weitere pve's,
hast filesystem und nfs cache pro pve, mit block storage alles komplizierter, unübersichtlich und viel cacheloser, aber ist wirklich nur persönliche Ansichtssache.

 

[waltar]

Cool ist ja auch Omnipath100, welches man gebraucht super günstig bekommen kann (neu auch nicht mehr so teuer wie früher).

 

[rebru]

Ahja, vergaß Breakout und SAS HBA (die ja fast nichts kosten ... oder bei HPE immer Raid-ctrl dafür).
Und Raid10 pro Ctrl. oder 2x Raid10 im virtual mode an A und B standby ?
Mmh, 5 (irgendwann ggf. x später) pve a sag mal 30 vm/lxc und dann noch mit iscsi und dann mal ein Problem ...,
ich bin ja lieber für den idiotensicheren nfs Weg, kannst 4 NFS Server (aus dem pve Pool) haben, und beliebig viele weitere pve's,
hast filesystem und nfs cache pro pve, mit block storage alles komplizierter, unübersichtlich und viel cacheloser, aber ist wirklich nur persönliche Ansichtssache.

RAID 10 pro Controller im linear Modus - und eben dann zwei Storages eingehängt für Volume A / B.

Bezüglich NFS - ja ich war ja eigentlich glücklich mit dem NFS im Grundsatz - hatte ein Syno HA und hat auch gut funktioniert, wäre da nicht die Problematik gewesen mit dem nicht unterstützten NFS4 und damit immer wieder mal das Hängenbleiben einer VM wo Du weder migrieren, resetten noch sonst was konntest. Nur den ganzen PVE booten.

Mit Linstor wäre ich auch glücklich gewesen nur hatte ich da noch ganz andere Probleme und da es noch relativ neu ist auch zu wenig Hilfe aus dem Internet. Und die Sub ist da so teuer wie das ganze ME5024 mit HD's und das pro Jahr - und dann hab ich nicht mal Hardware. Das war der Grund dagegen zu entscheiden. Ich mach das ja nicht nur aus Spass als Homelab.

Und was ich nicht unbedingt im HA von Proxmox selbst brauche, kommt auch nciht auf den Storage sondern auf die lokalen PVE's. Beispiel Agents von KASM, Proxies (die ich selbst clustere), CCR und solche Dinge. Alles was von sich aus selbst schon clustern/verteilen kann.

Aber ich danke Dir für Deine Zeit und Dein Willen mir zu helfen - muss ich halt weiter suchen oder eventuell hat noch sonst jemand eine Idee, warum ich in den Storage schneller schreiben als daraus lesen kann.

 

[Falk R.]

Hast du die Jumbo Konfiguration noch einmal geprüft. Am Storage und im PVE auf 9000 und im Switch unbedingt mehr als 9000 setzen. Je nach Hersteller ist da etwas zwischen 9128 und 10000. Du kannst auch mal im Seitch schauen ob er Giant Packets anmeckert. Generell auch mal schauen ob alle Ports sauber sind oder ob an einer Stelle viele resend getriggert werden.

 

[rebru]

Hast du die Jumbo Konfiguration noch einmal geprüft. Am Storage und im PVE auf 9000 und im Switch unbedingt mehr als 9000 setzen. Je nach Hersteller ist da etwas zwischen 9128 und 10000. Du kannst auch mal im Seitch schauen ob er Giant Packets anmeckert. Generell auch mal schauen ob alle Ports sauber sind oder ob an einer Stelle viele resend getriggert werden.

@MTU
Natürlich

PVE's -> Netzwerkkarte, Bond und Bridge Interface alles auf 9000 - PVE's auch durchgestartet
Storage -> Jumbo Frames aktiv, aber keine Einstellungsmöglichkeit - muss da eventuell nochmals auf die CLI um genau nachzusehen
Switches -> Jumbo Frames aktiv, laut CLI ist sie auf 9800 eingestellt, was ja ausreichen sollte.

Aber was mich nach wie vor irritiert - wäre es doch im Netzwerk zu suchen, müsste doch auch beim Schreiben dieser Einbruch zu sehen sein oder irre ich mich da? Netzwerkprobleme sind doch immer two way und nicht one way?

@Giant Packets
Am Switch ist in den Logs alles ruhig

@Resend
Hmm wie würde ich sowas prüfen? Da fehlt mir irgendwie gerade der Ansatz.

 

[Falk R.]

Gerade bei Jumbo Problemen ist es oft one Way.
Hast du einen Sender der MTU1500 schickt kommt es immer an. Wenn die Gegenseite mit MTU9000 schickt sind manche Pakete klein und kommen an, aber alle Jumbo Pakete werden am Ziel verworfen.

 

[waltar]

Map doch mal pro volume nur 1 port und pro controller (was ja nur für Ausfall eines Controllers da ist), dann restarte multipathd. Danach dein Migrationslesetest.

 

[rebru]

Map doch mal pro volume nur 1 port und pro controller (was ja nur für Ausfall eines Controllers da ist), dann restarte multipathd. Danach dein Migrationslesetest.

Gerade bei Jumbo Problemen ist es oft one Way.
Hast du einen Sender der MTU1500 schickt kommt es immer an. Wenn die Gegenseite mit MTU9000 schickt sind manche Pakete klein und kommen an, aber alle Jumbo Pakete werden am Ziel verworfen.

Scheinbar ist ein Switchport defekt - per Zufall hab ich gesehen, dass ein Link immer up/down/up/down gemacht hat, seit ich den in einen anderen Port gesteckt habe (dafür bin ich mal kurz 200km gefahren) läuft es wie gewünscht.


Aber jetzt eine andere Frage - durch irgend einen Umstand, hat sich ein Switch abgehängt gehabt, so dass von den 8 Links 4 tot waren - dadurch sind die Nodes komplett durchgedreht (glaube das meinte Waltar betreffend Problem und gute Nacht - gott ich hab fast ne Herzattacke gekriegt ).

Wie schon erklärt, hat jeder Switch mit dem Breakout Cable je 2 Verbindungen auf einen Controller - und es waren immer die ersten beiden Ports betroffen ( 10.89.0.100 - 107 sind die 8 Ports, 100,101,104,105 waren weg und ich hatte Weltuntergang auf dem Cluster (read only, io error, etc. ). Nachdem ich dem einen Switch wieder beibringen konnte, die Verbindungen wieder zuzulassen (hatte irgendwas mit dem MLAG zu tun) musste ich jede Maschine stoppen/starten - ansonsten flog ich gleich in den fsck mit io error rein.

Müsste Multipath nicht automatisch die restlichen Pfade sehen ( 102,103,106,107 ) und entsprechend das so gar nicht passieren?

Das einzige was ich mir noch erklären konnte ist, dass im /etc/pve/storage.cfg das ME5024 ja nur einfach konfiguriert ist

iscsi: ME5024
        portal 10.89.0.100
        target iqn.1988-11.com.dell:01.array.bc305b697b59
        content none
        nodes pxhv3,pxhv1,pxhv2

Muss ich um das in Zukunft zu vermeiden, bzw. wenn mal der Controller A aussteigt, wo das 100 drauf ist, das ME5024 mehrfach definieren mit dem "portal"?

 

[waltar]

Mmh, deine Verkabelung war ja genau dafür da einen Weltuntergang zu überleben ..., ich habe vor 15J 1x iscsi hardcore getestet (Strom gezogen), alles kaputt, damit hatte sich iscsi für mich erledigt. Nur 1 Portal IP ist ja auch sinnlos in der storage.cfg. Und ich zweifle noch immer an deiner multipath, entweder die einen 4 oder die anderen 4 ... nur wenn 1 Switch defekt wie hier, wie soll die multipath das wissen, wenn sie nicht entweder/oder einen Pfad sondern entweder/oder 4 Pfade nehmen soll ... Naja, schlaf erstmal 1 Nacht drüber.

 

[Falk R.]

Scheinbar ist ein Switchport defekt - per Zufall hab ich gesehen, dass ein Link immer up/down/up/down gemacht hat, seit ich den in einen anderen Port gesteckt habe (dafür bin ich mal kurz 200km gefahren) läuft es wie gewünscht.


Aber jetzt eine andere Frage - durch irgend einen Umstand, hat sich ein Switch abgehängt gehabt, so dass von den 8 Links 4 tot waren - dadurch sind die Nodes komplett durchgedreht (glaube das meinte Waltar betreffend Problem und gute Nacht - gott ich hab fast ne Herzattacke gekriegt ).

Wie schon erklärt, hat jeder Switch mit dem Breakout Cable je 2 Verbindungen auf einen Controller - und es waren immer die ersten beiden Ports betroffen ( 10.89.0.100 - 107 sind die 8 Ports, 100,101,104,105 waren weg und ich hatte Weltuntergang auf dem Cluster (read only, io error, etc. ). Nachdem ich dem einen Switch wieder beibringen konnte, die Verbindungen wieder zuzulassen (hatte irgendwas mit dem MLAG zu tun) musste ich jede Maschine stoppen/starten - ansonsten flog ich gleich in den fsck mit io error rein.

Müsste Multipath nicht automatisch die restlichen Pfade sehen ( 102,103,106,107 ) und entsprechend das so gar nicht passieren?

Das einzige was ich mir noch erklären konnte ist, dass im /etc/pve/storage.cfg das ME5024 ja nur einfach konfiguriert ist

iscsi: ME5024
        portal 10.89.0.100
        target iqn.1988-11.com.dell:01.array.bc305b697b59
        content none
        nodes pxhv3,pxhv1,pxhv2

Muss ich um das in Zukunft zu vermeiden, bzw. wenn mal der Controller A aussteigt, wo das 100 drauf ist, das ME5024 mehrfach definieren mit dem "portal"?

Das mit dem defekten Port erklärt das natürlich auch.

Das andere Phänomen solle gar nicht auftreten. War der Switch komplett tot oder war der nur in einem halbgaren Zustand? Wennd er noch halb lebt, sofort ausschalten, dann funktioniert alles wie gewünscht.
Fall der komplett tot war, dann hast du irgendwo einen Fehler im Setup, was ohne einen allumfassenden Plan keiner beurteilen kann.
MLAG läuft in der Regel sehr stabil, daher solltest du auch da mal deine Konfiguration checken.

 

[rebru]

Das mit dem defekten Port erklärt das natürlich auch.

Das andere Phänomen solle gar nicht auftreten. War der Switch komplett tot oder war der nur in einem halbgaren Zustand? Wennd er noch halb lebt, sofort ausschalten, dann funktioniert alles wie gewünscht.
Fall der komplett tot war, dann hast du irgendwo einen Fehler im Setup, was ohne einen allumfassenden Plan keiner beurteilen kann.
MLAG läuft in der Regel sehr stabil, daher solltest du auch da mal deine Konfiguration checken.

Ja da liegt wohl der Hund begraben - ich hab MLAG aktiv aber mein OVS Bond (lacp balance-tcp) will da nicht mitspielen

Wenn ich ein show mlag peer mache auf dem Switch sehe ich, dass dieser aktiv ist

SwitchLinks# show mlag peer
MLAG neighbor is 10.89.254.2, MLAG version 1
MLAG state = Established, up for 00:11:33
Last read 00:00:00, hold time is 5, keepalive interval is 1 seconds
Received 772 messages,Sent 740 messages
Open     : received 1, sent 2
KAlive   : received 694, sent 694
Fdb sync : received 66, sent 33
Failover : received 0, sent 0
Conf     : received 9, sent 9
Syspri   : received 1, sent 1
Peer fdb : received 1, sent 1

Connections established 1; dropped 0
Local host: 10.89.254.1, Local port: 61000
Foreign host: 10.89.254.2, Foreign port: 61001
remote_sysid: 649d.9932.bf41

SwitchRechts# show mlag peer
MLAG neighbor is 10.89.254.1, MLAG version 1
MLAG state = Established, up for 00:11:33
Last read 00:00:00, hold time is 5, keepalive interval is 1 seconds
Received 739 messages,Sent 772 messages
Open     : received 1, sent 1
KAlive   : received 694, sent 694
Fdb sync : received 33, sent 66
Failover : received 0, sent 0
Conf     : received 9, sent 9
Syspri   : received 1, sent 1
Peer fdb : received 1, sent 1

Connections established 1; dropped 0
Local host: 10.89.254.2, Local port: 61001
Foreign host: 10.89.254.1, Foreign port: 61000
remote_sysid: 649d.9932.95f9

Wenn ich jedoch ein show mlag interface mache, sehe ich dass alle down sind

SwitchLinks# show mlag interface 
mlagid  local-if  local-state    remote-state   
1       agg1      down           down           
2       agg2      down           down           
4       agg4      down           down 

SwitchRechts# show mlag interface 
mlagid  local-if  local-state    remote-state   
1       agg1      down           down           
2       agg2      down           down           
4       agg4      down           down

Konfiguriert habe ich auf den beiden Switches

1. port-channel 1,2,4 mit lacp-mode dynamic und load-balance-mode dynamic (static auch schon versucht, selbes Ergebnis)
2. eth-0-1,2,4 mit channel-group 1,2,4 mode active
3. agg1,2,4 mit mlag 1,2,4

Was ich sehe ist, dass im show channel-group summary die Flags für agg1,2,4 auf S (Layer2) stehen - kann es sein, dass das Problem ist, warum der OVS Bond mit lacp balance-tcp da nicht mitspielt und der Switch deswegen alles verwirft?

SwitchLinks# show channel-group summary
port-channel group-mode: flexible

Flags:  s - Suspend           T - Standby
        D - Down/Admin down   B - In bundle
        R - Layer3            S - Layer2
        w - Wait              U - In use

Mode:   SLB  - Static load balance
        DLB  - Dynamic load balance
        RR   - Round robin load balance
        RLB  - Resilient load balance
Aggregator Name  Mode      Protocol     Ports
----------------+---------+--------------+---------------------------------------------
agg1(SD)         DLB       LACP(Dynamic)  eth-0-1(s)
agg2(SD)         DLB       LACP(Dynamic)  eth-0-2(s)
agg4(SD)         DLB       LACP(Dynamic)  eth-0-4(s)
agg7(SU)         SLB       Static         eth-0-7(B)      eth-0-8(8)

SwitchRechts# show channel-group summary
port-channel group-mode: flexible

Flags:  s - Suspend           T - Standby
        D - Down/Admin down   B - In bundle
        R - Layer3            S - Layer2
        w - Wait              U - In use

Mode:   SLB  - Static load balance
        DLB  - Dynamic load balance
        RR   - Round robin load balance
        RLB  - Resilient load balance
Aggregator Name  Mode      Protocol     Ports
----------------+---------+--------------+---------------------------------------------
agg1(SD)         DLB       LACP(Dynamic)  eth-0-1(s)
agg2(SD)         DLB       LACP(Dynamic)  eth-0-2(s)
agg4(SD)         DLB       LACP(Dynamic)  eth-0-4(s)
agg7(SU)         SLB       Static         eth-0-7(B)      eth-0-8(B)

Nachtrag

Hier noch die Interface Config

iface bond1 inet manual
        ovs_bonds enp94s0d1
        ovs_type OVSBond
        ovs_bridge vmbr1
        ovs_mtu 9000
        ovs_options bond_mode=balance-tcp lacp=active

 

[rebru]

Nachtrag

Habs jetzt so halb zum Laufen gekriegt, bis ich halt einen Switch neu starte und dann dreht ein Host komplett am Rad - und ein anderer machts mal ab und an was ich hier beschrieben habe.

Auf jeden Fall konnte ich nicht via GUI den OVS konfigurieren - weil scheinbar geht Bridge und Bond anhängen wie man es übers GUI macht nicht, ich musste die Config von Hand machen, so dass ich die Bridge auf den Bond binden konnte.

https://forum.proxmox.com/threads/mlag-configuration-with-ovs.157570/

 

[Falk R.]

Warum nutzt du den OVS? Welches Feature benötigst du denn davon?
Bau doch ganz normal einen Bond und nutze diesen in deiner vmbr.

Ich hoffe du nutzt kein LACP für die iSCSI Verbindungen.

 

[rebru]

Warum nutzt du den OVS? Welches Feature benötigst du denn davon?
Bau doch ganz normal einen Bond und nutze diesen in deiner vmbr.

Ich hoffe du nutzt kein LACP für die iSCSI Verbindungen.

Eigentlich keine - aber ja, ich hab jetzt mal wieder umstellt auf Linux Bond (und die Switches auf static-group-channel gemäss MLAG Anleitung mit static-channels)

Und ich hab wieder genau das gleiche Problem - nach dem Einrichten lief es, bis ich ich den einen Switch neu gestartet habe - seither hab ich wieder diese Log Einträge seitens PVE und auch auf dem Switch, dass sich das Interface immer wieder abhängt (und gleich wieder kommt). Kabel etc. hab ich alles auch schon getauscht, aber nichts hält den Node1 davon ab dieses Spiel zu starten, es sei denn ich konfiguriere gar kein MLAG und gebe allen Hosts auf den beiden Ports zwei unterschiedliche Netze.

Grundsätzlich funktioniert aber das Switchen, wenn ein Switch gebootet wird, ich hab einfach dann ab und an Aussetzer im Netzwerk, weil sich auch bei einzelnem Switch das eth-0-1 (SwitchRechts) im up/down/up/down Modus befindet.

Aber ja, ich hab jetzt mal den Hersteller angefragt - weil ich weiss nicht mehr wo ich noch suchen soll.

 

[rebru]

Nachtrag

Ok, jetzt bleiben die Hosts ruhig, Quintessenz XOR geht nicht aber active/backup und gefühlt 1000x die Switches booten. Jetzt kann ich hin und her schalten ohne dass es zu diesem plustern führt.

Aber ja, mit dem Hersteller trotzdem mal gucken, warum XOR nicht geht - ich vermute mal es hat mit dem group-channel mode zu tun, der steht nämlich auf flexibel - und im Journalctl gibt er ne warnung aus, dass es deprecated ist und er deshalb immer 16 nimmt (the hash_elasticity option has been deprecated and is always 16)

Weil just genau das kann ich im port-channel einstellen

port-channel group-mode 
16        32        8         flexible  56

Gott was für eine Zangengeburt

Aber wenn das jetzt endlich gegessen ist (und vor allem XOR dann auch problemlos funktioniert), kann ich mich dann nochmals ans ISCSI machen ohne LACP und mit den richtigen Portalen. Ich komme dan nochmals mit einer Frage zurück betreffend Portalen (ich nehme an, ich muss auf allen Hosts das ME5024 (ISCSI) zweimal hinzufügen, mit je einer IP erreichbar aus je einem Switch?)

 

[Falk R.]

Link State doesnt match auf dem Switch sagt ja schon, dass die Konfiguration nicht ganz passt.
Für iSCSI Verbindungen mit Multipath niemals LAGs nutzen.

Theoretisch sollte das Portal alle IPs mitteilen. Das funktioniert manchmal nicht richtig, dann die IPs alle einzeln hinzufügen, aber nicht die Portal IP.

 

[rebru]

Link State doesnt match auf dem Switch sagt ja schon, dass die Konfiguration nicht ganz passt.
Für iSCSI Verbindungen mit Multipath niemals LAGs nutzen.

Theoretisch sollte das Portal alle IPs mitteilen. Das funktioniert manchmal nicht richtig, dann die IPs alle einzeln hinzufügen, aber nicht die Portal IP.

Ja, weil der Port ja down geht aus irgend einem Grund (sehe aber weder im Log des Switch noch im Journalctl einen Grund - im Journalctl sehe ich ja nur Link up, aber niemals Link down) - entsprechend sagt der Switch dann Link STATE doesnt match ( so nach dem Motto, Link down, dann raus aus dem AGG)

Betreffend kein LAG - und wie sonst soll ich das bewerkstelligen in der Konstellation? Beide Ports mit je zwei IP Adressen bestücken damit ich dann von jedem Switch aus jeden Controller erreichen kann? Dann brauch ich dann aber logischerweise zwei Bridges und darf meine anderen Maschinen wie EX19 CCR ebenfalls mit zwei Ports ausstatten (für jede VMBR). Was mach ich dann mit dem PX Cluster MIgration Netzwerk bzw. Corosync? Noch einen Ring hinzufügen?

Betreffend alle IP's - das war ja auch der Fall im Grunde - jedoch sah ich unter /etc/iscsi/send_targets die PortalIP (ME5024 hat auf jedem der 8 Links ein Portal gebunden) - da drin waren dann alle 8 IP's gelistet. Als aber die PortalIP runter ging drehten die Hosts alle komplett durch - 4 Links waren ja weg als ich den Switch neu gestartet habe wo eben unter anderem die IP drauf war die ich als Portal nutzte für die ISCSI Einbindung - die anderen 4 IP's waren aber immer noch erreichbar (ISCSI gemäss dieser Anleitung konfiguriert gehabt -> https://pve.proxmox.com/wiki/Multipath - Sektion ISCSI)

Nebenbei - Mal angenommen ich würde die 3 Hosts, die ich jetzt habe, alle direkt mit dem Storage verbinden (je eine SFP+ Verbindung auf je einen Controller Port) läuft es doch wieder auf dasselbe hinaus. Würde er da nicht automatisch auch alle Ports zurückliefern, obwohl er die anderen 6 gar nicht erreichen kann? Und würdest Du da den jeweiligen Ports am Storage je ein anderes Subnetz geben?

 

[waltar]

Schönes Ding so'n iscsi setup, da hast du dir jetzt Probleme "in's Haus" geholt, die du vorher noch garnicht ahntest bzw. kanntest und irgendwann im Prod-Betrieb schlägt es auch nochmal erneut zu ... so be prepared ... Erinnert mich so'n bißchen an einen früher mal ausgefallenen FC-switch in HA-config, wo dann der neue erstmal wieder mühselig (nach 4J) auf Konfigstand gebracht werden mußte, damit er dann auch wieder so funktioniert, wie er soll, war 'ne "heiße Zeit" ...

 

[rebru]

Schönes Ding so'n iscsi setup, da hast du dir jetzt Probleme "in's Haus" geholt, die du vorher noch garnicht ahntest bzw. kanntest und irgendwann im Prod-Betrieb schlägt es auch nochmal erneut zu ... so be prepared ... Erinnert mich so'n bißchen an einen früher mal ausgefallenen FC-switch in HA-config, wo dann der neue erstmal wieder mühselig (nach 4J) auf Konfigstand gebracht werden mußte, damit er dann auch wieder so funktioniert, wie er soll, war 'ne "heiße Zeit" ...

Na ja, ich komme ja von VMware her - bin jetzt seit bisschen mehr als einem Jahr bei Proxmox - ich hatte bei VMWare ISCSI jahrelang im Einsatz ohne nennenswerte Probleme (also im Sinne, wenn ISCSI Device mal abstürzt/abhängt - klar die VM's laufen dann auch Amok, aber nach Stop/Start alles wieder gut). Zu Hause auch über Jahre hinweg und auch nie wirklich Probleme, selbst als mir da das NAS ausgestiegen ist ( Power Supply ) - ersetzt hochgefahren alles wieder funktional.

Aber ja mal gucken, ich hab ja noch zwei alte Server - vielleicht mach ich doch lieber ein HA mit DRBD und darüber dann ein NFS 4.x - Wobei auch da Dinge schief gehen können. Aber ja, ich warte jetzt erst mal ab was der FS Support meint.

 

[Falk R.]

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.

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.

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