|
Hi Joe,
I hope that you are well.
> It's called the HighUpTime project.
People ask about LVS for xxxBSD and my reply is a FAQ.
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-28.html#ss28.10
No comments... I agree all the line...
I don't know what loadd is and I can't imagine why it takes
so long for everyone to find out about each other's projects.
Yes I doesn't know HUT too... AFAIK the main site is :
http://conan.lip6.fr/~spe/hut_hdpage1.html
Searching the web for "communication" activity on HUT show that it is a new
project (around 27 january 2002). Great a new project ! :)
But when I read : "When I try, one year ago, to search a product like
Altheon(tm), Big-IP(tm) etc... I don't find anything except a solution
under Linux systems. So, I have decided to write a Load Balancer and a VRRP
daemon for participate to the FreeBSD project."
It makes me think : Why not trying to port LVS to FreeBSD or why not
participating direclty to LVS ? You will benefit for the LVS maturity code
and that way will be able to capitalize on the knowledge embended... As a
matter of fact SAVE TIME ! which is the most important OpenSource base and
advantage for me :) And even more enhance the LVS code.
I expect the loadd guy knows about us at least. I'd be happy to hear a
"hello, we're doing something similar" from him and to put a note
in the HOWTO.
This is perhaps in its intention but if it is a new project he can be a
little overloaded at that time ?
A group in England about a year ago put out a press release for
their commercial software which they loudly proclaimed
as the first and only "Linux Virtual Server". It does different things
to LVS, but I would have thought they'd first do a google search on
the name. I assume they didn't know about us. I sent off a "hello,
we're a Linux Virtual Server project too" letter, but they never replied.
boring & not productive !
It has something called loadd, which
> hooks into FreeBSD's ipfw (like linux's iptables), to provide load
> balancing. There is also an interesting monitoring, ip-takeover daemon
> called vrrp, which I guess would be similar to mon?
When quick read the code, I can see that loadd is a userspace layer7
forwarder tool. Using loadbalancing algo like rr wrr lc wlc over a socket pair.
=> So the tool have to deal with an heavy overead whhen runing on high
bandwidth.... => spending most of the time copying buffers between
kernelspace & userspace.
LVS can not be compared to loadd since LVS is fully kernelspace and really
optimized, secure, design optimized, connection tracking nicely
handled....... (I can write many lines, :) )
But IMHO I do not think loadd want to compete with LVS.
vrrpd is a demon with its own RFC. I think cisco was around in the early
moments of its gestation, and may have initiated the whole thing,
but I don't really know.
Yes CISCO & NOKIA & IBM => impluse by CISCO to replace their HSRP code
suffering security limitations.
A French guy has done
an implementation of vrrpd for Linux and gave a talk about it at OLS last
year.
Yes Jerome Etienne realsed the first vrrp code.
Our own Alexandre Cassen (who has fingers in many pies) is doing another
implementation (or fork of the French guy's code) of vrrpd for LVS.
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-20.html#ss20.1
I don't know why Alexandre has had to redo the code - I believe the French
guy doesn't reply to e-mails.
Yes : Historicaly, I read the first Jerome Etienne code then work on the
IPSEC-AH part and create an enhanced release that I send to him. He never
reply to my emails even feedback/discuss on new design and the work I done.
So I decided to publish my work because he never update/patch with my
enhancements... => So I decided to put it on cheetah :
http://www.linux-vs.org/~acassen/vrrpd-0.6.tar.gz a release 0.6 for the
community.
Then after many thoughts, code design reading (network design patterns,
...), and always no reply from jerome etienne, I realize that many stuff in
vrrpd suffers a design limitation which limite an enhanced use. This is why
I take 2 weeks to design a framework for implementing VRRP. And since VRRP
can be closely use with LVS (since it is really designed for HA routers) I
decided to integrate in my thoughts some LVS specific functions (like
sync_instance & sync_daemon activation => currently working on that part)
=> vrrpd must be considered as a proof of concept tool : nicely coded ! can
be used on prod env but is limited to only 1 VRRP instance per NIC => for
some users it is enought but still too limited for others.
The design done : So what ... As I used keepalived in a previous devel, I
decided to implement VRRP in keepalived that way keepalived will be
designly enhanced and more robust. And all maintenance part will be done in
keepalived. The design is centralized on an I/O muliplexer used for all
parts of keepalived. In fact this I/O multiplexer is a generic scheduling
framework since all sheduling task in network code can be directly handled
upon I/O activity.
I have spend 1 year of thought to enhance both healthcheck & failover
(VRRP). So right now the design is stabilized and I am finishing some VRRP
parts to full test it in a production env. The current design of VRRP in
keepalived permit the use of multiple VRRP instances per NIC using a packet
dispatcher.
The VRRP code will be finish quickly (but still too busy to give a fixed
date) after my current fight with NIC MII-registers....
The Sebastien Petit VRRP code (freevrrpd) is nice, but since keepalived
framework is based on a generic I/O scheduler (the one from zebra), the
port to other UNIX env can be more quicker...
Alexandre's vrrpd together with keepalived etc appears to be the
current front-runner for the all bells and whistles, everything to all men,
software to setup and maintain an HA-LVS. Alexandre is working on it at
the moment,
and someday I expect to be deluged with a stack of documentation that will
take a week to read.
If you want docs on VRRP, I will be disponible for writing after my MII
hack...
Best regards,
Alexandre
PS: try to free my time for attempting OLS :)... not easy.... too busy :/
|
