Продукт NSX-T создавался как программно-определяемая организация виртуальных сетей для сред VMware и дружественных экосистем. Виртуальные сети декларируются вендором как целое самодостаточное направление виртуализации – масштабное и чрезвычайно полезное с точки зрения своей функциональности. И сегодня мы будем учиться базовым принципам их разворота.
Предваряя нижеследующее, рекомендуем обязательно ознакомиться с общими принципами дизайна NSX-T, изложенными в статье «Дизайн VMware NSX-T Data Center 3.1», и разобраться в соответствующей терминологии. А обо всех требованиях и подготовительных процессах будет рассказано здесь.
Также рассмотрим по отдельности рабочие процессы инсталляции NSX-T Data Center 3.1 для vSphere, KVM и Bare Metal Server.
Требования и совместимость
Перед тем, как приступать к практике разворота виртуальных сетей, стоит проверить исходные данные своих лицензий на совместимость с решением, а также узнать обо всех конфигурационных минимумах и максимумах, требованиях к топологии, чтобы реализация ранее намеченного генерального дизайна прошла успешно.
Системные требования к развороту NSX Manager и транспортных нод
Учитывая, что глобальная концепция виртуализации сетей опирается на деление всей их плоскости на гипотетические уровни (управления, контроля и данных), ее реализация упирается в использование двух типов нод: NSX Manager и транспортных.
NSX Manager
Любой разворот с нуля виртуальных сетей начинается с организации уровня управления и контроля, то есть – с инсталляции нод NSX Manager. Их в дальнейшем можно будет объединять в кластеры (трех-нодовые и только такие) для НА. Ноды NSX Manager могут ставиться только на поддерживаемые продуктом версии 3.1 хосты:
- ESXi,
- KVM.
Совместимость с версией гипервизора, по традиции, проверяем в «VMware Product Interoperability Matrices».
По vSphere ESXi это:
Важно! Функции авто-разворота и профили хостов поддерживаются исключительно в версиях vSphere 6.7 U1 и свежее.
Для KVM – RHEL 7.7 и Ubuntu 18.04.2 LTS.
Важно! На RHEL и Ubuntu команда «yum update» апдейтит версию ядра, которая не должна быть старше 4.19.х и рушит совместимость с NSX-T Data Center. Следует отключить автоматическое обновление ядра при использовании этой команды. После запуска «yum install» следует убедиться, что NSX-T Data Center поддерживает версию ядра.
С целью разворота NSX Manager устанавливается соответствующий Аppliance, доступный, в зависимости от будущих своих задач, в трех размерах:
- Small – для лабораторий и презентации функционала (4 CPU, 16 Гб памяти, 300 Гб диск),
- Medium – для разворотов с, максимум, 64 хостами (6 CPU, 24 Гб памяти, 300 Гб диск),
- Large – для крупных масштабируемых сред (12 CPU, 48 Гб памяти, 300 Гб диск).
Под него подготавливается shared-хранилище и хост(ы) со статическим IP-адресом (можно поменять после инсталляции), исключительно IPv4, а его имя не должно содержать запрещенных символов, таких как «_», «.» и т.д. Если вы пропустите такое имя, разворот автоматически его поменяет на «nsx-manager». Освежить в памяти информацию по не валидным именам виртуальной инфраструктуры можно здесь и здесь.
Лимиты конфигурации NSX Management Cluster
Как уже отмечалось, всего нод NSX Manager может быть только три. Полезной в разработке дизайна будет и информация о существующих максимумах в организации сети (L2/L3, файерволлинг, Load Balancing, служба самоанализа гостевых структурных единиц и сети, агрегация в облако, а также федерация). Руководствоваться ограничениями из таблиц лимитов.
Транспортные ноды
Поддерживаемые хостами транспортных нод гипервизоры:
- vSphere,
- CentOS Linux KVM,
- RHEL KVM,
- SUSE Linux Enterprise Server KVM,
- Ubuntu KVM.
Совместимость с версией гипервизора снова проверяем в «VMware Product Interoperability Matrices». Поддерживаемая версия CentOS Linux KVM – 7.7/8.2, RHEL KVM – 7.7/8.2, SUSE Linux Enterprise Server KVM – 12 SP4, Ubuntu KVM – 18.04.2 LTS, 20.04 LTS.
По vSphere ESXi – все аналогично NSX Manager.
Требования к аппаратной части:
| Гипервизор | CPU | Память, Гб |
| vSphere | 4 | 16 |
| CentOS Linux KVM | 4 | 16 |
| RHEL KVM | 4 | 16 |
| SUSE Linux Enterprise Server KVM | 4 | 16 |
| Ubuntu KVM | 4 | 16 |
NSX Edge
Так как ВМ и bare-metal форм-факторы NSX Edge имеют ряд кардинальных отличий, требования по подготовке к их установке также отличаются.
NSX Edge ВМ
Перед инсталляцией ВМ Edge-нод, следует убедиться в следующем:
- В процессе используются исключительно хосты ESXi c Intel или AMD-чипсетами;
- Если планируется включать режим vSphere EVC, CPU должен быть Haswell или более позднего поколения;
- В наличии только VMXNET3 vNIC.
Разворот виртуальных машин Edge-нод может производиться в таких размерах (системные требования к каждому приведены в таблице):
| Размер | Память, Гб | vCPU | Диск, Гб | Версия аппаратного оборудования | Примечания |
| Small | 4 | 2 | 200 | 11+ | Для лабораторий и концептуальных демонстраций. L7-правила не реализованы на Т1-шлюзе |
| Medium | 8 | 4 | 200 | 11+ | Продакшен-среды с балансировкой нагрузки |
| Large | 32 | 8 | 200 | 11+ | Продакшен-среды с балансировкой нагрузки. |
| Extra Large | 64 | 16 | 200 | 11+ | Продакшен-среды с балансировкой нагрузки. |
Отдельно стоит выделить требования к CPU при развороте ВМ Edge-нод:
- Должна быть возможность AES-NI;
- Поддержка 1 GB Huge Page;
- Марка и версия:
- Intel (Xeon E7-xxxx Westmere-EX поколение и новее, Xeon 56xx Westmere-EP, Xeon E5-xxxx Sandy Bridge поколение и новее, все поколения Xeon Platinum, Xeon Gold, Xeon Silver, Xeon Bronze);
- AMD (EPYC 7XX1-серия Naples, EPYC 3000 Embedded Family и новее, EPYC 7XX2-серия Rome).
NSX Edge bare-metal
Для разворота bare-metal Edge-ноды, нужно иметь, минимум, 32 Гб памяти, 8 CPU и 200 Гб дискового пространства. Рекомендовано по best practice: 256 Гб памяти, 24 CPU и 200 Гб дискового пространства.
Для поддержки DPDK необходимо следующее:
- CPU должен иметь возможность AES-NI и поддерживать 1 GB Huge Page;
- Марка и версия аналогичны случаю с ВМ Edge-нодой (см. выше).
Совместимость с аппаратной частью следует проверять на этой странице.
Требования к сетевому адаптеру:
Системные требования к Bare Metal Server
Перед установкой Bare Metal Server следует убедиться, что:
- Значение MTU установлено на 1 600 для поддержки сетевым адаптером или драйверами ОС Jumbo frame;
- Хосты Ubuntu должны быть проапгрейджены до версии 18.04.2 LTS, либо проинсталлированы с нуля.
В разрезе операционных систем требования к их версиям и аппаратной части следующие:
Требования к NIC хоста гипервизора и задержке
Убедиться в поддержке NIC-карт версией ESXi, на которой запущен NSX-T Data Center, можно в VCG, выбрав под «I/O Device Type» – «Network», и опционально, чтобы использовать GENEVE-инкапсуляцию, под «Features» – «GENEVE options». Также если необходимо применять Enhanced Data Path, выбираем «N-VDS Enhanced Data Path».
Обязательно следует загрузить поддерживаемые NIC драйвера со страницы загрузок VMware для соответствующих карт, если нужен Enhanced Data Path:
Максимальная задержка между всеми NSX Manager в кластере – 10 мс. Максимальная задержка между NSX Manager и транспортными нодами – 150 мс.
Требования к хранилищу
Рекомендовано устанавливать NSX Manager на хранилище общего доступа. Обязательно настроить на хранилище НА, чтобы избежать переноса файловой системы менеджера в режим «только для чтения» при некоторых событиях или сбоях.
Требования к браузеру
С NSX Manager совместимы следующие браузеры в разрезе желаемых ОС:
Важно! Internet Explorer не поддерживается.
Еще несколько замечаний к выбору браузера:
- Минимальное поддерживаемое разрешение – 1280х800 рх;
- Языки локализации NSX Manager: английский, немецкий, французский, японский, испанский, корейский, упрощенный и традиционный китайский.
Порты и протоколы
Система портов и протоколов обеспечивают связь от ноды к ноде в NSX-T Data Center, при этом пути должны быть защищены и аутентифицированы. Место хранения учетных данных применяется для установки факта взаимной аутентификации.
Порты и протоколы следует открыть и на физическом файерволе, и на файерволе хоста гипервизора. Список нужных портов и протоколов с описанием связанной службы:
По умолчанию все сертификаты являются самоподписанными. GUI и API северного направления, а также приватные ключи могут быть замещены СА-подписанными сертификатами.
Существуют внутренние демоны, общающиеся через петли или сокеты доменов UNIX:
- KVM – MPA, OVS;
- ESXi – nsx-cfgagent, ESX-DP (в ядре).
Важно! Для доступа к нодам NSX-T Data Center необходимо включить на них SSH.
Случай с портами и протоколами при развороте NSX Cloud в данном гайде не рассматривается. В планах выпустить серию статей по cloud-решениям VMware – там и будет подробно про это рассказано.
Подготовка к инсталляции NSX-T Data Center 3.1
Когда все требования по совместимости, аппаратные и прочие, перечисленные выше, соблюдены, а необходимые порты и протоколы открыты и сконфигурированы, можно приступать непосредственно к подготовке виртуальных сетей.
Подготовка к инсталляции NSX-T Data Center в vSphere
Если будем работать со средой vSphere, какой-то специфической подготовки, кроме описанных выше шагов, не требуется, так как подразумевается, что мы имеем дело с сопоставимой версией ПО, организованными хранилищами и прочими аспектами. О том, как проапдейтить свою vSphere и ее компоненты до последней версии, мы писали в статье «Инсталляция и разворот VMware vSphere 7.0».
Особенности установки NSX-T Data Center на Bare Metal Server
Стоит привести пару замечаний по поводу подготовки к инсталляции NSX-T Data Center на Bare Metal Server. Некоторые процедуры разворота могут потребовать разрешения командой «sudo». Как и в случае KVM, нужно будет проинсталлировать сторонние пакеты на физический сервер.
Кроме того, для разворотов на Bare Metal Server следует обеспечить доступность PXE-сервера в среде. Он устанавливается любой из Linux-дистрибутивов, и должен обладать двумя интерфейсами – один для внешней коммуникации, и другой для обеспечения IP DHCP и TFTP-сервисов. Подробно его подготовка будет расписана ниже – в разделе про разворот NSX-T Data Center на Bare Metal Server.
Инсталляция сторонних пакетов на физический сервер
- На Ubuntu запускаем команду «apt-get install <package_name>», где <package_name> для:
- Ubuntu 18.04.2:
-
- Ubuntu 16.04:
- На RHEL, CentOS, and Oracle Linux запускаем «yum install» для:
- RHEL 7.8/7.7/7.6:
-
- CentOS 7.8/7.7/7.6:
-
- Oracle Linux 7.6 и 7.7:
- На SUSE запускаем «zypper install <package_name>», где <package_name>:
Подготовка к инсталляции NSX-T Data Center на KVM
Что же касается KVM, вначале следует подготовить его среду, установив сам KVM.
Важно! В этом случае протокол Geneve-инкапсуляции использует порт 6081 – его надо открыть на файерволе KVM-хоста.
Напомним эту процедуру:
- Открываем файл «/etc/yum.conf» и ищем в нем строку «exclude»;
- Добавляем в ней «exclude=[existing list] kernel* redhat-release*», чтобы избежать любых неподдерживаемых RHEL апгрейдов;
Важно! Если планируется использовать NSX-T Data Center Container Plug-in, вместо этой строчки вписываем такую:
exclude=[existing list] kernel* redhat-release* kubelet-* kubeadm-* kubectl-* docker-*
- Далее, в зависимости от типа дистрибуции вводим следующие команды:
-
- Ubuntu:
apt-get install -y \
qemu-kvm \
libvirt-bin \
ubuntu-vm-builder \
bridge-utils \
virtinst \
virt-manager \
virt-viewer \
libguestfs-tools
-
- RHEL или CentOS Linux:
yum groupinstall “Virtualization Hypervisor”
yum groupinstall “Virtualization Client”
yum groupinstall “Virtualization Platform”
yum groupinstall “Virtualization Tools”
-
- Для SUSE Linux Enterprise Server запускаем YaSt и выбираем «Virtualization» – «Install Hypervisor and Tools».
- Чтобы NSX Manager автоматически проинсталлировал весь свой софт на KVM-хосте, следует подготовить сетевую конфигурацию «uplink/data»-интерфейса. Для этого в Ubuntu следует заполнить файл «/etc/network/interfaces», а в RHEL, CentOS или SUSE – «/etc/sysconfig/network-scripts/ifcfg-$uplinkdevice» таким образом:
-
- Ubuntu (в «/etc/network/interfaces»):
auto eth0
iface eth0 inet manual
auto ens32
iface ens32 inet manual
-
- RHEL, CentOS (в «/etc/sysconfig/network-scripts/ifcfg-ens32»):
DEVICE=”ens32″
TYPE=”Ethernet”
NAME=”ens32″
UUID=”<something>”
BOOTPROTO=”none”
HWADDR=”<something>”
ONBOOT=”yes”
NM_CONTROLLED=”no”
-
- SUSE Linux Enterprise Server (в «/etc/sysconfig/network/ifcfg-ens32»):
DEVICE=”ens32″
NAME=”ens32″
UUID=”<UUID>”
BOOTPROTO=”none”
LLADDR=”<HWADDR>”
STARTMODE=”yes”
- Перезапускаем сетевую службу командой «systemctl restart network» или просто перезагружаем сервер, чтобы сделанные изменения применились.
Важно! Нельзя создавать индивидуальные сетевые конфигурационные файлы в Ubuntu – все изменения указываются исключительно в «/etc/network/interfaces». Иначе нода просто не установится.
Инсталляция сторонних пакетов на KVM-хост
Без описанных ниже рекомендаций не обойтись в процессе подготовки транспортной ноды KVM. Заметим, вначале нужно пройти все обязательные пункты подготовки соответствующей среды.
Для RHEL и CentOS Linux, если какие-то пакеты вышеописанной процедурой не установились, это делается вручную командой:
yum install glibc.i686 nspr
Для SUSE Linux Enterprise Server перед инсталляцией сторонних пакетов необходимо запустить:
libcap-progs
Сама процедура в разрезе ОС выглядит следующим образом:
- В Ubuntu запустить команду «apt-get install <package_name>», где <package_name> это:
- 04.2 LTS версия:
-
- 04.2 LTS-версия:
- Для RHEL and CentOS Linux запустить «yum install <package_name>», где <package_name> – это:
- RHEL 7.7 и CentOS 7.7:
-
- RHEL 8.2 и CentOS 8.2:
- На SUSE Linux Enterprise Server 12.0 запустить «zypper install <package_name>», где <package_name> – это:
Организация аутентификации
Аутентификация в процессе установки NSX Manager Virtual Appliance играет важную роль. После установки доступ может организовываться тремя путями:
- через браузер в NSX UI,
- через CLI в NSX Manager,
- через API в NSX Manager.
В первом случае в адресную строку вводится FQDN или IP-адрес нового инстанса NSX Manager, после чего будет затребован логин и пароль:
Во втором, либо открывается SSH-сессия, либо используется консоль виртуальной машины. Для оформления запросов и настройки среды, можно получить список всех доступных команд через «list»:
Ввод придуманного в соответствии с назначенной ролью пароля потребуется в CLI в процессе установки Virtual Appliance. Доступные роли:
- Root (просмотр, разворот, настройка всего NSX, с использованием Linux-команд);
- Admin (просмотр, разворот, настройка всего NSX, с использованием CLI-команд);
- Audit (просмотр настроек, событий и отчетов – только чтение).
Доступ через Rest API полезен, когда его нет, по каким-либо причинам, через графический интерфейс, или же если хочется автоматизировать процессы скриптованием/другими инструментами. Отличная шпаргалка по использованию API конкретно под NSX находится здесь.
Требования к паролю ограничиваются следующими минимумами: 12 символов, 1 строчная буква, 1 заглавная, 1 цифра, 1 спецсимвол, 5 символов должны быть уникальными.
Важно! В Linux PAM задаются специальным образом характеристики допустимого пароля. В случае NSX Manager Virtual Appliance это:
retry=3 (количество попыток ввода нового пароля до возвращения ошибки),
minlen=12 (минимальный размер пароля),
difok=0 (минимальное кол-во байтов, которое должно отличаться в новом пароле),
lcredit=1 (максимальное кол-во строчных букв),
ucredit=1 (максимальное количество заглавных букв),
dcredit=1 (максимальное количество цифр),
ocredit=1 (максимальное количество других символов в пароле),
enforce_for_root (устанавливается как пароль рута).
Разворот NSX-T Data Center 3.1
Существует разница между разворотом виртуальных сетей на vSphere, KVM и bare-metal-хостах. Рассмотрим все по очереди.
Разворот NSX-T Data Center 3.1 на хостах vSphere
В целом, будем следовать такой процедуре:
- Установить NSX Manager;
- Сконфигурировать менеджер вычислений;
- Развернуть дополнительные ноды NSX Manager для формирования кластера;
- Проинсталлировать NSX Edge-ноды;
- Создать NSX Edge кластер;
- Назначить транспортные зоны;
- Создать хосты транспортных нод.
Приступим к воплощению пунктов этого плана на практике.
Установка NSX Manager Virtual Appliance на хостах vSphere
- Скачиваем со страницы загрузок продуктов VMware, в соответствии с уровнем купленной лицензии, соответствующий OVA-файл:
Отметьте, что на этой странице загрузок, помимо самого Appliance («NSX Manager/ NSX Global Manager / NSX Cloud Service Manager for VMware ESXi») предложен единственный загрузочный пакет, способный развернуть что базовую структуру, что GM, если сразу строится федерация, что cloud-приложение для соответствующего типа NSX. Мы пока остановимся на первом – самом простом варианте, чтобы понять принцип. Присутствуют там и другие полезные сопутствующие продукты, например, VMware vRealize Log Insight 8.2.0 for NSX, VMware Identity Manager 3.3.3, а также расширенный пакет для Enterprise Plus-лицензий (VMware vRealize Network Insight 6.0.0, VMware HCX и VMware NSX Intelligence 1.2.0). Они рекомендованы к инсталляции для полноценного функционирования каждого уровня лицензии, однако заняться ими можно и позже. VMTools уже встроены в инсталляционный пакет и запрещено их удалять или подвергать самостоятельному обновлению – только вместе с NSX;
- В клиенте vSphere выбираем хост/кластер, на котором будет развернут NSX-T Data Center, кликаем на нем правой кнопкой мыши и выбираем «Deploy OVF template», после чего запустится соответствующий визард:
Пробежимся по его пунктам последовательно. В первом, «Select an OVF template», ставим флажок на «Local file» и выбираем местоположение сохраненного OVA. «Next»;
- «Select a name and a folder». Придумываем имя виртуальной машины Appliance и указываем ее расположение:
«Next»;
- «Select a compute resource». Назначаем вычислительный ресурс для этой ВМ:
«Next»;
- «Review details». Проверяем все данные. «Next»;
- «Configuration». Здесь выбираем подходящий размер разворота:
«Next»;
- «Select storage». Определяемся с хранилищем (обязательно указать «Thin Provision»-формат виртуального диска для оптимизации и политику хранения – у нас пусть пока будет дефолтная):
«Next»;
- «Select networks». Выбираем сеть назначения и настройки расположения IP (обязательно статический и протокол IPv4):
«Next»;
- «Customize template». На этом пункте назначаем данные учетных записей для всех описанных выше в подразделе «Организация аутентификации» ролей (рута, админа CLI, аудита), а также сетевые свойства для нашей ВМ (имя хоста, роль, дефолтный шлюз IPv4, адрес и подсеть управления, DNS, путь к домену). Обязательно ставим галочку на «Enable SSH» и «Allow root SSH logins». Ниже будут «Internal Properties» – там крайне не рекомендуется что-либо менять:
«Next»;
- «Ready to complete». Проверяем все параметры, и, если все правильно, запускаем разворот виртуальной машины vApp NSX Manager.
Обычно инсталляция занимает несколько минут.
Добавление менеджера вычислений
Для управления ресурсами (хостами, ВМ) NSX-T Data Center нам необходимо зарегистрировать в NSX Manager менеджер вычислений. В случае vSphere пусть это будет vCenter Server. Именно от менеджера вычислений NSX-T Data Center будет получать информацию о кластере из vCenter Server.
Важно! Один и тот же vCenter Server не может использоваться более чем одним NSX Manager.
Перед тем, как перейти непосредственно к процедуре регистрации, следует определиться с привилегиями админского доступа на vCenter Server. В нем можно оставить дефолтные настройки, либо же создать собственную роль администратора с привилегиями из следующего списка:
Помимо них конкретно для этой цели регистрируемого vCenter Server, его администратор должен обладать рядом дополнительных разрешений:
После того, как завершилась инсталляция vApp NSX Manager, из браузера заходим на «https://<nsx-manager-ip-address>» под админским паролем, проверив, соответствуют ли его привилегии спискам. Далее нам предложат ознакомиться с EULA, ставим галочку, соглашаясь, и жмем «Continue». Следующее окошко предложит присоединиться к CEIP, после чего сохраняемся кнопкой «Save». После этого попадем в клиент NSX-T:
- В верхнем меню нажимаем на «System», после чего в левой панели под «Fabric» выбираем «Сompute Managers», и в соответствующей вкладке жмем на кнопку «Add»:
- В появившемся окне задаем имя нового менеджера вычислений, опционально – его описание, тип (у нас – vCenter), адрес, порт обратного прокси, данные учетной записи пользователя с соответствующими правами, обязательно передвигаем ползунок на «Enable Trust» в активное положение, после чего соглашаемся с регистрацией кнопкой «Add».
Важно! Если ничего не назначить в поле «SHA-256 Thumbprint», автоматически будет принят отпечаток, предложенный сервером.
Удачно назначенный в качестве менеджера вычислений vCenter будет показываться в соответствующем списке:
Там можно проверять впоследствии статус его подключения и главные параметры.
Важно! После регистрации vCenter Server нельзя выключать или удалять виртуальную машину NSX Manager, пока он не будет удален.
Важно! Нельзя удалить VC, если предварительно успешно:
-
Подготовлены с помощью VDS транспортные ноды, зависящие от этого VC;
-
Развернуты служебные ВМ на хосте или кластере в VC с использованием функции вставки служб в NSX;
-
Используется UI NSX Manager для разворота Edge-машин, NSX Intelligence или NSX Manager-нод на хосте или кластере в VC.
Если его удалить все-таки необходимо, вначале аннулируется все, что было перечислено.
Формирование кластера NSX Manager-нод на хостах vSphere
Для обеспечения НА и надежности функционирования создаваемой виртуальной сети, следует сформировать кластер из нод NSX Manager (ограничения и смысл этого действия описаны в статье «Дизайн VMware NSX-T Data Center 3.1»). В случае ESXi-хостов все очень удобно и просто разворачивается прямо из UI (другие типы хостов будут рассмотрены ниже – для них придется пользоваться исключительно CLI).
Разворот новой ноды автоматически подсоединяет ее к первой развернутой с целью формирования кластера. При этом все детали репозитория и учетной записи синхронизируются с новым его членом.
Сам процесс выглядит так:
- Заходим в браузере на https://<manager-ip-address> под учетной записью администратора;
- В верхнем меню выбираем «System», и в левом боковом ищем в разделе «Configuration» – «Appliances». В открывшейся справа вкладке нажимаем на большую кнопку «Add NSX Appliance»:
В появившемся окне визарда нужно пройти все его пункты.
- «Appliance Information». Вносим имя хоста, управляющий IP/подсеть, управляющий шлюз, DNS-сервера, NTP-сервера, а также размер разворачиваемой ноды (Small/Medium/Large):
«Next»;
- «Configuration». Указываем менеджер вычислений, кластер к которому он принадлежит, выбираем пул ресурсов, хост, дата-сторадж, формат виртуального диска (Thin Provision) и сеть:
«Next»;
- «Access & Credentials». Обязательно включаем ползунки на «Enable SSH» и «Enable Root Access», вводим данные учетной записи администратора для всех трех ролей (см. выше) и запускаем инсталляцию кнопкой «Install Appliance»:
Важно! Нельзя начинать разворот следующей ноды, пока не завершился предыдущий процесс. Если первая нода по какой-то причине уйдет в перезагрузку, пока инсталлируется новая нода, установка выдаст ошибку «Failed to Register». Если такое случится, придется вручную удалить неудачно созданную ноду и снова запустить разворот. Пока не закончилось удаление, те же сетевые данные использовать для другой ноды нельзя.
Обычно новая нода со всеми процессами синхронизации устанавливается за 10-15 минут.
Когда все три ноды будут добавлены, кластер сформируется автоматически. Информацию об эффективности функционирования нод в его составе можно получить из UI NSX, зайдя на вкладку «Home» в верхнем меню и выбрав в выпадающем меню «Monitoring Dashboard» – «System»:
Здесь будет только сигнализация о состоянии в режиме реального времени с использованием цветовой индикации, например, красный будет означать снижение производительности и т.д.
Статус самого кластера, а также все подробности о нодах в составе следует смотреть на вкладке «System» верхнего меню, где в «Configuration» выбираем «Appliance», после чего в появившемся справа информационном поле нажимаем на кнопку «View details»:
Разворот NSX Edge на хостах vSphere
Развернуть NSX Edge на ESXi можно тремя способами:
- Используя UI NSX Manager (рекомендованный метод);
- Прямо из веб-клиента vSphere или из командной строки OVF tool (Находим на странице загрузок продуктов VMware блок вида:
И загружаем соответствующий именно ESXi вариант NSX Edge OVA-файла. В клиенте vSphere ищем хост, на котором будем инсталлировать NSX Edge Аppliance, кликаем на нем правой кнопкой мыши и выбираем «Deploy OVF template», после чего откроется соответствующий мастер-установщик, в котором последовательно проходим все пункты);
- ISO-файлом для ВМ Аppliance на физическом сервере.
Мы пойдем первым, самым простым и безошибочным методом. Для этого:
- Заходим в UI NSX Manager на https://<nsx-manager-ip-address>. На вкладке «System» под «Configuration» в «Fabric» кликаем на «Nodes» – откроется пустой список справа, после чего нажимаем вверху него на кнопку «Add Edge VM»:
В результате запустится визард. Пробежимся по его пунктам:
«Name and description». Вписываем имя, имя хоста или FQDN, описание будущей ноды (по желанию) и выбираем ее форм-фактор (Small/Medium/Large):
«Next»;
- «Credentials». Ползунки все переводим в активное положение и вводим данные учетных записей для всех вышеупомянутых ролей:
«Next»;
- «Configure Deployment». Выбираем из списка нужный менеджер вычислений (ранее зарегистрированный нами в NSX Manager vCenter Server), кластер, пул ресурсов, хост и хранилище:
«Next»;
- «Configure Node Settings». Здесь в «IP Assignment» выбираем «Static» (почему именно так – рассказывалось в статье «Дизайн VMware NSX-T Data Center 3.1»), IP и дефолтный шлюз, а также управляющий интерфейс, доменное имя, DNS и NTP-сервера:
«Next»;
- «Configure NSX». Выбираем транспортные зоны, N-VDS из выпадающего меню (если ни одного заранее специально не подготовлено, нажимаем на кнопку «Add N-VDS», после чего вводим все его данные – имя, профиль аплинка, IP, IP пула ресурсов, интерфейс DPDK Fastpath):
Формировать транспортные зоны будем учиться ниже, а задавать профили аплинков, а также другим полезным в этой связи вещам – в следующей статье из посвященного NSX-T цикла «Администрирование и настройка VMware NSX-T Data Center 3.1».
По кнопке «Finish» стартуем разворот NSX Edge транспортной ноды.
Через какое-то время наша первая Edge-нода появится в списке «Transport Nodes» в таком виде:
Подключение Edge-ноды к уровню управления
Теперь нужно сделать Edge-ноду видимой из уровня управления. Для этого открываем SSH-сессию или консольное управление для того vApp NSX Manager, к которому необходимо ее привязать, а также SSH-сессию для ВМ NSX Edge-ноды. В vApp NSX Manager запускаем на выполнение команду:
get certificate api thumbprint
Выдаст что-то вроде такого (уникальное для каждого Appliance):
659442c1435350edbbc0e87ed5a6980d892b9118f851c17a13ec76a8b985f57
На виртуальной машине Edge-ноды запускаем команду вида:
NSX-Edge1> join management-plane <Manager-IP> thumbprint <Manager-thumbprint> username admin
где <Manager-IP> – айпишник нашего менеджера, <Manager-thumbprint> – отпечаток сертификата, кроме того в этой строке проставляются данные учетной записи администратора. Потом, когда создадим еще несколько Edge-нод с целью формирования кластера, на каждой их ВМ придется повторить то же самое.
Проверить, подключена ли Edge-нода к уровню управления можно, запустив команду «get managers» на каждой ВМ:
Создание кластера NSX Edge
Когда первая нода NSX Edge успешно развернулась, нам нужно создать кластер, чтобы заработали сервисы, вроде NAT, балансировщика нагрузки и прочих, была достигнута НА. С этой целью проходим следующую процедуру.
Заходим в NSX Manager на https://<nsx-manager-ip-address> под привилегиями администратора, на вкладке «System» в левой боковой панели ищем в выпадающем меню «Fabric» – «Nodes» и нажимаем на них. Тогда в правой части экрана появится поле со вкладками, где находим «Edge Clusters». Пока этот раздел пустой, но в верхней его части есть кнопка «Add», кликнув на которую перед нами откроется окно вида:
В нем сначала необходимо задать имя нового кластера и опционально – его описание. Также выбирается профиль, а в секции «Transport Nodes» в «Member Type» обязательно из выпадающего меню выбираем «Edge Node», после чего в левом из нижних двух блоков появится список доступных ТN – у нас одна. Ее выбираем и перемещаем в правый блок соответствующей кнопочкой («>»). Затем все ноды из правого блока аналогично отмечаем. После того, как все поля в этом окне заполнены, можно жать кнопочку «Save» и ждать, пока создастся наш новый кластер Edge.
Создание транспортных зон на хостах vSphere
О назначении и сути транспортных зон рассказывалось в статье «Дизайн VMware NSX-T Data Center 3.1». Сегодня же научимся их разворачивать на практике. Предваряя этот разговор, стоит заметить, что виртуальная сеть нуждается минимум в одной ТZ. В vSphere она создается несложно – снова-таки из клиента NSX Manager. Поэтому для начала заходим в него на https://<nsx-manager-ip-address>. Затем на вкладке «System» в левой панели в меню «Fabric» ищем «Transport Zones», кликнув на которые откроется соответствующий список (пока пустой) справа. Нажав в верхней части этого списка кнопку «Add», увидим окошко для задания всех параметров новой ТZ:
Здесь вписываем ее имя, описание (опционально), указываем имя свитча и тип трафика (у нас – Overlay, к примеру), если уже назначены политики тиминга, в соответствующем поле можно перечислить те, к которым мы хотим присоединить эту новосозданную TZ. После чего запускаем процесс кнопкой «Add» внизу.
После успешного создания, наша новая TZ появится в соответствующем списке:
Теперь можно создавать пользовательские профили транспортных зон и привязывать их к новым TZ. Проще всего это делать через POST API: «/api/v1/transportzone-profiles». Запуск процесса автоматический и пользователю при этом рабочий процесс не показывается, но, по завершению, вызвав PUT API: «/api/v1/transport-zones/<transport-zone-id>», – увидим, что новый профиль готов.
Разворот транспортных нод на хостах vSphere
Теорию транспортных нод, варианты их подключения и функционал мы подробно изучали в «Дизайн VMware NSX-T Data Center 3.1».
Вначале убеждаемся, что целевой хост с минимум одной неиспользуемой pNIC подсоединен к уровню управления, а его подключение в статусе «UP». Также важно, чтобы обратный прокси на всех нодах кластера NSX Manager тоже был «UP», сконфигурирована TZ, настроен пул IP или же был доступен DHCP. Учтите, что, если вручную не создавались профили аплинков (поговорим об этом в следующей статье цикла «Администрирование и настройка VMware NSX-T Data Center 3.1»), будут использоваться дефолтные.
Принципы процедуры разворота транспортной ноды, в принципе, ничем не отличается от описанной выше Edge. Но сейчас рассмотрим второй метод – через удобнейший автоматизированный помощник «Get Started». Для этого на вкладке «System» в левой панели кликаем на «Get Started», после чего в правой части экрана увидим три варианта задач – нам нужен средний, «Prepare NSX Transport Nodes»:
Кликнув на его кнопку перейдем в соответствующий визард, в котором последовательно пройдем все пункты. Заметим, пункты с 3 по 6 одинаковы и для соло-хоста, и для кластера, а вот первые стоит рассмотреть подробно и для того, и для другого вариантов:
- «Select Node Type». Здесь нужно выбрать тип ноды (это «Host Cluster», одинокий «Host» или «NSX Edge VM»). Если у нас это первая транспортная нода, выбираем средний пункт:
«Next»;
- «Select Host Claster». Здесь нужно выбрать хосты, которые будут включены в кластер транспортных нод или же создать новую ноду:
- Нод нет. Нажимаем «Add New Host»:
«Next»;
Откроется окошко, в котором привычно задаем имя хоста, IP-адрес, выбираем его тип (у нас, так как сейчас говорим про vSphere, это ESXi), вводим учетные данные администратора и, по желанию, «SHA-256 Thumbprint»:
Если в поле отпечатка ничего не указали, появится предупреждение, что система его сама назначит по своему усмотрению:
Соглашаемся кнопкой «YES».
Теперь в пункте визарда появится новый хост:
И можно будет перейти к следующему шагу по кнопке «Next»;
-
- Готовы несколько нод. Пункт «Select Host Claster» будет выглядеть так:
Из выпадающего меню выбираем подходящие TN для формирования кластера.
после чего жмем «Next»;
Важно! Если на выбранных хостах NSX до этого не устанавливался, появится предложение от системы автоматически его проинсталлировать:
Соглашаемся кнопкой «Install».
- «Select Transport Zone (East-West)». Выбираем нужную TZ из выпадающего списка:
«Next»;
- «Select Uplink Profile (East-West)». Назначаем подходящий профиль аплинка:
«Next»;
- «Link to Transport Zone (East-West)». Выбираем тип свитча (N-VDS или VDS), IP-настройки, включая тип IP (у нас пула), сам IP пула и в секции «Host NIC Connections» (скроллим страничку вниз) сопоставляем аплинки коммутатора и аплинки хоста:
- «Review». В этом пункте будет представлена визуализация сделанных нами назначений, проверяем, чтобы все соответствовало ранее разработанному дизайну, после чего запускаем инсталляцию транспортной ноды кнопкой «Finish»:
Удобно, что в процессе прохождения этого мастера-помощника, даже если предварительно не был назначен менеджер вычислений, не была создана транспортная зона, профиль аплинка и т.д., кликнув в тексте кона на соответствующее название (подчеркнутое как ссылка), перейдем на этап создания всего недостающего.
Подключение транспортной ноды к уровню управления
Аналогично «Подключение Edge-ноды к уровню управления» – см. выше.
Разворот NSX-T Data Center 3.1 на хостах KVM
Предварительно следует подготовить среду (см. раздел «Подготовка к инсталляции NSX-T Data Center 3.1», а также убедиться, что соблюдены все требования из раздела «Требования и совместимость»). Подготовленный соответствующим образом хост должен работать на bare-metal-сервере. В случае KVM план действий, в целом, будет следующим:
- Проинсталлировать NSX Manager;
- Установить стороннее ПО на KVM-хост;
- Развернуть дополнительные ноды NSX Manager и сформировать из них кластер;
- Создать NSX Edge-ноды и сформировать из них кластер;
- Назначить транспортные зоны;
- Развернуть транспортные ноды.
Этим и займемся по порядку.
Разворот NSX Manager на KVM
Важно! Нельзя устанавливать NSX Manager на KVM-хост, если этот хост используется как виртуальный Apppliance другого хоста (nested-инсталляция запрещена).
Инсталляция использует QCOW2-процедуру «guestfish» (инструмент командной строки Linux для прописывания параметров ВМ в QCOW2-файл). Единственный QCOW2-файл используется для разворота трех различных типов Appliance: NSX Manager, NSX Cloud Service Manager (CSM) под NSX Cloud и Global Manager (GM) для Федерации.
- Загружаем образ QCOW2 NSX Manager со страницы загрузок VMware из секции по KVM:
Подготавливаем три копии образов для работы NSX Manager с использованием SCP или синхронизации.
В случае Ubuntu добавляем пользователя, чьи учетные данные будут участвовать в развороте как libvirtd-пользователя:
adduser $USER libvirtd
- В директории, куда записывались QCOW2-образа, создаем три файла с именем «guestinfo.xml» и заполняем их свойствами ВМ NSX Manager (только для primary-версии, все последующие secondary такого не требуют), например, вот так:
<?xml version=”1.0″ encoding=”UTF-8″?>
<Environment
xmlns=”http://schemas.dmtf.org/ovf/environment/1″
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:oe=”http://schemas.dmtf.org/ovf/environment/1″>
<PropertySection>
<Property oe:key=”nsx_cli_passwd_0″ oe:value=”<password>”/>
<Property oe:key=”nsx_cli_audit_passwd_0″ oe:value=”<password>”/>
<Property oe:key=”nsx_passwd_0″ oe:value=”<password>”/>
<Property oe:key=”nsx_hostname” oe:value=”nsx-manager1″/>
<Property oe:key=”nsx_role” oe:value=”NSX Manager”/>
<Property oe:key=”nsx_isSSHEnabled” oe:value=”True”/>
<Property oe:key=”nsx_allowSSHRootLogin” oe:value=”True”/>
<Property oe:key=”nsx_dns1_0″ oe:value=”10.168.110.10″/>
<Property oe:key=”nsx_ntp_0″ oe:value=”10.168.110.10″/>
<Property oe:key=”nsx_domain_0″ oe:value=”corp.local”/>
<Property oe:key=”nsx_gateway_0″ oe:value=”10.168.110.83″/>
<Property oe:key=”nsx_netmask_0″ oe:value=”255.255.252.0″/>
<Property oe:key=”nsx_ip_0″ oe:value=”10.168.110.19″/>
</PropertySection>
</Environment>
С обязательным указанием следующих свойств:
| Свойство | Описание |
| nsx_cli_passwd_0 | Правила назначения учетных данных для трех доступных ролей см. в подразделе «Организация аутентификации» раздела подготовки к развороту NSX-T |
| nsx_cli_audit_passwd_0 | |
| nsx_passwd_0 | |
| nsx_hostname | Имя хоста NSX Manager |
| nsx_role | Если устанавливаем Appliance, вписываем «NSX Manager», если GM vApp – «NSX Global Manager», если CSM – «nsx-cloud-service-manager» |
| nsx_isSSHEnabled | Проставляем значение «True», так как нам нужен будет впоследствии доступ по SSH |
| nsx_allowSSHRootLogin | |
| nsx_dns1_0
nsx_ntp_0 nsx_domain_0 nsx_gateway_0 nsx_netmask_0 nsx_ip_0 |
Задаем IP-адрес для дефолтного шлюза, управляющей сети IPv4, подсети управляющей сети, DNS и IP-адрес NTP |
- Для записи созданных «guestinfo.xml» в образ QCOW2 используем команду «guestfish»:
sudo guestfish –rw -i -a nsx-unified-appliance-<BuildNumber>.qcow2 upload guestinfo /config/guestinfo
- Запускаем команду «virt-install» для разворота QCOW2 для RHEL-хостов:
sudo virt-install \
–import \
–ram 48000 \
–vcpus 12 \
–name <manager-name> \
–disk path=<manager-qcow2-file-path>,bus=virtio,cache=none \
–disk path=<secondary-qcow2-file-path>,bus=virtio,cache=none \
–network [bridge=<bridge-name> or network=<network-name>],
portgroup=<portgroup-name>,model=virtio \
–noautoconsole \
–cpu mode=host-passthrough
Starting install…
Domain installation still in progress. Waiting for installation to complete.
а для Ubuntu:
sudo virt-install \
–import \
–ram 48000 \
–vcpus 12 \
–name <manager-name> \
–disk path=<manager-qcow2-file-path>,bus=virtio,cache=none \
–disk path=<secondary-qcow2-file-path>,bus=virtio,cache=none \
–network [bridge=<bridge-name> or network=<network-name>],
portgroup=<portgroup-name>,model=virtio \
–noautoconsole \
–cpu mode=host-passthrough,cache.mode=passthrough
Starting install…
Domain installation still in progress. Waiting for installation to complete.
Убедиться, что NSX Manager успешно развернулся можно так:
virsh list –all
Id Name State
———————————
18 nsx-manager1 running
Теперь открываем консоль NSX Manager и вводим данные учетной записи администратора:
virsh console 18
Connected to domain nsx-manager1
Escape character is ^]
nsx-manager1 login: admin
Password: ******************
Чтобы убедиться в том, что все дефолтные службы запущены, используем команду «get services».
Важно! Такие сервисы, как «liagent» и «migration-coordinator snmp» автоматически не запускаются.
Теперь проверяем, что связь NSX Manager корректна путем пингования:
- ноды с другой машины,
- дефолтного шлюза нодой,
- хостов гипервизора из той же сети нодой через интерфейс управления,
- нодой – DNS-сервера, ее NTP Server IP или списка FQDN.
Также стоит проверить, доступно ли подключение по SSH.
После этого можно закрывать KVM-консоль командой «control-]» и заходить под правами администратора на https://<nsx-manager-ip-address> NSX Manager.
Формирование кластера NSX Manager на KVM
Предварительно разворачиваем три ноды по описанной выше схеме. Затем:
- Открываем SSH-сессию или консоль на первом развернутом NSX Manager и заходим под правами администратора;
- Запускаем на выполнение следующие команды по очереди:
-
- «get certificate api thumbprint» – выдаст строку с уникальным номером для этой ноды;
- «get cluster config» – получим ID кластера:
mgr-first> get cluster config
Cluster Id: 7b50abb9-0402-4ed5-afec-363587c3c705
Cluster Configuration Version: 0
Number of nodes in the cluster: 1
…
- Открываем SSH-сессию или консоль на новой ноде и заходим под правами администратора. Выполняем команду «join», чтобы присоединить ее к первому NSX Manager:
mgr-new> join <Manager-IP> cluster-id <cluster-id> username <Manager-username> password <Manager-password> thumbprint <Manager-thumbprint>
где указывается IP-адрес нашего менеджера, полученный выше ID кластера, имя пользователя и пароль, отпечаток сертификата.
Процесс присоединения занимает, обычно, 10-15 минут. По его окончанию запускаем «get cluster status» для верификации статуса нового кластера. Для дальнейшей работы он должен быть «UP».
- Аналогичным образом добавляем в кластер третью ноду.
Зайдя в веб-интерфейс NSX, проверяем статус кластера (вкладка «System» – «Appliances»).
Список и статус подключения менеджеров кластера можно получить командой: «get managers».
Теперь через UI NSX в «Fabric» – «Node» – «Hosts» проверяем состояние подключения наших МРА. Должно быть «UP». Или же GET-вызовом API:
GET https://<nsx-mgr>/api/v1/fabric/nodes/<fabric-node-id>/state
Результатом будет что-то вроде такого:
{
“details“: [],
“state“: “success“
}
По итогу проделанной работы, уровень управления начнет посылать сертификаты хоста на уровень управления, а уровень управления, в свою очередь – далее на хосты. Командой CLI «get controllers» можно просмотреть адреса NSX Controller по каждому хосту, или же просто в /etc/vmware/nsx/controller-info.xml:
[root@host:~] cat /etc/vmware/nsx/controller-info.xml
<?xml version=”1.0″ encoding=”utf-8″?>
<config>
<connectionList>
<connection id=”0″>
<server>10.143.1.47</server>
<port>1234</port>
<sslEnabled>true</sslEnabled>
<pemKey>—–BEGIN CERTIFICATE—–…—–END CERTIFICATE—–</pemKey>
</connection>
<connection id=”1″>
<server>10.143.1.45</server>
<port>1234</port>
<sslEnabled>true</sslEnabled>
<pemKey>—–BEGIN CERTIFICATE—–…—–END CERTIFICATE—–</pemKey>
</connection>
<connection id=”2″>
<server>10.143.1.46</server>
<port>1234</port>
<sslEnabled>true</sslEnabled>
<pemKey>—–BEGIN CERTIFICATE—–…—–END CERTIFICATE—–</pemKey>
</connection>
</connectionList>
</config>
До тех пор, пока хост не будет назначен как транспортная нода, его подключение к NSX-T Data Center инициировано, однако зависает в статусе «CLOSE_WAIT»:
user@host:~$ netstat -anp –tcp | grep 1234
tcp 0 0 192.168.210.54:57794 192.168.110.34:1234 CLOSE_WAIT –
Инсталляция NSX Edge и формирование NSX Edge-кластера
См. ниже «Разворот NSX Edge на bare-metal».
Создание транспортных зон на хостах KVM
Аналогично хостам ESXi – см. выше в «Создание транспортных зон на хостах vSphere» (через UI NSX Manager).
Разворот транспортных нод на хостах KVM
Перед разворотом транспортных нод на KVM следует убедиться, что нужные сторонние пакеты проинсталлированы (см. подраздел «Инсталляция сторонних пакетов на KVM-хост» в подготовке). Чтобы назначить ноду как транспортную, вначале ее следует добавить в «Fabric» NSX-T Data Center, аналогично тому, как мы это делали для ESXi-хостов.
Опционально перед началом процедуры можно узнать об отпечатке гипервизора (можно будет внести в соответствующее поле при организации TN). В Linux-shell это:
# echo -n | openssl s_client -connect <kvm -ip-address>:443 2>/dev/null | openssl x509 -noout -fingerprint -sha256
А также отпечаток SHA-256 для KVM-гипервизора:
# awk ‘{print $2}’ /etc/ssh/ssh_host_rsa_key.pub | base64 -d | sha256sum -b | sed ‘s/ .*$//’ | xxd -r -p | base64
Далее все аналогично ESXi-случаю, но отличие по KVM состоит в том, что можно как применять декларируемую NSX Manager конфигурацию N-VDS, так и переконфигурировать N-VDS по своему усмотрению: на пункте «тип N-VDS», доступен будет выбор из «NSX Created» и «Preconfigured», если до этого был специально настроен хотя бы один виртуальный распределенный коммутатор.
В случае пользовательских настроек свитча, в его конфигурации обязательно должны быть указаны следующие опции:
- N-VDS External ID (точно такой же, как имя N-VDS TZ, к которой принадлежит эта нода);
- VTEP (имя конечной точки виртуального туннеля).
Когда инсталляция TN завершится, просмотреть статус подключения можно командой «netstat -anp –tcp | grep 1234»:
user@host:~$ netstat -anp –tcp | grep 1234
tcp 0 0 192.168.210.54:57794 192.168.110.34:1234 ESTABLISHED –
Подключение транспортной ноды к уровню управления происходит так же, как это делалось в подразделе «Подключение Edge-ноды к уровню управления» в случае хоста ESXi.
Разворот NSX-T Data Center 3.1 на Bare Metal Server
Все требования и рекомендации раздела «Подготовка к инсталляции NSX-T Data Center 3.1» (см. выше) должны быть соблюдены. В случае разворота NSX-T Data Center 3.1 на Bare Metal Server мы должны будем осуществить следующее:
- Проинсталлировать NSX Manager на KVM;
- Установить стороннее ПО на физический сервер;
- Организовать NSX Edge;
- Развернуть транспортные ноды;
- Создать интерфейс приложения для рабочих процессов Bare Metal Server.
Пройдемся по этим пунктам.
Инсталляция NSX Manager
См. «Разворот NSX Manager на KVM» выше.
Разворот NSX Edge на bare-metal
В случае Bare Metal Server можно использовать PXE-сервер для автоматизации установки или же загрузить со страницы загрузок VMware ISO-файл для ВМ Аppliance Edge на bare-metal:
Важно! PXE boot-инсталляция не поддерживается NSX Manager. Кроме того, нельзя редактировать такие настройки, как IP-адрес, шлюз, маску сети, NTP и DNS. Все теоретические знания о bare-metal-разворотах, их применении и особенностях можно почерпнуть в статье «Дизайн VMware NSX-T Data Center 3.1».
Подготовка PXE-сервера для NSX Edge
Нижеследующие советы касаются, в качестве примера, Ubuntu. Сам PXE состоит из DHCP, HTTP и TFTP. DHCP динамически распределяет IP-настройки по компонентам NSX-T Data Center, в том числе и на Edge. В PXE-среде DHCP-сервер позволяет NSX Edge запрашивать и получать IP-адреса автоматически. Протокол пересылки файлов TFTP чутко прислушивается к клиентам PXE в сети, и как только обнаруживает какой-либо их запрос на PXE-сервисы, предоставляет ISO-файл – компонент NSX-T Data Center, – в котором и содержатся необходимые настройки.
Обязательно стоит проверить, чтобы в предварительно заданном файле конфигурации были параметры:
net.ifnames=0
biosdevname=0
и должны они располагаться после «–» для сохранения и после перезагрузки.
Если нужны новые TFTP или DHCP-сервисы на сервере Ubuntu, используем kickstart-файл (текстовый файл с CLI-командами, запускающими приложение после первой загрузки), например, «nsxcli.install» для их установки. Этот файл нужно скопировать на веб-сервер (допустим, на «/var/www/html/nsx-edge/nsxcli.install»), после чего добавить в него все необходимые CLI-команды. К примеру, если нужно настроить IP-адрес для интерфейса управления, вписываем такое:
stop dataplane
set interface eth0 <ip-cidr-format> plane mgmt
start dataplane
А чтобы поменять пароль администратора:
set user admin password <new_password> old-password <old-password>
Важно! Заданный в файле preseed.cfg пароль должен совпадать с тем, который вносится в kickstart-файл.
Также именно в этом файле NSX Edge будем присоединять к уровню управления строкой:
join management-plane <manager-ip> thumbprint <manager-thumbprint> username <manager-username> password <manager password>
После всего сделанного, переходим к созданию двух интерфейсов (упоминалось в «Подготовке…») для DHCP и TFTP служб:
- Убеждаемся, что оба они находятся в той же самой подсети, что и NSX Edge. Сделать это можно, например, вот так:
# The loopback network interface
auto lo
iface lo inet loopback
# PXE server’s management interface
auto eth0
iface eth0 inet static
address 192.168.110.81
gateway 192.168.110.1
netmask 255.255.255.0
dns-nameservers 192.168.110.10
# PXE server’s DHCP/TFTP interface
auto eth1
iface eth1 inet static
address 192.168.210.82
gateway 192.168.210.1
netmask 255.255.255.0
dns-nameservers 192.168.110.10
- Устанавливаем софт DHCP-сервера:
sudo apt-get install isc-dhcp-server –y
- Открываем на редактирование файл «/etc/default/isc-dhcp-server», чтобы добавить туда только что созданный интерфейс:
INTERFACES=”eth1″
Важно! Если этот DHCP-сервер должен стать официальным сервером DHCP для локальной сети, раскомментируйте строку «authoritative;» в файле «/etc/dhcp/dhcpd.conf».
- В файле «/etc/dhcp/dhcpd.conf» определяем настройки DCHP для PXE-сети:
subnet 192.168.210.0 netmask 255.255.255.0 {
range 192.168.210.90 192.168.210.95;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.110.10;
option routers 192.168.210.1;
option broadcast-address 192.168.210.255;
default-lease-time 600;
max-lease-time 7200;
}
- Запускаем DHCP-службу:
sudo service isc-dhcp-server start
Убедиться, что она запущена можно, введя в командную строку:
service –status-all | grep dhcp
- Устанавливаем Apache, TFTP и другие компоненты, которые нужны для загрузки PXE:
sudo apt-get install apache2 tftpd-hpa inetutils-inetd
Убедиться, что они запущены можно так:
service –status-all | grep tftpd-hpa
service –status-all | grep apache2
- Добавляем в файл «/etc/default/tftpd-hpa» следующие строки:
RUN_DAEMON=”yes”
OPTIONS=”-l -s /var/lib/tftpboot”
- В файл «/etc/inetd.conf» вписываем такую строку:
tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
- Перезапускаем TFTP-сервис:
sudo /etc/init.d/tftpd-hpa restart
- Копируем или загружаем инсталлятор NSX Edge во временную папку. Теперь нужно подмонтировать этот ISO и скопировать компоненты инсталляции на TFTP и Apache сервера:
sudo mount -o loop ~/nsx-edge.<build>.iso /mnt
cd /mnt
sudo cp -fr install/netboot/* /var/lib/tftpboot/
sudo mkdir /var/www/html/nsx-edge
sudo cp -fr /mnt/* /var/www/html/nsx-edge/
- Добавляем следующие строки в файл «/var/lib/tftpboot/pxelinux.cfg/defaul». Вместо 192.168.210.82 проставляем IP-адрес TFTP-сервера:
label nsxedge
kernel ubuntu-installer/amd64/linux
ipappend 2
append netcfg/dhcp_timeout=60 auto=true priority=critical vga=normal partman-lvm/device_remove_lvm=true netcfg/choose_interface=auto debian-installer/allow_unauthenticated=true preseed/url=http://192.168.210.82/nsx-edge/preseed.cfg mirror/country=manual mirror/http/hostname=192.168.210.82 nsx-kickstart/url=http://192.168.210.82/nsx-edge/nsxcli.install mirror/http/directory=/nsx-edge initrd=ubuntu-installer/amd64/initrd.gz mirror/suite=xenial –
- В файле «/etc/dhcp/dhcpd.conf» делаем то же самое, но уже для DHCP-сервера:
allow booting;
allow bootp;
next-server 192.168.210.82; #Replace this IP address
filename “pxelinux.0”;
- Перезапускаем службу DHCP.
Автоматическая инсталляция NSX Edge через ISO-файл
- Заходим в управляющий «out-of-band»-интерфейс (например, в ILO на НР-серверах) bare metal и кликаем на «Launch» в превью виртуальной консоли;
- Выбираем в «Virtual Media» – «Connect Virtual Media» и ждем несколько секунд подключения;
- Выбираем в «Virtual Media» – «Map CD/DVD» и находим наш ISO-файл;
- Выбираем в «Next Boot» – «Virtual CD/DVD/ISO»;
- Выбираем «Power» – «Reset System (warm boot)». Какое-то время будет идти инсталляция;
- Ищем «Automated installation» и жмем «Enter»;
- Выбираем нужный основной интерфейс сети, затем запросят пароль (по умолчанию пароль для рута будет «vmware», а для администратора – «default»);
- Открываем консоль ноды NSX Edge, чтобы следить за процессом загрузки.
- Когда NSX Edge-нода запустится, заходим под учетной записью администратора в CLI;
После перезагрузки можно будет использовать как логин администратора, так и запись рута. И теперь можно приступать к настройке интерфейса управления. Он может быть:
- Не тегированным. Это out-of-band-интерфейс, и для его установки на DHCP запускаем команду:
set interface eth0 dhcp plane mgmt
а для статического:
set interface eth0 ip <CIDR> gateway <gateway-ip> plane mgmt
- Тегированным. Устанавливается командой:
set interface eth0 vlan <vlan_ID> plane mgmt
для DHCP:
set interface eth0.<vlan_ID> dhcp plane mgmt
для статического:
set interface eth0.<vlan_ID> ip <CIDR> gateway <gateway-ip> plane mgmt
- «In-band»-интерфейсом:
set interface mac <mac_address> vlan <vlan_ID> in-band plane mgmt
для DHCP:
set interface eth0.<vlan_ID> dhcp plane mgmt
статического:
set interface eth0.<vlan_ID> ip <CIDR> gateway <gateway-ip> plane mgmt
Запускаем, если VLAN нету, «get interface eth0», а если есть – «get interface eth0.<vlan_ID>», чтобы убедиться, что IP-адрес получен правильно:
nsx-edge-1> get interface eth0.100
Interface: eth0.100
Address: 192.168.110.37/24
MAC address: 00:50:56:86:62:4d
MTU: 1500
Default gateway: 192.168.110.1
Broadcast address: 192.168.110.255
…
Важно! Если имеем дело с тегированным и «In-band»-интерфейсом, любой существующий для управления VLAN интерфейс должен быть очищен, перед тем как создается новый:
clear interface eth0.<vlan_ID>
Устанавливаем pNIC, которые будут использоваться уровнем данных NSX-T Data Center из списка доступных PCI-девайсов:
get dataplace device list
set dataplane device list <NIC1>, <NIC2>, <NIC3>
restart service dataplane
get physical-port
После выбора перезапускаем службы уровня данных, чтобы применить изменения.
Перед тем, как создать NSX Edge как транспортную ноду, перезагружаем список карт уровня данных:
reset dataplane nic list
Убеждаемся, что NSX Edge получил свое подключение (через SSH, как было описано выше).
Установка NSX Edge через ISO-файл в интерактивном режиме
Проходим п. 1 – 5 автоматического метода. Далее вместо «Automated installation» находим «Interactive Install». Затем:
- В окне «Configure the keyboard» выбираем «Yes», если нуждаемся в авто-обнаружении клавиатуры, и выбираем в качестве языка «English US»;
- В окне «Configure the network» выбираем соответствующий основной сетевой интерфейс;
- Вводим имя хоста, который должен к нему подключаться и затем жмем «ОК». Пароли по умолчанию аналогичны автоматической установке;
- В «Configure NSX appliance» используем окно kickstart, либо введя URL конфигурационного файла kickstart, чтобы автоматизировать настройку NSX на Bare Metal Server, или же оставляем поле пустым, и тогда это делать придется вручную;
- В окне «Partition disks» выбираем одну из двух опций:
- «Yes» – если хотим размонтировать существующие партиции, чтобы создать на дисках новые;
- «No» – если хотим использовать существующие партиции.
- После этого запустится NSX Edge-нода, и нужно будет зайти в CLI под правами администратора;
- Запускаем, если VLAN нету, «get interface eth0», а если есть – «get interface eth<vlan_ID>», чтобы убедиться, что IP-адрес получен как должно:
nsx-edge-1> get interface eth0.100
Interface: eth0.100
Address: 192.168.110.37/24
MAC address: 00:50:56:86:62:4d
MTU: 1500
Default gateway: 192.168.110.1
Broadcast address: 192.168.110.255
…
После того, как наша NSX Edge-нода успешно развернулась на Bare Metal Server, ее следует по аналогии со всеми вышеописанными случаями присоединить к уровню управления виртуальными сетями.
Создание транспортных нод на bare-metal
Процесс инициации транспортных нод на базе Bare Metal Server полностью аналогичен тому, что мы предпринимали в отношении KVM, за исключением обязательности шага добавления в «Fabric» NSX-T Data Center этой ноды, если она рассматривается как часть оверлея. Следует заметить, что предварительно обязательно установить под каждую ОС свой пакет стороннего ПО (см. выше в разделе «Подготовка…» для bare-metal). Точно так же делаем все через UI NSX Manager, поэтому повторяться, думается, не стоит.
Начиная с версии NSX-T Data Center 3.0, Windows bare-metal поддерживается как транспортная нода.
Создание интерфейса приложения для рабочих процессов физических серверов
Важно учесть, что NSX-T Data Center не поддерживает бондинг интерфейсов ОС Linux. Для физических серверов транспортных нод следует использовать Open vSwitch (OVS) и только Active/Standby-режим. Осуществлять управление рабочими процессами физических серверов, зарегистрированных в качестве транспортных нод NSX, помогают специально созданные с помощью т.н. «Ansible playbook» интерфейсы приложений.
Режимы поддержки Ansible представляют собой набор автоматизированных скриптов, которые устанавливают интерфейс приложения на физические сервера. Из всего три:
- Static – при нем IP-адрес интерфейса приложения конфигурируется вручную,
- DHCP – IP-адрес интерфейса приложения настраивается динамически,
- Migrate – поддержка управления и расшаривания одинаковых IP-адресов приложений (еще часто называют underlay-режим или VLAN-0).
Если мы имеем дело с физическими серверами на Linux, установить Ansible в разрезе каждой операционной системы поможет специальная документация. Поддерживаемая в нашем случае версия Ansible – 2.4.3 или свежее. Верификация соответствия этому пункту предпринимается путем запуска команды: «ansible-version». Также потребуется загрузить и извлечь серверную интеграцию отсюда.
Под физические сервера Windows придется вначале проинсталлировать «pip» для «pywinrm», а затем и сам «pywinrm», после чего запустить:
pip install pywinrm
Разворот федерации в NSX-T Data Center 3.1
Функционал федерации, как мы уже писали в статье «Дизайн NSX-T Data Center 3.1» – заслуженная гордость вендора, начиная с версии 3.0. Все теоретические знания о схеме построения и работе этой возможности можно почерпнуть из указанной статьи.
По традиции, перед созданием федерации сформулируем наше глобальное ТЗ:
- Проинсталлировать GM Аppliance;
- Назначить один GM активным (Active) и добавить резервный GM Standby;
- Добавить локацию.
Установка NSX Global Manager Аppliance
Чтобы начать работать с федерацией, в первую очередь устанавливаем Global Manager на ESXi по описанной выше схеме – как NSX Manager Аppliance, только при развороте выбираем роль ноды («Rolename» в UI ESXi и «nsx_role» для KVM) не «NSX Manager», а «NSX Global Manager»:
Важно заметить, что для гипервизоров vSphere размер конфигурации разворота выбирается только как «Medium» или «Large». Под KVM мы можем иметь дело только со среднего размера Аppliance, для этого задаем, к примеру:
virt-install –import –ram 16000–vcpus 6
После того, как vApp GM успешно установилось, следует зайти в него, и, если работаем в среде vSphere, можем добавить соответствующий менеджер вычислений (см. выше в теме про разворот NSX Manager на vSphere).
Active и Stanby GM
Для следования нормам НА и безопасного аварийного восстановления обязательно следует сформировать кластер и проинсталлировать standby-GM.
Важно! Резервный и активный GM должны быть установлены в различных локациях.
Если в наличии vSphere с настроенным менеджером вычислений, из UI NSX Manager создаем новый Manager Аppliance и прикрепляем его к Active с целью формирования кластера. Если менеджер вычислений не предусмотрен, повторяем разворот, нативный для этой среды с использованием CLI (процедура описана в разделе про KVM), еще дважды, и из полученных трех vApp формируем кластер. В случае же KVM тоже повторяем операцию еще дважды, чтобы в итоге получить три Аppliance и инициируем создание кластера. Все варианты были рассмотрены выше в соответствующих темах.
Затем настраиваем VIP для этого кластера – подробно обсудим этот момент в статье «Администрирование и настройка NSX-T Data Center 3.1».
Теперь нужно назначить «Active»-роль для этого кластера. Заходим в GM Аppliance на «https://global-manager-ip-or-fqdn/» и на вкладке «System» ищем «Location Manager». Под заголовком «Global Manager» кликаем на кнопку «Make Active»:
Вылетит окошко, в котором нужно будет задать имя для нашего кластера, после чего сохранить настройку кнопкой «Save»:
Чтобы создать резервный кластер, нажимаем на «Add Standby»:
После чего в появившемся окне нужно будет назначить:
- имя,
- FQDN/IP
- учетные данные администратора
- отпечаток SHA-256
Обязательно нажать на кнопку «Check Compatibility», чтобы убедиться, что с добавлением резервного GM не возникнет сложностей. Соглашаемся с разворотом кнопкой «Save»:
Пара Active/Standby GM-кластеров теперь в меню «Location Manager» будет показана вот так:
Добавление локации и создание Local Manager (LM)
Добавление локации в GM – очень важный шаг, ведь только после этого можно будет создавать объекты из GM, которые разделят эту локацию. Как только локация добавлена в GM, NSX Manager станет называться LM. Для этого делаем следующее:
- Заходим в GM на «https://global-manager-ip-or-fqdn/» и выбираем на вкладке «System»- «Location Manager», после чего кликаем на «Add On-Prem Location»:
- Вводим данные новой локации в открывшееся диалоговое окно «Add New Location»:
-
- имя локации,
- FQDN/IP (только VIP),
- имя пользователя и пароль,
- отпечаток SHA-256.
Снова обязательно проверяем совместимость («Check Compatibility»):
О том, как создавать шлюзы и сегменты в федерации, которые будут накрывать 1+ LM, о настройке RTEP на Edge-нодах в каждой локации для поддержки кросс-локационного трафика, а также многих других интересных вещах в растянутых сетях и не только, мы обязательно расскажем в нашей следующей статье по тематике виртуальных сетей «Администрирование и настройка NSX-T Data Center 3.1». Кроме того, там будет много полезной информации о настройке VIP, назначении политик и безопасности, также мы научимся создавать и конфигурировать N-VDS, сегменты, профили аплинков, NIOC, настраивать маршрутизацию и шлюзы, инициировать необходимые службы, эффективно использовать мониторинг и многому-многому другому.
Если же хочется узнать о сложных случаях разворотов NSX-T Data Center 3.1 и получить более глубокое видение стоящих перед виртуализаторами сетей задач, обязательно постарайтесь попасть на авторизованные курсы VMware по этой тематике.