Правильный расчет для VDI (часть 2)

    Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании. Первый пост здесь.

    Немного математики

    Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

    Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

    Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.

    Процессоры

    Посчитаем количество необходимых процессоров.

    Серверы заказчика на 6-ядерных процессорах Intel Xeon, 2 шт на сервер, т.е. 2 x 6 x 7 = 84 пользователя на 1 ESX-сервер с 2-мя процессорами. Кроме этого, архитектура Nehalem и Westmere очень эффективно позволяет задействовать Hyper Threading и получить на 50-80% больше клиентов. Т.е. на практике где-то: 1,52 * 84 = 126-128 пользователей.

    Еслу Hyper Threading не может быть использован или дает прирост меньше 50%, или если необходимо сделать просчет с запасом, то рекомендуемое правило: использовать 75% пользователей на сервер от показателя с hyper threading (т.е. в нашем случае: 128 * 75% = 96 пользователей на сервер), но в текущем расчете все показатели были проверены на практике и совпали с расчетными.

    Число серверов для первого этапа (700 пользователей) — 6 серверов, с учетом дальнейшего расширения — 8 серверов.

    Оперативная память

    Объем памяти напрямую зависит от используемой версии ОС Windows, и от того какие приложения будут запускаться. Требования по каждому приложению всегда можно посмотреть на сайте производителя ОС и программного обеспечения.

    Например, с Windows XP (это наш случай) для базовых операций требуется 400-500 МБ, с кэшированием — не более 700 МБ. Система в обычных условиях начинает использовать файл подкачки, когда остается менее 25% свободного места в оперативной памяти. ОС всегда старается сохранить как минимум 25% свободного места в резерве. Но использование файлов подкачки в виртуальной среде приведет к потере производительности, поэтому вместо создания файла подкачки с объемом в 1,5-2 от оперативной памяти жестко зафиксируем: не более 200-500 МБ на файл подкачки, если это недостаточно, то клиенту необходимо добавить больше оперативной памяти.

    Помимо этого, примерно половина всей используемой памяти содержит похожие блоки на всех клиентах (DLL, схожие блоки приложений и пр.). vSphere Memory Management делит всю память на страницы по 4 КБ, а служба TPS сканирует все блоки данных каждые 60 минут и вычисляет хэш. Ядро сохраняет хэш в таблицу и сравнивает с уже записанными ранее значениями, оставляя только одну копию из двух идентичных, высвобождая таким образом свободное пространство. Если необходимо внести изменения в эту страницу, то создается ее копия для записи. Процент RAM, который высвобождается c использованием TPS — относительный показатель, зависящий от многих факторов и может достигать 35%-50%. На Windows 7 этот показатель ниже из-за использования ASLR (Address Space Load Randomisation), но его также можно отключить.

    Для запуска Windows XP на ESX-сервере нам необходимо:

    1. Если будет занято 60% памяти и половина ее будет разделяться между другими виртуальными машинами (Transparent Page Sharing), то нам нужно 1 ГБ * 60% * 50% = 300 МБ. Плюс, каждая виртуальная машина требует немного оперативной памяти сама по себе – около 5% от общего объема памяти сервера, те около 50 МБ на клиента. Итого 350 МБ. Хост сам по себе требует 4 ГБ RAM. Итого: 4 ГБ (хост) + 350 МБ * 128 (число виртуальных машин на сервер) = 48 ГБ RAM на сервер.
    2. Если занято 75% оперативной памяти и только треть будет разделяться, то каждому клиенту необходимо 1 ГБ * 75% * 67% = 512 МБ. Итого: 4 ГБ (хост) + (512МБ + 50 МБ) *128 = 75 ГБ RAM на сервер.
    3. Если хост вобще не поддерживает разделение страниц, то нам необходимо: 4 ГБ (хост) + (1024 МБ +50 МБ)* 128 = 139 ГБ RAM.
    4. Для клиентов Windows 7 цифры следующие: (2 ГБ + 102МБ) * 50% * 60% = 645МБ на клиент. Итого: 4ГБ + 660МБ *128 = 81 ГБ. Если хост не поддерживает transparent page sharing, то необходимо: 4ГБ + (2ГБ + 102МБ) * 128 = 275 ГБ.

    К счастью, в нашем случае Transparent Page Sharing функционировал, гостевой системой была выбрана Windows XP, поэтому расчет делался по «худшему» сценарию из возможных для этого случая — пункт 2, т.е 75 ГБ RAM на сервер.

    Диски

    Показатель IOPS очень сильно зависит от версии ОС и от тех приложений, которые будут использоваться. Для ОС Windows XP примерный показатель — 8 IOPS на саму систему, для Windows 7 — 10 IOPS на систему. Исходя из этого, на 128 виртуальных машин Windows XP (8 IOPS) необходимо 1024 IOPS в режиме чтение/запись 20/80, т.е. 205 IOPS на чтение и 819 IOPS на запись. Т.е получаем количество дисков в RAID1: 205 / 160 IOPS + 819 / 80 IOPS (см. предыдущий пост, часть по RAID) = 14 дисков, неважно стоят ли они на хосте или на общем хранилище.

    В RAID5: 205 / 160 + 819 / 45 = 21 диск.

    Исходя из замеров на дисковую подсистему: на каждого обычного пользователя необходимо 20 IOPS дисковой производительности, таким образом: 20 IOPS * 1000 пользователей = 20000 IOPS. Из них 20% на чтение (4000 IOPS) и 80% на запись (16000 IOPS). Рассчитаем число дисков в RAID1: 4000 / 160 + 16000 / 80 = 226 дисков. Если пользователи отличаются по приложениям, то расчет берется по каждой группе пользователей.

    Если необходимо посчитать число дисков в RAID5: 4000 / 160 + 16000 / 45 = 381 диск.

    В требованиях нашего заказчика были указаны обычные пользователи (email, интернет, таблицы, текстовые документы).

    Так как текущее хранилище (HP EVA) могло быть расширено до требуемых 226 дисков, то необходимости в замене хранилища не было.

    Для получения показателей производительности VDI профилей в рамках массива используется команда vscsiStats. C помощью нее подсчитываются: IO size, seek distance, Outstanding IOs, Latency.



    У vmWare есть документ, в котором указаны показатели и команды для запуска статистики.



    После подсчетов в теории необходимо проверить этой командой правильно ли отрабатывает тестовая конфигурация, и если необходимо — внести корректировки в конфигурацию.

    Подведем итог в виде таблицы по VDI:
    Значение
    Windows XP
    Windows 7
    Число VDI клиентов на ядро CPU 6-9 6-9
    Эффективность Hyper-threading 150-180% 150-180%
    ЭRAM на VDI клиента 1 ГБ 1 ГБ
    Используемая RAM минимум: 37.5%
    средняя: 50%
    без TPS: 100%
    минимум: 20%
    средняя: 50%
    без TPS: 100%
    IOPS на VDI-клиента light user: 4-6
    medium user: 8-10
    heavy user: 12-16
    light user: 6-8
    medium user: 10-12
    heavy user: 14-20

    Показатели количества VDI-клиентов на 1 физический диск и числа дисков, необходимых для работы 128 пользователей:
    Сценарий со 128 пользователями
    20 IOPS
    R/W
    20/80%
    20 IOPS
    R/W
    50/50%
    10 IOPS
    R/W
    20/80%
    10 IOPS
    R/W
    50/50%
    VDI-клиентов на диск RAID5: 3
    RAID1: 4
    RAID5: 3
    RAID1: 5
    RAID5: 6
    RAID1: 8
    RAID5: 7
    RAID1: 10
    Число дисков на хост RAID5: 50
    RAID1: 34
    RAID5: 36
    RAID1: 26
    RAID5: 24
    RAID1: 16
    RAID5: 18
    RAID1: 12

    Таким образом, вот ряд шагов, которые могут повысить производительность VDI:

    • Отключить Memory Ballooning — для VDI файл подкачки не приносит пользы, стараться выставлять жесткие значения, при необходимости — увеличивать RAM, не файл подкачки.
    • Использовать single vCPU VMs — большинство приложений пользователей однопоточные, им не нужны multi vCPU.
    • Timed Boots — разделить группы пользователей по группам, запускать группы по приоритету.
    • Оптимизировать антивирусное сканирование. Антивирусное ПО — «необходимое зло» в IT, но если ПО не настроено грамотно, то это приведет к резкому снижению производительности. Полезно будет выставить сканирование по записи, сканирование только локальных дисков и исключить Pagefile.sys и папку Print Spool.
    • Отключить 3D Screen Savers в профилях пользователей – эти заставки потребляют очень много ресурсов CPU.
    • Использовать физические контроллеры доменов — да, можно запустить DC в виртуальной среде, но Microsoft все еще рекомендует использовать DC в виде физической машины.
    • NIC Teaming (Aggregation) — NICs должны быть объединены для большей пропускной способности.
    • Виртуализация приложений — приложения должны быть виртуализованы также, как и ОС. Это упрощает поддержку и сжимает размер «золотых образов». Такие образы легче разворачивать и обновлять.
    • Правильно рассчитывать пропускную способность сети — раньше расчет делался, исходя из показателя 20 КБ/с на пользователя, но это не отвечает текущему положению вещей. Актуальным значением сейчас будет около 100 КБ/с на пользователя.
    • Грамотно рассчитывать производительность системы хранения — выбор типа дисков и уровня RAID определяет как хорошо ваша система хранения выполняет работу в VDI-окружении. Опыт показывает, что RAID 10 – это разумный выбор для VDI из-за высокой производительности. А SSD и Flash-память серьезно уменьшают время загрузки, но имеют большую стоимость (правда, цена такого решения неуклонно падает).

    Интересное чтение:

    Hewlett Packard Enterprise
    Компания

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

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Спасибо!
          0
          весьма познавательная статья. спасибо :)
          0
          У неё меньше накладные расходы, по этой же причине рекомендуют использовать 32-битную систему. Windows 8 сильно оптимизировали в эту сторону, но врядли её будут активно использовать до окончания поддержки XP.
          0
          Интересен был бы опыт виртуализации с пробросом и совместным использованием видеоадаптера для тяжелых однопоточных приложений и к тому же с кучей внутренних багов (непроизвольные падения, повреждение файлов, утечка памяти, нелинейное уменьшение скорости при росте документов), например AutoCAD (в том числе 3D) на 256 человек. :)
            0
            GPU passtrough. Но для каждой VM потребуется своя физическая графическая карта.
              0
              Не для каждой, есть Citrix Xen там проброс и разделение ресурсов GPU возможно. Но получилось запустить сколько-нибудь масштабное тестирование.
                0
                *Не получилось
                  0
                  На хабре уже писали о пробном проекте проброса видеокарты habrahabr.ru/post/149416/
                  Пока такие решения не сильно востребованы заказчиком, в силу их нетривиальности.
                  Поэтому и больших тестов у нас не проводилось. Но это пока.
                    0
                    Вопрос не столько в пробросе (хотя бы один из игроков VM рынка обеспечивает и ладно), сколько в разделении ресурсов при высокой нагрузке. Нагрузка на CPU и GPU идет не равномерно, память имеет свойство «протекать», любые погрешности в работе системы будут списываться на виртуализацию, а не на приложение. Сложностей много, но перспектив не меньше — 1 рабочее место стоит около 2000$ долларов, при использовании Quadro и того выше.
                    Честно говоря смущает еще один момент, практически все клиенты представляют собой микро-компьютеры, когда реально нужен лишь аппаратный декодер и быстрый кеш для хранения промежуточного результата = DSP + DDR + Bluetooth для клавиатууры и мыши. Как-то проскакивала новость о мониторе-терминале который подключался по PoE, вот это идеальный вариант. Возможно я что-то упускаю и существуют сложности другого характера?
                      0
                      Все так: ARM-процессор с поддержкой PCoIP + DDR3 + Flash для хранения образов.
                      Может быть, имелся в виду такой продукт: HP t410 All-in-One SMART ZERO CLIENT (http://h18004.www1.hp.com/products/quickspecs/14267_div/14267_div.PDF) у него, правда, через PoE максимум 100Mbps и без Bluetooth. Процессор: Texas Instruments DM8148 processor: (1-GHz ARM® Cortex™-A8 RISC MPU,
                      TMS320C674x Floating-Point Digital Signal Processor (DSP), 256 KB L2 Unified Mapped RAM/Caches, HD Video Processing Subsystem (HDVPSS)) используются оба ядра ARM и DSP с протоколом PCoIP от Teradici, вот свежий релиз: www.teradici.com/news-and-events/press-releases/2012-08-20.
                      Может использоваться в виде PoE клиента, потребляющего только 13W или как традиционный клиент.
                        0
                        Это называется «нулевой клиент» (zero client), у Fujitsu есть такой:
                        www.fujitsu.com/ru/products/computing/pc/zero-clients/advanced/DZ22-2/index.html
                          0
                          Всегда считал что Zero Client это коробка без OS. Да примерно такой был в новостях, как-то не задумывался что это и есть интегрированный Zero Client. Непонятно правда что внутри, у HP все расписано.
                            0
                            Да, в первую очередь это коробка без ОС:
                            A newer trend is sometimes called an ultra-thin client or a zero client, which no longer runs a full operating system: the kernel instead merely initializes the network, begins the networking protocol, and handles display of the server's output.

                            Вот, например, zero-client в коробочном исполнении без монитора:
                            h18004.www1.hp.com/products/quickspecs/14424_div/14424_div.PDF
                              0
                              Zero Client — это однозадачное устройство (в данном случае, клиент для RDP, PCoIP и HDX), Thin Client — устройство с урезанной ОС, которое умеет выполнять несколько задач.
                            0
                            Сэкономить на VDI врядли получится (видеокарта в сервер может стоит $20к и больше), там другие преимущества: быстрота развёртывания рабочих мест, безопасность и возможность доступа с различных устройств.
                    0
                    Вам нужна Nvidia VGX, она поддерживается в VMware View. Правда 256 пользователей CAD/CAM на одном сервере врядли потянет.
                      0
                      Насколько мне известно VGX еще официально не вышла. Решение интересное, жаль цены и реальная производительность не известны. Судя по характеристикам это что-то наподобие двух Tesla K10 или Tesla K20, исходя из этой оценки цена будет в районе $5000-$7000. На одном сервере 256 пользователей и не нужно, к тому же это оценка с запасом, реально работают в CAD процентов 80, остальные пользуются не так часто и требования к ним ниже. Кстати не совсем понял концепцию NVidia USM — это просто заранее заданные профили распределения/потребления ресурсов по типу пользователей или различные аппаратные решения? Если условно взять HP DL380p или HP BL460c (если туда влезет VGX) это в 2-процессорной конфигурации около $10K + VGX $10K + доп. расходы 25% = $25K за сервер. Дополнительно на 256 пользователей х (Терминальный клиент $200 + Лицензия $200 ) = $100K. При расчете 32 пользователя на сервер нужно 8 серверов, итого $300K или примерно $1200 на пользователя. Сейчас также стоит нормальный PC. При таком необходимом количестве единоразовых инвестиций профит по безопасности, расширяемости, поддержке и прочему сложно показать. Скорее всего для комфортной работе нужно 16 пользователей на сервер (1 ядро, 4 Гб памяти, 1 Гб видеопамяти, 1/4 видеоядра на каждого), но даже это без реального теста очень приблизительный расчет.
                        0
                        Можно ещё посмотреть на карты от AMD, они совсем дешевые.
                    0
                    А какие поправки при сайзинге стоит сделать при расчете мощности для тонких клиентов без использования виртуализации?
                    Только потребности в ОЗУ по другому считать придется?
                      0
                      Если подразумевается подключение по RDP, то расчет следующий. При выборе процессора для сервера RDP упор делается на модель с большим количеством кэша. При расчете памяти — она должна быть добавлена с избытком, лучше высокоскоростная с коррекцией ошибок. Объем памяти зависит от приложений, которые будут запускаться, от числа одновременных подключений. На саму ОС около 8GB, на каждую RDP сессию — 4.5MB RAM, Microsoft RDP Client software требует минимум 6MB RAM.
                      Также Windows thin client требует наличия flash memory (50KB на клиента).
                      Если этот клиент загружается с ROM, то этому клиенту необходимо еще от 4MB ROM.
                      У Microsoft есть документ по системным требованиям: msdn.microsoft.com/en-us/library/ms927515.aspx
                      0
                      Вы написали, что использовался пул виртуальных машин. По этому поводу несколько вопросов:
                      — использовались ли дифференциальные диски?
                      — если использовался пул, то скорее всего использовался и откат изменений после логофа — как решили вопрос с установкой обновлений?

                      Спасибо.
                        0
                        Добрый день! Прошу прощения за поздний ответ — был в отпуске.
                        1. Дифференциальные диски на данный момент не предполагалось использовать, заказчик планировал использовать Steady State.
                        2. Если про обновление образов виртуальных машин — то используется VMware Update Manager.
                        Спасибо.
                          0
                          Если про обновление образов виртуальных машин — то используется VMware Update Manager.

                          Вы имеете ввиду vCenter Protect? Ведь VUM разучился обновлять винду в пятой версии.
                            0
                            Да, прошу прощения за ошибку.
                        0
                        При отключенном ASLR не запускается IE10 на Windows 7.

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

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