>
>Hello,
>
>On 2012-08-28 00:43, Hans Schillstrom wrote:
>> Hello
>>
>> [snip]
>>
>>>>
>>>> No loop? Because S2 will receive DR method in
>>>> the SYNC messages for its stack. You see traffic flow
>>>> or just that there is no reset?
>>>
>>> Yes, after the failover, all connections that were open on the S2 (which
>>> now becomes the active balancer) do not reset and continue to function
>>> just fine (traffic flow in both directions).
>>>
>>> We do understand (we think) your explanation about the sync table
>>> problem - the connections to the actual balancer are marked in a
>>> special way, which causes problems when these connection table records
>>> are used on a new balancer.
>>>
>>> It looks like updating the kernels is the only way, if (as you and Hans
>>> Schillstrom outlines) even the latest CentOS/RedHat kernels do not
>>> contain necessary patches. It's a pity, as the idea was to provide an
>>> "out of the box" solution for our customers, and asking them to update
>>> to some Linux kernel is not what they like to hear.
>>>
>>> But thank you very much in any case, we will update the kernels on our
>>> test systems and will see if this (last?) problem disappears.
>>>
>>
>> There is newer kernels floating around in the 3.x range
>> Have a look at ELRepo Project there you can find a 3.5.x kernel
>> that have all necessary changes.
>
>Installed CentOS 6.3 and the kernel 3.5.3 from elrepo.org
>
>[root@fe3 ~]# uname -a
>Linux fe3.msk 3.5.3-1.el6.elrepo.x86_64 #1 SMP Sun Aug 26 14:05:15 EDT
>2012 x86_64 x86_64 x86_64 GNU/Linux
>
>
>But we still see the same problem: connections to the old balancer are
>RSET'ed when the new balancer takes over. Any idea which particular
>kernel we need to use? Or, do we need to apply some specific patches and
>build our own kernel?
A silly question, old and new in this case
I hope it's a 3.5.x kernel in both cases ...
>
>Thank you for all your help so far!
>
>> BR
>> Hans
>>
>
>--
>Best regards,
>Dmitry Akindinov
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|