Не так давно в рамках тестирования продуктовых линеек EMC мне довелось поработать с их решением EMC Avamar Virtual Edition. Этим опытом я и хочу поделиться с вами в этой публикации.
История проблемы
Пообщавшись с коллегами с различных компаний, я сделал вывод, что многие пренебрегают резервным копированием рабочих станций сотрудников компании, ограничиваясь лишь копированием продакшн-приложений.
С одной стороны, это понятно — даже для «боевых» сервисов еще не так много устоявшихся практик, «пошедших в массы». Поэтому обеспечение хороших показателей RTO и RPO для критичных сервисов является одной из основных головных болей ИТ-отделов как крупных, так и средних компаний. Уделять же время такой мелочи, как резервное копирование пользовательских машин — это непозволительная роскошь.
Однако, на практике это означает, что поломка рабочей станции приводит либо к переносу жестких дисков из старого устройства в новое (с последующими сложностями по инвентаризации и учету), либо к полной утере пользовательских данных.
Безусловно, уже давно считается хорошим тоном хранить важные данные на NAS-серверах иили корпоративных файлообменниках. В этом случае вся важная информация сохраняется, однако теряются временныенекритичные данные. Плюс ко всему после замены железа пользователю придется заново персонализировать свое рабочее место, что не прибавит ему хорошего настроения.
Возможно, в масштабах бизнеса это не является чем-то важным, однако на практике приводит к операционным задержкам, увеличивает время простоя в случае поломки и банально повышает напряженность между ИТ-отделом и внутренними заказчиками. А последнее — это немаловажный фактор, на который многие руководители ИТ-отделов незаслуженно не обращают внимания.
Пути решения
Эту задачу можно решать несколькими способами:
1. Оставить все как есть;
2. Виртуализировать рабочие места сотрудников;
3. Внедрять сервисы по резервному копированию рабочих мест.
Безусловно, 2-й сценарий дает максимальные преимущества, которые уже не раз были расписаны и доказаны в различных источниках. Однако, это достаточно дорогое в реализации решение. А переход от «классической» схемы организации рабочего места к виртуализированной связан с большим количеством сложностей, как технических, так и операционных.
С другой стороны, средства по централизованному резервному копированию более просты в реализации, не требуют кардинального перестроения инфраструктуры и зачастую более бюджетные.
Что нам может предложить EMC?
Недавно в компании EMC произошли значительные структурные изменения, результатом которых, в том числе, стало создание (читай «объединение») нового департамента DPAD — Data Protection and Availability Department. Как видно из названия, в данный департамент входят решения по организации защиты и доступности данных. Пока что нам интересны именно решения по защите.
Итак, на данный момент EMC DPAD может предложить нам 3 решения по резервному копированию данных: DataDomain, Networker, Avamar. В этой статье я сконцентрируюсь на описании решения EMC Avamar. Однако, пару слов по каждому продукту все же следует сказать.
Networker
ПО для централизованного резервного копирования и восстановления данных. Он имеет широкий функционал по автоматизации, централизованному управлению и мониторингу. И в целом, оптимизирован для работы с большими и сложными инфраструктурами.
DataDomain
Аппаратное решение для хранения резервных копий, основанное на технологии VTL (Virtual Tape Library). Не имея собственных средств по резервному копированию, оно требует отдельного ПО для резервного копирования, например Networker. Сейчас набирает популярность технология DD Boost — передовой интерфейс транспортировки дедуплицированных данных и управления системами DataDomain.
Avamar
Программно-аппаратное решение, предназначенное для создания и хранения резервных копий рабочих станций и средненизко нагруженных сервисов и приложений.
Как это работает?
Avamar работает по классической схеме сервер-клиент. На защищаемые машины устанавливаются клиентские приложения, которые производят сбор, дедупликацию (исключение повторяющихся данных) и передачу данных.
Поэтому копирование всегда инкрементальное — т.е. вначале система делает полную копию данных, а потом только изменяющиеся блоки. Это позволяет значительно снизить нагрузку на канал и затраты по емкости хранилища. Чтобы не запутаться в инкрементальных копиях, Avamar хранит у себя синтетические полные резервные копии.
И ключевым принципом работы Avamar'а как раз и является его алгоритм дедупликации.
Если в двух словах, то данная технология позволяет исключить лишнюю передачу данных не только с конкретного компьютера, но и со всех источников, резервные копии которых уже были сделаны.
Ниже чуть более подробно расписан алгоритм дедуплицирования, применяемый Avamar.
У Avamar’а дедупликация происходти на клиенте, так сказать «на источнике» данных.
Для примера разберем задание на резервное копирование абсолютно нового файла, который ни разу ни кем не бэкапился:
1) Пришло задание на бэкап;
2) Клиентом Avamar’a запускается процесс avtar.exe, который и занимается дальнейшим процессом дедупликации, и сначала вся обработка будет происходить на файловом уровне;
3) Используя алгоритм SHA-1, подсчитывается 160-битное хэш-значение файла;
4) Avtar ищет полученный хэш в своей базе файловых хэшей — F_cache.dat. Он находится на клиенте, например в C:Program Filesavsvar. И во время бэкапа F_cache.dat полностью выгружается в оперативную память;
5) Так как наш файл новый, его хэш не будет найдет в F_cache.dat на клиенте, и тогда поиск будет производится на стороне сервера Avamar’a в таком же F_cache.dat, но там собрана уже база хэшей со всех предыдущих бэкапов, всех рабочих станций;
6) Но и там хэш-значение не найдется. Тогда avtar процесс переходит на блочный уровень и мы уже говорим о бэкапе блоков данных;
7) Данные разбиваются на сегменты различной длинны от 1 Б до 64 КБ, в среднем по 25 КБ;
8) После этого сегменты сжимаются на 30 — 50 %, при этом, если сегмент не сжимается больше чем на 25% — дальнейшая его обработка происходит без сжатия;
9) Высчитываются 160-битные хэши для каждого сжатого/несжимаемого сегмента;
10) хэши объединяются в композиты по 8 000 — 30 000 хэшей;
11) далее высчитываются хэши композитов хэшей;
12) хэши композитов хэшей снова объединяются в композиты;
13) и высчитывается большой рут-хэш – это хэш композита хэшей композитов хэшей
14) Полученное рут-хэш-значение avtar ищет в своей базе уже блочных хэшей – P_cache.dat.
15) Если рут-хэш на клиенте не найден, поиск будет происходить на стороне сервера Avamar;
16) Если рут-хэш не найден и на сервере Avamar, то поиск уже происходит по хэшу композитов хэшей, опять сначала на клиенте, потом на сервере;
17) И так далее пока не будет найден хоть какой нибудь хэш;
18) Только после того, как будут найдены все уникальные блоки данных, хэши которых ни где не записаны, начнется передача данных с рабочей станции на сервер авамара;
19) На сервере авамара только что забэкапленная связка «блок данных – хэш» записываются под своим уникальным индексом;
20) Создается карта бэкапа – это ссылки на файлы и блоки;
21) И все это оформляется в базу данных PostgreSQL;
22) Записывается номер задания на бэкап, по которому в дальнейшем определяется с какого клиента было произведено резервное копирование, время для хранения бэкапа, дерево индексов, карты бакапа и т.д. и т.п.
Такой алгоритм имеет две стороны медали:
1. Это позволяет значительно экономить на ширине канала передачи данных и позволяет производить резервное копирование даже с источников на удаленной площадке (пример: рабочие станции филиальной сети).
2. Но дедупликация на источнике забирает примерно 5-10% от производительности процессора и объёма оперативной памяти. Для сервера это может быть довольно таки критичной цифрой, но для рабочих станций будет незаметно.
При интеграции с EMC DataDomain, сервер сохраняет на своем локальном хранилище только метаданные, а сами данные уже в сжатом после дедупликации виде помещаются на DataDomain. Работает такая схема по использующейся в DD технологии DDboost.
Процедура восстановления происходит по следующей схеме:
В общем случае, нам необходимо новоепочиненное устройство с установленной ОС и клиентом Avamar'a. Исключением являются устройства с ОС Windows: ее файловая система с загрузочным разделом может быть включена в резервную копию, что позволит разворачивать резервную копию на «голое железо», используя утилиту baremetal.
Архитектура
Так как Avamar представляет собой сочетание Программного и Аппаратного продуктов, каждое решение формируется из набора различных узлов – нод. Нода — это хост с развернутым на нем Avamar (управляющая нода) или дисковое хранилище (стораджовые ноды).
Есть AVAMAR Grid, бывает как в виде одноузловой конфигурации (в таком случае это одна Storage Node), так и в конфигурации типа RAIN (redundant array of independent nodes)
Более подробно про типы нод
- Utility Node — Управляет всеми необходимыми сервисами
- Storage Node — Хранит данные, бывает трёх типов — M600, M1200, и M2400
- Spare Node — Резервная нода на случай выхода из строя сторадж ноды, активируется и вводится в работу вручную
- NDMP Node — Нода для работы Авамара по протоколу NDMP
- Media Access node — Узел для подключения ленточных устройств
Кроме этого, EMC предлагает своим клиентам виртуальную модель исполнения — AVE (Avamar Virtual Edition). Для этого необходимо иметь гипервизор, на котором и будет развернута Виртуальная машина с сервером Avamar. В качестве места хранения бэкапов будет использован datastore виртуального кластера либо внешние СХД.
Виртуальный Avamar доступен в нескольких версиях — на 0.5ТБ; 1ТБ; 2ТБ; 4ТБ полезного объёма. Регулируется это приобретенной компанией лицензией.
Кроме того, EMC гарантирует удобную интеграцию AVE с VMWare в качестве рекомендуемого гипервизора и EMC DataDomain в качестве рекомендуемого хранилища.
Мне довелось работать и с AVAMAR Grid и с Avamar Virtual Edition.
А так как у ЕМС имеется триальная демо версия Avamar Virtual Edition, я расскажу, как её установить.
Процесс установки Avamar Virtual Appliance
При наличии поднятого кластера VMWare установка проходит достаточно просто:
1. Разворачиваем скачанный с партнерского ресурса EMC .ovf образ и .vmdk диск виртуальной машины с инсталляционными пакетами внутри.
2. В зависимости от версии AVE, создаем необходимое количество виртуальных дисков и подключаем их к ВМ с AVE. В нашем случае это 3 диска по 250 Гбайт.
3. После развертывания и запуска ВМ мы получаем «голую» SUSE Linux Enterprise, но со всеми необходимыми репозиториями внутри. Подключение к ней осуществляется через виртуальную консоль vSphere, а управление через консоль. Скриптом /usr/local/avamar/bin/ave-part.pl подготавливаем ОС к установке на неё Avamar'a.
4. Настраиваем сетевые интерфейсы. Проще всего это сделать при помощи утилиты dpnnetutil, она уже есть в составе виртуалки, но можно и с помощью YaST2. После окончания настройки сетевых интерфейсов ВМ необходимо перезагрузить.
5. Разворачиваем мастер установки AVE командой ./usr/local/avamar/src/avinstaller-bootstrap-version.sles11_64.x86_64.run. После чего запускаем его. Мастер установки имеет удобный web-интерфейс: Avamar_Server_IP:8543/avi/avigui.html.
Процесс установки и настройки Avamar займет продолжительное время и потребует участия пользователя:
8. После завершения установки в веб интерфейсе, в консоли выполняем завершающий скрипт
./usr/local/avamar/bin/ave-post.sh
9. В конце установки сервера нам необходимо скачать и установить управляющую консоль. Для этого достаточно просто открыть в браузере IP-адрес сервера (который вы устанавливаете на шаге 4). С помощью web-интерфейса можно скачать и клиент под различные ОС, а также baremetal утилиту для ОС Windows. Там же и вся необходимая документация по всему, что умеет Авамар.
Управление
Вот так выглядит консоль администратора установленного Avamar:
Добавление клиентов
Администратору предлагается несколько сценариев по активации (добавлению) клиентов. В любом из них изначально требуется установить клиент на защищаемую машину.
После этого возможны следующие сценарии:
1. Пользователь может сам через клиент направить запрос на активацию:
2. Администратор может активировать клиенты «поштучно», направляя им команду на активацию через указание его IP-адреса.
3. Администратор может активировать пул клиентов, указав пул IP-адресов.
При первом сценарии клиент будет автоматически добавлен в корневой домен, и к нему будет применена дефолтная политика. При втором и третьем сценариях администратор может заранее определить домен и политику для добавляемых клиентов.
Домены
Концепция централизованного управления включает в себя объединение в иерархические «домены» (не путать со службой Windows AD). По сути, это просто древовидная структура папок, включающая в себя перечень клиентов, политики их копирования, пользователей и делегированные им права.
Таким образом, вы можете объединять защищаемые устройства в различные группы со своими политиками копирования и ограничивать к ним доступ разных пользователей.
Пример:
У вас есть root-пользователь, имеющий доступ к корневому домену, т.е. ко всем клиентам.
Далее вы разделяете всех пользователей по отделам — продажи, маркетинг, склад, логистика и т.д.
Для каждого домена (отдела) вы можете назначить пользователя, руководящего политиками копирования. А можете руководить копированием всех отделов лично.
При этом пользователи имеют разные уровни доступа: просмотр состояния, только копирование, только восстановление, полный доступ. Т.е. начальник отдела может иметь право на запуск незапланированного резервного копирования, а остальные сотрудники только на восстановление из имеющихся копий.
Для управления процессом копирования администратор резервного копирования должен установить себе консоль администратора.
Пользователи же могут только просматривать и восстанавливать только свои данные.
Для этого используется web-интерфейс, открываемый через установленный на устройство клиент.
Политики
Политиками копирования определяются все свойства резервного копирования:
Расписание
Maintenance window
В maintenance window входит создание Checkpoints, проверка Checkpoints, garbage collection.
Немного про Checkpoints — это резервное копирование сервером самого себя. В случае падения хоставиртуальной машины по этим Checkpoints в дальнейшем можно будет восстановить управляющий сервер без потери данных, сохраненных клиентов, пользователей, доменов и политик.
Объекты копирования
Время хранения копий
Вы можете назначить систематическое резервное копирование на любое время любого дня, выбрать хранилище и т.д. Есть поддержка большинства ОС, что позволяет выбирать конкретные директории для копирования. Это позволяет защищать только нужные данные, уменьшая затраты на хранение ненужных копий.
Кроме того, при создании политики вы можете указать срок «устаревания» копии. По истечении этого срока копия будет считаться «просроченной» и удалена с хранилища.
Интеграция с VMware
Avamar позволяет копировать виртуальные машины, запущенные на гипервизоре VMware vSphere ESXi. Для этого нет необходимости устанавливать клиенты на каждую ВМ. Достаточно развернуть виртуальную машину в кластере, которая будет выполнять роль клиента для всего гипервизора. Называется она proxy AVAMAR, и для резервного копирования использует технологию VCB. Для интеграции Avamar с ESXi обязательным условием является наличие vCenter.
Дистрибутив proxy AVAMAR доступен через web-интерфейс и представляет собой .ova файл.
После развертывания .ova и загрузки системы сразу стартует скрипт по настройке сетевых интерфейсов виртуальной машинки
Потом необходимо на ВМ c сервером Avamar в файле /usr/local/avamar/var/mc/server_data/prefs/mcserver.xml написать TRUE в строчке: entry key=«allow_duplicate_client_names» value=«true»
Для тех, кто хочет копировать только виртуальные машины VMware, можно приобрести продукт VMware VADP — vStorage APIs for Data Protection. Этот продукт тоже основан на технологии VCB. По сути VADP — это Avamar, «урезанный» и заточенный под VMware. Стоит он меньше чем EMC AVE, так как в нем оставлен только функционал по резервному копированию виртуальных машин.
Интеграция с DataDomain на примере DataDomain160
При интеграции Avamar c DD, DD используется только под хранение самих резервных копий, все метаданные и кэши остаются на сервере Avamar'a. Данные при этом будут передаваться по протоколу DDBoost.
Для начала необходимо создать в DD пользователя для Avamar'а:
Далее в Avamar Administrator, во вкладке Server, выбираем Server Management и нажимаем на кнопку Actions > Add Data Domain System.
Заполняем все предложенные поля, для проверки количества поддерживаемых потоков нажимаем Get Stream Info.
Переходим в этом же окне во вкладку SNMP. По данному протоколу сервер Avamar будет получать информацию о состоянии DD.
В результате мы видим добавленную систему:
Далее надо не забыть в настройках DataSet поставить галочку «хранить резервные копии на DD»
Резюмируя
Основными преимуществами продукта по резервному копированию и восстановлению данных EMC Avamar являются:
1. Универсальность — поддержка большинства коммерческих ОС, БД и сервисов.
2. Гибкость — различные конфигурации, включающие в себя виртуальную версию для VMware vSphere.
3. Простота в использовании — удобный клиентский интерфейс и интеграция с VMware vSphere.
4. Экономичность — ощутимая экономия на требованиях к пропускной способности канала данных за счет использования дедупликации на клиенте.
Таким образом, имея штат сотрудников от 50 человек, мы можем достаточно просто реализовать резервное копирование их устройств.
В большинстве случаев, при наличии виртуализированной инфраструктуры будет достаточно Avamar VE (virtual Appliance) и места в хранилище под копии.
Это позволит осуществить централизованное автоматическое резервное копирование без особых технических сложностей и затрат на квалифицированных сотрудников.
А процедура восстановления утраченных пользовательских данных сократится до замены однотипных рабочих станций и нажатия нескольких кнопок в административной консоли.
Автор: MEzhov
