提高性能的最佳方法(并以某种方式包括故障转移)

Question

我们有一个运行的应用程序,其中IIS和SQL在同一台机器上.它是一个Windows2003标准服务器,在VM上运行4GB内存.

现在,用户数量不断增加.还有一些巨大的统计数据,可以由用户运行,但对其他用户的性能影响很大.所以我们需要以某种方式提高性能.

我想在每台机器上使用windows2008 64位和至少6 GB内存的2台不同机器上分离IIS和SQL,但它也应该有一个故障转移解决方案.

您能否推荐一些有关如何解决性能和故障转移问题的方案？

谢谢

PS:

仅供参考:我们现在在IIS中使用inproc状态管理,但我认为更改为sqlstatemanagement会更好.

编辑

我已经将问题扩展到了故障转移的程度.因为我们的客户不想在服务器和SQL许可证上花太多钱.将复制到第二个SQL服务器并将其用作故障转移是否"可以"？你知道更好的"廉价"解决方案吗？

该应用程序仅供内部使用,但现在越来越多的部门参与此项目.

Answer 1

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

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

• 聚类。传统上，由于支持集群的硬件成本高昂，实现起来相当昂贵，但对于虚拟机来说，情况就不同了。标准版 SQL 支持两个节点集群。集群部署起来有点困难，但操作起来相当简单，并且不需要更改应用程序即可支持。对于集群，故障转移的单位是整个 SQL Server 实例（即每个数据库，包括 master/tempdb/model 和 msdb、所有登录、所有 SQL 代理作业等）。集群不是一种性能解决方案，因为备用服务器只是闲置，以防主服务器崩溃。您可以通过部署所谓的“主动-主动”集群来利用备用虚拟机。这意味着您部署两个集群，一个在 VM1 上处于活动状态，在 VM2 上处于备用状态，另一个在 VM2 上处于活动状态，在 VM1 上处于备用状态。如果发生故障转移，其中一个虚拟机将必须承担两个实例的负载，这就是为什么主动-主动部署有时会受到反对。鉴于您计划部署在虚拟机上而不是（昂贵的）金属上，我建议不要这样做，因为“摊销”没有巨大的成本。
• 镜像。这将保留数据库（而不是实例）的热备用镜像。镜像优于集群，因为部署成本较低（无需特殊硬件）、故障转移时间较短（集群中为数秒，而不是几分钟）和地理分布功能（镜像支持将节点分布在不同的大陆上，集群仅支持少数几个节点的短距离）。节点之间百米）。但由于故障转移的单位是数据库，镜像并不能提供集群的易用性。应用程序所需的许多资源并不驻留在数据库中：登录、代理作业、维护计划、数据库邮件消息等等。由于只有数据库进行故障转移，因此必须仔细规划故障转移，以便应用程序在故障转移后继续工作（例如，必须转移登录名）。应用程序还必须了解镜像部署，以便正确连接。使用标准版，您只能在高安全模式下部署镜像。
• 硬件镜像。我不打算详细介绍这一点，它需要能够进行磁盘级镜像的专门 SAN 硬件。

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

• 日志运输。日志传送基本上是带外镜像。日志不是通过专用 TCP 连接实时传输日志记录，而是通过文件复制操作传输。选择日志传送而不是镜像的原因很少：可以查询备用数据库以进行报告、备用数据库可以位于连接不定时的位置、备用数据库可以由功率非常低的计算机容纳。

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

您提到您担心许可证成本：实际上，您不需要使用除复制之外的任何这些技术的任何无源服务器的许可证。仅当备用服务器变为活动状态并运行数据库超过 30 天时才需要许可证。

考虑到您计划在虚拟机上部署，我的选择是集群。如果您要在金属上部署，我建议您使用镜像，因为集群硬件的成本较高。