Utilizando la herramienta UDEV en lugar de ASMLib para agregar discos a un ASM DiskGroup
El incremento de espacio en un DiskGrup de ASM
es una tarea rutinaria, o tal vez más de lo común en bases de datos altamente
transaccionales.
Cuando utilizamos sistemas operativos Linux,
Oracle provee una herramienta denominada Oracle ASMLib para la gestión de
discos y dispositivos que permite crear fácilmente ASMDisk para ser asignados
en un DiskGroup.
Sin embargo, existe una herramienta nativa en Linux
que puede proporcionarnos la misma facilidad que ASMLib, se trata de UDEV.
UDEV es un gestor de dispositivos que se
encarga de mantener actualizado el directorio /dev con los dispositivos
presentes en el sistema.
UDEV funciona a través de reglas escritas en
archivos de texto entendibles para el usuario, las reglas definen desde
directorios, permisos y dueños de objetos para los dispositivos reconocidos en
el sistema.
En el siguiente ejemplo vamos a descubrir un
nuevo disco agregado a nuestro servidor y los vamos a agregar a un ASM
DiskGroup.
Nombre: LUN_NLSAS_500G0060
SCSI ID: 6bc620e1003105e000cfc778000000ad
|
Para identificar que a que unidad en el
directorio /dev pertenece este nuevo LUN hacemos uso del comando /sbin/scsi_id
Normalmente, el último disco agregado por
default será la última literal que encontremos en /dev/sd[L] usando fdisk –l,
para asegurarnos que sea el nuevo dispositivo utilizamos:
[root@cenregspdb4 rules.d]# /sbin/scsi_id -g -u -d
/dev/sdat
36bc620e1003105e000cfc778000000ad
|
Una vez que hayamos identificado el nuevo
dispositivo vamos a hacer que sea visible para la instancia ASM, aquí es donde
entra la facilidad de UDEV.
Las reglas de UDEV están ubicadas en /etc/udev/rules.d
asi que vamos hacia allá:
[root@prdserver4
rules.d]# cd /etc/udev/rules.d
[root@prdserver4
rules.d]# ls -l
total
60
-rw-r--r-- 1 root root
190 Mar 19 04:34 55-usm.rules
-rw-------.
1 root root 114 Feb 25 06:26
56-nxup.rules
-rw-r--r--.
1 root root 1652 Aug 25 2010
60-fprint-autosuspend.rules
-rw-r--r--.
1 root root 1060 Jun 29 2010
60-pcmcia.rules
-rw-r--r--.
1 root root 316 Aug 6
2013 60-raw.rules
-rw-r--r--.
1 root root 432 Feb 6 03:33 70-persistent-cd.rules
-rw-r--r--.
1 root root 1239 Feb 6 03:09
70-persistent-net.rules
-rw-r--r--.
1 root root 320 Sep 12 2012 90-alsa.rules
-rw-r--r--.
1 root root 83 Apr 1
2011 90-hal.rules
-rw-r--r--.
1 root root 308 Oct 21 2013 98-kexec.rules
-rw-r--r--.
1 root root 54 Nov 3
2011 99-fuse.rules
-rw-r--r--. 1 root root 9854 Jun
26 12:13 99-oracle-asmdevices.rules
-rw-------.
1 root root 474 Feb 25 06:26
99-ultrapath.rules
|
Las reglas son ejecutadas todas a la vez en un
orden alfabético, por lo que para este ejemplo crearemos el archivo
99-oracle-asmdevices.rules para no afectar cualquier regla definida antes.
La regla que aplicaremos será la siguiente:
KERNEL=="sd*",
SUBSYSTEM=="block", PROGRAM=="/sbin/scsi_id --whitelisted
--replace-whitespace --device=/dev/$name", RESULT=="36bc620e1003105e000cfc778000000ad", NAME="ssd-disk01", OWNER="grid", GROUP="asmadmin",
MODE="0660"
|
Explicación: con esta regla crearemos nombres
persistentes para cada LUN a través de LINKS SIMBOLICOS de sistema operativo, también
se establecerán permisos y propietarios para las unidades a través de enlaces simbólicos. De modo que
para la instancia ASM puedan ser vistos en /dev.
Explicación de reglas línea por línea:
KERNEL=="sd*"
|
Identificar todos los discos en /dev/sd* donde
el * hara referencia a todas las literales encontradas en el directorio.
SUBSYSTEM=="block",
PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace
--device=/dev/$name", RESULT=="36bc620e1003105e000cfc778000000ad"
|
Las siguientes instrucciones hacen los mismo
que hicimos nosotros un paso atrás, ejecutan /sbin/scsi_id para encontrar el
identificador de cada unidad, si el resultado es el descrito en RESULT
ejecutara las instrucciones a seguir. En pocas palabras es un IF THEN.
NAME="data-disk41
", OWNER="grid", GROUP="asmadmin",
MODE="0660"
|
Finalmente, si se encontró una coincidencia en
las reglas anteriores, se van a ejecutar las siguientes acciones. Nombre de la
unidad: “data-disk41”, dueño de la unidad: Grid, grupo principal: asmadmin
Como último paso volveremos a cargar las reglas
definidas para UDEV:
[root@prdserver4
rules.d]# /sbin/udevadm control --reload-rules
[root@prdserver4
rules.d]# /sbin/udevadm trigger
|
Si verificamos el directorio /dev podremos ver
ahora la nueva unidad:
[root@prdserver4
rules.d]# ls -l /dev/data*
brw-rw----
1 grid asmadmin 8, 80 Jun 21 16:40 /dev/data-disk01
….
brw-rw----
1 grid asmadmin 66, 192 Jun 21 16:41 /dev/data-disk40
brw-rw---- 1 grid asmadmin 66,
208 Jun 21 16:40 /dev/data-disk41
|
No queda más que agregar nuestro nuevo ASM Disk
a un DiskGroup.
[root@prdserver4 rules.d]# su - grid
[oracle@prdserver4 ~]$ sqlplus / as sysasm
SQL> col PATH format a45
SQL> set lines 999
SQL> select path,header_status from v$asm_disk;
PATH
HEADER_STATU
---------------------------------------------
------------
/dev/data-disk41 CANDIDATE
/dev/data-disk39 MEMBER
/dev/data-disk03 MEMBER
/dev/data-disk38 MEMBER
/dev/data-disk35 MEMBER
/dev/data-disk40 MEMBER
…
SQL> alter diskgroup DATA_DG add disk
'/dev/data-disk41' name ERP_DG_0036 rebalance power 4;
SQL>
|
UDEV facilita mucho la aplicación de permisos y
pertenencia de unidades, a través de reglas podemos definir una cantidad
infinita de unidades y discos a la vez.
Ojo, para este caso en particular, la base de
datos pertenece a un ambiente RAC. En casos como este, como con cualquier otra
herramienta, hay que definir reglas y aplicarlas para cada nodo del cluster que
utilice la base de datos.
Punto aparte recomiendo leer otras entradas:
Para una
referencia del uso de Oraclel ASMLib pueden leer la entrada alterna: guía rápidade Oracle ASMLib.
Para
agregar discos a un DiskGroup en Solaris pueden consultar siguiente entrada:
ASMDisk en Solaris.
Comments
Post a Comment