Всем доброго здравия! В этой статье мы проведем обзор обновленной линейки систем хранения данных АЭРОДИСК Восток-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
Также предлагаем подписаться на наш телеграм-канал «Импортозамещение здорового человека», где мы подозрительно трезво рассуждаем об импортозамещении ИТ в России.
Всем спасибо, ждем конструктивных комментариев. До новых встреч!
