|
Peter,
On Wed, 8 Dec 1999, Skliarouk Peter wrote:
> Could you add an option to ipvsadm to print results in XML?
This wouldn't be a modification to ipvsadm, but would parse the
output/contents of /proc, which is probably as useful.
> I want to parse the results, put in an database and calculate some
> statistics (Perl,PHP,MySQL) with web frontend.
>
> DTD could be anything, but forewer.
I've been off work for a while so I hadn't put this anywhere, in the
meantime I've been looking at XML docs and stuff, and how about the
following DTD? First draft obviously.
<!-- LVS.dtd V0.0 for LVS V0.8.3 DTD for LVS state snapshots -->
<!ELEMENT VirtualServerRecord (service*)>
<!ATTLIST VirtualServerRecord lvs-dtd-version CDATA "0.0">
<!ATTLIST VirtualServerRecord lvs-version CDATA "0.8.3">
<!ATTLIST VirtualServerRecord hostip CDATA "127.0.0.1">
<!ATTLIST VirtualServerRecord vhostip CDATA>
<!ELEMENT service (realserver*)>
<!ATTLIST service type CDATA (UDP|TCP) #REQUIRED>
<!ATTLIST service service-ip CDATA #REQUIRED>
<!ATTLIST service port CDATA #REQUIRED>
<!ATTLIST service scheduler (wlc|pcc|rr|wrr) "wlc">
<!ELEMENT realserver (weight, activeconns, inactiveconns)>
<!ATTLIST realserver serverip CDATA #REQUIRED>
<!ATTLIST realserver serverport CDATA #REQUIRED>
<!ATTLIST realserver forwarding (local|direct|masquerade|tunnel) "direct"
#REQUIRED>
<!ELEMENT weight (#PCDATA)>
<!ELEMENT activeconns (#PCDATA)>
<!ELEMENT inactiveconns (#PCDATA)>
Any errors that anyone can spot with the DTD would be much appreciated!
Code to take the output of ipvsadm, and produce XML conforming to the
above will be found in:
http://epsilon3.mcc.ac.uk/LVS/
Some time today. Some sample output (IPs changed) is there now.
(Very much alpha code, but works, and will be integrated into something
larger shortly)
Regarding the IPs associated with the director (the hostip/vhostip etc),
I'm rapidly coming to the conclusion that in a VS-TUN environment, it's
useful for the director to have 3 IP addresses. One which is the real
machines base IP address, one which is the virtual service IP address, and
then another virtual IP address for servicing the director. The reason for
this is associated with director failover.
Suppose:
* X realservers pinging director on real IP A (assume a heartbeat style
monitor) serving pages off virtual IP V. (IP A would be in place of
hostip above)
* Director on IP A fails, backup director (*) on IP B comes online taking
over the virtual IP V. By not taking over IP A, IP B can watch for IP
A to come back online via the network, rather than via a serial link
(etc).
* Problem is the realservers are still sending to IP A for the heartbeat
code to be valid on IP B, the realservers need to send their pings to
IP B instead. IMO the easiest solution is to allocate a we need a
"heartbeat"/monitor virtual IP. (this is the vhostip)
(*) This is a realserver in our cluster.
Michael.
--
National & Local Web Cache Support R: G117
Manchester Computing T: 0161 275 7195
University of Manchester F: 0161 275 6040
Manchester UK M13 9PL M: Michael.Sparks@xxxxxxxxxxxxxxx
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
