auto-gerenciamentoderecursosem ...€¦ · keywords: self-adaptive software, container-based...

Geomerez Raduan de Oliveira Bandeira

Auto-Gerenciamento de Recursos emInfraestruturas baseada em Contêineres para

Desktop-as-a-Service:Um Estudo de Caso nos Laboratórios de

Informática da ECT/UFRN

Natal-RN

2017

Geomerez Raduan de Oliveira Bandeira

Auto-Gerenciamento de Recursos em Infraestruturasbaseada em Contêineres para Desktop-as-a-Service:

Um Estudo de Caso nos Laboratórios de Informática daECT/UFRN

Dissertação submetida ao Programa de Pós-graduação em Engenharia de Software da Uni-versidade Federal do Rio Grande do Nortecomo requisito parcial para a obtenção dograu de Mestre em Engenharia de Software.

Universidade Federal do Rio Grande do Norte – UFRN

Instituto Metrópole Digital – IMD

Programa de Pós-Graduação em Engenharia de Software

Orientador: Carlos Eduardo da Silva

Natal-RN2017

Universidade Federal do Rio Grande do Norte – UFRN Sistema de Bibliotecas – SISBI

Catalogação da Publicação na Fonte - Biblioteca Central Zila Mamede Geomerez, Raduan de Oliveira Bandeira. Auto-gerenciamento de recursos em infraestruturas baseada emContêineres para Desktop-as-a-Service: um estudo de caso noslaboratórios de informática da ECT/UFRN / Geomerez Raduan deOliveira Bandeira. - 2017. 128 f. : il.

Dissertação (mestrado) - Universidade Federal do Rio Grande doNorte, Instituto Metrópole Digital, Programa de Pós-Graduação emEngenharia de Software. Natal, RN, 2017. Orientador: Prof. Dr. Carlos Eduardo da Silva.

1. Software auto-adaptativo - Dissertação. 2. Virtualização baseadaem contêineres - Dissertação. 3. Desktop como um serviço (DaaS) -Dissertação. 4. OpenVZ - Dissertação. 5. LTSP-Cluster -Dissertação. I. Silva, Carlos Eduardo da. II. Título.

RN/UFRN/BCZM CDU004.75

Agradecimentos

Agradeço a minha família: Gilsa, Assis, Alzeni, Edileide e Raiany que me auxiliaramnão só nesse período do mestrado, mas em todos os momentos que juntos superamosos desafios. Agradeço a Luziene que esteve junto em todas as etapas vencidas ao longodesse mestrado e dificilmente teria êxito se não fosse sua compreensão nos momentos maiscríticos desse projeto.

Agradeço a Carlos Eduardo pela orientação, ensinamentos, atenção, paciência,incentivo e dedicação. Sempre solícito nas reuniões semanais, teve importância enorme emtodas as fases do projeto.

Agradeço a Marcos Madruga e Paulo Maia, membros da banca na defesa dadissertação, pelas contribuições valiosas indicadas nas arguições. Agradeço também pelaprontidão ao aceitar o convite e pelo tempo dedicado a ler este trabalho.

Agradeço aos integrantes da equipe que trabalham ou trabalharam comigo:Arthur ,Judson e Jeffersson, que participaram desse projeto desde a fase de concepção. Agradeçotambém a Rafael dos Prazeres que muito se dedica em melhorar o serviço nos laboratóriosda ECT e me ajudou muito a pensar como resolver os desafios enfrentados e relatadosnesse trabalho.

Agradeço aos professores: Wendel Medeiros, Sérgio Ramiro, Raul Paradeda, Emma-noel Monteiro e Margarida Knobe que marcaram na minha trajetória acadêmica. Agradeçotambém aos amigos André Henrique, Fábio, Diego, Danilo, Emanoel Gomes, Raniclécio,Fabiano, Mariana, Rafaela, Arlete, Eliceu, Leonardo, André Galvão, Gleide, Kinha ePriscila que sempre me incentivaram ao decorrer da minha vida acadêmica e pessoal.

ResumoUma alternativa viável para instituições que possuem múltiplos usuários com necessidadede acessar aplicações desktops é o Desktop-as-a-Service (DaaS), que caracteriza-se pelaentrega de um ambiente desktop que executa remotamente. A virtualização de recursosem conjunto com o balanceamento de carga são amplamente utilizados em infraestruturasque hospedam serviços com demandas sazonais, replicando instâncias e distribuindo asrequisições entre elas para alcançar elasticidade. Entretanto o balanceamento de carga nãoé a solução mais adequada para o DaaS, uma vez que sessões nesse serviço são de longaduração e não são migradas para um novo servidor que seja adicionado ao balanceador,permanecendo a lentidão percebida pelos usuários já conectados a um servidor sobrecar-regado. Neste contexto, o redimensionamento dinâmico de recursos em uma instânciavirtual se mostra como a abordagem mais apropriada. Contudo, soluções tradicionais devirtualização exigem a reinicialização do servidor afetado, e consequentemente, finalizandoas sessões DaaS com seus respectivos usuários. Por outro lado, virtualização baseadaem contêineres permitem tal redimensionamento, porém exige intervenções manuais doadministrador para ajustar a quantidade de recursos mediante à demanda. Este trabalhoapresenta o ConManager, um controlador autoadaptativo para ambientes baseados emcontêineres, que tem como propósito o redimensionamento dinâmico de recursos virtualiza-dos para lidar com sobrecargas sazonais. A proposta foi aplicada como estudo de caso noslaboratórios de informática da Escola de Ciências e Tecnologia da Universidade Federal doRio Grande do Norte. O ConManager monitora a utilização de recursos nos laboratórios,detectando cenários de sobrecarga, e propondo planos de adaptação que são aplicadosna infraestrutura de suporte ao serviço DaaS, efetivamente redistribuindo recursos decontêineres subutilizados para os sobrecarregados. A ferramenta se encontra em uso eisso trouxe ganhos perceptíveis como diminuição do tempo de adaptação de recursos ea simplificação do gerenciamento do ambiente, beneficiando a equipe de tecnologia dainformação da instituição, responsável por manter o serviço e à comunidade acadêmicaque desfruta de um ambiente computacional mais estável.

Palavras-chave: Software autoadaptativo, Virtualização baseada em contêineres, Contei-nerização, LTSP, Desktop-as-a-service

AbstractA viable alternative for institutions that have multiple users who need access to desktopapplications is Desktop-as-a-Service (DaaS), which is characterized by the delivery ofa desktop environment that runs remotely. Resource virtualization and load balancingare widely used techniques in infrastructures that host services with seasonal demands,replicating instances and distributing requests among them to achieve elasticity. Howeverload balancing is not the most suitable solution for DaaS, since sessions in this serviceare long lasting and are not migrated to a new server that is added to the balancer,remaining the slowness perceived by users already connected to an overloaded server. Inthis context, the dynamic resizing of resources in a virtual instance is shown as the mostappropriate approach. However, traditional virtualization solutions require a reboot ofthe affected server, and consequently, terminating DaaS sessions with their respectiveusers. On the other hand, container-based virtualization allows such resizing, but requiresmanual administrator intervention to adjust the amount of resources on demand. This workpresents ConManager, a self-adaptive controller for container-based environments, whichaims to dynamically resize virtualized resources to handle seasonal loads. The proposalhas been applied as a case study in the computer laboratories of the Escola de Ciências eTecnologia of the Universidade Federal do Rio Grande do Norte. ConManager monitors theuse of resources in laboratories, detecting overhead scenarios, and proposing adaptationplans that are applied to the DaaS service support infrastructure, effectively redistributingresources from underutilized containers to overloaded ones. The tool is currently in useand has brought noticeable gains such as reduced time to adapt resources and simplifiedenvironmental management, benefiting the institution’s information technology team,responsible for maintaining the service and the academic community that enjoys a Stablecomputing environment.

Keywords: Self-adaptive software, Container-based Virtualization, Containerization,LTSP, Desktop-as-a-service.

Lista de ilustrações

Figura 1 – Tipos de hypervisors, adaptado de Oliveira, Carissimi e Toscani (2010),Goncalves (2013) e Scheepers (2014). . . . . . . . . . . . . . . . . . . . 21

Figura 2 – Estrutura de funcionamento do OpenVZ. Relação de nó de hardwarecom os contêineres. Adaptado de SWsoft (2005). . . . . . . . . . . . . 23

Figura 3 – Tipos de virtualização de desktops, adaptado de Shabaitah (2014). . . 26Figura 4 – Arquitetura de funcionamento do VDI, adaptado de Shabaitah (2014). 27Figura 5 – Funcionamento do LTSP-Cluster. Adaptado de LTSP-Cluster (2015) e

Giraldeau Jean-Michel Dault (2006) . . . . . . . . . . . . . . . . . . . 29Figura 6 – Visão geral das abordagens para implementar a autoadaptação, adap-

tado de Oreizy et al. (1999) . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 7 – As fases do Mape-K. Figura adaptada de Salehie e Tahvildari (2009) . 32Figura 8 – Figura adaptada de Weyns et al. (2013) . . . . . . . . . . . . . . . . . 33Figura 9 – Funcionamento dos laboratórios com o VMWare ESXi . . . . . . . . . 35Figura 10 – Funcionamento dos laboratórios com OpenVZ . . . . . . . . . . . . . . 38Figura 11 – Gráficos representativos das respostas obtidas no questionário . . . . . 41Figura 12 – Visão geral da arquitetura conceitual do Conmanager. . . . . . . . . . 43Figura 13 – Visão dos componentes que compõem o ConManager. . . . . . . . . . . 47Figura 14 – Fluxograma do primeiro nível de tomada de decisão . . . . . . . . . . . 55Figura 15 – Fluxograma do segundo nível de tomada de decisão . . . . . . . . . . . 57Figura 16 – Demonstração da tela principal do ConManager, aba de alarmes e

monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figura 17 – Demonstração da tela principal do ConManager, aba distribuição de

recursos e tabela de horários . . . . . . . . . . . . . . . . . . . . . . . . 62Figura 18 – Simulação de alerta e planejamento através da demonstração de telas . 63Figura 19 – Gráficos do que exibem a carga de processamento durante o experimento 66Figura 20 – Gráficos do que mostram a utilização de memória RAM e SWAP durante

o experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Figura 21 – Gráficos do que mostram a quantidade de usuários logados e utilização

da rede durante o experimento . . . . . . . . . . . . . . . . . . . . . . 67Figura 22 – Gráficos do que mostram a utilização do disco durante o experimento . 68Figura 23 – Gráficos do Zabbix que ilustram a sobrecarga de um contêiner com o

Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Figura 24 – Dados de utilização de CPU e memória RAM do laboratório durante

aula de lógica de programação. . . . . . . . . . . . . . . . . . . . . . . 71Figura 25 – Telas do ConManager no momento que foi acusado a sobrecarga no

laboratório 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Figura 26 – Gráfico de utilização e carga do CPU durante a aula de lógica deprogramação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Figura 27 – Gráfico de utilização da quantidade de usuários logados durante a aulade lógica de programação . . . . . . . . . . . . . . . . . . . . . . . . . 74

Figura 28 – Caso de uso ilustrando a interação do usuário no cenário de cadastrarinfraestrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Figura 29 – Caso de uso ilustrando a interação do usuário no cenário de realizarintervenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Figura 30 – Caso de uso ilustrando a interação do usuário na utilização da telaprincipal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Figura 31 – Diagrama de classe dos servidores hardware e aplicação . . . . . . . . . 114Figura 32 – Diagrama de classe do monitor e agente . . . . . . . . . . . . . . . . . 115Figura 33 – Diagrama de classe da intervenção . . . . . . . . . . . . . . . . . . . . 116Figura 34 – Diagrama de classe de planejamento . . . . . . . . . . . . . . . . . . . 117Figura 35 – Diagrama de sequência que mostra o comportamento dos componentes

de monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Figura 36 – Diagrama de sequência que mostra o comportamento dos componentes

do módulo de análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Figura 37 – Diagrama de sequência que mostra o comportamento dos componentes

dos módulos de planejamento e execução . . . . . . . . . . . . . . . . . 120

Lista de tabelas

Tabela 1 – Concatenação dos dados obtidos no questionário aos professores . . . . 40Tabela 2 – Configuração de Triggers . . . . . . . . . . . . . . . . . . . . . . . . . 50Tabela 3 – Status de utilização dos servidores de aplicacao . . . . . . . . . . . . . 51Tabela 4 – Status de utilização do servidor hardware . . . . . . . . . . . . . . . . 52Tabela 5 – Sequência de intervenções feitas no cenário de sobrecarga apresentado. 72

Lista de abreviaturas e siglas

API Application programming interface

BCT Bacharelado em Ciências e Tecnologia

CPU Unidade central de processamento

DAAS Desktop as a Service

DHCP Dynamic Host Configuration Protocol

ECT Escola de Ciências e Tecnologia

FTP File Transfer Protocol

GB Gigabyte

HD Hard Disk

HDX High Definition Experience

HTTP Hypertext Transfer Protocol

I/O Input/Output

ID Identificador

IP Internet Protocol

LTSP Linux Terminal Server Project

LVS Linux Virtual Server

LXC Linux Containers

MVC Model-Control-Control

OSI Open System Interconnection

PcoIP Personal Computing over Internet Protocol

PID Identificador de processo

PXE Pre-eXecution Environment

RAM Random Access Memory

RDC Cliente de desktop remoto

RDP Remote Desktop Protocol

RDS Remote Desktop Services

SBDV Session-based desktop virtualization

SO Sistema Operacional

SSH Secure Shell

TFTP Trivial File Transfer Protocol

TI Tecnologia da Informação

V-CPU CPUs virtuais

VDI Virtual desktop infraestructure

VE Virtual Environment

VM Máquina virtual

VMM Virtual machine monitor

VNC Virtual Network Computing

VOIP Voice over Internet Protocol

VPS Virtual Private Server

WTS Windows Terminal Services

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 192.1 Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.1 Caracterizando Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.2 Conteinerização com OpenVZ . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Desktop como um serviço . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.1 Virtual Desktop Infraestructure (VDI) . . . . . . . . . . . . . . . . . . . . 262.2.2 Virtualização de desktops baseada em sessão . . . . . . . . . . . . . . . . 282.3 Sistemas autoadaptativos . . . . . . . . . . . . . . . . . . . . . . . . . 302.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 O CASO DA ECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1 O cenário da ECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Solução anterior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3 Evolução do serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 PROJETO CONMANAGER . . . . . . . . . . . . . . . . . . . . . . 424.1 Visão geral da arquitetura do ConManager . . . . . . . . . . . . . . . 424.2 Elicitação de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Detalhamento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.2.1 Definição de gatilhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.2.2 Status de utilização dos servidores . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.3 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.3.1 Processo de tomada de decisão do módulo de planejamento . . . . . . . . . . . . . 53

4.3.3.2 Primeiro nível de tomada de decisão . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.3.3 Segundo nível de tomada de decisão . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3.4 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.1 Detalhes da implementação . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Demonstração de utilização . . . . . . . . . . . . . . . . . . . . . . . . 615.3 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.1 Experimentos controlados . . . . . . . . . . . . . . . . . . . . . . . . . 656.2 Relato de uso em produção . . . . . . . . . . . . . . . . . . . . . . . . 696.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 767.1 Produtos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.2 Pesquisas relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.3 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A APÊNDICE - REQUISITOS DO SISTEMA . . . . . . . . . . . . . . 86A.1 Onde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86A.2 Quando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.3 O quê . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.4 Porquê . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A.5 Quem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A.6 Como . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

B APÊNDICE - CASOS DE USO . . . . . . . . . . . . . . . . . . . . . 104

C APÊNDICE - DIAGRAMAS DE CLASSES . . . . . . . . . . . . . . 114

D APÊNDICE - DIAGRAMAS DE SEQUÊNCIA . . . . . . . . . . . . 118

E APÊNDICE - QUESTIONÁRIO . . . . . . . . . . . . . . . . . . . . 121

F APÊNDICE - RESTRIÇÕES . . . . . . . . . . . . . . . . . . . . . . 122

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

14

1 Introdução

Em muitas instituições de ensino é comum a presença de laboratórios de informáticadirecionados a atender a comunidade acadêmica que, de uma forma ou de outra, os utilizampara a realização de suas tarefas, sejam elas uma aula ou uma simples navegação na internetem horários livres. Projetar quais tecnologias utilizar como softwares, hardwares e rede,tanto como manter e controlar toda essa estrutura em funcionamento se torna um grandedesafio para os responsáveis pelo gerenciamento desses laboratórios. Existem diversasalternativas para atender essa demanda, tais como desktops tradicionais equipados comboa quantidade de memória, processador e disco; terminais leves que se conectam em umservidor de grande capacidade através de protocolos de acesso remoto como RDP e VNC,de acordo com Banik et al. (2006); terminais leves com sistemas locais mas com grandelimitação de recurso, conforme Moreira et al. (2008), entre outras possibilidades.

A Escola de Ciências e Tecnologia (ECT) da Universidade Federal do Rio Grandedo Norte (UFRN) oferece o curso de Bacharelado em Ciências e Tecnologia (BC&T) noqual provê formação generalista (primeio ciclo) para a maioria dos cursos de engenharia(segundo ciclo) da UFRN, segundo ECT (2010). A ECT dispõe de quatro laboratóriosde informática com um total de 160 estações de trabalho baseadas em terminais-leves1

(computadores que caracterizam-se pela pouca quantidade de recursos computacionaiscomo disco, memória, processamento), para atender aos diversos componentes curricularesoferecidos. Estes componentes envolvem aulas com diferentes tipos de software, indo desdeprogramação básica, desenvolvimento Web e móvel, até aulas com simulação de fenômenosfísicos/quimicos, métodos numéricos, e Computer-aided design (CAD).

Tendo a responsabilidade de gerenciar a infraestrutura computacional dos labo-ratórios, a equipe de TI da ECT adotou uma abordagem Desktop-as-a-Service (DaaS),um serviço de entrega de um ambiente desktop que está executando remotamente, comoafirmam Gomes et al. (2016). A solução adotada pela ECT é baseada em sessão de desktop,onde um servidor remoto provê diversas sessões simultâneas, compartilhando recursos doservidor, conforme Cruz et al. (2010). Tal escolha considerou o custo com infraestrutura(já que pode-se compartilhar uma instância em diversas sessões) e centralização do geren-ciamento (uma mudança feita em uma instância afeta todas as sessões hospedadas nela).Mais especificamente, foi adotada a tecnologia de terminais leves com o Linux TerminalServer Project (LTSP)2, juntamente com o LTSP-Cluster 3, projeto que reúne plugins doLTSP e provê novas funcionalidades como o balanceamento de carga em um grupo de1 Neste texto utiliza-se os termos terminais leves e thin-clients de maneira intercambiável2 <http://www.ltsp.org/>3 <https://www.ltsp-cluster.org/documentation/howto/openvz-setup>

http://www.ltsp.org/

https://www.ltsp-cluster.org/documentation/howto/openvz-setup

Capítulo 1. Introdução 15

servidores de aplicação. O uso dos dois projetos permite que a carga de trabalho geradapelos clientes remotos sejam equilibradas em mais de um servidor. O provimento desteserviço na ECT evoluiu com o passar do tempo, graças aos estudos de novas técnicas eabordagens para melhorar a experiência do usuário (referente à estabilidade do ambiente)e facilitar o gerenciamento da infraestrutura.

O autor deste trabalho de mestrado é integrante da equipe de Tecnologia da Infor-mação (TI) da ECT. Seu ingresso na equipe aconteceu quando já estava em funcionamentoesse serviço de terminais leves nos laboratórios. Quando já integrado, participou na implan-tação da evolução do serviço ofertado e aprofundou os estudos referentes à virtualização,suas características e as demais tecnologias de ambientes remotos para dar subsídio aotrabalho desenvolvido no mestrado.

1.1 MotivaçãoUm dos requisitos da ECT é o isolamento dos laboratórios para que atividades

realizadas em um não interfira nos demais. Para isso, foi adotada uma estratégia devirtualização no qual cada laboratório é atendido por um servidor virtual independente.Um servidor com grande capacidade de recursos computacionais (como processamento,memória e espaço em disco) foi utilizado para comportar as instâncias virtuais destinadasaos laboratórios. Desse modo, consegue-se independência na instalação de softwares, regrasde acesso à rede interna ou externa e outras configurações de ambiente. Cada laboratóriorecebe uma quantidade dos recursos do servidor para atender a seus usuários e esse valorfoi estipulado pela equipe que gerencia o ambiente, levando em consideração o quanto éexigido normalmente por cada laboratório.

Um desafio comum enfrentado pela equipe da ECT e por demais pessoas quegerenciam esse tipo de ambiente virtual, segundo Chebiyyam et al. (2009), é o de gerenciarrecursos no servidor (como memória, CPU e disco) em ocasiões onde uma instância virtualutiliza toda a sua cota de recursos enquanto as outras são pouco utilizadas. Os limitesestipulados às instâncias garantem que elas não utilizarão mais do que está configurado.Essa dificuldade não acontece apenas em pequenas infraestruturas, mas também emgrandes data centers e provedores de computação em nuvem, consoante Maurer, Brandic eSakellariou (2013). Para ocasiões como essa, é necessário que a tecnologia de virtualizaçãoconsiga adaptar a quantidade de recursos destinados à instância sobrecarregada paraatender as demandas em horários de picos. A tecnologia utilizada pela ECT para implantaresse cenário (VMWare ESXi versão free) traz limitações, de acordo com VMware (2009),que não permitem a adaptação dos recursos nos momentos de alta utilização em tempode execução, cabendo à equipe utilizar o balanceador de cargas (LTSP-Cluster) pararedirecionar novos usuários para laboratórios sem utilização, quando era possível. Essa


manobra era necessária, pois aumentar a quantidade de recursos de uma instância só épossível se reiniciar a máquina virtual, causando imensos transtornos a todos os usuários.Porém, no mercado existem diferentes abordagens para solucionar esse problema: outrastecnologias de virtualização utilizam técnicas que auxiliam na otimização do uso dosrecursos, como o memory balloning implementado pela VMware ESX4, Hyper-V e KVM,como afirma Rouse (2014), que é conseguido através do compartilhamento de páginasidênticas de memória, segundo Miller et al. (2013) ou compartilhamento de CPU tambémadotado pela VMware, de acordo com VMware (2006), conhecido como (time-sharing) ,como explicado por Muchalski (2014), para contornar essa situação. Mesmo as tecnologias devirtualização que fazem uso dessas técnicas possuem um ponto fraco ao serem empregadasem ambientes como os dos laboratórios da ECT, pois as técnicas citadas exigem queo administrador estipule previamente a faixa da quantidade de recurso que poderá serredimensionada sem desligar a instância. Para os casos que a instância necessite maisrecurso do que configurado, o administrador deve adaptar manualmente os recursos entreas instâncias.

A tecnologia de conteinerização (também conhecida como virtualização a nívelde sistema operacional), segundo Soltesz et al. (2007) e Xavier et al. (2013), surge comouma alternativa para o provisionamento de servidores de aplicações virtuais, permitindoalterar os recursos alocados a cada contêiner em tempo de execução. No entanto, somentea contêinerização não é o suficiente para atender o requisito do gerenciamento de recursos.Existem hoje soluções para o gerenciamento de contêineres com forte uso do balanceamentode carga, tais como kubernetes5 e Docker Swarm6, que suportam a criação e remoçãodinâmica de novos contêineres de acordo com a carga de trabalho. Entretanto, tais soluçõesabordam a escalabilidade com balanceamento de carga iniciando contêineres idênticossegmentando a carga de maneira a deixar todos contêineres com a mesma carga de trabalho.Essa abordagem não é a mais indicada para cenários DaaS, pois as sessões dos usuáriosapresentam um longo tempo de duração e a adição de novos servidores não faz com que acarga seja balanceada imediatamente, pois as sessões já iniciadas no sistema operacionalpermanecerão no servidor sobrecarregado, sendo necessário reiniciar a sessão para quea carga seja balanceada. Essa situação pode causar transtornos em ocasiões de aulas eprincipalmente de avaliações. Outra estratégia considerada para esse cenário foi a migraçãodas sessões dos usuários para outro servidor virtual. Contudo, as soluções atuais para DaaSbaseado em sessão (como o Remote Desktop Services da Microsoft 7 e o próprio LTSP)não permitem tal migração sem que a sessão seja interrompida e reiniciada. Por outrolado, a migração da instância virtual de um hardware para outro com ela funcionando(conhecida como Live Migration) também não resolveu o problema, pois além de não ser4 <http://www.vmware.com/br/products/esxi-and-esx.html>5 <http://kubernetes.io/>6 <https://www.docker.com/products/docker-swarm>7 <https://technet.microsoft.com/en-us/windowsserver/ee236407.aspx>

http://www.vmware.com/br/products/esxi-and-esx.html

http://kubernetes.io/

https://www.docker.com/products/docker-swarm

https://technet.microsoft.com/en-us/windowsserver/ee236407.aspx


uma ação rápida, a instância virtual continua com a mesma quantidade de recurso alocada,permanecendo sobrecarregados.

As dificuldades enfrentadas motivaram os esforços aqui apresentados, desde o estudodas diferentes tecnologias de virtualização até as diversas abordagens de gerenciamentode recursos. Uma possível solução de gerenciamento desse ambiente pode ser alcançadaatravés de sistemas autoadaptativos, que são capazes de realizar alterações em seu estadoe/ou comportamento conforme variação com os picos de utilização, de acordo com Oreizyet al. (1999). Encontrar uma tecnologia de virtualização que atenda os requisitos e facilitaro gerenciamento dos laboratórios minimizando as dificuldades enfrentadas são os principaismotivadores deste trabalho.

1.2 ObjetivosEste trabalho tem como objetivo geral construir uma solução para o auto-gerenciamento

de recursos computacionais como memória, CPU e disco, em laboratórios que utilizamo serviço DaaS baseado em sessão e que fazem uso da contêinerização para manter seusservidores de aplicação. O alcance desse objetivo proporcionará uma melhor utilização dosrecursos presentes no hardware ao diminuir a subutilização causada pelo provisionamentoe, consequentemente, a expansão dessa solução para outros lugares que trabalham comessas tecnologias e enfrentam os mesmos desafios que a ECT enfrenta.

Para atingir esse objetivo geral, será preciso reunir os esforços para cumprir osobjetivos específicos que consistem em:

• Implementar o monitoramento das cargas de trabalho do cenário, contemplando ainfraestrutura física (hardware) e virtual (instâncias virtuais).

• Desenvolver na solução proposta a capacidade de analisar os dados providos pelomonitoramento para identificar instantes de sobrecarga no ambiente.

• Construir dentro da solução proposta a habilidade de criar planos de adaptação,com base nos dados analisados e efetuar as ações com o objetivo de redistribuir osrecursos do servidor para atender demandas sazonais.

• Medir e avaliar o ambiente com a utilização do software desenvolvido e confrontarcom o ambiente sem a presença do software.

Ao atender os objetivos específicos e consequentemente o geral, esperamos proverao ambiente dos servidores de aplicação uma impressão de elasticidade (auto-scaling) nosrecursos computacionais. Dessa forma, quando em momentos de grande sobrecarga dosrecursos em um laboratório o acréscimo de memória, CPU ou disco permitirá a melhora


da experiência da utilização do sistema operacional. Também é esperado que a tarefa degerenciar os laboratórios seja facilitada, no que diz respeito ao monitoramento e intervençãode forma manual sem fluxo de trabalho definido, diminuindo o tempo de respostas naidentificação da sobrecarga e na adaptação do ambiente. Com isso, proporcionará melhorexperiência de utilização desses laboratórios à toda comunidade acadêmica.

1.3 Organização do trabalhoO restante deste documento está organizado do seguinte modo:

O capítulo 2 contempla a apresentação dos temas que servirão de base teórica paraos assuntos-chave abordados no entendimento do problema e da proposta de intervenção.São eles: Virtualização, Desktop como um serviço e sistemas auto-adaptativos.

O capítulo 3 aborda o caso vivenciado na ECT. Será explicado a infraestruturade hardware disponível e quais tecnologias já foram utilizadas para atender o cenário doslaboratórios. Também é detalhado como se deu a evolução do serviço.

O capítulo 4 reúne as informações do projeto ConManager, como a visão geral daarquitetura, elicitação de requisitos e o detalhamento do projeto.

O capítulo 5 refere-se à implementação do ConManager, com detalhes da arquiteturadas classes e uma demonstração de utilização com as telas do sistema.

O capítulo 6 apresenta a avaliação feita do sistema descrevendo os experimentoscontrolados, os relatos de uso em produção e uma discussão sobre o ambiente.

O capítulo 7 desenvolve os trabalhos relacionados, apresentando os produtos epesquisas relacionadas.

O capítulo 8 debate as conclusões, demonstrando as contribuições, limitações e ostrabalhos futuros aplicados ao ConManager.

19

2 Referencial Teórico

O objetivo desse capítulo é proporcionar um embasamento teórico dos assuntose tecnologias explorados neste trabalho. Aqui é apresentado o resultado da consultabibliográfica e que ajudou a entender os conceitos e proporcionaram melhor compreensãodos assuntos pesquisados. A seção 2.1 apresenta os conceitos básicos sobre virtualização,as diferentes técnicas e será apresentado com mais detalhes o OpenVZ, tecnologia deconteinerização utilizada na ECT. A seção 2.2 apresenta os tipos de implementações doDesktop como um serviço, exemplificando as diferentes técnicas. Também será detalhado ofuncionamento do LTSP e LTSP-Cluster, tecnologias utilizadas nos laboratórios da ECT.A seção 2.3 apresenta os conceitos de softwares auto-adaptativos e do Mape-K.

2.1 VirtualizaçãoA tarefa da virtualização é estender ou substituir um recurso com o intuito de

imitar o comportamento do objeto virtualizado. Para isso, é usada uma camada desoftware como intermediária, responsável por transformar ações de um sistema A, não-virtualizado, em ações equivalentes em um sistema B, virtualizado. Os princípios básicosque a virtualização tenta atender são: (i) compatibilidade, seguindo a filosofia Java de“write once, run anywhere” ; (ii) isolamento, que garante que algo que esteja rodando emuma máquina virtual não veja e nem interfira nas outras máquinas virtuais e, por último;(iii) encapsulamento, permitindo a qualquer momento, capturar o estado da máquina emsua execução e posteriormente retomar o seu estado anterior, conforme Oliveira, Carissimie Toscani (2010).

2.1.1 Caracterizando Virtualização

O processo de virtualização pode se dar em diferentes locais dentro das camadas daarquitetura computacional. Os softwares de virtualização conseguem atuar em vários locaisdessa arquitetura, criando assim três camadas de virtualização, sendo elas: a virtualizaçãoa nível de hardware, a virtualização a nível de sistema operacional e virtualização a nívelde linguagem de programação, segundo Rosenblum (2004) e Oliveira, Carissimi e Toscani(2010).

Na virtualização a nível de hardware, a camada responsável por virtualizar ficabem no topo do hardware, disponibilizando às camadas superiores um hardware similarao original. Como a máquina virtual é semelhante ao hardware, todos os softwares serãoexecutados na máquina virtual, segundo Rosenblum (2004). Máquinas virtuais a nível

Capítulo 2. Referencial Teórico 20

de hardware são implementadas por uma camada de software chamada Virtual MachineMonitor (VMM) ou Hypervisor. Nesse nível de virtualização chamamos de Hypervisor(ou VMM) tipo I, consoante Oliveira, Carissimi e Toscani (2010). O VMM do tipo Iexecuta sobre o hardware da máquina real, fazendo que a máquina virtual se pareçacom o hardware. Esse nível de virtualização é bem difundida no mercado e exemplos detecnologias que implementam são muitos como Xen, VMWare ESX e Hyper-V, de acordocom Oliveira, Carissimi e Toscani (2010).

A virtualização a nível de sistema operacional se caracteriza por ficar entre osistema operacional e os programas aplicativos que são executados sobre ele. Seu papelenvolve a criação de partições lógicas sob o sistema operacional, gerando uma plataformaem cada partição, fazendo que cada uma delas seja vista como uma máquina isoladacapaz de executar aplicativos ou conjunto de aplicativos que são escritos para o sistemaoperacional que está sendo virtualizado.

Uma das implementações desse nível faz uso de uma camada de software devirtualização que fica sobre o sistema operacional hospedeiro capaz de virtualizar sistemasdiferentes do hospedeiro e é conhecido como VMM ou hypervisor do tipo II. Ferramentasconhecidas implementam essa virtualização como o VirtualBox, Virtual PC,VMwareworkstations, segundo Oliveira, Carissimi e Toscani (2010). Outra forma de implementarvirtualização a nível de S.O. é através da conteinerização, um software de virtualizaçãoque faz uso de técnicas do kernel para gerar ambientes isolados chamados de contêineres.As ferramentas que implementam a conteinerização são o LXC, OpenVZ, Linux VServer eas zonas do Solaris, como afirmam Oliveira, Carissimi e Toscani (2010). A Figura 1 ilustraas camadas onde são executadas o hypervisor do tipo I, tipo II e a conteinerização.


Figura 1 – Tipos de hypervisors, adaptado de Oliveira, Carissimi e Toscani (2010), Gon-calves (2013) e Scheepers (2014).

A virtualização a nível de linguagem de programação ocorre na camada de aplicação.Seu objetivo é criar uma máquina abstrata, executando as instruções da linguagem eabstraindo as diferenças nos sistemas operacionais de base. A ideia é que qualquer programaescrito na linguagem e compilado para esta máquina virtual, seja executado nele. Comoexemplos desse nível de virtualização existe o Java Virtual Machine (JVM) e o Smaltalk,segundo Rosenblum (2004).

A técnicas de implementação da virtualização são três: virtualização total, para-virtualização e baseada em contêineres (conteinerização). As duas primeiras são utilizadaspara implementar os hypervisors dos tipos I e II que estão presentes nas virtualizaçõesnos níveis de hardware e sistema operacional, enquanto que a virtualização baseada emcontêineres está presente apenas no nível de sistema operacional.

Virtualização total: Essa técnica de virtualização tem como objetivo prover uma réplicavirtual do hardware no qual está acontecendo a virtualização, de maneira que o sistemaoperacional possa fazer suas operações como se estivesse trabalhando sobre o hardwarereal. A vantagem dessa abordagem é que o sistema operacional hóspede não precisará seralterado para executar sobre o hypervisor. Porém, há alguns pontos negativos como: ohypervisor deve suportar um número muito elevado de hardwares diferentes, já que elesentregam uma réplica do hardware. Como medida para contornar a situação, os hypervisorsfornecem o uso de componentes genéricos, mas não conseguem garantir que serão utilizadosdentro de sua real capacidade. Algo comum que acontece é a perda de desempenhodo sistema hóspede, pois ele foi projetado para executar diretamente sob a camada de


hardware, sem nenhuma concorrência de recursos com outro tipo de sistema operacional,de acordo com Oliveira, Carissimi e Toscani (2010). Pode-se citar como exemplo dessetipo de virtualização KVM, QEmu, Bochs, Parallels, Virtualbox e VirtualPC, conformeKolyshkin (2006).

Para-virtualização: Nessa abordagem, o sistema operacional hóspede precisa ser alteradopara fazer uma chamada à máquina virtual toda vez que for executar uma instrução crítica,como afirmam Oliveira, Carissimi e Toscani (2010). Todas as chamadas de sistema críticasou privilegiada (que possa alterar o estado do sistema) são encaminhadas à máquina virtualpara que ela interprete e emule essas ações da maneira correta. Através desse paradigma,ganha-se com desempenho, já que não são todas as chamadas que precisam da intervenção(testar uma por uma) do hypervisor. As chamadas não-privilegiadas serão diretamenteenviadas ao hardware. Uma outra mudança com relação à virtualização total é que napara-virtualização os dispositivos de hardware são acessados por drivers específicos dasmáquinas virtuais, sem a necessidade de dispositivos genéricos que não exploravam toda acapacidade do dispositivo, de acordo com Oliveira, Carissimi e Toscani (2010). Algunsexemplos de tecnologias que implementam esse paradigma são o Xen e VMWare ESX.

Virtualização baseada em contêineres (conteinerização): Essa técnica de virtuali-zação possibilita a execução de múltiplos ambientes dentro de um único kernel de sistemaoperacional. Traz consigo o conceito de ambiente virtual, também conhecido como contêi-ner. Cada contêiner é um programa em execução totalmente isolado dos outros processosem execução no sistema operacional. Os processos que executam dentro do contêiner nãoconseguem enxergar os outros programas que executam em outros contêineres, segundoKolyshkin (2006). Cada um desses ambientes virtuais possuem seus próprios usuários,sistema de arquivos, interface de rede, endereço IP, regras de firewall, etc. Dentro deum sistema operacional, podem coexistir diversos contêineres e cada um deles podemconter diferentes distribuições, contanto que partilhem do mesmo kernel. Como exemplodesse tipo de tecnologia temos o OpenVZ, Linux-VServer, FreeBSD Jail, LXC, Docker etc,consoante Kolyshkin (2006).

2.1.2 Conteinerização com OpenVZ

Será utilizado como parte da solução proposta, a virtualização no nível de sistemasoperacionais, implementando contêineres com OpenVZ1. Esse tipo de virtualização foiescolhida devido a forma com que ela é implementada, através de manipulação do kernel,ganhando com isso mais agilidade na recuperação de falhas, gerenciamento de recursos(memória, CPU e disco) e isolamento das instâncias. A escolha pelo OpenVZ se deu pelafacilidade de gerenciamento de contêineres através da manipulação de recursos e pelafacilidade de manipulação desses recursos através de sua API.1 <https://openvz.org>

https://openvz.org


O OpenVZ é uma solução tecnológica que propõe o isolamento, virtualização egerenciamento dos recursos computacionais, métodos de congelamento do estado do sistemaoperacional e live migration, permitindo a migração de sistemas completos sem haverinterrupção do serviço.

Como a própria documentação oficial o define, em SWsoft (2005), OpenVZ é serviçocompleto de automação e muito indicado para a demanda de virtualização para servidores,muito comum em data centers. Sua principal característica é a criação de contêineres,também conhecido como Virtual Private Servers (VPS) isolados sobre um servidor físico(chamado no SWsoft (2005) como nó de hardware), com a intenção de compartilhar ouso do hardware e propiciar gerenciamentos dos recursos desse servidor, como pode-seperceber na Figura 2.

Figura 2 – Estrutura de funcionamento do OpenVZ. Relação de nó de hardware com oscontêineres. Adaptado de SWsoft (2005).

Semelhante a uma instância de máquina virtual, cada contêiner executa de maneiraindependente dos outros contêineres, compartilhando alguns recursos e virtualizandooutros. Cada VPS tem seus próprios atributos como usuário root, usuários, endereço IP,quantidade de memória, processos, arquivos, entre outros. No entanto, a forma como éimplementado o isolamento do ambiente, através de ferramentas que manipulam o kernelcompartilhado por todos os contêineres, torna possível o acréscimo e o decréscimo derecursos em tempo de execução, sem a necessidade do desligamento da instância virtual.


Embora soluções tradicionais de virtualização (tais como VMware ESX2, Xen3 e KVM4)possuam mecanismos para otimizar o uso de recursos físicos, de acordo com Miller etal. (2013) e Muchalski (2014), elas não permitem redimensionar em tempo de execuçãoos recursos alocados a uma máquina virtual, isto é, se faz necessário reiniciar a máquinavirtual para seu redimensionamento.

Com a utilização de Kernel Namespaces (recurso do kernel Linux capaz de criarum ambiente isolado, fazendo que os processos isolados em uma namespace consigamvisualizar apenas processos da mesma namespace) o OpenVZ consegue assegurar que cadacontêiner tenha seus recursos isolados. Com o PID namespace é possível que processossejam isolados entre contêineres, além do fato que cada um tenha seu próprio identificador.Também com namespaces o OpenVZ se faz possível o uso de técnicas conhecidas dasmáquinas virtuais como o live migration (migrar um contêiner para outro hardware semnecessidade de desligá-lo), checkpoint (salvar o estado da máquina) e resume (continuar aexecutar o contêiner do ponto em que ele foi salvo), segundo Xavier et al. (2013).

Cada usuário que está fazendo uso de um sistema operacional hospedado em umcontêiner tem a percepção que está em um sistema local e independente. Essa independênciana verdade somente é possível pela camada de virtualização presente no kernel do S.O.do servidor físico, de acordo com SWsoft (2005). Pode-se manipular softwares, fazermodificações em arquivos, ajustes no ambiente, instalar softwares adicionais, sem sepreocupar em afetar os outros contêineres que estão executando sobre o mesmo servidor.

O OpenVZ permite que diferentes distribuições Linux coexistam no mesmo servidorfísico, através dos contêineres. Para que isso ocorra, é preciso que tanto o kernel dadistribuição instalada no contêiner quanto do sistema operacional hospedeiro sejam omesmo. Um template de sistema operacional é um conjunto de pacotes de uma determinadadistribuição Linux que utiliza para criar um contêiner. Basicamente são programas desistemas, bibliotecas, scripts que executam ao iniciar o contêiner e alguns utilitários eaplicações fundamentais do Linux, segundo SWsoft (2005).

Outro pilar importante do paradigma da virtualização no nível de sistemas ope-racionais é o poder de gerenciamento de recursos que não se pode fazer com a mesmafacilidade nos outros tipos de virtualização. Os recursos que podem ser gerenciados são ocompartilhamento do processador, espaço em disco e um conjunto de parâmetros relacio-nados à memória. Todos esses atributos manipulados em tempo real, sem a necessidadede desligar o contêiner, ajustar o recurso desejado e ligar novamente, consoante SWsoft(2005).

O OpenVZ implementa um componente de gerenciamento de recursos (como RAM e2 <http://www.vmware.com/br/products/esxi-and-esx.html>3 <https://xenserver.org/>4 <https://www.linux-kvm.org/page/Main_Page>

http://www.vmware.com/br/products/esxi-and-esx.html

https://xenserver.org/

https://www.linux-kvm.org/page/Main_Page


SWAP) chamado User Beancounters e provê um conjunto de limites e garantias atribuídospara cada contêiner e, dessa forma, controla a distribuição de recursos. Por padrão, aCPU é compartilhada por todos os contêineres de forma igual, sem barreiras que limitam.Com isso, um contêiner pode monopolizar o uso do hardware em detrimento dos outroscontêineres. Para evitar essa situação, o OpenVZ implementa o cpulimit que limita autilização do CPU por contêiner, sendo possível indicar o percentual máximo que ocontêiner poderá utilizar. O valor cpulimit varia de acordo com a quantidade de núcleosde processamento existentes no hardware multiplicado por 100. Por exemplo, o hardwareutilizado na ECT para a instalação do OpenVZ possui 16 núcleos de processamento, sendoo valor cpulimit igual a 1600. Para limitar em 25% o uso do CPU para um contêiner,devemos indicar 400 cpulimits para ele.

2.2 Desktop como um serviçoO serviço de prover um ambiente desktop que está executando remotamente é

chamado de Desktop como um serviço, proveniente do termo em inglês: Desktop-as-a-service (DaaS), ele vem evoluindo cada vez mais com o aprimoramento de protocolos elargura de banda nas redes das instituições. Os tipos mais difundidos desse serviço nomercado e no meio acadêmico são dois: Infraestrutura de desktop virtual, do termo eminglês: virtual desktop infraestructure (VDI) e baseada em sessão, como afirma Shabaitah(2014).

Há três técnicas para implementar o DaaS, segundo Shabaitah (2014), como sãoilustradas na Figura 3: (1) Máquinas virtuais persistentes; (2) Máquinas virtuais não-persistentes; e (3) Baseada em sessão.

A tecnologia VDI implementa o primeiro e o segundo modelo, enquanto o tipobaseado em sessão implementa apenas o último modelo. Cada uma dessas implementaçõespossuem características que deve-se levar em consideração.

No modelo 1 (máquinas virtuais persistentes), chamado por Sakdeo (2012) de Fullclone virtual desktop, cada usuário tem uma máquina virtual dedicada exclusivamentepara ele. Essa máquina tem como base uma máquina virtual de referência e é feita umacópia completa no momento da instanciação. Esse tipo de modelo é caracterizado peloalto consumo de espaço em disco.

Já no modelo 2 (máquinas virtuais não-persistentes) os usuários compartilham asmáquinas virtuais entre eles. Cada vez que um usuário se conecta, ele recebe a instânciade uma máquina virtual aleatória. No lado do servidor, há um pool de recursos que sãoutilizados para a criação de máquinas virtuais. Além disso, Sakdeo (2012) esclarece que asmáquinas virtuais compartilham partes do disco que são apenas leitura e comum a todasas máquinas virtuais.


Figura 3 – Tipos de virtualização de desktops, adaptado de Shabaitah (2014).

No modelo 3 (baseada em sessão), o usuário não tem acesso à sua máquina virtualou uma máquina virtual só para ele. Esse modelo funciona com o compartilhamento derecursos de um servidor entre os usuários. Geralmente esse servidor é robusto e capaz desuprir as necessidades dos usuários em realizar suas atividades. Através de políticas quelimitam o uso dos recursos, é possível isolar a sessão de cada usuário e garantir que o maluso de uma sessão não influenciará as demais sessões no servidor compartilhado.

2.2.1 Virtual Desktop Infraestructure (VDI)

Chama-se de VDI a prática de hospedar o ambiente de sistema operacional de umusuário dentro de uma máquina virtual. Além da virtualização de sistema operacional, suaimplementação envolve outros componentes de virtualização como virtualização de sessão,aplicação, gerenciador de conexão (uma espécie de load balancer que gerencia a carga declientes e também é um ponto de conexão para clientes da rede local), dispositivos deacesso e dados de usuários e diferentes perfis, segundo Shabaitah (2014).

Para se conectar ao VDI é requisitado o uso de um cliente de desktop remoto,do tempo em inglês Remote Desktop Client (RDC), que se conecta ao gerenciador de


conexões. As informações contidas no RDC são o IP, o nome do servidor, a configuraçõesde resolução de tela e qualidade de conexão.

Figura 4 – Arquitetura de funcionamento do VDI, adaptado de Shabaitah (2014).

Como ilustrado na Figura 4, o cliente inicia a conexão executando o arquivo RDC,que se conecta ao gerenciador de conexão (passo 1). O gerenciador de conexão consultaa infraestrutura de servidores (passo 2) e recupera o tipo de VM (persistente ou não-persistente) utilizada pelo usuário (passo 3). O gerenciador de conexão se comunica com ogerenciador virtual (passo 4). Se o tipo de VDI for persistente, o gerenciador de conexãoconecta o usuário a sua máquina virtual e retorna a conexão ao cliente. Da mesma forma,se for do tipo não persistente, o gerenciador de conexão conectará o cliente a uma máquinavirtual aleatória (passo 5). Então é retornada ao usuário a conexão com a máquina virtual(passo 6).

Para acessar essa infraestrutura, diversos protocolos foram implementados e deacordo com o fornecedor da tecnologia, é possível obter experiências distintas. Por exemplo,uma nuvem privada com OpenStack utiliza o protocolo Spice, na estrutura da Microsoftusa-se muito o Remote Desktop Protocol (RDP), a Citrix faz uso do High DefinitionExperience (HDX) e por fim, a VMWare usa o seu VMWare Personal Computing overInternet Protocol (PCoIP), de acordo com Provazza (2013).


2.2.2 Virtualização de desktops baseada em sessão

Uma sessão é um conjunto de processos que provê um determinado serviço para umaentidade lógica como um usuário logado, conforme Shabaitah (2014). Nessa abordagem,é possível atender múltiplos usuários em um único servidor, todos compartilhando osrecursos presentes. Essa solução se mostra mais barata e de mais fácil implementaçãoque o VDI, no entanto, é necessário maior gerenciamento dos recursos disponíveis. Comodiversos usuários compartilham dos mesmos recursos, é preciso ficar atento ao mal uso dosmesmos por parte dos usuários logados.

No contexto deste trabalho, foi utilizado o DaaS baseado em sessão devido apossibilidade de vários usuários compartilharem os mesmos recursos e sistema operacional.Outros fatores importantes considerados são o menor investimento na compra de servidorese maior facilidade no gerenciamento do ambiente. Mais especificamente, foram empregadasas tecnologias Linux Terminal Server Project (LTSP) e LTSP-Cluster.

Por definição da própria comunidade do projeto, de acordo com LTSP (2015), atecnologia Linux Terminal Server Project (LTSP) trata-se de um conjunto de softwaresespecíficos que possibilitam a transformação de uma distribuição Linux instalada demaneira normal em um servidor de terminais. Diferente de outras tecnologias que atendemterminais leves, que necessitam de um pequeno sistema para inicializar (boot) o terminal ese conectar a um servidor, o LTSP não requer software pré-instalado do lado cliente.

A diferença está na interface de rede PXE (Pre-eXecution Environment), pré-requisito para carregar o sistema operacional via rede, ou seja, não precisamos de unidadede disco para realizar essa ação. Além de reduzir custos, ele também reduz a demandapor administração das máquinas existentes. O processo de boot pode ser resumido nosseguintes passos, de acordo com McQuillan (2004):

1. Ao ser iniciado, o computador busca informações de rede no servidor DHCP;

2. Via TFTP é feito o download do kernel;

3. O kernel Linux é carregado na memória do terminal. No caso da ECT, é utilizado oprotocolo PXE para realizar essa etapa;

4. Ao ser carregado o kernel na memória, sua execução é iniciada;

5. O kernel reconhece todos os periféricos e todo o sistema básico;

6. Outros parâmetros são lidos para montar a imagem, reconhecer os dispositivos daplaca mãe, montar toda a estrutura de sistema de arquivos e diretórios do usuário,configurar as interfaces de rede, etc;


7. O usuário se conecta ao LTSP, onde permanece com a sessão ativa no período queele está usando o computador.

O LTSP-Cluster é um projeto com o intuito de prover novas funcionalidades àtecnologia LTSP, além de propor uma arquitetura de funcionamento com a presença deum balanceador de carga, responsável por checar o estado dos servidores de aplicaçõese distribuir as sessões de forma igualitária. Também provê ferramentas do lado servidorque facilitam o gerenciamento do parque tecnológico atendido pelo LTSP, de acordo comLTSP-Cluster (2015).

Figura 5 – Funcionamento do LTSP-Cluster. Adaptado de LTSP-Cluster (2015) e Giral-deau Jean-Michel Dault (2006)

A Figura 5 ilustra o funcionamento lógico do LTSP-Cluster, conforme GiraldeauJean-Michel Dault (2006). A caixa com o nome Terminal representa os terminais leves oudesktops dentro de um laboratório, Boot Server representa o servidor capaz de receber eatender as requisições dos usuários e cada Application Server representa o servidor ondeestá instalado o sistema operacional que será compartilhado pelas sessões dos usuários.Dentro do Boot Server executa o serviço Accounts Manager, responsável por criar egerenciar as sessões dos usuários com auto-login (sem necessidade de autenticação paraentrar no ambiente). O PXE Configuration Editor obtém os parâmetros de configuraçõesfeitas pelo administrador através do Control Center (uma interface WEB de gerenciamento)para implementar as mudanças indicadas (se houver).

Cada Application Server possui um Load Balancer Agent que está em constantecomunicação com o Load Balancer Server (através de requisições HTTP GET/POST) ecom cada terminal (através do HTTP Client), informando o status do servidor de aplicação.Esse status envolve dados como quantidade de usuários logados, memória disponível euso do processador. Quando um cliente faz a requisição de um sistema operacional para


seu terminal leve, o load balancer server deverá conhecer qual servidor de aplicação temrecursos suficiente para receber o cliente que fez a solicitação.

2.3 Sistemas autoadaptativosUm sistema de software autoadaptativo é capaz de realizar, em tempo de execução,

alterações em seu estado e/ou comportamento de acordo com as mudanças ocorridas emseu ambiente de operação, de acordo com Oreizy et al. (1999), Laddaga e Robertson (2004)e Cheng et al. (2009). O ambiente operacional em que o sistema está inserido pode serentendido por qualquer coisa observável pelo software, tal como entrada de usuário final,dispositivos de hardware externos, sensores e todas as outras possibilidades de intervençãoque acontecem em um ambiente, como falhas e alterações em seus requisitos. Um softwareautoadaptativo requer confiança elevada, robustez, adaptabilidade e disponibilidade. Paraisso, é necessário desde a sua concepção, como no levantamento dos requisitos e modelagemdas classes, levar em consideração pontos que viabilizem a autoadaptação.

Em seu trabalho, Oreizy et al. (1999) apresentam diversas abordagens para atingira autoadaptação num software, organizadas em um espectro que vão de expressões condicio-nais fixadas em código-fonte ao uso de técnicas de Inteligência Artificial. A Figura 6 ilustraa visão geral das variadas maneiras de conseguir que um software se autoadapte, sendoque as abordagens que se aproximam mais da base dão suporte à mudanças localizadas,se referindo a ausência de generalização, enquanto que as abordagens que estão maispróximas do topo dão suporte a inúmeras mudanças e provêm uma clara generalizaçãodas adaptações.

Nos softwares que fazem uso das expressões condicionais para implementar aautoadaptação é feita a avaliação de uma expressão e, baseado no resultado, altera-se o comportamento. Embora simplista, essa maneira é muito comum para realizar aimplementação do comportamento adaptativo. Algoritmos online levam em consideraçãouma suposição de eventos futuros que são incertos. Eles são adaptativos no que utilizamseus prévios conhecimentos do problema e o domínio do que pode vir como entrada paraalcançar maior eficiência.

Os algoritmos genéricos e parametrizados proveem comportamentos parametrizadose, usualmente, variam devido ao tipo de instanciação ou entradas externas. Já que osalgoritmos genéricos e polimórficos se adaptam conforme os diferentes tipos de dadosque vêm como entrada. Os sistemas que usam a seleção de algoritmos tem como base aspropriedades do ambiente operacional para decidir dentro de um conjunto de algoritmosdisponíveis, o que mais se adequa para adaptar às mudanças no ambiente. Por fim, notopo das possíveis abordagens, a programação evolutiva e técnicas de aprendizagem demáquina utilizam propriedades do ambiente operacional e conhecimento obtido através de


Figura 6 – Visão geral das abordagens para implementar a autoadaptação, adaptado de Oreizyet al. (1999)

experiências anteriores para gerar um novo algoritmo eficaz para promover as adaptações.

Além dos algoritmos capazes de prover autoadaptação em um sistema, é reconhecidaa importância do feedback proveniente do ambiente, utilizado para o software analisar osdados, projetar a intervenção necessária e realizar a ação. Há importantes trabalhos queexibem loops de interação da coleta de dados que representam o estado atual do sistema,análise dos dados, tomada de decisão e efetuação da ação no objeto adaptável. Nesseâmbito, surge o feedback control loop, conforme Cheng et al. (2009), que tem como propostamanter a eficiência de um sistema independentemente das diversas variações que podemocorrer no ambiente que ele está inserido e que podem comprometer seu funcionamento.Para isso, são empregados sensores que monitoram o ambiente e enviam os dados a umcontrolador, que por sua vez utiliza algoritmos de controle ou estratégias para corrigir ocomportamento do sistema por meio de atuadores.

A constante tarefa de rever o ambiente é um processo que deve ser detalhado paraconstruir um sistema autoadaptativo eficiente. De acordo com IBM (2006), o Mape-k foicriado pela IBM, sendo uma forma de implementar o Feedback Control Loop. As fases quecompõe o Mape-K são monitoramento (M), análise (A), planejamento (P), execução (E),além da presença de uma base de conhecimento (K de Knowledge) compartilhada, comoilustrada na Figura 7.

A etapa de monitoramento é responsável pela coleta e correlação entre os dados. A


Figura 7 – As fases do Mape-K. Figura adaptada de Salehie e Tahvildari (2009)

análise é a etapa que fica com a tarefa de analisar os dados providos pela fase anterior ecabe a ela identificar variações no ambiente capazes de comprometer o bom funcionamentodo sistema. O planejamento decide o que deve ser adaptado através da definição de umplano de adaptação. Finalmente, a fase da Execução faz uso dos efetores, executores doscomando de mudança.

Um sistema autoadaptativo interage diretamente em um ambiente, afetando esendo afetado por agentes externos (como usuários e sistemas) e agentes internos (comoprocessos e hardware). Considerando esses aspectos, Weyns et al. (2013) cunham os termos“subsistemas gerenciados” e “subsistemas gerenciadores”, como ilustrado na Figura 8,sendo que os dois estão incluídos em um ambiente no qual interagem. Como resultadodessa interação são produzidos efeitos possíveis de serem observados e medidos. Apenascom essa observação e medição é possível planejar a afetação necessária no ambiente, capazde minimizar as interferências causadas por agentes externos.

O subsistema gerenciado é o responsável por prover o serviço final, destinando-se aos usuários ou ao suporte de outros sistemas. Ele utiliza o ambiente para poderdesempenhar suas funcionalidades. Por tratar-se de um sistema autoadaptativo, faz-senecessário que exista um suporte à adaptações, além de prover condições de monitorá-lo eadaptá-lo. Por sua vez, o subsistema gerenciador tem como papel o controle do subsistemagerenciado. Esse subsistema é capaz de aplicar adaptações que possibilitam ao sistemagerenciado continuar a prover as funcionalidades ao qual este foi projetado. É importantemencionar que o subsistema gerenciador não afeta diretamente o ambiente, mas altera ofuncionamento do sistema gerenciado para realizar tal tarefa.


Figura 8 – Figura adaptada de Weyns et al. (2013)

2.4 Considerações finaisNeste capítulo foi exposto o referencial bibliográfico com os assuntos relevantes

para o entendimento do contexto do problema e a proposta de intervenção no ambiente.Dentre as tecnologias apresentadas, será utilizada a conteinerização com OpenVZ parahospedar o serviço DaaS baseado em sessão e implementado com LTSP e LTSP-Cluster.

34

3 O caso da ECT

O objetivo principal deste capítulo é contextualizar o cenário da ECT e apresentar ainfraestrutura disponível. Serão apresentadas também as tecnologias utilizadas para ofertaro serviço DaaS em seus laboratórios de informática. Mostrando o que existia anteriormentee como se deu a evolução do serviço ofertado, assim como as principais dificuldades erequisitos desejáveis para melhorar o serviço.

3.1 O cenário da ECTA Escola de Ciências e Tecnologia (ECT) é uma importante unidade de ensino

da Universidade Federal do Rio Grande do Norte (UFRN), que ecebe em torno de 4 milalunos por dia, comportando-os em salas de aula, auditórios e laboratórios. O curso deBacharelado em Ciências e Tecnologia (BCT) é a porta de entrada para muitos cursosde engenharia da UFRN, como as engenharias ambiental, biomédica, da computação, demateriais, de petróleo, de telecomunicações, mecânica ou mecatrônica1. Para atender àsdiversas disciplinas do curso BCT, bem como outros cursos temporários, a escola dispõede quatro laboratórios de informática, sendo que um deles é utilizado para livre acesso dosalunos.

As aulas que acontecem nesses laboratórios fazem uso de variados tipos de software,indo desde programação básica, desenvolvimento Web e móvel, até aulas com simulaçãode fenômenos físicos/químicos, métodos numéricos, e Computer-aided design (CAD). Umdos requisitos da ECT é o isolamento dos laboratórios, para que atividades realizadasem um não interfira nos demais. Para isso, foi adotada uma estratégia de virtualização,na qual cada laboratório é atendido por um servidor virtual independente. Desse modo,consegue-se uma independência na instalação de softwares, regras de acesso à rede internaou externa e outras configurações de ambiente.

Cada laboratório suporta até 42 alunos e um professor. Dois laboratórios (Lab1 e Lab 2) são equipados com terminais leves e os outros dois (Lab 3 e Lab 4), commáquinas desktops completas. Em todos os laboratórios o Linux é disponibilizado atravésdo serviço DaaS baseado em sessão com LTSP e LTSP-Cluster. O hardware que dá suportea esse ambiente é um servidor PowerEdge R710, com processador Xeon com 16 núcleos deprocessamento, 80 GB de memória Ram, HD com 2 TB e 4 placas de rede Gigabit, o qualé dedicado exclusivamente para atender o ambiente LTSP.1 <http://ect.ufrn.br/index.php/faca-c-t>

http://ect.ufrn.br/index.php/faca-c-t

Capítulo 3. O caso da ECT 35

3.2 Solução anteriorO cenário implantado na ECT para atender aos laboratórios de informática é

preexistente ao ingresso do autor deste trabalho de mestrado na equipe de TI da ECT,tendo, posteriormente, assim como os demais membros da equipe a responsabilidadede manter o serviço ativo. Conforme mencionado anteriormente, de modo a atender aorequisito de isolar as atividades dos quatro laboratórios, e como não havia outros hardwarespara instalar o sistema operacional para receber os acessos feito pelos alunos, foi adotadaa abordagem de separar cada laboratório em máquinas virtuais. A tecnologia utilizadareferente à virtualização era o VMWare ESXi 5.5 versão free instalado sobre o servidor,máquinas virtuais (VM) com Linux, e para gerenciar as conexões LTSP, utilizava-se oLTSP-Cluster.

Figura 9 – Funcionamento dos laboratórios com o VMWare ESXi

A Figura 9 ilustra a estrutura montada para atender o serviço DaaS nos laboratórios.Os componentes mais à direita são voltados para a infraestrutura, enquanto que os mais àesquerda são voltados ao serviço. Sobre o hardware está instalado o hypervisor do VMWareESXi (dos diferentes tipos que foi visto na Seção 2.1, se trata de um hypervisor do tipo1 para-virtualizado) e sobre ele estão as máquinas virtuais que hospedam os serviços deacesso remoto. Uma máquina virtual era destinada a hospedar a instalação dos serviçosnecessários para o funcionamento do LTSP e LTSP-Cluster, além de outras quatro queserviam como servidor de aplicação (termo utilizado para denominar onde ficam as sessõesde usuários). A distribuição dos recursos se deu de forma igualitária, ficando 16 GB dememória RAM e 8 CPUs virtuais (referente ao tempo de uso do CPU compartilhado)para cada laboratório. A escolha da quantidade de recursos para cada máquina virtual sedeu através da experiência que a equipe adquiriu em gerenciar o ambiente. Na perspectivado balanceamento de cargas feito pelo LTSP-CLUSTER, os servidores de aplicação sãoseparados por grupos e os usuários inseridos nesse grupo, acessam os servidores apenas


do grupo que estão inseridos. Dessa maneira, foram criados um grupo por laboratório epor decisão da equipe, somente um servidor de aplicação por laboratório. Por sua vez, osusuários acessam as sessões através do serviço LTSP e compartilham os recursos alocadosao servidor de aplicação destinado ao laboratório onde se encontram.

Dificuldades encontradas:

No VMWare utilizado não é permitido alterar, nem mesmo de forma manual, aquantidade alocada de CPU, RAM e Disco de uma máquina virtual em funcionamento.Isso implica a impossibilidade de liberar mais recursos a uma VM sem desligá-la e fazer asalterações. Dessa forma, um dos problemas enfrentados nesse cenário estava relacionadoao fato da impossibilidade de alterar a quantidade alocada de recursos (aumentar oudiminuir) em tempo de execução nas máquinas virtuais. E mesmo que houvesse uma versãoque permitisse manipular recursos sem fazer o desligamento, era necessário que houvessemonitoramento do ambiente e um sistema que fizesse essa tarefa autonomicamente.

Em horários de maior funcionamento de um laboratório, a demanda por maisrecursos aumentava e os usuários sentiam lentidão no ambiente devido à sobrecarga derecursos da máquina virtual que atendia o laboratório. Essa lentidão comprometia o bomfuncionamento das atividades que estavam executando. Enquanto um laboratório estavasobrecarregado, os outros três geralmente estavam com pouco uso ou até mesmo totalmentesubutilizados. Quando a lentidão era excessiva, o professor se dirigia à equipe de TI parareportar a dificuldade enfrentada pela turma. Para contornar a situação de sobrecarga sempoder alocar mais memória e processamento, utilizava-se de um recurso do LTSP-Clusterque permite remanejar a carga de um servidor de aplicação para outro. Com isso, seo laboratório 1 tivesse precisando de recurso e o laboratório 2 estivesse sem utilização,alterava-se no balanceador de cargas o parâmetro que indica os servidores por laboratório,fazendo que os novos clientes fossem direcionados para o servidor que atende exclusivamenteo laboratório 2 e era pedido a alguns usuários que reiniciassem suas sessões. Com isso,o laboratório 2 passava a receber usuários do laboratório 1 e do laboratório 2. Além dotempo que se gastava em todo esse processo, isso trazia alguns outros inconvenientescomo: se o laboratório 2 estivesse com bloqueio de internet requisitado para ocasiões deprova, os usuários do laboratório 1, que estava lá por falta de recurso, tinham sua internetbloqueada.

A criação de novas máquinas virtuais (mesmo que houvesse recurso suficiente nohardware) e sua adição ao balanceador de cargas também não solucionava o problema, poisas sessões da virtualização de desktop permanecem no servidor onde ela foi criada. Porisso, se um servidor tem seus recursos sobrecarregados, as sessões que nele estão sentirão alentidão mesmo que o outro servidor seja inserido no balanceador de carga. Para que obalanceador ajude nesses casos é preciso que algumas sessões sejam reiniciadas para quesejam redirecionadas ao servidor com recursos mais livres.


Esse tempo gasto em contornar a sobrecarga de recursos pode atrapalhar o an-damento de uma avaliação, prejudicando todos os alunos e professor. A tecnologia devirtualização utilizada, a falta de monitoramento do ambiente e a tarefa manual de iden-tificar a sobrecarga em um dos laboratórios, verificar se há outros subutilizados, moveras requisições de novas sessões para outro laboratório com recursos mais livres tornavama tarefa demorada e trabalhosa. Como mencionado na Seção 2.1, alguns fabricantes tra-dicionais de virtualização possuem mecanismos para otimizar o uso de recursos, como ocompartilhamento de páginas idênticas de memória e compartilhamento de CPU, mas oredimensionamento dos recursos fica limitado a parâmetros pré-configurados, fazendo quepermaneça a necessidade do desligamento da máquina virtual para fazer o redimensiona-mento dos recursos.

Requisitos desejáveis para melhorar o ambiente: Baseado no cenário encontrado,foram identificados os seguintes requisitos para melhorar o fornecimento do serviço noslaboratórios:

1. Tecnologia de virtualização que permita o redimensionamento de recursos comomemória RAM, SWAP, CPU e disco em tempo de execução, sem a necessidadedesligar a instância virtual;

2. Monitoramento do ambiente por meio de uma ferramenta que forneça gráficos querepresentam o uso dos recursos dos laboratórios em tempo real;

3. Um sistema que administre o ambiente e tome decisões para solucionar a sobrecargade um laboratório, sem a necessidade do administrador ter que ficar monitorandovia terminal para perceber a sobrecarga. Esse sistema é necessário, pois mesmo coma adoção de outra tecnologia de virtualização que permita o redimensionamento derecursos e o monitoramento do ambiente, não garante que as instâncias terão seusrecursos gerenciados e adaptados de acordo com a utilização.

3.3 Evolução do serviçoApós o início deste trabalho foi feita uma evolução do serviço de virtualização

utilizado para criar os ambientes acessados nos laboratórios. Essa evolução foi motivadapelas dificuldades enfrentadas com o VMWare e foi o passo inicial no desenvolvimento daproposta de intervenção descrita nesse documento.

Diante das dificuldades enfrentadas com a solução implantada nos laboratórios deinformática da ECT, foram pesquisadas outras soluções de virtualização existentes que seadequassem aos requisitos listados e fossem compatíveis com a infraestrutura disponível.Como resultado dessa pesquisa chegou-se à conteinerização utilizando o OpenVZ. Alémde trazer todas as facilidades conhecidas de contêineres (como rápido provisionamento,


isolamento de ambientes, criação de snapshot, dentre outros), o OpenVZ possibilitaremanejar a quantidade de recursos entre contêineres em tempo de execução através desua API.

A proposta de redistribuir recursos entre contêineres de forma rápida e sem anecessidade de desligá-los se mostrou muito útil para nossa infraestrutura com recursos dehardware limitados para atender a todos os laboratórios. Apesar de não autogerenciar osrecursos dos contêineres sozinho, aumentando ou diminuindo de acordo com a carga, oOpenVZ permite através de sua API que isso seja automatizado.

Figura 10 – Funcionamento dos laboratórios com OpenVZ

A Figura 10 ilustra como ficou organizada a estrutura com a implantação doOpenVZ, seguindo a ordem que os componentes mais à direita representam a infraestruturae os mais à esquerda descrevem o serviço ofertado. Essa nova estrutura substitui a camadade virtualização do hypervisor e em seu lugar está instalado o sistema operacional DebianLinux e sobre ele o OpenVZ. Ao invés de máquinas virtuais, os contêineres fazem as vezesdos servidores de aplicações, mantendo a mesma lógica de funcionamento dos serviçosLTSP e do balanceamento de carga com LTSP-CLUSTER, dividindo cada laboratórioem grupos diferentes. Com isso, cada laboratório tem um servidor de aplicação destinadoa atender a carga de seus usuários. Os contêineres foram alocados com a quantidade derecursos com o intuito de distribuir os recursos do hardware de forma igualitária, sendo25% de CPU e 16 GB de memória RAM para cada laboratório. Com essa solução, é possívelrealocar memória (RAM e Swap) em tempo real entre contêineres. Também consegue-selimitar ou liberar o uso do CPU por contêiner e redimensionar a cota de espaço em discosem precisar desligar o contêiner ou encerrar as sessões dos usuários. Da forma como estáconfigurado, o balanceamento de carga enxerga apenas um servidor para balancear a carga,no entanto é possível adicionar novos servidores para fazer uso do balanceamento.

Dificuldades encontradas:

Com a migração do VMWare para o OpenVZ foi atendido um dos requisitos listados


na Seção 3.2 , referente à tecnologia que permitisse o redimensionamento de recursos emtempo de execução. No entanto, os outros requisitos continuaram sem solução. Apesar dapossibilidade de redistribuir recursos entre contêineres com eles executando, o OpenVZnão gerencia dinamicamente a cota de recursos alocada a um laboratório. Dessa forma,os usuários continuam sentindo a lentidão no ambiente quando o laboratório está muitoutilizado.

O problema do monitoramento também continuou sendo sentido, pois a ferramentanão possui dispositivo nativo que envie métricas de utilização dos contêineres e avise osadministradores do ambiente. Com isso, continuou a necessidade do professor se dirigir àequipe de TI para que o redimensionamento fosse feito.

Requisitos desejáveis para melhorar o ambiente: O requisito referente à tecnologiade virtualização foi atendido com a migração para o OpenVZ. Desse modo, os seguintesrequisitos ainda não foram atendidos:

1. Monitoramento do ambiente por meio de uma ferramenta que forneça gráficos querepresentam o uso dos recursos dos laboratórios em tempo real;

2. Um sistema que administre o ambiente e tome decisões para solucionar a sobrecargade um laboratório, sem a necessidade do administrador ter que ficar monitorandovia terminal para perceber a sobrecarga.

A adoção de uma tecnologia de virtualização que possibilita de forma simplificadao gerenciamento automatizado do ambiente por meio de uma API facilitou o atendimentodos demais requisitos. Para criar uma ferramenta que automatize essa tarefa era necessárioentender bem como os laboratórios são utilizados nas aulas.

Para entender os aspectos de utilização dos laboratórios foi elaborado um questio-nário destinado aos professores que os utilizam para ministrarem suas aulas. O objetivodesse questionário é saber quais disciplinas utilizam o ambiente Linux (pois o OpenVZsó hospeda os servidores com Linux), quais softwares são mais utilizados e quais são osrecursos computacionais mais requisitados por eles. Essas informações são relevantes paradefinir que tipo de redimensionamento o sistema proposto deverá se preocupar e quaisaulas são mais propensas a consumir todos os recursos do laboratório. Cada professor dasdisciplinas que acontecem nos laboratórios recebeu um e-mail contextualizando a pesquisa,qual seu objetivo e no cabeçalho do texto, havia seu nome, a disciplina ministrada e ohorário das aulas. É possível conferir o questionário no Apêndice E.

Cada questionário foi analisado e os dados tabelados com a identificação da dis-ciplina, o sistema operacional que será utilizado, o laboratório e os principais recursosutilizados.


Resultados da coleta: Foram enviados e-mails para os professores de 19 disciplinas (16pessoas diferentes) no total. Dessa quantidade foram obtidas informações referentes a 11disciplinas (10 pessoas). Na Tabela 1, os dados obtidos com o questionário estão agregadosem disciplinas, quais os principais programas utilizados nas disciplinas, quais recursos osprofessores apontaram como mais importantes, quais os sistemas operacionais utilizados eem qual laboratório acontece a disciplina.

Disciplinas Programasutilizados

Recursosutilizados

Sistemaoperacional Laboratórios

CN3 Scilab MemóriaProcessador Ambos Lab3

PROTOTIP. SolidWorks,fritzing e Eagle

MemóriaProcessador Windows Lab4

POO Java (IDE: NetBeans)Astah Memória Linux Lab4

LiP2 Codeblocks Processador Linux Lab2

LiP3 CodeblocksMemória

ProcessadorDisco

Linux Lab2Lab3

LiP5 g++ e Codeblocks MemóriaProcessador Ambos Lab2

Lab3

MICRO. Arduino MemóriaProcessador Windows Lab3

LoP2 Geany e CodeBlocks Memória Linux Lab2

LoP3 Codeblocks ProcessadorRede Linux Lab2

LoP4 Code Blocks,Firefox, gcc

ProcessadorMemóriaRede

Linux Lab2

LoP5 Code Blocks,Firefox, gcc

ProcessadorMemóriaRede

Linux Lab2

Tabela 1 – Concatenação dos dados obtidos no questionário aos professores

A coluna Disciplinas da Tabela 1 contém as abreviações de cada disciplina. Ondese lê CN3, leia-se Computação Numérica 3. O mesmo segue para Prototip. (PrototipagemMecânica Rápida e de Circuitos), POO (Programação Orientada à objetos), LiP (Lingua-gem de Programação, MICRO. (Projetos com Microcontroladores e Minicomputadores) eLoP (Lógica de programação).

Para facilitar a visualização das respostas obtidas, na Figura 11 consegue-se identi-ficar que os recursos mais utilizados pelas disciplinas são memória e CPU, de acordo coma percepção dos professores. O Linux apareceu como o sistema mais utilizado, justamenteo sistema operacional possível de gerenciamento dos recursos com a ferramenta idealizada.


Figura 11 – Gráficos representativos das respostas obtidas no questionário

O último gráfico demonstra o grau de certeza que cada professor tem sobre quais recursosmais impactam em suas aulas.

O que foi entendido do ambiente dos laboratórios com essa pesquisa é que osprofessores apontam o processador e a memória RAM como principais recursos utilizadosem suas aulas e, portanto, os que podem comprometer a boa realização da aula se elesestiverem sobrecarregados.

3.4 Considerações finaisNeste capítulo foram detalhadas as tecnologias de virtualização e DaaS utilizadas

na ECT para atender o serviço de virtualização de desktops nos laboratórios de informática,bem como a infraestrutura de hardware que é utilizada. Foram listadas as dificuldadesencontradas nas soluções implantadas e quais os requisitos desejáveis para que seja ofertadoum bom serviço de acesso remoto nos laboratórios. Por fim, foi exibido o questionário quebuscou entender a forma que os laboratórios são utilizados para ajudar no desenvolvimentode uma ferramenta que auxilie na administração do ambiente.

42

4 Projeto ConManager

Este Capítulo apresenta uma visão geral da ferramenta desenvolvida para o geren-ciamento do ambiente DaaS implantado nos laboratórios da ECT chamado ConManager.Inicia-se por uma visão geral da arquitetura descrita em figuras, diagramas UML erequisitos, seguido do detalhamento do projeto. Esse detalhamento descreve todas ascaracterísticas do sistema, abordando o tema na sequência proposta pelo padrão MAPE-K.

4.1 Visão geral da arquitetura do ConManagerO ConManager é um controlador autoadaptativo para ambientes baseados em

contêineres e tem como propósito o redimensionamento dinâmico de recursos virtualizadose balanceamento de cargas para lidar com demandas de carga sazonais. Uma visão geral doConManager é apresentada na Figura 12, aproveitando a arquitetura exibida na Figura 10e mesclando as camadas de hardware e sistema operacional para facilitar o entendimentodas camadas que compõem o ambiente controlado. A camada de Hardware/S.O. representao servidor físico que hospeda toda a infraestrutura de contêineres, bem como o sistemaoperacional instalado para suportar o gerenciador de contêiner. Esta camada é observadaatravés de sensores (Sensor) que se comunicam diretamente com o módulo Monitordo ConManager. Cada servidor físico alocado ao ambiente contém um Gerenciador decontêiner, que permite consultar (Sensor) e manipular (Effector) os contêineres ativosnaquele servidor. Sobre o gerenciador, diversos contêineres são organizados em grupos, deforma a atender ao requisito de isolamento entre diferentes laboratórios (ou aplicações). Osdiversos contêineres também podem ser monitorados (Sensor). Os grupos são utilizados peloBalanceador de carga, que distribui as requisições recebidas dos usuários nos laboratórios(camada LTSP) entre os contêineres de seu respectivo grupo. O balanceador de cargatambém pode ser consultado (Sensor) ou manipulado (Effector), permitindo assim aadição/remoção de contêineres em grupos.

O controlador segue em sua arquitetura as fases do Mape-K, consoante Weynset al. (2013) - como está ilustrado na Figura 12 - as caixas que representam os módulosdo ConManager. A primeira fase do MAPE-K é a de monitoramento do ambiente (Mo-nitor). Desse modo, o ConManager monitora a camada física do servidor, a camada decontêinerização, os contêineres e o balanceador de carga. Na camada de Hardware/S.Osão monitorados os parâmetros de utilização de CPU, memória RAM/SWAP, e disco.Na camada do gerenciador de contêiner, sensores coletam dados referente aos contêineresativos e suas respectivas configurações de alocação de recurso (CPU, memória RAM, Swape disco). Na camada seguinte são monitorados, para cada contêiner, os parâmetros de

Capítulo 4. Projeto ConManager 43

Figura 12 – Visão geral da arquitetura conceitual do Conmanager.

utilização de CPU, memória e disco, além da quantidade de sessões ativas (usuários loga-dos). Na camada de balanceamento o monitoramento acompanha os grupos de contêineresconfigurados em cada grupo. A fase de análise (Analyze) tem como objetivo identificar nosdados fornecidos pelo monitoramento se algum contêiner está sobrecarregado e, com isso,emitir um alerta à fase de planejamento.

A fase de planejamento (Plan) é responsável por decidir o que será feito pararesponder à situação identificada, produzindo um plano de adaptação que traça as açõesa serem implementadas no ambiente controlado. Um plano de adaptação é definidobaseado em um conjunto de regras que capturam o processo de tomada de decisão de umadministrador para adequar a quantidade de recurso em um contêiner de acordo com ademanda exigida. Para isso, devem ser levados em conta a prioridade do contêiner emrelação aos demais (se pode ou não retirar recusos), o status de utilização do hardware erestrições de acréscimo e decréscimo de recursos. E por fim, a fase de execução (Execute)tem a responsabilidade de efetivar as mudanças definidas na fase anterior. É necessário queo sistema esteja integrado com mecanismos capazes de realizar as alterações necessárias. OConManager atuará na camada de gerenciador de contêiner, fazendo o redimensionamentode recursos entre os contêineres e na camada balanceamento de carga, habilitando ainserção/remoção de novos servidores de aplicação no ambiente que atende os laboratórios.As quatro fases são apoiadas por uma base de conhecimento compartilhada (Knowledge).


4.2 Elicitação de requisitosPara chegar na arquitetura do ConManager, utilizamos na fase de elicitação de

requisitos o trabalho feito por Salehie e Tahvildari (2009), que traz um estudo sobresoftwares autoadaptativos. Nele são detalhadas as características e aspectos que o de-senvolvedor deve levar em consideração no instante do desenvolvimento desse tipo desistema, além de apresentar uma metodologia de elicitação de requisitos voltada para ossoftwares autoadaptativos. Através das conhecidas perguntas: Onde, Quando, O quê, Porquê e Como. Sendo que as respostas precisam estar inseridas no contexto de softwaresautoadaptativos, levando em consideração suas características na hora do levantamentodos requisitos. Será dado um exemplo de um requisito de cada pergunta abaixo, enquantoque todos os requisitos elicitados podem ser conferidos no Apêndice A.

Onde: Quais artefatos e em quais camadas ocorrerão as mudanças? Quais outras camadasdo software, em que nível de granularidade que essa mudança precisa acontecer?

Estes requisitos estão organizados de acordo com as camadas identificadas noambiente. Por exemplo:

Camada: Hardware/S.O.: Os dados que deverão ser coletados diretamente dohardware/ sistema operacional são:

1. Processamento

• Porcentagem de utilização do CPU: Porcentagem ocioso, Utilizado por usuários,Utilizado pelo sistema, Espera IO;

• Carga de processamento (load average): Carga média do último minuto, Cargamédia dos últimos 5 minutos, Carga média dos últimos 15 minutos;

• Quantidade de núcleos do processador

Quando: São levados em consideração os aspectos temporais, por exemplo: a mudança éfactível para aquele momento ou ela acarretará sobrecarga no sistema? Há restrições paramudanças a qualquer momento? Por exemplo:

• A adaptação acontecerá em duas camadas: Na camada do gerenciador de contêineracontecerá de forma reativa, quando um dos servidores de aplicação estiver sobrecar-regado e de forma proativa quando o ConManager, baseado na tabela de horários eno histórico de intervenções para aquela aula, redimensionar os recursos para umvalor que melhor atenda a demanda. Na camada do balanceador de cargas aconteceráquando um contêiner é incluído ou excluído nos grupos de balanceamento.

O quê: Com essa questão é possível identificar quais atributos ou artefatos de um sistemapodem ser mudados com ações de adaptação e qual mudança é necessária em cada uma


das situações. Que artefatos se deve considerar? Tenho outras alternativas para executaras mudanças?

Esses requisitos também estão organizados em camadas, por exemplo:

Camada: Gerenciador de contêiner: Os artefatos que podem sofrer alteração nacamada de gerenciador de contêiner são:

1. Contêineres ativos

• Criar contêiner. Checar na listagem dos contêineres.

• Excluir container. Checar na listagem dos contêineres.

• Iniciar contêiner. Checando o número de contêineres executando.

• Parar executando. Checando o número de contêineres rodando.

Por quê: Essa pergunta deve ser respondida com as motivações que se tem para construirum software autoadaptativo. Esse tipo de pergunta serve para definir os objetivos dosistema como robustez, disponibilidade, confiabilidade, etc. Por exemplo:

• A abordagem escolhida para solucionar o desafio de criar e gerenciar vários servidoresde aplicação que atendessem o ambiente de acesso remoto montado nos laboratóriosde informática foi a utilização de contêineres compartilhando recursos do hardware.Por esse fato, há sobrecarga de recursos em alguns servidores, enquanto em outros orecurso é subutilizado, gerando perda de desempenho nos computadores do labora-tório com muita utilização. O ConManager é um sistema que monitora o uso dosservidores e autoadapta o provisionamento dos recursos entre instâncias para provero melhor aproveitamento deles, otimizando os recursos do hardware.

Quem: Aqui foi definido o grau de automação e o envolvimento humano no software.Nesse tipo de sistema, espera-se que o humano tenha a mínima intervenção possível,uma vez que o sistema deve ser capaz de se ajustar às diferentes situações em tempo deexecução. Mesmo que a intervenção humana seja mínima, essa interação do sistema comos proprietários e gestores é necessária para construir confiança e definição das regras denegócio. Por exemplo:

• O ConManager deverá ser capaz de seguir as fases determinadas pelo Mape-K demaneira autônoma. No entanto, o sistema deve ser capaz de prover o máximo deinformações que auxiliem o administrador nos casos que a intervenção humana fornecessária. Essa intervenção consiste na adaptação dos recursos dos contêineres eadaptação do serviço de balanceamento de cargas. Para isso, é necessário que osistema avise ao administrador que há sobrecarga de recursos, exiba a quantidade de


recursos distribuída entre os contêineres, exiba também os gráficos de utilização doambiente, além da tabela de horário das aulas. Essas informações auxiliarão a tomara decisão mais acertada.

Como: Por fim, é descrito como as ações de adaptação ocorrerão no ambiente. Sãomapeadas as possíveis condições que o sistema enfrentará em tempo de execução e decididose a mudança é apropriada dada as condições vigentes e os possíveis impactos de cadaação. Por exemplo:

1. Reiniciar servidor de aplicação

• Descrição da ação: Essa ação reinicia um servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ser reiniciado;

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamadaprecisa ser realizada para reiniciar o servidor de aplicação indicado.

– Vzctl restart $id;

• Pré-condição: O servidor deve estar com o status “running”.

• Pós-condição: O servidor é reiniciado, logo todos seus processos são reiniciados.

Ainda na fase de análise do software, a criação dos diagramas de casos de usoauxiliou na tarefa de pensar nas funcionalidades do sistema, como o usuário iria interagircom os componentes antes mesmo deles serem desenvolvidos. Esse diagrama mostra asfuncionalidades do sistema e a ordem sequencial que eles são exibidos neste documento é amesma que deve ser obedecida na configuração do ConManager, bem como a demonstraçãode sua utilização para gerenciar o ambiente. Todos os casos de usos podem ser conferidosno Apêndice B.

4.3 Detalhamento do projetoEsta seção tem como objetivo detalhar como estão estruturados os módulos do

ConManager. As funcionalidades do sistema serão esclarecidas através de diagramas,tabelas e fluxogramas.

A Figura 13 apresenta os componentes utilizados no cenário, implementando omodelo conceitual exibido na Figura 12. Como pode-se perceber sobre a camada Hard-ware/S.O., o OpenVZ é a tecnologia de virtualização que permite o gerenciamento dasinstâncias virtuais que atendem os laboratórios. Para realizar o monitoramento dos recursos


computacionais tanto na camada do Hardware/S.O como nos servidores de aplicação, éfeito o uso do Zabbix1, uma ferramenta de código-aberto que faz o monitoramento devários parâmetros na rede e em servidores; Em cada um dos ambientes monitorados há umagente Zabbix que fica em constante comunicação com o servidor enviando métricas deutilização. Esses dados coletados são consumidos pelo módulo de análise através da APIdisponibilizada pelo Zabbix, além de possibilitar o envio de comandos para realizar confi-gurações a partir do ConManager. O módulo de análise também coleta dados referentes àtabela de horário das aulas que é alimentada no Google Agenda e é consumida atravésda API disponibilizada pelo próprio Google. Os dados coletados do Zabbix e da agendaservem para o módulo de análise identificar se há sobrecarga em um dos laboratóriose enviar os dados organizados para que o módulo de planejamento consiga traçar asações de redistribuição de recursos entre os servidores de aplicação. Após a tomada dedecisão de quais procedimentos adotar, o módulo de planejamento aciona as APIs doLTSP-CLUSTER ou do OpenVZ (que executam as instruções via SSH), registrando nobanco de dados cada ação tomada como uma intervenção. Todas essas atividades podemser acompanhadas através de uma interface Web, onde o administrador pode intervir nosistema. O funcionamento detalhado de cada módulo serão descritos nas subseções adiante.

Figura 13 – Visão dos componentes que compõem o ConManager.

A sequência de implantação do sistema iniciou com o módulo de monitoramento.Em seguida foi construído o módulo de execução, possibilitando aos administradoresmanipular os contêineres através do ConManager. A próxima fase implementada foi a de1 <www.zabbix.com>

www.zabbix.com


análise com o disparo de alarmes e a integração com a agenda de horários. A última faseimplantada foi a de planejamento, poupando o administrador da tarefa de analisar osgráficos, tabela de horários e status dos servidores de aplicação e automatizando a tomadade decisão.

O Apêndice D contém os diagramas de sequência que mostram a interação entreos componentes exibidos na Figura 13. Os diagramas estão divididos de acordo com asfases do Mape-K, dessa forma foi criado um diagrama com os componentes responsáveispelo monitoramento, um diagrama para a análise e outro diagrama para o planejamento eanálise.

As próximas subseções detalham as quatro fases do MAPE-K.

4.3.1 Monitoramento

Como ferramenta de monitoramento foi explorado o Zabbix. Desse modo, cadaservidor de aplicação, assim como os servidores físicos, são monitorados por um agenteZabbix que obtém os dados de utilização de recursos (com o intervalo configurável) earmazena em uma base de dados. Quase todas as configurações do Zabbix são feitas atravésdo ConManager, que abstrai detalhes relacionados a definição de agentes e parâmetrosdo Zabbix para o administrador, simplificando assim o monitoramento de novos servido-res. Com isso, basta ao administrador cadastrar informações relacionadas ao ambientecontrolado, como por exemplo, endereço IP e credenciais de acesso do servidor físicoe do balanceador de carga LTSP-CLuster. Com base nesta informação, o ConManageridentifica todos os contêineres disponíveis e permite ao administrador adicionar agentesa esses contêineres, além de permitir a vinculação de servidores de aplicação a gruposdo LTSP-Cluster. Das funcionalidades que o ConManager utiliza do Zabbix, as únicasque não se pode fazer a partir do sistema é a configuração de gatilhos (Triggers) e ações(Actions)2 .

4.3.2 Análise

Parte da análise do ConManager é implementada pelo Zabbix. O mecanismo dedisparo dos gatilhos no Zabbix é combinado com a definição status de utilização de cadaservidor no ConManager e dessa forma é provida à fase de planejamento as informaçõesnecessárias para a tomada de decisão. Os gatilhos devem ser definidos junto com uma action,esta configurada para notificar o ConManager via script, pelo administrador do ambienteno Zabbix. Com isso, a ferramenta de monitoramento está apta a notificar o módulo deanálise nos instantes que os recursos atingem níveis acima dos valores configurados, dandoassim a sua ativação. Cada ativação de Triggers no Zabbix vira um alarme no ConManager2 Uma Action é um conceito do Zabbix, seu papel é dar encaminhamento da notificação enviando-a por

e-mail, mensagem de celular ou acionar um script.


e a partir dele o planejamento é ativado. São dois os momentos que o Zabbix notifica oConManager sobre uma sobrecarga. O primeiro é quando a sobrecarga é percebida e éenviada uma mensagem com o status (problem), juntamente com dados que identificam aorigem, o horário, a quantidade de recurso disponível, etc. A segunda mensagem é enviadaquando o ambiente não está mais sobrecarregado, com isso é enviada uma mensagemcom o status (ok). O ciclo de vida de um alerta no ConManager está relacionado com orecebimento dessas mensagens. O alerta aciona o módulo planejamento e só é encerradoquando o Zabbix notifica a resolução.

Os limites de utilização dos recursos para disparar um gatilho foram definidosbaseando-se na experiência da equipe que administra o ambiente, que elencou os parâmetrosmonitorados e quais as condições necessárias para que seja considerada sobrecarga. Alémdisso, existe um cronograma para cada disciplina ao longo do semestre, no qual os horáriose datas de cada aula são armazenados no Google Agenda. O módulo de análise usa aAPI do Google agenda para obter os horários das aulas de cada laboratório. Quando umasituação de sobrecarga é detectada pelo Zabbix, o módulo de análise é ativado coletandoinformações acerca do estado atual do ambiente, tabela de horários e aciona o módulo deplanejamento.

4.3.2.1 Definição de gatilhos

Através da definição dos limites de cada recurso monitorado é possível interpretaros dados coletados e avisar o ConManager que há a necessidade de uma intervençãono ambiente. A configuração das triggers foram implementadas apenas nos agentes quemonitoram os servidores de aplicação que atendem os laboratórios (sejam de aula ou deuso geral). Quais recursos que disparam os gatilhos e os valores limites que são entendidoscomo sobrecarregados foram definidos com base na experiência da equipe de TI queacompanha o comportamento dos laboratórios, tem contato com os professores que osutilizam para ministrar aulas e até mesmo visitas nos laboratórios para sentir o desempenhodas máquinas de acordo com o nível de utilização dos recursos.

As triggers disparam um aviso ao ConManager quando algum dos recursos configu-rados ultrapassa o limite estipulado, persistindo por um intervalo de tempo que caracterizaa sobrecarga. É possível que exista mais de uma trigger por recurso (como é o caso daCPU). A necessidade de criar mais de um gatilho por recurso é a existência de diferentesparâmetros que indicam a sobrecarga na CPU, como o nível de utilização por processos deusuário, processos do sistema, tempo de espera para operações de entrada e saída (I/O) ecarga de processamento. A Tabela 2 exibe a relação de triggers configuradas.


Nome da TriggerCpu system time (processos do sistema)acima dos 50% por mais de 5 minutos

Cpu user time (processos de usuários acimados 70% por mais de 5 minutos

Cpu Iowait (operações de entrada e saída)maior que 20% por mais de 5 minutos

Memória RAM menor que 20% por maisde 5 minutos

Cpu load (carga de processamento) acima de 5por mais de 5 minutos

Espaço em disco menor que 20% do volume

Tabela 2 – Configuração de Triggers

4.3.2.2 Status de utilização dos servidores

O módulo de análise também tem a responsabilidade de organizar os dados coletadospara facilitar a tomada de decisão no módulo de planejamento. Pensando nisso, foramcriados os status de utilização dos servidores de aplicação e hardware. Os status representamo nível de utilização dos laboratórios de acordo com os dados coletados pelo Zabbix. OConManager faz uma consulta ao banco do Zabbix através de sua API, coleta os dados,compara com os intervalos configurados pelo administrador do ConManager e assimconsegue indicar se os laboratórios estão sobrecarregados ou subutilizados. Com basenesses status será possível criar regras para auxiliar o módulo de planejamento na tomadade decisão.

Assim como a configuração dos gatilhos, os parâmetros que indicam os status foramdefinidos de acordo com a experiência da equipe no gerenciamento desse ambiente. Cadastatus leva em consideração mais de um tipo de recurso para apontar o resultado. NaTabela 3 são exibidos os status criados, contendo os nomes de cada um e as condiçõesnecessárias para o ConManager identificar o nível de utilização dos laboratórios. Em cadaexpressão são utilizados operadores lógicos como && (quando as duas expressões foremverdadeiras), < (menor que),> (maior que),<= (menor ou igual que),>= (maior ou igualque),|| (quando uma ou outra expressão for verdadeira) e as representações dos parâmetrosmonitorados como sessões de usuários (usuarios), tempo ocioso do Cpu (Cpu_idle_time),memória RAM livre (ram_livre), carga de CPU (Cpu_load), tempo de CPU utilizado porprocessos de usuários (Cpu_user_time), quantidade de espaço em disco (disco_livre).

O módulo de planejamento do ConManager precisa levar em consideração antes defazer qualquer tipo de redimensionamento de recursos entre contêineres o estado do servidorHardware. Diante dessa necessidade, foram criados exclusivamente para o Hardware maistrês tipos de status (exibidos na Tabela 4), porém, ao invés de como foi implementadonos servidores de aplicação, no hardware os recursos de CPU, RAM e disco possuem


Nome do status Condição

Subutilizado(usuarios <5 && Cpu_idle_time >90% &&

ram_livre >= 90% && Cpu_load <1)por mais de 15 minutos

Pouco uso

( (usuarios >= 5 && usuarios <= 15) ||(Cpu_user_time >= 10% && Cpu_user_time <= 40%) ||

(Cpu_load >= 1 && Cpu_load <= 2) ||(ram_livre >= 60% && ram_livre <90%) ||(disco_livre >= 50% && disco_livre <65%) )

por mais de 5 minutos

Bem utilizado

( (usuarios >15 && usuarios <= 30) ||(Cpu_user_time >40% && Cpu_user_time <= 70%) ||

(Cpu_load >2 && Cpu_load <= 6 ) ||(ram_livre >= 20% && ram_livre <60%) ||(disco_livre >20% && disco_livre <50%) )

por mais de 5 minutos

Sobrecarregado

( (usuarios >30%) ||(Cpu_user_time >70%) ||

(Cpu_system_time >50%) ||(Cpu_iowait_time >20%) ||

(ram_livre <20%) ||(Cpu_load >6) ||

(disco_livre <20%) )por mais de 5 minutos

Tabela 3 – Status de utilização dos servidores de aplicacao

três possíveis status. O "verde"indica que o nível de utilização do recurso está baixo nohardware (mesmo que para um laboratório esse recurso esteja sobrecarregado), o status"amarelo"indica que o nível de utilização desse recurso está razoavelmente bem utilizado epor fim, o status "vermelho"indica que esse recurso está sobrecarregado.

4.3.3 Planejamento

O módulo de planejamento tem o objetivo de tomar decisão sobre o que fazer pararesponder à situação detectada. Ele recebe as informações do módulo de análise como:o laboratório sobrecarregado, o recurso, os status de utilização dos outros laboratóriose do hardware e a tabela de horário das aulas. Com base nisso, são aplicadas as regraspreviamente definidas para nortear o módulo na tomada de decisão.

Assim como os status auxiliarão o módulo de planejamento na tomada de decisão,foram criadas as restrições de redimensionamentos para serem consideradas nessa etapa.Essas restrições visam garantir que não serão retirados de um servidor de aplicação umaquantidade de recursos que pode comprometer sua utilização e nem permitirá que umlaboratório monopolize todos os recursos disponíveis no hardware. As restrições variam de


Recurso /Status Verde Amarelo Vermelho

CPU

(Cpu_user_time <= 45%)||

(Cpu_system_time <= 35%)||

(Cpu_load <= 12)

(Cpu_user_time >45%&&

Cpu_user_time <= 85%)||

(Cpu_system_time >35%&&

Cpu_system_time <= 70%)||

(Cpu_load >12&&

Cpu_load <= 25)

(Cpu_user_time >85%)||

(Cpu_system_time >70%)||

(Cpu_load >25)

RAM (ram_livre >= 60%)(ram_livre >= 15%

&&ram_livre <60%)

(ram_livre <15%)

Disco (disco_livre >= 40%)(disco_livre >= 10%

&&disco_livre <40%)

(disco_livre <10%)

Tabela 4 – Status de utilização do servidor hardware

acordo com o tipo do servidor de aplicação (se ele é destinado às aulas ou de uso geral),dos status de utilização dos servidores de aplicação e se ação é para retirar ou inserirrecursos. Por exemplo:

Quando o status do contêiner a ter recursos retirados for "subutilizado":

• Cpu: Não pode ficar com menos de 200 cpulimit (12.5% do hardware)

• Ram: Não pode retirar mais que 50% da quantidade original alocada

• Disco: Não pode retirar mais que 20% da quantidade original alocada

A lista de restrições implementadas estão no Apêndice F.

Duas abordagens foram consideradas para implementar o processo de tomada dedecisão do módulo de planejamento. A primeira abordagem foi o raciocínio baseado emcasos (Case Based Reasoning - CBR) que consiste em técnicas de resolução dos problemasbaseando-se casos semelhantes que aconteceram no passado, de acordo com Maurer,Brandic e Sakellariou (2013). Ainda no processo de desenvolvimento foram feitos exercíciosque simulavam os possíveis cenários de adaptação utilizando o CBR para resolvê-los. Combase nesses exercícios houve dificuldade para reusar as informações e conhecimentos decasos similares para resolver o problema. A outra abordagem utilizada foi a baseada emregras, na qual são introduzidas várias políticas que armazenam o conhecimento da equipee reflete as decisões que são consensuais na administração do ambiente. A abordagembaseada em regras foi utilizada, pois foi a que melhor conseguiu captar a experiência dosadministradores para reproduzi-la no instante da tomada de decisão.


4.3.3.1 Processo de tomada de decisão do módulo de planejamento

Quando um alarme é acionado, a análise envia os dados referentes à utilização dosservidores e a tabela de horários das aulas para o módulo de planejamento que decidirá qualo plano de ação para adaptar os recursos dos laboratórios para solucionar a sobrecarga. Noplanejamento foram implementados dois níveis de tomada de decisão. O primeiro nível levaem consideração os horários das aulas, os status dos servidores de aplicação, as restriçõesde acréscimo e decréscimo de recursos e qual horário que será revertida a adaptação. Osegundo nível é o responsável por chamar o módulo de execução para implementar asmudanças, definindo a quantidade de recursos que será redimensionada e para consulta ostatus de utilização do hardware.

4.3.3.2 Primeiro nível de tomada de decisão

Abaixo serão listadas as regras definidas para o primeiro nível de tomada de decisãono módulo de planejamento. Essas regras capturam o conhecimento da equipe de TI,adquirido com o manuseio do ConManager manualmente. O fluxograma da Figura 14ilustra como essas oito regras foram aplicadas no algoritmo.

1. O planejamento não tomará decisões quando o recurso sobrecarregado for disco.

2. Os contêineres destinados à aulas têm prioridades sobre os de uso geral.

3. Em caso de sobrecarga no contêiner destinado ao laboratório de uso geral, só haveráredistribuição de recurso se houver algum laboratório com o status “subutilizado”.Caso contrário, o planejamento deverá ignorar o alerta.

4. Caso a sentença acima seja verdadeira, deverá ser escolhido o contêiner com o fimde aula mais distante para ter seus recursos diminuídos, programando a reversãodas configurações para o horário do início da aula. Se não houver aula programadadeverá ser revertido quando o turno acabar (12:30 para o matutino, 18:30 para ovespertino e 22:30 para o noturno).

5. Em caso de sobrecarga em contêineres destinados às aulas, só haverá redistribuiçãode recursos se houver algum laboratório para aulas com status “subutilizado” ou“pouco uso” ou quando o laboratório de uso geral estiver com o status “subutilizado”.Caso contrário, o planejamento deverá ignorar o alerta.

6. Caso a sentença acima for verdadeira e existir mais de um contêiner com status“subutilizado”, escolher o contêiner sem aula acontecendo para fazer a redistribuiçãodos recursos, revertendo as configurações ao final da aula do contêiner sobrecarregado.Quando não houver contêiner sem aula, escolher o contêiner com o fim da aula mais


distante, revertendo as configurações quando a aula do contêiner sobrecarregadoacabar.

7. Quando houver sobrecarga em um dos laboratórios para aulas e existir apenaslaboratórios com status “pouco uso”, deverá ser levado em consideração a quantidadede recurso disponível e será escolhido para a redistribuição o contêiner que tiver amaior quantidade de recursos livres. As configurações deverão ser revertidas ao finalda aula do laboratório sobrecarregado.

8. Para casos de sobrecarga de recursos em um dos laboratórios para aula e não houveroutros contêineres com status “subutilizado” ou “pouco uso”, deverá ser checado seo laboratório de uso geral está com o status “subutilizado”. Caso afirmativo, seráfeita a redistribuição dos recursos revertendo as configurações ao final da aula dolaboratório sobrecarregado. Caso contrário, o planejamento deverá ignorar o alerta.


Figura 14 – Fluxograma do primeiro nível de tomada de decisão


4.3.3.3 Segundo nível de tomada de decisão

O segundo nível de tomada de decisão se preocupa com o status de utilização dohardware. Devido aos limites impostos pelo provisionamento de recurso, muito provavel-mente uma ocasião de sobrecarga de recursos em um contêiner não significará que esserecurso está sobrecarregado no hardware. Por esse motivo foi desenvolvido um segundonível na tomada de decisão, pois além de verificar o status, esse nível é o responsávelde indicar quais ações o administrador deverá executar. Abaixo serão listadas as regrasobedecidas por esse nível de tomada de decisão e a Figura 15 ilustra como está o algoritmoque aplica essas quatro regras. Essas regras não contemplam modificações no LTSP-Clustere os valores definidos levam em consideração o hardware utilizado no estudo de caso. Aquantidade manipulada de recursos em cada adaptação foi definida de acordo a experiênciada equipe que gerencia o ambiente e com os testes realizados no período de avaliações.

1. O planejamento tomará decisão de redimensionamento de recursos como CPU ememória RAM.

2. Será feito redimensionamento apenas quando o status do recurso sobrecarregado nolaboratório estiver “verde” ou “amarelo” no hardware. Caso contrário, o alerta seráignorado.

3. Quando o recurso sobrecarregado for CPU e o status do hardware estiver “verde” paraCPU, adicionar mais 18.75% de CPULimit se o contêiner não tiver intervenção emaberto ou 6.25% caso já exista intervenção. Se o status do hardware estiver “amarelo”para CPU, adicionar 12.50% de CPULimit se o contêiner não tiver intervenção emaberto ou 6.25%, caso já exista intervenção.

4. Quando o recurso sobrecarregado for memória RAM e o status do hardware estiver“verde” para RAM, adicionar 30% de RAM se o contêiner não tiver intervenção emaberto ou 6.25% caso já exista intervenção. Se o status do hardware estiver “amarelo”para RAM, adicionar 20% de RAM se o contêiner não tiver intervenção em abertoou 6.25%, caso já exista intervenção.


Figura 15 – Fluxograma do segundo nível de tomada de decisão

4.3.4 Execução

O módulo de execução recebe do planejamento um conjunto de ações que devem seraplicadas no ambiente através da API do OpenVZ (para casos que envolvam redimensiona-mento de recurso) ou da API do LTSP-Cluster (para casos que envolvam balanceamentode carga). No ConManager, cada ação que manipula o ambiente monitorado é chamada deintervenção. Cada intervenção realizada pelo ConManager é registrada, com um conjuntode informações sobre a mudança realizada, tais como o tipo de recurso (ex. memória, CPU,disco), o servidor de aplicação, a quantidade de recurso manipulada e ação (inserir ouretirar). Desse modo, a resposta para uma situação de sobrecarga pode envolver diversasintervenções encadeadas.

Quando uma intervenção é feita, ela fica com o status "em aberto"até que seja re-vertida ou consolidada. Quando revertida, as configurações feitas voltam ao estado anteriore ao consolidar uma intervenção, o administrador está fazendo com que o ConManagerassuma os novos valores como valores de referência. Por exemplo, se houve uma intervençãono laboratório 3, aumentando a memória RAM de 10 GB para 12 GB, o valor que oConManager entende como alocado para o laboratório 3 é de 10 GB. Caso a intervençãoseja revertida, o sistema manipula o contêiner para que ele fique com os 10 GB iniciais.Caso a intervenção seja consolidada, o ConManager entende que de agora em diante olaboratório 3 terá 12 GB de memória RAM como valor referência.

O LTSP-Cluster tem papel fundamental para que o ConManager entenda a organi-


zação dos servidores em grupos (que constituem os laboratórios). O arquivo de configuraçãoé lido para que seja possível organizar no ConManager os servidores de aplicações cadas-trados. As alterações de organização dos servidores devem ser atualizadas no sistema epara isso se faz necessária a manipulação do serviço a partir do ConManager. A tarefa deadicionar ou retirar novos servidores não acontece com frequência, mas é um ponto quedeve ser considerado para a escalabilidade da solução.

A base de conhecimento do ConManager reúne os dados que representam o ambienteDaaS implementado no cenário da ECT. As informações contidas na base são usadas parao acesso às APIs na infraestrutura que compõe o ConManager, bem como os alertas eadaptações feitas para solucionar as ocasiões de sobrecarga.

4.4 Considerações finaisEsse Capítulo detalhou o projeto ConManager desde a sua concepção, com elicitação

de requisitos, diagramas UML e todos os aspectos da engenharia do software. Foi abordadotambém cada característica do sistema implementado, especificando o funcionamento decada fase do MAPE-K presente no ConManager.

59

5 Implementação

O objetivo deste capítulo é descrever como o ConManager foi aplicado no geren-ciamento da infraestrutura dos laboratórios de informática da ECT. Serão descritos osdetalhes da implementação e feito um demonstrativo de algumas telas do sistema.

5.1 Detalhes da implementaçãoO ConManager foi desenvolvido em PHP com uma arquitetura simplificada baseada

em camadas com uso de padrões de projeto como o Data Access Object (DAO) e o Singleton,sem a utilização de qualquer framework, utilizando-se de um banco de dados Mysql1. Seudesenvolvimento se deu em fases, inicialmente com o objetivo de permitir o monitoramentoe manipulação do ambiente de contêineres montado nos laboratórios de informática da ECT.Em seguida, foram adicionadas as funcionalidades de análise, permitindo a identificaçãode situações de sobrecargas. Por fim, foi considerada a fase de planejamento, de modo aauxiliar na tomada de decisão acerca de como responder à sobrecarga identificada. Porainda estar em fase de homologação, o módulo de planejamento está funcionando de forma"semi-automática", ou seja, é preciso que o usuário administrador através da interfaceWEB, clique em um botão para chamar o módulo de planejamento.

Para representar como as classes se relacionam para implementar as funcionalidadesdo ConManager, foram criados quatros diagramas de classes. Todos os diagramas podemser conferidos no Apêndice C. Por ter uma arquitetura em camadas, elas estão organizadasde forma que a primeira camada é responsável pela interface com o usuário, a segunda temo papel de implementar as regras de negócio e atender as requisições do usuário, enquantoque a terceira é responsável pela persistência dos dados.

O monitoramento no ConManager se dá através da utilização do Zabbix versão2.2.2 e a instalação de seus agentes em cada ambiente monitorado. O Zabbix disponibilizauma API que viabiliza o consumo dos dados e até a manipulação de configuração a partirdela. Dessa forma o ConManager está integrado ao Zabbix, consumindo os últimos dadoscoletados e alterando configurações como a criação de agentes. Para isso, foi implementadauma classe que reúne os métodos necessários para o consumo da API. Na interface gráficado ConManager, ainda na fase de configuração inicial, é preciso cadastrar as informaçõesde acesso ao Zabbix e depois adicionar todos os agentes que já monitoram o ambiente,caso exista algum. Ainda nessa fase, é preciso indicar as credenciais do servidor hardwaree automaticamente o ConManager captura informações referentes aos recursos existentes1 <https://www.mysql.com/>

https://www.mysql.com/

Capítulo 5. Implementação 60

e traz todos os dados dos contêineres existentes. Fazendo-se necessário o cadastramentodeles. Essas instruções são executadas através de conexão SSH e requer que o usuário doConManager tenha privilégios de administrador no sistema operacional.

O sistema de alarme do ConManager foi implementado com Action do Zabbix.Nela pode-se configurar o que o Zabbix deve fazer quando uma trigger for acionada. Dessaforma foi configurado que os dados do gatilho disparado fosse direcionados para um scriptescrito com Shell script. Dentro desse script, há um tratamento dos dados recebidos paraidentificar se a notificação corresponde a um aviso de sobrecarga ou se está avisandoque o problema já foi solucionado. Então, os dados são inseridos no banco de dados doConManager. Na fase atual da implementação, o ConManager não está configurado paratomar decisões sozinho, por isso o alerta é direcionado ao administrador na interface webque pode fazer intervenções manuais ou chamar o módulo de planejamento para o auxiliarna tomada de decisão. Também fica a cargo do módulo de análise a consulta dos horáriosdas aulas e esta é feita pela API disponibilizada pelo Google à agenda da ECT alimentadapelo setor de reservas.

As regras do planejamento foram elaboradas pela equipe que administra o ambientee foram transcritas para o PHP através de condicionais IF/ELSE. O módulo inicia aconsulta das informações ao banco de dados, API do Zabbix e API do Google Agendapara reunir todos os dados necessários. Após essa etapa são consultadas as restrições deredimensionamento que estão organizadas em listas de arrays. Depois de seguir a lógicaapresentada nos fluxogramas de tomada de decisão, o módulo de planejamento indica asintervenções a serem implementadas pelo módulo de execução ou simplesmente ignoraro alerta. As ações retornadas pelo planejamento identificam os servidores afetados, aquantidade de recursos manipulados e o horário de reverter as intervenções. Atualmente oConManager está configurado para exibir as ações ao administrador e esperar que sejaclicado em um botão para que sejam executadas as instruções via API do OpenVZ.

Os comandos que o ConManager usa para manipular os contêineres no OpenVZsão implementados utilizando as ferramentas vzctl e vzlist disponibilizada pela própriatecnologia de contêinerização. Os comandos necessários foram mapeados e estão organizadosem métodos de uma classe do ConManager. A execução é feita via conexão SSH com ousuário cadastrado ainda na fase de configuração do ConManager. A API do LTSP-Clusterfunciona de maneira similar, via SSH, porém atualmente só está implementada a funçãode leitura do arquivo de configuração. Essa leitura identifica os grupos existentes e quaisos servidores de aplicação que estão alocados a cada grupo.


5.2 Demonstração de utilizaçãoEssa seção tem o objetivo de demonstrar o uso do ConManager através das telas

do sistema seguindo alguns casos de uso. O caso de uso a ser seguido será o ilustrado naFigura 30, que corresponde à tela principal. Serão mostradas as abas da tela principal euma interação simulando o acontecimento de um alerta e uma chamada ao módulo deplanejamento.

Figura 16 – Demonstração da tela principal do ConManager, aba de alarmes e monitoramento

A Figura 16 ilustra a tela principal do ConManager. A figura está dividida por umalinha laranja. Na parte superior à linha, pode-se perceber o menu de telas do ConManagerque referencia as fases do Mape-K (Monitoramento, Análise e Execução). Dentro dosubmenu monitoramento é possível acessar as telas de configuração do ConManager comoservidor hardware, de aplicação, monitor, agente e grupos. Dentro do submenu análisepode-se listar todos os alertas já gerados pelo sistema, podendo verificar as intervençõespara cada alerta. No submenu execução é possível listar todas as intervenções feitase também criar uma nova intervenção. Continuando na tela principal, a primeira abacorresponde a tela onde serão exibidos os alarmes. O ConManager consulta a todo momentoo banco de dados (dentro de um intervalo de alguns segundos) e caso haja algum alertanovo, é exibido nessa aba. Na parte inferior à linha laranja, a aba Gráficos Zabbix permitevisualizar do ConManager os gráficos de monitoramento dos laboratórios.

A aba "Distribuição de recursos", exibida na parte superior à linha laranja na


Figura 17 – Demonstração da tela principal do ConManager, aba distribuição de recursos etabela de horários

Figura 17, faz uma concentração de informações que ajudam o administrador a tomardecisões nos momentos que os alertas são emitidos. São listados os status do hardwareque variam de acordo com os recursos (CPU,RAM e disco) consultados no momentoque a página foi carregada. A seguir são listados todos os contêineres ativos que têmligação com os grupos do LTSP-Cluster. A Figura 17 exibe o contêiner do laboratório3 mostrando infomações do identificador do contêiner, o nome, o laboratório e o statusde utilização. Logo abaixo há uma tabela com informações da quantidade de recursosque estão alocados ao contêiner. Ao lado de cada recurso há uma coluna "consolidadono banco" representando os dados inseridos no banco de dados, sendo esses os valoresreferência entendidos pelo ConManager como os valores originais do contêiner. A coluna"alocados atualmente" são dados coletados dos próprios contêineres no momento que apágina é carregada. Quando há alguma alteração na quantidade de dados decorrente dealguma intervenção, o valor do recurso fica vermelho, indicando que há uma intervençãoem aberto para aquele laboratório e em algum momento será preciso consolidar esse valor(fazendo o ConManager entender que agora esse valor é o original do contêiner) ou reverterpara o valor anterior à intervenção. Na parte inferior à linha laranja na Figura 17 estão oshorários das aulas recuperados do Google Agenda, separados em duas tabelas a primeiramostra as aulas que estão acontecendo neste exato momento e abaixo são listadas todas


as aulas programadas para o dia.

Figura 18 – Simulação de alerta e planejamento através da demonstração de telas

A Figura 18 simula uma ocasião que o alerta é disparado e o módulo de planejamentoé chamado. A parte superior à linha laranja mostra um alarme que não foi feito nenhumaintervenção, acusando sobrecarga de CPU no laboratório 2, exibindo informações dedata/hora, quantidade do recurso no momento do alerta (carga de processamento como valor de 11.04). Aparecem três botões para solucionar esse alerta. O primeiro é "novaintervenção" que redireciona o usuário à tela de intervenção para que se faça de formamanual. O segundo é "chamar planejamento", o qual é a implementação da forma "semi-automática" de adaptação dos recursos nos laboratórios. Por fim, o "ignorar alerta" faz oalerta sumir dessa tela sem fazer nenhuma alteração no ambiente. Ao clicar em "chamarplanejamento", o usuário é redirecionado para uma tela exibida na parte inferior à linhalaranja, onde são sugeridas duas ações de redimensionamento que são executadas a partide um clique do usuário. A ação 1 será a de acréscimo de recurso em um contêiner e aação 2 será a de decréscimo. Ao clicar no botão de aplicar as mudanças, um ícone verdeaparece no lugar do botão.


5.3 Considerações finaisEsse capítulo apresentou os detalhes da implantação do ConManager nos labo-

ratórios de informática da ECT, além de ter feito a apresentação da tela principal dosistema.

65

6 Avaliação

Esse capítulo apresenta os esforços ao longo desse projeto para avaliar o impactocausado pelo ConManager no gerenciamento dos laboratórios. Essas avaliações se deramdurante e depois do desenvolvimento do ConManager. Durante o desenvolvimento, asavaliações serviram para testar o funcionamento do sistema e a integração entre os módulos.As avaliações depois do desenvolvimento serviram para comprovar a eficácia do sistemaresolver o que se propõe, além de avaliar seus pontos fortes e fracos.

6.1 Experimentos controladosPara realizar os experimentos ainda na fase de desenvolvimento foram utilizados os

próprios laboratórios de informática, aplicando em contêineres separados dos demais ou emhorários que não tinham atividades. Foram executados alguns experimentos controladosdivididos em duas etapas. Na primeira etapa, os experimentos foram executados diretamenteno laboratório, simulando a utilização das sessões nos computadores com o objetivo deentender quais recursos mais impactavam para uma utilização do ambiente. Na segundaetapa, com o sistema em desenvolvimento, os experimentos foram executados com auxiliode softwares que sobrecarregam os recursos do ambiente. Nessa etapa, para realizar ostestes das fases de análise, planejamento e execução era necessário um contêiner quepudesse ser desligado, ligado, sobrecarregado e ter seus recursos alterados na medida quefosse preciso. Dessa forma, foi escolhido um contêiner que não é utilizado pelos laboratóriosmas que contêm a estrutura similar.

O experimento controlado da primeira etapa foi feito em um dos laboratórios com oobjetivo de identificar a lentidão nas sessões quando os recursos estavam sobrecarregados,sem fazer nenhum redimensionamento para aliviar a sobrecarga. Outro objetivo era fazeruma correlação de quais recursos mais impactam para que seja percebida a lentidão noacesso, para confirmar as impressões obtidas no questionário aplicado. O experimentoconsistia em ligar manualmente metade dos computadores do laboratório 2 e simular autilização das sessões iniciando alguns programas bem utilizados nas aulas, que foramapontados na pesquisa. Além de executar ações e perceber a estabilidade do ambiente etempo de resposta das ações executadas. O laboratório 2, no momento do experimentoestava alocado com 25% do CPU (total de 400 cpulimits), 16 GB de memória RAM, 12GB de SWAP e 50GB de espaço em disco. Cada ação foi pensada para sobrecarregar umtipo de recurso. A sequência das ações eram:

1. Iniciar as sessões de três em três, esperando carregar o ambiente

Capítulo 6. Avaliação 66

2. Iniciar o Scilab1

3. Iniciar o Chrome

4. Iniciar o NetBeans2

5. Executar um vídeo do YouTube no Chrome

O experimento iniciou às 09:56 e cada ação teve o seguinte tempo de duração: Aação 1 iniciou às 09:56 e finalizou às 10:14. As ações 2 e 3 foram executadas concomitantesà ação 1. A ação 4 iniciou às 10:08 e finalizou às 10:16. A ação 5 iniciou às 10:12 e finalizouàs 10:24. As ações procuravam identificar o impacto que cada uma causava na utilizaçãode CPU, carga média de CPU, memória RAM, memória SWAP, rede e espaço livre nodisco. As figuras a seguir mostram os dados coletados nesse experimento e ajudarão aentender os resultados obtidos. A Figura 19 exibe o gráfico de utilização de CPU (a), ondea área verde representa o tempo ocioso do CPU, a área azul representa o tempo de uso doCPU por processos de usuário e a área vermelha representa o tempo de uso do CPU porprocessos de sistema. Exibe também a carga média de CPU (load-average) (b), onde alinha verde representa a carga do processador no último minuto, a linha azul representaa carga do processador nos últimos 5 minutos e a linha vermelha representa a carga doprocessador nos últimos 15 minutos.

Figura 19 – Gráficos do que exibem a carga de processamento durante o experimento

A Figura 20 exibe o gráfico de memória RAM livre (c), onde a linha vermelharepresenta o total de memória RAM alocada e a área verde representa a quantidade dememória RAM livre. Exibe também o gráfico de memória SWAP livre (d), onde a linha1 <http://www.scilab.org/>2 <https://netbeans.org/>

http://www.scilab.org/

https://netbeans.org/


vermelha representa o total de SWAP livre. A Figura 21 exibe o gráfico da quantidade deusuários logados (e), onde a linha vermelha representa a quantidade de usuários logados.Exibe também o gráfico de tráfego de rede (f), onde a área azul representa o tráfego desaída na interface de rede e a linha verde representa o tráfego de entrada na interface derede. A Figura 22 exibe o gráfico da utilização de disco, onde a área verde representa opercentual de espaço livre no disco (g).

Figura 20 – Gráficos do que mostram a utilização de memória RAM e SWAP durante oexperimento

Figura 21 – Gráficos do que mostram a quantidade de usuários logados e utilização darede durante o experimento

Esse experimento ajudou a entender melhor como acontece a sobrecarga dos recursose a traçar os limiares de cada recurso para detectar que o ambiente está com dificuldade


Figura 22 – Gráficos do que mostram a utilização do disco durante o experimento

para ofertar o serviço DaaS. As três primeiras ações não causaram sobrecarga em nenhumrecurso, até por ser em apenas metade do laboratório. No entanto, ao iniciarmos a ação4 (quatro) percebe-se no gráfico de Utilização de CPU (a) um grande salto às 10:08 nautilização do CPU por processos de usuário, atingindo o pico de 93% do alocado para olaboratório. Também é possível perceber no gráfico CPU (load-average) (b) que a carga deprocessamento no último minuto atingiu o pico de 33. Nesse momento foi possível perceberbastante lentidão ao navegar pelas sessões abertas, principalmente quando passávamos omouse sobre alguma barra ou ícone e percebíamos lentidão no ambiente para responder aessas ações. Passando o pico de utilização do CPU causada pela ação 4 (quatro), percebe-seque o ambiente voltou a responder com maior agilidade. Apesar da sobrecarga no CPU,percebe-se que os recursos de memória RAM, SWAP, rede e disco não sofreram muitavariação, não sendo eles, portanto, os causadores da lentidão sentida.

Quando as 24 sessões estavam ativas, como mostra no gráfico da quantidade deusuários logados (e), iniciou-se a ação 5 (cinco), utilizando os navegadores já abertos eexecutando vídeos no YouTube em todas as sessões. A partir disso, no gráfico de memóriaRAM livre (c) percebe-se um alto consumo da memória RAM às 10:12, chegando a ficarapenas 1.91% de RAM livre, o que equivale a 312 MB. Enquanto isso, no gráfico dememória SWAP livre (d), a memória SWAP passou a ser fortemente utilizada, ficandoapenas com 4 GB às 10:22 dos 12 GB alocados ao laboratório. Percebe-se também queo tráfego de saída da rede, no gráfico de tráfego de rede (f) chegou perto de 1 Gbps nomomento que estavam sendo executados os vídeos. O disco, no gráfico de espaço livre nodisco (g) teve maior utilização, mas não chegou a números expressivos no experimento. Aoexecutar a ação 5 (cinco), voltou a perceber bastante lentidão para abrir outros programase na renderização dos vídeos executados.

Com esse experimento conseguiu-se entender quais recursos visualizar para iden-tificar uma lentidão nos laboratórios. Os principais recursos que podem causar lentidãonesse ambiente são CPU, RAM e rede. Para os casos onde a lentidão é causada por CPU,deve-se observar os gráficos de utilização de CPU, verificando o percentual de utilização dosprocessos de usuários e de sistema, além de observar o gráfico de carga de processamento,verificando principalmente a carga de processamento do último minuto. Para os casos onde


a lentidão é causada pela RAM, deve-se observar além do percentual de memória livre, ográfico de SWAP, pois sua utilização indica baixa quantidade disponível de memória RAM.E como todo o ambiente é executado sobre a rede, se faz necessário consultar sempre osgráficos de rede para identificar a lentidão. Da mesma forma que o aumento desses índicessignificam lentidão, a diminuição deles representa melhora no acesso ao ambiente.

Nos experimentos controlados da segunda etapa, foram feitos alguns testes funcio-nais, onde dados de entrada são fornecidos e o resultado obtido é comparado ao esperado,segundo Neto (2007). Neles, foram envolvidos o funcionamento do monitoramento, ocadastro de alarmes no Zabbix pelo ConManager, o disparo desses alarmes em situações desobrecarga, a integração do disparo do alarme junto ao sistema de alertas do ConManager,criação de intervenção a partir de alertas e a eficácia do módulo de execução em redimen-sionar os contêineres. Esses experimentos envolveram o uso da ferramenta Stress3, quepossibilita impor ao sistema uma quantidade de carga determinada sobre o uso de CPU,memória RAM e disco (suporte a teste de escrita). Para os testes realizados nessa etapa,foi escolhido um contêiner semelhante aos que atendem os laboratórios, porém não estáno cenário para os usuários utilizarem. Os testes eram executados a qualquer momento eos recursos eram sobrecarregados pelo tempo suficiente para ativar a trigger do recurso.Não haviam sessões de usuários compartilhando os recursos e por isso não era necessárioexecutá-los em horários que não houvesse pessoas nos laboratórios. A Figura 23 ilustrauma sobrecarga de memória RAM no contêiner escolhido para testes. Pode-se perceberque logo após o comando ser executado (às 10:42), a disponibilidade de memória RAM(no gráfico Memory Usage) sofreu uma grande queda, chegando a ficar com apenas 0.33%de memória livre (como mostra no gráfico Memória Livre %). Abaixo dos gráficos está oalerta gerado e exibido na aba de alarmes da tela principal do ConManager.

Após testes em ambiente isolado, foram realizados os testes utilizando dois labora-tórios (com 40 estações cada) em um horário em que nenhuma aula estava ocorrendo. Estesexperimentos nos permitiram identificar diversos pontos de melhoria no ConManager, alémde terem servido de base para a definição dos valores de limite configurados nos diversosalarmes do Zabbix.

6.2 Relato de uso em produçãoNesta seção serão relatados duas ocasiões que o ConManager foi utilizado para

solucionar a sobrecarga de recursos em um laboratório.

À medida que o sistema estava sendo desenvolvido e os módulos prontos, osadministradores do ambiente já o utilizavam para realizar as adaptações nos recursos dosservidores de aplicação. Os primeiros módulos desenvolvidos foram o de monitoramento,3 <http://manpages.ubuntu.com/manpages/wily/man1/stress.1.html>

http://manpages.ubuntu.com/manpages/wily/man1/stress.1.html


Figura 23 – Gráficos do Zabbix que ilustram a sobrecarga de um contêiner com o Stress

análise e o de execução, por isso ainda era necessário que o administrador consultassea aba de horários, de gráficos, de distribuição de recursos para tomar uma decisão. Oprimeiro caso relatado evidencia essa fase. À medida que o desenvolvimento se dava, afase de planejamento foi concluída (precisando ainda que o administrador aperte o botãopara chamar esse módulo). O segundo caso relatado evidencia essa fase.

O primeiro caso a ser relatado aconteceu no dia 10/11/2016. Nesse dia o laboratório2 estava reservado para quatro aulas seguidas da disciplina de Lógica de Programação. Asduas primeiras aulas ocorreram entre 18:45 e 20:30, com um intervalo de 15 minutos, eo reinício das aulas as 20:45 até as 22:15. Nesse dia não havia nenhuma aula agendadapara os outros laboratórios, e um dos laboratórios estava liberado para uso livre pelosestudantes.

A tela principal do ConManager é constantemente exibida na sala da equipe de TIda ECT. Os dados de monitoramento de CPU e memória RAM desse dia para o laboratórioem questão são apresentados na Figura 24. A cor verde no gráfico de CPU representa amedida de tempo ocioso (disponível), enquanto que as outras cores representam que a CPUestá ocupada. A cor verde no gráfico de consumo de memória representa a quantidadede memória livre, enquanto que a linha preta representa o total de memória alocado aoservidor de aplicação. Por volta de 19:05, o administrador foi chamado a atenção por dois


alertas de sobrecarga no laboratório em que estava ocorrendo a aula. O primeiro alertaindicava sobrecarga de memória RAM que estava com menos de 10% disponível por maisde 5 minutos, e o segundo uma sobrecarga de CPU que permanecia acima de 70% pormais de 5 minutos.

Figura 24 – Dados de utilização de CPU e memória RAM do laboratório durante aula delógica de programação.

Para decidir como responder a esta situação, o administrador inicialmente consultouo cronograma de aulas para o laboratórios em questão, e para os outros. Após constatarque não havia nenhuma aula ocorrendo em paralelo o administrador decidiu realizar duasintervenções, aumentar a quantidade de memória RAM e de CPU alocada ao servidor deaplicação do laboratório em aula. Estas intervenções foram concluídas as 19:15 e 19:20,respectivamente. Foi aumentado 3 GB de memória RAM ao servidor sobrecarregado eacrescentado mais 12.5% de concessão do uso do CPU (subindo de 25% para 37.5%).Depois de feito o redimensionamento, o administrador configurou que o horário pararetornar aos parâmetros de referência seria no término da aula (22:15). Essas intervençõessurtiram efeito imediatamente de forma que o monitoramento do ConManager entendesseque não havia mais sobrecarga e os alertas foram encerrados no Conmanager.

No entanto, pouco mais de 15 minutos depois das intervenções o nível de utilizaçãode CPU e memória voltaram a crescer, novamente ultrapassando os limites de CPU ememória por mais de 5 minutos, e gerando um novo alerta. Decorrente dessa nova situação,o administrador fez outra intervenção aumentando a concessão de limite de utilização deCPU, uma vez que apesar da sobrecarga nesse servidor, o recurso de CPU não estavasobrecarregado no hardware. A nova intervenção aumentou o percentual de uso do CPUde 37.5% para 56.25%, além de conceder mais memória RAM ao servidor do laboratório 2.Com isso, o restante da aula transcorreu sem nenhum novo alarme, e ao seu término, osvalores de CPU e memória alocados ao laboratório foram realocados de acordo com os


Hora Ação Recurso Laboratório Qtdmanipulado

Qtdreferência

Qtdtemporário

19:12:42 Retirar RAM Lab 4 3 GB 16 GB 13 GB19:15:28 Inserir RAM Lab 2 3 GB 16 GB 19 GB19:19:48 Retirar CPU Lab 4 12.5% 25% 12.50%19:20:18 Inserir CPU Lab 2 12.5% 25% 37.5%19:32:37 Retirar CPU Lab 3 18.75% 25% 6,25%19:34:14 Inserir CPU Lab 2 18.75% 37.5% 56,25%19:36:50 Retirar RAM Lab 4 3 GB 16 GB 13 GB19:37:08 Inserir RAM Lab 2 3 GB 19 GB 22 GB

Tabela 5 – Sequência de intervenções feitas no cenário de sobrecarga apresentado.

valores de referência. A tabela 5 sumariza as intervenções realizadas pelo administrador,onde Qtd manipulado representa a quantidade de recurso retirada/inserida a um servidorde aplicação, Qtd referência é a distribuição de recursos definida no início do semestreletivo, e Qtd temporário é a alocação de recursos após conclusão da intervenção.

Depois das intervenções houve melhora significativa na quantidade de recursosdisponíveis para que a aula prosseguisse sem exigir mais redimensionamento de recursos.

O segundo caso aconteceu no dia 22/02/2017 no laboratório de informática 2, nadisciplina de Lógica de Programação. A aula começou às 10:50 e finalizou 12:30. Nesseintervalo de tempo o laboratório de informática 1 estava sendo utilizado como aberto aopúblico, no laboratório 4 começou ao mesmo tempo outra aula e no laboratório 3 nãohavia aula marcada, fazendo assim, que os recursos alocados a esse laboratório estivessemsubutilizados.

Como foi explicado na Seção 2.1.2, o CPU é compartilhado por todos os contêinerese o cpulimit indica o percentual de utilização de cada um. A quantidade de cpulimit é deacordo com a quantidade de núcleos de processamento presente no hardware. O cenárioconta com 16 núcleos que totaliza 16000 cpulimits disponíveis para ser distribuídos entreos contêineres. A Figura 25 apresenta as telas do ConManager divididas por uma linhalaranja. Na parte superior da tela está a aba "Alarmes" na tela principal do sistema,indicando que foi detectado sobrecarga de CPU no laboratório 2 às 11:04:45, atingindo opico de carga de processamento de 11.04, sendo que a trigger configurada dispara quando acarga atingir valor acima dos 6 por mais de 5 minutos. O administrador ao clicar no botão"chamar planejamento" foi redirecionado para a tela de planejamento onde o ConManagersugeriu duas ações. A primeira é adicionar 18.75% de cpulimit no laboratório 2 (ficandoassim com 43.75% do CPU do hardware) até 12:30. A segunda é retirar essa mesmaquantidade de cpulimit no laboratório 3 (que estava sem aula e com o status subutilizado)e reverter às 12:30.

Como resultado dessa intervenção, é possível identificar na Figura 26 o pico deutilização do processador representado no gráfico (b) CPU Load - LAB2 , onde a linha


Figura 25 – Telas do ConManager no momento que foi acusado a sobrecarga no laboratório2

Figura 26 – Gráfico de utilização e carga do CPU durante a aula de lógica de programação

verde que representa a carga de processamento com média dos dados coletanos no últimominuto chegou a atingir o valor de 13.56 e ficou acima de 6 por mais de 5 minutos, causandoo alerta. Nessa mesma faixa de horário o gráfico (a) Cpu Utilization - LAB2 registrao pico de utilização de 64.56%, não chegando a gerar o alarme de sobrecarga. Após a


Figura 27 – Gráfico de utilização da quantidade de usuários logados durante a aula delógica de programação

intervenção o uso do CPU normalizou no restante da aula, sem ocorrências de novos picosde sobrecarga que durasse o intervalor maior que 5 minutos. A Figura 27 mostra o gráfico(c) Usuários logados - Lab2 que representa a quantidade de sessões ativas no período daaula. Nela percebe-se que o pico do CPU tem relação com a chegada dos usuários aolaboratório, mas que o consumo ficou abaixo do que é considerado sobrecarregado mesmocom o número alto de usuários logados. As intervenções foram revertidas automaticamenteàs 12:30.

6.3 DiscussãoA partir do segundo semestre de 2016, quando foi implantado, os resultados

alcançados com o ConManager têm trazido diversos benefícios. Antes do ConManager,problemas de sobrecargas em laboratórios eram detectados pelos usuários dos mesmos, e aequipe de TI era notificada pelo professor da aula, que era interrompida para que o professorpudesse notificar a equipe de TI. A resolução envolvia o acesso manual ao servidor deaplicação para investigar as causas da sobrecarga, seguida do redimensionamento manualdo servidor de aplicação, que necessitava ser reiniciado, de forma que todos as sessõeseram perdidas. Todo esse processo chegava a demorar até 30 minutos após a notificaçãodo professor, causando a interrupção da aula e diversos transtornos para os usuários doslaboratórios e para a equipe acadêmica da ECT.

O ConManager tem permitido à equipe de TI da ECT se antecipar aos problemasde sobrecarga, sendo capaz de agir antes que a aula chegue a ser interrompida. Foi feito ocálculo da média de tempo que se leva para adaptar os recursos, levando em consideração10 casos reais e chegou-se ao valor de três minutos e quarenta e oito segundos (3:48) desdea detecção até a aplicação de uma intervenção. Em consultas com professores e alunos deaulas que sofreram intervenções, percebeu-se que os efeitos de sobrecarga foram reduzidossignificativamente, com alguns alunos mencionando percepção de melhoria no uso dolaboratório. Embora o cenário possa ser considerado simples, se trata de um cenário realque afeta em torno de 4000 alunos que frequentam o prédio diariamente e os resultados


alcançados são bastante significativos, mostrando a eficácia da solução desenvolvida.

Com relação aos requisitos levantandos, o ConManager solucionou o do monitora-mento do ambiente e atende parcialmente o segundo, referente ao sistema que administre oambiente sem interferência do administrador. Isso se dá porque foi decidido que nessa faseinicial na qual o ConManager está em pleno uso no ambiente de produção, o administradordeveria aceitar a tomada de decisão feita pelo módulo de planejamento para que sejamvalidadas suas decisões. Com a implantação do ConManager cessaram as reclamaçõesrelacionadas à sobrecarga de recursos, pois agora é possível adiantar-se e fazer intervençõespara manter a boa utilização dos laboratórios.

O que foi percebido com o uso do ConManager é que os recursos do hardwaresão mais bem utilizados pelos laboratórios. Já houveram casos onde um dos laboratóriosdestinado às aulas estava sobrecarregado, juntamente com o laboratório utilizado como usogeral, além de outro com o status "pouco uso". Nessa ocasião, o ConManager sugeriu retirarrecursos do único laboratório sem utilização para aumentar os recursos do laboratório deaula sobrecarregado. As requisições por mais recursos vindo do laboratório de uso geraleram ignorados pelo ConManager, que seguiu as regras estabelecidas como o previsto.Nesse caso, os usuários do laboratório de uso geral percebiam lentidão no sistema, masdessa forma não comprometem as aulas, que possuem maior prioridade.

O ambiente de produção conta com apenas um servidor físico, porém o ConManagerfoi desenvolvido para suportar mais de um hardware, como as regras do módulo deplanejamento e o módulo de execução. Atualmente, se um contêiner consumir todos osrecursos alocados a ele, não podendo ser redimensionado em obediência às restrições, oConManager não poderá fazer nada devido à restrição física de recursos. Com a experiênciaque a equipe tem com o ConManager, pode-se afirmar que com o hardware disponível e aquantidade de laboratórios existentes em momentos de sobrecarga, o ConManager consegueredistribuir recursos para atender bem dois laboratórios com status "sobrecarregado", umcom status "pouco uso" e a permanência dos recursos do laboratório utilizado para usogeral.

6.4 Considerações finaisEssa seção apresentou alguns resultados obtidos pelo ConManager em produção.

Eles foram bastante positivos, podendo ser percebido principalmente pela cessação dasreclamações por professores com relação às lentidões no ambiente. O ConManager seencontra em uso e as limitações identificadas serão discutidas no capítulo final.

76

7 Trabalhos relacionados

Neste capítulo serão apresentados alguns trabalhos relacionados com o tema doproblema de pesquisa como o gerenciamento de recursos dentro de um ambiente virtualtal como data centers e nuvem. Relacionado com o ambiente implantado nos laboratóriosda ECT/UFRN, foram pesquisados assuntos que tivessem como solução para a montagemde ambientes computacionais a virtualização de desktops, além de ferramentas autoadap-tativas, que fazem o uso da contêinerização a tecnologia ideal para conseguir os resultadosesperados.

7.1 Produtos relacionadosAssim como o OpenVZ, o Linux Containers (LXC) 1 também provê isolamento

entre contêineres utilizando a ferramenta Kernel Namespaces. Dessa forma ele consegueisolar processos, sistema de arquivos, rede (baseado em rotas ou em bridges), pontosde montagem, tudo isso através de namespaces. Diferente do OpenVZ (que introduziuo conceito de User Beancounters), o LXC só permite o gerenciamento de recursos doscontêineres através de cgroups. O cgroups também tem a responsabilidade do controle dosprocessos e tem a função de limitar o uso de CPU entre os contêineres, segundo Xavier etal. (2013). Dessa forma, implementar o ConManager utilizando o LXC aumentaria muitoa complexidade, já que o gerenciamento dos recursos não vem facilitado pela tecnologia deconteinerização.

O Docker2 roda sobre o LXC e tem como intuito o provimento de rápida imple-mentação de aplicações/serviços dentro de contêineres de maneira sistemática, de acordocom Bernstein (2014). O Docker em si não é a tecnologia que isola os recursos como CPU,memória e rede dentro dos contêineres utilizando ferramentas do kernel, isso é tarefa doLXC. A função do Docker é prover ao usuário uma forma simples de manter sua aplicaçãoou serviço, sem se preocupar com níveis mais baixos de implementação da virtualização emcontêineres. Os contêineres no Docker são iniciados com base em uma imagem referência,possibilitando assim a criação de contêineres personalizados para atender às diversasnecessidades do usuário, prontos para serem iniciados. Para o Docker, um contêiner éuma instância de uma imagem, que por sua vez é criada através de um Dockerfile (umconjunto de comandos que descreve os arquivos, o ambiente, as configurações que compõeuma imagem) e estão disponíveis no Docker Hub, local onde são buscadas as imagens1 <https://linuxcontainers.org/>2 <https://www.docker.com/>

https://linuxcontainers.org/

https://www.docker.com/

Capítulo 7. Trabalhos relacionados 77

disponíveis para implementação 3. A elasticidade dos recursos no Docker é conseguidaatravés da replicação de instâncias e feita o balanceamento de carga. Para ambientes comoo da ECT, que implementa o DaaS baseado em sessão, essa abordagem não é interessantepois uma sessão que está em um contêiner continuaria sentindo a lentidão mesmo como balanceamento sendo feito. Nesses casos a sobrecarga só é aliviada quando sessões sãoreiniciadas e são direcionadas aos novos contêineres provisionados.

Apesar da falta de documentação da implementação do LTSP no Docker, umaimplementação foi detalhada por seu autor4. Os contêineres foram utilizados para hospedaros servidores LTSP e, usando o Dockerfile, pode-se construir com facilidade os servidoresde aplicação para hospedar as sessões remotas. Em sua infraestutura de rede, é necessáriaa existência do serviço DHCP para suportar o processo de boot PXE e do DNS usadopelo Dockerfile para utilizar o repositório APT do ubuntu. No entanto, essa estrutura nãofoi implementada pensando no problema da sobrecarga de recursos no contêiner e sim nafacilidade de criar novos contêineres para replicar o serviço.

A Microsoft desenvolveu uma função presente no Windows Server que provêambientes virtualizados, onde são criadas e gerenciadas máquinas virtuais. Essa tecnologiaé o Hyper-V5. Nele há uma característica chamada memória dinâmica que, quandohabilitada, aumenta a eficiência do uso da memória física. Quando ativa a memóriaalocada às máquinas virtuais, passa a ser compartilhada, podendo ser realocadas em tempode execução (sem a necessidade de desligar a máquina). Para isso funcionar é necessárioatribuir um valor mínimo e máximo que a máquina virtual poderá utilizar de memória. Ogerenciamento da memória é feita pelo Hyper-V, atribuindo mais quantidade quando umamáquina demanda6. O problema de implantar essa tecnologia em nossos laboratórios éque a ferramenta não permite criar regras de alocação. Elas são necessárias para que umamáquina virtual não monopolize os recursos, principalmente a que atende o laboratóriode uso geral. Seria necessário também a possibilidade de uma integração com a tabela dehorário das aulas, para que uma máquina virtual fique sem recurso suficiente pois estásendo utilizado por outras. Como não foi implementada no cenário, também não se sabe aagilidade que a máquina virtual recebe mais recurso de acordo com a sua demanda, pois senão for instantaneamente (como nos contêineres), pode comprometer o bom funcionamentoda aula.

Uma poderosa ferramenta na manipulação de contêineres, o Kubernetes 7, projetoiniciado pelo Google em 2014, é um sistema open-source construído para automatizar aimplantação, elasticidade de recursos e gerenciamento de aplicações conteinerizadas. Ele3 <https://docs.docker.com/engine/getstarted/>4 <http://championofcyrodiil.blogspot.com.br/2014/08/ubuntu-1404-ltsp-docker-container.html>5 <https://technet.microsoft.com/en-us/library/mt169373(v=ws.11).aspx>6 <https://charbelnemnom.com/2014/01/understanding-dynamic-memory-in-hyper-v-2012r2-part-1/

>7 <http://kubernetes.io/>

https://docs.docker.com/engine/getstarted/

http://championofcyrodiil.blogspot.com.br/2014/08/ubuntu-1404-ltsp-docker-container.html

https://technet.microsoft.com/en-us/library/mt169373(v=ws.11).aspx

https://charbelnemnom.com/2014/01/understanding-dynamic-memory-in-hyper-v-2012r2-part-1/

https://charbelnemnom.com/2014/01/understanding-dynamic-memory-in-hyper-v-2012r2-part-1/

http://kubernetes.io/


agrupa contêineres que compõe uma aplicação em unidades lógicas para fácil gerenciamentoe sua proposta é prover o crescimento flexível para entregar as aplicações consistentementeindependente da complexidade que exista nela. Dentre suas principais características estãoo empacotamento automático de aplicações, que consiste em alocar os contêineres combase em suas necessidades de recursos e outras restrições. É fornecido o scaling horizontal(crescimento de poder computacional por meio de balanceamento de carga), possibilitandoo aumento de capacidade dos recursos (CPU) com um simples comando do usuário ou deforma automática. Apesar do fato que a ferramenta é muito poderosa, o scaling horizontalnão atende os requisitos de um ambiente com sessões desktops, pois essas sessões sãolongas e sentem a sobrecarga de recursos do sistema operacional onde estão hospedadas.O scaling horizontal, colocando mais nós no balanceamento e dividindo a carga entreos diversos servidores não resolve de forma imediata o problema da sobrecarga, sendonecessário que a sessão do usuário seja reiniciada para que ela vá para um servidor ondeos recursos estejam mais livres.

7.2 Pesquisas relacionadasO trabalho proposto por Gomes et al. (2016) assemelha-se a este na questão

da implementação do serviço DaaS baseado em sessão com LTSP e LTSP-Cluster. Aestrutura por eles proposta consiste em uma nuvem com OpenStack para gerenciar asmáquinas virtuais criadas com KVM e todo o serviço DaaS rodando sobre a camadada nuvem. Entretanto, eles não consideram o problema de gerenciamento de recursos,mas sim a escalabilidade oferecida pela nuvem para o armazenamento das imagens demáquinas virtuais e dos dados dos usuários. Para lidar com situações de sobrecarga,eles realizam o provisionamento de novas máquinas virtuais, utilizando-se do dashboarddo OpenStack, que são integradas ao ambiente LTSP-Cluster. Todo o processo é feitomanualmente, enquanto que o ConManager permite que tudo seja realizado a partir daprópria ferramenta. Além disso, conforme já mencionado anteriormente, tal solução nãoelimina a sobrecarga para sessões já estabelecidas. Os experimentos apresentados por elesconfirmam esse comportamento, deixando os usuários decepcionados com o atraso deresposta da plataforma.

O trabalho apresentado por Hao et al. (2009) tem foco na migração de instânciasvirtuais (utilizando o OpenVZ) entre data centers, melhorando o desempenho do ambientecom balanceamento de carga. No entanto, no cenário dos laboratórios da ECT, onde assessões ficam ativas por horas e não há a possibilidade de tirar uma sessão de um sistemaoperacional e colocar em outro sem reiniciá-la, apesar dessa solução ser muito eficientepara aplicações comerciais, ela não é a mais adequada para o cenário de virtualização dedesktops baseado em sessão.


Dentro do assunto de gerenciamento de recursos voltados para nuvem, Berrymanet al. (2010) apresentam o VDBench, um gerenciador de recurso em ambientes virtuaisvoltados para DaaS. A ferramenta é baseada no gerenciamento de memória do VMwareESXi, sendo capaz de provisionar novas máquinas virtuais ao verificar que há demandanecessária para esse tipo de ação. Seu objetivo é ajudar o administrador a provisionar aquantidade adequada de recursos por máquina virtual. Os mesmos autores Calyam et al.(2011), apresentam um módulo chamado “Utility-Directed Resource Allocation Model”(U-RAM) que busca solucionar o problema de alocação de recurso dentro do ambientevirtual. A abordagem dessa ferramenta é provisionar máquinas virtuais levando em conta ocomportamento do cliente para conseguir o máximo de eficiência nos recursos. A propostade gerenciamento de recursos apresentada por eles não se adequam a nosso cenário de DaaSbaseado em sessão, pois focam no provisionamento de novas máquinas virtuais, segundoBerryman et al. (2010), e com nova configuração, como em Calyam et al. (2011), enquantoque o ConManager permite o redimensionamento dinâmico de servidores virtuais.

Padala et al. (2007) no “Adaptative Control of Virtualized Resources in UtilityComputing Environnments” trabalham o gerenciamento de recursos em ambientes de datacenters, com foco, principalmente, na otimização do provisionamento de uma máquinavirtual de acordo com a demanda que ela atenderá. Como exemplo, um sistema que temserviços diferentes como a aplicação propriamente dita e o banco de dados. Seu trabalhotoma como base um ambiente onde toda a estrutura de recursos computacionais estão emum pool e todos os serviços fazem o compartilhamento dessa quantidade disponível. Suaproposta é criar um sistema que ajusta dinamicamente os recursos para uma aplicação,levando em consideração não só o serviço contemplado, como o impacto gerado em todosos outros nós. O controlador de recursos desenvolvido analisa as cargas, fazendo uso dofeedback control loop e através de técnicas disponibilizadas pelo próprio hypervisor, fazo escalonamento de CPU ora restringindo o uso ora liberando mais tempo de processa-mento. Apesar de seu trabalho ter inspirado alguns pontos para este trabalho, apenas ogerenciamento do CPU não atende os requisitos da ECT.

Assim como a proposta neste trabalho apresentada, alguns trabalhos consideramos recursos dos servidores físicos e virtuais no processo de tomada de decisão. Em Van,Tran e Menaud (2009) foi proposto um gerente autonômico que concentra seus esforços emcontrolar e ajustar os recursos presentes em uma infraestrutura de nuvem com múltiplasmáquinas virtuais (VM) chamada de Application Environment (AE), responsáveis pelasaplicações hospedadas. A presença do Local Decision Module (LDM) em cada AE tem aresponsabilidade de avaliar a oportunidade de alocar ou liberar VMs com base na atualcarga de trabalho. Há também o papel do Global Decision Module (GDM) no centro dosistema. O LDM interage com o GDM enviando as métricas de utilização, que por sua vezmonitora as máquinas físicas para decidir se provisiona ou elimina VMs, e avisa o LDM dadecisão que tomou. Apesar da proposta ser interessante, principalmente a divisão do nível


de decisão do LDM e do GDM, ela não se adequa ao cenário dos laboratórios de informáticainstalado na ECT, pois o aumento de novos servidores não aliviam imediatamente a faltade recursos em um servidor sobrecarregado.

De maneira similar, Maurer, Brandic e Sakellariou (2013) abordam o gerenciamentode uma infraestrutura de nuvem e propõem o gerenciamento de recursos entre máquinasvirtuais (VM) e máquinas físicas para atender os acordos de contrato com clientes (conhe-cidos como SLA). Similar aos outros trabalhos mencionados, a abordagem deles considerao provisionamento de novas máquinas virtuais. Para isso, eles aplicaram duas abordagenspara o gerenciamento de conhecimento, o baseado em regras e o raciocínio baseado emcasos, e as testou utilizando o processo MAPE-K. As técnicas apresentadas nesse trabalhoserviram como inspiração para alguns aspectos do ConManager, como a definição de statuspara as máquinas virtuais, e o uso de regras para a tomada de decisão, que serviu comobase para o processo de tomada de decisão realizado pela equipe de TI da ECT.

No trabalho de Barna et al. (2017) é proposto um sistema de gerenciamento au-tonômico (AMS do termo em inglês Autonomic management system) para aplicaçõesmulticamadas baseadas em contêineres implementadas na nuvem. O sistema foi desenvol-vido seguindo a arquitetura proposta pelo MAPE-K e sua função é detectar se algumacamada (que são atendidas por um ou mais contêineres por meio de balanceamento decarga) está sobrecarregada ou subutilizada para decidir se adiciona ou retira contêinerespara atender o serviço. A análise se baseia na definição de limites e quando há a violação dealgum deles, o módulo de planejamento é ativado chamando um plano diferente para cadalimiar violado. O AMS age somente quando um limite é violado n vezes, onde n foi definidopelo administrador e no planejamento é proposto um algoritmo para escalar contêineres.O conceito central do algoritmo é chamado Heat que determina o acúmulo para adicionarou remover contêineres, sendo que a sobrecarga no serviço resultará o aumento do Heate a subutilização significa a sua diminuição. Com o aumento do Heat aumenta a chancede adicionar contêineres e vice-versa, visto que o resultado desse fator é constantementeverificado e o algoritmo informa ao AMS para executar a ação de escala conforme oindicado pelo modelo. Analisando o AMS proposto, conclui-se que a faixa de aplicaçãoque o sistema se propõe atender não é compatível com nosso cenário, pois a abordagemde adicionar e remover contêineres não atende o requisito do serviço DaaS baseado emsessão. Justamente pelo fato do usuário continuar percebendo a lentidão do contêiner ondeestá hospedado. O conceito de Heat implementado no algoritmo é interessante e pode serutilizado em trabalhos futuros, substituindo a abordagem atual de reverter a configuraçãocom base no final da aula.

O trabalho feito por Morais et al. (2013) foca na problemática de elasticidade derecursos virtuais para atender demandas que variam de acordo com o tempo na computaçãoem nuvem. O monitoramento e a predição foram elencados como tarefas importantes em


um mecanismo que tem a responsabilidade de realizar o provisionamento automático epropõe um mecanismo para o provisionamento horizontal dos recursos, proativo e reativoindependente de aplicação e possui configuração dinâmica e automática para realizaressas tarefas. A abordagem adotada para conseguir a elasticidade de recursos é através doprovisionamento de novas máquinas virtuais para balancear a carga de trabalho entre asVMs. Dessa forma, o mecanismo proposto realiza o planejamento a curto prazo a capacidadenecessária para atender a demanda para minimizar a quantidade de máquinas ligadas.O comportamento reativo foi implementado através da definição de ações associadas acada tipo de recursos e quando um recurso atinge certo limite as ações são executadas. Ocomportamento proativo foi implementado através de preditores que estimam a utilizaçãofutura de uma camada com base na utilização dos recursos. Apesar de ser um trabalhomuito interessante, ele não se aplica por completo no cenário dos laboratórios, pois suaabordagem de elasticidade é por meio de provisionamento de máquinas virtuais e obalanceamento de carga entre elas. Como já discutido, essa abordagem não resolve asobrecarga de recursos sentida pela sessão do usuário, sendo necessária a finalização dasessão para que seja alocada em outra instância virtual com recursos livres.

Na linha dos softwares autoadaptativos, o Rainbow proposto por Garlan et al.(2004) apresenta uma arquitetura de software que implementa as etapas de monitoramento,análise, planejamento e execução da adaptação no ambiente. Sua arquitetura abstratapermite ainda que ele seja utilizado em diversos domínios que necessite de autoadaptação,realizando adaptações externas e desacoplando os módulos do sistema do ambiente emoperação. Sua infraestrutura de tradução ajuda a mediar o mapeamento da informaçãoatravés da abstração do sistema para o modelo, sendo possível manter vários mapeamentosno ambiente. Esse trabalho é capaz de se adaptar à diversas demandas, até mesmo à degerenciamento de recursos entre contêineres, devido à sua capacidade de abstração doambiente. Ele não foi utilizado na implantação da solução, porém a forma de adaptar oambiente serviram de inspiração para a construção do ConManager.

7.3 Considerações finaisNeste capítulo foi apresentado o resultado da pesquisa dos trabalhos relacionados,

tendo como norte os trabalhos na linha de gerenciamento de recursos, sistemas autoadap-tativos e ambientes de laboratórios com virtualização de desktops. Apesar da contribuiçãoque cada um dos trabalhos apresentados deu como inspiração para o ConManager, ne-nhum deles se propõe a solucionar o problema dos laboratórios com sessões de usuáriosvirtualizadas e que requer gerenciamento de recursos entre as instâncias virtuais.

82

8 Conclusões

Neste capítulo serão apresentadas as conclusões deste trabalho. As seções seorganizam da seguinte maneira: a seção 8.1 será destinada às contribuições deste trabalho.A seção 8.2 tratará das limitações do trabalho e a seção 8.3 listará o conjunto de tarefas aserem desenvolvidas em trabalhos futuros.

8.1 ContribuiçõesAs principais contribuições deste trabalhos são resultantes da pesquisa ao longo

do projeto aqui apresentado e do desenvolvimento da solução motivada pelas dificuldadesenfrentadas nos laboratórios de informática da ECT.

A primeira contribuição foi mostrar que em ambientes semelhantes à ECT, asobrecarga de recursos deve ser solucionada com acréscimo de recursos ao servidor. Isso épossível afirmar devido ao estudo das abordagens de escalabilidade de recursos em serviçosDaaS. Há duas formas de conseguir elasticidade de recursos para aumentar a capacidadede atendimento em momentos de pico, balanceamento de cargas e redimensionamentode recursos, segundo Coutinho et al. (2013). A abordagem do balanceamento de cargas(aderida pelas principais ferramentas de gerenciamento de máquinas virtuais e contêineres eambientes de nuvem) consiste em criar réplicas de uma instância e balancear a carga atravésdas réplicas. Essa abordagem não se mostra eficaz em ambiente DaaS baseado em sessões(como é o caso da ECT), pois quando um servidor fica sobrecarregado, o balanceamentodireciona novas requisições para os servidores com recursos mais livres, porém, sessões deusuários são longas e continuam a sentir a lentidão até que sejam reiniciadas e direcionadasa outros servidores. Para esses ambientes o ideal é o redimensionamento, pois permiteajustar a quantidade de recursos de acordo com a carga de trabalho, sem interromper assessões ou criar novas réplicas do servidor.

A segunda contribuição foi o desenvolvimento do ConManager, solução para ogerenciamento de recursos entre contêineres. Seguindo as fases do Mape-K, o sistemacontempla todo o ciclo de gerenciamento de recursos que envolve o monitoramento, aanálise dos dados coletados de forma a identificar a sobrecarga de recursos, o planejamentodas intervenções necessárias com possibilidade de criar regras específicas para a instituiçãoe a implementação dessas ações de maneira segura. Essa solução pode ser implementadaem outros laboratórios similares ao da ECT, se estendendo a outros centros da UFRN equalquer outra instituição que deseje fazer sua utilização. Além do ambiente no qual foiinstalado e testado, como o DaaS baseado em sessão, o ConManager pode ser empregadoem outros ambientes que necessitem de gerenciamento de contêineres como o de um

Capítulo 8. Conclusões 83

servidor que hospede múltiplos serviços Web e necessitem de mais recursos em momentosde pico de acesso.

A terceira contribuição foi o efeito que o ConManager gerou a ser implementadona ECT. Com o constante monitoramento, o sistema de alarmes, o planejamento (aindaque necessite do administrador aceitar as sugestões de intervenção) e a execução deintervenções de maneira rápida, conseguindo assim, anteceder a completa falta de recursosem um laboratório, muitas vezes vividas antes da utilização do sistema. Em conversa comalguns professores sobre a solução já implementada nos laboratórios, pode-se confirmara contribuição desse sistema no decorrer das aulas. A equipe técnica responsável pelogerenciamento dos laboratórios também percebeu a melhora no atendimento desse serviço,pois com o uso do ConManager deixou de ter reclamações de lentidão no ambiente doslaboratórios, além de ter facilitado as tarefas de gerenciamento.

8.2 LimitaçõesAs limitações deste trabalho se dão principalmente no módulo de planejamento

baseado em regras preestabelecidas pelo administrador do ConManager. Essas regras aindanão contemplam todos os cenários de sobrecarga de recursos (se limitando à CPU,RAMe disco), além de não ser capaz de aprender com as respostas dadas pelo ambiente deacordo com as intervenções feitas. O módulo de planejamento não relaciona o quantode recurso cada aula utiliza, o histórico de intervenções feitas ao longo do tempo paracada aula e se houve a necessidade de intervenção humana para resolver problemas nãosolucionados com as ações propostas pelo módulo. Também nesse contexto, o ConManagernão toma decisões verificando que tipo de programa está sendo utilizado nas aulas ouquantos usuários estão usando esse programa, para dessa forma alocar mais recursos deacordo com os programas utilizados nas aulas.

Há limitações do projeto que estão ligadas à maneira como o ConManager utilizaferramentas de terceiros para realizar importantes fases de monitoramento e análise comoo Zabbix. A integração dessas ferramentas é um fator limitante principalmente para aimplantação do ConManager em outros lugares, pois será requisito a utilização dessassoluções que requerem infraestrutura exclusiva e conhecimento de como manuseá-la. Outralimitação desse mesmo contexto é a necessidade de utilização do Google Agenda, quesó entrou nos requisitos do ConManager porque é utilizado pela equipe acadêmica pararegistro de aulas. Dessa forma, é necessário que alguém alimente esse calendário com oshorários das aulas, para que assim o módulo de planejamento possa decidir se é possívelou não fazer o remanejamento de recursos. Sem os horários das aulas, o ConManager nãotem outro parâmetro para decidir quando reverter uma intervenção.

O ConManager não está apto a redimensionar todos os recursos que um laboratório


de informática necessita como o de largura de banda, poder liberar mais tráfego de rede àum laboratório em detrimento de outro. A manipulação dos recursos implementada atéagora é feita através da ferramenta vzctl do OpenVZ. Com isso, todas suas limitações sãorefletidas no ConManager. Porém é possível ainda implementar novas funcionalidades degerenciamento de sessões de usuários que se encaixam com a proposta do ConManagercomo a limitação de utilização de recursos por sessão de usuários.

8.3 Trabalhos futurosOs trabalhos futuros terão foco principalmente no aprimoramento de dois módulos

importantes no ConManager: o de análise e o de planejamento. No módulo de análiseindicamos a implementação do reconhecimento da quantidade de recursos cada aulaconsome geralmente através do cruzamento dos dados como o histórico de intervenções emédia de utilização de recursos tal como CPU e memória RAM de acordo com a aula,possibilitando que o sistema faça o redimensionamento dos recursos se antecipando ànecessidade de intervenção.

Para o módulo de planejamento sugerimos a implementação do aprendizado dequais intervenções a se fazer mediante à consulta das últimas ações feitas. Para isso énecessário implementar uma maneira do sistema saber se uma intervenção surtiu efeito ounão, sendo assim possível indentificar qual escolha é a mais adequada segundo a ocasião.Sugerimos o uso de Domain-Specific Language (DSL) para representar os conhecimentosespecíficos de forma clara, facilitando as alterações de regras. Esse trabalho futuro conferemais automação ao sistema, fazendo que a intervenção humana seja cada vez mais rara.

O desenvolvimento da manipulação do serviço LTSP-Cluster também está nalista dos trabalhos futuros, assim como o da criação de um novo contêiner a partirdo ConManager. Hoje, para colocar um novo contêiner em funcionamento é precisorealizar os comandos via terminal, adicionar as informações no serviço do LTSP-Cluster ereiniciar o serviço. Assim como esses comandos, estarão nos trabalhos futuros também omelhoramento do módulo de execução, contemplando outros comandos de manipulação decontêineres como o de criar snapshots, parar, iniciar e migrar para outro hardware. Essasfuncionalidades tem o potencial de aumentar a robustez do ConManager, possibilitandoque toda interação seja possível via sistema.

Indicamos o uso de alguma ferramenta que consiga medir a percepção dos usuáriossobre a qualidade do serviço DaaS. Ela deverá ser capaz de captar o feedback dos alunose professores quando utilizam o ambiente. Com isso será possível aprimorar as regrasde redimensionamento do ConManager, para que a experiência do usuário na utilizaçãodo DaaS seja satisfatória e os recursos não fiquem subutilizados. Sugerimos também, arealização de medição de percepção de acordo com as metodologias de QoE, como em


Mok, Chan e Chang (2011).

Como evolução da ferramenta, apontamos a adaptação do módulo de execução doConManager para a nova versão do OpenVZ, o Virtuozzo 1. Essa evolução na tecnologiade contêinerização traz benefícios como a manipulação do hypervisor KVM, possibilitandoao ConManager gerenciar contêineres e máquinas virtuais.

1 <https://virtuozzo.com/>

https://virtuozzo.com/

86

A Apêndice - Requisitos do sistema

Nesse Apêndice estão reunidos todos os requisitos coletados na fase anterior aodesenvolvimento, que auxiliaram na contrução do ConManager. Eles estão organizados emSeções que respondem as perguntas Onde, Quando, O quê, Porquê, Quem e Como.

A.1 OndeAs camadas relevantes no ambiente de atuação do ConManager são: hardware/

sistema operacional (S.O.), gerenciador de contêineres, Servidor de aplicação e balanceadorde cargas. As adaptações ocorrerão nas camadas do gerenciador de contêineres através demanipulação de servidores de aplicação como criação, exclusão, redimensionamento dememória RAM, Swap, processador, disco e na camada do balanceador de cargas incluindoe excluindo servidores de aplicações do balanceador de carga do ambiente. As demaiscamadas servirão de base para o monitoramento do ambiente para auxiliar na tomada dedecisão. Abaixo serão listadas todas as camadas existentes e quais os parâmetros devemser monitorados pelo ConManager:

Camada: Hardware/S.O.: Os dados que deverão ser coletados diretamente do hardware/sistema operacional são:

1. Processamento

• Porcentagem de utilização do CPU: Porcentagem ocioso, Utilizado por usuários,Utilizado pelo sistema, Espera IO;

• Carga de processamento (load average): Carga média do último minuto, Cargamédia dos últimos 5 minutos, Carga média dos últimos 15 minutos;

• Quantidade de núcleos do processador

2. Memória

• Total de memória RAM do sistema

• Quantidade de memória RAM disponível

• Total de memória SWAP do sistema

• Quantidade de memória SWAP disponível

3. Rede

• Tráfego de entrada de cada interface de rede do hardware

Apêndice A. Apêndice - Requisitos do sistema 87

• Tráfego de saída de cada interface de rede do hardware

4. Armazenamento

• Quantidade total de espaço em disco

• Quantidade utilizada do espaço em disco

Gerenciador de contêiner: Os seguintes dados deverão ser obtidos do gerenciador decontêiner (OpenVZ):

1. Dados dos contêineres

• Contêineres criados/ativos

• Nome do contêiner

• ID do contêiner

• Quantidade de núcleos de processamento (utilizado para calcular o cpulimit)

2. Provisionamento de recursos de cada contêiner:

• Armazenamento: espaço em disco

• Processamento: Percentual máximo da utilização do CPU (em cpulimit) - valormáximo que o container vai conseguir usar da CPU.

• Memória: Quantidade memória Ram alocada e quantidade de memória Swapalocada

Camada: Servidor de aplicação (para cada servidor de aplicação): Em todosos contêineres que atendem os usuários nos laboratórios deverão ter os seguintes dadoscoletados:

1. Sessões ativas (usuários logados)

2. Processamento, memória, rede e armazenamento semelhante ao monitorado nacamada de hardware/S.O.

Camada: Balanceador de cargas: No balancador de cargas deverão ser coletados osseguintes dados:

1. Quantidade de grupos (um grupo para cada laboratório)

2. Para cada grupo:

• IP do servidor

• Nome do servidor


A.2 QuandoA adaptação acontecerá em duas camadas: Na camada do gerenciador de contêiner

acontecerá de forma reativa, quando um dos servidores de aplicação estiver sobrecarregadoe de forma proativa quando o ConManager, baseado na tabela de horários e no históricode intervenções para aquela aula, redimensionar os recursos para um valor que melhoratenda a demanda. Na camada do balanceador de cargas acontecerá quando um contêineré incluído ou excluído nos grupos de balanceamento.

A adaptação na camada do gerenciador de contêineres pode ser aplicada quando oprocesso de redimensionamento dos recurso entre os servidores não influenciar na utilizaçãodo servidor de aplicação que teve parte de seus recursos retirados, como por exemplo:Não tem aula no laboratório que os recursos estão subutilizados. O ConManager deverátambém ser capaz de analisar os eventos ocorridos para determinar a quantidade de recursomais adequado de acordo com a aula, dessa forma será possível fazer o redimensionamentoinstantes antes da aula começar. O momento de reverter a adaptação deverá acontecerquando a aula do contêiner sobrecarregado acabar ou quando o turno acabar (para casosde laboratórios de uso geral).

Na camada de balanceador de carga a adaptação acontecerá de forma reativa:quando o administrador criar/excluir um servidor de aplicação no ConManager, informandoem qual grupo (no balanceador de cargas) será feita a alteração.

A.3 O quêOs artefatos que poderão ser alterados serão listados de acordo com as camadas

identificadas. Será exemplificado também qual a abordagem para verificar se a mudançafoi realmente executada.

Camada: Gerenciador de contêiner: Os artefatos que podem sofrer alteração nacamada de gerenciador de contêiner são:

1. Contêineres ativos

• Criar contêiner. Checar na listagem dos contêineres.

• Excluir container. Checar na listagem dos contêineres.

• Iniciar contêiner. Checando o número de contêineres rodando.

• Parar container. Checando o número de contêineres rodando.

2. Quantidade de recursos alocados para cada contêiner

• Armazenamento - espaço em disco: Configurar nova cota. Listar após a alteração,a quantidade de espaço em disco.


• Processamento - Percentual Máximo de utilização do CPU (levando em conside-ração o parâmetro cpulimit). Listar após a alteração a quantidade de cpulimitalocado.

• Memória RAM - Quantidade de memória RAM alocada ao contêiner. Listarapós a alteração, a quantidade de memória RAM alocada.

• SWAP - Quantidade de SWAP alocada ao contêiner. Listar após a alteração, aquantidade de SWAP alocada.

Camada: balanceador de cargas: Os artefatos que podem sofrer alteração na camadabalanceador de cargas são:

1. Grupos

• Quantidade de servidores de aplicação por grupo. Sendo que cada grupo repre-senta um laboratório e os servidores incluídos nos grupos atendem as requisiçõesdemandadas por esse laboratório.

• Endereço IP e nome do servidor de cada grupo.

A.4 PorquêA abordagem escolhida para solucionar o desafio de criar e gerenciar vários servidores

de aplicação que atendessem o ambiente de acesso remoto montado nos laboratórios deinformática, foi a utilização de contêineres compartilhando recursos do hardware. Por essefato, há sobrecarga de recursos em alguns servidores, enquanto em outros o recurso ésubutilizado, gerando perda de desempenho nos computadores do laboratório com muitautilização. O ConManager é um sistema que monitora o uso dos servidores e autoadapta oprovisionamento dos recursos entre instâncias para prover o melhor aproveitamento deles,otimizando os recursos do hardware.

A.5 QuemO ConManager deverá ser capaz de seguir as fases determinadas pelo Mape-K de

maneira autônoma. No entanto, o sistema deve ser capaz de prover o máximo de informaçõesque auxiliem o administrador nos casos que a intervenção humana for necessária. Essaintervenção consiste na adaptação dos recursos dos contêineres e adaptação do serviço debalanceamento de cargas. Para isso, é necessário que o sistema avise ao administrador quehá sobrecarga de recursos, exiba a quantidade de recursos distribuídas entre os contêineres,exiba também os gráficos de utilização do ambiente, além da tabela de horário das aulas.Essas informações auxiliarão a tomar a decisão mais acertada.


Todas as ações executadas, humanas ou autônomas, no ambiente provido noslaboratórios devem ser feitas exclusivamente no ConManager. Para isso o sistema deveprover a estrutura necessária (comandos que executem as ações) para realizar as alteraçõesnecessárias dentro do gerenciador de contêiner.

O administrador do ConManager deverá inserir as regras de negócio que irão guiaro sistema na tomada de decisão presente na fase de planejamento. As regras especificamao ConManager quando entender que um servidor está sobrecarregado, quanto de recursodeve redimensionar, qual horário reverter, etc. Essas configurações poderão ser alteradaspelo administrador de acordo com a necessidade.

A.6 ComoAqui serão listadas todas as ações necessárias para implementar as mudanças. Cada

ação tem um número, descrição, os parâmetros utilizados na ação, a forma que a ação seráimplementada, pré-condição e pós-condição.

Camada: Gerenciador de contêiner:

1. Criar e configurar servidor de aplicação

• Descrição da ação: Essa ação cria um novo contêiner configurado de acordocom os parâmetros recebidos.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação criado.– Ostemplate:String: template do sistema operacional usado para criar o

template– DiskMin:Inteiro: Valor que determina a quantidade mínima de espaço em

disco o servidor de aplicação poderá fazer uso. Pode-se colocar junto como valor numérico a letra M para indicar que a medida será alocada emMegabytes ou um G para alocar a quantidade em gigabytes.

– DiskMax:Inteiro: Valor que determina a quantidade máxima de espaço emdisco o servidor de aplicação poderá fazer uso. Pode-se colocar junto como valor numérico a letra M para indicar que a medida será alocada emMegabytes ou um G para alocar a quantidade em gigabytes.

– Ram:Inteiro: Quantidade de memória RAM do hardware que será alocadapara o servidor de aplicação. Pode ser determinada por um número inteiroque indica quantidade de memória RAM junto com um M para alocar aquantidade em Megabytes ou um G para alocar a quantidade em Gigabytes.


– Swap:Inteiro: Quantidade de memória Swap do hardware que será alocadapara o servidor de aplicação. Pode ser determinada por um número inteiroque indica quantidade de memória Swap junto com um M para alocar aquantidade em Megabytes ou um G para alocar a quantidade em Gigabytes.

– Cpuunits:Inteiro: Unidade de medida representada em números inteirospositivos que determinam o mínimo garantido de tempo de CPU queum servidor de aplicação irá receber. Cuplimit:Inteiro: Um número inteiropositivo que indica o percentual de tempo de utilização do CPU por servidorde aplicação.

– Userpasswd:String: Senha do usuário administrador– Onboot:String: Determina se o contêiner ligará sozinho após a inicialização

do hardware. Valor padrão é String com “yes” ou “no”.– Hostname:String: Informa o nome do hostname do servidor de aplicação

criado. Nameserver:String: informa o IP do DNS para o servidor de aplicação– IP:String: informa o IP do servidor de aplicação que está sendo configurado.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. As seguintes chamadasprecisam ser realizadas na ordem apresentada.

– vzctl create $id –ostemplate $ostemplate -–config basic –hostname $host-name

– vzctl set $id –onboot $onboot –save– vzctl set $id –ipadd $ip –save– vzctl set $id –nameserver $nameserver –save– vzctl set $id –diskspace $diskmin:$diskmax –save– vzctl set $id –ram $ram –save– vzctl set $id –swap $swap –save– vzctl set $id –cpuunits $cpuunits –save– vzctl set $id –cpulimits $cpulimits –save– Vzctl set $id –userpasswd root:$userpasswd –save

• Pré-condição: É necessário que existam recursos disponíveis para se criar ocontêineres com a configuração desejada.

• Pós-condição: Servidor criado com sucesso. Servidor é criado com status parado

2. Iniciar servidor de aplicação

• Descrição da ação: Essa ação inicia um servidor de aplicação que está com ostatus parado.


• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ser iniciado;

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamadaprecisa ser realizada para iniciar o servidor de aplicação indicado.

– Vzctl start $id

• Pré-condição: Para iniciar um servidor de aplicação é necessário que ele estejacom o status “stopped”.

• Pós-condição: O servidor é iniciado, seu status fica com a descrição “running”.

3. Parar servidor de aplicação

• Descrição da ação: Essa ação para um servidor de aplicação que está com ostatus ativo.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ser parado;

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamadaprecisa ser realizada para parar o servidor de aplicação indicado.

– Vzctl stop $id

• Pré-condição: Para iniciar um servidor de aplicação é necessário que ele estejacom o status “running”.

• Pós-condição: O servidor é parado, seu status fica com a descrição “stopped”.

4. Destruir servidor de aplicação

• Descrição da ação: Essa ação destrói um servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ser destruído;

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. As seguintes chamadasprecisam ser realizada para destruir o servidor de aplicação indicado.

– Vzctl stop $id;– Vzctl destroy $id;

• Pré-condição: O servidor deve ter seu status como parado

• Pós-condição: O servidor é destruído


5. Destruir servidor de aplicação

• Descrição da ação: Essa ação destrói um servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ser destruído;

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. As seguintes chamadasprecisam ser realizada para destruir o servidor de aplicação indicado.

– Vzctl stop $id;– Vzctl destroy $id;

• Pré-condição: O servidor deve ter seu status como parado.

• Pós-condição: O servidor é destruído.

6. Reiniciar servidor de aplicação

• Descrição da ação: Essa ação reinicia um servidor de aplicação.

• Parâmetros:


• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamadaprecisa ser realizada para reiniciar o servidor de aplicação indicado.

– Vzctl restart $id;

• Pré-condição: O servidor deve estar com o status “running”.

• Pós-condição: O servidor é reiniciado, todos seus processos são reiniciados.

7. Consultar o status do servidor de aplicação

• Descrição da ação: Essa ação retorna o status do servidor de aplicação, consul-tando se o servidor se encontra iniciado ou parado.

• Parâmetros:


• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzlist. A seguinte chamadaprecisa ser realizada para consultar o status do servidor de aplicação indicado.

– Vzlist $id -Ho status;

• Pré-condição: O servidor de aplicação deve estar criado para que seja consultadoseu status.


• Pós-condição: O método retorna a string indicando o status do servidor.

8. Redimensionar espaço em disco de um servidor de aplicação

• Descrição da ação: Essa ação redimensiona em tempo real o espaço em discoalocado para um servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ser manipulado.– DiskMin:Inteiro: Valor que determina a quantidade mínima de espaço em

disco o servidor de aplicação poderá fazer uso. O valor passado será emGigabytes.

– DiskMax:Inteiro: Valor que determina a quantidade máxima de espaço emdisco o servidor de aplicação poderá fazer uso. O valor passado será emGigabytes.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. Os seguintes passosprecisam ser realizados para efetuar a manipulação do espaço em disco servidorde aplicação indicado.

– Checa se o valor passado não é menor que o espaço já utilizado pelo servidor.Com isso, não é possível reduzir o disco a um valor que já está em uso.

– Variável recebe valor do comando (vzlist $id -Ho diskspace) e é passada nafunção que retorna o valor em Gigabytes.

– Se o valor $diskmin for maior que obtido no passo anterior, executa opróximo passo.

– vzctl set $id –diskspace $diskminG:$diskmaxG –save

• Pré-condição: O valor a ser alterado de armazenamento não pode ser menorque o já utilizado pelo servidor de aplicação.

• Pós-condição: O servidor terá seu novo valor de espaço em disco após a mani-pulação.

9. Redimensionar memória ram de um servidor de aplicação

• Descrição da ação: Essa ação redimensiona a quantidade de memória RAMalocada para um servidor de aplicação em tempo real.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ter recurso manipulado.– Ram:Inteiro: Quantidade de memória RAM do hardware que será alocada

para o servidor de aplicação. O valor trabalhado será em GB.


• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. Os seguintes passosprecisam ser realizados para efetuar a manipulação da memória RAM noservidor de aplicação indicado.

– Checa se o valor passado não é menor que a quantidade de memória queestá em uso com o seguinte comando:

– vzctl exec $id free -g | grep "Mem: awk ’print $3’– Caso o valor passado em $ram seja maior, executa o próximo passo.– vzctl set $id –ram $ramG –save

• Pré-condição: A quantidade de memória RAM manipulada não pode ser menorque a quantidade da memória que está em uso.

• Pós-condição: O servidor disponibilizará da quantidade de memória RAMalocada com a manipulação.

10. Redimensionar memória Swap de um servidor de aplicação

• Descrição da ação: Essa ação redimensiona a quantidade de memória Swapalocada para um servidor de aplicação em tempo real.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ter recurso manipulado.– Swap:Inteiro: Quantidade de memória Swap do hardware que será alocada

para o servidor de aplicação. O valor trabalhado será em GB.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. Os seguintes passosprecisam ser realizados para efetuar a manipulação da memória Swap noservidor de aplicação indicado.

– Checa se o valor passado não é menor que a quantidade de memória queestá em uso com o seguinte comando:

– vzctl exec $id free -g | grep "Swap: awk ’print $3’ Caso o valor passadoem $swap seja maior, executa o próximo passo. vzctl set $id –ram $swapG–save

• Pré-condição: A quantidade de memória Swap manipulada não pode ser menorque a quantidade da memória que está em uso.

• Pós-condição: O servidor disponibilizará da quantidade de memória Swapalocada com a manipulação.

11. Redimensionar limite de uso do CPU por servidor de aplicação


• Descrição da ação: Essa ação altera o limite de utilização do CPU para umservidor de aplicação em tempo real.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação a ter recurso manipulado.– Cuplimit:Inteiro: Um número inteiro positivo que indica o percentual de

tempo de utilização do CPU por servidor de aplicação.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamadaprecisa ser realizada para efetuar a manipulação do cpulimit no servidor deaplicação indicado.

– Vzctl set $id –cpulimit $cpulimit –save;

• Pré-condição: É recomendado que essa alteração seja feita considerando aquantidade de cpulimit distribuída entre os outros servidores de aplicação e aquantidade de núcleos de CPU do hardware, pois essa informação determina oquanto de cpulimit pode ser distribuído entre os servidores de aplicação.

• Pós-condição: O servidor recebe um novo limite de utilização do CPU.

12. Incluir servidores de aplicação nos grupos do LTSP-Cluster

• Descrição da ação: Essa ação inclui um servidor de aplicação no serviço LTSP-Cluster dentro do grupo (laboratório) indicado.

• Parâmetros:

– Grupo:String: Determina em qual dos laboratórios o servidor será incluído.– IP:String: Indica o IP do servidor incluído.– Nameserver:String: Indica o Nameserver do servidor incluído.

• Implementação: Esta ação é implementada através de um agente ConManagerescrito em PHP com a biblioteca de alteração de XML DOM. O agente recebeos dados providos pelo ConManager e faz a inserção do servidor no grupoindicado. Os seguintes passos serão seguidos:

– O agente ConManager recebe os dados da ação inserir novo servidor.– Realiza a ação #6 consultando o status do servidor.– Se o servidor estiver com o status “running”, o agente prossegue na inserção

do servidor no arquivo de configuração do LTSP-Cluster.

• Pré-condição: Não poderá criar novos grupos a partir do agente, somente ainserção de servidores em grupos já existentes. Antes de inserir um novo servidor,é recomendado verificar o status do servidor, consultando se ele está ativo.


• Pós-condição: O arquivo de configuração do serviço LTSP-Cluster tem o servidorincluído.

13. excluir servidores de aplicação nos grupos do LTSP-Cluster

• Descrição da ação: Essa ação exclui um servidor de aplicação no serviço LTSP-Cluster dentro do grupo (laboratório) indicado.

• Parâmetros:

– Grupo:String: Determina em qual dos laboratórios o servidor será excluído.– IP:String: Indica o IP do servidor excluído.– Nameserver:String: Indica o Nameserver do servidor excluído.

• Implementação: Esta ação é implementada através de um agente ConManagerescrito em PHP com a biblioteca de alteração de XML DOM. O agente recebeos dados providos pelo ConManager e faz a exclusão do servidor no grupoindicado. Os seguintes passos serão seguidos:

– O agente ConManager recebe os dados da ação excluir servidor.– Realiza a ação #6 consultando o status do servidor.– Se o servidor estiver com o status “stopped”, o agente prossegue na exclusão

do servidor no arquivo de configuração do LTSP-Cluster.

• Pré-condição: Não será possível excluir grupos a partir do agente, somenteexcluir servidores em grupos já existentes. Será feita a verificação se o servidorestá parado antes de excluí-lo.

• Pós-condição: O arquivo de configuração do serviço LTSP-Cluster tem o servidorexcluído.

14. Reiniciar serviço LTSP-Cluster

• Descrição da ação: Essa ação retorna os dados referentes ao armazenamentoutilizado pelo servidor de aplicação.

• Parâmetros:Não há parâmetros exigidos

• Implementação: Esta ação é implementada pelo agente ConManager que ma-nipula o arquivo de configuração do serviço, através de um método com ocomando bash que reinicia o serviço.

• Pré-condição:Antes do método reiniciar o serviço, deve ser consultado o númerodo processo (PID) do LTSP-Cluster e comparar com o PID após o serviço serreiniciado.

• Pós-condição: O serviço LTSP-Cluster é reiniciado e a confirmação da ação éretornada pelo método.


15. Consultar status de armazenamento por servidor de aplicação

• Descrição da ação: Essa ação retorna os dados referentes ao armazenamentoutilizado pelo servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação com o status consultado.– Tipo: String: Identifica que tipo de dados será retornado. Podendo variar

entre alocado, livre e usado.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzctl exec. A seguinte chamadaprecisa ser realizada para para retornar os valores da utilização do espaço emdisco. Todos os valores serão trabalhados em Gigabytes.

– Será retornado o valor do espaço alocado ao servidor utilizando o seguintecomando:

– vzctl exec $id df -h | awk ’print $2’ | sed -n ’2p’– Será retornado o valor do espaço em uso do servidor utilizando o seguinte

comando:– vzctl exec $id df -h | awk ’print $3’ | sed -n ’2p’– Será retornado o valor do espaço livre do servidor utilizando o seguinte

comando: vzctl exec $id df -h | awk ’print $4’ | sed -n ’2p’

• Pré-condição: Para que seja consultado o valor do espaço em disco alocado aoservidor, é necessário que ele esteja criado. De acordo com o tipo, o métodoretorna um dos dados consultados.

• Pós-condição: O método informa os dados referente ao armazenamento.

16. Consultar o cpulimit de um servidor de aplicação

• Descrição da ação:Essa ação retorna a informação referente ao poder de pro-cessamento em cpuunits do hardware e a quantidade utilizada no momento daconsulta.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação com o status consultado.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uma leitura ao arquivo de configuração do servidor de aplicaçãoe retornando o valor de CPULIMIT.

– vzlist $id -o cpulimit

• Pré-condição: É necessário que o servidor de aplicação esteja criado.


• Pós-condição: O método retorna a quantidade de CPULIMIT alocado para oservidor de aplicação.

17. Consultar se um servidor de aplicação está inserido no LTSP-Cluster

• Descrição da ação: Essa ação retorna se um servidor de aplicação está inseridono LTSP-Cluster e em qual grupo (laboratório).

• Parâmetros:

– IP:String: Procura no arquivo pelo ip indicado.

• Implementação: Essa ação é implementada através de um comando via ssh aoservidor que hospeda o serviço LTSP-Cluster. O retorno é a quantidade delinhas que o parâmetros desejado aparece, indicando se o arquivo tem o servidorconfigurado.

– cat lbsconfig.xml | grep "$ip wc -l

• Pré-condição: O serviço LTSP-Cluster precisa estar configurado.

• Pós-condição: O método retorna a quantidade de linhas que o IP aparece noarquivo de configuração.

18. Consultar a quantidade de memória RAM por servidor de aplicação

• Descrição da ação: Essa ação retorna a informação referente à quantidade dememória RAM utilizada por um servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação com o status consultado.– Tipo:String: Identifica se o retorno será informações de memória alocada,

livre ou utilizada.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso do comando vzctl exec, que retorna os dados referente autilização da memória RAM em um servidor de aplicação. O retorno dos dadosserão em GB.

– Se o $tipo for “alocada”, é executado o seguinte comando no método: vzctlexec $id free -g | grep "Mem: awk ’print $2’

– Se o $tipo for “livre”, é executado o seguinte comando no método: vzctlexec $id free -g | grep "Mem: awk ’print $3’

– Se o $tipo for “utilizada”, é executado o seguinte comando no método: vzctlexec $id free -g | grep "Mem: awk ’print $4’



• Pós-condição: O método retorna a quantidade de memória (alocada, livre ouutilizada).

19. Consultar a quantidade de memória Swap por servidor de aplicação

• Descrição da ação: Essa ação retorna a informação referente à quantidade dememória RAM utilizada por um servidor de aplicação.

• Parâmetros:

– ID:Inteiro: Identificador do servidor de aplicação com o status consultado.– Tipo:String: Identifica se o retorno será informações de memória alocada,

livre ou utilizada.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso do comando vzctl exec, que retorna os dados referente autilização da memória RAM em um servidor de aplicação. O retorno dos dadosserão em GB.

– Se o $tipo for “alocada”, é executado o seguinte comando no método: vzctlexec $id free -g | grep "Swap: awk ’print $2’

– Se o $tipo for “livre”, é executado o seguinte comando no método: vzctlexec $id free -g | grep "Swap: awk ’print $3’

– Se o $tipo for “utilizada”, é executado o seguinte comando no método: vzctlexec $id free -g | grep "Swap: awk ’print $4’



20. Consultar a quantidade de memória RAM do hardware

• Descrição da ação: Essa ação retorna a informação referente à quantidade dememória RAM utilizada do hardware.

• Parâmetros:

– Tipo:String: Identifica se o retorno será informações de memória alocada,livre ou utilizada.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso do comando bash, que retorna os dados referente autilização da memória RAM do hardware. O retorno dos dados serão em GB.

– Se o $tipo for “alocada”, é executado o seguinte comando no método: free-g | grep "Mem: awk ’print $2’ Se o $tipo for “livre”, é executado o seguintecomando no método: free -g | grep "Mem: awk ’print $3’ Se o $tipo for


“utilizada”, é executado o seguinte comando no método: free -g | grep"Mem: awk ’print $4’

• Pré-condição: O sistema operacional precisa estar instalado corretamente nohardware.


21. Consultar a quantidade de memória Swap do hardware

• Descrição da ação: Essa ação retorna a informação referente à quantidade dememória Swap utilizada do hardware.

• Parâmetros:

– Tipo:String: Identifica se o retorno será informações de memória alocada,livre ou utilizada.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso do comando bash, que retorna os dados referente autilização da memória Swap do hardware. O retorno dos dados serão em GB.

– Se o $tipo for “alocada”, é executado o seguinte comando no método: free-g | grep "Swap: awk ’print $2’

– Se o $tipo for “livre”, é executado o seguinte comando no método: free -g |grep "Swap: awk ’print $3’

– Se o $tipo for “utilizada”, é executado o seguinte comando no método: free-g | grep "Swap: awk ’print $4’

• Pré-condição:O sistema operacional precisa estar instalado corretamente nohardware.


22. Consultar status de armazenamento do hardware

• Descrição da ação: Essa ação retorna os dados referentes ao armazenamentoutilizado pelo hardware.

• Parâmetros:

– Tipo: String: Identifica que tipo de dados será retornado. Podendo variarentre alocado, livre e usado.

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando bash. A seguinte chamadaprecisa ser realizada para para retornar os valores da utilização do espaço emdisco no hardware. Todos os valores serão trabalhados em Gigabytes.


– Se o $tipo for “alocado”, será retornado o valor do espaço alocado aoservidor utilizando o seguinte comando: df -h | awk ’print $2’ | sed -n ’2p’

– Se o $tipo for “usado”, será retornado o valor do espaço em uso do servidorutilizando o seguinte comando: vzctl exec $id df -h | awk ’print $3’ | sed -n’2p’

– Se o $tipo for “livre”, será retornado o valor do espaço livre do servidorutilizando o seguinte comando: vzctl exec $id df -h | awk ’print $4’ | sed -n’2p’

• Pré-condição: Para que seja consultado o valor do espaço em disco alocado aoservidor, é necessário que ele esteja criado. De acordo com o tipo, o métodoretorna um dos dados consultados.

• Pós-condição: O método informa os dados referente ao armazenamento.

23. Consultar os contêineres utilizados como servidor de aplicação

• Descrição da ação: Essa ação retorna os identificadores de todos os contêineresativos que são utilizados como servidor de aplicação

• Parâmetros: Não há parâmetros exigidos

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando vzlist. A seguinte chamadaprecisa ser realizada para para retornar os identificadores dos contêineres quesão utilizados como servidor de aplicação:

– vzlist | grep ltsp-appserv[0-9] | awk ’print $1’

• Pré-condição: É necessário que os contêineres estejam ativos e seu hostnamecomecem pelo padrão “ltsp-appserv”.

• Pós-condição: O método todos os contêineres ativos e que são utilizados comoservidor de aplicação.

24. Consultar a quantidade de núcleos de cpu do hardware para determinar cpulimit

• Descrição da ação: Essa ação retorna a quantidade de núcleos de cpu dohardware, pois com base nesse dado que descobrimos o cpulimit que podemosratear entre os servidores de aplicação.

• Parâmetros: Não há parâmetros exigidos

• Implementação: Esta ação é implementada através de um método da APIOpenVZ fazendo uso de chamadas ao comando bash. A seguinte chamada precisaser realizada para para retornar a quantidade de núcleos de cpu disponível nohardware. O método precisa multiplicar por 100, para chega na quantidadedisponível de cpulimit.


– egrep "p̂rocessor"/proc/cpuinfo | wc -l– Multiplicar por 100 e retornar o valor.

• Pré-condição: É necessário que o hardware e o S.O. estejam funcionando nor-malmente.

• Pós-condição: É informado a quantidade exata de cpulimit que será possíveldividir entre os servidores de aplicação.

104

B Apêndice - Casos de uso

Nesse Apêndice são reunidos todos os casos de uso do ConManager. Os modelos decaso de uso utilizados neste trabalho seguem os princípios descritos em Bezerra (2007). Oscasos de uso serão apresentados em cenários, que são descrições de utilização funcionalidadesdo sistema, com detalhamento de atores, objetivos, precondições e fluxo principal.

Diagrama caso de uso 1 – Cadastrar infraestrutura: O diagrama de caso de usoexposto na Figura 28 exibe um cenário que descreve a utilização do ConManager paracadastrar a infraestrutura DaaS na base de dados do sistema. Os casos de uso que compõemesse cenário tem o objetivo geral de tornar o ConManager conhecedor e integrado aosservidores, ferramentas externas e APIs. Dessa forma o sistema consegue interagir noambiente e realizar as adaptações necessárias quando detectada uma sobrecarga.

Figura 28 – Caso de uso ilustrando a interação do usuário no cenário de cadastrar infraestrutura

CSU01 – Cadastrar monitorObjetivo: Inserir no sistema os dados referente à ferramenta que monitora o ambiente deservidores do DaaS. Dessa forma o ConManager consegue se integrar à ferramenta por

Apêndice B. Apêndice - Casos de uso 105

meio de uma API disponibilizada.Atores: Administrador do ConManager.Precondições: A ferramenta de monitoramento deve estar previamente instalada econfigurada na mesma faixa de rede dos servidores monitorados. O ator deverá terconhecimento das credenciais de acesso da ferramenta.Fluxo principal:

1. Usuário seleciona a funcionalidade de cadastrar monitor.

2. O sistema exibe o formulário que solicita as credenciais de acesso à ferramenta demonitoramento.

3. O usuário informa as credenciais e clica no botão para testar a conexão.

4. O sistema apresenta a mensagem que a conexão foi estabelecida.

5. O usuário clica no botão para salvar os dados.

6. O sistema guarda os dados em sua base.

CSU02 – Listar e cadastrar agentes existentesObjetivo: Listar e cadastrar no sistema os dados de agentes que já existem nos servidoresenvolvidos no cenário DaaS.Atores: Administrador do ConManager.Precondições: É necessário a instalação e configuração do agente da ferramenta demonitoramento no servidor monitorado. Também se faz necessária a configuração dosagentes de monitoramento nos servidores monitorados na ferramenta de monitoramento.Fluxo principal:

1. O usuário seleciona a funcionalidade de listar e cadastrar agentes existentes.

2. O sistema exibe a lista de agentes cadastrados na ferramenta de monitoramento.

3. O usuário escolhe um dos itens.

4. O sistema exibe o formulário contendo as informações do agente.



CSU03 – Cadastrar agenteObjetivo: Cadastrar agentes na ferramenta de monitoramento através do ConManager.Atores: Administrador do ConManager.Precondições: A ferramenta de monitoramento deve estar inserida no ConManager.Fluxo principal:


1. O usuário seleciona a funcionalidade de cadastrar agente.

2. O sistema exibe um formulário que solicita os dados do novo agente como IP, nomee porta.

3. O usuário informa os dados do novo agente.


5. 0 O sistema guarda os dados em sua base.

CSU04 – Cadastrar servidor hardwareObjetivo: Inserir no sistema os dados referente ao servidor hardware que hospeda oscontêineres (servidores de aplicação) do DaaS.Atores: Administrador do ConManager.Precondições: O usuário informado no ConManager deve ter privilégios de administradordo ambiente no servidor hardware. O servidor hardware deve aceitar conexões SSH.Fluxo principal:

1. O usuário seleciona a funcionalidade de cadastrar servidor hardware.

2. O sistema exibe um formulário que solicita as credenciais do servidor hardware.

3. O usuário informa as credenciais.

4. O usuário clica no botão para testar a conexão.

5. O sistema exibe a mensagem que a conexão foi realizada com sucesso e exibe novoscampos no formulário contendo informações sobre a quantidade de recursos nohardware. As informações recuperadas do hardware são: quantidade de memóriaRAM, SWAP, espaço em disco e quantidade de núcleos de CPU.

6. O usuário indica qual é o agente responsável pelo monitoramento do hardware atravésdo CSU06.



CSU05 – Listar e cadastrar servidores de aplicaçãoObjetivo: Listar e cadastrar os servidores de aplicação (contêineres) que já existem nohardware. Com isso, o ConManager identifica os contêineres que pode adaptar a quantidadede recursos para responder às sobrecargas no ambiente.Atores: Administrador do ConManager.Precondições: Os servidores de aplicação devem estar previamente configurados no


gerenciador de contêiner e em funcionamento.Fluxo principal:

1. O usuário seleciona a funcionalidade de listar e cadastrar servidores.

2. O sistema exibe uma lista de servidores de aplicação existentes no gerenciador decontêiner.

3. O usuário escolhe um dos itens.

4. O sistema exibe o formulário contendo as informações do servidor de aplicação (comoquantidade de recursos)

5. O usuário informa ao sistema se o servidor é destinado pertence a um laboratóriodestinado à aula ou ao uso geral dos alunos.

6. O usuário indica qual é o agente responsável pelo monitoramento do servidor deaplicação através do CSU06.



CSU06 – Definir agenteObjetivo: Indicar qual o agente cadastrado no ConManager é o responsável por coletaros dados do monitoramento do servidor em questão.Atores: Administrador do ConManager.Precondições: É necessário o cadastro prévio do agente no ConManager.Fluxo principal:

1. O usuário clica no botão para listar os agentes cadastrados.

2. O sistema exibe a lista de agentes.

3. O usuário clica no item de sua escolha.

CSU07 – Cadastrar grupoObjetivo: Representar a estrutura de grupos e servidores presente no arquivo de configu-ração do LTSP-Cluster.Atores: Administrador do ConManager.Precondições: O servidor de aplicação que hospeda o LTSP-Cluster deve estar cadastradono ConManager.Fluxo principal:

1. O usuário seleciona a funcionalidade de cadastrar grupo.


2. O sistema exibe a lista de servidores de aplicação cadastrados no ConManager.

3. O usuário seleciona o servidor de aplicação que hospeda o LTSP-Cluster

4. O usuário executa o CSU08.

5. O usuário clica no botão para cadastrar o grupo no ConManager.


CSU08 – Exportar dados XMLObjetivo: Recuperar os dados presentes no arquivo de configuração do LTSP-Cluster efacilitar o cadastro de grupos no ConManager.Atores: Administrador do ConManager.Precondições: O serviço LTSP-Cluster deve estar configurado indicando os grupos quesegmentam o balanceamento de carga entre os servidores.Fluxo principal:

1. O usuário clica no botão para exportar os dados do arquivo de configuração

2. O sistema exibe uma lista de grupos e quais servidores de aplicação pertencem aosgrupos.

Diagrama caso de uso 2 – Realizar intervenção: O diagrama caso de uso na Figura29 mostra o cenário que descreve a ação de fazer uma intervenção (alterar quantidade derecursos nos servidores de aplicação) no ConManager. Os casos de uso desse diagramaexplicam a interação usuário/sistema na utilização dessa funcionalidade.


Figura 29 – Caso de uso ilustrando a interação do usuário no cenário de realizar intervenção

CSU09 – Fazer intervençãoObjetivo: Aumentar ou diminuir recursos em um servidor de aplicação.Atores: Administrador do ConManager.Precondições: O servidores de hardware e aplicação devem estar cadastrados no ConMa-nager.Fluxo principal:

1. O usuário seleciona a funcionalidade Fazer intervenção.

2. O sistema exibe o formulário que solicita informações sobre a intervenção.

3. O usuário seleciona em qual hardware será feita a intervenção.

4. O sistema abre a opção de escolher qual o tipo de recurso (CPU, memória ou disco).

5. O usuário seleciona o tipo de recurso (ex. Memória).

6. O sistema abre a opção de escolher qual o recurso que pertence ao tipo escolhido(ex. Ram e SWAP).

7. O usuário escolher qual servidor de aplicação será feita a intervenção.

8. O usuário executa o CSU10.

9. O usuário informa a quantidade de recurso a ser manipulado.

10. O usuário indica se a ação será de retirar ou adicionar.

11. O usuário clica no botão para efetuar a intervenção.


12. O sistema aplica as mudanças no gerenciador de contêiner

13. O sistema registra as informações intervenção e as guarda na base de dados com ostatus: “em aberto”.

CSU10 – Buscar recursoObjetivo: Recuperar a quantidade de recurso alocado para um servidor de aplicação.Atores: Administrador do ConManager.Precondições: O servidor de aplicação deve estar cadastrado no ConManager.Fluxo principal:

1. O usuário seleciona a funcionalidade de Buscar recurso.

2. O sistema exibe a quantidade de recurso presente no servidor de aplicação indicado.

CSU11 – ConsolidarObjetivo: Atualizar o valor referência da quantidade de recursos para um servidor deaplicação.Atores: Administrador do ConManager.Precondições: O status da intervenção escolhida deve ser “em aberto”.Fluxo principal:

1. O usuário escolhe uma das intervenções com o status “em aberto”.

2. . O sistema exibe o formulário com as informações da intervenção preenchidas.

3. O usuário clica no botão “consolidar”.

4. O sistema altera os dados da quantidade de recursos de um servidor de aplicação nasua base.

CSU12 – ReverterObjetivo: Reverter as configurações referente à quantidade de recursos de um servidorde aplicação, para que ela retorne aos valores de referência.Atores: Administrador do ConManager.Precondições: O status da intervenção escolhida deve ser “em aberto”. Fluxo principal:

1. O usuário escolhe uma das intervenções com o status “em aberto”.

2. O sistema exibe o formulário com as informações da intervenção preenchidas.

3. O usuário clica no botão “reverter”.


4. O sistema altera a quantidade de recursos de um servidor de aplicação por meio domódulo de execução.

5. O sistema atualiza na base de dados que a intervenção foi revertida.

Diagrama caso de uso 3 – Utilização da tela principal: A Figura 30 exibe odiagrama de caso de uso no qual descreve a utilização da tela principal do ConManager.Os casos de uso desse cenário demonstram o funcionamento do sistema e a interação como usuário na funcionalidade mais utilizada.

Figura 30 – Caso de uso ilustrando a interação do usuário na utilização da tela principal

CSU13 – Visualizar alarmesObjetivo: Exibir os alarmes recém-disparados, juntamente com um sinal sonoro.Atores: Administrador do ConManager.Precondições: Um novo alarme deve estar ativo para ser visualizado.Fluxo principal:

1. O sistema fica em constante monitoramento de novos alarmes. Assim que um alarmeé criado, o sistema o exibe, chamando a atenção do administrador.

2. O ator pode escolher entre CSU14, CSU15 ou CSU16.

CSU14 – Fazer intervenção manualObjetivo: Solucionar a sobrecarga apontada pelo alarme através de uma intervençãomanual.


Atores: Administrador do ConManager.Precondições: O servidores de hardware e aplicação devem estar cadastrados no ConMa-nager.Fluxo principal:

1. O usuário seleciona a funcionalidade Fazer intervenção manual.

2. O sistema encaminha o usuário para o CSU09.

CSU15 – Ignorar alarmeObjetivo: Ignorar a chamada visual e sonora do alarme.Atores: Administrador do ConManager.Precondições: Um novo alarme deve estar ativo para ser visualizado nessa funcionalidade.Fluxo principal:

1. O usuário seleciona a funcionalidade Ignorar alarme.

2. O sistema atualiza na base de dados que o alarme foi ignorado.

3. O sistema não exibe mais o alarme ignorado.

CSU16 – Chamar planejamentoObjetivo: Solucionar a sobrecarga apontada pelo alarme através do módulo de planeja-mento.Atores: Administrador do ConManager.Precondições: O servidores de hardware e aplicação devem estar cadastrados no Con-Manager. A API da ferramenta de monitoramento deverá estar integrada ao ConManager.A API do Google Agenda deverá estar integrada ao ConManager.Fluxo principal:

1. O usuário seleciona a funcionalidade Chamar planejamento.

2. O sistema exibe as ações necessárias para adaptar o ambiente e resolver o problemade sobrecarga.

3. O usuário aceita as ações propostas clicando nos botões para efetuar a ação.

4. O sistema efetua as ações e adaptam os recursos de acordo com os parâmetrospassados pelo módulo de planejamento.

CSU17 – Visualizar gráficosObjetivo: Visualizar os gráficos de monitoramento.Atores: Administrador do ConManager.


Precondições: Os gráficos da ferramenta de monitoramento devem estar organizados emuma única tela para ser exibido no ConManager.Fluxo principal:

1. O usuário seleciona a funcionalidade Visualizar gráficos.

2. O sistema exibe a tela com os gráficos.

3. O usuário navega nessa tela, visualizando os gráficos de monitoramento de todos osservidores.

CSU18 – Visualizar distribuição de recursos.Objetivo: Visualizar a distribuição de recursos do hardware entre os servidores de aplica-ção.Atores: Administrador do ConManager.Precondições: O ConManager precisa consultar o hardware, o gerenciador de contêinere a API da ferramenta de monitoramento para coletar os dados necessários. Toda ainfraestrutura deve estar funcionando corretamente.Fluxo principal:

1. O usuário seleciona a funcionalidade Visualizar distribuição de recursos.

2. O sistema exibe a tela com os dados da distribuição.

3. O usuário navega nessa tela, visualizando a distribuição de recursos entre os servido-res.

CSU19 – Visualizar horário de aulasObjetivo: Visualizar a tabela de horário das aulas do dia.Atores: Administrador do ConManager.Precondições: A internet deve estar funcionando. A API do Google agenda precisa estarconfigurada para recuperar os horários das aulas.Fluxo principal:

1. O usuário seleciona a funcionalidade Visualizar horários.

2. O sistema exibe a tela com os horários das aulas.

3. O usuário navega nessa tela, visualizando as aulas que estão acontecendo agora e atabela de horário do dia, separada por laboratório.

114

C Apêndice - Diagramas de classes

Os diagramas de classes apresentados nesse Apêndice foram organizados de maneiraque ilustre o relacionamento entre as classes nas principais funcionalidades do ConManager.As classes representam as principais entidades do ConManager que são os servidores dehardware, servidores de aplicação, monitores, agentes, grupos, intervenções e o planeja-mento. A seguir estão quatro diagramas que mostram como elas foram implementadas.

Figura 31 – Diagrama de classe dos servidores hardware e aplicação

O diagrama de classe da Figura 31 representam as classes que implementaram o

Apêndice C. Apêndice - Diagramas de classes 115

servidor hardware e o servidor de aplicação. a classe ServidorHardware utiliza a classeConectaSSH para coletar dados do hardware e também possui uma classe filha Geren-ciadorConteiner, que herda seus atributos e métodos, só que a sua responsabilidade émanipular a camada de virtualização do OpenVZ. A classe ServidorAplicacao tem opapel de representar os servidores de aplicação contidos no OpenVZ. Essa classe se ligaà classe Grupo com o intuito de representar a estrutura do arquivo de configuração doLTSP-Cluster, onde cada grupo tem um conjunto de servidores de aplicação. A classeAgente está ligada ao servidor hardware e ao servidor aplicação por meio de seu atributoidentificador, representando a ligação existente com o Zabbix.

Figura 32 – Diagrama de classe do monitor e agente

Na Figura 32, o diagrama de classe representa a implementação do monitor edo agente no ConManager. A classe Monitor_controller é a responsável por fazer acomunicação do usuário do sistema com o Zabbix. A classe ApiZabbix reúne todos osmétodos necessários para o ConManager interagir com a ferramenta de monitoramento.Essa classe antede requisições tanto do Monitor_controller quanto do Agente_controller.

O diagrama apresentado na Figura 33 ilustra o conjunto de classes utilizadas paraa implementação das intervenções. A classe Intervencao reúne os atributos utilizadospara fazer a manipulação de recursos no OpenVZ. A classe GerenciadorConteiner utiliza


Figura 33 – Diagrama de classe da intervenção

de comandos da ferramenta vzctl do OpenVZ para executar os comandos de adapta-ção nos contêineres. Todas as mudanças feitas nos contêineres são refletidas na classeServidorAplicacao.

O módulo de planejamento está representado no diagrama de classe da Figura34. A classe Planejamento faz consulta às diversas outras classes como ApiGoole paraconsultar os horários das aulas, IntervencaoDao para verificar se há intervenções cadas-tradas para um contêiner, MonitorDao para retornar as credenciais para acessar a classeApiZabbix e coletar dados da utilização dos laboratórios. As classes ServidorHardwareDaoe ServidorAplicacaoDao são necessárias para recuperar os dados inseridos na base dedados.


Figura 34 – Diagrama de classe de planejamento

118

D Apêndice - Diagramas de sequência

Os diagramas de sequências apresentados neste Apêndice mostram a interaçãoentre os componentes exibidos na Figura 13. Para isso, foram divididos em três diagramasque mostram o comportamento dos componentes na fase de monitoramento, análise,planejamento e execução.

O diagrama de sequência exibido na Figura 35 mostra o comportamento entreos componentes responsáveis pelo módulo de monitoramento. Os componentes AgenteZabbix, Monitor Zabbix, Script e Módulo Análise são representados em linhas verticais querepresentam o tempo de vida do objeto. O componente Agente Zabbix instalado em cadaum dos servidores de aplicação e no hardware se comunica com o Monitor Zabbix enviandoos dados monitorados nesses ambientes (mensagem 1). O Monitor Zabbix analisa todos osdados coletados constantemente (mensagem 2). Se identificar alguma sobrecarga, disparao gatilho (mensagem assíncrona 3) passando os dados referente ao servidor sobrecarregadopara o componente Script. Ele, por sua vez cria alertas na base de dados do ConManager(mensagem 3.1) com todas as informações recebidas. Como o Monitor Zabbix não parasua análise dos dados, quando percebe que os dados coletados do objeto sobrecarregadoindicam que não há mais sobrecarga, é disparado um novo gatilho (mensagem assíncrona4) informando que a sobrecarga foi solucionada. O Script, por consequência retira o statusde aberto para o alerta no ConManager (mensagem 4.1), dando o alerta como solucionado.

Figura 35 – Diagrama de sequência que mostra o comportamento dos componentes demonitoramento

O diagrama de sequência mostrado da Figura 36 representa o comportamento dos

Apêndice D. Apêndice - Diagramas de sequência 119

componentes utilizados no módulo de análise. O componente Módulo Análise consultaconstantemente na base de dados verificando a existência de novos alertas (mensagens 1 e1.1). Quando um novo alerta surge, a tabela de horários é consultada no Google Agenda(mensagens 2 e 2.1), bem como o Módulo Monitoramento é consultado para que atravésdos dados coletados seja possível identificar a carga de utilização de todos os contêineres(mensagens 3 e 3.1) e do hardware (mensagens 4 e 4.1). Uma última consulta é feita aobanco de dados para saber se existe alguma redistribuição de recursos que não foi revertidaou consolidada , chamada de intervenção em aberto (mensagens 5 e 5.1). Depois de todosesses dados reunidos, é enviado para o componente Interface Web (mensagem 6) o resumode todas essas informações.

Figura 36 – Diagrama de sequência que mostra o comportamento dos componentes domódulo de análise

O diagrama de sequência exibido na Figura 37 mostra a interação entre os compo-nentes dos módulos de planejamento e execução, a partir do ponto que o administradordecide chamar o módulo de planejamento para auxiliar na tomada de decisão atravésda interface web. A figura contempla apenas a ação de manipular o OpenVZ, mas essecomportamento é o mesmo para a manipulação do LTSP-Cluster. Quando o administradorclica no botão para chamar o planejamento, o módulo é acionado pela interface webque passa as informações como a carga de utilização (ou status) dos contêineres e dohardware, bem como a tabela de horários (mensagem 1). O módulo de planejamentotoma as decisões e retorna para a Interface Web com as ações sugeridas para aliviar asobrecarga no contêiner (mensagem 2). Ao clicar no botão para aceitar as sugestões através

Apêndice D. Apêndice - Diagramas de sequência 120

da Interface Web, esse componente aciona o módulo Execução passando as ações quedevem ser implementadas (mensagem 3). A fase de Execução se comunica com a APIOpenVZ ou com a API LTSP-Cluster (mensagem 3.1), que por sua vez faz a manipulaçãodireta no OpenVZ ou no LTSP-Cluster (mensagem 3.1.1). Ao final, é confirmada se aexecução foi bem sucedida e exibida na Interface Web (mensagem 4).

Figura 37 – Diagrama de sequência que mostra o comportamento dos componentes dosmódulos de planejamento e execução

121

E Apêndice - Questionário

Esse apêndice apresenta o questionário enviado aos professores para entender quaissistemas operacionais, softwares eram usados nos laboratórios, além de questionar sobrequais recursos mais influenciavam na utilização do ambiente.

O questionário enviado conteve as seguintes questões:

1. Qual sistema operacional utilizado nas aulas?

( ) Linux

( ) Windows

( ) Ambos

2. Quais programas mais utilizados na disciplina?

3. Quantos alunos estão cadastrados na turma?

4. Quais recursos computacionais são mais exigidos nos exercícios dados em aula?Escolha todos os itens mais requisitados.

( ) Memória - Grau de certeza da resposta: 1[ ], 2[ ], 3[ ], 4[ ], 5[ ]

( ) Processador - Grau de certeza da resposta: 1[ ], 2[ ], 3[ ], 4[ ], 5[ ]

( ) Rede - Grau de certeza da resposta: 1[ ], 2[ ], 3[ ], 4[ ], 5[ ]

( ) Disco -Grau de certeza da resposta: 1[ ], 2[ ], 3[ ], 4[ ], 5[ ]

122

F Apêndice - Restrições

Esse Apêndice reúne as restrições implementadas no ConManager, garantindo queo módulo de planejamento não retire todos os recursos de um contêiner ou monopolize osrecursos a uma única instância.

Restrições para diminuir recursos alocados aos servidores de aplicação desti-nado à aulas:





Quando o status do contêiner a ter recursos retirados for "pouco uso":




Restrições para diminuir recursos alocados aos servidores de aplicação desti-nados ao uso geral:


• Cpu: Não pode ficar com menos de 100 cpulimit (6.25% do nó de hardware)



Quando o status do contêiner a ter recursos retirados for "pouco uso":

• Cpu: Não pode ficar com menos de 200 cpulimit (12.5% do nó de hardware)



Apêndice F. Apêndice - Restrições 123

Restrições para acréscimo de recurso a um servidor de aplicação:

• Cpu: Não pode ficar com mais de 960 cpulimit (60% do nó de hardware)

• Ram: Não pode ficar com mais de 50% da memória física do nó de hardware (40 GB)

124

Referências

BANIK, T.; GERLACH, H.; LIST, S.; TALANIS, T.; TROSTER, T.; VOLKMANN,F. System for virtual process interfacing via a remote desktop protocol (rdp).Google Patents, 2006. US Patent App. 10/527,913. Disponível em: <https://www.google.com/patents/US20060142878>. Citado na página 14.

BARNA, C.; KHAZAEI, H.; FOKAEFS, M.; LITOIU, M. Delivering elastic containerizedcloud applications to enable devops. In: IEEE. IEEE/ACM 12th International Symposiumon Software Engineering for Adaptive and Self-Managing Systems (SEAMS). [S.l.], 2017.p. 65–75. Citado na página 80.

BERNSTEIN, D. Containers and cloud: From lxc to docker to kubernetes. IEEE CloudComputing, v. 1, n. 3, p. 81–84, Sept 2014. ISSN 2325-6095. Citado na página 76.

BERRYMAN, A.; CALYAM, P.; HONIGFORD, M.; LAI, A. M. Vdbench: A benchmarkingtoolkit for thin-client based virtual desktop environments. In: 2010 IEEE SecondInternational Conference on Cloud Computing Technology and Science. [S.l.: s.n.], 2010. p.480–487. Citado na página 79.

BEZERRA, E. Princípios de Análise e Projeto de Sistema com UML. [S.l.]: ElsevierBrasil, 2007. Citado na página 104.

CALYAM, P.; PATALI, R.; BERRYMAN, A.; LAI, A. M.; RAMNATH, R. Utility-directedresource allocation in virtual desktop clouds. Comput. Netw., Elsevier North-Holland, Inc.,New York, NY, USA, v. 55, n. 18, p. 4112–4130, dez. 2011. ISSN 1389-1286. Disponívelem: <http://dx.doi.org/10.1016/j.comnet.2011.07.019>. Citado na página 79.

CHEBIYYAM, M.; MALVIYA, R.; BOSE, S. K.; SUNDARRAJAN, S. Serverconsolidation: Leveraging the benefits of virtualization. Perform or Perish, p. 65, 2009.Citado na página 15.

CHENG, B. H.; LEMOS, R.; GIESE, H.; INVERARDI, P.; MAGEE, J.; ANDERSSON,J.; BECKER, B.; BENCOMO, N.; BRUN, Y.; CUKIC, B.; SERUGENDO, G. M.;DUSTDAR, S.; FINKELSTEIN, A.; GACEK, C.; GEIHS, K.; GRASSI, V.; KARSAI, G.;KIENLE, H. M.; KRAMER, J.; LITOIU, M.; MALEK, S.; MIRANDOLA, R.; MüLLER,H. A.; PARK, S.; SHAW, M.; TICHY, M.; TIVOLI, M.; WEYNS, D.; WHITTLE, J.Software engineering for self-adaptive systems. In: CHENG, B. H.; LEMOS, R.; GIESE,H.; INVERARDI, P.; MAGEE, J. (Ed.). Berlin, Heidelberg: Springer-Verlag, 2009. cap.Software Engineering for Self-Adaptive Systems: A Research Roadmap, p. 1–26. ISBN978-3-642-02160-2. Disponível em: <http://dx.doi.org/10.1007/978-3-642-02161-9_1>.Citado 2 vezes nas páginas 30 e 31.

COUTINHO, E.; SOUSA, F. R.; GOMES, D. G.; SOUZA, J. Elasticidade em computaçaona nuvem: Uma abordagem sistemática. XXXI Simpósio Brasileiro de Redes deComputadores e Sistemas Distribuıdos (SBRC 2013)-Minicursos, 2013. Citado na página82.

https://www.google.com/patents/US20060142878

https://www.google.com/patents/US20060142878

http://dx.doi.org/10.1016/j.comnet.2011.07.019

http://dx.doi.org/10.1007/978-3-642-02161-9_1

Referências 125

CRUZ, T.; SIMÕES, P.; BASTOS, F.; MONTEIRO, E. Integration of pxe-based desktopsolutions into broadband access networks. In: 2010 International Conference on Networkand Service Management. [S.l.: s.n.], 2010. p. 182–189. ISSN 2165-9605. Citado na página14.

ECT. PROJETO PEDAGÓGICO DE CURSO - Ciências e Tecnologia - Bacharelado(BC&T). 2010. Citado na página 14.

GARLAN, D.; CHENG, S. W.; HUANG, A. C.; SCHMERL, B.; STEENKISTE, P.Rainbow: architecture-based self-adaptation with reusable infrastructure. Computer, v. 37,n. 10, p. 46–54, Oct 2004. ISSN 0018-9162. Citado na página 81.

GIRALDEAU JEAN-MICHEL DAULT, B. d. L. F. MILLE-XTERM and LTSP. 2006.Disponível em: <http://www.linuxjournal.com/article/9097?page=0,0>. Citado 2 vezesnas páginas 7 e 29.

GOMES, D.; VERçOSA, N.; MEDEIROS, V.; GONçALVES, G. Plataforma de areas detrabalho virtuais escalável para nuvens privadas. In: Anais do WCGA 2016 Workshop deComputação em Clouds e Aplicações. [S.l.: s.n.], 2016. p. 119–132. Citado 2 vezes naspáginas 14 e 78.

GONCALVES, F. Hypervisor versus Linux Containers with Docker. 2013. Disponível em:<http://pt.slideshare.net/fasgoncalves/hypervisor-versus-linux-containers>. Citado 2vezes nas páginas 7 e 21.

HAO, F.; LAKSHMAN, T. V.; MUKHERJEE, S.; SONG, H. Enhancing dynamiccloud-based services using network virtualization. In: Proceedings of the 1st ACMWorkshop on Virtualized Infrastructure Systems and Architectures. New York, NY,USA: ACM, 2009. (VISA ’09), p. 37–44. ISBN 978-1-60558-595-6. Disponível em:<http://doi.acm.org/10.1145/1592648.1592655>. Citado na página 78.

IBM. An architectural blueprint for autonomic computing. IBM White Paper, Citeseer,v. 31, 2006. Citado na página 31.

KOLYSHKIN, K. Virtualization in linux. White paper, OpenVZ, v. 3, p. 39, 2006. Citadona página 22.

LADDAGA, R.; ROBERTSON, P. Self adaptive software: A position paper. In:CITESEER. SELF-STAR: International Workshop on Self-* Properties in ComplexInformation Systems. [S.l.], 2004. v. 31, p. 19. Citado na página 30.

LTSP, C. Concepts LTSP. 2015. Disponível em <http://wiki.ltsp.org/wiki/Concepts>.Citado na página 28.

LTSP-CLUSTER, C. LTSP-Cluster Technical Introduction. 2015. Disponível em<https://www.ltsp-cluster.org/documentation/technical-introduction>. Citado 2 vezesnas páginas 7 e 29.

MAURER, M.; BRANDIC, I.; SAKELLARIOU, R. Adaptive resource configuration forcloud infrastructure management. Future Generation Computer Systems, v. 29, n. 2,p. 472 – 487, 2013. ISSN 0167-739X. Special section: Recent advances in e-Science.Disponível em: <http://www.sciencedirect.com/science/article/pii/S0167739X12001525>.Citado 3 vezes nas páginas 15, 52 e 80.

http://www.linuxjournal.com/article/9097?page=0,0

http://pt.slideshare.net/fasgoncalves/hypervisor-versus-linux-containers

http://doi.acm.org/10.1145/1592648.1592655

http://wiki.ltsp.org/wiki/Concepts

https://www.ltsp-cluster.org/documentation/technical-introduction

http://www.sciencedirect.com/science/article/pii/S0167739X12001525

Referências 126

MCQUILLAN, J. LTSP- Linux Terminal Server Project- v4. 2004. <http://216.165.129.141/pub/ltsp/docs/ltsp-4.1.3-1-fr.pdf>. Citado na página 28.

MILLER, K.; FRANZ, F.; RITTINGHAUS, M.; HILLENBRAND, M.; BELLOSA,F. Xlh: More effective memory deduplication scanners through cross-layer hints. In:Presented as part of the 2013 USENIX Annual Technical Conference (USENIX ATC13). San Jose, CA: USENIX, 2013. p. 279–290. ISBN 978-1-931971-01-0. Disponível em:<https://www.usenix.org/conference/atc13/technical-sessions/presentation/miller>.Citado 2 vezes nas páginas 16 e 24.

MOK, R. K.; CHAN, E. W.; CHANG, R. K. Measuring the quality of experience of httpvideo streaming. In: IEEE. Integrated Network Management (IM), 2011 IFIP/IEEEInternational Symposium on. [S.l.], 2011. p. 485–492. Citado na página 85.

MORAIS, F.; BRASILEIRO, F.; LOPES, R.; ARAÚJO, R.; MACEDO, A.;SATTERFIELD, W.; ROSA, L.; GRANDE-BRASIL, C. Um arcabouço paraprovisionamento automático de recursos em provedores de iaas independente do tipo deaplicaç ao. In: SBRC. [S.l.], 2013. Citado na página 80.

MOREIRA, R. J.; COSTA, H. L. A.; JUNIOR, J. C.; SOUZA, G. M. de; LEITÃO, U. A.Terminais inteligentes: alternativa estratégica para otimização de recursos computacionais.Prefácio 5o WSL, p. 81, 2008. Citado na página 14.

MUCHALSKI, F. J. Alocação de máquinas virtuais em ambientes de computaçãoem nuvem considerando o compartilhamento de memória. Dissertação (Mestrado) —Universidade Tecnológica Federal do Paraná, 2014. Citado 2 vezes nas páginas 16 e 24.

NETO, A. C. D. Introduçao a teste de software. Engenharia de Software Magazine, v. 1,p. 22, 2007. Citado na página 69.

OLIVEIRA, R. S. de; CARISSIMI, A. da S.; TOSCANI, S. S. Sistemas Operacionais.[S.l.]: Bookman, 2010. Citado 5 vezes nas páginas 7, 19, 20, 21 e 22.

OREIZY, P.; GORLICK, M. M.; TAYLOR, R. N.; HEIMHIGNER, D.; JOHNSON,G.; MEDVIDOVIC, N.; QUILICI, A.; ROSENBLUM, D. S.; WOLF, A. L. Anarchitecture-based approach to self-adaptive software. IEEE Intelligent Systems and TheirApplications, IEEE, v. 14, n. 3, p. 54–62, 1999. Citado 4 vezes nas páginas 7, 17, 30 e 31.

PADALA, P.; SHIN, K. G.; ZHU, X.; UYSAL, M.; WANG, Z.; SINGHAL, S.; MERCHANT,A.; SALEM, K. Adaptive control of virtualized resources in utility computing environments.SIGOPS Oper. Syst. Rev., ACM, New York, NY, USA, v. 41, n. 3, p. 289–302, mar.2007. ISSN 0163-5980. Disponível em: <http://doi.acm.org/10.1145/1272998.1273026>.Citado na página 79.

PROVAZZA, A. Comparing remote display protocols: RemoteFX vs. HDX vs.PCoIP. 2013. Disponível em: <http://searchvirtualdesktop.techtarget.com/feature/Comparing-remote-display-protocols-RemoteFX-vs-HDX-vs-PCoIP>. Citado na página27.

ROSENBLUM, M. The reincarnation of virtual machines. Queue, ACM, v. 2, n. 5, p. 34,2004. Citado 2 vezes nas páginas 19 e 21.

http://216.165.129.141/pub/ltsp/docs/ltsp-4.1.3-1-fr.pdf

http://216.165.129.141/pub/ltsp/docs/ltsp-4.1.3-1-fr.pdf

https://www.usenix.org/conference/atc13/technical-sessions/presentation/miller

http://doi.acm.org/10.1145/1272998.1273026

http://searchvirtualdesktop.techtarget.com/feature/Comparing-remote-display-protocols-RemoteFX-vs-HDX-vs-PCoIP

http://searchvirtualdesktop.techtarget.com/feature/Comparing-remote-display-protocols-RemoteFX-vs-HDX-vs-PCoIP

Referências 127

ROUSE, M. virtual memory ballooning. 2014. Disponível em: <http://searchservervirtualization.techtarget.com/definition/memory-ballooning>. Citado napágina 16.

SAKDEO, S. Hypervisor Side Cache for Virtual Desktop Infrastructure. University ofCalifornia, Los Angeles, 2012. Disponível em: <https://books.google.com.br/books?id=aZ2FnQAACAAJ>. Citado na página 25.

SALEHIE, M.; TAHVILDARI, L. Self-adaptive software: Landscape and researchchallenges. ACM Trans. Auton. Adapt. Syst., ACM, New York, NY, USA,v. 4, n. 2, p. 14:1–14:42, maio 2009. ISSN 1556-4665. Disponível em: <http://doi.acm.org/10.1145/1516533.1516538>. Citado 3 vezes nas páginas 7, 32 e 44.

SCHEEPERS, M. J. Virtualization and containerization of application infrastructure: Acomparison. In: 21st Twente Student Conference on IT. [S.l.: s.n.], 2014. p. 1–7. Citado 2vezes nas páginas 7 e 21.

SHABAITAH, A. R. Server-Based Desktop Virtualization. [S.l.]: Rochester Institute ofTechnology, 2014. Citado 5 vezes nas páginas 7, 25, 26, 27 e 28.

SOLTESZ, S.; PöTZL, H.; FIUCZYNSKI, M. E.; BAVIER, A.; PETERSON, L.Container-based operating system virtualization: A scalable, high-performance alternativeto hypervisors. SIGOPS Oper. Syst. Rev., ACM, v. 41, n. 3, p. 275–287, mar. 2007. ISSN0163-5980. Disponível em: <http://doi.acm.org/10.1145/1272998.1273025>. Citado napágina 16.

SWSOFT. OpenVZ User’s Guide. 2.7.0-8. ed. 13755 Sunrise Valley Drive Suite 325Herndon, VA 20171 USA, 2005. Disponível em <https://download.openvz.org/doc/OpenVZ-Users-Guide.pdf>. Citado 3 vezes nas páginas 7, 23 e 24.

VAN, H. N.; TRAN, F. D.; MENAUD, J.-M. Autonomic virtual resource managementfor service hosting platforms. In: Proceedings of the 2009 ICSE Workshop on SoftwareEngineering Challenges of Cloud Computing. Washington, DC, USA: IEEE ComputerSociety, 2009. (CLOUD ’09), p. 1–8. ISBN 978-1-4244-3713-9. Disponível em:<http://dx.doi.org/10.1109/CLOUD.2009.5071526>. Citado na página 79.

VMWARE. ESX Server Performance and Resource Management for CPU-IntensiveWorkloads. [S.l.], 2006. Disponível em <https://www.vmware.com/pdf/ESX2_CPU_Performance.pdf>. Citado na página 16.

VMWARE, I. VMware ESX e VMware ESXi. 2009. Acessível em <https://www.vmware.com/files/br/pdf/products/VMW_09Q1_BRO_ESX_ESXi_BR_A4_P6_R2.pdf>.Citado na página 15.

WEYNS, D.; SCHMERL, B.; GRASSI, V.; MALEK, S.; MIRANDOLA, R.;PREHOFER, C.; WUTTKE, J.; ANDERSSON, J.; GIESE, H.; GÖSCHKA,K. M. On patterns for decentralized control in self-adaptive systems. In: SoftwareEngineering for Self-Adaptive Systems II. Springer, 2013. p. 76–107. Disponível em:<http://link.springer.com/chapter/10.1007/978-3-642-35813-5_4>. Citado 4 vezes naspáginas 7, 32, 33 e 42.

http://searchservervirtualization.techtarget.com/definition/memory-ballooning

http://searchservervirtualization.techtarget.com/definition/memory-ballooning

https://books.google.com.br/books?id=aZ2FnQAACAAJ

https://books.google.com.br/books?id=aZ2FnQAACAAJ

http://doi.acm.org/10.1145/1516533.1516538

http://doi.acm.org/10.1145/1516533.1516538

http://doi.acm.org/10.1145/1272998.1273025

https://download.openvz.org/doc/OpenVZ-Users-Guide.pdf

https://download.openvz.org/doc/OpenVZ-Users-Guide.pdf

http://dx.doi.org/10.1109/CLOUD.2009.5071526

https://www.vmware.com/pdf/ESX2_CPU_Performance.pdf

https://www.vmware.com/pdf/ESX2_CPU_Performance.pdf

https://www.vmware.com/files/br/pdf/products/VMW_09Q1_BRO_ESX_ESXi_BR_A4_P6_R2.pdf

https://www.vmware.com/files/br/pdf/products/VMW_09Q1_BRO_ESX_ESXi_BR_A4_P6_R2.pdf

http://link.springer.com/chapter/10.1007/978-3-642-35813-5_4

Referências 128

XAVIER, M. G.; NEVES, M. V.; ROSSI, F. D.; FERRETO, T. C.; LANGE, T.; ROSE,C. A. F. D. Performance evaluation of container-based virtualization for high performancecomputing environments. In: 2013 21st Euromicro International Conference on Parallel,Distributed, and Network-Based Processing. [S.l.: s.n.], 2013. p. 233–240. ISSN 1066-6192.Citado 3 vezes nas páginas 16, 24 e 76.

auto-gerenciamentoderecursosem ...€¦ · keywords: self-adaptive software, container-based...

Documents