Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We are running a a web application on our test system (CentOS) like this - one Web-server (apache), two tomcat instances running the same web application, one PostgreSQL database - each on four virtual servers. The application is [meant to be] used by thousands of users and also requires some storages of sensitive user data. We are planning to move this into a production system and seeking some advice on choosing the right hardware for this functionality. I'm pretty much open to any suggestions (VM or dedicated or mixed) that cost effective and suits the best in this environment. I think I'm looking for is instant failover. Can any one suggest me a spec and any extra equipment(s) may required to run these services?

Couple of things in my mind: For the DB server, I'm thinking a dedicated server - RAID 1 mirrored for the system disk and RAID10 for the DB (local storage). Or should we go for some shared storage with FC? Fastest disks for the tomcat (that's the bottleneck - isn't it?), Round-Robin DNS for Web Server failover and dedicated GbE per box for I/O bandwidth to the net. But I'm pretty much interested to see how others design their system (CPU, RAM, extra H/w, process etc.) keeping this requirements in mind. Any input welcomed and very much appreciated. Thanks in advance. cheers!!

share|improve this question

closed as off topic by sysadmin1138 Jan 5 '12 at 3:12

Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Unfortunately, the actual code plays a major part in how far and fast this can scale. Each of these technologies has ways to handle scale/failover, but if the programming doesn't take those methods into account it makes it a lot harder. –  sysadmin1138 May 28 '11 at 20:49
    
I knew that I'm gonna get this answer (at least from one), because whatever you said is very true. I'm not looking for anything in specific, but some generic opinion which fits in this sort of application. Cheers!! –  La Scavenger May 28 '11 at 21:21

1 Answer 1

up vote 0 down vote accepted

On the httpd/tomcat side, the way we do this is:

on a single server, run one httpd and two instances of the tomcat on different ports. We use mod_jk to talk to the tomcats over ajp and configure mod_jk to load balance between the two (or in some cases, an active/passive failover and let mod_jk figure out when to failover).

We run multiple server instances of the above, with an actual hardware load balancer in front that talks to all the httpds. To deal with the single point of failure that the hardware load balancer is, we replicate this entire setup at a different datacenter, then use DNS games to load balance people geographically using Dynect (which also has the ability to shift load over to the other datacenter during failure).

Part of the reason we run two instances of tomcat on each server is so that we can more easily apply software updates to an application without affecting our ability to handle peak load. Yes, this makes us have 2x the RAM requirement, but that's much cheaper than having to double the number of systems to operate the way we operate.

In your setup, you're handling the case of a single tomcat server dying, but not the front end httpd. You might be better building a pair of front end httpd servers that use heartbeat/corosync/pacemaker to handle front-end failover. It won't be "instant failover", but it'll be close to it. Most people can tolerate a few seconds as things switch around.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.