Kernel do Linux 6.x: Novidades relevantes para servidores de alojamento

Classificar corretamente a versão do kernel

A designação «Linux 6.x» agrupa várias versões principais, não um nível de funcionalidades uniforme. Considera-se «mainline» a linha principal mantida por Linus Torvalds: após a janela de fusão, seguem-se normalmente as versões candidatas até à versão principal final. É importante distinguir estas ramificações das ramificações «Stable» e «LTS», que continuam a dar suporte a kernels já publicados com correções selecionadas. Os kernels das distribuições, por sua vez, seguem os seus próprios níveis de pacotes, compromissos de suporte e decisões de integração.

Especialmente no caso dos servidores de alojamento, são Porta-bagagens Fundamental: uma distribuição pode incorporar funcionalidades específicas, melhorias nos controladores ou correções de segurança num kernel mais antigo, que seja mantido a longo prazo. Por outro lado, pode desativar funcionalidades, alterar patches ou limitá-los através da configuração. Por conseguinte, não é possível deduzir, a partir de um número de versão, nem o conjunto completo de funcionalidades nem o impacto operacional concreto.

O comando uname -r Identifica a cadeia de versão atual e constitui um ponto de partida útil para o inventário e a comparação de pacotes. No entanto, não comprova que uma função esteja compilada, ativada em tempo de execução ou acessível a uma aplicação. Mesmo uma nova versão do kernel não substitui a verificação da configuração e da documentação fornecidas pelo distribuidor.

Para uma análise fiável, deve verificar vários níveis: distribuição e estado dos pacotes, configuração do kernel, parâmetros de arranque e interfaces de tempo de execução existentes. A isto acrescentam-se o hardware, o firmware e os controladores, por exemplo, no caso do armazenamento ou da virtualização. Por fim, a aplicação utilizada tem de utilizar efetivamente uma interface; uma função existente no kernel não altera automaticamente um servidor web.

Por isso, este artigo não segue uma cronologia completa das versões. Aborda funcionalidades relevantes para o funcionamento dos atuais kernels da série 6.x. Nem todas estas funcionalidades foram introduzidas pela primeira vez na série 6.x; o que é determinante é o nível de funcionalidades disponível no kernel em questão, as possíveis extensões e os impactos no comportamento da memória, na concorrência da CPU, no isolamento de processos e na manutenção.

Quatro áreas de serviço de alojamento

No que diz respeito aos servidores de alojamento, há quatro áreas operacionais que se destacam: pressão de armazenamento, concorrência de CPU, isolamento adicional de processos e manutenção. Não se trata de ativar o maior número possível de funções do kernel, mas sim de utilizar as ferramentas adequadas para um problema específico. Os pools do PHP-FPM, as bases de dados, as caches, os trabalhos em lote e os workers especializados apresentam requisitos diferentes, que não podem ser determinados apenas a partir da versão do kernel.

cgroup v2 trata-se de um tema transversal, mas não constitui uma novidade da série 6.x. A hierarquia estrutura os recursos de memória e da CPU para serviços, contentores ou grupos de clientes. É necessário verificar, no respetivo ponto de montagem do cgroup-v2, quais os controladores que estão disponíveis e ativados numa subhierarquia. Por isso, um servidor web dedicado requer uma avaliação diferente da de um host de contentores ou de máquinas virtuais.

A tabela separa deliberadamente a configuração de compilação, a ativação de arranque, a interface de tempo de execução e a utilização efetiva. Uma funcionalidade pode estar incluída no kernel, mas estar desativada ou ser irrelevante para a aplicação. Da mesma forma, as distribuições podem portar funcionalidades para versões anteriores. Por isso, avalie as alterações com base no histórico de carga, na estrutura do cgroup, no hardware e nos valores de medição da aplicação, em vez de se basear no número de versão mais elevado disponível.

Pressão de memória e recuperação de páginas

O Linux costuma utilizar a memória livre como cache de ficheiros. Por isso, uma grande quantidade de RAM ocupada não é, por si só, um erro nem um indício de desperdício de memória: as páginas de ficheiros armazenadas em cache podem ser recuperadas quando necessário. Para o diagnóstico, o que conta mais é a evolução e as consequências da carga, tais como tempos de resposta, atividade de swap, registos de erros e interrupções de processos.

A decisão é tomada em função da pressão no reservatório Recuperação de Páginas , quais as páginas que podem ser removidas da cache ou, se for o caso, transferidas para a memória externa. O kernel pode realizar esta tarefa de forma assíncrona através de kswapd executar. Se um processo tiver de recuperar ele próprio as páginas aquando de um pedido de memória, a documentação do kernel refere-se a «recuperação direta»; esta pode afetar o trabalho solicitante e, consequentemente, as latências observadas.

Os sinais de alerta surgem geralmente como uma combinação: a transferência contínua de dados para a memória virtual (swap), os eventos OOM, o aumento dos tempos de espera e os erros ao nível da aplicação devem ser analisados num eixo temporal comum. Por outro lado, um pico pontual pode ser um trabalho em lote planeado. Da mesma forma, um serviço de cache com elevada utilização de RAM não é automaticamente a causa, desde que o seu cgroup e os restantes processos continuem a ter capacidade de resposta suficiente.

O cgroup v2 complementa a visão global com limites de serviço ou de contentor. O controlador de armazenamento disponibiliza contadores de eventos; memory.events é hierárquico, enquanto memory.events.local apresenta apenas os eventos locais do respetivo cgroup. Isto permite distinguir se um problema está relacionado com o limite do próprio serviço ou com a carga numa estrutura superior.

Estes princípios básicos ainda não justificam o ajuste de desempenho. Antes de alterar limites, estratégias de swap ou interfaces do kernel, deve identificar as fontes de carga, a atribuição de cgroups e a correlação temporal. Em particular, um limite de memória muito restritivo pode fazer com que um serviço falhe prematuramente, em vez de resolver o pico de carga subjacente. Só o diagnóstico revela se uma alteração dispõe, de facto, de um parâmetro técnico adequado.

Verificar de forma seletiva o LRU multigeração

O Multi-Gen LRU é uma implementação alternativa para Recuperação de Páginas e é descrito na documentação do kernel aqui abordada, a partir do Linux 6.1. Em situações de escassez de memória, o kernel tem de decidir quais as páginas da cache de ficheiros ou da memória anónima que podem ser recuperadas. Para tal, o Multi-Gen LRU classifica as páginas em gerações com base na idade de acesso e tem em conta os padrões de acesso, de modo a que seja menos provável que as páginas frequentemente necessárias sejam selecionadas para recuperação.

Isto é relevante para um servidor de alojamento web com elevada carga, no qual os pools do PHP-FPM, uma base de dados e um serviço de cache consomem memória RAM em simultâneo. Esta função pode alterar a seleção durante o processo de recuperação de memória, mas não constitui nem uma expansão de memória nem uma garantia de tempos de resposta mais curtos. A carga de trabalho, a capacidade de RAM, a área de troca, o armazenamento em massa e os limites do cgroup dos serviços continuam a determinar se e de que forma se nota algum efeito.

Antes de cada avaliação, deve verificar primeiro se a interface de tempo de execução está presente e é legível. A documentação atual do kernel indica as seguintes opções de configuração para o efeito CONFIG_LRU_GEN e CONFIG_LRU_GEN_ENABLED bem como o caminho em /sys/kernel/mm/lru_gen/. Um kernel de distribuição pode portar versões anteriores de funcionalidades ou configurá-las de outra forma; por isso, o número da versão, por si só, não constitui uma prova fiável.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

Uma saída apenas comprova, numa primeira fase, que a interface sysfs documentada existe e está acessível para leitura. Para determinar o estado de ativação, o valor do bit é relevante: 0x0001 é o interruptor principal do Multi-Gen LRU. Se este bit estiver ausente, o ficheiro pode indicar que o interruptor principal está desativado, apesar de a interface estar disponível; os restantes bits dizem respeito a componentes adicionais. Mesmo que o bit principal esteja definido, isso não constitui uma recomendação geral para alterar o valor na produção.

Por isso, os acessos de escrita ao sysfs não constituem um ajuste padrão. Comece por recolher séries temporais relativas ao Reclaim, ao Swap, às latências e aos eventos do cgroup; em caso de alteração justificada, registe o valor inicial e defina um plano de retorno. Desta forma, será possível verificar se o problema observado sofreu efetivamente alterações ou se apenas foram ajustadas várias variáveis de controlo em simultâneo.

Deve ter especial cuidado quando os limites de memória são reduzidos e os serviços estão sobrecarregados. Um algoritmo de recuperação alterado não corrige conjuntos de workers PHP excessivamente grandes, caches de bases de dados inadequados ou a falta de separação entre clientes concorrentes. A sequência recomendada é a seguinte: determinar a causa e o cgroup afetado, limitar ou distribuir a carga e só depois avaliar uma função disponível do kernel como possível fator de influência.

Identificar com precisão os problemas de memória

A RAM ocupada, por si só, não constitui um erro: o Linux utiliza a memória livre especificamente como cache de ficheiros. É mais provável que seja necessário tomar medidas quando as necessidades em Reclaim direto funcionar, a atividade de swap aumentar, ocorrerem eventos OOM ou as consultas ficarem mais lentas simultaneamente. Recuperação assíncrona através de kswapd funciona em segundo plano; por outro lado, a recuperação direta ocorre no contexto da tarefa que solicita memória e pode atrasar a sua execução.

O ficheiro de eventos memory.events conta os eventos de forma hierárquica, ou seja, incluindo os cgroups subordinados. Para a visualização exclusivamente local, está disponível memory.events.local pronto. high significa redução da potência e recuperação direta após a ultrapassagem de memory.high, enquanto oom uma tentativa de alocação que esteja prestes a falhar devido ao limite do cgroup conta. oom_kill Por outro lado, conta os processos deste cgroup que foram encerrados por qualquer tipo de OOM-Killer.

Comece o diagnóstico com uma identificação clara: que serviço ou contentor pertence ao cgroup em questão, quando ocorreram os eventos e que sinais da aplicação foram registados ao mesmo tempo? Em seguida, compare os contadores locais com os hierárquicos, o registo do sistema, o histórico de swap, bem como as latências HTTP, os tempos de espera da base de dados ou as taxas de erro. No caso de uma situação de OOM, é necessário esclarecer adicionalmente se os dados apontam para um processo relacionado com o cgroup ou para uma possível falta de memória global.

O valor memory.max trata-se de um limite rígido do cgroup e não de uma primeira medida padrão. Um limite mais restrito pode proteger os clientes, mas também pode levar uma aplicação a situações de OOM mais cedo; um limite mais elevado pode agravar a competição por recursos entre serviços vizinhos. Por isso, verifique primeiro o número de workers, os tamanhos das caches, os picos de carga e a estrutura do cgroup. Em seguida, altere apenas um parâmetro justificado, com um período de observação e um plano de reversão.

Compreender o EEVDF e a concorrência entre CPUs

A documentação oficial atual do kernel define o início da transição para EEVDF Linux 6.6. O algoritmo «Earliest Eligible Virtual Deadline First» altera a seleção de tarefas normais, agendadas de forma justa: são tidos em conta o tempo de execução virtual, o atraso como desvio em relação à distribuição ideal e os prazos virtuais. As tarefas elegíveis com o prazo virtual mais cedo podem, assim, receber tempo de CPU em primeiro lugar.

A expressão „transição“ é importante. O EEVDF não substitui a decisão de seleção da classe Fair Scheduling no sentido de que, com isso, desapareçam todas as estruturas de dados, interfaces e conceitos historicamente designados por CFS. Além disso, a documentação atual continua a comparar o EEVDF com o CFS. Por conseguinte, no caso de um kernel de distribuição específico, é necessário verificar o seu estado integrado de patches e funcionalidades, em vez de se basear apenas em 6.6 ou superior, para concluir que o comportamento é totalmente uniforme.

No que diz respeito à hospedagem, esta alteração é especialmente relevante em cargas mistas. As solicitações web, o trabalho com bases de dados e a monitorização competem, por exemplo, com importações, compressão ou cópias de segurança. É possível que haja um perfil de latência diferente entre versões do kernel, mas isso não significa automaticamente um maior débito total. O agendador não resolve problemas como núcleos constantemente sobrecarregados, processos bloqueados, tempos de espera de E/S e configurações de aplicações inadequadas.

A separação operacional continua a ser feita com base nos limites dos serviços e das plataformas. Os pesos da CPU influenciam a distribuição relativa em caso de concorrência, enquanto as quotas podem limitar o tempo de computação disponível. Se for necessário separar de forma fiável cargas web sensíveis à latência de trabalhos em lote de grande dimensão, poderá também ser adequado utilizar uma VM própria ou um host separado. O EEVDF substitui estas Planeamento de recursos não.

Antes de consultar cgroup.controllers tens de verificar se o cgroup v2 está montado e, em caso afirmativo, onde. O procedimento de leitura a seguir procura o ponto de montagem do cgroup v2, em vez do caminho habitual /sys/fs/cgroup presumir. Num sistema exclusivamente cgroup-v1, a variável permanece vazia; numa hierarquia híbrida, indica apenas a montagem v2 encontrada.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r refere-se apenas à cadeia de versão atual. cgroup.controllers enumera os controladores que estão disponíveis para ativação precisamente neste cgroup; não confirma, no entanto, que tenham sido ativados nas sub-hierarquias relevantes. Para isso, entre outros, existe cgroup.subtree_control verificar nos respetivos níveis hierárquicos. Os controladores são autorizados de cima para baixo, pelo que um cgroup filho só pode transmitir os controladores disponibilizados pelo nó pai.

systemd-cgtop também fornece apenas um instantâneo e não constitui uma análise das causas. Recolha dados sobre a utilização da CPU por grupo de serviços, as latências das solicitações, os tempos de execução dos trabalhos em lote e, se for o caso, os tempos de espera de E/S ao longo de várias fases de carga comparáveis. Se os atrasos ocorrerem apenas durante um backup, o seu intervalo de tempo, a carga na CPU ou a quota são, na maioria das vezes, pontos de ajuste iniciais mais concretos do que um suposto ajuste do agendador.

Landlock para profissionais especializados

O Landlock foi introduzido pela primeira vez com o Linux 5.13 e, por isso, não é uma inovação original da série 6.x. Nos kernels 6.x, estão disponíveis diferentes níveis avançados de ABI, dependendo da versão e do kernel da distribuição. Esta funcionalidade constitui um mecanismo de segurança complementar, através do qual um processo pode auto-restringir-se ainda mais.

Enquanto módulo de segurança Linux empilhável, o Landlock atua em complemento às decisões de acesso já em vigor; não substitui nem os direitos de ficheiro do Unix, nem o SELinux, o AppArmor, os namespaces ou os contentores. As regras podem, entre outras coisas, limitar o acesso ao sistema de ficheiros e são transmitidas aos processos filhos iniciados posteriormente. O conjunto de funcionalidades práticas depende da ABI disponível e da configuração do kernel.

O que faz sentido é Sem saída para o mar sobretudo para processos individuais desenvolvidos internamente ou selecionados de forma específica. Um conversor para uploads de clientes poderia ler ficheiros apenas a partir de uma pasta de entrada e gravar os resultados exclusivamente numa pasta de saída. Mesmo que o serviço seja processado de forma incorreta, não deve ser capaz de ler chaves SSH, segredos de aplicações ou caminhos gerais do sistema. Esta restrição complementa uma atribuição cuidadosa de direitos, não a torna supérflua.

Uma regra produtiva não deve basear-se exclusivamente num kernel atual. O Landlock possui versões ABI; uma aplicação deve consultar a ABI disponível em tempo de execução e solicitar apenas direitos de acesso ou funções que essa ABI suporte. Desta forma, pode funcionar de forma escalonada em sistemas mais antigos, em vez de deixar de funcionar completamente devido a uma interface indisponível.

À parte disso, estabelece handled_access_fs define explicitamente quais os acessos ao sistema de ficheiros que um conjunto de regras trata e que, na ausência de uma regra adequada, são recusados por predefinição. Este acordo explícito entre a aplicação e o kernel impede que uma sandbox se torne mais restritiva sem que se perceba, apenas devido a uma atualização do sistema, e que, consequentemente, provoque falhas nas aplicações. A consulta à ABI e os direitos tratados explicitamente estão, portanto, interligados, mas resolvem tarefas de compatibilidade diferentes.

Para o conversor de ficheiros, isto traduz-se numa implementação gradual: determinar os diretórios de leitura, escrita e de trabalho necessários com base no fluxo de trabalho efetivo, ter em conta os caminhos de erro e testar inicialmente no ambiente de teste. Uma política de exemplo sucinta não constituiria uma receita de produção fiável, uma vez que ficheiros temporários, bibliotecas externas e programas auxiliares iniciados podem necessitar de acessos adicionais. Medidas adicionais para o isolamento de serviços são também abordadas no artigo sobre Reforço do kernel para servidores de alojamento.

É necessário ter especial cuidado em OverlayFS. As regras para uma camada de overlay não restringem automaticamente a hierarquia de montagens consolidada e vice-versa. Por isso, os ambientes de contentores e de compilação com overlays requerem uma verificação específica das ligações concretas e dos caminhos de acesso. O Landlock constitui, neste contexto, uma camada adicional possível, mas não uma separação generalizada entre clientes nem um substituto para um conceito viável de contentores ou de autorizações.

DAMON apenas para casos especiais

O DAMON e os mecanismos de recuperação que se baseiam nele não podem ser classificados de forma generalizada como funcionalidades introduzidas pela primeira vez com o Linux 6.x. Para os administradores, o que importa é o estado funcional do kernel 6.x ou da distribuição concretamente utilizada. O DAMON monitoriza os acessos à memória com o objetivo de poder classificar as áreas de acordo com o seu comportamento de utilização.

Partindo dessa base, procura-se DAMON_RECLAIM, recuperar de forma proativa a memória que não é utilizada há muito tempo, mediante uma ligeira pressão. Este procedimento complementa a recuperação normal baseada no LRU; não se destina a substituí-la. A documentação do kernel atribui-o a sistemas de memória geralmente sobrecarregados e cita como exemplo a virtualização baseada no relatório de páginas livres.

Neste cenário de virtualização, o nível é determinante: os convidados comunicam ao anfitrião as páginas de memória livres, que o anfitrião pode atribuir a outros convidados. Se um convidado comunicar pouca memória livre, apesar de manter páginas que não são utilizadas há muito tempo, a recuperação proativa como convidado contribuir para que sejam comunicadas mais páginas livres ao anfitrião. Assim, o DAMON_RECLAIM não constitui, sem uma verificação adicional, uma solução do lado do anfitrião para a memória RAM não utilizada pelos convidados.

Por isso, não se trata de uma medida padrão para um único servidor Web ou de base de dados. Mesmo em ambientes virtualizados, é necessário esclarecer, em primeiro lugar, em que nível a pressão surge e se a causa é, de facto, a existência de áreas há muito sem utilização. Estrangulamentos da CPU, armazenamento lento, limites de cgroup inadequados ou caches de aplicações ativos podem explicar os mesmos sintomas, sem que a recuperação proativa seja a resposta adequada.

As quotas, os limites de idade e os marcadores de água determinam quando e em que medida o DAMON_RECLAIM funciona. Não se trata de valores padrão transferíveis: uma seleção demasiado agressiva pode substituir prematuramente a cache de ficheiros útil ou páginas de memória necessárias de forma recorrente. Isto pode desencadear operações de E/S adicionais e consumir tempo de CPU para um novo processamento, apesar de a memória nominalmente livre aumentar.

Uma decisão fundamentada exige, por isso, medições com parâmetros de comparação claros, tais como a memória livre declarada pelo utilizador, a atividade de recuperação, o comportamento da troca de memória, a latência de armazenamento e os tempos de resposta das aplicações. Teste primeiro as alterações num ambiente de teste comparável, defina um plano de reversão e observe-as durante fases de carga representativas. Se estas condições não estiverem reunidas ou se a causa da pressão sobre o armazenamento não estiver esclarecida, o DAMON permanecerá deliberadamente desativado.

Atualizações, correções em tempo real e reinícios

A manutenção do kernel começa com a verificação da correspondência entre o aviso de segurança, o pacote instalado e o kernel que está efetivamente a ser executado. Em seguida, verifique nas instruções da sua própria distribuição qual a correção prevista para essa ramificação específica do kernel e se é necessária uma reinicialização. Um número de versão 6.x mais elevado, por si só, não comprova nem a existência do patch nem a disponibilidade de um livepatch adequado; as correções de segurança também podem ser portadas para kernels de distribuições mais antigas.

Também Aplicação de correções em tempo real não foi introduzido como conceito apenas com o Linux 6.x. A infraestrutura relevante para os kernels 6.x permite aplicar determinadas alterações ao kernel em tempo de execução. Os «livepatches» cumulativos podem, neste contexto, substituir um patch mais antigo por um mais recente de forma atómica. Os limites documentados dizem respeito, entre outros aspetos, a alterações de estado, callbacks e à reversão entre patches.

Para saber se existe um Livepatch adequado para um kernel de distribuição específico, é necessário verificar a oferta correspondente e as autorizações do fornecedor. A infraestrutura geral do kernel não implica que todas as correções de segurança estejam disponíveis em tempo real, nem que um patch aplicado substitua de forma permanente uma atualização completa do kernel. Por isso, continue a planear janelas de manutenção regulares.

Avalia primeiro a urgência e o impacto de uma atualização, compara depois o estado dos pacotes e o kernel em execução e verifica a proposta concreta do Livepatch. Após uma atualização regular do kernel com reinício, verifique se o kernel esperado está ativo e se os serviços críticos, os caminhos de rede, as cópias de segurança e a monitorização estão a funcionar corretamente. Esta verificação faz parte do processo de manutenção e não deve ser confundida com a mera acessibilidade do servidor.

A reinício previsto pode continuar a ser necessário, apesar do Livepatching. As alterações aos parâmetros de arranque do kernel só entram em vigor, normalmente, no arranque seguinte. No caso dos controladores, do firmware dos dispositivos e do hardware, o procedimento depende, por outro lado, do componente, da sua integração e do processo do fabricante: em alguns casos, basta reiniciar um módulo, um dispositivo ou um serviço; noutros, é necessária uma reinicialização completa do anfitrião.

O artigo complementar sobre Aplicação de patches em tempo real em servidores AlmaLinux Aborda uma implementação concreta dependente da distribuição. Não transfira esses procedimentos para outros ramos do kernel ou fornecedores sem os verificar previamente. São determinantes os pacotes, as versões do kernel suportadas e as instruções de funcionamento da plataforma efetivamente utilizada.

• Não alterar nada deliberadamente, se a avaria observada ainda não tiver uma causa identificável.
• Não planear a aplicação de um Livepatch nem a alteração do kernel sem uma verificação adequada no ambiente de teste e sem um plano de reversão documentado.
• Não ativar nenhuma funcionalidade se a aplicação ou plataforma em questão não utilizar a respetiva interface.
• Não se deve substituir a ausência de uma janela de manutenção pela suposição de que o «livepatching» abrange todas as atualizações do kernel.