Hi On Sun, 2008-02-10 at 11:23 -0500, Sailesh Krishnamurthy wrote: > Thanks for that input, what I am looking for is more along the lines > of what would be the benefit of a web server farm, what would be the > design considerations and so on... How long have you got? The design considerations of a "farm" approach (or cluster, or pool, or whatever terminology you choose to use) are myriad, and depend entirely on what you're setting out to achieve. The principle benefit of a "farm" is one of resilience - failure of a single node does not render your service unavailable. Wedded to that is scalability - if you know you have a period of high load coming, you put in more servers. If you start to deliver a resource-hungry app, you put in more servers. If you want to do maintenance on part of your farm but not affect your service, you put in more servers; if you want to deliver a completely new service, guess what? You see where this is going :) And so on, and so forth. In the simplest sense, you start out with a "farm" of one machine running a simple webserver with no complex applications. If the server or machine (or network) fails (for whatever reason), the sites hosted by the server are inaccessible. Then you move to two servers - one serves all requests in normal operation, and when it fails you manually configure the other machine to take over. That gives a little bit more continuity and makes your system a bit more robust but requires human intervention to, for example, keep all the files up-to-date on the spare machine. Time passes, friend... Your company ends up with many (tens, hundreds, thousands, tens or hundreds of thousands, millions even) of customers who have many and varied requirements - Apache, CGI, PHP, Java servlets, .NET environments, IIS, Websphere, NGINX, lighttpd, MySQL, PostgreSQL, MS SQL Server, hell even IBM's DB2 or Oracle - suddenly you're several orders of magnitude away from your initial "farm" idea. You need a load balancer (software or hardware). In order to ensure you don't lose service when that needs patching (or breaks), you need two. They have to failover transparently between themselves, with state sharing so sessions don't get broken on failover. In order that a network outage doesn't cause a service delivery failure, you need another two on a physically different network. So a local power outage doesn't cause a failure, you need that network to be in a different location. The load balancers need to be application aware, or have an additional system which monitors the other systems which make up the "farm" and stop sending requests to them if they fail. They also need to notify a human being if they do fail (although the threshold for this is dependent on your available resources). To make sure you don't stop doing that, you need more than one machine doing the same task; with multiple locations you end with multiple machines. On top of that, because all your customers' data needs to be accessible from all the servers in the farm in all those different locations, you need replicated storage which does real-time, block-level replication with minimal latency. You therefore need a decent inter-location infrastructure, multiple paths between the two (three, four, five) locations; you need a way to validate the data integrity at each location so you don't end up serving stale data. I could go on, but I won't. The possibilities are quite literally endless and depend entirely on what you need to achieve. In your case - active/passive - assuming they're Linux boxes, you have load balancing built in to the kernel already. Google for IPVS or LVS, keepalived, heartbeat, ldirectord; look at the load balancing module(s) available for Apache. You can move quite quickly to active/active from your current position without too much pain; much of the pain will come from your backend storage. Graeme --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|