Soutenance mémoire
La génération des certificats auto signés
vCloud director est accessible une fois installé via le protocole https. Ce protocole utilise un système de cryptage des flux à base de clefs asymétriques. Il nous faut générer deux certificats afin de pouvoir installer vCloud (c’est un pré-requis à l’installation comme nous le verrons par la suite). Il y a deux manières de procéder : créer deux certificats signés par une autorité de certification ou bien générer deux certificats dit « auto signé ».
Nous opterons pour la deuxième option. Cela aura pour conséquence l’apparition d’un message à la première connexion dans le navigateur précisant que l’autorité de certification n’est pas reconnue par le navigateur. Voici les commandes utilisées pour générer les certificats :
Mise en place d’une maquette de test
Les Objectifs
Le premier objectif de la plate-forme de test est de démontrer la faisabilité du projet à savoir créer une plate-forme de cloud pour l’université. Le deuxième objectif est de permettre de gagner de l’expérience avant de se lancer sur une plate-forme de production. C’est donc le bon moment pour pousser l’outil dans ses li mites, ce que nous ne manquerons pas de faire notamment au point de vue du réseau.
Création d’un nouveau VLAN
La création d’un nouveau VLAN est nécessaire pour cloisonner d’un point de vue réseau l’infrastructure de cloud du reste de l’infrastructure. Le VLAN contiendra les machines créée par vCloud uniquement. Cela sous -entend que les machines virtuelles nécessaires à l’infrastructure (les ESXi, le serveur vCloud, le serveur de base de donnée, le serveur vShield) utiliseront des adresses ip « classiques » avec lesquelles nous adressons nos autres serveurs.
La création de ce nouveau VLAN a été confiée à l’équipe réseau de l’université qui est spécialiste de ces problématiques. Une charge de travail élevée ainsi qu’un effectif réduit dans cette équipe ont retardé la mise en place de l’infrastructure de test. C’est un imprévu qui peut survenir dans un projet tel que celui-ci où plusieurs personnes sont impliquées. Il faut toutefois souligner que le travail a bien été réalisé une fois l’équipe mobilisée sur ce sujet.
Aspect stockage
Les baies SAN utilisées
Le stockage est un aspect fondamental du cloud. Nous avons à l’université Lyon 2 la chance de disposer d’un matériel performant à ce niveau. En effet , notre infrastructure serveur fonctionne grâce à des baies SAN EMC VNX5300. Nous avons deux sites physiques (Lyon et Bron) contenant 2 baies de ce type, utilisant des « recover point » (figure 14) qui permettent la réplication en temps réel de ce stockage. Les « recover point » présents sur chaque site utilisent un « lien IP » direct entre les deux sites, assurant ainsi de bonnes performances pour le stockage répliqué.
Les baies EMC sont le fleuron de notre stockage. Celles-ci ont remplacé des baies HP d’ancienne génération (une baie HP EVA4000 et une baie HP EVA 4400). Ces baies ne sont plus supportées par le constructeur, c’est pourquoi seules nos machines de test uniquement les utilisent. Les baies HP en question ont l’avantage d’être simples d’utilisation et plus intuitives que les baies EMC qui sont plus complexes.
Dans le cadre du projet, nous utiliserons les baies présentes sur le site de Lyon (par opposition à celui de Bron), car c’est là où se situent les serveurs ESXi que nous prendrons pour soutenir l’activité des machines virtuelles issues du cloud. Pour fournir différents niveaux de service, nous utiliserons donc la baie EMC de Lyon ainsi que la baie HP 4000 de Lyon.
La figure 15 présente quelques concepts clés utilisés par la baie à savoir les disques physiques, les storage pools et les LUN. Les disques physiques sont de différents types, à l’université nous avons des disques SAS pour l’immense majorité et aussi quelques disques Flash. La configuration des storage pool est assez simple puisque nous n’en avons qu’un seul (l’avantage est que c’est plus simple à gérer comme cela). Dans ces storage pool on découpe des LUNs. C’est la plus petite unité logique que l’on peut présenter à un serveur.
La baie EMC permet une gestion très fine des performances grâce à sa technologie d’auto-tiering et grâce à la présence de disque ssd et sas. L’auto -tiering est une technologie qui permet de placer les données (blocks) les plus fréquemment accédées sur les disques les plus rapides (ssd). Concrètement chaque heure, la baie calcule quels blocks doivent être promus sur les disques ssd et les déplace une fois par jour (la nuit). Un système de statistiques interne à la baie permet cette opération.
C’est une opération complètement automatisée. Tout ceci est fait dans l’optique d’améliorer les performances et les accès disques et in fine l’expérience utilisateur.
Configuration des switchs fibres
Un switch fibre est un équipement utilisant le protocole FCP (Fibre Channel Protocol). Celui-ci permet d’associer un serveur à son stockage. L’université dispose de deux « fabriques » (ensembles des switchs FC) dans un souci de redondance.
Ainsi la perte d’un switch FC ou d’un port n’entame pas le bon fonctionnement de l’infrastructure.
Le projet de cloud n’a pas nécessité de modification particulière au niveau des switchs fibres. Cependant j’ai déjà eu l’occasion de faire du zoning lorsqu ’on m’a demandé de rajouter des serveurs physiques à notre ferme de serveurs ESXi à l’université. Ainsi, une bonne lecture de la configuration de ces switchs m’a aidé pour avancer rapidement sur les problématiques liées au stockage. Les modifications sur ces switchs sont à effectuer avec précaution car une erreur peut déconnecter un serveur de son stockage (ou plusieurs) et provoquer des corruptions en plus d’un arrêt du service délivré par le ou les serveurs impactés. L’université utilise des switchs fibre Brocade 10Gb. La configuration se fait via l’interface web développée en java dont voici un aperçu sur la figure 21.
Installation du produit vcloud
L’installation du produit vCloud se déclenche via un fichier exécutable binaire compatible avec Red Hat 6. J’ai utilisé notre modèle de machine virtuelle installée en Red Hat 6 64 bit. Pour cela il m’a fallu adresser une demande à notre équipe réseau afin qu’elle me fournisse une adresse ip, ainsi qu’une entrée dans notre dns (vcloud.univ-lyon2.fr).
Une fois le modèle cloné, j’ai installé les VMware Tools (qui ajoutent des fonctionnalités), entré le nom de la machine, modifié la configuration de la carte réseau afin de la faire correspondre à l’adresse que l’on m’avait fournie et modifié le nom de la machine (hostname). La préparation de la vm a été assez rapide au final.
Après cela il faut ensuite installer le binaire fourni par VMware (figure 30).
Lors de l’installation du produit on configure l’accès à la base de données en utilisant l’utilisateur de la base de données que l’on avait créé au préalable et en renseignant son mot de passe.
Une fois installé le service vmware-vcd démarre et lance l’interface web par laquelle on configure ensuite l’outil : https://vcloud.univ-lyon2.fr. On peut cependant rendre le démarrage automatique afin qu’il démarre en même temps que la vm via la commande.
L’accès web nécessite un navigateur compatible (internet explorer, firefox ou chrome) ainsi qu’adobe flashplayer et un plugin dédié VMRC.
La première connexion à l’interface web nous demande d’installer le certificat car nous utilisons un certificat auto signé. Nous aurions pu utiliser un certificat signé par une autorité de certification reconnu par le navigateur, ce qui a pour effet d’enlever le message d’alerte du navigateur lors de la première connexion. Il faut savoir que les certificats signés par une autorité de certification ont un certain coût.
La première connexion à vCloud (figure 31) permet d’installer la licence du produit qui dépend du nombre de processeurs utilisés par les machines physiques qui font tourner vCloud. Nous avons une licence pour 6 sockets de CPU soit 3 serveurs physiques possédant deux sockets chacun. Après la licence on crée un compte administrateur de l’outil en optant pour un mot de passe complexe, on ajoute l’adresse mail de l’administrateur et on donne un nom à la « cellule » du cloud que l’on vient d’installer.
Il faut noter que notre installation ne contiendra qu’une seule « cellule » mais il est possible d’en joindre plusieurs dans le cas d’énormes infrastructures réparties géographiquement sur plusieurs sites. Après cela, l’une des premières choses à faire est de joindre vCloud à vCenter. Cette opération nécessite un compte administrateur avec un niveau de droits élevé dans vSphere.
Ensuite il faut joindre vCloud à vShield, ce même vShield doit déjà être enregistré dans le vCenter en question sous forme de plugin. On utilise pour cette jonction le compte administrateur de vShield sur la figure 32.
Configuration de vCloud
Parmi les premiers utilisateurs de vCloud il y a le « pôle étude » qui travaille à la DSI. Il s’agit d’une population de développeurs et de chefs de projets dont les besoins sont souvent les mêmes : un serveur d’application tomcat, un serveur apache, un serveur de base de données… Nous connaissions ces besoins avant le début du projet étant donné que le pôle opération pour lequel je travaille est fournisseur de ce type de serveurs assez régulièrement. Les besoins étant très spécifiques, j’ai choisi de créer une organisation au sens «vCloud » du terme pour le pôle étude.
Une deuxième organisation est dédiée au pôle opération auquel j’appartiens.
La distinction entre les deux organisations repose sur les droits et la possibilité de publier des machines virtuelles pour le pôle opération, là où le pôle étude est tributaire du travail de notre pôle.
Les machines virtuelles issues du cloud doivent être isolées des machines virtuelles servant à l’infrastructure, c’est-à-dire la base de données, vShield et le serveur vCloud. D’un point de vue réseau, j’ai créé un switch virtuel distribué entre les serveurs ESXi, la figure 34 le décrit. Ceci permet de créer un objet de type switch distribué dans vSphere qui permet de partager des VLAN’s entre les serveurs ESXi.
Concrètement c’est une fonctionnalité de vSphere qui nécessite un haut niveau de licence contrairement à la fonctionnalité « switch standard ». Un des intérêts est par exemple de créer un VLAN sur x hôtes ESXi en une seule fois au lieu d’avoir à le créer individuellement sur chaque ESXi.
Tests au niveau réseau
J’ai réalisé plusieurs séries de tests au niveau réseau. Les tests effectués sur la plate-forme de test ont permis d’appréhender le produit et de concevoir une architecture cohérente avec les besoins de l’université. Les tests ont surtout été effectués au niveau réseau afin de comprendre comment isoler correctement le cloud. Ceci répond au besoin de sécurité.
Cette option peut s’avérer utile si l’on a une grande architecture et une qualité de service à assurer auprès de ses clients. Dans le cas de l’université je n’ai pas eu à l’utiliser. Des tests ont été réalisés afin de bien comprendre comment fonctionnait l’outil et pour connaître l’étendue des possibilités.
Recette de la plate-forme de test
Deux organisations ont été définies, c’est pourquoi j’ai choisi un utilisateur de chaque pôle afin de pouvoir faire tester l’ensemble de ce que j’allais créer dans vCloud. Bien sûr j’ai dû prendre le temps de les former à ces nouveaux outils. Même si l’interface web de vCloud est assez accessible, certains termes spécifiques au produit (vApp, catalogue…) le rendent moins facile à appréhender.
La mise en place de la plate-forme de test est terminée, les tests au niveau réseau ont notamment permis de dégager de bonnes pratiques en matière d’isolation des organisations. Nous pouvons décrire la mise en place de la plate-forme de production.
Mise en place de la production
Etude sur l’upgrade de la version vSphere de production et impacts sur la production
Le projet vCloud a démarré avant le début du projet de montée de version de vSphere pour notre infrastructure serveurs. Cependant, il a fallu réfléchir à l’impact de l’un sur l’autre. Pour revenir aux sources du projet de montée de version vSphere, il faut savoir que notre version de vSphere (5.0) ne supportait pas par exemple des machines virtuelles en Windows 2012 Server. Pour avoir testé personnellement l’installation d’un serveur de test en Windows 2012 sur un ESXi en 5.0, l’opération se soldait par un « écran bleu » lourd de sens.
Au-delà de cette limitation, la montée de version vSphere nous a également permi de remplacer certaines machines physiques par des machines plus puissantes. A nombre de machines physiques égal, nous avons augmenté la puissance de calcul (CPU et RAM) de notre ferme de serveurs. Le calcul est intéressant car les licences chez VMware se basent sur le nombre de sockets physiques utilisé par les serveurs ESXi. Cette puissance de calcul accrue s’est faite sans augmentation des coûts de licence.
Notre prestataire a été chargé de mettre en œuvre ces changements, mais il l’a fait après la mise en production du cloud. C’est au moment de cette étude que j’ai préconisé l’achat d’un nouveau serveur vCenter dédié à vCloud. Ce choix impliquait 5000 euros de dépense en plus. Il se justifie par le cloisonnement qu’apporte un vCenter dédié. En termes d’architecture il est intéressant d’isoler les sources potentielles de problèmes. Nous connaissions à l’époque plusieurs plantages récurrents du serveur vCenter (avant la montée de version en 5.5) et je trouvais préférable de ne pas partager le même serveur vCenter entre le cloud et l’infrastructure serveur. Cela donne aussi un peu plus de souplesse et permet de mettre en maintenance le cloud sans impacter nos autres serveurs de production (l’inverse est vrai également).
Pour ce qui est de l’impact de la montée de version vSphere sur le cloud, il s’est résumé à une interruption du service d’environ une heure liée à la maintenance des vm. Aussi cette montée de version a permis de récupérer un matériel plus récent et d’abaisser le nombre de CPU utilisés pour le cloud de six à quatre. En réalisant cette opération, on abaisse aussi les coûts de licence lié au support annuel.
Création d’une nouvelle base de données Oracle pour le nouveau serveur vCenter
Le choix de créer un nouveau serveur vCenter implique de créer une nouvelle base de données. Pour cela, trois options sont possibles : IBM DB2, Microsoft SQL Server ou Oracle. Le produit vCloud nous ayant déjà demandé d’installer une base de données Oracle, nous choisissons de créer une deuxième base de données sur le premier serveur de base de données utilisé par vCloud.
Techniquement la création de la base de données est très similaire à la première. Nous utilisons un « SID » différent. Le SID identifie la base de données dans Oracle.
Installation de vCenter server
L’installation de vCenter se fait sur un serveur Windows 2008 R2. Il existe également une appliance Linux Suse qui peut remplacer un vCenter Windows. Cependant la version 5.0 de cet appliance est limitée au support de cinquante vm seulement. Très intéressant pour une organisation de petite taille notamment pour les gains en termes d’administration, l’appliance me semblait encore être un produit trop jeune et trop limité pour pouvoir l’utiliser à cet endroit. Historiquement le serveur vCenter est une application que l’on installe sur un serveur Windows et j’ai poursuivi dans cette voie. Avant d’installer le produit vCenter j’ai donc utilisé un modèle de serveur Windows 2008 R2 que nous utilisons fréquemment. Rien de particulier à noter sur le déploiement, hormis le fait que je l’ai jointe à l’active directory (service d’annuaire Microsoft). La base de données de vCenter est donc déportée sur un autre serveur et cela nous oblige à installer le client oracle et à configurer un lien ODBC.
Migration de vShield
L’appliance vShield était à ce stade encore rattachée à l’ancien serveur vCenter de notre infrastructure serveur (« Nurn » sur la figure 43). J’aurais pu me contenter de redéployer un nouvel appliance vShield sur le nouveau vCenter mais il me semblait intéressant de garder la configuration de l’outil tel que je l’avais faite et donc de réutiliser les modifications. C’est la raison pour laquelle j’ai décidé de migrer la vm vShield de vCenter.
Pour migrer vShield, il faut d’abord déréférencer vShield de l’ancien vCenter au niveau des plugins de vCenter (figure 44). Pour cela on utilise l’url de ce type : https://vcenter.domain.local/mob: On arrive sur une page web référençant l’ensemble des plugins du vCenter, sur lequel on est connecté mais avec des noms un petit peu complexes. Par exemple vShield apparaît sous ce nom : com.vmware.vShieldManager,vShield Manager. On choisit unregisterExtension sur le plugin vShield puis invoke Method.
|
Table des matières
Introduction
I. Cloud computing
I.1. Définition du cloud computing
I.2. Les différentes familles de cloud (IaaS, PaaS et SaaS)
I.2.1. IaaS
I.2.2. PaaS
I.2.3. SaaS
I.3. Les différents types de cloud
I.3.1. Le cloud privé
I.3.2. Le cloud public
I.3.3. Le cloud hybride
I.4. Liens entre virtualisation et cloud
I.5. Les apports de la virtualisation
II. Présentation du projet
II.1. Présentation de l’université Lyon 2 et sa DSI
II.2. Les besoins de l’université
II.3. Les solutions possibles
II.3.1. Les cloud publics
II.3.2 Les cloud privés à base de technologie Microsoft
II.3.3. Les cloud privés à base de projets Open source : Openstack, Cloudstack
II.3.4. Les cloud privés à base de technologie VMware: vCloud Director
II.4. Mon rôle dans le projet
II.5. Planning prévu
III. Présentation de la solution retenue : vCloud Director
III.1. La couche vSphere et l’infrastructure physique
III.1.1. La couche vSphere
III.1.2. L’infrastructure physique
III.2. La couche vCloud
III.2.1. Le serveur vCenter
III.2.2. Architecture générale de vCloud
III.2.3. Concept vCloud : les organisations
III.2.4. Concept vCloud : les vDC (virtual DataCenter) d’organisation
III.2.5. Concept vCloud : les VDC fournisseur (PvDC)
III.2.6. Concept vCloud : les Edge Gateway
III.2.7. Concept vCloud : Réseaux externes
III.2.8. Concept vCloud : Pool de Réseaux
III.2.9. Concept vCloud : vApp et VM
III.3. Les prérequis de vCloud
III.3.1. Choix des versions d’ESXi et de vSphere
III.3.2. vCenter
III.3.3. vShield
III.3.4. Bases de données
III.4. Chargeback
III.5. VCloud Connector
IV. Mise en œuvre de la solution vCloud
IV.1.0. Choix de la version de Red Hat
IV.2.0. Choix de la version d’Oracle
IV.3.0. Création de la base de données Oracle
IV.4.0. Déploiement et configuration de vShield Manager
IV.5.0. La génération des certificats auto signés
IV.6. Bilan de l’infrastructure à cette étape
IV.6.1. Points réalisés
IV.6.2. Points réalisés avant le début du projet
V. Mise en place d’une maquette de test
V.1.0. Les Objectifs
V.2.0. Création d’un nouveau VLAN
V.3.0. Aspect stockage
V.3.1. Les baies SAN utilisées
V.3.2. Création de LUNs sur la baie EMC VNX5300
V.3.3. Création de LUNs sur la baie HP EVA
V.3.4. Configuration des switchs fibres
V.3.5. Configuration dans vSphere au niveau du stockage
V.4.0. Installation du produit vcloud
V.5.0. Configuration de vCloud
V.6.0 Tests au niveau réseau
V.7.0. Recette de la plate-forme de test
VI. Mise en place de la production
VI.1.0. étude sur l’upgrade de la version vSphere de production et impacts sur la production
VI.2.0. Création d’une nouvelle base de données Oracle pour le nouveau serveur vCenter
VI.3.0. Installation de vCenter server
VI.4.0. Migration de vShield
VI.4.0. Mise en place du monitoring avec nagios et centréon
VI.5.0. Politique de backup des vms
VI.6.0. Modifications sur la base de données
VI.6.1. Passage en Archive Log des bases de données
VI.6.2. Démarrage automatique des bases de données
VII. Configuration de l’infrastructure de production
VII.1.0. Gestion des niveaux de service
VII.1.1. Gestion des niveaux de service pour le stockage
VII.1.2. Gestion des niveaux de service pour la RAM et le CPU
VII.1.3. Gestion des niveaux de service pour le réseau
VII.2.0. Utilisation des clones liés
VII.3.0. Customisation des vm
VII.3.1. Customisation des vm Windows
VII.3.2. Customisation des vm Linux
VII.4.0. Gestion des droits
VII.5.0. Gestion des licences (vSphere, vCloud et système d’exploitation)
VII.6.0. Phase de recette
VII.7.0. Documentation, partage des connaissances et présentations du produit
VII.8.0. Migration vers la version vSphere 5.5 de l’infra serveur et impact sur vCloud
VII.9.0. Mise en place d’une vApp pour les serveurs qui gèrent vCloud
VII.10.0. Changement de serveurs ESXi
VII.11.0. Utilisation de EVC
VII.12.0. Backup des vm du cloud
VII.13.0. Packaging ThinApp
VII.14.0. Upgrade du serveur vCenter en 5.1
VII.15.0. Les difficultés rencontrées lors du projet
VII.15.1.Oracle
VII.15.2. Problème de gestion des objets vCloud
VII.15.3. Problème des licences
VIII. Les évolutions futures
VIII.1.0. Problématique liée au support
VIII.2.0. Les alternatives à vCloud
VIII.2.1. OpenStack
VIII.2.2. CloudStack
Conclusion
Annexes
Création de la base de données Oracle
Passage en Archive Log des bases de données
Script de démarrage automatique de la base de données
Table des figures
Table des tableaux
Bibliographie
Télécharger le rapport complet
