At the recent IT Forum conference in
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:
- Scalability
Exchange scalability is limited today by address space within the 32-bit Windows kernel. This fixed space has run out of elbow room, and gets tighter every day:- With the same # of users, an Exchange server today requires much more kernel space than a few years ago. On mailbox servers, connections per user have been growing over time: cached mode requires up to twice as many connections than online mode, mobile access keeps people connected more often, and folder sharing becomes more commonplace every day. Likewise, on the edge servers, spam can easily overwhelm an SMTP gateway with connections. For each and every one of these connections, precious kernel memory is reserved.
- The OS itself continues to reserve more kernel memory for itself over time. With Windows 2003 SP1, with IPSec enabled and StorPort drivers being used, Exchange has 10% less space in the kernel to work with than it did with Windows 2003 RTM.
More great reading on these issues can be found within the kernel memory section of our Troubleshooting Exchange 2003 Performance white paper.
- Features
Not having to worry about kernel memory starvation or IOPS exhaustion has freed us to deliver some great features. One of my favorite is aggregating individual Outlook-user safe lists out to the edge server, ensuring that any mail on an end-user safe list will get past server-side spam filters and make it to the user’s inbox. As you can imagine, even after all of the optimizations our engineers have dreamed up, this aggregation of all safe-lists in an organization can consume a large amount of memory – but we believe it is well worth it to make email becomes more reliable and secure.
- Co-existence with Outlook
Outlook will co-exist great with E12 on the same server. This is because 32-bit Outlook runs in WOW. Many of you have been asking for this since the 2000 releases where this became unsupported.
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:
- the 64-bit Xeon processor or Pentiums with EM64T (NOT the Itanium or IA64).
- any of the AMD64 processors (Opteron, Athlon and Turion).
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:
- 3rd party products. We are working closely with partners through our TAP program to ensure that they will be ready.
- Custom applications you have developed. The great news here is that all out-of-proc applications, e.g. those that use DAV, or those that use script interfaces, e.g. either WSH or ASP, will work unmodified. It is those applications which run in-proc to Exchange, that will need to be-recompiled 64-bit. Visual Studio 2005 provides great support for this re-compilation.
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.
Microsoft