The cloud is a big thing nowadays but there are still times when you need to build your own infrastructure to host a large Java application, it needs to be bomb proof but still not cost the earth and grow smoothly at need, such a situation has recently arisen for a client, and while i was putting it together i was luckily enough to chat with application architect for VMware, taking into consideration the tips he added, I put forward the following design, i hope its of use to someone else:
Icons Key for diagrams
This represents a dedicated Apache box used for load balancing, and it forwards requests to the main app servers. This server requires very very little by way of disk storage.
This represents a dedicated JBoss application server. It also has a read-only version of the main MySQL database so all SELECT statements can be run locally.
This represents a logical SQL server, the master database for the application. Its platform will vary as the application grows from a stand-alone database to a multi-master cluster. It is the only database in the system that is written to by the application.
Dashed links indicate when a change is committed to user data. Updates aren’t written to the local database on each application server, but written back to the master database.
Dotted links indicate when updates to the “slave” databases from the “master”. The master database is responsible for ensuring that the slaves are kept up-to-date.
Blue links indicate servers that are sharing user session states, which means users will not lose anything should we have an application server outage.
Red links are the “heart beat” links that the load balancers are monitoring. If the current load balancing server stops responding (per its heart beat) then the backup will pick up its duties (as well as taking over the live IP address).
Phase 1 (Development / test)
This is the most basic configuration, with two application servers sharing user session states (one load balancing).The development and test environments will be set up like this.
Phase 2 (Minimal live)
A basic live environment; this removes the single point of failure on load balancing. You will have to decide as to the format of the logical SQL Master (i.e. whether “Enterprise” or “Cluster”). At this stage you will need to do full load tests (to failure) and decide if it will meets your needs if a phase 3 set-up is required for go-live.
Phase 3 (Mid-range live)
This phase includes the addition of two more App servers. These do not share session states with the initial pair in order to limit the chance of a cascade failure. At this point the option of a delayed read slave for the master database server should be raised as this provides an excellent option to rectify large data corruptions without the need to resort to a full restore.
Phase 4 (Enterprise level)
Classed as a “fully populated” stage. Beyond this architecture, a dedicated load balancing system (hardware) would be required, distributing the application over multiple data centres, or move to a cloud-based infrastructure.
This phase comprises two groups of four servers sharing their user sessions, with two fail-over servers to mitigate cascade failure. The master database is also clustered, and a delayed-read slave become necessary.
give me a yell if you want LDC to build this for you (or even more fun a app that would need it 🙂 )