SAN 磁盘分配

Question 1

我会将所有 24 个磁盘放入同一个磁盘组，以便为您提供最大可能的 I/O 开销。您将在该阵列上托管一些 I/O 密集度极高的应用程序（SQL DB、SQL Reporting 和 Exchange），因此您需要尽可能多地利用这些资源。请不要使用 7.2K RPM 驱动器；它们可能便宜又大，但您需要为性能扩展付出代价。

在我看来，将 DB 和 Log 流量放在不同主轴上的优化可能会被整体虚拟化 I/O 流量淹没。您将在此存储上拥有两个大型数据库 I/O 应用程序（SQL 和 Exchange），并且（再次，我的观点）您将需要尽可能多的 I/O 开销，因此将它们全部集中到一个大池中；严格分离 DB 和 Log I/O 会导致您更快遇到瓶颈。

还要考虑确保您的 Exchange 服务器的在线碎片整理和备份与您的 SQL 备份不重合。这三个操作的 I/O 非常繁重，如果可能的话，您不希望它们重叠。至于 Reporting Services，如果您正在运行任何非常大的查询/报告/作业，请尽量避免这些备份期。

DC 和网络服务器在这里只是次要的角色，所以应该没问题。

为什么要将它们全部捆绑到一个组中而不是将它们分开呢？

有了 12 个 15K 驱动器和 12 个 10K 驱动器，您可能最终需要两个磁盘组，每个速度一个。我不建议进一步拆分。

12x 15K 驱动器应为您提供大约 2270 I/O Ops/s（R0 中的完全随机 I/O）、1135-2270（R10 中的）和 2080（R5 中的）。12x 10K 驱动器应为您提供 1700 I/O Ops/s（R10 中的 850-1700、R5 中的 1560）。R10 速度是可变的，因为它取决于您的读/写百分比，以及控制器是否提供来自多个条带的读取（我不知道戴尔是否这样做）。显著的连续操作将更快，但您不能指望共享存储系统能做到这一点。

这些速度相当可观，但它们也代表了每种磁盘类型的最高性能。针对您确定的五项服务采用完全分离模型：

SQL
SQL 报告
交换
直流电源
网络服务

我会将最后两个磁盘放在 R1 配置中的一对 300GB 10K 驱动器上，其余 22 个磁盘则留给其他人。至于其余的……

SQL
- 1x R5 6 组 15K 驱动器用于日志
- 1x R5 4 组 10K 驱动器用于数据库
SQL 报告
- 1x R5 组 3 个 10K 驱动器，用于数据库等
交换
- 1x R5 6 组 15K 驱动器，用于邮件存储
- 1x R5 4 组 10K 驱动器用于日志

根据您的容量要求，您可能需要交换 DB/Log 卷。这样的配置为 SQL 和 Exchange 分别提供了总计 945 I/O Ops/s（用于日志和邮件存储），以及 420 I/O Ops/s（用于数据库和日志）。报告获得 280 I/O Ops/s。这使整体磁盘子系统性能达到 3230 I/O Ops/s。

将其与仅具有两个磁盘组的 3640 进行比较，以获得整体系统性能。为了隔离生产系统，您需要牺牲 12% 的性能。此类共享存储系统的主要优势之一是您可以更有效地利用存储。将上述内容分开意味着您的主要优势是将所有存储放在一组 RAID 控制器上的一个设备中，而不是使用多个 RAID 控制器，从而节省成本。

通过采用上述孤立配置，您会遇到 I/O 瓶颈快点：

您的数据库备份可能会完全占用分配给它们的 945 I/O Ops/s，并且将比拥有两倍可用空间时花费更长的时间。在此期间，数据库查询将明显变慢。这是一个 I/O 瓶颈。
在处理偶尔出现的复杂查询时，您的数据库卷无法使用其他孤岛中未使用的容量来更快地返回结果。它们将受到明确分配给它们的磁盘的限制。这是一个 I/O 瓶颈。
备份 Exchange 时（备份速度非常快，这很好）您的备份将花费更长时间，从而导致备份期间与系统交互的用户出现明显的性能问题。这是一个 I/O 瓶颈。

当其他人说“一个大磁盘组意味着你会更快地遇到 I/O 瓶颈”时，他们通常的意思是，一个行为不当的应用程序会影响整个应用程序的性能，最好将所有应用程序隔离开来，以保护所有应用程序不受其他应用程序的影响。他们对待存储就像对待内存的旧操作系统一样：每个人在启动时都会获得一个独立的内存分配，没有人可以超出这个范围。与内存不同，在这个模型中没有虚拟内存这样的东西，因此在启动时分配给进程的是物理内存。

最好像现代操作系统对待内存一样对待它：虚拟地。系统有 3640 个 I/O 操作可用，为什么不让所有东西都认为它有那么多可用。所有东西都不会一直使用，存储子系统将能够很好地满足大多数请求。如果需求确实达到了这个水平，那么事情就会开始陷入困境（IOWAIT 增加），是时候分析系统以找出导致速度变慢的原因了。

Answer