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

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

Enviado por miguelcarmona :: 3 de noviembre de 2008

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.

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):

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):

Aceptamos la configuración y veremosla nueva interfaz 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 las interfaces 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á la configuración necesaria 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 router 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 no los aceptaba, al transferir desde y hasta varios equipos distintos, no se 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.

Insistir en que todas las tarjetas de red tienen una velocidad 10/100

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.

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.

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 hubo 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 caída 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