SQL Server 最佳实践建议为数据和日志文件使用单独的驱动器。如果两个逻辑驱动器都位于同一个 EVA 上，速度真的会提高吗？
答案1
啊——这正是我的专业领域！
SQL“最佳实践”假设您使用单独的物理磁盘来存储数据和日志，但这是在一个本地连接物理磁盘的服务器中，或者通过传统的 SAN 方法，其中 LUN 只是单个 SAN 磁盘的一部分。EVA 与此截然不同。
根据您拥有的型号，任何给定的 LUN 将分布在至少八个物理磁盘上，如果是 P6xxx，则一开始可能为 12 个或更多。因此，如果您将日志分布在一组八个或更多磁盘上，并将数据分布在另外八个或更多磁盘上，那么您显然会看到比将相同数据仅分布在两个磁盘上时更好的性能。鉴于这是性能最低的配置，并且由于分布范围更广，您实际上可能会看到更好的性能，我想您会同意这种“最佳实践”在 EVA 上是不切实际的。
基本上，只需从最大的磁盘组中分割它们（您确实希望单个 DG 中的所有磁盘类型/速度相同），然后让 EVA 担心其余部分。我在多个 EVA/P6xxx/3Par 盒上运行许多 MSSQL 群集，现在真的没有必要像我们在 2000 年代使用较旧的 SAN 阵列那样在 LUN 组成方面过于具体。
答案2
有可能，是的...每个块设备排队是一个可能从分离中受益的独特领域，即使是转到同一物理磁盘组。
答案3
完全同意 Chopper3 的观点。你为老式 JBOD 所做的 DB 文件/日志的磁盘分离理论早已不复存在。
您所需要的只是一个具有大型磁盘组（大量主轴）的 EVA。
此外，如果您实际观察 SQL Server 或 Oracle 在硬件层面上的表现，就会发现数据库文件上的磁盘 I/O 量可以通过拥有足够的 RAM 而大大减少。日志，是的，它们仍然按顺序写入；只需确保您已将日志滚动阈值设置为与您的事务速率相匹配即可。
我们在 VMware 上运行了一些中等规模（300GB）的 Oracle 实例，这些实例在 EVA 上运行。这增加了另一层抽象；即：
O/S 卷 (NTFS) -> VMware VMDK 文件 -> VMware 数据存储区 (VMFS 文件系统) -> EVA vDisk (LUN) 及其关联的 vRAID 级别 -> EVA 磁盘组 -> 物理 FC/AL 驱动器
因此，如果您要求计算机科学家找到包含数据库块的磁盘块，以便应用一些优化建议，他或她只会耸耸肩。
答案4
通常，在具有特定卷的特定 RAID 的旧存储上，他们建议将日志和数据保存在不同的 RAID 上。如今，大多数存储都安装了跨大型磁盘组的所有 IO 的池。在大型池中，无需避免将任何数据库的日志和数据放在同一个磁盘上，但我仍然建议将它们保存在不同的卷上，原因由 ewwhite 在他的回答中提到（队列争用）。