[kwlug-disc] low tech traffic splitting
unsolicited at swiz.ca
Wed Feb 17 16:28:07 EST 2010
Correct me if I'm wrong / it's my impression and I'd be glad to hear
Aside from both Khalid's and John's messages (which are good stuff) ...
Khalid seems to be essentially saying, that simplest / single point of
serving / K.I.S.S. is best. (For maintaining your sanity.) As John
pointed out, see Khalid's signature. But (as per Khalid), you can
build up the robustness of your infrastructure, e.g. ensure adequate
pipe sizes (probably already in place), try to prefer static over
dynamic pages, and so on and so forth.
And John points out some ways to address things when the above
measures are inadequate.
It also seems to me, I'm guessing, you could split out your load if
you can, in the sense of the web servicing you are offering. So, for
example, if you have 'internal' clients / applications, as well as
these static web pages, on the same server, and they don't really
depend upon each other ...
If you create a second server, and put one or the other of these areas
on it, then when one gets nailed (and perhaps addressed via Khalid's
measures), the rest of your servicing won't be impacted. (Assuming
adequate pipe size, etc.) i.e. Split out functionality.
So, news, announcements, blogs, etc., on one server. Apps. on another.
Perhaps with a failover from the former to the latter, for uptime. The
last (perhaps?) via the round robin dns John mentions. And at time of
failure, you can make the call that either you'll get the non-app
server up in sufficient time that you can let the app server bear the
load for the moment, or that you're not able to achieve that and you
take the app-server out of the round robin. Leaving your static pages
unavailable for the moment, unfortunately, but at least continuing to
serve your clients.
Even in that situation you might hope that google caching will make
things less debilitating than they otherwise might be.
I'm guessing it would be useful for you to form a plan as to how you
might handle things, beforehand. [As you are doing now, of course.]
Such as, do you have that overloaded / redirect page in place "I'm
sorry, our servers are currently overloaded and you have been
redirected to this message. We are currently making best effort to
restore full functionality. Please check back with us in a little
while." that you can set in motion when you have to. Better to figure
out that contingency beforehand to effect when or if you have to, than
suddenly be there and have to think through things then, in panic
mode. e.g. If the load turns out to be too much for the app server,
and you're beating on the non-app server as quickly as you can, you
can enable this redirect so that you don't just disappear into the
void of unavailable / unresolved. a la wikiservices.openoffice.org,
For whatever this is worth.
john at netdirect.ca wrote, On 02/17/2010 2:22 PM:
> kwlug-disc-bounces at kwlug.org wrote on 02/17/2010 02:06:23 PM:
>> If we're trying to preplan for getting slashdotted on our webservers,
>> what's the best low tech way to handle that? I've got two identical
>> webservers I can light up, but don't know how to share traffic, sync,
>> etc. I suspect some type of clustering is the answer in linux these
>> days, but I don't even know what that really is :).
> It depends on your web application and back-end infrastructure. You need
> to answer this question: can I have both web servers fully utilised by
> clients without any problems. If each web server has its own database on
> which users leave data, can you consolidate the databases? Do users get
> meaningful cookies? Can you share the cookie database?
> Typically, for servers that are static, a round-robin DNS will be the
> simplest. Just add several A records for the same web site name. Put a
> suitably long Time-To-Live on the records so that clients can finish their
> business with the same server and you'll likely be okay. If one of the
> servers goes down then half your clients will get errors until the TTL
> runs out.
> For servers or applications that require state tracking (think SSL,
> cookies, shopping cart, etc.) then an application level proxy or load
> balancer is required. This is free software that tracks each session and
> makes sure that the user is directed to the same server. This is used in
> combination with RR DNS. Load balancers monitor back-end servers so if one
> goes down requests are forwarded to a surviving server. Users on failed
> servers would have their session disappear, similar to a time out. For
> redundancy two load balancing servers are used and are clustered so that
> if one goes down, the other will take it's load.
> Finally some back-end sharing of state is needed to ensure that if users
> are forced to another server their state is maintained, e.g. their
> shopping cart remains, etc.
> We have done work with Red Hat Cluster Server which bundles all the free
> tools for managing load balancing and failover of load balancers. It also
> handles application failover.
More information about the kwlug-disc_kwlug.org