The number of arrays that are required in terms of performance must be defined in the pre-sales or solution design phase. However, when sizing the environment keep in mind that adding too many arrays to a single storage pool increases the failure domain, and therefore it is important to find the trade-off between the performance, availability, and scalability cost of the solution. 

The following actions are the starting preferred practices when planning storage pools for performance: 

GLYPH<SM590000> Create a dedicated storage pool with dedicated resources if there is a specific performance application request. 

GLYPH<SM590000> In a IBM FlashSystem 9100 clustered environment, create storage pools with IOgrp or Control Enclosure affinity. That means you have to use only arrays/MDisks supplied by the internal storage that is directly connected to one IOgrp SAS chain only. This configuration avoids unnecessary IOgrp-to-IOgrp communication traversing the SAN and consuming Fibre Channel bandwidth. 

GLYPH<SM590000> Use dedicated pools for image mode volumes. 

Limitation:  Image Mode volumes are not supported with Data Reduction Pools. 

GLYPH<SM590000> Try to limit the number of storage pools to avoid excessive cache partitioning. 

GLYPH<SM590000> For those Easy Tier enabled storage pools, always allow some free capacity for Easy Tier to deliver better performance. 

GLYPH<SM590000> Consider implementing child pools when you need to have a logical division of your volumes for each application set. There are often cases where you want to subdivide a storage pool but maintain a larger number of MDisks in that pool. Child pools are logically similar to storage pools, but allow you to specify one or more subdivided child pools. Thresholds and throttles can be set independently per child pool. 

## 4.3.3 Extent size considerations 

Limitation:  Child pools (VVols) are not supported with Data Reduction Pools 

When adding MDisks to a pool they are logically divided into chunks of equal size. These chunks are called extents  and are indexed internally. Extent sizes can be 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, or 8192 MB. The IBM Spectrum Virtualize architecture can manages 2^22 extents for a system and therefore the choice of extent size affects the total amount of storage that can be addressed. Check the link for the capacity limits per extent size. 

When planning for the extent size of a pool, remember that you cannot change the extent size later, it must remain constant throughout the lifetime of the pool. 

For the pool extent size planning, consider the following recommendations: 

GLYPH<SM590000> For standard pools usually 1 GB is suitable 

GLYPH<SM590000> For Data Reduction Pools use 4 GB (see 4.7, “Data Reduction Pools Best Practices” on page 93 for further considerations on extent size for DRP) 

GLYPH<SM590000> With Easy Tier enabled hybrid pools, consider smaller extent sizes to better utilize the higher tier resources and therefore provide better performance. 

GLYPH<SM590000> Keep the same extent size for all pools if possible. The extent based migration function is not supported between pools with different extent sizes. However, you can use volume mirroring to create copies between storage pools with different extent sizes. 

