Ниже приведены заметки о системе распределенного резервного копирования с дедупликацией данных на стороне клиентов EMC Avamar.
Avamar поставляется в 3 видах - как ПО, как устройство (сервер и ПО) и как виртуальная машина.
Устройства (appliance) поставляются в виде сервера, дистрибутива ОС (оптимизированный RedHat) и комплекта дистрибутива Avamar, которые интегратор должен самостоятельно поставить на этот сервер.
Устройство (appliance) 1 ТБ укомплектовано 6 дисками SAS, находящимися в RAID 5.
Устройство (appliance) 2 ТБ укомплектовано 6 дисками SATA, находящимися в RAID 10.
Доукомплектовать устройства дисками невозможно, если закуплено устройство в 1 ТБ и понадобится расширить емкость, придется закупать новое устройство. При этом объединить в RAIN архитектуру устройства разного объема невозможно.
В архитектуре RAIN есть роли storage node и utility node. Utility node не хранит информации, в нем 2 диска в RAID 1.
ПО можно ставить только на довольно узкий список поддерживаемых серверов. Для Avamar 4.X cейчас поддерживаются:
Dell PowerEdge 2950III, HP DL320s, HP DL360 G5 c MSA 60, HP DL365 с MSA60, HP DL380 G5, HP DL385 G2, IBM x3650.
Процессоры поддерживаются только 64-bit.
AVE - Avamar Virtual Engine версия 1,2 Требует 64-битного процессора.
AVD - виртуальная машина для демонстрации, позволяет сохранить около 10 ГБ - дедуплицированных данных. Запускается на VMWare workstation, требует 1 ГБ оперативной памяти. Работает на 32-битных процессорах.
Виртуальная машина с Avamar может быть 0,5 - 1 - 2 ТБ. Требует соответственно 3 - 4 - 16 ГБ RAM.
Процессор строго 64-бит .
Avamar проверяет сохраненные данные в фоновом режиме после окончания плановых резервных сессий резервного копирования. При этом некоторые служебные процессы (garbage collection) не должны пересекаться с сессиями резервного копирования во времени.
Дедупликация происходит на клиенте. Алгоритм работы ПО на клиенте следующий.
1. При помощи алгоритма Sticky-byte Factoring (вычисление бегущего хэша в 32 бита) выделяются сегменты из сохраняемых данных. Размер сегментов - от одного байта до 64 КБ.
2. Сжатие сегментов
3. Вычисление хэша SHA-1 (20 байт) для каждого сжатого сегмента и файлов целиком.
4. Commonality Factoring - запрос сервера Avamar на наличие в нем уникального сегмента.
5. Передача уникальных сегментов и метаданных на сервер Avamar.
На клиенте содержатся 2 файла с кэшем хэшей -
f_cahe.dat - содержит хэши файлов и метаданные
p_cache.dat - хэши фрагментов, отправленных на сервер
Рекомендуют устанавливать размер файлов f_cahe.dat в 1/8 от объема RAM а p_cache.dat 1/16 от объема RAM. При резервном копировании эти файлы выгружаются в RAM.
Root hash - хэш файла, его уникальный идентификатор.
Скорость работы клиентского приложения - сканирование примерно 1 млн объектов в час. Скорость резервного копирования - около 100 ГБ/час. Восстановление проходит дольше - около 25 ГБ в час (до 40 ГБ в час). Сильно зависит от типа данных.
После первичной дедупликации отсекается около 30 % данных. Для оценки первичной дедупликации есть вспомогательное ПО - avasst.exe Это набор скриптов, которые запускают клиента avamar и подсчитывают процент уникальных сегментов.
Если данные забьют хранилище сервера, он перейдет в режим Read Only. После этого требуется вручную запускать процесс очистки (garbage collection).
При резервном копировании данных файловой системы 15 рабочих станций, (копировали все кроме программ и windows) дедупликация получилась 1:20 (на 300 ГБ хранились 5,7 ТБ полезных данных).
На 1 узел максимально возможно 18 одновременных сессий их которых 17 сессий используется для клиентов и 1 для репликации.
Общего места на дисковой подсистеме требуется в 1,5 раза больше, чем доступно для хранения дедуплицированных данных резервного копирования. Это связано с проверкой данных в фоновом режиме и хранении двух check point.
Данные Avamar хранятся в специализированной базе данных GSAN. Ее элементы называются stipe, их максимальный размер - 360 МБ. После прохождения процесса Garbage Collection ненужные блоки помечаются, но не удаляются. Для высвобождения места должен пройти процесс crunch - формирования новых страйпов или сжатие старого страйпа без копирования.
65 % дискового пространства на сервере Avamar отводятся для хранения данных, выше этого объема система переходит в режим read-only. (например, при лицензировании на 1 ТБ, 1 ТБ -
Это 65 % от общей емкости дисковой подсистемы).
Рекомендуется применять Avamar при активности изменения файлов не более 5% за день. Avamar неоптимально работает с аудио, видео, архивами, мультиплексированными данными.
Рекомендуют подвергать резервному копированию не более 2 ТБ на одном клиенте. Максимальный объем дедуплицированных данных, хранимых в RAIN Avamar - 32 ТБ.
Конкурент Avamar - Pure Disk. У него лицензии дешевле, но взимаются за объем до дедупликации. У Avamar лицензии считаются после дедупликации.
