ADVANSERV
Компания
27,88
рейтинг
5 марта 2014 в 11:30

Разное → Забудь про СХД. Nutanix – революция в виртуализации



В последнее время набирает популярность идея SDN (Software-defined Networking). На фоне данной концепции, а может и под её влиянием, развивается идея и SDS – Software Defined Storage. Данное направление выглядит перспективным и начинает активно развиваться, к примеру, выход в бета версии VSAN.




Я хотел бы рассказать о решении возможно знакомом многим, и отчасти похожем на VSAN, я говорю о компании Nutanix. Одним из интересных отличием является то, что VSAN 1.0 Beta и его разработка начата только в прошлом году, а Nutanix версии 3.5.2 и существует с 2009 года. Расскажу подробней про это решение.

Nutanix предлагает виртуальную вычислительную платформу для решений VMware vSphere, MS Hyper-V, KVM. Он объединяет вычислительные ресурсы серверов и корпоративную систему хранения в едином решении. Такой подход обеспечивает несколько преимуществ:
  • Прогнозируемые расходы на инфраструктуру. Nutanix расширяется блоками и вы всегда сможете сказать сколько будет стоить система в 2, 4, 8 раз более производительная. Вам не придется менять контроллеры СХД на более мощные или докупать лицензии при переходе на более старшую модель СХД.
  • Пошаговое расширение. Начав с 3-х узлов вы можете докупать их по необходимости. Без надобности сразу закладывать производительные контроллеры, если планируется быстрый рост требований к ресурсам.
  • Упрощение архитектуры. В данном решении не требуется SAN и СХД, что упрощает администрирование.
  • Высокая производительность. Использование оперативной памяти, SSD накопителей и локальных дисков позволяет добиться высокой скорости работы и минимальных задержек.

Изначально Nutanix возник как решение для VDI (Virtual Desktop Infrastructure). Потенциал самой платформы, развитие продукта и увеличение функционала вполне позволяют использовать его и для серверной виртуализации.

Пятиминутка маркетинга закончилась, давайте посмотрим, что это такое.
Решение представляет собой x86 серверы с локальными жесткими дисками процессорами памятью. Они выполнены в виде твин серверов 4/2U, 2/2U или один сервер на 2 юнита. Серверы подключаются к сети 10Gb/s (только младшая модель 1Gb/s) и используют данную сеть для всех коммуникаций. Совершенно ничего необычного тут нет, всю магию данного решения делает программное обеспечение. Честно говоря, использовать можно было бы любую платформу, но продается только в связке SW + HW.



Узлы доступны в нижеуказанных конфигурациях. Минимальное количество узлов для заказа 3 шт. В рамках одного кластера возможно использовать разные узлы. Докупать узлы можно поштучно.

Модель Процессор Накопитель Память Количество ВМ Сеть
NX-1000 Series Per Node (4 per Appliance) NX-1050 2x Intel Sandy Bridge E5-2620, 12 cores / 2.0 GHz 400 GB SSD, 4x 1 TB HDDs 64 GB или 128 GB до 50 ВМ 2x 10 GbE, 2x 1 GbE, 1x 10/100 BASE-T RJ45
NX-3000 Series Per Node (4 per Appliance) NX-3050 2x Intel Ivy Bridge E5-2650v2 16 cores / 2.6 GHz 2x 400 GB SSD, 4x 1 TB HDDs 128 GB или 256 GB до 100 ВМ 2x 10 GbE, 2x 1 GbE, 1x 10/100 BASE-T RJ45
NX-3051 2x 800 GB SSD, 4x 1 TB HDDs
NX-3060 2x Intel Ivy Bridge E5-2680v2, 20 cores / 2.8 GHz 2x 400 GB SSD, 4x 1 TB HDDs 128 GB, 256 GB или 512 GB до 115 ВМ
NX-3061 2x 800 GB SSD, 4x 1 TB HDDs
NX-6000 Series Per Node (2 per Appliance) NX-6020 2x Intel Ivy Bridge E5-2630v2, 12 cores / 2.6 GHz 1x 800 GB SSD 5x 4 TB HDDs 32 GB, 64 GB, 128 GB или 256 GB до 75 ВМ 2x 10 GbE, 2x 1 GbE, 1x 10/100 BASE-T RJ45
NX-6050 2x Intel Sandy Bridge E5-2670, 16 cores / 2.6 GHz 2x 400 GB SSD, 4x 4 TB HDDs 128 GB или 256 GB до 100 ВМ
NX-6060 2x Intel Ivy Bridge E5-2680v2, 20 cores / 2.8 GHz 128 GB, 256 GB или 512 GB до 115 ВМ
NX-6070 2x Intel Sandy Bridge E5-2690, 16 cores / 2.9 GHz 2x 800 GB SSD, 4x 4 TB HDDs 128 GB или 256 GB до 110 ВМ
NX-6080 2x Intel Ivy Bridge E5-2690v2, 20 cores / 3.0 GHz 128 GB, 256 GB или 512 GB до 115 ВМ
NX-7000 Series Single Node (1 per Appliance) NX-7110 2x Intel Ivy Bridge E5-2680v2, 20 cores / 2.8 GHz 2x 400 GB SSD, 6x 1 TB HDDs 128 GB или 256 GB Users – GRID K1 vSGA: 8-64, GRID K2 vSGA: 6-48, GRID K2 vDGA: 6; 3x PCIe expansion slots; Up to 2x GRID K1, 3x GRID K2, 1x APEX 2x 10 GbE, 2x 1 GbE, 1x 10/100 BASE-T RJ45


Особо хочу выделить модель NX-7110. Она позволяет устанавливать карты Nvidia Grid K1/K2 и используется для высоконагруженного VDI. Основная линейка это серия NX-3000. Серия NX-6000 отличается большим объемом SATA дисков.

На каждый из узлов устанавливается стандартный гипервизор, и на нем разворачивается ПО Nutanix в виде виртуальной машины. Апплайнс который установлен на каждый узел, использует часть вычислительных ресурсов сервера и «забирает» все жесткие диски, использую PCI-E Pass-through. Соответственно гипервизор не видит диски.



Далее узлы Nutanix (ВМ) объединяются в кластер, узлы называются Controller VM — CVM. Сделать это можно одной командой на любом из узлов или через WEB-интерфейс управления. В принципе, в данный момент СХД готова к работе, остается только презентовать место гипервизорам. Презентация осуществляется по-разному и только «своим» гипервизорам, где есть ВМ Nutanix. В случае VMware – это NFS; Hyper-V – SMN 3.0; KVM – iSCSI.



Что происходит между этими двумя событиями, как это работает?
В общих чертах ответить на этот вопрос может данное видео:



В дополнении к видео хочу рассказать об основных фичах продукта (но не всех) и о принципе работы чуть подробнее.
  1. Доступность данных.
    Для управления ресурсами хранения используется Nutanix Distributed Filesystem (NDFS) – распределенная файловая система Nutanix. Она контролирует операции чтения и записи данных, гарантирует целостность данных и резервирует их для защиты от выхода из строя диска или узла. С операциями чтения всё понятно, они происходят по возможности локально. Единственное исключение — это перемещение виртуальной машины. В этом случае узел, на который виртуальная машина переехала, не будет иметь её полной копии. И для операций чтения он будет по сети запрашивать данные с других узлов и в фоновом режиме восстанавливать полную копию у себя. А вот для обеспечения отказоустойчивости необходимо реплицировать данные на другие узлы. Как это происходит: во-первых, необходимо сохранить метаданные. Для этого используется сервисная роль на каждом из узлов (модифицированый Apache Cassandra, для обеспечения консистентности данных — алгоритм Паксос).
    Для защиты самих данных используется синхронная репликация между узлами. Nutanix использует такое понятие, как Фактор Репликации (replication factor (RF) — по умолчанию он равен двум. Соответственно, каждый вновь записанный блок имеет две копии: одну локальную, одну на другом узле. В данный момент из командной строки можно поменять RF для каждой ВМ, установив его значение 3, к примеру, мы будем иметь копии на трех узлах.
  2. Производительность.
    Высокая скорость работы (IOPS и низкие задержки) в первую очередь обеспечена тем, что большая часть данных хранится локально. Каждый гипервизор имеет свой контроллер в виде CVM, что минимизирует задержки на передачу данных по сети. Помимо этого «горячие» блоки кэшируются в оперативной памяти и на SSD. Операции записи идут на SSD, для этого на диске выделена область кеширования – Oplog. Далее данные распределяются между SATA и SSD. Возможна конфигурация, когда последовательные операции записи пропускают Oplog и идут на SATA диски. Тиринг перемещает данные между SSD и SATA дисками, как это обычно бывает на основе частоты запросов к блокам данных.
    Помимо этого возможно включение дедупликации данных, которая снижает занимаемый объем на SSD и в оперативной памяти. Дедупликация как и онлайн компрессия уже включены в стоимость.

К слову о лицензировании и стоимости: отдельно лицензируются две опции – репликация и пост компрессия. Репликация стоит отдельного упоминания. Помимо самого механизма передачи данных, репликация Nutanix, включает в себя механизм автоматизации запуска ВМ на удаленный площадке. По своему функционалу конечно он не сравнится с VMware Site Recovery Manager. Но учитывая, что он лицензируется на узел, а не ВМ, может быть весьма интересен для отдельных сценариев. Производительность на примере VDI в цифрах — Estimated Sizing Guidelines for VDI Deployments.

Стоимость: Мы не можем раскрыть информацию о фактической цене, но по опыту расчётов могу сказать так, в итоге стоимость решения на Nutanix выходит значительно дешевле, чем решение классической архитектуры из 4 двухпроцессорных серверов + СХД (уровня VNX5200, 3PAR 7200) с аналогичным размером SSD/HDD. Оформив заказ в течении недели с момента этой публикации и указав ключевое слово — «Зуммер» и получите скидку до 20% (размер скидки зависит от общей стоимости вашего заказа).

Хочу напомнить, что Вы можете взять данное оборудование у нас в Demo на тестирование. По всем вопросам по Nutanix обращайтесь к нашему руководителю направления — Владимиру Подымову.
Автор: @Advanserv
ADVANSERV
рейтинг 27,88
Компания прекратила активность на сайте

Комментарии (109)

  • +5
    Мы не можем раскрыть информацию о фактической цене

    Укажите цены по прайсу, shapa ведь их писать не стесняется.
  • 0
    Звучит не плохо, но так и не понятно, что за софт там внутри, никогда в жизни не поверю, что они меньше чем за год сделали ОС и сетевую файловую систему.
    • +1
      ОС Free BSD. Почему за год?
      • 0
        Одним из интересных отличием является то, что VSAN 1.0 Beta и его разработка начата только в прошлом году

        Так сказано в описании… А так как это не бердовый маркетинговый ресурс, а технический, такие подробности ожидают прочитать многие, не только я, а откуда вести про FreeBSD?
        • 0
          из названия файла дистрибутива.
          • +1
            Ответ неверен к сожалению. Внутри — Centos.

    • +1
      Файловая система — ext4 (там хранятся группы экстентов по 4 мегабайта), метаданные — кассандра.

      Все работает поверх Centos.
      • +1
        Если CentOS и ext4, то честно говоря совсем не интересно.
        • 0
          конечно не интересно.

          одна из самых производительных и надежных ФС в мире (NDFS), плоха лишь потому что использует для базового хранения экстентов ext4, а для метаданных — кассандру, и все это под «ужасным» линуксом который работает как запускалка наших сервисов ;))

          это конечно пять баллов ;).

          и конечно-же ничуть не смущает что сейчас самые производительные и надежные сетевые «железки» на сотни гигабит / терабиты трафиков (Arista Networks, F5 Networks и тд) — это тоже линукс и даже Centos.


          а если без шуток — ext4 как раз идеальна в нашем случае, ибо от базового уровня нам просто надо сохранить мегабайтный файл на диске. Никакого другого функционала ext4 не используется. И надежность у нее — сотни миллионов инсталляций в мире (ни одна другая ФС кроме FAT разве что — и рядом не лежит).
          • 0
            Количество инсталляций совсем не показатель. Я считаю, что xfs лучше и гугль тоже почти выбрал выбрал xfs, почти только потому, что у них ext2 и они ее сконвертировали в ext4, а так бы на xfs перешли. Считаю я так не просто исходя из названия, а исходя из опыта эксплуатации.
            Количество инсталляций так же зависит от того, что ext4 много где ФС по умолчанию, но это опять же не значит, что она лучшая, не спорю может быть для этих задач она и подходит, но выбор он всегда лучше, чем его отсутствие… Zfs и FreeBSD для данного решения выглядит куда вкуснее.
            • 0
              «почти» — ключевое слово.

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

              Количество инсталляций — факт сверхважный, в данном случае это означает отполированность до блеска.

              XFS для нашего случая был бы крайне странным, и прямо говоря глупым вариантом.

              ZFS и FreeBSD для нашего решения выглядят еще более неразумным, чем XFS.

              FreeBSD в сущности уже практически трупик, их только Juniper и тащит (у которого глобальные проблемы с бизнесом в общем-то по слухам — как минимум народ от них бежит, в ту же Arista или F5 Networks. А кто-то и к нам.).

              Со всем уважением, ваш опыт эксплуатации generic файловых ничего не имеет общего к области кластерных ФС — это разные вещи.
              • 0
                В каждом релизе до блеска полируют :)

                Вот 3.13.6 вышла…

                1883d76 ext4: don't leave i_crtime.tv_sec uninitialized
                fe01b1a ext4: fix online resize with a non-standard blocks per group setting
                385d7ce ext4: fix online resize with very large inode tables
                1503cbd ext4: don't try to modify s_flags if the the file system is read-only
                087cee5b7 ext4: fix error paths in swap_inode_boot_loader()
                4c5e5c7 ext4: fix xfstest generic/299 block validity failures
                • 0
                  Что прекрасно иллюстрирует мои слова, ибо все эти баги — мягко говоря незначительны, а для наших задач — вообще абсолютно неактуальны. Все-бы баги были такими ;)

                  Если посмотреть на список изменений XFS или ZFS — вот там точно весело станет.

  • 0
    Расскажите в паре слов как происходит обновление «прошивок» управляющих контроллеров. Есть какие-то ограничения, в момент, когда у нод одного кластера разные версии fw?
    • 0
      У нод нет FW — наш контроллер работает поверх стандартных гипервизоров

      Так что апдейты все на лету ;)
    • 0
      Кратко процесс обновления: прошивка заливается на один узел, он распространяет его на другие, по очереде перезагружаются ноды. Делается из командной строки. Обещают автоматизировать в следующих версиях, сделать из GUI.
      • 0
        Не обещаем, а уже сделали в 4-ке.
        Так-же как мультикластерный менежмент и много другого.

        Клиентам начнем выдавать в течении месяца-двух ;)
  • 0
    Интересные железки, вернее сказать правильная концепция и хорошо написанный софт.
    Но применимость ограниченна: под VDI да круто, под смешанные решения (несколько типов гипервизоров) уже не применимо как единая система, физические сервера в пролете, для них эта система не подходит. Никаких iSCSI, FCP и т.д.
    По цене, если сравнивать СХД с забивкой SSD вендоров первого эшелона + сервера для обработки, то стоимость сопоставимая или выигрывает Nutanix, а если рассматривать смесь HDD+SSD то обычная СХД.
    Nutanix по скорости очень крут, хоть и не во всех сценариях применим. Но там где применим, он смотрится отлично.
    • 0
      «уже не применимо как единая система» это не так.

      с версии 4.0 ПО — у нас мультикластерный менежмент, хоть 1000 кластеров в разных точках мира на разных гипервизорах управляйте (ESXi, KVM, HyperV)
      • 0
        Ок. Xen?
        «смешанные решения» это же не только виртуализация, там и по физике задач полно. Как пример offload backup (LAN Free), да и много чего еще.
        Nutanix это хорошая система, я не спорю )
        • 0
          XenServer к сожалению уже не имеет практически никакого спроса в мире, в отличии от XenDesktop (которая превалириует с огромным преимуществом)

          Если коротко — KVM более чем достаточно.
    • 0
      тем не менее в виртуалках можно много чего развернуть, например:
      Microsoft SQL Server Best Practices
      go.nutanix.com/rs/nutanix/images/sql-on-nutanix-bp.pdf

      Решение начиналось как VDI, сейчас это и серверная виртуализация
  • 0
    Привязка к железу сделана из чисто маркетинговых соображений, или каких-то ещё?
    Есть ли у вас сравнительная таблица с аналогичными решениями от конкурентов?
    • +1
      Привязка к железу сделана из маркетинговых соображений, это мое мнение. В прицепе, есть возможны варианты купить Nutanix на другом железе.
      Как таковых аналогов мне не известно, если брать только СХД часть, то очень похоже на LeftHand, Starwind итд.
    • 0
      Не совсем.

      Как Apple — надежно потому что проверенная комбинация железа и ПО.

      Впрочем, под крупные проекты / заказчиков мы делаем чисто софтовое решение.

      Обращайтесь к нам по тех. вопросам напрямую, обсудим.
  • 0
    Кеширование горячих блоков на SSD и прочие FS-related плюшки делаются посредством ZFS?
    • 0
      У нас не кэширование, а полноценное хранение. Технически мы вообще без SATA дисков работать можем.

      Мы намного «умнее» ZFS, вплоть до того что умеем дедуплицировать RAM кэш (!).
      • 0
        Я понимаю, но все-же, не писали же вы все с нуля. Там явно ZFS со специями?
        • 0
          Нет, смотрите ниже.

          ext4 — хранение экстентов, кассандра — метаданные. ZFS хорошая ФС, но до нормальной кластерности ей как до луны. ZFS ARC — да, снимаю шляпу, на момент создания — была прорывной. Сейчас мы ушли кардинально дальше.

          у нас одни из ключевых разработчиков кассандры (из фейсбука, гугла и ряда других контор к нам перешли целыми командами).
  • 0
    Это реализовано на NDFS. Поверх чего она работает, на основе чего создана не знаю.
    Общий принцип тут:
    go.nutanix.com/TechNoteNutanixPerformance_LP.html
    go.nutanix.com/TechNoteNutanixSystemReliability_LP.html
    go.nutanix.com/TechNoteNutanixSystemScalbility_LP.html
    • 0
      Если не знаете, то спросите ;)

      Centos + ext4 + cassandra — ключевые слова.
  • +1
    А расскажите пожалуйста, какие параметры у вашей системы, интересует удельная пропускная способность на ноду по I/O. Также из статьи немного непонятно, чем решение отличается от обычного iscsi — не упомянут multipath или какие-либо пути фейловера при отказе одной ноды хранилища, буду признателен за детализацию.
    • 0
      блок 3461 дает около 102 тысяч I/O на чтение и 40 тысяч на запись.

      на ноду — разделите на 4.
    • 0
      Мультипас у нас в ДНК. Даже в случае отказа виртуального контроллера (или апгрейда — у нас все на лету, понятие даунтайма или «окна обслуживания» просто отсутствует), трафик гипервизора переадресуется на соседние ноды (в версии 4.x — per inode проксируется на весь кластер через NFS-proxy который есть на каждом ноде).
      • 0
        100К иопсов, это, надо полагать, с агрегацией/кешированием на клиенте? Если не грузить по уши, какое получается выдерживать SLA для латенси клиента в режиме нормальных операций и в режиме рекавери? Используется ли кворум «контроллеров» для обеспечения отказоустойчивости всего кластера?
        • 0
          Кворум — сильно доработанный Paxos.
          en.wikipedia.org/wiki/Paxos_(computer_science)

          Лейтенси чрезвычайно низкий, если не «по уши» и брать нормальные коммутаторы типа Arista Networks (и боже упаси от нексусов).

          Конкретнейшие цифры есть в наших Best Practice — с замерами, таблицами и тд.

          Они открыто доступны на сайте Nutanix

          www.nutanix.com/resources/

          100к — это абсолютные честные IOPS, тестирование FIO (у нас встроенная самодиагностика / тестирование кластера). Сегодня лично видел в одной сверх-крупной Российской компании.

          С каждой версией ПО производительность сильно растет, еще прошлой осенью было около 50.000 IOPS на чтение на кластер.
          • 0
            Ага, теперь более-менее понятно. С цефом не сравнивали по производительности, поскольку по архитектуре у вас практически он, судя по информации на сайте?
            • 0
              По архитектуре скорее ceph — как мы, но опять-же только в первом приближении.

              Nutanix с 2009 года существует, просто работал только на США и только на гос. рынки.

              Проблема ceph — то что это просто ФС, неплохая вполне, для многих онлайн проектов — самый лучший вариант.

              Мы — конвергентная платформа, с кучей высокоуровневого функционала, максимально упрощенного управления и запуска (хватает 1 среднеквалифицированного инженера на все).

              Ну это как говорить что ext3 конкурент FreeBSD.
  • 0
    Расскажите побольше о том, как осуществляется масштабирование. Вот скажем кончилось у меня свободное место, значит я должен купить это самое место (с некоторым поправочным коэффициентом, вероятно?), а в нагрузку получу дополнительные процессоры и память. И наоборот. В любом сценарии получается, что купленное оборудование простаивает. Неужели такая хорошая цена, что одно компенсирует другое?

    Еще один вопрос, как все это себя ведет в случае различных сбоев и профилактических работ. Например, выключили всю ферму, а потом начали включать по одному? Или все сразу? Что будет происходить?

    Есть ли возможность в явном виде создавать мультисайтовые решения, допускающие выход из строя сайта целиком?

    Или это все же по прежнему очень нишевое решение (VDI), когда соотношение производительности и емкости узла практически фиксировано во времени, а для отказоустойчивости есть только HA?
    • 0
      Доступное место считается по простой формуле, сложить пространство на все узлах и поделить попалам. (порядка 50ГБ отъедается от SSD на каждом узле для своих нужд). Новый узел добавляется просто. кнопкой Add.

      В кластер можно объединять любые узлы с разной конфигурацией, часть узлов может иметь больше SSD, меньше SATA, наоборот. Есть определенный выбор CPU/ количества RAM.
      Ньюанс в том, что при малом количестве узлов может быть некий дисбаланс распределения данных между емкими и быстрыми узлами.

      Одно из удобств расширения блоками в том, что Вы знаете сколько будет стоить апгрейд на любое количество. При это вместе с емкостью у растет и скорость. Сейчас 20 ВМ, а через год надо 200 и это стоит в 10 раз больше. Классическая СХД, так просто не маштабируется, тут и лицензирование может быть другое и замена контроллеров, помимо того что это непредсказуемо это, как правило, дороже.

      В случае сбоев — минимально надо 2 узла для работы, это деградированое состояние, но если хватит места Nutanix сделает две копии данных.
      В случае включения выключения коробки тоже все просто CVM загрузились собрали кластер появился сторадж. Если вопрос в том, как включать — включать все сразу.

      Мультисайт. Растянуть кластер не получиться (пока). Возможна эта фича будет. Есть асинхронная репликация, есть возможность включить машину на резервной площадке из консоли управления Nutanix. Есть интеграция c SRM.

      Решение не только под VDI, но и под серверную виртуализацию. Нишевое — согласен, но виртуализация практически везде есть. Платформа так же работает с Big Data — Hadoop, Splunk.

      А что кроме HA есть для отказоустойчивости ВМ? Чтобы Вы еще хотели?

      • 0
        Не надо говорить что наш DR сильно хуже SRM. Многие клиенты наборот считают что мы сильно лучше.

        И да, SRM мы тоже официально поддерживаем, правильно замечено.

        На резервной площадке не «виртуальную машину» включать, а protection domain. Это понятие описывает бизнес-логику.
        • 0
          >>И да, SRM мы тоже официально поддерживаем, правильно замечено.

          То есть, у вас есть сертифицированый SRA? (В списке доступных не нашел.)
          Поддерживается ли VMImageConsistency при репликации (при использовании SRA и вашего DR)?

          И кстати, поддерживается ли HardwareAcceleratedMove, HardwareAcceleratedInit (VAAI)?
          • +1
            VAAI 100% поддержка.

            Констистенси мы поддерживаем, причем уже есть App. Consistency тоже (пока в бете).

            Сертификации многие нам vmware мееедленно, причины можно только догадываться.
            Ровно те-же по которым нас резко попросили не участвовать в VMware PEX за неделю до него, при том что мы единственные за всю историю 3 года подряд брали золотую медаль VMworld.

            www.crn.com/news/virtualization/240165846/vmware-limits-some-storage-vendors-presence-at-vmware-pex.htm

            (папа у vmware кто? :))) уж не EMC ли? )

      • 0
        Спасибо. Про HA я с shapa поговорю.
    • 0
      Место можно расширять на capacity node — там мало процессоров, мало памяти, можно использовать бесплатный гипервизор (включая esxi (!)), много дисков.

      Смотрите модель NX6120 — один нод 20TB места.
      • 0
        Спасибо за ответы здесь и ниже, приятно читать.
  • +1
    А теперь поехали сложные вопросы.

    Как выбирается «пара» для записи? Запись синхронная или асинхронная? Если асинхронная, что делать при падении ноды, если синхронная, как защищаются от перегрузки спары? Парность полная (сервер-сервер) или блочная (а-ля ceph)? Какое latency на запись при трёх нодах и latency ethernet'а в 100µs?

    Предположим, что всё железо работает исправно. Какая надёжность системы в этой конфигурации?
    • 0
      Пара для записи выбирается случайно, репликация поблочно, запись синхронная. Можно увеличить/ уменьшить количество копий блоков, на уровне ВМ. Nutanix пытается растащить данные между несколькими коробками если блоков несколько.
      Я не готов ответить на вопрос про величину задержки.

      В конфигурации с тремя нодами система гарантирована переживет потерю любой ноды. Время ребилда зависит от многих факторов, но надо понимать что поскольку нет RAID, то, при выходе из строя диска, данные ребилдятся со всех дисков и на все диски, что намного быстрее… Если вопрос про софт, то он вполне надежен — решению не первый год.
      • +1
        Если выбор происходит случайно, каким образом обеспечивается изоляция Fault Domain'ов? У ceph'а (давайте сравнить с текущими решениями) выбор дисков структурирован, и вполне предсказуем.

        Далее: если распределение поблочное, где хранится информация о том, кто что где хранит? Как обеспечивается доступность этой информации? Какое пенальти по производительности это даёт (для понимания, у ceph'а минимальное пенальти при трёхкратной избыточности — аммортизированное 6x)?

        Каким образом система защищается от партиционирования (когда две половинки кластера с потерянной связью между друг другом каждая утверждает, что она самая главная тут)?

        В конце-концов, общественность жаждет сравнения лоб-в-лоб с glusterfs, ceph, parallels (забыл как их distributed вариант зовётся).
        • 0
          Вы от ребят слишком многого требуете :)



          Часть информации открыта, часть — уж пардон, открывать не будем. Мы дорогу переходим слишком многим, и компания уже более миллиардов долларов value. На 100% опенсорс мы не претендуем, и «наколенные» проекты — не наш рынок.

          Кворум — сильно доработанный Paxos.
          en.wikipedia.org/wiki/Paxos_(computer_science)

          Fault Domain — для RF2 — 3 копии метаданных в кассандре. Для RF3 — 5 копий.

          Конфигурации — жестко допиленный Zookeper. Пенальти у нас нет, все цифры производительности — уже с резервированием. Ребилд системы из 20 нодов при вылете жесткого диска одного — около 10 минут.
          • 0
            Ребилд при какой нагрузке? :)
            • 0
              Стандартная типовая нагрузка кластера (читай — чуть свободных мощностей есть). Если их нет — это ошибка дизайна инфраструктуры.



              Чего уж там, раскидать 1TB данных по кластеру где десятки / сотни дисков в режиме «торрента» (экстент группы по нодам всем размазать) — проблемы большой нет.

              Очевидно, что если жесткий прессинг на I/O идет (SATA уровень) — то может быть дольше, чудес тут никто не обещает.
    • 0
      Надежность:

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

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

      4.0 (будет вот-вот) — выдерживаем отказ любых двух нодов одновременно, или (при наличии 3+ блоков) — целого блока (4 нода целиком).

      аналогичными показателями выживаемости на рынке никто не обладает (из известных мне решений).
      • 0
        Переживать вылет одной любой ноды умеют любые системы, у которых хоть сколько-то думали про избыточность. Начиная от самых дешёвых лефтхендов и заканчивая нетаппами. Что не мешает быть им унылым дерьмом периодически радующим стейкхолдеров «edge cases» и предложением прислать perfstat при следующей аварии. Это если про энтерпрайз. Если про new wave, то указанная функциональность заявляется для практически всех таких систем. Just for lulz назовём pohmelfs от товарищей, тесно связанных с Яндексом (или даже в нём работающих, я точно не помню). В запасе gluster, wastsky, ceph, ocfs, gfs, etc.
        • 0
          Все далеко не так.

          При вылете контроллера одного (и нода) — мы просядем в производительности ровно на проценты (если один нод из 10 — то на 10%).

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

          А мы выдержим без проблем (нам надо считанные минуты в 3.5 чтобы переместить / заместить ключевые сервисы на вылетевшем ноде).



          Лулзы можно раздавать направо и налево, но всем упомянутым проектам до энтерпрайза — еще дальше чем до луны. Так-же как Openstack пока.

          Nutanix работает только на компании начиная с medium, основные клиенты — правительственные службы (США и Европа в основном пока), военные, спецслужбы, энтерпрайзы. Типа Toyota, Kia, Ebay и тд
          Мягко говоря — мы говорим о разных критериях производительности и надежности.

          Недавний пример — в одном из самых развитых государств в мире государственная мед. система тоже на Nutanix переходят.



          Есть реальные проекты — берите и тестируйте.
          • +1
            Я, кажется, понял. Для вас слово «энтерпрайз» — синоним слова «крутое и надёжное», а для меня синоним «говно, палки и интеллектуальная собственность в три дорога», плюс «громкое имя», которым удобно прикрывать задницу.
            • 0
              Иметь личное мнение не запретишь.

              Похоже до многих так и не дошло что серьезные бизнесы и «наколенное» — это почти взаимоисключающие понятия. SLA готовы подписать с проектом на ceph? Миллионы долларов штрафов выплачивать если SLA нарушите? :)


              А про опенсорс — мне не надо рассказывать. Я с кластерными ФС уже лет 15 работаю.

              Особенно если учитывать что лично я делал тех инфраструктуры пачкк крупных и сверхкрупных онлайн проектов (типа мамбы и badoo), а вся команда Nutanix — из facebook / google / amazon и прочих.

              Реально, спорить нечего — мы о разных мирах и вещах.
              • 0
                Ну, скажите, гугль ваши или ваших энтерпрайз конкурентов юзает? Фейсбук? Твиттер? Амазон? Майкрософт (в азуре)? Каждый из них живёт с наколенными поделками. И неплохо. А вот про всякие романтические «мы доверили все наши данные новой суперсистеме за пять миллионов долларов, а она повела себя не так, как объясняли на тренингах для персонала» я вижу довольно регулярно.

                Да, насчёт SLA. А вы подпишитесь на миллионные штрафы за найденную багу в софте?
                • 0
                  Я абсолютно «за» наколенные поделки. Если есть деньги держать штат разработчиков / инженеров и это профильный бизнес компании.

                  Я абсолютно «против» наколенных вещей для непрофильных (читай — не онлайн) бизнесов.

                  Про «романтику» — у нас данные восстановить можно из любой проблемы практически, ввиду того что базовый уровень — ext4 (надежный как танк) и 3-5 копий метаданных.

                  За всю историю компании — ни одной потери данных (иначе EMC / Netapp уже бегали бы с большим красным флагом).

                  Я не говорю что никогда не случится, но мы по дизайну реально в первую очередь на надежность (при крайне высокой производительности) закладывались.
                • 0
                  SLA за баги не подписывают, подписывают за потери данных / простои.
                  • +1
                    Таким образом, нет никакой разницы, что это пальцатый вендор с миллионными системами, что это apt-get install ceph — у всех жидко протекает, по шее получает IT-отдел или поставщик услуги, а решение проблемы находится в другой плоскости (перестать ожидать от СХД бесконечной надёжности и адаптировать софт).

                    Я ничего против вас не имею, но я точно могу предсказать по всему своему предыдущему опыту, что у вас протечёт ровно так же, и ровно так же максимум что можно будет добиться, и сообщения о том, что проблему локализовали и устранили в новой версии (это самый лучший сценарий, чаще всего всё затыкается на уровне саппорта, который просит показать, как воспроизвести аварию).
                    • 0
                      Ваш опыт не совпадает с нашим.

                      Как известно, ошибаться не запретишь ;)

                      У нас собраны одни из лучших (буквально и дословно) инженеров в индустрии. Включая ключевую команду разработки GoogleFS.

                      Мы как раз бескончной надежности «СХД» не ожидаем, и решаем проблемы в софте. Если рассуждать кто лучше это сделает — мы или вы, то с чрезвычайно большой вероятностью мы сделаем лучше (бюджеты на R&D, лучшие разработчики и т.д.).
                      • +1
                        Вы сумели решить проблему множественных error path? А теорему Райса? (Иными словами, «ключевая команда googlefs» делает ровно такие же ошибки, как и все остальные, и производитель за них никакой ответственности не несёт).

                        Вы не ожидаете бесконечной надёжности СХД, а (неявно) её обещаете. «У нас не будет отказов из-за софта, потому что „с чрезвычайно большой вероятностью мы сделаем лучше“». А проблема в том, что её не бывает — бесконечной надёжности.

                        (я как раз недавно про это писал: habrahabr.ru/post/124755/)

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

                          Вы можете предусматривать «ненадежность СХД» в вашем ПО сколько угодно, и при этом точно так-же делать косяки.

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

                          Да, сейчас Nutanix так же признан одним из самых лучших технологических «стартапов» в Кремниевой как место для работы.
                          • 0
                            Ну, если вы сводите вопрос к девяткам, то давайте я его тоже к девяткам сведу. Сколько девяток вы предлагаете, и чем, кроме понтов, гарантируете?
              • 0
                Максим, по-моему это очевидно, что «миллионы долларов штрафов» уже включены в цену «энтерпрайза».
                Если не упало — значит «энтерпрайз» в плюсе, а упало — ну просто вернем клиенту его деньги :)
                При условии что у «энтерпрайза» клиентов больше чем один, получается такая себе страховая компания, где риски одного клиента нивелируются деньгами другого. Таким образом сам «энтерпрайз» ничего не платит :)

                • 0
                  Возместить можно деньги, но не репутацию.
                  С подпорченной репутацией сложно зарабатывать деньги.
  • 0
    iSCSI — сам протокол у всех одинаковый, и в данном случае протокол зависит от гипервизора. Отличие от остальных решений, что серверы используются не только как вычислительные узлы гипервизора, но и реализуют отказоустойчивую СХД. За счёт того что данные расположены локально мы получаем большую скорость. За счёт того, что всё реализовано программно — гибкость.

    В данном документе чуть более подробно написано как защищаются данные:
    go.nutanix.com/TechNoteNutanixSystemReliability_LP.html

    Если кратко, в случае отказа возможны 2 варианта:
    1) мы теряем один или несколько дисков, или саму CVM Nutanix. Тогда данные запрашиваются с других узлов, средствами MPIO гипервизора происходит переключение, как у обычных СХД. Для ВМ это незаметно, есть деградация по скорости, чем больше узлов тем менее заметная.

    2) Если мы теряем целиком узел, то данные ВМ доступны на других узлах, и могу быть там перезапущены — вручную или средствами HA, например.

    При это каждый из гипервизоров видит пространство как общедоступный раздел/шару. Поверх этого работают все фичи гипервизора: vMotion/Live migration; HA; SCV; DRS итд.

    Что касается скорости — заявлено до 20 000 IOPS на узел. Это синтетика. С точки зрения реально производительности я бы ориентировался, я давал ссылку, вот на это: go.nutanix.com/rs/nutanix/images/Nutanix_VDI_Sizing_Guideline.pdf

    5000 реальных, честных IOPS, что очень неплохо.
    • 0
      Эти данные на уже старом ПО и железе.

      Сейчас сильно лучше уже. Мы каждые 3-4 месяца выпускаем новый (большой) релиз ПО.
  • 0
    Господа из Advanserv

    Во-первых, спасибо за приятные слова про Nutanix

    Во-вторых, у вас _крайне_ большое количество неточной в статье, да и в комментариях много серьезнейших ошибок.

    Было-бы лучше если сначала тех. вопросы уточняли у меня например ;)
    • 0
      Будет ещё лучше, если вы напишите внятное описание алгоритмов распределения блоков, пересчёта хэшринга, хранения метаданных и т.д.
      • 0
        Что-то напишем, что-то — наше ноу-хау.

        Метаданные / кассандру мы не закрываем, можно зайти на любой контроллер и посмотреть работу всей кассандры и содержимое (nodetool и тд)
        • +1
          «Зайти и посмотреть» — это значит, зарыться в продукт по уши. А мы пока что про мимо проходящих людей говорим.

          Почему ваше решение интереснее, чем ceph?
          • 0
            ceph имеет интеграцию с ESXi, HyperV? энтерпрайз поддержку «единое окно»? держит 400+ виртуалок на коробку 2U?

            … я наверное сильно отстал от жизни :D

            еще раз — мы не СХД. даже так — МЫ НЕ СХД :)

            мы — ковергентная платформа. заточенная под промышленные применения.

            ceph — просто файловая система. неплохая в целом, но с большой кучей архитектурных проблем.



            если вы делаете онлайн проект большой — на Nutanix точно не смотрите, вы не наш клиент, только опенсорс и хардкор.

            если что-то «энтерпрайзное» нужно — чрезвычайно компактное, надежное, быстрое (при этом весьма недешевое) — обращайтесь, обсудим детали.
            • 0
              ceph имеет интеграцию с ESXi, HyperV? энтерпрайз поддержку «единое окно»? держит 400+ виртуалок на коробку 2U?

              да =)

              Поверх можно навинтить что угодно, от проксмокса до вмвари и иметь абсолютно то же. Дьявол будет в деталях типа цифер латенси, SLA по латенси и по бендвизу при восстановлении/перестроении итд. Нужны бенчмарки, чтобы сравнивать предметно.

              • 0
                Можно. Как внешнюю СХД, с ужасной производительностью, большими потерями на электричестве и месте в датацентре.

                Про SLA — абсолютно верно. Смотрите бенчмарки / гайдансы и прочее, при наличии серьезного проекта — брать и тестровать.

                SAP и SAP Hana на нас тоже вот-вот будет сертифицирован.
                • 0
                  Мм, почему ужасной? Производительность чтения или записи 70-80 процентов от сырой скорости носителей с учетом уровня репликации, плюс высокая степень агрегирования операций. Иопсы получаются, конечно, на небольших масштабах не космические, но достичь 100к/клиента с 3-4 нодами возможно при использовании тьеризованного хранилища. Инктанк к тому же довольно бодро закрывает проблемы, вылезающие у клиентов на контрактах, так что уровень поддержки примерно тот же, что и во всем «хорошем» энтерпрайзе.
                  • 0
                    Ниже написали.

                    И я ответил.

                    В случае с KVM и нативным монтированием Ceph ситуация чуть получше, согласен / не спорю.

                    KVM в «энтерпрайзах» пропишется ой не скоро.
                    • 0
                      Зависит от клиента. Если хотят получить lowlat виртуалки — только виндривер, если хотят порезать ценник — можно поставить опинстек и сэкономить на нанятом десятке инженеров относительно лицензий на вмварь на тех же масштабах итд. С совсем закостенелым бизнесом возиться неохота, хотя они, наверное, самые денежные в расчете на килобайт-место решения :)
                      • 0
                        Логично.

                        А вы считали, сколько вам обойдется Ceph с коммерческой поддержкой, и еще и сервера для гипервизоров?

                        При том что это будет минимум в два раза больше по потреблению и в разы — по месту в ДЦ?

                        Ну вот взять нашу коробку 2U — NX1450. До 200 виртуалок, потребление — менее киловатта (!), 2U места в стойке.

                        8x10G интерфейсы (адвансерв некорректно написал, у нас на 1050 поддерживается 1G, но при этом все 10G присутствуют)

                        16TB + 400G*4 SSD — места на «СХД» c тирингом.

                        GPL — 100$k. По GPL понятно что мало кто берет.

                        Ну и кому реально нужен ceph-то? Без шуток, много клиентов в РФ хотя-бы? Там же тупо в пару раз больше «железа» понадобится. И кормить потом ДЦ.
              • 0
                Кстати, монтировать как собрались? NFS3 не параллелизуемый? NFS4 который никто не поддерживает до сих пор (типа ESXi)? SMB3?

                Да, мы например с нуля свою реализацию SMB3 написали. Раза в 3 быстрее Самбы работает.
                в 3.5.2 была самба, достала нас ужасно, за 3 месяца написали свое.
                • 0
                  Для клоузедсерся — iscsi реэкспорт, для кему и виндривер кему — нативно через драйвер эмулятора. Позиксфс слой втыкать — куча геморроя на ровном месте, сорри, от этого надо уходить.
                  • 0
                    Угу. Вот и я говорю, ceph + гипервизоры (кроме KVM / Openstack) — это для любителей большого топора и ножовки.

                    Нативно ни на один коммерческий (читай — самый распространенный в энтерпрайзе / правительстве / военных) — смонтировать не получится.

                    Куча бубнов с плясками и наслоениями протоколов. При том что iSCSI реэкспорт будет упираться все равно в производительность конкретных нодов через которые он смонтирован (никаких сотен тысяч / миллионов IOPS и близко не будет).

                    • 0
                      Реэкспорт упирается в производительность сети ноды-реэкспортера, для небольших бандлов, о которых идет речь(десяток-два нод плюс 10/40г бекнет) этот факт не будет иметь никакого значения, операции так же будут размазываться по всем машинам. Более того, при очень небольшом желании можно сделать эту процедуру автоматизированной и убрать видимость плясок. Миллионы иопсов в одном клиенте никому в принципе не нужны, даже требовательным телекомам, а сто тысяч получится сделать в таких масштабах на сата дисках.
                      • 0
                        В случае с внешней СХД — никто не будет брать Ceph для серьезных задач, возьмут Netapp / EMC / Hitachi / прочие и будут правы.

                        Возможно, лет через 5-10 все и изменится…

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

                        Ровно так-же как сравнивать parrot drone за 300$ и квадрокоптеры профессиональные для МЧС за 70.000$k.

                        Похожие технологии, разные рынки и клиенты, разные надежности и возможности.
                        • 0
                          Ну вот один очень серьезный телеком(в топ5 по разрабатываемому софту) колеблется между цефом и гластером для своего решения. Полки невозможно перепродать в составе решения из-за ценника, ну или решение будет очень ограниченным. Плюс, начиная с определенного масштаба решения, инженеры обходятся дешевле.
                          • 0
                            Для телеком облака — мы зачастую очень хорошо подходим. Чисто если все подсчитать корректно (особенно — стойко-места и электричество не забыть). Инженеры обходятся дешевле — пока не легло все капитально.

                            В РФ я ни одного «серьезного телекома» не знаю без серьезнейших пролежек (кроме N1 разве что).

                            Говоря откровенно — крупнейший (top-1 :D ) телеком в РФ сейчас с нами активно сотрудничает и особо не скрывают этого. Как минимум очень серьезно рассматривают нас как вариант (один из основных).

                            Про ceph и gluster никто даже не вспоминает — не тот уровень надежности.

                            • 0
                              В мировом top5 :)

                              А вы дважды упомянули электричество — эти супермикры отличаются от своих собратьев чем-то? Если совмещать роль вычислительной и сторож ноды, на питании придется сэкономить ровно 0 — машины будут гвоздями прибиты к C0, чтобы не ронять производительность виртуалок.
                              • 0
                                Ну, с мировыми топами у нас тоже более чем хорошо. Например один из самых больших bigdata кластеров (мы умеем подменять HDFS нашим NDFS для базового map/reduce с ускорением в 2-3 раза как минимум, зачастую — в 10 раз).

                                На питании — вы попадаете очень сильно в случае если гипервизоры типа ESXi / HyperV (сиречь — отдельные сервера от ceph кластера с реекспортами iSCSI и прочей мишурой).

                                В случае телекома огромного который строит свой Amazon — ceph может быть вполне разумен, спорить с этим глупо (я сам строил мега-кластера на опенсорсе, и не в РФ).
                                • 0
                                  Реэкспортеры висят на сторож нодах и места/ресурсов не едят. Вся моя риторика сводится к тому, что опенсерсный цеф, в принципе, равен по надежности и по производительности вашему решению и уступает только в отдельных фичах, которых там просто нет из-за ориентации в другую сторону. Риски заложить каждый может сам после тестирования, ну или если контора довольно небольшая или специализированная в ином направлении, т.е. без возможности проведения экспертизы хранилища, купить не глядя энтерпрайз.
                                  • 0
                                    Нет, ни по надежности ни по производительности он не равен. Мы имеем большие лаборатории, где регулярно все тестируем — в том числе опенсорс.

                                    Прежде чем вам делать неверные _предположения_ — крайне желательно протестировать сначала и то и другое, затем уже говорить.

                                    В реальность чуть ближе к нам будет только на KVM, и то весьма относительно.

                                    Я понимаю желание защитить то что привычно (пришли тут какие-то Nutanix :) ), но надо объективнее.
                                    • 0
                                      Откровенно говоря, я ничто, кроме KVM, и не рассматриваю. Все прочее за цену решениеспецифичных фич требует очень больших доплат, которые вылезут боком для меня. Цифры на цефе и у вас отличаются в примерно полтора раза для масштаба «десяток серверов», при этом на фиошных тестах не было задачи выбить максимальные цифры. Цеф надо очень сильно докручивать, да, это же опенсорц решение — из коробки цифры у него совершенно далекие от максимальных.
                              • 0
                                В EU чрезвычайно крупный телеком нас тоже выбрал (Франция), на KVM.

                                в Японии — та-же cитуация (крупнейший телеком, KVM кластер, мы собственно под них делали поддержку KVM).

                                в Китае — мы признаны лучшими для построения ДЦ нового поколения.

                                www.nutanix.com/2013/11/14/nutanix-wins-chinas-hpc-annual-big-data-infrastructure-award/
                                www.nutanix.com/2013/09/12/nutanix-wins-china-computerworld-award/

                                Gartner нас назвал Cool Vendor 2013 (Servers).

                                Далее. Если этот top-5 телеком рассматривает решения — то мы можем продать только ПО.
                                Экономика там меняется колоссально, но смысл имеется только от сотен нодов.
                        • 0
                          Ну вот жидко какающий нетапп я своими глазами видел. Было грустное зрелище. А продавали-то как…
                          • 0
                            Ну, вы же профессионал чтобы в сказки не верить?

                            Netapp — это уже давно «не торт». Мы их регулярно (и понятно почему) в тендерах отжимаем.
                      • 0
                        Создавать пачки iSCSI реэкспортов для каждого гипервизора — не выйдет.

                        iSCSI экспорт должен быть shared, так что ВСЕ ноды кластера (гипервизоры) будут завязаны на производительность и надежность конкретных нодов Ceph кластера. Да еще и ввод-вывод уже будет упираться в сетевые интерфейсы (вместо локализации). Это называется — от чего убегали, к тому и приходим обратно.

                        Это — мало кому нужный ахтунг. Netapp сильно лучше сделает это, право :).

                        Про маленькие кластеры и клиенты мы не говорим — откровенно, если нет 100$k минимального бюджета на проект — на нас лучше не смотреть.
                        • 0
                          Нет, почему. Туда опять же вставляется multipath и получается красивая и удобная штука с нулевым временем простоя. Условно говоря, набросать базовый алгоритм разложения активного и бекап пути для каждого из вольюмов на сторожноды можно за день. При отсутствии перекосов (1 клиент потребляет 90 процентов бендвиза) решение мало чем будет отличаться по надежности от нативного драйвера, разве что обеспечивать его будет неэнтерпрайзный питонячий скрипт. Локализация — путь гластера, и это плохо — нода шлепается, и все обращения к конкретному набору данных подвстают раком, не очень это хорошо.

                          Ceph в масштабах стойки/полки/whatever позволяет получить значения, близкие к параметрам энтерпрайз полок за десятикратно меньшую цену, с той же надежностью. Говорить о том, что он намного хуже работает — бессмысленно, надежность работы софта — да, чуть ниже, если использовать текущую стабильную ветку. Тут дискуссия уже перейдет в то, что будет, если заплатить за поддержку верхнего уровня у инктанка, но в этом, как правило, нет никакой необходимости.
                          • 0
                            Любой мультипас (нам он кстати не нужен) — дополнительные проблемы, все равно упор в конкретные ноды (даже если пачку мультипасов делать, хотя обычно более 2-х — никто не рекомендует) и «подвисания» I/O на время отработки failover.

                            Далее, на HyperV некоторый (и очень интересный клиентам) функционал вообще чисто на SMB3 только работает.

                            Про энетрпрайз полки (и сервера) — мы точно так-же дешевле выходим в разы зачастую.

                            У нас стойка выдаст 2 миллиона IOPS на ура. При этом будут терабайты RAM и сотни процессорных ядер для работы приложений. На ceph-же будет только хранение.

                            Не надо теплое и мягкое плз ;)

                            Если нужна чисто хранилка без compute — ceph очень хорош, никто не спорит.
                            • 0
                              Хорошо, ну допустим для hyper-v и esx ваше решение будет работать только как внешняя хранилка(или esx превратится в тыкву при совмещении, хотя платформа примерно та же). В случае с кему мне ничто не мешает иметь совмещенное решение. Если честно, не представляю, как nutanix, пусть даже при наличии перебегающего между нодами айпи и сопутствующих доделок в серверной части работает лучше, чем мультипуть, если рассматривать работу с тем же айскази, при отказе ноды в плане затупов.
                              • 0
                                налицо непонимание нашей архитектуры, но это нормально — многим мозг взрывает :)

                                лучше — потому что каждый нод физический имеет _локальный_ контроллер и _локальный_ I/O (с сохраниением копий данных на соседние ноды).

                                на ESXi / HyperV мы монтируемся локально (сам с себя нод монтирует), скорость — ограничние работы процессора / памяти / PCI шины.

                                ESXi монтирует NFS3 датастор с виртуалки запущенной на нем самом, через логический коммутатор без физических интерфейсов. HyperV тоже самое, но по SMB3 (который мы написали). KVM — iSCSI (бинго!).

                                100 нодов — 100 NFS / SMB3 / iSCSI «потоков». 1000 нодов — 1000 потоков («путей»). Мы превращаем старые надежные протоколы в суперпроизводительные просто за счет логики.

                                Адреса везде одинаковые — 192.168.5.2 (на каждом виртуальном контроллере поднят). Поэтому для гипервизора мы shared.

                                Это — уникальная архитектура. Никаких тыкв.
                                • 0
                                  А как обеспечивается консистентность резервных копий в этом случае? Примерно такой же подход в плане локализованности данных исповедует гластер, но, повторюсь, это не очень удобно, по хотя бы тем соображениям, что перекосы в нагрузке придется время от времени балансировать миграциями. У нас была в свое время идея модицифировать алгоритм распределения данных в цефе для стопроцентной локализации, но по итогу это оказалось не нужным — латенси сети вводит задержки около миллисекунды для операций, а ее насыщение во всех случаях наступит примерно одновременно из-за трафика копий.
                                  • 0
                                    Констинтетность — нет подтверждения записи (в гостевую ОС) (softupdates) пока не прошло на других нодах запись копий. Поэтому на запись 40.000 IOPS на блок, а на чтение — 100.000+

                                    Данные ездят вслед за виртуалкой (мы все автоматом сами делаем) — при переезде VM на другой нод, данные локализуются там максимально быстро.

                                    Есть кластера на десятки тысяч виртуалок.

                                    Про сеть — мир меняется :)

                                    Наш глобальный партнер, Arista Networks (подавляющее большинство наших инсталляций — на аристах) — коммутаторы 320-350нс имеют (скорость коммутации / маршрутизации, L2-L4), при смешной цене (24 wire rate порта — GPL прайс аля 12$k).
                                    • 0
                                      Еще есть стек на самих машинах, который вносит задержку, я указал все вместе. К слову, это дорого за 24 порта, трайдент2 стоит столько же, портов в два раза больше, умеет плюс-минус то же, что и ариста. Да, и как вы получаете в случае синхронного коммита на копии с TCP стеком латенси внутри 10мс?
                                      • 0
                                        … зевая… — GPL ключевое слово :)

                                        трайдент не умеет дофига. и по лейтенси только в теории близко. это опять примерно как ceph vs NDFS :)

                                        Arista взяли Interop 2013. Читай — лучший коммутатор в мире.

                                        www.aristanetworks.com/en/news/pressrelease/572-pr-20130508-01

                                        “The 7500E is the winner in both the Networking and Grand Award categories, and its impressive specs are part of the reason,”
                                        • 0
                                          Ариста его взяла по умению прыгать через палку с надписью опенфлоу лучше остальных. Для коммодити — слишком дорого, для простого свичинга трайдент куда дешевле. Да, и у меня нет возможности заходить сзади с порезанным надвое прайсом, потому я смотрю только на gpl.
                                          • 0
                                            Ариста даже в наших прайсах есть.

                                            А по GPL берут только очень редкие клиенты, я бы сказал — уникальные ;) Их надо холить и лелеять.

                                            Вы пишите, мы если что направим к кому надо.

                                            Ариста — не простой свитчинг. Ключевое — лейтенси и архитектура ОС (они — ультрастабильны и быстры).

                                            Openflow там имеет отношение только к одной категории. Ариста взяла в двух главных.
                                            • 0
                                              Спасибо за предложение, посмотрим. У нас задача, в общем-то, простая — запихнуть бекнет в опенфлоу, будем тестировать железки, кто лучше справится.
                                              • 0
                                                Ну, у Аристы помимо отличной поддержки OpenFlow еще и DirectFlow есть.

                                                Тоже очень интересный функционал.

                                                Arista DirectFlow is intended to complement OpenFlow for greater flexibility and broader ecosystem integration.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное