Здравствуйте, хабровчане! Продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье будет обсуждаться архитектура этой системы.
В прошлой статье мы рассмотрели нашу файловую систему ARDFS, а в этой статье мы рассмотрим все основные программные компоненты, входящие в состав vAIR, и их задачи.
Начнем описывать архитектуру снизу вверх — от хранения до управления.
Файловая система ARDFS + драйвер кластера Raft
Основой vAIR является распределенная файловая система ARDFS, объединяющая локальные диски всех узлов кластера в единый логический пул, на основе которого формируются виртуальные диски с той или иной схемой отказоустойчивости (коэффициент репликации или Erasure coding).виртуальные блоки по 4 МБ каждый.
Более подробное описание того, как работает ARDFS, приведено в предыдущая статья.
Raft Cluster Driver — это внутренний сервис ARDFS, решающий задачу распределенного и надежного хранения метаданных файловой системы.
Метаданные ARDFS разделены на два класса.
- уведомления – информация об операциях с объектами хранения и информация о самих объектах;
- служебная информация – установка блокировок и информация о конфигурации узлов хранения.
Лидер является единственным истинным источником этой информации.
Кроме того, лидер организует Heart-beat, т.е.
проверяет доступность всех узлов хранения (к доступности виртуальных машин это не имеет никакого отношения, RCD — это всего лишь сервис хранения).
Если по какой-либо причине лидер становится недоступным для одного из рядовых узлов более чем на одну секунду, этот рядовой узел организует переизбрание лидера, запрашивая доступность лидера у других рядовых узлов.
При наличии кворума руководитель переизбирается.
После того, как бывший лидер «просыпается», он автоматически становится обычным узлом, поскольку новый лидер посылает ему соответствующую команду.
Сама логика работы УЗО не является чем-то новым.
Аналогичной логикой руководствуются и многие сторонние, коммерческие и бесплатные решения, но нам эти решения не подошли (как и существующие файловые системы с открытым исходным кодом), поскольку они довольно тяжелые, и оптимизировать их под наши простые задачи очень сложно.
задачи, поэтому мы просто написали свой сервис УЗО.
Может показаться, что лидер — это узкое место, способное замедлить работу больших кластеров на сотни узлов, но это не так.
Описанный процесс происходит практически мгновенно и «весит» совсем немного, так как мы написали его сами и включили только самые необходимые функции.
Причём это происходит совершенно автоматически, оставляя в логах только сообщения.
MasterIO — сервис управления многопоточным вводом-выводом
После настройки пула ARDFS с виртуальными дисками его можно использовать для ввода-вывода.В этот момент возникает вопрос, специфичный для гиперконвергентных систем, а именно: каким количеством системных ресурсов (ЦП/ОЗУ) мы можем пожертвовать ради ввода-вывода? В классических СХД этот вопрос стоит не так остро, поскольку задачей СХД является только хранение данных (причем большая часть системных ресурсов СХД может быть безопасно выделена для ввода-вывода), а задачи гиперконвергентной системы , помимо хранилища, также включают в себя выполнение виртуальных машин.
Соответственно, GKS требует использования ресурсов ЦП и ОЗУ в первую очередь для виртуальных машин.
Ну а как насчет ввода/вывода? Чтобы решить эту проблему, vAIR использует службу управления вводом-выводом: MasterIO. Цель услуги проста – «взять все и разделить» гарантированно возьмет n-ное количество системных ресурсов для ввода-вывода и на их основе запустит n-ное количество потоков ввода-вывода.
Изначально мы хотели предоставить «очень умный» механизм распределения ресурсов для IO. Например, если на хранилище нет нагрузки, то системные ресурсы можно использовать для виртуальных машин, а при появлении нагрузки эти ресурсы «мягко» изымаются из виртуальных машин в заданных пределах.
Но эта попытка закончилась частичной неудачей.
Тесты показали, что если нагрузку увеличивать постепенно, то все ресурсы ОК (помеченные для возможного вывода) постепенно изымаются из ВМ в пользу ввода-вывода.
Но резкие скачки нагрузки на хранилища провоцируют не такой уж мягкий изъятие ресурсов у виртуальных машин, в результате чего накапливаются очереди к процессорам и, как следствие, и волки голодны, и овцы мертвы и виртуалки виснут, и IOPS нет. Возможно, в будущем мы вернёмся к этой проблеме, а пока мы реализовали выдачу ресурсов для IO старым добрым способом — вручную.
На основе данных о размерах администратор предварительно выделяет n-ное количество ядер ЦП и объем оперативной памяти для службы MasterIO. Эти ресурсы выделяются эксклюзивно, т.е.
их нельзя каким-либо образом использовать для нужд ВМ, пока это не разрешит администратор.
Ресурсы распределяются равномерно, т.е.
с каждого узла кластера изымается одинаковое количество системных ресурсов.
В первую очередь MasterIO заинтересованы в ресурсах процессора (ОЗУ менее важна), особенно если мы используем Erasure-кодирование.
Если произошла ошибка с сайзингом, и мы отдали MasterIO слишком много ресурсов, то ситуацию можно легко разрешить, выведя эти ресурсы обратно в пул ресурсов ВМ.
Если ресурсы простаивают, то они почти сразу вернутся в пул ресурсов ВМ, но если эти ресурсы будут утилизированы, то придется подождать некоторое время, пока MasterIO их мягко освободит. Обратная ситуация сложнее.
Если нам нужно увеличить количество ядер для MasterIO, а они заняты виртуальными машинами, то нам придется «договариваться» с виртуальными машинами, то есть выбирать их вручную, так как в автоматическом режиме, в ситуации резкий скачок нагрузки, эта операция еще чревата зависаниями ВМ и прочим капризным поведением.
Соответственно, довольно много внимания необходимо уделять определению производительности ввода-вывода гиперконвергентных систем (не только нашей).
Чуть позже, в одной из статей, мы обещаем рассмотреть этот вопрос подробнее.
Гипервизор
Гипервизор Аист отвечает за запуск виртуальных машин в vAIR. Этот гипервизор основан на проверенном временем KVM-гипервизоре.В принципе, о работе KVM написано достаточно много, поэтому описывать ее особо нет нужды, просто отметим, что все стандартные функции KVM хранятся в Аисте и прекрасно работают. Поэтому здесь мы опишем основные отличия от стандартного KVM, который мы реализовали в Аисте.
Stork входит в состав системы (предустановленный гипервизор) и управляется из общей консоли vAIR через Web-GUI (русская и английская версии) и SSH (разумеется, только английский).
Кроме того, конфигурации гипервизора хранятся в распределенной базе данных ConfigDB (подробнее о ней ниже), которая также является единой точкой управления.
То есть вы можете подключиться к любому узлу кластера и управлять ими всеми без необходимости выделять отдельный сервер управления.
Важным дополнением к стандартной функциональности KVM является разработанный нами модуль HA. Это простейшая реализация кластера виртуальных машин высокой доступности, которая позволяет в случае сбоя узла автоматически перезапустить виртуальную машину на другом узле кластера.
Еще одна полезная функция — массовое развертывание виртуальных машин (актуально для VDI-сред), которая позволит автоматизировать развертывание виртуальных машин с автоматическим распределением их между узлами в зависимости от нагрузки на них.
Распределение ВМ между узлами — основа автоматической балансировки нагрузки (аля DRS).
В текущем релизе этой функции пока нет, но мы над ней активно работаем и она обязательно появится в одном из следующих обновлений.
Гипервизор VMware ESXi поддерживается опционально; на данный момент реализован с использованием протокола iSCSI; Поддержка NFS также планируется в будущем.
Виртуальные коммутаторы
Для программной реализации переключателей предусмотрен отдельный компонент — Fractal. Как и в случае с другими нашими компонентами, мы идем от простого к сложному, поэтому первая версия реализует простое переключение, тогда как маршрутизация и межсетевой экран в настоящее время передаются сторонним устройствам.Принцип работы стандартный.
Физический интерфейс сервера соединен мостом с объектом Fractal — группой портов.
Группа портов в свою очередь с необходимыми виртуальными машинами кластера.
Поддерживается организация VLAN, а в одном из следующих релизов будет добавлена поддержка VxLAN. Все созданные свитчи распределены по умолчанию, т.е.
распределены по всем узлам кластера, поэтому какие виртуальные машины к каким свитчам подключены, не зависит от узла, на котором находится ВМ, это исключительно вопрос решения администратора.
Мониторинг и статистика
Компонент, отвечающий за мониторинг и статистику (рабочее название Monica), по сути, является переработанным клоном системы хранения ENGINE. В свое время он хорошо себя зарекомендовал и мы решили использовать его в vAIR с небольшой настройкой.Как и все остальные компоненты, Моника выполняется и хранится на всех узлах кластера одновременно.
Сложные обязанности Моники можно обозначить следующим образом: Сбор данных:
- от аппаратных датчиков (то, что может отправлять оборудование по IPMI);
- из логических объектов vAIR (ARDFS, Aist, Fractal, MasterIO и других объектов).
Сбор данных в распределенную базу данных; Интерпретация данных в виде:
- бревна;
- оповещения;
- графики.
Распределенная база данных конфигурации
В предыдущих параграфах упоминалось, что большое количество данных хранится на всех узлах кластера одновременно.Для организации такого способа хранения предусмотрена специальная распределенная база данных ConfigDB. Как следует из названия, в базе данных хранятся конфигурации всех объектов кластера: гипервизора, виртуальных машин, модуля HA, коммутаторов, файловой системы (не путать с базой метаданных ФС, это другая база данных), а также статистика.
Эти данные хранятся синхронно на всех узлах, и согласованность этих данных является обязательным условием стабильной работы vAIR. Важный момент: несмотря на то, что функционирование ConfigDB жизненно важно для работы vAIR, его выход из строя хоть и остановит работу кластера, но никак не повлияет на консистентность данных, хранящихся в ARDFS, что, на наш взгляд, это плюс к надежности решения в целом.
ConfigDB также является единой точкой управления, поэтому вы можете зайти на любую ноду кластера по IP-адресу и полностью управлять всеми нодами кластера, что довольно удобно.
Кроме того, для доступа внешних систем ConfigDB предоставляет Restful API, с помощью которого можно настроить интеграцию со сторонними системами.
Например, недавно мы провели пилотную интеграцию с несколькими российскими решениями в области VDI и информационной безопасности.
Когда проекты будут завершены, мы будем рады написать здесь технические подробности.
Большая картина
В результате мы имеем два варианта архитектуры системы.
В первом — основном случае — используется наш KVM-гипервизор Aist и софт-переключатели Fractal. Сценарий 1. Верно 
Во втором — опциональном варианте — когда нужно использовать гипервизор ESXi, схема несколько усложняется.
Чтобы использовать ESXi, его необходимо стандартным образом установить на локальные диски кластера.
Далее на каждый узел ESXi устанавливается виртуальная машина vAIR MasterVM, которая содержит специальный дистрибутив vAIR для работы в качестве виртуальной машины VMware. ESXi предоставляет все свободные локальные диски, перенаправляя их непосредственно в MasterVM. Внутри MasterVM эти диски уже стандартно форматируются в ARDFS и передаются наружу (точнее обратно в ESXi) по протоколу iSCSI (а в будущем будет NFS) через интерфейсы, выделенные для ESXi. Соответственно, виртуальные машины и программная сеть в данном случае предоставляются инструментами ESXi. Сценарий 2: ESXi 
Итак, мы рассмотрели все основные компоненты архитектуры vAIR и их задачи.
В следующей статье мы поговорим об уже реализованном функционале и планах на ближайшее будущее.
Ждем комментариев и предложений.
Теги: #linux #Хранилище данных #отказоустойчивость #Системное администрирование #Хранение данных #Администрирование серверов #Системы хранения #импортозамещение #высокая доступность #репликация #хранилище #SAN #iops #репликация #гиперконвергенция #HCI #стирание кодов #стирание кодирования #гиперконвергенция #гиперконвергентные платформы #система хранения данных #airdisk #российское оборудование #российское оборудование #российское оборудование #гиперконвергентные #гиперконвергентный кластер #гиперконвергентные системы #гиперконвергентная система #гиперконвергентная система #масштабирование #масштабирование
-
Продажа Книг
19 Oct, 24 -
Как Круто (Не)Работать В Телекоме
19 Oct, 24 -
Я Руководитель Команды, Зачем Мне Все Это?
19 Oct, 24
