用于数据库服务器和数据存储的虚拟化技术的优缺点

这是“视情况而定”的问题之一。

性能取决于资源、争用、配置和 VM 引擎

无竞争的虚拟机主机：如果您正确地为虚拟机提供无竞争的高性能本地连接或 SAN 存储、CPU 资源争用低、没有内存过度使用或争用、快速专用网络访问等，它通常会在适当的调整 VM 引擎。确切的结果将取决于所使用的 VM 系统、您如何提供对资源的访问等等。

您可以通过保证低争用率和良好存储的高端 VPS 计划获得出色的结果。

竞争/资源不足的 VM 主机：如果将它与其他三个应用程序服务器和一个文件服务器放在同一个盒子上，它们都共享同一个 RAID 5 阵列并且正在争夺 RAM 和 CPU，它的性能会非常糟糕。

如果你把它放在一个廉价的超额订阅和超额使用的 VPS 主机上，你会得到同样糟糕的结果。如果您的一半 RAM 真的在主机磁盘上交换，那么没有什么会很快。

“在云中”：如果你把它放在 EC2、Azure 或其他任何东西上，那么性能将取决于服务的争用率、他们正在使用的存储、其他用户在做什么、他们的 QoS 有多好，以及更多。

至少对于 EC2，磁盘子系统的性能非常糟糕（在标准 VM 上，至少在 2012 年），因此只有在您有足够的 RAM 至少可以缓存您的索引时，它才能正常运行。亚马逊推出了新的高 I/O 实例，可能会更好，但我还没有看到基准测试。

通常，如果您选择具有良好磁盘的轻度竞争托管，例如高质量的高端虚拟专用服务器主机，您会得到一些介于两者之间的东西。

直接与虚拟机保证

关于文件排序之类的具体保证，这取决于您的 VM 设置。您是否使用文件支持的虚拟机？通过原始块设备？通过 iSCSI SAN？它还取决于您的 VM 引擎是如何配置的，以及您使用的是哪个 VM 系统。

最佳案例

在最好的情况下——一个具有全副虚拟驱动程序、VT-x、VT-IO、对主机资源的无竞争访问等的系统——你可能会获得非常接近主机的性能。如果您给虚拟机直接块设备而不是托管文件进行存储，那么您将获得正确的文件排序，而不会出现主机端碎片。究竟有多接近取决于您的特定硬件、主机和来宾、配置等；用您的工作量对其进行基准测试。

fsync() 和写持久性

使用 VM 需要注意的一件事是，您必须确保磁盘系统说出 fsync() 的真相。使虚拟机更快的一种非常简单的方法是忽略 fsync() 请求。在虚拟机主机崩溃或断电之前，这很好，此时您的数据库可能会被彻底破坏。VM 主机必须通过尊重客户操作系统的磁盘刷新命令来满足 fsync() 请求，或者必须提供在断电时不会消失的非易失性写入缓存。一些 SAN 使用 SSD，大多数其他系统使用电池支持的 RAID 控制器缓存。如果您的 VM 每秒可以处理超过几百个事务，则可能会忽略 fsync 或写入缓存存储，您应该在它吃掉您的数据之前找出哪个。

但为什么？

（更新）：正如 Chris Travers 所说，为什么要虚拟化数据库服务器？为什么不在数据库服务器级别处理复制、心跳和故障转移，通过提升副本进行迁移，并获得裸机的全部性能？

我以虚拟机是给定的心态写了这个原始回复，问题是如何获得最佳结果。在我看来，最好的数据库服务器虚拟化仍然是没有虚拟化。也就是说，我只管理过相当小的网站。

一般来说，我对虚拟机上的数据库服务器有疑问。我不怀疑按照前面的答案是可能的，但它让我感到复杂性损失，特别是对于 PostgreSQL，只要您使用不同的 IP 地址或端口，您就可以在没有虚拟化的情况下在同一个系统上运行多个集群。

人们在专业方面谈论的事情是您可以整合服务器。这在其他 RDBMS 系统上最有用，因为在同一台服务器上运行多个实例是不可行的。在某些情况下，它可能会在性能方面提供一些灵活性。特别是对于低端应用程序，这些可能是引人注目的好处。

然而，这些必须与虚拟机是一个非常黑匣子的事实相权衡，如果你特别是在云上运行，你就缺乏对硬件的控制。这意味着此类服务器特别敏感的磁盘 I/O 通常不在您的控制范围内。可以通过网络存储来缓解这种情况。

所以我的看法是这样的：虚拟化，如果它解决了你遇到的特定问题，如果你已经处于一个可以控制每个集群的磁盘 I/O 的环境中，它可能是一个有用的解决方案。然而，更多时候它是寻找问题的解决方案，而不是复杂性的胜利。如果您问这个问题，那么这不是适合您的解决方案。