Computadores são hardware. E hoje voltamos ao ponto de partida, no sentido de que agora você raramente encontra um host físico no qual uma única tarefa é executada. Mesmo se apenas um aplicativo estiver em execução no servidor, provavelmente ele consiste em vários processos, contêineres ou até máquinas virtuais (VMs), e todos eles funcionam no mesmo servidor. O Red Hat Enterprise Linux 7 lida bem com a distribuição de recursos do sistema nessas situações, mas, por padrão, ele se comporta como uma avó gentil, tratando os netos com bolo caseiro e dizendo: "Igualmente a todos, igualmente a todos".
Em teoria, o princípio de "igualmente dividido", é claro, é belo, mas, na prática, alguns processos, contêineres ou VMs são mais importantes que outros e, portanto, devem receber mais.
O Linux há muito tempo possui ferramentas de gerenciamento de recursos (nice, ulimit etc.), mas com o advento do Red Hat Enterprise Linux 7 e systemd, finalmente temos um conjunto poderoso dessas ferramentas integradas ao próprio sistema operacional. O fato é que o principal componente do systemd é um conjunto pronto e personalizado de cgroups que é totalmente utilizado no nível do SO.
Bem, que tipo de cgroups são esses e para onde vai o gerenciamento de recursos ou desempenho?
Controle no nível do kernel
Começando com a versão 2.6.24, lançada em janeiro de 2008, o kernel Linux apareceu originalmente inventado e criado no Google sob o nome "process containers" e, no Linux, ficou conhecido como "control groups", cbroups abreviados. Em resumo, o cgroups é um mecanismo do kernel que permite limitar o uso, manter registros e isolar o consumo de recursos do sistema (CPU, memória, E / S de disco, rede etc.) no nível das coleções de processos. Os Cgroups também podem congelar processos para verificar e reiniciar. Os controladores Cgroups apareceram pela primeira vez na versão 6 do Red Hat Enterprise Linux, mas eles precisavam ser configurados manualmente. Mas com o advento do Red Hat Enterprise Linux 7 e systemd, o conjunto pré-configurado de cgroups vem com o sistema operacional.
Tudo isso funciona no nível do kernel do sistema operacional e, portanto, garante um controle rigoroso sobre cada processo. Portanto, agora é extremamente difícil para qualquer malware carregar o sistema, para que ele pare de responder e congele. Embora, é claro, o código de buggy com acesso direto ao hardware (por exemplo, drivers) ainda seja capaz disso. Ao mesmo tempo, o Red Hat Enterprise Linux 7 fornece uma interface para interagir com cgroups, e todo o trabalho com eles é feito principalmente através do comando systemd.
Seu pedaço de bolo
O diagrama abaixo, remanescente de uma fatia de fatias, mostra três cgroups que são por padrão no servidor Red Hat Enterprise Linux 7 - Sistema, Usuário e Máquina. Cada um desses grupos é chamado de "fatia" (setor de fatia). Como você pode ver na figura, cada fatia pode ter setores de fatia filhos. E, como no caso do bolo, no total, todas as fatias fornecem 100% do recurso correspondente.
Agora, vejamos vários conceitos de cgroups usando os recursos do processador como exemplo.
A figura acima mostra que o tempo do processador é dividido igualmente entre as três fatias de nível superior (Sistema, Usuário e Máquina). Mas isso só acontece sob carga. Se algum processo da fatia Usuário solicitar 100% dos recursos do processador e ninguém mais precisar desses recursos no momento, ele receberá 100% do tempo do processador.
Cada uma das três fatias de nível superior foi projetada para seu tipo de carga de trabalho, que divide os setores filhos na fatia pai:
- Sistema - daemons e serviços.
- Usuário - sessões de usuário. Cada usuário recebe uma fatia subordinada e todas as sessões com o mesmo UID "vivem" na mesma fatia, de modo que especialistas em inteligência inteligentes não podem obter recursos mais do que deveriam.
- Máquina - máquinas virtuais, como convidados KVM.
Além disso, o conceito da chamada “bola” (compartilhamento) é usado para controlar o uso de recursos. Uma bola é um parâmetro numérico relativo; seu valor faz sentido apenas em comparação com os valores de outras bolas incluídas no mesmo cgroup. Por padrão, todas as fatias têm uma bola igual a 1024. Na fatia do sistema na figura acima, as bolas de CPU iguais a 1024 são definidas para httpd, sshd, crond e gdm. Os valores de bola para fatias de sistema, usuário e máquina também são 1024. É um pouco confuso? De fato, isso pode ser representado como uma árvore:
- Sistema - 1024
- httpd - 1024
- sshd - 1024
- crond - 1024
- gdm - 1024
- Usuário - 1024
- bash (mrichter) - 1024
- bash (dorf) - 1024
- Máquina - 1024
Nesta lista, temos vários daemons em execução, alguns usuários e uma máquina virtual. Agora imagine que todos solicitem simultaneamente todo o tempo do processador que pode ser obtido.
Em resumo:
- O Slice System recebe 33,333% do tempo do processador e o compartilha igualmente entre quatro demônios, o que fornece a cada um deles 8,25% dos recursos da CPU.
- A fatia Usuário recebe 33,333% do tempo do processador e o compartilha entre dois usuários, cada um com 16,5% dos recursos da CPU. Se o usuário mrichter fizer logout ou parar todos os processos em execução, o dorf terá acesso a 33% dos recursos da CPU.
- Slice Machine recebe 33,333% do tempo do processador. Se você desligar a VM ou colocá-la no modo ocioso, as fatias do sistema e do usuário receberão aproximadamente 50% dos recursos da CPU, que serão compartilhados entre as fatias filho.
Além disso, para qualquer daemon, usuário ou máquina virtual, é possível inserir não apenas restrições relativas, mas também absolutas, no consumo de tempo do processador, não apenas um, mas também vários processadores. Por exemplo, o usuário slice mrichter possui a propriedade CPUQuota. Se você defini-lo como 20%, o mrichter em nenhuma circunstância receberá mais de 20% dos recursos de uma CPU. Em servidores com vários núcleos, o CPUQuota pode ser superior a 100%, para que a fatia possa usar os recursos de mais de um processador. Por exemplo, com CPUQuota = 200%, uma fatia pode utilizar totalmente dois núcleos de processador. É importante entender que o CPUQuota não reserva, em outras palavras, não garante uma determinada porcentagem de tempo do processador para qualquer carga do sistema - este é apenas o máximo que pode ser alocado a uma fatia, levando em consideração todas as outras fatias e configurações.
Torça ao máximo!
Como posso alterar as configurações de fatia?
Para isso, cada fatia tem propriedades personalizadas. E, como é o Linux, podemos escrever manualmente as configurações nos arquivos de configuração ou na linha de comando.
No segundo caso, o comando systemctl set-property é usado. Aqui está o que acontecerá na tela se você digitar este comando, adicione o nome da fatia no final (no nosso caso, Usuário) e pressione a tecla Tab para exibir as opções:
Nem todas as propriedades nesta captura de tela são configurações do cgroup. Estamos interessados principalmente naqueles que iniciam em Block, CPU e Memória.
Se você preferir não a linha de comando, mas os arquivos de configuração (por exemplo, para implantação automatizada em vários hosts), precisará lidar com os arquivos na pasta / etc / systemd / system. Esses arquivos são criados automaticamente quando você define as propriedades usando o comando systemctl, mas também podem ser criados em um editor de texto, carimbado no Puppet ou até mesmo gerado por scripts em tempo real.
Portanto, com os conceitos básicos do cgroups, tudo deve ficar claro. Da próxima vez, examinaremos alguns cenários e veremos como as alterações em certas propriedades afetam o desempenho.
E literalmente amanhã, convidamos todos ao Red Hat Forum Russia 2018 - haverá uma oportunidade de fazer perguntas diretamente aos engenheiros da Red Hat.Outras postagens de cgroups de nossa série Resource Fight estão disponíveis em: