What is the general guidance for choosing suitable storage for a Db2 pureScale workload?
Two aspects of performance are considered in storage for Db2® pureScale®: recovery performance and runtime performance. Recovery performance is minimizing the time to recover from a software or hardware failure, while runtime performance is maximizing transaction rates.
For recovery performance, storage where Spectrum Scale supports Fast IO Fencing is considered first. See What type of file system or storage is supported? for more details.
For runtime performance, Db2 pureScale storage requirements are typically measured by using input/output operations per second (IOPS) and the time for the I/O request to complete (also known as latency). Different workload characteristics (read/write ratio) generally dictates the requirements of the mentioned metrics, which provide the guidance of the storage type choices. For most users, the most performance critical storage is for the transaction log file system.
Guidance for transaction log storage
For latency, submillisecond is the goal for transaction log writes. Since Db2 pureScale requires a SAN storage controller, which adds to the overall latency, low to mid hundreds of microseconds is deemed an acceptable range for moderate to high workload demands (based on in-house performance tests).
- IOPS is 5,000 - 25,000 or higher (the higher the better for demanding workload)
- Latency is submillisecond for transaction log writes (the lower the better)
Guidance for database container storage
For some users who have larger databases (for example, databases with hundreds of terabytes or higher), more care is needed in choosing the storage where the database containers are stored. Larger databases require more reads from physical disk, as the available system memory that is used for buffer pools cannot hold all the active data at once. A similar consideration applies to database workloads: if the workload needs to read 10,000 4k pages from the table space containers per second, the SAN storage must be able to maintain this IOPS rate. SAN storage with low-latency is beneficial in reducing the time that it takes to read the pages and can reduce contention in other parts of the database, such as page and lock contention. As with the transaction log SAN, submillisecond latency is highly recommended.