Hace tiempo ya hablé de la configuración de las reglas udev para presentar discos que serán utilizados en bases de datos Oracle RAC pero, ¿cuál es el procedimiento a seguir si queremos dejar de utilizar esos discos?
El siguiente procedimiento lo he utilizado para migrar los datos de una base de datos de Oracle RAC de la cabina de discos actual a una nueva y todo eso sin parar el servicio en ningún momento.
En este caso, solamente vamos a ver la parte de despresentación de los discos de Linux (RedHat 7), partiendo de la base que los datos ya están en la nueva cabina.
Desconfiguración del multipath
Cada uno de los discos antiguos que ya no se utilizan, los deberemos eliminar del fichero de configuración de multipath, que se encuentra en /etc/multipath.conf.
Una vez eliminadas las líneas correspondientes, recargaremos la configuración con el siguiente comando:
systemctl reload multipathdAlternativamente, también podemos utilizar el comando:
multipath -rLo que sucederá es que seguiremos viendo el disco en el sistema pero sin ningún alias.
Esto lo hacemos porque todos los discos que son utilizados en Oracle tienen un alias configurado, por lo que evitaremos posibles errores a la hora de asignar discos a la base de datos.
Eliminación de las reglas udev
En el fichero /etc/udev/rules.d/99-oracle-asmdevices.rules tenemos configurado el alias de cada disco y su WWID (Word Wide ID). Lo que conseguimos con esta configuración es que se cree el dispositivo (disco) que utilizará Oracle RAC bajo la estructura /dev/oracleasm/disks/Alias_del_disco, pero lo que queremos hacer en este caso, es eliminar este dispositivo para que Oracle no lo utilice.
Modificación de permisos del dispositivo
Lo primero de todo es asegurarse de que la base de datos no lo está utilizando realmente, así que antes de despresentarlo definitivamente, es una buena práctica cambiar los permisos o el propietario del dispositivo y revisar el log de la base de datos (alert.log), por si apareciera algún error.
Eliminación del dispositivo
Si no ha aparecido ningún error en la base de datos, pasaremos despresentarlo. Lo que haremos será eliminar el dispositivo del fichero de reglas de udev (/etc/udev/rules.d/99-oracle-asmdevices.rules), recargar las reglas de nuevo y eliminar el dispositivo. El procedimiento completo sería:
chown root:root /dev/oracleasm/disks/Alias_del_disco
udevadm control --reload-rules
udevadm trigger /dev/oracleasm/disks/Alias_del_disco
rm /dev/oracleasm/disks/Alias_del_disco
IMPORTANTE: Si al comando udevadm trigger NO le pasamos el alias del disco, realizará una desconexión en frío de todos los discos y tiraremos todo el cluster de Oracle RAC. Por lo tanto, SIEMPRE hay que indicarle el disco concreto que queremos desconectar. Aún así, hará un reset de las tarjetas de red que puede provocar la caída del listener.
Aug 2 12:59:33 server1 multipathd: uevent trigger error
Aug 2 12:59:33 server1 udevd-work[41531]: error changing netif name 'eth3' to 'eth1': Device or resource busy
Aug 2 12:59:33 server1 udevd-work[41513]: error changing netif name 'eth2' to 'eth0': Device or resource busy
Aug 2 12:59:34 server1 ntpd[6041]: Deleting interface #11 bond1:2, 10.49.25.23#123, interface stats: received=10, sent=7, dropped=0, active_time=15
51321 secs
Aug 2 12:59:34 server1 ntpd[6041]: Deleting interface #10 bond1:1, 10.49.25.40#123, interface stats: received=10, sent=7, dropped=0, active_time=15
51325 secs
Aug 2 12:59:34 server1 ntpd[6041]: Deleting interface #9 bond0:2, 30.34.25.29#123, interface stats: received=0, sent=0, dropped=0, active_time=1551
325 secs
Aug 2 12:59:34 server1 ntpd[6041]: Deleting interface #8 bond0:1, 169.254.11.3#123, interface stats: received=0, sent=0, dropped=0, active_time=155
1375 secs
Aug 2 12:59:37 server1 ntpd[6041]: Listen normally on 12 bond0:1 169.254.11.3 UDP 123IMPORTANTE: El reload de las reglas de udev reiniciará las tarejtas de red, por lo que puede tirar el cluster de Oracle RAC o algún componente, como los listeners, ya que en el directorio /etc/udev/rules.d también tenemos reglas para las tarjetas.
El siguiente paso sería que el equipo de Storage despresente la LUN de todos los servidores del cluster. Cuando eso ocurra, tendremos que volver a recargar la configuración de multipath para que dejemos de recibir errores del estilo «path failed».
Mi pasión por la tecnología me lleva constantemente a explorar las últimas tendencias y aplicaciones, buscando siempre formas de implementar soluciones innovadoras que mejoren la eficiencia. En puerto53.com comparto contenido valioso para ayudar a otros profesionales y entusiastas de la informática a navegar y dominar el complejo mundo de la tecnología. Mi especialidad en Linux RedHat.
Más sobre mí en el este enlace,
