|
> sure. the way i understand it, at least with lvs' direct routing, is
> this:
>
> a packet comes in to a router. the router sends it along to the balancer.
> the balancer checks its ipvs (managed with ipvsadm or some other tool)
> table to see where the packet should be directed to, and does any
> necessary calculations in the process in terms of round robin or least
> connection or weighted values and if persistence is on. the packet is
> then pushed along to the proper real server via the real server's network
> interface's hardware address. the real server then, assuming proper
> configuration,
which is that it accepts packets for the VIP (ie has the VIP as a local
address, or you have transparent proxy setup to accept packets for the
VIP)
accepts the packet, processes it however necessary (web
> request? etc) and sends its response (if any)
it's going to at least have to send an ACK
back to the requesting
> client ip. the real server's gateway (next hop) is that router in step 1.
usually, but it can be another router too.
> lvs' nat method, in contrast, works by the packet going through the router
> to the balancer, the balancer does similar procesing of determining which
> real server it should go to, then rewrites the packet's destination
> ip/port
yes
(source ip/port also?)
no, otherwise there'd be no way to remember who to send the reply packets
to.
, and sends it to the real server. the real
> server processes it, and sends the response back. the real server's
> gateway is the _balancer_. so the balancer then gets the response packet,
> rewrites it again to put the proper source/destination
puts the VIP:port as the source of the reply packet
information back in
> it, and the balancer then sends it along to the router and back to the
> client.
>
>
> here are some typical reasons i've heard as to why lvs' dr won't fly, and
> the workarounds:
>
> . in order for the real server to send directly back to the client, the
> real server needs a route to get there. this is usually accomplished by
> giving the machine a real public ip and route.
real-servers in VS-DR send reply packets from the VIP. All other IP's
on the real-servers can be private and non-routable (eg 192.168.x.x). You
aren't using any extra IPs.
this is a waste of ip
> space and an extra missed layer of security. the workaround is to give
> the real servers internal unroutable ips, and set their gateway to the
> router's address, and add the router's route the the real server.
> unfortunately, this isn't enough for proper arp requests and responses to
> be sent between the router and real server.
the solution is to add a
> static arp entry in the real server's arp table of the router's ip and mac
> address.
I hadn't thought about this. I have the router with an 192.168.x.x address
and an address in the network of the VIP, so can communicate with the
real-servers and the director.
So what are the minimum addresses for the inside of the router, the
outside of the director and the real-servers?
Joe
--
Joseph Mack mack@xxxxxxxxxxx
|
