Nutanix Community Edition

Материал из Национальной библиотеки им. Н. Э. Баумана
описание

История компании

Компания основана в Кремниевой долине в 2009 году ключевыми инженерами Google (разработчиками Google Filesystem), Facebook, Amazon и других глобальных проектов, с 2012 года расширяется в Европу и подключает инженеров из ключевых Европейских команд (например, Badoo).

Компания названа самым быстрорастущим технологическим стартапом последних 10 лет, уже вошла в рейтинг Gartner как визионеры (технологические лидеры) индустрии конвергентных решений.

По мнению Forbes, является лучшим в мире «облачным» стартапом для работы.

Технические детали

Базируется на open-source компонентах, доведенных до ума:

  • Cassandra для хранения метаданных файловой системы,
  • Apache Zookeper для хранения конфигурации кластера,
  • Centos Linux и файловая система EXT4.

Активно используют BigData технологии внутри.

Вместо использования сложных и медленных RAID систем, данные должны разбиваться на блоки (так называемые extent groups в данном случае) и “размазываться” по кластеру с нужным количеством копий, причем в P2P режиме. Отсюда вытекает новый для многих (но не для рынка) термин — RAIN (Redundant/Reliable Array of Inexpensive/Independent Nodes) — резервируемый/надежный массив из недорогих/независимых нодов. Ярким представителем данной архитектуры как раз и является Nutanix.

Преимущества

  • Быстрый цикл разработки и обновлений
  • Отвязка от зависимостей к пропиетарному оборудованию
  • Использование стандартного оборудования для решения задач любых масштабов.

NDFS - «основа Nutanix»

В фундаменте Nutanix как архитектуры и решения лежит Nutanix Ditributed File System, NDFS. Как следует из названия, NDFS — это распределенная, кластерная файловая система.

Одной из наиболее важных проблем для работы кластерной распределенной файловой системы, является проблема работы с так называемыми метаданными.

Метаданные

Что такое «метаданные», и чем они отличаются от самих хранимых «данных»?

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

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

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

Хранение метаданных

При создании NDFS для хранения метаданных файловой системы в кластере была использована NoSQL база данных Apache Cassandra, первоначально разрабатывавшейся внутри Facebook, а затем отданная на OpenSource. Она хорошо маштабируется, но как правило проблема маштабирования не приходит одна, а ведет с собой проблему консистентности базы в масштабах кластера.

Разумеется, эта проблема не всегда столь критична - например, для систем вроде Facebook не критично, что аватарка пользователя обновится не моментально на всех узлах кластера, в то время как в других системах этот вопрос стоит очень остро. В Nutanix существенно переработали Cassandra, чтобы обеспечить необходимую консистентность хранения в кластере, то, чего не хватало в исходной реализации базы.

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

Отказ от RAID

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

Преимущества отказа от RAID

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

Организация доступа к дискам

Во-первых, 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, внутри гипервизора это просто одна большая виртуальная машина со множеством специальных процессов в ней.

Эта виртуальная машина, пропускает через себя трафик ввода-вывода виртуальных машин к их виртуальным дискам. Физические диски находятся для ОС виртуальных машин не только «за гипервизором», но и за CVM. И уже CVM всех кластерных нодов, включенных в общий кластер, создают общее пространство из отдельных физических дисков. Создают и отдают его гипервизору, который видит уже общее хранилище. Это хранилище CVM отдает в форме, наиболее удобной для данного конкретного гипервизора (см. таблицу).

Гипервизор Форма хранилища
VMware ESXi «виртуальный» NFS-сторадж
2012R2 Hyper-V сторадж по протоколу SMB3
KVM iSCSI

Для каждого гипервизора, поддерживаемого Nutanix, сейчас делается свой CVM, который устанавливается в гипервизор в ходе первоначальной установки кластера.

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

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

NUtanixStructure.png

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

NutanixStorage.png

Минимальные технические требования для установки Nutanix Community Edition

  • 1, 3 или 4 (внимание! 2 сервера — не поддерживается) сервера (или «нода») с 4+ ядрами и поддержкой Intel VT-x,
  • минимум один SSD диск (можно и all-flash (!)) от 200GB,
  • 1 или больше HDD (холодный уровень хранения) от 500GB
  • 16+ гигабайт ОЗУ (очевидно, что лучше 64+ если вы планируете запускать серьезные виртуальные машины),
  • 1G или 10G сетевая плата (по ряду причин поддерживается только Интел)

Ссылки