¿Qué tipo de disco KVM usar?


11

Estoy configurando algunos invitados virtuales KVM y estoy debatiendo qué tipo de disco usar. No he podido encontrar un buen recurso en línea que reduzca los pros y los contras de cada uno.

¿Me pueden ayudar a crear una lista de los diferentes tipos de discos y las ventajas y desventajas de cada uno? Estos son los tipos de discos que conozco:

  • Imagen en bruto
  • qcow2
  • Partición dedicada (p. Ej., En LVM)

Tengo curiosidad sobre estos criterios:

  • Facilidad de configuración (qué tan fácil es crear cada tipo)
  • Actuación
  • Facilidad de clonación
  • Facilidad de expansión (para hacer más grande, para que el invitado virtual tenga más espacio en disco)
  • Características específicas de ese tipo de disco
  • Facilidad de respaldo
  • Migración a otros hosts

¿Me pueden ayudar a evaluar mis elecciones?

Respuestas:


8

Me concentraría en la imagen en bruto y LVM.

La imagen sin formato es más fácil de respaldar y copiar, ya que es solo un archivo y puede hacer con él lo que sea que pueda hacer en un archivo simple. Además, evitando formatos específicos, puede usarlo fácilmente, como montarlo en un dispositivo de bucle para acceder a los archivos en caso de bloqueo o problema (o incluso en un servidor de respaldo sin virtualización). Por otro lado, los archivos de imagen sin procesar se ven afectados por la memoria caché del archivo del núcleo, por lo que debe tener mucho cuidado cuando se trata de bloqueos y apagados, ya que VM sync () realmente no significa que el servidor host sincronizó () el archivo a un disco Tuve muchos problemas con eso.

LVM evita el problema de caché, tiene un mejor rendimiento que los archivos (AFAIK, puede haber cambiado en los últimos meses) y tiene las ventajas de las instantáneas para la copia de seguridad. Cambiar el tamaño de los discos tampoco es complicado, pero es un poco menos trivial que los archivos sin formato. También con LVM puede configurar DRBD para migraciones en vivo / failover.

En mi opinión, utiliza LVM a menos que tengas necesidades muy específicas de archivos.


9

teniendo en cuenta la lista de consideraciones que dio, definitivamente vaya con LVM. La única ventaja de usar qcow2 es que permite hacer instantáneas. Esas instantáneas son muy superiores a las instantáneas LVM. RAW, por supuesto, no tiene ninguna opción de instantánea, pero una imagen RAW puede ser la base para una instantánea qcow2.

  • Facilidad de configuración (lo fácil que es crear cada tipo): igual para todos, raw / qcow2 utilizado por qemu-img, particiones / LVs por fdisk / lvm api
  • Rendimiento: los LV sin formato o los dispositivos de bloque son más rápidos, los archivos RAW son los siguientes, qcow2 tiene la mayor sobrecarga, pero es la más rica en funciones
  • Facilidad de clonación: qemu-img se utiliza para eso, y puede tener en cuenta las instantáneas ya tomadas. con LVs de otros desarrolladores de bloques, probablemente necesites usar dd
  • Facilidad de expansión (para hacer más grande, por lo que el invitado virtual tiene más espacio en disco): si esto es importante, LV es la mejor opción. Por lo general, no lo es, porque simplemente agregaría otro disco virtual o un tamaño arbitrario, y también puede comprometer el almacenamiento en exceso usando discos dispersos
  • Características específicas de ese tipo de disco: qcow2 es el formato con más funciones, como ya he mencionado. Se puede combinar con una imagen sin formato por cierto, usar la imagen sin formato como imagen base y qcow2 como instantáneas
  • Facilidad de copia de seguridad: copie un archivo o dd / cpio, no es realmente un problema
  • Migración a otros hosts: para la migración en vivo, normalmente usaría almacenamiento centralizado, donde no es necesario mover la imagen. La migración en bloque también es posible. en cuanto a solo mover la VM de host a host en modo fuera de línea: es lo mismo que hacer una copia de seguridad / restaurar la VM

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.