Foro en Español

Reply
Highlighted
Moderator
Posts: 948
Registered: ‎07-29-2010

Nueva arquitectura ArubaOS8

[ Edited ]

Como muchos de vosotros ya sabréis, hace unos meses lanzamos ArubaOS 8, y tras unos meses de rodaje (se trata de un cambio muy significativo), ya no quedan excusas para no meterse a tope con ello.

 

Con este post me gustaría empezar una cadena dedicada a todas las novedades que hemos incorporando a raíz de este cambio, pero antes de meternos en los detalle, vayamos a lo fundamental, la nueva arquitectura.

 

El cambio más radical que trae esta versión es la posibilidad de separar el plano de control  del plano de datos (ojo, que podemos seguir teniendo controladoras en modo "standalone" o HA). Esta separación entre plano de control y de datos implica utilizar un servicio adicional, el "Mobility Master". A diferencia de los "Master Controller" en AOS6.x, se trata de un appliance (físico o virtual) basado en arquitectura x86, lo cual permite mucha mayor memoria y capacidad de proceso que la arquitectura de los controladores tradicionales, más orientada a mover tráfico. Esta arquitectura, quedaría por tanto, como se describe en la imagen a continuación.

 

Arch-AOS8.png

 

Por un lado tendremos el "Mobility Master" (o pareja de MMs) y por otro lado los "Managed Nodes" (cualquier controller, ya sea HW o VM). Estos "managed nodes", además, podrán estar en una misma sede, o repartidos por todas las delegaciones de mi empresa. Por supuesto, también podrán conectarse con el MM a través de Internet, tal como hacíamos en el modo "SmartBranch" en AOS6.5, permitiendo también ofrecer servicios de tipo SD-WAN (escribiré más sobre esto en un post dedicado).

 

¿Y a qué viene este cambio? La arquitectura tradicional, con el plano de control y de datos en el mismo equipo, ha funcionado bien hasta ahora, pero empezaba a limitarnos un poco. 

Por poner un ejemplo, la gestión de recursos radio se hacía tomando en cuenta los valores medidos en cada instante de tiempo, ya que los controller no tienen un disco duro para almacenar toda la información a de RF recibida a lo largo de un día, como sí puede hacer el MM (pondré más info sobre esta funcionalidad, Airmatch, más adelante). Y no sólo eso, cada vez que queríamos añadir cualquier funcionalidad al código, o aplicar cualquier parche, había que actualizar el controlador, lo que implica tener que buscar ventana de corte, etc. A partir de ahora, si ingeniería saca una mejora sobre, por ejemplo, la integración con Skype4Business, bastará con actualizar el módulo de UCC del MM para ponernosal día. :) Se trata, por tanto, de un plano de control modular que podremos actualizar sin afectar al plano de datos.

 

¿Y cómo se gestiona esto? Esta es la parte que más me gusta :) En el momento en que introducimos un MM en nuestra arquitectura, toda la configuración de los nodos gestionados pasa a hacerse a través del MM, que además nos permitirá hacerla de forma jerárquica. Es decir, si tengo varios controladores en una misma sede, puedo aplicarles configuraciones de grupo (por ejemplo, los SSID que van a radiarse) sin que por ello pierda la capacidad de tener configuraciones específicas para cada uno de los controladores.

hierarchy.png

 

 Y esto es sólo el principio, como iremos contando en los siguientes posts de esta serie, ArubaOS8 trae funcionalidades súper útiles como el "clustering", el mencionado "Airmatch", "Multizone" o las actualizaciones en caliente. Así que estad atentos :)

 

Enlaces relacionados:

Cluster de controladores.

 

 

 

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
Showing results for 
Search instead for 
Did you mean: