| Author |
Message
|
| kanand2585 |
 Posted: Thu Oct 27, 2011 7:27 pm Post subject: Setting Multi Instance q manager in windows |
 |
|
Newbie
Joined: 15 Sep 2011
Posts: 2
|
Hi Experts,
We are implementing multisntance q manager for high availbilty in windows 2008. The project is entire from scratch and i need to know the prerequisite of installing to configuring Multiinstance q manager.
I have gone through ibm docs regarding the same however just wanted some clarification regarding hopw to plan for
1>Automatic switching of ipaddress to standby machines.
2>Automatic client reconnection to standby ,will admin intervention wud be required.
3>2 Physical machines so 2 sepearte licesnse would be required for MQ installation?
4>Whaty would be the best approach of the MQ client conencting to MQ server through MQCHLTAB or through clinet server connection channel.
5>the application is VB 6 as i havve read in ajva there is no autaomatic switching of ipaddress supported.
Any resposne from your side is appreciated. |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Oct 28, 2011 12:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
1. There is no automatic switching of IP addresses, the discrete IP address of each server is used;
2. Depends on the version of client being used, and how the MI queue manager fails over;
3. Generally a licence is required for each server on which the software is installed;
4. A client doesn't connect through a CCDT, it uses the information within one to form a connection.
I strongly suggest you read the manuals agian, more closely, and also ensure you will be allowed to configure an MI queue manager - Windows MI queue managers can only be configured on Domain Controllers.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| markt |
| Posted: Fri Oct 28, 2011 12:33 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| Quote: |
| Windows MI queue managers can only be configured on Domain Controllers. |
Not true with V7.1 |
|
| Back to top |
|
|
| kanand2585 |
| Posted: Fri Oct 28, 2011 1:19 am Post subject: |
|
|
Newbie
Joined: 15 Sep 2011
Posts: 2
|
My bad for 1> point as i meant autamatic failover not automatic switching
As per my undertanding automatic ipadress is pointed to queue manager which acts as standby when it fails over in scenarios of abrupt close and without issuing command endmqm.
I was confused while reading it "Ip address is not taken over" does that means tha once the lock on qmanager data held by active instances is released , the failover happens and than standby isntance becomes active and automatically client connection points to qmanager whihc is running.
I am new to MQ however will try to understand as much through response and ibm documentaion. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 28, 2011 1:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MI queue managers do not move IP addresses.
MSCS might, but MI queue managers don't.
So you have box A with IP address X, and box B with IP address Y.
Then your channels point to BOTH IP address X and IP Address Y. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 28, 2011 1:56 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The need to support two different MQ client connection IP names/addresses is an impossible one for us to meet.
It would need 90% of our MQ client applications to be re-written (very few use a CCDT) and some are vendor written (who are unlikely to change them).
There is a clear need for a script that can re-direct a DNS entry to the current queue manager IP address following a MI failover (or even better it could just switch a DNS alias between two DNS names). This could be run as a QMGR service command.
Would some kind person at IBM please write such a script (for AIX etc). Then the world at large could actually make use of this great new feature? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 28, 2011 3:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
CHANGING THE DNS ENTRY IS THE WRONG APPROACH.
Use IPCONFIG/IFCONFIG to move the address pointed to by a DNS name.
You already have a script to do this. It is part of your normal processes for doing HA failover under non-MI. |
|
| Back to top |
|
|
| markt |
| Posted: Fri Oct 28, 2011 3:49 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| Quote: |
| This could be run as a QMGR service command. |
No it couldn't.
Changing IP addresses on Unix systems typically needs root authority, which the qmgr does not have. You'd have to either have a root-setuid program (which is not likely to be shipped with MQ itself as many people would not want such a program always installed), or script something via sudo. Which you can trivially do yourself if you've configured sudo to be available to mqm, but cannot be assumed by MQ code. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 28, 2011 4:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I am unlikely to be allowed to experiment with root authority and our DNS service.
As far as authorities go - yes we could use sudo to allow mqm to run the script as root.
This would make a great support pac - I am disappointed that you think this is not the case.
I am not talking about changing IP addresses on the Unix server that MQ runs on. I am suggesting that MQ (via this command) notifies the DNS service to update its entry for a given DNS name.
Then clients will connect to the new IP address, if they use the DNS name/alias for their MQ server (which they do), once the DNS change has replicated.
So if DNS value MQ-PROD points to server A, then MI fails the QM there over to server B, the script that runs on B would instruct the DNS server to update the DNS entry MQ-PROD to have the IP address for B (instead of A).
MQ clients simply use MQ-PROD as their connection address name.
I believe the nsupdate command is used to update a DNS zone, it might be trivial to an IBMer, but we don't get to develop code or even scripts much out here. As always, a working (and tested) example/sample would make life much easier - if it really is simple that's even better.
http://linux.yyz.us/nsupdate/ |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 28, 2011 4:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| I am suggesting that MQ (via this command) notifies the DNS service to update its entry for a given DNS name. |
I am telling you that this is the wrong way to solve this problem.
You can not guarantee that the client will receive the "new" DNS resolution in a timely fashion. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 28, 2011 5:05 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Better than nothing, Jeff and much better than a manual process - whereby I would have to raise a request to the network team and wait possibly hours for it to be actioned.
I realise the DNS replication time limitations. But it would allow us to use MI (rather than just admire it!). 
We could then say that well-written clients (using multiple connection strings) would get immediate re-connection, and less well written clients (using a single connection string) would reconnect once the (automatically initiated) DNS change propagated.
As it stands we cannot ever expect all the MQ client apps to be able to accept multiple connection addresses, or use a CCDT.
The real world cannot always conform to the IBM idea of perfection, sorry.
Trying to get third-parties to change their app code is a nightmare, even if we decided to re-write and re-test all of our own MQ client applications.
http://linux.yyz.us/nsupdate/nsupdate-man.html |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 28, 2011 6:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| markt wrote: |
| Quote: |
| Windows MI queue managers can only be configured on Domain Controllers. |
Not true with V7.1 |
Would you care to elaborate please, as I can find nothing in the announcement that supports this. As far as I am aware the 'problem' lies with the fact that the replication of SIDs is only possible on Domain Controllers, so would be interested to know what has changed in WMQ V7.1.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 28, 2011 7:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Better than nothing, Jeff and much better than a manual process - whereby I would have to raise a request to the network team and wait possibly hours for it to be actioned.
I realise the DNS replication time limitations. But it would allow us to use MI (rather than just admire it!). |
I'm confused quite a bit about this.
Do you have any queue managers that are currently under any sort of HA configuration? HACMP, MSCS, Veritas, etc?
In all cases where you have a queue manager that is NOT an MI queue manager and it is under HA, there is a *virtual* IP address that *moves* between boxes during failover. This movement of the IP address is handled by the HA manager - the HACMP service or etc.
Whatever mechanism is used to make this IP address move is the same one you would use, potentially from an MQ service object using a sudo command, in an MI situation where you needed to provide a single IP address to the clients that can't use an MI connection string.
And there's no reason to use an MI queue manager if you already have existing HA configurations. Just use the same HA configurations in v7, except modified as documented in the InfoCenter to take advantage of the changes in v7 to support MI. |
|
| Back to top |
|
|
| markt |
| Posted: Fri Oct 28, 2011 7:59 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| Quote: |
| I can find nothing in the announcement |
Not everything gets written in the announce material ...
There's a new option on crtmqm that allows things to be done to file permissions that could not be done during a service-stream update that has to be capable of being rolled back.
For much more info on what's in V7.1, far more than can be fitted in an announce letter, there have been various presentations in a number of places - next "public" event I know of is December 6 at the NYNJUG though there might be others, including webcasts.
And of course the new InfoCenter will be available soon.
Last edited by markt on Fri Oct 28, 2011 9:31 am; edited 1 time in total |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 28, 2011 9:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Jeff, we do have HA/CMP now but I would prefer to use an integrated MQ feature if possible.
Aside from the high HA/CMP license cost, it is a bolt-on to MQ which needs special start/stop scripts and other things. We really don't use many of its features, other than simple failover if the system is entirely down.
HA/CMP does the job - but at a cost and configuration complexity I would prefer to remove. I don't have root access, so I have to keep asking for Unix resource to do anything with HA/CMP.
For those who haven't got hardware HA, MI would still be better if it could be operated as I suggested - why are you opposed to that?
Software HA also has the potential to operate across sites, reducing our need for two clusters, to one. Geographic HA/CMP is in theory possible but I am told that we can't do it for various network reasons. |
|
| Back to top |
|
|
|
|
