Migration de Q4 2009 Numéro 2 Edito vsphere est un ensemble de logiciels qui représente la nouvelle et 4ème génération du socle de virtualisation VMware. En effet, l éditeur propose selon un cycle d environ trois ans des mises à jour majeures de la gamme de virtualisation de serveurs. Un peu d historique : 1. Juillet 2003 première mise à jour majeure et disponibilité de ESX Server 2.0 2. Juin 2006, ESX 3.0 VirtualCenter 2.0 : Virtual Infrastructure 3 3. Mai 2009, ESX 4.0, vcenter 4.0 : vsphere VMware a profité de la dernière génération pour mettre en phase les numéros de version en 4.0 pour ESX et vcenter. L upgrade des serveurs ESX 2.x vers 3.0 nécessitait des procédures complexes et des arrêts planifiés requis pour la mise à jour des Datastores VMFS. La migration ESX génération 3 vers vsphere n est pas aussi contraignante et ceci sur au moins deux critères : 1. Pas de conversion VMFS 2. Evolution de VMware Update Manager pour la mise à jour majeure ESX Merci à Nassima BENAISSA, formatrice VMware Certified Instructor (VCI), pour la rédaction de ce cahier technique qui vous assistera dans les différents scénarios de migration Virtual Infrastructure vers vsphere. N'hésitez pas à nous faire part de vos commentaires : cta@amosdec.fr Bonne lecture!
Avec ombre portée Sans ombre portée Cahier technique Amosdec
Sommaire Introduction I : ce qui change 1. Virtual Center 2. Serveur ESX / ESXi a.vsphere Host Utility b.vcenter update manager 3. Datastore 4. Machine Virtuelle 5. Licence II Scénarios d upgrade 1. Introduction 2. Scénario 1 a. Présentation b. Installation de vsphere client c. Mise à jour de vcenter Server d. Mise à jour des Machines Virtuelles e. Mise à jour licences 3 Scénario 2 a. Présentation b. Installation de vsphere client c. Mise à jour des serveurs d. Mise à jour des Machines Virtuelles e. Mise à jour des licences III Compatibilité CPU 1. Compatibilité CPU 2. VMware CPU Host Info IV Sauvegarde de l infrastructure 1. Virtual Center a. Machine Virtuelle V Migration en vsphere 1. Scénario 1 : Update Manager a. Machine V4 b. Machine V7 : mise à jour avec Update Manager c. Mise à jour mannuelle d. Serveurs ESX / ESXi 2. Scénario 2 : vsphere Host Update Utility a. Serveurs ESX / ESXi b. Machine Virtuelle 3 Scénario 3 : mise à jour à froid VI : Post Upgrade 2 2 3 3 3 3 4 4 5 5 6 6 7 7 8 8 8 8 9 9 9 9 10 10 11 12 12 13 14 14 16 17 19 20 20 21 23 23 27
Introduction L objectif de ce cahier technique est de couvrir les différentes étapes d une mise à jour complète d une infrastructure VI 3 en vsphere. La première partie de pré- Upgrade concernera la compatibilité et la sauvegarde de l infrastructure 3.5. La partie de migration sera présentée par des scénarios utilisant différents moyens et outils. L illustration de ces scénarios, se fera grâce à des captures d écrans et des diagrammes Unified Modeling Language (UML). La dernière partie du cahier sera consacrée au «Post-Upgrade». Dans ce cahier, nous aborderons la mise à jour du Virtual Center, des serveurs ESX/ESXi ainsi que des machines virtuelles. La configuration et l optimisation de vsphere feront l objet de prochains cahiers. 1
I VI3 vers Vsphere : ce qui change Le processus d upgrade est différent de celui utilisé lors du passage de la version 2 en 3. Ces changements concernent aussi bien le vcenter Server, que l ESX/ESXi. Pour aller plus loin : Formation Amosdec vsphere 4 - What's new : http://www.amosdec.com/fr/formations/ White Paper VMware vsphere 4 : http://www.vmware.com/support/vsphere4/doc/vsp_40_new_feat.html 1. Virtual Center Un des changements qui concerne la mise à jour de Virtual center est le fait que l exécutable «autorun.exe» d installation, redirige vers une interface HTML qui propose des liens de téléchargement de différents modules ou composants comme : vcenter Server vcenter Guided Consolidation vsphere Client vcenter Update Manager vcenter Converter L autre changement est l obligation de faire une mise à jour du schéma de la base de données avant de faire celle du vcenter Server afin de s assurer de la consistance et de la compatibilité du nouveau schéma, avant de lancer le processus de migration du vcenter Server. Etant donné la criticité de cette étape, une sauvegarde est fortement recommandée. La partie sauvegarde sera traitée ultérieurement dans ce cahier. 2. Serveur ESX / ESXi Deux outils permettent de passer de ESX/ESXi 3.5 vers ESX/ESXi 4.0 : «vsphere Host Update Utility» et le «vcenter Update Manager». 2
a. vsphere Host Utility Cet utilitaire permet de mettre à jour des serveurs ESX/ESXi gérés par un vcenter Server. De plus, une fois la migration réalisée, il permettra d appliquer facilement des patchs et de mettre à niveau l infrastructure. Ce moyen de migration est plutôt réservé aux petites infrastructures (moins de 10 ESX/ESXi, sans vcenter Server ni vcenter Update Manager). Il offre une gestion simple et assistée de la migration de plusieurs serveurs un à un, grâce à une interface qui montre l état de progression de la migration. L installation et l utilisation de cet utilitaire seront détaillées dans la partie Upgrade de ce cahier. b. vcenter update manager Cet outil ne concerne que les ESX/ESXi gérés par un vcenter server. Le module Update manager 4.0 permet de mettre à jour les différents serveurs ainsi que les machines virtuelles. A la différence du «Host Update utility», le processus de migration est industrialisé en créant des baselines de mise à jour comme le montre la figure suivante. Update Manager Administration Ces mises à jour peuvent être appliquées aux différents objets de l inventaire du serveur vcenter. Ceci simplifie le processus de migration d une infrastructure, en respectant les recommandations ainsi que le bon enchainement des séquences du processus de migration. Un exemple : la mise à jour du matériel des machines virtuelles s effectue après celle des VMware Tools. 3. Datastore Aucun besoin de migration, car le format reste le même : VMFS 3. En ce qui concerne les Datastores en VMFS 2, ils sont supportés en Read-Only. Pour ceux qui sont encore en VMFS 2 une migration en version 3 s impose pour utiliser les machines virtuelles. 3
4. Machine Virtuelle La mise à jour des «VMware Tools» est obligatoire avant de lancer celle du «Virtual hardware». Si l ordre n est pas respecté, les machines risquent de perdre la connectivité réseau. Le «vcenter Update Manager» se charge de réaliser les différentes étapes automatiquement sur un ensemble de machines virtuelles et de templates. 5. Licence La gestion des licences reste centralisée par vcenter Server. En revanche, le fichier de licences, ainsi que le serveur de licences disparaissent, ce qui dispense d une installation, d une configuration et d un suivi supplémentaires. Ces derniers sont remplacés par une clé de licence de 25 caractères. Ce mécanisme permet la gestion uniquement de produits vsphere. En phase de transition, il faudra combiner les deux modes : serveur de licences et clés afin de gérer les différentes versions. La configuration et l activation de la clé de licence sont simplifiées (quatre étapes au lieu de onze précédemment). Chaque ESX/ESXi nécessite une clé de licence, ainsi que le vcenter Server. Une seule clé par produit est attribuable. Aucune modification ou remplacement de la clé ne sera plus nécessaire après l application de patchs ou de mises à jour mineures. Par contre, pour une mise à jour plus importante (comme le passage d une version standard en entreprise), il faut remplacer la clé existante. Il suffit pour cela de se connecter sur le portail de licences du site de VMware (http://www.vmware.com/licensemgmt/login.lic) et de mettre à jour sa licence. Important Dans un environnement professionnel moderne, les données doivent être disponibles à tout instant. C est la sécurisation des flux d informations. Avec la généralisation des environnements virtuels, les professionnels de l informatique doivent veiller à ce qui ces nouveaux espaces de travail soient aussi sécurisés que les anciens systèmes physiques. L apport de vsphere ne s arrête pas là, de nombreuses fonctionnalités et mécanismes sont apparus. La liste des nouveautés est longue. Amosdec propose une formation «What s New?» de deux jours qui couvre les nouveautés de vsphere. 4
II Scénarios d Upgrade 1. Introduction Avant de commencer votre migration de la, il faut déterminer la topologie de votre infrastructure VMware. Cette topologie est déterminée selon son organisation. Est-elle constituée de «Clusters» ou non? : Ressource Pools VMware High Availability (HA) VMware Distributed Ressource Scheduler (DRS) Comment ces derniers sont ils configurés? Quel type de stockage est utilisé (Local, SAN FC, iscsi, )? La figure précédente montre les différents scénarios de déploiement possibles. Elle permet d identifier l organisation de votre infrastructure. Les phases du processus de migration sont identiques pour tous les scénarios. Il y a trois phases correspondant à un traitement selon une granularité décroissante. Ces étapes peuvent être réalisées à des moments distincts mais en respectant un ordre précis. Ceci permet de structurer le projet de migration et de mettre en place une transition progressive par paliers afin de se familiariser au fur et à mesure avec les nouvelles fonctionnalités de vsphere. Il est impératif de respecter l ordre des différentes étapes du processus de migration. Le non respect de cet ordre peut provoquer la perte de données. Le respect de l enchainement ne concerne pas seulement les phases du processus de mise à jour mais aussi les différentes tâches au sein de chaque étape. 5
En règle générale, il n est possible d effectuer la mise à jour de chaque composant que dans une seule direction. Par exemple, après la migration vers vcenter Server 4.0 aucun retour en VirtualCenter 2.x n est envisageable, excepté s il y a eu planification et par conséquent la réalisation des sauvegardes appropriées, permettant ainsi de faire une restauration. De plus, il n est possible de passer à l étape suivante de migration que lorsque la précédente est achevée. Comme certaines actions ne sont pas réversibles et peuvent concerner différents composants de l environnement de production, il est impératif de respecter les étapes ainsi que les guides de compatibilité. Pour une mise à jour sécurisée, VMware recommande d utiliser le «vcenter Update Manager». Le processus de migration en vsphere se compose de trois étapes majeures : Phase 1 : mise à jour du vcenter Server et VMware Update Manager. Phase 2 : selon la topologie et la taille de votre infrastructure, choisir le mode de migration approprié : VMware Update Manager, Host Update Utility ou plus radical, une installation. Phase 3 : mise à jour complète de vos machines virtuelles. La mise à jour des licences n est pas considérée comme étant une étape du processus de migration. Vous pouvez la réaliser à partir de la fin de la première phase, à n importe quel niveau du processus. Selon la topologie de votre infrastructure et en respectant les étapes de migration, quelques scénarios sont possibles. 2. Scénario 1 a. Présentation Ce scénario d upgrade repose sur l utilisation du «vcenter Update Manager» qui simplifie le processus de mise à jour des serveurs et des machines virtuelles, en permettant de réduire les temps d arrêt. Pour l utiliser, il faut que votre infrastructure soit composée de serveurs ESX/ESXi 3.5 gérés par un Virtual Center 2.x, et bien évidemment, disposer de vcenter Update Manager. Avant de démarrer le processus de migration pensez aux points suivants : Vérifier la compatibilité de la base de données (BD). Avoir les permissions nécessaires sur la base de données pour réaliser la mise à jour du schéma de la base. Sauvegarder la base de données du VirtualCenter 2.x. Sauvegarder le certificat SSL du VirtualCenter 2.x. 6
Notes Pendant cette phase aucune opération de clonage ou de création de machine virtuelle n est autorisée. Les clusters VMware High Availability (HA) et VMware Distributed Resource Scheduler (DRS) sont aussi reconfigurés. Vérifiez néanmoins que la reconfiguration automatique a été correctement réalisée. Dans certains cas, une reconfiguration manuelle peut être nécessaire. b. Installation du «vsphere client» Vous pouvez installer le «vsphere Client» sur la même machine que le «VI3 Client». Pourquoi garder l ancienne version du Client? Pour la simple raison que seul le «VI3 Client» permet de se connecter directement aux versions précédentes : le Virtual Center Server et les ESX/ESXi 3.5. c. Mise à jour du vcenter Server vcenter Update Manager met les serveurs en mode maintenance avant de démarrer la phase de migration. Une fois celle-ci complétée, les serveurs sont automatiquement reconnectés au vcenter Server 4.0. En cas de dysfonctionnement, vcenter Update Manager permet de revenir en arrière et de retrouver la version précédente des serveurs ESX/ESXi. 7
d. Mise à jour des Machines Virtuelles Utiliser vcenter Update Manager pour mettre à jour vos machines virtuelles permet d actualiser les VMware Tools puis le virtual hardware. Le respect de cet ordre évite tout risque de perte de connexion réseau ou dysfonctionnement. De plus vcenter Update Manager peut faire automatiquement une sauvegarde des machines virtuelles sous forme de snapshot pour permettre un retour en arrière. e. Mise à jour des licences Après avoir récupéré votre nouvelle clé de licence, par mail ou sur le portail de licences de VMware, activez cette licence à travers le vcenter Server. 3. Scénario 2 a. Présentation Si votre infrastructure ne contient que des hosts ESX/ESXi 3.5 standalone, vous pouvez utiliser «vsphere Host Update Utility» pour faire l upgrade de vos hosts et le vsphere Client pour mettre à jour les machines virtuelles. 8
b. Installation de «vsphere client» Au cours de l installation, exécutez également le «vsphere Host Update Utility» qui lance le processus de mise à jour des serveurs. c. Mise à jour des serveurs En cas de problème un retour en arrière de l ESX/ESXi 4.0 en version 3 est possible (dual boot). d. Mise à jour des Machines Virtuelles Utilisez vsphere Client pour mettre à jour les machines virtuelles en respectant cet ordre: 1. Mettre à jour les VMware Tools. 2. Mettre à jour le virtual hardware des machines de la version 4 en version 7. Il faut noter qu une machine virtuelle dont le Virtual Hardware est en version 7 ne pourra plus être exécutée sur un serveur ESX/ESXi 3.5. e. Mise à jour des licences Et pour finir, mettre à jour vos licences au travers du vcenter Server si vous en avez un, ou par le vsphere Client. Important Ces étapes doivent être réalisées sur tous les ESX/ESXi, un par un, ainsi que sur les machines virtuelles s exécutant dessus. 9
III Compatibilité CPU Un des pré-requis dans vsphere est le fait d avoir des CPU 64-bit long mode (par exemple pour un CPU Intel, il faut avoir EM64T et Intel VT pour la compatibilité VMware 64 bit), ce qui est le cas pour les serveurs récents. Pour vérifier la compatibilité de vos serveurs, vous disposez de différents outils. Pour plus d informations CPU ID Utility : https://www.vmware.com/download/shared_utilities.html VMware CPU Host Info : http://www.run-virtual.com/?page_id=155 1. Compatibilité CPU Un outil fourni par VMware permet de connaître les caractéristiques CPU de vos serveurs. Il suffit de booter le serveur sur l image iso de l utilitaire (ce qui nécessite un redémarrage de votre ESX/ ESXi). Ce qui nous intéresse pour notre processus d Upgrade : le support du 64 bit long mode et des guest-os 64 bit. Pour ce type de CPU, qui supporte le «64-bit long mode» et pas le «64-bit VMware guest OS», on peut installer vsphere sur ce serveur, mais on ne peut exécuter que des guest OS 32-bit. Ce qui n est pas le cas pour le second serveur dont les caractéristiques CPU supportent les deux : on peut installer vsphere et exécuter des guest OS 32 ou 64-bit. 10
2. VMware CPU Host Info Cet outil, «VMware CPU Host Info», permet de savoir si votre CPU est compatible 64-bit mais seulement en mode «Intel VT».(Autrement dit, si vous pouvez exécuter des machines virtuelles un OS 64-bit). Il permet aussi de savoir si les serveurs sont compatibles avec la nouvelle fonctionnalité de vsphere : Fault tolerance (FT). Après installation de l outil, il suffit de spécifier le serveur vcenter ainsi que le compte administrateur ayant les droits sur celui-ci. Après vérification et connexion, un tableau nous renseigne sur les caractéristiques CPU de l ensemble des serveurs gérés par le serveur vcenter. On y retrouve le support ou non du bit NX/XD, les jeux d instructions supportés, la compatibilité Fault Tolerance (FT),. Un outil simple à utiliser et qui 11
IV Sauvegarde de l infrastructure Après avoir vérifié la compatibilité de votre infrastructure actuelle pour une mise à jour en vsphere et avant de se lancer dans le processus d Upgrade quelques mesures sont à prendre en amont. En effet, certaines étapes du processus de migration ne permettent pas de retour en arrière. Par exemple, une fois en vcenter Server 4.0, on ne peut plus revenir en VirtualCenter 2.x sauf, si un backup adéquat a été réalisé. 1. Virtual Center Si vous voulez être certain de pouvoir restaurer votre configuration de vcenter dans le cas où l Upgrade de ce dernier ne soit pas complet, un backup s impose. Plus précisément, celui de sa base de données car en vsphere le schéma de la base change, ce qui empêche tout retour en arrière. Pour la restauration il suffit de suivre ces étapes : 1. Désinstallation complète du vcenter Server 4.0. 2. Restauration de la version précédente de la base de données du vcenter. 3. Réinstallation du vcenter Server, en sélectionnant la base de données (restaurée dans l étape précédente), durant l installation. 4. Réinstaller le serveur de Licences, s il y en avait un initialement. Une autre alternative est possible, si le Virtual Center est une machine virtuelle hébergeant sa propre base de données, en utilisant la technologie de snapshot. En cas d échec de mise à jour un «revert to snapshot» permet de revenir à la situation initiale. 12
a. Machine Virtuelle Il y a différents moyens de réaliser des sauvegardes de machines virtuelles : Backup des fichiers des machines virtuelles comme le.vmdk ou.dsk et les fichiers.vmx Utiliser un agent de backup classique qui réalise la sauvegarde de la machine virtuelle au niveau Guest OS. Cette méthode nécessite pour la restauration, la création de la machine virtuelle et l installation du Guest OS dans cette dernière, puis d utiliser la procédure de restauration classique. Cloner la machine virtuelle et stocker le clone dans un autre Datastore. Utiliser des solutions dédiées comme : Veeam Backup & Replication, vranger,. 13
V Migration en vsphere Dans cette partie nous allons aborder différents scénarios de migration vers vsphere, en utilisant trois méthodes citées précédemment : «VMware Update Manager» «Host Update Utility» Utilisation de l image ISO d installation. 1. Scénario 1 : Update Manager Pour ce premier scénario Virtual Center Server 2.5 gère des serveurs ESX et ESXi 3.5. Sachant que des machines virtuelles s exécutent sur chacun des serveurs. VMware Update Manager est installé. Afin de pouvoir suivre les différentes étapes de la mise à jour en utilisant l outil Update Manager, une illustration basée sur un diagramme d activités, ainsi que des captures d écran sont proposés. 14
Avant d effectuer l installation du vcenter Server 4.0, une vérification de la compatibilité et de la version de la base de données (BD) est effectuée. La mise à jour de cette dernière est impérative puisque le schéma change. Une fois la mise à jour du Virtual Center achevée, la connexion au serveur vcenter est autorisée uniquement à travers le vsphere Client. D où l obligation de mettre à jour ce dernier. La page HTML lancée par l autorun du vcenter propose d installer/mettre à jour le VI Client. En utilisant le vsphere Client on peut se connecter au vcenter Server afin d installer le plugin d Update Manager qui servira à mettre à jour le reste de l infrastructure. 15
La mise à jour des serveurs ESX/ESXi 3.5 se fait facilement avec Update Manager. Concernant la mise à jour des machines virtuelles, rappelons que cette étape n est pas à réaliser immédiatement après celle des serveurs ESX/ESXi. En effet, la cohabitation et la gestion des machines virtuelles de versions différentes est possible. On illustre ensuite les limitations dues à la gestion d un ensemble hétérogène de serveurs (3.5 et 4.0) et de machines virtuelles (version 4 et 7 pour le virtual Hardware). a. Machine V4 On peut continuer à exécuter les machines en virtual hardware version 4 sur un serveur ESX 4.0 ou sur un ESX 3.5, avec par exemple, la possibilité de migrer les machines d un ESX 3.5 (voir figure A et B) vers un serveur 4.0 et, inversement. Figure A La machine Win4 est une machine Windows en hardware version 4, initialement située sur un serveur ESXi 3.5 (esx4form3), dans le Datacenter Upgrade. Au sein du même Datacenter, il y a le serveur esx3form3 de version 3.5, sur lequel s exécute une machine Linux en hardware version 4 : Slax3. Après migration de ces machines et sans avoir à les mettre à jour, on les retrouve dans le Datacenter New-Generation dont les serveurs sont des ESX 4.0. Figure B 16
b. Machine V7 : mise à jour avec Update Manager La mise à jour des machines virtuelles dans ce premier scénario se fait avec Update Manager. Une fois le module installé de nouvelles actions sont possibles sur les machines virtuelles. Pour une mise à jour d un ensemble de machines virtuelles, la création de baselines dans Update Manager est nécessaire. En ce qui concerne notre exemple, la mise à jour se fera sur une seule machine. Le processus reste identique pour un ensemble de machines. Une fois la baseline créée dans Update Manager, on l attache à la machine Win 4 à mettre à jour. Avant de lancer le processus on peut vérifier qu elle n est pas à jour (scan). Pour y remédier il suffit de lancer «Remediate» via Update Manager. 17
Update Manager offre la possibilité de faire une sauvegarde de la machine virtuelle sous forme de snapshot avant sa mise à jour. Ce qui permet de retrouver, si cela s avère necessaire, la machine initiale. Il est recommandé d activer cette option (Rollback options) sachant qu on peut définir une période en heures, qui représente la durée de vie du snapshot à partir du moment où la mise à jour a été achevée. La mise à jour de la machine virtuelle se fait en deux étapes lancées automatiquement par Update Manager: Mise à jour des VMware Tools. Mise à jour du Virtual Hardware en version 7. 18
Le processus de mise à jour de la machine virtuelle Win4 avec Update Manager est ainsi complet. c. Mise à jour manuelle La mise à jour des machines peut être faite manuellement à condition de bien respecter l ordre: VMware Tools puis Virtual Hardware. Notes Une fois le Virtual Hardware de la machine virtuelle en version 7, elle ne pourra plus s exécuter sur un ESX / ESXi 3.x. Pour notre exemple, la migration d une machine virtuelle d un serveur du Datacenter New-generation vers le Datacenter Upgrade est refusée, étant donné qu un serveur 3.5 ne supporte pas de machine dont le Virtual Hardware est en version 7 19
d. Serveurs ESX / ESXi Le processus de mise à jour des serveurs ESX/ESXi 3.5 est simplifié par l utilisation d Update Manager qui met les serveurs en mode maintenance avant de les mettre à jour. Update Manager offre la possibilité de retrouver la version précédente du serveur (dual boot). 2. Scénario 2 : vsphere Host Update Utility Pour ce scénario, on dispose d un poste accédant au fichier ISO d installation. Pour réaliser la mise à jour d'un serveur ESX 3.5 on installe le Host Update Utility. La mise à jour de la machine virtuelle se réalise manuellement. Pendant l installation du vsphere Client, il faut installer en même temps le vsphere Host Update Utility. Pour ce scénario, on considère que le vsphere Host Update Utility est installé dans une machine Windows qui accède aux différents serveurs ESX/ESXi 3.5 ainsi qu au fichier ISO d installation de l ESX 4.0. 20
a. Serveurs ESX / ESXi Avant de lancer la mise à jour du serveur, il faut le mettre en mode maintenance. Sinon le processus ne se lance pas. Une fois le VMware vsphere Host Update Utility lancé (Start > Programs > VMware > vsphere Host Update Utility 4.0), on peut ajouter les serveurs ESX/ESXi 3.5 à mettre à jour. Une fois la liste construite, il suffit d en sélectionner un et de lancer le processus de migration. 21
Une fois la vérification et la préparation du serveur 3.5 achevées, le processus de mise à jour se lance. Les différentes étapes du processus sont illustrées dans le diagramme suivant. Une fois la compatibilité du serveur vérifiée, il faut sélectionner le Datastore où le disque.vmdk du service console 4.0 sera créé pendant la mise à jour. De plus, ce Datastore doit être en VMFS local ou FC (NFS et Software iscsi Datastore ne peuvent recevoir le disque de la SC 4.0), avec un minimum de 8.4GB d espace libre pour le Service Console. Pour des raisons évidentes, le Datastore ne doit être accessible que pour ce serveur. Pour garantir cela, il est recommandé d utiliser un Datastore local ou avoir recours au Zonning et Masking. Il est possible de désactiver le rollback si la mise à jour échoue, il suffit de désélectionner la case correspondante. Par défaut, il est activé. On peut aussi lancer des scripts, par exemple de nettoyage, à la fin de la mise à jour. 22
b. Machine Virtuelle Il est possible de continuer à exécuter sur un ESX 4.0 des machines virtuelles en hardware version 4. Cependant, pour avoir accès aux nouvelles fonctionnalités de vsphere, il est recommandé de mettre à jour les machines virtuelles. On effectue la mise à jour des machines virtuelles avec le vsphere Client. Pour commencer il faut mettre à jour les VMware Tools, ensuite, le Virtual Hardware de la machine virtuelle de la version 4 vers 7. 3. Scénario 3 : mise à jour à froid Pour ce scénario, l installation est plus simple que celle des scénarios précédents : un serveur ESX 3.5 sur lequel s exécute une machine virtuelle Windows (Win6), le CD ISO d installation se trouvant au niveau du serveur et le Script de pré-installation disponible dans un Datastore accessible. 23
Il s agit ici plus d un cas particulier que d un scénario de migration en vsphere. Notre configuration de base est un ESX 3.5 et un CD/.ISO d installation. On démarre l ESX pour qu il puisse booter sur le CD d installation et nous permettre de faire la mise à jour. Première remarque le menu ne propose pas d Upgrade Pire encore, il se propose d installer «proprement» l ESX 4.0, autrement dit, perte des données de configuration. Il s agit ici, d une solution d installation et non de mise à jour, sauf si un script de préinstallation a été lancé, afin d offrir une autre alternative : celle de la mise à jour «Upgrade». Le lien suivant redirige vers la base de connaissances de VMware où l on peut trouver la procédure à suivre, ainsi que le script à lancer. http://kb.vmware.com/selfservice/microsites/search.do?language=en_us&cmd=displaykc&externali d=1009440 Pendant le test de cette solution il a y eu un problème de reconnaissance des volumes. Il suffit alors d utiliser la même commande en spécifiant l identifiant Universally Unique IDentifier (UUID) au lieu d utiliser les chemins. Une fois le script lancé, le serveur redémarre et propose de faire une mise à jour. 24
Après la mise à jour, un «dual boot» est alors disponible. On choisit la version du serveur qui nous intéresse. Autrement dit, le Rollback est possible. Restons dans le monde du script. Il est possible d utiliser des scripts qui réalisent la mise à jour des machines virtuelles ainsi que celle des templates. Pour rappel, un template ne peut pas être exécuté, d où la nécessité d une conversion en machine virtuelle. Par exemple, pour une mise à jour scriptée, il suffit de lancer le vsphere powercli et de se connecter à un serveur ESX 4.0. 25
Une fois authentifié en tant que root, on exécute le script. Voici un exemple de fonction à insérer dans un script de mise à jour des machines virtuelles. 26
VI Post-Upgrade Pour une mise à jour réussie, on peut trouver les fichiers de log du serveur ESX sous ces chemins : 1. /esx3-installation/esx4-upgrade/ 2. /var/log/vmware Dans le cas d un échec de mise à jour, les fichiers de log se trouvent sous : 1. /esx4-upgrade/ 2. /var/log/vmware Si un vcenter Server gère le serveur ESX/ESXi, il faut le reconnecter manuellement. Il suffit d un «clic droit» sur ce dernier et sélectionner Connect. Le serveur ESX/ESXi mis à jour est en mode d évaluation de 60 jours. Pour mettre à jour ses licences, il suffit de se connecter sur le site de VMware afin d accéder au portail de licences, qui générera à partir de la licence 3.5 une clé pour vsphere. Important Le compte à rebours du mode d évaluation se lance à partir du premier «power on» des ESX/ESXi 4.0, même si ces derniers ne sont pas en mode d évaluation. Supposons que 10 jours après la mise à jour des serveurs on ne souhaite plus utiliser nos licences et être en mode évaluation, la période de validité de l évaluation n est plus que de 50 jours. Pour rappel le disk du service console en version 4 est virtuel, ce qui n était pas le cas avant la mise à jour. Ceci n a pas d effet, ni de répercussion sur la gestion de l ESX, sauf si des scripts font appel au sdx, dans ce cas il faudra adapter les scripts. Dans vsphere l architecture de gestion du stockage a changé. Afin de changer le format de masking des logical unit Number s (LUN) qui est fait au niveau de l ESX (pour rappel, le masking à ce niveau n est pas recommandé), il faut lancer la commande «esxcli corestorage claimrule convert» dans le «vsphere CommandLine Interface». Les paramètres avancés du esx.conf (/adv/disk/maskluns) en MASK_PATH sont alors modifiés en tant que paramètres du plug-in de gestion du stockage. 27
vsphere Web Access La mise à jour du serveur ESX désactive le Web Access. Pour le réactiver, il faut avoir les droits administrateur sur l ESX et lancer le service correspondant: Vérification de l état du service : service vmware-webaccess status Au besoin le redémarrer : service vmware-webaccess start Une fois la mise à jour validée et la stabilité de l ESX 4.0 confirmée, on peut retirer l option de boot en ESX 3.5 et annuler le Rollback. Ceci n est possible que par l administrateur. Avant de lancer le script, une sauvegarde des données de l ESX 3.5 est nécessaire (/esx3-installation). Dans le Service Console 4.0, lancer la commande : cleanup-esx3, avec l option -f (force). Cela élimine toute référence à l ESX 3.5 dans l ESX 4.0, dans : /etc/fstab, /boot, Le script : rollback-to-esx3 dans /usr/sbin/ Pour pouvoir gérer des ESX/ESXi 3.5, le vcenter Server doit utiliser un serveur de licences. Il faut noter que la présence du serveur de licences n a aucun effet sur le fonctionnement. Pour le supprimer : En tant qu administrateur du système Microsoft Windows : Start > Settings > Control Panel > Add/ Remove Programs. *Selection du VMware License Server et le supprimer * Dans le vcenter Server, Administration > vcenter Server Settings, supprimer le chemin vers le serveur de licences. Pour les fichiers de log : %TEMP%\VCDatabaseUpgrade.log. Pour les bases de données Oracle : il faut copier le driver (ojdbc14.jar) dans : VMware vcenter Server (\ tomcat\lib) Pour les bases SQL Server : si le bulk logging a été activé, il faut le désactiver après la mise à jour du vcenter Server. Activation de la vérification du certificat SSL: Home > vcenter Server Settings > SSL Settings Selection: vcenter requires verified host SSL certificates Ce qui implique une déconnexion des serveurs ESX, qu il faudra reconnecter. 28
Félicitations Vous avez migré vers VMware vsphere 4 avec succès. A propos d Amosdec Distributeur, grossiste à valeur ajoutée, créé en 1990, AMOSDEC recherche des solutions innovantes et performantes sur les marchés internationaux et en assure la commercialisation en France au travers d'un réseau de revendeurs partenaires. La société acquiert l expertise de ces nouvelles technologies, puis la transfère à des revendeurs, sélectionnés pour leur haut niveau de compétences et leurs capacités à traiter les problématiques propres aux architectures du système d information. AMOSDEC s'est intéressé très tôt à VMware et a pris en charge sa distribution en France dès 2002. En moins de 10 ans, Amosdec est devenu un expert dans la virtualisation des infrastructures. Amosdec dispose de centres de formation répartis sur toute la France. Au cours des années, Amosdec a signé la distribution de logiciels d éditeurs proposant un écosystème riche et performant autour de VMware tant sur le Datacenter que sur le poste de travail : Expand, Leostream, Novell/Platespin, Stonesoft, Thinprint, Veeam et Vizioncore. Amosdec développe également son expertise dans le Datacenter virtualisé et complète son offre avec la distribution des systèmes de stockage NetApp. Avec plus de 50 collaborateurs entièrement dédiés à la virtualisation et au stockage, Amosdec met son expertise au service de ses revendeurs partenaires. Il leur propose des outils pour accélérer les processus de certification et d acquisition de compétences et met à leur disposition en permanence ses équipes techniques, commerciales et marketing. Nous contacter Amosdec 1, place Victor Hugo 92400 Courbevoie Tel : 01 41 91 55 55 Fax : 01 41 91 55 96 www.amosdec.com Le Cahier Technique est diffusé par Amosdec. l'autorisation d'amosdec est illicite et constitue une contrefaçon.