Inicio > Español, Telecentros > Una red de telecentros con software libre: Esquema básico de un telecentro

Una red de telecentros con software libre: Esquema básico de un telecentro

Durante esta entrada trataré de exponer el esquema básico de un telecentro. Trataré de hacer hincapié en el porqué de ciertas decisiones de diseño, y en los errores cometidos. También es fundamental para mi señalar que este desarrollo ha sido el producto del trabajo de un equipo, al que he tenido el gran honor de coordinar: vaya todo el mérito para Alfredo Matas, Javier Hernández, David Teyssiere, Enrique Jiménez, José Ignacio Álvarez y Roberto C. Morano.

¡Al lío!

Esquema de un telecentro

Un telecentro tal y como se concibe en este proyecto, es un conjunto de equipos preparados tanto para el trabajo en local como para la navegación, con una serie de restricciones orientadas a mantener la estabilidad del sistema en el tiempo, la confidencialidad de los usuarios, y el control por parte del equipo técnico. El telecentro es desatendido (no hay un responsable del mismo), y por tanto debe permitir el acceso a los usuarios de forma sencilla y clara.

Esquema básico de la red de telecentros

Conectividad de los equipos

A nivel técnico, estamos hablando de una red local con una serie de equipos e impresoras conectados . La forma en que dichos equipos se conectarían, o mejor dicho la tecnología usada para ello, fue una de las primeras cuestiones que se trataron.

Por parte del equipo técnico se abogó por el cableado completo de los centros. Contamos con experiencia en el uso de WiFi en entornos de producción gracias al proyecto Guadalinfo, y somos conscientes de la inestabilidad, la poca fiabilidad y el escaso ancho de banda de dicha tecnología. Gran parte de los problemas experimentados en dicho proyecto son debidos al uso de tecnología WiFi, por lo que nuestra primera recomendación fue, como he dicho, el cableado de los centros.

No obstante, y debido a problemas logísticos, no fue posible el cableado por lo que la tecnología WiFi quedó como única opción. He de decir que a pesar de los problemas indicados, dicha tecnología ofrece una ventaja importante: la topología de red no puede ser alterada por los usuarios. Ésto es una ventaja importante: en Guadalinfo, la alteración de la topología de red es causa importante de incidencias. Si añadimos que estamos ante centros desatendidos, y por tanto sin vigilancia, dicha ventaja lo es aún más.

Servidor

Otra de las cuestiones que surgieron durante el diseño fue si existiría o no un equipo que ejerciera de servidor en el centro, ofreciendo los servicios necesarios para el funcionamiento del mismo; o si por otro lado tendríamos un centro sin servidor central.

A primera vista, la opción de contar con un servidor en el centro es muy atractiva. Ofrece mucha flexibilidad (se puede habilitar cualquier servicio que se estime necesario siempre que el hardware tenga capacidad para servirlo), el control sobre el centro es más fino y simplifica (aparentemente) el desarrollo. Además:

  • El servidor puede ofrecer servicios que de otro modo tendrían que ofrecerse remotamente. Ésto es aún más relevante si tenemos en cuenta que los telecentros están en algunas de las poblaciones más inaccesibles de Andalucía, y la conexión de banda ancha disponible es inestable y con poco ancho de banda.
  • Si surgen nuevas necesidades en el futuro, pueden cubrirse más fácilmente al contar con un equipo en el centro donde alojar servicios.
  • Se simplifica el desarrollo de la distribución cliente, al no tener que ser tan autónoma.

Este modelo fue el aplicado en Guadalinfo: un servidor central que hace de router para la red interna del centro, ofrece servicios de todo tipo a los equipos, y es controlado remotamente por el equipo técnico y presencialmente por el dinamizador del centro (figura que no existe en los telecentros que estamos tratando).

Pero dicho modelo presenta más inconvenientes de los que en un primer momento podemos percibir. El servidor es un punto único de fallo, que no aporta tantas ventajas en un centro desatendido, y que la experiencia nos dice que ofrece más problemas de los percibidos en un primer momento. Siendo más explícito:

  • Un servidor es un punto único de fallo: hay que tener en cuenta que en muchos de los locales donde se instalan los equipos tienen una instalación eléctrica defectuosa, con corte frecuentes del suministro, y que por tanto los fallos hardware son más frecuentes de lo que en un primer momento podría parecer.
  • En un centro desatendido, no tiene tanto sentido un servidor local: no se desarrollan actividades, no es necesario un control de puestos ni un directorio compartido, etc.
  • Habilitar un servidor en los centros implica mantener dos líneas software: es necesario desarrollar dos “sabores” distintos de la distribución, uno para clientes y otro para servidores. Lo que te ahorras en la configuración de los clientes, lo pierdes ampliamente al tener que desarrollar dos distros.
  • Cualquier usuario podría apagar el equipo servidor confundiéndolo con un equipo cliente, dejando a todo el telecentro sin servicio.

Interfaz web de un router con dd-wrt

Por tanto, ¿por qué opción nos hemos decantado? Bien, hemos optado por un esquema de centro sin servidor, pero con un router compatible con dd-wrt que ofrece los siguientes servicios:

  • Conecta el centro a la VPN que hemos habilitado para toda la red de telecentros, tanto a si mismo como a los clientes, ofreciéndoles una dirección IP única para cada uno a través de DHCP. La autenticación es a través de certificados digitales únicos para cada centro.
  • Permite la monitorización de la conectividad del centro.
  • Cuenta con servicio DNS.
  • Enruta el tráfico propio de los servicios de teleadministración a través de la VPN, dejando el tráfico de navegación fuera de la misma.
  • Prioriza el tráfico de la VPN sobre el resto, a través de QoS.
  • Almacena la MAC de la impresora del centro y le asigna siempre la segunda IP del rango asignado a cada centro.

Al contar con un modelo intermedio entre la completa ausencia de servidor en el centro, y la presencia del mismo, contamos con unas ventajas que nos hicieron decantarnos por este modelo:

  • Contamos con un único punto de fallo en el centro, pero mientras reparar un servidor es caro y costoso en tiempo, sustituir un router defectuoso es mucho más ágil y barato.
  • La fiabilidad y estabilidad de la electrónica de red es mayor que la de un equipo de informática de consumo.
  • El router es capaz de suministrar los servicios básicos necesarios para un centro, sin encontrar necesidades no cubiertas (al menos de momento).

Por tanto, la estructura de un telecentro está formada por un router inteligente con un firmware personalizado basado en dd-wrt, y una serie de equipos e impresoras conectados al mismo a través de tecnología inalámbrica. El router, a su vez, está conectado al router adsl/lmds/vsat que ofrezca conectividad en el centro.

Como veis, hemos intentado aplicar toda la experiencia obtenida en proyectos anteriores de telecentros y desarrollar una estructura sencilla y lo menos propensa a fallos posible, con los medios a nuestra disposición. ¿Qué os parece?

About these ads
  1. Aún no hay comentarios.
  1. No trackbacks yet.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 28 seguidores

%d personas les gusta esto: