| Author |
Message
|
| rinchu |
 Posted: Thu Dec 01, 2016 10:03 am Post subject: Http request load balancing |
 |
|
Newbie
Joined: 13 Sep 2012
Posts: 7
|
| Hi I have a issue with a http request node . I have configured the web service URL in node level. The URL has the DSn name instead of IPaddress . And the system that I am trying to call have 3 servers and they all have different IP but the same DSN that I have configured . Now the issue is when the calling system shuts down one of the server broker is not able to point to the next available ipaddress. Even after restart of broker the broker is not able to refresh the IP. But it is able to refresh after reboot of the server.Can you please help me figure out if it's an issue iWith the broker or some where else . Thank you |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 01, 2016 10:09 am Post subject: Re: Http request load balancing |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rinchu wrote: |
| Can you please help me figure out if it's an issue iWith the broker or some where else |
Somewhere else. The IP address that resolved out of the DNS is cached at one of a number of places; the restart of the broker/EG will clear out that cache. If it works after the server has been restarted, that implies it's additionally cached somewhere else.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rinchu |
| Posted: Thu Dec 01, 2016 10:22 am Post subject: |
|
|
Newbie
Joined: 13 Sep 2012
Posts: 7
|
| Thank you . But when I did a lookup of the server from broker I was able to see that it's connected to the next available server. Do you think I should configure URL at local environment destination and then assign the value each time the data is sent . Or do Ignore searching at broker level and get a trace at network level. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 01, 2016 10:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rinchu wrote: |
| But when I did a lookup of the server from broker I was able to see that it's connected to the next available server. |
If you lookup a server behind a DNS, you'll get an IP address. If you fail that server and then look up the DNS again, you'll get the next available IP address (assuming no load balancing) because the failed IP has been eliminated as a target by whatever's hosting the DNS.
Nothing, not IIB, not WAS, not anything, looks up the DNS every single time it encounters it; the resource cost would be prohibitive. So if you look up a DNS and obtain an IP address then you continue to use the same IP address for that connection until something acts to make another DNS lookup occur. This is typically the DNS lease expiring or some kind of reboot.
So if you do a lookup of the DNS from the IIB server and get the next IP address, that proves nothing about what IP address IIB was given.
| rinchu wrote: |
| Do you think I should configure URL at local environment destination and then assign the value each time the data is sent |
No. It probably won't help as we've established rebooting the broker doesn't help so the failed IP address is cached elsewhere.
| rinchu wrote: |
| Ignore searching at broker level and get a trace at network level. |
Yes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rinchu |
| Posted: Thu Dec 01, 2016 11:54 am Post subject: |
|
|
Newbie
Joined: 13 Sep 2012
Posts: 7
|
| Thank you . Shall investigate further. IIB is run in soft layer cloud . |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 01, 2016 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rinchu wrote: |
| Thank you . Shall investigate further. IIB is run in soft layer cloud . |
Have you tried?
| Code: |
| sudo service dns-clean |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 01, 2016 12:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rinchu wrote: |
| IIB is run in soft layer cloud . |
Congratulations.
Irrelevant to the issue as posted.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 02, 2016 6:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| rinchu wrote: |
| IIB is run in soft layer cloud . |
Congratulations.
Irrelevant to the issue as posted. |
Not entirely. What the OP needs is a load balancer that is local to his cloud.
He can then enter the IP/DNS of the load balancer and be totally abstracted from the actual broker doing the work. This would in fact leave the OP with 4 dns names, one for each of the brokers doing the work and one for the (Virtual)IP that he needs to call and that will connect to the load balancer...
DNS changes are not a favored way for fail over because they can be very slow. DNS change propagation inside the firewall can take up to 2 hours, so imagine how long it will take across the Wan.
If the OP insists going the DNS change route...
The best bet would be to clear the dns cache on the server in which ever way that was implemented...
Hope it helps
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Dec 02, 2016 8:08 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
DNS resolutions and their Time to Live (TTL) can be cached inside the JVM of the broker (default is indefinite, but this can be changed).
Also can be cached by the OS (e.g. in NETCD) and by the DNS servers themselves.
BTW "Time to Live" means time before invalid (not time until they are live).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
