eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The average employee today checks e-mail once every 15 minutes, with some users checking e-mail as often as 40 times per hour. In addition, the growing use of personal mobile devices means that employees have become literally attached to their e-mail at all times, with some checking their device as soon as each e-mail message arrives. Now that e-mail has evolved into a critical business communications tool, employees have come to expect access to their e-mail 24/7, with very little tolerance for downtime.
Meeting the “always on” expectations of employees creates challenges for the IT administrator. Service-level agreements (SLAs) are increasingly stringent and demanding as users require non-stop access to e-mail and other collaborative features of Microsoft Exchange. Availability of Exchange is paramount, as well as protecting the integrity of your Exchange data. In order to maintain Exchange availability, every component of the Exchange infrastructure needs to be considered. You can protect your mailbox server to the highest degree but if your Domain Name System (DNS) server fails, the Exchange server may not be accessible.
To help your company protect its Exchange environment, there are a series of steps you can follow to achieve optimal Exchange availability. The tips are designed to help identify what availability levels should be designated in order to achieve Exchange SLA commitments with fewer resources and lower costs.
Define availability objectives
Creating availability objectives is an important first step in formulating Exchange protection strategies. This is typically done by establishing a Recovery Time Objective (RTO) and a Recovery Point Objective (RPO) for your Exchange environment. RTO is the time it takes for an application to be running again, while RPO is the point in time to which the IT professional can recover data in case of a failure.
RTO and RPO baselines establish the SLAs you commit to for the overall company, business units or specific internal groups. You may even have different Exchange SLAs for different users within your company. For example, you may have an executive group that requires 24/7 e-mail access while the rest of the company can withstand Exchange downtime of up to one hour. In addition, consideration should be given to what level of protection is needed for the other components of your Exchange infrastructure such as Active Directory and DNS servers.
Understanding the Availability Levels
Understanding the availability levels
There are multiple levels of availability to consider for different applications and their support infrastructures. The levels of availability start with basic failover and recovery, move up to high availability (HA), and go all the way to continuous availability for extremely transaction-sensitive applications. Let’s take a closer look at each level:
Level No. 1: The recovery level
The recovery level is for those applications for which a RTO of a day or more is often acceptable. Some downtime is acceptable and even significant downtime won’t have a detrimental effect on the business. Assurances that recovery will happen is not a requirement.
Level No. 2: The HA level
The HA level is the home of the majority of applications that run the business such as e-mail, CRM, financial systems and databases. These are systems with high downtime costs and therefore short RTO requirements. These applications require assurances that they will not be down for extended periods should failures occur.
Level No. 3: The continuous availability level
The highest level of availability is continuous availability, in which even brief moments of downtime or a single lost transaction can be extremely detrimental and/or costly to the client or business.
As you establish availability objectives for different groups of Exchange users, you need to consider the protection requirements for your entire Exchange infrastructure, beyond just the mailbox server. You will need to protect all of the components of the Exchange environment, in addition to the different workloads deployed on the mailbox server.
Also, don’t rule out the possibility that the way you use Exchange today may change in the future. You may use Exchange today for general correspondence but within the next year you may plan to use e-mail to process orders. This adds to the need to have multiple levels of availability to assign to the components of the Exchange infrastructure and Exchange user groups. Additionally, you’ll need flexibility to change those levels as your business changes.
Assigning Availability Levels to Exchange Environments
Assigning availability levels to Exchange environments
A meaningful exercise to undertake is to apply various levels of protection to your Exchange infrastructure based on your SLA commitments. First, look at the users and their requirements for Exchange access. Do you have a single SLA in place for all users or do you have multiple user groups with different SLAs? If you have a single SLA in place company-wide, you can deploy those users in workloads based on e-mail usage and assign them a single level of protection. However, if you have different SLAs for different business groups, you can divide those into multiple workgroups on the mailbox server based on their SLA requirements.
For example, if you have an executive group that needs a 24/7 uptime, then you should consolidate those executives in a dedicated Exchange workload and assign a level of protection that will provide continuous availability. Salespeople can often fall into this category as well, requiring non-stop access to e-mail and Exchange collaboration features. Other employees may have less stringent SLAs in place and would require a lower level of protection.
It is also important to keep the components of Exchange-including the Dynamic Host Configuration Protocol (DHCP) server, DNS server and Active Directory server-up and running. If one or more of these components goes down, it would require the IT administrator to manually intervene. This could cause excessive downtime for Exchange and exceed your SLAs. Automatic recovery from failures enables you to keep the Exchange environment operating to meet your SLA commitments.
Assigning a level of protection to the supporting systems (including the DNS, DHCP and Active Directory servers) that’s equivalent to those necessary to meet your Exchange SLAs is as important as protecting the actual Exchange servers. Any single point of failure could bring down a well-protected Exchange server.
For remote employees and road warriors, your company may also have a BlackBerry Enterprise Server (BES) and/or Client Access Server (CAS) implementation to serve as a secondary or backup method for remote e-mail access. The BES and CAS implementations should be protected to the level you require based on your remote e-mail access strategy and user SLAs.
Establishing RTO and RPO for SLA commitments, determining the right level of availability protection to meet these commitments, and protecting all components necessary to support an Exchange environment will help create a robust and reliable messaging system.
Tom Reed is Senior Solutions Architect at Marathon Technologies Corporation, where he is responsible for the deployment of mission-critical platforms to support enterprise-computing environments. He can be reached at treed@marathontechnologies.com.