Ми продовжуємо знайомити вас із гіперконвергентною системою Cisco HyperFlex.
У квітні 2019 року компанія Cisco в черговий раз проводить серію демонстрацій нового гіперконвергентного рішення Cisco HyperFlex у регіонах Росії та Казахстані. Записатися на демонстрацію можна через форму зворотного зв'язку, перейшовши за посиланням. Приєднуйтесь!
Раніше ми публікували статтю про навантажувальні тести, виконані незалежною лабораторією ESG Lab у 2017-му році. У 2018 році характеристики рішення Cisco HyperFlex (версія HX 3.0) значно покращали. Крім того, конкурентні рішення також продовжують удосконалюватися. Саме тому ми публікуємо нову, свіжішу версію порівняльних тестів навантаження від ESG.
Влітку 2018 року лабораторія ESG провела повторне порівняння Cisco HyperFlex з конкурентами. Враховуючи сучасну тенденцію використання Software-defined-рішень, порівняльний аналіз також додали виробники подібних платформ.
Тестові конфігурації
У рамках тестування HyperFlex порівнювався з двома повністю програмними гіперконвергентними системами, які встановлюються на стандартні сервери x86, а також з одним програмно-апаратним рішенням. Тестування проводилося з використанням стандартного для гіперконвергентних систем ПЗ – HCIBench, яке використовує інструмент Oracle Vdbench та автоматизує процес тестування. Зокрема, HCIBench автоматично створює віртуальні машини, координує навантаження між ними та генерує зручні та зрозумілі звіти.
Було створено 140 віртуальних машин кластера (35 на ноду кластера). Кожна віртуальна машина використовувала 4 vCPU, 4 ГБ RAM. Локальний диск ВМ був 16 ГБ та додаткові диск 40 ГБ.
У тестуванні брали участь такі зміни кластерів:
- кластер із чотирьох вузлів Cisco HyperFlex 220C 1 x 400 ГБ SSD для кешу та 6 x 1.2 ТБ SAS HDD для даних;
- кластер конкурента Vendor A із чотирьох вузлів 2 x 400 ГБ SSD для кешу та 4 x 1 ТБ SATA HDD для даних;
- кластер конкурента Vendor B із чотирьох вузлів 2 x 400 ГБ SSD для кешу та 12 x 1.2 ТБ SAS HDD для даних;
- кластер конкурента Vendor C із чотирьох вузлів 4 x 480 ГБ SSD для кешу та 12 x 900 ГБ SAS HDD для даних.
Процесори та оперативна пам'ять усіх рішень були ідентичними.
Тест на кількість віртуальних машин
Тестування розпочалося з робочого навантаження, призначеного для емуляції стандартного OLTP-тесту: читання/запис (RW) 70%/30%, 100% FullRandom із цільовим значенням 800 IOPS на одну віртуальну машину (ВМ). Тест проводився на 140 ВМ у кожному кластері протягом трьох-чотирьох годин. Ціль тесту – зберегти затримки при записі на максимальній кількості ВМ на рівні 5 мілісекунд або нижче.
В результаті тесту (див. графік нижче) HyperFlex виявився єдиною платформою, яка завершила цей тест із початковими 140 ВМ та при затримках нижче 5 мс (4,95 мс). Для кожного з інших кластерів тест був перезапущений для того, щоб дослідним шляхом за кілька ітерацій підігнати кількість ВМ під цільову затримку 5 мс.
Vendor A успішно впорався з 70-ма ВМ із середнім часом відгуку 4,65 мс.
Vendor B забезпечив необхідні затримки 5,37 мс. тільки з 36-ма ВМ.
Vendor C зміг витримати 48 віртуальних машин з часом відгуку 5,02 мс
Емуляція навантаження SQL Server
Далі ESG Lab емулювала навантаження SQL Server. У тесті використовувалися різні розміри блоків та співвідношення читання/запису. Тест було запущено також на 140 віртуальних машинах.
Як показано на малюнку нижче, кластер Cisco HyperFlex майже вдвічі перевершив IOPS-ам вендора A і В, а вендора С більш ніж у п'ять разів. Середній час відгуку Cisco HyperFlex становив 8,2 мс. Для порівняння, середній час відповіді вендора А становив 30,6 мсек, вендора В - 12,8 мс, а вендора С - 10,33 мс.
Цікаве спостереження було зроблено під час усіх тестів. Vendor B показав значний розкид середньої продуктивності в IOPS-ах різних ВМ. Тобто навантаження розподілялося вкрай нерівномірно, деякі ВМ працювали із середнім значенням 1000 IOPS+, а деякі – зі значенням 64 IOPS. Cisco HyperFlex в даному випадку виглядав значно стабільнішим, усі 140 ВМ отримували в середньому 600 IOPS від підсистеми зберігання даних, тобто навантаження між віртуальними машинами було розподілено дуже рівномірно.
Важливо відзначити, що такий нерівномірний розподіл IOPS по віртуальних машинах у вендора B спостерігався у кожній ітерації тестування.
У реальному продуктивності така поведінка системи може бути великою проблемою для адміністраторів, по суті, окремі віртуальні машини випадково починають «підвисати» і ніякого способу для контролю цього процесу не існує. Єдиним, не дуже вдалим способом вирівнювання навантаження, при використанні рішення від вендора B є використання тієї чи іншої реалізації QoS або балансування.
Висновок
Давайте подумаємо, що таке 140 віртуальних машин у Cisco Hyperflex на 1 фізичний вузол проти 70 або менше в інших рішень? Для бізнесу це означає, що для підтримки тієї самої кількості додатків на Hyperflex потрібно вдвічі менше вузлів, ніж у рішеннях конкурентів, тобто. підсумкова система буде значно дешевшою. Якщо додати сюди ще рівень автоматизації всіх операцій з обслуговування мережі, серверів та платформи зберігання HX Data Platform, стає зрозуміло, чому рішення Cisco Hyperflex так швидко завойовують популярність на ринку.
В цілому, лабораторія ESG підтвердила, що гібридні Cisco HyperFlex версії HX 3.0 забезпечують більш високу та стабільну продуктивність, ніж інші аналогічні рішення.
При цьому гібридні кластери HyperFlex ще й випереджали конкурентів за показниками IOPS та Latency. Не менш важливим є і те, що продуктивність HyperFlex була забезпечена при дуже добре розподіленому навантаженні по всьому сховищу.
Нагадаємо, що побачити рішення Cisco Hyperflex та переконатися у його можливостях ви можете вже зараз. Система доступна для демонстрації всім бажаючим:
Джерело: habr.com