Vector: herramienta de monitorización en tiempo real de Netflix

Hace unos días Netflix liberaba la herramienta que utilizan internamente para analizar el rendimiento de sus instancias: Vector. Esta herramienta no deja de ser una aplicación web que se conecta a la API de PCP para obtener las métricas. PCP es un demonio que se instala en cada una de las instancias o servidores que se quiere monitorizar.Sigue leyendo «Vector: herramienta de monitorización en tiempo real de Netflix»

Configurar NTP en Red Hat 7

Estoy empezando a montar servidores con Red Hat 7 y hay muchas cosas nuevas. Una de ellas ha sido el servicio de NTP, que deja e ser controlado por el demonio ntpd. Ahora el servicio es Chrony. Si no lo sabes es posible que estés un rato intentando configurando el ntpd y tras reiniciar el servidor lo encuentres parado.

[root@jupiter ~]# systemctl status ntp

ntpd.service - Network Time Service

Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)

Active: inactive (dead)

Viendo como esta definido el servicio chronyd vemos que es incompatible con el servicio ntpd. Por tanto deberemos elegir entre uno u otro:

[root@jupiter ~]# more /usr/lib/systemd/system/chronyd.service [Unit] Description=NTP client/server After=ntpdate.service sntp.service ntpd.service Conflicts=ntpd.service

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/chronyd
ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS
ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers

[Install]
WantedBy=multi-user.target

Tras reiniciar el servidor este servicio arranca al estar habilitado y no tener incompatibilidades con otros servicios :

[root@jupiter ~]# systemctl status chronyd
chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
Active: active (running) since jue 2015-04-23 14:29:00 CEST; 1min 52s ago
Process: 2257 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers (code=exited, status=0/SUCCESS)
Process: 2250 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 2254 (chronyd)
CGroup: /system.slice/chronyd.service
└─2254 /usr/sbin/chronyd -u chrony

El fichero de configuración es el siguiente:

[root@jupiter ~]# more /etc/chrony.conf
# These servers were defined in the installation:
server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst

stratumweight 0

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Enable kernel RTC synchronization.
rtcsync

# In first three updates step the system clock instead of slew
# if the adjustment is larger than 10 seconds.
makestep 10 3

# Listen for commands only on localhost.
bindcmdaddress 127.0.0.1
bindcmdaddress ::1

keyfile /etc/chrony.keys

# Specify the key used as password for chronyc.
commandkey 1

# Generate command key if missing.
generatecommandkey

# Disable logging of client accesses.
noclientlog

# Send a message to syslog if a clock adjustment is larger than 0.5 seconds.
logchange 0.5

logdir /var/log/chrony

En la documentación de Red Hat nos recomiendan en que casos usar un demonio u otro:
– En sistemas que se reinicien a menudo o que entren en hibernación recomiendan utilizar Chronyd.
– En sistemas que estén permanentemente encendidos recomiendan utilizar Ntpd.
Según cada caso instalaremos uno u otro, pero no los dos.

Para más información:

1. Documentación oficial de Red Hat
2. http://www.certdepot.net/rhel7-set-ntp-service/

Seguimiento en tiempo real de los vuelos en aerolíneas

En los últimos días han aparecido en los medios locales noticias sobre el estreno del nuevo OCC de Air Europa. En las noticias lo más destacado parece haber sido el seguimiento en vivo y tiempo real que se hacen de los aviones, y más después de las recientes catástrofes aéreas y desapariciones.

Air Europa inaugura en Llucmajor un nuevo centro de operaciones

Dicho seguimiento se realiza con la aplicación Aircom Server de SITA y ha sido un proyecto en el que estuve involucrado desde el principio y del que me siento muy orgulloso.

Air Europa seguirá en tiempo real los 46 aviones de su flota desde su sede central

Este programa tiene múltiples funcionalidades entre las que se pueden destacar las siguientes:
– Envío de mensajes tipo TELEX a y desde los aviones. Sirve como gateway para otros sistemas de mensajería como el e-mail.
– Conexión con varías fuentes para obtener información meteorológica: vientos, tormentas, nubes volcánicas, etc.
– Información en tiempo real de las rutas de los aviones, permitiendo comparar desviaciones con los planes de vuelo.
– Al saber exactamente las rutas y tener información meteorológica se pueden optimizar las rutas permitiendo ahorros en tiempo y combustible haciendo los vuelos más eficientes.

Este sistema tiene conexión con varios sistemas de geolocalización. El ultimo que se integró es el servicio que proporciona FlightAware. Para la geolocalización, se utiliza entre otros el sistema ADS-B que se basa en la transmisión por radio de la posición de los aviones a pequeños receptores conectados a través de Internet al servicio de FlightAware. Con sistemas como estos la investigación de catástrofes como la desaparición del avión de Air Asia hubiese sido mas fácil. La instalación de estos transmisores en los aviones será obligatoria en Europa a partir de 2017 pero ya son muchos las aerolíneas que lo tienen implementado.

Los receptores los puede tener instalado cualquiera, de hecho existen proyectos para montar un receptor en una Rapsberry Pi. También se pueden solicitar en la web de FlightAware y en función de la cobertura en el punto donde se va a instalar te lo envían gratis.

Selection_059La información que se puede obtener con estos receptores es sorprendente y se reciben reportes de los aviones que están en un radio de hasta 200Km. En los acercamientos a los aeropuertos, donde hay muy buena cobertura para el sistema la precisión es muy exacta:

Selection_060Selection_061
A modo de resumen se puede decir que es una herramienta muy útil en los departamentos de operaciones de las aerolíneas y estos tipos de sistemas deberían ser obligatorios. Además me pregunto el potencial que podría llegar a tener si tuviera alguna licencia Open Source, estoy convencido que la comunidad haría auténticas maravillas.

Compilar PHP de 32 bits en Red Hat de 64 bits

Por una incopatibilidad entre aplicaciones he tenido que compilar la última versión de PHP en un servidor de 64 bits. El proceso es bastante sencillo si se tienen correctamente instaladas las librerias de 32 bit en el sistema. 

En este sistema ya tenia una serie de librerias de 32 bits instaladas, pero ha sido necesario instalar algunas mas para poder compilar correctamente. En concreto, las que hacian falta eran:

libstdc++-devel.i686
glib2.i686
zlib-devel.i686

Para instalarlas se puede hacer con yum.
Descargar el codigo fuente de la última versión de php desde la web de php.net en el servidor. Una vez verificado el MD5 procederíamos a descomprimir el código fuente en /var/tmp:

# md5sum php-5.6.4.tar.bz2
d31629e9c2fb5f438ab2dc0aa597cd82 php-5.6.4.tar.bz2
# tar xjvf php-5.6.4.tar.bz2

Una vez en la carpeta del codigo fuente exportaremos las variables CFLAGS, CXXFLAGS y LDFLAGS donde indicaremos que la arquitectura sobre la que se debe compilar es de 32 bits:

# export CFLAGS=’-m32′
# export CXXFLAGS=’-m32′
# export LDFLAGS=’-m32′

Si ya habíamos intentado compilar deberemos ejecutar un «make clean» y a continuación configurar la compilación:

# ./configure –libdir=/lib  –prefix=/usr/local/php-5.6.4 –with-libdir=/lib

Este proceso finaliza con la recomendación de ejecutar un test antes del install, con lo que ejecutaremos lo siguiente:

# make test && make install

Al finalizar la compilación la nueva versión de PHP quedará instalada en /usr/local/php-5.6.4 y veremos que es un binario de arquitectura de 32 bits:

# pwd
/usr/local/php-5.6.4/bin
# ./php -v
PHP 5.6.4 (cli) (built: Dec 23 2014 11:43:42)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
# file php
php: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

El servidor web se deberá configurar para que apunte a este binario.
Una vez sabemos que compila se debería recompilar con las opciones de configuración que sean necesarias en cada caso (módulos y extensiones).

#TIP

Como he comentado anteriormente, este sistema ya tenia una serie de librerias de 32 bits instaladas:

zlib.i686
libstdc++-devel.i686
libxcb.i686
libaio.i686
libXtst.i686
libstdc++.i686
libzip.i686
libXau.i686
libXi.i686
libxml2-devel.i686
glibc-devel.i686
gamin.i686
nss-softokn-freebl.i686
libXext.i686
compat-libstdc++-33.i686
glibc.i686
libselinux.i686
glib2.i686
zlib-devel.i686
libuuid.i686
libxml2.i686
libgcc.i686
libX11.i686
libaio-devel.i686
libXrender.i686
libzip-devel.i686
compat-libcap1.i686
libXp.i686

Para instalarlas todas con un comando lo que se puede hacer es copiar el listado en un fichero e instalarlo con yum de la siguiente manera:

# vi /tmp/paquetes
# yum install $(cat /tmp/paquetes)

Nginx como proxy inverso con SSL

Hace unos días me plantearon la necesidad de publicar en Internet u servicio que estaba corriendo sin ningún tipo de encriptacion, con lo que los passwords se estaban transmitiendo en claro.
Dándole vueltas encontré este tutorial donde se exponía un caso similar con la aplicación Jenkins:
(por cierto, muy buena la página de tutoriales de Digital Ocean)

La idea de este tutorial es la de montar un nginx delante del servicio que se quiere securizar de forma que encripte las comunicaciones que van por la red publica. Esta configuración se conoce como «reverse proxy» y el diagrama seria el mostrado a continuación:

Instalación de nginx

Para instalar nginx descargaremos el rpm ccorrespondiente desde la web del proyecto Nginx . Éste rpm nos configurara el repositorio lo que nos permitira instalarlo con yum:

[root@nginxprxy tmp]# yum -y install nginx-release-rhel-6-0.el6.ngx.noarch.rpm [root@nginxprxy tmp]# yum install -y nginx

Configuración del proxy reverso con ssl 

Como este servidor va a servir exclusivamente para la securización de un servicio no seguro editaremos el fichero de configuración default.conf. Lo deberemos dejar de la siguiente forma:
[root@nginxprxy tmp]# cd /etc/nginx/conf.d 
[root@nginxprxy conf.d]# cat default.conf 
server {
 listen 80;
 return 301 https://$host$request_uri;
}


# HTTPS server
#
server {
 listen 443;
 server_name service.enterprise.com;

 ssl_certificate           /etc/nginx/certs/service.enterprise.com.crt;
 ssl_certificate_key       /etc/nginx/certs/service.enterprise.comm.key;

 ssl on;
 ssl_session_cache  builtin:1000  shared:SSL:10m;
 ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
 ssl_prefer_server_ciphers on;

 access_log            /var/log/nginx/service.access.log;

 location / {

  proxy_set_header        Host $host;
  proxy_set_header        X-Real-IP $remote_addr;
  proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header        X-Forwarded-Proto $scheme;

# Fix the “It appears that your reverse proxy set up is broken" error.
  proxy_pass          http://unsecureservice.enterprise.com;
  proxy_read_timeout  90;

  proxy_redirect      http://unsecureservice.enterprise.com https://service.enterprise.com;
 }
}
En la primera parte, se redigirán todas las peticiones a la misma URL pero al puerto de HTTPS. Así, cualquier petición al puerto por defecto de HTTP será redirigida, sin posibilidad de servir contenido que no esté cifrado.
En la segunda parte, es donde se especifica el puerto de escucha HTTPS, los certificados y varias opciones del protocolo SSL. 

Por último se establecen las reglas de redirección del proxy de forma que todo lo que entre a través de la URL https://service.enterprise.com; lo redirija a la http://unsecureservice.enterprise.com.

Antes de arrancar el servidor deberemos conseguir los certificados. Lo primero será generar el CSR en el directorio que hemos especificado en el fichero de configuración:

[root@nginxprxy tmp]# cd /etc/nginx/
[root@nginxprxy tmp]# mkdir certs
[root@nginxprxy certs]# openssl req -new -newkey rsa:2048 -nodes -keyout service.enterprise.com.key -out service.enterprise.com.csr
Generating a 2048 bit RSA private key
……………………………………….+++
…+++
writing new private key to ‘service.enterprise.com.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [XX]:XX
State or Province Name (full name) []:XXXX
Locality Name (eg, city) [Default City]:XXXX 
Organization Name (eg, company) [Default Company Ltd]:XXXX
Organizational Unit Name (eg, section) []:XXXX
Common Name (eg, your name or your server’s hostname) []:service.enterprise.com
Email Address []:XXXX@enterprise.com

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Una vez obtengamos el certificado deberemos crear el fichero crt con el contenido del certificado: 

[root@nginxprxy certs]# vi service.enterprise.com.crt  —–BEGIN CERTIFICATE—– MIIFWjCCBEKgAwIBAgIDCmMEMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVT…8WjFirPK7+2Gbq+9w4DpJ+a5FJjTOKfcRvIrZION 

—–END CERTIFICATE—–

Será el momento de arrancar el servidor Nginx y probar la conexión desde un navegador, donde deberemos ver que inmediatamente se redirecciona a un puerto seguro y que el certificado es válido:

[root@nginxprxy conf.d]# service nginx stop Stopping nginx: [FAILED] [root@nginxprxy conf.d]# service nginx start  Starting nginx: [ OK ]

Conseguir Root en OnePlus One

Ayer me llegó el OnePlus One y después de utilizarlo un rato y acostumbrado a tener acceso root en mi anterior móvil me decidí a rootearlo para poder bloquear anuncios y utilizar el Greenify. El proceso es muy sencillo y se puede dividir en tres partes: Desbloquear el bootloader, instalar el recovery y instalar el SuperSU.

Como prerequisito para todo el proceso será necesario tener las utilidades fastboot y ADB en el PC que vayamos a utilizar. Para instalar las android tools en ubuntu podemos hacerlo desde los repositorios de ubuntu (fastboot y adb) con el siguiente comando:

$ sudo apt-get install android-tools-fastboot android-tools-adb

Vayamos ya con el proceso de rooteo.

1. DESBLOQUEAR EL BOOTLOADER

Debemos activar el modo Depuración. Para ello habilitaremos primero las opciones de desarrollo. Iremos a Ajustes-> Información del teléfono y tocaremos 7 veces en compilación. Una vez habilitado en el menú principal de los ajustes nos saldrá la opción «opciones de desarrollo». Una vez dentro habilitaremos el debug de USB en el teléfono dejándolo como en la siguiente imagen:

Habilitar la opción de Depuración

Conectaremos el teléfono al ordenador con el cable USB y desde una terminal reiniciaremos en modo «fastboot»:

$ adb reboot bootloader

Una vez en modo «Fastboot» verificar que el PC vea el dispositivo con el comando «sudo fastboot devices«. El comando nos devolverá el número de serie del teléfono. En el modo fastboot en la pantalla aparece el logo de OnePlus y un texto con el mensaje fastboot.

Desde el mismo terminal desbloquear el bootloader:

$ sudo fastboot oem unlock
…
OKAY [ 0.005s]
finished. total time: 0.005s

NOTA: En este paso se borran todos los datos del teléfono. Haz una copia de seguridad de lo que necesites antes.

A continuación el teléfono se reiniciará, aparecerá un Android ejecutando el proceso y finalmente se vuelve a reiniciar.

Será necesario volver a habilitar el debug de usb para continuar con la instalación del recovery.

2. INSTALAR RECOVERY

Antes de instalar el nuevo recovery deshabilitaremos la opción «Actualizar recovery de CM» para que no nos lo machaque la próxima vez que arranque el teléfono. Esta opción esta en las opciones de desarrollo:

Deshabilitar la opción «Actualizar recovery de CM»

Descargaremos la última imagen correspondiene para el OnePlus desde la URL:

http://techerrata.com/browse/twrp2/bacon

En mi caso he descargado la siguiente imagen:

http://techerrata.com/file/twrp2/bacon/openrecovery-twrp-2.8.0.1-bacon.img

Filename: openrecovery-twrp-2.8.0.1-bacon.img

MD5sum: d03de30d110d0075a2a6c5cf5f2706a2

Verficaremos el MD5 por seguridad, ya que si instalamos una imagen dañada el teléfono no arrancaría:

$ md5sum openrecovery-twrp-2.8.0.1-bacon.img
d03de30d110d0075a2a6c5cf5f2706a2 openrecovery-twrp-2.8.0.1-bacon.img

Vemos que el MD5 corresponde con el publicado en la web, con lo que procederemos a reiniciar en modo «Fastboot»:

$ adb reboot bootloader

Otra vez verificaremos que el PC vea el dispositivo con el comando «sudo fastboot devices«. En caso correcto grabaremos la imagen del nuevo recovery (tarda apenas unos segundos):

$ sudo fastboot flash recovery openrecovery-twrp-2.8.0.1-bacon.img

En la pantalla del teléfono no se aprecia ningún cambio, pero realmente se ha instalado bien si la salida del comando no da errores.
Una vez flasheada la partición de recovery se continua con el arranque con el siguiente comando:

$ sudo fastboot continue
resuming boot…
OKAY [ 0.002s]
finished. total time: 0.003s

Una vez se haya completado correctamente, reiniciar el teléfono en modo recovery para verificar la instalación. Para arrancar en modo recovery con el teléfono apagado pulsar las teclas Volumen-Abajo y la tecla de encendido.

3. ROOTEAR:

Hay que bajar la última versión del fichero UPDATE-SuperSU-v2.37.zip desde http://download.chainfire.eu/supersu y grabarlo en la raíz de la memoria del teléfono.

Una vez el recovery instalado, arrancar en modo recovery con el siguiente comando:

$ adb reboot recovery

Seleccionar «Install» en el TWRP Recovery. Buscar el fichero que hemos copiado e instalarlo.

Reiniciar el teléfono y ahora encontrarás la aplicación SuperSU. Abre la aplicación y si no se obtienen errores el teléfono se habrá rooteado correctamente.

VMware: Mejores prácticas en la sobresuscripción de CPU

Como es bien sabido, una de las ventajas de la virtualización es la de poder asignar mas recursos virtuales de los que realmente disponemos sobre un determinado hardware. Esto hace que el uso de los recursos sea mas eficiente y los aprovechemos mejor. Si bien es posible hacer una sobresuscripción con un ratio elevado, esto nos puede llevar a tener problemas de rendimiento en las máquinas virtuales. He encontrado una guía muy completa donde se establecen algunas mejores prácticas a la hora de dimensionar las máquinas virtuales.

pCPU vs vCPU

Lo primero a tener en cuenta es que se entiende por pCPU y vCPU:
  • pCPU se refiere a las CPU físicas. El número de CPUs físicas presentes en un determinado host depende de varios factores como son el número de sockets, el número de cores y si tiene hiperthreading y está habilitado. 
  • vCPU son las CPU que se asignan a una máquina virtual y no tiene porque está ligado al número de pCPU. Cuando se crea una máquina virtual las vCPU se asignan a una pCPU. Debe haber un número de pCPU disponibles para soportar el número de vCPU asignadas a una máquina virtual o esta no podrá arrancar.

En vSphere 5 el número máximo de vCPU por pCPU es de 25:1. Aunque se recomienda que por temas de rendimiento esta relación no sobrepase el 5:1. No obstante esto siempre dependerá del tipo de carga de trabajo que ejecuten las máquinas virtuales.

    Cuando se supera la relación 1:1 debe entrar en funcionamiento el «scheduler» para distribuir los tiempos de procesador entre las máquinas que lo necesiten.

    A la hora de dimensionar el ratio vCPU:pCPU la guía recomienda seguir dos estrategias:

    1. Empezar con una vCPU en la máquina virtual. Una vez analizada la carga de la máquina virtual ir añadiendo vCPU según la necesidad. Cuando la máquina virtual necesite realizar una operación, esta tendrá que esperar a que haya disponibles un número de pCPU igual al número de vCPU. Con lo que, al añadir mas vCPU se incrementa el riesgo de que el tiempo de espera de pCPU aumente provocando un rendimiento peor.
    2. Como la relación vCPU:pCPU depende de la carga de trabajo, la relación puede ser mayor en hosts que ejecuten máquinas virtuales con necesidades de procesamiento marginal. Por otro lado, en hosts que requieran intensivas cargas de trabajo, el ratio deberá ser inferior.

    Métricas

    Existirán ciertas métricas que nos servirán para determinar si el host está teniendo algún problema de rendimiento y para hacer un uso mas eficiente de los recursos mientras se mantienen las cargas de trabajo.

    • Uso de CPU de la máquina virtual: Se deberán añadir vCPU adicionales cuando el uso medio de CPU se mantenga en altos niveles.
    • CPU Ready en el host: Desde el punto de vista de la salud del host, esta es la métrica mas importante. Esta métrica determina el tiempo que una máquina virtual esta esperando para obtener vCPU disponibles que necesita. Por ejemplo, si una máquina virtual tiene asignadas cuatro vCPU, esta métrica indica el tiempo que una máquina virtual ha esperado para que cuatro pCPU estén disponibles en el mismo instante de tiempo.
    • Uso de CPU del host: permite analizar la carga que está soportando el host.

    En el White paper se establecen estos criterios:

    • Una relación entre 1:1 y 3:1 no provoca problemas
    • Entre 3:1 y 5:1 puede empezar a causar alguna degradación de rendimiento
    • Si la relación es superior a 6:1 se suelen tener problemas.

    Adicionalmente se recomienda que el CPU Ready este por debajo del 5%.

    Calculo del CPU Ready

    Como hemos comentado esta métrica es realmente importante para determinar si estamos teniendo problemas de rendimiento. En el cliente de vSphere esta métrica se representa en segundos, mientras que con un ESXTOP se devuelve en porcentaje.

    Para realizar la conversión debemos tener en cuenta el tiempo de muestreo de la gráfica, 20 segundos en la gráfica de real time. La fórmula será la siguiente:
    (x ms  / 20.000 ms) * 100 = %rdy
    Por ejemplo, con esta formula sabremos que:

    • 1% = 200ms
    • 5% = 1000ms
    • 10% = 2000ms
    • 100% = 20000ms

    Hay que tener en cuenta que estas medidas se dan por vCPU, co lo que una máquina con 4 vCPU podrá llegar a tener un 400% de tiempo de planificación. La misma máquina con un 10% de CPU Ready implicará que cada vCPU tenga un CPU Ready de 2.5%.

    Caso Real

    En el siguiente ejemplo tenemos un host HP Prolian DL580 G7 con 4 CPU octacore y con Hyperthreading activado:

     
    En dicho host hay máquinas virtuales de todo tipo, pero especialmente hay varias «Monster Machines» con hasta 128GB de RAM y 32 vCPU. Como se puede ver en la siguiente gráfica, estas máquinas están sobredimensionadas, ya que el uso de CPU medio es muy bajo:

    Otras tienen un uso de CPU mas elevado, la media en torno al 65%.

    Sin embargo en momentos puntuales llegamos a tener contención y el CPU ready se dispara como podemos ver en esta gráfica donde aparece el acumulado en el host. Esto es debido a que estas máquinas forman parte de un servicio que hace que todas tengan una carga intensiva de CPU en momentos puntuales haciendo que el CPU Ready suba tanto que al final el rendimiento de las máquinas es peor del esperado:

     Como vemos en las gráficas de rendimiento de estas  «Monster Machines», en momentos puntuales el CPU Ready se dispara a la vez, llegando a los 13 segundos:

     
    Según la fórmula de conversión al %rdy esos 13 segundos corresponden a un 65% de CPU Ready. Para la máquina de 32 vCPU es un 2% por CPU y para la máquina de 8 vCPU corresponde a un 8%. Esta última es la que realmente está teniendo un peor rendimiento y la que se vé mas afectada. Lo ideal sería bajar el número de vCPU asignadas a estas máquinas virtuales para adecuarse mas al consumo real que están teniendo.


    Algunos enlaces interesantes respecto a este tema:

    Fallo al arrancar máquinas virtuales despues de migrar oVirt a 3.5

    Recientemente he actualizado una instalación de oVirt de la versión 3.4 a la versión 3.5. El proceso es bastante trasparente y básicamente consiste en actualizar el repositorio y seguir los mismos pasos que durante la instalación. Una vez con la nueva versión podemos actualizar la compatibilidad del cluster que tengamos configurado a la versión 3.5. Para ello es recomendable poner los hosts en mantenimiento. Una vez actualizado se pueden actualizar también los Hosts. Ya con todo actualizado vemos que hay funcionalidades nuevas, como la gestión de memoria con NUMA. 
    Esta funcionalidad puede ser interesante en entornos que requieren un uso intensivo de CPU y Memoria, pero debe estar bien configurado. Si, como en mi caso, tenemos un entorno mas estándar no es necesario configurarlo, pero al intentar arrancar las máquinas de nuevo podemos tener el siguiente error:
    VM compute1 is down with error. Exit message: internal error internal error NUMA memory tuning in ‘preferred’ mode only supports single node.
    Para solucionarlo basta seguir los pasos que se indican en la lista de distribución:
    Resumiendo, hay que editar la máquina virtual que presenta los problemas y acceder a la opción Host:
    Allí veremos que el «Tune Mode» esta deshabilitado y configurado por defecto en «Preferred». Para poder cambiarlo seleccionaremos un host sobre el que correrá esta máquina y deshabilitaremos las migraciones. En ese momento ya podemos seleccionar la opción «Interleave» como «Tune Mode»:
    Una vez cambiado podemos volver los parámetros por defecto. Una vez aplicados podremos arrancar la máquina

    Agilizando la Infraestructura IV: Trabajando con oVirt

    En el post anterior vimos como instalar y configurar oVirt dejándolo preparado para el despliegue de máquinas virtuales. En este post explicaré como configurar el repositorio de imágenes ISO, de forma que podamos arrancar una máquina virtual y asignarle una imagen de instalación por ejemplo. A continuación veremos como integrarlo con Foreman de forma que el despliegue de las máquinas virtuales lo hagamos desde Foreman como si fuese una máquina física.

    Repositorio de imágenes

    Durante la instalación se ha creado un Storage Domain que debemos configurar y que aparece como «Unattached». Al seleccionarlo, en la consola inferior seleccionamos la pestaña «Data Center» y a continuación lo activamos con el boton de «Attach»:

    A continuación nos aparecerá una ventana donde indicaremos al «Data Center» donde lo queremos añadir, en nuestro caso, al solo tener uno no tendremos mas opción:

    En este punto ya podremos subir imágenes. No he encontrado otra forma de subirlas, y al parecer hay que hacerlo desde la línea de comandos con la herramienta engine-iso-uploader:


    [root@ovirt ~]# engine-iso-uploader upload -i ISO_DOMAIN /var/lib/exports/iso/ubuntu-14.04-desktop-amd64.iso
    Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort):
    Uploading, please wait…
    INFO: Start uploading /var/lib/exports/iso/ubuntu-14.04-desktop-amd64.iso  

    A los pocos minutos la imagen estará subida y disponible para añadirla a alguna máquina virtual. Así mismo, podemos ver el listado de imágenes que tenemos subidas desde la interfaz web:

    Integración con Foreman

    La integración con Foreman es bidireccional. Por una parte una vez integrado, desde Foreman, seremos capaces de provisionar máquinas virtuales y aplicarle las clases que hayamos definido como si de una máquina física se tratara. Por otro lado, desde oVirt, podremos acceder al inventario de máquinas de Foreman para el caso de que quisieramos añadir mas hosts, por ejempo.
    Para el primer caso, desde la consola de Foreman accederemos al menú «Infraestructure/Compute Resources» y configuraremos la URL de la API de oVirt. También deberemos especificar el usuario administrador y su password. Finalmente probaremos la conexión para poder obtener el certificado e importarlo:
    Para la integración en el otro sentido, desde la consola de oVirt añadiremos en este caso la URL de la API de Foreman desde la rama «External Providers» y con el botón de «Add»:

    Creación de máquinas virtuales

    Para la creación de máquinas virtuales podríamos seguir el método clásico de crear una nueva máquina e instalarle el sistema operativo desde el CD que le hayamos asignado. Sin embargo, aprovechando que tenemos nuestra instalación de Foreman, realizaremos el aprovisionamiento de las máquinas virtuales con el.
    En la interfaz de Foreman, iremos a añadir un nuevo Host, y tras ponerle el nombre y asignarle el Host Group le pondremos que el despliegue se realice sobre oVirt. Esta opción se ha habilitado gracias a la integración que hemos configurado anteriormente. Veremos además que aparece una nueva pestaña de «Virtual Machine» donde podremos configurar parámetros específicos:

    En la pestaña «Virtual Machine» le asignaremos los recursos que queremos que tenga nuestra máquina virtual: número de cores y memoria. También deberemos añadirle una interfaz de red y uno o mas discos, marcando que uno de ellos sea bootable:

    En este punto ya veremos en la interfaz de oVirt que se ha creado una nueva máquina con el nombre que le hemos especificado y empezará la instalación de la misma.
    Para poder ver la consola, desde Ubuntu deberemos instalar el paquete virt-viewer. Al acceder a la consola con Firefox nos pedirá con que programa abrirlo, a lo que deberemos seleccionar «Remote viewer»

    julian@ubuntu:~$ sudo apt-get install virt-viewer