Nesta 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, os administradores do ambiente já o utilizavam para realizar as adaptações nos recursos dos servidores de aplicação. Os primeiros módulos desenvolvidos foram o de monitoramento, 3 <http://manpages.ubuntu.com/manpages/wily/man1/stress.1.html>
Capítulo 6. Avaliação 70
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 consultasse a aba de horários, de gráficos, de distribuição de recursos para tomar uma decisão. O primeiro caso relatado evidencia essa fase. À medida que o desenvolvimento se dava, a fase de planejamento foi concluída (precisando ainda que o administrador aperte o botão para 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ório 2 estava reservado para quatro aulas seguidas da disciplina de Lógica de Programação. As duas primeiras aulas ocorreram entre 18:45 e 20:30, com um intervalo de 15 minutos, e o reinício das aulas as 20:45 até as 22:15. Nesse dia não havia nenhuma aula agendada para os outros laboratórios, e um dos laboratórios estava liberado para uso livre pelos estudantes.
A tela principal do ConManager é constantemente exibida na sala da equipe de TI da ECT. Os dados de monitoramento de CPU e memória RAM desse dia para o laboratório em questão são apresentados na Figura 24. A cor verde no gráfico de CPU representa a medida de tempo ocioso (disponível), enquanto que as outras cores representam que a CPU está ocupada. A cor verde no gráfico de consumo de memória representa a quantidade de memória livre, enquanto que a linha preta representa o total de memória alocado ao servidor de aplicação. Por volta de 19:05, o administrador foi chamado a atenção por dois
Capítulo 6. Avaliação 71
alertas de sobrecarga no laboratório em que estava ocorrendo a aula. O primeiro alerta indicava sobrecarga de memória RAM que estava com menos de 10% disponível por mais de 5 minutos, e o segundo uma sobrecarga de CPU que permanecia acima de 70% por mais de 5 minutos.
Figura 24 – Dados de utilização de CPU e memória RAM do laboratório durante aula de lógica de programação.
Para decidir como responder a esta situação, o administrador inicialmente consultou o cronograma de aulas para o laboratórios em questão, e para os outros. Após constatar que não havia nenhuma aula ocorrendo em paralelo o administrador decidiu realizar duas intervenções, aumentar a quantidade de memória RAM e de CPU alocada ao servidor de aplicaçã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 e acrescentado 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 para retornar aos parâmetros de referência seria no término da aula (22:15). Essas intervenções surtiram efeito imediatamente de forma que o monitoramento do ConManager entendesse que 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ção de CPU e memória voltaram a crescer, novamente ultrapassando os limites de CPU e memó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 de CPU, uma vez que apesar da sobrecarga nesse servidor, o recurso de CPU não estava sobrecarregado no hardware. A nova intervenção aumentou o percentual de uso do CPU de 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, os valores de CPU e memória alocados ao laboratório foram realocados de acordo com os
Capítulo 6. Avaliação 72
Hora Ação Recurso Laboratório Qtd manipulado
Qtd referência
Qtd temporário
19:12:42 Retirar RAM Lab 4 3 GB 16 GB 13 GB
19:15:28 Inserir RAM Lab 2 3 GB 16 GB 19 GB
19: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 GB
19: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 tabela5 sumariza as intervenções realizadas pelo administrador, onde Qtd manipulado representa a quantidade de recurso retirada/inserida a um servidor de aplicação, Qtd referência é a distribuição de recursos definida no início do semestre letivo, 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 recursos disponí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, na disciplina de Lógica de Programação. A aula começou às 10:50 e finalizou 12:30. Nesse intervalo de tempo o laboratório de informática 1 estava sendo utilizado como aberto ao público, no laboratório 4 começou ao mesmo tempo outra aula e no laboratório 3 não havia aula marcada, fazendo assim, que os recursos alocados a esse laboratório estivessem subutilizados.
Como foi explicado na Seção2.1.2, o CPU é compartilhado por todos os contêineres e o cpulimit indica o percentual de utilização de cada um. A quantidade de cpulimit é de acordo com a quantidade de núcleos de processamento presente no hardware. O cenário conta com 16 núcleos que totaliza 16000 cpulimits disponíveis para ser distribuídos entre os contêineres. A Figura 25 apresenta as telas do ConManager divididas por uma linha laranja. 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 o pico de carga de processamento de 11.04, sendo que a trigger configurada dispara quando a carga 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 ConManager sugeriu duas ações. A primeira é adicionar 18.75% de cpulimit no laboratório 2 (ficando assim com 43.75% do CPU do hardware) até 12:30. A segunda é retirar essa mesma quantidade 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 de utilização do processador representado no gráfico (b) CPU Load - LAB2 , onde a linha
Capítulo 6. Avaliação 73
Figura 25 – Telas do ConManager no momento que foi acusado a sobrecarga no laboratório 2
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 último minuto chegou a atingir o valor de 13.56 e ficou acima de 6 por mais de 5 minutos, causando o alerta. Nessa mesma faixa de horário o gráfico (a) Cpu Utilization - LAB2 registra o pico de utilização de 64.56%, não chegando a gerar o alarme de sobrecarga. Após a
Capítulo 6. Avaliação 74
Figura 27 – Gráfico de utilização da quantidade de usuários logados durante a aula de lógica de programação
intervenção o uso do CPU normalizou no restante da aula, sem ocorrências de novos picos de 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 da aula. Nela percebe-se que o pico do CPU tem relação com a chegada dos usuários ao laboratório, mas que o consumo ficou abaixo do que é considerado sobrecarregado mesmo com o número alto de usuários logados. As intervenções foram revertidas automaticamente às 12:30.