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 IndexGeneral IBM MQ SupportPossible limitations of using MSCS

Post new topicReply to topic
Possible limitations of using MSCS View previous topic :: View next topic
Author Message
rammer
PostPosted: Tue Jun 20, 2017 1:23 am Post subject: Possible limitations of using MSCS Reply with quote

Partisan

Joined: 02 May 2002
Posts: 343
Location: England majority USA the rest..

Hi All,

Wondering if any one can assist on my query or give advice.

I have a client that has a single Server running 10+ Queue Managers on Windows and is looking to move this to Microsoft Clustered Server (MSCS) This is their design decision I have no sway either way.

At the moment I can see two options

1) They could put all Queue Managers into one resource group in Windows and lets say assign E:..../logs & F:..../data and sub directories underneath for QMG1,2,3 etc...

2) They could create separate LUNS per Queue Manager splitting out logs and data. So example QMGR1 has E & F, QMGR2 G and H. These can then be treated as seperate resources assigned unique IP's and failover independently of each other.

A limitation I can see is that its only possible to have just over 20 drive letters due to C, D and possibly a couple of other drive letters being taken by the O/S. Meaning going for option 2 you can only have a maximum of around 10 independent queue managers?

I notice that on Windows you can use Mount Points, just starting to read up on this.

Sorry if my explanation is a little wooley. I have ever only supported MSCS on single Queue Manager installations, and on Unix for multiple Queue Managers.

Any advice appreciated.

Thank you
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Jun 20, 2017 1:41 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5749

MSCS will try and restart an entire resource group if there is an issue with just one component of it, therefore, if all your queue managers are in the same resource group, if one fails to start they will all fail to start and you can be in an endless loop of retries, or until the set retry limit is reached. Also bear in mind that it if the issue is a volume group it may even fail to start on another server in the cluster.

I confess to never having used mount points in Windows as generally speaking I have never configured more than five MSCS-controlled queue managers on any one set of servers.

Have they considered using more servers to split the load, or Multi-Instance?
_________________
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
View user's profile Send private message
rammer
PostPosted: Tue Jun 20, 2017 1:56 am Post subject: Reply with quote

Partisan

Joined: 02 May 2002
Posts: 343
Location: England majority USA the rest..

Hi Thanks for the response,

Yep understood if all grouped together they all stop / start together, that seems the way they have it now on various sites.

The reason I was trying to look into splitting them all out into individual resources was to give them greater flexibility ie they can run 5 on one server and 5 on the other server (they have purchased a 2 node solution), but the limitations will still be there using drive letters if / when they fail over and possibly all end up on same server. I also guess at config time of clusters no matter which server they run on initially the limit of drive letters will occur.

Multi Instance has been mentioned but wont be considered at the moment as they are predominantly using MSCS within the company, so dont want to look into anything new at this time.

Worse case we can deliver what they are used to ie all in one resource group, but just trying to give greater flexibility..
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Jun 20, 2017 2:14 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5749

I agree with your flexibility approach, and was not suggesting running all on one node - a massive waste of resource - but MSCS is not restricted to just two machines and resource groups can be affinitised to particular servers...
_________________
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
View user's profile Send private message
fjb_saper
PostPosted: Tue Jun 20, 2017 5:03 am Post subject: Reply with quote

Grand Poobah

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

Don't try to run each queue manager in its individual resource group. As you noticed you'd be running out of drive letters fast.

Group them into multiple resource groups. So let's say 4 groups of 5 for 20 queue managers?

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
rammer
PostPosted: Tue Jun 20, 2017 5:14 am Post subject: Reply with quote

Partisan

Joined: 02 May 2002
Posts: 343
Location: England majority USA the rest..

Thanks fjb_saper

A few thoughts I had on grouping queue managers (as they have now on other sites)

Negatives
Failure of 1 Queue Manager means others in that group will also take a hit.

Positives:
If in groups allows group1 for example to run on Node A whilst group2 run on Node 2 thus spreading out processing power, exta IP will need allocating to group2 and so on if more than 1 group.


The use of Mountpoints to me looks like it can be used and in theory double the amount of drive letters for example
QMGR1 could be allocated to G with mount points to Logs / Data both on G, rather than having G for logs and H for Data, and so on for each QMGR. That is if I have understood mountpoints correctly.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Jun 20, 2017 5:44 am Post subject: Reply with quote

Grand Poobah

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

rammer wrote:
Thanks fjb_saper

A few thoughts I had on grouping queue managers (as they have now on other sites)

Negatives
Failure of 1 Queue Manager means others in that group will also take a hit.

Positives:
If in groups allows group1 for example to run on Node A whilst group2 run on Node 2 thus spreading out processing power, exta IP will need allocating to group2 and so on if more than 1 group.


The use of Mountpoints to me looks like it can be used and in theory double the amount of drive letters for example
QMGR1 could be allocated to G with mount points to Logs / Data both on G, rather than having G for logs and H for Data, and so on for each QMGR. That is if I have understood mountpoints correctly.

And how are you going to handle the mount points when you need to fail over to the other side?
Same thing you need to group your assets.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
rammer
PostPosted: Tue Jun 20, 2017 5:55 am Post subject: Reply with quote

Partisan

Joined: 02 May 2002
Posts: 343
Location: England majority USA the rest..

Maybe my misunderstanding but if it was something like this

QMGR1 G
QMGR2 H
QMGR3 I
QMGR4 J
QMGR5 K
QMGR6 L
QMGR7 M
QMGR8 N

Data and Logs for each QMGR put to there own mountpoint but mapped to same drive so QMGR1 G, QMGR2 H etc thus not taking two drive letters up.

Each QMGR has its own resource

If the above assumption works (yes we will have to find a server to trial it on)

Then each resource can run on either Node without having an impact on other queue managers and each queue manager is only taking one drive letter up. So there could be upto 20 queue managers configured in the cluster rather than needing to group queue managers? I dont envisage they will need to go to 20 though!.. but you never know
Back to top
View user's profile Send private message
rammer
PostPosted: Wed Jun 28, 2017 2:20 am Post subject: Reply with quote

Partisan

Joined: 02 May 2002
Posts: 343
Location: England majority USA the rest..

ok, so I still dont have access to Windows Servers to start doing some hands on testing / configuration but I may have a previous misunderstanding of how it works.

Initially I thought when setting up the Queue Manager for 1 Queue Manager I would set up 2 LUNS on the shared storage for example
\QMGRA\ and also QMGRA\LOGS and these would be represented as shared drives
E & F respectively.

Now reading the documentation it appears that I still set 2 luns up but they will be accessable via one share? Am I reading this correct anyone using MSCS can probably tell me straight away!..

hamvmqm /m qmname /dd " e: \ IBM MQ " /ld " e: \ IBM MQ \log"


https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.con.doc/q018000_.htm

**Edit** I guess I can have them both under E or actually split them out by using another drive letter for \...\log.


Regards
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Wed Jun 28, 2017 4:28 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1732
Location: Melbourne, Australia

We have a Win2012 MSCS cluster with 2 resource groups, to run 2 sets of IIB + MQ + 3rd party job scheduler + 3rd party app monitor + File server.

The MQ log and qmgrs directories are on the same drive, and this drive is also used for other app data that is in the same resource. So, only 1 drive letter is being used per resource group. This might not be the best choice for ultimate performance or reliability, but it has been rock solid for us.
_________________
Glenn
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportPossible limitations of using MSCS
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.