|
Hello,
Agreed, except with the speed issue. A session state cannot be the
bottleneck or you have commited a serious design crime to your whole
application.
I have never measured it myself, but it seems to me that fetching data from
shared storage or a database is by definition slower than fetching it from
RAM. And our database is already a bit heavily loaded, so I'm not too happy
with adding extra load to it for session state storage...
Ok, now I understand. You want to equalize the let's call it fictive load
imbalance caused by 'cached' session IDs?
s/connected/directed/
Ok.
WLC reassigns per HTTP request for non-persistent connections or per IP
address for persistent connections. What I was thinking about is that as long
Yes. But it takes into account the amount of connections (I think
active*50+inactive) which is to 95% a direct result of the servers load and CPU
idle time.
as all servers are available and have a similar load that LVS keeps
redirecting you to the same realserver and only reassigns when needed to
restore the balance or handle a failover condition.
Why do you want to do this? If all server have similar load and you keep on
redirecting a session to the same RS, this RS will be overloaded while the
others start idling. If you distribute the load according to your scheme (if I
understand it correctly) then you wouldn't send a new incoming connection
request to a new server.
This all with the idea that session storage is faster from RAM so you want to
stick with one realserver if possible. If that point is moot (that's what I
understand from you, but I don't understand why) this is obviously no longer
an issue and you can disregard my entire mail ;-)
Let's give it a practical touch:
We have RS1 to RS3, all the same weight of 1, initial status is
RS[123]_SESS->disk. Connection 1 is C_START->IP1 to C_END-IP1 with END-START
packets. I set the WLC scheduler and persistency.
--------------------+------------------------+------------------------
flow | RS, RS_SESS->? | state
--------------------+------------------------+------------------------
C_START->IP1 | RS1, RS1_SESS->disk | passive -> active
C_PACK2->IP1 | RS1, RS1_SESS->RAM | active
C_PACK3->IP1 | RS1, RS1_SESS->RAM | active
C_PACK4->IP1 | RS1, RS1_SESS->RAM | active
====================> this goes on and on <========================
C_START->IP2 | RS2, RS2_SESS->disk | passive -> active
C_END->IP2 | RS2, RS2_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
C_START->IP3 | RS3, RS3_SESS->disk | passive -> active
C_END->IP3 | RS3, RS3_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
C_START->IP4 | RS4, RS4_SESS->disk | passive -> active
C_PACK2->IP4 | RS4, RS4_SESS->RAM | active
C_END->IP4 | RS4, RS4_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
C_START->IP5 | RS2, RS2_SESS->disk | passive -> active
C_END->IP5 | RS2, RS2_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
C_END->IP1 | RS1, RS1_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
C_START->IP6 | RS3, RS3_SESS->disk | passive -> active
C_END->IP6 | RS3, RS3_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
C_START->IP7 | RS1, RS1_SESS->disk | passive -> active
C_END->IP7 | RS1, RS1_SESS->RAM | active -> passive
--------------------+------------------------+------------------------
Does it make sense? Warning: This is one possibility of how the load balancer
would redirect the incoming requests. I have not taken into account the timing
and the packet size, but nevertheless it should show you what I intended to
explain in words before.
If you have 3 realservers one of them sets up a session and keeps the session
state in RAM. It's most efficient to return to that realserver because the
other realservers don't have the session state yet. They can fetch it from
the database, but that's slower than simply fetching it from RAM.
That's why you will need persistency. Persistency will assure you that you get
back to that RS once the session ID is in RAM for that specific client. New
incoming requests will go to the RS with the least amount of (something in the
line of that formula, I didn't check it):
100 * (50 * RS->active_conns + RS->inactive_conns) / RS->weight
If it's only for failover this can also be achieved using the sysctl flags
that Joseph now finally documented in the HOWTO (thanks!), if it's also
for
Where did he document new sysctrl flags for failover or do I misunderstand
you again?
http://www.linuxvirtualserver.org/docs/sysctl.html, expire_nodest_conn. Set
it to non-zero and at least you get proper failover reassignments from LVS
AFAICS. My LVS doesn't have this option yet, but that's what I read from the
docs.
:) It was even me with an email last week that caused this. My brain has some
serious dysfunction sometimes.
Well, WLC is either per-request or per-ip. Per-request is too often and per-ip
is too little, because it doesn't reassign even if the balance is completely
skewed, nor does it cope with failover.
I say you start using persistency with WLC and if you experience extremely load
imbalance, I will assure you that we will fix the problem withing 96 hours. Also
note that load imbalance is not measured after 10 Minutes, but after about 3
days. If you monitor your sessions and the load of all RS the mean amount of
connections should be the same as for every single RS. If not, we need to take
further actions and address this issue.
Again, I'm only assuming that session state transition is as expensive as the
site developers are trying to tell me, I haven't measured it myself yet.
Aha, and what number of requests/s + amount of bytes/s and RS machines are we
talking about?
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
