A rede de interconexión en RAC é un compoñente crítico para o funcionamento da base de datos, na que é importante reducir as latencias, maximizar o ancho de banda dispoñible e evitar a perda de paquetes, punto de elevada penalización para unha BD RAC.

Algo máis ca un heartbeat

Á hora de traballar cos administradores de redes ou sistemas, é lóxico atoparse con equipos cun concepto de rede de interconexión “clásica”, onde esta é empregada para unha mínima intercomunicación entre nodos imprescindible para a coordinación e xestión do clúster. De feito unha das conversas habituais cando se trata de deseñar ou instalar un novo RAC, é a da xustificación da configuración das redes privadas. En ocasións, falar de uso de redes 10GbE, de minimizar as latencias, e de illar o tráfico da rede pública, pode sorprender. O motivo, coñecido de sobra polos DBAs, é que a rede de interconexión debe ser vista como un sistema de I/O, xa que sobre ela se desprega a tecnoloxía Cache Fusion que busca axilizar o envío de datos entre instancias evitando o seu paso por disco (escritura en orixe e lectura en destino), e facendo un envío directamente a través da rede de interconexión. Isto significa que, ademais do tráfico de control, podemos ter un importante tráfico de datos a través desta rede, en bloques de 8KiBs se estamos a empregar o tamaño de bloque por defecto. Polo tanto, a nivel de sistemas debemos imaxinar a rede de interconexión como, por exemplo, unha rede iSCSI.

Especificacións de Oracle

Anos atrás, Oracle indicaba que era preciso o emprego dunha rede física adicada e diferenciada da rede pública para ser utilizada como rede privada de interconexión. Este requisito non era cumprido na maior parte de casos ó non contar con hardware adicado e si con configuración de VLANs específicas dentro dos fabrics de cada cliente. No ano 2012 Oracle publicou o WhitePaper de obrigada lectura para os administradores de rede, Oracle Real Application Clusters (RAC) and Oracle Clusterware Interconnect Virtual Local Area Networks (VLANs) Deployment Considerations. O documento comeza facendo referencia ó ambiguo dos conceptos privada e separada.

Como resumo, os puntos que debemos ter en conta son:

  • Podemos empregar VLANs para a rede de interconexión, tanto tagged como untagged. Este documento se centra nas recomendacións de configuración a ter en conta.
  • Os servidores RAC deben estar conectados en adxacencia OSI de nivel 2, mesmo dominio broadcast e comunicación nun único salto.
  • Deshabilitación ou restrición da configuración STP (Spanning Tree Protocol) para evitar suspensións de tráfico que provoquen un split brain.
  • Habilitación de prunning para as VLANs, de xeito que o tráfico multicast e broadcast privado das redes non sexa propagado máis aló da capa de acceso.

Adicionalmente, é importante ter en conta que a partires da versión 11.2.0.2, é preciso que o tráfico multicast se atope habilitado para a rede 230.0.0.1, ou, dende 11.2.0.2.1, na rede 224.0.0.251. Podemos ver máis información sobre este requisito na nota MOS . Tamén podemos atopar nesta mesma nota unha ferramenta para verificar se este tráfico se atopa habilitado.

Recomendacións adicionais

Hai moitos puntos a ter en conta para a configuración da rede de interconexión, para o que é recomendable acudir á nota MOS Entre as recomendacións destaco as seguintes:

  • Jumbo Frames. Cunha MTU de 1500 bytes, un bloque de 8KiBs precisa ser fragmentado en 6 paquetes, cada un deles ser procesado coas correspondentes cabeceiras, ser enviado, e na recepción reprocesado de novo para volver a ser reensamblado para xerar un único bloque de datos de 8KiBs. Isto supón unha sobrecarga a nivel de procesamento e a nivel de tráfico (maior cantidade de datos de control) que podemos evitar modificando a MTU na rede a 9000 bytes, tamaño co que un bloque de 8KiBs será enviado nun único paquete IP.
  • HAIP. Esta funcionalidade, dispoñible dende 11.2.0.2, é unha alternativa ó emprego de solucións de bonding ou alta dispoñibilidade a nivel de SO, e a opción recomendada por Oracle. Presentamos ó clúster até 4 redes privadas, sempre con subredes diferentes todas elas, e Clusterware xestionará de xeito automático o balanceo do tráfico entre aquelas redes superviventes en caso de fallos de conectividade. Deste xeito, en certo modo desprazamos a responsabilidade de xestión HA na rede privada do administrador de sistemas ó DBA ou administrador da GI. É posible empregar HAIP sobre bonding de SO, pero aporta complexidade e non funcionalidade. Do mesmo xeito, en contornos virtualizados onde as interfaces de rede virtuais están protexidas por bondings físicos, pode non ter sentido práctico configurar múltiples redes HAIP se non aporta tolerancia a erros sobre a xa aportada pola capa de virtualización. Si ten un uso práctico claro en contornos físicos onde HAIP nos permite tolerar o fallo dun switch ou dunha tarxeta de rede de xeito casi transparente (aínda que as BDs non sufren cortes, o tráfico de interconexión si se ve parado durante uns segundos nunha reconfiguración HAIP, polo que pode chegar a percibirse ralentización na BD).
  • Velocidade. Aínda que en moitos casos podemos empregar redes de interconexión a 1GbE, recoméndase o emprego de tecnoloxías cun maior ancho de banda, como 10GbE. Miremos de novo á rede de interconexión como un sistema de I/O e non será preciso xustificar moito mais.
  • En caso de empregar bonding en Linux para a rede de interconexión, non debemos empregar o modo 3. Este modo é o broadcast que transmite os paquetes a través de tódalas interfaces do bonding.
  • Evitar a interferencia da funcionalidade kernel Reverse Path Filtering,establecendo o parámetro kernel rp_filter ó valor 0 (deshabilitado) ou 2 (loose). Esta funcionalidade, ó estar a nivel IP, en caso de emprego de bonding, é no dispositivo de bonding onde a debemos aplicar, non nas interfaces físicas. Esta configuración evita que, con kernels 2.6.31 e superiores, se poida producir unha situación de bloqueo ou descarte de paquetes nestas redes que poidan afectar ó comportamento do clúster. Podemos atopar máis información na nota MOS rp_filter for multiple private interconnects and Linux Kernel 2.6.32+ (Doc ID 1286796.1).
  • Parametrización de buffers de lectura e escritura para os sockets de rede. A recomendación inicial para versións 11g e superiores, é a de net.core.rmem_default=262144, net.core.rmem_max=4194304, net.core.wmem_default=262144 e net.core.wmem_max=1048576. Estes valores poden ser cambiados, por exemplo, en función dos resultados que obteñamos nas probas de rede para correxir potenciais deficiencias que atopemos.
  • Probas. É moi importante validar a rede de interconexión. Na miña experiencia é habitualmente un punto de fallos que pasa desapercibido por non ser validado. O emprego de ferramentas como netperf permitiranos atopar problemas de configuración, que habitualmente pasan por taxas baixas de transferencia, e especialmente por una taxa de perda de paquetes UDP importante. A comunicación Cache Fusion está baseada en UDP, protocolo non orientado a conexión. A perda de paquetes UDP na rede pode conlevar un problema grave de rendemento, e a aparición na BD de eventos global cache de perda de paquetes que deberán ser reenviados. É moi importante abordar probas de comunicación TCP e UDP, e revisar as estatísticas de rede (netstat e ethtool resultan aquí de gran axuda), para, en caso de existir problemas identificar o punto no que se producen (buffers en SO, ring buffers, switches, problema de envío ou de recepción, etc.). Con esta información poderemos traballar cos administradores de redes e sistemas para aportar unha solución, que pode chegar a pasar por restrinxir o ancho de banda mediante a manipulación dos buffers de envío en caso de existir algún problema limitante a nivel de capacidade da infraestrutura. Un dos obxectivos principais é sempre o de verificar que a rede non produce erros relevantes no envío en momentos de elevada carga. Por exemplo, non debemos atopar un 10% de erros de recepción de paquetes UDP. O documento de probas e rendemento de rede debería ser imprescindible en calquera instalación RAC.

Que verificar nas probas de rede?

Imos ver nun exemplo real de medición sobre un contorno RAC de 3 nodos os datos obtidos empregando HAIP con 2 redes privadas, polo que cada servidor ten dúas conexións co resto do clúster, unha a través da rede priv1 e outra a través da rede priv2. No Doc ID 810394.1 mencionado antes podemos atopar mais información sobre enlaces a documentos para probas RAC incluíndo o emprego de netperf.

Nestas táboas, aparecen datos máximos e mínimos porque executamos varios ciclos de probas para comprobar a estabilidade dos datos en diferentes momentos de estrés na rede.

As probas están feitas coa ferramenta netperf, e consisten en obter datos de dous xeitos diferentes, STREAM enviando bloques de 8KiBs para obter o rendemento en MiB/s, e RESPONSE, enviando paquetes de 1 único byte para analizar a latencia existente na rede, vendo neste caso non o rendemento senón a máxima cantidade de paquetes de mínimo tamaño que podemos enviar. Os datos que debemos verificar son:

  • No caso dunha transmisión UDP, ó non existir conexión, é importante comparar os datos de envío e recepción, xa que é habitual que un equipo poida enviar datos a moita velocidade, pero problemas de configuración ou procesamento en destino fai que estes non sexan recibidos. Se só revisamos os datos de envío poderiamos concluír de xeito erróneo que a proba foi correcta. No exemplo vemos que os valores de envío e de recepción son exactos neste caso. No caso de TCP, en caso de problemas de recepción o que atoparemos é que as taxas de envío son inferiores ás que atopamos con UDP xa que o control de conexión regula as transferencias e comunica a correcta recepción de paquetes, xestionando con elo a velocidade de transferencia.
  • Estabilidade nos resultados das probas. Verificar se os resultados son constantes nos diversos ciclos de probas e, de non selo, consultar cos administradores de rede para contrastar os datos.
  • Acadamento do máximo ancho de banda. Tendo en conta o ancho de banda teórico da nosa rede, verificar se é o que estamos acadando. Neste caso, contamos cun bonding de 20Gpbs, que pola súa configuración nos permite para unha única conexión un rendemento máximo de 10Gbps, sendo 1180Mbps un resultado moi bo.
  • Latencia de rede. A proba RESPONSE daranos como resultado o número de paquetes recibidos, polo que a partires delo podemos calcular o tempo de resposta medio para o envío de un paquete de 1 byte pola canle, que neste caso é un valor estable en tódalas probas de 0,03ms, tamén moi bo en comparación con resultados de tests de outros contornos, sen entrar a profundar en valores teóricos a nivel de administrador de redes.

Aínda que nestas probas os datos son claros, é recomendable revisar os erros que se producen nas estatísticas de sistema operativo, empregando ferramentas como netstat e ethtool, especialmente cando facemos as probas de UDP, co obxectivo de identificar os potenciais puntos de fallo se atopamos diferencias entre o envío e a recepción. Neste caso, os resultados para o par de nodos rac1 – rac2, son os seguintes:

Comparamos as taxas de envío coas de recepción. Sen entrar en detalle, por como están recollidas as métricas no script empregado para elo, é normal que as taxas de recepción sexan aproximadamente a metade que as de envío, debido á existencia de dúas redes de interconexión. Vemos nas estatísticas que de se recibiron mais de 227 millóns de paquetes dos que sólo 254 xeraron un erro e foron polo tanto descartados, sendo a poncentaxe de erros descartable. Vemos tamén o efecto dos jumbo frames, xa que nin no envío se crean paquetes IP, nin na recepción se teñen que reensamblar. Os erros de envío tamén son insignificantes, contabilizando 22 para un total de preto de 590 millóns de paquetes IP. Con ethtool vemos que non se producen a nivel físico (tarxeta de rede) erros, sendo un resultado óptimo o que amosamos nestas capturas.

Validación HAIP

Unha vez validada a capacidade e configuración das redes, algo que facemos antes da instalación de software, tras ter despregado a GI e as BDs, debemos incluír nas probas de clúster a validación da HA con HAIP. Para elo, o noso inventario de probas incluirá a perda individual de cada rede. Nestas probas validaremos:

  • Estado inicial antes de lanzar as probas.
  • Failover da IP HAIP á rede supervivente tras desconexión de cableado nunha das redes privadas.
  • Correcta actualización da táboa de rutas no sistema operativo do nodo na que executamos a proba.
  • Recuperación de IP e rutas unha vez recuperada a conexión.

Como exemplo, facemos unha proba nu nodo con dúas redes privadas. A situación inicial é a seguinte:

[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

Temos dúas redes privadas, cada unha delas asignadas ás interfaces físicas eno53 e eno54. Sobre estas redes, Oracle ten arrincadas as IPs 169.254.0.0 (inicialmente en eno53), e 169.254.128.0 (eno54). Desconectamos o cable da tarxeta eno53. Tras facelo, o resultado é:

[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

A IP 169.254.0.0 segue arrincada e disposta para a comunicación co resto de membros do clúster, coa diferencia de que agora está na interface física eno54 tras a perda de eno53. Adicionalmente comprobamos que a tábos de enrutamento do SO foi modificado para reflexar este cambio. Ó reconectar o cable, tras un segundos, a situación volve a ser a 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

No fondo é algo moi simple, pero é moi importante executar esta proba para estar seguros de que ningunha configuración a nivel de SO ou rede está a interferir na correcta relocalización da IP.

Conclusións

En xeral, a calidade e rendemento da nosa infraestrutura non debe ser algo improvisado, e debe responder ás expectativas e especificacións do noso hardware e configuración. Podemos despregar un RAC de xeito rápido sen asegurarnos de sei hai problemas, ou podemos forzar o hardware e software para sometelo a estrés e probas de HA para tentar buscar potenciais puntos de fallo, solucionalos e finalmente validar o produto instalado. É demasiado frecuente atopar problemas na rede de interconexión como para obviar este punto, que debe ser un requisito imprescindible en calquera despregue RAC, eleborando o correspondente documento de resultados das probas que poder contrastar cos administradores de sistemas e rede.

Créditos

Imaxe do post obra de Vera Pereiro. A Suricata de Arumel.

Revisión: Alicia Constela.