Como a Meta aplica patches no Linux em larga escala

• Aplicar patches em servidores Linux é simples, mas aplicar patches em dezenas de milhares de servidores sem downtime não é fácil
• A Meta usa o Kpatch da Red Hat e o KLP (Kernel Live Patching) para aplicar patches em milhões de servidores Linux
  • O KLP permite aplicar as atualizações de segurança mais recentes ao kernel do Linux sem reiniciar

Patch ao vivo do kernel

• O patch ao vivo do kernel é fornecido como um pacote separado do pacote principal do kernel, contendo o código corrigido
• Os patches ao vivo são cumulativos, e o patch mais recente inclui todas as correções dos patches anteriores
• Os patches ao vivo não se aplicam a tudo: não é possível aplicar patch em dados ou estruturas, e criar um patch ao vivo exige trabalho adicional de engenharia

Kpatch

• O Kpatch funciona comparando o kernel original com o kernel corrigido e depois aplicando o novo código ao kernel em execução usando um módulo de kernel personalizado
• Em seguida, o processo do Kpatch usa o ftrace para monitorar a pilha dos processos existentes e verificar se o patch pode ser aplicado sem efeitos nocivos
• Se for considerado seguro, ele redireciona o código em execução para a função corrigida e então remove o código que ficou obsoleto
• Com isso, o patch é aplicado ao servidor sem causar downtime

No caso da Meta

• Claro, na prática isso não é tão simples
• Na Meta, ao aplicar um patch ao vivo, normalmente leva de 1 a 2 segundos para aplicar o patch em um host
• Levar 1 a 2 segundos por host é extremamente rápido em comparação com o kexec, o mecanismo do kernel Linux para inicializar um novo kernel
• Não há necessidade de downtime nem de migração de workload; basta aplicar o patch ao vivo e ele já pode ser usado imediatamente

Como aplicar patches em milhões de máquinas

• Ao aplicar patches em milhões de máquinas, isso não é tudo
• Na Meta, como bugs podem ser descobertos durante o rollout do patch, os administradores aplicam primeiro na camada de release candidate
• O package roller, que fornece patches baseados em RPM, também verifica automaticamente a saúde dos servidores
• A Meta monitora falhas, alertas críticos, problemas de aplicação e desempenho no novo kernel, e se a taxa de erro ultrapassar 1 crash a cada 1.000 servidores, o patch é interrompido e o sistema volta ao kernel anterior
• A Meta usa Kpatch, mas existem outras alternativas
  • A SUSE oferece o kGraft, a Oracle usa o Ksplice e a Canonical oferece suporte ao Livepatch
  • Independentemente do código, todas oferecem resultados semelhantes

Opinião do GN⁺

O ponto mais importante deste artigo é que a Meta adotou um método eficiente de aplicação de patches sem downtime para milhões de servidores ao redor do mundo. Esse também é um tema interessante até para engenheiros de software iniciantes e destaca a importância da manutenção e da segurança em sistemas Linux. Além disso, o artigo pode ajudar a entender a complexidade e a necessidade da tecnologia de live patch.

[GN⁺]

Comentários do Hacker News

• Ksplice é a tecnologia original de live patching que, depois de ser adquirida pela Oracle, foi expandida para programas em espaço de usuário durante o período em que trabalhei lá. É uma tecnologia muito legal que não se tornou obsoleta porque, apesar da migração para a nuvem, ainda elimina a necessidade de reiniciar sistemas inteiros em grande escala.
• Parece um detalhe importante que a Meta não mencione quanto tempo leva para aplicar isso em toda a sua implantação. Com live patching, é possível operar sem downtime de servidores, data centers ou nuvens.
• Na escala da Meta, live patching pode fazer sentido, mas a maioria dos serviços e aplicações bem projetados deveria tolerar tranquilamente reinicializações completas dos servidores. É difícil imaginar a complexidade de administrar milhões de servidores.
• KernelCare é um serviço de live patching do kernel que oferece suporte à maioria das distribuições Linux.
• Já usei Kpatch em muitas máquinas virtuais, e ele funciona bastante bem.
• Atualmente, eles operam cerca de 13 milhões de servidores, gastaram US$ 20 bilhões em novos equipamentos de data center em 2023 e pretendem gastar mais US$ 20 bilhões em 2024. No momento, usam CentOS 8 Stream e em breve devem migrar para o 9.
• Dizem que drenar e tirar da drenagem os hosts é difícil. Isso basicamente significa que não é fácil drenar um host do serviço e depois restaurá-lo, o que indica que o kernel Linux não foi projetado para live patching, e tentar fazer isso sempre introduz incerteza, custa caro em termos de trabalho de engenharia e mantém o risco de desastre sempre por perto. Em contrapartida, tornar os sistemas de drenagem e restauração de hosts muito robustos e confiáveis traria enormes ganhos de confiabilidade. Essa abordagem parece encobrir uma disfunção organizacional. Uma equipe pode aplicar patch em todos os kernels, mas é impossível fazer com que todos os hosts suportem drenagem e restauração de serviço, e como não há incentivo real para corrigir isso, ninguém tenta resolver. Só hacks legais e projetos novos são devidamente recompensados.
• A maioria das organizações não ganha nada tentando imitar a Meta, e nem precisa fazer isso.
• É a primeira vez que ouço o conceito de "hiperescala". Fico curioso sobre como isso difere de simplesmente escalar.