Balanceador de carga MySQL con HAProxy

balanceadorHace unas semanas, vimos cómo configurar un balanceador de carga con la aplicación de balanceo en entornos Red Hat por antonomasia: LVS, (y Piranha). LVS es la aplicación nativa de balanceo, muy bien documentada en la documentación oficial de Red Hat, e incluso vendida como balanceador en forma de addons.

Este tipo de configuraciones, funcionan muy bien, pero tienen una serie de requisitos, pues se ha de reconfigurar la red de los servidores implicados para compartir una IP Virtual, o para cambiar el default gateway (en el caso de LVS-NAT). Ésto no siempre nos es posible hacerlo, puesto que quizá estemos trabajando con un proveedor de servidores dedicados, como en mi caso Hetzner, que no permite hacer cambios en las interfaces de red que vienen configuradas en el equipo, y que además parece que no lleva bien lo de las IPs compartidas.

En cualquier caso, hay otras soluciones de balanceo, como HA Proxy, que en el siguiente ejemplo usaré para balancear las peticiones MySQL entre dos servidores con IPs públicas situados bajo el mismo switch, en Hetzner. Todos los servidores son CentOS 6.3 x64.

Continuar leyendo «Balanceador de carga MySQL con HAProxy»

Instalar el rpm de opendkim en Fedora 13

Spam dkimDKIM (DomainKeys Identified Mail) es un mecanismo de autentificación para luchar contra el spam, que consiste en (y aquí prácticamente copio de la wikipedia) añadir una cabecera llamada «DKIM-Signature»que contendrá una firma digital tanto de la cabecera como del cuerpo del mensaje. El destinatario, hará una consulta DNS usando el dominio origen y un selector, contra un registro DNS del tipo TXT del estilo selector._domainkey.dominio.com que contendrá la clave pública necesaria para descifrar el valor de la firma de la cabecera y verificar así su procedencia.

Aquí explican mejor qué es y cómo funciona DKIM, pero en esta ocasión, lo que veremos no es explicar cómo funciona, si no cómo usar nuestro servidor de correo (postfix sobre un antiguo Fedora 13) para firmar nuestros mails mediante opendkim, instalando el rpm oficial en lugar de instalarlo mediante yum. Instalar el rpm seguramente tenga más trabajo que hacerlo desde yum, pero el proceso servirá en cualquier distribución basada en Red Hat.

Continuar leyendo «Instalar el rpm de opendkim en Fedora 13»

Guardar la hora en el history de Linux

history linux

Algo que nos puede venir muy bien, es modificar el history de linux para:

  1. Almacenar la fecha y la hora en la que se ejecutaron los comandos
  2. Aumentar el límite por defecto del history para almacenar más comandos

En entornos RedHat (he hecho la prueba en un CentOS 6.3), en lugar de modificar el .bashrc de cada usuario, se puede modifiar el script de bash global, para que afecte a todos los usuarios del sistema. Sin embargo, esta modificación no se debe hacer directamente en  /etc/bashrc, si no que es preferible crearse un fichero donde ir añadiendo las modificaciones globales, sin tocar los archivos de sistema.

Continuar leyendo «Guardar la hora en el history de Linux»

RAID1 vs RAID0 en replicación MySQL

MySQL RAIDHoy vamos a intentar mejorar la replicación de un slave MySQL, cuyo master recibe demasiadas modificaciones como para que el slave sea capaz de seguirle el ritmo. El problema que tienen los slaves, es que con versiones anteriores a MySQL 5.6, la replicación usa un único thread, y por tanto, las sentencias a replicar se ejecutan de forma secuencial. En realidad, si usamos una única base de datos, con MySQL 5.6 y su replicación con múltiples threads, no ganamos nada, puesto que MySQL 5.6 aporta un thread por base de datos.

El testeo se ha realizado con servidores CentOS 6.3 a 64 bits, con dos discos SATA 7200rpm.

Identificando el problema

En cualquier caso, el primer paso es identificar el problema, lo cual de forma natural haríamos con un «top». A continuación veremos como el único proceso del server consumiendo algo de recursos es el proceso mysqld, que a pesar de eso, no llega ni mucho menos a provocar un problema de CPU ni de RAM. Sin embargo, si que vemos un 9.6% de %iowait lo cual indica que podríamos tener ahí el cuello de botella.

[root@slave]$ top
top – 12:28:38 up 23:10,  1 user,  load average: 2.76, 2.72, 2.69
Tasks: 211 total,   3 running, 208 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.6%sy,  0.0%ni, 85.8%id,  9.6%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  32776052k total, 32519856k used,   256196k free,   156192k buffers
Swap: 16777136k total,   122344k used, 16654792k free,  9163420k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4450 mysql     20   0 29.0g  21g 4628 S 37.7 68.0 394:26.55 mysqld 
584 root      20   0     0    0    0 S  6.0  0.0  70:17.46 md4_raid1

Continuar leyendo «RAID1 vs RAID0 en replicación MySQL»

nf_conntrack: table full, dropping packet

NetworkingEsta semana me he encontrado con un servidor CentOS con varios mensajes de error como el que sigue, en su fichero de logs messages:

Mar 14 18:55:48 localhost kernel: nf_conntrack: table full, dropping packet.

Ya había visto antes este error, que se solucionaría de forma radical, reiniciando el server, pero por suerte un compañero ya había hecho algo de investigación sobre este mismo problema.

Para empezar, ¿a qué se refiere este problema? Aquí lo explican bastante bien. El Connection Tracking le permite al kernel mantener un seguimiento de todas las conexiones (o sesiones) abiertas con el servidor, y poder así relacionar los paquetes con su correspondiente conexión. Así, Connection Tracking puede entender que dos o más conexiones distintas están «relacionadas». Por ejemplo, cuando se abre una sesión FTP, primero se abre una conexión contra el puerto 21 para iniciar la sesión FTP, y después se abre otra conexión contra el 20 o contra un puerto aleatorio en función de como tengamos configurado el servidor FTP. En cualquier caso, el Connection Tracking se encargaría de marcar ambas conexiones como relacionadas (RELATED).

Continuar leyendo «nf_conntrack: table full, dropping packet»

Downgrade o cambio de versión de PHP

PHP choiceInteresante post, éste, que explica cómo cambiar la versión de PHP con un ejemplo real, ya sea, haciendo un downgrade de la versión de PHP o instalando a una versión concreta. Este ejemplo está ejecutando en una máquina con CentOS 6.3 64 bits, con el repositorio de remi instalado.

Primero, podemos ver qué versión tenemos.

# php -v
PHP 5.4.11 (cli) (built: Jan 16 2013 16:51:38)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Con yum, podemos, a continuación, ver qué versiones tenemos disponibles en los diferentes repositorios.

# yum –showduplicates list php
Available Packages
php.x86_64               5.3.3-3.el6_2.8                                                   base
php.x86_64               5.3.3-14.el6_3                                                    updates
php.x86_64               5.4.10-1.el6.remi                                                remi
php.x86_64               5.4.11-1.el6.remi                                                remi

Continuar leyendo «Downgrade o cambio de versión de PHP»

Seconds_Behind_Master no para de crecer

timeYa hemos hablado de replicación Master-Slave (o replicación) con anterioridad, pero, ¿cómo saber en qué estado están los slaves? ¿Está todo funcionando?

Hay un comando sumamente útil (y necesario) que nos muestra una serie de información, que nos puede venir muy bien para saber cómo están nuestros slaves. El comando lo ejecutaríamos en el cliente MySQL de cada servidor slave:

mysql> show slave status\G;

Entre la información que devuelve, destacan dos variables que han de estar a «Yes» para asegurar que la replicación está funcionando:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

El parámetro «Seconds_Behind_Master» también nos ayudará a ver cómo de sincronizado va ese slave, respecto al master, en segundos, pero no es un valor muy exacto.

Continuar leyendo «Seconds_Behind_Master no para de crecer»

Cloud Computing VS Servidor Dedicado

Cloud ComputingGran pregunta. Difícil Respuesta. La fácil es… depende. Hasta aquí estaba claro. Pero no sólo depende de cuales sean tus necesidades, también depende de qué proveedor vayas a elegir.

Cloud Computing

He trabajado mucho durante los últimos dos años, con dos de las empresas de Cloud Computing más importantes, Amazon AWS y RackSpace. ¿Cómo me ha ido?

Bueno, para empezar he aprendido que Cloud Computing es sinónimo de flexibilidad y agilidad. Es trementamente útil para proyectos que reciben cargas de trabajo extremadamente diferentes en función del día o la hora, o en función del resultado de determinada campaña de márketing. Por ejemplo, puedes aumentar o disminuir los recursos de tu máquina, según necesites, en cuestión de minutos. Incluso Amazon tiene un servicio llamado «Cloud Watch Auto Scaling» que te permite aumentar o disminuir recursos de forma totalmente automática, en función de la carga del servidor. Escalado vertical tremendamente fácil y rápido.

Continuar leyendo «Cloud Computing VS Servidor Dedicado»

Balanceador de carga con LVS y Piranha

cloud computingEn este artículo veremos cómo configurar un balanceador de carga con LVS y Piranha, en un servidor CentOS, con un único router LVS. Hay muchos artículos por Internet que explican cómo hacerlo con 2 routers, para conseguir así tener alta disponibilidad en el balanceador, pero no siempre se disponen de dos máquinas para conseguir la alta disponibilidad. Como añadido, el servicio a balancear será MySQL, no Apache como suele ser habitual.

Para el test, los sevidores tienen las siguientes características, además de selinux deshabilitado e iptables configurado:

Hostname: balancer
IP: (eth0) 192.168.2.228. Default gw: 192.168.2.1

Hostname: mysql1
IP: (eth0) 192.168.2.241. Default gw: 192.168.2.1

Hostname: mysql2
IP: (eth1) 192.168.2.242. Default gw: 192.168.2.1

Continuar leyendo «Balanceador de carga con LVS y Piranha»

Load Average

Load AverageEl Load Average nos sirve para hacernos una idea de la carga del servidor actual, y de los últimos minutos, en media. Se puede ver con el comando «top», en la esquina superior derecha, o con el comando «uptime», por ejemplo.

[user@server ~]$ uptime
09:38:57 up 6 days, 6:33, 1 user, load average: 2.05, 1.59, 1.56

En estos comandos, el Load Average muestra 3 números, correspondientes al Load Average del sistema en el último minuto, los últimos 5 y los últimos 15. En realidad, interesará especialmente el Load Average de los últimos 5 y 15 minutos, puesto que puntualmente (en el último minuto) podría haber una carga alta, pero nos empezaremos a preocupar cuando la elevada carga dure varios minutos.

El Load Average es la media de procesos que han estado:
a) Usando CPU o esperando a usarla
b) Esperando obtener acceso I/O

Así pues, nos puede ayudar a detectar problemas de CPU o de I/O. Un alto Load Average y un bajo uso de CPU nos apuntará a que hemos de usar iostat para revisar la i/o e iotop para acabar de identificar el problema.

El Load Average no se adaptará al número de CPUs, así que hay que tenerlo en cuenta a la hora de intepretar sus valores. Un Load Average de 1, cuando se tiene una CPU, indicará que la CPU se está usando al 100% y que todos los procesos están entrando en la CPU. Pero cuando se tienen 4 CPUs, un LoadAverage de 1 indica que sólo se está usando el 25% del total.

Fuente: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

Flickr! Foto por 4Cheungs