Cómo configurar la agrupación de red de alta disponibilidad y conmutación por error en Linux

Este tutorial explica cómo configurar la agrupación de red en un servidor Linux. Antes de comenzar, permítanme explicar qué es la agrupación de red y qué hace. En un entorno de Windows, la agrupación de red se llama agrupación de red, esta es una característica que ayuda a cualquier arquitectura de servidor a proporcionar alta disponibilidad y conmutación por error en escenarios donde uno de los cables ethernet principales tiene un mal funcionamiento o está mal configurado.

Normalmente, es una buena práctica y una característica imprescindible que debe implementarse cuando se configura un servidor para fines de producción. Aunque esta característica se puede realizar en una configuración de entorno Linux, primero debe confirmar con su administrador de red para asegurarse de que los switches que están vinculados a su servidor tienen soporte para la agrupación de red. Hay varios modos de agrupación que se pueden implementar en su entorno de servidor. A continuación se muestra una lista de los modos disponibles y lo que hacen:

• Balance-rr
  Este modo proporciona características de balanceo de carga y tolerancia a fallos (conmutación por error) a través de una política de round-robin. Significa que transmite paquetes en orden secuencial desde el primer esclavo disponible hasta el último.
• Active-Backup
  Este modo proporciona características de tolerancia a fallos a través de una política de active-backup. Esto significa que una vez que el ethernet de agrupación está activo, solo 1 de los esclavos ethernet está activo. El otro esclavo ethernet solo se activará si y solo si el esclavo activo actual deja de estar activo. Si elige este modo, notará que la dirección MAC de agrupación es visible externamente en solo un adaptador de red. Esto es para evitar confundir el switch.
• Balance-xor
  Este modo proporciona balanceo de carga y tolerancia a fallos. Transmite en función de la política de hash de transmisión seleccionada. Se pueden seleccionar políticas de transmisión alternativas a través de la opción xmit_hash_policy.
• Broadcast
  Este modo proporciona solo tolerancia a fallos. Transmite todo en todas las interfaces ethernet esclavas.
• 802.3ad
  Este modo proporciona balanceo de carga y tolerancia a fallos. Crea un grupo de agregación que comparte la misma velocidad y configuraciones de dúplex. Utiliza todas las interfaces ethernet esclavas en el agregador activo, se basa en la especificación 802.3ad. Para implementar este modo, el ethtool debe soportar los controladores base para recuperar la velocidad y el modo de dúplex de cada esclavo. El switch también debe soportar la agregación de enlace dinámica. Normalmente, esto requiere la intervención de un ingeniero de red para una configuración detallada.
• Balance-TLB
  Este modo proporciona capacidades de balanceo de carga ya que el nombre TLB representa balanceo de carga de transmisión. Para este modo, si la configuración tlb_dynamic_lb = 1, entonces el tráfico saliente se distribuye de acuerdo con la carga actual en cada esclavo. Si la configuración tlb_dynamic_lb = 0, entonces el balanceo de carga está deshabilitado, sin embargo, la carga se distribuye solo utilizando la distribución hasd. Para este modo, el ethtool debe soportar los controladores base para recuperar la velocidad de cada esclavo.
• Balance-ALB
  Este modo proporciona capacidades de balanceo de carga ya que el nombre TLB representa balanceo de carga adaptativo. Similar a balance-tlb, excepto que tanto el tráfico de envío como el de recepción están agrupados. Recibe balanceo de carga mediante la negociación ARP. El controlador de agrupación intercepta las respuestas ARP enviadas por el sistema local en su camino hacia afuera y sobrescribe la dirección de hardware de origen con la dirección de hardware única de uno de los esclavos en la agrupación. Para este modo, el ethtool debe soportar los controladores base para recuperar la velocidad de cada esclavo.

1. Nota Preliminar

Para este tutorial, estoy usando Oracle Linux 6.4 en la versión de 32 bits. Tenga en cuenta que aunque la configuración se realiza en Oracle Linux, los pasos también son aplicables a las distribuciones CentOS y Red Hat OS y a sistemas de 64 bits también. El resultado final de nuestra configuración de ejemplo mostrará que la conexión realizada a nuestro servidor de agrupación permanecerá conectada incluso si he desactivado 1 de las redes ethernet. En este ejemplo, mostraré cómo aplicar la agrupación de red utilizando el modo 1 que es la política de active-backup.

2. Fase de Instalación

Para este proceso, no se necesita instalación. Una instalación predeterminada de Linux de un servidor incluye todos los paquetes requeridos para una configuración de agrupación de red.

3. Fase de Configuración

Antes de comenzar la configuración, primero necesitamos asegurarnos de que tenemos al menos 2 interfaces ethernet configuradas en nuestro servidor. Para verificar esto, vaya a la carpeta de configuración de red y liste las interfaces ethernet disponibles. A continuación se muestran los pasos:

cd /etc/sysconfig/network-scripts/  
ls *ifcfg*eth*

El resultado es:

ifcfg-eth0 ifcfg-eth1 

Observe que actualmente tenemos 2 interfaces ethernet configuradas en nuestro servidor que son ETH0 y ETH1.

Ahora configuremos una interfaz de agrupación llamada BOND0. Esta interfaz será una interfaz ethernet virtual que contiene las interfaces ethernet físicas de ETH0 y ETH1. A continuación se muestran los pasos:

vi ifcfg-bond0

DEVICE=bond0  
ONBOOT=yes  
MASTER=yes  
IPADDR=172.20.43.110  
NETMASK=255.255.255.0  
GATEWAY=172.20.43.1  
BONDING_OPTS="mode=1 miimon=100"  
TYPE=Ethernet 

Luego ejecute:

ls *ifcfg*bon*

El resultado es:

ifcfg-bond0 

Eso es todo. Tenga en cuenta que dentro de la interfaz BOND0, he incluido una dirección IP. Esta dirección IP será la única dirección IP conectada a nuestro servidor. Para continuar con el proceso, necesitamos modificar la interfaz ethernet física relacionada con la interfaz BOND0. A continuación se muestran los pasos:

vi ifcfg-eth0

DEVICE=eth0  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 

vi ifcfg-eth1

DEVICE=eth1  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 

Listo. Hemos realizado la modificación de las interfaces ETH0 y ETH1. Observe que hemos eliminado la dirección IP dentro de ambas interfaces y agregado MASTER = bond0. Esto es necesario para validar que ambas interfaces serán interfaces virtuales dedicadas a la interfaz ethernet BOND0.

Para continuar con la configuración. Vamos a crear un archivo de configuración de agrupación llamado bonding.conf en /etc/modprobe.d. A continuación se muestran los pasos:

vi /etc/modprobe.d/bonding.conf

alias bond0 bonding  
options bond0 mode=1 miimon=100 

modprobe bonding 

Según la configuración anterior, hemos configurado un módulo de agrupación utilizando la interfaz BOND0. También asignamos la configuración de agrupación para usar el modo = 1 que es la política de active-backup. La opción miimon = 100 representa la frecuencia de monitoreo para que nuestro servidor de agrupación monitoree el estado de la interfaz en milisegundos. Como se describió anteriormente, este modo proporcionará características de tolerancia a fallos en la configuración de red del servidor.

Como todo está configurado, reiniciemos el servicio de red para cargar la nueva configuración. A continuación se muestran los pasos:

service network restart

Apagando la interfaz eth0: [ OK ]  
Apagando la interfaz eth1: [ OK ]  
Apagando la interfaz de loopback: [ OK ]  
Activando la interfaz de loopback: [ OK ]  
Activando la interfaz bond0: [ OK ] 

Excelente, ahora hemos cargado la nueva configuración que hicimos anteriormente. Notará que la nueva interfaz llamada BOND0 se mostrará en la lista de red. También notará que no hay dirección IP asignada a las interfaces ETH0 y ETH1, solo la interfaz BOND0 muestra la IP.

ifconfig

bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
inet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0  
inet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link  
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1  
RX packets:1723 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:147913 (144.4 KiB) TX bytes:108429 (105.8 KiB) 

eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB) 

eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:632 errors:0 dropped:0 overruns:0 frame:0  
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 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:16436 Metric:1  
RX packets:208 errors:0 dropped:0 overruns:0 frame:0  
TX packets:208 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB) 

También puede verificar el estado de la agrupación a través de este comando:

cat /proc/net/bonding/bond0

Controlador de Agrupación de Canal Ethernet: v3.6.0 (26 de septiembre de 2009) 

Modo de Agrupación: tolerancia a fallos (active-backup)  
Esclavo Primario: Ninguno  
Esclavo Activo Actualmente: eth0  
Estado MII: activo  
Intervalo de Sondeo MII (ms): 100  
Retraso de Activación (ms): 0  
Retraso de Desactivación (ms): 0 

Interfaz Esclava: eth0  
Estado MII: activo  
Velocidad: 1000 Mbps  
Dúplex: completo  
Conteo de Fallos de Enlace: 0  
Dirección HW permanente: 08:00:27:61:e4:88  
ID de cola de Esclavo: 0 

Interfaz Esclava: eth1  
Estado MII: activo  
Velocidad: 1000 Mbps  
Dúplex: completo  
Conteo de Fallos de Enlace: 0  
Dirección HW permanente: 08:00:27:c8:46:40  
ID de cola de Esclavo: 0 

Observe que hemos convertido con éxito las interfaces ETH0 y ETH1 en una configuración de agrupación utilizando el modo active-backup. También se indica que el servidor está utilizando la interfaz ETH0, ETH1 será la interfaz de respaldo.

4. Fase de Pruebas

Ahora que todo está configurado como se esperaba. Hagamos una prueba simple para asegurarnos de que la configuración que hicimos es correcta. Para esta prueba, iniciaremos sesión en un nuevo servidor (o escritorio Linux) y comenzaremos a hacer ping a nuestro servidor de agrupación para ver si hay alguna conexión intermitente durante la prueba. A continuación se muestran los pasos:

login as: root  
[email protected]'s password:  
Último inicio de sesión: Mié Sep 14 12:50:15 2016 desde 172.20.43.80

ping 172.20.43.110

PING 172.20.43.110 (172.20.43.110) 56(84) bytes de datos.  
64 bytes desde 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms  
64 bytes desde 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms  
64 bytes desde 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms  
64 bytes desde 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms  
64 bytes desde 172.20.43.110: icmp_seq=5 ttl=64 time=0.554 ms  
64 bytes desde 172.20.43.110: icmp_seq=6 ttl=64 time=0.443 ms  
64 bytes desde 172.20.43.110: icmp_seq=7 ttl=64 time=0.663 ms  
64 bytes desde 172.20.43.110: icmp_seq=8 ttl=64 time=0.961 ms  
64 bytes desde 172.20.43.110: icmp_seq=9 ttl=64 time=0.461 ms  
64 bytes desde 172.20.43.110: icmp_seq=10 ttl=64 time=0.544 ms  
64 bytes desde 172.20.43.110: icmp_seq=11 ttl=64 time=0.412 ms  
64 bytes desde 172.20.43.110: icmp_seq=12 ttl=64 time=0.464 ms  
64 bytes desde 172.20.43.110: icmp_seq=13 ttl=64 time=0.432 ms 

Durante este tiempo, volvamos a nuestro servidor de agrupación y apaguemos la interfaz ethernet ETH0. A continuación se muestran los pasos:

ifconfig eth0

eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB) 

ifdown eth0 

Ahora hemos apagado los servicios para la interfaz de red ETH0. Verifiquemos el estado de la agrupación. A continuación se muestran los pasos:

cat /proc/net/bonding/bond0

Controlador de Agrupación de Canal Ethernet: v3.6.0 (26 de septiembre de 2009) 

Modo de Agrupación: tolerancia a fallos (active-backup)  
Esclavo Primario: Ninguno  
Esclavo Activo Actualmente: eth1  
Estado MII: activo  
Intervalo de Sondeo MII (ms): 100  
Retraso de Activación (ms): 0  
Retraso de Desactivación (ms): 0 

Interfaz Esclava: eth1  
Estado MII: activo  
Velocidad: 1000 Mbps  
Dúplex: completo  
Conteo de Fallos de Enlace: 0  
Dirección HW permanente: 08:00:27:c8:46:40  
ID de cola de Esclavo: 0 

Notará que ahora la interfaz ETH0 ya no existe en el estado de agrupación. Durante este tiempo, volvamos al servidor de prueba anterior y verifiquemos el ping continuo a nuestro servidor de agrupación.

64 bytes desde 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms  
64 bytes desde 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms  
64 bytes desde 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms  
64 bytes desde 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms  
64 bytes desde 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms  
64 bytes desde 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms  
64 bytes desde 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms  
64 bytes desde 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms  
64 bytes desde 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms  
64 bytes desde 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms  
64 bytes desde 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms  
64 bytes desde 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms  
64 bytes desde 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms 

¡Genial! Ahora verá que, aunque hemos apagado la interfaz ETH0, todavía podemos hacer ping y acceder a nuestro servidor de agrupación. Ahora hagamos 1 prueba más. Encienda de nuevo la interfaz ETH0 y apague la interfaz ETH1.

ifup eth0  
cat /proc/net/bonding/bond0

Controlador de Agrupación de Canal Ethernet: v3.6.0 (26 de septiembre de 2009) 

Modo de Agrupación: tolerancia a fallos (active-backup)  
Esclavo Primario: Ninguno  
Esclavo Activo Actualmente: eth1  
Estado MII: activo  
Intervalo de Sondeo MII (ms): 100  
Retraso de Activación (ms): 0  
Retraso de Desactivación (ms): 0 

Interfaz Esclava: eth1  
Estado MII: activo  
Velocidad: 1000 Mbps  
Dúplex: completo  
Conteo de Fallos de Enlace: 0  
Dirección HW permanente: 08:00:27:c8:46:40  
ID de cola de Esclavo: 0 

Interfaz Esclava: eth0  
Estado MII: activo  
Velocidad: 1000 Mbps  
Dúplex: completo  
Conteo de Fallos de Enlace: 0  
Dirección HW permanente: 08:00:27:61:e4:88  
ID de cola de Esclavo: 0 

Como la interfaz ETH0 ya estaba activa, apaguemos la interfaz ETH1.

ifdown eth1

cat /proc/net/bonding/bond0

Controlador de Agrupación de Canal Ethernet: v3.6.0 (26 de septiembre de 2009) 

Modo de Agrupación: tolerancia a fallos (active-backup)  
Esclavo Primario: Ninguno  
Esclavo Activo Actualmente: eth0  
Estado MII: activo  
Intervalo de Sondeo MII (ms): 100  
Retraso de Activación (ms): 0  
Retraso de Desactivación (ms): 0 

Interfaz Esclava: eth0  
Estado MII: activo  
Velocidad: 1000 Mbps  
Dúplex: completo  
Conteo de Fallos de Enlace: 0  
Dirección HW permanente: 08:00:27:61:e4:88  
ID de cola de Esclavo: 0 

Ahora volvamos al servidor de prueba y verifiquemos qué sucede con el ping continuo realizado a nuestro servidor de agrupación.

64 bytes desde 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms  
64 bytes desde 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms  
64 bytes desde 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms  
64 bytes desde 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms  
64 bytes desde 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms  
64 bytes desde 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms  
64 bytes desde 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms  
64 bytes desde 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms  
64 bytes desde 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms  
64 bytes desde 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms  
64 bytes desde 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms  

¡Buen trabajo! Hemos configurado con éxito y demostrado que nuestro servidor de agrupación logra manejar el escenario de recuperación ante desastres en una condición de conmutación por error de red.