Вы наверняка сталкивались с системами хранения данных семейства TATLIN или серверами VEGMAN, хотя можете об этом даже не подозревать. Например, делая заказ в интернет-магазине или пользуясь другими популярными онлайн-сервисами: в глубине ИТ-инфраструктуры для них можно обнаружить продукты YADRO. 

Добрый день, меня зовут Александр Чуриков, я технический эксперт отдела сервисного дизайна YADRO. Мы служим мостиком между сервисом и нашим R&D, который разрабатывает продукты: изучаем все боли сервиса, которые возникают при обслуживании, в том числе при обновлении и замене компонентов, и транслируем их в R&D. 

Фактически мы участвуем в разработке продуктов как продуктовые менеджеры с точки зрения дизайна. Для этого мы разработали фреймворк — это чек-лист требований для продукта. На стадии дизайна нового продукта R&D берет этот чек-лист, который в соответствии с нашими требованиями реализует нужные фичи продукта. Допустим, заменяемые «на горячую» компоненты промаркированы лососевым цветом, «на холодную» — синим. Также в чек-листе собраны требования к индикации и заменяемым компонентам TATLIN.UNIFIED.

Терабайт кеша и умные полки

Система хранения данных (СХД) — это программно-аппаратный комплекс. В основе TATLIN.UNIFIED лежит ОС собственной разработки: Tatlin.OS. Аппаратная часть также разработана нами, вместе с соответствующими прошивками. Требования к ней: отказоустойчивость, работа при выходе из строя любого компонента и обслуживание без перерыва доступа к данным. Наши СХД, как правило, используются в высоконагруженных сервисах — если для обновления выключить систему даже на час, это уже критично. Поэтому все наши процедуры разрабатываются так, чтобы клиент не терял доступ к данным.

TATLIN.UNIFIED — это высокопроизводительная система общего назначения со стандартным функционалом: файловый и блочный доступ к данным, работа под высокой нагрузкой без перерывов и поддержка умных полок, в которых располагаются диски. К СХД можно подключить до шести таких полок и в общей сложности более 500 дисков. Общий объем пространства может достигать 9 петабайт на одну систему. 

Также в TATLIN.UNIFIED есть единое контроллерное шасси с батарейным модулем и 1 ТБ кеша, который организован в оперативной памяти и имеет очень сложную математическую модель. Батарейный модуль обеспечивает сохранность кеша при отключении электропитания. Алгоритмы внутренней обработки данных, в том числе и работы кеша, улучшаются от версии к версии. 

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

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

На основе подсистемы кеширования реализованы такие функции, как снапшоты, толстые и тонкие тома, а также unmap, которая освобождает неиспользуемое пространство. В планах — добавить в TATLIN.UNIFIED дедупликацию. 

Зачем и как обновлять СХД

Разберемся, зачем нам нужны обновления:

• Новая функциональность — клиентам нужны новые фичи. 

• Поддержка нового оборудования и ПО. В России много отечественных гипервизоров, и иногда под конкретный вариант нам нужно, например, модифицировать подсистемы target’ов.

• Увеличение лимитов — например, доступных логических дисков (LUN) с 500 в версии 2.5 до 700 в версии 3.1. Также в версии 2.5 мы увеличили количество поддерживаемых дисковых полок — с трех до шести.

• Повышение производительности.

• Устранение ошибок ПО. 

Процедура обновления корпоративного СХД, такого как TATLIN.UNIFIED, должно удовлетворять трем основным требованиям:

• сохранять непрерывность доступа к данным,

• занимать минимальное время,

• быть максимально простой.

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

Обновление должно занимать минимум времени, поскольку в процессе мы перегружаем контроллеры по очереди. В момент, когда один контроллер перезагружается, кеш на запись отключается, и клиент замечает падение производительности. Поэтому всю процедуру нужно провести максимально быстро. Чтобы минимизировать влияние на производительность приложений и сервисов, рекомендуется проводить обновление в периоды минимальной нагрузки на СХД.

Парк установок TATLIN.UNIFIED составляет около двух тысяч систем. Если привлекать высококвалифицированного инженера для обновления каждой СХД, это окажется слишком дорого. Поэтому процедура обновления должна быть максимально простой — ее должен уметь выполнить инженер с минимальным уровнем квалификации.

Присоединяйтесь к команде разработки и поддержки СХД в YADRO:

? Инженер технической поддержки
? Координатор L3
? Менеджер проектов
? Инженер технической поддержки L3, СХД R&D

Как устроен TATLIN.UNIFIED

Кратко расскажу об устройстве нашей СХД.

В системе два контроллера и батарейный модуль, объединенные бэкплейном в едином шасси. Есть управляющий элемент, который отвечает за работу вентиляторов, а также элементы, управляющие питанием. Для подключения полок используются SAS HBA: полки подключаются цепочкой. Также установлены PCIe-свичи с фронтенд-картами: к ним и подключаются клиенты. Подключение всегда идет к обоим контроллерам, что сделано для резервирования и повышения производительности. Контроллеры работают в режиме active-active: оба контроллера активны.

Слева направо: первый и второй контроллеры, затем батарейный модуль. Последний — очень мощный, похож на те, что ставят в электросамокатах. Такая емкость нужна, чтобы при отключении электропитания успеть сбросить около 1 ТБ данных из кеша на NVMe-диск. Это занимает несколько минут, иногда 10–20, и все это время батарейный модуль должен поддерживать работоспособность контроллеров.

Компоненты объединены в единую сеть I2C-шиной:

Каждая точка на схеме — это микроконтроллер. Прошивки для микроконтроллеров мы пишем сами. Это нужно для мониторинга работоспособности отдельных компонентов: если, например, остановятся вентиляторы и система начнет перегреваться, то мы можем отреагировать сразу, а не ждать, пока данные клиента будут утеряны.

Еще один важный элемент TATLIN.UNIFIED — это умная полка. На схеме показана всего одна полка с шестью SAS-экспандерами. Экспандер — это разветвитель, на который приходит один или несколько SAS-каналов, а дальше трафик распределяется на множество дисков: до 48 каналов. У экспандеров есть собственная прошивка.

Внутри полки по I2C-шине организован своеобразный мини-кластер. На каждом узле стоят микроконтроллеры, которые следят за работой экспандеров, вентиляторов и питания. 

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

На передней панели видны три мощных вентилятора и два экспандера. Сверху устанавливаются диски — в полке их 96 штук. Сзади — еще пара экспандеров и два блока питания.

Как мы обновляем нашу СХД

TATLIN.UNIFIED — это программно-аппаратный комплекс, и нам нужно обновлять два основных блока:

• ПО Tatlin.OS.

• Прошивки «железа»: контрольного шасси, полок, фронтенд-карт, дис��ов и BIOS/BMC контроллеров.

Обновление «софта»

Первый этап — подготовка к обновлению. Сервисный инженер, который проводит весь процесс обновления, должен убедиться, что:

• На компьютере, с которого выполняется обновление, установлен SSH-клиент, открыты нужные порты и так далее.

• У него есть все права и пароли для копирования образа на контроллер.

• Образ копируется в предназначенную для этого директорию. 

Затем начинается процесс обновления ПО, то есть Tatlin.OS.

Мы продумывали процесс обновления еще на этапе проектирования архитектуры, поэтому обновление — это неотъемлемая часть Tatlin.OS. У нас есть два stateless-контроллера: на них не хранятся данные: ни настройки, ни пользователи. Все настройки хранятся в ETCD, кластерной базе вида ключ-значение:

• менеджмент-сети, 

• пулов, 

• логических дисков (LUN) на базе пулов, 

• access-листов.

То есть все настройки СХД хранятся в ETCD. Всем этим управляет оркестратор Pacemaker: он запускает сервисы на контроллерах и следит за их работой.

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

Такой дизайн был заложен изначально: у нас stateless-контроллеры, поэтому при обновлении или замене не требуется вручную переносить конфигурации. 

В других системах хранения, где не используются stateless-контроллеры, заметная часть времени уходит на сохранение настроек и данных (шаги 1, 3 и 5 на схеме ниже). В TATLIN.UNIFIED конфигурация хранится централизованно: контроллер включается, синхронизируется и входит в кластер.

Чем больше исправлений и нового функционала в обновлении, тем дольше идет весь процесс, так как мы вносим в Tatlin.OS много изменений. Когда мы обновляем Tatlin.OS, контроллер работает с раздела 0 (part0).

Инженер получает бандл — архив размером около 1,5–2 ГБ. Он копирует его на контроллер и запускает процесс обновления. После старта выполняется проверка системы. Один из элементов бандла — образ SquashFS, который целиком разворачивается на раздел part 1 без каких-либо модификаций.

Затем контроллер перезагружается и уже работает с новой версией. Все это быстро и просто. Также нам не нужно следить за совместимостью пакетов и определять очередность их установки: вся установка идет одним бандлом.

Кроме того, есть раздел Rescue — туда временно распаковывается бандл. И есть раздел Persistent — он предназначен для данных, которые нельзя удалять: для логов и файлов конфигурации. Pacemaker и ETCD работают в кластере, но иногда СХД отключают, и нам важно не потерять настройки — они периодически сохраняются в разделе Persistent, а также фиксируются при выключении. При старте СХД снова запускается Pacemaker: он читает данные из Persistent и поднимает кластер.

Схематически процесс обновления Tatlin.OS можно представить так:

Сначала выполняется предварительная проверка — нужно убедиться, что комплекс исправен и все компоненты работают. Иначе можно обновить и перезагрузить один контроллер, а второй, оказывается, был неисправен. 

Затем образ ОС разворачивается на втором разделе, перезагружается сначала первый контроллер, затем второй, после чего вносятся изменения в кластер. Модификация кластера нужна, если вместе с релизом приходит новая фича и требуются новые ключи в ETCD или новые настройки в Pacemaker.

В финале обновления запускается пост-проверка, чтобы убедиться в работоспособности всей системы. 

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

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

Поэтому мы ввели ручную перезагрузку и добавили процедуру проверки доступности путей от сервера:

Перед стартом процедуры и в середине старта, когда первый контроллер уже запустился, — второй не перезагружается автоматически. Мы проверяем пути и доступность обоих контроллеров. После проверки подтверждаем клиенту, что все ок.

Обновление «железа»

Название раздела условное, ведь у всех «железных» компонентов TATLIN.UNIFIED есть прошивки. Чтобы организовать максимально безболезненный процесс обновления, мы занялись их серьезным изучением и выяснили много интересных нюансов.

В ранних версиях, когда мы запрашивали версию прошивки микроконтроллера, в ответ возвращался номер коммита. В итоге получалось несоответствие: файл помечен как 1.3, а прошивка отвечает 2aa8217 — непонятно, какая версия установлена. Мы модифицировали прошивку, чтобы она возвращала именно версию, а не номер коммита.

Мы сами разрабатываем BIOS/BMC, и перед началом обновления нужно узнать их текущие версии. Самый логичный путь — через IPMI, но выяснилось, что он показывает только два разряда версии BIOS: вместо 1.10.2 мы видим 1.10. Часто третий разряд фиксирует баги, поэтому мы используем два способа: узнаем точную версию через BMC CLI, либо используем Redfish.

Схема обновлен��я прошивок экспандеров:

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

Сначала мы обновляем Tatlin.OS на первом и втором контроллере, затем — прошивки. Однако у наших клиентов процесс будет отличаться. У нас получается пять проверок:

Проверки занимают время сопоставимое, а часто и больше, чем сами операции на системе хранения. У наших клиентов бывает до 700 хостов, и проверка доступности всех путей на каждом из них отнимает много времени. В некоторых случаях обновление занимало полтора часа, а проверка — от трех до 12 часов. Это нас не устраивало, и мы изменили порядок обновлений.

Теперь обновляем ОС первого контроллера и сразу микрокод его аппаратных компонентов. Затем переходим ко второму контроллеру и тоже сразу обновляем его прошивки — и так далее.

В итоге мы снова пришли к трем проверкам, а время сократилось кардинально. Но обновление еще должно быть простым.

Если попытаться описать все процедуры пошагово, получится около 150 шагов, которые должен выполнить инженер. Поэтому мы все шаги разбили на 7 стадий:

Для каждой стадии мы написали скрипт, который выполняет действия, нужные именно на этой стадии. После завершения скрипт выдает понятный результат: либо «ОК», либо сообщение с описанием проблемы. Логи при этом сохраняются.

Если обновление выполняет инженер L1 или инженер партнера и сталкивается с проблемой, то он заводит тикет на следующий уровень — L2. Если там не удается решить, эскалируем на L3. Если и L3 не справляется, открываем тикет в R&D.

Сервисная служба работает круглосуточно: L1 и L2 дежурят 24/7. Есть дежурный по телефону от R&D и от L3. Даже в праздники — если случается инцидент (не только при обновлениях) — мы оперативно подключаем R&D.

В будущем мы собираемся еще больше все упростить и свести процедуру к одной стадии. Недавно вышел наш новый продукт — TATLIN.AFA, и в нем мы планируем передать обновление клиенту, чтобы снизить стоимость и для нас, и для клиента, и упростить весь процесс. Но для этого предстоит большая работа по исследованию и тестированию: те самые 150 шагов никуда не денутся — их все равно кому-то нужно выполнять.

Заключение

Поделюсь несколькими советами, которые пригодятся, если вы работаете с обновлениями СХД или других высоконагруженных систем.

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

У всех компонентов должна быть версионность, доступная привычным способом. Ее нужно получать штатной командой.

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

Сервисная процедура должна иметь четкую инструкцию на русском языке. В ней указываем время выполнения, требуемый уровень доступа и какие именно инженеры ее выполняют. Мы удаляем ветвления вроде «если у вас NVMe такой-то модели — сделайте шаги 1–3, иначе переходите к шагу 5». Прыжки по тексту — источник ошибок. Лучше вынести такие случаи в конец, либо сделать шаги условно безопасными для выполнения всегда — пусть скрипт сам решит, нужно ли что-то обновлять.

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

Другие статьи про TATLIN.UNIFIED, которые могут вас заинтересовать:

? Снапшоты, клоны и не только: как устроен и что умеет маппер в СХД TATLIN
? Что не убивает, делает сильней: как мы тестируем СХД, «ломая» его по частям
? Как устроен T-RAID — RAID-массив в СХД TATLIN
? Один на 150 миллионов операций. Расследуем причины выброса времени отклика в операциях ввода-вывода