Klonen von virtuellen Computern über die Netzwerkisolation

 

Veröffentlicht: Juli 2016

Virtuelles Lab Management ist ein im Wachstum begriffener Bereich in den Lebenszyklen der Softwareentwicklung. Visual Studio Lab Management ist ein Produkt in Visual Studio, das Entwicklern und Testern virtuelles Lab Management bereitstellt. Mithilfe von Visual Studio Lab Management können Entwicklungsteams die Virtualisierungstechnologie in der Entwicklung und in Testumgebungen nutzen, um komplexe Umgebungen mit mehreren Ebenen aus virtuellen Computern zu bilden. Sie können dann Anwendungsbuilds bereitstellen und Tests in diesen Umgebungen ausführen.

Einer der Beweggründe für die Verwendung der Virtualisierung in Entwicklung und Testumgebung ist, dass Duplikate bzw. Klone von bereitgestellten virtuellen Computern erstellt werden können, indem nur einige Dateien kopiert werden. Klonen ist in vielen Szenarien nützlich. So kann z. B. ein Entwickler, der eine Kopie der Umgebung eines Testers zum Reproduzieren eines Problems benötigt, einen Klon dieser Umgebung erstellen. In einem Testteam kann jeder einzelne Tester eine Kopie einer Umgebung klonen und den Testaufwand dann mit dem Rest des Teams koordinieren. Das Klonen spart Zeit für Entwickler und Tester, da sie Betriebssysteme und andere Software nicht wiederholt in jeder Umgebung installieren müssen, die sie erstellen.

Anforderungen

• Visual Studio Enterprise, Visual Studio Test Professional

Obwohl es einfach ist, eine virtuelle Umgebung zu klonen, gibt es Folgen des Klonens, die berücksichtigt werden müssen. Computer in einer geklonten Umgebung haben dieselben Computernamen wie die Computer in der ursprünglichen Umgebung. In einigen Fällen können die IP-Adressen und MAC-Adressen sogar identisch sein. Dies kann dazu führen, dass einer der Klone die Netzwerkverbindung verliert oder dass der für einen Klon bestimmte Netzwerkdatenverkehr stattdessen den anderen erreicht. Schließlich kann eine unbeabsichtigte Folge sein, dass Sie einem bestimmten Klon eine Anwendung bereitstellen, den Test jedoch auf dem anderen Klon durchführen.

Hinweis

Sie können die Netzwerkisolation nur mit SCVMM-Umgebungen verwenden.Diese Funktion ist für Standardumgebungen nicht verfügbar.

Visual Studio Lab Management löst diese Probleme und erleichtert sicheres Klonen von virtuellen Umgebungen über eine Technologie, der sogenannten Netzwerkisolation. In diesem Thema wird die Funktionsweise der Netzwerkisolation erläutert und das Klonen mit und ohne Netzwerkisolation verglichen. Im ersten Beispiel werden die verschiedenen Formen von Konflikten beschrieben, die zwischen Klonen in Ermangelung der Netzwerkisolation auftreten können. In nachfolgenden Beispielen werden mehrere Lösungen zum Verhindern von Konflikten mit der Verwendung von Visual Studio Lab Management untersucht.

Netzwerkkonflikte

Abbildung 1 zeigt eine typische virtuelle Umgebung, die Sie mit Lab Management erstellen können. Diese Umgebung, genannt "ursprüngliche Umgebung", hat zwei virtuelle Computer: "web-server" und "db-server". Diese Computer erfüllen die Rollen des Webservers bzw. des Datenbankservers in einer Webanwendung mit drei Ebenen. In diesem Beispiel wird angenommen, dass ein Mitglied des Entwicklungsteams diese Umgebung erstellt und den neuesten Build der Webanwendung dort bereitgestellt hat. Es wird außerdem vorausgesetzt, dass eine als neuester Build bezeichnete Momentaufnahme von dieser Umgebung nach Bereitstellung des Builds erstellt wurde. Eine Momentaufnahme ist ein Zustand der Umgebung zu einem bestimmten Zeitpunkt. Sie können jederzeit diesen gespeicherten Zustand wiederherstellen und die Ausführung ab diesem gespeicherten Zustand fortsetzen. Die Abbildung zeigt die Computernamen, IP-Adressen und MAC-Adressen der zwei virtuellen Computer in der ursprünglichen Umgebung.

Ursprüngliche Umgebung

Abbildung 2 zeigt eine geklonte Umgebung und dazu die ursprüngliche Umgebung. Die folgenden Typen von Netzwerkkonflikten können auftreten, wenn beide Umgebungen nach dem Klonen gestartet werden:

1. Computernamenskonflikte

2. IP-Adressenkonflikte

3. MAC-Adressenkonflikte

Ursprüngliche und geklonte Umgebung in einem Netzwerk

Das genaue Ergebnis jedes dieser Konflikte hängt von mehreren Faktoren ab, u. a. vom Betriebssystem der virtuellen Computer und von der Netzwerkinfrastruktur im Lab. In Abbildung 2 wurde vorausgesetzt, dass eine statische IP-Adresse und eine statische MAC-Adresse auf jedem virtuellen Computer der ursprünglichen Umgebung konfiguriert wurden. Daher hatten die geklonten virtuellen Computer, als die Umgebung geklont wurde, dieselben IP- und MAC-Adressen.

Computernamenskonflikte

Ein Computername ist ein von einem Benutzer zugewiesener Anzeigename zur Identifizierung des Computers im Netzwerk. In der Regel werden zwei Protokolle zum Auflösen eines Computernamens in die entsprechende IP-Adresse verwendet: NetBIOS und Domain Name Server (DNS). Wenn zwei Computer mit demselben Computernamen im selben Netzwerksegment gestartet werden, erkennt NetBIOS den Namenskonflikt und warnt den Benutzer. Normalerweise kann NetBIOS Konflikte nur erkennen, wenn sich die Computer im selben Netzwerksegment befinden. Wenn sich die Computer nicht im selben Netzwerksegment befinden, oder wenn die Warnungen ignoriert werden, tritt die nächste Ebene von Konflikten in DNS auf. DNS ist ein zentrales Repository, in dem Namen für Computer registriert werden. Wenn zwei Computer mit demselben Computernamen versuchen, sich in DNS zu registrieren, kann der zweite Computer ggf. den vom ersten Computer erstellten Eintrag überschreiben. In diesem Fall ist der erste Computer, der gestartet wird, über die Namensauflösung nicht erreichbar.

Computernamenskonflikte lassen sich leicht vermeiden oder korrigieren. Anstatt identische Kopien von Umgebungen zu erstellen, können Sie jeden Klon beim Erstellen mit einem Mechanismus namens "sysprep" anpassen. Sysprep ist Teil der Windows-Betriebssysteme. Wenn Sie mit sysprep Umgebungen klonen, erhalten alle virtuellen Computer der Umgebung jeweils eindeutige Computernamen, IP-Adressen und MAC-Adressen, die sich von denen in der ursprünglichen Umgebung unterscheiden. Die Klone sind jedoch nicht mehr identisch.

Welche Auswirkungen ein eindeutiger Computernamen in jedem Klon hat, hängt unabhängig davon, ob dies durch sysprep oder durch manuelles Eingreifen des Benutzers erfolgte, um Konflikte zu vermeiden, von der Software ab, die auf dem virtuellen Computer installiert ist. Betrachten Sie zum besseren Verständnis folgendes Beispiel. Bei Bereitstellung der Anwendung in der Umgebung wurde eine web.config-Datei auf dem Webserver erstellt. In dieser Datei wurde der Computername db-server als Teil der Verbindungszeichenfolge konfiguriert. Ein Ausschnitt dieser Datei wird im Folgenden dargestellt:

<?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>

Wenn der Computername des Datenbankservers in der geklonten Umgebung geändert wird, muss auch die web.config-Datei manuell wie folgt geändert werden, um den neuen Namen zu verwenden (db-server2 ist der neue Computername für den virtuellen Computer in der geklonten Umgebung).

<?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>

Außerdem sind für SQL Server zusätzliche Schritte erforderlich, wenn der Computername geändert wird. Ein Ausschnitt des SQL-Skripts zu diesem Zweck wird im Folgenden dargestellt:

sp_dropserver db-server
sp_addserver db-server2, local
GO

Im vorhergehenden Beispiel wurde gezeigt, wie eine Anwendung konfiguriert werden muss, wenn Computernamen geändert werden. Verständlicherweise ist diese Prozedur anwendungsabhängig. Wenn die Computernamen von einer Anwendung in eine Datenbank eingetragen werden, müssen diese Einträge auf ähnliche Weise geändert werden. In einigen Fällen müssen Sie eine Anwendung neu installieren, wenn der Computername geändert wird. In erster Linie wollten wir aber mit dem Klonen genau das vermeiden, nämlich Konfigurationen und Installationen erneut auszuführen. Dafür ist eine robustere anwendungsunabhängige Lösung erforderlich, mit der gefahrlos mehrere Klone gleichzeitig vorhanden sein können, ohne dass Computernamenskonflikte auftreten.

IP-Adressenkonflikte

Eine Internetprotokoll- oder IP-Adresse wird verwendet, damit Computer miteinander über ein TCP-Netzwerk kommunizieren können. IP-Adressen werden entweder statisch oder dynamisch durch einen DHCP-Server im Netzwerk zugewiesen. Jede verbundene Netzwerkschnittstelle eines Computers hat eine IP-Adresse. Wenn ein mit einer statischen IP-Adresse konfigurierter virtueller Computer geklont und anschließend im selben Netzwerk wie der ursprüngliche virtuelle Computer platziert wird, treten ein IP-Adressenkonflikt und zusätzlich ein Computernamenkonflikt auf. Sie können diesen Konflikt manuell korrigieren, indem Sie die IP-Adresse eines der Klone ändern. Welche Auswirkungen also die Änderung der IP-Adresse hat, hängt davon ab, wie die statische IP-Adresse von Anwendungen verwendet wird, die auf virtuellen Computern installiert sind.

Wenn Sie mit dem Klonen eines virtuellen Computers beginnen, der mit einer dynamischen IP-Adresse konfiguriert ist, tritt für kurze Zeit ein Netzwerkkonflikt auf. Kurz nach dem Klonen des ersten virtuellen Computern erkennt der zweite virtuelle Computer, der mit dem Netzwerk verbunden wird, diesen Konflikt und behebt ihn, indem er seine IP-Adresse erneuert. Eine ähnlich kurze Konfliktperiode ist immer dann vorhanden, wenn die geklonte Umgebung von einer Momentaufnahme wiederhergestellt wird, die in der ursprünglichen Umgebung erstellt wurde. Diese Konfliktperioden sind normalerweise nicht lang genug, um die Anwendung zu beeinflussen.

MAC-Adressenkonflikte

Eine Media Access Control- oder MAC-Adresse ist eine Adresse, die jeder Netzwerkschnittstelle eines Computers zugewiesen wird. Im Fall physischer Computer wird sie jeder Netzwerkschnittstellenkarte durch den Hersteller der Karte zugewiesen. Im Fall virtueller Computer gibt es zwei Möglichkeiten für die Zuweisung von MAC-Adressen: statische oder dynamische MAC-Adressen. Sie können eine bestimmte MAC-Adresse angeben, die für eine Netzwerkschnittstelle eines virtuellen Computers verwendet werden soll. Das ist eine sogenannte statische MAC-Adresse. Sie können eine MAC-Adresse aber auch vom Hypervisor dynamisch zuweisen lassen. Das ist eine sogenannte dynamische MAC-Adresse. Dynamische MAC-Adressen werden durch Hyper-V aus einem Pool von MAC-Adressen bei jedem Start eines virtuellen Computers zugewiesen. Jeder Host verfügt über ein Schema zum Generieren von MAC-Adressen, damit sie keine Konflikte mit den virtuellen Computern auf anderen Hosts verursachen.

Wenn statische MAC-Adressen für virtuelle Computer in der ursprünglichen Umgebung verwendet werden, erhalten virtuelle Computer in der geklonten Umgebung dieselben MAC-Adressen. Dies führt sofort zu MAC-Konflikten. Doppelte MAC-Adressen sind schwerer zu erkennen, da sie von den Computern nicht immer gemeldet werden. Auch wenn sie gemeldet werden, werden solche Meldungen in der Windows-Ereignisanzeige protokolliert. Für Endbenutzer können doppelte MAC-Adressen zwei Konsequenzen haben. Die eine Konsequenz ist der Verlust der Netzwerkverbindung auf einem Klon oder auf beiden Klonen. Ein weitere Konsequenz ist, dass an einen Computer adressierte Netzwerkpakete stattdessen den anderen Computer erreichen können. Wenn ein ursprünglicher Computer und sein Klon dieselbe MAC-Adressen haben, sind auch deren IP-Adressen identisch. Auch wenn DHCP zum Abrufen von dynamischen IP-Adressen verwendet wird, werden ihnen vom DHCP-Server dieselben IP-Adressen zugewiesen, da die MAC-Adressen identisch sind.

Bis zu einem gewissen Grad können Sie MAC-Konflikte vermeiden, indem Sie dynamische MAC-Adressen verwenden. Wenn die geklonte Umgebung von einer Momentaufnahme wiederhergestellt wird, die in der ursprünglichen Umgebung erstellt wurde, wird der gesamte Zustand dieser virtuellen Computer zurückgesetzt, auch die MAC-Adressen. Dies führt wiederum zu MAC-Konflikten, und die gleichen oben beschriebenen Probleme bestehen, bis der geklonte virtuelle Computer neu gestartet wird. Der Neustart der geklonten Umgebung veranlasst den Hypervisor, die MAC-Adressen freizugeben und mit Werten aus dem eigenen Gültigkeitsbereich zu erneuern.

Es ist wichtig, zeitaufwendig und für zahlreiche Benutzer von virtuellem Lab Management fehleranfällig, die oben beschriebenen Formen von Konflikten zu erkennen, zu lösen und dann das Betriebssystem bzw. die Anwendung manuell zu korrigieren, um nach der Lösung weiterhin zu funktionieren. In vielen Fällen wird durch das Ändern eines dieser Parameter die virtuelle Umgebung soweit geändert, dass Fehler nicht reproduziert werden oder ein ähnliches Problem mit der Produktionsumgebung auftritt. Das Prinzip, die Anwendung einmal in einer virtuellen Umgebung zu installieren und dann diese Umgebung problemlos zu klonen, um mehrere identische Kopien zu erstellen, erfordert eine anspruchsvollere Vorgehensweise, als von normalen Benutzern erwartet werden kann.

Netzwerkisolation

Bis jetzt wurden zwei Anforderungen identifiziert. Die erste Anforderung besteht darin, dass virtuelle Computer in einer geklonten Umgebung dieselben Computernamen, IP-Adressen und MAC-Adressen wie die in der ursprünglichen Umgebung haben müssen. Aber gleichzeitig müssen diese Klone von außerhalb der Umgebung unabhängig adressierbar sein. Dies ist beispielsweise erforderlich für Benutzer, damit sie sich mit jedem der Klone über die Desktops verbinden können, für Anwendungen, damit sie auf einem bestimmten Klon bereitgestellt werden, oder für Tests, damit sie auf einem bestimmten Klon ausgeführt werden. Dies führt zur zweiten Anforderung, die darin besteht, dass die virtuellen Computer in einer geklonten Umgebung auch eindeutige Computernamen, IP-Adressen und MAC-Adressen haben müssen, die sich von denen in der ursprünglichen Umgebung unterscheiden. Um diese beiden Anforderungen zu erfüllen, muss jeder virtuelle Computer logischerweise über zwei Schnittstellen verfügen: eine private Schnittstelle, deren Computername, IP-Adresse und MAC-Adresse in jedem Klon gleich sind, und eine öffentliche Schnittstelle, deren Werte dafür in jedem Klon eindeutig sind.

Um Netzwerkkonflikte bei den privaten Schnittstellen zu verhindern, müssen sie mit einem privaten Netzwerk in jedem Klon verbunden werden. Ein privates Netzwerk ist ein virtuelles Netzwerk, das auf die virtuellen Computer in einer Umgebung beschränkt ist. Da dieses Netzwerk nicht über die Grenzen einer Umgebung hinaus verfügbar gemacht wird, können selbst dann keine Konflikte auftreten, wenn dieselben Computernamen, IP-Adressen und MAC-Adressen in einem anderen Klon verwendet werden. Für einen Zugriff von außerhalb der Umgebung müssen alle öffentlichen Schnittstellen mit einem allgemeinen öffentlichen Netzwerk verbunden werden. Das öffentliche Netzwerk oder Lab-Netzwerk ist das Netzwerk, in dem virtuelle Computer von Umgebungen mit Clients und anderen Computern im Lab interagieren können.

Abbildung 3 zeigt, wie private und öffentliche Schnittstellen mit Netzwerkkonflikten umgehen.

Netzwerkisolation in Visual Studio Lab Management

Visual Studio Lab Management implementiert Netzwerkisolation für SCVMM-Umgebungen durch Einführung von zwei Netzwerkschnittstellen auf jedem virtuellen Computer. Eine dieser Netzwerkschnittstellen ist eine private Schnittstelle, die mit einem privaten Netzwerk verbunden ist, und die andere ist eine öffentliche Schnittstelle, die mit dem öffentlichen Netzwerk verbunden ist.

Die Lab Management-Software stellt zusammen mit einem auf jedem virtuellen Computer installierten Agent sicher, dass die ursprüngliche Umgebung und die geklonte Umgebung ohne Konflikte gleichzeitig vorhanden sein können.

Private Schnittstellen in privatem Netzwerk

Nachfolgend wird zusammenfassend beschrieben, wie Computernamen, IP-Adressen und MAC-Adressen privaten Schnittstellen in einer Umgebung zugewiesen werden.

Computernamen: Computernamen im privaten Netzwerk werden mit NetBIOS aufgelöst. Sie benötigen keine zusätzliche Behandlung durch Lab Management-Software. Anwendungen, die für das Arbeiten mit NetBIOS-Computernamen konfiguriert sind, werden in jedem Klon erwartungsgemäß funktionieren. Im vorliegenden Beispiel verweist der Computer "web-server" anhand des Namens auf den Computer "db-server". Diese Namen sind in der ursprünglichen und geklonten Umgebung identisch. Folglich muss die Datei "web.config" in der geklonten Umgebung nicht geändert werden.

Da es keinen DNS-Server im privaten Netzwerk gibt, muss die Situation angesprochen werden, wenn virtuelle Computer vollqualifizierte Domänennamen (FQDN) statt NetBIOS-Namen für die gegenseitige Referenzierung verwenden. Wenn z. B. in der Datei "web.config" auf den Computer "db-server" als db-server.lab.contoso.com verwiesen wird, ist die Auflösung dieses Namens in eine IP-Adresse nicht ohne DNS im privaten Netzwerk möglich. Um dieses Problem zu lösen, fügt der auf dem virtuellen Computer ausgeführte Lab-Agent Einträge hinzu, die den anderen virtuellen Computern derselben Umgebung in der Hostdatei entsprechen. Die Hostdatei ist eine weitere Möglichkeit, dem Betriebssystem zu signalisieren, dass ein Name in eine bestimmte IP-Adresse aufgelöst werden muss. In diesem Beispiel enthält die Hostdatei auf web-server den folgenden Eintrag:

192.168.23.2 db-server.lab.contoso.com

IP-Adressen: Der Schnittstelle des privaten Netzwerks jedes virtuellen Computers wird eine statische IP-Adresse im Bereich von 192.168.23.1 bis 255 zugewiesen. So wird z. B. der privaten Schnittstelle von web-server 192.168.23.1 und der privaten Schnittstelle von db-server 192.168.23.2 zugewiesen. Mit Lab Management wird sichergestellt, dass web-server und db-server dieselben statischen IP-Adressen in jedem Klon erhalten. Selbst wenn die web.config-Datei auf dem Webserver mit der IP-Adresse von db-server konfiguriert wird, muss sie in der geklonten Umgebung nicht neu konfiguriert werden. In jeder mit Netzwerkisolation konfigurierten Umgebung erhalten die privaten Schnittstellen IP-Adressen desselben Bereichs, beginnend mit 192.168.23.1. Die maximale Anzahl von Adressen, die in diesem Bereich erforderlich sind, entspricht der maximalen Anzahl von virtuellen Computern in einer Umgebung. Da dieser Satz IP-Adressen von außerhalb des privaten Netzwerks nicht routingfähig ist, kann gefahrlos ein vordefinierter Bereich verwendet werden, solange derselbe Bereich nicht im öffentlichen Netzwerk verwendet wird.

MAC-Adressen: Eine zufällige statische MAC-Adresse wird der Schnittstelle des privaten Netzwerks jedes virtuellen Computers in einer netzwerkisolierten Umgebungen zugewiesen. Im vorliegenden Beispiel wird der privaten Schnittstelle im ursprünglichen Webserver eine MAC-Adresse wie 00-15-5D-07-57-01 zugewiesen. Mit Lab Management wird sichergestellt, dass dieser Webserver dieselbe MAC-Adresse auch in der geklonten Umgebung erhält. Da diese MAC-Adressen von außerhalb des privaten Netzwerks nicht routingfähig sind, können bedenkenlos zufällige Adressen verwendet werden, solange sie nicht im vom Hypervisor auf diesem Host verwendeten Bereich liegen.

Öffentliche Schnittstellen im öffentlichen Netzwerk

Nachfolgend wird zusammenfassend beschrieben, wie Computernamen, IP-Adressen und MAC-Adressen öffentlichen Schnittstellen in einer Umgebung zugewiesen werden.

Computernamen: NetBIOS soll die Computernamen im öffentlichen Netzwerk nicht auflösen, da dies zu einem Computernamenskonflikt führen würde. Um dies zu verhindern, deaktiviert Lab Management NetBIOS-Übertragungen auf der öffentlichen Schnittstelle jedes virtuellen Computers. Ähnlich wie bei NetBIOS sollen NetBIOS-Computernamen der virtuellen Computer nicht in DNS registriert werden. Lab Management deaktiviert auch die DNS-Registrierung für jede öffentliche Schnittstelle. In Ermangelung von NetBIOS und standardmäßiger DNS-Registrierung, sollen die virtuellen Computer doch eindeutige Namen haben, die in einem öffentlichen Netzwerk verwendet werden können. Lab Management generiert einen eindeutigen Aliasnamen für jeden virtuellen Computer und registriert ihn als "A"-Datensatz in DNS. In unserem Beispiel könnte web-server in der ursprünglichen Umgebung mit einem eindeutigen Aliasnamen der Art VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com registriert werden. Der gleiche Webserver in der geklonten Umgebung wird mit einem anderen Namen der Art VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com registriert.

IP-Adressen: Die Schnittstelle des öffentlichen Netzwerks in jedem virtuellen Computer wird zum Abrufen einer dynamischen IP-Adresse von einem DHCP-Server konfiguriert. Dadurch wird sichergestellt, dass virtuelle Computer in der ursprünglichen und geklonten Umgebung eindeutige IP-Adressen haben. Beispielsweise könnte web-server in der ursprünglichen Umgebung die IP-Adresse 172.52.20.140 und der gleiche Webserver in der geklonten Umgebung die IP-Adresse 172.52.20.205 erhalten.

MAC-Adressen: Die Schnittstelle des öffentlichen Netzwerks auf jedem virtuellen Computer kann zum Abrufen dynamischer MAC-Adressen vom Hypervisor konfiguriert werden, um MAC-Konflikte zu verhindern. Dadurch wird sichergestellt, dass der Computer "web-server" im vorliegenden Beispiel in der ursprünglichen und in der geklonten Umgebung eine andere MAC-Adresse erhält. Wenn jedoch, wie zuvor beschrieben, eine geklonte Umgebung von einer Momentaufnahme wiederhergestellt wird, die in der ursprünglichen Umgebung erstellt wurde, übernehmen die MAC- und die IP-Adresse des geklonten virtuellen Computers die gleichen Werte wie das Original. Wenn z. B. die geklonte Umgebung von der Momentaufnahme des neuesten Builds wiederhergestellt wird, erhält web-server die IP-Adresse 10.86.51.61 (siehe Abbildung 3), also den gleichen Wert wie in der ursprünglichen Umgebung. Gleiches gilt für die MAC-Adresse. Während der IP-Adressenkonflikt temporär ist, bis die IP-Adresse von DHCP erneuert wird, bleibt der MAC-Konflikt bestehen, bis die virtuellen Computer neu gestartet werden. Wegen dieser Einschränkung ist das Verwenden dynamisch zugewiesener MAC-Adressen vom Hypervisor für öffentliche Schnittstellen keine praktikable Lösung.

Um dieses Problem zu beheben, verwendet Lab Management einen eigenen MAC-Adressenpool. Eindeutige MAC-Adressen aus diesem Pool werden den öffentlichen Schnittstellen von virtuellen Computern zugewiesen. Immer wenn die geklonte Umgebung von einer Momentaufnahme wiederhergestellt wird, ändert Lab Management die MAC-Adressen automatisch, um Konflikte zu verhindern. Um zu verstehen, wie dies funktioniert, berücksichtigen Sie, dass die MAC-Adresse von web-server in der ursprünglichen Umgebung 1D-D8-B7-1C-00-05 und die MAC-Adresse von web-server in der geklonten Umgebung 1D-D8-B7-1C-00-07 ist. Wenn die geklonte Umgebung von einer in der ursprünglichen Umgebung erstellten Momentaufnahme wiederhergestellt wird, erhält die MAC-Adresse von web-server vorübergehend den Wert 1D-D8-B7-1C-00-05. Lab Management ändert diesen zurück in 1D-D8-B7-1C-00-07, um Netzwerkkonflikte zu verhindern.

Typische Interaktionen mit Netzwerkisolation

Als Nächstes wird erörtert, was geschieht, wenn zwei virtuelle Computer in der Umgebung miteinander kommunizieren:

1. Web-server verwendet NetBIOS oder die HOSTS-Datei, um den Computernamen db-server in die IP-Adresse der privaten Schnittstelle von db-server (192.168.23.2) aufzulösen.

2. Web-server kommuniziert mit db-server unter dieser IP-Adresse.

Wenn ein Client außerhalb der Umgebung mit web-server in einer geklonten Umgebung kommunizieren muss, wird folgender Prozess durchlaufen:

1. Der Client führt eine Abfrage an die Lab Management-Software durch, um den eindeutigen Aliasnamen von web-server in der geklonten Umgebung zu erhalten.

2. Die Lab Management-Software gibt als Antwort den eindeutigen Aliasnamen zurück.

3. Der DNS-Server löst den eindeutigen Aliasnamen in die IP-Adresse der öffentlichen Schnittstelle von web-server (10.86.51.63) auf.

4. Der Client kommuniziert mit web-server unter dieser IP-Adresse.

Alternative Ansätze für Netzwerkisolation

Die Verwendung von zwei Schnittstellen ist nicht der einzige Ansatz für Netzwerkisolation. Ein sehr ähnlicher Ansatz besteht in der Verwendung einer bidirektionalen NAT. NAT ist ein allgemeiner Ansatz zum Erstellen eines privaten Netzwerks mit Geräten, die mit Geräten in einem öffentlichen Netzwerk kommunizieren müssen. Obwohl die Kommunikation in einem typischen NAT immer vom privaten Netzwerk ausgehen muss, geht bidirektionales NAT (oder Two-Way NAT) in dieser Hinsicht einen Schritt weiter und ermöglicht die Initiierung der Kommunikation von Computern im privaten Netzwerk oder Computern im öffentlichen Netzwerk.

Zum Realisieren der Netzwerkisolation mithilfe dieses Ansatzes muss ein Two-Way NAT-Server in die Umgebung bereitgestellt werden. Dazu wird normalerweise ein spezieller virtueller Computer der Umgebung hinzugefügt, der nur die Rolle eines bidirektionalen NAT-Servers erfüllt. Wenn eine netzwerkisolierte Umgebung erstellt wird, werden die öffentlichen und privaten IP-Adressen der virtuellen Computer ebenso wie im Ansatz der Verwendung von zwei Schnittstellen zugewiesen. Anstatt jedoch die öffentliche IP-Adresse einer Netzwerkschnittstelle im virtuellen Computer zuzuweisen, werden die Zuordnungen in einer NAT-Tabelle auf dem Two-Way NAT-Server gespeichert.

Die Schritte, die zwei virtuelle Computer in der Umgebung durchlaufen müssen, um mithilfe des Two-Way NAT-Ansatzes zu kommunizieren, sind dieselben wie im Ansatz der Verwendung von zwei Schnittstellen:

1. Web-server verwendet NetBIOS oder die HOSTS-Datei, um den Computernamen db-server in die IP-Adresse der privaten Schnittstelle von db-server (192.168.23.2) aufzulösen.

2. Web-server kommuniziert mit db-server unter dieser IP-Adresse.

Wenn ein Client außerhalb der Umgebung mit web-server in der geklonten Umgebung kommunizieren muss, sind leicht abgewandelte Schritte erforderlich:

1. Bei Implementierung des NAT-Ansatzes führt der Client eine Abfrage an die Lab Management-Software durch, um den eindeutigen Aliasnamen von web-server in der geklonten Umgebung zu ermitteln. (Der NAT-Ansatz wird von Visual Studio Lab Management nicht implementiert).

2. Die Lab Management-Software gibt als Antwort den eindeutigen Aliasnamen zurück.

3. Der DNS-Server löst den eindeutigen Aliasnamen in die öffentliche IP-Adresse von web-server auf (10.86.51.63).

4. Diese IP-Adresse ist tatsächlich einer Schnittstelle im Two-Way NAT-Server zugeordnet. Der Client kommuniziert mit dem Two-Way NAT-Server in der Annahme, dass er mit web-server kommuniziert.

5. Der NAT-Server ruft die in den Konfigurationstabellen gespeicherten Zuordnungen ab und übersetzt die öffentliche IP-Adresse (10.86.51.63) in die private IP-Adresse (192.168.23.1).

6. Der NAT-Server leitet die Nachricht vom Client im privaten Netzwerk an 192.168.23.1 weiter, der IP-Adresse von web-server.

Der Vorteil dieses Ansatzes gegenüber dem Ansatz der Verwendung von zwei Schnittstellen besteht darin, dass die virtuellen Computer in der Umgebung in keiner Weise geändert werden müssen. Es ist nicht erforderlich, eine zusätzliche Netzwerkschnittstelle auf jedem virtuellen Computer bereitzustellen. Das Bereitstellen einer zusätzlichen Netzwerkschnittstelle auf einem virtuellen Computer kann bei einigen Anwendungen Unterbrechungen verursachen.

Ein weiterer Vorteil dieses Ansatzes besteht darin, dass die gesamte Logik zum Erreichen der Netzwerkisolation im zusätzlichen virtuellen Computer gekapselt wird. Es wird kein Agent in jedem der anderen virtuellen Computer benötigt. Das Routing aller Pakete über den zusätzlichen virtuellen Computer bietet zudem einen zusätzlichen Kontrollpunkt, um komplexere Funktionen der Netzwerkisolation zu unterstützen, so z. B.:

• Außenumgrenzung: Lässt nicht zu, dass virtuelle Computer in der Umgebung von Clients außerhalb der Umgebung initiierte Netzwerkpakete erhalten.

• Außenumgrenzung mit Ausnahme bestimmter Ports: Lässt nicht zu, dass virtuelle Computer in der Umgebung von Clients außerhalb der Umgebung initiierte Netzwerkpakete erhalten, es sei denn, ihr Ziel ist ein bestimmter Port.

Diese Funktionen können im Two-Way NAT-Ansatz leicht implementiert werden, indem eine Firewall auf dem NAT-Server bereitgestellt wird. Der primäre Nachteil des Two-Way NAT-Ansatzes besteht darin, dass einige Anwendungen nicht über NAT arbeiten. Beispielsweise funktionieren DCOM- und .NET-Remotingprotokolle, die in Windows-Anwendungen häufig verwendet werden, nicht, wenn Client und Server durch einen NAT-Server getrennt sind. Aus diesem Grunde verwendet Visual Studio Lab Management den Ansatz der dualen Schnittstellen. Ein weiterer Nachteil des Two-Way NAT-Ansatzes besteht darin, dass ein zusätzlicher virtueller Computer in jeder Umgebung erforderlich ist. Dies verursacht einen Mehraufwand bei der Erstellung oder bei anderen Vorgängen in virtuellen Umgebungen.

Andere Konflikte

Bisher wurde beschrieben, wie Konflikte mit Computernamen, IP-Adressen und MAC-Adressen mithilfe der Netzwerkisolation behandelt werden können. Wenn Umgebungen geklont werden, können auch noch andere Formen von Konflikten auftreten. Sobald eine Abhängigkeit von einer externen Komponente besteht, die sich außerhalb der virtuellen Umgebung befindet, kann potenziell ein Konflikt auftreten, wenn diese Umgebung geklont wird. In diesem Abschnitt werden zwei allgemeine Fälle betrachtet, in denen diese Konflikte auftreten können.

Active Directory-Konflikte

In der Regel greifen Computer und Anwendungen unter Windows auf Active Directory (AD) entweder für Verzeichnisdienste oder für die Benutzerauthentifizierung und -autorisierung zurück. Die zentrale Verwaltung von Windows-Computern mithilfe von AD-Gruppenrichtlinien ist eine gängige Vorgehensweise. Nehmen wir im vorliegenden Beispiel an, dass web-server und db-server in der ursprünglichen Umgebung Teil einer Domäne sind, die durch AD verwaltet wird. AD wird außerhalb der Umgebung gehostet. Wenn diese Umgebung geklont wird, sind zwei identische Klone von web-server vorhanden, es gibt jedoch nur einen Eintrag in AD. Dies ist eindeutig nicht wünschenswert und kann zu verschiedenen Problemen führen. Wenn z. B. einer der Klone von web-server durch eine Benutzeraktion von der Domäne getrennt wird, wird auch der andere Klon getrennt. Änderungen, die in einer Umgebung vorgenommen werden, wirken sich ungewollt auf die andere Umgebung aus.

Um Active Directory-Konflikte zu verhindern, muss ein AD-Server auf einem virtuellen Computer in der Umgebung gehostet werden. Der AD-Server sollte keine Vertrauensstellungen mit anderen Verzeichnissen außerhalb der Umgebung haben.

Für die Einrichtung von AD in einer netzwerkisolierten Umgebung gelten einige weitere Überlegungen. Zunächst sollte der virtuelle AD-Computer nicht mit dem öffentlichen Netzwerk verbunden werden. Bezogen auf den Ansatz der Verwendung von zwei Schnittstellen bedeutet dies, dass der virtuelle AD-Computer keine öffentliche Schnittstelle haben sollte. Bezogen auf den Two-Way NAT-Ansatz bedeutet dies, dass die NAT-Tabelle keine Zuordnung für den virtuellen AD-Computer aufweisen sollte.

Da sich AD zweitens in einer unabhängigen Gesamtstruktur befindet, ist ein DNS-Server in der Umgebung erforderlich. Andere virtuelle Computer in der Umgebung müssen diesen DNS-Server im privaten Netzwerk für die ordnungsgemäße Kommunikation mit AD verwenden. Beispielsweise ist ein virtueller Computer möglicherweise nicht in der Lage, einer Domäne im privaten AD beizutreten, sofern die DNS-Servereinstellung auf der privaten Schnittstelle nicht ordnungsgemäß konfiguriert wird.

Wenn Sie eine Umgebung so konfigurieren, dass sie einen virtuellen AD-Computer umfasst, wird das Trennen eines AD vom öffentlichen Netzwerk und das Konfigurieren privater Schnittstellen von virtuellen Computern mit DNS-Einstellungen von Visual Studio Lab Management automatisiert.

Es kann Situationen geben, in denen das Hosten von AD in der Umgebung nicht möglich ist. Dies kann beispielsweise vorkommen, wenn die Anwendung in der Entwicklungsphase ein Unternehmens-AD zur Integration in andere vorhandene Unternehmensanwendungen verwenden muss. Es gibt keine bekannte Lösung, sicheres Klonen von Umgebungen zu ermöglichen, wenn die Computer mit einer Domäne außerhalb der Umgebung verknüpft sind.

Datenbankkonflikte

Häufig werden virtuelle Umgebungen verwendet, um die Datenbank der Anwendung außerhalb der Umgebung zu hosten. Dies wird in der Regel durchgeführt, wenn die Datenbank groß genug und es nicht praktikabel ist, die Datenbank mit jeder Umgebung zu klonen. Dies kann auch vorkommen, wenn die Anwendung in der Entwicklungsphase ein einfacher Webclient ist, der mit einer Datenbank interagiert, die an anderer Stelle gehostet wird. In solchen Fällen, in denen zwei identische Klone mit der Datenbank interagieren, ist der Datenbankserver nicht in der Lage, die Identität der zwei Clients zu unterscheiden.

Zusammenfassung

Die Möglichkeit, identische Klone von virtuellen Umgebungen zu erstellen, ist für einige Szenarien im virtuellen Lab Management von wesentlicher Bedeutung. Wenn identische Klone erstellt werden, treten jedoch Konflikte mit Computernamen, IP-Adressen und MAC-Adressen auf. Einfache Techniken zum Beheben dieser Konflikte, wie z. B. Ändern von Computernamen oder IP-Adressen, erfordern normalerweise eine Neukonfiguration oder -installation der Anwendung und vereiteln das Vorhaben, identische Klone zu erstellen. Mit Netzwerkisolation wird dieses Problem durch die Möglichkeit behoben, zwei Klone gleichzeitig erstellen und ausführen zu können.

Nächste Schritte

Planen von SCVMM-Umgebungen: Informieren Sie sich über die Verwendung der verschiedenen Optionen für SCVMM-Umgebungen, wie z. B. Verwenden von ausgeführten virtuellen Computern, gespeicherten virtuellen Computern, Vorlagen, gespeicherten Umgebungen und Netzwerkisolation. Siehe Leitfaden zum Erstellen und Verwalten von SCVMM-Umgebungen.

Erstellen einer netzwerkisolierten Umgebung: Verwenden Sie dieses Thema, wenn Sie bereit sind, eine netzwerkisolierte Umgebung zu erstellen. Siehe Erstellen und Verwenden einer netzwerkisolierten Umgebung.

Siehe auch

Automatisieren von Systemtests