Balance de carga

y y y y y

Artculo Discusin Ver cdigo fuente Historial Versin para imprimir

Este artculo discute cmo mejorar el rendimiento de un sitio Web, distribuyendo el trfico entre varios servidores. El objetivo es utilizar un grupo de servidores estndar, sin tener que recurrir a hardware ms costoso.

Tabla de contenidos
[ocultar]
y y y

y y

y y

1 Introduccin 2 La aproximacin va DNS 3 La aproximacin va DNS con BIND o 3.1 Listado con varios CNAME o 3.2 Configuracin de Bind o 3.3 Configuracin de Zona: o 3.4 Archivo de zona para el dominio rr.chilerock.cl. 4 La aproximacin utilizando un proxy en reversa 5 Apache como proxy en reversa o 5.1 Archivo de configuracion de cluster de servidores apache-rproxy. o 5.2 Extracto de configuracion de apache especializado en rproxy: 6 Balance Bridge-Path y Route-Path 7 Vnculos

Introduccin
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 prdida en la calidad del servicio, en trminos de velocidad de transmisin de la red y de tiempo de respuesta del servidor. Por una parte la velocidad de transmisin de la red depende casi completamente del ancho de banda del enlace del servidor, mientras que el tiempo de respuesta del servidor depende de otros factores como la velocidad del procesador, la memoria RAM disponible, y un buen performance en las operaciones de entrada/salida (I/O) especialmente para discos y trfico de red. Una alternativa es instalar ms RAM en las maquinas existentes, o reemplazar las CPU por otras ms 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. El problema es que a un cierto punto

la inversin en hardware comienza a ser considerable, y es preferible aumentar el nmero de servidores. En este artculo, asumimos que existen N servidores wwwN.chilerock.cl, y se desea utilizar balance de carga para resolver el problema, la meta es balancear el trfico a www.chilerock.cl de tal forma que la distribucin sea totalmente transparente para el usuario final. Es decir el grupo de servidores se debe ver igual que si fuera una sola mquina, y cada uno de los servidores debe realizar una parte equivalente del trabajo.

La aproximacin va DNS
La primera solucin esta basada en el servicio de resolucin de nombres (DNS), aprovechandose del hecho que un browser debe como primer paso para obtener el contenido de una URL, resolver su nmero 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 nmero IP. Una alternativa para balancear la carga es entregar la direccin IP de uno de los servidores dentro del cluster.

Lo que hace funcionar esta solucin es el hecho de que gran parte de los servidores de DNS proveen una funcionalidad llamada "round robin", esta permite entregar un nmero IP distinto, seleccionado desde un conjunto de nmeros IP, cada vez que se recibe una consulta DNS. Esta solucin es simple, elegante, pero tiene sus problemas. El cache de la informacin en la jerarqua de servidores DNS y la forma simple de tomar las decisiones (round robin) por parte de el servidor de DNS restringen su utilidad. Por ejemplo si uno de los servidores en el grupo esta cado, la direccin www.chilerock.cl no estar disponible para todos los visitantes que sean dirigidos a ese servidor, y esto durar por lo menos por el TTL (time to live, tiempo de vida del registro DNS) que se utiliz, el recargar la pgina no funcionar por que debe esperar a que su informacin expire. Adems el

esquema de round robin rigidiza la igualdad de los servidores en el cluster, por ejemplo, los servidores no pueden ser seleccionados segn el URL solicitado.

La aproximacin va DNS con BIND

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 cannico):

Listado con varios CNAME

www.chilerock.cl. IN IN IN IN IN IN CNAME CNAME CNAME CNAME CNAME CNAME www1.chilerock.cl www2.chilerock.cl www3.chilerock.cl www4.chilerock.cl www5.chilerock.cl www6.chilerock.cl

Todo esto suena perfecto, el trfico est distribuido igualitariamente en el cluster, pero en la prctica hay que luchar contra el hecho de que los servidores de DNS guardan un cache que resuelve los nmeros IP en cualquier nivel de la jerarqua. Este cache es controlado por el parmetro TTL (time-to-live), que es agregado en cada pieza de informacin 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 parmetro TTL muy alto disminuyen las consultas DNS por el enlace a Internet, pero por otra parte los otros servidores DNS retienen la informacin en el cache por mucho tiempo, lo que lleva a tener una mala distribucin del trfico en la carga de los servidores. En cambio setear el parmetro TTL muy bajo aumenta el trfico de solicitudes DNS y el tiempo de solicitus del visitante dramaticamente dado que los otros servidores de DNS expiran la informacin ms rpido y por lo tanto deben resolverla ms seguido, pero se obtiene un mejor balance de la distribucin del trfico. La decisin del TTL ptimo 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 artculo Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Traffic se sugiere un valor de una hora para parmetro TTL. Un ltimo problema queda, al disminuir el parmetro 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 ejemplo para ftp.chilerock.cl. La solucin en este caso es utilizar un pequeo 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:

Configuracin de Bind

;; ;; ;;

named.boot -- configuracin de BIND

: : ;type primary primary : :

domain source -file chilerock.cl db.chilerock rr.chilerock.cl db.chilerock.rr

Configuracin de Zona:
; ; ; 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 ) NS ns.chilerock.cl.

IN ;; ;; 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

Archivo de zona para el dominio rr.chilerock.cl.

; ; ; ; ; ; ; 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 IN

CNAME CNAME

www5.rr.chilerock.cl. 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 aproximacin utilizando un proxy en reversa

Una alternativa completamente distinta a usar DNS para balancear la carga es utilizar un servidor proxy, pero en la direccin contaria a su uso normal. Un proxy en reversa se hace pasar como el servidor final (www.chilerock.cl) y traduce el URL recibido en un URL interno 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 trucos con el DNS.

Esta aproximacion tiene sus ventajas:

y

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 delegacin, dado que es realizado localmente en el proxy para cada solicitud y no esta en algn cache en Internet, lo que conlleva a un mejor balance de la carga. La tercera es que al poder manejar el esquema de delegacin permite responder a eventualidades, como la caida de un servidor, modificando el esquema y terminando inmediatamente con los problemas de los usuarios (y las pginas 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).

El reparto a esta configuracin de balance de carga es que aun existe un nico punto de falla, y ahora es el balanceador.

Apache como proxy en reversa

Desde apache 1.3.0 se puede configurar Apache como un proxy en reversa. En el listado de abajo 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 siguiente listado 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 tendrn los servidores segn sus etiquetas.

Archivo de configuracion de cluster de servidores apache-rproxy.

# # 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

Extracto de configuracion de apache especializado en rproxy:

# # # 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] : : :

Balance Bridge-Path y Route-Path

Los mtodos de implementacin de balance de carga, aunque son muchos, pueden ser clasificados como Bridge-Path o Route-Path:

El la figura se observa que el trfico 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 trfico de regreso al balanceador (paso 3) y finalmente el trfico deja al balanceador (paso 4). En el caso de Balance de carga Bridge-Path el trfico 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 existirn problemas serios. En el caso de Balance de carga Route-Path el trfico 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, solo se puede mantener una pareja de balanceadores, dado que mas produciran conflictos en el Layer 2.