As camadas relevantes no ambiente de atuação do ConManager são: hardware/ sistema operacional (S.O.), gerenciador de contêineres, Servidor de aplicação e balanceador de cargas. As adaptações ocorrerão nas camadas do gerenciador de contêineres através de manipulação de servidores de aplicação como criação, exclusão, redimensionamento de memória RAM, Swap, processador, disco e na camada do balanceador de cargas incluindo e excluindo servidores de aplicações do balanceador de carga do ambiente. As demais camadas servirão de base para o monitoramento do ambiente para auxiliar na tomada de decisão. Abaixo serão listadas todas as camadas existentes e quais os parâmetros devem ser monitorados pelo ConManager:
Camada: Hardware/S.O.: Os dados que deverão ser coletados diretamente do hardware/ sistema operacional são:
1. Processamento
• Porcentagem de utilização do CPU: Porcentagem ocioso, Utilizado por usuários, Utilizado pelo sistema, Espera IO;
• Carga de processamento (load average): Carga média do último minuto, Carga média dos últimos 5 minutos, Carga média dos últimos 15 minutos;
• Quantidade de núcleos do processador 2. Memória
• Total de memória RAM do sistema • Quantidade de memória RAM disponível • Total de memória SWAP do sistema • Quantidade de memória SWAP disponível 3. Rede
Apêndice A. Apêndice - Requisitos do sistema 87
• Tráfego de saída de cada interface de rede do hardware 4. Armazenamento
• Quantidade total de espaço em disco • Quantidade utilizada do espaço em disco
Gerenciador de contêiner: Os seguintes dados deverão ser obtidos do gerenciador de contêiner (OpenVZ):
1. Dados dos contêineres
• Contêineres criados/ativos • Nome do contêiner
• ID do contêiner
• Quantidade de núcleos de processamento (utilizado para calcular o cpulimit) 2. Provisionamento de recursos de cada contêiner:
• Armazenamento: espaço em disco
• Processamento: Percentual máximo da utilização do CPU (em cpulimit) - valor máximo que o container vai conseguir usar da CPU.
• Memória: Quantidade memória Ram alocada e quantidade de memória Swap alocada
Camada: Servidor de aplicação (para cada servidor de aplicação): Em todos os contêineres que atendem os usuários nos laboratórios deverão ter os seguintes dados coletados:
1. Sessões ativas (usuários logados)
2. Processamento, memória, rede e armazenamento semelhante ao monitorado na camada de hardware/S.O.
Camada: Balanceador de cargas: No balancador de cargas deverão ser coletados os seguintes dados:
1. Quantidade de grupos (um grupo para cada laboratório)
2. Para cada grupo:
• IP do servidor • Nome do servidor
Apêndice A. Apêndice - Requisitos do sistema 88
A.2
Quando
A adaptação acontecerá em duas camadas: Na camada do gerenciador de contêiner acontecerá de forma reativa, quando um dos servidores de aplicação estiver sobrecarregado e de forma proativa quando o ConManager, baseado na tabela de horários e no histórico de intervenções para aquela aula, redimensionar os recursos para um valor que melhor atenda a demanda. Na camada do balanceador de cargas acontecerá quando um contêiner é incluído ou excluído nos grupos de balanceamento.
A adaptação na camada do gerenciador de contêineres pode ser aplicada quando o processo de redimensionamento dos recurso entre os servidores não influenciar na utilização do servidor de aplicação que teve parte de seus recursos retirados, como por exemplo: Não tem aula no laboratório que os recursos estão subutilizados. O ConManager deverá também ser capaz de analisar os eventos ocorridos para determinar a quantidade de recurso mais adequado de acordo com a aula, dessa forma será possível fazer o redimensionamento instantes antes da aula começar. O momento de reverter a adaptação deverá acontecer quando a aula do contêiner sobrecarregado acabar ou quando o turno acabar (para casos de laboratórios de uso geral).
Na camada de balanceador de carga a adaptação acontecerá de forma reativa: quando o administrador criar/excluir um servidor de aplicação no ConManager, informando em qual grupo (no balanceador de cargas) será feita a alteração.
A.3
O quê
Os artefatos que poderão ser alterados serão listados de acordo com as camadas identificadas. Será exemplificado também qual a abordagem para verificar se a mudança foi realmente executada.
Camada: Gerenciador de contêiner: Os artefatos que podem sofrer alteração na camada de gerenciador de contêiner são:
1. Contêineres ativos
• Criar contêiner. Checar na listagem dos contêineres. • Excluir container. Checar na listagem dos contêineres.
• Iniciar contêiner. Checando o número de contêineres rodando. • Parar container. Checando o número de contêineres rodando. 2. Quantidade de recursos alocados para cada contêiner
• Armazenamento - espaço em disco: Configurar nova cota. Listar após a alteração, a quantidade de espaço em disco.
Apêndice A. Apêndice - Requisitos do sistema 89
• Processamento - Percentual Máximo de utilização do CPU (levando em conside- ração o parâmetro cpulimit). Listar após a alteração a quantidade de cpulimit alocado.
• Memória RAM - Quantidade de memória RAM alocada ao contêiner. Listar após a alteração, a quantidade de memória RAM alocada.
• SWAP - Quantidade de SWAP alocada ao contêiner. Listar após a alteração, a quantidade de SWAP alocada.
Camada: balanceador de cargas: Os artefatos que podem sofrer alteração na camada balanceador de cargas são:
1. Grupos
• Quantidade de servidores de aplicação por grupo. Sendo que cada grupo repre- senta um laboratório e os servidores incluídos nos grupos atendem as requisições demandadas por esse laboratório.
• Endereço IP e nome do servidor de cada grupo.
A.4
Porquê
A abordagem escolhida para solucionar o desafio de criar e gerenciar vários servidores de aplicação que atendessem o ambiente de acesso remoto montado nos laboratórios de informática, foi a utilização de contêineres compartilhando recursos do hardware. Por esse fato, há sobrecarga de recursos em alguns servidores, enquanto em outros o recurso é subutilizado, gerando perda de desempenho nos computadores do laboratório com muita utilização. O ConManager é um sistema que monitora o uso dos servidores e autoadapta o provisionamento dos recursos entre instâncias para prover o melhor aproveitamento deles, otimizando os recursos do hardware.
A.5
Quem
O ConManager deverá ser capaz de seguir as fases determinadas pelo Mape-K de maneira autônoma. No entanto, o sistema deve ser capaz de prover o máximo de informações que auxiliem o administrador nos casos que a intervenção humana for necessária. Essa intervenção consiste na adaptação dos recursos dos contêineres e adaptação do serviço de balanceamento de cargas. Para isso, é necessário que o sistema avise ao administrador que há sobrecarga de recursos, exiba a quantidade de recursos distribuídas entre os contêineres, exiba também os gráficos de utilização do ambiente, além da tabela de horário das aulas. Essas informações auxiliarão a tomar a decisão mais acertada.
Apêndice A. Apêndice - Requisitos do sistema 90
Todas as ações executadas, humanas ou autônomas, no ambiente provido nos laboratórios devem ser feitas exclusivamente no ConManager. Para isso o sistema deve prover a estrutura necessária (comandos que executem as ações) para realizar as alterações necessárias dentro do gerenciador de contêiner.
O administrador do ConManager deverá inserir as regras de negócio que irão guiar o sistema na tomada de decisão presente na fase de planejamento. As regras especificam ao ConManager quando entender que um servidor está sobrecarregado, quanto de recurso deve redimensionar, qual horário reverter, etc. Essas configurações poderão ser alteradas pelo administrador de acordo com a necessidade.
A.6
Como
Aqui serão listadas todas as ações necessárias para implementar as mudanças. Cada ação tem um número, descrição, os parâmetros utilizados na ação, a forma que a ação será implementada, pré-condição e pós-condição.
Camada: Gerenciador de contêiner: 1. Criar e configurar servidor de aplicação
• Descrição da ação: Essa ação cria um novo contêiner configurado de acordo com os parâmetros recebidos.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação criado.
– Ostemplate:String: template do sistema operacional usado para criar o template
– DiskMin:Inteiro: Valor que determina a quantidade mínima de espaço em disco o servidor de aplicação poderá fazer uso. Pode-se colocar junto com o valor numérico a letra M para indicar que a medida será alocada em Megabytes ou um G para alocar a quantidade em gigabytes.
– DiskMax:Inteiro: Valor que determina a quantidade máxima de espaço em disco o servidor de aplicação poderá fazer uso. Pode-se colocar junto com o valor numérico a letra M para indicar que a medida será alocada em Megabytes ou um G para alocar a quantidade em gigabytes.
– Ram:Inteiro: Quantidade de memória RAM do hardware que será alocada para o servidor de aplicação. Pode ser determinada por um número inteiro que indica quantidade de memória RAM junto com um M para alocar a quantidade em Megabytes ou um G para alocar a quantidade em Gigabytes.
Apêndice A. Apêndice - Requisitos do sistema 91
– Swap:Inteiro: Quantidade de memória Swap do hardware que será alocada para o servidor de aplicação. Pode ser determinada por um número inteiro que indica quantidade de memória Swap junto com um M para alocar a quantidade em Megabytes ou um G para alocar a quantidade em Gigabytes. – Cpuunits:Inteiro: Unidade de medida representada em números inteiros
positivos que determinam o mínimo garantido de tempo de CPU que um servidor de aplicação irá receber. Cuplimit:Inteiro: Um número inteiro positivo que indica o percentual de tempo de utilização do CPU por servidor de aplicação.
– Userpasswd:String: Senha do usuário administrador
– Onboot:String: Determina se o contêiner ligará sozinho após a inicialização do hardware. Valor padrão é String com “yes” ou “no”.
– Hostname:String: Informa o nome do hostname do servidor de aplicação criado. Nameserver:String: informa o IP do DNS para o servidor de aplicação – IP:String: informa o IP do servidor de aplicação que está sendo configurado. • Implementação: Esta ação é implementada através de um método da API
OpenVZ fazendo uso de chamadas ao comando vzctl. As seguintes chamadas precisam ser realizadas na ordem apresentada.
– vzctl create $id –ostemplate $ostemplate -–config basic –hostname $host- name
– vzctl set $id –onboot $onboot –save – vzctl set $id –ipadd $ip –save
– vzctl set $id –nameserver $nameserver –save – vzctl set $id –diskspace $diskmin:$diskmax –save – vzctl set $id –ram $ram –save
– vzctl set $id –swap $swap –save
– vzctl set $id –cpuunits $cpuunits –save – vzctl set $id –cpulimits $cpulimits –save
– Vzctl set $id –userpasswd root:$userpasswd –save
• Pré-condição: É necessário que existam recursos disponíveis para se criar o contêineres com a configuração desejada.
• Pós-condição: Servidor criado com sucesso. Servidor é criado com status parado 2. Iniciar servidor de aplicação
• Descrição da ação: Essa ação inicia um servidor de aplicação que está com o status parado.
Apêndice A. Apêndice - Requisitos do sistema 92
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser iniciado;
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamada precisa ser realizada para iniciar o servidor de aplicação indicado.
– Vzctl start $id
• Pré-condição: Para iniciar um servidor de aplicação é necessário que ele esteja com o status “stopped”.
• Pós-condição: O servidor é iniciado, seu status fica com a descrição “running”. 3. Parar servidor de aplicação
• Descrição da ação: Essa ação para um servidor de aplicação que está com o status ativo.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser parado;
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamada precisa ser realizada para parar o servidor de aplicação indicado.
– Vzctl stop $id
• Pré-condição: Para iniciar um servidor de aplicação é necessário que ele esteja com o status “running”.
• Pós-condição: O servidor é parado, seu status fica com a descrição “stopped”. 4. Destruir servidor de aplicação
• Descrição da ação: Essa ação destrói um servidor de aplicação. • Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser destruído;
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. As seguintes chamadas precisam ser realizada para destruir o servidor de aplicação indicado.
– Vzctl stop $id; – Vzctl destroy $id;
• Pré-condição: O servidor deve ter seu status como parado • Pós-condição: O servidor é destruído
Apêndice A. Apêndice - Requisitos do sistema 93
5. Destruir servidor de aplicação
• Descrição da ação: Essa ação destrói um servidor de aplicação. • Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser destruído;
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. As seguintes chamadas precisam ser realizada para destruir o servidor de aplicação indicado.
– Vzctl stop $id; – Vzctl destroy $id;
• Pré-condição: O servidor deve ter seu status como parado. • Pós-condição: O servidor é destruído.
6. Reiniciar servidor de aplicação
• Descrição da ação: Essa ação reinicia um servidor de aplicação. • Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser reiniciado;
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamada precisa ser realizada para reiniciar o servidor de aplicação indicado.
– Vzctl restart $id;
• Pré-condição: O servidor deve estar com o status “running”.
• Pós-condição: O servidor é reiniciado, todos seus processos são reiniciados. 7. Consultar o status do servidor de aplicação
• Descrição da ação: Essa ação retorna o status do servidor de aplicação, consul- tando se o servidor se encontra iniciado ou parado.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser reiniciado;
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzlist. A seguinte chamada precisa ser realizada para consultar o status do servidor de aplicação indicado.
– Vzlist $id -Ho status;
• Pré-condição: O servidor de aplicação deve estar criado para que seja consultado seu status.
Apêndice A. Apêndice - Requisitos do sistema 94
• Pós-condição: O método retorna a string indicando o status do servidor. 8. Redimensionar espaço em disco de um servidor de aplicação
• Descrição da ação: Essa ação redimensiona em tempo real o espaço em disco alocado para um servidor de aplicação.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ser manipulado. – DiskMin:Inteiro: Valor que determina a quantidade mínima de espaço em
disco o servidor de aplicação poderá fazer uso. O valor passado será em Gigabytes.
– DiskMax:Inteiro: Valor que determina a quantidade máxima de espaço em disco o servidor de aplicação poderá fazer uso. O valor passado será em Gigabytes.
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. Os seguintes passos precisam ser realizados para efetuar a manipulação do espaço em disco servidor de aplicação indicado.
– Checa se o valor passado não é menor que o espaço já utilizado pelo servidor. Com isso, não é possível reduzir o disco a um valor que já está em uso. – Variável recebe valor do comando (vzlist $id -Ho diskspace) e é passada na
função que retorna o valor em Gigabytes.
– Se o valor $diskmin for maior que obtido no passo anterior, executa o próximo passo.
– vzctl set $id –diskspace $diskminG:$diskmaxG –save
• Pré-condição: O valor a ser alterado de armazenamento não pode ser menor que o já utilizado pelo servidor de aplicação.
• Pós-condição: O servidor terá seu novo valor de espaço em disco após a mani- pulação.
9. Redimensionar memória ram de um servidor de aplicação
• Descrição da ação: Essa ação redimensiona a quantidade de memória RAM alocada para um servidor de aplicação em tempo real.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ter recurso manipulado. – Ram:Inteiro: Quantidade de memória RAM do hardware que será alocada
Apêndice A. Apêndice - Requisitos do sistema 95
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. Os seguintes passos precisam ser realizados para efetuar a manipulação da memória RAM no servidor de aplicação indicado.
– Checa se o valor passado não é menor que a quantidade de memória que está em uso com o seguinte comando:
– vzctl exec $id free -g | grep "Mem: awk ’print $3’
– Caso o valor passado em $ram seja maior, executa o próximo passo. – vzctl set $id –ram $ramG –save
• Pré-condição: A quantidade de memória RAM manipulada não pode ser menor que a quantidade da memória que está em uso.
• Pós-condição: O servidor disponibilizará da quantidade de memória RAM alocada com a manipulação.
10. Redimensionar memória Swap de um servidor de aplicação
• Descrição da ação: Essa ação redimensiona a quantidade de memória Swap alocada para um servidor de aplicação em tempo real.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ter recurso manipulado. – Swap:Inteiro: Quantidade de memória Swap do hardware que será alocada
para o servidor de aplicação. O valor trabalhado será em GB.
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. Os seguintes passos precisam ser realizados para efetuar a manipulação da memória Swap no servidor de aplicação indicado.
– Checa se o valor passado não é menor que a quantidade de memória que está em uso com o seguinte comando:
– vzctl exec $id free -g | grep "Swap: awk ’print $3’ Caso o valor passado em $swap seja maior, executa o próximo passo. vzctl set $id –ram $swapG –save
• Pré-condição: A quantidade de memória Swap manipulada não pode ser menor que a quantidade da memória que está em uso.
• Pós-condição: O servidor disponibilizará da quantidade de memória Swap alocada com a manipulação.
Apêndice A. Apêndice - Requisitos do sistema 96
• Descrição da ação: Essa ação altera o limite de utilização do CPU para um servidor de aplicação em tempo real.
• Parâmetros:
– ID:Inteiro: Identificador do servidor de aplicação a ter recurso manipulado. – Cuplimit:Inteiro: Um número inteiro positivo que indica o percentual de
tempo de utilização do CPU por servidor de aplicação.
• Implementação: Esta ação é implementada através de um método da API OpenVZ fazendo uso de chamadas ao comando vzctl. A seguinte chamada precisa ser realizada para efetuar a manipulação do cpulimit no servidor de aplicação indicado.
– Vzctl set $id –cpulimit $cpulimit –save;
• Pré-condição: É recomendado que essa alteração seja feita considerando a quantidade de cpulimit distribuída entre os outros servidores de aplicação e a quantidade de núcleos de CPU do hardware, pois essa informação determina o quanto de cpulimit pode ser distribuído entre os servidores de aplicação.
• Pós-condição: O servidor recebe um novo limite de utilização do CPU. 12. Incluir servidores de aplicação nos grupos do LTSP-Cluster
• Descrição da ação: Essa ação inclui um servidor de aplicação no serviço LTSP- Cluster dentro do grupo (laboratório) indicado.
• Parâmetros:
– Grupo:String: Determina em qual dos laboratórios o servidor será incluído. – IP:String: Indica o IP do servidor incluído.
– Nameserver:String: Indica o Nameserver do servidor incluído.
• Implementação: Esta ação é implementada através de um agente ConManager escrito em PHP com a biblioteca de alteração de XML DOM. O agente recebe os dados providos pelo ConManager e faz a inserção do servidor no grupo indicado. Os seguintes passos serão seguidos:
– O agente ConManager recebe os dados da ação inserir novo servidor. – Realiza a ação #6 consultando o status do servidor.
– Se o servidor estiver com o status “running”, o agente prossegue na inserção do servidor no arquivo de configuração do LTSP-Cluster.
• Pré-condição: Não poderá criar novos grupos a partir do agente, somente a inserção de servidores em grupos já existentes. Antes de inserir um novo servidor, é recomendado verificar o status do servidor, consultando se ele está ativo.
Apêndice A. Apêndice - Requisitos do sistema 97
• Pós-condição: O arquivo de configuração do serviço LTSP-Cluster tem o servidor incluído.
13. excluir servidores de aplicação nos grupos do LTSP-Cluster
• Descrição da ação: Essa ação exclui um servidor de aplicação no serviço LTSP- Cluster dentro do grupo (laboratório) indicado.
• Parâmetros:
– Grupo:String: Determina em qual dos laboratórios o servidor será excluído. – IP:String: Indica o IP do servidor excluído.
– Nameserver:String: Indica o Nameserver do servidor excluído.
• Implementação: Esta ação é implementada através de um agente ConManager escrito em PHP com a biblioteca de alteração de XML DOM. O agente recebe os dados providos pelo ConManager e faz a exclusão do servidor no grupo