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

Клиентът искаше 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.1 Ghz.
RAM: 768GB, 12 x 64GB LRDIMM DDR4 2666MHz.
Основен дисков контролер: HPE Smart Array P816i-a SR Gen10.
Твърди дискове: 9 x 1.92 TB SATA 6Gb/s SSD (в конфигурация RAID6 7+2, т.е. това е среден модел в термините на HPE SimpliVity).
Мрежови карти: 4 x 1Gb Eth (потребителски данни), 2 x 10Gb Eth (SimpliVity и vMotion бекенд).
Специални вградени FPGA карти във всеки възел за дедупликация/компресия.

Възлите са свързани помежду си чрез 10Gb Ethernet интерконект директно без външен превключвател, който се използва като Backend на SimpliVity и за прехвърляне на данни от виртуална машина чрез NFS. Данните за виртуална машина в клъстер винаги се отразяват между два възела.

Възлите се комбинират в Vmware vSphere клъстер, управляван от vCenter.

За тестване бяха внедрени домейн контролер и Citrix брокер за връзка. Домейн контролерът, брокерът и vCenter са поставени на отделен клъстер.

Като тестова инфраструктура бяха внедрени 300 виртуални десктопа в конфигурацията Dedicated – Full Copy, т.е. всеки десктоп е пълно копие на оригиналния образ на виртуалната машина и запазва всички промени, направени от потребителите.

Всяка виртуална машина има 2vCPU и 4GB RAM:

На виртуалните машини е инсталиран следният софтуер, необходим за тестване:

Windows 10 (64-битова), версия 1809.
Adobe Reader XI.
Citrix Virtual Delivery Agent 1811.1.
Doro PDF 1.82.
Java 7 Актуализация 13.
Microsoft Office Professional Plus 2016.

Между възлите - синхронна репликация. Всеки блок данни в клъстера има две копия. Тоест сега има пълен набор от данни за всеки от възлите. При клъстер от три или повече възли, копията на блоковете са на две различни места. При създаване на нова виртуална машина се създава допълнително копие на един от възлите на клъстера. Когато един възел се повреди, всички виртуални машини, работещи преди това на него, автоматично се рестартират на други възли, където имат реплики. Ако даден възел се повреди за дълго време, тогава започва постепенно възстановяване на резервирането и клъстерът се връща към N+1 резервиране.

Балансирането и съхранението на данни се извършва на ниво софтуерно съхранение на самия SimpliVity.

Виртуалните машини изпълняват клъстер за виртуализация, който също ги поставя в софтуерно хранилище. Самите бюра бяха взети по стандартен шаблон: бюрата на финансистите и оперативните служители дойдоха за теста (това са два различни шаблона).

Тестване

За тестване беше използван софтуерният тестов пакет LoginVSI 4.1. Комплексът LoginVSI, състоящ се от контролен сървър и 12 машини за тестови връзки, бяха разположени на отделен физически хост.

Тестването се проведе в три режима:

Режим на сравнителен анализ - случаи на натоварване 300 работници със знания и 300 работници за съхранение.

Стандартен режим - случай на натоварване 300 Силови работници.

За да се даде възможност на служителите на Power да работят и да се увеличи разнообразието на натоварването, към комплекса LoginVSI беше добавена библиотека от допълнителни файлове на Power Library. За да се осигури повторяемост на резултатите, всички настройки на тестовия стенд бяха оставени по подразбиране.

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

Тестът Storage works е създаден специално за тестване на системи за съхранение на данни; той е далеч от реалните натоварвания и най-вече включва потребителя да работи с голям брой файлове с различни размери.

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

резултати

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

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

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

Ето основните показатели:

Метрика

Взети мерки

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

Заредени компоненти

Н.С.Л.Д.

Време за отваряне на текста
файл с тегло 1 KB

Notepad се отваря и
отваря случаен документ от 1 KB, който се копира от пула
ресурси

CPU и I/O

НФО

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

Отваряне на VSI-Notepad файл [Ctrl+O]

CPU, RAM и I/O

ZHC*

Време е да създадете силно компресиран Zip файл

Локална компресия
произволен 5MB .pst файл, копиран от
пул от ресурси

CPU и I/O

ZLC*

Време е да създадете слабо компресиран Zip файл

Локална компресия
произволен 5MB .pst файл, копиран от
пул от ресурси

I / O

процесор

Изчисляване на големи
случаен масив от данни

Създаване на голям масив
произволни данни, които ще бъдат използвани в таймера за вход/изход (I/O таймер)

процесор

Когато се извършва тестване, първоначално се изчислява основната метрика VSIbase, която показва скоростта, с която се изпълняват задачи без натоварване на системата. Въз основа на него се определя VSImax Threshold, който е равен на VSIbase + 1ms.

Заключенията относно производителността на системата се правят въз основа на два показателя: VSIbase, който определя скоростта на системата, и VSImax праг, който определя максималния брой потребители, с които системата може да се справи без значително влошаване.

Еталон за 300 работници на знанието

Работниците на знания са потребители, които редовно зареждат памет, процесор и IO с различни малки пикове. Софтуерът емулира натовареността на взискателните офис потребители, сякаш непрекъснато се ровят в нещо (PDF, Java, офис пакет, преглед на снимки, 7-Zip). Докато добавяте потребители от нула до 300, забавянето за всеки постепенно се увеличава.

VSImax статистически данни:

VSIbase = 986ms, прагът на VSI не е достигнат.

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

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

Заключение: 300 потребители на знания работят върху текущия клъстер без никакви проблеми и не си пречат, достигайки pCPU/vCPU презаписване от 1 до 6. Общите забавяния нарастват равномерно с увеличаване на натоварването, но определеният лимит не е достигнат.

300 бенчмарка за работници в хранилището

Това са потребители, които постоянно пишат и четат в съотношение съответно 30 към 70. Този тест беше извършен по-скоро с цел експериментиране. VSImax статистически данни:

VSIbase = 1673, прагът на VSI е достигнат при 240 потребители.

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

Този тип натоварване е по същество стрес тест на системата за съхранение. Когато се изпълни, всеки потребител записва много произволни файлове с различни размери на диска. В този случай може да се види, че когато определен праг на натоварване е надвишен за някои потребители, времето, необходимо за изпълнение на задачите за писане на файлове, се увеличава. В същото време натоварването на системата за съхранение, процесора и паметта на хостовете не се променя значително, така че в момента е невъзможно да се определи точно какво причинява забавянията.

Заключения относно производителността на системата с помощта на този тест могат да бъдат направени само в сравнение с резултатите от тестовете на други системи, тъй като такива натоварвания са синтетични и нереалистични. Като цяло обаче тестът мина добре. Всичко вървеше добре до 210 сесии и след това започнаха странни отговори, които не бяха проследени никъде освен Login VSI.

300 енергетици

Това са потребители, които обичат процесора, паметта и високия IO. Тези „опитни потребители“ редовно изпълняват сложни задачи с дълги серии, като например инсталиране на нов софтуер и разопаковане на големи архиви. VSImax статистически данни:

VSIbase = 970, прагът на VSI не е достигнат.

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

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

В този случай системата може да издържи на повишено натоварване без значително влошаване на производителността. Времето, необходимо за изпълнение на потребителските задачи, се увеличава плавно, времето за реакция на системата не се променя по време на тестване и е до 3 ms за запис и до 1 ms за четене.

Редовните тестове не бяха достатъчни за клиента и ние отидохме по-далеч: увеличихме характеристиките на VM (брой vCPU, за да оценим увеличението на свръхабонамента и размера на диска) и добавихме допълнително натоварване.

При провеждането на допълнителни тестове е използвана следната конфигурация на стенда:
300 виртуални десктопа бяха внедрени в конфигурация 4vCPU, 4GB RAM, 80GB HDD.

Конфигурация на една от тестовите машини:

Машините са разположени в опцията Dedicated – Full Copy:

Бенчмарк за 300 работници на знанието с прекомерен абонамент 12

VSImax статистически данни:

VSIbase = 921 ms, VSI Threshold не е достигнат.

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

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

300 Силови работници с 12 презаписвания

VSImax статистически данни:

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

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

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

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

Какво се случва, ако работите с натоварване 10 часа?

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

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

300 бенчмарк за работници на знанието + 10 часа

Освен това беше тестван случай на натоварване на 300 работници с знание, последван от работа на потребителя в продължение на 10 часа.

VSImax статистически данни:

VSIbase = 919 ms, VSI Threshold не е достигнат.

VSImax Подробни статистически данни:

Графиката показва, че не се наблюдава влошаване на производителността по време на целия тест.

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

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

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

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

Бенчмарк за 300 работници на знанието + 22 IOPS на потребител

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

Натоварване на процесора на хоста:

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

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

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

230 Бенчмарк за офис служители + 22 IOPS на потребител

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

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

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

VSImax статистически данни:

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

Статистика за натоварване на процесора:

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

Натоварването на системата за съхранение по време на теста беше приблизително 6 IOPS в съотношение 500/60 (40 IOPS четене, 3 IOPS запис), което е приблизително 900 IOPS на работна станция.

Времето за реакция е средно 3 ms за запис и до 1 ms за четене.

Общо

При симулиране на реални натоварвания на инфраструктурата на HPE SimpliVity бяха получени резултати, потвърждаващи способността на системата да поддържа виртуални настолни компютри на най-малко 300 машини Full Clone на двойка SimpliVity възли. В същото време времето за реакция на системата за съхранение се поддържа на оптимално ниво по време на цялото тестване.

Много сме впечатлени от подхода на дълги тестове и сравнение на решенията преди внедряването. Можем да тестваме производителността и за вашите натоварвания, ако желаете. Включително други хиперконвергентни решения. Споменатият клиент в момента завършва успоредно тестове на друго решение. Текущата му инфраструктура е просто набор от компютри, домейн и софтуер на всяко работно място. Преминаването към VDI без тестове, разбира се, е доста трудно. По-конкретно, трудно е да се разберат реалните възможности на VDI ферма, без да се мигрират реални потребители към нея. И тези тестове ви позволяват бързо да оцените реалните възможности на конкретна система, без да е необходимо да включвате обикновени потребители. Ето откъде идва това изследване.

Вторият важен подход е, че клиентът незабавно се ангажира с правилното мащабиране. Тук можете да закупите допълнителен сървър и да добавите ферма, например за 100 потребители, всичко е предвидимо на потребителската цена. Например, когато трябва да добавят още 300 потребители, те ще знаят, че се нуждаят от два сървъра във вече дефинирана конфигурация, вместо да обмислят надграждането на цялата си инфраструктура.

Интересни са възможностите на федерацията HPE SimpliVity. Бизнесът е географски отделен, така че има смисъл да инсталирате свой собствен отделен VDI хардуер в отдалечен офис. Във федерацията SimpliVity всяка виртуална машина се репликира по график с възможност за репликация между географски отдалечени клъстери много бързо и без натоварване на канала - това е вграден бекъп на много добро ниво. При репликиране на VM между сайтове, каналът се използва възможно най-минимално и това прави възможно изграждането на много интересни DR архитектури при наличието на един контролен център и куп децентрализирани места за съхранение.

федерация

Всичко това заедно дава възможност да се оцени много подробно финансовата страна и да се наложат разходите за VDI върху плановете за растеж на компанията и да се разбере колко бързо ще се изплати решението и как ще работи. Защото всеки VDI е решение, което в крайна сметка спестява много ресурси, но в същото време най-вероятно без рентабилната възможност да го промените в рамките на 5-7 години употреба.

Като цяло, ако имате въпроси, които не са за коментар, пишете ми на имейл [имейл защитен].

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

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