| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Agents HA |
« View previous topic :: View next topic » |
| Author |
Message
|
| telesguilherme |
 Posted: Fri May 23, 2014 4:52 am Post subject: Agents HA |
 |
|
Acolyte
Joined: 16 Feb 2008
Posts: 56
|
Dear All Experts,
I was reading the documentation of the approach to HA with MQ FTE.
On the Getting Started with WebSphere MQ File Transfer Edition V7, i have found:
"FTE agents and queue managers in two machines are set to the same
configuration, including agent name, QM name, queue name, and so on. They use internal IP addresses (192.168.0.1 and 192.168.0.2) in the hardware cluster and share the same floating IP address (192.168.65.131) that the HA software manages. In the default configuration, the floating IP is directed to the FTE master server"
And on the MQ documentation:
http://www.ibm.com/developerworks/websphere/library/techarticles/0807_hsieh/0807_hsieh.html
"Queue manager names should be unique in the MQ network and reflect the location, function, and environment of the queue manager (dev, test, etc.)"
What is the best advice ? |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Sun May 25, 2014 3:20 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
What issue do you have with the advice? The qmgr and agent names are unique and can only run on 1 node of the HA cluster at at time.
_________________
Glenn |
|
| Back to top |
|
|
| telesguilherme |
| Posted: Mon May 26, 2014 5:22 am Post subject: |
|
|
Acolyte
Joined: 16 Feb 2008
Posts: 56
|
On the Getting Started with WebSphere MQ File Transfer Edition V7, i have found:
"FTE agents and queue managers in two machines are set to the same
configuration, including agent name, QM name, queue name, and so on. They use internal IP addresses (192.168.0.1 and 192.168.0.2) in the hardware cluster and share the same floating IP address (192.168.65.131) that the HA software manages. In the default configuration, the floating IP is directed to the FTE master server"
And that statement refers to an aproach without shared disks. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon May 26, 2014 3:13 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| telesguilherme wrote: |
| And that statement refers to an aproach without shared disks. |
The statement seems OK for a HA scenario. How could it possibly work without shared disks for MQ and FTE data? Where does it say its doesn't require shared disks?
_________________
Glenn |
|
| Back to top |
|
|
| telesguilherme |
| Posted: Tue May 27, 2014 5:43 am Post subject: |
|
|
Acolyte
Joined: 16 Feb 2008
Posts: 56
|
Here:
13.2.1 Using active-standby without shared disks
A full HA clustering is not always necessary when considering an HA solution. If
you are willing to resend a file transfer request at a later time when the master
queue manager or server is out of service, you can use the simple HA method for
FTE without shared disks. If you do not care about transfer log loss on the
coordination queue manager, you can also use this solution. In Figure 13-7 on
page 335 there is an FTE master server (active machine) and secondary server
(standby machine) in Washington, and an HA software is installed and
configured in the two servers.
FTE agents and queue managers in two machines are set to the same
configuration, including agent name, QM name, queue name, and so on. They
use internal IP addresses (192.168.0.1 and 192.168.0.2) in the hardware cluster
and share the same floating IP address (192.168.65.131) that the HA software
manages. In the default configuration, the floating IP is directed to the FTE
master server.
Two servers both utilize the local disks for logs and queues. You can still set FTE
system queues (SYSTEM.FTE, SYSTEM.FTE.COMMAND.<AGENT>,
SYSTEM.FTE.STATE.<AGENT>, and SYSTEM.FTE.EVENT.<AGENT>
queues) to persistence for transfer log integrity, agent recovery, and file transfer
checkpoint. This set up means that if agent recoverable exceptions and network
timeouts occur, file transfer commands and statuses can be kept in the persistent
system queues that reside on local disks, the file transfer is recovered to the last
checkpoint when the agent begins to work, and the network is connected
between source and destination.
Under normal circumstances, the files that are transferred from the FTE server
on New York are sent to the master FTE server on Washington. When the
master FTE queue manager on Washington is not available, the HA software can
find this failure within the heartbeat interval and switch the floating IP to a
standby FTE server. When the new file transfer request is submitted, a
secondary FTE server starts to take over and transfers files.
We suggest that before you want to recover the master machine, you kill the
agent, do an fteCleanAgent on the agent in the master machine, and then restart
the agent again. When the agent is restarted with empty FTE queues, it might be
necessary to clean up the transfers from the other agents that are participating in
the transfers that were current when the agent failed over to the other server.
Use the fteCancelTransfer command to do this if the other agents and the
transfer IDs are known. If they are not cleaned details, the original transfers will
remain in the SYSTEM.FTE.STATE.<AgentName> queue of the agents. Also,
the SYSTEM.FTE.EVENT.<AgentName> queue holds details of scheduled
transfers and directory monitors, and these are not copied across to the new
server |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue May 27, 2014 4:51 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
That's not really a HA solution in the true sense of the words. "If you are willing" "If you do not care" indicates there are compromises that you would probably not want in a prodution scenario. Personally, I would never cut corners like this.
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
