lvm - Solaris mon amour

17 décembre 2011 6 17 /12 /décembre /2011 19:05

Problématique de la LUNZ avec MPxIO

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.

Partager cet article

Published by gloumps - dans lvm
commenter cet article …

21 novembre 2010 7 21 /11 /novembre /2010 11:40

Création d'un disque miroir pas à pas sous VxVM

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).

Partager cet article

Published by gloumps - dans lvm
commenter cet article …

13 octobre 2010 3 13 /10 /octobre /2010 22:54

Analyse vxconfigd: core dump

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.

Partager cet article

Published by gloumps - dans lvm
commenter cet article …

24 octobre 2008 5 24 /10 /octobre /2008 16:52

diskgroup : no valid configuration copies

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.

Partager cet article