Привет, Хабр! На связи Алексей Зотов из К2Тех, и у меня для вас свежий обзор на железо. Сегодня пришла очередь СХД для бэкапов от ExaGrid — это продукт с продвинутым функционалом дедупликации на хранилище и отдельной фишкой в виде удивительно большого кэша. Под катом вас ждут первое впечатление, результаты тестирования и выводы об этой системе.

В целом, ExaGrid можно рассматривать как замену или альтернативу для Dell DataDomain и HPE StoreOnce. Это такая же стоечная СХД, которую можно подключить к серверам по CIFS/NFS или через плагин и сохранять на нее бэкапы, например, сразу от нескольких СРК. 

Основной фишкой системы является двухуровневое хранение данных:

• Горячее хранение. По умолчанию ExaGrid забирает под хранение данных без оптимизации 50% места в системе. Это любопытное решение, потому что при восстановлении данных в итоге не требуется процесс регидрации (процесс, обратный дедупликации, который как известно требует значительных ресурсов, как следствие, более долгое восстановление). А также это обеспечивает дополнительную отказоустойчивость, ведь кэш – это единственное доступное пространство извне. У старших моделей, кстати, кэш на более быстрых SSD дисках.

• Холодное хранение. Это как раз уже внутреннее пространство, где хранятся данные уже в дедуплицированном виде, только сама система может производить операции чтения/записи в этом разделе. Внешнего доступа ни у кого нет (ни у админа, ни у софта бэкапа, ни у вируса/потенциального злоумышленника).

Установка

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

ExaGrid с завода настроен так, что NIC2 имеет статический адрес 192.168.0.5, а NIC1 завязан на DHCP (в нашем случае мы подключались с ноутбука прямо в лабе к NIC2). При первом входе запускается мастер настройки системы и окружения с базовыми в общем-то вопросами (hostname, IP и т.д.). По окончанию настройки система перезагружается и появляется доступ к дальнейшей конфигурации. 

Основной интерфейс системы делится на несколько уровней и выглядит так:

Что здесь любопытно — часть функционала закрыта от администратора. Для доступа необходимы специальная учетная запись Support и отдельный пароль, который автоматически генерируется системой:

Если вы заметили, из одной консоли можно управлять всеми системами одновременно. И в терминологии ExaGrid можно создать «Site» — логическое объединение нескольких массивов.

Есть также интерфейс IPMI, который может выручить в определенных ситуациях, но он полностью стандартный и фокусировать на нем внимание я не буду:

Настройка и тестирование

Разработчики ExaGrid позаботились о том, чтобы СХД работала с различными системами резервного копирования. Система умеет интегрироваться с Veritas NetBackup через специальный плагин по протоколу OpenStorage (OST). А также c Veeam через решение ExaGrid-Veeam Accelerated Data Mover. Для остальных же решений подключение возможно через универсальные CIFS/NFS. 

Чтобы проверить, насколько хорошо это все работает, я собрал тестовый стенд с ExaGrid EX18 и подключил к нему сразу четыре системы резервного копирования:

• NetBackup и Veeam как основной формат интеграции; 

• Кибер Бэкап – представитель от России, отвечающий требованиям импортозамещения;

• Vinchin – китайская СРК, которой в последнее время все чаще интересуются на рынке.

В качестве исходных данных у нас выступает ферма виртуализации VMWare и пара БД MS SQL. Схема стенда представлена ниже:

Подключение СРК

Начнем с наиболее простых систем – Кибер Бэкапа и Vinchin. Создание новой шары (а в терминологии вендора любое пространство – это шара, аналог MTree на DataDomain) требует настройки Network Access Policy (NAP), где указывается сетевая доступность, как это выглядит у нас для NFS:

Для CIFS же, помимо этого, дополнительно требуется User Access Policy (UAP) – политика доступа для конкретного юзера к конкретной шаре. Поэтому сначала создаем локальных бэкапных пользователей:

А потом связываем их с шарой:

Со стороны серверов резервного копирования

1. Vinchin (NFS)

Добавляется стандартное NFS хранилище:

После чего оно становится доступным для бэкапа:

2. Кибер Бэкап (CIFS)

Добавляем сетевой каталог через узел хранения: 

После чего хранилище становится доступным для бэкапов:

3. NetBackup (OST)

Далее чуть сложнее – NetBackup. Первый шаг схож – создаем NAP, но в протоколе уже выбираем OST:

После чего нужно скачать плагин из веб-интерфейса (Help > Online Library) и поставить его на медиа-сервер согласно инструкции:

• Запускаем установщик;

• Вписываем IP;

• После этого все добавится в автоматическом режиме, включая IP второго интерфейса и имя сайта:

Далее необходимо настроить новый Storage Server, что в целом стандартно:

И дисковый пул:

На выходе получаем систему, которая понимает технологии NBU – Optimized Deduplication, A.I.R. и Accelerator, с киллер фичей в виде хранения данных без дедупа в кэше для возможности более быстрого восстановления. Причем каждый новый бэкап будет ре-синтезирован в полный бэкап.

4. Veeam (ADM)

И последняя СРК в наших тестах – Veeam. Первый шаг не меняется, нужно создать шару с правильным типом и протоколом:

После чего со стороны Veeam добавляется новый репозиторий как устройство с дедупликацией:

Все здесь достаточно стандартно, но в требованиях указано отключить оптимизацию самого вима:

Система это проверит дополнительно на следующем шаге:

Как это выглядит в самой СРК:

По итогу получаем систему соответствующего типа с поддержкой Veeam Data Mover, а наличие кэша позволяет использовать такой функционал как Sure Backup, Virtual Lab, Instant VM Recovery, Copy and Replicate прямо из коробки.

Спустя несколько недель тестов всех вышеописанных СРК, получил коэффициент дедупликации – 22:

Немного деталей об этой статистике:

• Site Capacity – 36 ТБ, это общий объем СХД (система, напомню, у нас EX18);

• Landing Zone – 18 ТБ выделено под кэш;

• Retention Allocation – 17.83 ТБ выделено для данных;

• Primary Retention – 524 ГБ данных находятся в зоне хранения (после всех оптимизаций);

• System Reserved – 65 ГБ ушло на системные нужды.

Проверка отказоустойчивости и сохранности данных 

А теперь, пожалуй, перейдем к самому интересному – проверка отказоустойчивости кэша. Как ранее было сказано – Retention Zone недоступна извне, благодаря чему потеря Landing Zone не является критичной. Для проверки я сделал доп шару /cyber2, дали ей доступ к серверу Кибер Бэкапа и создали один .txt файлик:

Спустя пару дней этот файлик мы удалили:

Чтобы его вернуть выполняем следующее – останавливаем шары:

Соглашаемся с предупреждением от системы:

Когда все шары переходят в статус Suspended, становится доступной кнопка Point in Time Recover:

Далее выбирается дата отката и запускается процесс:

По результатам шара перейдет в статус Point Recovered и данные снова будут доступны:

Немного о мониторинге

Система умеет отправлять письма (SMTP), работать с SNMP трапами и интегрируется с syslog. В консоли имеется стандартный журнал событий и алерты:

Также есть несколько дополнительных графиков – статистика хранения:

И скорость передачи:

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

Выводы

Знакомство с ExaGrid показало, что мы имеем дело с хорошей СХД, заточенной под резервное копирование. Особая фишка массива — это кэш, который обеспечивает как повышенную отказоустойчивость, так и положительно влияет на скорость работы РК. 

Отдельно хочу отметить продвинутый функционал дедупликации, который позволяет рассматривать ExaGrid как конкурента Dell DataDomain и HPE StoreOnce. Бонусом система умеет полноценно интегрироваться с Veeam и Veritas NetBackup, что позволяет улучшить процессы как резервного копирования, так и восстановления. 

Для других СРК, в том числе из стека импортозамещения, предусмотрена упрощенная интеграция. Мы с вами увидели хороший кейс для использования ExaGrid с Кибер Бэкапом, любые клиенты которого умеют самостоятельно записывать данные на CIFS/NFS шару без использования узла хранения. С учетом дедупликации, оперативной и защищенной зон, может получиться интересное решение. А один из минусов СХД ExaGrid — это, пожалуй, отсутствие эмуляции виртуальной ленточной библиотеки (VTL), которой кому-то может не хватить. 

Как итог, система отлично подойдет в качестве первичного хранилища резервных копий с потенциальной возможностью горизонтального масштабирования и построения Data recovery. Благодаря Landing Zone восстановление будет выполняться быстрее конкурентов, в то время как Retention Zone позволяет безопасно и оптимально хранить данные. 

Почитать больше о железе:

Мир. Труд. Майпу. Или как мы тестировали китайскую СХД

Знай наших! Обзор сервера Аквариус T50 D224CF R52