The ESE database engine can maintain a file up to 16 terabytes, this is double the size of a database from Exchange 2003 (barring non-Enterprise SKU limitations). This fact is based not off some radical restructure of the database format, ESE databases are still limited to 2^31 pages in the database. The increase in size is because Exchange 2007 store has moved to used ESE's larger page size option (8k, from 4k in Exch 2k3). Note the Exchange Information Store process artificially limits the database file to 16000 GBs (and 8000 GBs in 2003), to allow room to get administrators out of a bad situation.
The next obvious question is: Will that change the basic IO size? Will SAN/storage designs w/ 4k size assumed for average IO need to be redesigned? Yes, we will on average[1] be using 8+ KB IOs against the DB volume. While that fact may change SAN/storage designs the following are other even more significant affects to the storage design for Exchange 2007:
- Approximately 70% reduction in IOs (only part of which was caused by increased page size)
- The 64-bitness / ability to work around slow disks with 100s of GBs of RAM
- The suggestion to do 50 storage groups (effectively extending the checkpoint depth)
- And finally (especially don't underestimate this last thing, being from AD replication I can say this), the ability to use log shipping to avoid having to build super-availability into your storage stack
All these will much more radically affect the storage designs for Ex2k7. The page size should be thought of as an after thought ("oh yeah and don't forget to optimize the volume for 8k IO" ;-) when considering storage designs.
Asking the more general question: Exchange 2007, won't that change SAN/storage designs? Yes, absolutely. The Exchange team worked hard to do this, in a favorable way for customers and I suspect they succeeded (perhaps a few more tweaks will be required to keep costs low or even drive lower as we move to RTM?). It may take a while for people to catch on as old instincts will kick in, Exchange = Big Storage.
To change favorably (i.e. lowering significantly the costs) of storage requires delivering enhancements on variety of fronts simultaneously (write IOPS, read IOPS, IOPS on cold start, cold start to store responsiveness after failover, backup time, restore time, and any other customer SLA requirement) because storage costs can and will be raised by any particular customer requirement of Exchange that can only be met via upgrading to big storage. Only deployments can truly tell us if we delivered on this goal, I encourage anyone to let us know if something is holding them back from using less costly storage.
[1] To be a little more technically accurate the average IO will be bigger than 8k, the median will likely be 8k ... the reason is the ESE DB engine can combine page IOs when next each other, so we will use 8k or some multiple of 8k for read and write to disk on the DB files. On Today’s Ex2k3 servers the median (i.e. at least 50% of the IOs) IO size is definitely 4k on any decent sized Exchange server I've seen, this based on a page size,
The above applies only for the DB volumes, on the log we never necessarily used 4k/8k, for write we can go as low as the atomic write size (the HD sector size) of the volume (always 512 bytes on today's hardware and pre-Vista, changes to 1k | 4k on soon to be released HDs if you're running Vista+/LH Server) , and if we read (generally only during recovery) we usually threw out big (MUCH larger than 4k) reads.
