Últimamente me he encontrado con una serie de preguntas sobre las direcciones IP virtuales (VIP) para Oracle RAC. Espero que esta publicación de blog pueda arrojar algo de luz sobre qué es un VIP, cómo funciona y por qué Oracle RAC los aprovecha. Antes de continuar, debo explicar que no soy un especialista en redes. De hecho, las redes informáticas son probablemente mi punto más débil de todo lo que sucede en las tiendas de TI. Así que no me insulten si no entiendo las cosas de la red por completo, 100% precisas. Explicaré esto en términos que me han servido bien en mi carrera de DBA, especialmente trabajando con Oracle RAC.
La mayoría de las personas están familiarizadas con la conexión de cualquier aplicación, SQL*Plus u otras, a un servidor de base de datos de instancia única. Al final, su solicitud de conexión se envía a una dirección IP específica. En nuestro diagrama a continuación, el usuario final desea conectarse a 192.168.1.1 para acceder a la base de datos. La solicitud de red se enruta al conmutador de red al que está conectado ese servidor de base de datos. Este conmutador pasa la solicitud al servidor que tiene la dirección IP solicitada.
La mayoría de los DBA de Oracle no tienen problemas para comprender este concepto. La vida se vuelve un poco más complicada cuando se implementa RAC, ya que hay varias máquinas (nodos) en el clúster. En el siguiente diagrama, tenemos un clúster RAC de dos nodos, cada uno de los cuales tiene una dirección IP diferente.
Al usuario final no le importa a qué nodo está conectada su sesión. El usuario final solo quiere acceder al clúster. Cualquier nodo será suficiente. La configuración de TNSNAMES.ORA del usuario final puede indicar que primero pruebe con 192.168.1.1 y, si eso no funciona, pruebe con 192.168.1.2. De esta forma, Oracle RAC proporciona una solución de alta disponibilidad.
Ahora llegamos a la razón completa por la que se deben usar las direcciones IP virtuales. ¿Qué pasa si el usuario final intenta acceder al primer nodo (192.168.1.1) pero no está disponible? El nodo está inactivo por algún motivo. El usuario final podría conectarse fácilmente al nodo 192.168.1.2. Sin embargo, debido a la forma en que funcionan las redes TCP/IP, la conexión de red a 192.168.1.1 puede demorar hasta diez minutos antes de que se acceda a 192.168.1.2. La larga espera de tiempo de espera de TCP/IP es la única razón por la que Oracle RAC aprovecha los VIP. Simplemente queremos reducir el tiempo para acceder a otro nodo en el clúster en caso de que nuestro nodo solicitado no esté disponible.
Una IP tradicional generalmente está vinculada a la tarjeta de red en el servidor. El administrador de TI configurará el servidor para usar siempre esa dirección IP específica y ningún otro dispositivo en la red usará la misma IP. Nota:Estoy tratando de simplificar esto aquí y evitar DHCP y el registro de arrendamiento para aquellos que están familiarizados con los temas.
Una dirección IP virtual no está vinculada a la tarjeta de red. Ni siquiera está definido en el sistema operativo. El VIP no es una dirección IP real similar a la forma en que una máquina virtual no es un sistema real. Simplemente parece ser real para quienes lo usan. Así que echemos un vistazo a nuestro clúster de dos nodos, pero esta vez con VIP definidos para ellos.
Nuestros servidores aún tienen sus direcciones IP regulares, 192.168.1.1 y 192.168.1.2 para NODE1 y NODE2 respectivamente. Estos dos nodos también tienen VIP asociados con ellos. NODE1-VIP y NODE2-VIP se indican como direcciones IP 192.168.1.11 y 192.168.1.12 respectivamente. Cada nodo del clúster RAC tiene su dirección IP normal y una VIP. También puede ser beneficioso saber que el nombre de host y los nombres VIP a menudo se definen en DNS para que no tengamos que recordar las direcciones IP específicamente.
Observe que el usuario final ahora solicita acceder a uno de los VIP. Las únicas personas que deberían usar estas direcciones IP tradicionales son los administradores de TI que necesitan trabajar en el servidor. Los usuarios finales y todas y cada una de las aplicaciones deben conectarse con el VIP.
¿Recuerdas que dije antes que el VIP ni siquiera está definido en el sistema operativo? Bueno, si ese es el caso, ¿cómo sabe todo que el VIP está asignado a ese nodo? Todo esto es manejado por Grid Infrastructure (GI). Cuando se instala GI, una de las pantallas de Oracle Universal Installer (OUI) solicitará los nombres de los nodos en el clúster (los nombres de host) junto con el nombre de host virtual. La siguiente captura de pantalla muestra el aspecto de la instalación de 11g GI cuando se solicitó esa información (captura de pantalla de la documentación de Oracle).
El administrador configura el nombre de host público en el sistema operativo. La IP virtual no está configurada en el sistema operativo, pero Grid Infrastructure lo sabe. Para comprender cómo funciona esto, debemos desviarnos un poco y comprender el Protocolo de resolución de direcciones (ARP).
Cuando se inicia un servidor y se inician sus componentes de red, el Protocolo de resolución de direcciones es el mecanismo que le dice al conmutador frente al servidor que enrute todo el tráfico de su dirección IP a la dirección MAC de su tarjeta de red. El sistema operativo, a través de ARP, le dice al conmutador que vaya a NODE1 para las solicitudes 192.168.1.1.
Cuando se inicia Grid Infrastructure, una de sus tareas de inicio es hacer algo similar. GI, a través de ARP, le dice al conmutador que vaya a NODE1 para todas las solicitudes de NODE1-VIP (192.168.1.11). Hasta que GI inicie el VIP, esa dirección VIP no se puede enrutar.
Ahora, aquí está la parte mágica... cuando NODE1 se cae, GI en otro nodo en el clúster detectará la interrupción. Luego, GI realizará una nueva operación ARP que informa al conmutador para enrutar el VIP a otro nodo en el clúster. Debido a que el VIP es virtual, se puede redirigir sobre la marcha. En el siguiente diagrama, NODE1 ha fallado. Su IP tradicional ya no está disponible también. GI ha vuelto a enviar el VIP al nodo restante del clúster.
El re-ARPing del VIP se puede lograr en segundos. El usuario final puede experimentar una breve pausa en su comunicación de red entre la aplicación y la instancia de la base de datos, pero esto es mucho, mucho menor que si esperáramos los tiempos de espera de TCP/IP.
Oracle 11gR2 presentó SCAN Listeners. Un clúster de Oracle RAC puede tener como máximo tres SCAN Listeners. El nombre de SCAN todavía está en el DNS, pero el DNS rotará la resolución del nombre de SCAN a una de hasta tres direcciones IP diferentes.
En el siguiente diagrama, nuestro clúster de dos nodos ahora tiene dos agentes de escucha SCAN. El usuario final realiza una solicitud de conexión a my-scan.acme.com y el DNS resuelve el nombre en 192.168.1.21 o 192.168.1.22.
Como se muestra arriba, esos dos SCAN VIP se asignan a diferentes nodos en el clúster. Si NODE1 deja de funcionar, Grid Infrastructure reubicará NODE1-VIP y MY-SCAN (192.168.1.21) en un nodo sobreviviente en el clúster, a través de la misma operación de ARP de la que hablamos anteriormente. Los oyentes de SCAN más nuevos y sus VIP se manejan de la misma manera que los VIP de estilo antiguo.
En resumen, las direcciones IP virtuales se utilizan para proporcionar una conmutación por error más rápida de las comunicaciones de red entre la aplicación y los nodos del clúster. El sistema operativo utiliza el Protocolo de resolución de direcciones para que el conmutador de red sepa enrutar las conexiones al host. Grid Infrastructure utiliza las mismas operaciones ARP para que el conmutador de red sepa dónde enrutar el tráfico para VIP y SCAN VIP. Si un nodo deja de funcionar, GI volverá a ARP el VIP y SCAN VIP a otro nodo en el clúster.
