Сергей Харитоненко: Хранение данных в эпоху кризиса

Как родилась идея ПАКа для S3? Какие решения ему предшествовали?

Изначально команда наших разработчиков принимала участие в реализации проектов ВГТРК и решала задачи, связанные с большими объемами данных. Поскольку для долговременного хранения медиаактивов все крупные и большинство средних телевизионных компаний традиционно использовали ленточные библиотеки и RAID СХД, то возникла идея реализовать функционал ленточных библиотек, но уже с применением жестких дисков.

Эта идея и стала отправной точкой для начала разработки программного обеспечения, которое впоследствии получило название «Ивановна» и СХД, которую мы назвали «Дататека».

Реализовав эти проекты, мы решили многие задачи в медийной отрасли и продолжаем активное сотрудничество с крупными телерадиокомпаниями.

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

Сейчас мы занимаемся внедрением наших разработок в медиаотрасли там, где их еще нет, и масштабируем там, где они уже интенсивно применяются.

Следующий этап нашего развития заключается в том, что мы выводим эти решения за пределы медиаотрасли и начинаем интегрировать и адаптировать их под задачи традиционного ИT-сегмента.

Такова наша основная цель и задача на данном этапе.

Насколько я понял, ваше решение состоит из аппаратной части «Дататека» и ПО «Ивановна». Вместе это СХД для больших объемов данных, так? Для каких сценариев предназначен подобный комплекс? Для быстрого доступа? Или это архив, к которому редко обращаются?

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

Кому-то необходимо именно архивное хранение — мы строим инфраструктуру с упором на архив.

Кому-то нужно интенсивно работать, например, с большим количеством мелких файлов — настраиваем инфраструктуру под это требование заказчика. В каких-то проектах предпочтительна комбинация длительного хранения и активного использования данных.

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

Я упомянул только базовые. Основное — мы не ограничены жесткими рамками, как у ленточных библиотек или RAID-массивов, мы идем от задач заказчика и необходимого для него функционала. Все в наших руках.

О комплаенсе. Для банков и финансово-кредитных организаций есть требования к хранению данных. Видите ли вы такие компании в числе своих пользователей?

Именно так. Когда я начал рассматривать сценарии применения, то в иерархии поставил выше страховые компании, потом медицину, потом банкинг и дальше по списку. На практике самый большой интерес сейчас проявляют банки. Вторыми идут страховые компании. Третий сектор по рейтингу интереса — медицина.

Все три типа объединяются по принципу большого числа клиентов и связанных с ними данных. Огромное количество клиентов — тысячи, десятки тысяч. Информация о них должна храниться достаточно долго, и при этом никто не знает, в какой момент понадобится ее быстро извлечь. Например, страховая компания создает объект, наполняет его договорами, нормативной базой. Эта информация может лежать год-два-три до наступления страхового случая, и вот тогда она должна быть доставлена пользователю практически мгновенно. И дальше этот объект пополняется — фото, видеофиксацией, справками. То есть информация должна храниться долго, но когда она понадобится — предоставляться очень быстро и быть расширяемой. И банки, и страховые, и медицина работают примерно по одному алгоритму: десятки и сотни тысяч клиентов, каждый из которых может быть представлен в виде объекта.

Расскажите, где еще применяются такие хранилища? Какие есть пилотные проекты? Какие ниши считаете ключевыми?

Есть еще направление — геодезия, картография, проектно-конструкторские компании. Создается проект, например, здания. Данные по проекту представляются в виде объекта или нескольких объектов: один под технологии, другой под проектную документацию, третий под нормативные документы. Одновременно работает большое количество людей, получающих доступ к этим данным. Потом проект реализуется, и вся документация должна храниться столько, сколько живет объект — 10, 20, 30 лет. В один момент идет активная работа, потом данные по объекту уходят в холодное хранение, но если что-то происходит — они тут же извлекаются и переводятся в активное состояние.

Также есть структуры, отвечающие за безопасность, для которых крайне важен вопрос сохранности данных, при любых катаклизмах. Там должен быть реализован принцип «3-2-1». Кроме ленточных библиотек, на сегодня этот принцип физически не может реализовать никто: две копии данных должны храниться на двух разных активных устройствах, третья, условно говоря, «на полке». И для дополнительной сохранности данные должны быть защищены использованием принципа Air Gap, который сейчас у всех на слуху.

Мы можем это делать на совершенно другом, современном технологическом уровне.

У нас есть опция специальных боксов для отчуждаемых дисков. Можно «на горячую» вынуть жесткие диски прямо из работающей системы, положить в специальные боксы, закрыть на ключ, оставить в стойке или унести в сейф, можно вообще отвезти на хранение в другой город. Причем в случае глобальной катастрофы, когда есть вероятность, что будет уничтожено все работающее оборудование, эти диски можно будет прочитать на любой рабочей станции. Для таких организаций — это ключевой фактор.

Помимо того, есть сценарий географического резервирования — геораспределенные площадки с оборудованием. Мы делаем это не кластеризацией целых узлов и гиперконвергентностью, как большинство компаний, использующих RAID-архитектуру, а физическим распределением нескольких «Дататек» и организацией управления данными по географическим точкам.

А что, если компания уже накопила большие объемы данных, использует облако или СХД другого производителя, как понять, что нужно менять систему? В каких случаях и как планировать переход?

Чего боится любой администратор любой крупной компании? Любых новшеств. У него что-то работает, пусть на временных решениях, но работает. А тут приходит новый вендор и говорит: «Я тебя спасу, предложу классное решение, но для интеграции тебе нужно отказаться от всего, что у тебя есть». ИТ-администратор хватается за голову и говорит: «Да иди ты!», потому что лучше продолжать использовать временные решения, которые еще как-то работают, чем попробовать внедрить новое, отказаться от существующего, а потом обнаружить, что новое не заработало, и тогда все окажутся в крайне неприятной ситуации.

Поэтому мы предлагаем несколько сценариев.

Первый — когда люди заинтересовались, но очень боятся. Сейчас мы начинаем работать с одним заказчиком, у которого объем данных просто гигантский. Они говорят: «Решение великолепное, именно то, что нам нужно, но мы не готовы сразу интегрировать его в инфраструктуру». И предлагают: «Давайте возьмем одну вашу «Дататеку» и серверное ПО, в изолированном виде поиграемся с одним устройством».

Схема такая. У нас есть устройства на 30, 45, 60 дисков. И они готовы выделить несколько SATA-дисков с информацией — для проверки работоспособности системы в реальном продакшене. Они берут минимальное устройство на 30 дисков, вставляют туда свои диски и в рамках одного устройства пробуют копировать, извлекать диски, создавать резервные копии, реализовывать функционал.

Следующий этап — у них есть еще SAS-диски. Кстати, месяца через три у нас появится в доступе универсальный SAS/SATA-бэкплейн. К тому времени, когда они освоят вариант с SATA, мы поставим вторую «Дататеку» с возможностью использовать SAS HDD, и они смогут сравнить оба предложения. Наработают опыт на всех вариантах и сценариях использования в «изолированных устройствах», не внося никаких изменений в работающую инфраструктуру.

И затем мы плавно подходим ко второму сценарию и говорим: «Теперь, когда у вас два изолированных устройства и есть управляющий сервер, давайте установим серверную «Ивановна» на управляющий сервер и построим кластер из двух «Дататек». Будем копировать данные не внутри одного устройства, а настраивать политики копирования и резервирования между двумя устройствами».

Я правильно понял, что «Ивановна» управляет всеми этими устройствами?

Да. ПО «Ивановна Сервер» устанавливается на выделенный сервер и позволяет организовать обмен данными как между «Дататеками», так и с любыми внешними устройствами — ленточной библиотекой, RAID-массивом, блочными системами из множества томов.

Сама «Ивановна» может быть кластеризована на требуемое количество серверов, работая в режиме Active-Active.

А как она общается с устройствами?

Для каждого типа устройств мы пишем специализированный тип «агента» — это можно считать чем-то вроде драйвера для систем хранения данных.

«Агент» для «Дататеки» знает, как с ней работать, учитывая специфику отчуждения HDD.

В ленточной библиотеке «агент» знает, как раскладывать информацию на ленточном носителе и что кассеты могут извлекаться.

Сейчас закончили разработку «агента» для блочных устройств, то есть к «Ивановне» можно подключить логический том в управление.

Выглядит это взаимодействие так: ПО «Ивановна Сервер» дает команду «агенту», установленному на конкретном типе устройств, выполнить конкретное действие. «Агент» его выполняет и сообщает «Cерверной Ивановне» о выполненном действии.

Сама «Дататека» — это не просто аппаратная платформа, она поставляется с предустановленным агентом. Это полноценное, работоспособное устройство, но оно не может взаимодействовать с другими элементами инфраструктуры или объединяться и встраиваться в кластеры.

Если администратор боится глубокой интеграции, он может ограничиться внутренним кластером — ленточные библиотеки существуют отдельно, RAID-массивы отдельно, а «Дататека» живет параллельно с ними. Если он прогрессивный— ставит ПО «Ивановна Сервер» поверх всех устройств на управляющий сервер, и она под одним интерфейсом управляет всем. Он говорит: «Эту информацию ты кладешь на RAID-массив, эту — на «Дататеку», эту — на ленточную библиотеку». Причем политики репликации можно настроить так, что одна копия создается на «Дататеке», а потом «Дататека» передает холодную копию на ленточную библиотеку и две копии хранятся на двух различных типах устройств. Вот настолько гибкая инфраструктура. Если человек доверяет — мы предоставляем единый интерфейс управления всеми устройствами. Если боится — говорим про изолированные системы.

В чем уникальность вашего ПАКа? На рынке есть российские объектные S3-хранилища на стандартных серверах, которые тоже работают с HDD любых производителей. И «ленточки». Ваше преимущество — это «Дататека» с уникальным управлением питанием каждого диска в отдельности? Или же более глубокая интеграция с ПО «Ивановна» и управлением жизненным циклом данных?

Прямых конкурентов на российском рынке у нас нет. Но есть компании, которые тоже пытаются решить эти задачи «по частям».

C одной стороны, это поставщики ленточных библиотек по схемам параллельного импорта. С заменой оригинального названия, на российское. Просто идет замена «шильдиков».

И многие пользуются такими решениями. Риск — благородное дело. Создавать заново, поддерживать и масштабировать инфраструктуру критических важных данных с помощью ушедших вендоров — так себе история. Но в традиции многих людей делать некоторые вещи по принципу «мы так привыкли», совершенно не думая о последствиях.

С другой стороны, есть действительно интересные решения локальных производителей RAID СХД, под объектное хранение по S3, но они не реализуют все необходимые задачи заказчиков, а только часть из них, при этом могут быть очень дорогостоящими, если говорить про большую инфраструктуру.

Наша уникальность в том, что мы не те и не другие. Во-первых, мы 100% российская компания. Де-факто российский производитель. 100% софта написано нами, он внесен в реестр. Это не заимствованное ПО. Мы предоставляем заказчику не полуфабрикат, который он будет доделывать, а полностью готовое решение под конкретные требования клиента. Если нужно что-то специфичное — поскольку мы чисто российский производитель и все разработчики у нас здесь, — мы быстро дописываем функционал под ТЗ заказчика.

Во-вторых, с точки зрения «железа»: разработка платформы — полностью наша, корпуса мы производим в Твери, разработка бэкплейна — наша собственная, уникальная, кабельная сборка и монтаж тоже выполняются здесь. Мы не занимаемся «перелицовкой». Понятно, что жесткие диски, процессоры, память, блоки питания — это не наше, никто еще не научился все это делать, но остальное мы делаем сами. Этим мы отличаемся от многих игроков, которые пытаются приземлить чужое, наклеить свою этикетку на что угодно.

Чем мы отличаемся от лент? Ленты — это чисто «импортная» вещь. Да еще и из середины прошлого века. И 80% проблем лент — в поддержке и совместимости поколений. Их обслуживают узкоспециализированные сотрудники, и кроме них в этой технологии никто не разбирается. Плюс параллельный импорт, плюс хранение критически важной информации в нынешних условиях на оборудовании недружественного вендора, который в любой момент может нажать рубильник, — и что будет дальше? Практически все госструктуры сейчас ориентированы на то, чтобы уходить от таких решений.

Но кто-то продолжает верить в мечту, что «скоро будет локализация производства ленточных библиотек».

Пусть продолжают верить и ждать. Но реалии таковы, что в этом направлении никто не собирается вкладываться в нечто большее, чем «переклейка шильдиков».

Кстати, раз уж речь зашла об импортозамещении, то как насчет отечественных CPU?

У нас сейчас второе поколение устройств. Первое поколение мы делали лет шесть-семь назад, и оно было на «Байкалах». Но новых процессоров-то нет. Если сделают «Эльбрус», который можно будет реально использовать, и он будет доступен, то, поскольку мы делаем все сами, нам ничего не мешает создать модификацию на «Эльбрусе». Но первое поколение у нас было именно на «Байкале». Умер «Байкал», а вместе с ним ушло первое поколение «Дататеки».

Вы наверняка отслеживаете новые перспективные носители данных. Каковы, на ваш взгляд, шансы на успех у технологии стеклянных дисков на 360 Тбайт?

До ухода иностранных вендоров, я и глава нашего R&D-департамента не один десяток лет отвечали у них за сегмент энтерпрайз-накопителей на всем постсоветстком пространстве и обеспечивали его развитие.

Поэтому мы прекрасно знаем, что происходило, происходит в этой отрасли и понимаем, куда и как движется рынок.

Сейчас из прикладных задач нас больше заботит, где найти «правильные» HDD, поскольку сейчас на рыке представлены в основном либо «восстановленные», либо различные вариации HDD со спецализированными прошивками под конкретного OЕM-производителя, так как они «дешевле и выгоднее».

А к чему может привести применение таких дисков в критически важной инфраструктуре, уж мы-то, как бывшие профессиональные «хардовики», прекрасно знаем. И у нас очень много сил уходит на смещение акцентов заказчика с «хочу самое дешевое» на «качественное».

А в отношении конкретного решения, то стеклянные пластины на 360 Тбайт — это замечательно, мы очень внимательно за этим следим, но это перспектива. Оптимистичный прогноз — пять лет, скорее всего, десять. Когда они будут доступны — обязательно будем использовать. Тем более что наши системы «всеядны». В рамках одного СХД можно использовать диски любых производителей, любых поколений, любых емкостей — причем в миксе одновременно.

Будут такие диски — обязательно найдем им применение. Если они будут иметь стандартный форм-фактор и интерфейс, то мы их просто установим в наше устройство. Если это будет какое-то принципиально новое устройство с другим форм-фактором или интерфейсом, то напишем для него нового «агента» — и вперед.

А если говорить о ближайших перспективах, то в каких направлениях вы развиваете решение?

Сейчас у нас уже есть пилотный образец универсального SAS/SATA-бэкплейна, мы его доводим до ума, чтобы выпустить в продакшен. Думаю, к концу года у нас в ассортименте появится модель нашего устройства под SAS HDD. Тогда можно будет реализовать на практике функционал и таких дисков.

Следующее, над чем работает наш R&D-департамент, — двухюнитовое устройство на NVMe-накопителях. Почему NVMe? Само хранение на NVMe нелогичное, но по сценариям некоторых заказчиков у них бывает очень узкое окно бэкапа — например, когда за очень небольшой промежуток времени нужно закачать огромный объем информации и в ночное окно обслуживания успеть быстро создать вторую и третью копию.

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

Мы видим наше развитие в этом направлении.