Étiquette : Virtualisation

TEK Arena > Virtualisation

Nouvelle version de RedHat 9 et ses nouvelles influences

Publié le 20 juillet 202211 juillet 2023 par Guy VANDENBERGHE

Comme vous le savez probablement, Red Hat Enterprise Linux (RHEL) 9 est désormais et généralement disponible. En parallèle de la sortie de la version RHEL release 8.6, cette version est conçue pour répondre aux besoins de l’environnement de cloud hybride. Dorénavant, cette version accentue l’exécution de votre code source plus efficacement, qu’il soit déployé sur une infrastructure physique, dans une machine virtuelle ou dans des conteneurs partir d’ images de base universelles Red Hat (UBI).

Actuellement RHEL 9 peut être téléchargé gratuitement dans le cadre de l’abonnement au programme Red Hat Developer.

Mais sans ressortir les informations commerciales, le mieux c’est de rentrer dans le vif du sujet en comparant les deux versions majeures distribuée par RedHat.

Caractéristiques	RHEL 9	RHEL 8
Date de sortie	17 mai 2022	7 mai 2019
Nom de code	Plow	Ootpa
Noyau	Distribué avec la version 5.14 du noyau	Distribué avec la version 4.18 du noyau
Gestion des packages	DNF, MIAM	DNF, MIAM
Architectures prises en charge	Architectures AMD et Intel 64 bits (x86-64-v2) L’architecture ARM 64 bits (ARMv8.0-A) IBM Power Systems, Little Endian (POWER9) IBM Z 64 bits (z14)	Architectures AMD et Intel 64 bits L’architecture ARM 64 bits IBM Power Systems, Little Endian IBM Z
Référentiels	Red Hat Enterprise Linux 9 est distribué via deux référentiels principaux; ce sont des OS AppStream	Red Hat Enterprise Linux 8 est distribué via deux référentiels principaux; ce sont des OS AppStream
La configuration initiale	À partir de RHEL 9, les écrans de configuration initiale ont été désactivés par défaut pour améliorer l’expérience utilisateur.	Les utilisateurs de RHEL doivent configurer les configurations initiales (licences, système (gestionnaire d’abonnements) et paramètres utilisateur) avant les écrans de configuration initiale et de connexion de gnome.
SELinux	Avec cette version, la prise en charge de la désactivation de SELinux via l’option SELINUX=disabled dans le fichier /etc/selinux/config a été supprimée du noyau.	La prise en charge de la désactivation de SELinux via l’option SELINUX=disabled dans /etc/selinux/config est prise en charge.
Script réseau	RHEL 9 ne contient pas le package network-scripts. Pour configurer les connexions réseau dans RHEL 9, utilisez NetworkManager.	Le package network-scripts était toujours disponible mais obsolète dans RHEL 8.
Versions des langages de programmation dynamiques	Node.js 16 PERL 5.32 PHP 8.0 Python 3.9 Rubis 3.0	Node.js 16 PERL 5.26 PHP 7.2 Python 3.6 Rubis 2.5 Python 2.7 est disponible dans le package python2 (aura un cycle de vie plus court)
Filtrage de paquets	nftables est le cadre de filtrage de paquets réseau par défaut et les packages ipset et iptables-nft ont été dépréciés.	nftables remplace iptables comme cadre de filtrage de paquets réseau par défaut
Systèmes de fichiers	XFS est le système de fichiers par défaut et prend désormais en charge les fonctionnalités bigtime et inobtcount. De plus, le système de fichiers exFAT est désormais pris en charge dans RHEL 9.	XFS est le système de fichiers par défaut. Le système de fichiers Btrfs est supprimé dans Red Hat Enterprise Linux 8.
Optimiseur de données virtuel (VDO)	Le logiciel de gestion VDO basé sur python n’est plus disponible dans RHEL 9. Au lieu de ce logiciel, utilisez l’implémentation LVM-VDO pour gérer les volumes VDO.	VDO est disponible sur toutes les architectures prises en charge par RHEL 8.
Exécution du conteneur par défaut	crun	runc et Docker ne sont pas inclus dans RHEL 8.0.

bref comparaison entre versions

Changements majeurs dans RHEL 9.0

Sécurité

L’utilisation du SHA-1 à des fins cryptographiques a été dépréciée dans RHEL 9. Le résumé produit par SHA-1 n’est pas considéré comme sécurisé en raison de nombreuses attaques réussies documentées basées sur la recherche de collisions de hachage. Les composants cryptographiques principaux de RHEL ne créent plus de signatures à l’aide de SHA-1 par défaut. Les applications dans RHEL 9 ont été mises à jour pour éviter d’utiliser SHA-1 dans les cas d’utilisation liés à la sécurité.

OpenSSL est désormais fourni dans la version 3.0.1, qui ajoute un concept de fournisseur, un nouveau schéma de gestion des versions, un client HTTP(S) amélioré, la prise en charge de nouveaux protocoles, formats et algorithmes, et de nombreuses autres améliorations.

Les politiques cryptographiques ont été ajustées pour fournir des valeurs par défaut sécurisées à jour.

OpenSSH est distribué dans la version 8.7p1, qui fournit de nombreuses améliorations, corrections de bogues et améliorations de sécurité par rapport à la version 8.0p1, qui est distribuée dans RHEL 8.5.

Le protocole SFTP remplace le protocole SCP/RCP précédemment utilisé dans OpenSSH . SFTP offre une gestion plus prévisible des noms de fichiers et ne nécessite pas d’extension de glob(3)motifs par la coque du côté distant.

SELinux ont été considérablement améliorées, y compris le temps de chargement de la politique SELinux dans le noyau, la surcharge de mémoire et d’autres paramètres. Pour plus d’informations, consultez le Améliorer les performances et l’efficacité de l’espace de SELinux blog

L’utilisation de SHA-1 pour les signatures est restreinte dans la politique de chiffrement DEFAULT. À l’exception de HMAC, SHA-1 n’est plus autorisé dans les protocoles TLS, DTLS, SSH, IKEv2, DNSSEC et Kerberos.

Consultez la Sécurité dans le Considérations relatives à l’adoption de RHEL 9 pour plus d’informations sur les principales différences liées à la sécurité entre RHEL 9 et RHEL 8.

La mise en réseau

Vous pouvez utiliser le nouveau démon MultiPath TCP (mptcpd) pour configurer les points de terminaison MultiPath TCP (MPTCP) sans utiliser iproute2 . Pour rendre les sous-flux et les points de terminaison MPTCP persistants, utilisez un script de répartiteur NetworkManager.

Par défaut, NetworkManager utilise désormais les fichiers de clés pour stocker les nouveaux profils de connexion. A savoir que format ifcfg est toujours pris en charge.

Pour plus d’informations sur les fonctionnalités introduites dans cette version et les modifications apportées aux fonctionnalités existantes, consultez Nouvelles fonctionnalités – Mise en réseau .

La technologie WireGuard VPN est désormais disponible optionnel mais non supporté. Pour plus de détails, voir Aperçus technologiques – Mise en réseau .

Le service teamdservice etsa librairie libteam sont obsolètes. En remplacement, il faudra configurer une liaison type bond au lieu du service team.

La iptables-nft et ipset sont obsolètes. Ces packages incluent des utilitaires, tels que iptables, ip6tables, ebtableset arptables. Il faut utiliser le framework nftables pour configurer les règles de pare-feu.

Pour plus d’informations sur les fonctionnalités obsolètes, consultez Fonctionnalité obsolète – networking.network-scripts a été supprimé. Utilisez NetworkManager pour configurer les connexions réseau. Pour plus d’informations sur les fonctionnalités qui ne sont pas loin r partie de RHEL, consultez la Mise section Considérations relatives à l’adoption de RHEL 9 .

Langages de programmation dynamiques, serveurs web et bases de données

RHEL 9.0 fournit les langages de programmation dynamique suivants :

Node.js 16
Perl 5.32
PHP 8.0
Python 3.9
Rubis 3.0

RHEL 9.0 inclut les systèmes de contrôle de version suivants :

Gite 2.31
Sous-version 1.14

Les serveurs Web suivants sont distribués avec RHEL 9.0 :

Serveur HTTP Apache 2.4.51
nginx 1.20

Les serveurs de mise en cache proxy suivants sont disponibles :

Cache de vernis 6.6
Calmar 5.2

RHEL 9.0 propose les serveurs de base de données suivants :

MariaDB 10.5
MySQL 8.0
PostgreSQL 13
Redis 6.2

Voir Section 4.13, « Langages de programmation dynamiques, serveurs Web et de base de données » pour plus d’informations.

Implémentations Java dans RHEL 9

Le référentiel RHEL 9 AppStream comprend :

La java-17-openjdkpackages, qui fournissent l’environnement d’exécution Java OpenJDK 17 et le kit de développement logiciel OpenJDK 17 Java.
La java-11-openjdkpackages, qui fournissent l’environnement d’exécution Java OpenJDK 11 et le kit de développement logiciel OpenJDK 11 Java.
La java-1.8.0-openjdkpackages, qui fournissent l’environnement d’exécution Java OpenJDK 8 et le kit de développement logiciel OpenJDK 8 Java.

Pour plus d’informations, consultez la documentation OpenJDK .

Outils Java

Les outils Java suivants sont disponibles avec RHEL 9.0 :

Maven 3.6
Le 1.10

Voir Section 4.14, « Compilateurs et outils de développement » pour plus d’informations.

Virtualisation

Dans la version de RHEL 9, la bibliothèque libvirt utilise des démons modulaires qui gèrent des ensembles de pilotes de virtualisation individuels sur votre hôte. Cela permet d’affiner une variété de tâches qui impliquent des pilotes de virtualisation, telles que l’optimisation et la surveillance de la charge des ressources.

L’émulateur QEMU est maintenant construit à l’aide du compilateur Clang. Cela permet à l’hyperviseur KVM de RHEL 9 d’utiliser un certain nombre de fonctionnalités avancées de sécurité et de débogage. L’une de ces fonctionnalités est SafeStack, qui rend les machines virtuelles (VM) hébergées sur RHEL 9 beaucoup plus sûres contre les attaques basées sur la programmation orientée retour (ROP).

De plus, Virtual Trusted Platform Module (vTPM) est désormais entièrement pris en charge. À l’aide de vTPM, vous pouvez ajouter un crypto-processeur virtuel TPM à une machine virtuelle, qui peut ensuite être utilisé pour générer, stocker et gérer des clés cryptographiques.

Finalement, le système de gestion de fichiers virtiofs a été implémentée.
Rappel: Il s’agit d’une option que vous pouvez utiliser pour partager plus efficacement des fichiers entre un hôte RHEL 9 et ses machines virtuelles.

Pour plus d’informations sur les fonctionnalités de virtualisation introduites dans cette version, reportez- la Section 4.20, « Virtualisation » .

Mise à niveau sur place

Mise à niveau sur place de RHEL 8 vers RHEL 9

Les passerelles de mise à niveau actuellement en place prennent en charge :

De RHEL 8.6 à RHEL 9.0 sur les architectures suivantes :
- Intel 64 bits
- AMD 64 bits
- ARM 64 bits
- IBM POWER 9 (petit boutiste)
- Architectures IBM Z, hors z13
De RHEL 8.6 à RHEL 9.0 sur des systèmes avec SAP HANA

Pour plus d’informations, consultez Chemins de mise à niveau sur place pris en charge pour Red Hat Enterprise Linux . Pour obtenir des instructions sur la réalisation d’une mise à niveau sur place, consultez Mise à niveau de RHEL 8 vers RHEL 9 .

Mise à niveau sur place de RHEL 7 vers RHEL 9

Il n’est pas possible d’effectuer une mise à niveau sur place directement de RHEL 7 vers RHEL 9. Cependant, vous pouvez effectuer une mise à niveau sur place de RHEL 7 vers RHEL 8, puis effectuer une deuxième mise à niveau sur place vers RHEL 9. Pour plus plus d’informations, consultez Mise à niveau de RHEL 7 vers RHEL 8 .

Les nouvelles limites supportées et théoriques

Que peut faire Red Hat® Enterprise Linux® ? Découvrez dans ce tableau les limites supportées et théoriques de la plateforme.

Cet article fournit des informations sur les versions du système d’exploitation actuellement gérées. Pour plus d’informations sur les anciennes versions retirées qui ne sont plus maintenues, veuillez consulter l’article complémentaire de la base de connaissances intitulé Red Hat Enterprise Linux Technology Capabilities and Limits for Retired, Non-Maintained Releases .

Les limites prises en charge reflètent l’état actuel des tests du système par Red Hat et ses partenaires pour le matériel grand public. Les systèmes dépassant ces limites prises en charge peuvent être inclus dans le catalogue matériel après des tests conjoints entre Red Hat et ses partenaires. Si elles dépassent les limites prises en charge affichées ici, les entrées du catalogue de matériel incluront une référence aux détails des limites spécifiques au système et sont entièrement prises en charge. En plus des limites prises en charge reflétant la capacité matérielle, il peut y avoir des limites supplémentaires dans les conditions d’abonnement à Red Hat Enterprise Linux.

Les limites prises en charge sont susceptibles d’être modifiées à mesure que les tests en cours se terminent.

Les valeurs suivantes sont formatées comme testées et prises en charge [théorique] .

CPU logiques maximales

Red Hat définit un CPU logique comme n’importe quelle entité planifiable. Ainsi, chaque cœur/thread d’un processeur multicœur/thread est un processeur logique.

Architecture	RHEL 6	RHEL 7	RHEL 8	RHEL 9
x86	32	N/A ¹	N/A ¹	N/A ¹
x86_64	448 [4096] ²	768 [5120] ³	768 [8192]	1792 [8192]
POWER	128	768 [2048] ⁴	POWER8 : 768 [2048] POWER9 : 1536 [2048] ⁵ POWER10 : 1920 [2048] ⁶	POWER9 : 1536 [2048] POWER10 : 1536 [2048]
IBM Z	z13 : 64	z13 : 256	z13 : 256 z14 : 340	z14 : 340 z15 : 380
BRAS	N / A	N / A	256	512 [4096]

Mémoire maximale

Les limites architecturales sont basées sur les capacités du noyau Red Hat Enterprise Linux et du matériel physique. La limite de Red Hat Enterprise Linux 6 est basée sur un adressage de mémoire physique de 46 bits. La limite de Red Hat Enterprise Linux 5 est basée sur un adressage de mémoire physique de 40 bits. Toute la mémoire système doit être équilibrée entre les nœuds NUMA dans un système compatible NUMA.

Architecture	RHEL 6	RHEL 7	RHEL 8	RHEL 9
x86	16 GB	N/A ¹	N/A ¹	N/A ¹
x86_64	12 To [64 To] ⁷	12 To [64 To] ⁸	24 To [64 To]	48 To [64 To]
POWER	2 To	32 To ⁹	POWER8 : 32 To [128 To] POWER9 : 64 To [128 To] ¹⁰ POWER10 : 32 To [128 To] ¹¹	POWER9 : 64 To [128 To] POWER10 : 32 To [128 To]
IBM Z	z13 : 4 To	z13 : 10 To	z13 : 10 To z14 : 16 To	z14 : 16 To z15 : 16 To
BRAS	N / A	N / A	1,5 To [256 To]	1,5 To [256 To]
Espace d’adressage virtuel x86 maximum par processus	Environ. 3 Go	N/A ¹	N/A ¹	N/A ¹
Espace d’adressage virtuel maximal x86_64 par processus	128 To	128 To	128 To	128 To
Espace d’adressage virtuel de puissance maximale par processus	—	—	4PB ¹²	4PB ¹²

Mémoire minimale requise

Architecture	RHEL 6	RHEL 7	RHEL 8	RHEL 9
x86	512 Mo minimum, 1 Go par processeur logique recommandé	N/A ¹	N/A ¹	N/A ¹
x86_64	1 Go minimum, 1 Go par processeur logique recommandé	1 Go minimum, 1 Go par processeur logique recommandé ¹³	1,5 Go minimum, 1,5 Go par processeur logique recommandé ¹³	1,5 Go minimum, 1,5 Go par processeur logique recommandé ¹³
POWER	2 Go minimum, 2 Go requis par installation	2 Go minimum, 2 Go requis par installation	2 Go minimum, 2 Go requis par installation	2 Go minimum, 2 Go requis par installation
IBM Z	512 Mo	1 Go	1 Go minimum, 2 Go requis pour l’installation	1 Go minimum, 2 Go requis pour l’installation
BRAS	N / A	N / A	2 Go	2 Go

Espace disque minimum requis

RHEL 6	RHEL 7	RHEL 8	RHEL 9
1 Go minimum, 5 Go recommandés	10 Go minimum, 20 Go recommandés	10 Go minimum, 20 Go recommandés	10 Go minimum, 20 Go recommandés

Systèmes de fichiers et limites de stockage

Ext3

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Taille de fichier maximale	2 To	2 To	2 To	2 To
Taille maximale du système de fichiers	16 To	16 To	16 To	16 To
Nombre maximal de sous-répertoires	32000	32000	32000	32000
Profondeur maximale du lien symbolique	8	8	8	8
Prise en charge de la LCA	Oui	Oui	Oui	Oui

Ext4

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Taille de fichier maximale	16 To	16 To	16 To	16 To
Taille maximale du système de fichiers	16 To [1 EB]	50 To [1 EB]	50 To [1 EB]	50 To [1 EB]
Nombre maximal de sous-répertoires	65000/illimité	65000/illimité	65000/illimité	65000/illimité
Profondeur maximale du lien symbolique	8	8	8	8
Prise en charge de la LCA	Oui	Oui	Oui	Oui

SFP

Veuillez consulter l’article de la base de connaissances intitulé Red Hat Enterprise Linux Technology Capabilities and Limits for Retired, Non-Maintained Releases pour plus d’informations sur la prise en charge de GFS.

GFS2

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Taille de fichier maximale	100 To [8 EB]	100 To [8 EB]	100 To [8 EB]	100 To [8 EB]
Taille maximale du système de fichiers	100 To [8 EB]	100 To [8 EB]	100 To [8 EB]	100 To [8 EB]
Nombre maximal de sous-répertoires	illimité	illimité	illimité	illimité
Profondeur maximale du lien symbolique	illimité	illimité	illimité	illimité
Prise en charge de la LCA	Oui	Oui	Oui	Oui

XFS

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Taille de fichier maximale	100 To [8 EB]	500 To [8 EB]	8EB	8EB
Taille maximale du système de fichiers	300 To [16 EB] ¹⁴	500 To [16 EB]	1PB	1PB
Nombre maximal de sous-répertoires	illimité	illimité	illimité	illimité
Profondeur maximale du lien symbolique	8	8	8	8
Prise en charge de la LCA	Oui	Oui	Oui	Oui

Stockage

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Taille maximale du LUN de démarrage (BIOS)	2 To ¹⁵	2 To ¹⁵	2 To	2 To
Taille maximale du LUN de démarrage (UEFI)	32 bits (i686) – 2 To, 64 bits – 16 To (limite testée)	50 To	8EB	8EB
Nombre maximal de chemins d’accès aux périphériques ( `sd`dispositifs)	8,192 ^16,17	10,000 ^16,17	10,000 ^16,17	10,000 ^16,17

Fonctionnalités du noyau et du système d’exploitation

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Fondation du noyau	2.6.32 – 2.6.34	3.10	4.18	5.14
Compilateur/chaîne d’outils	CCG 4.4	CCG 4.8.2	CCG 8.2.1	CCG 11.2.1
Langues prises en charge	22	22	À déterminer	À déterminer
Certifié NIAP/CC	Oui (4+)	En cours d’évaluation (4+)	En discussion	En discussion
KVM certifié Critères Communs	Évalué	En cours d’évaluation	—	—
IPv6	Prêt Logo Phase 2	En cours d’évaluation	En discussion	En discussion
Certifié FIPS	Oui (8 modules)	En cours d’évaluation (9 modules)	En discussion	En discussion
Conforme à l’environnement d’exploitation commun (COE)	N / A	N / A	En discussion	En discussion
Conforme au LSB	Oui – 4.0	En cours d’évaluation (4.1)	En discussion	En discussion
GB18030	Oui	Oui	Oui	En discussion

Environnement clients

Caractéristique	RHEL 6	RHEL 7	RHEL 8	RHEL 9
Interface graphique du bureau	Gnome 2.28	Gnome 3.8	Gnome 3.28 ¹⁸	Gnome 40, plus mises à jour ¹⁸
Graphique	X.org 7.4	X.org 7.7	Wayland 1.15 ¹⁸	Wayland 1.19 ¹⁸
Suite bureautique	Open Office v3.2 ¹⁸	Libre Office v4.1.4 ¹⁸	Libre Office v6.0.6.1 ¹⁸	Libre Office v7.1.8.1 ¹⁸
Évolution de GNOME	v2.28	v3.8.5	v3.28.5 ¹⁸	v3.40.4 ¹⁸
Navigateur par défaut	Firefox 3.6 ¹⁸	Firefox 24.5 ¹⁸	Firefox 60.5.1 ¹⁸	Firefox 91.8.0 ¹⁸

Caractéristique environnement client

Remarques

Red Hat Enterprise Linux 7 et les versions plus récentes n’incluent pas la prise en charge de l’architecture x86 32 bits.
Red Hat Enterprise Linux 6.7 ou plus récent est requis pour la prise en charge de 448 CPU. Le nombre maximal de processeurs pris en charge pour les versions antérieures était de 288 processeurs.
Red Hat Enterprise Linux 7.3 avec le noyau d’errata 3.10.0-514.26.2.el7 ou plus récent est requis pour la prise en charge du processeur 768. Red Hat Enterprise Linux 7.2 avec le noyau d’errata 3.10.0-327.18.2.el7 ou plus récent est requis pour la prise en charge du processeur 576. Red Hat Enterprise Linux 7.2 ou plus récent est requis pour la prise en charge de 384 CPU. Le nombre maximal de processeurs pris en charge pour les versions antérieures était de 288 processeurs. De même, pour la version 7.2 ou ultérieure, veuillez consulter l’article suivant de la base de connaissances Red Hat : L’échange de mémoire se produit pendant la récupération du cache de page .
Red Hat Enterprise Linux 7.5 ou plus récent, Red Hat Enterprise Linux 7.4 Extended Update Support (EUS) kernel version 3.10.0-693.25.2.el7 ou plus récent, ou Red Hat Enterprise Linux 7.3 Extended Update Support (EUS) kernel version 3.10.0 -514.48.1.el7 ou plus récent est requis pour la prise en charge du processeur 768. Le nombre maximal de processeurs pris en charge pour les versions de mise à jour antérieures ou les noyaux EUS de Red Hat Enterprise Linux 7 était de 192 processeurs.
Red Hat Enterprise Linux 8.2 ou plus récent est requis pour prendre en charge les processeurs 1536 sur les systèmes IBM POWER9. Le nombre maximal de CPU pris en charge sur Red Hat Enterprise Linux 8.0 et 8.1 pour POWER9 est de 768 CPU.
Les tests initiaux ont démontré la prise en charge complète des processeurs 1536 sur les systèmes IBM Power10 exécutant Red Hat Enterprise Linux 8.4 ou une version plus récente. Des tests supplémentaires nous ont permis d’augmenter le nombre maximal de processeurs pris en charge à 1920 processeurs lors de l’exécution de Red Hat Enterprise Linux 8.4 ou plus récent sur les systèmes IBM Power10.
Red Hat Enterprise Linux 6.7 est requis pour la prise en charge de 12 To de RAM. Red Hat Enterprise Linux 6.6 peut prendre en charge jusqu’à 6 To de RAM. Les versions précédentes de Red Hat Enterprise Linux 6, à commencer par Red Hat Enterprise Linux 6.3, prennent en charge jusqu’à 3 To de RAM. Les versions de Red Hat Enterprise Linux antérieures à Red Hat Enterprise Linux 6.3 prennent en charge jusqu’à 1 To de RAM.
Red Hat Enterprise Linux 7.2 est requis pour la prise en charge de 12 To de RAM. Red Hat Enterprise Linux 7.1 peut prendre en charge jusqu’à 6 To de RAM. Les versions précédentes de Red Hat Enterprise Linux 7 (c’est-à-dire Red Hat Enterprise Linux 7.0) prennent en charge jusqu’à 3 To de RAM. Red Hat Enterprise Linux 7.2 est requis pour la prise en charge de 12 To de RAM. Red Hat Enterprise Linux 7.1 peut prendre en charge jusqu’à 6 To de RAM. Les versions précédentes de Red Hat Enterprise Linux 7 (c’est-à-dire Red Hat Enterprise Linux 7.0) prennent en charge jusqu’à 3 To de RAM.
Red Hat Enterprise Linux 7.5 ou plus récent, Red Hat Enterprise Linux 7.4 Extended Update Support (EUS) kernel version 3.10.0-693.25.2.el7 ou plus récent, ou Red Hat Enterprise Linux 7.3 Extended Update Support (EUS) kernel version 3.10.0 -514.48.1.el7 ou plus récent est requis pour la prise en charge de 32 To de RAM. Les versions de mise à jour précédentes ou les noyaux EUS de Red Hat Enterprise Linux 7 pouvaient prendre en charge jusqu’à 2 To de RAM.
Red Hat Enterprise Linux 8.2 ou plus récent est requis pour prendre en charge 64 To de RAM sur les systèmes IBM POWER9. La quantité maximale de RAM prise en charge sur Red Hat Enterprise Linux 8.0 et 8.1 pour POWER9 est de 32 To.
Red Hat Enterprise Linux 8.4 ou plus récent est requis pour prendre en charge 32 To de RAM sur les systèmes IBM Power10.
Pour les processeurs prenant en charge l’adressage virtuel 52 bits.
L’installation réseau / PXE nécessite au moins 1,5 Go de RAM pour la procédure d’installation uniquement.
Red Hat Enterprise Linux 6.8 ou plus récent est requis pour la prise en charge du système de fichiers XFS de 300 To sur RHEL 6.x. La taille maximale du système de fichiers XFS précédemment prise en charge dans RHEL 6.7 et versions antérieures était de 100 To.
La prise en charge d’UEFI et de GPT est requise pour une prise en charge de LUN de démarrage supérieure à 2 To, comme détaillé dans l’article de la base de connaissances intitulé Configuration requise du lecteur de démarrage pour Red Hat Enterprise Linux .
Des nombres plus importants sont possibles, en fonction des tests et de la prise en charge par le fournisseur de matériel spécifique. Consultez votre fournisseur de matériel pour déterminer leur limite et confirmez avec votre représentant du support Red Hat. En aucun cas, Red Hat ne prendra en charge une limite qui dépasse la limite prise en charge par le fournisseur de matériel.
Il peut être nécessaire d’augmenter certains paramètres du pilote pour atteindre ces limites. Consultez votre représentant de l’assistance Red Hat. Il peut être nécessaire d’augmenter certains paramètres du pilote pour atteindre ces limites. Consultez votre représentant de l’assistance Red Hat.
Les applications de l’espace utilisateur seront mises à jour pendant la durée de vie de la version.

Cycle de vie de Red Hat Enterprise Linux

Liée à ces nouvelles versions, les influences du support et garanties indiquées sur le tableau ci-contre:

Description	Plein soutien	Entretien Soutien 1 (RHEL 7) ¹²	Entretien Prise en charge (RHEL 8 et 9) ¹³ Entretien Soutien 2 (RHEL 7) ¹²	Durée de vie prolongée Phase ⁷	Module complémentaire ELS (Extended Life Cycle Support) ⁸	Module complémentaire de prise en charge étendue des mises à jour (EUS) ⁸
Accès au contenu précédemment publié via le portail client Red Hat	Oui	Oui	Oui	Oui	Oui	Oui
Auto-assistance via le portail client Red Hat	Oui	Oui	Oui	Oui	Oui	Oui
Assistance technique ¹	Illimité	Illimité	Illimité	Limité ⁹	Illimité	Illimité
Errata de sécurité asynchrone (RHSA) ¹⁰ ¹¹	Oui	Oui	Oui	Non	Oui ⁸	Oui ⁸
Errata de correction de bogue asynchrone (RHBA) ² ¹¹	Oui	Oui	Oui	Non	Oui	Oui
Versions mineures	Oui	Oui	Oui (RHEL 7) ; Non applicable (RHEL 8 & 9)	Non	Non	Non
Activation matérielle actualisée ³	Originaire de	Limité ⁴natif	Utilisation de la virtualisation	Utilisation de la virtualisation	Utilisation de la virtualisation	Utilisation de la virtualisation
Améliorations du logiciel ⁵	Oui ⁶	Non	Non	Non	Non	Non
Mise à jour des images d’installation	Oui	Oui	Oui ¹⁴	Non	Non	Non

Cycle de vie de Red Hat Enterprise Linux

L’accès au support technique dépend du niveau de service inclus dans votre abonnement Red Hat Enterprise Linux.
Red Hat peut choisir, à titre de mesure temporaire, de résoudre ces problèmes catastrophiques ayant un impact significatif sur l’activité du client avec un correctif pendant que l’avis d’errata de correction de bogue (RHBA) est en cours de création.
L’activation du matériel natif est fournie par le rétroportage des pilotes matériels, etc., vers la version appropriée de Red Hat Enterprise Linux. L’activation du matériel à l’aide de la virtualisation est obtenue en exécutant une version antérieure de Red Hat Enterprise Linux en tant qu’invité virtuel sur une version plus récente de Red Hat Enterprise Linux. Voir la virtualisation description de REMARQUE : La certification matérielle (y compris les limites matérielles associées) s’applique à la version de Red Hat Enterprise Linux qui est utilisée comme hôte.
L’activation du matériel natif dans la phase de support de maintenance 1 est limitée à l’activation du matériel qui ne nécessite pas de modifications logicielles substantielles. Voir la support de maintenance 1 ci-dessous pour plus de détails.
Les améliorations logicielles sont des ajouts de nouvelles fonctionnalités au-delà de la correction des défauts ou de l’activation de fonctionnalités existantes sur une nouvelle génération de matériel.
Les versions majeures sont le principal vecteur d’améliorations logicielles importantes, bien que des améliorations logicielles à faible impact puissent également être fournies dans des versions mineures.
Voir la phase de durée de vie prolongée description
La prise en charge étendue des mises à jour (EUS) et la prise en charge étendue du cycle de vie (ELS) sont disponibles en tant que modules complémentaires en option. Voir les EUS et ELS descriptions
Uniquement pour les installations existantes. Voir les détails dessous pour les autres limitations.
Consultez la Classification de la gravité des problèmes pour les classifications de gravité de la sécurité.
Tous les errata sont fournis à la discrétion de Red Hat.
S’applique à la version 7 de RHEL ; ne s’applique pas à RHEL 8 & 9.
Le support de maintenance pour RHEL 8 et 9 est l’équivalent du support de maintenance 2 pour toute la phase de maintenance.
Image d’installation mise à jour fournie à la date de la première version mineure GA.

Guide de planification RHEL

Construisez votre cluster de virtualisation AMD au format Mini-ITX

Publié le 14 septembre 202015 juin 2022 par Guy VANDENBERGHE

Ce n’est pas nouveau, mais beaucoup d’ingénieur en informatique ou développeur cherche perpétuellement la bonne configuration pour construire son serveur pour un lab ou plus.

La problématique est que l’encombre d’un serveur au format tour ou rack est avéré.
Si l’on cherche à se retrouver seul chez soi avec son serveur, au lieu de la personne avec qui nous vivons, c’est la bonne démarche !

Après une configuration à base de Shuttle et d’intel I7-8700 créée en 2017, je vous propose un nouveau challenge:
Un VRAI serveur AMD en format Mini-ITX.
Vous allez me rétorquer, “Pffffuu, facile….”. Mais là je vous parle d’un VRAI serveur avec une carte serveur sans l’équipement de carte vidéo.
“Aahhhh ?”. Eh bien oui ! 🙂

Après sa fameuse carte mère X470D4U au format ATX, ASRock Rack, la filiale d’ASRock, a publié courant janvier une nouvelle version de cette fameuse carte mère. Plus rapide et pourvu du chipset X570 devenu un standard pour les cartes mères à base de processeurs AMD.
Mais cela n’est pas tout. Cette carte est au format Mini-ITX.

Cette nouvelle au final avec les problématiques de COVID, à pris beaucoup…beaucoup de retard sur la production venant de Chine.
Les premières livraisons sont arrivées au compte-gouttes courant Juin dans certains pays en Europe, et Juillet/Aout en France.

Pour couronner le tout, certains composants comme les alimentations se sont fait attendre également. Autant dire que les approvisionnements sont tendues à cause de ces épisodes d’épidémies et partout dans le monde.

Voici donc un exemple de configuration que je vous propose en versus Mini-ITX.

Le cahier des charges

Un serveur avec un processeur AMD et dépassant 10 cœurs.
Pas de blocage d’évolution de la RAM à 32 ou 64GB
La possibilité de mettre plus de deux disque de stockage
Un budget raisonnable pour ce genre de configuration

La carte mère

Cette X570D4I-2T est une bombe, et propose tous de sa petite sœur la X470. Attention cependant, cette carte mère est le premier centre de coût après le processeur. Comptez plus de 300€.:

1 socket AMD AM4 pour processeur AMD Ryzen 3000
4 Slots mémoire DDR4 2133/2400/2666/2933 MHz Dual-Channel (128 Go max.)
8 SATA 6Gb/s (par OCulink) avec le support RAID 0/1/10
1 x M.2 PCIe 4.0 x4 / SATA 6 Gbps
1 port PCI-Express 4.0 16x
2 LAN 10 GbE Intel X550-AT2
1 port LAN mangement IPMI Realtek RTL8211E
1 Contrôleur Aspeed AST2500

Et oui, cette carte serveur possède sa carte graphique. Inutile de monopoliser un port PCI pour une carte graphique, car comme vous le savez, seul les AMD de la série Vega intègre le processeur graphique. Un sacré gain de place, de consommation. Et il nous reste un port PCI utilisable pour soit une carte graphique dédié pour du calcul GPU ou autre.

Il s’agit bien ici d’une carte mère serveur, car il y a la présence d’un BMC, car comme on peut le voir, un troisième port Ethernet est disponible. Il s’agit d’un port de management qui permet, comme beaucoup de carte mère serveur de prendre la main à distance (RSA, iLO, et cie). Et surtout de démarrer la carte mère et ses périphériques.

Add’On

Pour ajouter un petit plus (qui existait dans la configuration Shuttle), une carte Wifi en port PCI avec un chipset Intel, et … une puce bluetooth. De quoi être complet, non !?!

Le processeur

Deuxième centre de coût.

Mon objectif était de monté en puissance après ma configuration Shuttle à base d’Intel I7-8700.
Ainsi, de 12 Thread sur 6 Cœurs, j’ai fais le choix rapport/prix de passer à 12 Cœurs 24 Thread, soit doubler le compute.
Les EPYC étant trop cher, j’ai sélectionner le Ryzen 9 3900X 3800MHz.

La RAM

Troisième centre de coût. Le choix important et doit-être en compatibilité avec les recommandations constructeurs.
Deux barettes Crucial CT2K32G4SFD8266 propose ainsi 64 GB de RAM. Ainsi deux emplacements reste libre pour monter à 128GB la capacité maximale mémoire.

L’alimentation

Pour faire fonctionner cela, une bonne alimentation au format TFX, car au format Mini-ITX, c’est le format implicite.
J’ai choisi un bon rendement pour jouer la carte budget électrique et éviter des pertes dû au mauvais rendement. La TFX Power 2 300W Gold de chez BeQuiet me semblait une évidence pour rester dans un budget convenable. 300W, cela parait faible, mais cela est très suffisant, a moins d’utiliser des disques dur mécanique)

Le boitier

C’est très secondaire, mais au final, non. Il va accueillir tous l’ensemble et doit-être d’encombrement minimal. J’ai choisi le boitier BU12 de Chieftec, bien sur sans l’alimentation. Le boitier est de bonne facture pour un prix très raisonnable. Si on cherche à héberger beaucoup de disque dur il faudra changer pour un boitier un peu plus haut. Pour mon besoin, je suis parti pour deux unités à fortes capacités. (Nous en parlerons plus tard)

Ce boitier possède des emplacements 2,5″, 3,5″ et un pseudo 5 1/4″. Avec des berceaux d’adaptations à prix modique, il est donc possible de mettre en deux à quatre disque 2,5″.

Le Refroidissement

C’est un choix important pour éviter d’avoir trop de bruit et avoir une ventilation efficace. Par rapport à la hauteur du boitier, le choix est très dirigé.

ATTENTION, ASRock impose un montage des ventilateurs au format LGA15xx, alors que le processeur est au format M2.

Certains constructeur de système de refroidissement propose des ventilateurs, ou ventirad pour les puristes, adaptables pour de nombreux format et cela peut import le socket du processeur.

C’est le cas du C7 de chez Cryorig, qui possède un look très sympa, sans cloisonnement qui provoque lorsque le ventilateur se voile, des bruits de frottement. La hauteur de ce ventirad nous laisse encore un petit de mou.

Le stockage

Comme je vous l’ai dit, j’ai choisi deux disques SATA SSD à fortes capacités. Selon son besoin, ils pourront être montés en RAID1 ou non en fonction. J’ai choisi un volume par disque Segate Baracuda 120 SSD. Ce choix est le meilleur compromis/prix avec IO supérieurs à Western Digital ou Crucial par exemple.

Enfin pour éviter de monopoliser l’un de ces pour le système de virtualisation, un disque M2 de 250 GB WD blue que je possédais. Très largement suffisant.

L’intégration

La carte mère s’intègre sans complication sur le boitier.
C’est côté alimentation que l’intégration doit-être soignée, car la place disponible est faible. Notamment près du ventilateur du boitier.
Une attention toute particulière est aussi sur le raccordement. Fourni avec l’alimentation TFX, BeQuiet! propose un adaptateur ATX vers ATX 12V. Il ne faut pas non plus oublier l’alimentation 12v du CPU, sinon la carte mère s’allumera de facto, mais sans CPU rien ne fonctionnera et sans aucune alerte sur la partie BMC.

Comme on peut le voir sur les illustrations, le raccordement des unités de disques de stockage SATA s’effectue par un câble OnLink. Attention ce câble est assez fin et peu, vite s’abimer. Via ce câble, quatre connexions SATA sont disponibles.

ATTENTION également, ASRock recommande d’utiliser les câbles d’alimentations venant de l’alimentation à découpage TFX et non de la carte mère pour éviter des dégradations de la carte mère. Tous dépends de l’alimentation utilisée ATX ou ATX12V.

Installation de l’hyperviseur

Aspeed AST2500 oblige, il faudra se contenter d’un port vidéo VGA. Mais cela n’est pas forcément utile, car nous disposons de notre BMC. Et là tout se fait à distance !
Précaution, tout de même, utilisez la version Java de la prise à distance. Cela vous permettra d’avoir plus d’options à disponibilité.

Cela parait simple, mais il y a toujours des mauvaises estimations de compatibilité avec un hyperviseur ou un autre.

ESXi 7

Avant l’achat, il est évident que des vérifications de compatibilités ont été réalisé notamment avec VMware. L’objectif était également de pouvoir installer un ESXi 7. Comme vous le savez, les drivers de l’ESXi 7 ont été complètement ré-écrit, ce qui ne peut pas forcément arranger les choses.

Force de dire que l’installation passe comme une lettre à la poste. Même la carte WIFI grace à son chipset Intel, est reconnue.

J’ai poussé le bouchon un peu plus loin en virtualisant un hyperviseur Linux, Proxmox. Bien évidement il est important d’activer le partage de l’hyper threading et affecter un nombre suffisant de CPU dédié à cette VM.

Ainsi nous disposons, d’un hyperviseur ESXi, et d’un hyperviseur Proxmox afin de virtualiser des containers LXC/LXD.

Chacun y trouvera son compte.

Proxmox 6.2.x

Installer un Proxmox au lieu d’un ESXi 7, ne pose aucun soucis de facto non plus. Noyau Linux oblige, c’est du gâteau !
Là aussi, tout est reconnu. Le petit plus, par rapport à une config Shuttle Intel, aucun besoin de toucher au configuration IOMMU pour éviter des instabilités, car ici TOUT est disponible et fonctionne sans rien faire.

Ainsi le partage en Pass-Thru des add’on PCI ou USB pour une VM, est fonctionnel.

Deux exemples de VM avec leur port PCI ou USB en mode Pass-Thru.

Installer un ESXi en mode Nested ne pose non plus aucun soucis. Il suffit de réserver un certains nombre de ressources CPU en mode CPU-Host par exemple pour profiter d’un hyperviseur VMware sous Proxmox.

Pour rappel sous linux, il est impératif de paramétrer les modules modprobe en fonction du fondeur du cpu:

Activation du support nested

Il faut commencer par contrôler si le paramètre nested est activé ou pas dans le processeur :

cat /sys/module/kvm_intel/parameters/nested
ou
cat /sys/module/kvm_amd/parameters/nested
# N ou 0

S’il est à N ou à 0, c’est qu’il n’est pas activé.

Pour activer l’activer, il suffit de positionner la variable à 1 à l’aide de la commande; Remplacez xxxx par le fondeur du cpu:

echo "options kvm-xxxx nested=1" > /etc/modprobe.d/kvm-xxxx.conf

Il faut ensuite redémarrer le module kvm. Pour cela il faut que toutes les vms soient arrêtée sur le serveur.

modprobe -r kvm-intel ou modprobe kvm-intel

On vérifie :

cat /sys/module/kvm_intel/parameters/nested
# Y ou 1

Côté hyperviseur, on est prêt !

Coté guest-OS, plus particulièrement l’hyperviseur virtualisé, il est impératif de paramétrer au niveau de l’enveloppe du guest le type de cpu à host.

Puis également, même si ce n’est pas forcément impératif, ajouter le paramètre : args: -enable-kvm dans le fichier de conf de la vm (Par exemple : /etc/pve/qemu-server/106.conf

C’est tout ! Vous voilà prêt pour virtualiser un hyperviseur…Heu mais que dis-je ? 🙂

La boucle est bouclée !

Nextcloud avec cluster KVM: GlusterFS, Redis, MariaDB et Load-Balancing

Publié le 9 juin 202015 juin 2022 par Matthieu Fontana

Nous avons vu précédemment comment monter une infra simple et créer un module scalable avec Terraform et Ansible. Maintenant nous allons tout mélanger pour faire un autre cocktail.

Présentation :

Pour le fun, je mets le graph Terraform que l’on obtient avec la commande `terraform graph | dot -Tpng > graph.png` (la sortie peut également être en .svg) :

Comme vous l’avez compris, il y a maintenant cinq modules :

2 Mariadb Master / Slave servers,
2 Redis Master / Slave servers,
2 vms in GlusterFS Cluster,
Haproxy load-balancer,
2 Nextcloud serveurs avec Nginx ou Apache et php-fpm.

Avec cette version du code j’ai forcé l’installation de nginx : j’avais mis précédemment apache par défaut. C’est configurable via les variables d’Ansible. La base de donnée est répliquée sur le slave de mariadb, j’utiliserai prochainement galera. Le cache Redis est également configuré en Master/Slave, il n’y a pas (encore) de Redis-Sentinelle pour basculer le slave en master en cas de crash du master… Le cluster GlusterFS possède deux bricks répliquées en temps réel sur deux serveurs (replica). Les serveurs Nexcloud utilisent un répertoire /var/www/html/nextcloud commun pour l’application web ainsi qu’un répertoire /var/nc_data commun pour les données du cloud. Vous l’aurez compris lorsque haproxy vous redirige sur l’un ou l’autre des deux serveurs nexcloud, les données sont immédiatement visibles et accessibles sur les deux et répliquées. Par sécurité j’ai gardé SELinux en mode enforcing, mais vous avez la possibilité de basculer en permissive via une variable Ansible.

J’ai aussi intégré dans cette version le code du réseau. J’aurais pu créer des réseaux distincts avec des routes pour que les briques puissent communiquer, cela sera dans une prochaine version… pour l’instant tout est dans un réseau 10.17.3.0/26. De même je n’ai pas eu le temps de coder l’intégration avec les serveurs d’autorité DNS, pour l’instant ça reste un POC, mais ça aussi sera pour une version ultérieure avec noms de domaines, Let’s Encrypt et Terraform en mode multi providers : libvirt et sans doute OVH hein parce qu’on est frenchies.

Requirement

Le tout fonctionne sous Fedora Server cloud image.

Vous devez avoir installé sur l’hyperviseur : Terraform, Libvirt provider et Ansible (Tout est expliqué ici)

Copie / Installation

Copiez le repo, séparez la partie Terraform de la partie Ansible dans les répertoires des applications respectives. Adaptez les variables :

variables.tf (terraform)
vars (ansible)

Comme le code est franchement long, j’ai tout mis dans un github.

A vous de jouer…

Vous avez dit … Proxmox ?

Publié le 19 mai 202015 juin 2022 par Guy VANDENBERGHE

Un autre progiciel de virtualisation ? … non pas vraiment, parlons plutôt d’une solution intégrée de virtualisation.

Poursuivre la lecture

Créer un module scalable avec Terraform

Publié le 19 mai 202015 juin 2022 par Matthieu Fontana

Je profite de la fin du confinement qui n’en finit plus de finir pour continuer de jouer avec ma récente découverte : Terraform. Comme j’en parlais dans de précédents articles, la force de Terraform vient d’une part de sa capacité à pouvoir “dialoguer” avec différents fournisseurs de Cloud, d’autre part de rendre trivial la “scalabilité” de l’infra. On peut parfaitement en cas de montée de charge sur une application, décider de créer par exemple, un serveur supplémentaire dédié au cache (un slave Redis).

Poursuivre la lecture

Cookie	Durée	Description
IDE	1 an et 24 jours	Utilisé par Google DoubleClick et stocke des informations sur la façon dont l'utilisateur utilise le site Web et toute autre publicité avant de visiter le site Web. Ceci est utilisé pour présenter aux utilisateurs des publicités qui les concernent en fonction du profil de l'utilisateur.
test_cookie	15 minutes	Ce cookie est défini par doubleclick.net. Le but du cookie est de déterminer si le navigateur de l'utilisateur prend en charge les cookies.
VISITOR_INFO1_LIVE	5 mois et 27 jours	Ce cookie est défini par Youtube. Utilisé pour suivre les informations des vidéos YouTube intégrées sur un site Web.

Cookie	Type	Durée	Description
__cfduid		1 month	Le cookie est utilisé par les services cdn comme CloudFare pour identifier les clients individuels derrière une adresse IP partagée et appliquer les paramètres de sécurité par client. Il ne correspond à aucun identifiant d'utilisateur dans l'application Web et ne stocke aucune information personnellement identifiable.
cookielawinfo-checkbox-performance		1 an	Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour stocker le consentement de l'utilisateur pour les cookies dans la catégorie «Performance».