Os resultados obtidos pela aplica¸c˜ao desenvolvida, foram como um todo satisfat´orios, e encontram-se listados abaixo:
1. A nuvem implantada no LabEPI em um ambiente de testes agora possui o servi¸co de Telemetria instalado e funcionando corretamente, algo que anteriormente n˜ao existia e permite o uso de suas funcionalidades no gerenciamento de recursos da nuvem acadˆemica;
2. A aplica¸c˜ao permite maior controle e gerˆencia quanto ao uso de recursos da nuvem, auxiliando a tomada de decis˜oes de gestores em casos de escolha por solu¸c˜oes em nuvens, utilizando o monitoramento do uso dos recursos;
3. A aplica¸c˜ao possu´ıa uma vers˜ao similar (que ´e integrada diretamente ao Dashboard e vem implementada por padr˜ao quando se instala o servi¸co Ceilometer), no entanto, a aplica¸c˜ao desenvolvida existe de maneira separada e pode ser executada de maneira independente do Dashboard;
Figura 4.3: Gr´afico contendo as informa¸c˜oes da m´etrica cpu util. Fonte: O Autor
4. Permite facilmente a futuras implementa¸c˜oes estipular o consumo baseado em valores monet´arios e at´e mesmo prover outras informa¸c˜oes al´em do consumo;
5. A aplica¸c˜ao oferece um maior n´ıvel de transparˆencia com todos os usu´arios, qualquer usu´ario pode acessar suas informa¸c˜oes de uso de recursos, e a hora que quiser, na aplica¸c˜ao similar provida pelo Dashboard apenas usu´arios administradores podem acessar as m´etricas de todos os usu´arios como pode ser visto na Figura 4.4.
De acordo com o observado na Figura4.4, para a vers˜ao Icehouse do OpenStack (que foi a vers˜ao estudada e desenvolvida a aplica¸c˜ao), o usu´ario Admim (Administrador) tem acesso ao painel do sistema e tem acesso `as informa¸c˜oes de estat´ısticas para m´etricas.
J´a na Figura 4.5 percebe-se claramente que o usu´ario comum intitulado ”teste”n˜ao possui nenhum acesso ao painel de controle e n˜ao pode acompanhar as varia¸c˜oes estat´ısticas de uso dos recursos.
Por fim, com a aplica¸c˜ao criada, pode-se agora, concentrar-se no desenvolvimento de tarefas mais elaboradas para o refinamento dos algoritmos utilizados e fun¸c˜oes da mesma, e para a adi¸c˜ao de novas funcionalidades.
As limita¸c˜oes presentes na aplica¸c˜ao desenvolvida foram:
• Interface com o usu´ario em modo terminal (linha de comandos): A in- tera¸c˜ao do usu´ario com a aplica¸c˜ao ´e feita via terminal, ou seja, para esta vers˜ao a aparˆencia n˜ao ´e amig´avel e pouco intuitiva para a inser¸c˜ao dos dados, ideal seria a implementa¸c˜ao de uma interface gr´afica com bot˜oes caixas de di´alogo;
Figura 4.4: Exemplo de visualiza¸c˜ao de metrica do Dashboard para usu´ario admin. Fonte: O Autor.
Figura 4.5: Exemplo de visualiza¸c˜ao de metrica do Dashboard para usu´ario comum. Fonte: O Autor.
• Credenciais de usu´ario vis´ıveis durante a autentica¸c˜ao: As credenciais (login, tenant, e password) ficam vis´ıveis aos usu´arios e a quem estiver pr´oximo ao mesmo, caracterizando uma inconfidˆencia de dados por falta de seguran¸ca, onde o ideal seria ocultar essas informa¸c˜oes;
• A cada m´etrica pesquisada um novo token ´e gerado: Por padr˜ao, quando um usu´ario se autentica no Ceilometer, ´e gerado um ”token”que ´e uma chave ´unica validando aquele acesso realizado, cada token gerado durante uma autentica¸c˜ao ´e v´alido por 60 minutos, sendo necess´ario o usu´ario relogar para voltar a usar as funcionalidades do servi¸co. Na aplica¸c˜ao desenvolvida n˜ao h´a um controle desse tempo e a cada m´etrica consultada o processo de gerar um token ´e refeito n vezes de
acordo com o n´umero n de m´etricas isso faz com que o desempenho da aplica¸c˜ao seja afetado pois demora mais tempo at´e processar todas as requisi¸c˜oes de autentica¸c˜ao e consultar todas as m´etricas. O ideal para este caso seria a cria¸c˜ao de um m´etodo que sempre teste o per´ıodo de uso do token mais atual e caso o mesmo j´a tenha expirado ´e que dever´a existir o envio de uma requisi¸c˜ao para um novo token; • N˜ao foi implementada o suporte `a exce¸c˜oes geradas por pesquisas de
m´etricas n˜ao cadastradas: Caso um usu´ario digite um nome de uma m´etrica de forma errada, ser´a gerada um exce¸c˜ao que n˜ao ´e tratada ainda na vers˜ao atual da aplica¸c˜ao, isso interrompe a execu¸c˜ao e nenhuma informa¸c˜ao relevante ´e exibida. • C´alculo para faturamentos indispon´ıvel: Um dos objetivos iniciais da aplica¸c˜ao
era realizar as estimativas do uso das m´etricas para se realizar o c´alculo do fatura- mento em Valores monet´arios. Essa estimativa poderia ser realizada atrav´es do c´alculo de gastos com equipamentos e com o local onde a nuvem se hospeda, di- vidindo os gastos totais em um per´ıodo de tempo (mensalmente por exemplo) e estipulando o valor por hora, dessa forma quando se instanciar o servi¸co para v´arios usu´arios basta aplicar os valores baseando-se na utiliza¸c˜ao dos recursos. Dessa ma- neira tornaria poss´ıvel para gestores de empresas que utilizem o servi¸co comparar gastos utilizando os recursos da nuvem com gastos utilizando recursos f´ısicos provi- dos pela pr´opria empresa, isso ´e importante na avalia¸c˜ao de vantagens de se adquirir o servi¸co por parte de clientes.
No entanto, houveram limita¸c˜oes para que fosse poss´ıvel a implementa¸c˜ao de tal funcionalidade, pois para a nuvem acadˆemica implantada no LabEPI n˜ao havia ma- neiras de mensurar valores de gastos com a nuvem hospedada, devido n˜ao se ter o acesso aos gastos individuais com ar-condicionado, energia el´etrica utilizada pelos equipamentos e pela pr´opria nuvem, e etc.
OpenStack: Utilizando o servi¸co de Telemetria para c´alculo de estimativas 37
Cap´ıtulo 5
Considera¸c˜oes Finais
“Talvez n˜ao tenha conseguido fazer o melhor, mas lutei para que o melhor fosse feito. N˜ao sou o que deveria ser, mas Gra¸cas a Deus, n˜ao sou o que era antes”
Marthin Luther King
5.1
Conclus˜oes
O trabalho realizado teve como caracter´ıstica principal a implanta¸c˜ao e desenvolvi- mento de projetos para cloud computing. Apesar desta ser uma ´area em grande expans˜ao, muitos desenvolvedores e alunos de cursos de tecnologias em geral talvez tenham apenas a op¸c˜ao de trabalhar em projetos similares se contribu´ırem ou se aventurarem tamb´em nas diversas plataformas de c´odigo aberto para desenvolvimento em nuvem. Durante este trabalho, foi poss´ıvel adquirir conhecimentos quanto `a estrutura, tecnologias, processos e funcionamento de grandes sistemas, como o do OpenStack o que com certeza agora se torna base para pesquisas e desenvolvimentos futuros de projetos maiores.
Conclui-se que as atividades e objetivos planejados antes e durante o processo foram realizados de forma satisfat´oria, mostrando a importˆancia do trabalho `as ´areas tecnol´ogicas envolvidas e que o utilizam, das quais a cloud computing e Tecnologia da Informa¸c˜ao se destacam. Este mesmo trabalho tamb´em pode ser utilizado como base para a cria¸c˜ao de sistemas mais avan¸cados, auxiliando no desenvolvimento de novos estudos sobre o tema e integra¸c˜oes com outras aplica¸c˜oes.
Como legado, permanece o fato de ter-se desenvolvido uma aplica¸c˜ao totalmente ´util para usu´arios de cloud computing calcularem e estimarem seus consumos de recursos em uma nuvem OpenStack. Outro ponto de destaque foi a iniciativa de desenvolvimento do trabalho em ambientes acadˆemicos, em que atrav´es de pesquisa liter´aria n˜ao foi encontrado nenhum outro registro de aplica¸c˜ao similar, antes desenvolvida especificamente com o escopo e finalidades aqui propostas, e que pode ser usado pela comunidade open source em geral.
Para gestores, a aplica¸c˜ao assume o papel de ferramenta alternativa para an´alise e com- para¸c˜ao de gastos, e desempenho econˆomico de organiza¸c˜oes em situa¸c˜oes de utiliza¸c˜ao de recursos em nuvem, auxiliando a tomada de decis˜oes, quanto a circunstˆancias e vantagens de utiliza¸c˜ao de servi¸cos em Nuvem.
acadˆemica na qual a aplica¸c˜ao foi desenvolvida. Permitindo que instancias acadˆemicas levantadas (criadas) na nuvem, sejam monitoradas quanto a utiliza¸c˜ao dos recursos, au- xiliando professores e alunos em projetos que a utilizem. Al´em de ser um servi¸co pr´oprio da universidade.
Por fim, foram enfrentadas algumas limita¸c˜oes durante a realiza¸c˜ao da pesquisa, sendo elas, a inacessibilidade `a informa¸c˜oes espec´ıficas de valores gastos com implanta¸c˜ao e manu- ten¸c˜ao (gastos com equipamentos, energia el´etrica) da nuvem no ambiente laboratorial, o qual possibilitaria realizar/desenvolver o trabalho de forma mais abrangente. E limita¸c˜oes quanto `a capacidade de hardware onde a nuvem est´a implantada, recursos computacionais limitados para a realiza¸c˜ao de testes com grandes quantidades de instˆancias, reduzindo dessa maneira as op¸c˜oes de testes e possibilidade de implementa¸c˜oes.