Networking: Alta Disponibilidad a nivel de enlace físico de servidor a red

Muy buenas,

Un poco mas de Networking para animar el día 😉 Esta vez un poco de HA y redes, pero enfocado únicamente en el detalle de la HA a nivel del enlace físico servidor – red, sin levantar la cabeza a otras perspectivas mas globales.

Es un tema recurrente, con el que nos solemos encontrar mucho, y básicamente, si tenemos un servidor conectado con un único cable de red a un switch, tenemos las siguientes casuísticas:

post_lacp_globalview

 

Es decir, el fallo de cualquiera de las partes del esquema de conexión implica un fallo total del sistema.

Llegamos por tanto al punto de de querer redundar «algo» este esquema, sin entrar en clustering con dos servidores ni complicaciones mayores, centrándonos en esta parte concreta, nos salen un par de opciones que comentamos a continuación:

Bucle / Bridge (STP)

Esta es quizás la estrategia mas simple de todas (y menos potente, claro está): Ponemos doble nic al servidor y lo enlazamos, o bien doblemente al mismo switch o a dos switches diferentes que cierren el círculo:

post_lcacp_stp_view (1)

Para ilustrar esto, primero lo podemos simular muyyy rápidamente con GNS3, partiendo de este mini esquema (con 3x 28XX):

3routers

Tras configurar STP correctamente, si nos conectamos a R2 y vemos el status STP:

R2#show spanning-tree summary 
Root bridge for: none.
PortFast BPDU Guard is disabled
UplinkFast is disabled
BackboneFast is disabled

Name                 Blocking Listening Learning Forwarding STP Active
-------------------- -------- --------- -------- ---------- ----------
VLAN1                1        0         0        2          3         
-------------------- -------- --------- -------- ---------- ----------
              1 VLAN 1        0         0        2          3         
R2#

De la misma forma, desde el punto de vista del servidor, lo podemos simular perfectamente tb con GNS3, dado que soporta integración nativa de máquinas virtuales QEMU/VirtualBox, así que hemos montado este otro mini esquema:

gns3_debian_sw

En este caso, dado que el switch soporta STP, hemos optado por no habilitarlo en la VM Debian, y el propio IOS nos muestra como uno de los puertos está bloqueado:

 Port 42 (FastEthernet1/1) of VLAN1 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.42.
   Designated root has priority 32768, address c401.148b.0000
   Designated bridge has priority 32768, address c401.148b.0000
   Designated port id is 128.41, designated path cost 0
   Timers: message age 2, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 101, received 129

Para probar nuestra configuración, quitamos de la máquina virtual el interfaz que estaba en estado forwarding (f1/0 <> eth3) del bridge:

brctl delif br0 eth3
ifconfig eth3 down

Y observamos que en el switch ha cambiado la topología:

  Number of topology changes 3 last change occurred 00:01:45 ago
          from FastEthernet1/1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15 
  Timers: hello 1, topology change 0, notification 0, aging 300

y finalmente, se ven ambos puertos en forwarding:

 Port 41 (FastEthernet1/0) of VLAN1 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.41.
   Designated root has priority 32768, address c401.148b.0000
   Designated bridge has priority 32768, address c401.148b.0000
   Designated port id is 128.41, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 440, received 1

 Port 42 (FastEthernet1/1) of VLAN1 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.42.
   Designated root has priority 32768, address c401.148b.0000
   Designated bridge has priority 32768, address c401.148b.0000
   Designated port id is 128.42, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 168, received 263

y lo que es mas importante, el servidor sigue estando accesible 😉 (que al fin y al cabo, era el objetivo de todo esto):

ESW1#ping 192.168.1.1 repeat 60 timeout 1 

Type escape sequence to abort.
Sending 60, 100-byte ICMP Echos to 192.168.1.1, timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (60/60), round-trip min/avg/max = 36/54/92 ms

En este mini ejemplo hemos optado por no desplegar STP en el lado del servidor, pero con las bridge-utils de toda la vida es perfectamente posible

Cross Stack – LACP

Esta es la configuración que mas nos gusta y la que realizamos casi siempre ultimamente, siemrpe y cuando tengamos un stack en-frente (no siempre existe esa suerte ;)).

El kernel Linux soporta desde hace muchos años (initial release en el año 2000) varios tipos de agregación y lo que se conoce como bonding, o en términos de Cisco como Etherchannel , soportando varias estrategias de reparto de la carga con mas o menos tolerancia a fallos y aumento global o no de ancho de banda. Existe información detallada en la misma documentación oficial del kernel.

El mas común, y sobre todo, el mas standard es LACP (803.1ad), soportado por prácticamente todos los switches gestionables que no sean los más básicos, y si ya hablamos de stack’s reales, hasta donde hemos visto todos lo soportan. La ventaja de hacerlo cross-stack, es decir, 1 cable al menos a cada miembro del stack, es que tenemos tolerancia completa a fallo de switch, o incluso si tendríamos que actualizar el firmware, se podría hacer con 0 downtime 😉

Sirva el siguiente esquema de situaciones y supervivencia, partiendo del comentado anteriormente:
post_lacp_stackview

En este caso, no lo podemos simular con GNS3, así que presentamos una configuración hecha en nuestro lab con 2x Cisco 3750 Stackados.

En lo que respecta el port-channel en el switch Cisco 3750:

interface Port-channel1
 description LACP_TESTING
 switchport trunk encapsulation dot1q
 switchport mode trunk

Lo, mismo pero para los interfaces:

interface GigabitEthernet1/0/1
 description LACPTEST_NIC1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-protocol lacp
 channel-group 1 mode active

interface GigabitEthernet3/0/1
 description LACPTEST_NIC2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-protocol lacp
 channel-group 1 mode active

(como se ve, se opta por ir en trunk dado que luego probablemente pasemos VM’s de diversas redes o situaciones similares)

Desde el punto de vista del servidor GNU/Linux, la configuración en /etc/network/interfaces para el caso de una Debian sería tal que:

iface eth2 inet manual
iface eth3 inet manual
auto bond0
iface bond0 inet static
	address  192.168.1.11
	netmask  255.255.255.0
	network  192.168.1.0
    gateway  192.168.1.1
	slaves eth2 eth3
	bond_mode 802.3ad
	bond_miimon 100
	bond_downdelay 200
	bond_updelay 200

De este ejemplo cabe destacar de la configuración:

  • slaves:  Para indicar que interfaces están agrupados.
  • bond_mode: El tipo de agrupación, en la docu del kernel aparecen todas, 802.3ad es el standard LACP.
  • bond_miimon: Es la frecuencia en ms para monitorizar el estado del enlace físico (MII).
  • bond_down/up delay: Se utiliza para retrasar la agrupación o desagrupación cuando se cae o levanta el interface a nivel físico, por si acaso está en flapping.

Para comprobar el status de la agregación lo podemos y debemos hacer desde el punto de vista del SO GNU/Linux:

irontest:~# cat /proc/net/bonding/bond0 
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
	Aggregator ID: 1
	Number of ports: 2
	Actor Key: 17
	Partner Key: 1000
	Partner Mac Address: 00:0d:bd:9a:8e:c1

Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: b4:b5:2f:61:c1:64
Aggregator ID: 1
Slave queue ID: 0

Slave Interface: eth3
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: b4:b5:2f:61:c1:66
Aggregator ID: 1
Slave queue ID: 0

y desde el punto de vista del switch stack:

ironcoretest#show lacp internal 
Flags:  S - Device is requesting Slow LACPDUs 
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode     

Channel group 1
                            LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Gi1/0/1  SA      bndl      32768         0x1       0x1     0x116       0x3D  
Gi3/0/1  SA      bndl      32768         0x1       0x1     0x316       0x3D  

 

Y esto es todo por hoy, como resumen, siempre que se pueda: Plantearse lo importante y a la vez sencillo que es darle un mínimo de HA a la parte más básica de nuestra arquitectura 🙂



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...
Sobre Gorka Gorrotxategi

CTO en Irontec, en el frente técnico desde un par de lustros ya, para todo lo que tenga que ver con Networking, VoIP y Sistemas, en ese orden :D) Desde @zetagor escribo algo, pero poco verbose la verdad

1 Comentario

¿Por qué no comentas tú también?


  • Hola Gorka

    Gran artículo como siempre. En los últimos tiempos me ha tocado pegarme con todo esto, y la verdad es que te libra de muchos quebraderos de cabeza. Y me ha servido para conocer el GNS3, que parece que puede molar mucho…

    Como comentario, destacar que cuando se implementa esto creo que es fundamental combinarlo con algún tipo de sistema de logging/alarmas (kiwi, nagios, etc.), de modo que si hay fallo de alguno de los enlaces te enteres y puedas resolverlo mientras el sistema sigue online. La mayor parte de los switches ya permiten snmp o rsyslog, así que no es mucho problema. Más que nada porque no mola tener redundancia si no te enteras de cuando hay un fallo (sólo estás retrasando el desastre… 😉 ).

    Sólo una mini corrección. En la configuración del fichero interfaces de debian, donde pones network creo que tendría que poner gateway. Más que nada por si alguno lo va a probar y hace copy-paste, que no se vuelva loco 😀

    Un saludo

    Berto

    Alberto Arcanos Hace 6 años Responde


    • Alberto!

      Muy buenas ! Gracias por el feedback y la corrección, lo acabamos de re-editar.

      Thanksss .)

      Gorka Gorrotxategi Hace 6 años Responde


  • He comprado una cámara IP de la marca Foscam que permite enviar los videos e imágenes que capte en situación de alarma a un servidor FTP. La cámara trae su propio software de envío por lo que no requiere intervención del usuario y lo único que pide es la dirección ftp a la que se tiene que conectar el usuario, contraseña y si actúa en modo activo o pasivo y el puerto que utiliza. Pues bien algo que parece tan tonto y simple resulta que no veo se pueda hacer con las habituales «nubes» como dropbox, onedrive, google drive etc.Y la verdad es que no entiendo por qué si el propósito de tales servicios es que te sirvan de almacenamiento y sin embargo en algo tan interesante como la videogilancia de tu casa cuando estás ausente no pueda utilizarse de manera automática. Disculpad si se puede hacer y yo no he sabido verlo pues, repito, que algo tan simple no vea la forma de hacerlo.

    Juan Antonio Hace 5 años Responde


Queremos tu opinión :)