| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CLUSTERed MQM's in MVS & Distributed Platforms in a DRP |
« View previous topic :: View next topic » |
| Author |
Message
|
| cicsprog |
 Posted: Thu Apr 17, 2003 9:40 am Post subject: CLUSTERed MQM's in MVS & Distributed Platforms in a DRP |
 |
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
What kind of problems will I have given this scenario:
1) DRP Hot Site Test
2) MVS and Distributed MQM’s recovered
3) MQM’s have CLUSTERs on both platforms
4) Shared Queues in the CLUSTER
5) Stand alone CLUSTER queues (not shared)
6) Now the BIGGY, Open TCPIP Network between Hot Site and Production Enterprise
I see some doom and gloom here. Dynamic CHANNELS being created between MQM’s running on the Hot Site and Production Site where messages could flow from DRP to Production or vice-versa. Not to mention MQM’s with the same names.
What can I do to put a fence around the DRP Hot Site for MQSeries CLUSTER’s to stop any message exchange between Production/Test and the Hot Site? Remember this is only a Test.
Thanks for your input! |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Fri Apr 18, 2003 11:17 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
The Quick approach is have no routes in the network between the two sites, not use full.
Second you know how MQ-clustering works with regard to sign-in a cluster, then it's easy to create a security exit, and use it to pass only "good" qmgrs into your cluster and refuse to connect to the rest. You have ofcause allready secured your clusters.... or 
I've did some work in this field, and you can read my first drafts here:
http://d1o111.dk.telia.net/~u149101068/Cluster_security1.htm
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Sun Apr 20, 2003 12:33 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Security CHANNEL exit may do the trick.
So, just changing the port numbers for the listeners for the MQM's at the Hot Site will prevent any message exchange with my normal production/test MVS MQM images?
Just so I am clear, given this simple example, Production site:
MVS1(QM1) Listener 1415 and MVS2(QM2) Listener 1416 with CLUSTER
At Hot Site when we test our disaster recovery:
MVS1(QM1) Listener 1900 and MVS2(QM2) Listener 1901 with CLUSTER
No messages could flow from MVS1(QM1) at the Hot Site to MVS2(QM2) at the production site given the port id changes? Makes sense given the nature of the way CHANNELs hook up with each other.
Lastly, regular back-ups at the Production/Test site create the restores tapes for the Hot Site. When the Partial and Full Repository Q's for the MQM's are restored at the Host Site for the DRP test, will those Q's contain any dynamic CHANNEL CONNAME data (IP/DNS and PORT ID's) that point back to the Production/Test site? If they do, then this seems where a msg exchange could happen that you would NOT want to happen.
Obviously, a DR test in an open network is not my preference.
Regards
Jason AndersEn |
|
| 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
|
|
|
|
