It is not just the pure cache size which accounts for good performance figures. Economical use of cache, like 4 KB cache segments and smart, adaptive caching algorithms, are just as important to guarantee outstanding performance. This is implemented in the DS8000 series.

Processor memory or cache can grow to up to 256 GB in the DS8300 and to 128 GB for the DS8100. This processor memory is subdivided into a data in cache portion, which holds data in volatile memory, and a persistent part of the memory, which functions as NVS to hold DASD fast write (DFW) data until de-staged to disk.

Cache, or processor memory as a DS8000 term, is important to z/OS-based I/Os. Besides the potential for sharing data on a DS8000 processor memory level, it is the main contributor to good I/O performance. When coming from an existing disk storage server environment and you intend to consolidate this environment into DS8000s, follow these recommendations:

￿Choose a cache size for the DS8000 series which has a similar ratio between cache size and disk storage to that of the currently used configuration.

￿When you consolidate multiple disk storage servers, configure the sum of all cache from the source disk storage servers for the target DS8000 processor memory or cache size.

For example, consider replacing four ESS F20s with 3.2 TB and 16 GB cache each with a DS8100. The ratio between cache size and disk storage for the ESS F20 is 0.5% with 16 GB/3.2 TB. The new DS8100 is configured with 18 TB to consolidate 4 x 3.2 TB plus some extra capacity for growth. This would require 90 GB of cache to keep the original cache-to-disk storage ratio. Round up to the next available memory size, which is 128 GB for this DS8100 configuration.

This ratio of 0.5% cache to backstore is considered high performance for z/OS environments. Standard performance suggests a ratio of 0.2% cache to backstore ratio.

S/390 or zSeries channel consolidation

The number of channels plays a role as well when sizing DS8000 configurations and when we know from where we are coming. The total number of channels used where you are coming from has to be considered in the following way:

￿Use the same number of ESCON channels when the DS8000 has to be ESCON-connected as well. Since the maximum number of ESCON channel ports in a DS8100 is 32, and 64 for a DS8300, this also determines the consolidation factor. Note that with ESCON channels only, the potential of the DS8000 series cannot be fully exploited. You might consider taking this opportunity to change from ESCON to FICON to improve performance and throughput by multiple magnitudes compared to an ESCON world.

￿When the connected host uses FICON channels with 1 Gbps technology and it will stay at this speed as determined by the host or switch ports, then keep the same number of FICON ports. So four ESS 800s with eight FICON channels each connected to IBM 9672 G5 or G6 servers might end up in a single DS8300 with 32 FICON channels.

￿When migrating not only to DS8000 models, but also from 1 Gbps FICON to FICON Express channels at 2 Gbps, you can consider consolidating the number of channels to about 2/3 of the original number of channels. Use at least four FICON channels per DS8000. (By the way, when we write about FICON channels, we mean FICON ports in the disk storage servers.)

￿Coming from FICON Express channels, you should keep a minimum of four FICON ports. You might consider using 25% fewer FICON ports in the DS8000 than the aggregated number of FICON 2 Gbps ports from the source environment. For example, when you consolidate two ESS 800s with eight FICON 2 Gbps ports each to a DS8100, plan for a minimum of 12 FICON ports on the DS8100.

272DS8000 Series: Concepts and Architecture

Page 294
Image 294
IBM DS8000 manual Or zSeries channel consolidation