EMC AVAMAR - система резервного копирования с глобальной дедупликацией на стороне клиента

Ниже приведены заметки о системе распределенного резервного копирования с дедупликацией данных на стороне клиентов 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 лицензии считаются после дедупликации.