Optimizar el servidor Proxy
Hasta ahora todo muy bien, nuestro servidor Proxy responde perfecto a una red menor a 50 usuarios. Sin embargo, la red de datos se nos puede crecer, los servicios aumentar y el servidor podría flaquear. De manera que para soportar el crecimiento de equipos y servicios se debe optimizar el servidor Proxy. Básicamente se trata de aumentar el valor de un parámetro llamado File Descriptor.
Un File Descriptor no es más que un número que representa un archivo o un socket. Cada vez que un proceso abre un archivo o un socket, se asigna un nuevo File Descriptor. En general, un File Descriptor puede ser un una conexión TCP, un archivo abierto o sockets de comunicaciones entre procesos. Por ejemplo, una conexión con un cliente requiere tres Files Descriptors: uno para la conexión, otro para la escritura de logs y otro para la lectura de configuración.
Puede ampliar más sobre File Descriptor, aquí
Optimización técnica del servidor Proxy
Para aumentar el número de File Descriptors en el sistema operativo, debemos realizar los siguientes pasos:
A. Verificar como usuario normal la configuración del número de Files Descriptors
_$ ulimit -a | grep ‘open files’
Generalmente da como salida 1024
B. Agregar las siguientes líneas en /etc/security/limits.conf
* soft nofile 8192
* hard nofile 8192
C. Luego, adicionamos la siguiente linea en el archivo /etc/pam.d/common-session
session required pam_limits.so
D. Aplicar el cambio:
_$ sysctl -p
Una vez aplicados los pasos anteriores debemos cerrar sesión, volver a entrar y verificar de otra vez el nuevo límite:
_$ ulimit -a | grep ‘open files’
E. El comando anterior debe mostrar el número 8192. Luego, se debemos adicionar la siguiente directiva en el archivo de configuración de Squid:
max_filedesc 8192
Normalmente el número de File Descriptors por default en el sistema operativo es de 1024, y con ese número el Squid trabaja bien con 40 clientes (relación de 25). De manera que optimizar el servidor Proxy para que soporte más de 300 clientes, es aumentar el número de File Descriptors a un valor mayor de 7500. De ahí que se haya configurado un tope de 8192.
Opciones adicionales para optimizar el servidor Proxy
Continuando con los ajustes para optimizar el servidor Proxy, podemos adicionar las siguientes líneas al /etc/sysctl.conf del sistema operativo:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 4096
Aplicamos:
_# sysctl -p
Agregamos las siguienest líneas al squid.conf:
maximum_object_size 512 KB
maximum_object_size_in_memory 256 KB
Si el servidor cuenta con una cantidad generosa de memoria RAM, digamos, 20 GB, podemos configurar
maximum_object_size_in_memory en 64 MB
Limpieza de la caché y rotación de logs para Squid Proxy
Una actividad periódica que suele exigir esta solución, es su mantenimiento, es decir, limpieza de logs y reconstrucción de la caché. Entonces, podemos emplear un par de scripts sencillos para esas dos labores.
Llamaremos al de la reconstrucción de la caché «cache_squid.sh» y al encargado de la rotación de logs «rotalog_squid.sh«. Ambos con permiso de ejecución
El primer archivo contiene la siguiente secuencia de comandos:
#!/bin/bash
#
#
#
#
echo "Parando Squid"
/opt/squid/sbin/squid -k interrupt
echo "Borrando cache de Squid"
rm -rf /opt/squid/var/cache/squid/*
echo "cache borrada"
sleep 1
echo "Iniciando la cache de Squid"
/opt/squid/sbin/squid -f /etc/squid/squid.conf -z
sleep 1
/opt/squid/sbin/squid &
echo "Squid iniciado"
exit 0
El segundo armalo con esta secuencia de comandos:
#!/bin/bash
#
#
#
#
echo "Rotando logs de Squid"
/opt/squid/sbin/squid -k rotate
sleep 1
echo "Logs rotados"
sleep 1
exit 0
Puede colocarlos en el directorio /root/ y programarlos con crontab para que se ejecuten todos los domingos a las 4 y 4:30 PM
00 16 * * 7 root /root/cache_squid.sh
30 16 * * 7 root /root/rotalog_squid.sh
Squid con Máxima Prioridad
Podemos decirle al kernel que nos ejecute a Squid Proxy con la mayor prioridad posible en el planificador de tareas. Solo basta con iniciar Squid con el comando nice, así:
Hasta aquí podemos decir que tenemos ya un servidor Proxy funcional, algo básico para una red de no más 50 equipos de cómputo. A partir de la siguiente entrega verémos configuraciones un poco más avanzadas para redes más grandes.
En la siguiente parte de este tutorial vamos a ampliar la optimización de este servidor, afinando el tratamiento de paquetes a nivel de kernel.
< Quinta Parte Séptima Parte >
Comparte esto en
