Привет, Хабр!
Это — третья часть «Внедрения VMware Horizon глазами инженера». В этот раз разберёмся с сетевой связностью, из чего вообще состоит Horizon и как именовать весь этот «зоопарк».
Сетевое оборудование
В прошлой статье я обещал слегка окунуться в мир сетевого оборудования.
Закрыть тему vSAN, не разобравшись со схемой сети, невозможно. Предполагается, что читатель уже знаком с базовыми принципами сетевой модели ESXi/vSphere — иначе только этой теме пришлось бы посвящать отдельный цикл статей.
Существует множество подходов к построению сети для кластеров VDI. Мы рассмотрим один из практических вариантов — тот, который используем сами в ПИК — и на его основе набросаем типовую схему подключения ESXi к коммутаторам. Нам потребуется как минимум три отдельных сети. Две из них (для ВМ и vSAN) должны быть высокоскоростными — 10, а лучше 25 гигабит.
Сеть IPMI
Для управления серверами на уровне железа используется отдельная сеть управления, куда подключаются интерфейсы IPMI/iDRAC/iLO. Как правило, она уже существует в инфраструктуре и подключается обычной витой парой.
На логическом уровне эта сеть никак не участвует в работе ESXi, поскольку находится за пределами операционной системы. Поэтому подробно останавливаться на ней нет смысла.
Сеть ВМ и хостов (Mgmt + VM Network)
С помощью этой сети осуществляется управление серверами (например, коммуникация с vCenter), и здесь проходит трафик виртуальных машин. Через неё осуществляется выход в интернет. На физическом уровне это два аплинка из разных сетевых адаптеров в два независимых коммутатора, подключённых к сети предприятия.
Логический уровень этой сети подразумевает наличие как минимум двух виртуальных портгрупп: одна — для самих серверов, вторая — для виртуальных машин. Хорошей практикой принято считать разделение этих сетей по VLAN. Даже если VLAN по каким-то причинам не используются, экономить на портгруппах не стоит: логическое разделение упрощает эксплуатацию и диагностику.
Сеть vSAN
Эта сеть выполняет одну задачу — обеспечить максимально быструю и стабильную коммуникацию между узлами кластера.
На физическом уровне — то же самое, что и сеть ВМ/хостов. С той разницей, что здесь связь с сетью предприятия не обязательна. В целях экономии допустимо использовать отдельные порты на тех же коммутаторах, что и для сети ВМ/хостов. Главное здесь — обеспечить единый высокоскоростной домен коммутации для всей сети vSAN, чтобы исключить узкие места на пути трафика. На практике это в большинстве случаев означает подключение всех серверов к одному стеку или паре коммутаторов. Разнести узлы по разным стекам возможно, но межстековый линк становится потенциальной точкой отказа и легко превращается в «бутылочное горлышко».
На логическом уровне для сети vSAN потребуется по отдельному VMK-адаптеру на хост. Также для них крайне рекомендуется отдельный VLAN.
vMotion / Provisioning
Ещё один VMK-адаптер потребуется для трафика vMotion/Provisioning. Разместить его можно как в сети vSAN, так и в сети ВМ/хостов в зависимости от ваших предпочтений.
Схема сети
Такая схема подключения обеспечивает отказоустойчивость: сбой любого сетевого адаптера или коммутатора не приводит к потере связности. Трафик vSAN/vMotion/Provisioning и VM/Mgmt разделяется на физическом уровне.
LACP или не LACP
Для обеспечения отказоустойчивости просто включить провода в коммутаторы согласно схеме недостаточно. Коммутаторы и серверы должны так или иначе договориться о том, какие интерфейсы образуют единый логический канал и как именно по ним распределяется трафик.
Наиболее распространённый способ — протокол LACP. Он позволяет динамически формировать агрегированный канал и быстро исключать отказавшие линки.
Однако LACP несовместим с vSAN over RDMA: RDMA-трафик требует прямого соответствия между сетевым интерфейсом и физическим линком, тогда как агрегация скрывает эту связь за логическим интерфейсом. Для RDMA это — непреодолимое препятствие.
Альтернативный вариант — отказ от агрегации на стороне коммутатора и балансировка средствами гипервизора. В такой конфигурации использование RDMA возможно, правда, только с двумя стратегиями балансировки: Route based on originating virtual port и Route based on source MAC hash. Отработка отказа в таком случае осуществляется медленнее, чем с LACP.
И это не единственная сложность, связанная с RDMA. Для работы этой технологии требуются коммутаторы с её поддержкой, а также опытный специалист, способный корректно настроить lossless-сеть и QoS-механизмы. Без этого RDMA превращается в источник трудно уловимых проблем.
В итоге придётся определиться, хотите вы использовать RDMA, позволяющий сократить задержки на уровне сети и повысить скорость работы vSAN, или же воспользоваться надёжным и проверенным механизмом LACP. В наших кластерах мы сознательно отказались от RDMA в пользу более простой и устойчивой конфигурации.
Альтернативы
Описанная схема — лишь один из рабочих вариантов. Возможны вариации, где все четыре порта сетевых плат объединены в один большой канал. Или же где портов только два, а для vSAN используются два VMK-адаптера на отдельных, неагрегированных аплинках, полный air-gap и тому подобное. Все они жизнеспособны, но в рамки этой статьи просто не поместятся.
Нейминг и его важность
С физической инфраструктурой мы разобрались, поэтому перейдём к следующему шагу. На этом этапе стоит определиться с паттернами нейминга, по крайней мере, для тех компонентов, которые нам уже известны. Почему это важно? Потому что правильный нейминг — залог порядка в любой системе.
Об этом необходимо подумать заранее, поскольку, например, Horizon при создании пулов ориентируется в структуре vSphere исключительно по именам объектов. Это значит, что переименовать дата-центр или кластер на «живом» развёртывании стандартными средствами, без удаления пулов, будет невозможно. Так, мы живём восемь лет с дата-центром, имя которого не соответствует правилам, принятым уже после его создания. Решили, что лучше так, чем устраивать масштабные технические работы ради его переименования.
Я могу выделить три подхода к неймингу, с которыми сталкивался на практике.
Подход стихийный
Используется неопытными администраторами повсеместно. Суть подхода — в его отсутствии. Объекты получают имя в момент создания: то, которое первым пришло в голову. Компоненты инфраструктуры начинают называться буквами греческого алфавита, именами античных богов, кличками домашних животных и чем угодно ещё.
Подход безопасный
Распространён в компаниях, где ИБ направляет админов в «правильную» сторону, и там, где ИТ живёт в атмосфере регламентов и таблиц. Порядка здесь больше: есть реестр сущностей, всё сопоставлено с функциями. Но сами имена при этом неотличимы друг от друга. В лучшем случае нейминг может намекать на роль: db82, app212, dtc4. В худшем это будут цифровые индексы или бессмысленные комбинации символов. Такой подход немного усложняет жизнь потенциальному злоумышленнику, сканирующему сеть. Однако он одновременно усложняет жизнь администраторам.
Подход осмысленный
Этого подхода придерживаюсь я сам. Для каждого типа объектов на всех уровнях: кластер, хост, виртуальная машина, распределённый ресурс — заранее задаются шаблоны нейминга. При этом имена выбираются в рамках шаблона так, чтобы по ним с первого взгляда была понятна функция объекта. Шаблоны, в свою очередь, составляются таким образом, чтобы имена объектов всегда отражали наиболее важную информацию о его свойствах.
Такой подход позволяет админам быстро ориентироваться в инфраструктуре без постоянного обращения к документации. Разумеется, реестр всё равно нужен. Но он становится инструментом контроля, а не единственным способом понять, что перед тобой находится.
Пример правил нейминга
Примеры ниже основаны на субъективном опыте автора, носят рекомендательный характер и не являются исчерпывающими.
Дата-центр: dtc-sl.
dtc — дата-центр, sl — имя дата-центра.Кластер: cls-sl-vdi01.
cls — кластер, sl — имя дата-центра, vdi — имя системы/имя кластера.Хост виртуализации: sv-vdi-esxi018.
sv — физический сервер, vdi — имя системы, esxi — функция, 018 — сквозная нумерация по всем хостам vdi.Серверная ВМ: vm-vdi-view01.
vm — виртуальная машина, vdi — имя системы, view — функция.Балансировщик нагрузки: vm-vdi-view-lb01.
vm — виртуальная машина, vdi — имя системы, view-lb — функция.Пул VDI: pool-sl-vdi01-8-dev.
pool — пул, sl-vdi01 — имя дата-центра и кластера, 8 — номер пула, dev — функция.ВМ VDI: vd-sl-vdi01-80001. vd — ВМ VDI, sl-vdi01 — имя кластера, 8 — номер пула, 0001 — номер ВМ.
dSwitch: ds-sl01-LAN.
ds — dswitch, sl01 — имя дата-центра, LAN — функция.Портгруппа на dSwitch:
VL1017-Desktops — номер VLAN + функция.
Вопросы и ответы о правилах нейминга
— У меня в инфраструктуре уже есть правила нейминга, и я не собираюсь их менять. Нужно ли что-то делать?
— Нет. Главное — корректно адаптировать существующие правила под новые компоненты. Примеры выше — справочная информация.
— Зачем в имени ВМ VDI указывать кластер?
— Для корректной работы App Volumes в имени ВМ требуется уникальный идентификатор, указывающий на кластер. Имя кластера — лучший кандидат на эту роль.
— Зачем везде номера, если у меня один кластер или один пул?
— Потому что невозможно предугадать, в какой момент появится второй.
— Почему в таком случае в имени дата-центра нет номера?
— Если в инфраструктуре много дата-центров, можно добавить номер. Порядковый номер можно добавить в любую часть имени, но важно, чтобы в этом была необходимость, иначе имена получатся плохо читаемыми.
— Почему в имени хоста не упоминается кластер? Почему у хостов сквозная нумерация?
— Потому что хосты могут перемещаться между кластерами. Коллизии имён хостов между разными кластерами разрешаются сквозной нумерацией.
— Почему в таком случае упоминаются система и функция? Ведь они тоже могут меняться.
— Потому что при смене функции сервера его зачастую переустанавливают, и несложно сменить имя в этот момент.
— Почему шаблон имени пула или портгруппы не похож на остальные шаблоны?
— Шаблоны для разных типов объектов могут различаться, и составлять их нужно исходя из их функций.
Компоненты Horizon
Теперь, когда мы обсудили нейминг и необходимость его строго соблюдать, попробуем собрать воедино схему развёртывания — опишем полный список компонентов, которые нам понадобятся.
В нашем примере, чтобы избежать путаницы, разместим все компоненты VDI в одном кластере, на единственном датасторе vSAN. Это допустимо, но на практике лучше всего размещать серверные ВМ, в особенности vCenter, в других кластерах или в частном облаке, чтобы не потерять управление системой в случае неполадок на vSAN.
Здесь и далее будем рассчитывать на пул из 1000 ВРМ (виртуальных рабочих мест), для других объёмов ресурсы серверных ВМ и их количество могут быть другими.
vSphere
Дата-центр — как минимум один. Здесь мы будем размещать наши кластеры (в этом примере один кластер) и сетевую логику.
Кластер — для размещения ВРМ.
Датастор vSAN в кластере. Все данные ВРМ и серверных ВМ будут храниться на нём.
Политика хранения данных vSAN.
Ресурс-пул — как минимум два. Мы будем использовать ресурс-пулы не по их прямому назначению, а для поддержания порядка в админпанели vSphere.
Фолдеры для ВМ — раздельные для инфраструктурных и пользовательских машин.
dSwitch — как минимум два. dSwitch LAN — для трафика хостов, серверных ВМ и ВРМ; dSwitch SAN — для трафика vSAN, vMotion, Provisioning.
Хосты — по ранее составленному плану.
Horizon
View Connection Server — как минимум два. Это основной компонент Horizon. Отсюда производится управление всеми ВРМ, их развёртывание и удаление. Тут же находится админпанель системы.
БД PostgreSQL — для хранения событий View (допускается MS SQL). Позволяет отслеживать работу системы из админпанели.
Балансировщик нагрузки View — как минимум два. Обеспечивает отказоустойчивость View Connection Server.
Syslog-сервер — для форварда логов View (опционально).
Unified Access Gateway — как минимум три. UAG является, по сути, реверс-прокси, специально адаптированным под работу с протоколами Horizon. Он обеспечивает возможность подключения пользователей к ВРМ через интернет.
Балансировщик нагрузки UAG — как минимум два. Обеспечивает отказоустойчивость UAG.
AppVolumes
AppVolumes Manager — как минимум два, для обеспечения отказоустойчивости. Менеджеры управляют системой доставки приложений и пользовательских данных. Там же находится админпанель AppVolumes.
БД MS SQL — для хранения данных менеджеров. Желательно, чтобы БД размещалась в отказоустойчивом кластере, но в нашем примере это будет просто отдельная ВМ.
Балансировщик нагрузки — как минимум два. Обеспечивает отказоустойчивость менеджеров.
Внешние сервисы
Домен Active Directory — для аутентификации пользователей и регистрации ВРМ.
Центр сертификации — потребуются сертификаты для компонентов VDI.
Сетевые сервисы — DNS, DHCP, NTP, KMS.
Пример таблицы серверных ВМ:
Компонент | Имя ВМ | Доп. имя | Ресурсы (500-1000) | ОС | Интернет IP | VRRP IP |
vCenter | vm-vdi-vc01 | vdi-vc.domain.loc | Medium | Appliance | ||
Horizon View 1 | vm-vdi-view01 | 6 ЦП / 16 ОЗУ | Windows | |||
Horizon View 2 | vm-vdi-view02 | 6 ЦП / 16 ОЗУ | Windows | |||
Horizon View Event DB | vm-vdi-view-edb01 | 2 ЦП / 4 ОЗУ | Linux | |||
Horizon View LB 1 | vm-vdi-view-lb01 | view.domain.loc | 2 ЦП / 4 ОЗУ | Linux | 10.10.10.10 | |
Horizon View LB 2 | vm-vdi-view-lb02 | 2 ЦП / 4 ОЗУ | Linux | |||
AppVolumes Manager 1 | vm-vdi-av01 | 4 ЦП / 8 ОЗУ | Windows | |||
AppVolumes Manager 2 | vm-vdi-av02 | 4 ЦП / 8 ОЗУ | Windows | |||
AppVolumes DB | vm-vdi-av-db01 | 6 ЦП / 16 ОЗУ | Windows | |||
AppVolumes LB 1 | vm-vdi-av-lb01 | av.domain.loc | 2 ЦП / 4 ОЗУ | Linux | 10.10.10.11 | |
AppVolumes LB 2 | vm-vdi-av-lb02 | 2 ЦП / 4 ОЗУ | Linux | |||
UAG 1 | vm-vdi-uag01 | uag01.domain.ru | 8 ЦП / 10 ОЗУ | Appliance | 123.123.12.34 | |
UAG 2 | vm-vdi-uag02 | uag02.domain.ru | 8 ЦП / 10 ОЗУ | Appliance | 123.123.12.35 | |
UAG 3 | vm-vdi-uag03 | uag03.domain.ru | 8 ЦП / 10 ОЗУ | Appliance | 123.123.12.36 | |
UAG LB 1 | vm-vdi-uag-lb01 | 2 ЦП / 4 ОЗУ | Linux | 123.123.12.30 | 10.10.10.12 | |
UAG LB 2 | vm-vdi-uag-lb02 | 2 ЦП / 4 ОЗУ | Linux |
Учётные записи
Подготовим заодно и список учёток, которые понадобятся для работы системы. Учётные записи рутов и прочих локальных пользователей перечислять в примере не буду, но для реального внедрения неплохо было бы заранее описать и их.
Тип | Ресурс | Имя | Домен | Назначение |
AD | AD | vdi-horizon | domain.loc | Взаимодействие Horizon с AD |
AD | AD | vdi-appvol | domain.loc | Взаимодействие AppVolumes с AD (только чтение) |
AD | AD | vdi-vsphere | domain.loc | Взаимодействие vSphere с AD (только чтение) |
vSphere | vdi-vc.domain.loc | administrator | vsphere.local | Локальный администратор vsphere |
vSphere | vdi-vc.domain.loc | horizon | vsphere.local | Учётная запись Horizon для управления ВМ |
vSphere | vdi-vc.domain.loc | appvol | vsphere.local | Учётная запись AppVolumes для монтирования дисков |
vSphere | vdi-vc.domain.loc | readonly | vsphere.local | Учётная запись мониторинга (только чтение) |
App | vm-vdi-view-edb01 | horizon | Пользователь для аутентификации Horizon в Postgresql | |
App | vm-vdi-uag01 | admin | Вход в админ-панель UAG |
Заключение
Всё вышеперечисленное: нейминг, список компонентов и учётных записей — лучше подготовить до начала внедрения, чтобы не споткнуться в процессе. Чтобы не оказалось через неделю после начала работ, что дата-центр нужно срочно переименовать, а количества выделенных IP-адресов недостаточно для размещения всех ресурсов.
Третья часть на этом подходит к концу, а в четвёртой мы поговорим о сетевой связности компонентов, файрволах, балансировщиках нагрузки и общей сетевой схеме системы. А также, наконец, перейдём от теории к практике и начнём развёртывание.
