Basically we have many severs running many ASP.NET sites in different app pools. We roll updates every 2 weeks. My basic question comes down to this:
Is using the GAC codebase feature with a URL that we maintain the latest versions of the class libraries on an independent server a good approach to simple updates of all of these sites on all of these servers?
Is there any general pitfalls or potential issues that might arise with this?
I read the Download Cache is used on a per user basis. In this case would all the sites on the server simply use the version in the ASP.NET user download cache?
Would updates occur only when a site starts? What if One site is restarted and all the other sites are using the version in the Download Cache?
Is there anyway to also manage the .aspx/.js/.css/.ascx files in this manner?
I wouldn't like to trust that sort of update mechanism. It would be better to write a set of scripts, or use Web Deploy to push the updates to the servers in a much more controlled manner.
Simon
Related
We have a non-standard Kentico architecture which Kentico have advised is supported as long as synchronization of physical files between load balanced servers is disabled and handled manually. What is the correct way to manually synchronize web farm server files? I wondered about using a tool like DirSync but assume this would require one server to act as the primary, whereas with Kentico a new media file, for example, may be initially saved to any of the physical servers.
I'm hoping to identify a definitive solution to this issue. Thanks.
Kentico web farm by default synchronizes physical files automatically if the web farm is working properly. As each request can be served by different server Kentico serializes file binary into Database which is shared by all servers and then re-creates file on the server where it is missing.
I'm not aware of any situation where web farms are supported, but file synchronization isn't. It's either all or nothing, there is no middle solution.
Can you be more specific of why the synchronization of physical files is not working on your end? As long as all servers see the database (which they should otherwise the WF is not working at all) the file synchronization will work.
PS: If your files are not synchronized, go to Web farm -> Tasks application and check how many tasks are there. If there are no tasks (or very few which are being deleted constantly) then your web farms are working, if there are tasks older then few minutes then your web farms are not working at all.
I read the thread above and would recommend you take a look at this tool from BizStream: https://devnet.kentico.com/marketplace/modules/compare-for-kentico
I haven't gotten to play with it myself, but they are a top notch shop so I can bet its a top notch product.
Otherwise you are going to have to go the custom sync code.
We've tried to do moves via the SQL Tables and it is 'possible', but the amount of interconnected relationships just make it quite unrealistic to build or support.
Good day.
I'm wondering if the Enterprise Library Caching using isolated storage (disk, not DB) can be accessed by multiple apps in IIS? That is , can they all share the same instance of it.
I have various WCF services running on one machine, set up in different web apps (and potentially in different app pools, if that makes a difference). They all need access to a shared cache.
I had been told that this is possible with EntLib, but after doing some reading I'm not entirely sure this is the case. All of the services are running under NETWORK SERVICE user, but since they are all different apps in IIS does this prevent the sharing? I know having a different user certainly would.
So, can the same user use the same cache across multiple apps, or is it limited to within one app?
Any guidance would be appreciated!
If you want to share your cache across several services it would be better to go with App Fabric caching. See: http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
I ended up not using EntLib for this and just used isolated storage.
In case anybody has the same problem, you can see the following question where I posted the code I used, as well as an issue I hit while using it plus the resolution.
Can't share isolated storage file between applications in different app pools
I have a situation where information about a user is stored in the web application cache and when that information is updated in one application - I want to notify the other applications (running on the same machine) that the data should be removed from it's cache so it can be refreshed. Basically I need to keep cached data in sync across multiple asp.net applications.
I have started down the path of using a central web service to help coordinate the notifcations but it is turning out to be more complex than I think it needs to be.
Is there a way that one asp.net application can easily reach across to another on the same box to clear an item from the cache?
Is there a better way to achieve shared cached information than using the application cache?
I really want to create a way for apps to communicate in a loosely coupled way - I looked at nservice bus but the dependency on MSMQ scared me away - my client has had bad experiences with MSMQ and does not want to support an app that requires it.
Suggestions?
Michael
I agree with Hogan. Best is to use a shared database. I want to add to that that, when using SQL Server, you can use SQL Cache Dependency. This SQL Server mechanism allows notifications to applications in such a way that used caches can be invalided directly after a change is made to the data.
A shared database is probably going to cause you the least pain.
Edit
Note: ASP.NET allows you to make "cache clearing" triggers on SQL server changes. Should be a quick search in the cache examples on MSDN to find some examples. Thus when the user info stored in the cache changes in the DB the local cache copy will clear and be re-loaded from the DB.
There are commercial distributed caches available for .net other than Microsoft Velocity - NCache, Coherence, etc.
How about Velocity? It's a distributed cache that works between servers as well as between applications. It has PowerShell management and all sorts of documentation to get you going faster and be far more maintainable in the long-term.
What about COM/DCOM, using namespace System.Runtime.Remoting
What is the simplest way to distribute an asp.net web application? I tried to look at some of the open source asp.net projects out there to see how they distribute their apps and how they do updates and they seem rather complicated to me (not for myself to perform but for non-technical users). A lot of them entail backing up the entire installed project, deleting specific folders and save parts of their web.config. I am hoping to find a solution that will make the update process specifically as simple as possible.
Thanks.
I am working on a project with a similar requirement now. We decided to use WiX to create an installer that can be run on the server or machine where the site is installed. WiX is incredibly powerful, but takes a bit to get the hang of.
There are plenty of other open source, and paid installer technologies as well. Here is a post with some info on a few.
CommunityServer provides a setup msi that will create a virutal directory, generate the SQL database and populate it with default data. Updating for point releases though is still a manual process involving an update.sql file and having everyone download then merge binary and static file changes.
They probably could have created an update msi too, but because so many people customize CommunityServer, it is probably better to let people merge changes themselves.
Do you mean in terms of breaking up the functionality into tiers that could be handled on separate machines, e.g. having 3 servers for a 3-tier architecture where one is the DB server, one handles middleware and the other handles the requests in ASP.Net? Another point here would be in going from a web server to multiple web servers in terms of scaling up.
Or are you referring to deployment?
It's a web application, man. Serve it publicly, require registration, and move on. Isn't that the point of the web application?
Our company currently runs two Windows 2003 servers (a web server & a MSSQL 8 database server). We're planning to add another couple of servers for redundancy / availability purposes in a web farm setup. Our web sites are predominately ASP.NET, we do have a few PHP sites, but these are mainly static with no DB.
Does anyone who has been through this process have any gotchas or other points I should be aware of? And would using Windows Server 2008 offer any additional advantages for this situation (so I can convince my boss to upgrade :) ?
Thanks.
If you have dynamic load balancing (i.e. My first request goes to server X, but my next Request may go to server Y or Z), you will find out that In-Proc Sessions do not work. So you will either need sticky Sessions (your load balancer will ALWAYS send me (=my session) to server X) or out-of-process sessions (i.e. stored in an SQL Server).
Like Michael says, you'll need to take care of your session. Ideally make it lean and store out of process. You'll have similar challenge with cache depending on how you use it and might be interested in looking towards a more robust caching technology if you only use asp caching.
Don't forget things like machine keys and validation in your web.config. The machineKeys need to be consistant across your servers.
Read up on IIS7 and you should be able to pick out several good examples to show off to your boss.
A web farm can give you opportunities and challenges with deployment that should not be overlooked.
Without specifc experience to the setup above but to general moves of this kind. I would recommend phasing the approach. That is, move to Windows 2008 first and then farm.
One additional thing to look at is your deployment plan. Deployment plans seem to be sadly overlooked and/or undervalued. Remember that you are deploying to multiple nodes and you want to take into account how you want to deploy and test in a logical fashion.
For example, assume you have four nodes in your farm. Do you pull two out of the cluster and update and test, then swapping out the other two to repeat? Determine if your current deployment process fits in with the answer you provide. Just because you have X times the amount of servers does not mean that you want or need to do X times the amount of work.
Just revisiting the caching part of the conversation for a moment. You should definitely take a look at a distributed caching solution. If you are pre-caching data and using callbacks with cache removals, you can really put a pounding on the database if you are not careful. Also, a lot of the distributed caching solutions offer some level of session state management, as well. I have been very much enjoying Microsoft's Velocity project, although it is just a second CTP release and not ready for production.
In addition to what others have said, you might want to consider looking into Richard Campbell's (of .NET Rocks!) product:
http://www.strangeloopnetworks.com/
We use the ASP.NET State Server for handling out sessions. This comes free with windows server 2003/2008.
We then have to make sure the machine key's are the same (a setting in your web.config files).
I then manually take each site offline (using app.offline or whatever the magic file is called). Alternatively, u can use IIS and just turn the site off and the offline site 'on'.
That's about it. You could worry about distributed caching, but that's pretty hard-core stuff. You can get a lot of good millage out of the default Output Caching with ASP.NET. I'd start there, before you delve into the complexity (and cost, for some products) if you're going to do distributed caching.
Oh, we're using an F5 load balancer that does NOT do sticky sessions, so we need to maintain our sessions .. which is why we're using the ASP.NET state server.
One other gotcha aside from the Session issues described by the other posters is if the apps are writing to the local file system. Scaling out to a web farm would break the apps if they assume the files are on the local PC. For example, uploaded files might be available or not depending on which server is hit. Changing the paths to point to a shared drive should fix this.