Servidores en Alta Disponibilidad (IV): Mysql Master-Slave

El poner el MySQL en master-master me ha dado algún que otro problema por no hacerlo bien desde el principio, así que vamos paso a paso. Para empezar, pondremos el MySQL en master-slave. Es una configuración que no da problemas y el modo master-master es un master-slave doble. 

Con el MySQL en master-slave conseguiremos que se replique todo lo que pasa en un servidor en el otro, pero no al revés. En nuestro caso, si lo hiciésemos así, antes de recuperar el funcionamiento del servidor principal habría que hacer una copia de seguridad del secundario y restaurarla, pero tratamos de automatizar todo lo posible el sistema así que no nos interesaría que se quedase así.

Para hacer el master-slave, lo primero es editar el archivo de configuración del mysql de los dos nodos (/etc/my.cnf en mi caso) y añadimos:

Nodo 1:
[mysqld]
log-bin=mysql-bin
server-id=1 

Nodo 2:

[mysqld]
server-id=2

Cada servidor tiene que tener un id distinto, y en log-bin será el encargado de revisar el log para la replicación.

Luego tenemos que crear un usuario en el master (Nodo 1) y darle acceso desde la IP del esclavo (Nodo 2):

mysql> create user 'replicator'@'%' identified by 'C0ntraseña';
mysql> grant replication slave on *.* to 'replicator'@IPSLAVE \
identified by 'slave';

Tenemos que obtener ahora la información del log binario para poder usarla, para ello en el Nodo 1:

mysql> FLUSH TABLES WITH READ LOCK; <- Dejar ejecutado en una sesión durante la creación de la copia de seguridad

mysql> SHOW MASTER STATUS;

Que nos devolverá algo similar a esto:

+------------------+-----------+--------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000001 | 324 |              |                  |
+------------------+-----------+--------------+------------------+

Deberemos apuntar "File" y "Position".

Hacemos una copia de seguridad del master (Nodo 1):

$ mysqldump -u da_admin -p --all-databases --master-data > dbdump.db

Y la restauramos en el slave (Nodo 2):

$ mysql -u da_admin -p < dbdump.db

Ya sólo falta en el slave (Nodo 2) declarar el master:

mysql> CHANGE MASTER TO
         MASTER_HOST='IP MASTER',
         MASTER_USER='replicatror',
         MASTER_PASSWORD='C0ntraseña',
         MASTER_LOG_FILE='mysql-bin.000001',
         MASTER_LOG_POS=324;

Y arrancar el esclavo:

mysql> START SLAVE;

Podremos comprobar el estado en todo momento con el comando:

mysql> SHOW SLAVE STATUS\G;

Servidores en Alta Disponibilidad (III): sincronización de archivos

El siguiente punto es relativamente sencillo, que es sincronizar los archivos de la web. En nuestro caso se ha optado por usar un cron con rsync.

La parte mas "difícil" es decidir las carpetas a sincronizar. En nuestro caso ambos servidores tienen DirectAdmin, lo que implica que hay archivos "web" tanto en /var/www/html como en el /home de cada usuario. En /var/www/html están las aplicaciones web (webmails varios, phpmyadmin, etc) que no nos interesa replicar ya que se encarga el propio DA de actualizar y pasando de que den errores.

Los dominios con web se encuentran dentro del /home de cada usuario, así que en un primer momento me decanté por hacer el rsync a /home/*, que hizo que se duplicasen correos a gogó porque se guardan el la carpeta /home/*/Maildir. Como tienen configurado el correo como POP3, les da igual que vayan a un lado o a otro porque los borran, así que fuera la carpeta Maildir y zurzing.

 */10 * * * * rsync -e ssh -a --exclude 'Maildir' /home/* [email protected]:/home

Así que con esto metido en el cron lo tenemos solucionado, es cuestión de ajustar tiempos. Cuidado con replicar configuraciones del servidor (/etc) o las bbdd (/var/lib/mysql) que da problemas como no se tenga ojo. Mejor hacer todas estas cosas de forma manual ya que no se hacen cambios a todas horas.

Servidores en Alta Disponibilidad (II): DNS

Siguiendo con el post anterior, vamos a ver como hacer el tema de las DNS. Vamos a suponer que usamos el dominio biremaz.es y las ips de los servidores son 1.2.3.4/24 y 2.3.4.5/24, dos clases C distintas y en distintos data centers.

Primero configuramos las entradas DNS en los servicios DNS de cada equipo.

En el servidor 1:

• biremaz.es. A 1.2.3.4
• www.biremaz.es. A 1.2.3.4
• ftp.biremaz.es. A 1.2.3.4
• mail.biremaz.es. A 1.2.3.4
• mail2.biremaz.es. A 2.3.4.5
• ns1.biremaz.es A 1.2.3.4
• ns2.biremaz.es A 2.3.4.5
• ns1.biremaz.es NS 1.2.3.4
• ns2.biremaz.es NS 2.3.4.5
• biremaz.es. MX 10 mail.biremaz.es
• biremaz.es. MX 20 mail2.biremaz.es

 En el servidor 2:

•  biremaz.es. A 2.3.4.5
• www.biremaz.es. A 2.3.4.5
• ftp.biremaz.es. A 2.3.4.5
• mail.biremaz.es. A 2.3.4.5
• mail2.biremaz.es. A 1.2.3.4
• ns1.biremaz.es A 1.2.3.4
• ns2.biremaz.es A 2.3.4.5
• ns1.biremaz.es NS 1.2.3.4
• ns2.biremaz.es NS 2.3.4.5
• biremaz.es. MX 10 mail2.biremaz.es
• biremaz.es. MX 20 mail.biremaz.es

Como veis, cada servidor está de tal manera que resuelve el mismo. En el caso de los MX, el correo se intentará dejar siempre que se pueda en el principal, para evitar problemas.

Lo siguiente es configurar las DNS del dominio en el registrador, eso ya depende de con quien se tenga contratado.

Si lo dejamos tal cual, van a empezar a responder indistintamente ambos servidores, cosa que en nuestro caso no queremos, así que paramos el servicio DNS del servidor 2.3.4.5 para que siempre responda el servidor 1.2.3.4. Si queremos que responda el servidor 2.3.4.5, paramos el servicio DNS en el 1.2.3.4 y lo arrancamos en el 2.3.4.5. El tiempo del cambio es el TTL que hayamos definido, por lo que hay que mantenerlo bajo, en mi caso 60 segundos.

Servidores en Alta Disponibilidad (I): Planteamiento

Me ha tocado montar un par de servidores en alta disponibilidad en dos data centers distintos. La idea es la de usar uno como servidor principal y sólo en el caso de que este falle se ponga a funcionar el otro.

La primera idea que tuvimos fue la de usar los DNS del dominio para hacer esta HA. Suponiendo que el dominio fuese biremaz.es, la idea era:

• Declarar ns1.biremaz.es apuntando al servidor principal y ns2.biremaz.es.
• Poner como NS primario al dominio ns1.biremaz.es y ns2.biremaz.es
• En cada servidor DNS, el dominio estaría configuradas con las ips del propio servidor.

Con esto se pretendía que siempre respondiese el DNS en ns1.biremaz.es con las ips de ese servidor, y si cae, que respondiese ns2.biremaz.es con las ips nuevas.

Esta aproximación fue un fracaso, porque aun estando declarado ns1.biremaz.es como primario, respondía también ns2.biremaz.es.

Tras investigar un poco, descubrí que las peticiones DNS las responde indistintamente cualquiera de los servidores NS que tengas declarado en el dominio, que no hay ninguna prioridad que permita forzar el uso de un servidor NS concreto.

Al fallar esto, se ha tenido que ver otra forma de hacerlo porque no se quiere que respondan los dos servidores al mismo tiempo*. Haciendo pruebas, al final lo que se ha hecho es mantener la idea de tener dos servidores DNS con distintas IPs, uno como primario y otro como secundario, pero manteniendo el servicio DNS del secundario parado. Cuando suceda algo, lo que hay que hacer es parar el servicio DNS del primario y arrancar el secundario, que teniendo un TTL de 60s hará que se refresquen las IPs del DNS rápidamente y en caso de fallo responda el servidor secundario.

Habiendo resuelto este punto, que es el más importante, quedaba ver cómo poder replicar los datos de la web y de la bbdd. Para los datos es algo sencillo, un cron con un rsync permite hacerlo, y como los datos web en sí no se modifican a cada momento, no hay mucho problema de desfase de datos.

El otro problema nos vino con la bbdd. Hice la prueba de poner el servidor mysql en master-slave, lo que permitía que cada vez que se hiciese un cambio en el servidor principal se replicase al de prueba, pero en el caso de que cayese el principal y se empezase a usar el secundario, habría un desfase de datos, por lo que se decidió usar el mysql en modo master-master, que ambos servidores se replicasen.

Esto nos trajo otro problema, ya que durante las pruebas que hicimos ambos servidores estaban respondiendo a la web y se han creado entradas distintas con los mimos PKs, así que eso falla más que una escopeta de feria**. Como la web está en funcionamiento, no tenemos la posibilidad de hacer muchas pruebas, por lo que lo que voy a hacer es borrar las bbdd de las webs, forzar en la configuración del mysql que tengan distintos PKs las bbdd, y restaurar un dump con la esperanza de que se regenere todo bien y ya no de problemas el master-master.

Si esto funciona bien, lo único que quedaría por hacer sería encontrar la forma de que se haga automáticamente el cambio de servidores DNS, que por ahora creo que lo haré con el programa Monit que permite un chequeo TCP a puertos de servidores externos. En caso de que no funcione el master-master, la solución es ponerlo en master-slave pero implica más trabajo manual y pierde la gracia.

En otros posts voy a desgranar un poco más la configuración de cada parte, más a modo de apuntes que otra cosa.

* Si se pudiesen usar ambos servidores a la vez no habría tanto problema en esto, y hubiésemos optado por dejarlo así o por usar un DNS RoundRobin, aunque los problemas del mysql hubiesen sido los mismos.
** El servicio de replicación de mysql se para si encuentra fallos de este tipo para evitar inconsistencias, pero se puede cambiar el comportamiento mediante la configuración del mysql.