Развертывание масштабируемой сетевой инфраструктуры для поставщиков услуг размещения

Опубликовано: Июнь 2013 г.

Назначение: System Center 2012 R2, Windows Azure Pack, Windows Server 2012 R2

Чем может быть полезно данное руководство? Являясь поставщиком услуг размещения и относясь к сегменту среднего бизнеса, вы можете воспользоваться данным руководством, чтобы ознакомиться со структурой решения и этапами внедрения, которые мы рекомендуем применять при развертывании масштабируемой сетевой инфраструктуры для поддержки концепции «инфраструктура как услуга» (IaaS). Подготовка к работе сетей клиентов может оказаться сложной как в реализации, так и в управлении.

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

Содержание данного руководства по решению:

• Сценарий, постановка проблемы и цели

• Рекомендуемая структура для такого решения

• Аргументы в пользу такой структуры

• Этапы внедрения решения

• Дополнительные конфигурации

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

Клиенты, подключающиеся к поставщику услуг размещения

Сценарий, постановка проблемы и цели

Этот раздел содержит описание сценария, проблемы и целей на примере типовой организации.

Сценарий

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

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

Постановка проблемы

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

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

• Если клиенту нужно подключить несколько объектов, то для каждого из них также нужен отдельный шлюз.

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

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

Цели организации

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

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

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

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

• Структура управляемой виртуальной сети с удобным единым интерфейсом, который позволяет управлять виртуальными сетями, пространствами IP-адресов и шлюзами. Это позволяет клиенту эффективнее управлять множеством клиентом одновременно.

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

• Возможность предоставить клиентам простые и понятные указания по подключению локальной сети к инфраструктуре поставщика услуг размещения через безопасную виртуальную частную сеть (VPN) типа «сеть — сеть». Эти указания включают в себя инструкции по настройке маршрутизаторов с подробным описанием требуемых протоколов, параметров и адресов конечных точек.

Рекомендуемая структура для такого решения

На следующей схеме показаны рекомендуемая структура для этого решения, которая подключает сеть каждого клиента к мультитенантному шлюзу поставщика услуг размещения с помощью одного туннеля VPN типа «сеть — сеть». Это позволяет поставщику услуг размещения обслуживать примерно 100 клиентов в кластере с одним шлюзом, что снижает сложность управления и соответствующие затраты. Каждому клиенту необходимо настроить свой собственный шлюз для подключения к шлюзу поставщика услуг размещения. После этого шлюз осуществляет маршрутизацию данных сети каждого клиента и использует протокол NVGRE для виртуализации сетей.

Структура мультитенантного сетевого решения

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

Windows Server 2012 R2 вместе с System Center 2012 R2 Virtual Machine Manager (VMM) предоставляют поставщику услуг размещения мультитенантное решение шлюза, которое поддерживает несколько VPN-подключений типа «узел — узел» клиентов, доступ в Интернет для виртуальных машин клиента с использованием компонента преобразования сетевых адресов (NAT) шлюза, а также возможности переадресации шлюза для реализаций частного облака. Виртуализация сети Hyper-V предоставляет клиенту изоляцию виртуальной сети с помощьюNVGRE, что позволяет клиентам добавлять собственные адресные пространства, а поставщикам услуг размещения добиваться лучшей масштабируемости по сравнению с использованием виртуальных локальных сетей для изоляции.

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

Дополнительные сведения о преимуществах виртуализации сети Hyper-V и шлюза Windows Server см. в разделе

• Обзор виртуализации сети Hyper-V

• Шлюз Windows Server

VMM предоставляет пользовательский интерфейс для управления шлюзами, виртуальными сетями, виртуальными машинами и другими элементами структуры.

При планировании данного решения необходимо учитывать следующее:

• Структура, обеспечивающая высокую доступность для серверов с Hyper-V, гостевых виртуальных машин, сервера SQL Server, шлюзов, VMM и других служб

  Вы захотите убедиться, что структура является отказоустойчивой и позволяет обеспечить заявленные требования к доступности.

• Требования по доступу в Интернет для виртуальных машин клиентов

  Проанализируйте, требуется ли вашим клиентам доступ в Интернет для их виртуальных машин. Если такой доступ нужен, вам потребуется настроить компонент NAT при развертывании шлюза.

• Емкость и пропускная способность физического оборудования инфраструктуры

  Вам потребуется убедиться, что физическая сеть может масштабироваться по мере расширения вашего предложения IaaS.

• Пропускная способность подключения типа «сеть — сеть»

  Вам потребуется проанализировать, какой уровень пропускной способности вы можете предоставить клиентам и будет ли достаточно VPN-подключений типа «сеть — сеть».

• Технологии сетевой изоляции

  Это решение использует протокол NVGRE для сетевой изоляции клиентов. Вам потребуется определить, владеете ли вы оборудованием для оптимизации использования данного протокола и можете ли получить такое оборудование. Например, сетевые карты, коммутаторы и т. д.

• Способы проверки подлинности

  Это решение использует два домена Active Directory для проверки подлинности: один для серверов инфраструктуры и один для кластера шлюза и горизонтально масштабируемого файлового сервера этого шлюза. Если у вас нет доступного домена Active Directory для такой инфраструктуры, необходимо подготовить контроллер домена перед началом развертывания.

• IP-адресация

  Вам потребуется планировать пространства IP-адресов, используемые данным решением.

Определение требований клиента

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

Используйте следующие вопросы при проведении планирования под требования клиента.

Дополнительные сведения о рекомендациях по физическим вычислительным ресурсам см. в разделе «3.1.6 Физические вычислительные ресурсы: низкоуровневая оболочка» руководства по вариантам разработки в статьеРешение облачной инфраструктуры для корпоративных ИТ.

Определение стратегии отказоустойчивого кластера

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

Для этого решения настраивайте масштабируемые файловые серверы, вычислительные узлы Hyper-V, узлы управления Hyper-V и узлы шлюза Hyper-V как отказоустойчивые кластеры. Кроме того, настройте гостевые виртуальные машины SQL, Диспетчер виртуальных машин и шлюза как отказоустойчивые кластеры. Эта конфигурация обеспечивает защиту от потенциальных сбоев физического компьютера и виртуальной машины.

Определение стратегии высокой доступности SQL

Вам потребуется выбрать вариант SQL, чтобы обеспечить высокую доступность для этого решения. В SQL Server 2012 предусмотрено несколько вариантов:

• Экземпляры отказоустойчивого кластера AlwaysOn

  Этот вариант обеспечивает локальную высокую доступность посредством избыточности на уровне экземпляра сервера — экземпляра отказоустойчивого кластера.

• Группы доступности AlwaysOn

  Этот вариант позволяет добиться максимальной доступности для одной или нескольких пользовательских баз данных.

Дополнительные сведения см. в разделе Обзор решений высокой доступности SQL Server.

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

Определение требований к шлюзу

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

Рекомендации по конфигурации шлюза Windows Server см. в разделе Требования к оборудованию и конфигурации шлюза Windows Server.

Для планирования мощности рекомендуется использовать один гостевой кластер шлюза на 100 клиентов.

Структура этого решения в подключении клиентов к шлюзу посредством VPN типа «сеть — сеть». Поэтому рекомендуется развертывать шлюз Windows Server с помощью VPN. Можно настроить отказоустойчивый кластер из двух узлов Hyper-V с гостевым отказоустойчивым кластером из двух узлов, используя предварительно заданные шаблоны служб, доступных в Центре загрузки Майкрософт (дополнительные сведения см. в разделе Использование сервера под управлением Windows Server 2012 R2 в качестве шлюза с VMM).

Планирование сетевой инфраструктуры

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

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

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

Структура сети для узлов кластера

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

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

План по подсетям и VLAN

План логических сетей в VMM

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

План сети виртуальных машин VMM

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

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

Такая структура использует следующие профили порта исходящей связи, определенные в VMM:

План профилей порта исходящей связи VMM

Такая структура развертывает следующие логические коммутаторы с помощью данных профилей порта исходящей связи, определенных в VMM:

План логических коммутаторов в VMM

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

Планирование развертывания Windows Azure Pack

Если вы используете Windows Azure для портала самообслуживания клиентов, существует множество возможностей, которые можно предложить клиентам. Это решение включает в себя некоторые функции облака виртуальных машин, но вам доступно множество дополнительных возможностей — не только облаков виртуальных машин, но и облаков веб-сайтов, облаков служебной шины, серверов SQL Server, серверов MySQL, а также многое другое. Дополнительные сведения о компонентах Windows Azure см. в разделе Windows Azure Pack для Windows Server.

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

Для определения требований по узлам для рабочего распределенного развертывания см. раздел Архитектура Windows Azure Pack.

Используйте распределенное развертывание, если решено развернуть Windows Azure в рабочей среде. Если вы хотите оценить возможности Windows Azure до развертывания в рабочей среде, воспользуйтесь экспресс-развертыванием. Для этого решения экспресс-развертывание используется в целях демонстрации службы облаков веб-сайтов. Вы развертываете Windows Azure на одной виртуальной машине, расположенной в вычислительном кластере, чтобы веб-порталы были доступны из внешней сети (Интернет). После этого вы развертываете виртуальную машину с Service Provider Foundation на виртуальной машине, выполняемой в кластере управления.

Аргументы в пользу такой структуры

Структура включает в себя отказоустойчивые кластеры для обеспечения высокой доступности и масштабируемости решения.

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

В следующей таблице показаны физические узлы, которые мы рекомендуем для этого решения. Число используемых узлов было выбрано таким образом. чтобы получить необходимый минимум для обеспечения высокой доступности. Вы можете добавить дополнительные физические узлы для дальнейшего распределения рабочих нагрузок в соответствии с конкретными требованиями. Каждый узел имеет 4 физических сетевых адаптера для поддержки требований сетевой изоляции в рамках структуры. Мы рекомендуем использовать сетевую инфраструктуру с пропускной способностью 10 ГБ/с или больше. Скорости в 1 Гбит/с может быть достаточно для трафика инфраструктуры и кластера.

Рекомендации по физическим узлам

Этапы внедрения решения

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

1. Разверните (или определите) домен Active Directory.

   Ваши серверы управления, вычисления и масштабируемые файловые серверы присоединятся к этому домену. Можно также определить существующий домен Active Directory, который может содержать серверы.

2. Разверните (или определите) второй домен Active Directory.

   Этот второй домен Active Directory будет содержать серверы шлюза узла Hyper-V и масштабируемый файловый сервер для хранилища шлюза. В целях обеспечения безопасности этот домен Active Directory не должен иметь отношения доверия с доменом инфраструктуры.

   Важно!

   Убедитесь, что оба домена могут разрешать имена в другом домене. Например, на каждом DNS-сервере можно настроить службу пересылки, указывающую на DNS-сервер в другом домене.

3. Разверните узлы хранилища и кластеры для домена управления.

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

4. Разверните узлы управления и кластеры.

   Примечание

   Вам понадобится создать временный виртуальный коммутатор с помощью диспетчера Hyper-V, чтобы можно было установить и настроить виртуальные машины. После установки VMM можно определить логический коммутатор в VMM, удалить определенный в Hyper-V виртуальный коммутатор и настроить узлы для использования виртуального коммутатора на базе определенного в VMM логического коммутатора.

   Этот кластер узлов будет содержать виртуальные машины SQL Server, VMM, сервера Service Provider Foundation (SPF) и масштабируемого файлового сервера (для домена шлюза). Масштабируемый файловый сервер для домена шлюза реализован в виртуальных машинах и присоединен к домену шлюза. Дополнительные сведения см. в следующих разделах:

   • Обзор отказоустойчивой кластеризации

   • Развертывание гостевого кластера с помощью общего виртуального жесткого диска

   Важно!

   Разверните все виртуальные машины на одном узле кластера. После настройки сетевых компонентов в VMM выполняется балансировка нагрузки виртуальных машин по узлам кластера.

   1. Разверните гостевой кластер SQL.

      Дополнительные сведения о развертывании экземпляра отказоустойчивого кластера SQL Server см. в следующих разделах:

      • Экземпляры отказоустойчивого кластера AlwaysOn (SQL Server)

      • Установка SQL Server с общей папкой SMB в качестве варианта хранилища

      • Создание нового отказоустойчивого кластера SQL Server (установка)

   2. Разверните VMM.

      Сведения о том, как это сделать, см. в разделеРазвертывание System Center 2012 — Virtual Machine Manager. В этом решении VMM используется для развертывания шлюза и других сетевых компонентов и управления ими.

      1. Установите VMM на гостевом кластере.

         Сведения о том, как это сделать, см. в следующих разделах:

         • Установка высокодоступного сервера управления VMM

         • Инструкции по установке сервера управления VMM на дополнительном узле кластера

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

         Важно!

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

      3. Отключите параметр Создать логические сети автоматически перед добавлением каких-либо узлов. Позднее вы вручную создадите логические сети с нужными параметрами. Этот параметр находится в окне Параметры, Параметры сети.

      4. Добавьте требуемые узлы Hyper-V в качестве узлов VMM.

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

         Кластер масштабируемого файлового сервера следует добавить в категорию Структура, Хранилище, Файловые серверы. Кластер управления (и в конечном счете вычислительный кластер) следует добавить в раздел Все узлы. Чтобы упростить упорядочение узлов, необходимо создать дополнительные группы узлов (например, Вычисления и Управление) и поместить в эти группы соответствующие кластеры.

         Важно!

         При развертывании масштабируемого файлового сервера для домена шлюза вам потребуется открыть открытый порт Удаленное управление Windows (HTTP — входящий трафик) на обоих узлах гостевого кластера. Этот порт должен быть открыт, поскольку сервер VMM и кластер шлюза находятся в отдельных недоверенных доменах, а этот порт не открыт по умолчанию для общего профиля.

         Дополнительные сведения см. в разделе Обзор добавления серверов Windows в качестве узлов Hyper-V в VMM.

         Для ознакомления с примером процедуры см. подраздел «Добавление HNVHOST1, HNVHOST2 и HNVHOST3 в качестве узлов VMM» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

      5. Добавьте хранилище общих папок.

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

      6. Создайте запланированные логические сети и связанные пулы IP-адресов.

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

         Логическая сеть сетей узлов настраивается как Независимые сети на основе виртуальной ЛС, а остальные логические сети — как Одна подключенная сеть.

         Дополнительные сведения см. в статье Создание логической сети в VMM.

         Пример процедуры в тестовой среде см. в подразделе «Определение логических сетей со связанными пулами IP-адресов» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

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

         Создайте пул IP-адресов для сетей хранилища и динамической миграции с помощью соответствующего диапазона адресов из имеющегося плана.

         Дополнительные сведения см. в разделе Создание сети виртуальной машины в VMM в System Center 2012 R2.

         Пример процедуры в тестовой среде см. в подразделе «Определение сетей виртуальных машин» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

      8. Создайте профили портов каналов исходящей связи.

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

         Дополнительные сведения см. в разделе Настройка портов и коммутаторов для сетей виртуальных машин в VMM.

         Пример процедуры в тестовой среде см. в подразделе «Создание профилей портов и логических коммутаторов» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

      9. Создайте логический коммутатор.

         Выберите платформу фильтрации Microsoft Windows для расширений, выберите объединение для режима исходящей связи и добавьте три созданных ранее профиля портов исходящей связи.

         Добавьте следующие виртуальные порты: «Высокая пропускная способность», «Инфраструктура», «Динамическая миграция», «Низкая пропускная способность» и «Средняя пропускная способность».

      10. Создайте объединенный виртуальный коммутатор на узле управления.

          Добавьте виртуальный коммутатор на узел кластера управления. Это узел, с которыми не сопоставлено никаких виртуальных машин.

          Для этого найдите в VMM узел в разделе «Структура» области «Серверы», откройте страницу Свойства и добавьте виртуальный коммутатор на странице Новый виртуальный адаптер.

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

          После этого убедитесь, что виртуальный коммутатор имеет следующий вид:

          

          

          

          Важно!

          Может понадобиться внести некоторые изменения в конфигурацию портов физического коммутатора, к которым подключены эти сетевые адаптеры. При использовании протокола LACP для объединения необходимо настроить порты коммутатора для LACP. Если порты коммутатора настроены в режиме доступа (для пакетов без тега), необходимо настроить их в режиме магистрали, поскольку от объединенных адаптеров будут поступать пакеты с тегами.

          Дополнительные сведения см. в разделе Настройка параметров сети на узле посредством применения логического коммутатора в VMM.

          Совет

          Для устранения неполадок можно использовать следующие командлеты Windows PowerShell:

          Get-NetLbfoTeam, Get-NetLbfoTeamMember и Get-NetLbfoTeamNic

          Чтобы просмотреть другие связанные командлеты, введите Get-command *lbfo*.

      11. Настройте параметры миграции.

          После настройки адаптера динамической миграции на виртуальном коммутаторе можно настроить параметры миграции на странице Свойства, Параметры миграции каждого узла. Настройте необходимые параметры и убедитесь, что адрес подсети динамической миграции был добавлен и находится в начале списка. Подсеть фактически указывается как один IP-адрес с 32-битной маской: x.x.x.x/32. Поэтому если виртуальный сетевой адаптер динамической миграции имеет адрес 10.0.3.6, страница параметров миграции может иметь следующий вид:

          

      12. Выполните динамическую миграцию виртуальных машин.

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

          Для миграции виртуальных машин в VMM выберите рабочую область Виртуальные машины (VM) и службы, выберите в кластере управления узел с запущенными виртуальными машинами, щелкните правой кнопкой мыши работающую виртуальную машину и выберите пункт Выполнить миграцию виртуальной машины. Выберите другой узел и переместите виртуальную машину.

      13. Удалите виртуальный коммутатор, который изначально был создан с помощью диспетчера Hyper-V.

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

      14. Создайте новый объединенный виртуальный коммутатор с помощью VMM.

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

      15. Выполните динамическую миграцию некоторых виртуальных машин обратно.

          Теперь, когда для обоих узлов настроен объединенный виртуальный коммутатор с использованием VMM, можно выполнить миграцию некоторых виртуальных машин обратно. Например, переместите один из узлов гостевого кластера SQL, чтобы разделить узлы гостевого кластера по узлам кластера узлов. Сделайте это для всех других гостевых кластеров.

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

5. Разверните вычислительные узлы и кластеры.

   На этом кластере Hyper-V размещаются виртуальные машины клиента и сервер портала Windows Azure Pack.

   Вычислительный кластер Hyper-V можно установить таким же способом, что и кластер управления:

   1. Разверните узлы Hyper-V и выполните присоединение к домену управления.

   2. Объедините узлы в кластер и добавьте его в группу вычислительных узлов VMM.

   3. Создайте объединенный виртуальный коммутатор и виртуальные адаптеры динамической миграции и хранилища для обоих узлов, как это было сделано для обоих узлов управления. При объединении физических адаптеров используйте для адаптеров профиль портов исходящей связи «Вычисления».

   4. Добавьте хранилище общих папок.

      Настройте расположение хранилища для виртуальных машин, развернутых на узлах кластера. Откройте страницу «Свойства» для кластера и добавьте общую папку с масштабируемого файлового сервера на странице «Хранилище общей папки».

6. Разверните шлюз.

   Для развертывания шлюза Windows Server в Windows Server 2012 R2 разверните выделенный кластер узлов Hyper-V и затем виртуальные машины шлюза с помощью VMM. Шлюз Windows Server обеспечивает точку подключения для нескольких VPN-подключений типа «сеть — сеть» клиентов. Выполните аналогичную процедуру, чтобы развернуть физические узлы, но после этого используйте шаблон службы VMM для развертывания виртуальных машин гостевого кластера.

   Чтобы развернуть шлюз Windows Server, используйте следующую процедуру:

   1. Разверните узлы Hyper-V и выполните присоединение к домену шлюза.

   2. Объедините узлы в кластер и добавьте его в группу узлов шлюза VMM.

   3. Создайте объединенный виртуальный коммутатор и виртуальные адаптеры динамической миграции и хранилища для обоих узлов, как это было сделано для обоих узлов управления и вычислений. При объединении физических адаптеров используйте для адаптеров профиль портов исходящей связи «Шлюз».

   4. Добавьте хранилище общих папок.

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

   5. Убедитесь в наличии доступной из VMM общей папки (где доступен файл VHD или VHDX Windows Server 2012 R2). Этот файл будет использоваться шаблоном службы VMM для развертывания виртуальных машин шлюза.

   6. Настройте узлы в качестве узлов шлюза.

      Каждый узел шлюза Hyper-V необходимо настроить как выделенный шлюз виртуализации сети. В VMM щелкните правой кнопкой мыши узел шлюза и выберите пункт Свойства. Выберите Доступ к узлу и установите флажок Этот узел является выделенным шлюзом виртуализации сети, поэтому он недоступен для размещения виртуальных машин, для которых требуется виртуализация сети.

   7. Для развертывания виртуальных машин шлюза выполните процедуры, описанные в разделе Использование сервера под управлением Windows Server 2012 R2 в качестве шлюза с VMM, и проведите развертывание с помощью шаблона высокодоступной службы шлюза с 3 сетевыми картами.

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

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

      

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

      

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

   • Обновление устройства сетевой службы

   • Добавление подключения для устройства сетевой службы

   Совет

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

   [!CAUTION>
   Не изменяйте шаблон службы шлюза для обеспечения высокой доступности виртуальных машин. Шаблон службы шлюза намеренно оставляет снятым флажок Сделать эту виртуальную машину машиной высокой надежности в области Дополнительно\Доступность. Виртуальные машины настраиваются как узлы гостевого кластера, и важно не изменять этот параметр. В противном случае при отработке отказа адреса клиента не сопоставляются с новым адресом поставщика, и шлюз будет работать неправильно.

7. Проверьте функциональность шлюза.

   Убедитесь, что возможно взаимодействие между тестовой виртуальной машиной и узлами, расположенными в тестовой сети клиента.

   Для проверки правильности взаимодействия шлюза и сетей виртуальных машин выполните следующие действия.

   1. Установите VPN-подключение типа «сеть — сеть».

      Порядок подключения тестовой сети клиента будет зависеть от оборудования, используемого для установления VPN-подключения. Одним из способов подключения к шлюзу является удаленный доступ (который объединяет в себе службу маршрутизации и удаленного доступа (RRAS) и прямой доступ). Пример процедуры с использованием RRAS для подключения к шлюзу см. в подразделе «Установка RRAS на Contoso EDGE1 и создания VPN-подключения типа «сеть — сеть» к GatewayVM1 под управлением HNVHOST3" раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

      Совет

      Требования к возможностям подключения для других VPN-устройств аналогичны требованиям к VPN-подключениям для Windows Azure. Дополнительные сведения см. в разделе Сведения о VPN-устройствах для виртуальной сети

   2. Просмотрите VPN-подключение типа «сеть — сеть» на шлюзе.

      После установки VPN-подключения можно использовать некоторые команды Windows PowerShell, а также некоторые новые параметры проверки связи.

      Пример процедуры в тестовой среде см. в подразделе «Просмотр VPN-подключений типа «сеть — сеть» на GatewayVM1» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

   3. Разверните тестовые виртуальные машины клиента.

      После подтверждения успешного подключения типа «сеть — сеть» к шлюзу можно развернуть тестовую виртуальную машину и подключить ее к сети тестовых виртуальных машин в сети поставщика услуг размещения.

      Пример процедуры в тестовой среде см. в подразделе «Шаг 2. Развертывание виртуальных машин клиента» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

   4. Проверьте взаимодействие с сетью тестовых виртуальных машин и работу виртуализации сети Hyper-V типа «сеть — сеть».

      После развертывания тестовой виртуальной машины убедитесь, что она имеет сетевое подключение к удаленным ресурсам в локальной сети клиента через Интернет посредством мультитенантного шлюза типа «сеть — сеть».

      Пример процедуры в тестовой среде см. в подразделе «Проверка сетевого подключения для виртуальных машин APP2» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

8. Развертывание Windows Server IPAM (рекомендуется).

   Компонент Windows Server IPAM интегрирован в VMM, чтобы управлять пространством IP-адресов для инфраструктуры структуры и клиента. Дополнительные сведения см. в разделе Развертывание IPAM-сервера.

   Пример процедуры в тестовой среде см. в подразделе «Шаг 6. Установка и настройка IPAM на HNVHOST2" раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

   После развертывания IPAM настройте подключаемый модуль IPAM VMM. Дополнительные сведения см. в разделе Добавление IPAM-сервера в VMM в System Center 2012 R2.

   Пример процедуры в тестовой среде см. в подразделе «Настройка подключаемого модуля на HNVHOST2» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

   После завершения этого шага убедитесь, что виртуализированное адресное пространство можно просмотреть в IPAM.

   Пример процедуры в тестовой среде см. в подразделе «Просмотр виртуализированного адресного пространства с помощью IPAM» раздела Руководство по лаборатории тестирования. Виртуализация сети Hyper-V Windows Server 2012 R2 с использованием System Center 2012 R2 VMM.

9. Разверните портал самообслуживания клиентов.

   Портал самообслуживания клиентов позволит вашим клиентам создать собственные виртуальные сети и виртуальные машины при минимальном участии поставщика услуг размещения. Поставщики услуг могут разрабатывать и внедрять мультитенантные порталы самообслуживания, в которые интегрированы возможности IaaS, доступные в System Center 2012 R2. Service Provider Foundation (SPF) предоставляет расширяемую веб-службу OData, которая взаимодействует с VMM.

   Windows Azure — это решение портала самообслуживания корпорации Майкрософт, которое интегрируется с VMM с помощью SPF. Оно предоставляет собой веб-портал, аналогичный Windows Azure, поэтому если ваши клиенты также являются клиентами Windows Azure, они уже будут знакомы с пользовательским интерфейсом в Windows Azure. Чтобы продемонстрировать компоненты Windows Azure для этого решения, используется экспресс-развертывание Windows Azure. Оно разворачивает необходимые компоненты на отдельном сервере. Если вы хотите развернуть Windows Azure в рабочей среде, следует использовать распределенное развертывание. Дополнительные сведения см. в разделе Требования к установке Windows Azure Pack.

   1. Создайте виртуальную машину WAPPortal.

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

   2. Установите необходимые программные компоненты.

      Выполните процедуру, описанную в разделе Установка необходимых программных компонентов.

   3. Установите экспресс-развертывание Windows Azure Pack.

      Выполните процедуру, описанную в разделе Установка экспресс-развертывания Windows Azure Pack.

   4. Ознакомьтесь с подразделами раздела Подготовка облаков виртуальных машин, а затем с инструкциями в разделе Требования для использования облаков виртуальных машин.

   5. Создайте облако с помощью VMM.

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

      Свойства	Настройки
      Общие проблемы	Имя. Золотой
      Ресурсы	Группа узлов: Вычисление
      Логические сети	Виртуализация сети
      Классификации портов	Высокая пропускная способность
      Хранилище	Удаленное хранилище
      Библиотека	VMM-Lib (общая папка на масштабируемом файловом сервере)
      Емкость	Емкость облака: установите требуемое значение

      Дополнительные сведения о создании облака в VMM см. в разделе Создание частного облака из групп узлов.

   6. Установите Service Provider Foundation на отдельной виртуальной машине, расположенной на кластере управления и инфраструктуры, с помощью процедуры, описанной в разделе Установка Service Provider Foundation для System Center 2012 SP1.

   7. Настройте SPF на использование с Windows Azure, как описано в подразделе Настройка порталов для Service Provider Foundation раздела «Настройка Windows Azure Pack для Windows Server».

      После завершения процедуры регистрации конечной точки SPF для облаков виртуальных машин вы увидите облако, созданное в VMM, на портале администратора Windows Azure.

   8. На портале администратора Windows Azure составьте план, который можно использовать для проведения тестирования. Например, можно создать план с именем Золотой план и следующими свойствами:

      Свойства	Настройки
      Имя	Золотой план
      Службы	Облака виртуальных машин

      После создания плана щелкните его, чтобы продолжить настройку. Щелкните службу Облака виртуальных машин и настройте Сервер управления VMM, Облако виртуальной машины и пределы использования. Нажмите кнопку Сохранить для завершения настройки облаков виртуальных машин. Нажмите кнопку «Назад» и выберите Изменить доступ, чтобы сделать план общедоступным.

   9. Создайте ресурс коллекции Windows Azure. Клиенты могут использовать коллекцию для размещения виртуальных машин в своих виртуальных сетях. Дополнительные сведения см. в разделе Загрузка и установка ресурсов коллекции Windows Azure Pack.

   10. На странице входа в систему портала клиентов Windows Azure щелкните элемент Зарегистрироваться для регистрации тестовой учетной записи клиента.

       Перейдите на портал клиентов, добавьте подписку и выберите план.

   11. После создания учетной записи создайте новую виртуальную сеть для клиента с помощью элемента Настраиваемое создание.

       После завершения создания сети убедитесь, что она существует в VMM в разделе Сети виртуальных машин.

   12. Установите VPN-подключение типа «сеть — сеть» с тестовым клиентом, как уже делали ранее при создании виртуальной сети для ручного тестирования.

   13. Создаете новую роль виртуальной машины с помощью ранее созданной коллекции.

   14. После создания тестовой виртуальной машины убедитесь в наличии подключения к сети клиента через туннель VPN типа «сеть — сеть».

Дополнительные конфигурации

В этом разделе описываются необязательные конфигурации для добавления функциональности в данное решение.

Развертывание шлюза переадресации для поддержки подключенных к Интернету виртуальных машин

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

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

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

Вот как это сделать:

1. Разверните шлюз с помощью шаблона службы таким же образом, как и в исходном решении.

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

3. Создайте в VMM новую сетевую службу для развертывания службы шлюза переадресации. Используйте строку подключения, аналогичную следующей:

   VMHost=gateway-cl.adatum-gw.lab;GatewayVM=FGWCL01.adatum-gw.lab;BackendSwitch=VMSwitch;DirectRoutingMode=True;FrontEndServerAddress=131.107.0.55

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

   1. Создайте отдельную подсеть для каждого клиента. Например:

5. Поместите виртуальные машины клиентов в соответствующие подсети.

6. Чтобы изолировать виртуальные машины, ознакомьтесь с разделом Расширенные списки управления доступом к портам и запустите командлеты на узле VMM. Настройте порты и протоколы, необходимые для виртуальных машин клиента.

   Важно!

   Перед выполнением следующих командлетов необходимо установить на узле VMM модуль PowerShell Hyper-V. Для этого используется командлет PowerShell Install-WindowsFeature hyper-v-powershell

   Пример:

   $vm = get-scvirtualMachine -Name "<имя_компьютера>"
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn –VMName $vm.Name –Direction in  –Action Allow -Weight 15 -localport 68 -Protocol udp –Stateful $true
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action allow -Weight 12 -RemotePort 53 -Protocol udp -Stateful $true
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action allow -Weight 11 -LocalPort 443 -Protocol tcp -Stateful $true
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action allow -Weight 10 -LocalPort 80 -Protocol tcp -Stateful $true
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn –VMName $vm.Name –Direction in  –Action Allow -Weight 10 -localport 80 -Protocol tcp –Stateful $true
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action deny  -Weight 1
   Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction in  -Action deny  -Weight 1
   

   Пример для удаления списков ACL с виртуальной машины.

   $vm = get-scvirtualMachine -Name "<имя_компьютера>"
   Get-VMNetworkAdapterExtendedacl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name | Remove-VMNetworkAdapterExtendedAcl
   

См. также