Hola a todos,
Hoy vengo con un articulo que mezcla algo de hard y algo de soft. A día de hoy, con el auge de los entornos virtuales, es relativamente sencillo montar máquinas virtuales (también es aplicable a las físicas) con varias tarjetas de red. De hecho en VirtualBox, que es el software de servidor que empleo para la creación de dichas máquinas, se pueden crear hasta 4 interfaces, que yo sepa, por máquina.
En mi caso, la primera vez que vi un interfaz de este tipo fué en una NAS de Netgear. Me pareció curioso cómo empleaba las interfaces físicas para proporcionar diversos servicios, entre otros equilibrio de carga adaptativo, o simplemente failover. En cualquiera de los casos, me quede con la copla y ahora lo he trasladado a ciertas máquinas para lograr esa misma funcionalidad.
¿Que significa?
¿Bueno, cómo podríamos definir un interfaz bonded?, pues simplemente como una agrupación lógica de interfaces de red físicos que son agrupados con una finalidad, normalmente o bien por cuestiones de rendimiento o bien por cuestiones de disponibilidad o por ambas cosas como veremos más adelante.
Como ejemplo del primero de los casos, dos interfaces físicas de red, unidas lógicamente, pueden transmitir / recibir paquetes de forma simultánea y balancear la carga en base a la situación de cada una de ellas.
Como ejemplo del segundo de los casos lo más habitual es mantener un interfaz en funcionamiento normal y tener otro de reserva para el caso de que el primero falle.
¿Que necesitamos?
Bueno, pues necesitamos una máquina con al menos dos tarjetas de red. En el caso que nos ocupa, yo tengo varias máquinas virtuales con varias de ellas. Emplearemos una de ellas para mostrar la configuración.
En la captura siguiente podéis apreciar la máquina con 4 tarjetas de red. Luego veremos en detalle su configuración en debian.
¿Para que podemos emplearlo?
Ya lo he comentado en puntos anteriores, por cuestiones de rendimiento o simplemente por cuestiones de disponibilidad física. Esto realmente se corresponde con lo que en el driver se denomina política y puede tener los siguientes valores:
- balance-rr (0): clásica política round robin, transmite los paquetes en orden secuencial empleado todas los interfaces esclavos existentes. Este modo proporciona tanto balanceo de carga como tolerancia a fallos.
- active-backup (1): Solo uno de los interfaces esclavos se encuentra activo. El otro solo pasa a activo en el caso de que el primero falle. Este modo solo provee tolerancia a fallos.
- balance-xor (2): basa la transmisión en los hash de los direcciones origen y destino de los paquetes. El algoritmo por defecto solo considera para el calculo direcciones MAC. Todo esto dicho de otra forma mas entendible, permite emplear cada uno de los esclavos para las comunicaciones con ciertas máquinas, de esta forma separando de alguna manera la transmisión. Este modo proporciona tanto balanceo de carga como tolerancia a fallos.
- broadcast (3): Transmite todos los paquetes por todas las interfaces. Este modo solo proporciona tolerancia a fallos.
- 802.3ad (4): crea grupos de interfaces que comparten velocidad y tipo de transmisión. Emplea todos los esclavos que pertenecen al grupo conforme a la especificación 802.3ad. Este modo proporciona tanto balanceo de carga como tolerancia a fallos.
- balance-tbl (Adaptive transmit load balancing) (5): Es un modo que no requiere ningún tipo de soporte por parte de los switch de red, al contrario que en el caso anterior. Los paquetes que son transmitidos a la red se envian por los esclavos dependiendo de la carga de cada uno de ellos. El tráfico de entrada solo es recibido por uno de los interfaces. En el caso de que este de entrada falle, es empleado el otro directamente. Este modo soporta tanto balanceo de carga como tolerancia a fallos.
- balance-alb (Adaptive load balancing) (6): Es un modo que no requiere ningún tipo de soporte por parte de los switch de red, e incluye tanto TLB de salida como balanceo de entrada. Para ello emplea paquetes ARP. Este modo soporta tanto balanceo de carga como tolerancia a fallos.
En base a los modos que acabo de indicar, creo que el lector ya se estará haciendo una idea de para que podemos querer configurar un interfaz de este tipo.
Configuración en debian
Bien, dicho lo dicho pasemos a ver cómo configurar un par de bonded. En el caso que voy a poner de ejemplo, como ya se ha comentado, la máquina virtual cuenta con cuatro tarjetas de red. ¿Y para que cuatro?, bien, es una máquina especial, dedicada a hacer copias de seguridad a traves de la LAN, y para ello he destinado dos tarjetas de red para la red interna y dos mas para la red externa. De esta forma logro que el tiempo que la máquina se encuentra haciendo la copia de seguridad a traves de la LAN emplee solo uno de los interfaces bonded y para el uso de otros servicios emplee el otro interfaz, logrando de esta forma mejorar la velocidad de la copia, al menos, es el objetivo aunque realmente no he hecho pruebas de rendimiento. Debemos tener en cuenta que este escenario de ejemplo poca ventaja va a sacar de la configuración, pues por debajo de la máquina virtual solo existe un host con una tarjeta de red, pero si en vuestro caso disponéis de máquinas con varias interfaces físicas seguro que os podéis beneficiar.
Existen varias alternativas para configurar los interfaces bounded, en mi caso el que uso es el siguiente:
- uso del paquete ifenslave, para ello procedemos a su instalación
- A continuación procedemos a su configuración que la realizaremos en el propio fichero /etc/network/interfaces. En este fichero se definen las cuatro interfaces esclavas y las dos bonded, asociando de dos en dos a las bonded. En mi caso el fichero queda de la siguiente forma:
root@clonezillaServer:~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet manual bond-master bond0 bond-primary eth0 bond-mode balance-alb auto eth1 iface eth1 inet manual bond-master bond0 bond-primary eth0 bond-mode balance-alb auto eth2 iface eth2 inet manual bond-master bond1 bond-primary eth2 bond-mode balance-alb auto eth3 iface eth3 inet manual bond-master bond1 bond-primary eth2 bond-mode balance-alb # Define master auto bond0 iface bond0 inet dhcp bond-slaves none bond-primary eth0 bond-mode balance-alb bond-miimon 100 # Define master auto bond1 iface bond1 inet dhcp bond-slaves none bond-primary eth2 bond-mode balance-alb bond-miimon 100
En estas condiciones si hago un ifconfig de la máquina podremos ver que las direcciones IP de la LAN las han tomado los interfaces bonded en lugar de los «físicos». Interesante tambien fijarse, que los interfaces bond han heredado la MAC de la tarjeta ethx definida como primary en cada una de las interfaces bonded.
root@clonezillaServer:~# ifconfig -a bond0 Link encap:Ethernet HWaddr 08:00:27:a3:9e:92 inet addr:192.168.3.97 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fea3:9e92/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:944 errors:0 dropped:164 overruns:0 frame:0 TX packets:599 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:234249 (228.7 KiB) TX bytes:48053 (46.9 KiB) bond1 Link encap:Ethernet HWaddr 08:00:27:8a:d2:11 inet addr:192.168.3.76 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe8a:d211/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:450 errors:0 dropped:164 overruns:0 frame:0 TX packets:546 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:48636 (47.4 KiB) TX bytes:39482 (38.5 KiB) eth0 Link encap:Ethernet HWaddr 08:00:27:a3:9e:92 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:744 errors:0 dropped:0 overruns:0 frame:0 TX packets:326 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:214241 (209.2 KiB) TX bytes:28048 (27.3 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:d5:97:7c UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:200 errors:0 dropped:164 overruns:0 frame:0 TX packets:273 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20008 (19.5 KiB) TX bytes:20005 (19.5 KiB) eth2 Link encap:Ethernet HWaddr 08:00:27:8a:d2:11 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:243 errors:0 dropped:0 overruns:0 frame:0 TX packets:293 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:28208 (27.5 KiB) TX bytes:22950 (22.4 KiB) eth3 Link encap:Ethernet HWaddr 08:00:27:2d:e4:a4 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:207 errors:0 dropped:164 overruns:0 frame:0 TX packets:253 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20428 (19.9 KiB) TX bytes:16532 (16.1 KiB) 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:65536 Metric:1 RX packets:70 errors:0 dropped:0 overruns:0 frame:0 TX packets:70 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4944 (4.8 KiB) TX bytes:4944 (4.8 KiB)
Conclusiones
Pues por mi parte poco más que añadir. Si estáis interesados en el asunto, hay multitud de información en inet sobre el mismo, bastante más completa y detallada que este articulo.
Mi idea era simplemente trasladaros esta posibilidad, para que vosotros mismos a partir de este momento podáis buscar la información que estiméis conveniente e implementéis este tipo de interfaz en los casos que estiméis conveniente.
Fuentes de información
- https://wiki.debian.org/Bonding
- https://www.kernel.org/doc/Documentation/networking/bonding.txt
- https://en.wikipedia.org/wiki/Link_aggregation
- http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html#wp1111405
- https://en.wikipedia.org/wiki/Address_Resolution_Protocol