Servidor de mail elástico em Cloud Computing

Transcrição

1 Servidor de mail elástico em Cloud Computing Paulo Abreu, Vitor Castro Mestrado de Informática Universidade do Minho Braga, Portugal Resumo O correio electrónico é, neste momento, o serviço mais utilizado na internet, sendo uma das maiores invenções das tecnologias de informação, desde o aparecimento da internet. Com a nova era das infraestruturas distribuídas, as Clouds, vão aparecendo cada vez mais serviços distribuídos que oferecem melhor performance e estabilidade. Pretende-se fazer uma investigação sobre o funcionamento de um serviço de mail distribuído tirando proveito de uma plataforma construída com recurso ao Hadoop. O estudo apresenta resultados interessantes que podem servir como ponto de partida para investigações futuras, na área de serviços distribuídos. Palavras chave: Cloud Computing, Distributed Filesystem, Map Reduce, Postfix, Hadoop. 1 Introdução O correio electrónico é, neste momento, o serviço mais utilizado na internet, sendo uma das maiores invenções das tecnologias de informação, desde o aparecimento da Internet. Como quase todas as invenções, o surge de uma necessidade, a necessidade de comunicar entre entidades ligadas através de uma rede. Um servidor de , como o Postfix, funciona em cima de um sistema operativo e que, através do protocolo SMTP, permite que sejam feitos envios e entregas de mensagens, através de uma rede que pode ter dimensões escaláveis até à dimensão da internet. Um servidor de mail está sujeito a grandes cargas, provocadas por s fidedignos ou por spam, o que afecta a performance do serviço e por consequência, afecta o funcionamento das empresas, dos serviços, em suma, do utilizador. Com o aparecimento do conceito de Cloud, surge um novo conceito de serviços e infraestruturas, que permitem obter melhor perfomance, mais segurança e acima de tudo, quase dissipa os limites dos serviços e torna-os escaláveis. Os servidores de mail não são excepção, o que nos permite escalar o serviço de mail e desta forma aumentar a sua performance, bem como garantir mais segurança dos dados à custa da dispersão de informação. No trabalho efectuado, foi construída uma Cloud, com recurso ao Hadoop, o que nos permitiu construir um serviço de mail distribuído, usando para o efeito o Postfix. 1.1 Objectivo O objectivo deste trabalho é criar uma Cloud onde possamos ter um serviço de mail elástico que funciona de forma distribuída, sobre uma plataforma de máquinas onde a informação é armazenada e processada paralelamente. Desta forma, há vários aspectos que podem ser estudados como a performance dos servidores de mail elásticos, o funcionamento distribuído da plataforma, bem como os conceitos de escalabilidade, eficiência e confiabilidade. Particularmente: Pretende-se verificar que numa Cloud com Hadoop é feito o processamento e armazenamento distribuído e desta forma, é possível construir um modelo em que os serviços de mail herdam esta propriedade. Espera-se obter uma performance superior do serviço de mail numa arquitectura distribuída, em comparação com um servidor de mail normal.

2 2 1.2 Arquitectura A arquitectura da Cloud implementada tem por base o funcionamento do Hadoop. Esta pode ser arquitectada de diferentes formas, tendo na sua constituição um conjunto de Datanodes e um Namenode, os slaves e o master, respectivamente. No caso em estudo, foi criada uma infraestrutura com um Namenode e quatro Datanodes. Embora o Hadoop tenha algumas limitações, como será referido, é na sua generalidade uma boa forma de se poder estudar uma plataforma distribuída, contudo, carece de melhoramentos que dada a sua natureza, podem ser feitos pelos próprios investigadores e enviados para a equipa que mantém e dá continuidade ao projecto. 1.3 Aplicabilidade Numa visão mais geral, o trabalho elaborado consiste em criar um serviço de mail de elevada disponibilidade, que garanta segurança da informação e com indíces elevados de performance. Por todas as características apresentadas, a ideia e o trabalho realizado podiam passar para soluções de carácter empresarial, desde que fossem feitas melhorias no filesystem distribuído e algumas optimizações no servidor de mail. Certamente que algumas empresas que têm constantemente problemas com os serviços de mail, desde perdas de dados, excesso de mensagens por processar ou até efectuar alterações no serviço sem downtime, optariam por uma solução que lhes permitisse resolver esses problemas. Nas secções que se seguem é exposta a abordagem a este tema, onde se pode encontrar informação relativa às ferramentas utilizadas, arquitectura da infraestrutura, resultados e a respectiva discussão dos mesmos. O documento termina com a conclusão que retrata uma análise geral do projecto. 2 Abordagem 2.1 Cloud The cloud is a virtualization of resources that maintains and manages itself. [11] - Kevin Hartig, Sun Microsystems. O termo de Cloud surge da utilização da imagem de nuvem para representar redes, mais precisamente grandes redes como a internet. Contudo, neste momento o termo Cloud já não é usado para representar um grande conjunto de ligações, routers, switchs e servidores, mas sim para representar serviços. Com o aparecimento do conceito de Cloud, surge uma nova era na informática que vai certamente revolucionar os conceitos de infraestruturas e serviços. Desta forma o utlizador perde a noção de tudo o que está por trás de um serviço, ou até mesmo a forma como este funciona, focando o seu interesse na performance, segurança e na disponibilidade do serviço. Vive-se uma nova era onde ninguém quer ficar atrasado na corrida e a avaliar pelos investimentos recentes de grandes empresas como a Yahoo!, Google, IBM, DELL, HP e muitas outras, pode-se facilmente concluir que é uma onda que quem não a apanhar, será certamente arrastado com ela ou atirado para fora - Ou as empresas adoptam a Cloud ou ficam obsoletas. [1] A Google, amazon e outras grandes multinacionais, têm espalhado por todo o mundo, vários centros de dados o que lhes permite criar uma enorme Cloud à escala mundial. Já pensaram quantas vezes não tinham acesso ao Gmail por este estar indisponível, ou quantas vezes não conseguiram fazer um pesquisa no Google porque o motor debusca não respondia? Porém, não é inimaginável que a Google tenha avarias nos seus centros de dados como acontece em todos os outros, contudo,

3 3 usufrui de um novo modelo de arquitectura, aliado a outras medidas, que permite dissipar os problemas e manter a elevada disponibilidade dos serviços, a Cloud. Claro que o termo Cloud pode levar a conclusões erradas, pois nem todas têm o mesmo funcionamento, nem a mesma arquitectura. É portanto um termo que nos remete para um plano de abstração, onde se retrata uma infraestrutura, com uma dada arquitectura e um conjunto de serviços que funcionam em cima de uma camada aplicacional onde se aglutinam os vários componentes da infraestrutura, como se fossem um todo. 2.2 Hadoop O Hadoop[3] surge em 2004, por Doug Cutting & Mike Cafarella. Nasce assim uma plataforma de software que usa map reduce, retratado na figura 1, num sistema de ficheiros distribuído. Este modelo define-se pelos princípios de escalabilidade, eficiência, confiabilidade e economia. Figura 1. Map Reduce software framework É escalável porque permite que o número de nodos seja aumentado ou diminuído sem que isto provoque uma quebra no funcionamento do serviço, o que também permite guardar e processar pequenas ou grandes quantidades de informação, dependendo do número de nodos que são usados. A efeciência vem do modo de funcionamento do Hadoop, que distribuí a informação pelos nodos e desta forma faz um processamento paralelo, tornando-o mais rápido que um serviço que processa toda a informação num só ponto, como se pode verificar através dos resultados obtidos pelas benchmarks referidas na wiki do Hadoop [8,9]. Esta forma de funcionamento permite economia de custos e maximização de recursos, pois a informação ao ser processada e armazenada em computadores que estejam livres para o fazer, permite utilizar melhor os recursos disponiveís e construir um centro de processamento de dados que pode ir desde algumas unidades até centenas de unidades de processamento. Por fim, o Hadoop mantém mais que uma cópia da informação, podendo até replicar a informação por todos os nós da Cloud, aumentando a confiabilidadedo serviço e diminuído a probalidade de perda da informação devido a falhas. O projecto Hadoop continua em evolução, quer no sentido de resolver algumas limitações que ainda tem, quer para explorar novas formas de o aplicar nas mais variadas temáticas, como por exemplo o HBase[4]. Como foi referido, o Hadoop ainda tem algumas limitações, das quais destacamos os problemas de processamento de symbolic links, o Job Tracker, ou Namenode, é um SPOF(Single Point of Failure), ou seja, em caso de falha deste nó, os pedidos que já foram enviados para a Cloud não são respondidos e até que seja nomeado um novo Job Tracker, não são processados mais pedidos. Existem vários projectos que utilizam o Hadoop, alguns na área de investigação e outros já em sistemas de produção, como podem verificar no conjunto de patrocinadores que são apresentados na wiki[7] do Hadoop.

4 4 2.3 Postfix O Postfix[12], definido como um MTA(Mail Transfer Agent) foi originalmente construído por Wietse Venema, sendo desde 1998 um software live que permite enviar e receber s de forma rápida, segura e eficaz. Surge nos centros de investigação da IBM, sendo inicialmente designado por Secure Mailer, aparecendo como uma evolução do Sendmail, mas com maior cuidado ao nível da segurança, performance, fiabilidade e flexibilidade, sendo estas as suas principais características. Um atravessa várias fases, nomeadamente a composição, envio, recepção e visualização, onde para o efeito, é utilizado o protocolo SMTP(Simple Media TransferProtocol). Parte deste processo é feito pelas aplicações normalmente designadas por MUA(Mail User Agent), como por exemplo o mutt, o Outlook Express e o Netscape Communicator, estando presentes na concepção do e na visualização, ou seja, os pontos de contacto com o utilizador comum. É precisamente no envio e recepção que o Postfix é utilizado, funcionamento como um estafeta que se encarrega de entregar as mensagens, o transporte, seguindo-se a recepção do , funcionando desta feita como MSA (Mail Submission Agent). Devido à sua natureza de software livre, é possível alterar a forma como este opera, podendo ser modelado mediante as nossas exigências, quer ao nível da configuração do serviço, quer editando a source e alterando o modo como são feitas as operações que garantem o funcionamento do serviço. Desta forma podemos modelar o software e preencher certos problemas que não resultam ou não são resolvidos pela camada aplicacional que rodeia o funcionamento deste serviço. O Postfix é configurável ao ponto de evitar que o sistema operativo entre num estado de degradação funcional e termine num crash por falta de memória, devido ao excesso de carga ou a outras variáveis que influenciam a sua estabilidade. Postfix has been designed from the beginning to handle unexpected hardware or software problems gracefully. [2] 2.4 Configuração do Hadoop Na configuração do Hadoop é necessário indicar o endereço do Master e uma lista de endereços de todos os Slaves, através dos ficheiros de configuração HADOOP HOME/conf/master e HA- DOOP HOME/conf/slaves. Para além destas configurações, é no ficheiro HADOOP HOME/conf/hadoop-site.xml onde se inserem todas as outras configurações necessárias, tais como: Nome do filesystem, indicado o endereço/porta para o master; Replicação do filesystem com o número de máquinas replicadas Localização do filesystem Map Reduce Job Tracker com o endereço/porta Para as restantes ferramentas foi realizada uma instalação default. 2.5 Estrutura da Cloud A Cloud baseia-se numa estrutura de master e slaves de forma a garantir que os dados do sistema de ficheiros são distribuidos pelos slaves e coordenados pelo master. De forma a tentar optimizar o processamento de mails no Postfix, foi instalado um servidor de mail em cada slave para permitir uma distribuição dos pedidos por cada Datanode. A máquina que contém o master do Hadoop, é também utilizada para fazer a distribuição de mails através da ferramenta Balance que usa o algoritmo de Round Robin. Assim o cliente de mail desconhece a existência de uma Cloud ou mesmo que os pedidos lançados por ele serão tratados por máquinas diferentes.

5 5 Figura 2. Arquitectura da Cloud 2.6 Fuse DFS É utilizado para montar um sistema de ficheiros virtual e intercepta as operações referentes a esse sistema de ficheiros, propagando as operações no Hadoop, onde se encontra a informação e representação do sistema de ficheiros. Assim, qualquer outro computador que se ligue a este sistema de ficheiros irá ver reflectidas todas as alterações realizadas pelos outros nós da estrutura distribuída. 2.7 Configuração do Postfix O funcionamento do Hadoop obriga que o postfix seja configurado com maildirs por ser criado um lock exclusivo aos ficheiros que são replicados para os Datanodes da Cloud. Este lock faz com que o não seja processado correctamente, fazendo com que demore mais tempo a estar disponível para leitura e por outro lado introduz latência no processo. Usando maildirs, ao testar o funcionamento do servidor de mail com o Hadoop, verificamos que sempre que um era recebido pelo serviço, ocorriam erros pelo facto do fuse usado pelo Hadoop, o Fuse DFS, não suportar symbolic lynks. Desta feita, tivemos que editar a source do Postfix e alterar o seu funcionamento normal. O Postfix com funcionamento em maildirs, cria três directorias, nomeadamente a new, cur e tmp. Sempre que um é recebido pelo servidor de mail, este passa pela directoria tmp, é criado um symbolic link para a directoria new e só depois é transferido para a directoria new, sendo removida a entrada na tmp, bem como o symbolic lynk. De forma a contornar a limitação do Fuse DFS, alteramos o processo referido e em vez de criar symbolic lynks, o passa directamente da directoria tmp para a directoria new, sem criação do link. Com este modus operandis, as mensagens são enviadas e recebidas correctamente, ao mesmo tempo que deixam de haver erros na estrutura distribuída. 2.8 Envio de s O envio de s foi feito através de uma script que permite enviar mails em blocos ou de forma contínua. A script de envio é chamada como um comando de shell, ficando a correr até que, por

6 6 intervenção de um operador, esta seja terminada. A forma de execução e os parâmetros passados são os mesmos para todos os testes realizados, de forma a ter um padrão de envio de s, para não provocar desvios nos resultados. 2.9 Recolha de métricas Para melhor compreensão dos testes realizados, definiram-se três modelos, o Modelo N, o Modelo D1 e o Modelo D2. O Modelo N consiste no funcionamento normal de um servidor de mail, sem que este faça parte de um modelo distribuído. Quanto ao Modelo D1, é a representação da arquitectura distribuída concebida com o Hadoop, onde cada entidade da infraestrutura tem um servidor de mail Postfix com as mesmas configurações que foram colocadas no Modelo N. Por fim, o Modelo D2 consiste em ter uma arquitectura como no Modelo D1, contudo apenas uma máquina funciona como servidor de mail, enquanto que as outras máquinas são apenas Datanodes, que embora tenham a mesma informação, são funcionalmente distintas da primeira máquina descrita. Para fazer a análise dos dados, foram recolhidas métricas através de ficheiros de log do Postfix. Para tal, foi necessário criar scripts de recolha de dados, permitindo saber quantos mails foram processados em determinado período de tempo. Estas scripts extraem, para ficheiros de texto, a informação que representa a entrada do no servidor, a hora correspondente e o identificador de cada . 3 Avaliação 3.1 Hardware e Software O estudo realizado carece de uma infraestrura que nos permita aproximar o mais possível de um comportamento real, motivo pelo qual foram utilizadas máquinas virtuais que representam as entidades constituintes da Cloud. Embora inicialmente a infraestrutura tenha sido criada em máquinas bastante rudimentares, foi possível migrar as máquinas virtuais para algumas máquinas gentilmente cedidas pelo grupo de sistemas distribuídos. Desta forma, tornou-se possível a realização de testes em que o estrangulamento da performance não fosse a capacidade computacional, mas sim as limitações impostas pelas aplicações ou pelo próprio modelo distribuído. Uma Cloud é constituída por uma camada aplicacional e uma camada física que a suporta. Na camada física, definiu-se uma implementação base da infraestrutura com cinco computadores iguais ligados numa LAN. Cada máquina tem as seguintes características: Hardware: Processador: Intel Core 2 Duo 2.13Ghz Memória: 1Gb RAM Disco: Seagate, 8Mb Cache, 7200RPM Rede: Gigabit (GbE) Software: Sistema Operativo: Unbuntu Kernel VMWare Server A correr uma imagem com o Sistema Operativo: CentOS 4.7 / 750Mb de RAM Todas as configurações adicionais para o funcionamento do projecto, foram implementadas nas imagens de VMWare, o que permitiu tornar a infraestrutura facilmente portável. Na camada aplicacional, foram instaladas e configuradas, uniformemente em todas máquinas, as aplicações que se seguem:

7 7 Hadoop [3] Fuse DFS (incluído no Hadoop) Postfix [12] Balance 3.42 [10] 3.2 Resultados Como referido, foram efectuados três testes em condições exactamente iguais, contudo com finalidades diferentes. O primeiro teste é feito na arquitectura distribuída Hadoop, sobre as condições anteriormente descritas. Ao fim do período temporal estabelecido, é feita a recolha de informação através da análise dos logs aplicacionais. Da análise dos logs, é apurada a informação que nos permite construir uma representação gráfica do desempenho obtido, tal como se pode verificar na Figura 3. Na Figura 3, o número de mails processados é apresentado no eixo vertical em função da escala Figura 3. Total de mails processados por cada máquina temporal do teste. Na representação anterior, pode-se verificar que existem quatro séries, onde cada uma retrata o comportamento de um Datanode da Cloud. O número de mails processados são 4025 na Maq.1, 4111 na Maq.2, 4365 na Maq.3 e por fim, 4621 na Maq.4, sendo esta uma amostra recolhida no espaço de vinte minutos. No segundo teste, sob as mesmas condições que o primeiro teste efectuado, é usado um servidor de mail numa das máquinas da infraestrutura, com um funcionamento independente. Trata-se portanto de um servidor de mail normal, ou seja, sem arquitectura distribuída. Na Figura 4, pode-se verificar que na série Modelo N, é apresentado o comportamento do Postfix sem arquitectura distribuída, sendo a amostra recolhida nas mesmas condições que o teste anterior. A composição que se segue, pretende estabelecer uma comparação entre o Modelo N e os Modelos D1 e D2, sendo o Modelo D1 o somatório de mails processados pelos vários Datanodes. Os totais obtidos são mails processados para o Modelo N, para o Modelo D1 e para o Modelo D2.

8 8 Figura 4. Modelo N vs Modelo D1 e D2 3.3 Discussão No gráfico do Modelo D1, o primeiro teste, mostra o comportamento individual de cada entidade da arquitectura distribuída. Através de uma análise da Figura 3, verifica-se que apesar de numa fase inicial ter um crescimento acentuado e regular, revela algumas quebras no processamento de s. Estas quebras podem resultar das variações na carga computacional, sendo esta induzida pelo Hadoop em cada máquina da infraestrutura distribuída, bem como pela carga que advém dos Datanodes serem simultâneamente servidores de mail. Os servidores de mail do Modelo D1 processaram quantidades de mail ligeiramente diferentes, o que pode estar relacionado com o comportamento referido no ponto anterior. O somatório dos s processados por todos os servidores atinge valores um pouco aquém do esperado, sendo isto discutido nos pontos que se seguem. O Modelo D2, com um Postfix e o mesmo número de Datanodes que o Modelo D1, apresentou resultados muito inferiores a esse modelo. Este comportamento era esperado, pois com o Modelo D1 a carga computacional é dividida por várias máquinas enquanto que no Modelo D2 todos os s são processados em apenas um servidor e o resto da infraestrutura apenas armazena a informação. Desta forma, consegue-se atingir um dos objectivos propostos. Quanto ao Modelo N, apresentou óptimos resultados de performance, chegando mesmo a superar os outros modelos propostos. Porém, este resultado vem contra o esperado. Pretendia-se provar que um modelo distribuído quando sujeito a testes de carga, responderia com melhor performance que um servidor de mail normal, contudo isto não foi alcançado. Pela análise da Figura 4, constata-se que, em termos globais, o Modelo N tem melhor comportamento que o Modelo D1, quando submetido a cargas iguais. Uma limitação que prejudica os modelos distribuídos D1 e D2, é o funcionamento do Fuse DFS, que devido a falhas provoca problemas não só de desempenho como funcionais, nomeadamente a já retratada falha[5] no tratamento de symbolic links, bem com uma falha[6] que condiciona a performance do Hadoop. A segunda falha apresentada provoca um grande impacto negativo no processamento de grandes quantidades de ficheiros, o que se retrata nos testes efectuados para o Modelo D1. Como se pode verificar na Figura 4, quando se aproxima dos dez mil mails processados, há uma quebra significativa na performance, agravando-se a partir dos quinze minutos do teste. Quando o teste se aproxima dos trinta mil mails processados, o Fuse deixa de responder e o modelo distribuído torna-se impraticável. Outra razão pela qual os modelos D1 e D2 apresentaram resultados aquém

9 9 do esperado, prende-se com o facto de os servidores de mail não serem disjuntos das entidades que representam os Datanodes. Esta configuração induz carga suplementar que prejudica o desempenho do serviço de mail e simultâneamente o desempenho global da Cloud. Como sugestão para dar continuidade a esta investigação, sugere-se que seja desenvolvida uma aplicação middleware que permita substituir o Fuse, de forma a estabelecer uma comunicação directa entre a API do Hadoop e Postfix. 4 Conclusão Na conjugação do Hadoop com o Postfix, nem sempre foi fácil a integração de um serviço de mail numa plataforma distribuída, dadas as limitações que há de parte a parte. Contudo, conseguimos provar que é possível ter uma camada aplicacional distribuída e funcional. Devido às limitações impostas, não é possível provar que o Postfix num modelo distribuído tem melhor performance que no seu funcionamento normal, porém, há benefícios claros em seguir um modelo distribuído, pois este permite replicação da informação e uma maior disponibilidade do serviço. Uma investigação posterior, executada nos mesmos módulos mas desta feita, com recurso a um midleware que permitisse substituir o Fuse-DFS, poderia fornecer resultados mais satisfatórios para uma solução como a do Modelo D1. 5 Agradecimentos Gostaria de agradecer ao professor José Orlando Pereira e ao professor António Luís Sousa, pela supervisão e disponibilização de uma infraestrutura de testes, extendendo estes agradecimentos ao grupo de sistemas distribuídos do departamento de informática, da Universidade do Minho. À Joana Guimarães e Andreia Castro, o nosso muito obrigado pelo apoio. Referências 1. N. Carr. Ou empresas adotam cloud ou ficam obsoletas K. D. Dent. Postfix - The definitive guide. O Reilly, A. S. Foundation. Hadoop A. S. Foundation. Hbase A. S. Foundation. Fuse-dfs should support symlinks A. S. Foundation. Fuse module chokes on directories with lots (10,000+ or so) files A. S. Foundation. Hadoop wiki A. S. Foundation. Hadoop wiki - data processing benchmarks A. S. Foundation. Hadoop wiki - hardware benchmarks I. S. GmbH. Balance K. Hartig. What is cloud computing? Postfix. Postfix web site de Janeiro de 2009