Virtualisation des serveurs

La configuration de notre infrastructure virtuelle est maintenant terminée, nous disposons de deux ressources ESX gérées par un serveur Vcenter et connectées à notre réseau. Nous pouvons maintenant héberger sur cet environnement des machines virtuelles.

5.3.3.1.1. Physical to Virtual (P2V)

La solution de la virtualisation a été choisie car elle nous permet de virtualiser des applications tournant sur de vieux serveurs. Cette technique offre la possibilité des séparer l’application de la machine physique sur laquelle elle tourne. Nous allons voir par quel procédé d’un serveur physique nous arrivons à une machine virtuelle.

5.3.3.1.1.1 Utilitaire VMware converter

VMware Converter est un utilitaire développé par VMware qui permet de virtualiser une machine physique.

D’une manière générale nous avons virtualisé tous les serveurs contenant une application métier pour laquelle nous ne disposions pas des sources pour les installer manuellement sur une machine virtuelle. Cette manipulation nous a permis de les maintenir dans leur environnement. Par exemple ‘Oenobiol3’, serveur de comptabilité tournant sous windows 2000 serveur. Serveur pour lequel une nouvelle allocation de ressources (CPU/RAM), aurait du nécessiter l’achat d’un nouveau serveur, un passage de l’OS de sa version 2000 à 2003, l’achat d’une prestation d’accompagnement de la migration par un expert. Grâce à la virtualisation nous avons pu allouer plus de ressource à ces serveurs sans toucher à leurs configurations.

Avec l’expert technique nous avons du élaborer une stratégie de migration des serveurs. La difficulté réside dans le fait qu’une fois la machine physique virtualisée, si on venait à lancer l’image de celle-ci sous forme d’une VM, les deux machines seraient en conflit. En effet elles disposeraient du même SID (identifiant de sécurité de windows permettant d’identifier de manière unique une entité), ce qui risquerait de déstabiliser les deux systèmes.

Nous avons fait aussi en sorte qu’aucun utilisateur ne soit connecté à celle-ci durant l’opération de virtualisation, pour figer l’état du système et ne pas avoir de décalage entre la machine physique et son image sous forme de VM.

La procédure a été définie comme suit :

- Pour s’assurer qu’aucuns utilisateurs ne puissent se connecter au serveur, nous avons changé l’adresse IP de la machine.

- Nous avons lancé la procédure de virtualisation du serveur, - Nous avons éteint (déconnecté) la machine physique. - Lancer la machine virtuelle,

- Alloué à la VM les identifiants réseaux de l’ancien serveur.

- Vérifié auprès des utilisateurs qu’ils avaient à nouveau accès à l’application. Cette opération de virtualisation des serveurs physiques c’est déroulé sans incident. Nous avons pu passer à l’étape suivante qui consistait à créer de nouvelles

machines virtuelles pour héberger les applications qui se partagent un même serveur. Par exemple la base de données Boileau est sur la même machine que le

serveur web de l’application. En dissociant ces composants sur des VM différentes, cela permettra de les isoler et en cas de problème d’annuler l’impact de la

défaillance d’une application sur les autres applications. 5.3.3.1.2. Ajout de nouveau serveur virtuel

Comme il a été évoqué dans la partie précédente, nous avons du créer de nouveau serveur virtuel.

En plus des serveurs virtualisés deux nouveaux serveurs ont été créés :

- Oenobiol 4, serveur alloué pour l’hébergement d’une base de données Oracle et une nouvelle application (Klee).

- Oenobiol6, pour l’hébergement d’une nouvelle application (Jeeves). 5.3.4 Tests fonctionnels

- Arrêt d’un ESX et vérification que les ressources supportées par cet ESX basculent bien sur l’autre ESX. Ce test peu être réalisé en arrêtant un des deux ESX.

- Vérifications du fonctionnement de la sauvegarde et de la restauration des données. Test réalisée à partir du serveur de sauvegarde sur plusieurs VM. Les tests ont fonctionnés parfaitement et le résultat obtenu était satisfaisant. Nous sommes à même de pouvoir restituer des données endommagées sur un serveur virtualisé. La condition de persistance des données est donc assurée.

Quelques erreurs ont été relevées suite à ces tests. Ces erreurs ont été consignées dans le Procès verbal de recette que vous trouverez en annexe 7 de ce document. Ces erreurs ont fait l’objet de deux fiches incidents qui ont été résolu par la suite.

5.3.5 Transfert de compétences

Durant toute la phase de réalisation du projet, nous avons suivi les experts et participé à la mise en place des différents composants. A la fin de chaque étapes importante du projet un temps à été réservé pour de la formation. Ce temps représente 2 jours/homme. Ce transfert a été réalisé en deux étapes :

- 1 jour en parallèle du projet

- 1 jour trois semaines après la fin du projet.

L’objectif initial était dans un premier temps de permettre à l’utilisateur de se familiariser avec l’environnement technique. Suite à cette phase de pratique, lui permettre de collecter des questions et au retour du formateur, de pouvoir poser ces questions et ainsi pousser plus loin la phase d’expertise sur le système.

5.3.6 Bilan de l’opération

Même si dans l’ensemble le système semble gagner en complexité, la contre partie offerte par la gestion centralisé, le gain de performance de l’ensemble des serveurs d’application contrebalance aisément ce handicap.

Un autre avantage : le temps de déploiement d’un nouveau serveur. Auparavant, lorsque nous voulions déployer un nouveau serveur, il fallait commander la machine chez notre revendeur. Le temps de livraison était alors dans le meilleur des cas d’une dizaine de jours. Avec la virtualisation, l’opération de déploiement d’un nouveau serveur est instantanée. Ce nouveau paramètre permet de proposer aux utilisateurs la mise à disposition rapidement de solutions d’environnements de développement.

La seule contrainte étant économique : les licences qui auparavant étaient incluses dans le prix d’achat des serveurs physiques (Licence OEM) doit faire maintenant l’objet d’un achat supplémentaire (Licence Open).