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


13

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.)


1
Un serveur restreint fonctionnerait-il comme une machine qui n'a jamais besoin d'être redémarrée? Après tout, si personne ne peut y accéder, vous n'avez jamais besoin de le redémarrer? ;) - Par exemple, un serveur de surveillance sur une centrale nucléaire, qui sonne simplement une alarme si quelque chose ne va pas. (Oui, je sais que ce serait probablement un système dédié plutôt qu'un serveur aléatoire, mais j'utilise l'exemple juste pour faire valoir qu'il y a des occasions où le redémarrage pour des `` mises à jour de sécurité '' peut être une idée tout à fait fastidieuse.
djsmiley2k TMW

3
@ djsmiley2k C'est l'un de ces cas où une machine que vous ne redémarrez jamais ne vous offre pas une disponibilité suffisante. Au lieu de cela, vous avez besoin de redondance.
kasperd

@kasperd ok, donc un cluster de machines jamais redémarrées?
djsmiley2k TMW

3
@ djsmiley2k Ma réponse à la question explique déjà pourquoi je considère qu'un cluster de machines qui sont redémarrées une à la fois est plus fiable que celles que vous ne redémarrez jamais.
kasperd

2
Qu'est-ce qui vous fait penser qu'il est préférable d'éviter les temps d'arrêt individuels du système?
warren

Réponses:


12

À 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.


30

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.


J'ai aimé votre description du risque; "patched vs booted with the latest kernel" .. Cependant, vous n'avez pas répondu à ma question .. que je pourrais reformuler, y a-t-il des distributions Linux qui sont livrées avec 'livepatch' prêt à l'emploi?
user75126

@ user75126 Je le vois comme une fonctionnalité plus appropriée pour les machines clientes que pour les serveurs. De plus, demander quelles distributions prennent en charge sonne comme une question de recommandation de produit. Pour moi, cela ressemble à deux raisons pour lesquelles reformuler la question comme ça le rendrait hors sujet pour ce site.
kasperd

3
@ user75126 Ksplice d'Oracle propose un essai gratuit et un niveau gratuit pour les bureaux Ubuntu et Fedora (uniquement, mais ils ne l'appliquent pas vraiment). Le problème est que la création des patchs en direct est difficile à automatiser, et même les pièces qui peuvent être automatisées prennent également beaucoup de temps. La création de ces correctifs est une opération relativement laborieuse, et il est raisonnable pour les entreprises de facturer cela. J'ai regardé ce qu'il faudrait pour créer les patchs en direct moi-même, et je suis sorti de là. Je n'ai pas ce genre de temps dans ma journée.
Michael Hampton

12
@ user75126 C'est vraiment une mauvaise pratique sur ce site de changer le titre et le corps de la question d'une manière qui invalide une réponse existante. Si vous vouliez poser une question différente, posez une autre question.
Greg Schmit

2
@ user75126 Merci. J'ai lu votre question et je ne pensais pas que c'était vraiment une réponse. Je commentais simplement pourquoi c'est un service payant.
Michael Hampton
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.