假设您有一个使用 ASP.NET 和 IIS 7 的成功的 Web 应用程序。它会对 SQL Server 2008 数据库产生许多调用,并且预计以 99.9% 的正常运行时间(每年的停机时间为 8 小时 45 分钟)向公众开放。
我们的目标是:
- 在服务器上安装 Windows 更新,而不会导致客户停机
- 防止服务器硬件崩溃导致 ASP.NET 应用程序因超时而变慢
与 ASP.NET 应用程序的负载平衡不同,SQL 的负载平衡似乎要困难得多。对于使用 Microsoft 堆栈的 Micro-ISV,您设置简单的负载平衡 SQL Server 2008 R2 群集的最佳实践是什么?
答案1
如果您需要高可用性,那么 Windows/SQL Server 群集或 SQL Server 数据库镜像可提供解决方案。如果您以前从未做过群集,则需要大量规划和熟悉,但它对应用程序来说是透明的。
SQL Server 可以实现负载平衡,但这并不适合胆小者。这是一种在 SQL Server 前面使用 Windows 网络负载平衡 (NLB) 的解决方案。如果 NLB 中的 SQL Server 本身是只读的,则更易于管理,但如果您使用具有可更新订阅者的事务复制,则可以将其设置为读写。不过,这种类型的复制在未来版本中将被标记为弃用。
最后一种可能性是可扩展共享数据库,但它们绝对是只读的。
更多阅读:
请参阅 Allan Hirt 的 Apress 书籍《SQL Server 2005 High Availability》和《Pro SQL Server 2005/2008 Replication》。
可扩展的共享数据库: http://technet.microsoft.com/en-us/library/ms345392.aspx
答案2
关系数据库系统很少像 Web 服务器那样进行负载平衡。传统的负载平衡方法的问题在于,所有数据库都需要不断同步。如果两台服务器在任何时间点的状态不相同,关系模型就毫无价值。
从你的问题来看,你似乎根本没有尝试实现负载平衡,这主要是一种性能衡量标准,以确保每台服务器仅能处理尽可能多的用户。听起来你想要一个高可用性设置。既然您说您正在使用 SQL Server,我会研究故障转移。这意味着,如果主数据库不可用,客户端将尝试访问故障转移服务器。SQL Server 负责保持主实例和每个故障转移同步,并在主实例从离线状态恢复在线时负责将主实例重新同步到故障转移。
答案3
好的,我们开始吧。这不可能。除非应用程序发生变化。
- 安装更新 - 使用群集或镜像来确保您拥有两个可以正常工作或可以更快地将故障转移到另一台计算机的数据库。强烈建议使用镜像。
- 重写应用程序来处理该问题(即连接失败,需要透明地重新连接,以便连接到副本)。
请注意,当您部署新副本/进行数据库模式更改时,仍然需要关闭该应用程序进行维护。
答案4
让我给你一个侏罗纪时代的答案。如果你的目标包括“安装 Windows 更新”,你就无可救药了。
我已经满头白发,还记得曾经有一段时间,一款应用程序可以运行 10 年而不必忍受“操作系统更新”。一款应用程序的有效寿命是以十年而不是几年来衡量的。
所以我的建议是:建立 SQL Server 数据库 + 应用程序的工作版本,并将数据库服务器与微软更新隔离。如果它没有损坏,就不要修复它。
使用热插拔 RAID 磁盘。
准备好镜像数据库服务器(根据 TomTom 的建议),以防硬件出现故障。