ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » What should we configure our Load Balancer to check

Post new topic  Reply to topic
 What should we configure our Load Balancer to check « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Tue Oct 01, 2013 6:26 pm    Post subject: What should we configure our Load Balancer to check Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

In WMB 6.1 we had our F5 Load Balancers check for the port being active for the Broker's HTTP and HTTPs Listeners, and the embedded Listeners in the Execution Groups for the SOAP nodes. It was a very basic test for the F5 to decide if that WMB server should remain in the load balancing pool for that URL. Obviously this has some issues. Just because the port is open doesn't mean any one particular message flow servicing a specific URL is functional.

So, on our WMB 8 Brokers I want to beef this up. Our F5 guys say the web guys for the Web Hosting farm will create an "IsAlive" web page hanging off a particualr URL and the F5 checks for that "IsAlive" page to determine if that particular web site is up on that particular server. If it can't find the IsAlive page for that URL on that web server, it drops that web server from the load balancing pool for that URL.

How can I do something similiar in WMB? I doubt we can do an IsAlive web page in WMB for each flow, but maybe? We are considering moving away from the embeded Listeners in the Execution Groups for SOAP and just using one common Listener for HTTP and another one for HTTPS - a new feature offered as of 8.0.0.1. If we do, that makes our old way of just checking on the port even less useful.

So, is there something common to HTTP, HTTPs and Soap Node flows that we could have the F5 check on to determine if that message flow is reasonably healthy?

I found this:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/ac20450_.htm
Quote:

Setting the HTTP Status Code for a reply
The default HTTP Status Code is 200, which indicates success. If you want a different status code to be returned, take one of the following actions:


Is it as simple as telling the F5 Admin to just check for a HTTP status of 200 for every URL we give him, and if any URL doesn't report a 200, the F5 can drop that WMB server from the load balancing pool for just that URL?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Wed Oct 02, 2013 3:12 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

No, if you write your code properly, your code will return any of a series of status codes, not just 200.

A thorough test would be a probe message, checking the contents of the return payload.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Thu Oct 03, 2013 2:04 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You certainly can create an "isalive" message flow, that returns a blob message that contains HTML.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Thu Oct 03, 2013 3:06 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

mqjeff wrote:
You certainly can create an "isalive" message flow, that returns a blob message that contains HTML.


Hmmm... Number One, launch the "isalive" probe. Make it so.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Thu Oct 03, 2013 4:23 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

lancelotlinc wrote:
mqjeff wrote:
You certainly can create an "isalive" message flow, that returns a blob message that contains HTML.


Hmmm... Number One, launch the "isalive" probe. Make it so.


I agree, it's an excellent idea for other people to implement.

I'd tend to skip the whole business, and put a proper three tier architecture in place, using the functions in 8.0+ to export the broker's config to an apache mod_proxy config.

then let the f5 worry about which one or the other of the apache http's was up and running, instead of which broker and EG was up and running.

But that's just me.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu Oct 03, 2013 6:38 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

mqjeff wrote:
You certainly can create an "isalive" message flow, that returns a blob message that contains HTML.


But the "isAlive" message flow's health has no direct coorelation to any other message flow.

Message Flow A has an HTTP Input node and is addressed via a URL http.MessageFlowA.com

Message Flow B has an HTTP Input node and is addressed via a URL http.MessageFlowB.com

Message Flow isAlive has an HTTP Input node and is addressed via a URL http.MessageFlowisAlive.com


Lets say someone messes up and deletes Message Flow B from one of the Brokers, Broker #3. The fact that MessageFlowisAlive is responding affirmativly on Broker #3 is irrelevent.


I want something at the message flow level that could confirm to the F5 that the message flow is present and functional to some basic degree on a Broker. It needs to be something the F5 can check seperate from a real transaction coming thru - we need to know of a failure without using an actual transaction to identify that.

What if MessageFlowA and MessageFlowB each had a secondary HTTP Input node added to the flow with a unique URL/URI that would only be used by the F5. That path in the message flow could be the isAlive path.

http.MessageFlowA.com/businessdata would be for the real transactions.
http.MessageFlowA.com/isalive would be used by the F5 to verify Message Flow A is there and responding.

http.MessageFlowB.com/isalive would be the exact same code, so the F5 guy would not need to code something unique for each new message flow we add.

I don't know if 2 HTTP / SOAP / HTTPS nodes in one message flow is a dumb idea or not - I haven't been to my WMB training
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Oct 03, 2013 6:45 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

PeterPotkay wrote:
I don't know if 2 HTTP / SOAP / HTTPS nodes in one message flow is a dumb idea or not - I haven't been to my WMB training


It's a dumb idea if it's done for no good reason.

This is a reasonable reason.

It's likely easier than implementing an "I Live" operation on every service interface you build.

But it does throw in some complication because each input node gets a separate thread, so you could still have a "stuck" flow because all "main input node" threads are hung, but the one for "i'm alive" is just fine.

Back to top
View user's profile Send private message
smdavies99
PostPosted: Thu Oct 03, 2013 6:46 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

Quote:

Lets say someone messes up and deletes Message Flow B from one of the Brokers, Broker #3. The fact that MessageFlowisAlive is responding affirmativly on Broker #3 is irrelevent.

If that happens then you have far more to worry about than a few HTTP messages.

If that happened to one of my systems I'd probably just deploy everything again using the scripts that do all the heavy lifting for me.
Mine are called 'Night Owls' because they run at 01:00 every day. One checks for deleted or stopped flows and if they find one, it is re-deployed or restarted automatically and an event emailed to me.

['Night Owls' were the name given to the 2-8-0 locos built for the GWR (uk) for high speed overnight freight use http://www.knowles-cadbury-brown.co.uk/4709/]
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu Oct 03, 2013 1:33 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

mqjeff wrote:
But it does throw in some complication because each input node gets a separate thread, so you could still have a "stuck" flow because all "main input node" threads are hung, but the one for "i'm alive" is just fine.


Agree. The only sure way to know the thing is working is to send a transaction thru it. But that F5 is not going to do that. So looking for something in between just checking if the port is open and sending an actual transaction.

I did not consider the additional thread due to the secondary "Is Alive" HTTP Input node....boom, we just doubled the number of threads used by all our HTTP / HTTPS / SOAP flows.


What about doing something inline in each message flow so that it queries each transaction to see if its a real transaction or not. Real transaction pass it along to the real logic in the flow. If its an F5 probe, reply back you're alive and done. A little reuseable chunk of code placed in each HTTP / HTTPS / SOAP flow?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu Oct 03, 2013 1:36 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

smdavies99 wrote:
Quote:

Lets say someone messes up and deletes Message Flow B from one of the Brokers, Broker #3. The fact that MessageFlowisAlive is responding affirmativly on Broker #3 is irrelevent.

If that happens then you have far more to worry about than a few HTTP messages.


OK, maybe a bad example. But something to identify a message flow that is hosed. Psudo transactions are really the only way to be sure, but looking for something an F5 can do that is just short of that to give you a reasonably good idea the server is up, the broker is up, the EG is up, the message flow is responsive.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mgk
PostPosted: Fri Oct 04, 2013 9:36 am    Post subject: Reply with quote

Padawan

Joined: 31 Jul 2003
Posts: 1642

One way to achieve this is to get the F5 box to send an HTTP "HEAD" request to each URL that is exposed. This request will return an OK result if the flow has been deployed and has registered its URL with the HTTPListener. For SOAP nodes this will just work with no extra config needed. For HTTP nodes, by default the HEAD request would actually be sent to the flow which in this scenario is probably undesirable. So you should set the "autoRespondHTTPHEADRequests" documented here: http://pic.dhe.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/an09148_.htm

I should point out that this will not solve all possible problems in this area, but it is a reasonable alternative to the overhead of managing an "isAlive" flow.

I hope this helps,

Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » What should we configure our Load Balancer to check
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.