出于性能原因的数据库分区在虚拟化环境中有意义吗？

Question

在物理硬件上运行 SQL Server 时，将数据库数据和日志文件放在单独的磁盘或 RAID 阵列上可以提高性能、弹性和维护。在单独的物理磁盘和 RAID 阵列上对数据库进行分区也是一种选择。简单地说，更多的锭子更好。

当 SQL Server 在虚拟环境中运行时，主轴的概念应用不同。您通常几乎无法直接控制虚拟磁盘映射到的物理磁盘。这是否意味着对数据库进行分区或将数据和日志文件拆分到单独的虚拟磁盘上是没有意义的，就像我们对物理磁盘所做的那样？

我了解对仍然适用于虚拟环境的数据库进行分区还有其他原因。例如，大的只读表可以在一个单独的分区中，只需要备份一次，但这不是本文的主题。

Answer 1

这是一个老问题，但我遇到了这个问题，并对一个特定的评论感到震惊，这表明最初的问题是“混乱的”。这个问题非常清楚，只是不严格涉及数据库管理。它主要属于虚拟环境中的服务器虚拟化和存储配置领域。这个问题很可能更适合另一个 StackExchange 站点，但因为不理解这个问题而傲慢地驳回这个问题是不可接受的。

让我尝试更好地解释这个问题，并就这个主题给出我最好的建议，试图为任何其他可能被搜索引擎丢弃的人留下一些有用的东西。

部署数据库服务器时，最佳实践是将操作系统、数据文件和日志文件放在不同的磁盘组上。举个随机的例子，假设我们有一台由三个 RAID 阵列组成的服务器：

RAID 1 中的 2 个 HDD 用于操作系统 RAID 10 中的 4 个 HDD 用于数据库数据文件 RAID 10 中的 4 个 HDD 用于数据库日志文件 此设置将分离 IO，并为数据文件和日志创建单独的故障点，以及将其与操作系统分开。这样做是出于性能、弹性和维护方面的原因。很简单，对吧？

但是，如果我们在虚拟环境中部署数据库服务器怎么办？虚拟环境中没有物理磁盘。不，确实没有，除非您将虚拟机磁盘 1:1 映射到物理磁盘，这不是您在典型的虚拟服务器场中看到的做法。即使这样，物理磁盘和虚拟服务器之间也会有一个虚拟化层，将物理磁盘呈现为连接到虚拟磁盘控制器，而不是磁盘实际连接到的物理控制器。

那么问题出在哪里呢？我们以小型虚拟服务器部署为例。一组在虚拟化集群中运行的机架服务器和一个 SAN，其中包含一组采用 RAID 5 和 RAID 6 的磁盘组，并具有自动存储分层功能。在本示例中，所有虚拟磁盘都存储在 SAN 中。

您现在如何为虚拟数据库服务器分配单独的物理磁盘组？或者也许你不知道？这就是这里问的问题。没有给出有用的答案，这是可以理解的，因为这是一个复杂的问题，答案在很大程度上取决于您的特定部署。某些设置可能会让您非常严格地控制虚拟磁盘最终所在的物理磁盘类型和特定物理磁盘，而其他设置可能更像是一个黑匣子，可以自动处理所有内容。

在我上面概述的简单“one-SAN”示例中，我想说您实际上并不需要这样做。但你可能仍然想这样做。即使您无法实际控制 IO 最终到达的物理磁盘，分割数据还有其他好处。如果您将来迁移到新的虚拟环境，并且获得具有不同且已知性能特征的独立 LUN，该怎么办？如果数据已分割到多个虚拟磁盘上，则将它们移动到具有适当 IO 功能的新 LUN 会容易得多。在许多管理程序中，您还可以为虚拟磁盘提供不同的 IO 优先级。同样，这为您提供了一些额外的控制权。对快照行为进行更准确的控制也成为可能。每个数据库都有自己独立的底层文件系统，不需要与同一服务器上的其他数据库甚至操作系统本身共享。

基本上，这取决于您的性能要求、数据库大小、您可以使用的虚拟机管理程序和存储解决方案以及许多其他因素。我希望我已经指出了一些有用的提示。未雨绸缪。虽然采用 SAN/NAS 解决方案的虚拟环境在很多方面可能看起来像黑匣子，但其中许多解决方案确实有办法实现与传统直接存储相同的性能和冗余目标。