Componente de envio de e-mail

Vamos iniciar esta seção relembrando alguns conceitos sobre o funcionamento do SMTP7 _{e explicar a infraestrutura de e-mail utilizada pela Arquitetura SIG. A especificação}

do SMTP permite que dentro de um mail object8 _{sejam definidos um ou mais destinatários}

para o e-mail que vai ser enviado. Esse comportamento do SMTP foi retratado na listagem 3.1da seção 3.1.3 Funcionamento do SMTP quando foram definidos três RCPT TO, ou seja, três pessoas distintas irão receber o mesmo e-mail.

A Arquitetura SIG quando precisa enviar um e-mail para mais de um destinatário usa esse recurso STMP. A vantagem da utilização desta técnica é a economia de dados trafegados entre o servidor de e-mail e o sistema que usa a Arquitetura SIG, uma vez que ele manda apenas uma mensagem com N destinatários, no lugar de mandar N mensagens cada uma com um destinatário diferente.

Quando a infraestrutura de servidores de e-mail possui apenas um servidor de e-mail, a solução de usar uma mensagem com vários destinatários é adequada. Mas quando na infraestrutura tem um balanceador de conexões (este é o caso da UFRN), essa combinação de balanceamento e múltiplos destinatários resulta em um balanceamento ineficiente. A infraestrutura da UFRN possui mais de um servidor de e-mail e o balanceamento entre eles é feito com Linux Virtual Server (LVS).

7 _{Os detalhes sobre o funcionamento do SMTP foram abordado no Capitulo 3na seção3.1.3 Funciona-} mento do SMTP.

64 Capítulo 4. Hermod - Uma plataforma para serviços de e-mail

Figura 16 – Balanceamento por LVS utilizado pela Arquitetura SIG

Antes de falar sobre como o problema é gerado, é preciso entender como funciona o balanceamento por LVS e para isso vamos exemplificar seu funcionamento usando a figura16. Esta tecnologia de balanceamento realiza a distribuição de carga fazendo um

round-robin baseado na quantidade de conexões recebidas, então se nove conexões são

realizadas pelas instâncias 1 e instância 2 do SIGAA, cada servidor de e-mail vai receber três conexões.

Vamos exemplificar como o problema é gerado através da figura 16. Supondo que a instância 1 do SIGAA realiza uma conexão com o Balanceador por LVS e este por sua vez distribui a conexão para o Servidor de e-mail 1. Após a realização da conexão, a

instância 1 do SIGAA envia um mail object com mil destinatários. O Servidor de e-mail 1 vai trabalhar sozinho para despachar as mil mensagens de e-mails, enquanto os outros

servidores de e-mail estão ociosos.

Essa má distribuição acontece porque o balanceamento não é feito pela quantidade de destinatários, o LVS faz o balanceamento apenas de conexões já que ele opera na

4.2. Primeiro protótipo 65 camada de transporte do modelo OSI. Ele não tem como inspecionar o conteúdo do mail

obejct que está sendo enviado para tomar as decisões de balanceamento. O balanceamento

correto para que cada servidor de e-mail possua exatamente a mesma carga foi um dos objetivos durante a implementação deste componente.

Figura 17 – Diagrama de classes do balanceador implementado no Hermod

Pensando em resolver este problema implementamos no Componente de envio

de e-mail um balanceador de carga baseado na quantidade de e-mails total. Quando

um sistema cliente envia para o Hermod um mensagem com múltiplos destinatários, o componente fragmenta a mensagem original e cria um mail object para cada destinatário.

A figura 17 representa o diagrama de classes do balanceador desenvolvido neste componente. A interface BalancingAlgorithm permite que qualquer tipo de implementa- ção de balanceamento seja implementada sem que haja impacto no restante do projeto. A implementação padrão utilizado pelo Hermod é a classe RoundRobinServers que realiza o balanceamento através da técnica round-robin.

Este componente também tem a função de manter uma tabela com todos os servidores de e-mail. Manter essa tabela sempre consistente é importante para que o nosso balanceador consiga fazer uma distribuição correta. Manter esta tabela consistente não é trivial porque o Componente de elasticidade (mais detalhes na seção 4.2.2.5 Componente

66 Capítulo 4. Hermod - Uma plataforma para serviços de e-mail

de elasticidade) cria e destrói os servidores de e-mail dentro de nossa infraestrutura de acordo com algumas situações (estas situações são discutidos na seção4.2.2.5 Componente de elasticidade).

A figura 17 apresenta a entidade TableServers, cuja responsabilidade é manter a estrutura que armazena os servidores de e-mail. Fizemos uma implementação do pa- drão de projeto Observer então sempre que um servidor for adicionado ou removido, os interessados serão notificados. Os interessados em receber a notificação devem imple- mentar a interface ChangeServersListener e registrar-se através do método addListe-

ner(ChangeServersListener listener) presente em TableServers. O RoundRobinServers

por exemplo, é uma das entidades interessadas em receber qualquer alteração da tabela de servidores.

Eventualmente algum provedor de e-mail pode bloquear um de nossos servidores de e-mail por extrapolar algum sistema quota deles. O Componente de monitorar e-mail (mais detalhes na seção 4.2.2.4 Componente de monitorar e-mail) é o responsável por detectar o bloqueio e informar ao Componente de envio de e-mails que e-mails para aquele provedor não devem ser enviados através do servidor que sofreu o bloqueio.

Figura 18 – Diagrama de classes do modelo de restrição de servidores

4.2. Primeiro protótipo 67 é importante para nosso balanceador já que ele precisa usar essa informação durante o processo de decisão para qual servidor vai balancear. Por exemplo, caso o e-mail do destinatário pertença ao domínio gmail.com antes de decidir para qual servidor ele vai distribuir este e-mail, o balanceador vai verificar na tabela de restrição e descartar os servidores que possuem restrição para o gmail.com. Assim, o balanceador só realiza o

round-robin entre os servidores saudáveis.

Manter a tabela de restrições é responsabilidade do Componente de envio de e-mail. A figura 18 mostra o diagrama de classes referente a funcionalidade de restrição. A classe Restrictions é a entidade que armazena todas as restrições, portanto ela é vital para o bom funcionamento do nosso sistema de balanceamento.