|
>> If cookie management is at director level, and packets go in one-way
>> only, then:
>>
>> 1 - Client send request {req}. Request has no cookie attached.
>> 2 - Director sees no cookie, forwards to RS1
>> 3 - RS1 gives cookie COOKIE1
>> 4 - Packet goes out with {COOKIE1, reply}
>>
>> 5 - Client send new request {COOKIE1, newReq}
>> 6 - Director sees COOKIE1, but has no mapping information of it ?!?
>>
>
> You can use the persistence feature of LVS-DR to solve this cookie
> problem. If the virtual service is specified as persistent, all the
> requests from a single client (per IP address) will be redirected to the
> same server selected for the first request.
Is this a workaround?
>> This doesn't seems to be a problem specific to KTCPVS, but to all
>> arquitectures who do not use a "two-way" balancer.
>> Maybe the solution is completely different, and the balancer itself
>> inserts the control cookie?
>>
>> You'ld have
>> 1 -
>> 2 - Director sees no cookie, forwards to RS1 as {DIR_COOKIE1, req} 3
>> 4 - Packet goes out with {DIR_COOKIE1, COOKIE1, reply}
>> ...
>>
>> Is this the racionale behind KTCPVS phttp behaviour?
>>
>
> Yes, KTCPVS can remember the cookies and send requests according to the
> cookies, but current KTCPVS code doesn't support. We are thinking about
> adding this support.
If KTCPVS cant handle cookies, that means it can't insert/remove cookies
from the packets, only see them , right?~
So, KTCPVS was designed to work with (or as) LVS-NAT, as a proxy, right?
(doing two-way routing : From client to server, then from server to
client. At that second step it will record the cookie that the server
inserted, is that it?)
Thank you
|
