Hyper v et sc virtual machine manager by البوق اللبوق

HyperV et SC VMM Virtualisation sous Windows Server 2008 R2

JeanFrançois APRÉA

Résumé Ce livre sur Hyper-V, la technologie de virtualisation sous Microsoft Windows Server 2008 R2, s’adresse à des responsables informatiques sur le point de s’engager dans la mise en œuvre d’une solution de virtualisation des serveurs, aussi bien qu’à des informaticiens confrontés à la planification, à l’installation et à l’administration de cette architecture critique pour l’entreprise. Le livre permettra à certains de découvrir le monde de la virtualisation des systèmes, tandis que pour d’autres, il permettra de bâtir une stratégie de virtualisation centrée sur l’offre Microsoft : Hyper-V et System Center Virtual Machine Manager. Les premiers chapitres détaillent l’architecture générale d’Hyper-V (concept, principes technologiques, bénéfices pour l’entreprise...) ainsi que les particularités qui distinguent Hyper-V de son concurrent direct VMWare. Les chapitres suivants décrivent les méthodologies d’implémentation d’une architecture de virtualisation Hyper-V (choix de l’architecture d’entrées/sorties SAN, iScsi, choix de l’architecture réseau, dimensionnement des serveurs...) et les fonctionnalités d’administration offertes par System Center VMM 2008 R2. Cet ouvrage synthétise les possibilités et apports réels des services de virtualisation Hyper-V de Windows Server 2008 R2 et de System Center VMM 2008 R2. A l’heure du choix, il pourra vous aider à envisager ce type de projet en toute connaissance de cause et à en maîtriser la mise en place. L’auteur, Jean-François APREA, est reconnu Microsoft MVP (Most Valuable Professionnal) sur Windows Server System, Directory Services et Virtual Machine Architecture.

L'auteur Jean-François APRÉA est Consultant Senior - Architecte Infrastructures Microsoft. Outre sa participation aux programmes béta et séminaires techniques de Microsoft, il a conduit de nombreux projets d'infrastructures globales pour des clients prestigieux. Il est reconnu Microsoft MVP (Most Valuable Professionnal) sur Windows Server System, Directory Services et Virtual Machine Architecture. Son engagement en tant qu'instructeur certifié Microsoft depuis 1992 lui permet de répondre aux attentes des architectes Windows Server.

Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars 1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI

- 1-

À propos d’HyperV v2 et de System Center VMM 2008 R2 Même si l’appellation R2 signifie qu’il s’agit d’une version intermédiaire dans le cycle général de quatre ans au rythme duquel Microsoft fait évoluer son système d’exploitation serveur, les nouveautés apportées par cette nouvelle version sont nombreuses et les améliorations tout aussi importantes. Disponible en version RTM depuis le mois d’août 2009, la version R2 de Windows Server 2008 est la première version livrée uniquement en 64 bits. Destinée aux serveurs, cette version a été développée dans le même cycle de développement que la nouvelle version du système d’exploitation client, Windows 7. Un signe de fabrique habituel à Microsoft, illustré par la sortie quasi simultanée des deux versions via MSDN, le 6 août pour Windows 7 et le 14, pour Windows Server 2008 R2. Conçus pour donner le meilleur d’euxmêmes lorsqu’ils fonctionnent ensemble, Windows Server 2008 R2 et Windows 7 supportent, par exemple, deux fonctionnalités remarquables. Avec DirectAccess, les connexions Internet sont facilitées via une communication sécurisée entre clients distants Windows 7 et serveurs internes, sans avoir à déployer et gérer une configuration VPN. Avec BranchCache, le trafic WAN est optimisé via la réduction de l’utilisation de la bande passante entre sites pour tous les accès à des fichiers distants. Il est clair que la prise en charge de ces deux fonctionnalités intéressera à coup sûr nombre d’entreprises. Les plus grandes nouveautés ne concernent pas uniquement ce duo de choc ! La version 2 d’HyperV intégrée à Windows Server 2008 R2 présente de nouvelles fonctionnalités qui feront le bonheur des administrateurs de platesformes de virtualisation. Ainsi, avec Live Migration, fini les interruptions de service en cas de migration. Il est désormais possible de migrer à chaud les machines virtuelles d’une machine hôte vers une autre sans aucune coupure. De même, avec une interruption de service réduite au minimum, pour la migration du stockage offerte avec System Center VMM 2008 R2. HyperV v2 permet aussi de préserver l’évolutivité des configurations en cluster en introduisant la compatibilité des processeurs au sein de la famille Intel d’une part, et au sein de la famille AMD d’autre part. Il est aussi possible d’éteindre les cœ urs non utilisés d’une plateforme afin d’en réduire le coût énergétique. Comme vous pouvez le constater, R2 n’est pas une version mineure ! Avec R2, la virtualisation est au cœ ur des préoccupations de Microsoft. En effet, outre les nouvelles possibilités offertes par HyperV v2 et System Center VMM 2008 R2, il est désormais possible de démarrer une machine physique depuis un disque virtuel ! La disparition de la distinction entre disques physiques et disques virtuels, fichiers VHD, est une étape importante puisqu’elle permet d’envisager une administration ramenée à la seule administration d’une bibliothèque de disques virtuels. Le ton est donc donné !

- 1-

À propos de l’ouvrage 1. À qui s’adresse ce livre sur HyperV v2 et System Center Virtual Machine Manager 2008 R2 ? Ce livre s’adresse aux architectes, ingénieurs systèmes et administrateurs ayant en charge la planification, la mise en œ uvre et l’administration d’une plateforme de virtualisation HyperV v2 et System Center VMM 2008 R2. Il permettra aussi aux responsables informatiques sur le point de s’engager dans le choix d’une solution de virtualisation de disposer de tous les éléments utiles et indispensables. HyperV est au cœ ur de la stratégie système de Microsoft et l’objectif est grand : capturer le marché dominé par VMware et intégrer les services de virtualisation au cœ ur de l’offre Windows Server. De cette manière, quelle que soit l’entreprise, la virtualisation deviendra un service « Ready in the box ». Cet ouvrage permettra à certains de découvrir le monde de la virtualisation des systèmes, tandis que pour d’autres, il leur permettra de bâtir une nouvelle stratégie de virtualisation centrée sur l’offre Microsoft, c’estàdire HyperV et les produits de la famille System Center. Il permettra aussi d’identifier les bénéfices apportés par les dernières technologies de virtualisation intégrées à Windows Server 2008 R2 et System Center Virtual Machine Manager 2008 R2.

2. Organisation de l’ouvrage Les premiers chapitres détaillent l’architecture générale d’HyperV, les concepts, les principes technologiques, les bénéfices pour l’entreprise ainsi que les particularités qui distinguent la solution HyperV v2 de celle de VMware. Les chapitres suivants décrivent les méthodologies d’implémentation d’une architecture de virtualisation HyperV v2 en termes de choix de l’architecture d’entrées/sorties SAN, iScsi, choix de l’architecture réseau et dimensionnement des serveurs. Enfin, la configuration, l’installation et l’administration d’une plateforme de virtualisation à l’aide de SC VMM 2008 R2 sont traitées. Cet ouvrage synthétise les possibilités et apports réels des services de virtualisation HyperV v2 de Windows Server 2008 R2 et de System Center Virtual Machine Manager 2008 R2. À l’heure du choix, il pourra vous aider à envisager ce type de projet et à en maîtriser la mise en place, dans les règles de l’art.

- 1-

À propos de l’auteur JeanFrançois APREA est Consultant Senior, Spécialiste des Infrastructures Microsoft. Au commencement, JeanFrançois était responsable produits systèmes et réseaux IBM dans une SSII, lorsque Microsoft a commencé à développer sa stratégie pour pénétrer les réseaux d’entreprises avec MS OS/2 LAN Manager. Un peu plus tard, en 1992, il obtient sa première certification MCP et MCT sur LAN Manager, puis peu de temps après sur Windows NT 3.1. Dans le même temps, JeanFrançois a contribué à la formation de nombreux consultants et ingénieurs des équipes Support de Microsoft France, sur Windows NT, Windows 2000 et Systems Management Server. Sa connaissance des technologies de l’éditeur de Redmond fait de lui un consultant passionné par ses activités d’audit, de conseil, de formation et gestion de projet. C’est avec le même enthousiasme qu’il intervient pour le groupe Marketing Technique de Microsoft France dans l’animation de séminaires Technet ou dans le cadre du lancement des nouveaux produits avec Microsoft. Ce fût tout récemment le cas avec Windows Server 2008 et HyperV. Son activité de formation en intra ou en inter entreprises auprès des clients et des SSII lui permet de faire le lien entre les technologies du marché et les attentes des architectes et spécialistes des infrastructures Windows. Ses domaines d’activité sont basés sur les services d’entreprise de Windows Server et tout particulièrement sur les services de domaine et de sécurité Active Directory, tels que les services de domaines AD DS, les services de certificats AD CS et les services de gestion des droits numériques AD RMS. En plus de sa participation régulière aux programmes béta de Microsoft, JeanFrançois a participé au prélancement de Windows Server 2003 (Rapid Deployment Program) avec Microsoft Corp à Redmond et l’ETSI (Institut Européen des Télécommunications http://www.etsi.org). Ce programme a permis à l’ETSI d’évaluer puis de déployer les services Windows Media Server inclus dans Windows Server 2003 Enterprise Edition. Ses contacts avec l’industrie sont constants et de nombreuses entreprises lui font confiance, tout particulièrement dans le sudest de la France. JeanFrançois est MCP et MCT depuis 1992, MCSE Charter Member depuis 1994, MCSE + I, MCSE Early Achiever sur Windows 2000, MCSE et MCSA sur Windows Server 2003, MCSE Security, MCSA Exchange Server, MCTS Windows Vista, MCITP EA Windows Server 2008, MCTS Windows Server Virtualization sur HyperV et VMM 2008. Il a reçu le label Microsoft MVP Windows Server Management Infrastructure en 2005 et 2006, Microsoft MVP Windows Server Directory Services en 2007 et 2008 et Microsoft MVP Virtual Machine Architecture en 2009. Vous pouvez le contacter via son site Web dédié aux technologies Microsoft à l’adresse : http://www.adstraining.com PS : Merci à tous ceux qui m’ont supporté pendant l’écriture de ce livre ! Sans oublier mes deux garçons Pierre, Bat et mon épouse… !

- 1-

Introduction Avant d’aborder la solution de virtualisation Microsoft HyperV, il est nécessaire de faire le point sur les tenants et aboutissants des technologies de virtualisation dans leur ensemble. Sans être trop technique, l’idée principale est que la virtualisation permet de dissocier de manière essentielle les utilisateurs et les applications des matériels qui leur sont spécifiquement associés. Ce concept et les technologies s’y référant promettent de nombreux bouleversements en termes d’innovations tant du côté des matériels, que des systèmes d’exploitation et aussi des logiciels. La virtualisation permet dès aujourd’hui de déployer des solutions bien plus efficaces en terme de consommation énergétique que ne le permettaient les mises en œ uvre traditionnelles. Les ressources processeurs, mémoire, les ressources réseau ainsi que le stockage initialement affectés à des machines physiques peuvent désormais être affectés avec une granularité bien plus « intelligente » car adaptée aux réels besoins des utilisateurs et de leurs applications.

1. Virtualisation et Green Computing Toute la stratégie du futur des systèmes d’information est bâtie sur le concept du « Green Computing », aussi appelé Green IT et que l’on peut traduire par Informatique écologique. Cette approche est basée sur une tendance technologique qui consiste à réellement tenir compte des coûts en énergie et de leur impact écologique. Cette approche est bien sûr devenue une véritable stratégie commerciale chez les plus grands constructeurs, toujours prêts à mettre en avant leurs dernières gammes de matériels, toujours plus proches des besoins des entreprises. À l’heure où nous écrivons ces lignes, les effets de la crise mondiale sont déjà bien installés et il est clair que les entreprises chercheront un moyen supplémentaire pour réaliser de substantielles économies en particulier sur la consommation électrique des serveurs et des autres ressources nécessaires à leur fonctionnement. Normalement, les principes du Green Computing doivent prendre en charge les aspects les plus importants liés au cycle de vie des équipements informatiques dédiés aux technologies de l’information, mais en pratique l’activité se focalise essentiellement sur l’efficacité énergétique des équipements et des centres de traitement. Une stratégie de Green Computing efficace doit donc permettre d’améliorer sensiblement la performance énergétique des systèmes informatiques sur la base d’éléments concrets.

a. Le constat De nombreuses études ont été menées ces dernières années. Le point qui a été en tout premier lieu identifié est que les entreprises ne connaissent absolument pas la performance énergétique de leurs équipements informatiques. Ensuite, après analyse, il a été constaté que les éléments de type informatique consommaient une quantité importante d’énergie électrique. C’est par ce constat qu’il a été remarqué que les enjeux financiers du Green Computing pouvaient être très importants. Aujourd’hui, il est vraiment banal de constater que tous les constructeurs de matériels réalisent un effort important en terme de communication pour vanter l’efficacité énergétique de leurs équipements. Nous pouvons, par exemple, citer HP qui a développé de nouveaux ventilateurs capables de ventiler 3 fois plus en consommant presque 2 fois moins d’électricité.

b. Des chiffres Bien plus que de longues phrases, certains chiffres ne trompent pas. En voici quelquesuns qui permettront d’appréhender l’importance des changements qui commencent à s’opérer aujourd’hui : ●

La facture « électricité » représente 10 % du budget des DSI.

●

La consommation électrique des postes de travail augmente de 5 % par an.

●

La consommation électrique globale des Centres de données a augmenté de près de 13 % en 2007.

●

La facture électrique des postes de travail, par rapport à leur durée de vie, est aujourd’hui supérieure à leur coût d’achat.

●

Entre 2000 et 2006, la consommation électrique des Centres de données a doublé dans le monde. Des études prévoient qu’à ce rythme, d’ici 2010, les ÉtatsUnis devraient disposer de plusieurs nouvelles centrales électriques uniquement pour répondre à ces besoins informatiques.

- 1-

La liste d’exemples frappants est longue mais le plus remarquable dans tout cela est que ces mêmes études montrent que ces mêmes Centres de données informatiques ne sont utilisés qu’à légèrement plus de 50 % de leur potentiel réel !

c. Pour corréler… Pour aller plus loin, il est nécessaire de mettre en place une véritable démarche ou mieux une véritable stratégie. Il faut mesurer l’ensemble des phénomènes physiques et les corréler avec des scénarios d’usage représentatifs des traitements informatiques ou des opérations réalisées par les utilisateurs finaux. Ensuite, sur cette base, l’idée consistera à comparer ces premiers états par rapport aux spécifications techniques des matériels et à leur pourcentage d’utilisation. Dans le cadre de ces évaluations, de nombreux critères ont été petit à petit introduits afin d’aider à la modélisation de ces données. Le plus important est appelé Power Usage Effectiveness. Ce critère est un indicateur d’efficacité énergétique représentant le ratio entre l’énergie totale consommée par les systèmes informatiques et l’énergie effectivement utilisée par ces mêmes équipements. En effet, par exemple, les systèmes ou périphériques d’ancienne génération, consomment sensiblement la même quantité d’énergie, qu’ils soient ou non utilisés !

d. Agir ! Comment diminuer la consommation électrique ? Tout simplement en consommant moins ! Cidessous quelques exemples d’actions efficaces : ●

L’optimisation de la climatisation des salles machines. Il s’agit d’une part importante de la consommation électrique associée aux Datacenters.

●

Sur les postes de travail, le remplacement systématique des écrans cathodiques par des écrans LCD qui consomment beaucoup moins d’énergie.

●

La mise en place de nouvelles méthodes qui permettent de travailler à l’extérieur de l’entreprise et donc de limiter les coûts. C’est par exemple le cas de l’utilisation des clients légers ou de la virtualisation du poste de travail.

●

La virtualisation des serveurs, qui, nous allons le découvrir, offre le meilleur taux d’utilisation des matériels qui soit. Processeurs, nombre de processeurs, quantité de mémoire, quantité et type de stockage, ressources réseaux, toutes ces ressources sont traditionnellement dépendantes des matériels physiquement alloués. La virtualisation va offrir une souplesse exceptionnelle aux administrateurs et architectes en leur permettant d’affecter virtuellement les ressources nécessaires bien plus finement qu’en agissant physiquement sur le matériel.

Enfin, d’autres aspects liés aux sauvegardes, à la récupération rapide ou à la mise en place d’un plan de reprise d’activité pourront être des points très intéressants à traiter lors de la mise en place d’une plateforme de virtualisation.

2. Virtualisation et services associés Les technologies de virtualisation sont très séduisantes mais ne doivent pas se transformer en un miroir aux alouettes ! En effet, la virtualisation ne doit pas être considérée “seulement” comme la technologie associée à un projet mais comme un ensemble de technologies associées à une stratégie beaucoup plus large. C’est avec cette approche que les plus grands bénéfices seront obtenus ! Qu’il s’agisse de la consolidation des serveurs, des postes de travail, du stockage ou du réseau, le principe même de la virtualisation est certainement le principe qui va influencer et impacter le plus l’ensemble des technologies. Cette vague technologique se développe très sensiblement aujourd’hui dans les plus grandes entreprises mais elle deviendra un élément de base de toute infrastructure informatique d’ici peu. Les avantages sont nombreux et les impacts positifs tout simplement énormes notamment en considérant les gains relatifs aux points cidessous :

- 2-

●

Réduction sensible de la consommation électrique et de la nécessité de refroidir des machines sousutilisées. Une meilleure utilisation du potentiel des machines permet de minimiser le nombre de serveurs de manière significative.

●

Suppression rapide des matériels anciens en passe de devenir obsolètes. La virtualisation permet de casser la dépendance par rapport aux matériels, en remplaçant les ressources physiques matérielles par des ressources logiques virtuelles.

●

Le Datacenter devient progressivement dynamique via une réponse rapide aux exigences des besoins utilisateurs. Le déploiement de nouvelles applications ou les besoins en termes de performances peuvent être très facilement et quasi dynamiquement pris en charge et/ou résolus.

Tous ces points sont, bien entendu, d’énormes avantages. Cependant, les réels avantages apportés par les technologies de virtualisation ne seront vraiment constatés que si les impacts sur la productivité des utilisateurs ou sur les processus métiers sont mesurés sur la base d’indicateurs représentatifs de l’activité.

3. Pourquoi virtualiser ? De bonnes raisons ! Depuis la première moitié des années 90, une tendance remarquable s’est dégagée : les centres de données se sont multipliés et une décentralisation des services d’infrastructure, des applications et des données a eu lieu de manière quelque peu désordonnée. En fait, de plus en plus d’applications et d’environnements complexes ont du être déployés et, par voie de conséquence, le nombre de serveurs s’est accéléré à un rythme soutenu. En même temps, durant cette période, les machines puissantes capables d’assurer de manière centralisée de multiples rôles étaient très coûteuses à acquérir et aussi à maintenir. Pour limiter les coûts et disposer d’une plus grande réactivité face aux besoins et enjeux des entreprises, l’idée de pouvoir rationaliser l’utilisation des ressources matérielles pour mieux les gérer a fait son chemin. Première raison : les matériels sont sousutilisés et coûtent cher ! Les systèmes d’exploitation et matériels professionnels disposent aujourd’hui de fonctionnalités de supervision et de monitoring des performances très sophistiquées. Ces outils ont permis de mettre en évidence que les serveurs ne sont utilisés en moyenne qu’à seulement 10 ou 15 % de leur capacité processeur et de 20 à 30 % de leur capacité mémoire. En résumé, cela signifie que la grande majorité des machines en exploitation dans les Datacenters ne sont utilisées qu’à un faible pourcentage de leur puissance. Sur la base de ce constat, il est facile de comprendre qu’une machine, même lorsqu’elle est faiblement chargée occupe sa propre place au sein de la salle machine et consomme sa propre électricité ! Ainsi, le coût de fonctionnement d’un serveur sousutilisé est très proche de celui d’un serveur fonctionnant à pleine capacité. Ce constat met en évidence un énorme gâchis de ressources qui n’en finit pas de croître au rythme des améliorations réalisées sur les matériels dont les performances sont tous les ans sensiblement augmentées. L’idée consiste donc à développer de nouvelles solutions qui permettent de mieux répondre aux besoins des entreprises en terme de puissance machine. La virtualisation permet d’atteindre cet objectif en permettant à une seule machine physique de faire le travail de N machines physiques, en partageant les ressources de cette machine avec plusieurs environnements, et ce, de manière totalement transparente. La mise en œ uvre d’une véritable stratégie de virtualisation peut permettre à une entreprise d’augmenter le taux d’utilisation des systèmes de manière spectaculaire en utilisant pleinement le potentiel de chaque machine. Deuxième raison : les salles machines manquent de place et coûtent cher ! Ces dernières années ont vu l’émergence de nouveaux concepts lesquels ont transformé la façon dont les entreprises sont organisées. De plus, ces transformations ont fait l’objet d’investissements très importants de la part des entreprises. Les services associés à Internet ont aussi accéléré cette mutation profonde notamment par le fait que les entreprises communiquent entre elles à de multiples niveaux. Cette évolution a provoqué une informatisation de presque tous les processus internes et métiers des entreprises ainsi qu’une externalisation de bon nombre de ces services dans des centres de données spécialisés. Cette stratégie a aussi permis l’avènement de la virtualisation des réseaux à l’aide des VLAN ainsi que celui de la virtualisation du stockage à l’aide des SAN. Aujourd’hui, la virtualisation des serveurs doit permettre de récupérer une place importante dans les salles machines, tout en diminuant l’ensemble des coûts associés et en permettant à l’entreprise de profiter d’un Système d’Information toujours plus dynamique et opérationnel. Troisième raison : les serveurs ne participent pas à la protection de notre planète ! Aujourd’hui, le monde change. Le réchauffement climatique y est pour beaucoup et il est urgent d’agir pour ralentir de graves échéances et peutêtre les stopper. Ainsi, la révolution du « tout écologique » a été, c’est certain, un signe déclencheur vers les citoyens, les salariés et les entreprises pour changer leur façon de voir et de faire les choses. Les entreprises ont pour leur part commencé à mettre en œ uvre des politiques résolument plus « vertes » que par le passé, tant au niveau de l’utilisation des matières premières nécessaires à la fabrication de leurs produits que des éléments et ressources nécessaires au bon fonctionnement de l’entreprise ellemême. Cela est bien sûr le cas pour le Système d’Information. De nouvelles stratégies, communément appelées en anglais « Green IT » pour Système d’Information Vert, permettent aux entreprises de diminuer de manière importante leur niveau de consommation en électricité, et tout particulièrement la consommation électrique de tous les éléments localisés dans la salle machine. Ainsi, les études montrent que la consommation électrique des salles machines a doublé ces dernières années de manière linéaire avec le nombre de serveurs physiquement installés. Il est donc clair que le coût des machines physiques faiblement utilisées peut être réduit de manière significative dès lors qu’une politique de virtualisation est mise en place. Quatrième raison : les coûts d’administration des matériels sont importants ! Le coût total de possession d’un serveur et plus largement encore celui du système d’information tout entier est © ENI Editions - All rigths reserved

- 3-

fonction des multiples étapes qui permettent de définir son cycle de vie. L’acquisition des machines, leur intégration, le déploiement des systèmes d’exploitation, l’installation des applications, la sécurisation des systèmes physiques, des systèmes d’exploitation et des applications font partie des coûts habituels auxquels il faudra ajouter de nombreuses tâches d’administration. Chaque serveur physique nécessite d’être surveillé avec attention d’où les nombreuses tâches d’administration telles que la surveillance des défauts de fonctionnement matériels, le remplacement des éléments défectueux, la gestion des opérations de mise à niveau des firmwares ou encore le passage des correctifs nécessaires au bon fonctionnement des systèmes d’exploitation et aussi des applications (un firmware est un micrologiciel embarqué dans un composant matériel, tel qu’un contrôleur de disques, une carte réseau, une carte vidéo, etc.). Il faut aussi y ajouter la redondance de certaines tâches due au fait qu’il est nécessaire de dupliquer de plus en plus de serveurs pour respecter les engagements en terme de services associés, SLA (Service Level Agreement). Bien entendu, l’ensemble de ces tâches innombrables a un coût et la virtualisation du stockage, des réseaux ou celle des serveurs ne pourra pas, comme par magie, être une solution de diminution des coûts dans toutes les situations. Cependant, dans le cas de la virtualisation des serveurs les gains pourront généralement être très importants car la technologie de virtualisation permet de réduire radicalement le nombre de serveurs et donc le nombre de machines physiques dont il faut prendre en charge l’ensemble des tâches d’administration. Sur ce point, il convient de faire remarquer qu’en général les équipes d’administration des systèmes varient en fonction de l’emplacement des serveurs et aussi de leur nombre. Bien que les outils d’administration à distance des matériels aient considérablement évolué ces dernières années, il est en effet parfois nécessaire et souvent pratique pour ces personnels d’être physiquement à proximité des machines pour réaliser un certain nombre d’opérations, d’où une augmentation des coûts d’exploitation. Audelà de ces quatre grandes raisons qui permettent aux entreprises de se positionner dans une stratégie de type Green IT, il est important de rappeler les grands centres d’intérêt suivants : ●

La virtualisation permet une optimisation optimale des ressources matérielles.

●

La virtualisation permet une répartition des machines virtuelles sur les machines physiques en fonction de critères ou contraintes de charge.

●

Les mises en production de serveurs sont facilitées.

●

L’utilisation des machines virtuelles est particulièrement utile et adaptée aux environnements de tests, de qualification et de développement notamment via l’utilisation des snapshots clichés instantanés, sur les machines virtuelles qui permettent des retours en arrière facilités.

●

L’isolation et la sécurisation des réseaux utilisés par les machines virtuelles et les machines hôtes.

●

L’allocation dynamique de ressources en fonction des besoins des applications.

●

La simplification de la phase de dimensionnement des serveurs en diminuant les risques liés aux choix des machines.

Au final, il est clair que la virtualisation des serveurs pourra réduire de manière importante le coût total de possession des systèmes via le principe de mutualisation des ressources. Ceci concernera notamment la consommation électrique, la surveillance, le support, la maintenance matérielle, la compatibilité des matériels avec les systèmes d’exploitation du marché.

- 4-

À propos des technologies de virtualisation de serveurs Les solutions de virtualisation des serveurs existent sous différentes formes dont les principales sont l’émulation du matériel, la virtualisation du système d’exploitation et les technologies les plus modernes basées sur la paravirtualisation. Nous retrouverons parmi ces dernières la solution de Microsoft incluse dans Windows Server 2008 R2, c’estàdire HyperV.

1. Virtualisation complète avec translation binaire et Hyperviseur La virtualisation de serveur peut être implémentée avec un environnement matériel émulé sur lequel les systèmes d’exploitation invités pourront fonctionner. Cette mise en œ uvre d’une technologie de virtualisation offre un premier niveau de services implémenté au travers d’un composant responsable du bon fonctionnement de l’environnement émulé, lequel est en général appelé VMM (Virtual Machine Manager), pour Gestionnaire de Machines Virtuelles. Le fait que le système d’exploitation invité dépende de l’environnement émulé via le VMM rend la machine virtuelle émulée indépendante des spécificités du matériel prenant réellement en charge l’exécution des systèmes d’exploitation invités. Ce type de solution est implémenté sous la forme d’un composant responsable de la translation de tous les appels du VMM vers les ressources matérielles spécifiques à la machine physique. Ce composant, fondamental pour la stabilité de la plateforme lorsque de multiples systèmes d’exploitation invités fonctionnent simultanément, est appelé hyperviseur. Les implémentations réalisées par VMware avec VMware Server et VMware ESX et par Microsoft avec Virtual Server 2005 et HyperV sont des solutions qui utilisent la virtualisation matérielle, sans pour autant que ce mode soit exhaustif. La figure cidessous illustre une implémentation basée sur ce modèle.

Environnement Virtuel avec translation binaire

La translation binaire fournit une virtualisation complète au niveau du système d’exploitation invité. Cette forme d’abstraction permet de découpler complètement la machine virtuelle du matériel spécifique puisqu’en effet, la machine virtuelle ne sait pas qu’elle fonctionne dans un environnement de virtualisation. La virtualisation complète est basée sur une combinaison de deux types d’opérations : la première assure une translation binaire des opérations tandis que la deuxième permet l’exécution directe d’opérations vers le matériel. Au final, ce type d’implémentation ne nécessite aucune assistance matérielle ni aucune assistance au niveau du système d’exploitation puisque l’ensemble des fonctions est intégré au sein de produits tels que les produits de VMware (VMware Server et VMware ESX) ou de Microsoft (Virtual Server 2005 R2 et Hyper V inclu dans Windows Server 2008 et Windows Server 2008 R2). Bien sûr, la virtualisation complète offre un très bon niveau d’isolation et de sécurité pour les machines virtuelles tout en permettant la simplification des processus de migration des machines virtuelles systèmes d’exploitation invités, entre les environnements virtuels ou directement sur les machines physiques.

- 1-

2. Virtualisation assistée par le matériel et hyperviseur Les processeurs Intel et AMD 32 bits et 64 bits, puisque ces derniers utilisent le jeu d’instructions Intel x86 et AMD64, ne disposaient pas d’adaptations particulières pour que les technologies de virtualisation puissent s’appuyer sur des fonctionnalités optimisées. Les accords étroits existant entre VMware, Microsoft, Intel et AMD ont donné naissance à une nouvelle génération de processeurs incorporant des fonctionnalités pour aider à la simplification des technologies de virtualisation. Il convient de rappeler que les architectures de processeurs x86 ne sont pas virtualisables nativement sans implémenter une forte charge sur le matériel. C’est principalement pour cette raison qu’Intel et AMD ont développé des extensions matérielles, respectivement Intel VT et AMDV, capables de faciliter la virtualisation de leur architecture en utilisant les principes de la virtualisation complète et de la paravirtualisation. Dans ce dernier cas, de nouvelles instructions processeur permettent au système d’exploitation fonctionnant dans une machine virtuelle d’appeler directement les fonctions de l’hyperviseur. Concernant l’implémentation Intel VT, l’extension matérielle VTx permet la virtualisation partielle des processeurs Intel en utilisant deux types de logiciels distincts, d’un côté le code de l’hyperviseur et de l’autre le code du système d’exploitation invité. L’hyperviseur a le contrôle complet du processeur et du matériel tandis que le système d’exploitation invité permet à chaque machine virtuelle de s’exécuter indépendamment des autres. Toujours concernant les processeurs Intel VT, les opérations liées à la virtualisation sont appelées opérations VMX, lesquelles peuvent fonctionner en mode VMX root pour l’hyperviseur en dessous du traditionnel Ring 0, ou en mode VMX nonroot pour l’exécution des systèmes d’exploitation invités. Dans ce dernier mode, le comportement du processeur est limité au sein du Ring 0, de telle sorte que certaines instructions et/ou événements en provenance des machines virtuelles seront déroutés vers l’hyperviseur fonctionnant dans le mode le plus privilégié, c’estàdire VMX root, encore appelé Ring 1. A ce niveau, l’avantage est que le système d’exploitation invité fonctionne normalement en Ring 0 pour ce qui concerne le noyau et en Ring 3 pour ce qui est des différents soussystèmes et des applications. Les transitions vers l’hyperviseur, appelées VM exit, signifient que les fonctions présentes dans l’environnement VMX nonroot sont limitées, puisqu’en fait, elles sont réellement prises en charge par l’environnement VMX root. Comme le montre la figure cidessous, le code le plus privilégié et tous les appels les plus critiques sont directement interceptés et transmis vers l’hyperviseur, supprimant ainsi le besoin ou plutôt la nécessité de faire appel à un mécanisme de translation binaire. Vu sous un autre angle, la machine virtuelle accueillant le système d’exploitation invité est encapsulée dans des structures VTx spécialisées pour contrôler les machines virtuelles.

Environnement Virtuel avec Assistance matérielle Intel VTx ou AMDV et Ring 1

3. Paravirtualisation ou la Virtualisation assistée par le système d’exploitation Au départ, le terme « para » est d’origine grecque et signifie « à côté ». Cependant, s’agissant de la paravirtualisation, le principe réside dans le fait que la machine virtuelle prenant en charge un système d’exploitation invité dispose de moyens de communication entre le système d’exploitation invité et l’hyperviseur luimême. Cette mise en œ uvre permet aux machines virtuelles de disposer de très bonnes performances en leur donnant la possibilité d’invoquer directement la couche inférieure de l’hyperviseur à partir du noyau du système d’exploitation invité. Ces appels, appelés hypercalls, sont directement dirigés vers les interfaces hypercall pour des opérations importantes en termes de performances telles que la gestion des interruptions, des timers et aussi les fonctions de gestion mémoire. Le concept de la paravirtualisation est vraiment différent de celui qui sert de modèle pour la virtualisation complète,

- 2-

essentiellement basée sur la translation binaire des appels vers le matériel. En effet, nous avons vu précédemment que dans le cas de la virtualisation complète le système d’exploitation invité ne pouvait pas savoir qu’il fonctionnait dans un environnement de virtualisation. À l’opposé, lorsque le système d’exploitation invité est modifié pour invoquer les fonctions de l’hyperviseur, la surcharge liée à la translation binaire est limitée. Pour résumer, les hyperviseurs qui supportent la paravirtualisation limitent les surcharges liées à la virtualisation en augmentant de manière significative la performance des machines virtuelles.

Concept de la Paravirtualisation Cependant, toutes les technologies ont leurs avantages et aussi leurs inconvénients. Le concept même de la paravirtualisation signifie que des composants doivent être installés au sein de la machine virtuelle contenant le système d’exploitation invité, impliquant que la portabilité même de la machine virtuelle peut s’avérer délicate. À l’inverse, le développement de solutions de virtualisation complète basées sur le concept de la translation binaire n’est pas facile à réaliser et à faire évoluer au fur et à mesure des évolutions matérielles. À l’inverse, les modifications à apporter aux systèmes d’exploitation invités, afin qu’ils supportent le concept de paravirtualisation, sont relativement faciles à implémenter. Le concept de paravirtualisation n’a pas pour objet de représenter aux systèmes d’exploitation invités une architecture matérielle complète. À l’opposé de la virtualisation complète qui masque la présence de la couche de virtualisation aux systèmes d’exploitation invités, la paravirtualisation crée une relation entre l’hyperviseur sous jacent et les machines virtuelles. Cette relation « intime » permet une très bonne gestion des ressources matérielles et offre d’excellentes performances d’exécution des machines virtuelles. Les technologies telles que Xen de Citrix et HyperV de Microsoft implémentent la paravirtualisation.

4. Technologie de Virtualisation HyperV La technologie de virtualisation HyperV est la base de la solution de virtualisation de Microsoft. Avec une intégration au cœ ur de Windows Server 2008 R2 x64, la technologie de virtualisation est disponible en tant que solution complètement intégrée au système d’exploitation. Cette technologie moderne utilise le meilleur des technologies offertes par les dernières générations de processeurs, comme la virtualisation assistée disponible avec les processeurs Intel dotés du support des fonctions de virtualisation VTx et les processeurs AMD des fonctions de virtualisation AMDV. Le fait que les services Windows Server 2008 R2 HyperV soient intégrés de base dans les versions 64 bits de Windows Server 2008 R2 Edition Standard, Edition Entreprise et Datacenter permet d’ores et déjà à toutes les entreprises de s’intéresser au sujet et, si elles le souhaitent, de profiter d’accords de licences intégrés au produit. En effet, Windows Server 2008 R2 avec HyperV intègre les droits de licences suivants : pour la version Standard : 1 machine virtuelle est incluse. Pour la version Entreprise : 4 machines virtuelles sont incluses. Pour la version Datacenter : nombre illimité de machines virtuelles.

- 3-

L’accord de licences permet au client d’utiliser « gratuitement » un certain nombre de machines en fonction de la version de Windows Server 2008 R2, sachant qu’un droit de downgrade de 1 niveau est aussi accordé. Cela signifie, par exemple, qu’avec une version Entreprise, le client dispose d’un droit pour installer 4 machines virtuelles fonctionnant sous Windows Server 2008 R2 ou bien sous Windows Server 2003.

a. Microsoft et les technologies de virtualisation Bien que Microsoft ait disposé d’une solution de virtualisation de serveurs avec Microsoft Virtual Server 2005 Edition Entreprise R2, cette version n’a jamais permis à l’éditeur d’être un sérieux concurrent visàvis des ténors du marché que sont VMware avec VMware ESX ou Citrix avec XenServer. Pendant cette phase, Microsoft a temporisé l’attente de ses clients avec une solution intermédiaire stable mais limitée en performances et aussi en fonctionnalités. Ces années de retard sur ses concurrents ont pesé lourd sur Microsoft qui a dû faire un très gros travail pour rattraper son retard. Les différentes étapes, pour revenir au plus haut niveau avec HyperV sont résumées ci dessous. Environnement de tests et démonstrations avec Connectix Virtual PC Cette entrée en matière a permis à Microsoft de se positionner sur des services de virtualisation d’entrée de gamme mais très utiles et souvent suffisants pour les tests et démonstrations. Au départ, le produit permet de créer de multiples machines virtuelles acceptant des systèmes d’exploitation invités tels que DOS, Windows et aussi OS/2. Microsoft a fait l’acquisition de la technologie issue de Connectix en 2003. Depuis, la technologie a évolué puisque Virtual PC 2007 SP1 existe en versions 32 bits et 64 bits et supporte les fonctions d’assistance matérielle Intel VTX et AMDV. Virtual PC peut fonctionner sur une machine hôte Windows XP, Windows Server 2003, Windows Vista et peut accueillir des machines virtuelles dont les systèmes d’exploitation invités peuvent être toutes les versions de Windows, clientes et serveurs, mais aussi des systèmes nonWindows. Notez que Virtual PC 2007 ne prend pas en charge les machines virtuelles 64 bits, mais uniquement 32 bits. Le produit existe en deux versions, une version orientée Windows, Microsoft Virtual PC, et une version orientée Macintosh, Microsoft Virtual PC for Mac. Cette dernière version, permet aux utilisateurs Macintosh d’utiliser les applications Windows en créant des machines virtuelles Windows sur les Macintosh. Microsoft Virtual Server 2005 R2 SP1 Microsoft Virtual Server 2005 est directement issu des travaux de la société Connectix. Obtenus par Microsoft lors du rachat de la compagnie en février 2003, il aura fallu deux années de développement pour que Microsoft puisse rendre disponible la première version de Microsoft Virtual Server en 2005. Le produit existera en deux versions, la version Standard et la version Entreprise, cette dernière supportant un nombre plus important de processeurs. C’est au cours du premier trimestre 2006 que Microsoft va directement concurrencer VMware en arrêtant la distribution de la version standard et en rendant disponible la version Entreprise en téléchargement gratuit. Quelque temps plus tard, Microsoft publiait le SP1, lequel supporte les nouveaux processeurs Intel et AMD incorporant les fonctions de virtualisation avec assistance matérielle. En plus de ces fonctionnalités, le SP1 améliore le produit sur bien des points en supportant les fonctions suivantes : ●

Support de la mise en cluster des machines hôtes Virtual Server 2005 R2 SP1

●

Support des machines hôtes fonctionnant sous Windows Server 2003 64 bits

●

Support des baies de stockage via iSCSI

●

Support des disques virtuels jusqu’à 2 To

Puisque Windows Server 2003 prend en charge des capacités mémoire importantes et plus de processeurs, Virtual Server est alors la première solution offerte par Microsoft capable de virtualiser des serveurs Windows dans des environnements de production. Malgré ces progrès, la solution Virtual Server « audessus de Windows Server 2003 » est convenable pour des besoins et des scénarios limités mais ne peut rivaliser avec les solutions basées sur VMware ou Xen. Pour plus d’informations sur les solutions de virtualisation VMware, connectezvous sur le site http://www.vmware.com/

Pour plus d’informations sur les solutions de virtualisation Citrix, connectezvous sur le site http://www.citrix.com/ Pendant ce temps, Windows Server 2008 R2 est en cours de développement avec l’idée de réécrire une partie du noyau luimême pour y intégrer les interfaces nécessaires au support de services de virtualisation HyperV. L’objectif de cette intégration au cœ ur du système d’exploitation doit permettre à Microsoft de fournir des services de

- 4-

virtualisation aussi performants et aussi aboutis que ce que les leaders du moment sont capables d’offrir.

b. HyperV, un hyperviseur sur une plateforme connue À la différence des autres solutions du marché qui pour la plupart fonctionnent sur une base Linux ou des noyaux propriétaires, HyperV est une solution intégrée au sein d’un système d’exploitation aujourd’hui bien connu et bien maîtrisé par les ingénieurs systèmes et les équipes de support technique. En effet, ceuxci connaissent bien les outils d’administration, de surveillance, la gestion des matériels et des pilotes de périphériques de Windows Server. Comme pour l’ensemble des fonctionnalités centrales de Windows Server 2008 R2, l’installation et la configuration de l’hyperviseur HyperV sont implémentées sous la forme d’un rôle au sein du Gestionnaire de serveur.

HyperV est implémenté sous la forme d’un rôle Les premiers retours d’expérience montrent que la technologie a été facilement adoptée par les administrateurs. Qu’il s’agisse de la création, de la maintenance des machines virtuelles, de la surveillance ou même du dépannage, HyperV surprend par sa simplicité d’apprentissage, de mise en œ uvre et d’administration. Du côté des performances, les premiers objectifs sont atteints puisque des configurations accueillant plusieurs dizaines de machines virtuelles avec plusieurs dizaines de gigaoctets de RAM chacune sont mises en œ uvre dans des entreprises représentatives quant à leurs besoins de virtualisation de serveurs. Support des applications : à la différence de Virtual Server 2005, Microsoft a clairement annoncé que le support des applications serveur Microsoft serait pris en charge avec HyperV. Cela est donc le cas de Microsoft Exchange Server 2007 (SP1), de Microsoft Office SharePoint Server 2007 (SP1) ou encore des produits de la gamme System Center tels que SC Configuration Manager 2007 (SP1) et aussi SC Configuration Manager 2007 (SP1).

Attention ! Le fait qu’un éditeur supporte une application sur un système d’exploitation physiquement installé sur une machine ne signifie pas pour autant que le support au sein d’une machine virtuelle soit assuré ! Le fait que Microsoft s’engage pour que ses grandes applications soient supportées en environnement virtuel est encourageant pour l’adoption quasi généralisée de la virtualisation des serveurs.

c. HyperV, un hyperviseur de type 1 en mode micronoyau © ENI Editions - All rigths reserved

- 5-

Comme cela est le cas avec toutes les technologies de virtualisation de serveurs, HyperV permet une virtualisation complète d’un ou de plusieurs ordinateurs. Pour y parvenir, HyperV intègre les services de virtualisation suivants : ●

Un ordonnanceur : la couche de virtualisation nécessite la présence de ce composant pour contrôler le dispatching des différentes ressources entre chaque machine virtuelle et permettre aux administrateurs de la plateforme HyperV de configurer différents niveaux de priorités entre les machines virtuelles.

●

Un gestionnaire mémoire : ce composant est indispensable pour garantir que chaque machine virtuelle disposant de ses propres ressources mémoire est correctement protégée.

●

Des interfaces d’administration : ces interfaces sont nécessaires à l’exécution de toutes les tâches d’administration et de surveillance.

●

Un gestionnaire réseau et un gestionnaire de stockage : ces composants ont pour mission de créer l’abstraction entre les ressources physiques contrôlées par HyperV et les machines virtuelles en fonctionnement. Ces composants mettent en œ uvre des systèmes de multiplexage des accès concurrents aux périphériques physiques pour garantir la stabilité de la plateforme tout entière en isolant et en sécurisant les accès aux ressources.

●

Des périphériques et des pilotes virtuels : ces composants permettent de créer une représentation logique des périphériques réels. Les systèmes d’exploitation invités manipulent ces périphériques de la même manière que s’il s’agissait de périphériques physiques. Ces opérations sont rendues possibles via l’installation de pilotes de périphériques virtuels au sein même des machines virtuelles.

●

Un gestionnaire d’état : ce composant est responsable du démarrage, de l’arrêt des machines virtuelles et aussi des ressources élémentaires qui lui sont associées, processeurs, mémoire RAM, cartes réseaux, contrôleurs de disques et disques, etc.

La solution Microsoft HyperV est une solution où l’hyperviseur est en prise directe avec le matériel : HyperV ne fonctionne pas sous Windows ! C’est Windows qui fonctionne sous HyperV ! HyperV est un hyperviseur de type 1 en mode micronoyau : l’approche de Microsoft est souvent pragmatique. Comment construire une plateforme de virtualisation pérenne clairement orientée vers le futur et tirer parti de l’écosystème existant, fortement dominé par les technologies Windows ? Comment faire en sorte que les performances soient au rendezvous et que les pilotes de périphériques ne soient pas le maillon faible ? En fonction du choix d’architecture pris au départ, Microsoft pourrait obtenir les meilleures réponses ! Finalement, les architectes d’HyperV se sont orientés vers un modèle d’hyperviseur de type 1 en mode micronoyau. Ce modèle d’hyperviseur, encore appelé « barre métal ou natif », permet d’atteindre les meilleures performances. Les solutions Microsoft HyperV, VMware ESX ou Citrix XenServer utilisent ce modèle. Toutefois, les implémentations pourront varier de manière significative. Ainsi, la mise en œ uvre réalisée par Microsoft est très proche de celle de XenServer. Nous verrons plus loin les différences d’implémentation existant entre HyperV et VMware ESX. D’autres solutions, telles que Microsoft Virtual Server, Microsoft Virtual PC, VMware Server, VMware Workstation, VMware Fusion ou encore SUN VirtualBox sont des hyperviseurs de type 2. Ces hyperviseurs sont moins performants car, à la différence des hyperviseurs de type 1, ils ne sont pas en contact direct avec le matériel et fonctionnent audessus d’un système d’exploitation. L’hyperviseur de type 1 n’implémente aucun pilote de périphériques matériels. Les pilotes sont localisés au sein d’une machine virtuelle particulière appelée partition parent. Au sein de cette partition, encore appelée machine virtuelle principale, les pilotes de périphériques prendront en charge la gestion de matériels physiques tels que les contrôleurs d’entréessorties disques, les cartes réseau, etc. Les machines virtuelles invitées, appelées partitions enfants, n’ont pas la possibilité d’accéder au matériel. Les accès au matériel ne sont possibles qu’en empruntant les canaux de communication spéciaux vers la partition parent. Le modèle utilisé par VMware avec sa version phare ESX utilise un modèle différent de type hyperviseur monolithique. Le démarrage du système est initialisé via le démarrage d’une première machine virtuelle appelée Service Console. Durant cette phase de chargement, le noyau Linux appellera le chargement du noyau ESX, VMkernel.

- 6-

Les modèles d’architecture de VMware et d’HyperV La figure montre que la différence d’architecture la plus remarquable concerne l’emplacement d’exécution des pilotes de périphériques. Dans le cas de l’implémentation d’un modèle d’hyperviseur monolithique, tel que celui utilisé par VMware, l’hyperviseur assure sa propre gestion des drivers. Par contre, ces mêmes drivers doivent être adaptés et compilés pour l’hyperviseur luimême ce qui nécessite une attention toute particulière. Un autre aspect important concerne la sécurité puisque les composants les plus sensibles fonctionnent dans le niveau le plus privilégié qui soit. L’approche micronoyau utilisée par HyperV est différente et apporte son lot d’avantages : ●

Il n’est pas nécessaire de disposer de pilotes de périphériques spécifiques. Les pilotes 64 bits certifiés pour Windows Server 2008 R2 sont simplement nécessaires au bon fonctionnement d’HyperV.

●

La surface d’attaque est minimisée dans la mesure où le code des pilotes ne fonctionne pas dans l’hyperviseur HyperV mais à l’extérieur, au sein de la machine virtuelle principale.

●

Enfin, une meilleure stabilité est assurée puisque l’hyperviseur est déchargé de la prise en charge des pilotes de périphériques, lesquels sont placés sous le contrôle de la machine virtuelle principale.

Bien entendu, le fait que certaines fonctions soient délocalisées dans la partition principale peut laisser penser que la machine virtuelle parent fonctionnant sous Windows Server 2008 R2 en 64 bits apparaît comme un goulot d’étranglement, puisque les machines virtuelles invitées doivent transiter par celleci pour accéder au matériel. En fait, il n’en est rien car Windows Server 2008 R2 a été structuré de manière à y parvenir !

d. Architecture d’HyperV Une partie importante de l’architecture d’HyperV repose sur le concept de partitions. Les partitions existent au sein de l’environnement HyperV comme des entités étanches disposant de ressources processeurs et mémoire. Nous avons vu que le modèle d’hyperviseur utilisé par HyperV utilise deux types de partitions : la partition parent et les partitions enfants. La partition parent, ou principale, permet la gestion complète des partitions enfants, en local et aussi à distance. L’ensemble des fonctions d’administration sont implémentées à l’aide d’un fournisseur WMI prévu à cet effet. La partition parent prend aussi en charge la gestion des ressources matérielles, à l’aide des drivers validés pour la plateforme Windows Server 2008 R2 64 bits ainsi que l’ensemble des fonctions plugandplay et d’économie d’énergie. La couche de virtualisation HyperV implémentée dans la machine virtuelle principale audessus d’HyperV, comprend les composants systèmes suivants : ●

Le service HyperV Virtual Machine Management (vmms.exe) : ce service permet la gestion des partitions enfants, des clichés instantanés, des différents états et statuts.

- 7-

Liste des services HyperV de la partition principale

●

Un processus de travail pour chaque machine virtuelle invitée (vmwp.exe) : ce processus permet la gestion des opérations pendant le fonctionnement d’une partition enfant donnée. Il prend en charge la plupart des opérations de transitions telles que la configuration, la mise en pause et la mise en ligne ainsi que les opérations relatives aux clichés instantanés et aux sauvegardes. Un processus spécifique de ce type est associé à chaque partition enfant assurant ainsi une isolation totale. Afin de garantir une sécurité maximum, ce composant fonctionne en mode utilisateur et n’utilise pas l’autorité Système mais uniquement Service réseau.

Lorsque plusieurs machines virtuelles fonctionnent, chaque machine virtuelle dispose de son propre processus de contrôle. Il peut être utile de déterminer quel processus prend en charge quelle machine virtuelle. Chaque machine virtuelle, comme cela est le cas pour tous les objets systèmes et applications des environnements Windows, dispose de son propre GUID (Globally Unique Identifier). Pour connaître cette valeur, utilisez le Gestionnaire de tâches de Windows en prenant soin d’afficher la colonne Ligne de commande.

Affichage du processus VMWP, du GUID de la machine virtuelle et de l’identité utilisée : NETWORK SERVICE

- 8-

●

Un pilote de périphériques pour l’infrastructure de virtualisation (Vid.sys) : ce composant, de type noyau prend en charge la gestion des processeurs et de la mémoire pour l’ensemble des partitions enfants. Il sert aussi de passerelle pour permettre au composants de virtualisation du mode utilisateur de communiquer avec la couche HyperV, située en Ring 1.

●

Un pilote d’interface avec la couche HyperV (WinHv.sys) : ce pilote, de type noyau, implémente la couche de paravirtualisation en réalisant la translation des appels standard Windows en Hypercalls vers l’hyperviseur HyperV.

●

Les fournisseurs de services de virtualisation : les VSP (Virtualization Service Providers), situés dans la partition parente instancient les bus virtuels d’entréessorties mis à disposition des partitions enfants. Ces

dernières utilisent, de leur côté, des fournisseurs appelés VSC (Virtualization Service Clients). ●

Le bus HyperV, VM Bus (Virtual Machine Bus) : l’ensemble des communications des partitions enfants vers le matériel transite sur un bus de communication virtuel à haute vitesse (VM Bus). Pour profiter des grandes performances de ce bus, les machines virtuelles doivent disposer des services d’intégration HyperV. Les machines virtuelles qui ne disposent pas des services d’intégration ne peuvent accéder au VM Bus, et dans ce cas, utiliseront des mécanismes d’émulation moins performants.

Vue complète de l’architecture interne d’HyperV

e. Configuration requise La mise en œ uvre, détaillée au chapitre Installation, administration et maintenance, nécessite les éléments listés ci dessous : ●

Choix des types de processeurs : les machines hôtes, généralement des machines de classe « serveur » doivent impérativement être équipées de processeurs 64 bits x64 / AMD 64, supportant la technologie de virtualisation assistée. Il s’agit bien sûr des processeurs Intel VTX et AMDV. En plus de ce support, assurez vous que les processeurs disposent du support de DEP (Data Execution Prevention). Cette option est appelée Intel XD Execute Disable, et AMD NX No Execute.

●

Système d’exploitation sur la machine Hôte : HyperV est une fonctionnalité implémentée sous la forme d’un rôle disponible dans les versions Windows Server 2008 R2 Edition Standard, Windows Server 2008 R2 Edition Entreprise et Windows Server 2008 R2 Edition Datacenter.

À propos des versions de Windows Server 2008 R2 : l’installation en mode Server Core est supportée et recommandée dans certains cas. HyperV n’est pas disponible ni sur les versions 32 bits de Windows Server 2008, ni sur les versions Itanium. Cette dernière remarque vaut pour Windows Server 2008, non R2. En effet, Windows Server 2008 SP1 et SP2 sont disponibles en versions x86 (32 bits) et AMD 64 (64 bits) tandis que la dernière version ne l’est plus qu’en AMD 64.

La version de Windows Server 2008 (non R2 et R2) est toujours disponible pour les processeurs Itanium (IA64) mais ne contient pas la technologie de virtualisation HyperV.

- 9-

●

Choix de la capacité de mémoire RAM : la partition parent doit disposer d’un minimum de 1 Go de RAM, plus la mémoire dynamique nécessaire à chaque machine virtuelle. Chaque machine virtuelle consomme aussi une petite zone de mémoire, 32 Mo de RAM. Cet espace mémoire permet la gestion de la partition enfant au sein de l’environnement HyperV.

Windows Server 2008 R2 Edition Standard prend en charge 32 Go de RAM, tandis que les versions Edition Entreprise et Datacenter prennent en charge 1 To de RAM, sachant que chaque machine virtuelle dispose d’un espace maximum de 64 Go. Attention au fait que la somme de la mémoire allouée à toutes les machines virtuelles ne peut excéder la mémoire totale de la mémoire dynamique installée dans la machine, diminuée de la taille mémoire nécessaire à la partition parent, qui est de 1 Go. Nous verrons plus loin que, par défaut, System Center Virtual Machine 2008 R2 réserve 512 Mo de mémoire RAM pour chaque machine hôte HyperV prise en charge. Cependant, Microsoft recommande de considérer que la machine hôte HyperV devrait disposer de 1 Go de mémoire RAM.

●

Nombre de processeurs : pour un maximum de 64 cœ urs la version Windows Server 2008 R2 Edition Standard supporte 4 processeurs physiques, la version Windows Server 2008 R2 Edition Entreprise supporte 8 processeurs physiques, tandis que la version Windows Server 2008 R2 Edition Datacenter supporte 64 processeurs physiques. Notez que la gestion des processeurs implémentés dans HyperV supporte : ●

Sur les machines hôtes fonctionnant sous Windows Server 2008 non R2, un maximum de 24 cœ urs, soit par exemple, 4 processeurs à 6 cœ urs ou 6 processeurs à 4 cœ urs.

●

Sur les machines hôtes fonctionnant sous Windows Server 2008 R2, un maximum de 64 cœ urs.

●

Haute disponibilité : migration rapide (Quick Migration), migration en live (Live Migration) : les fonctionnalités de haute disponibilité nécessitent Windows Server 2008 R2 Edition Entreprise ou Datacenter ainsi qu’une infrastructure de stockage adaptée (stockage partagé via SAN iSCSI ou Fiber Channel). La haute disponibilité des machines HyperV est traitée au chapitre Architecture et installation de System Center VMM.

●

Nombre de cartes réseau : un environnement de test peut être mis en œ uvre avec une seule carte réseau. Cependant, les environnements de production nécessitent généralement plusieurs cartes réseau. Une carte sera dédiée à l’administration en étant directement prise en charge par la partition parent. Une ou plusieurs autres cartes réseau sera(ont) affectée(s) aux machines virtuelles. Enfin, si l’accès au stockage est de type iSCSI, vous devrez encore ajouter une ou plusieurs cartes pour séparer les flux du réseau de stockage des flux du ou des réseaux IP de production et d’administration.

5. Caractéristiques techniques a. Fonctionnalités Les fonctionnalités intégrées à HyperV peuvent être classées dans les trois catégories suivantes : ●

Les fonctionnalités HyperV propres à la machine hôte ;

●

Les fonctionnalités HyperV offertes aux machines virtuelles ;

●

Les fonctionnalités HyperV de type haute disponibilité.

Bien entendu, les caractéristiques de la machine hôte auront un impact sur les possibilités de la couche de virtualisation HyperV, qui aura à son tour un impact sur l’ensemble des machines virtuelles. L’ensemble des fonctionnalités HyperV est listé cidessous :

- 10 -

●

Architecture : Hyperviseur micronoyau 64 bits de Type 1.

●

Support de la virtualisation assistée avec les processeurs 64 bits Intel VTX et AMDV.

●

Support multiprocesseur (de 4 CPU à 64 CPU pour un total de 64 cœ urs HyperV).

●

Support de 32 Go (version Standard) à 1 To de RAM (versions Entreprise et Datacenter).

●

Support du WSFC (Windows Service Failover Clustering) jusqu’à 16 nœ uds HyperV.

●

Support de l’installation en mode Server Core.

●

Intégration au Gestionnaire de serveur de Windows Server 2008 R2.

●

Support des contrôles d’accès basés sur les rôles via Authorization Manager (AzMan).

●

Support des machines virtuelles 32 bits et 64 bits.

●

Support des machines virtuelles multiprocesseurs (1,2 ou 4 en fonction des systèmes invités).

●

Support de 64 Go de RAM par machine virtuelle.

●

Droits de virtualisation pour les machines virtuelles : Standard 1VM, Entreprise 4 VM, Datacenter illimité.

●

Architecture de partage du matériel en mode paravirtualisation.

●

Nombre maximum de machines virtuelles : 512 machines virtuelles configurables pour 192 machines virtuelles simultanées (en fonction des ressources CPU et RAM) sous Windows Server 2008, non R2 et jusqu’à 384 machines virtuelles simultanées sous Windows Server 2008 R2.

●

Gestion du stockage direct : SATA, eSATA, PATA, SAS, SCSI, USB, Firewire.

●

Gestion du stockage SAN : iSCSI, Fiber Channel, SAS, NAS.

●

Gestion des ressources des machines virtuelles.

●

Mise en cluster entre machines virtuelles.

●

Équilibrage de la charge réseau dans les machines virtuelles.

●

Migration rapide (Quick Migration) et migration en live (Live Migration) des machines virtuelles entre hôtes HyperV.

●

Clichés instantanés et sauvegardes de machine virtuelle en cours d’exécution.

●

Interfaces d’administration : console MMC 3.0, interfaces WMI, interface WMI, via la ligne de commande et/ou des scripts PowerShell et via System Center Virtual Machine Manager 2008.

●

Nombre de switchs réseaux virtuels avec support des VLANs : illimité

●

Support 802.1q (VLAN Tagging).

●

Support 802.1p (QoS).

●

Jusqu’à 128 VLAN différents.

Support des périphériques disques dans les VM : ●

2 contrôleurs IDE avec 2 disques par contrôleur, soit 4 disques IDE par machine virtuelle.

- 11 -

●

4 contrôleurs SCSI avec 64 disques par contrôleur, soit 256 disques SCSI par machine virtuelle.

●

Taille d’un disque virtuel VHD maximum portée de 127 Go (Virtual Server) à 2 To.

●

Accès directs aux disques en mode PASSTHROUGH.

●

Périphériques synthétiques ou émulés.

Support des périphériques réseaux dans les machines virtuelles : ●

12 cartes réseaux par machine virtuelle.

●

8 cartes synthétiques par machine virtuelle.

●

4 cartes émulées par machine virtuelle.

●

Jusqu’à 10 Gb/s via les drivers synthétiques de paravirtualisation.

b. Systèmes d’exploitation invités supportés Les différents systèmes d’exploitation supportés officiellement par Microsoft en environnement de virtualisation HyperV sont listés cidessous : ●

Windows Server 2008 R2 et non R2 (SP1 et SP2), toutes éditions en versions 32 bits et 64 bits (sans HyperV ou sans installer HyperV) avec 1,2 ou 4 processeurs virtuels.

●

Windows HPC 2008 (High Performance Computing) avec 1,2 ou 4 processeurs virtuels.

●

Windows Server 2003 R2, toutes éditions en versions 32 bits et 64 bits (SP2) avec 1 ou 2 processeurs virtuels.

●

Windows Server 2003, toutes éditions en versions 32 bits et 64 bits (SP2) avec 1 ou 2 processeurs virtuels.

●

Windows 2000 Server (SP4) avec 1 seul processeur virtuel.

●

Windows Vista Professionnel.

●

Windows Server 32 bits et 64 bits avec 1 ou 2 processeurs virtuels, Entreprise et Intégrale (SP1 ou SP2) avec 1 ou 2 processeurs virtuels.

●

Windows XP Professionnel (SP3) avec 1 ou 2 processeurs virtuels.

●

Windows XP Professionnel (SP2) avec 1 seul processeur virtuel.

●

Windows XP Professionnel (SP2) 64 bits avec 1 ou 2 processeurs virtuels.

Lors de la sortie d’HyperV et suite aux accords de partenariat conclus avec Novell, Microsoft a annoncé le support de la distribution Linux suivante : ●

Suse Linux ES 10 (SP1 et SP2) en versions 32 bits et 64 bits

Courant février 2009, Microsoft et Red Hat ont signé un agrément réciproque pour permettre une plus grande interopérabilité entre les technologies de virtualisation des deux compagnies. Chaque compagnie rejoint le programme de validation et de certification de l’autre et assurera le support des systèmes d’exploitation invités. Microsoft supporte les versions suivantes, avec un seul processeur virtuel : ●

- 12 -

Red Hat Enterprise Linux 5.2 (x86)

●

Red Hat Enterprise Linux 5.2 (x64)

●

Red Hat Enterprise Linux 5.3 (x86)

●

Red Hat Enterprise Linux 5.3 (x64)

La liste des systèmes d’exploitation est susceptible d’évoluer. Microsoft, Red Hat et Novell ont d’ailleurs annoncé que les futures versions de systèmes seraient supportées dans le cadre de ces accords. La liste des systèmes d’exploitation invités supportés par Microsoft est disponible via le lien http://support.microsoft.com/kb/954958

c. Applications supportées Les applications les plus importantes sont supportées par Microsoft dans les environnements virtuels. Cette liste n’est, bien sûr, pas exhaustive et évolue en fonction des évolutions des produits. ●

Microsoft Application Virtualization (AppV),

●

Microsoft Dynamics CRM,

●

Microsoft Exchange Server,

●

Microsoft IAG,

●

Microsoft ISA Server,

●

Microsoft Office SharePoint Server,

●

Windows SharePoint Services,

●

Microsoft Search Server,

●

Microsoft System Center Configuration Manager,

●

Microsoft System Center Essentials,

●

Microsoft System Center Virtual Machine Manager,

●

Microsoft Visual Studio Team System,

●

Windows Server 2003 Web Edition

●

Windows Web Server 2008,

●

Microsoft Dynamics AX,

●

Microsoft Dynamics NAV,

●

Microsoft Forefront Client Security,

●

Microsoft Forefront Security for Exchange (FSE),

●

Microsoft HIS,

- 13 -

●

Microsoft Office Groove Server,

●

Microsoft Office Project Server,

●

Microsoft Operations Manager,

●

Microsoft SQL Server 2008,

●

Microsoft System Center Data Protection Manager,

●

Microsoft System Center Operations Manager,

●

Microsoft Systems Management Server (SMS),

●

Microsoft Windows Server Update Services (WSUS).

La liste complète des applications et des recommandations de mise en œ uvre en environnement virtuel peut être obtenue en consultant l’article de la base de connaissance Microsoft KB 957006.

- 14 -

Planification et architecture d’un environnement HyperV 1. Introduction Ce chapitre met l’accent sur l’évaluation technique de l’existant, les serveurs à virtualiser ainsi que le ou les serveurs hôtes HyperV du point de vue de leur dimensionnement. L’idée est de définir une stratégie de migration qui soit la plus efficace pour les personnels ayant en charge ces opérations et aussi la plus profitable pour l’entreprise. Par exemple, au lieu de simplement commencer la virtualisation des serveurs au hasard ou de façon séquentielle, l’entreprise pourrait souhaiter faire une meilleure utilisation de ses ressources matérielles en évaluant les charges de serveur physique existant. Pour y parvenir, le projet de virtualisation des serveurs nécessite une planification et une définition rigoureuse. Les règles cidessous pourront servir de guide pour mener à bien votre projet de virtualisation avec la technologie Hyper V : ●

Il est indispensable de définir une méthodologie de mise en œ uvre qui permette de découvrir la technologie, définir l’architecture, tester et enfin implémenter la solution cible adaptée aux besoins de l’entreprise.

●

Il faut identifier et comprendre les objectifs de la nouvelle solution ainsi que la portée des avancées qui seront réalisées avant l’implémentation de ladite solution.

Une bonne méthodologie associée à une expression claire des besoins seront les garants du succès du projet. Le prolongement de cette réflexion va nous permettre de lister les bonnes pratiques pour planifier, tester, migrer et déployer Windows Server 2008 R2 HyperV. Les différentes étapes sont les suivantes, à savoir : ●

Créer le périmètre de l’environnement contenant les serveurs qui seront virtualisés.

●

Définir les buts principaux du projet et les impacts organisationnels, s’il y a lieu.

●

Déterminer les composants, applications et éléments réseau importants qui contribuent à l’atteinte des objectifs et ceux qui au contraire peuvent être des points de blocage.

●

Déterminer clairement les objectifs techniques du projet en prévision du déploiement de la solution HyperV.

La suite de ce chapitre met l’accent sur les aspects techniques en termes d’évaluation de l’existant et de dimensionnement des machines hôtes HyperV. La mise en œ uvre d’une solution de virtualisation de serveurs exige un minimum de préparation notamment concernant le dimensionnement de la solution de virtualisation, puis la virtualisation des différents serveurs physiques au sein de l’environnement virtuel. Bien sûr, les serveurs peuvent être virtualisés au fil de l’eau de manière séquentielle. Cependant, une analyse plus fine des performances permettra d’obtenir une meilleure utilisation des ressources matérielles tout en considérant les besoins en termes de sauvegardes et de haute disponibilité.

2. Définition d’une stratégie de placement des machines virtuelles sur les hôtes Hyper V Plusieurs paramètres peuvent influencer la définition d’une stratégie de placement des serveurs virtuels sur les machines hôtes HyperV, parmi lesquels : ●

Les contraintes relatives aux performances souhaitées des machines virtuelles.

●

La redondance des machines virtuelles sur plusieurs hôtes.

●

Les contraintes de connectivité cliente réseau en termes de LAN et/ou de VLAN.

●

Les contraintes d’accès au réseau de stockage SAN Fiber Channel et/ou iSCSI.

a. Contraintes de performance CPU, mémoire RAM, I/O disques et débits réseaux

- 1-

●

La charge CPU de la machine hôte HyperV est directement fonction de la charge qui sera imposée par la somme de toutes les machines virtuelles. Toutes les applications utilisent les ressources processeurs, mais souvent de manière différente. Pour cette raison, il est probable que lors du placement des machines virtuelles sur tel ou tel hôte, les performances de la machine virtuelle puissent varier en fonction de la nature des opérations réalisées par les autres machines virtuelles. Par exemple, dans le cas d’un serveur de bases de données tel que Microsoft SQL Server, Microsoft a démontré qu’une machine virtuelle 64 bits obtenait exactement les mêmes niveaux de performances que sur une machine physique, avec une légère charge processeur supplémentaire. Les tests ont montré que dans le cas où l’objectif était de virtualiser plusieurs serveurs SQL Server, il suffisait de s’assurer que le cumul des ressources nécessaires à chaque machine virtuelle pouvait être pris en charge physiquement par la machine hôte HyperV, l’hyperviseur étant quasiment transparent.

Recommandation concernant la charge CPU : HyperV permet d’allouer 4 cœ urs virtuels par machine virtuelle. Ce point peut être une limitation si vous devez disposer de plus de cœ urs pour assurer un certain niveau de performances. Microsoft recommande aussi de ne pas pratiquer de dépassement du nombre de cœ urs alloués par rapport au nombre de cœ urs réellement disponibles dans la machine hôte. Des tests ont montré que lorsque toutes les machines virtuelles sont chargées de manière significative, les performances globales de la machine hôte pouvaient en être altérées.

●

La mémoire RAM : la performance des systèmes d’exploitation et des applications est généralement très dépendante de la mémoire dynamique allouée. Bien sûr, parmi les candidats à la virtualisation, toutes les machines virtuelles ne devront pas forcement disposer d’une grande quantité de mémoire. En effet, de nombreuses machines sont aujourd’hui dédiées à des tâches ou opérations spécifiques qui ne nécessitent que peu de mémoire. À l’inverse, certaines machines virtuelles pourront nécessiter 2, 3 ou 4 Go de RAM, voire plus. Il sera donc judicieux de procéder par étape, sachant qu’il n’est pas non plus nécessaire de surdimensionner la quantité de mémoire à allouer. Tout dépendra des tests de performances et des recommandations liées à chaque environnement d’exécution spécifique.

Recommandation concernant la mémoire RAM : la règle consiste à affecter à chaque machine virtuelle la quantité de mémoire adaptée. En général, la mémoire est toujours impliquée, de près ou de loin, dans la performance des serveurs. Pour limiter les risques, vous devez donc allouer dans un premier temps à la machine virtuelle une quantité de mémoire identique à celle du serveur original. Pour rappel, chaque machine virtuelle HyperV peut gérer 64 Go de RAM au maximum, la machine hôte HyperV prenant en charge jusqu’à 1 To de RAM. Dans un deuxième temps, vous pourrez optimiser les ressources mémoire allouées en réalisant plusieurs scénarios de tests afin de déterminer la configuration la mieux adaptée.

Exemple : Exchange Server 2003 étant une application 32 bits et en raison des limitations d’adressage des platesformes 32 bits, Exchange Server 2003 est limitée à 4 Go de RAM. A contrario, Exchange Server 2007 est une application 64 bits qui peut donc utiliser, par exemple, 64 Go de RAM ou plus encore. Néanmoins, Microsoft précise que les meilleurs gains en performance sont obtenus avec 32 Go de RAM. Les informations cidessous illustrent les recommandations de Microsoft concernant les différents rôles Exchange Server 2007 SP1 en environnement HyperV. ●

Rôle Edge Transport : 2 Go min. / 1 Go par cœ ur (2 Go min.) / 16 Go max.

●

Rôle Hub Transport : 2 Go min. / 1 Go par cœ ur (2 Go min.) / 16 Go max.

●

Rôle Client Access : 2 Go min. / 2 Go par cœ ur (2 Go min.) / 16 Go max.

●

Rôle Mailbox Server : 2 Go min. / 1 Go par cœ ur (2 Go min.) / 32 Go max. Dans le cas de ce rôle, il faut considérer 2 Go de RAM au minimum auquel il faut ajouter entre 2 et 5 Mo de RAM par boîte aux lettres utilisateur, pour une taille de mémoire maximum recommandée de 32 Go.

Dans le cas d’un serveur multirôle, Microsoft préconise d’appliquer les recommandations suivantes : 4 Go de RAM au minimum, 8 Go de RAM recommandée plus entre 2 et 5 Mo de RAM par boîte aux lettres utilisateur, pour une taille de mémoire maximum recommandée de 32 Go. Rôle UM (Messagerie Unifiée) : tous les rôles d’Exchange Server 2007 sont supportés en environnement virtuel hormis le rôle Messagerie Unifiée.

●

- 2-

La charge sur les entréessorties du soussystème disque : les soussystèmes disques sont, encore aujourd’hui, les éléments les moins performants des machines de type serveurs. Ce constat sera d’autant © ENI Editions - All rigths reserved

plus vrai que les charges cumulées par de multiples machines virtuelles ne feront qu’aggraver ce phénomène. Dans les cas où les charges sur le soussystème d’entréessorties disques sont importantes, la meilleure tactique à mettre en œ uvre sera de créer et dédier des axes d’entréessorties et des grappes de disques spécifiques à ces machines virtuelles. Exemple : Le cas d’Exchange Server 2007 SP1 est un bon exemple pour comprendre les recommandations à respecter pour obtenir les meilleures performances. Le système d’exploitation ainsi que l’application Exchange Server peuvent être installés sur un disque virtuel qui doit disposer d’assez d’espace pour prendre en charge les queues de messages utilisées par les rôles Hub et/ou Edge Transport. Microsoft recommande que le stockage des données Exchange soit séparé du stockage du système d’exploitation et d’utiliser des disques SCSI en mode HyperV Passthrough pour les bases de données et journaux de transactions Exchange. Bien que cette configuration complique la portabilité des machines virtuelles dans HyperV, ce type de disques offre les meilleures performances. Dans le cas où le protocole iSCSI serait utilisé, et toujours dans le but d’atteindre les meilleures performances, il est recommandé de configurer le composant initiateur iSCSI au sein de la machine hôte HyperV, de présenter les disques aux machines virtuelles en mode Passthrough et de créer un réseau gigabits Ethernet iSCSI dédié. ●

La charge sur les entréessorties du soussystème réseau : les applications qui jouent le rôle de passerelles ou de frontaux de communication doivent disposer de grandes performances réseau pour prendre en charge des trafics importants, or les machines virtuelles de ce type peuvent diminuer les performances réseau des autres machines virtuelles, dès lors que cellesci partagent le même adaptateur réseau sur la machine hôte HyperV. Il est donc crucial d’identifier les machines ayant une importante activité réseau pour isoler ces débits. Cette opération est facilement réalisable en dédiant une interface réseau à une ou plusieurs machines virtuelles. Dans le cas où des communications interserveurs devraient être particulièrement optimisées, il est recommandé de placer ces machines virtuelles sur le même hôte HyperV. En procédant de cette manière, les machines pourront dépasser les limites des connexions Gigabits et directement utiliser la vitesse du bus virtuel HyperV.

b. Contraintes de haute disponibilité Le placement des machines virtuelles doit tenir compte des contraintes de disponibilité associées à chaque machine virtuelle. Ainsi, il est tout à fait envisageable de disposer d’applications installées sur des systèmes au sein de machines virtuelles dont les systèmes d’exploitation et les applications sont configurés avec les services Windows Server Failover Clustering. Bien entendu, ce type de configuration est recommandé lorsque plus qu’un seul hôte HyperV est implémenté. En effet, le fait de placer les deux nœ uds du cluster sur le même hôte HyperV annule la tolérance de panne mise en œ uvre via le cluster Windows si la machine hôte HyperV venait à subir une défaillance. La figure cidessous illustre le placement des machines virtuelles de chaque cluster sur deux machines hôtes HyperV distinctes. De plus, les machines hôtes HyperV sont ellesmêmes en cluster.

- 3-

Haute disponibilité des hôtes HyperV et des machines virtuelles

Les services de cluster Windows Server Failover Clustering intégrés à Windows Server 2008 R2 permettent à HyperV de supporter des configurations à haute disponibilité composées d’au maximum 16 machines hôtes HyperV.

c. Contraintes liées à l’architecture physique du réseau Les aspects réseau peuvent être abordés de plusieurs manières. Toutefois, la problématique peut se résumer à deux grands types d’activités réseau. La première concerne la connectivité des utilisateurs vers les machines virtuelles tandis que la deuxième concerne les flux réseaux entre serveurs. Concernant les performances réseau des machines virtuelles, il faut déterminer où se trouvent les utilisateurs et où se trouveront les serveurs virtualisés. Si les nouvelles machines virtuelles sont localisées au même endroit que les utilisateurs, il ne devrait pas y avoir de problèmes particuliers. Si par contre les nouvelles machines virtuelles sont délocalisées au sein d’un Datacenter distant, et que la bande passante WAN n’est pas suffisante pour offrir aux utilisateurs les niveaux de performances qu’ils avaient par le passé, les utilisateurs finaux pourront exprimer un vif mécontentement parfaitement justifié. Vous devez donc considérer les performances du réseau permettant la connectivité des clients vers les serveurs comme un aspect particulièrement important. Enfin, il est important de s’assurer que le niveau des performances réseaux interserveurs sera, à l’issue du processus de virtualisation, conservé. Il pourra aussi s’agir d’améliorer le niveau des performances. En effet, certaines applications distribuées nécessitent de multiples machines et un niveau de communication entre les machines excellent. Un cas d’école bien connu concerne, encore une fois Exchange Server. Ainsi, Microsoft recommande fortement qu’un serveur Exchange Server dispose d’une connexion rapide vers un contrôleur de domaine de type catalogue global, lequel sera fréquemment sollicité pour obtenir les listes de distributions et autres listes d’adresses. Il peut donc être judicieux de positionner une machine virtuelle contenant un contrôleur de domaine sur le même hôte HyperV et, si possible, sur le même switch virtuel HyperV.

d. Contraintes liées à la sécurité physique La définition d’une stratégie de virtualisation doit aussi tenir compte d’impératifs incontournables liés à la stratégie de sécurité déjà en place au sein de l’entreprise. Ainsi, la virtualisation de certaines machines pourra être interdite tant du point de vue d’une stratégie de sécurité que de contraintes d’emplacement géographique ou d’isolation en terme de connectivité réseau.

- 4-

Les réponses aux questions suivantes aideront à la prise de décision finale : ●

Des exigences réglementaires relatives à la sécurité des systèmes ou à la sécurité des données interdisent elles l’exécution d’applications particulières sur les mêmes serveurs, dans les mêmes baies de stockage, dans la même salle informatique ?

●

Existetil des exigences juridiques relatives à l’emplacement des données ou des serveurs ?

●

Les politiques de sauvegarde et/ou de haute disponibilité empêchentelles la cohabitation de certaines machines virtuelles entre elles ? Il faudra considérer les politiques basées sur la sauvegarde des applications, la sauvegarde au sein des machines virtuelles, les sauvegardes des machines virtuelles au sein des hôtes HyperV en mode « Offline » ou à l’aide des clichés VSS en mode « Online ».

●

L’environnement de virtualisation cible fonctionnant sous HyperV estil capable de répondre aux futurs besoins d’évolution sans que cela ait un impact sur la politique de sécurité précédemment définie ?

3. Choix de candidats à la virtualisation Bien que l’objectif principal d’une infrastructure de virtualisation soit de fournir des environnements virtuels capables de supporter une grande variété de systèmes d’exploitation et d’applications, certaines limitations pourront empêcher la virtualisation de certaines platesformes. Pour être capable de lister les applications susceptibles d’êtres virtualisées, il est nécessaire de considérer les aspects techniques relatifs à l’ensemble des applications. Les éléments cidessous sont déterminants pour choisir les meilleurs candidats à la virtualisation : ●

Architecture de processeurs/Nombre de processeurs nécessaires ;

●

Mémoire RAM nécessaire et support de cartes graphiques particulières ;

●

Support de périphériques matériels spécifiques ;

●

Niveaux de performances exigés.

En plus de ces points, il est nécessaire de tenir compte des impératifs de la plateforme HyperV, tels que : ●

HyperV nécessite Windows Server 2008 R2 Edition Standard, Entreprise ou Datacenter en version 64 bits.

●

HyperV nécessite les processeurs supportant la virtualisation assistée Intel VTX ou AMDV.

●

HyperV ne supporte pas les accès aux ports USB ni les accès directs vers le matériel.

Le tableau cidessous illustre un exemple de tableau qui pourra aider à définir les meilleurs candidats. Nom de l’application

Description

Responsables de l’application

Version de l’application

Support de la virtualisation

Approbation

IAS 2003 SP2

Serveur Radius pour 802.1x

Security Team

Win 2003 SP2

OUI

NPS 2008

Serveur de stratégies NAP

Security Team

Win 2008 SP1

OUI

SCCM 2007

Config Mgr

Management Team

Win 2003 SP2

OUI

SCCM SP1 R2 Autres … Notez qu’en fonction de certaines contraintes, il serait aussi judicieux d’ajouter une colonne pour signifier le niveau d’importance ou de priorité en vue du déploiement vers la plateforme de virtualisation HyperV.

- 5-

4. Dimensionnement : ressources nécessaires aux hôtes HyperV Grâce à la liste des applications précédentes et sur la base des informations que chaque environnement virtuel devra supporter, l’ensemble des ressources nécessaires pour héberger chaque application devra être déterminé. La récupération de ces informations pourra provenir de multiples sources : ●

Données de performances issues des statistiques de performances existantes provenant de l’environnement de production.

●

Spécifications et recommandations issues de l’éditeur de l’application, des équipes systèmes et des équipes de développement.

●

Résultats de benchmarks.

Évaluation de la charge : attention à ne pas considérer uniquement que la valeur moyenne. Pour être certain de ne pas subir de dégradation des performances, il est recommandé de considérer les charges maximum. Les données de performances d’un serveur donné doivent porter sur le serveur dans son ensemble et pas seulement sur l’application hébergée sur ledit serveur ! Rappelezvous qu’il est supposé que c’est le serveur physique en anglais, « the server box » dans son ensemble, qui doit être virtualisé et non uniquement l’application y résidant. Le tableau cidessous reprend les applications identifiées précédemment, mais considère, cette foisci, les ressources nécessaires à cellesci : Nom de l’application

Description CPU

IAS 2003 SP2

I/O Débit réseau Disques / et nb sec. d’interfaces

Tolérance de panne

Haute disponibilité

Serveur 2% Radius pour 802.1x

1024

100

100 Mbs

OUI

Vis IAS

NPS 2008

Serveur de 4% stratégies NAP

2048

150

1 Gbs

OUI

Via NPS

SCCM 2007

Config Mgr

4096

1500

1 Gbs

OUI

Via Cluster SQL

20%

RAM

Autres …

Il n’est pas toujours possible de quantifier les ressources nécessaires aux serveurs virtuels. En pareil cas, il est recommandé de se baser sur les ressources physiquement allouées et d’ajouter un pourcentage supplémentaire. Le processus d’analyse des ressources devrait cependant être réalisé dans un deuxième temps.

a. Objets Windows représentant les ressources Le tableau cidessus devra être mis à jour en examinant l’usage des différentes ressources matérielles. Grâce au cumul de toutes ces ressources, il sera possible de correctement dimensionner l’environnement cible de la plate forme de virtualisation HyperV. Objet Windows

- 6-

Compteur d’objet Windows

Processeur

% de temps processeur

Mémoire

Octets validés

Disque Physique

Lectures disques par seconde

Instance _Total

_Total

Disque Physique

Ecritures disques par seconde

_Total

Network Interface

Total des octets par seconde

Pour chaque interface réseau

●

Pourcentage de temps processeur : c’est le pourcentage de temps que le processeur utilise pour exécuter des threads actifs. Ce compteur est l’indicateur principal de l’activité du processeur et affiche le pourcentage de temps passé sur l’intervalle échantillon à faire un travail utile. Il est à noter que le calcul de l’inactivité du système est effectué à un intervalle d’échantillonnage interne basé sur l’horloge système (10 minutes). Sur les processeurs rapides actuels, le pourcentage Temps processeur peut donc sousestimer l’utilisation du processeur.

●

Octets validés : ils correspondent à la taille de la mémoire virtuelle dédiée en octets. La mémoire dédiée est la mémoire physique pour laquelle de l’espace a été réservé dans le fichier d’échange du disque. Ce compteur affiche seulement la dernière valeur observée, ce n’est pas une moyenne.

●

Lectures et Écritures disque/s : il s’agit du taux d’opérations de lecture et d’écriture sur le disque.

●

Interface réseau : le Total des octets/s est la vitesse à laquelle les octets sont envoyés et reçus sur chaque carte réseau, incluant les caractères de trame. Interface réseau\total des octets/s est la somme de « Interface réseau\octets reçus/s » et « Interface réseau\octets envoyés/s ».

b. Bonnes pratiques De grandes entreprises ont déployé depuis plusieurs années un grand nombre de leurs serveurs de tests, de validation et de production dans des environnements virtuels basés sur différentes technologies. Qu’il s’agisse des solutions de VMware, de Citrix ou de Microsoft avec HyperV, ces premières expériences ont permis aux acteurs de l’industrie de formaliser tous ces grands principes. Certains sont issus du bon sens tandis que d’autres sont issus de l’expérience par rapport à l’implémentation particulière de telle ou telle solution. Les points qui suivent font référence à ces deux catégories en mettant l’accent sur la technologie de virtualisation de serveurs HyperV. De nombreuses recommandations sont directement issues de l’expérience de Microsoft qui a, à ce jour, déployé plus de 3500 serveurs en environnement HyperV. Parmi ceuxci figurent une partie des serveurs Web Internet de Microsoft (microsoft.com, sites TechNet et MSDN) lesquels font partie des serveurs Web les plus importants en taille et en charge de la planète. Pour plus d’informations, recherchez le document « Microsoft.com Operations Virtualizes MSDN and TechNet on HyperV » sur le site de Microsoft. Les bonnes pratiques suivantes vous permettront d’optimiser les performances des machines virtuelles fonctionnant sous HyperV : ●

Utilisez, à chaque fois que cela est possible, des machines virtuelles fonctionnant sous Windows Server 2008 R2 32 bits ou 64 bits.

●

Installez les composants d’intégration au sein des machines virtuelles pour profiter des hautes performances de la paravirtualisation offerte par les VM Bus et les Hypercalls.

●

Évitez la surallocation de cœ urs sur les configurations lourdement chargées.

●

Pour les meilleures performances, utilisez des disques SCSI en mode Passthrough.

●

Pour commencer, affectez aux machines virtuelles les mêmes ressources que sur les machines physiques originales. Vous pourrez optimiser les ressources réellement nécessaires dans un deuxième temps.

●

Dimensionnez les machines hôtes HyperV pour disposer d’au moins 50 % de ressources matérielles disponibles. Vous pourrez ainsi allouer de nouvelles ressources virtuelles matérielles aux machines virtuelles, en cas de nécessité.

●

Ne partez pas du principe qu’il est possible de virtualiser tous les serveurs ou toutes les charges associées à tel ou tel serveur. Il n’est pas évident d’apprécier le niveau de performances à atteindre, ni les ressources à y associer. Il faut accepter que dans certains cas, la meilleure solution est encore une machine physique.

●

Surveillez et évaluez les performances des nouvelles machines virtuelles que vous prévoyez de déployer. Cette démarche proactive vous permettra de découvrir les goulets d’étranglement dès que possible.

- 7-

●

Standardisez la configuration et le déploiement de la majorité des machines virtuelles. Utilisez les fonctionnalités des librairies intégrées dans System Center Virtual Machine Manager 2008 telles que les modèles de machines virtuelles. En fonction des environnements, il est possible de modéliser plus de 80 % des besoins.

●

Considérez avec une grande précaution les fonctionnalités de haute disponibilité intégrées aux applications par rapport aux fonctionnalités offertes par la plateforme de virtualisation HyperV. Par exemple, Exchange Server 2007 dispose aussi de fonctionnalités de haute disponibilité. Vous devez alors comparer les avantages et inconvénients de chacune des solutions.

c. Préserver les bénéfices de la virtualisation Une plateforme de virtualisation permet d’atteindre un nouveau niveau de qualité de service concernant la mise en œ uvre, la disponibilité et l’administration des ressources matérielles associées aux serveurs. En plus de ces nouveaux services, plus dynamiques et plus flexibles, de nombreuses économies seront réalisées dans le prolongement du projet et de la mise en service de la plateforme. La rationalisation des services sur la base des rôles, charges, et des ressources affectées à des machines virtuelles a permis à Microsoft d’économiser plusieurs millions de dollars en achat de matériels et en dépenses d’électricité. Pour préserver le meilleur des possibilités de la plateforme de virtualisation, notez que deux grands axes devront être développés : ●

L’analyse du fonctionnement et des performances : il est indispensable de surveiller de manière proactive et réactive les charges et leurs performances au niveau des machines virtuelles et aussi au niveau des machines hôtes HyperV. Microsoft SCOM (System Center Operations Manager) est parfaitement intégré aux platesformes systèmes, aux applications Windows Server et à System Center Virtual Machine Manager.

Pour plus d’informations sur Microsoft SCOM 2007, suivez http://www.microsoft.com/systemcenter/operationsmanager/en/us/default.aspx

lien

HyperV supporte les machines virtuelles nonWindows fonctionnant sous Linux Suse et Red Hat Enterprise Linux. Les extensions Microsoft SCOM Cross Platform Extensions Ops Mgr Cross Plat, permettent d’étendre les possibilités de Microsoft SCOM 2007 aux platesformes nonMicrosoft suivantes : HPUX, Sun Solaris, Red Hat Enterprise Linux, Novell Suse Linux Enterprise Server et IBM AIX 5L® V5.3. Ces extensions seront disponibles dans la prochaine version de SCOM appelée, Microsoft System Center Operations Manager R2. ●

La modélisation des machines virtuelles et des ressources : il est recommandé de modéliser et rationaliser les processus de construction des machines virtuelles. SCVMM (System Center Virtual Machine Manager) est l’outil qui permettra d’organiser l’environnement virtuel. Il prend en charge un maximum de 400 machines hôtes HyperV pour un total de 8000 machines virtuelles.

Pour plus d’informations sur Microsoft SCVMM 2008, suivez le http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/default.aspx

- 8-

lien

cidessous :

Installation de Windows Server 2008 R2 et ajout du rôle HyperV Ce chapitre décrit le processus d’installation et de configuration d’une plateforme de virtualisation HyperV. L’intégration de l’hyperviseur HyperV sous Windows Server 2008 R2 sous la forme d’un rôle rendra l’installation très intuitive. Cependant, nous allons découvrir qu’HyperV peut aussi être installé en mode Server Core et que dans ce cas, il faudra passer par l’interface de type ligne de commande pour configurer totalement les éléments fondamentaux du système.

1. Préparation de l’installation L’installation d’HyperV nécessite un minimum de préparation avant de commencer. Les points cidessous vous aideront à aborder cette phase. Chaque point doit être respecté : ●

Processeur Intel x64 EM64T Dualcore ou supérieur cadencé à 1 Ghz minimum ou processeur AMD 64.

●

Mémoire RAM minimum de 512 Mo, 4 Go de RAM recommandé ou supérieur.

●

Espace disque de 8 Go minimum pour une installation de base de Windows Server 2008 R2.

Le rôle HyperV nécessite l’installation de Windows Server 2008 R2 Edition Standard, Entreprise ou Datacenter avec HyperV sur une machine équipée de processeurs 64 bits supportant la virtualisation assistée par le matériel. De fait, les versions 32 bits de Windows Server 2008 R2 ne disposent pas du rôle HyperV.

Il est nécessaire d’activer l’option matérielle DEP (Data Execution Prevention). Cette option est appelée XD (Execute Disable) sur les processeurs Intel et NX (No execute), sur les processeurs AMD.

●

Choix de la version de Windows Server 2008 R2 : vous pouvez envisager l’utilisation d’une plateforme de virtualisation basée sur la version Standard de Windows Server 2008 R2 si la limite de capacité de mémoire RAM maximum de 32 Go n’est pas un point bloquant vous limitant le nombre de machines virtuelles. Une autre limitation pourra concerner le nonsupport des fonctionnalités de haute disponibilité et le fait que la version Standard n’incorpore qu’une seule machine virtuelle Windows Server offerte avec le produit. La version Entreprise est sans aucun doute la version qui sera la plus intéressante pour la plupart des entreprises : cette version supporte 1 To de RAM, les services de haute disponibilité ainsi que quatre machines virtuelles Windows Server offertes avec le produit. Les platesformes de virtualisation devant accueillir plusieurs dizaines de machines virtuelles devraient être mises en œ uvre sous Windows Server 2008 R2 Edition Datacenter. Cette version inclut un nombre de machines virtuelles Windows Server illimité. Cela signifie que l’entreprise ne doit plus faire l’acquisition des licences nécessaires à l’utilisation de Windows Server.

Windows Server 2008 R2 Edition Web ne supporte pas le rôle HyperV.

2. Installation de Windows Server 2008 R2 : version complète ou Server Core ? Le DVD d’installation de Windows Server 2008 R2 contient, sous la forme d’une seule image WIM, les distributions de Windows Server 2008 R2 Edition Web, Edition Standard, Edition Entreprise et Edition Datacenter. Une fois la version souhaitée sélectionnée, il est alors possible de choisir entre l’installation d’une version complète ou une installation en mode Server Core. Attention : une fois ce choix réalisé, il est irréversible. Il n’est pas possible de faire une mise à niveau entre une version « complète » et une version « Server Core » ou vice versa. Un tel changement nécessitera une réinstallation complète du système d’exploitation.

●

Pourquoi installer Windows Server 2008 R2 en mode Server Core ? L’installation en mode Server Core, encore appelée en français, Installation minimale, est une option d’installation de Windows Server 2008 R2. Ce mode n’installe pas l’interface graphique utilisateur et permet uniquement d’exécuter les principaux rôles d’infrastructure réseau. Une seule partie des fichiers exécutables et des DLL est installée. Une installation minimale offre plusieurs avantages. Elle permet d’éviter certaines tâches de maintenance logicielle, de limiter la © ENI Editions - All rigths reserved

- 1-

surface d’attaque au niveau réseau, de simplifier la gestion, de limiter l’espace disque utilisé par le système d’exploitation. Attention : une installation en mode Server Core n’est pas une plateforme applicative. À la différence d’une installation complète de Windows Server 2008 R2, une installation en mode Installation minimale ne permet pas le fonctionnement de toutes les applications serveur. Une installation minimale permet uniquement d’exécuter les rôles serveur et les outils de gestion pris en charge dans ce mode particulier. Ainsi, les outils d’administration à distance fonctionnent sans aucun problème. Ce point est tout à fait normal puisque ces outils utilisent, entre autres, les protocoles tels que les RPC, les authentifications Kerberos et les mécanismes de résolution DNS. De même, les fonctionnalités standard, telles que l’enregistrement des événements, le protocole HTTP, la gestion des licences, la prise en charge d’IPSec, la disponibilité des compteurs de performance, la gestion des services Web et le support de l’interface WMI (Windows Management Instrumentation) sont supportées. Mais, l’absence de toute interface graphique utilisateur obligera les administrateurs à accéder à tous ces services via une invite de commande. La gestion de l’installation minimale est détaillée ciaprès dans ce module. Une installation en mode Server Core fournit un environnement pour exécuter les rôles suivants : ●

HyperV,

●

Services Internet (IIS 7.0 pour Windows Server 2008 non R2 et 7.5 avec Windows Server 2008 R2),

●

Serveur DHCP (Dynamic Host Configuration Protocol),

●

Serveur DNS (Domain Name System),

●

Serveur de fichiers,

●

Services d’annuaire Active Directory,

●

Services AD LDS (Active Directory Lightweight Directory Services),

●

Services Windows Media et Serveur d’impression.

En plus de ces rôles d’infrastructure, les fonctionnalités suivantes sont prises en charge : ●

Backup,

●

BitLocker Drive Encryption,

●

Failover Clustering,

●

Multipath IO,

●

Network Load Balancing,

●

Removable Storage,

●

SNMP (Simple Network Management Protocol),

●

Subsystem for UNIXbased applications,

●

Telnet client,

●

WINS (Windows Internet Name Service),

Windows Server 2008 R2 et mode Server Core : Windows Server 2008 R2 apporte son lot de nouveautés à l’installation minimale Server Core, de Windows Server 2008 : support des services de certificats AD CS - 2-

(Active Directory Certificate Services), support de WoW64 pour les applications 32 bits, Windows PowerShell, support du Framework .NET 2.0, 3.0 et 3.5 (WCF, WF) et support d’ASP.NET. Installation en mode Server Core : pour qui ? Ce mode d’installation du système d’exploitation a été spécialement conçu pour les entreprises disposant de nombreux serveurs Windows Server dont certains sont dédiés à des tâches très spécifiques dont les contraintes de sécurité sont telles qu’il est indispensable de réduire au maximum la surface d’exposition du serveur. ●

Pourquoi installer la version complète de Windows Server 2008 R2 ? La version complète de Windows Server 2008 R2 fournit aux administrateurs un environnement graphique complet ainsi que la possibilité d’utiliser 100 % des services et outils disponibles avec la version du système d’exploitation. Généralement, il s’agit du mode d’installation le plus fréquent. Ce mode est particulièrement adapté aux entreprises disposant d’un nombre limité de serveurs dont les administrateurs privilégient une administration simplifiée de ces serveurs. Les administrateurs pourront directement installer sur le serveur l’ensemble de leurs outils favoris.

3. Paramètres d’environnement réseau Les précédentes versions de Windows permettaient, pendant la phase d’installation, de directement renseigner le nom de l’ordinateur, l’ensemble des paramètres TCP/IP ainsi que les paramètres d’appartenance au sein d’un domaine ou bien d’un groupe de travail. Avec Windows Server 2008 R2, tous ces paramètres sont générés automatiquement et seront définis dans un deuxième temps. Il faudra donc définir les paramètres suivants : ●

Nom de l’ordinateur (Computer Name) : comme dans tous les réseaux, chaque ordinateur doit disposer d’un nom DNS, et aussi NetBIOS, unique. Pour rappel, les noms NetBIOS sont limités à 15 caractères, en majuscules, tandis que les noms d’hôtes TCP/IP peuvent utiliser jusqu’à 63 caractères sur la base des caractères az, AZ, les nombres de 0 à 9 et le tiret .

Attention aux noms FQDN enregistrés dans les serveurs DNS Windows Server : les serveurs DNS Windows 2000 Server, Windows Server 2003, Windows Server 2008 et Windows Server 2008 R2 supportent des caractères spéciaux tels que le caractère _ (underscore) et tous les caractères contenus dans les tables de caractères Unicode. Le caractère _ est depuis maintenant plusieurs années inscrit dans le RFC 2782, initialement 2052, pour supporter les enregistrements de service SRV RR. Ces enregistrements sont principalement utilisés par les contrôleurs de domaine Active Directory et aussi par d’autres applications telles que Microsoft Office Communication Server ou encore Microsoft Outlook 2007. Il est cependant recommandé de respecter les caractères az, AZ, 09 et pour le nommage des ordinateurs, et plus généralement tous les noms d’hôtes IP.

●

Nom de domaine Active Directory ou de Groupe de travail : le nouveau serveur devra ou non appartenir à un domaine Active Directory ou bien à un groupe de travail dont le nom par défaut est le nom NetBIOS WORKGROUP. Généralement, les serveurs devant utiliser les mécanismes d’authentifications et de contrôles d’accès les plus modernes et les plus sécurisés sont intégrés au sein d’un domaine Active Directory. Les serveurs positionnés en DMZ seront, à l’inverse, pour protéger le domaine, généralement configurés comme membres d’un groupe de travail.

●

Paramètres TCP/IP : Windows Server 2008 R2 implémente une nouvelle pile de protocole TCP/IP à très hautes performances TCP/IP NextGen, laquelle implémente nativement au sein de Windows, le protocole IPv6. Bien que la plupart des applications Microsoft, telles que par exemple, IIS 7.0, les services de cluster Windows Failover Clustering Services, Microsoft Exchange 2007 SP1 ou encore HyperV, supportent totalement IPv6, il est actuellement recommandé de délier IPv6 pour ne conserver que le protocole IPv4. La configuration des adresses peut, comme sous Windows Server 2003, être réalisée via DHCP, via le support du protocole APIPA et bien sûr de manière statique. Cette dernière méthode est bien sûr la méthode la plus traditionnelle.

4. Installation de Windows Server 2008 R2 Le point de départ de l’installation consiste à initialiser le processus d’installation en démarrant le serveur avec le DVD d’installation de Windows Server 2008 R2 x64.

a. Démarrage sur le DVD de Windows Server 2008 R2 Une fois l’image Windows PE chargée et le programme d’installation initialisé, la fenêtre de bienvenue permet de sélectionner les paramètres de langage, de format horaire et de monnaie ainsi que celui du clavier.

- 3-

Installer Windows : sélection des formats de langues et de clavier

- 4-

■

Cliquez sur Suivant pour poursuivre le processus d’installation.

■

Cliquez sur le bouton Installer pour démarrer le processus d’installation de Windows Server 2008 R2.

Sélection de la version de Windows Server R2 en mode installation complète ou minimale L’écran précédent permet de valider l’accord de licence lié au produit, puis propose de sélectionner le type d’installation souhaitée. Notez que dans le cas d’une nouvelle installation de Windows Server 2008 R2, le choix Mise à niveau n’est pas disponible. Une fois ces formalités réalisées, les pilotes de périphériques des contrôleurs de disques et des disques seront initialisés pour permettre la configuration de la partition système sur laquelle sera installé Windows Server 2008 R2. Taille de la partition système : une installation complète de Windows Server 2008 R2 nécessite au minimum une partition de 10 Go, mais Microsoft recommande une taille de 40 Go ou plus en fonction des configurations. Notez que les serveurs équipés de plus de 16 Go de mémoire RAM nécessiteront plus d’espace disques pour la pagination et les fichiers de dump. Il faut savoir que Windows Server 2008 R2 supporte l’extension et la diminution dynamique de la partition système. Il est donc toujours possible d’étendre ou de diminuer la partition en fonction des besoins ou de la politique de l’entreprise.

Sélection du type d’installation En fonction de la distribution de Windows, vous devrez renseigner la clé du produit en rapport avec votre contrat de licence Microsoft. Dans le cas où vous ne disposez pas encore de cette clé, vous aurez la possibilité de procéder à cette opération ultérieurement, après l’installation proprement dite du système d’exploitation. La figure ciaprès illustre la préparation du disque qui accueillera Windows Server.

- 5-

Création de la partition système

Formatage des disques : les précédentes versions de Windows Server 2008 non R2, permettaient de formater les disques à l’aide des systèmes de fichiers NTFS, FAT et FAT32. La nouvelle version de Windows Server 2008 R2 ne supporte plus que le système de fichiers NTFS. Version issue du commerce, Retail, ou version issue d’un Contrat en volume : quel que soit le type de contrat Microsoft, à la différence des versions précédentes de Windows, Windows XP Professionnel, Windows Server 2003, Windows Server 2008 R2 et Windows Vista SP1 nécessitent une activation auprès de Microsoft. Pour les entreprises qui déploient un nombre important de systèmes et qui disposent d’un contrat en volume, il est possible d’installer un service d’activation dynamique des licences. Ce composant, appelé KMS pour Key Management Server, peut être déployé sous Windows Server 2003, Windows Vista et aussi Windows Server 2008 R2. Pour plus de renseignements sur l’activation en volume, recherchez sur le site de Microsoft les documents intitulés Volume Activation 2.0 Overview Guide, Planning Guide, Deployment Guide et aussi Operations Guide. Ces documents contiennent toutes les opérations à réaliser pour définir la meilleure stratégie d’activation en volume pour Windows Server 2008 R2 et aussi Windows Vista ou Windows 7. La figure cidessous illustre la dernière étape du processus d’installation.

- 6-

Étapes finales de l’installation de Windows Server 2008 R2

b. Finalisation de l’installation À l’issue du processus d’installation et du premier redémarrage du serveur, le système d’exploitation propose de déclarer le mot de passe initial du compte administrateur.

- 7-

Changement du mot de passe de l’administrateur Une fois le mot de passe déclaré, la première session s’ouvre et propose à l’administrateur de procéder à l’ensemble des tâches de configuration du serveur. Toutes ces opérations vont pouvoir être réalisées en quelques minutes à l’aide de l’assistant Tâches de configuration initiales. Cet outil est lancé automatiquement la première fois à l’ouverture de session. Une fois toutes les opérations réalisées, le Gestionnaire de serveur sera automatiquement lancé à l’ouverture de session. L’assistant Tâches de configuration initiales peut être invoqué à tout moment en lançant la commande Oobe.exe. L’acronyme oobe signifie Out of Box Experience. La configuration initiale du serveur est composée de plusieurs parties distinctes :

Tâches de configuration initiales

●

L’étape 1 Fournir les informations sur l’ordinateur permet de configurer les paramètres de fuseau horaire, réseau et les noms de l’ordinateur et de domaine.

●

L’étape 2 Mettre à jour ce serveur permet de configurer les paramètres de mise à jour automatique, de rapport d’erreurs Windows ainsi que la participation au programme d’amélioration du produit. Un lien permet aussi de procéder directement au téléchargement et à l’installation des dernières mises à jour Windows.

Remarques sur les mises à jour Windows : même si l’option qui permet de mettre à jour le serveur a été configurée, il est fortement recommandé de procéder au téléchargement et à l’installation des derniers correctifs avant de configurer les rôles et fonctionnalités du serveur.

●

L’étape 3 Personnaliser ce serveur permet d’invoquer les fonctions de configuration intégrées au gestionnaire de serveur. Ainsi, il est possible d’ajouter des rôles, des fonctionnalités, d’activer le Bureau à distance et de configurer les paramètres du Parefeu Windows.

Par le passé, l’ensemble de ces tâches était réalisé pendant l’installation du système d’exploitation. Désormais, la phase d’installation est réduite à sa plus simple expression et l’ensemble de ces éléments est configuré dans un deuxième temps via cet assistant. À propos de la configuration du Parefeu Windows avec fonctions avancées de sécurité : le Parefeu Windows est par défaut activé. Par rapport à Windows Server 2003, le nouveau parefeu est beaucoup plus complet car il est capable de fonctionner en mode bidirectionnel, c’estàdire en entrée mais aussi en sortie. Pour faciliter la mise en place de configurations plus complexes, les règles IPSec sont intégrées au sein du parefeu. Les règles du parefeu - 8-

sont désormais plus fines puisqu’il est possible de spécifier les adresses IP sources et destination, les numéros de protocoles, les ports TCP et UDP sources et destinations, les protocoles et trafics particuliers tels que ICMP et IPv6. Une problématique importante de l’administration des serveurs est le dilemne qui oppose « disponibilité du serveur, des services et des applications hébergées » et « protection » dudit serveur ! C’est pour cette mauvaise raison que, presque toujours, le parefeu de Windows Server 2003 est désactivé ! La bonne nouvelle est que tout a été fait pour que les rôles, fonctionnalités et aussi les applications installées sur le serveur puissent fonctionner en harmonie avec le parefeu. Le concept est le suivant : les règles du parefeu sont créées et activées à la volée par le Gestionnaire de serveur, l’assistant Tâches de configuration initiales ou directement par les applications disposant du logo Windows Vista ou Windows Server 2008 R2 Compatible. Dans le cas des applications qui ne prennent pas en charge ces nouvelles fonctionnalités, l’administrateur devra créer les nouvelles règles nécessaires à ces types de trafics. Recommandation : la protection des serveurs des attaques réseau passe par une protection renforcée à de multiples niveaux. La connectivité réseau est bien sûr un point essentiel. La majorité des logiciels antivirus d’entreprise se sont d’ailleurs étoffés de nombreuses fonctionnalités de protection des couches réseau. La configuration du nouveau Parefeu Windows avec fonctions avancées de sécurité va dans ce sens en étant beaucoup plus granulaire. Il faut aussi noter que toutes les règles du parefeu peuvent être déployées à l’aide d’objets GPO (Group Policy Object, objet stratégie de groupe). Exemples de configuration du parefeu :

Trafic autorisé en sortie pour l’administration WMI d’HyperV

Trafic autorisé en entrée pour l’administration WMI d’HyperV

5. Installation minimale de Windows Server 2008 R2 (mode Server Core) L’installation de Windows Server 2008 R2 en mode Installation minimale est en tout point identique à une installation classique. Pour résumer le processus, l’installation commence par le démarrage du serveur sur le DVD de Windows

- 9-

Server 2008 R2, le choix de la version et du mode d’installation est réalisé, l’accord de licence est accepté et le disque contenant la partition système est préparé. Enfin, l’assistant d’installation copie les fichiers et configure le serveur pour le premier amorçage et une première ouverture de session au sein d’un environnement limité composé seulement de l’invite de la ligne de commande. À ce stade, la configuration et la gestion d’une installation de Windows Server 2008 R2 en mode Server Core implique une approche particulière puisque l’interface minimale a pour principale conséquence une utilisation quasi exclusive de la ligne de commande localement sur la machine. Bien sûr, l’administration à distance à l’aide des outils basés sur l’interface RPC permettra aux administrateurs et équipes de support de continuer à utiliser les outils d’administration Windows au travers du réseau. Une fois le premier démarrage du serveur réalisé, la configuration en mode Server Core se déroule en plusieurs étapes. Ces étapes sont rapidement présentées cidessous avant d’être traitées plus en détail : La définition du mot de passe initial de l’administrateur : cette opération est facilement réalisable à l’aide de la commande net user administrator * ou via l’interface d’ouverture de session invoquée à l’aide de la séquence de touches [Ctrl] [Alt] [Suppr]. Une fois la session ouverte sur un serveur exécutant une installation de Windows Server 2008 R2 en mode Server Core, une invite de type ligne de commandes démarre automatiquement.

●

La fermeture de cette invite de commandes ne ferme pas la session Windows. Ce comportement est normal. À l’aide de la séquence de touches [Ctrl] [Alt] [Suppr], il est nécessaire de fermer et de rouvrir la session.

●

La définition d’une configuration TCP/IP valide. Par défaut, une adresse DHCP est définie mais une configuration statique sera plus habituelle. La commande Netsh interface ipv4 set address name= "IDCarteRéseau" source= <Adresse IP> mask= <masque de sousréseau> gateway= <passerelle par défaut> permet de configurer les paramètres TCP/IP traditionnels.

●

L’intégration au sein d’un domaine Active Directory existant. Par défaut, la machine fait partie d’un groupe de travail appelé WORKGROUP. Pour insérer le nouveau serveur au sein d’un domaine Active Directory, il sera nécessaire de disposer d’un nom d’utilisateur et du mot de passe associé. La commande netdom join <nom_ordinateur> /domain:<nom_domaine> /userD:<domaine\utilisateur> /passwordD:* permet d’adhérer à un domaine à l’aide de la ligne de commande.

L’ensemble de ces opérations, ainsi que la configuration des règles du Parefeu Windows, l’activation du Bureau à distance, l’activation de la licence de Windows Server 2008 R2 auprès de Microsoft, la configuration des langages, paramètres de clavier et autres paramètres régionaux, sont décrites ciaprès.

a. Configuration du serveur en ligne de commande Les différentes étapes de configuration d’un serveur Windows Server 2008 R2 installé en mode Installation minimale (Server Core), sont listées cidessous : Pour autoriser l’administration à distance à l’aide de la console MMC, le Parefeu Windows doit être configuré de la manière suivante : ●

netsh advfirewall firewall set rule group=”Remote Administration” new enable=yes

●

netsh advfirewall set currentprofile settings remotemanagement enable

Ces deux commandes permettent d’activer le groupe de règles concerné et d’associer les paramètres au profil courant. Pour activer les connexions de type Bureau à distance, la commande suivante doit être exécutée : ●

cscript %windir%\system32\scregedit.wsf /ar 0 La commande cscript %windir%\system32\scregedit.wsf /v permet d’afficher les paramètres.

Pour autoriser les connexions de type Bureau à distance, le Parefeu Windows doit être configuré de la manière suivante : ●

netsh advfirewall firewall set rule group=”Remote Desktop” new enable=yes

Cette commande permet d’activer le groupe de règles concerné.

- 10 -

Pour déclarer les paramètres d’adresse IP, de masque de sousréseau et de passerelle par défaut, les commandes suivantes doivent être exécutées : ●

netsh interface ipv4 show interfaces. Cette commande permet de repérer le numéro d’index associé à chaque interface réseau. Ce numéro sera utilisé avec la commande suivante :

●

netsh interface ipv4 set address name = ”Idx” mask=255.255.255.0 gateway=192.168.1.254

source = static

address = 192.168.1.111

Pour déclarer les adresses IP du ou des serveurs DNS, la commande suivante doit être exécutée : ●

netsh interface ipv4 add dnsserver name=2 address=192.168.1.22 index=1

Pour renommer le serveur, la commande suivante doit être exécutée : ●

netdom renamecomputer WINUFUHGNWD3QG /newname:HYPERVNODE1

Pour joindre le serveur à un domaine Active Directory dont le nom est Corpnet.Mycorp.net, la commande suivante doit être exécutée : ●

netdom join NODE1 /domain:Corpnet.Mycorp.net /userD:DOMAIN\administrator /passwordD:*

HYPERV

UserD signifie UserDomain et PasswordD signifie Password Domain.

Attention : comme cela est le cas avec les versions précédentes de Windows, il ne faut pas réaliser l’intégration au sein du domaine si le nom de l’ordinateur vient d’être changé. Le changement du nom impose un redémarrage obligatoire. Pour activer le serveur Windows Server 2008 R2 auprès de Microsoft, les commandes suivantes doivent être exécutées : ●

Pour afficher l’état courant de la licence : slmgr dli

●

Pour installer ou remplacer la clé existante : slmgr ipk “Clé ou Clé KMS ou Clé MAK”

●

Pour réafficher l’état courant de la licence, après l’installation ou le remplacement de la clé : slmgr dli

●

Pour déclencher la procédure d’activation auprès de Microsoft : slmgr ato

Activation réussie à l’aide de la commande slmgr ato Pour changer les langages, paramètres de clavier et autres paramètres régionaux, la commande intl.cpl (applet du panneau de configuration Options régionales et linguistiques) peut être exécutée. ■

Choisir dans la liste Anglais (EtatsUnis) et valider en cliquant sur le bouton Appliquer.

- 11 -

■

Toujours à l’aide de la même applet, dans l’onglet Administration, sélectionner Modifier les paramètres régional du système et choisir Anglais (EtatsUnis).

■

Enfin, sélectionner l’option Copier dans les comptes réservés vers les comptes Compte d’utilisateur par défaut et Comptes Système. Ces opérations nécessitent le redémarrage du serveur.

Pour autoriser l’utilisation du protocole WMI (Windows Management Infrastructure), au sein du Parefeu Windows, la commande suivante doit être exécutée : ●

netsh advfirewall firewall set rule group= ”Windows Management Instrumentation (WMI)” new enable=yes

Pour configurer les services Windows Updates, les commandes suivantes pourront être exécutées : ●

Pour activer les mises à jour automatiques : cscript scregedit.wsf /AU 4

●

Pour désactiver les mises à jour automatiques : cscript scregedit.wsf /AU 1

Pour plus de renseignements sur la configuration de la version minimale de Windows Server 2008 R2, recherchez sur le site de Microsoft, le document intitulé Server Core Installation Option of Windows Server 2008 R2 StepByStep Guide. Ce document traite en détail des différentes étapes de configuration présentées plus haut.

b. Outils assistants additionnels Bien que ce ne soit pas indispensable, plusieurs outils additionnels pourront assister les administrateurs dans cette étape de mise en œ uvre de serveurs Windows Server 2008 R2 déployés dans le mode d’Installation minimale. Par exemple, l’outil Core Configurator développé par la société SmartX (http://www.smartx.com/), prend en charge l’intégralité des éléments qu’il sera presque toujours indispensable de configurer. Cet outil est donc très complet et bien abouti. Cet outil supporte la configuration des fonctionnalités suivantes :

- 12 -

●

Support des options régionales et linguistiques ;

●

Gestion des services ;

●

Gestion des connexions réseaux ;

●

Gestion des paramètres Windows Updates ;

●

Activation de Windows.

Utilitaire graphique pour configuration de Windows Server 2008 R2 / Server Core

●

Configuration de la résolution d’affichage de l’écran ;

●

Gestion de la date, de l’heure ;

●

Gestion du Bureau à distance ;

●

Création, suppression, modification des comptes locaux ;

●

Configuration du Parefeu Windows ;

Exemple :

- 13 -

Activation des groupes de configuration du Parefeu avec Core Configurator

●

Configuration de WinRM ;

●

Configuration des paramètres TCP/IP ;

●

Gestion du nom de l’ordinateur et de l’appartenance à un domaine ;

●

Installation des rôles et fonctionnalités de Windows Server 2008 R2.

c. Script de sélection des mises à jour La mise à jour des serveurs installés en mode Server Core peut parfois être délicate. En effet, généralement, les mises à jour sont téléchargées une par une puis installées à l’aide d’un script. Pour simplifier ce type d’opérations, Microsoft a publié un script qui permet de vérifier la disponibilité de nouveaux patchs. Une fois la vérification réalisée, le script affiche la liste des patchs et propose à l’administrateur de sélectionner ceux qu’il souhaite télécharger. La dernière étape permet de lancer l’installation des patchs proprement dite. Ce script peut être téléchargé à partir du site de Microsoft à l’adresse cidessous : http://msdn.microsoft.com/en us/library/aa387102(VS.85).aspx Une fois téléchargé, il suffit de le copier sur la machine Windows Server 2008 R2 installée en mode Installation minimale et d’exécuter la commande cscript WUA_SearchDownloadInstall.vbs

Exécution du script sur un serveur HyperV à jour

- 14 -

La figure cidessus illustre l’exécution du script sur une machine n’ayant pas besoin d’une mise à jour. À l’inverse, la figure cidessous, montre qu’une mise à jour est manquante. La mise à jour est d’abord téléchargée. Ensuite, l’administrateur valide ou non l’installation du patch.

Exécution du script et installation avec succès du patch souhaité Dans le cas où le serveur est configuré pour utiliser un serveur WSUS, il faudra veiller à ce que les patchs aient été au préalable approuvés. Si tel n’est pas le cas, le script n’affichera aucune mise à jour disponible pour la machine. Une fois le script exécuté, et en fonction du nombre de patchs détectés sélectionnés, un code de retour sera associé à chaque patch installé. Les codes de retour d’exécution permettent de connaître le statut de chaque application de mise à jour sur l’ordinateur. La liste de ces codes est disponible à l’adresse cidessous : http://msdn.microsoft.com/en us/library/aa387095(VS.85).aspx

6. Installation du rôle HyperV Une fois le système d’exploitation Windows Server 2008 R2 x64 installé et configuré en termes de paramètres de configuration généraux, il ne reste plus qu’à installer le rôle HyperV. Le rôle HyperV est disponible avec les éditions Standard, Entreprise et Datacenter de Windows Server 2008 R2, et ce, dans les versions complète et minimale de Windows Server. Dans le cas de l’installation sur une version complète de Windows Server 2008 R2, il est possible d’initialiser le processus d’installation à l’aide des trois méthodes présentées dans ce paragraphe. Cependant, l’étape de préparation suivante sera nécessaire avant d’initialiser le processus d’installation proprement dit.

a. Préparation et mise à niveau du serveur Avant de pouvoir ajouter le rôle HyperV à l’aide du Gestionnaire de serveur de Windows Server 2008 R2, le serveur devra avoir été préparé à l’aide des tâches de configuration initiales. Les serveurs qui utiliseraient Windows Server 2008 non R2 devront avoir fait l’objet d’une mise à jour obligatoire « Update for Windows 950050 » parue en juin 2008. Remarque sur les tâches de configuration initiales : à l’issue de la première ouverture de session, le serveur aura été renommé, les paramètres TCP/IP auront été configurés avec une adresse et une configuration IP © ENI Editions - All rigths reserved

- 15 -

valide sur le réseau. De ce point de vue, cette carte réseau pourra être dédiée à l’administration du serveur. Le serveur aura été joint à un domaine Active Directory pour profiter d’un environnement sécurisé ainsi que d’une administration centralisée. Le système aura aussi fait l’objet d’une mise à jour via Windows Update.

●

Mise à jour obligatoire « Update for Windows 950050 » pour Windows Server 2008 non R2 : les composants de virtualisation HyperV inclus avec la version RTM (Release to Market), de Windows Server 2008 SP1 ne contiennent pas la version finale du code de l’hyperviseur HyperV, mais une version de type Technical Preview. Cette version, livrée à la sortie de Windows Server 2008 en février 2008 ne doit pas être utilisée dans un environnement de production. Pour cette raison, il est indispensable de réaliser une mise à niveau du système d’exploitation via Windows Update ou de télécharger et installer manuellement la mise à jour « Update for Windows 950050 » parue en juin 2008. La mise à jour 950050, contenant la version finale du code d’HyperV existe, bien entendu, en version 64 bits.

Mise à jour du serveur réalisée avec succès avant l’installation d’HyperV Une fois la mise à jour KB950050 appliquée, il ne sera plus possible de la retirer. Il est aussi recommandé d’installer toute autre mise à jour déclarée comme nécessaire par Microsoft, avant d’installer le rôle HyperV. La figure ciaprès illustre l’utilisation de la commande « wmic qfe list » qui permet de vérifier que la mise à jour 950050 est bien installée.

Vérification de la mise à niveau HyperV 950050 via WMIC pour Windows Server 2008 non R2 La version 64 bits de la mise à jour obligatoire 950050 pour Windows Server 2008 contient les éléments suivants :

- 16 -

●

La couche et les composants systèmes HyperV.

●

La console de gestion MMC Gestionnaire HyperV : cette console MMC permet d’accéder à l’ensemble des

opérations d’administration des hôtes HyperV en local et aussi à distance. ●

Les outils de connexion aux machines virtuelles pour les versions 64 bits de Windows Server 2008 : ces outils permettent d’accéder à distance aux machines virtuelles exécutées sur les machines hôtes HyperV.

●

Les Services d’Intégration Services pour les systèmes d’exploitation Windows Server 2008 32 et 64 bits, Windows Server 2003 SP2 32 et 64 bits, Windows 2000 SP4, Windows Vista SP1 32 et 64 bits, Windows XP SP3 32 Bits et enfin Windows XP SP2 32 et 64 bits.

Ces composants sont un ensemble de pilotes de périphériques (pilotes réseau et de services) qui permettent aux machines virtuelles invitées de tirer pleinement parti des services de la plateforme de virtualisation HyperV. De bonnes performances sont assurées grâce à l’implémentation des pilotes synthétiques et des capacités de transport des bus virtuels HyperV (VMBUS HyperV). Les services d’intégration assurent aussi le support des clichés instantanés ainsi que la synchronisation horaire entre la partition parent et la partition enfant contenant la machine invitée. ●

La console de gestion MMC Gestionnaire HyperV,

●

Les outils de connexion aux machines virtuelles pour les versions 32 bits de Windows Server 2008.

Pour plus d’informations sur la mise à jour 950050, veuillez vous référer au document de la base de connaissances Microsoft via le lien http://support.microsoft.com/?kbid=950050. ●

Vérification de la configuration matérielle : chapitre Implémentation et gestion d’HyperV qui présentait les différents types d’hyperviseurs a introduit le principe de la virtualisation assistée par le matériel à l’aide des nouveaux processeurs Intel VTx et AMDV. HyperV nécessite que ces fonctions soient d’une part supportées et d’autres part actives au niveau du BIOS du serveur. En fonction de la documentation des serveurs, il faudra donc activer ces options, désactivées par défaut.

Le fait qu’il soit possible d’installer le rôle HyperV sur le serveur ne signifie pas que les fonctions d’assistance matérielle et de protection contre l’exécution des données soient pour autant activées et opérationnelles. En effet, si HyperV ne démarre pas correctement lors du redémarrage, il est probable que l’une ou l’autre des deux options nécessaires à HyperV ne soient pas opérationnelles.

Il faut aussi noter que l’activation de l’option de virtualisation au niveau des processeurs Intel et AMD nécessite un arrêt électrique de la machine. Un simple redémarrage à chaud ne rend pas opérationnelles ces options spécifiques !

b. Via l’assistant Tâches de configuration initiales oobe.exe L’assistant Tâches de configuration initiales est automatiquement exécuté lors de la première ouverture de session tant que la case à cocher Ne pas afficher cette fenêtre à l’ouverture de session n’est pas sélectionnée.

- 17 -

Ajout du rôle HyperV à l’aide de l’assistant Tâches de configuration initiales Cet assistant, représenté par le programme oobe.exe, permet d’appeler via l’étape 3 Personnaliser ce serveur l’option Ajouter des rôles. Cet assistant ne fait qu’invoquer la fonction d’ajout de rôles implémentée dans la console de gestion MMC Gestionnaire de serveur, intégrée à Windows Server 2008 R2. L’assistant Tâches de configuration initiales ne prend aucune initiative particulière qui nécessiterait de l’utiliser de manière impérative. Il offre cependant l’avantage de proposer à l’administrateur du système une démarche logique qui couvre l’ensemble des points de configuration. De ce point de vue, il peut donc être intéressant d’y faire appel même après un premier niveau de configuration.

c. Via le Gestionnaire de serveur L’installation d’HyperV à l’aide du Gestionnaire de serveur de Windows Server 2008 R2 est certainement la méthode la plus simple et la plus intuitive. En effet, l’objectif principal de ce nouveau composant enfichable de type MMC 3.0 est de permettre aux administrateurs une meilleure prise en charge des processus d’installation, de configuration et d’administration des rôles et des fonctionnalités intégrées à Windows Server 2008 R2. En effet, avec un seul outil il est possible de : ●

Voir et appliquer des changements sur les rôles et fonctionnalités du serveur,

●

Réaliser des tâches d’administration quotidiennes telles que gérer les services, les comptes d’utilisateurs et d’ordinateurs, …

●

Gérer des opérations particulières en rapport avec les rôles et fonctionnalités installées,

●

Contrôler l’état des fonctions vitales du serveur en identifiant les événements les plus importants.

Les différentes étapes de configuration proposées par l’assistant d’installation du rôle HyperV à l’aide du Gestionnaire de serveur sont listées cidessous :

- 18 -

●

À l’aide du menu Démarrer ou de la barre de lancement rapide, cliquez sur Gestionnaire de serveur.

●

Dans la zone Résumé des rôles, cliquez sur le lien Ajouter des rôles.

●

Dans la page de sélection des rôles, choisissez le rôle HyperV.

●

Dans la page Créer des réseaux virtuels, sélectionnez une carte réseau physique pour créer un réseau © ENI Editions - All rigths reserved

virtuel capable de fournir des accès au réseau physique. Cette étape de configuration n’est pas obligatoire dans la mesure où la gestion des réseaux virtuels est une tâche qui sera souvent réalisée après l’installation de l’hyperviseur HyperV puis régulièrement en fonction des besoins. ●

Dans la page de confirmation Confirmer les sélections pour l’installation, cliquez sur le bouton Installer.

●

Dans la page de Résultats de l’installation qui vous informe que vous devez redémarrer le serveur pour terminer l’installation, cliquez sur le bouton Fermer pour quitter l’assistant d’installation, puis cliquez sur le bouton Oui pour redémarrer.

●

Après le redémarrage du serveur, ouvrez une session avec le même compte d’utilisateur utilisé pour installer le rôle HyperV. Enfin, sur la page Assistant Reprise de la configuration / Résultats de l’installation, cliquez sur le bouton Fermer pour terminer l’assistant.

Les figures suivantes illustrent les étapes les plus importantes.

Ajout des rôles à l’aide du Gestionnaire de serveur

- 19 -

Sélection du rôle HyperV

Création d’un premier réseau virtuel

- 20 -

Résultats de l’installation après le redémarrage du serveur

Cette figure montre que l’installation du rôle HyperV sur un serveur Windows Server 2008 non R2 a été réalisée avec succès. Cependant, un message d’information précise que la version installée est une version préliminaire. Il est donc nécessaire de procéder à une mise à jour du système via Windows Update. Il est aussi possible d’installer la mise à jour KB 950050 après l’avoir téléchargée à partir du site de Microsoft. Bien entendu, l’installation de la version Windows Server 2008 R2 ne nécessite plus le passage de ce correctif.

d. Via la ligne de commande La dernière méthode permettant l’installation du rôle HyperV est basée sur l’utilisation d’une invite de commande et de la commande ServerManagerCmd.exe. Cette commande permet facilement d’ajouter ou de supprimer des rôles et des fonctionnalités au serveur sur lequel la commande est exécutée. Les paramètres les plus importants sont listés cidessous : ●

query : ce paramètre liste à l’écran les rôles et les fonctionnalités pris en charge sur le serveur ainsi que leur statut installé ou non installé.

●

install : ce paramètre installe les rôles ou les fonctionnalités spécifiés après le paramètre install. Pour installer toutes les options d’un rôle, il est nécessaire d’ajouter le paramètre allSubFeatures.

●

remove : ce paramètre supprime le ou les rôles et fonctionnalités spécifiés. Il est probable qu’il soit nécessaire de redémarrer le serveur.

En général, l’ajout ou la suppression de rôle nécessite le redémarrage du serveur. Par défaut, une opération réalisée à l’aide de la commande servermanagercmd.exe ne prend pas l’initiative de redémarrer le serveur. Pour automatiser le redémarrage, le paramètre restart devra être ajouté.

La commande servermanagercmd.exe n’est pas une commande PowerShell mais une commande système intégrée à Windows Server 2008 R2. Pour plus d’informations sur les paramètres de la ligne de commande servermanagercmd.exe, utilisez la commande servermanagercmd.exe / ?

- 21 -

Pour installer le rôle HyperV à l’aide de la commande servermanagercmd.exe, les opérations suivantes pourront être réalisées : ■

Ouvrir une session avec un compte disposant des privilèges d’administrateur sur la machine locale.

■

Ouvrir une invite de commande.

■

Taper la commande Servermanagercmd.exe install HyperV restart, puis valider par la touche [Entrée].

7. Installation du rôle HyperV en mode Server Core L’installation du rôle HyperV sur un serveur Windows Server 2008 R2 installé en mode Server Core nécessite l’utilisation de la commande ocsetup (Optional Components Manager). Cependant, comme cela est le cas sur la version complète de Windows Server 2008, vous devez au préalable installer la mise à niveau « HyperV update packages for Windows Server 2008 KB950050 ». L’installation de cette mise à niveau pourra être réalisée automatiquement si les mises à jour automatiques ont été activées. Sinon, il faudra procéder au téléchargement manuel de la mise à jour, puis exécuter la commande suivante : wusa.exe Windows6.0KB950050x64.msu /quiet

●

Attention : la distribution finale de Windows Server 2008 R2 SP1 appelée familièrement RTM (Release To Market) ou aussi Gold, ne contient pas la version finale d’HyperV. La version finale d’HyperV est disponible via Windows Update ou sur le site de téléchargement Microsoft sous le KB 950050 HyperV Update for Windows Server 2008 R2 x64 Edition. L’installation de ce package MSU nécessite un redémarrage obligatoire du serveur. Cette étape préparatoire étant réalisée, il est possible d’ajouter le rôle HyperV à l’installation Windows Server 2008 R2 installée en mode Server Core. La commande ocsetup sera utilisée de la manière suivante : start /w ocsetup MicrosoftHyperV

●

Une fois le rôle installé et le serveur redémarré, la gestion de la nouvelle plateforme pourra être réalisée à partir des outils d’administration à distance d’HyperV. Ces outils d’administration sont disponibles pour Windows Server 2008, Windows Vista et Windows Server en téléchargement à partir du site de Microsoft. Pour plus de renseignements sur l’installation et la configuration de Windows Server 2008 R2 en mode installation minimale avec le rôle HyperV, téléchargez le document intitulé « Server Core Installation Option of Windows Server 2008 R2 StepByStep Guide »

8. Mises à jour HyperV à appliquer sur le serveur Windows Server 2008 (non R2) Les mises à jour et correctifs suivants sont à installer sur les machines hôtes HyperV fonctionnant sous Windows Server 2008 (non R2) et si les services de haute disponibilité et System Center Virtual Machine Manager 2008 sont utilisés conjointement avec HyperV. Les mises à jour disponibles via Windows Update et/ou celles disponibles via le Centre de téléchargement Microsoft sont listées cidessous.

a. Mises à jour pour HyperV

- 22 -

●

KB950050 : HyperV Update for Windows Server 2008 x64 Edition. Il s’agit de la version finale d’HyperV. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 26/06/2008.

●

KB950182 : A computer that is running an x86based version of Windows Server 2008 or an x86based version of Windows Vista may use fewer processors than expected if the number of cores on a socket is not a power of 2. Yes, if you want to start an x86based virtual machine running Windows Server 2008 on a computer that uses a 6core processor. Ce patch est disponible via un lien sur le site de téléchargement Microsoft datant du 11/04/2008. http://go.microsoft.com/fwlink/?LinkId=139067

●

KB951308 : Increased functionality and virtual machine control in the Windows Server 2008 Failover Cluster Management console for the HyperV role. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 11/09/2008.

●

KB951636 : HyperV Language Pack Update for Windows Server 2008. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 26/06/2008. http://go.microsoft.com/fwlink/?LinkId=139069

●

KB952627 : Description of the Windows Vista Service Pack 1 Management Tools update for the release version of HyperV. Cette mise à jour permet l’administration à distance des serveurs hôtes HyperV. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 26/06/2008. http://go.microsoft.com/fwlink/?LinkID=122189

●

KB953585 : Error message when you try to start a HyperV virtual machine on a Windows Server 2008 R2 based or Windows Vistabased computer that uses the NUMA architecture: An error occurred while attempting to change the state of virtual machine VMNAME. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 04/09/2008. http://go.microsoft.com/fwlink/?LinkId=139068

●

KB953828 : The NLB host does not converge as expected on Windows Server 2008 HyperV virtual machines. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 03/10/2008. http://go.microsoft.com/fwlink/?LinkId=139070

●

KB956386 : Microsoft HyperV Server 2008. Ce patch est disponible via un lien sur le site de téléchargement Microsoft datant du 03/10/2008. http://go.microsoft.com/fwlink/?LinkId=139610

●

KB956589 : HyperV Update for Windows Server 2008 x64 Edition. Cette mise à jour résout certains problèmes d’administration d’HyperV avec System Center Virtual Machine Manager 2008. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 23/09/2008. http://go.microsoft.com/fwlink/?LinkId=139611.

●

KB956697 : Update for Windows Server 2008 x64 Edition. Cette mise à jour résout un problème avec le service HyperV Volume Shadow Copy Service (VSS) qui ne sauvegarde pas correctement les machines virtuelles. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 08/09/2008. http://go.microsoft.com/fwlink/?LinkId=139612.

●

KB956710 : Update for Windows Server 2008 x64 Edition. Cette mise à jour permet à HyperV de supporter jusqu’à 24 processeurs logiques et 192 machines virtuelles en fonction simultanément. Ce patch est disponible via Windows Update lorsque le système dispose de plus de 16 cœ urs et aussi via un lien sur le site de téléchargement Microsoft datant du 23/09/2008. http://go.microsoft.com/fwlink/?LinkId=139613.

●

KB956774 : Update for Windows Server 2008 x64 Edition. Cette mise à jour corrige un scénario ou BITS Background Intelligent Transfer Service, n’arrive pas à prendre en charge les fichiers ayant des chemins basés sur des GUID de volumes au lieu de lettres de lecteurs ou de points de montage. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 23/09/08. http://go.microsoft.com/fwlink/?LinkId=139614.

●

KB957967 : Stop error message on a Windows Server 2008 based computer that has the HyperV role installed: STOP 0x0000001A. Ce patch est disponible via Windows Update et aussi via un lien sur le site de téléchargement Microsoft datant du 08/10/2008. http://go.microsoft.com/fwlink/?LinkId=139615.

●

KB958065 : You cannot configure a HyperV virtual machine by using Windows Server 2008 Failover Clustering when the virtual machine uses a storage device that is managed by a thirdparty clustered file system or a thirdparty replication solution. Yes, if you are using a nonMicrosoft clustered file system or non Microsoft replication solutions. Ce correctif est disponible depuis le 03/11/2008.

●

KB958184 : Virtual machine backup operations fail in Windows Server 2008 when HyperV virtual machine files are saved on a volume that is mounted on a failover cluster by using a volume GUID Yes, when backing up a volume that is mounted using a volume GUID. Ce correctif est disponible depuis le 05/11/2008.

b. Mises à jour pour SC Virtual Machine Manager 2008 ●

956589 : Description of the HyperV update for issues that may occur when you manage the HyperV role on the 64bit editions of Windows Server 2008 by using SCVMM. http://support.microsoft.com/default.aspx?

- 23 -

scid=kb;ENUS;956589 ●

956774 : A Background Intelligent Transfer Service (BITS) client cannot handle files that have paths that contain the volume GUID in Windows Server 2008 or in Windows Vista. http://support.microsoft.com/default.aspx?scid=kb;ENUS;956774

●

942372 : When you try to create a template from a Windows Server 2003 Service Pack 2based virtual machine in System Center Virtual Machine Manager 2007, the job fails. http://support.microsoft.com/default.aspx/kb/942372

●

959596 : Description of the System Center Virtual Machine Manager 2008 update to address physical to virtual (P2V) issues. http://support.microsoft.com/kb/959596

●

954563 : Memory corruption may occur with the Windows Management Instrumentation (WMI) service on a computer that is running Windows Server 2008 or Windows Vista Service Pack 1. http://support.microsoft.com/default.aspx?scid=kb;ENUS;954563

●

958124 : A wmiprvse.exe process may leak memory when a WMI notification query is used heavily on a Windows Server 2008 R2based or Windows Vistabased computer. http://support.microsoft.com/default.aspx?scid=kb;ENUS;958124

●

955805 : Certain applications become very slow on a Windows Server 2008 R2based or Windows Vista SP1based computer when a certificate with SIA extension is installed. http://support.microsoft.com/default.aspx?scid=kb;ENUS;955805

●

956697 : Windows Server 2008 HyperV VSS writer is not used during a backup job because of corrupted or invalid virtual machine configuration files http://support.microsoft.com/default.aspx?scid=kb;ENUS;956697

●

959978 : Error message when you back up a Windows Server 2003based virtual machine on a Windows Server 2008 HyperVbased computer: "GetWriterStatus FAILED for Selected writer [Microsoft HyperV VSS Writer], writer is in state [9] [VSS_WS_FAILED_AT_FREEZE]" http://support.microsoft.com/default.aspx? scid=kb;ENUS;959978

●

958184 : Virtual machine backup operations fail in Windows Server 2008 when HyperV virtual machine files are saved on a volume that is mounted on a failover cluster by using a volume GUID. http://support.microsoft.com/default.aspx?scid=kb;ENUS;958184

c. Mise à jour pour les services de haute disponibilité de Windows Server 2008 pour HyperV ●

951308 : Increased functionality and virtual machine control in the Windows Server 2008 Failover Cluster Management console for the HyperV role. Cette mise à jour améliore les fonctionnalités et le contrôle des machines virtuelles au sein de la console de gestion MMC des services de cluster de Windows Server 2008. http://support.microsoft.com/?id=951308

d. Mise à jour pour les services P2V de SCVMM 2008 ●

- 24 -

959596 : Last Review January 15, 2009 Revision: 2.0 Description of the System Center Virtual Machine Manager 2008 update to address physical to virtual (P2V) issues http://support.microsoft.com/kb/959596. System Center Virtual Machine Manager 2008 doit être installé et il n’est pas nécessaire de redémarrer le système.

Administration et maintenance L’administration et la maintenance des platesformes HyperV sont cruciales pour garantir le bon fonctionnement des machines virtuelles invitées utiles aux différentes applications de l’entreprise. Nous avons vu à quel point une stratégie de virtualisation pouvait influer sur le coût total de possession et donc sur le retour sur investissement que l’entreprise était en droit d’espérer. Cependant, à l’opposé de ces aspects positifs, le fait que les platesformes de virtualisation soient au cœ ur des infrastructures informatiques, impose de la part des équipes systèmes une rigueur particulièrement stricte et précise et plus particulièrement en terme d’administration avancée de serveurs. Par administration avancée, il faudra entendre l’administration et la supervision en fonction du niveau de criticité de chaque plateforme mais aussi une surveillance proactive des ressources des machines hôtes et une politique de contrôle des changements efficace. Ce chapitre présente les différentes opérations que les responsables des hôtes HyperV devront prendre en charge.

1. Découverte des outils d’administration HyperV Comme cela est le cas avec chaque rôle ou fonctionnalité intégré à Windows Server 2008 R2, la console MMC d’administration d’HyperV est automatiquement ajoutée dans les Outils d’administration à l’issue de l’installation d’HyperV. Il est donc possible d’accéder, à l’ensemble des fonctions d’administration d’HyperV de plusieurs manières. Ces différentes méthodes sont présentées cidessous.

a. Via le Gestionnaire de serveur L’utilisation de cette console centrale sera surtout utile lorsque l’administrateur souhaite réaliser de multiples tâches d’administration. Il peut s’agir de créer une unité d’organisation dans Active Directory, de modifier les paramètres d’un objet GPO ou de créer une capture instantanée d’une machine virtuelle avant d’y appliquer une mise à jour.

Intégration des outils HyperV dans le Gestionnaire de serveur La figure illustre le fonctionnement de plusieurs machines virtuelles. La machine virtuelle SCOM01 utilise à cet instant 45 % du processeur et dispose d’une capture instantanée.

b. Via la console Gestionnaire HyperV L’utilisation de cette console spécialisée offrira à l’administrateur toutes les fonctions de base nécessaires à la gestion de la plateforme HyperV.

- 1-

Console de gestion Gestionnaire Hyper V

c. Via la commande Vmconnect.exe L’administrateur aura aussi la possibilité d’invoquer la commande Vmconnect.exe. Cette commande est disponible sur toutes les machines sur lesquelles sont installés les outils d’administration HyperV. Pour lancer cette commande, il est nécessaire de se positionner dans le répertoire contenant le programme ou de spécifier l’emplacement C:\Program Files\HyperV.

Utilisation de la commande Vmconnect.exe, sans aucun paramètre Lorsque la commande est exécutée sans aucun paramètre, l’interface graphique apparaît. Elle permet alors de spécifier le nom DNS ou l’adresse IP de la machine hôte HyperV ainsi que le nom de la machine virtuelle sur laquelle l’administrateur souhaite se connecter. La commande Vmconnect.exe supporte les paramètres suivants :

- 2-

Paramètres supportés par la commande Vmconnect.exe La ligne de commande cidessous permet à l’administrateur d’accéder à la machine virtuelle nommée "Ubuntu 8.10 KDE Ubuntu01" sur la machine hôte HyperV hv02.

Exemple de ligne de commande Vmconnect.exe La commande cidessus utilise le nom de la machine virtuelle, telle qu’elle existe sur le serveur hôte HyperV. Le fait de renommer la machine virtuelle, pourrait avoir un impact dans l’exécution de scripts qui utiliseraient ces noms. Pour parer à ce type d’inconvénient, la commande vmconnect.exe peut utiliser le GUID de la machine virtuelle. L’utilisation du GUID à la place du nom est intéressante lorsque deux machines virtuelles disposent du même nom. Dans ce cas, il faut utiliser la commande : "C:\Program Files\HyperV\vmconnect.exe" HyperVHost G {GUID de la VM}.

À l’inverse de la console MMC Gestionnaire HyperV, la commande Vmconnect.exe ne fonctionne pas en mode élévation. Pour éviter des problèmes d’authentification, il faudra exécuter ce programme en spécifiant l’option Exécuter en tant qu’administrateur.

2. Installation des outils d’administration à distance Windows Server 2008 R2 dispose de nombreuses méthodes d’administration à distance. Concernant la gestion des machines hôtes HyperV, il sera nécessaire d’installer les outils d’administration à distance pour prendre en charge les serveurs hôtes HyperV et pour accéder aux machines virtuelles invitées. Les entreprises qui ont déployé HyperV sur des installations minimales de Windows Server 2008 R2, Server Core, sont obligées d’implémenter les outils d’administration à distance.

a. Installation des outils d’administration sous Windows Server 2008 R2 Les serveurs qui exécutent une version complète de Windows Server 2008 R2 sans avoir le rôle HyperV installé disposent du nouveau Gestionnaire de serveur mais ne disposent pas du composant enfichable Gestionnaire HyperV. L’ajout d’un ou de plusieurs composants d’administration est implémenté au niveau des fonctionnalités intégrées au niveau du Gestionnaire de serveur.

- 3-

Assistant Ajout de fonctionnalités / Outils d’administration de serveur distant Les outils d’administration à distance, appelés RSAT (Remote Server Administration Tools), sont disponibles dans les versions Windows Server 2008 R2 Editions Standard, Entreprise et Datacenter.

b. Installation des outils d’administration sous Windows Vista La stratégie de Microsoft et les recommandations qui en découlent font que Windows Vista, et depuis peu Windows 7, sont des systèmes d’exploitation particulièrement adaptés aux administrateurs. Le système est moderne et sécurisé tant au niveau des couches réseaux TCP/IP NextGen, IPv6, IP Auth, qu’au niveau de l’environnement d’exécution du système UAC, Bitlocker, etc. Par voie de conséquence l’approche de Microsoft est très claire : le système d’exploitation client le plus récent est le système optimum pour assurer le meilleur niveau de sécurité qui soit, surtout concernant les tâches d’administration. Les outils d’administration HyperV sont donc disponibles pour les platesformes 32 bits et 64 bits de Windows Vista SP1et SP2 Editions Professionnel, Entreprise et Intégrale. Vous pourrez vous procurer cette mise à jour en 32 bits et aussi en 64 bits en recherchant sur le site de Microsoft l’article KB952627. Cette mise à jour contient la console MMC Gestionnaire HyperV ainsi que l’outil de connexion aux machines virtuelles. Les outils d’administration à distance pour HyperV sont particulièrement nécessaires pour prendre en charge l’administration des machines hôtes HyperV installées en mode Server Core. Pour plus de renseignements sur la mise à jour décrite dans le document KB952627, référezvous au lien suivant : http://support.microsoft.com/kb/952627.

c. Utilisation du Bureau à distance via RDP (Mstsc.exe) ou via RemoteApp L’administration à distance des machines hôtes HyperV consiste à utiliser les outils prévus à cet effet. Cependant, au lieu d’utiliser le Gestionnaire HyperV, il est possible d’accéder à la console du serveur à l’aide d’une session de type Bureau à distance. L’utilisation de cette méthode permettra à des machines Windows XP d’accéder aux outils d’administration HyperV, qui rappelonsle, ne sont disponibles que pour les environnements Windows Server 2008 R2, Windows Vista SP1 et SP2 et Windows 7. Cependant, il faut noter que même si l’utilisation des sessions de type Bureau à distance est utilisable dans nombre de cas, les limitations suivantes doivent être considérées : ●

- 4-

La séquence de touches [Ctrl] [Alt] [Suppr] . pourra être conflictuelle entre Mstsc.exe, utilisé pour la session RDP, et Vmconnect.exe, utilisé pour accéder à la machine virtuelle. Ce problème n’est pas dû à HyperV mais à Mstsc.exe qui intercepte de manière prioritaire ces séquences de touches avant l’outil HyperV

Vmconnect.exe. ●

Pour corriger ce problème gênant, il suffit de configurer les paramètres HyperV pour que les combinaisons de touches Windows soient directement envoyées vers la machine virtuelle. La figure cidessous illustre cette option disponible via le Gestionnaire HyperV Paramètres HyperV Clavier.

Gestion des Combinaisons de touches Windows avec Mstsc.exe et Vmconnect.exe Il est aussi possible d’utiliser le menu Action de l’application Vmconnect.exe. De cette manière, la séquence de touche est directement routée vers la machine virtuelle sans interférer avec l’environnement de la session de Bureau à distance.

- 5-

Envoi de la séquence de touches via le menu Action

●

L’outil de connexion aux machines virtuelles, Vmconnect.exe, ne disposera pas du contrôle de la souris tant que les services d’intégration n’auront pas été installés dans la machine virtuelle.

Contrôle de la souris en session RDP sans les services d’intégration

- 6-

●

Il faut donc s’assurer que les services d’intégration sont bien installés dans chaque système d’exploitation invité.

Une autre solution originale consiste à accéder aux outils d’administration HyperV en publiant l’application Virtmgmt.msc, c’estàdire la console Gestionnaire HyperV, via RemoteApp inclu avec les services de terminaux de Windows Server 2008 R2. Ainsi, n’importe quel poste de travail du réseau fonctionnant sous Windows Vista, Windows Server 2008 R2, Windows XP SP2 ou Windows Server 2003 SP1 pourra accéder à l’application Gestionnaire HyperV. RemoteApp nécessite que le client Connexion Bureau à distance version 6.0 ou 6.1 soit installé. La version 6.0 utilisable sur Windows XP SP2 et Windows Server 2003 SP1 ou ultérieur est disponible via l’article 925876 de la Base de connaissances Microsoft ou via le lien http://go.microsoft.com/fwlink/?LinkId= 79373. La version 6.1 du client RDP est directement intégrée Windows Server 2008 R2, Windows Vista SP1 et Windows XP SP3. Toutes les applications publiées via RemoteApp s’exécutent sur le serveur Terminal Services sur lequel les services RemoteApp ont été installés, mais s’affichent dans leur propre fenêtre Windows dans le bureau de l’utilisateur. D’un point de vue licence, les sessions offertes via RemoteApp s’inscrivent dans le contexte des accords de licences des services de terminaux. Enfin, concernant la méthode d’accès, RemoteApp est un portail Web basé sur le client Connexion Bureau à distance version 6.1 ou 6.0, donc sur le protocole RDP utilisant le port TCP 3389. Vous avez cependant la possibilité de « passer en HTTPS sur le port 443 » en implémentant les services TS Gateway de Windows Server 2008 R2. Pour plus d’informations sur l’installation de ce composant, téléchargez le Guide d’installation disponible via le lien http://go.microsoft.com/fwlink/?linkid=79605.

d. Windows PowerShell Microsoft a clairement positionné PowerShell comme étant « le » langage de scripting des administrateurs. La version 1.0 de PowerShell inclut quelques 130 cmdlets qui permettent aux administrateurs de réaliser des tâches d’automation complexes et la version 2.0, qui sera intégrée de base dans Windows Server 2008 R2, en contient plusieurs centaines. Une autre nouveauté de cette dernière version est aussi le support natif d’HyperV. Ce langage est pris en charge sur les platesformes Windows XP, Windows Vista, Windows Server 2003 et est inclus de base dans Windows Server 2008 R2. De plus, il fait partie intégrante des produits de la gamme serveurs de Microsoft. En effet, PowerShell est un composant indispensable pour Exchange Server 2007, System Center Operations Manager 2007, System Center Data Protection Manager 2007 et aussi System Center Virtual Machine Manager 2008. Concernant les outils d’administration fournis avec HyperV, ils n’incluent pas d’outils de type ligne de commande. En fait, l’interface d’administration Gestionnaire HyperV invoque le fournisseur WMI HyperV inclus avec HyperV. La solution consiste donc à utiliser le support de WMI inclus dans PowerShell via le cmdlet GetWmiObject pour invoquer l’ensemble des services d’administration d’HyperV. Vous pourrez télécharger à partir du site CodePlex la version 1.0b de la librairie PowerShell HyperV contenant plus de 80 fonctions. Les mises à jour de cette librairie contenue dans le fichier HyperV.ps1 peuvent être téléchargées à l’adresse suivante : http://www.codeplex.com/psHyperV CodePlex est un site web mis à la disposition des projets de développement Open Source par Microsoft. Vous pouvez simplement y récupérer librement les logiciels créés par la communauté CodePlex ou participer à des projets existants. Pour plus de renseignements sur PowerShell et le site CodePlex dédié à HyperV, connectezvous sur les liens cidessous : Scripting with PowerShell, http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx ainsi que la communauté HyperV CodePlex via http://pshyperv.codeplex.com/. Les fonctions suivantes permettront aux administrateurs de réaliser la plupart des opérations d’administration d’HyperV et de gestion de machines virtuelles : ●

Rechercher une machine virtuelle : GetVM, ChooseVM, GetVMHost

●

Se connecter à une machine virtuelle : NewVMConnectSession

●

Découvrir et manipuler l’état des machines virtuelles :

- 7-

GetVMState, SetVMState, ConvertVmState, PingVM, TestVMHeartBeat, ShutdownVM, StartVM, StopVM, SuspendVM GetVMKVP, AddKVP, RemoveKVP, GetVMJPEG ●

Sauvegarder, exporter et créer une capture instantanée de machines virtuelles : ExportVM, ImportVM, GetVMSnapshot, ChooseVMSnapshot, ApplyVMSnapshot, NewVMSnapshot, RemoveVMSnapshot, RenameVMSnapShot, UpdateVMSnapshot, GetVMSnapshotTree, GetVmBackupScript

●

Ajouter, supprimer et configurer les machines virtuelles : NewVM, RemoveVM, SetVM, GetVMCPUCount, SetVMCPUCount, GetVMMemory, SetVMMemory, Set VMSerialPort

●

Manipuler les contrôleurs de disques, les disques et les disques virtuels : GetVMDiskController AddVMSCSIController, RemoveVMSCSIcontroller GetVMDriveByController, AddVMDRIVE, RemoveVMdrive GetVMDiskByDrive, AddVMDISK, SetVMDisk, GetVMDisk GetVMFloppyDisk, AddVMFloppyDisk AddVMNewHardDisk

●

Manipuler les interfaces réseau : GetVMNic, ListVMNic, ChooseVMNIC, VMNICConnection, GetVMNicport,

AddVMNIC,

RemoveVMNIC,

SetVMNICAddress,

Set

GetVMnicSwitch, ChooseVMSwitch, NewVMSwitchPort, GetVMByMACaddress, ChooseVMExternalEthernet, NewVMExternalSwitch, NewVMInternalSwitch, NewVmPrivateSwitch ●

Manipuler les fichiers des disques virtuels VHD : GetVHDDefaultPath, GetVHDInfo, NewVHD, CompactVHD, TestVHD, ConvertVHD, MergeVHD, MountVHD, UnmountVHD

e. Interface et classes WMI pour HyperV La couche de virtualisation HyperV expose une interface d’administration très complète qui permettra aux administrateurs de surveiller et de contrôler l’ensemble de l’environnement de virtualisation. L’intégralité des fonctions d’HyperV peut être contrôlée via le fournisseur WMI (Windows Management Instrumentation), HyperV. Ainsi, il est possible d’accéder aux grandes catégories de services cidessous : ●

Services de gestion des systèmes virtuels ;

●

Services réseau ;

●

Gestion des ressources.

Sur la base de ces catégories, il est possible de développer des scripts et des applications capables de faciliter la gestion des environnements virtuels HyperV. Le fournisseur WMI expose les classes les plus importantes suivantes : BIOS, Integration Components, Memory, Networking, Processor, profile Registration, Resource Management, Storage, Virtual System, Virtual System Management.

- 8-

Parcours des classes WMI HyperV à l’aide du WMI Object Browser La figure cidessus montre les différentes classes WMI à l’aide de l’outil Microsoft WMI Object Browser. Les différentes classes WMI sont en contact direct avec les services Windows de la partition parent de la machine hôte HyperV. Ces différentes relations sont présentées dans le tableau qui suit en faisant correspondre les services de gestion HyperV, les noms des classes WMI HyperV et les différentes opérations prises en charge : Nom du service Windows VMMS (Virtual Machine Management Service)

Nom de la classe WMI Msvm_VirtualSystemManagementService

Opérations supportées Création, suppression de machine virtuelle Import, Export, Snapshot de machine virtuelle

HyperV Networking Management Service (nvspwmi)

Msvm_VirtualSwitchManagementService

Création, suppression de ressources réseaux, switchs virtuels et ports.

HyperV Image Management Service (vhdsvc / virtsvcs)

Msvm_ImageManagementService

Création, montage et démontage de média virtuels

Les outils WMI Microsoft sont inclus dans le package WMITools.exe disponible sur le site de téléchargement Microsoft. Ce package contient WMI CIM Studio, WMI Object Browser, WMI Event Registration et WMI Event Viewer. Pour plus de renseignements sur l’ensemble des classes WMI HyperV, vous pouvez accéder au site MSDN ou télécharger le Webcast TechNet intitulé « Managing HyperV and Virtual Machines with WMI and Windows PowerShell ».

f. System Center Virtual Machine Manager System Center Virtual Machine Manager 2008 fait partie de la gamme Microsoft System Center et fournit à ce titre une solution d’administration globale pour les environnements virtualisés de type Datacenter. Il permet la prise en charge de plusieurs technologies de virtualisation et permet d’optimiser l’utilisation des ressources offertes par les machines hôtes. © ENI Editions - All rigths reserved

- 9-

Les principales fonctionnalités de SCVMM 2008 sont les suivantes : ●

Gestion des machines virtuelles fonctionnant sous HyperV et HyperV Server.

●

Prise en charge des machines virtuelles fonctionnant sous MS Virtual Server 2005 R2 EE SP1 et VMware ESX.

●

Support complet pour la consolidation des serveurs au sein d’une infrastructure de virtualisation.

●

Support de la technologie PRO Performance and Resource Optimization, pour une gestion dynamique et efficace des opérations de gestion des ressources des infrastructures virtualisées.

●

Placement intelligent des charges virtuelles sur les meilleurs serveurs hôtes.

●

Gestion des objets à l’aide des librairies SCVMM.

Les services pris en charge par SCVMM 2008 sont résumés cidessous :

- 10 -

●

Gestion des environnements hétérogènes à partir d’une console centrale unique.

●

Services de conversion P2V et V2V rapides et performants.

●

Placement intelligent des machines virtuelles sur les hôtes.

●

Gestion centralisée des ressources grâce aux librairies SCVMM.

●

Provision rapide des machines virtuelles.

●

Surveillance centralisée des machines virtuelles.

●

Gestion de la délégation des rôles.

●

Administration de la délégation au niveau de l’infrastructure virtuelle.

●

Interface familière Windows et services basés sur les technologies Windows.

●

Automation via l’intégration de PowerShell.

Interface d’administration centrale avec SC Virtual Machine Manager 2008 L’administration HyperV basée sur SCVMM 2008 est traitée dans les chapitres Architecture et installation de SCVMM 2008 R2, Gestion de la virtualisation avec SCVMM 2008 R2 et Sauvegarde et automation avec SCVMM 2008 R2 de l’ouvrage. Pour plus de renseignements sur System Center Virtual Machine Manager, vous pouvez aussi consulter le site : http://www.microsoft.com/scvmm.

3. Administration des composants HyperV La console d’administration Gestionnaire HyperV permet de faire le réglage de paramètres globaux qui auront un impact sur la structure et le comportement de la plateforme HyperV. Parmi ces paramètres principaux, l’interface d’administration met en évidence : ●

Les paramètres concernant la machine hôte HyperV.

●

Les paramètres concernant la segmentation des réseaux avec les Switchs virtuels.

●

Les paramètres des disques durs.

La figure cidessous montre le menu Actions de la console Gestionnaire HyperV. L’ensemble des fonctions principales est concentré dans ce menu.

- 11 -

Menu Actions HyperV

a. Paramètres HyperV Les paramètres HyperV concernent principalement les emplacements relatifs au stockage. L’administrateur a ainsi la possibilité de définir l’emplacement des disques des machines virtuelles, fichiers VHD, ainsi que l’emplacement des données concernant les captures instantanées. Les captures instantanées sont appelées en anglais snapshots. Elles représentent des points d’arrêt d’une machine virtuelle donnée situés à différentes dates. Directement implémentés par HyperV, les captures instantanées sont utilisables avec n’importe quelle version de système d’exploitation, quelle que soit l’activité en cours au sein de la machine virtuelle et ne génèrent aucune interruption de service. HyperV supporte jusqu’à 50 captures instantanées par machine virtuelle.

- 12 -

Paramètres HyperV : stockage disques, captures instantanées et paramètres utilisateurs

●

Le premier paramètre Disques durs virtuels permet de spécifier le dossier qui contiendra les disques durs virtuels. Généralement, cet emplacement sera affecté à un disque disponible via une architecture de stockage SAN en Fibre Channel ou en iSCSI.

●

Le deuxième paramètre Ordinateurs virtuels permet de spécifier le dossier contenant les captures instantanées. Par défaut, le chemin utilisé par HyperV pour stocker les informations générales de toutes les machines virtuelles est le suivant : C:\ProgramData\Microsoft\Windows\HyperV.

Le sousdossier Virtual Machines contient des liens symboliques qui pointent vers les machines virtuelles. Le sousdossier « Snapshots » contient pour sa part des liens symboliques qui pointent vers les fichiers de captures instantanées.

Les dossiers Virtual Machines et Snapshots contiennent des liens symboliques

- 13 -

Les emplacements spécifiés ici peuvent être des disques locaux directement attachés à la machine hôte HyperV ou des disques externes situés sur un SAN. ●

Les paramètres de Clavier permettent de configurer le comportement des combinaisons de touches Windows (par exemple, la séquence [Alt] [Tab]), lorsque l’application Connexion à un ordinateur virtuel Vmconnect est utilisée. Les options disponibles permettent de diriger les séquences de touches vers la machine hôte HyperV, vers la machine virtuelle ou aussi vers la machine virtuelle uniquement lorsque celleci est en mode plein écran.

●

Les paramètres de Touche de relâchement de la souris permettent de spécifier la combinaison de touches à utiliser avec l’application Connexion à un ordinateur virtuel Vmconnect, pour relâcher la souris lorsque les services d’intégration ne sont pas installés à l’intérieur de la machine virtuelle. Les options disponibles permettent de sélectionner [Ctrl] [Alt] [Flèche à gauche] ou [Flèche à droite] ou [Espace] ou encore [Shift].

●

Les paramètres d’informations d’identification de l’utilisateur donnent, ou non, la possibilité d’utiliser les informations d’identification mises en oeuvre lors de l’ouverture de session avec l’application Connexion à un ordinateur virtuel.

Pour utiliser une authentification de type Carte à puce, il est nécessaire de décocher l’option Utiliser automatiquement (sans invite) les informations d’identification par défaut.

●

L’option Supprimer les informations d’identification enregistrées permet de supprimer les informations utilisées pour se connecter à une machine virtuelle en cours d’exécution.

●

L’option Réinitialiser les cases à cocher permet de restaurer les messages de confirmation et les pages d’assistants masquées à la demande de l’utilisateur.

Pour obtenir les meilleures performances en I/O disques, il est recommandé de placer l’emplacement des fichiers de disques virtuels et de fichiers de snapshots sur des disques différents. De cette manière, les demandes d’écritures disques ne satureront pas les disques contenant les fichiers VHD des machines virtuelles.

b. Paramètres des réseaux virtuels La configuration des réseaux virtuels est une phase essentielle à la bonne implémentation d’une plateforme de virtualisation. La figure cidessous met en évidence qu’un réseau virtuel dispose de trois grands types de connectivité :

- 14 -

●

Une connectivité Externe, physiquement connectée sur une unique interface réseau,

●

Une connectivité Interne uniquement,

●

Une connectivité Réseau d’ordinateurs virtuels privé.

Options de configuration d’un réseau virtuel

●

Réseau Externe : ce type de modèle de connectivité permet les communications suivantes : ●

Communications autorisées entre les machines virtuelles sur la machine hôte ;

●

Communications autorisées entre les machines virtuelles et la partition parent ;

●

Communications autorisées entre les machines virtuelles et les machines externes.

Ce type de configuration est particulièrement utile pour autoriser les communications entre n machines virtuelles, entre n machines virtuelles et la partition parent et aussi avec les machines situées à l’extérieur. Il est recommandé de séparer les flux réseaux d’administration des flux réseaux relatifs aux machines virtuelles en implémentant plusieurs cartes réseaux. ●

Réseau Interne uniquement : ce type de modèle de connectivité permet les communications suivantes : ●

Communications autorisées entre les machines virtuelles sur la machine hôte ;

●

Communications autorisées entre les machines virtuelles et la partition parent.

Ce type de configuration est particulièrement utile pour autoriser les communications entre n machines virtuelles et aussi avec la partition parente. Un usage intéressant de ce type de modèle sera la mise en œ uvre de machines virtuelles de tests. Vous pouvez aussi isoler les machines virtuelles de la partition parente en sélectionnant l’option Activer l’authentification LAN virtuelle pour la partition parente. ●

Réseau d’ordinateurs virtuels privé : ce type de modèle de connectivité permet les communications

- 15 -

suivantes : ●

Communications autorisées entre les machines virtuelles sur la machine hôte.

Ce type de configuration est particulièrement utile pour autoriser les communications seulement entre les machines virtuelles. Dans cette configuration les communications avec la machine hôte HyperV et les réseaux externes sont interdites.

c. Paramètres et opérations sur les disques virtuels HyperV supporte la majorité des options de stockage disponibles sur le marché. Les disques locaux de type SAS ou SATA ainsi que les stockages de type SAN basés sur Fibre Channel et iSCSI. Une fois que le stockage est exposé à la machine hôte HyperV, plusieurs méthodes peuvent être utilisées pour que les machines virtuelles puissent l’exploiter : ●

Les machines virtuelles ont leur système d’exploitation installé sur un disque virtuel. Ce disque existe sous la forme d’un fichier .VHD stocké sur un disque local ou un disque exposé via une architecture SAN.

●

Les machines virtuelles ont leur système d’exploitation installé sur un disque physique pris en charge par la machine hôte HyperV, ce qui signifie que dans ce cas, la machine virtuelle utilise directement le disque physique sans utiliser de disque virtuel.

La page suivante illustre l’utilisation du disque au sein d’une machine virtuelle. La figure cidessous montre que le disque de base n°3 est positionné dans l’état déconnecté.

Passage du disque Windows en mode Déconnecté La figure cidessous illustre la sélection du type de disque "physique", sachant qu’au préalable, le disque devra être positionné dans l’état "Déconnecté".

- 16 -

Choix du type de disque : disque virtuel ou bien disque physique #3 Audelà de ces grands choix, l’interface Gestionnaire HyperV permet, via le menu Actions d’accéder aux fonctions de maintenance des disques. Deux options sont proposées : la première, Modifier le disque, permet de réaliser des opérations d’entretien, tandis que la seconde, Inspecter le disque, permet d’obtenir le statut général du disque. Ces deux options sont décrites cidessous : ●

Modifier le disque : le lancement de cet assistant permet d’accéder aux fonctions de compactage, de conversion et d’extension des disques virtuels.

- 17 -

Choix des actions de modifications applicables sur les disques virtuels.

- 18 -

●

Opération de compactage : cette opération permet de réduire la taille du fichier du disque virtuel en supprimant les zones du disque non utilisées. Cette opération peut être longue en fonction de la taille du disque mais est très pratique s’il est nécessaire de récupérer de l’espace de stockage. Par exemple lorsqu’un volume de données important est définitivement supprimé d’une machine virtuelle ou si le disque doit être le plus petit possible pour par exemple être archivé.

●

Opération de conversion : cette option a pour objet de convertir un disque dur virtuel dynamique en un disque dur virtuel fixe en recopiant son contenu. À la différence des disques virtuels dynamiques qui peuvent s’étendre dynamiquement, les disques fixes disposent d’une taille bien définie. Les disques virtuels dynamiques sont donc bien plus flexibles mais moins performants que les disques virtuels fixes. Il peut être judicieux de commencer par utiliser des disques virtuels dynamiques, et si le niveau de performances l’exige, de lancer une opération de conversion pour profiter des temps d’accès offerts par les disques virtuels fixes.

●

Opération d’extension : cette option permet d’augmenter la capacité de stockage d’un disque dur virtuel de taille dynamique ou d’un disque dur virtuel de taille fixe. Les disques virtuels de taille dynamique disposent néanmoins d’une limite fixée au moment de la création du disque. L’opération d’extension permet de repousser cette limite. Pour rappel, la taille par défaut d’un disque virtuel dynamique ou fixe est de 127 Go, sachant que la taille maximum est de 2040 Go (2To). Attention au fait qu’il n’est pas recommandé de modifier un disque virtuel lorsqu’une machine virtuelle utilise des captures instantanées ou quand il est associé à un disque différentiel. L’opération d’extension peut causer une perte de données.

●

Opération de fusion : cette opération concerne uniquement les disques de différentiation et permet de combiner les modifications d’un disque de différenciation avec le disque parent. Il est possible de copier le contenu du disque parent et du disque de différenciation sur un nouveau disque dur virtuel cible, ce qui permet de conserver les deux disques intacts, ou bien de directement appliquer les modifications sur le disque parent. La première option est plus sûre car elle permet de préserver les données originales.

●

Opération de reconnexion : cette opération concerne uniquement les disques de différenciation. Lorsque le disque dur virtuel parent est introuvable, cette option apparaît automatiquement et permet de réassocier le disque parent, si par exemple celuici a été déplacé ou restauré à un autre emplacement.

Problème de chaînage dans la chaîne de différenciation et option Reconnecter

●

Inspecter le disque : cette opération permet d’afficher l’ensemble des propriétés d’un disque virtuel. Les informations concernant le type de disque (disque dynamique, fixe ou différentiel), l’emplacement, le nom du fichier de disque virtuel avec l’extension VHD, la taille courante, la taille maximum ainsi que le statut de la chaîne de différenciation lorsqu’il s’agit d’un disque différentiel sont affichées.

4. Maintenance des hôtes HyperV La maintenance des machines hôtes HyperV doit obligatoirement faire l’objet d’un plan de gestion basé sur les impératifs de disponibilité et de sécurité de la plateforme. La criticité d’un serveur hôte HyperV prenant en charge des machines virtuelles utilisées à des fins de tests n’est bien entendu pas du même ordre que celui accueillant une application critique pour le fonctionnement de l’entreprise. Il conviendra donc dans le PRA (Plan de Reprise d’Activité), en anglais DRP (Disaster Recovery Plan), d’estimer les impacts sur l’activité de l’entreprise en se basant sur une catégorisation des machines virtuelles et applications et enfin sur la disponibilité d’un environnement opérationnel en mode dégradé assorti des opérations à entreprendre pour récupérer un niveau de fonctionnement optimal. Ainsi, il est fréquent de définir les niveaux d’indisponibilité acceptés suivants : « critique pour moins de 4 heures d’indisponibilité », « important lorsque celleci est comprise entre 4 heures et 24 heures » et « bas lorsque celleci est supérieure à 24 heures ». Enfin, une fois la politique clairement définie, il faut implémenter les moyens qui permettront aux équipes informatiques de surveiller de manière proactive les platesformes physiques, la technologie de virtualisation HyperV, les machines virtuelles ainsi que les systèmes d’exploitation invités et les applications.

a. Surveillance proactive avec SCOM 2007 La charge et la qualité des services à prendre en compte sont des facteurs qui seront directement impactés par le nombre d’hôtes HyperV et le nombre de machines virtuelles incluses dans l’étendue du projet. Une surveillance de bon niveau nécessite de contrôler et d’analyser de manière systématique les journaux d’événements des systèmes les plus critiques, ainsi que les changements de configuration et l’ensemble des tâches d’administration. Microsoft System Center Operations Manager 2007 prend en charge les platesformes Windows Server, la version R2 ayant été enrichie du support des platesformes Unix. SCOM a été conçu pour faciliter le travail des administrateurs des plus grandes entreprises en consolidant les événements, les données de performances et en restituant le statut des systèmes, des hôtes HyperV, des machines virtuelles au sein d’un stockage central basé sur SQL Server. SCOM 2007 est intéressant à plus d’un titre pour la supervision des platesformes de virtualisation HyperV, grâce aux fonctionnalités suivantes : ●

Interface de gestion centralisée pour la supervision des matériels serveurs (Dell, HP, IBM…), des hôtes HyperV, des machines virtuelles, des systèmes d’exploitation Windows Server et des applications Windows fournies par Microsoft.

●

Support des applications tierces parties via l’ajout de « Management Packs » additionnels.

- 19 -

●

Consolidation de tous les événements pour analyse.

●

Base de connaissance constituée des bonnes pratiques et articles techniques Microsoft.

●

Gestion des alertes.

●

Gestion des rapports.

Microsoft SCOM 2007 est nécessaire à l’utilisation de la technologie PRO (Performance and Resource Optimization), intégrée à SCVMM 2008. Les données de performances sont collectées par SCOM pour proposer un placement intelligent des machines virtuelles sur les meilleurs hôtes HyperV.

b. Protection du Système d’exploitation de la partition principale La sécurisation d’une plateforme de virtualisation HyperV est basée sur les mêmes mesures que celles qui seraient prises pour Windows Server 2008 R2. Pour plus d’informations sur la sécurisation des systèmes Windows Server 2008 R2, consultez le Windows Server 2008 R2 Security Guide disponible à l’adresse : http://go.microsoft.com/fwlink/?LinkId=134200 Cependant, il peut être judicieux d’implémenter certaines actions spécifiques pour sécuriser particulièrement les machines virtuelles, les fichiers de configuration et les données de la plateforme de virtualisation. Les points suivants peuvent être implémentés : ●

Sécuriser les machines virtuelles en accord avec les procédures de sécurisation en vigueur dans l’entreprise (outils, antivirus, segmentation réseau, stratégie de sauvegardes, etc.).

●

Configurer les contrôles d’accès bases sur les rôles HyperV.

●

Utiliser la technologie de cryptage disque BitLocker pour protéger les disques virtuels et les données stockées sur le serveur hôte HyperV.

Le cryptage des disques via BitLocker nécessite une implémentation rigoureuse. Pour plus d’informations, consultez le Guide de déploiement de BitLocker disponible à l’adresse : http://go.microsoft.com/fwlink/? LinkId=134201

Attention ! N’utilisez pas BitLocker à l’intérieur d’une machine virtuelle. Le cryptage des disques via BitLocker n’est pas supporté au sein d’une machine virtuelle.

●

Installer la partition parent sur une installation minimale Server Core, de Windows Server 2008 R2. La surface d’attaque est fortement réduite ainsi que le nombre de mises à jour Windows et le nombre de redémarrages. Pour plus d’informations sur l’installation et la configuration de Windows Server 2008 R2 en mode Server Core, consultez le document intitulé « Server Core Installation Option of Windows Server 2008 R2 StepByStep Guide » via le lien suivant : http://go.microsoft.com/fwlink/?LinkId=134202.

Attention ! Il n’est pas possible de réaliser une mise à niveau d’une installation en mode Server Core vers une installation complète de Windows Server 2008 R2.

●

Éviter d’installer, et a fortiori, d’utiliser des applications au sein de la partition parent.

●

Si installation d’un antivirus dans la partition parent, veiller à exclure les répertoires suivants : ●

- 20 -

Emplacement des fichiers de configuration C:\ProgramData\Microsoft\Windows\HyperV.

des

machines

virtuelles

●

Emplacement des disques virtuels, y compris C:\Users\Public\Documents\HyperV\Virtual Hard Disks.

l’emplacement

par

défaut :

●

Emplacement contenant les captures instantanées, y compris l’emplacement par défaut : C:\ProgramData\Microsoft\Windows\HyperV\Snapshots.

●

Appliquer le même niveau de sécurité que celui des machines virtuelles à la machine hôtes HyperV.

●

Ne pas attribuer de privilèges d’administration sur la machine hôte HyperV aux administrateurs des machines virtuelles. En particulier sur ce type de machine respecter toujours la règle du moindre privilège accordé.

●

S’assurer que les machines virtuelles sont correctement mises à jour avant de les déployer dans l’environnement de production.

●

S’appuyer sur une machine hôte HyperV de maintenance configurée pour utiliser la fonctionnalité de haute disponibilité « Quick Migration ». Un serveur de maintenance peut être utilisé pour stocker les machines virtuelles à mettre à jour avant leur « déplacement » vers le nœ ud HyperV de production.

●

S’assurer que les services d’intégration sont installés dans les machines virtuelles. La validité de l’heure peut être utile pour la journalisation, la conformité de l’exécution de certaines opérations sensibles. Les services d’intégration prennent en charge la synchronisation horaire localement par rapport à la machine hôte Hyper V et aussi dans le cas où les machines virtuelles sont déplacées vers une salle machine située sur un autre fuseau horaire ou restaurées à partir de captures instantanées à une date antérieure.

●

Utiliser un réseau dédié à l’administration HyperV et assurezvous que ce réseau n’accepte aucun trafic non approuvé.

●

Microsoft recommande de désactiver au niveau du BIOS du serveur les options de virtualisation assistée par le matériel lorsque cela n’est pas nécessaire.

c. Mise à jour des machines virtuelles arrêtées Nous verrons plus loin qu’avec System Center Virtual Machine Manager 2008, il est possible de disposer de modèles de machines virtuelles stockées au sein d’une ou plusieurs librairies. Les librairies VMM tiennent lieu de stockage contrôlé pour les administrateurs qui disposeront des droits de créer des machines virtuelles. Concernant « les modèles de machines virtuelles », il s’agit de véritables « machines virtuelles arrêtées » dans l’attente d’être utilisées comme point de départ. La question posée est donc « Comment garantir le niveau des mises à jour des machines virtuelles modèles qui peuvent exister par dizaines, sans pour autant les démarrer manuellement et régulièrement ? ». La réponse est incluse avec l’outil Offline Virtual Machine Servicing Tool : cet outil permet de réaliser l’automation d’un nombre important de machines virtuelles non démarrées en coordination avec HyperV et System Center Virtual Machine Manager 2008. En plus de SCVMM, il faudra avoir procéder à la mise en œ uvre d’une plateforme de déploiement des mises à jour basée sur Windows Server Update Services 3.0 SP1, SC Configuration Manager 2007 SP1 ou SC Configuration Manager 2007 R2. Le fonctionnement de cet outil est basé sur l’exécution de jobs spécifiques appelés « servicing job ». Ces travaux gèrent les processus de mise à jour des machines virtuelles stockées dans les librairies VMM. Cette application basée sur la technologie Windows Workflow Foundation et sur l’exécution de scripts PowerShell réalise pour les cibles sélectionnées : ●

Une opération de réveil d’une ou de plusieurs machine(s) virtuelle(s) ;

●

Un cycle de contrôle des mises à jour approuvées vers la plateforme de mises à jour configurée, WSUS ou SC Configuration Manager ;

●

Une opération d’arrêt d’une ou des machine(s) virtuelle(s) accompagnée de son rangement au sein de la librairie VMM.

L’installation de cet outil est très simple. Un assistant de configuration assure le processus de connexion entre l’outil Offline Virtual Machine Servicing Tool, VMM et la plateforme de mises à jour. L’utilisation est ensuite basée sur la gestion de groupes de machines virtuelles, l’exécution de tâches pour définir les machines à mettre à jour, les ressources à utiliser et enfin, une planification de l’exécution. Les travaux pourront être déclenchés immédiatement

- 21 -

ou bien pendant des périodes de moindre activité, ou de manière périodique pour garder les machines virtuelles « modèles » le plus à jour possible. De plus, cet outil utilise le Gestionnaire de tâches de Windows. L’outil Offline Virtual Machine Servicing Tool 2.0.1 est disponible en téléchargement à partir du site de Microsoft via le lien : http://go.microsoft.com/fwlink/?LinkId= 110333. Le contenu du package contient le fichier MSI du programme ainsi que le Guide d’installation et de configuration.

- 22 -

Bonnes pratiques Vous trouverez cidessous une liste des meilleures recommandations en rapport avec la mise en œ uvre du rôle Hyper V : ●

Une fois la machine hôte HyperV mise en production, mettez en place une stratégie de surveillance et d’analyse des performances.

●

Surveillez les performances matérielles en fonction du nombre et de l’activité des machines virtuelles.

●

Évitez de surcharger le serveur HyperV : tout dépend du nombre de machines virtuelles et de la charge assurée par chacune d’entre elles. Pour les configurations les plus performantes, il est recommandé d’utiliser Windows Server 2008 R2 x64 Edition Entreprise ou Edition Datacenter. Ces deux versions prennent en charge avec HyperV jusqu’à 64 cœ urs, 1 To de mémoire RAM et les configurations à haute disponibilité jusqu’à 16 nœ uds avec le support de la fonctionnalité Quick Migration et Live Migration. La version Datacenter contient un accord de licence pour un nombre illimité de machines virtuelles.

●

Microsoft conseille un minimum de 2 Go de RAM par Cœ ur, soit par exemple 32 Go de RAM pour 16 cœ urs. La mémoire recommandée est de 4 Go de RAM par cœ ur, soit 96 Go de RAM pour 24 cœ urs.

●

Ne placez pas de fichiers systèmes sur le stockage utilisé par les machines v virtuelles HyperV.

●

Étudiez la structure de stockage pour allouer un espace à la partition parent, un espace au stockage des disques virtuels (fichiers VHD), un espace au stockage des captures instantanées via VSS et un espace au stockage des captures instantanées des machines virtuelles.

●

Utilisez des disques VHD de taille fixe ou bien des disques en mode Pass Through. La différence de performance est peu significative. Notez que les disques VHD peuvent être sauvegardés en mode VSS via les sauvegardes de la machine hôte HyperV, ce qui n’est pas le cas des disques Pass Through qui sont déconnectés de la machine parente.

●

Les disques en mode Pass Through sont légèrement plus performants que les disques virtuels de taille fixe mais ils ne peuvent pas profiter des sauvegardes VSS et créent une relation de type LUN x par rapport à une machine virtuelle. Réservez leur utilisation pour les serveurs de bases de données ou les serveurs de fichiers.

●

Évitez d’utiliser les disques VHD dynamiques avec des machines virtuelles devant disposer de bonnes performances en I/O disques.

●

Activez les fonctions MPIO du SAN pour utiliser plusieurs chemins et plus de bande passante.

●

Installez au moins 3 cartes réseaux pour chaque hôte HyperV : une interface à 1 Gb devrait être dédiée à l’administration des machines hôtes HyperV, au réseau intracluster et à la migration des machines virtuelles (les trafics de type cluster peuvent aussi être séparés), comme cela était le cas avec les versions antérieures de Windows Server. Une ou plusieurs cartes Quad Ports Gb Ethernet PCI Express pourront être dédiées pour les trafics des machines virtuelles. Il est recommandé d’utiliser une ou plusieurs autres interfaces. Les machines virtuelles nécessitent une bande passante. Cette même recommandation est à suivre si des flux doivent être isolés d’autres machines virtuelles. Attention au fait que lors de l’installation du rôle HyperV en mode RDP, la sélection de l’unique carte réseau en tant que carte intégrée au sein d’un réseau virtuel provoquera la coupure du lien réseau.

●

Configurez le logiciel de protection antivirus installé sur une machine hôte HyperV de telle sorte qu’il ne tienne pas compte des processus et répertoires d’HyperV. Vous devez aussi exclure les processus vmms.exe, le service de gestion des ordinateurs virtuels et vmwp.exe, le processus de travail de chaque machine virtuelle. Il est aussi recommandé d’exclure les répertoires contenant les fichiers de configuration des machines virtuelles ainsi que ceux contenant les disques durs virtuels et les captures instantanées.

●

Évitez d’accueillir sur le même serveur HyperV des machines virtuelles configurées avec les services d’intégration et des machines virtuelles configurées avec des périphériques en mode émulation. Les périphériques émulés nécessitent parfois de désactiver certaines capacités matérielles, ce qui aura un impact sur les périphériques synthétiques. Une solution consiste à ne pas partager ces interfaces entre des machines invitées de différente nature ou à les placer sur des machines hôtes HyperV différentes.

- 1-

●

Consultez sur le site de Microsoft le document intitulé « Performance Tuning Guidelines for Windows Server 2008 R2 » à l’aide du lien cidessous. Ce document résume l’ensemble des recommandations et règles de bonne conduite à avoir visàvis de chacun des rôles pris en charge par la plateforme Windows Server 2008 R2 : http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx.

●

Pour les tâches d’administration HyperV, utilisez principalement la console Gestionnaire HyperV puis le Gestionnaire de serveur de Windows Server 2008 R2 comme outil de gestion central pour toutes les tâches d’administration HyperV et Windows Server 2008 R2.

●

Utilisez SC Operations Manager 2007 pour mettre en œ uvre une politique de surveillance et d’analyse des performances proactives.

●

Maintenez les modèles de machines virtuelles à jour à l’aide de l’outil « Offline Virtual machine Servicing Tool ».

●

Utilisez comme stratégie de retour arrière les captures instantanées.

●

Appuyezvous sur des stratégies quotidiennes, hebdomadaires et mensuelles pour réaliser toutes les opérations d’administration de la plateforme HyperV.

La plupart de ces recommandations sont faciles à mettre en œ uvre. Cependant, le nonrespect de ces recommandations pourra affecter de manière significative la plateforme HyperV, tant du point de vue de sa performance globale que de sa capacité à assurer une surcharge ponctuelle.

- 2-

Machines virtuelles invitées Ce chapitre présente la gestion des machines virtuelles au sein de l’environnement HyperV. Cependant avant de présenter ces différentes opérations, nous allons rappeler les points les plus importants en termes de systèmes d’exploitation supportés par Microsoft, d’émulation de l’environnement matériel présenté aux systèmes d’exploitation invités et aussi de virtualisation de périphériques tels que les périphériques disques et périphériques réseaux virtuels.

1. Systèmes d’exploitation supportés La liste cidessous présente les différentes versions de systèmes d’exploitation de type clientserveur supportés par Microsoft : ●

Windows XP Professionnel 32 bits (SP2) pour un processeur virtuel au sein de la machine virtuelle.

●

Windows XP Professionnel 32 bits (SP3) pour un ou deux processeurs virtuels au sein de la machine virtuelle.

●

Windows XP Professionnel 64 bits (SP2) pour un ou deux processeurs virtuels au sein de la machine virtuelle.

●

Windows Vista Professionnel, Entreprise et Ultimate (SP1 et SP2) en versions 32 bits et 64 bits pour un ou deux processeurs virtuels au sein de la machine virtuelle.

●

Windows 7 en version 32 bits et 64 bits.

La liste cidessous présente les différentes versions de systèmes d’exploitation de type serveur supportés par Microsoft : ●

Windows 2000 Server (SP4) et Windows 2000 Advanced Server (SP4) pour un processeur virtuel au sein de la machine virtuelle.

●

Windows Server 2003 (SP2) Editions Standard, Entreprise ou Datacenter en version 32 bits et 64 bits pour un ou deux processeurs virtuels au sein de la machine virtuelle.

●

Windows Server 2003 R2 (SP2) Editions, Standard, Entreprise ou Datacenter en version 32 bits et 64 bits pour un ou deux processeurs virtuels au sein de la machine virtuelle.

●

Windows HPC Server 2008 pour un, deux ou quatre processeurs virtuels au sein de la machine virtuelle.

●

Windows Server 2008 Editions Web, Standard, Entreprise ou Datacenter en version 32 bits et 64 bits pour un, deux ou quatre processeurs virtuels au sein de la machine virtuelle. Il en de même pour les versions « sans HyperV ».

●

Windows Server 2008 R2 Editions Web, Standard, Entreprise ou Datacenter en version 32 bits et 64 bits pour un, deux ou quatre processeurs virtuels au sein de la machine virtuelle. Il en de même pour les versions « sans HyperV ».

●

Novell Suse Entreprise Server 10 (SP1 et SP2) et 11, en versions 32 bits et 64 bits pour un processeur virtuel au sein de la machine virtuelle.

Reposant sur le noyau Linux 2.6.27, la version 11 de Suse Linux Entreprise a été optimisée pour prendre en charge les environnements de virtualisation XEN, ESX et HyperV. La version Novell Suse ES supporte les platesformes de virtualisation KVM et XEN. Quoi qu’il en soit, il faut remarquer que cette dernière est largement privilégiée. En effet, la version XEN 3.3 intégrée à SLE 11 fait l’objet du partenariat signé en 2006 entre Novell et Microsoft, accords inclus via le « Server Virtualization Validation Program ». Microsoft optimise Windows Server 2008 R2 pour qu’il puisse être virtualisé via XEN tandis que Novell optimise SLE 11 pour qu’il puisse être virtualisé via Hyper V. Le même type d’accords a été conclu entre Microsoft et RedHat. Mais dans ce cas précis, le concurrent de Novell, pour les solutions de virtualisation basées sur Linux, a décidé de privilégier la technologie de virtualisation KVM.

- 1-

●

RedHat REHL 5.2 et 5.3 en versions 32 bits et 64 bits pour un processeur virtuel au sein de la machine virtuelle.

La liste des systèmes d’exploitation invités supportés par Microsoft en environnement HyperV est spécifiée dans le document de la base de connaissances Microsoft KB 954958 à l’adresse : http://support.microsoft.com/kb/954958 ou aussi via le lien http://www.microsoft.com/windowsserver2008/en/us/hypervsupportedguestos.aspx voir figure ci dessous. Pour plus d’informations sur le support des systèmes d’exploitation Microsoft sur d’autres platesformes de virtualisation, vous pouvez consulter le document de la base de connaissances Microsoft 897615 Support policy for Microsoft software running in nonMicrosoft hardware virtualization software, via le lien http://support.microsoft.com/kb/897615.

Accédez au site d’informations HyperV pour faire vos recherches

2. Environnement matériel des machines virtuelles Toutes les platesformes de virtualisation exposent aux machines virtuelles un ensemble de composants virtualisés. Ces composants peuvent être ou pas directement liés à la présence physique d’un périphérique matériel donné. Ces composants « virtuels » sont bien sûr détectés par les machines virtuelles et, de fait, apparaissent comme de réelles ressources physiques à cellesci. Exemple : HyperV travaille en relation étroite avec la partition parente, appelée aussi partition principale, pour translater les opérations issues de l’environnement virtuel vers le matériel via les pilotes de périphériques situés en ring 0 de la partition parente. Cette implémentation permet aux machines virtuelles d’utiliser des ressources matérielles « virtualisées » et à la couche de virtualisation HyperV située en ring 1 d’être totalement isolée des pilotes de périphériques s’exécutant en ring 0. Les composants matériels de la machine hôte HyperV sont virtualisés vers les machines virtuelles de la manière suivante : ●

- 2-

BIOS : BIOS AMI American Megatrends avec chipset Intel 440 BX et PIIXX4 ACPI. Le BIOS American Megatrends virtualisé par HyperV supporte les fonctions suivantes : ●

gestion de la mémoire CMOS,

●

support d’une horloge temps réel,

●

support de la mémoire RAM via son contrôleur mémoire associé,

●

support des DMA,

●

du bus PCI,

●

ISA et d’un bus SM System Monitoring,

●

pour accéder aux fonctions de surveillance de certains composants comme les sondes de température,

●

support des fonctions d’économie d’énergie,

●

support du contrôleur d’interruptions programmable 8259.

●

Processeur : de un à quatre processeurs du même type que la machine hôte HyperV.

●

Mémoire RAM : jusqu’à 32 Go de RAM par machine virtuelle pour les machines hôtes fonctionnant sous Windows Server 2008 R2 Editions Standard et sous HyperV Server 2008. Jusqu’à 64 Go de RAM par machine virtuelle pour les machines hôtes fonctionnant sous Windows Server 2008 R2 Editions Entreprise et Datacenter.

●

Carte Vidéo : émulation d’une carte graphique type VESA avec 4 Mo de VRAM. Support VGA et SVGA compatible avec la norme VESA 1.2, l’accélération 2D et le support de DirectX.

●

Stockage IDE/ATAPI : support de deux canaux IDE, chaque canal pouvant prendre en charge deux périphériques de types disques durs, lecteurs CD/DVD et aussi images ISO.

Attention ! Avec HyperV, une machine virtuelle ne peut démarrer qu’à partir d’un disque virtuel connecté via l’interface IDE. Lorsqu’une machine virtuelle est créée, elle dispose d’une interface IDE primaire et d’une interface IDE secondaire. Chaque interface IDE peut supporter deux périphériques, soit quatre périphériques au total par machine virtuelle. Par défaut, le premier disque dur est connecté sur le port 0 du contrôleur IDE 0 et le premier lecteur de CD/DVD est connecté sur le port 0 du contrôleur IDE 1.

●

Stockage SCSI : jusqu’à quatre contrôleurs SCSI synthétiques, chaque contrôleur pouvant supporter jusqu’à 64 disques durs. Les machines virtuelles disposent d’une émulation IDE intégrée tandis que l’interface virtuelle SCSI nécessite l’ajout des composants d’intégration. Une fois les composants installés au sein du système d’exploitation invité, la machine virtuelle supporte quatre contrôleurs SCSI synthétiques, chacun pouvant prendre en charge jusqu’à 64 périphériques, soit 256 périphériques SCSI par machine virtuelle.

Attention aux problèmes de boot ! Les composants d’intégration étant chargés après le démarrage du système d’exploitation invité, les fichiers de disques virtuels attachés à un contrôleur SCSI synthétique ne peuvent être utilisés pour l’amorçage du système.

Une machine virtuelle peut aussi accéder aux ressources disques iSCSI via un l’initiateur iSCSI Microsoft, ou autre. Cependant, le système d’exploitation ne peut être initialisé de cette façon, la connectivité iSCSI n’étant opérationnelle qu’après le chargement du système d’exploitation. Notez que dans le cas de l’utilisation de iSCSI, il est fortement recommandé d’utiliser une carte réseau dédiée au niveau de la machine parent HyperV.

- 3-

Propriétés de l’Initiateur iSCSI intégré à Windows Server 2008 R2

●

Lecteur de disquettes : un lecteur de disquettes type 1.44 Mo mappé vers une image de type fichier .VFD (Virtual Floppy Disk). Les fichiers .vfd peuvent être créés à l’aide du menu Actions Nouveau Disquette de la console MMC Gestionnaire HyperV ou à l’aide d’un logiciel tiers (Winimage, etc.)

●

Ports série (COM) : deux ports série sont connectables via des canaux nommés.

●

Port impression (LPT) : non supporté.

●

Carte son : non supporté.

●

Port souris : souris PS/2 Microsoft IntelliMouse.

●

Clavier : clavier standard PS/2 Microsoft.

●

Cartes réseau : jusqu’à quatre cartes Ethernet Multiport DEC/Intel 21140.

L’installation des composants d’intégration HyperV au sein des machines virtuelles Windows ou Linux, permet la prise en charge de la paravirtualisation. Dans ce cas, les éléments suivants sont implémentés en lieu et place des périphériques émulés présentés plus haut : périphérique de souris synthétique, périphérique de clavier synthétique, jusqu’à huit cartes réseaux synthétiques à 10 Gbits, carte vidéo synthétique. Notez que les systèmes d’exploitation invités ou les applications qui devraient accéder directement au matériel ne peuvent fonctionner en tant que machines virtuelles. À cause des mêmes types de contraintes liées au matériel, les applications spécifiques bases de données SQL, etc., qui prennent en charge le traitement multiprocesseur symétrique ne peuvent « voir » qu’un, deux ou quatre processeurs virtuels au sein d’une machine virtuelle.

3. Disques durs virtuels - 4-

La mise en œ uvre de chaque machine virtuelle implique de déterminer quel type de stockage disque sera implémenté. Il faudra donc déterminer si les disques présentés à une machine virtuelle donnée sont des disques physiques virtuels. Les disques virtuels, fichiers .VHD, existent depuis la première version de Microsoft Virtual PC 2004 et ont évolué avec Microsoft Virtual Server 2005 R2, Virtual PC 2007 et maintenant avec HyperV, ce dernier supportant des fichiers VHD pouvant atteindre une capacité de 2040 Go, soit 2 To. Les disques durs virtuels pris en charge par HyperV permettent d’atteindre une capacité maximum de stockage de 512 To par machine virtuelle. Nous verrons plus loin qu’il est aussi possible d’attacher au sein des machines virtuelles des disques durs physiques appartenant à la machine hôte HyperV. Dans ce cas, il n’existe plus aucune limite de taille de disque pour la machine virtuelle. Plusieurs types de disques virtuels existent et sont facilement gérés à l’aide de la console de gestion Gestionnaire HyperV.

Assistant Nouveau disque dur virtuel de la console Gestionnaire Hyper V Il est aussi possible d’invoquer via PowerShell, l’interface WMI. De cette manière, il est possible d’accéder à toutes les opérations de gestion des disques virtuels. Dans l’exemple cidessous, la première commande retrouve un objet WMI pour Msvm_ImageManagementService, tandis que la deuxième commande exécute la méthode CreateDynamicVirtualHardDisk pour créer un nouveau disque dur virtuel de taille dynamique de 75 Go.

Création d’un disque virtuel dynamique via PowerShell et l’interface WMI

- 5-

Le code de retour 4096 signifie que la méthode utilisée a été exécutée en tâche de fond en mode asynchrone. Du point de vue de la machine virtuelle, un disque dur virtuel est vu comme un disque dur physique tandis que, côté HyperV, il ne s’agira que d’un simple fichier se terminant par l’extension .VHD. Cependant, il faut faire remarquer que les machines virtuelles accèdent aux disques via des interfaces normalisées telles qu’IDE ou SCSI, HyperV prenant à sa charge la translation nécessaire. Attention ! Dans le cas d’un disque VHD connecté via une interface IDE, la taille maximum sera de 127 Go, tandis que dans le cas d’un disque VHD connecté via une interface SCSI, la taille maximum sera de 2040 Go, soit 2 To. Les différents types de disques sont présentés cidessous : ●

Les disques virtuels de taille FIXE : un disque virtuel de taille fixe utilise la quantité spécifiée comme taille de disque et ce, quelle que soit la quantité de données enregistrées sur le disque dur virtuel. Un disque virtuel de taille fixe de 75 Go consomme donc 75 Go sur le disque dur de la machine hôte sur lequel il a été créé.

L’inconvénient notable d’un disque dur de taille fixe est que le temps nécessaire à sa création sera considérablement plus long qu’un autre type de disque. Par contre, un avantage important concernera les performances car l’espace de données utilisé sera une suite de blocs contigus. ●

Les disques durs virtuels à extension dynamique : un disque dur à extension dynamique est un disque virtuel dont la taille augmente au fur et à mesure que des données sont écrites au sein du disque. Bien sûr, ces disques offrent l’énorme avantage d’être créés et disponibles instantanément quelle que soit leur taille.

Ces disques doivent faire l’objet d’une surveillance de l’espace disponible sur le disque de la machine hôte pour éviter un problème de stockage au sein de ou des machine(s) virtuelle(s). De même, ces disques peuvent être convertis en disques durs de taille fixe à l’aide du menu Actions Modifier le disque de la console de gestion Gestionnaire HyperV. L’opération inverse peut aussi être réalisée. Pour diminuer la taille d’un disque de type dynamique qui aurait à un moment donné dû grossir de manière importante, il est possible de réaliser une opération de compactage. Cette opération est réalisée à l’aide du menu Actions Modifier le disque Compacter. Cette option déclenchera la réduction de la taille du fichier en supprimant l’espace libre restant après suppression de données du disque à extension dynamique.

Actions disponibles : compactage, conversion et extension d’un disque dur virtuel

- 6-

●

Les disques durs virtuels de différenciation : un disque dur virtuel de différenciation stocke uniquement les données de différence par rapport à un disque dur virtuel de départ. Ce type de disque offre l’avantage d’isoler les changements réalisés sur une machine virtuelle en partant du principe que le disque de départ pourra être partagé entre n machines virtuelles et devra être marqué en lecture seule.

●

Les disques durs virtuels liés : ce type de disque est lié à une opération particulière consistant à copier le contenu d’un disque physique spécifié vers un disque virtuel. Cette opération sera intéressante pour réaliser une migration de données d’un disque dur physique vers un disque dur virtuel.

Pour obtenir plus d’informations sur les spécifications des disques durs virtuels, vous pouvez vous référer au lien cidessous : http://www.microsoft.com/windowsserversystem/virtualserver/techinfo/vhdspec.mspx

Création d’un nouveau disque virtuel et copie des données du disque physique spécifié

●

Les disques durs physiques, en anglais PassThrough Disks : les disques durs physiques pris en charge par les machines hôtes HyperV peuvent être directement attachés aux machines virtuelles. Il est ainsi possible d’associer à une machine virtuelle un disque physiquement connecté et vu par HyperV ou bien directement présenté par le SAN sous la forme d’une LUN. Le plus grand avantage des disques durs physiques est qu’ils ne dépendent pas des spécifications des disques virtuels VHD, en particulier concernant la limite de taille de 2 To.

Attention ! Malheureusement, les disques durs physiques ne tirent pas profit des fonctionnalités avancées des fichiers VHD telles que les extensions dynamiques, les disques de différenciation ou les captures instantanées supportées par HyperV.

4. Réseaux virtuels HyperV supporte trois types de réseaux virtuels capables de répondre à trois types de problématiques : externe, privé et interne.

- 7-

Menu Actions Gestionnaire de réseau virtuel.

Création de différents types de réseaux virtuels

●

Un réseau virtuel externe crée une connexion à une véritable carte réseau physique de telle sorte que les machines virtuelles connectées au réseau virtuel puissent accéder au réseau physique.

Lorsqu’un nouveau réseau virtuel externe est créé à l’aide de la console MMC Gestionnaire HyperV, une nouvelle carte réseau, configurée avec les liaisons par défaut, est créée dans la partition parent HyperV. Celleci est ensuite connectée vers un nouveau réseau virtuel, luimême associé à une carte réseau physiquement présente dans la machine. ●

- 8-

Un réseau virtuel interne permet aux machines virtuelles connectées sur ce réseau de communiquer entre elles et avec la machine hôte HyperV, sans pour autant avoir accès à aucun réseau physique. Comme pour un réseau virtuel externe, un réseau virtuel interne nécessite, au sein de la partition parente, la création d’une carte réseau virtuelle, d’un switch virtuel et d’un port associé.

●

Un réseau virtuel privé permet aux machines virtuelles connectées sur ce réseau de communiquer entre elles mais en aucune façon avec la machine hôte HyperV, ni avec aucune machine connectée sur un réseau physique externe.

L’association des cartes réseau physiques est réalisée au niveau d’un objet de type Réseau virtuel externe. La carte physique existant au sein de la partition parente ne disposera d’aucune liaison de protocoles excepté celle prenant en charge les commutateurs virtuels, c’estàdire le protocole appelé « Protocole de commutation réseau virtuelle ».

Connexions réseaux HyperV : une connexion est associée à un réseau virtuel

- 9-

Détails des liaisons sur les connexions réseau et les réseaux virtuels Un réseau virtuel est implémenté sous la forme d’une émulation d’un commutateur logiciel de niveau 2 possédant un nombre illimité de ports commutés à 10 Gbits. Ce commutateur peut être accroché, ou non, à une carte réseau physique prise en charge par la machine hôte HyperV au travers de la partition parente. Dans le cas où aucune carte réseau n’y est associée, le réseau est alors virtuellement isolé du ou des réseau(x) interne(s). HyperV supporte un nombre illimité de commutateurs virtuels disposant à leur tour d’un nombre illimité de ports. Enfin, chaque réseau virtuel créé à l’aide de la console de gestion Gestionnaire HyperV, créera automatiquement le commutateur virtuel associé au sein de la partition parente. Chaque nouvelle machine virtuelle connectée sur un réseau virtuel donné donne lieu à la création d’un nouveau port réseau au sein du commutateur virtuel.

- 10 -

Architecture réseau d’HyperV La figure cidessus illustre l’architecture réseau implémentée sur une machine hôte HyperV, avec les composants de la partition parente, des partitions enfants ainsi que le VM BUS autorisant des transferts de données entre les machines virtuelles, les commutateurs virtuels et les interfaces réseaux contrôlées au sein de la partition parente.

- 11 -

Opérations de gestion des machines virtuelles Toutes les opérations de gestion des machines virtuelles sont prises en charge par la console de gestion MMC Gestionnaire HyperV, laquelle est automatiquement installée lors de l’ajout du rôle HyperV, lors d’une installation complète de Windows Server 2008 R2 Edition Standard, Entreprise ou Datacenter. En effet, nous avons vu précédemment qu’avec une installation minimale de Windows Server 2008, il était nécessaire d’installer la console de gestion Gestionnaire HyperV sur une station d’administration fonctionnant sous Windows Vista. Disponible via le menu Démarrer Outils d’administration, la console peut aussi être lancée via la commande C:\Program Files\HyperV\VirtMgmt.msc en passant par l’invite de commande ou via le menu Démarrer Exécuter. La console de gestion Gestionnaire HyperV permet à un administrateur de prendre en charge de multiples machines hôtes HyperV dans le cadre de configurations dont le nombre de machines hôtes et le nombre de machines virtuelles est limité. Bien qu’il n’y ait pas de limitations techniques particulières avec la console de gestion Gestionnaire HyperV, la gestion avancée des machines virtuelles, des machines hôtes HyperV et des fonctionnalités de haute disponibilité nécessite l’utilisation de System Center Virtual Machine Manager 2008. L’administration SCVMM 2008 est traitée au chapitre Gestion de la virtualisation avec System Center VMM 2008. La console de gestion Gestionnaire HyperV supporte totalement l’administration à distance. Il est ainsi très simple de se connecter sur d’autres serveurs HyperV et de passer de l’un à l’autre en un simple clic de souris.

Sélection d’une machine hôte HyperV à l’aide de la console MMC Gestionnaire Hyper V. Une fois un serveur HyperV installé et opérationnel, l’utilisation de la console MMC et des nouveaux assistants associés permettra à l’administrateur de réaliser les opérations cidessous : ●

La création de machines virtuelles,

●

La suppression de machines virtuelles,

●

L’exportation d’une machine virtuelle,

●

L’importation d’une machine virtuelle,

●

La configuration des paramètres de détail d’une machine virtuelle.

1. Création des machines virtuelles La création d’une machine virtuelle est une opération très simple à réaliser au sein de l’environnement HyperV.

- 1-

Utilisation de la console Gestionnaire Hyper V pour créer une machine virtuelle La figure cidessus montre le menu Nouveau Ordinateur virtuel accessible via la zone Actions.

Vue de l’Assistant Nouvel ordinateur virtuel L’assistant récupère les informations importantes qui caractérisent la machine virtuelle telles que le nom de la machine virtuelle, l’emplacement de stockage des fichiers de configuration et des captures instantanées, la mémoire RAM dynamique affectée et les paramètres de disques virtuels. Concernant les disques, l’assistant propose à l’administrateur de créer un nouveau disque virtuel, d’utiliser un disque existant ou de déclarer ce paramètre indispensable ultérieurement.

- 2-

La dernière option de l’assistant permet à l’administrateur de spécifier les options d’installation du système d’exploitation invité. L’opération peut être réalisée ultérieurement ou immédiatement en démarrant la machine virtuelle. Dans ce cas, le système d’exploitation invité peut être installé via : ●

le lecteur de CD/DVD physique,

●

une image ISO contenant la distribution du système d’exploitation à installer,

●

l’image d’une disquette virtuelle,

●

un démarrage réseau de type PXE pour accrocher un serveur d’installation de type WDS (Windows Deployment Services).

Utilisation d’une image ISO pour installer le système d’exploitation invité La validation de l’assistant est réalisée via le bouton Terminer. L’assistant crée alors le fichier de configuration de la machine virtuelle, composé du GUID de la machine virtuelle et de l’extension .xml, et la nouvelle machine virtuelle est affichée au sein de la console MMC Gestionnaire HyperV.

2. État des machines virtuelles L’état des machines virtuelles est contrôlé par l’administrateur à l’aide de la console de gestion Gestionnaire HyperV. Les différentes options sont sélectionnables via le menu Actions ou bien en faisant un clic droit sur une machine virtuelle à l’aide de la souris. Les états pris en charge via la console sont les suivants : ●

Démarrer : cette action permet d’alimenter la machine virtuelle et de la démarrer.

●

Éteindre : cette action coupe électriquement la machine virtuelle. Dans ce cas, la machine virtuelle est « violemment » stoppée.

●

Arrêter : cette action permet de contrôler l’arrêt de la machine virtuelle lorsque les services d’intégration sont installés. Un arrêt propre du système est réalisé puis la machine virtuelle s’éteint.

- 3-

●

Enregistrer : cette action permet d’arrêter le fonctionnement de la machine virtuelle sans pour autant déclencher un arrêt du système. L’état de la mémoire et du ou des processeur(s) sont sauvegardés dans un fichier. La machine est donc gelée, ses ressources sont désengagées, donc disponibles pour une autre machine virtuelle.

●

Suspendre : cette action permet de suspendre tous les traitements CPU de la machine virtuelle. La machine est donc gelée, ses ressources CPU sont désengagées, donc disponibles pour une autre machine virtuelle.

●

Reprendre : cette action permet de reprendre tous les traitements CPU de la machine virtuelle qui avait fait l’objet d’une action de type Suspendre.

●

Réinitialiser : cette action permet de complètement réinitialiser la machine virtuelle. L’arrêt n’est pas du tout contrôlé et la machine redémarre instantanément pour réaliser un chargement complet.

Utilisation du menu contextuel ou de la zone Actions, sur la droite

3. Gestion de la configuration des machines virtuelles La configuration des machines virtuelles est une opération que l’administrateur HyperV peut réaliser à l’aide de la console de gestion Gestionnaire HyperV. À l’aide de la souris en faisant un clic droit sur la machine virtuelle devant être gérée, il suffit de cliquer sur l’option Paramètres. La gestion de la configuration des machines virtuelle peut prendre en charge les évolutions nécessaires telles que l’ajout de mémoire RAM, d’une carte réseau supplémentaire, de disques ou de contrôleurs de disques.

- 4-

Paramètres d’une machine virtuelle Le tableau cidessous liste les différentes options de configuration matérielle d’une machine virtuelle, les opérations autorisées en cours de fonctionnement et les restrictions les plus notables. Paramètres matériels

Description et remarques

Ajouter un matériel Permet l’ajout de contrôleurs synthétiques de type SCSI et réseau. Permet l’ajout de cartes réseau émulées. BIOS

Permet la gestion du verrouillage numérique. Permet de gérer l’ordre de démarrage des périphériques tels que les CD/DVD, disques IDE, carte réseau héritée, lecteur de disquette.

Mémoire

Permet de spécifier la taille de mémoire RAM dynamique à allouer à la machine virtuelle lors du prochain redémarrage.

Processeur

Permet de spécifier l’allocation de temps CPU, le contrôle des ressources et les fonctionnalités du processeur.

Contrôleur IDE 0

Permet l’ajout de disques durs virtuels ou de lecteurs de CD/DVD attachés au contrôleur IDE 0.

Disque dur

Permet de gérer la position du disque sur le contrôleur associé. Permet aussi l’accès aux fonctions de disques HyperV Compacter Convertir Etendre … Permet d’ajouter et de supprimer des disques. © ENI Editions - All rigths reserved

- 5-

Contrôleur IDE 1

Permet l’ajout de disques dur virtuels ou de lecteurs de CD/DVD attachés au contrôleur IDE 1.

CD/DVD

Permet la prise en charge des lecteurs de CD/DVD. Permet d’utiliser une image ISO à la place du lecteur de CD/DVD. Permet aussi de supprimer les lecteurs de CD/DVD.

Contrôleur SCSI

Permet l’ajout de disques durs virtuels à un contrôleur SCSI.

Carte réseau

Permet l’ajout, la suppression et la configuration de cartes réseau synthétiques. Possibilité de spécifier la connexion réseau virtuel associée et la gestion de l’adresse MAC de la carte réseau.

Carte réseau héritée Une carte réseau héritée fonctionne sans installation d’un pilote virtuel. Ce type de carte émule une carte physique type DEC 21140 10/100TX multiport. Attention au fait qu’une carte réseau héritée prend également en charge le boot PXE (PreExecution Environment). Il est recommandé ce type de carte réseau seulement lors d’une installation via le réseau ou lorsque le système d’exploitation invité ne prend pas en charge le pilote de carte réseau synthétique. COM 1 & COM 2

Permet de déclarer un ou 2 ports COM virtuels attachés à un canal nommé (named pipe). Attention au fait qu’il n’est pas possible d’associer le port COM virtuel à un port COM physique.

Lecteur de disquettes

Permet de déclarer un lecteur de disquettes à une machine virtuelle. Attention au fait qu’il n’est pas possible d’associer le lecteur de disquettes virtuel à un lecteur de disquettes physique.

Le tableau cidessous décrit les paramètres de la rubrique Gestion de la fenêtre Paramètres pour une machine virtuelle. Paramètres de gestion

Description et remarques

Nom

Permet de nommer la machine virtuelle.

Services d’intégration

Permet de configurer les services HyperV qui seront offerts à la machine virtuelle. Il pourra s’agir de la prise en charge de l’arrêt, de la synchronisation horaire, de l’échange de données, de la pulsation et du support des captures instantanées de la machine virtuelle.

Emplacement du fichier de capture instantanée

Permet de spécifier le dossier à utiliser pour stocker les fichiers de captures instantanées.

Action de démarrage automatique

Permet de contrôler l’action à réaliser lorsque la machine hôte HyperV est redémarrée.

Action d’arrêt automatique

Permet de contrôler l’action à réaliser lorsque la machine hôte HyperV est arrêtée.

4. Capture instantanée des machines virtuelles a. Introduction Cette fonctionnalité est l’une des plus remarquables offerte aux administrateurs des machines virtuelles HyperV ! Elle permet de capturer les données, la configuration matérielle et l’état d’une machine virtuelle donnée. Une fois une ou plusieurs capture(s) réalisée(s), il est possible d’exécuter la machine virtuelle à la position de n’importe quelle capture instantanée, et ce, sans aucune interruption de service. Pour cette raison, la capture instantanée des machines virtuelles est une grande fonctionnalité qui peut principalement être utilisée dans les environnements de développement ou de tests. La capacité à rétablir l’état

- 6-

d’une machine virtuelle à telle ou telle position dans le temps peut être extrêmement précieuse pour les contrôles et le dépannage. Bien entendu, les captures instantanées peuvent être utilisées avec les machines virtuelles incluses dans les environnements de production. La possibilité d’utiliser les captures instantanées pour rétablir instantanément l’état d’une machine virtuelle critique à son état précédent sera une alternative qui rendra de grands services à la majorité des équipes de support. Cela pourra être le cas lors du passage des mises à jour de sécurité, des correctifs Windows ou des services packs d’applications critiques.

b. Gestion des captures instantanées Plusieurs méthodes peuvent être invoquées pour créer une capture instantanée d’une machine virtuelle : ●

À l’aide de la console de gestion Gestionnaire HyperV.

●

À l’aide de l’outil Connexion à un ordinateur virtuel Vmconnect.exe disponible dans le dossier C:\Programmes\HyperV, puis via le menu Action Capture instantané, et aussi via l’interface PowerShell et WMI.

Pour créer une capture instantanée d’une machine virtuelle à l’aide de la console de gestion Gestionnaire HyperV, il suffit, à l’aide de la souris d’appeler le choix Capture instantanée.

Choix de l’option Capture instantanée à l’aide de la console Gestionnaire Hyper V La figure cidessus montre l’exécution d’une capture instantanée sur la machine virtuelle SCOM01 alors que celleci est en cours de fonctionnement. La capture est directement réalisée dès que l’option est sélectionnée à l’aide de la souris. Lorsqu’une ou plusieurs capture(s) instantanée(s) est (sont) réalisée(s), l’interface graphique montre dans la partie centrale de la console de gestion une structure arborescente correspondant à la structure hiérarchique des captures instantanées de la machine virtuelle. Ainsi, la racine de l’arbre est représentée par la première capture instantanée réalisée, reprenant par défaut le nom de la machine virtuelle associé à la date et l’heure de sa création.

- 7-

Exécution de la capture instantanée en cours de fonctionnement Une fois une ou plusieurs capture(s) instantanée(s) réalisée(s), l’interface de gestion permet à l’administrateur de gérer les différentes captures. La figure cidessous illustre les différentes options offertes à l’administrateur.

Choix des opérations réalisables sur les captures instantanées

- 8-

●

L’option Paramètres permet d’ouvrir la fenêtre Paramètres de la machine virtuelle et d’accéder ainsi aux propriétés relatives aux captures instantanées.

●

L’option Appliquer permet d’appliquer l’état d’une capture instantanée à la machine virtuelle en cours de fonctionnement, mais aussi lorsque celleci est arrêtée.

●

L’option Renommer permet de nommer chaque capture plus précisément qu’avec les valeurs par défaut composées de la date et de l’heure.

●

L’option Supprimer la capture instantanée permet de détruire la capture sélectionnée et de récupérer

l’espace disque qui lui était associé. ●

L’option Supprimer la sousarborescence de la capture instantanée permet de détruire la capture sélectionnée et toutes les captures ayant été réalisées après celleci. Cette possibilité est très pratique pour supprimer en une seule fois plusieurs captures et ainsi récupérer l’espace disque associé.

Disponibilité de deux captures instantanées (13/02/2009 et 04/05/2009) La figure cidessous illustre l’opération de sélection d’une capture instantanée pour l’appliquer à la machine virtuelle.

Option Appliquer disponible dans la console Gestionnaire Hyper V La sélection de cette option démarre la mise en production de la capture instantanée sélectionnée au sein de la machine virtuelle. Dans la figure cidessus, la machine virtuelle n’est pas en cours de fonctionnement. Ce choix n’est pas du tout obligatoire puisque les captures instantanées peuvent être créées et appliquées sans aucune incidence sur les machines virtuelles en cours de fonctionnement. La possibilité de le faire sur une machine virtuelle arrêtée permet à l’administrateur de démarrer une machine virtuelle en fonction d’un certain état. Cela peut être très utile pour des machines virtuelles de tests. Par exemple, plutôt que de disposer de n machines de tests chacune avec son propre

- 9-

niveau de Service Pack, il pourrait être suffisant de disposer d’une seule machine virtuelle assortie de plusieurs captures instantanées, chaque capture correspondant à une version particulière du système. L’un des avantages de cette méthode est que lors de l’activation de la machine virtuelle, celleci est directement disponible sans passer par la phase de démarrage habituelle ! La figure suivante montre une fenêtre de confirmation jouant le rôle de dernier avertissement. Elle recommande à l’administrateur de prendre d’abord une nouvelle capture instantanée avant d’appliquer celle qui était précédemment sélectionnée. Ce choix doit être utilisé le plus souvent pour garantir un retour en avant facilité, si cela s’avère nécessaire.

Confirmation de l’application d’une capture instantanée Une fois la capture instantanée appliquée, la machine est opérationnelle sans aucune interruption de service et la position de l’icône Maintenant est mise à jour au sein de l’interface.

Affichage de la capture instantanée en production Afin d’annuler toute erreur de manipulation dramatique dans le cas où de multiples changements auraient été réalisés, il sera facilement possible de récupérer l’état de la capture instantanée précédente. Pour y parvenir, vous pourrez utiliser l’option Rétablir disponible via le menu contextuel de la machine virtuelle. Ainsi, la configuration et l’état de la machine virtuelle seront repositionnés en fonction des données de la capture précédente.

- 10 -

Utilisation de l’option Rétablir

c. Suppression des captures instantanées En général, le type d’usage qui est fait des captures instantanées ne nécessite pas de les conserver pendant des mois ou des années. L’interface de gestion Gestionnaire HyperV permet donc de détruire les captures instantanées et les données qui y sont associées aussi facilement que de les créer.

Suppression d’une sousarborescence de captures instantanées Deux choix sont proposés à l’administrateur : le premier permet de supprimer n’importe quelle capture de la hiérarchie sans interférer avec les autres, tandis que le deuxième lui permet de supprimer tout ou partie de l’arborescence des captures instantanées de la machine virtuelle. Attention : lorsque les données de captures instantanées sont supprimées par l’administrateur, les fichiers .avhd contenant les données utilisées par les captures demeurent à l’emplacement de stockage de cellesci. Les données seront réellement supprimées lorsque la machine virtuelle sera arrêtée ou positionnée dans l’état Sauvegardé. L’espace précédemment occupé ne sera donc réellement récupéré qu’après cette étape. Attention au fait qu’en fonction du nombre de captures et de la taille de chaque capture, l’opération de récupération de l’espace disque peut être longue.

d. Stockage des captures instantanées

- 11 -

L’emplacement du stockage des captures instantanées est directement affichable au niveau de chaque capture instantanée.

Affichage de l’emplacement des captures instantanées d’une machine virtuelle donnée HyperV utilise deux dossiers importants comme emplacements de stockage : ●

Les fichiers VHD utilisés par les disques durs virtuels sont par défaut stockés dans le dossier suivant : C:\Users\Public\Documents\Microsoft HyperV\Virtual Hard Disks.

●

Les fichiers de données et de configuration liés aux captures instantanées sont stockés dans le dossier suivant : C:\ProgramData\Microsoft\Windows\HyperV.

L’emplacement de ces deux dossiers peut facilement être modifié à l’aide de la console de gestion Gestionnaire HyperV, mais l’administrateur a aussi la possibilité de contrôler l’emplacement des fichiers de disques virtuels et celui des données de captures instantanées, au dernier moment, lors de la création de la machine virtuelle.

- 12 -

Paramètres Hyper V : changement de l’emplacement des captures instantanées L’emplacement par défaut est configurable à l’aide de la console de gestion Gestionnaire HyperV au niveau de l’option Paramètres HyperV.

- 13 -

Emplacement des captures instantanées via l’Assistant Nouvel ordinateur virtuel La figure cidessous illustre la structure des dossiers utilisée par les captures instantanées de la machine virtuelle nommée Win2KAS Win2K01, sachant que dans ce cas, le répertoire par défaut a été modifié pour utiliser le dossier C:\VM.Data.

Structure du dossier contenant les captures instantanées d’une machine virtuelle

e. Fichiers de disques durs virtuels VHD et de captures instantanées AVHD Une capture instantanée correspond à un point d’arrêt où l’état de la machine virtuelle est enregistré dans un fichier de type AVHD. Ce type de fichier peut être considéré comme un fichier de différenciation spécialisé pour les captures instantanées. Le fichier représentant ce contexte est ensuite lié vers le fichier VHD de départ. Une fois qu’une capture instantanée est réalisée, le fichier VHD de départ n’est plus jamais modifié.

f. Fusion automatique des captures instantanées Bien sûr, lorsque des captures instantanées sont supprimées, les données relatives à ces captures sont fusionnées dans la dernière capture instantanée. Ces opérations peuvent avoir lieu en tâche de fond pendant le fonctionnement de la machine virtuelle.

- 14 -

Enfin, pour récupérer un fichier VHD contenant toutes les données de toutes les captures instantanées, chaque capture devra être supprimée à l’aide de la console de gestion Gestionnaire HyperV. La fusion des différents fichiers sera ensuite automatiquement réalisée juste après l’arrêt de la machine virtuelle.

Suppression de la totalité des captures instantanées d’une machine virtuelle

Fusion des AVHD au sein du VHD original lors de l’arrêt de la machine virtuelle

g. Fusion manuelle des captures instantanées en un seul fichier VHD Le fait qu’une machine virtuelle possède des captures instantanées signifie que le disque dur virtuel, ayant l’extension .VHD, sera accompagné d’autant de fichier ayant l’extension .AVHD que de captures instantanées. Par voie de conséquence, l’utilisation du seul fichier VHD sur une machine virtuelle nouvellement créée fonctionnera mais pas avec la version la plus récente de l’état de la machine virtuelle. Pour disposer, à nouveau, d’un disque dur virtuel composé d’un seul et unique fichier VHD, il sera nécessaire de fusionner manuellement toutes les captures instantanées au sein du fichier original. Les fichiers AVHD sont des disques de différenciation contenant un chemin absolu et un chemin relatif vers le disque parent. Ces pointeurs sont utilisés lorsqu’une opération de fusion est réalisée. Attention, l’opération de fusion modifie le fichier parent original.

- 15 -

La procédure cidessous vous permettra de réaliser cette opération : ■

À partir de la machine hôte HyperV, arrêtez la machine virtuelle originale.

■

Copiez le fichier VHD et les fichiers AVHD correspondant aux différentes captures instantanées.

■

Renommez les fichiers ayant l’extension AVHD en VHD.

■

Repérez l’ordre des fichiers VHD du plus ancien au plus récent, le plus ancien étant le VHD original de départ. Cette opération peut être réalisée en contrôlant la date de la dernière modification sur les fichiers originaux AVHD.

■

Finalement, à l’aide de la console de gestion Gestionnaire HyperV, lancez l’Assistant Modification de disque dur virtuel via le menu Actions Modifier le disque.

■

Sélectionnez le fichier VHD utilisé pour les captures instantanées le plus ancien et cliquez sur le bouton Reconnecter.

■

Sélectionnez le fichier VHD parent de départ.

■

Choisissez l’option Reconnecter. L’opération de fusion commence.

■

Recommencez le processus jusqu’au dernier fichier à intégrer.

■

Une fois tous les fichiers de différenciation intégrés au sein du fichier VHD, vous pouvez créer une nouvelle machine virtuelle qui utilisera le fichier VHD fusionné.

Cette procédure, certes pénible, fonctionne sans problème. La partie la plus délicate concerne le repérage de l’ordre des différents fichiers AVHD au sein de la chaîne de disques différentiels. En plus de la dernière date de modification de chaque fichier, une autre méthode pourra consister à analyser le fichier de configuration de la machine virtuelle.

h. Captures instantanées via PowerShell et WMI HyperV intègre de nombreuses classes WMI. Ces classes permettent de consulter et de manipuler tous les aspects de la plateforme de virtualisation HyperV et des machines virtuelles qui y sont hébergées. L’usage de PowerShell combiné aux classes de virtualisation WMI permet de développer de puissants scripts de gestion des environnements virtualisés. Il est ainsi possible de créer des scripts de maintenance automatique des machines virtuelles et de la machine HyperV ellemême. Au sein de l’espace de noms \\.\Root\Virtualization, utilisé par le fournisseur WMI HyperV, résident des centaines de fonctions invocables. Parmi toutes ces possibilités, voici les quatre objets principaux : ●

ComputerSystem : utilisé pour la représentation des machines virtuelles et machines hôtes.

●

VirtualSystemSettingData : utilisé pour manipuler les options des machines virtuelles.

●

ResourceAllocationSettingData : utilisé pour l’attribution des ressources.

●

VirtualSystemManagementService : utilisé pour accéder aux méthodes de manipulation des objets.

La liste complète des classes WMI de l’espace « Root\Virtualization » est affichable sur une machine disposant du rôle HyperV en tapant la commande suivante au sein de l’invite de commande Windows PowerShell : getwmiobject namespace root\virtualization list. Toujours à l’aide de PowerShell et de l’invocation des classes WMI, il est possible de créer un script basé sur les commandes cidessous. Ces différentes opérations permettent de créer une capture instantanée d’une machine virtuelle. ■

- 16 -

Création d’une variable de connexion au fournisseur WMI.

$VSMS = getwmiobject namespace root\virtualization class Msvm_VirtualSystemManagementService ■

Création d’une variable de connexion à la machine virtuelle VM01. $CS = getwmiobject namespace root\virtualization class Msvm_ComputerSystem filter " ElementName = ’VM01’ "

■

Étape finale de création de la capture instantanée. $VSMS.CreateVirtualSystemSnapShot($CS.__PATH)

De nombreuses autres fonctions sont disponibles telles que celles qui permettent de supprimer ou d’appliquer une capture instantanée via les méthodes RemoveVirtualSystemSnapShot et ApplyVirtualSystemSnapshot. L’étape finale à la mise en place d’un tel script sera de créer une tâche planifiée qui pourra être déclenchée régulièrement ou lors d’un évènement particulier.

i. Points importants ! 1. Les captures instantanées peuvent être réalisées lorsque la machine virtuelle est en cours de fonctionnement, dans l’état Arrêté ou dans l’état Enregistré. 2. Lorsque les captures instantanées concernent une machine virtuelle hautement disponible, c’estàdire configurée avec la fonctionnalité Quick Migration ou Live Migration et les services de cluster à basculement de Windows Server 2008 R2 Edition Entreprise ou Datacenter, toutes les ressources associées à chaque capture instantanée doivent être stockées sur le même stockage SAN que la machine virtuelle. 3. L’utilisation des captures instantanées peut introduire une consommation importante de l’espace disque utilisé par la machine virtuelle et aussi une baisse des performances de celleci. 4. Il n’est pas judicieux de considérer les captures instantanées comme une alternative aux sauvegardes. En effet, les captures instantanées n’utilisent pas les composants VSS utilisés par Windows et par les applications Windows. Bien que les captures instantanées soient pratiques et utilisables dans de nombreux cas, un certain nombre de risques demeurent. Le point certainement le plus important est que les captures instantanées dépendent totalement du bon fonctionnement de la plateforme de virtualisation. En cas de panne matérielle ou de problème logiciel au niveau de la plateforme logicielle de virtualisation, il n’y a plus aucune récupération possible. Une autre raison concerne directement les applications non informées du fait qu’une capture instantanée a été réalisée. Le retour en arrière d’un contrôleur de domaine ou d’un serveur Exchange Server sera réalisé mais ne permettra pas de récupérer un environnement globalement intègre au niveau de l’entreprise. En résumé, les captures instantanées apportent leur lot de nouveautés et rendront service dans de nombreux cas aux équipes ayant en charge le support et la maintenance des systèmes les plus critiques mais une solution de sauvegarde prenant en charge les environnements virtualisés devra être mise en œ uvre pour garantir une récupération en cas de catastrophe.

5. Exportation et importation des machines virtuelles La console de gestion Gestionnaire HyperV prend en charge l’exportation et l’importation des machines virtuelles entre différentes machines hôtes HyperV. Cette fonctionnalité permet de facilement migrer une machine virtuelle d’un hôte HyperV donné vers une autre machine plus adaptée. La procédure de migration d’une machine virtuelle entre deux machines hôtes HyperV est composée de deux étapes : La première étape prend en charge l’exportation de la machine virtuelle choisie sous la forme d’une collection de fichiers. Les opérations nécessaires à la bonne exécution de cette étape sont listées cidessous : ●

La machine virtuelle à transférer doit être à l’état Arrêté ou Enregistré.

●

Un emplacement cible du transfert de la machine virtuelle doit être déterminé : vous pouvez choisir de stocker les données exportées dans un emplacement temporaire ou bien directement positionner ces données au sein d’un dossier sur la machine hôte HyperV cible. La fenêtre cidessous illustre la définition du chemin d’accès d’exportation.

- 17 -

Exportation d’une machine virtuelle à l’aide du bouton Exporter de la console Gestionnaire Hyper V.

La case à cocher Exporter uniquement la configuration d’ordinateur virtuel permet d’exporter uniquement le fichier de configuration {GUID}.exp. Dans ce cas, aucun autre fichier (données d’état, fichiers VHD des disques durs virtuels...) n’est exporté.

●

Le fichier Config.xml : ce fichier XML contient uniquement des informations relatives aux disques virtuels exportés. Dans notre exemple, l’emplacement du disque est noté tel qu’il sera considéré à l’arrivée.

Contenu du dossier créé lors de l’exportation vers \\hv01\VM.Data

●

Le dossier Snapshots : ce dossier contient les informations relatives aux éventuelles captures instantanées, de la machine virtuelle exportée. Les données de captures instantanées sont composées des informations d’état, fichiers .vsv et fichiers .bin, ainsi que des fichiers de captures différentielles des disques, fichiers .avhd.

●

Le dossier Virtual Hard Disks : ce dossier contient tous les fichiers .vhd des différents disques virtuels de la machine virtuelle exportée.

●

Le dossier Virtual Machines : ce dossier contient un fichier nommé {GUID}.exp. La valeur du GUID, par exemple, 28B94DF66DBC43F989C2DADD4D81F7E2, est celle de la machine virtuelle exportée. Ce fichier, de type XML, malgré son extension .exp, comme export, contient les informations de configuration de la machine virtuelle exportée. Ce fichier sera converti lors du processus d’import en un fichier de configuration de machine virtuelle compatible avec HyperV.

La deuxième étape prend en charge l’importation des fichiers et des dossiers précédemment exportés vers la machine HyperV de destination. Elle est réalisée, localement ou à distance, à l’aide de la console de gestion Gestionnaire HyperV via le menu Actions Importer un ordinateur virtuel.

- 18 -

Importation d’une machine virtuelle via le menu Importer un ordinateur virtuel de la console Gestionnaire Hyper V Le bouton Parcourir permet de parcourir l’espace de stockage de la machine hôte HyperV de destination, sachant que tout à fait logiquement, il n’est pas possible d’importer une machine virtuelle distante.

Administration à distance HyperV et parcours des disques locaux refusé

Fenêtre de parcours vers la machine locale HyperV cible de l’importation Une fois le chemin sélectionné localement ou à partir d’une machine distante via le parcours réseau de type HyperV Remote File Browsing, le chemin local sur la machine hôte HyperV s’affiche.

- 19 -

Chemin d’accès local d’importation L’option Réutilisez les anciens ID d’ordinateurs virtuels est un choix important qui vous permettra ou non de réutiliser le GUID, ID de la machine virtuelle, lorsque celleci sera importée sur la machine hôte HyperV. Dans le cas où il s’agit du déplacement d’une machine virtuelle ou de la restauration d’une copie d’une machine virtuelle, le meilleur choix consiste à réutiliser le GUID original. Par contre, dans le cas de la copie d’une machine virtuelle existante, la bonne pratique consiste à générer un nouvel ID. Par défaut, cette case à cocher n’est pas sélectionnée. Attention : l’option Importer ne permet pas d’importer des machines virtuelles en provenance d’une plate forme de virtualisation différente telle que Virtual Server 2005 ou VMware ESX. Pour pouvoir exporter une machine virtuelle vers un partage réseau, il est nécessaire que l’utilisateur exécutant la console de gestion Gestionnaire HyperV et le compte de la machine hôte HyperV source disposent des permissions adéquates sur le partage et au niveau du disque NTFS. Ceci est spécifié des le document HyperV Release Notes datant du 26 juin 2008. Ce document est disponible à partir du site de téléchargement Microsoft http://www.microsoft.com/downloads. Attention à la déclaration du chemin d’importation : lorsqu’une machine virtuelle est importée, il n’est pas possible de facilement déplacer les différents fichiers. Le processus d’importation ne peut être joué qu’une seule fois par machine virtuelle exportée. Cette limitation s’explique par le fait que le fichier d’export .exp est converti en un nouveau fichier de configuration XML pour la nouvelle machine virtuelle migrée. Ce mode de fonctionnement signifie qu’en cas d’erreur pendant le processus d’importation, ou si les dossiers d’exportation n’ont pas été correctement définis, il sera nécessaire de rejouer à nouveau le processus d’exportation. Une autre solution sera de supprimer la machine virtuelle, repositionner les fichiers VHD vers les bons dossiers, puis recréer une nouvelle machine virtuelle.

6. Cas particulier des machines virtuelles de type Contrôleur de domaine La virtualisation des serveurs nécessite de la part des responsables du projet de virtualisation de déterminer les meilleurs candidats à la virtualisation. Les serveurs d’infrastructure tels que les contrôleurs de domaine, sont de très bons candidats à la virtualisation, puisque cette approche permet une réduction importante des coûts en matériels. Concernant les contrôleurs de domaines, les avantages sont nombreux : ●

Réduction du nombre de serveurs physiques à l’échelle de l’entreprise.

●

Possibilité d’héberger des contrôleurs de domaine prenant en charge des domaines différents, et ce, sans baisse de performance notable.

●

Mise en œ uvre facilitée des infrastructures de tests avant mise en production des modifications.

Cependant, parce qu’il s’agit de machines virtuelles « particulières », le cas des contrôleurs de domaine, considérés à juste titre comme des machines critiques, nécessite de prendre quelques précautions particulières. En majorité, celles ci sont directement en rapport avec la réplication des services d’annuaires Active Directory, du volume SYSVOL et des contraintes liées aux sauvegardes de cet environnement. Ces recommandations sont présentées cidessous : ●

- 20 -

Ne pas copier ou cloner le fichier VHD d’un contrôleur de domaine.

●

Ne pas mettre en pause, arrêter ou enregistrer l’état d’une machine virtuelle contrôleur de domaine pendant une période de temps supérieure à la durée définie au paramètre « Tombstone Lifetime » des contrôleurs de domaine puis de la remettre en service après coup.

●

Limiter l’utilisation des disques de différenciation sur les machines virtuelles contrôleur de domaine.

●

Ne pas utiliser la fonctionnalité de capture instantanée sur une machine virtuelle contrôleur de domaine sous peine de corruption totale (USN Rollback).

●

Ne pas restaurer un contrôleur de domaine en utilisant un ancien fichier VHD sous peine de corruption totale (USN Rollback).

Lorsqu’une opération illégale du type USN Rollback est réalisée au niveau d’un contrôleur de domaine le message, NTDS General, Event ID 2103, apparaît dans l’observateur d’événements : « La base de données Active Directory a été restaurée en utilisant une procédure de restauration non supportée. Active Directory ne sera plus capable d’authentifier les utilisateurs tant que cette condition persistera ». Ce problème peut se produire avec les captures instantanées réalisées par VMware ESX et aussi avec Microsoft HyperV. La seule solution capable d’atteindre un niveau d’intégrité correct est de réaliser, dans le même temps, un retour arrière de tous les contrôleurs de domaine et non d’un seul. Des solutions de contournement du nonsupport des captures instantanées sur les machines virtuelles de type contrôleur de domaine existent, sachant que les contrôleurs Windows Server 2008 R2 intègrent nativement le support des clichés Active Directory. S’agissant des contrôleurs de domaine Windows Server 2003, mais aussi Windows Server 2008, vous pourrez utiliser Microsoft System Center Data Protection Manager ou aussi l’outil UMove édité par la société ALGIN Technology. Cet outil prend en charge le déplacement, la récupération, le clonage des bases de données Active Directory ainsi que la gestion des clichés instantanés et la copie de machines virtuelles de tests. Pour plus d’informations sur cet outil, connectezvous sur le lien cidessous : http://utools.com/Default.asp Recommandation : une bonne pratique consiste à conserver deux contrôleurs de domaine sur des machines physiques. De cette manière, une tolérance de panne dans le cas où la plateforme de virtualisation viendrait à être indisponible est assurée.

Des machines physiques peuvent posséder les rôles de maitres d’opérations FSMO, sachant que les rôles FSMO ne font l’objet d’aucune contreindication à la virtualisation de la part de Microsoft. Cette remarque concerne principalement le rôle de PDC Emulator, lequel, en fonction de la taille du domaine Active Directory, peut être positionné sur un contrôleur de domaine installé physiquement. Pour plus d’informations concernant la virtualisation des contrôleurs de domaines sous HyperV, recherchez sur le site Microsoft Technet, « Running Domain Controllers in HyperV ».

7. Bonnes pratiques pour la configuration des machines virtuelles Vous trouverez cidessous les bonnes pratiques que tout administrateur de plateforme de virtualisation devrait s’attacher à respecter. Bon nombre d’entre elles sont directement issues du bon sens tandis que d’autres proviendront des équipes de Microsoft. Pour plus d’informations concernant les meilleures pratiques en terme de configuration et de mise en œ uvre de la plateforme HyperV, vous pourrez vous référer au document Microsoft intitulé « Performance Tuning Guidelines for Windows Server 2008 », téléchargeable à partir du site de Microsoft à l’aide du lien suivant : http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx

a. Performance Tuning Guidelines for Windows Server 2008 Ce guide décrit précisément les paramètres d’optimisation et bonnes pratiques qui doivent être respectées pour obtenir les meilleures performances de Windows Server 2008. Chaque paramètre et ses effets positifs et négatifs, sont décrits de telle sorte que l’administrateur peut faire le meilleur choix en fonction de chaque situation particulière. Ce document contient les chapitres suivants : ●

Performance Tuning for Server Hardware,

●

Performance Tuning for Networking Subsystem,

●

Performance Tuning for Storage Subsystem,

- 21 -

●

Performance Tuning for Web Servers,

●

Performance Tuning for File Servers,

●

Performance Tuning for Active Directory Servers,

●

Performance Tuning for Terminal Server,

●

Performance Tuning for Terminal Server Gateway,

●

Performance Tuning for Virtualization Servers,

●

Performance Tuning for File Server Workload (NetBench),

●

Performance Tuning for Network Workload (NTttcp),

●

Performance Tuning for Terminal Server Knowledge Worker Workload,

●

Performance Tuning for SAP Sales and Distribution TwoTier Workload.

b. Recommandations

- 22 -

●

Assurezvous que toutes les machines virtuelles disposent des services d’intégration HyperV et que le meilleur niveau est installé.

●

Ne mélangez pas sur la même machine hôte HyperV des machines virtuelles disposant des services d’intégration HyperV et des machines n’en disposant pas.

●

Utilisez des disques durs virtuels de taille fixe plutôt que les disques virtuels dynamiques ou les disques virtuels de différenciation. Les performances sont supérieures et le système de fichiers sousjacent sera moins sensible à la fragmentation.

●

Avant de créer un nouveau disque virtuel, assurezvous que le disque physique ou le volume exposé via le SAN n’est pas sujet à un niveau de fragmentation trop élevé. En pareil cas, procédez à une opération de défragmentation des disques SAN.

●

Préférez les interfaces virtuelles SCSI pour accéder aux disques de données. HyperV impose que le démarrage des machines virtuelles ait lieu à partir d’un contrôleur de disque IDE. Cependant, les adaptateurs SCSI peuvent être utilisés après l’amorçage du système. Microsoft fait remarquer que les performances entre IDE et SCSI sont identiques au sein de l’environnement virtuel HyperV. L’utilisation de contrôleurs SCSI sera privilégiée lorsque la machine virtuelle devra disposer de plus de quatre disques virtuels. Pour rappel, une machine virtuelle peut gérer un maximum de 256 disques SCSI répartis sur quatre contrôleurs SCSI.

●

Assurezvous que vous obtenez les performances maximum du SAN.

●

Assurezvous de la disponibilité des emplacements qui contiennent les données de configuration des machines virtuelles. Si cet emplacement est un partage réseau, il est recommandé qu’il s’agisse d’un partage hautement disponible.

●

Configurez les propriétés d’affichage pour obtenir les meilleures performances. Pour y parvenir, installez les services d’intégration HyperV et assurezvous que les propriétés de l’ordinateur utilisent l’option d’affichage Meilleures performances. Ce choix garantit que l’accélération matérielle est complète.

●

Dans le cas de la migration des machines virtuelles depuis Virtual Server 2005 R2 ou Virtual PC, n’oubliez pas de désinstaller les « VM Additions » avant la migration vers HyperV. Il est aussi recommandé de procéder à un compactage des fichiers VHD avant leur utilisation sur la nouvelle plateforme HyperV.

●

Évitez de surcharger la machine hôte HyperV.

●

Allouez les ressources CPU en ayant anticipé les charges.

●

Réfléchissez à l’opportunité d’utiliser les disques durs physiques, PassThrough Disks. Il est généralement recommandé d’utiliser des disques virtuels. Cependant, certaines configurations, par exemple, dans le cas d’Exchange Server 2007 SP1, nécessitent l’usage de disques physiques. Leur utilisation permet de dépasser la barrière de 2 To supportée par les fichiers VHD et les performances en entréessorties sont légèrement supérieures. Cependant, les disques durs physiques nécessitent de placer les fichiers de configuration de la machine virtuelle à un autre emplacement et ne supportent pas les captures instantanées HyperV. Il faut noter que Microsoft supporte les captures instantanées dans les environnements de production mais ne le recommande pas. Les captures instantanées étant basées sur des disques différentiels, les performances peuvent être inférieures à celles d’un disque virtuel de taille fixe. Il faut prévoir l’espace disque nécessaire au stockage des captures instantanées. Lorsque des captures sont supprimées, il faudra accepter le temps d’indisponibilité qui pourra résulter de la fusion des fichiers AVHD lors de l’arrêt de la machine virtuelle. Les captures instantanées ne sont pas supportées dans les environnements en cluster. Enfin, les disques physiques ne supportent pas les captures instantanées. En résumé, la mise en œ uvre des captures instantanées peut être réalisée sur certaines machines virtuelles mais déconseillée sur d’autres ! Cette grande fonctionnalité devra donc faire l’objet d’une considération particulière avant toute mise en production.

c. À propos de System Center Virtual Machine Manager 2008 Comme vous pouvez le constater, HyperV permet aux administrateurs de la plateforme de virtualisation une administration « basique ». Bien sûr, il est possible de regretter que l’interface graphique de la console Gestionnaire HyperV ne supporte pas de notion de modèles de machine virtuelle ou de modèles de différents types de disques ou de connectivité réseau. Cependant, les fonctions essentielles sont bien là. Pour disposer d’une plateforme de gestion puissante basée sur différentes familles d’objets, il faudra s’équiper de System Center Virtual Machine Manager 2008. SCVMM 2008 est un produit de la gamme Microsoft System Center adapté aux Datacenter de toutes tailles ; un seul serveur VMM 2008 peut prendre en charge jusqu’à 400 machines hôtes HyperV pour un total de 8000 machines virtuelles. Cependant VMM est aussi adapté aux configurations d’entrée de gamme que l’on retrouvera dans les TPE et les PME. Pour répondre à ce besoin, il existe une version de VMM 2008 adaptée aux clients PME. Cette édition, Virtual Machine Manager 2008 Workgroup Edition, comprend toutes les licences pour administrer un nombre illimité de machines virtuelles hébergées sur un maximum de 5 machines hôtes HyperV. Cette version de VMM est disponible pour moins de 500 euros. Par rapport à l’investissement important que nécessite la plateforme matérielle, les licences Windows Server 2008 R2 et SCVMM 2008 ne sont qu’une toute petite partie du budget. Il est fortement conseillé d’utiliser VMM WGE avec un outil de surveillance des machines hôtes et des applications tel que System Center Essentials ou System Center Operations Manager.

- 23 -

Plateforme de virtualisation et haute disponibilité HyperV Depuis plusieurs années les équipes informatiques ont été confrontées à la mise en œ uvre de solutions de haute disponibilité pour garantir un fonctionnement constant des services les plus sensibles de type 24H/24, 7j/7. Les solutions ont généralement toujours été proches du matériel et du système d’exploitation assurant le support des applications. Cependant, aujourd’hui, la mise en œ uvre de platesformes de virtualisation rend encore plus dramatique et significative la perte d’une machine unique dont le rôle est de supporter de multiples machines virtuelles. En effet, les platesformes de virtualisation permettent de réduire le coût total de possession et aussi d’améliorer la qualité des services offerts (déploiement de nouveaux serveurs virtuels accéléré, meilleure gestion des ressources, etc.) mais malheureusement, elles introduisent un problème majeur : un point de défaillance unique au niveau du serveur de virtualisation luimême ! Ainsi, un dysfonctionnement provoquant l’arrêt brutal d’un serveur hôte assurant le fonctionnement d’une vingtaine de machines virtuelles sera un événement catastrophique aux conséquences multiples ! Pour répondre à cette problématique et ainsi aux enjeux des entreprises, HyperV a été conçu pour assurer une haute disponibilité des machines virtuelles. Plusieurs alternatives sont envisageables : ●

La mise en cluster de la machine hôte,

●

La mise en cluster des machines virtuelles hébergées par la machine hôte,

●

L’utilisation des fonctionnalités de haute disponibilité intégrées aux applications,

●

L’ajout de solutions tierces.

1. Windows Server Failover Clustering offre ses services à HyperV Les versions Entreprise et Datacenter de Windows Server 2008 R2 permettent à chaque nœ ud devant supporter des machines virtuelles de faire partie intégrante d’un cluster Windows Server 2008 R2. Un cluster Windows Server 2008 R2 est un groupe d’ordinateurs regroupés ensemble pour fournir des services hautement disponibles entre les différents nœ uds. Les services de cluster de Windows Server 2008 R2, désormais appelés Windows Server Failover Clustering, ont été conçus pour supporter jusqu’à 16 nœ uds HyperV fonctionnant sous Windows Server 2008 R2 Edition Entreprise ou Datacenter. Ainsi, la configuration d’une machine virtuelle au sein du cluster signifie que vous pouvez rendre disponible auprès des autres nœ uds du cluster, les ressources nécessaires à la machine virtuelle, c’estàdire l’ensemble de ses paramètres de configuration ainsi que le ou les disque(s) virtuel(s) accessible(s) via le stockage SAN FC ou iSCSI. De cette manière, chaque machine virtuelle peut être protégée à l’aide de la fonctionnalité Quick Migration et Live Migration. En plus des aspects « haute disponibilité », la possibilité de déplacer une machine virtuelle vers un autre hôte HyperV permet de tirer parti des meilleures performances d’un autre nœ ud. Cette fonctionnalité est aussi très intéressante dans le cadre de la maintenance matérielle et logicielle des machines hôtes.

a. Principe de fonctionnement de Quick Migration Le principe utilisé par Quick Migration est le suivant : lorsque la migration d’une machine virtuelle est planifiée, Quick Migration met en pause la machine virtuelle, sauvegarde l’état de sa mémoire et des registres CPU utilisés, vers un disque accessible via le stockage SAN. Ensuite, il déplace le ou les disques SAN de la machine virtuelle vers un autre nœ ud du cluster pour, finalement, restaurer l’état de la machine virtuelle sur l’autre nœ ud. La première étape pour utiliser la nouvelle fonctionnalité Quick Migration prise en charge par HyperV est de créer un cluster Windows Server 2008 R2. Ce point signifie que vous devez utiliser Windows Server 2008 R2 Edition Enterprise ou Windows Server 2008 R2 Edition Datacenter, l’édition Standard de Windows Server 2008 R2 ne prenant pas en charge les configurations en cluster. Une fois la fonctionnalité disponible au sein du cluster de machines hôtes HyperV, tout ou partie des machines virtuelles pourront être rendues « hautement disponibles ». En cas de crash ou de mauvais fonctionnement d’une machine virtuelle, celleci peut être redémarrée sur le même nœ ud ou bien sûr un autre nœ ud du cluster. Enfin, un administrateur peut, par exemple dans le cadre des opérations de maintenance matérielles des machines hôtes HyperV, déplacer à chaud les machines virtuelles, afin de libérer le serveur.

- 1-

b. Temps de bascule Quick Migration Le temps nécessaire à la migration d’une machine virtuelle dépend essentiellement de la mémoire dynamique qu’il sera nécessaire d’écrire sur le disque et de la performance de la connexion au stockage SAN. Le tableau cidessous liste les temps de migration d’une machine virtuelle en fonction de la mémoire RAM de celleci et de la technologie de stockage utilisée : RAM de machine virtuelle

1 Gb Ethernet iSCSI

2 Gb FC

4 Gb FC

512 Mo

Env. 8 secondes

Env. 4 secondes

Env. 2 secondes

1 Go

Env. 16 secondes

Env. 8 secondes

Env. 4 secondes

2 Go

Env. 32 secondes

Env. 16 secondes

Env. 8 secondes

4 Go

Env. 64 secondes

Env. 32 secondes

Env. 16 secondes

8 Go

Env. 2 minutes

Env. 64 secondes

Env. 32 secondes

En général le temps de bascule, correspondant au « passage » de la machine virtuelle d’un nœ ud à l’autre, ne prend que quelques secondes. Cependant, dans le cas d’un arrêt non planifié, c’estàdire dans le cas d’une interruption totale de la machine virtuelle ou du nœ ud hôte HyperV au sein du cluster, l’état du système n’existant pas, la machine virtuelle devra être redémarrée. Quoi qu’il en soit, les connexions réseau ne sont pas maintenues. De ce point de vue, l’application cliente doit être capable de rétablir la connectivité vers le serveur virtuel ayant été déplacé. En dernier ressort, l’application client devra être relancée. Windows Server 2008 R2 introduit Live Migration : Live Migration est une évolution majeure du concept introduit avec Quick Migration. Avec Live Migration, le temps de bascule est de 0 seconde et les connexions réseau sont préservées. Les applications clientes ne sont donc pas impactées. Microsoft prévoit de rendre disponible cette nouvelle version à la fin de l’année 2009 ou durant le premier trimestre 2010. De plus, la fonctionnalité Live Migration devrait être présente dans la version gratuite d’HyperV, HyperV Server 2008 R2.

2. Profiter des services de virtualisation et des services de clustering Windows Le principe consiste à déterminer quelle est la meilleure solution à implémenter pour mettre à disposition de l’application un environnement hautement disponible. Dans l’absolu, la bonne approche consiste à utiliser les fonctionnalités intégrées au sein des applications. Par exemple, il n’est pas nécessaire d’implémenter de mécanisme supplémentaire pour les contrôleurs de domaines, les serveurs DNS, les espaces DFSR ou les bases de données SQL Server. Tous ces services disposent de mécanismes de réplication intégrés qui les rendent hautement disponibles, pour peu qu’au minimum deux machines soient configurées. De son côté, Exchange Server 2007 n’est pas en reste avec plusieurs solutions de haute disponibilité intégrées telles que la Réplication Locale en Continue (LCR), la Réplication Continue en Cluster (CCR), la Réplication Continue en mode Standby (SCR) et enfin la réplication de Copie Unique en Cluster (SCC). Toutes ces méthodes de secours peuvent être implémentées dans des environnements de machines virtuelles. De cette manière, en cas d’indisponibilité d’une machine virtuelle invitée ou de la machine hôte HyperV, une autre machine virtuelle fonctionnant sur un autre serveur de virtualisation HyperV pourra fournir les services et applications « manquantes ». De cette manière, la disponibilité des systèmes est assurée grâce à la plateforme de virtualisation associée aux fonctionnalités de haute disponibilité de l’application.

3. À propos des services de clustering de Windows Server 2008 R2 Les services de cluster de Windows Server 2008 R2 ont fait l’objet d’une refonte totale pour profiter pleinement de Windows Server 2008 R2. En effet, depuis son introduction avec Windows NT 4.0 Edition Entreprise, ni Windows 2000 Server, ni Windows Server 2003 n’ont totalement banalisé la mise en œ uvre, l’administration et la maintenance de ce service, et ce, même si au fil des années, les services MSCS (Microsoft Cluster Service) se sont considérablement améliorés. Fort de ce constat, l’équipe de développement de Windows Server 2008 R2 a mis l’accent sur la simplicité et a entrepris de complètement remanier la fonctionnalité. Aujourd’hui appelée « Windows Failover Clustering » ou Cluster avec basculement, cette nouvelle implémentation supporte jusqu’à 16 nœ uds x64, les architectures x86 et Itanium étant limitées à 8 nœ uds.

- 2-

a. Nouvelle console MMC Gestion de cluster de basculement et nouveaux assistants Une fois le cluster avec basculement installé, l’interface de gestion de cluster de basculement est très agréable à utiliser, même si elle peut dérouter les administrateurs habitués à l’interface de Windows 2000 Server/Windows Server 2003. Comme cela est le cas de toutes les interfaces d’administration basées sur la console de gestion MMC 3.0, la nouvelle interface, cluadmin.msc, est divisée en trois volets distincts. Le volet de gauche liste tous les clusters Windows Server 2008 R2 de l’entreprise, tandis que le volet central fournit des détails sur tout ou partie de la configuration du cluster. Comme il s’agit d’une console de type MMC 3.0, le volet situé le plus à droite liste les actions pouvant être exécutées, en fonction du contexte.

Composant logiciel enfichable de Gestion de cluster de basculement

Attention : le nouveau composant logiciel enfichable de gestion de cluster de Windows Server 2008 R2 ne peut pas être utilisé pour administrer les versions antérieures des services de cluster Microsoft. De même, la console de gestion de Windows Server 2003 ne prend pas en charge la gestion des services de cluster de Windows Server 2008 R2.

b. Amélioration de la configuration du cluster La configuration d’un cluster Windows Server 2008 R2 est aujourd’hui très simple. De nombreux assistants sont présents et permettent de configurer, modifier et gérer les configurations en cluster, localement et à distance.

- 3-

Page de résumé de l’Assistant Création d’un cluster La figure cidessous illustre la configuration d’une machine virtuelle HyperV au sein du cluster. Le fait que les nœ uds du cluster disposent du rôle HyperV permet au cluster d’implémenter les fonctions de haute disponibilité aux machines virtuelles dont les ressources disques sont prises en charge par le cluster Windows Server 2008 R2.

L’Assistant Haute disponibilité permet la mise en cluster des machines virtuelles La dernière étape de la configuration permet à l’administrateur de consulter une page de résumé et un rapport détaillé des opérations.

- 4-

Traitement de la validation de la configuration du cluster

c. Validation de la configuration Les services de cluster de Windows Server 2008 R2 permettent désormais de valider la configuration du cluster via un nouveau processus de validation intégré regroupant un ensemble de quatre familles de tests. Avec l’intégration de ce nouveau processus de validation, la politique de support de Microsoft devient beaucoup plus souple. Désormais, il n’est plus nécessaire que les matériels figurent dans la liste de compatibilité matérielle dédiée aux configurations de type « cluster ». Les matériels doivent simplement disposer du logo Windows Server 2008 R2 et tous les tests de validation doivent réussir. Les seules exceptions à cette nouvelle règle sont les clusters géographiquement dispersés sur des réseaux IP distincts qui utilisent des baies de disques localement sur chaque site. Il en est de même pour l’implémentation de la réplication continue en cluster Exchange Server 2007 qui n’utilise pas de stockage partagé. Par le passé, les solutions de cluster supportées par Microsoft devaient avoir fait l’objet de tests pris en charge par les constructeurs et validés par les Labs de Microsoft certification WHQL (Windows Hardware Quality Lab).

Pour plus de détails sur la politique de support Microsoft relative aux configurations en cluster Windows Server 2008 R2, recherchez l’article 943984 Microsoft Support Policy for Windows Server 2008 R2 Failover Clusters de la base de connaissance Microsoft. http://go.microsoft.com/fwlink/?LinkId=111552. Concernant la validation, la catégorie Stockage est certainement la plus importante. Elle inclut de nombreux tests avancés qui permettent de s’assurer que la solution de stockage déployée est bien conforme aux exigences imposées par les nouveaux systèmes en cluster de basculement fonctionnant sous Windows Server 2008 R2.

- 5-

Lancement de la validation de la configuration des deux nœuds du cluster Par défaut, tous les tests sont réalisés. Cependant, l’administrateur peut désélectionner les tests jugés non indispensables. Attention : les pilotes de stockage doivent être basés sur Storport et prendre en charge les réservations persistantes SCSI3. De plus, les modules spécifiques aux périphériques des logiciels avec plusieurs chemins d’accès doivent être basés sur la norme Multipath I/O (MPIO) intégrée à Windows Server 2008 R2. La figure cidessous montre le résumé issu de l’Assistant Validation d’une configuration. Le compte rendu indique que la configuration semble être adaptée aux services de clustering mais qu’il est recommandé d’examiner le rapport qui contient des avertissements.

- 6-

Résumé final de la Validation d’une configuration en cluster

d. Quorum WSFC : Garantir l’intégrité et l’unité du cluster Les clusters Windows implémentent depuis la toute première version la notion de quorum. Windows Server 2008 R2 introduit de nouvelles possibilités de mise en œuvre dont dépendent les nouveaux modèles de quorum supportés par cette nouvelle version de Windows.

L’un des changements les plus importants apportés par les nouveaux services de clustering de Windows Server 2008 R2 Edition Entreprise et Edition Datacenter est le nouveau modèle de quorum. Windows Server 2003 permet seulement deux types de quorums, à savoir le disque unique de type quorum, datant de Windows NT Server 4.0, et le quorum de type MNS Majority Node Set (MNS).

En fait, nous pouvons dire qu’il existe réellement trois types de quorums, si l’on considère le quorum de type MNS Majority Node Set (MNS) avec partage témoin FSW File Share Witness (FSW). Un cluster étant composé de plusieurs machines, lorsque des problèmes réseau surviennent, les communications entre les différents nœ uds de cluster peuvent être impactées. Par exemple, il est possible qu’un certain nombre de nœ uds puissent communiquer entre eux mais ne puissent pas communiquer avec un ensemble de nœ uds différent situés dans une autre partie du réseau. Cette situation peut provoquer des problèmes de cohérence, le cluster étant « coupé en plusieurs morceaux ». Lorsqu’une situation de ce genre se produit, au moins un des ensembles de nœ uds doit arrêter de participer au cluster, et ce, même si les différents ensembles de nœ uds n’ont aucune information concernant l’état des autres nœ uds. Pour pallier ce type de situation délicate, le service de cluster impose que tous les ensembles de nœ uds exécutés au sein d’un cluster utilisent un algorithme de vote pour déterminer si, à un instant spécifique, le jeu du cluster a un quorum. En fonction du nombre de nœ uds et de la configuration particulière de quorum du cluster, celuici peut facilement déterminer combien de machines votantes pourront constituer une majorité c’estàdire un quorum. Lorsque le nombre de votes est inférieur à la majorité, le cluster s’arrête spontanément de fonctionner. Durant cette période, les nœ uds continuent d’écouter sur le réseau la présence d’autres nœ uds. Enfin, ils ne recommenceront à fonctionner que lorsque le quorum sera à nouveau atteint. La configuration du quorum au sein d’un cluster de basculement permet de déterminer le point à partir duquel un certain nombre de nœ uds défaillants stopperont l’exécution du cluster. Les défaillances concernées dans ce contexte sont des défaillances de nœ uds membres du cluster ou, un disque témoin ou un partage de fichiers témoin, lequel contient une copie de la configuration de cluster.

e. Les types de quorums L’assistant de configuration d’un nouveau cluster distingue quatre types d’implémentations qui dépendent du modèle de quorum choisi : ●

Le quorum de type MNS (Majority Node Set) : un cluster configuré avec un quorum à jeu de majorité reste en ligne tant que la majorité des nœ uds le composant est opérationnelle. Par exemple, un cluster à 4 nœ uds fonctionnera tant que 3 nœ uds sur 4 seront opérationnels

Mais si 3 nœ uds sur 4 sont en fonction et qu’un deuxième nœ ud devient indisponible, alors la majorité n’est plus atteinte et le service de cluster tombe. ●

Le quorum de type NDM (Node and Disk Majority) : un cluster configuré de cette manière est une évolution du modèle précédent. Dans ce modèle, un pseudonœ ud, agissant dans le calcul de la majorité, sera ajouté via un disque partagé de type NAS ou SAN qui jouera le rôle de témoin. Le fait d’ajouter un pseudomembre au cluster influence le calcul de la majorité et augmente donc le niveau de tolérance de pannes. Effectivement, dans ce cas, un cluster à 4 nœ uds pourra rester en ligne tant que 2 des nœ uds plus le disque partagé, seront opérationnels.

Cette fonctionnalité est disponible à partir de Windows Server 2008 SP1 sous la forme d’une mise à jour. Il est ainsi possible d’ajouter un témoin de partage de fichiers et de configurer les pulsations du cluster. Pour plus d’informations, vous pouvez vous référer au document de la base de connaissances Microsoft à l’aide du lien :

- 7-

http://support.microsoft.com/kb/921181/enus

Le partage réseau utilisé pour le témoin de partage de fichiers ne peut pas être mis en œ uvre au sein d’un environnement DFS.

●

Le quorum de type NFSM (Node and File Share Majority) : ce modèle de configuration utilise uniquement un partage de fichiers en tant que témoin.

●

Le quorum de type disque sans majorité : cette configuration utilise un quorum partagé de type SAN ou NAS. Il s’agit du seul modèle de cluster Microsoft où le quorum n’est pas répliqué localement sur l’ensemble des nœ uds. Ce type de configuration n’implémentant pas le principe de la majorité, un cluster composé de 4 nœ uds restera fonctionnel tant qu’au moins un nœ ud sera actif.

Attention : le quorum de type disque sans majorité introduit un point de défaillance ! Si le quorum partagé sur le SAN est corrompu, le cluster est perdu ! Microsoft recommande de ne plus utiliser ce modèle de quorum qui date de Windows NT et Windows 2000 Server. Si tous les nœ uds du cluster ainsi que le réseau de stockage sont disponibles pendant la création du cluster, le modèle de quorum le mieux adapté à la configuration est automatiquement sélectionné.

Recommandations proposées par l’Assistant de Configuration du quorum du cluster

f. Éléments à considérer pour choisir le type de quorum Les éléments à considérer pour aider au choix du type de cluster le mieux adapté à l’environnement de production sont listés cidessous :

- 8-

●

Les configurations de clusters à quorum partagé possèdent un point de défaillance unique, SPOF (Single Point of Failure). En effet, les données de configuration sont uniquement localisées au niveau du quorum partagé. De plus, le fait que le quorum soit en un seul point fait qu’il n’est pas possible d’implémenter une solution de type cluster géographique.

●

Les configurations de clusters à nœ uds majoritaires, quorum MNS, permettent la mise en œ uvre de clusters géographiques. Dans ce cas, les données de configurations sont sécurisées via la réplication.

●

Enfin, les clusters de type MNS utilisant des témoins additionnels, disques ou partages de fichiers, améliorent la tolérance de pannes.

Microsoft recommande d’utiliser un quorum à majorité avec témoin. L’utilisation de cluster à quorum partagé ne se justifie que dans certains scénarios et nécessite une attention particulière. En plus de ces évolutions concernant les différents types de quorums, les services Windows Server Failover Clustering apportent les nouveautés suivantes : ●

La possibilité d’utiliser des opérateurs logiques, ET, OU, pour gérer les dépendances entre ressources. Cette nouvelle option améliore considérablement la configuration des ressources.

●

La prise en charge native des clusters géographiques en offrant la possibilité à l’administrateur de gérer la fréquence des pulsations heartbeats, entre les nœ uds. Cette nouvelle option permet une meilleure prise en charge des timeouts lorsque les nœ uds d’un cluster sont interconnectés via une connexion WAN.

Remarque concernant la migration des clusters de Windows Server 2003 Edition Entreprise ou Datacenter vers Windows Server 2008 R2 : il n’est pas possible d’intégrer au sein d’un même cluster des nœ uds utilisant des systèmes d’exploitation différents. La méthode consiste donc à migrer les ressources d’un cluster Windows Server 2003 vers un cluster fonctionnant sous Windows Server 2008 R2. Cette méthode peut être réalisée dans le cadre d’une transition vers une nouvelle plateforme cluster fonctionnant sous Windows Server 2008 R2 ou bien dans le cadre d’une migration « sur place ». Dans ce cas, un nœ ud du cluster fonctionnant sous Windows Server 2003 est retiré en vue de l’installation d’un nouveau cluster fonctionnant sous Windows Server 2008 R2. À ce stade, il ne reste plus qu’à déplacer les ressources du cluster à 1 nœ ud fonctionnant sous Windows Server 2003 vers le cluster à 1 nœ ud fonctionnant sous Windows Server 2008 R2. Une fois les ressources transférées, le nœ ud fonctionnant sous Windows Server 2003 peut être réinstallé à son tour sous Windows Server 2008 R2 en vue de son intégration au sein du nouveau cluster. Enfin, audelà de la mise en cluster des machines virtuelles HyperV, les éléments tels que les services de fichiers et d’impressions, les services DHCP, WINS, les services de noms DFS, les machines virtuelles HyperV, les applications telles que, par exemple, Microsoft SQL Server, Microsoft Exchange Server, mais aussi des scripts et des services génériques sont pris en charge.

4. Souplesse et haute disponibilité L’idée est la suivante : il se peut que certaines applications soient installées en cluster Windows et que l’entreprise souhaite virtualiser ces machines physiques. L’installation des services de cluster au sein des machines virtuelles étant identique, il est alors possible de tirer parti des deux technologies ! La mise en cluster des machines virtuelles invitées vous permet de créer l’abstraction par rapport au matériel de telle sorte qu’il soit aisé d’arrêter une machine invitée pendant qu’une autre machine virtuelle du cluster assure le service. L’administrateur peut modifier les ressources virtuelles telles que le nombre de processeurs, la mémoire RAM ou le stockage disque, lui aussi virtualisé via le SAN et via HyperV. Les ressources CPU, RAM, disques, réseaux étant prises en charge par la plateforme de virtualisation, la maintenance est véritablement améliorée de manière significative. En effet, les mises à niveaux matérielles de machines physiques utilisées par les clusters ne sont pas toujours faciles. Elles nécessitent des achats, des mises à jour de firmware (microcode, BIOS, etc.), des redémarrages complets à froid. Grâce à la virtualisation, toutes ces opérations deviennent « virtuelles » et n’impactent plus les serveurs qui « virtualisés » sont déplaçables facilement. Dans le même ordre d’idées, il est aussi très facile d’ajouter une nouvelle machine hôte HyperV plus moderne techniquement au sein du cluster et d’y déplacer des machines virtuelles invitées : elles profiteront des nouvelles performances du nouvel hôte HyperV. Les technologies de NLB (Network Load Balancing) et les mécanismes de réplication intégrés à certaines applications ou solutions tierces, ne doivent pas être comparés aux technologies de Clustering supportées par des applications comme SQL Server ou Exchange Server. Elles ne les remplacent pas ! Elles les complètent quant à la répartition de la charge réseau et la disponibilité de données répliquées sur plusieurs machines. Notez aussi que la mise en cluster de machines virtuelles peut être réalisée sur la même machine hôte HyperV, mais qu’il est recommandé de placer chaque machine virtuelle invitée en cluster sur des machines HyperV différentes.

5. Solution de virtualisation et PRA

- 9-

Nous venons de voir à quel point les services de cluster de Windows Server 2008 R2 sont indispensables aux environnements virtualisés. Cependant, audelà de la consolidation souvent nécessaire des serveurs et des environnements de tests utiles aux équipes informatiques et aux développeurs, les solutions de virtualisation permettent la continuité des services et la récupération rapide en cas de désastre. La continuité des services est la capacité implémentée par l’équipe informatique à minimiser au maximum les arrêts prévisibles et aussi imprévisibles. La plateforme de virtualisation HyperV prend en charge des fonctionnalités de récupération très puissantes telles que les fonctionnalités Quick Migration et Live Migration mais aussi les sauvegardes en ligne des machines virtuelles, les captures instantanées et aussi les configurations de type géo cluster. Audelà de la technologie, la mise en place d’un PRA (Plan de Reprise d’Activité) est un processus long et itératif qui pourra être structuré de la manière suivante : Première étape : création de l’équipe PRA. ●

Lors de cette étape, il faudra déterminer les différents membres de l’équipe. Ces personnes doivent disposer d’une autorité suffisante qui permette à l’équipe de recenser les informations relatives à ce qui est le plus important pour l’entreprise.

●

Il faudra définir les responsabilités des différents membres de l’équipe puis associer à chaque membre chaque aspect du plan de reprise de l’activité.

Deuxième étape : catégoriser l’ensemble des processus métiers ●

Identifier et classifier l’ensemble des processus métiers.

●

Définir par rapport aux processus métiers identifiés les systèmes, les technologies, les applications, les données qui devront être pris en charge en vue de la continuité des services.

●

Déterminer le niveau de protection à prendre en charge pour chaque élément nécessaire à la mise en œ uvre opérationnelle des processus métiers.

Troisième étape : déterminer quels processus métiers feront partie ou non du Plan de Reprise d’Activité. ●

Évaluer l’ensemble des procédures de sauvegardes et de récupération nécessaires au PRA.

●

Intégrer toutes les procédures validées au sein du PRA.

●

Faire évoluer, si nécessaire, les procédures existantes pour les intégrer au sein du PRA.

Quatrième étape : tester puis implémenter le PRA. Une fois implémenté, le PRA devra faire l’objet de procédures de tests partiels ou complets pour s’assurer que le niveau d’efficacité est toujours maintenu. Pour plus d’informations sur la mise en œ uvre d’un Plan de Reprise d’Activité avec HyperV, vous pouvez consulter le document Microsoft Planning and Deployment Guide disponible sur le site de Microsoft.

- 10 -

Mise en œuvre de Quick Migration Ce paragraphe illustre la mise en œ uvre de la fonctionnalité Quick Migration en prenant le cas d’une configuration basée sur un cluster Windows Server 2008 R2 composé de deux nœ uds. Windows Server 2008 supporte le déplacement des machines virtuelles à chaud en mode Quick Migration, avec coupure des connexions réseau. Windows Server 2008 R2 supporte ce mode mais aussi le nouveau mode de déplacement Live Migration, sans aucune coupure, ni interruption de service. Cette fonctionnalité R2 est présentée au chapitre Fonctionnalités avancées d’HyperV v2. Une fois le cluster opérationnel avec le rôle HyperV actif, une machine virtuelle est configurée en mode haute disponibilité au sein du cluster. Nous sommes dans un modèle de type « Share nothing ». Ce modèle signifie que la machine virtuelle mise en cluster ne sera active que sur un nœ ud à la fois mais pourra faire l’objet d’une migration rapide vers un autre nœ ud du cluster. Ce concept est aussi appelé actifpassif puisqu’un des nœ uds est actif, tandis que le ou les autres sont passifs, toujours par rapport à une ressource donnée. Au sens HyperV du terme, il arrive que l’on parle de cluster actifactif. En effet, chaque nœ ud a la capacité de faire fonctionner n machines virtuelles, tout en étant le secours des autres machines virtuelles en cluster sur les autres nœ uds. Notez toutefois qu’en général, le terme actifactif sousentend que n nœ uds sont actifs sur la même ressource, ce qui n’est pas le cas ici. La configuration est présentée cidessous : le réseau public est utilisé pour connecter les ressources prises en charge par le cluster au réseau de l’entreprise. De cette manière, les machines virtuelles hébergées au sein du cluster pourront accéder aux autres machines du réseau, si nécessaire. Le réseau privé est exclusivement dédié aux communications intracluster, lesquelles permettent de vérifier l’état des autres nœ uds du cluster.

Configuration Windows Server Failover Clustering et HyperV Quick Migration Le réseau utilisé pour l’accès au SAN dépend de la technologie utilisée. Pour les SAN FC, il sera nécessaire d’implémenter un commutateur ainsi qu’une carte HBA (Host Base Adapter) pour chaque serveur afin de réaliser la connexion au switch via la fibre optique. Il est fortement recommandé de doubler tous ces éléments (switchs FC, cartes HBA, fibres, etc.) pour garantir une totale sécurité du SAN. Le protocole iSCSI est une alternative très intéressante en proposant une simplification de la connectivité du SAN. L’utilisation de ce protocole permet l’utilisation de composants Ethernet standard. Ainsi, il est possible de réduire les coûts d’acquisition de matériel, les coûts de formation et de

- 1-

support, d’unifier les structures techniques. Un autre avantage des architectures SAN iSCSI est de bénéficier d’un plus large choix de contrôleurs. Les reproches autour du iSCSI concernent ses performances : ses détracteurs prétendant que sa bande passante est inférieure à celle du FC, et que le protocole luimême est trop bavard. Les composants du réseau SAN FC sont généralement beaucoup plus onéreux que les composants Ethernet standard. Les éléments FC, des commutateurs en passant par les cartes HBA et les câbles, sont toujours bien plus chers que les composants Ethernet. Il faut noter que les constructeurs Dell, HP, IBM, etc. qui étoffent leurs catalogues de solutions de stockage SAN FC le font à travers un accord OEM. Ce mode de distribution inclut donc forcément une majoration souvent importante. À l’inverse, les composants Ethernet, switchs, cartes Ethernet GB sont en général directement achetés chez le fournisseur du produit.

1. Ressources nécessaires ●

Vous devez disposer de Windows Server 2008 Edition Enterprise ou Datacenter installé sur deux nœ uds ou plus, une configuration à trois ou quatre nœ uds donnant une bien plus grande souplesse.

●

Les nœ uds du cluster doivent tous faire partie du même domaine Active Directory. Concernant le rôle « Contrôleur de domaine », Microsoft recommande que tous les nœ uds aient le même rôle. La bonne pratique serait donc que les nœ uds HyperV en cluster ne soient pas des contrôleurs de domaine.

●

Des services de résolution de noms tels que le service DNS doivent être pleinement disponibles et utilisés par tous les nœ uds du cluster.

●

Les serveurs doivent supporter les technologies de virtualisation assistées par le matériel, à savoir les technologies Intel VT ou AMDV.

●

Tous les nœ uds du cluster doivent avoir les mêmes architectures de processeurs.

●

Une architecture SAN FC ou iSCSI doit être en place et les services de cluster de Windows Server 2008 R2 doivent avoir été déployés.

●

Tous les nœ uds du cluster doivent avoir au moins deux cartes réseau, connectées sur des réseaux indépendants. Ces deux LAN ou VLANs permettent de supprimer un SPOF (Single Point of Failure), dans les environnements de production. Cependant, une seule carte et un seul réseau peuvent suffire au sein d’un environnement de test.

●

Une baie de stockage disque externe doit être connectée à tous les nœ uds du cluster pour être déclarée en tant que stockage au sein du cluster. Dans le cas des réseaux SAN iSCSI, il est recommandé de disposer d’une carte Ethernet Gb dédiée au réseau de stockage. Une carte réseau déjà existante peut aussi être suffisante au sein d’un environnement de test.

2. Création du Cluster Windows Server 2008 R2 Comme nous venons de le voir précédemment, la mise en œ uvre d’un cluster de basculement de serveurs à n nœ uds nécessite plusieurs étapes préparatoires. Ces étapes sont rappelées cidessous : ●

Étape 1 : phase de connexion de tous les serveurs du cluster aux différents réseaux et à l’infrastructure de stockage SAN.

●

Étape 2 : phase d’installation de la fonctionnalité de cluster de basculement, du rôle HyperV sur tous les nœ uds.

●

Étape 3 : phase de validation de la configuration du cluster.

●

Étape 4 : phase de création du cluster.

●

Étape 5 : phase de tests de validation du bon fonctionnement de tous les nœ uds au sein du cluster.

Les étapes préparatoires ayant été présentées précédemment, nous allons maintenant détailler la phase de création du cluster. Les tests finaux seront réalisés de manière pratique en déclarant une machine virtuelle au sein du cluster. - 2-

La fonctionnalité Quick Migration sera utilisée pour faire basculer à chaud la machine virtuelle entre deux nœ uds du cluster.

a. Lancement de l’assistant La configuration des services de cluster de Windows Server 2008 R2 est intégralement réalisée à l’aide du nouvel assistant intégré à Windows Server 2008 R2. Ce nouvel assistant est très intuitif et donc très simple à utiliser. L’ensemble des étapes de configuration est réalisé en quelques minutes. La figure suivante montre la nouvelle console MMC Gestion du cluster de basculement.

Lancement du nouvel Assistant Créer un cluster Quelques précautions sont à prendre avant de pouvoir créer un cluster de basculement. Il est au préalable nécessaire d’ajouter la fonctionnalité à l’aide du Gestionnaire de serveur Ajout de fonctionnalités. Les nœ uds du cluster doivent tous être configurés pour accéder au réseau de stockage SAN. De plus, avant de procéder à la création du cluster à l’aide de cet assistant, Microsoft recommande de réaliser la série de tests disponibles au travers de l’Assistant Validation d’une configuration. De cette manière, vous pourrez vous assurer en tout premier lieu que le matériel et les paramètres associés sont compatibles avec le clustering de basculement. Voici quelques détails de l’interface principale : ●

Les trois fonctions principales sont directement intégrées dans la console : Valider une configuration Créer un cluster Gérer un cluster.

●

Une aide très détaillée accompagne ces opérations.

●

Les liens Web vers le site Microsoft Technet « Rubriques relatives aux clusters de basculement », vers le site des « Communautés relatives aux clusters de basculement » ainsi que vers la page de support Microsoft sont directement intégrés dans l’interface.

- 3-

L’Assistant Création d’un cluster L’assistant permet la configuration des nœ uds distants ainsi que la déclaration du point d’accès pour l’administration du cluster.

Sélection des serveurs à intégrer dans le cluster à partir du domaine Active Directory MyCorp.net

b. Configuration du réseau Lors de cette étape de configuration, il est nécessaire de vérifier que les liaisons au niveau des différentes cartes réseau sont correctement ordonnées et que les cartes et paramètres TCP/IP des réseaux privé et public sont bien définis.

- 4-

Exemple de Rapport de validation du cluster de basculement Grâce à ce rapport, la bonne décision pourra être prise : plusieurs cartes réseau redondantes, configuration en « team », seront installées dans chaque serveur du cluster afin de garantir la séparation des trafics. Dans l’exemple cidessus, le rapport final de validation du cluster de basculement analyse l’ensemble des éléments de configuration. Le rapport met en évidence le fait que la plateforme déployée possède un point de défaillance unique, SPOF, au niveau de la connectivité réseau. En effet, la configuration n’est composée que d’une seule carte réseau utilisée pour les communications intracluster et vers le réseau de l’entreprise.

c. Création d’un nouveau cluster L’étape de création du cluster nécessite de fournir l’ensemble des informations de configuration. Cette opération est réalisée à l’aide de l’assistant Nouveau cluster. Le principe consiste à créer au minimum le premier nœ ud et à en valider la configuration à l’aide de la console MMC Gestion du cluster de basculement. L’étape de création du cluster permet de configurer plusieurs nœ uds en même temps. Cette méthode aboutira avec succès si tous les nœ uds sont correctement configurés. Il est donc préférable de commencer avec un ou deux nœ uds afin de valider le bon fonctionnement du cluster. Une fois cette étape réalisée, d’autres nœ uds pourront être ajoutés à l’aide de l’assistant Ajouter un nœ ud. À l’issue de cette dernière étape, un cluster Windows Server 2008 R2 à n nœ uds est disponible. Pour rappel, un cluster Windows Server 2008 R2 peut compter jusqu’à 16 nœ uds, avec ou sans le rôle HyperV, tandis que les versions Itanium et x86 supportent jusqu’à 8 nœ uds et ne disposent pas du rôle HyperV. La fenêtre qui suit déclare le point d’accès pour l’administration du cluster R2, lequel est composé du nom du cluster et de l’adresse IP qui lui est associée.

- 5-

Déclaration du point d’accès utilisé pour l’administration du cluster La figure suivante permet à l’administrateur de confirmer la création du nouveau cluster.

Page de confirmation avant la création du cluster

- 6-

Résumé des opérations réalisées par l’assistant

Notez le bouton Rapport qui permet d’afficher un rapport d’activité détaillé des opérations qui ont été réalisées par l’assistant. La figure suivante illustre ce rapport.

Compte rendu de l’opération de création du cluster

- 7-

d. Configuration des disques cluster L’accès au stockage partagé est nécessaire pour entreprendre et réussir la création d’un cluster. Il est donc indispensable de respecter toutes les consignes d’installation des contrôleurs ou cartes appropriées pour ce stockage : ●

Pour les architectures de types SAS (Serial Attached SCSI) ou Fibre Channel, il est important de vérifier que, sur tous les serveurs mis en cluster, les contrôleurs de périphérique de stockage mis en commun au niveau du cluster sont identiques et utilisent la même version de firmware.

Attention au fait que Windows Server 2008 R2 ne supporte plus les attachements directs de type SCSI parallèle entre les nœ uds du cluster et les baies de stockage.

●

Pour les architectures de type iSCSI, il est important de vérifier que, sur tous les serveurs mis en cluster, une ou plusieurs cartes réseau ou un ou plusieurs adaptateurs HBA (Host Bus Adapter), sont connectés à l’espace de stockage mis en cluster. Il est recommandé de ne pas utiliser les cartes réseau utilisées pour le trafic iSCSI pour des communications réseau LAN. De plus, toutes les cartes réseau utilisées pour le trafic iSCSI doivent être identiques et disposer d’un débit de type Gigabit Ethernet ou supérieur.

Attention au fait que dans le cas de la connectivité iSCSI, les attachements de type « Team » ne sont pas supportés. Pour plus de renseignements sur le support de iSCSI, référezvous au lien suivant : http://go.microsoft.com/fwlink/?LinkId=61375.

●

Nombre de disques vus par le cluster : un cluster doit contenir au moins un volume configuré en tant que disque témoin, ou quorum. Ensuite, concernant l’environnement de cluster associé au rôle Hyper, il faudra prévoir autant de volumes que nécessaire en fonction du nombre de machines virtuelles et des disques virtuels de cellesci.

●

Types de disques : les disques exposés aux services de cluster de Windows Server 2008 R2 doivent utiliser le type Disque de base, et pas dynamique, et être formatés en NTFS. Le type de partition des disques peut être de type MBR (Master Boot Record) ou GPT (GUID Partition Table).

●

Il est recommandé que les partitions supérieures ou égales à 4 To soient de type GPT.

●

La taille maximum d’une partition GPT est de 18 Eo, mais Windows Server 2008 R2 supporte 128 partitions de type GPT, chacune pouvant avoir une taille maximum de 256 To. Les partitions de type GPT ont fait leur apparition dans le cadre de l’initiative EFI (Extensible Firmware Interface). Ces nouvelles partitions sont beaucoup plus flexibles que les traditionnelles partitions de type MBR, datant du MSDOS. Au départ, principalement créée pour les processeurs Itanium d’Intel, l’interface EFI est aujourd’hui disponible pour les autres architectures de processeurs. Les partitions GPT permettent de s’affranchir des limitations imposées par le BIOS. Il est ainsi possible de créer plus de 4 partitions, de gérer quelque 18 Eo. De plus, la taille d’un cluster disque n’est plus dépendante de la taille des partitions.

●

Comme sous Windows Server 2003, Windows Server 2008 R2 prend en charge 4 partitions principales de type MBR. Pour convertir un disque MBR vers GPT ou l’inverse, le disque ne doit pas être partitionné. Si c’est le cas, il faut sauvegarder les données avant de supprimer les partitions. Enfin, via la console Gestion de l’ordinateur / Stockage, utilisez l’option Conversion en disque GPT. Il est aussi possible d’utiliser « diskpart » depuis l’invite de commande. Aujourd’hui, l’interface EFI fait l’objet d’un travail commun regroupant Intel, AMD, Apple, HP, IBM, Microsoft et Phoenix. Pour plus d’informations sur EFI et les partitions GPT, référezvous aux liens cidessous : http://www.intel.com/technology/efi et http://www.uefi.org.

Il faut s’assurer auprès des fournisseurs que le système de stockage, les contrôleurs, les pilotes, les versions de firmware ainsi que les logiciels utilisés pour le stockage sont compatibles avec les nouveaux services de cluster de Windows Server 2008 R2. En particulier, les nouvelles fonctions prises en charge par les services de cluster de Windows Server 2008 R2 nécessitent que le stockage supporte des commandes SCSI

- 8-

spécifiques, commandes SPC3, SCSI Primary Commands3 et que le pilote miniport utilisé pour le stockage fonctionne avec le pilote de stockage Microsoft Storport de Windows Server 2008 R2.

3. Création d’une machine virtuelle hautement disponible Une fois le cluster opérationnel, il est possible de commencer à y créer des services et des applications. Notre configuration va donc nous permettre de créer des machines virtuelles sur n’importe lequel des nœ uds du cluster et de déclarer les nœ uds pouvant être impliqués dans les fonctionnalités de basculement.

a. Création de la machine virtuelle La création de la machine virtuelle est réalisée à l’aide de la console de gestion MMC Gestionnaire HyperV et de l’assistant Nouvel ordinateur virtuel. Cet assistant permet de facilement créer une machine virtuelle en définissant l’ensemble de ces paramètres : nom de la machine virtuelle, emplacement disque, taille de la mémoire RAM, paramètres réseaux, etc. Attention ! Pour être déclarée au sein du cluster en tant que machine virtuelle hautement disponible, il est indispensable que la machine virtuelle réside sur un stockage réseau de type partagé accessible par tous les nœ uds du cluster.

b. Configuration en haute disponibilité via WSFC Une fois que la machine virtuelle existe sur le stockage partagé, celleci peut être déclarée et mise en œ uvre très simplement au sein du cluster. Le premier écran de l’assistant permet de sélectionner le type de ressource. Dans notre cas, il faudra sélectionner une ressource de type Ordinateur virtuel.

Sélection du type de service ou application à mettre en haute disponibilité Le deuxième écran de l’assistant permet de sélectionner la ou les machines virtuelles à mettre en configuration hautement disponible.

- 9-

Sélection des machines virtuelles à configurer en haute disponibilité (Quick ou Live Migration) La figure suivante crée et met en ligne les ressources nécessaires aux machines virtuelles configurées en haute disponibilité au sein du cluster.

Attention aux dépendances par rapport au stockage (disques locaux et disques SAN) L’Assistant de Haute Disponibilité est capable d’énumérer l’ensemble des machines virtuelles déclarées sur les nœ uds HyperV. Afin de réaliser facilement la sélection, le nom et l’état de la machine virtuelle ainsi que le nom de la machine hôte HyperV sont affichés. Notez que si vous sélectionnez plusieurs machines virtuelles, cellesci seront affectées au même objet mis en haute disponibilité classé sous Services et applications. Cela signifie que toutes les machines virtuelles sélectionnées seront gérées de manière unique avec les mêmes paramètres de basculement. Généralement, l’administrateur souhaite que chaque machine virtuelle gérée au sein du cluster dispose de sa propre

- 10 -

politique de gestion.

Configuration et mise en ligne des machines virtuelles des machines sélectionnées Une fois l’exécution du processus de configuration terminée, l’assistant affiche un compte rendu des opérations réalisées. Le bouton Afficher le rapport permet à l’administrateur d’accéder à un statut détaillé qui aidera à la résolution de certains problèmes de configuration.

Fin de la configuration et affichage du compte rendu

- 11 -

Compte rendu de la configuration réalisée Une fois la ou les machine(s) virtuelle(s) mise(s) en cluster, les différentes actions HyperV apparaissent dans la console Gestionnaire du cluster de basculement, de telle sorte qu’il est très facile pour l’administrateur d’accéder aux opérations essentielles.

- 12 -

Affichage de la machine virtuelle en cluster sous le nœud Services et applications L’interface expose les fonctions Start all virtual machines, Gérer un ordinateur virtuel, Turn Off, Shut Down, Save et aussi Move virtual machine(s) to another. La figure cidessus montre que la machine virtuelle Win2k3r264 est en cours de fonctionnement sur le nœ ud HV01 du cluster HVFCS01.MyCorp.net.

c. Paramètres de basculement des machines virtuelles en cluster Les paramètres de basculement d’un nœ ud à l’autre sont automatiquement configurés dès lors que le rôle HyperV est opérationnel sur le nœ ud et qu’il est possible d’y accueillir le groupe de ressources. La figure cidessous illustre les propriétés de la machine virtuelle win2k3r2x64.

- 13 -

Sélection des Propriétaires favoris et gestion des paramètres de basculement L’ensemble des nœ uds du cluster apparaît dans cette liste de sélection, de telle sorte que les machines favorites sont connues du cluster. Les machines sélectionnées seront donc choisies en fonction de la sélection et de l’ordre spécifiés. Mais que se passetil lorsqu’une défaillance se produit au niveau d’un nœ ud du cluster ou d’une machine virtuelle prise en charge par le cluster ? En fonction de la politique définie sur la ressource, celleci sera déplacée vers un autre nœ ud favori. Enfin, lorsque le nœ ud défaillant sera de nouveau dans un état opérationnel, et en fonction des paramètres de restauration automatique, la machine virtuelle pourra « retourner à sa place » sur la machine originale. La restauration automatique des ressources n’est pas activée par défaut. Il est donc nécessaire, en fonction de la stratégie de récupération que vous aurez définie, de configurer manuellement ces paramètres au niveau de chaque « service et/ou application, c’estàdire au niveau des machines virtuelles invitées » déclarées au sein du cluster. Dans la suite de ce paragraphe, un objet créé sous le nœ ud « Services et applications » dans la console MMC Gestion du cluster de basculement sera appelé "machine virtuelle". La fonction de restauration automatique n’est pas « nécessaire » du point de vue des services de haute disponibilité offerts par les services de cluster de basculement aux machines virtuelles HyperV. Elle permet de faire en sorte qu’un serveur préféré soit associé à une machine virtuelle particulière. Dans ce cas, une machine virtuelle ayant basculé vers un autre nœ ud suite à une défaillance du nœ ud de production, pourra automatiquement être redéplacée vers le nœ ud de production lorsque celuici sera à niveau disponible. La fenêtre de configuration Autoriser la restauration automatique permet d’activer ou non cette possibilité ainsi que de définir une plage horaire autorisée. Les figures qui suivent illustrent l’ensemble des propriétés de la machine virtuelle nommée « win2k3r2x64 » tel que résumé cidessous :

- 14 -

Options relatives à un objet de type Ordinateur virtuel

●

L’onglet Basculement permet de gérer le nombre de tentatives de redémarrage sur une période de temps donnée ainsi que la politique de restauration automatique.

- 15 -

Sélection des paramètres de basculement et de restauration automatique

●

- 16 -

L’onglet Dépendances permet de lister les dépendances et conditions composant la ressource mise en cluster. Dans cet exemple, on voit qu’il est nécessaire de disposer d’un objet de type Configuration d’ordinateur virtuel et aussi un objet de type disque.

Liste des ressources et dépendances entre les ressources

Le fait de spécifier des dépendances de ressources permet de contrôler l’ordre dans lequel le service de cluster les mettra en ligne et aussi hors connexion. Par définition, une ressource dite « dépendante » est mise en ligne seulement après la ou les ressource(s) dont elle dépend. À l’inverse, elle sera mise hors ligne avant la ou les ressource(s) dont elle dépend. Le fait de créer des dépendances entre les ressources permet d’imposer une organisation logique de cellesci sur la base des opérateurs « ET » et « OU ». La fonction Afficher le rapport de dépendance permet de visualiser l’ensemble des ressources liées.

Rapport de dépendance obtenu via la console Gestion du cluster de basculement

- 17 -

Vision logique des relations des ressources d’une machine virtuelle La nouvelle console MMC Gestion du cluster de basculement permet de générer un rapport de dépendance des ressources. Pour accéder à cette fonction, positionnezvous sur le service ou l’application mis en cluster puis déclenchez l’action « Afficher le rapport de dépendance ». ●

L’onglet Stratégies définit la stratégie de redémarrage des ressources, c’estàdire la politique de réponse à un échec. Par défaut, si la ressource en question est défaillante, il sera tenté de redémarrer sur le nœ ud actuel, une fois pendant une période de 15 minutes. Audelà, toutes les ressources nécessaires à l’application ou au service feront l’objet d’un basculement vers le nœ ud ordonné dans la liste des nœ uds favoris.

Paramètres de stratégie d’un ordinateur virtuel La figure cidessous illustre l’action qui sera entreprise lors de la mise hors connexion de la ressource de type machine virtuelle win2k3r2x64.

- 18 -

Option déclenchée lors du passage en mode hors connexion La figure ciaprès illustre les paramètres de stratégie avancée. ●

L’onglet Stratégies avancées définit quels nœ uds sont autorisés ou non dans la prise en charge de la ressource au sein du cluster. Les paramètres d’intervalles de vérification de bon fonctionnement de la ressource sont spécifiés à cet emplacement.

- 19 -

Paramètres de stratégie avancées La liste des propriétaires possible permet à l’administrateur du cluster de spécifier si oui ou non la ressource peut basculer vers tel ou tel nœ ud. Attention ! Si un seul et unique nœ ud est sélectionné, la ressource en question n’a plus la possibilité de basculer. De plus, Microsoft recommande de ne pas modifier les paramètres Intervalle de vérification de base d’intégrité de ressource et Intervalle de vérification approfondie d’intégrité de ressource.

Attention au fait que tous les paramètres présentés plus haut ont un effet direct sur le comportement du basculement des machines virtuelles entre les nœ uds du cluster. La modification de ces paramètres doit d’abord être réalisée sur une ressource de test afin de valider le comportement en cas de défaillance, nœ uds associés, nombre de tentatives de redémarrage, configuration de la restauration automatique, dépendances des ressources, stratégie de réponse aux échecs, actions à entreprendre lors de la mise hors connexion d’une ressource.

d. Quick Migration : déplacement à chaud d’une machine virtuelle Une fois le cluster Windows Server 2008 R2 configuré et une première machine virtuelle déclarée au sein de celuici, il faudra procéder à l’étape finale qui consiste tester la capacité de la plateforme à faire basculer ou à déplacer une machine virtuelle. Deux types de tests devront être réalisés : un test de déplacement manuel et un test de simulation de défaillance d’une ressource du cluster. Pour réaliser le test de déplacement manuel, vous pourrez procéder de la façon suivante :

- 20 -

■

À partir de l’un des nœ uds du cluster, d’un serveur Windows Server 2008 R2 ou d’un ordinateur Windows Vista disposant des outils d’administration à distance, ouvrez une session disposant des pouvoirs d’administration au sein du cluster Windows.

■

A l’aide de la console MMC Gestion de cluster de basculement, sélectionnez le cluster puis Services et applications « nom de la machine virtuelle ».

■

Dans la fenêtre centrale de la console, notez le propriétaire actuel de la machine virtuelle.

■

À l’aide la souris via le bouton droit, sélectionnez l’option Move virtual machine(s) to another node. L’opération de déplacement est alors démarrée.

Le groupe de ressources contenant la machine virtuelle est déplacé vers le nœ ud cible sélectionné et est disponible dès que l’interface graphique affiche un état Connecté, l’objet ordinateur virtuel affichant de son côté un état Running.

Opération de déplacement à l’aide du volet Actions Move virtual machine(s)

Attention au fait que la console Gestion du cluster de basculement ne propose pas de confirmation sur l’opération de déplacement. La figure suivante montre la progression de l’opération. Pour rappel, le déplacement de la machine virtuelle, à l’aide de la fonctionnalité Quick Migration nécessite la mise en mémoire de l’ordinateur virtuel. Cette opération gèle la machine virtuelle, puis copie son espace mémoire vers la ressource disque utilisée par la machine virtuelle.

Étape de Mise en mémoire de l’ordinateur virtuel Une fois la machine virtuelle mise en cache sur le disque SAN contenant la machine virtuelle, le cluster de basculement déplace l’ensemble des ressources vers le nœ ud spécifié pendant l’opération. Dans notre exemple, la ressource a été déplacée du nœ ud hv01 vers le nœ ud hv02.

- 21 -

Résultat du déplacement de la machine virtuelle vers le nœud hv02 Les tests de déplacement manuel ayant été réalisés avec succès, il est maintenant possible de réaliser des tests de simulation d’une défaillance sur les différentes ressources nécessaires au bon fonctionnement de la machine virtuelle. L’opération sera réalisée à l’aide de la console Gestion du cluster de basculement. Chaque ressource devra être « testée » pour valider que l’effet attendu tout en sachant que la détection d’une défaillance par le cluster aura pour effet de Redémarrer ou restaurer à son état initial la machine virtuelle afin qu’elle soit de nouveau disponible sur le nœ ud le plus favori. Lorsque le seuil du nombre de défaillances est atteint, la machine virtuelle est positionnée dans l’état Offline, déplacée vers un autre nœ ud disponible du cluster puis repositionnée dans l’état Online. Pour réaliser le test de simulation d’une défaillance, vous pourrez procéder de la façon suivante : ■

■

À l’aide de la console MMC Gestion de cluster de basculement, sélectionnez le cluster puis l’objet Nœuds.

■

À l’aide de la souris, via bouton droit Autres actions, accédez à la fonction Arrêtez le service de cluster.

Arrêt du service de cluster sur l’un des nœuds Le groupe de ressources contenant la machine virtuelle est alors automatiquement déplacé vers un nœ ud disponible du cluster. Le choix du nœ ud sera dépendant des noms des nœ uds du cluster déclarés en tant que Propriétaires favoris dans les propriétés du groupe de ressources de la machine virtuelle. À l’issue du déplacement, la machine virtuelle retrouvera son état Running.

- 22 -

L’arrêt du service cluster sur le nœ ud possédant des groupes de ressources provoque, en fonction de la stratégie définie sur chaque groupe de ressources, le déplacement ou non, desdits groupes. L’interface de la console permet de réaliser les tests de simulation au niveau des différentes ressources au sein du groupe. La figure cidessous illustre la simulation d’un échec sur la ressource Ordinateur virtuel.

Opération de Simulation d’un échec sur une ressource cluster

e. Maintenance des services de cluster Nous venons de voir qu’une solution HyperV hautement disponible nécessite plusieurs niveaux de configuration. Comme cela doit généralement être le cas, la maintenance matérielle et logicielle des différents nœ uds qui composent le cluster ne devra pas interférer avec la disponibilité des machines virtuelles prises en charge par Hyper V et les services de cluster de basculement de Windows Server 2008 R2. Pour réaliser les opérations d’entretien telles que les mises à jour de firmware, BIOS, Service Packs..., il est recommandé de réaliser les opérations suivantes : ■

Validez, à l’aide des éditeurs, constructeurs et partenaires, que les éléments remplacés ou mis à niveau sont bien supportés dans un environnement Windows Server 2008 R2 et dans le cadre des services de cluster de basculement de Windows Server 2008 R2 Edition Entreprise et Edition Datacenter.

■

A l’aide de la console MMC Gestion de cluster de basculement, sélectionnez le cluster et assurezvous que tous les groupes de ressources du nœ ud devant faire l’objet d’une opération de maintenance sont déplacés et opérationnels vers un autre nœ ud du cluster.

■

Toujours à l’aide de la console, sélectionnez le nœ ud du cluster devant faire l’objet d’une opération de maintenance, puis à l’aide du bouton droit de la souris, sélectionnez l’option Suspendre.

■

Une fois les opérations de maintenance réalisées, utilisez la même méthode que précédemment en sélectionnant l’opération Reprendre pour rendre à nouveau disponible le nœ ud au sein du cluster.

- 23 -

Suspension du service cluster pour les opérations de maintenance matérielles et logicielles

- 24 -

Architecture de System Center VMM 2008 R2 Microsoft System Center Virtual Machine Manager 2008, communément appelé VMM, est au cœ ur de la solution d’administration des platesformes de virtualisation basées sur Windows Server 2008 R2 HyperV. De plus, même si bien entendu HyperV est « la » plateforme de virtualisation préférée de Microsoft, l’accent a été mis pour être compatible aux autres technologies qui pourraient être présentes dans la salle machine. Ainsi, VMM 2008 R2 supporte les machines hôtes fonctionnant sous Virtual Server 2005 R2 EE mais aussi VMware ESX.

1. Fonctionnalités et scénarios d’usage de VMM 2008 R2 VMM 2008 R2 permet de centraliser l’administration de l’infrastructure, améliore le taux d’utilisation des machines hôtes et optimise les ressources prises en charge par les platesformes de virtualisation de Microsoft et de VMware. En tant qu’élément incontournable d’un environnement de virtualisation, Virtual Machine Manager peut être positionné au centre de la gamme de produits Microsoft System Center.

a. Fonctionnalités Les caractéristiques de Virtual Machine Manager permettent de répondre aux problématiques cidessous : ●

L’administration avancée des platesformes de virtualisation et des machines virtuelles fonctionnant sous Windows Server 2008 R2 HyperV, Microsoft HyperV Server 2008 R2, Windows Server 2008 HyperV, Microsoft HyperV Server 2008 et Microsoft Virtual Server 2005 R2.

●

L’administration des platesformes de virtualisation VMware ESX et ESXi.

●

La consolidation des serveurs physiques au sein d’une infrastructure de virtualisation via la prise en charge des fonctions de conversion des serveurs physiques en machines virtuelles, P2V et aussi V2V, au sein de l’infrastructure virtuelle.

●

Le support des configurations mettant en œ uvre les services de haute disponibilité « Quick Migration » et « Live Migration » de Microsoft et « VMotion » de VMware.

●

Le placement des machines virtuelles en fonction des charges et des contraintes de performance pour offrir aux administrateurs des Datacenter une administration des infrastructures de virtualisation plus dynamique via la technologie PRO (Performance and Resource Optimization). Cette technologie permet une répartition intelligente des charges virtuelles sur les serveurs hôtes les plus appropriés.

●

Le support natif de PowerShell pour réaliser l’automation des tâches d’administration.

●

La gestion centralisée des « objets » nécessaires à la gestion des environnements virtuels à l’aide des « Bibliothèques ».

Ces fonctionnalités permettent à VMM 2008 R2 de répondre à la totalité des scénarios d’usage pris en charge par les grandes platesformes de virtualisation. VMM peut être une bonne solution pour la consolidation des serveurs, la gestion standardisée des machines virtuelles, la fourniture des ressources matérielles et l’optimisation de cellesci au sein du Datacenter. En plus de ces grands scénarios, VMM 2008 R2 et les technologies de virtualisation prises en charge permettent à l’équipe informatique d’offrir une meilleure disponibilité des applications en contribuant à la mise en place de solutions hautement disponibles indépendantes des platesformes matérielles.

b. Avantages de la plateforme VMM Les points cidessous mettent en évidence les avantages les plus remarquables apportés par VMM 2008 R2. ●

VMM offre à l’administrateur du Datacenter une console unique pour gérer un environnement de virtualisation hétérogène : les nouvelles platesformes HyperV et l’ancienne solution de Microsoft, Virtual Server 2005. Il faut faire remarquer que VMM 2008 R2 permet aussi la gestion des environnements VMware VI3 via l’intégration avec Virtual Center. VMM supporte donc les fonctionnalités propres à VMware telles que VMotion, mais apporte également une plusvalue non négligeable en offrant des fonctions spécifiques VMM telles que le placement intelligent sur les serveurs VMware. VMM 2008 R2 intègre aussi les fonctions de conversion des

- 1-

systèmes virtuels VMware (transformation des VMDK en VHD) via un processus de conversion V2V (Virtual to Virtual). ●

VMM intègre un système de conversion rapide et fiable : la technologie incorporée à VMM utilise le service de cliché instantané VSS de Windows (Virtual Shadow Services). La création de la machine virtuelle est ainsi plus rapide et peut être réalisée On Line, sans interrompre le serveur source physique.

●

VMM permet le placement intelligent des machines virtuelles sur les meilleures machines hôtes Microsoft et non Microsoft : lorsqu’un administrateur VMM décide de déployer une machine virtuelle, VMM utilise les données de performance et les ressources nécessaires, pour la machine virtuelle et aussi pour la machine hôte. Cette méthode permet d’obtenir un placement réellement adapté à la situation. Ce processus maximise l’utilisation des ressources physiques en équilibrant les charges des hôtes physiques ou en optimisant l’utilisation des ressources au sein d’un hôte particulier.

●

VMM permet l’administration centralisée des ressources : la nouvelle console Administrateur VMM permet de gérer l’ensemble des ressources virtuelles. La console intègre la possibilité de déplacer les machines virtuelles à chaud en minimisant l’indisponibilité de cellesci qu’il s’agisse de machines virtuelles VMware, via VMotion, ou de machines virtuelles HyperV, via Quick Migration et Live Migration sur les machines hôtes fonctionnant sous Windows Server 2008 R2.

●

VMM permet aux administrateurs de progresser au niveau du déploiement des serveurs : le déploiement des nouveaux serveurs est rapide pour les administrateurs et les utilisateurs autorisés. De plus, l’optimisation des serveurs est plus facile grâce à la surveillance des ressources et des événements via SCOM 2007 SP1.

●

VMM supporte la technologie PRO (Performance Resource Optimization) : cette fonction permet de s’assurer que les machines virtuelles fonctionnent de manière optimisée en réagissant dynamiquement en fonction de règles aux problèmes de performances. Cette technologie est ouverte et extensible de telle sorte que des solutions tierces puissent s’intégrer au dessus de VMM.

●

VMM supporte la notion de bibliothèque centralisée : une bibliothèque centralisée contient tous les composants d’un centre de données virtuel. L’administrateur pourra y ranger des éléments tels que des disques durs virtuels, des images ISO, des scripts de personnalisation, des configurations matérielles, des modèles, etc.

●

VMM utilise la notion de modèles : pour permettre aux administrateurs de déployer rapidement tous types de serveurs, VMM supporte les modèles de machines virtuelles. Un modèle contient des paramètres matériels et systèmes afin d’offrir une grande cohérence au sein du Datacenter.

●

VMM peut assurer la supervision centralisée des hôtes, des machines virtuelles et des applications : VMM étend les services de virtualisation d’HyperV et de VMware via l’intégration avec System Center Operations Manager 2007. Une fois les charges regroupées au sein de l’infrastructure virtuelle, VMM génère des rapports et utilise les données de performances remontées par SCOM. L’intégration de SCOM est très importante car elle permet à VMM d’utiliser la technologie PRO, et de superviser le bon fonctionnement et les performances des machines virtuelles et des applications installées au sein des machines virtuelles.

●

VMM permet la délégation des opérations VMM : le rôle Administrateur délégué permet de définir les tâches et fonctions attribuées à chaque administrateur VMM. La délégation est en général utilisée dans des environnements de tests lorsqu’il est nécessaire de créer et supprimer des machines virtuelles de manière répétitive. Ces opérations peuvent être réalisées à l’aide du nouveau portail Web en libreservice de VMM 2008 R2.

●

VMM tire parti des compétences existantes sur Windows Server : VMM est une application et System Center. Cela réduit au minimum les besoins en formation des administrateurs et du personnel du support technique.

●

VMM utilise au maximum la nouvelle interface de ligne de commande Windows PowerShell : les administrateurs peuvent utiliser et développer des scripts puissants basés sur plus de 170 cmdlets, et autres exemples disponibles sur le site de Microsoft.

c. Scénarios VMM SCVMM 2008 R2 est une solution qui est adaptée à de nombreux cas de mise en œ uvre des technologies de virtualisation. Plusieurs scénarios principaux sont identifiables parmi lesquels une gestion « industrielle » de la consolidation des serveurs, la possibilité de fournir l’ensemble des ressources virtuelles nécessaires aux machines virtuelles, la capacité à obtenir les meilleures performances des matériels en s’assurant que les machines virtuelles disposent du meilleur environnement d’exécution. Enfin, l’un des scénarios intéressant le plus les entreprises

- 2-

aujourd’hui concerne la mise en œ uvre d’un plan de reprise d’activité pour répondre aux situations de crises particulières. Ces différents scénarios sont présentés cidessous. ●

SCVMM et la consolidation des serveurs : la consolidation des serveurs est certainement le scénario qui intéressera en tout premier lieu les entreprises. En minimisant de manière importante le nombre des serveurs physiques, l’entreprise peut « instantanément » engager un processus de réduction des coûts très important. Les économies en matériels, en contrat de maintenance et de support, en consommation électrique, en énergie nécessaire au refroidissement des serveurs et aussi en m 2 sont substantielles ! ●

La première étape consistera à mettre en place une politique de virtualisation des serveurs.

●

La deuxième étape consistera à mettre en œ uvre de manière progressive la nouvelle plateforme.

Une approche douce permettra de prendre possession de la nouvelle plateforme et d’en maîtriser les nouvelles technologies qui lui sont associées tandis qu’une approche plus volontaire consistera à mettre en place un véritable projet de consolidation des serveurs. Les meilleurs candidats à la virtualisation seront alors identifiés et associés aux meilleures ressources matérielles disponibles. ●

SCVMM et la gestion des ressources virtuelles :un autre scénario intéressant est la possibilité offerte par VMM de permettre aux équipes informatiques de disposer d’un « pool de ressources matérielles » rapidement affectables à différents types de besoins. La fourniture d’un serveur virtuel, disposant de ressources adaptées à l’usage qui en sera fait, peut être réalisée en quelques minutes. À l’inverse, la mise en œ uvre d’un serveur physique pourra nécessiter plusieurs semaines, de la demande d’achat à sa livraison dans la salle machine.

●

SCVMM et l’optimisation des ressources matérielles : cet aspect de la virtualisation est certainement un point qui permettra aux administrateurs des environnements de virtualisation de se sentir « rassurés ». En effet, il ne serait pas raisonnable de confier à une machine hôte particulière n machines virtuelles sans s’assurer que les charges de chacune de ces machines virtuelles ne puissent réellement être supportées. Pour répondre à cette problématique, la technologie PRO permet de s’assurer que la machine hôte physique est capable de faire fonctionner correctement les machines virtuelles de la meilleure manière. Cette technologie s’appuie sur System Center Operations Manager 2007 SP1. Cette solution de supervision prend en charge les machines hôtes, les machines virtuelles ainsi que les applications disposant d’un pack d’administration pour SCOM. L’utilisation de PRO nécessite donc que SCOM soit configuré de manière à ce qu’il interagisse avec VMM.

●

SCVMM et la prise en charge d’un PRA : nous avons vu précédemment qu’HyperV utilisait les services de basculement de Windows Server 2008 R2 pour implémenter une protection totale des machines virtuelles hébergées sur les machines hôtes HyperV. Cependant, certaines entreprises nécessitent aujourd’hui la capacité de redémarrer tout ou partie de leur activité sur un site distant, dans le cas où un événement catastrophique se produirait. La technologie de virtualisation HyperV associée aux services A WSFC (Windows Server Failover Clustering), peut participer pour tout ou partie à la mise en œ uvre d’une solution de repli efficace. L’une des raisons les plus évidentes qui permettent cette possibilité est la portabilité des serveurs. En effet, une machine virtuelle peut non seulement être déplacée vers une autre machine hôte mais peut aussi être répliquée en temps réel vers un autre serveur distant aussi facilement qu’un simple fichier. Des solutions telles que SteelEye DataKeeper Cluster Edition ou encore DoubleTake for HyperV permettent de répliquer en temps réel des machines virtuelles localement ou sur un site géographique distant. Un des avantages les plus importants de ces solutions logicielles est qu’elles ne nécessitent pas la mise en œ uvre de solutions matérielles propriétaires.

Ces méthodes logicielles sont très intéressantes car elles ne sont pas basées sur des outils de sauvegardes ou des outils de réplications intégrés aux architectures SAN. Il n’y a aucune dépendance par rapport au stockage ce qui permet aux administrateurs d’utiliser toutes les ressources disponibles du site distant. Un autre avantage apporté par ces solutions « spécialisées HyperV » est la possibilité d’appliquer des niveaux de protection particuliers sur la base de chaque machine virtuelle. Pour plus de renseignements sur ces produits additionnels, utilisez les liens cidessous : http://www.doubletake.com/english/products/doubletake virtualization/Pages/DoubleTakeforHyperV.aspx et http://www.steeleye.com/products/virtual/

2. Objets et terminologie VMM Les objets pris en charge par VMM 2008 R2 sont directement identifiables au sein de la console Administrateur VMM. Le volet de navigation de la console permet par exemple à l’administrateur de sélectionner les types d’objets qu’il souhaite afficher, ainsi la sélection en est grandement simplifiée. L’interface permet de sélectionner les types d’objets en rapport avec les rubriques fonctionnelles cidessous :

- 3-

●

Les ordinateurs hôtes ;

●

Les ordinateurs virtuels ;

●

Les bibliothèques ;

●

Les travaux ;

●

L’administration ;

●

La création de rapports.

Ces différents types d’objets sont définis plus bas.

a. Les ordinateurs hôtes Un ordinateur hôte est un ordinateur capable de prendre en charge une ou plusieurs machines virtuelles. VMM 2008 R2 prend en charge les serveurs Windows Serveur 2008 R2 et non R2 disposant du rôle HyperV, les serveurs Microsoft HyperV Server 2008 R2 et non R2, les serveurs exécutant Microsoft Virtual Server 2005 R2 EE et les serveurs fonctionnant sous VMware ESX. Les machines hôtes peuvent être facilement ajoutées à l’aide de la console Administrateur VMM et de l’assistant Ajouter un ordinateur hôte.

Utilisation de l’assistant Ajouter des ordinateurs hôtes

b. Les ordinateurs virtuels Cette rubrique de la console permet à l’administrateur d’accéder aux différents groupes de machines hôtes et ainsi, aux machines virtuelles hébergées sur chaque machine hôte. L’administrateur a la possibilité de créer de multiples groupes de machines hôtes afin d’en gérer globalement certaines propriétés. Il est par exemple possible de spécifier les réserves de ressources des machines hôtes (pourcentages de temps processeur, de mémoire RAM, d’espace disque, de capacité d’entréessorties disques et la capacité réseau).

- 4-

La définition de quotas de ressources est utile lorsque des machines virtuelles sont placées sur une machine hôte. Une machine virtuelle ne pourra pas être placée sur un hôte, à moins de pouvoir répondre à ses besoins en ressources, sans utiliser les réserves définies pour l’hôte.

Propriétés d’un groupe de machines hôtes : Réserve de ressources de l’ordinateur hôte au niveau CPU, mémoire, espace disque et I/O disques et bande passante réseau

c. Les bibliothèques Les bibliothèques sont des objets pris en charge par les serveurs de bibliothèque, ces derniers contenant d’autres objets appelés Partages de bibliothèques. Les bibliothèques sont donc des conteneurs contrôlés par le serveur VMM 2008 R2. Ces conteneurs peuvent stocker des machines virtuelles, des disques virtuels, des fichiers .iso (images CD/DVD Microsoft et autres), des fichiers de configuration et de personnalisation des machines virtuelles, des configurations matérielles et aussi des modèles VMM. Tous les objets contenus dans les bibliothèques sont disponibles au travers de l’interface Administrateur VMM pour servir d’éléments de base utiles à la création et au déploiement des machines virtuelles.

- 5-

Vue des objets contenus dans un serveur de bibliothèque VMM 2008 R2

d. Les travaux Plusieurs administrateurs VMM peuvent être amenés à réaliser de multiples tâches simultanément. L’ensemble des tâches réalisées est mis en œ uvre et consigné sous la forme de travaux. Ainsi, un travail sera créé pour toute action qui modifie l’état d’un objet managé par VMM et un suivi détaillé sera possible au sein de la console Administrateur VMM dans la vue Tâches. Les différents types de travaux sont réalisables par l’interface Administrateur VMM 2008 R2 mais aussi via une ou plusieurs cmdlets PowerShell. De cette manière, les administrateurs VMM ont la possibilité d’effectuer toutes les actions de la console Administrateur VMM à partir de la ligne de commande, et d’écrire des scripts complexes pour réaliser l’automation des opérations d’administration les plus fréquentes. La figure cidessous illustre une suite de travaux VMM au sein de l’interface Administrateur VMM.

Exemple d’une vue de type Travaux pour une conversion P2V Les travaux décomposent les différentes étapes effectuées de manière séquentielle pour exécuter une action. Un travail simple, tel que par exemple, l’arrêt d’une machine virtuelle, ne comporte qu’une seule étape. Dans le cas de

- 6-

travaux plus complexes, tels que l’exécution d’une conversion P2V, conversion d’un ordinateur physique en une machine virtuelle sur un serveur, le travail à réaliser est une suite de travaux organisés appelés Groupe de travaux. Le groupe de travaux est ensuite à son tour composé de plusieurs étapes. Les administrateurs disposent donc d’un suivi très détaillé.

e. L’administration Cette partie de la console Administrateur VMM fournit un accès à l’ensemble des paramètres de configuration de VMM 2008 R2 : paramètres de base de données et des bibliothèques, déclaration des ports réseaux utilisés pour les connexions de contrôle à distance, choix de la stratégie de sélection élective (mode équilibrage de charge ou maximisation des ressources), activation des conseils PRO. Cette rubrique permet aussi de déclarer les rôles des utilisateurs VMM déclarés à partir d’Active Directory et de configurer l’intégration VMM 2008 R2 / SCOM 2007.

f. La création de rapports Cette partie de la console permet d’afficher, d’imprimer et d’exporter des rapports à partir de la vue Création d’un rapport de la console Administrateur VMM. L’affichage et l’utilisation des rapports au sein VMM ne sont possibles que si et seulement si : ●

System Center Operations Manager 2007 SP1 est configuré.

●

Le serveur de rapport de SCOM 2007 est opérationnel.

●

La création des rapports dans VMM est activée.

De plus, pour qu’ils puissent afficher et ouvrir les rapports VMM, il faudra accorder aux utilisateurs le rôle Opérateur de rapports dans Operations Manager. D’autres objets spécifiques à l’environnement d’administration VMM facilitent les opérations d’administration des machines virtuelles. Ces objets sont présentés dans les paragraphes suivants.

g. Les profils de système d’exploitation invité Ce type d’objet permet de regrouper un ensemble de paramètres standard permettant la personnalisation du système d’exploitation invité qui sera ensuite déployé en tant que machine virtuelle. Ces profils peuvent ensuite être importés dans les modèles d’ordinateurs virtuels. Un profil de système d’exploitation invité peut être comparé à un fichier de réponse de type Sysprep.inf ou Unattend.xml. Il peut contenir des informations telles que : ●

le nom de l’ordinateur (ou * pour générer automatiquement un nom d’ordinateur unique),

●

le mot de passe de l’administrateur,

●

la clé du produit,

●

le fuseau horaire,

●

la version de système d’exploitation,

●

les paramètres d’appartenance à un domaine Active Directory ou à un groupe de travail.

Il est aussi possible d’attacher un fichier de réponse, de type Sysprep.inf pour Windows XP, Windows 2000 et Windows Server 2003 ou de type Unattend.xml pour Windows Vista et Windows Server 2008 R2, et de déclarer une liste de commandes à exécuter la première fois qu’un utilisateur se connecte à une machine virtuelle, cette dernière opération correspond à la section [GuiRunOnce] du fichier SysPrep. L’importation d’un profil de système d’exploitation dans un modèle, puis l’utilisation de ce modèle pour la création des machines virtuelles, permet de garantir des configurations homogènes pour chaque machine virtuelle créée à partir du modèle.

- 7-

Exemple de profil de système invité au sein de VMM 2008 R2 Les profils de système d’exploitation invités résident directement au sein de la base de données VMM aucun fichier physique ne leur est associé. Les profils sont gérés à partir de la vue Bibliothèque, où ils apparaissent dans le dossier spécial nommé Ordinateurs virtuels et modèles.

h. Les profils matériels Ce type d’objet permet de regrouper un ensemble de paramètres standard qui permet de définir les caractéristiques matérielles d’une machine virtuelle tels que le type de processeur, la mémoire RAM, les interfaces disques et DVD et les interfaces réseau. Les paramètres du profil matériel définissant une machine virtuelle peuvent être modifiés à tout moment. Les profils matériels ne sont considérés qu’au moment de la création d’une machine virtuelle. Aucune relation n’est conservée après la création de la machine virtuelle de telle sorte que les profils matériels peuvent être modifiés sans aucune incidence sur les machines virtuelles.

- 8-

Exemple de profil matériel au sein de VMM 2008 R2

Un profil matériel peut être créé de toutes pièces au sein d’une bibliothèque, mais peut aussi être basé sur la configuration matérielle d’une machine virtuelle ou d’un modèle.

i. Les ordinateurs virtuels stockés Il s’agit simplement d’une machine virtuelle dont les fichiers de disques, fichiers .vhd, et les propriétés sont stockés dans une bibliothèque VMM. Une fois placée dans une bibliothèque, la machine virtuelle peut être déployée à l’aide de l’assistant Déployer l’ordinateur virtuel. Pour être placée dans une bibliothèque, une machine virtuelle doit être en état arrêté ou enregistré. Dans ce dernier cas, l’état de la machine virtuelle est déplacé dans le partage de bibliothèque avec la machine virtuelle.

- 9-

Objets de la bibliothèque : machine virtuelle stockée et opération Déployer

Attention : le déploiement, ou la migration via Quick Migration, d’une machine virtuelle depuis un serveur de bibliothèque vers une machine hôte fonctionnant sous Windows Server 2008 nécessite que l’architecture processeur deux machines hôtes soit compatible. Windows Server 2008 R2 et SCVMM 2008 R2 supportent désormais des machines hôtes utilisant des processeurs différents au sein de la même famille de processeurs (famille Intel ou famille AMD). Ce point est présenté en détail au chapitre Fonctionnalités avancées d’HyperV v2.

j. Les modèles Le type d’objet Modèle est certainement le plus pratique pour l’administrateur VMM. Cet objet est la combinaison d’un profil de système d’exploitation invité, d’un profil matériel et d’un ou de plusieurs fichiers de disques virtuels (fichiers .vhd). Les modèles sont utilisés pour créer régulièrement de nouvelles machines virtuelles répondant à des paramètres matériels et logiciels standardisés. Il faut noter que les utilisateurs du portail libreservice VMM doivent créer leurs machines virtuelles sur la base des modèles qui leur sont affectés. L’administrateur VMM a la possibilité d’utiliser un disque dur virtuel « généralisé » à partir de la bibliothèque ou bien de créer un disque dur virtuel à partir d’un ordinateur virtuel existant. Pour simplifier le processus de généralisation (utilisation de Sysprep), il faut prendre soin d’ajouter tous les modules et outils nécessaires, services d’intégration HyperV, antivirus, etc., devant être disponibles dans la machine virtuelle. Pour préparer le disque dur virtuel source, il faut supprimer les informations d’identité d’ordinateur à l’aide de la commande Sysprep, puis ajouter le fichier du disque dur virtuel à la bibliothèque. Enfin, le modèle pourra être créé sur la base du disque dur virtuel préparé via le menu Actions Nouveau modèle.

- 10 -

Création d’un nouveau modèle d’ordinateur à partir d’un disque virtuel ou d’un ordinateur virtuel de la bibliothèque Lorsque le modèle créé ne contient pas de profil de système d’exploitation, ces informations devront être renseignées manuellement au moment de la création de la machine virtuelle basée sur ce modèle. De même, lorsque l’assistant Nouvel ordinateur virtuel est invoqué et qu’un modèle est sélectionné à partir de la bibliothèque, les paramètres de l’ordinateur virtuel pourront être remplacés au dernier moment. Une nouvelle machine virtuelle créée sur la base d’un modèle ne peut pas être directement rangée dans une bibliothèque. La machine virtuelle doit au préalable être placée sur une machine hôte car l’étape de personnalisation ne peut être réalisée hors connexion.

3. Composants et architecture de VMM Comme nous venons de le voir, VMM 2008 R2 fait partie de la famille des produits serveur, System Center. De fait, l’architecture de VMM est dimensionnée pour répondre aux besoins des entreprises de toutes tailles. Ainsi, une seule instance VMM 2008 R2 est validée et testée par Microsoft pour supporter jusqu’à 400 machines hôtes et 8000 machines virtuelles en fonctionnement sur ces machines hôtes.

a. Introduction VMM 2008 R2 est composé de multiples composants qui incluent au cœ ur de la solution les services suivants : ●

Le service Virtual Machine Manager (VMMService), agissant en tant que serveur « System Center Virtual Machine Manager 2008 R2».

●

Une base de données Microsoft SQL Server 2005 ou 2008 contenant l’ensemble des objets gérés par VMM.

●

Le service Virtual Machine Manager Agent (VMMAgent), responsable de toutes les opérations à réaliser sur les machines hôtes fonctionnant sous Windows Server 2008 R2 et non R2 HyperV, HyperV Server 2008 R2

- 11 -

et non R2 et Virtual Server 2005 R2 EE. ●

Le service Virtual Machine Manager Agent (VMMAgent), responsable de la gestion des serveurs de bibliothèques contenant l’ensemble des ressources utilisées dans l’environnement VMM sous la forme d’objets.

●

Les serveurs Web assurant la fonction de Portail LibreService Virtual Machine Manager pour permettre aux utilisateurs autorisés à créer et gérer leurs propres machines virtuelles.

●

Les machines d’administration sur lesquelles la console d’administration de VMM 2008 R2 est installée. Ces machines disposent de l’interface graphique et des commandes PowerShell nécessaires à la gestion de l’infrastructure virtuelle composée des machines hôtes et des machines virtuelles.

b. Modèle d’architecture, services et ports utilisés Comme pour les produits de la famille Windows Server et System Center, VMM 2008 R2 est construit sur la base d’une architecture modulaire. Cette architecture est composée de trois couches communicantes via des interfaces disponibles pour les développeurs qui souhaitent étendre la plateforme. Ces différentes couches et interfaces sont présentées cidessous. ●

Windows Remote Management : WinRM est l’implémentation Microsoft du protocole WSManagement. Ce protocole permet l’administration des serveurs, des équipements réseau et l’administration à distance des matériels et des systèmes d’exploitation dans un environnement hétérogène. WinRM est basé sur un modèle client/serveur utilisant le protocole HTTP comme transport. De son côté, VMM 2008 R2 utilise WinRM pour les communications entre le serveur VMM, les hôtes HyperV et Virtual Server 2005, et les serveurs de bibliothèques.

WSManagement est un protocole standard ouvert publié en version 1.0 en 2008 par le DMTF (Desktop Management Task Force). Ces travaux ont été au départ initialisés par AMD, Dell, Intel, Microsoft et Sun Microsystems. WS Management fournit une méthode unifiée pour échanger des informations d’administration à distance en supportant plus que de simples accès en lecture/écriture sur des variables. De fait, ce standard est très proche de WBEM. Une correspondance entre la structure des données de type CIM (Common Information Model) vers WSManagement a aussi été définie. Windows Server 2008 R2 et Windows Vista supportent nativement WinRM tandis que Windows XP et Windows Server 2003 le supportent via une mise à jour disponible sur le site de Microsoft. La version Suse Linux Enterprise 11 de Novell vient aussi d’implémenter la spécification WSManagement.

●

Windows Communications Foundation : Windows Communication Foundation (WCF) est le modèle de programmation unifié de Microsoft. Il permet de générer des applications orientées service et des solutions transactionnelles sécurisées telles que SCVMM. Les applications WCF utilisent des fonctionnalités WCF telles que : ●

les points de terminaison

●

le transfert de données et la sérialisation,

●

les sessions et accès concurrentiel,

●

les transports WCF,

●

les files d’attente,

●

les transactions,

●

les services de confidentialité et d’intégrité ainsi que des métadonnées.

De plus, l’interface de programmation WCF peut être utilisée pour étendre la logique existante sans nécessiter la réécriture d’une application existante. Ce point est important pour les développeurs qui ont beaucoup investi sur des composants COM+. Pour plus d’informations sur WCF, connectezvous sur le site MSDN, http://msdn.microsoft.com, et recherchez WCF.

- 12 -

●

La figure cidessous illustre l’architecture modulaire de VMM 2008 R2 ainsi que ses différentes couches et interfaces. Notez que les transferts de données entre les serveurs hôtes et les serveurs de bibliothèques utilisent le protocole BITS (Background Intelligent Transfer Service).

Architecture de Microsoft System Center Virtual Machine Manager 2008 R2

c. Le serveur Virtual Machine Manager VMMService Le serveur VMM est au centre de la configuration VMM 2008 R2. Au travers de ce service, l’ensemble de tous les autres composants de la solution VMM pourra communiquer et échanger les données nécessaires à la plateforme. Une fois installé, le serveur VMM 2008 R2 est opérationnel et il peut prendre en charge le contrôle des communications avec les autres composants VMM, l’exécution de commandes à distance, le transfert des données entre les machines hôtes, les machines virtuelles et les serveurs de bibliothèque VMM... Dans le cadre de son fonctionnement, le serveur VMM doit accéder à une base de données SQL Server dont le rôle est de contenir toutes les informations de configuration du serveur VMM et de l’environnement pris en charge. L’ensemble de ces informations est accessible via la console d’administration VMM ou à l’aide de l’environnement de commande PowerShell. À l’issue de l’installation de SC Virtual Machine Manager 2008, le serveur VMM est également considéré comme le serveur de bibliothèque par défaut. Nous verrons plus loin que les bibliothèques VMM sont très utiles pour regrouper l’ensemble des ressources nécessaires aux machines virtuelles. Il pourra s’agir, par exemple, de disques durs virtuels disponibles, d’images ISO, de modèles de machines virtuelles, de scripts PowerShell, de fichiers de réponses et aussi de machines virtuelles « complètes » utilisées comme modèles. L’administrateur de VMM 2008 R2 aura ensuite la possibilité de déclarer d’autres serveurs de bibliothèque pour prendre en charge plus facilement un plus grand nombre de machines hôtes.

d. Le serveur de bases de données SQL Server de VMM Le serveur Virtual Machine Manager nécessite une base de données Microsoft SQL Server. Cette base de données sera spécifiée au moment de l’installation du serveur VMM. Une fois opérationnelle, la base de données VMM stocke toutes les informations de configuration de l’environnement de virtualisation pris en charge. Comme pour d’autres produits de la famille System Center, par exemple SCOM 2007 ou SCCM 2007, il est nécessaire de s’assurer que la version utilisée de Microsoft SQL Server est bien une version supportée. VMM 2008 R2 supporte les versions suivantes de Microsoft SQL Server :

- 13 -

●

SQL Server 2008 Express Edition et SQL Server 2005 Express Edition SP2,

●

SQL Server 2008 (32 et 64 bits) Editions Standard et Entreprise,

●

SQL Server 2005 (32 et 64 bits) Edition Standard et Entreprise SP2.

L’assistant d’installation de System Center Virtual Machine Manager 2008 vous proposera de spécifier le type d’instance SQL à utiliser : une instance SQL locale ou bien une base de données Microsoft SQL Server située sur un autre serveur. L’assistant d’installation de System Center Virtual Machine Manager 2008 propose aussi l’installation sur le serveur VMM d’un serveur SQL Server 2005 Express Edition SP2 auquel sont ajoutés les outils SQL Server 2005. Par défaut, la création de cette instance SQL Server sur le serveur VMM est appelée MICROSOFT$VMM$. Attention au fait que les versions SQL Server Express Edition ne prennent pas en charge les rapports de VMM 2008 R2.

La version gratuite de SQL Server est limitée à 1 processeur ainsi qu’à une taille de base de données de 4 Go au maximum. De plus, SQL Server 2005 Express Edition est supporté sur les platesformes systèmes x64 et EMT64 via le soussystème WoW (Windows on Windows).

Si vous prévoyez de gérer plus de 150 machines hôtes et/ou d’intégrer System Center Operations Manager 2007 à VMM 2008 R2 pour implémenter les rapports et les conseils PRO, il est recommandé d’utiliser SQL Server Edition Standard ou Enterprise.

4. Ports utilisés par VMM 2008 R2 Les communications entre la console Administrateur VMM, le portail selfservice, les serveurs de bibliothèques, les machines hôtes HyperV ou VMware ESX sont implémentées via l’utilisation de ports TCP. Le fait que chaque composant spécifique de VMM utilise des ports particuliers signifie qu’ils sont positionnés sur des machines différentes, le Parefeu Windows ainsi que les parefeu du réseau d’entreprise devront être configurés pour activer les communications au travers de ces ports. Lorsque le Parefeu Windows est activé sur un serveur où des composants de VMM 2008 R2 sont installés, le programme d’installation de VMM 2008 R2 déclare et active automatiquement les exceptions nécessaires. Les ports utilisés par les différents composants de VMM sont présentés cidessous : Communications

Ports utilisés

Serveur VMM

80 / HTTP / WinRM 443 / BITS 8100 / WCF Connexions vers la console Administrateur VMM et PowerShell.

Serveur de Bibliothèque VMM

80 / HTTP / WSMAN (WinRM)

Machines virtuelles hébergées sur machines hôtes

443 / HTTPS / BITS 3389 / RDP 2179 / VMConnect 5900 / VMRC

Microsoft SQL Server

1433 / Connexion à distance SQL Server 1434 / SQL Browser service

Serveur VMware Virtual Center

- 14 -

443 / HTTPS Appels des services Web (Virtual Infrastructure)

Machines Hôtes VMware ESX (HTTPS)

443 Appels des services Web (Virtual Infrastructure) 22 / SSH (non nécessaire pour les machines hôtes ESXi)

Serveur VMM vers Agent VMM Contrôle (WinRM)

Serveur VMM vers Agent VMM Data (BITS)

443

Serveur VMM vers SQL Server (HTTP)

1433

Serveur VMM vers Source P2V (WinRM)

135

Console Administrateur vers Serveur VMM (WCF)

8100

Console Admin. vers Portail Selfservice VMM (WCF)

Serveur de bibliothèques vers machine hôte (BITS)

Machine hôte vers machine hôte (BITS)

Session Portail Selfservice vers machine hôte HyperV 3389 (RDP) Session Portail Selfservice vers machine hôte Virtual Server 2005 (VMRC)

5900

Vue Rapports de la console Administrateur VMM vers serveur de rapports SCOM 2007 (HTTP)

VMConnect pour hôtes HyperV

2179

5. Nouveautés de VMM 2008 R2 SCVMM 2008 R2 est une solution de management capable de prendre en charge des environnements complexes hétérogènes composés de machines hôtes fonctionnant sous Windows Server 2008 R2 HyperV, Virtual Server 2005 R2 EE et VMware ESX via VMware Virtual Center. Les nouvelles fonctionnalités prises en charge par Windows Server 2008 R2 nécessitent l’utilisation de SCVMM 2008 R2. Cette nouvelle version de VMM tire parti des nouvelles améliorations de la plateforme et améliore sensiblement l’ensemble des fonctionnalités de VMM. Avant la sortie de VMM 2008 R2, vous trouverez cidessous les évolutions les plus importantes incorporées à cette nouvelle version : ●

Intégration de Live Migration : directement disponible via la console VMM, cette nouvelle fonctionnalité permet de déplacer à chaud sans aucune coupure, des machines virtuelles d’un hôte vers un autre hôte du cluster. En offrant aux administrateurs une plus grande souplesse, la nouvelle version de Windows Server 2008 R2 avec HyperV associée à VMM 2008 R2 permet de mieux prendre en charge les arrêts planifiés et non planifiés.

La nouvelle fonctionnalité Live Migration nécessite que les différentes machines hôtes HyperV fassent partie d’un cluster Windows Server 2008 R2 Edition Entreprise ou Datacenter. Il faut aussi veiller à ce que tous les processeurs proviennent du même fabricant, c’estàdire Intel ou AMD. Bien entendu, tous les nœ uds du cluster doivent avoir un ou plusieurs accès à l’infrastructure de stockage partagé.

La mise à niveau de Windows Server 2008 vers Windows Server 2008 R2 ne nécessite aucun changement de configuration au niveau des machines virtuelles existantes, ni du réseau, ni des périphériques de stockage.

●

Ajout et suppression à chaud des disques virtuels : cette nouvelle fonctionnalité permet l’ajout et la suppression de disques virtuels au sein d’une machine virtuelle en cours de fonctionnement. Cette possibilité © ENI Editions - All rigths reserved

- 15 -

sera la bienvenue pour répondre à la problématique de manque de stockage sur des serveurs d’applications critiques tels que les serveurs de messagerie ou de bases de données.

- 16 -

●

Amélioration des performances réseau : Windows Server 2008 R2 et VMM 2008 R2 supportent deux nouvelles technologies pour augmenter les performances réseaux de la couche de virtualisation HyperV et du même coup réduire la charge processeur : VMQ (Virtual Machine Queue) et TCP Chimney. Les adaptateurs réseau qui supportent VMQ créent une queue réseau virtuelle pour chaque machine virtuelle sur la machine hôte. Ainsi, chaque machine virtuelle peut passer ses flux réseaux directement de l’HyperV vers la machine virtuelle. Cette amélioration accélère considérablement les performances en supprimant une partie des traitements habituellement pris en charge par la couche de virtualisation. L’opération de déchargement de ces opérations directement dans la carte réseau physique est prise en charge via le support de la fonctionnalité TCP Chimney.

●

CSV (Clustered Shared Volumes) : les services de cluster supportent un nouveau type de cluster permettant d’améliorer la gestion des LUN (Logical Unit Number), sur les architectures de stockage SAN. Il est ainsi possible de mettre en œ uvre un environnement de stockage unique capable d’accueillir n machines virtuelles sur la même LUN. Les machines hôtes HyperV peuvent donc désormais accéder de manière concurrente aux fichiers des machines virtuelles. La fonctionnalité CSV permet d’éliminer la limitation de Windows Server 2008 R2 qui nécessite qu’une LUN soit affectée à chaque machine virtuelle tout en faisant une meilleure utilisation de l’infrastructure de stockage.

●

Utilisation conjointe de Live Migration et des volumes en cluster de type CSV : CSV permet les opérations de Live Migration sur des machines virtuelles sur une LUN partagée sans impacter les autres machines virtuelles. L’activation de la fonctionnalité CSV sur les clusters fonctionnant sous Windows Server 2008 R2 est très simple et complètement intégrée au sein de la nouvelle console d’administration de VMM 2008 R2. Grâce à cette grande évolution, la totalité des opérations de configuration complexes liées au stockage a été supprimée.

●

Utilisation des transferts SAN au sein et en dehors des machines hôtes en cluster : cette nouvelle fonctionnalité permet de déplacer les machines virtuelles vers des hôtes HyperV en cluster en utilisant un transfert de type SAN. Ensuite, les nœ uds du cluster sont automatiquement configurés pour reconnaitre et prendre en charge les nouvelles machines virtuelles au sein du cluster.

●

Support étendu des SAN iSCSI : habituellement, seulement une LUN pouvait être associée à une cible iSCSI. Désormais, VMM 2008 R2 permet de lier de multiples LUNs vers une seule cible iSCSI. Cette possibilité apporte un plus large support à l’industrie des SAN iSCSI et offre aux clients plus de souplesse dans le choix des fournisseurs et des options en rapport avec les infrastructures de SAN basées sur le protocole iSCSI.

●

Amélioration des opérations de mises à jour des machines hôtes HyperV : VMM 2008 R2 introduit un nouveau mode appelé Mode Maintenance. Cette nouvelle option permet aux administrateurs d’appliquer les mises à jour nécessaires, de réaliser les mises à niveaux de firmware sur des machines hôtes HyperV en transférant toutes les machines virtuelles de la machine hôte vers d’autres machines du cluster via Live Migration, ou bien via l’enregistrement de cellesci. Une fois les opérations de maintenance terminées, les machines virtuelles peuvent être repositionnées à chaud ou réveillées dans le cas de leur enregistrement.

●

VMM 2008 R2 introduit d’autres améliorations telles que le support des environnements composés de multiples domaines disjoints. Les opérations de réconciliation de machines hôtes ayant des noms de domaine DNS et Active Directory différents sont ainsi facilitées. Pour y parvenir, VMM 2008 R2 crée automatiquement un SPN personnalisé (Service Principal Name), configuré dans Active Directory et dans le DNS pour qu’il soit possible de réaliser une authentification Kerberos. Enfin, il est possible d’utiliser des groupes de ports définis pour accéder à VMware Virtual Center. Durant l’installation de VMM 2008 R2, l’assistant d’installation présente les groupes de ports disponibles que VMM utilisera pour accéder à VMware Virtual Center. Cette option offre aux administrateurs VMM un meilleur contrôle des ports utilisés.

Installation de System Center VMM 2008 R2 Cette partie du chapitre détaille l’installation de VMM 2008 R2 en précisant les différentes contraintes qu’il faut respecter. En plus des contraintes de base, certaines recommandations pourront vous aider à dimensionner les ressources nécessaires en fonction des différents composants de VMM et du nombre de machines virtuelles que vous souhaitez prendre en charge.

1. Installation du serveur VMM 2008 R2 a. Eléments logiciels et matériels nécessaires Avant d’installer le serveur, il est indispensable de s’assurer que l’on dispose de tous les éléments nécessaires. Avant d’installer VMM 2008 R2, les éléments cidessous doivent être installés : ●

Windows Server 2008 R2 avec HyperV, Editions Standard, Entreprise ou Datacenter.

●

Windows PowerShell : ce composant est inclus avec Windows Server 2008 R2. Dans le cas où le composant aurait été retiré, l’assistant d’installation de VMM 2008 R2 le rajoutera.

●

Windows Remote Management (WinRM) : ce composant est inclus avec Windows Server 2008 R2. Il sera configuré pour démarrer automatiquement. Dans le cas où le service WinRM serait désactivé, le programme d’installation de VMM 2008 R2 échouera. Dans le cas où le service WinRM serait arrêté, l’assistant d’installation le démarrera.

●

Windows Automated Installation Kit (WAIK) 1.1 : dans le cas où il ne serait pas installé, l’assistant d’installation l’installera automatiquement.

●

Windows Server Internet Information Services (IIS) 7.0 ou 7.5 en fonction de la version de Windows Server 2008 utilisée (R2 ou non R2) : le rôle Serveur Web (IIS) doit être installé. Il faut veiller à ce que les services de rôle cidessous soient aussi sélectionnés au moment de l’installation : Compatibilité avec la métabase de données IIS 6, Compatibilité WMI d’IIS 6, Contenu statique, Document par défaut, Exploration de répertoire, Erreurs HTTP, ASP.NET, Extensibilité .NET, Extensions ISAPI, Filtres ISAPI, Filtrage des demandes.

Si le port par défaut du serveur Web est déjà utilisé par un autre site Web, il est nécessaire de spécifier un port différent ou bien de déclarer un header particulier pour déclarer le nom du portail en libreservice.

●

Serveur de base de données SQL Server : comme de nombreux produits de la famille System Center, l’installation de VMM 2008 R2 nécessite une base de données. Les versions supportées sont listées ci dessous : ●

SQL Server 2008 Express Edition et SQL Server 2005 Express Edition SP2,

●

SQL Server 2008 (32 et 64 bits) Editions Standard et Entreprise,

●

SQL Server 2005 (32 et 64 bits) Edition Standard et Entreprise SP2.

L’assistant d’installation de VMM 2008 R2 vérifie la présence d’une version supportée de Microsoft SQL Server sur la machine locale. Si le serveur ne dispose pas localement d’une instance SQL Server opérationnelle, l’assistant d’installation proposera d’installer la fonctionnalité Base de données interne Windows de Windows Server 2008 R2 ou bien de sélectionner un serveur de base de données distant.

●

Composants VMM 2008 R2 et versions de Windows : les différents composants de VMM 2008 R2 peuvent fonctionner sur différentes versions de Windows. Ces différentes possibilités sont listées cidessous : ●

Serveur VMM : ce composant central fonctionne uniquement sous Windows Server 2008 R2 x64 © ENI Editions - All rigths reserved

- 1-

Editions Standard, Entreprise et Datacenter, avec ou sans HyperV. Le serveur VMM est un composant 64 bits qui ne fonctionne pas sur une version minimale de Windows Server 2008 R2 (installation en mode Server Core).

Les configurations mettant en œ uvre le serveur VMM 2008 R2 sur une machine hôte HyperV ou aussi en tant que machine virtuelle Windows Server 2008 R2 x64 sont officiellement supportées par Microsoft.

●

La console Administrateur VMM 2008 R2 : ce composant peut être installé sur les systèmes fonctionnant sous Windows Server 2008 R2 x64 et 86 Editions Standard, Entreprise et Datacenter, Windows Server 2003 R2 x64 et x86 SP2 Editions Standard, Entreprise et Datacenter, Windows Server 2003 x64 et x86 SP2 Editions Standard, Entreprise et Datacenter, Windows Vista SP1 et SP2, Windows XP Professionnel SP2 et SP3.

●

Le portail libreservice VMM : ce composant peut être installé sur les systèmes fonctionnant sous Windows Server 2008 R2 x64 et 86 Editions Standard, Entreprise et Datacenter, Windows Server 2003 R2 x64 et x86 SP2 Editions Standard, Entreprise et Datacenter, Windows Server 2003 x64 et x86 SP2 Editions Standard, Entreprise et Datacenter.

●

Les serveurs de Bibliothèques : ce composant peut être installé sur les systèmes fonctionnant sous Windows Server 2008 R2 x64 et 86 Editions Standard, Entreprise et Datacenter, Windows Server 2003 R2 x64 et x86 SP2 Editions Standard, Entreprise et Datacenter, Windows Server 2003 x64 et x86 SP2 Editions Standard, Entreprise et Datacenter.

b. Installation complète de VMM 2008 R2 sur un serveur unique Le début de ce chapitre nous a permis de découvrir que System Center VMM 2008 R2 était composé de plusieurs éléments : le serveur VMM, la console Administrateur VMM, le portail libreservice VMM, l’agent VMM et bien sûr la base de données SQL Server contenant l’ensemble des éléments de configuration de la plateforme VMM. Nous verrons plus loin que l’assistant d’installation de VMM 2008 R2 prend entièrement en charge le processus d’installation. Cependant, il n’est pas possible d’installer tous les composants sur le même serveur en une seule fois. Pour installer le serveur VMM, la console Administrateur VMM et aussi le portail libreservice VMM, il faudra lancer l’assistant d’installation à plusieurs reprises. Bien que cette configuration convienne aux solutions d’entrée de gamme, l’ajout de tous les composants sur un seul serveur n’est pas une configuration recommandée lorsque VMM doit prendre en charge plus de 20 serveurs hôtes HyperV. Les configurations prenant en charge plusieurs centaines de machines hôtes HyperV sont présentées plus bas.

- 2-

Installation de SCVMM 2008 R2 Bien sûr, et même si dans certains cas ce n’est pas recommandé, l’assistant d’installation de VMM 2008 R2 permet l’installation complète de tous les composants sur un seul et unique serveur. Mais, ce scénario n’est recommandé que lorsque le serveur VMM 2008 R2 prend en charge un nombre limité de machines hôtes. Si VMM doit prendre en charge un nombre important de machines hôtes et de machines virtuelles, comme cela est le cas pour la plupart des services d’infrastructure, il faudra alors répartir les charges en distribuant les différents composants VMM sur des machines séparées. De cette manière, la plateforme VMM 2008 R2 disposera des meilleures performances. Les services d’administration offerts par VMM 2008 R2 et les services de virtualisation HyperV peuvent être tous les deux cumulés sur la même machine physique. Cette solution conviendra certainement à des entreprises de petite ou moyenne taille souhaitant optimiser les investissements matériels. Dans le cas du cumul des deux fonctionnalités, vous devrez vous assurer que la machine respecte les différents prérequis pour supporter HyperV. Pour correctement dimensionner une plateforme VMM 2008 R2 lorsque tous les composants VMM sont installés sur le même serveur, Microsoft recommande de respecter les préconisations SC suivantes : ●

●

Pour une prise en charge maximum de 10 machines hôtes HyperV : ●

Processeur type Intel DualCore x64 à 2 GHz, ou supérieur,

●

Mémoire RAM : 2 Go et 40 Go d’espace disque, ou supérieur.

Pour une prise en charge maximum de 20 machines hôtes HyperV : ●

Processeur type Intel DualCore x64 à 2 GHz ou supérieur,

●

Mémoire RAM : 4 Go et 50 Go d’espace disque.

c. Installation du composant Serveur VMM

- 3-

Les informations cidessous regroupent les éléments de la configuration système recommandée pour l’installation du serveur VMM sur un ordinateur dédié. Si la machine cible ne présente pas la configuration requise minimale, il ne sera pas possible d’installer ce composant. Nous verrons plus bas, que les ressources nécessaires dépendront du nombre de machines hôtes et du nombre de machines virtuelles gérées par le serveur VMM. Pour pouvoir installer avec succès le serveur VMM, l’ordinateur doit disposer d’au minimum 1 processeur type Pentium 4 à 2 GHz (x64), de 2 Go de mémoire RAM et de 10 Go d’espace disque. Dans le cas contraire, l’assistant d’installation de SCVMM 2008 R2 indiquera une erreur et annulera le processus d’installation.

●

Pour une prise en charge maximum de 150 machines hôtes HyperV : ●

Machine équipée de 1 ou 2 processeurs Intel DualCore ou QuadCore x64 à 2 GHz, ou supérieur.

●

Mémoire RAM : 4 Go et 50 Go d’espace disque, ou supérieur. Si vous prévoyez d’utiliser le serveur VMM 2008 R2 comme serveur de bibliothèque, vous devez prévoir davantage d’espace disque pour le stockage des objets.

●

Attention au fait que la base de données interne Windows SQL Server 2005 Express Edition SP2, installée localement est limitée à 4 Go.

Pour une prise en charge de plus de 150 machines hôtes HyperV : ●

Machine équipée de 1 ou 2 processeurs Intel DualCore ou QuadCore x64 à 3,6 GHz, ou supérieur.

●

Mémoire RAM : 8 Go et 50 Go d’espace disque, ou supérieur.

●

Lorsque le serveur VMM gère plus de 150 machines hôtes, il est judicieux d’ajouter un ou plusieurs serveurs de bibliothèque et d’éviter d’utiliser le partage de bibliothèque par défaut créé automatiquement par l’assistant d’installation de VMM.

●

Attention au fait que la base de données interne Windows SQL Server 2005 Express Edition SP2, installée localement est limitée à 4 Go.

Les figures ciaprès illustrent les étapes de configuration importante du serveur VMM 2008 R2. La première étape consiste à utiliser l’outil VMM Configuration Analyzer (VMMCA). Cet outil est directement utilisable à partir de l’interface d’installation de SCVMM. Ce composant peut donc être utilisé sur la machine locale sur laquelle VMM 2008 R2 doit être installé. Notez que VMMCA peut aussi être utilisé sur un ordinateur utilisant déjà SCVMM pour vérifier que la machine en question est bien conforme aux recommandations de Microsoft. VMMCA permet d’évaluer les paramètres de configuration matériels et logiciels les plus importants nécessaires au bon fonctionnement des rôles du serveur VMM Serveur VMM, Console Administrateur VMM, Portail libreservice VMM.

- 4-

Validation des rôles VMM avec VMM Configuration Analyzer

L’utilisation de l’outil VMMCA ne remplace en rien les tests réalisés pendant l’exécution du programme d’installation. Cet outil permet aux administrateurs d’évaluer la configuration cible pour s’assurer qu’elle répond aux prérequis de bon fonctionnement de SCVMM 2008 R2. Une fois l’évaluation terminée un rapport est généré permettant d’identifier les points de nonconformité.

- 5-

Utilisation de l’Analyseur de configuration VMM Notez que cet outil intégré au sein du programme d’installation de VMM 2008 R2 a fait l’objet d’une mise à jour. La version originale du 04/12/2008 a été mise à jour par la version Update 1 du 13/02/2009. Attention au fait que le serveur VMM 2008 R2 nécessite Windows Server 2008 R2 ou Windows Server 2008 x64 et que de ce fait, il faudra télécharger la version 64 bits de VMMCA MBCASetup64.msi, http://go.microsoft.com/fwlink/?LinkID=97952. Les étapes à suivre sont listées sur les figures suivantes :

- 6-

Écran de Bienvenue, Termes du contrat de licence

Activation de la participation au programme d’amélioration du produit © ENI Editions - All rigths reserved

- 7-

Vérification des prérequis pour installer le serveur Virtual Machine Manager Le programme d’installation s’assure que les caractéristiques matérielles et logicielles sont respectées (Windows Remote Management (WinRM), Microsoft .NET Framework 3.0, Windows PowerShell 1.0.

- 8-

Définition de l’emplacement d’installation de VMM

- 9-

Configuration des Paramètres de partage de la bibliothèque VMM par défaut

Configuration des paramètres des ports de communication de VMM - 10 -

Cette étape permet aussi de spécifier le compte de service utilisé par le serveur VMM. Notez que si le Parefeu Windows est activé, l’assistant ajoutera automatiquement les exceptions nécessaires au bon fonctionnement de VMM.

Affichage du Résumé des paramètres VMM avant l’installation

- 11 -

Exécution des différentes étapes de l’installation de VMM

Fin du processus d’installation et dernière étape de recherche des mises à jour - 12 -

2. Installation de la console d’administration VMM La console Administrateur Virtual Machine Manager (VMM) peut être installée sur le même ordinateur que le serveur VMM ou bien sûr une station de travail d’administration. Cette dernière possibilité doit être choisie lorsqu’il n’est pas possible d’accéder à distance au serveur VMM. Dans le cas où il serait nécessaire de créer des rapports VMM, il faut prévoir d’installer la console Administrateur VMM sur le même serveur que le serveur VMM. La création de rapports VMM s’appuie sur System Center Operations Manager 2007 (SP1). Les administrateurs SCOM 2007 n’auront la possibilité d’effectuer des tâches SCOM vers les machines hôtes prises en charge par VMM disposant du « Pack d’administration de virtualisation » que si l’interface PowerShell est installée sur le serveur VMM. Pour pouvoir installer la console Administrateur VMM, l’assistant d’installation de VMM installe automatiquement l’interface de commande Windows PowerShell et les cmdlets associés. Les informations cidessous indiquent la configuration recommandée pour l’installation de la console Administrateur VMM sur une machine dédiée. Si l’ordinateur ne répond pas à ces critères, l’assistant d’installation de VMM refusera d’installer ce composant. Comme dans le cas du serveur VMM, la configuration recommandée dépendra du nombre de machines hôtes et de machines virtuelles gérées par le serveur VMM. ●

●

Pour une prise en charge jusqu’à 150 machines hôtes HyperV : ●

Machine équipée de 1 ou 2 processeurs Intel DualCore ou QuadCore x64 à 1 GHz, ou supérieur.

●

Mémoire RAM : 1 Go et 50 Go d’espace disque. Une capacité de mémoire RAM supérieure est en général recommandée en fonction du système d’exploitation utilisé, Windows XP Professionnel, Windows Vista, Windows Server 2003 ou Windows Server 2008 R2.

Pour une prise en charge de plus de 150 machines hôtes HyperV : ●

Machine équipée de 1 ou 2 processeurs Intel DualCore ou QuadCore x64 à 2 GHz, ou supérieur.

●

Mémoire RAM : 2 Go et 50 Go d’espace disque, ou supérieur. Une capacité de mémoire RAM supérieure est en général recommandée en fonction du système d’exploitation utilisé, Windows XP Professionnel, Windows Vista, Windows Server 2003 ou Windows Server 2008 R2.

Composants additionnels nécessaires : l’installation de la console Administrateur VMM nécessite Windows PowerShell 1.0 ainsi que le Microsoft .NET Framework 2.0 ou 3.0. Windows PowerShell 1.0, est déjà inclus dans Windows Server 2008 R2. Le Microsoft .NET Framework 2.0 sera requis sur toutes les autres plates formes prises en charge sauf pour les systèmes fonctionnant sous Windows Server 2008 et Windows Server 2008 R2. L’assistant d’installation de VMM 2008 R2 prendra en charge l’installation du Framework, si nécessaire.

- 13 -

Installation de la console Administrateur VMM 2008 R2

3. Installation du portail libreservice VMM L’installation des fonctionnalités de portail libreservice VMM 2008 R2 n’est pas obligatoire. Il s’agit d’un composant Webfacultatif qui permet aux personnes autorisées de prendre en charge la création et la gestion de leurs propres machines virtuelles au sein de l’environnement de virtualisation contrôlé par VMM. Comme pour les autres composants VMM, l’installation du portail libreservice VMM devra être réalisée à partir de l’assistant d’installation VMM, après l’installation du serveur VMM. Si le port HTTP par défaut (80) est affecté à un autre site Web, il faudra déclarer un autre port ou un entête d’hôte particulier à utiliser pour se connecter au portail. L’utilisation des entêtes http Headers, est décrite dans l’article 190008 de la base de base de connaissances Microsoft. Il n’est pas possible d’installer le portail libreservice VMM sur un serveur Windows Server 2003 ou Windows Server 2008 R2 jouant le rôle de contrôleur de domaine. Afin d’obtenir les meilleures performances, Microsoft recommande que le portail libreservice VMM soit installé sur un serveur autre que le serveur VMM.

- 14 -

Exemple d’erreur d’installation dans le cas du portail libreservice VMM

Tous les composants logiciels et matériels requis sont présents © ENI Editions - All rigths reserved

- 15 -

Paramètres du serveur Web pour le portail libreservice VMM Notez que le serveur VMM est contacté sur le port 8100 et que si le Parefeu Windows est activé, l’assistant ajoutera automatiquement les exceptions nécessaires au bon fonctionnement de VMM. L’utilisation d’un entête d’hôte permet d’utiliser une seule et unique adresse pour n serveurs Web virtuels. Il faudra dans ce cas veiller à renseigner le FQDN (Fully Qualified Domain Name) déclaré au sein de la zone DNS.

- 16 -

Résumé des paramètres avant le lancement de l’installation du portail libreservice VMM La figure qui suit illustre les différentes étapes d’installation de la version 3.0 du .NET Framework et de Windows PowerShell 1.0.

- 17 -

Fin des étapes d’installation du portail libreservice VMM

Accès au portail en libreservice de VMM 2008 R2

4. Déploiement de l’Agent VMM sur les machines hôtes Le déploiement de l’Agent VMM Virtual Machine Manager Agent (VMMAgent) est directement pris en charge par la console Administrateur VMM. Cependant, lorsque la machine hôte sera positionnée au sein d’un réseau de périmètre DMZ (Demilitarized Zone), il ne sera pas possible de procéder à l’installation à distance de l’agent. La solution consiste à installer l’agent VMM localement sur la machine cible avant de procéder à son ajout via la console Administrateur

- 18 -

VMM. Lorsque la console Administrateur VMM est utilisée pour ajouter une nouvelle machine hôte, le serveur VMM installe automatiquement un agent VMM sur l’ordinateur hôte. Il en est de même concernant les serveurs de bibliothèque. Une fois installés, les ports des agents sont automatiquement configurés en fonction des ports affectés sur le serveur VMM. Dans le cas d’une installation personnalisée de l’agent, il faut s’assurer que les ports qui sont déclarés sont bien identiques à ceux attribués pour la communication avec les agents pendant l’installation du serveur VMM. Les ports sont facilement modifiables via la page Paramètres de configuration de l’assistant d’installation de l’agent. L’installation de l’agent VMM sur une machine hôte est prise en charge sur les machines Windows Server 2008 R2 HyperV Editions Standard, Entreprise et Datacenter ainsi que sur les platesformes précédentes fonctionnant sous Windows Server 2008 et Microsoft Virtual Server 2005 R2 EE. Comme pour les autres composants VMM, l’assistant d’installation propose le choix d’installation de l’Agent VMM localement sur une machine hôte. L’intégration des platesformes de virtualisation VMware ESX ne nécessite pas l’installation d’un agent. En effet, dans le cas de ces platesformes, le serveur VMM contacte directement une machine disposant de VMware VirtualCenter version 2.5 ou supérieur. Une fois la communication établie avec VirtualCenter, le serveur VMM 2008 R2 peut prendre en charge les machines hôtes VMWare fonctionnant sous VMware X Server 3.5, VMware ESX Server 3.0.2 et VMware ESX Server 3i ainsi que les machines virtuelles associées à ces platesformes.

- 19 -

Informations complémentaires et recommandations ●

Bien que VMM 2008 R2 puisse être installé sans problème sur un contrôleur de domaine fonctionnant sous Windows Server 2008 R2 x64, notez qu’il n’est pas possible de réaliser l’opération de promotion après l’installation de VMM. Pour réaliser cette opération, désinstallez VMM, ajoutez le rôle contrôleur de domaine puis réinstallez VMM.

●

VMM 2008 R2 supporte les environnements dont les espaces de noms sont disjoints. Cependant, pour prendre en charge cette problématique qui se produit lorsque le nom DNS principal de l’ordinateur ne correspond pas au nom du domaine dont l’ordinateur est membre, il est nécessaire d’utiliser un compte de domaine, à la place du compte Local System pour le compte de service du serveur VMM.

●

Il est fortement recommandé de rendre le serveur VMM 2008 R2 hautement disponible. Le serveur VMM ne peut pas être configuré en tant qu’application en cluster. Une bonne solution consiste à installer System Center VMM 2008 R2 au sein d’une machine virtuelle hautement disponible. Il pourra en être de même pour le serveur de base de données Microsoft SQL Server 2005 ou 2008.

●

Attention au fait que si une version 32 bits de Microsoft SQL Server est installée sur un ordinateur 64 bits, le nom de la base de données n’apparaît pas automatiquement dans la liste des bases de données. Dans ce cas, il est nécessaire d’entrer manuellement le nom de la base de données.

●

Les serveurs de librairie contiennent tous les objets utilisés par les administrateurs VMM. Il est donc recommandé que ces machines soient hautement disponibles, par exemple grâce aux services de basculement de Windows Server 2008 R2. Dans le cas d’utilisation intensive des librairies, il est recommandé d’utiliser des disques à 10.000 ou 15.000 tpm.

●

Les serveurs de librairie doivent fonctionner sous Windows Server 2008 R2 ou Windows Server 2003 SP1 ou supérieur. Pour disposer de serveurs hautement disponibles, il est recommandé de déployer les services de cluster de basculement de Windows Server 2008 R2 (WSFC).

●

Lorsque le rôle HyperV est retiré d’un serveur de bibliothèque, l’agent VMM reste présent sur le serveur de bibliothèque. L’agent VMM est automatiquement désinstallé lorsque le rôle de serveur de bibliothèque est retiré.

●

Le processus de déploiement des Agents VMM utilise des appels RPC port TCP 135 plus une plage de ports dynamiques utilisés par DCOM, ainsi que le protocole SMB. Pour sécuriser ces trafics, vous pouvez utiliser la signature de paquets SMB et/ou le protocole IPSec. Les Agents VMM peuvent aussi être installés directement à partir du DVD de VMM 2008 R2. Dans ce cas, les seuls ports à contrôler sont les ports utilisés par WinRM (par défaut, le port 80) et le port utilisé par BITS (par défaut, le port 443).

●

Les Agents VMM peuvent, bien entendu, être installés sur une installation minimale de Windows Server 2008 R2 Server Core. Il suffit d’exécuter la commande suivante à partir du dossier du DVD \amd64\msi\agent : msiexec /I vmmagent.msi. Notez qu’il est au préalable nécessaire d’installer le package Visual C++ 2005 Redistribuable, via la commande Vcredist_x64.exe disponible sur le DVD de VMM 2008 R2.

Pour plus de renseignements sur l’installation et la configuration de VMM 2008 R2 et des différents rôles supportés, référezvous au site Microsoft Technet/System Center Virtual Manager Tech Center, à l’adresse : http://technet.microsoft.com/enus/scvmm/default.aspx

- 1-

Administration de la virtualisation avec VMM 2008 R2 L’administration d’une plateforme de virtualisation doit répondre à de multiples challenges. En introduisant une première version de System Center Virtual Machine Manager en 2007 prenant en charge les platesformes basées sur Virtual Server 2005, Microsoft à commencé à répondre à la problématique d’administration de ces platesformes. Le chapitre Architecture et installation de System Center VMM nous a permis de nous intéresser à l’architecture et à la procédure d’installation de System Center Virtual Machine Manager 2008 R2. Ce chapitre présente maintenant les différentes opérations liées à l’administration et à l’optimisation d’une plateforme de virtualisation. Les technologies de virtualisation apportent de profonds changements concernant le déploiement, la configuration et la haute disponibilité des machines virtuelles, mais nous allons découvrir que les avantages sont nombreux.

1. Découverte de l’environnement de la console a. Introduction La console d’administration SCVMM est utilisée pour prendre en charge l’ensemble des tâches de gestion des environnements virtuels fonctionnant sous HyperV, Virtual Server 2005 R2 et VMware ESX, lorsque ces derniers sont intégrés au sein d’une plateforme VMware Infrastructure 3 ou ultérieure.

Interface Console d’administration SCVMM 2008 R2

La console d’administration SCVMM 2008 R2 peut être directement utilisée sur le serveur VMM ou aussi sur des postes de travail jouant le rôle de station d’administration. La figure précédente illustre la structure de l’interface Console d’administration SCVMM. Bien qu’une application bureautique n’ait rien de commun avec une application d’administration, la console d’administration SCVMM utilise une navigation largement inspirée des versions récentes de Microsoft Outlook. On retrouve d’ailleurs ce type de navigation dans SCOM 2007 (System Center Operation Manager 2007). La console est composée de six vues, lesquelles disposent de leur propre arbre de navigation, de leur propre volet d’affichage de résultats, de leurs propres filtres et de leur propre volet d’actions. Par défaut, la console d’administration SCVMM tente de se connecter localement au serveur VMM, cependant l’administrateur a la possibilité de se connecter à tout serveur SCVMM 2008 R2. À la différence de certaines consoles © ENI Editions - All rigths reserved

- 1-

qui ne peuvent s’exécuter qu’une seule et unique fois sur la même machine, programmes mono instance, la console d’administration peut être lancée n fois, en étant connecté sur le même serveur ou bien sûr des serveurs VMM distincts.

Connexion à un autre serveur SCVMM 2008 via le port TCP 8100

b. Détails des différentes vues de la Console d’administration SCVMM L’administrateur VMM pourra réaliser l’ensemble des tâches d’administration en fonction des vues qu’il sélectionnera. Le détail des opérations principales associées à ces vues est listé cidessous : Gestion des machines hôtes Cette vue de la console permet aux administrateurs VMM de réaliser les opérations suivantes : ●

L’ajout, la suppression, les modifications des paramètres des machines hôtes HyperV, Virtual Server 2005 R2 et VMware ESX.

●

La configuration des options de placement des machines virtuelles sur les hôtes, la déclaration des chemins autorisés pour le stockage des machines virtuelles ainsi que la configuration des réseaux virtuels.

●

L’ajout, la suppression, les modifications des paramètres des « groupes hôtes » pour faciliter l’administration des machines hôtes en termes de réserves de ressources (CPI, mémoire, espace disque, IOPS disques et capacité réseau) ainsi que la configuration des paramètres PRO.

●

La configuration des ports réseau utilisés pour les connexions à distance aux machines virtuelles.

●

L’inscription d’ordinateurs virtuels sur des machines hôtes pour les machines virtuelles n’ayant pas été préalablement inscrites sur un ordinateur hôte dans SCVMM ou qui auraient été déplacées sans passer par VMM, d’une machine hôte vers un autre.

●

L’ajout, la suppression, les modifications des paramètres des réseaux virtuels.

Gestion des machines virtuelles Cette vue de la console permet aux administrateurs VMM de réaliser les opérations suivantes :

- 2-

●

La création, le déploiement, la migration, le clonage, le contrôle du bon fonctionnement, la réparation, le stockage, la suppression de machines virtuelles et la connexion à ces mêmes machines.

●

La création des points de contrôle, en d’autres termes, de captures instantanées, afin de pouvoir restaurer les ordinateurs virtuels à un état précédent.

Gestion des bibliothèques Cette vue de la console permet aux administrateurs VMM de réaliser les opérations suivantes : ●

La configuration de profils de système d’exploitation invité,

●

La configuration de modèles d’ordinateurs virtuels en vue de leur utilisation lors de la création des machines virtuelles.

●

L’ajout des ressources fichiers au sein des librairies en vue de leur utilisation lors de la création des machines virtuelles.

●

L’ajout des serveurs de librairies, des partages qui leur sont associés ainsi que du rafraîchissement du contenu des serveurs, la valeur de rafraîchissement des partages d’une bibliothèque étant, par défaut, définie à la valeur minimale d’une heure.

Gestion des travaux Cette vue de la console permet aux administrateurs VMM de réaliser les opérations suivantes : ●

La surveillance, l’annulation, le redémarrage, le tri, la recherche, le filtrage des travaux.

●

Le suivi des modifications apportées par un travail aux objets VMM.

Configuration des paramètres de VMM Cette vue de la console permet aux administrateurs VMM de réaliser les opérations suivantes : ●

Vue d’ensemble : cet item permet l’affichage sous forme graphique d’informations récapitulatives sur l’environnement (ordinateurs hôtes, ordinateurs virtuels, travaux récents et ressources de bibliothèque).

●

Général : cet item donne accès à la configuration des paramètres VMM globaux, tels que le contrôle à distance et le fonctionnement de la technologie PRO.

●

Ordinateurs gérés : cet item permet la gestion des agents VMM sur les machines hôtes gérées ainsi que sur les serveurs de bibliothèque. Il permet la mise à jour, la suppression de l’agent et aussi la réassociation au serveur VMM actif.

●

Mise en réseau : cet item permet l’affichage et la configuration de la plage statique des adresses MAC utilisées par VMM sur l’ensemble des ordinateurs hôtes gérés. Cette option permet de garantir que lorsqu’une adresse MAC de la liste a été utilisée, elle ne sera plus jamais utilisée par VMM.

●

Rôles d’utilisateurs : cet item permet l’affichage, l’ajout et la suppression de rôles à des utilisateurs de l’annuaire Active Directory. Les utilisateurs ainsi déclarés peuvent créer et gérer leurs propres machines virtuelles dans un environnement contrôlé en utilisant le portail libreservice VMM ou l’interface de commande Windows PowerShell.

●

System Center : cet item permet de configurer le support des rapports générés par System Center Operations Manager 2007. Le nom du serveur Operations Manager ainsi que l’URL du serveur de rapport Operations Manager peuvent être déclarés à cet emplacement.

●

Gestionnaires de virtualisation : cet item permet l’affichage de tous les gestionnaires de virtualisation disponibles, tels que Virtual Machine Manager et VMware VirtualCenter.

Gestion des rapports Cette vue de la console permet aux administrateurs VMM de réaliser les opérations suivantes :

- 3-

●

Affichage et ouverture des rapports. Cette vue n’est disponible que si SCVMM et SC Operations Manager ont été configurés.

Barre de boutons de la console d’administration SCVMM.

Cette barre de boutons permet d’accéder aux opérations qui permettront aux administrateurs VMM de réaliser les opérations suivantes : ●

Travaux : permet un accès direct à la vue Travaux.

●

Conseils PRO : permet un accès direct à la vue Conseils PRO.

●

Mise en réseau : affiche une représentation graphique de la configuration réseau en fonction des ordinateurs hôtes et des machines virtuelles sélectionnées.

●

Diagramme : la vue Diagramme est une vue hiérarchique qui indique l’intégrité du serveur Virtual Machine Manager, du serveur de base de données, des serveurs de bibliothèque, des ordinateurs hôtes, des ordinateurs virtuels et des serveurs VMware VirtualCenter.

La vue Diagramme n’est disponible que si Operations Manager est configuré. Pour plus d’informations, reportezvous à l’article Microsoft disponible via le lien suivant : http://go.microsoft.com/fwlink/? LinkId=120283.

●

PowerShell : permet un accès direct à l’invite de commande Windows PowerShell.

2. Gestion des serveurs Hôtes et des groupes d’hôtes La console d’administration permet aux administrateurs VMM de gérer les serveurs hôtes. Lorsque l’infrastructure de virtualisation est composée de multiples machines hôtes fonctionnant sous HyperV, HyperV Server, Virtual Server 2005 R2 ou VMware ESX, il peut être intéressant de créer des « groupes hôtes ».

- 4-

Gestion des machines hôtes au sein des groupes hôtes La figure cidessus montre une structure de groupes d’hôtes regroupant plusieurs salles machines réparties sur des sites géographiquement dispersés. Une fois ces groupes créés, un peu comme des unités d’organisation au sein des services de domaine Active Directory, les machines hôtes pourront y être placées. Une telle organisation permettra de gérer plus facilement de manière uniforme les machines hôtes et machines hôtes en cluster devant utiliser des paramètres identiques.

a. Ajout des machines hôtes La console Administrateur SCVMM permet aux administrateurs VMM d’utiliser l’Assistant Ajouter des ordinateurs hôtes pour ajouter un ou plusieurs types de machines hôtes suivantes à VMM : ●

Ordinateurs hôtes Windows Server 2008 R2 HyperV ou HyperV Server 2008 situés dans un domaine Active Directory (AD DS),

●

Ordinateurs hôtes Windows Server 2008 R2 HyperV ou HyperV Server 2008 situés sur un réseau de périmètre, DMZ,

●

Ordinateurs hôtes fonctionnant sous VMware ESX situés n’importe où au sein de l’environnement de virtualisation.

Sélection du type de serveur hôte à intégrer dans SCVMM 2008 R2

- 5-

Cas des machines hôtes HyperV membres d’un domaine Active Directory L’assistant Ajouter des ordinateurs hôtes permet d’ajouter en une seule opération un ou plusieurs ordinateur(s) hôte(s) HyperV à SCVMM 2008. Pour réaliser une sélection multiple, toutes les machines hôtes sélectionnées doivent être membres d’un domaine Active Directory. Les ordinateurs hôtes peuvent se trouver dans un domaine ayant une relation d’approbation bidirectionnelle ou appartenir à un domaine non approuvé par le domaine contenant le serveur VMM. L’assistant d’ajout des machines hôtes permet de réaliser une recherche en fonction de certains paramètres simples tels que la technologie de virtualisation, HyperV ou Virtual Server, ou le nom du ou des ordinateur(s) recherché(s). L’interface présentée ciaprès permet de spécifier le nom du domaine Active Directory approuvé, sachant que par défaut le nom du domaine local sera spécifié. Dans notre exemple, c’est le domaine Active Directory MyCorp.net. Le champ Nom de l’ordinateur permet de taper le nom complet de l’ordinateur pour rechercher un ordinateur spécifique, ou de taper uniquement les premiers caractères pour renvoyer tous les ordinateurs dont le nom commence par ces caractères. Par exemple, le fait de saisir WSV renverra tous les ordinateurs dont le nom commence par les caractères WSV.

Fenêtre de recherche proposée par l’assistant Ajouter des ordinateurs hôtes Ordinateurs hôtes Windows Server sur un réseau de périmètre Le cas des réseaux protégés par un parefeu est aujourd’hui un cas banal. En effet, même s’il est vrai que généralement le serveur VMM sera en contact direct avec les machines hôtes, il se pourra que cela ne soit pas le cas. Dans ce contexte, plusieurs solutions sont envisageables : ●

- 6-

La première consiste à autoriser temporairement les trafics acceptant le protocole SMB, les RPC (TCP 135) et

range de port DCOM, entre le serveur VMM et la machine hôte concernée. ●

La deuxième consiste à installer l’agent VMM localement sur l’ordinateur hôte cible. Une fois l’agent installé, il sera possible d’utiliser l’assistant Ajouter des ordinateurs hôtes pour ajouter l’ordinateur hôte à VMM.

●

La troisième consiste à sécuriser les trafics à l’aide d’une stratégie IPSec entre le serveur VMM et les machines hôtes afin de sécuriser le processus de déploiement des agents.

Il faut savoir que l’agent VMM, déployé sur les machines hôtes et les serveurs de bibliothèque, utilise uniquement les protocoles WSMAN (WinRM, TCP 80) et BITS (TCP 443). Ensuite, les protocoles de prise de contrôle des machines virtuelles suivants pourront être utilisés en fonction des situations : ●

RDP (TCP 3389) : pour les connexions vers des machines virtuelles à partir d’une console Administrateur SCVMM fonctionnant sur une machine nonWindows Server 2008 R2 ou Windows Vista SP1 (ou supérieure). Il n’est pas possible de modifier le port par défaut pour les connexions RDP dans VMM.

●

Le port 2179 via VMConnect.exe pour accéder aux machines virtuelles prises en charge via HyperV à partir de machines fonctionnant sous Windows Server 2008 R2 ou Windows Vista SP1 (ou supérieure).

●

Le port TCP 5900 pour l’utilisation de VMRC pour accéder aux machines virtuelles prises en charge par Virtual Server.

De même, lorsque vous installez un agent VMM localement sur un ordinateur hôte, l’Assistant Installation de l’agent invite à fournir une clé de chiffrement dont le serveur VMM a besoin pour accéder à l’ordinateur hôte. L’Assistant génère automatiquement un jeu d’informations d’identification d’agent et utilise la clé pour chiffrer ces informations et les autres informations d’accès dans un fichier de sécurité. Après avoir installé un agent localement sur l’ordinateur hôte, il faudra utiliser le fichier de sécurité pour insérer l’ordinateur hôte à VMM. Le fichier de sécurité SecurityFile.txt, est placé sur la machine hôte au sein du dossier \Program Files\Microsoft System Center Virtual Machine Manager. Une fois le fichier transféré dans un dossier accessible à la machine où est installée la console Administrateur SCVMM, il suffit d’utiliser le volet Actions, l’option Ajouter des ordinateurs hôtes puis de sélectionner le choix Ordinateur hôte Windows Server sur un réseau de périmètre. Ordinateurs hôtes VMware ESX Server L’assistant Ajouter des ordinateurs hôtes permet à l’administrateur VMM d’ajouter un ou plusieurs ordinateur(s) hôte(s) ESX Server à VMM. Cependant, la nécessité d’intégrer VMware VirtualCenter ajoute quelques étapes supplémentaires. En effet, VMM 2008 R2 gère les platesformes VMware ESX via les API VMware Infrastructure. Pour cette raison, pour commencer à gérer VMware, il est nécessaire d’ajouter en premier lieu le serveur VMware VirtualCenter à VMM. Virtual Machine Manager prend en charge les versions VMware suivantes : VMware VirtualCenter 2.5 et VMware VirtualCenter 2.0.1 et les machines hôtes VMware ESX 3.5, VMware ESX 3.0.2 et VMware ESX 3i.

Action Ajouter un serveur VMware VirtualCenter La procédure cidessous liste les tâches à effectuer pour configurer VMM de manière à gérer un environnement VMware Infrastructure 3 (VI3). La première étape consiste à ajouter le serveur VirtualCenter afin que VMM puisse utiliser l’API VMware Infrastructure pour gérer les machines hôtes ESX Server et les machines virtuelles. Lorsque vous ajoutez une machine VirtualCenter à VMM, toutes les machines hôtes qui exécutent ESX Server sont également ajoutées à VMM. VMM crée au final un groupe hôte pour stocker les machines hôtes ESX. Lorsque vous ajoutez le serveur VirtualCenter, vous indiquez si les communications avec les ordinateurs hôtes ESX Server doivent être réalisées en mode sécurisé. Si vous choisissez Mode sécurisé, vous devez fournir un certificat et une clé publique, en plus des informations d’identification, pour chaque ordinateur hôte ESX Server.

- 7-

Pour ajouter un serveur VMware VirtualCenter à VMM, les étapes suivantes sont à réaliser : ■

À l’aide de la console Administrateur SCVMM, cliquez sur Ajouter un serveur VMware VirtualCenter.

■

Dans le champ Nom de l’ordinateur de la boîte de dialogue Ajouter un serveur VMware VirtualCenter, spécifiez le serveur VirtualCenter à ajouter.

■

Dans le champ Port TCP/IP, spécifiez le port TCP/IP à utiliser pour les connexions au serveur VirtualCenter ; le port par défaut étant le port SSL, 443.

■

Dans la rubrique Compte administratif, entrez le compte et le mot de passe à utiliser pour établir la connexion au serveur VirtualCenter.

■

Dans la rubrique Sécurité, indiquez s’il est nécessaire de communiquer avec les machines hôtes ESX Server en mode sécurisé.

En mode sécurisé, un certificat et une clé publique sont requis pour chaque ordinateur hôte ESX Server. Désactivez cette option si vous souhaitez approuver les communications et n’utilisez que les informations d’identification des machines hôtes ESX. Si le serveur VirtualCenter utilise un certificat autosigné, il est nécessaire d’importer le certificat du serveur dans le magasin de certificats de l’ordinateur local. Cette étape est obligatoire pour vérifier l’identité du serveur. Bien sûr, si le certificat utilisé par le serveur VirtualCenter est un certificat émis par une autorité de certification tierce connue, cette opération ne sera pas requise.

Fenêtre de configuration de l’Action Ajouter un serveur VMware VirtualCenter

- 8-

Une fois la machine VirtualCenter ajoutée à VMM, les machines hôtes ESX sont ajoutées automatiquement à VMM dans leur propre hiérarchie de groupes hôtes. Cette opération, parfois longue, permettra l’ajout des machines hôtes ESX et l’actualisation des données relatives aux machines virtuelles. À l’issue de l’intégration des machines hôtes ESX au sein de VMM, l’état initial des machines hôtes ESX Server nouvellement découvertes prend la valeur OK (Limité). Ce statut signifie que pour gérer entièrement les machines virtuelles hébergées sur les machines hôtes ESX, il sera nécessaire de spécifier les informations d’identification au niveau des propriétés de chaque machine hôte ESX.

Assistant Ajouter des ordinateurs hôtes VMware ESX

Sécurité des accès aux machines hôtes ESX : VMM doit disposer d’un accès de type Root à l’ordinateur hôte ce qui nécessite d’activer la connexion Root SSH sur l’ordinateur hôte ESX. Une autre solution pourra consister à utiliser les informations d’identification d’un compte délégué configuré au sein de VMware VirtualCenter. Étape d’importation des modèles VMware dans la bibliothèque VMM Une fois la machine VMware VirtualCenter intégrée et les différentes machines hôtes ESX reconnues par VMM, l’importation des modèles devient possible. Cette opération sera facilement réalisée en spécifiant un compte d’administration tel que celui qui est utilisé pour les connexions aux machines hôtes ESX. Attention au fait que si le serveur VirtualCenter utilise des communications sécurisées, il est nécessaire de fournir un certificat contenant la clé publique de chacun des ordinateurs hôtes ESX. Une fois le serveur VirtualCenter connu de VMM et les modèles de machines virtuelles importés avec succès, la dernière étape pourra être d’implémenter le support de PRO, pour les groupes hôtes VMware. De cette manière, PRO pourra prendra en charge l’optimisation des ressources HyperV ainsi que celle des machines hôtes VMware ESX, en fonction des charges de travail. Attention ! Si la machine hôte spécifiée est déjà gérée par VMM mais via un autre serveur VirtualCenter, la machine hôte sera déplacée de son serveur VirtualCenter actuel vers le nouveau serveur VirtualCenter spécifié.

b. Gestion des paramètres des machines hôtes © ENI Editions - All rigths reserved

- 9-

Chaque machine hôte dispose de propriétés VMM. La figure cidessous illustre que de multiples onglets permettent de configurer tous les aspects de la machine hôte sélectionnée.

Propriétés de la machine hôte HV01 Par défaut, un Résumé décrivant la machine est présenté de telle sorte qu’il est facile d’identifier les capacités en termes de processeurs, de mémoire RAM, de capacité disques, de version de système d’exploitation et aussi concernant la version de l’Agent VMM déployé. État L’onglet État permet à l’administrateur d’obtenir l’état des composants principaux de la machine hôte sélectionnée. De cette manière, VMM permet de vérifier l’état global d’une machine hôte, ainsi que celui de l’agent VMM et de la couche de virtualisation. Bien entendu, tous ces indicateurs sont importants pour déterminer l’état opérationnel d’une machine hôte. En cas de nécessité, ces indicateurs permettront à l’administrateur VMM de réaliser une opération particulière, telle que, par exemple, la mise à jour de l’agent VMM.

- 10 -

Affichage de l’état d’une machine hôte HyperV Ces différents statuts sont décrits cidessous : État global : ●

OK : aucun problème n’affecte un état de la machine hôte.

●

OK (Limité) : la machine hôte VMware ESX Server requiert des informations d’identification et d’autres paramètres de sécurité pour que VMM puisse le gérer complètement.

●

Attention requise : un problème affecte un ou plusieurs états de la machine hôte.

État de la connexion : ●

Réponse en cours : le serveur VMM est en mesure de communiquer avec l’agent sur la machine hôte.

●

Pas de réponse : le serveur VMM n’est pas en mesure de communiquer avec l’agent sur la machine hôte.

●

Accès refusé : l’agent n’est plus associé au serveur VMM.

Version de l’agent : ●

Mis à jour : la version de l’agent est à jour.

●

Mise à niveau disponible : la version de l’agent doit être mise à niveau de manière à correspondre à la version du serveur VMM.

- 11 -

●

Non pris en charge : la version de l’agent n’est prise en charge pour aucune des fonctions VMM.

État du service de virtualisation : ●

En cours d’exécution : le service de virtualisation est démarré.

●

Arrêté : le service de virtualisation est arrêté.

Version du service de virtualisation : ●

Mis à jour : la version du logiciel de virtualisation est à jour.

●

Mise à niveau disponible : la version du logiciel de virtualisation doit être mise à niveau vers une version prise en charge par VMM.

●

Non pris en charge : la version du logiciel de virtualisation n’est prise en charge pour aucune des fonctions VMM.

Les informations de statut montrant l’état de la machine hôte sont mises à jour toutes les 30 minutes. Pour exécuter une actualisation des informations affichées utilisez la fonction Actualiser du menu contextuel de la machine hôte à l’aide du bouton droit de la souris. Ordinateurs virtuels Chaque fois qu’une machine virtuelle est créée, déployée ou migrée, VMM inscrit la machine virtuelle au sein de l’environnement de virtualisation. Dans ce cas, VMM reconnaît la machine virtuelle automatiquement. Dans certains cas cependant, l’administrateur VMM pourra souhaiter inscrire manuellement une machine virtuelle provenant de fichiers relatifs à celleci. Dans ce cas, l’onglet Ordinateurs virtuels de la boîte de dialogue Propriétés d’ordinateur hôte permettra d’inscrire les fichiers virtuels se trouvant déjà sur la machine hôte. Une fois l’inscription des fichiers effectuée, VMM découvrira automatiquement la machine virtuelle lors du prochain cycle d’actualisation de la machine hôte. À ce stade, la ou les machine(s) virtuelle(s) est(sont) affichée(s) au sein de la console Administrateur SCVMM dans la vue Ordinateurs virtuels. La procédure suivante permet de réaliser cette opération : ■

Via l’onglet Ordinateurs virtuels, dans la zone Inscrire les ordinateurs virtuels, cliquez sur Parcourir, et effectuez l’une des opérations suivantes : ●

Dans le cas d’une machine hôte Virtual Server 2005 R2, accédez au dossier contenant le fichier de configuration des machines virtuelles (.vmc), cliquez sur le fichier, cliquez sur OK, puis de nouveau sur OK.

●

Dans le cas d’une machine hôte exécutant HyperV, accédez au dossier qui contient les fichiers des machines virtuelles, cliquez sur le dossier, cliquez sur OK, puis de nouveau sur OK.

La figure suivante illustre l’onglet Ordinateurs virtuels.

- 12 -

Onglet Ordinateurs virtuels et inscription de machines virtuelles externes Réserves Cet onglet permet à l’administrateur VMM de configurer les paramètres de ressources matérielles qui seront utilisés pour déterminer quand une machine virtuelle peut, ou non, être prise en charge sur la machine hôte. Si la machine hôte ne satisfait pas à ces exigences de ressources alors la ou les machine(s) virtuelle(s) ne pourront être hébergées sur la machine hôte. Les ressources de machines hôtes sont utiles lorsque des machines virtuelles sont placées sur un ordinateur hôte. Ces réserves déterminent quel pourcentage du processeur, de la mémoire RAM, de l’espace disque, de la capacité d’entrée/sortie et de la capacité réseau sera toujours disponible pour le système d’exploitation hôte.

- 13 -

Onglet Réserves d’une machine hôte HyperV Matériel Cet onglet permet à l’administrateur VMM d’afficher les caractéristiques matérielles de la machine hôte. Il est aussi possible, comme le montre la figure cidessous, de spécifier si tel ou tel volume disque est disponible dans le cadre de la sélection élective, comme stockage ou non. Les paramètres réseaux accessibles au travers de cet onglet permettent aussi d’altérer la découverte de l’emplacement réseau pour une carte réseau particulière.

- 14 -

Caractéristiques matérielles de la machine hôte et sélection du stockage Voici quelques compléments sur la sélection élective : ●

Lorsqu’un ordinateur virtuel est déployé sur un ordinateur hôte, le processus de sélection de l’ordinateur hôte le plus approprié pour l’ordinateur virtuel porte le nom de sélection élective d’un ordinateur virtuel, ou simplement sélection élective. Lors de la sélection élective, les ordinateurs hôtes sont évalués en fonction de la configuration matérielle requise et des besoins en ressources de l’ordinateur virtuel, de l’utilisation anticipée des ressources et des possibilités offertes par la plateforme de virtualisation concernée. Ces évaluations prennent également en compte l’objectif de la sélection élective : maximisation des ressources sur les différents ordinateurs hôtes, équilibrage de charge entre les ordinateurs hôtes ou obtention éventuelle d’un ordinateur virtuel à haut niveau de disponibilité. C’est sur la base de ces évaluations que l’administrateur choisit un ordinateur hôte pour l’ordinateur virtuel.

●

La sélection élective peut fonctionner en mode automatique. Par exemple, dans le portail libreservice, les machines virtuelles des utilisateurs sont automatiquement placées sur l’ordinateur hôte le plus approprié du groupe hôte utilisé pour le libreservice.

●

La sélection élective automatique est également invoquée lorsqu’un administrateur VMM réalise une opération de type Glissédéplacé pour migrer une machine virtuelle vers un groupe hôte dans une vue de type Ordinateurs virtuels. Dans le cas de la sélection élective automatique, les fichiers de configuration de la machine virtuelle sont déplacés vers le volume jugé le plus approprié sur la machine hôte sélectionnée. Pour que la sélection élective automatique réussisse, le chemin d’accès de l’ordinateur virtuel doit être configuré sur le volume recommandé.

Mise en réseau Cette rubrique permet à l’administrateur VMM d’ajouter, de modifier et de supprimer des nouveaux réseaux virtuels sur des machines hôtes HyperV. VMM 2008 R2 utilise les réseaux virtuels avec support, ou non, des VLAN. L’infrastructure de virtualisation permet de virtualiser les réseaux en créant des réseaux logiques indépendants au sein d’un réseau physique. Cette approche facilite l’administration du réseau grâce au découpage apporté par une

- 15 -

séparation des segments logiques qui ne doivent pas échanger de données dans un réseau local. L’avantage apporté par la mise en œ uvre de réseaux logiques au sein de la plateforme de virtualisation HyperV/VMM est lié au fait que la configuration des réseaux virtuels, étant assurée côté logiciel, les machines virtuelles peuvent facilement être déplacées entre machines hôtes en conservant leur configuration réseau. La virtualisation des réseaux est donc un autre avantage apporté par les platesformes de virtualisation, par rapport aux solutions matérielles. Les machines hôtes HyperV contrôlées par VMM utilisent une approche basée sur des ports pour taguer les réseaux locaux virtuels. De cette manière, au sein d’un réseau virtuel donné, chaque port peut être configuré de manière à appartenir à différents VLAN. Les VLAN sont configurables en affectant une valeur numérique, le VLAN ID, au niveau du port. Ensuite, tout le trafic en provenance de ce port est identifié avec l’ID de ce VLAN. De cette manière, seul le trafic du réseau local virtuel est transmis à destination et en provenance des ports de ce même VLAN. Attention à une perte de connectivité éventuelle ! Avant d’activer les réseaux locaux virtuels sur une carte réseau, assurezvous que vous disposez d’au moins une autre carte réseau disponible pour les communications entre la machine hôte et le serveur VMM.

Onglet Mise en réseau des propriétés d’une machine hôte Sélection élective Lorsqu’une machine virtuelle est déployée sur une machine hôte via VMM, l’assistant de déploiement enclenche un processus particulier appelé « Sélection élective ». Ce processus a pour objectif d’aider l’administrateur VMM à déterminer la machine hôte la plus appropriée pour la machine virtuelle. Lors de cette présélection, les machines hôtes sont évaluées en fonction des exigences de la machine virtuelle à déployer, configuration matérielle requise, besoins en ressources, utilisation anticipée des ressources. Les figures qui suivent illustrent l’utilisation de l’assistant Nouvel ordinateur virtuel disponible via la console Administrateur SCVMM Actions. - 16 -

Cet assistant est aussi directement invocable en passant par la vue Bibliothèque, en sélectionnant une image stockée via le menu contextuel puis l’option Déployer. Cidessous l’option Placer l’ordinateur virtuel sur un ordinateur hôte avec sélection élective.

Assistant Déployer un ordinateur virtuel et sélection du placement Une fois le profil matériel sélectionné par l’administrateur VMM, l’assistant propose de sélectionner la machine hôte. Les machines hôtes sont évaluées en fonction des spécifications de la machine virtuelle et des options de sélection élective par défaut.

- 17 -

Sélection d’une machine hôte pour héberger une machine virtuelle Cette fenêtre de sélection permet à l’administrateur de rechercher des machines hôtes particulières en tapant tout ou partie de leur nom et en agissant sur l’étendue souhaitée, hiérarchie de groupes d’hôtes existants. Le bouton Personnaliser affiche la fenêtre ciaprès. L’administrateur a ainsi la possibilité de configurer la manière dont les évaluations de la machine hôte sont calculées. Dans cet exemple, les modifications apportées affecteront uniquement le déploiement en cours.

- 18 -

Options de personnalisation de la politique de sélection élective À propos de la Sélection élective automatique : dans les cas cidessous, la machine virtuelle sera placée automatiquement sur la machine hôte la plus appropriée. ■

Lorsque la création de la machine virtuelle est réalisée à l’aide du portail Web libreservice, les machines virtuelles sont automatiquement placées sur la machine hôte du groupe hôte affecté au portail libreservice.

■

Lorsque l’administrateur utilise un glissédéplacé d’une machine virtuelle via la vue Ordinateurs virtuels vers un groupe hôte.

Une fois la sélection élective automatique réalisée, l’administrateur choisira parmi toutes les machines hôtes potentiellement validées comme étant capables d’assurer la prise en charge de la machine virtuelle. Ensuite, les fichiers de configuration de la machine virtuelle seront déplacés vers le stockage disque jugé le plus approprié sur la machine hôte sélectionnée. Il est recommandé de ne pas ajouter de chemins d’accès issus du même lecteur que les fichiers de système d’exploitation. La bonne pratique consiste à utiliser un stockage de type SAN de telle sorte qu’en cas de réinstallation du système d’exploitation, il n’y ait aucun risque de perte de fichiers de machines virtuelles. En plus des chemins d’accès par défaut ajoutés par vos soins, HyperV crée son propre chemin d’accès par défaut, lequel apparaît sous l’onglet Sélection élective de la boîte de dialogue Propriétés d’ordinateur hôte. La console Administrateur SCVMM n’autorise pas la suppression des chemins d’accès par défaut.

- 19 -

Gestion des chemins d’accès par défaut à utiliser pour la sélection élective des machines virtuelles sur les machines hôtes La figure cidessous illustre une évaluation négative pour les machines hôtes HV01 et HV02.

- 20 -

Explication de l’évaluation : un manque de ressource de stockage est détecté

Notez que lorsqu’un noeud d’un cluster est sélectionné, le nom du cluster est affiché dans le message d’information. Dans notre exemple, le noeud hv02.MyCorp.net est sélectionné, mais le message indique que le cluster HVFCS01.MyCorp.net est trop sollicité. Le message suivant s’affichera si l’administrateur tente d’outrepasser les recommandations de SCVMM 2008.

Message d’explication de la cause de l’impossibilité de réaliser l’opération de placement Les mécanismes d’évaluation impliqués dans la sélection élective prennent également en compte des objectifs de maximisation des ressources des machines hôtes HyperV, l’équilibrage de charge entre les ordinateurs hôtes ou aussi l’obtention éventuelle d’une machine virtuelle devant disposer d’un haut niveau de disponibilité. Sur la base de tous ces critères, l’administrateur VMM pourra, au final, choisir la meilleure machine hôte pour y héberger la machine virtuelle.

- 21 -

Attention ! Dans le cas d’un cluster de machines hôtes, le chemin d’accès par défaut est forcement un volume partagé de type cluster. Une fois configurée en cluster, une machine hôte HyperV n’a plus la possibilité de disposer de chemins d’accès par défaut supplémentaires. C’est pour cette raison que, comme le montre la figure cidessous, le bouton Ajouter est grisé.

Machine en cluster et gestion des chemins d’accès

Lorsqu’une machine virtuelle est configurée avec l’option Rendre cet ordinateur virtuel hautement disponible alors, seules les machines hôtes en cluster recevront une évaluation élevée.

Configuration de la priorité et de la disponibilité d’un ordinateur virtuel L’administrateur VMM a la possibilité de configurer l’allocation des ressources processeur et aussi d’indiquer si la machine virtuelle doit fonctionner avec un haut niveau de disponibilité. Ces paramètres peuvent être directement intégrés au sein d’un profil matériel.

- 22 -

Gestion de la Priorité au niveau des propriétés d’une machine virtuelle Lorsque l’utilisation du processeur sur un ordinateur hôte est intense, les ressources CPU sont en premier lieu allouées aux machines virtuelles présentant un niveau de priorité le plus élevé. L’administrateur VMM a donc la possibilité de sélectionner une priorité de niveau Haute, Normale ou Basse ou même une priorité personnalisée pour affiner au mieux le contrôle. La valeur par défaut du niveau de priorité processeur est égale à 1. Cette valeur est la plus basse, sachant que la valeur la plus élevée peut être égale à 10 000. À distance La figure suivante illustre la possibilité de fixer la valeur du port TCP/IP qui sera utilisé pour la fonctionnalité de connexion à distance vers les machines virtuelles de la machine hôte HyperV.

- 23 -

Configuration du port utilisé pour la connexion à distance d’une machine virtuelle Personnalisé L’onglet Personnalisé permet à l’administrateur d’affecter jusqu’à 10 champs personnalisés à une machine virtuelle.

- 24 -

Onglet Propriétés personnalisées L’administrateur VMM a la possibilité d’attribuer un maximum de dix propriétés personnalisées à un ordinateur hôte. Ces propriétés peuvent ensuite être ajoutées au volet des résultats de la vue Ordinateurs hôtes.

c. Suppression des machines hôtes Lorsqu’il n’est plus nécessaire de prendre en charge une machine hôte particulière, l’administrateur a la possibilité d’utiliser la console Administrateur SCVMM pour supprimer la machine hôte sélectionnée. Pour des raisons de sécurité, la console Administrateur SCVMM n’autorise pas la suppression de n machines hôtes à l’aide d’une sélection multiple. Une fois la ou les machine(s) hôte(s) supprimée(s), l’agent VMM est automatiquement désinstallé et cellesci ne sont plus gérées à l’aide de SCVMM 2008 R2. À l’issue de l’opération, la ou les machine(s) hôte(s) ainsi que les machines virtuelles sont automatiquement retirées de la base de données SQL et des différentes vues de la console Administrateur SCVMM. La suppression d’une machine hôte de l’environnement SCVMM ne modifie en rien les machines hôtes et machines virtuelles associées. Les platesformes de virtualisation demeurent pleinement opérationnelles, sans avoir été redémarrées, et peuvent être de nouveau ajoutées au même, ou à un autre, environnement SCVMM. Dans le cas où une machine hôte ne serait plus joignable ou dans le cas ou l’administrateur ne disposerait pas des autorisations permettant de désinstaller, l’Agent VMM, il est possible d’utiliser la commande PowerShell Remove VMHost Force. L’utilisation du paramètre Force demande à VMM de ne pas tenter de se connecter à la machine hôte et donc, de ne pas désinstaller l’Agent VMM. Le paramètre Force ne doit être utilisé que pour retirer de manière forcée une machine hôte et pour nettoyer la base de données SCVMM de toutes les données relatives à ce hôte.

- 25 -

Suppression des machines hôtes en cluster et suppression d’un cluster hôte La suppression des machines hôtes en cluster est particulière dans la mesure où les machines hôtes membres du cluster ne sont plus « seulement » des machines hôtes mais, très logiquement, des machines hôtes en cluster. De plus, du point de vue de VMM, l’objet principalement ajouté ou supprimé à l’environnement de virtualisation VMM est directement le cluster Windows Server 2008 R2. La console de gestion Administrateur SCVMM n’autorise pas la suppression des machines hôtes membre d’un cluster. Cellesci devront être supprimées directement en utilisant la console MMC Gestion du cluster de basculement. À l’inverse, la suppression du cluster hôte est tout à fait possible.

Action Supprimer le cluster hôte Finalement, il faut retenir que, de la même manière qu’une machine hôte peut être supprimée d’un environnement VMM donné, un cluster hôte peut l’être aussi. La figure cidessous, illustre cette opération.

Suppression d’un cluster hôte à l’aide de la console Administrateur SCVMM

d. Création des groupes hôtes Les groupes hôtes sont des groupes personnalisés contenant des machines hôtes et aussi d’autres groupes hôtes. Dans un premier temps, les groupes hôtes sont très utiles pour regrouper des machines hôtes et les machines virtuelles qui leur sont associées de manière organisée. Dans un deuxième temps, les groupes hôtes peuvent être très utiles pour réserver des ressources à des machines hôtes, membres du groupe hôte, pour les besoins de la couche de virtualisation ellemême, et aussi de la machine virtuelle parente, c’estàdire le système d’exploitation local. Les groupes hôtes apparaissent dans le volet de navigation de la vue Ordinateurs hôtes et Ordinateurs virtuels sous la forme de dossiers. La figure qui suit illustre la création d’un groupe hôte.

- 26 -

Menu contextuel Nouveau groupe hôte dans la console SCVMM 2008 R2 L’option Nouveau groupe hôte est disponible via les vues Ordinateurs hôtes et Ordinateurs virtuels de la console Administrateur SCVMM.

Propriétés générales d’un groupe hôte

- 27 -

Les propriétés générales permettent d’afficher le nom du groupe hôte, une description, le chemin d’accès par rapport à la racine Tous les ordinateurs hôtes, la liste des machines hôtes membres contenus dans le groupe hôte ainsi que dans tous les groupes hôtes enfants. Cas d’utilisation des groupes hôtes Les points cidessous présentent des cas pratiques du bon usage des groupes hôtes : ●

Modèle d’organisation de base pour gérer un nombre important de machines hôtes et de machines virtuelles : dans ce cas, l’administrateur VMM a la possibilité de créer des vues personnalisées dans la vue Ordinateurs hôtes et dans la vue Ordinateurs virtuels. De cette manière, le suivi et l’accès aux groupes de machines hôtes sont facilités. Comme le montre la figure précédente, il peut être intéressant de créer un groupe hôte pour chaque site géographique de l’entreprise, Montréal, SophiaAntipolis.

●

Modèle d’organisation pour gérer les réserves de ressources des machines hôtes : dans ce cas, l’administrateur VMM peut utiliser une hiérarchie de groupes hôtes pour déterminer les réserves en termes de pourcentage processeur, mémoire, capacité disque, capacité d’entrées/sorties et capacité réseau, qui doivent toujours être disponibles pour le système d’exploitation hôte.

La figure cidessous illustre les propriétés du groupe hôte nommé Infrastructure Salle 1 Baie 5.

Gestion des réserves de ressources sur un groupe hôte Bien sûr, l’administrateur pourra définir des réserves de ressources spécifiques pour chaque groupe hôte. ●

- 28 -

Modèle d’organisation pour gérer les machines hôtes affectées aux portails libreservice. Il peut être judicieux de gérer de manière particulière les machines hôtes à partir desquelles des utilisateurs pourront créer et déployer leur propres machines virtuelles. L’administration du portail Web libreservice VMM nécessite que l’administrateur VMM identifie les machines hôtes à partir desquelles les groupes ou utilisateurs libreservice, disposant de ce rôle, seront autorisés à créer et gérer leurs propres machines virtuelles. L’utilisation d’un groupe hôte spécifique facilitera la gestion de ces machines hôtes.

●

Modèle d’organisation utiliser pour prendre en charge les paramètres PRO : les paramètres cidessous permettent de configurer le comportement de PRO sur le groupe hôte et aussi les machines membres d’un cluster hôte.

Gestion des paramètres PRO au niveau d’un groupe hôte

Lorsqu’un serveur VMware VirtualCenter est ajouté au sein d’un groupe hôte, toutes les machines hôtes existantes pour ce serveur sont également ajoutées. Les machines hôtes sont automatiquement placées dans des groupes hôtes qui correspondent à la hiérarchie des centres de données de chaque serveur. Un groupe hôte est automatiquement créé pour chaque dossier et cluster hôte au sein de chaque centre de données. Les serveurs VMware ESX doivent demeurer dans leur groupe hôte parent ou dans un enfant de ce groupe hôte. Enfin, lorsqu’un nouveau centre de données est ultérieurement ajouté, il apparaîtra en tant que nouveau groupe hôte au sein de la console Administrateur SCVMM lors de la prochaine actualisation.

3. Gestion des librairies a. Introduction Une bibliothèque VMM est un élément incontournable du modèle d’administration de Virtual Machine Manager 2008 R2. Cet objet joue le rôle de catalogue pour offrir aux administrateurs VMM un accès contrôlé aux ressources fichiers nécessaires au déploiement des machines virtuelles : disques durs virtuels, images ISO, fichiers de type Sysprep. De plus, les bibliothèques VMM contiennent aussi les modèles d’ordinateurs virtuels, les profils de systèmes d’exploitation invités et les profils matériels qui résident dans la base de données VMM. Lorsque certaines machines © ENI Editions - All rigths reserved

- 29 -

virtuelles ne sont plus utilisées, l’administrateur VMM peut juger utile de les conserver en les stockant dans une bibliothèque, en vue de leur réutilisation future. À l’issue de l’installation du serveur VMM, une bibliothèque est automatiquement créée sur le serveur VMM. L’emplacement de stockage par défaut est disponible à l’aide du dossier partagé MSSCVMMLibrary localisé dans le dossier : %SystemRoot%\ProgramData\Virtual Machine Manager Library Files.

Recommandation : organisez la structure de chaque bibliothèque en fonction des données qui y seront stockées. Vous pouvez, par exemple, créer des dossiers pour y ranger des scripts PowerShell, des scripts Sysprep, des fichiers VHD contenant des images enrichies prêtes à être déployées.

b. Ajout des serveurs de bibliothèques La console Administrateur SCVMM permet à l’administrateur VMM d’ajouter des serveurs de bibliothèques. Cette fonction, disponible dans toutes les vues de la console Administrateur VMM, est facilement accessible via le menu Action Ajouter un serveur de bibliothèque.

Quand un serveur de bibliothèque a été ajouté, il est toujours possible d’ajouter d’autres partages de bibliothèque supplémentaires à l’aide de l’action Ajouter des partages de bibliothèque dans la vue Bibliothèque. Lorsque la fourniture de machines virtuelles est intense, les serveurs de bibliothèques sont des serveurs de fichiers particulièrement utilisés et critiques. Dans ce type de cas, il est recommandé d’offrir au serveur de bibliothèque un haut niveau de disponibilité en implémentant un cluster de basculement fonctionnant sous Windows Server 2008 R2 Edition Entreprise. Du point de vue de la déclaration d’un serveur de bibliothèque en cluster, il faudra entrer le nom du serveur de fichiers virtuel, au sens cluster. Attention ! VMM 2008 R2 ne prend pas en charge les clusters créés sous Windows Server 2003. L’ajout d’un serveur de bibliothèque installe l’Agent Virtual Machine Manager sur le serveur ayant le rôle Serveur de bibliothèque. De plus, comme cela est le cas sur les machines hôtes, le processus de déploiement de l’Agent VMM utilise les ports SMB, RPC et DCOM. Procédure d’ajout de serveurs de bibliothèques L’assistant Ajouter un serveur de bibliothèque propose à l’administrateur d’entrer les informations d’identification. Comme le fait remarquer l’assistant Ajouter un serveur de bibliothèque, la sélection de plusieurs ordinateurs à ajouter en tant que serveurs de bibliothèques nécessite que le compte d’utilisateur utilisé soit un compte de domaine disposant de droits d’administration sur tous les ordinateurs sélectionnés. Une fois l’authentification réalisée avec succès la fenêtre Sélectionner des serveurs de bibliothèques permet à l’administrateur de rechercher et sélectionner les serveurs souhaités.

- 30 -

Sélection des futurs serveurs de bibliothèques La figure suivante liste l’ensemble des serveurs sélectionnés, les noms des partages de chacun des serveurs ainsi que le chemin d’accès partagé associé.

- 31 -

Sélection des partages à ajouter aux serveurs de bibliothèque La dernière étape consiste à sélectionner les partages qui seront considérés comme partages de bibliothèque.

- 32 -

Fenêtre de vérification des paramètres avant l’ajout des serveurs La suite du processus d’installation déclenche un ensemble de travaux. Ces travaux pourront être suivis à l’aide de la vue Travaux de la console Administrateur SCVMM. Dans notre exemple, trois nouveaux serveurs de bibliothèques sont ajoutés à l’environnement SCVMM.

Détail du travail Ajouter un serveur de bibliothèque La figure cidessus illustre le suivi des opérations de configuration demandées par l’administrateur. La progression de chaque travail est visualisée sous la forme d’une ligne comprenant le nom, l’état, l’heure de début, la cible et le propriétaire de l’opération.

c. Ajout de ressources dans les bibliothèques Pour pouvoir être utilisés dans VMM, les fichiers tels que les disques durs virtuels, les images ISO et autres ressources nécessaires à la création des ordinateurs virtuels doivent être ajoutés à une ou plusieurs bibliothèque (s) VMM.

- 33 -

Détail des différents types de ressources des bibliothèques La figure cidessus montre les différents types d’objets connus au sein d’une bibliothèque : ●

les disques durs virtuels,

●

les fichiers de réponses,

●

les images ISO,

●

les modèles de machines virtuelles invités.

Les fichiers n’apparaissent dans la bibliothèque qu’une fois celleci actualisée. Pour pouvoir utiliser les fichiers immédiatement, vous pouvez actualiser, à l’aide de la console Administrateur SCVMM Bibliothèques ou du bouton droit de la souris, un partage de bibliothèque donné ou un serveur de bibliothèque particulier dans son ensemble.

Option Actualiser De même, si vous déplacez un ordinateur virtuel stocké dans une bibliothèque et que celuici n’a jamais été déployé sur une machine hôte, les partages source et destination doivent être actualisés. Cette opération garantit la mise à jour des chemins d’accès dans la configuration de la machine virtuelle. Les bibliothèques jouent « simplement » le rôle de catalogue au sein de l’environnement VMM. Elles ne sont donc pas impliquées dans le niveau des performances en transfert de données. Néanmoins, il convient de rappeler que l’emplacement des disques durs virtuels et des images ISO aura un impact important sur les performances et sur le trafic occasionné pendant la création et le déploiement des machines virtuelles.

- 34 -

d. Ajout des modèles de machines virtuelles Les modèles de machines virtuelles sont des objets VMM qui permettront aux administrateurs de créer des machines virtuelles basées sur des paramètres matériels et aussi logiciels standard. Les figures qui suivent illustrent le fonctionnement de l’assistant Nouveau modèle. Les utilisateurs du portail Web selfservice VMM utilisent aussi les modèles qui leurs sont assignés pour créer leurs propres machines virtuelles. Ils disposent ainsi de machines virtuelles adaptées à leur besoin en quelques clics.

- 35 -

Deux types de sources peuvent servir de modèle

- 36 -

Fenêtre d’identité du modèle : déclaration du nom et du propriétaire

- 37 -

Fenêtre de création ou de sélection d’un profil matériel Comme le montre la figure cidessus, les profils matériels sont des ressources placées dans les bibliothèques VMM. Ces objets contiennent toutes les caractéristiques matérielles qui seront appliquées lors de la création d’une nouvelle machine virtuelle. Un profil matériel peut ainsi contenir les paramètres de processeurs, type et nombre de processeurs virtuels, de mémoire RAM, de cartes réseaux, de lecteurs CD/DVD, de ports COM, et aussi des paramètres de priorité de la machine virtuelle au moment de l’allocation des ressources par la machine hôte. Un profil matériel peut être créé à la volée, lors de la création d’un nouveau modèle de machine virtuelle, via le menu Actions Actions de la bibliothèque Nouveau modèle. Les options sont identiques à celles disponibles lorsque l’administrateur VMM met à jour la configuration matérielle d’une machine virtuelle, modifie directement un profil matériel ou un modèle de machine virtuelle. Il faut noter que le fait de spécifier un profil matériel lors de la création d’une machine virtuelle n’empêche pas d’en modifier les paramètres importés. Les paramètres peuvent être changés sans affecter en rien le profil ayant été utilisé au départ. Aucune relation directe n’est conservée entre la machine virtuelle créée et le profil matériel utilisé au départ.

- 38 -

Fenêtre de création ou de sélection d’un profil de système d’exploitation invité

- 39 -

Résumé avant la création du nouveau modèle et bouton Afficher le script

La figure cidessus illustre la création du nouveau modèle ainsi que la possibilité d’afficher le script PowerShell associé à l’action. De cette manière, l’administration peut entreprendre la création de dizaines de modèles adaptés à ses besoins simplement en créant un script prévu à cet effet.

e. Dépendances des ressources des bibliothèques L’ensemble des ressources stockées dans les librairies est utilisable au sein des profils matériels, des profils de systèmes d’exploitation invités ou directement par des machines virtuelles. L’administrateur VMM a cependant la possibilité de supprimer des fichiers jugés non nécessaires. Cette opération, réalisable à l’aide de la console Administrateur SCCM ou directement via l’explorateur Windows, aura pour effet de réellement supprimer les fichiers précédemment utilisés.

Suppression à l’aide de la console SCVMM : les fichiers seront réellement détruits Lorsque des fichiers de ressources sont directement supprimés via l’explorateur Windows toute machine virtuelle, modèle de machine virtuelle, profil matériel, profil de système d’exploitation invité faisant référence aux fichiers supprimés devront être « réparés ». Cette opération aura pour effet de supprimer les références aux fichiers précédemment supprimés. À l’inverse, le fait d’utiliser la console de gestion Administrateur SCVMM supprimera - 40 -

proprement des ressources dépendantes toutes les références aux fichiers supprimés. Le tableau cidessous liste les liens possibles entre les fichiers de ressources positionnés au sein des bibliothèques VMM et les objets VMM mis à disposition des administrateurs : Ressources utilisables

Objets SCVMM 2008 R2

Disques durs virtuels, fichiers de réponse, scripts, images ISO

Modèles de machines virtuelles

Fichiers de réponse et scripts

Profils de systèmes d’exploitation invités

Images ISO

Profils matériels

Les disques durs virtuels attachés à une machine virtuelle sont indexés par VMM mais ne sont pas affichés dans les bibliothèques, sauf s’ils y sont déclarés par un administrateur.

Machines virtuelles

Tableau de dépendance des ressources utilisées par les objets VMM

4. Gestion des machines virtuelles a. Opérations de gestion des machines virtuelles La console Administrateur SCVMM permet d’utiliser les actions suivantes pour commander et gérer les machines virtuelles prises en charge par l’environnement de virtualisation :

Actions disponibles sur les machines virtuelles

●

Démarrer : cette action démarre une machine virtuelle arrêtée, suspendue ou dans un état enregistré.

●

Arrêter : cette action arrête une machine virtuelle et n’enregistre aucune information d’état. Cette action a

- 41 -

le même effet sur la machine virtuelle que la coupure électrique d’un ordinateur physique. ●

Suspendre : cette action suspend l’exécution d’une machine virtuelle et conserve en mémoire tous les états de la machine virtuelle.

●

Enregistrer l’état : cette action suspend l’exécution d’une machine virtuelle et enregistre son état actuel sur le disque afin de libérer de la mémoire et des ressources processeur pour les autres machines virtuelles. Lorsque la machine virtuelle est restaurée à partir d’un état enregistré, celleci est renvoyée dans la position à laquelle elle se trouvait quand l’état a été enregistré.

●

Ignorer l’état de mise en mémoire : cette action ignore l’état enregistré d’une machine virtuelle. La machine virtuelle est alors désactivée.

●

Arrêt : cette action arrête le système d’exploitation invité de la machine virtuelle.

●

Se connecter à l’ordinateur virtuel : cette action permet de se connecter à une machine virtuelle via le protocole RDP (Remote Desktop Protocol). La console SCVMM essaie de se connecter à une machine virtuelle en cours de fonctionnement. Pour ouvrir une fenêtre de connexion plus large afin de se connecter à la machine virtuelle, il suffit de double cliquer sur la miniature ou d’utiliser le menu Actions Se connecter à l’ordinateur virtuel.

Pour rappel, VMM 2008 R2 utilise toujours le protocole VMRC (Virtual Machine Remote Control), pour les machines virtuelles prises en charge par Virtual Server et VM Connect (port par défault 2179) pour les machines virtuelles prises en charge par des machines hôtes HyperV.

b. Gestion des configurations, les disques et les points de contrôle Les actions listées cidessous sont disponibles via le même menu pour les administrateurs SCVMM : ●

Réparer : cette action répare une machine virtuelle défaillante en réitérant l’action à l’origine de l’échec, en restaurant la machine virtuelle à son état antérieur à l’action ayant engendré l’échec. Une fois le problème corrigé, l’état de la machine virtuelle est actualisé au sein de la console SCVMM.

Lorsque la machine virtuelle est considérée par VMM comme étant défaillante, l’option Réparer est considérée comme l’action par défaut. La boîte de dialogue Réparer est aussi automatiquement ouverte à l’aide d’une action de type double clic.

- 42 -

●

Désactiver les disques d’annulations : cette action est particulière à l’environnement Microsoft Virtual Server 2005. Elle désactive les disques d’annulations supportés par Virtual Server, puis fusionne ou ignore les modifications. Cette opération permet à VMM de prendre en charge la machine virtuelle.

●

Nouveau point de contrôle : cette action crée un point de contrôle permettant de restaurer une machine virtuelle à son état actuel. L’action enregistre l’état de chaque disque dur virtuel attaché à la machine virtuelle, y compris les fichiers de données. Ainsi une sauvegarde temporaire de la machine virtuelle pourra être utilisée en cas de nécessité.

●

Gérer les points de contrôle : cette action ouvre la fenêtre Points de contrôle permettant de créer, de modifier et de fusionner des points de contrôle. Elle permet aussi de restaurer une machine virtuelle à un point de contrôle donné.

●

Installer les services d’invité virtuel : cette action installe les services d’invité, services d’intégration d’HyperV ou les composants additionnels nécessaires aux machines virtuelles prises en charge par les machines hôtes fonctionnant sous Microsoft Virtual Server 2005 R2 SP1.

●

Désactiver : cette action désactive une machine virtuelle stockée dans une bibliothèque afin de provisoirement empêcher son utilisation. Une machine virtuelle désactivée reste stockée dans une bibliothèque. Cependant, elle ne peut plus être ni déployée, ni réparée.

●

Propriétés : cette action modifie les propriétés d’une machine virtuelle.

L’ouverture de la fenêtre de propriétés d’une machine virtuelle est l’action par défaut lorsque la machine virtuelle est dans un état de bon fonctionnement État sain.

c. Création et déploiement d’une machine virtuelle La console Administrateur SCVMM permet à l’administrateur de créer des machines virtuelles à destination de machines hôtes fonctionnant sous HyperV, HyperV Server, Virtual Server 2005 et des machines hôtes fonctionnant sous VMware ESX.

Action Nouvel ordinateur virtuel

SCVMM 2008 R2 avec un cluster d’hôtes 2 nœuds, et une machine hôte supplémentaire La création des machines virtuelles est assistée de bout en bout et peut suivre différents scénarios tels que : ●

La création d’une machine virtuelle à partir d’un modèle de la bibliothèque,

●

La création d’une machine virtuelle à partir d’un disque dur virtuel existant dans la bibliothèque,

●

La création d’une machine virtuelle à partir d’un disque dur virtuel vide,

●

La création d’une machine virtuelle à partir d’une autre à l’aide de l’opération « Cloner ».

Les étapes qui suivent illustrent le cas du déploiement d’une nouvelle machine virtuelle au sein d’une infrastructure © ENI Editions - All rigths reserved

- 43 -

virtuelle composée de machines hôtes HyperV disposant des fonctionnalités de haute disponibilité, de machines hôtes et de bibliothèques. La première étape consiste à invoquer l’assistant Nouvel ordinateur virtuel. Cet assistant est disponible : ●

Dans toutes les vues de la console Administrateur SCVMM via le volet Actions,

●

Au sein des bibliothèques via le menu contextuel en étant positionné sur un modèle de machine virtuelle ou directement sur un disque dur virtuel stocké dans la bibliothèque.

Étape 1 : sélectionner une source Le premier écran de l’assistant propose à l’administrateur de sélectionner la source de la nouvelle machine virtuelle.

Étape de sélection de la source de la machine virtuelle Dans notre exemple, l’administrateur a choisi de créer une machine virtuelle basée sur un disque dur virtuel vide. Cependant, il est plus rapide et plus pratique de directement créer cette nouvelle machine virtuelle en utilisant des objets déjà existants au sein d’une bibliothèque VMM. Dans ce cas, l’administrateur pourra, tel que le montre la figure cidessous, faire son choix sur la base de machines virtuelles déjà existantes, sur la base de modèles de machines virtuelles ou de disques durs virtuels déjà préparés.

- 44 -

Étape de sélection de l’objet à utiliser en tant que source de création Étape 2 : identité de la machine virtuelle Une fois, l’élément de type modèle de machine virtuelle ou disque dur virtuel choisi, l’assistant Nouvel ordinateur virtuel propose de renseigner certaines informations générales telles que le nom, le propriétaire et une description de la machine virtuelle.

- 45 -

Étape d’identification de la machine virtuelle Étape 3 : configurer le matériel Les étapes suivantes permettent de configurer les ressources matérielles de la future machine virtuelle et de sélectionner la destination de celleci. La configuration des ressources est basée sur l’utilisation des profils matériels créés au préalable par l’administrateur ou sur des paramètres particuliers à cette machine virtuelle. Le choix de la destination pourra être dirigé vers une machine hôte mais aussi vers une bibliothèque dans le cas où la machine virtuelle est créée pour un usage futur, déploiement ultérieur ou création de machines virtuelles à partir de celleci, servant de modèle.

- 46 -

Étape de configuration du matériel via la sélection d’un profil matériel adapté Étape 4 : sélectionner la destination

- 47 -

Étape de sélection de la destination de la machine virtuelle Déploiement ou Stockage Étape 5 : sélectionner une bibliothèque ou une machine hôte Comme expliqué précédemment, l’étape de sélection de la destination de la machine virtuelle permet de placer la machine virtuelle vers une machine hôte ou bien de la « ranger » en vue d’une utilisation ultérieure dans une bibliothèque. La figure cidessous illustre la sélection que l’administrateur VMM peut être amené à faire :

- 48 -

Étape de sélection d’un serveur de bibliothèque et méthode de transfert utilisée

- 49 -

Étape de sélection de la machine hôte en fonction de la sélection élective La figure cidessus, Sélectionner l’ordinateur hôte, permet à l’administrateur de sélectionner la machine hôte sur laquelle la machine virtuelle sera déployée. Toutes les machines hôtes disponibles évaluées sont affichées. La colonne Évaluation propose un classement basé sur un nombre d’étoiles de 0 à 5, permettant ainsi à l’administrateur de réaliser le meilleur choix en fonction de la capacité d’hébergement de chaque machine hôte par rapport aux exigences contenues dans la configuration de la machine virtuelle. Ces évaluations sont des recommandations qui permettent à l’administrateur de sélectionner la machine hôte parmi toutes celles disposant des ressources nécessaires. Cette évaluation utilise les paramètres de sélection élective disponibles via les paramètres généraux de VMM et l’option Cet ordinateur hôte est disponible pour la sélection élective via l’onglet État des propriétés d’une machine hôte. Notez que la rubrique Détails indique l’état de la machine hôte, la version du système d’exploitation, le type et l’état de fonctionnement de la plateforme de virtualisation. Lorsqu’une machine hôte reçoit une évaluation égale à zéro, l’onglet Explication de l’évaluation affiche la liste des points ayant généré l’évaluation. Notez que les critères d’évaluation de la machine hôte pour la machine virtuelle sélectionnée peuvent être réévalués à l’aide du bouton Personnaliser. L’administrateur peut ainsi modifier les contraintes de la sélection élective ou l’importance relative concernant la disponibilité du processeur, de la mémoire, de la capacité des E/S disques, et la capacité réseau pour l’ordinateur virtuel actif. Étape 6 : sélectionner le chemin d’accès La figure suivante illustre la sélection du chemin d’accès dans lequel seront stockés les fichiers de configuration de la machine virtuelle. La création de la machine virtuelle pourra avoir lieu à l’aide des transferts SAN. Si les transferts SAN sont activés pour ce déploiement, la machine virtuelle est transférée par défaut vers la machine hôte via le réseau SAN.

- 50 -

Étape de sélection du chemin d’accès à la machine virtuelle

- 51 -

Explication SAN : le transfert n’utilisera pas le SAN mais le réseau TCP/IP

La case à cocher Transférer sur le réseau même si un transfert SAN est disponible permet de ne pas utiliser le réseau SAN. Dans ce cas, le réseau TCP/IP sera utilisé normalement pour assurer un transfert entre les serveurs de bibliothèques et les machines hôtes. Notez que lorsque l’architecture physique ne le supporte pas, l’option n’est pas disponible. Étape 7 : sélectionner des réseaux La dernière étape consiste à associer la machine virtuelle à un ou des réseaux virtuels pris en charge par la machine hôte cible. L’assistant propose de procéder à cette ultime étape de rattachement vers la machine hôte sélectionnée. Pour déterminer quels sont les réseaux à proposer à la machine virtuelle, VMM détermine les réseaux disponibles sur la machine hôte choisie en proposant à l’administrateur une liste déroulante affichant la légende et l’emplacement réseau spécifiés au niveau de la carte réseau virtuelle dans la configuration matérielle. La figure suivante illustre la sélection du ou des réseau(x) sur le(s)quel(s) la nouvelle machine devra se trouver à l’issue de son déploiement.

- 52 -

Étape de sélection des réseaux virtuels à utiliser sur la machine hôte Ainsi, les champs Emplacement et Légende réseau sont utilisés au moment du placement de la machine virtuelle sur une machine hôte. Lors de l’évaluation des prérequis de la machine virtuelle, ces informations sont comparées aux possibilités offertes par les machines hôtes. Cette opération permet de proposer à l’administrateur une machine hôte qui puisse répondre le mieux possible aux exigences de la machine virtuelle. La figure cidessous illustre les exigences définies au niveau de la machine virtuelle.

- 53 -

Déclaration des Conditions de connexion à l’aide des emplacements et des légendes dans la configuration de la machine virtuelle Comme vous pouvez le constater, l’administrateur a la possibilité de sélectionner ces exigences parmi une liste d’emplacements et de légendes réseau. Par exemple, si la machine virtuelle devant être déployée devait disposer d’une interface réseau placée dans un réseau réservé aux trafics d’administration, l’administrateur pourrait choisir, sans se tromper, l’emplacement réseau nommé « DMZManagement » Le paramètre réseau permet à la logique de sélection élective de déterminer une équivalence entre les réseaux virtuels pris en charge par plusieurs machines hôtes. Les réseaux virtuels déterminent leur emplacement à partir de la carte hôte qui leur est associée. Notez qu’il est possible de lier plusieurs cartes réseau de machines hôtes à plusieurs réseaux virtuels, chaque carte hôte disposant d’une seule et unique adresse en guise d’emplacement. Une telle configuration permet à une machine virtuelle de changer d’emplacement tout en conservant la connectivité nécessaire. La barre d’outils de la console Administrateur SCVMM permet d’afficher une vue de la mise en réseau de la plateforme de virtualisation tout entière en définissant l’étendue de la vue. L’administrateur peut ainsi visualiser toutes les associations existant entre les machines virtuelles et les différentes interfaces virtuelles des machines hôtes.

Barre d’outils de la console Administrateur SCVMM Le bouton Étendue permet de sélectionner quels groupes hôtes ou quelles machines hôtes au sein de ces groupes hôtes doivent être insérés au sein de la vue.

- 54 -

Mise en réseau : vue de la configuration des interfaces réseau d’une machine hôte Étape 8 : propriétés supplémentaires L’étape suivante permet de configurer les actions à effectuer sur une machine virtuelle lors du démarrage et/ou lors de l’arrêt du service de virtualisation sur la machine hôte. Ces options sont configurables lors d’une opération de déploiement, de migration ou lorsque les propriétés de la machine virtuelle sont mise à jour. Pour spécifier l’action souhaitée au démarrage, modifiez l’option Action lors du démarrage du serveur physique et sélectionnez l’option en fonction des contraintes de démarrage de la machine hôte : ●

Ne jamais activer automatiquement l’ordinateur virtuel.

●

Toujours activer automatiquement l’ordinateur virtuel.

●

Activer automatiquement l’ordinateur virtuel s’il s’exécutait quand le serveur physique s’est arrêté.

- 55 -

Actions au démarrage et à l’arrêt de la machine hôte HyperV

Il est possible de retarder le démarrage d’une machine virtuelle, dans la limite de 32 767 secondes, soit environ 9 heures. Ce retard de démarrage imposé permet de définir l’ordre dans lequel les machines virtuelles doivent démarrer. La possibilité de jouer sur ce paramètre permet aux administrateurs de contrôler l’ordre de démarrage des machines virtuelles sur chaque machine hôte. Pour spécifier l’action souhaitée à l’arrêt du service HyperV, sélectionnez le choix Action lors de l’arrêt du serveur physique puis sélectionnez l’une des options suivantes : ●

Enregistrer l’état.

●

Désactiver l’ordinateur virtuel.

●

Arrêter le système d’exploitation invité.

●

Spécifiez le système d’exploitation à installer sur l’ordinateur virtuel.

Étape 9 : résumé La dernière étape résume les paramètres avant la confirmation du déploiement de la nouvelle machine virtuelle.

- 56 -

Étape de résumé pour vérification avant la création finale L’option Démarrer l’ordinateur virtuel après l’avoir déployé sur l’ordinateur hôte pourra être sélectionnée pour démarrer la nouvelle machine virtuelle après son déploiement. Le bouton Afficher le script permet à l’administrateur de facilement récupérer le script utilisé par VMM pour réaliser l’opération demandée. La totalité des tâches d’administration de VMM peut être effectuée à partir de la ligne de commande ou sous forme de script utilisant l’interface de commande Windows PowerShell. Suivi des opérations de création et de déploiement Une fois le bouton Créer actionné, un certain nombre de travaux seront automatiquement exécutés pour déployer la nouvelle machine. Enfin, afin de permettre à l’administrateur de suivre la progression et le résultat final de l’opération, la fenêtre Travaux s’ouvrira automatiquement dès la fermeture de l’assistant. Pour afficher cette fenêtre à tout moment, cliquez sur le bouton Mes travaux dans la barre des tâches de la fenêtre principale de la console Administrateur SCVMM.

- 57 -

Fenêtre de suivi du travail Créer un ordinateur virtuel La figure suivante illustre l’intégration de l’opération de suivi au sein de la console Administrateur SCVMM.

État du travail : création et déploiement de la machine virtuelle SCOM02 L’item État : Création en cours… montre l’état d’avancement général, tandis que les détails sont affichés dans la partie inférieure de l’interface. De plus, la figure cidessus illustre le déroulement, séquentiel « parallélisé » des opérations de création des objets nécessaires à la nouvelle machine virtuelle ainsi que son déploiement au sein de l’infrastructure de virtualisation à l’aide du travail NewVM :

- 58 -

Étape 1 : Créer un ordinateur virtuel. ●

Sousétape 1.1 : Créer un ordinateur virtuel.

●

Sousétape 1.2 : Déployer le fichier à l’aide de BITS.

●

Sousétape 1.3 : Corriger les disques de différenciation.

●

Sousétape 1.4 : Modifier les propriétés de l’ordinateur virtuel.

●

Sousétape 1.5 : Ajouter une ressource.

●

Sousétape 1.5.1 : Déployer le fichier à l’aide du LAN.

●

Sousétape 1.5.2 : Corriger les disques de différenciation.

Sousétape 1.6 : Installer les composants d’ordinateur virtuel. ●

Sousétape 1.6.1 : Démarrer l’ordinateur virtuel pour installer les composants d’ordinateur virtuel.

●

Sousétape 1.6.2 : Arrêter l’ordinateur virtuel.

d. Déploiement d’une machine virtuelle Nous avons vu précédemment les étapes de création et de déploiement d’une machine virtuelle en vue de son placement sur la meilleure machine hôte. VMM 2008 R2 permet aussi de développer le concept de machine virtuelle Provisionning en utilisant pleinement les bibliothèques VMM. L’opération de déploiement d’une machine virtuelle à partir d’une bibliothèque supprime la machine virtuelle de la librairie dès lors qu’elle est placée sur la machine hôte de destination.

Option Déployer une machine virtuelle stockée dans une bibliothèque

Attention à ne pas confondre l’option Déployer et l’option Nouvel ordinateur virtuel. La première option déplace une machine virtuelle « rangée » dans une bibliothèque vers une machine hôte. La deuxième crée une nouvelle machine virtuelle sur la base d’un disque dur virtuel vierge, d’un disque dur virtuel de production ou d’un modèle de machine virtuelle. Dans le cas où il est nécessaire de conserver la machine originale source, il suffira d’utiliser l’assistant Nouvel ordinateur virtuel.

- 59 -

Option Nouvel ordinateur virtuel Pour créer une nouvelle machine virtuelle sur la base d’objets existant dans des bibliothèques VMM, utilisez l’option Utiliser un ordinateur virtuel, un modèle ou un disque dur virtuel existant.

e. Migration d’une machine virtuelle VMM 2008 R2 permet à l’administrateur de migrer une machine virtuelle donnée d’une machine hôte vers une autre machine hôte si ces machines hôtes utilisent la même plateforme de virtualisation. Toutes les platesformes de virtualisation supportées par VMM, c’estàdire HyperV, Virtual Server et VMware ESX, supportent la fonctionnalité de migration, sachant qu’il est aussi possible de réaliser une opération de migration dans le sens Virtual Server vers HyperV. Plusieurs méthodes peuvent être utilisées pour réaliser la migration d’une machine hôte vers une autre machine hôte :

- 60 -

●

À l’aide de la souris, faire un glissédéposé de la machine virtuelle vers la machine hôte de destination.

●

À l’aide de la souris, faire un glissédéposé de la machine virtuelle vers un groupe de machines hôtes. Cette opération fait appel aux fonctionnalités d’évaluation du placement automatique. L’assistant proposera à l’administrateur la liste contenant l’évaluation des machines hôtes pour réaliser au dernier moment, le meilleur choix.

●

À l’aide du menu Actions Migrer : cette action démarre l’assistant Migration de l’ordinateur virtuel. L’assistant proposera alors à l’administrateur de sélectionner la meilleure machine hôte, de spécifier l’emplacement du stockage et le type de transfert à utiliser.

Option Migrer

Lorsque l’administrateur réalise une action de type Migrer dans un environnement de cluster fonctionnant sous Windows Server 2008 non R2, alors SCVMM 2008 R2 utilisera la fonctionnalité de Migration rapide, en anglais Quick Migration. Dans ce cas, la migration d’une machine virtuelle provoquera l’enregistrement de l’état de l’ordinateur virtuel, d’où une perte de service temporaire pour tous les utilisateurs de la machine virtuelle en cours de transfert. S’agissant d’un cluster de machines hôtes fonctionnant sous Windows Server 2008 R2, SCVMM 2008 R2 utilisera la fonctionnalité de Migration en direct, en anglais Live Migration, laquelle ne provoque aucune perte de service, ni aucune déconnexion réseau.

Option Migrer : l’utilisation de Quick Migration provoquera une perte temporaire de service La figure suivante illustre l’exécution des tâches liées à l’opération de migration de la machine virtuelle vers une autre machine hôte.

- 61 -

Vue Travaux Déplacer l’ordinateur virtuel

SCVMM 2008 R2 utilise de manière sousjacente les fonctionnalités de migration à chaud supportées par Windows Server 2008, Quick Migration, et Windows Server 2008 R2, Live Migration.

f. Clonage d’un ordinateur virtuel VMM 2008 R2 permet à l’administrateur de cloner une machine virtuelle. Une opération de clonage réalise une parfaite copie d’une machine virtuelle hébergée sur une machine hôte, dans ce cas, la machine virtuelle devra être dans l’état Arrêté, ou stockée au sein d’une bibliothèque. Une opération de clonage recopie la machine virtuelle arrêtée à l’identique. De fait, l’administrateur devra penser à reconfigurer la machine, notamment concernant le SID qui aura exactement la même valeur que l’original.

- 62 -

L’opération de clonage est directement intégrée dans le volet Actions. Cependant, elle n’est active que lorsque la machine virtuelle n’est pas en fonctionnement. L’opération de clonage peut aussi être utilisée pour effectuer des sauvegardes de machines virtuelles existantes. Lorsqu’une machine virtuelle fait l’objet d’une opération de clonage, l’assistant Nouvel ordinateur virtuel est démarré. L’assistant permet de spécifier d’autres paramètres matériels mais ne permet pas d’apporter des changements au système d’exploitation.

g. Mise en réseau des machines virtuelles et propriétés des machines hôtes La configuration d’une machine virtuelle supporte la mise en œ uvre de 4 cartes réseau émulées et 8 cartes réseau synthétiques. L’administrateur VMM a donc la possibilité de configurer une ou plusieurs cartes réseau virtuelles pour une machine virtuelle donnée. La gestion de la connectivité réseau apparaît donc à deux niveaux : ●

Au niveau des machines virtuelles,

●

Au niveau des machines hôtes.

Connectivité réseau des machines virtuelles La configuration des cartes réseau peut être réalisée directement au niveau d’une machine virtuelle, d’un modèle de machine virtuelle ou dans les paramètres des profils matériels à partir de l’assistant Nouveau modèle ou de l’assistant Nouvel ordinateur virtuel. Ainsi, lorsqu’il est nécessaire que des machines virtuelles aient la possibilité de se connecter à des réseaux internes et des réseaux externes, il est facile d’ajouter une ou plusieurs cartes réseau virtuelles. La figure cidessous illustre les paramètres de carte réseau d’une machine virtuelle :

- 63 -

Carte réseau virtuelle et affichage des conditions de Sélection effective En plus des paramètres classiques, la carte peut être caractérisée avec des conditions de connexion réseau. Ces conditions seront utilisées par la sélection élective lors des opérations de migration des machines virtuelles entre machines hôtes. Les paramètres d’emplacement réseau et de légende réseau sont présentés cidessous : Emplacement réseau Ce paramètre permet de spécifier le nom du réseau sur lequel l’administration souhaite que la machine virtuelle soit positionnée. La valeur déclarée permet à la sélection élective de déterminer une équivalence entre les réseaux virtuels comportant de multiples machines hôtes. Par défaut, les réseaux virtuels déterminent leur emplacement à partir de la carte réseau de la machine hôte associée. Toutefois, il est possible de lier plusieurs cartes réseau hôtes à plusieurs réseaux virtuels tout en définissant une seule adresse d’emplacement. Cette possibilité permet à la machine virtuelle de changer d’emplacement tout en conservant la connectivité adéquate. En général, l’emplacement réseau est déterminé par la machine hôte en utilisant le service NLA Windows (Network Location Awareness). La machine détermine un nom sur la base du nom DNS. Pour plus d’informations sur le protocole NLA, consultez le lien suivant : http://msdn.microsoft.com/enus/library/ms740558 (VS.85).aspx. Dans certains cas, VMM ne peut déterminer l’emplacement réseau via l’utilisation de NLA, par exemple, dans le cas des machines VMware ESX ou des cartes réseau fonctionnant en mode bouclage Loopback mode. VMM prend en charge le contournement de la découverte des emplacements réseau en permettant à l’administrateur de clarifier cette valeur. Cette option est présentée plus loin. Légende réseau Ce paramètre est une propriété de réseau virtuel qui permet de définir des contraintes précises sur l’accès réseau - 64 -

d’une machine virtuelle. Il est, par exemple, possible de configurer le réseau virtuel d’administration en lui attribuant la légende Management. Gestion des emplacements et des légendes sur les machines hôtes La déclaration des noms à utiliser comme emplacements réseaux permettra à la fonctionnalité de sélection élective de proposer des machines hôtes disposant de la connectivité et des réseaux virtuels demandés. La figure ci dessous montre les propriétés réseaux de carte Connexion au réseau local 3 de la machine hôte vmm01.mycorp.net. L’emplacement réseau découvert via NLA est remplacé par la valeur DMZ Management.

Propriétés physiques des réseaux d’une machine hôte Gestion des réseaux virtuels sur un ordinateur hôte Les machines hôtes HyperV utilisent les réseaux virtuels supportés par Windows Server 2008 R2. La possibilité de créer des réseaux logiques indépendants au sein d’un réseau physique facilite l’administration du réseau grâce à la séparation de segments logiques. Le fait que VMM prenne en charge de manière logicielle la gestion des réseaux virtuels facilite les possibilités de déplacement des machines virtuelles entre les machines hôtes.

- 65 -

Propriétés des réseaux virtuels d’une machine hôte Pour assurer la prise en charge réseau des machines hôtes HyperV, VMM met en oeuvre des ports sur lesquels sont associés des légendes. Ainsi, sur un réseau virtuel HyperV chaque port peut être configuré de manière à appartenir à différents réseaux locaux virtuels. L’interface permet de configurer des réseaux locaux virtuels en affectant un ID de VLAN au niveau du port. En interne, tout le trafic réseau en provenance de ce port est alors identifié avec cet ID de VLAN. La procédure ci dessous liste les différentes étapes pour ajouter ou modifier un réseau virtuel HyperV sur une machine hôte Hyper V :

- 66 -

■

À l’aide de la console Administrateur SCVMM, positionnezvous dans Ordinateurs virtuels, puis accédez aux Propriétés d’une machine hôte.

■

Sélectionnez l’onglet Mise en réseau,

■

Cliquez sur Ajouter pour créer un nouveau réseau virtuel.

■

Dans la liste Mise en réseau virtuelle, cliquez sur un réseau existant à modifier.

■

Dans la zone Détails du réseau virtuel, dans la zone Nom, tapez un nom pour le réseau virtuel.

■

Dans la zone Légende réseau, tapez ou sélectionnez la légende réseau à utiliser.

■

Dans la zone Description, tapez une description.

■

Dans la zone Liaisons réseau, cliquez sur Réseau privé pour créer un réseau interne permettant aux machines virtuelles de la machine hôte de communiquer les unes avec les autres, mais pas avec l’ordinateur hôte. Cliquez sur Réseau interne pour créer un réseau interne permettant aux ordinateurs virtuels sur l’ordinateur hôte de © ENI Editions - All rigths reserved

communiquer les uns avec les autres, ainsi qu’avec l’ordinateur hôte. Dans ce cas, si vous souhaitez autoriser les ordinateurs virtuels à accéder à l’ordinateur hôte par le biais d’un réseau local virtuel, procédez comme suit : Activez la case à cocher Accéder à l’ordinateur hôte par le biais d’un VLAN. Puis dans la zone ID du réseau local virtuel, sélectionnez l’ID de réseau local virtuel à utiliser. Enfin, cliquez sur Carte réseau physique pour créer un réseau externe lié à une carte réseau physique afin que les ordinateurs virtuels sur l’ordinateur hôte puissent accéder à un réseau physique. ■

Pour configurer la carte réseau liée, procédez comme suit : Si vous ne souhaitez pas que les ordinateurs virtuels de l’ordinateur hôte accèdent à l’ordinateur hôte (configuration par défaut), désactivez la case à cocher Accès des ordinateurs hôtes. Si vous souhaitez autoriser les ordinateurs virtuels à accéder à l’ordinateur hôte par le biais d’un réseau local virtuel, vérifiez que la case à cocher Accès des ordinateurs hôtes est activée, puis, dans la zone ID du réseau local virtuel, sélectionnez l’ID de réseau local virtuel à utiliser. Cliquez sur Ajouter, puis, dans la boîte de dialogue Changer de liaison, procédez comme suit : ●

Dans la liste Carte réseau de l’ordinateur hôte, cliquez sur une carte réseau pour ce réseau virtuel. Si vous souhaitez activer les réseaux locaux virtuels sur cette carte réseau, activez la case à cocher Activer les VLAN sur cette connexion, puis effectuez l’une des opérations suivantes : cliquez sur Mode access, puis, dans la zone ID du réseau local virtuel, sélectionnez l’ID de réseau local virtuel à utiliser ou cliquez sur Mode trunk, puis activez ou non la case à cocher Relier tous les ID de VLAN. Dans la zone ID du réseau local virtuel, sélectionnez l’ID de réseau local virtuel à utiliser, puis cliquez sur Ajouter. Vous pouvez ajouter plusieurs ID de réseau local virtuel.

Attention ! Avant d’activer les réseaux locaux virtuels sur cette carte réseau, vérifiez qu’il y aura au moins une autre carte réseau disponible pour les communications entre l’ordinateur hôte et le serveur VMM.

5. Gestion des rôles La gestion des rôles est une fonctionnalité nécessaire pour déléguer les opérations d’administration et de gestion des machines virtuelles à des utilisateurs ou groupes d’utilisateurs choisis. Un rôle d’utilisateur peut être comparé à un groupe de sécurité au sein des services d’annuaire Active Directory. Les rôles offerts par VMM sont donc basés sur des utilisateurs ou des groupes d’utilisateurs disposant de certaines permissions. Le profil du rôle d’un utilisateur détermine les actions réalisables par cet utilisateur tandis que l’étendue du rôle d’un utilisateur détermine les objets qu’il pourra gérer. VMM 2008 R2 supporte les trois grands rôles suivants.

a. Rôle Administrateur Ce rôle d’utilisateur dispose d’un accès complet au serveur VMM 2008 R2 et aux objets contenus dans les bibliothèques VMM. Les administrateurs VMM peuvent donc gérer l’accès aux bibliothèques des utilisateurs ou groupes. Un seul rôle administrateur existe. Il n’est donc pas possible, ni de le détruire, ni de créer d’autres rôles basés sur ce modèle. De plus, les membres de ce rôle peuvent utiliser la console Administrateur SCVMM ainsi que l’ensemble des commandes d’administration de l’invite de commande PowerShell. Cependant, les membres de ce rôle ne disposent pas d’un accès au portail VMM libreservice. Pour accéder au portail VMM libreservice, ils doivent disposer aussi du rôle Utilisateur libreservice.

b. Rôle Administrateur délégué Ce rôle permet aux utilisateurs de réaliser la plupart des actions via la console Administrateur SCVMM, mais uniquement dans l’étendue définie dans le rôle. Les membres de ce rôle d’utilisateur peuvent créer de nouveaux rôles d’utilisateurs Administrateur délégué et aussi des Utilisateurs Libreservice.

- 67 -

Bien entendu, les utilisateurs disposant du rôle Administrateur délégué n’ont pas la possibilité de s’octroyer le rôle Administrateur. Comme pour les utilisateurs disposant du rôle Administrateur, les administrateurs délégués peuvent utiliser la console Administrateur SCVMM ainsi que l’ensemble des commandes d’administration de l’invite de commande PowerShell. Cependant, les membres de ce rôle ne disposent pas d’un accès au portail VMM libre service. Pour accéder au portail VMM libreservice, ils doivent disposer aussi du rôle Utilisateur libreservice. Un administrateur délégué peut réaliser les opérations suivantes sur les objets contenus dans l’étendue déclarée pour ce rôle, à savoir : ●

Voir, créer et gérer les groupes hôtes, les hôtes, les réseaux virtuels.

●

Voir, créer, modifier et migrer des machines virtuelles.

●

Ajouter des serveurs de bibliothèques à l’infrastructure de virtualisation VMM.

●

Gérer les ressources des machines virtuelles sur tous les serveurs de bibliothèques.

●

Créer des rôles utilisateur.

●

Voir, modifier et supprimer les rôles utilisateurs qu’ils ont créés.

●

Réaliser toutes les opérations d’administration au sein de l’étendue de leur rôle sauf les opérations suivantes : ils ne peuvent pas voir, modifier ou supprimer des rôles utilisateurs créés par d’autres administrateurs ou administrateurs délégués.

Ces opérations ne peuvent pas être changées.

c. Utilisateur libreservice Les utilisateurs disposant de ce rôle peuvent accéder au portail VMM libreservice pour effectuer sur les ordinateurs virtuels détenus les tâches définies au niveau du rôle d’utilisateur. Bien entendu, les membres de ce rôle d’utilisateur ne peuvent pas créer de nouveaux rôles d’utilisateurs. Les utilisateurs du portail ont la possibilité de stocker leurs propres machines virtuelles sur certains serveurs de bibliothèques. De plus, VMM 2008 R2 permet aux utilisateurs du portail de créer, gérer et supprimer des machines virtuelles de manière complètement transparente qu’il s’agisse d’opérations réalisées vers des machines hôtes HyperV ou bien des machines hôtes VMware ESX. Les utilisateurs disposant du rôle Utilisateur libreservice peuvent accéder à l’invite de commande PowerShell, mais ne disposent pas d’un accès à la console Administrateur SCVMM. De plus, les droits qu’ils possèdent sont limités à leurs propres machines virtuelles exclusivement. Un utilisateur disposant du rôle utilisateur libreservice peut réaliser les opérations suivantes sur les objets contenus dans l’étendue déclarée pour ce rôle, à savoir : ●

Créer, démarrer, arrêter, mettre en pause, reprendre le fonctionnement d’une machine virtuelle.

●

Créer, supprimer et appliquer des points de contrôle, captures instantanées.

●

Supprimer les machines virtuelles qu’il a créées.

Un utilisateur du portail libreservice a la capacité de fixer le mot de passe de l’administrateur des machines virtuelles qu’il crée, faisant ainsi de lui l’administrateur de la machine virtuelle. Les propriétés d’un rôle permettent aussi de définir quelles bibliothèques sont accessibles à quels utilisateurs du portail libreservice. De cette manière, les utilisateurs du portail ont aussi la possibilité de ranger leurs machines virtuelles inutilisées au sein des bibliothèques. Lorsque des utilisateurs utilisent l’espace de stockage des bibliothèques, l’espace consommé dans les bibliothèques n’est pas comptabilisé. Les machines virtuelles des utilisateurs du portail libreservice sont déployées automatiquement sur la machine hôte la mieux adaptée sur la base des groupes hôtes déclarés dans les prérequis de chaque machine virtuelle et des paramètres définis au niveau de la plateforme VMM. Le placement des machines virtuelles est donc

- 68 -

complètement automatisé de telle sorte qu’au final les utilisateurs ne savent pas où la machine virtuelle a été déployée. Les utilisateurs du portail libreservice ont la possibilité d’accéder aux fichiers de disques durs et aux images ISO disponibles dans les bibliothèques uniquement pendant la phase de création de leurs machines virtuelles. De plus, l’usage de ces ressources ne leur permet pas de déterminer l’emplacement exact des fichiers utilisés. Les figures cidessous illustrent les propriétés offertes par VMM concernant la gestion des rôles.

Propriétés générales d’un rôle basé sur l’Administrateur délégué

- 69 -

Membres du rôle créé sur la base d’utilisateurs, ou de groupes, Active Directory

- 70 -

Rôles et étendue : sélection des groupes hôtes en délégation pour le rôle créé

6. Utilisation du portail en libreservice L’utilisation du portail libreservice VMM permet aux utilisateurs habilités de créer, gérer et utiliser leurs propres machines virtuelles de manière totalement autonome au sein de l’environnement de virtualisation HyperV. Pour mettre en œ uvre le portail libreservice VMM, les étapes suivantes doivent être réalisées : ●

Le composant Portail libreservice doit être installé sur un serveur disposant d’IIS fonctionnant sous Windows Server 2003 ou sous Windows Server 2008 R2. Le portail peut être installé sur une machine dédiée, mais il résidera le plus souvent sur la machine jouant le rôle de serveur VMM.

●

Afin de limiter la portée du portail libreservice VMM, il est recommandé de créer un groupe hôtes et d’y ajouter la ou les machine(s) hôte(s) qui sera(ont) mises en délégation au sein de l’environnement de portail libreservice.

●

Créer des modèles de machines virtuelles adaptées aux utilisateurs du portail libreservice VMM. Les utilisateurs du portail utiliseront ces modèles pour créer leurs propres machines virtuelles.

●

Créer des rôles d’utilisateurs du portail adaptés aux différentes catégories d’utilisateurs.

Une fois ces étapes réalisées, les utilisateurs du portail pourront y accéder à l’aide de l’URL permettant d’accéder à la racine du site web et créer leurs propres machines virtuelles. La figure cidessous illustre la page de création d’une machine virtuelle basée sur le modèle R2EESP2FRPROD1 supportant Windows Server 2008 R2 EE, avec une interface © ENI Editions - All rigths reserved

- 71 -

réseau, 1 Go de mémoire RAM et 127 Go d’espace disque.

Création d’une machine virtuelle à l’aide d’un modèle via le portail libreservice

- 72 -

Migration des machines virtuelles et migration P2V VMM 2008 R2 permet aux administrateurs de convertir des serveurs physiques existants en machines virtuelles. Cette fonctionnalité, appelée P2V pour Physical to Virtual, est intégrée au sein de la plateforme SCVMM 2008 R2 sous la forme d’assistants qui simplifient l’ensemble des opérations à réaliser. Les outils intégrés à VMM permettent aussi de réaliser la conversion de machines virtuelles en provenance d’autres platesformes de virtualisation. Grâce à cette fonctionnalité, appelée cette foisci V2V pour Virtual to Virtual, il sera possible de convertir des machines virtuelles provenant de platesformes de virtualisation VMware ESX et Microsoft Virtual Server 2005 R2.

1. Identification des candidats Le processus de conversion des machines physiques en machines virtuelles peut être en relation directe avec un projet de consolidation des serveurs où les machines physiques les moins utilisées et consommatrices de ressources seraient converties en machines virtuelles. La sélection des meilleurs candidats à la virtualisation, et donc à un processus de P2V, doit respecter les recommandations suivantes : ●

Commencer par les serveurs peu utilisés et n’ayant aucune fonction critique au sein de l’entreprise. Une approche « douce » permettra aux personnels ayant en charge le processus de P2V, de prendre en main la technologie et d’acquérir un premier niveau d’expérience sans prendre de risque. Les machines de type serveurs Web, serveurs d’administration, SCOM, SCCM, SCVMM, IAS… sont de bons candidats.

●

Intégrer les serveurs moyennement utilisés et hébergeant les applications les moins critiques.

●

Intégrer les serveurs utilisés ou fortement utilisés hébergeant les applications les moins critiques.

●

Intégrer des serveurs critiques et profiter des fonctionnalités avancées de la plateforme de virtualisation, haute disponibilité, captures instantanées, indépendance par rapport aux matériels, gestion des ressources virtuelles, etc.

a. Microsoft Assessment and Planning (MAP) Toolkit Pour aider à identifier les meilleurs candidats, Microsoft met en téléchargement gratuit sur son site un outil d’inventaire et de génération de rapports très puissant. Cet outil, appelé Microsoft Assessment and Planning Toolkit (MAP), est capable, sans installer aucun agent, d’inventorier les machines clientes et serveurs du réseau et de fournir des rapports d’analyse concernant les éventuelles opérations de migration vers Windows Vista, Office 2007, Windows Server 2008 R2, Windows Server 2008 R2 HyperV, SQL Server 2008 et aussi APPV anciennement SoftGrid et aussi les produits de sécurité Forefront / NAP. Les rapports livrés avec MAP sont dans les langages suivants : français, anglais, allemand, japonais, coréen, brésilien, portugais et espagnol. ●

L’installation de MAP nécessite les prérequis suivants : ●

Microsoft MAP peut être installé, physiquement ou en tant que machine virtuelle, sous Windows Server 2003, Windows Server 2008 R2, Windows Vista SP1 ou Windows XP Professionnel SP2.

●

Un processeur Intel ou AMD à 1,6GHz ou supérieure, DualCore pour Windows Vista ou Windows Server 2008 R2.

●

2 Go de mémoire RAM et 1 Go d’espace disque.

●

Microsoft SQL Server 2005 ou Microsoft SQL Server 2008 Express Edition pour stocker les données d’inventaire et données de recommandations.

●

Microsoft Word 2003 SP2 ou Microsoft Word 2007 avec Microsoft Excel 2003 SP2 ou Microsoft Excel 2007 pour la génération des rapports,

- 1-

●

Framework .NET v3.5 SP1 et Windows Installer v4.5.

L’assistant d’inventaire intégré à MAP utilise les interfaces WMI, le service Registre à distance, les compteurs de performance, les services Active Directory et SNMP. Pour que l’agent d’inventaire puisse être pleinement opérationnel, les points suivants doivent être vérifiés : ●

Mots de passe des comptes locaux : lorsque l’ordinateur distant est une machine membre d’un groupe de travail et que le mot de passe n’est pas configuré, alors, par défaut, l’ouverture de session est autorisée uniquement localement et interdite au travers du réseau. Par voie de conséquence, un inventaire WMI nécessite que le compte local soit membre du groupe local Administrateurs et dispose d’un mot de passe correctement défini.

●

Activation de l’administration à distance : si le Parefeu Windows est activé, il faut s’assurer que le port RPC port TCP 135 n’est pas bloqué.

●

Activation du partage de fichiers et d’impressions : si le Parefeu Windows est activé, il faut s’assurer que les ports TCP 139 et 445 ainsi que les ports 137 et 138 ne sont pas bloqués.

Pour plus d’informations concernant Microsoft Assessment and Planning (MAP) Toolkit, consultez les liens suivants : http://go.microsoft.com/fwlink/?LinkId=106437 et http://www.microsoft.com/map.

b. System Center Operations Manager 2007 SP1 Toujours pour aider les équipes informatiques à identifier les meilleures machines candidates à la virtualisation, System Center Operations Manager peut être utilisé pour afficher le rapport Candidats de virtualisation. Ce rapport SCOM aide à identifier les machines physiques sousutilisées en affichant les statistiques d’un ensemble de compteurs de performance tels que le processeur, la mémoire et l’utilisation des disques. Les configurations inventoriées sont aussi représentées avec leurs caractéristiques matérielles telles que le modèle et nombre de processeurs, la mémoire RAM, etc. Les rapports sont finement configurables et peuvent, par exemple, être limités aux seuls ordinateurs répondant aux critères choisis par l’administrateur. Pour plus d’informations et une description détaillée des rapports VMM offerts par System Center Operations Manager 2007, reportezvous au guide du pack d’administration de System Center Virtual Machine Manager 2008 à l’aide du lien cidessous : http://go.microsoft.com/fwlink/?LinkId=85858

2. Migration P2V a. Introduction La conversion des ordinateurs physiques en machines virtuelles peut faire appel à deux méthodes. ●

La première méthode, réalisée lorsque la machine source est en fonctionnement, Online P2V, est basée sur l’utilisation des services VSS (Volume Shadow Service). Les services VSS prennent en charge la copie alors que le système est en pleine activité sans aucune perturbation du fonctionnement opérationnel de la machine. La machine source n’est donc aucunement interrompue pendant la phase de P2V.

●

La deuxième méthode, réalisée lorsque la machine source n’est pas en cours de fonctionnement est réalisée en procédant au redémarrage sous Windows PE (Windows Preinstallation Environment). Dans ce cas, l’environnement Windows PE est utilisé pour réaliser le processus de capture du disque, ce qui nécessite que les pilotes de périphériques de cartes réseau et contrôleurs de disques soient installés. Cette phase d’injection des drivers nécessaires à l’environnement Windows PE est automatiquement réalisée par le serveur VMM.

Dans le cas où des pilotes de périphériques ne seraient pas connus, l’administrateur aura la possibilité de les ajouter à la dernière minute.

- 2-

Le tableau cidessous liste les différents systèmes d’exploitation et les possibilités de conversion supportées par VMM 2008. Système d’exploitation

P2V à chaud

P2V à froid

Windows Server 2008 R2

Supporté

Windows Server 2008 x86

Supporté

Windows Server 2008 x64

Supporté

Windows Server 2003 x86 SP1 ou supérieure

Supporté

Windows Server 2003 x64 SP1 ou supérieure

Supporté

Windows 2000 Server SP4 ou supérieure

non

oui

Windows XP Professional x86 SP2 ou supérieure

Supporté

Windows XP Professional x64 SP2 ou supérieure

Supporté

Windows Vista x86 SP1 ou supérieure

Supporté

Windows Vista x64 SP1 ou supérieure

Supporté

VMM ne supporte pas les opérations de P2V avec les systèmes fonctionnant sous Windows NT Server 4.0. Pour supporter les fonctions de P2V, les systèmes fonctionnant sous Windows 2000 Server SP4 doivent disposer des éléments suivants : Windows Installer 3.1 (v2), Microsoft Visual C++ 2005 Redistribuable Package, le Framework .Net 2.0, la mise à jour BITS disponible via le KB 842773. Pour réaliser une conversion P2V en mode hors connexion, la machine physique source doit disposer d’au minimum 512 Mo de mémoire RAM, être dans un environnement de type groupe de travail, être membre du même domaine que le serveur VMM ou membre d’un domaine disposant d’une approbation bidirectionnelle avec le domaine du serveur VMM.

b. Migration P2V étape par étape L’Assistant Conversion de serveur physique est disponible au sein de la console Administrateur SCVMM via le volet Actions Convertir le serveur physique. Les figures qui suivent illustrent les grandes étapes d’une migration P2V SCVMM. Étape de sélection de la machine physique source

- 3-

Déclaration du nom de l’ordinateur ou de son adresse IP, et authentification

Étape de déclaration de l’identité de l’ordinateur virtuel

- 4-

Déclaration du nom de la machine virtuelle et propriétaire

Même si le nom déclaré dans l’assistant ne doit pas obligatoirement respecter le nom réel de la machine, l’utilisation du même nom garantit des affichages cohérents dans System Center Operations Manager 2007.

Étape de collecte des informations système de la machine source

- 5-

Étape de collecte via l’installation de l’agent temporaire VMM

Étape de sélection des volumes à dupliquer

- 6-

Étape de sélection des volumes, de la taille, du type de disque virtuel et du mode de conversion

Spécification des processeurs et de la mémoire allouée

- 7-

Déclaration du nombre de processeurs et de la mémoire

Sélection de la machine hôte via la sélection élective

- 8-

Proposition des meilleures machines via la sélection élective

Sélection de l’emplacement de stockage sur la machine hôte choisie

- 9-

Étape Sélectionner une source

Sélection du réseau virtuel HyperV à utiliser

- 10 -

Choix du réseau virtuel qui accueillera la machine virtuelle

Réglages des actions lors du démarrage et de l’arrêt

- 11 -

Définition des actions à entreprendre au démarrage et à l’arrêt du serveur hôte

Informations de conversion et détection des problèmes

Affichage des problèmes éventuels empêchant la conversion P2V

- 12 -

Accès au script PowerShell et démarrage de la conversion P2V

Écran de synthèse des sélections et création de la machine virtuelle

Affichage des travaux et vue du travail Conversion physiqueàvirtuel

Suivi de l’exécution des étapes de migration P2V

- 13 -

Suivi de l’exécution des étapes de migration P2V

Attention ! Pour les migrations P2V online, assurezvous que les applications critiques sont stoppées ou bien qu’elles disposent d’un Writer VSS.

Attention ! Pour les migrations P2V offline, assurezvous que vous disposez de pilotes de périphériques de cartes réseaux et de contrôleurs de disques durs compatibles Windows Vista, c’estàdire PE 2.0. Lors de l’évaluation de la machine physique, VMM fournira les informations nécessaires à l’administrateur pour ajouter des pilotes de périphériques.

3. Migration V2V Dans Virtual Machine Manager, une conversion de machine virtuelle en machine virtuelle, ou conversion V2V, est le processus par lequel une machine virtuelle est convertie en ordinateur virtuel HyperV ou Virtual Server dans un environnement VMM. La machine virtuelle source peut se trouver dans la bibliothèque ou être gérée par un serveur VMware ESX. Actuellement, Virtual Machine Manager prend en charge la conversion d’une machine virtuelle VMware en une machine virtuelle HyperV ou Virtual Server analogue déployée sur une machine hôte géré par VMM. La conversion V2V réalisée via l’assistant Conversion de l’ordinateur virtuel est directement accessible via la console Administrateur SCVMM volet Actions Convertir l’ordinateur virtuel. Méthodes supportées entre les platesformes de virtualisation Plateforme source

- 14 -

Plateforme cible

Méthode SCVMM

HyperV

Option Migration

Virtual Server

Option Migration

Virtual Server

HyperV

Option Migration

VMware ESX

Option Migration

VMware ESX

HyperV

Option V2V

VMware ESX

Virtual Server

Option V2V

Attention ! Il n’est pas possible de réaliser une conversion V2V d’une machine virtuelle HyperV vers Virtual Server 2005 R2 ou VMware ESX.

Sélection de la machine source à migrer vers HyperV

4. P2V V2V : remarques Une conversion P2V On Line assure la création d’une copie à un instant t à l’aide de VSS. En fait, les composants P2V jouent le rôle d’un VSS Backup Requestor au sein de l’interface VSS. Une conversion V2V en mode Off Line est le mode par défaut des machines virtuelles sources fonctionnant sous Windows 2000 Server. Il s’agit de la seule méthode supportée par Microsoft pour convertir un contrôleur de domaine ou une machine source contenant des disques formatés avec le système de fichiers FAT. Les opérations de conversions sont pleinement supportées. Il est nécessaire de spécifier les informations d’identification disposant des privilèges d’administration sur la machine locale. Attention à la présence du Parefeu Windows ou de tout autre logiciel capable de bloquer les ports. Il est recommandé de réaliser une conversion P2V en mode Off Line afin de ne pas être confronté à un éventuel problème de type « USN Rollback ». Il est possible de lancer plusieurs processus P2V simultanément. À propos des protocoles utilisés lors des migrations P2V ou V2V : les communications entre les machines impliquées pendant le processus de conversion utilisent les protocoles suivants : © ENI Editions - All rigths reserved

- 15 -

●

Entre la machine de destination et la machine source : HTTPS

●

Entre le serveur VMM et l’agent P2V sur la machine source : WMI

●

Entre le serveur VMM et la machine de destination : WSManagement WinRM.

À propos de la conversion des machines cluster : VMM ne reconnaît pas une machine en cluster comme une ressource prise en charge par les fonctionnalités de P2V. Les composants d’intégration HyperV sont automatiquement installés pendant le processus P2V.

- 16 -

Bonnes pratiques L’utilisation de System Center VMM 2008 pour gérer efficacement une plateforme ou une infrastructure de virtualisation nécessite de respecter un certain nombre de bonnes pratiques. Vous trouverez cidessous celles qui vous permettront de tirer le maximum de SCVMM : ●

N’hésitez pas à déléguer, lorsque cela est nécessaire, la création et la gestion des machines virtuelles aux personnes devant en disposer via le nouveau portail Web libreservice VMM.

●

Pour mieux découvrir toutes les possibilités et toutes les fonctionnalités de SCVMM 2008, parcourez « dans tous les sens » la nouvelle console Administrateur SCVMM.

●

À l’aide de la console Administrateur SCVMM, contrôlez les détails de chacune des machines virtuelles afin de vous assurer que tous les paramètres sont corrects.

●

Utilisez les profils matériels pour définir les ressources virtuelles nécessaires aux différentes familles de machines virtuelles que vous devez prendre en charge.

●

Utilisez les profils de machines invités pour définir les environnements système nécessaires aux différentes familles de machines virtuelles que vous devez prendre en charge.

●

Assurez un suivi des travaux en examinant les travaux en cours d’exécution, les travaux terminés avec succès et les travaux en erreur.

●

Profitez de la console VMM et copiez les commandes qui sont utilisées par VMM lorsque vous réalisez une tâche. Cela pourra vous être utile par la suite pour réaliser des scripts PowerShell et automatiser certaines opérations d’administration.

●

Assurezvous que les partages des serveurs de bibliothèques sont pris en charge par des serveurs hautement disponibles.

●

Lorsque VMM prend en charge des machines hôtes situées sur des sites différents, déclarez une ou plusieurs bibliothèques sur chaque site.

●

Configurez les rôles des administrateurs VMM, des administrateurs délégués et des utilisateurs du portail libre service VMM pour disposer d’un niveau d’administration plus granulaire, sachant que le rôle d’administrateur VMM ne peut pas être limité à certaines machines hôtes ou réduit en fonctionnalités.

●

Utilisez les filtres de la barre de navigation pour réduire le nombre des items affichés dans la zone de détails.

●

Importez toutes les machines hôtes HyperV et VMware pour tirer tous les bénéfices d’une administration unifiée et centralisée.

●

"Scriptez" les opérations complexes répétitives en utilisant les nouvelles commandes cmdlets de VMM au sein de l’environnement Windows PowerShell.

●

Utilisez des machines hôtes en cluster intégrées dans VMM 2008 R2 pour héberger les machines virtuelles les plus critiques.

●

Si vous déployez une machine hôte HyperV ou un cluster de machines hôtes HyperV utilisez SCVMM 2008. De même, si vous disposez de platesformes VMware ESX intégrées avec Virtual Center, intégrez ces plates formes dans SCVMM pour profiter d’une gestion unifiée de vos platesformes.

●

En général, pour les configurations simples, VMM 2008 R2 et SQL Server peuvent être installés sur la même machine. Dans les cas où le nombre de machines hôtes et de machine virtuelles gérées est très important, répartissez les rôles sur plusieurs machines.

●

Si les composants VMM sont répartis sur plusieurs machines, assurezvous qu’il en est de même pour les serveurs de bibliothèques.

- 1-

- 2-

●

Pour faciliter toutes les opérations au sein de la console VMM, stockez tous les fichiers de données nécessaires aux déploiements des machines virtuelles dans les bibliothèques VMM.

●

Assurezvous que seules les machines virtuelles devant être « Hautement disponible » sont configurées avec l’option Hautement disponible. De cette manière, seules ces machines virtuelles pourront être placées sur des machines hôtes en cluster.

●

Sauf si dans le cas de la configuration de votre serveur des spécificités l’exigent, laissez l’assistant d’installation de VMM 2008 R2 installer les composants nécessaires au bon fonctionnement de la plateforme, Windows PowerShell 1.0, Framework .NET 3.0, WAIK (1.1).

●

Pour des raisons de sécurité, assurezvous que le serveur VMM 2008 R2 est membre d’un domaine Active Directory.

Sauvegarde et récupération d’urgence 1. Stratégies de sauvegardes des machines virtuelles L’évolution des technologies de virtualisation des serveurs confortent les entreprises dans leur choix de mise en œ uvre de ces solutions, notamment concernant la réduction des coûts d’infrastructure et l’augmentation du niveau de qualité de services offerts grâce à une bien plus grande agilité. Pour aller au bout de cette stratégie, et pour encore développer les avantages apportés par les platesformes de virtualisation, une étape importante, et indispensable, consiste à profiter de ces nouvelles possibilités comme un nouveau moyen de permettre ou d’améliorer les stratégies de récupération d’urgence Disaster Recovery strategies, dans les entreprises. Les études montrent que la préparation des plans de reprise, ou de récupération d’urgence, sont toujours parmi les sujets les plus « chauds » de l’industrie informatique, en mettant en avant les pertes auxquelles sont soumises les entreprises. Les plus grandes d’entre elles perdent en moyenne quelque 100.000 €, ou $, par heure ou par jour d’arrêt en fonction de leur importance. Toutefois, même si ces pertes financières sont considérables, en général, aucune de ces entreprises ne souffrira d’une perte de données catastrophique qui mettrait en danger sa survie à court ou moyen terme. Ce chapitre introduit les possibilités, limites et recommandations en rapport avec les grands principes de récupération d’urgence dans le cadre de la plateforme de virtualisation Microsoft HyperV. Nous nous attarderons à analyser les différentes options de sauvegarde et de restauration des machines virtuelles avec les outils intégrés à Windows Server 2008 R2 ainsi qu’avec les grandes possibilités offertes par Windows PowerShell. La sauvegarde industrielle des machines virtuelles devrait être implémentée avec une solution professionnelle telle que celle offerte par Microsoft via System Center Data Protection Manager 2007, la version SP1 permettant la prise en charge native des platesformes Virtual Server 2005 R2 EE et surtout Microsoft Windows Server 2008 R2 HyperV et Microsoft HyperV Server 2008 R2. Les partenaires Microsoft, par exemple Symantec, offrent aussi de très bonnes solutions de sauvegarde et de restauration des environnements de virtualisation.

2. Définir un plan de reprise de l’activité Le processus de récupération d’urgence est la formalisation des opérations qui permettent à l’entreprise le rétablissement des services essentiels dans le cas d’une panne majeure. Bien sûr, un tel plan doit faire partie intégrante du « Plan de Reprise d’Activités » de toute entreprise. Celuici garantit la poursuite des activités pendant ou après un événement catastrophique. L’ensemble de ces processus, tous liés entre eux, forment la stratégie de récupération dans son ensemble. De nombreuses solutions sont aujourd’hui à la disposition des architectes de systèmes d’information pour prendre en charge cette problématique. Cependant, certaines mises en garde s’imposent. En effet, certains fournisseurs affirment que leur technologie d’automatisation de plan de récupération d’urgence minimise voire élimine totalement la nécessité de réaliser des « répétitions » pour s’assurer de l’efficacité constante et réelle de la solution mise en place. Il faut rester prudent, car s’il est vrai que l’automatisation des tâches complexes améliore les temps de reprise et réduit la dépendance vis à vis des interventions humaines, il n’est pas raisonnable de penser que la seule technologie de reprise soit capable d’atténuer la catastrophe. En résumé, la technologie est nécessaire voire indispensable, les hommes et les processus sont au moins aussi importants et indispensables pour « maîtriser » les technologies utilisées et en faire le bon usage, tant attendu. En général, il n’est pas raisonnable de sélectionner les technologies sans au préalable connaître toutes les contraintes et les objectifs en relation avec le plan de récupération d’urgence luimême. Les éléments nécessaires à prendre en compte pour sélectionner les technologies sont présentés plus loin.

3. Définition des services et catégorisation La définition et la catégorisation des services utiles à la bonne continuité des services de l’entreprise permettent de clarifier ce qui définit l’ensemble du service à protéger et en quoi il est essentiel. Le tableau cidessous illustre ce grand principe. Services

Composants

Dépendances

Usage

Niveau de service SLA

- 1-

Système de messagerie

Serveurs en cluster

DNS, Parefeu, Réseau, Service d’annuaire

Communication interne et externe, support client international

99,99 %

Gestion financière

Bases de données en cluster, serveur d’application, serveur Web

DNS, réseau, PKI, cartes à puces

Conformité aux réglementations en vigueur

99,5%

Présence Internet via serveur Web

Bases de données en cluster, Serveur Web.

Parefeu, DNS, Load Informations sur 99,99 % Balancers. l’entreprise, support technique international

Le SLA (Service Level Agreement) ou Niveau de service offert, formalise un accord négocié entre deux parties. Cet accord peut exister entre clients et fournisseurs, entre fournisseurs et aussi au sein même des différents services d’une entreprise. Il permet de manière contractuelle de formaliser l’attente des parties en termes de services offerts, priorités, responsabilités et garanties. Sur la base des différents SLA, tout peut être défini quant aux niveaux de disponibilité, de performance, et d’opération ou de tout autre attribut lié à un service particulier. Le SLA peut aussi contenir les éventuelles pénalités lorsque le SLA n’est pas respecté. La première étape consiste donc à identifier et à définir chaque service. Une fois cette étape réalisée, il suffira d’identifier les différents systèmes, leurs interdépendances et aussi les éventuelles dépendances avec des composants externes. Les SLA présentés cidessous peuvent être classés en différentes catégories de telle sorte qu’il sera possible de les assigner à tel ou tel service. À propos des SLA :

Un SLA, est un accord ou un contrat, entre un prestataire de services, par exemple le service informatique, et un client, par exemple l’entreprise ou un service de l’entreprise, définissant les objectifs de disponibilité pour un service donné. Le plus souvent, les SLA sont classés en différents niveaux de services. À propos des OLA :

Un OLA (Operating Level Agreement), décrit les accords entre les différentes équipes informatiques sur la base d’un SLA particulier contenant un certain nombre de paramètres, par exemple, des contraintes de performances ou des temps de réponse. Ces OLA permettent d’aligner les équipes vers le même objectif de qualité. À propos des RPO / RTO :

Les RPO/RTO (Recovery Point/Recovery Time Objectives), définissent combien de temps un service peut ne pas être disponible avant qu’il y ait une rupture dans la continuité de ce service. Cette valeur est donc considérée comme acceptable. Sur la base de ce principe, lorsqu’un service dispose d’un SLA de 99% par mois, cela signifie qu’il a un RTO associé d’environ 7 heures et 18 minutes. La valeur du RPO correspondant au temps de remise en conformité peut, par exemple, être fixée à 4 ou 8 heures en fonction de la criticité. À propos des DRP :

Les DRP (Data Retention Policies), définissent des politiques de conservation des données en précisant combien de temps il est nécessaire de conserver les sauvegardes ainsi que l’endroit où les stocker. Ces stratégies sont presque toujours motivées par des exigences légales et réglementaires. À propos de la catégorisation des données :

La catégorisation des données a pour objet de prendre en charge la nature même des données. Lorsque les données sont catégorisées, il devient plus facile d’envisager la création de politiques particulières en fonction des contraintes relatives a ces catégories de données. À propos des scénarios catastrophiques :

Les différents types de scénarios catastrophes doivent être définis de telle sorte qu’il soit plus facile de planifier pour chacun d’entre eux les procédures de restauration, les impacts sur l’entreprise et les coûts à y associer. Une fois ces scénarios définis, il faudra sélectionner ceux qui seront effectivement pris en compte dans la planification du plan de récupération d’urgence. Les impacts provoqués par ces scénarios sont listés cidessous : ●

- 2-

Perte de la totalité d’un site,

●

Perte d’un centre de données complet,

●

Perte d’un système complet, lié à une panne matérielle ou une défaillance du système d’exploitation,

●

Perte de données, liée à une suppression accidentelle ou bien à une corruption,

●

Perte d’une dépendance, vitale au fonctionnement d’un service ou d’une application.

Comme vous pouvez le constater, il n’est pas possible de comparer la perte d’un Datacenter tout entier à la perte d’un seul serveur. Quoi qu’il en soit, les responsables informatiques devront définir les seuils de récupération souhaités en fonction du niveau de service appliqué. Là ou les choses se compliquent, c’est justement lorsqu’un SLA impose, par exemple, une reprise du service en au plus 4 heures alors que le temps de remise en place des matériels est de 8 heures et que le temps de restauration peut nécessiter plusieurs jours ! Dans de pareilles situations, il peut être envisagé d’effectuer un basculement de l’activité du service en question vers le site de secours sans passer par un processus de récupération des données long et fastidieux. L’idée consiste donc à anticiper au maximum un basculement vers un site de reprise, le plus rapidement possible, bien entendu.

4. Récupération d’urgence et technologies de virtualisation Cette introduction nous permet de mieux percevoir les challenges auxquels sont confrontées les équipes informatiques d’aujourd’hui. La bonne nouvelle est que les platesformes de virtualisation permettent de contourner la problématique de restauration complexe des systèmes d’exploitation, ceuxci étant réduits à de simples fichiers, véritablement indépendants des matériels. Les services fonctionnels peuvent donc, grâce à la virtualisation des serveurs, être facilement intégrés au sein d’un DRP (Disaster Recovery Plan). Ce succès réel fait finalement penser qu’il est facile d’atteindre les objectifs d’un plan de récupération d’urgence en utilisant au mieux les technologies de haute disponibilité, HA solutions, Hight Availability solutions, offertes par les platesformes de virtualisation. La figure cidessous illustre un tel principe.

Cluster Multisites HyperV → Plan DRP, virtualisation, haute disponibilité et réplication du stockage Cette figure illustre une solution fonctionnant sous Windows Server 2008 R2 Edition Entreprise utilisant les services de basculement WFCS. Différents nœ uds du cluster sont positionnés sur des sites géographiques distincts et les données sont synchronisées entre les sites. Dans le cas d’un incident grave, il est alors décidé de basculer l’activité sur le nœ ud du site de secours et de reprendre ainsi des activités normales dans un temps minimal. Sans chercher à affronter de multiples solutions les unes contre les autres, il faut, pour pouvoir répondre à de multiples scénarios de catastrophes, une combinaison de technologies. Il faudra alors intégrer des solutions de sauvegardes performantes, les mécanismes de haute disponibilité ne permettant pas de garantir une protection dans tous les cas de sinistres. Il faut aussi faire remarquer que ces solutions, complexes, nécessiteront de soigneusement planifier la mise en œ uvre de la couche de stockage, notamment lorsqu’il s’agira de réaliser la réplication des volumes partagés au sein d’un réseau. Attention ! La figure cidessus met en œ uvre un cluster géographique à deux nœ uds avec HyperV et un stockage partagé de type SAN ou iSCSI. Dans cet exemple, le soussystème de stockage des données est un

- 3-

point de défaillance, et ce, même si les différents nœ uds de cluster sont localisés sur des sites différents.

Windows Server 2008 R2 Edition Entreprise supporte sans problème la perte de l’accès au stockage partagé. Toutefois, pour que le nœ ud survivant puisse être fonctionnel suite à la perte des données ou du stockage sur l’autre nœ ud, il sera nécessaire de déployer une solution additionnelle prenant en charge la réplication des données entre le site de production et le site de repli.

5. Les Clusters géographiques Windows et la réplication du stockage a. Critères à respecter La réplication des données entre différents sites est un sujet important s’agissant des configurations en clusters géographiquement dispersés, concept du géocluster. Les fournisseurs de solutions tierces implémentent des solutions parfois très différentes qui nécessitent donc que nous y portions une attention toute particulière. Les critères ou considérations suivantes doivent impérativement être respectés : ●

Choix du niveau de réplication : la solution peut supporter la réplication au niveau bloc via une prise en charge spécifique du matériel, au niveau du système de fichiers ou via une prise en charge spécifique au niveau du système d’exploitation, ou encore au niveau d’une application, comme cela est le cas avec des applications telles que Microsoft SQL Server ou Microsoft Exchange Server. En fonction du besoin, ce premier choix devra être fait.

●

Configuration de la réplication pour éviter la corruption des données : la solution de réplication doit être configurée de telle sorte que toute interruption impromptue de la réplication n’introduise pas de corruption des données. Le moteur de réplication doit toujours considérer que les données réelles sont issues du site principal et que l’ordre des opérations d’entréessorties doit être préservé. Ce point est important car il existe peu d’applications capables de réparer les données corrompues.

●

Il est interdit d’utiliser la réplication DFSR : les systèmes en cluster géographiques Windows Server 2008 R2 Edition Entreprise ne peuvent pas utiliser la fonctionnalité DFSR (Distributed File System Replication), intégrée à Windows Server 2008 R2. En effet, DFSR réplique les données uniquement lorsque les fichiers sont fermés. Cela peut donc fonctionner pour des fichiers de type bureautique, par exemple, mais ne fonctionnera pas pour des fichiers tenus constamment ouverts comme cela est le cas concernant les machines virtuelles HyperV ou les bases de données.

●

Choix d’une réplication en mode synchrone ou en mode asynchrone : les opérations de réplications peuvent avoir lieu de manière synchrone. Dans ce cas, aucune opération d’écriture ne peut avoir lieu tant que les données en réplication ne sont pas encore « arrivées » sur le site cible de la réplication. À l’inverse, lorsque les réplications utilisent un modèle asynchrone, alors des opérations d’écritures peuvent avoir lieu à tout moment sur le site d’origine et être répliquées vers le site cible en tâche de fond. Ce dernier modèle de réplication améliore la performance des applications mais peut introduire une incohérence sur le site cible puisque certaines opérations peuvent ne pas être enregistrées vers le site de destination. Pour cette dernière raison, la méthode de la réplication synchrone est généralement conseillée dans le cas des clusters multisites disposant des bonnes connexions intersites. Cette remarque signifie aussi que dans ce cas, il ne peut s’agir de connexions intersites de type longue distance. La réplication en mode asynchrone permet de son côté une bonne prise en charge des configurations en cluster dans des environnements moins performants.

Nous venons de voir que les technologies de virtualisation permettent de faciliter la mise en œ uvre d’une meilleure politique de reprise d’activité mais elles nécessitent d’être complémentées par des solutions tierces pour assurer la réplication des machines virtuelles et de leurs paramètres entre les sites géographiques. Pour y parvenir, vous aurez la possibilité d’utiliser des solutions tierces telles que celles qui sont proposées par les éditeurs cidessous : Editeur

Produits

SteelEye Technology

SteelEye DataKeeper Cluster Edition for HyperV

www.steeleye.com

- 4-

SteelEyeLogo.png

DoubleTake

DoubleTake for HyperV

www.doubletake.com DoubleTakelogo.png

b. Solution Tierce « SteelEye DataKeeper Cluster Edition for HyperV » SteelEye DataKeeper fournit une solution de prise en charge des sinistres via une solution de haute disponibilité pour les machines virtuelles fonctionnant sur les platesformes HyperV. L’un des principaux avantages de la virtualisation est la « portabilité » offerte par ces platesformes et ainsi, la facilité de récupération des serveurs virtualisés. Le produit DataKeeper permet la récupération complète en cas de catastrophe en préservant le fonctionnement des machines virtuelles HyperV via une synchronisation vers un autre emplacement géographique. Le produit est complètement intégré aux services WSFC (Windows Server Failover Clustering), de telle sorte qu’il permet aux administrateurs de construire un cluster HyperV géographiquement dispersé, en éliminant l’exigence d’un stockage partagé sur plusieurs sites. StellEye DataKeeper for HyperV supporte les fonctionnalités suivantes : ●

Réplication asynchrone des machines virtuelles HyperV.

●

Intégration au sein des services de basculement de Windows Server 2008 R2 Edition Entreprise.

●

Mode test pour la simulation du basculement vers un site de secours.

●

Réplication des machines virtuelles et des volumes via Volume Level Continuous Data Protection (CDP) pour les platesformes 32 bits et 64 bits Intel et AMD.

●

Support de plusieurs cibles de réplication pour prise en charge des DRP (Data Recovery Plan), multisites.

●

Support de 9 niveaux de compression.

●

Gestion des retours en arrière.

Pour plus d’informations sur les produits SteelEye pour HyperV, consultez le site de la société SteelEye à l’adresse cidessous : http://www.steeleye.com/hyperv/

c. Solution Tierce « DoubleTake for HyperV » DoubleTake for HyperV permet la réplication et le basculement des machines virtuelles HyperV en temps réel au travers de plusieurs sites géographiquement dispersés sans investir massivement dans une infrastructure de réplication complexe de type SAN. Le produit supporte les fonctionnalités suivantes : ●

Auto Discovery : utilisation des API HyperV pour localiser automatiquement les fichiers de configuration des machines virtuelles, les disques virtuels et les captures instantanées.

●

Auto Provisioning.

●

Virtual Switch Mapping : configuration des interfaces réseau virtuelles entre les machines du cluster pour connexion automatique vers les interfaces virtuelles de destination.

●

Réplication des machines virtuelles en temps réel de type « byte level ».

●

Aucun composant à installer au sein des machines virtuelles.

- 5-

●

Bandwidth Throttling : l’administrateur définit le taux de bande passante à allouer pour la réplication des machines virtuelles.

●

Mise en queue des réplications en cas de perte de connectivité.

●

Snapshot Awareness : DoubleTake réplique les captures instantanées vers le nœ ud de destination.

●

Gestion automatique des disques virtuels ajoutés ou bien supprimés des machines virtuelles.

●

Manual Failover : l’administrateur peut initier un basculement manuel à l’aide de l’interface graphique du produit.

●

Protection séparée de chaque machine virtuelle en fonction des besoins de protection.

●

Mode simulation pour tester les basculements avec un mode « undo ».

●

Indépendance par rapport aux systèmes d’exploitation : DoubleTake for HyperV peut protéger n’importe quelle machine virtuelle indépendamment du système d’exploitation.

Pour plus d’informations sur ce produit, consultez le site de la société DoubleTake, à l’adresse suivante : http://www.doubletake.com/english/products/doubletakevirtualization/Pages/DoubleTakeforHyper V.aspx

Pour plus d’informations sur les différents partenaires Microsoft développant des solutions pour la plate forme de virtualisation Microsoft, consultez ce lien : http://www.microsoft.com/virtualization/partners/default.mspx

6. Sauvegarde des Machines Virtuelles La sauvegarde des machines virtuelles est certainement le point le plus sensible d’une plateforme de virtualisation, le regroupement de n serveurs sur une seule machine hôte créant naturellement un SPOF, ou point de défaillance unique, qu’il faut impérativement prendre en charge.

a. Planification des sauvegardes : stockage et type de sauvegarde La planification d’une stratégie de sauvegarde et de récupération pour une plateforme de virtualisation nécessite la considération de multiples facteurs. Parmi ces facteurs, nous pouvons recenser les suivants : ●

Le type de sauvegarde qui sera réalisé,

●

Le type de stockage utilisé pour les machines virtuelles,

●

L’état des machines virtuelles.

Ces différents critères, tous à considérer, possèdent leurs propres avantages et leurs propres inconvénients présentés cidessous : Considérations et options de sauvegarde

Le nouveau service de sauvegardes de Windows Server 2008 R2 associé au Writer VSS d’HyperV permet de sauvegarder les machines virtuelles ainsi que les paramètres systèmes en rapport avec HyperV. Ce point précisé, l’administrateur peut utiliser les deux méthodes suivantes : ●

- 6-

Exécuter une sauvegarde à partir de la machine hôte HyperV : cette méthode est la plus judicieuse car elle sauvegarde le maximum de données. Comme la grande majorité des systèmes de stockage est compatible avec HyperV et le Writer VSS, il est donc possible de sauvegarder la totalité du serveur. L’administrateur peut alors réaliser une restauration complète en cas de sinistre majeur. Une sauvegarde complète de la

machine hôte HyperV inclut la configuration des machines virtuelles, les réseaux virtuels, les captures instantanées ainsi que les disques virtuels associés à chacune des machines virtuelles. Une sauvegarde complète offre l’avantage de permettre la restauration de tous les paramètres HyperV, facilitant ainsi la reprise du service. Il n’est pas nécessaire de reconfigurer les paramètres associés aux machines virtuelles tels que les réseaux virtuels et autres options déclarés au niveau des machines virtuelles. ●

Exécuter une sauvegarde à partir d’une machine virtuelle invitée. Cette méthode peut être utilisée, en solution de repli, lorsque le stockage utilisé n’est pas pris en charge par le Writer VSS d’HyperV.

À propos du stockage utilisé par les machines virtuelles

Il est très important de vérifier la compatibilité des outils et solutions de sauvegardes / restaurations avec le stockage pris en charge par la plateforme de virtualisation et, dans certains cas aussi, les machines virtuelles. Les points suivants doivent être considérés : ●

Cas des disques physiques HyperV : le support des accès directs aux disques physiques est une fonctionnalité recommandée par Microsoft lorsqu’il est nécessaire de garantir un très haut niveau de performances en entréessorties. Ce type d’accès, aussi appelé PassThrough Disks, permet à une machine virtuelle d’attaquer les disques en passant directement par la machine virtuelle principale, c’estàdire la machine hôte HyperV. La conséquence de cette implémentation, certes très performante, est que le Writer VSS HyperV est tout simplement courtcircuité. L’utilisation de ce type de stockage nécessite donc d’utiliser une autre solution comme, par exemple, l’installation d’un agent de sauvegarde tiers, au sein de la machine virtuelle.

●

Cas des disques virtuels VHD situés sur le réseau : l’utilisation de partages réseau comme emplacement de stockage des disques virtuels doit faire l’objet de toutes les attentions car en cas de problème de connectivité ou d’accès au réseau pendant l’exécution de la sauvegarde, l’opération ne pourra être réalisée avec succès.

●

Cas du stockage iSCSI directement utilisé au sein d’une machine virtuelle : lorsqu’une machine virtuelle utilise l’initiateur iSCSI depuis la machine virtuelle pour utiliser un stockage externe iSCSI, l’opération de sauvegarde n’inclura pas ce type de stockage. L’utilisation de ce type de stockage nécessite donc d’utiliser une solution du même type que dans le cas des PassThrough Disks, c’estàdire via l’installation d’un agent de sauvegarde tiers, au sein de la machine virtuelle.

Les systèmes de stockage iSCSI sont intégralement pris en charge par les outils de sauvegarde compatibles avec le Writer VSS HyperV lorsqu’ils sont connectés via la partition parente HyperV et qu’ils hébergent des disques virtuels VHD.

●

Finalement, les disques virtuels VHD sont les disques pris en charge par les machines virtuelles qui sont les plus compatibles en termes d’environnements virtuels et les plus souples en termes de stockage.

Sauvegardes En ligne et Hors ligne

Lorsqu’il est nécessaire de réaliser l’opération de sauvegarde alors que la machine virtuelle ne peut être interrompue, il est bien sûr intéressant de disposer de la possibilité de réaliser une sauvegarde En ligne. Cependant, les conditions suivantes devront être réunies : ●

Les services d’intégration HyperV sont installés dans la machine virtuelle et sont opérationnels. Ce dernier point signifie qu’il faut s’assurer que l’option Sauvegarde (capture instantanée de volume) n’a pas été désactivée.

●

Les disques utilisés au sein de la machine virtuelle doivent être de type de base Basic Disks, et formatés en NTFS.

Attention : si une machine virtuelle ne possède ne seraitce qu’un seul disque ne respectant pas ces consignes, par exemple un disque formaté en FAT ou un disque de type dynamique, une sauvegarde de type « En ligne » ne pourra pas être exécutée. Les services VSS doivent être opérationnels sur tous les volumes de la machine virtuelle concernée. Lorsqu’une sauvegarde de type En ligne ne peut pas être exécutée, alors une sauvegarde de type Hors ligne est

- 7-

automatiquement réalisée. À la différence d’une sauvegarde En ligne, une sauvegarde Hors ligne provoque le passage de la machine virtuelle dans l’état Enregistré lorsque cette dernière est dans l’état Exécution ou En pause. Une fois l’opération de sauvegarde Hors ligne terminée, la machine virtuelle est automatiquement repositionnée dans son état initial. La figure cidessous illustre les paramètres des services d’intégration d’une machine virtuelle configurables à l’aide de la console MMC Gestionnaire HyperV.

Activation des services de sauvegarde HyperV à offrir à la machine virtuelle

b. Activation du Writer VSS d’HyperV et principes de sauvegarde et de restauration Nous avons vu précédemment que Windows Server 2008 R2 et non R2 intégraient le Writer VSS d’HyperV. Notez cependant que concernant Windows Server 2008 l’application Sauvegarde de Windows Server ne fait pas référence à ce composant. De ce fait, il sera nécessaire de réaliser cette opération manuellement en enregistrant le Writer VSS. Windows Server 2008 R2 utilise directement le Writer VSS d’HyperV.

L’article de la base de connaissances intitulé « How to back up HyperV virtual machines from the parent partition on a Windows Server 2008 based computer by using Windows Server Backup », téléchargeable à l’aide du lien suivant, explique cette procédure. http://support.microsoft.com/kb/958662/enus Pour enregistrer le Writer VSS HyperV, exécutez les étapes cidessous à l’aide de l’éditeur de registre : ■

- 8-

Localisez la clé suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

■

Sur le dossier CurrentVersion, à l’aide du menu contextuel, faites Nouvelle Clé.

■

Saisissez WindowsServerbackup, et validez par [Entrée].

■

Sur le dossier WindowsServerBackup, à l’aide du menu contextuel, faites Nouvelle Clé.

■

Saisissez Application Support puis validez par [Entrée].

■

Sur le dossier Application Support, à l’aide du menu contextuel, faites Nouvelle Clé.

■

Saisissez {66841CD46DED4F4B8F17FD23F8DDC3DE} puis validez par [Entrée].

■

Sur le dossier {66841CD46DED4F4B8F17FD23F8DDC3DE}, à l’aide du menu contextuel, faites Nouvelle Valeur Chaine.

■

Saisissez Application Identifier puis validez par [Entrée].

■

Sur le dossier Application Identifier, à l’aide du menu contextuel, faites Modifier.

■

Dans la boîte de dialogue Données de la valeur, entrez HyperV.

■

Quittez Regedit.

Sauvegarde et restauration des machines virtuelles via l’outil Sauvegarde de Windows Server

Pour sauvegarder les machines virtuelles d’une machine hôte HyperV, vous devez réaliser la sauvegarde de tous les volumes qui accueillent des fichiers utiles aux machines virtuelles. Par exemple, si les fichiers de configuration des machines virtuelles sont stockés sur le disque D: et les fichiers des disques durs virtuels sur le disque E:, alors il faudra sauvegarder les volumes D: et E:. Les machines virtuelles qui ne disposent pas des Services d’intégration HyperV seront positionnées dans l’état Enregistré pendant le temps de la création de la sauvegarde lors de la création de la capture instantanée. Pour restaurer les machines virtuelles d’une machine hôte HyperV, procédez de la manière suivante : ■

Via le menu Démarrer Outils d’administration, démarrez Sauvegarde de Windows Server.

■

Via le menu Actions, sélectionnez l’option Récupérer.

■

Sélectionnez le serveur à partir duquel vous souhaitez récupérer des données.

■

Sélectionnez la date et l’heure à partir de laquelle vous souhaitez restaurer des données.

■

Sélectionnez le type d’application à récupérer en choisissant HyperV.

■

Sélectionnez l’emplacement de la restauration.

■

Cliquez sur le bouton Récupérer pour lancer le processus de récupération.

Attention ! La restauration individuelle d’une machine virtuelle n’est pas possible à l’aide de l’outil intégré à Windows Server 2008 R2 Sauvegarde de Windows Server. Pour sauvegarder de manière granulaire les machines virtuelles, utilisez Microsoft System Center Data Protection Manager 2007 SP1 ou un produit tiers tels que Symantec Backup Exec System Recovery BESR. Attention ! Les machines virtuelles qui contiennent deux ou plus de deux captures instantanées ne seront pas restaurées. Pour contourner cette limitation de l’outil Sauvegarde de Windows Server, utilisez la procédure décrite dans l’article 958662 disponible via le lien http://support.microsoft.com/kb/958662/enus.

- 9-

c. Exemple de planification des sauvegardes via le Planificateur de tâches de Windows Server 2008 R2 La procédure qui suit explique comment créer une tâche planifiée pour sauvegarder les machines virtuelles stockées sur un volume particulier. L’utilisation de l’interface du Planificateur de tâches planifiées est plus adaptée que l’assistant intégré à l’outil graphique Sauvegarde de Windows Server car ce dernier ne permet que de programmer des travaux de sauvegarde s’exécutant sur une période journalière. Ce point n’est pas bloquant et il est néanmoins possible d’utiliser l’assistant Sauvegarde de Windows Server, puis de modifier la tâche programmée dans un deuxième temps. ■

À l’aide du menu Outils d’administration, lancez le Planificateur de tâches.

■

Exécutez l’assistant Créer une tâche. Veillez à ne pas utiliser l’option Créer une tâche de base qui ne propose pas tous les paramètres.

Création d’une tâche à l’aide du Planificateur de tâches de Windows Server 2008 R2 L’interface du Planificateur de tâches de Windows Server 2008 R2 est très bien organisée. La figure cidessus montre la structure des dossiers Microsoft contenant toutes les tâches d’entretien des composants de Windows Server. Il est recommandé de faire de même pour les tâches propres à l’exploitation du serveur en les classant par familles ou types d’activités. La figure cidessous montre le Planificateur de tâches contenant la tâche créée à l’aide de l’assistant Créer une tâche.

- 10 -

Création d’une tâche à l’aide du Planificateur de tâches de Windows Server 2008 R2 La figure cidessous met en évidence le fait qu’une tâche peut être caractérisée par six onglets. Les paramètres les plus importants sont décrits cidessous. ■

Via l’onglet Général, choisissez si la tâche est autorisée à s’exécuter lorsque l’utilisateur déclaré n’est pas en session. Veillez à ne pas sélectionner la case à cocher Ne pas enregistrer le mot de passe.

Détail des paramètres affichés via l’onglet Général

■

L’onglet Déclencheurs spécifie les conditions d’exécution de la tâche. Dans notre cas, la tâche sera exécutée toutes les semaines.

- 11 -

Détail des paramètres affichés via l’onglet Déclencheurs

■

- 12 -

La modification du déclencheur peut être réalisée via un double clic ou à l’aide du bouton Modifier.

Modification des paramètres de déclenchement

■

L’onglet Actions, certainement le plus important, permet de renseigner la ligne de commande que le Planificateur de tâches devra exécuter.

- 13 -

Détail des paramètres affichés via l’onglet Actions La fenêtre cidessous permet à l’administrateur de modifier à tout moment la commande déclarée via l’assistant Créer une tâche.

- 14 -

Modification des paramètres de l’action à réaliser. Les paramètres passés derrière la commande Wbadmin.exe permettant la sauvegarde du volume sont spécifiés ci dessous : start backup -quiet -backuptarget:\\DATASTORE1\DATAVM\VMBackups -include:d: -allcritical -vssFull -user:MYCORP\EXECBACKUP Bien sûr, le mot de passe n’ayant pas été spécifié en clair, une fenêtre de confirmation du mot de passe sera proposée à l’administrateur. Recommandation : avant de configurer et d’activer la tâche au sein du Planificateur de tâches de Windows Server 2008 R2, assurezvous que les paramètres de la ligne de commande fonctionnent parfaitement.

d. Montage des disques virtuels VHD via PowerShell et VB Script Le montage des disques virtuels VHD peut s’avérer très utile pour la maintenance des images des machines virtuelles ou l’accès direct à des sauvegardes, qui rappelonsle utilisent le format VHD. Windows Server 2008 R2 et Windows 7 incorporent nativement le montage des fichiers VHD à l’aide de la nouvelle console de gestion des disques. Malheureusement, Windows Server 2008 n’implémente aucun outil permettant de directement accéder au contenu des fichiers de disques virtuels. Une solution, simple mais peu pratique, pourra consister à déclarer le disque au sein d’une machine virtuelle existante. Cependant, il est aussi possible d’utiliser d’autres méthodes pour y parvenir. Windows Server 2008 non R2, mais et aussi R2, permettent le montage des disques VHD à l’aide des méthodes présentées cidessous : Montage d’un disque virtuel en VBScript

Le code du script VBS cidessous invoque l’interface WMI pour accéder aux classes offertes par le service Windows Service de gestion des images HyperV via Msvm_ImageManagementService. ’Sample VB Script code to mount VHD file’ Option Explicit Dim WMIService Dim VHDService Dim VHD ’Set the VHD file to mount’ VHD = "X:\VM.Data\Disk0.vhd" ’Get instance of the virtualization WMI service on local machine Set WMIService = GetObject("winmgmts:\.\root\virtualization") ’Get the MSVM_ImageManagementService to operate Set VHDService = WMIService.ExecQuery("SELECT * FROM Msvm_ImageManagementService").ItemIndex(0) ’Operate the mount operation VHDService.Mount(VHD) Montage d’un disque virtuel en PowerShell

Le code du script PowerShell cidessous invoque l’interface WMI pour accéder aux classes offertes par le service Windows Service de gestion des images HyperV via Msvm_ImageManagementService. #Sample Windows PowerShell code to mount VHD file $VHDName = "X:\VM.Data\Disk0.vhd" #Get the MSVM_ImageManagementService from WMI $VHDService = get-wmiobject -class "Msvm_ImageManagementService" -namespace "root\virtualization" -computername "." #Operate the mount operation $Result = $VHDService.Mount($VHDName) Enregistrez ce code dans un fichier .PS1 et exécutezle dans l’invite de commande PowerShell. Utilisation de la commande Vhdmount.exe de Virtual Server 2005 R2 SP1

Microsoft Virtual Server 2005 R2 SP1 intègre de base un outil de la ligne de commande qui permet de monter et démonter les fichiers de disques virtuels VHD. Pour utiliser cette commande, procédez de la manière suivante : © ENI Editions - All rigths reserved

- 15 -

■

Téléchargez à partir du site de Microsoft la version 64 bits de Virtual Server 2005 R2 EE SP1.

■

Sur la machine Windows Server 2008, choisissez une installation personnalisée du produit en prenant soin de tout désélectionner, sauf la commande VHDMOUNT.

Windows Server 2008 R2 prenant en charge le montage des disques virtuels VHD de manière native, il n’est pas nécessaire d’utiliser cet outil (VHDMOUNTEXE).

Virtual Server 2005 R2 EE n’ayant pas été conçu pour fonctionner sous Windows Server 2008 R2, à l’issue de l’installation, la commande VHDMOUNT, ne fonctionnera pas. Ce problème est documenté par Microsoft dans l’article 943487 de la base de connaissances et le téléchargement du correctif qui lui est associé. De plus, il faudra utiliser la commande Vhdmount.exe avec le paramètre /p.

Pour plus d’informations sur les différents paramètres de la commande VHDMOUNT, consultez le site Microsoft Technet à l’adresse cidessous : http://technet2.microsoft.com/windowsserver/en/library/22c042cd9029407f98663288fe2ad2d61033.mspx

La librairie PowerShell pour HyperV, disponible sur le site de la communauté Open Source Microsoft CodePlex, prend aussi en charge le montage et le démontage des disques virtuels VHD. Cette librairie est présentée plus loin dans ce chapitre.

- 16 -

Automation des tâches liées à la virtualisation 1. Windows PowerShell et HyperV HyperV est totalement « scriptable » en permettant à l’administrateur d’accéder aux fonctions de virtualisation au sein de l’espace WMI. Ainsi, qu’il s’agisse d’HyperV ou de System Center Virtual Machine Manager 2008, il est remarquable de voir l’ensemble des possibilités issues du mariage WMI / PowerShell. Pour administrer le rôle HyperV à l’aide de PowerShell, vous pourrez utiliser un ensemble de CmdLets spécialisées HyperV en téléchargeant la librairie « Hyperv.ps1 » à partir du site CodePlex via le lien suivant : http://www.codeplex.com/pshyperv. Ces différentes commandes sont présentées plus loin. « The CodePlex Open Source Project Community » est un projet Open Source parrainé par Microsoft. Le site, mis à disposition par Microsoft, peut être utilisé pour créer vos propres projets, ou pour rejoindre les projets et travaux initialisés par d’autres membres. Au sein de la communauté CodePlex, vous pouvez accéder à plus de 9000 projets, dont le projet « PowerShell management Library for HyperV » conduit par James O’Neill http://www.blogs.technet.com/jamesone. Tous les projets sont distribués sous license « Microsoft Public license MSPL ». La communauté relative à ce projet peut être directement accessible via le lien http://pshyperv.codeplex.com/

a. Installation de la librairie PowerShell pour HyperV Une fois téléchargé, il suffit de copier le script .ps1 dans un dossier, par exemple, C:\PowerShell, puis de procéder à son chargement en mémoire. Le script doit, pour être chargé, lancé à l’aide de la commande suivante : « . C:\PowerShell\hyperv.ps1 » Attention à ne pas omettre le (.). Dans le cas où le caractère (.) serait omis, ou si vous ne disposiez pas des privilèges suffisants vous recevriez un message d’avertissement au lancement du script. Cette librairie de commandes invoquant l’interface WMI et les fonctions de l’espace de virtualisation fonctionne parfaitement sous Windows Server 2008 R2 HyperV et a fait l’objet de tests concluants sous Windows Server 2008 R2 RC. Windows Server 2008 R2 étant équipé de la version 2.0 de PowerShell, une nouvelle version de la librairie de fonctions PowerShell pour HyperV devrait être à terme mise à disposition. Une fois installé, ce script n’étant pas signé, l’exécution en sera interdite. La solution consiste donc à modifier la stratégie d’exécution des scripts au sein de l’environnement PowerShell. La commande Get-executionpolicy permet d’afficher la valeur actuellement en production, dans notre exemple, Restricted. Pour modifier cette valeur, l’administrateur pourra entrer la commande Set-executionpolicy Unrestricted.

Désactivation de la signature des scripts PowerShell Une fois la stratégie d’exécution des scripts modifiée, le script hyperv.ps1 est capable de charger les fonctions PowerShell additionnelles de gestion de machines virtuelles.

- 1-

Chargement du script Hyperv.psi réalisé avec succès

b. Fonctions disponibles via la librairie HyperV CodePlex La version 1.00b, disponible depuis janvier 2009, contient environ 80 fonctions qui rendront bien des services aux administrateurs HyperV. L’exécution des fonctions intégrées dans la librairie nécessite que l’invite de commande soit exécutée avec un niveau élevé de privilèges. ●

Rechercher une machine virtuelle :

GetVM, ChooseVM, GetVMHost ●

Se connecter à une machine virtuelle :

NewVMConnectSession ●

Découvrir et manipuler l’état des machines virtuelles :

GetVMState, SetVMState, ConvertVmState, PingVM, ShutdownVM, StartVM, StopVM, SuspendVM GetVMKVP, GetVMJPEG ●

Sauvegarder, exporter et créer des captures instantanées des machines virtuelles :

ExportVM, GetVMSnapshot, ChooseVMSnapshot, ApplyVMSnapshot, NewVMSnapshot, RemoveVMSnapshot, GetVMSnapshotTree, GetVmBackupScript ●

Ajouter, supprimer des machines virtuelles et configurer les paramètres de carte mère :

NewVM, RemoveVM, SetVM, GetVMCPUCount, SetVMCPUCount, GetVMMemory, SetVMMemory ●

Manipuler les contrôleurs de disques, les disques et les images disques :

GetVMDiskController AddVMSCSIController, RemoveVMSCSIcontroller GetVMDriveByController, AddVMDRIVE, RemoveVMdrive GetVMDiskByDrive, AddVMDISK, SetVMDisk, GetVMDisk GetVMFloppyDisk, AddVMFloppyDisk AddVMNewHardDisk ●

- 2-

Manipuler les interfaces réseau :

GetVMNic, ListVMNic, ChooseVMNIC, AddVMNIC, RemoveVMNIC, SetVMNICAddress, SetVMNICConnection, Get VMNicport, GetVMnicSwitch, ChooseVMSwitch, NewVMSwitchPort, GetVMByMACaddress, ChooseVMExternalEthernet, NewVMExternalSwitch, NewVMInternalSwitch, NewVmPrivateSwitch ●

Manipuler les disques durs virtuels : Working with VHD files

GetVHDDefaultPath, GetVHDInfo, NewVHD, CompactVHD, TestVHD, ConvertVHD, MergeVHD, MountVHD, UnmountVHD Pour plus d’informations sur les paramètres de chaque commande de la librairie PowerShell pour HyperV, reportezvous au fichier Pshyperv.pdf disponible en téléchargement le site http://pshyperv.codeplex.com à la rubrique Downloads.

c. À propos de Windows Server 2008 R2, HyperV Server R2, PowerShell v2 Windows Server 2008 R2 et HyperV Server R2 intègrent la version 2.0 de Windows PowerShell. L’interface d’automation offerte par PowerShell étant fondamentale pour l’administration des systèmes et des applications Microsoft, il était normal que Microsoft continue d’en étendre les possibilités, si nécessaires aux administrateurs. PowerShell V2 est une évolution importante avec notamment la présence d’un tout nouvel éditeur graphique, des dizaines de nouvelles Cmdlets, ainsi que le support du Drag and drop pour insérer des fichiers au sein de l’invite de commande PowerShell. De plus, il est maintenant possible de personnaliser les onglets apparaissant sur un fichier PowerShell en décrivant les propriétés à l’intérieur de ce fichier. Ces options sont très pratiques pour y implémenter la documentation des paramètres ainsi que la gestion de la touche [Tab] pour le défilement des différentes options disponibles. Une autre nouveauté importante est la possibilité d’utiliser Windows PowerShell sur les installations minimales Server Core, de Windows Server 2008 R2 ainsi que sur HyperV Server 2008 R2. Si PowerShell est installé et l’administration à distance via WinRM activée, il est alors possible à l’administrateur d’exécuter n’importe quelle commande PowerShell à distance, à partir d’un poste de travail fonctionnant sous Windows XP Professionnel, Windows Vista ou Windows 7. Disponible avec Windows 7 et Windows Server 2008 R2, la version 2.0 de PowerShell peut être téléchargée à partir du site de téléchargement de Microsoft. À ce jour en CTP (Community Technology Preview), Windows PowerShell 2.0 fonctionne sur Windows Server 2003 SP2, Windows Vista, Windows XP Service Pack 2 et bien sûr Windows Server 2008 R2, en version x86 et aussi x64. L’installation de Windows PowerShell v2 nécessite les composants suivants : le Framework .Net 2.0, l’interface WSManagement 1.1 pour supporter les fonctionnalités à distance et optionnellement le Framework 3.0 pour utiliser la nouvelle interface graphique Windows PowerShell.

Pour plus d’informations sur Windows PowerShell v1 et v2 et accéder à de multiples exemples de scripts PowerShell, vous pouvez accéder aux liens cidessous : http://blogs.msdn.com/powershell, http://www.microsoft.com/powershell, http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

- 3-

Windows Server 2008 R2, HyperV v2 et SCVMM 2008 R2 1. Nouveautés de Windows Server 2008 R2 Ce chapitre présente l’ensemble des avancées technologiques et fonctionnelles apportées par Microsoft à la technologie de virtualisation HyperV incluse dans la version la plus aboutie de son système d’exploitation serveur, Windows Server 2008 R2. Avec cette nouvelle version, Microsoft dispose d’une version plus aboutie pour faire pénétrer la technologie de virtualisation au cœ ur de l’entreprise. Bien sûr, les objectifs de réduction des coûts de l’infrastructure physique et l’optimisation de l’utilisation des ressources matérielles permettent d’augmenter encore plus l’efficacité globale de la plateforme HyperV. Ainsi, nous allons découvrir que la version 2 d’HyperV est devenue encore plus puissante en gérant encore plus de cœ urs et en améliorant encore les performances en entréessorties via une optimisation des composants NTIO. Cependant, en plus de ces aspects, HyperV v2 améliore de manière notable la disponibilité des applications en permettant une continuité de l’activité des machines virtuelles dans la quasitotalité des situations de stress. Windows Server 2008 R2 permet aussi aux architectes du Système d’Information de proposer de nouveaux scénarios de virtualisation. En effet, en plus des scénarios traditionnels permettant l’utilisation de machines virtuelles pour les tests, le développement d’applications et pour la consolidation des serveurs, HyperV v2 offre désormais une prise en charge facilitée pour la continuité des activités. Comme cela a été le cas pour Windows Server 2008, les objectifs principaux de la plateforme de virtualisation Windows Server 2008 R2 et HyperV v2 sont de fournir une solution native à l’environnement Windows Server, capable de fournir les meilleurs niveaux de performances aux machines virtuelles, tout en assurant une meilleure disponibilité de cellesci. La nouvelle fonctionnalité de migration à chaud, Live Migration, la plus attendue, permet désormais à HyperV de supporter la comparaison avec son prestigieux concurrent VMware ESX, sachant qu’il ne s’agit pas de la seule nouveauté. Nous verrons plus loin que les possibilités d’administration ont encore été étendues, par exemple avec la fonctionnalité de migration du stockage, Storage Migration, sans oublier la politique tarifaire des solutions de virtualisation Microsoft qui permet de réduire encore plus les coûts associés aux platesformes de virtualisation. La section suivante présente les nouveautés d’HyperV v2. Avant de les découvrir, les points cidessous résument les nouveautés les plus notables apportées par la version R2 de Windows Server 2008 : En termes de fondation orientée performance et fiabilité : ●

●

Support de 256 cœ urs. ●

Organisation du système en mode composants OS Componentization.

●

Boot des machines physiques à partir du SAN et des disques virtuels VHD.

●

Support natif des disques SSD (SolidState Devices).

●

Nouvelle architecture FCI (File Classification Infrastructure).

En termes de fondation orientée infrastructure Windows 7 : ●

Services d’accès distants DirectAccess.

●

Services de mise en cache avancé BranchCache.

●

Performances en copie de fichiers au travers des réseaux étendus.

●

Amélioration des objets stratégies de groupe.

●

Accès aux applications via RemoteApp et les connexions aux bureaux distants.

En termes de technologies de virtualisation : ●

HyperV v2 avec Live Migration.

- 1-

●

Ajout et suppression du stockage à chaud.

●

Remote Desktop Services.

En termes de services d’administration :

●

Gestion de l’énergie : Processors Core Parking.

●

Windows PowerShell

●

Active Directory Administration Center.

●

Best Practices Analyzer.

En termes de services Web :

●

IIS version 7.5

●

ASP.Net disponible en mode Server Core.

●

Enhanced FTP et WebDAV.

●

Modules d’administration et Windows PowerShell pour IIS.

Pour plus de renseignements sur les nouveautés de Windows Server 2008 R2, recherchez sur le site de Microsoft « Windows Server 2008 R2 Documentation & Ressources ». Vous y trouverez une collection très complète des meilleurs documents, présentations PowerPoint et ressources en rapport avec toutes les nouveautés de Windows Server 2008 R2.

2. Nouveautés d’HyperV v2 Introduite avec Windows Server 2008 x64 Build 6001 SP1 Editions Standard, Entreprise et Datacenter, la technologie de virtualisation HyperV fait depuis cette version partie intégrante de l’offre système de Microsoft. La nouvelle version d’HyperV intégrée à Windows Server 2008 R2 apporte trois axes d’amélioration importants qui aideront à la mise en œ uvre de Datacenters de plus en plus dynamiques, et aussi de plus en plus respectueux de l’environnement. Ces axes d’évolution intégrent donc de nouvelles technologies pour que les performances et les fonctionnalités soient améliorées et que les matériels se trouvant dans les salles machines consomment le moins d’énergie possible.

a. Meilleure disponibilité des hôtes et des machines virtuelles La version d’HyperV incluse dans Windows Server 2008 R2 permet de mieux répondre à la nécessité de l’augmentation de la disponibilité des Datacenters mettant en œ uvre des technologies de virtualisation. Les technologies qui permettront d’y parvenir sont listées cidessous :

- 2-

●

Support de la fonctionnalité Live Migration via les volumes CSV (Cluster Shared Volumes) : grâce à cette fonctionnalité, les machines virtuelles peuvent être migrées sans aucune interruption, ni perte de service. Live Migration utilise les nouveaux volumes CSV supportés par les nouveaux services de basculement, Failover Clustering, de Windows Server 2008 R2. Ce nouveau type de volume en cluster permet à plusieurs nœ uds du même cluster d’accéder de manière concurrente au même LUN. Du point de vue d’une machine virtuelle, chaque machine virtuelle à l’illusion de disposer de son propre LUN.

●

Support de la gestion dynamique du stockage des machines virtuelles sur SCSI.

●

Méthode de déploiement des serveurs physiques et des serveurs virtuels à l’aide d’une image unique sous la forme d’un disque dur virtuel de type VHD.

●

Amélioration de la tolérance de panne pour la connectivité des nœ uds des Clusters : les composants CSV implémentent un mécanisme appelé Dynamic I/O redirection, pour redirection des I/O en dynamique, lequel permet aux opérations d’entrées/sorties d’être reroutées au sein du cluster Windows en fonction de la connectivité.

●

Amélioration des outils de validation des configurations en cluster Windows.

●

Intégration des BPA (Best Practices Analyzer), au sein de Windows Server 2008 R2 pour les rôles de serveur les plus importants, y compris pour le rôle de cluster à basculement.

b. Meilleure administration des hôtes et des machines virtuelles Nous avons vu au début de cet ouvrage que les platesformes de virtualisation jouaient un rôle déterminant en termes de souplesse, d’économies d’énergie et de mise en œ uvre de solutions dynamiques, de solutions de haute disponibilité et aussi comme élément central des plans de reprise d’activité. Cependant, malgré ces avantages indéniables, les machines virtuelles ont toujours besoin d’être administrées, et ce, quel que soit le système d’exploitation invité. La virtualisation des serveurs permettant un déploiement rapide facilité, sans nécessiter d’investissements matériels directement associés, il est constaté un nombre de machines virtuelles en nette augmentation. Ce constat met en avant un phénomène de prolifération des serveurs et d’augmentation des coûts relatifs à l’administration des serveurs. Un point important, qui mérite d’être rappelé, concerne l’importance des opérations de gestion, d’administration et de supervision des environnements virtualisés. Pour permettre de prendre en charge ces opérations, Windows Server 2008 R2 et les différents logiciels associés progressent de la façon suivante : ●

Meilleure utilisation de la console de gestion HyperV pour les tâches quotidiennes.

●

Meilleure utilisation de la ligne de commande et des fonctions d’automation via l’interface de commande Windows PowerShell qui est désormais présente dans les installations en version minimale de Windows Server 2008 R2, mode Core, et aussi dans Microsoft HyperV Server 2008 R2. Une autre fonctionnalité apportée par R2 est PowerShell v2, lequel supporte désormais un mode "remoting" basé sur WinRM.

Pour rappel, WinRM n’est autre que l’implémentation Microsoft du protocole WSManagement.

À propos de la librairie PowerShell pour HyperV disponible via CodePlex : la version 1.00b disponible à ce jour en téléchargement via http://pshyperv.codeplex.com/, permet aux administrateurs ne disposant pas de SCVMM 2008 de disposer d’une collection de 80 commandes PowerShell prenant en charge la quasitotalité des opérations d’administration d’HyperV et de gestion des machines virtuelles. Les tests de la version 1.00b avec R2 montrent un fonctionnement correct mais non garanti. Pour cette raison, une version 2 de cette librairie est en cours de développement pour supporter HyperV v1 et aussi HyperV v2. Bien que l’initiative de la création de cette librairie soit plébiscitée par tous, il n’en demeure pas moins que l’administrateur devrait utiliser SCVMM 2008 R2 et l’interface PowerShell de SCVMM 2008 R2.

●

Améliorations apportées à SCVMM 2008 R2 via la prise en charge des nouvelles fonctionnalités de la version d’HyperV comprise avec Windows Server 2008 R2.

●

Ajout à SCVMM 2008 R2 des fonctionnalités de Quick Storage Migration, aussi appelée QSM. Cette fonctionnalité nécessite des serveurs HyperV v2 et utilise le protocole de transfert BITS (Background Intelligent Transfert Service). Nous verrons plus loin que cette fonctionnalité est très attendue par les administrateurs HyperV puisqu’elle facilite la prise en charge de la migration du stockage des machines virtuelles dans les deux grands scénarios suivants : ●

Scénario de migration du stockage : dans ce premier scénario, la machine virtuelle s’exécute sur le même serveur et son stockage est migré vers un autre emplacement.

●

Scénario de migration de type réallocation : dans ce second scénario, la machine virtuelle est déplacée vers une autre machine hôte et son stockage est migré vers un autre emplacement.

Grâce à cette nouvelle fonctionnalité, la migration du stockage d’un emplacement à un autre peut être réalisée lorsque la machine virtuelle est en cours de fonctionnement. Cependant, à la différence de Live Migration, la machine virtuelle devra être placée dans l’état « Enregistré » pendant quelques minutes. Ce temps

- 3-

est nécessaire pour migrer l’état mémoire et les disques de différenciation de la machine virtuelle, et garantir l’intégrité des données transférées.

●

Gestion des disques de démarrage et des disques de données : la nouvelle version de Windows Server 2008 R2 apporte une évolution remarquable des fichiers de disques durs virtuels VHD : ●

Premièrement, il est désormais possible de rajouter et de retirer des disques durs virtuels VHD ainsi que des disques durs déclarés en mode Passthrough sur des contrôleurs virtuels SCSI, à chaud, c’estàdire sans que cela nécessite un redémarrage.

●

Enfin, Windows Server 2008 R2 peut être physiquement démarré à partir d’un fichier VHD stocké localement sur le disque dur physique d’une machine. Cette nouvelle fonctionnalité permet à des machines virtuelles ou à des machines physiques d’utiliser un même fichier VHD. La notion de physique ou de virtuel tend à s’effacer en fournissant aux administrateurs une méthode simple concernant la phase de test, souvent réalisée à l’aide de machines virtuelles, et la mise en production qui elle, pourra être réalisée via une machine virtuelle ou une machine physique, en fonction des situations.

c. Meilleures performances processeurs, mémoire et support des fonctions matérielles À sa sortie, HyperV v1 prenait en charge 4 processeurs physiques Quad Core, soit un maximum de 16 cœ urs. La version 1 d’HyperV a fait l’objet d’un patch pour prendre en charge les nouveaux processeurs équipés de 6 cœ urs. En fonction des configurations, il pourra être nécessaire d’installer le patch KB956710 disponible en téléchargement sur le site de Microsoft et permettre ainsi une prise en charge, pour HyperV v1, de 4 processeurs physiques à 6 cœ urs, soit 24 cœ urs au maximum.

d. Nombre de cœurs et nombre de machines virtuelles supportées avec HyperV v1 HyperV supporte jusqu’à 8 processeurs virtuels pour chaque processeur logique affecté à HyperV (ratio de 8:1). Le fait que HyperV v1 gère jusqu’à 24 cœ urs permet à HyperV v1 de supporter de 128 à 192 machines virtuelles. Cependant, vous devez aussi tenir compte du nombre de cœ urs affectés à chaque machine virtuelle. Par exemple, si chaque machine utilise 2 cœ urs virtuels et que HyperV dispose de 16 cœ urs, alors le nombre maximum de machines virtuelles sera de 64. En utilisant le même ratio, si HyperV dispose de 24 cœ urs, alors le nombre de machines virtuelles pourra atteindre 96. HyperV v2 dispose de performances encore améliorées. En effet, HyperV v2 supporte désormais 64 processeurs logiques au niveau du pool de processeurs de la machine hôte HyperV. HyperV v1 et v2 supportent un maximum de 512 machines virtuelles « déclarées » par machine hôte. À propos du nombre de machines virtuelles officiellement supportées avec Windows Server 2008 R2 et HyperV v2 : le nombre de machines virtuelles prises en charge simultanément dépend essentiellement des caractéristiques physiques de la machine hôte et des charges prises en charge par les machines virtuelles. HyperV v2 prend en charge 64 cœ urs pour 1 To de mémoire RAM. À l’heure où ces lignes sont écrites, Microsoft n’a pas encore annoncé le nombre maximum de machines virtuelles officiellement prises en charge par la version 2 d’HyperV. Microsoft annoncera le nombre de machines virtuelles officiellement supportées peu de temps avant la sortie de la version RTM. Si le ratio de 8:1 est toujours conservé, ce qui devrait être le cas, le nombre de machines virtuelles simultanées pourrait atteindre 512.

e. Caractéristiques des versions de Windows Server 2008 et HyperV Les différentes versions de Windows Server 2008 supportent les caractéristiques suivantes : Windows Server 2008 Edition Standard avec HyperV (v1) ●

4 sockets x64 32 Go de RAM aucune fonctionnalité de haute disponibilité. Cette version est proposée par Microsoft pour répondre aux besoins d’entrée de gamme et de tests.

Windows Server 2008 Edition Entreprise avec HyperV (v1) ●

- 4-

8 sockets x64 jusqu’à 24 cœ urs maximum.

●

2 To de RAM pour Windows Server 1 To de RAM pour HyperV.

●

Haute Disponibilité via cluster jusqu’à 16 nœ uds et Quick Migration.

Windows Server 2008 Edition Datacenter avec HyperV (v1) ●

64 sockets x64 jusqu’à 24 cœ urs maximum.

●

2 To de RAM pour Windows Server 1 To de RAM pour HyperV.

●

Haute Disponibilité via cluster jusqu’à 16 nœ uds et Quick Migration.

Windows Server 2008 Edition Standard R2 avec HyperV (v2) ●

4 sockets x64 jusqu’à 32 cœ urs maximum 32 Go de RAM maximum aucune fonctionnalité de haute disponibilité. Cette version est proposée par Microsoft pour répondre aux besoins d’entrée de gamme et de tests.

Windows Server 2008 Edition Entreprise R2 avec HyperV (v2) ●

8 sockets x64 2 To de RAM pour Windows Server 1 To de RAM pour HyperV.

●

Haute Disponibilité via cluster jusqu’à 16 nœ uds.

●

Support de Quick Migration et Live Migration.

Windows Server 2008 Edition Datacenter R2 avec HyperV (v2) ●

64 sockets x64 2 To de RAM pour Windows Server 1 To de RAM pour HyperV.

●

Haute Disponibilité via cluster jusqu’à 16 nœ uds.

●

Support de Quick Migration et Live Migration.

Les versions Entreprise et Datacenter de Windows Server 2008 R2 disposent des fonctionnalités additionnelles suivantes : ●

Support du moteur de réplication DFSR.

●

Support du cluster WSFC à 16 nœ uds.

●

Gestion de la mémoire à tolérance de panne Fault Tolerant Memory Sync.

●

Ajout à chaud de mémoire RAM Hot Add Memory.

●

Ajout à chaud des processeurs Hot Add Processors.

●

Remplacement à chaud de la mémoire, Hot Replace Memory, pour la version Datacenter seulement.

●

Remplacement à chaud des processeurs, Hot Replace Processors, pour la version Datacenter seulement.

●

Droit de virtualisation inclus pour 4 machines virtuelles pour la version Entreprise et illimité pour la version Datacenter.

●

Quick Migration

●

Live Migration

- 5-

●

Quick Storage Migration via SCVMM 2008 R2.

Nombres de processeurs supportés par Windows Server 2008 R2 : comme cela était le cas avec Windows Server 2003, Microsoft définit pour Windows Server 2008 et Windows Server 2008 R2 le nombre de processeurs logiques comme étant égal au nombre de processeurs physiques multiplié par le nombre de cœ urs multiplié par le nombre de threads. Le noyau de R2 a été optimisé pour que la version Datacenter prenne en charge jusqu’à 256 cœ urs avec un maximum de 64 processeurs physiques. Attention ! Bien que la version Datacenter prenne en charge 64 processeurs physiques pour un maximum de 256 cœ urs, HyperV v2 ne supporte que 64 cœ urs. Support des fonctionnalités de gestion mémoire SLAT Second Level Address Translation : les processeurs à technologie de virtualisation intégrée les plus récents permettent la gestion d’un second niveau de pagination en dessous des tables de pagination x86 / x64. SLAT implémente une couche d’indirection entre l’accès mémoire de la machine virtuelle et l’accès à la mémoire physique. Dans les scénarios de virtualisation particulièrement chargés, la prise en charge SLAT matérielle améliore de manière significative les performances. Cette fonctionnalité nécessite que les processeurs Intel supportent le mode EPT (Extended Page Tables), et que les processeurs AMD supportent le mode NPT (Nested Pages Tables). Support de l’immobilisation des cœurs Core Parking : cette nouvelle fonctionnalité permet à HyperV de suspendre l’utilisation de cœ urs non ou sousutilisés pour consolider les traitements sur un nombre de cœ urs de processeurs réduits. L’idée est donc de suspendre les cœ urs de processeur inactifs afin de minimiser la consommation électrique des processeurs.

f. À propos d’HyperV Server 2008 R2 Apparu avec Windows Server 2008, Microsoft HyperV Server est une version gratuite de l’hyperviseur HyperV. Dans sa version initiale disponible quelques mois après la sortie officielle de Windows Server 2008, les caractéristiques du produit étaient quelque peu limitées. Ainsi, HyperV Server 2008 supporte : ●

4 processeurs physiques x64 pour 24 cœ urs au maximum.

●

32 Go de mémoire RAM.

●

Aucune fonctionnalité de haute disponibilité.

●

Aucune licence d’utilisation de Windows Server en tant que machine virtuelle.

Pour ces raisons, la première version d’HyperV Server 2008 était plutôt destinée aux environnements de tests et de développement, Microsoft recommandant d’utiliser la version d’HyperV fournie avec Windows Server 2008 lorsqu’il était nécessaire de supporter plus de 4 processeurs physiques, plus de 32 Go de mémoire RAM et les fonctionnalités de haute disponibilité telles que Quick Migration et le support du cluster jusqu’à 16 nœ uds. Apports de la version HyperV Server 2008 R2 Avec la dernière version R2, Microsoft entend offrir à ses clients une version bien plus complète de sa technologie de virtualisation HyperV. Toujours disponible gratuitement et adaptée aux besoins des petites et moyennes entreprises, cette version répond aux demandes des clients en y intégrant, sans aucun coût, les fonctionnalités suivantes :

- 6-

●

Support de 8 processeurs physiques x64 et 64 cœ urs.

●

Support de 1 To de RAM.

●

Support de Live Migration pour le déplacement, sans aucune interruption des machines virtuelles entre machines hôtes.

●

Support du cluster jusqu’à 16 nœ uds pour la prise en charge des interruptions de services non planifiées.

●

Coût total de possession inférieur comparé à l’offre VMware ESXi qui n’inclut aucune fonctionnalité de haute disponibilité gratuitement.

●

Support officiel d’HyperV Server 2008 R2 dans les environnements de production jusqu’à 32 machines virtuelles de type « Serveur » ou 64 machines virtuelles de type VDI (Virtual Desktop Infrastructure).

●

Administration centralisée via l’installation des outils d’administration HyperV sur une machine Windows Vista, Windows Server 2008 ou Windows 7, via l’utilisation de l’utilitaire de configuration Sconfig, via Windows PowerShell et via SCVMM 2008 R2.

La nouvelle commande de configuration Sconfig d’HyperV Server 2008 R2 permet d’accélérer la mise en œ uvre d’un serveur HyperV Server 2008 R2. Grâce à cette nouvelle commande, un outil de type mode caractère permet une gestion facilitée des opérations suivantes : nommage de la machine, Intégration au sein du domaine AD, Configuration de l’administration à distance en activant l’administration via Server Manager, Windows PowerShell et en configurant le Parefeu Windows, Configuration des mises à jour Windows Update, Activation du Bureau à distance et la configuration des paramètres IP v4 et IP v6 de n cartes réseau. Différences majeures entre HyperV Server 2008 R2 et les versions d’HyperV disponibles avec Windows Server 2008 Edition Entreprise et Datacenter R2 HyperV Server 2008 R2 est gratuit, certes ! Cependant, à la différence des versions « complètes » de Windows Server, il dispose d’un support limité en fonction du nombre de machines virtuelles : 32 machines virtuelles serveurs et 64 en VDI. Enfin, HyperV Server 2008 R2 supporte toutes les fonctionnalités de haute disponibilité, cluster et migration en Live, mais ne supporte pas les fonctionnalités avancées telles que l’ajout à chaud de mémoire RAM, Hot Add Memory, l’ajout à chaud des processeurs, Hot Add Processors, le remplacement à chaud de la mémoire, Hot Replace Memory ainsi que le remplacement à chaud des processeurs, Hot Replace Processors. Licences Windows Server HyperV Server 2008 R2 ou Windows Server 2008 R2 Edition Entreprise ou Datacenter ? Audelà de 7 machines virtuelles Windows Server, Microsoft recommande d’acquérir l’édition Datacenter tarifée à quelques 2999 $ par processeur physique et qui donne le droit d’installer un nombre illimité de machines virtuelles Windows Server 2008 associé d’un droit de downgrade (cf. section Virtualisation et licences Windows Server) ! À l’heure du choix, tous ces critères seront à considérer. À propos des droits de downgrade : consultez la page Windows Server 2008 Downgrade Rights à l’adresse http://www.microsoft.com/windowsserver2008/en/us/downgraderights.aspx

g. Virtualisation et licences Windows Server La gestion des licences Windows Server, et aussi des systèmes d’exploitation clients, a fait l’objet d’évolutions importantes « pour faire percevoir aux entreprises » qu’il y avait de nombreux intérêts à virtualiser les nouveaux serveurs et pas seulement les anciens ! Les points cidessous expliquent rapidement cette politique. Droit d’installation de la version N1 Est inclus avec une licence Windows Server 2008 le droit d’exécuter une instance de n’importe quelle version précédente de Windows Server à la place de la version de Windows Server 2008 acquise. Les termes de la licence Windows Server 2008 acquise s’appliquent à l’utilisation de la version précédente utilisée. Microsoft fournit un droit de « downgrade » à ses clients car de nombreux circuits de distribution prennent seulement en charge la vente des dernières versions de produits. La fourniture du droit de « downgrade » permet donc aux clients de faire l’acquisition de la dernière version d’un produit tout en ayant le droit d’installer une version antérieure. Cette possibilité est bien sûr très intéressante lorsque l’entreprise n’est pas prête à installer la dernière version mais souhaite acquérir la nouvelle version en prévision de la transition future. Un autre scénario classique concerne l’installation d’applications anciennes nécessitant l’usage d’une version plus ancienne. Windows Server 2008 : droit de downgrade Lorsque le client dispose déjà du média et de clés d’activation, Microsoft accorde l’usage de ce média et de ces clés pour utiliser une version inférieure. Si par contre, le client ne dispose pas de ces éléments, il lui faudra se procurer un kit de mise en œ uvre comprenant seulement Windows Server 2003 R2 Edition Standard ou Edition Entreprise. Cas des Clients « Retail » Les clients achetant des produits pleins hors contrat disposent des mêmes droits d’utilisation d’une version antérieure que les clients disposant d’un contrat en volume ou de type OEM. La seule différence consiste dans la fourniture du ou des médias et des clés permettant l’installation de la version antérieure du produit. Utilisation d’anciens médias et d’anciennes clés d’installation La première méthode consiste à utiliser les médias et les clés dont le client peut disposer suite à un achat antérieur, sachant que cette version peut être issue de tous les canaux de distribution Microsoft VL, OEM, etc. Le problème

- 7-

qui peut se poser concerne l’activation via Internet d’un produit ayant déjà été activé par le passé. En pareils cas, le client peut contacter le Centre d’activation en ligne et expliquer les circonstances de la demande de « downgrade ». Une fois qu’il a été établi que le client possède bien une version d’un produit donnant droit à un « downgrade », le service de support Microsoft prend en charge l’activation du produit. Obtention des Kits de mise en œuvre et de nouvelles clés d’installation La deuxième méthode permet aux clients ne disposant pas des médias ou des clés nécessaires à l’installation de commander un « downgrade media kit » contenant Windows Server 2003 R2. Ce kit contient les médias ainsi qu’une clé d’installation donnant droit à l’usage de l’ancienne version à la place de la nouvelle. Microsoft précise que la clé ainsi obtenue n’est pas une nouvelle licence Windows mais seulement un droit d’utilisation d’une version antérieure. Pour plus d’informations sur la gestion des licences de type « downgrade », référezvous au site Microsoft « The Windows Server Fulfillment site » disponible à l’adresse cidessous : http://www.microsoft.com/windowsserver2008/en/us/downgradeTC.aspx

Clients OEM En général, les clients OEM (Original Equipment Manufacturers), obtiennent leurs licences et médias directement de la part de leurs fournisseurs de matériels. Néanmoins, ils disposent des mêmes droits de « downgrade » de version. En fonction des produits et des contrats OEM, la procédure d’obtention des médias et des clés peut être réalisée de la même manière que celle vue précédemment via le site Microsoft « The Windows Server Fulfillment site », mais elle peut aussi être réalisée différemment. Attention ! Microsoft précise que le fabricant du serveur n’est pas tenu d’assurer la fourniture ni le support des versions antérieures du produit. Si tel est le cas, le client devra se rapprocher de Microsoft pour obtenir les médias et clés nécessaires.

h. Meilleures performances des réseaux virtuels HyperV v2 tire parti des nouvelles améliorations implémentées au niveau des fonctionnalités réseau de Windows Server 2008 R2. Les améliorations les plus importantes sont les suivantes : ●

Support des fonctionnalités de déchargement TCP TCP Chimney.

●

Support des Jumbo Frames.

Ces fonctionnalités étaient déjà implémentées dans Windows Server 2008 mais non exploitées par la première version d’HyperV. HyperV v2 étend désormais ces fonctionnalités aux machines virtuelles accueillies par HyperV. Ces deux évolutions permettent de décharger les processeurs tout en obtenant une meilleure performance réseau. Il est aussi notable que ces évolutions sont supportées avec Live Migration. Le mode VM Chimney nécessite des cartes réseau compatibles. Afin d’éviter des problèmes d’incompatibilité, la valeur par défaut désactive l’usage de cette fonctionnalité.

Le Jumbo Frames permet d’utiliser des tailles de trames permettant de transporter chacune six fois la capacité de transport de données d’une trame Ethernet classique de 1200 octets. Cette fonctionnalité est particulièrement intéressante pour les transferts de fichiers de taille volumineuse.

3. Nouveautés de System Center Virtual Machine Manager 2008 R2 a. Introduction : vous avez dit R2 ? La version R2 de System Center Virtual Machine Manager 2008 inclut de nouvelles fonctionnalités en relation directe avec les nouveautés implémentées dans la nouvelle version d’HyperV disponible dans Windows Server 2008 R2.

- 8-

En plus de la prise en charge de la première version d’HyperV contenue dans Windows Server 2008, de Microsoft HyperV Server 2008, de Microsoft Virtual Server 2005 R2 Edition Entreprise et de VMware ESX 3.5, cette nouvelle version R2 prend en charge les machines hôtes HyperV v2 fonctionnant sous Windows Server 2008 R2 ainsi que Microsoft HyperV Server 2008 R2. Le fait d’ajouter une machine hôte Windows Server 2008 R2 à SCVMM 2008 R2 ajoute automatiquement le rôle de serveur HyperV. Les fonctionnalités nouvelles apportées à la version R2 de System Center Virtual Machine Manager sont nombreuses et sont détaillées plus bas.

b. SCVMM 2008 R2 et les machines hôtes Windows Server 2008 HyperV R2 Les nouvelles possibilités offertes aux administrateurs des environnements de virtualisation VMM en liaison directe avec Windows Server 2008 R2 sont présentées cidessous : ●

Support des migrations de machines virtuelles en mode Live Migration entre les nœ uds Windows Server 2008 R2. Cette fonctionnalité majeure pour répondre aux contraintes les plus fortes en termes de haute disponibilité permet le déplacement des machines virtuelles entre des nœ uds Windows Server 2008 R2 membres du même cluster à basculement.

La machine virtuelle migrée n’est sujette à aucune coupure ou perte de service. Le déplacement est donc totalement transparent pour les utilisateurs connectés à la machine virtuelle.

●

Support de l’ajout et de la suppression à chaud des disques virtuels fichiers VHD et des disques en mode passthrough via un contrôleur virtuel SCSI ou via le protocole iSCSI. Cette fonctionnalité majeure pour répondre aux contraintes les plus fortes en termes de haute disponibilité permet à l’administrateur d’ajouter ou de supprimer du stockage aux machines virtuelles pouvant le nécessiter. Les machines virtuelles accueillant des applications telles que Microsoft Exchange Server, Microsoft SQL Server ou d’autres applications nécessitant de l’espace disque pourront tirer profit de cette nouvelle possibilité.

●

Support de nouvelles optimisations réseau lors des opérations de placement des machines virtuelles. SCVMM 2008 R2 exploite les nouvelles fonctionnalités apportées par Windows Server 2008 R2 en matière d’optimisations réseau pour HyperV v2, à savoir le support de VMQ (Virtual Machine Queue) et du protocole TCP Chimney, aussi appelé TCP Offload.

Le protocole TCP Chimney nécessite un composant matériel embarqué généralement appelé TOE pour TCP/IP Offload Engine. Cette problématique est traitée plus loin avec plus de détails.

●

Support d’une file d’attente réseau par machine virtuelle avec accès direct à la mémoire de la machine virtuelle lors de l’utilisation des cartes réseau compatibles avec les fonctionnalités VMQ.

●

Meilleure gestion des permissions HyperV : SCVMM 2008 R2 préserve le magasin d’autorisations HyperV par défaut InitialStore.xml, en termes de définition des rôles et membres de ces différents rôles au sein de la racine du magasin. Les autres emplacements du magasin HyperV sont systématiquement rafraîchis toutes les 30 minutes par SCVMM 2008 R2. La version précédente de SCVMM détermine les accès aux machines hôtes et aux différentes machines virtuelles uniquement sur la base des rôles définis au sein de l’environnement SCVMM 2008 R2. Il n’altère en rien le magasin d’autorisations propre à chaque machine hôte HyperV. Le magasin d’autorisations HyperV est tout simplement ignoré pour toutes les machines virtuelles contrôlées par SCVMM 2008 R2.

Le magasin des autorisations HyperV utilise AzMan (Authorization Manager). Le gestionnaire d’autorisations AzMan peut être lancé en invoquant le fichier de console de gestion MMC azman.msc.

- 9-

InitialStore.xml est stocké dans le dossier C:\ProgramData\Microsoft\Windows\HyperV.

Modification du magasin AZMAN d’HyperV

Pour plus de renseignements sur la configuration complète des rôles HyperV via Authorization Manager, reportezvous aux articles cidessous publiés sur le site Microsoft Technet : « Planning HyperV Security » et « Configure HyperV for Rolebased Access Control ».

c. SCVMM 2008 R2 et la gestion du stockage SAN Les nouvelles options prises en charge par VMM relatives à la gestion du stockage sont présentées cidessous : ●

Support des nouveaux volumes CSV(Cluster Shared Volumes) gérés par Windows Server 2008 R2 et les services de cluster de basculement. Les volumes CSV permettent à tous les nœ uds d’un cluster à basculement Windows Server 2008 R2 d’accéder de manière concurrente aux fichiers des machines virtuelles situés sur un LUN (Logical Unique Number) partagé sur le SAN. La possibilité offerte à tous les nœ uds du cluster d’accéder à un stockage unique virtuellement partagé permet aux différentes machines virtuelles de ne plus être contraintes de respecter quel nœ ud du cluster est actuellement en possession de tel LUN. Cette possibilité permet la mise en œ uvre de la migration des machines virtuelles en mode Live Migration.

●

Support du mode Quick Storage Migration : les machines hôtes Windows Server 2008 R2 disposant d’un réseau de stockage partagé configuré pour utiliser les fonctionnalités de migration Live Migration et les machines hôtes VMware disposant d’un stockage pris en charge par VMWare peuvent utiliser les nouveaux services de migration du stockage pour migrer les fichiers d’une machine virtuelle vers un système de stockage différent accessible par la même machine hôte, et ce, avec une interruption de service minimale ou nulle.

Une des nouvelles options de cet assistant laisse désormais la possibilité à l’administrateur de spécifier des emplacements de stockage différents pour chaque disque virtuel de la machine virtuelle.

- 10 -

VMM 2008 non R2 ne supporte pas cette possibilité. Les interfaces graphiques de cette version ne permettent de sélectionner qu’un seul et unique chemin. Une solution consiste à créer la machine virtuelle avec un seul disque puis, dans un deuxième temps, à utiliser PowerShell.

●

Support du mode de maintenance : SCVMM 2008 R2 supporte un nouveau mode appelé Mode de Maintenance. Ce mode peut être appliqué à tout moment à une ou plusieurs machines hôtes HyperV lorsqu’il est par exemple nécessaire de procéder à des tâches de maintenance. Cette action rend impossible les opérations de création de machines virtuelles et exclut la machine hôte des calculs d’évaluation d’ordinateurs hôtes pendant la sélection élective d’ordinateurs virtuels.

Démarrage du mode maintenance sur une machine hôte HyperV En fonction de la configuration du cluster de machines hôtes HyperV et de la configuration des machines virtuelles, mode haute disponibilité ou non, le passage en mode de maintenance provoquera la migration de toutes les machines virtuelles vers d’autres machines hôtes du même cluster HyperV. Si toutes les machines ne sont pas migrées ou dans un état enregistré, alors le mode de maintenance n’est pas implémenté et les machines virtuelles déjà migrées ne sont pas automatiquement remigrées vers la machine hôte source. Lorsque le mode de maintenance est activé sur une machine hôte HyperV autonome ou une machine hôte HyperV membre d’un cluster, ou lorsqu’une machine virtuelle n’est pas configurée en mode Haute disponibilité, alors VMM 2008 R2 place automatiquement toutes les machines virtuelles de la machine hôte dans l’état État enregistré.

- 11 -

Les machines hôtes HyperV positionnées mises en mode maintenance n’acceptent plus les opérations de création de machines virtuelles, ne participent plus aux évaluations de placement des machines virtuelles et apparaissent dans l’interface SCVMM 2008 R2 avec le statut État global : En mode de maintenance.

●

Support des Migrations SAN au sein et en dehors des configurations en cluster : SCVMM 2008 R2 supporte l’utilisation des transferts SAN pour migrer les machines virtuelles et les machines virtuelles hautement disponibles au sein et en dehors d’un cluster. Lorsque l’administrateur VMM initie la migration d’une machine virtuelle au sein d’un cluster, VMM s’assure que tous les nœ uds peuvent accéder au nouveau LUN et crée au sein du cluster une ressource disque pour ledit LUN. Une fois la ressource disque validée par l’administrateur à l’aide de l’assistant de validation de la configuration du cluster, la migration de la machine virtuelle pourra avoir lieu.

●

Support étendu pour les SAN iSCSI : SCVMM 2008 non R2 supporte l’utilisation des transferts SAN basés sur des connexions iSCSI, lesquelles nécessitent une cible iSCSI pour chaque LUN. SCVMM 2008 R2 prend en charge la gestion du masquage des LUN, permettant ainsi au serveur d’accéder à plusieurs LUN par cible iSCSI. De plus, la version R2 intègre le support des dernières solutions proposées par les fournisseurs de solutions de stockage iSCSI.

Les cibles iSCSI permettent de gérer les connexions entre les soussystèmes de stockage iSCSI du SAN et les machines hôtes qui ont besoin d’y accéder. La méthode consiste à attribuer des numéros de LUN à des cibles de telle sorte que toutes les machines hôtes qui s’y connecteront auront accès aux LUN qui y sont associés. En général, ces opérations sont facilement réalisées. Cependant, certains systèmes de stockage iSCSI ne prennent en charge que des cibles « simples ». Ces configurations ne sont pas souples à administrer car il n’est pas possible de supprimer une cible particulière, ni de leur attribuer des LUN manuellement. Le masquage des LUN est basé sur un processus d’authentification permettant de rendre des LUN disponibles à certaines machines et indisponibles à d’autres. En général, cette technique de masquage est implémentée au sein des contrôleurs HBA (Host Bus Adapter). Ce point devrait être considéré plus qu’il ne l’est aujourd’hui car si le contrôleur HBA est sujet à une tentative d’agression ayant réussi, le masquage des LUN peut alors être compromis. ●

Support du système de fichiers tiers fourni par Sanbolic : SCVMM 2008 R2 prend en charge les opérations de migration de machines virtuelles en mode Quick Migration et en mode Live Migration avec le système de fichiers cluster Melio FS. Sanbolic fournit aussi le gestionnaire de volumes en cluster LaScala, lequel est aussi supporté au sein de l’environnement de virtualisation System Center Virtual Machine Manager 2008 R2.

Pour plus de renseignements sur les produits Sanbolic pour les platesformes VMware ESX et Microsoft HyperV, reportezvous au site Sanbolic http://www.sanbolic.com. Des informations concernant les nouveautés apportées à Sanbolic Melio FS pour SCVMM 2008 R2 sont contenues dans le document disponible via le lien cidessous : http://www.sanbolic.com/pdfs/Sanbolic_Press_Release_SCVMM_2008R2.pdf

●

Support de la technologie Veritas Storage Foundation 5.1 for Windows : SCVMM 2008 R2 tire profit des volumes clusters créés et gérés par SFW. Les volumes Veritas sont détectés automatiquement par SCVMM 2008 R2 de telle sorte que l’administrateur peut sélectionner un volume Veritas dans le cadre des opérations de placement ou de migration de machines virtuelles.

Attention ! À la différence des volumes Microsoft CSV (Cluster Shared Volumes), ou des volumes Sanbolic Melio FS, un volume Veritas SFW ne peut supporter qu’une seule machine virtuelle.

d. SCVMM 2008 R2 et les machines hôtes VMware ESX Les nouvelles options prises en charge par VMM 2008 R2 relatives à la gestion des machines hôtes VMware ESX sont présentées cidessous : ●

- 12 -

SCVMM 2008 R2 supporte les groupes de ports pour les Switchs virtuels VMware : SCVMM 2008 R2 utilise les propriétés Emplacements réseau et Légendes réseau spécifiées pour la carte du réseau virtuel au niveau de la configuration matérielle pour déterminer la disponibilité du réseau spécifié pour une machine virtuelle

sur une machine hôte donnée. Désormais, lors du déploiement d’une machine virtuelle vers une machine hôte ESX, VMM 2008 R2 permet à l’administrateur de sélectionner la connectivité souhaitée à partir des groupes de ports disponibles pour les Switchs virtuels VMware. ●

Comparaison des propriétés réseau avec HyperV : les machines hôtes HyperV contrôlées par SCVMM 2008 et SCVMM 2008 R2 disposent de propriétés réseau particulières. Ainsi, un réseau virtuel donné dispose d’un nom, d’une légende réseau et aussi d’une description, qui seront utilisés par VMM pour déterminer les meilleures machines hôtes aptes à supporter telle ou telle machine virtuelle.

Pour rappel, la valeur de l’attribut Emplacement réseau est définissable dans les propriétés de la machine hôte HyperV (Matériel Cartes réseau La carte souhaitée Emplacement réseau). La déclaration de l’attribut Légende réseau est définissable dans les propriétés de la machine hôte HyperV (Mise en réseau Mise en réseau virtuelle Cartes réseau La carte souhaitée Légende réseau).

Les paramètres Emplacement réseau et Légende réseau sont utilisés lors des opérations de placement des machines virtuelles. Les paramètres déclarés dans les propriétés de la machine virtuelle sont comparés aux paramètres de la machine hôte pour évaluer ses possibilités. Ce contrôle aide l’administrateur à placer la machine virtuelle sur une machine hôte capable de répondre à ses exigences. Par exemple, si un réseau virtuel déclaré sur une machine hôte HyperV possède une condition de connexion d’emplacement réseau nommée VLAN1ADMIN tandis qu’une autre est nommée VLAN40PROD et que vous souhaitez qu’une machine virtuelle d’administration soit connectée sur le réseau d’administration, faites en sorte que les propriétés réseau de la machine virtuelle soient définies pour utiliser le réseau souhaité. Notez que le choix par défaut « Non spécifié » signifie qu’aucune exigence particulière n’est définie. De cette manière, l’administrateur peut orienter la sélection élective en déterminant une équivalence entre les réseaux virtuels pris en charge par plusieurs machines hôtes HyperV. Les réseaux virtuels déterminent leur emplacement via la carte réseau de la machine hôte qui leur est associée. Une machine hôte peut être équipée de plusieurs cartes réseaux reliées à plusieurs réseaux virtuels. L’administrateur peut dans ce cas définir une seule adresse pour définir cet emplacement. De cette manière, une machine virtuelle peut être déplacée et donc changer d’emplacement tout en conservant la connectivité réseau nécessaire.

- 13 -

Haute disponibilité des machines virtuelles via Live Migration 1. Comparaison entre Quick Migration et Live Migration a. Introduction L’un des points les plus importants considéré par les équipes informatiques ayant en charge la gestion des Datacenters concerne la haute disponibilité des systèmes et des applications les plus critiques. Depuis plusieurs années maintenant, les Datacenters déploient de plus en plus de platesformes prises en charge via des solutions de virtualisation qui, au même titre que les platesformes physiques, doivent être hautement disponibles. Windows Server 2008 R2 introduit une avancée significative en implémentant la fonctionnalité de migration à chaud sans aucune interruption de service, Live Migration. La version d’HyperV, disponible avec Windows Server 2008, disposait de la fonctionnalité de Quick Migration. Avec cette première fonctionnalité, la haute disponibilité était assurée dans le sens où l’administrateur pouvait déplacer à la volée, c’estàdire sans redémarrage, les machines virtuelles vers une autre machine du cluster HyperV. L’inconvénient introduit par l’opération de Quick Migration était cependant important puisqu’il introduisait une perte du service égale à la somme des périodes de temps nécessaires à l’opération de mise en sommeil, puis au temps de basculement et enfin au temps de réveil de la machine virtuelle sur le nœ ud de destination. Nous avons vu au chapitre traitant de la haute disponibilité des machines virtuelles et des hôtes HyperV que le temps de bascule avec Quick Migration pouvait être compris entre quelques secondes et plusieurs minutes. Ce temps varie en fonction de la quantité de mémoire RAM de la machine virtuelle, du débit disponible sur le SAN, FC ou iSCSI, et aussi de la charge des machines hôtes HyperV. Avec Windows Server 2008 R2, HyperV v2 peut désormais utiliser Live Migration au lieu de Quick Migration. De cette manière, il est possible de déplacer des machines virtuelles sans aucun arrêt ni aucune perte de service en relation avec le système, le réseau ou les applications.

b. Prérequis Les prérequis et méthodes relatives aux opérations de Quick Migration et de Live migration sont très similaires : ●

Dans les deux cas, il est nécessaire de disposer des services de basculement de Windows Server 2008 R2 Edition Entreprise ou Datacenter pour former un cluster Windows comprenant au minimum deux nœ uds et pouvant atteindre un maximum de seize nœ uds.

●

Le cluster Windows doit disposer d’un stockage partagé de type SAN en technologie FC (Fibre Channel) ou iSCSI.

●

Les machines membres du cluster ainsi formé doivent disposer d’au minimum une interface réseau. Il s’agit bien sûr d’un minimum et il est fortement recommandé de respecter les points suivants : ●

une interface réseau dédiée à l’administration du cluster HyperV,

●

une interface réseau utilisable pour les communications intracluster. Bien qu’il soit recommandé de ne pas perturber la disponibilité de l’interface d’administration, cette interface pourra aussi être configurée au niveau de chaque machine virtuelle au sein du cluster HyperV pour les transferts Live Migration,

●

une ou plusieurs interfaces réseau à répartir en autant de commutateurs virtuels, virtual switchs, pour prendre en charge les flux réseau liés aux machines virtuelles.

c. Processus de migration Live Migration Le processus de migration d’une machine virtuelle est présenté cidessous : ●

Dans un premier temps, toutes les pages mémoire sont transférées de la machine hôte HyperV source vers la machine hôte HyperV de destination. Durant cette opération de transfert toutes les modifications mémoire

- 1-

de la machine virtuelle sont sous surveillance. ●

Les pages modifiées lors de la première étape sont transférées vers la machine hôte de destination.

●

Les pointeurs du stockage relatifs aux fichiers VHD de la machine virtuelle sont déplacés vers la machine hôte de destination.

●

Le contrôle de la machine virtuelle est transmis à la machine hôte de destination qui met la machine virtuelle dans l’état En ligne.

L’opération de Live Migration d’une machine virtuelle ne produit aucune coupure perceptible ni par le système d’exploitation ou les applications contenues dans la machine virtuelle, ni par les services réseau. Ce dernier point est possible car l’opération de « transfert » entre les 2 machines hôtes HyperV v2 est très inférieure au timeout d’une connexion TCP.

2. Haute disponibilité, cartes réseau et optimisations apportées par R2 a. Haute disponibilité de la connectivité réseau Toutes les cartes réseau précédemment présentées jouent un rôle important ou critique. En conséquence, vous devrez prévoir de mettre en œ uvre une fonction de teaming au niveau de chaque port réseau. Les cartes réseau proposées par les constructeurs tels que Dell, HP ou IBM, pour ne citer que les trois plus grands, sont adaptées aux débits que l’on sera amené à prendre en charge dans des environnements de virtualisation, de consolidation de serveurs ou de segmentation réseau avec une densité de ports et de bande passante importantes. Pour vous assurer des meilleures performances avec HyperV v2, respectez les points suivants : ●

Utilisez des cartes Quad Ports plutôt que des cartes Dual Ports.

●

Évitez de mélanger des cartes de constructeurs différents : même si ce type de configuration est parfaitement supporté du point de vue logiciel par Microsoft, vous devez vous assurer qu’il en est de même du côté du fabricant du serveur.

Attention ! Il n’est pas rare que le mélange de cartes réseau provenant de multiples fournisseurs pose problème dans les environnements complexes. Dans de pareilles situations, n’insistez pas ! Le coût des cartes réseau n’est pas un point bloquant. Il est vraiment recommandé d’utiliser uniquement des périphériques homogènes au sein des machines soumises à de fortes charges !

- 2-

●

Carte livrée avec des pilotes supportant les fonctions de Teaming (mise en association de plusieurs cartes réseau pour la haute disponibilité et la répartition de la charge).

●

Gestion de multiples VLAN via le support du protocole 802.1q, VLAN Tagging.

●

Support du protocole 802.1p, QoS.

●

Support des Jumbo Frames : ces trames disposent d’un MTU de 9K, c’estàdire six fois plus important que la taille de trame standard Ethernet de 1500 octets pour une bande passante supérieure et une meilleure utilisation des processeurs.

●

Support des fonctions TOE (TCP/IP Offload Engine).

●

Support d’un nombre suffisant de ports au sein d’un team : des constructeurs tels que HP supportent généralement jusqu’à 8 ports réseau au sein du même team.

●

Support d’un nombre suffisant de teams et de ports sur un serveur donné : toujours à titre d’exemple, HP supporte jusqu’à 16 teams sur le même serveur, sachant qu’un team peut accueillir jusqu’à 8 ports réseau au maximum.

●

Support de fonctionnalités de type TLB (Transmit Load Balancing) : ce mode de fonctionnement permet de recevoir sur un port mais transmet en mode répartition de charge sur tous les ports. Ce mode est aussi parfois appelé ALB, pour Adaptive Load Balancing.

●

Support des fonctionnalités de type SLB (SwitchAssisted Load Balancing) : ce mode de fonctionnement permet de recevoir et d’envoyer les trafics en mode répartition de charge sur tous les ports.

b. Optimisations réseau d’HyperV v2 : recommandations Windows Server 2008 R2 offre de nouvelles possibilités en termes d’augmentation significative des performances réseau des machines virtuelles hébergées par les machines hôtes HyperV v2. Ces optimisations ainsi que les remarques concernant leur mise en œ uvre dans un environnement de production sont présentées cidessous : ●

Les optimisations réseau sont implémentées sous la forme du support des protocoles VMChimney (Chimney for Virtual Machines) et VMQ (Virtual Machines Queues). En fonction des contraintes de bande passante réseau et des matériels dont vous disposez, vous pourrez être amené à mettre en œ uvre tout ou partie de ces technologies pour augmenter de manière importante les performances réseau et décharger l’utilisation du ou des processeurs de la machine hôte HyperV.

Les protocoles VMChimney et VMQ nécessitent tous les deux des matériels supportant ces fonctionnalités. L’utilisation du protocole VMChimney est, à ce jour, validée pour les pilotes de périphériques suivants : ●

Cartes Broadcom NetXtreme II 1 Gb/s NICs (Modèles 5706, 5708 et 5709).

●

Cartes Broadcom 10Gb/s NICs (Modèles 57710 et 57711).

L’utilisation du protocole VMQ est quant à lui à ce jour validée pour les pilotes de périphériques cidessous : ●

Cartes Intel Pro/1000 ET, aussi appelées Intel Kawela (E1Q) 1 Gb/s.

●

Cartes Intel 82598, aussi appelées Intel Oplin NICs (IXE) 10Gb/s.

À propos des pilotes supportés : les chipsets Broadcom et Intel sont largement utilisés dans l’industrie par de nombreux fournisseurs de cartes réseau. À l’heure où ces lignes sont écrites, les versions RC (Release Candidate), de Windows Server 2008 R2 (Build 7100 et Build 7260) sont livrées avec les pilotes correspondant aux cartes listées cidessus. Microsoft travaille activement avec l’ensemble des fournisseurs pour que lors de la disponibilité officielle de la version RTM du produit, les pilotes supportant VMChimney et VMQ soient disponibles en téléchargement sur le site de ces fournisseurs. Recommandations et interactions réseau avec VMChimney et VMQ ●

Les pilotes fournis par les constructeurs implémentant des fonctions de Teaming doivent être mis à jour pour supporter le Teaming et aussi le support des fonctions VMChimney et VMQ.

●

Les flux IPSec ne supportent pas les fonctions d’accélération VMChimney et VMQ.

●

Les fonctionnalités d’inspection de paquets implémentées sur une connexion particulière via le Parefeu Windows, ou bien un autre filtre d’inspection nonMicrosoft, peuvent ne pas tirer parti des fonctions d’accélération VMChimney et VMQ.

●

Lorsque les fonctions d’accélération VMChimney et VMQ sont invoquées simultanément sur la même carte réseau, Windows Server 2008 R2 utilisera VMQ.

●

Les fonctionnalités VMChimney et VMQ peuvent être indépendamment activées sur des cartes réseau différentes au sein de la même machine hôte HyperV v2.

Le point le plus important concerne le support cumulé des fonctions de Teaming et des fonctions d’accélération VMChimney et VMQ. Cependant, en fonction des situations, d’autres interactions peuvent être aussi importantes. Pour plus d’informations concernant les interactions entre les fonctions d’accélération de Windows Server 2008 R2 et les fonctionnalités additionnelles spécifiques apportées par d’autres composants réseau fournis par Microsoft ou par des fournisseurs tiers, référezvous au document Microsoft disponible à

- 3-

l’adresse spécifiée cidessous : « Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008 » http://support.microsoft.com/kb/951037/enus

3. Services WSFC de Windows Server 2008 R2 et Live Migration a. Nouveautés des services de cluster de Windows Server 2008 R2 Windows Server 2008 R2 apporte aussi des améliorations notables concernant les services WSFC (Windows Server Failover Clustering). Nous savons qu’aujourd’hui, il est de plus en plus demandé que des applications soient ou puissent être considérées comme critiques lorsque la situation l’exige. Pour y parvenir, les services de cluster incorporés à Windows Server 2008 Edition Entreprise et Datacenter ont fait l’objet d’une refonte complète. Cependant, la version R2 du produit introduit son lot de nouveautés concernant particulièrement les clusters de machines hôtes HyperV. Du point de vue fonctionnel, les services de basculement de Windows Server 2008 R2 permettent toujours de déployer très facilement des solutions à haute disponibilité pour les serveurs de messagerie, de base de données, mais nous verrons plus loin que l’administration des configurations HyperV va être grandement facilitée par cette nouvelle version R2. Les avancées apportées par R2 améliorent l’administration et la configuration des clusters en permettant à l’administrateur de créer plus facilement une configuration complexe valide. L’interface gagne en convivialité en offrant à l’administrateur un meilleur contrôle et une mise en oeuvre facilitée de la haute disponibilité des machines virtuelles. Toujours concernant l’administration, R2 inclut une interface d’administration supplémentaire via le support de Windows PowerShell et de nouveaux assistants. Ces nouveautés sont introduites cidessous : ●

Installation facilitée : Windows Server 2008 introduit un nouvel assistant de validation contenant plusieurs centaines de procédures de tests et de vérifications de conformité. Le principe est toujours conservé avec la nouvelle version R2 mais il a été étendu de manière très importante. Une nouvelle rubrique est désormais dédiée aux « bonnes pratiques ». Cette nouveauté permettra aux administrateurs et membres des équipes de support de déployer des configurations en cluster respectant les meilleures recommandations de Microsoft.

●

Support facilité : Windows Server 2008 R2 incorpore de nouveaux compteurs de performances ainsi que des journaux plus détaillés.

●

Migration des anciens clusters Windows Server 2003 facilitée : Windows Server 2008 R2 inclut un nouvel assistant de migration pour aider à la récupération de la quasitotalité des paramètres des ressources d’un ancien cluster vers un autre cluster fonctionnant sous Windows Server 2008 R2.

●

Gestion du stockage SAN pour HyperV via CSV : cette dernière fonctionnalité est certainement la grande fonctionnalité introduite par Microsoft au sein des nouveaux services de basculement WSFC de Windows Server 2008 R2 Edition Entreprise ou Datacenter. Avec ce nouveau type de ressource CSV pour Cluster Shared Volumes, le cluster permet de simplifier de manière considérable la configuration des machines virtuelles au sein des clusters de machines hôtes HyperV. Seulement supporté par HyperV, comme cela est le cas de VMFS pour la solution de VMware ESX, ce nouveau type de volume en cluster, construit audessus de NTFS, simplifie la gestion du stockage SAN, réduit les temps de basculement et améliore de manière significative la disponibilité et l’évolution du cluster HyperV ! Il suffit de quelques secondes pour retirer un stockage ou en introduire un nouveau instantanément visible par tous les nœ uds du cluster HyperV au sein du SAN ! Une fois les machines virtuelles accueillies sur un volume CSV, la fonctionnalité Live Migration est disponible, permettant le déplacement de cellesci vers une autre machine hôte HyperV sans aucune perte de service.

Pour plus d’informations sur les nouveaux services de cluster de basculement de Windows Server 2008 R2, référez vous aux documents listés cidessous :

- 4-

●

Windows Server 2008 Clustering Technical http://www.microsoft.com/windowsserver2008/en/us/clusteringresources.aspx

●

Windows Server Failover Clustering Newsgroup https://www.microsoft.com/technet/community/newsgroups/dgbrowser/enus/default.mspx? dg=microsoft.public.windows.server.clustering

●

Webcast (Windows Server 2008 R2) : Introduction to Failover Clustering http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032407190&Culture=enUS

Ressources

●

Webcast (Windows Server 2008 R2) : HA Basics with http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032407222&Culture=enUS

●

Webcast (Windows Server 2008 R2) : Cluster Shared Volumes http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032407238&Culture=enUS

HyperV

(CSV)

b. Création d’un cluster Windows Server 2008 R2 La mise en œ uvre d’un cluster Windows impose le respect des points suivants. Une fois les matériels validés, le stockage partagé doit être préparé sous la forme d’au moins deux LUN, sachant que les LUN insérés dans le cluster ne doivent plus être exposés à des machines ne faisant pas partie de celuici. La préparation des disques nécessite que ces mêmes disques utilisent le mode par défaut, c’estàdire le mode basique et pas le mode dynamique, et qu’ils soient formatés en NTFS. Les partitions peuvent, en fonction de leur taille, utiliser le format MBR (Master Boot Record), ou bien le format GPT (GUID Partition Table). Pour créer un cluster Windows Server 2008 R2, procédez de la manière suivante. : ■

Lancez la console d’administration du cluster via le menu Démarrer Outils d’administration Gestionnaire de cluster de basculement ou le Gestionnaire de serveur disponible dans la barre des tâches ou dans le groupe de programmes Outils d’administration.

Création d’un cluster à l’aide du Gestionnaire du cluster de basculement

■

Dans le volet Administration ou Action, sélectionnez l’option Créer un cluster et suivez les différentes étapes de configuration proposées par l’assistant. Au cours de cette étape, il sera nécessaire de renseigner les paramètres suivants : ●

Le nom DNS du cluster.

●

L’adresse IP statique et le masque de sousréseau du cluster.

●

Les noms DNS des membres du cluster.

- 5-

Sélection des membres d’un cluster Windows Server 2008 R2 à 8 nœuds La figure suivante illustre l’exécution des tests de validation des membres du cluster. Le succès de ces tests garantit la bonne configuration du cluster Windows.

Étape de validation du nouveau cluster

■

Une fois la configuration validée et les différents paramètres renseignés, l’assistant configure toutes les machines déclarées comme faisant partie du nouveau cluster.

L’étape de validation du cluster est une opération qui peut être invoquée avant, pendant et aussi après la création et la configuration du cluster.

- 6-

Configuration des machines Windows Server 2008 R2 membres du cluster La figure suivante illustre le choix le plus judicieux en fonction du nombre de nœ uds membres du cluster pour la configuration du quorum.

Le disque 1 est sélectionné comme disque témoin

Le disque témoin Witness Disk, utilisé pour détenir une copie de la base de données de configuration du cluster CLUDB, doit lui aussi utiliser NTFS. Par exemple, pour une configuration cluster composé d’un nombre pair de nœ uds, la configuration du quorum recommandée par l’assistant et donc à mettre en œ uvre doit être Nœud et disque majoritaires. Cette configuration permet à tous les nœ uds et au disque témoin de posséder une copie de la configuration du cluster, permettant ainsi de définir un quorum tant que la majorité est préservée,

- 7-

c’estàdire lorsque deux de ces copies sont disponibles sur les trois au total, les deux nœ uds plus le disque témoin.

■

À l’issue de la configuration, la dernière étape consiste à visualiser le rapport HTML d’installation. De cette manière, vous pourrez vous assurer que l’ensemble des nœ uds et des éléments de configuration du cluster est configuré tel que souhaité.

Affichage du rapport d’installation et de mise en route du cluster À ce stade de la configuration, nous venons de déployer un cluster Windows Server 2008 R2 composé de 8 nœ uds, configuré avec un quorum de disques et nœ uds majoritaire utilisant le disque 1 du cluster. La prochaine étape consiste à activer la gestion des volumes CSV (Cluster Shared Volumes), pour permettre à tous les nœ uds membres du cluster d’accéder simultanément au stockage partagé du SAN. De cette manière, n’importe quel nœ ud du cluster pourra prendre en charge n’importe quelles machines virtuelles dudit cluster et ce, indépendamment de la machine membre du cluster prenant en charge le stockage.

c. Mise en œuvre des volumes CSV pour HyperV v2 Les volumes CSV permettent à tous les nœ uds membres d’un cluster d’accéder en lecture et en écriture de manière simultanée. Les différents nœ uds du cluster prennent en charge la coordination des opérations de lecture et d’écriture de telle sorte qu’il n’y ait pas de corruption de données. À l’opposé des volumes CSV, les LUN d’un SAN vus comme des disques au sein du stockage du cluster sont toujours possédés par une seule et unique machine. Conceptuellement, cette méthode de Clustering utilisée depuis les toutes premières versions de Windows NT, met en œ uvre le modèle share nothing, lequel n’est pas adapté à l’usage d’HyperV. Les volumes CSV permettent à HyperV (v2) de s’appuyer sur un système de fichiers distribué parfaitement optimisé pour son usage. Incorporée au sein des services de basculement en cluster de Windows Server 2008 R2 Edition Entreprise et Datacenter, cette fonctionnalité est aussi disponible, sans aucun coût, au sein de HyperV Server 2008 R2. À la différence d’un système de fichiers cluster, les volumes CSV n’utilisent aucune structure propriétaire : les partitions sont de type MBR ou GPT, les disques sont formatés en NTFS et l’infrastructure de stockage SAN est traditionnelle via le support des SAN iSCSI et FC.

Avantages L’avantage principal des volumes CSV est que tous les nœ uds membres du cluster peuvent accéder au stockage partagé, prendre en charge n’importe laquelle des machines virtuelles publiées au sein du cluster et ce, indépendamment de la machine prenant en charge le stockage. La gestion du stockage HyperV est réduite à sa plus simple expression, de simples dossiers à l’intérieur du dossier C:\ClusterStorage. En plus de ces avantages, l’utilisation des volumes CSV permet aussi une plus grande résistance aux incidents et la possibilité d’utiliser un seul et unique LUN pour y stocker toutes les machines virtuelles. Les volumes CSV offrent aussi l’immense avantage de fournir un espace de fichiers cohérent avec tous les nœ uds membres du cluster. Le dossier C:\ClusterStorage est visible sur tous les nœ uds du cluster, permettant ainsi aux machines hôtes HyperV d’avoir des accès identiques à partir de n’importe quel nœ ud. CSV casse la dépendance existant depuis toujours entre les ressources de type application, dans notre cas les machines virtuelles, et les ressources disques puisqu’il n’est plus important de se soucier de quelle machine possède réellement le disque.

- 8-

Principe N’importe quel nœ ud du cluster peut être désigné comme « nœ ud coordinateur ». Lorsqu’une application tente d’écrire sur le disque, l’application envoie une demande de permission d’accès vers le « nœ ud coordinateur ». Si les données à écrire ne nécessitent pas de modification de la structure du fichier, le nœ ud coordinateur retourne l’adresse des blocs à écrire, permettant ainsi à la machine virtuelle d’écrire directement sur le disque, c’estàdire le LUN. Si, par contre, les données à écrire nécessitent des changements dans la structure du système de fichiers du disque, déplacement, modification des attributs, etc., alors le nœ ud coordinateur prendra la responsabilité des opérations d’écriture des données vers le disque. Relation avec Live Migration Les fonctionnalités intrinsèques des volumes CSV sont profitables aux environnements en cluster de machines hôtes HyperV. Cependant, les fonctionnalités de Live Migration n’exigent pas la mise en œ uvre des volumes CSV. Les deux technologies sont complémentaires et bien que les volumes CSV ne soient pas obligatoires pour réaliser la mise en œ uvre de Live Migration, Microsoft recommande leur utilisation. Mise en œuvre des volumes CSV avec Windows Server 2008 R2 Pour activer le support des volumes CSV et procéder à la configuration du stockage, procédez de la manière suivante : Étape d’activation des volumes CSV ■

À l’aide du Gestionnaire du cluster de basculement, choisissez le cluster Windows sur lequel vous souhaitez activer le support des volumes CSV puis sélectionnez l’option Activer les volumes partagés de cluster.

Cette option est disponible dans le menu Actions de la console de gestion du cluster. Cependant, il est aussi possible, à l’aide du bouton droit de la souris, d’utiliser le menu contextuel.

Option Activer les volumes partagés de cluster Tel que le montre la figure suivante, il faudra lire et accepter les restrictions liées au cadre d’utilisation des volumes partagés en cluster. En effet, tel que cela est précisé, la fonctionnalité CSV est prise en charge seulement dans le cadre d’une utilisation avec le rôle HyperV v2 inclus dans Windows Server 2008 R2 Editions Entreprise et Datacenter et aussi avec la version gratuite HyperV Server 2008 R2.

- 9-

Message d’avertissement concernant l’utilisation des volumes CSV

Attention ! La création, la copie et le stockage de fichiers sur des volumes CSV qui ne sont pas sous contrôle des opérations HyperV, y compris des données utilisateur ou des données d’applications stockées sous le dossier C:\ClusterStorage sur tous les nœ uds du cluster Windows, ne sont pas pris en charge et peuvent aboutir à des corruptions et pertes de données irrémédiables. Étape d’ajout du stockage SAN au sein du volume CSV Une fois le support des volumes CSV activé, un nouveau nœ ud apparaît au sein de la console Gestionnaire du cluster de basculement, permettant ainsi de rajouter les disques présentés sous la forme de LUN par le stockage SAN. Pour ajouter des disques en tant que nouveaux volumes CSV, procédez de la manière suivante : ■

Positionnezvous sur Volumes partagés de cluster.

Nœud permettant l’administration des volumes CSV au sein de la console

- 10 -

■

Via le menu Actions, sélectionnez l’option Ajouter un stockage.

■

À l’aide de la fenêtre de sélection, ajoutez le ou les disques au sein du volume CSV du cluster.

Ajout des disques en tant que volumes CSV Une fois les disques ajoutés, les différents disques apparaîtront dans le dossier C:\ClusterStorage, lequel est un dossier système que vous pourrez néanmoins renommer, si vous le jugez nécessaire. Chaque LUN inséré dans le volume CSV apparaîtra instantanément sous la forme d’un dossier nommé Volume1, Volume2, Volume3, etc. La fenêtre de sélection précédente peut être utilisée pour ajouter et aussi pour retirer les volumes CSV pris en charge par un cluster donné. De cette manière, il est facile de « sortir » un LUN d’un volume CSV pour l’insérer dans un autre volume CSV géré par un autre cluster fonctionnant sous Windows Server 2008 R2. La figure cidessous illustre l’affichage des disques mis à disposition des fonctionnalités CSV et les disques utilisés au niveau d’autres applications en cluster, dans cet exemple, l’application App1.

- 11 -

Affichage des volumes partagés en cluster via la console Gestionnaire du cluster de basculement Une fois la configuration des disques au sein du volume CSV terminée, l’administrateur peut commencer à utiliser le stockage CSV localisé virtuellement dans le répertoire local C:\ClusterStorage, et ce, quelle que soit la machine membre du cluster, comme s’il s’agissait d’un simple disque local. Grâce aux volumes CSV, l’administration des volumes est réduite au minimum et la tolérance de pannes est garantie par les possibilités de gestion à 16 nœ uds de Windows Server 2008 R2. La figure cidessous illustre l’intégration parfaite des volumes CVS de Windows Server 2008 R2 avec HyperV v2 et System Center Virtual Machine Manager 2008 R2.

Exemple d’intégration du stockage CSV via SCVMM 2008 R2

Les connexions réseau utilisées pour les trafics propres aux contrôles d’accès des volumes CSV disposent de mécanismes de tolérance de panne intégrés. Ainsi, si le réseau utilisé par les volumes CSV était soumis à une indisponibilité, le trafic serait automatiquement transmis au travers d’un autre réseau.

Le support des volumes CSV est activé uniquement une fois au niveau du cluster Windows Server 2008 R2. - 12 -

Le fait d’activer le support des volumes CSV au niveau du cluster Windows active la fonctionnalité sur tous les nœ uds membres du cluster.

Désactivation des volumes CSV sur un cluster Windows Server 2008 R2 Dans le cas où il serait nécessaire de désactiver le support des volumes CSV, vous devrez utiliser l’interface Windows PowerShell. Pour y parvenir, procédez de la manière suivante : Chargement des cmdlets PowerShell ■

Pour charger la cmdlet GetCluster, lancez l’interface de la ligne de commande Windows PowerShell via le menu Démarrer Outils d’administration Windows PowerShell Modules.

Cette opération démarre l’interface Windows PowerShell avec l’argument de la ligne de commande ImportSystemModules. Ce paramètre a pour effet de procéder au chargement de tous les modules Windows PowerShell placés dans le répertoire C:\Windows\System32\WindowsPowerShell\v1.0\Modules. ■

Une fois l’interface initialisée, entrez la ligne de commande suivante pour désactiver le support des volumes CSV :

Get-Cluster | %{$_.EnableSharedVolumes = "Disabled"}

Pour obtenir la liste de toutes les options de la commande GetCluster, entrez la commande suivante à l’invite Windows PowerShell : GetHelp GetCluster Full.

d. Mise en œuvre de Live Migration pour HyperV v2 Nous avons vu précédemment que Windows Server 2008 et Windows Server 2008 R2 Editions Entreprise et Datacenter disposent d’un processus de configuration des services de basculement en cluster extrêmement simplifié. En effet, il suffit de quelques minutes pour créer un cluster Windows Server 2008 R2, activer le support des volumes CSV et insérer les LUN proposés par le stockage SAN. Recommandation : malgré leur grande simplicité de mise en œ uvre, les services de cluster de basculement de Windows Server 2008 R2 nécessitent un minimum de planification. Une fois les éléments matériels déterminés nombre et caractéristiques des nœ uds, nombre de cartes réseau dans chaque nœ ud…, il est nécessaire de s’assurer que les matériels indispensables à la mise en œ uvre du stockage SAN partagé sont bien supportés par les services de cluster de Windows Server 2008 R2. Cette opération doit être réalisée à l’aide de l’option Valider une configuration via la console de gestion MMC Gestionnaire du cluster de basculement.

Options Valider une configuration Créer un cluster Gérer un cluster

Prérequis à la mise en œuvre de Live Migration Les prérequis nécessaires à la mise en place de la fonctionnalité de Live Migration sont résumés cidessous : ●

Installer la fonctionnalité Clustering avec basculement à l’aide du Gestionnaire de serveur de Windows Server 2008 R2.

- 13 -

●

Connecter l’ensemble des nœ uds, ou tout ou partie, sur les différents réseaux et sur le stockage partagé.

●

Configurer la fonctionnalité Clustering avec basculement sur tous les nœ uds membres du cluster.

●

Installer le rôle HyperV à l’aide du Gestionnaire de serveur de Windows Server 2008 R2.

●

Activer au sein du Cluster R2 le support des volumes disque CSV, Cluster Shared Volumes.

Pour plus d’informations sur les détails de l’installation d’un cluster Windows Server 2008 R2 avec Live Migration, vous pouvez vous référer à la section précédente, au chapitre Gestion de la haute disponibilité et aussi au document Microsoft intitulé « Step by Step instructions » disponible via le lien http://go.microsoft.com/fwlink/?LinkId=139667.

Mise en œuvre de Live Migration La mise en œ uvre de Live Migration nécessite la configuration suivante : ●

Créer ou configurer une machine virtuelle existante pour qu’elle supporte la fonction de Live Migration.

●

Configurer les réseaux du cluster Windows Server 2008 R2 pour leur usage via Live Migration.

Configuration d’une machine virtuelle pour Live Migration

Pour configurer une machine virtuelle pour la haute disponibilité avec Live Migration, il est nécessaire de créer la machine virtuelle, de la configurer pour qu’elle utilise un volume CSV, de vérifier les options de démarrage automatique et de déclarer la machine virtuelle comme hautement disponible. Les étapes listées cidessous vous permettront de réaliser ces tâches : ■

Création d’une nouvelle machine virtuelle : cette étape fait appel à l’assistant Nouvel ordinateur virtuel.

Attention ! Il est obligatoire de créer la machine virtuelle sur un stockage partagé de type SAN. Si tel n’est pas le cas, il ne sera pas possible de positionner la machine virtuelle en mode haute disponibilité. Avec Windows Server 2008 R2 et les volumes CSV, vous pouvez créer la machine virtuelle à partir de n’importe quel nœ ud. Si les volumes CSV ne sont pas utilisés, il est indispensable de créer un LUN par machine virtuelle et de posséder le disque de stockage lors de la création de l’image.

- 14 -

■

Lancez la console de gestion Gestionnaire HyperV.

■

Assurezvous que vous avez accès au stockage SAN et au volume CSV désiré.

■

À partir du menu Actions, faites Nouvelle Machine virtuelle.

■

À partir de l’assistant Nouvelle machine virtuelle, cliquez sur Suivant.

■

Sur la page Spécifiez le nom et l’emplacement, spécifiez le nom de la machine virtuelle, sélectionnez l’option Stocker la machine virtuelle à un emplacement différent puis sélectionnez l’emplacement désiré au sein du stockage partagé, c’estàdire le volume CSV.

■

Sur la page Mémoire, spécifiez la taille de mémoire dynamique à allouer à la machine virtuelle.

■

Sur la page Réseau, spécifiez la carte réseau virtuelle qui doit être connectée sur le réseau virtuel associé à la carte réseau physique du serveur.

■

Sur la page Disques virtuels, sélectionnez l’option Créer un disque dur virtuel. Si vous souhaitez renommer le disque, tapez un nouveau nom pour celuici puis cliquez sur Suivant.

■

Sur la page Options d’installation, cliquez sur Installer un système d’exploitation à partir d’un CD/DVDROM de démarrage.

Important : la mise en haute disponibilité ne peut être activée que lorsque la machine virtuelle est dans l’état Arrêtée. À ce stade, il n’est donc pas judicieux de démarrer la machine virtuelle.

■

Activez l’option haute disponibilité via VMM 2008 R2 en configurant les propriétés de la machine virtuelle : Configurer le matériel Avancé Disponibilité : Haute.

Activation de l’option de haute disponibilité pour une machine virtuelle

Configuration des réseaux du cluster pour Live Migration

Les réseaux du cluster sont automatiquement configurés pour être utilisés pour les trafics Live Migration. Cependant, vous pouvez spécifier vos propres paramètres. Cette étape de configuration est réalisée à l’aide du Gestionnaire de cluster de basculement, tel que précisé cidessous. ■

À l’aide du Gestionnaire du cluster de basculement, sélectionnez le cluster Windows à administrer et accédez aux nœ uds du cluster.

■

Via l’arbre de la console, sélectionnez la machine virtuelle mise en cluster HyperV pour laquelle vous souhaitez configurer le réseau Live Migration.

- 15 -

Accès aux propriétés de configuration de la machine virtuelle

■

Accédez aux propriétés de l’objet Configuration de la machine virtuelle via la partie centrale de l’interface.

■

Accédez aux propriétés réseau pour Live Migration en sélectionnant l’onglet Réseau pour la migration dynamique puis sélectionnez et ordonnez, tel que vous le souhaitez, les différentes interfaces.

Lorsque plusieurs réseaux sont sélectionnés, l’ordre de préférence utilisé pour la sélection du réseau pour les opérations de Live Migration prend en compte en premier lieu les réseaux ne possédant aucune passerelle par défaut, puis les réseaux utilisés pour les volumes CSV, puis les réseaux utilisés pour le trafic du Custer. Live Migration utilisera l’ordre spécifié en se basant sur la liste des réseaux du cluster. Si la connexion vers le nœ ud de destination à l’aide du premier réseau ne peut aboutir, alors Live migration tentera d’utiliser le prochain réseau dans la liste.

- 16 -

Sélection du ou des réseaux à utiliser pour Live Migration Une fois les propriétés précédentes correctement définies, la dernière étape consiste à activer l’option Rendre cette machine hautement disponible puis à tester la migration d’une machine virtuelle via Live Migration.

e. Déplacement de machines virtuelles via Live Migration La fonctionnalité de Live Migration a été conçue pour que les administrateurs aient la possibilité de déplacer une machine virtuelle d’une machine hôte source vers une autre machine hôte de destination, aussi vite que possible. Cette opération peut être invoquée par un administrateur VMM à l’aide des outils suivants : ●

Via la console de gestion MMC Gestionnaire du cluster de basculement.

●

Via Windows PowerShell ou l’interface WMI.

●

Via la console de gestion de SC Virtual Machine Manager 2008 R2.

Gestion de n opérations de Live Migration En fonction du nombre de nœ uds membres du cluster Windows, il est possible au sein du cluster R2 de déplacer plus d’une seule machine virtuelle en même temps avec Live Migration. En fait, un nœ ud du cluster ne peut participer à une opération de Live Migration qu’une seule fois, en tant que source ou que destination. Par conséquent, un cluster à 2 nœ uds ne supporte qu’une seule opération de Live Migration simultanée tandis que, par exemple, un cluster à 4 nœ uds supportera 2 opérations de Live Migration, etc. En cas d’échec, l’opération de Live Migration est abandonnée et la machine virtuelle continue de fonctionner normalement, sans être déplacée.

Déclenchement d’une opération de Live Migration via la console de gestion du cluster Pour réaliser le déplacement d’une machine virtuelle à l’aide de la console de gestion du cluster, procédez de la

- 17 -

manière suivante : ■

À l’aide du Gestionnaire du cluster de basculement, sélectionnez le cluster Windows à administrer et accédez aux nœ uds du cluster.

■

Via l’arbre de la console, sélectionnez la machine virtuelle configurée en haute disponibilité pour laquelle vous souhaitez initier un déplacement via Live Migration.

■

Accédez aux propriétés de la machine virtuelle. Sélectionnez l’option Migrer dynamiquement cet ordinateur vers un autre nœud.

■

Sélectionnez le nœ ud vers lequel vous souhaitez déplacer la machine virtuelle.

Une fois la migration terminée, la machine virtuelle est opérationnelle sur l’autre nœ ud, sans aucune interruption de service. ■

Pour vérifier que la machine virtuelle est bien positionnée sur le nœ ud sélectionné précédemment, assurezvous que le nom du propriétaire reflète bien le nom du nœ ud HyperV.

Déclenchement d’une opération de Live Migration via PowerShell Pour réaliser le déplacement d’une machine virtuelle à l’aide de la console de la ligne de commande Windows PowerShell, procédez de la manière suivante : ■

Chargement des cmdlets PowerShell : pour charger la cmdlet GetCluster, lancez l’interface de la ligne de commande Windows PowerShell via le menu Démarrer Outils d’administration Windows PowerShell Modules.

Une fois l’interface initialisée, entrez la ligne de commande suivante :

Get-Cluster “<Cluster Name>” | Move-ClusterVirtualMachineRole -Name “<VM group name>” -Node “<Destination node name>” Dans laquelle : ●

<Cluster Name> est le nom du cluster où la machine virtuelle réside.

●

<VM group name> est le groupe de ressources contenant la machine virtuelle.

●

<Destination node name> est le nom du nœ ud de destination vers lequel la machine virtuelle doit être déplacée.

Pour obtenir la liste de toutes les options de la commande Get-Cluster, entrez la commande suivante à l’invite Windows PowerShell : Get-Help Get-Cluster -Full.

Déclenchement d’une opération de Live Migration via SCVMM 2008 R2 Pour réaliser le déplacement d’une machine virtuelle à l’aide de la console de gestion de SCVMM 2008 R2, procédez de la manière suivante :

- 18 -

■

À l’aide de la console d’administration SCVMM 2008 R2, sélectionnez le cluster Windows à administrer et accédez aux nœ uds du cluster.

■

Via l’arbre de la console, sélectionnez la machine virtuelle configurée en haute disponibilité pour laquelle vous souhaitez initier un déplacement via Live Migration.

■

À l’aide de la souris, accédez au menu contextuel puis sélectionnez l’option Migrer.

■

À l’étape Sélectionner l’ordinateur hôte, appuyezvous sur l’évaluation proposée par SCVMM, sélectionnez le nœ ud le mieux adapté à la situation puis validez à l’aide du bouton Suivant.

- 19 -

Sélection de la machine hôte HyperV au sein du cluster à 8 nœuds La figure cidessous illustre le déplacement de la machine virtuelle. Un travail a été créé, de telle sorte que l’ensemble des opérations de déplacement peut être suivi par l’administrateur ou un opérateur SCVMM.

Affichage du travail « Live Migration » : PROD01 est déplacé de HVR202 vers HVR205

À propos du temps nécessaire pour migrer en machine virtuelle avec Live Migration : la vitesse du processus de migration complet est en partie dépendante des matériels utilisés, de la performance réseau disponible

- 20 -

au moment de l’opération et de la charge de la machine virtuelle à migrer.

f. Processus de déplacement Live Migration Une fois l’opération de migration d’une machine virtuelle déclenchée, les opérations cidessous se réalisent : Étape 1 : configuration de l’opération de Live Migration La machine hôte HyperV source crée une connexion TCP avec la machine hôte de destination. À l’aide de cette connexion, les données de configuration de la machine virtuelle sont transmises vers la machine hôte de destination. Un « squelette » de la machine virtuelle est créé sur la machine hôte HyperV de destination et la mémoire RAM nécessaire à la machine virtuelle est allouée. Étape 2 : transfert des pages mémoire La mémoire de la machine virtuelle est transmise au travers du réseau vers la machine hôte de destination. Cette opération transfère l’intégralité de la machine virtuelle, c’estàdire son jeu de travail complet, aussi appelé memory working set, sous la forme de pages mémoire de 4 Ko. Au cours de cette opération de copie des pages mémoire, la machine HyperV source surveille l’évolution des pages mémoire de la machine virtuelle en activité. À l’issue du début du transfert des pages, toutes les pages modifiées sont marquées. HyperV réitère le processus de synchronisation de la mémoire n fois, permettant ainsi à chaque passage une recopie d’un nombre plus faible de pages modifiées vers la machine hôte de destination. Une fois le working set de la machine virtuelle synchronisé sur les deux machines hôtes, l’étape suivante peut commencer. Étape 3 : transfert des registres processeurs La mémoire de la machine virtuelle étant exactement identique entre les deux machines hôtes HyperV, la machine hôte source transfère vers la machine hôte de destination le contenu des registres processeurs. Vitesse du réseau de transfert utilisé par Live Migration : durant cette étape, la bande passante du réseau est déterminante pour réduire le temps nécessaire à la conclusion du processus de Live Migration. Bien que ce ne soit pas obligatoire pour réaliser des tests, il est recommandé que les environnements de production disposent d’une interface Ethernet à 1 Gbit/s dédiée aux trafics Live Migration. Cette interface sera utilisée en fonction de l’activité de la machine virtuelle pendant le processus de synchronisation de la mémoire. Jusqu’à cette étape, l’administrateur peut annuler l’opération de Live Migration. L’opération d’annulation supprime les éléments créés sur la machine hôte HyperV de destination puis nettoie et libère la mémoire qui avait été allouée. Étape 4 : déplacement du pointeur de stockage de la machine hôte source vers la machine hôte de destination Au cours de cette étape, HyperV sollicite les services de cluster de Windows Server 2008 R2 pour transmettre le contrôle du stockage fichiers VHD et disques durs configurés en mode passthrough, à la machine hôte de destination. Étape 5 : mise en ligne de la machine virtuelle migrée À ce stade des opérations, la machine hôte de destination possède une copie de la mémoire et des registres processeurs complètement synchronisés ainsi que le contrôle des accès fichiers sur le stockage partagé disponible sur le SAN. La machine virtuelle est alors mise en ligne sur la machine hôte de destination et « détruite » sur la machine hôte source. Étape 6 : nettoyage des caches réseau La machine virtuelle en cours de fonctionnement sur la machine hôte de destination doit maintenant faire l’objet de la mise en œ uvre de ses interfaces. Cette opération est réalisée via l’envoi d’un message réseau vers le switch physique. Dans le cas où la machine virtuelle est équipée de plusieurs interfaces réseau, l’adresse MAC de chaque interface sera réenregistrée. De cette manière, les trafics réseau seront rétablis. Le processus de transition proprement dit est réalisé en moins de temps que le timeout d’une connexion TCP de telle sorte qu’aucune connexion n’est rompue. À propos du temps de transition via Live Migration : le temps de déplacement réel dépend surtout du nombre de pages mémoire modifiées durant la période de déplacement de la machine virtuelle. Plus le nombre de pages modifiées est important et plus le temps de migration sera lui aussi important. Pour limiter ces impacts, il faudra agir sur l’ensemble des éléments impliqués dans les opérations à réaliser entre les deux machines hôtes HyperV, c’est àdire la bande passante réseau disponible, la bande passante disponible sur le SAN via iSCSI ou FC, et la charge des deux machines hôtes HyperV. Live Migration, cluster HyperV et volumes CSV : les volumes CSV ne sont pas obligatoires pour activer et utiliser Live Migration, cependant, ils sont fortement recommandés ! Si les volumes CSV ne sont pas activés, configurés et utilisés, la règle consistant à déployer une machine virtuelle uniquement par LUN devra être rétablie ! Notez aussi que SCVMM 2008 R2 nécessite l’utilisation des volumes CSV pour assurer la prise en charge de Live Migration.

- 21 -

Le temps de bascule final d’une machine virtuelle ne prend que 10 millisecondes. Cependant, la phase de transfert des pages mémoire entre la machine hôte source et la machine hôte de destination est limitée à 10 passages. Au delà de cette valeur, le processus Live Migration n’aura pas lieu et une migration via Quick Migration sera alors automatiquement tentée. La capacité à utiliser Quick Migration en dernier recours après live Migration permet de garantir que le processus de migration sera normalement terminé avec succès. Tous les systèmes d’exploitation invités supportent les fonctionnalités de Live Migration et de Quick Migration de Windows Server 2008 R2 Edition Entreprise et Datacenter.

4. Mode de compatibilité des processeurs pour Live Migration a. Concept et cadre d’utilisation HyperV v2 implémente une nouvelle fonctionnalité appelée Compatibilité du processeur pour la migration à chaud. Cette nouvelle possibilité permet à l’administrateur de réaliser le déplacement à chaud d’une machine virtuelle, Live Migration, vers une machine hôte HyperV ne disposant pas d’un processeur rigoureusement identique. Cette nouvelle option permet de masquer certaines instructions disponibles sur un processeur afin de rendre compatibles entre eux des processeurs différents mais ayant malgré tout d’importantes similitudes. HyperV utilise directement les fonctionnalités embarquées dans les processeurs Intel et AMD, respectivement Flex Migration pour Intel et Extended Migration pour AMD. Lorsqu’une machine virtuelle est démarrée sur une machine hôte HyperV, l’hyperviseur expose un ensemble de fonctionnalités vers la machine virtuelle. Cet ensemble de fonctionnalités processeur, appelé Guest Visible Processor Features, est ensuite disponible au sein de la machine virtuelle, jusqu’à ce que celleci soit redémarrée. Lorsque la machine virtuelle est démarrée avec le mode de compatibilité processeur activé, HyperV opère une opération de normalisation consistant à exposer seulement les fonctionnalités communes à tous les processeurs des machines hôtes HyperV. Cette réduction fonctionnelle permet à la machine virtuelle d’être migrée vers une autre machine hôte disposant de processeurs du même fournisseur, mais pas rigoureusement identiques. Techniquement, cette opération de masquage est réalisée en interceptant l’instruction CPUID émise par la machine virtuelle et en effaçant le ou les bits correspondant aux fonctionnalités à masquer. Attention : l’option Compatibilité du processeur ne permet pas de réaliser une opération de Live Migration entre des machines hôtes disposant de processeurs Intel et des machines hôtes disposant de processeurs AMD. Cependant, en plus des fonctionnalités disponibles au sein des processeurs les plus récents permettant de prendre en charge les disparités des processeurs Intel Flex Migration et AMD Extended Migration, la fonctionnalité Compatibilité du processeur permet une gestion plus large en supportant les processeurs non compatibles Intel Flex Migration ou AMD Extended Migration. De plus, l’option Compatibilité du processeur peut être configurée indépendamment de chaque machine virtuelle et ne nécessite aucun changement au niveau du BIOS.

b. Fonctionnalités mises en sommeil et possibilités offertes Nous venons de voir plus haut que la fonctionnalité de Compatibilité du processeur permettait d’améliorer le support des configurations en cluster lorsque plusieurs nœ uds HyperV utilisent des versions différentes de processeurs. La figure cidessous illustre l’option Autoriser la migration vers un ordinateur hôte d’ordinateur virtuel et aussi, plus accessoirement, l’option Exécuter un ancien système d’exploitation, tel que Windows NT permettant le bon fonctionnement d’anciens systèmes d’exploitation en tant que machines virtuelles invitées.

- 22 -

Support de Live Migration avec des processeurs non identiques Les points les plus importants concernant les fonctionnalités mises en sommeil au sein des processeurs virtuels exposés aux machines virtuelles et les possibilités offertes aux administrateurs sont présentés cidessous : ●

Bien que le cadre d’usage de cette fonctionnalité soit principalement destiné au déplacement des machines virtuelles via Live Migration, elle profite aussi à la méthode Quick Migration ainsi qu’aux captures instantanées.

●

La compatibilité des processeurs est assurée au sein de la gamme des processeurs d’un constructeur donnée et pas entre les constructeurs que sont Intel et AMD. Il n’est donc pas possible de déplacer une machine virtuelle entre deux machines hôtes HyperV utilisant des processeurs issus de constructeurs différents.

●

L’activation du mode compatibilité des processeurs peut amener une machine virtuelle à ne plus disposer des fonctionnalités suivantes :

●

Pour les processeurs Intel : SSE4.1, SSE4.2, POPCNT, XSAVE et AVX.

●

Pour les processeurs AMD : SSSE3, SSE4.1, SSE4.A, SSE5, POPCNT, LZCNT, AMD 3DNow! et Extended AMD 3DNow!

Le support de la fonctionnalité de compatibilité des processeurs ne nécessite pas de prérequis liés au matériel ni au BIOS de la machine. De plus, le processeur ne doit pas supporter les technologies Intel Flex Migration ni AMD Extended Migration.

Pour plus de renseignements concernant les fonctionnalités Intel Flex Migration et AMD Extend Migration, vous pouvez vous référer aux documents listés cidessous : Intel Processor Identification and the CPUID Instruction : http://developer.intel.com/design/processor/applnots/241618.htm et Live Migration with AMDV Extended Migration Technology : http://developer.amd.com/Assets/43781 3.00PUB_LiveVirtualMachine MigrationonAMDprocessors.pdf L’activation de la fonctionnalité de compatibilité des processeurs est réalisable de manière indépendante au niveau de chaque machine virtuelle HyperV. Il est possible de modifier ce paramètre à l’aide de trois méthodes : ●

à l’aide de la console de gestion MMC Gestionnaire HyperV,

●

à l’aide de la console d’administration SCVMM 2008 R2,

●

à l’aide de la console Windows PowerShell Virtual Machine Manager.

c. Activation du mode de compatibilité des processeurs via HyperV La fonctionnalité de compatibilité des processeurs à l’aide de la console Gestionnaire HyperV est disponible au niveau des paramètres d’une machine virtuelle via la rubrique Matériel Processeur. La figure cidessous illustre ces propriétés ainsi que la case à cocher Migrer vers un ordinateur physique ayant une autre version de processeur.

- 23 -

Compatibilité des processeurs au sein de la console Gestionnaire Hyper V pour permettre la migration à chaud des machines virtuelles vers des machines hôtes disposant de CPU différentes

À propos de VMware : les versions antérieures à VMware ESX 3.5 Update 2 étaient elles aussi soumises au respect du type de processeurs entre les différentes machines hôtes ESX pour permettre les opérations de déplacement à chaud via VMotion. Comme cela est le cas aujourd’hui avec HyperV v2, VMware introduit une fonctionnalité appelée Enhanced VMotion Compatibility. Cette fonctionnalité améliore la compatibilité entre processeurs lors de la migration des machines virtuelles via VMotion mais ne permet pas de changer de famille de processeur. Enhanced Vmotion Compatibility offre donc un niveau de compatibilité au sein de la famille Intel et au sein de la famille AMD, mais ne permet pas de les mélanger.

d. Activation du mode de compatibilité des processeurs via SCVMM 2008 R2 L’activation de la fonctionnalité de compatibilité des processeurs à l’aide de la console d’administration de SCVMM 2008 R2 est très intuitive. Après avoir chargé la console d’administration SCVMM, positionnezvous sur la vue Ordinateurs virtuels, choisissez la machine virtuelle à modifier puis via le menu contextuel Propriétés Configuration matérielle Processeur, cochez l’option Autoriser la migration vers un ordinateur hôte d’ordinateur virtuel.

- 24 -

Activation de l’amélioration de compatibilité des processeurs à l’aide de la console d’administration de SCVMM 2008 R2

e. Activation du mode de compatibilité des processeurs via PowerShell Pour réaliser cette modification sur de multiples machines virtuelles, l’administrateur VMM pourra décider de mettre au point un script PowerShell utilisant l’une ou l’autre des commandes PowerShell accompagnant SCVMM 2008 R2. L’administrateur VMM peut invoquer la ligne de commande Windows PowerShell Virtual Machine Manager via le menu Démarrer Tous les programmes Microsoft System Center Virtual Machine Manager 2008 R2, en cliquant sur Windows PowerShell Virtual Machine Manager. L’activation du mode de compatibilité des processeurs via PowerShell est gérée en manipulant le paramètre LimitCPUForMigration avec la valeur 0 ou la valeur 1. Ce paramètre peut être utilisé avec les différentes commandes PowerShell listées cidessous de telle sorte qu’il sera facile de gérer l’activation ou la désactivation du mode de compatibilité du processeur. Comme cela a été expliqué précédemment, l’objectif est de limiter les fonctionnalités processeurs que la machine virtuelle utilisera pour permettre le déplacement vers une machine hôte équipée de versions différentes de processeurs. Comme cela est le cas avec les autres méthodes, il n’est pas possible de déplacer des machines virtuelles vers des machines hôtes dont les processeurs proviennent de fournisseurs différents.

Commandes PowerShell supportant le paramètre LimitCPUForMigration NewVM : cette commande permet de créer une machine virtuelle au sein de l’environnement de gestion SCVMM

- 25 -

2008 R2. Cette commande peut, par exemple, être utilisée pour créer une machine virtuelle à partir d’un modèle, à partir d’un disque dur virtuel contenant un système d’exploitation Windows ou nonWindows, à partir d’une machine déjà existante déployée sur une machine hôte HyperV ou bien encore à partir d’une machine virtuelle stockée dans une bibliothèque VMM. Les différentes déclinaisons de cette commande sont listées cidessous : Création d’une nouvelle machine virtuelle sur une machine hôte HyperV New-VM [-Name] <String> -Path <String> -VM [<String VM>] -VMHost [<String Host>] [-CPUCount <Int32>] [-CPUType <ProcessorType>] [-DelayStart <Int32>] [-Description <String>] [-HardwareProfile <HardwareProfile>] [-JobGroup <Guid>] [-JobVariable <String>] [-LimitCPUForMigration <Boolean>] [-LimitCPUFunctionality <Boolean>] [-MemoryMB <Int32>] [-OperatingSystem <OperatingSystem>] [-Owner <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsSystem] [-RunAsUserCredential <PSCredential>] [-RunAsynchronously] [-StartAction <String>] [-StartVM] [-StopAction <String>] [-UseHardwareAssistedVirtualization <Boolean>] [-UseLocalVirtualHardDisks] [<CommonParameters>] Création d’une nouvelle machine virtuelle au sein d’une bibliothèque SCVMM 2008 R2 à partir d’un disque virtuel existant : New-VM [-Name] <String> -LibraryServer [<String LibraryServer>] -SharePath <String> -VirtualHardDisk <VirtualHardDisk> [-CPUCount <Int32>] [-CPUType <ProcessorType>] [-DelayStart <Int32>] [-Description <String>] [HardwareProfile <HardwareProfile>] [-JobGroup <Guid>] [-JobVariable <String>] [-LimitCPUForMigration <Boolean>] [-LimitCPUFunctionality <Boolean>] [-MemoryMB <Int32>] [-OperatingSystem <OperatingSystem>] [Owner <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsSystem] [-RunAsUserCredential <PSCredential>] [-RunAsynchronously] [-StartAction <String>] [-StopAction <String>[-UseHardwareAssistedVirtualization <Boolean>] [-UseLocalVirtualHardDisks] [<CommonParameters>] Création d’une nouvelle machine virtuelle au sein d’une bibliothèque SCVMM 2008 R2 à partir d’une machine virtuelle existante : New-VM [-Name] <String> -LibraryServer [<String LibraryServer>] -SharePath <String> -VM <String VM>] [-CPUCount <Int32>] [-CPUType <ProcessorType>] [-DelayStart <Int32>] [-Description <String>] [-HardwareProfile <HardwareProfile>] [-JobGroup <Guid>] [-JobVariable <String>] [LimitCPUForMigration <Boolean>] [-LimitCPUFunctionality <Boolean>] [MemoryMB <Int32>] [-OperatingSystem <OperatingSystem>] [-Owner <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsSystem] [-RunAsUserCredential <PSCredential>] [-RunAsynchronously] [-StartAction <String>] [-StopAction <String>] [-UseHardwareAssistedVirtualization <Boolean>] [-UseLocalVirtualHardDisks] [<CommonParameters>] Création d’une nouvelle machine virtuelle sur une machine hôte HyperV à partir d’un modèle : New-VM [-Name] <String> -Path <String> -Template [<Template String>] -VMHost [<String Host>] [-AdminPasswordCredential <PSCredential>] [AnswerFile <Script>] [-ComputerName <String>] [-CPUCount <Int32>] [CPUType <ProcessorType>] [-DelayStart <Int32>] [-Description <String>] [-FullName <String>] [-GuestOSProfile [<GuestOSProfile String>]] [GuiRunOnceCommands <String[]>] [-HardwareProfile <HardwareProfile>] [JobGroup <Guid>] [-JobVariable <String>] [-JoinDomain <String>] [JoinDomainCredential <PSCredential>] [-JoinWorkgroup <String>] [-LimitCPUForMigration <Boolean>] [-LimitCPUFunctionality <Boolean>] [-MemoryMB <Int32>] [-MergeAnswerFile <Boolean>] [-OperatingSystem <OperatingSystem>] [-OrgName <String>] [-Owner <String>] [-ProductKey <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsSystem] [-RunAsUserCredential <PSCredential>] [-RunAsynchronously] [-SelfServiceRole <User Role>] [-StartAction <String>] [-StartVM] [StopAction <String>] [-TimeZone <Int32>] [-UseHardwareAssistedVirtualization <Boolean>] [-UseLocalVirtualHardDisks] [<CommonParameters>] Création d’une nouvelle machine virtuelle sur une machine hôte HyperV à partir d’un disque dur virtuel existant : New-VM [-Name] <String> -Path <String> -VirtualHardDisk <VirtualHardDisk>

- 26 -

-VMHost [<String Host>] [-CPUCount <Int32>] [-CPUType <ProcessorType>] [DelayStart <Int32>] [-Description <String>] [-HardwareProfile <HardwareProfile>] [-JobGroup <Guid>] [-JobVariable <String>] [LimitCPUForMigration <Boolean>] [-LimitCPUFunctionality <Boolean>] [MemoryMB <Int32>] [-OperatingSystem <OperatingSystem>] [-Owner <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsSystem] [RunAsUserCredential <PSCredential>] [-RunAsynchronously] [-StartAction <String>] [-StartVM] [-StopAction <String>] [UseHardwareAssistedVirtualization <Boolean>] [-UseLocalVirtualHardDisks] [<CommonParameters>] Au lieu d’utiliser la commande NewVM, il est aussi possible d’utiliser les commandes PowerShell suivantes : NewP2V : cette commande crée une nouvelle machine virtuelle à partir d’une machine physique déjà existante à l’aide du processus de conversion P2V. NewV2V : cette commande crée une nouvelle machine virtuelle à partir d’une machine virtuelle déjà existante fonctionnant sur un serveur VMware ESX à l’aide du processus de conversion V2V. NewHardwareProfile : cette commande permet de créer un profil matériel au sein de l’environnement de gestion SCVMM 2008 R2. Un profil matériel contient des informations de configurations matérielles. Cette commande permet la création de profils matériels mais aussi la modification de modèles ou de machines virtuelles pour y incorporer les paramètres issus d’un profil matériel. La commande NewHardwareProfile prend en charge l’opération de création au sein de la bibliothèque VMM. Un profil matériel peut être créé sur la base des paramètres par défaut mais peut aussi être basé sur un profil matériel existant. Création d’un nouveau profil matériel au sein de l’environnement de gestion SCVMM 2008 R2 : New-HardwareProfile [-Name] <String> [-BootOrder <BootDevice[]>] [CPUCount <Int32>] [-CPUMax <Int32>] [-CPUReserve <Int32>] [-CPUType <ProcessorType>] [-Description <String>] [-DiskIO <Int32>] [ExpectedCPUUtilization <Int32>] [-HardwareProfile <HardwareProfile>] [HighlyAvailable <Boolean>] [-JobGroup <Guid>] [-JobVariable <String>] [LimitCPUForMigration <Boolean>] [-LimitCPUFunctionality <Boolean>] [MemoryMB <Int32>] [-NetworkUtilization <Int32>] [-NumLock] [-Owner <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsynchronously] [-VMMServer [<String ServerConnection>]] [<CommonParameters>] SetHardwareProfile : cette commande permet de modifier les propriétés d’un profil matériel utilisé au sein de l’environnement de gestion SCVMM 2008 R2. À l’aide de cette commande, l’administrateur SCVMM a la possibilité de modifier une ou plusieurs propriétés. Parmi les propriétés les plus intéressantes, on retrouvera les paramètres de démarrage, les paramètres des processeurs, la taille de la mémoire RAM affectée à la machine virtuelle et de nombreuses autres options. Création d’un nouveau profil matériel au sein de l’environnement de gestion SCVMM 2008 R2 : Set-HardwareProfile [-HardwareProfile] <HardwareProfile> [-BootOrder <BootDevice[]>] [-CPUCount <Int32>] [-CPUMax <Int32>] [-CPUReserve <Int32>] [-CPUType <ProcessorType>] [-Description <String>] [-DiskIO <Int32>] [ExpectedCPUUtilization <Int32>] [-HighlyAvailable <Boolean>] [-JobGroup <Guid>] [-JobVariable <String>] [-LimitCPUForMigration <Boolean>] [LimitCPUFunctionality <Boolean>] [-MemoryMB <Int32>] [-Name <String>] [NetworkUtilization <Int32>] [-NumLock] [-Owner <String>] [-PROTipID <Guid>] [-RelativeWeight <Int32>] [-RunAsynchronously] [<CommonParameters>]

Pour plus de renseignements sur l’intégralité des nouvelles commandes Windows PowerShell de System Center VMM 2008 R2, vous pouvez vous référer aux liens suivants : SCVMM 2008 Scripting Guide : http://technet.microsoft.com/enus/library/cc764259.aspx et télécharger le document « System Center Virtual Machine Manager 2008 R2 RC Cmdlet Reference » à partir du site de téléchargement Microsoft.

- 27 -

Évolution des fonctions d’administration apportées par R2 1. Administration à distance via le Gestionnaire de serveur Le Gestionnaire de serveur de Windows Server 2008 R2 a fait l’objet d’une évolution remarquable puisqu’il est désormais possible d’utiliser cet outil pour un certain nombre de tâches d’administration à distance.

Utilisation du Gestionnaire de serveur pour l’administration à distance Les points cidessous vous permettront de découvrir les possibilités et aussi les limites du Gestionnaire de serveur dans ce contexte d’utilisation : ●

Il est indispensable d’être membre du groupe Administrateurs de la machine administrée à distance.

●

Les fonctionnalités d’administration distante du nouveau Gestionnaire de serveur nécessitent Windows PowerShell.

a. Tâches d’administration supportées en administration à distance ●

Accès aux statuts des mises à jour automatiques.

●

Exécution des BPA (Best Practices Analyzer).

●

Accès et modification des options Windows CEIP (Windows Customer Experience Improvement Program).

●

Accès aux informations d’erreurs via Windows Error Reporting.

●

Accès et modification des options du Parefeu Windows.

●

Accès et administration des rôles à partir de la page d’accueil du Gestionnaire de serveur.

L’administration à distance des rôles installés sur un serveur nécessite au préalable l’installation des outils adéquats installation de RSAT (Remote Server Administration Tools), sur la machine d’administration.

●

Accès et modification des options de sécurité avancée d’Internet Explorer.

●

Gestion des services Windows.

b. Tâches d’administration non supportées en administration à distance ●

Ajout, suppression des rôles, des services de rôles et des fonctionnalités.

- 1-

●

Configuration des paramètres du Bureau à distance.

●

Configuration des propriétés Système.

●

Vérification des nouveaux rôles.

●

Changement des paramètres de mises à jour automatiques via Windows Update.

●

Changement des paramètres réseau.

●

Changements des paramètres de sécurité avancée d’Internet Explorer.

●

Changement du nom de l’ordinateur et des paramètres de domaine Active Directory.

●

Exécution de l’Assistant Configuration de la sécurité.

Pour limiter les risques de failles de sécurité, ces tâches ont été expressément interdites dans les fonctions d’administration à distance du Gestionnaire de serveur.

c. Activation et désactivation des fonctions d’administration à distance de Windows Server 2008 R2 Pour garantir une sécurité maximum des serveurs à l’issue de leur installation, les fonctions d’administration à distance via le Gestionnaire de serveur sont, par défaut, désactivées. L’administrateur de la machine pourra localement activer l’administration à distance à l’aide du Gestionnaire de serveur en utilisation l’une des trois méthodes présentées cidessous. Activation de l’administration à distance à l’aide du Gestionnaire de serveur via Windows Pour activer l’administration à distance à l’aide du Gestionnaire de serveur à partir de l’interface Windows, procédez de la façon suivante : ■

Ouvrez le Gestionnaire de serveur.

■

Sur la première page, dans la rubrique Résumé serveur Informations sur l’ordinateur, cliquez sur l’option Configurer la gestion à distance du Gestionnaire de serveur.

Option de Configuration de la gestion à distance à l’aide du Gestionnaire de serveur

■

- 2-

Pour autoriser l’administration à distance, activez la case à cocher Enable remote management of this server

from other computers.

Activation de la gestion à distance à l’aide du Gestionnaire de serveur Administration à distance à l’aide du Gestionnaire de serveur via GPO Dans le cas où les fonctions d’administration à distance à l’aide du Gestionnaire de serveur de Windows Server 2008 R2 devraient être activées sur de nombreux serveurs, vous pourriez forcer la mise en place de ce paramètre en créant un objet stratégie de groupe. ■

À l’aide de la console de gestion des objets stratégies de groupe, créez un objet stratégie de groupe contenant les paramètres suivants : Configuration ordinateur Modèles d’administration Composants Windows Gestion à distance de Windows (WinRM) Service Gestion à distance de Windows, puis configurez le paramètre Autoriser la configuration automatique des écouteurs avec la valeur Activé.

■

Au final, assurezvous que le parefeu est correctement configuré pour supporter les fonctions d’administration à distance (voir ciaprès).

d. Administration à distance via le Gestionnaire de serveur et ports TCP/IP Pour vous assurer du bon fonctionnement des fonctions d’administration à distance, vous devrez vérifier que le Parefeu Windows dispose bien des définitions correctes de ports autorisés. La liste des ports automatiquement autorisés lorsque l’administration à distance a été activée pour le Gestionnaire de serveur est listée cidessous : ●

Remote Service Management (NPIn)

●

Remote Service Management (RPC)

●

Remote Service Management (RPCEPMAP)

●

Remote Event Log Management (NPIn)

●

Remote Event Log Management (RPC)

●

Remote Event Log Management (RPCEPMAP)

●

Windows Firewall Remote Management (RPC)

●

Windows Firewall Remote Management (RPCEPMAP)

Performances de l’administration à distance avec le Gestionnaire de serveur de Windows Server R2 : Lorsque les exceptions du parefeu relatives à l’administration des journaux d’évènements à distance ne sont pas activées, la connexion à distance peut s’avérer très longue en fonction du nombre de rôles et de fonctionnalités installées sur la machine distante. Pour cette raison, Microsoft recommande de ne pas désactiver les règles du parefeu autorisant l’administration des journaux d’évènements à distance.

- 3-

e. Activation de l’administration à distance à l’aide du Gestionnaire de serveur via Windows PowerShell L’activation de l’administration à distance via le Gestionnaire de serveur de Windows Server 2008 R2 peut aussi être réalisée à l’aide d’une commande Windows PowerShell. Sur la machine que vous souhaitez administrer à distance, ouvrez une session Windows PowerShell, puis tapez la commande suivante : Set-executionPolicy -executionPolicy remotesigned Configure-SMRemoting.ps1 -force -enable La première commande permet de configurer l’environnement d’exécution de Windows PowerShell pour pouvoir exécuter le script PowerShell. La deuxième commande lance l’exécution du script ConfigureSMRemoting.ps1 situé dans le dossier C:\Windows\System32, lequel active toutes les exceptions nécessaires au sein du parefeu de Windows Server.

f. Activation de l’administration à distance pour une installation minimale L’activation de l’administration à distance pour une installation minimale de Windows Server 2008 R2 nécessite l’installation de Windows PowerShell. Pour y parvenir, procédez de la manière suivante : ■

Ouvrez une session avec un compte d’utilisateur membre du groupe Administrateurs.

■

À la ligne de commande, tapez la commande cidessous :

Pkgmgr.exe /iu:MicrosoftWindowsPowerShell;ServerManager-PSH-Cmdlets; BestPractices-PSH-Cmdlets Cette commande invoque le gestionnaire de paquets de Windows Server 2008 R2 pour déclencher l’installation de Windows PowerShell, des cmdlets du Server Manager et des cmdlets des différents BPA (Best Practices Analyzer). ■

À l’issue de l’installation des composants, redémarrez le serveur.

■

Pour vérifier que les composants sont bien installés, ouvrez de nouveau une session en tant que membre du groupe Administrateurs et lancez la commande « oclist ». Cette commande retourne la liste de toutes les fonctionnalités installées sur la machine Windows Server 2008 R2 installée en mode Core.

La dernière étape consiste à configurer les règles d’exception dans le Parefeu Windows. L’activation de l’administration à distance sur une installation minimale en mode Core est aussi réalisée à l’aide d’une commande Windows PowerShell. ■

Ouvrez une session Windows PowerShell, puis tapez la commande suivante :

Set-executionPolicy -executionPolicy remotesigned Configure-SMRemoting.ps1 -force -enable Comme vu précédemment, la première commande permet de configurer l’environnement d’exécution de Windows PowerShell pour pouvoir exécuter le script PowerShell. Enfin, la deuxième commande lance l’exécution du script ConfigureSMRemoting.ps1 situé dans le dossier C:\Windows\System32, lequel active toutes les exceptions nécessaires à l’administration à distance au sein du parefeu.

2. PowerShell et Scripts SCVMM 2008 R2 Nous avons vu que Windows Server 2008 R2 et HyperV v2 apportent des améliorations significatives aux fonctionnalités de ces deux produits. SCVMM 2008 R2 tire parti de ces améliorations en rajoutant deux nouvelles commandes PowerShell assorties de nombreux paramètres qui étendent les fonctionnalités des commandes VMM 2008 existantes.

a. Nouvelles cmdlets et nouveaux paramètres SCVMM 2008 R2

- 4-

Les nouvelles commandes disponibles avec SCVMM 2008 R2 sont les suivantes : DisableVMHost Cette nouvelle commande place une machine hôte dans le mode de maintenance. EnableVMHost Cette nouvelle commande supprime le mode de maintenance d’une machine hôte VMM et remet la machine hôte en service opérationnel. Les nouveaux paramètres disponibles avec SCVMM 2008 R2 sont listés cidessous : AllowUnencryptedTransfers Ce nouveau paramètre peut être utilisé pour spécifier que les transferts de fichiers vers et depuis les bibliothèques VMM et au sein des groupes de machines hôtes ne nécessitent pas de cryptage. Ce paramètre peut améliorer les performances de manière significative lors des transferts de données importants. Ce nouveau paramètre peut être utilisé avec les commandes SetLibraryServer et Set VMHostGroup. BlockLMIfHostBusy Ce nouveau paramètre permet de stopper une opération de migration de machine virtuelle utilisant Live Migration. Ce paramètre est utilisable avec la commande MoveVM lorsque HyperV tente de redémarrer une opération de Live Migration en attente car la machine hôte source ou la machine hôte de destination est déjà en train de réaliser une opération de Live Migration. LimitCPUForMigration Ce nouveau paramètre limite les fonctionnalités des processeurs de telle sorte qu’une machine virtuelle puisse être migrée entre des machines hôtes disposant de versions de processeurs différentes. Ce paramètre peut être utilisé avec les commandes NewHardwareProfile, SetHardwareProfile, NewVM, SetVM et SetTemplate. MoveWithinCluster Ce nouveau paramètre peut être utilisé lorsque vous souhaitez déplacer toutes les machines virtuelles d’une machine hôte en cluster placée en mode maintenance. Ce paramètre s’utilise avec la commande DisableVMHost. RemoveLibraryStoreSharePath Ce nouveau paramètre peut être utilisé pour effacer le chemin d’un partage de bibliothèque donné. Ce paramètre s’utilise avec la commande SetVMMUserRole pour gérer les accès des utilisateurs du portail libreservice aux bibliothèques. De cette manière, les utilisateurs du portail peuvent accéder ou ne pas accéder aux ressources des bibliothèques telles que les machines virtuelles ou des fichiers images, ISO, stockés. RetainDeletedObjects Ce nouveau paramètre permet de conserver les objets du cache VMM marqués en suppression. Ce paramètre est utilisable avec la commande GetVMMServer. Microsoft précise que ce paramètre est surtout utilisé par les développeurs qui souhaitent étendre l’interface graphique utilisateur. UseCluster Ce nouveau paramètre permet de forcer le transfert d’une machine virtuelle via Quick Migration même si les fonctionnalités Live Migration sont disponibles. Ce paramètre peut être utilisé avec la commande MoveVM. UseLocalVirtualHardDisks Ce nouveau paramètre permet de spécifier que le fichier .VHD utilisé par une nouvelle machine virtuelle est déjà situé sur la machine hôte de destination et qu’il n’est pas nécessaire de copier un fichier VHD à partir de la bibliothèque. Ce paramètre permet de supporter la nouvelle fonctionnalité de Rapid Provisioning of Virtual Machines. VMNetworkOptimizationEnabled Ce nouveau paramètre permet l’activation de la détection des fonctions d’accélération réseau. Ces nouvelles fonctionnalités augmentent de manière significative les performances réseau si et seulement si les cartes réseau

- 5-

supportent les protocoles VMQ (Virtual Machine Queue) ou TCP Chimney. VMQ permet de créer une queue unique pour chaque carte réseau. Les fonctions de déchargement TCP Chimney permettent aux opérations réseau d’être déchargées vers la carte réseau. Ce paramètre est utilisable avec les commandes NewP2V, NewV2V, New VirtualNetworkAdapter et SetVirtualNetworkAdapter. VMWarePortGroup Ce nouveau paramètre permet de spécifier un groupe de ports VMware.

b. Live Migration et opérations PowerShell SCVMM 2008 R2 Live Migration permet à l’administrateur SCVMM 2008 R2 de déplacer, c’estàdire migrer, des machines virtuelles en fonctionnement d’un nœ ud à un autre nœ ud au sein d’un cluster Windows Server 2008 R2 sans aucune interaction pour les systèmes, les applications ou les connexions utilisateurs. Lorsque la commande MoveVM est invoquée pour déplacer une machine virtuelle hébergée au sein d’un cluster de machines hôtes HyperV, SCVMM 2008 R2 tente d’utiliser la fonctionnalité de Live Migration. Si la fonctionnalité de Live Migration n’est pas disponible ou utilisable, alors SCVMM 2008 R2 utilisera une migration de type cluster, c’est àdire Quick Migration. L’administrateur a la possibilité d’utiliser le paramètre UseCluster pour forcer SCVMM 2008 R2 à utiliser une migration de type cluster même lorsque la fonctionnalité de Live Migration est disponible.

c. Déploiement rapide des machines virtuelles SCVMM 2008 non R2, ne permet pas d’associer un disque virtuel VHD non positionné par luimême. Les différents assistants ou commandes PowerShell permettent de créer de nouvelles machines virtuelles à partir de modèles de machines virtuelles déjà existantes, ou bien basées sur des modèles utilisant euxmêmes des disques VHD stockés au sein d’une bibliothèque VMM. Pour accélérer la création des machines virtuelles à partir des modèles VMM contenus dans les bibliothèques, l’administrateur VMM peut utiliser la commande NewVM avec le paramètre UseLocalVirtualHardDisks. Ce paramètre permet de spécifier l’utilisation d’un disque virtuel existant stocké localement sur la machine hôte. De cette manière, il n’est pas nécessaire d’utiliser le protocole de transfert BITS pour réaliser une copie importante de la bibliothèque vers la machine hôte cible. La commande MoveVirtualHardDisk pourra aussi être utilisée pour spécifier le fichier de disque dur virtuel que la machine virtuelle doit utiliser à la place des paramètres originaux. La commande NewVirtualDiskDrive pourra aussi être utilisée lorsque l’on souhaite rajouter un nouveau disque à une machine virtuelle existante. L’exemple commenté ciaprès montre à quel point il est simple de créer une machine virtuelle à l’aide de Windows PowerShell, via le nouveau paramètre UseLocalVirtualHardDisk, sachant que généralement ce genre de script sera décliné pour créer en masse de multiples machines virtuelles. # Récupère le nom de la machine hôte Hyper-V Get-VMMServer -ComputerName "VMMServer1.Contoso.com" # Affecte un GUID à une variable pour créer un job $JobGroupID = [Guid]::NewGuid().ToString() # Affecte le modèle de VM MyTemplate à une variable $Template = Get-Template | where {$_.Name -eq MyTemplate"} # Affecte le nom de la machine hôte Hyper-V à une variable $VMHost = Get-VMHost | where {$_.Name -eq "VMHost.Contoso.com"} # Crée un job de déplacement du disque de démarrage vers L:\Disk0.VHD Move-VirtualHardDisk -IDE -BUS 0 -LUN 0 -Path "P:\Disk0.VHD" -JobGroup $JobGroupID # Crée un job de création d’une machine virtuelle en utilisant les différents paramètres définis via les variables déclarées plus haut. New-VM -Name "PROD-SOPHIA-WIN01" -Path "P:\" -Template $Template -VMHost $VMHost -JobGroup -$JobGroupID -UseLocalVirtualHardDisks

- 6-

Pour plus d’informations sur l’utilisation du paramètre UseLocalVirtualHardDisks, n’hésitez pas à utiliser l’aide en ligne. À l’invite de commande Windows PowerShell, tapez GetHelp NewVM. Pour créer rapidement via PowerShell des machines virtuelles, vous pourrez vous référer à deux exemples de scripts disponibles sur le site de Microsoft ou via le document intitulé « System Center Virtual Machine Manager 2008 R2 RC Scripting Guide » : RapidProvisionVM.ps1 et RapidProvisionVMwithAnswerFile.ps1.

d. À propos de la commande MoveVirtualHardDisk Cette nouvelle commande déplace un fichier de disque dur virtuel Windows fichier VHD, d’un emplacement vers un autre sur la même machine hôte. Par exemple, si la machine hôte dispose de plusieurs lecteurs de disque physique et que la machine virtuelle possède deux disques durs virtuels ou plus, par exemple pour le système d’exploitation et pour les données, il est possible d’utiliser cette commande PowerShell pour positionner un des disques durs virtuels sur un autre disque dur physique. De cette manière, les I/O sont réparties et les performances sont améliorées. Cette commande peut aussi être utilisée dans le cas où un disque dur virtuel de taille dynamique sature l’espace disque physique de stockage. Elle vous permettra de déplacer le disque dur virtuel dynamique vers un disque dur physique disposant de plus d’espace. Dans le cadre des opérations de gestion des disques virtuels, l’administrateur VMM pourra aussi être amené à utiliser les commandes CompressVirtualDiskDrive, SetVirtualHardDisk, Get VirtualHardDisk et RemoveVirtualHardDisk. Attention ! La cmdlet MoveVirtualHardDisk ne peut déplacer que des fichiers VHD utilisés par les plates formes de virtualisation HyperV ou Virtual Server. Il n’est pas possible d’utiliser cette commande pour déplacer un fichier VMDK VMware vers un autre emplacement sur une machine hôte VMware ESX.

e. Migration du stockage avec Quick Storage Migration Les machines hôtes fonctionnant sous Windows Server 2008 R2 ou sous VMware ESX disposant des fonctionnalités VMotion peuvent utiliser la commande PowerShell VirtualHardDisk avec la commande MoveVM pour migrer une machine virtuelle vers un stockage différent, sur la même machine hôte ou sur une machine hôte différente. La migration du stockage à chaud est une nouvelle fonctionnalité de SCVMM 2008 R2. Elle prend en charge le déplacement des fichiers de disques virtuels au format Windows VHD et VMware VMDK pendant le fonctionnement de la machine virtuelle avec une indisponibilité faible ou nulle. Pour plus d’informations sur l’utilisation du paramètre MoveVM, n’hésitez pas à utiliser l’aide en ligne. À l’invite de commande Windows PowerShell, tapez GetHelp MoveVM.

f. Gestion du mode maintenance et script d’automation PowerShell Nous avons vu précédemment que SCVMM 2008 R2 permettait à l’administrateur VMM de placer les machines hôtes HyperV en mode maintenance. Ce mode peut être utilisé lors des opérations de maintenance des machines hôtes, par exemple pour procéder à des mises à niveaux matérielles ou lors du passage des mises à jour Microsoft ou de produits tiers. La nouvelle commande PowerShell DisableVMHost positionne une machine hôte HyperV membre d’un cluster Windows Server 2008 R2 en mode maintenance. Pour plus d’informations sur l’utilisation du paramètre DisableVMHost, n’hésitez pas à utiliser l’aide en ligne. À l’invite de commande Windows PowerShell, tapez GetHelp DisableVMHost.

Lors de la mise en maintenance de la machine hôte HyperV, toutes les machines hôtes sont migrées vers d’autres nœ uds du cluster. Si les fonctionnalités Live Migration sont disponibles, le déplacement des machines virtuelles est réalisé de cette manière. Sinon, les machines virtuelles non configurées en mode haute disponibilité seront placées en état Enregistré. En plus de ces opérations, cette commande interdit toutes les opérations de création de machines virtuelles sur le ou les nœ uds concernés et exclut cellesci de toutes les opérations d’évaluation relatives aux opérations de placement.

La désactivation du mode maintenance ne repositionne pas les machines virtuelles migrées via Live

- 7-

Migration sur la machine hôte originale. De la même manière, les machines virtuelles placées dans l’état Enregistré ne sont pas redémarrées. Il est du ressort de l’administrateur VMM de décider des opérations à entreprendre après la sortie du mode de maintenance. Microsoft livre en téléchargement un exemple d’automation du passage et de la sortie de machines hôtes du mode maintenance vers le mode production.

Script de gestion du mode de maintenance "MaintenanceModeInCluster.ps1" Le script cidessous réalise les opérations suivantes : ●

il récupère la liste des machines hôtes membres du cluster HyperV fonctionnant sous Windows Server 2008 R2,

●

il place séquentiellement chaque machine hôte dans le mode maintenance,

●

il utilise le paramètre MoveWithinCluster pour utiliser les fonctions Live Migration,

●

il déclare une période de maintenance de 2 heures,

●

il redémarre les machines hôtes mises en maintenance.

# Connexion au serveur SCVMM. $VMMServer = Get-VMMServer -ComputerName "SCVMM01.Corpnet.net" # Récupérations des machines members du cluster. $Cluster = Get-VMHostcluster -Name "Hyper-VCluster01" $VMHosts = Get-VMHost -VMHostCluster $Cluster # Placement séquentiel de chaque machine du cluster en mode maintenance. # Pause du script pour une période de 2 heures. # Reprise des services. Foreach ($VMHost in $VMHosts) { Write-Host "Activation du mode MAINTENANCE pour" $VMHost "pour 2 heures." Disable-VMHost $VMHost -MoveWithinCluster Start-Sleep "7200" Write-Host "Retour en production pour" $VMHost "." Enable-VMHost $VMHost }

Pour plus d’informations sur la manipulation de commandes PowerShell de SCVMM 2008 et SCVMM 2008 R2, référezvous aux liens cidessous : System Center Virtual Machine Manager TechCenter http://technet.microsoft.com/enus/scvmm/default.aspx, et aussi System Center Virtual Machine Manager Scripting http://technet.microsoft.com/enus/library/cc764259.aspx

- 8-