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