MERCADOS FINANCIEROS

viernes, 13 de noviembre de 2015

Procedimiento para cambiar IPs de servidores en RAC11gR2

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.
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 ellas.
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)
NombreIPs OriginalesNuevas IPs
MyServer1.lab.com169.254.234.10169.254.234.70
MyServer2.lab.com169.254.234.20169.254.234.80
MyServer3.lab.com169.254.234.30169.254.234.90

NombreIPs OriginalesNuevas IPs
MyServer1-vIP.lab.com169.254.234.11169.254.234.71
MyServer2-vIP.lab.com169.254.234.12169.254.234.81
MyServer3-vIP.lab.com169.254.234.13169.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.
  1. Detener la base de datos y deshabilitar el inicio automático de los servicios de RAC.
  2. 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>
    • Detener las instancias ASM
    • Detener nodeapps

  3. Detener la instancia ASM y deshabilitar el inicio automático.
  4. 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 
    [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.
  5. Detener el servicio de cluster del nodo donde se va a cambiar la IP
  6. 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

  7. Desmontar los filesystems NFS
  8. 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.
  9. Actualizar el archivo /etc/hosts en todos los nodos de base de datos.
  10. 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 


  11. Actualizar el archivo ifcfg-eth0 con la nueva IP.
  12. 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 


  13. Reiniciar el servicio de red.
  14. [root@MyServer1 ~]# service network stop
    [root@MyServer1 ~]# service network  start 


  15. Realizar una prueba con el comando ping
  16. [root@MyServer1 ~]# ping 169.254.234.70
    [root@MyServer1 ~]# ping 169.254.234.80
    [root@MyServer1 ~]# ping 169.254.234.90 


  17. Modificar el archivo listener.ora
  18. 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.
  19. Iniciar el servicio de cluster
  20. 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 


  21. Volver a detener el servicio de nodeapps en todos los nodos.
  22. [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 
     
  23. Cambiar las direcciones IPs públicas en el OCR
  24. 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 


  25. Revisar nuevamente el archivo /etc/hosts. 
  26. 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.
  27. Cambiar las direcciones IPs Virtuales
  28. 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 


  29. Reiniciar el nodeapps en cada nodo.
  30. [root@MyServer3 ~]# $ORA_CRS_HOME/bin/srvctl start nodeapps -n  $HOSTNAME 


  31. Volver a montar los filesystems NFS listados en el archivo /etc/fstab. 
  32. 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.
  33. Verificar e iniciar las instancias de base de datos.
  34. 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.

No hay comentarios: