Red Hat fait l’acquisition de Qumranet.

Après le rachat de XenSource par Citrix, en août 2008, c’est au tour de Qumranet de se faire racheter par un des grand acteurs OS, Red Hat.

Qumranet est une société spécialisée dans les solutions de virtualisation pour serveurs et bureautique. Elle est assez connu par les passionés de Linux grâce à KVM (Kernel-based Virtual Machine) une solution de virtualisation concurrente de Xen et VMWare. Qumranet est aussi à l’origine de Solid Ice, une solution de virtualisation d’ordinateur de bureautique, elle directement concurrente de Citrix. KVM, à la différence de Xen ou de VMWare, est directement intégré dans le kernel Linux depuis la version 2.6.20, et est ainsi donc supporté directement par la communauté des développeurs du kernel Linux. Il est à noter qu’il est aussi tous à fait possible de virtualiser un serveur Windows sur un serveur hôte Linux.

Ce qui est le plus étonnant, en fait pas aussi étonnant que cela, dans cette acquisition c’est que lors de la sortie de RHEL5, Red Hat avait directement intégré Xen au sein de sa distribution et en avait fait le coeur de lance de sa communication. Une RHEL5 a la possibilité d’émuler 4 instances Xen virtuelles sur un serveur hôte, tandis que la version avancée de RHEL5, se nommant RHEL AP a elle la possibilité d’émuler un nombre illimité d’instances Xen virtuelles.

Le modèle économique des souscriptions RHEL est devenu d’autant plus intéressant, car avec une RHEL5, pour le prix de 330 €, nous avons 3 RHEL5 gratuites (le serveur RHEL5 hôte ne doit s’occuper que d’émuler les 4 instances Xen virtuelles). Pour une RHEL AP, le modèle économique est encore plus intéressant, car pour 1500 €, le nombre de serveurs RHEL5 gratuits est illimité, mais par contre l’utilisation d’une RHEL AP ne s’effectue que dans des infrastructures complexes nécéssitants de la haute disponibilité (SAN, ISCSI ou fibre), un distributeur de “lock” centralisé ou encore Red Hat Cluster Suite.

Red Hat avait poussé encore plus loin l’intégration de Xen dans ses solutions orientés vers les entreprises ayant un grand parc informatique par le biais de RHN 5 (Red Hat Satellite pour les intimes). Il est possible directement depuis le satellite de faire des installations (kickstart), d’effectuer du provisionning et le management d’instances virtuelles para-virtualisées sur un serveur hôte RHEL5. L’on regrettera tous de même que le déploiement des instances Xen virtuelles ne soient faisable que sous la forme de fichiers images et non pas directement dans une partition LVM.

Tous cela pour vous dire (et c’est en cela que ce rachat de Qumranet n’est pas aussi étonnant) que Xen, produit de XenSource, était marié avec les produits de Red Hat. Mais déjà, il y a deux ans de cela, lors de ma recontre avec Sophie Arras, Channel Manager du Benelux, on parlait d’intégration d’autres hyperviseurs et justement de KVM. Sûrement qu’à l’époque un rachat de XenSource par Red Hat avait échoué et que Red Hat se préparait au rachat de XenSource par un de ses concurrents.

Citrix, lors du rachat de XenSource, avait déjà abordé la volonté d’aller vers la virtualisation de la bureautique, car à peu près 30 millions d’employés utiliseront des postes de travail virtuels, ce qui représente un marché d’environ 1 milliard de dollars, et ce marché ne fera que croître. Justement, au Luxembourg, patrie de votre interlocuteur, un cadre légal oblige les sociétés PSF (Prestataire du Secteur Financier) a avoir une solution de résilience en cas de sinistre, et cela ne s’applique pas qu’aux serveurs mais aussi aux positions de travail des employés. Encore aujourd’hui les solutions de résilience de postes de travail sont des postes de travail dédiés et mutualisés, mais l’arrivé des postes de travail virtuel va grandement réduire les coûts et augmenter les ROI.

Les questions qui restent encore en suspend par rapport à ce rachat :

– est-ce que Xen va continuer a être maintenu dans l’absolu sur les solutions Red Hat (allons-nous devoir réinstaller tous nos guest 0-0 d’ici quelques années) ?
– Comment va se positionner VMWare dans la course à la virtualisation intégrée directement aux OS ? Ne pas oublier que VMWare utilise un Red Hat strippé.
– Comment va se positionner Windows sur un marché qui sait autant gérer la virtualisation de Linux que de Windows, alors que son produit de virtualisation ne sait gérer que du Windows.

Quelques chiffres clés pour les ROI qu’offre RHN

Il y a 2 ans de cela, je me suis retrouvé devant une problématique de gestion de croissance d’un parc informatique. Nous avions en totalité environ une cinquantaine de serveurs, dont la plupart étaient sous Linux. Comme dans chaque startup l’homogénéisation n’était pas notre fort, suivant les humeurs des sysadmin l’on pouvait se retrouver avec des Debian, des Gentoo, des Centos ou encore des Suse.

Il n’est pas sans vous dire que la gestion quotidienne de ce parc était horrible :

  • les installations prenaient un temps fous, car nous n’avons pas d’images (releases) de serveurs cibles.
  • l’administration quotidienne était longue et demandait d’avoir un personnel connaissant la plupart des distributions (vive la guerre des standard dans l’opensource…).
  • les mises à jour étaient problématiques, car là aussi l’on ne pouvait, par exemple, pas se fier sur la stabilité des développeurs de certaines distribution.
  • Créer des images et réinstaller un serveur en cas de panne grave était aussi long et difficile vu que nous n’avions déjà pas d’installation uniformes.

Un administrateur système pouvait prendre :

  • 0,5 à 1 jour / homme pour l’installation et la réinstallation d’un serveur.
  • 1 jour / homme par mois par serveur pour les mises à jour.
  • 0,5 jour / homme pour l’administration quotidienne.

Rien que pour l’administration de 50 serveurs 1 administrateur système ne suffisait pas, nous avions une équipe de 2 sysadmin.

De plus, vu que nous n’avions pas des outils simples pour effectuer des processus de “Change Management” et de “Release Management“, nous n’avions pas la garantie qu’après une mise à jour un serveur repartirai et que nous pourrions au cas où il ne repartirai pas le restaurer à l’identique.

Heureusement pour nous, un gros projet a pu m’aider à trouver les arguments financier nécessaires pour remettre de l’ordre dans tous cela. Ce projet commençait avec un parc de 50 serveurs sous Linux et avec 1 nouveau serveur à installer chaque semaine. Il n’était pas possible pour nous de continuer à travailler avec nos anciennes méthodes et surtout nous aurions du embaucher beaucoup plus de personnel pour gérer ce parc.

Je me suis donc penché sur un outil qui me permettrait d’installer des serveurs comme si je construisait mon infrastructure avec des briques.

L’outil devait :

  • nous permettre d’installer très rapidement un serveur à l’identique d’un serveur de production.
  • nous faciliter l’administration système avec une gestion centralisée de ceux-ci.
  • nous faciliter les déploiements des mises à jour avec une gestion centralisée de celles-ci.
  • nous permettre d’effectuer des retours dans le temps très rapide, si une mise à jour c’était mal déroulée, ou si un changement n’avait pas été maîtrisé correctement.

Au bout de quelques temps, je me suis penché sur RHN Satellite de Red Hat qui offrait toutes ces possibilités. Depuis ce jour, RHN Satellite est devenu un outil incontournable dans la gestion de notre parc informatique. Les améliorations se sont vues tous de suite, et nous ont permis de nous libérer du temps sont avoir pourtant à recruter d’avantage de personnel.

Suite à l’utilisation de RHN Satellite, un administrateur système prend :

  • 0,0625 jour / homme pour l’installation et la réinstallation d’un serveur.
  • 0,5 / homme par mois par serveur pour les mises à jour.
  • 0,25 jour / homme pour l’administration quotidienne.

Si vous avez un parc informatique important à gérer et que vous vous retrouver devant les mêmes problématique auxquelles j’étais confronté, je vous conseille d’étudier de façon sérieuse ce produit.

CFIA – Component Failure Impact Analysis

CFIA est un processus définis originalement par IBM dans les années 80 pour améliorer la disponibilité des services. Ce processus analyse les configuration hardware/software pour déterminer les impacts réels si un des composants vient à ne plus fonctionner. CFIA fait maintenant parti des bonnes pratiques ITIL et est utilisé pour documenter et étendre la résilience d’infrastructures larges. Principalement l’on pourra retrouver l’utilisation de CFIA dans les processus de “Incident Management“, “Problem Management“, “Change Management“, “Configuration Management“, “Availability Management” et “Capacity Management“.

CFIA permet donc :

  • d’identifier les CIs qui peuvent causer une panne.
  • de localiser les CIs qui n’ont pas de sauvegardes.
  • d’évaluer les risques d’une panne pour tous les CIs.
  • de localiser des SPOF.
  • de justifier de futurs investissements.
  • d’assister à la création et la maintenance de la CMDB.

Pour développer un CFIA, il vous suffit d’utiliser un tableur du type Excel et de suivre les étapes suivantes :

  • Sélectionner un “Service IT” et répertorier les CIs (normallement tirer du processus de “Configuration Management“) qui en dépendent.
  • Lister les CIs en vertical (un CI par ligne) et placer le “Service IT” en horizontal.
  • Pour chacun des CIs placer :
  1. un “X” si la panne de ce CI peut causer un arrêt du “Service IT”.
  2. un “A” si le CI a une sauvegarde à chaud.
  3. un “B” si le CI a une sauvegarde intermédiaire.
  • Examiner maintenant tous les “X” et ensuite les “B”, en vous posant les questions suivantes :
  1. Est-ce que ce CI est un SPOF ?
  2. Quel est l’impact business si le CI vient à avoir une panne ? (Combien d’utilisateurs seront impactés ? Quel serait le coût de cette panne pour le business ?)
  3. Quel est la probabilité de panne ?
  4. Est-il possible de combler ce SPOF pour minimiser l’impact ?

Vous avez maintenant une matrice CFIA où chaque “X” et “B” sont des CIs à risques. Vous pouvez aussi considérer que les procédures de “recovery” sont des CIs dont le “Service IT” dépend. De rajouter les procédures en tant que CIs d’un service IT, vous permez d’examiner autant l’organisationnel que la partie infrastructure.

  • Comment répondons-nous en cas de panne sur un CI ?
  • Quels sont les procédures à suivre en cas de panne sur un CI ?
  • Est-ce que ces procédures existent au format numérique ou papier ?
  • Est-ce que ces procédures peuvent être améliorées ?
  1. Est-ce que ces procédures peuvent être améliorées en formant les techniciens ?
  2. Est-ce que ces procédures peuvent être améliorées par de nouveaux outils ? (Est-ce que ces procédures peuvent être automatisées ? Est-ce que des maintenances préventives peuvent limiter les pannes ? )

Si un CFIA complet est mis en place, normalement le “Service Desk” devrait voir sa réactivité augmentée pour les processus “Incident Management” et de “Problem Management“.

Comment créer un diagramme RACI

Un diagramme RACI, ou encore matrice RACI, est utilisé pour décrire les rôles et responsabilités, de différentes équipes et personnes, sur un projet ou sur des processus courants. Il est très pratique pour éclairer les R&R des projets sur lesquelles plusieurs équipes travaillent.

Le diagramme RACI décompose les tâches en quatres type de responsabilités, qui sont alors attribuées à différents rôles. Ces quatres types de responsabilités sont :

  • Responsible (Réalisation) : Les R sont ceux qui réalisent l’action. Ces équipes, ou personnes, peuvent être responsable de plusieurs tâches. Si les R ne remplissent pas leurs objectifs, c’est le A qui assume.
  • Accountable (Approbation) : Celui qui doit rendre des comptes sur l’avancement d’un projet. Il ne peut y avoir qu’un seul A par tâche.
  • Consulted (Consultation) : Ceux qui sont consultés pour la réalisation de la tâche.
  • Informed (Information) : Ceux qui sont informés de l’évolution du projet.

Vous pouvez trouver ci-dessous un exemple de diagramme RACI, qui est en fait une matrice en deux dimensions. Afin de créer un diagramme RACI, il faut nommer de façon claire les tâches à effectuer et de façon non générique (afin d’éviter les confusions). Si possible, placer toujours les A et les R le plus à gauche du diagramme RACI. Chaque ligne doit au moins contenir un A et un R, même si ce sont les mêmes personnes. La présence de deux R pour la même tâche signifie une duplication de l’éxécution de celle-ci, il est alors préférable de découper cette tâche en sous tâches.

Un diagramme RACI apporte plusieurs avantages :

  • Les rôles et responsabilités sont clairement définis.
  • Cette méthode encourage le travail en équipe, réduit l’incertain et éprouve la communication entre les différentes équipes.
  • La redondance des tâches est éliminées et cela réduit l’obligation de former des gens au mêmes tâches.
  • La productivité est augmentée.