想象一下,你有一个成功的Web应用程序,它使用ASP.NET和IIS 7.它会产生很多对SQL Server 2008数据库的调用,并且预计将以99.9%的正常运行时间向公众提供(停机时间为8小时45分钟年)。
我们的目标是:
与对ASP.NET应用程序进行负载平衡不同,负载平衡SQL似乎要困难得多。 为使用Microsoft堆栈的Micro-ISV设置简单的负载平衡SQL Server 2008 R2群集,您有哪些最佳做法?
如果您需要高可用性,那么Windows / SQL Server集群或SQL Server数据库镜像提供解决scheme。 如果你以前从未做过,集群的确需要大量的计划和熟悉,但是它对于应用程序来说是透明的。
使用SQL Server可以实现负载均衡,但这不适合心存不满的人。 这是一个在SQL Server之前使用Windowsnetworking负载平衡(NLB)的解决scheme。 如果使用可更新的订户进行事务复制,则NLB中的SQL Server本身更容易pipe理,但它们可以是可读写的。 尽pipe这种types的复制在未来的版本中被标记为弃用。
最后一种可能性是可扩展共享数据库,但它们绝对是只读的。
更多阅读:
看一下Allan Hirt关于SQL Server 2005高可用性的Apress书籍,以及Apress的Pro SQL Server 2005/2008复制。
可扩展的共享数据库: http : //technet.microsoft.com/en-us/library/ms345392.aspx
关系数据库系统很less像Web服务器一样负载均衡。 经典的负载平衡方法的问题是,所有的数据库都需要保持同步。 如果两个服务器在任何时间点都没有相同的状态,那么关系模型是毫无价值的。
从你的问题来看,你甚至不想完成负载均衡,这主要是一个性能testing,以确保只有尽可能多的用户按照服务器可以处理的每个服务器。 这听起来像你想要一个高可用性设置。 既然你说你正在使用SQL Server,我会考虑故障转移。 这意味着,如果主数据库不可用,客户端将尝试访问故障转移服务器。 SQL Server处理使主实例和每个故障转移保持同步,并在主服务器从脱机状态恢复联机时处理将主实例重新同步到故障转移。
好的,我们走吧。 不能做。 不是没有应用程序更改
意识到在部署新的复制/制作数据库模式更改时,仍然需要将应用程序停机以进行维护。
这里经济有效的答案通常是用廉价商品平衡的服务器层托pipe应用程序服务来缓冲数据库,这些应用程序服务提供逻辑处理和数据存储,否则这些服务器会占用数据库资源。 显然,这需要对数据的波动性和caching策略进行一些思考。
让我给你一个侏罗纪的答案。 如果你的目标包括“安装Windows更新”,你是无法挽救的。
我的胡子灰了,可以记得一个应用程序可以运行10年而不必遭受“操作系统更新”的时间。 一个应用程序的使用寿命是几十年,而不是几年。
所以我的build议是:build立一个SQL Server数据库+应用程序的工作版本,并隔离MICROSOFT UPDATES中的数据库服务器。 如果没有损坏,请不要修复。
使用热插拔RAID磁盘。
如果您的硬件出了问题,请准备镜像数据库服务器(根据TomTom的build议)。