¿Cuál es el mejor formato de imagen, raw o qcow2, para usar como imagen base para otras máquinas virtuales?


25

Estoy usando una imagen base y basada en eso creando muchas máquinas virtuales. Y ahora quiero saber cuál es mejor, qcow2 o raw para usar en una imagen base. Además, ¿podría decirme si hay alguna ventaja de usar esta imagen base, en lugar de clonar todo el disco? La velocidad puede ser un factor, pero en términos de eficiencia, ¿hay algún problema al usar una imagen base y luego crear máquinas virtuales con esa imagen base?

Edición 1:

Realicé algunos experimentos y obtuve ingrese la descripción de la imagen aquíingrese la descripción de la imagen aquíingrese la descripción de la imagen aquí

El primero es cuando tanto la imagen base como la superposición son qcow2. Segundo, cuando la imagen base es sin formato pero la superposición es qcow2 y, en tercer caso, estoy dando una imagen de disco sin formato individual a cada VM. Sorprendentemente, el último caso es mucho más eficiente en comparación con los otros dos.

Configuración experimental: 
Sistema operativo en imagen base: Ubuntu Server 14.04 64 bit.
SO host: Ubuntu 12.04 64bit
RAM: 8 GB
Procesador: CPU Intel® Core ™ i5-4440 @ 3.10GHz × 4 
Disco: 500 GB 

En el eje x: número de máquinas virtuales iniciadas simultáneamente. A partir de 1 e incrementado hasta 15.

En el eje y: Tiempo total para arrancar "x" número de máquinas.

De los gráficos, parece que dar una imagen de disco completa a VM es mucho más eficiente que otros 2 métodos.

Edición 2: ingrese la descripción de la imagen aquí

Esto es para el caso cuando estamos dando una imagen en bruto individual a cada VM. Después de enjuagar el caché, este es el gráfico. Es casi similar a la imagen base en bruto + superposición qcow.

Gracias.


1
Usaría una imagen base sin procesar y superpondría QED en lugar de qcow2. QED es más rápido que qcow2 y es menos probable que el diseño lo corrompa.
Matt

@ Matt, por favor comente la pregunta editada.
AB

Las diferencias de rendimiento son interesantes. ¿Puedes probarlo con qed? podría ser un problema de contención / bloqueo en la implementación de qcow2. Creo que tiene algunos problemas, por eso inventaron qed.
Matt

1
@Matt Lo comprobé con superposición de baseimage-qed sin procesar y superposición de baseimage-qcow2 sin procesar. Pero qed es mucho más lento que qcow2 en esta configuración.
AB

Respuestas:


18

Para su caso de uso específico (imagen base + superposición qcow2), debe preferirse el formato RAW:

  1. Es más rápido: como no tiene metadatos asociados, es lo más rápido posible. Por otro lado, Qcow2 tiene dos capas de indirección que deben cruzarse antes de llegar a los datos reales.
  2. Como la capa de superposición debe ser un archivo Qcow2, no pierde la capacidad de instantánea siempre útil (las imágenes RAW no admiten instantáneas por sí mismas)

La elección entre imagen base + superposición qcow2 frente a múltiples copias completas depende de su prioridad:

  1. Para un rendimiento absoluto, utilice imágenes RAW con fallas. Esto tiene la desventaja de no admitir la instantánea, ya que en la mayoría de los entornos es un precio demasiado alto para pagar
  2. Para mayor flexibilidad y eficiencia de espacio, utilice imágenes base RAW + superposiciones Qcow2.

De todos modos, encontré los archivos Qcow2 algo frágiles.

Para mis hipervisores KVM de producción, básicamente utilizo dos configuraciones diferentes:

  1. donde el rendimiento es el # 1, uso volúmenes LVM directamente conectados a las máquinas virtuales, y uso la capacidad de instantánea LVM para realizar copias de seguridad consistentes
  2. donde puedo sacrificar algo de rendimiento para una mayor flexibilidad, uso un solo, gran volumen LVM Thin Provisioned Volume + XFS + RAW imágenes

Otra posibilidad es usar un volumen LVM normal + XFS + imágenes RAW. El único inconveniente es que las instantáneas LVM normales (no delgadas) son muy lentas y la captura de un volumen LVM normal ocupado matará el rendimiento (durante la vida útil de la instantánea). De todos modos, si planea usar solo un uso esporádico de instantáneas, esta puede ser la apuesta más simple y segura.

Algunas referencias:
Lentitud de E / S
KVM en el rendimiento de almacenamiento RHEL 6 KVM y prelocalización Qcow2 en RHEL 6.1 y Fedora 16
Rendimiento de almacenamiento KVM y configuraciones de caché en Red Hat Enterprise Linux 6.2
LVM volumen delgado explicado


Como se indicó anteriormente: las imágenes RAW individuales serán más rápidas debido a que no hay capas de indirección. Sin embargo, recuerde que está renunciando a las instantáneas (a nivel de imagen) y a la eficiencia del espacio. Además, tengo la impresión de que su tercer resultado fue sesgado por la memoria caché del host. Para estar seguro, rehaga todas sus pruebas emitiendo "sync; echo 3> / proc / sys / vm / drop_caches" entre cada ejecución.
shodanshok

En realidad estaba pensando lo mismo. Pero luego pensé que, en caso de uso real, también seguirá el mismo flujo.
AB

En realidad no: en este entorno de prueba, simplemente está arrancando sus máquinas virtuales, sin usarlas. En un caso real, después de arrancar se utilizarán las máquinas virtuales, contaminando la caché. En general, es mejor comparar con un caso de uso razonable.
shodanshok

¿Tiene alguna idea de por qué el almacenamiento en caché no juega tanto papel en el gráfico 1 y el gráfico 2, es decir, Qcow2 base-image + Qcow2 overlay y Raw base-image + Qcow2 overlay.
AB

6

Tenga en cuenta ... si está utilizando Linux, puede usar rawy obtener los mismos beneficios qcow2en cuanto al tamaño.

... Si su sistema de archivos admite agujeros (por ejemplo, en ext2 o ext3 en Linux o NTFS en Windows), solo los sectores escritos reservarán espacio.

https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Using_qemu_img.html

formato de imagen de disco sin formato (predeterminado). Este puede ser el formato más rápido basado en archivos. Si su sistema de archivos admite agujeros (por ejemplo, en ext2 o ext3 en Linux o NTFS en Windows), solo los sectores escritos reservarán espacio. Use qemu-img info para obtener el tamaño real utilizado por la imagen o ls -ls en Unix / Linux.


¡Buen punto! Pero parece que en la copia de seguridad / copia / compresión se utiliza todo el tamaño del archivo de imagen sin procesar. Un archivo sin formato de 20 GB que solo asigna 4 MB en el disco fue comprimido a 20 MB
MrCalvin

Esto fue completamente nuevo para mí. Tengo una VM en Proxmox VE con un disco virtual de 30 GB ... y puedo ver que el disco tiene el tamaño en el sistema de archivos del host. Pero el sistema de archivos host tiene un uso total de << 10GB. Ahora esa es la razón por la que estaba buscando.
cljk
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.