active-active only works with kernel 2.4.26?

[Michael Spiegle]

Francisco,
Your explanation makes perfect sense and it is in-line with the 
whitepaper published, but my issue is with this statement:

"So one of the -->most important thing<-- here, is that no director has 
to put the virtual-MAC in the wire, as every director has to receive the 
packet."

If every director receives every packet, how can you possible support 
traffic beyond 100% of a single director?  Lets say you have 5 directors 
with 1gbit interfaces each, and you have 1.5gbit of traffic coming over 
the wire.  That 1.5gbit of traffic has to be mirrored on each of the 5 
directors.  Unfortunately, each of the 5 directors only has a 1gbit 
link, so how can the director process all 1.5gbit of traffic?

Or, can active-active LVS not increase bandwidth?

---
Michael Spiegle
mike at nauticaltech.com



Francisco Gimeno wrote:
> Hello
>
> as far I remember the thing work something like this:
> - All director nodes know about the others
> - Each one have an ID ( for example, the MAC or the IP )
> - Each director node can elaborate a sorted list based on that ID
> - Heartbeat everywhere, so the list is dynamic list
> - The "view" of each node should be the same for each node (ie: all nodes 
> should have the same list)
> - They should have a virtual-MAC
> Those requirements could be satisfied with a broadcast sync protocol (it could 
> be similar to the WCCP, for example)
>
> for each packet it arrives,
> - Make a HASH with the parameters you want to keep the __affinity__ (like src 
> IP, dst IP, ports, ...) to.
> - Calculate HASH % numer_of_nodes ( % := module )
> - If that value it's the order in the list for the node processing the packet, 
> the packet is accepted, if not, discarded.
> As every packet go to every director...
>
> So one of the -->most important thing<-- here, is that no director has to put 
> the virtual-MAC in the wire, as every director has to receive the packet. Arp 
> responses to the VIP should be the virtual-MAC, but it should be sent with a 
> bogus-MAC. With that, the responsible to route packets to the VIP, will send 
> the packets to that virtual-MAC. As the switch (L2) don't know the physical 
> port associated to it, it sends the packet to all the active ports that 
> hasn't a MAC associated which are the director's. If you use a HUB then, 
> there will not be this kind of problems (who ownes a HUB nowadays?).
>
> I hope I help you understanding how it works...
>
> BR,
> Francisco Gimeno
>
>   
>> Roberto,
>> My thoughts exactly!  It doesn't seem like it should be possible, but
>> Horms sure knows his stuff.  Maybe he can chime in and elaborate on
>> those details?
>>
>> ---
>> Michael Spiegle
>> mike at nauticaltech.com
>>
>> Roberto Nibali wrote:
>>     
>>>>>> I just just built 2 fresh gentoo boxes for testing active-active.
>>>>>> I had
>>>>>>             
>>>>> How is active-active possible
>>>>>           
>>>> it's Horms experimental code called Saru. He explained it at OLS one
>>>> year you didn't come.
>>>>
>>>> http://www.ultramonkey.org/papers/active_active/active_active.shtml
>>>>         
>>> Downloaded and printed, will read this weekend. Although, if Horms
>>> engineers something it's most likely flying anyway. So I just have to
>>> understand how he cheated the TCP stack this time :). I see some
>>> netfilter related stuff in it and I wonder if (from what I've seen)
>>> his approach works for 2.6.x kernels with proper TCP state tracking,
>>> TSO and USO? In 2.4.x where netfilter is mostly broken with regard to
>>> TCP state tracking, such quirks might be possible.
>>>
>>> Cheers mate,
>>> Roberto Nibali, ratz
>>>       
>> _______________________________________________
>> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
>> Send requests to lvs-users-request at LinuxVirtualServer.org
>> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>>     
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
>
>