| Author |
Message
|
| holgi |
 Posted: Tue Jan 28, 2003 7:30 am Post subject: Connection to several remote queue managers |
 |
|
Newbie
Joined: 28 Jan 2003
Posts: 3
|
We want to setup the following environment:
- one central communication server with MQS to handle (transform / map) incoming and outgoing messages. Message transformation is done by one single, but multithreaded application.
- 5 remote systems which have MQS installed and one single queue manager
- Differentiate between 2 connection "types": real-time (=critical) and normal
- Requirement that messages from different remote systems don't block each other.
Now here are my questions concerning the setup of our communication server, as the setup would work in different ways, but we are not sure which one is the best solution.
- Should we create an own local queue manager for each remote system on our communication server? Our current design is to use one local queue manager.
- If one queue manager is connect to all remote queue on the 5 remote systems: Do we need an own transmission queue for each destination system (1:1 relationship to corresponding channel) ?
- When communicating between 2 queue managers: Do we have to create a separate transmission queue for each connection "type" to avoid that critical messages are not blocked by message with normal priority? (To avoid misunderstandings: We currently don't use the priority attribute in the message descriptor. Instead we decided to use two separate queues)
Thanks, Holger |
|
| Back to top |
|
 |
| yaakovd |
| Posted: Tue Jan 28, 2003 10:41 am Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
| Quote: |
| Should we create an own local queue manager for each remote system on our communication server? Our current design is to use one local queue manager |
It not must - you can connect to one QMgr from remote systems, better to let do it to MQSeries - I mean 1 QMgr on each remote system, but it depends your data trafic...
| Quote: |
| If one queue manager is connect to all remote queue on the 5 remote systems... |
It is not exact, QMgr is connects to QMgr and not to remote Q. Yes, you need create transmission Q, sender and receiver channels for each connection. May be for 6 systems connectivity you can use cluster, what will save remote queues definition.
| Quote: |
| Do we have to create a separate transmission queue for each connection "type" to avoid that critical messages... |
You can use same transmission queue for both remote Q, but if you have 99% of regular messages and 1% of critical - better create separated channels. Again it depends your data trafic - MQSeries is very fast  .
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| holgi |
| Posted: Wed Jan 29, 2003 3:07 am Post subject: |
|
|
Newbie
Joined: 28 Jan 2003
Posts: 3
|
Data traffic is about 400.000 messages per day.
Each remote system already has an own queue manager. So our discussion is currently whether we should set up a corresponding queue managers on our communication server or setup one queue manager which is connected to all "remote" queue managers.
Thanks, Holger |
|
| Back to top |
|
|
| yaakovd |
| Posted: Wed Jan 29, 2003 5:06 am Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
If all 6 servers should be able to send messages to each one:
In first case you need 5 Transmition Q, 5 Senders and 5 receivers on each server.
In case of QMgr concentrator each remote server have single connection point. Also when you change your configuration (IP address etc.) you will manage it on one QMgr. In our configuration we also connected 5 remote systems to one central.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 29, 2003 3:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You are designing what is called a hub-and-spoke architecture. Your communications server is acting like the hub, the 5 remote servers are the spokes. You only need one queue manager on the hub.
If you really need 2 separate channel pairs to each spoke, then yes, you will need to seperate XMIT queues. But I think this will make your architecture more complicated. Why do you think you need separate channels? I understand that one app is more important than the others, but what makes you say that the less important app will interfere with the more important's messages?
The only way I can think of is if the less important app is flooding the system with a tremondous amount of messages and your XMIT queues are actually backing up (highly unlikely with only 400,000 messages a day). The other way is if you have an app other than the non important one that is putting very large messages (like 75 megs). These big messages will take a while to transmit, and in the meantime, your important app's messages get stuck waiting. Again, you would see this by noticing the XMIT queues backing up.
I would start with the single XMIT queue / channel pair to/from each spoke. The channels can be configured to make them very fast and effecient in moving all your messages (longer DICINT interval to alleviate channel startups, a BATCHINT of zero to immediatly send any message across, etc.) I bet it will work just fine for you.
The other option is to get rid of the hub, and just cluster all 5 remote queue maangers.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bigdavem |
| Posted: Wed Jan 29, 2003 4:26 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
| Be careful with a hub and spoke architecture. It's great to keep things simple, but that central (hub) queue manager is a single point of failure and as things get more complex, losing it can be catastrophic. |
|
| Back to top |
|
|
| holgi |
| Posted: Thu Jan 30, 2003 2:07 am Post subject: |
|
|
Newbie
Joined: 28 Jan 2003
Posts: 3
|
The reason for this central communication server is that it's provides an central interface to our backend system (non-MQS interface). So the backend system sends the data to the communication server which converts the data, determines the receiver and sends it to the corresponding remote MQS queue. In the other direction all remote servers have to send the messages to our central communication server which converts the data and sends the data to the backend system.
Proceeding with our internal discussion we now plan to use only one queue manager on our communication server (instead of a separate one per remote server) which should be connected to the queue managers of the 5 other remote servers.
Configuring the direction from the central communication server to the remote servers it's evident that we need one transmission queue and one channel per remote "destination". Our central question is now whether we should use one central remote queue for that on the communication server (which forwards the data dependent on the message descriptor to the correct transmission queue of the remote destination) or whether we should define a separate remote queue for each remote system.
Thanks, Holger |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 30, 2003 5:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You will have to make a remote queue def for each remote server. Associate each remote queue def with the correct XMIT queue. Your central app will then be the router based on message content. Is this message transformer and message router application MQSI?
And yes, a single HUB is a single point of failure unless you incorparate High Availability concepts.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
