Will Exchange 2000 Server free us once and for all from the bondage of limited scalability? In the early days of Exchange Server 4.0, we were limited to a 16GB Information Store (IS), which didn’t present a real disaster recovery problem. When Exchange Server 5.5 shipped with its 16TB IS capability, we began to experience scalability limited by disaster recovery considerations. Why am I hopeful about Exchange 2000? Let me go off on this tangent a bit.
We've all heard about the wonders of Exchange 2000 and its partitioned IS model. Exchange 4.0, 5.0, and 5.5 had one monolithic IS in which all users on a particular server stored their mailboxes. Many times in this column, I've harped about the problems this has created, so I won’t go down that path now. With Exchange 2000, we can think about data storage in a whole new way: We can focus on service levels. Whether you manage an enterprise Exchange deployment or provide hosted services based on Exchange Server, you have service level agreements (SLAs), either formal or informal, by which you are judged. These service levels cover many areas such as performance and availability. With versions of Exchange prior to Exchange 2000, SLAs were heavily biased toward disaster recovery and availability, and it's been difficult to get the scalability and performance service levels that we desire. With Exchange 2000, I believe we'll be able to finally achieve scalability service levels that we couldn’t touch with earlier versions.
The ability to partition storage into manageable service units is the key. For example, if I had 1000 users on an Exchange 5.5 server, these users shared one database. With Exchange 2000, I can spread those users over multiple databases. Database size will most likely be dictated by recoverability—how fast mechanisms in place can back up and restore the databases. This approach will free system managers to focus on performance service levels: They will now be able to look at client performance requirements and design their storage accordingly.
For example, Exchange 2000 will give me more design flexibility when choosing the location of databases. I might put databases with lower performance service requirements on the same physical array. For databases whose users require better performance or reliability, I can dedicate an array for each database. I can even separate my streaming store (*.stm file) when performance service levels dictate (e.g., when I have Internet protocol clients).
I'm hopeful about the possibilities for Exchange 2000 data storage and the capabilities that we will have to focus on many different service levels, but I also recommend proceeding with caution. This additional flexibility also means a higher degree of complexity that we will need to address in our management of Exchange 2000 deployments.
