Está en: » Artículos »

Tolerancia a fallos y balanceo de cargas en red (bonding)

Tolerancia a fallos y balanceo de cargas en red (bonding)

La técnica bonding consiste básicamente en hacer funcionar varias tarjetas de red con la misma dirección ip. Así podemos realizar que funcionen como una única tarjeta, obteniendo ventajas como la tolerancia a fallos y balanceo de cargas.

Actualmente hay 7 métodos de funcionamiento:

  • balance-rr (mode=balance-rr o mode=0): Configura una política de round-robin para la tolerancia de fallas y balanceo de cargas. Las transmisiones son recibidas y enviadas secuencialmente en cada interfaz esclava vinculada comenzando con la primera disponible.
  • active-backup (mode=active-backup o mode=1): Configura una política de respaldo activa para la tolerancia de fallas. Las transmisiones son recibidas y enviadas a través de la primera interfaz esclava vinculada disponible. Sólo se utiliza otra interfaz esclava vinculada si la interfaz esclava activa falla.
  • balance-xor (mode=balance-xor o mode=2): Configura una política XOR (o-exclusivo) para la tolerancia de fallas y el balanceo de cargas. Usando este método la interfaz coincide la dirección MAC de las peticiones entrantes con la dirección MAC de una de las NICs esclava. Una vez que se establece el enlace, las transmisiones son enviadas secuencialmente comenzando con la primera interfaz disponible.
  • broadcast (mode=broadcast o mode=3): Configura una política de difusión para la tolerancia de fallas. Las transmisiones son enviadas en todas las interfaces esclavas.
  • 802.3ad (mode=802.3ad o mode=4): Configura una política de agregación de enlace dinámico IEEE 802.3ad. Crea grupos de agregación que comparten las mismas especificaciones de velocidad y duplex. Transmite y recibe en todos los esclavos en el agregador activo. Requiere de un switch que sea conforme con 802.3ad.
  • balace-tbl (mode=balace o mode=5): Configura una política de balanceo de carga de transmisión (Transmit Load Balancing, TLB) para la tolerancia de fallas y el balanceo de cargas. El tráfico saliente es distribuido de acuerdo a la carga actual en cada interfaz esclava. El esclavo actual recibe el tráfico entrante. Si el eslavo receptor falla, otro esclavo toma la dirección MAC del esclavo fallido.
  • balance-alb (mode=balance o mode=6): Configura una política de balanceo de cargas activa (Active Load Balancing, ALB) para la tolerancia de fallas y el balanceo de cargas. Incluye el balanceo de cargas de transmisión y recepción para el tráfico IPV4. Se logra el balanceo de las cargas recibidas a través de la negociación ARP.


Es importante que el kernel soporte bonding. La mayoría de las distribuciones cotidianas actuales lo soportan, como es el caso de openSuse.

Para realizar dicha acción en openSuse 11.0 (y supongo que en versiones posteriores), es tan fácil como:

Abrimos yast, y nos dirigimos al apartado de configuración de red. Una vez allí, eliminamos la configuración de red para las interfaces que querramos utilizar.

yast - eliminar interfaces de red

yast - eliminar interfaces de red

Una vez eliminadas, añadimos una nueva interfaz, con tipo de dispositivo Asociado (si teneis yast en inglés, creo que el tipo de dispositivo se llamaría bonding o bond):

yast - agregando interfaz bond

yast - agregando interfaz bond

Elejimos las interfaces que se utilizarán para bonding, método de funcionamiento y la dirección ip a utilizar (en mi caso yo lo he dejado para resolver mediante dhcp):

yast - agregando interfaces físicas a bond0

yast - agregando interfaces físicas a bond0

Aceptamos la configuración y veremosla nueva interfaz configurada.

yast - vista final con interfaz bond0 configurada

yast - vista final con interfaz bond0 configurada

Tengo que aclarar que no todas las interfaces aceptan todos los modos. Por ejemplo, para un par de tarjetas algo viejas ya (chip RTL-8139), no me permitió los modos 802.3ad, balace-tbl y balance-alb (el estándar 802.3ad, el cual se estableció en 2000, por lo que tarjetas anteriores a esta fecha seguramente no lo aceptarán).

Hay otras opciones útiles como miimon, que especifica la frecuencia (en milisegundos) con la que se verifica si la interfaz física está activa. Para definirlo, bastaría con editar la interface bond creada y establecer a continuación del modo miimon=100 (o el tiempo que deseemos). Prácticamente todas las tarjetas de la actualidad soportan MII, pero para comprobarlo, puede ejecutar ethtool <interfaz_red> | grep “Link detected:” y si reporta Link detected: yes, es que está soportado. Claro está que para que lo reporte, la tarjeta debe estar conectada al swich o equipo pertinente.

Para configurar bonding en sistemas openSuse 10.3 o anteriores, o sistemas derivados de redhat (como fedora), hay una entrada en opensuse.org que nos indica como realizarlo. http://es.opensuse.org/Bonding

Ya que una de la interfaz sin configurar es la que utilizo para despertar el equipo (wake on lan), al no estar configurada no se establece la configuración de ethtool para dejar esta interfaz a la escucha del paquete mágico. Para solucionar esto, podemos abrir de nuevo yast, configuración de red, editamos la interfaz indicada y la establecemos sin configuración de ip. Esto nos creará el archivo necesario para configurar el wake on lan (WOL)

Estadísticas

Las pruebas que he realizado se basan en dos equipos con dos tarjetas cada uno conectado mediante un ruter WRT54G. Los modos 802.3ad, balace-tbl y balance-alb no los he podido probar, ya que uno de los equipos no me lo aceptaba. Configurando dichos modos en el equipo que nos lo aceptaba, al transferir desde y hasta varios equipos distintos, nose reflejaron cambios de aumento de ancho de banda.

Respecto a los modos active-backup y balance-xor, tampoco se amplió el ancho de banda, ya que utiliza una tarjeta principalmente, y si esta falla, utiliza la siguiente.

La única estadística que puedo reportar es para el modo balance-rr.

Se utilizan:

  • Equipo NFS->  openSuse 11.0, compartiendo ficheros mediante nfs y con bonding modo balance-rr.
  • Equipo SMB-> Windows XP SP2, compartiendo ficheros mediante su protocolo de compartición de bloques smb y sin ningún tipo de bonding.
  • Equipo CLIENTE-> openSuse 11.0,  cliente de acceso a los otros equipos, utilizado para las estadísticas y con bonding modo balance-rr.

Para los gráficos de estadísticas, se utiliza el software ktrafficanalyzer

El promedio lo he calculado sobre el tamaño de archivo y el tiempo que ha durado la operación, por lo que se descartada el peso extra del archivo (cabeceras de los paquetes, etc…) y las confirmaciones.

Transferencia de un archivo entre equipo CLIENTE y equipo SMB:

  • Tamaño del archivo: 4.688,93 Mb
  • Tiempo de copia: 00:05:09
  • Velocidad media de copia: 14,20 Mb/s.

estadisticas - bond0 / balance-rr - protocolo NFS

estadisticas - bond0 / balance-rr - protocolo NFS

La velocidad ha mejorado respecto a una conexión normal (sin bonding) de 100 Mbits. Aún así, nose alcanza una gran velocidad como podría ser de esperar. Seguramente sea producido por una gran cantidad de colisiones en el swich.

Tambien hay que tener en cuenta que hay prácticamente 1Mb de transferencia en la subida (confirmación de paquetes y otros detalles) que es un ancho de banda consumido.

Transferencia de un archivo entre equipo CLIENTE y equipo NFS y otro archivo entre equipo CLIENTE y equipo SMB a la vez:

  • De equipo CLIENTE a equipo NFS:
    • Tamaño del archivo: 4.688,93 Mb
  • De equipo CLIENTE a equipo SMB:
    • Tamaño del archivo: 648,89 Mb
  • Tiempo de copia: 00:05:48
  • Velocidad media total de copia: 14,57 Mb/s.

estadisticas - bond0 / balance-rr - protocolo NFS y SMB (2 archivos)

estadisticas - bond0 / balance-rr - protocolo NFS y SMB (2 archivos)

En este caso, la velocidad de transferencia ha subido ligeramente. Así mismo ha subido también el consumo de descarga al tener más confirmaciones por parte de ambos equipos. Tambien hay que decir que mediante el protocolo smb se obtiene un peor rendimiento que mediante nfs, por lo que si los tres equipos utilizasen nfs, seguramente se hubiese notado mucho más el aumento de transferencia.

Conclusiones:

El sistema, verdaderamente se ha portado bastante bien para el hardware de red utilizado. Mediante un método bastante económico, hemos establecido un sistema que ha aumentado el ancho de banda y tiene un buen refuerzo de tolerancia a fallos.

En las pruebas de tolerancia a fallos, mientras estaba la transferencia en curso, desenchufé una interfaz, y no serealizó ningún corte en la transferencia, simplemente una bajada en la velocidad de transferencia. Al conectarla de nuevo, se aumentó automáticamente la velocidad sin ninguna intervención.

También probé a conectar una interfaz (anteriormente desconectada) y rápidamente desconectar la que estaba conectada. La transferencia no se interrumpió, y el gráfico mostró una caida instantánea y vuelta a subir ( de una duración aproximada de 600 milisegundos).

Así queda constancia de que es un buen sistema para combatir posibles fallos.Para equipos en producción, lo correcto sería conectar las tarjetas a distintos swich (y estos a su vez que estén conectados a distintos SAI), de manera que si cae un cable o un swich, el sistema siga en funcionamiento.

Referencias:

http://es.opensuse.org/Bonding

Comentarios

  1. Eduardo dice:

    es derivados no “deribados” que no existe…

  2. Juan Manuel dice:

    hola una consulta, una vez que configuro el dispositivo. Las interfaces interfaces de red son usables por separado para usarlas por ejemplo con iptables o estan ocupadas por el bounding? no se si me esplico!!!

    • Te explicas pero no le termino de encontrar la lógica.
      Se supone que unes varias tarjetas para ganar velocidad y tener una mejor tolerancia a fallos por lo que lo lógico es aplicar la configuración de iptables para la interface bonding; no tiene lógica que establezcamos directivas por separado ya que ambas tarjetas deben hacer lo mismo por lo que tendrían las mismas reglas.
      De todas formas y contestando a tu pregunta, ni idea de si se puede aplicar.

      ¿algún motivo en concreto para hacerlo?

Deje su comentario

Previsualización de comentario
  1. Anónimo dice:





Pings para esta entrada