| Author |
Message
|
| Jeff.VT |
 Posted: Fri Feb 03, 2023 10:28 am Post subject: Move FR? Or Create New Cluster? |
 |
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
I have a bit of a conundrum.
We've been using an MQ Cluster for our queue routing for quite some time now. But now I need to decommission the current Full Repositories. So I need to put the Full Repositories in a current Partial Repository.
We have ... I dunno... say 10,000 objects on the cluster. With maybe 200 or so being used pretty constantly.
Keeping in mind all of this is live production and can't really come down for any length of time...
I was going to follow this: https://www.ibm.com/docs/en/ibm-mq/9.2?topic=cluster-moving-full-repository-another-queue-manager
And just sort of promote one of the new nodes that will be sticking around to a FR, and then demote the old FR.
But... I just thought of another idea.
Couldn't I...
1. Create a whole new Cluster - using the new FR's that I want, add all the PRs to the New Cluster as well.
2. Then just move all the Clustered Objects to the new Cluster.
3. Once all the objects no longer appear on the OldCluster, decommission the Old Cluster.
I feel like that would be less invasive than stopping channels to delete them. |
|
| Back to top |
|
 |
| Jeff.VT |
| Posted: Fri Feb 03, 2023 10:56 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
The reason I wouldn't want to just follow the IBM Support documentation is it requires me to stop & delete channels. I feel like it's going to cause a lot of downtime.
My only real concern with going down the new Repository route is if it will be instantaneous enough to use the new channels/cluster when I change the queue. I think it will. There might be a time where both clusters claim the queue, but I don't think there will be a time when neither cluster claims it.
Even if it does happen, it shouldn't be for very long.
I know QM's can be in two clusters simultaneously. I already have that with a third party, and it seems to work just fine. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 03, 2023 11:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
Demote one of the two current FRs to a PR. Then remove it from the cluster with RESET CLUSTER command. Then promote one of the PRs to FR.
Of course, do this in test first.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Fri Feb 03, 2023 12:20 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
The real fun part is I don't have a Test environment, so I'm just kinda stuck on Production.
But here's what I'm worried about...
QM01 - FR #1
QM02 - FR #2
QM10 - Primary FR of QM01
QM11 - Primary FR of QM01
QM12 - Primary FR of QM01
QM20 - Primary FR of QM02
QM21 - Primary FR of QM02
QM22 - Primary FR of QM02
When I demote QM02 from being a FR, correct me if I'm wrong, but I'm going to have to go into QM20 and QM21 to set their primary FR to QM01? Right? Otherwise, they're both still stuck on QM02 which is now a PR, and may not be up to date.
And so in order to do that, I have to go in to QM20 and QM21 and make a Cluster Sender channel for QM01, but there's already a shadowed QM01 sender channel... so I'd have to stop the QM01 channel, delete it, then create a "real" one.
And then the same problem for when I promote QM20 to FR... I have to go into everywhere that I want QM20 to be the primary FR sender channel, and stop it, delete it, then create a hard QM20 FR channel.
Or am I thinking too much about this?
By "Real" I mean one that shows up as a Cluster Sender channel in Channels, not just in Clusters. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 03, 2023 6:21 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
In order to demote an FR, you will need to stop its channels and then remove channels and other objects from the cluster. Then, from an FR RESET CLUSTER all objects owned by the FR being demoted.
Yes, you will need to manually define CLUSSDR channels from PRs to the new FR.
You will repeat this with the 2nd FR you demote.
I'd recommend that you only demote one FR now, so you can address any problems. Your cluster can get along fine with only one FR for quite some time.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Feb 04, 2023 5:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7719
|
Best practice is for FRs to be on a pair of small dedicated servers that host no other function. This allows you to upgrade them as needed (without negotiating / coordinating / begging colocated apps on a shared QM). And dedicated servers / queue managers minimizes the risk of unrelated apps and changes impacting the critical FRs.
If you can, provision 2 new servers. They don't need to be big at all - even in large clusters the performance requirements for FRs are modest. But do segregate the 2 servers for the 2 FRs as much as possible so that the same fault doesn't take them both out at the same time.
If you can do this, you can then do a rolling migration from
FR1old and FR2old
to
FR3new and FR2old
to
FR3new and FR4new
I've done this several times over the years. I can dig up and post the detailed steps if this is a possible route for you.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Feb 05, 2023 4:21 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2527
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
Best practice is for FRs to be on a pair of small dedicated servers that host no other function. This allows you to upgrade them as needed (without negotiating / coordinating / begging colocated apps on a shared QM). And dedicated servers / queue managers minimizes the risk of unrelated apps and changes impacting the critical FRs.
If you can, provision 2 new servers. They don't need to be big at all - even in large clusters the performance requirements for FRs are modest. But do segregate the 2 servers for the 2 FRs as much as possible so that the same fault doesn't take them both out at the same time.
If you can do this, you can then do a rolling migration from
FR1old and FR2old
to
FR3new and FR2old
to
FR3new and FR4new
I've done this several times over the years. I can dig up and post the detailed steps if this is a possible route for you. |
We did this many years ago using a pair of Linux servers and reaped the rewards. MQ updates and upgrades are seamless, as we can take each FR off line with no impact.
_________________
Glenn |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Mon Feb 06, 2023 7:04 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
I feel like the least disruptive solution would be to set up a second MQ Cluster (CLUS_NEW) on top of the current one (CLUS_CUR) - but this one having the correct new FR's defined from the start. Then just re-assign each Cluster Object to the new cluster.
I'm going to test it today (send a continuous stream of messages, and change the queue's cluster assignment, and see if I lose or delay any messages). I feel like it should basically be seamless. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Mon Feb 06, 2023 9:07 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
Alright - I found the fuzzy part of the lollipop trying to create a second cluster on top of the current cluster...
A full repository on CLUSTER_CURRENT can't be a partial repository of CLUSTER_NEW
which... is fun...
-----------
*EDIT*
Nevermind, of course you can. Just can't do it through the GUI apparently. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 06, 2023 1:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
| A full repository on CLUSTER_CURRENT can't be a partial repository of CLUSTER_NEW |
Yes it can.
Qmgr attributes REPOS and REPOSNL only identify for which cluster/clusters this qmgr will be an FR. It will be a PR for other clusters.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Wed Feb 08, 2023 7:19 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
| bruce2359 wrote: |
| Jeff.VT wrote: |
| A full repository on CLUSTER_CURRENT can't be a partial repository of CLUSTER_NEW |
Yes it can.
Qmgr attributes REPOS and REPOSNL only identify for which cluster/clusters this qmgr will be an FR. It will be a PR for other clusters. |
Ya, I figured that out. When you try to add it via the MQ Explorer GUI, it says the queue manager is already part of a cluster. Just had to do it manually is all. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 08, 2023 8:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
| bruce2359 wrote: |
| Jeff.VT wrote: |
| A full repository on CLUSTER_CURRENT can't be a partial repository of CLUSTER_NEW |
Yes it can.
Qmgr attributes REPOS and REPOSNL only identify for which cluster/clusters this qmgr will be an FR. It will be a PR for other clusters. |
Ya, I figured that out. When you try to add it via the MQ Explorer GUI, it says the queue manager is already part of a cluster. Just had to do it manually is all. |
What exactly is the 'it' you were trying to add in MQExplorer? A queue manager attribute? A queue? A channel? Please be precise.
What do you mean by 'manually'? Please post the command(s) you issued and error(s) received.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
