enchufado.com RSS 2.0 Feed http://enchufado.com/ Feed rss 2.0 del blog enchufado.com es Unixbenchs de SoC/NAS/Barebone/HTPC/Mini PC http://enchufado.com/post.php?ID=369 http://enchufado.com/post.php?ID=369 Fri, 25 Apr 2014 00:31:41 +0200De la web del proyecto, Unixbench es una suite de benchmarking cuyo propósito es proporcionar un indicador básico de rendimiento de sistemas con base Unix. Por ello usa una serie de tests cuyos resultados son comparados a unos considerados "base" (para entendernos, con el que se comparan todos los demás) para producir unos índices. Además, éstos índices obtenidos por cada test se combinan para producir un íncide sintético final (léase como una puntuación final) para medir el desempeño del sistema. Esto facilita la comparación de puntuaciones.

En la misma web avisan que se trata de un benchmark de sistema y no sólo de CPU/RAM/disco, por lo que los resultados variarán no sólo en función del hardware, sino también según el sistema operativo, librerias e incluso el compilador.

El caso es que no he encontrado ninguna comparativa "facilona" (que puedas ver de un vistazo) como ésta de sistemas pequeños (SoC/NAS/Barebone/HTPC/Mini PC), así que he pensado que podía intentar recopilar los que pudiese con la ayuda de quien quiera y pueda colaborar a ésta recolección de datos. De momento ya hay unos pocos y espero y deseo poder ir recopilando más.

El recurso puede encontrarse aquí en inglés para tratar de llegar a un mayor público, pero a modo de resumen, los pasos a seguir para colaborar serian los siguientes:

  1. Descargar Unixbench desde aquí.
  2. Extraer los ficheros y ejecutar:
  3. ./Run -c `cat /proc/cpuinfo | grep processor | wc -l`

    Avisar que la primera vez que se ejecute, la aplicación necesita compilar un par de cosas, así que asegúrate de tener los paquetes make, gcc y build-essential (en caso de Debian) o instálalos. De otro modo, la compilación fallará.

  4. Esperar a que termine el script y muestre la salida.
  5. Una vez haya terminado, enviarme un correo (a jors*at*enchufado*dot*com) con lo siguiente:
    • Marca y modelo del aparato (la salida de dmidecode sería lo ideal)
    • URL del producto (si tiene)
    • Sistema Operativo y versión
    • Resultados de Unixbench

¡Agradecido desde ya por cualquier contribución! :)

]]>
Infiniband en Debian GNU/Linux Wheezy http://enchufado.com/post.php?ID=368 http://enchufado.com/post.php?ID=368 Mon, 14 Apr 2014 00:30:46 +0200Los motivos de la elección de Infiniband por encima de otras opciones pueden ser la alta tasa de transferencia (10, 20 o incluso más Gbps), la baja latencia, el bajo precio si nos decidimos por hardware de segunda mano (comparado p.ej. con 10GbE) y la posibilidad de hacerlo funcionar con el protocolo ip (IPoIB / IP over Infiniband). Algún que otro inconveniente puede ser que la rigidez de los cables puede complicar la instalación y que no hay instrucciones claras -o no las supe encontrar- de cómo echarlo a andar.

Así pues, vamos al lio. Las tarjetas que cayeron en nuestras manos fueron unas Mellanox MT25418.

  1. La pinchamos en el servidor y tendríamos que verla:
  2. # lspci
    07:00.0 InfiniBand: Mellanox Technologies MT25418 [ConnectX VPI PCIe 2.0 2.5GT/s - IB DDR / 10GigE] (rev a0)
    
    # dmesg | grep -i mlx4
    [    4.500835] mlx4_core: Mellanox ConnectX core driver v1.0 (July 14, 2011)
    [    4.500839] mlx4_core: Initializing 0000:07:00.0
    [    4.500889] mlx4_core 0000:07:00.0: setting latency timer to 64
    [    6.492856] mlx4_core 0000:07:00.0: irq 84 for MSI/MSI-X
    [    6.492864] mlx4_core 0000:07:00.0: irq 85 for MSI/MSI-X
    [    6.492873] mlx4_core 0000:07:00.0: irq 86 for MSI/MSI-X
    [    6.492879] mlx4_core 0000:07:00.0: irq 87 for MSI/MSI-X
    [    6.492887] mlx4_core 0000:07:00.0: irq 88 for MSI/MSI-X
    [    6.492894] mlx4_core 0000:07:00.0: irq 89 for MSI/MSI-X
    [    6.492901] mlx4_core 0000:07:00.0: irq 90 for MSI/MSI-X
    [    6.492907] mlx4_core 0000:07:00.0: irq 91 for MSI/MSI-X
    [    6.492914] mlx4_core 0000:07:00.0: irq 92 for MSI/MSI-X
    [    6.492921] mlx4_core 0000:07:00.0: irq 93 for MSI/MSI-X
    [    6.492928] mlx4_core 0000:07:00.0: irq 94 for MSI/MSI-X
    [    6.492935] mlx4_core 0000:07:00.0: irq 95 for MSI/MSI-X
    [    6.492942] mlx4_core 0000:07:00.0: irq 96 for MSI/MSI-X
    [    6.492949] mlx4_core 0000:07:00.0: irq 97 for MSI/MSI-X
    
    # lsmod | grep mlx
    mlx4_core              78702  0
    
  3. Como vemos ya carga algún módulo, pero no es suficiente, así que cargamos otros necesarios:
  4. # modprobe ib_ipoib mlx4_en mlx4_ib
    
  5. Si no trabajamos con un switch Infiniband, también necesitamos instalar el paquete opensm para tener link ACTIVE (en el siguiente punto vemos cómo poder consultarlo):
  6. # aptitude install opensm
    
  7. Podemos obtener un poco de información de la tarjeta/interfície de distintas maneras:
  8. # Bien consultando /sys, p.ej. consultando el modo de conexión Infiniband:
    # cat /sys/class/net/ib0/mode 
    datagram
    # cat /sys/class/net/ib1/mode 
    datagram
    
    # Bien instalando el siguiente paquete:
    # apt-get install infiniband-diags
    # ibstat
    ibwarn: [8624] umad_init: can't read ABI version from /sys/class/infiniband_mad/abi_version (No such file or directory): is ib_umad module loaded?
    ibpanic: [8624] main: can't init UMAD library: (No such file or directory)
    
    # En éste caso nos falta cargar otro módulo:
    # modprobe ib_umad
    
    # Ahora sí:
    # ibstat
    CA 'mlx4_0'
     CA type: MT25418
     Number of ports: 2
     Firmware version: 2.6.0
     Hardware version: a0
     Node GUID: 0x001a4bffff0cf264
     System image GUID: 0x001a4bffff0cf267
     Port 1:
      State: Active ('Initializing' si no está instalado opensm!)
      Physical state: LinkUp
      Rate: 20
      Base lid: 2 ('0' si no está instalado opensm!)
      LMC: 0
      SM lid: 1 ('0' si no está instalado opensm!)
      Capability mask: 0x0251086a ('0x02510868' si no está instalado opensm!)
      Port GUID: 0x001a4bffff0cf265
     Port 2:
      State: Down
      Physical state: Polling
      Rate: 8
      Base lid: 0
      LMC: 0
      SM lid: 0
      Capability mask: 0x02510868
      Port GUID: 0x001a4bffff0cf266
    
    # ibhosts
    Ca	: 0x001a4bffff0c22b8 ports 2 "MT25408 ConnectX Mellanox Technologies"
    Ca	: 0x001a4bffff0cf264 ports 2 "MT25408 ConnectX Mellanox Technologies"
    
  9. También podemos instalar un poco de literatura (documentación) acerca del tema:
  10. # apt-get install ofed-docs
    # dpkg -S ofed-docs
    ofed-docs: /usr/share/doc/ofed-docs/DEBIAN-HOWTO/infiniband-howto.txt.gz
    ofed-docs: /usr/share/doc/ofed-docs/DEBIAN-HOWTO/infiniband-howto-6.html
    ofed-docs: /usr/share/doc/ofed-docs/mpi-selector_release_notes.txt
    ofed-docs: /usr/share/doc/ofed-docs/copyright
    (...)
    # zless /usr/share/doc/ofed-docs/ipoib_release_notes.txt.gz
    

    De la misma, sacamos un poco de tunning con sysctl, si bien aparentmente no marca ninguna diferencia:

    # sysctl -p
    net.ipv4.tcp_timestamps = 0
    net.ipv4.tcp_sack = 0
    net.core.netdev_max_backlog = 250000
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.core.rmem_default = 16777216
    net.core.wmem_default = 16777216
    net.core.optmem_max = 16777216
    net.ipv4.tcp_mem = 16777216 16777216 16777216
    net.ipv4.tcp_rmem = 4096 87380 16777216
    net.ipv4.tcp_wmem = 4096 65536 16777216
    
  11. Finalmente ya sólo nos queda asignar un direccionamiento ip a las interfaces (mapeadas como ib0, ib1, etc...) y ya podemos proceder a hacer pruebas de ancho de banda:
  12. # iperf -c 10.99.99.4
    ------------------------------------------------------------
    Client connecting to 10.99.99.4, TCP port 5001
    TCP window size:  649 KByte (default)
    ------------------------------------------------------------
    [  3] local 10.99.99.3 port 55727 connected with 10.99.99.4 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  13.1 GBytes  11.3 Gbits/sec
    
    # iperf -c 10.99.99.4
    ------------------------------------------------------------
    Client connecting to 10.99.99.4, TCP port 5001
    TCP window size:  649 KByte (default)
    ------------------------------------------------------------
    [  3] local 10.99.99.3 port 55728 connected with 10.99.99.4 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  13.3 GBytes  11.4 Gbits/sec
    
    # iperf -s
    ------------------------------------------------------------
    Server listening on TCP port 5001
    TCP window size: 85.3 KByte (default)
    ------------------------------------------------------------
    [  4] local 10.99.99.4 port 5001 connected with 10.99.99.3 port 55727
    [ ID] Interval       Transfer     Bandwidth
    [  4]  0.0-10.0 sec  13.1 GBytes  11.3 Gbits/sec
    [  5] local 10.99.99.4 port 5001 connected with 10.99.99.3 port 55728
    [  5]  0.0-10.0 sec  13.3 GBytes  11.4 Gbits/sec
    

Referencias:

http://blog.maumene.com/installing-the-mlx4-ib-driver-for-infiniband-on-debian-squeeze
http://inqbus-hosting.de/support/dokumentation/docs/debian-infiniband-howto
http://pkg-ofed.alioth.debian.org/howto/infiniband-howto-5.html#ss5.4
https://www.kernel.org/doc/Documentation/infiniband/ipoib.txt]]>
MySQL HA Multi-Master con Percona XtraDB Cluster, parte II http://enchufado.com/post.php?ID=367 http://enchufado.com/post.php?ID=367 Fri, 27 Dec 2013 16:26:51 +0100En un post previo vimos cómo crear una infraestructura Multi-Master con Percona XtraDB Cluster, pero si hacemos caso omiso a las recomendaciones y montamos clusters de 2 nodos, si se pierde la conexión entre los 2 nodos del cluster se pierde el quorum (cada nodo obtiene el 50%). Y ésto no sólo rompe el cluster, sino que además cada nodo por separado deja de funcionar.

Éste hecho lo tratan en la documentación de Percona relativa al failover:

Cluster Failover

The size of the cluster is used to determine the required votes to achieve 
quorum. A quorum vote is done when a node or nodes are suspected to no longer 
be part of the cluster (they do not respond). This no response timeout is the 
evs.suspect_timeout setting in the wsrep_provider_options (default 5 sec), and 
when a node goes down ungracefully, write operations will be blocked on the 
cluster for slightly longer than that timeout.

Once the node (or nodes) is determined to be disconnected, then the remaining 
nodes cast a quorum vote and if a majority remain from the total nodes 
connected from before the disconnect, then that partition remains up. In the 
case of a network partition, some nodes will be alive and active on each side 
of the network disconnect. In this case, only the quorum will continue, the 
partition(s) without quorum will go to the non-Primary state.

Because of this, it’s not possible to safely have automatic failover in a 2 
node cluster, because the failure of one node will cause the remaining node 
to go non-Primary. Further, cluster with an even number of nodes (say two 
nodes in two different switches) have some possibility of a split brain 
condition when if network connectivity is lost between the two partitions, 
neither would retain quorum, and so both would go to Non-Primary. Therefore: 
for automatic failover, the “rule of 3s” is recommended. It applies at various 
levels of infrastructure, depending on how far cluster is spread out to avoid 
single points of failure.

Ante éste escenario, ¿qué soluciones se nos ofrecen? En éste enlace de MySQL Performance Blog hablan del tema:

*Is is possible anyway to have a two nodes cluster?*

So, by default, Percona XtraDB Cluster does the right thing, this is how
it needs to work and you don’t suffer critical problem when you have
enough nodes. But how can we deal with that and avoid the resource to
stop ? If we check the list of parameters on galera’s wiki 
(http://www.codership.com/wiki/doku.php?id=galera_parameters_0.8) we can
see that there are two options referring to that:

- pc.ignore_quorum: Completely ignore quorum calculations. E.g. in
case master splits from several slaves it still remains operational. Use
with extreme caution even in master-slave setups, because slaves won’t
automatically reconnect to master in this case.

- pc.ignore_sb: Should we allow nodes to process updates even in the
case of split brain? This is a dangerous setting in multi-master setup,
but should simplify things in master-slave cluster (especially if only 2
nodes are used).

By ignoring the quorum (*wsrep_provider_options = “pc.ignore_quorum =
true”*), we ask to the cluster to not perform the majority calculation
to define the Primary Component (PC). A component is a set of nodes
which are connected to each other and when everything is ok, the whole
cluster is one component. For example if you have 3 nodes, and if 1 node
gets isolated (2 nodes can see each others and 1 node can see only
itself), we have then 2 components and the quorum calculation will be
2/3 (66%) on the 2 nodes communicating each others and 1/3 (33%) on the
single one. In this case the service will be stopped on the nodes where
the majority is not reached. The quorum algorithm helps to select a PC
and guarantees that there is no more than one primary component in the
cluster.

In our 2 nodes setup, when the communication between the 2 nodes is
broken, the quorum will be 1/2 (50%) on both node which is not the
majority… therefore the service is stopped on both node. In this case,
__/service/__means accepting queries.

By ignoring the splitbrain situation (*wsrep_provider_options =
“pc.ignore_sb = true”*). When the quorum algorithm fails to select a
Primary Component, we have then a split-brain condition. In our 2 nodes
setup when a node loses connection to it’s only peer, the default is to
stop accepting queries to avoid database inconsistency. If we bypass
this behaviour by ignoring the split-brain, then we can insert in both
nodes without any problem when the connection between the nodes is gone.
When the connection is back, the two servers are like independent, these
are now two single node clusters.

This is why two node clusters is not recommended at all. Now if you have
only storage for 2 nodes, using the galera arbitrator
(http://www.codership.com/wiki/doku.php?id=galera_arbitrator) is a very
good alternative then. On a third node, instead of running Percona
XtraDB Cluster (mysqld) just run *garbd*. Currently there is no init
script for garbd, but this is something easy to write as it can run in
daemon mode using -d:

garbd -a gcomm://192.168.70.2:4567 -g trimethylxanthine

If the communication fails between node1 and node2, they will
communicate and eventually send the changes through the node running
garbd (node3) and if one node dies, the other one behaves without any
problem and when the dead node comes back it will perform its IST or SST.

*In conclusion:* 2 nodes cluster is possible with Percona XtraDB Cluster
but it’s not advised at all because it will generates a lot of problem
in case of issue on one of the nodes. It’s much safer to use then a 3rd
node even a fake one using garbd.

If you plan anyway to have a cluster with only 2 nodes, don’t forget that:

- by default if one peer dies or if the communication between both nodes
is unstable, both nodes won’t accept queries.
- if you plan to ignore split-brain or quorum, you risk to have
inconsistent data very easily.

Así pues, podemos ver que la mejor solución para un cluster con 2 nodos pasa por crear un nuevo 'thin node' con un demonio (garbd, también conocido como galera arbitrator) para no encontrarnos con split brains a la mínima que los 2 nodos pierdan comunicación y evitar así que ésto pase. Cierto es que ésto supone usar un tercer nodo, pero sólo lo será a efectos de quorum, pues no aloja ni datos ni siquiera la parte cliente/servidor de MySQL.

Antes de proceder, nótese que usamos las direcciones de red del post previo relativo al tema más una nueva dirección ip para el 'thin node' (192.168.0.63). Asimismo, aquí asumimos que en el escenario que nos ocupa (con 2 nodos "reales") usaremos una configuración Unicast. Así pues, vamos a ello:

  1. Instalamos el paquete que contiene el demonio:
  2. $ apt-get install percona-xtradb-cluster-galera-2.x
    
  3. Iniciamos el demonio indicando la cadena de conexión, el nombre del cluster y un fichero de log que nos puede ayudar en caso de necesitarlo:
  4. garbd -d -a gcomm://192.168.0.61,192.168.0.62,192.168.0.63 -g my_percona_cluster -l /var/log/garbd.log
    

    Hay que tener en cuenta de modificar y tener el mismo string de conexión (gcomm://...) en todos los nodos, adaptándolo para nuestro caso.

  5. Si la comunicación es correcta con los demás nodos del cluster, esto debería ser cuanto se necesita. Comprobamos que tengamos el nuevo 'thin node' unido al cluster:
  6. $ mysql> show status like 'wsrep%';
    | wsrep_cluster_conf_id      | 19                                   |
    | wsrep_cluster_size         | 3                                    |
    
  7. Finalmente podemos situar éste demonio para que se inicie automáticamente (p.ej. en /etc/rc.local).

Con ésto, podemos hacer la prueba de bajar uno de los 2 nodos "reales" por un tiempo y veremos que podemos seguir lanzando queries al restante. Y no sólo eso, puesto que cuando el caído vuelva en sí, se podrá al día de los cambios que sufrió el primero.

]]>
http://enchufado.com/post.php?ID=366 http://enchufado.com/post.php?ID=366 Sun, 15 Dec 2013 22:03:50 +0100Para empezar, comentar que Policyd es un sistema antispam para Postfix que hace muchas cosas: greylisting, throttling, rate limiting, spamtrap y blacklisting/whitelisting. Aquí vamos a usar la función de throttling o de limitación del número de correos por unidad de tiempo. Efectivamente, usaremos Debian GNU/Linux, aunque partes de la guía puedan adaptarse a otras distros.

Al lío:

  1. Instalamos el paquete:
  2. $ apt-get install postfix-policyd

    A modo de nota informativa, la instalación del paquete nos crea automáticamente la BD postfixpolicyd en MySQL, y la tabla que nos interesa aquí es throttle.

  3. Configuración de la opción de throttling (sección SENDER THROTTLE):
  4. $ vi /etc/postfix-policyd.conf:
    
    # Habilitamos el sender throttling.
    SENDERTHROTTLE=1
    # Le decimos que dé un rechazo temporal (4xx) en lugar de uno definitivo (5xx).
    QUOTA_EXCEEDED_TEMP_REJECT=1
    # Ponemos un mensajito que nos sirva para identificarlo.
    SENDER_QUOTA_REJECTION="Quota Exceeded (check policyd!)."
    SENDER_SIZE_REJECTION="Message size too big (check policyd!)."
    # Definimos la quota de número de correos permitido por unidad de tiempo...
    SENDERMSGLIMIT=200
    # ...así como la cantidad de destinatarios permitidos.
    SENDERRCPTLIMIT=500
    # Y el tamaño máximo total transferido. Ojo porque tiene un hardlimit en 2GB.
    SENDERQUOTALIMIT=2000000000
    # La unidad de tiempo en que ésta limitación se reinicializa/resetea.
    SENDERTIMELIMIT=1h
    # El tamaño máximo del mensaje (100MB).
    SENDERMSGSIZE=102400000
    # Y finalmente los umbrales de los avisos, que iran a syslog.
    SENDERMSGSIZE_WARN=50
    SENDERMSGSIZE_PANIC=90
    SENDER_INACTIVE_EXPIRE=5d
    
  5. Reiniciamos el servicio para aplicar éstos cambios:
  6. $ /etc/init.d/postfix-policyd restart
  7. Finalmente incluimos éste filtro en postfix y lo reiniciamos también:
  8. $ vi /etc/postfix/main.cf:
    smtpd_end_of_data_restrictions =
            check_policy_service inet:127.0.0.1:10031,
            permit_mynetworks
    
    $ /etc/init.d/postfix restart
    
  9. Opcional: hice éste pequeño script de monitoritzación en PHP a modo de interfaz gráfico web que toma los valores de la base de datos para poder consultar (y también resetear) el estado de éste throttling. Sustituir los campos ip, db_user y dp_password al principio del script por unos correctos para tu setup.

Y con ésto ya tendríamos funcionando el throttling, cuyo estado podemos consultar a través de la base de datos, los logs o el mencionado script.

]]>