The new HP 3PAR StoreServ 7450
Earlier this year (I actually wrote this post to co-incide with the announcement but it has sat in my draft box ever since – my bad…), we announced the HP 3PAR StoreServ 7450 – A purpose built flash optimised 3PAR array designed for the environments wheres things can get a little ….. crazy. Crazy in the sense where the application is demanding up and above the “usual” performance requirements architects typically see with other workloads – File serving, VMware (which is mixed and sometimes unpredictable)-even SQL and Exchange environments are part of the “usual” suspects when it comes to architecting for IOPs. We also announced a number of other enhancements throughout this launch including QOS and Recovery Manager for Hyper-V environments.
The need for lower latency and faster response.
Not all applications and subsuquently IO’s are created equal, flash is purposefully design for the applications which require sub-millisecond and high-end IOPS for performance intensive environments. the new HP 3PAR StoreServ 7450 clocks in approximately 550,000 IOPS with a latency of under .7ms. And the 7450 uses an 8-core Intel Xeon Sandy Bridge processor running at 2.3Ghz, compared to the previous 6-core 1.8Ghz model
Flash Virtual Environments “Flirtual” 🙂
Virtual powers cloud, Cloud powers Services, and providing services are all about meeting SLA’s. Delivering a service is one thing, delivering a service well and quickly with a guaranteed satisfaction level is another.
3PAR Family
Cloud-hosting services may benefit from 3PAR 7450 for their customers who require those latency times and IOPS I mentioned earlier in this post. However I must stress that the HP 3PAR StoreServ 7450 is NOT a one size fits all, consider the following graphic on where it sits within the 3pAR family. Additionally, check out my post on the other 3PAR 7000 members here.
The purpose of me making this emphasis is that there is one family, and subsequently one operating system, so a multi-3PAR environment means you can shift workloads between the different arrays using HP 3PAR Peer Motion – or as we call it Storage Federation – check out this brief on Peer Motion covering the requirements and supported O/S . Note: Tiering at the cache and hard-drive levels only occur within the one array, meaning Dynamic Optimisation\Adaptive Optimisation cant (yet) identify a suitable tier on a separate 3PAR to place a particular volume.
But back to the 3PAR 7450 specifically.
All cached up – Cache Handling and Cache Offload on 3PAR
The software on the HP 3PAR 7450 uses a page size of 16K for cache, what that means is that it can handle up to 16K of read and\or write IO’s for serving data from cache. So without flash, if we had a read operation of 8KB, we check to see if we can serve out of cache, if it is not there – we retrieve the data from back-end disk to serve the request and then store it in cache for future use. This can result in a slightly higher latency if spinning disk is used.
But we are talking flash here!!! Let’s take a look how an all flash array may do this same request. Same example, a 8K read request comes through, if it is not in cache, again 3PAR software looks to the backend storage to serve the request but as there are no spinning drives or concept of disk heads aligning. So from Flash to Cache, we call this Adaptive Reads – 8K of data is read from the flash drives back into cache at super speeds. More granular examples such as 4K result in even less data being read (but still the right amount), only 4K of data gets transported enabling even higher backend throughput making it super efficient.
The same goodness extends to write operations but altered slightly to allow fragmented writes, for IO’s smaller than 16K, such as 8K – we would only write 8K to the flash drives, we don’t flush the whole 16K. If we did, we would see the flash drives getting hit more than what is required . Flash has a limited lifetime, writing as little data as possible is best for this reason.
But wait theres more………Just as HP 3PAR Dynamic and Adaptive Optimisation provides policy driven “autonomic” movement of data blocks based on utilisation levels at the CPG level. We extend these ideas into the cache and flash tiers on the 7450. So
To be flash is to be expensive
But Flash storage is traditionally expensive and comes in different flavours SLC and MLC – one more reliable and expensive than the other (I’ll save this discussion for a separate post), Why would a CIO splash out thousands of dollars without proper justification as to why a certain response time is required – in fact I still see situations where Infrastructure architects are speccing flash with capacity in mind, flash is NOT about capacity given the price points so it should not be treated as such. IOPs per GB is the wrong way to look at it given the tiering solutions there are out there these days that assist in storage efficiencies. IOPS per IO is a suggested followed by meeting capacity requirements.
For more information on HP 3PAR StoreServ 7450, please visit http://www8.hp.com/us/en/products/disk-storage/product-detail.html?oid=5386547#!tab=features
