|
This is great! I had not worried about this because my servers are behind a
router which will get ARP'd separately. Obviously this is needed in more
general
usage.
After we test this a bit more, I'd like to clean up my code a bit, add a patch
description line for my original patch along with yours, and submit it to
linux-kernel. This doesn't solve the problem at the source but does create a
more
correct kernel, especially for our purposes.
Should we add a patch to prevent ARP's from being sent for other devices? I
mentioned before that when you have two ethernet devices on the same network
segment, each will answer for an IP that only one of the interfaces has.
Now all we need is layer 3 routing to be completely state of the art. Difficult
to do in a DR setup, probably requires NAT or possibly TUN. The idea is to
allow
the router to start a TCP connection, read in the header (in the case of HTTP
especially) watching for cookies, domain names, etc., and then replay the
initial
transmissions to the server selected, thereafter just acting as a dumb router.
The server would be selected based on where the user had been last or the URL
path
in addition to more direct load balancing.
This is required if your application requires that all connections for the same
session talk to the same box. Many simple CGI programs would fall into this
category, while some or most application servers handle this problem by
replicating the session state with other servers either through the database or,
better, by directly replicating to the other servers.
Several companies appear to support this, including iPivot. They can even
notice
that the server returned 404 errors or too busy errors and replay the request to
another server.
sdw
Axel Dunkel wrote:
> Hi,
>
> even after the arp patch I still had problems with DR and local clients. I
> tracked this down to the following: a local client connects to the farm
> address, the VS machine forwards the packet to a real server. If this very
> real server does not have an arp entry for the local client, it sends out an
> arp request for the local client - and gets stuck since he is using the farm
> address (the request gets blocked by the arp patch). So the local client
> does not get a reply until the real server has an arp entry (due to some
> other traffic). I hope this was the last ARP problem. :-)
>
> I patched arp.c again to let those arp's through but to change the ip adress
> of the request to the main ip address of the very interface where the
> request gets send.
>
> So, I include two patches: one for plain 2.2.12/2.2.13pre6 (dunkel-
> vs+arp.patch) and the other one for 2.2.12/2.2.13pre6 with the arp patch
> applied (dunkel-vs.patch).
>
> It finally works here, but - as usual - use at your own risk...feedback is
> welcome!
>
> Nice weekend,
> Axel
>
> ---
> Systemberatung A. Dunkel GmbH, Gutenbergstr. 5, D-65830 Kriftel
> Tel.: +49-6192-9988-0, Fax: +49-6192-9988-99, E-Mail: ad@xxxxxxxxx
>
> ----------------------------------------------------------------------------
>
> dunkel-vs+arp.patchName: dunkel-vs+arp.patch
> Type: unspecified type (Application/Octet-stream)
>
> dunkel-vs.patchName: dunkel-vs.patch
> Type: unspecified type (Application/Octet-stream)
>
> ----------------------------------------------------------------------------
> ----------------------------------------------------------------------
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
sdw
--
OptimaLogic - Finding Optimal Solutions Web/Crypto/OO/Unix/Comm/Video/DBMS
sdw@xxxxxxx Stephen D. Williams Senior Consultant/Architect http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 5Jan1999
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
