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

现在你假设VM上有32位操作系统.由于标准版不允许 AWE这两台服务器(IIS和SQL),SQL Server将加载最大约1.8 GB的内存,并为IIS和操作系统留下足够的RAM.但是一旦你转移到64位操作系统,事情会发生变化,因为SQL Server将为其缓冲池占用所有RAM(如果有6GB可用,则为~5GB),然后在 notified时开始将其返回给操作系统.可以通过配置SQL来调整此行为服务器 memory options.通过将IIS和SQL拆分到单独的VM上,可以将SQL VM上的所有内存留给缓冲池,这很好.理想情况下,您应该有足够的RAM,以便SQL可以将整个数据库加载到内存(包括tempdb)中,只触摸磁盘以进行日志写入以及何时必须检查数据库.换句话说,更多的RAM意味着更快的SQL.它是迄今为止SQL对性能所需的最重要的硬件资源,并将带来最大的收益.

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

> Clustering.传统上由于支持群集的硬件成本高,实施起来相当昂贵,但对于虚拟机,这是一个不同的故事. Standard Edition SQL支持两个节点集群.集群有点难以部署,但操作非常简单,无需支持应用程序更改.通过群集,故障转移单元是一个完整的SQL Server实例(即每个数据库,包括master / tempdb / model和msdb,所有登录,所有SQL Agent作业等).群集不是性能解决方案,因为备用服务器只是闲置以防主要服务器崩溃.您可以通过部署所谓的“主动 – 主动”群集来利用备用VM.这意味着您部署了两个集群,一个在VM1上处于活动状态,在VM2上处于备用状态,另一个在VM2上处于活动状态,在VM1上处于备用状态.在故障转移的情况下,其中一个VM必须承担两个实例的负载,这就是为什么主动 – 主动部署有时不受欢迎的原因.鉴于你计划部署在没有(昂贵)金属的虚拟机上,我建议反对它,因为’ammortize’没有巨大的成本.
> Mirroring.这将保留数据库的热备用镜像(不是实例).镜像优于群集,因为部署成本较低(无需特殊硬件),故障转移时间较短(与群集中的分钟数相对的秒数)和地理分布功能(镜像支持在单独的端口上分配节点,群集仅支持少量短距离)节点之间的百米).但由于故障转移单元是数据库,因此镜像不提供集群的易用性.应用程序所需的许多资源不驻留在数据库中：登录,代理作业,维护计划,数据库邮件消息等等.由于只有数据库进行故障转移,因此必须仔细规划故障转移,以便应用程序在故障转移后继续工作(例如,必须转移登录).应用程序还必须了解镜像部署,以便connects properly.使用Standard Edition,您将只能在high-safety mode中部署镜像.
>硬件镜像.我不打算详细介绍这个,它需要能够进行磁盘级镜像的专用SAN硬件.

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

> Log Shipping.日志传送基本上是带外镜像.日志不是通过专用TCP连接实时传输日志记录,而是通过文件复制操作传输.通过镜像选择日志传送的原因很少：可以查询备用数据库进行报告,备用数据库可以位于具有零星连接的位置,备用数据库可以由非常低功率的机器安装.
>复制.这实际上不是高可用性解决方案.复制是一种在站点之间提供数据副本和/或交换数据更新的解决方案.虽然它可以用于部署某种高可用性的make-shift“解决方案”,但是存在许多问题并且基本上没有优势.与日志传送和镜像相比,它还有许多其他缺点,因为故障转移单元甚至不是数据库,只是数据库中的数据片段(某些表).用户和安全权限等元数据不会进行故障转移,必须在replication aware mode中完成模式更改,甚至无法复制某些更改.通过合同,镜像和日志传送都提供与生产数据库相同的备用副本,该数据库自动覆盖对数据库所做的任何更改.

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

考虑到您计划在VM上部署,我的选择将是群集.如果你要在金属上部署,我建议使用镜像,因为集群硬件的成本.