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 IndexIBM MQ File Transfer EditionMQFTE Failover

Post new topicReply to topic
MQFTE Failover View previous topic :: View next topic
Author Message
next
PostPosted: Mon Feb 27, 2017 8:43 am Post subject: MQFTE Failover Reply with quote

Acolyte

Joined: 02 May 2010
Posts: 70

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
View user's profile Send private message
gbaddeley
PostPosted: Mon Feb 27, 2017 3:49 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1742
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
View user's profile Send private message
rammer
PostPosted: Tue Aug 01, 2017 5:16 am Post subject: Reply with quote

Partisan

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

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Aug 01, 2017 8:04 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19424
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
View user's profile Send private message Send e-mail
rammer
PostPosted: Tue Aug 01, 2017 8:14 am Post subject: Reply with quote

Partisan

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

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Aug 01, 2017 2:10 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19424
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
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Tue Aug 01, 2017 3:53 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1742
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
View user's profile Send private message
rammer
PostPosted: Tue Aug 01, 2017 10:54 pm Post subject: Reply with quote

Partisan

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

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
View user's profile Send private message
rammer
PostPosted: Tue Aug 01, 2017 11:39 pm Post subject: Reply with quote

Partisan

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

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
View user's profile Send private message
gbaddeley
PostPosted: Sun Aug 06, 2017 5:03 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1742
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
View user's profile Send private message
fjb_saper
PostPosted: Mon Aug 07, 2017 3:42 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19424
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
View user's profile Send private message Send e-mail
rammer
PostPosted: Mon Aug 07, 2017 4:17 am Post subject: Reply with quote

Partisan

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

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
View user's profile Send private message
gbaddeley
PostPosted: Mon Aug 07, 2017 8:40 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1742
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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ File Transfer EditionMQFTE Failover
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.