Fotolia

Hot patching (mise à jour à chaud) : Linux est-il devenu meilleur qu'UNIX ?

Dans l’écosystème du Hot Patching, Linux tend à affirmer son positionnement, quitte à détrôner UNIX sur ce sujet. Le point dans cet article.

Il existe un débat permanent : celui de la proximité de Linux et d’UNIX et de ses variantes et quand ce premier pourra-t-il rivaliser avec le second. Mais les temps ont changé, et désormais, il s’agit plutôt de savoir quand UNIX va rattraper Linux en matière de fiabilité, disponibilité et capacité de fonctionnement, comme pourrait l’illustrer les fonctions de migration à chaud (hot patching).

Le hot patching est la capacité de pouvoir appliquer, à chaud, des mises à jour au noyau de l’OS, sans en interrompre le fonctionnement.  Une fonction très recherchée  pour un OS en production.

Recherchée car tant les développeurs que les équipes opérationnelles reconnaissent qu’avoir à éteindre une instance qui supporte des tâches hautement critiques représente au mieux une vraie rupture et au pire un véritable cauchemar. Son niveau de complexité en fait aussi une solution quelque peu insaisissable. Certains projets sont presque parvenus à cette prouesse, mai sont tellement jonchés d’exceptions qu’ils restaient impraticables en production.

Ce qui a changé

Les premières versions d’un hot patching pour Linux sont arrivées il y a quelques années, notamment via la société Ksplice, rachetée depuis par Oracle. Mais le vrai changement est intervenu lorsque Suse a fait de son outil kGraft une solution prête pour la production.

Suse avance certes sur le sujet, mais s’expose également à des problèmes dans le cas de pannes régulières de son outil. Toutefois, comme pour appuyer ses propos, Suse a annoncé lors de l’événement SAPPHIRE en mai dernier que son module de patch à chaud était certifié pour Hana.

La communauté Open Source, qui a démontré sa capacité à innover rapidement sur l’OS, a aussi montré que Linux pouvait désormais distancer UNIX en termes de fonctionnalités. Certaines versions d’UNIX ont le hot patching depuis des années, mais n’ont jamais vraiment mis l’accent dessus, faute de cas d’usage. Ceux qui ne l’ont pas vont désormais devoir rattraper leur retard. Toutefois, l’idée que Linux est une option inférieure est désormais bannie.

La raison est aussi simple qu’elle est inévitable. La communauté des développeurs travaillant sur un UNIX propriétaire est probablement plus réduite que celle contribuant au noyau Linux ou à d’autres projets associés. De plus, les flux de revenus restants pour les systèmes propriétaires ne sont pas suffisants pour rivaliser avec Linux, ce qui nécessite de concentrer les ressources et, parfois, de réduire les budgets.

Oracle a récemment montré des capacités d’accélération hardware de certaines de ses applications et des améliorations en termes de sécurité supportées par les dernières puces de la marque (les Spark).

De son côté, IBM continue d’investir dans AIX, son UNIX propriétaire, et a innové dans la continuité de services (avec une approche différente du hot patching) et dans sa gamme Power8 et la communauté OpenPower.

HPE est quant à lui resté très opaque sur le futur de HP-UX ces derniers temps, ayant déjà perdu une grande partie des parts de marché. Il n’a pas porté HP-UX sur les nouveaux Superdome-X x86. Cela laisse supposer que HPE pourrait abandonner HP-UX sur le long terme pour se centrer sur Linux et Windows.

Patch à chaud : quel est le marché

Si Suse peut se targuer d’avoir franchi la ligne en premier avec  la disponibilité de kGraft, l’écosystème du hot patching est très actif, et propose même plusieurs approches architecturales. En plus de kGraft, Red Hat a développé son outil Kpatch (encore en preview) et Oracle a adapté Ksplice à son propre OS Linux.

Tous ont une approche différente. Suse avec kGraft fonctionne au thread. Cela permet à OS de fonctionner en continu quand on passe de l’ancienne vers la nouvelle version du runtime. Toutefois, cela peut prendre plusieurs minutes car le système continue d’opérer sous l’ancienne version non patchée et passe au nouvel environnement de façon très transparente lorsque le processus de mise à jour est terminé.

Les outils Ksplice et Kpatch d’Oracle et Red Hat respectivement quant à eux stoppent – du moins ce qu’on en dit - l’exécution du noyau entre 10 et 40 millisecondes puis passent la main, d’une version à l’autre. Cette pause peut être insignifiante pour certains systèmes, mais très sensibles pour d’autres.

Le débat, pour faire simple, porte sur le choix entre réaliser la procédure en une seule fois et rapidement -  ce qui peut être risqué si le système effectue de grands volumes de transactions -, et prendre plusieurs minutes pour effectuer  la procédure sans interruption. Il existe également des différences dans le type de patches supportés.

Sur le front UNIX, certains proposent déjà des solutions partielles depuis des années ; d’autres l’ont programmé pour leurs prochaines versions. En 2014, Oracle a placé le hot patching sur la liste des développements futurs. On peut donc imaginer que cela arrive avec les prochaines versions de Solaris.

De son côté, IBM travaille sur les fonctions de la migration à chaud, ainsi que sur leur documentation depuis 2007, mais au regard des travaux en place, il semble qu’il y ait encore trop de limites pour évoquer une fonction prête pour la production.

Dans la dernière version AIX, la 7.2, IBM a inclut une fonction de live update qui semble installer une nouvelle image d’OS sur une autre partition logique pour y transférer tous les process en cours ainsi que leur mémoire. Cette approche semble supprimer toutes les limites liées aux types de patches, mais la documentation indique  toutefois qu’il faille interrompre a minima le système. Finalement, au milieu de toutes ces tentatives, seul Suse est parvenu à créer une fonction viable de migration à chaud qui soit adaptée à la production.

Vers quoi Linux se dirige ?

Avec plusieurs technologies concurrentes, la communauté Linux fait souvent le choix d’embrasser les différents camps. Dans ce processus décalé de coopération et de concurrence, qui est au cœur de la communauté Open Source, les deux camps injectent en amont de la technologie dans le process de développement du noyau. La version 4.0 semble contenir du code lié aux différentes approches.

Il est presque certain que la prochaine version du noyau devrait embarquer une fonction de migration à chaud en standard, jetant la pierre dans le jardin d’UNIX qui devra bien rattraper Linux.

Richard Fichera est vice-président et analyste principal chez Forrester.

Traduit et adapté par la rédaction

Pour approfondir sur Gestion et administration du Datacenter