我们有一个用 ASP 和 SQL Server 开发的应用程序。我们使用 Rackspace 来托管它。我们的每个“客户”都有自己的 IIS 站点和 SQL 数据库。每个客户可能有十几个或几百个用户访问该应用程序。
我们现在有几百个客户。到目前为止，我们所做的就是在需要时出于性能原因添加另一对服务器（一个 IIS，一个 SQL）。现在我们最多有四对服务器。
我们正在继续增加新客户，并且正在寻找扩大规模的替代方法，而不是简单地添加服务器对。
我们正在考虑的一种方法是针对 IIS 端建立一个 Web 场，针对数据库端建立一个 SQL Server 群集和 SAN。
这是一个好方法吗？我们现在可能有 400 个客户，每个客户都有自己的 IIS 站点和 SQL 数据库。如果我们发展到 1,000 个怎么办？5,000 个？一个 SQL 集群可以处理数千个数据库吗？
每个数据库都有几百个表。我们一些大客户的主表可能有几十万条记录。
转向大型 IIS Web 场和大型 SQL 集群的一个吸引力在于，如果一台服务器出现故障，其他服务器可以承担负载。现在，如果我们的一台 SQL 服务器出现故障，或者我们的一台 IIS 服务器出现故障，四分之一的客户将无法使用该系统。因此，我们希望提高可靠性，并增加增加新客户的能力。
答案1
SQL Server 群集不是可扩展性解决方案，严格来说，它是一种高可用性解决方案。在 SQL Server 群集中，只有一个节点处于活动状态并处理负载，所有其他节点都只是被动待命，以防活动节点出现硬件故障。因此，从 SQL Server 群集中，您最多只能获得单个 SQL Server 实例的性能。您有时会发现所谓的“主动-主动”部署，但这不是 SQL Server 群集。所谓的“主动-主动”是二单独的集群以相反的角色使用彼此的节点（一个集群在节点 A 上处于主动状态而在 B 上处于被动状态，另一个集群在 B 上处于主动状态而在 A 上处于被动状态）。
如果您的应用程序已经分区，并且每个客户都有单独的数据库，那么继续扩展会更好。管理和维护问题可以解决，一旦您自动化了 4 台服务器的管理（即现在），您就可以自动化 1000 台服务器的管理。版本控制、部署和帐户配置问题也是如此。
虽然现在您可能会被扩大规模解决方案所带来的管理、故障排除和调整的简易性所吸引，但您会遇到更难解决的新问题，最终达到扩大规模的限制。
更新在您编辑 OP 并解释与扩展相关的问题之后。
确实，扩展和集群提供了高可用性解决方案。SQL Server 基本上有两种 HA 解决方案：集群和数据库镜像。由于您计划使用数千个单独的数据库，因此这几乎排除了镜像。但您必须记住的是，SQL Server 集群仅在有限的列表中受支持硬件组合：
Microsoft 服务器群集仅在群集解决方案下的 Windows Server 目录中列出的群集解决方案上受支持。要查看 Windows Server 目录，请访问以下 Microsoft 网站： http://www.windowsservercatalog.com/
这并不意味着您不能在具有共享 SCSI 总线的任何硬件对/组上运行集群。这意味着如果您在未经批准的硬件上遇到问题，您将无法向 Microsoft CSS 请求支持。
SQL Server 群集可防止硬件故障，但介质故障除外（因为介质在节点之间共享）。它无法防止人为管理错误，不幸的是，这是停机的主要原因。如果单个群集上有 1000 个客户数据库，那么你将在一个篮子里煎一个非常大的煎蛋卷……
至于你问的集群可以运行多少个数据库，最终集群在任何时候都只有一个活动实例，因此单个实例的限制也适用于集群。连接一千个数据库并不是什么大事，真正的问题是负载，有多少用户将同时运行查询。要获得一个大致的数字，请考虑 SQL Server 发布的 TPC-C 基准测试是在 64 路 Superdome 上每分钟处理大约 120 万个事务，这意味着大约每秒 16k 个事务。你预计大约有 5k 个客户端连接，这为你提供了每秒每个客户端 3 个查询的余量，而要达到这个目标，你需要一个非常强大的硬件和一个异常地经过良好调整的应用程序。
答案2
我同意之前发帖者的观点。这听起来确实像是你需要开始更多地考虑扩展的情况。但如果我有你现在的环境，我会花更多的时间致力于自动化，并确保我对我的环境有一个清晰的了解。无论你选择如何扩展，如果你没有编写脚本并自动化你的流程，你都会陷入管理噩梦。
就实际的规模策略而言，我认为您的可能设置可能如下所示；
1）所有客户的网络文件都位于所有网络服务器上
2）所有客户的网站均在各服务器的 IIS 中配置
3）对任何客户网络文件的更改都会同步到所有网络服务器
4）以下网页配置
- - - - - - - - - - - - - -
| Load Balancer |
- - - - - - - - - - - - - -
|
|
- - - - - - - - - - - - - - - -
| web | | web | | web | | web |
- - - - - - - - - - - - - - - -
| | | |
- - - - - - - - - - - - - -
| SQL Cluster |
- - - - - - - - - - - - - -
|
|
- - - - - - - - - - - - - -
| Warm SQL Cluster |
- - - - - - - - - - - - - -
然后，一旦我开始看到我的 SQL 群集的限制，我就会创建一个新的 SQL 群集，将我的数据库拆分到我的 2 个群集之间，并更改客户连接字符串，使它们指向各自的群集。
这里的想法是让负载均衡器发挥其最大作用，并在 Web 层之间分配流量。随着流量的增加，您可以随时将新的 Web 服务器放入轮换中以稍微平衡一下。保持所有 Web 服务器同步是这里的关键。
此外，我们让数据库服务器做它们最擅长的事情，一旦它们开始陷入困境，我们将添加一个新的服务器\集群来平衡工作。热 SQL Server 为您提供了一定程度的冗余，尽管在这里关于是否真的需要它可能会与我存在一些分歧。
最近有一篇关于 Foursquare 及其如何平衡负载的文章。他们使用的方法基本上是将用户分布在各个分区上，在 MongoDB 中，各个分区是独立的服务器。这种方法对他们来说非常有效，直到一组用户（他们都是重度用户，并且使用同一个分区 (分片)）使分片达到极限，从而导致分片崩溃。当然，这其中还有更多内容，但要点是：分布在各个机器上并监控使用情况，这样您就知道何时再次拆分和重新平衡负载。
不管怎样...这是我的观点。
答案3
您可能需要考虑使用云解决方案，例如 Amazon Web Services 的 EC2 以及补充数据库和存储服务。它非常易于扩展，并且完全可编程。您可以构建自定义仪表板来管理所有服务器并根据需要进行扩展。您只需按使用量付费，它们支持 Windows 和 Linux 平台，包括 IIS。如果您需要扩展到多台服务器或通过在东海岸和西海岸甚至欧洲托管服务器来提供地理冗余，您可以构建自己的自定义映像。Rackspace 有一个类似的解决方案，但我不确定他们是否已经发布了 Windows 支持 - 他们可能已经发布了。我尝试了两者，发现亚马逊更灵活、更全面，但由于您已经使用 Rackspace，它可能更有意义。祝你好运！