Мы продолжаем знакомить вас с гиперконвергентной системой 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 ГБ.
В тестировании участвовали следующие конфигурации кластеров:
Процессоры и оперативная память всех решений были идентичными.
Тестирование началось с рабочей нагрузки, предназначенной для эмуляции стандартного 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 мс
Далее 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 нужно в 2 раза меньше узлов, чем в решениях конкурентов, т.е. итоговая система будет сильно дешевле. Если добавить сюда еще уровень автоматизации всех операций по обслуживанию сети, серверов и платформы хранения HX Data Platform, становится ясно, почему решения Cisco Hyperflex так стремительно завоевывают популярность на рынке.
В целом, лаборатория ESG подтвердила, что гибридные Cisco HyperFlex версии HX 3.0 обеспечивают более высокую и стабильную производительность, чем другие аналогичные решения.
При этом гибридные кластеры HyperFlex еще и опережали конкурентов по показателям IOPS и Latency. Не менее важно и то, что производительность HyperFlex была обеспечена при очень хорошо распределенной нагрузке по всему хранилищу.
Напомним, что увидеть решение 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 нужно в 2 раза меньше узлов, чем в решениях конкурентов, т.е. итоговая система будет сильно дешевле. Если добавить сюда еще уровень автоматизации всех операций по обслуживанию сети, серверов и платформы хранения HX Data Platform, становится ясно, почему решения Cisco Hyperflex так стремительно завоевывают популярность на рынке.
В целом, лаборатория ESG подтвердила, что гибридные Cisco HyperFlex версии HX 3.0 обеспечивают более высокую и стабильную производительность, чем другие аналогичные решения.
При этом гибридные кластеры HyperFlex еще и опережали конкурентов по показателям IOPS и Latency. Не менее важно и то, что производительность HyperFlex была обеспечена при очень хорошо распределенной нагрузке по всему хранилищу.
Напомним, что увидеть решение Cisco Hyperflex и убедиться в его возможностях вы можете уже сейчас. Система доступна для демонстрации всем желающим:
