Suppose a user's session is load balanced to server #8 and some state is maintained at server #8. The next action from user needs to be routed to server #8 again because that is the only place with his server state. Is there a standard solution to maintain this mapping from user session to server number for long lived sessions? It seems like this problem of mapping user session to a specific server among many servers should be a common problem with a standard "textbook" solution thats cpu and memory efficient.
An easy solution is to configure your load balancer to use sticky sessions. the load balancer will associate a user session to Server #8, and then subsequent requests from the same session will automatically be forwarded to the same server (Server 8).
The best solution is not to rely on server affinity - it makes your system fragile. I wouldn't expect a textbook answer in the same way I would not expect a textbook answer on how to play with a toaster in the bath nor how to perform brain surgery with a screwdriver.
If you must have sticky routing then how you implement it depends a lot on how you propose to deal with a server not being available - do you failover the requests? Or just stop processing requests which would have been directed to that server?
I initially thought that this was a very dumb question - what's the relevance unless you're writing your own proxy/load-balancer (in which case you should already know he answers) but there are proxies available which allow you to implement your own director.
So ultimately it boils down to what characteristics of the session are visible in the HTTP request. Since an IP adderss can change mid stream, the only practical characteristic you can use is the session idenitifier - usually implemented as a cookie.
Related
Cant find this issue anywhere...
Using ASP.NET 3.5, I have 3 web servers, in a web farm, using ASP.NET State Server (on a different Server).
All pages Uses session (they read and do update the session)
Issue: my pages are prone to DDOS attack, it so easy to attack, just go to any page, and HOLD down 'F5' key for 30-60 seconds, and the request will pile up in all web servers.
I read, that if you make multiple call to session each will LOCK the session, hence the other request has to wait to get the same user's session, this waiting, ultimately causes DDOS.
OUR solution has been pretty primitive, from preventing (master page, custom control) to call session and only allow the page to call, to adding javascript that disable's F5 key.
I just realize ASP.NET with session is prone to such DDOS attacks!!
Anyone faced similar issue? any global/elegant solution? please do share
Thanks
Check this:
Dynamic IP Restrictions:
The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.
Also, Check this:
DoS Attack:
Most sites/datacenters will control (D)DOS attacks via hardware not software. Firewalls, routers, load balancers, etc. It is not effeicent or deesirable to have this at the application level of IIS. I don't want bloat like this slowing down IIS.
Also DDOS preventation is a complex setup with even deadicated hardware boxes just to deal with it with different rules and analysis for them that take a lot of processing power.
Look at your web enviornment infrastucuture and see the setup and see what your hardware provides as protection and if it is a problem look at dedicated hardware solutions. You should block DDOS attacks as soon as possible in the chain, not at the end at the webserver level.
Well, for the most elegant solution; it has to be done on network level.
Since it is "nearly" impossible to differentiate a DDOS attack from a valid session traffic, you need a learning algorithm running on the network traffic; most of the enterprise level web applications need a DDOS defender on network level. Those are quite expensive and more stable solutions for DDOS. You may ask your datacenter, if they have a DDOS defender hardware and if they have, they can put your server traffic behind the device.
Two of the main competitors on this market :
http://www.arbornetworks.com/
http://www.riorey.com/
We had the same issue at work. Its not solved yet but two workarounds we were looking at were:
Changing the session state provider so that it doesn't lock
session. If your application logic would allow this...
Upgrading the session state server so that it was faster (SQL 2016 in-memory session state for example). This makes it a little harder for users to cause issues and means your app should recover faster.
I am building a service which requires me to dynamically launch and close servers at many locations around the world, (for example using AWS). When a user visits my domain they need to be assigned to a local server with the lowest latency.
By assignment, I mean that for example the client makes an ajax call to example.com/getData, it should go directly to one particular server that is has been assigned to. Different servers will be doing different computation, so it is not sufficient to have some kind of general load balancing.
What general mechanisms/technology would allow me to 1) Assess the latency between a particular client and any server under my control? 2) Assign a particular client to a particular server? I cannot use just the IP addresses for example, since javascript has domain name based restrictions.
Thanks
Note: I do not have enough reputation to link all the technologies in the response, therefore sometimes you will see the links copied in plain text.
1) Assign users to a local server with the lowest latency is not always possible.
Sometimes the geographically closest server to a user is unexpectedly the one with the highest latency.
To find the lowest latency between your (running) servers and the users is not an easy task.
There might be many different hops (routers) between the client and the server, and any of them at any time can have problems, routes update, packet congestions and so on.
The quickest way to assess the latency is a ping, but it can be that the firewalls block this.
So the best way to achieve this is to use the anycast
All the major CDN providers implement this method. Some use the TCP anycast, which seems to be not recommended, and others UDP anycast. It is an open debate.
Anyway in order to implement anycast you need to be able to peer with the ISP routers, and normally this is not possible. Additionally there are good peers and bad peers.
Finally All this requires a deep knowledge of the routing protocols and the TCP/IP stack.
A quick and dirty solution could be to use BIND with the GEO-IP patch.
So you can define specific dns query responses per country.
What I mean is that, for instance, if you have a server in UK and one in US you can configure BIND to respond to users coming from europe to hit the UK server and users coming from US to hit the US server.
2) To assign a particular client to a particular server you can use the technique I described on the point 1 or you can use a proxy and sticky sessions.
HA-Proxy is a good product to achieve this. (the URL: xy.1wt.eu )
3) if you use the point 1, you will not have problems with cross domain ajax calls. In fact it is completely transparant for the client. For instance for the same domain example.com a user coming from US will resolve it to 1.1.1.1 whereas a user coming from Germany will resolve example.com to 2.2.2.2 (ip addresses are fake and used just as an example).
On a side note, a solution to do cross domain ajax call is JSON-P which has though some drawbacks, like the lack of support for POST.
If I were you I would go with the BIND and GEO-IP, because it would solve all three problems in once. (a part for the latency because is not always true that the geographically closest server is the one with the lowest latency.)
Our infrastructure team has configured a a load balancing using Radware. Basically we have 3 web server that are load balanced.
Before we go live I would like to test and make sure that load balancing is working. How do I test the following:
3 servers are load balanced and requested are evenly distributed. (Any automated tool exists?)
Asp.net InProc session are working.
You can test by first generating an artificial load on your site (with any one of a number of load generators). Then have a look at the Windows Performance Counters for each site: things like HTTP requests per second and CPU use would be reasonable high-level metrics.
Yes, there are automated tools, but they usually require quite a bit of setup, and the better ones charge a fee. Perf counters are fast, easy and free.
As #swannee said, InProc sessions won't work in a load-balanced scenario unless your load balancer is configured to use sticky sessions. It's better to use SQL Server sessions with load balancing.
FWIW, you can test your software in a "mini" load balanced scenario on a single server by enabling IIS web gardens (multiple worker processes), from the AppPool config dialog.
Can you look in the IIS server logs to see how many hits each server is getting?
http://msdn.microsoft.com/en-us/library/ms953324.aspx
Also, unless you are using sticky sessions, you are going to have problems with InProc session. It won't work on a server farm (unless as stated you have sticky sessions turned on). If you don't have sticky sessions, you'll be able to tell real quickly that your session is being lost between requests with just some manual testing.
Our organization makes a series of ping and advanced status pages. These pages are monitored by our load balancers so it can take out unhealthy nodes in the event one node loses a connection to a database server or the node itself is having issues.
Our ping pages spit out the server name that you're connecting to and the status. They are avaliable by the common server names themself, like server01.application.com/ping and server02.application.com/ping but more important, they all answer on application.com/ping.
Refreshing the page will show us a new connection (you can see the server name change).
To test load you could use WCat, it's not the easiest tool to setup and script but it works.
To test sessions. you'll need to build out some pages that you can do load testing on to test sessions
I am working on asp.net (newbie) and I am trying to understand what it means to do "load balancing" for the web site. The website will be used by multiple users and resources (database, web service,..).
If anyone could help me understanding the concept of the load balance for asp.net web site, I would really appreciate it.
Thanks.
One load-balancing-related issue you may want to be aware of at development time: where you store your session state. This MSDN article gives a good overview of your options.
If you implement your asp.net system using "out-of-process" or "sql-server-mode" session state management, that will give you some additional flexibliity later, if you decide to introduce a load-balancer to your deployed system:
Your load balancer needn't handle session affinity. As one poster mentioned above, all modern load-balancers handle it anyway, so this is a minor consideration in any case.
Web-gardens (a sort of IIS/server-implemented load-balancer) REQUIRES use of "out-of-process" or "sql-server-mode" session state management. So if your system is already configured that way, you'll be one step closer to being able to use web-gardens.
What is it?
Load balancing simply refers to distributing a workload between two or more computers. As a concept, it's not unique to asp.net. Although having separate machines for your database and web server could be called "load balancing" it more commonly refers to using multiple machines to serve a single role, such as having multiple web servers.
Should you worry about it? Probably not. Do you already have a performance problem? Are your database and web server on their own machines? If you do find that your server resources are strained, it would probably be easier to scale up (a more powerful single machine) than out (load balancing). These days, a dedicated box can handle a LOT of traffic if your code is decent.
Load Balancing, in the programming sense, does not apply to ASP.NET; it applies to a technique to try to distribute server load across two or more machines, rather than it all being used on one machine. Unless you will have many thousands (millions?) of users, you probably do not need to worry about it.
Check the Wikipedia article for more information.
Load balancing is not specific for any on technology stack be it asp.net, jsp etc. To load balance is to spread the incoming requests to a web site over more than one server. This is typically done with a software or hardware load balancer. The load balancer sits in front of two or more web servers and delegates the incoming traffic. Although this technique is not limited to web servers. Load Balancing
Enjoy!
I've never used it, but an option is IIS Application Request Routing.
IIS Application Request Routing (ARR)
2.0 enables Web server administrators, hosting providers, and Content
Delivery Networks (CDNs) to increase
Web application scalability and
reliability through rule-based
routing, client and host name
affinity, load balancing of HTTP
server requests, and distributed disk
caching
In a typical web server/database scenario, the db is almost always guaranteed to load up the machine first. This is because dealing with storing data requires more resources. Before you even start looking at load balancing your web server, you need to think about how to load balance the database.
Spreading one database across multiple servers is a lot harder than load balancing a web server. One of the techniques that can be used is sharding (or horizontal partitioning). This is where some records are stored on one server, and other records - on another server. For example records with ID 1-900000 are on server 1 and records 900001- are on server 2.
In comparison to DB load balancing, spreading the load across multiple ASP.NET servers is not overly complicated. Most of the session issues can be easily mitigated by using out of process session and/or never talking to Application.Cache directly. Data load balancing on the other hand is hard and requires a lot of planning and trial and error. In most cases, talking to a load balanced DB requires using an ORM which supports it (e.g. NHibernate) or your own Data Access Layer. The reason being is that you need to take out establishing a connection from the code that uses the database, so that the decision which DB to talk to is handled in one place.
the exact solution is to save session into the SQL Server with Stored Procedure. To read session call 'SessionCheck' stored Procedure.
I'd add that it really isn't something to worry about. By the time you need a load balancer, you can probably afford one of the neato newfangled ones with sticky sessions so you don't even have to deal with the session boogeyman.
I'm looking to prevent session hijacking in my ASP.NET application and came across this great post by Jeff Prosise. However, it's from 2004 and I was wondering if there have been any updates that either perform the same thing, or result in any complications? Also, has anyone used this on a production server and, if so, have there been any issues caused by this? The only problem that could affect my applications is if someone's IP network changes in a short period of time, but I can't imagine this being very likely.
Thanks
This is an interesting approach to session hardening but it does not stop session hijacking. This system has the same problem as HTTPOnly Cookies which is that an attacker can create requests from the victim's browser using xss and there for the attacker doesn't need to know the value of the session id.
This quote is taken from the article you linked to:
SecureSessionModule raises the bar for hackers who hijack sessions using stolen session IDs
This raises the bar, but you still need to patch your XSS and CSRF vulnerabilities.
This is long dead but I have noticed a problem with it that will possibly start affecting more and more servers in the coming years. Part of the MAC that's generated uses the IP address, splitting on the ".", but IPv6 addresses use ":".
I don't have a production server on IPv6 but I've recently upgraded my development machine which is connecting to Cassini via IPv6 and I very quickly get into a non-stop string of session errors.