Red Hat Enterprise Linux 5.5 : Virtualisation et interopérabilité

Posté par  (site web personnel, Mastodon) . Modéré par rootix.
Étiquettes :
17
2
avr.
2010
Red Hat
Red Hat a annoncé le 30 mars dernier la version 5.5 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises. La version précédente intégrait de nombreuses nouveautés pour une version mineure. Cette fois, Red Hat revient dans le moule, avec une stratégie de validation et d'officialisation de ces nouveautés. Nous avons donc droit à une version mineure un peu plus "classique", focalisée sur la stabilisation.

Comme depuis le début de la branche RHEL 5, de nombreuses améliorations et correctifs concernent la prise en charge de nouveau matériel et la virtualisation. Installation

L'installeur de RHEL et de Fedora, Anaconda, prend à présent en charge plusieurs points de montage NFS, ainsi que les sources situées sur des serveurs FTP protégés par mot de passe. Kickstart, l'outil permettant d'automatiser les installations, a été amélioré au niveau des rapports d'erreurs, qui sont maintenant dans le fichier anaconda.log. Toujours côté Kickstart, il est possible d'exclure un groupe de paquets plutôt qu'individuellement. L'option --hvargs, passée au chargeur de démarrage de l'installation permet de spécifier des options à Xen.

Virtualisation

RHEL 5.4 a apporté une très grosse nouveauté : l'hyperviseur KVM. Celui-ci n'est plus une avant-première technologique et est donc officiellement supporté. Il est aussi possible pour les deux hyperviseurs (Xen et KVM) d'allouer des périphériques aux machines virtuelles (PCI passthrough). Pour les systèmes utilisant Huge Pages de nombreuses améliorations de performances ont été faites du côté de libvirt, par l'activation de hugetlbfs.

Prise en charge du matériel

L'une des grosses nouveautés de RHEL 5.5 est la prise en charge de nouvelles plates-formes : Intel Nehalem EX, AMD Opteron 6000 (nom de code Magny-Cours) et IBM Power 7. Il est dorénavant recommandé d'avoir au moins 1Go de mémoire vive par processeur logique sur les systèmes x86 et x86_64. Pour un processeur Intel i920 par exemple, il est recommandé d'avoir au moins 8 Go de mémoire vive (ce processeur a 4 cœurs mais 8 threads, donc 8 processeurs logiques).

De nombreux pilotes réseau ont été mis à jour, dont les pilotes iwlwifi, e1000 (Intel), rtl8180, rtl8187, r8169 (RealTek), des pilotes pour cartes 10 Gigabit Ethernet ainsi que des pilotes pour contrôleurs de stockage de données.

Cluster et stockage de données

Le stockage des données, parlons-en avec deux améliorations concernant l'ordonnanceur CFQ (Completely Fair Queuing) et GFS2 : dans le cas de multiples processus ou thread réclamant accès au disque, CFQ avait des problèmes de performances d'entrées/sorties ; ceux-ci sont résolus et le noyau détecte automatiquement quand il doit agréger ou séparer les files d'attente. GFS2 se voit doté d'une option de montage "errors=" pour aider à la recherche d'erreurs ou de pannes. Par défaut, cette option vaut "withdraw", qui fera sortir la machine de la grappe si des erreurs d'entrées-sorties ou des erreurs de méta-données arrivent. Une deuxième option, "panic", un kernel panic sera forcé (même si l'erreur n'est pas gravissime).

Interopérabilité

OpenOffice.org a été mis à jour : au-delà des correctifs de bogues, l'important est la possibilité d'utiliser les formats OOXML de la suite Microsoft Office 2007. Il est possible de faire cohabiter RHEL 5.5 et Windows 7 grâce à Samba 3.3, présent depuis RHEL 5.4 mais dont le support a été officialisé. L'intégration avec Active Directory a été améliorée.

Diagnostic et outils système

Les programmeurs ne sont pas en reste avec la mise à jour de GDB en version 7.0.1, comprenant entre autres des améliorations pour le langage C++, pour les jeux de caractères multi-octets et la possibilité de déboguer des threads multiples individuellement et en toute indépendance. SystemTap se voit doté de nouveaux tracepoints, et il n'est plus nécessaire d'être root pour s'en servir (cette possibilité restant pour le moment une avant-première technologique). Valgrind a quant à lui été mis à jour en version 3.5.0 pour être utilisé sur des architectures supplémentaires.

Aller plus loin

  • # Web 2.0

    Posté par  (site web personnel) . Évalué à -7.

    Je lirais ça demain quand le site ne me fera plus mal aux yeux

    • [^] # Re: Web 2.0

      Posté par  (site web personnel) . Évalué à 3.

      Je n'aime pas ton commentaire donc je le moinsserai demain.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # RH Desktop ?

    Posté par  . Évalué à 2.

    Vous croyez qu'une RedHat peut faire l'affaire en Poste de travail ? (ou Centos c'est pareil).

    J'ai peur d'avoir des vieilles versions plus supportées avec (comme Firefox 3.0.x).
    Mais bon, c'est super stable (peut etre moins si on rajoute des depots rpm fusions pour rajouter la lecture dvd, java, flash...)

    Qu'en pensez-vous d'une redhat desktop ?

    Jeff

    • [^] # Re: RH Desktop ?

      Posté par  (site web personnel) . Évalué à 4.

      Et pourquoi pas une fedora ?
      Ça me semble plus adapté ... c'est d'ailleurs ce que j'utilise.

    • [^] # Re: RH Desktop ?

      Posté par  . Évalué à 3.

      J'utilisais des fedora (7,9,10,12) mais la dernière install, j'ai mis une CentOS 5.4 x64 car c'est ce qu'on utilise au niveau serveur en production (Apache, MySQL...) et surtout les mises à jour durent beaucoup plus longtemps sur CentOS que sur fedora (où il faut tout réinstaller assez souvent).... Aucun problème particulier à noter mis à part Firefox & Flash. Pour Ooo 3.x, l'installeur dispo sur le site fédora marche nickel.

      • [^] # Re: RH Desktop ?

        Posté par  . Évalué à 3.

        Une Fedora a une durée de vie de 13 mois, donc tu n'es pas obligé de réinstaller aussi souvent que ça.

        Sinon, tu peux très utiliser CentOS en desktop, les dépôts EPL, rpmfusion couvrent pas mal de besoins. Quant à ta remarque sur Firefox, RHEL a un support de 7 ans minimum (et le mainteneur des paquets Mozilla dans RHEL n'est pas un guignol loin de là), et si tu passes à une version mineure, la plupart des paquets desktop sont mis à jour (Firefox, OOo, etc ...)

        Kiki Novak a publié un bouquin destiné aux débutants ("linux aux petits oignons") et il se base sur CentOS.
        http://www.microlinux.fr/linux_aux_petits_oignons/avant-prop(...)

      • [^] # Re: RH Desktop ?

        Posté par  (site web personnel) . Évalué à 2.

        Pourquoi pas.
        Pour les packages que tu souhaites mettre à jour, utiliser le dépot de dag/rpmforge ou EPEL. Mais choisir définitivement l'un ou l'autre, mélanger les dépots, c'est une mauvaise idée.
        Soit en récupérant/installant les rpm à la main.
        Soit en configurant yum sur ces dépots et en configurant yum d'une manière qui va bien.
        Désolé, je n'ai plus d'exemple sous la main, mais de mémoire, il faut avoir un exclude=* (pour ne rien prendre par défaut) et derrière un include=liste des packages qu'on souhaite mettre à jour.

        J'utilisais ça à une époque, et ça permet en effet de garder un environnement stable, nécessitant peu de maintenance et de faire évoluer juste quelques packages (n'ayant pas trop de dépendances, sinon, c'est une mauvaise idée).

    • [^] # Re: RH Desktop ?

      Posté par  (Mastodon) . Évalué à 3.

      En général tu n'as envie (besoin?) d'une nouvelle version que sur un petit groupes d'applis. Le /opt est fait pour ça, rien ne t'empêche d'installer les dernières releases de firefox sur ta distrib.

  • # besoins et utilité

    Posté par  . Évalué à 3.

    je trouve que l'interet de cette distribution manque de clarté. J'ai dejà eut à l'utilisé en entreprise et je suis assez mitigé.

    D'abord, il y a très peu de paquet fourni sur le depot officiel. Je comrpend qu'ils veulent limiter la profusion pour garantir le support, mais je suis assez consterné de devoir me remettre au configure/make en 2010... Ou alors de devoir chercher sur rpmfind des rpm dont on ne connais pas vraiment la fabrication. Le tout avec les problèmes de dépendances que ça implique! J'ai bien essayé de brancher un depot Fedora mais sans succès...

    D'un autre coté ya un support sur le noyau et les paquets fournis, ce qui est appréciable en entreprises ou on ne rigole pas avec la chaine des responsabilité (c'est toujours agréable de reporter les fautes sur une entreprise exterieure!)

    pour conclure je dirais que cette distrib est finalement très ciblé vers une minorité d'utilisateur : ceux qui installe une machine linux sur un materiel un peu costaud et veulent que ca marche et qui de toute facon n'utiliseront pas le système de paquet et feront eux-meme l'integration aux normes de l'entreprise par exemple.


    Alors je vous dit tout ça, mais finalement chacun fait ce qu'il veux... Sauf que je commence a m'enerver d'être obliger d'utiliser cette distrib parce que c'est la "seule professionnelle" autorisé par mon daicideur, pour faire un serveur nagios ou PHP !
    Et je parle même de ceux qui me conseillent Centos!

    Donc soyons précis sur nos besoin et utilsons Debian ou Redhat ES en fonction de nos vrais besoins.


    Suis-je le seul à penser ça?

    • [^] # Re: besoins et utilité

      Posté par  . Évalué à 2.

      Non !

      Mais aucun vendeur, revendeur
      ni integrateur
      ni éditeur
      ni décideur

      Et pourtant elle tourne ! (Debian !)

      • [^] # Re: besoins et utilité

        Posté par  . Évalué à 1.

        (Debian !)

        Sauf que Debian pour son support dépend de ... Red Hat. Par exemple, kernel-xen de la dernirère Debian est resté à 2.6.18 car Red Hat utilise un 2.6.18.

        Toutes les prochaines distributions (sauf Fedora qui aura un 2.6.33) auront un 2.6.32 car ... Red Hat (et Novell aussi pour ce coup).

    • [^] # Re: besoins et utilité

      Posté par  . Évalué à 2.

      D'abord, il y a très peu de paquet fourni sur le depot officiel.

      Le "problème" est que Red Hat supporte VRAIMENT tout ce qui est forni (sauf ce qui est en "aperçu technologique").
      Red Hat n'aurait aucun problème à fournir des tonnes de paquets (il suffit de piocher dans Fedora et RHEL est un fork de Fedora).
      Il y a le dépot EPEL (supporté par le projet Fedora ; pas de support payant) mais il a été créé après RHEL 5. Pour RHEL 6 ça devrait être nettement mieux je pense (beaucoup vont "copier" de F12 à RHEL6).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.