CLUSTER

1. Funcionamiento con MySQL
En su implementación más sencilla, un clúster
MySQL integra un servidor MySQL estándar y
un motor de almacenamiento en memoria
llamado NDB clúster, funcionando en un
conjunto de una o más computadoras. Cada una
de estas computadoras ejecutando uno o más
procesos, que pueden consistir en procesos de
MySQL server, nodos de almacenamiento de
datos, servidor administrador del clúster, o
programas especializados para acceder a los
datos.

2. Las tablas de la base de datos se almacenan utilizando el
motor NDB en los nodos de almacenamiento. La manera
de acceder a los datos almacenados en el clúster es a
través de cualquiera de los nodos MySQL. Los nodos de
datos funcionan utilizando un esquema de espejado,
permitiendo soportar sin impacto la caída de nodos
individuales de datos dentro de cluster. La única
consecuencia que tendría un suceso como la caída de un
nodo de datos, es que un pequeño conjunto de
transacciones relacionados al nodo caído serán
abortadas. Estas transacciones deben cumplir con el
esquema transaccional, tal y como si estuvieran
trabajando directamente con un servidor no clusterizado
de MySQL

3. BALANCEO DE CARGA
Las soluciones de balance de carga pueden ser tanto
hardware como software. En este caso, nosotros vamos a
optar por una solución software llamada HAProxy que
instalaremos en otra máquina virtual independiente y
que funcionará de proxy con el resto de nodos SQL de la
arquitectura, a fin de repartir las peticiones.
INSTALACION
Lo primero que tenemos que hacer es instalar una nueva
máquina virtual. Esta máquina solo va a actuar de proxy
balanceador por lo que lo único que tenemos que
instalar es el paquete HAProxy.
view plainprint?
1. sudo apt-get install haproxy

4. Una vez instalado vamos a configurarlo para que balance la carga de
MySQL. Para ello abrimos con un editor el fichero /etc/haproxy/haproxy.cfg
que se ha creado con contenido por defecto en la instalación del paquete.
Esta es una posible configuración para nuestro caso:
view plainprint?
global
maxconn 4096
user haproxy
group haproxy
daemon
defaults
mode http
option tcplog
option dontlognull
retries 3
option redispatch
contimeout 5000
clitimeout 50000

5. srvtimeout 50000
listen mysql-cluster 0.0.0.0:3307
mode tcp
balance roundrobin
server nodo1 192.168.1.15:3306 check
server nodo2 192.168.1.16:3306 check
server nodo3 192.168.1.14:3306 check

6. La parte importante de la configuración se encuentra en la
sección [listen] donde estamos indicando que el proxy
escuche por el puerto 3307, y que las peticiones que le
lleguen por ese puerto las reparta en base a un algoritmo
round robin entre los servidores que se especifican. En caso
de tener unos servidores más potentes que otros, podríamos
definir un peso para cada uno de forma que los más potentes
tengan más posibilidades de recibir más peticiones. Para
hacer esto añadimos a la definición de los servers el peso que
le damos de esta forma:
view plainprint?
listen mysql-cluster 0.0.0.0:3307
mode tcp
balance roundrobin
server nodo1 192.168.1.15:3306 check weight 10
server nodo2 192.168.1.16:3306 check weight 50
server nodo3 192.168.1.14:3306 check weight 40

7. Reiniciamos el proxy indicándole donde está el fichero de configuración:
view plainprint?
sudo haproxy -f /etc/haproxy/haproxy.cfg
Y ya tenemos el proxy listo para empezar a recibir peticiones.
4. Probamos el resultado
Lo primero que tenemos que hacer para probar el resultado es crear y dar
permisos de conexión remota al mismo usuario en los distintos nodos SQL
que están referenciados en la configuración del proxy.
Estos pasos los repetimos por cada uno de los nodos SQL. Primero nos
logamos como root:
view plainprint?
mysql -u root -ppassword
Creamos el usuario y le damos los permisos para conectar remotamente:
view plainprint?
GRANT ALL PRIVILEGES ON *.* TO 'prueba'@'%' IDENTIFIED BY 'prueba' WI
TH GRANT OPTION;
FLUSH PRIVILEGES;
Abrimos el archivo de configuración /etc/mysql/my.cnf y ponemos a 0.0.0.0
el valor de la variable bind-address y el valor de la variable maxconnections a 1000

8. Reiniciamos todos los nodos y comprobamos que el
cluster sigue funcionando.
Para probar el balanceo de la carga basta con situarnos en
un nodo SQL y tratar de ejecutar una conexión remota a
la dirección y puerto del proxy con la siguiente sentencia:
view plainprint?
mysql -u prueba -pprueba -h ip_del_proxy --port=3307
Tenemos que ver que el servidor conecta y permite la
ejecución de consultas. Recordad que en la máquina del
proxy no está instalado MySQL, así que nuestro proxy
está funcionando. Otra forma de asegurarnos es
comprobando en cada nodo SQL con el comando "SHOW
PROCESSLIST" si el usuario "prueba" está conectado a él.

9. FUNCIONAMIENTO CON VLS
Linux Virtual Server (LVS) es una solución para gestionar balance de carga
en sistemas Linux. Es un proyecto de código abierto iniciado por Wensong
Zhang en mayo de 1998.
El objetivo es desarrollar un servidor Linux de alto rendimiento que
proporcione buena escalabilidad, confiabilidad y robustez usando
tecnología clustering.
Actualmente, la labor principal del proyecto LVS es desarrollar un sistema IP
avanzado de balanceo de carga por software (IPVS), balanceo de carga por
software a nivel de aplicación y componentes para la gestión de clústers.
IPVS: sistema IP avanzado de balanceo de carga por software implementado
en el propio núcleo Linux y ya incluido en las versiones 2.4 y 2.6.
KTCPVS: implementa balanceo de carga a nivel de aplicación en el propio
núcleo Linux. Actualmente está en desarrollo.
Los usuarios pueden usar las soluciones LVS para construir un sistema
altamente escalable, donde se garantiza una alta disponibilidad de los
servicios de red, como son servicios web, correo electrónico o VoIP.

10. FUNCIONAMIENTO CON RED HAD PIRHANA
Piranha es un paquete de software, que esta incluida en
la distribución Linux RedHat. Esta compuesto por un
servidor LVS (Linux Virtual Server) y un gestor del
mismo, que permite administrar los servicios de la Web
con un navegador a través de una interfaz gráfica.

11. LVS permite crear un clúster de balanceo de carga, en el
cual hay un nodo que se encarga de gestionar y repartir
las conexiones (nodo master LVS) entre todos los nodos
esclavos del clúster. El servicio de datos debe residir en
todos los nodos esclavos. LVS puede soportar sin
problemas hasta 200 nodos esclavos.

12. Pulse._ Es el controlador del proceso este inicia todos los demonio y
permite editar los parámetros de configuración. Lvs._ Demonio que
corre en LVS routers lee la configuración y llama a ipvsadm. Ipvsadm
._Construye y mantienen las tablas IPVS routing. Nanny._ Monitorea
el demonio que corre en LVS router.
Todos estos programas utilizan el mismo fichero de configuración,
que esta ubicado en /etc/lvs.cf.
INSTALACIÓN DEL PAQUETE PIRAHNA Instalación del paquete de
dependencia ipvsadm.rpm [root@localhost root]# rpm -ivh
ipvsadm-1.21-4.i386.rpm Preparing... ### [100%] 1:ipvsadm
#################### [100%] Instalación del paquete
piranha.rpm [root@localhost root]# rpm -ivh piranha-0.7.61.i386.rpm Preparing...
###########################################
[100%] 1:piranha
###########################################
[100%]

13. Para buscar donde esta el servicio de piranha: rpm -ql piranha
[root@ localhost root]# rpm -ql piranha /etc/rc.d/init.d/piranhagui Levantar el servicio de piranha [root@ localhost root ]#
service piranha-gui start Starting piranha-gui: [ OK ]
Para buscar puertos. El piranha por defecto se levanta en el
puerto 3636. [root@ localhost root ]# netstat -nat Active Internet
connections (servers and established) Proto Recv-Q Send-Q Local
Address Foreign Address State tcp 0 0 0.0.0.0:3636 0.0.0.0:*
LISTEN
Levantar el servicio FTP [root@ localhost root]# service vsftpd
start Iniciando vsftpd para vsftpd: [ OK ] Guardar archivos en el
servidor FTP [root@localhost root]# cd /var/ftp/pub
[root@localhost pub]# ls 01 Suelta mi mano.mp3 drivs.zip
piranha-0.7.6-1.i386.rpm avseq01.dat GAVirusParteII.mpg
prueba Configuración Piranha mpegav Documentación nfs-utils1.0.6-31EL.i386.rpm