País Llamar

Menú
Oracle Technology Network / Artículos / Rendimiento y Disponibilidad de Base de datos

Framework para el Desarrollo Procedimiento para cambiar IPs de servidores en RAC11gR2

de Aplicaciones
Por Joel Pérez , Ajith Narayanan y Jorge Zorrilla (OCP)
Application Express Publicado en Abril 2015

Business Intelligence 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 ).
Cloud Computing

Communications Ahora, ¿en qué escenario es necesario cambiar la(s) IP(s) de los servidores de base de datos?

Rendimiento y Disponibilidad Existen muchos escenarios que pueden conllevar un cambio de este tIPo. Ilustremos uno:
de Base de datos
A nivel empresarial normalmente los requerimientos de auditoría indican que las bases de datos que manejen información crítica en general deben
Data Warehousing 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
.NET 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.
Lenguajes de Programación
Dinámicos En este artículo deseamos explicar paso a paso el procedimiento para cambiar las IPs de una configuración en RAC.
Embedded
En una configuración RAC cada servidor tiene 3 direcciones IPs asignadas.
Arquitectura Enterprise
IP Publica: resuelve al nombre <servidor>. Ejm MyServer1. Se define en el DNS y en el archivo /etc/hosts.
Enterprise Management IP Virtual(VIP): resuelve al nombre <servidor>-vIP. Ejm MyServer1-vIP. Se define en el DNS y en el archivo /etc/hosts.
IP Privada(Interconnect): resuelve al nombre <servidor>-priv. Ejm MyServer1-priv.
Grid Computing
Solo las IPs públicas y Virtuales serán modificas ya que las IPs Privadas no se encentran en la red LAN y ningún otro sistema o servidor acceden a
Identidad y Seguridad ellas.
Java La siguiente tabla muestra las direcciones IPs originales y las nuevas direcciones IPs que se desean definir:
Linux (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)
Service-Oriented Architecture
Nombre IPs Originales Nuevas IPs
SQL & PL/SQL

Virtualización MyServer1.lab.com 169.254.234.10 169.254.234.70

MyServer2.lab.com 169.254.234.20 169.254.234.80

Chat
MyServer3.lab.com 169.254.234.30 169.254.234.90
Chat

Chat
Nombre IPs Originales Nuevas IPs
Chat
MyServer1-vIP.lab.com 169.254.234.11 169.254.234.71
Chat
MyServer2-vIP.lab.com 169.254.234.12 169.254.234.81 Chat
Chat
MyServer3-vIP.lab.com 169.254.234.13 169.254.234.91
Chat
Chat
Chat
Guardar la configuración Actual Chat
Chat
Guardar el detalle de la configuración actual puede ser muy útil al momento de resolver problemas que puedan presentarse. Chat
Para obtener la configuración actual debemos de ejecutar la siguiente secuencia de comandos Chat
Chat
Configuración de nodeapps Chat
Chat
[oracle@MyServer1 ~]# srvctl config nodeapps -n $HOSTNAME -a Chat
Chat
Interfaces de red almacenadas en el OCR Chat
Chat
[root@MyServer1 ~]# $ORA_CRS_HOME/bin/oifcfg getif Chat

Configuración de red a nivel del Sistema Operativo. Chat

Chat
[root@MyServer1 ~]# /sbin/ifconfig Chat

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. Chat
Utilizar el procedimiento estándar para bajar las instancias de base de datos. Bajar todas las instancias de base de datos.
Luego de bajar las instancias de base de datos es necesario> Chat
Detener las instancias ASM Chat
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.
Los comandos que utilizamos son los siguientes:

[oracle@MyServer1 ~]#srvctl stop database –d <db name>

[oracle@MyServer1 ~]#srvctl disable instance -d <db name> -i <instance name>
[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.

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.
El comando para detener el servicio de cluster es:

[root@MyServer1 ~]#/etc/init.d/init.crs stop

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.

​[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

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.

[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

Reiniciar el servicio de red.

[root@MyServer1 ~]# service network stop
[root@MyServer1 ~]# service network start

Realizar una prueba con el comando ping

[root@MyServer1 ~]# ping 169.254.234.70
[root@MyServer1 ~]# ping 169.254.234.80
[root@MyServer1 ~]# ping 169.254.234.90

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.

[root@MyServer1 ~]#/etc/init.d/init.crs start

[root@MyServer2 ~]#/etc/init.d/init.crs start
[root@MyServer3 ~]#/etc/init.d/init.crs start

Volver a detener el servicio de nodeapps en todos los nodos.

[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

Cambiar las direcciones IPs públicas en el OCR

Se realiza con el usuario root. La sub-red es 10.12.20.0
 [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

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)

[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

Reiniciar el nodeapps en cada nodo.

[root@MyServer3 ~]# $ORA_CRS_HOME/bin/srvctl start nodeapps -n $HOSTNAME

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.
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.

Esperando como siempre que el artículo haya sido de agrado y utilidad. Nos despedimos y nos vemos en la próxima entrega.

Joel Pérez es un experto DBA (Oracle ACE Director, OCM Cloud Admin. & OCM11g) con más de 14 años de experiencia real en el mundo de
tecnología Oracle, especializado en diseño e implementación de soluciones de: Alta disponibilidad, Recuperación contra desastres, Upgrades,
Replicación y toda área relacionada con bases de datos Oracle. Consultor Internacional con trabajos, conferencias y actividades relacionadas en
más de 50 países alrededor del mundo. Habitual Orador en eventos Oracle alrededor del mundo tales como: OTN LAD, OTN MENA, OTN APAC y
más. Joel se ha caracterizado siempre por ser un pionero en materia de tecnología Oracle desde los inicios de su carrera siendo el primer
latinoamericano publicado como experto en Oracle.com como "OTN Expert" en el año 2003, uno de los primeros Oracle ACE del respectivo
programa en el año 2004, unos de los primeros OCP Cloud en el mercado global en el año 2013 y como uno de los mayores logros de su carrera,
recientemente en el 2014 fue honorificado como uno de los primeros "OCM Database Cloud Administrator" del mundo. En la actualidad Joel Pérez
esta radicado en el continente de Asia con base en Beijing, China llevando a cabo operaciones profesionales en alianza con una de las mayores
compañías de consultoría Oracle en China "Enmotech".

Ajith Narayanan posee 9 años de experiencia en tecnología Oracle, principalmente en administración de Bases de Datos y Administración de
Oracle Apps. Habitual conferencista en eventos tales como: OTN APAC, UKOUG y otros.

Ing. Jorge Zorrilla. Es un IT especialista de tecnología Oracle e instructor de cursos oficiales de certificación Oracle. Amplia experiencia en Base de
Datos Oracle, soluciones de Alta Disponibilidad & Contingencia. Fue uno de los primeros especialistas en Latinoamérica con la certificación
OCPOracle12c. Cuenta con un blog sobre Oracle 12c y temas relacionados.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los
productos Oracle.

E-mail this page Printer View

Contáctenos Cloud Acciones principales Temas clave

Ventas en EE. UU.: Descripción general de Cloud Descargue Java ERP, EPM (Finanzas)
+1.800.633.0738 Solutions Descargue Java para HCM (RR. HH. y talento)
Reciba una llamada de Oracle Software (SaaS) desarrolladores Mercadeo
Contactos globales Plataforma (PaaS) Pruebe Oracle Cloud CX (Ventas, servicio, comercio)
Directorio de soporte Infraestructura (IaaS) Suscríbase a los correos Soluciones sectoriales
electrónicos
Datos (DaaS) Base de datos
Acerca de Oracle Prueba gratuita de la nube
Noticias MySQL
Información de la empresa
Middleware
Comunidades Eventos Sala de prensa
Java
Revistas
Carreras Oracle Code Historias de éxito de los clientes Sistemas de ingeniería
JavaOne Blogs
Todos los eventos de Oracle

© Oracle Mapa del sitio Términos de uso y privacidad Cookie Preferences Cookie Preferences Opciones de publicidad