О Чем Стоит Задуматься, Сохраняя Свои Данные в Облаке. Часть 2

Вкратце, речь идет о том, что, сохраняя данные на нескольких облаках, можно существенно повысить их доступность и сохранность. Под сохранностью имеется ввиду, что данные будут существовать, даже если у одного провайдера (или нескольких) случился серьезная проблема. Подробная мотивация в первой части ^[1].

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

Хочу сразу отступление сделать. Я сознательно использую английский термин erasure codes в статье – я не нашла этого термина на русском языке. Это не коды корректирующие ошибки никоем образом. Если кто знает и подскажет – буду благодарна.

Теория

Коды

К счастью, существует иной подход, позволяющий сэкономить и на занятом дисковом пространстве и на трафике, не снижая при этом уровень доступности данных. Это erasure codes ^[2].

Суть erasure codes заключается в том, что после кодирования некоторого файла получается n фрагментов (в практической реализации это так же файлы). Любые m из этих фрагментов равны по размеру оригинальному файлу. При этом n > m. Каждый из фрагментов сохраняется в отдельном облачном хранилище. Для восстановления первоначального файла достаточно собрать m любых фрагментов и декодировать. Остальные n-m фрагменты могут быть удалены, испорчены, содержащие их облачные хранилища не доступны итд. Таким образом, система, использующая erasure codes может справиться с появлением n — m ошибок.

Для тех кто хочет копать глубже, я описываю именно MDS erasure codes. Существуют иные типы кодов и у них слегка иные свойства. Если будет интерес, могу описать подробно со всей математикой.

Чем такой подход лучше

Размер избыточных данных

Соотношение параметров n и m можно выбирать. Например, можно задать параметры так, что n = 2*m, в таком случае размер закодированных данных будет ровно в два раза больше оригинального. К примеру, пускай m = 5, n = 10. Тогда фрагментов после кодирования получается 10 штук. Размер одного фрагмента будет равен отношению размера файла к m. Если собрать любые 5 из этих фрагментов и посчитать общий размер, то он будет равен размеру первоначального файла. Каждый из фрагментов сохраняется на одном из 10-ти облачных хранилищ. Любые 5 хранилищ при этом могут в один момент времени оказаться недоступны, на доступность же пользовательских данных это не повлияет – файл можно будет восстановить.

В математических обозначениях это выглядит так. Допустим, размер файла равен L. Тогда размер одного фрагмента составляет p = L/m, общий размер избыточных данных – 2*L. Размер всех фрагментов, необходимых для восстановления равен L = p*m.

Сравним с репликацией. Чтобы иметь в систему, в которой любые 5 облачных хранилищ могут выйти из строя, необходимо иметь 6 облачных хранилищ, каждый из которых хранит копию файла. В таком случае размер данных сохраненных в системе будет в 6 раз больше размера файла. В то время как при использовании erasure codes – понадобится сохранить избыточные данные в два раза превышающие размер первоначального файла.

Таким образом, в системе, которая способны пережить появление определенного числа ошибок, при использовании erasure code:

• на каждом из сервером нужно хранить меньшее количество данных
• общий размер данных которые нужно сохранить будет существенно меньше
• общее число облачных хранилищ требуется больше

Последний пункт может перевесить достоинства первых двух, а может и нет. Все зависит от конкретной ситуации. Насчет этого можно подискутировать в комментариях, если возникнет интерес.

Трафик

Ну это очевидно. Если объем данных, которые необходимо сохранить – меньше, то и количество трафика потраченного на сохранение будет пропорционально меньше. Плюс в сторону erasure codes. При восстановлении в любом из случаев – используется ли репликация или erasure codes, размер данных, которые требуется передать будет равен размеру изначального файла, те L.

Время затраченное на кодирование

Очевидно, репликация кодирования не требует. Насколько же использование кодов замедляет работу? Существует великое множество подобных тестов. У меня кодирование 512 мегабайтного файла в среднем заняло меньше 4-х секунд (тест я повторяла 1000 раз). Конфигурация была следующая — компьютер с оперативкой 3 гигобайта, процессор 3 GHz Intel Core 2 Duo. Операционная система – 11.10 Убунту. В качестве кодека я использовала знаменитую библиотеку Jerasure, актуальная версия ^[3] которой есть на github.

Итог

Erasure codes:

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

Практика

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

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

Пока что представляю Вашему вниманию игрушки:

• NCCloud ^[4]
• NubiSave ^[5]

NCCloud использует новейшие коды –регенерирующие коды. Основной предлог использования этих кодов – уменьшение трафика в случае, когда у одного или нескольких облаков произошли ошибки и Ваши данные оказались недоступны-испорчены. При этом способности к восстановлению данных у таких кодов падают (в сравнении с рассмотренными в этой статье, при одинаковом уровне доступности). Я с таким подходом в корне не согласна. Причина проста. Такие коды играют важную роль если данные храниться в p2p сети, где ноды сети то появляются то пропадают. В случае использования облаков, доступность каждого облако очень высока и ошибки, проблемы возникают редко. Соответственно, и процесс восстановления данных будет происходить редко. Экономить на трафике во время этого процесса, при этом ухудшая его эффективность мне представляется не разумным.

NubiSave использует код Каучи Рида-Соломона ^[6] для создания избыточных данных. Кодирование данных происходит поэтапно, то есть в тот момент, когда один блок данных кодируется, предыдущий уже загружается на облачные хранилища. Это позволяет сократить время ожидания для пользователя. Положительный аспект их архитектуры заключается в том, что Можно гибко настраивать обработку данных – будут ли они зашифрованы или сжаты. Серьезный недостаток – имплементация шифрования и конфиденциальность в целом не продуманы пока что (повторюсь, об этом подробнее в другой части статьи).

Кстати, некоторые облачные провайдеры уже тоже используют erasure коды. Например, пропиетарное решение ^[7] от Wuala.

Автор: mechanical_mind