Распределённое архивирование файлов

Автор: Виталий Сайфуллин

Я помню те времена когда впервые столкнулся с проблемой архивирования своих данных. Помнится всё начиналось достаточно радужно. Тогда винчестер на 120МБ был запредельным счастьем на которое влазил Turbo C, Borland C++, несколько игрушек, а иногда даже и Windows 3.11 с Word 6.0. Обычно бэкап всего необходимого влазил на одну дискету 1.44МБ и состоял из документов и пары десятков файлов с исходниками. Занимало пять минут времени и не требовало автоматизации, ибо все файлы были наперечёт и отследить что появилось нового не было проблемой.

Потом ситуация стала ухудшаться, количество файлов по делу и просто так росло, появилась клятая Win95 (её как dos с дискетки не восстановишь), начал набирать популярность формат mp3. Бэкап стал проблемой, любимая музыка требовала носителей больше чем 1.44МБ, приходилось клянчить у везунчиков-с приводы cd-rw и покупать весьма дорогие оптические носители. Но и это было не главное. Возникла животрепещущая проблема недостатка жёсткого диска. И проблема возникала независимо от объёма самого диска. На лицо была ситуация когда скорость роста объёмов данных существенно превышал скорость роста объёмов носителей. Привод для оптических дисков стал не роскошью, а суровой необходимостью. Ведение архивов стало рутинной задачей.

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

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

Но взглянем теперь на корпоративный сегмент.

Исходные данные по среде ИТ приблизительно следующие:

• десятки серверов;
• несколько операционных систем;
• космическая стоимость основных систем хранения;
• огромные объёмы данных
• доступ к файлам может понадобиться в любой момент;
• обязательное резервное копирование данных.

В повседневной деятельности отделов ИТ перед ними стоят следующие задачи относящиеся к файловому хранению:

• непрерывный доступ к файлам;
• снижение стоимости хранения;
• надёжная защита данных.

Предположим, мы хотим оптимизировать стоимость хранения файлов. Уменьшить стоимость можно двумя способами: уменьшив собственно количество файлов или уменьшив стоимость носителей. Так как зачастую удаление файлов не является допустимым способом, то остаётся единственный вариант - перенос файлов на более дешёвые носители (введём упрощённый термин - миграцию). При этом нам необходимо помнить про то что две остальные задачи никто не отменял: оперативный доступ к файлам должен сохраниться, данные должны быть защищены. Чтобы полностью соответствовать пожеланиям пользователей на процесс архивирования данных также необходимо наложить несколько дополнительных требований:

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

Таким образом у нас вырисовываются характеристики системы архивирования под которые необходимо подобрать решение. Наиболее дешёвыми из существующих дисковых носителей являются дисковые системы с подключением по протоколу iSCSI, набитые дешёвыми дисками SATA. Скорости как iSCSI так и дисков SATA вполне достаточно для организации архивного хранилища. Для решения задачи автоматической миграции данных на архивное хранилище рассмотрим одноимённое решение австралийской компании Moonwalk. Пройдёмся подробнее по возможностям системы в свете описанных требований.

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

В основе его архитектуры лежит универсальный агент Columbia который обрабатывает файлы согласно политик. Columbia может работать в двунаправленом режиме, т.е. нет отдельного агента для сервера архивирования и отдельного для клиентских серверов. Можно сказать что агенты Columbia выстраиваются в одноранговую сеть. Каждый агент Columbia может выполнять роль исходного сервера данных или архивного сервера или обе одновременно. Архивная система хранения должна быть подключена ко всем серверам где агент Coulmbia будет работать в режиме архивного сервера.

Управляет агентами Columbia отдельный сервис Eagle. Он держит на себе политики, расписание, информацию о подключенных серверах. Ключевым моментом является то, что Eagle не участвует в фактической передаче данных. Эдакий образцовый сержант, который сам не работает, но командует отменно.

Сервис Eagle управляет автоматическим процессом архивирования и перемещения файлов, отдавая команды агентам Columbia на действия с файлами. Действия могут практически любые:

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

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

Для определения списка файлов Eagle оперирует широким набором критериев поиска:

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

На основе этих критериев файлы можно рассортировать практически с неограниченной гибкостью и рассовать по архивам так как того требуют обстоятельства.

Кросс-платформенность решения заключается в том что агенты Columbia существуют для различных операционных систем, а файлы могут свободно мигрировать между агентами на различных операционных системах и файловых системах.Основные операционные системы, под которые написаны агенты Columbia: Windows, SLES, RHEL, Novell OES2/Netware. Надо заметить что ОС от компании Novell поддерживает только это решение. Практически все конкуренты имеют кругозор, ограниченный платформой Windows и файловой сиcтемой NTFS.

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

• агент работы с серверами NFS, т.е. как источником данных, так и архивом может выступать любое устройство или сервер с включенным протоколом NFS, что существенно расширяет спектр поддерживаемых платформ;
• агент NetApp, который позволяет как вычистить NetApp от лишних данных, так и наоборот использовать файлер для надёжного хранения архивов;
• агент Amazon S3 - только как архив;
• агент Caringo CAStor - только как архив.

Самой интересной архитектурной особенностью решения безусловно является её распределённая структура и отсутствие центральной точки отказа.

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

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

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