A 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 a equipe de TI era notificada pelo professor da aula, que era interrompida para que o professor pudesse notificar a equipe de TI. A resolução envolvia o acesso manual ao servidor de aplicação para investigar as causas da sobrecarga, seguida do redimensionamento manual do servidor de aplicação, que necessitava ser reiniciado, de forma que todos as sessões eram perdidas. Todo esse processo chegava a demorar até 30 minutos após a notificação do professor, causando a interrupção da aula e diversos transtornos para os usuários dos laboratórios e para a equipe acadêmica da ECT.
O ConManager tem permitido à equipe de TI da ECT se antecipar aos problemas de sobrecarga, sendo capaz de agir antes que a aula chegue a ser interrompida. Foi feito o cálculo da média de tempo que se leva para adaptar os recursos, levando em consideração 10 casos reais e chegou-se ao valor de três minutos e quarenta e oito segundos (3:48) desde a detecção até a aplicação de uma intervenção. Em consultas com professores e alunos de aulas que sofreram intervenções, percebeu-se que os efeitos de sobrecarga foram reduzidos significativamente, com alguns alunos mencionando percepção de melhoria no uso do laboratório. Embora o cenário possa ser considerado simples, se trata de um cenário real que afeta em torno de 4000 alunos que frequentam o prédio diariamente e os resultados
Capítulo 6. Avaliação 75
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 o ambiente sem interferência do administrador. Isso se dá porque foi decidido que nessa fase inicial na qual o ConManager está em pleno uso no ambiente de produção, o administrador deveria aceitar a tomada de decisão feita pelo módulo de planejamento para que sejam validadas suas decisões. Com a implantação do ConManager cessaram as reclamações relacionadas à sobrecarga de recursos, pois agora é possível adiantar-se e fazer intervenções para manter a boa utilização dos laboratórios.
O que foi percebido com o uso do ConManager é que os recursos do hardware são mais bem utilizados pelos laboratórios. Já houveram casos onde um dos laboratórios destinado às aulas estava sobrecarregado, juntamente com o laboratório utilizado como uso geral, além de outro com o status "pouco uso". Nessa ocasião, o ConManager sugeriu retirar recursos do único laboratório sem utilização para aumentar os recursos do laboratório de aula sobrecarregado. As requisições por mais recursos vindo do laboratório de uso geral eram 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, mas dessa 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 ConManager foi desenvolvido para suportar mais de um hardware, como as regras do módulo de planejamento e o módulo de execução. Atualmente, se um contêiner consumir todos os recursos alocados a ele, não podendo ser redimensionado em obediência às restrições, o ConManager não poderá fazer nada devido à restrição física de recursos. Com a experiência que a equipe tem com o ConManager, pode-se afirmar que com o hardware disponível e a quantidade de laboratórios existentes em momentos de sobrecarga, o ConManager consegue redistribuir recursos para atender bem dois laboratórios com status "sobrecarregado", um com status "pouco uso" e a permanência dos recursos do laboratório utilizado para uso geral.
6.4
Considerações finais
Essa seção apresentou alguns resultados obtidos pelo ConManager em produção. Eles foram bastante positivos, podendo ser percebido principalmente pela cessação das reclamações por professores com relação às lentidões no ambiente. O ConManager se encontra 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 do problema de pesquisa como o gerenciamento de recursos dentro de um ambiente virtual tal como data centers e nuvem. Relacionado com o ambiente implantado nos laboratórios da ECT/UFRN, foram pesquisados assuntos que tivessem como solução para a montagem de 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 resultados esperados.
7.1
Produtos relacionados
Assim como o OpenVZ, o Linux Containers (LXC) 1 também provê isolamento
entre contêineres utilizando a ferramenta Kernel Namespaces. Dessa forma ele consegue isolar processos, sistema de arquivos, rede (baseado em rotas ou em bridges), pontos de montagem, tudo isso através de namespaces. Diferente do OpenVZ (que introduziu o conceito de User Beancounters), o LXC só permite o gerenciamento de recursos dos contêineres através de cgroups. O cgroups também tem a responsabilidade do controle dos processos e tem a função de limitar o uso de CPU entre os contêineres, segundo Xavier et al. (2013). Dessa forma, implementar o ConManager utilizando o LXC aumentaria muito a complexidade, já que o gerenciamento dos recursos não vem facilitado pela tecnologia de conteinerizaçã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 acordo com 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 do LXC. A função do Docker é prover ao usuário uma forma simples de manter sua aplicação ou serviço, sem se preocupar com níveis mais baixos de implementação da virtualização em contê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 diversas necessidades 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 (um conjunto de comandos que descreve os arquivos, o ambiente, as configurações que compõe uma imagem) e estão disponíveis no Docker Hub, local onde são buscadas as imagens 1 <https://linuxcontainers.org/>
Capítulo 7. Trabalhos relacionados 77
disponíveis para implementação 3. A elasticidade dos recursos no Docker é conseguida
através da replicação de instâncias e feita o balanceamento de carga. Para ambientes como o da ECT, que implementa o DaaS baseado em sessão, essa abordagem não é interessante pois uma sessão que está em um contêiner continuaria sentindo a lentidão mesmo com o balanceamento sendo feito. Nesses casos a sobrecarga só é aliviada quando sessões são reiniciadas e são direcionadas aos novos contêineres provisionados.
Apesar da falta de documentação da implementação do LTSP no Docker, uma implementação foi detalhada por seu autor4. Os contêineres foram utilizados para hospedar os servidores LTSP e, usando o Dockerfile, pode-se construir com facilidade os servidores de aplicação para hospedar as sessões remotas. Em sua infraestutura de rede, é necessária a existência do serviço DHCP para suportar o processo de boot PXE e do DNS usado pelo Dockerfile para utilizar o repositório APT do ubuntu. No entanto, essa estrutura não foi implementada pensando no problema da sobrecarga de recursos no contêiner e sim na facilidade 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, quando
habilitada, aumenta a eficiência do uso da memória física. Quando ativa a memória alocada às máquinas virtuais, passa a ser compartilhada, podendo ser realocadas em tempo de execução (sem a necessidade de desligar a máquina). Para isso funcionar é necessário atribuir um valor mínimo e máximo que a máquina virtual poderá utilizar de memória. O gerenciamento da memória é feita pelo Hyper-V, atribuindo mais quantidade quando uma má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 uma máquina virtual não monopolize os recursos, principalmente a que atende o laboratório de uso geral. Seria necessário também a possibilidade de uma integração com a tabela de horá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 a agilidade que a máquina virtual recebe mais recurso de acordo com a sua demanda, pois se não for instantaneamente (como nos contêineres), pode comprometer o bom funcionamento da aula.
Uma poderosa ferramenta na manipulação de contêineres, o Kubernetes 7, projeto
iniciado pelo Google em 2014, é um sistema open-source construído para automatizar a implantação, elasticidade de recursos e gerenciamento de aplicações conteinerizadas. Ele 3 <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/>
Capítulo 7. Trabalhos relacionados 78
agrupa contêineres que compõe uma aplicação em unidades lógicas para fácil gerenciamento e sua proposta é prover o crescimento flexível para entregar as aplicações consistentemente independente da complexidade que exista nela. Dentre suas principais características estão o empacotamento automático de aplicações, que consiste em alocar os contêineres com base em suas necessidades de recursos e outras restrições. É fornecido o scaling horizontal (crescimento de poder computacional por meio de balanceamento de carga), possibilitando o aumento de capacidade dos recursos (CPU) com um simples comando do usuário ou de forma automática. Apesar do fato que a ferramenta é muito poderosa, o scaling horizontal não atende os requisitos de um ambiente com sessões desktops, pois essas sessões são longas 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 entre os diversos servidores não resolve de forma imediata o problema da sobrecarga, sendo necessário que a sessão do usuário seja reiniciada para que ela vá para um servidor onde os recursos estejam mais livres.
7.2
Pesquisas relacionadas
O 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. A estrutura por eles proposta consiste em uma nuvem com OpenStack para gerenciar as máquinas virtuais criadas com KVM e todo o serviço DaaS rodando sobre a camada da nuvem. Entretanto, eles não consideram o problema de gerenciamento de recursos, mas sim a escalabilidade oferecida pela nuvem para o armazenamento das imagens de má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 dashboard do OpenStack, que são integradas ao ambiente LTSP-Cluster. Todo o processo é feito manualmente, enquanto que o ConManager permite que tudo seja realizado a partir da própria ferramenta. Além disso, conforme já mencionado anteriormente, tal solução não elimina a sobrecarga para sessões já estabelecidas. Os experimentos apresentados por eles confirmam esse comportamento, deixando os usuários decepcionados com o atraso de resposta da plataforma.
O trabalho apresentado porHao et al. (2009) tem foco na migração de instâncias virtuais (utilizando o OpenVZ) entre data centers, melhorando o desempenho do ambiente com balanceamento de carga. No entanto, no cenário dos laboratórios da ECT, onde as sessões ficam ativas por horas e não há a possibilidade de tirar uma sessão de um sistema operacional e colocar em outro sem reiniciá-la, apesar dessa solução ser muito eficiente para aplicações comerciais, ela não é a mais adequada para o cenário de virtualização de desktops baseado em sessão.
Capítulo 7. Trabalhos relacionados 79
Dentro do assunto de gerenciamento de recursos voltados para nuvem, Berryman et al. (2010) apresentam o VDBench, um gerenciador de recurso em ambientes virtuais voltados para DaaS. A ferramenta é baseada no gerenciamento de memória do VMware ESXi, sendo capaz de provisionar novas máquinas virtuais ao verificar que há demanda necessária para esse tipo de ação. Seu objetivo é ajudar o administrador a provisionar a quantidade 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 ambiente
virtual. A abordagem dessa ferramenta é provisionar máquinas virtuais levando em conta o comportamento do cliente para conseguir o máximo de eficiência nos recursos. A proposta de gerenciamento de recursos apresentada por eles não se adequam a nosso cenário de DaaS baseado em sessão, pois focam no provisionamento de novas máquinas virtuais, segundo
Berryman et al.(2010), e com nova configuração, como em Calyam et al.(2011), enquanto que o ConManager permite o redimensionamento dinâmico de servidores virtuais.
Padala et al. (2007) no “Adaptative Control of Virtualized Resources in Utility Computing Environnments” trabalham o gerenciamento de recursos em ambientes de data
centers, com foco, principalmente, na otimização do provisionamento de uma máquina
virtual de acordo com a demanda que ela atenderá. Como exemplo, um sistema que tem serviços diferentes como a aplicação propriamente dita e o banco de dados. Seu trabalho toma como base um ambiente onde toda a estrutura de recursos computacionais estão em um pool e todos os serviços fazem o compartilhamento dessa quantidade disponível. Sua proposta é 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 todos os outros nós. O controlador de recursos desenvolvido analisa as cargas, fazendo uso do
feedback control loop e através de técnicas disponibilizadas pelo próprio hypervisor, faz
o 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 o gerenciamento do CPU não atende os requisitos da ECT.
Assim como a proposta neste trabalho apresentada, alguns trabalhos consideram os 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 em controlar e ajustar os recursos presentes em uma infraestrutura de nuvem com múltiplas máquinas virtuais (VM) chamada de Application Environment (AE), responsáveis pelas aplicações hospedadas. A presença do Local Decision Module (LDM) em cada AE tem a responsabilidade de avaliar a oportunidade de alocar ou liberar VMs com base na atual carga de trabalho. Há também o papel do Global Decision Module (GDM) no centro do sistema. O LDM interage com o GDM enviando as métricas de utilização, que por sua vez monitora as máquinas físicas para decidir se provisiona ou elimina VMs, e avisa o LDM da decisão que tomou. Apesar da proposta ser interessante, principalmente a divisão do nível
Capítulo 7. Trabalhos relacionados 80
de decisão do LDM e do GDM, ela não se adequa ao cenário dos laboratórios de informática instalado na ECT, pois o aumento de novos servidores não aliviam imediatamente a falta de recursos em um servidor sobrecarregado.
De maneira similar,Maurer, Brandic e Sakellariou(2013) abordam o gerenciamento de uma infraestrutura de nuvem e propõem o gerenciamento de recursos entre máquinas virtuais (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 considera o provisionamento de novas máquinas virtuais. Para isso, eles aplicaram duas abordagens para o gerenciamento de conhecimento, o baseado em regras e o raciocínio baseado em casos, e as testou utilizando o processo MAPE-K. As técnicas apresentadas nesse trabalho serviram como inspiração para alguns aspectos do ConManager, como a definição de status para as máquinas virtuais, e o uso de regras para a tomada de decisão, que serviu como base para o processo de tomada de decisão realizado pela equipe de TI da ECT.
No trabalho deBarna et al. (2017) é proposto um sistema de gerenciamento au- tonômico (AMS do termo em inglês Autonomic management system) para aplicações multicamadas 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 alguma camada (que são atendidas por um ou mais contêineres por meio de balanceamento de carga) está sobrecarregada ou subutilizada para decidir se adiciona ou retira contêineres para atender o serviço. A análise se baseia na definição de limites e quando há a violação de algum deles, o módulo de planejamento é ativado chamando um plano diferente para cada limiar violado. O AMS age somente quando um limite é violado n vezes, onde n foi definido pelo administrador e no planejamento é proposto um algoritmo para escalar contêineres. O conceito central do algoritmo é chamado Heat que determina o acúmulo para adicionar ou remover contêineres, sendo que a sobrecarga no serviço resultará o aumento do Heat e a subutilização significa a sua diminuição. Com o aumento do Heat aumenta a chance de adicionar contêineres e vice-versa, visto que o resultado desse fator é constantemente verificado e o algoritmo informa ao AMS para executar a ação de escala conforme o indicado pelo modelo. Analisando o AMS proposto, conclui-se que a faixa de aplicação que o sistema se propõe atender não é compatível com nosso cenário, pois a abordagem de adicionar e remover contêineres não atende o requisito do serviço DaaS baseado em sessão. Justamente pelo fato do usuário continuar percebendo a lentidão do contêiner onde está hospedado. O conceito de Heat implementado no algoritmo é interessante e pode ser utilizado em trabalhos futuros, substituindo a abordagem atual de reverter a configuração com base no final da aula.
O trabalho feito por Morais et al.(2013) foca na problemática de elasticidade de recursos virtuais para atender demandas que variam de acordo com o tempo na computação em nuvem. O monitoramento e a predição foram elencados como tarefas importantes em
Capítulo 7. Trabalhos relacionados 81
um mecanismo que tem a responsabilidade de realizar o provisionamento automático e propõe um mecanismo para o provisionamento horizontal dos recursos, proativo e reativo independente de aplicação e possui configuração dinâmica e automática para realizar essas tarefas. A abordagem adotada para conseguir a elasticidade de recursos é através do provisionamento de novas máquinas virtuais para balancear a carga de trabalho entre as VMs. Dessa forma, o mecanismo proposto realiza o planejamento a curto prazo a capacidade necessá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 a cada tipo de recursos e quando um recurso atinge certo limite as ações são executadas. O comportamento proativo foi implementado através de preditores que estimam a utilização futura de uma camada com base na utilização dos recursos. Apesar de ser um trabalho muito interessante, ele não se aplica por completo no cenário dos laboratórios, pois sua abordagem de elasticidade é por meio de provisionamento de máquinas virtuais e o balanceamento de carga entre elas. Como já discutido, essa abordagem não resolve a sobrecarga de recursos sentida pela sessão do usuário, sendo necessária a finalização da sessã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 abstrata permite 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 em operação. Sua infraestrutura de tradução ajuda a mediar o mapeamento da informação através da abstração do sistema para o modelo, sendo possível manter vários mapeamentos no ambiente. Esse trabalho é capaz de se adaptar à diversas demandas, até mesmo à de gerenciamento de recursos entre contêineres, devido à sua capacidade de abstração do ambiente. Ele não foi utilizado na implantação da solução, porém a forma de adaptar o ambiente serviram de inspiração para a construção do ConManager.
7.3
Considerações finais
Neste 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ção que cada um dos trabalhos apresentados deu como inspiração para o ConManager, ne-