|
On Thu, 25 Nov 1999, Julian Anastasov wrote:
>
> Hi Joe,
>
> On Wed, 24 Nov 1999, Joseph Mack wrote:
>
> > I was not thinking clearly. I was thinking that the machines on the LAN
> > would be talking to the LVS via a router. THis is not what Julian was
> > talking about.
>
> Is this mean:
Sorry to take so long to reply. I am getting ready to take
a 1 month vacation in Australia (where I am originally from)
(I will mainly be bushwalking in the mountains west of Sydney)
+------+
|Client|
+------+
> |
> +------+
> |ROUTER|
> +------+
> |
> +-------+
> | LVS | --------+----------------------------- LAN
> +-------+ |
> +----+
> |WEB1| ...
> +----+
(Joe - I added the client box above)
>
> May be I don't understand fully. This is same
> as the MASQ case: default gw for real server is the MASQ
> box. In this configuration there is no ARP problem.
> Only the ROUTER and LVS are on the same LAN (if the media
> allows broadcasts).
The setup above (with the added client) is VS-NAT. With VS-NAT there is no
forwarding in either direction except packets under the control of the
LVS, so even if the director has only one NIC, it is acting as a firewall.
there is no arp problem here - agreed
When he director has two network cards and the director is in VS-Tun or
VS-DR ("Lars' method" in the HOWTO, Lar's ws the first to tell me about
this, so I named it after him), there is no arp problem either. This
probably is the most general solution (the price of an extra NIC is small
compared to all the messing around we have done trying to handle the arp
problem).
All other hosts must be on same LAN:
> LVS and all webs. If there is another host on the LAN which
> can ARP query about VIP then we have the same problem.
I'm assuming there are no clients on the piece of network you have
labelled as "LAN"
> ARP replies don't hurt only these hosts which have VIP
> configured. In fact, LVS and the webs never send ARP
> queries for the VIP. Even LVS doesn't send ARP query
> "who-has ROUTER tell VIP" - only the webs can ask
> "who-has LVS tell VIP" as they use the LVS as default
> gateway.
I have assumed that the realservers do not ask "who has ROUTER tell VIP"
- I thought they only asked "who has ROUTER tell realserverIP".
But I'm not sure if the LVS will reply
> to this query as its src IP=VIP. It have to be tested.
>
> But this configuration is same as the MASQ,
> i.e. outgoing traffic is redirected through LVS (MASQ).
> The advantage of the DROUTE mode is that all web servers
> can use any router for the outgoing traffic. For example,
>
same for VS-Tun
> +-------+
> |ROUTER1|
> +-------+
> |
> |LAN1
> |
> |
> +-------+ +----+
> | LVS | |WEB1| ...
> +-------+ +----+
> | | LAN 2 +-------+
> +-------------+---------------------->>>|ROUTER2|
> +-------+
>
> But may be this is not so different, we always have to change
> their default gateway if we suspect that this router is
> not working. I'm not sure if this configuration is working
> but it allows ROUTER1 and LVS to be on same LAN1 and
> all webs and ROUTER2 to be on LAN2.
>
> This is a good example of configuration which is
> not working. The problem is if the real servers ask
> "who-has ROUTER2 tell VIP".
The realserver has a packet src=VIP,dest=ClientIP but
when it asks for a route to ClientIP it does so from
the realserverIP (I thought). The LVS works fine for
me if there is no route for the VIP on the realservers.
> So, we are at the same place:
> to define permanent entries for the ROUTER2 in all
> web servers. It is so complex to be working :)
I set up the default gw (ROUTER2 above) for the realservers before I setup
the LVS.
> In this configuration it is again not possible WEB1
> for example to switch to LVS mode when LVS box is down.
I'm sorry I don't understand this sentence.
> Who knows, may be this configuration is useful for
> someone?
>
> So, the user have to know the answers of these
> questions:
>
> - if it is not possible to define static arp entries
> in the incoming router and if the LVS box and the real
> servers are on same LAN, it is preferred the real
> servers not to talk ARP about VIP. In Linux this
> can be achived applying one of the two patches:
> http://www.linuxvirtualserver.org/arp.html
agree
>
> - how many LVS boxes must be supported (only one active
> at the same time)
>
> - if the real servers ARP reply and how they ARP query, i.e.
> is the src ip=VIP. So, it can choose the proper OS.
>
> - if the real servers will use many routers for the
> outgoing traffic
>
> So, this is a problem which can't be handled
> properly for dynamic configurations. We (the users)
> must be ready to isolate so many possible faults:
> in the incoming routers, LVS (many LVS?), LAN switch (buy
> one more?), many webs (thanks to LVS), outgoing
> router(s). So, it depends.
>
> One thing which can be recommended: if some
> of the webs can be configured to switch to LVS mode when
> main LVS box is down (someone can configure all web
> servers :)) this WEB and LVS have to be on same LAN with
> the router, i.e. they must be ARP visible for the incoming
> router.
do you mean that if a director fails, that a realserver
takes over the role of director? That's a neat idea.
> In this configuration it is easy the current LVS
> box to send Gratuitous ARP reply when it's switched to LVS
> mode.
> It is always preferred to use ARP for such
> dynamic configurations. Permanent ARP entries are
> useful only for static configurations.
agree
Joe
>
> Regards,
>
> Julian Anastasov
>
>
--
Joseph Mack mack@xxxxxxxxxxx
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
