|
por Mauricio Paredes
Balance de Carga
- 1. Introducción
- 2. La aproximación vía DNS
- 3. La aproximación vía DNS con BIND
- 4. La aproximación utilizando un proxy en reversa
- 5. Apache como proxy en reversa
- 6. Balance Bridge-Path y Route-Path
- 7. Vínculos
¿Que hacer cuando se maneja un sitio exitoso en Internet y la cantidad de visitantes y el volumen de datos transmitidos llegan a ser un problema?. ¿Cual es el problema?, el problema es el descontento de los usuario del sitio, es decir una pérdida en la calidad del servicio, en términos ingenieriles típicamente depende de dos parámetros, la velocidad de transmisión de la redy el tiempo de respuesta del servidor. Por una parte la velocidad de transmisión de la reddepende casi completamente del ancho de banda del enlace y de su disponibilidad, por la otra el tiempo de respuesta del servidordepende de otros recursos como la velocidad de la CPU (especialmente para programas CGI), memoria RAM, y un buen performance en entrada/salida (I/O) especialmente para discos y tráfico de red.
Se puede instalar mas RAM en las maquinas existentes, o reemplazar las CPU por otras más veloces, o intalar controladores SCSI y discos con menores tiempos de acceso, quisá sistemas RAID con un cache inmenso, optimizar el Software, ya sea el sistema operativo o el software del servicio Web, todo esto para mejorar el performance. O se puede utilizar una aproximacion alternativa: Mejorar el performance aumentando el número de servidores Web. Esto involucra distribuir el tráfico en un grupo (cluster) de servidores Web. Aparte del reto técnico esta aproximación es interesante por que con ella los servidores Web no necesitan ser máquinas de gran escala.
Suponiendo que se tienen N servidores wwwN.chilerock.cl, y se desee utilizar la aproximación por cluster para resolver el problema, la meta es balancear el tráfico a www.chilerock.cl de tal forma que la distribución técnica sea totalmente transparente para el usuario final. Es decir el nuevo cluster de servidores se debe comportar de forma identica que la aproximación con una sola máquina.
La primera solución esta basada en el servicio de resolución de nombre, aprovechandose del hecho que un explorador debe tomar como primer paso para obtener el contenido de la URL http://www.chilerock.cl/discos/discos.cgi es resolver su número IP. Esto se logra consultando a un servidor DNS cercano, el cual desencadena una serie de solicitudes entre servidores DNS que finalmente responde con el número IP. Entonces en vez de entregar una dirección estática el servidor de DNS entrega el número IP de uno de los servidores dentro del cluster.
| Aproximación vía DNS |
 |
Lo que hace funcionar esta solución es el echo de que gran parte de los servidores de DNS proveen una funcionalidad llamada "round robin", esta permite entregar un número IP en particular, seleccionado desde un conjunto de números IP, cuando una consulta DNS llega.
Esta solución es simple, elegante, pero tiene sus contras. El cache de la información en la jerarquía de servidores DNS y la forma simple de tomar las deciciones (round robin) por parte de el servidor de DNS restringen su utilidad. Por ejemplo si uno de los servidores en el cluster esta caído, la dirección www.chilerock.cl no estará disponible para todos los visitantes que acceden a ese servidor, y esto durará por lo menos por el TTL que se utilizó, el recargar la página no funcionará por que debe esperar a que su información expire. El esquema de round robin rigidiza la igualdad de los servidores en el cluster, los servidores no pueden ser seleccionados según el URL solicitado (separando a los trabajos intensivos en CPU como los GCI impidiendo que la información estatica también se demore).
Para implementar esto se configura al dominio www.chilerock.cl como in alias mapeado a los servidores del cluster wwwN.chilerock.cl usando multiples lineas CNAME (nombre canónico):
www.chilerock.cl. IN CNAME www1.chilerock.cl
IN CNAME www2.chilerock.cl
IN CNAME www3.chilerock.cl
IN CNAME www4.chilerock.cl
IN CNAME www5.chilerock.cl
IN CNAME www6.chilerock.cl
Todo esto suena perfecto, el tráfico está distribuido igualitariamente en el cluster, pero en la práctica hay que luchar contra el hecho de que los servidores de DNS guardan un cache que resuelve los números IP en cualquier nivel de la jerarquía. Este cache es controlado por el parámetro TTL (time-to-live), que es agregado en cada pieza de información entregada por el servidor de DNS, y que reside el campo SOA (start of authority) de los archivos de zona de BIND, mismo archivo donde residen los CNAME.
Ahora aparece un nuevo problema: cuando se setea el parámetro TTL muy alto disminuyen las consultas DNS por el enlace a Internet, pero por otra parte los otros servidores DNS retienen la información en el cache por mucho tiempo, lo que lleva a tener una mala distribución del tráfico en la carga de los servidores. En cambio setear el parámetro TTL muy bajo aumenta el tráfico de solicitudes DNS y el tiempo de solicitus del visitante dramaticamente dado que los otros servidores de DNS expiran la información más rápido y por lo tanto deben resolverla más seguido, pero se obtiene un mejor balance de la distribución del tráfico. La desición de cual es el valor que el parámetro TTL debe tener depende de cuantos delays intermitentes se piense que un visitante esta dispuesto a aceptar anter de considerar que se perdió en la calidad del servicio, y cual es el nivel de balance que se desea. En el artículo Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Trafficse sugiere un valor de una hora para parámetro TTL.
Un último problema queda, al disminuir el parámetro TTL del archivo de zona para se obtiene el efecto deseado, pero al mismo tiempo se el TTL de todos las direcciones en el archivo, por ejeplo para ftp.chilerock.cl. La solución en este caso es utilizar un pequeño truco, separando los servidores del cluster en un archivo de zona distinto y por lo tanto en un subdominio de chilerock.cl, para el ejemplo llamado rr.chilerock.cl. Como resultado se obtiene un archivo de configuracion de BIND y dos archivos de configuracion de zona:
;;
;; named.boot -- configuración de BIND
;;
:
:
;type domain source-file
primary chilerock.cl db.chilerock
primary rr.chilerock.cl db.chilerock.rr
:
:
;
; db.chilerock -- zona de BIND DNS para chilerock.cl
;
IN SOA world.chilerock.cl. root.world.chilerock.cl. (
1998021502 ; SERIAL
604800 ; REFRESH: Secondaries refresh after 1 week
3600 ; RETRY: Secondaries retry after 1 hour
604800 ; EXPIRE: Maximum TTL of Data is 1 week
86400 ; MINTTL: Minimum TTL of Data is 1 day
)
IN NS ns.chilerock.cl.
;;
;; the resource record for www.foo.dom which
;; maps to the Round-Robin domain
;;
www IN CNAME www.rr.chilerock.cl. ;; aqui es donde apunta a otro archivo
ftp IN A 192.168.1.253
;
; db.chilerock.rr -- zona de BIND DNS para rr.chilerock.cl
;
;
; the start of authority (SOA) resource record which
; forces a minimal time-to-live (TTL) for this zone file
;
IN SOA world.chilerock.cl. root.world.chilerock.cl. (
1998021501 ; SERIAL
3600 ; REFRESH: Secondaries refresh after 1 hour
600 ; RETRY: Secondaries retry after 10 minutes
3600 ; EXPIRE: Maximum TTL of Data is 1 hour
1800 ; MINTTL: Minimum TTL of Data is 30 minutes
)
IN NS ns.chilerock.cl.
;;
;; the multiple canonical name (CNAME) resource record
;; which implies BIND's Round-Robin (RR) feature
;;
www IN CNAME www1.rr.chilerock.cl.
IN CNAME www2.rr.chilerock.cl.
IN CNAME www3.rr.chilerock.cl.
IN CNAME www4.rr.chilerock.cl.
IN CNAME www5.rr.chilerock.cl.
IN CNAME www6.rr.chilerock.cl.
;;
;; the address (A) resource records for the
;; final NAME -> IP mapping
;;
www1 IN A 192.168.1.1
www2 IN A 192.168.1.2
www3 IN A 192.168.1.3
www4 IN A 192.168.1.4
www5 IN A 192.168.1.5
www6 IN A 192.168.1.6
La idea esta vez consiste en utilizar un servidor proxy que opera en la dirección contaria a su uso normal. Un proxy en reversa se hace pasar como el servidor final (www.chilerock.cl) y traduce el URL relativo recibido en un URL absoluto dirigido a uno de los sevidores en el cluster. En la siguiente figura se puede observar como para los navegadores el proxy en reversa aparece como el servidor final, pero en vez de servir la solicitud el mismo, determina el servidor que va a responder, envia la solicitud y despues encamina la respuesta. Ahora los servidores en el cluster pueden pertenecer a una subred enmascarada por el servidor proxy en reversa y no se hacen necesarios truco con el DNS.
| Aproximación vía Proxy en Reversa |
 |
Esta aproximacion tiene sus ventajas:
- La primera es que como existe un unico punto de acceso, es mucho mas facil hacer log y monitorear el sitio (que con la version por DNS).
- La segunda es que ahora se tiene total control del esquema de delegación, dado que es realizado localmente en el proxy para cada solicitud y no esta en algún cache en Internet, lo que conlleva a un mejor balance de la carga.
- La tercera es que al poder manejar el esquema de delegación permite responder a eventualidades, como la caida de un servidor, modificando el esquema y terminando inmediatamente con los problemas de los usuarios (y las páginas de error). Una vez reparado se puede reactivar de forma tan simple como fue desactivado.
Soluciones para implementar este esquema existen muchas, por ejemplo proxy de software (como Squid, Internet Object Cache, Netscape Proxy Server, Microsoft Proxy, Netra Proxy Cache Server) y otras por hardware dedicado (LocalDirector de Cisco Systems y Equalizar de Coyote Point, CS-100 de ArrowPoint, BIG/ip de F5 Networks).
| Aproximación via proxy en reversa usando una subred |
 |
El reparo a esta configuración de balance de carga es que aun existe un único punto de falla, y ahora es el balanceador.
Existen muchos métodos para implementar el balance de carga, y usualmente un producto es capaz de funcionar en muchas de ellas, sin embargo esto puede ser simplificado en dos categorias: Bridge-Path y Route-Path, las que se explican más adelante.
Desde apache 1.3.0 los parches necesarios para construir un proxy en reversa ya han sido incluidos, y lo único necesario es este script (apache-rproxy.mk) y las fuentes de Apache que contruye una versión de Apache limitada y especialmente orientada a servir como proxy en reversa.
En el listado 5 se muestra como agrupar los servidores del cluster de tal forma que respondan a distintos contenidos, para este caso se agrupan cuatro servidodes bajo la etiqueta static, y otros dos bajo la etiqueta dinamic.
Luego en el listado 6 se configura apache y las reglas de reescritura que lo convierten en un proxy en reversa. Notar que en estas reglas se decide cual será el uso que tendrán los servidores según sus etiquetas.
# # apache-rproxy.conf-servers -- Apache/mod_rewrite selection table # # list of back-end servers which serve static # pages (HTML files and Images, etc.) static www1.foo.dom|www2.foo.dom|www3.foo.dom|www4.foo.dom # list of back-end servers which serve dynamically # generated page (CGI programs or mod_perl scripts) dynamic www5.foo.dom|www6.foo.dom
#
# apache-rproxy.conf -- Apache configuration for Reverse Proxy Usage
#
:
:
:
# define a rewriting map with value-lists where
# mod_rewrite randomly chooses a particular value
RewriteMap server rnd:/path/to/apache-rproxy.conf-servers
# make sure the status page is handled locally
# and make sure no one uses our proxy except ourself
RewriteRule ^/rproxy-status.* - [L]
RewriteRule ^(http|ftp)://.* - [F]
# now choose the possible servers for particular URL types
RewriteRule ^/(.*\.(cgi|shtml))$ to://${server:dynamic}/$1
[S=1]
RewriteRule ^/(.*)$ to://${server:static}/$1
# and delegate the generated URL by passing it
# through the proxy module
RewriteRule ^to://([^/]+)/(.*) http://$1/$2 [E=SERVER:$1,P,L]
# and make really sure all other stuff is forbidden
# when it should survive the above rules...
RewriteRule .* - [F]
:
:
:
 | Archivo de configuración Apache rproxy completo [.zip, 1.2Kb] |
| Archivo de configuración de ejemplo, para aprender a configurar Apache como proxy en reversa. |
Los métodos de implementación de balance de carga, aunque son muchos, pueden ser clasificados como Bridge-Path o Route-Path.
| Tráfico y el balanceador de carga |
 |
El la figura se observa que el tráfico de un usuario que llega hasta el balanceador (paso 1), luego el balanceador decide a que servidor envia la solicitus (paso 2), el servidor Web responde y envia el tráfico de regreso al balanceador (paso 3) y finalmente el tráfico deja al balanceador (paso 4).
En el caso de Balance de carga Bridge-Path el tráfico recorre el camino tal y como se acaba de explicar y el balanceador se encuentra en el camino del Layer 2, actuando como puente entre dos redes. El problema en este caso es que el Layer 2 por naturaleza debe tener un solo camino hasta un objetivo, si hay mas de uno existirán problemas serios.
En el caso de Balance de carga Route-Path el tráfico recorre el mismo camino pero a diferencia el balanceador se encuentra en el Layer 3 y es la ruta por defecto del cluster de servidores.
La gran ventaja de utilizar Balance Route-Path está en la escalabilidad, dado que en Bridge-Path solo puede existir una sola ruta, el mantener redundancia significa mantener un balanceador inactivo hasta que el otro falle, y lo que es peor, sole se puede mantener una pareja de balanceadores, dado que mas prducirían conflictos en el Layer 2.
- 1. Load Balancing Your Web Site
- 2. Wide-area load balancing
- 3. Bridge-Path vs. Route-Path Server Load Balancing
- 4. Load Balancers As Firewalls
- 5. It's Always the Load Balancer
- 6. Preparing Your Site for Speed and Reliability
- 7. Speed and Reliability, Part Two
- 8. Load Balancing: Where the Action Is
- 9. Web Site Aims for the Big Time with Load Balancing
- 10. Business Case: Loading Up -- High-Speed Transaction Processing on the Internet
- 11. Linux Virtual Server Project
- 12. Eddie
- 13. Piranha
- 14. VAnessa, VA Network Enhanced Scalable Server Architecture
|
