XenServer的RAID 10条带大小

我将尝试将我的意见总结为一个答案。 基本路线是：

除非你有充分的证据certificate它会有利于你的工作量，否则你不应该去掉钢带的大小。

推理：

• 对于条纹，您必须select一些条带大小，64 KB是制造商select的默认值。 由于制造商（在这种情况下，由戴尔重新命名的LSI）确实有大量运行大量不同RAID级别和工作负载的设置的经验，你可以相信他们已经明智地select了
• 64 KB可能与虚拟环境中的请求的平均大小大致相当（至less比256KB或1 MB大得多），因此是延迟和寻道时间优化之间的良好折衷¹ 。
• 由于工作负载的高度变化的性质以及考虑到不同层的不同预读和cachingalgorithm的模型的复杂性，关于应用性能随着带宽变化的准确模型驱动的预测几乎是不可能的

如果您需要获得这些证据，可以通过运行典型负载和一些带有不同带宽configuration的非典型负载情况来收集数据（Xen Server层的I / O子系统性能，后端服务器性能并在应用层回答时间），并通过统计评估运行。 然而，这将是非常耗时的，除了“我可能只是把它留在最终的默认值”之外，不可能产生任何突破性的结果，所以我认为这是浪费资源。

¹如果假设单个磁盘的传输速率为100MB / s，则很容易看出Kilobyte读取的时间大约为0.01ms，因此64 KB的读取延迟为0.64ms。 考虑到随机I / O请求的平均“服务时间”通常在5-10ms的范围内，读取延迟只是总等待时间的一小部分。 另一方面，512KB的读取时间大约需要5ms，这对于“随机小读”types的工作负载很重要，大大减less了arrays在这种特定情况下能够提供的IOPS数量， 2.并发随机大型读取操作的场景将会受益，因为较大的块读取会导致耗时较less的查找，但在虚拟环境中很难看到这种情况。

使用RAID10的一般经验法则是较小的块大小可以让您在更广泛的情况下快速顺序传输，而较大的块在所选场景中提供更高的IOP 和更高的连续速度。

您期望的工作负载（虚拟机）都是发布中小型（<256KB），伪随机请求。 换句话说，您需要一个RAID条带configuration，以最大限度地减less响应时间并最大限度地提高伪随机IOP。

虽然64K是一个安全的默认值，我觉得它对你的预期工作量有点小。 例如，考虑虚拟机想要读/写128KB数据块的情况。 根据您的控制器如何处理读取请求，一个128KB的块将使用2或4个磁盘，而这种大小的写入请求将始终使用所有4个磁盘。 同时，由于读/写块（128KB）的小尺寸，I / O性能将由寻道时间而不是顺序传输来支配，所以你的实际传输速度只会比单个磁盘快一点可以提供。 这意味着其他虚拟机几乎没有机会使用这些磁盘，但与此同时，您的arrays为单个虚拟机提供单磁盘性能，而单个虚拟机正在使用它。

对于虚拟机的使用，我将configuration256K或512K块大小的arrays：这保证了小的（<256KB）读取请求将由单个磁盘提供（2个磁盘用于写入），而另一个可用于其他虚拟机。 同时，大的顺序传输（> 256 / 512K）将非常快，因为它们将涉及多个磁盘。