Хабр, привет! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К2Тех. За последние годы у российских ИT-специалистов выработался «синдром недоверчивого покупателя». Когда презентуют очередную «полностью отечественную» разработку, машинально ищешь подвох: знакомый корпус под новым шильдиком, наспех перелицованный Open Source или иероглиф где-нибудь на плате. Устройство выглядит солидно, жужжит по-корпоративному, но все равно хочется заглянуть под капот. И мы заглянули.
В нашу лабораторию приехала система хранения данных YADRO TATLIN.UNIFIED Gen2. Мой коллега ранее делился в Хабра-статьях итогами тестирования решений от вендора YADRO: СХД начального уровня TATLIN.FLEX.ONE и системы TATLIN.BACKUP для хранения резервных копий.
Итак, мы не стали церемониться: дергали диски на горячую, рубили питание / сеть / контроллеры и все, до чего могли дотянуться, протестировали модный NVMe over TCP в сравнении с классическим Fibre Channel. А потом обнаружили, что реальные цифры производительности разошлись с даташитом — причем в неожиданную сторону. Сейчас все расскажу.
TATLIN.UNIFIED — универсальные высокопроизводительные системы хранения данных (СХД). Модель второго поколения (Gen2) представлена на рынке с 2023 года и продолжает развиваться. Мы тестировали актуальную версию СХД с прошивкой v3.2 (на тот момент она еще не вышла в открытый доступ, но сейчас уже готова и вышла в релиз). Главное нововведение — поддержка высокопроизводительного протокола NVMe over TCP, но обо всем по порядку.
Heavy Metal
Когда смотришь на распаковку TATLIN.UNIFIED Gen2 (точнее на то, как сервисные инженеры YADRO делают это за тебя), сразу видно, что устр��йство создавали люди, которые действительно любят железо и не боятся экспериментировать.
Так, одно из главных отличий TATLIN.UNIFIED Gen2 от большинства СХД — компоновка шасси. Здесь доступ к внутренностям открывается сверху. Чтобы обслужить контроллеры, добавить плату расширения или заменить память, нужно выдвинуть шасси из стойки и снять верхнюю крышку, как капот автомобиля. Раз шасси нужно выдвигать, сзади должен быть идеально уложенный кабель. К счастью, YADRO комплектует систему специальным органайзером.
Внутри 3U-корпуса установлена пара независимых контроллеров. Это кастомные платы с плотной компоновкой и собственным интерконнектом. Еще одна деталь, которая привлекает внимание — массив синих батарей. Это аккумуляторы, которые защищают кэш: при отключении электричества они поддерживают работу системы, пока система не перенесет данные из кэша на запись в ПЗУ. Для отечественных СХД такое решение уникально, хоть и привычно для всех зарубежных А-вендоров.
Компоновка
Дисковые полки подключаются по SAS к портам HBA-контроллеров. На первый взгляд система выглядит громоздкой: контроллер занимает 3U, полка на 96 накопителей — еще 4U. Но если посчитать плотность размещения, то картина меняется. Один контроллер с одной полкой — 96 дисков в 7U, то есть примерно 13,7 диска на юнит. Добавляем вторую полку и получаем 192 диска в 11 U, плотность 17,5 диска на юнит. Это не хуже, а при масштабировании даже лучше привычных 2U-полок на 24 диска.
Диски загружаются вертикально сверху, и для этого полку нужно выдвигать. Но ради такой плотности можно и повозиться.
Внутри обычные, SAS SDD Samsung MZILT1T9HBJR, установленные в специальные переходные салазки, однако диски прошиты производителем, так что об использовании сторонних комплектующих речи не идет.
Интерфейсы
Слоты расширения TATLIN.UNIFIED Gen2 позволяют установить до 20 портов Fibre Channel 32 Гбит/с, 40 портов Fibre Channel 16 Гбит/с (10 4-портовых карт FC 16 Gb/s) или до 20 портов Ethernet 25 Гбит/с. В нашей СХД стояла пара карт FC 32 Гбит/с и пара Ethernet 25 Гбит/с. Через Ethernet порты возможен как блочный (iSCSI, NVMe over TCP), так и файловый доступ.
Полки подключаются по SAS 12 Гбит/с. Между собой контроллеры общаются через RDMA на скорости 100 Гбит/с. Это позволяет им работать в режиме Active-Active.
Блоков питания четыре (два в контроллерном шасси по 1600 Вт и два в дисковой полке по 2000 Вт каждый), они дублированы и поддерживают горячую замену. По энергопотреблению в зависимости от набивки потребуется от 650 до 2000 Вт.
Резюме по железу
К качеству распайки компонентов на платах, продуманности воздушных потоков, салазкам и фиксаторам трудно придраться. Шасси выполнено на высоком уровне. Разве что форм-фактор с верхней загрузкой — решение «на любителя», которое требует аккуратного кабель-менеджмента. В целом для российского рынка образца 2025 года аппаратная платформа TATLIN.UNIFIED Gen2 выглядит неожиданно бескомпромиссной.
Сервис «под ключ»
Мы привыкли ковыряться в железе сами, но даже для тестового сервера YADRO настояла на установке «под ключ». Так что для нас знакомство с TATLIN.UNIFIED Gen2 началось не с распаковки, а с опросных листов.
Процесс инсталляции формализован до мелочей. Перед отгрузкой оборудования проходит валидация площадки: нужно указать глубину стоек, тип направляющих, описать охлаждение и подвод питания. Нам даже пришлось взяться за рулетку, так как никто точно не помнил, на какую глубину выставлены рельсы в тестовом стенде. Зато при монтаже все прошло без сюрпризов.
Пусконаладку выполняет сертифицированный инженер YADRO. Ряд операций доступен только производителю: сброс паролей, восстановление в заводское состояние, переустановка ОС, глубокая диагностика. Чувствуешь себя не владельцем железа, а пользователем, которому «дали порулить».
Следовательно, переехать в другой ЦОД или переставить полку самостоятельно не получится. Но для большинства enterprise-заказчиков предсказуемость SLA важнее возможности самообслуживания.
Ситуация с обновлениями ПО пока такая же, как с монтажом. Мы тестировали СХД в предрелизной версии 3.2. Обновление прошивки проводили инженеры YADRO, и это, пожалуй, к лучшему: в процессе возникали заминки. Вендор обещает, что в будущих релизах процедура упростится и, возможно, станет доступна партнерам.
Отдельно отметим качество техподдержки. На протяжении всего теста мы общались с инженерами, которые знают архитектуру продукта изнутри. Когда в бенчмарках увидели неожиданные цифры (об этом дальше), получили развернутую консультацию: как работает кэширование, как распределяются потоки, почему NVMe over TCP ведет себя именно так.
Чувствуешь, что за железкой стоят живые люди, которым не все равно: они признают баги и фиксят, объясняют логику, помогают с сайзингом. Для российского enterprise-рынка такая открытость — редкость.
Документация
Человеческий подход ощущается и в документации. В веб-интерфейсе есть отдельный раздел с PDF, там лежат руководство администратора, инструкции по CLI, описание REST API, гайды по настройке хостов под Linux, Windows и VMware.
В общем, все под рукой, и не нужно лезть на портал поддержки, вспоминать логин, искать модель СХД в каталоге. Инструкции написаны хорошо, это не машинный перевод с китайского и не копипаст из man-страниц Linux.
Call-Home и удаленная диагностика
А еще СХД умеет «звонить домой» в сервис-центр YADRO, если что-то идет не так. Конечно, оповещения можно направить и себе: по SMTP, через SNMP-трапы или на внешний Syslog-сервер. Кроме алертов об ошибках, система шлет и регулярные отчеты о состоянии.
Логи выгружаются прямо из GUI и не запаролены. Правда, без документации разработчика читать их сложновато, бинарные дампы и системные сообщения — не художественная литература.
Резюме по сервису
Если вы enterprise-заказчик — банк, госкорпорация, крупный ритейл, для которых простой стоит миллионы, а штат админов и так перегружен, такой сервис — именно то, что нужно. YADRO выстроила зрелую сервисную модель, как у взрослых вендоров, а местами даже лучше.
Интерфейс
UI российского enterprise-ПО обычно ассоциируется с чем-то средним между Windows 95 и пультом управления АЭС. Поэтому, открывая веб-интерфейс TATLIN.UNIFIED Gen2, испытываешь легкий культурный шок. Он... красивый? Логичный? И да, темная тема тоже есть.
Первое, что встречает после логина (помимо дашборда с графиками нагрузки) — интерактивная модель СХД.
Вид сверху отображает дисковую полку: если диск сбоит, он подсвечивается красным или желтым прямо на картинке.
Вид сзади — порты как на ладон��: наводишь курсор на FC-порт, и всплывает тултип со статусом линка, скоростью и WWN.
UI выполнен на уровне зарубежных вендоров, а местами даже удобнее. Кстати, YADRO настолько уверена в своем интерфейсе, что сделала публичную демо-версию (но не самую последнюю) — Tatlin Tour.
Логическая топология
В разделе «Логические объекты» представлена карта связей: справа хосты, слева тома, между ними линии подключений. Сразу видно: какой кластер подключен к десяти томам, а какой никому не назначен. Стоит привыкнуть и карта становится становится любимым инструментом для аудита конфигурации.
Отдельно стоит упомянуть систему мониторинга. В TATLIN.UNIFIED Gen2 реализован полноценный набор графиков: загрузка контроллеров, поведение томов, активность портов.
Для кастомных графиков доступны выгрузки в CSV, но встроенных предопределенных метрик выгрузок пока нет. С масштабированием тоже не совсем удобно: диапазон приходится задавать вручную, хотя удобнее было бы выделить нужный участок мышкой и сразу зуммировать.
Заметное отличие от предыдущих поколений — снижение детализации по отдельным накопителям. Если раньше можно было посмотреть здоровье каждого SSD, то теперь система ориентирует администратора на «прикладные» объекты: тома, хосты, группы. Предполагается, что детали — скорее забота техподдержки. Для крупных инсталляций это логично, но инженерам, привыкшим диагностировать железо самостоятельно, может быть неудобно.
Групповые операции
Большая часть работы с СХД — это рутина: создать 50 томов, нарезать их хостам, настроить маппинг. Для решения подобных задач YADRO предлагает использовать групповые операции.
Через фильтр находишь тома по маске имени, выделяешь галочками, жмешь «Действие» → «Подключить к хосту» — готово. Однако подобная логика работает не везде. Например, создать «Группу ресурсов» (по сути, группу консистентности) можно, но назначить ее целиком на «Группу хостов» нельзя. Приходится мапить тома по старинке, а в крупных кластерах это ощутимая ручная работа.
Ложка дегтя
Идеальных интерфейсов не бывает, и в TATLIN.UNIFIED Gen2 есть и другие мелкие недоработки UX.
В разделе журналов есть фильтры по уровню критичности: Warning, Error, Critical. Логика подсказывает, что если выбирать Warning, то увидишь все, что Warning и хуже. Но фильтр работает строго: выбрал Warning — видишь только Warning. Критические ошибки при этом не отображаются. Это наверняка поправят (или уже поправили), но поначалу это нас здорово запутало.
В некоторых вложенных меню, например, при просмотре ресурсов внутри хоста, пропадает сортировка по колонкам.
Справедливости ради, в��е это придирки уровня «почему в Ferrari неудобный подстаканник». Ехать не мешает, но фидбэк вендору мы передали.
CLI и API
TATLIN.UNIFIED Gen2 предлагает полноценную командную оболочку с понятной структурой на радость фанатам CLI-only.
Логика команд: объект → действие → параметры. Например: volume create name=test size=100G. Tab-completion на месте: нажимаете Tab, и система дописывает команду или предлагает варианты. Встроенный help покрывает все команды с примерами.
Приятная деталь: при подключении по SSH вы попадаете в ограниченную оболочку rbash, из которой запускается tatlin-cli. Вырваться в «голый» Linux и исполнить что-нибудь вроде rm -rf / вам не дадут. Но в то же время есть и эргономический просчет: даже находясь в специальной оболочке, приходится писать tatlin-cli перед каждой командой. Алиасы или вход сразу в контекст утилиты пока не предусмотрены, и при длительной отладке это утомляет.
У TATLIN.UNIFIED Gen2 подробно документированный REST API. На СХД крутится Swagger-интерфейс: открываете в браузере документацию, смотрите пример curl-запроса, выполняете и сразу видите ответ.
Это развязывает руки для автоматизации. Нужен скрипт, который каждую ночь делает снэпшоты и удаляет старые? Пожалуйста. Хотите интегрировать создание томов в CI/CD-пайплайн? Легко.
Мы тестировали создание ресурсов через API — все работало, пока наш скрипт не зациклился и не забил снэпшотами все свободное место. Ввод-вывод на томах остановился, но система повела себя достойно: после очистки мусора тома автоматически продолжили нормальную работу без перезапуска и каких-либо проблем.
Резюме по интерфейсу
Интерфейс TATLIN.UNIFIED Gen2 производит приятное впечатление. Это современное, быстрое и информативное одностраничное приложение.
Да, местами видны следы активной разработки: баги фильтров, мелкие недочеты верстки. Но направление верное, ведь сложная система не должна выглядеть сложно. Среди отечественных конкурентов это высшая лига. Среди западных аналогов — крепкий уровень, за который не стыдно. YADRO умеет делать не только мощное железо, но и удобный софт.
Производительность: маркетологи... занизили цифры?
Есть негласное правило, известное каждому админу: «Дели на два». Если в красивом PDF-буклете вендор пишет «до 1 миллиона IOPS», опытный инженер читает это как: «Ну, если поставить систему в вакуум, забить ее одними кэш-хитами, отключить все фоновые процессы и принести в жертву черного петуха, может быть, мы увидим эту цифру перед тем, как контроллеры расплавятся».
С YADRO TATLIN.UNIFIED Gen2 получилось наоборот: инженеры сделали продукт, который работает быстрее, чем обещают их собственные маркетологи. Когда мы запустили первые тесты в лаборатории, сначала подумали, что сломался инструмент мониторинга.
Архитектура стенда
СХД: YADRO TATLIN.UNIFIED Gen2;
Хосты: серверы с Linux CentOS 9;
Сеть: FC 32 Gb/s (HBA Emulex), Ethernet 25 Gb/s (Mellanox ConnectX-6), iSCSI на том же 25 Gb/s Ethernet.
Нагрузка: пул прямой адресации схема защиты 8+2 из 24 дисков, для трех разных протоколов.
Обратите внимание, что полоса пропускания у FC физически выше, чем у Ethernet. Это важно для понимания результатов.
Тест 1 и два миллиона попугаев
Любое тестирование СХД начинается с прогрева — попытки найти предел возможностей контроллеров. Подаем нагрузку, которая гарантированно попадает в кэш. Это синтетика, далекая от реальной жизни, но она показывает потолок производительности архитектуры. Если контроллер захлебнется на 500 тысячах IOPS из памяти — никакие быстрые SSD его не спасут.
Сценарий: профиль 100% Random Read, блок 4KB и 8KB. Цель — перегрузить контроллер.
В справочных материалах YADRO заявляет около 1,5 миллиона IOPS. Мы запустили vdbench и увидели стабильные 2,2 миллиона. В пике до 2,4 млн, но самое интересное — не абсолютное значение, а загрузка CPU. Обычно, когда СХД выходит на предельные IOPS, процессоры контроллеров загружены на 90–95%. У TATLIN.UNIFIED Gen2 при 2,2 млн IOPS процессоры работали на 35%.
На практике это означает колоссальный запас прочности. Архитектура настолько оптимизирована (или железо настолько мощное), что «бутылочным горлышком» становятся не мозги СХД, а внешние интерфейсы или сами накопители.
Тест 2: Fibre Channel против NVMe over TCP
Синтетика — не самое интересное. Основная цель, ради которой мы взялись за этот обзор — сравнение протоколов доступа.
Сколько работаем с СХД, столько Fibre Channel был королем в ЦОДах: привычный, надежный. Но отечественных реестровых FC-коммутаторов нет и не предвидится, в отличие от Ethernet. Отсюда вопрос, который встает перед многими заказчиками: как пересесть с FC на Ethernet, не потерять в производительности, не раздуть задержки, да еще и сохранить удобство эксплуатации?
iSCSI — известный вариант, но со своими болячками. На смену ему приходит NVMe over Fabrics, а конкретно в случае YADRO — NVMe over TCP. Поддержка этой технологии появилась в версии 3.2, причем системе не важно, какие диски стоят внутри — NVMe или нет. Мы стали одними из первых, кто протестировал эту функциональность и сравнил протокол с классикой.
Мы подготовили стенд и начали подавать нагрузку (70/30% Read/Write, 4K, 32 потока), постепенно повышая количество IOPS: 300к, 500к, 800к и NVMe over TCP оказался быстрее Fibre Channel.
Нагрузка | 300K iops | 500K iops | 800K iops | 1100k iops | |||||
| Задержка, мс | Утилизация CPU% | Задержка, мс | Утилизация CPU | Задержка, мс | Утилизация CPU | Задержка, мс | Утилизация CPU | Достигнутый максимум, IOPS при заданной нагрузке |
NVMEovTCP | 0.12 | 16.40 | 0.15 | 17.2 | 0.239 | 23.1 | 0.495 | 18.5 | 963K |
FC | 0.168 | 19.40 | 0.22 | 18.8 | 0.24 | 20.2 | 0.282 | 24.2 | 1100K |
iSCSI | 0.207 | 19.10 | 0.24 | 20.8 | 0.293 | 29.1 | 0.462 | 33 | 1079K |
Но почему NVMe over TCP упёрся в потолок 963K IOPS, а Fibre Channel и даже iSCSI выдали больше миллиона? По логике, NVMe over TCP должен масштабироваться лучше, ведь у него меньше накладных расходов на инкапсуляцию. В iSCSI команды SCSI упаковываются в TCP, затем в IP, затем в Ethernet. В результате получается многослойная конструкция, которую процессору приходится распаковывать на каждый запрос.
Мы перепроверили настройки стенда, но результаты повторились. Возможно, дело в особенностях реализации драйвера или в параметрах тюнинга, которые мы не учли.
NVMe over TCP устроен иначе. Этот протокол создавали специально для флеш-памяти. У него глубже очереди и меньше процессорных тактов уходит на обработку каждого пакета. Поэтому на рабочих нагрузках до 800 тысяч IOPS (а это покрывает 99% реальных задач) NVMe over TCP побеждает. Мы получаем меньшую задержку на обычном сетевом оборудовании.
Однако, когда мы выкрутили нагрузку на максимум, на отметке 1,1 млн IOPS протокол NVMe over TCP начал сдавать позиции:
FC 32 Гбит/с — спокойно переварил нагрузку, задержка 0,28 мс;
NVMe/TCP 25 Гбит/с — уперся в потолок около 960K IOPS, задержка выросла до 0,5 мс;
iSCSI — выдал чуть больше (1 млн IOPS), но с задержкой 0,46 мс.
Мы подозреваем, что дело не в СХД, а в стеке хоста и сетевых настройках. NVMe over TCP — технология молодая и драйверы в ядре Linux, параметры сетевых карт, настройки очередей под нее еще не оптимизированы, в то время как Fibre Channel отлаживают уже десятки лет.
Но давайте будем реалистами: насколько часто в продакшене нагрузка на одну СХД превышает миллион IOPS? Если нет, то низкая задержка NVMe over TCP оказывается полезнее. Однако стоит иметь в виду, что если вы привыкли к классической триаде «Host — LUN — Masking», то с NVMe over TCP придется перестроиться. Здесь логика диктуется стандартом NVMe: вместо маппинга конкретного луна хосту мы оперируем «группами доступа».
В группы собираются тома (становясь Namespaces), порты контроллеров и хосты (NQN). По сути, вы конфигурируете NVMe Subsystem. Это ломает привычные паттерны SAN-администратора, но технически это более грамотная реализация спецификации. Коллеги из YADRO написали про это целый пост с массой подробностей.
Функциональность: пока скромно
К аппаратной платформе TATLIN.UNIFIED Gen2 вопросов нет, а вот функционально решение пока что довольно минималистичное. Архитектура СХД ставит администратора перед выбором уже на этапе создания пула.
T-RAID
Для базовой защиты данных YADRO использует собственную технологию T-RAID — виртуализированный RAID на основе кодов Рида-Соломона. Про нее у компании есть целая статья на Хабре. Эта реализация напоминает RAID-DP или RAID 6, но гибче: данные распределяются по всем дискам в пуле.
Обычно, если вы покупаете полку на 24 диска, два из них становятся запасными и ждут, когда откажет кто-то из соседей. В TATLIN.UNIFIED Gen2 выделенных дисков горячей замены нет. Резервная емкость тонким слоем распределена по всем накопителям. И когда диск выходит из строя, восстановление идет на все оставшиеся диски.
Благодаря этому перестроение после отказа идет быстро: работает схема «много дисков ↔ много дисков», без узкого места в виде одного накопителя. Сейчас доступно два типа пулов.
Пулы прямой адресации поддерживают блочные ресурсы (thin и thick provisioning) и файловые ресурсы, обеспечивают максимальную производительность: данные пишутся на диски линейно и быстро. Бонусом идет синхронная репликация в два географически разнесенных ЦОДа, однако снэпшоты для них не поддерживаются.
Пулы косвенной адресации появились позже. Они виртуализируют адресное пространство через Redirect-on-Write. Здесь доступны снэпшоты, но репликация и файловые ресурсы пока не поддерживаются. Производитель не рекомендует заполнять такие пулы выше 80–90%: при высокой нагрузке это снизит производительность. Ограничение временное: вендор обещает скрестить технологии в будущих релизах (ориентировочно 2026 год, Gen3). Но прямо сейчас, планируя архитектуру на Tatlin, придется четко сегментировать задачи: этот LUN реплицируем в резервный ЦОД, а этот снэпшотим для разработчиков. Впрочем, это стандартная рекомендация для подобных архитектур.
Снэпшоты и клоны
Снэпшоты — моментальные снимки состояния тома. Этот привычный для современных СХД механизм появился в TATLIN.UNIFIED Gen2 не сразу и работает только на пулах косвенной адресации. Используется технология Redirect on Write (RoW), поэтому снэпшоты практически не влияют на производительность, в отличие от Copy-on-Write. О технологии подробно рассказали в статье.
Снэпшот можно создать для отдельного блочного ресурса или для группы ресурсов (группы консистентности). Группа позволяет снимать снэпшоты сразу с нескольких томов одновременно, что очень удобно.
Помимо очевидного сценария с откатом после неудачного обновления, снэпшоты защищают от случайного удаления данных пользователем и непредвиденных изменений, а значит, снижают RPO и RTO в таких ситуациях. Отдельный бонус — защита от шифровальщиков: во-первых, резкий рост размера снэпшота сразу сигнализирует о проблеме, а во-вторых, можно быстро откатиться на «чистую» копию.
Сам снэпшот в TATLIN — это не ресурс (том), поэтому напрямую предоставить к нему доступ хосту нельзя. Зато можно откатить на состояние снэпшота исходный том или родственный ресурс.
Еще из снэпшота можно создать новый блочный ресурс — клон (по факту снэпклон, но это название не фигурирует в документации). Его уже можно предоставить хостам. Берете снэпшот продовой базы и за секунду превращаете его в полноценный LUN с доступом на чтение и запись. Для DevOps это подходит идеально: утром подняли клон, отдали разработчикам на растерзание, а вечером удалили.
Настроить создание и ротацию снэпшотов по расписанию не сложно. Или можно встроить это в другие процессы: создать «одной кнопкой» нужные снэпшоты перед установкой обновлений.
Важный плюс реализации: после использования снэпшоты никуда не исчезают. Для меня это привычное поведение СХД, но на некоторых системах снэпшоты оказываются «одноразовыми». Они либо исчезают после отката, либо не могут использоваться повторно, а в TATLIN все сделано правильно.
Более того, веб-интерфейс дает полезный совет: сначала создать новый снэпшот, а потом откатиться на нужную версию. Такие мелочи показывают, что над СХД работают люди, которые понимают, как и зачем это используется.
Снэпшоты открывают еще одну неочевидную возможность — миграцию между протоколами. Напрямую переключить работающий том с iSCSI на NVMe нельзя. Зато можно сделать снэпшот iSCSI-тома и развернуть из него клон, указав в мастере NVMe как тип экспорта. Сценарий для переезда получается элегантный: снимок → клон по быстрому протоколу → переключение хоста. Данные копировать не нужно, все происходит мгновенно.
Еще одна полезная функция — группы консистентности. Если база данных распределена по нескольким LUN, можно объединить их в группу и делать снэпшоты синхронно. Единственное ограничение: количество снэпшотов на том пока лимитировано.
Создание пулов
При создании пула доступен широкий выбор схем резервирования.
Схема записывается как K+M: K — количество блоков данных в страйпе, M — блоки избыточности (parity). Например, 1+1 — зеркалирование.
Поэтому 4+4 здесь не RAID 10, а четыре порции кодов избыточности. На практике чаще всего нужны три-четыре схемы: 1+1 (зеркало), N+1 (аналог RAID 5), N+2 (аналог RAID 6) и, возможно, N+3 для особых случаев с большими дисками. Triple parity встречается в разных продуктах.
Отдельно отмечу удобное отображение емкости. У нас 30 накопителей по 1,92 ТБ. В TiB это примерно 1,74 TiB × 30 = 52,2 TiB, ровно столько и показывает интерфейс.
Кроме того, в интерфейсе можно переключаться между TB и TiB. Пул 1+1 из восьми накопителей по 1,92 ТБ дает ожидаемые 1,92 × (8−1) / 2 = 6,72 ТБ. Пул 4+1 из двенадцати накопителей — 1,92 × (12−1) × (4/5) = 16,89 ТБ. Цифры не заставляют гадать, куда делась емкость и как округлялись значения. Производитель явно постарался, чтобы всё было понятно сразу. Это приятно, потому что объяснение разницы между TB и TiB на других системах превращается в отдельный квест.
В целом базовая работа с пулами организована удобно.
Файловый доступ
С блочным доступом у TATLIN все хорошо — протоколы работают стабильно. А вот файловый доступ (NAS) пока отстает. Базовый набор есть: NFS версий 3 и 4, SMB версий 2 и 3, можно создавать шары для Windows и Linux, но на этом пока все: ни снэпшотов для файловых ресурсов, ни репликации, ни квот.
Интеграция с Active Directory работает, хотя и с оговорками. В нашем случае система не видела тестовый AD, пока мы не установили сертификаты и не отключили SecureRPC (указание есть в документации — но ее ж надо читать:)). Еще один нюанс: при вводе в домен СХД создает Computer Account, но выбрать целевую OU нельзя. Объект попадает в контейнер по умолчанию. Мелочь, но в организациях с жесткими политиками безопасности это создает проблемы.
Чего еще не хватает:
Дедупликации и компрессии (YADRO обещает добавить компрессию в 3 квартале 2026 года, дедупликацию — в 2027 году);
синхронной репликации;
синхронная репликация работает, но автоматического failover всего сайта, как в полноценном метрокластере пока нет. Переключение требует участия администратора;
автоматически двигать данные между быстрыми SSD и медленными HDD система не умеет. Впрочем, в случае All-Flash хранилищ это уже не важно.
Экосистема
Там, где функционал из «коробки» ограничен, YADRO компенсирует это обвязкой. В ее роли выступают так называемые «Спутники»: готовые шаблоны и плагины, которые помогают встроить СХД в инфраструктуру. Здесь представлены и шаблоны для мониторинга в Zabbix и Prometheus, и плагины для дашбордов Grafana, и Ansible-плейбуки для автоматизации, и CSI-драйверы для Kubernetes. Покупаешь не изолированную «вещь в себе», а компонент, который сразу готов работать в связке с инфраструктурой.
Краш-тесты: дергаем диски и рубим кабели
Тестирование отказоустойчивости мы начали со стандартного сценария отказа путей. Сервер был настроен с резервированием: несколько линков по Fibre Channel и Ethernet к обоим контроллерам.
Здесь стоит объяснить, как обычно устроены СХД среднего класса. Большинство из них используют схему ALUA (Asymmetric Logical Unit Access): у каждого LUN есть «владелец» — контроллер, через который идет прямая запись. Это так называемый Optimized path. Второй контроллер работает в режиме подстраховки: если писать через него, данные все равно пересылаются на контроллер-владелец по внутренней шине, а это дополнительные задержки.
TATLIN.UNIFIED Gen2 построен иначе — это честный симметричный Active-Active. Оба контроллера равноправны, можно писать в один и тот же том через любой порт любого контроллера с одинаковой скоростью. Когерентность кэша система обеспечивает сама.
Тест 1. Отказы интерфейсных портов
Мы запустили нагрузку в 100 000 IOPS и начали по очереди отключать порты на стороне сервера.
Отключаем первый FC-порт. На графиках кратковременный провал, не до нуля, буквально секунда. Драйвер multipath на хосте (DM-MPIO в Linux) зафиксировал потерю пути, записал ошибку в лог ядра и мгновенно перенаправил ввод-вывод на оставшиеся пути. Генератор нагрузки vdbench продолжил работу без ошибок.
Второй порт, третий… В итоге оставили один путь. Система продолжала держать нагрузку. Задержки выросли — очередь запросов на единственный порт стала длиннее, но ввод-вывод не прерывался.
Вердикт: все работает как часы. Симметричная архитектура показывает себя отлично — никаких пауз на перевыборы «мастера», нагрузка просто перераспределяется на оставшиеся пути.
Тест 2. Отказ контроллера
Теперь имитируем отказ контроллера. Физически выдернуть его из шасси TATLIN.UNIFIED Gen2 достаточно сложно, поэтому мы ограничились программной перезагрузкой. Что происходит? GUI мгновенно окрашивается тревожными цветами и предупреждает: система работает без резервирования.
На графиках в момент падения контроллера наблюдается кратковременная просадка ввода-вывода до нуля. Это нормально для большинства систем: выживший контроллер должен принять монопольное владение логическими объектами или понять, что это действительно был сбой. Восстановление заняло несколько секунд. TCP-соединения (если говорить про NVMe/TCP) или FC-сессии не разорвались, а просто повисели на таймауте.
Вердикт: тест пройден. Для хоста это выглядело как кратковременная задержка ввода-вывода, а не потеря устройства. При типичных настройках таймаутов СУБД такая просадка не должна приводить к падению базы.
Тест 3. Отказы питания
К тесту подошли просто — как неопытная уборщица «случайно» вытащили кабель питания из одного БП. В итоге этот БП окрасился красным:
Когда выдернули БП целиком в журнале появилось новое событие. Правда на этот раз с небольшой задержкой. Видимо, опрос датчиков идет интервально.
Вердикт: скучно. И это лучший комплимент для теста по питанию. Ничего не сгорело, ничего не остановилось.
Тест 4. Отказы накопителей
В нашей конфигурации использовался T-RAID со схемой 8+2, где можно одновременно потерять любые два диска без потери данных.
Ак�� первый. Под нагрузкой физически извлекаем SSD-накопитель
В интерфейсе появилось предупреждение. На момент извлечения диска, видимо, произошла кратковременная приостановка ввода-вывода со стороны хоста, но нагрузка быстро восстановилась, только время отклика подросло.
Акт второй. Не дожидаясь завершения ребилда, выдергиваем второй диск
Индикаторы активности дисков вновь на мгновение замирают, на графиках ввода-вывода хоста видна краткая просадка. На главной странице появляется предупреждение о затронутых компонентах, но в журнале новое событие пока не фиксируется.
Пока идет перестроение, СХД продолжает обслуживать наши «скромные» 100K IOPS без сбоев, но задержки ощутимо выросли. До отказов мы видели стабильные ~0,22–0,23 мс, а теперь, во время ребилда, латентность временами превышает 1 мс.
Прогноз времени перестроения пула при отказе второго диска во время перестроения отображается некорректно. Видимо, перестроение двух накопителей формируется как две отдельные задачи. Латентность не возвращается к прежним значениям, и какое-то время прогресс перестроения вообще никак не отображается.
Если подождать, задержка возвращается к норме. Обновляется и прогнозируемое время восстановления, а событие об отказе второго диска появляется в журнале примерно через полчаса после его извлечения.
После краткого периода нормальной работы латентность снова подскакивает: вероятно, система перешла к активной фазе перестроения второго диска. Прогнозируемое время уменьшается, а оставшийся объем работ, наоборот, увеличивается — индикация неоднозначная, но в целом отражает происходящее.
В конце концов пул возвращается в нормальное состояние (хотя резервной емкости под восстановление уже нет), а время отклика стабилизируется на уровне, который был до сбоя.
Полное перестроение двух накопителей и возврат пула к полноценному уровню защиты заняли около 1,5 часов.
Акт третий. Решили вернуть диски на место, вставили в слоты.
Индикаторы загорелись. Тут нас ждал сюрприз, о котором стоит знать всем будущим владельцам TATLIN. Система отказалась принимать диски обратно в пул. Логика YADRO такова: выпавший диск считается ненадежным и просто вернуть его в работу — риск. Его можно заново инициализировать только через консоль сервисного инженера или поддержку — они сбросят флаг ошибки. Для Enterprise это правильный подход: безопасность важнее.
Резюме по краш-тестам
В сухом остатке: за надежность хранения данных можно ставить твердую пятерку. Система ведет себя предсказуемо, а это главное качество для СХД.
Итоговая оценка
По результатам тестов и полученной информации мы оценили СХД по ряду критериев и пришли к следующим оценкам по десятибалльной шкале (где 10 — идеально/великолепно — недостижимый идеал).
Критерий | Что оцениваем | Оценка | Комментарий |
Удобство эксплуатации | Насколько удобно реализовано управление, доступ к ресурсам, общее впечатление | 9 | Все удобно, но есть ряд мелочей, которые можно улучшить. Однако, благодаря хорошей экосистеме СХД зарабатывает дополнительный балл. |
Функциональность | Насколько широкие функции (относительного доступного в отрасли) предоставляются решением | 5 | По отраслевым стандартам набор функций скромный, но почти все, что реализовано не вызывает вопросов. Из новых функций доступен NVMe over TCP. |
Простота администрирования | Насколько интуитивно понятно, не требует отдельного изучения (противоположность порога вхождения) | 9 | Все организовано интуитивно понятно, ломать голову не приходится, документация потребовалась только для интеграции с AD. |
Производительность | Производительность по результатам тестов | 9 | Производительность очень высокая. |
Надежность / стабильность | Отсутствие ошибок, сбоев и стабильность поведения | 8 | Проблем не обнаружено. СХД не получила 10 из 10 лишь из-за отдельных проблем с которыми мы столкнулись в ходе тестов. Однако важно помнить, что мы работали с тестовой версией прошивки. |
|
|
| |
Общая взвешенная оценка | 8 |
Брать или не брать?
По железу и архитектуре TATLIN.UNIFIED Gen2 уверенный A-класс. Эту СХД можно без оговорок ставить в один ряд с мировыми лидерами. По набору функций ПО здесь все пока довольно скромно. Вендор выбрал стратегию «лучше меньше, да лучше». Сырые функции в продакшн не выкатывают, предпочитая стабильность маркетинговым галочкам. И когда речь идет о хранении данных — это, пожалуй, единственно верная стратегия.
Так что переход на эту СХД осознанный выбор в пользу платформы с большим потенциалом. Ищете надежную рабочую лошадку для критичных приложений и готовы мириться с временным отсутствием некоторых «плюшек» ради производительности и поддержки? TATLIN.UNIFIED Gen2 — ваш выбор. Нужен комбайн «все-в-одном» с дедупликацией? Загляните в Roadmap YADRO на 2026 год, там обещают много интересного.
Аргументы «за»:
1. Качественное железо.
Качество сборки, проприетарные платы, интерконнект на 100 Гбит/с RDMA, уникальная компоновка с верхней загрузкой — к железу у нас вопросов нет.
2. Производительность «на вырост».
Мы видели 2,2+ миллиона IOPS из кэша. Видели, как процессоры контроллеров «скучают» (load < 35%) даже под серьезной нагрузкой, а значит, есть куда расти. У системы серьезный запас прочности.
3. NVMe over TCP как киллер-фича.
Пока конкуренты спорят о судьбе Fibre Channel (или ищут, где его достать), YADRO дает работающий NVMe/TCP. Наши тесты показали: на стандартном 25GbE можно получить задержки ниже, чем на классическом 32G Fibre Channel.
4. Предсказуемость и поддержка.
У YADRO огромная инсталляционная база, а их инженеры действительно знают свой продукт.
Аргументы «против»:
1. Функциональный аскетизм (пока).
Нет дедупликации и компрессии. Нет снэпшотов для файловых систем. Жесткое разделение пулов: или репликация, или снэпшоты на выбор. Но справедливости ради вендор этого не скрывает и показывает Roadmap, где фичи запланированы на ближайшее время.
2. Мелкие недоработки софта.
Мы тестировали версию 3.2. И в ней встречались вещи, которые можно улучшить: удобство отображения и фильтрации, корректная работа прогноза времени перестроения для двух последовательных отказов. Ожидаем, что эти шероховатости будут исправлены.
Кому это нужно?
Берите TATLIN.UNIFIED Gen2, если:
вы — КИИ, и вам нужно железо из реестра Минпромторга, которое будет стабильно работать под высокой нагрузкой;
вам нужен мощный блочный доступ. Тяжелые базы данных (Oracle, PostgreSQL, 1С), виртуализация, миллионы IOPS и низкие задержки;
вы готовы к NVMe over TCP и хотите уйти от Fibre Channel;
вам важен SLA. Хотите, чтобы проблемы решали специально обученные люди.
Подождите (или смотрите на другие продукты YADRO), если:
нужно корпоративное файловое хранилище с полным набором возможных функций. Для файлового доступа функционал пока беден;
критична экономия места. Без дедупликации и компрессии хранить бэкапы или однотипные VDI-образы на All-Flash будет дороговато;
необходим Metrocluster с автопереключением. Эта функциональность пока только в планах.
P.S. Вопрос к вам, коллеги: как относитесь к переходу на NVMe over TCP? Готовы доверить прод новому протоколу?
