HP 3PAR recently released version 3.2.1 of the InForm OS, which most notably brought in-line deduplication to the already rock-solid storage platform. Last week, I wrote briefly about it and included screenshots of estimates in the CLI. Today, I’d like to share real-world results.
I’d like to give particular thanks to Ivan Iannaccone of the HP 3PAR team for reaching out and for early access to the 4.6.1 IMC with dedupe in the GUI.
After I ran the estimate in the previous post, I learned from Ivan that estimates (and jobs) of multiple virtual volumes (VVs) in the same common provisioning group (CPG) will return increased data reduction ratios (read: less used space). Thus, when I received the new InForm Management Console (IMC) yesterday, I ran a new estimate against two VDI (Microsoft RemoteFX) VVs to see how the numbers panned out.
As you can see, the dedupe ratio rose from 2.31 to 2.83. Every little bit helps, but what is the actual deduplication ratio?
In the new IMC, I followed these steps to start the jobs:
- Go to the “Provisioning” section
- Expand “Storage Systems” > “[array_name]” > “Virtual Volumes”
- Select “Exported”
- Go to the “Virtual Volumes” tab in the upper right pane
- Shift-select both RemoteFX virtual volumes (“rfx_ssd_a” and “rfx_ssd_b”)
- Right-click the selected VVs and click “Convert Virtual Volume…”
- In the top section, change the radio button to “To Thinly Deduped”
- In the bottom section, move down the two VVs to be converted
- Lastly, I chose to keep the “Target CPG” the same as the source (these are the only VVs in that CPG)
At this point, it is prudent to mention that you should review your available SSD capacity before starting the conversion job. When I ran these two jobs (each VV is its own job), my free SSD capacity on the entire array dropped to 116GB (3%). It’s possible that the IMC would have warned me before letting me run jobs that would have exhausted the free space, but I can’t say.
To be absolutely certain and safe, the array would require each job to reserve 100% of it’s source space before starting or letting other jobs begin. Otherwise, it is conceivable that a job running against entirely unique data would only achieve a 1:1 ratio and thus save no space. That job alone could run out while in process, let alone multiple jobs of varying outcomes.
Back to dedupe, the jobs ran concurrently for 1 hour and 25 minutes and had this result:
Content temporarily removed. Check back later…