Overblog
Suivre ce blog
Administration Créer mon blog
17 décembre 2011 6 17 /12 /décembre /2011 19:05

 

Petite astuce sur une problématique connue par tous les administrateurs Solaris utilisants des baies du types CLX et VNX (baie clariion chez EMC) avec le gestionnaire de multipath natif de Solaris MPxIO.

 

En simplifiant grandement, lors de la première attribution de Lun(s) sur le serveur Solaris, le mécanisme de la baie utilise un type de lun spécifique appelé LUNZ. Il s'agit ni plus ni moins d'une lun d'administration qui à l'image des Gatekeeper sous DMX ne s'intégre pas à la configuration MPxIO du serveur (je ne détaille pas ici les raisons). Une fois l'attribution des luns effectuée sur le serveur, cette LUNZ est substituée par une lun classique. Mais voilà le probléme, la configuration MPxIO n'est plus correct. En effet la Lun qui reprend la position de la LUNZ n'est pas sous contrôle MPxIO. Le plus simple est de rebooter le serveur en mode reconfiguration mais en production ce n'est pas toujours possible.

 

Voilà donc la solution de ce petit problème que j'ai plaisir à répéter un peu trop souvent à mes collégues :)

 

# luxadm probe | more
No Network Array enclosures found in /dev/es

Found Fibre Channel device(s):
  Node WWN:50060160b9a01d49  Device Type:Disk device
    Logical Path:/dev/rdsk/c2t5006016839A01D49d0s2
    Logical Path:/dev/rdsk/c2t5006016039A01D49d0s2
    Logical Path:/dev/rdsk/c3t5006016A39A01D49d0s2
    Logical Path:/dev/rdsk/c3t5006016239A01D49d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900A477E76B20CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900C041CD7320CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900C241CD7320CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900C441CD7320CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
...

# luxadm disp /dev/rdsk/c2t5006016839A01D49d0s2
DEVICE PROPERTIES for disk: /dev/rdsk/c2t5006016839A01D49d0s2
  Vendor:               DGC
  Product ID:           RAID 5
  Revision:             0326
  Serial Num:           CK200070200964
  Unformatted capacity: 34818.750 MBytes
  Read Cache:           Enabled
    Minimum prefetch:   0x0
    Maximum prefetch:   0x0
  Device Type:          Disk device
  Path(s):
  /dev/rdsk/c2t5006016839A01D49d0s2
  /devices/pci@1,700000/SUNW,emlxs@0/fp@0,0/ssd@w5006016839a01d49,0:c,raw
    LUN path port WWN:          5006016839a01d49
    Host controller port WWN:   10000000c9991aae
    Path status:                O.K.
  /dev/rdsk/c2t5006016039A01D49d0s2
  /devices/pci@1,700000/SUNW,emlxs@0/fp@0,0/ssd@w5006016039a01d49,0:c,raw
    LUN path port WWN:          5006016039a01d49
    Host controller port WWN:   10000000c9991aae
    Path status:                O.K.
  /dev/rdsk/c3t5006016A39A01D49d0s2
  /devices/pci@11,700000/SUNW,emlxs@0/fp@0,0/ssd@w5006016a39a01d49,0:c,raw
    LUN path port WWN:          5006016a39a01d49
    Host controller port WWN:   10000000c99920a4
    Path status:                O.K.
  /dev/rdsk/c3t5006016239A01D49d0s2
  /devices/pci@11,700000/SUNW,emlxs@0/fp@0,0/ssd@w5006016239a01d49,0:c,raw
    LUN path port WWN:          5006016239a01d49
    Host controller port WWN:   10000000c99920a4
    Path status:                O.K.

 

La LUNZ prenant la première position, on nomme fréquemment ce dysfonctionnement de problème entre LUNZ et LUN0. 

 

# fcinfo hba-port
HBA Port WWN: 10000000c99920a4
        OS Device Name: /dev/cfg/c3
        Manufacturer: Emulex
        Model: LPe12000-S
        Firmware Version: 1.11a5 (U3D1.11A5)
        FCode/BIOS Version: Boot:5.03a4 Fcode:3.10a3
        Serial Number: 0999BT0-10380003HU
        Driver Name: emlxs
        Driver Version: 2.50o (2010.01.08.09.45)
        Type: N-port
        State: online
        Supported Speeds: 2Gb 4Gb 8Gb
        Current Speed: 4Gb
        Node WWN: 20000000c99920a4
HBA Port WWN: 10000000c9991aae
        OS Device Name: /dev/cfg/c2
        Manufacturer: Emulex
        Model: LPe12000-S
        Firmware Version: 1.11a5 (U3D1.11A5)
        FCode/BIOS Version: Boot:5.03a4 Fcode:3.10a3
        Serial Number: 0999BT0-10380003EC
        Driver Name: emlxs
        Driver Version: 2.50o (2010.01.08.09.45)
        Type: N-port
        State: online
        Supported Speeds: 2Gb 4Gb 8Gb
        Current Speed: 4Gb
        Node WWN: 20000000c9991aae

# fcinfo remote-port -p 10000000c99920a4 -s
Remote Port WWN: 5006016a39a01d49
        Active FC4 Types: SCSI
        SCSI Target: yes
        Node WWN: 50060160b9a01d49
        LUN: 0
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c3t5006016A39A01D49d0s2
        LUN: 1
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00E0BF020FE0A5DF11d0s2
        LUN: 2
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00B827016B604BDE11d0s2
        LUN: 3
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00347A5E80604BDE11d0s2
... 

 

Il suffit simplement de déconfigurer tous les paths de cette Lun et de la redécouvrir. Attention tout de même qu'aucune ressource utilise l'in des paths de cette Lun, par exemple : des datas, dans la configuration d'un gestionnaire de volumes, un agent type Navisphere, etc.

 

# luxadm -e offline /dev/rdsk/c2t5006016839A01D49d0s2
devctl: I/O error

# vxdisk -e list | grep -i 5006016039A01D49d0
c2t5006016039A01D49d0s2 auto:sliced - - online c2t5006016039A01D49d0s2

# vxdisk rm c2t5006016039A01D49d0s2 

# luxadm -e offline /dev/rdsk/c2t5006016839A01D49d0s2
# luxadm -e offline /dev/rdsk/c2t5006016039A01D49d0s2
# luxadm -e offline /dev/rdsk/c3t5006016A39A01D49d0s2
# luxadm -e offline /dev/rdsk/c3t5006016239A01D49d0s2

# cfgadm -al
...
c2                             fc-fabric    connected    configured   unknown
c2::5006016039a01d49           disk         connected    configured   unusable
c2::500601603b205594           disk         connected    configured   unknown
c2::500601603b206f30           disk         connected    configured   unknown
c2::5006016230603a09           disk         connected    configured   unknown
c2::5006016839a01d49           disk         connected    configured   unusable
c2::500601683b205594           disk         connected    configured   unknown
c2::500601683b206f30           disk         connected    configured   unknown
c2::5006016a30603a09           disk         connected    configured   unknown
c3                             fc-fabric    connected    configured   unknown
c3::5006016130603a09           disk         connected    configured   unknown
c3::5006016239a01d49           disk         connected    configured   unusable
c3::500601623b205594           disk         connected    configured   unknown
c3::500601623b206f30           disk         connected    configured   unknown
c3::5006016930603a09           disk         connected    configured   unknown
c3::5006016a39a01d49           disk         connected    configured   unusable
c3::5006016a3b205594           disk         connected    configured   unknown
c3::5006016a3b206f30           disk         connected    configured   unknown
... 

# cfgadm -o unusable_FCP_dev -c unconfigure c2::5006016039a01d49
# cfgadm -o unusable_FCP_dev -c unconfigure c2::5006016839a01d49
# cfgadm -o unusable_FCP_dev -c unconfigure c3::5006016239a01d49
# cfgadm -o unusable_FCP_dev -c unconfigure c3::5006016a39a01d49

 

La déconfiguration de cette Lun par ces quatres paths est terminée. Il suffit donc de la réintégrer au serveur.

 

# cfgadm -c configure c2::5006016039a01d49
# cfgadm -c configure c2::5006016839a01d49
# cfgadm -c configure c3::5006016239a01d49
# cfgadm -c configure c3::5006016a39a01d49

 

# devfsadm -Cv
devfsadm[25244]: verbose: removing file: /dev/rdsk/c2t5006016839A01D49d0s3
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016239A01D49d0s6
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016A39A01D49d0s5
devfsadm[25244]: verbose: removing file: /dev/rdsk/c2t5006016039A01D49d0s2
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016A39A01D49d0s2
devfsadm[25244]: verbose: removing file: /dev/rdsk/c2t5006016039A01D49d0s5
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016239A01D49d0s1
... 

 

Une petite vérification simpose toujours.

 

# fcinfo remote-port -p 10000000c99920a4 -s
Remote Port WWN: 5006016a39a01d49
        Active FC4 Types: SCSI
        SCSI Target: yes
        Node WWN: 50060160b9a01d49
        LUN: 0
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
        LUN: 1
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00E0BF020FE0A5DF11d0s2
        LUN: 2
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00B827016B604BDE11d0s2
        LUN: 3
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00347A5E80604BDE11d0s2
...

# luxadm disp /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
DEVICE PROPERTIES for disk: /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
  Vendor:               DGC
  Product ID:           RAID 5
  Revision:             0326
  Serial Num:           CK200070200964
  Unformatted capacity: 34818.750 MBytes
  Read Cache:           Enabled
    Minimum prefetch:   0x0
    Maximum prefetch:   0x0
  Device Type:          Disk device
  Path(s):

  /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
  /devices/scsi_vhci/ssd@g600601600c421c00ca9ecd0544a5df11:c,raw
   Controller           /devices/pci@1,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016039a01d49,0
    Host controller port WWN    10000000c9991aae
    Class                       secondary
    State                       ONLINE
   Controller           /devices/pci@1,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016839a01d49,0
    Host controller port WWN    10000000c9991aae
    Class                       primary
    State                       ONLINE
   Controller           /devices/pci@11,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016239a01d49,0
    Host controller port WWN    10000000c99920a4
    Class                       secondary
    State                       ONLINE
   Controller           /devices/pci@11,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016a39a01d49,0
    Host controller port WWN    10000000c99920a4
    Class                       primary
    State                       ONLINE

 

Et voilà rien de plus facile. Quelques commandes dans un autre bien précis pour corriger un dysfonctionnement de MPxIO avec ce type de baie. Juste une dernière précision, si vous retirez cette Lun (en position 0), lors d'un prochain ajout il est possible que vous retombiez sur ce cas de figure. Mais bon vous avez l'astuce maintenant.

Published by gloumps - dans lvm
commenter cet article
21 novembre 2010 7 21 /11 /novembre /2010 11:40

 

Même si ZFS devient le système de fichiers par défaut pour toutes les nouvelles installations de Oracle Solaris il ne faut pas oublier de maintenir son parc existant. Hier lors d'une intervention sur un serveur Solaris 8, j'ai fait appel à mes souvenirs pour re-encapsuler un disque système sous contrôle VxVM. Ci-joint la méthode, expliquée pas à pas...

 

# Variables disques
DISKSYS=c0t0d0
DISKMIR=c1t0d0

 

# Recup de la taille de la private
PRVLEN=$(devinfo -p /dev/rdsk/${DISKSYS}s0 | awk '{print $4}')

 

# Recup offset private (slice 3)
PRVOFFSET=$(prtvtoc -h /dev/rdsk/${DISKSYS}s2 | grep " ${PRVLEN} " | awk '{print $4}')

 

# Recup offset publique (slice 4)
PUBOFFSET=$(prtvtoc -h /dev/rdsk/${DISKSYS}s2 | grep " ${PRVLEN} " | awk '{print $NF}')
PUBOFFSET=$((OFFSET+1))

 

# Initialisation du disque
vxdisksetup -i ${DISKMIR} prioffset=${PRVOFFSET} privlen=${PRVLEN} puboffset=${PUBOFFSET}

 

# Ajout du disque dans le dg
DGNAME=$(vxdisk -e list | grep ${DISKSYS} | awk '{print $4}')
vxdg -g ${DGNAME} adddisk rootmir=${DISKMIR}

 

#
#sd rootdisk-01  rootvol-01   rootdisk 0        12584484 0         c0t0d0   ENA
#sd rootdisk-02  swapvol-01   rootdisk 54344979 16776423 0         c0t0d0   ENA
#sd rootdisk-03  export-01    rootdisk 12584484 41760495 0         c0t0d0   ENA

 

# Mise en place de la vtoc (identique au disque système)
prtvtoc -h /dev/rdsk/${DISKSYS}s2 | while read VTOC
do
   SLICE=$(print $VTOC | awk '{ print $1 }')
   TAG=$(print $VTOC | awk '{ print $2 }')
   FLAGS=$(print $VTOC | awk '{ print $3 }')
   START=$(print $VTOC | awk '{ print $4 }')
   SIZE=$(print $VTOC | awk '{ print $5 }')

   if [ ${SLICE} != 3 -a ${SLICE} != 4 ]
   then
       vxpartadd /dev/rdsk/${DISKMIR}s2 ${SLICE} 0x${TAG} 0x2${FLAGS} ${START} ${SIZE}
   fi
done

 

# Création des subdisques, plex et synchro
vxprint -g ${DGNAME} -qst | grep ${DISKSYS} | while read CONF
do
    NUM1=$(print ${CONF} | awk '{print $2}' | cut -f2 -d"-")
    NUM2=$(print ${CONF} | awk '{print $3}' | cut -f2 -d"-")
    NUM2=$((NUM2+1))
    VOLUME=$(print ${CONF} | awk '{print $3}' | cut -f1 -d"-")
    OFFSET=$(print ${CONF} | awk '{print $5}')
    SIZE=$(print ${CONF} | awk '{print $6}')

    vxmake -g ${DGNAME} sd rootmir-${NUM1} rootmir,${OFFSET},${SIZE}
    vxmake -g ${DGNAME} plex ${VOLUME}-${NUM2} sd=rootmir-${NUM1}
    vxplex -g ${DGNAME} att ${VOLUME} ${VOLUME}-${NUM2} &
done

 

# Ne pas oublier par la suite le bootblock et de renseigner correctement l'eeprom.

 

Avec quelques petites variantes, on peut faire pas mal de choses intéressantes : génération d'un disque alterné, génération d'un disque système avec des tailles de disques différentes (recopie par ufsdump)... Attention à une chose, le dg de boot doit contenir un et un seul volume avec le tag root. Seul ce volume est bootable (si le fichier system est correctement mis à jour ainsi que la vfstab).

Published by gloumps - dans lvm
commenter cet article
13 octobre 2010 3 13 /10 /octobre /2010 22:54

 

Return to a problem with VxVM after adding san disks. By analyzing the core and the logs of daemon, I found (and understood) the origin of the problem.

 

It's a classical error but the root cause a little less traditional. The vxconfigd daemon not running just after adding disks. Why ? 

 

# vxdisk list
VxVM vxdisk ERROR V-5-1-684 IPC failure: Configuration daemon is not accessible

 

Nothing serious Doctor ? I decide to restart the daemon 

 

# vxconfigd -k
VxVM vxconfigd ERROR V-5-1-0 Segmentation violation - core dumped

 

It's bad start, hummm look at this core

 

# ls -l /core
-rw------- 1 root root 13221414 Sep 20 18:50 /core

# file /core
/core: ELF 32-bit MSB core file SPARC Version 1, from 'vxconfigd'

# mdb /core
Loading modules: [ libc.so.1 libnvpair.so.1 libavl.so.1 libuutil.so.1 ld.so.1 ]
> $C
ffbfea58 ddl_migration_devlist_removed+0x198(4820c0, 131b8, 2cf928, 2bc770, 50000, 482dd8)
ffbfeab8 ddl_check_migration_of_devices+0x9c(4b7598, 4ccdf8, ffbfeb7c, 4820c0, 5c00,0)
ffbfeb18 ddl_reconfigure_all+0x26c(2c254c, 4820c0, 2bc770, 50000, 3400, 2cf8dc)
ffbfeb80 ddl_find_devices_in_system+0x3f0(11400, 0, 5de8, 2bc770, 0, 2c0ad0)
ffbff110 find_devices_in_system+0x28(2, 0, 276664, 2cb214, 11, 276800)
ffbff170 mode_set+0x184(2, ffbff954, 2cb214, 2cb250, 0,2c0000)
ffbff8f0 setup_mode+0x24(2, 274400, 0, 2c0800, a39, 274400)
ffbff958 startup+0x284(8fa656a0, 2dcc00, 2c0800, 2c0800, 274400, 657a)
ffbff9c8 main+0xcac(2, ffbffb1c, ffffffff, 0, ffbffbf0, 0)
ffbffab8_start+0x108(0, 0, 0, 0, 0, 0)

> ddl_migration_devlist_removed+0x198::dis
ddl_migration_devlist_removed+0x170: ld [%l1], %o4
ddl_migration_devlist_removed+0x174: ba+0xb8 <ddl_migration_devlist_removed+0x22c>
ddl_migration_devlist_removed+0x178: ld [%l1 + 0xc], %l1
ddl_migration_devlist_removed+0x17c: ld [%l1 + 0x4], %o5
ddl_migration_devlist_removed+0x180: ld [%l1 + 0x8], %l2
ddl_migration_devlist_removed+0x184: btst 0x2, %o5
ddl_migration_devlist_removed+0x188: bne,pn %icc, +0x48 <ddl_migration_devlist_removed+0x1d0>
ddl_migration_devlist_removed+0x18c: btst 0x8,%o5
ddl_migration_devlist_removed+0x190: bne,pn %icc, +0x40 <ddl_migration_devlist_removed+0x1d0>
ddl_migration_devlist_removed+0x194: add %i4, 0x9, %o0
ddl_migration_devlist_removed+0x198: ld [%l2 + 0x8], %g5
ddl_migration_devlist_removed+0x19c: sethi %hi(0x2d400), %g1
ddl_migration_devlist_removed+0x1a0: sethi %hi(0x5400), %o1
ddl_migration_devlist_removed+0x1a4: ld [%l2 + 0xc], %g3
ddl_migration_devlist_removed+0x1a8: xor %g1, -0x2e4, %o7
ddl_migration_devlist_removed+0x1ac: add %o1, 0x148, %o1
ddl_migration_devlist_removed+0x1b0: add %i3, %o7, %o2
ddl_migration_devlist_removed+0x1b4: sub %g5, 0x1, %g4
ddl_migration_devlist_removed+0x1b8: mov %i2, %o3
ddl_migration_devlist_removed+0x1bc: st %g4, [%l2 + 0x8]
ddl_migration_devlist_removed+0x1c0: add %g3, 0x1, %g2

> ::regs
%g0 = 0x00000000 %l0 = 0xfffffffe
%g1 = 0x0015e160 ddl_check_if_exists_in_prop_list+0x58 %l1 = 0x00485340
%g2 = 0x00000000 %l2 = 0x00000000
%g3 = 0x002dcc00 vxconfigd`progname %l3 = 0x00000000
%g4 = 0x002c0800 vxconfigd`ioctls+0x318 %l4 = 0x00000001
%g5 = 0x00000088 %l5 = 0x004820e8
%g6 = 0x00000000 %l6 = 0x00482112
%g7 = 0xff0d2a00 %l7 = 0x004b7598
%o0 = 0x00050009 vold_change_common+0x1751 %i0 = 0x004820c0
%o1 = 0x40000025 %i1 = 0x000131b8
%o2 = 0x002bc770 %i2 = 0x002cf928
%o3 = 0x00000000 %i3 = 0x002bc770
%o4 = 0x00485340 %i4 = 0x00050000 vold_change_common+0x1748
%o5 = 0x40000025 %i5 = 0x00482dd8
%o6 = 0xffbfea58 %i6 = 0xffbfeab8
%o7 = 0x00157c7c ddl_migration_devlist_removed+0x11c %i7 = 0x00157a7c ddl_check_migration_of_devices+0x9c

%psr = 0xfe401002 impl=0xf ver=0xe icc=nZvc
                  ec=0 ef=4096 pil=0 s=0 ps=0 et=0 cwp=0x2

%y   = 0x00000000
%pc  = 0x00157cf8 ddl_migration_devlist_removed+0x198
%npc = 0x00157cfc ddl_migration_devlist_removed+0x19c
%sp  = 0xffbfea58
%fp  = 0xffbfeab8

%wim = 0x00000000
%tbr = 0x00000000

 

It's in a function 'ddl_migration_devlist_removed' that the problem is... Without a source code, it's more difficult to understand. So I change the method...

 

# vxconfigd -x 9 -k -x log -x logfile=/tmp/vxconfigd.out
...
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
...

 

Strange, no ? The same function as in the core. But what is DDL ? DDL (Device Discovery Layer) is the process of locating and identifying disks attached to a host. What are the disks connected to my server

 

# egrep Enclosure /tmp/vxconfigd.out
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:CLR-A/PF:EMC_CLARiiON:832
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:A/A:EMC_CLARiiON:832
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300471:0:EMC:A/A:EMC:834
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300446:0:EMC:A/A:EMC:834
.. vxconfigd DEBUG V-5-1-14475 Enclosure is DISKS:0:SEAGATE:Disk:Disk:514
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300446:50:EMC:A/A:PP_EMC:194
.. vxconfigd DEBUG V-5-1-14475 Enclosure is DISKS:5:SEAGATE:Disk:Disk:2
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:52:DGC:A/A:PP_EMC_CLARiiON:194
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300471:50:EMC:A/A:PP_EMC:194

 

Looking at the vxconfigd.log, we noticed the following

 

.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:CLR A/PF:EMC_CLARIION:832
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:A/A:EMC_CLARIION:832

 

The same enclosure is being seen as both ALUA and AP/F. Google is my friend, after a little research on the web I found the following bug by Symantec: TECH76277. This root is simple: this can occur if the array had existing LUNS configured as AP/F. Subsequently, some ALUA LUNS were added. This mixed configuration can cause problems with DMP. An the solution is: after changing all LUNS to either AP/F or ALUA, the problem is resolved.

 

Published by gloumps - dans lvm
commenter cet article
24 octobre 2008 5 24 /10 /octobre /2008 16:52
Cela restera à jamais gravé dans ma mémoire. Suite à un ajout de volumétrie dans un diskgroup, la ressource HAS du cluster n'a pas pu s'activer correctement sur aucune des nodes. Le message à la console était clair "diskgroup : no valid configuration copies". Je suis passé des cris aux larmes : il s'agissait d'un cluster de prod (instance SAP de 3 To avec 120 sapdatas). J'ai retroussé mes manches, et j'ai appliqué la procédure. C'est simple dans la théorie mais très stressant dans la pratique.... en tout cas c'est expliqué en dessous...

Pour qu'un diskgroup VxVM soit importé sur un serveur, il est nécessaire que son nombre de copie soit valide. Dans le cas contraire le diskgroup ne peut importé. Cela ne veut pas dire que les données soient perdues mais que la structure VxVM est invalide. La méthode suivante permet de reconstruire un diskgroup VxVM (sans perte des données physiques... enfin normalement).

Avant de commencer, il est nécessaire de posséder une sauvegarde de la structure. Pour la récupérer il faut l'enregistrer dans un fichier (le mieux est de la sauvegarder régulièrement via un script exécuté par la cron).

Sauvegarde de la structure VxVM


# vxdisk list
DEVICE       TYPE            DISK       GROUP       STATUS
c0t0d0s2     auto:sliced     disk1      zonesdg     online
c0t1d0s2     auto:sliced     disk2      zonesdg     online
c0t2d0s2     auto:sliced     disk3      zonesdg     online
c0t3d0s2     auto:sliced     disk4      zonesdg     online
c0t4d0s2     auto:sliced     disk5      zonesdg     online
c0t5d0s2     auto:sliced     rootdisk   rootdg      online
c1t0d0s2     auto:sliced     mir1       zonesdg     online
c1t1d0s2     auto:sliced     mir2       zonesdg     online
c1t2d0s2     auto:sliced     mir3       zonesdg     online
c1t3d0s2     auto:sliced     mir4       zonesdg     online
c1t4d0s2     auto:sliced     mir5       zonesdg     online
c1t5d0s2     auto:sliced     rootmir    rootdg      online
c3t0d0s2     auto:sliced     rootalt    rootdg      online

# vxdisk list c0t0d0
...
config   priv 000017-000247[000231]: copy=01 offset=000000 enabled
config   priv 000249-007310[007062]: copy=01 offset=000231 enabled
log      priv 007311-008415[001105]: copy=01 offset=000000 enabled
 
...

# /etc/vx/diag.d/vxprivutil list /dev/rdsk/c0t0d0s3
config   priv 000017-000247[000231]: copy=01 offset=000000 enabled
config   priv 000249-007310[007062]: copy=01 offset=000231 enabled
log      priv 007311-008415[001105]: copy=01 offset=000000 enabled


La structure VxVM est bien présente sur ce disque (config enabled). La sauvegarde est alors possible.

 

# /etc/vx/diag.d/vxprivutil dumpconfig /dev/rdsk/c0t0d0s3 > /tmp/zonesdg

 

Si vous prévérerz sauvegarder la config régulièrement ci-joint un petit script à faire exécuter par la cron.

 

Réinitialisation des disques


On recherche l'ensemble des disques appartenants au diskgroup (attention au éventuelle duplication dans le fichier /tmp/zonesdg pour les volumes et les plexes : si nécessaire les supprimer ou rejouer la sauvegarde de la structure).

 

# cat /tmp/zonesdg | vxprint -D - -md | /usr/xpg4/bin/grep -e "^dm" -e "last_da_name" > /tmp/disklist

 

La liste des disques générées correspond dans notre cas à :


dm disk1
last_da_name=c0t0d0s2
dm disk2
last_da_name=c0t1d0s2
dm disk3
last_da_name=c0t2d0s2
dm disk4
last_da_name=c0t3d0s2
dm disk5
last_da_name=c0t4d0s2
dm mir1
last_da_name=c1t0d0s2
dm mir2
last_da_name=c1t1d0s2
dm mir3
last_da_name=c1t2d0s2
dm mir4
last_da_name=c1t3d0s2
dm mir5
last_da_name=c1t4d0s2

 

Une fois la liste obtenu il faut réinitialiser les disques (attention à la taille de la private). Il est impératif que les disques que l'on initialise soit les mêmes disques physiques (attention au changement de contrôlleurs si reboot).

 

# ksh 
# for disk in $(cat /var/tmp/disks) 
do 
/etc/vx/bin/vxdisksetup -i $disk 
done

 

Création du diskgroup et ajout des disques au diskgroup


Une fois les disques initialisés il faut recréer le diskgroup et y inclure les disques. Il est impératif que les noms dm correspondent bien au disques physiques.

 

# vxdg init zonesdg disk1=c0t0d0s2
# vxdg -g zonesdg adddisk disk2=c0t1d0s2
# vxdg -g zonesdg adddisk disk3=c0t2d0s2
...
# vxdg -g zonesdg adddisk mir5=c1t4d0s2

 

Recopie de la structure VxVM

Si les disques phydiques intégrés au diskgroup sont bon et que les noms dm correspondent bien au bon disque physiques alors la configuration VxVM peut être reclaquée.

 

# cat /tmp/zonesdg | vxprint -D - -hmvps > /tmp/vxmakefile
# vxmake -g zonesdg -d /tmp/vxmakefile

 

Activation des volumes

 

# vxrecover -g zonesdg -s -b
# ksh
# for vol in $(vxprint -q -g zonesdg -v | awk '{print $2}')
do
vxvol -g zonesdg -f start $vol
done

 

Normalement, il suffit de faire un check (fsck) sur les systèmes de fichiers (pour être sur) puis de les monter.

 

 

Published by gloumps - dans lvm
commenter cet article