Follow us on Twitter
Follow us on YouTube
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
At the recent IT Forum conference in Barcelona, we started talking publicly about E12. It was great to talk with so many customers about the work we’re doing and get your feedback. One of the topics we discussed at the conference was the system requirements for which we are designing E12. I wanted to discuss one of these design points within this blog: requiring the 64-bit platform.
80% of the capital costs of an Exchange deployment are typically associated with storage. One of our primary E12 goals was to reduce these costs. Underlying today’s high cost is disk drive technology; specifically, that disk capacity is outpacing random IO performance significantly. According to Seagate, while disk capacity increased 15,000 times from 1987 to 2004, the random IO performance increased only 11 times during the same period. This presents a problem for any application that deals with large amounts of data; how to actually utilize this increased capacity while being constrained by such low IO rates. Customers either end up buying more storage capacity than they can effectively utilize (since the system is constrained by IOPS – IO per second), or buy faster, more expensive disks that match storage capacity with storage throughput.
In the E12 timeframe, 500 GB drives will be the norm and 1 TB drives will be available. E12 has been designed to leverage these large inexpensive drives, to lower your storage costs and enable you to provide larger mailbox quotas to end-users. Specifically, when comparing E2K3 to E12 on the same hardware, with the same user profile – but with a 64-bit OS vs. the 32-bit OS, our current tests show a >70% reduction in IOPS/user. In a future blog entry, we’ll discuss these improvements in detail.
In addition to these storage cost savings, there were 3 other benefits driving our focus on 64-bit:
More great reading on these issues can be found within the kernel memory section of our Troubleshooting Exchange 2003 Performance white paper.
Unfortunately, the optimizations we have made for the 64-bit platform cause the 32-bit platform to perform worse in many cases. Rather than fork the code base, and produce 2 different releases, one targeted to 32 and one targeted to 64, we thought it best to keep things simple and focus on one product. We will release a 32-bit version of E12 for feature evaluation, training, and demonstrations—but we are not planning to support this release in production.
Most servers shipping today are already x64-based, even entry level systems. You may have x64-based hardware in your environment already and not even know it. Because of the backwards compatibility of the x64 processors, 64-bit hardware can run 32-bit and 64-bit operating systems. If you are buying new systems today, to be ready for E12, look for systems with either of these 2 processors:
So how will migration work? The first thing to understand is that we are totally committed to full interop with E2K and E2K3 topologies. In fact, here at Microsoft we have 3000 people running on E12, with the remainder on E2K3 or even a few on E2K (for our sustained engineering team). The second thing which should make us all feel good is that all configuration data is mastered in AD – so we can introduce new servers into the topologies at any time, and the configuration data is always available to them. With that background, the migration process should be straightforward – introduce new mailbox servers running E12, and then “move mailbox” (which is now completely scriptable) the users across. The two places where things might get tricky are:
Lastly, we didn’t make this decision lightly. We understand that this will impact some of your planning- which is why we’re discussing it so early. We faced a trade-off of delivering an Exchange that tried to eke out a few $’s of savings on yesterday’s architecture, or a product truly optimized for today’s modern hardware that will deliver incredible cost savings to our customers.
- Terry Myerson