Vxdisk shows disk error on secondary cluster

Hello ppl,

 

I need quick help to understand the below situation as i am a bit new to VCS world .

 

We have a global cluster running with 2 nodes on each site . Primary side (2) and secondary site 2.

 

The secondary site however is complete idle doing nothing and just gettng data replicated via storage disk groups.

There are usually 2 disk group on each site cluster (ossdg and sybasedg) when active . From few days i am observing on secondary site nodes (admin1 and 2) Vxvm disk errors and its hard for me to figure out is it nomral beacuse it si idle cluster. The disks on storgare looks fine with no failure however Vxvm gives error and OS doesnt see it too . Also i dont see any output for vxprint . Is this normal for global cluster. Please help me figure out if i need to take an action .

 

PFB Vxdisk list ouput :


Seondary cluster server 1
[23:18:11 root@xxx-xyz-admin1 /]>> vxdisk list
DEVICE       TYPE            DISK         GROUP        STATUS
c0t0d0s2     autoSmiley FrustratedVM        -            -            SVM
c0t1d0s2     autoSmiley FrustratedVM        -            -            SVM
c1t500601623DE03785d0s2 auto:sliced     c1t500601623DE03785d0s2  vxfendg1     on                                                                                        line
c1t500601623DE03785d1s2 auto:sliced     c1t500601623DE03785d1s2  vxfendg1     on                                                                                        line
c1t500601623DE03785d2s2 auto:sliced     c1t500601623DE03785d2s2  vxfendg1     on                                                                                        line
c1t500601623DE03785d3s2 auto:sliced     -            -            online
c1t500601623DE03785d4s2 auto:sliced     -            -            online
c1t500601623DE03785d5s2 auto:sliced     -            -            online
c1t500601623DE03785d6s2 auto            -            -            error
c1t500601623DE03785d7s2 auto            -            -            error
c1t500601623DE03785d8s2 auto            -            -            error

secondary cluster server 2

[23:19:40 root@xxx-xyz-admin2 /]>> vxdisk list
DEVICE       TYPE            DISK         GROUP        STATUS
c0t0d0s2     autoSmiley FrustratedVM        -            -            SVM
c0t1d0s2     autoSmiley FrustratedVM        -            -            SVM
c1t500601623DE03785d0s2 auto:sliced     -            -            online
c1t500601623DE03785d1s2 auto:sliced     -            -            online
c1t500601623DE03785d2s2 auto:sliced     -            -            online
c1t500601623DE03785d3s2 auto:sliced     -            -            online
c1t500601623DE03785d4s2 auto:sliced     -            -            online
c1t500601623DE03785d5s2 auto:sliced     -            -            online
c1t500601623DE03785d6s2 auto            -            -            error
c1t500601623DE03785d7s2 auto            -            -            error
c1t500601623DE03785d8s2 auto            -            -            error
c1t500601623DE03785d9s2 auto            -            -            error
 

Server icluster runs in active /active mode.

 

Let me know if any extrax info is required to analyse this.

 

 

 

 

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

HI, As mentioned before that

HI,

 

As mentioned before that EMC Mirrorview LUNS are seen in error state on the secondary site in VxVM, this is becasue the replication technology does not provide access to the device metadata on the secondary site.

You can refer to the below URL

https://www.veritas.com/support/en_US/article.HOWTO32485

https://www.veritas.com/support/en_US/article.HOWTO32495

Regards,

Sudhir

View solution in original post

10 Replies
Highlighted

Hi , I am still loking for

Hi ,

I am still loking for some help

Rgds

Mohammed

Highlighted

Which array based replication

Which array based replication are you using?

 

Regards,

Sudhir

Highlighted

Such a behaviour is observed

Such a behaviour is observed in case of EMC Mirrorview technology.

Regards,

Sudhir

Highlighted

Hello, about vxprint, you are

Hello,

about vxprint, you are not getting outputs on secondary because diskgroup is deported ... so that is normal

secondly, this doesn't looks to be a A/A cluster, as your secondary site is idle, it will takeover if some failure happens or someone forces secondary to be active .

Now about the errors you are getting,

1. Paste the exact error messages here

2. What is the version of OS & VxVM ?

3. I am assuming your replication is VVR here ? or something else ?

4. Have you made sure that disks which are giving errors on secondary are indeed part of the replicated data set from primary ? are there any additional disks in system which are not participating in replication ?

 

G

Highlighted

Also, I see that this post

Also, I see that this post was posted in "Storage & clustering documentation",  I have moved it to "Storage Foundation" forum so that others can see & contribute

 

G

Highlighted

Hello , As Sudhir Mentioned

Hello ,

 

As Sudhir Mentioned we are using EMC Mirrorview technology and not VVR. 

ok i agree for vxprint not showing any results. I am not fully sure if the disk with errors is a part of data replication set , but i assume yes if i see the disk will typically form  critical disk groups when cluster will be made online

OS Version :

uname -a
SunOS  5.10 Generic_150401-10 i86pc i386 i86pc

VxVM version :

   PKGINST:  VRTSvxvm
      NAME:  Binaries for VERITAS Volume Manager by Symantec
  CATEGORY:  system
      ARCH:  i386
   VERSION:  5.1,REV=10.06.2009.21.48
   BASEDIR:  /
    VENDOR:  Symantec Corporation
      DESC:  Virtual Disk Subsystem
    PSTAMP:  5.1.103.000-5.1SP1RP3_x86-2012-09-25-142630-16
  INSTDATE:  Mar 04 2014 20:02
   HOTLINE:  http://support.veritas.com/phonesup/phonesup_ddProduct_.htm
     EMAIL:  support@veritas.com
    STATUS:  completely installed
     FILES:      876 installed pathnames
                  44 shared pathnames
                 113 directories
                 402 executables
              376060 blocks used (approx)

 

 

What more error should i paste ?

 

One extra info i can view the device from vxddl , below marked bold

 

> vxddladm list devices
DEVICE               TARGET-ID    STATE   DDL-STATUS (ASL)
===============================================================
c0t1d0s2             -            Online  CLAIMED (Disk)
c0t0d0s2             -            Online  CLAIMED (Disk)
c1t500601693DE03785d0s2 c1_p4_t0     Online  -
c1t500601693DE03785d1s2 c1_p4_t0     Online  -
c1t500601693DE03785d2s2 c1_p4_t0     Online  -
c1t500601693DE03785d3s2 c1_p4_t0     Online  -
c1t500601693DE03785d4s2 c1_p4_t0     Online  -
c1t500601693DE03785d5s2 c1_p4_t0     Online  -
c1t500601693DE03785d6s2 c1_p4_t0     Online  -
c1t500601693DE03785d7s2 c1_p4_t0     Online  -
c1t500601693DE03785d8s2 c1_p4_t0     Online  -
c1t500601693DE03785d9s2 c1_p4_t0     Online  -
c1t500601623DE03785d0s2 c1_p2_t0     Online  -
c1t500601623DE03785d1s2 c1_p2_t0     Online  -
c1t500601623DE03785d2s2 c1_p2_t0     Online  -
c1t500601623DE03785d3s2 c1_p2_t0     Online  -
c1t500601623DE03785d4s2 c1_p2_t0     Online  -
c1t500601623DE03785d5s2 c1_p2_t0     Online  -
c1t500601623DE03785d6s2 c1_p2_t0     Online  CLAIMED (libvxCLARiiON.so)
c1t500601623DE03785d7s2 c1_p2_t0     Online  -
c1t500601623DE03785d8s2 c1_p2_t0     Online  -
c1t500601623DE03785d9s2 c1_p2_t0     Online  -

c2t5006016A3DE03785d0s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d1s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d2s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d3s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d4s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d5s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d6s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d7s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d8s2 c2_p4_t0     Online  -
c2t5006016A3DE03785d9s2 c2_p4_t0     Online  -
c2t500601613DE03785d0s2 c2_p2_t0     Online  -
c2t500601613DE03785d1s2 c2_p2_t0     Online  -
c2t500601613DE03785d2s2 c2_p2_t0     Online  -
c2t500601613DE03785d3s2 c2_p2_t0     Online  -
c2t500601613DE03785d4s2 c2_p2_t0     Online  -
c2t500601613DE03785d5s2 c2_p2_t0     Online  -
c2t500601613DE03785d6s2 c2_p2_t0     Online  -
c2t500601613DE03785d7s2 c2_p2_t0     Online  -
c2t500601613DE03785d8s2 c2_p2_t0     Online  -
c2t500601613DE03785d9s2 c2_p2_t0     Online  -

Regards,

Mohammed

Highlighted

Hi, If you are using EMC

Hi,

 

If you are using EMC Mirroeview than the disk son the secondary site show as error in VxVM. The diskgroup will be imported correctly when the replication role is changed from secondary to primar when you try to bring the service group online on the DR site.

Were these disk in a different state before? Do u have anyother cluster with similar configurations showing a different disk state?

 

Regards,

Sudhir

Highlighted

What is the version of ASLAPM

What is the version of ASLAPM in use ?

# pkginfo -l VRTSaslapm

seems like linux had some issues with lvm headers which was fixed in hotfix, worth to find if something similar in Solaris was discovered

https://www.veritas.com/support/en_US/article.TECH179423

 


G

Highlighted

Hi , To Answer @Sudhir : I

Hi ,

 

To Answer @Sudhir : I am really not sure as i have been given responsibility of this recently ,and this is the only global cluster setup we have.

@ Gaurav :

pkginfo -l VRTSaslapm

 PKGINST:  VRTSaslapm
      NAME:  Array Support Libraries and Array Policy Modules for Veritas Volume Manager.
  CATEGORY:  system
      ARCH:  i386
   VERSION:  5.1.100.400,REV=04.14.2012.07.08
   BASEDIR:  /
    VENDOR:  Symantec Corporation
      DESC:  Virtual Disk Subsystem
    PSTAMP:  5.1.100.400,2012-04-14
  INSTDATE:  Mar 04 2014 18:36
   HOTLINE:  http://www.symantec.com/business/support/assistance_care.jsp
    STATUS:  completely installed
     FILES:      225 installed pathnames
                  20 shared pathnames
                  20 directories
                 121 executables
                6685 blocks used (approx)

 

You might be true with the "linux article"  but what surprises me is that the disks cannot be seen at OS layer too . PFB .

 

21:04:14 root@xyz /]>> echo | format | grep -i dri
       8. c1t500601623DE03785d6 <drive type unknown>
       9. c1t500601623DE03785d7 <drive type unknown>
      10. c1t500601623DE03785d8 <drive type unknown>
      11. c1t500601623DE03785d9 <drive type unknown>

      18. c1t500601693DE03785d6 <drive type unknown>
      19. c1t500601693DE03785d7 <drive type unknown>
      20. c1t500601693DE03785d8 <drive type unknown>
      21. c1t500601693DE03785d9 <drive type unknown>
      28. c2t5006016A3DE03785d6 <drive type unknown>
      29. c2t5006016A3DE03785d7 <drive type unknown>
      30. c2t5006016A3DE03785d8 <drive type unknown>
      31. c2t5006016A3DE03785d9 <drive type unknown>
      38. c2t500601613DE03785d6 <drive type unknown>
      39. c2t500601613DE03785d7 <drive type unknown>
      40. c2t500601613DE03785d8 <drive type unknown>
      41. c2t500601613DE03785d9 <drive type unknown>

[21:04:38 root@xyz /]>> vxdisk list
DEVICE       TYPE            DISK         GROUP        STATUS
c0t0d0s2     autoSmiley FrustratedVM        -            -            SVM
c0t1d0s2     autoSmiley FrustratedVM        -            -            SVM
c1t500601623DE03785d0s2 auto:sliced     c1t500601623DE03785d0s2  vxfendg1     on                                                                                        line
c1t500601623DE03785d1s2 auto:sliced     c1t500601623DE03785d1s2  vxfendg1     on                                                                                        line
c1t500601623DE03785d2s2 auto:sliced     c1t500601623DE03785d2s2  vxfendg1     on                                                                                        line
c1t500601623DE03785d3s2 auto:sliced     -            -            online
c1t500601623DE03785d4s2 auto:sliced     -            -            online
c1t500601623DE03785d5s2 auto:sliced     -            -            online
c1t500601623DE03785d6s2 auto            -            -            error
c1t500601623DE03785d7s2 auto            -            -            error
c1t500601623DE03785d8s2 auto            -            -            error
c1t500601623DE03785d9s2 auto            -            -            error

 

Rgds,

Mohammed
 

Highlighted
Accepted Solution!

HI, As mentioned before that

HI,

 

As mentioned before that EMC Mirrorview LUNS are seen in error state on the secondary site in VxVM, this is becasue the replication technology does not provide access to the device metadata on the secondary site.

You can refer to the below URL

https://www.veritas.com/support/en_US/article.HOWTO32485

https://www.veritas.com/support/en_US/article.HOWTO32495

Regards,

Sudhir

View solution in original post