Proxy en HA (activo-pasivo)

Hola de nuevo,

En este post expondre como montar un squid en modo HA activo-pasivo, la idea es bastante simple aunque por el nombre parezca complicado.

Basicamente haremos:

• 2 Servidores Proxy
• 1 servidor web para anunciar que el server este caido
• 1 servidor de logs donde recogeremos las trazas del proxy (que en este caso es el mismo del web)
• Un servicio de IP virtual para los usuarios

Como topologia tendriamos algo asi:

Estara todo desplegado con servidores Debian 10.

Paquetes instalados para este ejemplo en caso de no hacerlo con ansible son:

• Squid (proxys)
• Keepalived (ip virtual)
• rsyslog (configracion de logs para envios)
• rsync (syncronizacion de ficheros cuando se pasa del activo al pasivo)
• apache2 / nginx ( para el aviso / ver los logs con cualquier herramienta )

Nota aclaratoria: Esta demostracion no es para poner los proxys balanceados donde aceptarian los requests a la misma vez ok?… eso lleva otra configuracion,… primero veremos esta q es la mas facil para poner 1 solo y en el caso de que no este activo el servicio pase hacia el otro.. lo importante aqui es ver 2 cosas; el despliege de ansible para crear esta configuracion de manera rapida y que para los usuarios este servicio es transparente mientras el sysadmin en el caso de que no funciona 1 squid no tenga la gente arriba de uno hasta que se restablezca y pueda trabajar en paz. En los proximos post pondre la otra configuracion que si seria activo-activo.

Entonces… aclarado esto primero les muestro mi infrastructura de laboratorio… visto que aun no logro poner proxmox usare hyperv para tener las vm listas.

Como ven las 4 maquinas virtuales encendidas 1 donde gestiono los playbooks para el despliegue ansible-manager…las otras ansideb 1 y 2 seran los squids y ansideb3 sera el que mostrara la pagina web y los logs, la ansideb4 no esta encendida pero esta lista para ser usada para los proximos tutoriales.

Demostracion al fin como ven tambien con simplemente 512mb me es suficiente, para su uso en produccion por supuesto le darian a la vm lo que necesiten para que el servicio no sea lento.

Entonces de acuerdo con esto, lo que tendriamos es en nuestro inventario, una cosa asi para luego probar si tenemos comunicacion con nuestros servers entre ansible-manager y ellos.

En el sitio pondre los ficheros de ansible para que puedan usarlo con la debida preparacion del entorno.

Podemos decir aqui algunas notas como por ejemplo:

1- Yo uso directamente en este caso ansible_host como variable para fijar el ip y asi poder llamar las vms por su nombre debido a que no tengo dns en este caso.

2- Se pudiera dejar solo el nombre y pasar los datos de las ip hacia /etc/hosts en el sistema linux del propio ansible-manager para hacerlo con el DNS local.

3- Otra opcion seria usar un DNS ya existente en la red y poner los records para q usando el dns en ansible-manager en /etc/resolv.conf apunte a este dns y cuando lo llamen por sus nombres el encuentre sus ips.

Osea, que lo que esta escrito no es obligado que sea asi, sino que es una opcion para cuando no quieras o no tengas un DNS pues puedes tambien forzarlo diciendole el ip que debe apuntar para conectarse con la variable de ansible_host=ip.de.la.vm

Ya teniendo una comunicacion y respuesta satisfactoria lo que queda es empezar a crear los tasks que irian en el playbook para desplegar los servicios de squid, rsyslog, rsync y el server web.

El flujo de ansible seria el siguiente

• Instalar los paquetes y sus dependencias que ya hace «apt install» por su parte.
• Copiar las configuraciones de los templates para setear para cada server proxy los ficheros de squid, keepalived, un script de apoyo y rsyncd para los logs
• Habilitara los servicios en cada servidor de los paquetes que se instalaron.
• Levantara un ip virtual para los usuarios que es donde haran los requests en uno de los servidores.
• Ambos proxys en su configuracion de squid tendras puesto que los logs los enviara al servicio rsyslog, que a su vez enviara los logs al server donde estara la informacion cuando el servicio de navegacion no este disponible, que sucedera solamente cuando los 2 squid esten apagados. Mientras exista 1 vivo el servicio se mantendra de otra manera mostrara en los navegadores el index.html que esta preparado en el server ansideb3.
• El hecho de centralizar los logs es porque con ansible pueden escalar horizontalmente en este caso agregando otro squid con la misma configuracion y para no perderse entre tantos logs los centralizo enviadolos a un mismo lugar.

Ejemplos para probar:

• Como prueba de funcionamiento hace un restart al keepalived que esta siendo de master (el que tiene el ip virtual flotante) porque se mueve entre los 2 servers para ver que pasa hacia el otro. Basta hacer en el server activo:
  «`ip a«`
  «`systemctl restart keepalived«` y luego de nuevo
  «`ip a«` no debe aparecer el ip virtual, este server pasa a BACKUP,
  
• Ver que el ping continua cuando hace el cambio de IP entre ellos (lo que garantizaria que el servicio este activo)
• Comprobar que squid correo en ambos servers aunque uno de ellos sea BACKUP
• Al pasar el IP de un server a otro hay un script por medio que esta declarado en la configuracion de keepalived donde traera la configuracion hacia el pasivo desde el server donde estaba activo, para que en caso de cambios sincronize la nueva configuracion, porque recuerden que el que no tiene el IP Virtual en este caso esta en modo pasivo (que no da servicio).
• Para probar esto en el server activo editen alguna linea nueva en la configuracion del squid.conf, y luego reinicien el servicio keepalived
• Recuerden que la configuracion del rsync usara todo lo que este en el directorio /etc/squid/ asi podra garantizar cualquier file de configuracion del squid que usen extra y lo transferira hacia el otro cuando sea lanzado el comando de restart
• Para configurar el servicio del proxy basta entrar por ssh al ip virtual. Esto es importante porque es la manera mas facil y segura que tendria en el caso de tener varios y no ir 1 por 1 a identificar quien es el master. El que este con el IP flotante es donde le dara el ingreso al server y configuraran el squid.common.conf, luego cuando necesiten reiniciar el servicio de keepalived donde esta en ese momento el master por: actualizacion del sistema o lo que sea que hagan con el, el servicio keepalive le mandara un aviso al script que intervendra para recoger la nueva configuracion a travez de rsync y reiniciar el squid en el pasivo convirtiendolo en master y la configuracion sincronizada, mientras que los usuarios no se enteran de que esta pasando detras del IP virtual que tienen configurado en su navegador , o lo hayan puesto via WPAD pasandoselo automaticamente.
• El server donde esta la informacion de que el servicio esta caido tiene 2 cosas que son importante. Keepalived siendo el servicio que interviene entre el usuario y el proxy es quien identifica cuando estos proxys estan caidos y cambia la direccion de destino para los usuarios hacia el server de informacion, que pasa que al estar en el medio el sustituye la IP de origen del cliente por la de el, y cuando llega el paquete a su destino debe responder la llamada, en este caso a el mismo por lo que en ese server se configura la IP flotante en la interfaz de loopback.

Keepalived haciendo check cuando los squid estan corriendo

Cuando alguno se reinicia o esten reinciando el server por alguna actualizacion del tipo kernel o algo asi simplemente quita del check el que este en ese estado.

En el caso que los 2 no esten activos entonces el automaticamente cambia la informacion para el server que anunciara a los usuarios el mensaje personalizado

Aqui claro ya uds tendran la imaginacion de poner algo mas pacotilla, esto es para que vean la respuesta… ya luego le meten el logo de la empresa o css y esas cosas.

y en ese caso veran keepalived redirigiendo el trafico al 3er server ansideb3 para ver el mensaje

• La segunda cosa importante es que tiene una redireccion de puertos en iptables para cuando llamen al 3128 que es el request de los navegadores este se lo redirija al apache/nginx que tienen en el 80 para poder mostrarle la informacion al cliente. Teniendo respuesta el loopback retornara la llamada hacia keepalived y este a su vez retornara el request hacia los navegadores mostrando el mensaje del servicio caido.

Aqui mismo vemos las trazas de ambos squid que llega en /var/log/syslog y de ahi bueno ya usarian la herramienta que quieran para verlo mas en detalle que no entra en este articulo.

Configuracion: ansible-lab-squid-ha.tar

Lo ideal seria haber hecho cada servicio con su propio rol… pero los puse juntos para el que empieza a ver ansible desde cero vea como son las cosas, ya que luego iremos separandolo para hacerlo mas modular y aprovechar mejor el codigo en otras soluciones.

Veamos esto en accion con un video: ansible-squid-ha