Тестируем СХД ExaGrid EX18: получилось ли заменить Dell DataDomain и HPE StoreOnce?
Привет, Хабр! На связи Алексей Зотов из К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
