DB2和磁盘存储虚拟化如此重要的原因

从传统上讲，大型机的存储配置流程一直缓慢而又复杂。除了采购和硬件安装外，该流程还包含大量针对输入/输出定义文件 (IODF)、SMS 存储组和自动类选择 (ACS) 例程的主机活动。IBM 创建了 zDAC 来帮助系统程序员匹配 IODF 与存储控制器，但这只是配置流程的一

从传统上讲，大型机的存储配置流程一直缓慢而又复杂。除了采购和硬件安装外，该流程还包含大量针对输入/输出定义文件 (IODF)、SMS 存储组和自动类选择 (ACS) 例程的主机活动。IBM 创建了 zDAC 来帮助系统程序员匹配 IODF 与存储控制器，但这只是配置流程的一个方面。当采用 DB2 基于时间点的系统恢复技术的时候，或者利用 Symmetrix Remote Data Facility (SRDF) 和对等远程拷贝 (PPRC) 来实现基于阵列的长距离复制的时候，有一些注意事项。可以将整个过程都融入变更控制中，这种做法虽然是必要的，但可能既枯燥又费时。

这种痛苦而又漫长的过程不可避免地会导致最终用户频繁地要求获取超过当时所需空间的存储空间，以便减少空间不足所带来的困扰。有时候，此种额外空间并未得到使用，或者更糟糕，已经分配但从未使用，这是一种隐式浪费。例如，如果使用 8 GB PRIQTY 创建 DB2 线性，即使 DB2 仅写入一小部分所分配的数据集，而所有正常的容量规划和评估工具仍然认定该空间已被利用。

完全配置完存储空间之后，仍有一些挑战可能会导致应用程序性能不良。某些光纤通道驱动器容量可能高达 600 GB。试想一下，有多少 MOD-9 才能构建一个 600 GB 的光纤通道驱动器。

存储管理

存储管理员必须思考下列一些问题：
&＃61623; 如何管理控制器中的大型磁盘？
&＃61623; 满足应用程序 SLA 的最佳方式是什么？
&＃61623; 如何区分重要的生产应用程序，例如测试应用程序和 QA 应用程序？
&＃61623; 性能需求（IOPS 或 MB/秒）是什么？
&＃61623; 可用性需求（RAID 保护和远程复制）是什么？

促使这项活动更加复杂的关键因素之一是：光纤通道驱动器的 IOPS 密度最近有所降低。旋转磁盘容量大大提升，但速度却未显著加快，因此 IOPS 提供的速度与数年前大致相同。图 1 就这一趋势进行了说明。

图 1. 随着旋转磁盘容量逐渐变大，每 GB 的 I/O 能力以惊人的速度大幅下降。

IOPS 密度的计算方法：驱动器 I/O 能力（每秒 I/O）除以驱动器大小（单位：GB）。从图 1 中可以明显看出，四个 146 GB 的光纤通道驱动器实现的 I/O 可达一个 600 GB 光纤通道驱动器的四倍。然而，问题在于，随着高密度替代品的面世，146 GB（或者更小的）驱动器将会很快绝迹。过去的 15 年一直在延续这种趋势，低容量磁盘逐渐被高容量磁盘所代替，迫使您对这些超大型传动装置部署 DB2 系统，这放大了共享相同物理驱动器的工作负载之间的争用现象。

图 1 显示，当前的 600 GB 光纤通道驱动器的性能为 0.25 IOPS/GB，远低于图表第一栏呈现的慢速 9 GB 驱动器。这种 IOPS 密度降低是一种不太好的趋势，如果应用程序能够实现自身的 SLA，就能阻止这一趋势再继续。但这需要进行一场量子变革。

固态硬盘打破了 IOPS 密度的螺旋下降趋势

这场量子变革以固态硬盘 (SSD) 的方式存在已久。200 GB SSD 可以实现的 IOPS 密度约为 25 IOPS/GB，是 600 GB 旋转硬盘的 100 倍。

虽然依然十分昂贵，但是，因为众多供应商之间的竞争以及企业就绪 MLC 驱动器的推出，SSD 的价格开始持续下降。随着 IOPS 密度的逐渐下降，人们很难想象，如果未来没有这些 SSD 应该如何部署企业级阵列。然后，惟一的挑战在于如何对它们进行有效利用。

我们很难按照 z/OS 的方式将卷映射至实际的后端存储阵列实例；也就是说，在 z/OS 中显示为两个独立物理卷的内容实际上可能呈现在同一物理磁盘上。任何企图通过区分表及其索引来提升性能的尝试，都可能会在不知不觉中将它们置于同一磁盘上，因此会导致争用现象。现今的阵列中并未提供解决这一问题的简便解决方案。