By Andre Carpenter, Senior Solution Architect in Australia
(Editor's note: I did a podcast introducing Andre while at VMworld San Francisco)
My colleague Calvin Zito wrote a great blog recently talking about why he thought 3PAR is awesome for VMware. I agree with him and wanted to share a deep dive post on why I agree.
The traditional RAID era and how the storage world has changed.
I started my storage career doing design and implementation services in this era; not all RAID groups were created equal, and it seems (at least to me) that more thought and planning had to be put in with traditional RAID because the arrays weren’t as capable and smart as they are today. There was no concept of automated storage tiering or shared storage pools for example.
The spindle count in RAID groups were calculated by storage architects based on host IOP workload requirements. There was no real concept of throwing all spindles into one big “pool”, and then carving and provisioning storage from that pool.
The architecture is similar to this example image depicting the traditional era; each RAID group was more or less dedicated to one particular workload.
Things have changed since then, thus the concept of shared pools or shared storage was born; this was to drive initiatives like cloud computing, deduplication (if your array supported it natively), and storage tiering amongst other things. By having this shared pool of resources, workloads were “spread out” across the storage resources thus generating a bigger pool of grunt to draw from.
HP 3PAR does this in the form of wide striping, breaking storage down into “chunklets”.
The term chunklets may sound like some sort of breakfast cereal, but although not of the food variety the concept definitely still holds some nutritional value for your storage requirements. Here’s how they work:
- An HP 3PAR array is populated with one or more disk types; these can be either Fibre Channel, SATA, or SSD. In order to provision storage from these drives to a host, there needs to be a Common Provisioning Group (CPG) created; this serves as a template for creating LUNs. Typically, the CPG needs to be of the same disk type and the same RAID characteristics.
- From there, LUNs can be created and provisioned to the host. When ESXi hosts starts storing virtual machine data - whether its virtual disks data or meta data to the LUN - each physical drive is broken down into 256 MB chunklets that the LUNs can use to store the data. One point to note is that there is also chunklets for distributed sparing as well.
As an example, for a single 600Gb drive you will have 2400 chunklets at your disposal for virtual machine use (600Gb*1024Mb/256Mb). When you add more shelves of drives, the picture gets bigger as does the performance.
From physical disks right through to the LUNs that are provisioned to the ESXi host, the result is that the chunklets are created across all of the spindle types in the array as defined in the CPG. This system wide allocation super charges performance for virtual workloads.
Ready for provisioning to the host!
The result is an architecture that is optimal and balanced for mixed workloads, including virtual environments with their own mixed workloads within.
Multi Raid? Sure!
One hard question as a storage architect to answer is “what type of RAID shall I use for this virtual environment?”. This question is typically answered with the usual “It depends” response. Different workloads call for different strategies as different RAID types have different RAID penalties\performance considerations.
There is a consensus in the industry to consider the following rules of thumbs (these are only rules of thumb and are not best practices in any form):
- RAID 1/0 – Usually higher write intensive random workloads suit this.
- RAID 5 – Arguably one of the best all-rounders, offering a good balance of performance and redundancy. Modest random workloads are a good fit.
- RAID 6 – HP 3PAR offers double parity protection in the form of RAID-MP, offering a higher redundancy (double failure) than RAID 5 but at the cost of usable storage and performance because of the added write penalty.
It is important that all crucial data is protected; this includes virtual machines that provide various services for your organisation. In HP 3PAR, RAID protection is achieved by striping the data (whether RAID 5, RAID 6 or RAID 1/0) across chunklets that are spread across multiple disks, across disk magazines and across shelves in the array, so that your data can survive a failure of any of these components. VMware environments rely on a solid robust RAID architecture to provide the redundancy for the virtual machines, features such as VMware HA, VMware Fault Tolerance and even DRS features all benefit from well-architected RAID platform.
Regardless of which RAID type is used, making a write I/O takes time. The quicker the write is made, the better the latency and throughput and the less write penalty is observed.
Gen4 ASIC to super charge performance and efficiency
HP 3PAR has a secret sauce to handle storing data fast. Each HP 3PAR node has two Gen4 ASIC with the ability to do thin conversion data on the fly.
This architecture steers the workload away from the controller node to avoid driving the CPU usage up trying to convert and write data, allowing the nodes to focus on serving data and delivering high service levels rather than converting. The VMware VAAI primitive Zero Blocks/Write same can also utilize this resulting in a true thin environment!
VMware eager zero thick (EZT) datastores thrive on this technology. An example is that EZT’s are required for VMware Fault Tolerance; traditionally thick in nature, moving to 3PAR offers a unique way of “thinning” those EZT datastores without the hypervisor even knowing!
Dynamic Optimisation (DO) and Adaptive Optimisation (AO) – Where hot is hot and cold is cold.
Here is something really cool: virtual workloads have different performance requirements with some VM’s demand more resources and performance than others – that’s a known fact. What 3PAR can do with these variety of workloads is offer an automated tiering function which comes in two flavours.
Dynamic Optimisation (DO) is the automated tiering of the whole datastore or LUN, so when the virtual machines that the datastore houses become busy or “hot” then the LUN is promoted into a faster tier. This is similar to VMware Storage DRS but the notable difference here is that the array moves the data not the ESXi host.
Adaptive optimization (AO) goes one step further and moves the blocks within the datastore (as opposed to the whole LUN with DO) up and down the tiers.
So VMware datastores now become balanced across different tiers, hot blocks exist in faster storage tiers and cold blocks reside on slower disk all with the help of HP System Reporter, which acts as the brains behind the magic.
The end result is that your data gets automagically spread across all disks and all disk types in the 3PAR, with hot regions on fast disks and cold data on slow disks. The whole performance capability of the entire array is made available to all of your data automatically; this is how virtual workloads should be stored!
Here's the key takeaway to remember for this architecture built for VMware.
The main contributor of an array’s performance is determined by how many disks of each disk type is installed in the array, the more drives you have in the CPG then the more throughput and overall IOPS is available to all of your VMFS datastores and subsequently your virtual machine workloads. With HP 3PAR architecture and functions such as ASIC, DO, AO and wide striping the array works out the best way to store your virtual workloads driving up performance of the workloads while keeping your environment thin and efficient. And that’s why I firmly believe that HP 3PAR architecture is fit for VMware environments.