Llevo unos días sin escribir, el motivo principal ha sido las constantes caídas de las maquinas virtuales, mi equipo no es muy potente y tengo el procesador al 100 el 90% del tiempo, las maquinas solaris arrancan una vez si otra no, y el proxy debian murió sin más el sistema de archivos(con su consiguiente kernel panic), lo gracioso es que fui a rescatar las configuraciones en /etc y era exactamente el directorio muerto (enlace muerto). Así que volver empezar, así que en resumen estas son las instalaciones repetidas:
- Los dos opensolaris con mysql(llamados mysql1 y mysql2)
- El Proxy debian
- Re-configurar todo otra vez
Lo gracioso es que siempre se rompias cuando iba a configurar el backup de todas pues el servidor nas ya estaba.
La otra gran parte del tiempo he estado investigando de ipmp (IP MultiPath), la verdad que como tecnología es una cosa grandiosa que debería existir en otros S.O. pero en este caso no podía utilizarlo, para entenderlo voy a explicar en que consiste. IPMP nos permite balancear y tener a prueba de fallos dispositivos de red físicos( y a partir de ahora también virtuales), para ello creamos un grupo del cual tiene una IP que responderá por el grupo y enviando al los dispositivos activos, existen básicamente dos configuraciones uno es “activo-activo” y otro “activo-en espera”, el segundo es el caso que se activa un dispositivo cuando se cae el principal, el primero balancea entre todos los dispositivos.
Bueno ya explicado se podría configurar una maquina virtual (LDom por ejemplo) que escuchara un dispositivo y otra maquina otro, así podríamos disponer de un balanceador a nivel de red si tenemos el mismo servicio en ambas maquinas virtuales. Este esquema no me es posible al tener ya todo virtualizando, el virtualizado del virtualizado es muyyyy lento y si la cosa la tengo ajustada eso podría terminar de apretar más el cinturón.
Así que busque un esquema más clasico, un simple mysql-proxy, que me da más juego pues permite ejecución de scripts lua, también he mirado lo de iptables lo que no me acordaba es que el failover es manual por tanto no sirve(habría que hacer un daemon especial y el tiempo anda justo sorry). También estuve peleandome con el squid pero he optado por otra solución mejor, apache, es más robusto y configurable, permitiéndome jugar con las direcciones ademas de darme una interfaz web al balanceador. Entonces los cambios son:
- Squid-> Apache
- IPMP->mysql-proxy
Apache tiene una configuración sencilla pero robusta, usa los módulos proxy, proxy_balancer, rewrite y proxy_http. Debido a un cambio en la ultima versión proxy se desgloso en varios módulos (http, ftp, etc…) y tiré horas para saber que tenia que habilitar este, pues los manuales era para versiones anteriores (etch). Así que más tiempo gastado por cambios de versión, pero al final quedo muy bien:
<VirtualHost *:80>
ServerName proxy.abstracctest.com
ServerAlias abtracctest.com
RewriteEngine On
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from 192.168
</Location>
<Proxy balancer://mycluster>
BalancerMember http://192.168.122.50:8080 route=w1
BalancerMember http://192.168.122.51:8080 route=w2
</Proxy>
<Location /clusterjsp>
Order allow,deny
Allow from all
</Location>
ProxyPass /clusterjsp balancer://mycluster/clusterjsp/ stickysession=JSESSIONID
<Location />
Order allow,deny
Allow from all
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
</VirtualHost>
Laresolución es sencilla, activamos el proxy (abrimos la puerta con allow all), despues activamos el balanceador y ponemos los miembros de balanceo(aquí hay muchas opciones por si el balancio no es igualitario por ello no hay más) importante el “route=wx” pues es lo que nos sirve para distinguir los servidores a la hora de enrutar (para ello en cada instancia de glassfish en el panel de administración hay que añadir al servidor la opcion “-DjvmRoute=wx” a la JVM de cada instancia). Tambien destacar el stickysession=JSESSIONID que nos permite tener sticky sessión, en mi ejemplo para probarlo use el ear que viene de demostración cluster con glassfish, en caso de ser PHP y apache seria BLANCEID. Cuando se deploye la aplicación con quercus(php en java) se verá si funciona con una opción u otra.
Mañana a primera hora explico mysql-proxy que ha sido un bonito descubrimiento, ademas de la construcción de un master to master con mysql.
.
Últimos comentarios