Комментарии 3
И снова — на сцене цирка Cisco, под яркими лучами софитов :)
Коллеги, право — статьи писать на техническом ресурсе — все же IMHO не ваше.
«Гиперконвергентные решения до недавнего времени являлись не очень подходящим решением для СУБД, тем более с высокой нагрузкой.» — очень, очень смелое заявление.
Впрочем, учитывая любовь вендора к сравнению с какими-то мифическими «A» и «B» от (опять-же) любимой ESG Labs (Huawei и Pivot3?)…
Между тем как у реальных лидеров (их видно на приведенном вами-же MQ) — с поддержкой баз данных не просто все давно прекрасно, а стало обыденностью жизни.
Показывать на публику тесты на vdbench и делать столь громкие заявления о разрыве в «сотни процентов» — в целом расписаться в полном / вопиющем непрофессионализме.
Почему? Все просто — такие утилиты (iometer, vdbench, и тд) не рассчитаны на тестирование работы современных мультипоточных операционных систем. Они создавались для тестирования традиционных 3-tier архитектур / shared storage.
При тестировании HCI они покажут что угодно (вплоть до погоды на марсе), кроме реальной призводительности.
При реальных тестах баз данных (в том числе по отзывам клиентов) — производителеность SpringPath (компании приобретенной Cisco для «закрытия дыры» HCI) одна из худших на рынке.
Фактически, по результату чтения вашей «статьи», любой грамотный инженер должен вас не пустить ближе порога, ибо в русском языке это называется «голимый маркетинг».
Отсюда, видимо, и вытекает смешная доля Cisco на HCI рынке — около 2%.
Клиенты, к счастью, нынче пошли образованные и умные.
Чуть ликбеза:
«The reason we had to address this problem is because traditional workload generators like iometer, vdbench, and fio are brute force speed tests designed for traditional shared storage arrays. There's a lot of baggage that accompanies that:
They just read and write data.
They were created when the upper limits of storage performance really mattered.
They are leftovers of measuring spinning disks
Ultimately, they were built in a time when storage performance was the first order problem: the most likely limit to your application’s performance was its ability to access storage.
But that changed with SSDs.
Flash changed the storage performance conversation. Just a few SSDs can easily exceed application requirements. If you take advantage of SSDs the way hyperconverged infrastructures (HCI) do, you can move most application bottlenecks to waiting for CPU, not storage. This also changed the way systems scale.
HCI allows for incremental scale with workloads colacted on the same system as your storage. It removes the guesswork needed to evaluate the maximum a storage array can handle. Instead of buying one big instance of storage and adding workloads over time, you scale your storage as your needs increase. You should still understand the performance of a system but it changes to a broader sense, one that is more applicable to true datacenter operations rather than the unsophisticated drag race of the old workload generators.
Because most application requirements are easily met with flash, storage performance becomes a control variable in a more complete test of an entire system. X-ray will run a workload characterization and for most tests it will make the throughput requirement steady state. Instead of testing the limits of storage performance, we shift the focus to that of maintaining consistent and reliable performance in a number of scenarios that are encountered in data centers.
Some of these common scenario categories include:
Noisy Neighbors — Run a workload in one VM and add a new VM with new work. The application in the first VM should be unaffected.
Additional workload — Increase the rational workload of an application, there should be little effect on performance as work is added.
Rolling upgrades — There should be little effect seen at the application as hypervisor and virtual storage controllers are upgraded.
Node failures — Fail a node, there should be a slight pause (that’s probably not noticed by application or user) and then little effect to the application after the failure.
»
Коллеги, право — статьи писать на техническом ресурсе — все же IMHO не ваше.
«Гиперконвергентные решения до недавнего времени являлись не очень подходящим решением для СУБД, тем более с высокой нагрузкой.» — очень, очень смелое заявление.
Впрочем, учитывая любовь вендора к сравнению с какими-то мифическими «A» и «B» от (опять-же) любимой ESG Labs (Huawei и Pivot3?)…
Между тем как у реальных лидеров (их видно на приведенном вами-же MQ) — с поддержкой баз данных не просто все давно прекрасно, а стало обыденностью жизни.
Показывать на публику тесты на vdbench и делать столь громкие заявления о разрыве в «сотни процентов» — в целом расписаться в полном / вопиющем непрофессионализме.
Почему? Все просто — такие утилиты (iometer, vdbench, и тд) не рассчитаны на тестирование работы современных мультипоточных операционных систем. Они создавались для тестирования традиционных 3-tier архитектур / shared storage.
При тестировании HCI они покажут что угодно (вплоть до погоды на марсе), кроме реальной призводительности.
При реальных тестах баз данных (в том числе по отзывам клиентов) — производителеность SpringPath (компании приобретенной Cisco для «закрытия дыры» HCI) одна из худших на рынке.
Фактически, по результату чтения вашей «статьи», любой грамотный инженер должен вас не пустить ближе порога, ибо в русском языке это называется «голимый маркетинг».
Отсюда, видимо, и вытекает смешная доля Cisco на HCI рынке — около 2%.
Клиенты, к счастью, нынче пошли образованные и умные.
Чуть ликбеза:
«The reason we had to address this problem is because traditional workload generators like iometer, vdbench, and fio are brute force speed tests designed for traditional shared storage arrays. There's a lot of baggage that accompanies that:
They just read and write data.
They were created when the upper limits of storage performance really mattered.
They are leftovers of measuring spinning disks
Ultimately, they were built in a time when storage performance was the first order problem: the most likely limit to your application’s performance was its ability to access storage.
But that changed with SSDs.
Flash changed the storage performance conversation. Just a few SSDs can easily exceed application requirements. If you take advantage of SSDs the way hyperconverged infrastructures (HCI) do, you can move most application bottlenecks to waiting for CPU, not storage. This also changed the way systems scale.
HCI allows for incremental scale with workloads colacted on the same system as your storage. It removes the guesswork needed to evaluate the maximum a storage array can handle. Instead of buying one big instance of storage and adding workloads over time, you scale your storage as your needs increase. You should still understand the performance of a system but it changes to a broader sense, one that is more applicable to true datacenter operations rather than the unsophisticated drag race of the old workload generators.
Because most application requirements are easily met with flash, storage performance becomes a control variable in a more complete test of an entire system. X-ray will run a workload characterization and for most tests it will make the throughput requirement steady state. Instead of testing the limits of storage performance, we shift the focus to that of maintaining consistent and reliable performance in a number of scenarios that are encountered in data centers.
Some of these common scenario categories include:
Noisy Neighbors — Run a workload in one VM and add a new VM with new work. The application in the first VM should be unaffected.
Additional workload — Increase the rational workload of an application, there should be little effect on performance as work is added.
Rolling upgrades — There should be little effect seen at the application as hypervisor and virtual storage controllers are upgraded.
Node failures — Fail a node, there should be a slight pause (that’s probably not noticed by application or user) and then little effect to the application after the failure.
»
Максим!
В целом согласен с вами о маркетинговом характере статьи Cisco, но по крайней мере ребята подошли к задачи со всей прямотой: взяли всем известные тесты и померили по явно описанной методике производительность своей и конкурирующих систем (правда, непонятно каких и на собственных серверах). А вот ваш комментарий вызывает некоторые вопросы:
1. «утилиты (iometer, vdbench, и тд) не рассчитаны на тестирование работы современных мультипоточных операционных систем»
Критикуя — предлагай! Приведите примеры альтернативных общепризнанных индустрией тестов (я не говорю о X-Ray, которым можно померить только вас самих и которые ни на что другое не ставится), которые адекватно показывали бы производительность HCI?
2. «Гиперконвергентные решения до недавнего времени являлись не очень подходящим решением для СУБД, тем более с высокой нагрузкой»
Покажите результаты работы хоть какой голой HCI системы на СУБД под высокой нагрузкой? Ни одной публикации в интернете нет. На Oracle, HANA, Hadoop? Да хотя бы попробуйте нагрузить свыше 500 пользователей 1С. Только не надо прислыать ссылки на признание производителей ПО. Мы не о совместимости, мы о производительности. Проблема есть и она заложена в самой архитектуре HCI.
3. the most likely limit to your application’s performance was its ability to access storage. But that changed with SSDs.
Никто не будет спорить, что SSD быстрее, чем HDD. Но так же никто не будет спорить, что скорость DDR4 существенно выше не только SSD дисков, но и Optane.
Мы сейчас вроде о высоконагруженных системах. Вы тоже вроде за реальных потребителей ратуете, а не о рекордах круглых коней в вакууме. Сколько реально в системе горячих данных, а сколько просто лежит? А о деньгах задумались?
Есть определенные плюсы в HCI технологии, но нужен сбалансированный подход к созданию архитектуры и приложений и предприятия в целом. Говорить сразу — у нас работает, а это не работает — не верно. Вы тогда тоже, простите, опускаетесь до уровня «голимого маркетинга».
Дайте ваши цифры и тесты!
В целом согласен с вами о маркетинговом характере статьи Cisco, но по крайней мере ребята подошли к задачи со всей прямотой: взяли всем известные тесты и померили по явно описанной методике производительность своей и конкурирующих систем (правда, непонятно каких и на собственных серверах). А вот ваш комментарий вызывает некоторые вопросы:
1. «утилиты (iometer, vdbench, и тд) не рассчитаны на тестирование работы современных мультипоточных операционных систем»
Критикуя — предлагай! Приведите примеры альтернативных общепризнанных индустрией тестов (я не говорю о X-Ray, которым можно померить только вас самих и которые ни на что другое не ставится), которые адекватно показывали бы производительность HCI?
2. «Гиперконвергентные решения до недавнего времени являлись не очень подходящим решением для СУБД, тем более с высокой нагрузкой»
Покажите результаты работы хоть какой голой HCI системы на СУБД под высокой нагрузкой? Ни одной публикации в интернете нет. На Oracle, HANA, Hadoop? Да хотя бы попробуйте нагрузить свыше 500 пользователей 1С. Только не надо прислыать ссылки на признание производителей ПО. Мы не о совместимости, мы о производительности. Проблема есть и она заложена в самой архитектуре HCI.
3. the most likely limit to your application’s performance was its ability to access storage. But that changed with SSDs.
Никто не будет спорить, что SSD быстрее, чем HDD. Но так же никто не будет спорить, что скорость DDR4 существенно выше не только SSD дисков, но и Optane.
Мы сейчас вроде о высоконагруженных системах. Вы тоже вроде за реальных потребителей ратуете, а не о рекордах круглых коней в вакууме. Сколько реально в системе горячих данных, а сколько просто лежит? А о деньгах задумались?
Есть определенные плюсы в HCI технологии, но нужен сбалансированный подход к созданию архитектуры и приложений и предприятия в целом. Говорить сразу — у нас работает, а это не работает — не верно. Вы тогда тоже, простите, опускаетесь до уровня «голимого маркетинга».
Дайте ваши цифры и тесты!
Все смешалось в доме Облонских ;)
Для начала — спасибо за то, что как минимум — пытаешься разобраться в реальностях.
Но ты бы хотя бы погуглил чуток перед тем как писать.
1) X-Ray — внезапно — может тестировать что угодно. Нутаникс для него вообще не нужен. И исходники доступны, и параметры тестирования — все открыто. Можно запустить как VM на чем угодно, и далее тестировать хоть 3-tier.
github.com/nutanix/xray-scenarios
2) Насчет «хоть какой» — я так понимаю ты очень серьезно отстал от рынка. У нас масса внедрений огромных баз данных в мире — начиная от «Платона» в РФ (300TB насколько помню крутят на Постгрес) и InBev (70TB базы Oracle), заканчивая всякими Nintendo и прочими Toyota.
Идешь на nutanix.com и смотришь Best Practices.
Как намек — SAP сертифицировал Nutanix для SAP HANA (на 4-х сокетах в том числе), а так-же всех приложений Netweaver.
Которые по определению требуют business critical базу данных.
Или идешь и смотришь результаты CFT (ЦФТ) — на их АБС (которую они официально сертифицировали под Нутаникс) мы порвали даже ExaData (на старом железе результат был с Oracle RAC — около 7000TPS, сейчас я думаю раза в полтора будет выше). В РФ кроме Сбербанка даже нет банков которым столько нужно.
В общем откровенно ты удивил, замечание про «HCI архитектуру» крайне посмешило. HCI (за счет той-же data locality) по определению способен работать с БД намного быстрее и лучше чем традиционные архитектуры.
blog.in-a-nutshell.ru/nutanix-1-tier-business-critical-cft
pgconf.ru/2017/93499
www.reddit.com/r/NintendoNX/comments/51wo4s/whats_in_a_name_nitendo_utilising_nutanix_xtreme
4) Нутаникс поддерживает полноценный тиринг.
Горячие данные на SSD, холодные на SATA. Остальные HCI вендоры нормальный тиринг не умеют (как и большинство традиционных СХД), поэтому пихают All Flash.
Так-что да, Нутаникс о клиентах как раз позаботился.
Для начала — спасибо за то, что как минимум — пытаешься разобраться в реальностях.
Но ты бы хотя бы погуглил чуток перед тем как писать.
1) X-Ray — внезапно — может тестировать что угодно. Нутаникс для него вообще не нужен. И исходники доступны, и параметры тестирования — все открыто. Можно запустить как VM на чем угодно, и далее тестировать хоть 3-tier.
github.com/nutanix/xray-scenarios
2) Насчет «хоть какой» — я так понимаю ты очень серьезно отстал от рынка. У нас масса внедрений огромных баз данных в мире — начиная от «Платона» в РФ (300TB насколько помню крутят на Постгрес) и InBev (70TB базы Oracle), заканчивая всякими Nintendo и прочими Toyota.
Идешь на nutanix.com и смотришь Best Practices.
Как намек — SAP сертифицировал Nutanix для SAP HANA (на 4-х сокетах в том числе), а так-же всех приложений Netweaver.
Которые по определению требуют business critical базу данных.
Или идешь и смотришь результаты CFT (ЦФТ) — на их АБС (которую они официально сертифицировали под Нутаникс) мы порвали даже ExaData (на старом железе результат был с Oracle RAC — около 7000TPS, сейчас я думаю раза в полтора будет выше). В РФ кроме Сбербанка даже нет банков которым столько нужно.
В общем откровенно ты удивил, замечание про «HCI архитектуру» крайне посмешило. HCI (за счет той-же data locality) по определению способен работать с БД намного быстрее и лучше чем традиционные архитектуры.
blog.in-a-nutshell.ru/nutanix-1-tier-business-critical-cft
pgconf.ru/2017/93499
www.reddit.com/r/NintendoNX/comments/51wo4s/whats_in_a_name_nitendo_utilising_nutanix_xtreme
4) Нутаникс поддерживает полноценный тиринг.
Горячие данные на SSD, холодные на SATA. Остальные HCI вендоры нормальный тиринг не умеют (как и большинство традиционных СХД), поэтому пихают All Flash.
Так-что да, Нутаникс о клиентах как раз позаботился.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cisco Hyperflex для высоконагруженных СУБД