Antes de pasar a la acción, vamos a describir el proyecto que tenemos en mente y algunas opciones de montaje. Y para ello, nada mejor que unas figuras para visualizar los 3 tipos de arquitectura que podemos configurar con este número de nodos (unos 4-5):

La primera (Figura 1) define 2 servidores web con la misma configuración sirviendo los mismos contenidos y atacando a la misma base de datos (en clúster), pero funcionan independientemente y por ello cada uno tiene una ip pública propia. Esto evidentemente no puede definirse HA; el balanceo se haría a nivel de dns (2 registros A). Si uno falla, tendremos problemas. Dependiendo del navegador, si éste es medianamente moderno no tendremos la mala suerte de perder el 50% de los requests que van al servidor caído porque -y esto es experiencia personal- su estrategia es esperar un tiempo prudencial (<1 minuto) y si no hubo suerte en la carga del request del primer registro A, redirigirá la petición al otro y acabaría cargando el contenido. La mala noticia es que en el mundo web, cuando tenemos tiempos de carga superiores a los 15-20 segundos... hay una gran probabilidad que el visitante desista.

La segunda arquitectura (Figura 2) ya es otra cosa. En este caso también lo tenemos todo redundado (a nivel de servidores, ojo), con la diferencia que el clúster vigila no sólo la disponibilidad de la base de datos, sino también del servidor web, de modo que si uno de estos 2 servicios cae, se mueve todo al segundo (incluyendo la ip virtual compartida).

La tercera arquitectura (Figura 3) es otro modo de ofrecer ésta redundancia web, con la diferencia de que quien gestiona su disponibilidad normalmente también sabe repartirla y aprovechamos una característica adicional: el balanceo de carga (p.ej. con Zen Load Balancer, LVS, Apache mod_proxy_server, etc). Aunque éste sería el mejor escenario de los 3, vamos a desarrollar el segundo que bastante chicha tiene ya éste tema. Y posteriormente, cuando tengamos todo digerido, siempre podemos movernos hacia la figura del balanceador.

Así pues, he aquí el gráfico definitivo que ilustra cómo va a quedar el asunto sería algo como lo siguiente:

Los equipos mostrados (2) son destinados únicamente a la parte de base de datos (aunque posteriormente podemos añadirle la parte web) y comparten una ip virtual (192.168.2.145). También podemos apreciar que cada uno tiene 2 particiones: la principal para / y la otra para montar la parte de los datos de MySQL (que ubicaremos en la ruta original, /var/lib/mysql). Por el nombre de los discos, puede verse que estoy operando con máquinas virtuales KVM, aunque esto carece de interés para nuestro propósito.

Al lío y por pasos:

1. Configuramos las direcciones ip y los hostnames (ponerlos también en /etc/hosts):

    debian1# echo "drbd1" > /etc/hostname
    debian2# echo "drbd2" > /etc/hostname
    drbd1# vi /etc/network/interfaces:
     auto eth0
     iface eth0 inet static
      address 192.168.2.143
      netmask 255.255.255.0
      gateway 192.168.2.1
    drbd2# vi /etc/network/interfaces:
     auto eth0
     iface eth0 inet static
      address 192.168.2.144
      netmask 255.255.255.0
      gateway 192.168.2.1
    # vi /etc/hosts:
     192.168.2.143	drbd1
     192.168.2.144	drbd2
   

2. Generamos y ubicamos las respectivas llaves ssh en cada host:

    drbd1# ssh-keygen
    drbd2# ssh-keygen
    drbd1# ssh-copy-id root@drbd2
    drbd2# ssh-copy-id root@drbd1
   

3. Instalamos los siguientes paquetes en ambos nodos (el ntpd es para drbd):

    # apt-get install drbd-utils pacemaker ntp-date
   

4. Quitamos el autostart de DRBD en ambos nodos porque los gestionará Pacemaker. Esto es una norma general para todos los recursos que sean gestionados por el clúster para que no se inicien mas que cuando deban. Adicionalmente, habilitarlo para Corosync:

    # update-rc.d -f drbd remove
    # echo "START=yes" > /etc/default/corosync
    drbd1# scp /etc/default/corosync drbd2:/etc/default/corosync
   

5. Configuramos DRBD en ambos nodos:

    # vi /etc/drbd.conf:
     include "drbd.d/global_common.conf";
   

    # vi /etc/drbd.d/global_common.conf:
     global {
      usage-count no;
     }
     common {
      syncer {
       # Max. sync rate (couple bandwitdh with harddisk performance).
       rate 10M;
      }
     }
     resource srv {
      device    /dev/drbd0;
      disk      /dev/vdb1;
      flexible-meta-disk internal;
      # Synchronous replication protocol.
      protocol C;
      handlers {
       # Notify when splitbrain happens.
       split-brain "/usr/lib/drbd/notify-split-brain.sh root";
       # Called if node is primary, degraded and local copy of the data is inconsistent.
       pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
       # Node is primary but lost the after-split-brain auto recovery procedure. As a consequence, it should be abandoned.
       pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
       # DRBD got an IO error from the local IO subsystem.
       local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
      }
      startup {
       degr-wfc-timeout 120;
      }
      disk {
       # Disk error handling. On disk errors, DRBD will automatically use the other node, even if this can cause a performance penalty.
       on-io-error detach;
      }
      net {
       cram-hmac-alg sha1;
       shared-secret "EldersOfTheInternet1";
       # Lines dedicated to handle split-brain situations (e.g. if one of the nodes fails).
       after-sb-0pri discard-zero-changes; # If both nodes are secondary, just make one of them primary.
       after-sb-1pri discard-secondary; # If one is primary, one is not, trust the primary node.
       after-sb-2pri call-pri-lost-after-sb; # If there are two primaries, make the unchanged one secondary.
       rr-conflict disconnect;
      }
      syncer {
       al-extents 257;
      }
      on drbd1 {
       address   192.168.2.143:7788;
      }
      on drbd2 {
       address   192.168.2.144:7788;
      }
     }
   

6. Cargamos el módulo del kernel drbd, nos aseguramos que lo haga a cada inicio y arrancamos DRBD para comprobar que funciona y se sincroniza:

    # modprobe drbd
    # echo "drbd" >> /etc/modules
    # /etc/init.d/drbd start
    # drbd-overview ó cat /proc/drbd
   

7. Hacemos que uno de los nodos DRBD sea primario, creamos un filesystem, lo montamos, instalamos MySQL, le quitamos el autoarranque, comprobamos que inicie y posteriormente lo paramos junto con DRBD:

    drbd1# drbdadm primary all
    drbd1# mkfs.ext4 /dev/drbd0
    drbd1# mkdir /var/lib/mysql
    drbd1# mount -t ext4 /dev/drbd0 /var/lib/mysql
    drbd1# apt-get install mysql-server
    drbd1# /etc/init.d/mysql stop
    drbd1# chmod mysql.mysql /var/lib/mysql
    drbd1# update-rc.d -f mysql remove
    drbd1# /etc/init.d/mysql start
    drbd1# /etc/init.d/mysql stop
    drbd1# /etc/init.d/drbd stop
   
    drbd2# apt-get install mysql-server
    drbd2# update-rc.d -f mysql remove
    drbd2# /etc/init.d/mysql stop
    drbd2# rm -rf /var/lib/mysql/*
    drbd2# /etc/init.d/drbd stop
   

8. Configuramos Corosync:

   totem {
           # Version of the configuration file.
           version: 2
           # How long before declaring a token lost (ms).
           token: 3000
           # How many token retransmits before forming a new configuration.
           token_retransmits_before_loss_const: 10
           # How long to wait for join messages in the membership protocol (ms).
           join: 60
           # How long to wait for consensus to be achieved before starting a new round of membership configuration (ms).
           consensus: 3600
           # Turn off the virtual synchrony filter.
           vsftype: none
           # Number of messages that may be sent by one processor on receipt of the token.
           max_messages: 20
           # Limit generated nodeids to 31-bits (positive signed integers).
           clear_node_high_bit: yes
           # Disable encryption (faster).
           secauth: off
           # How many threads to use for encryption/decryption.
           threads: 0
           # This specifies the mode of redundant ring, which may be none, active, or passive.
           rrp_mode: none
           interface {
                   # The following values need to be set based on your environment.
                   ringnumber: 0
                   # The address of the network in which totem will route traffic.
                   bindnetaddr: 192.168.2.0
                   # Multicast address used by corosync executive (default is ok).
                   mcastaddr: 226.94.1.1
                   # UDP port number.
                   mcastport: 5405
           }
   }
   
   service {
           # Load the Pacemaker Cluster Resource Manager.
           ver:       0
           name:      pacemaker
   }
   
   logging {
           fileline: off
           to_stderr: yes
           to_logfile: yes
            logfile: /var/log/corosync/corosync.log
           to_syslog: yes
           syslog_facility: daemon
           debug: off
           timestamp: on
   }
   

9. Comprobamos el estado del cluster:

    # crm_mon -1 ó crm status
   

10. Configuramos el clúster con crm:

     drbd1# crm configure property stonith-enabled="false"
     drbd1# corosync-keygen
     drbd1# scp /etc/corosync/authkey drbd2:/etc/corosync/authkey
     drbd1# crm configure # Entering crm interactive prompt...
    

     # Creamos un resource de tipo "drbd" y definimos los parámetros (el nombre del recurso en la config. de drbd es "srv" y los tiempos de los checks para cada nodo).
     primitive drbd_mysql ocf:linbit:drbd params drbd_resource="srv" op monitor interval="29s" role="Master" op monitor interval="31s" role="Slave"
     # Creamos un resource de tipo "Filesystem" y definimos sus parámetros.
     primitive fs_mysql ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/var/lib/mysql" fstype="ext4"
     # Creamos un resource de tipo "IPaddr2" y definimos sus parámetros.
     primitive ip_mysql ocf:heartbeat:IPaddr2 params ip="192.168.2.145" nic="eth0:0"
     # Creamos un resource del tipo mysql (sin parámetros).
     primitive mysqld lsb:mysql
     # Creamos el grupo "mysql" que une los resources: fs_mysql ip_mysql mysqld. Los inicia secuencialmente y los apaga del mismo modo, pero en orden inverso.
     group mysql fs_mysql ip_mysql mysqld
     # Creamos un resource del tipo clon multi-state del recurso "drbd_mysql". Permite a las múltiples instancias estar en uno de ambos modos de operación: Master y Slave, iniciándose ésta -el clon- en estado Slave.
     ms ms_drbd_mysql drbd_mysql meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
     # Definimos un colocation constraint para forzar que el grupo "mysql" se ejecute en el mismo nodo dónde el recurso "ms_drbd_mysql:Master" esté activo.
     colocation mysql_on_drbd inf: mysql ms_drbd_mysql:Master
     # Definimos un order constraint para forzar que tengamos el recurso DRBD promovido a Master previo a iniciar MySQL en él.
     order mysql_after_drbd inf: ms_drbd_mysql:promote mysql:start  
     property $id="cib-bootstrap-options" expected-quorum-votes="2" stonith-enabled="false" no-quorum-policy="ignore"  
     rsc_defaults $id="rsc-options" resource-stickiness="100" migration-threshold="3"
     exit
    

    Un inciso para comentar que ésta herramienta tiene muchas opciones que podemos ir descubriendo a medida que lo necesitemos. Comandos inmediatamente necesarios pueden ser los siguientes:

    • crm status|crm_mon para consultar el estado del clúster.
    • crm configure show para mostrar la configuración.
    • crm node show para mostrar el estado de los nodos que forman el clúster.
    • crm node standby|online para poner un nodo en mantenimiento o de vuelta a producción.
    • crm ra list para ver una lista de los resource agents (los scripts que usa Pacemaker para interactuar con los servicios).

11. Como en nuestro clúster sólo usamos 2 nodos, modificamos la configuración de quorum en el cluster para ajustar la gestión de fallos:

     # crm configure property expected-quorum-votes="1"
     # crm configure property no-quorum-policy="ignore"
    

12. (Opcional) Si quisiéramos añadir Apache2 a la ecuación para terminar consiguiendo lo descrito en la Figura 2, añadiríamos algo como lo siguiente:

     # crm configure primitive apache ocf:heartbeat:apache params configfile=/etc/apache2/apache2.conf op monitor interval="30s"
     # crm configure colocation apache_on_drbd inf: apache ms_drbd_mysql:Master
     # crm configure order apache_after_drbd inf: ms_drbd_mysql:promote apache:start
    

    Que en definitiva viene a añadir la gestión de Apache2 con un archivo de configuración dado, la ubicación para que se ejecute en el mismo nodo dónde esté levantado el DRBD en modo Master y el orden para que se lance una vez el nodo DRBD haya sido promovido a Master.

Nota final: Esta configuración ha sido probada satisfactoriamente en Debian 6 y posteriormente migrada a Debian 7, donde también funciona a pesar de la actualización a versiones superiores de Corosync y Pacemaker.

Referencias imprescindibles:

MySQL high availability cluster with DRBD+Pacemaker/Corosync
Building HA cluster with Pacemaker, Corosync and DRBD
Clusters from Scartch

¿Qué es lo que pasa? Que por algún motivo, la combinación de motion + la Raspberry Pi + la webcam Creative Live! Cam Sync no acaba de funcionar, y motion captura imágenes corruptas (partes de la misma desplazadas/desordenadas). Con esto, el cálculo del movimiento se vuelve, literalmente, loco, y detecta movimiento constantemente cuando no lo hay. En definitiva, resulta inusable.

¿Cómo solventamos la papeleta? Después de historias varias probando combinaciones varias de motion e incluso recompilando algún que otro paquete como libpjeg con retoques de código, ya tengo andando la Creative Live! Cam Sync (una webcam bastante barata) + motion en la Raspberry Pi. Éstos son los pasos seguidos:

Paso 1: mjpg_streamer

# Instalamos los paquetes necesarios:
apt-get install subversion libv4l-dev libjpeg8-dev imagemagick checkinstall
# Bajamos mjpg-streamer de subversion, lo compilamos...
cd /usr/src/
svn co https://mjpg-streamer.svn.sourceforge.net/svnroot/mjpg-streamer mjpg-streamer
cd mjpg-streamer/mjpg-streamer
make USE_LIBV4L2=true clean all
# ... y creamos un paquete Raspbian para facilitar su manejo:
checkinstall
# Comprobaremos que se instaló:
dpkg -l | grep mjpg
ls -lh /usr/src/mjpg-streamer/mjpg-streamer/mjpg_20130203-1_armhf.deb
# Y probamos que mjpg-streamer funcione especificando paths absolutos
# hacia los plugins...
mjpg_streamer -i "/usr/local/lib/input_uvc.so -d /dev/video0 -r 352x288 -f 5" -o "/usr/local/lib/output_http.so -p 8090 -w /var/www/mjpg_streamer"
# ... o con paths relativos añadiendo la ruta al LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=/usr/local/lib; mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 352x288 -f 5" -o "output_http.so -p 8090 -w /var/www/mjpg_streamer"

Una vez lanzado mjpg_streamer, tenemos 2 URL's a través de las cuales podemos comprobar el funcionamiento:

1. Visualizar la salida del stream: http://localhost:8080/?action=stream
2. Tomar capturas del mismo: http://localhost:8080/?action=snapshot

Las resoluciones que he conseguido usar con ésta webcam en mjpg-streamer són 320x240 y 352x288, a pesar de que en teoría soporta 640x480.

Paso 2: motion

# Instalamos motion y lo configuramos:
apt-get install motion
vi /etc/motion/motion.cnf
netcam_url "http://localhost:8090/?action=snapshot"
# Lo lanzamos en modo interactivo para ver qué nos cuenta:
motion -n

En definitiva, lo que hemos hecho es usar una aplicación de streaming (mjpg_streamer) para la captura de imágenes, y que motion coja eso como la entrada para calcular los deltas con el threshold definido.

Referencias:

Todo esto no hubiera sido posible sin estas referencias en los foros de Raspberry Pi:

1. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=27186&p=276985
2. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=30&t=8659&p=164539&hilit=mjpeg+streamer#p164539

Como en el caso de todos los balanceadores, éste siempre acaba atacando contra unos backends y es el que se encarga de redirigir las peticiones. Esta tarea la lleva a cabo -por debajo- principalmente con el antiguo y poco conocido pen.

Voy a ir al grano y seré escueto dado que su documentación ya detalla suficientemente cada cosa. Además, también está disponible una Quick Start Guide para tener un overview de cómo va el tema. Para terminar esta breve intro, solamente queda aclarar un par de conceptos de su jerga:

• Farm es un grupo de backends con una configuración determinada que sirven a un mismo propósito.P.ej. podemos tener un farm que tenga un número determinado de nodos que se encargue de servir peticiones web.
• Real Servers son los backends propiamente. P.ej. los servidores web finales con Apache mismo.
• Cluster es un conjunto de 2 o más nodos de balanceo/frontends (Zen Load Balancers, para entendernos).

Instalación de un sólo nodo de balanceo

1. Instalación, bien en base a iso/imagen virtual, bien en base a paquete, de Zen Load Balancer. En el caso de Debian basta con añadir los siguientes repositorios y lanzar un apt-get update && apt-get install zenloadbalancer para tenerlo andando (se puede gestionar a nivel de servicio).
deb http://zenloadbalancer.sourceforge.net/apt/x86 v2/
2. Acceso a la interfaz de gestión: https://<ip>:444, donde <ip> es la dirección ip que le hemos asignado al host. Las credenciales por defecto son admin:admin.
3. Creación y configuración de una ip virtual (Settings > Interfaces > Add virtual network interface).
4. Creación y configuración de un farm (usando la recién creada ip virtual): Manage > Farms > Add farm, especificando el profile (protocolo) a usar y otros settings.
5. Asignación de backends/real servers. Dentro de la configuración del farm está la opción Add real server, que usaremos para añadir cada backend. Destacar que en este punto debemos tener los hosts y el servicio a balancear (p.ej. web) instalados y debidamente configurados en cada backend.
6. Comprobación de funcionamiento. Sólo queda comprobar que atacando a la ip definida en el farm esten sirviendo los distintos real servers. Comentar que si no hemos definido persistencia, podemos ver la alternancia del uso de backends.

Instalación de un par de nodos de balanceo (clúster)

Llegados a este punto, añadir la capacidad de clúster son sólo unos pocos pasos más:

1. Instalación de un segundo Zen Load Balancer siguiendo el anterior primer paso.
2. El Zen Load Balancer que ya teniamos instalado (no el del paso previo) será el nodo primario del Clúster. Crearemos el cluster en Settings > Cluster y usamos la ip virtual. A continuación añadimos los datos del segundo Zen Load Balancer (Remote hostname), puesto que el principal -que es en el que estamos- ya figura. Guardamos (Save).
3. Ahora establecemos la contraseña del segundo Zen Load Balancer (Remote host root password) para que el primero pueda sincronizarse a fin y efecto de crear el cluster, sincronizar datos y, en definitiva, operar con el mismo. Nos aseguramos de establecer correctamente la RSA connection between nodes.
4. Finalmente definimos un Cluster type, que puede estar en Disabled (sin cluster), Master/Failback ó Both masters. La diferencia entre los 2 últimos tipos es que en el caso del Master/Failback, el nodo secundario del clúster sólo entra en funcionamiento temporalmente mientras el primario no esté disponible (y cuando lo está, cada uno recupera su rol). En el segudo caso (Both masters), el nodo secundario del clúster se convertirá en primario de modo permanemte (o hasta que forcemos manualmente lo contrario) mientras el primario no esté disponible.
5. Si todos los anteriores pasos han terminado satisfactoriamente, veremos (en cada Zen Load Balancer, bien en la cabecera al lado del usuario admin, bien en la sección Cluster) la indicación de que existe una configuración de clúster y su rol en cada caso (master o failback/backup).
6. Comprobación de funcionamiento. Podemos apagar el que esté actuando como nodo primario del clúster Zen Load Balancer y ver que el secundario rescata los requests (levantando la ip virtual) y los redirige a los real servers de igual modo que hacía el primario. Y cuando el primario vuelva a levantarse, podemos ver si recupera o no su rol en función del tipo de cluster elegido.

Notas/Troubleshooting

• Asegúrate siempre de operar (Farms y Clusters) con la ip virtual.
• Si quieres acceder a cada nodo por separado, recuerda que cada uno sigue teniendo su ip "física" disponible por la url de gestión. Esto es interesante si uno de ellos está deshabilitado/caído o si simplemente quieres ver rasgos particulares de cada uno (rol dentro del cluster, logs...).
• Antes de crear un Cluster, asegúrate de tener un nodo secundario limpio: será el nodo primario el que se encargará de replicarlo todo en él.
• Para las pruebas, puedes instalar un servidor web en cada realserver con una web estática que muestre el nombre del nodo. Así verás la alternancia (o stickyness) dependiento de la configuración de persistencia elegida.

1. ¿Qué es lo mínimamente imprescindible para que la Raspberry Pi funcione?
2. ¿De qué es capaz la Raspberry Pi?
3. ¿Porqué no instalar el Sistema Operativo como si fuera un ordenador normal?
4. ¿Porqué mi SD va tan lenta en mi RaspberryPi si en mi cámara fotográfica/de video vuela?
5. Entonces ¿qué tarjeta me compro? ¿Una Clase 10? ¿Utilizo un USB?
6. ¿Puedo ponerle ip fija a mi Raspberry?
7. ¿Qué Sistema Operativo es el indicado teniendo en mente instalar un servidor?
8. ¿Puedo montar fácilmente la imagen (.img) del Sistema Operativo para ver su contenido/realizar cambios sin necesidad de haberla volcado antes a la SD?
9. ¿Qué parámetros de montado sirven para tunear el rendimiento del rootfs y dónde ponerlos?
10. ¿Cómo puedo actualizar el firmware? ¿Es peligroso?
11. ¿Se puede hacer overclocking? ¿Invalida la garantía?

¿Qué es lo mínimamente imprescindible para que la Raspberry Pi funcione?

La propia Raspberry Pi, una tarjeta SD con el Sistema Operativo y el conector de alimentación micro USB. Si no se precisa, no es necesario conectar red, monitor/televisión, teclado ni ratón.

¿De qué es capaz la Raspberry Pi?

Pensada para la enseñanza de programación a los peques, es un pequeño ordenador barato (unos 35¤) y de muy bajo consumo (3.5W, muy probablemente inferior que tu router ADSL). Por poner un ejemplo, este blog y alguna otra web de bajo tráfico estan hospedadas en una, pero comunmente también se usa como media center, NAS o pequeña máquina para entornos de test/preproducción de pequeños proyectos.

¿Porqué no instalar el Sistema Operativo como si fuera un ordenador normal?

El RaspberryPi no es un ordenador normal entre otras cosas porque por defecto, el disco duro es una tarjeta de memoria SD (aunque puedan usarse USB) y éstas se caracterizan, en comparación con otros medios de almacenamiento, por su lentitud. En algunos casos (p.ej. con Raspbian) disponemos de instalador, pero no se recomienda y se aconseja al usuario (para mantener indemne su salud mental) planchar la imagen en la tarjeta. Alguno pensará que esto no es así porque dispone de la tarjeta más rápida del mercado y sus tasas (de lectura/escritura) son una maravilla, lo cual nos lleva a la siguiente pregunta...

¿Porqué mi SD va tan lenta en mi RaspberryPi si en mi cámara fotográfica/de video vuela?

Porque este tipo de tarjetas, dada la tendencia a ser usadas mayormente en este tipo de dispositivos, se están especializando cada vez más en el acceso secuencial a los datos. Y he aquí el problema, puesto que los sistemas de ficheros de los Sistemas Operativos hacen todo tipo de accesos, si bien predominan los aleatorios (esto es, a distintas partes del almacenamiento).

Entonces ¿qué tarjeta me compro? ¿Una Clase 10? ¿Utilizo un USB?

Esto ya es decisión personal. Un USB va a operar más rápido, pero el arranque debe hacerse forzosamente desde una SD, así que te obliga a tener ambos pinchados simultáneamente. Si optas por hacerlo todo desde la SD debes saber que la velocidad de este tipo de tarjetas viene definido normalmente por el término Class. La parte mala es que su significado parece haber variado con el tiempo. La Class 2/4/6 supone garantizar (al menos en teoría) un acceso sostenido fragmentado/aleatorio de mínimo 2/4/6 MB/s, mientras que esta definición es con acceso secuencial para la Class 10. La indústria está para vender, está claro. Esto se traduce en que no es raro ver tarjetas SD Class 4/6 con acceso aleatorio más rápido que las de Class 10. Para empeorarlo, cada marca y modelo tiene sus rendimientos, así que sólo queda fiarse de los tests de rendimiento que se haga de las mismas (p.ej. en el foro de RaspberryPi o en este apartado de eLinux). Personalmente pensé en obtener una Sandisk Ultra SDHC Class 6, pero finalmente me decanté por Class 10. Principalmente porque no conseguí encontrar Class 6, pero también porque por lo que pude ver en diversos tests, esta marca y modelo de tarjetas da un buen rendimiento también en acceso aleatorio (y la diferencia de precio con las Extreme no parece compensar). Esto en cuanto a la velocidad.

En cuanto al espacio, no penséis que es sólo un tema de saber cuánto almacenamiento se precisa para alojar los datos. Éste tipo de sistema de almacenamiento (mayormente del tipo MLC/Multi Level Cell) tiene una durabilidad inferior a los demás (p.ej. los discos magnéticos/duros y ópticos). Para retrasar este efecto, estas memorias disponen de una tecnología llamada "cell leveling" encargada de repartir equitativamente las lecturas y escrituras, es decir, de reducir el riesgo de gastar más unas celdas que otras y hacer que todas se deterioren por igual a la par. ¿Y qué tiene que ver el espacio? Pues que cuándo más espacio libre (en desuso) tenga la tarjeta, más podrá repartir la carga y su durabilidad aumentará.

¿Puedo ponerle ip fija a mi Raspberry?

Sí, y para ello no sólo es necesario que edites el archivo /etc/network/interfaces deshabilitando el dhcp y sustituyéndolo por un static como se muestra a continuación, sino que además (al menos en Raspbian) es recomendable eliminar el paquete del cliente dhcp: isc-dhcp-client.

$ cat /etc/network/interfaces 
auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

auto eth0
iface eth0 inet static
        address 192.168.1.2
        network 192.168.1.0
        netmask 255.255.255.0
        broadcast 192.168.1.255
        gateway 192.168.1.1

¿Qué Sistema Operativo es el indicado teniendo en mente instalar un servidor?

Para gustos los colores, pero personalmente siempre prefiero empezar con lo básico y luego instalar/configurar aquello que exclusivamente voy a usar. Y cuando se trata de una máquina que no destaca por su potencia, como es el caso, es la mejor opción para aprovechar sus escasos recursos. La DarkBasicImage de Raspbian viene a ser como una netinstall de Debian que además aprovecha el coma flotante por hardware (hfp) del que dispone la RaspberryPi. Para que nadie se lleve sorpresas, no está de más decir que no dispone de entorno gráfico y su gestión es totalmente por consola.

¿Puedo montar fácilmente la imagen (.img) del Sistema Operativo para ver su contenido/realizar cambios sin necesidad de haberla volcado antes a la SD?

Sí. Para ello puedes usar la herramienta kpartx con los siguientes parámetros:

• -l imagen.img para ver la lista de particiones de la imagen.
• -a imagen.img para tenerlas accesibles vía /dev/mapper/loop0pX y así poder montarlas con mount.
• -d imagen.img para desconectar los dispositivos de loop (¡recuerda desmontarlos previamente!).

plas:/home/jors# kpartx -l raspbian_wheezy_20120608.img
loop0p1 : 0 153600 /dev/loop0 2048
loop0p2 : 0 3364864 /dev/loop0 155648
loop0p3 : 0 391168 /dev/loop0 3520512

plas:/home/jors# kpartx -a raspbian_wheezy_20120608.img

plas:/home/jors# ls -lh /dev/mapper/loop0p*
lrwxrwxrwx 1 root root 7 sep  1 11:58 /dev/mapper/loop0p1 -> ../dm-0
lrwxrwxrwx 1 root root 7 sep  1 11:58 /dev/mapper/loop0p2 -> ../dm-1
lrwxrwxrwx 1 root root 7 sep  1 11:58 /dev/mapper/loop0p3 -> ../dm-2

plas:/home/jors# mount /dev/mapper/loop0p2 /mnt/SD -o loop

plas:/home/jors# ls /mnt/SD/
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var

plas:/home/jors# umount /mnt/SD/

plas:/home/jors# kpartx -d raspbian_wheezy_20120608.img
loop deleted : /dev/loop0

¿Qué parámetros de montado sirven para tunear el rendimiento del rootfs y dónde ponerlos?

En /boot/cmdline.txt se pueden poner por ejemplo los siguientes en el parámetro rootflags:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootflags=data=writeback,discard,commit=300 quiet rootwait

También se puede deshabilitar el journal (tune2fs -O ^has_journal /dev/particion), pero existe mayor riesgo de pérdida de datos. Se pueden cojer ideas del documento SSD optimization - Debian Wiki.

¿Cómo puedo actualizar el firmware? ¿Es peligroso?

No entraña ningún riesgo porque el firmware va alojado en la propia SD, así que en el peor de los casos bastaría con reflashear (instalar o volcar la imagen del Sistema Operativo a la SD de nuevo). El procedimiento es actualmente tan sencillo como el que sigue:

wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update
chmod +x /usr/bin/rpi-update
apt-get install git
rpi-update

Después de esto nos pedirá reiniciar. Un modo de comprobar el update, a parte del cambio de versión de kernel que podemos comprobar con un uname -r (debemos ver 3.2.27+), es comprobar el número de interrupciones del driver USB, bien con:

vnstat # Ver el valor bajo el apartado system, in (de interrupts)

...o bien con:

sh -c "cat /proc/interrupts | grep dwc && sleep 10 && cat /proc/interrupts | grep dwc" | awk '{ if (s==0) s=$2 } END { print ($2-s)/10 }'

Antes, dependiendo de los dispositivos conectados a los puertos USB podian llegar a o incluso superar las 8000. Ahora no deberian superar las 1000, y si no tienes nada conectado por USB, deberian rondar las 200-300.

Otro modo de comprobar la versión de firmware es checkeando la versión que dispone la GPU:

# Estos 2 exports deberian estar en nuestro .bashrc:
export PATH=$PATH:/opt/vc/bin
export LD_LIBRARY_PATH=$LD_LIBRARYPATH:/opt/vc/lib
$ vcgencmd version
Sep 25 2012 00:17:37 
Copyright (c) 2012 Broadcom
version 339133 (release)

¿Se puede hacer overclocking? ¿Invalida la garantía?

Tradicionalmente se ha podido hacer overclocking, pero ésto habilitaba un bit en un componente de la Raspberry que invalidaba la garantía en caso de problemas. Actualmente hay un modo de hacer overclocking "legalmente" (aprobado por la propia compañía fundación) y sin invalidar la garantía: usar raspi-config. Para instalarlo deberemos añadir a nuestros repositorios (si no lo tenemos ya) el siguiente:

deb http://archive.raspberrypi.org/debian/ wheezy main
wget http://archive.raspberrypi.org/debian/raspberrypi.gpg.key
apt-key add raspberrypi.gpg.key

Esta utilidad basada en ncurses nos permite hacer una serie de configuraciones de nuestro sistema, incluyendo el apartado de overclocking. Hecho esto, podemos querer consultar la velocidad del procesador o su temperatura, respectivamente, en un momento dado:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/class/thermal/thermal_zone0/temp

Si tienes algún otro tip/truco/consejo interesante, estaré encantado de oirlo y añadirlo a la lista. ¡Gracias por contribuir a la difusión de la información y el conocimiento! ;)