Сергей Лебедев: Система резервного копирования должна быть антихрупкой

За последние полтора года на российскую инфраструктуру было совершено много атак. Были и случаи полного уничтожения данных. Компании всерьёз опасаются того, что их данные могут быть утрачены. Начинать заботиться об отказоустойчивости и резервном копировании нужно прямо сейчас. Об этом — в интервью с Сергеем Лебедевым, директором направления систем резервного копирования компании «Киберпротект», и Иваном Смирновым, старшим менеджером продукта «Кибер Инфраструктура».

Зачастую атакам подвергались очень крупные компании, у которых есть бюджет на средства защиты и резервного копирования. Что они делали не так? Почему стали жертвами?

Сергей Лебедев: Прежде всего стоит вспомнить о том, что киберзащита — понятие комплексное. Надеяться на то, что какой-то продукт или сервис полностью защитит инфраструктуру и бизнес от всех атак, нельзя.

Можно иметь очень надёжную систему резервного копирования, но при этом уровень противодействия атакам на уровне сети или защита конечных точек могут быть слабыми. Бывает и наоборот: они сильны, но при этом система резервного копирования не была развёрнута должным образом. Может быть и так, что всё работает, но самые важные документы именно в это время мигрировали и из-за недоступности какого-то сервиса были утрачены.

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

Здесь как раз и возникает вопрос, как же всё-таки происходит утеря данных. У многих система резервного копирования даже дублируется, но при этом все бэкапы уничтожаются вместе с основной инфраструктурой. Может быть, дело в неправильной настройке?

С. Л.: Совершенно верно. Система резервного копирования может быть настроена идеально: «3-2-1», отчуждаемый носитель, передовые СЗИ. Но в это самое время какой-нибудь сотрудник где-нибудь случайно открыл свою рабочую станцию, а злоумышленник банально подсмотрел или поставил кейлогер туда, где вводились логин и пароль, получил привилегии этого пользователя, дальше внутри через эксплойты получил привилегии администратора, а затем уже и полный доступ.

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

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

Давайте поговорим об отказоустойчивости в целом. Какие здесь, на ваш взгляд, происходят ошибки при проектировании ИТ- и ИБ-систем?

С. Л.: Тут важно подчеркнуть, что термин «отказоустойчивость» — сложный и комплексный. Отказоустойчивостью обладают разные сервисы и разные компоненты.

Иван Смирнов: Также важно понимать, для чего нужна отказоустойчивость. Она необходима для того, чтобы обеспечить непрерывность бизнеса. К информационной системе предъявляются определённые требования. Существуют метрики RTO — допустимое время восстановления, RPO — целевая точка восстановления, расчёт стоимости часа простоя бизнеса. Важно знать, какой максимальный объём данных можно потерять.

Абсолютно надёжных систем не бывает.

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

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

Безусловно, специфика бизнеса играет здесь ключевую роль. На примере атак на маркетплейсы мы видим, что за 15 или 30 минут можно понести критические потери. В то же время в других сферах простой в 15 минут не играет такой большой роли: на сайт «Госуслуг» можно зайти и попозже.

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

С. Л.: Ещё раз отмечу, что отказоустойчивость в рамках бизнеса — это свойство или требование, предъявляемое к инфраструктуре и технической составляющей бизнес- процессов, обеспечивающих непрерывность и эффективность данного бизнеса.

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

Отказоустойчивость накладывается разными слоями на элементы бизнеса.

Какой должна быть современная надёжная система резервного копирования именно в текущий момент времени?

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

Система должна быть антихрупкой, то есть рассчитанной на то, что случится нечто неопределённое.

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

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

Поэтому к системе резервного копирования предъявляются чуть менее жёсткие требования с точки зрения высокой доступности, но всё равно любая крупная компания требует от этого сервиса отказоустойчивости и высокой доступности.

Второй аспект касается самих резервных копий и надёжности их хранения.

Резервные копии терять нельзя никогда.

Ряд компаний, например из финансового сектора, обязаны длительно хранить архивные копии. Это требование на них накладывает регулятор. И потом, через несколько лет, от них могут потребовать восстановить данные из АБС за такую-то дату три года назад. И они обязаны это выполнить, иначе со стороны регулятора будут санкции.

В крупных компаниях одинаково недопустимы как простой систем резервного копирования, так и потеря данных. Эти угрозы могут предотвращаться кластеризацией сервиса резервного копирования, всех его основных компонентов. Надёжность хранения данных достигается разными способами и на разных уровнях, в основном аппаратными средствами.

Зачастую утечки могут быть не напрямую из продуктива, а из бэкапа, до которого проще дотянуться и достать все необходимые данные. Как в вашем случае резервные копии защищаются от несанкционированного доступа?

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

Кроме того, возвращаясь к вопросу о том, какой должна быть современная система резервного копирования, следует отметить такое её свойство, как гибкий доступ. Если в компании часть регламентов определяет, что какие-то люди должны только следить за состоянием данных, то они не должны иметь возможности посмотреть, что находится в этих данных, или удалить резервную копию. Это регулируется на уровне привилегий доступа, а также на уровне носителей.

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

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

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

Существуют также ленточные библиотеки, у которых в принципе иной профиль доступа. Удалить их сложнее, даже получив полный доступ к системе. Есть также специальные ленты, которые называются WORM («write once, read many»). Раз записав на них данные, перезаписать что-то сверху уже нельзя — как на старый CD-ROM. WORM находит достаточно широкое применение, например, в финансовом секторе, особенно для архивных копий, которые предполагается хранить длительное время.

А как насчёт старого доброго способа записать информацию на некий носитель и убрать в сейф? Так сейчас больше никто не делает?

И. С.: Есть золотое правило, классика, которая никогда не стареет и обязательна (must have) практически для всех. Это правило называется «3-2-1». Нужно иметь как минимум три резервные копии на двух различных типах носителей, и одна копия размещается за пределами дата-центра, в котором находится защищаемая система, либо записывается на физически отчуждаемый носитель. Это именно тот вариант, когда записали данные на ленту, положили в шкаф и заперли на ключ. Вот туда проникнуть очень сложно.

Существуют и другие целевые системы для резервного копирования. Так, у нас есть бэкап-шлюз (backup gateway). Кроме этого, нашими заказчиками всё ещё используются так называемые D2D (disk-to-disk backup) от зарубежных производителей. Они либо эмулируют ленточные библиотеки, либо используют свой проприетарный протокол, и для того чтобы удалить оттуда данные, нужно получить доступ непосредственно в консоль управления системы резервного копирования либо на это устройство.

Доступа в операционную систему (клиентскую, например) либо просто на сервер резервного копирования будет недостаточно для того, чтобы удалить эти копии.

Давайте поговорим теперь о наиболее известном вашем продукте «Кибер Бэкап». Какие системы он сейчас поддерживает и работаете ли вы над поддержкой отечественного стека продуктов?

С. Л.: «Кибер Бэкап» по праву можно назвать нашим флагманским продуктом. Что касается отечественных систем — мы не только работаем над их поддержкой, мы возглавляем этот тренд.

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

По нашим данным, сейчас в России больше 30 систем виртуализации, включённых в реестр российского ПО, и мы поддерживаем максимальное их количество.

Кроме того, мы поддерживаем и российские ОС: можно делать бэкап для серверов, работающих под их управлением. Помимо этого, мы осуществляем поддержку и виртуальных машин.

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

Важным вектором в развитии поддержки российских систем мы считаем охват всего их многообразия.

Мы сейчас находимся в ситуации, когда инфраструктура технологически очень пестра. Некоторые заказчики ещё пользуются VMware, у кого-то есть пара серверов с Hyper-V, кто-то хочет размещать свои данные уже в хранилище от российского вендора. И всё это нужно бэкапить и восстанавливать при помощи нашего продукта, поэтому, безусловно, список поддерживаемого российского ПО широк и будет ещё активно расти.

 

 

Можно ли при помощи вашего продукта производить также резервное копирование данных, которые находятся в публичном облаке — например, в VK Cloud или Yandex Cloud?

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

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

«Яндекс» — наш уважаемый партнёр, мы тесно сотрудничаем. Так, совсем недавно на собственной конференции «Яндекс» рассказывал про свой облачный бэкап с помощью нашего решения. Можно прямо в «Яндексе» включить наш шлюз и, развернув наш продукт, подключить этот сервис и бэкапить виртуальные машины в Yandex Cloud.

А как быть с теми, кто хочет хранить свои резервные копии у себя в периметре?

С. Л.: Такая возможность тоже существует. Здесь мы говорим об агентском резервном копировании. Нужно только обеспечить связность. Это уже гибридная инфраструктура, одна часть которой локальна, а другая находится в облаке. Такой сценарий мы тоже можем поддержать, потому что на виртуальной машине, развёрнутой в облаке, можно поставить агент и забэкапить её локально. Важно лишь, повторюсь, обеспечить сетевую связность между агентом и сервером управления.

И. С.: Как выглядела инфраструктура резервного копирования многих крупных заказчиков до известных событий? У них были среда виртуализации, которая занимала 90 % всех вычислительных мощностей, и отдельно стоящие приложения. Была также система резервного копирования, которая поддерживала западные решения. Всё это, как правило, бэкапилось на два типа целевых систем резервного копирования.

Первый тип — системы для данных со сроком хранения до 28 дней. Как правило, они применяются для более быстрого восстановления. Для того чтобы окно восстановления было как можно меньше, обычно используются D2D. Это устройства наподобие сервера, со множеством дисков и специальным проприетарным ПО. Помимо этого были роботизированные ленточные библиотеки, где стоимость хранения за гигабайт невелика. Они очень хорошо подходили для хранения «холодных данных».

Что же произошло? Появилась одна большая проблема: для всех D2D-устройств в 2022 году исчезла поддержка. Эти системы гораздо более сложны в поддержке, чем, например, обычные x86-серверы. К слову сказать, сейчас появилось очень много x86-серверов под различными российскими марками, и с ними нет настолько больших проблем в части доступности поддержки и запасных частей.

Кроме того, ряд заказчиков использовал высокопроизводительные (high-end) системы хранения данных, и у них разом обрушился весь западный стек: системы хранения, ПО резервного копирования, D2D-устройства и ленточные библиотеки.

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

Есть возможность выполнить резервное копирование данных в систему хранения на базе «Кибер Инфраструктуры», где мы поддерживаем репликацию резервных копий на удалённую площадку, многоуровневое хранение с использованием внешних облачных S3-хранилищ. Кроме того, у нас есть ещё своё хранилище, которое масштабируется на десятки петабайт и хорошо интегрировано с нашим же продуктом «Кибер Бэкап».

Предлагаю перейти теперь к теме киберконвергентности. Что это такое и какая роль здесь отводится резервному копированию?

И. С.: Сначала, лет 30 назад, нагрузки ставились на аппаратные серверы с одной операционной системой. Всё было хорошо, пока люди не поняли, что утилизация вычислительных ресурсов мала и можно сделать дешевле.

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

Затем, в начале 2010-х годов, появилась конвергенция. Был вычислительный слой (серверы), затем — слой коммутации (сети связи), а ещё ниже — системы хранения данных. Именно так заказчики строили классическую виртуальную инфраструктуру. Тогда некоторые вендоры стали предлагать конвергентную инфраструктуру.

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

Можно представить себе это как некий шкаф, который заранее настроен и скоммутирован на заводе. На нём уже стоит какая-то система виртуализации, и заказчику нужно только подключить его к сети питания.

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

Потом появилась гиперконвергенция — модное слово в середине 2010-х годов. Идея состояла в том, чтобы полностью отвязать инфраструктуры хранения, вычислительную и сетевую от кастомного проприетарного «железа».

Мы используем обычные стандартные серверы без какого-то сложного специально разработанного аппаратного обеспечения. Есть программное обеспечение, которое объединяет вычислительные ресурсы, сеть и устройства хранения в общий пул, управляемый программным способом.

Какие здесь есть преимущества? Во-первых, нет вендорского ограничения (lock-in). Во-вторых, мы экономим средства на оборудовании, так как миграция со старого оборудования на новое происходит достаточно легко.

Как эволюционирует резервное копирование под такие системы?

И. С.: Гиперконвергенция — просто платформа на уровне инфраструктуры. Сами информационные системы работают, как и ранее, в различных виртуальных машинах и прочих устройствах. Гиперконвергенция очень удобна в эксплуатации, так как универсальна и быстра в развёртывании.

Резервное копирование гиперконвергентных структур выполняется примерно таким же образом, как раньше с обычными операционными системами.

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

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

Давайте поговорим теперь о вашем продукте «Кибер Инфраструктура». Он как раз ориентирован на ЦОДы и программно определяемые среды. Какими преимуществами он обладает?

С. Л.: Прежде всего «Кибер Инфраструктура» — это отказоустойчивое хранилище наших же бэкапов.

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

Вместо того чтобы хранить свои данные на ленте или в NAS, заказчики могут развернуть у себя наше отказоустойчивое и гибкое решение. Мы предоставляем вендорскую поддержку, и наш продукт — это надёжная связка системы резервного копирования с местом хранения бэкапов. Ещё раз отметим его ценные свойства: отказоустойчивость, высокая доступность и масштабируемость.

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

Таким образом, гиперконвергенция — это слой архитектуры, а поверх него наш продукт отдаёт разные сервисы: хранилище бэкапов, S3-совместимое хранилище, а также виртуализация компьютеров.

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

Хранилище может использоваться как бэкап-таргет медленных, дешёвых, но объёмных дисков в связке с «Кибер Бэкапом». Кроме того, ещё одна сфера применения нашего решения — HCI. На трёх и более серверах разворачивается отказоустойчивая система виртуализации, которая хранит данные своих виртуальных машин на этих же серверах с локально установленными дисками. Данные «размазываются» по серверам так, что вы можете, условно говоря, потерять целиком один аппаратный хост, при этом доступ к данным не прекратится.

Можно ли в настоящий момент восстанавливать данные из резервных копий без остановки бизнес-приложений? Это особенно важно, например, для маркетплейсов.

С. Л.: Бизнес-приложение — это не «file.exe». Это — некая архитектура. Всё зависит от того, как она сделана.

Если мы хотим вживую восстанавливать серверы, которые посещает большое количество пользователей, то, например, в моменты пиковой нагрузки (в случае маркетплейса — с 20:30 до 22:00, когда люди выбирают подарки себе и близким) восстанавливать что-либо в продуктив не очень хорошо.

Но это связано ещё и с отказоустойчивостью бизнес-приложения. Так, может быть три клиентских (frontend) сервера. Мы выключаем один из них, а два продолжают работать. Между ними балансируется нагрузка, а третий мы восстанавливаем или обновляем.

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

Каковы ваши планы дальнейшего развития продуктов на ближайшее время?

С. Л.: У нас большие планы в отношении «Кибер Бэкапа». Есть несколько направлений развития. У нас имеется дорожная карта, которая «приземлена» в грядущие релизы. Ближе к релизу мы будем более точно знать, какая именно функциональность войдёт в новую версию и в каком объёме.

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

Продукт должен удовлетворять всем требованиям, о которых сегодня шла речь: предсказуемость по операционным расходам, сайзинг, удобство масштабирования.

У нас также есть цель поддерживать большую скорость и управление количеством потоков и производительностью. Требования растут, и мы должны выполнять эти запросы. Часть этих требований касается управления. Должно быть гибкое управление ролями и привилегиями, здесь у нас запланирован целый набор. Системами должны управлять разные люди с разным доступом. Должна быть гибкая настройка времени (backup window) и так далее.

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

Систем виртуализации немало; многие из них мы уже поддерживаем, другие — планируем поддерживать. Кроме того, мы наблюдаем за всеми изменениями на рынке.

Другое направление — это бэкап разных приложений, как в части данных, так и в части почты. Это, например, системы управления базами данных. Есть разные решения на базе Postgres. Кроме того, мы активно развиваем направление NoSQL.

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

И. С.: Один из кейсов использования «Кибер Инфраструктуры» — это, как уже говорилось, S3-хранилище. На базе этого решения мы можем организовать как локальное, так и облачное хранилище. Наша сильная сторона — в том, что оно может масштабироваться в рамках одного кластера до больших объёмов, самых больших на рынке.

Ещё одна наша цель — добиться полного покрытия согласно спецификации Amazon S3. Мы хотим, чтобы наше хранилище было не только самым масштабируемым и отказоустойчивым, но и чтобы абсолютно любое приложение на рынке можно было бесшовно с ним интегрировать. Мы считаем, что у нас сейчас уже довольно большое покрытие. Периодически тестируем различные внешние программные комплексы и считаем, что больше 80 % из них не требуют каких-то дополнительных действий для хорошей работы с нашим S3-хранилищем.

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

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

Один из наших кейсов, как я уже говорил, — это шлюз (backup gateway). Мы уже реализовали его с «Яндексом» и будем развивать это направление в части замены зарубежных D2D-систем. В дальнейшем будет добавлена такая функциональность, как дедупликация и компрессия.

Большое спасибо за содержательное интервью. Желаем вам дальнейших успехов, а нашим зрителям, как всегда, — всего самого безопасного!