I just did an Exchange 2010 architectural design session for a university in Ohio and this was a key question they asked me. The answer is yes, you truly can leverage JBOD (Just a Bunch Of Disks) storage with large TB SATA drives for Exchange 2010 now. Microsoft IT has deployed Exchange 2010 with JBOD storage and we are benchmarked as some of the heaviest mail profiles available. This proves using JBOD storage with Exchange 2010 can handle even the highest of mail loads/stress and IOPS per user (.11+).
Why would I consider JBOD storage for Exchange 2010?
Storage is going to be your largest expense in deploying Exchange 2010. If you can reduce your storage costs by anywhere from 90%+ to 40%, maintain the same performance, and significantly grow your mail quota per user it becomes a no brainer. This is the same conclusion MS IT came to. They also did not need to grow their storage staff to maintain JBOD.
How is this possible?
Cheap SATA and JBOD storage are possible since, with Exchange 2010, the product team managed to significantly increase and optimize database performance which resulted in reducing the IOPS per user by another 70% over Exchange 2007. This translates to the use of cheaper storage can be leveraged for equivalent performance of higher cost storage used with Exchange 2007.
For example, a 7200RPM 1TB SATA drive will provide an estimated 75-80 IOPS per spindle. This now becomes a viable spindle type for Exchange 2010 with the additional 70% IOPS/mailbox reduction. If you add in our new DAG availability, where we replicate and failover at the database layer, JBOD becomes a viable option as well.
What do I have to have in place in order to use JBOD storage?
The recommended DAG architecture for JBOD storage is a minimum of 3 mailbox server nodes with 3 database copies per database. You dedicate one spindle per database and associated transaction logs. If a spindle fails, since it is non-RAIDed, it doesn’t matter since you have TWO other good copies of the database to failover to on two other dedicated spindles.
What does a sample JBOD storage look like?
This is just a sample architecture for reference. You could use larger SATA drives now such as 2TB SATA drives to lower your spindle count. If you look closely you will see, 3 copies of any given database spread across 3 servers.
Are there tools I can use to validate my JBOD storage?
Yes, first thing I would recommend would be to use the Mailbox Calculator to level set that JBOD is a good fit for your organization. Note: Make sure you specify 3 or more database copies or the calculator will not recommend JBOD as a viable option. The nice part about the calculator is you can play with different SATA spindles (7200 RPM, 3.5”, 1TB, 2TB, etc) to arrive at different results.
Sample Mailbox calculator data showing JBOD is a fit:
Once you have purchased JBOD storage, I would leverage the following stress tools:
to benchmark your storage and hardware. Grab those tools here.
Is there a storage matrix I can use to reference?
I found this useful storage matrix put together from the product team:
Exchange 2010 Storage Guidance
Database Availability Group: 2 nodes, 2 Database copies
Database Availability Group: 3+ nodes, 3+ Database copies
Direct Attached Storage (DAS)
Storage Area Network (SAN): iSCSI
Supported. Best Practice = Do not share physical disks backing Exchange data with other applications.
Storage Area Network (SAN): Fibre Channel (FC)
Supported. Best Practice = Do not share physical disks backing Exchange data with other applications. Best Practice = Do not place both database copies on the same physical spindles.
Network Attached Storage (NAS): SMB
Physical Disk Type
Supported, requires battery backed caching array controller for data integrity
SSD (Flash Disk)
Physical Disk Write Caching (enabled)
RAID5/6, RAID10, RAID1
JBOD, RAID5/6, RAID10, RAID1
JBOD, RAID1, RAID10
Disk Array RAID Stripe Size (kb)
Storage Array Cache Settings
75% Write Cache, 25% Read Cache (with Battery Backed Cache)
Database/Log file placement
Best Practice (for recoverability) = separate database file (.edb) and logs from same Database on to different volumes backed by different physical disks
Database file (.edb) and logs from same Database can share same volume and same physical disk.
Database file (.edb) and logs from same Database can share same volume and same physical disk. This is a best practice for JBOD/RAID'less storage scenario where one or more volumes store the edb and log files backed by the same physical disk.
Based on backup methodology
RAID = based on backup methodology, JBOD = one DB file/volume is recommended
RAID = based on backup methodology, JBOD = one log stream/volume is recommended
Windows Disk Type
GUID Partition Table (GPT)
Master Boot Record (MBR)
Windows 2008 Default: 1MB
Drive Letter or Mount Point (mount point host volume must be RAIDed)
NTFS support only
Not required, not recommended
NTFS Allocation Unit Size
64KB for both edb and log volumes
Not Supported for Exchange Database files
NTFS Encrypted File System (EFS)
Windows Bitlocker (volume encryption)
Supported for all Exchange database and log files
More on storage planning here and here.
DAG samples here.