En la primera parte hemos visto cómo instalar squid cache para mejorar la navegación, sin embargo, ahora nos vamos a centrar en cómo instalar squid cache como proxy reverso. Esto hará que nuestra instalación Web pueda ser rápida y sobre todo escalable.
A continuáción tenemos un gráfico de una conexión normal de un cliente HTTP a nuestro servidor Web que dispone de un Application Server detras. Como podemos ver, cada petición HTTP entrará en nuestro servidor web y éste hará una peteción a nuestro servidor de aplicaciones que se conectará a la base de datos.
Esta aquitectura es completamente válida, el problema es que no es óptima para numerosos usuarios concurrentes. El problema principal de esta aquitectura está en nuestro servidor Web y cómo cada petición acaba siempre en nuestro Application Server. Imaginemos que tenemos un pico de 5000 conexiones/seg, lo cierto es que tenemos un problema ....Debemos tener en cuenta que podremos servir tantas conexiones como los Límites Teóricos Máximos sobre la parametrización de nuestros servidores web, application server y base de datos, principalmente los siguientes valores:
- Apache HTTPD MaxClients
- Apache Tomcat JK Max Threads
- Oracle/Postgres MaxConnection
Estructura Reverse Proxy
Dentro de esa problemática es donde entra nuestro servidor proxy reverso. Su utilidad radica en que aquellas peticiones cacheables no pasan a nuestro servidor Web/AppServer y por lo tanto, podemos soportar un mayor número de conexiones concurrentes. Además, si añadimos soporte para balanceo tenemos una arquitectura escalable sencilla y potente.
Aquí tenemos una Estructura con Nuestro ReverseProxy
Es cierto que ahora el cuello de botella lo hemos trasladado de nuestros servidores Web a nuestro Proxy Reverso, sin embargo, hemos comentado que es una arquitectura escalable, así que veamos un ejemplo escalando un poco nuestra arquitectura:
Como vemos, hemos incluido un mayor número de reverse proxy en nuestra arquitectura y hemos incluido más web/appserv para conseguir mayor concurrencia. Una vez hemos visto el potencial de un proxy reverso vamos a ver cómo se instala y cuáles son las diferencias en la configuración con una instalación de squid-cache normal.
Compilación squid-cache
La configuración de nuestro squid no dista mucho de cómo lo hemos hecho antes, simplemente debemos incluir --disable-internal-dns como una opción más. En nuestro caso he incluido --with-large-files y --enable-snmp para su monitorización
$ ./configure--prefix=/opt/www/squid-2.7--with-pthreads--with-large-files--with-maxfd=16000--disable-internal-dns--enable-large-cache-files--enable-storeio=ufs,aufs--enable-devpoll--enable-x-accelerator-vary--enable-cache-digests--enable-http-violations--enable-snmp
Compilamos e Instalamos
Como hemos hecho en los artículos anteriores, la compilación se realiza con GNU make, en Solaris por defecto se encuentra en /usr/sfw/bin/gmake
$ make# make install
Configuración de squid-cache
Los parámetros de nuestro squid.conf diferentes serán http_port y cache_peer que los utilizaremos de la siguiente forma:
http_port HOST:PUERTO [defaultsite=VHOST] accel vhost
Donde HOST hará referencia a la IP/HOST en el cual el proxy reverso se encuentra y PUERTO puerto de escucha, normalmente será 80. La opción defaultsite sirve para asignar un VirtualHost por defecto ya que asumimos que nuestro Apache está en modo virtual host
Por otro lado, debemos incluir cache_peer para indicar cuál será realmente nuestro servidor Web de la siguiente forma
cache_peer HOST/IP parent PUERTO 0 no-query originserver round-robin login=PASS name=NOMBRE
Donde HOST/IP hace referencia al servidor Web Original, PUERTO puerto en el que está escuchando el servidor Web y NOMBRE nombre que queremos asignarle, esto se utiliza cuando tienes múltiples cache_peer y quieres que diferentes virtualhost accedan a un grupo de cache_peer diferentes.
Así pues, nuestros cambios sobre el archivo de configuración serán los siguientes:
####################################################### PARAMETROS ADMINISTRATIVOS#####################################################visible_hostname www1.test.comcache_effective_user wwwcache_effective_group wwwhttpd_suppress_version_string on
####################################################### COMMON ACLS######################################################### ALL Sourcesacl all src 0.0.0.0/0.0.0.0
####################################################### PARAMETROS REVERSE PROXY#####################################################http_port revproxy:80 defaultsite=test.com accel vhostcache_peer websrv parent 80 0 no-query originserver round-robin login=PASS name=test
####################################################### SNMP#####################################################acl snmpManager src 192.168.1.16/32acl SNMPPublic snmp_community publicsnmp_access allow snmpManagersnmp_access deny allsnmp_port 7655
####################################################### SEGURIDAD DE HEADER#####################################################forwarded_for off
header_access From deny allheader_access Warning deny allheader_access Via deny allheader_access Proxy-Connection deny allheader_access X-Forwarded-For deny allheader_access X-Cache deny allheader_access X-Cache-Lookup deny all
####################################################### PARAMETRIZACION SEGURIDAD#####################################################acl SSL_ports port 443 # SSLacl Safe_ports port 80-84 # httpacl CONNECT method CONNECT
http_access deny !Safe_portshttp_access deny CONNECT !Safe_ports
Ahora sólo nos queda incluir los hosts que hemos definido en nuestro cache_peer en el archivo /etc/hosts para que squid pueda encontrarlos.
# vi /etc/hosts#################################### REVERSE PROXY##################################192.168.1.201 websrv webserv.test.com192.168.1.202 websrv websrv.test.com192.168.1.203 websrv websrv.test.com
:wq
Finalización de la instalación
Para finalizar, primero verificaremos que el archivo de configuración está bien definido utilizando $SQUID_HOME/sbin/squid -k parse y si todo está correcto lanzaremos $SQUID_HOME/bin/RunCache
# /opt/www/squid-2.7/sbin/squid -k parse# /opt/www/squid-2.7/bin/RunCache &
Conclusiones
Aunque no es un post sobre Alta disponibilidad y Concurrencia hemos visto cómo podemos optimizar nuestros recursos y con unos pequeños cambios aumentar de forma notable el rendimiento de nuestros aplicativos Web.
Hemos visto cómo squid-cache puede darnos mucha mayor funcionalidad y aunque es una tarea ardua cuando tenemos un squid tuneado las ventajas son innumerables.
Una nota sobre la configuración es que hemos utilizado una opción de squid-cache para eliminar las cabeceras referentes al sistema de cache, ésto lo hemos hecho para hacer más transparente la instalación, así mismo, el usuario nunca sabrá que tiene un squid-cache por delante del servidor Web.
pregunta. en la tercera foto, el esquema que planteas. funciona cuando se necesita persistencia?
ResponderEliminar