Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to build an architecture with Virtual Servers for J2EE Web applications Hosting. I've no experience in virtualisation. I currently have 1 server whith Apache/Jboss/Postgresq/Proftpd installed and I want to design something where services run on different servers.

1 HTTP Load Balancer (+ 1 HTTP server for failover)--> Multiple Application Servers or web servers--> Database Server (+ 1 server for replication)

Files will be stored on SAN and 2 servers for Database and HTTP Load Balancer (not virtual)

Here is what I have in mind: Architecture

  • What do you think about this architecture?
  • Is Jboss running well on Xen (or VMWare) virtual machines?
  • Is heartbeat the best tool to get failover?
  • Am I right to put the database on a dedicated server (and not on SAN)?
  • my SAN will be used for static files (images...). Should I use iSCSI or Fiber Channel?

Thank You !!!

share|improve this question
Hi, I know this is off-topic, but I'd like to ask you something: where did you get the server pictures that you used in your diagram? They look good! – mfriedman Aug 21 '09 at 14:55
Hi, I use Visio 2003 ;-) – Matthieu Aug 21 '09 at 15:05
up vote 1 down vote accepted

Minus the FTP, that diagram looks very like one of our systems, which has been working fine for us. As for some of your other points:

  • We've got a few RH4 virtual machines (ESX 3.5) running JBoss, and they're all fine. Just keep JBoss's memory requirements in mind when you're building the virtual boxes.

  • If you can afford it, I'd definitely go for an FC-based SAN if you're either anticipating high throughput or future expansion.

  • In my experience, there isn't much performance difference between a physical DB server with a good disk subsystem and a virtual one accessing the SAN.

share|improve this answer

Generally fine, I'd 100% put your DBs on an FC SAN if you're anticipating high-load, we run JBoss on Oracle's rebadged RHEL 5U3 inside VMWare ESX 3.5U4, works very well, you could use VMWare's HA for failover if you wished?

My 2c

share|improve this answer

Xen virtualization is extremely stable and well configured can give you really good performance (not a trivial task, to be sure!). Almost the only applications that suffer significantly are high bandwidth ones, like fileservers or DBMS. So, it's wise to put the DB on a real server if you expect heavy load. Everything else would be limited by your internet bandwidth, so virtualizing them isn't a problem.

About the SAN: it's usually enough to use iSCSI for Xen storage if you have good switches (learn that the hard way! 3Com isn't so good, better go HP or Dell). If the DB won't grow into the TeraByte range, I'd use internal storage (10K or 15Krpm SAS disks on RAID1 if you want) and not a SAN. If the DB would grow beyond that, better invest in a good FC SAN (there i can't help you)

share|improve this answer

If your load balancers are exposed to untrusted networks I would consider firewalling the application servers and database servers in different zones. Your server roles are already nicely layered. Also, I would try to avoid direct access to my database servers for the FTP farm.

Putting the DBMS on physical hardware is always the safer bet. Don't virtualize unless your back is to the wall and your boss is bigger than you.

Get FC if you have money. A single iSCSI adapter is 4 times slower than a single FC HBA. You can get to the theoretical bandwidth of FC by adding gigabit ethernet adapters, but you won't get the low latency.

Have you considered putting your VM's (Virtual Machines) on SAN? For virtual machines the low latency of FC counts a lot since VM's generate many small I/O's. For a cheaper NAS option for VM's I prefer NFS over iSCSI. Configuration is easier while backing up a VM is just a folder copy.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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