New life, new blog!

I was meaning to do this for a long time, but not it seems that I managed to get it done. I've now migrated my blog from Wordpress to Nikola - and while I'm on it, I've decided to start blogging in English ;-)

The migration itself is still a work in progress but the old content should be there. Nikola has an almost by-default configuration and will take some more time to get it finished but I guessed it'd be better to start small and make small improvements than not migrating at all... so in the meantime please bear with me.

Also I've changed domains as well. My old bofh.es domain will be configured to redirect to the new one, frangarcia.me .

Happy hacking!

Camino al RHCA... y más allá

Por fin he recibido mi nota del último examen y finalmente... he aprobado, lo que significa que ya cumplo los requisitos para acceder a Red Hat Certified Architect. Por otra parte, debo ser de las pocas personas que, aprobando un examen EX300 de RHCE, le han dado una certificación de RHCA ;-)

Han sido unos cuantos años divertidos de andar haciendo exámenes y aprendiendo cosas, y me lo he pasado muy bien en este tiempo. La parte buena es que la diversión no se acaba y puedo continuar con el resto del programa RHCA y sus nuevas concentraciones (tracks) orientadas a datacenter y cloud.

¡Mola! :D

Camino al RHCA: RHEV (EX318)

Parecía un poco raro haber completado la certificación de Red Hat Openstack sin haber hecho antes la de su 'hermano pequeño', Red Hat Enterprise Virtualization (RHEV).

Así que me puse manos a la obra, y tras algunas peripecias de exámenes cancelados por parte de Red Hat, por fin pude presentarme al EX318. En mi caso hice la preparación usando el proyecto upstream, oVirt en su versión 3.5 .

Para montar un laboratorio medianamente útil, será necesario :

  • Una VM para montar un servidor IPA, DNS, NTP (1CPU, 1GB RAM)
  • Una VM para montar un servidor RHEV/oVrt (2CPU, 4-8 GB RAM)
  • Hosts en los que desplegar las máquinas virtuales. Si eres amante de las aventuras, se pueden instalar mediante virtualización anidada (nested virtualization), tanto en KVM como en Vmware vSphere.
  • (Opcional) Una VM para hacer de servidor de almacenamiento NFS & iSCSI.

Como siempre, en la web de Red Hat tenemos disponibles los objetivos del examen.

De cara al examen es muy importante tener encuenta el tiempo asignado a cada ejercicio y no pararse en exceso en una parte concreta si no sale a la primera.

Happy hacking :-)

Actualizar herramientas de HP con VUM

Después de muchos años administrando ESXi sobre servidores HP, nos hemos dado cuenta de un pequeño truco que permite actualizar de forma mucho más fácil las herramientas para administrarlos y monitorizarlos correctamente.

Basta con añadir la siguiente URL como origen de parches en la configuración de VMware Update Manager (VUM) para que todas las actualizaciones de paquetes se instalen al mismo tiempo que el resto de parches del hipervisor. Del mismo modo, esto sirve para

La URL a añadir es:

http://vibsdepot.hpe.com/index.xml

Es muy importante acordarse de que es index.XML ; si no, la descarga de actualizaciones no funcionará.

Igualmente hay un documento bastante interesante que describe algunas opciones más, incluyo una copia local (que ya sabemos cómo de fácil y buena es la web de HP).

Happy hacking!

Máquina del tiempo con btrfs y snapper

Llevaba bastante tiempo buscando un método "más rápido" de poder realizar mis copias de seguridad. Aunque sigo usando el método que mencionaba en artículos anteriores de hacer tars con pigz, para las copias incrementales del día a día era matar moscas a cañonazos.

Así que nada, un día me compré un disco externo adicional y decidí poner en funcionamiento 3 cosas que tenía por probar:

  • Cifrado completo de disco/partición con LUKS.
  • El filesystem btrfs
  • Los checks de integridad de btrfs (scrub)
  • La compresión y los snapshots de btrfs

Estos son los resultados:

Después de particionar el disco, inicializarlo con LUKS y crear el filesystem btrfs, podemos ver la estructura con lsblk:

$ lsblk 
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
[...]
sdb                                             8:16   0   1.8T  0 disk  
├─sdb1                                          8:17   0     1T  0 part  /run/media/fran/wd20ntfs
└─sdb2                                          8:18   0 837.6G  0 part  
  └─luks-0aad2fa7-f2c9-4acb-81f5-xxxxxxxxxxxx 253:5    0 837.6G  0 crypt /run/media/fran/wd20brtfs

Con btrfs obtenemos algo más de información sobre el filesytem:

$ sudo btrfs subvolume list -puta /run/media/fran/wd20btrfs/ 
ID      gen     parent  top level       uuid    path
--      ---     ------  ---------       ----    ----
257     944     5       5               75a8331b-9cd3-0d46-b773-9aaba88b6369    root
514     950     5       5               c767358c-83e0-134f-9698-2ae535742284    backup
556     951     514     514             54f942af-31e7-6e4c-ae4a-691d4642ddfd    <FS_TREE>/backup/.snapshots
558     828     556     556             add72c57-3f1b-a143-8902-cc0242e971bf    <FS_TREE>/backup/.snapshots/2/snapshot
559     841     556     556             9e6e71aa-8ddc-ee44-a0cc-628ab659c544    <FS_TREE>/backup/.snapshots/3/snapshot
560     848     556     556             fc44d63a-393d-294e-b868-6d12c9e5515f    <FS_TREE>/backup/.snapshots/4/snapshot

snapper es una herramienta desarrollada por SUSE que permite automatizar la creación de snapshots btrfs. Originalmente estaba pensada para dar la característica de rollback en caso de querer dar marcha atrás una actualización del sistema, pero es suficientemente potente para poder encargarse también de otros discos de datos.

$ sudo btrfs subvolume show /run/media/fran/wd20btrfs/                                                   
/run/media/fran/wd20btrfs is btrfs root

$ sudo btrfs subvolume show /run/media/fran/wd20btrfs/backup/
/run/media/fran/wd20btrfs/backup
    Name:                   backup
    uuid:                   c767358c-83e0-134f-9698-2ae535742284
    Parent uuid:            -
    Creation time:          2015-01-20 22:03:20
    Object ID:              514
    Generation (Gen):       950
    Gen at creation:        202
    Parent:                 5
    Top Level:              5
    Flags:                  -
    Snapshot(s):
                            .snapshots/2/snapshot
                            .snapshots/3/snapshot
                            .snapshots/4/snapshot
                            .snapshots/5/snapshot

$ btrfs filesystem df /run/media/fran/wd20btrfs
Data, single: total=119.01GiB, used=118.45GiB
System, DUP: total=8.00MiB, used=32.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=2.50GiB, used=1.70GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=512.00MiB, used=0.00B

$ sudo btrfs scrub status -d /run/media/fran/wd20btrfs/
scrub status for 7bb1d318-c7a9-40d8-995a-972a9d43544f
scrub device /dev/mapper/luks-0aad2fa7-f2c9-4acb-81f5-5197751fee3e (id 1) status
scrub started at Fri Apr 17 21:48:08 2015, running for 25 seconds
total bytes scrubbed: 847.03MiB with 0 errors

$ sudo btrfs scrub status -d /run/media/fran/wd20btrfs/
scrub status for 7bb1d318-c7a9-40d8-995a-972a9d43544f
scrub device /dev/mapper/luks-0aad2fa7-f2c9-4acb-81f5-5197751fee3e (id 1) history
scrub started at Fri Apr 17 21:48:08 2015 and finished after 3460 seconds
total bytes scrubbed: 121.84GiB with 0 errors

$ sudo btrfs prop list /run/media/fran/wdbuttercrypt/                                                        
ro                  Set/get read-only flag of subvolume.
label               Set/get label of device.
compression         Set/get compression for a file or directory

$ sudo btrfs prop get /run/media/fran/wdbuttercrypt/                                                         
ro=false
label=wdbuttercrypt

$ sudo btrfs prop get /run/media/fran/wdbuttercrypt/backupdedup/                                             
ro=false
compression=zlib

La configuración de snapper es, en principio, bastante sencilla.

#> snapper create-config  -f btrfs -t root /run/media/fran/wd15btrfs
#> snapper list-configs
Config | Subvolume                
-------+--------------------------
root   | /run/media/fran/wd15btrfs

jnuc /etc/snapper/configs #> snapper list
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 |       |      | root |         | current     |

jnuc /etc/snapper/configs #> snapper create

jnuc /etc/snapper/configs #> snapper list
Type   | # | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+---+-------+--------------------------+------+---------+-------------+---------
single | 0 |       |                          | root |         | current     |         
single | 1 |       | Wed Sep 23 13:37:16 2015 | root |         |             |

# btrfs subvol list -puta /run/media/fran/wd15btrfs
ID      gen     parent  top level       uuid    path
--      ---     ------  ---------       ----    ----
257     135     5       5               afb541bd-5459-e245-84af-eca6c17c1eaf    backupdedup
379     124     5       5               49b14378-0390-cf48-a81e-08a84b8b88a5    .snapshots
380     123     379     379             b1650ae6-4baf-e744-8b3a-26f4d5dd6fb9    <FS_TREE>/.snapshots/1/snapshot

Con esto vemos como crear nuestro primer filesystem que será controlado por snapper. Ahora solo es cuestión de invocar snapper create cada vez que vayamos a hacer cambios significativos en el filesystem, o queramos tener un punto de restauración en ese momento.

Snapper tambien nos permite hacer cosas muy interesantes, como por ejemplo controlar las diferencias que hay entre dos snapshots creados anteriormente:

snapper status 0..1

Happy hacking :)

Introducción a btrfs

Butter Filesystem, o btrfs, es un "nuevo" filesystem que toma bastantes ideas de ZFS de Solaris. Su idea fundamental es unificar la gestión de ficheros y de volúmenes (tipo LVM) bajo un mismo entorno. De esta forma, operaciones como añadir o quitar discos en caliente, redistribuir los datos (balance) o cambiar el nivel de protección (RAID) son factibles y mucho más eficientes al conocer qué ficheros están involucrados en cada operación (y no simplemente unos bloques que desconocemos si contienen datos o no).

Teniendo ya creado un filesystem btrfs, podemos empezar a sacar algo de información de esta forma:

$ df -ht btrfs
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-5       838G  123G  715G  15% /run/media/fran/wd20btrfs

$ sudo btrfs filesystem show /run/media/fran/wd20btrfs/
Label: 'wd20btrfs'  uuid: 7bb1d318-c7a9-40d8-995a-972a9d43544f
    Total devices 1 FS bytes used 120.15GiB
    devid    1 size 837.59GiB used 124.04GiB path /dev/mapper/luks-0aad2fa7-f2c9-4acb-81f5-5197751fee3e

Btrfs v3.18.1

Dentro de btrfs existe el concepto de subvolúmenes, que vendrían a ser similares a los filesystems zfs. Los subvolúmenes tienen una estructura jerárquica y pueden ser susceptibles de hacer snapshots con ellos, enviarlos con btrfs send/receive, etc.

$ sudo btrfs subvolume list -puta /run/media/fran/wd20btrfs/ 
ID      gen     parent  top level       uuid    path
--      ---     ------  ---------       ----    ----
257     944     5       5               75a8331b-9cd3-0d46-b773-9aaba88b6369    root
514     950     5       5               c767358c-83e0-134f-9698-2ae535742284    backup
556     951     514     514             54f942af-31e7-6e4c-ae4a-691d4642ddfd    <FS_TREE>/backup/.snapshots
558     828     556     556             add72c57-3f1b-a143-8902-cc0242e971bf    <FS_TREE>/backup/.snapshots/2/snapshot
559     841     556     556             9e6e71aa-8ddc-ee44-a0cc-628ab659c544    <FS_TREE>/backup/.snapshots/3/snapshot
560     848     556     556             fc44d63a-393d-294e-b868-6d12c9e5515f    <FS_TREE>/backup/.snapshots/4/snapshot

$ sudo btrfs subvolume show /run/media/fran/wd20btrfs/                                                   
/run/media/fran/wd20btrfs is btrfs root

$ sudo btrfs subvolume show /run/media/fran/wd20btrfs/backup/
/run/media/fran/wd20btrfs/backup
    Name:                   backup
    uuid:                   c767358c-83e0-134f-9698-2ae535742284
    Parent uuid:            -
    Creation time:          2015-01-20 22:03:20
    Object ID:              514
    Generation (Gen):       950
    Gen at creation:        202
    Parent:                 5
    Top Level:              5
    Flags:                  -
    Snapshot(s):
                            .snapshots/2/snapshot
                            .snapshots/3/snapshot
                            .snapshots/4/snapshot
                            .snapshots/5/snapshot

Al igual que en ZFS, las herramientas df y du no necesariamente muestran información correcta sobre nuestro filesystem. Factores como la compresión, nivel de RAID, etc harán que no concuerden estas informaciones con el uso real de espacio en disco y sobre la cantidad de información que este contiene.

En el ejemplo de abajo, podemos ver que hay 119.01 GiB de datos, pero solo ocupan en disco 118.45.

$ btrfs filesystem df /run/media/fran/wd20btrfs
Data, single: total=119.01GiB, used=118.45GiB
System, DUP: total=8.00MiB, used=32.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=2.50GiB, used=1.70GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=512.00MiB, used=0.00B

Cada subvolumen de btrfs puede tener distintas propiedades establecidas, fundamentalmente ro para cambiar un filesystem a sólo-lectura, y compression para establecer el algoritmo de compresión a utilizar para nuevos datos escritos en el subvolumen:

$ sudo btrfs prop list /run/media/fran/wd20btrfs/                                                        
ro                  Set/get read-only flag of subvolume.
label               Set/get label of device.
compression         Set/get compression for a file or directory

$ sudo btrfs prop get /run/media/fran/wd20btrfs/                                                         
ro=false
label=wd20btrfs

$ sudo btrfs prop get /run/media/fran/wd20btrfs/backup/                                             
ro=false
compression=zlib

Otra de las características que tiene btrfs es que podemos comprobar la integridad de nuestros datos. No nos servirá para arreglar nada si no tenemos otra copia de los mismos (bien por RAID, o de un backup externo), pero al menos nos enteraremos si nuestros datos están bien.

$ sudo btrfs scrub status -d /run/media/fran/wd20btrfs/
scrub status for 7bb1d318-c7a9-40d8-995a-972a9d43544f
scrub device /dev/mapper/luks-0aad2fa7-f2c9-4acb-81f5-5197751fee3e (id 1) status
scrub started at Fri Apr 17 21:48:08 2015, running for 25 seconds
total bytes scrubbed: 847.03MiB with 0 errors

$ sudo btrfs scrub status -d /run/media/fran/wd20btrfs/
scrub status for 7bb1d318-c7a9-40d8-995a-972a9d43544f
scrub device /dev/mapper/luks-0aad2fa7-f2c9-4acb-81f5-5197751fee3e (id 1) history
scrub started at Fri Apr 17 21:48:08 2015 and finished after 3460 seconds
total bytes scrubbed: 121.84GiB with 0 errors

Por lo visto anteriormente, btrfs es un sistema de ficheros prometedor y llamado a reemplazar a filesystems más tradicionales como ext4 ó XFS, a la vez que sistemas de volúmenes como LVM. Ahora sólo hace falta que gane algo más de soporte por parte de la comunidad y usuarios que lo prueben hasta el límite.

Happy Hacking :-)

Camino al RHCA: Openstack (EX210)

Hace unos meses tuve la ocasión de registrarme para el examen de Openstack EX210, y como oferta, Red Hat otorgaba acceso al entorno de formación online ROLE.

Como entorno de formación me pareció bastante correcto. Con el usuario habitual de la RedHat Network (RHN), se obtiene acceso tanto a la documentación como a un set de máquina o máquinas virtuales que permiten hacer prácticas y resetear el estado al original en caso de que rompamos algo. Además, el acceso permanece durante 90 días para poder utilizarlo cuando mejor nos convenga.

La única parte mala que le veo es que la única forma de acceder a las VMs es a través de una consola Javacript, y no tienen conectividad desde o hacia afuera. Esto significa que el teclado es tipo US y que para escribir algunos caracteres especiales es algo complicado sin utilizar el teclado en pantalla.

En lo relativo al proceso de examen, también novedades al haber utilizado el Kiosk disponible para hacer los exámenes en solitario. Todo bien, salvo el hecho de tener que utilizar un teclado (físico) US. Hay que venir acostumbrado para no tener problemas ;-)

Como siempre, en la web de Red Hat tenemos disponibles los objetivos del examen. Hay que tener en cuenta que, siendo un curso introductorio de Openstack, los contenidos van más sobre tener un entendimiento general de la arquitectura del sistema que tener un conocimiento muy detallado de cada parte.

De cada a preparar el examen por cuenta propia, se puede montar un laboratorio con la distribución RDO de Openstack. Grosso modo , es una distribución equivalente a lo que sería Fedora/CentOS en relación a RHEL, el 90% del producto es igual en la versión de pago de RHOSP (RedHat OpenStack Platform).

Así que para instalar un entorno pequeño de Openstack en CentOS 7, es tan sencillo como hacer lo siguiente:

yum install -y epel-release
yum install -y https://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-4.noarch.rpm
yum install -y openstack-packstack
packstack --allinone

Como siempre, de cara al examen hay que tener muy en cuenta el tiempo asignado a cada ejercicio y no pararse en exceso en una parte concreta si no sale a la primera.

Happy hacking :-)

Truco: Seleccionar el navegador predeterminado

Si queremos configurar el navegador predeterminado del escritorio, hay una herramienta muy útil llamada xdg-settings.

Las opciones para cambiarlo son:

$ xdg-settings --list
Known properties:
default-url-scheme-handler Default handler for URL scheme
default-web-browser Default web browser

$ xdg-settings get default-web-browser
midori-private.desktop

$ xdg-settings set default-web-browser firefox.desktop

$ xdg-settings get default-web-browser
firefox.desktop

Esto es válido en Fedora, Debian, tanto para XFCE como Gnome. El paquete que provee este ejecutable es xdg-utils, que da esta información :

Name : xdg-utils
Summary : Basic desktop integration functions
URL : http://portland.freedesktop.org/
License : MIT
Description : The xdg-utils package is a set of simple scripts that provide basic
: desktop integration functions for any Free Desktop, such as Linux.
: They are intended to provide a set of defacto standards.
: This means that:
: * Third party software developers can rely on these xdg-utils
: for all of their simple integration needs.
: * Developers of desktop environments can make sure that their
: environments are well supported
: * Distribution vendors can provide custom versions of these utilities
:
: The following scripts are provided at this time:
: * xdg-desktop-icon Install icons to the desktop
: * xdg-desktop-menu Install desktop menu items
: * xdg-email Send mail using the user's preferred e-mail composer
: * xdg-icon-resource Install icon resources
: * xdg-mime Query information about file type handling and
: install descriptions for new file types
: * xdg-open Open a file or URL in the user's preferred application
: * xdg-screensaver Control the screensaver
: * xdg-settings Get various settings from the desktop environment

Ya no perderé el tiempo buscando entre confusos menús gráficos :-)

HFT, un caso práctico de Performance Tuning

Hace poco escribía sobre la dificultad de encontrar de encontrar un escenario donde aplicar técnicas de análisis y mejora de rendimiento. Basta hablar para que venga un proyecto que te haga cerrar la boca :-) . Lo que me ha tocado es un proyecto de High Frequency Trading (HFT) donde se compra-venden divisas y la latencia es fundamental.

Sin entrar en muchos detalles, este es un negocio muy competitivo donde solo los mejores ganan, y donde cada microsegundo pueden suponer millones de euros.

Ahora el proyecto está en fase de implmentación y pruebas, y es de esperar que en las próximas semanas llevemos unas pruebas para determinar qué latencia conseguimos en cada transacción y qué se puede hacer para mejorarla.

Las guías de referencia y buenas prácticas que he consultado hasta ahora recomiendan lo siguiente:

Del lado del hardware (BIOS, procesadores, RAM, etc) :

  • Desactivar hyperthreading.
  • Desactivar cores de cada CPU si no son necesarios.
  • Elegir módulos de memoria grandes (ej mejor uno de 16Gb que dos de 8Gb).
  • Desactivar todos los estados de ahorro de energía de los procesadores.
  • Desactivar el máximo posible de SMIs (System Management Interrupts).
  • Desactivar la revisión de fallos en módulos de RAM, y bajar la frecuencia de refresco CAS si es posible.

También incluyo unos cuantos recursos interesantes que encontré preparando el examen de certificación:

La preparación del examen se puede hacer en entornos virtuales; en mi caso lo hice bajo Fedora 17 con KVM. La parte de storage se puede hacer con RHEL6 "pelado", la parte de GlusterFS se puede hacer con los paquetes de gluster de EPEL y la parte de cluster se puede excepto la configuración de dispositivos de fencing.

Happy hacking ;-)

Camino al RHCA: Performance Tuning (EX442)

Acabo de presentarme al examen de RedHat Performance Tuning tras atender al curso y tengo una sensación agridulce. Independientemente de la nota, no tengo la sensación de "Saber Kung-fu" [tm]. En otros cursos exámenes o sales con la sensación de saber casi todo lo que que hay saber sobre el producto o servicio en cuestión, mientras que tras este todo es un mar de dudas y un "ahora sé lo que no sé" :-)

Algunos comentarios aleatorios sobre el curso en sí:

  • Es un curso bastante denso en cuanto a pequeñas cosas que recordar. Desde luego, no es fácil de impartir y requiere mucha preparación previa para darlo de forma fluida. Especialmente difícil si solo impartes el curso de pascuas a ramos.

  • Deja más puertas abiertas al mundo del performance tuning. No espero en una semana convertirme en un super experto del kernel a bajo nivel, ni en un Alan Cox o Ingo Molnar. Pero también es cierto que las espectativas de los asistentes pueden ir por otros derroteros.

  • Al ser un curso enfocado a ver únicamente tecnologías de RedHat, se puede quedar un poco "corto" en el mundo real con productos de muy diversos fabricantes; ej: tuning avanzado de HBAs, LVM, filesystems, ... Por otra parte, las referencias a Valgrind, y en menor medida a SystemTap se quedan un poco cogidas de los pelos para sysadmins puros y duros - normalmente no vas a debuggear software en entornos de producción (normalmente se trabaja con software privativo o del que no se tiene el código fuente igualmente).

También incluyo unos cuantos recursos interesantes que encontré preparando el examen de certificación:

La preparación del examen se puede hacer en entornos virtuales; en mi caso lo hice bajo Fedora 17 con KVM. La parte de storage se puede hacer con RHEL6 "pelado", la parte de GlusterFS se puede hacer con los paquetes de gluster de EPEL y la parte de cluster se puede excepto la configuración de dispositivos de fencing.

Happy hacking ;-)