负载平衡 ASP.NET 站点的架构建议

StackOverflow https://stackoverflow.com/questions/613568

题

更新2009-05-21

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

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

结束更新

我收到了一份 ASP.NET 网站的提案，其工作原理如下：

硬件负载平衡器 -> 4 个 IIS6 Web 服务器 -> 具有故障转移集群的 SQL Server DB

问题是这样的...

我们正在选择存储 Web 文件的位置（aspx、html、css、图像）。提出了两种方案：

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

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

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

从角度来看，这是针对目前每月约 2000 万次点击量的网站而言的。在最近的高峰期，它每秒收到约 200 次点击。

如果您对此类设置有特殊经验，请告诉我。感谢您的意见。

更新2009-03-05

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

有帮助吗？

解决方案

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

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

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

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

其他提示

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

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

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

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

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

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

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

VPP for ZIP via #ZipLib 。

通过DotNetZip获取ZIP的VPP

在理想的高可用性情况下，不应出现单点故障。

这意味着一个带有网页的盒子是禁忌。在为一家大型电信公司完成 HA 工作后，我最初提出以下建议：

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

这就是您无需额外硬件即可实现的方法。在我工作的电信公司的肛门保留世界中，我们会这样做：

  • 我们会有八台服务器（当时，我们的钱多得你无法想象）。当过渡时间到来时，四个离线服务器将使用新数据进行设置。
  • 然后，HA 平衡器将被修改为使用四台新服务器并停止使用旧服务器。这使得切换（更重要的是，如果我们吃饱了，还可以切换回来）成为一个非常快速且轻松的过程。
  • 只有当新服务器运行一段时间后，我们才会考虑下次切换。在那之前，四台旧服务器一直处于离线状态，但已做好准备，以防万一。
  • 为了以更少的财务支出获得相同的效果，您可以拥有额外的磁盘而不是整个额外的服务器。恢复不会那么快，因为您必须关闭服务器电源才能将旧磁盘放回原处，但它仍然比恢复操作更快。

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

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

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

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

希望它有所帮助！

问候！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top