Perhaps I have the wrong product in mind for our needs -- but I want to know if I can use Application Request Routing (ARR) in IIS7 to load balance requests for our application tier.
We have a farm of web servers. Each will be running our MVC web application. We load balance these servers through our web application firewall and load balancing appliances. In turn, they will be make WCF calls to our application servers. It's these calls that I want to use ARR to manage.
However, after looking at ARR, it seems like it's all about rewriting URLs coming from the client. But that's not how our situation works. If a user browses to www.myapp.com/home/index, we will in turn be making WCF calls to services configured in the web.config to say myappservice.foo.local/home/GetInfo.
How do I configure for this scenario, or am I looking at the wrong product?
I am not really sure to understand your scenario, but if i understand correctly, I think you would be able to call your WCF sevice. If you dont need to keep the session on your call, just uncheck the client affinity checkbox in server affinity configuration.
Configure your load balance to Round Robin, or Least response time in the load balance interface and your request will suppose to be load balance.
If you got more that one ARR server, i suggest you to disable Shared configuration on your ARR, we get some problem with this features on the ARR server.
I agree with #Cedric, not sure if the question has been phrased as well as it could be?
What type of load balancing/distribution are you looking to achieve?
Are you looking to balance load? Distribute load to specific server farms based on request content? Some other function? A little more info here might help get a better answer.
Will ARR work with WCF?
Yes, but only with the HTTP bindings as far as I know (wsHttpBinding and basicHttpBinding).
I still imagine there being a hardware loadbalancer (or some other method) in front of your ARR servers.
Your web servers are going to act as clients of the application servers servicing your WCF requests. However, it appears as if your already going to a DNS name of myappservice.foo.local/home/GetInfo - if it resolves to a virtual ip your already getting loadbalancing of some kind?
Why not use your existing "load balancing appliances" to do the load balancing?
I could definitely imagine a hardware loadbalancer servicing requests for mayappservice.foo.local, which then resolves to a virtual ip backed by your ARR servers. Then conceivably your ARR servers could then further refine who services the request, maybe by some content of the request? Maybe map all /home requests to one group of servers and all /foo to another?
Pretty sure I muddied the waters a bit more! :) But I'm very curious for reasons for looking at ARR.
Related
Here is my situation. Recently, my production environment has been burned by a few Windows updates that caused some production servers to stop responding. While we have since resolved the issue of both of the servers (which are in a load balancing configuration) getting updates on the same day, the question arouse, how do we check that the application running on each server is still working? If we call the load balancing IP, we may or may not hit a server that is working. So if the update takes out the application on one server, how do we know that this has happened
The only idea I have for this is to purchase 2 more SSL certificates and allocate 2 ip addresses and assign one to each server. This way I would be guaranteed that I would know each server is up (we have a 3rd party service pinging our servers). But I have to believe that there is a better way to do this?
Please note that I am a .Net developer by trade with only an extremely small smattering of networking and IIS experience, but I'm what my small company has. So please assume I don't know where a lot of stuff is and dumb down the answer.
Load balancer maintains live status of the servers ( based on timeouts or http health checks ). It uses this status to route the traffic only to active servers.
Generally, LBs have a dashboard through which you can check this status. If not, you can check it's logs.
Enviroment
Consider the following production environment setup for a web application:
End user --Internet--> web server in DMZ --Firewall--> WCF hosted on app server --> DB Server
Constraint:
Also consider that we cannot change anything from the infrastructure point of view. For example, open ports, change any firewall setting etc.
Problem:
We want to expose the WCF, which is hosted on the app server, to external clients. We are trying to solve this as follows:
End user --Internet--> Router WCF in DMZ --Firewall--> WCF hosted on app server --> DB Server
Please note that we cannot establish a db connection from the DMZ environment where the WCF needs to be hosted so that the external clients can consume it. We have developed a "Router WCF" which passes through all messages to the internal WCF and vice-versa.
This solution adds an unnecessary overhead of serializing and de-serializing data. There must a better and proper way of doing this. We are looking forward to the community for guidance. Thank you.
In DMZ the bibliography tells you: always create an intermediate layer. This means another machine on the internet will be the point of connection and it will proxy the connection back to WCF.
The machine is the web server you seem to mention, that is stupid, has no data, and (to be a proper DMZ) has a firewall between it and all the machines (WCF and the others) it serves that permits only IP:PORTS used on such machines.
In this scenario, usually Apache on the public web server with a URL-rewrite rule (i.e if it is /x/y send it to servera.internal.com:9900 - if it is /x/z send it to serverb.internal.com:9901 etc...) is enough, but there are plenty of solutions of course.
It seems you are doing exactly this, why do you say it is not the proper solution?
DMZs could seem a bit dated as protection mechanism (I agree) but you have to think when servers like your WCF machine had dozens of ports opened, and you wanted to lower the risk of random ports on web-facing machines, a giant attack surface. Nowadays everything can work with couple of ports opened, so it can seem "silly" to do all of this just to forward a TCP port. But it is still valuable as (for example) if servers behind the web server in DMZ do not have internet access, even when WCF is compromised, the attacker cannot use its own reverse shell to deploy what it is nowadays called an APT (yesterday backdoor). The attacker "won't see" his own machine from WCF as the DMZ provides the connection to the external world.
I wanted to send all the requests for same content to the same backend server. How I can do this. Are there any open source versions like HaProxy which can do this.
For example. Client 1 has requested for Content A, and my load balancer directs that request to one of the backend server say X on round robin basis. Now if I receive a request from different client 2 for the same content A, this request should be directed to the same backend server X. Are there any open source solution which can do this.
Any help/pointers would be appreciated.
Thanks, Nikhil
Ha proxy can do what you want and more. It has many acl options available to suit most requirements. Varnish is another option that has a robust acl language.
Interesting question!
I'm affraid it can depend on technology. As long as you're in HTTP domain, maybe you can somehow configure your loadbalancer.
I'm a Java guy, so, in java you can have, say EJB. These are distributed components installed on server and can be run remotely. Their communication protocol is binary and I doubt load balancer can read it.
So, in JBoss, for example you can create a cluster of servers, and deploy different EJBs on different servers.
For example, lets assume, there are two EJBs in the system. One allows to buy milk, and one for pizza.
So you deploy the milk ejb on server 1 and pizza ejb on server 2.
Now you have a naming resolution service (in java/jboss its called HA-JNDI).
It basic idea is to provide a remote stub based on the name:
PizzaEJB pizzaEjb = NamingService.getMyStub(PizzaEJB.class);
Its not a real working code of course, but it demonstrates an idea.
The trick is that this naming server knows where each EJB is deployed, so if you have the pizza ejb only on server 2 it will always return a stub that will go to server 2 and buy the pizza :)
Java programmers so, don't really care how its implemented under the hood. Just to give an idea - the naming service has some form of agent deployed on each server and they talk with each other...
This is how java can work here.
Now what I think, maybe you can base your api on Restful web services, in this case its easily parsable http request, so the implementation can be relatively easy (again, if your load balancer supports this kind of processing).
Hope this helps somehow
what's the best way to achieve high availability for a dynamic website? If I create a second copy on another server and do not wish to use a load balancer since it will mess up user sessions, what are the best alternatives?
You can store session data in a database instead, which gets around that problem, then you can round-robin the requests to the application servers.
(Good) Load Balancers can be configured to be "sticky" which means they send requests from the same IP to the same server each time.
Even if you have a load balancer sitting infront of two backend webservers, you just move the single point of failure onto the load balancer instead of the webserver. So your application would still not be highly available.
I highly recommend using a load balancer and at least a pair of web servers. At work, we use HA Proxy, which is fully capable of ensuring sessions are 'sticky', and are sent to the same web server unless it goes down, where it will fail over.
To make your load balancer highly available, you can set up two load balancing servers which are a mirror image of each other. Assign a single virtual IP to both of your load balancers. Write a script that will poll the other server to check if it's down; if it's down, have that script pick up that virtual IP address. The script should be running on both servers.
This link describes one way of managing a virtual IP address. Similar articles have been written for a large number of linux distros, but they are all based on the same method.
Loadbalancers. They should be configured in such a way that they can handle the sessions. Maybe by sending the same ip to the same backend every time. Or store them inside a database, or some shared memory if it needs to be really fast for some reason i haven't thought of.
From what I understand, if you have multiple web servers, then you need some kind of load balancer that will split the traffic amongst your web servers.
Does this mean that the load balancer is the main connecting point on the network? ie. the load balancer has the IP address of the domain name?
If this is the case, it makes it really easy to add new hardware since you don't have to wait for any dns propogation right?
There are several solutions to this "problem".
You could round-robin at the DNS-level. I.e. have www.yourdomain.com point to several IP-addresses (well all your servers).
This doesn't give you any intelligence in the load balancing, but the load will be more or less randomly distributed, but you wouldn't be resilient to hardware failures as they would still require changes to DNS.
On the other hand you could use a proxy or a loadbalancing proxy that has a single IP but then distributes the traffic to several back-end boxes. This gives you a single point of failure (the proxy, you could of course have several proxies to defeat that problem) and would also give you the added bonus of being able to use some metric to divide the load more evenly and intelligently than with just round-robin dns.
This setup can also handle hardware failure in the back-end pretty seamlessly. The end user never sees the back-end, just the front-end.
There are other issues to think about as well, if your page uses sessions or other smart logic, you can run into synchronisation problems when your user (potentially) hits different servers on every access.
It does (in general). It depends on what server OS and software you are using, but in general, you'll hit the load balancer for each request, and the load balancer will then farm out the work according to the scheme you have in place (round robin, least busy, session controlled, application controlled, etc...)
andy has part of the answer, but for true load balancing and high availability you would want to use a pair of hardware load balancers like F5 bigips in an active passive configuration.
Yes your domain IP would be hosted on these devices and traffic would connect firstly to those devices. Bigips offer a lot of added functionality including multiple ways of load balancing and some great url rewriting, ssl acceleration, etc. It also allows you to run your web servers on a seperate non routable address scheme and even run multiple sites on different ports with the F5's handling the translations.
Once you introduce load balancing you may have some other considerations to take into account for your application(s) like sticky sessions and session state but that is a different subject