NDFS — Nutanix Distributed File System, «фундамент» Nutanix

    image

    Nutanix — это «конвергентная платформа 2.0», если под «конвергентной платформой 1.0» считать первоначальные эксперименты по механическому соединению стораджей и серверов в единый продукт и некую условно-общую архитектуру, предпринятые в VCE (EMC+Cisco) Vblock, NetApp FlexPod или Dell VRTX. В отличие от перечисленных, в Nutanix уже не просто соединенные проводами в 19" стойке вместе сервера, сеть и сторадж, интеграция куда глубже и интереснее.

    Но начнем мы с основ, с того, что лежит в фундаменте Nutanix как архитектуры и решения, с Nutanix Ditributed File System, NDFS.


    Как следует из названия, NDFS — это распределенная, кластерная файловая система.

    Одной из наиболее важных проблем для работы кластерной распределенной файловой системы, которую приходится решать разработчику таковой, является проблема работы с так называемыми метаданными.
    Что такое «метаданные», и чем они отличаются от собственно «данных»?
    У любых данных, которые мы храним на системе хранения, всегда присутствуют связанные с ним вспомогательные данные. Это, например, имя файла, путь к этому файлу, то есть то, где он расположен в структуре хранения, его атрибуты, размер, время создания, время изменения, время доступа, какие-то битовые атрибуты, как, например, «только для чтения», а также права доступа, от самых простейших, то развернутых ACL. Эти данные не являются собственно нашими хранимыми данными, но они с ним связаны, и обеспечивают доступ к данным. Вот эти дополнительные данные и принято называть «метаданными». Как правило, обращение к данным начинается с доступа к метаданным, хранимым в файловой системе, а уже с их помощью OS может начать работать с данными.
    Проблема начинается тогда, когда желающий поработать с данными становится не один. С одним — все просто. Считал путь к файлу, прочитал нужный кусок, изменил, записал, если нужно — исправил метаданные. Но что делать, когда в то время, пока один процесс, на одной кластерной ноде, записывал в файл свои изменения, этот файл прочитал и начал вносить свои изменения другой процесс с другого узла?

    Одна из уже классических ошибок начинающих сисадминов, это смонтировать по iSCSI с системы хранения на два и более сервера ее LUN (физически это вполне возможно), отформатировать его в какой-нибудь NTFS, после чего попытаться на него читать и писать с разных серверов. Кто уже это проходил — знает, что происходит дальше. Кто еще на это не натыкался — рассказываю. Все идет хорошо, пока записывает на такой «диск» только один сервер. Как только записывать начинает второй — файловая система немедленно (более или менее фатально) рассыпается. Почему? Потому что NTFS не кластерная файловая система, и ничего не знает о ситуации, когда в нее могут параллельно писать два разных сервера на одну файловую систему.


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

    Например, те, кто пытался ставить множество (сотни) виртуальных машин на один LUN в VMFS-раздел (а VMFS это классическая кластерная файловая система с блокировками, с помощью механизма SCSI Locks), те знают, что при большом числе операций с метаданными, LUN с VMFS порой сильно и неприятно «тормозит». А «операции с метаданными» это, например, перезагрузка VM, изменение размеров VMDK, создание, удаление и расширение VMFS datastore на LUN-е, создание templates или развертывание VM из template, все это вызывает блокировку LUN и кратковременную приостановку ввода-вывода целиком, для всех VM на нем. Частично с этой проблемой борются с помощью Atomic Test and Set locking, переложенной на систему хранения, если та поддерживает VAAI, но это, все равно, часто, решает проблему только частично.

    Поэтому вопрос создания хорошей, по-настоящему широко масштабируемой кластерной системы это, часто, вопрос создания хорошо масштабируемой схемы работы с метаданными.
    При создании NDFS для хранения метаданных файловой системы в кластере была использована NoSQL база данных Apache Cassandra, первоначально разрабатывавшейся внутри Facebook, а затем отданной в OpenSource. Ее уже не в первый раз используют в подобном качестве, поскольку она прекрасно масштабируется, но почти всегда, вместе с проблемой масштабирования возникает и проблема консистентности базы в масштабах кластера. Поэтому перед разработчиками Nutanix встала задача обеспечить не просто распределенность (например, Cassandra распределенно работает в Facеbook, на кластерах в тысячи узлов), но и консистентность. Для Фейсбука не слишком большая проблема, что ваши фоточки в фотосете обновятся не моментально на всех узлах кластера, но для Nutanix консистентость метаданных хранилища является критически важной. Поэтому, так сказать vanilla-Cassandra была существенно переработана, чтобы обеспечить необходимую консистентность хранения в кластере, то, чего не хватало в исходной реализации базы.

    При этом, за счет распределенности Cassandra в системе, нет никакого «главного узла», отказ которого может повлиять на работоспособность кластера в целом. База метаданных распределена по кластеру и никакого «главного узла», «старосты файловой системы», единственно управляющего доступом к метаданным, у Nutanix нет.

    Каким же образом происходит работа и доступ к дискам в кластере Nutanix?
    На «крупноблочном» уровне эта работа выглядит так:

    image

    Неожиданным для многих будет то, что Nutanix не использует технологии RAID для обеспечения высокой доступности данных на дисках. Мы настолько привыкли к RAID на дисках в энтерпрайз-системах, что заявление об «отсутствии RAID» часто вызывает недоумение. «А как же необходимая надежность дискового хранения?» Все верно, RAID нет. Но, тем не менее, обеспечивается избыточность данных, и обеспечивается она способом, который у нас принято называть RAIN — Redundant Array of Independent Nodes. Избыточность хранимых данных обеспечивается тем, что, на логическом уровне, каждый записываемый блок данных записывается не только на диски того узла кластера, которому он предназначается, но и, одновременно и синхронно, также на диски еще одного (или двух, как опция) другого узла.

    Что дает отказ от RAID? Прежде всего это более быстрое и гибкое восстановление в случае потери диска, а, следовательно, выше надежность, ведь на время восстановления в классическом RAID его надежность снижена, к тому же, вдобавок, падает и производительность дисковых операций, так как RAID-группа занята своими внутренними процессами чтения и записи блоков для восстановления.
    Во-вторых — это гораздо бОльшая гибкость размещения данных. Файловая система знает, куда и какие блоки данных записаны, и может восстановить ровно то, что необходимо в данный момент, или записывать так, как это оптимально для данных, так как полностью контролирует весь процесс записи данных на физические диски, в случае RAID-контроллера логически отделенных от уровня операций OS.

    Как же организуется доступ к дискам?
    Во-первых, вы помните, что Nutanix — это платформа для гипервизора. Все задачи внутри сервера Nutanix крутятся поверх baremetal hypervisor, например ESXi, MS Hyper-V или Linux KVM.

    Среди виртуальных машин есть одна — специальная, она называется CVM, или Controller VM. Это так называемый «virtual appliance», внутри которого работает вся кухня формирования и обеспечения файловой системы Nutanix. Физически, CVM — это виртуальная машина под Centos Linux, с многочисленными нашими сервисами, например, об Apache Cassandra, NoSQL-хранилище метаданных файловой системы, я уже рассказал выше, а кроме этого там работает разнообразный «зверинец» процессов, обеспечивающий все, что Nutanix умеет. Вообще, если уж заостряться, то Nutanix — это вот эта самая CVM и есть, это — его сердце и мозг, и главная intellectual property.
    Но внутри гипервизора это просто одна большая виртуальная машина со множеством специальных процессов в ней.

    Эта виртуальная машина, как видно на схеме, пропускает через себя трафик ввода-вывода виртуальных машин к их виртуальным дискам. Физические диски находятся для OS виртуальных машин не только «за гипервизором», но и за CVM. И уже CVM-ы всех кластерных нодов, включенных в общий кластер создают из физических дисков, из отдельных SSD и HDD, прямо замапленных в них, общее пространство. Создают и отдают его гипервизору, который видит уже общее хранилище. Хранилище это CVM отдает в форме, наиболее удобной для данного гипервизора. Например для VMware ESXi это будет «виртуальный» NFS-сторадж, для 2012R2 Hyper-V — сторадж по протоколу SMB3, а для KVM — iSCSI.
    Для каждого гипервизора (а сейчас поддерживается три перечисленных) у нас сейчас делается свой CVM, который устанавливается в гипервизор в ходе первоначальной установки кластера.

    Процесс, который обеспечивает ввод-вывод по выбранным протоколам, между физическими дисками с одной стороны, и VM на гипервизоре с другой, называется Stargate, а процесс, который занимается распределением задач по кластеру нодов, в том числе всеми Map-Reduce задачами, например балансировкой нагрузки по нодам, скраббинг (онлайн-проверка целостности) дисков — Curator. Prism — это интерфейс управления, в том числе GUI, а Zookeper (также продукт из лаборатории Apache) — хранит и обслуживает конфигурацию кластера.

    image

    Так как, как я уже рассказывал выше, Nutanix не использует RAID, и раскладывает блоки данных по дискам самостоятельно, это дает ему большую гибкость. Например, вы видите на схеме диски SSD. На них хранится так называемый hot tier, то есть те блоки данных, к которым идет активное обращение, считывание или изменение. На hot tier также попадают записываемые на диски блоки. Там же они остаются до тех пор, пока они не буду из-за неактивности вытеснены на cold tier, на HDD SATA. Причем, так как «раскладыванием» блоков по дискам занимается сама кухня Nutanix в CVM, она полностью контролирует то, где и как, какие и как долго блоки будут лежать.

    Соединяя ноды кластера Nutanix в единый кластер, мы получаем вот такую структуру:

    image

    Непосредственно поверх физических дисков располагается хранилище данных. Данные хранятся в форме экстентов, то есть последовательно располженных, адресуемых цепочек блоков, и групп этих экстентов. В качестве адресуемого хранилища было принято решение использовать хорошо отработанную файловую систему ext4, из которой используется только функция хранения и адресации экстентов. Вся логика работы с метаданными, как я рассказывал выше, вынесена на уровень самого Nutanix.
    На схеме ниже желтое — физические диски SSD и HDD SATA, зеленое — NDFS, состоящая из ext4 как extent store данных и кластерного хранилища метаданных в Cassandra, и, наконец, поверх них располагаются блоки данных файловых систем «гостевых» VM OS, это уже будут NTFS, ext3. XFS, или что пожелаете.

    image

    В следующих постах я планирую продолжать «техническую» часть рассказа о том, что происходит у Nutanix «под капотом», например, подробнее о том, как обеспечивается работа RAIN и отказоустойчивость, как работает дедупликация и компрессия, как реализован распределенный кластер и как работает репликация данных для DR, как можно делать резервные копии, и многое другое интересное.

    Если вы только что подключились к нашему хабу, то вам, скорее всего, будет интересно прочитать и другие публикации о Nutanix на Habrahabr:
    http://habrahabr.ru/company/nutanix/blog/240859/

    Кроме того, желающим углубиться в тему хочу порекомендовать блог, к в котором также можно найти множество технических статей про то, как работает Nutanix «под капотом».
    http://blog.in-a-nutshell.ru
    Nutanix 31,10
    Компания
    Поделиться публикацией
    Комментарии 33
    • +1
      А цифры, цифры-то где?
      IOPS, максимальный объем и т.д.
      Я так и не понял, на каждой ноде своя CVM или одна на кластер?
      Как обеспечивается ее отказоустойчивость?
      • 0
        На каждой ноде своя CVM.

        Исходя из этого, понятия максимального размера не существует — так как нет никакого лимита роста. Старт с 3-х нодов (серверов), потолка не существует. В мире есть инсталляции Cassandra на тысячи (десятки тысяч) серверов.

        IOPS — опять-же, рост линейный.

        Коробка 2U (4 нода, готовый кластер под ключ) выдает около 130000 IOPS на чтение и около 60000 IOPS на запись.

        Места на ней — 16TB SATA + 6.4TB SSD (гибридная ФС).

        10 коробок (20U, пол стойки) выдадут соответственно 1.3 миллиона IOPS на чтение и 600 тысяч на запись.

        Вот например видео с демонстрацией миллионов IOPS при масштабировании.

        https://www.youtube.com/watch?v=B-RBDtKgQTo

        Отказоустойчивость — двойное или тройное резервирование данных (те самые экстент группы, описанные в статье), в sync кластере может выйти из строя 8 узлов (серверов) одновременно и никаких потерь данных от этого не будет.

        Подробнее об архитектуре будем рассказывать в дальнейших статьях.
        • 0
          Понятно, спасибо.
          Цифры впечатляют.
          Я спрашивал про отказоустойчивость CVM.
          Допустим, на ней случился kernel panic при записи данных.
          Что будет с данными? К примеру, с транзакциями базы данных?
          Судя по скоростных характеристикам, у вас скорее всего Write-Back система, что означает неконсистентность данных.
          P.S. Максим, а вы никакого отношения к blog.aboutnetapp.ru не имеете?:)
          • 0
            Если бы у нас было Write-Back, цифры были бы в разы больше :)

            Указанные цифры — для 100% гарантированной записи данных в двух копиях, для трех — около 15% ниже.

            Если БД получила результат операции ввода-вывода, это означает 100% гарантию консистентности.

            Как указано в статье — мы очень сильно «пилили» Кассандру как раз в строну консистентности (по CAP теореме — вместо AP мы перешли к CA)

            Это означает, что сбоев CVM мы не боимся абсолютно, даже если случится kernel panic.

            А в общем-то паниковать там нечему, это абсолютно немодифицированное ядро Centos.

            Учитывая-то что это ext4 (900+ миллионов инсталляций в мире, включая все Android телефоны) и centos 6.5 (миллионы инсталляций) — работает Nutanix ультра-стабильно, не зря на наших решениях сидят множество военных и правительственных служб США, а в офис недавно приезжал бывший министр обороны США (Роберт Гейтс)
            • 0
              «для трех — около 15% ниже.» -> «для трех — производительность около 15% ниже.»
              • 0
                А какая задержка получается?
                • 0
                  С задержками тоже все очень хорошо, если правильное сетевое оборудование (Arista Networks например) используется — у них на TOR коммутаторах 320-350ns задержка (очень близко к infiniband).

                  Очевидно, что задержки сильно зависят от загрузки системы и включенного фунционала (дедупликация на лету, компрессия и тд).

                  Фактически, latency сильно ниже чем FC SAN — ибо средняя задержка FC коммутатора 700ns, а если строить SAN Fabric — и того выше.

                  Опять-же, насколько я знаю — мы единственные на рынке кто делает локализацию ввода-вывода («таскаем» горячие данные вслед за VM по кластеру), тобишь все операции чтения идут со скоростью локальной шины. Именно поэтому на чтение — в два раза больше IOPS.
                  • +1
                    Спасибо, интересно! Сетевыая latency важна, но zookeeper обеспечивает не так много операций записей в секунду — с десяток тысяч в зависимости от IOPS записи файла его лога. А также чем больше узлов в zookeeper, тем медленнее происходит запись из-за того что кворум зукиперов должен записать данные для гарантии целостности. Также в zookeeper точно были race condition при старте, выясняли коллеги тестами в кластере.
                    Также надо как либо хранить его снепшоты, для восстановления в случае выхода ЦОД из строя. WAN репликация для zookeeper просто нереальна, т.к. сильно увеличивает время записи в кворуме между разными ЦОД…
                    Ну и curator всего лишь удобная обертка и набор алгоритмов для zookeeper…
                    Как у вас решаются все эти проблемы?
                    • +1
                      Zookeeper у нас во-первых сильно доработанный (так-же как Cassandra), во-вторых — на него минимальная нагрузка на запись, ибо все что от него требуется — хранить конфигурацию кластера (и не более того), причем конфиги у нас хранятся только на SSD и даже десяток тысяч IOPS в секунду с зукипера дает возможность за секунду обновить конфиги кластера на десяток тысяч нодов.

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

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

                      Далее, для RF3 — у нас 5 инстансов зукипера, что позволяет избежать проблему split brain.

                      Для WAN репликации zookeper не используется у нас, еще раз — он нужен только для хранения конфигурации кластера и не более того.

                      p.s. Кстати на прошлом HighLoad++ был хороший доклад на эту тему, сравнение различных хранилищ.
                      • 0
                        Спасибо за подробный ответ! Есть ли у вас ссылка на эту презентацию по сравнению хранилищ. Думаю многие здесь вам будут благодарны)
                        Но все-таки как вы выполняете DR для zookeeper между датацентрами или при DR не важна вся конфигурация, которая в нем хранится.
                        Кстати, что вы понимаете под конфигурацие кластера? IP адреса хостов гипервизоров и стореджей, статусы компонент, ...?
                        • +1
                          Сравнивать хранилища нам нет смысла, ибо Nutanix — это не хранилище.
                          NDFS — это просто один из базовых элементов. Почитайте Nutanix Bible и я думаю сами прекрасно сможете ответить в чем отличия (там ну очень детально все описано).

                          stevenpoitras.com/the-nutanix-bible/

                          Для аналогии — это примерно как просить сравнить Oracle SQL RAC с SQLite :)



                          Мы не синхронизируем zookeeper вообще. Конфигурация кластера — да, верно — это редкоизменяемые данные (IP адреса и прочие конфиги).

                          О Nutanix DR и Metro Cluster можно почитать тут:

                          www.nutanix.com/blog/2014/10/14/nutanix-metro-availability/
                          www.nutanix.com/blog/2013/07/25/replication-topologies-for-successful-enterprise-dr-initiatives-2/

                          Идея в том что у нас репликация не ориентируется на датасторы никоим образом, но на контейнеры (виртуальные объекты) и виртуальные машины сами. Работает это между различными кластерами (в одном или многих ДЦ), причем оборудование и его количество может отличаться.

                          • 0
                            Спасибо за информацию!!! Почитаю чуть позже
                            • 0
                              Сравнивать хранилища нам нет смысла, ибо Nutanix — это не хранилище.
                              NDFS — это просто один из базовых элементов. Почитайте Nutanix Bible и я думаю сами прекрасно сможете ответить в чем отличия (там ну очень детально все описано).


                              Но обсуждение-то идет в статье про NDFS вот поэтому про хранилище я вас и спрашиваю.
                              • 0
                                Мы не сравнивали, не видим практического смысла.

                                На рынке Enterprise (куда мы в первую очередь нацелены) Gluster / CEPH вообще не игроки, мы же в свою очередь не идем на рынок больших интернет проектов (где как раз лучше использовать тот-же GlusterFS ввиду бесплатности и незаточенности под виртуализацию).

                                Можно разбирать Nutanix на части и каждую из компонент с чем-то сравнивать, но это просто лишняя трата времени.

                                Там где пересекаемся — это рынок сервис-провайдеров, но и тут это разные рынки — для ДЦ / сервис-провайдеров которые предоставляют услуги корпоративным клиентам, работа с ESXi / HyperV / KVM и наличие массы функционала энтерпрайз-уровня в Nutanix / NDFS (такие как VAAI, DR, Metro Sync, Data Locality, Inline / Post-process compression / dedup, tiering и многое другое) — ключевой вопрос.

                                И наоборот, для рынка «копеечных VM» Nutanix будет неоправданно дорог, но GlusterFS / Ceph очень хороши.

                                При этом, если вам нужно получить просто датастор — Ceph или GlusterFS вполне интересные варианты.

                                По совокупности характеристик на данный момент мы предлагаем уникальное, но достаточно дорогое решение.
                                Для понимания — средний размер чека по нашим проектам в РФ сейчас от 600000$ (в мире немного ниже).
                • 0
                  Понятно, тогда у вас просто отличные показатели:)
                  И все же я немного не верю, что можно бесконечно горизонтально масштабировать систему, все равно куда-нибуть упремся — например, в сеть.
                  • 0
                    А чего в сеть-то упираться? Гугл же не упирается?

                    Например, есть коммутаторы Аристы — Всего 11U на 1152x10G портов.

                    http://www.arista.com/en/products/7500-series


                    14+Billion PPS и 30Tbps Fabric

                    Это 570 нодов в кластере на один коммутатор, а с резервированием — 1140 нодов на два коммутатора

                    1140 нодов — это около 40 миллионов IOPS :) А так-же 22800 ядер уровня Ivy Bridge 2.8Ghz, 570TB RAM и тд

                    В мире есть считанное количество компаний которым столько нужно.

                    При том что у нас за счет ультра-быстрого I/O — плотность VM очень высокая, для типового VDI — в районе 400 виртуальных машин на 2U блок. 1140 нодов = 285 блоков = 114000 VM.

                    Пока у нас самые крупные проекты — максимум 50 тысяч VM на один кластер требовалось, больше просто не встречалось необходимость.
                • 0
                  p.s. Блог о нетапе вел Роман, эту статью в нашем блоге писал он. Сейчас Роман — работник Nutanix :)
                  • 0
                    Ага, понятно, а то стиль знакомый, я, как бывший, но все еще сертифицированный инженер по NetAppу часто читал его блог:)
                    • 0
                      Роман — ценный кадр в нашей компании ;)
                    • 0
                      То-то, я думаю, мне так Nutanix стало хотеться купить, как в свое время NetApp. :)
                  • +1
                    В чем преимущество вашей системы хранения перед, например, glusterfs. Там так же применяется share nothing архитектура хранение метаданных, но без zookeeper и тюнинга параметров GC JVM!

                    Тот же сегмент, ориентированный в первую очередь на хранение образов виртуальных машин, но открытый исходный код, интеграция с hadoop в качестве замены HDFS, платная поддержка RedHat.

                    Ваша компания составляла какое-либо сравнение по фичам, стоимости владения и т.п.?
                    • +1
                      Интересный вопрос, любим такие ;)

                      Glusterfs — это проект (весьма хороший кстати), который заточен под хранение данных но не виртуализацию.

                      Отсутствуют даже простейшие вещи как локализация ввода-вывода VM (когда горячие данные виртуальной машины переезжают на локальную ноду вслед за ней).
                      Только свой формат работы с ФС (засим — фактически только KVM).

                      Nutanix — это продукт High-End уровня, поддерживающий все современные гипервизоры (HyperV, ESXi, KVM), созданный изначально под виртуализацию.
                      Нативно поддерживаются стандартные протоколы — NFS, iSCSI, SMB3 (который мы сами написали ввиду того что Samba нас не устроила)

                      Функционал различается колоссально.

                      Если же сравнивать продукты ( Red Hat Enterprise Storage и Nutanix), то опять-же у нас все намного интереснее — та-же система управления KVM (Acropolis), сделанная на NoSQL и безлимитно масштабируемая.

                      Кстати вот забавная статья, где человек пишет что был бы очень рад видеть NDFS отданным в комммьюнити «Personally, I’d love to see Nutanix add some real gasoline to their support of Open Source by contributing NDFS back to the community as an upstream project. „

                      “Nutanix vs. GlusterFS or Projects are not Products»

                      blog.gluster.org/category/tech/

                      Табличка (неполная), о том что умеет Nutanix / NDFS

                      www.nutanix.com/software/
                      CORE DATA SERVICES
                      vSphere & Hyper-V Support • • •
                      Heterogeneous Clusters • • •
                      MapReduce Tiering • • •
                      Inline Compression • • •
                      Inline Performance Deduplication • • •
                      MapReduce Compression • •
                      MapReduce Deduplication • •
                      KVM Support • •
                      RESILIENCE
                      Data Path Redundancy • • •
                      Tunable Redundancy Factor 2 2 or 3 2 or 3
                      Availability Domains • •
                      DATA PROTECTION
                      VMCaliber Snapshots • • •
                      VMCaliber Clones • • •
                      Single Site DR (1-to-1) • • •
                      Online Cluster Grow/Shrink • • •
                      Time Stream • •
                      SRA Integration • •
                      VSS Integration • •
                      Multiple Site DR (1-to many, many to many) •
                      Metro Availability •
                      Cluster Shield •
                      Common Access Card •
                      MANAGEMENT & ANALYTICS
                      Prism Element • • •
                      Pulse • • •
                      Cluster Health • • •
                      One-click Upgrades • • •
                      Prism Central • •
                      Rest APIs • •

                      По поводу HDFS — если делать map/reduce на Nutanix NDFS (тот-же teragen прогнать), то на одинаковом железе около 5 раз ускорение получается — это к вопросу об эффективности.
                      • 0
                        Спасибо!!!

                        По поводу HDFS — если делать map/reduce на Nutanix NDFS (тот-же teragen прогнать), то на одинаковом железе около 5 раз ускорение получается — это к вопросу об эффективности.

                        Вполне логично что почти любая файловая система, написанная на компилируемом языке и без сборщика мусора, будет производительнее чудесной HDFS на java. В исходниках HDFS в 2008 году мне пришлось провести много времени и я был неприятно поражен, особенно не потоко безопасным на тот момент клиентом этой файловой системы.

                        Отсутствуют даже простейшие вещи как локализация ввода-вывода VM (когда горячие данные виртуальной машины переезжают на локальную ноду вслед за ней).
                        Только свой формат работы с ФС (засим — фактически только KVM).

                        Не проверял пока, но утверждают что они позволяют работать с glusterFS как NFS диском. По поводу миграции данных на хост на который мигрирует виртуальная машина, настраивают даже гео репликацию
                        Из extended posix аттрибутах файлов можно понять data affinity и запустить VM на соответствующем хосте. Но вы правы, похоже в glusterFS есть недоработка для этого применения.
                        On GlusterFS, MapReduce jobs use “data locality optimization”.
                        That means Hadoop tries its best to run map tasks on nodes where the data is present locally to optimize on the network and inter-node communication latency.
                        говорится в презентации.

                        Glusterfs extended attribute "Trusted.glusterFS.pathinfo" позволяет узнать на каких узлах хранилища есть реплики образа VM и остается запустить виртуальную машину именно на нужном хосте.
                        • 0
                          «будет производительнее чудесной HDFS на java. „


                          Вопрос лишь в том — насколько производительнее. У нас метаданные в NoSQL. Что весьма уникально и дает как раз ту самую сверх-производительность.

                          “Не проверял пока, но утверждают что они позволяют работать с glusterFS как NFS диском. „

                          Это эмуляция, никто в здравом уме не будет GlusterFS например использовать для ESXi под серьезные задачи. Там нет даже failover.

                          Подходит под простенькие задачи типа веб сервинга.

                          Using a platform's native NFS client will result in best performance when reading many small files (web serving). However, no automatic fail-over will happen in case of brick failure.

                          Note: NFS should not be used to support the lock volume used by CTDB as NFS does not currently support locking. Instead, use the Gluster native mount.

                          gluster.org/community/documentation/index.php/Gluster_3.2:_Using_NFS_with_Gluster

                          “That means Hadoop tries its best to run map tasks on nodes where the data is present locally to optimize on the network and inter-node communication latency.»


                          И причем тут собственно Hadoop-то? Да, он пытается. Но hadoop — это всего лишь одна из миллионов типов задач / нагрузок которые бывают. Вы предлагаете учить все ПО работать с GlusterFS? :))))

                          «и остается запустить виртуальную машину именно на нужном хосте.»


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

                          • 0
                            Согласен с вашими аргументами про enterprise и комплексное решение.
                            Вообще-то это с точностью до наоборот — вы принуждаете запускать VM там где данные, а надо — там где хочет клиент (причин может быть множество, в том числе лицензирование аппаратных хостов (Oracle / MS и тд), аппаратные ресурсы доступные (процессоры / память и прочее), множество других.

                            Действительно, я предложил костыль, но в некоторых случаях он может быть решением. Конечно, это не подойдет для клиентов, которые раскошелились от 600000$ на платформу, но решили сэкономить немного на лицензиях MS/Oracle.

                            И причем тут собственно Hadoop-то? Да, он пытается. Но hadoop — это всего лишь одна из миллионов типов задач / нагрузок которые бывают. Вы предлагаете учить все ПО работать с GlusterFS? :))))

                            Меня не очень интересует платформа виртуализации, но раз уж статья называется «NDFS — Nutanix Distributed File System, «фундамент» Nutanix» считаю вполне логично расспрашивать про разные аспекты применения распределенной файловой системы. И hadoop сейчас довольно популярен, даже в тех проектах где он не особо нужен, бывает такая прихоть заказчиков.

                            Не обязательно все ПО писать с учетом extended атрибутов файловой системы, но Data Locality впринципе хорошая идея в распределенных системах. Если ее не учитывать, то до определенных масштабов спрятать интенсивную передачу данных смогут infiniband FDR 4X или 50G ethernet
                            По поводу HDFS — если делать map/reduce на Nutanix NDFS (тот-же teragen прогнать), то на одинаковом железе около 5 раз ускорение получается — это к вопросу об эффективности.


                            Ну и чисто по скорости — при mapreduce тестах, просто подменой HDFS на NDFS ускорение в разы (это буквально).


                            Вот и интересно какой трафик у вас был в ваших тестах, т.к. похоже по вашим ответам что «если делать map/reduce на Nutanix NDFS» и не учитывать Data Locality/Affinity, то все волшебство будет просто в быстрой сети с низкими задержками. А Data Locality в этом случае относится только к перемещению образов виртуалок на хост к гипервизору.
                            • 0
                              " И hadoop сейчас довольно популярен


                              Никто не спорит. Hadoop — одно из множества применений, под которые Nutanix прекрасно подходит. У нас в том числе в РФ есть заказчики которые очень крупные проекты на Hadoop и прочих BigData технологиях делают именно на Nutanix.

                              Но если брать чисто Hadoop задачи — то Nutanix чаще всего будет серьезным overkill (ничто не сможет перебить сервера набитые дисками и linux + hadoop сверху), хотя «крупняки» любят как раз за то что на одном кластере могут пачки разных хадупов версий гонять + другие BigData технологии. Вот тут виртуализация уже незаменима. Позавчера лично в Цюрихе запускал Nutanix для Hadoop в одном из крупнейших банков в мире (с HQ в Швейцарии).

                              " Если ее не учитывать, то до определенных масштабов спрятать интенсивную передачу данных смогут infiniband FDR 4X или 50G ethernet"

                              Смогут конечно. тут как говорится кесарю кесарево. для многих задач и одного сервера хватит с ext4.

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

                              Мы сделали решение, которое реально безлимитно масштабируется. Самая крупная (пока) инсталляция — 2000 нодов. Кластер — ну скажем так, возможно тот из-за которого Сноуден в РФ живет :)

                              Но забивать микроскопом гвозди никто не предлагает.

                              Меня не очень интересует платформа виртуализации


                              NDFS — ФС для платформы виртуализации, в отрыве ее воспринимать бессмысленно. Именно для этого делалась первая статья в нашем блоге — общий обзор Nutanix.

                              http://habrahabr.ru/company/nutanix/blog/240859/

                              То, как сделана NDFS (в виде виртуального контроллера / машины), как-бы уже должно очень явным образом на это намекать.

                              Изоляция сбоев и прочие радости, которых лишены «классические» кластерные системы типа GlusterFS / Ceph.

                              будет просто в быстрой сети с низкими задержками.


                              Нет, волшебство в очень грамотной архитектуре ФС и кластера, использовании лучших bigdata технологий с существенной доработкой, найм людей которые делали эти разработки (ключевые инженеры гугл, facebook, amazon и тд), которые заняты только этими задачами.
                              • 0
                                Позавчера лично в Цюрихе запускал Nutanix для Hadoop в одном из крупнейших банков в мире (с HQ в Швейцарии).

                                Это случаем не мои позапрошлые работодатели, UBS? ))))

                                NDFS — ФС для платформы виртуализации, в отрыве ее воспринимать бессмысленно.


                                Я вас понял. Спасибо вам за ответы!
                                • 0
                                  Это случаем не мои позапрошлые работодатели, UBS? ))))

                                  Без комментариев :)))
                      • 0
                        Вот еще коротко и достаточно ясно описано

                        blog.appcore.com/distributed-file-systems-brceph-vs-gluster-vs-nutanix

                        Заключение объективное — «The self management capability of storage makes Nutanix one of the most turn key solutions on the market. „
                  • –1
                    iSCSI… Потому что NTFS не кластерная файловая система, и ничего не знает о ситуации

                    Дело не в NTFS, дело в том, что iSCSI это block-level device. В сервер экспортируется именно оно. И ломается FS именно потому, что можно одновременно переписать блоки, о чем вышележащая FS не узнает в принципе. ЛЮБАЯ FS.
                    • +1
                      Почему любая FS?
                      Возьмем, например, OCFS2. Существуют и другие Shared-disk файловые системы и их не так уж и мало.
                      • 0
                        Если задаться вопросом, то на десятки счет пойдет ;)
                      • 0
                        Насчет «любой ФС» — сильно сказано.

                        Существует множество FS (в том числе упомянутая VMFS) которые вполне себе работают в кластерном режиме.

                        Причем тут блочный доступ — совершенно непонятно. Вы хотите сказать что при блочном доступе невозможно иметь кластерную ФС? :) Тогда вы сильно ошибаетесь, существует множество вариантов ФС кластерных которые работают поверх FC / iSCSI например.

                        Другой разговор, что они (почти все) имеют из-за этого ограничения — нужно синхронизировать блокировки файловой системы (locks), дабы избежать одновременной записи в один блок, при этом этот самый механизм блокировок является узким местом (централизация) — например так работает IBM GPFS.

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

                      Самое читаемое