| Author |
Message
|
| next |
 Posted: Mon Feb 27, 2017 8:43 am Post subject: MQFTE Failover |
 |
|
Voyager
Joined: 02 May 2010
Posts: 75
|
Hi,
We have an active passive set up for the MQ Gateway Queue manager using the NFS shared drive. We have the MFT queue manager as well in the active server. But we dont have an instance of the MFT server in the passive server.
If we add a multi instance queue manager to the passive server, would the MQFTE set up automatically failover and continue processing files in case of failures with active server?
Is this a right design decision for the fail over set up for MQFTE ? Anyone has seen issues in the past ? |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Mon Feb 27, 2017 3:49 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
A multi instance qmgr could failover, but you need some mechanism to failover the MFT agent process. This could possibly be done as a MQ SERVICE. I haven't looked into it.
Also, the MFT agent config directory and logs directory should failover (eg. set up on the shared drive), although its possible to have these in local directories on both servers, provided the properties files etc are identical.
It might be better to replace multi instance qmgr with a proper OS HA solution, because of the dependency on the MFT agent.
_________________
Glenn |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Aug 01, 2017 5:16 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Hi Glenn - Reopening old thread and looking at other FTE threads you have a good knowledge of the software.
Initially we were going to use MSCS but last minute issues have occurred (outside of MQ) and we may have to use Multi Instance.
MQ version will be 7.5 at the moment and MQMFT 7.5.
Ive read the online documentation and to me its very limited in detailing MFT with Multi Instance.
This is my query.
I have set up Queue Managers using MI, but how does FTE really work in this situation. The documentation shows it has to use Client Connections rather than bindings which I understand. But lets use the example
QMGR1 and Agents currently running on Node 1. QMGR1 then fails to Node 2. In the example of Client connectivity this will still work as agents can connect to MQ over the Network. But what if Node A collapses what would you suggest is the best to get this going on Node B? Copy the config to Node B as well? If so, under MI you cant configure the MFTE Services to stop / start can you, unlike in MSCS!...
Just wondering if you have thought any more around this over last few months.
Thanks in advance. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 01, 2017 8:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rammer wrote: |
Hi Glenn - Reopening old thread and looking at other FTE threads you have a good knowledge of the software.
Initially we were going to use MSCS but last minute issues have occurred (outside of MQ) and we may have to use Multi Instance.
MQ version will be 7.5 at the moment and MQMFT 7.5.
Ive read the online documentation and to me its very limited in detailing MFT with Multi Instance.
This is my query.
I have set up Queue Managers using MI, but how does FTE really work in this situation. The documentation shows it has to use Client Connections rather than bindings which I understand. But lets use the example
QMGR1 and Agents currently running on Node 1. QMGR1 then fails to Node 2. In the example of Client connectivity this will still work as agents can connect to MQ over the Network. But what if Node A collapses what would you suggest is the best to get this going on Node B? Copy the config to Node B as well? If so, under MI you cant configure the MFTE Services to stop / start can you, unlike in MSCS!...
Just wondering if you have thought any more around this over last few months.
Thanks in advance. |
MFT with multi-instance is not such a good idea. Remember MFT runs as a windows service. So when the qmgr is on the other server you still run the MFT agent....
The risk here is of course that nothing will process when the server on which the MFT agent is running is down.
As to the control of an agent over a service... only so much fun as the agents config needs to be shared.... and again the agent would not be allowed to scan anything that's local to either MQ servers... and not on the shared drive...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Aug 01, 2017 8:14 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Hi fjb
That was my thoughts as well once I got playing with it and thinking about it..
On a side note any idea what I am missing here >
I have a MAchine with multiple Queue Managers on it and QM3 is the command and co-ordination qmgr and works fine.
I wanted to do some quick testing on a new set of queue managers so created a new queue manager "MIQMGR" and for simplicity set that as the coordination queue manager. That command worked fine and the file structure path is good
c:\programfiles\ibm\webspheremq\mqft\config\MIQMGR (also there is QM3 under config
When i try to create the command process for MFT it tries to route under QM3 for some reason, which I dont want it to
This is my command
ftesetupcommands -connectionQMgr MIQMGR -connectionQMgrHost
192.168.147.161 -connectionQMgrPort 1478 -connectionQMgrChannel SYSTEM.DEF.SVRCONN
BFGUB0049E: The attempt to create a 'command.properties' property file in directory 'C:\Program Files\IBM\WebSphere MQ\mqft\config\QM3' could not be completed because a property file already exists and the force overwrite parameter (-f) was not specified.
Regards |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 01, 2017 2:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rammer wrote: |
Hi fjb
That was my thoughts as well once I got playing with it and thinking about it..
On a side note any idea what I am missing here >
I have a MAchine with multiple Queue Managers on it and QM3 is the command and co-ordination qmgr and works fine.
I wanted to do some quick testing on a new set of queue managers so created a new queue manager "MIQMGR" and for simplicity set that as the coordination queue manager. That command worked fine and the file structure path is good
c:\programfiles\ibm\webspheremq\mqft\config\MIQMGR (also there is QM3 under config
When i try to create the command process for MFT it tries to route under QM3 for some reason, which I dont want it to
This is my command
ftesetupcommands -connectionQMgr MIQMGR -connectionQMgrHost
192.168.147.161 -connectionQMgrPort 1478 -connectionQMgrChannel SYSTEM.DEF.SVRCONN
BFGUB0049E: The attempt to create a 'command.properties' property file in directory 'C:\Program Files\IBM\WebSphere MQ\mqft\config\QM3' could not be completed because a property file already exists and the force overwrite parameter (-f) was not specified.
Regards |
Bad juju all around.
If your coordination qmgr is MI everything concerning it i.e. mft config etc... should really go to the MQData path as defined in the MI set up... If you define any agent on the box you must define the start and stop agent commands as services on the qmgr. No local drive can come into play like C:\ but absolute UNC paths should be allowed like \\hostname\C$\etc...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Aug 01, 2017 3:53 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
>When i try to create the command process for MFT it tries to route under QM3
Because mqft\installations\Installation1\installation.properties is referring to QM3.
On a server, you can only have one active coord qmgr per MQ installation at any one time.
The coord qmgr has a special role in a MFT network. It should be on its own server and be highly available. Ideally, it should not be used for any agent or command queues, and not be used for application messaging, and not run on a server where there are any MFT agents.
_________________
Glenn |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Aug 01, 2017 10:54 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Thanks for the responses guys, this was just my laptop playing around with the settings it wouldn't be like that in prod.
I didn't realize you can only have one co-ordination QMGR though, as it does let you create another one without complaining .
I'll wipe old ones for my testing!..
Cheers |
|
| Back to top |
|
|
| rammer |
| Posted: Tue Aug 01, 2017 11:39 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| fjb_saper wrote: |
| rammer wrote: |
Hi fjb
That was my thoughts as well once I got playing with it and thinking about it..
On a side note any idea what I am missing here >
I have a MAchine with multiple Queue Managers on it and QM3 is the command and co-ordination qmgr and works fine.
I wanted to do some quick testing on a new set of queue managers so created a new queue manager "MIQMGR" and for simplicity set that as the coordination queue manager. That command worked fine and the file structure path is good
c:\programfiles\ibm\webspheremq\mqft\config\MIQMGR (also there is QM3 under config
When i try to create the command process for MFT it tries to route under QM3 for some reason, which I dont want it to
This is my command
ftesetupcommands -connectionQMgr MIQMGR -connectionQMgrHost
192.168.147.161 -connectionQMgrPort 1478 -connectionQMgrChannel SYSTEM.DEF.SVRCONN
BFGUB0049E: The attempt to create a 'command.properties' property file in directory 'C:\Program Files\IBM\WebSphere MQ\mqft\config\QM3' could not be completed because a property file already exists and the force overwrite parameter (-f) was not specified.
Regards |
Bad juju all around.
If your coordination qmgr is MI everything concerning it i.e. mft config etc... should really go to the MQData path as defined in the MI set up... If you define any agent on the box you must define the start and stop agent commands as services on the qmgr. No local drive can come into play like C:\ but absolute UNC paths should be allowed like \\hostname\C$\etc...
Have fun |
Thanks for the response. Im pretty sure I still have a little confusion here.
For the very simple testing I am doing I have 2 Windows Machines hosting a MI Queue Manager this being called MIQMGR.
For the data path for MIQMGR I have set \\MQDATA and Logs \\MQLOGS.
This all works fine.
MQ is installed into
c:\programfiles\ibm\webspheremq\
When I create the Co-ordination command then by default it created the mqft configuration under this c drive path, the same when i create the command and fte agents.
Now my query would be, is it possible to actually store the coordination / command and fte agents under a share rather than to the default c:\. Looking at the commands for the creation I can not see anywhere that it allows to have a non default path?
Commands ran
fteSetupCoordination -coordinationQMgr QMIQMGR -coordinationQMgrPort 1478 -coordinationQMgrChannel SYSTEM.DEF.SVRCONN -coordinationQMgrHost 192.168.147.161
ftesetupcommands -connectionQMgr MIQMGR -connectionQMgrHost
192.168.147.161 -connectionQMgrPort 1478 -connectionQMgrChannel SYSTEM.DEF.SVRCONN
fteCreateAgent -agentName AGENT1 -agentQMgr MIQMGR -agentQMgrHost 192.168.147.161 -agentQMgrPort 1478 -agentQMgrChannel SYSTEM.DEF.SVRCONN
I understand I need to update the properties file for the above to add the standby configuration.
If none of this can be carried out to a share, then I presume I also need to run the above commands on the standby host as well? thus more agents I create to that particular queue manager I need to keep in sync across the 2 nodes?
Thanks in advance |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Aug 06, 2017 5:03 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
In your MQ Data path, there should be file mqft/installations/Installation1/installation.properties, and this contains the name of the active coord QM. eg
defaultProperties=MQMYCOORD
This points to directory in MQ Data path mqft/config/MQMYCOORD, under which is all the agent configuration.
AFAIK, there is no easy way to move this elsewhere. We have accepted to leave it under the MQ Data path, as it fits in with the HA requirement for MQ and MFT to fail over together.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 07, 2017 3:42 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So setting up the following:
Coordination qmgr => MIQMGR => no problem
Command qmgr => MIQMGR => no problem
Agent qmgr => MIQMGR => no problem
Agent not residing on MIQMGR host => no problem
Agent residing on MIQMGR host => BIG problem.
The same agent configuration would need to be created on both hosts.
The qmgr would need to run a service to start and stop the agent
The agent could only monitor directories that are common to the MIQMGR host.
Hope this clears some up.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rammer |
| Posted: Mon Aug 07, 2017 4:17 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| fjb_saper wrote: |
Agent residing on MIQMGR host => BIG problem.
The same agent configuration would need to be created on both hosts.
The qmgr would need to run a service to start and stop the agent
The agent could only monitor directories that are common to the MIQMGR host.
|
Yep thats the conclusion I came to. Agents residing on the host that is within MI could be an issue, not so much from configuration but controlling the Windows Services. At least if using MSCS you can allow that to manage agents if you went that way... |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 07, 2017 8:40 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
MSCS is a practical and robust solution for controlling the qmgr, MFT agent, the apps, and cluster disk(s).
I would not even consider MIQM if MSCS were available. MIQM has limitations and difficulties, particularly when there other HA resources in the picture. It is a "poor mans" HA solution.
_________________
Glenn |
|
| Back to top |
|
|
|
|
