IBM manual Workload characteristics, Data placement in the DS8000, 265

12.4.1 Workload characteristics

The answers to questions like how many host connections do I need?, how much cache do I need? and the like always depend on the workload requirements (such as, how many I/Os per second per server, I/Os per second per gigabyte of storage, and so forth).

The information you need, ideally, to conduct detailed modeling includes:

￿Number of I/Os per second

￿I/O density

￿Megabytes per second

￿Relative percentage of reads and writes

￿Random or sequential access characteristics

￿Cache hit ratio

12.4.2Cache size considerations for open systems

Cache sizes in the DS8000 can be either 16, 32, 64, 128, or 256 GB. The 16 GB of system memory is only available on the DS8100 and the 256 GB of system memory is only available on the DS8300.

The factors that have to be considered to determine the proper cache size are:

￿The total amount of disk capacity that the DS8000 will hold

￿The characteristic access density (I/Os per GB) for the stored data

￿The characteristics of the I/O workload (cache friendly, unfriendly, standard; block size; random or sequential; read/write ratio; I/O rate)

If you do not have detailed information regarding the access density and the I/O operations characteristics, but you only know the usable capacity, you can estimate between 2 GB and 4 GB for the size of the cache per 1 TB of storage, as a general rule of thumb.

12.4.3 Data placement in the DS8000

Once you have determined the disk subsystem throughput, the disk space and number of disks required by your different hosts and applications, you have to make a decision regarding the data placement.

As is common for data placement and to optimize the DS8000 resources utilization, you should:

￿Equally spread the LUNs across the DS8000 servers.

Spreading the LUNs equally on rank group 0 and 1 will balance the load across the DS8000 servers.

￿Use as many disks as possible.

￿Distribute across DA pairs and RIO-G loops.

￿Stripe your logical volume across several ranks.

￿Consider placing specific database objects (such as logs) on different ranks.

Chapter 12. Performance considerations 265