I have been struggling with the best way to make sure that the certain XML configuration files stay synchronized between multiple servers in a Web Farm. I am not necessarily concerned about the Web.Config, as much as I am concerned about some of the other configuration files that are present in the application.
For example, we store caching policies in an external XML file, where it has its own schema, and will soon have its own tool to maintain the values. Once the changes are applied, they should be migrated across the farm.
Some scenarios that I have considered so far:
RoboCopy, replication, or equivalent. This requires that work only ever be done on a particular node of the farm. (Push to application.)
Configuration Server. All external configurations and their tools are stored on a physical instance of IIS. The application will retrieve these configuration files on application start and periodically poll for changes. (Application polls.)
Team Build. We could host the tools in-house and set up a post-build process to deploy the files. (Application polls.)
Database Storage. Applications could read and poll database for configuration. (Application polls.)
All of these scenarios have their pros and cons. I am not sure what the best solution is, although I think having the application poll for changes might be the cleanest approach. Still, the question is which way would you best consider this to be accomplished?
I have web cluster running Windows Server 2008. To keep everything synchronized I'm using a DFS share that is on each of the members. Any changes made to any of the members are replicated to the others. I'm also using the IIS "Shared Configuration" feature to store my metabase within this DFS share. That way all of the IIS settings are replicated as well.
On a project that I worked on, we used a product called ServerSync to replicate files on the farm. It works pretty good and it is -fast-.
Related
We've quite a big project at work which sometimes needs to be published during the day. However, the application will (of course) crash during publish and show errors. (because the /bin is being overwritten)
Is there a way to avoid this? Sometimes a publish takes up to 3-4 minutes.
I know I can use the app_offline.htm file to display a message instead of them seeing the actual errors.
There isn't a way to have 0 downtime on a deployment. But you have some options
Deploy a pre-compiled site
To speed up the time taken for a site to be active after deployment, you can use ASP.NET Web Site Pre-compilation. This process will package the site so that it will not need to be compiled on-the-fly after deployment.
Benefits
Faster site startup
Less assets to deploy
Can be packaged via the Web Deployment Tool
Drawbacks
Debugging can be harder as the names are scrambled; Debug mode can be turned on for it though
You cannot edit a pre-compiled site; you must do a full re-deployment
You should still use the app_offline.htm so avoid yellow-screen-of-death errors
Add another web server
The best option for these scenarios is to have 2 servers with a load balancer in front of them. Then this way you use the load balancer to redirect active traffic to one node while the new application is being deployed.
Benefits
Parallel deployments do not affect the existing site
Have double the capacity for future expansion
Load balancing allows the load to be spread evenly across servers.
Drawbacks
Session now needs to be stored out-of-process. Therefore, you must check you can switch to an out-of-process session storage to confirm you do not have any serialization problems. StateServer is a quick one to get started with locally.
More maintenance overhead for a deployment, as you need to include load balancing configuration as part of your deployment processes. Network Admins are normally familiar with this.
One of our clients has a Java EE application. We would like to develop a new project using ASP.NET/C# by hosting the application as a sub directory under this Java EE project.
My questions are:
Will the .NET application run smoothly?
Do I need to keep anything in mind before I make a promise to the client?
The way you strucure your projects do not affect the behavior of your applications at all.
However in the end, each of the compiled and not compiled resources need to be configured propoerly to their proper Web Server, you shouldn't have any problem at all.
IIS has its own directory and Tomcat(or whatever you are using) will have its own directory.
Just let him understand that there is no sense on sharing the projects in a single root folder if the projects are not going to be related at all.
The only way to make them interact is by means of services and queues that you can orchestrate in any of both technologies.
UPDATE
let's suppose that:
you are using default of both web servers: your IIS need your applications to be copied to c:\inetpub folder whereas tomcat uses the $CATALINA_BASE system variable to locate their own folder. That won't be a problem at all.
Now, let's suppose that your client chose the same exact folder to be the root of your websites in tomcat and iis, (very bad maintenance decision by the way)
you could also separate both environments by having two folders : JAVA and DOTNET
Now let's suppose your client won't accept any logic suggestion, and you have to merge java files and aspx files, technically there won't be any issue because each web server will handle requests for very different issues, however, if you are also using the same resources, let's say a picture used in both pages, you will have locked-files issues, your iis can only respond for its own behavior and tomcat will only respond with its own behavior.
So in summary, technically speaking it could work, performance will be hit on your hard drive, it all depends on the request loads of each app, but overall it is a bad infrastructure design.
hope it helps,
I have an existing ASP.NET website that I would like to port to Azure within my free trial.
I would like the migration to be as painless as possible. The application uses log4net and NHibernate, plus it needs to share data with an application supposed to run on a virtual server.
Two questions can be asked as 1
How do I configure paths in Web.config to access a shared drive?
I need to configure the paths into which logs will be stored and, most important, I have to specify where the application will read the files written by the daemon that will run on my Azure Linux VM.
When both the app and the daemon ran on the same server (yes, I had Mono running fine) I just had to choose a shared local directory.
I'm not sure I'm totally understanding the scenario, but I'll try to give you a few options.
One - Windows Azure Web Sites (currently in Preview) could be a great option for your ASP.NET site. Of course, it depends what needs your site has. But, you can write your log4net files with web site and using NHibernate too.
Two - Web roles work great for situations like this. You would likely have to change some code to use blob storage for persistant file storage. You could use Windows Azure drives as a way to get a persistent location for log files. Windows Azure drives don't have a pre-determined drive letter, so you'd want to use the API to get to that. That may, or may not, be a good option for your situation. With web roles you could also write the log4net files to local storage and use Windows Azure diagnostics to transfer them periodically to blob storage. Just another way to persist the files.
Three - Using Windows Azure Virtual Machines (currently in Preview) you could write the log files to a data disk, which is backed by blob storage.
In the end, if you have files you need to share across instances and/or roles, then leveraging blob storage is likely your best option.
I currently work with a legacy asp.net web application and one of the requirements going forward is that it be deployable to windows azure.
I would like to know how difficult it will be to manage deployment to both Azure and a traditional IIS web server.
Azure seems to require a specific customized version of a web applicaiton project is it possible to deploy the customized web application to a standard IIS instance once it has been converted.
EDIT:
It is a ASP.NET Web Application rather than a Web Site (compiles everything into one dll)
UPDATE:
In the end due to the amount of work involved in converting the application to work in Azure and the cost of Azure compared with other cloud solutions it was decided to go with a traditional Cloud hosted virtual server.
And thank you for the really good answers.
Whether or not you can deploy your application to Azure almost as is depends a lot on how your application works. Azure pretty much requires your application be stateless. If it's a plain vanilla web application that stores data in the session or application cache only and saves data to a database only, then you can deploy it to Azure.
If you have stateful services running like background threads (which is bad anyways), or if you save data to the file system (besides temporary caching), then you may have issues. Really, the issues moving to Azure are really the same as moving to any multi-server load balanced solution. One caveat is permanent storage.
If you need to store data in a place other than the database, then you're best off working with Azure's storage solution which has an API and client library for storing binary data, key/value data (they call it tables, but really, it's not tables), and queues. They also do have a transparent blob-as-file-system option for compatibility. If you want to use these in your app that also is used outside of Azure then you need to write an extra layer between your code and the Azure client library that supports both Azure services and standard local service. Azure SDK does include emulators for Azure services, but they're definitely not meant for production use.
As far as the mechanics of Azure-specific projects, that is actually not that difficult. Yes, you need to create an Azure-specific project in your solution that defines the Web Role and what gets deployed, but it will reference your existing Web Application, not the other way around. You can deploy the Azure Web Role to Azure or you can continue to deploy the existing application to IIS normally and concurrently.
Web Site, Web Application, MVC, really doesn't make much of a difference. Actually doesn't have to be .NET either. Can be PHP or Java or whatever you want to put on your VM. It'll all work the same as far as Azure is concerned.
MS likes to push Azure as a Platform-as-a-Service (Paas) solution where they have a ton of services they offer and you run apps on their standard platform, and contrasts that with Amazon AWS which they call Infrastructure-as-a-Service (Iaas) which is "just" a Virtual Machine. However, MS is really just as much a IaaS solution as AWS, perhaps even more so. The only difference between AWS and Azure is AWS allows you to choose what to install on your VM and with Azure you have to use Windows Server 2008 R2 as the basis for your VM (but you can customize the VM image to install custom software on top of windows). With both Azure and AWS, the hosts offer additional PaaS services you can take advantage of for data storage and message routing. AWS also offers tons of extra services like video streaming.
Also note that with Azure (and AWS I think) you can use the services they offer even in a non-hosted application. If you want to use Azure's data storage from a non-Azure application, you can do that, it's just HTTP REST calls to get/put data. The only differences you pay for data in/out between datacenter and your non-datacenter-hosted application which would be free if the app was also inside the datacenter (just the data in/out is free in-datacenter, you still have storage and transaction fees).
A few things:
Samuel Neff's answer mentioned mounting a file system in a blob (a Cloud Drive). Only one instance may lock this cloud drive for writing, so it does not behave like a network file share. You'll need to plan for this.
You'll need to integrate with the Windows Azure diagnostics subsystem, to gain visibility into your app's run state (e.g. performance counters, trace logs, etc.).
If there are 3rd-party apps that your web app depends on, you'll need to install these. These actually get installed as part of the role instance's boot process, either via your OnStart() event handler or as a startup task. The latter allows for admin-level installs (including registry changes, COM component installations, etc.). You'll need to carefully manage these installations, as they impact the boot time of the instance.
For an asp.net app, you'll need to think about session state. In-proc session state won't work, because each instance will have its own state store in memory. The SQL Azure session state provider doesn't have background cleanup agents, so you'll need to build this into your web or worker role instance (see this blog post by the SQL Azure team for the implementation). The best option is to use the AppFabric Cache, a new service that just went into production. This cache-as-a-service provides an custom session state provider for asp.net as well. Note: As of today, the AppFabric Cache service is only accessible via a .NET interface; there's no REST interface for it (all other storage services - tables, blobs, queues - have a REST interface). .NET, Java, and PHP all have storage client libraries. Ruby has one from the open source community.
You'll have to manage scaling out to more than one instance, when the need arises. This is not a built-in service today, but there are 3rd-party services such as ParaLeap's AzureWatch. There's also Microsoft's System Center Operations Manager, which now has Windows Azure monitoring support. You'll also need to handle scale-back situations, where you reduce the number of server instances.
I have some additional details in an answer for a similar StackOverflow question, here.
I have not tried Windows Azure Migration Scanner personally, but if it works as advertised, this would really come in handy.
We need to deploy our asp.net web site in web farm which consists of 16 web servers. Whenever we need to roll out a new release it is very time consuming and tedious as we need to deploy it first on the DR environment (16 web servers) and then on to Live environment (16 web servers).
Currently we prepare the msi on our build server and copy it on all the front end web servers which involves first FTPing the msi to a common location on hosting network and then copying from the common location to each server.
After thet we backup the existing website and then run the installer one by one on each machine.
After installing the new version we replace the web.config file with the older one as it is encrypted and hardly contains any new thing in it as part of new release. This saves us from encrypting the web.config file again.
Could somebody please suggest a better way of doing this deployement as it is really turning out to be time consuming. Previously this model was ok for us as we had only 4 web servers but not it is no longer a sutable option.
Thanks..
Take a look at the Web Farm Framework. It will handle the replication of your application across your entire farm.
Another option is to use the "Shared Configuration" option in IIS7 as well as a DFS share to replicate all of your files and metabase configuration. This just won't handle registry changes or the GAC.