Клонирование виртуальных машин посредством сетевой изоляции

Виртуальное управление лаборатории вытекая жизненных область в цикле разработки программного обеспечения.Visual Studio Lab Management продукта Visual Studio, перемещение виртуальное управление лаборатории для разработчиков и тест-инженеров.С помощью Visual Studio Lab Management, команды разработки могут использоваться технология виртуализации в проектировании и лабораториях тестирования, формирующих сложные многоуровневого среды из виртуальных машин.Они могут затем построения и развертывания приложения выполнение тестов в этих средах.

Одна из мотивировок для использования виртуализации в разработке и лабораториях тестирования, можно создать идентичные копии, или клона, развертываемых виртуальных машин, можно просто скопировать несколько файлов.Клонирование полезно во многих сценариях.Например, разработчик, чтобы копию среды тестер может воспроизвести проблему может создание клона среды.В команде тестирования, каждый отдельный тест-инженер может клонировать копию среды и затем координации своя работ по тестированию с остальными участниками команды.Клонирование сохранение время для обоих разработчиков и тестеров, поскольку они не должны повторно установить операционные системы и другое программное обеспечение в каждой среде, в которой они создаются.

Требования

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

Даже если легко клонировать виртуальную среду, последствия клонирования, которые следует учитывать.Компьютеры в клонированной среде имеют те же имена компьютеров, компьютеры в исходной среде.В некоторых случаях, они могут даже те же IP-адрес и MAC-адреса.Это может привести к или в одном из клонов окончанием соединение сети или сетевом трафике, на которую ориентирован одного клона этап другое вместо.Наконец, непреднамеренное последствия может отличаться от развертывания приложения к определенному клону и проводить тесты на другой клон.

Примечание
Можно использовать только с использованием сред с сетевой изоляцией SCVMM.Эта функция недоступна в стандартные среды.

Visual Studio Lab Management решить эти проблемы и облегчает безопасное клонирование по технологии виртуальных сред с сетевой изоляцией.В этом разделе обсуждается сетевая изоляция и сравнивает клонирование работает с или без сетевой изоляции.В первом примере описываются различные формы конфликтов, возникающих между клонами в отсутствие сетевой изоляции.Следующие примеры нескольких решений проверьте, чтобы избежать конфликтов с помощью Visual Studio Lab Management.

Конфликтам

На рисунке 1 представлен типичный виртуальную среду можно создать с помощью Lab Management.Эта среда, первоначально вызывается средой, содержит 2 виртуальной машины. веб-сервер и сервер базы данных.Эти компьютеры служат роль Интернета и сервера базы данных соответственно в веб-приложении 3 уровней.В этом примере мы высказывать член команды разработки создана среда разработки и развертывания последнее построение их веб-приложения на него.Рекомендуется также высказывать вызывается снимок последним построением были приняты на эту среду после построения, развертывания.Снимок состояния момента времени.Можно восстановить на и выполнение продолжения из этого сохраненного состояния в любое время.На рисунке показаны имена компьютеров, ip-адреса и MAC-адреса 2 виртуальных машин в исходной среде.

Исходной среде

На рисунке 2 представлен клонированную среду в дополнение к оригиналу.После клонирующ, если обе среды будут запущены, следующие типы конфликтов сети могут возникнуть:

1. Конфликты имен компьютеров

2. Конфликты IP-адрес

3. Конфликты MAC-адреса

Исходный и клонированные среды в одной сети

Точный результат каждого из этих противоречит зависит от нескольких факторов: операционной системы на виртуальных машинах, инфраструктура в лабораторной сети и т дНа рисунке 2, а высказывать статический ip-адреса и статический mac-адреса настроен в каждой виртуальной машине исходной среды.Следовательно, если среда была клонируется, клонированные виртуальные машины будут те же ip-адресов и MAC-адреса.

Конфликты имен компьютеров

Имя компьютера понятное имя, присвоенное пользователем для указания компьютера в сети.2 Протокола обычно используются, чтобы разрешить имя компьютера с его IP-адрес. NetBIOS и сервер доменных имен (DNS).Когда 2 компьютера, имеют одно и то же имя компьютера запущены на одном сегменте NetBIOS сети, обнаруживает конфликт имен и предупреждает пользователя.Обычно NetBIOS обнаруживает конфликты, только если компьютеры в одном сегменте сети.Если компьютеры не на одном сегменте сети или если предупреждения игнорируются, следующий уровень конфликтов происходит в DNS.DNS центральный репозиторий для компьютеров, чтобы зарегистрировать их имена.Когда 2 компьютера, имеют одну и ту же попытку регистрации имени компьютера в DNS, второй компьютер может переопределить запись созданная первым компьютером.В этом случае первый компьютер, на котором запускается не доступен доступные разрешения имен.

Простые способы избегать или устранение конфликтов имен компьютеров.Вместо создания идентичные копии среды, можно настраивать каждого клона при создании их с использованием механизма с sysprep.Sysprep часть операционных систем Windows.При использовании sysprep для клонирования среды, каждая виртуальная машина среды получает уникального имени компьютера, ip-адреса и mac-адреса, отличаются от тех в исходной среде.Однако клонов больше не совпадают.

Влияние иметь уникальное имя компьютера в каждом клоне, выполняется ли это с помощью sysprep или посредством ручную интервенцию пользователя, чтобы избежать конфликтов, - в программном обеспечении, задаваемое в виртуальной машине.Это понять, просмотрите образец.Когда приложение было развернуто на среде 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

В предыдущем примере показано, как приложение должно быть повторно скомпоновано, если изменены имена компьютеров.Постижимо, эта процедура зависит от приложения.Если приложение записывает имя компьютера в записи в базе данных, эти записи необходимо изменить таким же образом.В некоторых случаях может потребоваться переустановить приложения при изменении имени компьютера.Поиск тех повторяющихся переходы и установки, что не требуется избежать сначала с помощью клонирования.Это требует более надежные приложения независимо от решения, которая может безопасно разрешить несколько клонов, чтобы сосуществовать без конфликтов имен компьютеров.

Конфликты IP-адрес

Адрес (IP) протокол IP используется для компьютеров для взаимодействия друг с другом по сети TCP.IP-адрес каждой статически или динамически DHCP-сервером лабораторной сети.При подключении сетевой интерфейс в компьютере имеется IP-адрес.Если клонируется виртуальную машину, настроенную со статическим IP-адресом и затем установить в одной сети как исходную виртуальную машину, конфликт IP-адрес, в дополнение к конфликту имен компьютеров.Можно вручную устранить этот конфликт путем изменения IP-адрес одного из клонов.Еще раз, влияние изменения ip-адреса в зависимости от того, как статический IP-адрес используется приложениями, которые установлены на виртуальных машинах.

При запуске, чтобы клонировать виртуальную машину, настроенную с динамическим IP-адрес, конфликты сети в течение короткого периода времени.Вскоре после первой виртуальная машина клонируется, вторая виртуальную машину, чтобы подключиться к сети обнаруживает и исправляет этот конфликт, возобновлять его IP-адрес.Точка конфликтов, которая существует при каждом клонированная среды восстановлена к снимку, который был принят в исходную среду.Эти точки конфликтов не является достаточно долго повлиять на приложение.

Конфликты MAC-адреса

Адрес (MAC) уровня управления доступом к среде передачи адрес, присвоенный каждому сетевому интерфейсу в компьютере.В случае физических компьютеров, он присваивается каждому сетевому интерфейсу производителем карты.В случае виртуальных машин, 2 можно присвоить MAC-адреса: статические или динамические mac-адресов.Можно указать определенный mac-адреса для сетевого интерфейса виртуальной машины.Это называется статическим mac-адресов.Кроме того, можно разрешить низкоуровневой оболочке присвойте mac-адреса динамически.Это называется динамическим mac-адресов.Динамические MAC-адреса присвоены hyper-v из пула MAC-адресов каждый раз виртуальная машина запущена.Каждый узел имеет схему создавать MAC-адреса так, чтобы они не конфликтовали с виртуальными машинами на другом узле.

Если статические MAC-адреса используются для виртуальных машин в исходной среде, виртуальные машины клонированной среде будут иметь одинаковые MAC-адреса.Это приводит к быстрому в конфликтах mac-адресов.Повторяющиеся MAC-адреса более сложно определить, поскольку они не всегда выводятся компьютерами.Даже если они регистрируются, такие сообщения зарегистрированный средство просмотра событий Windows.Пользователю, 2 возможные последствия двойные MAC-адресов.Следствием потеря подключения к сети на одном или обоих клонах.Другой смысл, что пакеты сети обращаннсяые на один компьютер могут достичь другого компьютера вместо.Когда исходный компьютера и его копия имеют одинаковые MAC-адреса IP-адрес, их также одинаково.Даже если DHCP будет использоваться для получения динамические IP-адрес, DHCP-сервер присвоить им те же IP-адрес, их MAC-адреса идентичны.

В определенных пределах, можно избежать конфликтов с помощью mac-ключа динамических MAC-адресов.Однако если клонированная среда будет восстановлена в снимке, который был принят в исходной среды, все состояния этих виртуальных машин откачено, включая MAC-адреса.Это приводит к еще раз в конфликтах mac-адресов и те же проблемы, описанные ранее существуют до тех пор, пока клонированная виртуальная машина не запущена заново.Перезапустите среду клонированная вызывает низкоуровневую оболочку выпуска и возобновления MAC-адреса значениями из собственного диапазона.

Обнаружение и разрешение конфликтов форм, а просто описаны и вручную устранение OS/application для продолжения работы после разрешения, значительно, без много времени и подвержено ошибкам для частых виртуальных пользователей управления лаборатории.Во многих случаях изменять какие-либо из этих параметров изменяет виртуальную среду достаточно, чтобы привести к потере воспроизводства ошибки или подобной проблемы с рабочей среды.Принцип установить приложение один раз в виртуальную среду и не от беспокойств клонирование среды создания нескольких идентичные копии требует более изощренного подхода, чем обычные пользователи могут быть, предназначенную задачей.

Сетевая изоляция

2 Требования определено на данный момент.Первое требование, виртуальные машины клонированной среде должны иметь одинаковые имена компьютеров, IP-адрес, MAC-адреса и их в исходной среде.Но, одновременно, эти клонов должны быть отдельно адресуемый вне среды.Это необходимо, чтобы, например, для другого подключиться к каждому из клонов из их стола, приложения до при развертывании на определенном клоне, или для теста для запуска на определенном клоне.Это приводит к второй требование, которое было виртуальных машин в клонированной среде также должны иметь уникальные имена компьютеров, ip-адреса и MAC-адреса, отличаются от тех в исходной среде.Логический путь выполнения оба этих требований для каждой виртуальной машины, чтобы иметь 2 интерфейса: закрытый интерфейс, для которого имя компьютера, ip-адреса и mac-адреса то же в каждом клоне; и открытый интерфейс для которого эти значения уникальным в каждом клоне.

Для предотвращения сетевых конфликтов для закрытых интерфейсов они должны быть подключены к частной сети в каждом клоне.Виртуальная частная сеть сеть, ограничена только виртуальные машины внутри среды.Поскольку эта сеть не доступны за границы среды, отсутствует возможность конфликтов, даже если одни и те же имена компьютеров, ip-адреса и MAC-адреса используются в другом клоне.Для специальных возможностей вне среды все открытые интерфейсы должны быть подключены к общей общедоступной сети.Через открытую сеть или сеть лабораторной сети, в которой виртуальные машины среды могут взаимодействовать с клиентами и другими компьютерами в лаборатории.

На рисунке 3 демонстрируется сеть закрытым и открытых интерфейсов адреса конфликты.

Возможность сетевой изоляции в Visual Studio Lab Management

Visual Studio Lab Management реализует сетевой изоляции для среды SCVMM, вставив 2 сетевого интерфейса в каждой виртуальной машине.Один из этих сетевых интерфейсов закрытый интерфейс подключенной к частной сети, другой открытый интерфейс подключенной к общедоступной сети.

Программное обеспечение Lab Management вместе с агентом, сформированным на каждой виртуальной машине, гарантирует, что исходной среде и клонированная среды могут сосуществовать без конфликтов.

Закрытые интерфейсы для частной сети

Следующее описание сводки, как имена компьютеров, ip-адреса и MAC-адреса присвоенные закрытым интерфейсы среды.

Имена компьютеров Имена компьютеров. в частной сети разрешены по NetBIOS и не требуют дополнительной обработки программным обеспечением Lab Management.Приложения, которые настроены для работы с именами компьютеров NetBIOS будут работать ожидаемым образом в каждом клоне.В данном примере, компьютер веб-сервера ссылается на компьютере сервера базы данных с помощью его имя.Эти имена совпадают в исходном документе и клонированных средах.Поэтому файлы web.config не должен изменяться в клонированной среде.

Так как нет DNS-сервер в частной сети, тогда необходимо обрабатывать ситуацию, когда полные доменные имена (полные доменные имена) используются виртуальными машинами ссылаться друг к другу, а не NetBIOS-имен.Например, если файл web.config ссылается на сервер базы данных как db-server.lab.contoso.com, разрешение с таким именем на IP-адрес не был возможна без DNS в частной сети.Чтобы устранить эту проблему, запуск агента лаборатории на виртуальной машине добавляет записи, которые соответствуют другим виртуальных машинах среды в тот же файл hosts.Файл hosts другой способ отображения в операционной системе, имя должно быть разрешено для конкретного ip-адреса.В данном примере файл hosts на веб-сервере будет иметь следующую запись:

192.168.23.2 db-server.lab.contoso.com

Ip-адреса: - из статического IP-адрес 192.168.23.1 - 255 диапазон присвоенный интерфейсу частной сети каждой виртуальной машины.Например, веб-сервер получает интерфейс закрытый 192.168.23.1 и интерфейс базы данных сервера закрытый получает 192.168.23.2.Lab Management гарантирует, что веб-сервер и серверы базы данных получают одни и те же статические IP-адреса в каждом клоне.Таким образом, даже если файл web.config на веб-сервер настроен на IP-адрес сервера базы данных, он не должен быть повторно скомпонован в клонированной среде.В любой среде, настроенную с сетевой изоляцией, закрытые интерфейсы получают IP-адрес из этого одного диапазона, начиная с 192.168.23.1.Максимальное количество адресов необходимо в этом диапазоне совпадает с максимальное число виртуальных машин.Поскольку этот набор ip-адреса не routable извне частной сети, безопасно использовать предопределенный диапазон, пока тот же диапазон не используется в общедоступной сети.

MAC-адреса: - mac-адреса случайный статический присвоенный интерфейсу частной сети каждой виртуальной машины в изолированной от сети среде.В данном примере, дают все равно интерфейс в исходном веб-сервера mac-адреса как 00–15-5D-07–57-01.Lab Management гарантирует, что этот веб-сервер получает mac-адреса клонированной в той же среде также.Поскольку этот набор MAC-адресов не routable извне частной сети, безопасно использовать произвольный адрес, пока они не находятся в пределах диапазона, низкоуровневая оболочка используется на этом узле.

Открытые интерфейсы в общедоступной сети

Следующее описание сводки, как имена компьютеров, ip-адреса и MAC-адреса присвоенные открытых интерфейсов среды.

Имена компьютеров. нам не требуется NetBIOS для разрешения имен компьютеров в общедоступной сети так, так как это привело бы к конфликту имен компьютеров.Для предотвращения этого Lab Management запретит передачу NetBIOS для открытого интерфейса каждой виртуальной машины.Аналогично NetBIOS, нам не требуется виртуальные машины зарегистрировать их имена NetBIOS компьютера в DNS.Lab Management будет отключена регистрация DNS также для каждого открытого интерфейса.В отсутствие NetBIOS и регистрации DNS, по умолчанию будет по-прежнему будет иметь уникальные имена виртуальных машин, которые можно использовать в общедоступной сети.Lab Management создают уникальный псевдоним от имени каждой виртуальной машины и регистры, как "a" запись в DNS.В данном примере, веб-сервер в исходной среде может быть зарегистрирован с помощью уникальный псевдоним, который будет выглядеть как VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com.То же веб-сервера в клонированной среде зарегистрированное под другим именем, которое может содержать VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com.

Ip-адреса: интерфейс общедоступной сети на каждой виртуальной машине настроен для получения динамическое IP-адрес, с DHCP-сервера.Это гарантирует, что виртуальных машин в исходном документе и клонированные среды имеют уникальные IP-адрес.Например, веб-сервер в исходной среде может получить IP-адрес 172.52.20.140 и то же веб-сервера в клонированной среде может получить IP-адрес 172.52.20.205.

MAC-адреса: чтобы избежать конфликтов mac-адресов, интерфейс общедоступной сети на каждой виртуальной машине может быть настроено для получения динамические MAC-адреса из низкоуровневой оболочки.Это задается, что компьютер веб-сервера в приведенном примере получает другой mac-адреса в исходном документе и клонированных средах.Однако как было описано ранее, когда клонированная среды восстанавливаются на снимок среды, принятому в исходном mac-адресов и ip-адреса клонированной виртуальной машины принимает те же значения, исходный документ.Например, если клонированная среды восстановлена наиболее поздно для построения снимок будет веб-сервера, IP-адрес 10.86.51.61 (см. рисунок 3), то же значение, что и в исходной среде.Это же происходит с MAC-адресом также.Пока конфликт является временным IP-адрес до тех пор, пока не возобновлен DHCP, конфликты mac-адресов существует до тех пор, пока виртуальные машины не собраны.Вследствие этого ограничения, используя динамически, MAC-адреса из низкоуровневой оболочки для открытых интерфейсов не возможного решения.

Чтобы исправить это, Lab Management используется собственный пул MAC-адресов.Уникальный MAC-адреса из этого пула присвоенные открытых интерфейсов виртуальных машин.Когда среда клонированная восстановлена к снимку, Lab Management MAC-адреса меняется автоматически, чтобы избежать конфликтов.Чтобы понять, как это работает, если mac-адреса веб-сервера в исходной среде 1D-D8-B7-1C-00–05 и что mac-адреса веб-сервера в 1D-D8-B7-1C-00–07 клонированной среде.Когда среда клонированная восстановлена к снимку принятому в исходной среды, mac-адреса веб-сервера. 1D-D8-B7-1C-00–05 однократно.Lab Management изменяет это значение 1D-D8-B7-1C-00–07, чтобы предотвратить конфликт сети.

Типичные взаимодействия с сетевой изоляцией

Затем мы обсудим, что происходит, когда 2 виртуальной машины в какой-либо среде взаимодействуют друг с другом.

1. Веб-сервер использует NetBIOS или файл hosts, чтобы разрешить имя компьютера "db-server" на IP-адрес частного интерфейса db-server (192.168.23.2).

2. Веб-сервер взаимодействует с db-server на этом IP-адрес.

Когда клиент вне среды должен установить связь с веб-сервером через клонированной среде, следующий процесс выполняется.

1. Запросы клиентского программного обеспечения Lab Management для получения уникальный псевдоним веб-сервера в клонированной среде.

2. Программное обеспечение Lab Management отвечает с уникальным именем псевдонима.

3. DNS-сервер разрешает уникальный псевдоним на IP-адрес открытого интерфейса веб-сервер (10.86.51.63).

4. Клиент взаимодействует с веб-сервером на этом IP-адрес.

Альтернативные подходы для сетевой изоляции

С помощью 2 интерфейса не является единственным подход для сетевой изоляции.Очень подобный подход заключается в использовании двухнаправленное преобразования сетевых адресов (NAT).Преобразование сетевых адресов (NAT) общий подход для создания частная сеть устройств, которые должны взаимодействовать с устройствами в общедоступной сети.Даже если сообщение в обычном преобразовании сетевых адресов (NAT) всегда должно возникать в частной сети, двухнаправленное преобразования сетевых адресов (NAT) (или двухстороннее преобразования сетевых адресов (NAT)) предпринимают меры этот шаг вперед и позволяют сообщение разработанное компьютерами в частной сети или этими в общедоступной сети.

Чтобы осуществить сетевой изоляции при использовании этого подхода, двусторонней сервер преобразования сетевых адресов (NAT) должен быть представлен в среду.Обычно это делается путем добавления специальная виртуальную машину в среду, просто выполняет роль сервера двухнаправленного преобразования сетевых адресов (NAT).После создания среды с сетевой изоляцией, присвоены открытые и закрытые IP-адрес виртуальных машин так же, как в подхода к 2 интерфейсов.Однако вместо присвоения открытый IP-адрес к сетевому интерфейсу в виртуальной машине сопоставления, хранятся в таблице преобразования сетевых адресов (NAT) на сервере двухстороннем преобразования сетевых адресов (NAT).

Инструкции по 2 виртуальных машин среды, чтобы взаимодействовать друг с другом с помощью двусторонней подход к преобразования сетевых адресов (NAT) точно так же, как и в подхода к 2 интерфейсов:

1. Веб-сервер использует NetBIOS или файл hosts для разрешения db-server на имя компьютера ip-адресов частного интерфейса db-server (192.168.23.2).

2. Веб-сервер взаимодействует с db-server на этом IP-адрес.

Действия, когда клиент вне среды должен установить связь с веб-сервером через клонированной среде несколько отличаются и следующим образом:

1. Путем реализации подход к преобразования сетевых адресов (NAT), программное обеспечение Lab Management запросов клиента для получения уникальный псевдоним веб-сервера в клонированной среде.(Visual Studio Lab Management не реализует подход к преобразования сетевых адресов (NAT).

2. Программное обеспечение Lab Management отвечает с уникальным именем псевдонима.

3. DNS-сервер разрешает уникальный псевдоним общедоступного IP-адрес веб-сервер (10.86.51.63).

4. Сопоставления этого IP-адрес, на интерфейс на сервере двухстороннем преобразования сетевых адресов (NAT).Клиент взаимодействует с сервером двухсторонним преобразования сетевых адресов (NAT) во время высказывать его связи с веб-сервера.

5. Сервер преобразования сетевых адресов (NAT) извлекает сопоставления, хранящиеся в соответствующих таблицах конфигурации и преобразует открытый IP-адрес (10.86.51.63) частному IP-адрес (192.168.23.1).

6. Сервер преобразования сетевых адресов (NAT) переадресует сообщение от клиента в частной сети на 192.168.23.1, IP-адрес веб-сервера.

Преимущество этого подхода на подходом к 2 интерфейсов, виртуальные машины не должны быть изменены любым способом.Необходимость вставить дополнительный сетевой интерфейс в каждой виртуальной машине.Вставка дополнительный сетевой интерфейс в виртуальную машину может вызвать некоторые приложения приостановить выполнение.

Другим преимуществом этого подхода состоит в том, что вся логика для достижения сетевой изоляции инкапсулирована в дополнительную виртуальную машину.Нет необходимости иметь агент в каждой из других виртуальных машин.Маршрутизация все пакеты с помощью дополнительную виртуальную машину также обеспечивает дополнительную контрольную точку для поддержки несколько дополнительных функций сетевой изоляции, например:

• только для размещения ограждение: не позволяет пакеты, разработанные с клиентами вне среды для достижения виртуальных машин среды.

• только для размещения с определенными исключениями порта: не позволяет пакеты, разработанные с клиентами вне среды для достижения виртуальных машин среды, если они не предназначены для конкретного порт.

Эти функции можно легко реализовать в двухстороннем подхода к преобразования сетевых адресов (NAT), вставив брандмауэр на сервере преобразования сетевых адресов (NAT). Основным недостатком двухстороннего подхода преобразования сетевых адресов (NAT), некоторые приложения не работают через преобразование сетевых адресов (NAT).Например DCOM и протоколы удаленного взаимодействия .NET, которые часто используются в Windows-приложение, не работают, когда клиент и сервер разделяются сервером преобразования сетевых адресов (NAT).Именно поэтому Visual Studio Lab Management использует подход к сдвоенных интерфейсов.Другим недостатком двухстороннего подхода преобразования сетевых адресов (NAT), который требуется дополнительная виртуальной машины в каждой среде, что дополнительная нагрузка во время создания или других операций в виртуальных средах.

Это противоречит

До сих пор мы описывали как имя компьютера, конфликты ip-адреса и MAC-адреса можно выполнить с помощью сетевой изоляции.Когда среды копируются, другие формы конфликтов, которые могут возникнуть также.Если зависимость в отдельном компоненте, вне виртуальной среды, вероятность конфликтов при этой среде клонируется.В этом разделе мы смотрим 2 общие случаи, когда те конфликты могут возникнуть.

Конфликты Active Directory

Он применяется для компьютеров и приложений Windows полагаться на Active Directory (AD) или служб каталогов или для проверки подлинности и авторизации пользователей.Компьютеры управления окнами централизованно политики с помощью команды конструктора приложений очень обычная практика.Используя этот пример, предположим, что веб-сервер и сервер базы данных в исходной среде соединение к домену управляемый конструктором приложений.Конструктор приложений размещена вне среды.Если это клонируем среда теперь мы имеем 2 одинаковых клона веб-сервера. однако только одна запись в конструкторе приложений.Это, нежелательно и может привести к нескольким проблем.Например, если один из клонов веб-сервера disjoined из домена действиями пользователя, disjoined другой копия также.Изменения, внесенные в одном аффекте среды непреднамеренно другой среды.

Чтобы избежать конфликтов Active Directory, сервер приложений конструктора должен быть включен на виртуальной машине внутри среды.Сервер разработки приложений не должна содержать отношения доверия с другими каталогами вне среды.

Некоторые дополнительные соображения по настраивать конструктор приложений в изолированной от сети.Во-первых, виртуальная машина конструктора приложений не должна быть подключена к общедоступной сети.При применении подхода 2 интерфейсов, это означает, что виртуальную машину конструктора приложений не должна иметь открытый интерфейс.В двухстороннем подхода к преобразования сетевых адресов (NAT), это означает, что таблица преобразования сетевых адресов (NAT) не должна быть сопоставление для виртуальной машины конструктора приложений.

Во-вторых, поскольку конструктор приложений в независимом лесу, должно быть DNS-сервер внутри среды.Другие виртуальных машин следует использовать этот DNS-сервер в частной сети правильность сообщения в конструкторе приложений.Например, виртуальная машина не может быть соединение в конструкторе частном домене приложений, если параметр DNS-сервера неправильно настроен на частном интерфейсе.

При настройке среды, чтобы включить виртуальную машину конструктора приложений в Visual Studio Lab Management автоматизирует отключения конструктор приложений из общедоступной сети и настройка закрытые интерфейсы виртуальных машин с параметрами DNS.

Возможны ситуации, в которых невозможно на узел в конструкторе приложений Visual Studio.Например, это может произойти, когда приложение на стадии разработки необходимо использовать корпоративный конструктор приложений для интеграции с другими корпоративными существующих приложений.Никакие известные решение, чтобы включить безопасное клонирование сред при соединении компьютеры к домену вне среды.

Конфликты базы данных

Это общее потребление виртуальных сред включает размещаться базы данных приложения вне среды.Обычно это выполняется, когда базой данных, достаточно большие и при ее невозможно, чтобы клонировать базу данных с каждой средой.Это может также произойти, когда приложение на стадии разработки простой клиент Интернета, который взаимодействует с базой данных, размещенная в другом месте.В таких случаях при 2 одинаковых клона взаимодействуют с базой данных, сервер базы данных не может отличить идентификатор 2 клиентов.

Сводка

Возможность создания клонов идентичные виртуальных сред, необходимой для нескольких сценариев в элементе управления виртуальной лаборатории.Однако если создают идентичные клонов, имя компьютера, конфликты ip-адреса и MAC-адреса.Простые методы, такие как изменять имена компьютеров или ip-адреса, чтобы устранить эти конфликты обычно требуется перенастройки или установки приложения и эффективно наносят отмена намерению создать идентичные клонов.Сетевая изоляция устраняет эту проблему, позволяет создания и запуска 2 клона одновременно.

Следующие шаги

Планирование, среда SCVMM. сведения о том, когда использовать различные параметры для сред SCVMM, такие как использование запуска виртуальных машин, хранимых виртуальных машин, шаблонов и хранимых сред сетевой изоляции.Дополнительные сведения см. в разделе Руководство по созданию сред SCVMM и управлению ими.

Создание среды с сетевой изоляцией. эта область используется при приступить к созданию среды с сетевой изоляцией.Дополнительные сведения см. в разделе Создание и использование изолированной от сети среды.

См. также

Основные понятия

Использование лабораторной среды в жизненном цикле приложения