Artículos técnicos
vCloud Availability: funcionalidades para nube híbrida
Pyxis Comunicación
16 de junio de 2020
Comparte
En este nuevo post del blog vamos a mostrar los resultados y conclusiones de nuestras pruebas sobre las funcionalidades de migración y replicación de máquinas virtuales con vCloud Availability, para nube híbrida.
INTRODUCCIÓN
Este artículo está dirigido a los administradores de organizaciones (o tenant) de nubes basadas en vCloud Director, a quienes llamaremos OrgAdmins.
Asumiremos que el OrgAdmin es también responsable de la administración del resto de la infraestructura IT de la empresa.
En el concepto de nube híbrida, una empresa ejecuta aplicaciones tanto en nubes públicas, como en nubes privadas, entendiéndose lo público o privado según si la infraestructura es compartida o no con otras empresas.
Una funcionalidad básica de nube híbrida es la de poder migrar una aplicación entre nubes, con la menor indisponibilidad posible. Algunos casos de uso típicos son los de afrontar escenarios de disaster recovery, o de migrar aplicaciones entre nubes para responder a una demanda inesperada.
vCloud Availability (abreviado vCav) permite migrar o replicar máquinas virtuales y vApps entre nubes basadas en vCloud Director; o entre vCloud Director y vSphere.
Una vez desplegado y configurado vCav, el mismo funciona como un plugin en las interfaces HTML5 de vCloud Director o de vCenter, permitiendo al OrgAdmin la auto-gestión de los procesos de migración y replicación. A alto nivel se ve como el diagrama a continuación:
Diagrama de componentes a alto nivel en el caso de migraciones desde on-premise hacia nube
Como mencionamos anteriormente, también es posible integrar dos proveedores de nube entre sí usando vCloud Availability, de forma que un OrgAdmin que cuente con organizaciones de vCloud Director en ambos proveedores de nube, puede migrar máquinas virtuales entre esos proveedores, sin intervención adicional de terceros. Ver siguiente diagrama:
Diagrama de componentes a alto nivel en el caso de migraciones nube a nube.
Este artículo no pretende ser un paso a paso sobre configuración de Availability, sino mostrar algunas pruebas desarrolladas y sus resultados.
RESUMEN
Algunos comentarios sobre usar vCloud Availability para migraciones en nube híbrida:
– La indisponibilidad causada por una migración y de su respectivo rollback se reduce drásticamente. En nuestras pruebas fueron de 10 minutos o menos rollback más migración.
– Las tareas de migración/replicación y sus respectivos rollbacks son auto-gestionadas por el OrgAdmin.
– En el caso de migraciones de on-premise hacia vCloud Director, es relativamente simple de configurar desde el lado del sitio on-premise.
– En el caso de migraciones entre vCloud Directors, no requiere despliegue de ningún componente adicional por parte del OrgAdmin.
– El cliente no tiene que pagar ningún licenciamiento adicional.
– El cliente debe usar vCenter 5.5 en adelante para usar Availability 3.x
– Para usar todas las funcionalidades, el cliente debe contar con vCenter 6.5 U2 en adelante.
Ejecutamos estas pruebas y estos son los resultados:
| Prueba | Resultado esperado | Resultado obtenido |
| Ejecutar una migración de una máquina virtual, y su vuelta atrás, de forma 100% auto-gestionada por parte del OrgAdmin. | Es posible ejecutar una migración y su vuelta atrás usando herramientas de autoservicio, sin intervención alguna del proveedor o de terceros. | Éxito. Se ejecutó la migración y la vuelta atrás usando exclusivamente la interfaz de gestión del tenant de vCloud Director. |
| Tomar el tiempo que toma activar la réplica y desactivar el origen, y viceversa. | Reducir los tiempos de indisponibilidad a un orden de minutos. | Éxito. 5 minutos o menos entre el apagado de la máquina virtual de origen, y el encendido en el sitio de destino. |
| Revisar cifrado de la conexión para pasaje de datos entre el sitio on-premise y la nube. | El tráfico de datos entre on-premise y nube es encriptada. | El tráfico va encriptado usando HTTPS. |
RIESGOS Y PRUEBAS
Todo OrgAdmin que quiera migrar la infraestructura on-premise de su empresa hacia la nube, tiene el reto de lograrlo en el menor tiempo posible, minimizando el riesgo de impacto en el negocio.
A continuación evaluamos cómo con vCloud Availability se pueden mitigar algunos de esos riesgos.
Tomamos en cuenta cinco atributos básicos de toda solución, como ser performance, disponibilidad, recuperabilidad, seguridad y administrabilidad.
En base a eso, hicimos un punteo de riesgos percibidos por parte de clientes en los distintos puntos de los procesos de migración hacia la nube, y posibles mitigaciones:
1. ¿Que pasa si la performance de la nube no es mejor o igual a la de la infraestructura on-premise? (Performance)
Dimensionar correctamente la asignación de recursos de la nube usando métricas objetivas.
Si bien VMware vCloud Availability no mejora la performance de la nube de por sí, puede ayudar al migrar rápidamente de una nube a on-premise o viceversa, de forma totalmente auto-gestionada.
2. ¿La nube a la que voy a migrar va a tener igual o mejor disponibilidad que a infraestructura on-premise? (Disponibilidad)
Si bien vCloud Availability no interviene directamente sobre la disponibilidad de la plataforma per se, al crear réplicas de máquinas virtuales entre dos sitios puede mejorar la disponibilidad de una solución dada.
3. ¿Cómo reduzco la indisponibilidad de las soluciones durante el proceso de migración? (Disponibilidad).
En migraciones de gran porte, ejecutar la migración de cada componente de cada aplicación puede generar bajas de servicio (programadas o no) de varias horas, sin contar con tareas potencialmente dependientes de terceros como traslado de medios físicos. vCloud Availability permite migraciones sin transporte de medios físicos, en el mejor de los casos se puede reducir al tiempo de indisponibilidad a lo que tome apagar la VM del sitio de origen y encenderla en el sitio de destino.
4. ¿Cómo vuelvo atrás en caso de que desee volver a mi plataforma on-premise? (Recuperabilidad)
Como comentamos antes, vCloud Availability permite una total auto-gestión respecto a migraciones (o vuelta atrás de las mismas), sin intervención de terceros.
5. ¿Cómo afecta la migración, una vez completada, a mis procesos de backup y recovery? (Recuperabilidad)
El OrgAdmin debe planificar sus métodos de backup y recovery en el sitio de vCloud Director.
Vcloud Availability permite replicar máquinas virtuales entre dos virtual data centers (VDCs) de una misma nube basada en vCloud Director, por lo que podría usarse como método de replicación.
6. ¿Que pasa con la seguridad de mis datos mientras y después del proceso de migración? (Seguridad)
Usando vCloud Availability, se puede evitar mover medios físicos entre sitios, ya que Availability usa una conexión cifrada entre ambos sitios para transferir los datos.
7. ¿Cómo gestiono el proceso de migración, desde el punto de vista técnico? (Administrabilidad).
Con vCloud Availability, el cliente puede auto-gestionar la migración y la vuelta atrás de sus máquinas virtuales, entre su sitio on-premise y la nube, usando la misma interfaz de gestión HTML5 de vCloud Director.
A los efectos de las pruebas, podemos agrupar los puntos 1,4,5,7 en una sola prueba, y los puntos 2 y 3 en otra.
| Prueba | Resultado esperado |
| Ejecutar una migración y su vuelta atrás de una máquina virtual sin intervención de terceros. (Punto 1,4,5,7) | Es posible ejecutar una migración y su vuelta atrás usando herramientas de autoservicio. |
| Tomar el tiempo que toma activar la réplica y desactivar el origen, y viceversa. (Puntos 2,3) | La indisponibilidad se puede reducir a los tiempos de apagado y prendido de la máquina virtual. |
| Revisar cifrado de la conexión para pasaje de datos entre el sitio on-premise y la nube. (Puntos 6) | El tráfico de datos entre on-premise y nube es encriptada. |
ARQUITECTURA DE VCLOUD AVAILABILITY
Antes de hablar del resultado de las pruebas, vamos a comentar un poco sobre la arquitectura de vCloud Availability desde el punto de vista del OrgAdmin.
En esta sección asumimos que el proveedor de nube usa vCloud Director y ademas ya tiene implementado vCav.
El appliance para tenant puede ser descargado de la web de VMware, y las URLs y detalles de conectividad necesarios pueden ser provistos por el proveedor de la nube.
Es posible que haya que pedir una autorización adicional al proveedor de la nube para usar este servicio, pero eso dependerá de las políticas de negocio del proveedor.
De forma resumida, el OrgAdmin debe desplegar un appliance, al cual se le deben configurar los servicios para que pueda conectarse al proveedor de nube.
vCloud Availability a nivel de aplicación consiste en tres servicios:
Tunnel
-Establece el túnel SSL VPN entre sitios
Replicator
– Genera el tráfico de replicación y migración, copiando los datos de máquinas virtuales y redirigiéndolos hacia el sitio de destino usando una conexión encriptada hacia el servicio Tunnel.
Cloud Management
– Servicio de interfaz de gestión del appliance de Availability. Cuando el sitio tiene vCloud Director, se integra a la interfaz HTML5 de Director.
vCloud Availability cuenta con dos versiones del appliance:
Tenant – para sitios con vCenter.
-Todos los servicios están concentrados en un appliance.
-Éste es el appliance que despliega el OrgAdmin en el sitio on-premise.
Service provider – para sitios con vCloud Director.
-Éstos appliances los despliegan por única vez los proveedores de la nube y no son gestionados ni configurados por los OrgAdmin.
A continuación, diagrama de componentes a alto nivel, con los distintos servicios, y de conectividad del appliance Tenant:
Arquitectura de vCloud Availability alto nivel. VMware.
Arquitectura de vCloud Availability en el sitio on-premise. VMware
LABORATORIO
Desplegamos un laboratorio usando virtualización anidada sobre vCloud Director.
No vamos a entrar en detalle sobre el procedimiento de despliegue del laboratorio, ya que seguimos los procedimientos estándar de la documentación de VMware para todos los productos.
En ese laboratorio vamos a simular dos sitios:
- Sitio A: proveedor de vCloud Director 9.5, con un cluster basado en vCenter 6.5 U3
- Sitio B: sitio on-premise del cliente, con un cluster de vCenter 6.5 U3
Ver el siguiente diagrama de componentes del laboratorio:
Diagrama a alto nivel de componentes del laboratorio.
RESULTADOS
Ejecutar una migración y su vuelta atrás de una máquina virtual sin intervención de terceros.
Este no es un paso a paso detallado, ya que el propósito es más bien mostrar el resultado y cómo se aprecian
Una vez instalado y configurado en ambos sitios Availability, usando la interfaz HTML5 de vCloud Director, es posible ejecutar una migración de una máquina on-premise a la nube (ver siguiente captura).
En este caso, c01-vc03 es nuestro ‘Sitio A’
Luego de ello, podemos configurar la réplica, que se puede apreciar de esta forma en la imagen siguiente. Notar que Availability cambia algunos nombres de máquinas cuando hace la replicación, agregándoles un sufijo.
Vista de replicación desde on-premise hacia nube
Luego de ejecutada la migración, se puede apreciar la máquina en el virtual datacenter de la nube de destino, como en la imagen siguiente:
Detalles de la VM migrada
Probando la vuelta atrás de la migración
Vemos que es necesario primero hacer un ‘reverse’, para que el flujo de réplica de datos cambie el sentido. Luego de esto podemos que el tipo de replicación aparece como ‘Outgoing Replications’ → ‘to On-Prem’
Luego de ejecutar el wizard para hacer el ‘Migrate’, vemos la VM prendida nuevamente en el vCenter on-premise. En la siguiente imagen se ve la VM nuevamente importada al vCenter.
Tomar el tiempo que toma activar la réplica y desactivar el origen, y viceversa.
Las pruebas fueron hechas a partir de una instalación nueva de CentOS 8, con 4GB RAM, 2 vCPU y 16GB de RAM, versión de hardware virtual 10.
Durante ambas pruebas, la máquina virtual está con carga menor al 10% de CPU y RAM, y con una cantidad ínfima de IOPS.
Además, notar que en nuestro laboratorio, ‘Internet’ entre ambos sitios en realidad era una LAN.
En nuestro laboratorio, migrar una VM tomó unos 5 minutos, contando desde el apagado en origen hasta el prendido en destino.
El proceso de vuelta (nube hacia on-premise), tomó aproximadamente 5 minutos.
Ejemplos de tiempos desde que vCav apaga la VM en el sitio on-premise, y la enciende en el sitio de nube, vistos desde vCenter:
Revisar cifrado de la conexión para pasaje de datos entre el sitio on-premise y la nube.
Las conexiones entre sitios son cifradas usando el protocolo HTTPS. En caso de querer cambiar los métodos de cifrado poniendo más restricciones sobre los algoritmos de cifrado, basta con poner proxies reversos entre los appliances y el firewall de borde.
PARA TERMINAR
Encontramos satisfactorio el uso de vCloud Availability para ejecutar migraciones y réplicas de máquinas virtuales entre sitios. (ver la tabla que está en el resumen de este artículo).
Opino que un OrgAdmin no precisa apoyo significativo para migrar máquinas virtuales entre nubes una vez configurado el appliance de vCav. Es posible que el OrgAdmin, al desplegar el appliance de vCav precise soporte. Pero en ambos casos, pienso que una documentación breve y concisa sobre despliegue y uso de vCav por parte del proveedor de la nube cubrirá la mayor parte de las dudas.
Por otro lado, el cliente debería actualizar su sitio para al menos vCenter 5.5, o vCenter 6.5 U2 si quiere visualizar el plugin en la interfaz de vCenter. Esto no es imprescindible para operar con vCav a través de la interfaz HTML5 de vCloud Director.
AGRADECIMIENTOS
Al equipo de Research de Pyxis por coordinar y ejecutar las pruebas de la solución, y darme una devolución sobre la misma.
Como siempre, al equipo de Comunicación por la buena disposición a ayudarnos a que la entrada quede lo mejor posible.
LINKS DE INTERÉS
Pyxis Comunicación
16 de junio de 2020