Заказчик захотел VDI. Очень присматривался к связке SimpliVity + VDI Citrix Virtual Desktop. Для всех операторов, сотрудников офисов по городам и так далее. Там пять тысяч пользователей только в первой волне миграции, и поэтому они настояли на нагрузочном тестировании. VDI может начать тормозить, может спокойно прилечь — и не всегда это случается из-за проблем с каналом. Мы купили очень мощный пакет тестирования специально для VDI и грузили инфраструктуру, пока она не легла по дискам и по процессору.
Итак, нам понадобятся пластиковая бутылка, софт LoginVSI для навороченных тестов VDI. У нас он с лицензиями на 300 юзеров. Потом взяли железо HPE SimpliVity 380 в набивке, подходящей для задачи максимальной плотности пользователей на один сервер, нарезали виртуальных машин с хорошей переподпиской, поставили на них офисный софт на Win10 и начали тестить.
Поехали!
Система
Два узла (сервера) HPE SimpliVity 380 Gen10. На каждой:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Оперативная память: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Основной дисковый контроллер: HPE Smart Array P816i-a SR Gen10.
- Жесткие диски: 9 x 1.92 TB SATA 6Gb/s SSD (в конфигурации RAID6 7+2, т. е. это модель Medium в терминах HPE SimpliVity).
- Сетевые карты: 4 x 1Gb Eth (данные пользователей), 2 x 10Gb Eth (бэкэнд SimpliVity и vMotion).
- Специальные встроенные FPGA-карты в каждом узле для дедупликации/компрессии.
Узлы подключены между собой интерконнектом 10Gb Ethernet напрямую без внешнего коммутатора, который используется как бэкэнд SimpliVity и для передачи данных виртуальных машин по NFS. Данные виртуальных машин в кластере всегда зеркалируются между двумя узлами.
Узлы объединены в кластер Vmware vSphere под управлением vCenter.
Для проведения тестирования развёрнуты контроллер домена и брокер подключений Citrix. Контроллер домена, брокер и vCenter вынесены на отдельный кластер.
В качестве тестовой инфраструктуры развёрнуты 300 виртуальных рабочих столов в конфигурации Dedicated – Full Copy, т. е. каждый рабочий стол представляет собой полную копию оригинального образа виртуальной машины и сохраняет все изменения, сделанные пользователями.
Каждая виртуальная машина имеет 2vCPU и 4GB RAM:
На виртуальные машины было установлено следующее ПО, требуемое для проведения тестирования:
- Windows 10 (64-bit), версия 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Между узлами — синхронная репликация. У каждого блока данных в кластере — две копии. То есть сейчас полный набор данных на каждом из узлов. При кластере в три и больше узлов — копии блоков в двух разных местах. При создании новой ВМ создаётся дополнительная копия на одном из узлов кластера. При выходе из строя одного узла все ВМ, ранее запущенные на нём, автоматически перезапускаются на других узлах, где у них есть реплики. Если узел вышел из строя надолго, то начинается постепенное восстановление избыточности, и кластер снова возвращается к резервированию N+1.
Балансировка и хранение данных происходят на уровне программного хранилища самого SimpliVity.
Виртуальные машины запускают кластер виртуализации, он же располагает их на программном хранилище. Сами рабочие столы брали по типовому шаблону: на тест заехали столы финансистов и операционистов (это два разных шаблона).
Тестирование
Для проведения тестирования использовался тестовый комплекс ПО LoginVSI 4.1. Комплекс LoginVSI в составе управляющего сервера и 12 машин для тестовых подключений были развёрнуты на отдельном физическом хосте.
Тестирование проводилось в трёх режимах:
Режим Benchmark — варианты нагрузки 300 Knowledge workers и 300 Storage workers.
Стандартный режим — вариант нагрузки 300 Power workers.
Для возможности работы Power workers и повышения разнообразия нагрузки в комплекс LoginVSI была добавлена библиотека дополнительных файлов Power Library. Для обеспечения повторяемости результатов все настройки тестового стенда были оставлены Default.
Тесты Knowledge и Power workers имитируют реальную нагрузку пользователей, работающих на виртуальных рабочих станциях.
Тест Storage workers создан специально для тестирования систем хранения данных, далёк от реальных нагрузок и большей частью состоит в работе пользователя с большим количеством файлов разных размеров.
В процессе тестирования пользователи заходят на рабочие станции в течение 48 минут примерно по одному пользователю каждые 10 секунд.
Результаты
Основным результатом тестирования LoginVSI является метрика VSImax, которая составляется из времени выполнения различных заданий, запускаемых пользователем. Например: время открытия файла в блокноте, время сжатия файла в 7-Zip и т. д.
Подробное описание подсчета метрик доступно в официальной документации по .
Другими словами, LoginVSI повторяет типовой шаблон нагрузки, симулируя действия пользователя в офисном пакете, при чтении PDF и так далее, и измеряет различные задержки. Есть критический уровень задержек «всё тормозит, работать невозможно»), до достижения которого считается, что максимум юзеров не набран. Если время отклика на 1 000 мс быстрее, чем это состояние «всё тормозит», то считается, что система работает нормально, и можно добавлять ещё пользователей.
Вот основные метрики:
Метрика
Производимые действия
Подробное описание
Нагружаемые компоненты
NSLD
Время открытия текстового
файла весом 1 500 Кбайт
Запускается блокнот и
открывает случайный документ весом 1 500 Кбайт, который скопирован из пула
ресурсов
CPU и I/O
NFO
Время открытия диалогового
окна в блокноте
Открытие файла VSI-Notepad [Ctrl+O]
CPU, RAM и I/O
ZHC*
Время создания Zip-файла с сильным сжатием
Сжатие локального
случайного файла в формате .pst размером 5MB, который скопирован из
пула ресурсов
CPU и I/O
ZLC*
Время создания Zip-файла со слабым сжатием
Сжатие локального
случайного файла в формате .pst размером 5MB, который скопирован из
пула ресурсов
I/O
CPU
Вычисление большого
массива случайных данных
Создание большого массива
случайных данных, которые будут использованы в таймере ввода-вывода (I/O-таймере)
CPU
При выполнении тестирования изначально подсчитывается базовая метрика VSIbase, которая показывает скорость выполнения заданий без нагрузки на систему. На ее основе определяется VSImax Threshold, который равен VSIbase + 1 000мс.
Выводы о производительности системы делаются на основе двух метрик: VSIbase, определяющей скорость работы системы, и VSImax threshold, определяющей максимальное количество пользователей, которое выдержит система без существенной деградации.
300 Knowledge workers benchmark
Knowledge workers — это юзеры, которые регулярно нагружают память, процессор и IO разными мелкими пиками. Софт эмулирует нагрузку с требовательных офисных пользователей, как будто они постоянно что-то тыкают (PDF, Java, офисный пакет, просмотр фото, 7-Zip). По мере добавления пользователей с нуля до 300 задержка у каждого плавно растёт.
Данные статистики VSImax:
VSIbase = 986мс, VSI Threshold достигнут не был.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
При данном типе нагрузки система выдерживает повышение нагрузки практически без деградации производительности. Время выполнения заданий пользователей растёт плавно, время отклика системы не изменяется в течение тестирования и составляет до 3 мс на запись и до 1 мс — на чтение.
Вывод: 300 knowledge юзеров без каких-либо проблем работают на текущем кластере и не мешают друг другу, достигая переподписки pCPU/vCPU 1 к 6. Общие задержки при возрастании нагрузки равномерно растут, но обсусловленный предел достигнут не был.
300 Storage workers benchmark
Это пользователи, которые постоянно пишут и читают в пропорции 30 к 70 соответственно. Этот тест был проведён скорее ради эксперимента. Данные статистики VSImax:
VSIbase = 1673, VSI Threshold достигнут на 240 пользователях.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
Такой тип нагрузки, по сути, — стресс-тест системы хранения. При его выполнении каждый пользователь записывает на диск множество случайных файлов разных размеров. В этом случае видно, что при превышении некоторого порога нагрузки у части пользователей повышается время выполнения задач на запись файлов. При этом нагрузка на систему хранения, процессор и память хостов существенно не изменяется, поэтому точно определить, с чем связаны задержки, на данный момент нельзя.
Выводы о производительности системы с помощью этого теста можно делать только в сравнении с результатами теста на других системах, так как такие нагрузки — синтетические, нереалистичные. Тем не менее, в целом тест прошёл неплохо. До 210 сессий всё шло хорошо, а затем начались непонятные отклики, которые при этом нигде, кроме Login VSI, не отслеживались.
300 Power workers
Это пользователи, которые любят процессор, память и высокие IO. Эти «продвинутые пользователи» регулярно запускают сложные задачи с долгими пиками вроде установки нового ПО и распаковки больших архивов. Данные статистики VSImax:
VSIbase = 970, VSI Threshold достигнут не был.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
При тестировании был достигнут порог нагрузки процессоров на одном из узлов системы, но это не оказало существенного влияния на её работу:
В этом случае система выдерживает повышение нагрузки также без существенной деградации производительности. Время выполнения заданий пользователей растёт плавно, время отклика системы не изменяется в течение тестирования и составляет до 3 мс на запись и до 1 мс — на чтение.
Обычных тестов заказчику было недостаточно, и мы пошли дальше: повысили характеристики ВМ (количество vCPU, чтобы оценить повышение переподписки и размер диска) и добавили допнагрузку.
При проведении дополнительных тестов была использована следующая конфигурация стенда:
Развёрнуто 300 виртуальных рабочих столов в конфигурации 4vCPU, 4GB RAM, 80GB HDD.
Конфигурация одной из тестовых машин:
Машины развёрнуты в варианте Dedicated – Full Copy:
300 Knowledge workers benchmark с переподпиской 12
Данные статистики VSImax:
VSIbase = 921 мс, VSI Threshold достигнут не был.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
Полученные результаты аналогичны тестированию предыдущей конфигурации ВМ.
300 Power workers с переподпиской 12
Данные статистики VSImax:
VSIbase = 933, VSI Threshold достигнут не был.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
При данном тестировании также был достигнут порог нагрузки процессоров, но это не оказало существенного влияния на производительность:
Полученные результаты аналогичны тестированию предыдущей конфигурации.
Что будет, если запустить нагрузку на 10 часов?
Теперь смотрим, будет ли «эффект накопления», и пускаем тесты на 10 часов подряд.
Длительные тесты и описание раздела должны быть нацелены на то, что мы хотели проверить, будут ли возникать какие-то проблемы с фермой при длительной нагрузке на неё.
300 Knowledge workers benchmark + 10 hours
Дополнительно было проведено тестирование варианта нагрузки 300 knowledge workers с последующей работой пользователей в течение 10 часов.
Данные статистики VSImax:
VSIbase = 919 мс, VSI Threshold достигнут не был.
Данные статистики VSImax Detailed:
По графику видно, что в течение всего теста не наблюдается какой-либо деградации производительности.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
Производительность системы хранения остаётся на одном уровне на протяжении всего теста.
Дополнительное тестирование с добавлением синтетической нагрузки
Заказчик попросил добавить дикой нагрузки на диск. Для этого на систему хранения в каждую из виртуальных машин пользователей было добавлено задание на запуск синтетической нагрузки на диск при входе пользователя в систему. Нагрузка обеспечивалась утилитой fio, позволяющей ограничивать нагрузку на диск по количеству IOPS. В каждой машине запускалось задание на запуск дополнительной нагрузки в количестве 22 IOPS 70 %/30 % Random Read/Write.
300 Knowledge workers benchmark + 22 IOPS per user
При первоначальном тестировании было обнаружено, что fio создаёт значительную дополнительную нагрузку на процессор виртуальных машин. Это привело к быстрой перегрузке хостов по CPU и сильно повлияло на работу системы в целом.
Нагрузка на CPU хостов:
Задержки системы хранения при этом также закономерно увеличились:
Недостаток вычислительной мощности стал критичным примерно к 240 пользователям:
Вследствие полученных результатов было решено провести тестирование, менее нагружающее CPU.
230 Office workers benchmark + 22 IOPS per user
Для снижения нагрузки на CPU был выбран тип нагрузки Office workers, на каждую сессию также было добавлено по 22 IOPS синтетической нагрузки.
Тест был ограничен 230 сессиями для того, чтобы не превысить максимальную нагрузку на CPU.
Тест был запущен с последующей работой пользователей в течение 10 часов для проверки стабильности системы при длительной работе на нагрузке, близкой к максимальной.
Данные статистики VSImax:
VSIbase = 918 мс, VSI Threshold достигнут не был.
Данные статистики VSImax Detailed:
По графику видно, что в течение всего теста не наблюдается какой-либо деградации производительности.
Данные статистики по нагрузке на CPU:
При выполнении данного теста нагрузка на CPU хостов была практически максимальной.
Статистика нагрузки на систему хранения из мониторинга SimpliVity:
Производительность системы хранения остаётся на одном уровне на протяжении всего теста.
Нагрузка на систему хранения в течение теста составила примерно 6 500 IOPS в соотношении 60/40 (3 900 IOPS — на чтение, 2 600 IOPS — на запись), что составляет примерно 28 IOPS на одну рабочую станцию.
Время отклика в среднем составляло 3 мс на запись и до 1 мс — на чтение.
Итог
При моделировании реальных нагрузок на инфраструктуру HPE SimpliVity были получены результаты, подтверждающие способность системы обеспечивать работу виртуальных рабочих столов в количестве не менее 300 Full Clone-машин на паре узлов SimpliVity. При этом время отклика системы хранения сохранялось на оптимальном уровне на протяжении всего тестирования.
Нам очень импонирует подход про длительные тесты и сравнение решений до внедрения. Мы можем протестировать производительность и для ваших нагрузок, если хотите. В том числе на других гиперконвергентных решениях. Упомянутый заказчик сейчас заканчивает тесты на другом решении в параллель. Его текущая инфраструктура — просто парк ПК, домен и софт на каждом рабочем месте. Переезжать на VDI без тестов, конечно, довольно сложно. Конкретно сложно понимать реальные возможности фермы VDI, не смигрировав на неё реальных пользователей. А эти тесты позволяют быстро оценить реальные возможности той или иной системы без необходимости привлечения обычных пользователей. Отсюда и возникло такое исследование.
Второй важный подход — заказчик сразу заложился на правильное масштабирование. Тут можно докупать сервер и добавлять ферму, например, на 100 пользователей, всё предсказуемо по цене пользователя. Например, когда им понадобится добавить ещё 300 пользователей, они будут знать, что нужны два сервера в уже определённой конфигурации, а не пересматривать возможности модернизации своей инфраструктуры в целом.
Интересны возможности федерации HPE SimpliVity. Бизнес — географически разделённый, поэтому в дальний офис имеет смысл ставить свою отдельную VDI-железку. В федерации SimpliVity каждая виртуалка реплицируется по расписанию с возможностью делать между географически удалёнными кластерами очень быстро и без нагрузки на канал — это встроенный бекап очень хорошего уровня. При репликации ВМ между площадками канал задействуется настолько минимально, насколько это возможно, и это даёт возможности строить очень интересные архитектуры DR при наличии единого центра управления и кучи децентрализованных площадок хранения.
Всё это в совокупности даёт возможность оценить и финансовую сторону очень детально, и наложить затраты на VDI на планы роста компании, и понять, как быстро окупится решение и как оно будет работать. Потому что любой VDI — это решение, которое в итоге экономит массу ресурсов, но при этом, скорее всего, без экономически выгодной возможности поменять его в течение 5–7 лет использования.
В общем, если остались вопросы не для комментариев, — пишите мне на почту [email protected].
Источник: habr.com