问题描述
我们将.net Web应用程序部署在六台服务器(每台都有一个副本)中以获得更好的性能，当然，我们拥有负载平衡硬件，因此来自客户端的请求将分派到其他服务器.
现在，我们发现应用程序中有一些更新时这很简单，我们必须将更新的文件一张一张地复制到六个服务器上.
所以我想知道您如何在iis下进行负载平衡，以及如何使文件更新变得更简单?
您在这里有很多选择.您选择的选择将取决于您的情况和组织中已部署的适当流程.当然，任何解决方案都有其优缺点，因此您需要根据自己的情况来权衡每个方案.我已亲自使用以下各项:
您的第一个选择是在网络驱动器上创建一个共享存储位置，以保存您的内容.此功能内置于IIS服务器(6.0+)中.这样一来，您的网站就可以为您的Web代码指定一个位置，从而使部署成为单个x副本部署.这种方法的优点是，您可以通过标准网络共享将内容设置为只读.您必须具有可靠且冗余的网络基础结构才能实现此选项，因为在服务器启动时由于某种原因或其他原因而无法在某些服务器上获取内容时，我已经看到了一些问题.IIS会在启动后从共享中缓存信息，这有很多原因，但是如果您的网络出现故障，这会有所帮助.您还可以在服务器级别而不是应用程序级别使用共享配置(请参见http://learn.iis.net/page.aspx/211/shared-configuration/).
第二个选项是使用Web Deploy 2.0实现解决方案(免费:请参阅 http://www.iis.net/download/WebDeploy ).使用此框架进行部署可以轻松轻松地创建适合组织过程的解决方案.您可以相当容易地创建一个自动部署解决方案，但是您将需要在如何从应用程序团队接受要部署的软件包方面制定标准，以使实施解决方案变得一致且可重复使用.
第三个选项是使用诸如"Repliweb"之类的产品实施解决方案，该产品可处理整个Web场中的网站和内容同步.Repliweb和类似产品具有非常强大的部署选项.这些产品不是免费的，但提供的好处是您无需花费时间直接在内部进行开发(例如，允许开发团队根据触发器文件部署应用程序而无需访问IIS服务器或让管理人员参与(有Microsoft提供了一种产品，但现在已经停产了，称为Application Center 2000，该产品的许多功能已在上面的WebDeploy选项中实现，尽管有更多的实践方法.>
第四个选项是使用用于IIS的Microsoft.Web.Administration API开发自定义解决方案.到目前为止，此选项是必须自定义的，但还需要在技术上进行较大的投资，并且非常依赖于负责部署应用程序的技能水平和人员以及是否有明确定义的流程来打包要部署的应用程序，等等.我已经开发出了一种使用这种方法的解决方案，该方法可以管理200多个服务器场(分为至少4个服务器的集群，每个集群在负载均衡器后面，每个集群在每个集群中托管许多应用程序，因此是一个堆叠环境).这使我们可以选择在整个组织中使用一个单一的部署界面，从而可以以最小的工作量在其中部署Web应用程序以及非Web应用程序(例如Windows服务).此解决方案是由于特殊需要而开发的，因为Microsoft宣布了Application Center产品的生命周期终止，我们已经采用了围绕Application API和命令行选项的部署方法.MS当时没有该产品的替代品，这使我们问我们现在该怎么办?所以我们走了这条路.我还必须提到，MS尚未宣布或发布WebDeploy框架，否则我们将围绕上面选项2中提到的框架编写解决方案.
同样，您有多种选择，并且如上所述，根据您的流程和环境的设置方式以及每种选择可能受到哪些限制(无论是成本，禁止Windows共享的网络限制等)，这些选项都会有所不同.
欢呼
We deploy our .net web application in six server(each with one copy) to get the better performance,of course we have the load balance hardware,so request from client will be dispatched to different server.
Now we found that it is trivial when there is some update in the appliation,we have to copy the updated file to six server one by one.
So I wonder what is your practice to do the load balance under iis,and how to make the file update in my suitation more simple?
You have a number of options here. The selection you choose will be dependent on your situation and processes you have in place for deployments at your organization. There are of course pros and cons to any solution, so you need to weigh each according to your situation. I have personally used each of the following:
Your first option is to create a shared storage location on a network drive to hold your content. This feature is built into the IIS Server (6.0+). This allows your site to have a single location for your web code making deployments a single x-copy deploy. The advantages to this approach is that you can make your content readonly via standard network sharing. You must have a reliable and redundant network infrastructure in order to implement this option as I have seen some issues when servers are unable to get the content on some of the servers for one reason or another at startup causing issues. IIS caches the information from the share once started for a number of reasons, but this helps if your network hiccups. You can also use a shared configuration at the server level instead of the application level (see http://learn.iis.net/page.aspx/211/shared-configuration/).
The second option is to implement a solution with Web Deploy 2.0 (free: see http://www.iis.net/download/WebDeploy). Deploying with this framework allows you to create a solution that is suited for your organizational processes easily and robustly with minimal effort. You can create an automated deployment solution fairly easy but you will need to have standards in how you accept packages for deployment from your application teams to make implementing solutions consistant and re-usable.
The third option is to implement a solution with products such as "Repliweb" which handle synchronizing website and contents across you entire web farm. Repliweb and similar products have very robust deployment options. These products are not free but offer benefits that you wouldn't need to spend time developing in house out of the box (such as allowing development teams to deploy applications based on trigger files without needing access to the IIS servers or involving administration staff (there are many options to configure deployments). Microsoft had a product that they sold, but is now end of lifed called Application Center 2000 which many of the features have been implemented in the WebDeploy option above, albeit a much more hands on approach.
The fourth option, is to develop a custom solution using the Microsoft.Web.Administration APIs for IIS. This option is by far the must customizable but also requires a bigger investment in technology and very dependent on the skill level and staff that are tasked with deploying the applications and whether or not there are well defined processes in place for packaging applications for deployment, etc. I have developed a solution using this method that manages a farm of 200+ servers (divided into clusters of at least 4 servers each behind load balancers, each cluster hosts many applications per cluster and as such is a stacked environment). This gave us the option to have a single deployment interface for the entire organization in which to deploy web applications as well as non-Web applications such as windows services, all with minimal effort. This solution was developed due to a special need as Microsoft announced end-of-life for the Application Center product which we had a deployment methodology wrapped around the Application APIs and command line options. MS did not have any replacement for this product at the time, which left us asking what do we do now? So we went this route. I also must mention that MS hadn't announced or released the WebDeploy framework yet or we would have wrote our solution around that framework mentioned in Option 2 above.
Again, you have many options to choose from and as mentioned, will be different based on how your processes and environment is setup and what restrictions may limit each option (whether it be cost, network restrictions disallowing windows shares, etc.).
Cheers
这篇关于更新我的应用程序时如何使多服务器中的文件同步的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！