company_banner

Подводные камни при переходе на VDI: что тестировать заранее, чтобы не было мучительно больно

    image

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

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

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

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

    Инсталляция


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

    image

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

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

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

    image

    image

    image

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

    image

    image

    image

    image

    image

    image

    Собственно, если что-то где-то тормозит — нужно менять настройки 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.
    КРОК
    IT-компания

    Комментарии 12

      0

      Не так давно как раз VDI от вмвари пытался смотреть. Насколько я понял нужен KMS ключ для win10, а вот по офису не понял, как его правильно активировать. До нагрузочных тестов не дошел, отсюда вопрос. Какое количество вм может потянуть сервер уровня 2x 2690v2, 380GB, fas 2240 на 24шт 10к rpm дисках (да новее ничего не нашлось). Есть ли смысл разворачивать инфраструктуру не имея all flash схд? (Планировалось зарулить на этот сетап порядка 80-100 сотрудников) Паттерн нагрузки аутлук, веб, местами клиент-серверный 1С.

        0
        Никто вам не ответит потянет ли ваши процессоры нагрузку VDI
        Если кто-то готов дать 100%, гарантию гоните его подальше.
        Правильный подход — звоните интегратору получаете тестовую установку за бесплатно (в обмен на обещание купить лицензии на VDI)
        Ручной вариант:
        Определяетесь с типом VDI (linked clones или instant clones) от этого зависим производительность и цена лицензий.
        Определяетесь с содержанием золотого имиджа (там офис? 1С? корел? автокад ?) — это даст возможность посчитать память и нагрузку на процессор.
        Ставите тестовую инсталяцию — и проверяете работу.
        Почему не посчитать ручками? Условно говоря считается хорошим вариантов это процессор виртуализируется из расчета 4 или 7 к 1 реальному (тоесть процеесор с 10 ядрами можно раздать как 40 или 70 ядер по VDI) но, все зависит от нагрузки.
        Простенький вариант — windows+офис+браузер — 2 ядра и 4г памяти но… это условности, в рабочем варианте это связка может уже тормозить и придется добавлять ресурсы

        Не забывайте про резервирование памяти и процессоров что бы в случаи сбоя было куда переездать виртуалкам ( условно говоря, на двух серверах должно быть по 50% свободных ресурсов, на трех уже 33% ).
          +1
          Если возможности провести пилот и нагрузочное тестирование нет, то можно ориентироваться на опыт подобных развертываний. По нашему опыту, для офисных пользователей (судя по описанию сценария использования, это как раз ваш случай) для комфортной работы на Windows 10 вполне достаточно следующих характеристик: 2 vCPU и 6 ГБ оперативной памяти. По коэффициенту переподписки vCPU на физическое ядро лучше ориентироваться на 4 к 1. По оперативной памяти лучше не заполнять более 80% объема в сервере.
          В вашем случае получается:
          Количество пользователей по процессорам — 20 ядер * 4 (коэффициент переподписки 4 к 1) / 2 vCPU у виртуальной рабочей станции = 40 виртуальных рабочих станций.
          Количество пользователей по памяти — 380 ГБ в сервере * 0,8 / 6 ГБ у виртуальной рабочей станции = 50
          Выбираем наименьшее значение. Это, конечно, грубый расчет, но на него можно ориентироваться.
          И совершенно согласен с awsswa59, если вы хотите, чтобы пользователи сохранили работоспособность после выхода из строя сервера, то нужно всегда использовать схему N+1, чтобы как минимум один сервер всегда был в резерве.
          Без all-flash СХД можно обойтись, просто виртуальные рабочие станции будут медленнее работать.
          0

          А как и куда такие объемы бекапить, или дедупликация все это проделывает до каких то адекватных размеров?

            0
            Ну для начала надо понимать что весь VDI бекапить не нужно.
            Обычно VDI структура выглядит так.
            Золотой имидж (это предположим windows 10 и офис ) он находится в режиме чтения.
            С него стартуют виртуальные машины и все изменения (документы, почта, работа в браузере) сохраняются на отдельный диск (условно говоря перемещаемый профиль).
            И вот его уже нужно сохранять.
            А дальше уже от обьемов, хороший вариант внешнее хранилище с возможностью добавление дисков по мере роста и veeam
              0
              Опять же согласен с awsswa59 :) Делать резервные копии для всех виртуальных рабочих станций не нужно. В зависимости от развертывания нужно бэкапить следующее:
              1. Инфраструктурные компоненты.
              2. Шаблоны виртуальных рабочих станций (для Linked Clone и Instant Clone).
              3. Сами виртуальные рабочие станции (для Full Clone).
              4. Данные пользователей переправленные на файловый сервер.
              Да, и дедупликация отлично работает для VDI-сценариев.
              0
              Пожалуйста, расскажите:
              450 «юзеров» в тесте, нагрузку генерируем локально. Робоюзеры делают разные действия одновременно

              Чем генерировали нагрузку?

              мы измеряем время каждой операции в течение нескольких часов работы

              Чем измеряли?

              Спасибо!
                0
                Для генерации и измерения нагрузки используем ПО VMware View Planner — www.vmware.com/go/download-viewplanner
                Он бесплатный и вполне хорошо справляется со своей задачей.
                0

                Сергей, поищи сканеры со встроенной jpeg компрессией. Они работают через usb redirection лучше, чем обычные через twain redirection ( только win клиент). Кроме того такой проброс доступен на любой клиентской ОС ( кроме телефонов) и на типа зеро клиентах

                  0
                  Мы обычно стараемся убедить наших заказчиков отказаться от использования локальной периферии там, где это возможно, и использовать сетевые устройства (МФУ, принтеры, сканеры). Но иногда приходится иметь дело с зоопарком устройств со средним возрастом 7+ лет, вот тогда и начинаются проблемы
                  А JPEG компрессия работает замечательно!
                  0

                  Можете подсказать примеры продуктов которыми можно протестировать UX изнутри и снаружи виртуалок?

                    0
                    Можно использовать ПО VMware View Planner — www.vmware.com/go/download-viewplanner
                    Из коробки в нем уже есть набор тестов: работа в веб-браузере, с MS Office, c PDF-файлами и т.д. Также можно написать свои тесты для повышения соответствия сценариям работы ваших пользователей или для каких-то специальных приложений.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое