Edge gateway что это значит

vCloud Director Extender: миграция

В этой статье будет рассмотрена процедура расширения сети предприятия в облако провайдера посредством компонента VMware NSX® Edge™ Gateway Standalone. А также детально разобраны виды миграции виртуальных машин.

Прежде чем приступать к миграциям и настройке сети, необходимо убедиться в том, что все компоненты инфраструктуры развернуты, настроены и запущены. О том, как развернуть и настроить инфраструктуру VMware vCloud Director® Extender, можно посмотреть в предыдущей статье.

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

Подключение к инфраструктуре vCloud Director

Управление инфраструктурой vCloud Director осуществляется в интерфейсе VMware vCenter Server®. Чтобы добавить новое облако:

Provider Cloud Name — произвольное имя, под которым будет отображаться данное подключение

Provider Cloud URL — ссылка на публичное облако с указанием имени организации

vCD Extender Cloud Service URL — ссылка на публичный адрес vCloud Extender, развернутого у провайдера

Развертывание NSX Edge Gateway Standalone и настройка сети

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

Подготовим виртуальный дата-центр для взаимодействия с vCloud Director Extender:

Конвертация займет не более пары минут, при этом возможно пропадание сетевой доступности маршрутизатора на 20-30 секунд.

Важно обратить внимание, что сеть должна быть создана как саб-интерфейс. Отметьте чекбокс в графе Create as subinterface.

В открывшемся окне L2 Appliance Configuration укажите параметры размещения виртуальной машины апплайнса: папку, кластер, датастор и имя порт-группы.

Также, в графе Uplink Network Pool IP задайте IP-адрес будущей виртуальной машины, введя его в поле и нажав кнопку ADD. Не забудьте указать адрес шлюза и сетевой префикс. Нажмите CREATE.

Select Source → Network — выберите локальную порт-группу, сеть которой будем «растягивать».

Select Target → vDC — выберите целевой виртуальный дата-центр.

Select Target → Network — выберите созданную ранее сеть.

В процессе развертывания NSX Edge Gateway Standalone создается дополнительная транковая порт-группа и развертывается OVF-шаблон самой виртуальной машины. Через пару минут все будет готово, и туннельное соединение с облаком будет установлено.

Виды миграции

Любую миграцию можно осуществить, перейдя на вкладку Migrations и нажав на кнопку NEW MIGRATION. Мигрировать можно как по одной виртуальной машине, так и группами.

Далее по порядку рассмотрим все типы миграции. И первой будет «холодная» миграция (Cold Migration).

Холодная миграция (Cold Migration)

Выберите тип миграции Cold Migration и далее следуйте указаниям мастера.

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

Заметим, что группировка виртуальных машин при миграции в один vApp отрабатывает не так, как ожидалось, что приводит к неудачной миграции всех виртуальных машин кроме одной, поэтому выберите Each VM stays individually.

Продолжительность миграции зависит от пропускной способности интернет-канала и размера виртуальной машины.

Горячая миграция (Warm Migration)

Для выполнения «горячей» миграции:

Выполнение «горячей» миграции возможно только на включенных виртуальных машинах.

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

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

Миграция на предварительно загруженную копию (Warm Migration with Preloaded Seed)

Миграция «на предварительно загруженную копию» отличается от обычной «горячей» миграции тем, что при миграции необходимо будет указать эту самую копию. Сама копия может быть загружена как OVF-шаблон через интерфейс vCloud Director, так и на копию, предварительно смигрированную «на холодную». Копия виртуальной машины в облаке, на которую будем «накатывать» репликацию, должна быть выключена.

Следует заметить, что на шаге Select a Target Cloud будет доступно выпадающее меню со списком выключенных виртуальных машин в целевом дата-центре.

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

После того, как были проведены миграции, виртуальные машины доступны для управления через интерфейс vCloud Director.

Сценарии использования миграции в облако VMware

В качестве наиболее актуальных сценариев использования решения vCloud Extender можно рассматривать следующие варианты:

Миграция инфраструктуры предприятия в облако

Данный процесс можно разделить на несколько этапов:

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

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

Перенос преднастроенных сервисов с целью повышения отказоустойчивости инфраструктуры

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

Заключение

В данной статье была рассмотрена возможность vCloud Director Extender по масштабированию сети предприятия в облаке VMware vCloud. Так же был дан обзор трем видам миграции: «холодной», «горячей» и «на предварительно загруженную копию». Как видно из вышеописанного, процедура миграции, как и процесс инсталляции компонентов, не требует особых знаний и навыков, выходящих за рамки компетенций системного администратора предприятия.

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

Тем не менее, несмотря на всю кажущуюся простоту процесса миграции в облако, к данному процессу следует отнестись ответственно и внимательно. Самым важным этапом является не сама миграция, а ее подготовка и планирование. Грамотно составленный и протестированный план поможет сэкономить время, нервы, деньги и сохранит спокойный сон!

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

Источник

VMware NSX для самых маленьких. Часть 6. Настройка VPN

Сегодня мы посмотрим на возможности настройки VPN, которые предлагает нам NSX Edge.

В целом мы можем разделить VPN-технологии на два ключевых вида:

IPsec

В этом примере мы использовали PSK для аутентификации пира, но возможен также вариант с аутентификацией по сертификатам. Для этого нужно перейти во вкладку Global Configuration, включить аутентификацию по сертификатам и выбрать сам сертификат.

Кроме того, в настройках сайта необходимо будет поменять метод аутентификации.

Отмечу, что количество IPsec-туннелей зависит от размера развернутого Edge Gateway (об этом читайте в нашей первой статье).

SSL VPN

SSL VPN-Plus – один из вариантов Remote Access VPN. Он позволяет отдельным удаленным пользователям безопасно подключаться к частным сетям, находящимся за шлюзом NSX Edge. Зашифрованный туннель в случае SSL VPN-plus устанавливается между клиентом (Windows, Linux, Mac) и NSX Edge.

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

Переходим во вкладку IP Pools и жмем +.

Ниже в этом окне можно указать параметры клиента для Windows. Выбираем:

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

L2 VPN

L2VPN понадобится в том случае, когда нужно объединить несколько географически
распределенных сетей в один broadcast-домен.

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

В нашей тестовой среде соединим друг с другом две площадки, назовем их, соответственно, A и B. У нас есть два NSX и две одинаково созданные маршрутизируемые сети, привязанные к разным Edge. Машина A имеет адрес 10.10.10.250/24, машина B – 10.10.10.2/24.

Возвращаемся в интерфейс NSx Edge/ Переходим на вкладку VPN —> L2VPN. Включаем L2VPN, выбираем режим работы Server, в настройках Server Global указываем внешний IP-адрес NSX, на котором будет слушаться порт для туннеля. По умолчанию, сокет откроется на 443 порту, но его можно поменять. Не забываем выбрать настройки шифрования для будущего туннеля.

В Egress Optimization Gateway Address задаем адрес шлюза. Это нужно для того, чтобы не происходил конфликт IP-адресов, ведь шлюз у наших сетей имеет один и тот же адрес. После чего нажимаем на кнопку SELECT SUB-INTERFACES.

Заходим на NSX стороны B, переходим в VPN —> L2VPN, включаем L2VPN, устанавливаем L2VPN mode в клиентский режим работы. На вкладке Client Global задаем адрес и порт NSX A, который мы указывали ранее как Listening IP и Port на серверной стороне. Также необходимо выставить одинаковые настройки шифрования, чтобы они согласовались при поднятии туннеля.

Проматываем ниже, выбираем сабинтерфейс, через который будет строиться туннель для L2VPN.
В Egress Optimization Gateway Address задаем адрес шлюза. Задаем user-id и пароль. Выбираем сабинтерфейс и не забываем сохранить настройки.

На этом про VPN на NSX Edge у меня все. Спрашивайте, если что-то осталось непонятным. Также это последняя часть из серии статей по работе с NSX Edge. Надеемся, они были полезны 🙂

Источник

VMware NSX для самых маленьких. Часть 1

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

Около каких-то правил, если повезет, прописаны комментарии «Попросил сделать Вася» или «Это проход в DMZ». Сетевой администратор увольняется, и все становится совсем непонятно. Потом кто-то решил почистить конфиг от Васи, и упал SAP, потому что когда-то Вася просил этот доступ для работы боевого SAP.

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

VMWare NSX – платформа виртуализации и обеспечения безопасности сетевых сервисов. NSX решает задачи маршрутизации, коммутации, балансировки нагрузки, файрвола и умеет много другого интересного.

NSX – это преемник собственного продукта VMware vCloud Networking and Security (vCNS) и приобретенного Nicira NVP.

От vCNS к NSX

Раньше у клиента в облаке, построенном на VMware vCloud, была отдельная виртуальная машина vCNS vShield Edge. Он выполнял роль пограничного шлюза, где можно было настроить множество сетевых функций: NAT, DHCP, Firewall, VPN, балансировщика нагрузки и пр. vShield Edge ограничивал взаимодействие виртуальной машины с внешним миром согласно правилам, прописанным в Firewall и NAT. Внутри сети виртуальные машины общались между собой свободно в пределах подсетей. Если очень хочется разделять и властвовать трафиком, можно сделать отдельную сеть для отдельных частей приложений (разных виртуальных машин) и прописать в файрволе соответствующие правила по их сетевому взаимодействию. Но это долго, сложно и неинтересно, особенно когда у вас несколько десятков виртуальных машин.

В NSX VMware реализовала концепцию микросегментации с помощью распределенного файрвола (distributed firewall), встроенного в ядро гипервизора. В нем прописываются политики безопасности и сетевого взаимодействия не только для IP- и MAC-адресов, но и для других объектов: виртуальных машин, приложений. Если NSX развернут внутри организации, то такими объектами могут стать пользователь или группа пользователей из Active Directory. Каждый такой объект превращается в микросегмент в своем контуре безопасности, в нужной подсети, со своей уютненькой DMZ :).

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

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

На смену самому пограничному шлюзу vCNS vShield Edge пришел NSX Edge. У него есть весь джентльменский набор старого Edge плюс несколько новых полезных функций. Про них и пойдет речь дальше.

Что нового у NSX Edge?

Функциональность NSX Edge зависит от редакции NSX. Всего их пять: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Все новое и интересное можно увидеть только начиная с Advanced. В том числе и новый интерфейс, который до полного перехода vCloud на HTML5 (VMware обещает лето 2019-го) открывается в новой вкладке.

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

DHCP. Помимо настройки диапазона IP-адресов, которые будут автоматически выдаваться виртуальным машинам этой сети, в NSX Edge стали доступны функции Binding и Relay.

Во вкладке Bindings можно привязать MAC-адрес виртуальной машины к IP-адресу, если нужно чтобы IP-адрес не менялся. Главное, чтобы этот IP-адрес не входил в DHCP Pool.

Во вкладке Relay настраивается ретрансляция DHCP-сообщений DHCP-серверам, которые находятся за пределами вашей организации в vCloud Director, в том числе и DHCP-серверам физической инфраструктуры.

Маршрутизация. У vShield Edge можно было настраивать только статическую маршрутизацию. Здесь появилась динамическая маршрутизация с поддержкой протоколов OSPF и BGP. Также стали доступны настройки ECMP (Active-active), а значит и аварийное переключение типа «активный-активный» на физические маршрутизаторы.

Настройка OSPF

Настройка BGP

Еще из нового – настройка передачи маршрутов между различными протоколами,
перераспределение маршрутов (route redistribution).

L4/L7 Балансировщик нагрузки. Появился X-Forwarded-For для заголовка HTTPs. Без него все плакали. Например, у вас есть сайт, который вы балансируете. Без проброса этого заголовка все работает, но в статистике веб-сервера вы видели не IP посетителей, а IP балансировщика. Теперь все стало правильно.

Также во вкладке Application Rules теперь можно добавлять скрипты, которые будут напрямую управлять балансировкой трафика.

VPN. В дополнение к IPSec VPN, NSX Edge поддерживает:

SSL-сертификаты. На NSX Edge теперь можно поставить сертификаты. Это снова к вопросу, кому нужен был балансировщик без сертификата для https.

Группы объектов (Grouping Objects). В этой вкладке как раз задаются группы объектов, для которых будут действовать те или иные правила сетевого взаимодействия, например правила файрвола.

Этими объектами могут быть IP- и MAC-адреса.

Здесь также указан список сервисов (сочетание протокол-порт) и приложений, которые можно использовать при составлении правил файрвола. Новые сервисы и приложения добавлять может только администратор портала vCD.

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

Статус и статистику по каждому туннелю IPSEC VPN и L2 VPN.

Логирование. Во вкладке Edge Settings можно задать сервер для записи логов. Логирование работает для DNAT/SNAT, DHCP, Firewall, маршрутизации, балансировщика, IPsec VPN, SSL VPN Plus.

Для каждого объекта/сервиса доступны следующие типы оповещений:

— Debug
— Alert
— Critical
— Error
— Warning
— Notice
— Info

Размеры NSX Edge

В зависимости от решаемых задач и объемов VMware рекомендует создавать NSX Edge следующих размеров:

Ниже в таблице – рабочие метрики сетевых служб в зависимости от размера NSX Edge.

→ Источник

Из таблицы видно, что балансировку на NSX Edge для продуктивных сценариев рекомендуется организовывать, только начиная с размера Large.

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

Источник