SQL Server 2005 磁盘配置:单个 RAID 1+0 还是多个 RAID 1+0?

SQL Server 2005 磁盘配置:单个 RAID 1+0 还是多个 RAID 1+0?

假设 SQL Server 的工作负载只是一个普通的 OLTP 数据库,并且总共有 20 个可用磁盘,哪种配置更合理?

单个 RAID 1+0,包含全部 20 个磁盘。此物理卷将包含数据文件和事务日志文件,但此 RAID 将创建两个逻辑驱动器:一个用于数据文件,一个用于日志文件。

或者...

两个 RAID 1+0,每个包含 10 个磁盘。一个物理卷包含数据文件,另一个物理卷包含日志文件。

提出这个问题的原因是因为我(SQL开发人员)与同事(DBA)之间存在分歧。

对于我做过的或见过其他人做过的每个配置,数据文件和事务日志文件在物理层面上都是分开的,并放在单独的 RAID 上。

然而,我同事的观点是,通过将所有磁盘放入单个 RAID 1 + 0,那么服务器执行的任何 IO 都可能由所有 20 个磁盘共享,而不是像我建议的配置中那样仅仅由 10 个磁盘共享。

从概念上来说,他的论点对我来说是有道理的。此外,我还从微软找到了一些似乎支持他的观点的信息。

http://technet.microsoft.com/en-us/library/cc966414.aspx

在标题为“3. RAID10 配置”的部分中,展示了将所有 20 个磁盘分配给单个 RAID 1+0 的配置,其中指出:

在此场景中,所有分区都可以充分利用 I/O 并行性。因此,在分区级别,I/O 工作负载分布在 20 个物理主轴上,而不是 4 个。

但是... 我见过的所有其他配置都建议将数据和日志文件物理地分离到单独的 RAID 上。我在 Server Fault 上找到的所有内容都建议这样做。

我知道日志文件的写入操作很繁重,而数据文件则是读写操作的组合,但是这是否要求将文件放置在单独的 RAID 上而不是单个 RAID 上?

答案1

DBA 的论点确实有道理,但问题在于:如果我没有看错的话,MS 指的是数据库分区和表级别的性能,而不是磁盘/文件系统分区级别的性能。如果您谈论的只是为数据文件创建什么类型的阵列,我相信 DBA 会赢得这场辩论。由于您谈论的是为数据和日志文件创建什么类型的阵列,我认为从磁盘/文件系统性能的角度来看,您的论点最有道理。数据库文件始终是随机访问的,而日志文件始终是顺序访问的。您永远不应该在同一个物理或逻辑驱动器上混合这两种类型的 I/O。此外,在同一个物理磁盘(或磁盘阵列)上创建多个逻辑分区对您没有任何好处,因为数据库和日志将争夺相同的物理资源。

我的建议是这样的:

为数据库文件创建一个物理阵列 (RAID10),并为日志文件创建一个单独的物理阵列 (RAID10)。

答案2

这取决于您在系统上施加的工作负载。如果您的工作负载很高,则需要将它们分开,因为数据文件将是一种非常随机的工作负载,而事务日志是一种非常连续的工作负载。将它们分开通常会获得更好的性能,因为您不希望日志的 IO 变慢或受到数据文件负载的影响。

答案3

不想讽刺,但 DBA 就是.. DBA。

在构建不需要进行大量表扫描的复杂查询时,他们比服务器管理员聪明得多,但硬件/服务器管理员在分配适当的资源方面也同样聪明得多(假设他有一根或四根白发)。:)

我的简短回答是:这全都与主轴有关,这全都与主轴有关,并且从过去几年来看,您选择的文件系统以及该文件系统可以占用多少内存。

我在将数据库数据/日志/事务分离到(a)不同的物理控制器、(b)使用调整后的文件系统参数(具体来说,这是一个很大的参数,将数据库写入/读取/提交的参数与构建文件系统的相同大小的扇区/块相匹配)和(c)“选择我的毒药”方面取得了巨大的成功。

非关键数据、日志、回滚数据库等或多或少可以放在“易受攻击的”文件系统(memfs、没有日志/预检/预提交缓存的 fast-io-fs)上,而实际数据文件(取决于数据库的类型)可以很好地分布在像构造良好的 zpool 这样便宜的东西上。

前面的发帖人说得完全正确,trans 日志是连续的,可以/应该放在为快速写入而不是读取(可能不一定是“稳定性”)而制作的卷上,例如大条带。响应者(“问题就在这里”)也是对的:如果数据不在 RAM 或磁盘缓存中,磁盘争用会很严重,如果没有认真(发音为“漫长、单调、乏味且容易猜测错误”)的分析,您绝对应该尽量避免将磁盘与功能不同的数据库混合使用。(例如,高 trans 读取和低 trans 大数据写入 - 任何缓存策略都完全是胡闹)。

我的“ISO Layer 8”建议是:找 DBA 并说,嘿,我不会告诉你你错了,作为回报,你也不会告诉我如何构建我的系统 :) 他们经常会遵循样板建议,而从长远来看,这些建议很少是最佳的。不是因为他们不知道自己在做什么——而是因为他们相信由 $vendor 推出的一份中庸文档,称其“旨在惹恼最少数量的客户/从而减少求助电话”。

如果您想直接给我发消息,请随意;但请记住——没有全局的理想配置。行数、预期扫描、键/索引的基数和效率、每秒查询数、每个间隔的完整表扫描等都与之有关。这是一场艰难的游戏。

让我想起了 WARGAMES……

你想玩游戏吗?

是的。我们来玩全球热核战争吧。

..

玩一场有趣的数据库架构游戏怎么样?

[ 全球热核战争战略本来会更容易一些.. ]

:)

答案4

事务日志通常只被写入,并且是按顺序写入的。如果您将日志保存在自己的一组磁盘上,这些磁盘几乎根本不会有任何寻道(更新文件系统元数据时除外),只需一次向前移动一个扇区即可。

如果将日志和数据混合在同一个 RAID 集上(即使它们位于不同的逻辑单元上),您将失去按顺序写入事务日志所带来的性能提升。

我猜想,如果您在每个事务中写入少量数据,那么将日志保存在自己的阵列上将提高性能。如果您拥有大量数据,以至于数据写入磁盘的时间与寻道时间相比相当长,那么最好有一个大型阵列。

相关内容