El mundo en bits: load balance

Mostrando entradas con la etiqueta load balance. Mostrar todas las entradas

Uso avanzado de ifenslave

Hace ya un tiempo hablamos en este blog de cómo crear un bonding en Debian, o en cualquier otro sistema Linux, ya que el proceso es prácticamente el mismo. Lo primero que se citó fue la necesidad de instalar un paquete llamado ifenslave, que era el que daba soporte para la creación del bond.

A mayores, este paquete ofrece más alternativas que dar soporte para la creación del nuevo interfaz, sino que permite en tiempo real modificar un bond ya existente, pudiendo alterar su modo e incluso añadir o sacar interfaces de red.

A continuación veremos algunos de los usos y del potencial de dicho comando.

Creación de un bond en tiempo real
Si necesitamos crear un bond en nuestra máquina, pero no nos interesa crear todos los ficheros de configuración ya que es para poco tiempo, podemos hacerlo tal que así:
```
shell> modprobe bonding
shell> ifconfig bond0 192.168.0.1 netmask 255.255.0.0
shell> ifenslave bond0 eth1 eth2
```
Cambiar la tarjeta de red esclava
Un bond (según la configuración) puede estar enviado todos los paquetes por un interfaz de red y tener el otro como slave, por si algo pasa. Si nos interesa cambiar el orden de los interfaces por algún motivo,
```
shell> ifenslave -c bond0 eth2 eth1
```
Añadir una nueva tarjeta de red
Para añadir una nueva tarjeta de red al sistema simplemente necesitamos indicar el bond al que irá y la interfaz a añadir. La tarjeta comenzará a trabajar según la configuración del bond.
```
shell> ifenslave bond0 eth2
```
Sacar una tarjeta de red
Puede ser que por algún motivo necesitemos sacar una tarjeta de red momentáneamente. Si este es el caso,
```
shell> ifenslave -d bond0 eth2
```

MySQL multimaster, transacciones

Hemos hablado ya de cómo instalar un servidor MySQL en replicación multimaster, y también cómo solucionar el problema que aparecía en los autoincrementales. Hoy voy a comentar un problema que también aparece en este modelo y que es el de las transacciones. Por temas de rendimiento generalmente MySQL no escribe todos los datos a disco cada vez que algo nuevo se manda, sino que lo junta todo en lo que se denomina una transacción y luego lo realiza. Esto garantiza que los datos sean en todo momento consistentes. El problema que tenemos aquí es saber qué sucede si lo mismo sucede a través de la red. Un master puede enviar los datos para que sean escritos en 'su slave', pero éstos deben garantizarse que son escritos antes de que el master los escriba. De no ser así, podríamos llegar a un punto de inconsistencia: master y slave tendrían datos diferentes. Para evitarlo debemos habilitar las transacciones síncronas. Esto obliga a que los datos sean escritos en el slave antes que en el master y en caso de que el slave no responda, se escriben únicamente en el master pasado un tiempo. Luego el proceso de sincronización de datos deja master y slave en el mismo punto cuando el slave esté nuevamente vivo.

Para configurar esto debemos ejecutar los siguientes comandos en ambos nodos del clúster.

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

Y en el fichero de configuración (/etc/my.cnf) escribir lo siguiente,

[mysqld]
...
rpl_semi_sync_slave_enabled  = 1
rpl_semi_sync_master_enabled = 1
...

Tras ello, reiniciar el servidor MySQL.

shell> service mysql restart

Una vez terminado de aplicar en ambos nodos, podemos ver las nuevas variables aplicadas y el valor de las mismas, el cual podemos modificar a nuestro antojo, para mejorar el rendimiento si así lo consideramos oportuno.

mysql> SHOW VARIABLES LIKE 'rpl_semi_sync%';
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled       | ON    |
| rpl_semi_sync_master_timeout       | 10000 |
| rpl_semi_sync_master_trace_level   | 32    |
| rpl_semi_sync_master_wait_no_slave | ON    |
| rpl_semi_sync_slave_enabled        | ON    |
| rpl_semi_sync_slave_trace_level    | 32    |
+------------------------------------+-------+
6 rows in set (0.01 sec)

mysql> SHOW STATUS LIKE 'Rpl_semi_sync%';
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 0     |
| Rpl_semi_sync_master_net_avg_wait_time     | 0     |
| Rpl_semi_sync_master_net_wait_time         | 0     |
| Rpl_semi_sync_master_net_waits             | 0     |
| Rpl_semi_sync_master_no_times              | 0     |
| Rpl_semi_sync_master_no_tx                 | 0     |
| Rpl_semi_sync_master_status                | ON    |
| Rpl_semi_sync_master_timefunc_failures     | 0     |
| Rpl_semi_sync_master_tx_avg_wait_time      | 0     |
| Rpl_semi_sync_master_tx_wait_time          | 0     |
| Rpl_semi_sync_master_tx_waits              | 0     |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0     |
| Rpl_semi_sync_master_wait_sessions         | 0     |
| Rpl_semi_sync_master_yes_tx                | 0     |
| Rpl_semi_sync_slave_status                 | ON    |
+--------------------------------------------+-------+
15 rows in set (0.00 sec)

Si quieres ampliar información, aquí.

MySQL multimaster: trucos

Si ya habéis leído el post sobre cómo montar un sistema MySQL con dos nodos activos, podréis ver que esa configuración presenta varias deficiencias. Una de las más notorias y que además es casi fijo que os suceda es un fallo a la hora de sincronizar datos si éstos tienen un campo que sea un ID autoincremental.
En una arquitectura master - slave, como sólo se escribe en uno de los nodos, no hay problema, pero en master - master, cada vez que se escriba el auto-incremental se va a aumentar en uno, pudiendo colisionar cuando lleguen los datos del otro nodo. Y si la tabla está diseñada para que no puedan existir datos con ID's duplicados, ya tenemos el lío montado!

Por suerte, MySQL tiene tiene una solución para este problema, que no es otra que indicarle a un nodo que emplee los autoincrementales pares y al otro nodo los impares. De esta forma, cuando se sincronicen los datos, siempre serán correctos y nunca habrá ID's replicados. Para lograr esto, simplemente en el fichero de configuración (/etc/my.cnf) de cada uno de los nodos tendremos que tener lo siguiente,

M1: Números pares

auto_increment_increment = 2
auto_increment_offset    = 1

M2: Números impares

auto_increment_increment = 2
auto_increment_offset    = 2

Lógicamente si aun aplicación es la encargada de realizar los insert's habrá que controlar en función del servidor destino el ID que deba escribir, evitando siempre escribir duplicados para que sea así posible la sincronización de los datos.

MySQL Active -- Active (multimaster)

Hace unos días hablamos aquí de cómo poder montar una arquitectura master - slave en MySQL y los beneficios de la misma. Hoy vamos a ver cómo crear un sistema en MySQL master - master (o multimaster) y los beneficios del mismo.

En la gran mayoría de los casos, un sistema master - slave será lo ideal y ofrecerá una buena estabilidad entre rendimiento y fiabilidad. En este caso, lo que se favorece es un gran número de lecturas, frente a un número considerablemente bajo de escrituras. Por el contrario, la nueva acquitectura master - master, lo que favorecerá será a un gran número de escrituras, frente a un número normal o bajo de lecturas. Se escribe más de lo que se lee, de ahí que nos interese dividir los servidores de escritura.

Montar un sistema master - master realmente es configurar en ambos sentidos un sistema master - slave. El Master-1 será el slave del Master-2 y viceversa. Todo lo que se escriba en Master-2 será replicado automática a Master-1 y todo lo que se escriba en Master-1 será replicado automática a Master-2.

Los datos de los que partimos serán:

M1 -- 192.168.0.33 -- id: 1
M2 -- 192.168.0.35 -- id: 2

En ambos nodos se cuenta con una versión 5.5.x de MySQL previamente instalada, por lo que únicamente explicaremos el proceso de replicación. Puesto que prácticamente lo que se haga en el primer nodo lo tendremos que ejecutar en el segundo, simplemente haremos un cambio del prompt de MySQL, para saber en qué equipo estamos en cada momento.

Configuramos los servidores
Aquí únicamente tendremos que configurar el fichero de configuración de MySQL (/etc/my.cfg) de ambos nodos. La configuración es similar a la de la arquitectura master-slave, pero como salvedad en este caso únicamente haremos réplica máster-máster de una base de datos.
```
log-bin          = mysql-bin
binlog-do-db     = BD_master
binlog-ignore-db = mysql
binlog-ignore-db = test
server-id        = 1
```
Y aplicamos la misma configuración para M2, salvo por el server-id.
```
log-bin          = mysql-bin
binlog-do-db     = BD_master
binlog-ignore-db = mysql
binlog-ignore-db = test
server-id        = 2
```

Reiniciamos el servicio MySQL

M1@shell> service mysqld restart

En ambos nodos...

M2@shell> service mysqld restart

Creamos un backup de los datos
El equipo M1 es el que contiene los datos de origen, así que serán los que empleemos para crear el clúster. Por lo tanto, haremos un backup de los mismos,
```
M1@shell> mysqldump -u root -p --master-data=2 > all.sql
```

Posición del log para replicación

Y al igual que sucede al crear un slave, necesitamos saber en qué punto del binary log estamos situados, para indicar que será a partir de ese punto desde donde deba comenzar a replicar. Para eso, simplemente desde el servidor M1, ejecutamos:

mysql@M1> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |       98 |              |                  | 
+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

Importamos los datos en M2
Importamos los datos que sacamos del servidor M1 al servidor M2 para partir de los mismos datos de origen. Previamente a este importado, tendremos que pasar el fichero all.sql de M1 a M2.
```
mysql@M2> SOURCE /home/javier/all.sql
```

Creamos el usuario de replicación

Puesto que ambos nodos se replican el uno del otro, tendremos que crear un usuario en cada uno de los servidores.

mysql@M1> GRANT REPLICATION SLAVE, REPLICATION CLIENT 
       -> ON *.* 
       -> TO remote_user@'192.168.0.35' 
       -> IDENTIFIED BY 'remote_user_passwd';

Lo mismo para el segundo master.

mysql@M2> GRANT REPLICATION SLAVE, REPLICATION CLIENT 
       -> ON *.* 
       -> TO remote_user@'192.168.0.33' 
       -> IDENTIFIED BY 'remote_user_passwd';

Configuramos la replicación de datos

mysql@M1> CHANGE MASTER TO MASTER_HOST='192.168.0.35',
       -> MASTER_USER = 'remote_user',
       -> MASTER_PASSWORD = 'remote_user_passwd',
       -> MASTER_LOG_FILE = 'mysql-bin.000001 ',
       -> MASTER_LOG_POS = 98;

mysql@M2> CHANGE MASTER TO MASTER_HOST='192.168.0.33',
       -> MASTER_USER = 'remote_user',
       -> MASTER_PASSWORD = 'remote_user_passwd',
       -> MASTER_LOG_FILE = 'mysql-bin.000001 ',
       -> MASTER_LOG_POS = 98;

Arrancamos los procesos slave's en ambos nodos

mysql@M1> START SLAVE;

mysql@M2> START SLAVE;

Y con esto ya tenemos un sistema de MySQL activo - activo, o lo que es lo mismo un slave de cada uno de los master's.

Cómo crear un bonding en Debian

Si estás trabajando con equipos de sobremesa únicamente, quizás este post no te sea de gran utilidad/ayuda, pero si trabajas con servidores, desde luego te interesa! En muchos casos accedes a un equipo y ves que aunque teniendo varias tarjetas de red, éste sólo está a emplear una (eth0, por ejemplo). Crear un bond entre varias tarjetas de red debería ser como emplear un RAID para el disco, algo casi 100% necesario. Si los datos son importantes, tenerlos disponibles también debe ser importarte.

Hay que recordar que poner las tarjetas de red en bond puede hacerse para conseguir mayor velocidad (emplear 2 tarjetas como una sola) o también para tener redundancia (si una tarjeta 'cae', la otra asumirá el trabajo). Por lo tanto, vamos a ver cómo conseguir hacer lo aquí descrito de forma muy sencilla en sistemas debian/ubuntu. Antes de comenzar, tenemos que instalar el software necesario,

shell> apt-get install ifenslave-2.6

A continuación, habrá que crear la definición de la tarjeta de red compartida, bond0, que por ejemplo una eth0 y eth1. Para ello, agregamos la siguiente configuración en /etc/network/interfaces:

auto bond0
iface bond0 inet static
   address 192.168.1.2
   netmask 255.255.255.0
   network 192.168.1.0
   broadcast 192.168.1.255
   gateway 192.168.1.1
   slaves eth0 eth1
   bond-mode balance-rr # mode 0
   bond-miimon 100
   bond-downdelay 200
   bond-updelay 200

Y a continuación levantamos el nuevo interfaz, con lo que debería automáticamente cargar el módulo del kernel con las opciones descritas.

shell> ifup bond0

En caso de que no se levante correctamente el interfaz por culpa del módulo del kernel, debemos crear un nuevo fichero bajo /etc/modprobe.d/ a que podremos llamar bonding.conf con el siguiente contenido,

alias bond0 bonding
   options bonding mode=0 miimon 100 downdelay 200 updelay 200

Las opciones que pasamos como parámetros son:

mode
Representa el modo de funcionamiento del interfaz, según la siguiente tabla.

Modo	Tolerancia	Balanceo	Descripción
0	Sí	Sí	[balance-rr] - Balanceo Round-Robin
1	Sí	No	[active-backup] - Backup Activo
2	Sí	Sí	[balance-xor] - Según MAC
3	Sí	No	[broadcast]
4	Sí	Sí	[802.3ad] - Crea grupos esclavos con la misma configuración
5	Sí	Sí	[balance-tlb] - Transmit Load Balancing
6	Sí	Sí	[balance-alb] - Adaptative Load Balancing (con una única MAC)

miimon
Es la frecuencia de monitorización de los interfaces, en ms.
downdelay
Tiempo en ms para dar de baja un link caído.
updelay
Tiempo en ms para dar de alta un link caído.

Round Robin DNS

Una de las formas más simples de escalar una aplicación web (o cualquier otro servicio) es la conocida como Round Robin DNS. RR-DNS es una técnica de balanceo de carga realizada desde los propios servidores DNS y no desde una máquina dedicada.

Round Robin es un algoritmo que permite seleccionar elementos de forma equitativa y por orden. Generalmente lo que se hace es crear una lista con todos los elementos y éstos luego son devueltos en orden. Cuando se ha recorrido toda la lista, se comienza de nuevo. Si se aplica este algoritmo a DNS, se puede comprender la forma de funcionamiento. Un nombre DNS tiene varias IP's detrás que pueden contestar a él, albergadas en diferentes servidores. Cuando un cliente pide la página, se envía a un servidor, al siguiente cliente se le mandará al siguiente servidor y así siempre. La carga se distribuye a través de los N equipos que formen el cluster, pero todo desde un DNS.

Suscribirse a: Entradas ( Atom )

El mundo en bits

Uso avanzado de ifenslave

MySQL multimaster, transacciones

MySQL multimaster: trucos

MySQL Active -- Active (multimaster)

Cómo crear un bonding en Debian

Round Robin DNS

Formulario de contacto

Últimos comentarios

Entradas más vistas