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.).
Blogger Comment
Facebook Comment