20 diciembre 2015

VMware Photon OS & Docker

Photon Os es una "technology preview" (TP) de una version open source de Linux de tamaño mínimo y que ha sido diseñado para ser puesto en marcha en minutos y poder desplegar contenedores.

Podéis descargaros las version del siguiente enlace donde hay documentación para poder desplegar la OVA en VMware Fusion (nos sirve incluso Workstation o VMware player gratuito) y vSphere 5.5 y 6, vCloud Air e incluso Google Compute Engine.  http://vmware.github.io/photon/


En los videos se muestra como una vez descargada la ISO de la TP1 con Docker 1.5 podemos actualizarlo a Docker 1.9.1 para beneficiarnos de todas sus ventajas.
Enlaces de las ISOs: https://bintray.com/vmware/photon/iso/view

Despliegue de Photon OS:




Actualización de Docker 1.5 a Docker 1.9.1:




Lineas de comando empleadas:
-descargar Photon OS TP1 y TP2: https://bintray.com/vmware/photon/iso/1.0TP1/view
-verificar version de Photon Os TP: cat /etc/*-release
-descargar Docker update: https://get.docker.com/builds/Linux/x86_64/docker-1.9.1.tgz
-update:
tar xzvf ./docker-1.9.1.tgz
sudo mv /usr/bin/docker /usr/bin/docker_old
sudo mv ./usr/local/bin/docker /usr/bin/docker


Enjoy!

09 diciembre 2015

Rightsize, Rightsize, Rightsize...

     ¿Rightsize? Si, cada dia es mas frecuente encontrarse con problemas de performance y de gestion de las conocidas como Monster VMs por una asignacion indebida de recursos a una maquina virtual, como si de un entorno fisico se tratase, aun sabiendo que posiblemente todos esos recursos no están correctamente aprovechados, ni siquiera la aplicacion esta diseñada para ello.

"No por asignar mas recursos a una VM se conseguirá mas performance, incluso puede producirse el efecto contrario"

     Es muy importante dedicar tiempo a realizar un dimesionamiento de las aplicaciones correcto, no solo para un uso mejor de los recursos del entorno de virtualizacion si no de la propio rendimiento de la VM y de las aplicaciones que en corran sobre ella.

     El ejemplo mas sencillo lo tenemos con el crecimiento scale-in (vertical, tambien conocido como scale-up) y el crecimeinto scale-out (horizontal)


     En un crecimiento scale-in debemos tener claro que las aplicaciones y el SO seran capaces de aprovechar la asignacion de mas memoria y CPU lo que posiblemente nos obligue a realizar modificaciones, por ejmeplo, en JAVA, si agregamos mas memoria RAM a la VM, deberiamos tocar los parametros de asignacion de la JVM, de lo contrario, la JVM seguiria disponiendo de la misma RAM que antes de su aumento.


     En un crecimiento scale-out, si conseguimos definir un building-block en la cual una VM con uan configuracion determinada de RAM y CPU, soporte por ejemplo un carga especifica de usuarios, ante eventos de crecimiento de demanda, sera mas sencillo desplegar desde la plantilla del building block tantas VMs como sean necesarias para soportan la nueva demanda, ahorrando ademas en tiempos de reconfiguracion y despliegue.

     Que se conseguimos con VMs mas pequeñas: al tener menos vCPU en estado iddle, el rendimeinto de una VMs en mas eficiente, reduciendose los valores de CPU Ready, CPU Wait y Co-Stop en la mayoria de las ocasiones (tendieno en cuenta que se realize un overcommit de los recursos del host ESXi de forma adecuada)

     A todo esto podemos añadirle las facilidades de getion de una VM mas pequeña e incluso poder protegerla con Fault Tolerace de VMware con tiempo de caida cero (downtime=0) que desde la version ESXi6 soporta ya 4 vCPU y hasta 64GB de RAM por VM protegida, unicamente hay un maximo de 8 vCPU protegidas por host ESXi lo que nos permite varias combinaciones.

    Como detalle a configurar para nota,  recordad cambiar en las BIOS de los host ESXi el performance en nivel HIGH, los valores balanced o low impactan negativamente en el rendimiento de las VM (en la mayoria de los servidores viene en modo balanced configurado de fabrica)

Rightsize, Rightsize and Rightsize