The average worker checks email once every 15 minutes, recent studies have shown, with some users checking email as often as 40 times per hour. In addition, increasing use of personal mobile devices means that employees have become attached to their email at all times, with some checking their device as soon as each email arrives.
Now that email has evolved into a critical business communications tool, employees have come to expect access to their email 24×7, with very little tolerance for downtime.
Availability of Exchange and protecting the integrity of Exchange data are critical. 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 DNS server fails, the Exchange server may not be accessible.
To help your company protect its Exchange environment, here are some tips for identifying what availability levels should be designated in order to achieve Exchange service-level agreement (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 two sets of baselines for your Exchange environment: Recovery Time Objective (RTO) baselines, referring to the time it takes for an application to be running again; and Recovery Point Objective (RPO) baselines, referring to the time points at 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 or for certain 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 email 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.
Understand the Levels of Availability
There are multiple levels of availability to consider for different applications and their support infrastructures, starting with basic failover and recovery, moving up to high availability, and going all the way to continuous availability for extremely transaction-sensitive applications.
Level 1 Recovery is for those applications for which an 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.
The High Availability level is the home of the majority of applications that run the business, such as email, 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.
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 that the way you use Exchange today may not change in the future. You may use Exchange today for general correspondence, but within the next year, you may plan to use email 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.
Assign Levels of Availability
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 email 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 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 nonstop access to email 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 DHCP server, DNS server and Active Directory server, up and running. If one or more of these components goes down, requiring the IT administrator to manually intervene 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 — equivalent to that 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 email access. The BES and CAS implementations should be protected to the level you require based on your remote email 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, a provider of automated, fault-tolerant, high availability solutions for virtual and physical environments.
Loading ...
