aVCS

A10 usa el concepto aVCS (Virtual Chassis System) para la configuración y administración centralizada de los equipos. Se combina con VRRP-A y nos habilita para montar un cluster de hasta 8 equipos. Estos deben ser iguales en modelo, hardware y versión de ACOS.

Entre los beneficios de aVCS es que nos permite administrar todos los equipos a través de una única dirección ip. Dependiendo de la capa OSI que afecta, los cambios afectan de una manera u otra:

• De capa 4 a 7 - los cambios se propagan automáticamente

• De capa 2 a 3 - los cambios se pueden ejecutar usando un ID específico del dispositivo.

Cuando añadimos un nuevo dispositivo al aVCS, este se añade automáticamente. El vMaster comprueba y actualiza el nuevo vBlade si es necesario. El vMaster le manda la configuración.

• vMaster:  toda la configuración se hace aquí. Se accede a través de la dirección ip flotante, vcs ip-floating, de la que es propietaria el vMaster incluso cuando hay un fail-over.

• vBlade: El nivel "privilege" para configurar está deshabilitado. Un vBlade puede tomar el rol de vMaster si se pierde la conectividad del actual o forzándolo por el administrador.

Dentro del Virtual Chassis podemos distinguir:

• Device ID: identificador único dentro de aVCS
• Chassis ID: identificador único para el Dominio de Broadcast. Se define como Set-ID.

Un identificador único para cada dispositivo dentro del aVCS:

• A10(config)#vrrp-a common
• A10(config-common)#device-id X

Un identificador único de chassis, del aVCS:

•  A10(config)#vrrp-a common
•  A10(config-common)#set-id X

En el Prompt se muestra el chassis y el id del dispositivo:

• A10-vMaster[1/1](config)#
• A10-vBlade[1/2](config)#

aVCS usa "Link Local UDP Multicast" para los mensajes de control (hearbeat). Estos son enviados a todos los vBlades a través de la dirección 224.0.0.210 y el puerto UDP 41217. Sin embargo, cuando el vMaster transfiere datos a los vBlades (configuración, status, imágenes) los envía en TCP Unicast. Las interfaces seleccionadas para estar en un aVCS deben pertenecer a mismo dominio de broadcast de capa 2.



El proceso de elección de vMaster sigue los siguientes pasos:

1. Se inician los equipos
2. El que tenga la prioridad más alta es elegido (va de 0 a 255)
3. Si todos tienen la prioridad igual, el dispositivo con el device ID más bajo es el elegido

Para la configuración de un aVCS los pasos son (con el gráfico de arriba de 2 equipos):

Primero configuramos el Device 1:

vrrp-a common 
  devide-id 1
  set-id 1
vcs enable
vcs floating-ip /
vcs device 1
   interface X
   interface X
   priority 250
   enable
vcs reload

Nota: importante configurar más de una interface para tener redundancia

Cuando añadimos un equipo nuevo a un aVCS el proceso es el siguiente:

Cuando reemplazamos un equipo del aVCS el proceso cambia un poco:

Después configuramos el Device 2:

vrrp-a common 
  devide-id 2
  set-id 1
vcs enable
vcs device 2
   interface X
   interface X
   priority 200
   enable
vcs reload


Para que los cambios se hagan efectivos, tendremos que introducir el comando: vcs reload


Una vez está formado el aVCS, todo se administra y se configura desde el vMaster, incluso las configuraciones particulares de los vBlade.


Recordad que el Prompt que se ve una vez formado el VCS muestra el rol del equipo:

• A10-vMaster[1/1]#
• A10-vBlade[1/2]#

Cunado añadimos


Podemos hacer temporalmente a otro equipo como vMaster. Esto hace que en el equipo donde lo introducimos tome el rol de vMaster. Esto no cambia la prioridad configurada en el equipo. La prioridad que le configuramos temporalmente no tiene por qué ser más alta que la del vMaster: tomará el rol de todas maneras. Si configuramos más de un equipo con este comando, se elegirá entonces al que tenga esta prioridad temporal más alta. Si hay empate, entonces se elige al que tenga el ID más bajo.

• A10-vBlade#vcs vmaster-take-over X -  la X es la prioridad temporal que le configuramos<1-255>

Un comando útil es "vcs vMaster-maintenance segundos ", que usamos cuando queremos hacer cambios en el vMaster y no queremos que se produzca un "failover" hacia el vBlade. Durante los segundos que le configuremos ( de 0 a 3600) no se hará un fail-over del master.


Si tenemos configurado el aVCS junto con VRRP, podemos hacer que el vMaster del aVCS que es el equipo "active" del VRRP, se cambie a un vBlade en "standby" si el VRRP cambia:

• A10-vMaster(config)#vcs device 1
• A10-vMaster(config:1-device:1)#affinity-vrrp-a-vrid

A la hora de hacer un "upgrade" a los equipos, A10 recomienda usar lo que ellos llaman como Straggered Upgrade" (escalonado). De esta manera el servicio se interrumpe lo mínimo posible. Esto lo hacemos desde el vMaster:

• A10-vMaster(config)#write memory all-patitions
• A10-vMaster(config)#upgrade hd pri use-mgmt-port straggered-upgrade-mode device X (nos pide reiniciar)
  

Comprobamos que el vBlade está actualizado y repetimos con los otros vBlades. El último en actualizar será el vMaster.


Comandos para verificar:

show vcs summary
show vcs statistics
show run | sec vcs
show bootimage
show version