How We Can Help You - Solution Reviews

My question is can you validate my approach for giving guidance for a layout for a four engine VMAX?  For this environment we have 600GB 10k disks.  Here is what I have to work with.

I have been asked to validate a design for a customer's Exchange 2010 future environment.  Upon researching what had been accomplished on the pre-sales side I found that no design work had been accomplished for Exchange 2010.  A resource from the MS Practice was asked to come in and have discussions with the customer around “Best Practices”.  No one has documented a MS Exchange 2010 Calculator.  The only thing that was done, by the customer, was his own calculations (attached).  I have no information on DAG layout, replication, backup, number of mailbox servers, etc…  I did make an attempt at putting together a manual calculation based on the information provided to me (bottom of this doc).  I have spoke to the SA for this implementation.  He supplied me with his BIN file configuration.  The customer is asking that someone from the MS Practice take a look at this configuration and validate it.  This is difficult when no design work has been done by us.  So, my approach was to take the information supplied and reference existing best practices for validation.  Here is what I have.

After reviewing the latest Best Practice Presentation from Corporate here is what I have from a guidance point of view.

From the Exchange 2010 Storage Best Practices – EMC World 2011.pptx

Slide 25 - Design guidance for Exchange 2010

• Isolate Exchange server workload to their own set of spindles from other workloads to guarantee performance.
  
• When sizing always calculate I/O spindle requirements first, then capacity requirements
  
• Sharing disks for database and logs from different Exchange databases is acceptable
  
  • If replication is used in the environment sharing database and logs of the same Exchange databases becomes an option.
    
  • DAG copies should be deployed on separate physical spindles
    
  • Databases up to 2TB in size are acceptable when DAG is being used
    
  • Consider backup and restore times when calculating the database size
    
  • Spread the load as evenly as possible across array resources, V-Max Engines, VNX SP’s etc.
    
  • Always format Windows NTFS volumes for databases and logs with an allocation unit size of 64k
    
  • Use an Exchange building block approach to design whenever possible
    

This is from V-Max CX4-960 Exchange 2010 Design Validation Testing 12-16 WebEx ver3

Slide 10 - Design guidance for Exchange 2010 on V-Max

• Database and its Logs for the same DB should be placed on different spindles.
  
• In DAG configurations the source and target LUNs can be in the same array but should be on, separate spindles, and V-Max Engines.
  
• Use an Exchange building block approach to design whenever possible.
  
• IO requirements include user IO (send\receive) plus 10%. Sequential IO like log, BDM, etc is not factored in. See MS TechNet guidance below:
  
  • Pure sequential IO operations are not factored in to the IOPS per Mailbox calculation since storage subsystems can handle sequential IO much more efficiently than random IO. These operations include background database maintenance, log transactional IO, and log replication IO.
    
  • Use fewer larger hyper volumes in creating LUNs will result in better performance.
    
  • Minimum two HBA’s per server, one connected to an even director the other to odd director, and when possible too different V-Max Engines.
    

All this being said, I believe that the logs should be on separate RAID 10 Spindles.  Separate RAID 5 pools for the DB copies within the DAG (3).  I believe the archive DB’s could be spread to alternate pools, different from the pool where the active DB lives.  This is just a recommendation.  As an alternate, I would at least create the log LUNs for a DB from a pool that it is not in.  for example if there are three pools (Pool A, Pool B, Pool C).  Then DB1 will have LUNs from Pool A, Logs for DB1 created from Pool B and so on.

At present, the BIN file has five pools using RAID 5 (3+1).  From a performance stand point, based on the information I have, this looks to be adequate.  My calculations show this is a capacity based configuration using 600 GB 10k disks.  One word of caution, I have baked in a lot of assumptions.

Manual calculations:

IO calculations

9,000 @ 150 messages or 0.150 IOPS = 1,350

1,350 IOPS is the total application IO from the above, and concurrency rate determined to be 100%

1,350 * 1.2 IO overhead MS is requesting = 1,620

1,620 * 1.2 IO overhead for Log and BDM activity requires = 1,944

Matching the math to the Microsoft calculator

• 1,944 IOPS is what is required for all active users per copy, this number is multiplied by the amount of copies requested. In this case 3 copies are required.
  
• 1,944 * 3 = 5,832
  
• 5,832 is then divided by the amount of servers / 4 = 1,458
  
• 1,458 can then be divided by the 39 databases/logs per server / 39 = 37.38  this will then be rounded to 38
  
• The Microsoft calculator outlines 38 IOPS per database/log which matches EMC’s calculations 
  
• Total application IO at target site 38 (DB/Log) * 39 (# of DB/Logs) * 4 (# of Servers) = 5,928
  

Array based calculations “total IO”:

The read/write ratio has been determined to be 3:2 so your reads and writes are calculated accordingly

60% read  - 5,928 * 0.60 = 3,556.8

40% write – 5,928 * 0.40 = 2,371.2

RAID10 calculations is determined by adding the reads plus the writes including a *2 write penalty for RAID10

3,556.8 + 2 ( 2,371.2 ) = 8,299.2

RAID5 calculations is determined by adding the reads plus the writes including a *4 write penalty for RAID5

3,556.8 + 4 ( 2,371.2 ) = 13,041.6

Server Building block

Capacity

• Each server will have 39 databases and 39 log files
  
• Each database and log file set will be 645 GB
  
• 645 GB * 39 = 25,743 GB rounded to 25.75 TB per server including the restore LUN which is 588 GB
  

IO building block

• Each server will be driving 1,482 application IOPS
  

60% read  : 1,482 * 0.60 = 889.2

40% write : 1,482 * 0.40 = 592.8

RAID5 calculations is determined by adding the reads plus the writes including a *4 write penalty for RAID5

889.2 + 4 ( 592.8 ) = 3260.4  / 130 IOPS which each 600GB FC drive can deliver = 25 round up to 28 for RAID 3+1

28 drives in a RAID5 configuration yields approximately 11.25 TB of capacity which does not meet the requirements.  You will need 68 drives which yields ~27 TB per server.

Total Summary

Thanks!  We're taking a look at what you have right now!

Done

Greetings, Bart.

Any chance I could convince you to post your request as a question in the discussions?  A couple of reasons:

1.  It'll keep this particular discussion (the solution review offering) on topic.

2.  It'll make sure that you're question about Exchange design is kept on topic.

3.  It'll make sharing the design discussion easier for other folks to find and participate in.

Sound good?

You can just copy and paste the text and click "Start A Discussion" over on the right hand side.

Thanks.

Rob Tacey

Solution Design Center