re : MSA30 help

[Vincent_5]

Hi Guys,
Can anyone of you help, I have 2 x rx4640 link up with two MSA30 storage via 2 port scsi card The two servers is install with hpux 11.31, configure with mirror disk ux on the two msa30 and mc service guard for fail over. It is also instal with SAP . There are 3 vg on the MSA30 with 12 x 72G disk mirror 1 grp, 6 x 36GB disk mirror another grp and 2 x 346gb disk mirror as the third. Initially, it was working fine fail over and etc. But, later part,somehow or rather the fail over seems to take a longer time and after which i tested with cluster shutdown and do vg activate and deactivate appearently the vg on the MSA take a long time to activate almost an hour which after checking it seems that the disk don't sync rite at the moment, can anyone advice what is the possible cause??

Regards
Vincent

[Torsten. · Accepted solution]

How about an "ioscan -fn" from both systems for a more detailed view.

Anything SCSI related in syslog or dmesg?

[Vincent_5]

Hi,
Thanks for the response. Attach is some of the output capture for your referrence. Please advice???


Regards
Vincent

[Vincent_5]

Hi,
Attach is some of the file for your referrence

Regards
Vincent

[Steven E. Protter]

Shalom Vincent,

If you are doing a direct SCSI connect, this is not relevant.


However if you are fiber connecting through an MSA1000 or MSA1500 switch a firmware upgrade is generally required before you can successfully connect two HP-UX based servers to your switch.

SEP

[Vincent_5]

hi,
It is a direct scsi connection, using mirror disk ux solution.Attach is other file for your referrence.

[Torsten.]

First thing I noticed:

There is a dds tape drive connected to the core I/O SCSI card. This may be a problem, see

http://www.hp.com/products1/storage/compatibility/tapebackup/IPF/Detail/16-0013-0025.html#CONTROLLERS

There are some lan failed messages.


And what is this:

Sep 28 18:34:28 sapprod1 LVM[5275]: vgchange -c n vg01
Sep 28 18:35:57 sapprod1 LVM[5470]: vgchange -c n vg02
Sep 28 18:36:18 sapprod1 LVM[5663]: vgchange -c n vg03
Sep 28 18:36:33 sapprod1 LVM[5668]: vgchange -a y vg03
Sep 28 18:40:54 sapprod1 LVM[5276]: vgchange -a y vg01


Sep 28 18:48:34 sapprod2 LVM[5931]: vgchange -c n vg01
Sep 28 18:48:40 sapprod2 LVM[5932]: vgchange -a y vg01


Sep 28 20:21:04 sapprod2 LVM[10240]: vgchange -a y vg02

Did you made the VG's cluster aware again?
Did you try to activate them in "normal" mode from both nodes at the same time?

[Steven E. Protter]

Shalom,

DDS tape drives are designed to be attached to their own scsi connector, not the core I/O of the system.

SEP

[Vincent_5]

Hi Guys,
I will check on the tape drive, thanks for the tip. As for the vgchange command, is activated when the cluster is shutdown just to simulate why the vg activation takes such a long time like one hour.

Regards
Vincent

Please let me know if any files is needed on my server to isolate the problem. Thanks

[Vincent_5]

Hi Guys,

Below is a brief description of the problem in detail

The problem manifested itself in the beginning after package was attempted to be started. The package startup took a very long time and package control log showed that it's stuck at activating the VGs exclusively. At this this time, I didn't know yet that the VGs were not properly synched. I rebooted both nodes and the MCSG cluster autostarted and package was started automatically. However, package start is stuck at activating the VGs. I waited for 10 minutes before decided to disabled auto cluster startup and rebooted both servers again.

This time round, I eliminated the cluster out of the picture by doing a "vgchange -c n" of all the 3 VGs. When I did a "vgchange -a y" now on node1, the VG activation still took a long time. Upon this happening, I just did a "vgdisplay -v" and noticed that the ALL LVs under the 3 VGs are stale. vg01 (6 disks) took around slightly longer than 30 minutes to be activated, vg02 (12 disks) took close to 2 hours to activate. vg03(2 disks) took only a few seconds which I believe is attributed to small number of disks. This time taken, I believe is because the vgchange command used to activate the VGs either in normal mode (-a y) or in exclusive-mode (-a e) has no -q n option, thus it has to wait for the VG activation to complete successfully.

The main issue here is what is the root cause for the ALL the LVs in the 3 VGs going out of synched at the same time ?

Can someone advice???

Regards
VIncent

[Aneesh Mohan]

Hi Vincent ,

Please let us know the below points:-

a) There is any notification on the LCD/OCP screen on MSA30

b) Controller LED status

c) Array status (you may get it through CLI )

d) Can you check the scsi cables connectivity


Aneesh

[Vincent_5]

Hi Guys,
The status for the servers front panel is green, same goes for the controllers on the MSA 30 is also green. As for the connectivity of the scsi the msa 30 is connected to two physical port cross link to on the scsi card in orader for the servers to see all the harddisk on the two MSA30

Regards
Vincent

[Aneesh Mohan]

Please let me know are u tried vgsync for this Vg`s and also are u getting the delay on both the server for activating the vg`s.


Aneesh

[Vincent_5]

Hi,
Yes, you are rite in a way, by doing a vg change to activate the vg there's a delay in the sync of the vg's both servers

Regards
Vincent

[Aneesh Mohan]

Hi Vincent,

vgsync is completed without any issues ?,pls post the output of the below command .

# vgdisplay -v |grep -e stale -e "unavail*"
# lvdisplay -v /dev/vg*/lvol* |grep -e stale |wc -l

If above commands completed with no outputs ,then please check the vgchange again.


Aneesh