Всем доброго здравия! В этой статье мы проведем обзор обновленной линейки систем хранения данных АЭРОДИСК Восток-5 и АЭРОДИСК Engine-5. В новых СХД мы уделили много внимания управлению большими хранилищами в многоконтроллерных конфигурациях на разных процессорных архитектурах («Кластер хранения»), новой реализации динамических пулов хранения, оптимизированных под твердотельные носители (DDP2) и защищенному исполнению СХД для выполнения требований ФСТЭК к критичной информационной инфраструктуре (КИИ).
Также, по традиции, после статьи на Хабре мы организуем вебинар «Около-ИТ» по теме новых СХД Восток-5 и Engine-5, который пройдет 29 марта 2022 года в 14 00. На вебинаре мы подробно разберем все технические аспекты новых систем и ответим на ваши вопросы.
Зарегистрироваться на вебинар можно по ссылке.
Наверное, вы спросите, а почему Восток-5 и Engine-5? Вакцина Спутник-V и процессорная архитектура RISC-V тут совсем ни при чём. Дело в версии системного ПО СХД A-CORE v5. До этого, с первой по четвертую версию, расширение функционала СХД происходило довольно плавно, если не сказать эволюционно. Но так сошлись звезды, что в пятой версии A-CORE мы сделали довольно много крайне полезных и актуальных улучшений в ПО и одновременно серьезно обновили аппаратные платформы. Поэтому обновление целого поколения систем хранения напрашивалось само собой и было нами выполнено исходя из текущей версии ПО A-CORE.
Обзор аппаратных платформ
Начинаем обзор с аппаратной составляющей. Линейка СХД АЭРОДИСК глобально делится на два продукта:
АЭРОДИСК Восток – СХД на базе процессоров Эльбрус.
АЭРОДИСК Engine – СХД на базе процессоров x-86.
Процессорная архитектура – это единственное отличие данных двух продуктов. Другая начинка СХД, т.е. кодовая база, фронт/бэк-энд адаптеры, корпус, носители информации, модули расширения и т.п. являются либо идентичными, либо очень похожими.
Кстати, именно эта «генетическая» близость двух продуктов подтолкнула нас к созданию опциональной функции «Кластер хранения», котора�� позволяет объединять системы хранения на разных процессорных архитектурах. Но об этом немного позже. Сейчас же посмотрим на железки.
Контроллерные пары
Контроллерные пары СХД АЭРОДИСК серии 5 независимо от процессорной архитектуры выпускаются в идентичных корпусах следующих форматов:
Двухконтроллерное шасси формата SBB (Storage Bridge Bay) – классическое исполнение СХД, узлы контроллерной пары физически расположены в одном корпусе/шасси, соединены внутри корпуса интерконнектом по шине PCI или Ethernet (RDMA) и подключены к общему бэкплейну дисковой корзины на передней панели корпуса. Для дополнительного расширения емкости и/или производительности предусмотрены внешние модули (см. раздел «Модули расширения»).
Раздельные узлы контроллерной пары, то есть контроллеры СХД, расположены в разных корпусах, соединяются между собой с помощью внешнего интерконнекта по оптическому Ethernet (10/25/40/100 Gb/s) с поддержкой RDMA. Дисковые корзины в таком решении могут быть только внешние (см. раздел «Модули расширения»)
На всех доступных вариантах контроллерных пар предустановлено программное обеспечение АЭРОДИСК A-CORE версии 5.
Все контроллерные пары поддерживают установку следующих Front/Back-end адаптеров:
Fibre channel 8/16/32 Gb/sec
Ethernet 1/10/25/40/100 Gb/sec
Infiniband 40/56/100 Gb/sec
Доступные конфигурации контроллерных пар приведены в документе «Техническая спецификация»:
Модули расширения
Модули расширения позволяют решать две задачи: увеличение емкости и увеличение производительности:
Модули расширения дисковой емкости (дисковые полки)
Модули увеличения вычислительной мощности (IO-модули)
Модули расширения дисковой емкости – это классические дисковые полки. В системах хранения АЭРОДИСК серии 5 поддерживаются следующие модели дисковых полок:
12 дисков SAS 2,5/3,5’, 2U, 2xБП
24 диска SAS 2,5/3,5’, 4U, 2xБП
24 диска SAS 2,5’, 2U, 2xБП
60 дисков SAS 2,5/3,5’, 4U, 2xБП
108 дисков SAS 2,5/3,5’, 4U, 2xБП
Модули расширения вычислительной мощности (IO-модули) – это дополнительные вычислительные узлы СХД, обеспечивающие операции ввода-вывода для подключенных к ним дисковых корзин / полок. В отличие от контроллеров СХД IO-модули не выполняют каких-либо управляющих функций.
С аппаратной точки зрения IO-модули полностью повторяют контроллерные пары, при этом на программном уровне есть существенные отличия. На IO-модулях установлена ограниченная версия ПО A-CORE (IO-версия), которая не требует дополнительных лицензий как на контроллерные пары. В данную версию ПО включены только Back-end часть IO-движка A-CORE, сервисная консоль (для гарантийного обслуживания) и Restful API. Все взаимодействие контроллерных пар и IO-модулей реализовано через Restful API в рамках кластера хранения. С точки зрения администратора СХД при этом подход к управлению не меняется, все управление происходит из веб-интерфейса контроллерных пар кластера (более подробно см. раздел «Кластер хранения»).
Более подробная информация об аппаратной составляющей, включая доступные конфигурации, лицензионные опции и поддерживаемые носители информации, приведена в технических спецификациях продуктов:
Обзор новых возможностей ПО A-CORE
Программное обеспечение A-CORE – мозг систем хранения данных АЭРОДИСК. ПО предоставляется в предустановленном варианте на контроллерных парах (в полной версии) и IO-модулях (в спец. версии).
Сразу хочется дать ответ на часто задаваемый вопрос. ПО A-CORE не имеет никакого отношению к SDS-у, и поэтому его нельзя купить/скачать отдельно и поставить на рандомное железо. Такая наша политика по СХД, и она продиктована жизнью.
Если интересуетесь SDS/SDDC от АЭРОДИСК, то нужно смотреть в сторону vAIR и ARDFS:
В данной статье мы разберем только новый функционал СХД АЭРОДИСК серии 5. С описанием остального функционала можно ознакомиться в техническом описании продуктов:
Техническое описание СХД АЭРОДИСК серии 5
Кластер хранения
Функция «Кластер хранения» позволяет объединять разные системы хранения данных АЭРОДИСК (до 16 СХД/до 32 контроллеров) в единую инфраструктуру хранения данных. В кластере хранения для СХД-участников кластера используется ролевая модель, в которой предусмотрено две роли:
MASTER – контроллерная пара, являющаяся источником управляющих команд для всех остальных СХД в кластере (IO-модулей). MASTER также обеспечивает операции ввода-вывода для подключенных к нему хранилищ (продолжая выполнять роль IO-модуля для своих дисков)
SLAVE – IO-модуль, обеспечивающий операции ввода-вывода для подключенных к нему хранилищ. Все управляющие команды IO-модуль получает от MASTER-а через Restful API.
Для обмена командами и выполнения других кластерных операций в кластере хранения на физическом уровне используется интерконнект на базе протокола Ethernet (10/25/40/100 Gb/s). Коммутаторы для интерконнекта при необходимости поставляются в комплекте.
Важно не путать интерконнект кластера хранения и внутренний интерконнект HA-пар (HA-пара – это общее название контроллерных пар и IO-модулей с точки зрения отказоустойчивости). Интерконнект HA-пар соединяет только два узла пары и используется для отказоустойчивости HA-пары, которая реализована с помощью ассиметричного ввода-вывода (ALUA)
Подробнее об организации отказоустойчивости можно почитать все в том же техническом описании на нашем сайте, а также в одной из наших предыдущих статей:
Полезной особенностью является возможность объединения в один кластер хранения СХД разных процессорных архитектур в частности: ВОСТОК-5 на базе процессоров E2K (Эльбрус) и ENGINE-5 на базе процессоров архитектуры x-86.
На рисунке ниже приведена общая логика построения кластера хранения с указанием выполняемых функций в зависимости от роли СХД.
Ещё одно важное замечание. Кластер хранения не выполняет функции «одной большой СХД», ввод-вывод и хранение данных выполняются на базе тех HA-пар, которые физически подключены к своим дисковым подсистемам (внутренним корзинам и внешним дисковым полкам). При этом в рамках кластера хранения поддерживается функционал миграции данных между HA-парами через кластерный интерконнект.
Но это не значит, что функционал «одной большой СХД» не разрабатывается в данный момент и не имеет прототипа ;-).
Управление кластером хранения
Как видно из схемы, управление кластером осуществляется только с контроллерной пары MASTER-а. MASTER централизованно осуществляет мониторинг, сбор статистики и логов, а также выполняет функции обновления. Кроме того, в рамках кластера хранения предусмотрена миграция данных между всеми СХД - участниками кластера. Локальные операции на конкретных СХД, такие как создание пулов, групп, блочных устройств и т.п., выполняются путем отправки API-команд с MASTER-а на SLAVE-ы. Для управления каждой СХД в отдельности можно выбрать её в интерфейсе кластера хранения и «провалиться» в её «локальный» интерфейс. «Локальный» выделен кавычками, поскольку сам интерфейс функционирует также на MASTER-е, а взаимодействие с управляемой СХД происходит через API.
Роль мастера назначается при инициализации СХД. Для управления кластером предусмотрены соответствующие веб-интерфейс и командная строка, функционирующие в отдельном контейнере контроллерной пары MASTER-а. Подключиться к SLAVE IO-модулю напрямую и осуществлять управление в обход MASTER-а не получится, контейнер с веб-интерфейсом и командной строкой из соображений безопасности там заблокирован. Это "by design".
Задачей кластера хранения является консолидация управления разными СХД АЭРОДИСК. Подключение хостов к СХД не завязано на роль MASTER и выполняется напрямую к HA-парам кластера, поэтому с точки зрения ввода-вывода MASTER не является точкой отказа. Таким образом потенциальная недоступность обоих узлов контроллерной пары MASTER-а не влияет на доступность данных, которые обслуживают IO-модули. При этом на случай выхода из строя обеих нод MASTER-а для восстановления управления SLAVE-ами в спец. версии A-CORE, устанавливаемой на IO-модули, предусмотрена сервисная консоль управления для целей технической поддержки, которая позволяет кроме стандартных функций управления переназначить роль MASTER-а.
Dynamic Disk Pool v2
Предыстория вопроса
В СХД АЭРОДИСК до версии 5 было предусмотрено два метода организации пулов хранения (то есть виртуальных объединений дисков для последующих операций с ними).
RDG
В первой версии СХД АЭРОДИСК в уже далеком 2014 году был предусмотрен только один тип организации пулов – RAID DISTRIBUTED GROUP (RDG). Он работает, развивается и поддерживается по сей день.
В RDG физические диски первоначально объединяются в виртуальные устройства (VDEV) согласно четности уровня RAID (поддерживаются 1/10, 5/50, 6/60, 6P/60P (тройная четность)), который указывается при создании пула. Далее эти виртуальные устройства объединяются в длинный страйп, который уже и представляет из себя RDG. Поверх основного страйпа могут быть разные варианты кэширования и дополнительный уровень хранения на SSD/NVMe. Потом на базе данной конструкции создаются блочные устройства и файловые шары, которые презентуются хостам.
Основными преимущества RDG - его гибкость и функциональность, возможность создавать огромные пулы хранения без ущерба производительности (логического лимита нет), а также наличие и файлового, и блочного доступа. RDG очень хорошо себя показывает с точки зрения производительности на последовательной нагрузке, но поскольку одним из его минусов является относительно невысокая производительность на случайном блочном доступе, в 2017 году мы разработали и добавили альтернативный метод организации пулов – Dynamic Disk Pool (DDP).
DDP v1
В DDP физические диски (и HDD, и SSD) объединяются в дисковый пул, при этом первоначально не форматируются, а лишь помечаются меткой о том, что принадлежат к тому или иному пулу. Пул состоит из виртуальных блоков (чанков 4МБ или 16МБ).
Важной особенностью DDP является то, что уровень RAID задается на уровне LUN, а не пула/группы (в RDG наоборот). Таким образом, в одном пуле можно получить LUN-ы с разным уровнем RAID.
После создания пул также можно увеличивать или уменьшать путем добавления или исключения физических дисков (в RDG диски можно только добавлять). Если в пуле уже есть созданные LUN-ы, то после добавления новых дисков есть возможность сделать перераспределение чанков LUN-а на новые диски, для получения большей производительности и объема.
Как и в RDG, в DDP пуле есть опции многоуровневого хранения, которые назначаются на LUN администратором СХД. При этом основное назначение DDP – это AllFlash, то есть массив только из твердотельных дисков.
DDP проще по организации чем RDG, поэтому менее гибок с функциональной точки зрения, но при этом успешно решает свою задачу - блочное хранилище высокой производительности. И DDP, и RDG возможно совмещать в рамках одной СХД (HA-пары). Но в DDP тоже был свой изъян, который не казался нам сильно критичным в 2017 году – количество используемых дисков в одном блочном устройстве. В DDP1 при создании больших (то есть с большим количеством дисков) блочных устройств с уровнем RAID-5 и 6 наблюдалась просадка по производительности: чем больше дисков задействовано в LUN-е, тем больше просадка. В зависимости от уровня RAID деградация начиналась с разного количества дисков:
RAID-5/50 – 10 шт.
RAID-6/60 – 24 шт.
Поэтому в DDP1 установлены соответствующие ограничения.
DDP v2
При разработке DDP2 мы решали две основные задачи:
Исключить деградацию производительности для больших LUN-ов RAID-5/6/50/60;
Не снизить (а лучше повысить) характеристики производительности в целом.
В итоге реализованный метод организации хранения DDP2 по факту представляет собой гибрид RDG и DDP
Из RDG DDP2 взяли структуру организации физических дисков в VDEV-вы. То есть уровень RAID в DDP2 теперь задается также, как и в RDG - при создании пула. Поддерживаются следующие типы RAID: 1/10, 5/50, 6/60. При создании VDEV есть возможность выбрать размер хранимого блока: 4K-512K. Это нужно, чтобы можно было подогнать топологию пула под шаблон нагрузки с хостов.
Из первой версии DDP2 взяла верхнеуровневую организацию блочных устройств. Блочные устройства, как и в DDP1, состоят из чанков, размер которых может быть 4 МБ или 16 МБ. Все чанки объединены в единый ресурсный пул в RAID0, поверх которого создаются блочные устройства. Перестроения чанков при выходе из строя дисков производятся на уровне VDEV как и в RDG.
Таким образом структура DDP2 позволила снять ограничение для RAID 5/6/50/60. Также такая организация хранения позволила не только сохранить, но и улучшить производительность на случайном блочном доступе по сравнению с DDP1. Большой преформанс-тест будем публиковать отдельно, но если смотреть в целом, то в зависимости от задачи прирост производительность составляет 10-20%.
Подробнее о производительности СХД ENGINE и ВОСТОК можно прочитать в наших статьях:
https://habr.com/ru/company/aerodisk/blog/451456/
https://habr.com/ru/company/aerodisk/blog/560076/
Новый пул хранения DDP2 будет существовать параллельно с текущими виртуальными рейдами (RDG, DDP1) давая возможность администраторам гибко выбирать и комбинировать подходящие инструменты для решения задач хранения данных предприятий.
В качестве резюме к разделу статьи приводим сравнение функционала всех трёх инструментов хранения СХД АЭРОДИСК серии 5.
Задачи/функционал | RDG | DDP1 | DDP2 |
Максимальное количество контроллеров | 8 в NAS-режиме 2 в SAN-режиме | 2 в SAN-режиме | |
Отказоустойчивость HA-пар | Active/Active (ALUA) | ||
Уровни RAID | 1/10, 5/50, 6/60, 6/60P (тройная четность) | 0, 1, 10 ,5, 6 | 1/10, 5/50, 6/60 |
Блочный доступ | Да | ||
Файловый доступ | Да | Нет | |
Протоколы доступа | FC/iSCSI/NFS/SMB/IB | FC\iSCSI | |
Гибридные группы (SSD+HDD) | Да | ||
All Flash группы | Да | Да (предпочтительно) | |
Ограничения дисковых групп | Нет | RAID5 - 10 дисков RAID6 - 24 диска | Нет |
Разные уровни RAID на одной группе | Нет | Да | Нет |
Изменение объема дисковой группы | Да | ||
Rомпрессия и дедупликация | Да | ||
Тонкие тома | Да | ||
Онлайн-миграция LUN | Да | ||
SSD-кэш (чтение и запись) | Да | ||
Онлайн тиринг (SSD+HDD) | Да | Нет | |
Снэпшоты | ROW | COW | |
Локальная репликация | Да | Нет | |
Удаленная репликация (синх./асинх.) | Да | ||
Метрокластер | Да | ||
Глобальная автозамена дисков | Да | ||
Политики перестроения RAID | Да | Нет | |
Поддержка сетевых меток (VLAN) | Да | ||
Объединение сетевых интерфейсов (Bonding) | Да | ||
Назначение | Файловый доступ или блочный доступ с последовательным характером чтения и записи. | Блочный доступ со случайным характером чтения и записи, любые All-Flash сценарии | |
Защищенное исполнение (нормативные требования ФСТЭК/КИИ)
Также, как и в другом нашем новом продукте АЭРОДИСК Machine-V, системы хранения данных ВОСТОК-5 и ENGINE-5 опционально поставляются в защищенном исполнении. Не будем сильно расписывать этот функционал, т.к. аналогичная история приведена в предыдущей статье про ПАК АЭРОДИСК Machine-V. Поэтому кратко…
Напомним, что с 2018 года в России действует закон 187-ФЗ «О безопасности критической информационной инфраструктуры (КИИ)», обязывающий организации обеспечить комплексную защиту значимых объектов КИИ. К данной категории относятся информационные системы и сети, нанесение ущерба которым может привести к возникновению угрозы для здоровья и жизни людей, негативному влиянию на экономическую, политическую, экологическую и социальную устойчивость региона и государства в целом.
Исходя из этого у предприятий России есть задача по категорированию и аттестации ИТ-инфраструктуры для использования её в рамках КИИ.
В системах хранения данных АЭРОДИСК Восток-5 и Engine-5 предусмотрены дополнительные опции для защищенного исполнения с помощью сертифицированных ФСТЭК средств защиты информации «Аккорд-МKT» и «Аккорд X K» — средств доверенной загрузки уровня базовой системы ввода-вывода (БСВВ), которые разработаны компанией ОКБ САПР.
Доверенная загрузка — это загрузка различных операционных систем только с заранее определенных постоянных носителей (например, только с жесткого диска) после успешного завершения специальных процедур: проверки целостности технических и программных средств ПК (с использованием механизма пошагового контроля целостности) и идентификации / аутентификации пользователя.
В итоге СХД АЭРОДИСК серии 5 в защищенном исполнении позволяет решать задачи и аттестовать инфраструктуру хранения для:
ГИС 1 класса защищенности
ИСПДн 1 уровня защищенности
КИИ 1 категории значимости
Минпромторг и Минцифра, без них никуда
Для полноценной отечественности важно не только создать и поддерживать продукт, но и добавить его в соответствующие государственные реестры. См. пруфы ниже.
Минпроторг:
Минцифра:
https://reestr.digital.gov.ru/reestr/305513/?sphrase_id=1205716
https://reestr.digital.gov.ru/reestr/310137/?sphrase_id=1205720
Совместимость и интеграция с другими продуктами
СХД АЭРОДИСК серии 5 имеет широкий спектр совместимых и интегрированных смежных систем как российских, так и зарубежных.
Поддерживаются большинство популярных российских и зарубежных операционных систем, гипервизоры, СУБД, СРК, системы мониторинга и видеонаблюдения. Кроме того, налажена работа с популярным оркестратором OpenStack. Для него в конце 2021 года мы выпустили собственный cinder-драйвер для блочного доступа, и уже сейчас есть первое успешное внедрение в инфраструктуру на базе OpenStack в одном из крупных российских заказчиков.
Подводим итог
Мы разобрали новый функционал систем хранения данных ВОСТОК-5 и ENGINE-5. Основные изменения заключаются в обновлении аппаратной составляющей, а также добавлении таких больших функций как:
Кластер хранения, позволяющий консолидировать управление большим количеством разных СХД АЭРОДИСК;
Виртуальные пулы DDP2, позволяющие создавать высокопроизводительные блочные устройства большого объема;
Отдельное защищенное исполнение СХД АЭРОДИСК для применения её в критичной информационной инфраструктуре.
По традиции, после обзора новых решений мы 29 марта устраиваем очередной вебинар «ОколоИТ», на котором разберем функции новых СХД подробнее и в прямом эфире ответим на ваши вопросы.
Зарегистрироваться на вебинар можно по ссылке: https://bit.ly/3q9kFok
Также предлагаем подписаться на наш телеграм-канал «Импортозамещение здорового человека», где мы подозрительно трезво рассуждаем об импортозамещении ИТ в России.
Всем спасибо, ждем конструктивных комментариев. До новых встреч!
