Sales
Support Using InMage DR-Scout planned failover between two servers for application recovery and business continuity.
As we have discussed in our previous entry (LINK), InMage is a powerful tool able to provide continuous data protection (CDP), business continuity and application recovery including both data and the application itself.You can very simply restore to any point in time (PIT), so you can restore lost files from a point in time or (and this is clever) an application specific consistency point, which could be something things as abstract as "Pre end of month invoicing run".
InMage can also provide more advanced recovery options, such as planned or unplanned failover between servers, which is useful for business continuity and application or data migrations.
In this entry we will talk about planned failover of our web based application, which might be useful if you need to do physical maintenance on the application server, but need the application to continue running. It might also be useful for testing disaster recovery (DR) procedures. As this can all be scheduled through the InMage web gui, you might schedule a planned failover in the middle of the night to minimise disruption to staff.
We are using the same test environment as used in our previous post. We have a pair of Windows 2003 servers, with the "source" server running a simple MySQL, Apache and PHP based web application. The target server does not have anything other than the InMage VX agent installed.
To complete a failover what we need to do is create a replication pair between the source servers volume and the target servers volume. This data is replicated initially and then as changes are written to the source volume, the changes (and only the changes, not the entire file again) are replicated to the target server. This change could be recovered by restoring a point 5 seconds before the time that the change was made using a point in time as your recovery point. However, as we can create unique user defined consistency points we can put a "tag" to easily identify a point in time we'd like to recover to. So we could put a consistency point called "Prior to updating to v2.45" or "Prior to purging dead contacts" or for our example "Demo Failover point". This allows us to easily find the the point in time we want to work from via the webinterface and recover to that time without having to use time and date.
The next step is then to make the data (and in this case the application) available to the users of the network. We are going to do this with the "push-button" application failover features of Inmage DR-Scout These allow us to do both data recovery and application recovery in an automated way, minimising human error. The actual steps we are going to take are...
1) Create a replication pair. In our case \\source\t: to \\target\s:
2) Create a consistency point, we are calling ours "Demo_Failover_Point"
3) "Recover" to \\target\t: at the consistency point.
4) Start MySql and Apache on the target server (they were restored along with the data in our example).
5) Use InMage to alter the network DNS settings to point the DNS entry for TARGET to point to SOURCE.
6) Stop Apache/MySQL on source server (optional)
Now, doing this is possible because InMage allows us to create scriptable failovers, these are over and above the the included pre-configured supported applications that include SQL Server, the System Registry and MS Exchange for example. We are able to script actions to occur prior and post data replication on both the target and source servers. In our example we create the consistency point on the source prior to replication, the recovery post replication onto the target. Stopping the Apache server on the source server is done afterwards also.
Once this is all configured; these steps (along with the ones not mentioned) are not in fact necessary, or visible, from a user perspective.
At this stage it becomes a "push button failover", in that you go into the InMage DR-Scout web based user interface, click on the failover you want (you can configure multiple different failovers) and click START. It's that simple, at that point DR-Scout goes away and gets on with the job. All you need to do is watch the status, maybe read the detailed log , and then access the application at the end to satisfy yourself the job is done.
Now, our configuration is probably not one you would use in production. We are replicating T -> S, which complicates the configuration and adds a recovery step that would not necessarily be required to provide a DR failover. If we simply replicated from T -> T all we would need to do is set the target volume to a Read Writeable state and start Apache and MySql. This would provide a faster response.
We have our configured as it is for two reasons.
1) Our recovery does not stop the replication pair. This is important to us as we demonstrate this failover and would prefer not to have to restart the replication from source to target every time. With our configuration, we can with a minimum of fuss failover and failover and failover again.
2) We can recover/failover to any consistency point with ease, again without breaking the replication pairing. So we are able to failover to the consistency point created specifically in this example, but we also have failovers configured to failover to consistency points in the past, so a point at midnight perhaps, or one just prior to running month end processing.
Once configured, InMage's application failover tools we think have great potential for use above and beyond disaster recovery.
The features could be used to allow you to maintain a test and development environment, "failing over" to a known good point, or standard build consistency tag. Support could "failover" to previous versions of applications for trouble-shooting with a client, then "Failover" to another version for another client with a couple of simple clicks of the mouse. Sales teams could "failover" to a clean demonstration state prior to doing client demonstrations.
Customised failovers do take some configuration time and testing, especially compared to the ease of using the failovers built in as standard such as MSSQL and Exchange failovers, where it all works "out of the box". Customising the failovers for your specific applications will take a little time to get right, but once in place doing even complicated failovers is, as the marketing puts it, a "push button" operation.
Further reading:
DR-Scout Page
Using InMage DR Scout to protect Web applications
CDP or Replication for DR and Business Continuity?.
[ add comment ] ( 78 views ) | [ 0 trackbacks ] | permalink
Calendar
