Гартнер составлял. Там много людей работает над любым квадрантом.
А так вообще-то есть расклад по рыночным долям HCI — и от Гартнера и от IDC. Цифры отличаются, но и по тем и другим — Nutanix + VMware лидеры с огромным отрывом, Cisco и остальные — даже не догоняющие, а жестко отставшие.
Cisco — маргиналы, около 5% всего доля (по IDC) и существенно меньше (по Гартнеру).
IDC:
Гартнер:
(Nutanix — 51%, VMware — 41%, все остальные маргиналы — 8%)
Господа, а кто у вас ближайший конкурент собственно, с которым производительность сравнивали?
Документ более чем полуторагодовалой давности приводить конечно можно, но это ни о чем реально не говорит.
Если судить по Magic Quadrant, Cisco не вошла в лидеры по HCI (имея крайне минорную / малозаметную долю на рынке), и находится где-то рядом с Huawei и Pivot3. О ком из них идет речь?
К сожалению, все ваши выкладки — в лучшем случае просто означают полное непонимание архитектуры. В худшем — осознанная попытка ввести в заблуждение. Solidfire кардинально проигрывает Nutanix с точки зрения эффективности использования пространства, ввиду того что не поддерживает EC-X и максимальный размер LUN всего 16TB.
«NetApp Cloud Volumes Service for AWS » — это прекрасно.
Внезапно, «NetApp Cloud Volumes» построены на NetApp.
Я бы реально удивился если бы они были построены на HPE 3par :)
Повторяю, цитата NetApp:
«NetApp Cloud Backup Service is an add-on feature for Cloud Volumes Service that delivers fully managed backup and restore capabilities for Cloud Volumes Service»
У AWS есть Cloud Volumes Service. Которые построены на технологиях AWS и там и близко не пахнет NetApp. Нетапу разрешили выпустить Add-On для Cloud Volumes Services, поэтому он и называется NetApp Cloud Volumes Service.
Это как примерно VMware начнет рассказывать что (им разрешили запускать ESXi на bare-metal instance i3 AWS) что AWS перешел на ESXi.
«Необходимость реплицировать данные между нодами и есть лимит в данной архитектуре. „
Т.е. Solidfire не защищает / реплицирует данные? Правда? :)
“Новая это там где нужно в 3 раза больше накладных расходов по ёмкости » — извините, глупость. Solidfire существенно проигрывает по эффективной емкости. Как начнут поддерживать EC-X хотя-бы — приходите обратно, поговорим.
«Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?»
Вы про solidfire? Где стартовая конфигурация — минимум 4 узла СХД (с выкинутыми процессорами — фактически только под СХД) и 2 сервера, итого 6 узлов?
…
Пардон, но еще раз непрозрачно намекаю — чтобы не нести странности, изучите для начала хотя-бы минимум технологический
Да, про «Backups for NetApp Cloud Volumes Service for AWS» — как я понимаю, вы совершенно не понимаете о чем пишете.
Backups for NetApp Cloud Volumes Service for AWS — это AWS разрешила поверх своего HCI запускать ПО NetApp для тех клиентов кому это нужно.
Попытка выдать это как AWS использует NetApp для расширения — прекрасна в своей неразумности.
«he NetApp Cloud Backup Service is an add-on feature for Cloud Volumes Service that delivers fully managed backup and restore capabilities for Cloud Volumes Service»
Вы уж сэр определитесь. Внезапно — вдруг как бы закинутое про «в 5 раз медленнее» — уже Нутаникса и не касается (хорошо что хотя бы это открыто признали).
В целом такое поведение называется «накинуть и попытаться отскочить».
«Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.»
Пардон — но это откровенная ерунда.
В контексте обсуждения (речь про HCI, FHCI и гиперскейлы) — вообще бессмыслица, ибо упомянутые «гиперскейлы» и Нутаникс обладают движками NoSQL с максимально высокой производительностью, надежностью и консистентностью данных на уровне наносекунд.
Современные динозавры рынка не только не обладают подобными технологиями, но и неспособны их создать.
Пойдем от обратного, как в анекдоте про Аленушку, чудовище заморское для утех и аленький цветочек.
Перечислите (например) сервисы AWS, которые предоставляют shared storage на NetApp.
Кстати, если долго говорить «сахар» — слаще не станет.
Первый же тотальный провал Yahoo при переходе Мариссы Мейер из Гугла — тотальная пролежка файлеров NetApp, с массой репутационных и финансовых потерь.
Собственно, как IMHO правильно пишут на tech crunch (ссылку давал выше) — одна из причин смерти Yahoo — устаревшие технологии NetApp / отсутствие инноваций.
«Building fast and building to last
At the beginning of the new millennium, Google and Yahoo started down very different paths to attain the enormous scale that the growing size and demands of the Internet economy (search, email, maps, etc.) required. For Yahoo, the solution came in the form of NetApp filers, which allowed the company to add server space at a dizzying rate. Almost every service that Yahoo offered ultimately ran on NetApp’s purpose-built storage appliances, which were quick to set up and easy to use, giving Yahoo a fast track to meet market demand (and soon made the company NetApp’s largest customer).
But in nearby Mountain View, Google began work on engineering its own software-defined infrastructure, ultimately known as the Google File System
…
Instead of using the latest storage appliances as a foundation, the Google File System used commodity servers to support a flexible and resilient architecture that could solve scalability and resiliency issues once and for all, „
Устройство «стоража» в данном случае — ключевой момент, ибо позволяет при сохранении ультра-высокой надежности — практически безлимитно масштабироваться — как по скорости так и емкости.
Cобственно, NDFS (Nutanix DFS) и «Кассандра» (она же Medusa) — это DNA Нутаникс, на который все остальные «фича» навешаны — включая SDN (чем и близко не пахнет в NetApp FHCI), стек виртуализации AHV, Karbon (Kubernetes), Buckets (Object Storage / S3) и многое другое — они все хранят данные в _всегда консистентной_ NoSQL базе данных (доработанная Кассандра).
По сути коллеги из NetApp и «любимых партнеров» откровенную глупость пишут про «гиперконвергентные» и «неконсистентные»
…
Да, согласен. NetApp — нишевая стораж компания, которая полезла по сути туда где не имеет практически никаких шансов закрепиться. Cкупка устаревших сторонних технологий (например Solidfire) этому точно не поможет.
Про гиперскейлеров, которые дают клиентам (но не используют для своих задач) устаревшие СХД — ответ тоже очевиден, многие клиенты хотят то, к чему привыкли.
Мантра про «треубется shared storage» — крайне забавна. AWS например не предоставляет shared storage? Вы реально утверждаете что S3 например работает на NetApp? :)
«Объясню. У этих компаний контент распределяется по их кластерным файловым системам или БД с задержкой, это называется eventual consistency, которую на практике им невозможно достичь. „
Cадитесь, два балла. Перефразируя — “слышали звон, да не знаем где он».
Т.е. CAP теорема слышали, как работает на практике — не в курсе.
Коллеги из EMC и то грамотнее пишут «battle cards» — приложил скриншотик just for fun. Они на удивление оказались совершенно недалеки от правды.
Так вот — NoSQL, на которых работают Гуглы и Фейсбуки — совершенно спокойно может работать в CAp режиме когда требуется.
Та-же Cassandra (существенно доработанный движок в Нутаникс) по умолчанию действительно работает в cAP режиме (eventually consistenent), но Нутаникс-таки переделал в «always consistent» режим.
И кстати не только Нутаникс — у всех «крупняков» (кроме собственно несчастного Yahoo с Netapp) есть собственные NoSQL движки, работающие в том режиме который им нужен.
Но да, сделать самим такое, без остутствия опыта разработки в «гуглах и фейсбуках», практически невозможно.
Поэтому, если посмотреть внимательно вот сюда — единственный инфраструктурный вендор на NoSQL / Cassandra — это Нутаникс (кроме Cisco Webex, но это онлайн проект).
Да, ни у NetApp ни у других вендоров нет такого уровня разработчиков чтобы сделать правильный NoSQL движок, поэтому все работает по старинке.
p.s. Если кому-то интересно как решили проблему партиционирования при переводе движка в CAp — то «умный в гору не пойдет», смотрим Paxos Computer Science
FC вообще-то про традиционные решения, клиенты регулярно радуются байкам инженеров Netapp про то что FC SAN это быстро.
С iSCSI-же обычным все еще хуже — начиная с того что это не мультипоточный протокол (не путать с multipath).
По определению это не может эффективным быть в 2019 году, особенно на высоких скоростях (25/40/50/100 гигабит) — поэтому изобретаются костыли уровня NFS4.1 (pNFS) (который кстати netapp поддерживает для традиционных СХД) или весьма грамотно спроектированный MS SMB3.
Для Нутаникс это не проблема — отдельный iSCSI поток на каждый виртуальный диск (vdisk) внутри хоста (множественные подключения к Stargate на CVM), фактически архитектурно iSCSI превращен в мультипоточный протокол, без изменения самого протокола.
Если работает на узле скажем 100 VM с 2-я дисками, то будет 200 потоков iSCSI в пределах хоста.
Интер-коммуникации CVM тоже мультипоточные. При том что поддерживается и SMB3 и NFS (для других гипервизоров).
Для Solidfire — все очень грустно, ввиду того что архитектурно это не HCI и реально сервера просто работают с внешними all flash СХД.
Как вишенка на торт — Нутаникс может на каждый узел ставить 4x40G адаптера Мелланокс, Solidfire — максимум 2 адаптера по 25G.
С учетом отсутствия Data Locality на Netapp FHCI — нагрузка на сеть совсем грустной становится — 12xSSD дисков забивают 50 гигабит «влет».
Во-первых, всем спасибо за заряд хорошего настроения этим утром.
Упоминания Nutanix с первых же слов — безусловно приятно и правильно, правильно ориентироваться на безусловного лидера рынка.
Коллегам советую-таки изучить сначала архитектуру Nutanix, затем писать статьи.
К сожалению в статье очень много маркетинга, что в целом понятно — надо выдать «недо-HCI» архитектуру (для которой уже появилась юмористическая абрревиатура FHCI — Fake Hyper Convergent Infractucture) за реальную гиперконвергенцию.
В целом — масса недостоверных фактов, удобных умолчаний и прочих натягиваний ужа на ежа («в которой гипервизор Nutanix, теоретически может запускаться на NetApp HCI»).
Причем тут Кубернетис / микросервисы и гипервизор Nutanix — это видно пожалуй лишь авторам статьи.
Например — «скорость записей плюс минус в лучшем случае равносильна тому» — не в лучшем, а в худшем, ибо в целом практически всегда будет быстрее (см. ниже).
По поводу пути записи / задержек (I/O latency) — есть масса нюансов, о которых в статье почему-то не упомянуто.
1) Задержки FC SAN фабрики (смотрим задержки типовых SAN коммутаторов) — существенно выше чем хорошие сетевые коммутаторы (которые имеют задержки близкие к Infiniband). А фабрику вы обязательно будете строить в случае достаточно большого кластера.
Достаточно посмотреть нано секунды задержек типовых SAN коммутаторов и сравнить со скажем Mellanox или Arista Networks.
Именно поэтому ни одна из действительно крупных компаний (уровень Google, Facebook и прочие) не использует СХД или «псевдо-HCI», но создали для себя (внутреннее использование) реальный HCI.
Собственно, те-же инженеры и создавали Nutanix DFS — это публичная и широко известная история.
Кстати, интересный момент — на СХД NetApp сидел Yahoo, который в итоге проиграл технологическую войну Гуглу. Пока одни пытались использовать традиционные технологии, другии занимались инновациями.
2) В случае операций чтения, данные читаются с локальных SSD / NVMe дисков на максимальной скорости (локализация ввода-вывода), что технически невозможно для псевдо-HCI систем уровня Netapp. Можно применять костыли (ставить локально SSD в сервера для кэширования), но это именно что костыли с массой недостатков.
3) В лучшем случае, в идеальных условиях (100% запись, отсутствие SAN фабрики / прямое включение FC портов), традиционные СХД (включая Netapp и их псевдо-HCI), лишь приблизятся по скорости работы к грамотно спроективрованным настоящим HCI.
Учитывая что в реальной жизни в большинстве случаев если чтение даже превалирует над записью, то как минимум составляет существенную часть нагрузки. Это в итоге создает существенный реальный отрыв по производительности того-же Нутаникс — как мы уже показывали, легко можем выдать 1 million IOPS в одну виртуальную машину c ультра-низкими задержками.
4) Подтверждение записи от 2-х cетевых узлов в кластере идет одновременно, никто не ждет «сначала один потом другой».
5) Говорить про Netapp / Soliчdfire как нормальное решение в 2018 году — откровенно удивило.
Для наводки — максимальный размер LUN дл Netapp FHCI — 16TB. На дворе — 2019 год.
Говорить о том что в Nutanix нет LUN как таковых, а storage pool / container может быть петабайты — думаю смысла нет.
«что со «Скалой-Р» происходит заметно реже, чем в случае Nutanix и Simplivity»
В таких случаях обычно спрашивают координаты места и врача, где выдавали рецепт.
Типовая SLA всех клиентов нутаникс в мире — минимум 99.999% (5 минут «даунтайма» в год максимум), при легко достижимом 99.9999% (30 секунд в год).
Даже и статистика живая имеется — приложено (десятки тысяч кластеров в мире).
Не покажете статистику с тех нескольких инсталляций в РФ (про мир как-то даже неудобно спрашивать) по SLA?
«и при этом повлечет заметное снижение производительности» — приведите пожалуйста факты, а не ваши фантазии.
Просадка производительности Нутаникс даже при полном ребилде (после потери дисков / узлов) — минимальная, еще в 2014 году показывали.
На 2018 алогоритмы / производительность Nutanix ускорены во много раз. Ре-локализация даных — с точки зрения нагрузки вообще около нуля просадку дает.
Отдельно посмешили «дает юридические гарантии, прописывает это в предложениях» американские юридические гарантии в РФ.
Huawei на Dorado тоже обещает коэффициент. Далее, как и с pure — начинается много мелкого текста.
Если коротко — гарантия «5:1» на pure не работает, и в данный (нереалистичный) коэффициент включаются (тонкие, само собой) снапшоты и прочее, что позволяет искусственно раздуть цифры.
Максимум двухконтроллерная СХД? в 2017 году? Серьезно? ;)
А теперь о технике. C ней — достаточно грустно.
1) Pure — представитель стремительно устаревающей традиционной трехуровневой архитектуры.
Есть масса аналитики на эту тему, вся индустрия глобально уже уходит в HCI / Server SAN.
2) Доступ к данным через внешнюю сеть — фактически производительность SSD (и уж тем более NVMe) просто выкинута, ибо всегда будет упор как в контроллеры и интерфейсы ввода / вывода как серверов так и СХД.
3) Линейное масштабирование на Pure невозможно — «купите еще одну pure».
4) Локализация I/O невозможна (тесно связано со вторым пунктом)
5) Флеш используется копеечный (cMLC) — «customer grade», не «enterprise grade», отсюда и вся «щедрость» по апгрейду. То что pure публикует статьи где пытается рассказывать что customer grade ничуть не хуже enterprise grade (cMLC vs eMLC) — примерно как фраза «сколько ни говори сахар, во рту слаще не станет».
6) Уровень качества техподдержки, хотя и лучше традиционных вендоров, существенно отстает от лидеров рынка.
В целом можно еще пару десятков пунктов накидать, но в общем-то все понятно.
Почему Jet проталкивает устаревшие технологии — тоже понятно.
А так вообще-то есть расклад по рыночным долям HCI — и от Гартнера и от IDC. Цифры отличаются, но и по тем и другим — Nutanix + VMware лидеры с огромным отрывом, Cisco и остальные — даже не догоняющие, а жестко отставшие.
Cisco — маргиналы, около 5% всего доля (по IDC) и существенно меньше (по Гартнеру).
IDC:
Гартнер:
(Nutanix — 51%, VMware — 41%, все остальные маргиналы — 8%)
www.gartner.com/doc/3891878/market-share-analysis-data-center
Документ более чем полуторагодовалой давности приводить конечно можно, но это ни о чем реально не говорит.
Если судить по Magic Quadrant, Cisco не вошла в лидеры по HCI (имея крайне минорную / малозаметную долю на рынке), и находится где-то рядом с Huawei и Pivot3. О ком из них идет речь?
К сожалению, все ваши выкладки — в лучшем случае просто означают полное непонимание архитектуры. В худшем — осознанная попытка ввести в заблуждение. Solidfire кардинально проигрывает Nutanix с точки зрения эффективности использования пространства, ввиду того что не поддерживает EC-X и максимальный размер LUN всего 16TB.
«NetApp Cloud Volumes Service for AWS » — это прекрасно.
Внезапно, «NetApp Cloud Volumes» построены на NetApp.
Я бы реально удивился если бы они были построены на HPE 3par :)
Повторяю, цитата NetApp:
«NetApp Cloud Backup Service is an add-on feature for Cloud Volumes Service that delivers fully managed backup and restore capabilities for Cloud Volumes Service»
У AWS есть Cloud Volumes Service. Которые построены на технологиях AWS и там и близко не пахнет NetApp. Нетапу разрешили выпустить Add-On для Cloud Volumes Services, поэтому он и называется NetApp Cloud Volumes Service.
Это как примерно VMware начнет рассказывать что (им разрешили запускать ESXi на bare-metal instance i3 AWS) что AWS перешел на ESXi.
Далее — у нас здесь не разговор «обо всем на планете», но про HCI и FHCI.
Ваша заявка про «в 5 раз медленнее» не имеет никакого отношения к теме статьи, и в лучшем случае просто является попыткой наброса и ухода от темы.
Т.е. Solidfire не защищает / реплицирует данные? Правда? :)
“Новая это там где нужно в 3 раза больше накладных расходов по ёмкости » — извините, глупость. Solidfire существенно проигрывает по эффективной емкости. Как начнут поддерживать EC-X хотя-бы — приходите обратно, поговорим.
«Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?»
Вы про solidfire? Где стартовая конфигурация — минимум 4 узла СХД (с выкинутыми процессорами — фактически только под СХД) и 2 сервера, итого 6 узлов?
…
Пардон, но еще раз непрозрачно намекаю — чтобы не нести странности, изучите для начала хотя-бы минимум технологический
Технически / по делу есть что-то?
Да, про «Backups for NetApp Cloud Volumes Service for AWS» — как я понимаю, вы совершенно не понимаете о чем пишете.
Backups for NetApp Cloud Volumes Service for AWS — это AWS разрешила поверх своего HCI запускать ПО NetApp для тех клиентов кому это нужно.
Попытка выдать это как AWS использует NetApp для расширения — прекрасна в своей неразумности.
«he NetApp Cloud Backup Service is an add-on feature for Cloud Volumes Service that delivers fully managed backup and restore capabilities for Cloud Volumes Service»
add-on требуется перевод? ;)
В целом такое поведение называется «накинуть и попытаться отскочить».
«Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.»
Пардон — но это откровенная ерунда.
В контексте обсуждения (речь про HCI, FHCI и гиперскейлы) — вообще бессмыслица, ибо упомянутые «гиперскейлы» и Нутаникс обладают движками NoSQL с максимально высокой производительностью, надежностью и консистентностью данных на уровне наносекунд.
Современные динозавры рынка не только не обладают подобными технологиями, но и неспособны их создать.
Пойдем от обратного, как в анекдоте про Аленушку, чудовище заморское для утех и аленький цветочек.
Перечислите (например) сервисы AWS, которые предоставляют shared storage на NetApp.
Кстати, если долго говорить «сахар» — слаще не станет.
Первый же тотальный провал Yahoo при переходе Мариссы Мейер из Гугла — тотальная пролежка файлеров NetApp, с массой репутационных и финансовых потерь.
Собственно, как IMHO правильно пишут на tech crunch (ссылку давал выше) — одна из причин смерти Yahoo — устаревшие технологии NetApp / отсутствие инноваций.
«Building fast and building to last
At the beginning of the new millennium, Google and Yahoo started down very different paths to attain the enormous scale that the growing size and demands of the Internet economy (search, email, maps, etc.) required. For Yahoo, the solution came in the form of NetApp filers, which allowed the company to add server space at a dizzying rate. Almost every service that Yahoo offered ultimately ran on NetApp’s purpose-built storage appliances, which were quick to set up and easy to use, giving Yahoo a fast track to meet market demand (and soon made the company NetApp’s largest customer).
But in nearby Mountain View, Google began work on engineering its own software-defined infrastructure, ultimately known as the Google File System
…
Instead of using the latest storage appliances as a foundation, the Google File System used commodity servers to support a flexible and resilient architecture that could solve scalability and resiliency issues once and for all, „
Cобственно, NDFS (Nutanix DFS) и «Кассандра» (она же Medusa) — это DNA Нутаникс, на который все остальные «фича» навешаны — включая SDN (чем и близко не пахнет в NetApp FHCI), стек виртуализации AHV, Karbon (Kubernetes), Buckets (Object Storage / S3) и многое другое — они все хранят данные в _всегда консистентной_ NoSQL базе данных (доработанная Кассандра).
По сути коллеги из NetApp и «любимых партнеров» откровенную глупость пишут про «гиперконвергентные» и «неконсистентные»
…
Да, согласен. NetApp — нишевая стораж компания, которая полезла по сути туда где не имеет практически никаких шансов закрепиться. Cкупка устаревших сторонних технологий (например Solidfire) этому точно не поможет.
Ввиду Apache License — изменения сделанные в Кассандре отдавать обратно никто не обязан, иначе бы уже развелось клонов ;)
Мантра про «треубется shared storage» — крайне забавна. AWS например не предоставляет shared storage? Вы реально утверждаете что S3 например работает на NetApp? :)
Cадитесь, два балла. Перефразируя — “слышали звон, да не знаем где он».
Т.е. CAP теорема слышали, как работает на практике — не в курсе.
Коллеги из EMC и то грамотнее пишут «battle cards» — приложил скриншотик just for fun. Они на удивление оказались совершенно недалеки от правды.
Так вот — NoSQL, на которых работают Гуглы и Фейсбуки — совершенно спокойно может работать в CAp режиме когда требуется.
Та-же Cassandra (существенно доработанный движок в Нутаникс) по умолчанию действительно работает в cAP режиме (eventually consistenent), но Нутаникс-таки переделал в «always consistent» режим.
И кстати не только Нутаникс — у всех «крупняков» (кроме собственно несчастного Yahoo с Netapp) есть собственные NoSQL движки, работающие в том режиме который им нужен.
Но да, сделать самим такое, без остутствия опыта разработки в «гуглах и фейсбуках», практически невозможно.
Поэтому, если посмотреть внимательно вот сюда — единственный инфраструктурный вендор на NoSQL / Cassandra — это Нутаникс (кроме Cisco Webex, но это онлайн проект).
en.wikipedia.org/wiki/Apache_Cassandra
Да, ни у NetApp ни у других вендоров нет такого уровня разработчиков чтобы сделать правильный NoSQL движок, поэтому все работает по старинке.
p.s. Если кому-то интересно как решили проблему партиционирования при переводе движка в CAp — то «умный в гору не пойдет», смотрим Paxos Computer Science
https://en.wikipedia.org/wiki/Paxos_(computer_science)
Делаем 5 копий метаданных, если отказы нескольких колец Кассандры — это не проблема, легко и быстро восстанавливаются корректные данные.
С iSCSI-же обычным все еще хуже — начиная с того что это не мультипоточный протокол (не путать с multipath).
По определению это не может эффективным быть в 2019 году, особенно на высоких скоростях (25/40/50/100 гигабит) — поэтому изобретаются костыли уровня NFS4.1 (pNFS) (который кстати netapp поддерживает для традиционных СХД) или весьма грамотно спроектированный MS SMB3.
Для Нутаникс это не проблема — отдельный iSCSI поток на каждый виртуальный диск (vdisk) внутри хоста (множественные подключения к Stargate на CVM), фактически архитектурно iSCSI превращен в мультипоточный протокол, без изменения самого протокола.
Если работает на узле скажем 100 VM с 2-я дисками, то будет 200 потоков iSCSI в пределах хоста.
Интер-коммуникации CVM тоже мультипоточные. При том что поддерживается и SMB3 и NFS (для других гипервизоров).
Для Solidfire — все очень грустно, ввиду того что архитектурно это не HCI и реально сервера просто работают с внешними all flash СХД.
Как вишенка на торт — Нутаникс может на каждый узел ставить 4x40G адаптера Мелланокс, Solidfire — максимум 2 адаптера по 25G.
С учетом отсутствия Data Locality на Netapp FHCI — нагрузка на сеть совсем грустной становится — 12xSSD дисков забивают 50 гигабит «влет».
Упоминания Nutanix с первых же слов — безусловно приятно и правильно, правильно ориентироваться на безусловного лидера рынка.
Коллегам советую-таки изучить сначала архитектуру Nutanix, затем писать статьи.
К сожалению в статье очень много маркетинга, что в целом понятно — надо выдать «недо-HCI» архитектуру (для которой уже появилась юмористическая абрревиатура FHCI — Fake Hyper Convergent Infractucture) за реальную гиперконвергенцию.
Можно даже на русском — например www.nutanixbible.ru
В целом — масса недостоверных фактов, удобных умолчаний и прочих натягиваний ужа на ежа («в которой гипервизор Nutanix, теоретически может запускаться на NetApp HCI»).
Причем тут Кубернетис / микросервисы и гипервизор Nutanix — это видно пожалуй лишь авторам статьи.
Например — «скорость записей плюс минус в лучшем случае равносильна тому» — не в лучшем, а в худшем, ибо в целом практически всегда будет быстрее (см. ниже).
По поводу пути записи / задержек (I/O latency) — есть масса нюансов, о которых в статье почему-то не упомянуто.
1) Задержки FC SAN фабрики (смотрим задержки типовых SAN коммутаторов) — существенно выше чем хорошие сетевые коммутаторы (которые имеют задержки близкие к Infiniband). А фабрику вы обязательно будете строить в случае достаточно большого кластера.
Достаточно посмотреть нано секунды задержек типовых SAN коммутаторов и сравнить со скажем Mellanox или Arista Networks.
Именно поэтому ни одна из действительно крупных компаний (уровень Google, Facebook и прочие) не использует СХД или «псевдо-HCI», но создали для себя (внутреннее использование) реальный HCI.
Собственно, те-же инженеры и создавали Nutanix DFS — это публичная и широко известная история.
Кстати, интересный момент — на СХД NetApp сидел Yahoo, который в итоге проиграл технологическую войну Гуглу. Пока одни пытались использовать традиционные технологии, другии занимались инновациями.
Хорошая статья например тут:
techcrunch.com/2016/05/22/why-google-beat-yahoo-in-the-war-for-the-internet
2) В случае операций чтения, данные читаются с локальных SSD / NVMe дисков на максимальной скорости (локализация ввода-вывода), что технически невозможно для псевдо-HCI систем уровня Netapp. Можно применять костыли (ставить локально SSD в сервера для кэширования), но это именно что костыли с массой недостатков.
3) В лучшем случае, в идеальных условиях (100% запись, отсутствие SAN фабрики / прямое включение FC портов), традиционные СХД (включая Netapp и их псевдо-HCI), лишь приблизятся по скорости работы к грамотно спроективрованным настоящим HCI.
Учитывая что в реальной жизни в большинстве случаев если чтение даже превалирует над записью, то как минимум составляет существенную часть нагрузки. Это в итоге создает существенный реальный отрыв по производительности того-же Нутаникс — как мы уже показывали, легко можем выдать 1 million IOPS в одну виртуальную машину c ультра-низкими задержками.
longwhiteclouds.com/2017/11/14/1-million-iops-in-1-vm-world-first-for-hci-with-nutanix
4) Подтверждение записи от 2-х cетевых узлов в кластере идет одновременно, никто не ждет «сначала один потом другой».
5) Говорить про Netapp / Soliчdfire как нормальное решение в 2018 году — откровенно удивило.
Для наводки — максимальный размер LUN дл Netapp FHCI — 16TB. На дворе — 2019 год.
Говорить о том что в Nutanix нет LUN как таковых, а storage pool / container может быть петабайты — думаю смысла нет.
«что со «Скалой-Р» происходит заметно реже, чем в случае Nutanix и Simplivity»
В таких случаях обычно спрашивают координаты места и врача, где выдавали рецепт.
Типовая SLA всех клиентов нутаникс в мире — минимум 99.999% (5 минут «даунтайма» в год максимум), при легко достижимом 99.9999% (30 секунд в год).
Даже и статистика живая имеется — приложено (десятки тысяч кластеров в мире).
Не покажете статистику с тех нескольких инсталляций в РФ (про мир как-то даже неудобно спрашивать) по SLA?
«и при этом повлечет заметное снижение производительности» — приведите пожалуйста факты, а не ваши фантазии.
Просадка производительности Нутаникс даже при полном ребилде (после потери дисков / узлов) — минимальная, еще в 2014 году показывали.
На 2018 алогоритмы / производительность Nutanix ускорены во много раз. Ре-локализация даных — с точки зрения нагрузки вообще около нуля просадку дает.
www.nutanix.com/2014/03/03/nutanix-disk-self-healing-laser-surgery-vs-the-scalpel
При этом на «российской» Скала-Р — просадка достаточно катастрофическая может быть.
Про бум тестирования — позабавило ;) Вы с Jet работаете?
Huawei на Dorado тоже обещает коэффициент. Далее, как и с pure — начинается много мелкого текста.
Если коротко — гарантия «5:1» на pure не работает, и в данный (нереалистичный) коэффициент включаются (тонкие, само собой) снапшоты и прочее, что позволяет искусственно раздуть цифры.
А теперь о технике. C ней — достаточно грустно.
1) Pure — представитель стремительно устаревающей традиционной трехуровневой архитектуры.
Есть масса аналитики на эту тему, вся индустрия глобально уже уходит в HCI / Server SAN.
2) Доступ к данным через внешнюю сеть — фактически производительность SSD (и уж тем более NVMe) просто выкинута, ибо всегда будет упор как в контроллеры и интерфейсы ввода / вывода как серверов так и СХД.
3) Линейное масштабирование на Pure невозможно — «купите еще одну pure».
4) Локализация I/O невозможна (тесно связано со вторым пунктом)
5) Флеш используется копеечный (cMLC) — «customer grade», не «enterprise grade», отсюда и вся «щедрость» по апгрейду. То что pure публикует статьи где пытается рассказывать что customer grade ничуть не хуже enterprise grade (cMLC vs eMLC) — примерно как фраза «сколько ни говори сахар, во рту слаще не станет».
6) Уровень качества техподдержки, хотя и лучше традиционных вендоров, существенно отстает от лидеров рынка.
В целом можно еще пару десятков пунктов накидать, но в общем-то все понятно.
Почему Jet проталкивает устаревшие технологии — тоже понятно.
Конкретные факты:
1) доказана прямая связь и использование «прямо сейчас» ресурсов американских компаний Parallels и Virtuozzo.
2) Доказано что документация крайне свежая, исходя из чего заявление про «устаревшую документацию» — некорректно.
3) Ни одного конкретного опровержения ни одного из фактов из таблицы — не приведено.
Спасибо, было искренне забавно с вами общаться.