Upgrade NSX Advanced Load Balancer

Buenas chic@s! Hoy vamos a ver la forma de realizar un upgrade de NSX Advanced Load Balancer, o AVI como me gusta llamarlo a mi. El método de actualización con el paso las versiones se ha convertido en algo sencillo, y bastante flexible.

Antes de seguir te dejo por aquí, todos los post que voy escribiendo sobre AVI.

Introducción

Una de las mejores cosas que tiene AVI y mas desde la versión 18.2.6 es la flexibilidad que nos proporciona a la hora de actualizarlo. Por ello durante los siguientes párrafos solo vamos hacer mención a como actualizar AVI a partir de la versión 18.26 en adelante. Vamos a ver de forma resumida todas las cosas que tenemos en cuenta para la actualización.

Elementos a tener en cuanta antes de empezar la actualización:

  • Consultar la lista de comprobación de la actualización en la base de conocimientos antes de realizarla.
  • Realizar un backup externo de toda la configuración.
  • Comprobar la capacidad en el clúster de controller.
    • Debemos tener al menos un 30% libre en cada controller.
  • Debemos descargar el archivo de upgrade antes de empezar con la actualización.
  • El proceso de actualización se debe empezar desde el «controller leader».

Software versioning

  • El formato que utiliza para denominar sus versiones es el siguiente: <año>,<major release>,<minor release>.
  • Hay 2 major releases al año, el resto de actualización suele ser consideradas «minor».
  • La pagina para la release notes, la podemos encontrar aquí.

Acerca del upgrade

  • Podemos ver el upgrade desde 3 partes
    • UI: Administration–>System–>Upgrade
    • CLI: Show upgrade status
    • API: https://<controller>/api/cluster/upgrade/status
  • Los archivos de actualización están disponibles mediante el inicio de sesión único (SSO) en el portal de Servicios en la nube utilizando las credenciales de Customer Connect.

Workflow de la actualización del clúster controller

  1. AVI realizar un snapshot localmente de la configuración que esta en ejecución.
  2. Cuando subimos el «upgrade bundle» desde el leader, esta se replica a resto de «controllers»
  3. Se bloquea la configuración.
  4. Se inicia el upgrade del clúster de controller simultáneamente
  5. Una vez actualizados, se reinician.
  6. Después del reinicio, entre ellos intentan contactar para validad el éxito de la actualización.
  7. En caso de que el contacto no se haya restablecido en 5 minutos, se realiza un rollback a la anterior versión.
  8. Una vez restablecida la conexión, los controller reconstruyen el quorum:
    • En este proceso se resincronizan y validan las bases de datos, configuraciones y demás.
    • El tiempo que toma este proceso ronda los 5 minutos.
  9. El clúster controller ha sido actualizado.

Este proceso de actualización del clúster toma entorno de 10 a 20 minutos.

Workflow de la actualización de los SEs group

  • SE upgrades:
    • Se permiten los cambios de configuraciones.
    • SEs se actualizan de uno en uno dentro del SE group.
    • Podemos actualizar los SE group de manera selectiva.
  • Detalles:
    • Si utilizamos «Virtual Services» en activo-activo, el trafico de los clientes se migra sin problemas al resto de SE del grupo.
    • Los controller instalan la nueva imagen de los SE en una nueva partición en el mismo SE.
      • El tiempo de actualización dependerá de donde este alojado el SE y de la velocidad del almacenamiento donde resida.
    • El SE arranca en la nueva partición corriendo la nueva versión de SE.
    • El upgrade de un SE suele ronda de 3 a 5 minutos

Interrupciones del servicio

Las actualizaciones no son disruptivas en los «Virtual Services», siempre y cuando se ejecutan en los siguientes modos:

  • «Elastic active-active»
  • «Elastic N+M», siempre que el virtual service este escalado en mas de un SE o mas.
  • «Legacy active-standby mode»

Las actualizaciones son disruptivas para los «Virtual Services» que funcionan en «Elastic N+M» y solo están corriendo en un SE.

Rollback

Esta quizá es una de esas situación que no quieres oír hablar pero hay que abordarla ya que nunca sabes lo que te puede llegar a pasar.

  • Los «Controllers» retroceden a la versión principal anterior del software.
  • A los «SEs Group» se les puede realizar rollback selectivamente
  • A los «SEs Group se puede realizan rollback a la versión anterior.

Parches VS Upgrades

  • Los parches permiten actualizar pequeñas piezas de AVI en lugar del despliegue completo
    • Controller
    • SEs(especificamente, SEs dentro de un «SE group».
    • UI
  • Los parches son ticamente para curbrir pequeños «bugs» o tapar agujeros de seguridad
  • Los «SEs group» pueden correr diferentes versiones de parches pero tiene que estar en la misma versión.

Actualización

Lo primero que tenemos que hacer es descarga el software, para ello nos vamos a la pagina Customer Connect de VMware, nos vamos a la parte de AVI, ahí nos iremos a la parte de Software y seleccionamos a la versión que queremos ir.

Nos dirigimos a la parte de Upgrade y seleccionamos el archivo bajo el apartado «All Platforms».

Para subir el «bundle», nos logueamos en nuestra consola de AVI y pulsamos sobre » Upload From Computer» y seleccionamos el archivo. Recordad que el archivo se tienen que subir desde el «controller leader».

Aquí vemos el progreso del subida del archivo.

Podemos comprobar como el archivo se ha subido satisfactoriamente.

Ahora nos vamos a la parte de Administration –> Controller –> System Update. Seleccionamos la parte de «System» y pulsamos «Upgrade».

En mi caso voy a deseleccionar el check de «Upgrade All Service Engine Groups», ya que lo haremos mas tarde y de manera controlada. Pulsamos en «Continue».

Si habéis realizado backup, no hay miedo :), pulsamos en «Continue».

Aquí podemos ver el progreso de actualización de los Controller.

Aquí podemos como ya tenemos nuestro cluster controller de AVI en la versión 30.1.1. Ahora es momento de ir a por los SE group.

Seleccionamos en mi caso el SE group » NGINX_GROUP» y pulsamos en «Upgrade».

Elegimos «System» y pulsamos sobre «Continue».

Escogemos la opción de «Suspend» para en caso de que falle la actualización.

Si previamente hemos realizado backup. Pulsamos «Continue».

Se puede observar como en la parte de «In Progress» un Service Group esta actualizándose.

Si pulsaríamos sobre el «checkbox» debajo de «Status» para ver el progreso del SE Group.

Si accedemos por SSH a unos de los controles y lanzamos el comando «show upgrade status», observaremos como uno de los SE (AVI_Avi-se-efcsw) ya esta actualizado, y por otro lado el SE AVI_Avi-se-ejzje se esta actualizando y va el 45%.

Con esto habríamos finalizado la actualización del SE Group.

Conclusión

Hasta aquí hemos llegado una vez mas, como veis es un proceso sencillo, donde podemos actualizar todos los componentes de manera flexible .Espero que os haya gustado, que os sea de utilidad, nos vemos en los siguientes post.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *