ISCSI SAN 上的 SQL Server 磁盘设计

Question

将日志和数据文件分开以将磁盘与操作系统分开的标准做法（临时数据库、备份和交换文件也是如此） 当您的驱动器都是基于 SAN 并且您的 LUN 不是由特定磁盘或突袭集雕刻时，这种逻辑是否仍然有意义-它们只是 SAN 上 x 个驱动器的一部分，而 LUN 只是空间分配

Answer 1

日志和数据驱动器具有不同的数据访问模式，它们在共享驱动器时会相互冲突（至少在理论上）。

日志写入

日志访问由大量的小顺序写入组成。简单地说，DB 日志是环形缓冲区，其中包含将数据项写入磁盘上特定位置的指令列表。访问模式由必须保证完成的大量小顺序写入组成 - 因此它们被写出到磁盘。

理想情况下，日志应该在一个安静的（即不与其他任何东西共享）RAID-1 或​​ RAID-10 卷上。从逻辑上讲，您可以将此过程视为主要的 DBMS 写出日志条目和一个或多个使用日志并将更改写出到数据磁盘的日志读取器线程（实际上，该过程经过优化，以便将数据写入写入在可能的情况下立即退出）。如果日志磁盘上有其他流量，则这些其他访问会移动磁头，并且顺序日志写入变为随机日志写入。这些要慢得多，因此繁忙的日志磁盘可能会创建一个热点，从而成为整个系统的瓶颈。

数据写入

（更新）日志写入必须提交到磁盘（称为稳定介质）才能使事务有效并符合提交条件。可以从逻辑上将其视为正在写入的日志条目，然后将其用作通过异步进程将数据页写入磁盘的指令。实际上，磁盘页面写入实际上是在创建日志条目时准备和缓冲的，但不需要立即写入以提交事务。磁盘缓冲区由 Lazy Writer 进程写出到稳定媒体（磁盘）（感谢 Paul Randal 指出这一点），这篇 Technet 文章对此进行了更详细的讨论。

这是一种高度随机的访问模式，因此与日志共享相同的物理磁盘可能会人为地造成系统性能瓶颈。日志条目必须书面提交事务，所以有随机寻道减缓这个过程（随机I / O是多少比顺序日志I / O速度较慢）将开启日志从sequenital成随机存取设备。这会在繁忙的系统上造成严重的性能瓶颈，应该避免。这同样适用于与日志卷共享临时区域。

缓存的作用

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 阵列的双插槽盒进行了比较。在这种情况下，从 ebay 购买的价值 3,000 英镑的硬件比价值 100 万英镑的高端 SAN 高两倍——在 CPU 和内存配置大致相同的主机上。

从这个特定的事件来看，可能有人会说，将这样的东西放在身边是让 SAN 管理员保持诚实的一种很好的方式。

Answer 2

我假设 Equallogic 标记和请求的内容意味着您正在谈论 Equallogic SAN。以下内容专门针对 Equallogic，不适用于其他 SAN 类型。

对于 Equallogic 阵列，无法像使用 EMC Clariion 阵列那样精确地指定用于卷的特定磁盘，因此该方法必须有所不同。

Equallogic 架构是非常自动化和动态的。它的基本构建块是阵列单元，而不是其他 SAN 中看到的阵列内的 RAID 包\组。每个阵列完全针对 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 专家进行真正的设计。如果您只有一个阵列，那么在分离卷方面您无能为力。

Answer 3

我们将 DB 存储在单个 SAN 盒上，但具有单独的数据、日志和备份 LUN，每个在不同的磁盘组上，按速度分层 - 将我们的日志存储在 RAID 10 15Krpm LUN 上，将数据存储在 RAID 1 10/15krpm LUN 上并备份到 RAID 5 个 7.2krpm LUN。我们还通过同一 SAN 上的不同控制器呈现日志和数据。