Foro en Español

Reply
Moderator

[Tutorial] Cluster de controladores con AOS8

Hola

Tal como comenté en el post sobre la "Nueva Arquitectora ArubaOS8", vamos a ir desgranando las diferentes novedades que nos ha traído este cambio tan radical;Y como bien indica el título, en este post nos centraremos en el Clustering.

 

¿En qué consiste esto del cluster de controladores?

 

Las redes de tipo campus siempre han sido un reto para la arquitectura con controlador por varias razones:
- Aprovechamiento de la infraestructura. Idealmente querría poder hacer redundancia N+1 y sacarle el máximo partido a mi red, pero eso complicaba bastante el diseño (o directamente no se podía hacer) con soluciones anteriores.
- Roaming entre controladores. Cuando pasamos de un controlador a otro tenemos que asegurarnos que el usuario no notará nada.
- Failover entre controladores. Si falla un controller, una vez más, el usuario no debe notar nada.
- Actualizaciones. En redes con controlador, actualizar estos siempre ha sido un problema, ya que de un plumazo tengo que reiniciar toda la red... En una oficina puede que no sea demasiado problemático, pero en un hospital o una fábrica que funcione 24x7 encontrar una ventana de corte puede ser un problema.

 

Pues bien, precisamente gracias a lo que comentabamos en el post de arquitectura (aquello de separar el plano de control del plano de datos) ArubaOS8 nos permite resolver todos estos problemas de una manera muy sencilla, agrupando los controladores en un cluster de hasta 12 miembros.

Balanceo de APs y Clientes:
A diferencia de lo que ocurría en versiones anteriores, ahora los AP establecen túneles de control y datos independientes. Un AP, por tanto, estará gestionado a nivel RF por uno de los controladores, y tendrá sus clientes repartidos entre los controller del cluster:
AP-Client LoadBalancing.png
Esto no sólo aplica a los clientes, sino a los AP. En el momento en el que un AP se asocie a uno de los controladores del cluster, el MM decidirá cuál de los controllers debe tomar control sobre este AP. Y hará esto, como es lógico, teniendo en cuenta la carga (y capacidad) de cada uno de los controllers. No será extraño, por tanto, ver algo así en nuestra red:

Client-Load Balancing.png


Roaming entre controladores:
Este es un problema histórico de las arquitecturas tradicionales, tanto las que utilizan controlador como en las que no utilizan controlador.

El roaming entre controladores, o el roaming de nivel 3 se solía resolver tunelando el tráfico desde el controller (o cluster, o colmena) de destino al de origen, así nos aseguramos que el usuario no nota nada raro. El problema es que esto da lugar a tráfico subóptimo, a sobrecargar el AP de la entrada, etc.

Pues ya nunca más :) Con el cluster de controladores, cuando un cliente se mueve de un AP gestionado por un controlador a otro AP gestionado por otro controlador el AP de destino continuará enviando el tráfico hacia el mismo controlador de origen.
Inter-Controller Roaming.pngMucho más sencillo, ¿verdad? :)

Failover entre controladores
Otro problema de los despliegues tradicionales había sido el failover cuando perdíamos un controlador, sobre todo en nuestro caso, en el que el controlador es también un firewall stateful. Una vez más, separar el plano de control del de datos nos da muchas más posibilidades.

 

Los AP (y esto es algo que ya veníamos haciendo desde hace tiempo) siempre tendrán sesiones de control activo/standby con dos controladores:

HitlessFailover.png


La novedad viene ahora porque estas sesiones activo/backup también se mantendrán para el tráfico de datos. Por lo tanto, las sesiones de un usuario (a nivel de AAA y cifrado) conectado al un controller del cluster siempre estarán sincronizadas con otro controlador más. Pero no sólo eso. No olvidemos que nuestro controlador es un firewall stateful, por tanto, las sesiones más sensibles tendrán que ser sincronizadas (ssh, FTP, SIP, etc). Si queremos "forzar" a que un flujo en concreto sea sicronizado (al margen de los que ya lo son por defecto), basta con que lo marquemos como "media"o que le cambiemos el valor de QoS en nuestra política de roles .

 

Actualizaciones en caliente
Esta es la novedad que más me gusta de todas. Poder actualizar la red a las 12 del mediodía y que los usuarios no noten nada :D

 

Nuestro "director de orquesta" (el MM) ve tanto la componente RF como los usuarios conectados, etc. Así que cuando usamos la opción de "cluster upgrade" lo que hará el MM será más o menos lo siguiente:

 

Primero, libera un controller de APs y lo actualiza. A partir de ahí, y teniendo en cuenta clientes conectados, RF, etc, va moviendo los AP poco a poco a este controlador. Cuando un AP se mueve al controller nuevo tendrá que reiniciarse, pero al hacerse poquito a poco (y viendo los vecinos RF de cada AP) los usuarios lo más que podrán notar será un nivel de señal algo más bajo (porque su AP se esté reiniciando). Finalmente, reiniciará el controlador (o controladores) de origen. Más información en este enlace.

Para que os hagáis una idea de lo que confiamos en nuestra tecnología, en el último Atmosphere hicieron una actualización del cluster que prestaba servicio a la sala plenaria durante la sesión de Partha (nuestro CTO). Y puedo aseguraros que no se notó nada :)


Bueno, y ahora a lo importante... ¿Cómo se configura?
Con la configuración jerárquica de ArubaOS8, lo normal será que tengamos ambos controladores dentro de la misma carpeta. En esta carpeta configuraremos, por tanto, lo siguiente:

cd /md/ARUBAPOC -- Con esto nos metemos en nuestra carpeta
configure terminal
lc-cluster group-profile ARUBAPOC
controller 172.16.0.252
controller 172.16.0.253
redundancy
(opcional) active-ap-lb

Configuración específica de cada uno de los controladores

cd /md/cluster/00:11:22:33:44:55
lc-cluster group-membership ARUBAPOC
(opcional) lc-cluster exclude-vlan 100 
write memory

cd /md/cluster/11:22:33:44:55:66
lc-cluster group-membership ARUBAPOC
(opcional) lc-cluster exclude-vlan 100 
write memory


Como habréis visto existe la posibilidad de excluir VLANs del cluster. Esto es así porque en el momento en que metemos un controller en el cluster, este envía "keepalives" por todas las VLANs a todos los controllers del cluster. Lo hace para asegurarse de que vamos a poder hacer cosas como el balanceo de clientes por todas las VLANs del cluster sin "romper" nada. Por tanto, si queremos excluir alguna VLAN (porque no exista en los otros controller, por ejemplo) lo haremos de esta manera.

 

Y esto es todo! Ahora animaos a probarlo :)

Un saludo!

Samuel Pérez
ACMP, ACCP, ACDX#100

---

If I answerd your question, please click on "Accept as Solution".
If you find this post useful, give me kudos for it ;)
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: