Come evitare i tempi di inattività con Linux?

Spesso gli aggiornamenti software a Ubuntu richiedono il riavvio (che può avere effetti collaterali come i tempi di inattività).

Vedo che Ubuntu ha https://www.ubuntu.com/livepatch che consente aggiornamenti del kernel senza riavvii, tuttavia, questo è un servizio a pagamento. C'è anche ksplice .

Esistono distribuzioni / processi Linux in cui aggiornamenti / patch non richiedono mai il riavvio?

(Lo so configurazione dei server ad alta disponibilità (HA) e avere i server monouso sono le migliori pratiche - così sto non chiedendo di mantenere un servizio all'altezza, ma su server attuali.)

Alla tua domanda "Esistono distribuzioni / processi Linux in cui gli aggiornamenti / le patch non richiedono mai il riavvio?", Non ne sono a conoscenza e ne dubito fortemente che ci saranno mai veramente dei veri riavvii. Oltre al commento di Michael Hampton sul perché il live patching non è un'esperienza immediata ovunque, anche il live patching non ottiene lo stesso risultato del riavvio.

Un aneddoto per illustrare questo: recentemente ho studiato un problema in cui una particolare utility aveva iniziato a segfault su un gran numero di macchine. Ho provato a guardare le librerie condivise che vedevano se qualcosa recentemente aggiornato lo aveva rotto; ldd ha detto che non era un eseguibile (anche se quando ho trasferito lo stesso file binario sul mio laptop, ldd ha potuto vedere bene le dipendenze della libreria condivisa). Ho provato a sfogliarlo in gdb; segfault prima ancora di arrivare alla prima istruzione.

Osservando i tempi dell'errore, ho scoperto che recentemente era stata applicata una patch Ksplice. Ho rimosso la patch e il file binario non è stato segfault, quindi l'ho aggiunto di nuovo e ha ricominciato a segfault. Il riavvio sul kernel con patch equivalenti ha funzionato bene. Si è rivelato essere una patch per il supporto a 32 bit che la gente di Ksplice non aveva applicato correttamente. A loro merito, hanno emesso una patch fissa entro poche ore ed è tornato a funzionare correttamente sulla nostra flotta senza intervento.

Un altro esempio: le patch Meltdown / Spectre erano così invasive che il team del kernel Ubuntu decise che il patching dal vivo era poco pratico e richiedeva alle persone di riavviare i loro sistemi nel kernel fisso prima di ricevere nuovamente le patch dal vivo.

Gestiamo una vasta flotta di server fisici e virtuali al lavoro, con un gran numero di sistemi Ksplice e Canonical Livepatch. Entrambi sono stati molto più affidabili di molti altri software, ma preferirei comunque vedere i nostri servizi progettati con un'architettura di riavvio piuttosto che fare affidamento sul patch live del kernel.

Esiste un'importante distinzione tra rendere altamente disponibile un servizio e rendere altamente disponibile una singola macchina.

Nella maggior parte dei casi l'obiettivo è rendere il servizio altamente disponibile e la disponibilità delle singole macchine è solo un mezzo per raggiungere tale obiettivo. Tuttavia, esiste un limite a quanto è possibile raggiungere l'obiettivo migliorando la disponibilità delle singole macchine.

Anche se è possibile eliminare tutti i tempi di inattività dovuti alla necessità di aggiornare il software, le singole macchine non saranno ancora disponibili al 100%. Pertanto, per aumentare la disponibilità del servizio al di sopra della disponibilità delle singole macchine, è necessario progettare la ridondanza a un livello superiore. L'ultima frase della tua domanda mostra che almeno in linea di principio lo sai.

Se si progetta un servizio per essere più disponibile di quello che le singole macchine sono in grado di offrire, non c'è più la pressione per ottenere un'alta disponibilità delle singole macchine. Pertanto, per i servizi a disponibilità elevata non è necessario evitare i riavvii. Invece puoi sacrificare un po 'di affidabilità delle singole macchine per realizzare risparmi che possono essere destinati ad altre aree in cui puoi ottenere guadagni molto più alti in termini di affidabilità.

Una volta che il sistema di alto livello è stato progettato per essere affidabile nel caso in cui singoli componenti hardware non funzionino, il patching live dei kernel cambia da un vantaggio a un rischio.

È un rischio perché possono esserci sottili differenze tra il comportamento di una macchina con patch live e una macchina che è stata avviata con la versione del kernel più recente. Questo può introdurre un bug latente che può causare un'interruzione al successivo riavvio di una macchina. Questo rischio è amplificato dal riavvio per vedere una lavagna pulita come un metodo per mitigare alcune interruzioni.

Un giorno potresti avere un'interruzione in cui pensi che potrebbe essere utile riavviare il computer. Ma al riavvio si viene colpiti dal bug latente che impedisce alla macchina di tornare nello stato desiderato. Il patching in tempo reale non è l'unico modo in cui può verificarsi un bug così latente, potrebbe anche accadere a causa di qualcosa di banale come un servizio che è stato abilitato manualmente e non è mai stato configurato per l'avvio durante l'avvio, o essendo stato configurato per l'avvio troppo presto in modo tale che non riesce a venire a causa di dipendenze insoddisfatte.

Per tali motivi, un servizio a disponibilità elevata potrebbe effettivamente essere più semplice da ottenere con i riavvii regolari dei singoli computer a una velocità sufficientemente bassa da poter rilevare i problemi e mettere in pausa la sequenza dei riavvii quando si verificano problemi.