|
Hello,
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-28.html#ss28.10
No comments... I agree all the line...
Well, I've already gotten several requests of porting LVS to other *BSD
variants :)
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."
Exactly what I thought was a little strange.
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 recently got a request by a group of students of a german university
to help porting LVS to NetBSD. The problem with porting LVS to another
Unix (BSD related in our case) is actually that there is about 10%
really Linux kernel specific stuff there which is either not portable
(framework doesn't exist) or must be completely rewritten. While going
through the TCP stack implementation of OpenBSD I just recall the
structure for hooking up a receiver for packets [Q: how do you mark
packets in OpenBSD :)]. You have quite a different way of accessing TCP
state transitions from kernel space. Following parts could pose a
serious porting trouble:
o export of statistics to proc-fs and tcp_defense strategy tunables
o hook a ipvs_service to the ip_fw struct in the masquerading code
o Julian's special HW_CHECKSUM workaround :)
o the (re-)routing and packet rewriting calls
What I would consider quite easy to port:
o the ipvs_service and load balancing modules (well not as loadable
kernel modules though)
o the user space tool :)
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.
Don't worry, at least Alteon Websystems knows about us :)
This is perhaps in its intention but if it is a new project he can be a
little overloaded at that time ?
I'm still not so sure if he wants to do load balancing in regard of the
load generated on the clients. If you check out his software, you see
that you need a client and a server. LVS provides the (network) load
balancing only, the notification/service takeout a third party modules
like keepalived, piranha and such.
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 !
LOL!
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.
In FreeBSD (CURRENT) kernelspace/userspace msg passing is actually a lot
more effective then under Linux (<2.5.x)
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, :) )
Exactly.
But IMHO I do not think loadd want to compete with LVS.
Exactly.
Yes CISCO & NOKIA & IBM => impluse by CISCO to replace their HSRP code
suffering security limitations.
With what do you want to replace such an established standard and teach
your customers to use it?
The VRRP code will be finish quickly (but still too busy to give a fixed
date) after my current fight with NIC MII-registers....
:) http://marc.theaimsgroup.com/?l=linux-kernel&m=101145413118679&w=2
and http://marc.theaimsgroup.com/?l=linux-kernel&m=101727648020657&w=2
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...
Seems to be the french people's most liked RFC. I wonder if this is
already translated to french (couldn't resist)
If you want docs on VRRP, I will be disponible for writing after my MII
hack...
What part is still missing?
PS: try to free my time for attempting OLS :)... not easy.... too busy :/
You'll better show up or I'll drag you up there. Seriously now, you
really need to sign up or you won't get a place anymore.
Best regards,
Roberto Nibali, ratz
|
