Привет, HABR! В постоянно меняющемся мире сфера IT как одна из самых молодых пытается держаться на переднем крае. И мы, системные инженеры, должны учитывать все факторы окружающей среды, чтобы оставаться на плаву в этом неспокойном море. 

Быт инженера госкорпорации ознаменован девизом «Импортозамещение – наше всё!», и это диктует свои правила адаптации. В этом материале мы посмотрим на ДОМашний рынок IT-решений, а конкретно - на системы хранения данных российского производства. 

Будучи избалованными крупными иностранными IT-игроками, продукция которых десятилетиями выковывалась на наковальнях «магического квадранта Гартнера» и потому предлагает больше фич, мы столкнулись с рядом сложностей при выборе серверного оборудования. Непредсказуемыми IOPS-ами и устойчивостью при длительном использовании во времена тотальной дифференциации по цвету штанов уже никого не удивить, но вернуться во времена легендарных первых поколений EMC CLARiiON и HP MSA, пожалуй, было несколько неожиданно. 

Что сейчас?

На запрос «СХД российского производства» мы получаем список из нескольких производителей:

• АЭРОДИСК

• Норси Транс

• BAUM

• Bitblaze

• DEPO

• ICL Техно

• RCNTEC

• RAIDIX

• YADRO

В контексте импортозамещения обязательным условием для нас является нахождение рассматриваемого продукта в реестрах Минпромторга в классе с кодом ОКПД2 26.20.2.

Теперь оценим СХД со стороны сисадмина, который спокойно спит по ночам:

• Два контроллера, имеющих одновременный доступ ко всем данным СХД;

• Подключение к серверам по протоколу iSCSI (отечественного оборудования FC ещё не завезли);

• Отказоустойчивое подключение каждого контроллера к независимым сетевым фабрикам;

• Доступная 24/7 и квалифицированная техническая поддержка.

Получаем список претендентов на премию «Внедрение года»:

• АЭРОДИСК ВОСТОК БИТБЛЭЙЗ E3113HL сертификат РЭ-4650/22 действителен до 31.03.2023;

• АЭРОДИСК ВОСТОК 2Э8СВ сертификат РЭ-7047/22 действителен до 05.06.2025;

• YADRO TATLIN.UNIFIED сертификат РЭ-713/21 действителен до 31.03.2023.

Наши участники согласно спецификации:

АЭРОДИСК ВОСТОК БИТБЛЕЙЗ E3113LH

• Узлы контроллерной пары соединяются между собой с помощью SAS Beck-End через SAS Expander и кластерный интерфейс 10 Гбит/с Ethernet;

• 2 процессора Эльбрус 8С, 16 ядер на контроллерную пару;

• Оперативная память 128 ГБ на контроллерную пару;

• Front-end адаптер Ethernet 4x25Gb/s SFP28;

• 24 слота LFF 3.5” SAS3 с подключением к двум контроллерам;

• До 24 штук NL-SAS 3.5” HDD;

• До 24 штук SAS3 2.5” SSD.

АЭРОДИСК ВОСТОК 2Э8СВ

• Узлы контроллерной пары соединяются между собой с помощью SAS Beck-End через SAS Expander и кластерный интерфейс 10 Гбит/с Ethernet;

• 4 процессора Эльбрус 8СВ, 32 ядра на контроллерную пару;

• Оперативная память 512 ГБ на контроллерную пару;

• Front-end адаптер Ethernet 4x25Gb/s SFP28;

• Модуль расширения дисковой емкости 4U на 108 HDD 3,5” SAS 3.0;

• Модуль расширения дисковой емкости 4U на 60 HDD 3,5” SAS 3.0;

• Модуль расширения дисковой емкости 4U на 24 HDD 3,5” SAS 3.0;

• Модуль расширения дисковой емкости 2U на 12 HDD 3,5” SAS 3.0;

• Модуль расширения дисковой емкости 2U на 24 SSD 2,5 SAS 3.0;

• Модуль расширения дисковой емкости 2U на 25 SSD 2,5 SAS 3.0 (реестр «НТ» JBOD-25» сертификат РЭ- 4333/22 действителен до 31.03.2023.);

• До 608 штук NL-SAS 3.5” HDD;

• До 608 штук SAS3 2.5” SSD.

YADRO Tatlin.Unified

• Узлы контроллерной пары соединяются между собой с помощью RDMA-NTB 2х100 Гбит/с RoCEv2;

• 4 процессора IBM Power 9, 64 ядра на контроллерную пару;

• Оперативная память 1024 ГБ на контроллерную пару;

• Front-end адаптер Ethernet 8x25ГБ/с SFP28;

• Дисковая полка расширения DBN (70 3.5” SAS3 + 34 U.2 NVMe + 2 U.2 NVMe для ОС);

• Дисковая полка расширения DBS (96 3.5” SAS3);

• До 550 штук NL-SAS 3.5” HDD;

• До 550 штук SAS3 2.5” SSD;

• До 34 штук U.2 NVMe SSD.

Сисадмин всегда решает утилитарные задачи, и в этот раз требуется обеспечить надежное хранение бэкапов БД Postgres, архивов электронной почты и холодных данных системы анализа событий информационной безопасности. Одно из самых важных условий для создания успешного бэкапа – уложиться в технологическое окно.

Наши требования:

• RAID/Erasure Coding по схеме N+2 при записи на физические носители информации;

• Наличие резервных накопителей, для автоматического восстановления заданного уровня отказоустойчивости дисковых групп;

• 500 ТБ полезного пространства;

• 100 ТБ записи за 6 часов технологического окна;

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

 Т.е. мы должны уметь принимать на борт 100 Тб за 6 часов при работе через 1 контроллер HA пары, или 4,7 Гбайт/с, а значит, рассматривать мы будем цепочку шин и интерфейсов от Front-end до Back-end в лице HDD, и её главный показатель – пропускную способность (maximum throughput). Сравнивать будем гигабайты с гигабайтами.

Итак, на одном конце (FE) нашей цепочки у нас во всех случаях интерфейсы Ethernet 25Gb/s. На другом (BE) - HDD NL SAS. Отличия будем искать на внутренних звеньях нашей цепи.

Для СХД АЭРОДИСК ВОСТОК БИТБЛЕЙЗ E3113LH, спускаясь от интерфейсов по шине PCIe 2.0 х8 (4Гбайт/с), попадаем на контроллер периферийных интерфейсов (КПИ-2, микросхема южного моста 1991ВГ2Я — контроллер ввода-вывода 2-го поколения собственной разработки МЦСТ), далее со скоростью 16 Гбайт/с до процессора, потом обратно, и вниз по шине PCIe 2.0 х8 (4Гбайт/с) до SAS HBA (16 х SAS3 = 24ГБ/с) и 24 дискам NL-SAS, которые в сумме нам смогут выдать 6,3 Гбайт/с = (24 х Throughput NL-SAS). Таким образом, узким местом в нашей цепи станут диски.

В случае АЭРОДИСК ВОСТОК 2Э8СВ картина выглядит чуть более радужно. Путь до SAS HBA практически повторяет предыдущий случай лишь за некоторыми исключениями в виде прохождения через два КПИ-2 и два процессора, которые можно наблюдать на структурной схеме контроллера данного СХД.  От SAS HBA контроллерного шасси по SAS3 x4 мы попадаем на SAS экспандер корзины со 108 дисками NL-SAS, которые уже смогут нам выдать 28,3Гбайт/с = (108 х Throughput NL-SAS).

В данном случае диски больше не являются узким местом, теперь это пропускная способность шины PCIe 2.0 x8 в 4 Гбайт/с.

 Наконец, перейдем к рассматриванию под нашим субъективным микроскопом СХД Yadro Tatlin Unified. От Front-Ent портов до процессора мы двигаемся по шине PCIe 3.0 x8, между процессорами по двум каналам XBUS 4B со скоростью 100Гб/с, далее опять по PCIe 3.0, только уже х16, до дисковой полки DBN, внутри полки PCIe 3.0 x8 до SAS HBA, и по SAS3 мы, наконец, попадаем на диски в количестве 70 штук (18,2Гбайт/с = 70 х Throughput NL-SAS). В итоге здесь мы также упираемся в пропускную способность шины PCIe, но уже версии 3.0 х8.

Ширина полосы пропускания для каждого СХД изображена на схемах ниже:

Вспомним одно из главных условий для наших претендентов – обеспечение пропускной способности в 4,7 Гбайт/с. Таким образом, можно сделать вывод, что 4 Гбайт/с, которые может обеспечить шина PCIe 2.0 x8, доступная на решениях от компании АЭРОДИСК, недостаточны для работы двух портов 25GbE на полной скорости и соответственно для решения нашей основной задачи (100ТБ за 6 часов при работе через 1 контроллер HA пары). Решение было принято в пользу закупки СХД от компании YADRO.

От теории к практике, или «что и как нам удалось потрогать»

Ниже рассказ об опыте внедрения Tatlin.Unified от компании Yadro.

Помимо вышеуказанных требований к оборудованию нам бы хотелось иметь в нем:

• интеграцию с виртуализацией (в нашем случае Vmware);

• полный комплект лицензий «из коробки»;

• возможность выбора нескольких видов защиты от отказа диска.

В итоге к нам приехала вот такая СХД Yadro Tatlin.Unified:

В нашей спецификации мы имеем:

• Пара контроллеров в корпусе 3U, работающие по схеме Symmetric Active/Active, в каждом 2хIBM Power9 16 core, 16х32 GB RAM DDR4;

• Дисковая полка DBN размером 4U с 70-ю дисками NLSAS по 14 ТБ и 10-ю дисками NVMe по 7.68 ТБ;

• Порты ввода-вывода:  8х25Gb/s Ethernet, 8x16Gb/s Fibre Channel;

• Служебные порты: 4x100 Gb/s RoCE (для интерконнекта), 2х1Gb/s (для управления), 8xPCIe 3.0 (для подключения первой полки DBN);

• 2 системных диска NVMe объемом 1.92 ТБ для функционирования кластера, установленные в дисковой полке DBN спереди.

Вид сзади на контроллеры с полкой DBN:

Из необычного сразу бросаются в глаза три вещи:

• схема размещения контроллеров в корпусе: "один за другим" (ниже на фото вид сверху);

• диски NLSAS стоят вертикально, при этом диски NVMe вставляются сзади полки обычным способом.

Полка DBN, вид сверху:

• первая (и единственная) полка DBN, которая поддерживает диски NVMe подключается по PCIe, остальные полки, в которых могут стоять только диски SAS/NLSAS – по SAS.

В качестве технологии защиты данных при отказе диска СХД использует технологию T-RAID, основанную на кодах Рида-Соломона. Напомним, что это корректирующие коды с избыточностью, работающие по схеме K+M+S, где K – число блоков исходной информации, M – число избыточных блоков, а S – число блоков, зарезервированных под восстановление данных (spare).

Администратор сам может выбирать необходимую схему защиты. Например, для NVMe дисков доступны схемы:

А для HDD их значительно больше:

При создании пула можно выбрать число накопителей в пуле или объем пула. Во втором случае СХД сама определит необходимое число накопителей. Все жесткие диски в пуле делятся на секции. Размер секции зависит от числа дисков в пуле и равен 16 МБ, если число дисков в пуле меньше или равно 60, и 32 МБ, если число дисков в пуле больше 60.

Размер секции даже в 16 МБ означает, что, например, при схеме 4+1 при изменении хотя бы одного байта в пуле необходимо прочитать 4х16 МБ пользовательских данных и записать новые 4х16 МБ пользовательских данных и 1х16 МБ корректирующих данных. Согласитесь, выглядит не слишком производительно.

На помощь нам приходит страйпинг. Это размещение последовательных пользовательских данных с чередованием секций.

Принципиальная схема страйпинга:

Размер страйпа можно выбрать при создании пула - от 4 KB до 2 MB в зависимости от схемы защиты данных.

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

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

СХД Tatlin.Unified:

• 70 HDD 14 ТБ дисков в пуле, собранные по схеме 8+2+4. Полезный объем – 667.63 ТБ. Размер страйпа 32 KB. Один ресурс (том) размером 10 ТБ, поданный по iSCSI. Версия ПО 2.5.

• 10 NVMe 7.68 ТБ дисков в пуле, собранные по схеме 1+1+1. Полезный объем – 31.43 ТБ. Размер страйпа 4 KB. Один ресурс (том) размером 10 ТБ, поданный по iSCSI. Версия ПО 2.5.

Хосты Vmware:

• 4 хоста Vmware 7.0.3: HP Proliant DL360 Gen10, Intel Xeon Gold 6226 2.7 GHz, 256 GB RAM, 2x10Gb/s Eth.

Сначала была проверка заявленных возможностей и функционала. И тут сразу возникли проблемы:

1. Прозрачное увеличение пула. При увеличении пула с 60 до 70 дисков происходит падение производительности на 50% на время менее 5 с. Производительность упала с 6000 IOPS до 3000 IOPS, при этом логический том был доступен, и Vmware пути к нему не потеряла.

2. Прозрачное увеличение логического тома (ресурса). При увеличении размера логического тома происходит падение производительности на 66% на время до 10 с. Производительность упала с 6000 IOPS до 2000 IOPS, при этом логический том был доступен и Vmware пути к нему не потеряла.

3. Система заявлена как Unified, но по факту файловый доступ работает в очень ограниченном режиме. Так, например, доступ по NFS с хоста возможен только под одним пользователем - под тем, кто монтировал share на хосте. Хотя создание пользователей и выдача им необходимых прав на СХД присутствует, но другим пользователям доступ на share не предоставляется. А подключение по CIFS работает только с помощью LDAP, AD не поддерживается.

4. Размер блочного логического тома увеличить можно, а размер share увеличить нельзя. Хотя команда в cli присутствует.

5. Вишенка на торте: СХД при выполнении нагрузочного тестирования по NFS просто выключилась через пару часов.

Несмотря на вышеуказанные недостатки мы решили провести вторую часть испытаний, а именно тесты на отказоустойчивость. Тут тоже не обошлось без сюрпризов:

1. При вынимании жесткого диска сообщение в почте администратора появляется только через 30 минут. Не стоит удивляться – это так и задумано производителем.

2. Выключение или перезагрузка одного из контроллеров в нашем случае привела к уменьшению производительности с 9000 IOPS до 1500 IOPS в течение 30 с.

3. Выключение кэша на запись уменьшает производительность с 6000 IOPS до 4000 IOPS. Выключение кэша на чтение уменьшает производительность с 6000 IOPS до 5000 IOPS.

4. Отключение 1 из 8 кабелей PCIe между контроллерами и дисковой полкой привело к прекращению работы СХД.

Сказать, что мы были слегка удивлены – это мало. Инженеры производителя собрали необходимые логи и ушли думать. В результате нам были заменены системные диски, обновлено ПО до версии 2.6, заменены платы коммутации PCIe с установкой новой версией ПО внутри них.

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

1. Выключение одного из четырех iSCSI портов приводит к остановке IOPS на время до 5 с. При этом логический том остается доступен хостам.

2. При схеме защиты 8+2 ребилд двух дисков уменьшает производительность СХД с 6000 IOPS до 4000 IOPS, то есть на 30%.

3. Выключение или перезагрузка одного из контроллеров приводит к остановке IOPS на время до 5 с. При этом ресурс остается доступен хостам.

Тесты на производительность

Замеры мы делали с помощью утилиты HCI Bench от Vmware. Нагрузку генерировали 8 виртуальных машин, в каждой 10 дисков по 100 ГБ. Тестирование проводили при 2 и 8 потоках на диск ВМ.

Основная нагрузка будет размещена на HDD дисках. Размер страйпа в 4 KB вряд ли будет уместен при работе с бэкапами и архивами.

Поэтому мы собрали HDD пул из 70 дисков со страйпом в 128 KB, исключили тесты с 1 потоком на диск, использовали размеры блоков 512k и 1024k, включили кэш на запись и на чтение.

И вот что получили:

1. Последовательное чтение

Для 100% последовательного чтения ситуация выглядит следующим образом:

С увеличением размера блока резко возрастают задержки. По полосе пропускания мы достигаем числа в 4,2 Гбайт/с при размере блока в 1024k.

2. Последовательная запись

При 100% последовательной записи картина несколько меняется и не в лучшую сторону:

Задержки могут достигать почти 500 мc при пропускной способности лишь в 1,7 Гбайт/с на блоке 1024k, а достижение целевых 4,7 Гбайт/с осталось в бэклоге.

Для измерения производительности также были проведены тесты с использованием утилиты ATTO Disk Benchmark. Виртуальная машина под ОС Windows была размещена на Датасторе, поданом с СХД YDRO Tatlin Unified. Внутри ОС был запущено приложение. Для блоков 512k, 1024k и 2048k с разным размером файла были получены следующие результаты:

Это лишь синтетика - как себя поведет СХД при реальной нагрузке, нам еще предстоит узнать.

Напоследок

Несколько слов хочется сказать про заботу об администраторах, а именно про удобство управления самой СХД. Из плюсов можно отметить:

• простой web-интерфейс на русском и английском языках;

• производительность в реальном времени на главной странице;

• трехцветная (зеленый, желтый, красный) индикация состояния логических и физических объектов на главной странице;

• удобство сбора логов прямо из web-интерфейса;

Но и минусы тоже присутствуют:

• не хватает детальной информации об ошибках на главном экране. Например, на главном экране высвечиваются желтым логические объекты. Нажимаем на иконку, попадаем в закладку “Логические объекты”, а они все горят зеленым, никаких ошибок по ним нет. Оказывается, что на порту, привязанном к логическому ресурсу, отсоединили оптический кабель;

• удалить ресурс можно, даже если он подключен к хостам. Хотелось бы иметь более продвинутую систему защиты от случайных нажатий;

• не отображается занятое место на share: в web-интерфейсе share показывается всегда размером 0 B;

• при включенном оповещении по SMTP система раз в сутки посылает сообщение о своем самочувствии. Отключить это невозможно, поэтому почтовый ящик администратора будет нуждаться в периодической чистке;

• дата и время хоть и берутся с ntp сервера, но отображаются в зоне GMT. Указать нужную временную зону нельзя;

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

• при добавлении хостов по iSCSI приходится руками вбивать их iqn. Автоматический discover у нас так и не заработал;

• журнал событий присутствует, но он не показывает ничего, кроме заголовка ошибки.

Вывод

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

К производительности тоже есть вопросы. Положить на Татлин нетребовательные ресурсы можно, но класть туда высоконагруженную БД или виртуализацию с большим количеством виртуальных машин – тут надо очень хорошо подумать.

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

Автор: Виктор Круглов, директор по ИТ-инфраструктуре ДОМ.РФ