Na seção 3.1.5 Proteção contra SPAM deste capítulo falamos que existe a possi- bilidade de ocorrer um bloqueio temporário dos nossos servidores de e-mail. Esse é um problema que a UFRN enfrenta diariamente utilizando o módulo de envio da Arquitetura SIG. Quando ocorre um bloqueio na infraestrutura servidores de e-mail da UFRN pelo Hotmail, por exemplo, 30% (dado presente na figura 7) da comunicação institucional é afetada.
A forma que encontramos de tratar este problema foi criando servidores novos de e-mail em tempo de execução (com um novo endereço IP) na medida em que é detectado que ocorreu um bloqueio de servidor de e-mail. Para realizar essa tarefa existem dois tipos de tecnologias de virtualização de servidores que são comuns em ambientes de datacenter: a virtualização em nível de hardware (máquinas virtuais) e em nível de sistema operacional (containers).
A figura9 mostra lado a lado essas duas tecnologias e como podemos observar a virtualização no nível de hardware envolve a utilização de um hypervisor que virtualiza os recursos do servidor em várias máquinas virtuais (comumente chamadas por sua sigla em inglês, VM). Cada VM roda seu próprio sistema operacional com seus aplicativos de forma isolada. Em contraste, a virtualização no nível do sistema operacional encapsula processos do SO e suas dependências para criar containers, que são gerenciados coletivamente pelo
kernel do SO subjacente, ou seja, todos os containers usam o mesmo kernel compartilhado
(SHARMA et al., 2016).
3.3.1
Máquinas Virtuais
O objetivo desse modelo é compartilhar os recursos físicos entre vários ambientes isolados, sendo que cada um deles tem sob sua tutela uma máquina inteira, com memória, disco, processador, rede e outros periféricos, todos entregues via abstração de virtualização. É como se dentro de uma máquina física existissem máquinas menores e independentes entre sí. Cada máquina dessa tem seu próprio sistema operacional completo, que por sua vez interage com todos os hardwares virtuais que foi entregue pelo modelo de virtualização
3.3. Virtualização 49 Figura 9 – Comparação Máquina Virtual vs Docker Container
a nível de máquina.
Cada VM não executa apenas uma cópia completa de um sistema operacional, mas uma cópia virtual de todo o hardware que o sistema operacional precisa para ser executado. Naturalmente, tudo isso irá consumir bastante memória RAM e CPU.
O hypervisor também conhecido como virtual machine monitor (MMV-monitor de máquina virtual) é responsável por controlar o acesso dos sistemas operacionais hóspedes ao hardware, e proporcionar a cada máquina virtual a ilusão de que ela está sendo executada em um hardware específico, além de simular a execução das instruções requisitadas pelo sistema operacional (BUENO, 2009).
3.3.2
Container Docker
Esse modelo de virtualização está no nível de sistema operacional, ou seja, ao contrário da máquina virtual um container não tem visão de uma máquina inteira, ele é apenas um processo em execução em um kernel compartilhado entre todos os outros containers. Ele utiliza o namespace8 para prover o devido isolamento de memória RAM,
processamento, disco e acesso a rede, ou seja, mesmo compartilhando o mesmo kernel, este processo em execução tem a visão de estar usando um sistema operacional dedicado.
Existem diversas tecnologias que provêem a criação de containers, como por exemplo LXC, Systemd-nspawn, libvirt. Entretanto, são tecnologias de baixo nível ou com uma complexidade elevada para usar "pura". O Docker9surgiu como um facilitador nesse sentido.
Como a maioria dos bons projetos de código aberto, ele incorpora várias tecnologias Linux
8 http://man7.org/linux/man-pages/man7/namespaces.7.html 9 www.docker.com
50 Capítulo 3. Fundamentação Teórica
existentes, juntamente com novas funcionalidades; ele usa tecnologias já existentes como
union filesystems (geralmente AUFS 10) e containers. (FINK, 2014)
Outra novidade do Docker foi a criação do conceito de “imagens”, que grosseiramente podemos descrever que são definições estáticas de como os containers devem ser no momento da sua inicialização. São como fotografias de um ambiente. Uma vez instanciadas, colocadas em execução, elas assumem a função de containers, ou seja, saem da abstração de definição e se transformam em processos em execução, dentro de um contexto isolado, que enxergam um sistema operacional dedicado para si, mas na verdade compartilham o mesmo kernel.
3.3.3
Considerações
A virtualização tem um papel forte nesse projeto. Nosso planejamento é utilizar uma combinação de máquinas virtuais e containers docker para a criação dos servidores de e-mail. O modelo proposto para infraestrutura de servidores é ter uma quantidade pequena mas fixa de máquinas virtuais e uma quantidade variável de conteiners. A criação dos containers vai ser gerenciada por um componente do Hermod (descrito na seção 4.2.2.5 Componente de elasticidade), onde de acordo com a situação ele pode expandir a quantidade de servidores.
51
4 Hermod - Uma plataforma para serviços de
Este capítulo descreve a implementação do Hermod, uma plataforma desenvolvida com as propriedades de interoperabilidade, alta disponibilidade, tolerância a falhas e elasticidade. O objetivo do Hermod é abstrair serviços de e-mail, tais como envio e rastreio de mensagens enviadas, comportando-se como um middleware oferecendo esses serviços a outros sistemas independente de linguagem de programação.
No início deste trabalho, na seção 1.1, falamos sobre a motivação deste trabalho e no capítulo 2dedicamos um espaço inteiro para discutir os problemas da solução de envio da Arquitetura SIG. Estes dois pontos foram a base para a elaboração dos objetivos e a implementação da plataforma Hermod que será discutido neste capítulo.
4.1
Visão Geral
O Hermod é um middleware desenvolvido para abstrair a complexidade de criar e manter uma infraestrutura de servidores de e-mail e prover funcionalidades de alto nível para outros sistemas que necessitam de serviços de e-mail. A figura 10 apresenta uma visão geral sobre a forma como o Hermod se relaciona com outros sistemas clientes. Esta figura é dividida em três níveis, a primeira chamada de Sistemas externos são os sistemas clientes que enviam solicitações e recebem as respostas do Hermod oriundo dos serviços ofertados. O Hermod aparece no nível logo abaixo, chamado Middleware e centraliza todos os pedidos dos sistemas clientes e despacha os pedidos para o nível Infraestrutura. Dentro do nível de infraestrutura existem os servidores e-mail, a base de dados Elasticsearch e o RabbitMQ (um middleware orientado a mensagens).