| Author |
Message
|
| AndyMQ |
 Posted: Mon Jun 06, 2005 8:26 am Post subject: MQ Clusters on Tandem (HP NSK) |
 |
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Folks,
My customer is investigating the use of Clusters. Currently I'm trawling through all the relevant manuals, but would appreciate if anyone had any pitfalls or gotchas to look out for, particularly since we are looking at clustering on WMQ release 5.1, the "latest" release available on Tandems.
Cheers chaps |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Jun 06, 2005 8:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I don't know if 5.1 supports clustering. There might be support packs/fixpacks for NSK that will, though.
The big gotchas that people find are a result of bad expectations. MQ Clustering is not a failover solution, it's a load balancing solution. MQ Clustering does not change the nature of GET - you can't get from cluster queues only local queues.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EddieA |
| Posted: Mon Jun 06, 2005 10:05 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I don't know if 5.1 supports clustering |
I'm fairly sure it was 5.1 where Clustering was introduced. But, I wouldn't trust it. The early versions were very flakey.
And I also seem to remember some problems with mixed versions in the same cluster.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jun 06, 2005 10:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| EddieA wrote: |
| And I also seem to remember some problems with mixed versions in the same cluster. |
As a rule, always upgrade your FR's before you upgrade anything else.
In particular, if you have a 5.2 FR and try to add a 5.3 Qmgr that uses SSL on it's channels... you will corrupt the repository! Fun!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 06, 2005 11:32 am Post subject: Re: MQ Clusters on Tandem (HP NSK) |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| AndyMQ wrote: |
Folks,
My customer is investigating the use of Clusters. Currently I'm trawling through all the relevant manuals, but would appreciate if anyone had any pitfalls or gotchas to look out for, particularly since we are looking at clustering on WMQ release 5.1, the "latest" release available on Tandems.
Cheers chaps |
I thought that with the unveiling of MQ V6.0 there was some talk about a 5.3 for Tandem NSK? I might be mistaken though as I did not pay that much attention to NSK.. |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Mon Jun 06, 2005 11:54 pm Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Clustering was introduced in 5.1, but I was aware of the early teething troubles....mainly via this site. Don't really have a warm feeling about using clusters, not on 5.1 MQ anyway, and 5.3 for Tandem has been talked about for quite some time now and the cynic in me tends to think that it'll continue to be talked about for quite some time to come.
It's always good to get the opinions of those who have already suffered through operating at the bleeding edge.
I'm a great believer in the old adage about "if it ain't broke, don't fix it". We only have 2 qmgr's and performance isn't an issue so the risks probably outweigh the gains in our case.
Thanks for the info' guys.....much appreciated. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Jun 08, 2005 6:48 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
Clusters on NSK (5.1) works fine with v5.3.0 or 5.3.1 versions of MQ.
The SSL property is ignored. Before CSD3 there was some problems with repository , but this one is fixed. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 08, 2005 6:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| LuisFer wrote: |
| Before CSD3 there was some problems with repository , but this one is fixed. |
CSD3 of what? NSK-MQ 5.1? Or distributed MQ 5.3?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Jun 08, 2005 6:54 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
csd3 for NSK
In our installation, with MVS, AS400, AIX, Solaris, Linux, Windows QMgrs, the NSK'S QMgr's have the "guinnes" record with more than 13 months without stop, working with Clusters & more than 3.000.000 messages every day.
Last edited by LuisFer on Wed Jun 08, 2005 7:18 am; edited 2 times in total |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jun 08, 2005 7:00 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| There is a statement of direction for V5.3 on Tandem NSK for 2H2005. (MIPS and Ithanium). |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Wed Jun 08, 2005 7:27 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
We're currently CSD02 but are looking to implement CSD03 soon. Sounds like the sooner the better!
I'd be interested in seeing the statement of direction for NSK 5.3 tho'. Where can I find that?
Still not convinced clustering will buy us much as we are looking at implementing 4 qmgrs (duplicate qmgrs) on 4 nodes of a Tandem cluster (not MQ this time...confusing, ain't it?). The messages will be flowing from Tandem to IBM mainframe qmgr, which might not be part of the cluster, hence my concerns. We'll probably have to nominate one Tandem qmgr as the gateway qmgr, which means a slightly different config for one qmgr. Kinda defeats the purpose, but we'll give it a thorough testing anyway.
Seems to me that they are expecting clusters to provide fault tolerance/failover of some description, but since the flow is between Tandem and IBM, the network (for distributed messaging) is still likely to be the bottleneck. If we have 4 identical qmgrs on Tandem, then we may hit sequencing problems. If we have a gateway qmgr, then it will be the single point of failure if that node crashes.
My dilemma was great!!!!!! |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Jun 08, 2005 7:32 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
Using tandem SuperNet Cluster??
Sounds like your z/OS app. needs secuently.
I should work with RDF & MQ, but when a Tandem totally crash. One Cpu down can be "Normal" but, all the node??.
Notes:
A good MQ Pathway configuration (no the installation defect) prevents cpus down, with no lost of availability.
There is a IPM for the Paralel TCP/IP needed if you have z/OS --> Tandem Channels. |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Wed Jun 08, 2005 8:20 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Yes, we are using a 4 node Super Cluster with 8 CPUs per node, but at present we are only licensed for MQ on one node.
Our pathway config is very robust and we run most servers nonstop, with obvious exceptions such as the MQ-ECxx servers and repository servers which run per cpu and should not "fall" into the partner cpu.
We do still have the occasional single CPU failure where MQ can be a bit temperamental. We've never lost a complete node yet, and we would have to be very unlucky to do so (though I suppose a careless workman cutting through network cables with a pneumatic drill might do the trick!!).
We will be implementing Parallel IP (v6) fairly soon, but this customer always keeps up to date with IPMs. Still, that should be fun, fun, fun!
We will probably have the Tandem qmgrs in a cluster using qmgr aliases to minimise the application impact, and introduce an additional qmgr as the gateway qmgr, with gateway configs existing on the other nodes, ready to be started in the event of loss of the gateway node (curse that workman with his drill!).
It's unlikely we will include the mainframe qmgr in the cluster....'cos it ain't fault tolerant. We'll just stick to distributed messaging for that baby. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Jun 08, 2005 8:41 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
Certanly that the MQ ,in the case of a CPU down, works "rare" ( QServer high CPU, etc).
We solved this situation using the L option of the ALTMQFLS command for QLocals, doing not taking CHKPT with the Backup process of the QServers processes. |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Wed Jun 08, 2005 8:55 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
| Thanks for the tip. I'll look into the option L on altmqfls, although, until recently, the customer was running with a single qserver for all local queues, which was NOT good, especially with non-persistent messages! Losing a couple of critical messages forced them to re-evaluate that particular configuration option. |
|
| Back to top |
|
|
|
|
