[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-virtual-server
Subject:    Automatic management of VIP dummy interfaces
From:       Stian =?iso-8859-1?Q?S=F8iland?= <stian () soiland ! no>
Date:       2004-05-04 14:24:13
Message-ID: 20040504142413.GA15220 () itea ! ntnu ! no
[Download RAW message or body]

First, a description of our setup.

At NTNU we are using LVS to do web directing for our 10 physical web
servers. Virtual domains are distributed on different virtual servers
according to the dependencies involved (different NFS servers, different
importance, security reasons, etc).  

For instance, our main site www.ntnu.no is on virtual server semper1,
while www.stud.ntnu.no - the site of students home pages, are on
semper2.  Miscellaneous sites are on semper3, as they have complex NFS
dependencies.

The idea is that we can have some real_servers with only some virtual
servers, to reduce complexity on each real_servers.

However, it varies which real server has which virtual servers, as we
take them out for service, testing, etc. 

Now, as a University we have lots of IPs, so both RIPs and VIPs are
'real' IPs. Each real_server has the VIP addresses configured on
their dummy0 interface, so they'll accept the redirected connections.

In our initial setup, all real servers had all possible VIP addresses
configured, so we didn't need to change the network configuration
locally if a server was going to have a new role. However, not all sites
are actually served locally, for instance for security reasons or a
missing NFS mount.

This introduced problems previously mentioned in the LVS faq as a
'gotcha'. Web applications, running on the real_servers, cannot connect
to VIPs outside them self. This is OK for sites actually served, but not
for those missing dependencies.
    

Our solution to this whole mess was to create a script that manages
which RIP addresses should be listened to on dummy0, and which should
not. The script parses keepalived.conf (that therefore needs to be
available), and runs 'ip addr' to fix things up.


The script, and more details, is available at:

    http://www.soiland.no/vip_manager/

Any comments are welcome, either here or in private emails.


(of course, this still does not solve the problem of connecting to VIP
addresses from the directors. This has introduced a problem for us, as
we have a local apt repository on apt.itea.ntnu.no, to manage locally
approved patches. We are serving this on a virtual server, and this
works fine for apt-get - EXCEPT when on the director.

The directors cannot contact VIPs correctly, they only get's answers from
their self. One suggested solution for this is to run a web proxy for
those special cases, but then the problem rises - where to run the web
proxy? This is a unsolved problem for us still.  )


-- 
Stian Søiland               Work toward win-win situation. Win-lose
Trondheim, Norway           is where you win and the other lose.
http://www.soiland.no/      Lose-lose and lose-win are left as an
                            exercise to the reader.  [Limoncelli/Hogan]
                            Og dette er en ekstra linje 
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://www.in-addr.de/mailman/listinfo/lvs-users

[prev in list] [next in list] [prev in thread] [next in thread]