Data Reduction Pools (DRP) deliver thin If best practices are not followed : provisioning, compression and deduplication across all volumes in a pool • Running out of storage will take volumes offline, making it difficult or time consuming to recover Requires best practices be followed because :
The FlashSystem 9100, Storwize V7000 Gen 3 and When using FCM based products: Storwize V5100 contain compressing physical storage (ie. FlashCore Modules, or FCMs) The user should ALWAYS monitor physical space
FCMs compress data at line speed with no performance The GUI will ensure the user creates configurations that impact to the workload are sensible and measurable
DRP is fully supported within these products, even when And the storage controller uses knowledge of both the using FCMs logical space and physical space (This is an advantage of Spectrum Virtualize being tightly integrated with the storage controller where more information about the underlying storage is known) If virtualizing external storage using these or any other Spectrum Virtualize products, then the best practices still apply!
If you create a solution where data reduction technologies ALL DRP volumes should run with compression switched are applied at both the storage and the virtualization on appliance levels, then here are the rules you should follow: (DRP uses Intel Compression Acceleration hardware & will not adversely affect general DRP performance)
Physical storage should be allocated 1:1
This means the usable capacity in the storage must be equal to the effective capacity provisioned to SVC. Review documentation for how to do this for your storage system.
Fully allocated volumes should be in their own pool
7
If you want to use DRP with an existing over-allocated
backend, you need to reclaim storage and configure it according to the best practices
Recommended! Spectrum Virtualize with DRP Use DRP at top level to plan for de-duplication and snapshot optimisations. DRP at top level provides best application capacity reporting (volume written capacity).
Fully Allocated Storage
(e.g. Storwize V5010) Always use compression in DRP to get the most benefits from the technology
Spectrum Virtualize Need to track physical capacity use carefully to avoid
with Fully Allocated out-of-space.
Spectrum Virtualize can report physical use but does not
manage to avoid out-of-space. No visibility of each applications data usage at the Data Reduced Storage Spectrum Virtualize layer. (e.g. FlashSystem A9000)
If actual out-of-space happens there is limited ability to
Assume 1:1 (effective:usable) compression in backend
storage – do not overcommit! Spectrum Virtualize Review product documentation for how to do this with DRP w/compression Small extra savings will be realized from compressing meta-data.
Monitor capacity and out-of-space alerts from the
backend storage system.
Data Reduced Storage Using DRP with over-allocated back end could lead to (e.g. FlashSystem A9000) the DRP garbage causing out-of-space
Think : For existing systems, do you need to move to
Avoid!! Spectrum Virtualize Very difficult to understand used capacity when DRP w/compression + FA combining DRP and FA and a compression backend
Temptation is to try to exploit capacity savings which
might overcommit backend
If a mix of DRP and FA is required, then use separate
pools; Previous design patterns can be used, but must Data Reduced Storage not combined in the same pool (e.g. FlashSystem A9000) (Or use with extreme caution and with a ~<20% mix of fully allocated)
Changes in compressibility of data between the tiers
can overcommit the storage leading to out-of-space. Data Reduced Storage Data Reduced Storage (e.g. FlashSystem A9000) (e.g. V7000 w/ DRP) Think: Is there risk my hot data is incompressible?
Flexibility Is Great, But Choose The Right Choose The Right Design Pattern Technology Don’t over-complicate Use Disk Magic to model the performance with both FCM and DRP data reduction If virtualizing a compressing storage system use a (IBM or your Business Partner can help with this) recommended design
Use Compresstimator to identify expected space savings. Other designs make it impossible to understand your real Data Reduction Estimation Tool (DRET) can identify capacity consumption and you will run out of space! deduplication workloads.
Use FlashCore Modules with inline hardware compression
for best performance
Use Data Reduction Pools if you can really benefit from
Good Deduplication Workloads Successful VDI Deployment
A workload with a lot of identical data across one or more VDI tends to have a large write contingent of around volumes 30/70
The more duplicates there are, the greater the savings As well as having a lot of duplication, this kind of workload realized in terms of physical space used benefits from having more cache
As mentioned, data reduction costs IOPS, so balance the To fully realize the benefits of the system, configure the capacity savings against the performance requirements VDI deployment across multiple VMFS datastores so as to increase parallelism. At least 16 if possible.
A great example of a deduplication friendly workloads is
Configure alerts – get warned EARLY when capacity starts Plan for high bandwidth demanding workloads (such as to fill up migration in) consuming excessive system resource • Allow enough time to delete or migrate data or augment existing capacity • Follow Spectrum Virtualize best practices to create a balanced system Running out of physical capacity will take volumes offline • Consider additional resource usage when using DRP • Use QoS to throttle heavy workloads and protect other Monitor your reclaimable capacity and free space to do workloads running on the system longer term planning (Throttling may elongate time taken to run a workload)
White Paper - Best Practices Details for Managing Physical Space on FlashSystems 900-AE3 https://www-01.ibm.com/support/docview.wss?uid=ibm10735459
