TL/ julio 20, 2019/ Cloud/ 0 comentarios

Nos gustan los retos y como bien es sabido Proxmox no recomienda para su plataforma raid por software porque el rendimiento no es bueno. Y esto es verdad pero a medias, tras muchas pruebas montando una plataforma Proxmox de 3 nodos con GlusterFS discos locales 3 de 2 TB 7k en Raid 5 para la partición del brick de Gluster y en raid 1 para la partición del sistema Proxmox.

Como pueden observar los discos son de 7k y si a eso le sumamos que los datos estarán replicados en 3 servidores con una conexión de 1Gb es difícil que tenga buen rendimiento, pues es cierto, pero solo si seguimos recomendaciones que vamos a encontrar por Internet y que son lógicas, de hecho empezamos por ahí, viendo recomendaciones y probando. Una vez agotadas todas las recomendaciones y viendo que las máquinas tenían un performance de escritura realmente horrible 10mb/s hicieras lo que hicieras decidimos hacer un análisis desde cero y configurando según nuestros criterios y cálculos.

No vamos a explicar como instalar Proxmox con raid por software ya que hay muchos manuales buenos en Internet al igual que no vamos a explicar como instalar Gluster, solo los parámetros que hemos tocado, aún así si desean un manual pónganse en contacto con nosotros y estaremos encantados de sacar un hueco para realizarlo.

Lo primero basándonos en teoría el formato elegido de disco de las máquinas en un principio es raw porque es más rápido, no tiene metadatos asociados aunque se pierde la ventaja de hacer snapshot. La elección también depende cual es el fin o por ejemplo utilizar qcow2 para el disco de sistema y raw para el disco de datos. En nuestro caso estamos buscando performance y raw en «teoría» es más rápido. Una vez creadas las máquinas con formato raw con bus VirtIO Block (el que mejor rendimiento nos ha dado) empezamos hacer pruebas con write back como cache y sin ella llegando a

Nada mal para tener muchas máquinas compartiendo datastore con discos de 7k

Para conseguir estos valores que han sido lo máximo tras muchas pruebas configuramos los siguientes parámetros en Gluster

Con Gluster volume info all podemos ver todos los parámetros pero nos interesa sin all porque nos muestra los que se han tocado y no están por defecto a partir de donde pone Options Reconfigured, no vamos a entrar en detalle explicando uno a uno porque ya hay mucha info en internet y más o menos con el nombre podemos identificar su propósito.

Para configurar dichos parámetros se utiliza:

gluster volume set <VOLNAME> <OPT-NAME> <OPT-VALUE>

Ejemplo: gluster volume set gv0 performance.cache-size 1024MB

Aún así no nos cuadraba mucho el rendimiento que nos estaba dando aunque no estaba nada mal, pero nos daba la sensación de que no estaba usando correctamente la cache, la estaba utilizando pero no todo lo que le marcamos y como tras muchas pruebas de cambio de drivers, parámetros etc… no conseguíamos mucho más, decidimos probar con qcow2 transformando el disco de dicha máquina en qcow2 (Hagan una copia de seguridad antes)

Apagamos la máquina y agregamos un segundo disco qcow2 pequeño para que tarde poco, cuando hagamos la conversión y lo volvamos a unir cogerá el tamaño del disco que tengamos.

Quitamos la protección de máquina en opciones

Despegamos ambos discos

Vamos a la consola de uno de los nodos y nos situamos en el directorio de la máquina dentro del brick de Gluster y convertimos el disco con qemu-img convert -f raw -O qcow2 disco.raw disco.qcow2

Dependiendo de los datos del disco tardará más o menos y una vez terminado lo volvemos a pegar editando dicho disco que aparecerá sin uso en la pestaña de hardware activando write back como aparece en la imagen.

Una vez hecho arrancamos la máquina y realizamos las mismas pruebas

Como pueden observar ahora si está haciendo un buen uso de la cache y el rendimiento ha aumentado de forma abismal. Una vez comprobado que la máquina va perfecta pueden eliminar el disco raw que aparecerá sin uso en las opciones hardware y volver a activar la protección.

Este cambio no solo ha mejorado el rendimiento de la máquina si no también el rendimiento del hypervisor ya que cuando teniamos máquinas con tipo raw las gráficas de retardo de proxmox I/O podían dispararse hasta a un 50% mientras que ahora está en unos valores constantes buenos para nuestro escenario no superando un 6%

Por lo tanto podemos decir que raw en Proxmox con GlusterFS y raid por software no es para nada lo mejor, es un cuello de botella.

Y que con 3 nodos sin cabinas de discos hemos conseguido una plataforma con HA decente.

Compartir esta entrada

Dejar un Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*