Hello,
>> PersistConn: 99.6622%
>> ActiveConn: 250.664%
> But this ActiveConn is strange, are some sync messages
> dropped/lost here due to high sync traffic? Even HZ/10 does not
> help here?
There was no dropped or lost packets on both nodes.
But abnormally high number of ActiveConn on the Backup server.
>> Have you thought about the possibility to distribute sync load on
multiple
>> processors?
> May be it is possible to use additional netlink
> parameter to provide the desired number of threads.
Please let me know if I can help with tests.
>> Do we really need "Virtual IP:Port" information for Fwmark? Can we use
>> "0.0.0.1:80" or better "0.0.0.1:0"?
>> 1. With "0.0.0.1:80" we can sync connections to LVS servers with
different
>> VIPs (in different data centers for example) - very useful for
scalability
> You mean, to avoid sync for normal conns when
> conn templates are synced anyways? The problem is that
> on role switch we should have correct cp->state. We
> do not create conns for packets without SYN bit. Of course,
> it can work for UDP and when no real servers are failing
> and being replaced.
>
>> 2. With "0.0.0.1:0" we can reduce the number of connections entries by
>> aggregating them
> This is what we use, dport=0. Single conn template
> for all normal connections from client that are with same mark.
>
>> Are there any potential problems?
> Wihtout syncing the normal connections to backup
> we are not sure that they are really using the real server
> that is currently assigned to connection templates. And
> the stateful method that is currently used does not allow
> to avoid such sync. The new persistence engines will
> require syncing. But for some normal cases may be it can
> work to reduce the sync traffic when persistence is used
> without stateful inspection.
Thanks for the clarification.
Regards,
Aleksey
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|