DS6000 and DS8000 Performance Management
With the current DS6000/DS8000 microcode, there are typically no performance implications when using single-rank extent pools as compared to multi-rank extent pools. However, single-rank extent pools can help make it easier to control LUN assignment to ranks to allow balanced spreading of volumes for a workload across multiple ranks. Single-rank extent pools can also simplify performance analysis and management.
Selecting an appropriate data-layout strategy depends on your primary objectives. Spreading workloads across all components maximizes the utilization of the hardware components. This includes spreading workloads across all of the available host adapters and ranks. However, when sharing resources, it's always possible for performance problems to arise due to contention on these resources.
Isolating critical workloads minimizes the chance of non-critical workloads impacting the performance of critical workloads.
The greater the granularity of the resource, the more it can be shared. For example, there's only one cache per processor complex so its use must be shared, although the DS6000 and DS8000 intelligent-cache management prevents one workload from dominating the cache. In contrast, there are frequently hundreds of distributed data management (DDMs), so workloads can easily be isolated on different DDMs.
To spread a workload across ranks you need to balance I/Os for any workload across all of the available ranks. Because i5/OS* automatically spreads data across all available LUNs, it's not necessary in a System i environment to use a logical volume manager to further stripe data across LUNs.
Isolation of workloads is most easily accomplished when each rank is isolated in its own extent pool. This ensures that you can place data where you intend to. I/O activity should be balanced between the two servers or controllers on the DS6000/DS8000. This is achieved by balancing between odd and even extent pools and ensuring that the number of ranks is balanced between odd and even extent pools.
You should consider isolating any critical, performance sensitive workloads. For performance-management reasons, IBM strongly recommends to only place System i LUNs on any rank (rather than mixing) - this won't provide improved performance. If you mix production and development workloads on ranks, make sure the customer understands which actions may impact production performance (e.g., adding LUNs to ASPs).
comments powered by