Publicado el

Instalar y configurar MySQL Percona XtraDB Clúster

clusterPercona XtraDB Clúster, es la solución de alta disponibilidad y balanceo de carga multi-máster del fork de MySQL «Percona». La solución recomendada para un cluster necesita un mínimo de 3 nodos, pero siempre un número impar de nodos. En este post, sin embargo, montaremos un cluster Percona con 2 nodos y un árbitro -todo con Percona XtraDB Cluster 5.5 y wsrep_provider_version 2.6(r152)- puesto que supondremos que únicamente disponemos de dos servidores dedicados para el clúster. Más adelante se explicará qué es y para qué sirve un árbitro.

Percona Master-Slave vs XtraDB Clúster

Master-slave consta de un único servidor que permite escrituras, mientras que resto de nodos (slaves) únicamente permiten lecturas. Los slaves replicarán los datos del único master, y se mantendrá así los mismos datos en todos los nodos de la solución. En este caso, si se dispone de un balanceador para los slaves, tendremos un balanceo de carga para las lecturas, lo cual hace de esta solución una solución ideal para entornos con un alto volumen de lecturas. Además, se conseguirá un entorno de alta disponibilidad para las lecturas, pero no así para las escrituras.

Con XtraDB Clúster tendremos múltiples servidores corriendo varios MySQL (basados en Percona) con los mismos datos, permitiendo a los clientes escribir en cualquiera de los servidores, y replicando los datos al resto de nodos del clúster. Ésto es ideal para entornos donde hay un gran volumen de escrituras, pero también de lecturas, o donde necesitemos tener alta disponibilidad, también de los nodos «master» (que permiten escrituras).

Limitaciones

Percona XtraDB Cluster, está basado en Galera Cluster (igual que MariaDB Cluster), y por tanto, a día de hoy, tiene un seguido de limitaciones  de entre las que destacan:

  • La replicación sólo funcionará con las tablas InnoDB. Puede haber otras tablas pero no se replicarán, lo cual significa que no se encontrarán en todo el clúster, únicamente existirán en ese nodo.
  • La velocidad de escritura de todo el clúster, viene delimitado por el nodo más lento. Si un nodo tiene problemas y se vuelve lento, el clúster entero será lento.
  • Puede darse el caso de que dos clientes estén modificando la misma celda al mismo tiempo. Si ésto ocurriera, únicamente uno de los dos tendría éxito, mientras que el otro recibiría un error de MySQL.
  • Se recomienda un mínimo de 3 nodos, aunque en la documentación oficial también confirman que se puede montar con 2 nodos. En entornos con dos nodos es altamente recomendable montar un árbitro (que es lo que haremos).
  • Ver listado completo.

Continuar leyendo «Instalar y configurar MySQL Percona XtraDB Clúster»

Publicado el

Cómo configurar VirtualHosts para HTTPS

ApacheEn Apache, usamos los VirtualHosts para poder definir diferentes proyectos web, cada uno con su propio dominio (o dominios), escuchando tras el mismo puerto e IP. Ésto podemos hacerlo para conexiones HTTP normales, pero antiguamente no se podía para HTTPS, puesto que la conexión venía cifrada y por tanto Apache no podía saber a qué dominio se quería acceder.

Al parecer, desde el 2006 se incorporó una extensión que le permitía al cliente (el navegador del usuario) enviar el dominio a consultar en la primera petición, antes de iniciar la transferencia cifrada de datos, permitiéndo así al servidor poder usar el mecanismo de VirtualHosts para tener varios sitios web HTTPS escuchando por el mismo puerto (típicamente el 443).

Requisitos

Seguramente nuestro servidor Linux con Apache ya tenga instalados los requisitos para funcionar, pero para asegurarnos, bastará con confirmar que tenemos:

  • openSSL 0.9.8f o posterior instalado
  • mod_ssl instalado en Apache

En mi ejemplo, un Fedora release 13 (Goddard) con Apache 2.2.15, lo he confirmado así:

[root@myServer]# openssl version
OpenSSL 1.0.0d-fips 8 Feb 2011

[root@myServer]# httpd -M | grep -i ssl
ssl_module (shared)

[root@myServer]# grep -i ssl /var/log/httpd/error_log*
Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.4 Python/2.7.5 configured — resuming normal operations

Si no tienes openssl ni mod_ssl, puedes instalarlo con yum y posteriormente reiniciar Apache:

[root@myServer]# yum install openssl mod_ssl
[root@myServer]# /etc/init.d/httpd restart

Continuar leyendo «Cómo configurar VirtualHosts para HTTPS»

Publicado el

VPN entre dos servidores con openVPN

openvpntech_logo1Hoy vamos a montar una VPN entre dos servidores ubicados en dos CPDs distintos, para que puedan comunicarse entre ellos a través de un canal seguro. En mi caso, he usado el túnel VPN (Full TLS) para conectar dos servidores MySQL que replican los datos el uno del otro. De esta forma, los datos que se replican de la base de datos viajan por Internet a través de un canal privado y seguro.

He hecho las pruebas en el siguiente entorno:

  • OpenVPN 2.3.2 x86_64-redhat-linux-gnu

Un servidor CentOS 6.4 con 512MB de RAM, instancia de RackSpace (sí, 512MB de RAM, y estamos en 2013, sí).

  • Hostname: vpntest1
  • IP pública: 80.80.80.81
  • IP privada: 10.10.10.81

Un segundo servidor CentOS 6.4 con 512MB de RAM, instancia de RackSpace en un CPD diferente.

  • Hostname: vpntest2
  • IP pública: 80.80.80.82
  • IP privada: 10.10.10.82

Por defecto, los servidores vienen con selinux deshabilitado, iptables parado, y no pueden hacer ping entre sí mediante sus ips privadas pero sí mediante sus ips públicas. He seguido, en mayor parte, este fantástico tutorial que han hecho los técnicos de Rackspace.

También es importante configurar ntp en ambos servidor, para que tengan la hora sincronizada.

Continuar leyendo «VPN entre dos servidores con openVPN»

Publicado el

Automatiza el mantenimiento de directorios temporales en Linux

cleanNo sé cómo he podido vivir tanto tiempo sin conocer tmpwatch, una herramienta que suele venir con el sistema y que nos permite automatizar el mantenimiento de directorios que por su naturaleza, acumulan ficheros temporales que pocas veces se vuelven a usar. tmpwatch, por lo tanto, busca los ficheros y directorios antiguos en una determinada ubicación, y los elimina de forma recursiva. Lo que antes solía hacer con una instrucción como la siguiente, ahora lo haré con tmpwatch:

# eliminación ficheros con más de 365 días desde la última modificación desde el directorio actual
find . -mtime +365 -exec rm {} \;

# eliminación ficheros con más de 365 días desde la última modificación desde el directorio actual y sub-directorios
find . -depth -mtime +365 -exec rm {} \;

Un ejemplo muy claro, es usar tmpwatch para eliminar los ficheros que no se han usado (access time) en los últimos x días (o meses) dentro de directorios como /tmp o ~/Downloads. En cuanto a servidores, seguro que tendemos la típica aplicación que va dejando cientos de archivos temporales en una determinada ubicación, que hemos de estar borrando cada cierto tiempo ya sea a mano o con algún script programado en el cron.

Continuar leyendo «Automatiza el mantenimiento de directorios temporales en Linux»

Publicado el

MongoDB: Recuperar un config server

mongodbHoy me he encontrado, que tras una caída de un servidor que alojaba un config server de mi cluster MongoDB 2.2.0 (sobre un entorno Red Hat), el config server no era capaz de arrancar. Concretamente, al intentar iniciar el config server, podría ver los siguientes logs en el fichero de error:

Thu Sep 12 11:47:37 [initandlisten] dbexception during recovery: 15874 couldn’t uncompress journal section
Thu Sep 12 11:47:37 [initandlisten] exception in initAndListen: 15874 couldn’t uncompress journal section, terminating
Thu Sep 12 11:47:37 dbexit:
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close listening sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to flush diaglog…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: waiting for fs preallocator…
Thu Sep 12 11:47:37 [initandlisten] shutdown: lock for final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: closing all files…
Thu Sep 12 11:47:37 [initandlisten] closeAllFiles() finished
Thu Sep 12 11:47:37 [initandlisten] shutdown: removing fs lock…
Thu Sep 12 11:47:37 dbexit: really exiting now

Al parecer, el fichero de journal se ha corrompido con la caída del server y ni si quiera es capaz de solucionarse con un «–repair». Aprovechando que mi cluster tiene 3 config servers, he pasado a parar uno de los dos config servers que aun funcionaban, para copiar los datos del dbpath al config server corrompido, con tal de recuperarlo.

El proceso ha sido el siguiente, descrito en la documentación oficial de MongoDB (v2.2): Continuar leyendo «MongoDB: Recuperar un config server»

Publicado el

Limpieza y rotación del slow-query-logs

cleanupYa hablamos de cómo limpiar de forma segura el error-log de MySQL. Otro fichero de logs que puede dar problemas, si lo tenemos activado, es el slow_query_log, que se encarga de almacenar las queries que se han ejecutado sin índices, o que han tardado más de determinados segundos en ejecutarse. Este fichero, por tanto, nos debería servir para identificar puntos de mejora en nuestras queries, pero si tenemos mucho que mejorar, se llenará rápidamente. En mysqlperformanceblog explican cómo crear un script para uso de logrotate para limpiar de forma automática este log de forma periodica, y evitar así problemas mayores.

Primero, crearemos el script de rotación, cogido directamente de mysqlperformanceblog:

[root@myserver]# vi /etc/logrotate.d/mysql-slow

/var/lib/mysql/mysql-slow.log {
nocompress
create 660 mysql mysql
size 1G
dateext
missingok
notifempty
sharedscripts
postrotate
/usr/bin/mysql -u logrotate -pmipassword -e ‘select @@global.long_query_time into @lqt_save; set global long_query_time=2000; select sleep(2); FLUSH SLOW LOGS; select sleep(2); set global long_query_time=@lqt_save;’
endscript
rotate 5
}

Se ha de tener en cuenta, que en la instrucción de postrotate, necesitaremos añadir el usuario y password de acceso al mysql para poder ejecutar esas consultas. También se deberá indicar la ruta al fichero del slow-log en la primera instrucción (marcado en negrita).

Continuar leyendo «Limpieza y rotación del slow-query-logs»

Publicado el

Instalar y configurar REDIS desde source

91018527El título es bastante identificativo. Este post explica cómo instalar y configurar Redis (la base de datos/caché key-value) en CentOS 6 desde source, si por alguna razón no pudiéramos o no quisiéramos instalar mediante yum.

Descarga e instalación

Podemos descargar la última versión estable de Redis directamente desde la web oficial. Bastará con extraer el tarball y ejecutar «make«:

[root@myserver]# wget http://redis.googlecode.com/files/redis-2.6.13.tar.gz
[root@myserver]# tar xzf redis-2.6.13.tar.gz
[root@myserver]# cd redis-2.6.13
[root@myserver]# make

Si todo ha ido bien, ya tendremos Redis listo. Como seguramente habremos descomprimido el tarball en un directorio temporal, en mi caso he preferido cubrirme las espaldas y mover el directorio extraido (y posteriormente recompilado con make) a /etc/redis/installation_files.

[root@myserver]# cd ..
[root@myserver]# mv redis-2.6.13 installation_files
[root@myserver]# mkdir /etc/redis
[root@myserver]# mv installation_files /etc/redis/

Continuar leyendo «Instalar y configurar REDIS desde source»

Publicado el

Vaciar el error.log de MySQL

Un tema que me ha preocupado siempre, son los logs de MySQL, y más concretamente el error.log. En entornos de replicación, el error.log puede llegar a ser gigante cuando se usan sentencias que el sistema detecta como «advertencias». Por ejemplo:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.

¿Cómo podemos vaciar el error.log de forma segura, sin que tenga impacto en el servicio de MySQL? Pues vamos a verlo.

Continuar leyendo «Vaciar el error.log de MySQL»

Publicado el

Monitorizar upload FTP desde script

Upload FTP¿Cómo podríamos saber si un fichero que está siendo subido por FTP ha acabado o no de subirse? Hay algunas posibles soluciones en esta conversación de SuperUser.com, la última de las cuales, es la que he usado.

Para los testeos, he usado un servidor vsFTPd (configurado tal y como expliqué aquí) sobre un servidor CentOS 5.4. Como no tenía ficheros grandes para hacer el test, he creado uno de forma instantánea, con el siguiente comando:

[root@adripc]# fallocate -l 100M test.img
[root@adripc]# ls -lah test.img
-rw-r–r– 1 root root 100M Jul 18 10:20 test.img

La idea es usar lsof para saber el PID del proceso de vsFTPd que está siendo usado para subir el fichero destino, y entoces monitorizar ese PID.  El problema que me he encontrado, al menos con el entorno de test que he usado, es que ese PID de subida puede cambiar durante la subida. No sé bien bien porqué razón, pero en mi caso cambia. Si cambia el PID entonces ya no podremos monitorizar ese PID, ya que el PID habrá finalizado (o no) pero no así la subida, que estará usando otro PID diferente.

En este caso, la solución es más sencilla aun, ya que bastará con símplemente ir consultando mediante lsof y en caso de devolver vacío, nos indicará que no hay ningún proceso usando el fichero y que por tanto, la subida ha finalizado. Así, nos dará igual que el PID cambie. Lo único importante es que durante la subida del fichero, ese archivo tendrá un PID asociado, mientras que cuando haya acabado el upload, no tendrá ningún PID y por tanto lsof devolverá vacío.

Continuar leyendo «Monitorizar upload FTP desde script»

Publicado el

vsftpd con TLS explícito en CentOS

Seguridad

vsftpd es un servidor FTP que debería ser «Very Secure FTP», pero que por defecto es justo lo contrario. Con un poco de trabajo, podemos dejarlo bastante mejor, que es precisamente, lo que voy a mirar de describir a continuación.

Lo que queremos es forzar a los clientes a usar FTP+TLS Explícito, en lugar de FTP simple, para forzar comunicaciones cifradas. Además, usaremos FTP pasivo, enjaularemos a los usuarios y crearemos un listado de usuarios que puedan conectar, para tener controlados a los usuarios FTP.

Las pruebas se han realizado sobre un servidor CentOS 5.4 con vsFTPd 2.0.5.

En primer lugar, si no lo tenemos ya, podremos instalar vsftpd desde yum.

[root@MyServer]# yum install vsftpd

Certificado SSL

A continuación, generaremos el certificado para el SSL y le daremos los valores adecuados:

[root@MyServer]# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/vsftpd/vsftpd.pem -out /etc/vsftpd/vsftpd.pem
Country Name (2 letter code) [GB]:ES
State or Province Name (full name) [Berkshire]:Spain
Locality Name (eg, city) [Newbury]:Barcelona
Organization Name (eg, company) [My Company Ltd]:Mi Empresa S.A.
Organizational Unit Name (eg, section) []: IT
Common Name (eg, your name or your server’s hostname) []:midominio.com
Email Address []:

Una vez generado, cambiaremos los permisos del fichero:

[root@MyServer]# chmod 600 /etc/vsftpd/vsftpd.pem

Continuar leyendo «vsftpd con TLS explícito en CentOS»