propuestas de mejoras y actualización del servicio de - ctica

Anuncio
PROPUESTAS DE MEJORAS Y ACTUALIZACIÓN
DEL SERVICIO DE CORREO ELECTRÓNICO DE
LA DE LA UNIVERSIDAD DE LOS ANDES
R. Calderón1, J. L. Chávez2, G. Díaz3,
Centro de Tecnologías de la Información (CTI)
Corporación Parque Tecnológico de Mérida (CPTM)
Septiembre 2.010
1 calderon@ula,ve
2 juanluis@ula.ve
3 gilberto@ula.ve
Plataforma de alta disponibilidad y alto rendimiento
para servicios de correo electrónico.
Conceptos Básicos
Antes de realizar la descripción de la arquitectura propuesta se definen los distintos elementos
que actúan en el proceso de envío y recepción de correo electrónico:
-
Mail User Agent (MUA).
-
Mail Transfer Agent (MTA).
-
Mail Submission Agent (MSA).
-
Mail Delivery Agent (MDA).
Para una comprensión inicial de cada elemento observemos el esquema que se muestra en la
siguiente figura:
Mail User Agent Mail (MUA)
Comúnmente conocido también como cliente de correo cliente de correo, es un programa utilizado de forma directa por los usuarios para gestionar su correo electrónico. Es aquel programa
que se utiliza para: leer, redactar, responder y eliminar mensajes. Generalmente está activo
cuando el usuario lo ejecuta. Así mismo, podemos encontrar varios MUAs en el mismo computador. Dentro de los MUA más conocidos tenemos: Thunderbird, Eudora, Outlook, Pine, Aplicaciones webmail. Las tareas más importantes que realiza un cliente de correo electrónico son:
-
Búsqueda y descarga de Mensajes: Búsqueda y descarga de Mensajes: Generalmente el
MUA se conecta al buzón del usuario que se encuentra localizado en un servidor remoto.
La conexión al buzón se puede hacer utilizando dos protocolos:
• Post Office Protocol (POP): Este protocolo permite descargar los mensajes del
buzón de correo y almacenarlos localmente. POP descarga uno por uno los mensajes de correo y elimina el mensaje del servidor sólo si éste se descargó correctamente. Es posible descargar los mensajes y conservar una copia en el servidor y
posteriormente descargarlos con otro MUA.
• Internet Message Access Protocol (IMAP): Mantiene una conexión activa entre
el MUA y el buzón de correo. Los mensajes se mantienen en el buzón ubicado en
el servidor.
-
Envío de Mensajes: Puede introducir mensajes de correo electrónico al sistema para ser
enviado a otro sitio remoto. Para ello, el MUA se contecta a un servidor de correo el cual
puede ser un MSA o un MTA. Estos dos últimos elementos son los dos tipos de servidores
que manejan el protocolo SMTP (Simple Mail Transport Protocol). El MUA debe colocar
rápidamente el mensaje en el sistema de transporte sin necesidad de preocuparse de a
donde tiene que ser enviado el mensaje. El MUA siempre se conecta al mismo servidor
configurado como preferido. Utiliza el Puerto 25 para MTA o el 587 para MSA.
Mail Delivery Agent (MDA)
Es un programa que se encarga de colocar los mensajes de correo electrónico en los buzones de
los usuarios una vez que el servidor los acepta. Los MDAs más utilizados actualmente son:
Procmail y Maildrop. El MDA es invocado por el MTA para realizar la entrega del mensaje. Las
funciones de un MDA además de la entrega de mensajes son: filtrar los mensajes y ordenar los
mensajes en carpetas.
Buzón de Correo
Los buzones de correo (mailbox mailbox) son el sitio donde se almacenan los mensajes una vez
que fueron aceptados por el servidor (MTA). Los buzones de correo tienen actualmente dos formatos: Mbox Mbox: donde se almacenan todos los mensajes en un archivo y Maildir Maildir:
donde se utiliza un directorio donde se guardan múltiples archivos. Cada archivo es un mensaje.
Mail Transfer Agent (MTA)
Es un programa que se encarga de transferir mensajes de correo electrónico entre computadores. Los MTAs más utilizados actualmente son: Sendmail y Postfix. Un servidor de correo puede
recibir mensajes desde un MUA o desde otro MTA.
Caracterización del Servicio
El servicio de correo electrónico tiene características particulares que deben ser consideradas
en el proceso de implantación del servicio. Estas características son:
-
Intensivo en IO: Elevado Este servicio realiza grandes cantidades de operaciones de Entrada/Salida pues los buzones son guardados en medios de almacenamiento de gran capacidad (discos duros). Así mismo, los archivos que se manejan tienen un tamaño relativamente pequeño (aproximadamente 500KB en promedio).
-
Intensivo en procesamiento: Cada mensaje necesita ser revisado para determinar la
existencia de virus o verificar si éste representa un correo no deseado (spam).
-
Archivos Adjuntos: Actualmente es muy común encontrar mensajes de correo contentivos
de documentos adjuntos. Esto ha incrementado el tamaño promedio de los mensajes y por
ende el tiempo de procesamiento pues tales adjuntos deben ser revisados en busca de virus.
-
Interfaz Web: En la actualidad los usuarios están utilizando cada vez más los servicios
ubicuos, por esto prefieren hacer uso del correo electrónico a través de una interfaz web
(webmail).
Propuesta
Esta sección describe la plataforma propuesta para ofrecer un servicio de correo electrónico
eficiente capaz de manejar grandes cantidades de usuarios, escalable y de alta disponibilidad.
Así mismo se muestran el conjunto de motivos que dan fundamento a la renovación de la plataforma de correo electrónico de la Universidad de Los Andes.
Justificación
A continuación se enumeran los distintos elementos que han generado una degradación considerable del servicio de correo electrónico:
-
Periodo de funcionamiento: Todo equipamiento de computación tiene una vida útil bajo
condiciones de uso intensivo. La plataforma actual se encuentra en funcionamiento continuo, sin interrupción programada alguna, desde el 2005.
-
Condiciones eléctricas: Las condiciones del suministro eléctrico han sido precarias en
los últimos 3 años. Los servidores de correo han enfrentado sobre carga de voltaje, cortes frecuentes de electricidad y actualmente, de manera regular se encuentran operando
a muy bajos niveles de voltaje (90 y 180 Volts).
-
Condiciones de ambiente: En el presente año, el precario servicio eléctrico afectó el sistema de enfriamiento de la sala donde se encuentran los servidores de correo en 3 ocasiones. En cada una de estas los servidores sufrieron recalentamiento extremo.
En el siguiente gráfico se compara las prestaciones del sistema de archivos que almacena los
buzones de correo vs. un sistema de archivos adecuado para esta función. Este último sistema de
archivos corresponde al nodo que será incorporado inicialmente para dar comienzo a la nueva
plataforma.
Se observa como el sistema de archivos que se encuentra actualmente en funcionamiento no
ofrece las prestaciones adecuadas para gestionar el alto volumen de archivos que representan
los mensajes de correo. Para las operaciones de escritura de archivos mayores de 2 MB el rendimiento cae significativamente.
Arquitectura propuesta
El esquema de la figura Error: No se encuentra la fuente de referencia muestra la arquitectura
de hardware planteada donde cada uno de los elementos del servicio se implanta utilizando un
cluster para tener redundancia.
Sistema de recepción y envío (MTA)
Como primera capa de gestión de correo se tiene un conjunto de servidores (Cluster A) que reciben y envían correo. Aquí se aplican métodos livianos de filtrado. Puede representar también
una primera barrera de defensa en contra de posibles ataques al servicio.
Servicio de Autenticación
Un conjunto de máquinas (Cluster B) tendrá las cuentas de los usuarios y toda su información
básica. Estos ofrecerán el servicio de validación a los otros clusters.
Sistema Anti Virus y Anti Spam
Un conjunto de servidores (Cluster C) conforman el servicio de verificación de virus y spam dentro de cada mensaje. La ventaja de esta implantación es que los servicios utilizados directamente por los usuarios no presentan degradación por el alto consumo de recursos de este proceso.
Sistema de Almacenamiento y MUA
El sistema de archivos utilizado para guardar los buzones debe ser lo suficientemente rápido
para responder a las ingentes cantidades de escrituras y lecturas realizadas por los distintos
elementos que conforman el servicio. Se recomienda que los buzones estén lo más cerca posible
al webmail para mantener un buen nivel de prestaciones.
Por otro lado, se recomienda distribuir los buzones para evitar sistemas de archivos de gran
tamaño, pues el tiempo para su mantenimiento, respaldo y recuperación se incrementa considerablemente. Así mismo, la falla de un sistema de archivos afectaría sólo a un grupo de usuarios.
Por todo esto, se plantea un cluster de servidores (Cluster D) que almacenen los buzones de forma distribuida y que a la vez ofrezca el servicio MUA mediante una aplicación webmail.
Para contar con tolerancia a fallas, se recomienda tener un servidor con características similares que tenga una copia de todos los buzones actualizada para que entre en funcionamiento en
caso de ocurrir una falla en alguno de los servidores activos.
Sistema MDA
Finalmente, un conjunto de servidores (Cluster E) que proporcionan los servicios de descarga de
mensajes (POP, IMAP) hacia los programas de gestión de mensajes de los usuarios.
Plan de Contingencia
La plataforma actual de correo electrónico presenta una degradación considerable debido a los
años de servicio en funcionamiento (desde el 2005) lo que ha provocado marcados niveles de
obsolescencia y deterioro natural. Por esto, se plantea un conjunto de tareas que permitirán dar
inicio a la implantación de la plataforma propuesta a través de la incorporación gradual de los
elementos del nuevo servicio, y al mismo tiempo tener un nivel de prestación aceptable. La siguiente figura muestra un esquema que ilustra este plan de contingencia.
El “Cluster Actual” está conformado por 8 servidores que realizan todas las funciones del servicio: Almacenamiento de buzones, MTA, MDA, MSA, MUA y Listas. Se instalará un servidor nuevo que funciona como MUA y almacenamiento local de buzones. Con esto se pretende que los
usuarios puedan gestionar sus buzones: sin notar la degradación que implica el procesamiento
de virus, spam y listas y con buzones que estén lo más cercano posible al webmail.
Se realizaron pruebas a la máquina que ejercerá estas funciones para determinar sus capacidades y verificar que atenderá a los usuarios sin presentar demoras en el servicio. Para ello se
utilizaron dos benchmarks: autobench4 y postmark5. El primero mide las prestaciones de un servidor web automatizando su proceso de evaluación con el benchmark httperf y el segundo fue
diseñado para medir el comportamiento de un sistema con altos niveles de operaciones de entrada/salida (I/O) con archivos de poco tamaño, como es característicos en los ambientes de correo
electrónico.
4
http://www.hpl.hp.com/research/linux/httperf/
5
http://www.freshports.org/benchmarks/postmark/
El objetivo de aplicar estas dos pruebas es determinar el nivel de degradación, del servicio de
webmail propuesto, producido por una intensiva carga de operaciones de entrada/salida (I/O).
En este sentido se realizaron 3 pruebas sobre un ambiente idéntico al que implementará la solución que representa el inicio de la implantación propuesta:
-
Medir el servidor web sin ocupación.
-
Medir el servidor web con un nivel alto de operaciones I/O locales.
-
Medir el servidor web con un nivel alto de operaciones I/O remotas.
El nodo que se agregará inicialmente es un Servidor SUN Fire x4150 con 2 procesadores Intel
Xeon quad-core E5440 @ 2.83GHz y 16 Gbytes de memoria RAM. Sistema operativo Linux Gentoo y kernel vanilla 2.6.34-r1 y con sistema de archivos ext4 montado sobre un volumen lógico
compuesto por siete (8) discos SAS, cada uno de ellos de 2.5", 146GB de capacidad y 10.000
RPM. La capacidad efectiva de almacenamiento de ese arreglo es de 985GB, pudiendo almacenar hasta 65.536.000 archivos.
El siguiente gráfico muestra los resultados obtenidos con autobench para los tres ambientes de
prueba. En cada una de ellas se realizaron 5 mil conexiones. Para cada conexión se hizo un conjunto de solicitudes comenzando en 20 solicitudes por segundo, con incrementos de 20, hasta 200
solicitudes por segundo.
Como se puede observar no hubo variación en el rendimiento del servidor web en términos de
número de respuestas por número de solicitudes. Es decir, se respondieron todas las solicitudes
a pesar de encontrarse cargado en las 2 últimas pruebas.
Las pruebas de rendimiento del sistema de entrada/salida consistió en la ejecución en paralelo
de 8 procesos del benchmark postmark. Cada instancia del benchmark realiza las siguientes operaciones:
-
La creación de 2.500 archivos entre 500 bytes y 6 Mbytes
-
La ejecución de 1.2500 transacciones (Read, Append, Create, Delete) sobre esos 2.500
archivos.
Es decir, en su conjunto, la prueba creaba 20.000 archivos y realizaba 100.000 transacciones
sobre ellos. El siguiente cuadro muestra los resultados obtenidos con postmark en el segundo
ambiente de prueba (operaciones de I/O locales).
Proceso
1
2
3
4
5
6
7
8
Tiempo
total (seg)
3692
3798
3844
3846
3853
3845
3840
3792
Tiempo en transacciones (seg)
2788
2711
2759
2764
2774
2767
2764
2718
Megabytes
Leídos/seg
2.94
2.94
2.92
2.92
2.85
2.83
2.95
2.91
Megabytes
Escritos/seg
5.68
5.46
5.39
5.51
5.37
5.38
5.45
5.47
Tomando el proceso con el peor tiempo total de ejecución (proceso 5) podemos afirmar, a grosso
modo, que los ochos procesos en su conjunto, tardaron 1 hora, 4 minutos y 13 segundos en crear
20.000 archivos sobre un sistema de archivo ext4 local y realizar 100.000 transacciones sobre
ellos. La tasa de creación de los 20.000 archivos (entre 512 bytes y 6 megabytes), sin incluir los
creados en transacciones, fue de 18 por segundo y los megabytes leídos y escritos por segundo
fueron 22,8 y 42,96 respectivamente.
Para el tercer ambiente de prueba (operaciones de I/O remotas), se configuraron dos equipos, de
prestaciones similares al Sun Fire x4150 donde se implementará la solución temporal, como
clientes nfs versión 3. Con 1 megabyte como máxima cantidad de bytes que pueden recibirse por
petición cuando se lee data desde el servidor NFS y 1 megabyte como máxima cantidad de data
que el cliente NFS puede enviar por petición cuando se envía data para ser escrita en un archivo
sobre el servidor NFS. En cada cliente se crearon cuatro instancias del benchmark postmark fue
similar a la empleada en el segundo ambiente de prueba (operaciones de I/O locales).
El siguiente cuadro muestra los resultados obtenidos con las 8 instancias de postmark en el tercer ambiente de prueba (operaciones de I/O remotas).
Cliente
nfs Nro.
Proceso
Nro.
Tiempo
total (seg)
1
1
1
2
4305
4265
Tiempo en
transacciones
(seg)
2892
2837
Megabytes
Leídos/seg
Megabytes
Escritos/seg
2.52
2.61
4.87
4.86
1
1
2
2
2
2
3
4
1
2
3
4
4285
4082
4425
4424
4410
4420
2861
2663
2952
2933
2906
2940
2.62
3.97
2.48
2.46
2.57
2.49
4.83
4.80
4.67
4.67
4.75
4.70
De manera análoga a como fue realizado con la evaluación del segundo ambiente de pruebas
(operaciones de I/O locales), se tomó el proceso con el peor tiempo total de ejecución (cliente nfs
número, 2 proceso 1) para poder afirmar, grosso modo, que los ochos procesos en su conjunto,
tardaron 1 hora, 13 minutos y 45 segundos en crear 20.000 archivos sobre un sistema de archivo
ext4 remoto a través de nfs y realizar 100.000 transacciones sobre ellos. La tasa de creación de
los 20.000 archivos (entre 512 bytes y 6 megabytes), sin incluir los creados en transacciones, fue
de 13 por segundo y los megabytes leídos y escritos por segundo fueron 19,84 y 37,36 respectivamente.
Durante la ejecución de las pruebas de I/O intensivo (local y remoto) se midió el uso de recursos
para observar el consumo de estos. Para ambas pruebas el comportamiento fue similar: procesadores desocupados o esperando la finalización de operaciones de I/O. En el siguiente gráfico
se ilustra cómo fue ese comportamiento.
Recomendaciones
Luego de observar las pruebas realizadas sobre el primero de los elementos de la arquitectura
diseñada que se plantea en este documento se recomienda:
1. Agregar un servidor que realice las siguientes funciones: Almacenamiento de los buzones
de correo electrónico y Webmail.
2. Iniciar de inmediato a la instalación y configuración de la plataforma propuesta en aras
de ofrecer a los usuarios un servicio de correo electrónico de calidad. Entre otras razones obvias, esta recomendación obedece además al hecho de que al estar instalado un
sólo servidor como almacenamiento de los buzones de correo en el Plan de contingencia,
se corre el riesgo de una suspensión total del servicio si esta máquina falla.
Además de las medidas técnicas, urge implementar medidas orientadas a lograr una mayor conciencia de uso racional del servicio por parte de la comunidad de manera de resguardar en lo
posible cualquier mejora técnica que se implemente, de lo contrario, cualquier cambio o inversión de esfuerzos y recursos tendrá una expectativa de vida muy corta. En tal sentido, se recomienda implementar las siguientes medidas:
1. Lograr en muy corto plazo la aprobación por parte del Consejo Universitario del conjunto de normas y reglamentos relacionados con el buen uso y aprovechamiento de los distintos recursos de red, haciendo énfasis en este momento con lo que tiene que ver con el
servicio de correo electrónico y listas de distribución.
2. Iniciar una campaña informativa agresiva a través de distintos medios, solicitando el
apoyo y colaboración de todos los usuarios del servicio en procura de:
- No hacer múltiples envíos del mismo mensaje,
- No enviar el mismo mensaje a varias listas,
- No enviar a las listas mensajes de más de 30 KB de tamaño,
- No enviar a las listas mensajes con archivos anexos, en su lugar, los archivos deben ser
colocados en un sitio web y en el cuerpo del correo se indica el enlace o dirección URL
a estos. También puede colocar toda la información en forma de texto en el cuerpo del
mensaje (para más información acerca de las políticas de uso de lista por favor visite
www.cca.ula.ve/documentos/Politicas_Uso_listas_correoinstitucionales_Marzo09.pdf),
- En la medida de las posibilidades utilizar un manejador de correo como Thunderbird,
Mozilla, Netscape, Opera, Eudora, Outlook, Pegasus, SeaMonkey, entre otros (para detalles
de
configuración,
por
www.atencion.ula.ve/correo/manuales_conf.php),
favor
diríjase
a:
- Mantener los buzones de correo lo más desocupados posible, manteniendo solo lo estrictamente necesario. Una medida que puede ayudar a conseguir esto es utilizar la
herramienta “Archive” del webmail que permite, antes de borra los mensajes, guardarlos o respaldarlos creando una copia de los mensajes seleccionados como un archivo en
el disco duro de la máquina del usuario y se podrá recuperar y leer cuando quiera. Esta
herramienta se encuentra ubicada en la parte inferior derecha de la ventana del webmail, justo debajo del listado de correos.
Descargar