Qué dificil es conformar a todos...

Buenos días, lectores.

El título de esta entrada de blog es una frase que todos debemos haber pronunciado alguna vez... porque es una realidad, totalmente innegable.

En mi actual posición de sysadmin, me encuentro administrando el servidor-router que conecta mi red local con internet. Y debo brindar acceso a todos los servicios de internet a casi 250 personas diariamente. Muchos dirán que tienen más usuarios en sus redes, pero estoy segura que aplican políticas de acceso a la web, especialmente, dado que es el servicio que mayor cantidad de tráfico de red genera y nuestros clientes consumen. Bueno... lo último no es mi caso. 

Por supuesto, hay horarios críticos... y sitios que deben ser accedidos con la mayor prioridad posible... y personas a las que se les debe garantizar una muy buena navegación... y tratar que nadie sienta el acceso ralentizado a algunas páginas... y lidiar con problemas del proveedor de internet. Son muchas condiciones cuando se tienen 100 personas navegando libremente por la web, mirando vídeos, diarios, redes sociales, etc.

Escenario:

• 9Mbit de tráfico de bajada, 2Mbit de tráfico de subida.
• Servicio Squid para acceso HTTP, HTTPS y eventualmente FTP. 
• Acceso a servicios comunes, como correo, FTP, DNS, etc.
• Usuarios exigentes que no aceptan esperar unos segundos que la página cargue (sin excepción).

Solución

• Dividir el tráfico de bajada, asignando un cierto ancho de banda para cada servicio utilizando tc del paquete iproute2.
• Dedicar un ancho de banda a Squid y emplear delay_pools para ralentizar el acceso a ciertos sitios.
• Monitorear el rendimiento.

Para el primer punto, mis reglas de tc quedarían como sigue:

 lan="eth1"
 red_local="192.168.0.0/24"
 pc1="192.168.0.2/32"
 nic_speed="900Mbit"
 download="9Mbit"
 gateway="192.168.0.1/32"
 # borrar todo
 tc qdisc del dev eth1 root  
 # qdisc por defecto 11  
 tc qdisc add dev $lan root handle 1:0 htb default 40  
 tc class add dev $lan parent 1:0 classid 1:1 htb rate $nic_speed ceil $nic_speed  
   # red local - acceso a internet: squid, dns, correo, ftp y otros  
   tc class add dev $lan parent 1:1 classid 1:10 htb rate $download ceil $download  
     tc class add dev $lan parent 1:10 classid 1:11 htb rate 5mbit ceil 8mbit prio 1 # squid  
     tc class add dev $lan parent 1:10 classid 1:12 htb rate 1024kbit ceil 1536kbit prio 2 # dns,correo,ftp,otro  
     tc class add dev $lan parent 1:10 classid 1:13 htb rate 1024kbit ceil 1536kbit prio 3 # otros  
 ######################################################################################  
 #------------------------------------scheduling--------------------------------------#  
 ######################################################################################  
 # asignación equitativa del ancho de banda  
 tc qdisc add dev $lan parent 1:11 handle 11: sfq perturb 10
 tc qdisc add dev $lan parent 1:12 handle 12: sfq perturb 10
 tc qdisc add dev $lan parent 1:13 handle 13: sfq perturb 10
 ######################################################################################  
 #----------------------------------- filtering --------------------------------------#  
 ######################################################################################  
 tc filter add dev $lan protocol ip parent 1:0 prio 1 u32 match ip src $gateway match ip dst $red_local match ip sport 3128 0xffff flowid 1:11 #squid 
 tc filter add dev $lan protocol ip parent 1:0 prio 1 u32 match ip dst $red_local match ip sport 20 0xffff flowid 1:12 #ftp
 .........
 tc filter add dev $lan parent 1:0 protocol ip prio 1 u32 match ip dst $pc1 flowid 1:13 #pc liberada

Con esto conseguí:

1. Asignarle a Squid un mínimo de 5Mbit y un máximo de 8 (en los horarios críticos, cuando todos se conectan, el consumo está a tope) .
2. Dedicar 1Mbit con máximo de 1.5Mbit para servicios como correo, DNS, etc.
3. Garantizarles a ciertos hosts que no utilizan Squid para acceso a la web y requieren un ancho de bajada dedicado.

Para el segundo punto, teniendo en cuenta que lo más consultado durante las horas críticas son diarios y redes sociales, mis delay_pools quedaron como sigue (omitiré muuuchas cosas del squid.conf):

 #------------------------------------------------  
 delay_pools 4  
 delay_initial_bucket_level 90  
 delay_class 1 1  
 delay_access 1 allow exten  
 delay_access 1 deny all  
 delay_parameters 1 100000/90000  
 delay_class 2 1  
 delay_access 2 allow youtube  
 delay_access 2 deny all  
 delay_parameters 7 35000/30000  
 delay_class 3 1  
 delay_access 3 allow facebook  
 delay_access 3 deny all  
 delay_parameters 8 35000/30000  
 delay_class 4 1  
 delay_access 4 allow diarios  
 delay_access 4 deny all  
 delay_parameters 4 90000/85000
 #------------------------------------------------ 

Como se ve, creé unos delay muy generosos para el acceso a las páginas definidas en las ACLs correspondientes, que son: exten (extensiones de archivos, como .exe, .iso, .rar, etc.), facebook, youtube y diarios.

Para el último punto, creé un script en bash para saber qué pasa con mi Squid...

 watch -n 3 "echo '===SQUID REAL TIME MONITOR===' && \  
  'Hosts connected: '; netstat -n | grep '\:3128' | awk '/ESTABLISHED/ {print \$5}' | cut -d: -f1 | sort | uniq -c | wc -l && \  
  echo 'NTLM helpers:'; pgrep -f ntlmssp | wc -l && \  
  echo 'Groups request:'; pgrep -f /usr/lib/squid3/ext_wbinfo_group_acl | wc -l && \  
  echo 'Winbind proceses: '; pgrep -f winbind | wc -l && \  
  echo 'Total GigaByte downloaded:'; awk '{sum += \$5} END {print (sum/1024^3)\" GB\"}' /var/log/squid3/access.log  
  echo 'Disk space usage: '; du -hs /var/log/squid3/ | awk '{print \$1}' &&   
  echo 'Disk space usage (in %) /var:'; df -h | egrep SYSTEM-var | awk '{print \$5}'  
  echo 'Disk space usage (in %) /spool:'; df -h | egrep SYSTEM-spool | awk '{print \$5}'  
  echo 'Queue rate for Squid traffic:'; tc -s -d -r -p class show dev eth1 classid 1:11 | egrep 'rate' | sed -n '$ p' | awk '{print \$1,\$2}'"  

Dado que empleo autenticación para acceder a la caché, monitoreo la cantidad de helpers empleados para que Squid no se quede con solicitudes encoladas. También la cantidad de contenido descargado, espacio usado por los logs (no está demás, aunque teniendo un cron para logrotate bien configurado no tiene que haber problemas de espacio en disco), espacio usado por Squid en disco para almacenar sus objetos y, finalmente, un monitoreo del consumo de la class definida para Squid, para saber el rate que circula por esa disciplina.

Espero que esta entrada de blog les resulte útil. Me llevó tiempo entender muchas cosas de Traffic Control y Squid... hay mucho material en internet disponible para lectura que recomiendo que lo lean.

¡Saludos!