以下是我们当前的服务器配置。几周后，我将通过安装 5 个新磁盘（1 个热备用）并从备份中恢复所有虚拟机来模拟灾难恢复。
将 RAID 条带大小更改为 64KB 以外的值会有什么好处吗？RAID 控制器有 8KB、16KB、32KB、64KB、128KB、256KB、512KB、1MB 等选项。
如能根据以下规范提出任何建议，我们将不胜感激 - 谢谢。
Hardware:
Dell PowerEdge 2900 III
Dell PERC 6/i
Intel Xeon 2.5GHz (x2)
32GB RAM
Seagate ST32000645SS ES.2 2TB Near-Line SAS 7.2K (x4)
Software:
Citrix XenServer 6.2 SP1
VM - Windows SBS 2008 x64 - Exchange & multiple SQL express instances
VM - Windows Server 2003 R2 x86 - single SQL express instance
VM - CentOS 6.6 x64 (x2) - cPanel & video transcoding and streaming
VM - CentOS 6.3 x86 - Trixbox (VoIP)
VM - PHD Virtual Backup 6.5.3 (running Ubuntu 12.04.1 LTS)
Configuration:
RAID 10, 64k Stripe Size
答案1
我将尝试将我的意见总结成一个答案。基本思路是：
除非有充分的证据证明修改条带大小将有利于您的工作量，否则您不应该修改条带大小。
推理：
- 对于条纹，你必须选择一些条带大小和 64 KB 是制造商选择的默认值。由于制造商（本例中为 LSI，由戴尔更名）在运行大量具有不同 RAID 级别和工作负载的设置方面拥有丰富的经验，因此您可以相信他们做出了明智的选择
- 64 KB 可能大致与虚拟化环境中的请求平均大小相匹配（至少比 256KB 或 1 MB 要大得多），因此可以在延迟和寻道时间优化之间取得良好的平衡1。
- 由于工作负载的高度可变性以及考虑到不同层的不同预读和缓存算法的模型的复杂性，几乎不可能对具有不同条带大小的应用程序性能进行准确的模型驱动预测
如果您想要获得这些证据，您可以通过运行典型负载和一些具有不同条带大小配置的非典型负载场景来获取这些证据，收集数据（Xen Server 层的 I/O 子系统性能、后端服务器性能和应用程序层的响应时间）并对其进行统计评估。然而，这将非常耗时，并且除了以下情况之外不太可能产生任何突破性的结果“我可能最终会保留其默认值”，所以我认为这是浪费资源。
1如果假设单个磁盘的传输速率为 100MB/s，则很容易看出读取 1 KB 大约需要 0.01ms，因此 64 KB 的读取延迟为 0.64ms。考虑到随机 I/O 请求的平均“服务时间”通常在 5-10ms 范围内，读取延迟只是总等待时间的一小部分。另一方面，读取 512 KB 大约需要 5ms - 这对于“随机小读取”类型的工作负载很重要，会大大减少阵列在此特定情况下能够提供的 IOPS 数量，即 1.5 - 2 倍。具有并发随机大读取操作的场景将受益，因为较大的块读取将减少耗时的寻道，但您不太可能在虚拟化环境中看到这种情况。
答案2
RAID10 的一般经验法则是，较小的块大小可在更多情况下提供快速顺序传输，而较大的块可提供更高的 IOP和在选定场景中可实现更高的连续速度。
您预期的工作负载（虚拟机）都是发出中小型（< 256KB）伪随机请求。换句话说，您需要一个 RAID 条带配置，以最大限度地缩短响应时间并最大限度地提高伪随机 IOP。
虽然 64K 是一个安全的默认值，但我觉得对于您预期的工作负载来说有点小。例如，考虑虚拟机想要读取/写入 128KB 数据块的情况。根据控制器处理读取请求的方式，128KB 块将占用 2 个或 4 个磁盘，而该大小的写入请求将始终占用所有 4 个磁盘。同时，由于读取/写入块（128KB）的大小较小，I/O 性能将由寻道时间而不是顺序传输决定，因此您的实际传输速度将仅比单个磁盘所能提供的速度快一点。这意味着其他虚拟机几乎没有机会使用磁盘，但同时您的阵列为正在使用它的单个虚拟机提供了单磁盘般的性能。
对于虚拟机使用，我将使用 256K 或 512K 块大小配置阵列：这可确保小型（< 256KB）读取请求将由单个磁盘（2 个磁盘用于写入）处理，而其他磁盘则可供其他虚拟机使用。同时，大型顺序传输（> 256/512K）将非常快，因为它们将使用多个磁盘。