Резервное копирование для облаков: контейнеры под защитой

Просмотров: 211
Автор:
Порохов Владимир

Порохов Владимир

Senior Engineer — Virtuozzo

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

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

Во-вторых, законодательные инициативы, требующие хранить персональные данные российских пользователей на территории России №152-ФЗ «О персональных данных» или длительное время сохранять переписки пользователей №374-ФЗ «Закон Яровой» значительно увеличивают стоимость каждого риска утери данных, дополняя их опасностью получения штрафных санкций со стороны регуляторов.

Свой вклад вносит и закон №187-ФЗ «О защите критической информационной инфраструктуры», где резервное копирование является неотъемлемым элементом средств информационной защиты. Можно сказать, что усиленное внимание к данным – это не только российская тенденция. Например, европейские положения GPDR по обработке данных, которые значительно ужесточают требования к хранению данных и устанавливают внушительные штрафы за их нарушение, так что проблема резервного копирования «всего и вся» становится на сегодняшний день глобальной, и наличие таких новых элементов экосистемы, как контейнеры, создает дополнительную «головную боль» для администраторов и ИТ-директоров.

Специфика контейнеров

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

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

Для того, чтобы настроить работу контейнеров, таких как, Docker, LXC или Kubernetes, с внешним хранилищем, требуется либо специально дорабатывать приложения для работы с определенным внешним ресурсом, либо использовать готовые решения, уже интегрированные с системой контейнерной оркестрации. Учитывая бум популярности контейнеров приложений, мы вынуждены были разрабатывать специализированные интерфейсы хранилища Virtuozzo Storage for Docker или Virtuozzo Storage for Kubernetes, чтобы автоматизировать запись во внешнее хранилище для всей контейнерной экосистемы.

Распределенное хранение данных и резервное копирование в нем

Но вернемся непосредственно к вопросам резервного копирования. На сегодняшний день существует потребность защищать данные от шифрования или утраты и для контейнеров, и для виртуальных машин, и для физических серверов. И как показывает практика, проще всего реализовать комплексную политику хранения резервных копий в распределенном хранилище данных. Кстати, SDS (Software-Defined-Storage) оказывается намного выгоднее само по себе. Например, по оценкам HP, затраты на распределенное хранение данных могут быть до двух раз меньше, чем при использовании традиционного подхода.

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

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

Тем временем резервные копии в распределенном хранилище могут создаваться автоматически. Когда виртуальная машина или контейнер делает запрос на запись, промежуточное ПО сразу же распределяет данные по сети, чтобы они находились на разных дисках и в разных серверах. Сам по себе этот подход позволяет повысить производительность системы хранения и создает условия для защиты информации – вплоть до катастрофоустойчивой. Если администраторы настроят распределение данных между разными серверными стойками, будет обеспечена безопасность от комплексного сбоя оборудования, а если между разными ЦОД — то ваша информация сохранится даже в случае взрыва.

Более эффективное использование дисков

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

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

Одной из популярных схем является хранение в режиме 3+2, когда на три блока данных приходится 2 хэша, которые позволяют восстановить информацию в случае утери любых двух блоков. Работа с Erasure Coding помогает экономить емкость, так при хранении 100Гб данных с двумя копиями в кластере из 5 серверов общая емкость будет сокращена примерно до 170Гб вместо 300 Гб. А чем больше серверов задействованы в хранилище, тем больше места будет сэкономлено. Например, если хранилище будет распределено по такой же схеме на 20 серверов, избыточное использование дисков будет ограничено 20% при таком же уровне защиты, когда утрата любых двух блоков данных не влияет на их целостность.

Есть и другой аспект использования EC для организации сценариев резервного копирования — и это оптимизация загрузки сети. Дело в том, что сохранение хэшей требует меньше пропускной способности, чем для полных копий данных. А поскольку резервное копирование фактически представляет собой последовательную запись данных, EC помогает добиться многократного снижения трафика в сети при увеличении нагрузки на процессоры серверов в пределах 1-2%. Например, когда мы тестировали кластер из 6 узлов, применение EC помогло увеличить пропускную способность кластера для задач резервного копирования в 1,6 раз, а при работе 12 серверов — в 3 раза! Это значит, что даже при увеличении потоков данных вполне можно обойтись существующими каналами связи.

Выбор в пользу будущего

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

Комментарии (0)

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.