Cuando creamos un volumen mapeado bajo el grupo de cluster, automáticamente es visible por las másquinas node1 y node2. Podemos montar dicho volumen directamente con el path /dev/dsk/* que se le ha sido asignado, pero si queremos que cluster vea dicho recurso debemos realizar una serie de pasos para que éste lo reconozca.

Sun Cluster monta los discos por encima del path ‘directo’, usando un árbol tipo /dev/did/dsk y /dev/did/rdsk, creando un mismo identificador para un mismo volumen en todos los miembros del cluster. Podemos ver la configuración actual tal que:

root@node1:/-> scdidadm -L
(…)
6 node1:/dev/rdsk/c4t600A0B800011BB8A00001802483A7407d0 /dev/did/rdsk/d6
6 node2:/dev/rdsk/c4t600A0B800011BB8A00001802483A7407d0 /dev/did/rdsk/d6
7 node1:/dev/rdsk/c4t600A0B800011BB6400001D4348562452d0 /dev/did/rdsk/d7
7 node2:/dev/rdsk/c4t600A0B800011BB6400001D4348562452d0 /dev/did/rdsk/d7
8 node1:/dev/rdsk/c4t600A0B800011BB8A0000180F485680B5d0 /dev/did/rdsk/d8
8 node2:/dev/rdsk/c4t600A0B800011BB8A0000180F485680B5d0 /dev/did/rdsk/d8
(…)

Vemos que cada volumen está asignado en las dos máquinas del cluster bajo un mismo identificador (el 6, 7, 8…) y que ha configurado las correspondientes entradas globales con la misma correspondencia en cada miembro… /dev/did/dsk/d6, /dev/did/dsk/d7…

Al añadir un nuevo volumen desde el Array 6140 este aún no será visible, así que tendremos que ejecutar una reconfiguración en todos los nodos:

root@node2:/-> scdidadm -r
did subpath /dev/rdsk/c4t600A0B800011BB6400001FE44ACC1313d0s2 created for instance 32.

root@node1:/-> scdidadm -r
did subpath /dev/rdsk/c4t600A0B800011BB6400001FE44ACC1313d0s2 created for instance 32.

Puede pasar que hace tiempo que estemos creando y borrando entrando, el comando scdidadm -r solo añade entradas nuevas pero no hace limpieza de aquello que ya hayamos borrado. Pero antes tendremos que borrar las entradas ‘físicas’ que ve el propio sistema operativo, por lo que ejecutaremos los dos comandos siguientes por el siguiente orden en cada uno de los nodos:

root@node1:/-> devfsadm -Cv
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s0
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s1
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s2
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s3
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s4
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s5
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s6
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB6400001D4348562452d0s7
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s0
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s1
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s2
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s3
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s4
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s5
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s6
devfsadm[6501]: verbose: removing file: /dev/dsk/c4t600A0B800011BB8A0000180F485680B5d0s7
root@node1:/-> scdidadm -C

Luego de hacer esto ya tenemos garantizado que el cluster puede ver los dispositivos bien, pero aún no los habrá registrado en la configuración global. Eso podemos verlo con el comando scdpm, si hay entradas en Fail ejecutaremos el script scgdevs. Este script trabaja en background, una vez ejecutado manda tareas a todos los elementos del cluster, y eso puede tardar un rato (incluso media hora). No nos debemos poner nerviosos y volveremos a mirar en un rato que ya estén bien:

root@node2:/-> scdpm -p node1:all
node1/dev/did/rdsk/d7 Ok
node1/dev/did/rdsk/d8 Ok
node1/dev/did/rdsk/d12 Ok
node1/dev/did/rdsk/d13 Fail
node1/dev/did/rdsk/d14 Fail
node1/dev/did/rdsk/d15 Fail
node1/dev/did/rdsk/d27 Fail
node1/dev/did/rdsk/d28 Fail
node1/dev/did/rdsk/d29 Fail
node1/dev/did/rdsk/d30 Fail
node1/dev/did/rdsk/d31 Fail
node1/dev/did/rdsk/d32 Fail

root@node1:/-> scgdevs
Configuring DID devices
Configuring the /dev/global directory (global devices)
obtaining access to all attached disks
(media hora más tarde)

root@node2:/-> scdpm -p node1:all
node1:/dev/did/rdsk/d7 Ok
node1:/dev/did/rdsk/d8 Ok
node1:/dev/did/rdsk/d12 Ok
node1:/dev/did/rdsk/d13 Ok
node1:/dev/did/rdsk/d14 Ok
node1:/dev/did/rdsk/d15 Ok
node1:/dev/did/rdsk/d27 Ok
node1:/dev/did/rdsk/d28 Ok
node1:/dev/did/rdsk/d29 Ok
node1:/dev/did/rdsk/d30 Ok
node1:/dev/did/rdsk/d31 Ok
node1:/dev/did/rdsk/d32 Ok

Una vez los dispositivos ya están visibles ya podemos configurarlos en los metasets de DiskSuite y en los recursos del cluster.

Como último comentario, en el paso de scgdevs puede que nos encontremos con un error:

root@node1:/-> scgdevs
Configuring DID devices
ioctl(IOCDID_INIT) failed for path node1:/dev/rdsk/c4t600A0B800011BB6400001FEE4AEF9D57d0
Invalid argument
ioctl(IOCDID_INIT) failed for path node1:/dev/rdsk/c4t600A0B800011BB8A00001AE14AEFFDDEd0
Invalid argument
ioctl(IOCDID_INIT) failed for path node1:/dev/rdsk/c4t600A0B800011BB8A00001ADF4AEFFD40d0
Invalid argument
Configuring the /dev/global directory (global devices)
obtaining access to all attached disks
root@node1:/->

Esto se suele producir cuando ya ha existido anteriormente un DID con ese mismo número. Para ‘reparar’ la base de datos de DID adecuadamente, basta con ejecutar scdidadm con la opción R para cada uno de los discos que fallan (para todas las máquinas que comparten esos discos) y volver a lanzar el comando scgdevs:

root@node1:/-> scdidadm -R /dev/rdsk/c4t600A0B800011BB6400001FEE4AEF9D57d0
device id for the device matches the data base
root@node1:/-> scdidadm -R /dev/rdsk/c4t600A0B800011BB8A00001AE14AEFFDDEd0
device id for the device matches the data base
root@node1:/-> scdidadm -R /dev/rdsk/c4t600A0B800011BB8A00001ADF4AEFFD40d0
device id for the device matches the data base
root@node1:/-> ssh node2
Last login: Tue Nov 3 10:49:11 2009 from node1
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
You have new mail.
root@node2:/-> scgdevs
Configuring DID devices
ioctl(IOCDID_INIT) failed for path node2:/dev/rdsk/c4t600A0B800011BB6400001FEE4AEF9D57d0
Invalid argument
ioctl(IOCDID_INIT) failed for path node2:/dev/rdsk/c4t600A0B800011BB8A00001AE14AEFFDDEd0
Invalid argument
ioctl(IOCDID_INIT) failed for path node2:/dev/rdsk/c4t600A0B800011BB8A00001ADF4AEFFD40d0
Invalid argument
Configuring the /dev/global directory (global devices)
obtaining access to all attached disks
root@node2:/-> scdidadm -R /dev/rdsk/c4t600A0B800011BB6400001FEE4AEF9D57d0
device id for the device matches the data base
root@node2:/-> scdidadm -R /dev/rdsk/c4t600A0B800011BB8A00001AE14AEFFDDEd0
device id for the device matches the data base
root@node2:/-> scdidadm -R /dev/rdsk/c4t600A0B800011BB8A00001ADF4AEFFD40d0
device id for the device matches the data base
root@node2:/-> scgdevs
Configuring DID devices
Configuring the /dev/global directory (global devices)
obtaining access to all attached disks
root@node2:/->