Почему NetApp не является конкурентом для Nutanix?

Вопрос конкуренции с уже существующими системами хранения и серверными системами, в том числе теми, которые называют себя популярным в отрасли buzz-словом «конвергентные», безусловно то, с чем Nutanix встречается постоянно. Разумеется постоянно возникает вопрос того, как и чем новая система и, в случае Nutanix, даже более того, «архитектура», превосходит традиционные и хорошо знакомые другие решения.
Так как, уверен, вы пришли в этот блог только что и в первый раз, а значит пока ничего, или почти ничего о Nutanix не знаете, то краткий elevator pitch:

Nutanix — это концепция, архитектура, и, наконец, конечный продукт, ставший результатом ответа на вопрос: «Что, если мы создадим идеальную платформу виртуализации такой, какой она должна быть, без необходимости использовать и подстраиваться под решения, придуманные 20 лет назад, для совсем другого применения и других задач?» Результатом стала компьютерная архитектура, вобравшая в себя достижения технологий, разработанных за те 20 лет, что в отрасли пока господствовали идеи SAN. Такая архитектура позволяет легко строить линейно масштабируемые (scale-up) и легко расширяемые кластера из однотипных «серверных модулей» — «IT-кирпичиков», включающих в себя одновременно и серверную платформу (с использованием новейших процессоров Intel Xeon) и элементы распределенного гибридного (SSD + HDD) хранилища, что позволяет обойтись без отдельной SAN как таковой, так как они используют идеи распределенной отказоустойчивой кластерной файловой системы, построенной поверх кластера равноправных узлов. Отказ от SAN, и использование других передовых идей, развивающихся в computersciense в последнее десятилетие, позволил построить архитектуру, идеально соответствующую требованиям решений построения «облачных» инфраструктур. В настоящий момент компания Nutanix — прочно стоящий на ногах стартап-бизнес, получивший крупное венчурное финансирование от ряда инвестфондов, и поставивший уже свыше трех тысяч своих систем нескольким сотням своих клиентов, в том числе и из «топов» отрасли, и недавно вышедший с исключительно американского на общемировой рынок дистрибуции.

Неизбежно такая новая архитектура будет снова и снова сталкиваться с вопросом пользователей: «А как насчет сравнения с %имявендора%? Вот про продукты %имявендора% мы знаем очень хорошо, и даже используем у себя, чем же вы настолько их лучше, чтобы мы все бросили, и пошли покупать ваши пока сомнительные новинки?»

Начнем мы такие разборы с продукта-конкурента, хорошо мне знакомого, с которым лично я давно работаю, и хорошо его возможности знаю, с системы хранения NetApp FAS, справедливо считающейся сегодня в отрасли одним из лучших выборов для построения облачной инфраструктуры высокого класса. Однако, справедливости ради, следует отметить, что у всего есть свои сильные и слабые стороны, и, конечно есть области, в которых новое решение от Nutanix превосходит возможности NetApp (о том, где оно ему уступает мы уже говорили в соответствующем месте).

1. Технология SAN была разработана около 20 лет назад, в совсем ином «ландшафте», и совсем для других применений чем она используется сейчас. По сути, базовый «ландшафт» SAN — это собрать индивидуальные диски серверов в одном месте и одном устройстве, объединить их в общее пространство, а потом нарезать на куски меньшего размера, которые раздать индивидуальным потребителям-серверам, словно это их индивидуальные диски, которые мы у них отобрали на первом шаге этого высокоинтеллектуального процесса. Как вы видите, в идее SAN LUN, как устройства и как протокола SCSI, вообще нет ничего, что позволило бы использовать такие LUN совместно, несколькими потребителями. Это можно сделать «поверх», с помощью внешнего, по отношению к самой SAN костыля «кластерной файловой системы», со своими оверхедами и ограничениями (пример: VMFS), но изначально SAN совершенно не предназначена была и не планировалась для такого использования. Отсюда, очевидно, что если мы не будем приспосабливать с помощью г..на и палок нечто, что для данного применения не планировалось, а возьмем что-то, более подходящее для данных задач, то мы сразу на старте получим существенное преимущество.

2. Кластерность вообще очень плохо поддается положению на идею SAN. Традиционные архитектуры систем хранения и серверов очень трудно и с большим оверхедом совмещаются со scale-up кластерами. Про необходимость использовать кластерную файловую систему поверх блочного LUN я уже упомянул выше. Все было относительно неплохо, пока IT-мир жил, покупая мощные сервера, на которых запускались отдельные приложения, а если нужно было еще — на сервере создавались новые партиции и новые приложения, или же VM. А когда мощности суперсервера не хватало — надо было просто пойти, и купить еще более мощный (и еще более дорогой). Но все перевернулось с ног на голову, когда родилась идея строить большие и мощные сервисы на базе несложных и относительно маломощных «commodity»-серверов, которые стало нужно не делить партициями, как какие-нибудь монстры p-Series, а наоборот, объединять сотни и даже тысячи таковых в единый общий сервисный пул. А вот тут сразу оказалось, что идея SAN на такой схеме не работает вовсе, или работает с большим количеством костылей и оверхеда.

3. В настоящий момент размеры масштабируемости кластера систем хранения NetApp ограничены 24 узлами для NAS-систем, и 6 узлами для SAN. К слову сказать, эта разница хорошо иллюстрирует то, насколько SAN труднее поддается «кластеризации», если даже такой специалист в этой области как NetApp, после стольких лет разработок предлагает для SAN-систем в четыре раза ниже лимит по scale-up кластерности, чем для более «интеллектуального» NAS. И это не просто так и не «просто потому, что не хочет». Компания и команда Spinnaker, разработки которой легли в основу разрабатываемой NetApp параллельно-кластерной архитектуры, была куплена еще в 2004 году, при том, что реально работающий продукт широкого применения, пригодный в продакшн у NetApp получился разве что вот в прошлом году. И крайне сомнительно, что NetApp удастся существенно увеличить эти лимиты в ближайшее время.

4. Экономичность в потреблении ресурсов (читай — минимальный операционный оверхед). Продемонстрированный Nutanix пример инсталляции, обслуживший на подтверждающем тесте 3200 VDI-пользователей, занял в стойке всего 21 юнит (8 x 2U Nutanix NX3050 и 5 x 1U Ethernet switches), в то время как построенный с использованием традиционной архитектуры NetApp система для 5000 VDI занимает существенно больше места и потребляет электричества/охлаждения из расчета «на обслуживаемый десктоп» ( 118 юнитов в 3 стойках — 90 x 1U серверов + 2x 2U контроллеров системы хранения и 4 х 4U дисков, плюс сетевая инфраструктура) при сравнимых показателях производительности, продемонстрированных на тестировании.

5. Наконец, на кластерных системах Nutanix куда проще (и дешевле!) строить распределенные фермы приложений, там где вам нужна именно такая задача. Покупая шасси с модулями Nutanix Complete Cluster вы получаете фактически готовое решение, готовые 4 хоста vSphere (или KVM), уже включающие в себя готовый к использованию отказоустойчивый датастор. В то же время, в случае «традиционной архитектуры», вы покупаете отдельно сервера и отдельно сторадж и отдельно сетевую (ethernet или FC) «кухню», и даже в случае «конвергентных систем» типа FlexPod или vBlock, они остаются логически отдельными, и лишь механически объединенными в одной стойке. При этом, пока, кластер NetApp все же ограничен размещением в едином датацентре, так как пока его географическая распределенность ограничивается размерами использующего 10G Ethernet кластерного интерконнекта. На момент написания этой статьи кластерный NetApp все еще не реализовал поддержку синхронной репликации между узлами кластера хранения.

Таким образом, как мы видим, на ряде задач решение от Nutanix, не наследующее устаревшие архитектурные концепции более чем 20-летней давности, и не снабженные разнокалиберными костылями разной степени удобства и прямости, решения, применяемые в той области, для которой они созданы, могут обеспечить беспрецедентно выгодный способ построения современных кластерных, облачных, распределенных инфраструктур; ферм виртуальных серверов и виртуальных десктопов; массивно-параллельных «шардов» веб-сервисов, подобных Facebook, Google или eBay; кластеров для BigData и датамайнинга.

Компания пока в начале своего пути, но перспективы, объективно, очень впечатляющие. Будем далее следить, а заодно — разбирать, как устроены системы Nutanix с технической стороны.

Почему NetApp не является конкурентом для Nutanix?: 19 комментариев

  1. Lesovsky

    Это конечно круто, но хотелось бы больше софтваре-гикпорно нюансов… что внутри? ОС понятно что Linux, а вот версии ядра, пакетов. Как туда устанавливаются гипервизоры? Вот лично мне было бы интересно запустить там oVirt/RHEV )))
    P.S. Надеюсь статьи будут появляться с такой же интенсивностью как в том самом «некоем» блоге.

    1. romx Автор записи

      Обязательно, просто не все сразу. Дойдем и до таких подробностей.
      Если коротко на заданные вопросы:
      1. OS там — baremetal hypervisor. В случае VMware — ESXi, для KVM — Red Hat Linux,конечно. Hyper-V 3.0 установлен конечно поверх Windows, ведь с точки зрения софта это — обычный x86 сервер.
      2. С установкой туда чего-то своего — основная проблема в том, что Nutanix это, по сути, некая intellectual property, которая содержится в некоем софте, называемом Controller VM, и обеспечивающего работу с дисками без SAN, строя поверх них свою распределенную «файловую систему». И вот этот вот CVM пока существует только под ESXi и KVM (даже под Hyper-V он пока не до конца готов). А без него Nutanix box — просто коробка с четырьмя x86 серверами, и локальными дисками, ничем не отличающаяся от любых других x86. Вся суть у него — в волшебных пузырьках. %)

      Посты я надеюсь публиковать еженедельно. Материал вроде пока есть,

  2. Artur

    Роман, только C-mode для SAN уже 8 нод поддерживает начиная с версии 8.2rc1. Сути это конечно не меняет :)

    Если кластер NetApp ограничен от геораспределения 10G интерконектом, то почему же Nutanix не ограничен? Ведь используется все та же 10G сеть.

  3. Artur

    Кстати, по поводу «4. Экономичность в потреблении ресурсов (читай — минимальный операционный оверхед)». А вам не кажется приведенное вами сравнение некорректно? Вы просто сравниваете две конфигурации приведенные в документах. В случае с NetApp плтность вычислительных нод была явно не на первом месте. Что мешает развернуть инсталляцию с NetApp и физическими серверами аналогичными по производительности и физической архитектуре. что и в решение Nutanix? Взять те же самые Супермикры с четырьмя серверами в 2U, с такими же процессорами и таким же количеством памяти. Сеть опять же 10П и NFS в качестве протокла доступа. Уверен, что по юнитам получится немногим более. только за счет того, что диски хранятся не в корпусах с серверами, а во внешнем массиве. А производительность может получится и выше за счет FlashCache или FlashPool.

    1. romx Автор записи

      Ну, видите как. Это вечная история с любыми тестами. Вы проводите тест, потом вас кто-то побивает, и есть большой соблазн сказать, что «а вот если бы мы тогда взяли … и сделали … а потом еще настроили …, то вы бы нас не побили тогда!» Но сравнивать можно то, что можно сравнить, а не гипотетический случай «как могло бы быть, если бы». Когда в следующий раз тот же NetApp захочет провести сравнение, тогда он сделает тест с другим стендом, и вот тогда может быть сравним по другому, а пока сравниваем ровно то, что имеется, ничего более.
      Поэтому путь «а если бы мы знали, то сделали бы иначе, и тогда бы всех порвали» — он неконструктивный. Сравниваем то, что можем документально подтвердить.

  4. Maxim Shaposhnnikov

    Рома, ну ты шустрый :)
    Уже и блог завел.

    Я сегодня твои письма длиннющие (много о чем спорить :) ) в спаме нашел, занимательно весьма. Буду отвечать :)

    Твоя позиция «не является конкурентом Netapp» понятна и вызывает уважение, но факт (упрямый) что в огромном множестве проектов мы выносим на 1-2-3 именно Netapp (зачастую в связке с HP) и EMC.

    1. romx Автор записи

      > Уже и блог завел.
      Ну, долго ли умеючи-то :)

      > Твоя позиция «не является конкурентом Netapp» понятна и вызывает уважение
      Моя позиция — что эти продукты конкурируют только в некоторой области пересечения множества их применений, и область эта, на мой взгляд, пока не так чтобы уж и велика, и в обоих случаях это только небольшая область общего множества областей применения. И в этих двух постах тут и «там» я постарался по возможности максимально объективно этот вопрос рассмотреть и перечислить сильные и слабые стороны обоих решений.
      Попытка, допустим, самолетом возить нефть, а кораблем — почту, не приведет к успеху, что, однако в своих областях они будут справляться с подходящими для них задачами вполне успешно. Нужно лишь правильно и здраво оценивать их возможности.

      > в огромном множестве проектов мы выносим на 1-2-3 именно Netapp
      Ну, во-первых, ты лицо заинтересованное, тебе это полагается публично говорить по должностной инструкции ;-Р (А мне — нет, поэтому я стараюсь придерживаться более объективной, и, во многом, критической позиции)
      Во-вторых, я не спорю, что правильно выбрав проект, который подходит под Nutanix, и не подходит под «СХД традиционной архитектуры», вполне можно последние «вынести», так что выбор таких проектов для входа делает честь вашим сейлам, но и только.

      Вообще же — рад и велкам, думаю, у читателей со временем будут вопросы по существу.

      1. Maxim Shaposhnnikov

        Небольшое говоришь :)

        Проще конкретизировать.

        Nutanix не подходит:

        1) Нестандартные архитектуры (рынок все уже)

        2) То что не поддается виртуализации (рынок опять-же сужается постоянно)

        3) Крупные БД / размеры датасторов не умещающиеся в один нод (достаточно временная проблема, стоимость флеш падает, мы выкатываем в начале следующего года 4-ю версию ПО, которая (вот уж головняк-то для Нетаппа очередной ;)) ) имеет более 80 новых фич.

        Реальная «проблема» для нас — пункты один и два, это как раз ниша традиционных СХД.
        То что ниша активно схлопывается — тоже очевидно, множество крупнейших компаний даже в РФ (Типа Сбербанка) работают над BigData решениями (да-да, Hadoop и прочие радости), для которых Nutanix опять-же идеален (а Netapp пролетает мимо как фанера над Парижем).

        p.s. Мы сейчас в процессе активного сотрудничества и сертификации для SAP HANA.

        1. romx Автор записи

          Я насчитал больше.
          И мне кажется — смотрю на ситуацию более объективно, по крайней мере более аргументированно — уж точно :)

          Но вообще-то ты оффтопишь, поскольку эти комментарии более подходят для «того» блога и той темы, а тут мы говорим наоборот, о том, для чего менее подходят «СХД традиционной архитектуры», давай все же оставаться в рамках топика. Если не боишься спора с нетапповцами «лицом к лицу» (а они там у меня инкогнито ходят и читают) — приходи. Но учти, булшит и пропаганда там не пройдет, сразу предупреждаю, надо будет быть более аргументированным, чем сейчас ;)

          > а Netapp пролетает мимо как фанера над Парижем
          Например это откровенная неправда. У NetApp для этого есть E-series. Прекрасно продается, в том числе и для BigData, кстати.

          Итак, предлагаю про NetApp _здесь_ закруглиться, а продолжить, если желаешь — «там».

          1. Maxim Shaposhnnikov

            Пардон, но насчет пропаганды и булшита это не ко мне :)

            Очевидно-же что и у тебя есть свои интересы, говорить о тотальной предвзятости не приходится, очевидно теперь и в интересах какой компании идет общение (не вендора). Никаких проблем, они наш официальный дистрибьютор и имеют все шансы таковыми и остаться, если не будет повторений ситуаций как с Arista Networks.

            Суть моих комментариев сводится к тому, что твоя позиция по минимальной области пересечения Netapp и Nutanix — мягко говоря не выдерживает критики.
            Пересечений очень много, и чем дальше — тем будет больше.

            Я понимаю, что коммерчески надо как-то сделать «и волки сыты и овцы целы» — и Netapp продавать и Nutaanix сверх-перспективный не упустить, никаких вопросов это не вызывает (бинес есть бизнес).

            Проблема в том, что для того чтобы спорить с нетаповцами (и с тобой) по BigData и вообще технологии «распределения» данных, надо чтобы вы в них разбирались и имели опыт долговременный — для вас концепция «все что может умереть в железе, умрет обязательно в самый неподходящий момент» не является непреложной истиной (иначе бы не было заявлений, про которые ниже).

            Фактически, сейчас сталкиваются две больших галактики — «традиционщики» и ребята из сверх-крупных онлайн проектов, снизошедшие до энтерпрайза и принесшие ровно те-же технологии в причесанном виде, доступные уже всем.

            Простой пример (как надо работать и как работают конторы типа Гугла) — наши ребята за несколько месяцев с нуля написали реализацию SMB3 под Linux для HyperV (стабильную и намного более быструю чем Samba), между тем как подобные вещи обычно делают годами (а самбу пилят уже лет 15).

            Да, мы используем Cassandra для распределенного хранения метаданных (которую сами и разрабатывали — люди по 5+ лет в Facebook сидели и к нам перешли), Apache Zookeeper, активно сотнудничаем с HortonWorks / Hadoop, и тд.
            Вы обладаете экспертизой в этом, чтобы активно спорить? :)

            Спорить с вами так-же достаточно сложно ввиду заявлений подобных «шансы что вылетит полка Нетапа и будет ребилд массива в течении недели маленькие, потому что там два контроллера» — шансы-то в любом случае далеко не нулевые.

          2. romx Автор записи

            > Пардон, но насчет пропаганды и булшита это не ко мне :)

            Без комментариев ;)

            > Суть моих комментариев сводится к тому, что твоя позиция по минимальной области пересечения Netapp и Nutanix — мягко говоря не выдерживает критики.

            Это потому, что ты смотришь «со стороны Nutanix», и тебе кажется, как это обычно и бывает, что область, в которой действует Nutanix — это вообще все, что только может быть на свете. Это известный психологический феномен. Когда сидишь в больнице, то кажется, что весь город болеет. Стоишь в пробке — ну все куда-то едут :)
            Я в «том» посте, в комментарии к которому ты так наотрез не хочешь перевести дискуссию, перечислил области, в которых я вижу сложности для Nutanix, и это совсем немаленькие и не незначительные вещи.

            > Пересечений очень много, и чем дальше — тем будет больше.

            Ну, если вас не купит в процессе какой-нибудь Dell или HP через год, и не сделает из вас какой-нибудь HP P5000 StoreNuts (в лучшем случае, а в худшем не задвинет, как PolyServe, Ibrix или тот же LeftHand) :-P

            > Проблема в том, что для того чтобы спорить с нетаповцами (и с тобой) по BigData и вообще технологии «распределения» данных, надо чтобы вы в них разбирались и имели опыт долговременный — для вас концепция «все что может умереть в железе, умрет обязательно в самый неподходящий момент» не является непреложной истиной (иначе бы не было заявлений, про которые ниже).

            Максим, ты эта… прикрути фитилек-то. Коптит :) Мы не в емэйле, не забывай, давай покорректнее. У NetApp в области BigDatа, например, просто банально больше опыта, NetApp с Hortonworks и Hadoop на E-series занимается (и продает) уже третий год, так что не надо грязи.

            > наши ребята за несколько месяцев с нуля написали реализацию SMB3 под Linux для HyperV (стабильную и намного более быструю чем Samba), между тем как подобные вещи обычно делают годами (а самбу пилят уже лет 15).

            На самом деле, если не стояла задача обеспечивать обратную совместимость и поддержку SMB1/CIFS, что необходимо в SAMBA, но, скорее всего, совсем не нужно вам, то ничего удивительного. Утверждается, что SMB2(3) был очень сильно упрощен с точки зрения протокола, одних команд было сокращено с более сотни, до всего 19.
            К тому же спеки на SMB2(3) куда более ясные. К тому же у вас не стоит задача обязательно соответствовать GPL (что висит над SAMBA, и не дает им просто взять уже готовый код, который не может быть выпущен под GPL). Это даже не говоря о том, что ущербность типичной модели community-driven опенсорсной разработки, в которой нет менеджера проекта, что кнутом и пинками не дает программистам отвлекаться, она хорошо иллюстрируется как раз всей этой «казачьей вольницей» Самбы.
            Так что как раз неудивительно, удивительнее было бы обратное.

  5. pLuto

    Ну т.е. в сухом остатке понимается так — аппаратная платформа — стандартная 2027 или 6027 от супермикры, внутри крутятся обычные гипервизоры, уникального в решении — только некая софтовая прослойка, размазывающая хранение по нодам.
    И тут сразу возникает вопрос — сколько нод должно выжить, чтобы все данные оставались доступны, т.е. какова избыточность решения на дисковом уровне?

    1. romx Автор записи

      Аппаратная часть — да, обычный x86 сервер, суть решения — в софтовом продукте, который на нем крутится, обеспечивая работу с гибридным стораджем, его отказоустойчивую репликацию, логику при отказах, tiering данных, дедупликацию и прочие фичи. И это совсем не «только».
      Избыточность — настраиваема, минимум нужна еще одна нода, а стандартно считается, что для штатной работы кластер должен иметь три ноды (поэтому starter pack сейчас и продается на три ноды, как вы видели в анбоксинге). Соответственно блок данных разбрасывается еще на две ноды, откуда он остается доступен в случае сбоя локальной ноды. То, как именно он разбрасывается, и каким образом эти реплики находятся, когда в них возникает необходимость, это задача той самой «софтовой прослойки».

      Но о технических деталях у нас впереди будет еще немало постов, где это будет разобрано подробнее.

      1. Maxim Shaposhnnikov

        Вообще как раз рекомендуем покупать 4 ноды, особенно для игрищ — например на 4-х нодовом кластере можно легитимно удалять ноду (дать команду на отключение ноды из кластера).

        На 3-х нодовом это очевидно сделать невозможно ;)

  6. comotoza

    В Nutanix Bible указано, что медуза крутится на всех нодах кластера и собственно выступает хранилищем метаданных. Это здорово.
    А что насчет зевса — хранилища конфигурации кластера? Он крутится только на 3 нодах, что будет при сценариях:
    1. умерли все 3 ноды одновременно — все конец кластеру? что будет при включении кластера после обслуживания — эти ноды запускать первыми?
    2. ноды умирают поочередно — будет ли он искать нового кандидата под хранилище конфигурации?

    маркетингово звучит — начнем с 3 нод и до бесконечности, а на факте всюду фигурирует 16 нод (та же дока по VMware View Pod=4 Block) и больше 16 нод кластер не предлагают собирать, а предлагают собирать новый кластер, да это все хорошо вписывается к требованию для HA/DRS кластера (не более 32), но получается я создаю много кластеров Nutanix, много кластеров VMware и гибкость немного пропадает — не работает DRS между новыми серверами-они в своем кластере VMware, не работает Storage DRS — новые серверы имеют свои диски
    Есть какие-то уточнения на этот вопрос — почему так сделано?

    1. romx Автор записи

      Я бы хотел обратить внимание присутствующих на то, что для общеценных и общеполезных разговоров, выходящих за рамки комментариев к тексту конкретного поста, тут на блоге заведен форум. Он простенький, но вполне рабочий, поэтому лучше такие вопросы, углубленные, задавать (и отвечать на них) — там, потому что тут они будут видны только зашедшим в тело поста, который скоро «утонет», а там — для всех, и ответы будут доступны и полезны всем.
      Ссылка на форум есть справа на главной странице блога: http://blog.in-a-nutshell.ru/forums/

    2. Maxim Shaposhnnikov

      1) умерли все 3 ноды одновременно — все конец кластеру?

      Да, так.

      Но мы сейчас имеем block awareness, и распихиваем зусы по блокам. скоро будет rack awareness, соответственно еще и по рэкам зусы распихивать. Вероятность выхода из строя — чрезвычайно низкая.
      Собственно, в этом и есть один из основных плюсов Nutanix — чем больше нодов в кластере, тем он быстрее (линейно) и надежнее.

      2) 2. ноды умирают поочередно — будет ли он искать нового кандидата под хранилище конфигурации?

      конечно будут, это очевидная логика :)

      3) «маркетингово звучит — начнем с 3 нод и до бесконечности, а на факте всюду фигурирует 16 нод (та же дока по VMware View Pod=4 Block) и больше 16 нод кластер не предлагают собирать»

      Проблема не в нас, а в средствах управления гипервизоров, особенно базы данных централизованные. есть кластеры (не могу разглашать где) на 50 нодов.

      30 нодов например — это рекомендация VMware (в 5.5 подняли до 50+)

      «почему так сделано» — только из-за вышеупомянутой причины. Ну и, учитывая что KVM мы уже сами из себя управляем (пока только из CLI — cкрипты), и у нас есть сверхмощный Prism / распределенное хранение данных без центральных точек отказа, то мысль сами продолжайте (что будет дальше / в ближайшее время).

      На самом деле нет никаких причин вообще лепить такие крупные кластера, потому как 2 миллиона IOPS (недавно наши тестировали под KVM) — это уже очень немного кому нужно на сегодняшний день.

      Архитектурно, мы можем тянуть кластера из тысяч нодов (тот-же Инстаграмм на Кассандре имеет в кластере более тысячи нодов).

      1. Maxim Shaposhnnikov

        Да, просьба понимать, что в отличии от конкурентов (не будем называть вендоров :D ), «окно опасности» на нутаниксе на порядки меньше — секунды или минуты.

        Если лег нод с Зусом — перенос считанные секунды, если вылетел диск — полные восстановление реплик на кластере достаточно большом — 10 минут или даже меньше.

  7. sl0n

    ИМХО, в статье присутствует некоторая путаница с терминам:

    scale-up — вертикальные рост, те «больше RAM, больше ядер CPU» в пределах одного сервера
    scale-out — горизонтальный рост, тк добавление серверов в некий кластер

    Nutanix как раз последнее (scale-out), поправьте, если не прав.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *