Virtually Jason

I recently had the chance to do some testing with PernixData ’s vSphere solution and it was very educational.  It worked great, doing exactly what it was supposed to do… and it also got me thinking about the nature of storage caching. For just about ever, caching has been the technique that allows storage devices to provide the blazing performance that we all demand.  Monolithic SANs always have some amount of cache on their controllers.  What exactly does that cache do?  As the name implies, it caches data.  On those SANs, we would typically assign some amount of read cache and some amount of write cache (I’ve typically biased my vSphere storage devices heavily towards write cache, but opinions vary).  When a write request comes in, it is very quickly written to that cache and the acknowledgement is sent to the device that is performing the write.  The SAN’s job is then to destage the data from the cache onto the disks for long term storage, whic...

IOPS – Input/Output Operations Per Second – is a key factor when designing a View solution (more important than storage space even, given the various tools that deal with storage consolidation). That’s old news. What I’ve been having fun doing recently is trying to determine just what kind of IO I can expect from the various LUNs that have been carved from my SAN. I’m using pretty standard techniques here that would work for any server analysis, however I’m applying them to my virtual desktops in order to ensure that my storage can support the number of desktops that I plan to load up. We’ve probably all seen tables that reveal per disk information in a table like this (taken from Wikipedia): Device Type IOPS Interface Notes 7,200 rpm SATA drives HDD ~75-100 IOPS [2] SATA 3 Gb/s 10,000 rpm SATA drives HDD ~125-150 IOPS [2] SATA 3 Gb/s ...