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.

Se ha presentado un nuevo LUN de 500GB:

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

Popular posts from this blog

Cómo extraer Archive Logs desde un Backup Piece

RMAN no es de mis herramientas favoritas en Oracle, quizás porque cada vez que nos vemos las caras es porque ha ocurrido algún desastre. En esta ocasión necesitaba extraer Archive Logs para aplicarlos a una operación de RECOVER pero resulta que los archives estaban catalogados en una ubicación externa y fuera de mi alcance. Cuando al fin logre catalogar los archivos de backup que contenían los Archive Logs era necesario colocarlos en una ubicación local para poder aplicarlos. Así que veamos como extraer los archivos necesarios. Una vez catalogados los archivos de backup en nuestro repositorio de RMAN, podemos visualizar los Archives contenidos con el comando LIST BACKUP OF ARCHIVELOG ALL. RMAN> list backup of archivelog all; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key  Size       Device Type Elapsed Time Completion Time ------- ---------- ...
Read more

Ejemplo práctico con SQL Tuning Advisor y SQL Access Advisor

Parte del perfil de un administrador de base de datos es el afinamiento de sentencias SQL, el afinamiento (o tuning) nos ayuda a mejorar el rendimiento de sentencias SQL dentro de nuestras bases de datos, mejorando: tiempos de respuesta de aplicaciones, tiempo de respuesta de procesos batch, consumo de recursos del sistema, escalabilidad de las aplicaciones. En Oracle, la ejecución de una sentencia SQL requiere tres fases: parseo, enlace y ejecución ( parse, bind and execute ). La parte de parseo es la que nos interesa para fines de este artículo. En esta, nuestro servidor interpreta lo que la sentencia significa y cuál es la mejor manera de ejecutarla. El parseo involucra interacción con el segmento de memoria SHARED POOL dentro de la instancia de la base de datos. Las estructuras del SHARED POOL convierten el SQL en algo ejecutable mediante un plan de ejecución. Plan de ejecución: es el resultado de la fase de parseo, indica la forma en cómo se va a acceder a los datos solici...
Read more

Tips para administración de memoria en una base de datos Oracle 11GR2

Image
Gestión de memoria en Oracle 11gR2 Constantemente recibo peticiones para establecer el tamaño ideal de memoria para una instancia de base de datos. Aunque el mejor consejo es manejar un estándar para toda las bases de datos, a veces el valor estándar no es suficiente o es demasiado, todo depende de los recursos con los que contemos y la funcionalidad que tendrá la base de datos. Aunque Oracle recomienda utilizar servidores dedicados para base de datos, en las organizaciones no siempre siguen ese consejo, esto sucede mucho en servidores de desarrollo, pruebas o QA, donde el servidor soporta: aplicación, base de datos, es repositorio de fuentes y hasta servidor ftp (he visto casos). La memoria es uno de los recursos mas valiosos de un servidor, pero, ¿por que rompernos la cabeza buscando un valor ideal para nuestros segmentos de memoria si Oracle puede hacerlo automáticamente y de forma eficiente? A continuación veremos algunos tips para administración eficiente de memoria...
Read more