| Author |
Message
|
| jasonlck |
 Posted: Wed Nov 26, 2008 2:22 am Post subject: Best practise for designing resource groups in MSCS |
 |
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
Hi guys,
I wondered where to post this here or the Clustering forum and realised clustering forum is about MQ clustering and not OS clustering.
So i'm asking how do you guys design your resource groups. I understand that there is always at least one cluster OS group for handling of the cluster. However I'm thinking of putting all my resources(MQ,Broker & DB2) into that single one resource group and share the disk and ip address with cluster OS control.
Would it be advisable? Would there be any significant issues? |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Nov 26, 2008 2:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
My advice: define a separate resource group for your components, and do not make the IP Address the same one as the cluster. Look at the dependencies, i.e. the Broker is dependent on the queue manager and DB2, so what would be gained (if anything) by putting each component in a separate resource group?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| jasonlck |
| Posted: Wed Nov 26, 2008 5:52 am Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
| exerk wrote: |
| My advice: define a separate resource group for your components, and do not make the IP Address the same one as the cluster. Look at the dependencies, i.e. the Broker is dependent on the queue manager and DB2, so what would be gained (if anything) by putting each component in a separate resource group? |
Well maybe I'll let on more information. We did not declare the need for additional IPs for Broker and thus considering to share the IP with the Cluster OS.
We wanted to create an IP for Broker, however due to procedural & security reasons, this process might take months which will definitely hamper the release date.
May I know based on your suggestion, what is the reason that you do not want to share the IP with Cluster OS? |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 26, 2008 6:00 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The OS Cluster IP is for administrative purposes according to the Wintel Sys Admins I've worked with, although I'm happy to concede that they may have been being as protective of their bits as I am protective of mine.
As far as I am concerned it is always better to assign separate IP resources to the different components, both for fault diagnosis reasons and to allow migration of those resources to other hardware - it's abstraction of hardware dependency.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 26, 2008 10:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We have an IP dedicated for the cluster group that includes the QM and Broker. And then there is a seperate IP for the cluster itself.
The below is from my build doc, showing what I have in a cluster group for a broker in MSCS.
| Quote: |
Modify the Description field for each of the Resources Types as follows:
• Volume Manager Disk Group (M) = Start 1st (Queue Files)
• Volume Manager Disk Group (L) = Start 2nd (Log Files)
• IP Address = Start 3rd
• Network Name = Start 4th
• Distributed Transaction Coordinator = Start 5th
• IBM MQSeries MSCS = Start 6th (Queue Manager)
• DB2 = Start 7th (if present)
• Broker = Start 8th (if present)
• Qpea = Start 9th (QPASA)
• Qpcfg = Start 10th (QPASA)
• Qpmon = Start 11th (QPASA) |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jasonlck |
| Posted: Wed Nov 26, 2008 5:13 pm Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
So based on what you guys are saying that putting them together is possible but not advisable due to fault rectification and isolation.
If I have really no choice, I guess I've to make do with everything in one cluster resource group. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 26, 2008 5:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And when you are connected to the cluster via the MSCS Cluster GUI Admin tool, and offline the group to fail it over, what's going to happen to your connection? Poof! Gone.
| Quote: |
however due to procedural & security reasons, this process might take months which will definitely hamper the release date. |
Not an excuse to do something wrong.
Not your problem, its the Project Manager's problem and its the Project Manager's task to chase down the people it takes to get one little IP address assigned.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jasonlck |
| Posted: Wed Nov 26, 2008 10:14 pm Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
Hi Peter,
Thanks for your reply. Yes we'll have to explain it out and let the upper mgmt to decide on the next step.
I've learnt something today!  |
|
| Back to top |
|
|
| jasonlck |
| Posted: Thu Nov 27, 2008 7:14 pm Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
Just wanna ask one more question...
Can I separate DB2 Instance into another group whilst MQ & Broker is in another group?
Will Broker be able to access the instance or they definitely have to be located in the same group? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 27, 2008 9:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You can have the Broker DB2 DB in a seperate group. If the QM and Broker (which should be in the same group) fail over, the Broker will be up that much faster if the DB2 group did not failover as well.
I keep all of them in the same group. Its a little simpler and easier to understand the dependency between the Broker and DB if both are in the same group and the Broker is made dependent on DB2 and the QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jasonlck |
| Posted: Thu Nov 27, 2008 9:44 pm Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
| PeterPotkay wrote: |
| You can have the Broker DB2 DB in a seperate group. |
Since we are able to separate them, so for the dependencies to be created for the Broker resource, am I able to redirect it to set the dependency on DB2 in another group?
Sorry havent done this so just wanna make sure the process is possible to be done. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 27, 2008 9:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jasonlck wrote: |
| PeterPotkay wrote: |
| You can have the Broker DB2 DB in a seperate group. |
Since we are able to separate them, so for the dependencies to be created for the Broker resource, am I able to redirect it to set the dependency on DB2 in another group?
Sorry havent done this so just wanna make sure the process is possible to be done. |
As Peter said what is possible may not be advisable. Think about what you are going to do when you need to failover DB2 but the broker is still running?? You have solid dependencies to consider:
MQ no dependency
DB2 no dependency
Broker dependency on both MQ AND DB2.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jasonlck |
| Posted: Mon Dec 22, 2008 5:51 pm Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
Hi guys,
I'm back. And got some new queries relating to my setup above.
Broker is now clustered on MSCS. However I would like to seek understanding is that do I need to deploy the same flow on both my active and passive node so that my flow is working??
The reason I'm using a QM for each component and setup channels for them to talk. When i deployed the message flow on the passive node only, the message doesn't get picked up. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Dec 23, 2008 2:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jasonlck wrote: |
| Broker is now clustered on MSCS. However I would like to seek understanding is that do I need to deploy the same flow on both my active and passive node so that my flow is working?? |
I'm not sure I understand this. If the Broker is under MSCS control, there is only one Broker, and it will be active on whichever node has the resource group, i.e. the active node.
| jasonlck wrote: |
| The reason I'm using a QM for each component and setup channels for them to talk. When i deployed the message flow on the passive node only, the message doesn't get picked up. |
Again, not sure I understand. Have you now got 'local' queue managers on each node?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| jasonlck |
| Posted: Tue Dec 23, 2008 2:51 am Post subject: |
|
|
Apprentice
Joined: 06 Oct 2008
Posts: 48
Location: Singapore
|
| exerk wrote: |
| jasonlck wrote: |
| Broker is now clustered on MSCS. However I would like to seek understanding is that do I need to deploy the same flow on both my active and passive node so that my flow is working?? |
I'm not sure I understand this. If the Broker is under MSCS control, there is only one Broker, and it will be active on whichever node has the resource group, i.e. the active node. |
What I'm asking is whether due to MSCS do i need to deploy the same flow on the active and passive node so that both contains the flow? Or do i jus deploy on the current active node will be fine?
| exerk wrote: |
| jasonlck wrote: |
| The reason I'm using a QM for each component and setup channels for them to talk. When i deployed the message flow on the passive node only, the message doesn't get picked up. |
Again, not sure I understand. Have you now got 'local' queue managers on each node? |
I only create QM for each component and each QM is push to MSCS for control. If your definition of local QM means not pushed to MSCS, then I do not have any local QM. |
|
| Back to top |
|
|
|
|
