Balance de Carga en Servidores Web
Escrito por tejedoresdelweb.com   
Viernes, 29 de Mayo de 2009 09:18

Este artículo discute cómo mejorar el rendimiento de un sitio Web, distribuyendo el tráfico entre varios servidores. El objetivo es utilizar un grupo de servidores estándar, sin tener que recurrir a hardware más costoso.
Tabla de contenidos

    * 1 Introducción
    * 2 La aproximación vía DNS
    * 3 La aproximación vía DNS con BIND


          o 3.1 Listado con varios CNAME
          o 3.2 Configuración de Bind
          o 3.3 Configuración de Zona:
          o 3.4 Archivo de zona para el dominio rr.chilerock.cl.
    * 4 La aproximación utilizando un proxy en reversa
    * 5 Apache como proxy en reversa
    * 6 Balance Bridge-Path y Route-Path

Introducción

¿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 de velocidad de transmisión de la red y de tiempo de respuesta del servidor. Por una parte la velocidad de transmisión 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 tráfico de red.

Una alternativa es instalar más 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. El problema es que a un cierto punto la inversión en hardware comienza a ser considerable, y es preferible aumentar el número de servidores.

En este artículo, asumimos que existen N servidores wwwN.chilerock.cl, y se desea utilizar balance de carga para resolver el problema, la meta es balancear el tráfico a www.chilerock.cl de tal forma que la distribución sea totalmente transparente para el usuario final. Es decir el grupo de servidores se debe ver igual que si fuera una sola máquina, y cada uno de los servidores debe realizar una parte equivalente del trabajo.


La aproximación vía DNS

La primera solución esta basada en el servicio de resolución de nombres (DNS), aprovechandose del hecho que un browser debe como primer paso para obtener el contenido de una URL, 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. Una alternativa para balancear la carga es entregar la dirección IP de uno de los servidores dentro del cluster.

 



Lo que hace funcionar esta solución es el hecho de que gran parte de los servidores de DNS proveen una funcionalidad llamada "round robin", esta permite entregar un número IP distinto, seleccionado desde un conjunto de números IP, cada vez que se recibe una consulta DNS.

Esta solución es simple, elegante, pero tiene sus problemas. El cache de la información en la jerarquía 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 caído, la dirección 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 página no funcionará por que debe esperar a que su información expire. Además el esquema de round robin rigidiza la igualdad de los servidores en el cluster, por ejemplo, los servidores no pueden ser seleccionados según el URL solicitado.

La aproximación vía 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 canónico):

Listado con varios CNAME

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 decisión 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 artículo Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Traffic se 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 ejemplo 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:

Configuración de Bind

 ;;
 ;;  named.boot -- configuración de BIND
 ;;
     :
     :
 ;type     domain          source-file
 primary   chilerock.cl     db.chilerock
 primary   rr.chilerock.cl  db.chilerock.rr
      :
      :
 

 

Configuración 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
                     )
         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


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  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 aproximación utilizando un proxy en reversa

Una alternativa completamente distinta a usar DNS para balancear la carga es utilizar un servidor proxy, pero 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 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:

    * 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).

 


El reparto a esta configuración 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 tendrán los servidores según 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 métodos de implementación de balance de carga, aunque son muchos, pueden ser clasificados como Bridge-Path o Route-Path:

 

 


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, solo se puede mantener una pareja de balanceadores, dado que mas producirían conflictos en el Layer 2.

Página Tejedores del Web

 

Última actualización el Viernes, 29 de Mayo de 2009 16:02
 
Make Text Bigger Make Text Smaller Reset Text Size

Usuarios Online

Tenemos 65 invitados conectado
Titulo Aleatorio