VDI – как рассчитать нагрузку

VDI sizingПри выборе различных инфраструктурных решений встаёт вопрос корректного подбора оборудования, ПО под оборудование в зависимости от предполагаемых нагрузок (или сайзинга, от англ. sizing). Сегодня я публикую статью стороннего автора – Василия Луковникова. Василий разработал свой инструментарий и методику сайзинга. Внизу статьи есть контакты Василия.

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

VDI Sizing

Что это?

Под VDI SIzing подразумевается как минимум две вещи:

— определение количества пользователей/сессий при помощи эмпирических соображений (например, не более 6-8-10 виртуальных машин на одно физическое ядро процессора) или VDI калькуляторов. в последнем случае предполагается, что известно среднее потребление ресурсов одной виртуальной машиной (CPU time, Memory, Disk IO, Network IO), соответственно, зная о доступных ресурсах сервера, можно прикинуть максимальное количество виртуальных машин, при котором эти ресурсы не заканчиваются.

— проведение непосредственно нагрузочного тестирования и измерение потребления ресурсов сервером, а также пользовательского user experience: как быстро он может совершать типичные действия (открытие и создание документов, создание RDP сессии и т.д.)

Сразу оговорюсь, что речь далее пойдет именно о нагрузочном тестировании.

Итак, зачем вообще нужен нагрузочное тестирование VDI?

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

— сравнение различных гипервизоров. ну тут все понятно, т.к. плотность виртуальных машин напрямую влиет на стоимость решения "per user"

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

— сравнение версий MS Office. вообщем тоже, что и в пункте выше

— сравнение железа. здесь речь идет о подборе гармоничной конфигурации с точки зрения сразу цены/производительности (плотности виртуальных машин)

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

Чем и как тестировать?

Одной из первых утилит была Microsoft Terminal Services Scalability (tbscript.exe из Windows 2003 resource kit). Представляет собой работающий через RDP интерпретатор скриптов. Сами скрипты пишутся на Visual Basic с использованием специальных функций, таких как печать слов, запуск приложений и т.д. В качестве метрики используется время работы одного цикла нагрузки. Наиболее очевидные проблемы: слишком много приседаний нужно совершить, чтобы эмулировать даже элементарную нагрузку, метрика слишком скудна, сложно написать нетривиальную и стабильно работающую нагрузку (ввиду скромного набора функция самой tbscript). Позже были выпущены Remote Desktop Load SImulation Tools (тоже от Microsoft). Это скорее framework, т.е. нагрузку и метрики предлагаетя также создать самим.

Другая утилита это VSI (Virtual Session Indexer) от голландской LoginConsultants. Это был первый широко известный VDI Sizing Benchmark, его известности способствовал сайт projectvrc.nl, содержащий результаты тестирования продуктов от MIcrosoft, VMware и Citrix. Основные фишки этой утилиты — относительная простота процесса тестирования и наглядное представление результатов (графики времен отдельных операций, в зависимости от количества запущенных сессий). Я пытался пользоваться VSI, но возникло несколько проблем: неправильное измерение времени в виртуальных машинах (позже исправлено, но только в платной версии), зависание тестов при большой нагрузки, ну и отсутствие некоторых фич (например возможности изменить интервал и интенсивность нагрузки). В итоге пришлось писать свою утилиту.

Итак, VDI Sizing Tool (www.vdi-sizing.com). В ней я постарался избавиться от недостатков VSI, а именно:

— тес
стабилен даже при очень высокой нагрузке

— деплой максимально упрощен, нет необходимости в сетевой шаре и настроенном active directory (по сравнению с VSI)

— есть возможность варьировать интенсивность нагрузки и время между запуском сессий (что важно для стресс тестов)

— время измеряется корректно

— множество метрик (включая время установления RDP соединения, длительность цикла нагрузки, запуска приложений и т.д.)

Вообщем-то об устройстве утилиты и ее использовании можно почитать на vdi-sizing.com Если появятся вопросы, пожелания и предложения — буду рад ответить, пишите на vdi.sizing@gmail.com

Tagged with: , ,
Опубликовано в Enterprise IT

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

%d такие блоггеры, как: