Communicating from a set of load-balanced Windows servers back to the same set of load-balanced servers – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, ssl, windows-server-2008-r2, nlb, windows-nlb.
We have a set of load-balanced (using Microsoft NLB v6.1) Windows servers (Windows Server 2008 R2) with IIS7 that host a range of web applications. These web applications do a lot of web service requests to external web services, which is fine.
We have found a problem with these web applications communicating with themselves. Say we have a web application at
https://app.example.com/ that communicates with
https://api.example.com/ (notice the use of SSL, which I think makes this even more problematic). Both
api are running on the same physical web servers, load-balanced under the same physical load balancer.
For some reason, this “looped” communication doesn’t work. From our ISP, we’ve gotten an explanation I don’t really understand, but that includes “the IP stack gets confused on which server is going to get the IP response to a given request”.
Is this a problem anyone, anywhere has managed to solve? We don’t want to communicate with our own web services in any other way than any of our external partners communicate with them. We wan to use the same SSL certificate, same URL and same IP address. Is this possible?
This is a common problem. Basically the problem (as I understand it) is that the load balancer doesn’t like the connection to come through the same port and back out the same port.
When using physical Cisco load balancers I’ve been able to work around this by using some pretty complex network designs. Not sure how to do the same when using NLB.