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

Виртуальное управление лабораторией — это новая область в жизненном цикле разработки ПО. 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. Она называется исходной средой. В ней содержится две виртуальные машины: web-server и db-server. В трехуровневом веб-приложении они выполняют функции веб-сервера и сервера базы данных соответственно. В этом примере мы исходим из того, что один из участников команды разработки создал эту среду и развернул в ней последнюю сборку создаваемого веб-приложения. Предполагается так же, что после развертывания этой сборки в среде был создан снимок с именем latest build. Снимок — это запись состояния среды в определенный момент. Среду в любой момент можно восстановить до этого сохраненного состояния и продолжить выполнение с той же точки. На приведенном ниже рисунке показаны имена компьютеров, IP-адреса и MAC-адреса двух виртуальных машин в исходной среде.

Исходная среда

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

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

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

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

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

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

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

Имя компьютера — это понятное имя, присвоенное пользователем для идентификации машины в сети. Обычно для разрешения имен компьютеров и определения IP-адресов используются два протокола: NetBIOS и DNS (Domain Name Server). Если в одном сегменте сети запущены две машины с одним и тем же именем, то NetBIOS обнаруживает конфликт имен и предупреждает пользователя. Обычно NetBIOS обнаруживает конфликты, только если машины находятся в одном и том же сегменте сети. Если машины находятся в разных сегментах (или если пользователь проигнорировал предупреждения), то в DNS возникают конфликты следующего уровня. DNS — это центральный репозиторий для регистрации имен компьютеров. Если в 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-адрес используется для взаимодействия между компьютерами по TCP-сети. DHCP-сервер сети назначает либо статический, либо динамический IP-адрес. Собственный IP-адрес имеется у каждого подключенного сетевого интерфейса на машине. Если создать клон виртуальной машины, в которой настроен статический IP-адрес, а затем подключить его к той же сети, в которой уже находится исходная виртуальная машина, то помимо конфликта имен компьютеров возникнет еще и конфликт IP-адресов. Устранить его можно вручную, изменив IP-адрес одного из клонов. Как и в предыдущем случае, последствия изменения IP-адреса зависят от того, каким образом этот статический IP-адрес используется приложениями, установленными на виртуальных машинах.

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

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

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

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

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

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

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

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

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

На рисунке 3 показано, как решить сетевые конфликты при помощи частных и общедоступных интерфейсов.

Сетевая изоляция в Visual Studio Lab Management

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

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

Частные интерфейсы в частной сети

Ниже приводится краткая информация о том, каким образом имена компьютеров и IP- и MAC-адреса присваиваются частным интерфейсам среды.

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

Поскольку в частной сети нет DNS-сервера, необходимо найти решение для ситуации, при которой виртуальные машины обращаются друг к другу не пол NetBIOS-именам, а по полным доменным именам. К примеру, если в файле web.config компьютер db-server обозначен как 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. Например, частный интерфейс на машине web-server получает адрес 192.168.23.1, а на машине db-server — 192.168.23.2. Lab Management следит за тем, чтобы машины web-server и db-server в каждом клоне получили одни и те же IP-адреса. Таким образом, даже если в файле web.config на машине web-server указан IP-адрес db-server, перенастраивать его в клонированной среде не требуется. В любой среде, в которой настроена сетевая изоляция, частные интерфейсы получают IP-адреса из одного и того же диапазона, который начинается с 192.168.23.1. Максимальное количество адресов, которое потребуется в этом диапазоне, совпадает с максимальным количеством виртуальных машин. Поскольку маршрутизация к этому набору IP-адресов из-за границ частной сети невозможна, допускается использовать заранее заданный диапазон (если в общедоступной сети не используется точно такой же диапазон).

MAC-адреса. Частному сетевому интерфейсу каждой виртуальной машины в среде с сетевой изоляцией присваивается случайный MAC-адрес. В нашем примере частному интерфейсу исходной машины web-server присвоен MAC-адрес 00-15-5D-07-57-01. Решение Lab Management следит за тем, чтобы в клонированной среде машина web-server получила точно такой же MAC-адрес. Поскольку маршрутизация к этому набору MAC-адресов из-за границ частной сети невозможна, допускается использовать случайно выбранный адрес (если он не относится к диапазону, который используется гипервизором для этого узла).

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

Ниже приводится краткая информация о том, каким образом имена компьютеров и IP- и MAC-адреса присваиваются общедоступным интерфейсам среды.

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

IP-адреса. На интерфейсе общедоступной сети на каждой виртуальной машине настроено получение динамического IP-адреса с DHCP-сервера. Благодаря этому виртуальные машины исходной и клонированной средах будут иметь уникальные IP-адреса. Например, в исходной среде машина web-server может получить IP-адрес 172.52.20.140, а в клонированной — 172.52.20.205.

MAC-адреса. Чтобы не допустить конфликта MAC-адресов, на общедоступном сетевом интерфейсе каждой виртуальной машины можно настроить получение динамического MAC-адреса с гипервизора. Благодаря этому в исходной и клонированной средах машина web-server из нашего примера получит разные MAC-адреса. Однако, как говорилось выше, каждый раз, когда в клонированной среде будет восстанавливаться снимок, созданный в исходной среде, MAC- и IP-адреса клонированной виртуальной машины будут получать те же значения, что и в исходной среде. Например, если в клонированной среде восстановить снимок latest build, то машина web-server получит IP-адрес 10.86.51.61 (см. рисунок 3) — тот же самый, что и в исходной среде. То же самое произойдет и с MAC-адресом. Хотя конфликт IP-адресов сохраняется недолго, только до обновления DHCP, конфликты MAC-адресов сохраняются до тех пор, пока виртуальные машины не будут перезапущены. Вследствие этого получать динамически назначаемые MAC-адреса с гипервизора для общедоступных интерфейсов невозможно.

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

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

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

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

2. Машина web-server обращается к машине db-server по этому IP-адресу.

Если к машине web-server в клонированной среде необходимо подключиться клиенту из-за ее границ, происходит следующее.

1. Клиент запрашивает у Lab Management уникальный псевдоним машины web-server в клонированной среде.

2. В ответ Lab Management высылает уникальное имя псевдонима.

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

4. Клиент обращается к машине web-server по этому IP-адресу.

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

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

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

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

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

2. Машина web-server обращается к машине db-server по этому IP-адресу.

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

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

2. В ответ Lab Management высылает уникальное имя псевдонима.

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

4. Этот IP-адрес на самом деле соответствует интерфейсу на сервере двунаправленного NAT. Клиент взаимодействует с сервером двунаправленного NAT, предполагая, что связывается с машиной web-server.

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

6. NAT-сервер переадресует сообщение от клиента в частную сеть на IP-адрес 192.168.23.1, принадлежащий машине web-server.

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

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

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

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

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

Другие конфликты

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

Конфликты Active Directory

Во многих системах и приложениях Windows используется решение Active Directory (AD). Оно может использоваться либо как служба каталогов, либо для аутентификации и авторизации пользователей. Довольно часто управление машинами с ОС Windows осуществляется при помощи групповых политик AD. Вернемся к нашему примеру и предположим, что машины web-server и db-server в исходной среде присоединены к домену, управляемому AD. При этом сервер AD находится за границей среды. Если мы клонируем эту среду, у нас будет два одинаковых клона машины web-server, однако в AD имеется только одна запись. Разумеется, такая ситуация нежелательна и может вызвать ряд проблем. Например, если пользователь отсоединит один из клонов этой машины от домена, тем самым будет отключен и второй клон. Изменения, внесенные в одной среде, повлияют и на другую среду, даже если это и не входит в намерения пользователя.

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

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

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

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

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

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

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

Сводка

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

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

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

Создание среды с сетевой изоляцией. Этот раздел предназначен для тех, кто уже готов создавать среду с сетевой изоляцией. См. раздел Создание и использование изолированной от сети среды.

См. также

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

Автоматизация системных тестов