A veces asumo varias tareas para configurar servidores. Hace algún tiempo, el dueño de una pequeña empresa de hosting se me acercó con un problema interesante. Le gustaría ejecutar máquinas virtuales de Windows bajo KVM en sus servidores, donde Ubuntu 18.04 ya estaba instalado.Sin embargo, sus pruebas mostraron que el sistema de disco KVM se retrasó decentemente detrás de los indicadores que tenía bajo Hyper-V. Quería liberar qemu en sus servidores Ubuntu para evitar comprar costosas licencias de servidor de Windows (la versión gratuita de Microsoft Hyper-V Server no funcionó debido a sus limitaciones).0. Disposición
Para las pruebas, utilizamos el SSD Samsung 970 Pro de 1TB. El cliente verificó los resultados del trabajo en CrystalDiskMark, por lo que más adelante en el artículo, todos los gráficos de él.El primer paso fue mejorar el rendimiento aleatorio de E / S. Este tipo de carga es típico para las máquinas virtuales, especialmente aquellas que usan varias bases de datos.Ubuntu (16.04 LTS y 18.04) todavía usa qemu versión 2.11. Por lo tanto, algunos de los últimos bollos qemu no se consideran en este artículo.Decidimos que debemos evitar atar el hierro a una máquina virtual, ya que esto complica la portabilidad de las máquinas virtuales, por lo que las opciones para lanzar SSD / discos físicos / particiones en máquinas virtuales se consideraron indeseables.Acerca del tamaño del archivo de prueba para CrystalDiskMark, 100 4. , : , .
, , Windows . 100 4 , 40 .
, , 100-1. 4.
1. Utilizamos volúmenes LVM, no archivos para almacenar discos de máquinas virtuales.
La lógica es esta. El archivo con el disco virtual se almacena en el sistema de archivos de Linux, NTFS se encuentra dentro del propio archivo. Cada sistema de archivos consume recursos durante las operaciones de disco. Por lo tanto, cuanto menor sea la profundidad de la muñeca, más rápida será la entrada / salida.Si hablamos de archivos qcow2, su nombre significa "Qemu Copy-On-Write" y, de hecho, tienen su propia tabla de traducción dentro de la cual es responsable de qué bloques están ocupados, cuáles no y dónde se encuentra.La capa LVM consume significativamente menos recursos de procesador que el sistema de archivos. Una de las razones de esto es que los bloques que contiene son mucho más grandes que un bloque típico del sistema de archivos (4KB). Cuanto mayor sea el bloqueo (extensión) en el dispositivo LVM físico, más rápido se produce IO y menor fragmentación.Pero incluso para SSD, la E / S aleatoria es mucho más lenta que la serie. Por lo tanto, al crear el grupo de volúmenes, especificaremos una extensión muy grande: 256 MB.La lectura anticipada de un volumen lógico debe estar desactivada, ya que gasta IO sin ganar, ya que ahora nadie está desfragmentando discos en Windows en SSD.LVM es bastante conveniente de usar para alojar máquinas virtuales. Los volúmenes LVM son fácilmente transportables entre discos físicos; hay instantáneas y redimensionamientos en línea. Además, virt-manager (libvirt) puede crear volúmenes lógicos listos para usar para discos de máquinas virtuales del grupo Volumen.La capacidad de crear volúmenes delgados también parece atractiva, pero dado que un volumen delgado es una capa adicional de abstracción, es obvio que degradará el rendimiento de IO. Además, libvirt no tiene una forma elegante de crear automáticamente discos para máquinas virtuales en un grupo delgado.
pvcreate /dev/nvme1n1p1
vgcreate -s 256M win_pool /dev/nvme1n1p1
lvcreate -n vm1 -L 100G win_pool
lvchange -r none /dev/win_pool/vm1
1.1. Volumen delgado como un disco y / o configuraciones de volumen lógico para instantáneas
Si desea utilizar un grupo delgado en el que creará volúmenes delgados, entonces tiene sentido establecer el tamaño del fragmento del grupo en 4 MB, que es mucho más grande que el tamaño predeterminado de 64 KB.Lo que implicará un trabajo más rápido de esta capa de abstracción.El mecanismo de instantánea en LVM funciona casi en el mismo código que los volúmenes delgados, por lo que la configuración será la misma para aumentar la velocidad de la instantánea.lvcreate -c 4m -L 300G -T -Zn win_pool/thin
La opción -Zndeshabilita la sobrescritura del fragmento con ceros durante la selección, lo que aumenta la velocidad del trabajo.Configuración para lvm.conf o un archivo similar (por ejemplo, lvmlocal.conf):thin_pool_chunk_size = 4096
thin_pool_zero = n
Puede determinar el tamaño óptimo del fragmento completando la prueba con el siguiente comando, eligiendo el valor --blocksize:fio --name=randwrite --filename=/dev/nvme0n1p9 --size=10G --ioengine=libaio --iodepth=1 --buffered=0 --direct=1 --rw=randwrite --blocksize=4m
Puede ver el tamaño actual del fragmento con el comando:lvs -ao name,chunksize
2. Aumentar el número de procesadores lógicos asignados a cada máquina virtual KVM mejora el rendimiento del disco
Está claro que casi nadie asignará 10 procesadores a la máquina virtual, pero fue interesante observar el caso extremo.Ya depende de la cantidad de procesadores libres. En mi opinión, no es conveniente asignar más de 4. Con el número de hilos igual a 8, obtuvimos el máximo rendimiento de lectura y escritura aleatoria. Esta es una especificidad de CrystalDiskMark 6.0.2, en la que la segunda prueba realiza 8 subprocesos.De lo cual podemos concluir que es bueno tener un procesador lógico para cada tarea que use activamente IO.3. Utilizamos grandes páginas de memoria de acceso aleatorio (enormes páginas) para evitar la degradación del rendimiento debido a la fragmentación de la RAM
Este paquete puede ser útil cuando necesitamos información diversa sobre páginas enormes durante la operación.apt install hugepages
Editar /etc/default/grub:GRUB_CMDLINE_LINUX="default_hugepagesz=1GB hugepagesz=1G hugepages=64"
En este caso, se asignaron 64 GB de memoria para todas las máquinas virtuales como páginas enormes. En su caso puede haber menos / más.Aplicamos esta configuración a GRUB para que la próxima vez que se inicie el sistema, se activen:grub-mkconfig -o /boot/grub/grub.cfg
Edición de la configuración de la máquina virtual:virsh edit vm_name
Añadir:<memoryBacking>
<hugepages/>
</memoryBacking>
4. Agregue una transmisión dedicada a cada máquina virtual para servir IO
Debe agregar lo que está resaltado en negrita. Usamos virsh, como en el párrafo anterior.<iothreads>1</iothreads>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='threads' iothread='1'/>
<source dev='/dev/win/terminal'/>
<target dev='vda' bus='virtio'/>
<boot order='2'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
4.1. writeback
Para acelerar la escritura accidental en el disco, pero con un mayor riesgo de pérdida de datos, puede usar cache=writebackel párrafo anterior. Solo se puede usar si existe una gran confianza en la calidad y el respaldo de la energía y en presencia de respaldos.5. Configuración del subsistema de disco en Virt Manager
Bus de disco:
formato de almacenamiento VirtIO :
modo de caché sin procesar :
modo IO de reescritura : subprocesos
5.1. Configurar un subsistema de disco a través de un archivo de configuración
Qemu 2.11 (que actualmente usa Ubuntu) admite dos tipos de dispositivos virtuales de disco: virtio-blk y virtio-scsi. Cuando se especifica en Virt Manager Disk bus: VirtIO, esto significa usar el dispositivo virtio-blk.En todos los casos, virtio-blk es mejor en velocidad, a pesar de que en la versión probada de qemu todavía no era compatible con TRIM, a diferencia de virtio-scsi ( ya lo admite desde la versión 5.x ).Desde el punto de vista de la velocidad de E / S del disco, virtio-scsi solo tiene sentido en casos exóticos, por ejemplo, cuando necesita conectar cientos de discos a una máquina virtual.6. Durante la instalación de Windows, instale el controlador VirtIO
De lo contrario, el disco no estará disponible para el sistema operativo. Para hacer esto, use la imagen del controlador, que conectamos previamente a la máquina virtual.7. Resultados después de aplicar todos los ajustes
De hecho, el tweak 4.1 no se usó, ya que no estaba seguro de la fiabilidad de la fuente de alimentación del cliente.Debe comprender que estos resultados tienen una convención determinada, ya que cada vez que inicia CrystalDiskMark, los valores son ligeramente diferentes.Vemos que fue posible acelerar significativamente el trabajo del subsistema de disco en qemu (kvm) con el mismo número de núcleos. La escritura se aceleró en un promedio de 58% y la lectura en un 25%.Elementos clave de éxito : uso de volúmenes LVM en lugar de archivos qcow2, E / S separadas y grandes páginas.Dirija los errores notados al PM. Aumento el karma para esto.PS vhost-user-blk y vhost-user-nvme
Durante los experimentos, Qemu 2.12 y la versión 3 también se compilaron. Se probó la opción vhost-user-blk para un disco.Al final, funcionó peor que virtio-blk.Para usar vhost-user-nvme era necesario parchear qemu, esta opción complicaba la actualización automática de los servidores en producción, por lo que no se probó.PPS SPDK
Intel diseñó este marco para lograr indicadores de rendimiento sobresalientes para sistemas de disco en máquinas virtuales que deberían ejecutarse en sus procesadores.Para que spdk funcione bien, recurren a muchos trucos: le asignan núcleos separados, colocan los núcleos de máquina virtual y spdk en un zócalo. Cargue la máquina virtual en una porción contigua de memoria. Si aplica tales medidas al virtio-blk regular, también funcionará más rápido.SPDK es capaz de trabajar en 3 modos: vhost-user-scsi, vhost-user-blk y vhost-user-nvme. El segundo modo solo está disponible en qemu desde 2.12, que aún no está disponible en ubuntu. El modo vhost-user-nvme es generalmente megaexperimental: debe parchear qemu para ello. Actualmente, solo la emulación scsi funciona y es lenta.Hay una limitación más seria para el modo vhost-user-scsi: spdk no puede ser arrancable.Asegúrese de que la opción bootindex = 2 Qemu esté disponible en el dispositivo vhost-user-scsi-pci.
Los registros se establecen cuando usan su controlador para compartir SSD en múltiples dispositivos y reenviarlos como vhost-user-nvme. El enfoque de perforación de hierro no nos convenía.La impresión era que era normal usar SPDK solo con su implementación de discos lógicos (que es completamente diferente de lvm estándar). Esta es una bicicleta hecha a sí misma con sus imágenes y clonación. Los equipos son todos diferentes de LVM.La dificultad en la configuración de SPDK, el soporte y la portabilidad de las máquinas virtuales, así como la conexión a los procesadores Intel, se alejaron de su uso.Expresiones de gratitud
Gracias por la imagen TripletConcept . Es mejor verlo en tamaño completo en una ventana separada.
Para obtener permiso para compartir materiales de trabajo:st_neon
Puede solicitar una máquina virtual con SSD de RUVDS para el cupón a continuación. Dirija los errores notados al PM. Aumento el karma para esto.