lvmcache

con lvm cache sobre el ssd se sacan 100MB/s

sobre el HD se saca una velocidad semejante, y sobre el SSD se baja hasta 60 (!!!)

 

…algo no esta funcionando como debiera…

maƱana pruebas desde live-cd para ver tiempos. El caso es que una instalacion sobre SSD (solo SSD) funciona a la velocidad esperada.

update 20160428

pruebas con ubuntu desktop 16.04: el test estandar (dd) sobre el SSD, 80MB/s; sobre el HD, 105MB/s

pruebas con ubuntu desktop 14.04: el test estandar (dd) sobre el SSD, 63 MB/s; sobre el HD, 104MB/s

luego, no es algo de la version de ubuntu… sera algo de la configuracion de la BIOS? algo que por casualidad esta diferente en el segundo servidor???

opciones posibles en la BIOS:

Advanced Options – Drive Write Cache – (de “disabled” a “enabled”)

otras:

System Options – Processor Options – No-Execute Memory Protection – (de “enabled” a “disabled”)

con ubuntu 14.04, HD: 104MB/s; SSD: 63MB/s

šŸ™

probando con el segundo SSD de 250GB, solo en el blade, 14.04 live-cd: 97MB/s

conclusion, el disco que va lento es el unico que va lento. El resto se comportan con normalidad….

img_20160428_160510.jpg

lvm cache, primeras conclusiones

la prueba es sencilla, dd:

dd if=/dev/zero of=ficher2.img conv=fdatasync bs=384k count=20k

el escenario: un servidor con dos discos, uno mecanico y el otro ssd. el sistema instalado en sda (el mecanico) sobre un lvm llamado sistema, en un vg llamado vg01, y sdb sin usar (el ssd)

haciendo copia de un fichero al disco, la velocidad es 52MB/s

para montar el LVM cache, hacemos un pool de lvms en el ssd, un lvm para cache y otro para metadatos (de un tamaƱo /1000 del de la cache). Si el VG original es data:

pvcreate /dev/sdb
vgextend vg01 /dev/sdb
lvcreate -n DataLVcache -L1200G vg01 /dev/sdb
lvcreate -n DataLVcacheMeta -L200M vg01 /dev/sdb
lvconvert --type cache-pool --cachemode writeback --poolmetadata vg01/DataLVcacheMeta vg01/DataLVcache
lvconvert --type cache --chunksize 512K --cachepool vg01/DataLVcache vg01/sistema

Para ver la situacion de la cache,

lvs -a0

Para eliminar la cache,

lvremove vg01/DataLVcache

En este escenario la velocidad es de 172MB/s, muy proxima a los 177 que teniamos con el SSD SOLO.

 

pero despues de un rato haciendo escrituras el sistema muestra una cierta inestabilidad, tiempos de espera elevados. (!)

update 20160425

otros problemas:

  • errores en la bios. aleatorios.
  • los discos que use el viernes han perdido el boot (!). El problema es que en el initrd no hay modulos relacionados con dmcache, y no es capaz de desplegar el root filesystem, ni aun con el /boot en una particiĆ³n separada y no cacheada. Es un error documentado desde hace un aƱo que parece ser que en 16.04 no se ha resuelto… Una guia para resolverlo:

al eliminar un disco, sigue apareciendo como pv. PAra eliminarlo:

vgreduce –removemissing –force vg01

pero necesitamos tener check_cache, que se encuentra en el paquete thin-provisioning-tools

los dos tutoriales sobre la incidencia de reinicio e initramfs no encuentra el lvmcache. Pendientes de probar…

en realidad no necesitamos que todo el disco este en cache, solo la jerarquia donde van a ir las imagenes de nova… solo /var/lib/nova/

luego el plan seria:

1 HD de 2TB, con boot (20MB), swap (8GB), /(20GB), y /var/lib/nova(el resto) en particiones separadas

1 SSD de 250GB como cache de /var/lib/nova (250Mb de metadata, y 249GB de data cache)

un lvm para /, con 20GB

un lvm para /var/lib/nova, con el resto del espacio disponible.

el cache ocupando toda la SSD, sobre el lvm de /var/lib/nova

 

….

warning despues de montado, sobre chunksize. Solucionado con:

lvcreate -H --chunksize 512K -L1.5T   --name data  vg/cpool

ansible, principios de diseƱo

  • Have a dead simple setup process and a minimal learning curve
  • Manage machines very quickly and in parallel
  • Avoid custom-agents and additional open ports, be agentless by leveraging the existing SSH daemon
  • Describe infrastructure in a language that is both machine and human friendly
  • Focus on security and easy auditability/review/rewriting of content
  • Manage new remote machines instantly, without bootstrapping any software
  • Allow module development in any dynamic language, not just Python
  • Be usable as non-root
  • Be the easiest IT automation system to use, ever.