现在，我在虚拟机上拥有32位操作系统。由于Standard
Edition不允许两个服务器（IIS和SQL）使用AWE，因此SQL Server将加载最大容量（大约1.8
GB），并为IIS和OS留出大量RAM。但是一旦移至64位操作系统，情况就会发生变化，因为SQL
Server将占用其缓冲池的所有RAM（如果有6GB可用，则为〜5GB），然后在收到通知时开始将其返还给OS 。可以通过配置SQL
Server内存选项来调整此行为。通过将IIS和SQL拆分为单独的VM，您可以将SQL
VM的所有内存留给其缓冲池，这很好。理想情况下，您应该有足够的RAM，以便SQL可以将整个数据库加载到内存（包括tempdb）中，并且仅需触摸磁盘进行日志写入，以及何时需要检查数据库。换句话说，更多的RAM意味着更快的SQL。到目前为止，它是SQL性能所需的最重要的硬件资源，并且将为您带来最大的收益。

现在回到有关“故障转移”的广泛问题。在SQL Server中， 高可用性 解决方案分为两类： 自动 和 手动 。对于 自动 故障转移，您实际上只有几种解决方案：

• 聚类 。传统上，由于支持群集的硬件成本高昂，因此实现起来相当昂贵，但是对于VM，情况则完全不同。Standard Edition SQL支持两个节点群集。群集有点难以部署，但是操作起来很容易，不需要更改应用程序即可支持。通过群集，故障转移的单元是整个SQL Server实例（即，每个数据库，包括master / tempdb / model和msdb，所有登录名，所有SQL Agent作业等）。集群 不是 一种性能解决方案，因为备用服务器只是在主服务器崩溃的情况下处于空闲状态。您可以通过部署所谓的“主动-主动”群集来利用备用虚拟机。这意味着您要部署 两个 集群，一个在VM1上处于活动状态，在VM2上处于备用状态，另一个在VM2上处于活动状态，在VM1上处于备用状态。在发生故障转移的情况下，其中一个VM必须承担 两个 实例的负载，这就是为什么有时不赞成双活部署的原因。鉴于您计划在非昂贵金属上的VM上进行部署，因此我建议不要这样做，因为不需要“摊销”大笔费用。
• 镜像 。这将保留 数据库 （而不是实例）的热备用镜像。由于部署成本较低（无特殊硬件），故障转移时间（以秒为单位，而不是群集中的分钟数）和地理分布功能（镜像支持将节点分布在单独的节点上，因此群集仅支持短距离的群集），因此镜像比群集更可取节点之间的距离为100米）。但是，因为故障转移的单位是 数据库 ，所以镜像无法提供使用集群的便利性。应用程序所需的很多资源都 没有 驻留在数据库中：登录名，代理程序作业，维护计划，数据库邮件等等。由于仅数据库进行故障转移，因此必须仔细计划故障转移，以使应用程序在故障转移后继续运行（例如，必须转移登录名）。该应用程序还必须注意镜像部署，以便正确连接。使用Standard Edition，您将只能在高安全性模式下部署镜像。
• 硬件 镜像。我将不对此进行详细介绍，它需要具有磁盘级别镜像功能的专用SAN硬件。

如果您正在考虑手动故障转移解决方案，那么还有其他两种选择：

• 日志传送 。日志传送基本上是带外镜像。通过文件复制操作可以传输日志，而不是通过专用的TCP连接实时传输日志记录。选择镜像传送而不是镜像的理由很少：可以查询备用数据库以进行报告，可以将备用数据库放置在具有零星连接性的位置，可以将备用数据库安装在功率真的很低的机器上。

• 复制。这确实不是一个高可用性解决方案。复制是提供数据副本和/或在站点之间交换数据更新的解决方案。尽管可以将其用于部署某种类型的高可用性临时“解决方案”，但这样做存在很多问题，并且基本上没有优势。与日志传送和镜像相比，它具有许多 其他 缺点，因为故障转移的单元甚至不是数据库，而仅仅是数据库（某些表）中的数据片。诸如用户和安全权限之类的元数据不会故障转移，架构更改必须在复制感知模式下完成有些更改甚至无法复制。根据合同，镜像和日志传送均提供与生产数据库相同的备用副本，该副本自动覆盖对数据库所做的 任何 更改。

您提到您担心许可证成本： 除 复制 外， 您实际上不需要具有任何这些技术的任何
被动 服务器的许可证。备用服务器只有在它们变为活动状态并且运行数据库超过30天时才需要许可证。 __

考虑到您计划在VM上进行部署，我的选择是群集。如果您要在金属上部署，由于群集硬件的成本，我建议您使用镜像。