CPU_BUSY Asked: 2009-05-01 05:33:54 +0800 CST2009-05-01 05:33:54 +0800 CST 2009-05-01 05:33:54 +0800 CST ISCSI SAN 上的 SQL Server 磁盘设计 772 将日志和数据文件分开以将磁盘与操作系统分开的标准做法（tempdb、备份和交换文件也是）当您的驱动器都是基于 SAN 并且您的 LUN 不是由特定磁盘或 RAID 集雕刻时，这种逻辑是否仍然有意义- 它们只是 SAN 上 x 个驱动器的一部分，而 LUN 只是空间分配 sql-server storage-area-network iscsi lun dell-equallogic 7 个回答 Voted Best Answer ConcernedOfTunbridgeWells 2009-05-16T00:57:30+08:002009-05-16T00:57:30+08:00 日志和数据驱动器具有不同的数据访问模式，它们在共享驱动器时会相互冲突（至少在理论上）。 日志写入 日志访问由大量的小顺序写入组成。稍微简单地说，DB 日志是环形缓冲区，其中包含将数据项写入磁盘上特定位置的指令列表。访问模式由必须保证完成的大量小型顺序写入组成 - 因此它们被写入磁盘。 理想情况下，日志应该位于安静的（即不与其他任何东西共享）RAID-1 或 RAID-10 卷上。从逻辑上讲，您可以将进程视为主要 DBMS 写入日志条目和一个或多个日志读取器线程，这些线程消耗日志并将更改写入数据磁盘（实际上，该过程被优化以便写入数据写入在可能的情况下立即退出）。如果日志磁盘上有其他流量，则这些其他访问会移动磁头，并且顺序日志写入变为随机日志写入。这些速度要慢得多，因此繁忙的日志磁盘会创建一个热点，成为整个系统的瓶颈。 数据写入 （更新）必须将日志写入提交到磁盘（称为稳定介质），才能使事务有效并有资格提交。从逻辑上讲，可以将其视为正在写入的日志条目，然后将其用作通过异步进程将数据页写入磁盘的指令。实际上，磁盘页面写入实际上是在创建日志条目时准备和缓冲的，但它们不需要立即写入以提交事务。磁盘缓冲区由 Lazy Writer 进程写入稳定媒体（磁盘）（感谢 Paul Randal 指出这一点），这篇 Technet 文章更详细地讨论了这一点。 这是一种高度随机的访问模式，因此与日志共享相同的物理磁盘可能会对系统性能造成人为的瓶颈。必须写入日志条目才能提交事务，因此随机搜索会减慢此过程（随机 I/O比顺序日志 I/O 慢得多）会将日志从顺序变为随机访问设备。这会在繁忙的系统上造成严重的性能瓶颈，应该避免。与日志卷共享临时区域时也是如此。 缓存的作用 SAN 控制器往往具有较大的 RAM 缓存，可以在一定程度上吸收随机访问流量。但是，为了事务完整性，最好保证从 DBMS 完成磁盘写入。当控制器设置为使用回写缓存时，脏块被缓存并且 I/O 调用向主机报告为完成。 这可以解决很多争用问题，因为缓存可以吸收大量 I/O，否则这些 I/O 会传输到物理磁盘。它还可以优化 RAID-5 的奇偶校验读取和写入，从而减少 RAID-5 卷对性能的影响。 这些是推动“让 SAN 处理它”思想流派的特征，尽管这种观点有一些局限性： 回写式缓存仍然存在可能丢失数据的故障模式，并且控制器已向 DBMS 发送错误消息，称块已被写入磁盘，而实际上并未写入。出于这个原因，您可能不想为事务应用程序使用回写缓存，特别是保存关键任务或财务数据的应用程序，其中数据完整性问题可能对业务产生严重后果。 SQL Server（特别是）在一种模式下使用 I/O，其中一个标志（称为 FUA 或强制更新访问）在调用返回之前强制对磁盘进行物理写入。Microsoft 有一个认证计划，许多 SAN 供应商生产的硬件都符合这些语义（此处总结的要求）。在这种情况下，再多的缓存都不会优化磁盘写入，这意味着如果日志流量位于繁忙的共享卷上，它就会颠簸。 如果应用程序产生大量磁盘流量，其工作集可能会超出缓存，这也会导致写入争用问题。 如果 SAN 与其他应用程序共享（特别是在同一磁盘卷上），来自其他应用程序的流量可能会产生日志瓶颈。 一些应用程序（例如数据仓库）会产生大的瞬时负载峰值，这使得它们在 SAN 上非常反社会。 即使在大型 SAN 上，单独的日志卷仍然是推荐的做法。您可能无需担心轻量级应用程序的布局。在非常大的应用程序中，您甚至可以从多个 SAN 控制器中受益。Oracle 发布了一系列数据仓库布局案例研究，其中一些较大的配置涉及多个控制器。 将绩效责任放在应有的地方 在大容量或性能可能成为问题的情况下，让 SAN 团队对应用程序的性能负责。如果他们将忽略您的配置建议，请确保管理层意识到这一点，并且系统性能的责任在于适当的位置。特别是，为关键数据库性能统计信息（如 I/O 等待或页面锁存等待）或可接受的应用程序 I/O SLA 建立可接受的准则。 请注意，将绩效责任分配给多个团队会鼓励相互指责并将责任推卸给其他团队。这是一种已知的管理反模式，也是一种解决问题的公式，这些问题拖延了数月或数年而从未得到解决。理想情况下，应该有一个架构师有权指定应用程序、数据库和 SAN 配置更改。 此外，在负载下对系统进行基准测试。如果可以安排，二手服务器和直连阵列可以在 Ebay 上以相当便宜的价格购买。如果你用一个或两个磁盘阵列设置一个这样的盒子，你可以使用物理磁盘配置来衡量对性能的影响。 例如，我对运行在大型 SAN（IBM Shark）上的应用程序和带有直接连接 U320 阵列的双插槽盒进行了比较。在这种情况下，在 CPU 和内存配置大致相同的主机上，从 ebay 购买的价值 3,000 英镑的硬件比 100 万英镑的高端 SAN 性能高出两倍。 从这个特定的事件来看，有人可能会说，有这样的东西是让 SAN 管理员保持诚实的好方法。 Helvick 2009-06-19T08:38:48+08:002009-06-19T08:38:48+08:00 我假设 Equallogic 标签和请求的内容意味着您正在谈论 Equallogic SAN。以下内容专门针对 Equallogic，不适用于其他 SAN 类型。 使用 Equallogic 阵列时，无法像使用 EMC Clariion 阵列那样精确地指定用于卷的特定磁盘，因此方法必须有所不同。 Equallogic 架构是非常自动化和动态的。它的基本构建块是阵列单元，而不是阵列中的 RAID 包\组，如在其他 SAN 中所见。每个阵列都完全配置为 RAID 5、6、10 或 50，尽管这并不意味着每个阵列只有一个 RAID 组，您只是永远无法在该级别决定或与它们交互。您将阵列放入存储池，然后您的池属于一个存储组。存储组有一个集群\虚拟 IP 地址，您将其用作该组内所有卷的 iSCSI 发现目标 - EQL 组管理软件和主机 MPIO 堆栈处理实际路由到最合适的端口所需的 ip 级别重定向请求数据块时的各个数组，但这是您几乎无法控制的事情。 存储卷是从每个池中的总可用空间分配的。池中的所有卷都分布在该池中的所有阵列（最多 4 个单独的阵列）中，以便在网络接口总数（每个 Eql 阵列 2-4 个，具体取决于型号）和 IO 之间分配网络 IO跨越尽可能多的控制器。Equallogic 管理软件随着时间的推移监控卷\阵列性能，并动态优化块在成员阵列中的分布。一般来说，除非您知道自己在做什么，否则您应该将所有阵列放在一个池中并让它做它的事情，只要记住确保您使用 RAID 10 配置高速磁盘（SAS 10k\15k），使用 RAID 50 配置中等速度或 5 以确保优化过程实际选择真正的高性能驱动器。 根据驱动器类型和 RAID 类型，粗略估计，每个 PS 阵列的 IOP 将介于 2500-5000 之间。如果您提供了足够的总 IOP，那么即使您只是将所有卷集中到一个池中，自动化管理过程最终也会为您提供良好的性能。 但是，如果您想保证您的日志、数据库、临时存储、操作系统驱动器等实际上彼此隔离，您可以做几件事。首先，您可以为卷定义 RAID 首选项，这将保证特定卷始终仅存储在该 RAID 类型的阵列上（如果它们存在于该卷所属的池中）。其次，您可以定义仅包含阵列的分层存储池，这些阵列可提供该特定层所需的各种性能等级，然后将您的卷分配到适当的池中。这种方法带来的健康警告是，您通常需要大量阵列才能真正提供更好的整体性能——这对您来说可能不如保证关键卷的性能重要，但它通常仍然是最好的选择。戴尔的 Oracle DB 参考架构使用一个具有 2 个 RAID 10 阵列的池用于数据、投票磁盘和 OCR，以及一个具有单个 RAID 5 阵列的单独池用于闪存恢复区。 在使用 Equallogic 的所有时间点，您都应该问自己，您在强制分区方面所做的决定是否会在可用网络接口、磁盘轴和控制器方面为您的卷提供更好的聚合性能。如果您无法回答这个问题，请选择最少数量的池并让其处理细节或让 Equallogic 专家进行真正的设计。如果您只有一个阵列，那么在分离卷方面您无能为力。 Chopper3 2009-05-16T02:33:58+08:002009-05-16T02:33:58+08:00 我们将数据库存储在单个 SAN 盒中，但具有单独的数据、日志和备份 LUN，每个都在不同的磁盘组上，按速度分层 - 我们的日志在 RAID 10 15Krpm LUN 上，数据在 RAID 1 10/15krpm LUN 上并备份到 RAID 5 个 7.2krpm LUN。我们还通过同一 SAN 上的不同控制器呈现日志和数据。 BradC 2009-05-01T05:45:01+08:002009-05-01T05:45:01+08:00 好问题！ 首先看一下 Brent Ozar 关于这个问题的“Steel Cage BlogMatch”辩论。 在我们公司，对于大多数服务器，我们将数据和日志放在同一个 SAN 驱动器上，并由 SAN 团队确保一切正常。 我开始认为这不是最好的策略，尤其是对于大容量服务器。根本的问题是，我真的无法验证 SAN 团队是否真的在做任何事情，而不仅仅是为我们需要的空间拼凑足够的驱动器。我们不会从我们这边或其他任何地方对 SAN 驱动器运行 IO 基准测试，我们只是假设它们正在“完成他们的工作”（针对性能和空间进行调整），这可能有点幼稚。 我的另一个想法是，数据与日志所需的访问类型是不同的。我将尝试找到我最近阅读的文章，该文章讨论了两种不同的驱动器类型应该如何以非常不同的方式进行优化（我认为一种需要针对顺序写入进行优化，另一种需要针对随机读取进行优化，诸如此类.) Peter Stuer 2009-05-31T02:47:43+08:002009-05-31T02:47:43+08:00 简而言之，是的，您将为 SQL Server 数据文件、日志文件以及 TempDB 数据和日志文件创建单独的卷。 由于您使用 Equallogic 标记了您的问题，请在设计解决方案之前通读免费的戴尔参考架构指南：使用戴尔™ EqualLogic™ PS5000 系列存储阵列部署 Microsoft® SQL Server® （需要注册）。通常，您会发现特定配置的指导与一般建议有很大不同。 Guy 2009-05-01T05:52:15+08:002009-05-01T05:52:15+08:00 在性能方面，我同意 BradC (+1)。一般来说，一个好的 SAN 会拥有比您预期使用的更多的原始 I/O。 将备份与实时系统分开仍然是一个好主意（很明显，我知道，但如果我每次看到这个都有 1 英镑......） 此外，建议将 tempdb 远离日志文件。当你开始想要日志、数据和温度的“不同存储桶”（技术术语）时，SAN 家伙的帐篷会向你翻白眼，但如果你告诉他们是这样，你就可以衡量进入每个区域的不同数据量 IO 和让他们向您展示他们精美的性能图表！ 只需仔细/仔细检查 SAN 人员是否已为您正确设置。如果你想要 RAID 10，那就坚持（我做过），即使他们一直说他们的 RAID 5 没有性能损失。 （对于“基于文件”的操作，RAID 5 很好。对于密集写入，一旦你填满了写入缓冲区，你就搞砸了！） pauska 2009-06-26T02:11:14+08:002009-06-26T02:11:14+08:00 请注意此处所有术语的混合。 一般来说，非常基本的： 阵列 = RAID 设置中的磁盘池（如 RAID5） 卷 = 阵列的一部分，通过 LUN 呈现给 SAN 上的主机 您可以在同一个阵列上拥有多个卷，这是在进行本线程中讨论的高级优化时要记住的事情。 关键是其他几个人提到的（不要忘记），在不同的驱动器主轴上分离数据/日志/备份，而不仅仅是单独的卷。 编辑：上面的 Helvick 给了你一个关于 Equallogic SAN 的很好的答案！
日志和数据驱动器具有不同的数据访问模式，它们在共享驱动器时会相互冲突（至少在理论上）。
日志写入
日志访问由大量的小顺序写入组成。稍微简单地说，DB 日志是环形缓冲区，其中包含将数据项写入磁盘上特定位置的指令列表。访问模式由必须保证完成的大量小型顺序写入组成 - 因此它们被写入磁盘。
理想情况下，日志应该位于安静的（即不与其他任何东西共享）RAID-1 或 RAID-10 卷上。从逻辑上讲，您可以将进程视为主要 DBMS 写入日志条目和一个或多个日志读取器线程，这些线程消耗日志并将更改写入数据磁盘（实际上，该过程被优化以便写入数据写入在可能的情况下立即退出）。如果日志磁盘上有其他流量，则这些其他访问会移动磁头，并且顺序日志写入变为随机日志写入。这些速度要慢得多，因此繁忙的日志磁盘会创建一个热点，成为整个系统的瓶颈。
数据写入
（更新）必须将日志写入提交到磁盘（称为稳定介质），才能使事务有效并有资格提交。从逻辑上讲，可以将其视为正在写入的日志条目，然后将其用作通过异步进程将数据页写入磁盘的指令。实际上，磁盘页面写入实际上是在创建日志条目时准备和缓冲的，但它们不需要立即写入以提交事务。磁盘缓冲区由 Lazy Writer 进程写入稳定媒体（磁盘）（感谢 Paul Randal 指出这一点），这篇 Technet 文章更详细地讨论了这一点。
这是一种高度随机的访问模式，因此与日志共享相同的物理磁盘可能会对系统性能造成人为的瓶颈。必须写入日志条目才能提交事务，因此随机搜索会减慢此过程（随机 I/O比顺序日志 I/O 慢得多）会将日志从顺序变为随机访问设备。这会在繁忙的系统上造成严重的性能瓶颈，应该避免。与日志卷共享临时区域时也是如此。
缓存的作用
SAN 控制器往往具有较大的 RAM 缓存，可以在一定程度上吸收随机访问流量。但是，为了事务完整性，最好保证从 DBMS 完成磁盘写入。当控制器设置为使用回写缓存时，脏块被缓存并且 I/O 调用向主机报告为完成。
这可以解决很多争用问题，因为缓存可以吸收大量 I/O，否则这些 I/O 会传输到物理磁盘。它还可以优化 RAID-5 的奇偶校验读取和写入，从而减少 RAID-5 卷对性能的影响。
这些是推动“让 SAN 处理它”思想流派的特征，尽管这种观点有一些局限性：
回写式缓存仍然存在可能丢失数据的故障模式，并且控制器已向 DBMS 发送错误消息，称块已被写入磁盘，而实际上并未写入。出于这个原因，您可能不想为事务应用程序使用回写缓存，特别是保存关键任务或财务数据的应用程序，其中数据完整性问题可能对业务产生严重后果。
SQL Server（特别是）在一种模式下使用 I/O，其中一个标志（称为 FUA 或强制更新访问）在调用返回之前强制对磁盘进行物理写入。Microsoft 有一个认证计划，许多 SAN 供应商生产的硬件都符合这些语义（此处总结的要求）。在这种情况下，再多的缓存都不会优化磁盘写入，这意味着如果日志流量位于繁忙的共享卷上，它就会颠簸。
如果应用程序产生大量磁盘流量，其工作集可能会超出缓存，这也会导致写入争用问题。
如果 SAN 与其他应用程序共享（特别是在同一磁盘卷上），来自其他应用程序的流量可能会产生日志瓶颈。
一些应用程序（例如数据仓库）会产生大的瞬时负载峰值，这使得它们在 SAN 上非常反社会。
即使在大型 SAN 上，单独的日志卷仍然是推荐的做法。您可能无需担心轻量级应用程序的布局。在非常大的应用程序中，您甚至可以从多个 SAN 控制器中受益。Oracle 发布了一系列数据仓库布局案例研究，其中一些较大的配置涉及多个控制器。
将绩效责任放在应有的地方
在大容量或性能可能成为问题的情况下，让 SAN 团队对应用程序的性能负责。如果他们将忽略您的配置建议，请确保管理层意识到这一点，并且系统性能的责任在于适当的位置。特别是，为关键数据库性能统计信息（如 I/O 等待或页面锁存等待）或可接受的应用程序 I/O SLA 建立可接受的准则。
请注意，将绩效责任分配给多个团队会鼓励相互指责并将责任推卸给其他团队。这是一种已知的管理反模式，也是一种解决问题的公式，这些问题拖延了数月或数年而从未得到解决。理想情况下，应该有一个架构师有权指定应用程序、数据库和 SAN 配置更改。
此外，在负载下对系统进行基准测试。如果可以安排，二手服务器和直连阵列可以在 Ebay 上以相当便宜的价格购买。如果你用一个或两个磁盘阵列设置一个这样的盒子，你可以使用物理磁盘配置来衡量对性能的影响。
例如，我对运行在大型 SAN（IBM Shark）上的应用程序和带有直接连接 U320 阵列的双插槽盒进行了比较。在这种情况下，在 CPU 和内存配置大致相同的主机上，从 ebay 购买的价值 3,000 英镑的硬件比 100 万英镑的高端 SAN 性能高出两倍。
从这个特定的事件来看，有人可能会说，有这样的东西是让 SAN 管理员保持诚实的好方法。
我假设 Equallogic 标签和请求的内容意味着您正在谈论 Equallogic SAN。以下内容专门针对 Equallogic，不适用于其他 SAN 类型。
使用 Equallogic 阵列时，无法像使用 EMC Clariion 阵列那样精确地指定用于卷的特定磁盘，因此方法必须有所不同。
Equallogic 架构是非常自动化和动态的。它的基本构建块是阵列单元，而不是阵列中的 RAID 包\组，如在其他 SAN 中所见。每个阵列都完全配置为 RAID 5、6、10 或 50，尽管这并不意味着每个阵列只有一个 RAID 组，您只是永远无法在该级别决定或与它们交互。您将阵列放入存储池，然后您的池属于一个存储组。存储组有一个集群\虚拟 IP 地址，您将其用作该组内所有卷的 iSCSI 发现目标 - EQL 组管理软件和主机 MPIO 堆栈处理实际路由到最合适的端口所需的 ip 级别重定向请求数据块时的各个数组，但这是您几乎无法控制的事情。
存储卷是从每个池中的总可用空间分配的。池中的所有卷都分布在该池中的所有阵列（最多 4 个单独的阵列）中，以便在网络接口总数（每个 Eql 阵列 2-4 个，具体取决于型号）和 IO 之间分配网络 IO跨越尽可能多的控制器。Equallogic 管理软件随着时间的推移监控卷\阵列性能，并动态优化块在成员阵列中的分布。一般来说，除非您知道自己在做什么，否则您应该将所有阵列放在一个池中并让它做它的事情，只要记住确保您使用 RAID 10 配置高速磁盘（SAS 10k\15k），使用 RAID 50 配置中等速度或 5 以确保优化过程实际选择真正的高性能驱动器。
根据驱动器类型和 RAID 类型，粗略估计，每个 PS 阵列的 IOP 将介于 2500-5000 之间。如果您提供了足够的总 IOP，那么即使您只是将所有卷集中到一个池中，自动化管理过程最终也会为您提供良好的性能。
但是，如果您想保证您的日志、数据库、临时存储、操作系统驱动器等实际上彼此隔离，您可以做几件事。首先，您可以为卷定义 RAID 首选项，这将保证特定卷始终仅存储在该 RAID 类型的阵列上（如果它们存在于该卷所属的池中）。其次，您可以定义仅包含阵列的分层存储池，这些阵列可提供该特定层所需的各种性能等级，然后将您的卷分配到适当的池中。这种方法带来的健康警告是，您通常需要大量阵列才能真正提供更好的整体性能——这对您来说可能不如保证关键卷的性能重要，但它通常仍然是最好的选择。戴尔的 Oracle DB 参考架构使用一个具有 2 个 RAID 10 阵列的池用于数据、投票磁盘和 OCR，以及一个具有单个 RAID 5 阵列的单独池用于闪存恢复区。
在使用 Equallogic 的所有时间点，您都应该问自己，您在强制分区方面所做的决定是否会在可用网络接口、磁盘轴和控制器方面为您的卷提供更好的聚合性能。如果您无法回答这个问题，请选择最少数量的池并让其处理细节或让 Equallogic 专家进行真正的设计。如果您只有一个阵列，那么在分离卷方面您无能为力。
我们将数据库存储在单个 SAN 盒中，但具有单独的数据、日志和备份 LUN，每个都在不同的磁盘组上，按速度分层 - 我们的日志在 RAID 10 15Krpm LUN 上，数据在 RAID 1 10/15krpm LUN 上并备份到 RAID 5 个 7.2krpm LUN。我们还通过同一 SAN 上的不同控制器呈现日志和数据。
好问题！
首先看一下 Brent Ozar 关于这个问题的“Steel Cage BlogMatch”辩论。
在我们公司，对于大多数服务器，我们将数据和日志放在同一个 SAN 驱动器上，并由 SAN 团队确保一切正常。
我开始认为这不是最好的策略，尤其是对于大容量服务器。根本的问题是，我真的无法验证 SAN 团队是否真的在做任何事情，而不仅仅是为我们需要的空间拼凑足够的驱动器。我们不会从我们这边或其他任何地方对 SAN 驱动器运行 IO 基准测试，我们只是假设它们正在“完成他们的工作”（针对性能和空间进行调整），这可能有点幼稚。
我的另一个想法是，数据与日志所需的访问类型是不同的。我将尝试找到我最近阅读的文章，该文章讨论了两种不同的驱动器类型应该如何以非常不同的方式进行优化（我认为一种需要针对顺序写入进行优化，另一种需要针对随机读取进行优化，诸如此类.)
简而言之，是的，您将为 SQL Server 数据文件、日志文件以及 TempDB 数据和日志文件创建单独的卷。
由于您使用 Equallogic 标记了您的问题，请在设计解决方案之前通读免费的戴尔参考架构指南：使用戴尔™ EqualLogic™ PS5000 系列存储阵列部署 Microsoft® SQL Server® （需要注册）。通常，您会发现特定配置的指导与一般建议有很大不同。
在性能方面，我同意 BradC (+1)。一般来说，一个好的 SAN 会拥有比您预期使用的更多的原始 I/O。
将备份与实时系统分开仍然是一个好主意（很明显，我知道，但如果我每次看到这个都有 1 英镑......）
此外，建议将 tempdb 远离日志文件。当你开始想要日志、数据和温度的“不同存储桶”（技术术语）时，SAN 家伙的帐篷会向你翻白眼，但如果你告诉他们是这样，你就可以衡量进入每个区域的不同数据量 IO 和让他们向您展示他们精美的性能图表！
只需仔细/仔细检查 SAN 人员是否已为您正确设置。如果你想要 RAID 10，那就坚持（我做过），即使他们一直说他们的 RAID 5 没有性能损失。
（对于“基于文件”的操作，RAID 5 很好。对于密集写入，一旦你填满了写入缓冲区，你就搞砸了！）
请注意此处所有术语的混合。
一般来说，非常基本的：
您可以在同一个阵列上拥有多个卷，这是在进行本线程中讨论的高级优化时要记住的事情。
关键是其他几个人提到的（不要忘记），在不同的驱动器主轴上分离数据/日志/备份，而不仅仅是单独的卷。
编辑：上面的 Helvick 给了你一个关于 Equallogic SAN 的很好的答案！