Комментарии 97
И когда виртуальная машина генерирует новую запись на локальный диск, всё бы было хорошо, если бы не нужно было эту запись синхронно продублировать и передать еще на второй сервер и дождаться ответа, что она находится в целости и сохранности. Другими словами, в Nutanix, да и в принципе любой share-nothing архитектуре, скорость записей плюс минус в лучшем случае равносильна тому, что эти записи были бы сразу переданы по сети на shared storage.
Вот это действительно важный момент, про который маркетинг умалчивает.
У них хотя бы есть «библия», где описано как работает Unified Cache.
А у Netapp вся техническая документация под NDA и маркетинг умалчивают значительно больше.
А у Netapp вся техническая документация под NDA и маркетинг умалчивают значительно больше.
Какой именно технической документации вам не хватает? Вроде уж чего-чего, а этого у нетапа завались
Да в половину статей как логиниться надо, иначе тайное знание не откроется.
Подробные офисания фичей и характеристики железок с филдпортала.
Куча документации с подробным описанием того как рабьотают технологии доступно в виде Technical Reports. К примеру TR-4476 про технологии эффективности. Характеристики оборудования доступны в hardware universe куда есть доступ у клиентов и партнёров.
Приходите в StorageDiscussions, вам там или документацию подкинут или объяснят без маркетинга.
Коллеги, а на кой чёрт вам меркетинговые материалы NetApp?
Я уверен что к маркетинговым материалам Nutanix у вас тоже нет доступа.
Дотошные характеристики железок на HWU.netapp.com
Я уверен что к маркетинговым материалам Nutanix у вас тоже нет доступа.
Дотошные характеристики железок на HWU.netapp.com
Где тут маркетинг? Я вижу подробное описание железок и характеристики, которых нет на HWU.
Боже, на кой чёрт вам этот документ? Что вам не хватает в характеристиках HWU?
Я вам еще раз говорю, что я просто уверен в том, что у нутаникса тоже есть такой же аналог fieldportal, к которому у вас тоже никто доступа нет.
Просто вы про fieldportal знаете.
Я вам еще раз говорю, что я просто уверен в том, что у нутаникса тоже есть такой же аналог fieldportal, к которому у вас тоже никто доступа нет.
Просто вы про fieldportal знаете.
Хочу всё знать! Про Нутаникс не скажу, но у IBM и Cisco в партнёрке только батлкарды с прайсами.
А docs с hwu тогда что? Там даже этого нет, лишь картинки как менять FRU и включать фичи в админмоде.
Это маркетинг. Картинки, слайды, собранная и пережёванная информация. Это не техническая документация.
А docs с hwu тогда что? Там даже этого нет, лишь картинки как менять FRU и включать фичи в админмоде.
Это конечно похвально.
Кстати хотел спросить, а зачем вам «всё знать» про вендора, которого вы упорно и всегда критикуете буквально в любой статье где речь заходит за NetApp, учитывая что он такой плохой?
Я так понимаю вы в интеграторе работаете и далеко не NetApp занимаетесь, правильно я понял?
У меня такое ощущение что «всё знать про NetApp» связано, особенно в маркетинговом плане, не просто с жаждой знаний.
Я так понимаю вы в интеграторе работаете и далеко не NetApp занимаетесь, правильно я понял?
У меня такое ощущение что «всё знать про NetApp» связано, особенно в маркетинговом плане, не просто с жаждой знаний.
Не угадали, я заказчик и пишу гадости про всех, так как считаю критику лучшим фидбеком.
Тоже вариант
Виссарион Григорьевич Белинский едет по вечернему Петербургу на извозчике. Извозчик видит — барин незаносчив, из простых, пальтишко на нём худое, фуражечка, — в общем, можно поговорить. Спрашивает:
— Ты, барин, кем будешь?
— А я, братец, литературный критик.
— А это, к примеру, что ж такое?
— Ну вот писатель напишет книжку, а я ее ругаю…
Извозчик чешет бороду, кряхтит:
— Ишь, говна какая…
— Ты, барин, кем будешь?
— А я, братец, литературный критик.
— А это, к примеру, что ж такое?
— Ну вот писатель напишет книжку, а я ее ругаю…
Извозчик чешет бороду, кряхтит:
— Ишь, говна какая…
Таки да. Это маркетинг. Картинки, слайды, собранная и пережёванная информация. Это не техническая документация.
Техническая документация без слайдиков и не из 100 страниц картинок, а 300 страниц сухого технического текста который рассказывает всё как есть без предвзятости, прикрас и маркетинга здесь
docs.netapp.com/ontap-9
Техническая документация без слайдиков и не из 100 страниц картинок, а 300 страниц сухого технического текста который рассказывает всё как есть без предвзятости, прикрас и маркетинга здесь
docs.netapp.com/ontap-9
«Login to continue»
Вообще логиниться по каждому чиху очень мешает работе.
А политика «зайдите на такой то канал вам там все разжуют» — такое…
Вообще логиниться по каждому чиху очень мешает работе.
А политика «зайдите на такой то канал вам там все разжуют» — такое…
Вы куда-то не туда смотрите. Вот куча открытой и технической документации.
docs.netapp.com/ontap-9
docs.netapp.com/ontap-9
Да, к сожалению открытостью документации NetApp похвастать не может.
Не то что не «умалчивает», а пишет (о том, как производится запись на диски в Nutanix HCI)всюду, включая и на русском, ссылки ниже.
Но тут конечно есть некоторая манипуляция в форме передергивания. Потому что вот в той форме, как у Евгения конечно не пишет, потому что это неправда.
Но тут конечно есть некоторая манипуляция в форме передергивания. Потому что вот в той форме, как у Евгения конечно не пишет, потому что это неправда.
Рома, ну ты сам прекрастно видишь, что все бегают с этими лозунгами «локальные диски быстрее», как обычно оставив в стороне «технические детали». Просто пора уже придумывать новые лозунги, эти устарели ;)
PS. Эта фраза больше не Женина, а моя.
PS. Эта фраза больше не Женина, а моя.
Слушайте, вы выдумываете проблему, а потом говорите, «ну, вот, проблема, видите»?
Если есть абстрактный «инженер», который не знает и не интересуется «техническими деталями», то проблема в этом «инженере», и в узости его понимания, а совсем не в Nutanix, при чем здесь мы-то?
Вы берете некоего абстрактного человека, который «бегает», а виноваты в этом мы?
Повторяю, в статье много от простого непонимания до передергивания, и это неприятно, потому что garbage-in garbage-out. Представьте статью про NetApp, в которой автор говорит: «Ну, так как всем известно, что LUN в NetApp это файловая эмуляция, а потому априори проигрывает нативному блочному доступу...» и дальше две страницы текста и выводов, основанных на этом заблуждении, это что? Это мусор с самого начала. Вот и тут та же история.
Если есть абстрактный «инженер», который не знает и не интересуется «техническими деталями», то проблема в этом «инженере», и в узости его понимания, а совсем не в Nutanix, при чем здесь мы-то?
Вы берете некоего абстрактного человека, который «бегает», а виноваты в этом мы?
Повторяю, в статье много от простого непонимания до передергивания, и это неприятно, потому что garbage-in garbage-out. Представьте статью про NetApp, в которой автор говорит: «Ну, так как всем известно, что LUN в NetApp это файловая эмуляция, а потому априори проигрывает нативному блочному доступу...» и дальше две страницы текста и выводов, основанных на этом заблуждении, это что? Это мусор с самого начала. Вот и тут та же история.
Во-первых, всем спасибо за заряд хорошего настроения этим утром.
Упоминания 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 с первых же слов — безусловно приятно и правильно, правильно ориентироваться на безусловного лидера рынка.
Коллегам советую-таки изучить сначала архитектуру 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 может быть петабайты — думаю смысла нет.
Достойный комментарий, жаль, что половину его можно было не писать, если для сначала разобраться, что SolidFire работает по iSCSI и FC там вообще никаким боком не участвует.
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 гигабит «влет».
С 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 гигабит «влет».
Можно подробнее про не мультипоточность iSCSI? Особенно в свете того, что можно создавать множество сессий к одним и тем же ресурсам.
А почему выше было про миллионы IOPS, а теперь мы пришли к поточной нагрузке?
Вообще меряться скоростью портов достаточно странное занятие, только в очень редких и весьма специфических случаях узким местом становится ширина канала. В случае со случайными нагрузками мелкими и средними блоками это вообще неважно.
Я правильно понял, что для репликации записи на второую ноду в Nutanix используется iSCSI?
Например — «скорость записей плюс минус в лучшем случае равносильна тому» — не в лучшем, а в худшем
Нет, таки в лучшем уважаемый коллега. Почему? Всё просто: replication factor 3. Нужно реплику не на один, а на два внешних сервера слать, да, они шлются параллельно, но разные сервера по-разному нагружены, мало того, что там «сторедж функция», так там ещё и компьютинг крутится, поэтому один из этих серверов может быть более занят чем другой. Плюс получается по сети в два раза больше внутреннего трафика бегает и вместо 2 нод так у вас еще и третья задействована. Это всё дополнительные накладные расходы. Именно поэтому применено выражение «в лучшем случае».
А вот в случае replication factor 2, то будет ровно тоже самое, как если бы система была подключена по сети откинуть влияние нагрузки серверов задачами от виртуальных машин. Эти нюансы вылазят именно из-за shared-nothing архитектуры и никуда от них ни деться. Это ни плохо и ни хорошо, они просто есть и про это нужно знать.
И вообще я Nutanix обидеть не хотел, заслуженная и уважаемая HCI архитектура. Но нужно расставить всё по своим местам, потому что даже при наличии «Библии Nutanix», всё равно некоторые инженеры думают, что записи пишутся исключительно локально, чего архитектура себе позволить не может при всём желании, далее делая из этого не правильные умозаключения, что говорит о том, как обычно техническую документацию никто не читает, а просто «борются на словах» не верными, маркетинговыми идеями.
Касательно Гугла и FB и гиперскейлеров.
У этих компаний другая постановка задачи, которая выливается в то, как у них построена внутренняя архитектура под эту задачу и как результат что они для этой задачи используют. И это отнюдь не связано с тем, что shared-nothing архитектура априори лучше и быстрее. Объясню. У этих компаний контент распределяется по их кластерным файловым системам или БД с задержкой, это называется eventual consistency, которую на практике им невозможно достичь. На пальцах: из-за eventual consistency разным пользователям в разных регионах, в поиске гугла/ФБ могут «не доползать» некоторые новые статьи. Но какая разница для пользователя, если он недополучит пару новых статей и вместо них будут другие тоже релевантные для поиска, но просто немного более старые статьи, если у него результат поиска и так состоит из релевантных 10 страниц, на каждой по 10 ссылок. Пользователь просто не заменит этой разницы или она будет не существенна и для бизнеса ФБ/Гугл это приемлемо и не критично.
Благодаря принципу eventual consistency, они могут не покупать промышленные системы хранения под описанные выше задачи, а использовать свою кластерную ФС/БД вместо этого, потому что им это может позволить сама постановка задачи. И не забывайте про армию программистов, которые постоянно допиливают эти алгоритмы.
При том в инфраструктуре с приложениями, к примеру виртуальными машинами, вы не можете себе позволить eventual consistency, это просто не из того мира функционал. Если у вас умирает один сервер с кучей виртуалок, а на второй сервер ещё не успели докатиться самые последние данные, у вас будет куча повреждённых виртуалок. Другими словами вам необходимо синхронно реплицировать данные и ярким примером тому является Nutanix.
А теперь давайте про гиперскейлеров. Оборудование (или софт) NetApp есть в таких гиперскейлерах как Azure, Amazon AWS, Google Cloud, Rackspace, IBM Cloud (и на этом список не заканчивается на самом деле) и доступно как сервис для конечных потребителей. Почему? Да потому что есть много задач в которых shared storage показывает необходим, имеет много функционала и показывает себя с очень хорошей стороны. Иначе бы NetApp не появился у них в ЦОДах.
У этих компаний другая постановка задачи, которая выливается в то, как у них построена внутренняя архитектура под эту задачу и как результат что они для этой задачи используют. И это отнюдь не связано с тем, что shared-nothing архитектура априори лучше и быстрее. Объясню. У этих компаний контент распределяется по их кластерным файловым системам или БД с задержкой, это называется eventual consistency, которую на практике им невозможно достичь. На пальцах: из-за eventual consistency разным пользователям в разных регионах, в поиске гугла/ФБ могут «не доползать» некоторые новые статьи. Но какая разница для пользователя, если он недополучит пару новых статей и вместо них будут другие тоже релевантные для поиска, но просто немного более старые статьи, если у него результат поиска и так состоит из релевантных 10 страниц, на каждой по 10 ссылок. Пользователь просто не заменит этой разницы или она будет не существенна и для бизнеса ФБ/Гугл это приемлемо и не критично.
Благодаря принципу eventual consistency, они могут не покупать промышленные системы хранения под описанные выше задачи, а использовать свою кластерную ФС/БД вместо этого, потому что им это может позволить сама постановка задачи. И не забывайте про армию программистов, которые постоянно допиливают эти алгоритмы.
При том в инфраструктуре с приложениями, к примеру виртуальными машинами, вы не можете себе позволить eventual consistency, это просто не из того мира функционал. Если у вас умирает один сервер с кучей виртуалок, а на второй сервер ещё не успели докатиться самые последние данные, у вас будет куча повреждённых виртуалок. Другими словами вам необходимо синхронно реплицировать данные и ярким примером тому является Nutanix.
А теперь давайте про гиперскейлеров. Оборудование (или софт) NetApp есть в таких гиперскейлерах как Azure, Amazon AWS, Google Cloud, Rackspace, IBM Cloud (и на этом список не заканчивается на самом деле) и доступно как сервис для конечных потребителей. Почему? Да потому что есть много задач в которых shared storage показывает необходим, имеет много функционала и показывает себя с очень хорошей стороны. Иначе бы 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, но это онлайн проект).
en.wikipedia.org/wiki/Apache_Cassandra
Да, ни у NetApp ни у других вендоров нет такого уровня разработчиков чтобы сделать правильный NoSQL движок, поэтому все работает по старинке.
p.s. Если кому-то интересно как решили проблему партиционирования при переводе движка в CAp — то «умный в гору не пойдет», смотрим Paxos Computer Science
https://en.wikipedia.org/wiki/Paxos_(computer_science)
Делаем 5 копий метаданных, если отказы нескольких колец Кассандры — это не проблема, легко и быстро восстанавливаются корректные данные.
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 копий метаданных, если отказы нескольких колец Кассандры — это не проблема, легко и быстро восстанавливаются корректные данные.
Если вкльюить режим консистентности «когда нужно», получается просадка в производительности в 5 раз ;)
В Нутаникс режим консистентности включен _всегда_. Его невозможно выключить. При максимально высокой производительности.
Ввиду Apache License — изменения сделанные в Кассандре отдавать обратно никто не обязан, иначе бы уже развелось клонов ;)
Ввиду Apache License — изменения сделанные в Кассандре отдавать обратно никто не обязан, иначе бы уже развелось клонов ;)
О боже. У вас какой-то режим защиты нутаникса включился неадекватный.
Никто и не говорил про ваш нутаникс. Понятное дело что в Нутаниксе он включён всегда, иначе быть не может.
Я говорю без привязки к Nutanix, если в NoSQL BD такой как MongoDB (подозреваю что в Касандре будет аналогичная картина) включить режим консистентности, то там просядет производительность в 5 раз по сравнению с той же самой БД, только с eventual consistency. Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.
Никто и не говорил про ваш нутаникс. Понятное дело что в Нутаниксе он включён всегда, иначе быть не может.
совершенно спокойно может работать в CAp режиме когда требуется.
Я говорю без привязки к Nutanix, если в NoSQL BD такой как MongoDB (подозреваю что в Касандре будет аналогичная картина) включить режим консистентности, то там просядет производительность в 5 раз по сравнению с той же самой БД, только с eventual consistency. Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.
Вы уж сэр определитесь. Внезапно — вдруг как бы закинутое про «в 5 раз медленнее» — уже Нутаникса и не касается (хорошо что хотя бы это открыто признали).
В целом такое поведение называется «накинуть и попытаться отскочить».
«Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.»
Пардон — но это откровенная ерунда.
В контексте обсуждения (речь про HCI, FHCI и гиперскейлы) — вообще бессмыслица, ибо упомянутые «гиперскейлы» и Нутаникс обладают движками NoSQL с максимально высокой производительностью, надежностью и консистентностью данных на уровне наносекунд.
Современные динозавры рынка не только не обладают подобными технологиями, но и неспособны их создать.
В целом такое поведение называется «накинуть и попытаться отскочить».
«Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.»
Пардон — но это откровенная ерунда.
В контексте обсуждения (речь про HCI, FHCI и гиперскейлы) — вообще бессмыслица, ибо упомянутые «гиперскейлы» и Нутаникс обладают движками NoSQL с максимально высокой производительностью, надежностью и консистентностью данных на уровне наносекунд.
Современные динозавры рынка не только не обладают подобными технологиями, но и неспособны их создать.
Да я опредилился. И повторяю вам еще раз, вы сами начали разговор за консистентность в базах данных и про то что его «можно включить если нужно», я его и продолжил. И этот трэд он был конкретно в тему про гиперскейлеров которые юзают файловые системы и баз данных с cогласованностью в конечном счёте (когда нибудь, может быть) и не юзают стореджи.
Я вам здесь и говорю не за ваш нутаникс, а за эти вот NoSQL базы данных. А вы всё со своим режимом защиты нутаникса, на свой счёт принимаете. Читайте внимательнее и отключите свой режим защиты нутаникса.
Это не ерунда, а правда жизни. Когда Вы включаете консистентность в моднго ДБ палает перфоменс в 5 раз. Когда отключаете, выростает. Это плата за консистентность и я говорю что эта плата она всегда есть. Я сейчас про БД, не про ваш нутаникс, если что.
Я вам здесь и говорю не за ваш нутаникс, а за эти вот NoSQL базы данных. А вы всё со своим режимом защиты нутаникса, на свой счёт принимаете. Читайте внимательнее и отключите свой режим защиты нутаникса.
Это не ерунда, а правда жизни. Когда Вы включаете консистентность в моднго ДБ палает перфоменс в 5 раз. Когда отключаете, выростает. Это плата за консистентность и я говорю что эта плата она всегда есть. Я сейчас про БД, не про ваш нутаникс, если что.
«а за эти вот NoSQL базы данных» — для начала, я крайне сомневаюсь что вы адекватно способны рассуждать про «эти вот NoSQL».
Далее — у нас здесь не разговор «обо всем на планете», но про HCI и FHCI.
Ваша заявка про «в 5 раз медленнее» не имеет никакого отношения к теме статьи, и в лучшем случае просто является попыткой наброса и ухода от темы.
Далее — у нас здесь не разговор «обо всем на планете», но про HCI и FHCI.
Ваша заявка про «в 5 раз медленнее» не имеет никакого отношения к теме статьи, и в лучшем случае просто является попыткой наброса и ухода от темы.
Тю, так вы же сами эту тему поднялии. Ну ладно, нет так нет.
Ой, как мне нравится как вы в каждом своём посте методично не забываете писать про Fake HCI. Жалко в Хабре хэштегов нет в комментариях…
А можно вас попросить в каждом своём комментарии к этой статье ставить хэштег #FHCI, мне так веселее будет?
Ой, как мне нравится как вы в каждом своём посте методично не забываете писать про Fake HCI. Жалко в Хабре хэштегов нет в комментариях…
А можно вас попросить в каждом своём комментарии к этой статье ставить хэштег #FHCI, мне так веселее будет?
Ну так NetApp не на том уровне бизнес ведёт, чтобы глубоко лезть в разработку Casandra.
Собственно вот вы сами и пришли к тому, что я сказал, что Nutanix интерестен своей внутренней экосистемой, а не устройством стореджа.
Собственно вот вы сами и пришли к тому, что я сказал, что Nutanix интерестен своей внутренней экосистемой, а не устройством стореджа.
Устройство «стоража» в данном случае — ключевой момент, ибо позволяет при сохранении ультра-высокой надежности — практически безлимитно масштабироваться — как по скорости так и емкости.
Cобственно, NDFS (Nutanix DFS) и «Кассандра» (она же Medusa) — это DNA Нутаникс, на который все остальные «фича» навешаны — включая SDN (чем и близко не пахнет в NetApp FHCI), стек виртуализации AHV, Karbon (Kubernetes), Buckets (Object Storage / S3) и многое другое — они все хранят данные в _всегда консистентной_ NoSQL базе данных (доработанная Кассандра).
По сути коллеги из NetApp и «любимых партнеров» откровенную глупость пишут про «гиперконвергентные» и «неконсистентные»
…
Да, согласен. NetApp — нишевая стораж компания, которая полезла по сути туда где не имеет практически никаких шансов закрепиться. Cкупка устаревших сторонних технологий (например Solidfire) этому точно не поможет.
Cобственно, NDFS (Nutanix DFS) и «Кассандра» (она же Medusa) — это DNA Нутаникс, на который все остальные «фича» навешаны — включая SDN (чем и близко не пахнет в NetApp FHCI), стек виртуализации AHV, Karbon (Kubernetes), Buckets (Object Storage / S3) и многое другое — они все хранят данные в _всегда консистентной_ NoSQL базе данных (доработанная Кассандра).
По сути коллеги из NetApp и «любимых партнеров» откровенную глупость пишут про «гиперконвергентные» и «неконсистентные»
…
Да, согласен. NetApp — нишевая стораж компания, которая полезла по сути туда где не имеет практически никаких шансов закрепиться. Cкупка устаревших сторонних технологий (например Solidfire) этому точно не поможет.
Необходимость реплицировать данные между нодами и есть лимит в данной архитектуре. По этому на практике лимит будет, точнее он есть.
А что такое устаревшая технология в данном случае и что есть новая технология? Новая это там где нужно в 3 раза больше накладных расходов по ёмкости и там где в два раза больше накладных расходов на cross-talsk между нодами кластера при записи? Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?
В то время как в древнем ONTAP все данные пишуться на ноду которая владеет этим вольюмом и только при аварии переключается и соответственно не жрёт ни рисурсов соседного контроллера ни дополнительных расходов на сеть?
И что значит не поможет, вы в будущем были, у вас машина времени? Давайте дождёмся этого будущего и посмотрим, а не будем выдавать желаемое за действительное. Я к примеру, свои два предсказания сделал потому что уже 7 лет этими устройствами занимаюсь и знаю как оно устроено и куда движется, и громких заявлений типа «нутаникс умрёт и ничто ему не поможет» не делаю.
А что такое устаревшая технология в данном случае и что есть новая технология? Новая это там где нужно в 3 раза больше накладных расходов по ёмкости и там где в два раза больше накладных расходов на cross-talsk между нодами кластера при записи? Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?
В то время как в древнем ONTAP все данные пишуться на ноду которая владеет этим вольюмом и только при аварии переключается и соответственно не жрёт ни рисурсов соседного контроллера ни дополнительных расходов на сеть?
И что значит не поможет, вы в будущем были, у вас машина времени? Давайте дождёмся этого будущего и посмотрим, а не будем выдавать желаемое за действительное. Я к примеру, свои два предсказания сделал потому что уже 7 лет этими устройствами занимаюсь и знаю как оно устроено и куда движется, и громких заявлений типа «нутаникс умрёт и ничто ему не поможет» не делаю.
«Необходимость реплицировать данные между нодами и есть лимит в данной архитектуре. „
Т.е. Solidfire не защищает / реплицирует данные? Правда? :)
“Новая это там где нужно в 3 раза больше накладных расходов по ёмкости » — извините, глупость. Solidfire существенно проигрывает по эффективной емкости. Как начнут поддерживать EC-X хотя-бы — приходите обратно, поговорим.
«Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?»
Вы про solidfire? Где стартовая конфигурация — минимум 4 узла СХД (с выкинутыми процессорами — фактически только под СХД) и 2 сервера, итого 6 узлов?
…
Пардон, но еще раз непрозрачно намекаю — чтобы не нести странности, изучите для начала хотя-бы минимум технологический
Т.е. Solidfire не защищает / реплицирует данные? Правда? :)
“Новая это там где нужно в 3 раза больше накладных расходов по ёмкости » — извините, глупость. Solidfire существенно проигрывает по эффективной емкости. Как начнут поддерживать EC-X хотя-бы — приходите обратно, поговорим.
«Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?»
Вы про solidfire? Где стартовая конфигурация — минимум 4 узла СХД (с выкинутыми процессорами — фактически только под СХД) и 2 сервера, итого 6 узлов?
…
Пардон, но еще раз непрозрачно намекаю — чтобы не нести странности, изучите для начала хотя-бы минимум технологический
Если мы говорим уже за SF, то там тоже, на подобии как в Nutanix есть репликация между нодами по сети. Ключевое слово тоже, так что не нужно тут пытаться опять песни петь про локальные диски и православные локальные записи. Вы как-то внезапно на SF переключились, хотя говорили мы про ONTAP & AFF и NoSQL, ну да ладно.
Да, в NetApp HCI/SF нужно по сути минимум две ноды SF и две ноды серверов, итого 4ре, а 10 версии прошивки нужно минимум 4 ноды SF. Я об этом честно пишу. Но опять таки уменьшаем/увеличиваем количество нод, что будет с нутаниксом? Потеряем пространство если нужно уменьшить компьютин, если нужно увеличить компьютинг — автоматом добавим пространство, нужно оно или нет, а добавить обязан. В архитектуре NetApp HCI компьютинг и пространство могут уменьшаться/расти независимо.
Ох уж этот режим защиты нутаникс. Всех порву. Все дураки. Один я дартаньян потому что читал биболию нутаникс.
EC-X это конечно классная штука. Сначала делаем replication factor 3, магко говоря охреневаем от оверхэдов как по пространству, так и по сети. А потом такие, «а давайте ка мы Eresure Coding по сети на продуктив натянем» (С)? Экономия! Только перфоменс гуляет лесом. Потому что это обратная строна медали EC. Когда у тебя есть опции, это говорит, что технология имеет недостатки, где выбор и принятие между несколькими обоими плохими решениями перелаживаются на плечи заказчика. Хотите безопасность — ставьте репликацию 3 (и охреневайте от оверхэдов), хотите сэкономитть, ставьте 2, хотите сильнее сэкономить, ставьте EC (и охреневайте от performance impact)! И каждый из этих вариантов со смоими проблемами.
Сделал себе проблему, а потом героически решил, точнее дал ложный выбор. А потом ещё сказать, а у вас в SF нет такой штуки как EC! Круто.
Да, в NetApp HCI/SF нужно по сути минимум две ноды SF и две ноды серверов, итого 4ре, а 10 версии прошивки нужно минимум 4 ноды SF. Я об этом честно пишу. Но опять таки уменьшаем/увеличиваем количество нод, что будет с нутаниксом? Потеряем пространство если нужно уменьшить компьютин, если нужно увеличить компьютинг — автоматом добавим пространство, нужно оно или нет, а добавить обязан. В архитектуре NetApp HCI компьютинг и пространство могут уменьшаться/расти независимо.
Ох уж этот режим защиты нутаникс. Всех порву. Все дураки. Один я дартаньян потому что читал биболию нутаникс.
EC-X это конечно классная штука. Сначала делаем replication factor 3, магко говоря охреневаем от оверхэдов как по пространству, так и по сети. А потом такие, «а давайте ка мы Eresure Coding по сети на продуктив натянем» (С)? Экономия! Только перфоменс гуляет лесом. Потому что это обратная строна медали EC. Когда у тебя есть опции, это говорит, что технология имеет недостатки, где выбор и принятие между несколькими обоими плохими решениями перелаживаются на плечи заказчика. Хотите безопасность — ставьте репликацию 3 (и охреневайте от оверхэдов), хотите сэкономитть, ставьте 2, хотите сильнее сэкономить, ставьте EC (и охреневайте от performance impact)! И каждый из этих вариантов со смоими проблемами.
Сделал себе проблему, а потом героически решил, точнее дал ложный выбор. А потом ещё сказать, а у вас в SF нет такой штуки как EC! Круто.
Про гиперскейлеров, которые дают клиентам (но не используют для своих задач) устаревшие СХД — ответ тоже очевиден, многие клиенты хотят то, к чему привыкли.
Мантра про «треубется shared storage» — крайне забавна. AWS например не предоставляет shared storage? Вы реально утверждаете что S3 например работает на NetApp? :)
Мантра про «треубется shared storage» — крайне забавна. AWS например не предоставляет shared storage? Вы реально утверждаете что S3 например работает на NetApp? :)
Ну при чём же здесь S3. Он преспокойно себе живет и работает на комодити оборудовании. Иногда работает, иногда не работает. Но опять таки постановка задачи у него «дешевое» и надёжное хранилище данных (про доступность этих данных умалчиваем). Которое кстати под задачи виртуальных машин и задачи баз данных использовать не возможно. Потому что протокол в основном заточен на то чтобы туда один раз записали и много раз читали. Или подождали пару часиков и прочитали ;)
Хорошо. Тяжело вздыхаем, идем длинным путем.
Пойдем от обратного, как в анекдоте про Аленушку, чудовище заморское для утех и аленький цветочек.
Перечислите (например) сервисы 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, „
Пойдем от обратного, как в анекдоте про Аленушку, чудовище заморское для утех и аленький цветочек.
Перечислите (например) сервисы 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, „
Ох уж этот NetApp со своими устаревшими технологиями!
Ох уж эти AWS, Azure, Google Cloud, IBM Cloud, Rackspace (и скоро ждите еще одного крупного играка), все хотят напродавать своим заказчикам этот поганый и устаревший NetApp своим заказчикам, а сами то посмотрите, сами то его не используют!
Всё строют и строют свои датацентры, расширяют покрытие со своими сутаревшими технологиями.
Это никак иначе как глобальный сговор буржуев против православного нутаникса!
Предлагаю выключить режим всезнайки,- плохо получается.
Ох уж эти AWS, Azure, Google Cloud, IBM Cloud, Rackspace (и скоро ждите еще одного крупного играка), все хотят напродавать своим заказчикам этот поганый и устаревший NetApp своим заказчикам, а сами то посмотрите, сами то его не используют!
Всё строют и строют свои датацентры, расширяют покрытие со своими сутаревшими технологиями.
Это никак иначе как глобальный сговор буржуев против православного нутаникса!
Предлагаю выключить режим всезнайки,- плохо получается.
Понятно, кого-то понесло.
Технически / по делу есть что-то?
Да, про «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 требуется перевод? ;)
Технически / по делу есть что-то?
Да, про «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 требуется перевод? ;)
Я вам технически уже выложил выше. И про репликацию по сети и про в 3 раза больше ёмкости и про архитектурные ограничения.
И читайте внимательнее там есть запятая и слово «and» в заголовке.
Чтобы вы били в курсе, NetApp Cloud Volumes Service for AWS построены на «устаревших» NetApp AFF, в октябре добавили 8 новых регионов.
И читайте внимательнее там есть запятая и слово «and» в заголовке.
Чтобы вы били в курсе, NetApp Cloud Volumes Service for AWS построены на «устаревших» NetApp AFF, в октябре добавили 8 новых регионов.
«Я вам технически уже выложил выше.»
К сожалению, все ваши выкладки — в лучшем случае просто означают полное непонимание архитектуры. В худшем — осознанная попытка ввести в заблуждение. 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 кардинально проигрывает 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.
Ой, так напишите статью на хабре про архитектуру и как в вашем нутаниксе операции записи на соседние ноды телепортируются без использования сети. И как они не занимают в 3 раза больше ёмкости с фактором репликации 3.
Я плачу. Просто плачу катаясь под столом. Вы ж вроде в Англии живёте. Читать на ангицком должны уметь. А ещё меня учить хотели.
Всё уже, прочитали, поняли, о чём в той статье говорилось? Что там про Cloud Volumes Service (Читай NetApp AFF), что это не исключительно речь про бэкапы, они как бы тоже (also) есть. И что в 8 новых регионах этот сервис с «устаревшими технологиями» NetApp AFF открыли. не с нутаниксом почему-то…
Ах да. Буржуи. Заговор… и не забываем добавить, то что NetApp ничего не спасёт.
Всё уже, прочитали, поняли, о чём в той статье говорилось? Что там про Cloud Volumes Service (Читай NetApp AFF), что это не исключительно речь про бэкапы, они как бы тоже (also) есть. И что в 8 новых регионах этот сервис с «устаревшими технологиями» NetApp AFF открыли. не с нутаниксом почему-то…
Ах да. Буржуи. Заговор… и не забываем добавить, то что NetApp ничего не спасёт.
Навеяно одним из основныз посылов статьи. Было бы интересно получить от обоих уважаемых вендоров перечень фич, которые с их точки зрения интересны сервис-провайдерам под раздачу виртуалок. Сегмент на который целится SP — B2E.
NetApp HCI:
Возможность независимого масштабирования compute и storage составляющих.
Автоматизация и интеграция с чем угодно — API, Trident (volume плагин для k8s и docker), OpenStack драйвер и т.д.
QoS — min, max, burst. Любые тома всегда создаются с QoS политикой.
Гарантированная эфективность 4:1 для Private Cloud, IaaS. Не учитываются клоны, снепшоты и т.д. Если эффективность оказывается меньше, вендор отружает дополнительное железо.
Это же всё фичи SF, в каком месте там HCI?
Без подколок, мне действительно интересно какие преимущества даёт NetApp HCI перед своими серверами + SolidFire + лицензии на vSphere. Кроме визарда длядебилов первичной настройки и поддержки из одного корыта.
Без подколок, мне действительно интересно какие преимущества даёт NetApp HCI перед своими серверами + SolidFire + лицензии на vSphere. Кроме визарда для
А какие преимущества даёт любоё HCI решение в сравнении с своими серверами+СХД+гипервизор?
навскидку —
Масштабируемость
управляемость из одной точки + api
Саппорт в «одном окне» (это как правило уже)
отказоустойчивость выше
Накладные расходы меньше (No SAN, 1/10/25/40G Ethernet only)
чаще всего — дешевле классического аналога (за комплект).
Масштабируемость
управляемость из одной точки + api
Саппорт в «одном окне» (это как правило уже)
отказоустойчивость выше
Накладные расходы меньше (No SAN, 1/10/25/40G Ethernet only)
чаще всего — дешевле классического аналога (за комплект).
чаще всего — дешевле классического аналога (за комплект)
Это спорно :) На чем же тогда вендор HCI зарабатывает?
отказоустойчивость выше
За счёт чего?
Масштабируемость у NetApp HCI до 40 storage нод и до 64 compute.
Можно без проблем убирать ноды из существуещего кластера и, например, собирать из них другой кластер на удаленной площадке.
Про API уже писал, всё управление из vCenter происходит. Поддержка на всё от NetApp. В том числе на коммутаторы и VMware.
То есть это реинкарнация FlexPod с масштабируемым сториджем?
Любое HCI не интересно, вопрос был конкретно про value от покупки NetApp HCI.
А какие преимущества даёт любоё HCI решение в сравнении с своими серверами+СХД+гипервизор?
Любое HCI не интересно, вопрос был конкретно про value от покупки NetApp HCI.
Выгоду от покупки NetApp HCI я уже описал, да по большой части это те преимущества, которые получены благодаря SolidFire. Для этого их и покупали.
То что SolidFire доступен как отдельный продукт говорит о том, что вендор видит в нем востребованность и понимает как на нём зарабатывать в отрыве от HCI.
Это спорно :) На чем же тогда вендор HCI зарабатывает
Так себест тоже ниже получается, основная цена у HCI — в софте же…
отказоустойчивость выше
На основе чего сделан данный вывод? Я не тролю, просто интересно мнение.
Накладные расходы меньше (No SAN, 1/10/25/40G Ethernet only)
Чем плох SAN? Тесты NVMEoF видели?
Меньше сущностей — от того и выше.
И да, SAN сам по себе ничем не плох. Как вобщем и Nokia 3310 :)
работает справно, что положено делает.
Технологически устаревает? Ну это закон природы, все устаревает :)
NVMeoF? Это прекрасно :) по мне — костыль для SAN, да.
И да, SAN сам по себе ничем не плох. Как вобщем и Nokia 3310 :)
работает справно, что положено делает.
Технологически устаревает? Ну это закон природы, все устаревает :)
NVMeoF? Это прекрасно :) по мне — костыль для SAN, да.
Меньше сущностей
Сущностей то как раз не меньше. Оборудования — да.
по мне — костыль для SAN, да.
чем?
Давайте считать.
Классика.
Серверы. (в них Адаптеры SAN и LAN)
SAN (Коммутаторы, провода и проч)
LAN (--"--)
СХД
HCI
Серверы (c LAN)
LAN (Коммутаторы, провода и тд)
Итого сущностей столько же, верно?
А про «чем костыль»… Это как разгон процессора на водяном или крио охлаждении (метафора). Работать будет, но это уже «дожим» возможностей.
Классика.
Серверы. (в них Адаптеры SAN и LAN)
SAN (Коммутаторы, провода и проч)
LAN (--"--)
СХД
HCI
Серверы (c LAN)
LAN (Коммутаторы, провода и тд)
Итого сущностей столько же, верно?
А про «чем костыль»… Это как разгон процессора на водяном или крио охлаждении (метафора). Работать будет, но это уже «дожим» возможностей.
HCI
Серверы (c LAN)
Не понял — зачем отдельно серверы, если мы про HCI?
«дожим» возможностей
Пока, судя по тестам NetApp + Brocade — дожимом там и не пахнет, учитывая более скромные показатели аналогов на Ethernet, которые ещё до конца и не готовы.
Ну так давайте посчитаем.
Если всё делаем с фактором репликации 3, нужно в 3 раза больше стореджа, в 3 раза больше дисков, в 3 раза больше серверов в которые можно вставить эти диски. в 3 раза больше лицензий на эти сервера и не важно нужно ли вам столько компьютинга.
Кабели, NIC/HBA в серверах и свичи, как ни крути всё-равно будут и у True HCI они никуда не делись. Единственное что нужно будет в 3 раза больше этих вот NIC, в 3 раза больше портов на свиче, где будет гоняться в 2 раза больше сетевого трафика и тех же самых кабелей в 3 раза больше.
Ситуацию немного может улучшить фактор репликации 2, тогда вам всего нужно в 2 раза больше, а не в 3 (Мама мия!). Но при этом немного ухудшить защищённость данных.
Касательно скорости, то «Записи не подтверждаются до тех пор, пока по сети удалённые ноды не подтвердят получения этих данных, что равносильно скорости работы с shared storage по сети».
Есть еще вариант сделать EC, и существенно сократить накладные расходы на железо и пространство, став по эффективности почти таким как shared storage, порядка 35%. Но при этом просев в производительности, потому что EC это по-сути сетевой RAID.
Если всё делаем с фактором репликации 3, нужно в 3 раза больше стореджа, в 3 раза больше дисков, в 3 раза больше серверов в которые можно вставить эти диски. в 3 раза больше лицензий на эти сервера и не важно нужно ли вам столько компьютинга.
Кабели, NIC/HBA в серверах и свичи, как ни крути всё-равно будут и у True HCI они никуда не делись. Единственное что нужно будет в 3 раза больше этих вот NIC, в 3 раза больше портов на свиче, где будет гоняться в 2 раза больше сетевого трафика и тех же самых кабелей в 3 раза больше.
Ситуацию немного может улучшить фактор репликации 2, тогда вам всего нужно в 2 раза больше, а не в 3 (Мама мия!). Но при этом немного ухудшить защищённость данных.
Касательно скорости, то «Записи не подтверждаются до тех пор, пока по сети удалённые ноды не подтвердят получения этих данных, что равносильно скорости работы с shared storage по сети».
Есть еще вариант сделать EC, и существенно сократить накладные расходы на железо и пространство, став по эффективности почти таким как shared storage, порядка 35%. Но при этом просев в производительности, потому что EC это по-сути сетевой RAID.
1) Нет уникальности. 3PAR тоже отдельно масштабируется от серверов.
2) Спорно. На российском B2E засилье предложений от SP на VMware. Управление через конечно API пишут в тендерах, но на практике выдают разве что в рамках dedicated private cloud. Чтобы не дай бог платформу с другими клиентами вместе с собой никто не положил.
3) Можно подробней? На практике QoS на LUN не очень работает, так как на нем обычно несколько дисков VM создаётся уже самим клиентом. QoS на диск? VVOLs?
4) Готовы сделать commitement на эффективность вместе с commitement по QoS? Разделить ответственность провайдера при трансляции back to back SLA в End User? У вендора с большим опытом в cloud есть представление, как это вообще может быть устроено? При том, что у провайдера жизнь на инфраструктуре достаточно динамичная — под одни включения нужен выше QoS возможно в ущерб эффективности, под другие наоборот. И это ещё во времени меняется
1) С каких пор 3Par стал HCI-решением?
3) QoS на LUN, на vvol. Что под диском понимается? Есть интеграция с SIOC.
4) Тут я за вендора отвечать не могу. По эффективности подписывается документ со всеми условиями. Есть 180 дней с момента отгрузки оборудования, чтобы выяснить достигается ли арантированная эффективность. Если не достигается, то клиент обращается к вендору. Для начала выделяют инженера для проверки, что все настроенно в соответствии с best practices, если это не помогает, то вендор отгружает ноды/диски.
При том, что у провайдера жизнь на инфраструктуре достаточно динамичная — под одни включения нужен выше QoS возможно в ущерб эффективности, под другие наоборот. И это ещё во времени меняется
Про это можно подробнее?
QoS по сути неотключаемая функциональность. Каждая нода имеет заявленную производительность с профилем 80/20 rr/rw 4k. В зависимости от модели ноды это 50К IOPS или 100K IOPS на ноду. Для любого создаваемого тома задаётся политика, в которой указывается минимально гарантированная производительность, максимальная и burst. Сумма минимальных QoS для всех томов не может превышать производительность всего кластера. Если нагрузка на томе не превышает максимальный QoS, то накапливаются кредиты. При превышении максимального значения QoS эти кредиты начинают тратиться.
1) Провайдер не ограничивает себя HCI. Главное, чтобы решение по хранению было удобно для предоставления услуг множеству конечных пользователей и было экономически эффективным.
2) Если вы не знакомы, в портале самообслуживания VMware vCloud Director клиенты сами создают диски (vHDD) для своих виртуальных машин. Интеграция с SIOC и vVOL хорошо.
3) Приведите пример формулировки правила QoS. Пока не понятно что в нем участвует — полоса, IOPS, latency?
4) Не скажу как для Enterprise, но для провайдера схема не очень рабочая. Клиенты на массив будут приходить 1-2 года. За 180 дней будет загружен лишь небольшой dataset от общего объема. Для примера допустим на нем эффективность 2:1. Вендор расширит весь массив в два раза? Ну и условия непонятно какие подписывать — провайдер еще не знает какие клиенты и с какими данными придут через отдел продаж
2) Если вы не знакомы, в портале самообслуживания VMware vCloud Director клиенты сами создают диски (vHDD) для своих виртуальных машин. Интеграция с SIOC и vVOL хорошо.
3) Приведите пример формулировки правила QoS. Пока не понятно что в нем участвует — полоса, IOPS, latency?
4) Не скажу как для Enterprise, но для провайдера схема не очень рабочая. Клиенты на массив будут приходить 1-2 года. За 180 дней будет загружен лишь небольшой dataset от общего объема. Для примера допустим на нем эффективность 2:1. Вендор расширит весь массив в два раза? Ну и условия непонятно какие подписывать — провайдер еще не знает какие клиенты и с какими данными придут через отдел продаж
В SF QoS в виде IOPS настраивается на лун, на VM нельзя. QoS в SF работает очень интерестно: каждому луну отдельно QoS натраивается минимальное, максимальное и пиковое значения IOPS. Любой лун не может получить меньше чем задано значение Min, если луну в этот момент не нужно максимум, то он получает минимум, а разница начисляется на будущее в виде кредитов. Когда же приложение «просыпается» и наченает потреблять свой максимум, система ему выдаёт «заработанные кредиты», пока они не будут выработаны. После того как кредиты выработаны производительность возвращается на максимум. Это очень удобно для сервис провайдеров.
Важно отметить что IOPS, IOPSу рознь. К примеру если вы настроите на SF 1000 минимум IOPS и при этом размер IOPS будет 4KB, значит у вас будет 4000 KB/s минимум. Если приложенеи будет генерировать блоки размером в 128KB, значит при тех же самых 1000 IOPS у вас будет уже 128000 KB/s минимум. Обычно приложения генерируют микс из разных размеров блоков, по этому иногда легче запустить приложение посмотреть сколько оно генерирует IOPS а потом установить минимум, максимум и пиковые значения.
На латенси QoS технически поставить не возможно. И я говорю о настоящем QoS а не о «уровнях» типа Gold/Silver etc.
По поводу 4): стоит подумать на счёт того чтобы в агрименте для пользователя прописать то что цена на ёмкость уменьшеется если данные сжимаются, и увеличивается, если данные несжимаемы (уже закомпресированные, зашифрованные или медиа файлы не сжимаются).
Важно отметить что IOPS, IOPSу рознь. К примеру если вы настроите на SF 1000 минимум IOPS и при этом размер IOPS будет 4KB, значит у вас будет 4000 KB/s минимум. Если приложенеи будет генерировать блоки размером в 128KB, значит при тех же самых 1000 IOPS у вас будет уже 128000 KB/s минимум. Обычно приложения генерируют микс из разных размеров блоков, по этому иногда легче запустить приложение посмотреть сколько оно генерирует IOPS а потом установить минимум, максимум и пиковые значения.
На латенси QoS технически поставить не возможно. И я говорю о настоящем QoS а не о «уровнях» типа Gold/Silver etc.
По поводу 4): стоит подумать на счёт того чтобы в агрименте для пользователя прописать то что цена на ёмкость уменьшеется если данные сжимаются, и увеличивается, если данные несжимаемы (уже закомпресированные, зашифрованные или медиа файлы не сжимаются).
Извините, но без latency это не QoS, а всего лишь продвинутая форма shaping-а. То что описано, удобно для целей тарификации IOPS. Но не подходит для нагруженных корп. приложений — клиенту не важно, спало его приложении или нет, ему важна гарантированная скорость обработки запроса.
Вот тут не понятно «Любой лун не может получить меньше чем задано значение Min, если луну в этот момент не нужно максимум, то он получает минимум, а разница начисляется на будущее в виде кредитов.» IOPS генерирует клиентский приклад, иногда он вообще ничего от массива не просит. Минимум в него силой заталкивают что-ли?
Кроме того, не очень понятно, про какие IOPS идет речь — front-end или back-end и как учитываются разные профили read и write?
4) Коммерчески так не работает с крупным бизнесом. Ему важнее предсказуемость бюджетируемых расходов.
Вот тут не понятно «Любой лун не может получить меньше чем задано значение Min, если луну в этот момент не нужно максимум, то он получает минимум, а разница начисляется на будущее в виде кредитов.» IOPS генерирует клиентский приклад, иногда он вообще ничего от массива не просит. Минимум в него силой заталкивают что-ли?
Кроме того, не очень понятно, про какие IOPS идет речь — front-end или back-end и как учитываются разные профили read и write?
4) Коммерчески так не работает с крупным бизнесом. Ему важнее предсказуемость бюджетируемых расходов.
:)) латенси в QoS засунуть архитектурно и технически не возможно, чтобы гарантировать постоянно минимальное значение латенси, разве что сделать «уровни» а-ля плохо-хорошо-отлично. QoS по-сути делает прерывания (паузы) на те потоки чтения/записи, которые относятся к тому или иному луну, в зависимости от их настроек. Другими словами чтобы герентировать латенси одному луну, нужно чтобы другие страдали, другими словами это не натягивается на идею общего хранилища ни на идею HCI. Чтобы латенси всегда была минимальная, необходимо иметь выделенные диски.
В SF/HCI NetApp говорит что будет sub-millisecond latency.
4) ну тогда продавайте без учёта дедупа. Потому что дедуп, у всех производителей, не может жать мультимедиа и уже скомпрессированные или зашифрованные данные.
В SF/HCI NetApp говорит что будет sub-millisecond latency.
4) ну тогда продавайте без учёта дедупа. Потому что дедуп, у всех производителей, не может жать мультимедиа и уже скомпрессированные или зашифрованные данные.
Я считаю, что вопрос не в архитектуре. А в недостаточном внимании запросам конечных клиентов — как самих сервис провайдеров так и их конечных потребителей из корпоративного сегмента. С учётом технологических особенностей массового обслуживания. Именно поэтому и решил устроить данную дискуссию, так как в статье читается тезис, что NetApp — лучшая СХД для облачных провайдеров. Но технических пруфов не увидел. Только отсылки на использование в больших западных облачниках.
Про QoS есть такой момент, что адекватный SLA допускает некий разумный % нарушений. Достаточно обеспечивать попадание в целевой latency "стабильно часто". И есть разные задачи — где-то акцент в паре на самом latency (30 — 10 — 3 мс), где то на стабильно (95%, 99%, 99,9%)
Собственно KorP работает в сервис провайдере которые юзают SF. Спросите его о том довольны ли они и какие есть нюансы. Он кстати статью на хабре про SF выкладывал, можете взглянуть если интересно.
Молодцы, Онланте продали. Но удовлетворительного решения принципиальных задач SP по ответам не увидел.
С QoS история чем-то напоминает рекомендацию ограничивать очередь на кассу в магазине через ограничение потока посетителей. Тогда как первоочередной проблемой покупателя является минимизация времени своего нахождения в очереди. Люди идут в магазины, где их быстро обслуживают!
Но удовлетворительного решения принципиальных задач SP по ответам не увидел.
А какие задачи вы перед собой ставите?
Ограничение по IOPS — нормальное явление для сервис провайдера, QoS в этом и помогает.
Отсутствие головной боли при расширении, заведомо известное кол-во IOPSов, которые вы получите при покупке X нод, с сайзингом которых справится и «эффективный» менеджер.
API.
Наши задачи он решает в полном объёме
Вы используете распространенное заблуждение. Вынужден повториться — ограничение по IOPS это shaping, а не QoS.
IOPS генерит клиент. Какое Quality вы даете ему взамен? Как выяснилось, latency не получается обеспечивать
IOPS генерит клиент. Какое Quality вы даете ему взамен? Как выяснилось, latency не получается обеспечивать
latency не получается обеспечивать
А какие системы позволяют вам обеспечить конкретный latency?
Какое Quality вы даете ему взамен?
Так клиенту продают IOPSы, а не задержки
"Я что, дурак рыбные места выдавать". На самом деле задача решается, но не самым удобным набором средств. Поэтому если найдётся вендор СХД, который сделает поуму, будет круто.
Тезис был, что NetApp HCI мегаудобное хранилище для SP. Оно может и удобное. Но не для SP с точки зрения бизнеса и клиентского сервиса.
Также можно утверждать "Клиенту vСPU, а не скорость их работы." Не путайте товар и его качество. Яблоки гнилые, цена им ноль.
Не путайте товар и его качество. Яблоки гнилые, цена им ноль.
Вы в корне не правы. Если бы провайдер не обеспечивал отклик проданного класса дисков — с ним бы просто никто работать не стал, был бы миллион отзывов и тд.
Задача решается банальным мониторингом и балансировкой данных между массивами, в случае SF — установка доп. нод
Задача решается банальным мониторингом и балансировкой данных между массивами, в случае SF — установка доп. нодВот именно. Задача решается «смекалкой» и рисками провайдера, а не технологией массива. А история с установкой доп. нод. — это в конечном итоге установка разных массивов под разных клиентов… А не multi-tenancy обслуживание клиентов с разными QoS Levels на одном массиве
кстати если мы говорим про Vmware, то там можно использовать vVOl, с которыми можно отдельно на ВМ (точнее на виртуальный диск от ВМ) настраивать QoS по IOPS.
3Par, как к примеру и NetApp FAS не HCI (по крайней мере пока), потому что в обоих есть дисковые полки которые нужно уметь правильно подключать, что бы без останова, правильно диски раскидывать, разбивать и в рейды собирать, под приложения тюнить. И что важно специальные докуменнты на достаточно хорошем уровне изучать, чтобы мочь эти системы конфигурировать и эксплуатировать. Так что перед тем как vVOL можно с них забрать, нужно сначала это всё нафонфирурировать и так чтобы правильно.
В то время как NetApp Solid Fier это система которая состоит из нод, каждая из которых это и контроллер и дисковая полки, каждая нода это всего-лишь 10-12 SSD дисков, а кластер максимум из 100 нод. Соостественно она существенно гранулярнее традиционных СХД: можно добавлять и забирать ноды из кластера. Подключение это два кабеля питания и два кабеля для данных 10/25 Гбс. Ничего особо конфигурировать не нужно: задискаверил ноду в визарде и добавил в кластер. Автоматически общий пул пространства и перфоменса в кластере вырос.
К примеру у вас кластер из 8 нод. И у вас утилизация 60% пространства. 60% от 8 =4.8 нод (округляем до 5). 8-5=3 ноды можно забрать из кластера. Дальше из этих высвобожденных 3 нод нод можно создать второнй, новый кластер, если ещё добавить 1 ноду. В реальной продуктивной системе, с высоким уровнем записей, вы наверное всё-таки одну ноду стоит оставить, то есть забрать 2, а не 3, чтобы пространства не совсем так мало оставалось, но суть в том, что добавлять/удалять можно с гранулярностью в одну ноду.
В то время как NetApp Solid Fier это система которая состоит из нод, каждая из которых это и контроллер и дисковая полки, каждая нода это всего-лишь 10-12 SSD дисков, а кластер максимум из 100 нод. Соостественно она существенно гранулярнее традиционных СХД: можно добавлять и забирать ноды из кластера. Подключение это два кабеля питания и два кабеля для данных 10/25 Гбс. Ничего особо конфигурировать не нужно: задискаверил ноду в визарде и добавил в кластер. Автоматически общий пул пространства и перфоменса в кластере вырос.
К примеру у вас кластер из 8 нод. И у вас утилизация 60% пространства. 60% от 8 =4.8 нод (округляем до 5). 8-5=3 ноды можно забрать из кластера. Дальше из этих высвобожденных 3 нод нод можно создать второнй, новый кластер, если ещё добавить 1 ноду. В реальной продуктивной системе, с высоким уровнем записей, вы наверное всё-таки одну ноду стоит оставить, то есть забрать 2, а не 3, чтобы пространства не совсем так мало оставалось, но суть в том, что добавлять/удалять можно с гранулярностью в одну ноду.
Если также упрощать, у классических СХД гранулярность в худшем случае в одну полку — 20-25 дисков. А на 3PAR при разбиении по рекомендациям вендора обычно несколько полок со свободными слотами и можно хоть квантами по 4 дика наращиваться…
Там есть требования по минимальному количеству дисков которые нужно добавлять в систему нужно делать «правильное», в смысле проприетарное кабелирование дисковых полок которое у каждого производителя своё уникальное, правильно диски докидывать. Это всё ведёт к тому, что необходимо более-мение глубокое понимание внутренней архитектуры СХД, которая не то что у каждого производителя разная, у каждой линейки разная.
В то время как SF нода подключается по Ethernet архитектурно так сделано, чтобы потребители СХД, как оно там устроено внизу, знать не то что не должны, им просто по барабану. А Ethernet он и в Африке Ethernet. Два кабеля в свичи воткнул и поехали. Не думаем о RAID, дисковых полках, специальных коммутациях, чтением мануалов, и вообще внутренней архитектуре СХД. Такую СХД как SF или HCI могут «потреблять» люди без специальных знаний СХД, к примеру отдел виртуализации или программисты из Dev/Ops. Разница по сути в существенном упрощении с точки зрения потребления пространства и производительности.
3Par и тот же NetApp FAS конечно же очень интерестные и стоящие системы под свои задачи. SF/NetApp HCI нужен если же задача построить инфраструктуру для сервис-провайдера, или исключительно виртуальной инфраструктуры VMware или инфраструктуру для Dev/Ops, которые не хотят ждать, а просто запросить по RESTFul API и получить гарантированную производительность и заданное пространство, вот прям сходу, сразу, ничего не тюнингуя, как только систему воткнути в питание и в свичи, ничего толком не конфигурируя кроме нескольких IP адресов.
В то время как SF нода подключается по Ethernet архитектурно так сделано, чтобы потребители СХД, как оно там устроено внизу, знать не то что не должны, им просто по барабану. А Ethernet он и в Африке Ethernet. Два кабеля в свичи воткнул и поехали. Не думаем о RAID, дисковых полках, специальных коммутациях, чтением мануалов, и вообще внутренней архитектуре СХД. Такую СХД как SF или HCI могут «потреблять» люди без специальных знаний СХД, к примеру отдел виртуализации или программисты из Dev/Ops. Разница по сути в существенном упрощении с точки зрения потребления пространства и производительности.
3Par и тот же NetApp FAS конечно же очень интерестные и стоящие системы под свои задачи. SF/NetApp HCI нужен если же задача построить инфраструктуру для сервис-провайдера, или исключительно виртуальной инфраструктуры VMware или инфраструктуру для Dev/Ops, которые не хотят ждать, а просто запросить по RESTFul API и получить гарантированную производительность и заданное пространство, вот прям сходу, сразу, ничего не тюнингуя, как только систему воткнути в питание и в свичи, ничего толком не конфигурируя кроме нескольких IP адресов.
Если честно, так не бывает, что собрал абы как, и оно все летает. С чем сталкивался — вендор дает рекомендации по составу дисковых групп и примерно куда попадёт итоговый IOPS performance на ноду. Детальных выкладок по performance, как в технических калькуляторах на классические массивы. Если есть обратный пример — с интересом посмотрю.
И ещё такое наблюдение. Истории "про HCI хорошо, классика плохо" очень часто строятся от массивов на SSD против имеющегося у клиента опыта на в лучшем случае Hybrid хранении на классике. Тот же latency 3 мс — вроде круто. Но это ведь не будет стрессовым сценарием для All Flash. Давайте лучше разные All Flash сравнивать на показателях уровня 0,1 мс?
Ну вот поинтересуйтусь как устроена архитектура SF. Вы даже увидите что документация на много меньше чем тот же ONTAP, потому что оно простое в использовании как двери.
Единственная рекомендация по SF не делать один большой лун, а делать много лунов, что вполне подходит для любого сервис провайдера. Rackspace на SF работает.
Единственная рекомендация по SF не делать один большой лун, а делать много лунов, что вполне подходит для любого сервис провайдера. Rackspace на SF работает.
вендор дает рекомендации по составу дисковых групп
В SF ничего этого нет, вы вообще физики практически не касаетесь, кроме настройки портов нод.
Единственное с чем мы столкнулись «непривычным» — LACP вместо «классических» 2 фабрик
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ближайшее будущее NetApp