Большие данные: архивация ≠ бэкап

Big Data Big Data / Безопасность
автор: Андрей Васильков  22 января 2015

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

Вместе с тем, в сфере «больших данных» классические методы резервного копирования оказались малопригодными. Для Big Data ни одна из схем ротации не применяется в чистом виде из-за слишком высоких требований к доступному объёму носителей и скорости чтения/записи.

Эволюция методов резервного копирования данных в XXI веке (инфографика: axcient.com).

Эволюция методов резервного копирования данных в XXI веке (инфографика: axcient.com).

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

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

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

Эволюция стандарта LTO и прогноз его развития (изображение: backupworks.com).

Эволюция стандарта LTO и прогноз его развития (изображение: backupworks.com).

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

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

Инфраструктурное решение VSPEX виртуализирует СУБД для облачных сред. Оно поддерживает дедупликацию и скоростное резервное копирование (изображение: emc.com).

Инфраструктурное решение VSPEX виртуализирует СУБД для облачных сред. Оно поддерживает дедупликацию и скоростное резервное копирование (изображение: emc.com).

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

На аппаратном уровне для резервного копирования «больших данных» используются специализированные серверы и узлы СХД. Они соединяются при помощи скоростных интерфейсов (например, оптоволоконный канал 16G / 20G или 10 Gb Ethernet) по протоколу iSCSI. Наличие параллельно работающих контроллеров ускоряет обработку, а оснащение энергонезависимой кэш-памятью (NAND Flash) объёмом в несколько гигабайт снижает риск потери данных и уменьшает задержки дисковой подсистемы.

Сети хранения данных в локальной сети крупного предприятия (изображение: sdsblog.com).

Сети хранения данных в локальной сети крупного предприятия (изображение: sdsblog.com).

Обычный пользователь редко обращает внимание на такой показатель, как частота возникновения невосстановимых ошибок чтения диска (unrecoverable error rate – UER или bit error rate – BER). Если он и столкнётся с такой раз в год, то вряд ли даже заметит. При петабайтных объёмах корпоративных данных картина складывается совсем другая: критические ошибки чтения не просто очень вероятны – они возникают регулярно и гарантированно.

Из соображений надёжности в СХД для Big Data не используются диски с интерфейсом SATA (их значение UER слишком высоко: 1 x 10-14) и редко встречаются диски типа Near Line SAS (NL-SAS). У них частота возникновения ошибок хоть и меньше на порядок, но всё равно недостаточна низкая. Практика показывает, что «Большие данные» остаются целостными длительное время только на лучших в отрасли дисках Serial Attached SCSI (SAS) класса Enterprise.

По этой же причине организация дисковой подсистемы во всех областях Big Data используется специфическая: обычно это тома RAID 50 или 60, в которых дисковые группы имеют малый размер. Это снижает вероятность ошибки при перестроении массива, которая напрямую связана с количеством дисков.

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

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

Поделиться
Поделиться
Tweet
Google
 
Читайте также
Технологии резервного копирования больших данных
Технологии резервного копирования больших данных
Dell Software анонсировала пакет для резервного копирования и восстановления.
Dell Software анонсировала пакет для резервного копирования и восстановления.
966
1С будет использовать резервное копирование от Acronis.
1С будет использовать резервное копирование от Acronis.
Хостинг "ИТ-ГРАД"
© ООО "Компьютерра-Онлайн", 1997-2017
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.
«Партнер Рамблера» Почта защищена сервером "СПАМОРЕЗ" Хостинг "Fornex"