Crear un canal bonding
El channel bonding o unión de interfaces de red consiste en simular un dispositivo de red con gran ancho de banda uniendo varias tarjetas de red independientes, de manera que las aplicaciones solo verán una interfaz de red. Con el channel bonding conseguimos varias cosas:
- Mayor ancho de banda: el ancho de banda de la interfaz virtual será la suma de los anchos de banda de las interfaces reales. Será necesario que el ancho de banda de la interfaz de salida del switch sea mayor que el de las interfaces individuales.
- Balanceo de carga: tendremos balanceo de carga del tráfico de red entre todas las interfaces reales (por defecto Round Robin).
- Tolerancia a fallos: si falla una tarjeta de red los datos irán por las restantes que estén en buen estado.
Algunos términos habituales en el contexto del bonding son:
- Canal bonding: Es la unión de dos o más interfaces físicas de red en una única interfaz virtual.
- Interfaz de canal bonding ó interfaz maestra: Es la interfaz de red virtual que agrupa a las interfaces de red físicas, y es lo que ve el sistema operativo y el exterior.
- Interfaz esclava: Cada una de las interfaces de red físicas que están conectadas al canal bonding.
- Interfaz esclava primaria: Interfaz esclava que se encuentra activa por defecto.
Existen varios tipos de bonding:
- Modo 0 ó Balance-RR (Balance Round Robin): transmite paquetes de manera secuencial entre todos las interfaces esclavas disponibles.
- Provee: balanceo de carga y tolerancia a fallos.
- Requiere: generalmente requiere poder agrupar puertos en los switchs. Las nomenclaturas de estos grupos dependen del fabricante del switch, concretamente, Cisco llama a estas agrupaciones EtherChannel.
- Modo 1 ó Active-Backup: una interfaz esclava del canal bonding está activa en todo momento, mientras que las otras permanecen en estado pasivo. Cuando la interfaz activa falla, la siguiente interfaz esclava toma la dirección MAC y se convierte en la interfaz activa. No hay balanceo de carga. Se aconseja conectar cada tarjeta a un switch distinto, con lo que conseguimos evitar los problemas del switch.
- Provee: tolerancia a fallos únicamente.
- Requiere: no requiere ningún soporte especial en el switch.
- Modo 2 ó balance-xor: las transmisiones son balanceadas a través de todas las interfaces esclavas en modo Xor ([source-MAC xor dest-MAC] mod n-slaves), es decir, el mismo esclavo es seleccionado para cada destino único MAC.
- Provee: tolerancia a fallos y balanceo de carga basado en el destino.
- Requiere: generalmente poder agrupar puertos en los switchs.
- Modo 3 ó broadcast: se transmite todo por todas las interfaces. Este método no balancea.
- Provee: tolerancia a fallos.
- Requiere: generalmente poder agrupar puertos en los switchs.
- Modo 4 ó 802.3ad: Modo IEEE Dynamic Link Aggregation, permite gestionar el balanceo, la velocidad y el duplex de la interfaz, pero requiere que el módulo del kernel y el switch lo soporten.
- Provee: balanceo de carga.
- Requiere: soporte a 802.3ad en el switch-
- Modo 5 ó balance-TLB (Adaptative Transmit Load-Balance): balancea la carga del tráfico de salida entre los esclavos dependiendo de la velocidad de estos y de la carga total. El tráfico de entreda es recibido por un esclavo, en caso de fallar otro esclavo toma su MAC y continúa recibiendo tráfico.
- Provee: balanceo de carga distribuido y tolerancia a fallos.
- Requiere: no requiere ningún soporte en el switch.
- Modo 6 ó balance-ALB (Adaptative Load-Balancing): realiza el balanceo anterior además de un balanceo también en la recepción.
- Provee: balanceo de carga distribuido y tolerancia a fallos.
- Requiere: no requiere nada especial en el switch, pero el módulo del kernel debe soportar cambio de MAC en caliente (mientras la interfaz esté activa).
Para implementar el channel bonding se requiere que todas las tarjetas de red instaladas en el servidor soporten:
- Misma velocidad.
- Misma configuración de duplex.
Para confirmar estos datos, podemos usar el comando ethtool.
A nivel software se requiere que el kernel incorpore el módulo bonding, algo que sucede en los kernels actuales:
# modinfo bonding
filename: /lib/modules/3.2.0-4-686-pae/kernel/drivers/net/bonding/bonding.ko
alias: rtnl-link-bond
author: Thomas Davis, tadavis@lbl.gov and many others
description: Ethernet Channel Bonding Driver, v3.7.1
version: 3.7.1
license: GPL
srcversion: 0384DF6574E0ED31BA573D8
depends:
intree: Y
vermagic: 3.2.0-4-686-pae SMP mod_unload modversions 686
parm: max_bonds:Max number of bonded devices (int)
parm: tx_queues:Max number of transmit queues (default = 16) (int)
parm: num_grat_arp:Number of peer notifications to send on failover event (alias of num_unsol_na) (int)
parm: num_unsol_na:Number of peer notifications to send on failover event (alias of num_grat_arp) (int)
parm: miimon:Link check interval in milliseconds (int)
parm: updelay:Delay before considering link up, in milliseconds (int)
parm: downdelay:Delay before considering link down, in milliseconds (int)
parm: use_carrier:Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default) (int)
parm: mode:Mode of operation; 0 for balance-rr, 1 for active-backup, 2 for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6 for balance-alb (charp)
parm: primary:Primary network device to use (charp)
parm: primary_reselect:Reselect primary slave once it comes up; 0 for always (default), 1 for only if speed of primary is better, 2 for only on active slave failure (charp)
parm: lacp_rate:LACPDU tx rate to request from 802.3ad partner; 0 for slow, 1 for fast (charp)
parm: ad_select:803.ad aggregation selection logic; 0 for stable (default), 1 for bandwidth, 2 for count (charp)
parm: min_links:Minimum number of available links before turning on carrier (int)
parm: xmit_hash_policy:balance-xor and 802.3ad hashing method; 0 for layer 2 (default), 1 for layer 3+4, 2 for layer 2+3 (charp)
parm: arp_interval:arp interval in milliseconds (int)
parm: arp_ip_target:arp targets in n.n.n.n form (array of charp)
parm: arp_validate:validate src/dst of ARP probes; 0 for none (default), 1 for active, 2 for backup, 3 for all (charp)
parm: fail_over_mac:For active-backup, do not set all slaves to the same MAC; 0 for none (default), 1 for active, 2 for follow (charp)
parm: all_slaves_active:Keep all frames received on an interfaceby setting active flag for all slaves; 0 for never (default), 1 for always. (int)
parm: resend_igmp:Number of IGMP membership reports to send on link failure (int)
Además, es necesario instalar el paquete ifenslave-2.6:
# aptitude install ifenslave-2.6
Tras los dos puntos anteriores, lo único que se precisa es crear la interfaz del canal bonding o interfaz maestra en el fichero /etc/network/interfaces teniendo en cuenta lo siguiente:
- Las interfaces esclavas del canal bonding no deben tener ninguna configuración en el fichero /etc/network/interfaces, ni se activarán con líneas auto o allow-hotplug.
- Elegimos un nombre para la interfaz maestra, normalmente bond0, bond1, etc.
- Si queremos que el canal bonding se active automáticamente al arrancar el sistema añadimos la línea: auto bond0
- Definimos la interfaz maestra con una línea iface y sus parámetros normales para el método static (address, netmask, gateway, network, broadcast, up, down, etc.) y los parámetros bonding.
Los parámetros bonding de iface son:
- bond_mode: modo de funcionamiento elegido (0, 1, etc.), aunque también podemos poner el nombre en minúscula.
- bond_miimon: tiempo en milisegundos entre revisiones del sistemas de las interfaces para ver si tienen algún problema (estropeada o cable desconectado).
- bond_downdelay: tiempo en milisegundos para considerar caída una interfaz.
- bond_updelay: tiempo en milisegundos para considerar levantada una interfaz.
- bond_slaves: listado ordenado de las interfaces que forman el canal bonding. En el modo active-backup la primera será la interfaz esclava primaria.
Una configuración de canal bonding en modo active-backup con dos interfaces físicas, se configuraría de la siguiente forma:
auto bond0
iface bond0 inet static
address 192.168.1.20
netmask 255.255.255.0
gateway 192.168.1.1
network 192.168.1.0
broadcast 192.168.1.255
bond_mode active-backup
bond_miimon 100
bond_downdelay 300
bond_updelay 300
bond_slaves eth0 eth1
Tras levantar la interfaz podemos comprobar que el canal bonding está funcionando:
# ifup bond0
# ifconfig
bond0 Link encap:Ethernet HWaddr 08:00:27:28:42:d2
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe28:42d2/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:409 errors:0 dropped:6 overruns:0 frame:0
TX packets:452 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:373079 (364.3 KiB) TX bytes:56761 (55.4 KiB)
eth0 Link encap:Ethernet HWaddr 08:00:27:28:42:d2
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:359 errors:0 dropped:0 overruns:0 frame:0
TX packets:452 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:368233 (359.6 KiB) TX bytes:56761 (55.4 KiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:28:42:d2
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:50 errors:0 dropped:6 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4846 (4.7 KiB) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1200 (1.1 KiB) TX bytes:1200 (1.1 KiB)
# lsmod | grep bond
bonding 73419 0
Podemos observar cómo solo la interfaz maestra es la que tiene la única dirección IP del canal, y la MAC que usa el canal es la MAC de la tarjeta esclava primaria.
Se pueden consultar los datos del canal bonding mirando el contenido del fichero /proc/net/bonding/bond0:
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 300
Down Delay (ms): 300
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:28:42:d2
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:37:d8:06
Slave queue ID: 0
Podemos ver los mensajes del sistema al iniciar la creación del canal bonding con dmesg o también en /var/log/message:
# dmesg | grep bond
[ 12.701196] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 12.705263] bonding: bond0: Setting MII monitoring interval to 100.
[ 12.705296] bonding: bond0: Setting down delay to 300.
[ 12.705323] bonding: bond0: Setting up delay to 300.
[ 12.716012] bonding: bond0: setting mode to active-backup (1).
[ 12.726534] bonding: bond0: Adding slave eth0.
[ 12.730408] bonding: bond0: enslaving eth0 as a backup interface with a down link.
[ 12.736587] bonding: bond0: Adding slave eth1.
[ 12.738877] bonding: bond0: enslaving eth1 as a backup interface with a down link.
[ 12.745002] bonding: bond0: link status up for interface eth0, enabling it in 0 ms.
[ 12.745005] bonding: bond0: link status up for interface eth1, enabling it in 300 ms.
[ 12.745041] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 12.748175] bonding: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex.
[ 12.748175] bonding: bond0: making interface eth0 the new active one.
[ 12.749383] bonding: bond0: first active interface up!
[ 12.749399] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 12.948139] bonding: bond0: link status definitely up for interface eth1, 1000 Mbps full duplex.
[ 22.888074] bond0: no IPv6 routers present
El funcionamiento por defecto del canal bonding en modo active-backup, el cual hace que todas las tarjetas trabajen con la misma MAC (la de la esclava primaria), interfiere con los métodos de enrutamiento interno de VirtualBox entre el anfitrión y el invitado de la máquina virtual. Esto obliga a configurar el módulo del kernel del bonding para que la dirección MAC de la tarjeta maestra sea siempre la dirección MAC de la tarjeta esclava activa, permaneciendo cada interfaz esclava con su propia dirección MAC. Este funcionamiento causará leves retrasos, pues los equipos tendrán que actualizar sus tablas ARP cuando se produzcan fallos en el canal bonding. El parámetro a añadir en el fichero /etc/network/interfaces para conseguir esto es el siguiente:
bond_fail_over_mac active
Licencia: licencia de software libre GPL