Start a Conversation

Unsolved

This post is more than 5 years old

1053

March 12th, 2012 04:00

Should I use Fast VP with Exchange 2010

Good morning Community

I have been asked if we should be using Fast VP with Exchange . That is a great question and I would like to ask the community what they think about using Fast VP with Exchange. By doing some reading I know that this depends entirely on the customers requirements.If the customer needs to be able to handle High IO spikes then Fast VP might be a good fit for them. according to White Paper "Microsoft exchange 2010 Storage Best Practices and Design Guidance for EMC storage" on page 16. they say to perform sizing according to Fast VP policy requirements using the 80/20 Skew assumption (80% on fiber and 20% on Sata) perform sizing exercise only on fiber channel and sata drives and use a small percentage on Flash to handle unexpected spikes.

have you used this approach and how did it work for your customer?

I also found a great white Paper that goes over Fast and Fast VP on exchange I add the link below for your reading pleasure.

"Storage Tiering for Microsoft Exchange server and EMC Symmetrixs"

http://www.emc.com/collateral/hardware/white-papers/h6733-storage-tiering-exchange-vmax-wp.pdf

2 Intern

 • 

643 Posts

March 12th, 2012 22:00

In comparison to earlier versions of Exchange, 2010 contains significant improvements in the areas of I/O and storage.  For example, there have been many changes to the core schema and extensible storage engine (ESE) to reduce the I/O usage profile. Due to this I/O reduction, Exchange2010 now supports a varity of different drive types such as SATA, SAS, FC, EFD, etc.  Low cost SATA can now be used for Exchange database and logs.  This allows for large mailbox at reduced cost without performance degradation.

2 Intern

 • 

225 Posts

March 14th, 2012 02:00

Bill,

I also noticed that not only on F_VP sizing on Exchange 2010 but also on VMware sizing.

The sizing methods mentioned on these articles only use smaill # of EFDs to absorb unexpected IO than count IOPS of these EFD on the baseline of sizing result.

I think these methods have more consideration on safety on an initial sizing, since F_VP sizing kind depends on real IO pattern.

It is good to me, since we could use pool tech to expend the configuration after received real IO information after application running for a while.

Eddy

No Events found!

Top