Hace año y medio me embarqué junto con mis colegas de departamento en la ardua empresa de migrar nuestra plataforma de servidores empresariales hacia una plataforma full-virtualized basada en OpenVZ, KVM y ProxMox. Escribo esto con la ventaja de hacerlo postumamente a la finalización de la misma.
La decisión de iniciar esta migración tiene su punto inicial en el anuncio de Debian de marcar como deprecated el uso y soporte oficial de VServer a partir de Debian 6.0
El caso es que de aquella estábamos de aquella realizando un uso habitual de la tecnología de VServer para los servicios de cliente y internos de la empresa
bajo las premisas:
“El sistema base lo más limpio posible y homogéneo” y “Máquina virtual por servicio“
(para evitar incompatibilidades entre distintos software bajo la misma
instancia de SO, reducir solapamientos de servicios …)
La alternativa que valoramos fue el paso a un sistema mixto de OpenVZ y KVM gestionado por una aplicación web ad hoc usando libvirtd y la justificación de esta alternativa era la siguiente:
- Fácil migración de VServer a OpenVZ (3 simples pasos)
- En OpenVZ tenía dos modos de gestión de la red: red virtual y dispositivo virtual
- El uno tenía la ventaja de ser rápido y sencillo de configurar y más restrictivo en cuanto capacidades del guest
- El otro permitía multicast/broadcast y usado conjunto bridges ofrecía una configurabilidad muy seductora. Por ejemplo, arranque por DHCP 🙂
- Ambos modos permitía la posibilidad de cargar reglas de IPtables en el guest
- El wiki/soporte documental del proyecto OpenVZ era mucho mayor, claro y organizado que el de VServer
- OpenVZ ofrecía la capacidad de migración de nodos en caliente.
- Los rendimientos de OpenVZ frente a VServer eran bastante equiparables
- Libvirtd había incorporado recientemente soporte para OpenVZ
- Libvirtd tenía sus respectivas implementaciones del API de C para Ruby y Python
- KVM era bastante cómodo de usar
- KVM empezaba a dar señales de robustez para AMD64
- KVM nos permitiría la evaluación de otras plataformas a las cuales no dedicabamos tiempo debido a lo engorroso de reinstalar máquinas físicas: BSDs, Solaris sin el uso de Zones, Windows …
- Era asumible la construcción de un software basado en Libvirtd + OnRails para la gestión homogénea de lo que sería nuestra nueva plataforma
No obstante, un punto crucial en nuestro camino fue el descubrimiento del proyecto ProxMox. Este hayazgo, facilitó enormemente el camino ya que, una vez analizado y probado, nos dimos cuenta que cubría a la perfección nuestras demandas como usuarios y administradores de la plataforma de virtualización y esto implicaba que el desarrollo de una frontend de gestión ya no sería necesario. Mientras tanto, las evaluaciones que estabamos realizando con respecto a OpenVZ eran muy positivas con respecto a VServer:
- Migración on live funcionaba realmente.
- El sistema probado fue entre nodos independientes (sin storage común)
- La migración se realiza en caliente usando ssh,public_keys y rsync.
- El cambio de nodo se hace sin aparente caída del servicio
- Sistema de snapshots funcional.
- Política de Red
- Venet (virtualización de la red). Funciona, es eficiente y nos permitió virtualizar segmentos de red (muy interesante en nuestro caso ya que hasta la fecha usabamos el mismo segmento de red para servicios que deberían estar aislados a nivel 2 y sólo accesibles a nivel 3 por enrutado). Venet nos permitió simular este comportamiento sin añadir hardware de red adicional.
- Veth (bridge). No era nada fuera de lo normal con respecto a lo que se hacía con KVM y con Xen. Nos vino muy bien para los entornos de desarrollo ya que da la sensación de entorno real, y también en los entornos controlados de producción donde necesitamos, por ejemplo, multicast (como clusters Tomcat).
- Gestión de recursos:
- Un poco confusa antes de leerse la documentación (muy buena, por cierto), pero muy simple de gestionar luego.
- Límites de uso de páginas de memoria, unidades de CPU, bloques de disco, número de procesos, nº PTYs, buffers TCP, buffers socket …, quotas, memoria del kernel, y otros parámetros de configuración como red, dominio …
- Finalmente, también se podían quitar los límites y dejar que las máquinas compitieran entre ellas por recursos del sistema real.
Finalmente, después 1 año y 4 meses, entre VZs, puedo decir que la migración a VZ fue un éxito en líneas generales. Cierto que tuvimos unos cuantos altercados en todo el proceso que nos costaron ciertos dolores de cabeza, pero en líneas generales el resultado final ha merecido la pena y ya llevamos más o menos desde marzo del año pasado (2009) trabajando a pleno rendimiento con la plataforma virtual.
A grandes rasgos y a modo conclusiones, resumiré los hitos conseguidos:
- Abstracción de red. Con Venet + iproute2 + iptables, e implementación de redes “virtuales” por encima de una única vlan.
- Desolapamiento entre servidores físicos y servidores virtuales
- Sencillo y fiable sistema de snapshots basado en vzdump y LVM2snapshots
- Aceptable sistema de appliances (plantillas de OS para usar)
- Pasamos de largo del centenar de máquinas virtuales corriendo en 15 nodos reales y aún con cierta holgura de crecimiento mayor.
- Hemos reducido a trivial la problematica de restauración tras pérdida y/o corrupción de datos;
- Hemos reducido a trivial las restauración y/o disponibilidad de servicio a pesar de averías hardware.
- Hemos reducido a trivial la clonación y replicación de servicios tanto para tareas eventuales de actualizaciones delicadas que requieren de un checkpoint como para la creación de escenarios réplica de servicios en funcionamiento los cuales poder llevar a ferias y demostraciones (a modo branch de los sistemas en “producción”)
- Sencillo y fiable interfaz de administración web y acceso mediante consola VNC.
- y lo más importante … todo 100% libre y sin coste asociado al producto.
503: Service Unavailable 