By Mike Talon
Once considered a peripheral function of the enterprise environment, messaging systems are quickly becoming a vital part of most modern organizations. Due to the increasing reliance on messaging systems, the systems themselves have become integral components of a disaster recovery plan.
In addition, many other programs are now relying on messaging systems in order to properly function. Common examples include voice mail systems, customer relationship management systems, and fax systems.
No matter which messaging platform your enterprise currently uses, or what other applications rely on it, messaging has become an essential part of the enterprise. That means it's also an application that you can't afford not to focus on when developing your organization's DR plan.
Messaging systems come in many versions and flavors. The most popular are currently Microsoft Exchange and Lotus Notes. Both of these systems run on the Windows platform, but there are many messaging systems that run on UNIX and Linux systems as well.
Regardless of what platform you choose to run your messaging system on, its failure could cause the failure of other applications that rely on it. Therefore, it becomes even more necessary to ensure that the messaging system does not fail. How do you secure messaging systems that require dedicated connections to the Internet and generally have end users connected at all times?
Of course, standard DR methodologies apply to messaging systems. Redundancy of hardware will allow you to survive single server failure, and redundancy of data via replication or another methodology of moving data from one place to another can help you survive hardware-related tragedies.
But many of these methodologies don't account for the fact that end users remain constantly connected to the systems. In this somewhat unique situation, end-user client software expects to find a steady state connection, which presents a rather difficult problem. How do you successfully fail over these operations from one hardware platform to another—or worse yet, from one data center to another?
Technologies exist to assist you in this plight. Whether you're using software based on Windows, UNIX, or Linux, some form of clustering should be available to you. Clustering solutions can allow you to fail over between physical hardware devices without losing end-user connectivity for more than a few seconds. Although you do lose the connection state for a brief period of time, most applications designed to work with these clustered messaging systems are more than capable of dealing with this particular kind of outage.
While clustering gives you the opportunity to endure a singular hardware failure at a singular data center, it usually doesn't take care of the situation when an entire data center goes offline. In these instances, it's necessary to use a WAN-based DR solution, which may or may not offer high availability.
This is not to say that there are no vendors that provide HA solutions across all WANs. But make sure you ask your DR vendors about the full capabilities of their products.
Procuring funding for DR and HA specifically for messaging systems may initially be an uphill battle. Many nontechnically trained personnel may not recognize the vital nature of the messaging system. They may simply see it as e-mail, in which case you might have to drill home the fact that many other applications within the enterprise rely on the messaging system. Once that distinction becomes clear in their mind, you'll probably find that procuring necessary budget funds becomes a great deal easier.
Mike Talon is an IT consultant and freelance journalist who has worked for both traditional businesses and dot-com startups.