GLYPH<SM590000> Capacity 

During the planning of an IBM FlashSystem 9100 environment, capacity (physical) has to be sized accordingly. Compression and deduplication might save space, but metadata will consume a little bit of space and for an optimal performance our recommendation is to utilize the Data Reduction Pool to a maximum of 85%. 

Consider monitoring storage infrastructure requirements with monitoring and/or management software such as IBM Spectrum Control or IBM Storage Insights before planning a new environment. The peak workload, like IOps, MB/sec, peak response time, and so on, at busy times, will give you an understanding of the required workload plus expected growth. Also take into account to allow enough headroom regarding performance required during planned and unplanned events (upgrades and possible defects or failures). 

It’s important to understand the relevance of Application response time rather than internal response time in conjunction with required IOps or throughput. Typical OLTP applications require IOps and low latency as well. Do not place capacity over performance while designing or planning a storage solution. Even if capacity might be sufficient, the environment might suffer from low performance. Deduplication and compression might satisfy capacity needs, but aim on performance as well for robust application performance. 

In order to size an IBM FlashSystem 9100 environment accordingly, you can use Disk Magic. The tool can be used to determine, that Data Reduction Pools are going to give suitable bandwidth and latency. If the data won’t deduplicate (according to the DRET tool) the Volume can also be fully allocated or compressed only. 

## 4.1.4 Flexibility for the future 

During the planning and configuration of Storage Pools, the decision has to been taken which pools to create. As the IBM FlashSystem 9100 allows you to create Standard Pools or Data Reduction Pools you have to decide which type fits the requirements best. 

We have already discussed requirements, such as workload and performance, and if the data is compressible or if the data will effectively deduplicate. Verify if the performance requirements meet the capabilities of the specific Pool type. Therefore you can see the section “What are the workload and performance requirements” on page 67 for more details. Later we will cover the dependencies with Child Pools and VVols in “Child Pools and VVols” and “DRP restrictions” on page 96. 

If other important factors do not lead to using Standard Pools, then Data Reduction Pools are the right choice. Usage of Data Reduction Pools can increase storage efficiency and reduce costs because it reduces the amount of data that is stored on hardware and reclaims previously used storage resources that are no longer needed by host systems. 

Data Reduction Pools provide great flexibility for future use. They add the flexibility of compression and deduplication of data at the volume level in a specific pool even if these features are initially not used at the time of creation. 

Keep in mind that it is not possible to convert a Pool. If you have to change the Pool Type (Standard Pool to a Data Reduction Pool or vice versa) it will be an offline process and you have to migrate the your data as described in 4.7.5, “Data migration with DRP” on page 99. 

Note:  We recommend to use Data Reduction Pools with fully allocated volumes as long as the restrictions and capacity do not affect your environment. For more details on the restrictions please see “DRP restrictions” on page 96. 

