I have an unusual scenario, where I am trying to scale a WCF service that isn't thread safe. I have four instances of the service running on a single 4-core server, in four separate IIS web sites, with CPU affinity enabled. The sites are bound to ports 8022, 8023, 8024 and 8025.
My question is: can I use Application Request Routing (ARR) to load balance requests to a single port (80) across these four sites?
As far as I know you can't use the Webfarm-Framework for balancing between different ports on one Server. Maybe because from a failure safety perspective it dosn't make sence.
A workaround is to add some additional IPs to your Webserver and configure your 4 web sites bindings to listen on the same port but on different IPs.
So you cann set up a web farm with 4 different IPs as servers which in fact are locatet on the same physical machine.
hope this helps.
Best regards,
Peter
Related
I set up a NLB cluster given two servers (WS 2008 R2). Each server has one NIC card which I set up for a static ip address. I assigned the cluster an internet name (MyCluster), and assigned it a static ip address. The third box is acting as a client sending TCP data (over WCF) to the cluster's IP I configured (static IP). I am observing the NLB cluster from the NLB manager at one of the nodes - both nodes are green, say started. However, I am only able to see traffic coming in to one of the NLB servers. When I suspend it, I see traffic going to the other NLB server, and so on. I was expecting traffic to be split equally between them. I can't figure out what I missed, any tips please?
If you need more detailed information please ask, not sure how much detail to put in here.
Thanks/.
By default, a port rule created with a Filtering mode of multiple host will use single affinity. In other words, multiple requests from the same client will get directed to the same host. To see traffic going to both hosts try accessing the cluster from multiple clients. You could also set the affinity to "none", but this can lead to other problems.
There's good information on the affinity parameter and how to use it in the NLB help file.
I'm testing a web application using Apache AB; I love it but my web hosting service does not: if I increase the concurrency level over 30/40 I start getting 503 errors. The reason (according to the web hosting support) is that all the requests come from the same IP; do you know any other similar tool which can also simulate concurrent requests coming from different IPs?
Do you think the rule adopted by the hosting service is correct? For Optical Fiber internet connections, having many people who share the same IP is not so uncommon.
I'm not sure, but you can try to use Apache JMeter. Just run it remotely from different IP
I'm looking to deploy a WCF services project to IIS - the services are both wsHttp and webHttp (not that it makes much difference!) in the same project at the moment.
The server is already hosting MVC3 web sites on port 80, separate to the web services.
In the future, the services and sites may be separated...depending on load/performance/cost etc.
Are there "accepted/common" ports or port ranges to use for web services?
Any ranges to really avoid (*obvious ports ignored of course - 25/80/8080/443/1521/etc.)
If you're expecting your app to get used by folks in all sorts of environments, I'd strongly encourage you to figure out how to host it on port 80. Everything else is going to get blocked by one sort of firewall or another. About the only port that just about every company allows open is port 80.
My personal experience with this comes from having hosted a Silverlight-accessible web service on a non-standard port (port 4502, though it doesn't make much difference). Because of Silverlight's networking limitations we didn't have much of a choice, but we ran into a whole bunch of firewall issues at one company after another after another. Do yourself a favor and just host it on port 80.
Trying to figure out the best way to easily connect a bunch of client machines running WCF service to a LAMP server on a wide area network....
Currently just set up set up each client with DynDNS, and port forwarding at the router... Absolutely not the best situation for deployment.
Ideally would like to have a simple program they run which automatically connects them to the LAMP server....
Can anyone point me in the right direction?
Should I be looking at Reverse SSH, Windows Azure AppFabric ServiceBus?
This is one the scenarios that Service Bus relay was created for. With the relay, a sort of tunnel is established via ServiceBus between your WCF services and your clients, independently of where each party is deployed (as long as both have internet access, that is).
This article has a tutorial on an scenario that's very similar to what you describe:
http://www.windowsazure.com/en-us/develop/net/tutorials/hybrid-solution/
A reverse proxy would certainly be relevant here.
There are a number of ways to provide this. You mention using a LAMP stack so I'm assuming that you are using Apache as a web server.
You need a couple of optional Apache modules. Proxy and Reverse Proxy.
Typically you would assign a virtual "folder" to each actual app:
https://server/app1
https://server/app2
The reverse proxy would forward requests through to the actual, internal server/port:
https://server/app1 -> http://localhost:8000/
https://server/app2 -> http://localhost:8001/
(or whatever configuration you want)
We use BigIP to load balance between our two IIS servers. We recently deployed a WCF service hosted on by IIS 6 onto these two Windows Server 2003R2 servers.
Each server is configured with two host headers: one for the load balancer address, and then a second host header that points only to that server. That way we can reference a specific server in the load balanced group for debugging.
So when we run We immediately got the error:
This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Parameter name: item
I did some research and we can implement a filter to tell it to ignore the one of the hosts, but then we cannot access the server from that address.
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://domain.com:80"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
What is the best solution in this scenario which would allow us to hit a WCF service via http://domain.com/service.svc and http://server1.domain.com/service.svc?
If we should create our own ServiceFactory as some sites suggest, does anyone have any sample code on this?
Any help is much appreciated.
EDIT: We will need to be able to access the WCF service from either of the two addresses, if at all possible.
Thank you.
On your bigIP Create 2 new virtual servers
http://server1.domain.com/
http://server2.domain.com/
create a pool for each VS with only the specific server in it - so there will be no actual load balancing and access it that way. If you are short on external IP'S you can still use the same IP as your production domain name and just use an irule to direct traffic to the appropriate pool
Hope this helps
The URL it uses is based on the bindings in IIS. Does the website have more than one binding? If it does, or is the WCF service used by multiple sites? If it is, then you are SOL AFAIK. We ran into this issue. Basically, there can be only one IIS binding for HTTP, otherwise it bombs.
Also, here's info on implementing a ServiceHostFactory. That WILL work if it's possible that your WCF service only be accessible through 1 address (unfortunately for us, this was not possible).
When you need to test a specific machine, you could "bypass" the load balancing and ensure the correct host-header is sent to keeep WCF happy by editing the "hosts" file on the machine you're testing from so, for example:
10.0.0.11 through 10.0.0.16 are the six hosts that are in the cluster "cluster.mycompany.local", with a load balanced IP address of 10.0.0.10. When testing you could add a line to the machines hosts file that says "10.0.0.13 cluster.mycompany.local" to be able to hit the third machine in the cluster directly.