Clonage d'ordinateurs virtuels via l'isolement réseau

Publication: juillet 2016

La gestion des laboratoires virtuels est en train de prendre de l'importance dans le cycle de vie de développement des logiciels.  Visual Studio Lab Management est un produit de Visual Studio qui permet aux développeurs et aux testeurs de gérer les laboratoires virtuels.  Grâce à Visual Studio Lab Management, les équipes de développement peuvent utiliser la technologie de virtualisation dans leurs laboratoires de développement et de test pour créer des environnements multicouches complexes à partir d'ordinateurs virtuels.  Ils peuvent ensuite déployer des builds et exécuter des tests sur ces environnements.  

L'un des intérêts de la virtualisation pour les laboratoires de développement et de test est qu'elle permet de créer des copies identiques, ou clones, d'ordinateurs virtuels déployés en ne copiant que quelques fichiers.  Le clonage est utile dans de nombreux scénarios.  Par exemple, un développeur qui a besoin d'une copie de l'environnement d'un testeur pour reproduire un problème peut créer un clone de cet environnement.  Chaque testeur d'une équipe de test peut cloner une copie d'un environnement, puis organiser ses tests en fonction du reste de l'équipe.  Le clonage permet aux développeurs et aux testeurs de gagner du temps, car ils n'ont pas à installer et réinstaller des systèmes d'exploitation et autres logiciels dans tous les environnements qu'ils créent.  

Spécifications

• Visual Studio Enterprise, Visual Studio Test Professional

Même s'il est facile de cloner un environnement virtuel, certaines conséquences du clonage doivent être prises en compte.  Les ordinateurs compris dans un environnement cloné possèdent les mêmes noms d'ordinateurs que les ordinateurs de l'environnement d'origine.  Dans certains cas, ils peuvent même avoir les mêmes adresses IP et MAC.  Pour cette raison, l'un des clones pourrait perdre la connectivité réseau ou bien le trafic réseau qui vise l'un des clones pourrait atteindre l'autre clone.  Vous pourriez également, sans le vouloir, déployer une application sur un clone et effectuer les tests sur un autre.  

Visual Studio Lab Management permet d'éviter ces problèmes en sécurisant le clonage des environnements virtuels grâce à la technologie appelée isolement réseau.  Cette rubrique aborde le fonctionnement de l'isolement réseau et compare le clonage avec et sans utilisation de l'isolement réseau.  Le premier exemple expose plusieurs formes de conflits entre clones en l'absence d'un isolement réseau.  Les exemples suivants proposent plusieurs solutions pour éviter de tels conflits grâce à Visual Studio Lab Management.  

Conflits de réseaux

La figure 1 montre un environnement virtuel typique que vous pourriez créer à l'aide de Lab Management.  Cet environnement (l'environnement d'origine) comprend deux ordinateurs virtuels : web-server et db-server.  Ces ordinateurs ont respectivement le rôle de serveur web et de serveur de base de données dans une application web à trois couches.  Dans cet exemple, nous supposons qu'un membre d'une équipe de développement ait créé cet environnement et qu'il y ait déployé la dernière build de son application web.  Nous supposons également qu'un instantané (appelé "latest build") de cet environnement ait été créé après le déploiement de la build.  Un instantané correspond à un état ponctuel d'un environnement.  Vous pouvez restaurer un environnement à partir de cet enregistrement d'état et reprendre son exécution.  La figure ci-dessous montre les noms d'ordinateurs, ainsi que les adresses IP et MAC des deux ordinateurs virtuels de l'environnement d'origine.  

Environnement d'origine

La figure 2 montre un environnement cloné et celui d'origine.  Après le clonage, les types de conflits réseau suivants peuvent se produire au moment du démarrage des environnements :  

1. Conflits de noms d'ordinateurs

2. Conflits d'adresses IP

3. Conflits d'adresses MAC

Environnement d'origine et environnement cloné dans un même réseau

Le résultat exact de chacun de ces conflits dépend de plusieurs facteurs : le système d'exploitation installé sur les ordinateurs virtuels, l'infrastructure de réseau du laboratoire, etc.  Dans la figure 2, nous avons supposé qu'une adresse IP statique et une adresse MAC statique ont été configurées sur chacun des ordinateurs virtuels de l'environnement d'origine.  Ainsi, quand l'environnement a été cloné, les ordinateurs virtuels clonés possédaient les mêmes adresses IP et MAC.  

Conflits de noms d'ordinateurs

Un nom d'ordinateur est un nom convivial attribué par un utilisateur à un ordinateur pour pouvoir l'identifier sur le réseau.  Deux protocoles sont généralement utilisés pour résoudre un nom d'ordinateur en son adresse IP : NetBIOS et DNS (Domain Name Server).  Quand deux ordinateurs portant le même nom d'ordinateur sont démarrés sur le même segment réseau, NetBIOS détecte le conflit de noms et en avertit l'utilisateur.  En général, NetBIOS ne peut détecter les conflits que si les ordinateurs se trouvent sur le même segment réseau.  Si les ordinateurs ne se trouvent pas sur le même segment réseau ou si les avertissements sont ignorés, le niveau de conflit suivant se produit au niveau du DNS.  Le DNS est un référentiel central dans lequel le nom des ordinateurs est enregistré.  Quand deux ordinateurs portant le même nom d'ordinateur tentent de s'inscrire auprès du DNS, le deuxième ordinateur peut remplacer l'entrée créée par le premier ordinateur.  Dans ce cas, le premier ordinateur qui démarre ne sera pas accessible via une résolution de noms.  

Il existe des moyens simples d'éviter et de résoudre les problèmes de conflits de noms d'ordinateurs.  Au lieu de créer des copies identiques d'un environnement, vous pouvez personnaliser chaque clone grâce à un mécanisme appelé sysprep.  Sysprep est inclus dans les systèmes d'exploitation Windows.  Quand vous utilisez sysprep pour cloner un environnement, chacun des ordinateurs de cet environnement se voit attribuer un nom d'ordinateur, une adresse IP et une adresse MAC différents de ceux des ordinateurs de l'environnement d'origine.  Cependant, les clones ne sont plus identiques.  

Les conséquences de l'attribution d'un nom d'ordinateur unique pour chaque clone (que cela ait été fait via sysprep ou au moyen d'une intervention manuelle) dépendent des logiciels installés sur l'ordinateur virtuel.  Pour comprendre cela, regardons l'exemple qui suit.  Quand l'application a été déployée sur l'environnement, un fichier web.config a été créé sur le serveur web.  Dans ce fichier, nous avons configuré le nom d'ordinateur db-server comme faisant partie de la chaîne de connexion.  Voici un extrait de ce fichier :  

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server"/>
  </appSettings>
</configuration>

Quand vous modifiez le nom d'ordinateur d'un serveur de base de données dans un environnement cloné, vous devez également modifier manuellement le fichier web.config comme suit pour qu'il utilise le nouveau nom (db-server2 est le nouveau nom d'ordinateur attribué à l'ordinateur virtuel de l'environnement cloné).

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server2"/>
  </appSettings>
</configuration>

La modification du nom d'ordinateur des serveurs SQL Server nécessite, quant à elle, des étapes supplémentaires.  Voici un extrait des scripts SQL nécessaires à cette modification :  

sp_dropserver db-server
sp_addserver db-server2, local
GO

L'exemple précédent montre comment une application doit être reconfigurée si les noms d'ordinateurs sont modifiés.  De toute évidence, cette procédure dépend de l'application.  Si une application écrit le nom d'ordinateur dans les entrées d'une base de données, ces entrées devront être modifiées de la même manière.  Dans certains cas, vous devrez réinstaller une application si le nom d'ordinateur change.  De telles reconfigurations et réinstallations sont évidemment ce que nous voulions éviter en utilisant le clonage.  Cela nécessite une solution plus robuste et indépendante de l'application qui puisse permettre à plusieurs clones de coexister sans conflits de noms d'ordinateurs.  

Conflits d'adresses IP

Une adresse IP (Internet Protocol, protocole Internet) est utilisée pour permettre aux ordinateurs de communiquer via un réseau TCP.  Les adresses IP sont attribuées de manière statique ou dynamique par un serveur DHCP via le réseau.  Chaque interface réseau connectée d'un ordinateur possède une adresse IP.  Si un ordinateur virtuel configuré à l'aide d'une adresse IP statique est cloné puis placé sur le même réseau que l'ordinateur virtuel d'origine, il y aura conflit d'adresses IP, en plus du conflit de noms d'ordinateurs.  Vous pouvez résoudre manuellement ce confit en modifiant l'adresse IP de l'un des clones.  Encore une fois, les conséquences de la modification de l'adresse IP dépendent de la manière dont l'adresse IP statique est utilisée par les applications installées sur les ordinateurs virtuels.  

Quand vous démarrez un ordinateur virtuel configuré à l'aide d'une adresse IP dynamique, il y a conflit de réseaux pendant une courte durée.  Peu après le clonage du premier ordinateur virtuel, le deuxième ordinateur virtuel à se connecter au réseau détecte ce conflit et s'autocorrige en renouvelant son adresse IP.  Un même conflit de courte durée se produit chaque fois que l'environnement cloné est restauré à partir d'un instantané de l'environnement d'origine.  En général, ces périodes de conflit ne durent pas suffisamment longtemps pour affecter l'application.  

Conflits d'adresses MAC

Une adresse MAC (Media Access Control; contrôle d'accès au support) est une adresse qui est attribuée à chaque interface réseau d'un ordinateur.  Dans le cas d'ordinateurs physiques, l'adresse est attribuée à chaque interface réseau par le fabricant de la carte réseau.  Dans le cas d'ordinateurs virtuels, il existe deux façons d'attribuer des adresses MAC : de manière statique ou dynamique.  Vous pouvez spécifier l'adresse MAC que l'interface réseau d'un ordinateur virtuel doit utiliser.  Il s'agit de l'adresse MAC statique.  Vous pouvez également attribuer une adresse MAC de façon dynamique au moyen d'un hyperviseur.  Il s'agit de l'adresse MAC dynamique.  Les adresses MAC dynamiques sont attribuées par l'hyperviseur Hyper-V à partir d'un pool d'adresses MAC à chaque démarrage d'un ordinateur virtuel.  Chaque hôte possède un schéma permettant de générer des adresses MAC de manière à éviter les conflits avec les ordinateurs virtuels d'un autre hôte.  

Si des adresses MAC statiques sont utilisées pour les ordinateurs virtuels de l'environnement d'origine, les ordinateurs virtuels de l'environnement cloné auront les mêmes adresses MAC,  ce qui résultera en un conflit d'adresses MAC.  Les doublons d'adresses MAC sont plus difficiles à détecter, car ils ne sont pas toujours signalés par les ordinateurs.  Même quand ils le sont, les messages d'avertissement sont journalisés dans l'Observateur d'événements Windows.  Pour l'utilisateur final, les doublons d'adresses MAC peuvent avoir deux conséquences.  La première est la perte de la connectivité réseau pour l'un des deux clones.  La deuxième est que les paquets réseau envoyés à un ordinateur peuvent être reçus par l'autre ordinateur.  Quand l'ordinateur d'origine et son clone ont les mêmes adresses MAC, leurs adresses IP sont également les mêmes.  Même quand le protocole DHCP est utilisé pour obtenir des adresses IP dynamiques, le serveur DHCP leur attribuera les mêmes adresses IP, car leurs adresses MAC sont identiques.  

Dans une certaine mesure, les conflits MAC peuvent être évités à l'aide d'adresses MAC dynamiques.  Cependant, quand l'environnement cloné est restauré à partir d'un instantané de l'environnement d'origine, l'état intégral de ces ordinateurs virtuels est restauré, y compris les adresses MAC.  Cela résulte donc en conflits d'adresses MAC et les mêmes problèmes décrits précédemment se produiront à chaque redémarrage de l'ordinateur virtuel cloné.  Quand l'environnement cloné est redémarré, l'hyperviseur émet et renouvelle les adresses MAC en utilisant des valeurs de sa propre plage d'adresses.  

La détection et la résolution des différentes formes de conflits que nous venons de voir, puis la résolution manuelle du système d'exploitation ou des applications pour qu'ils continuent de fonctionner, sont des étapes laborieuses et génératrices d'erreurs pour ceux qui utilisent fréquemment la gestion des laboratoires virtuels.  Souvent, le fait de modifier ces paramètres dans l'environnement virtuel ne permet plus de reproduire les bogues ou problèmes similaires de l'environnement de production.  Le fait d'installer l'application une fois dans un environnement virtuel et de cloner cet environnement pour créer des copies identiques nécessite une approche plus sophistiquée que d'ordinaire.  

Isolement réseau

Deux spécifications ont été déterminées jusqu'à maintenant.  La première est que les ordinateurs virtuels d'un environnement cloné doivent avoir les mêmes noms d'ordinateurs, et les mêmes adresses IP et MAC que les ordinateurs de l'environnement d'origine.  Cependant, ces clones doivent pouvoir être adressables de manière indépendante depuis l'extérieur de l'environnement.  Cela est nécessaire, par exemple, pour qu'une personne puisse se connecter à chacun des clones depuis son ordinateur de bureau, pour qu'une application soit déployée sur un clone en particulier ou pour qu'un test soit effectué sur un clone spécifique.  Cela nous mène à la deuxième spécification qui est que les ordinateurs virtuels d'un environnement cloné doivent avoir un nom d'ordinateur, une adresse IP et une adresse MAC différents de ceux des ordinateurs virtuels de l'environnement d'origine.  Logiquement, pour répondre à ces deux spécifications, il faudrait que chaque ordinateur virtuel ait deux interfaces : une interface privée pour laquelle le nom d'ordinateur, l'adresse IP et l'adresse MAC sont les mêmes pour chaque clone, et une interface publique pour laquelle les valeurs sont uniques pour chaque clone.  

Pour éviter les conflits réseau avec les interfaces privées, ces dernières doivent être connectées à un réseau privé dans chaque clone.  Un réseau privé est un réseau virtuel limité aux ordinateurs virtuels d'un environnement.  Ce réseau est limité à un environnement. Il ne peut donc y avoir aucun conflit, même si les mêmes noms d'ordinateurs et adresses IP et MAC sont utilisés par un autre clone.  Pour pouvoir être accessibles en dehors de l'environnement, toutes les interfaces publiques doivent être connectées à un réseau public commun.  Le réseau public ou réseau lab est un réseau sur lequel les ordinateurs virtuels d'un environnement peuvent interagir avec les clients et autres ordinateurs d'un laboratoire.  

La figure 3 montre comment les interfaces privées et publiques règlent les conflits réseau.

Isolement réseau dans Visual Studio Lab Management

Visual Studio Lab Management implémente l'isolement réseau pour les environnements SCVMM en créant deux interfaces réseau pour chaque ordinateur virtuel.  L'une de ces interfaces réseau est une interface privée connectée à un réseau privé, et l'autre est une interface publique connectée à un réseau public.  

Le logiciel Lab Management, associé à l'agent installé sur chaque ordinateur virtuel, permet à l'environnement d'origine et à l'environnement cloné de coexister sans conflits.

Interfaces privées sur réseau privé

La description suivante résume la façon dont les noms d'ordinateurs, les adresses IP et les adresses MAC sont attribués aux interfaces privées d'un environnement.

Noms d'ordinateurs : sur un réseau privé, les noms d'ordinateurs sont résolus par NetBIOS et ne nécessitent pas d'action supplémentaire de la part de Lab Management.  Les applications qui sont configurées pour fonctionner avec les noms d'ordinateurs NetBIOS fonctionneront comme prévu sur chaque clone.  Dans notre exemple, l'ordinateur web-server référence l'ordinateur db-server en utilisant son nom.  Ces noms sont les mêmes dans l'environnement d'origine et l'environnement cloné.  Le fichier web.config n'a donc pas besoin d'être modifié dans l'environnement cloné.  

Étant donné qu'il n'y a pas de serveur DNS sur le réseau privé, nous devons savoir gérer la situation dans laquelle des noms de domaine complets (FQDN) sont utilisés par les ordinateurs virtuels pour se référencer les uns les autres au lieu de noms NetBIOS.  Par exemple, si le fichier web.config référençait db-server en tant que db-server.lab.contoso.com, la résolution de ce nom en adresse IP ne serait pas possible sans serveur DNS sur le réseau privé.  Pour résoudre ce problème, l'agent lab exécuté sur l'ordinateur virtuel ajoute des entrées correspondant aux autres ordinateurs virtuels du même environnement dans le fichier HOSTS.  Le fichier HOSTS permet d'indiquer au système d'exploitation qu'un nom doit être résolu en une adresse IP particulière.  Dans notre exemple, le fichier HOSTS de web-server contiendra l'entrée suivante :  

192.168.23.2 db-server.lab.contoso.com

Adresses IP : une adresse IP appartenant à la plage 192.168.23.1 - 255 est attribuée à l'interface de réseau privé de chaque ordinateur virtuel.  Par exemple, l'interface privée de web-server reçoit l'adresse IP 192.168.23.1 et celle de db-server, l'adresse 192.168.23.2.  Lab Management permet de garantir que web-server et db-server recevront la même adresse IP statique pour chaque clone.  Ainsi, même si le fichier web.config présent sur web-server est configuré avec l'adresse IP de db-server, il n'aura pas à être reconfiguré dans l'environnement cloné.  Dans les environnements configurés avec l'isolement réseau, les interfaces privées reçoivent des adresses IP appartenant à cette même plage (démarrant par 192.168.23.1).  Le nombre maximal d'adresses requises dans cette plage correspond au nombre maximal d'ordinateurs virtuels d'un environnement.  Cet ensemble d'adresses IP n'est routable qu'au sein du réseau privé. Il est donc plus sûr d'utiliser une plage prédéfinie, du moment que celle-ci n'est pas utilisée sur le réseau public.  

Adresses MAC : une adresse MAC statique aléatoire est attribuée à l'interface de réseau privé de chaque ordinateur virtuel présent dans un environnement isolé du réseau.  Dans notre exemple, l'interface privée du web-server d'origine reçoit une adresse MAC telle que celle-ci : 00-15-5D-07-57-01.  Lab Management permet de garantir que web-server recevra la même adresse MAC dans l'environnement cloné.  Cet ensemble d'adresses MAC n'est pas routable en dehors du réseau privé. Il est donc plus sûr d'utiliser une adresse aléatoire, du moment qu'elle n'est pas comprise dans la plage utilisée par l'hyperviseur sur cet hôte.  

Interfaces publiques sur un réseau public

La description suivante résume la façon dont les noms d'ordinateurs, les adresses IP et les adresses MAC sont attribués aux interfaces publiques d'un environnement.

Noms d'ordinateurs : NetBIOS ne doit pas être utilisé pour résoudre les noms d'ordinateurs sur le réseau public, car cela entraînerait un conflit de noms d'ordinateurs.  Pour éviter cela, Lab Management désactive les diffusions NetBIOS sur l'interface publique de chaque ordinateur virtuel.  Comme pour NetBIOS, il n'est pas souhaitable que les noms d'ordinateurs NetBIOS des ordinateurs virtuels soient inscrits auprès du DNS.  Lab Management désactive également l'inscription DNS pour toutes les interfaces publiques.  En l'absence de NetBIOS et d'une inscription DNS par défaut, nous voulons toujours que les ordinateurs virtuels possèdent des noms uniques pouvant être utilisés sur le réseau public.  Lab Management génère un nom d'alias unique pour le compte de chaque ordinateur virtuel et l'inscrit en tant qu'enregistrement "A" auprès du DNS.  Dans notre exemple, le web-server de l'environnement d'origine peut être inscrit à l'aide d'un nom d'alias unique similaire à celui-ci : VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com.  Le même web-server de l'environnement cloné est inscrit à l'aide d'un autre nom similaire à celui-ci : VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com.  

Adresses IP : l'interface de réseau public de chaque ordinateur virtuel est configurée de manière à recevoir une adresse IP dynamique d'un serveur DHCP.  Cela permet de garantir que les ordinateurs virtuels de l'environnement d'origine et de l'environnement cloné auront des adresses IP uniques.  Par exemple, le web-server de l'environnement d'origine peut recevoir l'adresse IP 172.52.20.140 et le même web-server de l'environnement cloné peut recevoir l'adresse IP 172.52.20.205.  

Adresses MAC : pour éviter les conflits d'adresses MAC, l'interface de réseau public de chaque ordinateur virtuel peut être configurée de manière à recevoir des adresses MAC de l'hyperviseur.  Ainsi, l'ordinateur web-server de notre exemple est sûr de recevoir une adresse MAC différente dans l'environnement d'origine et dans l'environnement cloné.  Cependant, comme nous l'avons vu précédemment, quand un environnement cloné est restauré à partir d'un instantané de l'environnement d'origine, l'adresse IP et l'adresse MAC de l'ordinateur virtuel cloné possèdent les mêmes valeurs que celles de l'environnement d'origine.  Par exemple, quand l'environnement cloné est restauré à partir de l'instantané de la dernière build, l'adresse IP de web-server devient 10.86.51.61 (voir figure 3), qui est la même adresse que pour le web-server de l'environnement d'origine.  Il en va de même pour l'adresse MAC.  Le conflit d'adresses IP ne dure que jusqu'à ce que les adresses IP soit renouvelées par le serveur DHCP alors que le conflit d'adresses MAC dure tant que les ordinateurs virtuels n'ont pas été redémarrés.  En raison de cette limitation, l'utilisation d'adresses MAC attribuées dynamiquement aux interfaces publiques par l'hyperviseur n'est pas envisageable.  

Pour répondre à ce besoin, Lab Management utilise son propre pool d'adresses MAC.  Des adresses MAC uniques appartenant à ce pool sont attribuées aux interfaces publiques des ordinateurs virtuels.  Quand un environnement cloné est restauré à partir d'un instantané, Lab Management modifie automatiquement les adresses MAC pour éviter les conflits.  Pour comprendre comment cela fonctionne, imaginons que l'adresse MAC du web-server de l'environnement d'origine soit 1D-D8-B7-1C-00-05 et que celle du web-server de l'environnement cloné soit 1D-D8-B7-1C-00-07.  Quand l'environnement cloné est restauré à partir d'un instantané de l'environnement d'origine, l'adresse MAC de web-server devient temporairement 1D-D8-B7-1C-00-05.  Lab Management rétablit alors l'adresse 1D-D8-B7-1C-00-07 pour éviter les conflits réseau.  

Interactions typiques dans un environnement isolé du réseau

Nous allons parler de ce qui se passe quand deux ordinateurs virtuels d'un environnement communiquent l'un avec l'autre :

1. Web-server utilise NetBIOS ou le fichier HOSTS pour résoudre le nom d'ordinateur "db-server" en l'adresse IP de l'interface privée db-server (192.168.23.2).

2. Le serveur web communique avec le db-server possédant cette adresse IP.

Quand un client extérieur à l'environnement doit communiquer avec le web-server d'un environnement cloné, la procédure suivante est suivie :

1. Le client interroge Lab Management pour obtenir le nom d'alias unique du web-server de l'environnement cloné.

2. Le logiciel Lab Management répond par un nom d'alias unique.

3. Le serveur DNS résout le nom d'alias unique en l'adresse IP de l'interface publique de web-server (10.86.51.63).

4. Le client communique avec le web-server possédant cette adresse IP.

Autres approches pour l'isolement réseau

L'utilisation de deux interfaces n'est pas la seule méthode possible pour l'isolement réseau.  Une autre méthode très similaire est l'utilisation d'une NAT bidirectionnelle.  La NAT est couramment employée dans la création d'un réseau privé de périphériques qui doivent communiquer avec les périphériques d'un réseau public.  Même si dans une NAT typique la communication doit toujours être initiée par le réseau privé, la NAT bidirectionnelle va plus loin en autorisant les communications initiées par les ordinateurs d'un réseau privé ou par ceux d'un réseau public.  

Pour pouvoir mettre en place l'isolement réseau à l'aide de cette méthode, un serveur NAT bidirectionnel doit se trouver dans l'environnement.  Pour cela, il faut ajouter un ordinateur virtuel spécial à l'environnement qui jouera le rôle de serveur NAT bidirectionnel.  Quand un environnement isolé du réseau est créé, les adresses IP publiques et privées des ordinateurs virtuels sont attribuées de la même manière qu'avec la méthode des deux interfaces.  Cependant, au lieu d'attribuer une adresse IP à une interface réseau d'un ordinateur virtuel, les mappages sont stockés dans une table NAT sur un serveur NAT bidirectionnel.  

Les étapes permettant de faire communiquer deux ordinateurs virtuels dans un environnement à l'aide d'une NAT bidirectionnelle sont exactement les mêmes pour la méthode des deux interfaces :

1. Web-server utilise NetBIOS ou le fichier Hosts pour résoudre le nom d'ordinateur db-server en l'adresse IP de l'interface privée db-server (192.168.23.2).

2. Le serveur web communique avec le db-server possédant cette adresse IP.

Les étapes permettant à un client extérieur à l'environnement de communiquer avec le web-server d'un environnement cloné sont légèrement différentes :

1. Avec la méthode NAT, le client interroge Lab Management pour obtenir le nom d'alias unique du web-server de l'environnement cloné  (Visual Studio Lab Management n'implémente pas la méthode NAT).  

2. Le logiciel Lab Management répond par un nom d'alias unique.

3. Le serveur DNS résout le nom d'alias unique en l'adresse IP publique de web-server (10.86.51.63).

4. Cette adresse IP est mappée vers une interface sur un serveur NAT bidirectionnel.  Le client communique avec le serveur NAT bidirectionnel en supposant qu'il communique avec le web-server.  

5. Le serveur NAT récupère les mappages stockés dans ses tables de configuration et traduit l'adresse IP publique (10.86.51.63) en l'adresse IP privée (192.168.23.1).

6. Le serveur NAT transmet le message du client via le réseau privé à l'adresse IP 192.168.23.1, qui est celle du web-server.

L'intérêt de cette méthode par rapport à celle des deux interfaces est que les ordinateurs virtuels de l'environnement n'ont pas du tout à être modifiés.  Il n'est pas nécessaire d'ajouter une interface réseau supplémentaire sur chaque ordinateur virtuel.  L'ajout d'une interface réseau supplémentaire sur un ordinateur virtuel peut empêcher certaines applications de fonctionner.  

Un autre avantage de cette méthode est que l'intégralité de la logique visant à créer l'isolement réseau est encapsulée dans l'ordinateur virtuel supplémentaire.  Il n'est pas nécessaire d'installer un agent sur tous les autres ordinateurs virtuels.  Le routage de tous les paquets via un ordinateur virtuel supplémentaire fournit un point de contrôle supplémentaire pour les fonctionnalités plus avancées d'un isolement réseau telles que les suivantes :  

• Isolement en sortie seule : ne permet pas aux paquets réseau envoyés par les clients extérieurs à l'environnement d'atteindre les ordinateurs virtuels de l'environnement.

• Sortie seule avec exceptions sur ports spécifiques : ne permet pas aux paquets réseau envoyés par les clients extérieurs à l'environnement d'atteindre les ordinateurs virtuels de l'environnement, à moins d'utiliser les ports spécifiés.

Ces fonctionnalités peuvent être facilement implémentées avec la NAT bidirectionnelle par l'ajout d'un pare-feu sur le serveur NAT. Le principal inconvénient de cette méthode est que certaines applications ne fonctionneront plus.  Par exemple, les protocoles de communication à distance DCOM et .NET, qui sont couramment employés dans les applications Windows, ne fonctionnent pas quand le client et le serveur sont séparés par un serveur NAT.  C'est pour cette raison que Visual Studio Lab Management utilise la méthode des deux interfaces.  Un autre inconvénient de la NAT bidirectionnelle est qu'elle nécessite un ordinateur virtuel supplémentaire dans chaque environnement, ce qui crée une surcharge supplémentaire pendant la création des environnements virtuels ou autres opérations liées à ces derniers.  

Autres conflits

Nous venons d'évoquer la façon dont les conflits de noms d'ordinateurs et d'adresses IP et MAC peuvent être résolus grâce à l'isolement réseau.  Quand des environnements sont clonés, d'autres formes de conflits peuvent se produire.  Quand il existe une dépendance avec un composant extérieur à l'environnement virtuel, il y a un risque potentiel de conflit quand cet environnement est cloné.  Dans cette section, nous allons examiner deux cas dans lesquels de tels conflits se produisent couramment.  

Conflits Active Directory

Il est courant pour les ordinateurs et les applications Windows de dépendre d'Active Directory (AD) pour leurs services d'annuaire ou pour l'authentication et l'autorisation utilisateur.  La gestion centrale des ordinateurs Windows à l'aide de stratégies de groupe Active Directory est une pratique très courante.  Pour reprendre notre exemple, supposons que le web-server et le db-server de l'environnement d'origine soient joints à un domaine géré par Active Directory.  Active Directory est hébergé en dehors de l'environnement.  Quand nous clonons cet environnement, nous disposons de deux clones identiques de web-server. Toutefois, seule une entrée est présente dans Active Directory.  Cela n'est bien sûr pas souhaitable et peut être à l'origine de plusieurs problèmes.  Par exemple, si l'un des clones web-server est disjoint du domaine par une action d'un utilisateur, l'autre clone sera également disjoint.  Les modifications apportées à un environnement affecteront également l'autre environnement.  

Pour éviter les conflits Active Directory, un serveur Active Directory doit être hébergé sur un ordinateur virtuel au sein de l'environnement.  Le serveur Active Directory ne doit pas posséder de relations d'approbation avec des répertoires extérieurs à l'environnement.  

D'autres éléments doivent être pris en considération pour la configuration d'un serveur Active Directory au sein d'un environnement isolé du réseau.  D'abord, l'ordinateur Active Directory ne doit pas être connecté au réseau public.  Pour la méthode des deux interfaces, cela signifie que l'ordinateur Active Directory ne doit pas avoir d'interface publique.  Pour la méthode de la NAT bidirectionnelle, cela signifie que la table NAT ne doit pas contenir de mappage pour l'ordinateur virtuel Active Directory.  

Ensuite, étant donné qu'Active Directory se trouve dans une forêt indépendante, un serveur DNS doit se trouver dans l'environnement.  Les autres ordinateurs virtuels de l'environnement doivent utiliser ce serveur DNS sur le réseau privé pour pouvoir communiquer correctement avec Active Directory.  Par exemple, un ordinateur virtuel peut ne pas pouvoir joindre le domaine de l'Active Directory privé, à moins que le paramètre du serveur DNS ne soit correctement configuré dans l'interface privée.  

Quand vous configurez un environnement de façon à inclure un ordinateur virtuel Active Directory, Visual Studio Lab Management procède de manière automatique à la déconnexion d'Active Directory du réseau public, ainsi qu'à la configuration des interfaces privées des ordinateurs virtuels à l'aide des paramètres DNS.

Dans certaines situations, l'hébergement d'Active Directory dans un environnement peut ne pas être possible.  Par exemple, cela pourrait être le cas si une application en cours de développement doit utiliser un Active Directory d'entreprise pour son intégration aux autres applications d'entreprise existantes.  Il n'existe aucune solution connue permettant un clonage d'environnements sécurisé quand des ordinateurs sont joints à un domaine extérieur à l'environnement.  

Conflits de bases de données

Une autre utilisation courante des environnements virtuels est l'hébergement de la base de données d'une application en dehors de l'environnement.  En général, cette méthode est utilisée quand la base de données est de taille importante et quand il n'est pas pratique de cloner la base de données dans chaque environnement.  Elle est également utilisée quand une application en cours de développement est un simple client web qui interagit avec une base de données hébergée autre part.  Dans ces cas-là, quand deux clones identiques interagissent avec la base de données, le serveur de base de données est incapable de distinguer l'identité des deux clients.  

Résumé

La capacité à créer des clones identiques d'un environnement virtuel est essentielle pour plusieurs scénarios de gestion de laboratoires virtuels.  Cependant, quand des clones identiques sont créés, des conflits de noms d'ordinateurs et d'adresses IP et MAC apparaissent.  Les techniques simples (comme modifier les noms d'ordinateurs ou les adresses IP) qui permettent de résoudre ces conflits nécessitent généralement une reconfiguration ou une réinstallation de l'application et décourage la création de clones identiques.  L'isolement réseau résout ce problème en vous permettant de créer et d'exécuter deux clones simultanément.  

Étapes suivantes

Organiser un environnement SCVMM : découvrez comment utiliser les différentes options disponibles pour les environnements SCVMM, comme l'utilisation d'ordinateurs virtuels en cours d'exécution, d'ordinateurs virtuels stockés, de modèles, d'environnements stockés et de l'isolement réseau.  Voir Guide pour créer et gérer des environnements SCVMM.  

Créer un environnement isolé du réseau : utilisez cette rubrique quand vous êtes prêt à créer un environnement isolé du réseau.  Voir Création et utilisation d'un environnement isolé du réseau.  

Voir aussi

Automatiser des tests système