| Author |
Message
|
| ayeh |
 Posted: Wed Sep 14, 2005 3:56 pm Post subject: Maturity of Clustering with Z/OS |
 |
|
Novice
Joined: 21 Oct 2001
Posts: 18
Location: Los Angeles, CA
|
I've been away from MQ for quite some time and am testing ideas for clustering for high-availability and short maintenance windows. Long ago, I had little luck getting z/os 2.1 and windows 5.0 queue managers to "see" all of the cluster resources after the channels came up. My memory is a bit foggy -- but I seem to recall seeing definitions appear then disappear right after the cluster came up. I do admit that was my very first and very last test of clustering.
Here's what I'm after:
Can members from this group validate clustering z/os (5.x) and AIX (5.x) queue managers together (cross-platform) is a rational and tested configuration? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Sep 14, 2005 5:35 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Absolutly. MQ clustering is much more stable as of version 5.3, and mixing different O/Ses is no problem at all and fully supported.
If you tried clustering back at versions 5.0 and 2.1, I am not surprised you have foggy memories of weird problems.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 15, 2005 8:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
But use clusters sparingly, rather than massively.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Sep 15, 2005 10:43 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
MQ Clustering had, especially on z/OS, made a quantom leap forward in the past 2 years or so; from a buggy, difficult-to-maintain and troublesome concept to a stable, trustworthy way to implement load-balancing and DRPs.
That said, I agree with jeff - they are to be used only when necessary (did someone say "a double edged sword"?  ).
Last edited by hopsala on Thu Sep 15, 2005 11:38 am; edited 1 time in total |
|
| Back to top |
|
|
| mq_developer |
| Posted: Thu Sep 15, 2005 10:57 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
| But my personal observation , never use MQ on MVS as a FULL repository for various cluster related issues (even in 5.3). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 15, 2005 11:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess I'll agree that I meant that clusters should only be used when necessary, but from earlier conversations I think we disagree as to when they are necessary....
What I really meant was larger clusters are better than more clusters - significantly! One cluster for the entire production environment is probably enough. One cluster per production application is definately too many!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Sep 15, 2005 11:37 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
I guess I'll agree that I meant that clusters should only be used when necessary, but from earlier conversations I think we disagree as to when they are necessary....
What I really meant was larger clusters are better than more clusters - significantly! One cluster for the entire production environment is probably enough. One cluster per production application is definately too many! |
It really all depends - in a DMZ scenario, for example, you definitely *should not* use one cluster, but two overlapping ones; same goes for several applications that belong to diffrerent companies using a central hub. True, the complexity decreases significantly, but security and political considerations come first.
Concerning when to use cluster, yea I remember that conv and indeed we had some disagreement there; but let's let sleeping dogs lie
| mq_developer wrote: |
| But my personal observation , never use MQ on MVS as a FULL repository for various cluster related issues (even in 5.3). |
Could you tell us more about this? What problems have you encountered? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 15, 2005 2:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hopsala wrote: |
| mq_developer wrote: |
| But my personal observation , never use MQ on MVS as a FULL repository for various cluster related issues (even in 5.3). |
Could you tell us more about this? What problems have you encountered? |
Yes, do tell, since the general consensus is you want your Full Repositories on the machines most likely to be available, and what's more available than z/OS? 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mq_developer |
| Posted: Fri Sep 16, 2005 12:30 pm Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
Problem 1 : Cluster Cache Size cant be dynamically allocated in Z/OS - if you are running repository queue manager on Z/Os there are quite likely to be lot of subscriptions that needs to be maintained , and each of them required cache space which is cut out of the initially allocated address space. As you add clusters into it , you might hit the upper limit one day on cluster cache size and your repository manager crashes leaving messages on SYSTEM.CLUSTER.COMMAND.QUEUE , but now only way for you to allocate more space is to recycle the Queue Manager on MVS - But this is not the case in other OS. ( I am not sure whether same is the case in V6.0 , what i mentioned is applicable to WMQ V 5.3)
Problem 2 : Adminstrative reasons : - Let say you have cluster problem and you have to recycle the queue manager , how easy it is on non business , isolated mqseries queue manager running repository compared to queue manager running on Z/OS - I am safely assuming no company would run a a stand alone repository queue manager on Z/os without running any business applications on it.
Problem 3 : Look at this past flash (alert) for cluster damage on Z/OS - http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&q1=cluster+flash&uid=swg21181907&loc=en_US&cs=utf-8&lang=en
Ofcourse , above mentioned problem (reaching upper limit) occurs only if you are extensively using clusters on a massive scale of queue managers.
All in all , as one size doesnt fit all , its a case by case basis and it really depends on what problems you got hit upon - you can use Z/OS a full repsoitory for its reliablity & availability , but I prefer to run it on clustered distributed environments running dedicated repository queue manager which i can safely recycle without impacting my business and it's applications. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sun Sep 18, 2005 7:10 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mq_developer wrote: |
Problem 1 : ... As you add clusters into it , you might hit the upper limit one day...
|
Interesting, never encountered that sort of behavior, but apparently i've never had a really big cluster (only about 20 PR, 4 FR and 40 shared queues in two overlapping clusters). Have you any estimation on the limit? Is this documented? |
|
| Back to top |
|
|
| mq_developer |
| Posted: Mon Sep 19, 2005 6:29 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
Number of subscriptions are proportional to number of cluster objects (Queues , QueueManager) & their Usage - this is whether cluster cache exponentially grows , as you use more objects and bring more queue managers into cluster - cache size increases.
Its not documented i guess , but there is no hard limit number either as it really depends on the usage. We used to have 15 clusters with around 400 distinct queue managers participating in various cluster topolgies. |
|
| Back to top |
|
|
|
|
