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 » General IBM MQ Support » Suspending from cluster if server is down

Post new topic  Reply to topic
 Suspending from cluster if server is down « View previous topic :: View next topic » 
Author Message
yogibo50
PostPosted: Tue Jul 24, 2007 8:36 am    Post subject: Suspending from cluster if server is down Reply with quote

Newbie

Joined: 30 Aug 2006
Posts: 8

How can you suspend a Qmanager from a cluster if the server that it runs on is down. The scenario.. The Server fails and we resume a qmgr on the failover server to take the message traffic. When the failed server is restarted, it comes up resumed also as it was never suspended and we get messages sent to both servers until such time as we suspend one of them. We are not at ver 6. so no use of cluster rank or priority is available.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Jul 24, 2007 9:10 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Why do you want to suspend it while it's down? It's not going to receive any messages at all. This is not guaranteed when the qmgr is suspended.

In order for a qmgr to be suspended, it has to be able to send messages to at least one FR. This means it has to be up and running enough to start a channel, and receive a reply.

It's difficult to convince a qmgr to not start a whole bunch of cluster channels, when it starts up enough to start ONE cluster channel.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
yogibo50
PostPosted: Tue Jul 24, 2007 9:26 am    Post subject: Reply with quote

Newbie

Joined: 30 Aug 2006
Posts: 8

I thought I made it clear. Our failover is based on use of a cluster. 2 qmgrs each on a different server, one is active in the cluster and one is suspended. When we can manage failover, we suspend the active and resume the other. So always only 1 qmgr gets messages. On a crash, we cannot do the suspend, so when the server comes back up and the qmgr starts, messages can flow to both servers until we suspend one of them. So, ideally, on a crash, we want to somehow do the suspend so on server restart the qmgr does not participate in the cluster until we want it to. Ideally being able to issue suspends of a qmgr at the FR would be nice but as that is not possible, I ask the question here.

You say that a qmgr being suspended does not mean it does not receive messages.. what do you mean by that? I know about PUt disabled messages with a local queue definition being overriden but not a suspended Qmgr, surely the messages would just stay on the SYSTEM.CLUSTER.TRANSMIT.QUEUE if all qmgrs were suspended.
Back to top
View user's profile Send private message
tecbi
PostPosted: Tue Jul 24, 2007 10:20 am    Post subject: Reply with quote

Newbie

Joined: 06 Nov 2001
Posts: 5

Let me see if you understand this... You want only one Qmanager to be active at any point in time. If there is a QManager that goes down, you start a failover Qmanager but when the original queue manager comes up you still want messages to only go through one QManager.

You can control this by the use of the NETPRTY on the individual channels (this is available in previous versions of MQ also for e.g. 5.3). Set a higher NETPRTY on the cluster rcvr channels that you want messages to go to in the event that both QManagers are up.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Jul 24, 2007 10:32 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Let's be clear.

This is not a requirement that you use MQ Clustering for.

This is a requirement that you use HA Clustering for - Veritas, HACMP, MSCS, etc etc etc.

In that implementation, there is only ever "one" queue manager. It happens to run on different computers, at different times. But as far as the MQ Cluster is concerned, it's always the same qmgr - and it's either available or not available.

In order to ensure that, even during the relatively short timeframe of failover, there is still a qmgr in the cluster that is providing service to the qclusters you need - then set up two different qmgrs, each under HA.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
yogibo50
PostPosted: Tue Jul 24, 2007 11:00 am    Post subject: Reply with quote

Newbie

Joined: 30 Aug 2006
Posts: 8

OK.. was not really looking for other options on how to do failover, I just wanted to ask the quetion about suspending a cluster when the qmgr is down.

I assume from the replies not having any suggestion that it cannot be done.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Jul 24, 2007 11:08 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Umm.

The qmgr has to be able to exchange messages with at least one FR in order for it to be suspended.

If it's down, it can't exchange any messages with anyone.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
tecbi
PostPosted: Tue Jul 24, 2007 11:25 am    Post subject: Reply with quote

Newbie

Joined: 06 Nov 2001
Posts: 5

Quote:
We are not at ver 6. so no use of cluster rank or priority is available.


Which version are you in? NETPRTY can be set on the Cluster receiver channel for ver 5.3 to control where messages are sent. Just set the original queue manager cluster rcvrs at a lower NETPRTY.

When both QMgrs are up at the same time, messages will go only to the failed over QMgr.

Bring down the failed over QManager and all your messages will again start going to the original QManager.

Given that, do you still need for the original Qmgr to be suspended or am I missing something here?
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Jul 24, 2007 11:35 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

To be more pathological, but in a way more trustworthy than playing around with NETPRTY...

You can leave the "main" qmgr in a suspended state ALL THE TIME. The only time it will ever get messages is when it is the only qmgr that is available that hosts some particular queue.

That is, the qmgr will function normally for all queues where it is the only qmgr that hosts a copy of that queue.

Then just make the "backup" qmgr unsuspended. When it starts, it will be the only unsuspended qmgr that can receive messages for the set of queues. So it will get all messages for those queues.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Jul 24, 2007 11:43 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

tecbi wrote:
Quote:
We are not at ver 6. so no use of cluster rank or priority is available.


Which version are you in? NETPRTY can be set on the Cluster receiver channel for ver 5.3 to control where messages are sent. Just set the original queue manager cluster rcvrs at a lower NETPRTY.


It's still not wise to use MQ clustering for high availability. You'll find many rants from me on this subject in the forum, but MQ Clustering is a workload balancing solution not an HA one. Using the software for a purpose for which it's not designed may work, but is not a good idea. May people try to use queues like a database, for data storage. It works, but not very well!
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
yogibo50
PostPosted: Wed Jul 25, 2007 4:50 am    Post subject: Reply with quote

Newbie

Joined: 30 Aug 2006
Posts: 8

Getting in to the details does not really aid in clarifying my question, but just so you understand we are not ignoring other HA options.. The 'failover' must be managed, we do not want any situation where there can be 2 active qmgrs with the same queue defined. Nor do we want 'automatic' redirection as would be the case with NETPRTY as other factors come into play such as moving CICS regions, non-shareable VSAM files etc.

So.. The primary LPAR crashes and will come back up still in the cluster but because of the crash, we have moved work over to the failover LPAR and unsuspended this qmgr from the cluster. So.. we want the original primary to come up 'suspended' to then manage switch over from the failover. So... All I want to do is be able to set a qmgr to 'suspended' when it is not up to receive the directive.

As to Jefflowrey's comment..

You can leave the "main" qmgr in a suspended state ALL THE TIME. The only time it will ever get messages is when it is the only qmgr that is available that hosts some particular queue.

I tried this before posting my original message as I thought the same thing, but messages just stay on the SYSTEM.CLUSTER.TRANSMIT.QUEUE on the PUTting system, can you explain how exactly you expect this to work?
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Jul 25, 2007 5:01 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Hrm.

I'd thought one of the "disadvantages" of a suspended qmgr was that it would only get messages if they couldn't otherwise be delivered. Maybe that's not quite right. Wouldn't be the first or last time that I was wrong.

If you never want more than one instance of a given queue available on your MQ network, then the only value that MQ Clustering brings you is reduced administration - in that you don't have to manually define all necessary channels in order to get a fully connected MQ network.

Exactly how small a failover window are you capable of sustaining - in which *no* instance of a queue is available in the MQ network?

Is it smaller than the window you have for transient network failures? Becuase your SLAs should include at least some room for network hiccups. And also for failovers.

With a plain, normal, HA setup on an MQ queue manager - all of the requirements you have given are met. And without playing around with clustering at all. There are also things you can do to reduce the time that a qmgr takes to fail over.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Jul 25, 2007 5:16 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

I thought Jeff's idea about Suspending QM2 was kinda slick actually. (as slick as you are going to get without addressing this the correct way, i.e. hardware clustering)

QM1 and QM2 are in the cluster, and both are running. Both host the exact same queues.
QM2 is always suspened.

While both are up, work only goes to QM1. EXCEPT when a putting app specifies QM2 as the destination QM. Then the messages will go to QM2 even though its suspeneded. Or if someone makes a change and the only available destination is QM2. This could be the q got deleted on QM1, or Put Inhibited on QM1. Or, and I'm only 99% sure onn this last point, the channel to QM1 is busy starting up. If that channel is not INACTIVE or RUNNING, the cluster workload algorithim will choose QM2 (suspended or not) over QM1's starting or binding or initializing channel.

When QM2 crashes, work only goes to QM1. EXCEPT when a putting app specifies QM2 as the destination QM. Then the messages will sit in the S.C.T.Q. of the sending clustered QM trying to get to QM2.

When QM1 crashes, work only goes to QM2. EXCEPT if the putting app specified QM1, OR, if the app opened the queue while QM1 was up and used the BIND ON OPEN option, in which case all future puts on the hobj handle will only want to go to QM1 whether its up or not.



By the way, did I mention that all those "EXCEPTS" go away if you use hardware clustering?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
yogibo50
PostPosted: Thu Aug 02, 2007 10:48 am    Post subject: Reply with quote

Newbie

Joined: 30 Aug 2006
Posts: 8

I mentioned in an earlier response that I had thought of using the fact that if there is only one available Qmgr it will get the messaages, even if suspended from the cluster. I tried this but it did not operate that way. the messages just sat on the SCTQ. My test was to shut down the 'primary' qmanager and then PUT to the queue from a remote qmgr knowing the only available destination was the suspended qmgr... Did not work as we all expeted it would.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Aug 02, 2007 8:54 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Let's mention the qmgr suspension once again. I did not check if this a V6 form only but the command has a dual mode IIRC (be gentle from memory)
Code:
suspend qmgr cluster(mycluster) mode(quiesce|force)

Note that the force mode stops the cluster receiver. This might explain the messages waiting on the SCTQ.

Generally speaking when we mention a suspended qmgr we think about the quiesce mode which leaves the cluster receiver channel running. This means the qmgr is fully functional in the cluster but does not participate in load balancing. However if it is the only qmgr hosting a particular cluster queue you are posting to, it will receive the message. Same if it is the only qmgr hosting a non put inhibited queue in the cluster etc...

In more general terms: If it is the only qmgr hosting a viable destination it will receive the message intended for such destination....

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Suspending from cluster if server is down
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.