Nutanix «под крышкой»: как обеспечивается надежность хранения данных

nutanix-front3

Этим постом я начну серию «Nutanix под крышкой», переводов официальных technotes о внутреннем устройстве системы, который сейчас пишутся и постепенно выкладываются в resources на офсайте продукта.
В этом посте вы узнаете, как обеспечивать надежность хранения и сохранность данных, не используя RAID, каким образом хранятся данные на дисках, и как они оказываются доступны прикладным задачам, что такое «метаданные», и какую роль они играют в работе системы хранения Nutanix, наконец, что за механизмы приводят все это в движение.

Надежность хранения данных

Nutanix Virtual Computing Platform разработан и сконструирован «с нуля», чтобы обеспечить максимальную надежность так, чтобы успешно парировать возможные отказы оборудования и программные ошибки. Распределенная программная архитектура запускает виртуальный контроллер хранения (virtual storage controller, также Controller VM или CVM) на каждом узле кластера, составляющих вместе распределенную систему. Все узлы работают совместно, собирая отдельные, непосредственно-подключенные (DAS) к этим узлам диски в общее «пространство имен» (single global namespace), которое может быть использовано всеми хостами. Все диски кластерной системы управляются специальной структурой, называющейся Nutanix Distributed Filesystem (NDFS), которая обеспечивает целостность хранимых данных, и защищает их от сбоев узла, самих дисков, или программных ошибок.

Защита данных

NDFS использует в работе так называемый Oplog (сокращение от operations log, это аналог журнала в отказоустойчивой файловой системе) как своеобразный кэш, чтобы быстро обработать входящие операции записи, записав их на SSD, устройство с высокой производительностью и малыми задержками операций. Затем данные собираются вместе, и асинхронно сливаются на нижележащий уровень, состоящий из обычных жестких дисков, и носящий название Extent Store. Extent Store хранит в себе так называемые «экстенты», структуры данных, представляющие собой протяженные последовательные фрагменты данных vDisk переменной длины, то есть «файлы NDFS».
NDFS реализует полностью распределенный дизайн файловой системы, предотвращая потери данных Oplog, например в результате отказа данного аппаратного узла. Перед тем, как какая-либо операция записи будет отрапортована ее хосту как успешно записанная, оплог будет синхронно реплицирован на соседние узлы. Все узлы кластера в равной мере участвуют в процессах репликации. Только после того, как данные, и связанные с ними метаданные, будут успешно отреплицированы, хост получит подтверждение, что операция была успешно завершена и данные были успешно записаны. Это гарантирует, что данные будут храниться как минимум в двух независимых узлах кластера, и структура данных будет отказоустойчива.

Защита метаданных и надежность

Метаданные и маппинг vDisk-ов на соответствующие им экстенты хранится в строго консистентной, распределенной NoSQL-базе данных Cassandra. Cassandra обеспечивает высокодоступную и инкрементально-масштабируемую платформу хранения метаданных NDFS. По умолчанию, репликация метаданных происходит на, как минимум, два других узла кластера, обеспечивая избыточность метаданных в случае отказа узла.
После того, как метаданные будут обновлены в базе Cassandra, экстент пишется на диски.
Когда данные записаны в Extent Store, каждый экстент синхронно реплицируется (отдельным процессом от репликации Oplog) в Extent Stores на других узлах кластера. Это обеспечивает ситуацию, когда вы всегда располагаете несколькими копиями данных, что обеспечивает надежное хранение и отказоустойчивость.
Как дополнительный процесс, при операции записи данных вычисляется специальная контрольная сумма, которая включается в соответствующие метаданные. Это означает, что когда NDFS читает экстент, то, она вычисляет для считываемого экстента его новую контрольную сумму, а затем сравнивает ее с записанной для него ранее, и записанную в метаданных. Если две этих контрольных суммы совпадают, то данные рассматриваются как консистентные и что их содержимое цело и не изменилось с момента исходной записи. Если контрольная сумма не совпала, то экстент помечается как «поврежденный» (‘corrupt’), извлекается его реплика с другого узла, и в дальнейшем, при обращении к нему используется именно она. Далее иниициируется процедура репликации, которая восстанавливает поврежденный экстент на дисках соответствующего узла, из его целой реплики с других узлов.

Предотвращение отказа в результате разрыва межузловой сети

Для предотвращения ситуации так называемого ‘split-brain’, NDFS использует хорошо известный алгоритм Paxos. Этот алгоритм позволяет находить консенсусное решение (путем обеспечения кворума) при участии в операции нескольких участников распределенной системы.
Перед тем, как какие-либо метаданные файловой системы будут записаны в Cassandra, Paxos убеждается в том, что все узлы системы согласны записать одно для всех значение. Если кворум не собран, любые операции останутся неуспешными, чтобы избежать ситуации потенциального повреждения метаданных или неконсистентности данных.
Такое поведение защишает от разрывов связи в межузловой сети, так называемого «network partitioning», когда коммуникации между узлами кластера могут быть полностью разорваны, или же испытывать повреждения и потери пакетов, что приводит к тому, что консенсус в кластерном кворуме установить не удается. Для того, чтобы быть уверенным в том, что изменения данных прошли в нужном порядке, используется также отметка времени.

Проактивная схема обнаружения дисковых отказов

NDFS включает в себя процесс, под названием Curator, который выполняет фоновые процессы системы, и обеспечивает плавность и бесперебойность работы внутренних механизмов кластера. Среди множества задач Curator также есть задача обеспечения консистентности метаданных, и «прочесывание» Extent Store в поиске поврежденных экстентов или недописанных репликаций.
Дополнительно Curator сканирует экстенты, вычисляет их контрольные суммы для каждого, и сравнивает с записанными значениями в метаданных, обеспечивая проверку целостности. В случае, когда контрольные суммы не совпадут, поврежденный экстент, как уже было описано ранее, заменяется на содержимое, взятое с другого узла. Такой проактивный, упреждающий анализ состояния данных не только защищает от потери данных, он также позволяет обнаружить диск, готовый отказать, прежде, чем это фактически произойдет.

Обеспечение доступности данных в случае дискового отказа

Когда NDFS обнаруживает, что на каком-то конкретном диске увеличивается число ошибок (например ошибки ввода-вывода, или нечитаемые сектора), этот диск помечается как offline и немедленно удаляется из пула хранения системы. Curator идентифицирует все экстенты, хранившиеся на отказавшем диске, а NDFS затем запрашивает дополнительную репликацию копий данных со связанных реплик для восстановления необходимого уровня избыточности.
В отличие от традиционных RAID-массивов, которые должны пройти через полное перестроение для восстановления избыточности, что также вызывает существенное снижение производительности в процессе, репликация NDFS работает как фоновый процесс, не влияя на производительность кластера. Фактически, по мере роста размера кластера, время восстановления даже уменьшается, так как в требуемой репликации участвует больше узлов. Так как данные, требуемые для восстановления отказавшего диска распределены по кластеру, то больше и дисков будут вовлечены в процесс восстановления. Это увеличивает скорость и уменьшает время, за которое пострадавшие экстенты будут заново «разбросаны» по кластерному хранилищу.

Прозрачное для пользователя решение проблем с ПО и отказом узла кластера

NDFS не только позволяет парировать различные аппаратные отказы, но также обеспечивает избыточность для программного стека. ПО Nutanix работает таким образом, что в случае ошибки пытается быстро завершить свою работу (вместо того, чтобы ожидать исчезновения причины ошибки). Программные компоненты решения непрерывно мониторятся, а, в случае проблем, быстро убиваются и перезапускаются, чтобы обеспечить минимальное время восстановления, вместо длительного нахождения в состоянии «не отвечает». Каждый хост взаимодействует со своим собственным Controller VM для обслуживания всех запросов по хранению данных.
NDFS непрерывно отслеживает «состояние здоровья» всех CVM в кластере. Если на каком-то Controller VM возникает ошибка, которую невозможно восстановить, то Nutanix автоматически перенаправляет запросы к этому хосту на работающий Controller VM другого узла.
Это перенаправление продолжается до тех пор, пока локальный для этого узла Controller VM не решит свою проблему. Так как кластер существует в едином namespace, и имеет доступ к репликам данных на других узлах, он может обрабатывать эти запросы немедленно. Это как раз то, что обеспечивается с помощью так называемого N-way full fault-tolerant failover для всех VM в кластере Nutanix. Если Controller VM узла продолжает оставаться недоступным длительный период, то Curator автоматически инициирует ре-репликацию данных, чтобы сохранить достаточный уровень избыточности данных.

Надежное и избыточное оборудование

Nutanix Virtual Computing Platform представляет собой интегрированное решение, включающее в себя компьютерную, аппаратную часть, и программный продукт на нем работающий.
Все аппаратные компоненты проходят суровый процесс тестирования. Выполняя такое входное тестирование, Nutanix увеличивает надежность и долговечность попадающих к своим клиентам устройств.
Каждый узел Nutanix имеет полностью избыточные компоненты, включая CPU, память и источники питания. В случае полного отказа узла, автоматически инициируется HA event, и VM с этого узла переносятся или рестартуются на других узлах кластера. Curator затем мигрирует данные на локальный для данной VM контроллер, чтобы обеспечить максимальную «локальность» всех операций ввода-вывода. Следом за этим данные реплицируются, чтобы сохранить требуемый в системе коэффициент репликации и степень доступности данных.

Nutanix «под крышкой»: как обеспечивается надежность хранения данных: 3 комментария

  1. Maxim Shaposhnnikov

    Кстати, очень хорошее описание (и даже нечего поправить).

    Можно добавить про разные режимы работы Сassandra (чуть более медленно но консистентно — например тут почитайте http://www.datastax.com/docs/1.1/dml/data_consistency ), про soft updates (возврат результата I/O происходит только после того как записана реплика экстентов на другие ноды кластера), но это уже в сущности мелочи.

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

    https://code.google.com/p/snappy/

  2. Уведомление: Nutanix OS 4.0: Replication Factor = 3 | Virtualization solution with a nuts

  3. Уведомление: X vs. Y: Nutanix и SimpliVity - Virtualization solution with a nuts

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

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