Protect physical HTTPD and JBoss EAP instances from failure
Physical instances (HTTPD and JBoss EAP become unavailable) With the given architecture above and the already separation of responsibilities via at least virtual instances, our first step is to remove the physical failure and having our various tiers replicated across at least separate physical instances (or separate virtual instances that resolve to separate physical instances). In essence, we have duplicated the cost of our environment. Lets start with first replicating our HTTPD instance and JBoss EAP instance. We create another HTTPD instance and place it on another physical server (or virtual server on separate physical server). Once this is in place, we will need a load balancer in front of our HTTPD servers to load balance across the HTTPD tier. Similar to the second HTTPD instance, we create another JBoss EAP instance and place it on another physical server (or virtual server on separate physical server). The HTTPD tier will load balance across our EAP tier. Our infrastructure now looks like the following: Drawing 2: Updated Architecture with additional instances of HTTPD and JBoss EAP added With our updated infrastructure, we will of course want to add a second load balancer to avoid that singular point of failure. While this infrastructure can be expensive, load balancers can be shared across multiple applications. Additionally, JBoss EAP is a light footprint allowing multiple applications to potentially share instances, resulting in more controllable costs. We have addressed physical failures by adding instances and clustering our environment. Lets continue on and look at how we can handle disaster at the application level with JBoss EAP.