You are here: Service / High End: Load Balanced Application Cluster
Our high-end example is often used in cases where even the smallest amount of downtime is costly to the business such as an e-commerce website or a web based CRM platform. Not only does this example have the same datacentre, network and hardware failover and high availability of the other examples but it also has multiple points of resiliency within the internal infrastructure.
Although the most expensive example, it is also the most common that we deploy due to the number of different points of protection that it offers. Our load balanced application cluster example also provides a number of additional enterprise features such as load-balancers, multi-layer security and internal VLAN support so as an all-round example there is a lot more included in the price too.
Our example utilises 2 hyper-visors, 1 in our UK datacentre and 1 in our New York City datacentre. These hyper-visors are backed already by twin power feeds from different phases and twin network feeds that take entirely different routes within our network.
Within the hyper-visor configuration we then have multiple layers of virtualised infrastructure starting with 2 firewalls configured in high-availability mode to provide a resilient entry and exit point from the cluster.
To follow on from the firewalls we then have 2 load balancers again configured in high-availability mode to ensure that even in the event of a failure of an individual load balancer the cluster will continue to operate. These load balancers are able to handle a range of different types of traffic however the most common is HTTP and HTTPS traffic.
Sitting behind the load balancers we then have 3 application servers in our example which all contain the same static content for serving our application. These application servers are automatically kept in sync with each other to make sure that the same content is served whichever application server the user is served by. The load balancers check every few seconds that the application servers are returning the correct information and will remove them from the cluster if the expected result is not returned to offer resiliency within the application server layer.
Lastly we have a pair of MySQL databases in an active/passive configuration which the application servers talk to in order to serve the dynamic content for the website. As with all of the other layers in this example one of the database servers can fail and the other will take over as the master. Although MySQL is used in this example we have also used similar configurations for MS SQL and Oracle database servers.