De 4 Horas para 3 Minutos Como Corrigimos o Tempo de Boot com UEFI e iPXE

Quando você gerencia uma frota de servidores bare-metal, cada minuto de boot importa. Mas o que acontece quando uma atualização de firmware rotineira transforma um boot de 3 minutos em uma saga de 4 horas? Foi exatamente isso que aconteceu nos data centers centrais da Cloudflare, e a história de como corrigimos é uma aula sobre internals de UEFI, protocolos de boot de rede e automação.

Neste mergulho profundo, vou te guiar pelos sintomas, a causa raiz e a solução passo a passo que implementamos. Você vai aprender por que uma busca linear por interfaces de boot pode paralisar sua infraestrutura, e como uma ordem de boot declarativa combinada com scripts iPXE pode economizar horas.

O Culpado Oculto: Uma Busca Linear pela Interface de Boot Certa

Nossos servidores normalmente usam iPXE, um firmware de boot de rede open-source, para inicializar seus sistemas operacionais. iPXE é ótimo porque suporta HTTP/HTTPS, tornando o processo mais rápido e confiável que o PXE tradicional. Porém, após uma atualização de firmware, alguns servidores começaram a demorar horas para bootar.

Abrimos o console serial e assistimos a um ciclo de boot em tempo real. O POST do firmware completou normalmente, mas então o servidor ficou esperando. O console revelou o problema: ele tentava um boot HTTPS IPv4 (timeout), depois iPXE IPv4 (timeout), repetindo esses, e finalmente alcançava o boot HTTPS IPv6 que funcionava. Cada timeout queimava cerca de 5 minutos, e com quatro tentativas, são 20 minutos por boot. Para atualizações de firmware que exigem múltiplos reboots, isso se acumulou para quase 4 horas.

A Solução: Declare sua Interface de Boot, Não Busque por Ela

A causa raiz era clara: o servidor estava cegamente sondando todas as interfaces de boot disponíveis. A solução? Declare a ordem de boot correta desde o início, para que o sistema nunca perca tempo com interfaces que não responderão.

Mas implementar isso foi complicado. Enfrentamos três obstáculos:

1. Suporte Legado e Persistência: A ordenação de boot não é suportada em versões antigas de UEFI, e as configurações são redefinidas após uma atualização de firmware.
2. Bloqueio do Fornecedor: O UEFI tinha uma configuração imutável (Force Priority Httpv4 Httpv6 Pxev4 Pxev6) que impedia mudanças. Precisamos de uma nova versão de BIOS.
3. Inconsistência de Strings: Diferentes fornecedores de NIC usavam strings diferentes (ex.: HTTPS IPv4 Ethernet Network Adapter XXX-XXX-Y for OCP 3.0 P1 vs. HTTPS IPv4 Network Adapter - 50:00:E6:8F:4F:32 P1).

Para contornar o problema de strings, adicionamos correspondência com curingas à nossa ferramenta CfHIIConfig_App, usando padrões como .*HTTP.*IPv4.*P1. Também implementamos um flag booleano (uefi-same-hex) para evitar imprimir e comparar variáveis, reduzindo ainda mais o tempo de boot.

Aqui está um trecho do script iPXE que verifica mudanças e dispara um reboot se necessário:

# constrói o caminho para ler a variável de atualização
set buffer-var-guid 91468514-75bc-4bb5-8f33-91efff9e9b1f
set var-upd-path efivar/CfHIIVarUpd-${buffer-var-guid}

# Executa o comando de mudança de configuração
imgexecset ${uefi-setting}=${uefi-value}

# Compara a variável de atualização com o valor esperado
# Se mudou, define a variável local para reiniciar o sistema
iseq ${uefi-same-hex} ${${var-upd-path}} || set has-changed ${uefi-diff-hex}

Esse script agora faz parte da nossa automação de boot, garantindo que após qualquer atualização de firmware, a ordem de boot seja validada e reaplicada se necessário.

Os Resultados: Um Sistema de Boot Dinâmico e Autocurável

Ao eliminar a adivinhação, transformamos uma saga de 4 horas em um processo de 3 minutos. Veja o impacto:

Mas isso não foi só sobre velocidade. Tornou nosso sistema mais dinâmico e resiliente. Agora usamos uma única imagem de BIOS para todos os SKUs, implantamos atualizações de configuração em escala através do nosso pipeline de release, e todo o fluxo de trabalho roda a partir do iPXE sem interações manuais de BIOS.

Limitações e Considerações

Embora essa solução funcione maravilhas para nossa frota, não é isenta de ressalvas:

• Dependência do Fornecedor: Tivemos que trabalhar em estreita colaboração com os OEMs para liberar o controle da ordem de boot, o que pode não ser possível com todo hardware.
• Complexidade: Implementar correspondência curinga e validação de estado adiciona complexidade aos seus scripts de automação.
• Não é uma Bala de Prata: Se o problema de tempo de boot vem de latência de rede ou má configuração de DHCP, isso não vai ajudar.

Próximos Passos para sua Infraestrutura

Se você gerencia servidores bare-metal e enfrenta problemas semelhantes de tempo de boot, aqui está o que recomendo:

1. Audite sua sequência de boot — Use logs do console serial para identificar padrões de timeout.
2. Declare sua ordem de boot — Trabalhe com seu fornecedor para habilitar controle programático.
3. Automatize a validação — Implemente uma verificação de estado para reaplicar a configuração após atualizações de firmware.

Para um mergulho mais profundo em iPXE e automação de boot de rede, confira a documentação oficial do iPXE. E se você se interessa em como a Vercel lida com desafios de infraestrutura semelhantes com microfrontends, cobrimos as atualizações de roteamento da Vercel e feature flags JSON em outros posts.

Concluindo

Nossa jornada de boots de 4 horas para 3 minutos foi um mergulho profundo nos internals de UEFI, colaboração com fornecedores e ferramentas open-source como iPXE. Isso nos ensinou que às vezes as maiores vitórias de performance vêm de eliminar trabalho desnecessário—como uma busca linear por todas as interfaces de boot possíveis.

Se você enfrenta desafios semelhantes, lembre-se: não aceite boots lentos. Investigue a causa raiz, declare suas interfaces de boot e automatize a validação. Sua infraestrutura agradecerá.

Para mais insights sobre otimização do seu fluxo de trabalho de dev, confira nossos posts relacionados sobre roteamento de microfrontends da Vercel e feature flags baseadas em JSON. Feliz boot!