6.3 Best practice 3: Establish disaster-recovery service-level agreements

6.3 Best practice #3: Establish disaster-recovery service-level agreements

I will discuss defining SLAs specific to Exchange deployments in more detail in Chapter 10. An SLA for a messaging system can exist in many forms. However, in the context of this section, the scope is limited to disaster recovery. This type of SLA typically defines how long a client can be without Exchange services or how long a recovery can take to accomplish. Disaster-recovery SLAs may be based on an individual mailbox, database, or even an entire storage group. SLAs for restoring data will vary depending on how critical the data is to your clients and overall business.

Before negotiating an SLA with your customers, you should test your operational procedures to verify whether or not they can meet the anticipated SLAs. If not, you will have to take steps to improve the performance of your procedures. This may be accomplished through improved data partitioning, faster server hardware, or distributing your data across more Exchange servers. Exchange 2000/2003 drastically improves the flexibility of storage design and allocation on an Exchange server, providing you with the ability to purposely and proactively design your information stores for optimal performance and reliability. This new storage paradigm affords many more options than in previous versions of Exchange Server, which provided only a monolithic, single information store approach. Because of the flexibility available, administrators can now architect storage designs based on performance requirements as well as disaster-recovery requirements or SLAs. Let’s look at a couple of examples to illustrate this point.

Table 6.1: Typical Disaster-Recovery SLA for Exchange Deployments

SLA Coverage	Description
Availability	Establishes when the system is available for use. Measured in percentage of time that the system is scheduled to be in operation.
Reliability	Covers how often the system is inaccessible due to unscheduled outages. Measured in percentage of time that the system is operational during scheduled operational times.
Scheduled outage	Establishes and defines specific hours for planned outages for maintenance or other purposes.
Restoration time	Establishes the maximum time that the restoration efforts must not exceed.
Data retention	Establishes the maximum time that user data is retained and can be restored via backup or other measures.
Message integrity	Guarantees that messages and attachments will arrive intact and not be corrupted as they travel throughout the organization. Could also be tied to security requirements.

First, consider a scenario in which a customer (whether internal corporate IS or a consumer using the services of an ISP) has certain performance SLAs for message delivery or other metrics requiring a database to be located on a higher-performance disk subsystem. With the advent of storage groups and multiple databases in Exchange 2000/2003, an administrator can configure a specific storage group or database on a dedicated storage array or storage area network that can provide a higher level of performance than others already configured on the server. This also lends itself very nicely to storage charge-back schemes in which clients/customers can pay for the level of performance they require. A single Exchange 2000/2003 server could host many different storage groups, each providing the capabilities to meet one or many specific SLAs that clients require. The possibilities are only limited in degree by the amount of hardware you are willing to build around your Exchange server. In Chapter 7, I will address the topic of leveraging storage technology for Exchange. When I discuss this in more detail.

In another scenario illustrating the best practice of designing storage based on SLAs, let’s say a specific customer unit using Exchange requires higher levels of availability, reliability, and recoverability. For example, suppose you are an Internet service provider that provides hosting services utilizing Exchange Server to a financial services company (just an example) that has fairly strict requirements for disaster recovery. The flexibility of storage allocation in Exchange 2000/2003 allows for either storage groups or databases to be configured based on disaster-recovery needs. For example, if the disaster-recovery facility only allowed for backup rates of 30 GB per hour and restore rates of 15 GB per hour and the customer demanded a 2-hour recovery SLA, you would have to find methods of partitioning or segmenting user data in such a manner that the SLA could be achieved. If the maximum restore rate available is 15 GB per hour, an administrator may choose to limit the maximum database size to 20 to 30GB (allowing it to be restored within the two-hour window). This could be done with hard limits to the size of the information store or by limiting the number of users per information store. Since Exchange 2000/2003 provides such a high degree of storage flexibility (multiple storage groups and multiple databases), the administrator has many options for providing individual levels of services depending on the client’s needs. This best practice will be key as activities like server consolidation and multiple-organization hosting take place in Exchange 2000/2003 deployments. Again, the keys to successfully implementing this best practice will be to understand how Exchange 2000/ 2003 storage works and to seek opportunities to leverage it to meet customer requirements. The opportunities for creative storage management in Exchange 2000/2003 are what Microsoft is counting on to provide high levels of scalability, while delivering increased availability.