• Aucun résultat trouvé

Industrialisation du déploiement de machines virtuelles

N/A
N/A
Protected

Academic year: 2021

Partager "Industrialisation du déploiement de machines virtuelles"

Copied!
110
0
0

Texte intégral

(1)

HAL Id: dumas-01160091

https://dumas.ccsd.cnrs.fr/dumas-01160091

Submitted on 4 Jun 2015

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Industrialisation du déploiement de machines virtuelles

Nicolas Olive

To cite this version:

Nicolas Olive. Industrialisation du déploiement de machines virtuelles. Système d’exploitation [cs.OS]. 2014. �dumas-01160091�

(2)

CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL DE TOULOUSE

MEMOIRE

présenté en vue d'obtenir le DIPLOME D'INGENIEUR CNAM

SPECIALITE : INFORMATIQUE OPTION : SYSTEMES D'INFORMATIONS

par

OLIVE, Nicolas

___________________

Industrialisation du déploiement de machines virtuelles

Soutenu le 15 janvier 2014 _________________

JURY PRESIDENT : Professeur Anne Wei MEMBRES : Monsieur Thierry Millan

Monsieur Bertrand Raiff Monsieur Nicolas Cros Monsieur François Sarron

(3)

2

Remerciements

Ce mémoire est l’aboutissement de plusieurs années d’études au sein du CNAM. Tout d’abord, je tiens à remercier l’ensemble du corps enseignant de Toulouse, dont Monsieur Raiff qui a suivi mon étude et a été moteur dans l’aboutissement de sa réalisation. Je souhaite également remercier le Président du jury ainsi que ses membres.

Ce mémoire est la concrétisation de mon expérience professionnelle, pour cela je remercie globalement la société CLS et plus spécifiquement Monsieur Cros. C’est en effet dans cette société que j’ai commencé le cursus Ingénieur du CNAM dès le début de mon emploi en tant que technicien bureautique. Dans une relation gagnant-gagnant, et avec le support des plusieurs personnes qui se reconnaitrons, j’ai pu obtenir un poste d’ingénieur et avoir une responsabilité qui me permet de m’épanouir aujourd’hui professionnellement.

(4)

3

Table des matières

Remerciements ... 2 

Table des matières ... 3 

Introduction ... 6 

I  CONTEXTE ... 7 

I.1  COLLECTE LOCALISATION SATELLITES ... 7 

I.1.1  Présentation du CNES ... 8 

I.1.2  Présentation de l’IFREMER ... 9 

I.1.3  Présentation de CLS ... 10 

I.2  LES APPLICATIONS ... 11 

I.3  ORGANIGRAMME ... 13 

I.3.1  Organisation générale de CLS ... 13 

I.3.2  La Division Système d’Information ... 15 

I.4  LE SYSTEME D’INFORMATION ... 16 

I.4.1  Généralité ... 16 

I.4.2  La virtualisation ... 17 

I.4.2.1  Définition ... 17 

I.4.2.2  Historique ... 17 

I.4.2.3  Les solutions techniques ... 18 

I.4.2.4  La solution VMWare ... 20 

I.4.2.4.1  Généralités ... 20 

I.4.2.4.2  Gestion des ressources ... 23 

I.4.2.5  La virtualisation au sein de CLS ... 26 

I.4.3  La démarche ITIL ... 28 

I.4.3.1  Généralités ... 28 

I.4.3.2  Les étapes du cycle de vie ITIL v3 ... 28 

I.4.3.3  ITIL au sein de CLS ... 29 

II  PROBLEMATIQUE ET BESOINS ... 30  II.1  PROBLEMATIQUE ... 30  II.2  BESOINS ... 33  II.2.1  Industrialiser ... 33  II.2.2  Homogénéiser ... 33  II.2.3  Objectifs ... 34 

III  ETUDE PRELIMINAIRE ... 36 

III.1  ETAT DES LIEUX ... 36 

III.1.1  Parc serveurs virtuels ... 36 

III.1.2  Définitions de classes ... 37 

III.1.2.1  La classe système ... 37 

III.1.2.2  La classe applicative ... 38 

III.1.2.3  La classe service ... 38 

III.2  ITIL ET LE DEPLOIEMENT ... 39 

III.3  SOLUTIONS ENVISAGEES ... 40 

III.3.1  Outils de gestion des configurations ... 40 

III.3.2  Modèles de machine virtuelle ... 40 

IV  SOLUTION CHOISIE ... 42 

IV.1  LE FORMAT OVF ... 42 

IV.2  INTERET DU FORMAT OVF ... 43 

(5)

4

IV.4  PAQUETAGE OVF ... 45 

IV.4.1  Structure ... 45 

IV.4.2  Conformité (OVF Descriptor) ... 46 

IV.4.3  Enveloppe (OVF Descriptor) ... 47 

IV.5  OUTILS POUR CREER DES OVF ... 50 

IV.5.1  VMWare Studio ... 51 

IV.5.2  VMWare OVF Tool ... 52 

IV.5.3  Virtual Center ... 52 

V  REALISATION DU PROJET ... 53 

V.1  SOCLE TECHNIQUE ... 53 

V.1.1  Configuration de base ... 53 

V.1.2  Définition du socle technique ... 54 

V.1.3  Gestion des versions ... 55 

V.1.4  Choix de la version hardware ... 57 

V.2  MAQUETTE ... 58 

V.2.1  Création de l’image maîtresse ... 58 

V.2.1.1  Choix de l’architecture ... 58  V.2.1.2  Type d’installation ... 59  V.2.1.3  Gestion de parc ... 59  V.2.1.4  Installation ... 60  V.2.1.5  Validation ... 63  V.2.2  Création OVF ... 64 

V.2.3  Test déploiement OVF ... 66 

V.2.3.1  Déploiement sur des hyperviseurs type 2 ... 66 

V.2.3.2  Déploiement sur des hyperviseurs de type 1 ... 67 

V.2.3.3  Conclusion sur la portabilité testée ... 69 

V.3  ORGANISATION ... 69 

V.3.1  Gestion des modèles ... 69 

V.3.2  Stockage des OVF ... 71 

V.3.3  Interface web ... 71  V.4  MISE EN PRODUCTION ... 74  V.4.1  Le modèle système ... 74  V.4.2  Le modèle applicatif ... 74  V.4.3  Le modèle service ... 79  V.4.3.1  Mise à jour ... 81 

V.4.3.2  Exemple de supervision attachée ... 81 

VI  BILAN DU PROJET ... 83 

VI.1  ETAT ACTUEL DU PROJET ... 83 

VI.2  BILAN ... 85 

VI.3  PERSPECTIVES ... 86 

Conclusion ... 88 

Bibliographie ... 89 

Table des annexes ... 90 

Annexe 1 Création des paquets CLS-RELEASE ... 91 

Annexe 2 Notes d’installation du template CentOS 6 ... 93 

Annexe 3 Notes d’installation du template Iridium ... 99 

(6)

5

Liste des figures et tableaux ... 106 

(7)

6

Introduction

La société CLS est spécialisée dans la localisation et la collecte de données satellite. Pour répondre à ces activités, elle dispose d’applications avec des engagements de disponibilités 24h/24, 7j/7 avec certains de ses clients. Pour maintenir ce niveau de service, la direction informatique définit, conçoit et assure le bon fonctionnement des infrastructures hébergeant ces applications.

Avec son centre de données en forte évolution lié à l’augmentation constante de l’activité, donc du nombre de serveurs, la direction informatique se retrouve confrontée à des problématiques de gestions et de déploiements de serveurs, majoritairement virtuels. Le choix de l’étude d’une solution d’industrialisation a été soumis dans le domaine de la virtualisation, car il s’agit de la technologie en forte croissance et dont la récente utilisation permet d’entrevoir de nouvelles possibilités.

Dans une première partie, nous présenterons le contexte dans lequel j’ai réalisé ce projet. Nous ferons ensuite une analyse de la problématique et des besoins exprimés par l’équipe système, que nous poursuivrons avec un état des lieux et une explication sur le choix de la solution pour répondre aux besoins, à savoir l’utilisation de modèle au format OVF. Pour la réalisation du projet, elle sera décrite en quatre sous parties : la définition d’un socle technique, la réalisation d’une maquette, la mise en place organisationnelle et enfin la mise en production de la solution. Avant de conclure, nous présenterons les résultats obtenus ainsi que des perspectives sur la technologie OVF.

(8)

7

I Contexte

En premier lieu, nous allons présenter CLS (Collecte Localisation Satellites) qui est la société dans laquelle je travaille et dans laquelle j’ai réalisé mon mémoire. Dans un second temps, nous nous intéresserons brièvement aux différentes applications de CLS. Enfin, nous décrirons l’organisation de CLS avant d’en présenter son système d’information.

I.1 Collecte Localisation Satellites

CLS, filiale du Centre National d'Études Spatiales (CNES), est né en 1986 du regroupement d’actionnaires suivant : le CNES, l’IFREMER (Institut Français de Recherche pour l’Exploitation de la MER) et de banques françaises comme illustré par la figure 1.

Figure 1 : CLS en chiffre

CLS compte environ 400 salariés dont 260 présents au siège qui est situé en périphérie de Toulouse, à Ramonville Saint-Agne. CLS possède des filiales en France, et est également représenté internationalement avec des filiales aux Etats-Unis, au Pérou, en Indonésie et en Espagne. Des bureaux annexes servant de relais pour les utilisateurs locaux sont également implantés dans certains endroits stratégiques comme au Japon, en Russie, en Corée du Sud, au Chili ou encore en Australie.

(9)

8 La figure 2 représente CLS à l’échelle mondiale.

Figure 2 : CLS à l'échelle mondiale

I.1.1 Présentation du CNES

Avec 57% de ses parts détenues par le CNES, CLS est une filiale du CNES. Créé sous l'impulsion du Général de Gaulle, le 19 décembre 1961, le CNES est chargé d’élaborer et de proposer au gouvernement la stratégie spatiale française et de la mettre en œuvre. De 1961 à 1981, le CNES va être le moteur de l'Europe spatiale. Durant ces années, les structures indispensables à un programme spatial sont mises en place : lanceurs, satellites, ensemble de lancements, centres d'opérations et réseau de stations de contrôle, laboratoires. Parallèlement, une industrie spatiale compétente et dynamique voit le jour en France. C’est au sein de l'Agence Spatiale Européenne (ESA) que le CNES a contribué à la création de la fusée Ariane, et devient de ce fait une grande agence, où de nombreux programmes à vocation internationale lui sont confiés. En effet, le CNES représente la France à l'ESA et il recadre avec succès ses activités sur un programme national ambitieux orienté vers les applications. En 1977, les directives du gouvernement mettent l'accent sur les missions prioritaires de l'établissement qui sont notamment de qualifier le plus rapidement possible la fusée Ariane et lancer sa production. Cet objectif est atteint le 24 décembre 1979 avec le lancement réussi d'Ariane 1 de la base de Kourou. Une autre mission

(10)

9

prioritaire est l'étude interne d'un programme national de satellites d'observation de la Terre. Ce sera le projet du satellite Spot dont l'étude est réalisée au Centre Spatial de Toulouse. Les activités du CNES en faveur de la recherche scientifique ne diminuent pas mais les réductions de budget orientent les réalisations vers des programmes en coopération et vers des expériences embarquées sur des satellites de la NASA, de l'URSS et de l'ESA. On retiendra deux projets marquants qui sont Argos et TOPEX-Poséidon. C’est le projet Argos qui a abouti à la création de la filiale CLS.

Le CNES est composé du Centre Spatial de Toulouse (CST), de Kourou en Guyane française et d’Evry. Les activités du centre de Toulouse sont le management des projets, les études de recherche et technologie, la gestion des centres d'opération pour les mises à poste et la gestion en orbite, la mise en œuvre des moyens informatiques et d'études mathématiques et les supports administratifs, logistiques et de communication. Il regroupe environ 1500 personnes dont une majorité d'ingénieurs et cadres.

Le centre de Kourou est dénommé "port spatial" de l'Europe, depuis lequel les lanceurs Ariane ou depuis peu Soyouz et Vega sont envoyés dans l'espace. Le site de Kourou possède une position géographique exceptionnelle, proche de l'équateur, qui autorise des lancements vers l'est (en bénéficiant de la vitesse d'entraînement de la Terre) ou au nord dans des conditions maximales de sécurité. En effet, le lanceur ne survole aucune terre avant 4000 km.

Enfin, la Direction des Lanceurs s'installe dans la ville nouvelle d'Évry en 1974 à la fermeture de Brétigny-sur-Orge. Elle assure le développement des lanceurs Ariane et elle prépare l'avenir en travaillant sur les nouvelles générations de lanceurs et de systèmes de propulsion.

I.1.2 Présentation de l’IFREMER

L’IFREMER, l'Institut Français de Recherche pour l'Exploitation de la MER, est un établissement public à caractère industriel et commercial sous la tutelle du ministère de l’Écologie, de l’Énergie, du Développement durable et de la Mer et du ministère de l'Alimentation, de l’Agriculture et de la Pêche. Ses missions principales sont de connaître, d’évaluer et de mettre en valeur les ressources des

(11)

10

océans et permettre leur exploitation durable. Elles sont aussi d’améliorer les méthodes de surveillance, de prévision d'évolution, de protection et de mise en valeur du milieu marin et côtier. Elles favorisent également le développement économique du monde maritime.

L’IFREMER entretient des relations internationales à travers diverses coopérations. En effet, l'Ifremer participe activement aux travaux de l'Union Européenne (programmes de la direction générale de la Recherche et de la direction générale de la Pêche) et au Marine Board de la Fondation Européenne de la Science (ESF). Il contribue aux programmes internationaux de recherche (étude du climat, de l'environnement et de la biodiversité). Il anime aussi de nombreux accords bilatéraux (Japon, États-Unis, Canada, Australie, pays européens).

L'IFREMER est présent dans 26 sites répartis sur tout le littoral métropolitain et dans les DOM-TOM. L'Institut est composé de 5 centres (Boulogne, Brest, Nantes, Toulon et Tahiti), d'un siège social (Issy-les-Moulineaux) et d'une vingtaine de départements de recherche rattachés à ces centres.

I.1.3 Présentation de CLS

CLS, Collecte Localisation Satellites, est spécialisée dans la localisation et la collecte de données satellites, l’observation et la surveillance des océans mais également la géolocalisation de mobiles terrestres par satellite. CLS fournit à ses clients des services opérationnels et des solutions clés en main, issus de l'exploitation de systèmes spatiaux mondiaux, articulés autour de trois grands axes :

- La surveillance environnementale

o Surveiller l'océan.

o Préserver les grandes espèces migratrices. o Définir et évaluer des règlementations publiques. o Soutenir les politiques industrielles maritimes.

(12)

11

- La gestion durable des ressources marines

o Administrer une pêche raisonnée.

o Lutter contre la pêche illicite, non déclarée, non réglementée. o Modéliser les écosystèmes marins et mettre en place un

aménagement des pêches.

o Aider au développement des pêcheries locales.

- La sécurité maritime

o Suivre les navires à l'échelle du globe. o Surveiller des zones d'intérêt stratégique. o Déclencher et coordonner des actions en mer.

I.2 Les applications

Comme le montre la figure 3, une grande partie du résultat d’exploitation de CLS est réalisée par la collecte et localisation de données et l’océanographie spatiale.

(13)

12

Alors que l’océanographie spatiale est utilisée principalement dans le cadre de la surveillance environnementale, la collecte et localisation est, elle, beaucoup plus diversifiée. En quelques mots, voici quelques exemples d’applications des systèmes exploités ou opérés par CLS :

 Argos : Système de localisation et de collecte de données par satellite dédié à l'étude et à la protection de l'environnement de notre planète. CLS traite les données des 21 000 balises Argos réparties sur les mers et continents du globe. L’entreprise décode les signaux reçus et les transmet à ses clients. Ainsi, un biologiste peut depuis son bureau observer la migration de l’espèce qu’il étudie, ou encore un ministère des affaires maritimes peut suivre l’ensemble des mouvements d’une flotte de pêche et un patron d’armement peut surveiller les pérégrinations de ses bateaux de fret où qu’ils soient dans le monde.

 Iridium : CLS est qualifiée VAR1 Iridium, elle est donc habilitée à traiter,

intégrer et valoriser des données Iridium. L’application CLS propose ainsi de la géolocalisation en temps réel avec une couverture totale du globe terrestre en s’appuyant sur la constellation Iridium équipées de 66 satellites. CLS utilise Iridium en voie montante et descendante ce qui permet d’avoir une localisation régulière ou à la demande. Elle est utilisée dans le cadre de la pêche pour la surveillance des ressources halieutiques, mais aussi pour le suivi des courses de bateaux comme le Vendée Globe, la Solitaire du Figaro ou encore la très célèbre Route du Rhum.

 CLS est une entreprise spécialisée en Océanographie Spatiale. Pour ce faire elle opère 80 instruments embarqués à bord de près de 80 satellites. Grâce à ces données, les 90 océanographes de l’entreprise sont capables de mesurer le niveau moyen des mers du globe au millimètre près. Ces données sont indispensables aux climatologues et météorologues du monde entier. En dehors de ce paramètre, la température, les courants

(14)

13

ainsi que la couleur de l’eau sont envoyés aux scientifiques du monde entier.

 Radar : Pour compléter les deux familles de systèmes précédemment citées, dans les années 2000, CLS a voulu se doter de la capacité de surveiller les activités maritimes. Elle possède ainsi la capacité d’acquisition et de traitement d’images satellites haute résolution et peut donc offrir à ses clients des solutions de surveillance en temps quasi réel, de jour comme de nuit. L’interprétation experte des images satellites radar acquises par CLS permet de lutter contre la pêche illégale, de surveiller le trafic maritime, de lutter contre les actions illégales mais également de mesurer la hauteur des vagues, ou encore de « voir » le vent et soutenir ainsi l’industrie éolienne offshore.

I.3 Organigramme

Nous allons présenter ici l’organisation interne de CLS, qui est divisée en sept directions.

I.3.1 Organisation générale de CLS

Outre les directions administratives telles que la Direction Générale (DG), la Direction Financière (DF) et la Direction des Ressources Humaines (DRHC), nous allons présenter les directions métiers de CLS.

Comme le montre la figure 4, la Direction Technique (DT) forme un axe sur lequel reposent les « business units» de la diffusion commerciale des produits à savoir les directions Collecte et Localisation (DCL), Océanographie Spatiale (DOS) et Application Radar (DAR).

(15)

14

Figure 4 : Organigramme général de CLS

La DCL développe les activités technico-commerciales. On retrouve l’aspect commercial des trois pôles stratégiques de CLS à savoir, la surveillance environnementale, la gestion des ressources marines et la sécurité maritime. La DOS développe des activités scientifiques d’études océanographiques. Entre autre, le traitement de la télémesure scientifique des satellites, la géodésie spatiale et la modélisation des écosystèmes marins.

En ce qui concerne la DAR, c’est une direction qui est principalement implantée à Brest. Elle regroupe des activités fondées sur l’acquisition, le traitement et l’interprétation de l’imagerie radar satellitaire haute résolution.

La DT, quant à elle, est chargée de la conception, du développement, de la maintenance des systèmes mais également de leur exploitation (assurer le maintien en condition opérationnelle des applications 24h/24, 7j/7). Pour y parvenir, cette direction est divisée en 4 divisions, composées elles-mêmes de départements. La figure 5 représente l’organigramme de cette direction :

(16)

15

Figure 5 : Organigramme de la DT

I.3.2 La Division Système d’Information

Le rôle de la Division Système d’Information (DSI) est de définir, concevoir, et mettre en œuvre le système d’information à CLS, à travers trois départements :

- L’équipe « solutions et innovation » qui étudie les solutions innovantes qui pourraient être utilisées dans le futur par CLS.

- L’équipe « architecture » qui définit et met en place les infrastructures du système d’information.

- L’équipe « production » qui maintient et assure le bon fonctionnement du système d’information.

J’occupe actuellement le poste d’Ingénieur Système dans le département Production. Ma fonction dans l’équipe peut être décrite par plusieurs rôles : le principal est l’exploitation de l’infrastructure virtuelle, c'est-à-dire de mettre en œuvre les moyens garantissant une disponibilité maximale de celle-ci. A ce titre, j’effectue une analyse des anomalies, assure un suivi qualité, gère les évolutions et également les mises en production. Ma seconde fonction est l’exploitation de

(17)

16

l’outil de supervision de notre système d’information. Enfin, chaque membre de l’équipe est le référent système d’une ou plusieurs applications. Pour ma part ce sont les applications Iridium et Catsat.

C’est dans ce contexte que j’ai réalisé mon mémoire.

I.4 Le Système d’Information

I.4.1 Généralité

Pour héberger ces applications et rendre le service opérationnel à nos clients, nous disposons de plusieurs centres de données, appelés « Datacenter » (DC). A CLS-Toulouse, nous disposons de deux DC :

o Deux salles serveurs dans les locaux de CLS-Toulouse

o Une salle Disaster Recovery au CNES interconnectée au DC de CLS, via une liaison fibre optique dédiée

Nous disposons également de deux DC en dehors des locaux de CLS-Toulouse : - Un DC à CLS America

- Un DC à CLS Brest

Cette infrastructure est nécessaire afin de répondre aux contrats de services en place avec nos clients pour la majorité de nos applications. Pour les applications les plus critiques, le taux de disponibilité de l’application doit être supérieur ou égal à 99,5%, ce qui correspond à moins de 4 heures d’arrêt autorisé par mois. De ce fait, les ressources informatiques sont importantes pour réaliser les activités de CLS. Nous décomptons environ 500 serveurs, physiques et virtuels confondus, de production et de développement pour environ 250 To de données stockées, fonctionnant sous les systèmes d’exploitation Linux, OpenVMS, Solaris, Tru64 et Windows.

(18)

17

I.4.2 La virtualisation I.4.2.1 Définition

Afin d’introduire la notion de virtualisation, voici quelques définitions de la virtualisation et d’hyperviseur, issues du CNRTL2 et de Wikipédia :

« virtuel : se dit des éléments (terminaux, mémoire, …) d’un système informatique considérés comme ayant des propriétés différentes de leurs caractéristiques physiques »

« Techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur une seule machine plusieurs systèmes d'exploitation et/ou plusieurs applications, séparément les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes. »

« En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d'exploitation de travailler sur une même machine physique en même temps. »

I.4.2.2 Historique

Les premières solutions de virtualisation sont historiquement apparues au sein des systèmes mainframes de chez IBM à la fin des années soixante. Ce n’est que plus tard, dans les années quatre-vingt-dix, que la virtualisation s’est développée avec la progression des performances des processeurs et l’apparition pour le grand public d’émulateurs de consoles de jeux sur les architectures de type PC. A partir des années deux mille, les premières solutions sur ces architectures font leur apparition, permettant la virtualisation de système d’exploitation. Cet attrait du grand public et des entreprises pour la virtualisation fait que les deux acteurs majeurs de processeurs ont ajouté de nouvelles instructions visant à améliorer les performances des solutions de virtualisation (VT-x chez Intel et AMD-V chez AMD). Dans ce sens, les acteurs principaux de la virtualisation continuent de faire progresser la virtualisation, offrant des solutions toujours plus performantes.

2 Centre National de Ressources Textuelles et Lexicales, portail de ressources linguistiques informatisées du CNRS

(19)

18

I.4.2.3 Les solutions techniques

Nous allons aborder les principales techniques de virtualisation :

Isolateur : Un isolateur (ou virtualisation par cloisonnement) est un logiciel

permettant d'isoler l'exécution des applications dans des contextes ou bien zones d'exécution. L'isolateur permet ainsi de faire tourner plusieurs fois la même application dans un mode multi-instance (plusieurs instances d’exécution) même si elle n’était pas conçue pour cela. Cette solution est très performante mais les environnements virtualisés ne sont pas complètement isolés, on ne peut donc pas vraiment parler de virtualisation de systèmes d’exploitation. En effet, le matériel et le système d’exploitation sont les mêmes pour tout le monde. Ce type de virtualisation est essentiellement utilisé sur les systèmes Unix, Linux et BSD. Exemples : Linux-vServer, chroot

Hyperviseur de type 2 : Un hyperviseur de type 2 est un logiciel qui s’exécute sur

le système d’exploitation hôte et permet de lancer un ou plusieurs systèmes d’exploitation invités (machines virtuelles). La figure 6 représente ce fonctionnement :

Figure 6 : Hyperviseur de type 2

L’hyperviseur installé sur le système d’exploitation se charge de créer un environnement complet simulant du faux matériel pour les systèmes invités, ces derniers croient dialoguer directement avec le matériel réel. On appelle également cette solution une « virtualisation complète ». Cette solution permet de faire

(20)

19

cohabiter plusieurs systèmes d’exploitation hétérogènes sur une même machine grâce à une isolation complète, mais cette isolation a un coût en performance. Ce type de virtualisation est toutefois limité aux systèmes d’exploitations prévus sur la même architecture matérielle que le processeur physique du serveur hôte. C’est ce qui le différencie d’un émulateur3, qui va jusqu’à simuler le microprocesseur, et

donc d’avoir la possibilité d’héberger une architecture matérielle différente de celle du CPU hôte mais les performances sont considérablement réduites par rapport à la virtualisation.

Exemples : Microsoft VirtualPC, Oracle VM VirtualBox, VMware Player

Hyperviseur de type 1 : Cette technique de virtualisation « native », aussi

appelée « Bare-Metal », est une solution qui s’exécute directement sur la plate-forme matérielle. La figure 7 représente ce fonctionnement :

Figure 7 : Hyperviseur de type 1

C’est un noyau système très léger et optimisé pour gérer des systèmes d’exploitation invités à l'architecture matérielle sous-jacente. Les systèmes invités ont conscience de s’exécuter dans un environnement virtualisé : ils sont capables d’interagir avec l’hyperviseur. Actuellement, il s’agit de la méthode de virtualisation d'infrastructure la plus performante.

Cette solution, appelée également paravirtualisation, fournit un environnement virtuel (interface et ressources) censé représenter une architecture réelle. Ainsi,

3 L’émulation sert à utiliser des logiciels ou OS prévus sur un autre type de matériel.

Toutes les instructions, qui sont à la base incompatibles avec le matériel, sont transformées à la volée pour pouvoir être effectuées.

(21)

20

un système d’exploitation développé pour une architecture particulière, s’exécute de façon native, sans aucune modification, dans une machine virtuelle qui virtualise complètement cette architecture. Concrètement, les machines virtuelles partagent les ressources physiques du serveur (disques, mémoires, CPU, carte réseaux, …).

Exemples : VMWare ESXi, Citrix XenServer, Microsoft Hyper-V

I.4.2.4 La solution VMWare

I.4.2.4.1 Généralités

Je vais vous présenter la solution de virtualisation qui sera traitée dans ce mémoire car c’est celle qui est déployée à CLS : VMWare.

VMWare est une société américaine créée en 1998, aujourd’hui filiale d’EMC, qui conçoit des solutions de virtualisation d’infrastructures informatiques d’entreprise. VMware s’impose rapidement comme le plus grand fournisseur de solutions sur ce marché avec un chiffre d’affaires de 4,61 milliards de dollars en 2012 et plus de 480 000 clients et 55 000 partenaires.

VMWare décline son offre d’hyperviseur type 1 en deux gammes « ESX et ESXi ». Un serveur ESX/ESXi est un système d’exploitation optimisé pour gérer les accès des machines virtuelles à l’architecture matérielle. Son rôle est d’héberger des machines virtuelles et de permettre l’exécution de celles-ci. La dernière version majeure est la version 5.5 (septembre 2013) qui est présente uniquement en ESXi, la gamme ESX ayant été abandonnée depuis la version 4.1.

La différence entre les deux gammes est la présence d’un système d’exploitation Linux (appelé Service Console) permettant la gestion de l’ESX, qui a disparu dans la gamme ESXi afin de sécuriser et d’optimiser les ressources mais également l’espace utilisé par celui-ci (le système peut maintenant démarrer sur une clé USB). La console affiche un minimum d’opérations, s’approchant visuellement d’un BIOS (cf ci-dessous la figure 8).

(22)

21

Figure 8 : Interface ESXi

VMWare dispose de fonctionnalités de gestion et d’administration qui ont simplifié l’administration des serveurs. Ces fonctionnalités, reprises à ce jour en majorité par les concurrents, ont fortement contribué au succès et à la démocratisation de la virtualisation dans les entreprises :

vCenter : Console de gestion centralisée. Elle permet de gérer l’ensemble

des serveurs VMWare ESXi et machines virtuelles depuis une interface graphique, et de ce fait, d’accéder aux consoles des machines virtuelles.

(23)

22

VMotion : Cette option permet de migrer à chaud, donc sans interruption

de service, une machine virtuelle d’un serveur ESX vers un autre. Cette opération est possible si les serveurs hôtes utilisent des microprocesseurs compatibles et que l’espace de stockage est partagé entre les serveurs. Techniquement, VMotion déplace le contenu de la mémoire d’un serveur hôte vers un autre.

Figure 10 : vmotion et storage vmotion

Storage VMotion : Concept identique à VMotion mais pour le stockage.

Option très utile pour des opérations de réorganisation du stockage, ou la migration des VM vers de nouveaux espaces.

High Availability (HA) : Lorsqu’un ESX tombe en panne, l’ensemble des

machines virtuelles associées et faisant partie du cluster HA vont automatiquement et immédiatement redémarrer sur un autre ESX membre du cluster. Ceci permet de réduire le temps d’indisponibilité des applications.

(24)

23

Figure 11 : High Availability

Distributed Resource Scheduler (DRS) / Distributed Power

Management (DPM) : Ces deux composants permettent de proposer une

bonne répartition des machines virtuelles en fonction de l’utilisation des ressources de la plateforme. DRS, en s’appuyant sur VMotion, va jouer le rôle de répartiteur des machines virtuelles entre ESX en analysant l’utilisation mémoire et processeur des machines virtuelles. Pour sa part, DPM permet de réduire la consommation électrique de la plateforme, en consolidant les machines virtuelles sur les ESX. DPM est couplé avec DRS pour éviter de surcharger les ESX.

Fault Tolerance (FT) : La tolérance de panne apporte de la très haute

disponibilité. Même en cas d’arrêt brutal d’un ESX, il n’y a pas d’arrêt des machines virtuelles, donc pas d’interruption de service. FT crée une copie conforme d’une machine donnée. Tout ce qui se passe sur cette machine, appelée machine virtuelle primaire, est copié en miroir dans une machine virtuelle secondaire. En revanche, les contraintes sont nombreuses : consommateur en ressources et techniquement à ce jour un seul vCPU peut être attribué par machine virtuelle.

I.4.2.4.2 Gestion des ressources

Nous venons de voir les fonctionnalités qu’offre la virtualisation, nous allons maintenant nous intéresser à la gestion des ressources. Ces concepts sont à prendre en compte pour une meilleure compréhension du fonctionnement de la virtualisation. Un hyperviseur permet de virtualiser les principaux composants d’un serveur physique afin de pouvoir partager ces ressources. Quatre composants

(25)

24

majeurs d’un serveur sont concernés : le processeur, la mémoire, le stockage et le réseau.

- Le processeur est le seul composant du serveur qui n’est pas masqué par la couche de virtualisation. La machine virtuelle voit donc le type et le modèle du processeur physique du serveur sur lequel il s’exécute.

On définit sur des machines virtuelles un nombre de vCPU, l’hyperviseur s’occupe de répartir la charge sur les différents cœurs.

Figure 12 : Gestion des processeurs

- La mémoire est une ressource dont VMWare a pu tirer parti au mieux. En premier lieu, nous allons voir que la virtualisation permet «d’économiser » la consommation mémoire avec diverses technologies. De plus, la sur-allocation mémoire est possible : on peut avoir plus de mémoire dans les machines virtuelles qu’il n’y a de mémoire physique dans le serveur. Lorsque la sur-allocation a lieu, VMWare utilise différentes techniques pour récupérer de l’espace mémoire d’une ou plusieurs VM : le TPS, le ballooning et le swap.

o Le TPS (Transparent Page Sharing) : les VM partageant la même mémoire physique, il est fort probable que certaines pages mémoires soient identiques. Le TPS supprime les pages mémoires

(26)

25

qui sont redondantes, et ce, de manière transparente (les VM n’ont pas conscience de partager une page mémoire avec d’autres VM). La figure 13 représente ce fonctionnement, les pages mémoires représentées en orange sont identiques, elles ne seront consommées qu’une fois sur la mémoire physique :

Figure 13 : TPS

o Le Ballooning est le fait de prendre de la mémoire disponible à une machine virtuelle pour la donner à une autre qui en a besoin. Pour cela, l’hyperviseur fait la différence entre la mémoire consommée par le système d’exploitation et la mémoire utilisée (active). Ensuite, le driver du balloon (vmmemctl) donne l’instruction de « gonfler » (comme un ballon) la mémoire ce qui oblige le système d’exploitation à libérer les pages mémoire non utiles et à les déplacer vers le disque. La figure 14 représente le fonctionnement du ballooning :

(27)

26

o Le Swap : le concept est identique à celui appliqué sur un système linux. Un fichier de swap (vswp) de la taille de la mémoire de la VM va être créé. Cette technologie est employée par l’hyperviseur en dernier recours si le TPS et le ballooning ont été insuffisants.

- Le stockage : l’hyperviseur a accès aux disques sur serveur physique ou à un stockage partagé. L’espace de stockage est nommé « datastore » : c’est un volume formaté dans le format vmfs, propriétaire à VMWare. Cela permet d’avoir un modèle de stockage uniforme, pour y stocker les machines virtuelles.

- La connexion des VM au réseau est basée sur des switchs virtuels nommés vSwitch. Concrètement, le vmkernel va jouer le rôle de répartir les composants physiques du réseau aux switchs virtuels.

I.4.2.5 La virtualisation au sein de CLS

Comme de nombreuses entreprises, CLS a fait le choix d’implanter la virtualisation dans son infrastructure. C’est à l’occasion du projet Disaster Recovery en 2006 qu’ont eu lieu les premiers déploiements. Outre les nouvelles fonctionnalités techniques, la virtualisation a permis de rationnaliser nos centres de données, tant en consommation énergétique qu’en espace physique et de consolider en optimisant l’utilisation de nos serveurs. En effet, l’acquisition de serveurs physiques a été exponentielle avec l’apparition de serveurs à faible hauteur avec des performances toujours améliorées grâce à l’arrivée des nouveaux processeurs, avec par exemple l’arrivée des multi-cœurs et le 64 bits. En général, avant l’utilisation de la virtualisation les serveurs ont été « sous-exploités ». Ce n’est pas un constat spécifique à CLS mais un constat global dans le monde informatique. D’après E.Maillet, 80% des serveurs avaient un taux d’utilisation moyen inférieur à 10%. La virtualisation est arrivée à point nommé et a permis de faire face à l’accroissement des demandes tout en répondant aux problèmes répandus dans les DSI en consolidant et rationalisant l’infrastructure.

Depuis, la virtualisation a permis la mise en place de nombreuses applications et l’augmentation significative du nombre de serveurs dans notre infrastructure, aujourd’hui majoritairement virtuels. De plus, la virtualisation a apporté de la

(28)

27

souplesse dans l’administration globale des serveurs. Les tâches et rôles ont été modifiés : les administrateurs sont moins confrontés à des problématiques matérielles mais plus systèmes.

En ce qui concerne notre infrastructure virtuelle, nous disposons de 30 serveurs dédiés à la production et au développement pour environ 350 machines virtuelles. Vous retrouverez sur la figure 15 le schéma d’architecture concernant l’environnement de production du site de Toulouse, découpé en deux grandes familles : les ESX hébergeant les moyens communs et ceux hébergeant les applications.

(29)

28

I.4.3 La démarche ITIL

Les préconisations ITIL (Information Technology Infrastructure Library) ont été suivies pour l’évolution de notre système d’information. J’ai souhaité de ce fait utiliser cette démarche pour ce projet d’industrialisation.

Avant tout, il est nécessaire de vous présenter les concepts d’ITIL.

I.4.3.1 Généralités

Créé par le gouvernement britannique dans les années quatre-vingt comme une initiative d’amélioration de l’efficacité, la valeur ITIL a été rapidement identifiée par les entreprises et les organisations à travers le monde. Aujourd’hui, son rôle essentiel pour l’amélioration de la gestion des services est largement documenté. ITIL est constitué d’un ensemble d’ouvrages, basés sur les meilleures pratiques et dont les auteurs sont des experts internationaux publics et privés. ITIL en est à ce jour à la version 3 qui intègre cinq étapes dans son cycle de vie.

I.4.3.2 Les étapes du cycle de vie ITIL v3

La première étape de la démarche ITIL se transcrit par un premier ouvrage sur la stratégie des services (Service Strategy), c’est-à-dire la stratégie permettant de fournir des services créateurs de valeur. Autour, s’articulent les trois livres correspondant aux grandes phases de la vie d’un service : la conception du service (Service Design), la transition (Service Transition), et l’exploitation du service (Service Operation). Enfin, nous trouvons autour de ceux-ci la partie Amélioration continue du service (Continual Service Improvement). La figure 16 représente le cycle de vie des cinq chapitres d’ITIL v3.

(30)

29

Figure 16 : Cycle de vie ITIL v3

L’architecture des publications principales d’ITIL v3 est basée sur le cycle de vie du service où chaque livre est représenté par une « phase ». La définition selon ITIL d’un service est : « Un service représente un moyen de fournir une plus-value à un client, en produisant les résultats que ce dernier attend, sans qu’il n’ait à en porter lui-même les coûts et les risques spécifiques ».

I.4.3.3 ITIL au sein de CLS

Cette démarche a été utilisée pour l’amélioration de notre système d’information. Dans un premier temps, en 2006, notre solution de supervision, Eyes Of Network, a été mise en place en suivant les préconisations ITIL (gestion des alertes, gestion de la capacité, gestion de la disponibilité, etc.). Ensuite, en 2008, l’installation d’un outil de helpdesk, (gestion des événements, gestion des incidents, gestion des problèmes, gestion des changements, gestion des mises en production, etc.) et de gestion de parc (gestion des actifs et des configurations), ISILOG, est venue conforter cette démarche. Les trois grandes phases du cycle de vie ITIL v3 ont été ainsi parcourues. Conjointement, la Division des Opérations a travaillé plus spécifiquement sur la phase « Conception des Services » avec la mise en place des contrats de services formalisés au sein d’un SLA (Service Level Agreement) avec nos clients (internes et externes) pour la plupart de nos applications à ce jour.

(31)

30

II Problématique et besoins

Nous venons de voir dans quel contexte ce mémoire va être réalisé. Ce que nous allons voir maintenant est la problématique et les besoins exposés par le sujet du mémoire.

II.1 Problématique

Pour assurer les activités de CLS, des configurations informatiques (serveurs, logiciels, équipements de stockage et réseau) doivent être imaginées, validées puis mises en place à CLS ou chez nos clients. La virtualisation n’a pas modifié le comportement de l’équipe système qui s’occupe des installations et des configurations. De ce fait, toute la puissance qu’offre cette technologie n’est pas exploitée. Il est important de souligner que l'arrivée de la virtualisation dans notre infrastructure a bousculé l’évolution constante prévue, avec une forte croissance en termes de nombre de serveurs : en trois ans, nous avons triplé le nombre de serveurs applicatifs. Une des conséquences directes de cette forte hausse est la manière de procéder pour l'installation d’un serveur. Jusqu’à l’arrivée de la virtualisation, pour l’installation d’un serveur physique, l’équipe système avait divers moyens pour mettre en place les configurations :

- Installation du système d'exploitation via l’image disque (ISO) ou le CD-ROM pour ensuite travailler sur sa configuration à partir d’une check-list préétablie.

- Installation du système d'exploitation via l’image disque (ISO) ou le CD-ROM pour ensuite travailler sur sa configuration « à la carte ».

- par d'autres moyens de déploiement (par exemple la solution RDP avait été mise en place pour faciliter le déploiement d’applications).

Cette habitude a été dans un premier temps conservée pour l'environnement virtuel. Plusieurs voies alternatives sont apparues avec les nouvelles possibilités qu’offre la virtualisation sans qu'il n’y ait de règles précises mises en place, comme :

- le déploiement par l'action de cloner une machine virtuelle existante et d'en modifier ensuite la configuration.

(32)

31

- par la création d'une machine virtuelle via un modèle prédéfini antérieurement.

La figure 17 représente ces nouvelles alternatives :

Figure 17 : Méthode de création d'une VM

Nous venons de rendre compte des différentes alternatives qui se sont naturellement mises en place dans l’équipe afin d’installer et de configurer des serveurs virtuels. Seulement, nous nous sommes rendus compte que ces solutions n’étaient pas optimales. La solution d’installation depuis une image disque a deux défauts : elle est très consommatrice en temps et surtout il existe un risque très fort d’avoir des installations non identiques si elle n’est pas associée à un outil de gestion des configurations. La solution de clonage d’une machine virtuelle a le mérite d’apporter un gain de temps assez important car elle permet d’outrepasser l’étape longue et fastidieuse d’installation du système d’exploitation mais elle est peu fiable. Le fait de cloner la machine virtuelle implique, par exemple, que les deux serveurs auront la même adresse IP, le même nom, etc. En outre, le problème majeur est que l’on conserve toute l’ancienne vie de la machine virtuelle source, en plus de la rigueur nécessaire dans la reconfiguration afin qu’un oubli dans un fichier de configuration quelconque ne se transforme pas en conflits sur le réseau. Bien sûr, des solutions de reconfiguration existent et permettent de simplifier cette étape. Par exemple, l’outil Sysprep pour les serveurs du constructeur Microsoft permet, au premier démarrage, d’effectuer les étapes de configuration les plus communes. Il existe des outils équivalents dans le monde Linux, comme par exemple kickstart chez RedHat. Ces solutions d’installations depuis un modèle associé à un outil de configuration semblent être les solutions les plus adaptées. Nous en avions mis quelques unes en place afin de faciliter nos déploiements, dans l’objectif d’économiser du temps pour les prochains déploiements. Seulement, sans y associer un processus de gestion de ces modèles, nous avons constaté que les bénéfices étaient presque nuls. En effet,

(33)

32

nos modèles ne sont pas cadrés car ce n’était qu’une installation de base mise de côté afin d’éviter les étapes rébarbatives d’installation. En fonctionnant de la sorte, nous ne sommes pas prêts à prendre en compte l’évolution des configurations qui doivent êtres adaptées au fil du temps et des évolutions. De plus, si on utilise les nouvelles possibilités qu’offre la virtualisation, la solution de clonage ou de modèle, il faut de toute manière avoir une machine virtuelle « propre », spécifique. A partir d’une installation nouvelle, sans qu’elle ait « vécue ». C’est la seule manière d’obtenir la garantie que les machines virtuelles commenceront leur cycle de vie au même niveau. Un autre constat, nous n’avons aucune gestion de nos systèmes d’exploitation au sein de notre système d’information. Nous essayons de déployer au maximum des distributions choisies par l’équipe système, sans regard sur les versions de celles-ci. Cette gestion, qui est inexistante aujourd’hui dans l’équipe, est une action que nous souhaitons mettre en œuvre.

Illustrons par un exemple concret l’intérêt d’industrialiser le déploiement de machines virtuelles. Nous avons rencontré des problèmes avec notre première application 100% virtuelle : Iridium. Un problème d’arrondis sur les valeurs dans l’insertion des positions des balises Iridium dans la base de données a sérieusement impacté notre production. Les clients recevaient des positions erronées. Après de longues investigations des différentes équipes (exploitation, intégration, de développement et système), celles-ci ont été incapables de trouver l’origine du problème. Etait-ce :

- lié au système d’exploitation ? - lié à l’application ?

- ou lié à la virtualisation ?

CLS a fait appel à une société extérieure pour investiguer ce problème. Leur première demande a été de leur fournir la configuration système et applicative initiale, celle qui avait été validée en recette. Pour la version applicative, il n’y a pas eu de problème car un processus est en place pour la gestion des versions, ce qui n’est pas le cas pour le système. La conclusion est que nous avons été incapables de leur fournir le système tel qu’il a été livré deux ans auparavant, celui validé lors de la recette.

(34)

33

II.2 Besoins

II.2.1 Industrialiser

Le processus d’industrialisation qui est en cours de mise en place dans l’équipe système vise à maitriser ces installations et ces évolutions. Comme nous l’avons vu, l’objectif est, par exemple, d’être en mesure de reproduire une configuration à l’identique deux ans plus tard ou encore de garantir qu’une telle configuration n’a pas évolué et qu’elle est conforme à celle qui a été validée lors de la recette. Commençons tout d’abord par faire la synthèse des enjeux de l’industrialisation. Ce terme est répandu dans le monde de l’informatique d’aujourd’hui, nous allons voir de quoi il s’agit. En voici la définition brute issue du CNRTL :

« Processus complexe qui permet d'appliquer à un secteur, à une branche de l'économie, des techniques et des procédés industriels qui apportent rationalisation et hausse de productivité »

Nous pouvons résumer l’industrialisation en deux idées directrices qui seront au cœur des enjeux de mon mémoire :

- Processus de fabrication - Forte productivité de travail

En pratique, l’industrialisation dans le domaine informatique se traduit concrètement par la mise en place d’outils et de procédures afin de faciliter et de contrôler le déploiement, dans notre cas, de machines virtuelles. En effet, l’objectif est d’assurer la production des applications et de garantir qu’à tout moment, on peut reconstruire l’application de production à partir de ses sources. Cela se résume à disposer d’un réel processus de « fabrication » permettant de garantir la conformité et la qualité des services produits.

II.2.2 Homogénéiser

Comme déjà développé dans la problématique, l'objectif est d’homogénéiser notre manière de travailler, afin que chaque membre de l’équipe ait la même façon de procéder. Il est devenu indispensable de mettre en place une nomenclature

(35)

34

unique. L'équipe système attend la mise en place d'un socle technique, de versions validées par l'équipe pour les utilisateurs et les clients.

De plus, les installations se réalisent généralement avec la dernière version stable du système d’exploitation concerné, d’où l’apparition d’écarts de configuration dans notre parc. L’objectif est de protéger l’environnement de production et ses services en mettant en place des vérifications lors de l’implémentation des changements. Cette gestion des configurations vise à maitriser notre infrastructure. Concrètement, cela consisterait à empaqueter une application avec un système d’exploitation certifié, ce qui réduirait les problèmes de compatibilité entre une application et son système d’exploitation.

ITIL préconise que la gestion des configurations soit la base de référence afin de fournir la représentation la plus fidèle possible du système d’information et en particulier de son infrastructure en identifiant, contrôlant, et maintenant à jour et en vérifiant les versions de tous les éléments de configuration existants. La mise en place à CLS du couple d’outils Isilog pour la gestion de parc et Ocsinventory pour l’inventaire automatique a permis d’avoir une base de données unique des configurations (CMDB). Dans la même optique, nous avons besoin de gérer les profils et les versions de nos systèmes qui nous permettront de suivre et de maitriser les évolutions de notre système d’information.

II.2.3 Objectifs

Il est primordial de se fixer des objectifs réalistes et précis. Pour cela, nous devrons bâtir le projet afin qu’il corresponde à notre propre contrainte. Ainsi, il faut connaître les améliorations attendues par rapport aux faiblesses du Système d’Information actuel et à ses problématiques.

Que va apporter la nouvelle solution ? Il sera possible de mesurer les bénéfices à tous les niveaux et devront être clairement identifiés :

- Mise à disposition plus rapide et plus efficiente des mises en production. - Garantie que les utilisateurs peuvent utiliser le service dès sa mise en

place.

(36)

35

- Reconstruction possible d’un environnement identique à celui validé en recette.

Il conviendra de mettre en place un système simple à utiliser, convivial et rapide. L’objectif est que chaque membre de l’équipe, quel que soit son domaine de compétences, puisse facilement déployer des machines virtuelles rentrant dans le périmètre CLS défini par l’équipe.

(37)

36

III Etude préliminaire

Après avoir décrit la problématique et les besoins à couvrir, considérons maintenant la description des étapes préliminaires qui ont permis d’aboutir à une solution. Cette réalisation est décomposée en trois parties. Dans la première, nous allons effectuer un état des lieux de notre infrastructure. Ensuite, dans la deuxième, nous délimiterons le périmètre du projet. Enfin, dans la dernière partie, nous étudierons les préconisations ITIL pour la réussite du projet.

III.1 Etat des lieux

III.1.1 Parc serveurs virtuels

Avant d’entreprendre la réalisation du projet, il est indispensable d’effectuer un état des lieux de notre parc virtuel à CLS. Nous nous sommes limités aux machines virtuelles référencées dans le centre de données de CLS-Toulouse. Notre CMDB (Configuration Management Database) identifie environ 250 machines virtuelles. Suite à ces informations, la première analyse (comme le montre le tableau 1) révèle que l’on peut découper notre parc virtuel en deux grandes familles de systèmes d’exploitation : Linux et Windows.

Système d’exploitation Nombre de VM

Linux Server 191

Windows Server 33

Tableau 1 : Répartition des OS

Nous avons fait le choix d’ajouter un degré de granularité, c’est à dire en spécifiant les distributions dans leurs versions majeures. L’objectif est de ressortir seulement les distributions les plus déployées. De ce fait, les distributions ayant moins de dix machines virtuelles ne sont pas représentées dans le tableau 2 ci-dessous. Nous n’ajoutons pas de degré supplémentaire jugeant l’intérêt mineur. Par exemple, on aurait pu ajouter la répartition des updates : la distribution Redhat Entreprise Linux AS 4 regroupe toutes les updates existantes, c'est-à-dire de 1 à 8.

(38)

37

Distribution | Version majeure * Nombre de VM

RedHat Enterprise Linux AS 4 73

Centos 5.x 59

RedHat Enterprise Linux 5.x 25

Windows 2003 Server 22

RedHat Enterprise Linux AS 3 13

Debian 5.x 11

Tableau 2 : Répartitions des distributions

* Les familles (VM <10) ne sont pas représentées

Cet audit préalable fait ressortir que notre parc est assez hétérogène avec six versions majeures différentes déployées, majoritairement basées sur des systèmes Linux qui représentent environ deux cents machines virtuelles, soit 80% du parc.

III.1.2 Définitions de classes

L’état des lieux a permis de donner la composition de notre infrastructure virtuelle actuelle. La deuxième étape est de délimiter le périmètre du projet. Au cours de mes travaux, j’ai défini trois classes de machines virtuelles, décrites ci-dessous.

III.1.2.1 La classe système

J’ai nommé la première classe de machines virtuelles «système». En effet, cette famille est la base d’une configuration. Elle inclut le système d'exploitation supporté par l’équipe système de CLS, configuré selon nos préconisations, avec en plus, les outils nécessaires à une bonne exploitation lors de sa livraison. Les versions des systèmes et l’interopérabilité avec notre infrastructure seraient de ce fait validées. Par exemple, l’installation d’une machine virtuelle reposant sur une distribution Linux mais optimisée : les paquets concernant la suite bureautique ou le serveur graphique ne seront pas installés par défaut, car ils sont inutiles au bon fonctionnement d’un serveur web. De plus, les outils utilisés pour l'exploitation quotidienne seraient déployés : le client d'inventaire, de supervision, de

(39)

38

sauvegarde, etc. Enfin, les fichiers de configuration système seraient prédéfinis (configuration réseau, ...).

D’après le référentiel ITIL, ce mode d’implémentation peut se faire après un test exhaustif des éléments qui le composent mais permet de garantir que tous les éléments sont à niveau et validés.

III.1.2.2 La classe applicative

A ce jour, les équipes de développement créent une application sur un système préinstallé que l’équipe système leur fournit selon les besoins exprimés. Ensuite, elles en modifient généralement la configuration système avec le concours des administrateurs systèmes pour l’adapter aux besoins de leurs applications.

On peut imaginer que les développeurs utilisent une machine virtuelle de type « système » pour effectuer leurs installations et validations. Les équipes de développement et d’intégration effectueraient les modifications nécessaires. Par exemple, en ajoutant des paquets indispensables au bon fonctionnement de leur application. Lors de la recette, on certifiera que l'application fonctionne avec la configuration de livraison : configuration système avec par exemple version java 1.6.3. Un autre bénéfice est que nous pourrions également mettre rapidement à disposition d’autres machines virtuelles d’une application donnée « prêtes à l’emploi ».

III.1.2.3 La classe service

Il existe également des machines virtuelles ayant un rôle précis, généralement déployées à la chaîne. En effet, cela peut être intéressant pour les serveurs communs : serveurs web, serveurs d’annuaire centralisé, serveurs DNS4, etc.

Cette solution est celle que l’on retrouve majoritairement chez les éditeurs. Par exemple, la solution de serveurs collaboratifs « Zimbra » met à disposition un modèle qui est pré-empaqueté dans un système d’exploitation validé. Les utilisateurs de la solution n’ont plus à se préoccuper de l’intégration de la solution

(40)

39

sur leurs systèmes d’exploitation (compatibilité, dépendances, évolution, obsolescence, etc.).

III.2 ITIL et le déploiement

En me documentant sur les préconisations ITIL, j’ai pu relever que la phase principale concernant mon mémoire est la « Transition des services ». Je vais dans un premier temps en définir son rôle :

« La Transition des services » : cette phase est l’interface centrale entre la conception des services et l’exploitation des services. Son objectif est de définir et contrôler les composants des services de l’infrastructure afin d’assurer la précision et la fiabilité de cette information. On va s’assurer que tous les composants des services ou des produits sont identifiés, maintenus et rattachés à une configuration de référence et que tous les changements portant sur ces composants seront gérés.

Trois processus de cette phase vont être primordiaux pour le bon déroulement de notre projet :

- Gestion des changements : l’objectif est de s’assurer que les changements sont enregistrés, évalués, autorisés, priorisés, planifiés, testés, réalisés, documentés et vérifiés.

- Gestion des configurations et des actifs des services : l’objectif est de fournir et maintenir un modèle logique de l’infrastructure informatique, des services informatiques qui y sont liés et des différents composants informatiques (physiques, logiques, etc.).

- Gestion des mises en productions et des déploiements : l’objectif est de garantir le déploiement dans l’environnement de production.

La notion de configuration de référence fait son apparition et apporte entre autres :  Une meilleure connaissance de la production des services

 Une meilleure analyse des impacts des changements  Une aide à la résolution des incidents et problèmes

(41)

40

 Une aide à l’industrialisation et à la standardisation des infrastructures

III.3 Solutions envisagées

Nous avons identifié les besoins auxquels doit répondre la solution choisie. Il s’agit maintenant de présenter les différentes solutions disponibles, en révélant les avantages et inconvénients respectifs.

III.3.1 Outils de gestion des configurations

La première solution est d’utiliser un outil de gestion des configurations de serveurs. Il s’agit d’une solution où, depuis un serveur maître, nous pouvons gérer de manière centralisée le déploiement des paquets du système d’exploitation sur les serveurs esclaves. Ce genre de solution correspond à ce qui avait été mis en place quelques années auparavant à CLS : la solution RDP (Rapid Deployment software) de la société HP, aujourd’hui abandonnée. Il existe également des solutions comme PXEBoot+TFTP que l’on a utilisé pour notre ferme de calcul, ou lié à kickstart par exemple pour Linux, solution que l’on a utilisée pour nos serveurs de base de données. Depuis, des solutions plus abouties sont apparues, comme par exemple Puppet, Chef ou encore FAI (Fully Automatic Installation). L’avantage de ces solutions est qu’elles sont également fonctionnelles pour un environnement non virtuel. Elles permettent également des déploiements plus poussés comme par exemple le BIOS d’un serveur ou les firmwares des composants. L’inconvénient est qu’elles sont complexes à prendre en main, demandent une certaine période d’adaptation et qu’elles ne sont, pour l’instant, fonctionnelles que sur des systèmes d’exploitation Linux.

III.3.2 Modèles de machine virtuelle

Les modèles de machine virtuelle que nous appelons également « template » est également un moyen intéressant de répondre à nos besoins. En effet, la virtualisation a apporté des fonctionnalités intéressantes : à partir d’un modèle nous pouvons déployer des machines virtuelles assez facilement. Deux possibilités distinctes existent pour la création de templates :

(42)

41

 La première possibilité est l’utilisation de solutions permettant de générer des machines virtuelles à partir de configurations préétablies. Par exemple, VMware Studio ou encore Suse Studio sont les solutions les plus abouties à ce jour. Il s’agit de solution de gestion de configuration comme citée ci-dessus, mais orientée virtualisation. L’avantage de cette possibilité est que tout est décrit dans un profil mais il est aussi un inconvénient, car la configuration s’effectue à « l’aveugle », c'est-à-dire qu’à partir d’un système d’exploitation vierge on doit décrire les paquets supplémentaires ou les scripts post-installation. Cette possibilité manque de souplesse dans l’administration et dans les possibilités.

 La seconde possibilité est une création personnalisée avec une conversion de la machine en modèle une fois la machine virtuelle validée. L’avantage de cette possibilité est que le résultat de notre configuration est visible directement. L’inconvénient est que l’on perd l’obligation de description et donc de traçabilité. Cette solution peut être très intéressante si elle est associée à des procédures rigoureuses. De plus, un modèle est consommateur en termes d’espace disque rendant cette solution contraignante. Heureusement, les éditeurs majeurs dans le monde de la virtualisation ont bien compris l’enjeu de ce type de solution et ont donc décidé de mettre à disposition un modèle standard.

(43)

42

IV Solution choisie

La solution d’utiliser un outil de gestion des configurations a été écartée, bien que le potentiel de ces solutions soit intéressant mais le maintien de ces solutions est complexe. En effet, ce type de solution est lourd à mettre en place et à gérer. A ce titre, la solution d’utiliser les modèles de machines virtuelle est apparue comme la plus viable par rapport à nos besoins. De plus, au cours de mes recherches, j'ai appris l'existence d'un format ouvert créé en 2007 par les acteurs majeurs de la virtualisation (VMWare, XenSource, ...) : le format OVF : Open Virtual machine Format. Ce format tend à s’imposer comme la norme pour les modèles de machines virtuelles.

IV.1 Le format OVF

Ce format est apparu et a été accepté en 2007 par le DMTF (Distributed Management Task Force). Les spécifications sont à ce jour définies dans la version 2.0.1, et plus récemment ratifiées par l'organisme ANSI (American National Standards Institute). Il est à noter que la version prise en compte dans cette étude est la version 1.1.0, la version 2.0.1 datant de 2013. Le besoin d’un standard pour la distribution de machines virtuelles sur des plates-formes de virtualisation est né de la rapide adoption d’infrastructures virtuelles dans les entreprises.

Un OVF est un mécanisme de transport de modèle de machine virtuelle, concrètement une « image maître » de la version de l’application. Son rôle est de permettre la distribution de machines virtuelles en assurant l'interopérabilité des principales solutions de virtualisation du marché. Ce format est également nécessaire afin d'automatiser et sécuriser l'installation, la configuration et l'exécution de ces applications sur n'importe quelle plateforme de virtualisation. Ce format est basé sur le standard XML (Extensible Markup Language), il décrit les caractéristiques d'une machine virtuelle, aussi bien techniques (format des disques durs, nombre de processeurs,...) qu'administratives (compatibilité, licence,...). Il peut également contenir une signature numérique pour assurer l'intégrité d'une machine virtuelle ainsi que des informations facilitant son déploiement dans un nouvel environnement.

(44)

43

IV.2 Intérêt du format OVF

Le format OVF est une solution attractive qui permet de mettre ensemble une application et un système d'exploitation sur lequel l'application est certifiée. C'est-à-dire qu’elle passerait de la phase de développement à celle de tests d’intégration puis de production sous la forme d'un ensemble configuré, pré-assemblé, sans aucune dépendance extérieure. L’application peut être facilement transmise par un revendeur, le tout, à l'intérieur d'une machine virtuelle.

De plus, construire une application dans un environnement virtuel est plus simple et plus économique que de fournir une application dans un environnement matériel : l'application est préinstallée avec le système d'exploitation qu'elle utilise (réduisant d'autant les phases de tests de compatibilité entre l'application et le matériel, ainsi que le passage par les certifications). Peu importe que son utilisation soit interne ou externe, le format OVF permet de simplifier de manière importante le cycle de gestion à travers l'adoption d'un ensemble de procédés standardisés.

IV.3 Possibilité du format OVF

A l'heure actuelle, les applications ne contiennent généralement qu'une seule machine virtuelle, alors que les applications d'entreprise utilisent une architecture orientée service avec plusieurs tiers, où chaque tiers contient une ou plusieurs machines. Le modèle de machine virtuelle unique n'est donc pas suffisant pour distribuer un service multi-tiers. De ce fait, un OVF peut être composé d’une ou plusieurs machines virtuelles. Prenons par exemple le cas de la revente d’une solution hébergée sur un serveur. On pourrait imaginer que ce serveur accueille plusieurs machines virtuelles, composant le « service » fourni au client. Une machine virtuelle pour l’application, une pour la supervision de l’application, une pour la sauvegarde, … La figure 18 représente ce type d’OVF.

Figure

Figure 3 : Répartition du résultat d'exploitation
Figure 4 : Organigramme général de CLS
Figure 5 : Organigramme de la DT
Figure 6 : Hyperviseur de type 2
+7

Références

Documents relatifs

The text of the 9th Party Congress, referring to the nature of engagement of citizens, talks of “creating a space where people can study holistically and receive information on

Prérequis : Néant Évaluation : Contrôle continu et examen final Mentions concernées : L3 Mathématiques et Informatique Horaires hebdomadaires : 3 h

• Partage d’une machine physique entre plusieurs machines virtuelles. • Gestionnaire de machines virtuelles

Tables de pages étendues Afin de protéger l’espace mémoire de l’hy- perviseur et des machines virtuelles, il est nécessaire que le résultat de la traduction d’une adresse

peut être suffisamment rapide par rapport à code compilé car le code de l'interpreteur réside dans le cache L1 d'instructions du processeur. note: Il n'y a pas de d'instruction

● On vérifie que le type de l'expression de return est bien compatible avec le type de retour de

Lors du premier appel à invokedynamic, la VM appel la méthode de bootstrap qui doit créer un object CallSite qui contiendra un pointer de. fonction vers la fonction qui sera

Article numérisé dans le cadre du programme Numérisation de documents anciens