2010-10-04 08:05 PM
I'm implement SME 6.0 with Exchange 2010, and when i have two or more mailbox databases in a LUN, SME show me an invalid configuration.
SME only work with one Exchange database per LUN?
My customer want create 20 databases, and this implies that i must have al least 20 lun in Exchange server!!
Thanks in advance
Solved! SEE THE SOLUTION
2010-10-05 08:12 AM
If you dig out the TR-3845, it actually says on page 4 in 'Layout Recommendation' section:
"For Exchange Server 2010, multiple mailbox databases cannot be put on the same LUN"
I have no idea where this comes from (Microsoft limitation / recommendation?)
It looks a bit odd, as the recommendation for Exchange 2007 is quite opposite & they encourage you to have a single LUN for multiple databases (although you can still opt for separate LUNs).
2010-10-05 08:35 AM
The difference is in Exchange 2007 you had Storage Groups (which contained multiple databases) and in Exchange 2010 SGs no longer exist (you only have databases). I think best practices encourages you to make sure you have things laid out for the most granular level of restoration and replication. In Exchange 2007, this was at the SG level, I believe. IN 2019, it's now at the database level, thus you should not group multiple databases on a LUN.
2010-10-05 08:40 AM
Yeah, I see the point & personally I do like granular recoverability.
Having said this, there is a huge difference between 'you should' and 'you have to' - so the only outstanding question is why SME is saying the latter, not the former?
2010-10-05 02:16 PM
I apologize for the TR not being clear cut on this. But here's the text from the SME 6.0 IAG around database placement and SME restrictions. This is on page 77 & 78.
Database migration considerations
Databases from different Storage Groups cannot share a single LUN. Also, databases cannot
share a single LUN with transaction logs, even if both belong to the same Storage Group.
Note: SnapManager restores all databases on a LUN together. To restore an individual
database without restoring the rest of its Storage Group, move the database to a separate LUN.
Note: In a Database Availability Group (DAG) configuration, it you have a drive or LUN
existing on all the nodes and this drive is used by a database only on some nodes, then other
databases cannot use this drive on other nodes of the DAG.
Hope this helps. I'll work on getting better text in the TR.
2010-10-05 07:36 PM
Pretty sure your issue is with the fact that Exchange requires logs and db's to be on thier own LUN's as its a requirement of VSS.
SME leverages VSS and exchange api's to quiese each database prior to taking a snapshot.
2010-10-06 05:19 AM
This means that in Exchange 2007, VSS acting a SG level and in Exchange 2010, VSS acting a database level?. This explains the requirement that each LUN can store only one database.
Unfortunately, many customers prefers a lot of DB with a few users in each one but this approach implies have a lots of LUN for SME use (Exchange 2010 support up to 100 DB)
2010-10-06 10:51 AM
Here's a TechNet article that goes into more detail on LUN architecture for Exchange 2010.
Although you can have either the database & logs on a single LUN *or* multiple databases on a single LUN & the logs on another, you would not be able to back up your Exchange databases using VSS. SME uses VSS during its backup process, so therefore, the single database per LUN requirement is there.
And you're absolutely correct...with this requirement, the number of LUNs will definitely increase and multiple databases are created. I guess there has to be some education with customers about the affect of creating multiple DBs for particular users.
Let me know if you have any questions,
2010-10-06 03:10 PM
Not sure if you are aware but the 'recommended' db size limits in 2010 is several orders of magnitude larger then 2007 so you will most likely find you will end up with significantly less LUN's assuming you follow best practices around sizing.
2TB databases on sata disk seems to be a fairly common size being used in the industry atm, whereas 2007 builds were generally around 250-350GB on SAS/FC. So basically mailbox databases are getting collapsed by at least a factor of 6 and onto extremely cheap disk to provision.