Globalscape: Disaster Recovery
Written by Eric Hall at GlobalScape.
On additional item I wanted to cover is maximising uptime of Globalscape solutions, especially EFT and Mail Express, when dealing with a disaster in the Production data centre. This is an important topic that either doesn’t get enough attention or is discussed in terms limited to either Disaster Recovery or uptime within a single data centre, one or the other only. Forgive me for going long, but I want to make sure the topic of Disaster Recovery is addressed as thoroughly as possible in a forum like this, and I hope you will find this useful to keep for later reference.
With the current generation of Globalscape solutions, we strongly recommend either an Active-Active configuration made possible by the EFT Sync Tools or an automated Active-Passive (failover) cluster. Both options minimise downtime in the Production data centre during any interruptions in service due to failure or maintenance of the hardware, software, or OS. The Active-Passive configuration is supported out of the box, and it’s easy for EFT to be installed into this kind of failover cluster once it’s been set up. The installer will actually prompt you to specify whether it’s being installed in a cluster and will generally walk you through the extra steps required.
Some organisations have a high tolerance for downtime and are very unusual in that they have a seamless, high-bandwidth, low-latency integration of a secondary data centre with their primary data centre (often separated by only short distances over dark fibre, for instance). Those organisations may choose to get away with using their “disaster recovery” environment as the fail-over instance in lieu of a proper cluster. In reality, it’s rare that customers actually have the infrastructure to make this a reality. Even more rarely does this work in a manner that’s nearly as neat and tidy as they might expect, but it is theoretically possible.
For actual disaster recovery, where the primary data centre has been rendered unusable due to some natural disaster or otherwise a massive power or connectivity outage, there are two primary approaches.
1) Warm (some would call it “Hot”) – As a reminder, Globalscape now offers its EFT Sync Tools to regularly synchronise configurations between EFT installations, which is ideal for those who need a more seamless and “Warm” DR implementation. If there is a constant connection between the Production and DR data centres, then you can use the EFT Sync Tools to keep the DR installation up to date with the Production configuration. Some would call this a “Hot” backup, but that requires all of the surrounding services to also be up and running, and you typically do not want an EFT Enterprise continually attempting to accomplish Scheduled or Folder Monitor tasks against resources that may not be active and up to date. The EFT Sync Tools allow you to specify on which EFT installation various rules run, so that you can be sure any rules you don’t want running on the DR server are left alone until the appropriate time.
Using this approach intended for a Disaster Recovery scenario is what may allow them to potentially use it as a failover for simple maintenance or failures occurrences, but it is still not the kind of seamless and automatic failover achieved with MSCS on Server 2008 R2 and 2012 nor an Active-Active approach made possible by the EFT Sync Tools.
This option is often the best option, offering a high degree of confidence and value. And since the EFT Sync Tools are an optional component, they also help increase the size of the deal. Please follow up with your Globalscape contact for more information. You and your clients will love it!
2) Cold – Without the EFT Sync Tools, the next best option is a “cold” DR implementation, which is workable but more complicated. For this you would configure EFT Enterprise to periodically make a backup of the configuration not just locally but also to the remote server (ideally it will have connectivity to drop the file off through a shared folder on the DR EFT Enterprise server’s hard drive). This can be once a day or every 5 minutes, depending on how extreme the requirement and how often changes are realistically going to be applied to the production server’s configuration. This is one of the many reasons larger organisations should invest in EFT Enterprise, as the Standard version does not offer this kind of enterprise-minded capability.
When such a disaster occurs, the otherwise idle or sleeping EFT Enterprise in the DR data centre would need to be restored to the latest known-good configuration from the production environment. Keep in mind that for all the operations that require other resources (ARM, authentication sources, DMZ Gateways, shared folders to monitor, etc.) the DR environment must be well configured to appear functionally the same, which is a great time to push for name resolution rather than manually typing in hardcoded IP addresses. Additionally, remember that EFT will not replicate user data, database content, or anything other than configuration and operational data.
There are two ways to “restore” the latest production configuration onto the DR server. First, a human administrator can start the service, log into the administrative interface, and select File > Restore Server Configuration to start the wizard. It’s fairly simple, but of course it’s important to get it right; they should definitely go through the process once or twice in a little QA/dev lab first so they can document what to choose as the wizard walks them through it. EFT Enterprise documentation has more detailed information on all the options. Once it’s completed, it will be up and running with the production server’s configuration, and they can start directing incoming connections to that server.
Second, they can automate the process by creating a script or application to programmatically restore the configuration in a predetermined way. We’ve actually done some of that work by throwing together a hypothetical example script (Backup and BackupEx) we provide for free from our Help File (note the zip file download link). They would need to edit that script to be applicable to their particular environment (or you do that for them, of course), but we’ve gotten the ball rolling to help that process along.