次の方法で共有

ネットワークの分離を使用した仮想マシンの複製

  • [アーティクル]

仮想ラボ管理は、ソフトウェア開発ライフサイクルの発展途上の分野です。 Visual Studio Lab Management は、開発者およびテスト担当者による仮想ラボ管理を可能にする Visual Studio の製品です。 Visual Studio Lab Management を使用することで、開発チームは開発およびテスト ラボで仮想化テクノロジを利用して、仮想マシンから複雑な多階層環境を構築できます。 その後、アプリケーション ビルドをこれらの環境に配置してテストを実行できます。

開発およびテスト ラボで仮想化を使用する動機の 1 つは、数個のファイルをコピーするだけで、配置された仮想マシンの正確なコピー、つまり複製を作成できることです。 複製はさまざまなシナリオで役立ちます。 たとえば、問題を再現するためにテスト担当者の環境のコピーが必要な開発者は、その環境の複製を作成できます。 テスト チームでは、個々のテスト担当者は環境のコピーを複製できるので、自分のテスト作業量をチームの他のメンバーと調整できます。 作成された各環境へはオペレーティング システムと他のソフトウェアを繰り返しインストールする必要がないため、複製は、開発者とテスト担当者両方にとって時間の節約になります。

要件

  • Visual Studio Ultimate, Visual Studio Premium, Visual Studio Test Professional

仮想環境の複製は簡単ですが、複製の結果には考慮する必要があります。 複製された環境のコンピューターは、元の環境のコンピューターと同じ名前になります。 場合によっては、これらの IP アドレスと MAC アドレスが同じになる可能性があります。 これにより、一方の複製のネットワーク接続が失われたり、または一方の複製を対象としたネットワーク トラフィックがもう一方の複製に到達する可能性があります。 最終的に、一方の複製にアプリケーションを配置し、別の複製でテストを実行するという予期しない結果を招くおそれがあります。

注意

ネットワークの分離を使用できるのは、SCVMM 環境のみです。この機能は、標準環境には使用できません。

Visual Studio Lab Management は、ネットワークの分離と呼ばれるテクノロジを使用して、これらの問題を解決し、仮想環境の安全な複製を容易にします。 このトピックでは、ネットワークの分離のしくみを説明し、ネットワークの分離の有無による複製を比較します。 最初の例は、ネットワークが分離されていない場合に複製間で発生する可能性のあるさまざまな形式の競合を示します。 それ以降の例では、Visual Studio Lab Management を使用して競合を防ぐための複数のソリューションについて考えます。

ネットワークの競合

図 1 に、Lab Management を使用して作成できる一般的な仮想環境を示します。 元の環境と呼ばれるこの環境には、Web サーバーと db サーバーという 2 つの仮想マシンがあります。 これらのコンピューターは、3 層の Web アプリケーションでそれぞれ Web サーバーおよびデータベース サーバーの役割を果たします。 この例では、開発チームのメンバーがこの環境を作成し、その Web アプリケーションの最新ビルドを配置したと仮定します。 また、ビルドの配置後に最新のビルドと呼ばれるスナップショットがこの環境で作成されたことも前提としています。 スナップショットとは、特定の時点の環境の状態です。 この保存された状態からいつでも復元したり、実行を再開できます。 図では、元の環境にある 2 つの仮想マシンのコンピューター名、IP アドレス、および MAC アドレスを示します。

元の環境

元のホストの VM の 'web-server' と 'db-server'。

図 2 は、元の環境と複製された環境を示します。 複製を作成した後、両方の環境を開始すると、次の種類のネットワーク競合が発生することがあります。

  1. コンピューター名の競合

  2. IP アドレスの競合

  3. MAC アドレスの競合

共通のネットワーク上の元の環境と複製された環境

名前が競合している複製された VM を含む 2 つのホスト

これらの競合がもたらす正確な結果は、いくつかの要因 (仮想マシンのオペレーティング システム、ネットワーキング インフラストラクチャ、など) によって異なります。 図 2 では、静的 IP アドレスおよび静的 MAC アドレスが元の環境の各仮想マシンで構成されていると仮定しています。 したがって、環境が複製された場合、複製された仮想マシンの IP アドレスおよび MAC アドレスも同じになります。

コンピューター名の競合

コンピューター名はネットワークでコンピューターを識別するためにユーザーが割り当てる表示名です。 コンピューター名を IP アドレスに解決する際に、通常 2 つのプロトコル (NetBIOS およびドメイン ネーム サーバー (DNS)) が使用されます。 同じコンピューター名を持つ 2 台のコンピューターを同じネットワーク セグメント上で起動すると、NetBIOS は名前の競合を検出し、ユーザーに警告します。 通常、NetBIOS は、コンピューターが同じネットワーク セグメントにある場合にのみ、競合を検出できます。 コンピューターが同じネットワーク セグメントにない場合、または警告が無視された場合、DNS で次のレベルの競合が発生します。 DNS は、コンピューターが名前を登録するための中央リポジトリです。 同じコンピューター名を持つ 2 台のコンピューターが DNS で登録しようとすると、最初のコンピューターにより作成されたエントリが、2 番目のコンピューターによってオーバーライドされる可能性があります。 この場合、最初のコンピューターを起動しても、名前解決を使用してアクセスできません。

コンピューター名の競合を回避または修正するための簡単な方法があります。 環境のコピーを作成する代わりに、sysprep と呼ばれる機能を使って、作成する各複製をカスタマイズできます。 Sysprep は、Windows オペレーティング システムの一部です。 sysprep を使用して環境を複製した場合、環境内の各仮想マシンは、元の環境とは異なる一意のコンピューター名、IP アドレス、および MAC アドレスを取得します。 ただし、複製は同一ではありません。

各複製で一意のコンピューター名を持つことの影響は、それが sysprep またはユーザーによる手動の介入のどちらによって行われるかにかかわらず、仮想マシンにインストールされているソフトウェアによって異なります。 このことを理解するには、例を参照してください。 アプリケーションが環境に配置されたとき、Web サーバー上に web.config ファイルが作成されています。 このファイルでは、接続文字列の一部としてコンピューター名 db-server を構成しています。 そのファイルのスニペットをここに示します。

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

複製された環境でデータベース サーバーのコンピューター名を変更する場合は、新しい名前を使用するよう、次に示すとおり web.config ファイルを手動で変更する必要があります (db-server2 は複製された環境の仮想マシンに割り当てる新しいコンピューター名)。

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

また SQL Server では、コンピューター名が変更されたときに追加の手順が必要となります。 これを実現する SQL スクリプトのスニペットをここに示します。

sp_dropserver db-server
sp_addserver db-server2, local
GO

前の例では、コンピューター名が変更された場合のアプリケーションの再構成方法を示しています。 この手順がアプリケーションに依存することは明確です。 アプリケーションがデータベースのエントリにコンピューター名を記述する場合は、これらのエントリを同様の方法で変更する必要があります。 場合によっては、コンピューター名を変更すると、アプリケーションの再インストールが必要になる場合があります。 このような再構成および再インストールの実行は、複製を使用することで第 1 に避けたいことであることは明らかです。 これには、コンピューター名が競合することなく複数の複製が安全に共存できる、アプリケーションに依存しないより堅牢なアプリケーションが必要です。

IP アドレスの競合

インターネット プロトコル (IP) アドレスは TCP ネットワーク経由でコンピューターが互いに通信するために使用されます。 IP アドレスは、ネットワークの DHCP サーバーにより静的または動的に割り当てられます。 コンピューター内でネットワーク接続されている各インターフェイスに IP アドレスがあります。 静的 IP アドレスを使用して構成されている仮想マシンが複製され、元の仮想マシンと同じネットワーク上に置かれた場合、コンピューター名の競合だけでなく IP アドレスの競合が発生します。 複製のうち 1 つの IP アドレスを変更することで、手動でこの競合を解決できます。 この場合も、IP アドレスの変更による影響は、仮想マシンにインストールされているアプリケーションが静的 IP アドレスを使用する方法により異なります。

動的 IP アドレスを使用して構成されている仮想マシンの複製を開始すると、短時間ネットワークの競合が発生します。 最初の仮想マシンを複製した直後、ネットワークに接続する 2 番目の仮想マシンは競合を検出し、IP アドレスを更新することで自己解決できます。 複製された環境が元の環境で取得されたスナップショットに復元されるたびに、同様の短時間の競合が発生します。 競合のこれらの継続時間は、通常はアプリケーションに影響を与えるほど長くありません。

MAC アドレスの競合

メディア アクセス制御 (MAC) のアドレスは、コンピューターの各ネットワーク インターフェイスに割り当てられるアドレスです。 物理マシンの場合はカードのメーカーによって各ネットワーク インターフェイスに割り当てられます。 仮想マシンの場合、MAC アドレスを割り当てる 2 つの方法 (静的または動的 MAC) があります。 仮想マシンのネットワーク インターフェイスに使用する特定の MAC アドレスを指定できます。 これは、静的 MAC と呼ばれます。 または、ハイパーバイザーで MAC アドレスを動的に割り当てることができます。 これは、動的 MAC と呼ばれます。 動的 MAC アドレスは、MAC アドレス プールの Hyper-V によって仮想マシンが起動されるたびに割り当てられます。 別のホストの仮想マシンと競合しないように、各ホストには MAC アドレスを生成するためのスキームがあります。

静的 MAC アドレスが元の環境で仮想マシン用に使用されている場合、複製された環境の仮想マシンの MAC アドレスも同じになります。 これにより、すぐに MAC の競合が発生します。 重複する MAC アドレスはコンピューターによって必ずしも報告されるわけではないため、検出することは困難です。 それらが報告される場合でも、Windows イベント ビューアーにはそのようなメッセージが記録されます。 エンド ユーザーに、重複する MAC アドレスの 2 とおりの結果があります。 その結果、一方または両方の複製でネットワーク接続が失われます。 また別の結果として、一方のコンピューター宛てにアドレス指定されたパケットが、もう一方のコンピューターに到達する可能性があります。 元のコンピューターとその複製の MAC アドレスが同じである場合、IP アドレスも同じです。 DHCP サーバーを使用して動的 IP アドレスを取得する場合でも、MAC アドレスが同じであるため、DHCP サーバーは同じ IP アドレスを割り当てます。

動的 MAC アドレスを使用することで、MAC の競合をある程度回避できます。 ただし、複製された環境が元の環境で取得されたスナップショットに復元される場合は、MAC アドレスを含め、仮想マシンの状態全体がロールバックされます。 これにより MAC の競合が再度発生するため、複製された仮想マシンを再起動するまで、前述と同じ問題が生じます。 複製された環境を再開すると、ハイパーバイザーは MAC アドレスを解放して、独自の範囲の値を使用して更新します。

ここに記載した形式の競合を検出と解決し、解決後引き続き正常に動作するよう OS/アプリケーションを手動で修正することは、仮想ラボ管理を頻繁に使用するユーザーにとって非常に時間がかかり、エラーが発生しやすい作業です。 多くの場合、これらのパラメーターの変更により仮想環境が変更され、稼働環境で再現したバグの損失または同様の問題が発生します。 アプリケーションを仮想環境に 1 回インストールして、その環境を心配が要らないよう複製し、複数のコピーを作成するという原則には、通常のユーザーが予測するより高度なアプローチが必要です。

ネットワークの分離

これまでに 2 つの要件が特定されています。 最初の要件は、複製された環境の仮想マシンが、元の環境のコンピューターと同じコンピューター名、IP アドレス、および MAC アドレスを持つ必要があるということです。 ただし、同時に、これらの重複は環境の外部から個別にアドレス指定できる必要があります。 これは、たとえば、ユーザーが自身のデスクトップから各複製に接続する、アプリケーションを特定の複製に配置する、またはテストを特定の複製で実行する、などの場合に必要です。 このことから 2 番目の要件が発生します。つまり、複製された環境の仮想マシンは、元の環境のコンピューターと異なる一意のコンピューター名、IP アドレス、および MAC アドレスを持つ必要があるということです。 両方の条件を満たす論理的な方法は、各仮想マシンが 2 つのインターフェイスを持つことです。つまり、すべての複製でコンピューター名、IP アドレス、および MAC アドレスが同一であるプライベート インターフェイスと、すべての複製でこれらの値が一意であるパブリック インターフェイスです。

プライベート インターフェイスのネットワークの競合を回避するには、これらのインターフェイスが各複製内のプライベート ネットワークに接続する必要があります。 プライベート ネットワークは、環境内の仮想マシンのみに限定される仮想ネットワークです。 このネットワークは環境の境界を越えて公開されないので、同じコンピューター名、IP アドレス、および MAC アドレスが別の複製で使用されている場合でも競合の可能性はありません。 環境の外部のアクセシビリティを確保するため、すべてのパブリック インターフェイスは共通のパブリック ネットワークに接続する必要があります。 パブリック ネットワークまたはラボ ネットワークは、環境の仮想マシンがラボのクライアントや他のコンピューターとやり取りできるネットワークです。

プライベート インターフェイスとパブリック インターフェイスがネットワークの競合に対処する方法を図 3 に示します。

プライベートとパブリックのポートがある VM を含む 2 つのホスト

Visual Studio Lab Management でネットワークの分離

Visual Studio Lab Management は、各仮想マシンに 2 つのネットワーク インターフェイスを導入することによって、SCVMM 環境に対してネットワークの分離を実装します。 これらのネットワーク インターフェイスの 1 つが、プライベート ネットワークに接続されるプライベート インターフェイスで、もう 1 つがパブリック ネットワークに接続されるパブリック インターフェイスです。

各仮想マシンにインストールされているエージェントと共に Lab Management ソフトウェアは、元の環境と複製された環境が競合することなく共存できるようにします。

プライベート ネットワークのプライベート インターフェイス

コンピューター名、IP アドレス、および MAC アドレスが環境のプライベート インターフェイスに割り当てられるしくみについて、以下に概要を示します。

コンピューター名: プライベート ネットワークのコンピューター名は、NetBIOS によって解決され、Lab Management のソフトウェアによる追加の処理は必要としません。 NetBIOS のコンピューター名を使用するよう構成されているアプリケーションは、すべての複製で意図したとおりに動作します。 この例では、Web サーバー コンピューターは、db サーバーをその名前を使用して参照します。 これらの名前は、元の環境および複製された環境で同じです。 したがって、複製された環境で web.config ファイルを変更する必要はありません。

プライベート ネットワークには DNS サーバーがないため、仮想マシンが完全修飾ドメイン名 (FQDNs) を使用する場合は、この状況に対処して NetBIOS 名の代わりに互いを参照させる必要があります。 たとえば、web.config ファイルが db サーバーを db-server.lab.contoso.com として参照した場合、プライベート ネットワークに DNS がなければ IP アドレスへの名前解決はできません。 これを解決するには、仮想マシンで実行されるラボ エージェントは、ホスト ファイルで同じ環境内の他の仮想マシンに対応するエントリを追加します。 ホスト ファイルは、名前が特定の IP アドレスに解決される必要があるオペレーティング システムを示すもう 1 つの方法です。 この例では、Web サーバー上のホスト ファイルには次のエントリがあります。

192.168.23.2 db-server.lab.contoso.com

IP アドレス: 192.168.23.1 ～ 255 の範囲の静的 IP アドレスが、各仮想マシンのプライベート ネットワーク インターフェイスに割り当てられます。 たとえば、Web サーバーのプライベート インターフェイスが 192.168.23.1 を取得し、db サーバーのいうプライベート インターフェイスが 192.168.23.2 を取得するとします。 Lab Management は、Web サーバーと db サーバーがすべての複製で同じ静的 IP アドレスを確実に取得するようにします。 したがって、Web サーバーの web.config ファイルが db サーバーの IP アドレスを使用して構成されている場合でも、複製された環境でこのファイルを再構成する必要はありません。 ネットワークの分離で構成される環境では、プライベート インターフェイスは、192.168.23.1 で始まる同じ範囲から IP アドレスを取得します。 この範囲で必要なアドレスの最大数は、環境内の仮想マシンの最大数と同じです。 この IP アドレスのセットは、プライベート ネットワークの外部からはルーティング可能でないため、同じ範囲がパブリック ネットワークで使用されていない限り、定義済みの範囲を使用すると安全です。

MAC アドレス: ネットワーク分離環境では、各仮想マシンのプライベート ネットワーク インターフェイスにランダムな静的 MAC アドレスが割り当てられます。 この例では、元の Web サーバーのプライベート インターフェイスには、00-15-5D-07-57-01 などの MAC アドレスが付与されます。 Lab Management は、Web サーバーが複製された環境でも同様に同じ MAC アドレスを取得できるようにします。 この MAC アドレスのセットは、プライベート ネットワークの外部からはルーティング可能でないため、ハイパーバイザーがそのホストで使用するアドレス範囲内でない限り、任意アドレスを使用しても安全です。

パブリック ネットワークのパブリック インターフェイス

コンピューター名、IP アドレス、および MAC アドレスが環境のパブリック インターフェイスに割り当てられるしくみについて、以下に概要を示します。

コンピューター名: コンピューター名の競合が発生するため、NetBIOS ではパブリック ネットワークのコンピューター名を解決させません。 これを回避するには、Lab Management は各仮想マシンのパブリック インターフェイスの NetBIOS ブロードキャストを無効にします。 NetBIOS と同様に、仮想マシンでは DNS の NetBIOS コンピューター名を登録させません。 Lab Management は、すべてのパブリック インターフェイスに対して DNS の登録を同様に無効にします。 NetBIOS および既定の DNS の登録がない場合、パブリック ネットワークで使用できる一意の名前を仮想マシンに設定する必要があります。 Lab Management は、各仮想マシンの代わりに一意のエイリアス名を生成し、DNS に「A」というレコードとして登録します。 この例では、元の環境の Web サーバーは VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com に似た一意のエイリアス名を使用して登録できます。 複製された環境内の同じ Web サーバーは、VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com に似た別の名前を使用して登録されます。

IP アドレス: すべての仮想マシンのパブリック ネットワーク インターフェイスは、DHCP サーバーからの動的 IP アドレスを取得するように構成されます。 これにより、元の環境と複製された環境内の仮想マシンは、一意の IP アドレスを持つことができます。 たとえば、元の環境の Web サーバーは、IP アドレス 172.52.20.140 を取得し、複製された環境の同じ Web サーバーは、IP アドレス 172.52.20.205 を取得できます。

MAC アドレス: MAC アドレスの競合を回避するため、すべての仮想マシンのパブリック ネットワーク インターフェイスは、ハイパーバイザーから動的 MAC アドレスを取得するように構成できます。 これにより、この例の Web サーバー コンピューターは、元の環境と複製された環境で異なる MAC アドレスを取得できます。 ただし、前述したとおり、複製された環境が元の環境で取得されたスナップショットに復元された場合、複製された仮想マシンの MAC アドレスと IP アドレスは、元の環境と同じ値と見なされます。 たとえば、複製された環境が前回のビルドのスナップショットに復元された場合、Web サーバーの IP アドレスは 10.86.51.61 になり (図 3 を参照)、元の環境と同じ値になります。 MAC アドレスでも同様の状況が発生します。 IP アドレスの競合が、DHCP によって更新されるまでの一時的なものである一方、MAC の競合は、仮想マシンが再起動されるまで存続します。 この制限により、パブリック インターフェイス向けにハイパーバイザーから動的に割り当てられた MAC アドレスを使用することは、適切な解決策ではありません。

この問題に対処するには、Lab Management は MAC アドレスの独自のプールを使用します。 このプールからの一意の MAC アドレスが、仮想マシンのパブリック インターフェイスに割り当てられます。 複製された環境がスナップショットに復元されるたびに、Lab Management は MAC アドレスを自動的に変更して競合を防止します。 このしくみを理解するため、元の環境の Web サーバーの MAC アドレスが 1D-D8-B7-1C-00-05 で、複製された環境の Web サーバーで MAC アドレスが 1D-D8-B7-1C-00-07 であると考えます。 複製された環境が元の環境で取得されたスナップショットに復元されると、Web サーバーの MAC アドレスが一時的に 1D-D8-B7-1C-00-05 になります。 Lab Management により、これが再び 1D-D8-B7-1C-00-07 に戻され、ネットワークの競合を回避されます。

ネットワークの分離との標準的な対話

次に、環境内の 2 つの仮想マシンが互いに通信した場合どのような状況が発生するかについて説明します。

  1. Web サーバーは NetBIOS またはホスト ファイルを使用して、コンピューター名 "db-server" を db-server のプライベート インターフェイスの IP アドレス (192.168.23.2) に解決します。

  2. Web サーバーは、この IP アドレスで db-server と通信します。

環境の外部のクライアントが複製された環境の Web サーバーと通信する必要がある場合は、次の手順に従います。

  1. クライアントは、複製された環境の Web サーバーの一意のエイリアス名を取得するため、Lab Management ソフトウェアを照会します。

  2. Lab Management ソフトウェアは一意のエイリアス名を返します。

  3. DNS サーバーは、一意のエイリアス名を Web サーバーのパブリック インターフェイスの IP アドレス (10.86.51.63) に解決します。

  4. クライアントは、この IP アドレスで Web サーバーと通信します。

ネットワークを分離する別の方法

2 つのインターフェイスを使用することが、ネットワーク分離の唯一の方法ではありません。 よく似た方法として、双方向 NAT の使用があります。 NAT は、パブリック ネットワークのデバイスと通信する必要のあるデバイスのプライベート ネットワークを作成するための一般的な方法です。 一般的な NAT での通信がプライベート ネットワークから行う必要がある場合でも、双方向 NAT (または両方向 NAT) はこの手順を進め、プライベート ネットワークのコンピューターまたはパブリック ネットワークのコンピューターによって開始された通信を許可します。

この方法を使用してネットワークの分離を実現するには、両方向 NAT のサーバーをこの環境に導入する必要があります。 これを行うには通常、双方向 NAT サーバーの役割を果たす特殊な仮想マシンを環境に追加します。 ネットワーク分離環境が作成されると、2 つのインターフェイスを使用する方法と同じ方法で、仮想マシンのパブリックおよびプライベート IP アドレスが割り当てられます。 ただし、仮想マシンのネットワーク インターフェイスへのパブリック IP アドレスを割り当てる代わりに、マッピングが両方向 NAT サーバーの NAT テーブルに格納されます。

両方向の NAT を使用した VM へのパブリック アクセス

両方向 NAT の方法を使用して相互に通信するため環境内で 2 つの仮想マシンを使用する手順は、2 つのインターフェイスを使用する方法とまったく同じです。

  1. Web サーバーは NetBIOS またはホスト ファイルを使用して、コンピューター名 "db-server" を db-server のプライベート インターフェイスの IP アドレス (192.168.23.2) に解決します。

  2. Web サーバーは、この IP アドレスで db-server と通信します。

環境の外部のクライアントが複製された環境の Web サーバーと通信する必要がある場合の手順は、次に示すとおり若干異なります。

  1. NAT の方法を実行することで、クライアントは Lab Management ソフトウェアを照会して、複製された環境の Web サーバーの一意のエイリアス名を取得できます (Visual Studio Lab Management は NAT の方法を実装していません)。

  2. Lab Management ソフトウェアは一意のエイリアス名を返します。

  3. DNS サーバーは、一意のエイリアス名を Web サーバーの IP アドレス (10.86.51.63) に解決します。

  4. この IP アドレスは実際に、両方向 NAT のサーバーのインターフェイスへマッピングします。 クライアントは、Web サーバーと通信していることを前提として、両方向 NAT のサーバーと通信します。

  5. NAT サーバーは、構成テーブルに格納されたマッピングを取得して、パブリック IP アドレス (10.86.51.63) をプライベート IP アドレス (192.168.23.1) に変換します。

  6. NAT サーバーは、プライベート ネットワーク クライアントから、Web サーバーの IP アドレスである 192.168.23.1 へメッセージを転送します。

2 つのインターフェイスを使用する方法より優れたこの方法の利点は、環境内の仮想マシンをどのような方法でも変更する必要がないことです。 各仮想マシンに追加のネットワーク インターフェイスを導入する必要はありません。 仮想マシンに追加のネットワーク インターフェイスを導入すると、一部のアプリケーションが中断することがあります。

この方法のもう 1 つの利点は、ネットワークの分離を実現するためのロジック全体を、追加する仮想マシンにひとまとめにできることです。 他の各仮想マシンにエージェントを設定する必要はありません。 追加の仮想マシンを使用してすべてのパケットをルーティングすることで、次に示すとおり、ネットワーク分離のさらなる拡張機能をサポートするためのコントロール ポイントも得られます。

  • アウトのみのフェンス操作: 環境の外部のクライアントによるネットワーク パケットが環境内の仮想マシンに到達することを許可しません。

  • アウトのみ、ただし特定ポートの例外あり: 環境の外部のクライアントによるネットワーク パケットが特定のポートを対象としていない限り、環境内の仮想マシンに到達することを許可しません。

これらの機能は、NAT サーバーへファイアウォールを導入することで、両方向 NAT の方法に簡単に実装できます。両方向 NAT の方法の主な欠点は、一部のアプリケーションが NAT 上で動作しないことです。 たとえば、クライアントとサーバーが NAT サーバーによって区切られている場合、Windows アプリケーションでよく使用される DCOM および .NET リモート処理のプロトコルは動作しません。 このため、Visual Studio Lab Management はデュアル インターフェイスの方法を使用します。 両方向 NAT の方法のもう 1 つの欠点は、各環境に追加の仮想マシンを必要とすることです。これにより、仮想環境の作成または他の操作中に追加のオーバーヘッドが生じます。

その他の競合

これまで、ネットワーク分離を通じてコンピューター名、IP アドレス、および MAC アドレスの競合に対処する方法について説明しました。 環境を複製すると、他の形式の競合も同様に発生する可能性があります。 仮想環境の外部にある外部コンポーネントに依存関係がある場合は必ず、その環境を複製したときに競合が発生する可能性があります。 このセクションでは、このような競合が発生する可能性がある一般的な 2 つのケースについて考えます。

Active Directory の競合

ディレクトリ サービスまたはユーザー認証/承認向けに Windows コンピューターおよびアプリケーションが Active Directory (AD) に依存することは一般的です。 AD のグループ ポリシーを使用して Windows コンピューターを集中管理することは非常に一般的です。 この例を使用して、元の環境の Web サーバーと db サーバーが、AD によって管理されるドメインに参加すると仮定しましょう。 AD は、環境外でホストされます。 この環境を複製する際、Web サーバーの同一の複製が 2 つありますが、AD にはエントリが 1 つしかありません。 これは明らかに望ましくない状態であり、いくつかの問題を引き起こすおそれがあります。 たとえば、Web サーバーの複製の 1 つがユーザー操作によりドメインから切り離された場合、他の重複も同様に切り離されます。 1 つの環境で行われた変更が、意図せず他の環境に影響を及ぼします。

Active Directory の競合を回避するには、AD サーバーは環境内の仮想マシン上でホストする必要があります。 AD サーバーは、環境外部の他のディレクトリとの信頼関係を持つことはできません。

ネットワーク分離環境で AD を設定するには、追加の考慮事項があります。 第 1 に、AD の仮想マシンは、パブリック ネットワークに接続できません。 2 つのインターフェイスを使用する方法では、これは AD の仮想マシンにパブリック インターフェイスを設定してはならないことを意味します。 両方向 NAT を使用する方法では、これは NAT テーブルに AD の仮想マシン向けのマッピングを設定してはならないことを意味します。

第 2 に、AD は独立したフォレスト内にあるため、環境内でに DNS サーバーを置く必要があります。 環境内の他の仮想マシンは、AD と適切な通信を実現するためにはプライベート ネットワークでこの DNS サーバーを使用する必要があります。 たとえば、プライベート インターフェイスで DNS サーバーの設定が正しく構成されていない場合、仮想マシンはプライベート AD のドメインに参加できないことがあります。

AD の仮想マシンが含まれるように環境を構成している場合、Visual Studio Lab Management は、パブリック ネットワークからの AD の切断と、DNS 設定を使用した仮想マシンのプライベート インターフェイスの構成を自動的に実行します。

環境内の AD をホストできない状態になる場合があります。 たとえば、開発中のアプリケーションが、企業の他の既存アプリケーションと統合するために、企業の AD を使用する必要がある場合に発生します。 コンピューターを環境外のドメインに参加させた場合に、環境の安全な複製を実現するための既知のソリューションはありません。

データの競合

仮想環境のその他の一般的な使用方法として、環境外部のアプリケーションのデータベースのホストがあります。 通常、これが行われるのは、データベースが大きく、すべての環境についてデータベースを複製することが現実的でない場合です。 またこれは、開発中のアプリケーションが、他の場所でもホストされるデータベースとやり取りする単純な Web クライアントである場合にも使用されます。 このような場合、2 つの同一の複製がデータベースとやり取りすると、データベース サーバーは 2 つのクライアントを区別できません。

まとめ

仮想環境の複製を作成する機能は、仮想ラボ管理における複数のシナリオに不可欠です。 ただし、同一の複製が作成されると、コンピューター名、IP アドレス、および MAC アドレスの競合が発生します。 こうした競合を修正するための、コンピューター名または IP アドレスの変更などの単純な方法では、通常、アプリケーションを再構成または再インストールが必要となり、同一の複製を作成するという意図が実質的に無意味なものになります。 ネットワークの分離では、2 つの複製の作成と実行を可能にすることで、この問題に対処します。

次の手順

SCVMM 環境の計画を立てる: SCVMM 環境向けのさまざまなオプションを使用する時期 (実行中の仮想マシン、格納済み仮想マシン、テンプレート、格納済み環境、およびネットワーク分離の使用など) について学習します。 「SCVMM 環境の作成および管理に関するガイダンス」を参照してください。

ネットワーク分離環境を作成する: ネットワーク分離環境を作成する準備ができている場合はこのトピックを使用します。 「ネットワーク分離環境の作成および使用」を参照してください。

参照

概念

自動システム テスト