Цель статьи — рассказать про продукт и его архитектуру. По сути то, что постоянно рассказывают наши технические пресейл-инженеры нашим партнерам и заказчикам. Немного покидаемся помидорами в «конкурентов», совсем чуть-чуть. Куда без этого :D Спойлер: про вирус в статье ничего нет, кроме этого предложения. Так сложилось исторически, что внутри большого интегратора IBS завелся Департамент продуктового развития и производства. Раньше его еще неофициально называли Interlab. Сотрудники этого департамента занимаются исследованием перспективных технологий, проверкой гипотез, тестированием различных решений и, как не сложно догадаться, созданием собственных продуктов. Собственно, так была создана линейка продуктов, в названии которых присутствует слово «Скала». Сегодня речь будет идти о программном продукте — VDI-решении (virtual desktop infrastructure) Скала-Р Виртуальное Рабочее Место. Сокращенно — Скала-Р ВРМ. Все предельно просто. Мы верим в эту технологию. У нас есть опыт как внедрения VDI, так и участия в ее разработке. Проекты внедрения VDI не такие простые, так как затрагивают работу многих пользователей. Но нам кажется, что время VDI пришло. Мы видим спрос на такие решения на российском рынке. Многие заказчики стали учитывать санкционные риски, у некоторых даже есть KPI по импортозамещению. Ряд организаций уже давно активно используют подобные продукты западных производителей (самые популярные — Citrix и VMware). Другие ничем подобным не пользовались, но преимущества технологии осознают и готовы сделать ставку на отечественные решения. Наша команда уже не первый раз разрабатывает VDI-решение. Вместе с коллегами из Virtuozzo (подразделение Parallels, которое занимается виртуализацией) мы разработали совместно за 4 года продукт для виртуализации рабочих мест — Parallels VDI. В этом сотрудничестве наша команда занималась формированием технических и бизнес-требований к продукту. Наш партнер превращал требования в код. Особенностью этого продукта было использование контейнерной виртуализации Windows, которую разработала Parallels. Microsoft в то время о собственных контейнерах даже не думала. Продукт имел свои плюсы, были и технические трудности (в том числе из-за контейнеров). В конечном итоге мы провели сертификацию ФСТЭК Parallels VDI и Virtuozzo Containers for Windows. Провели несколько внедрений. К сожалению, по ряду причин продукт прекратил существование. Права на код остались у партнера, из-за чего сами развивать продукт дальше мы не имели права. Однако интерес к отечественному VDI остался. Кроме совместной разработки Parallels VDI, у нас есть богатый опыт реализации проектов по консолидации рабочих мест с использованием решений Citrix и VMware. В общем, наша команда видела, пожалуй, все, что творится «под капотом» VDI-решений. Мы хорошо знаем, как они должны быть устроены и чем отличаются от простой виртуализации. Всем известно, как быстро в нашей стране разрабатываются отечественные решения из open source. Возможно, в этом ничего страшного нет, но наш опыт показал, что на рынке часто происходит подмена понятий. Системой VDI могут назвать продукт, в котором все делается за счет «ручного привода»: администратор создает виртуальную машину (ВМ), администратор передает IP-адрес пользователю, пользователь подключается по протоколу по инструкции к конкретной ВМ. Даже минимальная автоматизация жизненного цикла ВМ отсутствует. Да, для малых организаций этого может быть достаточно. Но называть это промышленным VDI-решением категорически нельзя! Наблюдая такое безобразие, мы попытались сформулировать гигиенический минимум функций промышленного VDI-решения. Который, кстати, в том числе помог нам в разработке Скала-Р ВРМ. Надо признать, что не все собирают что-нибудь из open source на коленке. Видели товарищей, без стеснения совести предлагающих в государственных организациях использовать испанский VDI, который умеет интегрироваться с OpenNebula. Признаться честно, мы не знаем, насколько он хорош. Но то, что его нет в реестре отечественного ПО — это факт. Интерес к отечественному VDI есть. Есть и предложение, хотя по опыту у многих отечественных разработчиков все работает только на слайдах в PowerPoint. Очевидный вывод — надо сделать свой хороший промышленный VDI, который будет максимально близок к мировым лидерам в этой области. Кроме того, к моменту принятия решения мы уже разрабатывали собственную систему управления виртуализацией «Скала-Р Управление». Так что создать свой VDI с собственной системой управления виртуализацией — решение логичное и очевидное. Итак, в конце 2016 года мы усилили нашу команду и начали собственную разработку с нуля. Вся кодовая база была под нашим контролем, писали код преимущественно на Python. Наш прошлый опыт дал нам крутой буст. Так что побежали мы быстро. VDI-решение IBS Скала-Р Виртуальное Рабочее Место (ВРМ) — это программный комплекс для виртуализации рабочих мест пользователей. Назначение: Наше решение позволяет организовать виртуальные рабочие места, функционирующие на серверных мощностях в контролируемом периметре центра обработки данных. Подключаться к ним можно с защищенного устройства доступа на отечественной ОС. Целевые потребители — средние и крупные промышленные предприятия, государственные и коммерческие организации, госкорпорации, региональные и федеральные ведомства и органы власти. В прошлой статье, где мы рассказывали о нагрузочном тестировании на 16000 пользователей, мы уже затрагивали архитектуру решения. Тем кто ее не читал, рекомендую ознакомиться с разделом «Этапы подключения пользователя в виртуальный рабочий стол». Там достаточно подробно описано, как компоненты взаимодействуют в сценарии авторизации и подключения пользователя. В этой статье подробнее рассмотрим основные функции компонентов Скала-Р ВРМ. Схему можно увидеть в самом начале статьи. Компоненты будем рассматривать слева направо. Но сперва стоит сказать о функции, которая есть у всех компонентов нашего VDI-решения — контроль целостности. Как во время запуска компонента, так и систематически производится проверка его целостности (время проверки можно настраивать). Если целостность нарушена — компонент прекратит работу. Клиент ВРМ — клиентское ПО, которое устанавливается на устройство доступа пользователя. Представляет графический интерфейс взаимодействия конечного пользователя с инфраструктурой VDI. На момент написания статьи Клиент ВРМ есть для следующих ОС (список пополняется в зависимости от потребностей партнеров и заказчиков): Протокол доставки виртуального рабочего стола — исполнительный механизм, доставляющий картинку на устройство доступа, а управляющие воздействия пользователя в виртуальный рабочий стол в ЦОДе. От возможностей данного протокола зависит набор сервисов, которые будут работать (проброс принтеров, общий буфер обмена, смарт-карты и т.д.). И как они будут работать. Собственного протокола доставки рабочего стола у нас пока нет. Поэтому осуществляем поддержку существующих. Используем разные протоколы для подключения в виртуальные рабочие столы с разными ОС: Возможности протоколов представлены в таблице ниже: Как видите, для рабочих столов на Linux доступны не все функции, имеющиеся в Microsoft RDP из коробки. Главный критерий, по которому в свое время мы выбрали RX@Etersoft — это возможность проброса смарт-карты как известного устройства. В таком случае смарт-карта видна и в устройстве доступа, и в виртуальном рабочем столе. А это важно, если используются защищенные тонкие клиенты, в ОС которых пользователь авторизуется также по сертификату со смарт-карты. Если смарт-карта не будет видна локально, устройство заблокируется. Если на данный момент в SPICE что-то улучшилось, просим поделиться в комментариях. Настраивается протокол не только Клиентов ВРМ на устройстве доступа, но и в виртуальном рабочем столе при помощи нашего Агента ВРМ, до которого мы скоро дойдем. Диспетчер подключений — компонент, терминирующий на себе подключения пользователей. Это прокси, который передает управляющий трафик брокер-менеджерам, а трафик протокола доставки рабочего стола в виртуальный рабочий стол. Размещать его стоит в ДМЗ как пограничный компонент. На Диспетчерах подключений настраивается одна из четырех политик аутентификации: Причем можно указать разные политики для разных диспетчеров. Так, указывая разные Диспетчеры подключений в конфигурационном файле Клиента ВРМ, можно настроить разные политики для разных пользователей. Обычно этого не требуется, и настраивается одна политика для всех. Отказоустойчивость Диспетчеров подключений реализована очень просто. В Клиенте ВРМ указывается их список. Клиент ВРМ подключается к первому из списка, если не удается — ко второму и т.д. Отсюда возникает законный вопрос: как происходит балансировка пользователей между Диспетчерами подключений, если пользователей десятки тысяч? Собственный балансировщик в планах развития, поэтому пока используем сторонний, который пулирует соединения пользователей на разные Диспетчеры подключений. А чтобы это можно было делать эффективнее, через API можно получать коэффициент текущей загруженности Диспетчера подключений по шкале от 0 до 1. Опыт показал, что один Диспетчер подключений выдерживает около 2000 сессий пользователей. Если инсталляция на чуть большее количество пользователей, можно административно для части пользователей указать Диспетчеры подключений в конфиге Клиента ВРМ в одном порядке, для другой части пользователей — в другом порядке. Большая часть функционала замкнута на этом компоненте. Боюсь, всего мы здесь не опишем. Попробуем выделить основное: Брокер-менеджер — это компонент, который взаимодействует со всеми остальными компонентами Скала-Р ВРМ и управляет ими.  LDAP комментариев не требует. В любой организации есть LDAP каталог в качестве централизованной системы управления учетными записями пользователей. Мы поддерживаем интеграцию с Microsoft Active Directory и линуксовыми реализациями LDAP/Kerberos. PostgreSQL — конфигурационная база для хранения данных системы. Можно использовать российскую СУБД Postres Pro, даже сертифицированную. Однако обычно достаточно ванильного. Агент ВРМ — ключевой компонент по управлению и подготовке виртуального рабочего стола. Устанавливается на этапе подготовки шаблона, после чего может обновляться из веб-панели администратора. На наш взгляд, именно этот компонент критически необходим для автоматизации подготовки рабочего стола. Без него обеспечить адекватное управление рабочим столом (ввод в домен, настройку firewall, настройку разрешений на проброс устройств и т.д.) просто невозможно. А если управление осуществляется вручную, без агента, такое решение назвать VDI нельзя. Поэтому, наличие этого «засланного казачка», обычно отличает промышленное VDI-решение от собранного на коленке «ручного привода». Функции, которые выполняет Агент ВРМ: Скала-Р Управление. Наша система управления платформой виртуализации. На рисунке компонент изображен монолитно, т.к. основное внимание в данной статье уделяется системе VDI. На самом деле там также есть отказоустойчивость, возможность масштабирования и распределение нагрузки. В рамках данной статьи не будем затрагивать детально возможности этого продукта. Если будет интересно, что он умеет, напишите в комментарии — подготовим отдельную статью. Агент Скала-Р Управление. Компонент на хосте виртуализации, который транслирует команды Скалы-Р Управление гипервизору и собирает данные с хоста. Подробнее — отдельной статьей, если будет интерес. Виртуальные рабочие столы существуют только в рамках пулов рабочих столов. Пулы рабочих столов нужны, чтобы соотнести размещение ВМ в пуле ресурсов системы управления виртуализацией. Есть несколько типов пулов рабочих столов: Рассмотрим каждый по отдельности. Данный пул характеризует минимальная автоматизация и ручное создание под каждого пользователя виртуального рабочего стола из шаблона руками администратора. Сценарий использования — рабочие столы для руководства или сотрудников с очень специфичным набором ПО. Посмотрим настройки персонализированного пула: Как видите, в настройках даже нельзя задать шаблон рабочего стола. Все потому, что каждый рабочий стол создается администратором по отдельности.  Из параметров, заслуживающих отдельного внимания: Меню создания персонализированного рабочего стола: Тут уже присутствует выбор шаблона и учетной записи пользователя. Персонализированные рабочие столы назначаются на конкретные учетные записи пользователей. Однажды нас попросили сделать персонализированные рабочие столы, но так, чтобы не создавать каждый рабочий стол по отдельности. Чтобы раз создал на всех из одного шаблона, и все. Лень, знаете, — двигатель прогресса. Сценарий использования: набор персонализированных рабочих столов с одинаковым ПО.
Настройки пула: Тут настроек уже поприбавилось. Рассмотрим отличительные параметры: Сценарий работы данного пула следующий: администратор создает данный пул, система автоматически создает «минимальное количество» виртуальных рабочих столов, которые пока никем не заняты; когда пользователь подключается первый раз, за ним резервируется конкретный виртуальный рабочий стол. Все, рабочий стол, на который назначен пользователь, стал персонализированным. Учетная запись пользователя намертво ассоциируется с конкретным столом, пока администратор не разлучит их. Если минимальное количество меньше максимального, возможен сценарий, когда все свободные рабочие столы из «минимального количества» уже разобраны. В таком случае для конкретного пользователя система автоматом создаст виртуальный рабочий стол. Так до тех пор, пока не упремся в «максимальное количество». Самый интересный пул с максимальной автоматизацией. Сценарии использования: типовые стандартизированные рабочие столы пользователей; географическое распределение пользователей по часовым поясам и сменный график пользователей. Настройки пула: Рассмотрим отличительные параметры: Параметры сессионного пула позволяют создавать виртуальные рабочие столы по количеству активных пользователей. Актуальная задача, которая позволит сэкономить аппаратные ресурсы для крупных распределенных организаций или сменного графика работы. Мы считаем, пользователь не должен подключаться напрямую в рабочий стол, т.к. любое подключение должно контролироваться системой. Нехорошо, если после первого подключения пользователь сможет запустить протокол доставки рабочего стола и подключиться по подсмотренному IP-адресу. Никаких логов в VDI-системе о его подключении не останется. В общем, не стали бы мировые лидеры в области VDI делать различные Security Getway на сетевом периметре в ДМЗ. Мы опыт мировых лидеров уважаем, поэтому сделали таким же наш Диспетчер подключений. Диспетчер подключений как часть серверной составляющей VDI-решения устанавливается в демилитаризованной зоне и обеспечивает подключение пользователей к VDI-инфраструктуре. Прямого сетевого доступа к виртуальным рабочим столам или брокер-менеджеру, или еще кому-либо у пользователя нет. В качестве следующего шага необходимо исключить возможность подключения в соседний рабочий стол: пользователь легитимно подключается в свой рабочий стол, смотрит свой IP-адрес, и методом подбора пытается подключиться к соседнему рабочему столу в этой сети.  Тут на помощь приходит Агент ВРМ, который в закрытом firewall открывает нужный порт для подключения пользователя через Диспетчер подключений. Все остальное закрыто. По окончании сессии порт закрывается. Как следствие, нелегитимным путем подключиться не получится, только после авторизации в системе. А если есть авторизация, значит, мы уже залогировали устройство, с которого подключались, пользователя и рабочий стол, в который подключались. В случае инцидента сотрудники ИБ скажут нам спасибо. Кстати, системные логи мы умеем отправлять сразу по syslog в системы типа SIEM. Получилось достаточно подробно рассказать про наше VDI-решение, хотя и объемно.
Далее просим всех в комментарии. Очень хочется увидеть обратную связь: ваши мнения, комментарии, вопросы.