10. Comprendre les deux noyaux Oracle Linux “UEK” et “RHCK”

Oracle Linux dispose de deux noyaux : le noyau compatible Red Hat (RHCK), qui est un noyau compatible avec RHEL, et le propre noyau d’Oracle Linux, le noyau d’entreprise incassable (UEK).

Si vous n’avez jamais utilisé Oracle Linux auparavant, vous pourriez être préoccupé par le noyau d’entreprise incassable. Dans cet article, nous expliquerons le noyau d’entreprise incassable, ainsi que sa compatibilité et les critères pour déterminer quand l’utiliser.

Noyau compatible Red Hat et noyau d’entreprise incassable

En guise d’introduction de base, nous fournirons un aperçu du noyau compatible Red Hat et du noyau d’entreprise incassable.

Qu’est-ce que le noyau compatible Red Hat ?

Comme son nom l’indique, le noyau compatible Red Hat (RHCK) est un noyau compatible avec RHEL qui est simplement une version recompilée du code source du noyau RHEL. Étant donné qu’il s’agit simplement d’une version recompilée, il se comportera de la même manière que RHEL, y compris les bogues, tant que le numéro de version est le même.

Le tableau suivant montre les versions de RHCK et de glibc pour chaque version majeure d’Oracle Linux. Pour souligner la compatibilité au sein de la même version majeure de Linux, les versions de base des composants importants tels que le noyau et glibc ne changeront pas. Au lieu de cela, lorsqu’il y a une mise à jour, le numéro de version sera modifié comme décrit ci-dessous.

Version de Linux	Version RHCK	Version glibc
Oracle Linux 9	5.14.0	2.34
Oracle Linux 8	4.18.0	2.28
Oracle Linux 7	3.10.0	2.17

Le diagramme suivant montre les noms des paquets RPM pour le noyau et glibc. Lorsqu’un paquet de mise à jour est publié, la version de base reste la même et la version est mise à jour.

Figure 1. Version et sortie du noyau/glibc

Qu’est-ce que le noyau d’entreprise incassable ?

Le noyau d’entreprise incassable (UEK) est un noyau unique à Oracle Linux qui est basé sur un noyau plus récent que RHCK et est compatible avec RHCK. Le manuel suivant fournit une référence pour ses fonctionnalités.

Documentation officielle : Noyau d’entreprise incassable

Le noyau d’entreprise incassable (UEK) est un noyau Linux construit par Oracle et pris en charge via le support Oracle Linux. Son objectif est la performance, la stabilité et un minimum de rétroportages en suivant le code source principal aussi près que possible de manière pratique. L’UEK est bien testé et utilisé pour exécuter les systèmes conçus par Oracle, l’infrastructure cloud Oracle et les déploiements d’entreprise à grande échelle pour les clients Oracle.

Guide d’installation de la base de données pour Linux

Le noyau d’entreprise incassable est inclus et activé par défaut dans les noyaux Oracle Linux. Il est basé sur une version récente et stable du noyau Linux de développement principal, et inclut également des optimisations développées en collaboration avec les équipes d’ingénierie de la base de données Oracle, des intergiciels Oracle et du matériel Oracle pour assurer la stabilité et des performances optimales pour les charges de travail d’entreprise les plus exigeantes.

Les points principaux sont :

• L’UEK est un noyau Linux développé et pris en charge par Oracle.
• Noyau par défaut d’Oracle Linux
• Basé sur une nouvelle version stable du noyau Linux principal
• Développé en collaboration avec les équipes Exadata et de la base de données Oracle, avec un accent sur la performance et la stabilité
• Testé dans des environnements de charges de travail d’entreprise à grande échelle, y compris Exadata et l’infrastructure cloud Oracle

Relation entre Oracle Linux et la version du noyau

Le numéro de version de l’UEK change en fonction du noyau sur lequel il est basé, et est nommé, par exemple, UEK6 et UEK7. De plus, une différence majeure par rapport à RHCK est que la version majeure d’Oracle Linux et la version de l’UEK ne sont pas fixes. Le tableau suivant montre la correspondance entre l’UEK et Oracle Linux. Comme vous pouvez le voir dans ce tableau, Oracle Linux 8 peut utiliser UEK6 et UEK7.

Version UEK	Version du noyau	Oracle Linux 7	Oracle Linux 8	Oracle Linux 9
UEK7	5.15.0	×	○	○
UEK6	5.4.17	○	○	×
UEK5	4.14.35	○	×	×
UEK4	4.1.12	○	×	×

Le tableau suivant compare les versions du noyau de RHCK et de l’UEK pour Oracle Linux. Oracle Linux 9 a été publié en 2022, donc la différence entre les versions RHCK et UEK est faible. Cependant, comme Oracle Linux 7 et Oracle Linux 8 ont été publiés depuis un certain temps, la différence entre les versions RHCK et UEK est importante.

Version de Linux	RHCK	UEK
Oracle Linux 9	5.14.0	5.15.0
Oracle Linux 8	4.18.0	5.4.17, 5.15.0
Oracle Linux 7	3.10.0	4.1.12, 4.14.35, 5.4.17

Convention de nommage des versions du noyau Linux

Maintenant que nous avons couvert les versions du noyau Linux, examinons à nouveau la convention de nommage. En fait, il n’y en a pas de définitive, car elle a changé plusieurs fois et les conventions de nommage sont légèrement différentes entre le kernel.org original et les distributions Linux.

Conventions de nommage sur kernel.org

Tout d’abord, examinons les conventions de nommage utilisées par le site officiel du noyau Linux, kernel.org. Les noyaux Linux sont nommés comme « abc » et sont appelés comme suit. Cependant, cette convention de nommage n’est pas absolue.

a : Numéro de version majeure
b : Numéro de version mineure
c : Numéro de correctif ou de révision

De plus, la version suivante après 5.19 est 6.0, mais ce n’est pas parce que les fonctions ont changé de manière significative. C’est simplement parce qu’il n’est pas souhaitable que le nombre b devienne trop grand, et il est conventionnel d’incrémenter a lorsque b atteint environ 20. Et c représente les modifications de niveau de correctif telles que les corrections de bogues. Pour cette raison, il est maintenant courant d’appeler le numéro de version ou de sortie une combinaison de « ab » ou « abc ».

Dans le diagramme suivant, la version majeure est barrée car elle n’est plus beaucoup utilisée, mais elle est encore utilisée lorsque vous voulez être explicite sur le premier chiffre.

Figure 2. Convention de nommage des versions du noyau Linux

Jetez un œil au diagramme suivant. Il montre l’historique de développement du noyau Linux. Les parties grises représentent la période de développement, et après une certaine période, le développement passe à la version suivante. En d’autres termes, une version spécifique de Linux « abc » répète le cycle de vie de « développement → support → LTS (support à long terme) » une fois tous les quelques années. Le noyau LTS est publié une fois par an et est pris en charge pendant environ cinq ans.

Source : https://en.wikipedia.org/wiki/Linux_kernel_version_history

Figure 3. Historique des versions du noyau Linux 6.x

Figure 4. Historique des versions du noyau Linux 5.x

Conventions de nommage des distributions Linux

Les conventions de nommage des distributions Linux et de kernel.org sont légèrement différentes. Les noyaux des distributions Linux sont nommés comme « abc-z », mais en réalité, la plupart des distributions ont « ab0-z » où le c est un zéro. Cela est vrai non seulement pour RHEL mais aussi pour Ubuntu, ainsi que pour UEK7 et versions ultérieures.

Le diagramme suivant montre comment les versions du noyau sont appelées dans les distributions Linux. Il n’y a actuellement pas de compréhension commune, et cela semble varier en fonction du contexte et de la personne qui l’utilise.

Figure 5. Noms des distributions Linux

Le terme « Version de base » est nouveau pour la plateforme. Il indique la version de kernel.org sur laquelle elle est basée. Cependant, le nombre c est forcé à zéro, donc même si la version de base est 5.15.0, la version du noyau sur laquelle elle est basée n’est pas nécessairement 5.15.0. Par exemple, UEK7 est une version 5.15.0, mais elle est basée sur 5.15.6.

$ rpm -q --changelog kernel-uek-5.15.0-105.125.6.2.2.el9uek | tail -n 2
- Linux 5.15.6 (Greg Kroah-Hartman)

Relation entre mainline, longterm, stable et rc

Jetons un œil à la page du noyau Linux officiel, Les archives du noyau Linux. Plusieurs versions du noyau Linux sont listées, avec des étiquettes telles que mainline, longterm, stable et rc. Je vais expliquer chacune ci-dessous.

Figure 6. Les archives du noyau Linux

Le diagramme suivant montre certaines versions du noyau extraites de kernel.org avec des commentaires ajoutés. Le mainline est le développement principal. Une fois qu’un rc (candidat à la sortie) est disponible, il devient la version officielle, donc mainline et stable font référence au même état. Parmi les versions stables, une fois toutes les quelques versions, elles deviennent à long terme et sont prises en charge pendant une longue période.

Figure 7. Cycle de vie sur kernel.org

Qu’est-ce que le rétroportage ?

Il y a un mot à retenir ici : rétroportage. Le rétroportage désigne l’application de fonctionnalités ou de correctifs inclus dans une version plus récente d’un logiciel à une version plus ancienne du logiciel.

Par exemple, appliquer un nouveau correctif introduit dans la version 6.0 à la version 5.0 est appelé rétroportage. Généralement, plus la différence entre les deux versions est grande, plus la différence dans la base de code est importante, rendant l’application plus difficile. De plus, il y a des cas où le bogue en question n’existe pas dans la version plus ancienne, rendant le rétroportage inutile.

Certains se demandent peut-être quel est l’opposé du rétroportage. Par exemple, il s’agit du cas où un correctif de bogue de la version 5.0 d’un logiciel est appliqué à la version plus récente 6.0. J’ai fait quelques recherches, mais il n’y a pas de terme commun, et il semble que rétroportage, fusion, portage avant, etc. soient utilisés. Il semble que beaucoup appellent cela rétroportage sans trop y réfléchir.

Le texte suivant fait partie de la description de l’UEK introduite au début.

Son objectif est la performance, la stabilité et un minimum de rétroportages en suivant le code source principal aussi près que possible de manière pratique.

En tenant compte de ce que nous avons discuté jusqu’à présent, Oracle fait les affirmations suivantes :

• Les bases de code source mainline plus récentes sont plus susceptibles d’avoir une meilleure performance et stabilité car elles intègrent plus de nouvelles fonctionnalités et de correctifs de bogues.
• Commencer avec un code source mainline plus récent signifie qu’il y a moins de différences dans le code source, donc le moins de rétroportage est requis.

Connaissances de base sur les internes de Linux

L’une des choses les plus importantes à savoir sur l’UEK est sa compatibilité avec le noyau RHEL (RHCK). Pour comprendre la compatibilité, une connaissance de l’OS Linux est essentielle. Par conséquent, nous expliquerons les bases de la structure interne de Linux.

Principaux composants de l’OS Linux

Le diagramme suivant montre les principaux composants de l’OS Linux et leurs relations. Il est important de se souvenir de ces informations lorsque vous essayez de comprendre l’OS Linux.

• Noyau Linux
  Le noyau est le composant central de l’OS Linux. Il reçoit des requêtes des applications et effectue la gestion des processus et de la mémoire pour exécuter des programmes. Il utilise également des pilotes de périphériques, qui sont des modules du noyau, pour gérer le système de fichiers et contrôler les périphériques pour les E/S. Le rôle du noyau peut être résumé comme suit. Il est préférable de le comprendre comme une fonction qui agit sur le matériel.
  • Gestion des ressources matérielles pour le CPU, la mémoire, le disque, les cartes réseau, etc.
  • Gestion et contrôle des processus pour les applications fonctionnant sur Linux
• Modules du noyau
  Les modules du noyau sont des fichiers binaires qui étendent les fonctionnalités du noyau. Ce sont principalement des pilotes de périphériques, et ils sont dans un format qui peut être chargé en cas de besoin. Cela permet de prendre en charge de nouveaux matériels en ajoutant simplement des pilotes, et réduit également l’utilisation de la mémoire.
• Bibliothèques système
  Les bibliothèques système (ou simplement bibliothèques) sont des collections de fonctions couramment utilisées par les programmes, fournissant la plupart des fonctionnalités offertes par le système d’exploitation. La plus célèbre est glibc, la bibliothèque C standard utilisée dans Linux. Elle est appelée glibc car elle a été initialement développée par GNU sous le nom de GNU C Library.

Figure 8. Structure interne de Linux

Comprendre les bases (fonctions de bibliothèque et appels système)

Les applications dans la Figure 8 font référence à divers programmes, y compris les commandes et utilitaires inclus en standard dans l’OS. Ces programmes fonctionnent en appelant des fonctions de bibliothèque et des appels système. Comprenons la différence entre eux.

Les « bibliothèques » sont installées dans /lib64 et /usr/lib. Si vous affichez les informations de symbole de glibc avec la commande nm, vous verrez qu’elle contient printf(). Les informations de symbole font référence aux fonctions et variables contenues dans la bibliothèque ou le programme exécutable.

printf() fonctionne comme indiqué dans les arguments, en émettant des instructions au noyau si nécessaire.

$ rpm -qf /lib64/libc.so.6
glibc-2.34-60.0.3.el9.x86_64

$ nm /lib64/libc.so.6 | grep "T printf"
000000000006f430 T printf
000000000006e8f0 T printf_size
000000000006f350 T printf_size_info

Les « appels système » fournissent des fonctions pour manipuler le matériel telles que l’entrée/sortie de fichiers, la création de nouveaux processus, la communication réseau, etc. Dans la Figure 8, un appel système est appelé directement depuis une application. Cependant, il peut également être appelé via une fonction enveloppe d’appel système incluse dans glibc.

Avez-vous lu jusqu’ici ? Vous pouvez voir que les bibliothèques comme glibc sont très importantes. Pour cette raison, les distributions basées sur RHEL ne changent pas la version de glibc jusqu’à ce que la version majeure change.

Mode noyau et mode utilisateur

Décrit le mode noyau et le mode utilisateur.

Les programmes qui accèdent aux ressources matérielles, tels que le noyau et les pilotes de périphériques, fonctionnent dans un mode privilégié spécial appelé « mode noyau ». Ils fonctionnent dans un espace mémoire unique et isolé qui utilise les fonctionnalités de protection du CPU, et comme ils ne nécessitent pas de changements de contexte, ils fonctionnent très rapidement. Le noyau exécute non seulement chaque processus, mais fournit également un accès protégé au matériel.

En revanche, les programmes généraux fonctionnent dans un espace mémoire appelé « mode utilisateur ». Les programmes fonctionnant en mode utilisateur ne peuvent pas accéder directement au matériel. Au lieu de cela, ils accèdent aux fonctions du noyau via des appels système, et le noyau accède finalement au matériel.

Résumé des connaissances de base

Résumons brièvement les bases des internes de Linux que nous avons couvertes jusqu’à présent.

• Le noyau et glibc sont tous deux des composants importants de Linux, mais ils ont des rôles différents
• Le noyau est responsable du contrôle du matériel.
• Les bibliothèques fournissent des fonctions utilisées par les programmes courants. La bibliothèque la plus importante est glibc.
• Pour accéder au matériel, vous devez effectuer un appel système.
• Les programmes accèdent au matériel via des appels système ou des fonctions de bibliothèque.

Comment fonctionnent les conteneurs

Ensuite, nous expliquerons les conteneurs. Vous vous demandez peut-être « Pourquoi les conteneurs ? » après avoir expliqué le noyau. C’est parce que comprendre comment fonctionnent les conteneurs est un bon sujet pour comprendre la compatibilité du noyau.

Structure des conteneurs

Le diagramme suivant compare la virtualisation basée sur hyperviseur et basée sur conteneurs : une machine virtuelle a un OS invité et un noyau, tandis qu’un conteneur contient uniquement des applications et des bibliothèques, mais pas de noyau.

Figure 9. Différence entre le type hyperviseur et le type conteneur

La raison pour laquelle un noyau n’est pas requis dans un conteneur est qu’il utilise le noyau de l’OS hôte. Bien que les conteneurs utilisent des fonctionnalités Linux telles que cgroups et Namespace pour isoler les conteneurs les uns des autres, ce ne sont que des processus fonctionnant sur l’OS hôte. Voir le diagramme suivant. Un conteneur fonctionnera s’il contient les bibliothèques et programmes nécessaires pour exécuter une application.

Figure 10. Comment fonctionnent les conteneurs

Compatibilité du noyau Linux

Il y a quelque chose d’important ici.

Il fonctionnera même si l’OS sur lequel l’image du conteneur a été créée est une version différente de Linux de l’OS hôte.

Par exemple, supposons que l’OS hôte sur lequel le moteur de conteneur fonctionne est Ubuntu Server 22.04 LTS. Dans ce cas, même si l’image du conteneur est créée avec Oracle Linux 9, elle fonctionnera tant que les bibliothèques et binaires nécessaires sont inclus. Bien que les deux doivent être Linux, ils peuvent fonctionner même si les versions du noyau Linux sont légèrement différentes.

Cependant, c’est une question de savoir si cela fonctionne techniquement, et cela n’a rien à voir avec le fait que le fournisseur fournisse ou non un support technique.

Figure 11. Compatibilité du noyau Linux

Permettez-moi d’expliquer un peu plus en détail. Regardez la Figure 12 ci-dessous. L’interface entre les applications et le noyau dans les appels système Linux est appelée l’interface binaire d’application (ABI). Le noyau Linux est développé en tenant compte de la compatibilité afin que les appels système existant des versions précédentes puissent être appelés avec les mêmes spécifications. Par conséquent, même si la version du noyau Linux est légèrement différente, les applications fonctionneront de la même manière.

Figure 12. Maintien de la compatibilité via l’interface binaire d’application

Interface binaire d’application (ABI)

L’ABI est une définition d’interface, plus précisément le nom de l’appel système, le type de données des arguments, le nombre d’arguments, le type de données de la valeur de retour et la valeur, etc. Le noyau Linux est développé de manière à ce que ceux-ci ne changent pas. Si l’ABI ne change pas, il n’y aura pas d’erreurs lors de l’appel d’un appel système.

Cependant, si la version du noyau est différente, l’implémentation interne de l’appel système peut être différente. Cependant, l’appel système est une instruction primitive au matériel, comme « écrire des données sur le disque » ou « allouer de la mémoire ». Par conséquent, le comportement externe est également rendu identique. C’est ainsi que la compatibilité est maintenue.

Figure 13. Compatibilité maintenue par l’ABI

Incompatibilités à surveiller

D’autre part, de quelles incompatibilités faut-il se méfier ? Regardez la Figure 14 ci-dessous. Ce sont des modules du noyau tels que les pilotes de périphériques. Même si les numéros de version du noyau correspondent, ils peuvent ne pas fonctionner si les numéros de sortie à la fin sont différents. Certains modules du noyau peuvent absorber de légères différences dans les numéros de sortie, mais une recompilation est recommandée.

Bien que cela n’ait rien à voir avec le noyau, une chose à surveiller en matière de compatibilité des applications est les bibliothèques utilisées dans les langages, frameworks, etc. Les bibliothèques sont souvent mises à jour fréquemment, et il est courant qu’il y ait des restrictions telles que la bibliothèque XXX 2.0 ou supérieure.

Figure 14. Incompatibilité des modules du noyau

Comparaison entre UEK et RHCK

Maintenant que nous avons couvert les bases, nous pouvons enfin aborder le sujet principal de la comparaison : la compatibilité et les fonctionnalités.

Compatibilité avec RHCK

Il s’agit de la compatibilité entre UEK et RHCK. Si vous avez lu jusqu’ici, vous le savez probablement déjà. L’UEK est développé pour maintenir la compatibilité ABI avec RHCK. Par conséquent, s’il s’agit d’une application normale qui fonctionne en mode utilisateur, elle est compatible.

Cependant, il y a quelques points à garder à l’esprit.

Support pour les produits logiciels commerciaux
Le premier point est de savoir si le produit logiciel commercial est pris en charge. Même si un produit logiciel commercial prend en charge Oracle Linux, il peut prendre en charge RHCK mais pas UEK. En fait, les applications qui fonctionnent en mode utilisateur fonctionnent généralement sans problème, mais si vous voulez prioriser la politique de support du fournisseur, utilisez RHCK.

Un exemple de logiciel commercial qui nécessite une attention particulière à la compatibilité est les produits antivirus. Certains produits antivirus fonctionnent comme des modules du noyau, donc dans ce cas, vous devez vérifier qu’ils sont compatibles.

Il n’y a pas un large choix de logiciels japonais, mais vous pouvez vérifier la compatibilité avec Oracle Linux dans le catalogue ISV d’Oracle Linux.

Lors de l’utilisation d’un serveur fabriqué par un fabricant bien connu
La chose la plus importante à noter est qu’Oracle Linux est inclus dans la liste des matériels pris en charge. S’il n’est pas pris en charge par le fabricant, il y a de fortes chances qu’ils ne puissent pas vous aider en cas de problème.

De plus, comme les machines serveurs sont équipées de matériel spécial tel que des contrôleurs RAID et des NIC, les fabricants peuvent fournir leurs propres pilotes de périphériques. Si les pilotes ne sont pas pris en charge, vous ne pourrez peut-être pas les utiliser.

Consultez la page web du fabricant ou la liste de certification matérielle d’Oracle Linux pour des informations sur le support, qui inclut également des informations sur le support de RHCK et UEK.

Différences de fonctionnalités

Il est difficile de généraliser les différences de fonctionnalités, car elles varient selon la version du noyau, mais en général, l’UEK est basé sur un noyau mainline plus récent, donc il offre de meilleures performances et plus de fonctionnalités.

Par exemple, dans Oracle Linux 9, la version de base de l’UEK7 est 5.15.0, et la version de base de RHCK est 5.14.0. Il n’y a pas beaucoup de différence à ce stade. Cependant, comme montré dans le tableau suivant, les UEK changent même au sein de la même version majeure. Dans quelques années, l’UEK8 sera publié pour Oracle Linux 9, et la différence dans les versions du noyau s’élargira.

Version de Linux	UEK4	UEK5	UEK6	UEK7
Oracle Linux 9	×	×	×	○
Oracle Linux 8	×	×	○	○
Oracle Linux 7	○	○	○	×

Les fonctionnalités bien connues exclusives à l’UEK incluent ocfs2 et btfs. Il y en a d’autres, mais pour les détails, veuillez consulter « Nouvelles fonctionnalités et changements » dans les « Notes de version du noyau d’entreprise incassable ».

Figure 15. Notes de version 7 du noyau d’entreprise incassable

Résumé : Quand utiliser UEK ou RHCK ?

L’UEK est conçu pour les charges de travail à grande échelle de la base de données Oracle et d’Oracle Linux KVM, et est basé sur un noyau plus récent, ce qui signifie qu’il offre souvent de meilleures performances et fonctionnalités.

Cependant, l’UEK n’est pas une nécessité absolue. Je crois que vous devriez les utiliser en fonction de la situation et de l’objectif. Dans les cas suivants 1 et 2, vous devriez envisager d’utiliser RHCK. Ce qui est important, c’est de comprendre la différence entre UEK et RHCK et de les utiliser de manière appropriée. Je présenterai également un tableau résumant ce que j’ai expliqué jusqu’à présent.

1. Si vous utilisez un serveur physique et que le fabricant ne prend en charge que RHCK
   Utilisez RHCK.
2. Si vous utilisez un logiciel commercial et que le fournisseur ne prend en charge que RHCK
   Il est préférable d’utiliser RHCK. Cependant, si vous l’utilisez sur votre propre système et pouvez tolérer les risques, l’UEK est également une option.

Avantages et inconvénients de l’UEK par rapport à RHCK

Élément	Avantage	Inconvénient
Fonctions et performances	En fonction des versions de l’UEK et de RHCK que vous comparez, l’UEK est susceptible d’avoir de meilleures fonctionnalités et performances car il utilise un noyau mainline plus récent, et peut également avoir des optimisations pour la base de données Oracle.
Compatibilité des applications fonctionnant en mode utilisateur	Compatible	Dans le cas des produits packagés commerciaux, le support peut ne pas être disponible selon la politique de support du fournisseur.
Modules du noyau fonctionnant en mode noyau	Les pilotes de périphériques, etc., fournis sous forme de code source sont susceptibles d’être compatibles	Les logiciels antivirus et les pilotes de périphériques fonctionnant en mode noyau ne sont généralement pas compatibles.
Autres		Les serveurs de fabricants bien connus peuvent prendre en charge Oracle Linux (RHCK) mais pas l’UEK.