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:

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:

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

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

y finalmente, se ven ambos puertos en forwarding:

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

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:

Lo, mismo pero para los interfaces:

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

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:

y desde el punto de vista del switch stack:

 

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 3 años Responde


    • Alberto!

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

      Thanksss .)

      Gorka Gorrotxategi Hace 3 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 2 años Responde


Queremos tu opinión :)