Procedimiento para cambiar IPs de servidores en RAC11gR2
Por Joel Pérez , Ajith Narayanan y Jorge Zorrilla (OCP)Publicado en Abril 2015
Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo tendremos la oportunidad de visualizar y adentrarnos un poco en algunas de las tantas tareas posibles de realizar entorno a la administración de la solución Oracle denominada RAC ( Real Application Cluster ).
Ahora, ¿en qué escenario es necesario cambiar la(s) IP(s) de los servidores de base de datos?
Existen muchos escenarios que pueden conllevar un cambio de este tIPo. Ilustremos uno:
A nivel empresarial normalmente los requerimientos de auditoría indican que las bases de datos que manejen información crítica en general deben de estar en una red aislada, separada a través de un Firewall especial o varios de ellos. Para el caso de cuando ya se tiene instalada toda la infraestructura ( Servidores, software, etc.. ), y se deseen aplicar las mejores practicas mencionadas, es cuando nos encontramos con la necesidad de cambiar direcciones IP no solo para los servidores sino para la configuración del software que se encuentra trabajando internamente en este.
En este artículo deseamos explicar paso a paso el procedimiento para cambiar las IPs de una configuración en RAC.
En una configuración RAC cada servidor tiene 3 direcciones IPs asignadas.
- IP Publica: resuelve al nombre
. Ejm MyServer1. Se define en el DNS y en el archivo /etc/hosts. - IP Virtual(VIP): resuelve al nombre
-vIP. Ejm MyServer1-vIP. Se define en el DNS y en el archivo /etc/hosts. - IP Privada(Interconnect): resuelve al nombre
-priv. Ejm MyServer1-priv.
La siguiente tabla muestra las direcciones IPs originales y las nuevas direcciones IPs que se desean definir:
(NOTA: Para el ejemplo utilizamos direcciones IPs dentro de una red doméstica, sin embargo, el procedimiento es el mismo para IPs en diferentes tipos de redes)
Nombre | IPs Originales | Nuevas IPs |
MyServer1.lab.com | 169.254.234.10 | 169.254.234.70 |
MyServer2.lab.com | 169.254.234.20 | 169.254.234.80 |
MyServer3.lab.com | 169.254.234.30 | 169.254.234.90 |
Nombre | IPs Originales | Nuevas IPs |
MyServer1-vIP.lab.com | 169.254.234.11 | 169.254.234.71 |
MyServer2-vIP.lab.com | 169.254.234.12 | 169.254.234.81 |
MyServer3-vIP.lab.com | 169.254.234.13 | 169.254.234.91 |
Guardar la configuración Actual
Guardar el detalle de la configuración actual puede ser muy útil al momento de resolver problemas que puedan presentarse.
Para obtener la configuración actual debemos de ejecutar la siguiente secuencia de comandos
Configuración de nodeapps
[oracle@MyServer1 ~]# srvctl config nodeapps -n $HOSTNAME -a
Interfaces de red almacenadas en el OCR
[root@MyServer1 ~]# $ORA_CRS_HOME/bin/oifcfg getif
Configuración de red a nivel del Sistema Operativo.
[root@MyServer1 ~]# /sbin/ifconfig
Los siguientes pasos son requeridos para poder hacer el cambio de direcciones IPs en una arquitectura de base de datos RAC.
- Detener la base de datos y deshabilitar el inicio automático de los servicios de RAC. Utilizar el procedimiento estándar para bajar las instancias de base de datos. Bajar todas las instancias de base de datos.
- Detener las instancias ASM
- Detener nodeapps
- Detener la instancia ASM y deshabilitar el inicio automático. Es recomendable también deshabilitar la instancia ASM ya que en una situación de problema, es más sencillo poder hacer revisiones.
- Detener el servicio de cluster del nodo donde se va a cambiar la IP. Detenemos el servicio de cluster CRS con el usuario root. Si no se detiene el CRS, el servicio puede entrar en un estado inestable y provocar reinicios inesperados de los servidores.
- Desmontar los filesystems NFS Consultar el archivo /etc/fstab y desmontar todos los filesystems NFS que comparten información. Es necesario desmontar dichos filesystem antes de hacer el cambio de IP pública debido a que puede causar inestabilidad en los filesystems locales. Esto puede provocar que el acceso del usuario oracle, mediante ssh, no funcione correctamente.
- Actualizar el archivo /etc/hosts en todos los nodos de base de datos. Conectarse con el usuario root a todos los nodos de la arquitectura RAC y actualizar el archivo /etc/hosts. Los valores a cambiar serán las IPs públicas y virtuales.
- Actualizar el archivo ifcfg-eth0 con la nueva IP. Actualizar el archivo ifcfg-eth0 en la ruta /etc/sysconfig/network-scrIPts/ con la nueva IP. También se puede realizar mediante la interfaz gráfica del sistema operativo.
- Reiniciar el servicio de red.
- Realizar una prueba con el comando ping
- Modificar el archivo listener.ora Si los listener están definidos con IPs y no con nombre del servidor, es necesario modificar la dirección IP en el listener.ora.
- Iniciar el servicio de cluster Con el usuario root, iniciar el servicio de cluster en todos los nodos.
- Volver a detener el servicio de nodeapps en todos los nodos.
- Cambiar las direcciones IPs públicas en el OCR Se realiza con el usuario root. La sub-red es 10.12.20.0
- Revisar nuevamente el archivo /etc/hosts. El comando setif puede haber agregado registros en el archivo /etc/hosts, apuntando a las IP privadas. Si se ha agregado algún registro, es necesario removerlo. Además es necesario revisar que el registro de las IPs públicas de cada servidor se definan con el nombre del servidor y dominio (FDQN), así como también, con solo el nombre del servidor.
- Cambiar las direcciones IPs Virtuales Con el usuario root modificar las IPs virtuales con el comando srvctl (corregir el nombre del servidor, la dirección IP y la máscara de red si fuera necesario)
- Reiniciar el nodeapps en cada nodo.
- Volver a montar los filesystems NFS listados en el archivo /etc/fstab. Si existe algún problema de permisos, trabajar con el equipo de Storage para limpiar la cache del DNS en el servidor NAS. También es importante revisar que no haya direcciones IPs fijas definidas en el archivo /etc/hosts del servidor NAS.
- Verificar e iniciar las instancias de base de datos. De manera opcional se puede correr el utilitario runcluvfy.sh para verificar la configuración de red.
Luego de bajar las instancias de base de datos es necesario>
Los comandos que utilizamos son los siguientes:
[oracle@MyServer1 ~]#srvctl stop database –d[oracle@MyServer1 ~]#srvctl disable instance -d -i [oracle@MyServer1 ~]#srvctl disable asm -n $HOSTNAME
El siguiente paso es detener el nodeapps y verificar que las IPs Virtuales ya no se encuentran activas. Para eso ejecutamos el comando 'ifconfig -a'
[oracle@MyServer1 ~]#ifconfig -a
SI las interfaces aún se encuentran activas, puede que existan recursos dependiente de las IPs Virtuales, aun activos. El comando crs_stat nos puede ayudar a revisar cuales son los recursos activos.
El comando para detener el servicio de cluster es:
[root@MyServer1 ~]#/etc/init.d/init.crs stop
[root@MyServer1 ~]# vi /etc/hosts 169.254.234.70 MyServer1 MyServer1.lab.com 169.254.234.71 MyServer1-vIP MyServer1-vIP.lab.com 172.16.100.51 MyServer1-priv MyServer1-priv.lab.com 169.254.234.80 MyServer2 MyServer2.lab.com 169.254.234.81 MyServer2-vIP MyServer2-vIP.lab.com 172.16.100.52 MyServer2-priv MyServer2-priv.lab.com 169.254.234.90 MyServer2 MyServer2.lab.com 169.254.234.91 MyServer2-vIP MyServer2-vIP.lab.com 172.16.100.53 MyServer2-priv MyServer2-priv.lab.com 169.254.234.250 MyServer-scan MyServer-scan.lab.com 169.254.234.251 MyServer-gns MyServer-gns.lab.com ::1 localhost6.localdomain6 localhost6 127.0.0.1 localhost.localdomain localhost
[root@MyServer1 ~]# ls -l /etc/sysconfig/network-scrIPts/ total 392 -rw-r--r-- 3 root root 116 Oct 10 12:40 ifcfg-eth0 -rw-r--r-- 3 root root 187 Oct 10 12:40 ifcfg-eth1 -rw-r--r-- 3 root root 127 Oct 21 16:46 ifcfg-eth2 -rw-r--r-- 1 root root 254 Mar 3 2008 ifcfg-lo [...]
[root@MyServer1 ~]# cat /etc/sysconfig/network-scrIPts/ifcfg-eth0 # DEVICE=eth0 BOOTPROTO=static HWADDR=00:14:4F:29:00:1D IPADDR=169.254.234.70 NETMASK=255.255.255.0 ONBOOT=no
[root@MyServer1 ~]# service network stop [root@MyServer1 ~]# service network start
[root@MyServer1 ~]# ping 169.254.234.70 [root@MyServer1 ~]# ping 169.254.234.80 [root@MyServer1 ~]# ping 169.254.234.90
[root@MyServer1 ~]#/etc/init.d/init.crs start [root@MyServer2 ~]#/etc/init.d/init.crs start [root@MyServer3 ~]#/etc/init.d/init.crs start
[oracle@MyServer1 ~]# srvctl stop nodeapps -n $HOSTNAME [oracle@MyServer2 ~]# srvctl stop nodeapps -n $HOSTNAME [oracle@MyServer3 ~]# srvctl stop nodeapps -n $HOSTNAME
Revisar que el nodeapps se encuentre detenido en todos los nodos. Cuando se detuvo el servicio de cluster las IPs Virtuales se relocalizaron en otro nodo y se mantuvieron en dicho nodo incluso después de volver a iniciar el servicio de cluster.
[oracle@MyServer1 ~]# srvctl status nodeapps -n $HOSTNAME
[root@MyServer1 ~]# $ORA_CRS_HOME/bin/oifcfg delif -global eth0 [root@MyServer1 ~]# $ORA_CRS_HOME/bin/oifcfg setif -global eth0/169.254.234.70:public [root@MyServer2 ~]# $ORA_CRS_HOME/bin/oifcfg delif -global eth0 [root@MyServer2 ~]# $ORA_CRS_HOME/bin/oifcfg setif -global eth0/169.254.234.80:public [root@MyServer3 ~]# $ORA_CRS_HOME/bin/oifcfg delif -global eth0 [root@MyServer3 ~]# $ORA_CRS_HOME/bin/oifcfg setif -global eth0/169.254.234.90:public
[root@MyServer1 ~]# srvctl modify nodeapps -n MyServer1 -A 169.254.234.71/255.255.255.0/eth0
[root@MyServer2 ~]# srvctl modify nodeapps -n MyServer1 -A 169.254.234.81/255.255.255.0/eth0
[root@MyServer3 ~]# srvctl modify nodeapps -n MyServer1 -A 169.254.234.91/255.255.255.0/eth0
[root@MyServer3 ~]# $ORA_CRS_HOME/bin/srvctl start nodeapps -n $HOSTNAME
Validar que el nodeapps y el listener inicien de manera exitosa en todos los nodos.
Finalmente proceder a levantar las instancias de base de datos.
No hay comentarios:
Publicar un comentario