Why so much fluff?
When you use the Exchange 2007 Mailbox Storage Calculator on the face of it you seem to get a lot of fluff added to your storage design. ..fluff upon fluff. Will run through some of the reasoning where it may not seem obvious in the cell comments themselves.
LUN Free Space Percentage: couple of reasons to leave a percentage of the LUN free – performance and room for error. The more of the disk you use the longer the seek times and hitting data held on the last 20% of a disk will decrease performance markedly. [The opposite of short-stroking the disks for performance gain.]
..and of course if you don’t use this last 20% you have some room for manoeuvre. SCOM will report that you are running out of space and at that point you have some time and space to do something about it.
Data Overhead Factor: (..the so called ‘fluff factor’ ) Well this is better explained on Technet here.
“This value will account for the other data that resides in the database that is not necessarily seen when calculating mailbox sizes and white space. For example, the data structure (tables, views, and internal indices) within the database adds to the overall size of the database.”
I/O Overhead Factor:This is pretty simple – your I\O calculations are going to be estimates only and you need to account for periods of unexpected high activity and to give some room for times where your estimates are slightly out.
Additional I/O Requirement / Server: I have used this to add BES overheads and also where I am hosting public folders on the same server; and perfectly explained within the cell comments…
“Add in an additional I/O total value if you know that there will be additional load on the database disk drives that are not included in the mailbox IOPS factor.
Examples: - Store-based anti-virus, - A third-party mobility solutions, - store-based journaling, - client-side search engines when using online mode clients
To derive at how much overhead is needed, measure it in a controlled environment by comparing a baseline system against a system that has the I/O generating application installed and running.
For example, let’s say Application x generates 500 additional I/Os when compared with the baseline system. In that case, you want to enter 500 into this field.
Or consider this methodology. You know an application that you will be using will generate an I/O increase per mailbox. To determine how much I/O you need follow these simple steps:
1. Determine the I/O requirements without the application's overhead.
For example, you are designing a solution for 1000 heavy profile mailboxes. From the output of the calculator you know that each mailbox will require .32 IOPS, for a total of 320 host IOPS required to sustain all the databases.
2. Determine the application overhead.
For example, the application increases the I/O overhead by a factor of 4. For this scenario that would be (1000 *.32 *4) = 1280. So the total I/O that has to be sustained from the host perspective for the databases is (1280 + 320) = 1600
3. Enter in the application overhead into the "Additional I/O Requirements" field.
For our scenario you would enter 1280.”
Dedicated Maintenance / Restore LUN? : …and this is just one to watch out for. If you don’t use a dedicated maintenance/restore LUN and particularly if you are deploying big servers with lots of mailboxes you’ll see your storage capacity requirements grow considerably. This is because the calculator now adds sufficient space for maintenance for every LUN and database it recommends you deploy…
Comments
Anonymous
February 26, 2009
PingBack from http://www.clickandsolve.com/?p=15579Anonymous
February 27, 2009
When to use Move Mailbox Wizard or ExMerge to move Exchange mailboxes Exchange 2007 SP1 Features with