La red de interconexión en RAC es un componente crítico para el funcionamiento de la base de datos, en donde es importante reducir las latencias, maximizar el ancho de banda disponible y evitar la pérdida de paquetes, punto de elevada penalización para una configuración RAC.

 

Algo más que un heartbeat

A la hora de trabajar con los administradores de redes o sistemas, es lógico encontrarse con equipos con un concepto de red de interconexión “clásica”, donde ésta es empleada para una mínima intercomunicación entre nodos para la coordinación y gestión del clúster. De hecho, una de las conversaciones habituales cuando se trata de diseñar o instalar un nuevo RAC, es la justificación de la configuración de las redes privadas. En ocasiones, hablar de uso de redes 10GbE, de minimizar las latencias, y de aislar el tráfico de la red pública, puede sorprender. El motivo, conocido de sobra por los DBAs, es que la red de interconexión debe ser vista como un sistema de I/O, ya que sobre ella se despliega la tecnología Cache Fusion que busca agilizar el envío de datos entre instancias evitando su paso por disco (escritura desde el nodo origen y lectura desde el nodo destino), y haciendo un envío directo a través de la red de interconexión. Esto significa que, además del tráfico de control, podemos tener un importante tráfico de datos a través de esta red, en bloques de 8KiBs si estamos empleando el tamaño de bloque por defecto. Por lo tanto, a nivel de sistemas debemos imaginar la red de interconexión como, por ejemplo, una red iSCSI.

 

Especificaciones de Oracle

Años atrás, Oracle indicaba que era requisito el empleo de una red física dedicada y diferenciada de la red pública para ser utilizada como interconexión. Este requisito no era cumplido en la mayor parte de casos al no contar con hardware dedicado y sí con configuración de VLANs específicas dentro de los fabrics de cada cliente. En el año 2012 Oracle publicó el WhitePaper de obligada lectura para los administradores de red, Oracle Real Application Clusters (RAC) and Oracle Clusterware Interconnect Virtual Local Area Networks (VLANs) Deployment Considerations. El documento comienza haciendo referencia a lo ambiguo de los conceptos privada y separada.

Como resumen, los puntos que debemos tener en cuenta son:

  • Podemos emplear VLANs para la red de interconexión, tanto tagged como untagged. Este documento se centra en las recomendaciones de configuración a tener en cuenta.
  • Los servidores RAC deben estar conectados en adyacencia OSI de nivel 2, mismo dominio broadcast y comunicación en un único salto.
  • Deshabilitación o restricción de la configuración STP (Spanning Tree Protocol) para evitar suspensiones de tráfico que provoquen un split brain.
  • Habilitación de prunning para las VLANs, de manera que el tráfico multicast y broadcast privado de las redes no sea propagado mas allá de la capa de acceso.

Adicionalmente, es importante tener en cuenta que a partir de la versión 11.2.0.2, es necesario que el tráfico multicast se encuentre habilitado para la red 230.0.0.1, o, desde 11.2.0.2.1, en la red 224.0.0.251. Podemos ver mas información sobre este requisito en la nota MOS . También podemos encontrar en esta misma nota una herramienta para verificar si este tráfico se encuentra habilitado.

 

Recomendaciones adicionales

Hay muchos puntos a tener en cuenta para la configuración de la red de interconexión, para lo cual es recomendable acudir a la nota MOS Entre las recomendaciones destaco las siguientes:

  • Jumbo Frames. Con una MTU de 1500 bytes, un bloque de 8KiBs precisa ser fragmentado en 6 paquetes, cada uno de ellos ser procesado con las correspondientes cabeceras, ser enviado, y en la recepción reprocesado de nuevo para volver a ser reensamblado para generar un único bloque de datos de 8KiBs. Esto supone una sobrecarga a nivel de procesamiento y a nivel de tráfico (mayor cantidad de datos de control) que podemos evitar modificando la MTU en la red a 9000 bytes, tamaño con el que un bloque de 8KiBs será enviado en un único paquete IP.
  • HAIP. Esta funcionalidad, disponible desde 11.2.0.2, es una alternativa al empleo de soluciones de bonding o alta disponibilidad a nivel de SO, y la opción recomendada por Oracle. Presentamos al clúster hasta 4 redes privadas, siempre con subredes diferentes todas ellas, y Clusterware gestionará de manera automática el balanceo del tráfico entre aquellas redes supervivientes en caso de fallos de conectividad. De este modo, en cierto modo desplazamos la responsabilidad de gestión HA en la red privada del administrador de sistemas al DBA o administrador de la GI. Es posible emplear HAIP sobre bonding de SO, pero aporta complejidad y no funcionalidad. Del mismo modo, en entornos virtualizados donde las interfaces de red virtuales están protegidas por bondings físicos, puede no tener sentido práctico configurar múltiples redes HAIP si no aporta tolerancia a errores sobre la ya aportada por la capa de virtualización. Sí tiene un uso práctico claro en entornos físicos donde HAIP nos permite tolerar el fallo de un switch o de una tarjeta de red de manera casi transparente (aunque las BDs no sufren cortes, el tráfico de interconexión sí se ve parado durante unos segundos en una reconfiguración HAIP, por lo que puede llegar a percibirse ralentización en la BD).
  • Velocidad. Aunque en muchos casos podemos emplear redes de interconexión a 1GbE, se recomienda el uso de tecnologías con un mayor ancho de banda, como 10GbE. Miremos de nuevo a la red de interconexión como un sistema de I/O y no será necesario explicar mucho mas.
  • En caso de emplear bonding en Linux para la red de interconexión, no debemos emplear el modo 3. Este modo es el broadcast que transmite los paquetes a través de todas las interfaces del bonding.
  • Evitar la interferencia de la funcionalidad kernel Reverse Path Filtering, estableciendo el parámetro kernel rp_filter al valor 0 (deshabilitado) o 2 (loose). Esta funcionalidad, al estar a nivel IP, en caso de empleo de bonding, es en el dispositivo de bonding donde la debemos aplicar, no en las interfaces físicas que lo componen. Esta configuración evita que, con kernels 2.6.31 y superiores, se pueda producir una situación de bloqueo o descarte de paquetes en estas redes que pueda afectar al comportamiento del clúster. Podemos encontrar más información en la nota MOS rp_filter for multiple private interconnects and Linux Kernel 2.6.32 (Doc ID 1286796.1).
  • Parametrización de buffers de lectura y escritura para los sockets de red. La recomendación inicial para versiones 11g y superiores, es la de emplear net.core.rmem_default=262144, net.core.rmem_max=4194304, net.core.wmem_default=262144 y net.core.wmem_max=1048576. Estos valores pueden ser cambiados, por ejemplo, en función de los resultados que obtengamos en las pruebas de red para corregir potenciales deficiencias que encontremos.
  • Pruebas. Es muy importante validar la red de interconexión. En mi experiencia es un frecuente punto de fallo que pasa desapercibido por no ser probado correctamente. El empleo de herramientas como netperf los permitirán encontrar problemas de configuración, que habitualmente pasan por tasas bajas de transferencia, y especialmente por una tasa de pérdida de paquetes UDP importante. La comunicación Cache Fusion está basada en UDP, protocolo no orientado a conexión. La pérdida de paquetes UDP en la red puede conlevar un problema grave de rendimiento, y la aparición en la BD de eventos global cache de pérdida de paquetes que deberán ser reenviados. Es necesario llevar a cabo pruebas de comunicación TCP y UDP, y revisar las estadísticas de red (netstat y ethtool resultan aquí de gran ayuda), para, en caso de existir problemas, identificar el punto en el que se producen (buffers en SO, ring buffers, switches, problema de envío o de recepción, etc.). Con esta información podremos trabajar con los administradores de redes y sistemas para aportar una solución, que puede llegar a pasar por restringir el ancho de banda mediante la manipulación de los buffers de envío en caso de existir algún problema limitante a nivel de capacidad de la infraestructura. Uno de los objetivos principales es siempre verificar que la red no produce errores relevantes en el envío en momentos de elevada carga. Por ejemplo, no debemos encontrar un 10% de errores de recepción de paquetes UDP. El documento de pruebas y rendimiento de red debería ser imprescindible en cualquier instalación RAC.

 

¿Qué verificar en las pruebas de red?

Vamos a ver en un ejemplo real de medición sobre un entorno RAC de 3 nodos con datos obtenidos empleando HAIP con 2 redes privadas, por lo que cada servidor tiene dos conexiones con el resto de miembros del clúster, una a través de la red priv1 y otra a través de la red priv2. En el Doc ID 810394.1 mencionado antes podemos encontrar más información sobre enlaces a documentos para pruebas RAC incluyendo el empleo de netperf.

En estas tablas, aparecen datos máximos y mínimos porque ejecutamos varios ciclos de pruebas para comprobar la estabilidad de los datos en diferentes momentos de estrés en la red.

Las pruebas están hechas con la herramienta netperf, y consisten en obtener datos de dos maneras diferentes, STREAM enviando bloques de 8KiBs para obtener el rendimiento en MiB/s, y RESPONSE, enviando paquetes de 1 único byte para analizar la latencia existente en la red, viendo en este caso no el rendimiento sino la máxima cantidad de paquetes de mínimo tamaño que podemos enviar. Los datos que debemos verificar son:

  • En el caso de una transmisión UDP, al no existir conexión, es importante comparar los datos de envío y recepción, ya que es habitual que un equipo pueda enviar datos a mucha velocidad, pero problemas de configuración o procesamiento en destino hace que éstos no sean recibidos. Si sólo revisamos los datos de envío podríamos concluír de manera errónea que la prueba fue correcta. En el ejemplo vemos que los valores de envío y de recepción son idénticos en este caso. En el caso de TCP, en caso de problemas de recepción lo que encontraremos es que las tasas de envío son inferiores a las que encontramos con UDP o a las teóricas del canal, ya que el control de conexión regula las transferencias y comunica la correcta recepción de paquetes, gestionando con ello la velocidad de transferencia.
  • Estabilidad en los resultados de las pruebas. Verificar si los resultados son constantes en los diversos ciclos de pruebas y, de no serlo, consultar con los administradores de red para contrastar los datos y justificar el comportamiento.
  • Alcance del máximo ancho de banda. Conociendo el ancho de banda teórico de nuestra red, verificar si es en realidad lo que estamos consiguiendo. En este caso, contamos con un bonding de 20Gpbs, que por su configuración nos permite para una única conexión un rendimiento máximo de 10Gbps, siendo 1180Mbps un resultado muy bueno.
  • Latencia de red. La prueba RESPONSE los darán como resultado el número de paquetes recibidos, por lo que a partir de este dato podemos calcular el tiempo de respuesta medio para el envío de un paquete de 1 byte por el canal, que en este caso es un valor estable en todas las pruebas de 0,03ms, también muy bueno en comparación con resultados de tests de otros contornos, sin entrar a profundizar en valores teóricos a nivel de administrador de redes.

Aunque en estas pruebas los datos son claros, es recomendable revisar los errores que se producen en las estadísticas de sistema operativo, empleando herramientas como netstat y ethtool, especialmente cuando hacemos las pruebas de UDP, con el objetivo de identificar los potenciales puntos de fallo si encontramos diferencias entre el envío y la recepción. En este caso, los resultados para lo par de nodos rac1 – rac2, son los siguientes:

Comparamos las tasas de envío con las de recepción. Sin entrar en detalle, por cómo están recogidas las métricas en el script empleado para eslabón, es normal que las tasas de recepción sean aproximadamente la mitad que las de envío, debido a la existencia de dos redes de interconexión. Vemos en las estadísticas que de se recibieron mas de 227 millones de paquetes de los que sólo 254 paquetes generaron un error y fueron por lo tanto descartados, siendo el porcentaje de errores descartable. Vemos también el efecto de los jumbo frames, ya que ni en el envío se crean paquetes IP, ni en la recepción se tienen que reensamblar. Los errores de envío también son insignificantes, contabilizando 22 paquetes IP para un total de cerca de 590 millones. Con ethtool vemos que no se producen a nivel físico (tarjeta de red) errores, siendo un resultado óptimo lo que mostramos en estas capturas.

 

Validación HAIP

Una vez validada la capacidad y configuración de las redes, algo que hacemos antes de la instalación de software, tras haber desplegado la Grid Infrastructure y las bases de datos, debemos incluir en las pruebas de clúster la validación de la alta disponibilidad con HAIP. Para ello, nuestro inventario de pruebas incluirá la pérdida individual de cada red privada. En estas pruebas verificaremos:

  • Estado inicial antes de lanzar las pruebas.
  • Failover de la IP HAIP a una red superviviente tras desconexión de cableado en una de las redes privadas.
  • Correcta actualización de la tabla de rutas en el sistema operativo del nodo en la que ejecutamos la prueba.
  • Recuperación de IP y rutas una vez recuperada la conexión.

Como ejemplo, hacemos una prueba en un nodo con dos redes privadas. La situación inicial es la siguiente:

[oracle@rac1 ]$ oifcfg iflist
eno53  10.181.18.240
eno53  169.254.0.0
eno54  10.181.18.248
eno54  169.254.128.0
bond0  10.181.18.160

[oracle@rac1 ]$ oifcfg getif
bond0  10.181.18.160  global  public
eno53  10.181.18.240  global  cluster_interconnect
eno54  10.181.18.248  global  cluster_interconnect

[oracle@rac1 ]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 bond0
10.181.18.160   0.0.0.0         255.255.255.224 U     0      0        0 bond0
10.181.18.240   0.0.0.0         255.255.255.248 U     0      0        0 eno53
10.181.18.248   0.0.0.0         255.255.255.248 U     0      0        0 eno54
link-local      0.0.0.0         255.255.128.0   U     0      0        0 eno53
169.254.128.0   0.0.0.0         255.255.128.0   U     0      0        0 eno54

Tenemos dos redes privadas, cada una de ellas asignadas a las interfaces físicas eno53 y eno54. Sobre estas redes, Oracle tiene arrancadas las IPs 169.254.0.0 (inicialmente en eno53), y 169.254.128.0 (eno54). Desconectamos el cable de la tarjeta eno53. Tras hacerlo, el resultado es:

[oracle@rac1 ]$ oifcfg iflist
eno53  10.181.18.240
eno54  10.181.18.248
eno54  169.254.128.0
eno54  169.254.0.0
bond0  10.181.18.160

[oracle@rac1 ]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 bond0
10.181.18.160   0.0.0.0         255.255.255.224 U     0      0        0 bond0
10.181.18.240   0.0.0.0         255.255.255.248 U     0      0        0 eno53
10.181.18.248   0.0.0.0         255.255.255.248 U     0      0        0 eno54
link-local      0.0.0.0         255.255.128.0   U     0      0        0 eno54
169.254.128.0   0.0.0.0         255.255.128.0   U     0      0        0 eno54

La IP 169.254.0.0 sigue arrancada y dispuesta para la comunicación con el resto de miembros del clúster, con la diferencia de que ahora está en la interfaz física eno54 tras la pérdida de eno53. Adicionalmente comprobamos que la tábos de enrutamento del SO fue modificado para reflejar este cambio. Al reconectar el cable, tras un segundos, la situación vuelve a ser la inicial:

[oracle@rac1 ]$ oifcfg iflist
eno53  10.181.18.240
eno53  169.254.0.0
eno54  10.181.18.248
eno54  169.254.128.0
bond0  10.181.18.160

[oracle@rac1 ]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 bond0
10.181.18.160   0.0.0.0         255.255.255.224 U     0      0        0 bond0
10.181.18.240   0.0.0.0         255.255.255.248 U     0      0        0 eno53
10.181.18.248   0.0.0.0         255.255.255.248 U     0      0        0 eno54
link-local      0.0.0.0         255.255.128.0   U     0      0        0 eno53
169.254.128.0   0.0.0.0         255.255.128.0   U     0      0        0 eno54

En el fondo es algo muy simple, pero es muy importante ejecutar esta prueba para estar seguros de que ninguna configuración a nivel de SO o red está interfiriendo en la correcta relocalización de la IP.

 

Conclusiones

En general, la calidad y rendimiento de nuestra infraestructura no debe ser algo improvisado, y debe responder a las expectativas y especificaciones de nuestro hardware y configuración. Podemos desplegar un RAC de manera rápida sin asegurarnos de si hay problemas, o podemos forzar el hardware y software para someterlo la estrés y pruebas de HA para intentar buscar potenciales puntos de fallo, solucionarlos y finalmente convalidar el producto instalado. Es demasiado frecuente encontrar problemas en la red de interconexión como para obviar este punto, que debe ser un requisito imprescindible en cualquiera despliegue RAC, eleborando el correspondiente documento de resultados de las pruebas que poder contrastar con los administradores de sistemas y red.

 

Créditos

Imagen del post obra de Vera Pereiro. La Suricata de Arumel.

Revisión: Alicia Constela.