All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksey Chudov <aleksey.chudov@gmail.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: lvs-devel@vger.kernel.org
Subject: Re: [PATCH] Sloppy TCP, SH rebalancing, SHP scheduling
Date: Tue, 28 May 2013 16:41:01 +0300	[thread overview]
Message-ID: <51A4B3ED.4070809@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1305280011490.1728@ja.ssi.bg>

On 28.05.2013 0:31, Julian Anastasov wrote:
> On Fri, 24 May 2013, Aleksey Chudov wrote:
>
>> May be better to modify the sync algorithm to synchronize only persistence
>> templates for these specific cases? Is it possible at all?
> 	May be, with some flag and also sloppy_tcp. Then the
> parametrized SH with netmask will do the same - we can avoid
> the sync messages. Of course, with SH there is more risk
> for imbalance and it can be exploited. Also SH requires
> equal configuration for the real servers.
>

Currently we are using multiple active / standby server pairs and 
synchronize them with each other. So half of the servers are constantly 
doing nothing. We are searching how to use all the servers in active / 
active mode while maintaining high availability and sessions persistence 
in case of failure of one of the load balancers. Unfortunately the 
proposed stateless scheme with SH scheduler and Sloppy TCP is not 
suitable for as since we are using WLC and WRR schedulers. As you 
mentioned SH scheduler has several drawbacks because of which we can not 
use it. Also, we can not synchronize all connections between all 
servers, since it would require a lot of memory and the search for such 
a huge connection table is likely to be slower.

But we can solve the sync problem in such a way as done in the 
conntrackd which allows filtering by flow state. The easiest option is 
to make the filter only for IP_VS_CONN_F_TEMPLATE state. Thus if all the 
load balancers will sync persistent templates with each other then even 
if one of the load balancers fails most users will remain on the same 
real servers. Of course without the full sync clients must reestablish 
TCP connections, but for this case we can use Sloppy TCP to create a TCP 
connection state on any TCP packet.

What do you think of this idea?



Regards,
Aleksey

  reply	other threads:[~2013-05-28 13:41 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 12:09 [PATCH] Sloppy TCP, SH rebalancing, SHP scheduling Alexander Frolkin
2013-05-24 15:05 ` Julian Anastasov
2013-05-24 15:14   ` Alexander Frolkin
2013-05-24 16:18     ` Aleksey Chudov
2013-05-27 21:31       ` Julian Anastasov
2013-05-28 13:41         ` Aleksey Chudov [this message]
2013-05-30  6:37           ` Julian Anastasov
2013-06-07  7:53             ` Alexander Frolkin
2013-06-19  9:03           ` Julian Anastasov
2013-06-19 19:25             ` Julian Anastasov
2013-06-20 17:02               ` Aleksey Chudov
2013-06-20 20:09                 ` Julian Anastasov
2013-06-19 20:44             ` Aleksey Chudov
2013-06-22 11:20             ` [PATCH] ipvs: add sync_persist_mode flag Aleksey Chudov
2013-06-22 12:43               ` Julian Anastasov
2013-06-22 21:11                 ` Aleksey Chudov
2013-06-23  8:34                   ` Julian Anastasov
2013-06-24 14:37                     ` Aleksey Chudov
2013-06-24 19:57                       ` Julian Anastasov
2013-05-27 21:11     ` [PATCH] Sloppy TCP, SH rebalancing, SHP scheduling Julian Anastasov
2013-06-07  8:12       ` Alexander Frolkin
2013-06-10 19:31         ` Julian Anastasov
2013-06-11  8:38           ` Alexander Frolkin
2013-06-11 19:57             ` Julian Anastasov
2013-06-12 14:10               ` Alexander Frolkin
2013-06-12 20:47                 ` Julian Anastasov
2013-06-13  8:38                   ` Alexander Frolkin
2013-06-13 12:56                   ` Alexander Frolkin
2013-06-13 19:50                     ` Julian Anastasov
2013-06-13 14:18                   ` Alexander Frolkin
2013-06-13 20:31                     ` Julian Anastasov
2013-06-14 10:22                       ` Alexander Frolkin
2013-06-16  6:52                         ` Julian Anastasov
2013-06-17  8:32                           ` Alexander Frolkin
2013-06-17  9:00                             ` Julian Anastasov
2013-06-17  9:04                             ` Julian Anastasov
2013-06-17 11:11                               ` Alexander Frolkin
2013-06-17 20:05                                 ` Julian Anastasov
2013-06-18  9:30                                   ` Alexander Frolkin
2013-06-18 20:52                                     ` Julian Anastasov
2013-06-14 11:47                       ` Alexander Frolkin
2013-06-16  8:30                         ` Julian Anastasov
2013-06-17 10:35                           ` Alexander Frolkin
2013-06-17 19:48                             ` Julian Anastasov
2013-06-18  9:08                               ` Alexander Frolkin
2013-06-18 20:41                                 ` Julian Anastasov
2013-06-10 15:12       ` Alexander Frolkin
2013-06-10 16:03         ` Alexander Frolkin
2013-06-10 20:52         ` Julian Anastasov
2013-06-11 12:38           ` Alexander Frolkin
2013-06-11 20:13             ` Julian Anastasov
2013-06-12 10:49               ` Alexander Frolkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A4B3ED.4070809@gmail.com \
    --to=aleksey.chudov@gmail.com \
    --cc=ja@ssi.bg \
    --cc=lvs-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.