Auto-gerenciamento de recursos em infraestruturas baseada em contêineres para Desktop-as-a-service: um estudo de caso nos laboratórios de informática da ECT/UFRN

Texto

(1)Geomerez Raduan de Oliveira Bandeira. Auto-Gerenciamento de Recursos em Infraestruturas 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.

(2) Geomerez Raduan de Oliveira Bandeira. Auto-Gerenciamento de Recursos em Infraestruturas baseada em Contêineres para Desktop-as-a-Service: Um Estudo de Caso nos Laboratórios de Informática da ECT/UFRN. Dissertação submetida ao Programa de Pósgraduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau 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-RN 2017.

(3) 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 em Contêineres para Desktop-as-a-Service: um estudo de caso nos laboratórios de informática da ECT/UFRN / Geomerez Raduan de Oliveira Bandeira. - 2017. 128 f. : il. Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em Engenharia de Software. Natal, RN, 2017. Orientador: Prof. Dr. Carlos Eduardo da Silva. 1. Software auto-adaptativo - Dissertação. 2. Virtualização baseada em 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 004.75. CDU.

(4)

(5) Agradecimentos Agradeço a minha família: Gilsa, Assis, Alzeni, Edileide e Raiany que me auxiliaram não só nesse período do mestrado, mas em todos os momentos que juntos superamos os desafios. Agradeço a Luziene que esteve junto em todas as etapas vencidas ao longo desse mestrado e dificilmente teria êxito se não fosse sua compreensão nos momentos mais crí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 em todas as fases do projeto. Agradeço a Marcos Madruga e Paulo Maia, membros da banca na defesa da dissertação, pelas contribuições valiosas indicadas nas arguições. Agradeço também pela prontidã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ço também a Rafael dos Prazeres que muito se dedica em melhorar o serviço nos laboratórios da ECT e me ajudou muito a pensar como resolver os desafios enfrentados e relatados nesse trabalho. Agradeço aos professores: Wendel Medeiros, Sérgio Ramiro, Raul Paradeda, Emmanoel Monteiro e Margarida Knobe que marcaram na minha trajetória acadêmica. Agradeço também aos amigos André Henrique, Fábio, Diego, Danilo, Emanoel Gomes, Raniclécio, Fabiano, Mariana, Rafaela, Arlete, Eliceu, Leonardo, André Galvão, Gleide, Kinha e Priscila que sempre me incentivaram ao decorrer da minha vida acadêmica e pessoal..

(6) Resumo Uma alternativa viável para instituições que possuem múltiplos usuários com necessidade de acessar aplicações desktops é o Desktop-as-a-Service (DaaS), que caracteriza-se pela entrega de um ambiente desktop que executa remotamente. A virtualização de recursos em conjunto com o balanceamento de carga são amplamente utilizados em infraestruturas que hospedam serviços com demandas sazonais, replicando instâncias e distribuindo as requisiçõ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 longa duraçã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 sobrecarregado. Neste contexto, o redimensionamento dinâmico de recursos em uma instância virtual se mostra como a abordagem mais apropriada. Contudo, soluções tradicionais de virtualização exigem a reinicialização do servidor afetado, e consequentemente, finalizando as sessões DaaS com seus respectivos usuários. Por outro lado, virtualização baseada em contêineres permitem tal redimensionamento, porém exige intervenções manuais do administrador para ajustar a quantidade de recursos mediante à demanda. Este trabalho apresenta o ConManager, um controlador autoadaptativo para ambientes baseados em contêineres, que tem como propósito o redimensionamento dinâmico de recursos virtualizados para lidar com sobrecargas sazonais. A proposta foi aplicada como estudo de caso nos laboratórios de informática da Escola de Ciências e Tecnologia da Universidade Federal do Rio 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 aplicados na infraestrutura de suporte ao serviço DaaS, efetivamente redistribuindo recursos de contêineres subutilizados para os sobrecarregados. A ferramenta se encontra em uso e isso trouxe ganhos perceptíveis como diminuição do tempo de adaptação de recursos e a simplificação do gerenciamento do ambiente, beneficiando a equipe de tecnologia da informação da instituição, responsável por manter o serviço e à comunidade acadêmica que desfruta de um ambiente computacional mais estável. Palavras-chave: Software autoadaptativo, Virtualização baseada em contêineres, Conteinerização, LTSP, Desktop-as-a-service.

(7) Abstract A viable alternative for institutions that have multiple users who need access to desktop applications is Desktop-as-a-Service (DaaS), which is characterized by the delivery of a desktop environment that runs remotely. Resource virtualization and load balancing are widely used techniques in infrastructures that host services with seasonal demands, replicating instances and distributing requests among them to achieve elasticity. However load balancing is not the most suitable solution for DaaS, since sessions in this service are 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. In this context, the dynamic resizing of resources in a virtual instance is shown as the most appropriate approach. However, traditional virtualization solutions require a reboot of the affected server, and consequently, terminating DaaS sessions with their respective users. On the other hand, container-based virtualization allows such resizing, but requires manual administrator intervention to adjust the amount of resources on demand. This work presents ConManager, a self-adaptive controller for container-based environments, which aims to dynamically resize virtualized resources to handle seasonal loads. The proposal has been applied as a case study in the computer laboratories of the Escola de Ciências e Tecnologia of the Universidade Federal do Rio Grande do Norte. ConManager monitors the use of resources in laboratories, detecting overhead scenarios, and proposing adaptation plans that are applied to the DaaS service support infrastructure, effectively redistributing resources from underutilized containers to overloaded ones. The tool is currently in use and has brought noticeable gains such as reduced time to adapt resources and simplified environmental management, benefiting the institution’s information technology team, responsible for maintaining the service and the academic community that enjoys a Stable computing environment. Keywords: Self-adaptive software, Container-based Virtualization, Containerization, LTSP, Desktop-as-a-service..

(8) Lista de ilustrações Figura 1 – Tipos de hypervisors, adaptado de Oliveira, Carissimi e Toscani (2010), Goncalves (2013) e Scheepers (2014). . . . . . . . . . . . . . . . . . . . Figura 2 – Estrutura de funcionamento do OpenVZ. Relação de nó de hardware com os contêineres. Adaptado de SWsoft (2005). . . . . . . . . . . . . Figura 3 – Tipos de virtualização de desktops, adaptado de Shabaitah (2014). . . Figura 4 – Arquitetura de funcionamento do VDI, adaptado de Shabaitah (2014). Figura 5 – Funcionamento do LTSP-Cluster. Adaptado de LTSP-Cluster (2015) e Giraldeau Jean-Michel Dault (2006) . . . . . . . . . . . . . . . . . . . Figura 6 – Visão geral das abordagens para implementar a autoadaptação, adaptado de Oreizy et al. (1999) . . . . . . . . . . . . . . . . . . . . . . . . Figura 7 – As fases do Mape-K. Figura adaptada de Salehie e Tahvildari (2009) . Figura 8 – Figura adaptada de Weyns et al. (2013) . . . . . . . . . . . . . . . . . Figura 9 – Funcionamento dos laboratórios com o VMWare ESXi . . . . . . . . . Figura 10 – Funcionamento dos laboratórios com OpenVZ . . . . . . . . . . . . . . Figura 11 – Gráficos representativos das respostas obtidas no questionário . . . . . Figura 12 – Visão geral da arquitetura conceitual do Conmanager. . . . . . . . . . Figura 13 – Visão dos componentes que compõem o ConManager. . . . . . . . . . . Figura 14 – Fluxograma do primeiro nível de tomada de decisão . . . . . . . . . . . Figura 15 – Fluxograma do segundo nível de tomada de decisão . . . . . . . . . . . Figura 16 – Demonstração da tela principal do ConManager, aba de alarmes e monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 17 – Demonstração da tela principal do ConManager, aba distribuição de recursos e tabela de horários . . . . . . . . . . . . . . . . . . . . . . . . Figura 18 – Simulação de alerta e planejamento através da demonstração de telas . Figura 19 – Gráficos do que exibem a carga de processamento durante o experimento Figura 20 – Gráficos do que mostram a utilização de memória RAM e SWAP durante o experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 21 – Gráficos do que mostram a quantidade de usuários logados e utilização da rede durante o experimento . . . . . . . . . . . . . . . . . . . . . . Figura 22 – Gráficos do que mostram a utilização do disco durante o experimento . Figura 23 – Gráficos do Zabbix que ilustram a sobrecarga de um contêiner com o Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 24 – Dados de utilização de CPU e memória RAM do laboratório durante aula de lógica de programação. . . . . . . . . . . . . . . . . . . . . . . Figura 25 – Telas do ConManager no momento que foi acusado a sobrecarga no laboratório 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21 23 26 27 29 31 32 33 35 38 41 43 47 55 57 61 62 63 66 67 67 68 70 71 73.

(9) Figura 26 – Gráfico de utilização e carga do CPU durante a aula de lógica de programação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 27 – Gráfico de utilização da quantidade de usuários logados durante a aula de lógica de programação . . . . . . . . . . . . . . . . . . . . . . . . Figura 28 – Caso de uso ilustrando a interação do usuário no cenário de cadastrar infraestrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 29 – Caso de uso ilustrando a interação do usuário no cenário de realizar intervenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 30 – Caso de uso ilustrando a interação do usuário na utilização da tela principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 31 – Diagrama de classe dos servidores hardware e aplicação . . . . . . . . Figura 32 – Diagrama de classe do monitor e agente . . . . . . . . . . . . . . . . Figura 33 – Diagrama de classe da intervenção . . . . . . . . . . . . . . . . . . . Figura 34 – Diagrama de classe de planejamento . . . . . . . . . . . . . . . . . . Figura 35 – Diagrama de sequência que mostra o comportamento dos componentes de monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 36 – Diagrama de sequência que mostra o comportamento dos componentes do módulo de análise . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 37 – Diagrama de sequência que mostra o comportamento dos componentes dos módulos de planejamento e execução . . . . . . . . . . . . . . . .. . 73 . 74 . 104 . 109 . . . . .. 111 114 115 116 117. . 118 . 119 . 120.

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

(11) 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.

(12) 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.

(13) Sumário 1 1.1 1.2 1.3. INTRODUÇÃO . . . . . Motivação . . . . . . . . . Objetivos . . . . . . . . . Organização do trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. 14 15 17 18. 2 2.1 2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 2.4. REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caracterizando Virtualização . . . . . . . . . . . . . . . . . . . . . Conteinerização com OpenVZ . . . . . . . . . . . . . . . . . . . . Desktop como um serviço . . . . . . . . . . . . . . . . . . . . . Virtual Desktop Infraestructure (VDI) . . . . . . . . . . . . . . . . Virtualização de desktops baseada em sessão . . . . . . . . . . . . Sistemas autoadaptativos . . . . . . . . . . . . . . . . . . . . . Considerações finais . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 19 19 19 22 25 26 28 30 33. 3 3.1 3.2 3.3 3.4. O CASO DA ECT . O cenário da ECT . Solução anterior . . Evolução do serviço Considerações finais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 34 34 35 37 41. 4 4.1 4.2 4.3 4.3.1 4.3.2. PROJETO CONMANAGER Visão geral da arquitetura do Elicitação de requisitos . . . Detalhamento do projeto . . Monitoramento . . . . . . . . . Análise . . . . . . . . . . . . . Definição de gatilhos . . . . . . . . Status de utilização dos servidores . . Planejamento . . . . . . . . . .. . . . . . . . . . . . . . . . . . . ConManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processo de tomada de decisão do módulo de planejamento . . . . . . . . . Primeiro nível de tomada de decisão . . . . . . . . . . . . . . . . . . . . Segundo nível de tomada de decisão . . . . . . . . . . . . . . . . . . . . Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Considerações finais . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. 42 42 44 46 48 48. 4.3.2.1 4.3.2.2. 4.3.3 4.3.3.1 4.3.3.2 4.3.3.3. 4.3.4 4.4. . . . . .. . . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . . .. 49 50. 51 53 53 56. 57 58.

(14) 5 5.1 5.2 5.3. IMPLEMENTAÇÃO . . . . . Detalhes da implementação . Demonstração de utilização . Considerações finais . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. 59 59 61 64. 6 6.1 6.2 6.3 6.4. AVALIAÇÃO . . . . . . . . Experimentos controlados . Relato de uso em produção Discussão . . . . . . . . . . Considerações finais . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 65 65 69 74 75. 7 7.1 7.2 7.3. TRABALHOS RELACIONADOS Produtos relacionados . . . . . . Pesquisas relacionadas . . . . . . Considerações finais . . . . . . .. . . . .. . . . .. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. 76 76 78 81. 8 8.1 8.2 8.3. CONCLUSÕES . . . Contribuições . . . . Limitações . . . . . . Trabalhos futuros . .. . . . .. . . . .. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. 82 82 83 84. A A.1 A.2 A.3 A.4 A.5 A.6. APÊNDICE - REQUISITOS DO SISTEMA . . . . . . . . . . Onde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O quê . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Porquê . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Como . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 86 86 88 88 89 89 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.

(15) 14. 1 Introdução Em muitas instituições de ensino é comum a presença de laboratórios de informática direcionados a atender a comunidade acadêmica que, de uma forma ou de outra, os utilizam para a realização de suas tarefas, sejam elas uma aula ou uma simples navegação na internet em 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 grande desafio para os responsáveis pelo gerenciamento desses laboratórios. Existem diversas alternativas para atender essa demanda, tais como desktops tradicionais equipados com boa quantidade de memória, processador e disco; terminais leves que se conectam em um servidor 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 grande limitação de recurso, conforme Moreira et al. (2008), entre outras possibilidades. A Escola de Ciências e Tecnologia (ECT) da Universidade Federal do Rio Grande do Norte (UFRN) oferece o curso de Bacharelado em Ciências e Tecnologia (BC&T) no qual 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órios de informática com um total de 160 estações de trabalho baseadas em terminais-leves1 (computadores que caracterizam-se pela pouca quantidade de recursos computacionais como disco, memória, processamento), para atender aos diversos componentes curriculares oferecidos. Estes componentes envolvem aulas com diferentes tipos de software, indo desde programação básica, desenvolvimento Web e móvel, até aulas com simulação de fenômenos físicos/quimicos, métodos numéricos, e Computer-aided design (CAD). Tendo a responsabilidade de gerenciar a infraestrutura computacional dos laborató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, como afirmam 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 do servidor, 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 gerenciamento (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 Terminal Server Project (LTSP)2 , juntamente com o LTSP-Cluster 3 , projeto que reúne plugins do LTSP e provê novas funcionalidades como o balanceamento de carga em um grupo de 1 2 3. Neste texto utiliza-se os termos terminais leves e thin-clients de maneira intercambiável <http://www.ltsp.org/> <https://www.ltsp-cluster.org/documentation/howto/openvz-setup>.

(16) Capítulo 1. Introdução. 15. servidores de aplicação. O uso dos dois projetos permite que a carga de trabalho gerada pelos clientes remotos sejam equilibradas em mais de um servidor. O provimento deste serviço na ECT evoluiu com o passar do tempo, graças aos estudos de novas técnicas e abordagens 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 Informação (TI) da ECT. Seu ingresso na equipe aconteceu quando já estava em funcionamento esse serviço de terminais leves nos laboratórios. Quando já integrado, participou na implantaçã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 ao trabalho desenvolvido no mestrado.. 1.1 Motivação Um 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 de virtualizaçã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 destinadas aos laboratórios. Desse modo, consegue-se independência na instalação de softwares, regras de acesso à rede interna ou externa e outras configurações de ambiente. Cada laboratório recebe uma quantidade dos recursos do servidor para atender a seus usuários e esse valor foi 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 que gerenciam esse tipo de ambiente virtual, segundo Chebiyyam et al. (2009), é o de gerenciar recursos no servidor (como memória, CPU e disco) em ocasiões onde uma instância virtual utiliza toda a sua cota de recursos enquanto as outras são pouco utilizadas. Os limites estipulados à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 em grandes data centers e provedores de computação em nuvem, consoante Maurer, Brandic e Sakellariou (2013). Para ocasiões como essa, é necessário que a tecnologia de virtualização consiga adaptar a quantidade de recursos destinados à instância sobrecarregada para atender as demandas em horários de picos. A tecnologia utilizada pela ECT para implantar esse 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 tempo de execução, cabendo à equipe utilizar o balanceador de cargas (LTSP-Cluster) para redirecionar novos usuários para laboratórios sem utilização, quando era possível. Essa.

(17) Capítulo 1. Introdução. 16. 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: outras tecnologias de virtualização utilizam técnicas que auxiliam na otimização do uso dos recursos, como o memory balloning implementado pela VMware ESX4 , Hyper-V e KVM, como afirma Rouse (2014), que é conseguido através do compartilhamento de páginas idênticas de memória, segundo Miller et al. (2013) ou compartilhamento de CPU também adotado pela VMware, de acordo com VMware (2006), conhecido como (time-sharing) , como explicado por Muchalski (2014), para contornar essa situação. Mesmo as tecnologias de virtualização que fazem uso dessas técnicas possuem um ponto fraco ao serem empregadas em ambientes como os dos laboratórios da ECT, pois as técnicas citadas exigem que o administrador estipule previamente a faixa da quantidade de recurso que poderá ser redimensionada sem desligar a instância. Para os casos que a instância necessite mais recurso do que configurado, o administrador deve adaptar manualmente os recursos entre as instâncias. A tecnologia de conteinerização (também conhecida como virtualização a nível de sistema operacional), segundo Soltesz et al. (2007) e Xavier et al. (2013), surge como uma alternativa para o provisionamento de servidores de aplicações virtuais, permitindo alterar os recursos alocados a cada contêiner em tempo de execução. No entanto, somente a 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 balanceamento de carga, tais como kubernetes 5 e Docker Swarm 6 , que suportam a criação e remoção dinâmica de novos contêineres de acordo com a carga de trabalho. Entretanto, tais soluções abordam a escalabilidade com balanceamento de carga iniciando contêineres idênticos segmentando 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ários apresentam um longo tempo de duração e a adição de novos servidores não faz com que a carga seja balanceada imediatamente, pois as sessões já iniciadas no sistema operacional permanecerão no servidor sobrecarregado, sendo necessário reiniciar a sessão para que a carga seja balanceada. Essa situação pode causar transtornos em ocasiões de aulas e principalmente de avaliações. Outra estratégia considerada para esse cenário foi a migração das sessões dos usuários para outro servidor virtual. Contudo, as soluções atuais para DaaS baseado 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 outro lado, 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 ser 4 5 6 7. <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>.

(18) Capítulo 1. Introdução. 17. 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 estudo das diferentes tecnologias de virtualização até as diversas abordagens de gerenciamento de recursos. Uma possível solução de gerenciamento desse ambiente pode ser alcançada através de sistemas autoadaptativos, que são capazes de realizar alterações em seu estado e/ou comportamento conforme variação com os picos de utilização, de acordo com Oreizy et al. (1999). Encontrar uma tecnologia de virtualização que atenda os requisitos e facilitar o gerenciamento dos laboratórios minimizando as dificuldades enfrentadas são os principais motivadores deste trabalho.. 1.2 Objetivos Este 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 utilizam o serviço DaaS baseado em sessão e que fazem uso da contêinerização para manter seus servidores de aplicação. O alcance desse objetivo proporcionará uma melhor utilização dos recursos presentes no hardware ao diminuir a subutilização causada pelo provisionamento e, consequentemente, a expansão dessa solução para outros lugares que trabalham com essas tecnologias e enfrentam os mesmos desafios que a ECT enfrenta. Para atingir esse objetivo geral, será preciso reunir os esforços para cumprir os objetivos específicos que consistem em: • Implementar o monitoramento das cargas de trabalho do cenário, contemplando a infraestrutura física (hardware) e virtual (instâncias virtuais). • Desenvolver na solução proposta a capacidade de analisar os dados providos pelo monitoramento 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 os recursos do servidor para atender demandas sazonais. • Medir e avaliar o ambiente com a utilização do software desenvolvido e confrontar com o ambiente sem a presença do software. Ao atender os objetivos específicos e consequentemente o geral, esperamos prover ao ambiente dos servidores de aplicação uma impressão de elasticidade (auto-scaling) nos recursos computacionais. Dessa forma, quando em momentos de grande sobrecarga dos recursos em um laboratório o acréscimo de memória, CPU ou disco permitirá a melhora.

(19) Capítulo 1. Introdução. 18. da experiência da utilização do sistema operacional. Também é esperado que a tarefa de gerenciar os laboratórios seja facilitada, no que diz respeito ao monitoramento e intervenção de forma manual sem fluxo de trabalho definido, diminuindo o tempo de respostas na identificação da sobrecarga e na adaptação do ambiente. Com isso, proporcionará melhor experiência de utilização desses laboratórios à toda comunidade acadêmica.. 1.3 Organização do trabalho O 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 para os 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 infraestrutura de hardware disponível e quais tecnologias já foram utilizadas para atender o cenário dos laborató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 da arquitetura, elicitação de requisitos e o detalhamento do projeto. O capítulo 5 refere-se à implementação do ConManager, com detalhes da arquitetura das 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 experimentos controlados, 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 e pesquisas relacionadas. O capítulo 8 debate as conclusões, demonstrando as contribuições, limitações e os trabalhos futuros aplicados ao ConManager..

(20) 19. 2 Referencial Teórico O objetivo desse capítulo é proporcionar um embasamento teórico dos assuntos e tecnologias explorados neste trabalho. Aqui é apresentado o resultado da consulta bibliográfica e que ajudou a entender os conceitos e proporcionaram melhor compreensão dos 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 de conteinerização utilizada na ECT. A seção 2.2 apresenta os tipos de implementações do Desktop como um serviço, exemplificando as diferentes técnicas. Também será detalhado o funcionamento 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ção A tarefa da virtualização é estender ou substituir um recurso com o intuito de imitar o comportamento do objeto virtualizado. Para isso, é usada uma camada de software como intermediária, responsável por transformar ações de um sistema A, nãovirtualizado, em ações equivalentes em um sistema B, virtualizado. Os princípios básicos que 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 em uma 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 em sua execução e posteriormente retomar o seu estado anterior, conforme Oliveira, Carissimi e Toscani (2010).. 2.1.1 Caracterizando Virtualização O processo de virtualização pode se dar em diferentes locais dentro das camadas da arquitetura computacional. Os softwares de virtualização conseguem atuar em vários locais dessa arquitetura, criando assim três camadas de virtualização, sendo elas: a virtualização a nível de hardware, a virtualização a nível de sistema operacional e virtualização a nível de 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 fica bem no topo do hardware, disponibilizando às camadas superiores um hardware similar ao original. Como a máquina virtual é semelhante ao hardware, todos os softwares serão executados na máquina virtual, segundo Rosenblum (2004). Máquinas virtuais a nível.

(21) Capítulo 2. Referencial Teórico. 20. de hardware são implementadas por uma camada de software chamada Virtual Machine Monitor (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 I executa sobre o hardware da máquina real, fazendo que a máquina virtual se pareça com o hardware. Esse nível de virtualização é bem difundida no mercado e exemplos de tecnologias que implementam são muitos como Xen, VMWare ESX e Hyper-V, de acordo com Oliveira, Carissimi e Toscani (2010). A virtualização a nível de sistema operacional se caracteriza por ficar entre o sistema operacional e os programas aplicativos que são executados sobre ele. Seu papel envolve a criação de partições lógicas sob o sistema operacional, gerando uma plataforma em cada partição, fazendo que cada uma delas seja vista como uma máquina isolada capaz de executar aplicativos ou conjunto de aplicativos que são escritos para o sistema operacional que está sendo virtualizado. Uma das implementações desse nível faz uso de uma camada de software de virtualização que fica sobre o sistema operacional hospedeiro capaz de virtualizar sistemas diferentes do hospedeiro e é conhecido como VMM ou hypervisor do tipo II. Ferramentas conhecidas implementam essa virtualização como o VirtualBox, Virtual PC,VMware workstations, segundo Oliveira, Carissimi e Toscani (2010). Outra forma de implementar virtualização a nível de S.O. é através da conteinerização, um software de virtualização que 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 e as zonas do Solaris, como afirmam Oliveira, Carissimi e Toscani (2010). A Figura 1 ilustra as camadas onde são executadas o hypervisor do tipo I, tipo II e a conteinerização..

(22) Capítulo 2. Referencial Teórico. 21. Figura 1 – Tipos de hypervisors, adaptado de Oliveira, Carissimi e Toscani (2010), Goncalves (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 e abstraindo as diferenças nos sistemas operacionais de base. A ideia é que qualquer programa escrito na linguagem e compilado para esta máquina virtual, seja executado nele. Como exemplos 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, paravirtualização e baseada em contêineres (conteinerização). As duas primeiras são utilizadas para implementar os hypervisors dos tipos I e II que estão presentes nas virtualizações nos níveis de hardware e sistema operacional, enquanto que a virtualização baseada em contê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éplica virtual do hardware no qual está acontecendo a virtualização, de maneira que o sistema operacional possa fazer suas operações como se estivesse trabalhando sobre o hardware real. A vantagem dessa abordagem é que o sistema operacional hóspede não precisará ser alterado para executar sobre o hypervisor. Porém, há alguns pontos negativos como: o hypervisor deve suportar um número muito elevado de hardwares diferentes, já que eles entregam uma réplica do hardware. Como medida para contornar a situação, os hypervisors fornecem o uso de componentes genéricos, mas não conseguem garantir que serão utilizados dentro de sua real capacidade. Algo comum que acontece é a perda de desempenho do sistema hóspede, pois ele foi projetado para executar diretamente sob a camada de.

(23) Capítulo 2. Referencial Teórico. 22. 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 desse tipo de virtualização KVM, QEmu, Bochs, Parallels, Virtualbox e VirtualPC, conforme Kolyshkin (2006). Para-virtualização: Nessa abordagem, o sistema operacional hóspede precisa ser alterado para 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íticas ou privilegiada (que possa alterar o estado do sistema) são encaminhadas à máquina virtual para 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 diretamente enviadas ao hardware. Uma outra mudança com relação à virtualização total é que na para-virtualização os dispositivos de hardware são acessados por drivers específicos das máquinas virtuais, sem a necessidade de dispositivos genéricos que não exploravam toda a capacidade do dispositivo, de acordo com Oliveira, Carissimi e Toscani (2010). Alguns exemplos 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 virtualização possibilita a execução de múltiplos ambientes dentro de um único kernel de sistema operacional. Traz consigo o conceito de ambiente virtual, também conhecido como contêiner. Cada contêiner é um programa em execução totalmente isolado dos outros processos em execução no sistema operacional. Os processos que executam dentro do contêiner não conseguem enxergar os outros programas que executam em outros contêineres, segundo Kolyshkin (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 de um sistema operacional, podem coexistir diversos contêineres e cada um deles podem conter diferentes distribuições, contanto que partilhem do mesmo kernel. Como exemplo desse 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 sistemas operacionais, implementando contêineres com OpenVZ1 . Esse tipo de virtualização foi escolhida 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 pela facilidade de gerenciamento de contêineres através da manipulação de recursos e pela facilidade de manipulação desses recursos através de sua API. 1. <https://openvz.org>.

(24) Capítulo 2. Referencial Teórico. 23. O OpenVZ é uma solução tecnológica que propõe o isolamento, virtualização e gerenciamento dos recursos computacionais, métodos de congelamento do estado do sistema operacional e live migration, permitindo a migração de sistemas completos sem haver interrupção do serviço. Como a própria documentação oficial o define, em SWsoft (2005), OpenVZ é serviço completo 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 o uso do hardware e propiciar gerenciamentos dos recursos desse servidor, como pode-se perceber na Figura 2.. Figura 2 – Estrutura de funcionamento do OpenVZ. Relação de nó de hardware com os contêineres. Adaptado de SWsoft (2005). Semelhante a uma instância de máquina virtual, cada contêiner executa de maneira independente dos outros contêineres, compartilhando alguns recursos e virtualizando outros. 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 kernel compartilhado por todos os contêineres, torna possível o acréscimo e o decréscimo de recursos em tempo de execução, sem a necessidade do desligamento da instância virtual..

(25) Capítulo 2. Referencial Teórico. 24. 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 et al. (2013) e Muchalski (2014), elas não permitem redimensionar em tempo de execução os recursos alocados a uma máquina virtual, isto é, se faz necessário reiniciar a máquina virtual para seu redimensionamento. Com a utilização de Kernel Namespaces (recurso do kernel Linux capaz de criar um ambiente isolado, fazendo que os processos isolados em uma namespace consigam visualizar apenas processos da mesma namespace) o OpenVZ consegue assegurar que cada contêiner tenha seus recursos isolados. Com o PID namespace é possível que processos sejam 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 das máquinas virtuais como o live migration (migrar um contêiner para outro hardware sem necessidade de desligá-lo), checkpoint (salvar o estado da máquina) e resume (continuar a executar 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 um contêiner tem a percepção que está em um sistema local e independente. Essa independência na 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, fazer modificações em arquivos, ajustes no ambiente, instalar softwares adicionais, sem se preocupar 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 servidor físico, através dos contêineres. Para que isso ocorra, é preciso que tanto o kernel da distribuição instalada no contêiner quanto do sistema operacional hospedeiro sejam o mesmo. Um template de sistema operacional é um conjunto de pacotes de uma determinada distribuição Linux que utiliza para criar um contêiner. Basicamente são programas de sistemas, bibliotecas, scripts que executam ao iniciar o contêiner e alguns utilitários e aplicações fundamentais do Linux, segundo SWsoft (2005). Outro pilar importante do paradigma da virtualização no nível de sistemas operacionais é o poder de gerenciamento de recursos que não se pode fazer com a mesma facilidade nos outros tipos de virtualização. Os recursos que podem ser gerenciados são o compartilhamento do processador, espaço em disco e um conjunto de parâmetros relacionados à memória. Todos esses atributos manipulados em tempo real, sem a necessidade de 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 e 2 3 4. <http://www.vmware.com/br/products/esxi-and-esx.html> <https://xenserver.org/> <https://www.linux-kvm.org/page/Main_Page>.

(26) Capítulo 2. Referencial Teórico. 25. SWAP) chamado User Beancounters e provê um conjunto de limites e garantias atribuídos para cada contêiner e, dessa forma, controla a distribuição de recursos. Por padrão, a CPU é 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 outros contêineres. Para evitar essa situação, o OpenVZ implementa o cpulimit que limita a utilização do CPU por contêiner, sendo possível indicar o percentual máximo que o contêiner poderá utilizar. O valor cpulimit varia de acordo com a quantidade de núcleos de processamento existentes no hardware multiplicado por 100. Por exemplo, o hardware utilizado na ECT para a instalação do OpenVZ possui 16 núcleos de processamento, sendo o 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ço O 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-aservice (DaaS), ele vem evoluindo cada vez mais com o aprimoramento de protocolos e largura de banda nas redes das instituições. Os tipos mais difundidos desse serviço no mercado e no meio acadêmico são dois: Infraestrutura de desktop virtual, do termo em inglê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ão ilustradas na Figura 3: (1) Máquinas virtuais persistentes; (2) Máquinas virtuais nãopersistentes; e (3) Baseada em sessão. A tecnologia VDI implementa o primeiro e o segundo modelo, enquanto o tipo baseado em sessão implementa apenas o último modelo. Cada uma dessas implementações possuem características que deve-se levar em consideração. No modelo 1 (máquinas virtuais persistentes), chamado por Sakdeo (2012) de Full clone virtual desktop, cada usuário tem uma máquina virtual dedicada exclusivamente para ele. Essa máquina tem como base uma máquina virtual de referência e é feita uma cópia completa no momento da instanciação. Esse tipo de modelo é caracterizado pelo alto consumo de espaço em disco. Já no modelo 2 (máquinas virtuais não-persistentes) os usuários compartilham as máquinas virtuais entre eles. Cada vez que um usuário se conecta, ele recebe a instância de uma máquina virtual aleatória. No lado do servidor, há um pool de recursos que são utilizados para a criação de máquinas virtuais. Além disso, Sakdeo (2012) esclarece que as máquinas virtuais compartilham partes do disco que são apenas leitura e comum a todas as máquinas virtuais..

(27) Capítulo 2. Referencial Teórico. 26. 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 virtual ou uma máquina virtual só para ele. Esse modelo funciona com o compartilhamento de recursos de um servidor entre os usuários. Geralmente esse servidor é robusto e capaz de suprir as necessidades dos usuários em realizar suas atividades. Através de políticas que limitam o uso dos recursos, é possível isolar a sessão de cada usuário e garantir que o mal uso 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 um usuário dentro de uma máquina virtual. Além da virtualização de sistema operacional, sua implementaçã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 de clientes e também é um ponto de conexão para clientes da rede local), dispositivos de acesso 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.

(28) Capítulo 2. Referencial Teórico. 27. conexões. As informações contidas no RDC são o IP, o nome do servidor, a configurações de 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 consulta a infraestrutura de servidores (passo 2) e recupera o tipo de VM (persistente ou nãopersistente) utilizada pelo usuário (passo 3). O gerenciador de conexão se comunica com o gerenciador virtual (passo 4). Se o tipo de VDI for persistente, o gerenciador de conexão conecta 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áquina virtual 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 de acordo 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 Microsoft usa-se muito o Remote Desktop Protocol (RDP), a Citrix faz uso do High Definition Experience (HDX) e por fim, a VMWare usa o seu VMWare Personal Computing over Internet Protocol (PCoIP), de acordo com Provazza (2013)..

(29) Capítulo 2. Referencial Teórico. 28. 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 uma entidade 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 os recursos presentes. Essa solução se mostra mais barata e de mais fácil implementação que o VDI, no entanto, é necessário maior gerenciamento dos recursos disponíveis. Como diversos usuários compartilham dos mesmos recursos, é preciso ficar atento ao mal uso dos mesmos por parte dos usuários logados. No contexto deste trabalho, foi utilizado o DaaS baseado em sessão devido a possibilidade de vários usuários compartilharem os mesmos recursos e sistema operacional. Outros fatores importantes considerados são o menor investimento na compra de servidores e maior facilidade no gerenciamento do ambiente. Mais especificamente, foram empregadas as tecnologias Linux Terminal Server Project (LTSP) e LTSP-Cluster. Por definição da própria comunidade do projeto, de acordo com LTSP (2015), a tecnologia Linux Terminal Server Project (LTSP) trata-se de um conjunto de softwares específicos que possibilitam a transformação de uma distribuição Linux instalada de maneira normal em um servidor de terminais. Diferente de outras tecnologias que atendem terminais leves, que necessitam de um pequeno sistema para inicializar (boot) o terminal e se 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 unidade de disco para realizar essa ação. Além de reduzir custos, ele também reduz a demanda por administração das máquinas existentes. O processo de boot pode ser resumido nos seguintes 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 o protocolo 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 da placa mãe, montar toda a estrutura de sistema de arquivos e diretórios do usuário, configurar as interfaces de rede, etc;.

(30) Capítulo 2. Referencial Teórico. 29. 7. O usuário se conecta ao LTSP, onde permanece com a sessão ativa no período que ele 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 de um balanceador de carga, responsável por checar o estado dos servidores de aplicações e distribuir as sessões de forma igualitária. Também provê ferramentas do lado servidor que facilitam o gerenciamento do parque tecnológico atendido pelo LTSP, de acordo com LTSP-Cluster (2015).. Figura 5 – Funcionamento do LTSP-Cluster. Adaptado de LTSP-Cluster (2015) e Giraldeau Jean-Michel Dault (2006) A Figura 5 ilustra o funcionamento lógico do LTSP-Cluster, conforme Giraldeau Jean-Michel Dault (2006). A caixa com o nome Terminal representa os terminais leves ou desktops dentro de um laboratório, Boot Server representa o servidor capaz de receber e atender as requisições dos usuários e cada Application Server representa o servidor onde está 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 e gerenciar as sessões dos usuários com auto-login (sem necessidade de autenticação para entrar no ambiente). O PXE Configuration Editor obtém os parâmetros de configurações feitas 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 constante comunicação com o Load Balancer Server (através de requisições HTTP GET/POST) e com 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 e uso do processador. Quando um cliente faz a requisição de um sistema operacional para.

(31) Capítulo 2. Referencial Teórico. 30. seu terminal leve, o load balancer server deverá conhecer qual servidor de aplicação tem recursos suficiente para receber o cliente que fez a solicitação.. 2.3 Sistemas autoadaptativos Um 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 em seu 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 ser entendido 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ção que acontecem em um ambiente, como falhas e alterações em seus requisitos. Um software autoadaptativo requer confiança elevada, robustez, adaptabilidade e disponibilidade. Para isso, é necessário desde a sua concepção, como no levantamento dos requisitos e modelagem das classes, levar em consideração pontos que viabilizem a autoadaptação. Em seu trabalho, Oreizy et al. (1999) apresentam diversas abordagens para atingir a autoadaptação num software, organizadas em um espectro que vão de expressões condicionais fixadas em código-fonte ao uso de técnicas de Inteligência Artificial. A Figura 6 ilustra a visão geral das variadas maneiras de conseguir que um software se autoadapte, sendo que 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 mais próximas do topo dão suporte a inúmeras mudanças e provêm uma clara generalização das adaptações. Nos softwares que fazem uso das expressões condicionais para implementar a autoadaptação é feita a avaliação de uma expressão e, baseado no resultado, alterase o comportamento. Embora simplista, essa maneira é muito comum para realizar a implementação do comportamento adaptativo. Algoritmos online levam em consideração uma suposição de eventos futuros que são incertos. Eles são adaptativos no que utilizam seus prévios conhecimentos do problema e o domínio do que pode vir como entrada para alcançar maior eficiência. Os algoritmos genéricos e parametrizados proveem comportamentos parametrizados e, usualmente, variam devido ao tipo de instanciação ou entradas externas. Já que os algoritmos genéricos e polimórficos se adaptam conforme os diferentes tipos de dados que vêm como entrada. Os sistemas que usam a seleção de algoritmos tem como base as propriedades do ambiente operacional para decidir dentro de um conjunto de algoritmos disponíveis, o que mais se adequa para adaptar às mudanças no ambiente. Por fim, no topo das possíveis abordagens, a programação evolutiva e técnicas de aprendizagem de máquina utilizam propriedades do ambiente operacional e conhecimento obtido através de.

(32) Capítulo 2. Referencial Teórico. 31. Figura 6 – Visão geral das abordagens para implementar a autoadaptação, adaptado de Oreizy et 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, é reconhecida a importância do feedback proveniente do ambiente, utilizado para o software analisar os dados, projetar a intervenção necessária e realizar a ação. Há importantes trabalhos que exibem 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 proposta manter a eficiência de um sistema independentemente das diversas variações que podem ocorrer 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 um controlador, que por sua vez utiliza algoritmos de controle ou estratégias para corrigir o comportamento do sistema por meio de atuadores. A constante tarefa de rever o ambiente é um processo que deve ser detalhado para construir um sistema autoadaptativo eficiente. De acordo com IBM (2006), o Mape-k foi criado pela IBM, sendo uma forma de implementar o Feedback Control Loop. As fases que compõ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, como ilustrada na Figura 7. A etapa de monitoramento é responsável pela coleta e correlação entre os dados. A.

(33) Capítulo 2. Referencial Teórico. 32. 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 e cabe a ela identificar variações no ambiente capazes de comprometer o bom funcionamento do sistema. O planejamento decide o que deve ser adaptado através da definição de um plano de adaptação. Finalmente, a fase da Execução faz uso dos efetores, executores dos comando de mudança. Um sistema autoadaptativo interage diretamente em um ambiente, afetando e sendo afetado por agentes externos (como usuários e sistemas) e agentes internos (como processos 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 resultado dessa interação são produzidos efeitos possíveis de serem observados e medidos. Apenas com essa observação e medição é possível planejar a afetação necessária no ambiente, capaz de minimizar as interferências causadas por agentes externos. O subsistema gerenciado é o responsável por prover o serviço final, destinandose aos usuários ou ao suporte de outros sistemas. Ele utiliza o ambiente para poder desempenhar suas funcionalidades. Por tratar-se de um sistema autoadaptativo, faz-se necessário que exista um suporte à adaptações, além de prover condições de monitorá-lo e adaptá-lo. Por sua vez, o subsistema gerenciador tem como papel o controle do subsistema gerenciado. Esse subsistema é capaz de aplicar adaptações que possibilitam ao sistema gerenciado continuar a prover as funcionalidades ao qual este foi projetado. É importante mencionar que o subsistema gerenciador não afeta diretamente o ambiente, mas altera o funcionamento do sistema gerenciado para realizar tal tarefa..

(34) Capítulo 2. Referencial Teórico. 33. Figura 8 – Figura adaptada de Weyns et al. (2013). 2.4 Considerações finais Neste 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 para hospedar o serviço DaaS baseado em sessão e implementado com LTSP e LTSP-Cluster..