Configure Disaster recovery in a multi-site environment
Geographically Separate Data-Centers In events where your application is mission critical and deployed across more than one datacenter (to avoid a scenario where one datacenter is made unavailable) you will want to make the following additional considerations: Global Site Load Balancer – A global site load balancer is simply a load balancer that can balance requests across data centers. It has the benefit of built-in intelligence to determine datacenter proximity to requests thereby ensuring that a request gets the closest response. DNS – When applications span multiple data-centers, you will want to make sure that the IP’s for the datacenter loadbalancers are registered in DNS as A records. When a user makes a request for your domain, DNS responds back in a round-robin fashion to the sites defined as A records in DNS (and most browsers are smart enough that once a location is identified from DNS, the request isn’t made again until a certain amount of time – thereby avoiding datacenter hopping). Gossip Routers - JGroups has a built-in technology called Gossip Routers. With this technology we can setup a cluster that spans datacenters. While this is a fully supported approach, it is a configuration that requires quite a bit of consideration as it can create a large amount of network traffic as well as make your inter data-center network channel a single point of failure. Database Synchronization – Oracle has had a concept called ‘Streams’ for quite a while now and MySQL has recently introduced this feature as well. With this service in place, you can have databases at different locations / datacenters and upon action into schemas / tables in one, fire off updates to the other instances, with streams handling concurrency aspects (id incrementers, cascading deletes, constraints, etc). It is a monitorable service as well. With this in place, you can rest assured that if one datacenter were to become unavailable, your database would not have stale data.