• open panel
  • Home
  • Posts Tagged'failover'

Posts Tagged ‘failover’

Globalscape Mail Express and EFT Disaster Recovery Practices

By Eric Hall – Globalscape Channel Engineer Executive

How to maximise 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. I want to make sure the topic of Disaster Recovery is addressed as thoroughly as possible, and 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 you to potentially use it as a failover for simple maintenance or failure 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, offering a high degree of confidence and value.

 
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 good reason for the use of 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. Once it’s completed, it will be up and running with the production server’s configuration, and you can start directing incoming connections to that server.

Second, you 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. You would need to edit that script for it to be applicable to your particular environment, but we’ve gotten the ball rolling to help that process along.

Again, I advise against trying to use a DR site as a substitute for a proper highly available implementation (Active-Active via EFT Sync Tools or Active-Passive via MSCS), but it is do-able to create a very well groomed and orderly configuration and environment replication, as long as you can tolerate the additional downtime required to kick off and complete the process.

Please do not hesitate to contact Pro2col should you wish to discuss the design or implementation of DR in your environment.

Share on TwitterShare on FacebookShare on LinkedIn+1
 
© Pro2col Ltd 2012 | Terms of Sale | Privacy Policy | Sitemap
Part of the Pro2col Group