I'm trying to find the best server architecture solution to deploy monthly updates to an Asp.net external public facing website. What I'm looking for are ways to release a new version of a website with minimal impact to users. Besides deploying the standard way (ie. stop IIS, copy new website over existing website, start IIS), what are some "better" solutions for deployment out there? It would be nice if they kept their session and didn't have to see a "Website under maintenance" message during the update.
My server configuration
We have 2 IIS web servers (2003) and are trying to figure out the best way to utilize them for deployments. My first thought was to update the non-active web server with the latest release. Then to gracefully point the web traffic to that server with minimal impact to users (best case, the user doesn't lose his session). How would you go about "repointing" the web traffic from server 1 to server 2? Changing firewall NAT? Changing DNS records? Some other way?? We need to be able to test the live site immediately after we release the new changes (duh).
BTW, we are using nant and cruise control to automate the builds, and a custom web service to deploy the build to production. So it's all automated with the click of a button.
Could a better solution be achieved using a 3rd server? If so how?
The way we do is
We have a load balancer from netscaler,
take one webserver out of loadbalancer , do all deployments, do a iisreset and the put back in load balancer.
Do the same thing for server2 .
Finally invalidate loadbalancer cache.
Well, there are a couple of things here:
First, consider using a load balancing solution. Windows 2003 server ships with windows load balancing (WLBS), though its not the greatest product. It is, though, free. With that, you can point all traffic to one server, update it, and then do the opposite.
Secondly, you may want to consider looking at how you're working with sessions. HTTP is stateless, which means that as long as you can reconstruct a user's session on any page hit, you should be fine. One ideal step towards this is using ASP.NET Forms Authentication - the cookie written by it isn't tied to an ASP.NET session. Of course, this approach leads to greater risk - there is a chance users will get an error screen if they hit something JUST AS you're copying files. And then there will be a delay while the app pool refreshes.
Overall, your better option is load balancing. Even with it, though, consider trying the second option as well - having sessions that can regenerate works well if users fail to be sticky to one of the servers in the pool.
Just wanted to add this for brevity. At my previous work, we achieved seamless deployments by using the following setup:
A load balancer would point to the production ASP.NET webservers (two in your case, but we had three), and the webservers would have their session setup to pull from a third server dedicated to hosting OutOfProc ASP.NET session.
To deploy a site, we'd pull one of the servers out of the load balancer, update the files, fire it back up, and place it back into the load balancer pool. Repeat for the rest of the webservers.
Because each webserver got the session data from the one central server, taking one webserver out, did not log out the users on that server.
If we had code changes that were incompatible with the existing session data, we'd wait till a scheduled maintenance window to deploy. Otherwise, users with that session data would get errors till they logged out.
Additionally, since this setup relies on the webserver being up, if you wanted to increase reliability, you could change the OutOfProc to SQL based session servers. You would need several servers that replicated the same session database and point the webservers to them. More complicated, but would reduce site downtime.
Related
I have experience developing software and web applications and I have decided to do some freelance work on the side. Well, I met with my first client and they are requesting a relatively simple, custom system that (without being long winded) tracks client’s paperwork as it progresses through the business’s different manual processes. It is a small business that has about 10 employees, but all of the employees will interact with the client’s paperwork, therefore everyone would need access to the new system. When I say ‘track’ I literally mean that the employees will ‘check as complete’ on a simple page the increases a progress bar at different stages for the paperwork. Now I am %110 capable of coding the custom system that meets their needs, but I am unsure about how I should go about doing it.
The information that is being tracked in the new system and stored in the DB is confidential information that they are very protective of. My main question is how should I be developing this to be as secure as I can?
-They have their own server in house, so should I develop an application (VB and SQL) for the server and require employees to log on remotely to use it? Can more than one person access/use the application at a time?
-Or should I develop a web application (ASP.Net/VB and SQL) that is only accessible on their network to their employees? They plan to expand offices, could they set up a VPN to access the site?
I’m leaning towards a web application, but I have not done too much in term of security. Basically I’m looking for pros and cons for either option or any suggestions on what I should.
PS, stackoverflow is awesome! Long time user, first time poster!
If you want to develop using vb & sql you have to consider that:
You need to have real ip
Your system will communicate threw certain port and you have to handle the security measure for letting certain port opened in your server.
You should have good knowledge in network programming
If you want to develop using asp.net you have to consider that:
in case only office employees will use the system, you can develop against users in Active Directory and for outside users with username and password with SSL connection or vpn
for preventing more than one person access the file you can simply add column 'locked' in case file is being used.
Well im not a web fan (I suck) ive seen too many security issues go with it...i.e Lulzsec, but i do very much love VB apps.
So I would definetely recommend a VB app connected to a MSSQL database (coz it's easy to configure and havent seen any security exploits yet),my Chinese friend told me there is a way to access MySQL free databases.Now, allow remote access but make sure your Windows Firewall is also configured properly do look at all angles of security.
If I remember well there is an option in MSSQL to specify the IP addresses or is it MAC addresses that can access the DB so maybe input all of the 10 employees' IP addresses assuming they are static,if they are dynamic (DHCP) don't bother. And ask them to make the IP address of the server where you will host the DB on static.
If only 10 employees use the DB then limit the connections to 10. For now develop this when it comes to VPN you can make a Remote version of the App im sure that will come later right now focus on the basics. Also use Dotfuscator when you are publishing the app I heard it is very good.N also im suggesting the document/work order is received at the reception so that user will check in the document with specifics...if they are passing on the work order to the next user they should select the user and then THAT user may enter some sort of verification code unique to the user...im sure you can envision the rest from here. Now do I also get a cut from this?lol
I've been doing the same for years now, and I always take the website side, this days I go width ASP.NET MVC 4, it's easier, everything in their place and extremely easier to test and maintain.
The web application has a very big advantage to any standalone windows application, you deploy and upgrade only one application instead to maintain all the different versions once you start deploying windows apps, and they are harder to debug once you start to having different machines with different versions and so on...
so, Web or Win app = Web app, always!
All you need is a server that run IIS and set it up for using Active Directory (Visual Studio has that project already, simply create an ASP.NET MVC and choose the "intranet" template), it will set up everything for you, and all you need later is tweak the Active Directory connection string.
I also use a self-signed SSL to protect data between client and server, as I also make the apps available outside the office without VPN needed, as long as they login with their secure AD credentials.
And... audit everything into a secondary database, every action performed by a user since they login until they logout, every view, update or creating data witch .NET makes it simple if you create your Logging method to simple log messages and Stack messages on errors.
This will greatly benefit your employer and you when something goes wrong.
I would say to go with web application. Advantage using web application is, if they want to expand bussiness .. same can you do with you WebApp. But choose .Net over VB, going with latest techonology will help you resolve current challanges.
I am looking at implementing caching in a .net Web App. Basically... I want to cache some data that is pulled in on every page, but never changes on the database.
Is my Cache Element unique to each:
Session?
App Pool?
Server?
If it is session, this could get out of hand if thousands of people are hitting my site and each cache is ~5k.
If App Pool, and I had several instances of one site running (say with a different DB backend, all on one server, though) then I'd need individual App Pools for each instance.
Any help would be appreciated... I think this data is probably out there I just don't have the right google combination to pull it up.
By default it is stored in memory on the server. This means that it will be shared among all users of the web site. It also means that if you are running your site in a web farm, you will have to use an out-of-process cache storage to ensure that all nodes of the farm share the same cache. Here's an article on MSDN which discusses this.
"One instance of this class is created per application domain, and it remains valid as long as the application domain remains active" - MSDN
I couldn't find anything about this online so I thought I'd ask here. Do any of you have issues with sessions just randomly clearing on a Windows 2008 Server environment? This problem is completely random and very unpredictable. I have no code that clears sessions except on logout, and not quite sure what could be causing it (well, I have ideas...)
My host, who I've been with for many years (and never had a problem with) is telling me that Windows 2003 is better at managing session variables and that I will likely be rid of this session clearing issue if I were to move to a 2003 Server environment. Thing is, I'm already set up and running on IIS 7 with the URL Rewrite module and I'd rather not move or reconfigure URL rewriting. Tech support says the App Pool I am running on is configured properly. My session timeout is set to 60 minutes in Web.config and my host tells me that session timeout is set to 60 minutes for my domain.
I could optionally go with an Azure AppFabric Cache for sessions but I'd rather not pay an extra $50 a month--it's a pretty small and low income site. I'm currently using a SQL Azure database but from what I hear, database sessions are not ideal on SQL Azure.
Thoughts?
Are you modifying any files in the web site?
Changes to the folder or file structure of the web site often triggers an app pool recycling, resetting sessions. The work-around is to use a durable session store like the SQL Server Session State provider.
Most likely answer is your app pool is recycling on you for some reason or another which will dump your in process session every time. Proximate causes can be lots of things, especially if app pools are shared. An easy way to see if your app pool is getting dumped is to take advantage of asp.net heartbeat monitoring, it could be configured to email you when these events occur.
What issues do I need to be aware of when I am deploying an ASP.NET application as a web farm?
All session state information would need to be replicated accross servers. The simplest way would be to use the MSSQL session state provider as noted.
Any disk access, such as dynamic files stored by users, would need to be on an area avialable to all servers. Such as by using some form of Network Attached storage. Script files, images and html etc would just be replicated on each server.
Attempting to store any information in the application object or to load information on application startup would need to be reviewed. The events would fire each time the user hit a new machine in the farm.
Machine keys across each server is a very big one as other people have suggested. You may also have problems if you are using ssl against an ip address rather than a domain.
You'll have to consider what load balancing strategy your going to go through as this could change your approach.
Sessions is a big one, make sure you use SQL Server for managing sessions and that all servers point to the same SQL Server instance.
One of the big ones I've run across is issues with different machineKeys spread across the different servers. ASP.NET uses the machineKey for various encryption operations such as ViewState and FormsAuthentication tickets. If you have different machineKeys you could end up with servers not understanding post backs from other servers. Take a look here if you want more information: http://msdn.microsoft.com/en-us/library/ms998288.aspx
Don't use sessions, but use profiles instead. You can configure a SQL cluster to serve them. Sessions will query your session database way too often, while profiles just load themselfs, and that's it.
Use a distributed caching store like memached for caching data, and ASP.Net cache for stuff you'll need alot
Use a SAN or an EMC to serve your static content
Use S3 or something similar to have a fallback on 3.
Have some decent loadbalancer, so you can easily update per server, without ever needing to shut down the site
HOW TO: Set Up Multi-Server ASP.NET Web Applications and Web Services
Log aggregation is easily overlooked - before processing HTTP logs, you might need to combine them to create a single log that includes requests sent to across servers.
My company has a website product (ASP.NET) which is sold to customers. It means we don't host the website. They install it on their server and run it in the intranet.
I need to implement some sort of copy protection mechanism so that not everyone ends up installing the website. It has following aspects:
It has to be completely software based (no dongles).
Hiding usage information in registry or some folder in c:\ (basically outside virtual directory) is not an option for a website
Please can you suggest any scheme/method?
One suggestion is to use some kind of web service running, of course you need to have a main server to do so. In this server you can have some of your clients servers data (IP of the authorized servers, CPU and Motherboard ID's, and other important data).
This web service has to run some important logic of the program and return a value to the authorized servers. If the data of autorization sent by the client doesn't match, the server do will not execute the routine.
Of course I assume that this side of the logic is included in a DLL in the application and not in plain code.
A technique that worked well for a buddy of mine was to install a web bug on an administrative page which would report back to their server. You can monitor when and where the application is installed. It could be easily removed, but won't by most customers.
Simple, easy to do, and works relatively well.
Something you could try. Compile binaries for each client, obfuscate the code, lock the site down to a single domain. If its an internal app the domain might be something like "productname.clientname.internal". The app checks the domain of all the incoming requests, refuses anything that doesn't match.
As already pointed out by jeffamaphone: people will find ways around it, but it's enough to 'slow down' those not super determined.
[disclaimer]I sell the product I am recommending.[/disclaimer]
Take a look at DeployLX. You can add licensing to your web based application to require one of a couple different options.
Hardware based locking so it can only be used on one machine.
Domain based locking so it's tied to a specific domain name.
IP based locking to tie it to an IP address.
License server locking to that your app checks in periodically with a centralized web service.
It's pretty flexible and should let you create a balance between protection and not frustrating your users.