[kwlug-disc] low tech traffic splitting

[unsolicited]

Correct me if I'm wrong / it's my impression and I'd be glad to hear 
differently:

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, 
currently.

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.