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:
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:
Para ilustrar esto, primero lo podemos simular muyyy rápidamente con GNS3, partiendo de este mini esquema (con 3x 28XX):
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:
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:
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 🙂
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 10 años
Alberto!
Muy buenas ! Gracias por el feedback y la corrección, lo acabamos de re-editar.
Thanksss .)
Gorka Gorrotxategi Hace 10 años
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 9 años
Queremos tu opinión :)