As long as you have the correct FLARE version, there is no limitation in implementing FAST as you have described here. You should be able to create a pool consisting of Flash and FC drives. If you have the FAST enabler installed, you will be able to schedule relocation windows, choose tiering policy for the LUN, etc.

A recommended read would be the FAST whitepaper on Powerlink which goes into the details of what features are provided by this feature.

Thanks Avi.

I learnt that the data will be spread across 1 GB chunks in each disk of the storage pool. Hence is there any recommended Stripe Size for storage pool. The storage pool if of RAID 5.

When you create a pool, private RAID Groups and LUNs are created on the drives (RAID 5 pool creates as many 4+1 private RAID5 RAID Groups as possible). Once you create a new pool LUN, slice allocations happen in 1GB chunks from these private LUNs as and when you need capacity in your pool LUN. These 1GB chunks are spread across the pool drives to ensure that all the pool drives are equally utilized.

There are numerous discussions on this topic in this forum which you can refer for more details. Also, there is a Virtual Provisioning whitepaper on Powerlink which will explain this in detail.

Stripe size with pools would follow the same rules as RAID groups.. Since a RAID5 Pool uses 4+1 internally, the stripe size would be 256KB. A single 1GB slice will be comprised of many 256KB stripes.

Richard J Anderson

I strongly suggest you not use Raid5 for this implementation - it would be a mistake. When you have 80% write you really need to go with Raid 1. This is because each write from the server turns into 2 writes on the back end when using Raid 1, whereas it turns into 4 writes on the back end when using Raid 5. This is a big deal when you have VDI temp cache since this is a high IO application.

For example:

15 IOPs per concurrent VDI user (Windows 7 is very chatty with this many IOPs per user); 500 users would be 15x500 = 7500 IOPs. Ratios we have seen in benchmarks show closer to 90% write for this with XEN desktop. So, 90% of 7500 is 6750 write IOPS a second. Now we multiply by 4 for Raid 5 for a back end requirement of 27,000 IOPS (6750x4=27000), whereas with Raid 1 we multiply by 2 (6750x2=13,500 IOPs). In both cases we add back in the read IOPS(7500x.1=750). So, grand total back end IOPS requirements for this application are: Raid5 (27000+750=27,750 total IOPS) or alternatively Raid 1 (13,500+750=14,250 total IOPS).

Here are the disk requirements based upon 15k rpm disks getting max 180 IOPS (but scaled back to 170 IOPS max to have room for IO bursts):

Raid 5 = 27,500/170 = 162 physical disks required

Raid 1 = 14,250/170 = 84 physical disks required

The issue with VDI for temp cache (and really any extremely high write IO workload) is not so much to optimize for capacity (i.e. Raid5) as it is to optimize for IOPS (i.e. Raid1).

We just went through this exercise here for a similar environment, so that is why I have these stats so handy to share with you.

Eric

One more point: SSD is not appreciably faster for writes than using 15k rpm disks (due to internal SSD architecture). If you look at EMC recommendations for use of SSD you will see this is clearly stated that SSD is not indicated for speeding up writes. Since this workload is nearly all writes it may not make sense to use SSD for this application.  

Uhm…. A write will NOT turn into 4 writes on the back end, it turns into 4 IOs: 2 reads and 2 writes, but the effect is the same: 1 front end IO --> 4 back end IOs