| Author |
Message
|
| MQ_CMG |
 Posted: Thu Aug 24, 2006 6:04 am Post subject: MSCS/SAN Implementation |
 |
|
Newbie
Joined: 24 Aug 2006
Posts: 4
|
In one of the forms post, I notice a caution about having log files on a SAN. We are in a MSCS cluster; Active/passive with log files on a SAN. We have been in this configuration for about 4 months. Recently we started expericening performace issues. This is where messages from a remote location are arriving at a very slow rate. All other components of the system (networks, applications etc) are checking out OK. We moved the MQ configuration off of the cluster, and so far no problems. My questions are:
1. Has anyone else experienced performace problem when in MSCS configuration and how was it corrected?
2. Is there documation available on spefics do and don't in setting up MQSeries in a MSCS/SAN configuration?
Configuration:
Windows 2003
MQSeries 5.3 CSD 12
Any relavant insight would be appreciated
Thanks |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Aug 30, 2006 3:44 pm Post subject: Re: MSCS/SAN Implementation |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MQ_CMG wrote: |
| In one of the forms post, I notice a caution about having log files on a SAN. |
There is nothing wrong with that. We have had it set up that way for years.
Find out where the bottleneck is. Maybe its the remote system. Maybe its I/O from the server to the HBA. Maybe its the back end SAN that's got the issue.
Test yourself by trying to put messages to a test queue. Can you do it faster than the "remote system"?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQ_CMG |
| Posted: Fri Sep 01, 2006 8:19 am Post subject: |
|
|
Newbie
Joined: 24 Aug 2006
Posts: 4
|
Thanks for the response.
We have been in this configuration for about 4 months with no problem. This started about 2 months ago. Of course no one knows of anything that has changed 
We have moved back to a stand-alone Window 2000 server with MQ 5.3 CSD 7. We have not experienced any problems since the move.
We are working with IBM trying to determine the cause. The next step will be to move to a stand-alone (i.e. not MSCS) Window 2003 server, MQ 5.3 CSD 12. This should help rule in/out CSD12 and/or MSCS/SAN.
I am suspious of the MSCS/SAN. We've had MQSeries disruptions when data was copied from one SQL server to another. In this current case, no data was being copied. Also the System Admin and DBA have made configuration changes to elimate the interference cause by a copy
From the form, I was looking for any DO/Don't that anyone may have in configuring MQ within MSCS/SAN.
It may take a while to get get this one figured out. I will keep the form posted with our findings.
Thanks again |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Sep 02, 2006 7:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I remembered this AM that we had a similiar problem for about a week last year. Incoming channels to the QM hosted on MSCS / SAN were very slow, and the XMITQs were backing up.
Poking around, we discovered that opening files on the drive that mapped to the SAN took f-o-r-e-v-e-r. Trying to create a new file, or save a change to even a simple one line .txt file same deal. Obviously if we couldn't read/write from the SAN drive, neither could MQ, hence the reason the incoming channels were backing up; the receiver MCAs couldn't write to the logs. Another hint, our FAST channels were having no problems at all moving non persistent messages, since they don't log anything.
The Intel System Admin reset the HBA cards, and performance immediately returned. Eventually they found the real resolution, but until then, resetting the cards always worked. I emailed the admin asking what the final fix was and will post it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 05, 2006 5:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Here is the change that ultimatley resolved our issue with MQ and MSCS and SAN:
| Quote: |
Veritas DMP has required the "Look for Disappearing Devices" option enabled on the Emulex HBAs only under certain configurations. This requirement appears to change depending on the HBA driver version and DMP version/hotfix.
Of the servers examined with this issue, all have this option enabled. No servers with this option disabled, using various driver and DMP versions, have experienced these path failures during a zone change.
It would appear that the HBA driver, with this option enabled, is not allowing Veritas DMP to properly handle a path failure, preventing the path from coming back online automatically. Under normal circumstances, a zone change would send an RSCN, which would instruct the HBA to 're-discover' any new devices or paths. This information would then be passed on to Veritas.
I am recommending that you disable the "Look for Disappearing Devices" for each HBA in the server(s).
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQ_CMG |
| Posted: Wed Sep 06, 2006 3:13 am Post subject: |
|
|
Newbie
Joined: 24 Aug 2006
Posts: 4
|
Excellent information. I will be getting with our System Administrator to double check this configuration setting.
Thanks |
|
| Back to top |
|
|
| MQ_CMG |
| Posted: Wed Mar 07, 2007 1:06 pm Post subject: |
|
|
Newbie
Joined: 24 Aug 2006
Posts: 4
|
I'll close this one out. The problem was never discovered. We moved off the SAN and on to new hardware. Updated to MQ V6.0. Haven't had a problem since.
Thanks for the responses |
|
| Back to top |
|
|
|
|
