Category Archives: Various

Monitoring de Xen via SNMP

Various, , ,

Je suis tombé sur un blog intéressant où le monitoring d’instances Xen par le biais de Cacti – SNMP est décrite. Le monitoring ne s’effectue pas directement dans l’instance virtuelle, par le biais d’un monitoring Linux courant, mais au niveau du serveur hôte.

Le premier script “xen_cloud_stats.pl” est à placer sur le serveur hôte et qui sera lancé à chaque requête SNMP par le biais d’une MIB étendue. En détail “xen_cloud_stats.pl” va faire appel à la commande xentop afin de monitorer le Dom0 et les DomU présents sur le serveur hôte Xen. Nous vous conseillons de placer ce script dans /usr/sbin/ et de ne le rendre exécutable uniquement par root.

Afin qu’il puisse s’éxécuter il vous faut ensuite modifier la configuration SNMP du serveur hôte et de rajouter cette ligne à la fin du fichier de configuration snmpd.conf. N’oublier pas de relancer SNMP.

extend xen-stats /usr/sbin/xen_cloud_stats.pl

Nous devons maintenant, configurer Cacti afin de pouvoir récupérer les informations par le biais de requêtes SNMP classiques. Si vous avez un serveur sous RHEL4 ou Centos4, il vous faudra récupérer le fichier /usr/share/snmp/mibs/NET-SNMP-EXTEND-MIB.txt d’un serveur sous RHEL5 ou Centos5 et le mettre dans le répertoire /usr/share/snmp/mibs/ de votre serveur actuel. net-snmp sous RHEL4 ou Centos4 ne supporte pas nativement la MIB EXTEND. Si vous effectuer cette opération, n’oubliez pas de relancer SNMP.

Il vous suffit ensuite d’importe les 3 fichiers restants dans Cacti afin de pouvoir mettre sous monitoring vos instances Xen. Les scripts ont été adaptés pour qu’ils tournent autant sous PHP4 que PHP5, de plus des petits bugs dans les scripts Cacti ont aussi été corrigé dans cette version.

Monitoring Xen via SNMP

Red Hat fait l’acquisition de Qumranet.

Various,

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

Various

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

Various

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“.