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

    Представляю вам серию из двух постов, где я постараюсь рассказать о разработке довольно типового решения VDI для предприятия среднего размера. В первой части – подготовка к внедрению, планирование; во второй – реальные практически примеры.

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

    Например, у одного из заказчиков, крупной отечественной софтверной компании, имеется довольно большой парк серверов и систем хранения. В том числе — несколько серверов HP ProLiant 6-го и 7-го поколения и система хранения HP EVA, которые были в резерве. Именно на их базе нужно было разработать решение.
    Озвученными требованиями к решению VDI были:

    • Floating Desktops Pool (с сохранением изменений после окончания сессии);
    • Начальная конфигурация — 700 пользователей, с расширением до 1000.

    Мне предстояло просчитать какое количество серверов и систем хранения в итоге перейдут из резерва в состав решения.
    В качестве среды виртуализации выбрана VMware. Схема работы получилась примерно такая:

    Один из серверов выступает как connection broker, к нему подключаются клиенты. Connection broker выбирает из пула физических серверов на каком запустить виртуальную машину для обслуживания сессии.

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



    Под ESX-гипервизоры были отведены довольно мощные серверы с 6-ядерными процессорами Intel Xeon. При первом взгляде «слабым звеном» выступает система хранения данных, ведь для VDI скрытый убийца — это IOPS. Но конечно, при разработке VDI-решения нужно учесть еще много других моментов. Расскажу здесь о части из них:

    1. О чем необходимо помнить — весомую часть стоимости решения будут составлять лицензии на ПО. Чаще всего, выгоднее рассматривать предложения от хардверных вендоров, т.к. стоимость OEM-лицензий на ПО для виртуализации меньше.
    2. Во-вторых, стоит рассмотреть возможность установки карт графических ускорителей для работы большого количества пользователей с мультимедиа или в графических редакторах.
    3. Интересным решением у HP является блейд-сервер рабочих станций HP ProLiant WS460c Gen8. Его отличительная особенность: возможность установки графических карт прямо в блейд, не теряя пространство для 2-х жестких дисков, 2-х процессоров и 16 планок памяти. Графические ускорители поддерживают до 240 ядер CUDA, 2.0 ГБ памяти GDDR5 (интересное чтение здесь).
    4. В-третьих, необходимо просчитать заранее совокупную стоимость владения (она же TCO). Покупка оборудования — это, безусловно, большая трата, но можно и нужно показать экономию от внедрения решения, стоимость обновления и ремонта, а также стоимость продления лицензий на ПО.

    И наконец, перейдем к I/O и основным связанным с вводом/выводом проблемам.

    Windows, запущенная на локальном ПК с жестким диском, располагает примерно 40-50 IOPS’ами. Когда на таком ПК вместе с базовой ОС загружается набор сервисов – prefetching, сервисы индексации, сервисы аппаратной части и т.д. – часто это ненужный пользователю функционал, но он не несет больших потерь в производительности.

    Но когда используется клиент VDI, почти все дополнительные сервисы контрпродуктивны — они производят большое количество запросов ввода/вывода в попытке оптимизировать скорость и время загрузки, но эффект получает обратным.

    Также, Windows старается оптимизировать блоки данных таким образом, чтобы обращение к ним было по большей части последовательным, т.к. на локальном жестком диске для последовательного чтения и записи необходимо меньше перемещений головки жесткого диска. Для VDI этому нужно уделить особое внимание – см. в конце поста.

    Число IOPS, которые требует клиент в большей степени зависит от сервисов, которые ему необходимы. В среднем, эта цифра составляет 10-20 IOPS (замерить величину IOPS, которая необходима в каждом конкретном случае, можно с помощью механизмов, которые предоставляет, например, Liquidware Labs). Большая часть IOPS — это операции на запись. В среднем в виртуальной инфраструктуре соотношение операций на чтение/запись может достигать 20/80.

    Что все это значит в деталях:

    1. Проблема boot/logon storms – кэш и политики, политики и кэш

    В тот момент, когда пользователь обращается к своей виртуальной машине для входа создается большая нагрузка на дисковую подсистему. Наша задача – сделать эту нагрузку прогнозируемой, то есть свести большую ее часть к операциям чтения, а потом эффективно использовать выделенный кэш для типовых считываемых данных.

    Чтобы достичь этого, необходимо оптимизирозать не только образ виртуальной машины клиента, но и профили пользователей. Когда это настроено правильно, нагрузка на IOPS становится вполне прогнозируемой величиной. В хорошо отлаженной виртуальной инфраструктуре соотношение чтение/запись на момент загрузки будет составлять 90/10 или даже 95/5.

    Но если мы имеем дело с одновременным началом работы сразу большого количества пользователей, то система хранения данных должна быть довольно большой, иначе процесс входа в систему для некоторых пользователей может затянуться на несколько часов. Единственный выход: правильно рассчитать объем системы, зная максимальное число одновременных подключений.

    Например, если образ загружается 30 секунд, и если в пиковое время число одновременных подключений пользователей — 10% от их общего числа, то это создает двухкратную нагрузку на запись и десятикратную нагрузку на чтение, что составляет 36% от нормальной загрузки хранилища. Если число одновременных подключений — 3%, то нагрузка на систему хранения возрастает только на 11% по сравнению с обычной загрузкой. Даем совет заказчику — поощряйте опоздания на работу! (шутка)
    Но не нужно забывать, что пропорции «чтение/запись» после фазы загрузки меняются диаметрально: IOPS на чтение падает до 5 IOPS на сессию, но число IOPS на запись не уменьшается. Если об этом забыть, это привет к серьезным проблемам.

    2. OPS систем хранения – выбираем правильный RAID

    Когда запросы от пользователей приходят в общую систему хранения (SAN, iSCSI, SAS), то все операции ввода/вывода с точки зрения хранилища — на 100% случайные. Производительность диска со скоростью вращения 15 000 RPM составляет 150-180 IOPS, в системе хранения SAS/SATA диски в RAID-группе (относящиеся к ATA, т.е. все диски в RAID ждут синхронизации) дадут на 30% меньше производительности, чем IOPS одного SAS/SATA диска. Пропорции такие:

    • В RAID5: 30-45 IOPS с диска на запись, 160 IOPS на чтение;
    • В RAID1: 70-80 IOPS с диска на запись, 160 IOPS на чтение;
    • В RAID0 140-150 IOPS с диска на запись, 160 IOPS на чтение.

    Поэтому для виртуализации рекомендуется применять RAID с большей производительностью на запись (RAID1, RAID0).

    3. Расположение на диске – выравнивание важнее всего

    Т.к. мы хотим минимизировать операции ввода/вывода от системы хранения — наша главная задача, чтобы каждая операция была наиболее эффективной. Расположение на диске — это один из главных факторов. Каждый байт, запрошенный у системы хранения не читается отдельно от других. В зависимости от вендора, данные в системе хранения раделяются на блоки 32 KB, 64 KB, 128 KB. Если файловая система поверх этих блоков не «выровнена» относительно этих блоков, то запрос 1 IOPS со стороны файловой системы даст запрос 2 IOPS со стороны системы хранения. Если же эта система сидит на виртуальном диске, а этот диск на файловой системе, которая не выровнена, то запрос 1 IOPS операционной системой в этом случае приведет к запросу 3 IOPS со стороны файловой системы. Это показывает, что выравнивание по всем уровням имеет первостепенное значение.


    К сожалению, Windows XP и Windows 2003 создают сигнатуру на первой части диска в процессе установки операционной системы и начинают запись на последних секторах первого блока, это полностью сдвигает файловую систему ОС относительно блоков системы хранения. Чтобы это исправить необходимо создавать разделы, презентованные хосту или виртуальной машине с помощью утилит diskpart или fdisk. И назначать старт записи с сектора 128. Сектор — 512 байт и мы ставим начало записи точно на 64KB маркер. Как только раздел выровнен мы получим 1 IOPS от системы хранения на запрос от файловой системы.



    То же самое и для VMFS. Когда раздел создается через ESX Service Console, он не будет по умолчанию совпадать с системой хранения. В этом случае необходимо использовать fdisk или создавать раздел через VMware vCenter, который выполняет выравнивание автоматически. Windows Vista, Windows 7, Windows Server 2008 и более поздние продукты по умолчанию пытаются выровнять раздел на 1 MB, но лучше проверять выравнивание самостоятельно.

    Увеличение производительности от выравнивания может составлять около 5% для больших файлов и 30-50% для маленьких файлов и random IOPS. И поскольку для VDI в больше степени характерна нагрузка random IOPS, то выравнивание имеет огромное значение.

    4. Дефрагментация и prefetching должны быть отключены

    Файловая система NTFS состоит из блоков по 4KB. К счастью, система Windows старается расположить блоки так, чтобы обращение было максимально последовательным. Когда пользователь запускает приложения, запросы в большей степени идут на запись, а не на чтение. Процесс дефрагментации же пытается угадать как данные будут читаться. Дефрагментация, в этом случае, генерирует нагрузку на IO не давая существенного положительно эффекта. Поэтому рекомендуется отключать процесс дефрагментации для решений VDI.

    То же самое для процесса prefetching. Prefetching – это процесс, который помещает файлы, к которым идет больше всего обращений, в специальную кэш-директорию Windows так, чтобы чтение этих файлов было последовательным, минимизируя таким образом IOPS. Но поскольку запросы от большого числа пользователей делают IOPS совершенно случайными с точки зрения хранилища, то процесс prefetching не дает преимуществ, происходит только генерация трафика ввода/вывода «впустую». Выход — функция prefetching должна быть полностью отключена.

    Если система хранения использует дедупликацию, то это еще один довод в пользу отключения функций prefetching и дефрагментации — процесс prefetching, перемещая файлы с одного диска на другой, серьезно снижает эффективность процесса дедупликации, для которого критично хранить таблицу редко изменяемых блоков данных диска.
    Hewlett Packard Enterprise
    Компания

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

      0
      хорошая тема, полезная. и руководство подробное. не знаю, правда, насколько интересная Хабралюдям.
        0
        Интересно, единсвенное всегда возникает вопрос сколько стоит, чтобы сравнивать!
          0
          может, во второй части какой-то ориентир дадут?
            0
            Будет ориентир, который актуален для данного заказчика и проекта.
            Для каждого задания — свой сайзинг, но во второй части можно будет посмотреть как делается расчет.
              0
              Вот именно расчет и интересен, ибо без этого не понятно, нужно ли вооще заморачиваться предприятию и когда стоит об этом начинать думать!
            +1
            Стоит чуть дешевле полностью укомплектованного корпоративного компьютера, но окупается только на больших инсталяциях (от нескольких тысяч десктопов) из-за высоких требований к серверной инфраструктуре.
            0
            Какие тонкие клиенты будут использоваться?
              0
              Хороший вопрос, при десятке моделей тонких/нулевых клиентов HP, поддержка PCoIP реализована лишь в ещё не вышедшем T410.
                0
                VMware View over PCoIP реализована в моделях t310, t410, t510, t5565, t5565z, t5570, t5740, t5740e, t610.
                Мои коллеги из отдела персональных компьютерах рассчитывали клиентскую часть на одном из самых доступных в России t510 h18004.www1.hp.com/products/quickspecs/14256_div/14256_div.PDF
                Про t410 не слышал, что он недоступен.
                  0
                  Тогда вам стоит навести порядок в описаниях на сайте, так как в технических характеристиках он указан далеко не для всех перечисленных моделей.
                    0
                    Да, это, к сожалению, актуальный вопрос, спасибо за замечание, исправим.
              0
              По планированию инфраструктуры для View (и вообще VDI) есть неплохая книжка:
              www.amazon.com/VMware-View-Desktop-Virtualization-Solutions/dp/1849681120/
              Там есть описанное в посте и ещё много всего интересного, читать в дополнение к стандартной доке и/или курсам.
              0
              А можете привести какой-то пример расчета когда VDI выигрывает у обычных PC Per User решений.

              По тому как сходу складывается впечатление что VDI значительно дороже из-за более сложной серверной инфраструктуры (как на этапе закупки, так и обслуживания).
                +2
                По единовременной стоимости: стоимость одного PC (из рассчета ПК + монитор с Windows XP) на 11% — $750 (Windows 7 — на 15%) дешевле, чем использование одного VDI клиента (примерно $850 на клиента). Жизненный цикл одного PC — 4 года, VDI клиента — 7 лет, серверного оборудования — 4 года, по сроку службы клиенты будут иметь почти двухкратный срок службы. Кроме этого у VDI довольно сложная политика лицензирования, надеюсь, Microsoft поменяет ее с выходом новых версий программных продуктов, у них сейчас прослеживается прямой курс на виртуализацию. Это по минусам VDI решения. По железу — ничего сложного, основная проблема: правильно рассчитать лицензии Microsoft VDA.
                В долгосрочной перспективе (8-10 лет) VDI решение становится более выгодным по совокупной стоимости владения.
                Некоторые преимущества VDI, которые были критичными для заказчика при взвешивании вариантов и поиске решения:
                — VDI предлагают встроенное решение по BIOS / Disk Encryption, т.к. PCoIP шифрует данные, передаваемые клиенту, у PC по умолчанию этот функционал отсутствует;
                — Резервное копирование проще организовывать на общей системе хранения, чем устанавливать агенты бэкапирования и выставлять окна бэкапа на отдельных персональных компьютерах;
                — доступность данных в любом месте, каждый пользователь может подключиться с любого клиента или мобильного устройства и получить доступ к своим данным;
                — монолитность среды работы легче достичь с испрользованием VDI образов, такое решение проще обновлять. Также стоимость развертывания VDI решения ниже, чем развертывание образов на всех ПК.
                Приготовьтесь к тому, что на начальном этапе вы увидите VDI решение существенно дороже, но можно рассчитать в перспективе на 10 лет и сравнить. По числу клиентов: VDI экономически эффективнее при 1000+ клиентах, до 1000 клиентов иногда бывает целесообразнее рассчитать решение на терминальном доступе. Да, это, может, не так интересно с точки зрения функционала, но лицензии RDP стоят дешевле и по стоимости решение на RDP соразмерно стоимости традиционного PC решения (около $800 ).
                Универсальной формулы, увы, нет, в этом проекте решение VDI выиграло по функционалу и по стоимости на перспективу в 10 лет.
                0
                Планируется ли выложить расчёт экономической эффективности VDI?
                  0
                  Думаю, что заказчик предоставит такую информацию после внедрения проекта.
                  0
                  А файл подкачки рекомендуете отключать в Windows 7?
                    0
                    Добрый день! Прошу прощения за поздний ответ (был в отпуске).
                    Было проведено 2 теста с запуском аналогичных машин, одна из которых была с файлом подкачки, другая нет. Во время boot storm машина без файла подкачки производит на 27% меньше операций ввода-вывода на запись (writes IO), во все остальное время работы показатели примерно одинаковые.
                    Во время простоя (IDLE time) показатели IO примерно одинаковые.
                    Во время операций логина машина с файлом подкачки производит на 20% меньше операций read IO, по сравнению с машиной без файла подкачки, но с другой стороны машине без файла подкачки потребовалось на 27% на операции вода-вывода на запись.
                    Как мы знаем операции на запись стоят дороже из-за использования RAID striping на каждую операцию записи. Если бы весь трафик состоял бы из операций логина, то я бы старался снизить нагрузку на запись у систем хранения. В нашем случае paging был отключен.

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

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