OK, so I've started you thinking about your Exchange 2000 Server deployment plans. Last week, I concluded my series about the steps to deployment, but I want to spend time on Exchange 2000 storage this week. As most of you are aware, Exchange 2000's storage model is significantly different than previous versions. This is a key point for deployment and the number one topic of the questions that I receive in response to this column.
The keyword for the Exchange 2000 Information Store (IS) is partitioning. Exchange's Extensible Storage Engine (ESE) still runs as part of the Store process (store.exe) in Exchange 2000, but unlike earlier versions, multiple ESE instances enable the concept of the storage group (SG). Technically, Exchange 2000 will support up to 15 configured SGs per server, each with as many as six databases (in Exchange 2000, a database is actually two files—*.edb and *.stm). At a lower level, ESE supports 16 instances for recovery purposes but that's another discussion. The important point is that at its initial release, Exchange 2000 will support only four SGs per server because of testing constraints and memory limitations. In addition, Exchange 2000 will allow only five databases per SG because utilities such as ISINTEG need the sixth database.
The fact that one server can have up to 20 (4 SGs x 5) databases configured has extreme implications for storage design on your Exchange 2000 servers. Take a simple server with two SGs each with two databases. Depending on how much fault tolerance, recovery capability, and performance you want in your server design, things can get quite complicated. How will you apply the golden rule, "Separate random from sequential I/O"? In the above example, if you provide a separate array for each SG's transaction logs, you start with two arrays. If you want to configure a separate array for each database, you have a total of six arrays. You can start to see how the capabilities of traditional host-based storage will fall short, and you begin to favor technologies such as Storage Area Networks (SANs).
Other deployment options such as clustering complicate this configuration further. For example, in a cluster, your design must ensure that no single node runs more than four SGs in either a pre- or post-failover mode. Disaster recovery is also a design consideration. If you want to back up user data, what is the best design method—more storage groups or more databases? The recommended backup set is an entire SG, but the restore granularity can go down to database level (as can the backup). All of these concerns require some thought as you design your Exchange 2000 servers.
Obviously, we don't have all the answers for storage design because Exchange 2000 is not yet widely deployed. My advice is to focus on service levels. If you start with design points such as user mailbox size, recovery time, and performance criteria, you can work backward to determine the answers to questions such as database size, number of SGs, and the number of users per server. Partitioned storage in Exchange 2000 is a welcome feature, but it will force you to have a better plan for storage design. Begin by thinking about how you would redesign your existing Exchange server if you had the luxury of multiple SGs and databases.
End of Article
Register
