Nutanix «под крышкой»: Масштабируемость системы

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

Масштабируемость

Управление данными в распределенной системе

Ключевой задачей в дизайне широко масштабируемой системы является обеспечение того, чтобы каждый участвующий в построении системы узел управлял только ограниченным объемом состояний, вне зависимости от размера кластера. Выполнение этого требует отсутствия так называемого «главного узла», «master node», ответственного за обслуживание всех данных и метаданных кластерной системы. Эта концепция имеет первостепенное значение в настоящей широко масштабируемой системе, и очень сложно реализуется в традиционных архитектурах.

Nutanix Distributed Filesystem (NDFS) эффективно управляет всеми типами данных при линейном масштабировании их объемов от небольшого кластера, до кластера больших размеров, при этом без влияния на производительность узлов, и кластера в целом.

Хранение конфигурации

NDFS хранит данные конфигурации в очень маленькой, расположенной в памяти базе данных, резервная копия которой расположена на дисках SSD. Три копии этой конфигурационной базы данных постоянно поддерживаются кластером. Важно отметить, что существует строгий лимит на ее размер сверху, чтобы быть уверенным, что эта база не превысит своими размерами объем в несколько мегабайт

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

Метаданные

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

NDFS использует множество концепций NoSQL для масштабирования хранилища и управления метаданными. Например, система использует базу данных NoSQL под названием Cassandra для работы с парами «key-value», в которых ключ это смещение на определенном виртуальном диске, а значение — представляет физическое расположение реплики данных в кластере.

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

Данные виртуальных машин и операции ввода-вывода

На каждом узле Nutanix работает виртуальная машина Controller Virtual Machine (CVM), которая обрабатывает все операции ввода-вывода локального гипервизора и его виртуальных машин, а также служит шлюзом для NDFS. Такая «многоканальная» схема контроллера означает, что число CVM масштабируется пропорционально числу узлов кластера Nutanix, тем самым устраняется возможность получить узкое место на уровне контроллера ввода-вывода, что может произойти в случае традиционных систем хранения.

Архитектура NDFS обеспечивает то, что объем хранимых на кластерном узле данных прямо пропорционален объему хранилища на этом узле, включая общие объемы SSD и HDD. Он по определению ограничен и не зависит от размеров кластера. Системный компонент, называющийся Curator, который отвечает за нормальную и бесперебойную работу механизмов кластера, выполняет в фоне задачи типа «map-reduce» для проверки необычных уровней загрузки дисков.

Когда VM создает данные, NDFS хранит одну копию резидентно на локальном узле, чтобы обеспечить оптимальную производительность, и распределяет избыточные копии по другим узлам кластера. Распределенная репликация позволяет быстрое восстановление в случае отказа диска или узла целиком. Все удаленные узлы Nutanix участвуют в процессах репликации. Это позволяет обеспечить больший объем операций ввода-вывода для кластера больших размеров, так как в операции репликации будет вовлечено больше узлов.

Если VM перемещается на другой узел в результате операций High Availability (HA) или иных нужд виртуальной машины, Curator автоматически мигрирует активные данные на тот узел, на котором исполняется VM. NDFS позволяет всем кластерным ресурсам хранения быть доступными с любого хоста и любой VM, но без необходимости всем данным находиться локально на этом узле.

Масштабирование локирования на уровне vDisk

В традиционных неконвергентных архитектурах, ввод-вывод от одной VM может прийти через несколько интерфейсов, например при обеспечении multi-pathing или балансировки нагрузки контроллера. Это вынуждает традиционные файловые системы использовать тонко «гранулированное» локирование, чтобы избежать переключения владельца между контроллерами при записи, и объемного потока сообщений о инвалидации в сети. Такое использование локирования в архитектуре вызывает, в случае множественных контроллеров с множеством каналов ввода-вывода, потенциальное узкое место и ограничение, которое почти невозможно преодолеть.

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

Операции ввода-вывода определенной VM обслуживаются локальным Controller VM, работающим на этом хосте. Этот локальный Controller VM обслуживает все локи для всех виртуальных дисков, содержащих VM. Так как в нормальном случае доступ к виртуальным дискам не разделяется между несколькими хостами, оставаясб локальным вводом-выводом одного хоста, NDFS просто использует локирование на уровне vDisk.
Кроме прочего, это решает проблемы с инвалидацией и проблемами с когерентностью кэшей. Даже при довольно большом числе VM, NDFS эффективно управляет локированием с минимальным оверхедом, чтобы обеспечить линейность возможного масштабирования системы.

Масштабирование средств уведомления, мониторинга и отчетов

Уведомления (Alerts)

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

NDFS реализует полностью масштабируемую систему уведомлений, поддерживаемую сервисами, работающими на каждом узле. Все события и уведомления о них записываются в строго консистентную распределенную базу данных NoSQL, доступную с любого узла кластера. Они также легко доступны через GUI или через стандартизованный REST-based API.

Статистика и визуализация

Любая распределенная система требует надежные средства мониторинга и статистики, работающие в реальном времени. NDFS масштабирует компонент, отвечающий за сбор статистики, обеспечивая работающий почти в реальном времени мониторинг системы для администратора кластера. Это обеспечивается реализацией масштабируемой базы данных сбора статистики, использующей хранилище NoSQL вида key-value.

На каждом хосте кластера Nutanix работает агент, собирающий локальную статистику и периодически обновляющий хранилище в базе NoSQL Когда GUI запрашивает дата в отсортированном виде (например, верхние 10 максимально загружающие CPU виртуальные машины), запрос посылается используя фреймворк «map-reduce» на все хосты кластера, чтобы получить актуальную информацию. Каждый хост отвечает за выполнение запросов только к своей локальной статистике.

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

Предотвращение «единой точки отказа» (Single Points of Failure)

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

Для преодоления этого недостатка, Nutanix использует схему динамического выбора лидера (dynamic leader election scheme). Для всех функций и административных ролей кластера, сервисы всех хостов вызываются быть избранными как лидер. Лидер эффективно избирается используя сервис распределенной конфигурации, реализованный в системе.

При этом не является необходимым, чтобы лидеры для всех функций располагались на некотором одном узле. В реальности лидеры случайным образом распределяются по узлам, чтобы равномерно распределить нагрузку лидеров по кластеру. Когда избранный лидером узел становится недоступен, из-за отказа сервиса, или же по причине отказа узла целиком, автоматически избирается новый лидер среди оставшихся узлов кластера. Этот процесс происходит в течение субсекундного интервала для кластера любого размера. Другими словами, нет корреляции между временем выполнения выбора нового лидера после возникновения отказа, и числом узлов в кластере. Новоизбранный лидер автоматически принимает на себя ответственность за операции, лежавшую на предыдущем лидере.

Строгая консистентность в NoSQL и использование PAXOS

Большинство реализаций NoSQL жертвуют строгой консистентностью ради достижения высокой доступности. Например, используемая в Facebook реализация Cassandra и Amazon Dynamo обеспечивают только возможную консистентность, которая не может рассматриваться как достаточная в случае использования в качестве настоящей файловой системы. «Возможная консистентность» в данном случае означает, что если какая-то часть данных была записана на одном из узлов кластера, данные лишь возможно будут видимы измененными на остальных узлах того же кластера. Не гарантируется то, что измененные данные будут видимы всеми узлами кластера одновременно.

Хотя это и неплохо работает для некоторых систем, это вызовет повреждение файловой системы хранилища. Это может выглядеть как естественное поведение для NoSQL, которая демонстрирует ее ущербность и непригодность для построения масштабируемых файловых систем. NDFS, однако, обеспечивает строгую консистентность, будучи построенной поверх NoSQL-базы, реализуя распределенную версию алгоритма, известного как Paxos.

Paxos — это широко используемый протокол обеспечения «консенсуса» между узлами кластера. В хранилище метаданных NDFS, для каждого ключа указывается группа из трех узлов, которые могут содержать наиболее свежее состояние данных. NDFS выполняет алгоритм Paxos для обеспечения консенсуса в отношении значения запрошенного ключа. Paxos гарантирует, что в результате его работы достигнут консенсус между узлами в отношении значения наиболее свежего состояния данных. Строгая консистентность гарантируется несмотря на то, что нижележащее хранилище является базой NoSQL. Для любого ключа требуется достижение консенсуса между тремя узлами кластера, вне зависимости от размера кластера.

Возможность поддерживать строгую консистентность масштабируемой базы NoSQL, позволяет NDFS обеспечить линейную масштабируемость файловой системы.

Масштабируемость фреймворка Map-Reduce

В типичной файловой системе должны выполняться многие рутинные операции, более эффективно было бы запускать их как фоновые процессы. Производительности системы будет иметь преимущества, если подобные задачи будут выполняться при малой загрузке системы по вводу-выводу. Типичными примерами таких процессов являются операции проверки целостности дисков (disk scrubbing), балансировка загрузки, оффлайн-сжатие данных, проверка целостности метаданных и подсчет свободного места.

NDFS использует «map-reduce» фреймворк, называющийся Curator, и который отвечает за выполнение операций над кластером целиком, обеспечивая масштабируемость выполнения этих задач в системе узлов кластера так, чтобы она не влияла на возможности масштабирования системы в целом. Так как все узлы кластера участвуют в этой работе, и каждый из них обрабатывает часть задач Curator, производительность системы растет линейно, вместе с ростом размера кластера.

Каждый узел кластера отвечает за определенный объем и число задач «map-reduce», выполняемый пофазно всеми кластерными узлами. Координирующий узел случайным образом выбирается среди всех узлов кластера и выполняет только легкие задачи по координации узлов кластера.

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

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