Часть 1
Привет, Хабр!
Меня зовут Дмитрий Гайдамак. В ПИК я отвечаю за серверную инфраструктуру для проектировщиков и их техническую поддержку. В этом цикле статей я расскажу, как мы внедряли и развивали Omnissa (ранее — VMware) Horizon — с точки зрения инженера, а не менеджера.
Цикл будет полезен ИТ-специалистам — как тем, кто ещё сомневается, с чего вообще начать внедрение, так и тем, кто уже рисует первые наброски архитектуры под себя.
Постепенно мы разберём:
соображения на тему подбора железа для VDI;
базовые понятия vSAN и его сайзинг под свои нужды;
компоненты всей будущей системы VDI;
балансировку нагрузки и организацию отказоустойчивости решений Omnissa;
администрирование системы: золотой образ, клоны, пулы;
доставку приложений AppVolumes;
возможности кастомизации рабочих мест VDI;
мониторинг Horizon;
соображения на тему безопасности stateless рабочих мест;
брендирование и настройку веб-портала Horizon.
Всё это я постараюсь дополнить реальными случаями из опыта эксплуатации VDI у нас в ПИК. Но всему своё время. Начнём с краткой предыстории.
Борьба с распределённой инфраструктурой и кадровый голод
Когда мы впервые заговорили о VDI в 2018 году, никто не думал о глобальной удалёнке. Изначально этот инструмент выбрали в качестве решения для вполне конкретного круга задач, в частности — оптимизации работы нескольких офисов в регионах, далёких от Москвы. На тот момент никто и не подозревал, что через пару лет коронавирус форсирует внедрение удалёнки по всей стране.
Проблема была проста, но болезненна: проектировщиков в Москве катастрофически не хватало. Чтобы закрыть потребность, компания открыла офисы в регионах. Например, в Краснодаре и Новороссийске, которые позже и стали первыми офисами с VDI. Но на тот момент логичным казалось размещение инфраструктуры «по классике» — прямо в офисах. Кадры есть, интернет есть, серверы поставили — и поехали.
В то же время ПИК активно внедрял BIM-технологии, и для эффективной работы в Revit требовалось стабильное и быстрое подключение к revit-серверам, которых в компании становилось всё больше. Это повлекло за собой сначала модернизацию офисных сетей с устаревших 100 Мбит на более уважаемый 1 Гбит (и 10 Гбит в серверной и на межэтажных магистралях), а после –– и разговоры о том, как оптимизировать работу с удалёнными офисами.
Но классическая схема с серверами в каждом офисе к тому времени уже начала давать сбои. Каждый офис жил своей жизнью: проект, начатый в Новороссийске, оставался там, потому что передать его в Москву или просто открыть напрямую с московского компьютера означало выпасть из рабочего процесса на весь день. Частично этот вопрос решали ревит-акселераторы, которые кэшировали данные локально, но и их возможности вскоре исчерпались. Количество проектов росло, сами модели увеличивались в размерах, и держать их на акселераторах становилось сначала накладно, а затем и вовсе невозможно из-за архитектурных ограничений Revit Server, масштабируемость которого падает с ростом объёма данных.
К этому добавились и финансовые вопросы: оборудование для офисов и поддержка распределённой инфраструктуры стоили дорого. Так родилась идея поэкспериментировать с централизацией инфраструктуры проектирования — внедрить VDI, серверы которого размещались бы в московском офисе и имели бы высокоскоростной канал связи с ревит-серверами.
Подробности об удалёнке, её плюсах и минусах с точки зрения BIM и менеджмента, можно прочесть в отдельной статье, а мы перейдём к более техническим вопросам.
Обстановка на рынке
В 2018 году всё было достаточно тривиально: существовало всего два серьёзных решения — Citrix и Horizon. На мой взгляд, с тех пор мало что изменилось: реально экономически эффективных систем всё ещё две.
Но активно стали появляться отечественные решения, и развиваются они, стоит признать, очень бодро. Из коробочных альтернатив, доступных сейчас на российском рынке, можно назвать отечественные Termidesk, SpaceVM, HostVM, «Базис», да ещё китайский CStack. Все эти системы находятся на разной степени готовности, но объединяет их одно: по гибкости и соотношению цены и качества они пока не дотягивают до решения VMware (нынче — Omnissa).
Появились и услуги VDI as a Service у множества облачных провайдеров — построенные как на базе тех же Horizon и Citrix, так и на основе собственных разработок. Однако их мы в рамках этой статьи рассматривать не будем.
Итак, пока что именно таким образом можно описать обстановку по состоянию на конец 2025 года. Мы в ПИК ежегодно проводим оценку рынка VDI и искренне надеемся, что в будущем отечественные разработки смогут составить реальную конкуренцию именитым игрокам.
Точка старта
Предположим, вы уже приняли решение внедрять VDI в компании. С чего начать работу?
Мы, как и многие, начали с интегратора. На тот момент у нас не было опыта в построении таких систем, да и с технологиями VMware команда была знакома довольно поверхностно. Решение обратиться к специалистам, которые уже «собаку съели» на VDI, казалось самым логичным.
Но вы ведь пришли читать пост не за этим. «С интегратором каждый может, а сами-то внедрить — слабо?», — спросит читатель.
Вовсе нет. С момента того первого внедрения прошло много лет –– за это время мы не только основательно прокачались в эксплуатации VDI, но и несколько раз пересобрали всю систему с нуля. Присутствует у нашей команды и опыт внедрения VDI на других крупных предприятиях. Поэтому приступим к описанию потребностей пользователей и назначения системы.
От потребностей к конфигурации железа
В нашем случае формулировка получилась такая: «высокопроизводительные виртуальные машины для работы с 3D-моделями в проектировочном ПО, таком как Revit». Поскольку речь шла прежде всего об оптимизации затрат на удалённые офисы, машины должны были обладать хорошим соотношением цены и производительности.
В итоге мы пришли к следующей базовой конфигурации виртуальных машин:
ЦП | 4 ядра @ 3 ГГц |
ОЗУ | 24 Гб |
vRAM | 1 Гб (p40-1b) |
SSD | 50 Гб |
Сеть | 10 Гбит/с |
Но это конфигурация 2018 года. Позже она неоднократно пересматривалась и «подгонялась» под актуальное железо. Сейчас она выглядит примерно так:
ЦП | 8 ядер ЦП @ 3,6 ГГц |
ОЗУ | 45 Гб |
vRAM | 2 Гб (a16-2b) |
SSD | > 175 Гб |
Сеть | 10/25 Гбит/с |
В соответствии с этими требованиями (первой конфигурации) мы заказали несколько серверов — по два восемнадцатиядерных Intel Xeon 6154 на каждый, с 1 ТБ оперативной памяти и двумя видеокартами NVIDIA Tesla P40 на борту. Также установили по две сетевые карты на 10 Гбит/с и набор SSD для организации vSAN (о нём поговорим в одном из следующих постов).
Серверы в целом оказались неплохими, но в сайзинге была допущена критическая ошибка: предполагалось, что на них разместятся до 40 пользователей. На практике процессоры не вывезли такую орду виртуалок и дружно упёрлись графиками нагрузки в потолок.
Позже плотность пользователей на этих серверах снизили до 32, а мы взяли за правило не допускать загрузку процессоров гипервизоров выше 75%, поскольку опытным путём выяснили: примерно с этого уровня пользователи начинают жаловаться на заметные тормоза.
Из этого же опыта родилось второе правило: при сайзинге не допускать переподписку по процессорным ядрам выше 1:4, чем мы впоследствии поступились и не прогадали. В отличие от наших первых ксеонов, современные процессоры легко справляются с соотношением 1:5, 1:6 и даже больше, в зависимости от нагрузки.
Наши первые серверы в строю и по сей день, но плотность размещения на них пришлось снизить ещё больше — до 24 на сервер, чтобы сохранить стабильность при возросших требованиях современного софта. Этот опыт говорит нам о том, что конфигурацию следует не просто выбрать и забыть, а постоянно пересматривать во время эксплуатации.
Наиболее экономически эффективно показывают себя конфигурации с высокой плотностью — от 40 пользователей на сервер и выше, ведь их стоимость складывается не только из процессоров и прочих деталей, но ещё и из платформы, лицензий и логистики, затраты на которые, в отличие от железа, масштабируются линейно. Например, наша текущая «боевая» конфигурация рассчитана на 64 пользователя на сервер.
Сейчас мы используем процессоры AMD Epyc 9474f, они при правильном охлаждении обеспечивают частоту выше 4 ГГц в нагрузке около 70% и, что немаловажно, имеют гигантский L3-кэш, что положительно влияет на нагрузки в виде виртуалок VDI.
L3-кэш часто недооценивают и совершенно напрасно! Крупный общий кэш снижает обращения к оперативной памяти и ускоряет работу ВМ, в особенности когда дело касается машин с одинаковыми операционными системами и наборами софта, а это как раз наш случай.
Нет, виртуальные машины не имеют доступа к кэшу друг друга, но за счёт одинаковых рабочих наборов данных часть кэша повторно используется и «горячие» страницы ОС и ПО почти всегда находятся в L3. Это снижает задержки и повышает стабильность при высокой плотности и конкуренции за физические ядра.
Вопросы начинаются при использовании ВМ с очень большим количеством ядер, так как они вылезают за пределы NUMA нод, но это уже не наш случай и совсем другая история.
В соответствии с вышеописанным уже можно сделать выводы и подобрать процессоры под нужды своих виртуалок. А ещё — подумать над видеопрофилем.
Видеопрофиль — это непонятные буквы из таблицы выше: a16-2b. Состоит он из трёх частей. Первая — наименование видеокарты (а16). Вторая — объём выделенной видеопамяти (2). Третья — режим работы (B). Первое и второе мы обсудим дальше по ходу поста, а вот на третьем остановимся прямо сейчас.
Режимов нам доступно всего два, это B и Q. Есть и другие, но мы не будем на них останавливаться, так как для наших задач они не подходят. В чём же разница между этими двумя? Профиль Q даёт виртуальной машине доступ к продвинутым вычислениям (CUDA, например), а B — не даёт. Также для Q открыты большие размеры видеопамяти. Вот только лицензия на профили Q стоит в буквальном смысле в пять раз дороже, чем B. Если верить документации NVIDIA, пользователи CAD приложений должны работать на профилях Q, но по факту оказалось, что B справляются с AutoCAD и Revit не хуже при меньшей стоимости. На них мы и остановились.
Память — оперативная и не очень
Никого не удивлю, сказав, что сервер состоит не только из процессоров. Имеет место ещё и ворох всяческих запоминающих устройств, о них сейчас и поговорим. Начнём с самого основного: оперативной памяти. Здесь всё достаточно просто.
Тип оперативной памяти сразу же определяется выбранной платформой, а она, в свою очередь, процессором. С частотой памяти тоже никаких сложностей — чем она больше, тем лучше. В серверных конфигурациях выбор по частоте ОЗУ и так невелик, а чувствительность к ней у нагрузок типа VDI невысока, так что с этим вопросом можно особо не заморачиваться.
Что действительно важно, так это объём памяти. Он вычисляется путём перемножения количества ВМ, которые планируется размещать на одном хосте, на объём памяти одной машины.
Здесь следует упомянуть одну важную особенность виртуальных машин с vGPU — вся память для них резервируется при запуске полностью. С такими машинами не работает ни технология динамической памяти, ни page sharing и ballooning (потому что бессмысленно), а их память не свопится на диск. Так что никакой переподписки по ОЗУ, только беспощадное полное резервирование.
Ах да, и не стоит забывать о том, что некий резерв требуется для работы самого гипервизора, живой миграции и vSAN. Скажем, 10% от общего объёма. 100–150 св��бодных Гб в оперативке должно с избытком хватать на любые потребности ESXi.
Примерно тот же подход используется при планировании видеопамяти, только в этот раз не нужно оставлять никакого запаса: наша цель — забить её максимально плотно, как минимум, ради экономической эффективности. Объём видеокарты делим на размер желаемого видеопрофиля, и вот ровно столько ВМ влезет на одну карту.
А какой, кстати, размер видеопрофиля — желаемый? Здесь нашим ориентиром стали системные требования ПО, в котором будут работать пользователи и субъективный опыт. Мы в своё время перешли с профилей на 1 Гб к профилям на 2 Гб. Больше пока нашим пользователям не требуется, но время идёт, ПО становится прожорливее, разрешение мониторов растёт, и недалёк тот день, когда придётся перейти к 4 Гб.
Набиваем сервер необходимым числом видеокарт и не забываем при этом убедиться, что PCIe-слотов и линий PCIe достаточно как для самих видеокарт, так и для дополнительной периферии, например сетевых плат, которых потребуется не меньше двух.
И раз уж речь зашла о vGPU, память мы обсудили, а как же сами видеоядра? В отличие от видеопамяти, жёстко резервируемой под каждую отдельную машину, видеоядро на части не делится и имеет планировщик, который гибко распределяет вычислительную мощность между потребителями. В общем случае есть простое правило: чем видеокарта новее, тем она производительнее. При желании сравнить терафлопсы в пересчёте на рабочее место всегда можно подсмотреть подробности о конкретном GPU на сайте NVIDIA.
Опытным путём мы определили, что конкретно для наших нагрузок достаточную вычислительную мощность предоставляет абсолютно любая видеокарта не старше пяти лет, поэтому ориентировались при сборке последнего кластера в основном на соотношение видеопамяти и стоимости. Выбраны карты NVIDIA Tesla A16 — оптимальное решение по стоимости гигабайта и плотности видеопамяти.
Перед тем, как перейти к завершению, отвечу на частый вопрос об оперативке: что будет, если с сайзингом вышла ошибока и память всё же исчерпается в процессе эксплуатации? Если коротко: ничего катастрофического не произойдёт. Выделенное под vSAN и работу гипервизора пространство исчерпать не получится — оно строго зарезервировано. Резервирование памяти под виртуальные машины с vGPU, напоминаем, всегда полное, соответственно, никаких проблем с переподпиской и жёсткого свопинга тоже не ожидается. А вот живая миграция при плотно забитой оперативке может начать буксовать.
Естественно, забитая память будет препятствовать запуску новых ВМ, и хост может не выйти на расчётную плотность размещения рабочих мест. В таком случае придётся либо докупить ему оперативки, либо умерить аппетиты машин.
Заключение
На этом первая часть цикла о планировании и внедрении VDI подходит к концу. Мы разобрались, как подобрать основные аппаратные компоненты для наших будущих серверов VDI, и наметили конфигурацию ВМ для пользователей.
Тема подбора процессора достаточно обширная, и при отсутствии тестовых образцов очень тяжело выбрать какой-то конкретный. Хорошо, если есть возможность взять готовый сервер «на попробовать» и потестировать там пользовательские нагрузки. Если же такой опции нет, всегда можно обратиться к коллегам в открытых профильных чатах.
Как вы уже поняли, планировать мы будем много и подробно. Не стоит этого пугаться, ведь чем детальнее план внедрения, тем меньше сложностей возникнет в процессе его реализации!
Дальше будет интереснее: разберём, где хранить данные (спойлер: на vSAN), а также узнаем, как оценить ёмкость будущего датастора и как подобрать диски под ваши нужды.
