负载平衡的ASP.NET站点的体系结构建议

Question

更新2009-05-21

我一直在测试使用单个网络共享的＃2方法。这导致Windows Server 2003在加载时出现一些问题：

http://support.microsoft.com/kb/810886

结束更新

我收到的ASP.NET网站提案如下：

硬件负载均衡器 - ＆gt; 4个IIS6 Web服务器 - ＆gt;带有故障转移群集的SQL Server数据库

这是问题......

我们选择存储网络文件的位置（aspx，html，css，images）。有两种选择：

1）在4台IIS服务器上创建相同的Web文件副本。

2）将Web文件的单个副本放在4个Web服务器可访问的网络共享上。 4台IIS服务器上的webroots将映射到单个网络共享。

哪种解决方案更好？ 选项2显然更易于部署，因为它只需要将文件复制到一个位置。但是，我想知道是否存在可伸缩性问题，因为四个Web服务器都访问一组文件。 IIS会在本地缓存这些文件吗？它会在每个客户端请求中达到网络共享吗？ 此外，访问网络共享总是比获取本地硬盘驱动器上的文件慢？ 如果添加更多IIS服务器，网络共享上的负载是否会变得更糟？

为了给出观点，这是针对一个目前每月点击量达到约2000万次的网站。在最近的高峰期，它每秒接收约200次点击。

如果您对此类设置有特殊经验，请与我们联系。感谢您的投入。

更新2009-03-05

为了澄清我的情况 - 此系统中的“部署”比典型的Web应用程序更频繁。该网站是后台CMS的前端。每次在CMS中发布内容时，新页面（aspx，html等）都会自动推送到实际站点。部署基本上是“按需”。从理论上讲，这种推动可能会在一分钟或更长时间内发生几次。所以我不确定一次部署一个Web服务器是否切实可行。想法？

Answer 1

我将共享4台服务器之间的负载。不是那么多。

在生产中部署或单点故障时，您不希望出现单点争用。

部署时，您可以一次执行1个。您的部署工具应通过向负载均衡器通知不应使用服务器，部署代码，所需的任何预编译工作以及最终通知负载均衡器服务器已就绪来自动执行此操作。

我们在200多个Web服务器场中使用了这种策略，它可以很好地部署而不会中断服务。

Answer 2

如果您的主要关注点是性能，我认为这是因为您将所有这些钱花在了硬件上，那么为了方便起见共享网络文件系统并没有多大意义。即使网络驱动器性能极高，它们的性能也不如本机驱动器。

无论如何，部署您的网络资产都是自动化的（对吗？），因此以倍数进行此操作并不会造成太大的不便。

如果它比你让它更复杂，那么像DeltaCopy这样的东西对于保持这些磁盘同步很有用。

Answer 3

中央共享不好的一个原因是因为它使共享服务器上的NIC成为整个服务器场的瓶颈，并造成单点故障。

Answer 4

使用IIS6和7，明确支持在N个连接的Web / app服务器计算机上使用网络单一共享的方案。 MS进行了大量的性能测试，以确保此方案运行良好。是的，使用缓存。使用双网卡服务器，一个用于公共互联网，一个用于专用网络，您将获得非常好的性能。部署是防弹的。

值得花时间对它进行基准测试。

您还可以评估ASP.NET虚拟路径提供程序，它允许您为整个应用程序部署单个ZIP文件。或者，使用CMS，您可以直接从内容数据库而不是文件系统提供内容。这提供了一些非常好的版本控制选项。

VPP For ZIP via #ZipLib

VPP for ZIP via DotNetZip

Answer 5

在理想的高可用性情况下，应该没有单点故障。

这意味着单个包含网页的方框是禁忌。在为一家大型电信公司完成HA工作后，我最初会提出以下建议：

• 四个服务器中的每一个都拥有自己的数据副本。
• 在安静的时间，将两台服务器脱机（即修改HA平衡器以将其删除）。
• 更新两台离线服务器。
• 修改HA均衡器以开始使用两个新服务器，而不是两个旧服务器。
• 测试以确保正确。
• 更新另外两台服务器，然后将它们联机。

如果没有额外的硬件，你就可以做到这一点。在我工作的电信公司的肛门保留世界中，这就是我们本来会做的事情：

• 我们本来应该有八台服务器（当时，我们有更多的钱，而不是你可以用一根棍子）。当转换时间到来时，将使用新数据设置四个脱机服务器。
• 然后将修改HA平衡器以使用四个新服务器并停止使用旧服务器。这使得切换（更重要的是，如果我们填满了切换）是一个非常快速和无痛的过程。
• 只有当新服务器运行一段时间后，我们才会考虑下一次切换。直到那时为止，这四台旧服务器仍处于脱机状态，但以防万一。
• 要以较少的财务支出获得相同的效果，您可以拥有额外的磁盘，而不是整个额外的服务器。恢复速度不会那么快，因为您必须关闭服务器以重新放入旧磁盘，但它仍然比恢复操作更快。

Answer 6

我负责一个每月有6000万次点击的游戏网站的开发。我们这样做的方式是选项＃1。用户确实能够上传图像等，并将这些图像放在服务器之间共享的NAS上。它运作得很好。我假设您正在进行页面缓存等等，在应用程序端。我也会按需部署所有服务器的新页面。

Answer 7

你使用4IIS在NLB上获得了什么，你使用带有应用服务器的BottleNeck将其丢失。

为了扩展性，我会推荐前端Web服务器上的应用程序。

我公司正在实施该解决方案。前端的.NET应用程序和Sharepoint的APP服务器+ SQL 2008群集。

希望它有所帮助！

问候！

Answer 8

使用部署工具，其中一个进程一次部署一个，系统的其余部分继续工作（如Mufaka所说）。这是一个经过尝试的过程，可以处理内容文件和应用程序的任何已编译部分（部署会导致asp.net进程的循环）。

关于更新率，这是您可以控制的。让更新通过队列，并具有控制何时部署每个项目的单个部署过程。请注意，这并不意味着您单独处理每个更新，因为您可以获取队列中的当前更新并将它们一起部署。进一步更新将到达队列，并在当前更新集结束后将被接收。

更新：关于评论中的问题。这是一个基于我对重/长过程的经验的定制解决方案，需要控制其更新速率。我没有必要将此方法用于部署方案，因为对于这样的动态内容，我通常会在不同级别上使用DB和缓存的组合。

队列不需要保存完整信息，只需要拥有适当的信息（ids / paths），让您的流程通过信息通过外部工具启动发布流程。由于它是自定义代码，您可以将其加入要发布的信息，因此您不必在发布过程/工具中处理它。

数据库更改将在发布过程中完成，您只需要知道所需更改的信息位置，并让发布过程/工具处理它。关于如何使用队列，我使用的主要是msmq和sql server中的info自定义实现。队列就在那里控制更新速率，因此您不需要任何专门针对部署的内容。

更新2：确保您的数据库更改向后兼容。当您将更改实时推送到不同的服务器时，这非常重要。

Answer 9

我们也有类似的情况，我们的解决方案是使用发布者/订阅者模型。我们的CMS应用程序将实际文件存储在数据库中，并在创建或更新文件时通知发布服务。然后，该发布者通知所有订阅的Web应用程序，然后他们从数据库中获取文件并将其放在其文件系统上。

我们已将订阅者设置在发布者的配置文件中，但您可以全力以赴，让网络应用程序在应用启动时自行完成订阅，以便更轻松地管理。

您可以使用UNC进行存储，我们选择了数据库以方便和生产与测试环境之间的可移植性（我们只需复制数据库，我们拥有所有实时站点文件以及数据）。

Answer 10

部署到多个服务器的一种非常简单的方法（一旦节点设置正确）就是使用robocopy。

最好有一个小型的临时服务器进行测试，然后你“抢夺”所有部署服务器（而不是使用网络共享）。

robocopy包含在MS ResourceKit中 - 与/ MIR开关一起使用。

Answer 11

为了给你一些思考的食物你可以看一下像Microsoft's Live Mesh 这样的东西。我不是说这是你的答案，但它使用的存储模型可能是。

使用Mesh，您可以在网格中的每台Windows机器上下载一个小型Windows服务，然后在系统上指定属于网格的文件夹。将文件复制到Live Mesh文件夹时 - 这与复制到系统上任何其他文件夹的操作完全相同 - 该服务负责将该文件同步到所有其他参与设备。

作为示例，我将所有代码源文件保存在Mesh文件夹中，并让它们在工作和家庭之间同步。我不需要做任何事情来保持它们在VS.Net，记事本或任何其他应用程序中保存文件的操作同步启动更新。

如果您的网站有频繁更改的文件，需要转到多个服务器，并且可能是这些更改的多个作者，那么您可以将Mesh服务放在每个Web服务器上，并且作为作者添加，更改或删除文件更新将自动推送。就作者而言，他们只是将文件保存到计算机上的普通旧文件夹中。

Answer 12

假设您的IIS服务器运行的是Windows Server 2003 R2或更高版本，请务必查看DFS Replication。每个服务器都有自己的文件副本，这消除了许多其他人警告过的共享网络瓶颈。部署就像将更改复制到复制组中的任何一个服务器一样简单（假设是完整的网状拓扑）。复制自动处理其余部分，包括使用远程差分压缩仅发送已更改的文件的增量。

Answer 13

我们非常高兴使用4个Web服务器，每个服务器都有一个本地页面副本和一个带有故障转移群集的SQL Server。