Re: Anouncement: ipvsman/d more than a GUI to IPVS

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Anouncement: ipvsman/d more than a GUI to IPVS
From: Manuel Arostegui Ramirez <manuel@xxxxxxxxxxxxxx>
Date: Sat, 28 Apr 2007 23:17:44 +0200
El Sábado, 28 de Abril de 2007 22:50, Dr. Volker Jaenisch escribió:
> Hello Manuel!
> As I understand from overviewing your wiki-site pandora uses an pull
> aproach to gets it data from
> the modules. Please correct me if I'm talking nonsense ..
> If there were a push interface for pandora it shoud be no great deal to
> program ipvsmand to
> push events e.g. status changes of the realservers e.g. running->
> suspended oder suspended -> running
> to pandora.
> We are using zabbix and/or nagios to monitor the cluster server machines
> of our customers. We have never connected ipvsman/d with
> the monitoring. The reason is, that ipvsman/d knows not enougth of e.g.
> the web-portals it serves to give
> a clear answer on the crucial question "Is our portal running?"

I got it, this is not what I want either.
I meant, I want to take a deep look into ipvsman and how it works in order to 
find out some news ideas.
Actually PandoraFMS has several modules to do those things, one to keep apache 
under control and another one to monitor the content of a website (this could 
be useful to detected defacements, for instance).
And now, I've been dealing with loadbalancers, so I'll implement some modules 
for PandoraFMS to work with LVS.

> . Imagin 
> the following szenario : The backbone connection of the datacenter dies.
> In this case ipvsmand will think from its limited perspective that the
> world is in finest order.
> So we decided to monitor the reachability of the webportals from
> different sites in the internet and use this information as trigger in
> our monitoring software.

Well, what we actually want to keep under control are the status of Real 
Server, to monitor the portal or the content of a web we have other modules, 
as I wrote before,that is not the point here
Our scenario are like 5 machines after the loadbalancer which have LVS and 
I've already written an small module taking advantaje of ipvsadm output in 
order to know if any of the realserver went down, when went down I wanna mean 
one of the services the Real Server is supposed to serve, If so, and alert 
will be fired. 
I've also written some modules to get information about incoming packets/bytes 
to each node.
This is simply, I know, but keep in mind this is a spefic solution a client 
wanted us to do. So first off, I did what they want, and now, we're using 
that to improve PandoraFMS and build some more generalistic modules to work 
with LVS solutions :-)

> But if you go to the point of retrieving performance data e.g. conns per
> second per realserver or service then a linkage between ipvsmand and a
> monitoring software could be very fruitfully.
> It should be possible to write an interface (text-dump in file,
> tcp-status-port, xml-rpc, ..) to retrieve
> status information from the ipvsmand. You will know best what type of
> interface you like the most for application in pandora
> - just tell me.

Really? If it possible to get a dump file of all the data showed in ipvsmand? 
(I'm sorry I didn't go deep into ipvsmand, there's such a good weather in 
Madrid and I went out ;-)  )
Having a dump file with all the data in plain text would be wonderful, cause 
to write a module to parse all that data and send it to the PandoraFMS server 
would be so easy and that's _exactly_ what we need.

> ipvsmand has much more information on the loadbalancing as the output of
> ipvsadm you can give.
> ipvsadm shows only the actual state of the IPVS. ipvsadm knows nothing
> of an realserver that has been
> suspended (in terms of ipvsadm : ipvsadm -d -t xxxxx -r yyyyy) one
> second before you query ipvsadm - it is simply gone without a trace.
> ipvsmand knows the desired-configuration of IPVS, the cluster topology
> and the state changes that have happened.
> The datastructure of ipvsman/d is objectoriented :  Service instances
> own real server instances which know their state information.
> This information can be easily exported.

Again, if that's true (I trust you), that would be perfect for us and for 

Keep in touch, on or off the list :-)


Manuel Arostegui Ramirez.

Electronic Mail is not secure, may not be read every day, and should not
be used for urgent or sensitive issues.

<Prev in Thread] Current Thread [Next in Thread>