DR Made Simple
Wed 03 Dec 2014 | View all blogs
How to sleep easy at night
Disaster Recovery (DR) is an important aspect most commonly overlooked or simply ignored by IT managers.
The reasons are numerous. Many adopt a “It’ll be alright on the night” strategy, relying on statistics that show its unlikely a service provider will have a major outage, or perhaps concluding that whatever the problem, it will be down to the service provider to resolve. Some have the expectation that including DR means adding great complexity and cost and these factors outweigh the consequences of a once-in-a-blue-moon issue.
What if DR could be included in a solution easily and without breaking the bank? In this article we show you how to achieve just that.
For this example we’ll take a very typical setup; a customer running a web based application or site that relies on a database backend. This approach works equally well with Microsoft technologies (Windows Server, IIS, SQL Server) as well as LAMP stacks (Linux, Apache, MySQL and PHP)
Single Site solution: Firewall, Web Server and Database Server.
Dual Site solution: Dual Firewalls, Dual Load Balancers, Dual Web Servers (active/active) and dual Database Servers (active/passive)
In order to consider how a failover is made, we need to examine the various components of the service.
Networking and DNS
The second site needs to have a mirrored firewall and load balancer which can take over processing in the event of a failure at the primary site. The key to a smooth automatic failover is removing the need to change IP addresses or DNS. This is taken care of via our VMware vCloud technology. We “float” IP addresses between sites, such that in the event of a disaster, network traffic will be automatically re-routed to the second site and into the alternative firewalls and load balancers.
Additional cost? Zero.
Front end Web Servers
Quite simply we move from a single web server setup to a load balanced configuration using a pair of web servers. Each web server is in a different geographical location, so in the event of a disaster, at least one of them will be present to serve requests. The web servers can be configured as active/active or active/passive.
Additional cost? A second web server. This can be a smaller spec cloud server and requires no additional services like backup, so costs are very low indeed. Optionally the second web server could be left powered off and only started in the event of a failover scenario.
Back end Database Servers
Instead of a single database server we move to an active/passive pair of servers. Data is kept synchronised between the primary and secondary via mirroring, availability groups or similar replication functionality. In the event of a disaster, the secondary server is automatically promoted to being active and continues to serve queries.
Additional cost? A second database server. Again, this can be a reduced specification and will require no additional services like backup. There is no need for a second software license for the database server as active/passive solutions are covered by a single license (true of Microsoft SQL Server, other products may vary).
Conclusion
On our platform the only additional costs are that of the additional web and database servers. These are often reduced in specification to reduce their impact further. Our CronoSphere platform allows the hot-plug of additional CPU and RAM so secondary servers can be immediately beefed up in the event of a disaster to deal with loads.
Our customers typically express great surprise that adding a second firewall and load balancer incurs no cost, similarly the ability to “float” IP addresses is included in our services as standard.
The other requirement is a low latency high speed network between sites that allows for real-time replication of data without delay. Using modern VXLAN and 10Gb cloud optimised networking solutions allows us to provide exactly that.
Dual site active/active solutions require little in the way of DR testing either. It is very common for companies to try and instigate their DR solution only to find it hasn’t been maintained or tested and does not work when needed most. With this setup maintenance and testing is simple and ensures the service will be there when needed.
In conclusion, comprehensive DR can be included simply and affordably on our platform. Enjoy a good nights’ sleep :)