Восемь лет назад линейка TATLIN начиналась с одной универсальной системы хранения. Сегодня, на мой взгляд, компания YADRO является лидером Российского рынка систем хранения данных. Мне было интересно узнать немного внутренней кухни разработки продуктов, поэтому я поговорил с двумя руководителями разработки YADRO. Антон Казаков отвечает за TATLIN.AFA — флагманскую all-flash систему и Владислав Леонтьев отвечает за TATLIN.BACKUP.
В интервью — где проходит граница между «спроектировано в России» и «собрано в России», почему сильных системных инженеров не стало больше, хотя кандидатов на рынке прибавилось, и как продукт проходит путь от первого инженерного образца до отгрузки. Отдельно обсудили тестирование и миграцию с зарубежных систем, а также ближайшие планы: компрессию, репликацию и NVMe/RoCEv2 в TATLIN.AFA, WORM и режим «Бункер» в TATLIN.BACKUP.
Общие вопросы
Насколько реально сегодня говорить о «полностью отечественном» железе — где проходит честная граница между «спроектировано в РФ» и «собрано в РФ из импортных компонентов»?
Такую границу в современном мире в принципе сложно провести: ни одна страна не производит всю электронную компонентную базу полностью самостоятельно. Корректнее смотреть не на происхождение каждого отдельного компонента, а на то, где создается сам продукт и где сосредоточены ключевые компетенции.
Когда мы говорим об отечественном оборудовании YADRO, для нас принципиально, что продукт спроектирован и произведен российской инженерной командой. В России разрабатываются его архитектура, аппаратная платформа и программное обеспечение, здесь же находятся производство и контроль качества. Значительная часть производственной цепочки и компонентов также локализована в России — например, печать плат. При этом часть электронной компонентной базы сегодня остается импортной — это объективная реальность отрасли.
У нас нет задачи заменить импортный компонент российским ради самой замены. Когда на рынке появляется отечественное решение, мы оцениваем его по тем же критериям, что и любое другое: характеристики, качество, надежность и возможность серийного производства. Если компонент соответствует этим требованиям, мы готовы использовать его в своих продуктах и становиться для производителя якорным заказчиком, формируя реальный промышленный спрос.
Если речь идет о сложных компонентах, производство которых в России еще только формируется, один из рабочих подходов — напрямую участвовать в создании такой технологической и производственной базы. Например, совсем недавно на Восточном экономическом форуме ИКС Холдинг, материнская компания YADRO, подписал соглашение о создании в Приморском крае производственного комплекса сложных полупроводников с инвестициями свыше 35 млрд рублей. Одно из направлений — производство СВЧ-компонентов, которые будут использоваться в телеком-оборудовании YADRO. Так мы постепенно расширяем собственные компетенции — от производства конечного оборудования к разработке критически важных компонентов, от которых зависят его характеристики и возможности.
Как решается кадровый вопрос — где берёте инженеров под разработку СХД (свои R&D-школы, переманивание с рынка, вузовские программы), и в чём главный дефицит компетенций? Как изменился этот подход в последние пару, когда рынок IT начал переживать кризис?
Инженеров мы ищем по нескольким каналам одновременно. Это карьерные площадки и профессиональные сообщества, где работаем как с входящими откликами, так и с прямым поиском, отраслевые митапы и конференции, реферальная программа. Отдельное направление — работа со студентами и вузами: совместные проекты, стажировки, образовательные программы и открытые курсы позволяют знакомиться с будущими инженерами еще до их выхода на рынок труда.
Главный дефицит — специалисты с релевантным опытом разработки именно СХД и глубоким пониманием того, как такие системы устроены изнутри. Например, инженеров с опытом разработки в kernel-space на рынке в принципе немного: даже сильному C-разработчику, который раньше работал преимущественно в user-space, требуется время, чтобы перейти к работе на уровне ядра системы, где ошибка может повлиять на работу всего оборудования, а требования к надежности и отладке заметно выше. Поэтому для нас особенно ценны специалисты, которые уже решали системные задачи сопоставимого уровня сложности и умеют глубоко разбираться в работе системы целиком.
За последние пару лет кандидатов на ИТ-рынке действительно стало больше, и со стороны может показаться, что нанимать стало проще. Во многом это следствие того, что компании оптимизируют расходы и пересматривают эффективность команд: на рынок чаще выходят специалисты, с которыми работодатели готовы расстаться, тогда как наиболее сильных инженеров, наоборот, стараются удерживать. Такие специалисты редко находятся в активном поиске и сами на фоне общей нестабильности осторожнее относятся к смене работы. Нередко они получают контроффер от текущего работодателя и в итоге остаются на прежнем месте. В результате общий объем кандидатов вырос, но доступных специалистов нужного нам уровня больше практически не стало, а хантинг таких инженеров скорее стал сложнее.
TATLIN.AFA: Антон Казаков
Архитектура и инженерные решения
Какие компоненты платформы разрабатываются полностью в России, а какие — заимствованные или адаптированные модули (контроллеры, коммутационные платы, прошивки)?
Механический конструктив, все печатные платы (PCB) и на их основе собранные электронные модули (PCBA) — контроллеры, райзеры, интерпозеры, бэкплейны, специализированные сетевые платы, прошивки для их FPGA, микропрограммное обеспечение BIOS и BMC – все это разрабатывается в YADRO своим собственным штатом архитекторов, конструкторов, схемотехников, топологов и разработчиков низкоуровневого ПО для этого «железа». Пока еще заимствуются такие компоненты, как процессоры (в TATLIN.AFA используем Intel Xeon Gen 5), оперативную память DDR5, интерфейсные адаптеры Ethernet и Fibre Channel и накопители.
Чем архитектура AFA принципиально отличается от гибридных СХД — почему было решено делать выделенную all-flash линейку, а не «допилить» универсальную платформу?
Здесь можно отметить два фактора. Во-первых, все вендоры СХД прошли по пути, начинающегося от «одного продукта для любых задач» до разного масштаба портфолио продуктов, ориентированных на решение определенного круга задач заказчика. YADRO не исключение, 8 лет назад мы начали историю TATLIN с единственного продукта TATLIN.UNIFIED, представляющего собой унифицированную СХД для широкого круга задач, а сейчас линейка TATLIN насчитывает более десятка продуктов разного масштаба и предназначения. Во-вторых, в прошлом году YADRO выпустила первый продукт TATLIN.AFA на новейшей аппаратной платформе TATLIN.X – современной, модульной и гибкой в применении. Таким образом, вместо «допиливания» объективно устаревшей гибридной СХД мы пришли к линейке на единой аппаратной платформе, в которой будут продукты с потребительскими характеристиками по разным решаемым задачам. TATLIN.AFA занимает флагманское место и применяется там, где от СХД требуется максимально быстрый отклик при семизначном порядке количества операций ввода-вывода. TATLIN.AFA спроектирована сбалансировано с точки зрения движения данных снаружи внутрь и обратно, не содержит компромиссов и элементов, которые даже гипотетически могут принести лишнюю задержку. Для работы с оперативной памятью выбрана конфигурация с оптимальным заполнением слотов, high-speed интерфейсы разведены на платах без использования кабелей, все слоты I/O PCIe gen5 подключены 16-канальными соединениями к процессорам без переподписки и промежуточных PCIe-коммутаторов, полностью отсутствует SCSI в каком-либо виде, система принимает только NVMe-накопители, в том числе и в полках расширения, которые подключаются по двум каналам RDMA 200G каждая, без коммутатора. Алгоритмы компрессии данных вынесены на специализированные ускорители в процессорах. Протоколы доступа к данным только блочные, ставка сделана на NVMe/TCP и NVMe/RoCEv2, хотя для совместимости присутствуют и традиционные FC и iSCSI. Гибридные СХД TATLIN решают несколько другие задачи, и в следующем году можно ожидать новые модели, построенные на базе TATLIN.X, в том числе и обновленный TATLIN.UNIFIED.
Как устроено взаимодействие с NVMe-накопителями на уровне контроллера — свой драйверный стек или адаптация открытых решений?
СХД на базе NVMe-накопителей YADRO начала выпускать первой на отечественном рынке еще 7 лет назад. TATLIN.OS, которую YADRO разрабатывает на протяжении всей истории TATLIN, взаимодействует с накопителями классическим образом через их собственный контроллер, используя максимум его возможностей для обеспечения сохранности данных в наших СХД. Так, например, накопители имеют форматирование с индустриальным стандартом защиты данных контрольными суммами T10-DIF, анализ данных S.M.A.R.T, специфичный flash-накопителям, помогает отслеживать «здоровье» каждого накопителя и оперативно реагировать на отклонения.
Производство
Где физически происходит сборка — свои мощности или контрактное производство? Какая доля компонентов отечественная, какая импортная, и как обходите ограничения на поставки?
Оборудование YADRO производится на собственных площадках.
Если говорить о соотношении российских и импортных компонентов, одной универсальной цифры здесь нет: она различается от продукта к продукту и меняется по мере развития российской компонентной базы. При этом значительная часть производственных операций, а также ряд компонентов и конструктивных элементов уже локализованы в России.
Ограничения на поставки — часть рыночной реальности, с которой сегодня работает вся отрасль. В сложных ситуациях мы перестраиваем логистику, находим доступные каналы поставок и продолжаем выпускать оборудование для наших заказчиков. Для нас здесь важен прежде всего результат — стабильное производство и выполнение обязательств перед клиентами.
Как выглядит цикл от прототипа до серийного изделия?
Это как захватывающий и увлекательный сериал, где сезон может закончиться и не так позитивно, как все думали, но с неизменной победой добра в финале. Вначале появляется первый инженерный образец Rev.A (фаза EVT, engineering validation test) в штучных количествах, для целей валидации базовой архитектуры продукта – к нему имеют доступ разработчики аппаратной платформы и микропрограммного ПО, а также главные инженеры высокоуровневого ПО, в нашем случае TATLIN.OS. Производится серия тестов в HW QA (механическая совместимость, термовалидация, устойчивость проходимости сигналов, запуск BIOS, BMC и базовой ОС для проверки работоспособности периферии). Пожалуй, это самая волнительная фаза – первая сборка продукта, который до этого существовал только в чертежах и моделях. После сбора обратной связи по Rev.A формируется список доработок для Rev.B (фаза DVT, development validation test). Ее получают в работу уже все подразделение R&D и QA продукта, технологи на FAB-е для начала постановки на производство серийного продукта и отладки производственных процедур сборки и тестирования. Также в фазе DVT происходит знакомство сервисного подразделения с аппаратной платформой, они тоже являются ее пользователями, и их обратная связь не менее важна для успеха продукта в поле. Далее следует фаза PVT, или Product Validation test, с новой ревизией или нет – каждый раз по-разному. В этой фазе проверяются все сценарии, присущие серийному продукту – инженерный запуск производственной среды, выпуск релиза ПО TATLIN и всех сопутствующих наборов микрокодов компонент, разработаны сервисные и инсталляционные процедуры, готовы упаковочные материалы. Продуктовая команда получает свои демо-образцы для показа ключевым заказчикам и проведения маркетинговых мероприятий. Далее – первая отгрузка, и начало полевой эксплуатации!
Тестирование и надёжность
Как тестируется отказоустойчивость — есть ли лаборатория для «полевых» испытаний (вибрация, температура, наработка на отказ)?
Контроль качества разработки тестируется в нескольких командах QA. У Hardware QA в ведении тестирование механики на прочность, термо- и вибро испытания на специализированном оборудовании (термокамера, виброустановка, даже «Газель» на маршруте порядка 1000 км между пунктами погрузки/разгрузки), различные сигнальные валидации периферии, энергопотребление в разных конфигурациях. У Software QA три стадии тестирования – внутреннее по модулям ПО, интеграционное по релизу и приемочное по продукту в целом, включая длинные запуски на несколько недель, сценарии сервисных замен компонент, потерю электропитания, обновления ПО под нагрузкой и тд. На производстве также есть три фазы тестирования – отдельных PCBA, собранной платформы, где контроллеры СХД тестируются как отдельные «компьютеры», и финальный тест собранного кластера TATLIN в той конфигурации, которая отгружается заказчику. ОТК присутствует на всех трех фазах и не допускает прохождение в следующую при наличии отклонений.
Какие нагрузочные тесты проходит система перед релизом — есть ли эталонные профили нагрузки (OLTP, аналитика, виртуализация)?
Мы собираем не только эталонные нагрузки для проверки релиза на производительность. Мы стараемся собрать с заказчиков как можно больше сценариев ПМИ, которые они используют при тестировании продукта на соответствие их требованиям. В них входят как функциональные тесты, так и тестирование отказов под нагрузкой и достижение различных показателей производительности на разных профилях. В результате рождается большое кумулятивное ПМИ, заложенное в тест-планы приемочного QA и регрессионные тесты PERF-команды. Таким образом формируется доказанная уверенность в успехе продукта в поле.
Как проверяется совместимость с российским ПО и гипервизорами (сертификация, реестр Минцифры)?
У нас двусторонняя работа с экосистемным ПО – во-первых, проводится автоматическое и ручное тестирование в QA на базовую совместимость продукта с различными ОС при подключении на разных протоколах доступа. Список наименований и версий ОС постоянно обновляется – убираются устаревшие или малоиспользуемые, добавляются новые, и конечно последнее время очень много добавляется различных вариантов отечественных ОС и платформ виртуализации. Результатом этой работы является матрица совместимости, доступная в документации на продукт. Во-вторых, наш отдел по связям с ISV проводит совместные сертификации продукта YADRO и наиболее востребованных на рынке решений – операционных систем, гипервизоров, систем резервного копирования и тд, в которых участвуют оба вендора. В результате появляется совместный сертификат, в котором оба вендора заявляют о совместимости своих продуктов между собой. Это уникальный на отечественном рынке диалог, который направлен на углубление интеграции продуктов YADRO и отечественных ISV и освобождение заказчиков от неуверенности в «пограничных» сценариях, предоставляя им подтверждение взаимной поддержки взаимодействия продуктов.
При этом для заказчиков важна не только проверенная совместимость компонентов ИТ-стека, но и подтвержденный статус самого оборудования. Оборудование YADRO проходит процедуру включения в Единый реестр российской радиоэлектронной продукции Минпромторга. Для заказчиков это подтверждение российского происхождения продукции и возможность использовать такие решения в проектах, где предъявляются повышенные требования к ИТ-инфраструктуре, в том числе на значимых объектах критической информационной инфраструктуры.
Были ли случаи, когда баг находили уже у заказчика, и как перестраивали процесс тестирования после этого?
Отдел QA проводит грандиозную работу по расширению тестовой стратегии, основываясь на реальных сценариях использования продукта в поле и минимизации числа подобных случаев. Вместе с тем, с увеличением инсталляционной базы СХД TATLIN до тысяч единиц, причем каждая — в своем уникальном окружении (протоколы, нагрузки), новые сценарии продолжают появляться. Если баг выявлен в поле, его обрабатывает отдельная команда L4, которая их исправляют, а заодно работает с QA для выявления причины невыявления их тестами. В результате либо дорабатывается существующий тест, либо добавляется новый в тестовую стратегию.
Эксплуатация и обратная связь
Какие проблемы чаще всего возникают у заказчиков при миграции с зарубежных all-flash систем на TATLIN.AFA — на уровне драйверов, производительности, привычных инструментов управления?
Прежде всего надо сказать, что мы заранее проводим большую работу по предотвращению такого рода проблем. В QA есть отдел автоматических и ручных тестов совместимости ОС и гипервизоров, которые использует отечественный рынок. Недавно эти тесты пополнились новой серией проверки их совместимости по протоколам NVMeoF. Кроме того, если есть осведомленность о возможностях того или иного решения, которое подбирается на замену существующего, результаты проведенного тестирования, ответственность вендора за совместимость, то тоже проблемы как таковой не происходит. Для повышения осведомленности мы проводим массу мероприятий с заказчиками, на которых как технические консультанты, так и продуктовая команда, и даже R&D рассказывают о продукте и о том, как он соотносится со своими одноклассниками, в том числе и зарубежными.
Из того, что Вы назвали, производительность, пожалуй, практически не является камнем преткновения, мы еще на прошлом поколении СХД достигали паритета с одним из самых распространенных и уважаемых рынком вендоров, а сейчас с TATLIN.AFA и превосходим его в разы, целимся в соревнование с более старшими моделями. Многим не хватает возможностей сокращения объемов хранимых данных, но эту потребность мы начнем закрывать уже осенью, когда в продукте появится компрессия. Также есть большой запрос на DR-технологии, такие как различные виды репликаций и метро-кластеризация, этот трек тоже у нас в работе, и асинхронную репликацию между моделями семейства мы начнем предлагать тоже этой осенью.
Как собираете обратную связь от эксплуатации — есть ли телеметрия с полевых систем, которая влияет на приоритизацию доработок?
Есть телеметрия в виде Call Home, который заказчик может включить на системе и отправлять автоматические отчеты о состоянии систем, а сервис – сам открывать заявки по выявленным отклонениям. Если говорить про приоритизацию, то сами по себе доработки бывают разные – это могут быть исправления найденных багов и добавление функциональности. Первую часть проводят в L4, приоритет ставится в зависимости от оказываемого влияния и распространения найденного дефекта. Предложения для развития функционала мы собираем на сервисном портале «Идеи пользователей», где приоритетом могут управлять сами пользователи путем голосования за ту или иную идею.
Насколько быстро удаётся довести исправление от репорта заказчика до патча прошивки — какой цикл поддержки в среднем?
Выпуск hotfix в среднем занимает около 1-4 недель.
Какие метрики эксплуатации (задержки, IOPS, износ флеш-памяти) заказчики просят чаще всего показать «вживую», и как вы на это отвечаете инструментами мониторинга?
Все то же самое, что и обычно – данные о здоровье СХД, изменения ее состояния вследствие внешних и внутренних факторов, производительность по ресурсам в терминах IOPS, Bandwidth, Latency. В нашем сопутствующем интеграционном наборе TATLIN Satellites мы предоставляем инструментарий для взаимодействия с распространенными системами мониторингами, такими как Zabbix и Graphana, можно взять готовый виртуальный апплайенс с готовыми дашбордами для мониторинга нескольких СХД одновременно.
Перспективы
Куда движется линейка — NVMe-oF, storage-class memory, работа с AI/ML-нагрузками?
Мы активно работаем с заказчиками, чтобы выявить новые потребности в задачах обработки данных на перспективе 4-5 лет – какие из имеющихся методологий будут еще актуальны, какие нагрузку сойдут и что придет совершенного нового. Конечно, история с экспоненциальным ростом инфраструктур для AI/ML влияет на эти тренды, и мы привлекаем к разговору новых участников – и слышим удивительные вещи.
NVMeoF мы запустили в конце прошлого года на отечественный рынок как новый тренд, и уже сейчас видим результаты – заказчики активно его тестируют, запрашивают поддержку новых протоколов доступа у ISV. Мы продолжаем его развивать, и уже осенью предложим рынку NVMe/RoCEv2 в TATLIN.AFA. В целом, NVMeoF звучит как основа высокоскоростного доступа к данным, но природа самих данных и доступа к ним меняется, появляются новые требования к надежности их хранения – и что удивительно, в некоторых случаях эти требования ослабляются, а не ужесточаются. Это открывает новые горизонты для технологического развития – отказ от привычного legacy, которое снижает скорость обработки, ставка на скорости доступа в сотнях гигабайт в секунду и петабайтные объемы. Здесь уместно говорить об использовании CXL, SCM, DPU и Ultra Ethernet. Вместе с тем, не забываем и про развитие функциональности для классических инфраструктур – добавление функционалов из области DR и экономики хранения в ближайшей дорожной карте, а также выпуск новых продуктов на базе TATLIN.X.
Как вы видите конкуренцию с зарубежными all-flash системами с точки зрения производительности и TCO?
Выше уже приводили примеры по поводу конкуренции с точки зрения производительности, успех достигается и заказчики уже в курсе. ТСО в текущих реалиях нужно считать более широким методом, учитывая риски эксплуатации без официальной поддержка вендора – но работа в самом продукте, несомненно, продолжается в направлении ее снижения, мы оперативно реагируем на рыночные вызовы, такие как многократное подорожание ключевых компонент All Flash СХД – накопители и оперативной памяти. В нашей статье мы рассказываем, как оперативно выпустили «антикризисный» вариант TATLIN.AFA со сниженным объемом кэш-памяти, не понизив ее потребительские характеристики (объем, лимиты, производительность) – в сложившихся условиях мы меняем подходы в R&D к планированию бюджетов RAM на программные модули. Кроме этого, выводим функционал компрессии данных в разных вариантах лицензирования, включая бесплатный – чтобы наша продукция оставалась конкурентноспособной на рынке и доступной к закупке нашими заказчиками.
TATLIN.BACKUP: Владислав Леонтьев
Архитектура и продуктовая логика
Чем логика системы резервного копирования принципиально отличается от «просто СХД с большим объёмом» — какие специфические механизмы дедупликации и компрессии реализованы?
Когда мы подходим к задаче хранения резервных копий, мы бы хотели получить следующее: Первое и основное, чтобы из этих копий можно было восстановиться. Причем копии, как правило, нужны когда какой-то сбой уже произошел, и в такой момент они становятся наиболее ценными. Поэтому важным параметром хранилища для резервных копий, является её защищённость и неизменяемость. Под такие параметры отлично подходят Объектные хранилища, Ленты и Специализированные СХД Tatlin.Backup.
Ключевой особенностью именно Tatlin.Backup и решений подобно класса — является экономика хранения. Резервные копии, выполняются регулярно, при этом данные от копии к копии меняются не значительно.
Благодаря встроенным механизмам дедупликации мы записываем на систему только уникальные блоки данных, при этом не записывая повторяющиеся. Это позволяет достигать на продуктивных данных коэффициента дедупликации и сжатия 6-12 к 1. Получается, что использование такое системы, в пересчете на эффективный терабайт в несколько раз эффективнее альтернативных методов хранения.
Как устроено взаимодействие с ПО резервного копирования (аналоги Veeam, отечественные бэкап-решения) — через какие протоколы и API?
СХД Tatlin.Backup работает по стандартным файловым протоколам: NFS, CIFS, SMB, а также по проприетарному, написанному нашей командой, протоколу TBOOST.
Поскольку любая ПО СРК работает с резервными копиями именно как с файлами, это позволяет системе работать в связке с любым ПО СРК: VEEAM, Veritas, Commvault, Vinchin. С отечественными ПО СРК: RuBackup, Кибербэкап, Береста. У нас доступны более глубокие интеграции, поскольку мы с коллегами ведем совместную разработку. Например, коллеги из Бересты добавили на свою сторону библиотеку TBOOST SDK как нативный протокол передачи данных. Это позволило повысить эффективность и производительность протокола. Коллеги из RuBackup и Кибербэкап вносят эту библиотеку в ближайших релизах.
Есть ли собственные механизмы immutability и защиты (WORM, снапшоты с защитой от удаления, air-gap)?
Разумеется, это отсылает нас к первому вопросу, где мы обсуждали особенности хранилищ для резервных копий. Резервная копия должна быть неизменяемой. В Tatlin.Backup реализованы механизмы снапшотов, которые фиксируют состояние файловой системы на какой-то момент времени и позволяют в любой момент это состояние прочитать. Эти Снапшоты бывают нескольких уровней защищённости, и в максимальном уровне, их невозможно удалить без привлечения сервисного инженера ЯДРО. Это сделано специально, в качестве максимального уровня защиты данных.
В релизе 1.6, который планируется в конце текущего года выйдет функционал WORM, который будет работать по такому же принципу, как снапшоты, только с гранулярностью на уровне файлов, а не на уровне файловой системы. Также появится режим «Бункер», который позволит организовать безопасную репликацию копий на удалённую площадку. Что будет альтернативой физического Air-Gap.
Производство и компонентная база
Насколько отличается требование к «железу» для бэкап-системы от AFA — почему для холодного хранения выбираются другие диски и контроллеры?
AFA – это система созданная для очень высоконагруженных систем, для которых требуется минимальные задержки и максимальные показатели IOPS. Такая высокая производительность систем отлично подходит для Баз данных, например, но скорее всего будет излишня для хранилища резервных копий. При использовании Tatlin.Backup мы зачастую упираемся в то, что узким местом является не производительность системы, а сеть/клиент-серверы/медиа-серверы или другие компоненты. Резервное копирование очень комплексный процесс.
Для Хранилищ резервных копий, больше важны большие объемы хранений, и пропуская способность.
Конечно, можно было бы сделать Tatlin.Backup на аппаратной платформе от AFA, но в большинстве случаев это было бы излишне с точки зрения производительности, и при этом очень дорого сравнивая с альтернативными решениями.
Как балансируете стоимость и ёмкость — какая экономика лежит в основе выбора HDD/SSD-тиринга?
В Tatlin.Backup нет тиринга как такового. Используются разные диски, но они используются для разных целей. При записи файла, он разбивается на блоки переменной длины. Сами блоки записываются и хранятся на HDD дисках. На NVMe дисках находятся метаданные этих блоков, чтобы из них можно было собрать файл обратно. Обращение к метаданным необходимо чаще, поэтому и требования к дискам метапула с точки зрения скоростей более строгие.
Тестирование
Как тестируется скорость восстановления (RTO) в разных сценариях — есть ли лаборатория для симуляции катастроф и аварийного восстановления?
С каждым из перечисленных отечественных вендором ПО СРК, у нас есть совместные стенды разработки, где мы готовим интеграции и тестируем различные сценарии работы. Помимо этого, у нас есть несколько команд QA, которые на регулярной основе занимаются не только тестированием самой железки, но и тестированием сценариев копирования и восстановления. Тем не менее, Резервное копирование, это очень сложный и комплексный процесс, зачастую данные полученные в лаборатории могут отличаться от данных в продуктивной среде конкретного заказчика.
Так происходит из-за того что в процессе участвует слишком большое кол-во участников: Сервер источник, со своей ОС, поверх это ОС, стоит софт Базы Данных, рядом клиент резервного копирования, потом медиасервер резервного копирования, между всем этим сети, возможно виртуализация и только в конце всей этой цепочки находится целевое хранилище. Поэтому, чтобы получить точные данные, мы привозим СХД на площадку к заказчику и тестируем его сценарии в его окружении.
Как проверяется долговременная сохранность данных (bit rot, деградация носителей при долгом хранении, etc.)?
- Сквозная проверка целостности (End-to-End): Контрольные суммы данных проверяются на каждом этапе жизненного цикла.
- Технология T10 PI: На уровне дискового массива обеспечивает защиту от скрытых ошибок чтения/записи (Bit Rot).
- Фоновое сканирование: Система в фоновом режиме проверяет целостность данных на дисках и при обнаружении повреждений использует информацию четности (из T-RAID) для автоматического восстановления.
- Copy-on-Write: Гарантирует, что старые данные не будут перезаписаны при изменении, что защищает от повреждения при сбоях во время записи
Какие нагрузочные тесты проводятся на дедупликацию и компрессию — на каких датасетах: синтетика или реальные данные заказчиков?
Как я рассказывал ранее, проводятся все тесты, которые мы смогли придумать) Тесты на совместных стендах с ПО СРК, тесты внутренней перфоманс команды, тесты на площадках у заказчиков. Также у нас уже есть немалая инсталляционная база, которая работает в продуктивных средах, и которая тоже позволяет накопить опыт и потестировать СХД в разных условиях. На внутренних тестах, преимущественно используются синтетические данные. Однако, бывают тесты на наших мощностях, когда заказчик предоставляет нам не критичные для него продуктивные данные.
Эксплуатация и обратная связь
Какие проблемы чаще всего возникают у заказчиков при миграции с зарубежных бэкап-решений на TATLIN.BACKUP?
Если мы говорим, об импортозамещении СХД зарубежных производителей такого же класса, например DataDomain или StorOnce, основной сложностью становится некоторое неудобство, вызванное отсутствием интеграций с этими ПО СРК. Когда пользователь привык из одной консоли управлять и хранилищем и ПО СРК, это удобнее, чем администрировать СХД отдельно, а ПО СРК отдельно. Пользователи, которые использовали хранилище просто как эффективное хранилище, пишущее по NFS, скорее всего не заметят разницы, но те кто использует более глубокий функционал, например Снапшоты или репликацию, потратят некоторое время на администрирование. В целом, тут хотелось бы отметить, что Tatlin.Backup это СХД, которое приезжает как готовое к работе устройство, которое практически не требует настроек. Включил питание, включил сеть, создал точку монтирования и стартуешь РК.
Отдельным пунктом при переезде с других систем, является отсутствие у Tatlin.Backup FC-протокола. И в России, и в мире ярко выраженный тренд на уход от FC в сторону Ethernet, поэтому мы посчитали наличие только Ethernet достаточным. Тем не менее есть ряд заказчиков, у которых Бэкап сеть это отдельная сеть, построенная на FC. Это тоже, вполне решаемая проблема, если медиа-серверы готовы принимать FC и отдавать Ethernet, но она также сопряжена с рядом дополнительных действий.
Как собираете обратную связь от эксплуатации — есть ли телеметрия с полевых систем, которая влияет на roadmap?
В Tatlin.Backup нет механизма Call Home для сбора такой информации, и появится ли, пока вопрос. На мой взгляд СХД для резернвых копий, вообще не должно иметь доступ куда-то кроме локальной сети.
У нас несколько каналов общения – это встречи в предверии и по итогам пилотных проектов, совместные мероприятия и техническая поддержка. Мои контакты также в отрытом доступе, поэтому со многими пользователями мы общаемся напрямую. Мы формируем Дорожную карту ориентируясь на потребности наших пользователей, поэтому любой запрос на доработку обязательно попадает к нам на анализ, оценку и в Дорожную карту. Так в Tatlin.Backup была добавлена интеграция со службами каталогов AD и Ред АДМ. Некоторые метрики в WEB UI и многое другое.
Перспективы
Куда движется линейка — в сторону встроенной защиты от шифровальщиков «из коробки», интеграции с облачными хранилищами (гибридные сценарии) или углубления функций дедупликации?
Глобальный тренд текущего года, это наивысшая безопасность хранения резервных копий. Сейчас очень высок риск физического уничтожения ЦОДов, поэтому все ИТ-инфраструктуры требуют появления резервных площадок, как правило нескольких, между которыми нужно оперативно отправлять данные, при это делая это через air-gap, чтобы хакерская атака одной площадки не влияла на другие. Данные эти должны быть неизменяемы, при этом из них необходимо быстро восстановиться в случае необходимости.
Поэтому в последнем релизе мы выпустили функционал репликации, между системами. А в последующем релизе планируем выпустить режим «Бункер», который станет встроенным Air-gap.
Гибридные сценарии и облака: Мы активно работаем над интеграцией с облачными платформами. У нас уже есть партнерства и интеграция с объектным хранилищем TATLIN.OBJECT по протоколу S3 в связке с RuBackup. Это позволяет строить гибридные и многоуровневые схемы хранения, где «горячие» копии хранятся на TATLIN.BACKUP, а долгосрочный архив — в объектном хранилище или облаке.
Углубление дедупликации: Работа над эффективностью никогда не останавливается. Например, мы уже рассказывали, как нам удалось сократить объем метаданных на 83% с помощью Леса Меркла, что напрямую влияет на скорость и масштабируемость. И подобные оптимизации будут продолжаться.
Также отдельным треком мы регулярно ведем работу над ускорением операций восстановления с СХД.
Планируется ли поддержка объектного хранения (S3-совместимость) как основного протокола для бэкапов, помимо блочного и файлового доступа?
Мы вот-вот выпустим интеграцию Tatlin.Backup с продуктом Tatlin.Object, которая позволит бэкапить S3 с использованием протокола TBOOST. Делать S3 протокол доступа именно для Tatlin.Backup или нет, мы ещё не решили. Мы находимся в стадии сбора потребности в таком функционале.
Как вы видите конкуренцию с зарубежными решениями резервного копирования — в чём сегодня главный разрыв и как его планируете сокращать?
Мы уже сравнялись с мировыми лидерами DD/StorOnce по ключевым показателям: дедупликация, сжатие, протоколы (TBOOST / DDBOOST), производительность и надежность. Основное отличие нашего решения от зарубежных это уровень сервиса и экосистема.
Как сокращаем разрыв:
- Экосистема: Активно интегрируемся с лидерами российского рынка СРК (RuBackup, Кибер Бэкап). Это закрывает главный пробел в «готовых» решениях.
- Скорость развития: Гибкость российской компании позволяет нам быстрее реагировать на запросы клиентов и добавлять фичи, которых нет у западных вендоров (например, специфические требования для госсектора).
- Сервис и поддержка: Предоставляем сервис уровня 24 часа Фикстайм, в условиях санкций и серых поставок зарубежного оборудования, это становится нашим ключевым конкурентным преимуществом.