Comment éviter les temps d'arrêt avec Linux?

Les mises à jour logicielles d'Ubuntu nécessitent fréquemment des redémarrages (ce qui peut avoir des effets secondaires tels que des temps d'arrêt).

Je vois qu'Ubuntu a https://www.ubuntu.com/livepatch qui permet des mises à jour du noyau sans redémarrage, cependant, c'est un service payant. Il y a aussi ksplice .

Existe-t-il des distributions / processus Linux où les mises à niveau / correctifs ne nécessitent jamais de redémarrage?

(Je sais que la mise en place de serveurs à haute disponibilité (HA) et l'utilisation de serveurs jetables sont les meilleures pratiques - donc je ne demande pas de maintenir un service, mais sur des serveurs réels.)

À votre question, "Existe-t-il des distributions / processus Linux où les mises à niveau / correctifs ne nécessitent jamais de redémarrage?", Je n'en connais aucun et je doute fortement qu'il y en ait jamais qui soient vraiment sans redémarrage. En plus du commentaire de Michael Hampton sur la raison pour laquelle le patch en direct n'est pas une expérience prête à l'emploi, le patch en direct n'atteint pas le même résultat que le redémarrage.

Une anecdote pour illustrer cela: j'ai récemment enquêté sur un problème où un utilitaire particulier avait commencé à se briser sur un grand nombre de machines. J'ai essayé de regarder les bibliothèques partagées qu'il utilisait pour voir si quelque chose récemment mis à jour l'avait cassé; ldd a dit que ce n'était pas un exécutable (même si quand j'ai tiré le même binaire sur mon ordinateur portable, ldd pouvait voir très bien les dépendances de la bibliothèque partagée). J'ai essayé de le parcourir dans gdb; il a subi une défaillance avant même d'avoir atteint la première instruction.

En regardant le moment de la panne, j'ai constaté qu'un correctif Ksplice avait été récemment appliqué. J'ai annulé le correctif et le binaire n'a pas commis de défaut, puis je l'ai rajouté, et il a recommencé le défaut de segmentation. Le redémarrage sur un noyau à correctifs équivalents a bien fonctionné. Il s'est avéré être un patch pour le support 32 bits que les gens de Ksplice n'avaient pas appliqué correctement. À leur crédit, ils ont émis un patch fixe en quelques heures et il a recommencé à fonctionner correctement sur notre flotte sans intervention.

Autre exemple: les correctifs Meltdown / Spectre étaient si envahissants que l'équipe du noyau Ubuntu a décidé que les correctifs en direct n'étaient pas pratiques et exigeait que les gens redémarrent leurs systèmes dans le noyau fixe avant de recevoir à nouveau les correctifs en direct.

Nous gérons une grande flotte de serveurs physiques et virtuels au travail, avec un grand nombre de systèmes Ksplice et Canonical Livepatch. Ils ont tous deux été beaucoup plus fiables que de nombreux autres logiciels, mais je préférerais toujours que nos services soient conçus avec une architecture conviviale au redémarrage plutôt que de s'appuyer sur les correctifs en direct du noyau.

Il existe une distinction importante entre rendre un service hautement disponible et rendre une machine individuelle hautement disponible.

Dans la plupart des cas, l'objectif est de rendre le service hautement disponible, et la disponibilité des machines individuelles n'est qu'un moyen d'atteindre cet objectif. Cependant, il existe une limite dans la mesure dans laquelle vous pouvez atteindre l'objectif en améliorant la disponibilité des machines individuelles.

Même si vous pouviez supprimer tous les temps d'arrêt en raison de la nécessité de mettre à jour le logiciel, les machines individuelles ne seront toujours pas disponibles à 100%. Ainsi, pour augmenter la disponibilité du service au-dessus de la disponibilité des machines individuelles, vous devez concevoir la redondance à un niveau supérieur. La dernière phrase de votre question montre qu'au moins en principe vous le savez.

Si vous concevez un service pour qu'il soit plus disponible que les machines individuelles ne peuvent le fournir, il n'y a plus de pression pour atteindre une haute disponibilité des machines individuelles. Ainsi, pour les services hautement disponibles, il n'est pas nécessaire d'éviter les redémarrages. Au lieu de cela, vous pouvez sacrifier une certaine fiabilité des machines individuelles pour faire des économies qui peuvent être mises dans d'autres domaines où vous pouvez obtenir des gains de fiabilité beaucoup plus élevés.

Une fois que le système de haut niveau est conçu pour être fiable en cas de défaillance de composants matériels individuels, la correction en direct des noyaux passe d'un avantage à un risque.

C'est un risque car il peut y avoir de subtiles différences entre le comportement d'une machine qui a été corrigée en direct et une machine qui a été démarrée avec la dernière version du noyau. Cela peut introduire un bogue latent qui peut provoquer une panne au prochain redémarrage d'une machine. Ce risque est amplifié par le redémarrage pour obtenir une table rase vue comme une méthode pour atténuer certaines pannes.

Un jour, vous pourriez avoir une panne où vous pensez que le redémarrage de la machine pourrait aider. Mais lorsque vous redémarrez, vous êtes touché par le bug latent empêchant la machine de revenir dans l'état souhaité. Le patching en direct n'est pas le seul moyen pour qu'un tel bug latent puisse se produire, il pourrait aussi bien se produire en raison de quelque chose d'aussi banal qu'un service ayant été activé manuellement et jamais configuré pour démarrer au démarrage, ou ayant été configuré pour démarrer trop tôt de sorte qu'il ne se présente pas en raison de dépendances non satisfaites.

Pour ces raisons, un service hautement disponible peut être plus facile à réaliser avec des redémarrages réguliers de machines individuelles à un rythme suffisamment lent pour que vous puissiez détecter les problèmes et suspendre la séquence de redémarrages une fois que les problèmes surviennent.