Data Design Can Help You Meet your SLAs

Data design seems to be one of those nagging concerns in Exchange 2000. By data design, I mean logical data partitioning rather than spindles and arrays (physical), which I touched on in my last column of 2000 (Exchange & Outlook UPDATE, December 29, 2000). The options available for designing storage in Exchange 2000 can be a bit overwhelming. With Exchange 5.5, everything was easy (depending on your point of view). You had just one database engine and two databases. Now, with Exchange 2000, we have four database engines (storage groups—SGs) and up 20 databases per server. Eventually, we might have as many as 90 databases per server spread across 15 SGs. So how do we decide how to partition our SGs and databases and lay out user data?

The keyword is service level agreements (SLAs). One big advantage Exchange 2000 brings is the ability to build our servers as our SLAs direct. Which SLAs am I talking about? First are performance SLAs, which include items such as guaranteed response times or message delivery times and rates. The easiest way to ensure that we can meet these SLAs is to have the design flexibility that lets us meet them. In the old days of Exchange 5.5 and previous versions, the management granularity of design was at the server level. With Exchange 2000, I can manage to the SG or even database level. Therefore, if I want to ensure that we achieve a performance SLA, I can take steps to ensure optimal performance for the customers of that SLA. For example, suppose you have a set of customers to whom you're providing Exchange services, and you want to guarantee them a performance level. For optimal performance, you determine that their data must be separate and have disk I/O characteristics (RAID, spindles, and cache—the most important parts of Exchange performance) that are available only by dedicating a disk array to their data (whether a database or an entire SG). With earlier versions of Exchange, you needed a dedicated server. For Exchange 2000, you simply have to allocate a separate array for the SG or databases. Performance SLAs are more easily achieved and less costly with Exchange 2000.

Recovery and availability SLAs are a similar case. When you agree to a particular SLA for recovery and availability, you need the design flexibility that ensures you can achieve it. With Exchange 2000, you can partition user data based on SLAs for recovery and availability as well as for performance. Suppose I have 1000 users, each with 100MB mailboxes, and I have agreed to provide a 1-hour recovery SLA. This agreement means that I have to be able to recover a mailbox or information store (IS) within an hour. If I get 10GB/hour backup and 5GB/hour restore (only an example), my ISs need to be limited to less than 5GB each. Again, with Exchange 5.5 and earlier versions I would be limited to about 50 users per server (50*100MB=5GB) or fewer. For our 1000-user deployment, I would have to deploy 20 servers or more. With Exchange 2000, I still must limit each IS to 5GB but I can have 20 ISs per server (which means deploying one server instead of 20). I can manage each 5GB IS for whatever SLAs apply to it, including the 1-hour restore SLA.

Exchange 2000's data partitioning capabilities are extremely powerful but also complex (especially when you add factors such as clustering). We can now manage Exchange data in a very granular fashion and offer focused SLAs in the areas of performance, recovery, availability, security, and manageability. You can see where all this is leading—think server consolidation. We've wanted server consolidation since the days of Exchange 4.0; with Exchange 2000, it might be within reach.