Ich verwende LVS (ipvsadm) im NAT-Modus, um den UDP-Verkehr für eine Reihe von „Realservern“ auszugleichen. Ich verwende One-Packet-Scheduling, sodass der Verkehr, der von einem einzigen Quellport auf dem Client stammt, auf verschiedene Realserver verteilt wird.
Was ich jedoch sehe, ist, dass die Quell-IP/der Quell-Port der UDP-Datagramme, die von den Realservern stammen und an den Client zurückgesendet werden, auf die des Realservers eingestellt sind. Das verwirrt den Client, weil er Antworten erwartet, deren Quell-IP/-Port mit denen übereinstimmt, an die er das ursprüngliche Datagramm gesendet hat.
Das ist in der Tat sehr seltsam, da LVS die realen Server hinter der virtuellen IP/dem virtuellen Port „verstecken“ soll.
Es scheint, dass wenn ich die Einzelpaketplanung ausschalte, die Quell-IP/der Quell-Port ausgehender DatagrammeSindvon LVS korrekt neu geschrieben.
Ist das schon mal jemandem passiert? Wenn ja, wie kann man das umgehen?
Antwort1
Falls weiterhin Interesse besteht:
Ich glaube, dass die Ein-Paket-Planung keine Antwort von dem gerade geplanten Paket erwartet und daher keine Verbindungsinformationen speichert. Wenn dann die Antwort zurückkommt, kann LVS die Verbindung dafür nicht finden und weiß daher nicht, welche Quell-IP/welchen Quell-Port es verwenden soll.
Dies scheint so beabsichtigt zu sein. Suchen Sie hier nach „OPS ist für Setups implementiert, bei denen es keine Antwort auf das Originalpaket gibt“ und Sie werden eine Erklärung sehen.
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.UDP.html
Die Lösung besteht darin, ein Persistenz-Timeout für UDP-Verbindungen festzulegen (Sie können es niedrig einstellen, wenn Sie schnelle Antworten erwarten) und so eine Verbindungszeit explizit festzulegen. Da Sie dies tun können, besteht für OPS kein Grund, sich Verbindungen zu merken.