🥇Как ще работи HPE SimpliVity 380 за VDI: строги натоварващи тестове

Клиент поиска решения VDI. Стремился к связке SimpliVity + VDI Citrix Virtual Desktop для всех операторов и офисных сотрудников по городам и регионам. В первой волне миграции было пять тысяч пользователей, и поэтому они настояли на проведении нагрузочного тестирования. VDI может начать замедляться или быть в состоянии ожидания — и это не всегда связано с проблемами канала. Мы приобрели мощный пакет тестирования конкретно для VDI и нагружали инфраструктуру до тех пор, пока она не вышла из строя по дискам и процессору.

Итак, нам понадобятся пластиковая бутылка и софт LoginVSI для комплексных тестов VDI. У нас есть лицензии на 300 пользователей. Затем мы взяли оборудование HPE SimpliVity 380, подходящее для задачи высокой плотности пользователей на один сервер, развернули виртуальные машины с хорошим резервированием, установили офисный софт на Windows 10 и начали тестирование.

Хайде да започваме!

Система

Два узла (сервера) 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. За да се осигури повторяемост на резултатите, всички настройки на тестовата среда бяха оставени по подразбиране.

Тестовете Knowledge и Power workers имитират реалното натоварване на потребители, работещи на виртуални работни станции.

Тестът Storage workers беше създаден специално за тестване на системи за съхранение на данни, далечен е от реалните натоварвания и по-голямата част от него се състои в работата на потребителя с голям брой файлове с различен размер.

В процеса на тестване, потребителите се свързват с работните станции в продължение на 48 минути, обикновено по един потребител на всеки 10 секунди.

Резултати

Основният резултат от тестването на LoginVSI е метриката VSImax, която се изчислява на базата на времето за изпълнение на различни задачи, извършвани от потребителя. Например: време за отваряне на файл в блокнот, време за компресиране на файл в 7-Zip и т.н.

Подробно описание на метрик е достъпно в официалната документация за връзката.

С други думи, LoginVSI повтаря типичния товарен модел, симулирайки действия на потребител в офис пакет, при четене на PDF и така нататък, и измерва различни закъснения. Има критично ниво на закъснения "всичко забавя, невъзможно е да се работи"), до достигането на което се счита, че максималният брой потребители не е достигнат. Ако времето за отговор на 1 000 мс е по-бързо от това състояние "всичко забавя", то се счита, че системата работи нормално и могат да се добавят още потребители.

Ето основните метрики:

Метрика

Извършвани действия

Подробно описание

Натоварвани компоненти

NSLD

Време за отваряне на текстов
файл с размер 1 500 Кбайт

Стартиране на Notepad и
отваряне на произволен документ с размер 1 500 Кбайт, който е копиран от пула
ресурси

CPU и I/O

NFO

Време за отваряне на диалогово
прозорец в Notepad

Отваряне на файл 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 Знания работници бенчмарк

Знания работници — това са потребители, които редовно натоварват паметта, процесора и I/O с различни краткотрайни пикочни натоварвания. Софтуерът емулира натоварването на взискателни офис потребители, сякаш постоянно нещо кликаят (PDF, Java, офис пакет, преглед на снимки, 7-Zip). С добавянето на потребители от нула до 300 закъснението на всеки плавно нараства.

Данни за статистиката VSImax:

VSIbase = 986мс, VSI Threshold не е достигнат.

Статистика за натоварването на системата за съхранение от мониторинга на SimpliVity:

При този тип натоварване системата понася увеличението на натоварването практически без загуба на производителност. Времето за изпълнение на задачите на потребителите нараства плавно, времето за отговор на системата не се променя по време на тестването и е до 3 ms за запис и до 1 ms за четене.

Извод: 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

Това са потребители, които ценят процесора, паметта и високите I/O. Тези "напреднали потребители" редовно изпълняват сложни задачи с дълги пикове, като инсталиране на нов софтуер и разархивиране на големи архиви. Данни от статистиката 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 прага не беше достигнат.

Статистика за натоварването на системата за съхранение от мониторинга на SimpliVity:

Получените резултати са подобни на тестването на предишната конфигурация на ВМ.

300 Power workers с пренасищане 12

Данни за статистиката VSImax:

VSIbase = 933, VSI прага не беше достигнат.

Статистика за натоварването на системата за съхранение от мониторинга на SimpliVity:

При това тестване също беше достигнат прага на натоварване на процесорите, но това не оказа значително влияние на производителността:

Получените резултати са подобни на тестването на предишната конфигурация.

Какво ще стане, ако пуснем натоварването за 10 часа?

Сега гледаме дали ще има 'ефект на натрупване' и пускаме тестове за 10 часа поред.

Дългосрочните тестове и описание на раздела трябва да бъдат насочени към това, което искахме да проверим, ще възникнат ли някакви проблеми с фермата при дълготрайно натоварване.

300 Knowledge workers benchmark + 10 часа

Допълнително беше проведено тестване на вариант на натоварване 300 knowledge workers с последваща работа на потребителите в продължение на 10 часа.

Данни за статистиката VSImax:

VSIbase = 919 мс, VSI прага не беше достигнат.

Данни за статистиката VSImax Detailed:

По графика се вижда, че през цялото тестване не се наблюдава никаква деградация на производителността.

Статистика за натоварването на системата за съхранение от мониторинга на SimpliVity:

Производителността на системата за съхранение остава на едно ниво през цялото тестване.

Допълнително тестване с добавяне на синтетично натоварване.

Клиентът поиска да добави натоварване върху диска. За целта на системата за съхранение в всяка от виртуалните машини на потребителите беше добавена задача за стартиране на синтетично натоварване при входа на потребителя в системата. Натоварването се осъществяваше с помощта на утилитата fio, която позволява да се ограничи натоварването на диска по брой IOPS. Всяка машина стартираше задача за допълнително натоварване от 22 IOPS с 70 %/30 % произволно четене/запис.

300 Knowledge workers benchmark + 22 IOPS на потребител

При първоначалното тестване беше установено, че fio генерира значително допълнително натоварване на процесора на виртуалните машини. Това доведе до бързо претоварване на хостовете по CPU и оказа сериозно влияние върху работата на системата като цяло.

Натоварване на CPU на хостовете:

Закъсненията на системата за съхранение също закономерно се увеличиха:

Недостатъкът на изчислителна мощност стана критичен при около 240 потребители:

Вследствие на получените резултати беше решено да се проведе тестване, което да натоварва по-малко CPU.

230 Office workers benchmark + 22 IOPS на потребител

За намаляване на натоварването на CPU беше избран тип натоварване Office workers, на всяка сесия също беше добавено по 22 IOPS синтетично натоварване.

Тестът беше ограничен до 230 сесии, за да не се надвиши максималното натоварване на CPU.

Тестът стартира с последваща работа на потребителите в продължение на 10 часа за проверка на стабилността на системата при дълга работа с натоварване, близко до максималното.

Данни за статистиката VSImax:

VSIbase = 918 мс, VSI Threshold не беше достигнат.

Данни от статистиката по натоварване на CPU:

При изпълнение на този тест натоварването на CPU на хостовете беше практически максимално.

Натоварването на системата за съхранение по време на теста беше около 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 години употреба.

Ако имате въпроси, които не са за коментари, пишете ми на ел. поща mk@croc.ru.

Източник: habr.com