| Author |
Message
|
| George Carey |
 Posted: Thu Oct 11, 2007 1:46 pm Post subject: Need drawings don't we!! |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Bruce2359, sorry a lot of assumptions in low end details in this dialogue, but I think I understand what Peter and Scott are both saying because it is likely we tested/tried the same MQ architecture setups, so it seems a short hand for the details can be given and still be understood. (for the moment anyway!!)
On your z/OS comment. Yes I know that MQ on z/OS with shared queues and CF coupling facility has HA covered and GDP SYSPLEX has much better/simpler options for inter site connectivity. I mentioned it more for completeness as we do not use z/OS a (sister site does however). The tougher problem for intersite connectivity is for distributed platforms which we use. That is our situation (now anyway). Don't see customer bringing in z/OS any time soon. But the reference you give me is the type of info I am looking for, thanks.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| George Carey |
| Posted: Thu Oct 11, 2007 2:09 pm Post subject: John who?? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
IJeffLowrey said:
| Quote: |
| In addition, John's suggestion prevents MQ administrators ... |
John, who?? Did you mean Peter? Otherwise, yes I agree.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 11, 2007 2:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Oct 11, 2007 2:56 pm Post subject: Author |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Ah, yes sorry missed it ... Was just looking at the auther column and apparently not checking sig lines either! 
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jsware |
| Posted: Sun Oct 14, 2007 1:11 pm Post subject: Re: Good stuff |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| George Carey wrote: |
| Did you say this was an actual setup of yours with Clustering between sites or was this initial thoughts? What Cluster channels between sites main benefit is the auto detection of channel failure and rerouting of new messages. This could be handled with SDR/RCVR channels if used in conjunction with some monitoring tool like Veritas or the like. Any one done anything in that space. |
This was me just making suggestions. We have nothing more than two physical hosts and a single qmgr which fails over from one host to another in the event of a hardware problem.
I agree that if the OURCLUSTER gets messed up then you could be in a fix. Cluster tools & support are better these days than with older MQ versions. However, if your business partner has less than perfect MQadmins, you could be in a fix more often than you want.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| George Carey |
| Posted: Mon Oct 15, 2007 8:44 am Post subject: Perfect Admins...know of any? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Scottj2512(john) wrote:
| Quote: |
This was me just making suggestions. We have nothing more than two physical hosts and a single qmgr which fails over from one host to another in the event of a hardware problem.
I agree that if the OURCLUSTER gets messed up then you could be in a fix. Cluster tools & support are better these days than with older MQ versions. However, if your business partner has less than perfect MQadmins, you could be in a fix more often than you want |
Was hoping someone had actually tried/done this... oh well. On the perfect MQ Admin thing...don't know of any do you?? Even if you did it would be more a coordination challenge than an admin challenge. Seems like the SDR/RCVR channel failure detection and repointing SDR side chl option is best so far.
And as I say I actually tested this successfully with partner site for inbound to us. We had outbound to them covered by using Clustered Gateway(GW1,GW2) QMs. If traffic to one GW (outbound) failed the MQ Cluster auto routed to other GW QM to keep a continous outbound flow. Both GWs would be SDR/RCVR chl connected to sister site. It was still possible SDR/RCVR chls to sister site were down but not QMGRs (as Peter P. noted) but it was considered low probability and was the reponsibility of the network folks to have a HA solution for the network connectivity in the site to site cloud. Thus ball no longer in MQ transport court. But this is still the issue!!!!
Sounds like a possible Entrepreneurial opportunity for a Custom 'Channel Exit' or Custom MCA for intersite to intersite connectivity that could be setup/administered to autodetect channel failure and repoint to new QM. Thus avoiding site-to-site Cluster admin issues. Perhaps a concept similar to Client Channel Table but instead for site-to-site sdr/rcvr MCAs could be implemented. Call it the new S2SMCA, just ruminating here !! Any takers?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding")
Last edited by George Carey on Mon Oct 15, 2007 9:45 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 15, 2007 9:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The three cluster option is the only option that will provide a good level of security and "keep your hands off my qmgrs" between the business partners.
You still need to keep an eye on the cluster security of OURCLUSTER, and ensure that the remote admins do not have any rights to create or modify or etc. the definitions on your half of OURCLUSTER.
And you certainly want very good firewalls, and to make sure that there are NO open SVRCONNs on your half of OURCLUSTER.
The Datapower appliance, in some configurations, can (I believe) be configured to go get messages from a remote site, and run them through security stuff, and then put them to a local queue manager. And likewise get messages from a local qmgr and put them on a remote qmgr. Talk to your IBM Sales representative to be sure.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| George Carey |
| Posted: Mon Oct 15, 2007 9:57 am Post subject: Datapower solution |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Jefflowrey wrote:
| Quote: |
| The Datapower appliance, in some configurations, can (I believe) be configured to go get messages from a remote site, and run them through security stuff, and then put them to a local queue manager. And likewise get messages from a local qmgr and put them on a remote qmgr. Talk to your IBM Sales representative to be sure. |
I have actually seen a demo of this appliance, more in the encryption, decryption, translation space than in this(can't remember the details now unfortunately) but I do remember being very impressed. I like hardware plug and play solutions (if not too expensive!). This is worth looking into! If you have more info please post or send email, thanks.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Oct 16, 2007 9:51 am Post subject: MQ Client to Server site to site |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
The discussion so far has been heavily(almost entirely) focused on SDR/RCVR channels whether Clustered of not for site to site connectivity.
Can anyone offer MQ Client to MQ Server site to site connectivity pros and cons. A new customer is pushing that connection option. I have my reservations but it seems a synchonous request/response is what is desired by the application developers. Any site to site user out there using MQClient to MQServer and who like it and why or not and why?
Note that the end of the discussion may give if not a best practices for site to site messaging connectivity at least good options for site to site connectivity with reasons.
Regards,
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Oct 17, 2007 3:53 am Post subject: Re: MQ Client to Server site to site |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| George Carey wrote: |
| Can anyone offer MQ Client to MQ Server site to site connectivity pros and cons. |
Tried it. Not recommended. The application at the client end must do all of the failure handling (network failures and all that) reconnection logic (only attempt to re-connect 1ce every 30secs until we've done 10 attempts and then 1ce every 10 mins) and must keep track of what messages it has delivered. You also get into the situation where you issue an MQCMIT and get back say a "connection broken" 2009 error. Now did the connection break just before or just after the MQCMIT worked on the qmgr - or did it fail and you couldn't be told because the connection failed 
This is all stuff that the qmgr does for you. Connecting to a local qmgr, put a message and let mq handle all this networky stuff.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Oct 17, 2007 8:40 am Post subject: MQ Client site to site issues |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Yes I remember just recently reading some white paper or article off the web about just what you are referring. Whether MQCMIT or MQBACK same problem exists with time at which failure might occur, an in doubt state as to if message sent or rolled back, is unknown. Thus dups or omissions could occur, depending, according to article. If I find url I will post it. My understanding is that SDR/RCVR MCA's can better resolve these conditions automagically.
Ok, also socket connections can these not easily be maxed out either intentionally or unintetionally causing effective denial of service to one' s MQ server.
Also what about the added risk of foreign applications having full and direct api access to one's MQ Server. OAM can pin down the user id to specific objects but one has no control over remote user id admin policies. These issues could more easily be obviated with sdr/rcvr channels could they not, where no remote Geting access is even possible!
Others agree/disagree more pros/cons ?? Pointers to articles, etc. ..
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 17, 2007 10:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The previous 2 posts pretty much nailed it. The less control you have over the remote MQ Clients, the farther away they are physically, the more likley you should have them connect to their own QM and then have that QM connect to yours.
Note that the possability of getting a 2009 on a MQBACK or MQCMIT call exists even for an app connected in bindings mode, but obviously its much, much more less likely to happen.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 17, 2007 11:18 am Post subject: |
|
|
Guest
|
A client app still might be a good choice where a qmgr is not appropriate (on desktop pcs), where the application is not sensitive to unit-of-work processing, where there is no message-affinity (to another message or qmgr).
The client channel table offers application developers the possibility of connecting to one specific qmgr, or to one of a group of qmgrs.
A payroll time-card application example: I (as end-user) don't care which qmgr processes my time-card. I (as end-user) don't want a qmgr instance on my laptop/desktop. A single time-card message doesn't need (might not need) to be part of a unit of work - a downstream program will check for duplicate or missing time-cards. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Oct 18, 2007 4:53 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| PeterPotkay wrote: |
| Note that the possability of getting a 2009 on a MQBACK or MQCMIT call exists even for an app connected in bindings mode, but obviously its much, much more less likely to happen. |
I agree with this statement entirely, but the manual has this to say about MQRC 2009:
| Quote: |
| For MQ client applications, it is possible that the call did complete successfully, even though this reason code is returned with a CompCode of MQCC_FAILED. |
This above statement says that it may complete for MQ client applications. The assumption here is that this would never occur for bindings mode - I know when you assume you make an ass out of u and me
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Oct 18, 2007 10:15 am Post subject: Best Practices or good options |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Trying to stay with my intial quest for 'site to site' best practices/rules or good options. I see Peter P. giving the seed of what might be one with the comment:
| Quote: |
| The less control you have over the remote MQ Clients, the farther away they are physically, the more likley you should have them connect to their own QM and then have that QM connect to yours |
I try then to apply that to bruce2359 post with PC based clients doing time sheet submittals, and think that 'distance' in Peter P. rule of thumb should not be considered in physical or network distance but in business affliation proximity. For example the time sheet PC apps could be across the street from the server or across the country but maybe part of the same business entity and needing VPN network connection to server but a MQ client connection likely still makes sense as described.
But entities that may not be closely functionally or otherwise affliated but may still need to share some information between them even if phycisally in the same building should use a MQ server to MQ server connection, for reasons given previously.
Getting back to other options: what about the DATAPOWER product(mentioned by JeffL.). It apparently even has an option to take MQ messages right into other vendor's message service such as TIBCO EMS for example. What about DATAPOWER boxes as gateway sentinels with all the customizable security options that can at hardware speed inspect/validate messages content before it even enters one's enclave. If these boxes had HA capability you could have configurable site to site security and availablity covered in a plug and play manner at the message level.
Thoughts??
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
