Como evitar o tempo de inatividade com o linux?

As atualizações de software frequentemente para o Ubuntu requerem reinicializações (que podem ter efeitos colaterais, como tempo de inatividade).

Vejo que o Ubuntu possui https://www.ubuntu.com/livepatch, que permite atualizações do kernel sem reinicializações, no entanto, este é um serviço pago. Há também o ksplice .

Existem distribuições / processos Linux em que atualizações / patches nunca exigem reinicializações?

(Eu sei que configurar servidores de alta disponibilidade (HA) e ter servidores descartáveis ​​são práticas recomendadas - por isso não estou perguntando sobre como manter um serviço, mas em servidores reais).

Para sua pergunta, "Existem distribuições / processos Linux em que as atualizações / patches nunca exigem reinicializações?", Não conheço nenhuma e tenho muita dúvida de que existirá alguma que seja verdadeiramente livre de reinicialização. Além do comentário de Michael Hampton sobre por que o patch ao vivo não é uma experiência pronta para uso em qualquer lugar, o patch ao vivo também não alcança o mesmo resultado que a reinicialização.

Uma anedota para ilustrar isso: investiguei recentemente um problema em que um utilitário em particular havia iniciado o segfault em um grande número de máquinas. Tentei examinar as bibliotecas compartilhadas, que costumavam ver se alguma coisa atualizada recentemente havia quebrado; O ldd disse que não era um executável (mesmo quando eu puxei o mesmo binário para o meu laptop, o ldd podia ver as dependências da biblioteca compartilhada muito bem). Eu tentei percorrê-lo em gdb; ele falhou antes mesmo de chegar à primeira instrução.

Observando o momento da falha, descobri que um patch do Ksplice havia sido aplicado recentemente. Fiz o backup do patch e o binário não foi executado novamente, em seguida, adicionei-o novamente e ele começou a ser executado novamente. A reinicialização no kernel com correção equivalente funcionou bem. Acabou sendo um patch para suporte de 32 bits que o pessoal do Ksplice não havia aplicado corretamente. Para seu crédito, eles emitiram um patch fixo em poucas horas e voltaram a funcionar corretamente em nossa frota sem intervenção.

Outro exemplo: os patches Meltdown / Spectre foram tão invasivos que a equipe do kernel do Ubuntu decidiu que o patch ao vivo era impraticável e exigia que as pessoas reinicializassem seus sistemas no kernel fixo antes de receber os patches ao vivo novamente.

Operamos uma grande frota de servidores físicos e virtuais em funcionamento, com um grande número de sistemas Ksplice e Canonical Livepatch. Ambos têm sido muito mais confiáveis ​​do que muitos outros softwares, mas eu ainda prefiro ver nossos serviços projetados com uma arquitetura amigável à reinicialização do que confiar nos patches ativos do kernel.

Há uma distinção importante entre tornar um serviço altamente disponível e tornar uma máquina individual altamente disponível.

Na maioria dos casos, o objetivo é tornar o serviço altamente disponível, e a disponibilidade de máquinas individuais é apenas um meio para atingir esse objetivo. No entanto, há um limite de quão longe você pode alcançar, melhorando a disponibilidade de máquinas individuais.

Mesmo se você pudesse tirar todo o tempo de inatividade devido à necessidade de atualizar o software, as máquinas individuais ainda não estarão 100% disponíveis. Assim, para aumentar a disponibilidade do serviço acima da disponibilidade de máquinas individuais, é necessário projetar redundância em um nível superior. A última frase da sua pergunta mostra que pelo menos em princípio você sabe disso.

Se você projetar um serviço para estar mais disponível do que as máquinas individuais podem oferecer, não haverá mais pressão para obter alta disponibilidade de máquinas individuais. Portanto, para serviços altamente disponíveis, não há necessidade de evitar reinicializações. Em vez disso, você pode sacrificar alguma confiabilidade de máquinas individuais para economizar, o que pode ser aplicado em outras áreas nas quais você pode obter ganhos muito maiores em confiabilidade.

Uma vez que o sistema de alto nível foi projetado para ser confiável no caso de componentes individuais de hardware falharem, o patch ativo dos kernels muda de uma vantagem para se tornar um risco.

É um risco, pois pode haver diferenças sutis entre o comportamento de uma máquina que foi corrigida ao vivo e uma máquina que foi inicializada com a versão mais recente do kernel. Isso pode introduzir um bug latente que pode causar uma interrupção na próxima vez que uma máquina for reiniciada. Esse risco é amplificado pela reinicialização para que uma lista limpa seja vista como um método para mitigar algumas interrupções.

Um dia você pode ter uma interrupção na qual acha que reiniciar a máquina pode ajudar. Mas, quando você reinicia, é atingido pelo bug latente, impedindo que a máquina volte ao estado desejado. A aplicação de patches ao vivo não é a única maneira de ocorrer um bug latente, mas também porque algo tão comum como um serviço foi ativado manualmente e nunca configurado para iniciar durante a inicialização ou configurado para iniciar muito cedo, de modo que falha ao surgir devido a dependências não satisfeitas.

Por esses motivos, um serviço altamente disponível pode ser mais fácil de obter com reinicializações regulares de máquinas individuais a uma taxa lenta o suficiente para detectar problemas e pausar a sequência de reinicializações assim que ocorrerem problemas.