Задумывались когда-нибудь, что делает сканер с VDI-станцией? Сначала всё выглядит хорошо: он пробрасывается как обычное USB-устройство и «прозрачно» виден с виртуальной машины. Дальше юзер даёт команду на сканирование, и всё к чертям падает. В лучшем случае — драйвер сканера, похуже — через пару минут софт сканера, потом может поаффектить и других пользователей кластера. Почему? Потому что, чтобы получить пятимегабайтную сжатую картинку, нужно отправить через USB 2.0 на два-три порядка больше данных. Пропускная способность шины 480 Мбит/с.

Так что тестировать надо три вещи: UX, периферию и безопасность — обязательно. Есть разница, как тестировать. Можно установить агентов локально, на каждой виртуальной рабочей станции. Это относительно бюджетно, но не показывает нагрузку на канал и не совсем верно считает нагрузку на процессор. Второй вариант — развернуться в другом месте нужным количеством роботов-эмуляторов и начать их коннектить к реальным рабочим местам как настоящих пользователей. Добавится нагрузка от протокола передачи видеопотока экрана (точнее, изменённых пикселей), разбор и отправка сетевых пакетов, будут понятны нагрузки на канал. Канал вообще очень редко проверяется.

UX — это скорость выполнения разных действий конечным пользователем. Есть пакеты тестов, которые нагружают инсталляцию сотнями пользователей и делают типичные для них действия: запускают офисные пакеты, читают PDF, браузят, редко-редко смотрят порно в рабочее время и так далее.

Довольно хороший пример того, почему такие тесты важны заранее, был в последней инсталляции. Там тысяча пользователей переезжает в VDI, у них офис, браузер и SAP. ИТ-отдел в компании развитый, поэтому есть культура нагрузочного тестирования перед внедрениями. По моему опыту, обычно заказчика приходится уговаривать на такое, потому что затраты большие, а польза не всегда очевидна. Есть же расчёты, где можно ошибиться? На деле — такие тесты вскрывают места, где думали, но проверить не могли.

Инсталляция

Шесть серверов, конфигурация вот:



К СХД заказчика у нас доступа не было, предоставлялась она уже в виде места как сервис, фактически. Но мы знаем, что там all-flash. Какая именно all-flash, не знаем, но разделы по 10 ТБ. VDI — VMware по выбору заказчика, поскольку стек ИТ-команде уже знаком, и всё довольно органично дополняется до целостной инфраструктуры. VMware очень «подсаживает» на свою экосистему, но если бюджета в закупке хватает — годами можно не знать проблем. Но это часто очень большое «если». У нас хорошая скидка, и заказчик об этом знает.

Начинаем тесты, потому что ИТ-команда не пускает в прод почти ничего без тестов. VDI — это не та вещь, которую можно запустить, а потом принять. Пользователи загружаются постепенно, и с проблемами вполне можно столкнуться через полгода. Чего, естественно, никому не хочется.

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







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













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

Периферия

С периферией обычно три ситуации:

• Заказчик просто говорит, что ничего не подключаем (ну, кроме гарнитур, они обычно видны «из коробки»). Последние примерно лет пять я очень-очень редко вижу гарнитуры, которые не подцепились бы сами по себе, и которые не подхватила бы VMware.
• Второй подход — берём и в рамках проекта внедрения VDI меняем периферию: берём протестированное нами и заказчиком поддерживаемое. Случай по понятным причинам редкий.
• Третий подход — прокидываем имеющееся железо.

Про проблему со сканерами вы уже знаете: нужно ставить промежуточный софт на рабочую станцию (тонкий клиент), который получает поток USB, сжимает картинку и отправляет в VDI. В силу ряда особенностей, это не всегда возможно: если на Win-клиентах (домашних компьютерах и тонких клиентах) всё хорошо, то для *nix-сборок обычно вендором VDI поддерживается какой-то конкретный дистрибутив и начинаются танцы с бубном, как и на Mac-клиентах. На моей памяти мало кто подключал локальные принтеры с Linux-инсталляций так, чтобы они на этапе отладки работали без постоянных звонков в поддержку. Но это уже хорошо, некоторое время назад — даже просто чтобы работали.

Видеоконференцсвязь — все заказчики рано или поздно хотят, чтобы это работало и работало хорошо. Если правильно спроектировали ферму, то это работает хорошо, если неправильно — получаем ситуацию, когда у нас во время аудиоконференции растёт нагрузка на канал, плюс дополнительно помимо этого возникает проблема того, что картинка отображается плохо (full HD нет, лицо из 9–16 пикселей). Возникает очень сильная дополнительная задержка, когда появляется петля между клиентом, рабочей станцией VDI, сервером ВКС, оттуда вторым VDI и вторым клиентом. Правильно соединять сразу с клиента на сервер ВКС, что требует установки ещё одного дополнительного компонента.

USB-ключи — с ними вообще проблем нет, смарт-карты и подобное, всё работает из коробки. Сложности бывают со сканерами штрихкодов, принтерами этикеток, станками (да, было и такое), кассами. Но всё решается. С нюансами и не без сюрпризов, но в конечном счёте решается.

Когда пользователь смотрит Ютуб с VDI-станции — это самая плохая ситуация и для нагрузки, и для канала. Большинство решений предлагает HTML5 видео редирекшн. Сжатый файл передают на клиента, там показывает. Или же клиенту передаётся ссылка для прямой связи браузера и видеохостинга (это реже).

Безопасность

Безопасность обычно искрит на месте стыков компонентов и на клиентских устройствах. На стыках в одной экосистеме на словах всё должно работать хорошо. На практике так бывает процентах в 90 % случаев, и что-то всё равно надо доделывать. В последние годы очень удобной оказалась ещё одна покупка Вмвары — они взяли в экосистему MDM для управления устройствами внутри компании. У ВМов появились недавно интересные сетевые балансировщики (бывший Avi Networks), которые позволяют закрыть вопрос распределения потоков через год после сдачи VDI, например. Ещё одна чисто вмварная особенность — хорошая оптимизация филиалов благодаря их свежему шопингу, когда они взяли компанию VeloCloud, которая делает SD-WAN для филиальных сетей.

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

Особенность VDI-инсталляций сейчас в том, что у конечного пользователя дома просто нет компьютера. Часто есть слабый андроид-планшет (иногда даже с мышью или клавиатурой), либо же может вообще повезти и получить компьютер на Win XP. Которая, как вы можете догадаться, некоторое время не обновлялась. И не обновится никогда уже. Либо очень слабые машины, где клиент не ставится, приложения не работают, пользователь не может работать. По счастью, даже очень слабые устройства подходят (не всегда комфортно, но подходят), и это считается большим плюсом VDI. Ну а относительно безопасности — надо тестировать компрометацию клиентских систем. Это случается достаточно часто.

В свете рекомендаций Роспотребнадзора по организации работы предприятий в условиях риска COVID-19, подключение к своим рабочим местам в офисе очень актуально. Похоже, что эта история надолго, и да, если вы думали про VDI — можно начинать тестировать. Пригодится. Рекомендации лежат вот здесь, разъяснения вот тут. Важно, что с помощью VDI также можно переоборудовать помещения для соблюдения требований. Регулятором вводятся определённые нормы дистанцирования. Например, в офисе площадью 50 кв. м не может находиться более пяти сотрудников.

Ну а если есть вопросы по VDI не для комментариев — вот моя почта: SSkryl@croc.ru.