我们有一个在ASP和SQL Server中开发的应用程序。 我们使用Rackspace来托pipe它。 我们的每个“客户”都有自己的IIS站点和SQL数据库。 每个客户可能有十几个或几百个用户打这个应用程序。
我们现在有几百个客户。 到目前为止，我们所做的是在性能方面需要时添加另一对服务器（一个IIS，一个SQL）。 我们现在最多有四对服务器。
我们正在继续添加新的客户，我们正在寻找其他的方式来扩大，而不仅仅是添加服务器对。
我们正在考虑的一种方法是为IIS端提供Web服务器场，为数据库端提供SQL Server群集和SAN。
这是一个好方法吗？ 现在我们可能有400个客户，每个客户都有自己的IIS站点和SQL数据库。 如果我们增长到1000呢？ 5000？ 一个SQL集群可以处理数千个数据库吗？
每个数据库有几百个表。 一些大客户的主表可能有几十万条logging。
朝向一个大的IIS Web场和一个大的SQL集群的一个吸引力是，如果一个服务器停机，其他服务器可以承载这个负载。 现在，如果我们的某个SQL服务器出现故障，或者我们的某个IIS服务器出现故障，那么我们四分之一的客户将无法使用该系统。 所以我们希望增加可靠性，并增加增加新客户的能力。
SQL Server群集不是一个可伸缩性解决scheme，是严格意义上的高可用性解决scheme。 在一个SQL Server集群中，只有一个节点处于活动状态并处理负载，其他所有节点都只是被动的待机状态，等待活动节点发生硬件故障。 从SQL Server集群中，您可以获得最好的单个SQL Server实例的性能。 您会发现有时会引用所谓的“主动 – 主动”部署，但这不是SQL Server群集。 所谓的“主动 – 主动”是两个分开的集群，它们使用彼此的反向angular色节点（一个节点A处于活动状态，B处处于被动状态，另一个处于活动状态B，而A处于被动状态）。
如果您的应用程序已经分区，每个客户都有一个单独的数据库，那么您将继续向外扩展。 pipe理和维护的问题可以解决，一旦你自动pipe理4台服务器（即现在），你可以自动pipe理1000台服务器。 那么是版本，部署和帐户供应的问题。
虽然现在你可能会被一种易于pipe理的感觉所吸引，从一个扩大的解决scheme中排除故障并进行调整，你将会遇到新的问题，更难以解决，最后限制在多大的范围内。
更新编辑完OP后，解释与扩大相关的问题。
事实上，扩展和集群提供了高可用性解决scheme。 基本上有两种SQL Server解决scheme：集群和数据库镜像。 既然你计划了数以千计的个人数据库，这几乎排除了镜像。 但是你必须记住的是，SQL Server集群只能在受限的硬件组合列表上支持：
群集解决scheme下的Windows Server目录中列出的群集解决scheme仅支持Microsoft服务器群集。 要查看Windows Server目录，请访问下面的Microsoft网站： http : //www.windowsservercatalog.com/
这并不意味着您无法在具有共享SCSI总线的任何硬件对/组上运行群集。 这意味着如果您的硬件未获得批准，您将无法从Microsoft CSS请求支持。
除了介质故障（因为介质在节点之间共享）之外，SQL Server集群提供保护以防硬件故障。 它不能提供保护的是人为pipe理错误，不幸的是造成停工的主要原因。 在一个集群上有一千个客户数据库，你就可以在一个篮子里做一个非常大的煎蛋卷。
至于你对集群运行多less个数据库有疑问，最终一个集群最终只有一个活动实例，所以单个实例的限制也适用于集群。 拥有一千个数据库并不是一件大事，真正的问题是负载，有多less用户同时运行查询。 为了得到一个数字大小的区域，考虑为SQL Server发布的TPC-C基准testing是在64路Superdome上每分钟大约1.2百万个事务，这意味着每秒大约16k个事务。 您预计大约有5k个客户端连接在一起，每个客户端每秒可以获得3个查询的余量，为了达到这个目标，您需要一个漂亮的beeffy硬件和一个非常好的tunned应用程序。
我同意以前的海报。 它肯定听起来像是你需要开始思考更多关于缩放的情况。 但是如果我有这样的环境，现在听起来就像现在一样，我将花更多的时间在自动化的事情上工作，并确保我对自己的环境有一个稳健的鸟瞰图。 不pipe你如何select扩展，如果你不是脚本化和自动化你的stream程，你将会遇到一个pipe理上的噩梦。
就实际的规模战略而言，我认为你可能的设置可能如下所示：
1）所有客户的网页文件都在所有的网页服务器上
2）在所有服务器上的IIS中configuration的所有客户网站
3）更改任何客户的Web文件同步到所有的Web服务器
4）下面的webconfiguration
- - - - - - - - - - - - - - | Load Balancer | - - - - - - - - - - - - - - | | - - - - - - - - - - - - - - - - | web | | web | | web | | web | - - - - - - - - - - - - - - - - | | | | - - - - - - - - - - - - - - | SQL Cluster | - - - - - - - - - - - - - - | | - - - - - - - - - - - - - - | Warm SQL Cluster | - - - - - - - - - - - - - - 然后，一旦我开始在我的SQL集群上看到限制，我将创build一个新的SQL集群，将我的数据库拆分到我的两个集群中，并更改客户连接string，以便指向它们各自的集群。
这里的想法是让负载平衡器做它最擅长的事情，并在Web层之间分配stream量。 随着stream量的增加，你可以随时把一个新的web服务器放到轮换中来平衡一下。 保持所有Web服务器同步是关键。
另外，我们让数据库服务器做他们最擅长的工作，一旦他们开始陷入困境，我们会添加一个新的服务器\集群来平衡工作。 温暖的SQL Server给你一定程度的冗余，虽然在这里可能会有一些不同意见，是否真的需要。
最近有一篇关于Foursquare的文章，以及他们如何平衡他们的负载。 他们使用一种方法，基本上分布在不同分区上的用户，在MongoDB中，这些分区是独立的服务器。 这对他们来说工作得非常好，直到一群正好是沉重的用户并且在相同的分区（碎片）上的用户群通过使其达到极限而破坏了碎片。 当然还有更多，但是jist是;跨机器分布并监视使用情况，以便知道何时再次拆分和重新平衡负载。
无论如何….那是我的2美分。
您可能需要考虑像Amazon Web Services的EC2这样的云解决scheme以及补充的数据库和存储服务。 这是非常容易扩展，它是完全可编程的。 您可以构build自定义仪表板来pipe理所有服务器，并根据需要进行扩展。 您只需支付您使用的费用，并支持包括IIS在内的Windows和Linux平台。 如果您需要扩展到多个服务器或通过在东西海岸甚至欧洲托pipe服务器来提供地理冗余，则可以构build自己的自定义映像。 Rackspace有一个类似的解决scheme，但我不确定他们是否发布了Windows支持 – 他们可能有。 我试了两次，发现亚马逊更加灵活和全面，但是既然你已经在使用Rackspace，那么它可能更有意义。 祝你好运！