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.
