UNAM CUAED    
 
Presentacin
Presentacin
Contacto
Nm. Anteriores
CUAED
ECOESaD
OUI - COLAM
B@UNAM
UNESCO
Editorial






MATI Sobre la letra digital
Revista Digital Universitaria


Balanceo de carga Web para optimar servicio de Moodle

  • Esta plataforma contribuye a crear comunidades de aprendizaje en línea
  • Permite atender a un mayor número de conexiones y usuarios

Guadalupe Susana Ramos Palacios
Ulises Valderrama Abad

nternet ha impulsado nuevas formas para realizar las actividades cotidianas. En la educación, por ejemplo, potencia la modalidad a distancia, pues prácticamente puede realizarse desde cualquier parte del mundo con ayuda de una computadora y una conexión a la red.

La atención a la creciente demanda de educación a distancia en bachilleratos, licenciaturas, posgrados y diversas opciones de actualización profesional es una tendencia que representa un desafío en los ámbitos técnico y tecnológico, al requerir de sistemas estables, activos y eficientes que soporten la carga de trabajo y de recursos computacionales demandados por alumnos, tutores y asesores que hagan uso de los cursos establecidos en esta modalidad académica.

Moodle (Sistema de Administración de Aprendizaje) es una plataforma de libre distribución que por sus facilidades de manejo y adopción entre los participantes de la educación a distancia, ayuda a los educadores a crear comunidades de aprendizaje en línea. Una gran oportunidad de mejora de esta plataforma y que significa un reto a superar desde el punto de vista técnico-administrativo es cómo resolver el incremento en la demanda de recursos del servidor que lo aloja (Memoria RAM y procesamiento), conforme aumenta el número de conexiones o usuarios concurrentes de la plataforma.

Para enfrentar este reto es necesaria la distribución de servicio Web y de base de datos (BD) mediante cluster balanceador de carga que permite distribuir el servicio Web en un número n de servidores, todos conteniendo la misma información, lo cual hace posible distribuir las peticiones entre todos ellos, evitando así que un solo servidor degrade su desempeño. Un esquema de este tipo facilita agregar o quitar servidores al cluster balanceador de carga, según cambien las necesidades del proyecto.

Descripción del sistema

Un cluster es un conjunto de servidores Web que por medio y junto con un servidor llamado balanceador de carga, permite dar la apariencia de ser un solo servidor Web (virtual). El balanceador de carga debe contar con dos paquetes de software: ipvsadm y Linux Virtual Server (LVS), los cuales distribuyen las conexiones entre todos los servidores Web que responderán a un mismo dominio asociado a la dirección IP del balanceador.

Colocado al frente de los servidores Web, el balanceador de carga es el receptor de las peticiones hechas al dominio asociado a su dirección IP para repartirlas por la red local entre todos los servidores Web que responden a un dominio. Por medio de un criterio de distribución llamado Weighted Least-Connection (wlc) se asigna un valor de rendimiento a cada servidor, donde la asignación de peso a un servidor (weight de 1 a 3) determinará la cantidad de peticiones recibidas aplicando el criterio de weight. Con el criterio de least-connection se mandarán más peticiones al servidor que tenga menos conexiones activas, tratando de que los servidores con el mismo peso se mantengan con un número de conexiones similares.

El balanceador de carga es simplemente la puerta que da entrada al conjunto de servidores. Las peticiones llegan a un dominio y el balanceador las redirecciona a uno que en realidad hace el trabajo.

Es importante mencionar que todos los servidores Web deben responder al mismo dominio, contar con la misma información y proveer el mismo servicio, de forma que sin importar cuál de ellos responda, el usuario reciba la misma información en la respuesta.

Con el software ipvsadm el equipo balanceador de carga maneja diferentes criterios de balanceo, entre ellos:

  • rr - Robin Robin: distribuye las peticiones en cantidades iguales entre los servidores del cluster.
  • wrr - Weighted Round Robin: asigna las nuevas peticiones entre los servidores del cluster de manera proporcional a su peso. Los que tengan mayor peso recibirán más peticiones que los de menor peso. Los servidores con pesos iguales recibirán el mismo número de nuevas peticiones.
  • lc - Least-Connection: asigna más peticiones entrantes al servidor con menor número de conexiones.
  • wlc - Weighted Least-Connection: asigna peticiones entrantes a los servidores con menor número de conexiones y mayor peso.
  • lblc - Locality-Based Least-Connection: asigna peticiones entrantes destinadas a una misma IP al mismo servidor, si éste no está sobrecargado. De otro modo, las asigna a los servidores con menor actividad y lo guarda para una futura asignación.
  • lblcr - Locality-Based Least-Connection with Replication: asigna peticiones entrantes destinadas a la misma IP al nodo con menos conexiones del conjunto de servidores que tienen la misma IP. Si todos los nodos de este conjunto están sobrecargados, envía la petición a otro con menos conexiones en el cluster y lo agrega al conjunto. Si el servidor no ha sido modificado durante un tiempo especificado, el nodo más sobrecargado en este conjunto es removido para evitar un alto grado de replicación.

Por otra parte, los clusters desarrollados con Linux Virtual Server posibilitan la implementación de tres tipos de arquitectura para el manejo de las peticiones y el direccionamiento entre el balanceador de carga y los servidores web.

  • Arquitectura de direccionamiento directo
  • Arquitectura vía túnel de IP
  • Arquitectura vía NAT

La arquitectura de direccionamiento directo consiste en tener conectados físicamente los servidores Web junto con el balanceador de carga dentro de un segmento LAN ininterrumpido por medio de un dispositivo activo de interconexión como un Switch Ethernet.

En esta arquitectura, el balanceador redirecciona las peticiones entrantes al servidor Web elegido, al cambiar la dirección MAC (Medium Access Control) del encabezado de los paquetes que contienen las peticiones, por aquella que le pertenece al servidor Web asignado y los retransmite a través de la red local (LAN).

El balanceador de carga es un equipo que no necesita demasiados recursos, pues su actividad consiste en redireccionar las peticiones a los servidores Web que son en realidad los que realizan todo el trabajo de la plataforma de educación a distancia. Puede considerarse un equipo con una capacidad mínima de memoria de 2GB, un procesador P IV a 2 GHz y espacio en disco de al menos 2GB. Requiere tener instalado SO Linux, Kernel 2.6.x o más e ipvsadm. Actualmente equipos más sofisticados que realizan la función de balanceo, con una arquitectura diseñada para ello.

Aunque los requerimientos de los servidores Web pueden variar, dependiendo del tipo de aplicación que alberguen y del de páginas electrónicas que contengan (estáticas o dinámicas), en el caso de la plataforma Moodle las características dependerán del número de cursos, alumnos, tutores y asesores que existan. En cuanto al SW, se requiere SO, Linux Red Hat EL 4, Apache 1.3.41, MySQL 5.0.41 y PHP 4.4.7

En diversas pruebas de este sistema se observa que el balanceador de carga redireccionó todas las peticiones entrantes haciendo que los servidores de Web atendieran el mismo número de ellas, obteniendo así lo esperado de acuerdo con el criterio de balanceo de Round Robin e impidiendo la sobresaturación de los equipos. Además, el balanceador no consume muchos recursos de hardware, pues sólo redirecciona las peticiones entrantes y los que sí consumen recursos son los servidores Web que atenderán las solicitudes enviadas por el balanceador.

Alcances del cluster balanceador de carga

  • No hace uso excesivo de recursos de hardware por lo que puede implementarse fácilmente en un equipo con las características mínimas antes descritas.
  • Puede ser fácilmente escalable. Sólo basta con agregar el nuevo servidor al balanceador para que comience a recibir peticiones.
  • Funcionalidad permanente. A pesar de que uno de los servidores sufra una falla de software o hardware, el resto sigue respondiendo a las peticiones y el servidor dañado puede sacarse fácilmente del cluster dándolo de baja del balanceador.
  • Bajo costo por trabajar con software libre y permite integrar equipos con diferentes características de hardware.
  • Cuando la petición de un usuario es redireccionada a un servidor, éste atenderá la solicitud durante el tiempo en el que el usuario se encuentre conectado al sistema. Cuando el mismo usuario realiza una nueva petición, el balanceador se encargará de redireccionar su petición a uno de los servidores disponibles, por lo que puede o no ser atendido por el mismo servidor del cluster.
  • Transparente para el usuario. Nunca percibirán si su petición es redireccionada a uno u otro servidor del cluster.
  • No hay replica de la información contenida entre todos los servidores Web. Esta información debe ser exactamente igual en todos los servidores, por lo que para cumplir con este requisito, es necesario contar con un esquema de replicación entre estos equipos.

Limitaciones del cluster balanceador de carga

  • El cluster tiene un punto de falla importante: el balanceador de carga. Si éste llegara a fallar, ningunos de los servidores Web podrá atender las peticiones de los usuarios pues es él quien decide cuál de los servidores atenderá a cada una de las peticiones. Por esta razón es importante contar con un esquema de alta disponibilidad en este equipo, ya que si en algún momento falla el balanceador principal, puede entrar en funcionamiento uno secundario.
  • El cluster no presenta un “cuello de botella”. Todos los servidores de Web, una vez que han recibido la petición redirigida por el balanceador, atienden a dicha petición y envían la respuesta directamente al usuario, por lo que la respuesta no pasa de nuevo por el balanceador, evitando así un “cuello de botella”.

home

 
   
   
La responsabilidad de los artículos publicados recae, de manera exclusiva, en sus autores
Congreso
Tecnologa
Educacin
   
 

® D.R. 2000-2007 Universidad Nacional Autónoma de México, Coordinación de Universidad Abierta y Educación a Distancia,
Circuito Exterior, Cd. Universitaria, México, D. F. Hecho en México.
Se autoriza la reproducción total o parcial de los artículos aquí presentados, siempre y cuando se cite al autor, la fuente completa y la dirección electrónica