创buildIIS7中多个服务器共享多个站点的最佳方式是什么？

在我的公司，我们的主要产品是基于networking的，我们的每个客户都有自己的网站。每个客户都去customer.domain.com访问他们的网站。目前，在IIS中，每个客户都build立了自己的网站，并为该网站中的所有应用程序提供了1个应用程序池。我们的许多客户都在相同的代码基础上，但有些客户使用新版本（testing版）。

我们也使用负载平衡，以便每个请求可能会击中任何X服务器。

这是最理想的设置？其中一个主要问题是服务器上只有大约8 GB的内存，而且还有大约200个客户端，所以对于每个应用程序池，我们必须限制它可以使用的内存量为300MB，这样我们就不会内存不足，但这也会导致应用程序池经常回收。

我们希望扩展，而不是增加，但是随着我们添加越来越多的客户端，我们将拥有越来越less的RAM，或者我们将不得不开始向服务器添加大量的RAM。

如果你有类似的设置，你是怎么解决这个问题的？

我们为不同的客户在不同的域名下的同一个框中设置了多个不同的网站。我们从一个文件夹和一个应用程序池运行它们，因为它们都共享一个代码库。

对于想要查看testing代码的客户，我们还有一个登台站点设置，他们可以login并查看（如果帐户已在该站点上为其设置），它们具有不同的FQDN集。所以我们结束了两个网站和两个应用程序池。

基本上所有你需要做的是设置IIS侦听多个IP与证书设置为每个需要的。这样数据只caching一次。

这将取决于您的环境，特别是我们正在讨论的服务器数量，服务器是否为64位，以及应用程序的稳定性。

我看到三个选项：

继续在隔离的应用程序池中运行所有内容，平衡所有服务器，并添加更多内存。
优点：健壮。
缺点：成本（但是这些天ram变得相当便宜）
整合到更less的应用程序池中，平衡您所有的服务器，而不是添加额外的RAM。优点：没有额外的成本。
缺点：如果应用程序存在稳定性问题，则将200个客户端整合到2个或3个应用程序池中是潜在的灾难性配方。如果您的负载平衡器可以正确检测到应用程序的可用性并将状态更改应用于所有URL，则可以减轻此风险。另外，如果这些机器是32位的，在单个应用程序池中运行100多个客户端可能会使您的处理内存限制极其危险。
继续在孤立的应用程序池中运行所有应用程序，将您的服务器场分成多个子服务器场，而不是让6个服务器服务200个客户端，每个服务器有2个服务器组，每个服务100个客户端以减less内存负载，而不是增加额外的内存。
优点：强大的，没有额外的成本（只要你有足够的服务器！）。
缺点：如果你没有至less4台服务器，这将是一个昂贵/不吸引人的select。此外，还会引入新的问题，例如必须跟踪哪些特定的客户端使用率过高，并在多个服务器场之间进行平衡。

最简单的解决scheme是首先将您的testing版网站移到自己的一组服务器上，然后再看看如何将当前用户分成多个组。

客户1,2,3,4全部在服务器a，b，c上进行。客户5,6,7,8全部在服务器d，e，f上进行

等等，这样你有冗余，你的客户负载均衡

如果你想用vmware esx来更加细致地研究可视化，所以你在一个集群中有3台服务器，然后根据需要build立尽可能多的Web服务器，甚至可以为每个服务器创build一个专用的虚拟服务器客户，但这更多是一个扩大解决scheme的规模