Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[lvs\-users\]\s+persistence\s+and\s+destination\s+IP\s+hashing\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[lvs\-users\]\s+persistence\s+and\s+destination\s+IP\s+hashing\s*$/: 7 ]

Total 7 documents matching your query.

1. Re: [lvs-users] persistence and destination IP hashing (score: 1): Author: Malcolm Turnbull <malcolm@xxxxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 17:31:45 +0100; David, The way I understand it is that as long as the hash table server pool size does not change then the hash will always hit the same server (irrespective of weight). That is the way it worked on; /html/lvs-users/2014-10/msg00015.html (27,450 bytes)
2. Re: [lvs-users] persistence and destination IP hashing (score: 1): Author: David Waddell <David.Waddell@xxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 15:14:08 +0000; Malcolm, Supposing we could define a pool of IPS for real servers before they exist - would we not still need persistence, to prevent requests being steered to a different real server, as weight was; /html/lvs-users/2014-10/msg00014.html (23,730 bytes)
3. Re: [lvs-users] persistence and destination IP hashing (score: 1): Author: David Waddell <David.Waddell@xxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 14:40:03 +0000; Hi Malcolm (not matt! Apologies for that). I see what you mean; we can avoid re-hashing if the pool size if fixed, and use weights to control 'real' membership of the pool . We're looking at auto sca; /html/lvs-users/2014-10/msg00013.html (22,205 bytes)
4. Re: [lvs-users] persistence and destination IP hashing (score: 1): Author: Malcolm Turnbull <malcolm@xxxxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 15:11:46 +0100; David, Ah I see , my mistake I read it too quickly... As far as I'm aware the only thing you could try is to pre-populate the hash algorithm i.e. Setup 10 backend servers at the start... But only hav; /html/lvs-users/2014-10/msg00012.html (21,250 bytes)
5. Re: [lvs-users] persistence and destination IP hashing (score: 1): Author: David Waddell <David.Waddell@xxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 13:59:25 +0000; Hi Matt, Thanks for the reply. We have a setup much like you describe - requests are being made directly to web server, and we route these to the lb and the LB processes using fwms. The DH algo is wo; /html/lvs-users/2014-10/msg00011.html (18,606 bytes)
6. Re: [lvs-users] persistence and destination IP hashing (score: 1): Author: Malcolm Turnbull <malcolm@xxxxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 14:21:36 +0100; David, The dh scheduler only really works if the kernel can see the destination address, what you need is for traffic passing through the load balancer to be transparently load balanced to its destin; /html/lvs-users/2014-10/msg00010.html (15,942 bytes)
7. [lvs-users] persistence and destination IP hashing (score: 1): Author: David Waddell <David.Waddell@xxxxxxxxxxxxxx>; Date: Fri, 24 Oct 2014 13:11:06 +0000; Hi We are trying to use LVS as a virtual load balancer around a transparent http proxy, and are wondering if it is possible to use persistence and destination hashing together (from our tests; /html/lvs-users/2014-10/msg00009.html (16,394 bytes)

Current List: 1 - 7
Page: [1]