🥇Як будзе працаваць 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.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-біт), версія 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 Кбайт, які скапіяваны з пула.
рэсурсаў

CPU і I/O

НФА

Час адкрыцця дыялогавага
вокны ў блакноце

Адкрыццё файла VSI-Notepad [Ctrl+O]

CPU, RAM і I/O

ZHC*

Час стварэння Zip-файла з моцным сціскам

Сціск лакальнага
выпадковага файла ў фармаце .pst памерам 5MB, які скапіяваны з
пула рэсурсаў

CPU і I/O

ZLC*

Час стварэння Zip-файла са слабым сціскам

Сціск лакальнага
выпадковага файла ў фармаце .pst памерам 5MB, які скапіяваны з
пула рэсурсаў

Ўводу / высновы

CPU

Вылічэнне вялікага
масіва выпадковых дадзеных

Стварэнне вялікага масіва
выпадковых дадзеных, якія будуць выкарыстаныя ў таймеры ўводу-вываду (I/O-таймеры)

CPU

Пры выкананні тэсціравання першапачаткова падлічваецца базавая метрыка VSIbase, якая паказвае хуткасць выканання заданняў без нагрузкі на сістэму. На яе аснове вызначаецца VSImax Threshold, які роўны VSIbase + 1мс.

Высновы аб прадукцыйнасці сістэмы робяцца на аснове двух метрык: 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 гадзін

Дадаткова было праведзена тэсціраванне варыянту нагрузкі 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 дасягнуты не быў.

Дадзеныя статыстыкі па нагрузцы на CPU:

Пры выкананні дадзенага тэста нагрузка на CPU хастоў была практычна максімальнай.

Нагрузка на сістэму захоўвання на працягу тэсту склала прыкладна 6 IOPS у суадносінах 500/60 (40 IOPS – на чытанне, 3 IOPS – на запіс), што складае прыкладна 900 IOPS на адну працоўную станцыю.

Час водгуку ў сярэднім складала 3 мс на запіс і да 1 мс - на чытанне.

Вынік

Пры мадэляванні рэальных нагрузак на інфраструктуру HPE SimpliVity былі атрыманы вынікі, якія пацвярджаюць здольнасць сістэмы забяспечваць працу віртуальных працоўных сталоў у колькасці не менш за 300 Full Clone-машын на пары вузлоў SimpliVity. Пры гэтым час водгуку сістэмы захоўвання захоўвалася на аптымальным узроўні на працягу ўсяго тэсціравання.

Нам вельмі імпануе падыход пра працяглыя тэсты і параўнанне рашэнняў да ўкаранення. Мы можам пратэставаць прадукцыйнасць і для вашых нагрузак, калі хочаце. У тым ліку на іншых гіперканвергентных рашэннях. Згаданы заказчык зараз заканчвае тэсты на іншым рашэнні ў паралель. Яго бягучая інфраструктура – проста парк ПК, дамен і софт на кожным працоўным месцы. Пераязджаць на VDI без тэстаў, вядома, дастаткова складана. Канкрэтна складана разумець рэальныя магчымасці фермы VDI, не зміграваўшы на яе рэальных карыстальнікаў. А гэтыя тэсты дазваляюць хутка ацаніць рэальныя магчымасці той ці іншай сістэмы без неабходнасці прыцягнення звычайных карыстальнікаў. Адсюль і ўзнікла такое даследаванне.

Другі важны падыход - заказчык адразу заклаўся на правільнае маштабаванне. Тут можна дакупляць сервер і дадаваць ферму, напрыклад, на 100 карыстальнікаў, усё прадказальна па кошце карыстальніка. Напрыклад, калі ім спатрэбіцца дадаць яшчэ 300 карыстальнікаў, яны будуць ведаць, што патрэбны два серверы ва ўжо пэўнай канфігурацыі, а не пераглядаць магчымасці мадэрнізацыі сваёй інфраструктуры ў цэлым.

Цікавыя магчымасці федэрацыі HPE SimpliVity. Бізнес - геаграфічна падзелены, таму ў далёкі офіс мае сэнс ставіць сваю асобную VDI-жалезку. У федэрацыі SimpliVity кожная віртуалка рэплікуецца па раскладзе з магчымасцю рабіць паміж геаграфічна выдаленымі кластарамі вельмі хутка і без нагрузкі на канал - гэта ўбудаваны бекап вельмі добрага ўзроўню. Пры рэплікацыі ВМ паміж пляцоўкамі канал задзейнічаецца настолькі мінімальна, наколькі гэта магчыма, і гэта дае магчымасці будаваць вельмі цікавыя архітэктуры DR пры наяўнасці адзінага цэнтру кіравання і кучы дэцэнтралізаваных пляцовак захоўвання.

федэрацыя

Усё гэта ў сукупнасці дае магчымасць ацаніць і фінансавы бок вельмі дэталёва, і накласці выдаткі на VDI на планы росту кампаніі, і зразумець, як хутка акупіцца рашэнне і як яно будзе працаваць. Таму што любы VDI - гэта рашэнне, якое ў выніку эканоміць масу рэсурсаў, але пры гэтым, хутчэй за ўсё, без эканамічна выгаднай магчымасці памяняць яго на працягу 5-7 гадоў выкарыстання.

Увогуле, калі засталіся пытанні не для каментароў, - пішыце мне на пошту [электронная пошта абаронена].

Крыніца: habr.com

Як будзе працаваць HPE SimpliVity 380 для VDI: цвёрдыя нагрузачныя тэсты