Continuamos a estudar cgroups. No Red Hat Enterprise Linux 7, eles são ativados por padrão, porque ele usa systemd, e ele, por sua vez, já possui cgroups embutidos. Com o Red Hat, o Red Hat Enterprise Linux 6 é um pouco diferente. De fato, os controladores cgroups estavam lá inicialmente, mas esta versão foi lançada, lembre-se de janeiro de 2010, isto é, alguns séculos atrás, em termos de anos de computador.
No entanto, os cgroups no Red Hat Enterprise Linux 6 são capazes de muito ainda hoje, o que ilustraremos hoje.
Vamos analisar os recursos dos cgroups no Red Hat Enterprise Linux 6 usando um exemplo puramente hipotético, baseado inteiramente em eventos reais. Mas para iniciantes, por tradição, uma pequena digressão.
Nunca houve tantos problemas com a segurança de TI como agora. Não é de surpreender, porque hoje não apenas todos os computadores e telefones estão conectados à rede, mas também geladeiras, aspiradores de pó e várias outras coisas - a possibilidade de ameaças à rede é simplesmente imensa. E a luta contra essas ameaças, em regra, começa imediatamente em todas as frentes. Instalação rápida de patches de segurança? Sim definitivamente! Fortalecendo a segurança do sistema - firewalls, SELinux, autenticação inteligente, isso é tudo? Claro! Scanners antivírus em máquinas Linux? Bem, como dizer ...
Em máquinas Linux, os antivírus às vezes fazem mais mal do que bem. No entanto, os guardas de segurança têm seus próprios motivos e geralmente exigem que você execute varreduras de antivírus regularmente, sem realmente pensar na integridade deles do ponto de vista técnico. E essa é uma realidade que é preciso suportar e com a qual, mais cedo ou mais tarde, quase todo especialista em TI enfrenta.
O segundo ponto é que o Red Hat Enterprise Linux 7 é obviamente moderno, avançado e interessante, mas muitos ainda usam o Red Hat Enterprise Linux 6 e não pensam em recusá-lo. De fato, é por isso que as pessoas escolhem a Red Hat - você pode permanecer na mesma versão por anos e ainda ter os patches, atualizações e suporte mais recentes.
Vamos voltar ao nosso exemplo ... Imagine que existe um cara chamado Jerry. Jerry trabalha em um grande escritório e é responsável pelo servidor Red Hat Enterprise Linux 6. Ele está completamente satisfeito com a forma como eles funcionam e não precisa de novos problemas e restrições.
Mas os funcionários do departamento de segurança decidem que em todos os servidores dele é necessário colocar uma coisa chamada ScanIT. E como essa coisa verifica periodicamente discos e memória quanto a vírus e outros malwares, ela precisa de acesso root completo.
Jerry suspira, abaixa o violão e vai colocar o ScanIT em uma máquina de teste. Muito rapidamente, acontece o seguinte:
- Ao executar uma verificação antivírus, o scanit (este é um script para iniciar o processo) consome todo o tempo do processador que pode atingir. E isso afeta muito o trabalho da máquina de teste - uma vez que Jerry nem conseguia alcançá-la no ssh.
- Além disso, o processo scanit consome memória de tempos em tempos, como se estivesse dentro de si. Como resultado, o OOM Killer acorda e começa a matar qualquer processo que não seja o próprio scanit.
Em geral, algo precisa ser feito com isso.
Jerry pega o violão e, tocando Grateful Dead, começa a pensar. Muito rapidamente, ocorreu-lhe que os mesmos cgroups do Red Hat Enterprise Linux 7 provavelmente poderiam ajudar aqui, sobre os quais um amigo chamado Alex tocou em seus ouvidos. Jerry novamente tira o violão e começa a ler as
docas enviadas por Alex
no Red Hat Enterprise Linux 6 . Acontece que a primeira coisa que ele precisa é do libcgroup.
Não há libcgroup na máquina de teste, então Jerry começa a instalá-lo:
Além disso, Jerry inclui dois serviços necessários para o trabalho de cgroups permanentes (persistentes):
- cgconfig - fornece uma interface mais ou menos simples para trabalhar com árvores de cgroup. Jerry certamente poderia montar e configurar o cgroups manualmente, mas por que, se você pode economizar tempo?
- cgred - esse é um mecanismo de regras do cgroup: quando um processo é iniciado, esse serviço o coloca em um ou outro cgroup de acordo com as regras especificadas.
Tendo instalado e configurado tudo isso, Jerry pode finalmente prosseguir diretamente para o problema em si. Depois de refletir cuidadosamente, ele toma a seguinte decisão:
- O scanit e seus processos filhos não devem consumir mais de 20% dos recursos da CPU. De fato, menos ainda - não mais que 20% dos recursos de um núcleo de processador, mesmo em uma máquina com vários núcleos. Nos cgroups, isso é feito usando cotas de CPU.
- Quanto à memória, o scanit e seus processos filhos não devem consumir mais que 512 MB de memória do sistema. Se eles estão cruzando essa linha, o sistema deve matá-los, e não quaisquer outros processos.
Não há necessidade de me dizer o que fazer!
Jerry terá que lidar com dois conjuntos de arquivos de configuração:
- /etc/cgconfig.conf - Gerado automaticamente ao instalar o libcgroup.
- /etc/cgrules.conf - contém um conjunto de regras do conjunto de regras, de acordo com o qual o cgred classifica os processos em execução por grupos do cgroups.
Aqui está a aparência do arquivo cgconfig.conf padrão:
Jerry poderia ter feito as alterações necessárias diretamente para ele, mas é melhor usar arquivos conf drop-in para isso. Como isso funciona? Se você colocar (por exemplo, drop-in-drop) na pasta /etc/cgconfig.d qualquer arquivo com a extensão .conf, o sistema o processará e fará as alterações apropriadas na configuração. Isso é conveniente porque você pode criar drop-ins para diferentes tarefas e adicioná-los ou removê-los da configuração usando as ferramentas que você mais gosta (por exemplo, Ansible, bem, ainda é um blog da Red Hat).
Jerry primeiro cria um arquivo drop-in para a CPU:
Nós olhamos o que temos aqui e como ele funciona.
A palavra-chave group simplesmente define o nome do novo cgroup, no nosso caso, scanit. Dentro das chaves, especificamos os controles cgroup que queremos usar. Aqui, cpu.cfs_period_us e cpu.cfs_quota_us, eles permitem que você defina os limites correspondentes no Completely Fair Scheduler, o agendador de kernel usado por padrão no Red Hat Enterprise Linux 6. Vamos ver o que está escrito sobre eles no
Guia de Gerenciamento de Recursos do
Red Hat Enterprise Linux 6 :
Em outras palavras, Jerry escreveu isso em seu drop-in: “Para cada processo relacionado ao cgroup chamado scanit, uma vez por segundo, verifique a quantidade de recursos da CPU alocados a ele. Se o tempo total do processador para todos os processos deste grupo for superior a 200.000 milissegundos, pare completamente de dar tempo ao processador para esses processos ". Bem, isto é, alocar para todos os processos no scanit cgroup-group, bem como para os processos filhos, no total, no máximo, 20% do tempo do processador.
Após reiniciar o cgconfig, o servidor atualizará a configuração e, se você entrar no sistema de arquivos, veremos que o scanit está agora localizado no diretório do controlador da CPU:
Isso, é claro, é bom, mas ainda precisamos, de alguma forma, empurrar o scanit para esse cgroup. Crged é útil aqui, por padrão, é algo como isto:
Usar este arquivo é mais ou menos fácil. No entanto, para isso, teremos que editar diretamente o arquivo cgrules.conf, pois o mecanismo de entrada não é suportado aqui. Indicamos o usuário ou grupo que possui o processo, bem como o nome do processo específico - se você desejar -, bem como um controlador personalizado e um grupo de destino do cgroup.
Em nosso exemplo, em vez do scanit antivírus real, usamos um script que também é chamado scanit, mas na verdade apenas emula a carga. Sem o cgroup, tudo fica assim:
A CPU está totalmente ocupada, principalmente pelo espaço do usuário e um pouco de sistema.
Jerry coça a barba. Inicia o vi e, usando exatamente um dedo indicador, faz algumas alterações e reinicia o daemon cgred:
Em seguida, ele lança manualmente o scanit ...:
E - Saúde! Vitória
Como você pode ver, nossos processos de emulação de carga (processos filhos de scanits) agora consomem um total de 20% dos recursos da CPU, principalmente no espaço do usuário e um pouco no sistema. Portanto, esse maldito antivírus não carregará mais o carro com total insanidade.
Lembra o que vem a seguir?
Regozijado com o sucesso, Jerry quase esqueceu sua memória. Mas ele ainda se lembra e inicia o vi novamente para corrigir seu arquivo de configuração.
Agora ele adiciona duas configurações em relação à memória:
- Memory.limit_in_bytes - máx. A quantidade de RAM que todos os processos no scanit cgroup podem usar. E excluindo espaço de troca. Jerry limita a 256 MB
- Memory.memsw.limit_in_bytes - máx. Volume de RAM, mais espaço no arquivo de troca, que pode ser alocado para todos os processos no scanit cgroup-group, no total. Se esse limite for excedido, os processos serão eliminados pelo killer do OOM. Jerry define para 512 MB.
Oh não! O que está errado?
Jerry olha para o topo e vê que os processos filho do scanit ainda estão em execução. Como este cgroup está atualmente em uso, Jerry não pode iniciar o serviço. Portanto, ele mata processos filho manualmente e reinicia esses serviços.
Agora, uma pequena edição no cgred.conf:
Para verificar, Jerry executa várias tarefas de scanit de uma só vez, para que o assassino do OOM funcione com certeza.
Então Jerry olha para o log do sistema e assente com satisfação - o scanit não pode mais deixar a memória em quantidades com impunidade.
Esperamos que nossa série de artigos do cgroups tenha ajudado você a entender o que é, como usá-lo no Red Hat Enterprise Linux 7, como criá-lo no Red Hat Enterprise Linux 6 e como usá-lo em seu ambiente.