Создание резервных копий давно используется в качестве универсального метода защиты данных. Он применяется в качестве средства быстрого восстановления их целостности после аппаратного сбоя или человеческой ошибки. Случайное удаление файлов, повреждение баз данных, последствия заражения – всё это эффективно устраняется с помощью регулярного бэкапа.
Вместе с тем, в сфере «больших данных» классические методы резервного копирования оказались малопригодными. Для Big Data ни одна из схем ротации не применяется в чистом виде из-за слишком высоких требований к доступному объёму носителей и скорости чтения/записи.
При создании офлайновой копии придётся передать и проверить сотни терабайт, поэтому время простоя будет измеряться многими часами. Теневое копирование может снизить частоту обновления текущей информации, которая часто составляет миллионы запросов в минуту. В общем случае время выполнения бэкапа или восстановления из него может оказаться слишком большим – процесс потеряет актуальность до того, как будет полностью выполнен.
За последние годы было разработано несколько общих стратегий, программных решений и специализированных аппаратных средств корпоративного класса, ориентированных именно на резервное копирование «больших данных». Они позволяют эффективно обрабатывать петабайтные объёмы и множество одновременных обращений без ущерба для текущих операций.
В первую очередь из всего объёма данных требуется выделить операционные (обрабатываемые в данный момент) и актуальные (которые с высокой вероятностью потребуются в ближайшее время). Практика показывает, что на большинстве предприятий около семидесяти процентов файлов имеют низкую актуальность. Их ещё рано удалять совсем, но обращения к ним происходят только несколько раз в год. Поэтому целесообразно переместить их в архив – к примеру, на ленточные носители, обладающие низкой стоимостью хранения данных и высокой надёжностью.
Архивация – это не эквивалент резервного копирования. Перемещение старых файлов на ленту лишь освобождает полезный объём более быстрой системы хранения данных (СХД) для самых актуальных файлов и в разы сокращает время многих операций с ними, включая регулярный бэкап.
Однако даже после перемещения львиной доли файлов в архив среди них остаются блоки-дубликаты. Это не полные копии файлов, а содержащие мало уникальных фрагментов.
Поэтому на программном уровне главной технологией стало устранение избыточности данных, или их дедупликация. Какова бы ни была структура хранимых файлов, в ней всегда можно найти повторяющиеся сегменты. Их исключение помогает решить сразу несколько проблем: сократить поток сжимаемых данных, уменьшить суммарный объём резервной копии, время её создания, проверки и восстановления. Современные алгоритмы позволяют пропускать повторяющиеся данные «на лету» – то есть, ещё до того, как они будут записаны на СХД.
Вместе архивация и дедупликация существенно снижают уровень энтропии данных, но не устраняют повторы полностью. Остаточная избыточность зависит от исходного типа файлов и алгоритма их обработки. К примеру, в мультимедийных файлах удобно сравнивать большие блоки, а для оптимизации копирования СУБД – малые фрагменты по несколько килобайт. В отдельных случаях требуется проводить сплошное побайтное сравнение для снижения требований к полосе пропускания. Это принципиально разные алгоритмы, которые эффективно работают только со своим типом данных.
На аппаратном уровне для резервного копирования «больших данных» используются специализированные серверы и узлы СХД. Они соединяются при помощи скоростных интерфейсов (например, оптоволоконный канал 16G / 20G или 10 Gb Ethernet) по протоколу iSCSI. Наличие параллельно работающих контроллеров ускоряет обработку, а оснащение энергонезависимой кэш-памятью (NAND Flash) объёмом в несколько гигабайт снижает риск потери данных и уменьшает задержки дисковой подсистемы.
Обычный пользователь редко обращает внимание на такой показатель, как частота возникновения невосстановимых ошибок чтения диска (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 – это не выбор одного из типовых решений, а разработка персональной схемы бэкапа с учётом специфики предприятия и его ИТ-инфраструктуры. Без внедрения опытным интегратором даже лучшие системы в своём классе лишь усугубят проблему обслуживания возрастающих объёмов данных.