Es posible que en algún momento te hayas planteado la posibilidad de migrar tu base de datos (u otro servicio crítico) a una máquina virtual, y te haya asaltado la duda de si obtendrías el rendimiento de disco apropiado para mantener un buen grado de calidad del servicio.
Ciertamente, al virtualizar siempre aparece cierto grado de overhead en los accesos de E/S, al introducirse una capa intermedia y un posible arbitrador para el acceso, pero dicho overhead depende en gran medida de cómo configuremos el backend de disco de nuestra máquina virtual. Si lo hacemos bien, podremos conseguir que no afecte significativamente a las aplicaciones, y a cambio mantendremos todas las ventajas de tener nuestro servicio virtualizado.
Evaluando el rendimiento del disco virtual
A la hora de evaluar el rendimiento, es fundamental establecer un baseline, que en nuestro caso será el rendimiento de disco en el propio Host que alberga las máquinas virtuales. Posteriormente, sacaremos métricas de rendimiento con varias configuraciones para el disco de la máquina virtual, y las compararemos con dicho baseline.
Para las pruebas, usaremos FIO, una herramienta que nos permite simular carga sobre el almacenamiento de forma bastante flexible, con múltiples motores de E/S y patrones de acceso.
La configuración de nuestro entorno de pruebas es la siguiente:
- Procesador: 2 x AMD Opteron 6230 Octa-Core @ 2.80 Ghz (16 cores en total)
- RAM: 48 GB
- Sistema Operativo: flexVM Host 2.0 (basado en CentOS 6.5)
- Hypervisor: KVM + QEMU 0.12.1
- Almacenamiento: SSD Prevail Elite Professional 240GB 10K, MLC, SATA 6Gb/s
Y vamos a evaluar las siguientes configuraciones de almacenamiento:
- Native: Acceso a disco en el sistema operativo anfitrión, con sistema de ficheros ext4. Será nuestro baseline.
- Direct: Disco duro del sistema anfitrión pasado directamente a la máquina virtual.
- Raw: Disco en un fichero binario sin formato.
- QCOW2: Disco en un fichero con formato qcow2 con la configuración por defecto.
- QCOW2-Prealloc: Disco en un fichero con formato qcow2 con bloques reservados.
Resultados
Uno de los aspectos que puede llamar más la atención de estos resultados, es cómo al pasar del disco del Host al disco de la máquina virtual, la relación entre el rendimiento de escritura y el de lectura se invierte. Esto se produce ya que la virtualización añade una capa más de caché, lo cual perjudica a las operaciones de escritura pero beneficia a las de lectura.
Por otro lado, también podemos apreciar cómo la opción de pasar un disco directamente del Host a la máquina virtual se lleva lo mejor de los dos mundos: saca provecho de la caché adicional, manteniendo un rendimiento razonable en las escrituras.
Conclusiones
A la hora de configurar el disco de nuestra máquina virtual, debemos tener presente las necesidades del servicio que estamos virtualizando, así como los pros y los contras de cada opción. Usar el formato raw nos da el mejor rendimiento de los backends basados en fichero, pero nos obliga a prescindir de opciones como thin provisioning, snapshots y clonados. Por otro lado, al usar QCOW2 con reserva de bloques, sólo renunciamos al thin provisioning, manteniendo el resto de ventajas, y con el rendimiento bastante bueno.
Para despliegues productivos, si disponemos de almacenamiento compartido, sin duda la mejor opción es combinar un disco QCOW2 para albergar el sistema operativo, con un disco directo donde almacenar los datos críticos del servicio.
Usando acceso directo a disco con flexVM
Todas las ediciones de flexVM permiten configurar y gestionar físicamente discos directos, haciendo uso de un almacenamiento de tipo Direct Storage. Dicho almacenamiento, busca e identifica todos los discos compartidos del entorno, y permite hacer uso de los mismos en todos los Hosts, evitando así posibles colisiones entre dispositivos.