Diferente das etapas anteriores do loop de controle, a fase de Execução pode ser executada fora da máquina onde a solução AdaptMCloud é implantada. Para evitar uma sobrecarga desnecessária, as 3 primeiras etapas do loop de controle foram projetadas e im- plementadas para funcionarem totalmente desacopladas da(s) aplicação(ões). A Figura 19 apresenta as principais classes envolvidas na fase de execução do loop de controle. A classe
ApplicationComposerNotifier é responsável por enviar uma requisição do tipo Rest (MAN-
DEL, 2008) encriptada, para um servidor (um Servlet Java por exemplo) que recebe como
parâmetro o artefato Reconfiguration Description. Para que isso seja possível, no momento da inicialização do loop de controle, é necessário informar o endereço completo para re- quisição e o token de acesso. Esse token de acesso é enviado a cada requisição feita pela classe ApplicationComposerNotifier para que o servidor representado pela classe Applica- tionSpecificRestServer possa realizar o processo de autenticação e receber a artefato para reconfiguração. Essa medida foi adotada para evitar que as aplicações fossem notificadas por terceiros e consequentemente ficassem susceptíveis a processos de reconfiguração não desejados. Essa classe pode ser implementada como um Servlet ou mesmo um Web Ser- vice, desde que seja capaz de receber requisições Rest no formato especificado. Com o artefato, a classe ReconfigurationManagerHandler é instanciada de acordo com a técnica de programação utilizada pela aplicação, para que o processo de reconfiguração ocorra, do ponto de vista da aplicação. O Capítulo 6 apresenta o funcionamento das classes aqui apresentadas de forma detalhada e para cada técnica de programação utilizada.
3.4
Arquitetura de Implantação
A Figura 20 apresenta a arquitetura de implantação da solução AdaptMCloud de forma genérica, apresentando como a mesma se relaciona com as plataformas de nuvem públicas que são monitoradas e provêm serviços para as aplicações que estão susceptíveis ao processo de adaptação. O servidor AdaptMCloud contém a implementação do loop, assim como todos as dependências necessárias para sua execução. Para conferir flexibili- dade ao processo de adaptação, bem como evitar sobrecarga nos servidores nos quais as aplicações web são implantadas, a solução foi projetada para funcionar de forma remota, sem a necessidade de estar no mesmo espaço da aplicação. Uma única instância da solução AdaptMCloud pode monitorar diversos serviços e plataformas de nuvem (Plataforma A e Plataforma B), assim como gerenciar múltiplas aplicações ao mesmo tempo (App Web
Figura 19: Classes envolvidas no processo de reconfiguração, na fase de execução X e App Web Y ), conforme apresentado na figura. Na seção seguinte apresentamos um exemplo de cenário de implantação da solução, que foi usado ao longo desse trabalho.
3.5
Exemplo de Implantação
A Figura 21 ilustra o cenário de como a solução AdaptMCloud e de que forma ela se relaciona com as plataformas/serviços de nuvens e as aplicações multi-cloud gerenciadas pela mesma. Para efeitos de simplificação, omitimos as ligações das aplicações com as plataformas de nuvens e serviços, uma vez que essas ligações podem ser reconfiguradas em tempo de execução, como ilustrou a Figura 2 no Capítulo 1 e os modelos de features estendidos apresentados na Seção 3.2.
A solução AdaptMCloud é composta por vários componentes e softwares de terceiros, conforme descrito nas seções anteriores, o que demanda a organização de diversas depen- dências, sejam de software ou de bibliotecas. Considerando que o trabalho de configuração da solução envolve uma série de passos e configurações de baixo nível, disponibilizamos
a solução através da plataforma Docker (MERKEL, 2014), que permite a configuração de
aplicações e suas dependências dentro de containers, que são migráveis entre máquinas físicas ou virtuais, sem a necessidade de realizar o processo de configuração/implantação novamente. As principais plataformas públicas de computação em nuvem, como AWS, RackSpace e Google Cloud oferecem máquinas virtuais com suporte nativo ao Docker,
Figura 20: Arquitetura de Implantação
então uma vez criado o container, ele pode ser transportado de forma simples para outra máquina. Para o desenvolvimento do AdaptMCloud, optamos por utilizar o Docker local- mente, em uma máquina com 12GB de Memória RAM, com a distribuição Linux Ubuntu 14.10 e um processador Core Intel i5 de 2.2GHz. Um container em Docker é criado a partir de uma imagem, semelhante ao processo de criação de instâncias em nuvens como a AWS. Uma imagem pode conter uma série de software pré-instalados, que facilitam o processo de configuração e implantação das aplicações. No caso dessa tese, utilizamos a imagem
ubuntu4
que cria um container com as configurações básicas da distribuição Ubuntu 14.10. Uma vez instalado todos os softwares necessários (Servidor Tomcat, InfluxDB e servidor Jackrabbit), todo o processo de desenvolvimento fica associado ao container, ou seja, uma vez finalizado, basta fazer o upload da versão atual do container para uma máquina vir- tual em qualquer provedor de nuvem com suporte a Docker. Para avaliação, implantamos
o container em uma instância EC2 da Amazon do tipo t2.small5
, que possui 1 Unidade de CPU, 2GB de RAM a um custo mensal estimado de 18.72 dólares, considerando uma carga regular de utilização.
Na mesma Figura 21 são mostrados as plataformas públicas e serviços utilizados pe- las aplicações e que são monitorados pelo loop de controle. Conforme especificado na seção 3.3.2, o sistema QoMonitor realiza o processo do monitoramento através a exe-
4Ubuntu Docker Image - https://hub.docker.com/_/ubuntu/
cução cíclica de serviços web que fazem utilizações simples dos serviços de computação em Nuvem utilizados. Isso significa que para cada serviço ilustrado na figura, existe um WebService, que faz requisições periódicas ao serviço em questão. Para as avaliações apre- sentadas nos capítulos seguintes, definimos que a cada 30s deve ser feita uma requisição dos serviços de nuvem monitorados. Uma vez configurado o serviço de monitoramento, o usuário deve acessar o módulo web da solução AdaptMCloud e instanciar um novo processo de controle, informando a URL onde o servidor representado pela classe Applica- tionSpecificRestServer pode ser acessado, o token de acesso, além dos arquivos contendo a representação XML do modelo de features estendido; o artefato Implementation Descrip- tion e o arquivo contendo a transformação XSLT. Uma vez realizadas essas configurações o loop de controle para aquela determinada aplicação é iniciado e segue as etapas descritas neste capítulo.
Já as aplicações HealtWatcher e WebBombeioMecanico foram implantadas em duas plataformas de nuvem diferentes: AWS e Rackspace respectivamente. Para implantar a aplicação HealthWatcher criamos uma instância t2.micro que possui apenas uma CPU e 1GB de memória RAM e tem um custo mensal de aproximadamente 9.36 dólares. Já a aplicação WebBombeioMecanico foi implantada em uma instância Rackspace do tipo General1-1, que possui uma CPU e 1GB de memória RAM ao um custo mensal estimado de 23.34 dólares. Devemos destacar que as escolhas de instâncias simples estão associadas a natureza desse estudo, que é acadêmico e pela impossibilidade de custear simulações em instâncias maiores ou com simulação de aumento de carga que gere um novo escalonamento das aplicações.
3.6
Conclusão do Capítulo
Neste capítulo apresentamos a primeira contribuição desse trabalho, que consiste na visão geral da solução AdaptMCloud, um loop de controle autonômico, baseado no MAPE- K. O processo de adaptação é iniciado com o monitoramento de propriedades de serviços de nuvem, que podem ser utilizados por uma aplicação multi-cloud. Para representar as possibilidades de serviços a serem utilizados, bem como de que forma essas proprieda- des estão relacionadas com esses serviços, propomos um modelo de features estendido, da qual seja possível derivar configurações multi-cloud para uma aplicação. Para definir qual configuração deve ser utilizada, criamos mecanismos para a especificação de requisi- tos não-funcionais, com base nas propriedades monitoráveis definidas. Durante a fase de análise, o processo de seleção é executado, gerando uma configuração multi-cloud para a
Figura 21: Cenário de Implantação do AdaptMCloud, aplicações exemplos e plataformas/- servições de nuvem
aplicação. Considerando a natureza heterogênea das aplicações em que cada desenvolvedor pode adotar uma técnica diferente para definir como a aplicação pode ser adaptada, essa solução permite a utilização de três técnicas diferentes de programação, onde na fase de planejamento é definido como a adaptação/reconfiguração será realizada. Para evitar que um eventual overhead da solução comprometa a aplicação ou mesmo para dar liberdade ao usuário/desenvolvedor sobre a forma como a aplicação é implementada, a solução foi projetada para funcionar de forma totalmente desacoplada da aplicação, podendo inclu- sive estarem em locais distintos. Dessa forma, na fase de execução, a solução AdaptMCloud notifica um módulo específico implantado junto com a aplicação para executar o processo de adaptação propriamente dito, de acordo com a técnica de programação utilizada.
Apresentamos ainda duas aplicações exemplos que utilizam diversos tipos de serviços de nuvem, em plataformas líderes de mercado e públicas, uma vez que é objetivo deste trabalho que a utilização da solução aqui proposta seja utilizada em cenários reais, o que motivou a construção de todas as avaliações usando dados reais de plataformas públicas e acessíveis a qualquer um. Uma vez apresentado como loop de controle funciona, a primeira etapa para sua concreta utilização é a modelagem dos serviços de nuvem e a especificação dos requisitos não-funcionais, atividades essas descritas no próximo capítulo.