Guia Abrangente de Cgroups do Systemd para Limitação e Isolamento de Recursos

Guia Abrangente do Systemd Cgroups para Limitação e Isolamento de Recursos

Systemd, o moderno sistema de inicialização e gerenciador de sistema e serviços para Linux, oferece ferramentas poderosas para gerenciar recursos do sistema. Entre suas capacidades mais significativas está a integração com Control Groups (cgroups), um recurso do kernel Linux que permite a limitação, contabilização e isolamento do uso de recursos (CPU, memória, I/O de disco, rede, etc.) para uma coleção de processos. Este guia detalhará como o systemd utiliza cgroups através de seus tipos de unidade — slices, scopes e services — para permitir a limitação precisa de recursos e o isolamento, garantindo que processos críticos recebam os recursos de que necessitam, ao mesmo tempo que impede que aplicações descontroladas impactem a estabilidade do sistema.

Compreender e alavancar a integração de cgroups do systemd é crucial para administradores de sistema, desenvolvedores e qualquer pessoa responsável por manter o desempenho e a confiabilidade dos sistemas Linux. Ao definir limites de recursos apropriados, você pode prevenir a exaustão de recursos, melhorar a previsibilidade do desempenho das aplicações e aumentar a estabilidade geral do sistema. Este guia fornecerá uma abordagem prática para configurar esses limites, tornando o gerenciamento complexo de recursos acessível e eficaz.

Entendendo os Control Groups (cgroups)

Antes de mergulhar na implementação do systemd, é essencial compreender os conceitos fundamentais dos cgroups. Cgroups são um mecanismo hierárquico no kernel Linux que permite agrupar processos e, em seguida, atribuir políticas de gerenciamento de recursos a esses grupos. Essas políticas podem incluir:

• CPU: Limitar o tempo de CPU, priorizar o acesso à CPU.
• Memória: Definir limites de uso de memória, prevenindo condições de falta de memória (OOM).
• I/O: Estrangular (throttling) as operações de leitura/gravação em disco.
• Rede: Limitar a largura de banda da rede.
• Acesso a Dispositivos: Controlar o acesso a dispositivos específicos.

A kernel expõe as configurações de cgroup através de um sistema de arquivos virtual, tipicamente montado em /sys/fs/cgroup. Cada controlador (e.g., cpu, memory) tem seu próprio diretório, e dentro deles, hierarquias de diretórios representam grupos e seus limites de recursos associados.

Arquitetura de Gerenciamento de Cgroups do Systemd

Systemd abstrai a complexidade da manipulação direta de cgroups, fornecendo um sistema estruturado de gerenciamento de unidades. Ele organiza os processos em uma hierarquia de unidades, que são então mapeadas para hierarquias de cgroup. Os principais tipos de unidade relevantes para o gerenciamento de recursos são:

• Slices: Contêineres abstratos para unidades de serviço. Slices formam uma hierarquia, permitindo a delegação de recursos. Por exemplo, um slice para sessões de usuário pode conter slices para aplicações individuais. O Systemd cria automaticamente slices para serviços de sistema, sessões de usuário e máquinas virtuais/contêineres.
• Scopes: Geralmente são usados para grupos de processos temporários ou criados dinamicamente, muitas vezes associados a sessões de usuário ou serviços de sistema que não são gerenciados como unidades de serviço completas. Eles são transitórios e existem enquanto os processos dentro deles estiverem em execução.
• Services: São as unidades fundamentais para gerenciar daemons e aplicações. Quando uma unidade de serviço é iniciada, o systemd coloca seus processos em uma hierarquia de cgroup, geralmente dentro de um slice. Limites de recursos podem ser aplicados diretamente às unidades de serviço.

A hierarquia padrão do Systemd geralmente se parece com isto:

-.slice (Slice Raiz)
  |- system.slice
  |  |- <nome_do_serviço>.service
  |  |- outro-serviço.service
  |  ...
  |- user.slice
  |  |- user-1000.slice
  |  |  |- session-c1.scope
  |  |  |  |- <aplicação>.service (se iniciada pelo usuário)
  |  |  |  ...
  |  |  ...
  |  ... 
  |- machine.slice (para VMs/contêineres)
  ... 

Aplicando Limites de Recursos com Arquivos de Unidade do Systemd

Systemd permite que você especifique limites de recursos de cgroup diretamente nos arquivos de unidade .service, .slice ou .scope. Essas diretivas são colocadas nas seções [Service], [Slice] ou [Scope], respectivamente.

Limites de CPU

As diretivas primárias para controle de recursos da CPU são:

• CPUQuota=: Limita o tempo total de CPU que a unidade pode usar. Isso é especificado como uma porcentagem (e.g., 50% para metade de um núcleo de CPU) ou uma fração de um núcleo de CPU (e.g., 0.5). Também é possível especificar um valor em microssegundos por período. O período padrão é de 100ms.
• CPUShares=: Define um peso relativo para o tempo de CPU. Uma unidade com CPUShares=2048 receberá o dobro do tempo de CPU de uma unidade com CPUShares=1024 quando houver contenção.
• CPUWeight=: Um alias para CPUShares= mas com uma faixa diferente (1-10000, padrão 100).
• CPUQuotaPeriodSec=: Define o período para CPUQuota. O padrão é 100ms.

Exemplo: Limitando um servidor web a 75% de um núcleo de CPU:

Crie ou edite um arquivo de serviço, por exemplo, /etc/systemd/system/mywebapp.service:

[Unit]
Description=Minha Aplicação Web

[Service]
ExecStart=/usr/bin/mywebapp
User=webappuser
Group=webappgroup

# Limita a 75% de um núcleo de CPU
CPUQuota=75%

[Install]
WantedBy=multi-user.target

Após criar ou modificar o arquivo de serviço, recarregue o daemon do systemd e reinicie o serviço:

sudo systemctl daemon-reload
sudo systemctl restart mywebapp.service

Limites de Memória

Os limites de memória são controlados por diretivas como:

• MemoryLimit=: Define um limite rígido para a quantidade de RAM que os processos da unidade podem consumir. Isso pode ser especificado em bytes ou com sufixos como K, M, G, T (e.g., 512M).
• MemoryMax=: Semelhante a MemoryLimit, mas frequentemente considerado mais moderno e flexível na forma como interage com a contabilização de memória. Geralmente é recomendado em vez de MemoryLimit.
• MemoryHigh=: Define um limite suave (soft limit). Quando este limite é atingido, a recuperação de memória (troca/swapping) é acionada de forma mais agressiva, mas o limite rígido ainda não é imposto.
• MemorySwapMax=: Limita a quantidade de espaço de troca (swap) que a unidade pode usar.

Exemplo: Limitando um banco de dados a 2GB de RAM:

Crie ou edite um arquivo de serviço, por exemplo, /etc/systemd/system/mydb.service:

[Unit]
Description=Meu Serviço de Banco de Dados

[Service]
ExecStart=/usr/bin/mydb
User=dbuser
Group=dbgroup

# Limita a memória a 2 Gigabytes
MemoryMax=2G

[Install]
WantedBy=multi-user.target

Recarregue e reinicie:

sudo systemctl daemon-reload
sudo systemctl restart mydb.service

Limites de I/O

O estrangulamento (throttling) de I/O pode ser controlado usando diretivas como:

• IOWeight=: Define um peso relativo para as operações de I/O. Valores mais altos dão mais prioridade de I/O. A faixa é de 1 a 1000 (padrão 500).
• IOReadBandwidthMax=: Limita a largura de banda de I/O de leitura. Especificado como [<dispositivo>] <bytes_por_segundo>. Por exemplo, IOReadBandwidthMax=/dev/sda 100M limita as operações de leitura em /dev/sda a 100MB/s.
• IOWriteBandwidthMax=: Limita a largura de banda de I/O de escrita. Formato semelhante a IOReadBandwidthMax.

Exemplo: Limitando um serviço de processamento em segundo plano a 50MB/s em um disco específico:

Crie ou edite um arquivo de serviço, e.g., /etc/systemd/system/batchproc.service:

[Unit]
Description=Serviço de Processamento em Lote

[Service]
ExecStart=/usr/bin/batchproc
User=batchuser
Group=batchgroup

# Limita as operações de escrita a 50MB/s em /dev/sdb
IOWriteBandwidthMax=/dev/sdb 50M

# Dá-lhe uma prioridade de leitura moderada
IOWeight=200

[Install]
WantedBy=multi-user.target

Recarregue e reinicie:

sudo systemctl daemon-reload
sudo systemctl restart batchproc.service

Gerenciando e Monitorando Cgroups

Systemd fornece ferramentas para inspecionar e gerenciar os cgroups associados às suas unidades.

Inspecionando o Status do Cgroup

O comando systemctl status fornece informações sobre a associação do cgroup de uma unidade e o uso de recursos.

systemctl status mywebapp.service

Procure por linhas que indicam o caminho do cgroup. Por exemplo:

● mywebapp.service - Minha Aplicação Web
     Loaded: loaded (/etc/systemd/system/mywebapp.service; enabled; vendor preset: enabled)
     Active: active (running) since Ter 2023-10-27 10:00:00 UTC; 1 day ago
       Docs: man:mywebapp(8)
   Main PID: 12345 (mywebapp)
      Tasks: 5 (limit: 4915)
     Memory: 15.5M
        CPU: 2h 30m 15s
      CGroup: /system.slice/mywebapp.service
              └─12345 /usr/bin/mywebapp

Você também pode inspecionar diretamente o sistema de arquivos cgroup:

systemd-cgls # Exibe a hierarquia de cgroup gerenciada pelo systemd
systemd-cgtop # Semelhante ao top, mas para cgroups

Para ver os limites específicos aplicados ao cgroup de um serviço:

# Para limites de memória
catsysfs /sys/fs/cgroup/memory/system.slice/mywebapp.service/memory.max

# Para limites de CPU
catsysfs /sys/fs/cgroup/cpu/system.slice/mywebapp.service/cpu.max

(Nota: Os caminhos exatos e nomes de arquivos podem variar ligeiramente dependendo da versão do cgroup e da configuração do sistema.)

Modificando Limites de Cgroup em Tempo de Execução

Embora a prática recomendada seja definir limites em arquivos de unidade, você pode ajustá-los temporariamente usando systemctl set-property:

sudo systemctl set-property mywebapp.service CPUQuota=50%

Essas alterações não são persistentes após a reinicialização. Para torná-las permanentes, atualize o arquivo de unidade e recarregue o daemon do systemd.

Slices para Delegação de Recursos

Slices são poderosos para gerenciar grupos de serviços ou aplicações. Você pode definir limites de recursos em um slice, e todos os serviços ou scopes dentro desse slice herdarão ou serão restritos por esses limites.

Exemplo: Criando um slice dedicado para trabalhos em lote de uso intensivo de recursos:

Crie um arquivo de slice, e.g., /etc/systemd/system/batch.slice:

[Unit]
Description=Slice de Processamento em Lote

[Slice]
# Limita a CPU total para todos os trabalhos neste slice a 1 núcleo
CPUQuota=100%
# Limita a memória total a 4GB
MemoryMax=4G

Agora, você pode configurar serviços para serem executados dentro deste slice usando a diretiva Slice= em seus arquivos de serviço .service:

[Unit]
Description=Trabalho em Lote Específico

[Service]
ExecStart=/usr/bin/mybatchjob

# Coloca este serviço no batch.slice
Slice=batch.slice

[Install]
WantedBy=multi-user.target

Recarregue o systemd, habilite/inicie o slice se necessário (embora ele seja frequentemente ativado implicitamente) e inicie o serviço.

sudo systemctl daemon-reload
sudo systemctl start mybatchjob.service

Esta abordagem permite agrupar processos relacionados e gerenciar seu consumo coletivo de recursos.

Melhores Práticas e Considerações

• Comece com Limites Incrementais: Ao definir limites, comece com valores conservadores e aumente-os gradualmente conforme necessário. Limites agressivos podem desestabilizar aplicações.
• Monitore: Monitore regularmente o uso de recursos do seu sistema e o impacto das suas configurações de cgroup. Ferramentas como systemd-cgtop, htop, top e iotop são inestimáveis.
• Entenda Cgroup v1 vs. v2: Systemd suporta cgroup v1 e v2. Embora muitas diretivas sejam semelhantes, o v2 oferece uma hierarquia unificada e algumas diferenças de comportamento. Certifique-se de estar ciente de qual versão seu sistema está usando se encontrar problemas complexos.
• Priorização vs. Limites Rígidos: Use CPUShares/CPUWeight para priorização quando os recursos são escassos e CPUQuota para limites rígidos estritos. Da mesma forma, MemoryHigh é para limites suaves e MemoryMax para limites rígidos.
• Serviço vs. Slice: Use unidades de serviço para aplicações individuais e slices para gerenciar grupos de aplicações relacionadas ou pools de recursos.
• Documentação: Documente claramente os limites de recursos aplicados aos serviços críticos, especialmente em ambientes de produção.
• OOM Killer: Esteja ciente de que, se um processo exceder seu limite MemoryMax, o matador de Falta de Memória (OOM) do kernel poderá terminá-lo, mesmo que esteja dentro de um cgroup. O Systemd pode gerenciar como o matador OOM se comporta para cgroups específicos usando diretivas como OOMPolicy=.

Conclusão

A integração do Systemd com cgroups fornece um mecanismo robusto e fácil de usar para controlar e isolar recursos do sistema. Ao dominar o uso das unidades de serviço, escopo e slice, os administradores podem aplicar efetivamente limites de CPU, memória e I/O para garantir a estabilidade do sistema, desempenho previsível e prevenir a escassez de recursos. A implementação desses controles é um aspecto fundamental da administração moderna de sistemas Linux, permitindo maior controle sobre seus ambientes de aplicação e a infraestrutura subjacente.