ipvsman-users — Discussion on the ipvsman GUI

Re: [Ipvsman-users] ipvsman tarball

[Gerry R. <gr...@ve...>]

Gerry Reno wrote:
> Dr. Volker Jaenisch wrote:
>   
>> Hi Gerry!
>>
>> Gerry Reno schrieb:
>>   
>>     
>>> Hi Volker,
>>>   I have a suggestion involving packaging.  In order to support various 
>>> downstream packaging such as RPM, the ipvsman tarball will need to 
>>> conform to certain convention.  The high level directory name inside the 
>>> tarball must be like "ipvsman-9.0.3" or whatever is the version number.  
>>> This is a requirement of RPM specfiles.  Also, the general processing 
>>> expected is:
>>> ./configure
>>> make
>>> make install
>>>   
>>>     
>>>       
>> Thank you very much for this information. I will improve the 
>> installation for RPM based systems.
>>
>> To work around your problems. You should go to
>>
>> ipvsman_0.9.2-9.tar.gz/trunk
>>
>> and issue a
>>
>> #python setup.py install
>>
>> this shloud do the installation.
>>
>> Best Regards
>>
>> Volker
>>
>>
>>
>>   
>>     
> Hi again,
>   I found a target: bdist_rpm that is trying to create an RPM but it errors:
>
> # python setup.py bdist_rpm
> running bdist_rpm
> creating build/bdist.linux-i686
> creating build/bdist.linux-i686/rpm
> creating build/bdist.linux-i686/rpm/SOURCES
> creating build/bdist.linux-i686/rpm/SPECS
> creating build/bdist.linux-i686/rpm/BUILD
> creating build/bdist.linux-i686/rpm/RPMS
> creating build/bdist.linux-i686/rpm/SRPMS
> writing 'build/bdist.linux-i686/rpm/SPECS/ipvsman.spec'
> running sdist
> reading manifest file 'MANIFEST'
> creating ipvsman-0.9.2-9
> making hard links in ipvsman-0.9.2-9...
> hard linking ipvsman -> ipvsman-0.9.2-9
> 'ipvsman.py' not a regular file -- skipping
> hard linking ipvsmand -> ipvsman-0.9.2-9
> hard linking setup.py -> ipvsman-0.9.2-9
> creating dist
> tar -cf dist/ipvsman-0.9.2-9.tar ipvsman-0.9.2-9
> gzip -f9 dist/ipvsman-0.9.2-9.tar
> removing 'ipvsman-0.9.2-9' (and everything under it)
> copying dist/ipvsman-0.9.2-9.tar.gz -> build/bdist.linux-i686/rpm/SOURCES
> building RPMs
> rpmbuild -ba --define _topdir 
> /root/build/ipvsman/trunk/build/bdist.linux-i686/rpm --clean 
> build/bdist.linux-i686/rpm/SPECS/ipvsman.spec
> error: File 
> /root/build/ipvsman/trunk/build/bdist.linux-i686/rpm/SOURCES/ipvsman-0.9.2_9.tar.gz: 
>   
-----------------------------------------------------------------------------------------------------------^
syntax error _ instead of -


> No such file or directory
> error: command 'rpmbuild' failed with exit status 1
> # ls
> build   debian  ipvsman   ipvsmand_rh      lib       README.txt  
> svn-commit.tmp
> config  dist    ipvsmand  keepalived.conf  MANIFEST  setup.py    test.shtml
>
>
> Does it need for me to manually copy the tgz into SOURCES?
>
> Thanks,
> Gerry
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Ipvsman-users mailing list
> Ipv...@li...
> https://lists.sourceforge.net/lists/listinfo/ipvsman-users
>
>   

Re: [Ipvsman-users] ipvsman tarball

[Gerry R. <gr...@ve...>]

Dr. Volker Jaenisch wrote:
> Hi Gerry!
>
> Gerry Reno schrieb:
>   
>> Hi Volker,
>>   I have a suggestion involving packaging.  In order to support various 
>> downstream packaging such as RPM, the ipvsman tarball will need to 
>> conform to certain convention.  The high level directory name inside the 
>> tarball must be like "ipvsman-9.0.3" or whatever is the version number.  
>> This is a requirement of RPM specfiles.  Also, the general processing 
>> expected is:
>> ./configure
>> make
>> make install
>>   
>>     
> Thank you very much for this information. I will improve the 
> installation for RPM based systems.
>
> To work around your problems. You should go to
>
> ipvsman_0.9.2-9.tar.gz/trunk
>
> and issue a
>
> #python setup.py install
>
> this shloud do the installation.
>
> Best Regards
>
> Volker
>
>
>
>   
Hi again,
  I found a target: bdist_rpm that is trying to create an RPM but it errors:

# python setup.py bdist_rpm
running bdist_rpm
creating build/bdist.linux-i686
creating build/bdist.linux-i686/rpm
creating build/bdist.linux-i686/rpm/SOURCES
creating build/bdist.linux-i686/rpm/SPECS
creating build/bdist.linux-i686/rpm/BUILD
creating build/bdist.linux-i686/rpm/RPMS
creating build/bdist.linux-i686/rpm/SRPMS
writing 'build/bdist.linux-i686/rpm/SPECS/ipvsman.spec'
running sdist
reading manifest file 'MANIFEST'
creating ipvsman-0.9.2-9
making hard links in ipvsman-0.9.2-9...
hard linking ipvsman -> ipvsman-0.9.2-9
'ipvsman.py' not a regular file -- skipping
hard linking ipvsmand -> ipvsman-0.9.2-9
hard linking setup.py -> ipvsman-0.9.2-9
creating dist
tar -cf dist/ipvsman-0.9.2-9.tar ipvsman-0.9.2-9
gzip -f9 dist/ipvsman-0.9.2-9.tar
removing 'ipvsman-0.9.2-9' (and everything under it)
copying dist/ipvsman-0.9.2-9.tar.gz -> build/bdist.linux-i686/rpm/SOURCES
building RPMs
rpmbuild -ba --define _topdir 
/root/build/ipvsman/trunk/build/bdist.linux-i686/rpm --clean 
build/bdist.linux-i686/rpm/SPECS/ipvsman.spec
error: File 
/root/build/ipvsman/trunk/build/bdist.linux-i686/rpm/SOURCES/ipvsman-0.9.2_9.tar.gz: 
No such file or directory
error: command 'rpmbuild' failed with exit status 1
# ls
build   debian  ipvsman   ipvsmand_rh      lib       README.txt  
svn-commit.tmp
config  dist    ipvsmand  keepalived.conf  MANIFEST  setup.py    test.shtml


Does it need for me to manually copy the tgz into SOURCES?

Thanks,
Gerry

Re: [Ipvsman-users] ipvsman tarball

[Dr. V. J. <vol...@in...>]

Hi Gerry!

Gerry Reno schrieb:
> Hi Volker,
>   I have a suggestion involving packaging.  In order to support various 
> downstream packaging such as RPM, the ipvsman tarball will need to 
> conform to certain convention.  The high level directory name inside the 
> tarball must be like "ipvsman-9.0.3" or whatever is the version number.  
> This is a requirement of RPM specfiles.  Also, the general processing 
> expected is:
> ./configure
> make
> make install
>   
Thank you very much for this information. I will improve the 
installation for RPM based systems.

To work around your problems. You should go to

ipvsman_0.9.2-9.tar.gz/trunk

and issue a

#python setup.py install

this shloud do the installation.

Best Regards

Volker



-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

[Ipvsman-users] ipvsman tarball

[Gerry R. <gr...@ve...>]

Hi Volker,
  I have a suggestion involving packaging.  In order to support various 
downstream packaging such as RPM, the ipvsman tarball will need to 
conform to certain convention.  The high level directory name inside the 
tarball must be like "ipvsman-9.0.3" or whatever is the version number.  
This is a requirement of RPM specfiles.  Also, the general processing 
expected is:
./configure
make
make install

Regards,
Gerry

Re: [Ipvsman-users] ipvsman and keepalived

[Gerry R. <gr...@ve...>]

Volker,
  What a great writeup!  Thanks for this.

  I do have experience with heartbeat.  Some good, some bad.  Right now 
heartbeat is contributing in some way to a kernel oops when using NFS.  
I've sent details to Alan Robertson who is looking at this.  It may be 
NFS and not heartbeat but the problem does not occur if we shutdown 
heartbeat.  Anyway, yes, we run two network paths with heartbeat to 
prevent the split-brain and that was one of my concerns with 
keepalived.  keepalived is the younger technology so of course it will 
lack some features of heartbeat but I think the situation will not stay 
like this.  I think eventually VRRP will be favored by a lot of people. 
  I'm still a couple days away from digging in on ipvsman/d.  I'm dug in 
to a database cluster build.  But you've really whet my appetite after 
reading your writeup.  Can't wait to get started.

Thanks,
Gerry

[Ipvsman-users] ipvsman and keepalived

[Dr. V. J. <vol...@in...>]

Hello Gerry!
>>
>> Yesterday I wrote an import-filter for the keepalived.conf file which 
>> is included in the current release. You are welcome to be my first 
>> tester. To use the keepalived feature please run ipvsman this way:
>> #ipvsman -k
>> Just try it out and keep me informed.
> Yes, I think I will try this.  I should have time in about 2-3 days to 
> start.
Just tested myself. If have had no direct experiance with keepalived yet.

Keepalived is not very verbose in error reporting or talking with you at 
all.
One syntax error in the config and it is executed incomplete without any 
warnings.
Will talk about this on the keepalived list.

To spare you all my  pitfalls here a sample configuration that works
on my virtual XEN Cluster:

/etc/keepalived/keepalived.conf:
    virtual_server 10.3.0.2 80 {
        delay_loop 6
        lb_algo wrr
        lb_kind NAT
        persistence_timeout 300
        protocol TCP

        real_server 10.4.0.7 80 {
            weight 100
            HTTP_GET {
                connect_timeout 3
                url {
                    path /test.shtml
                    status_code 200
                }
            }
        }
        real_server 10.4.0.8 80 {
            weight 100
            HTTP_GET {
                connect_timeout 3
                url {
                    path /test.shtml
                    status_code 200
                }
            }
        }
    }

Please have a simple file with content "test" as /test.shtml delivered 
by your webservers.

do
#/etc/init.d/keepalived start
to stat keepalived as your livekeeper.

No configuration on ipvsman is needed if running ipvsman as:
#ipvsman -a -k

Version 0.9.1-7. Please type "h" for help.
Label         FW Shed Tra State                               
Label         Weight Conns CPS State
t:10.3.0.2:80 m  wrr  t    noService                          
t:10.4.0.7:80    100     0   0 http
                                                              
t:10.4.0.8:80    100     0   0 http
                                                              
------------------------------------
                                                                               
200     0   0
                                                              
====================================

The state "noService" is not entirely correct. ipvsman knows that the 
definition of the service
metadata for t:10.3.0.2:80 is not from its own service.cfg file (but 
from keepalived.conf) so it complains. Minor bug to be eliminated in 
0.9.1-8.

If 10.4.0.7 is shut down:

apoweb3:~# /etc/init.d/apache2 stop
Stopping web server (apache2)...apache2: Could not reliably determine 
the server's fully qualified domain name, using 10.4.0.7 for ServerName

you will get

Version 0.9.1-7. Please type "h" for help.
Label         FW Shed Tra State                               
Label         Weight Conns CPS State
t:10.3.0.2:80 m  wrr  t    noService suspended                
t:10.4.0.7:80      0     0   0 suspended
                                                              
t:10.4.0.8:80    100     0   0 http
                                                              
----------------------------------------
                                                                               
100     0   0
                                                              
========================================

and after restart of 10.4.0.7 we reach the initial state:

Version 0.9.1-7. Please type "h" for help.
Label         FW Shed Tra State                               
Label         Weight Conns CPS State
t:10.3.0.2:80 m  wrr  t    noService                          
t:10.4.0.7:80    100     0   0 http
                                                              
t:10.4.0.8:80    100     0   0 http
                                                              
------------------------------------
                                                                               
200     0   0
                                                              
====================================

Interactively addition and deletion of realserver works as I can see.
But as I stated earlier these changes have to be done manually in the
/etc/keepalived/keepalived.conf to make them permanent.

Please stop keepalived at this point and reset ipvs.
#/etc/init.d/keepalived
#ipvsadm -C

The same as above can be achived with ipvsman/ipvsmand

Define in /etc/ipvsman/service.cfg :

MyCluster:t:10.3.0.2:80 ["web1+:10.4.0.7-8"]

After
# ipvsman -a

Version 0.9.1-7. Please type "h" for help.
Label     FW Shed Tra State                                   Label 
Weight Conns CPS State
MyCluster m  wrr  t    notRunning noConfig                    
----------------------------
                                                                         
0     0   0
                                                              
============================
motRunning : Service has no active realservers yet.
noConfig : Service has no desired configuration.

So lets give it a desired config.

type "a"

Version 0.9.1-7. Please type "h" for help.
Label     FW Shed Tra State                                   Label 
Weight Conns CPS State
MyCluster m  wrr  t    notRunning noConfig                    
----------------------------
                                                                         
0     0   0
select reals                                                  
============================
[ ] web1
[ ] web2
< OK         >

Select e.g. web1 and web2, commit.

Version 0.9.1-7. Please type "h" for help.
Label     FW Shed Tra State                                   Label 
Weight Conns CPS State
MyCluster m  wrr  t    noConfig                               web1     
100     0   0 http
                                                              web2     
100     0   0 http
                                                              
----------------------------
                                                                       
200     0   0
                                                              
============================
We are running.

An shutdown of apache on web1 yield:

Version 0.9.1-7. Please type "h" for help.
Label     FW Shed Tra State                                   Label 
Weight Conns CPS State
MyCluster m  wrr  t    suspended                              web1       
0     0   0 suspended
                                                              web2     
100     0   0 http
                                                              
--------------------------------
                                                                       
100     0   0
                                                              
================================

Ups. Let's disable web1. press "a", uncheck web1,commit.

Version 0.9.1-7. Please type "h" for help.
Label     FW Shed Tra State                                   Label 
Weight Conns CPS State
MyCluster m  wrr  t                                           web2     
100     0   0 http
                                                              
----------------------------
                                                                       
100     0   0
                                                              
============================

Now a history of three desired configs have arrived on your harddisc:
1)
/var/lib/ipvsman/ipvscfg-2007-05-03_22:50 :
<empty>

generated by ipvsman from the actual state of the ipvs at first time 
starting of ipvsman.
It is empty since we have had cleared ipvs with ipvsadm -C.
2)
/var/lib/ipvsman/ipvscfg-2007-05-03_22:52 :
-A -t 10.3.0.2:80 -s wrr -p 300
-a -t 10.3.0.2:80 -r 10.4.0.7:80 -m -w 100
-a -t 10.3.0.2:80 -r 10.4.0.8:80 -m -w 100

This desired config was written as I commited the addition of web1 and web2.
You see the service first and then the two realserver mappings.
3)
The last desired config file in this history is
/var/lib/ipvsman/ipvscfg-2007-05-03_22:55 :
-A -t 10.3.0.2:80 -s wrr -p 300
-a -t 10.3.0.2:80 -r 10.4.0.8:80 -m -w 100

web1 aka 10.4.0.7:80 is gone.

This short story may have convinced you to use ipvsman/d without keepalived.

The heartbeat vs. VRRP battle still stands out.

After reading the configuration of the keepalived.conf I noticed the absence
of one crucial thing in VRRP : A good measure against a split brain 
situation.

We are using heartbeat not at least because we can use robust RS-232 
serial cables between
every of our two heartbeat-Servers to assure that in case of a partial 
network blackout
not to run into a split brain situation.

VRRP (in the implemetation of keepalived) relies on the availability of 
a network connection
between the two failover nodes. Heartbeat seems to me the fairly more 
robust approach.
As long as the serial connection between the two nodes stands the two 
servers can discuss which
of both has the better chance to fullfill the task of service. E.g. by 
comparing the
ping times/counts to the next router.

Thank you. I have learned a lot while writing this for you:
* VRRP is not as robust as heartbeat
* keepalived is much more difficult to run as I assumed

My now adjusted recomendation is to use:
* ipvsman
* ipvsmand
* heartbeat
for your project.

Best regards

Volker




-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

Re: [Ipvsman-users] ipvsman

[Dr. V. J. <vol...@in...>]

Hi Gerry!
Gerry Reno schrieb:
> Dr. Volker Jaenisch wrote:
>> Yes, but this feature is only one day old.
>> In principle there is no problem since ipvsman does only rely on the 
>> ipvs and the desired configuration but not on the daemon that 
>> controls the ipvs.
> Ok, so ipvsman is always looking at the ipvs kernel table for it's 
> information and does not interact directly with any daemon.
Exactly! Please have a look at 
http://wiki.inqbus.de/twiki/bin/view/Ipvsman/Dokumentation .
>>
>> So ipvsman uses the config file of keepalived and the status 
>> information of the ipvs and bring those two parts together in its GUI.
>> ipvsman is not a point and click GUI to interactively build the 
>> configuration file. In all cases you will have to build up a valid 
>> configuration file for keepalived (or for ipvsmand). ipvsman can be 
>> used without any configuration to adjust the weight of the 
>> realservers in realtime and have a look of the number of connections 
>> etc..
>> But if ipvsman should be able to take a realserver completely out of 
>> the loadbalancing it needs the meta information what realserver 
>> belongs to what service. So this functionality is only possible via a 
>> valid config file.
> Ok, so ipvsman cannot create a config file.  
ipvsman creates the desired configuration file. Its file format is 
compatible with ipvsadm -S -n.
> But if you use ipvsman to adjust the function of the realservers then 
> how can you preserve those changes over a reboot?
On reboot the ipvsmand will be started (if configured so). ipvsmand sets 
the state of the ipvs to that saved in the
actual desired config file.
>   Who/what takes care of changing the config file to reflect the 
> realtime changes you made with ipvsman?  
If you alter the state of the ipvs e.g. you adjust the weight of a 
realserver the daemon is not informed as long as you not
SAVE the actual config as the desired config. If you add or remove a 
realserver this changes will be told the
daemon exactly at the time you press OK in the gui. This was one of the 
mayor changes today. I am not absolutly happy with
that solution. From the point of the enduser it is ok - it looks as if 
ipvsman drives the daemon directly.
But this
1) is not the truth
2) is a simplification that can lead to errors
3) can lead people to the conclusion that ipvsman/ipvsmand is not as 
stable as an other lifekeeper since the GUI can interact with the daemon.

>>
>> Yesterday I wrote an import-filter for the keepalived.conf file which 
>> is included in the current release. You are welcome to be my first 
>> tester. To use the keepalived feature please run ipvsman this way:
>> #ipvsman -k
>> Just try it out and keep me informed.
> Yes, I think I will try this.  I should have time in about 2-3 days to 
> start.
cool. I like that. I will give you the best support.
>>
>> Due to the complete rewrite of the code for this public release lots 
>> of bugs were born. The ipvsmand part was severely broken. I'm just 
>> doing the fixes. Tomorrow you can expect 0.9.1-6 with smothly running 
>> ipvsmand.
> That sounds good.
Please use 0.9.1-7 released now. I have done lots of testing.
Fixed a whole bunch of bugs and the code has found its way back to 
stability.

Best regards

Volker

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

Re: [Ipvsman-users] ipvsman

[Gerry R. <gr...@ve...>]

Dr. Volker Jaenisch wrote:
> Yes, but this feature is only one day old.
> In principle there is no problem since ipvsman does only rely on the 
> ipvs and the desired configuration but not on the daemon that controls 
> the ipvs.
Ok, so ipvsman is always looking at the ipvs kernel table for it's 
information and does not interact directly with any daemon.
>
> So ipvsman uses the config file of keepalived and the status 
> information of the ipvs and bring those two parts together in its GUI.
> ipvsman is not a point and click GUI to interactively build the 
> configuration file. In all cases you will have to build up a valid 
> configuration file for keepalived (or for ipvsmand). ipvsman can be 
> used without any configuration to adjust the weight of the realservers 
> in realtime and have a look of the number of connections etc..
> But if ipvsman should be able to take a realserver completely out of 
> the loadbalancing it needs the meta information what realserver 
> belongs to what service. So this functionality is only possible via a 
> valid config file.
Ok, so ipvsman cannot create a config file.  But if you use ipvsman to 
adjust the function of the realservers then how can you preserve those 
changes over a reboot?  Who/what takes care of changing the config file 
to reflect the realtime changes you made with ipvsman?  Must this be 
done manually as in duplicating your changes, this time to the config file?
>
> Yesterday I wrote an import-filter for the keepalived.conf file which 
> is included in the current release. You are welcome to be my first 
> tester. To use the keepalived feature please run ipvsman this way:
> #ipvsman -k
> Just try it out and keep me informed.
Yes, I think I will try this.  I should have time in about 2-3 days to 
start.
>
> Due to the complete rewrite of the code for this public release lots 
> of bugs were born. The ipvsmand part was severely broken. I'm just 
> doing the fixes. Tomorrow you can expect 0.9.1-6 with smothly running 
> ipvsmand.
That sounds good.

Gerry

Re: [Ipvsman-users] ipvsman

[Gerry R. <gr...@ve...>]

Dr. Volker Jaenisch wrote:
> Hello Gerry!
>
> Gerry Reno schrieb:
>> Congratulations on the start of your ipvsman project! I posted a 
>> message to the ipvsman-user list.  Is it active yet? 
> Yes and no. The list was active but my email-address was wrong so I 
> don't get your posting.
> Sorry for that and thank you very much for informing me.
>
> To answer your question.
>
>> I am looking to setup a pair of
>> fault-tolerant load balancers that will route a virtual web IP to my
>> real webserver cluster nodes. I was originally thinking about heartbeat
>> and ldirectord or keepalived. How does ipvsman/d compare to these? Is
>> it an all-in-one type solution? Or do I still need some other things?
>> The description says that it replaces ldirectord. Ok, then what about
>> the heartbeat failover functionality? Do I still need heartbeat?
> ipvsman is more an all-in-one solution than ldirectord or keepalived
>
> in that way it's a realtime GUI plus a lifekeeping daemon.
>
> ipvsman does not address the problem of failover via heartbeat or VRRP 
> active active IP-sharing. I personally do not like all in wonder 
> solutions and like to divide things that are not much related to 
> reduce komplexity.
>
> Therefore in our cluster projects we run two loadbalancers running 
> ipvsman coupled over heartbeat as failover-pair. This setup is not 
> very complicated and robust enought for quite large mumber of 
> realservers.
>
> In addition we have some projects where we do only failover with 
> heartbeat and without loadbalancing at all.
>
> We have started with heartbeat and ldirectord. At this time keepalived 
> was not so well established as now. So I wrote ipvsman.
> So there are two possible advices I can give you.
>
> Use ipvsman/ipvsmand + heartbeat if you like a solution with 2 
> components.
>
> Use ipvsman + keepalived + heartbeat if you like a solution with 3 
> components or ipvsman + keepalived + VRRP.
>
> keepalived is much more complete than ipvsmand - it features more 
> availability checks, sorry_servers, firewall rules, VRRP etc.
>
> ipvsmand may have all this features some time. Our customers run sites 
> with 100 Mio. pagevisits per month with ipvsman/ipvsmand without 
> needing this advanced features.
>
> I hope this gives you a picture. Do not hesitate to ask further.
>
> Best regards,
>
> Volker
>
Volker,
  Thank you for this picture.  Would it be possible to use a combination 
of keepalived and ipvsman/d?  Can ipvsman drive keepalived?  Heartbeat 
is very much complex just for failover and I think I prefer keepalived 
for this function as well as maybe for load balance unless it would be 
better to use ipvsmand for the load balance function.

Gerry

Re: [Ipvsman-users] ipvsman

[Dr. V. J. <vol...@in...>]

Hello Gerry!

Gerry Reno schrieb:
> Congratulations on the start of your ipvsman project! I posted a 
> message to the ipvsman-user list.  Is it active yet? 
Yes and no. The list was active but my email-address was wrong so I 
don't get your posting.
Sorry for that and thank you very much for informing me.

To answer your question.

> I am looking to setup a pair of
> fault-tolerant load balancers that will route a virtual web IP to my
> real webserver cluster nodes. I was originally thinking about heartbeat
> and ldirectord or keepalived. How does ipvsman/d compare to these? Is
> it an all-in-one type solution? Or do I still need some other things?
> The description says that it replaces ldirectord. Ok, then what about
> the heartbeat failover functionality? Do I still need heartbeat?
ipvsman is more an all-in-one solution than ldirectord or keepalived

in that way it's a realtime GUI plus a lifekeeping daemon.

ipvsman does not address the problem of failover via heartbeat or VRRP active active IP-sharing. I personally do not like all in wonder solutions and like to divide things that are not much related to reduce komplexity.

Therefore in our cluster projects we run two loadbalancers running ipvsman coupled over heartbeat as failover-pair. This setup is not very complicated and robust enought for quite large mumber of realservers.

In addition we have some projects where we do only failover with heartbeat and without loadbalancing at all.

We have started with heartbeat and ldirectord. At this time keepalived was not so well established as now. So I wrote ipvsman. 

So there are two possible advices I can give you.

Use ipvsman/ipvsmand + heartbeat if you like a solution with 2 components.

Use ipvsman + keepalived + heartbeat if you like a solution with 3 components or ipvsman + keepalived + VRRP.

keepalived is much more complete than ipvsmand - it features more availability checks, sorry_servers, firewall rules, VRRP etc.

ipvsmand may have all this features some time. Our customers run sites with 100 Mio. pagevisits per month with ipvsman/ipvsmand without 
needing this advanced features.

I hope this gives you a picture. Do not hesitate to ask further.

Best regards,

Volker

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

[Ipvsman-users] test2

[Dr. V. J. <vol...@in...>]

test2

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

[Ipvsman-users] test

[Dr. V. J. <vol...@in...>]

test

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

[Ipvsman-users] ipvsman

[Gerry R. <gr...@ve...>]

  I ran across this project while searching for a load balancer/virtual 
router solution.  I didn't find a mail archive so forgive me if I am 
asking previously answered questions.  I am looking to setup a pair of 
fault-tolerant load balancers that will route a virtual web IP to my 
real webserver cluster nodes.  I was originally thinking about heartbeat 
and ldirectord or keepalived.  How does ipvsman/d compare to these?  Is 
it an all-in-one type solution?  Or do I still need some other things?  
The description says that it replaces ldirectord.  Ok, then what about 
the heartbeat failover functionality?  Do I still need heartbeat?

Gerry