Замовник захотів 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 LRDIMM DDR4 2666MHz.
- Основний дисковий контролер: HPE Smart Array P816i 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 Кбайт
Запускається блокнот та
відкриває випадковий документ вагою 1 Кбайт, який скопійований з пулу
ресурсів
CPU та I/O
НФО
Час відкриття діалогового
вікна у блокноті
Відкриття файлу VSI-Notepad [Ctrl+O]
CPU, RAM та I/O
ZHC*
Час створення Zip-файлу з сильним стисненням
Стиснення локального
випадкового файлу у форматі .pst розміром 5MB, який скопійовано з
пула ресурсів
CPU та I/O
ZLC*
Час створення Zip-файлу зі слабким стисненням
Стиснення локального
випадкового файлу у форматі .pst розміром 5MB, який скопійовано з
пула ресурсів
I / O
центральний процесор
Обчислення великого
масиву випадкових даних
Створення великого масиву
випадкових даних, які будуть використані в таймері вводу-виводу (I/O-таймері)
центральний процесор
Під час виконання тестування спочатку підраховується базова метрика 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:XNUMX?
Тепер дивимося, чи буде «ефект накопичення» і пускаємо тести на 10 годин поспіль.
Тривалі тести та опис розділу повинні бути націлені на те, що ми хотіли перевірити, чи виникатимуть проблеми з фермою при тривалому навантаженні на неї.
300 Knowledge workers benchmark + 10 годин
Додатково було проведено тестування варіанта навантаження 300 знань працівників з подальшою роботою користувачів протягом 10 годин.
Дані статистики VSImax:
VSIbase = 919 мс, VSI Threshold не досяг.
Дані статистики VSImax Detailed:
За графіком видно, що протягом усього тесту немає будь-якої деградації продуктивності.
Статистика навантаження на систему зберігання з моніторингу SimpliVity:
Продуктивність системи зберігання залишається одному рівні протягом усього тесту.
Додаткове тестування з додаванням синтетичного навантаження
Замовник попросив додати дике навантаження на диск. Для цього до системи зберігання в кожну з віртуальних машин користувачів було додано завдання на запуск синтетичного навантаження на диск під час входу користувача до системи. Навантаження забезпечувалося утилітою fio, що дозволяє обмежувати навантаження на диск за кількістю IOPS. У кожній машині запускалося завдання на запуск додаткового навантаження у кількості 22 IOPS 70%/30% Random Read/Write.
300 Знання робітників 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 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