Привет, Хабр!
Это вторая часть с результатами наших тестов китайского массива. В первом посте мы рассказали, как проходили нагрузочные испытания и проверка на отказоустойчивость. В этой части поделимся результатами функциональных тестов модели Maipu MPS5580G2. Разберем его ключевые возможности: репликацию, метрокластер, QoS, снепшоты, мониторинг и безопасность. Ведь именно для этого в тест мы взяли не один массив, а сразу два!
Массив имеет джентльменский набор в виде функций, к которым мы привыкли в нашем любимом еnterprise. Некоторые из этих функций мы упомянем коротко, а на некоторых остановимся чуть детальнее. Отчет у нас получится большой, много деталей на Хабр не выложить. Поэтому, если у вас будут вопросы или появится желание протестировать массив, пишите на infrastructure@jet.su.
Итак, дисковый массив поставляется с двумя обязательными лицензиями — это базовая MPSXXXX Storage Platform Software (Support FC, iSCSI Protocol, Including Basic Storage Management, CRAID, System Monitoring, Log and Alarm Functions) и Advanced Performance Monitoring. Остальные лицензии на дополнительный функционал являются опциональными и гибко подбираются под задачи.
Что мы получаем с базовой лицензией?
CRAID — технология хранения и обработки данных, собственная разработка Maipu. Тут мы видим всем известные чанки и ячейки (cells), из которых уже и собираются пулы и луны.
Интуитивно понятный веб-интерфейс. Конечно, у вендора тут своя терминология, но она не вызывает разрыва шаблона, если у вас есть опыт работы с А-вендорами. Процессы по созданию любых логических сущностей — от пула, зоннинга/маппинга до репликации и метрокластера — просты и удобны.
Поддержку блочных протоколов доступа — FC и iSCSI.
Возможность создания тонких томов. Тонкие тома могут создаваться с дедупом и с компрессией как по отдельности, так и вместе.
Возможность создания толстых томов. Использование дедупа и компрессии на них невозможно.
Для логических томов есть две настройки — ALUA и SLUA, где, как вы уже догадались, ALUA — это асимметричный доступ к логическим томам (пути через другой контроллер будут неоптимальными), а SLUA — симметричный доступ, где все пути до логических томов оптимальны.
Мы знаем, что вы скучаете по таким мелочам
По умолчанию login timeout не настроен, но его настройка возможна в принципе.
Создание разных типов пользователей (Local user, LDAP user, LDAP user group), с разными ролями (Common admin, Monitor admin) и методами входа (WEB, CLI, RESTful).
Гибкая система ролей, имеющая достаточно большое количество объектов.
Возможность отслеживать все события. Во вкладке «Concerns» даются рекомендации по устранению проблем.
Возможность отслеживания событий (как логических, так и физических), выгрузка их в dump для анализа.
Возможность отслеживать выполненные действия разных пользователей, глубокое и понятное описание.
Возможность отслеживать запущенные задания и их статус, например, создание/изменение снепшотов, под каким пользователем выполняется это действие, время старта и завершения.
Возможность отправки нотификаций в почту по протоколу SMTP.
Возможность отправки нотификаций по протоколу SNMP (от v1 до v3) во внешние системы мониторинга.
Возможность настройки исключений для оповещений для разных типов объектов.
Возможность отложенных оповещений, например, в случае ложных срабатываний.
Огромный список типов событий и нотификаций, доступных к отправке. Статусы отдельных компонентов (диски, полки и т.д.) можно отправлять на разные приемники (включать подсветку, отправлять по SMTP, SNMP или все сразу).
В веб-интерфейсе есть удобные встроенные средства по информации о статусе конкретного оптического модуля и ошибок на портах.
В массив встроены пречеки основных компонентов перед обновлением прошивки. Мы не обновлялись (не было повода), но это очень хороший признак.
Что с настройками безопасности?
В дисковом массиве есть опция установки срока действия пароля, контроля количества попыток входа и задания временного периода для авторизации. Это удобно для ограничения рабочего времени и отслеживания (изоляции) ИБ-инцидентов. Также можно ограничить управление массивом, указав конкретные адреса для доступа (например, АРМ администраторов СХД), интегрировать с LDAP и настраивать глобальные параметры кеша на запись с возможностью изменения его размера).
Что с мониторингом?
Встроенный веб-интерфейс массива обладает кучей разных крутилок для анализа перформанса. Часть графиков вы уже видели в первой части, другая часть будет показана ниже. Есть возможность выгрузки исторических отчетов в CSV-формате с нужными метриками для парсинга.
Также имеется редкий встроенный функционал с предсказанием производительности на неделю или на месяц на основе имеющихся данных как для одного контроллера, так и для двух. Например, после ряда наших тестов прогноз на следующую неделю выглядел вот так. Среди зарубежных решений такой функционал встречается не часто, и обычно он реализован в виде отдельного ПО (иногда и за отдельные деньги). Но в случае Maipu — это как печенька с предсказаниями!
В массиве можно создать политики по качеству сервиса (QoS) и установить его как сверху (не более чем…), так и снизу (не менее чем…) на конкретный том или на группу томов. В рамках тестирования этой функции QoS-политика на один логический том отработала без проблем. QoS можно установить как на пропускную способность, так и на IOPS. Причем как на чтение, так и на запись!
Политику QoS можно задавать по расписанию, или оставить ее всегда включенной, или задать промежуток (конкретные дни, временной интервал). Это полезная функция для гарантии производительности, например, высоконагруженных приложений и их резервного копирования.
Функционал расширенный
Дедупликация и компрессия работают на тонких томах, режим работы — онлайн. Включается она автоматически на этапе создания пула (размеры блока — 8,16к). Менять их после создания нельзя, рекомендуется оставлять дефолтное значение 16к). Этот функционал лицензируется отдельно.
DDSR (Data Duplicate Shared Resource) — функционал, который управляет пространством хранения с учетом гранулярности пула хранения. После включения DDSR все новые тонкие тома, созданные в пуле хранения, будут использовать DDSR для хранения данных в соответствии с гранулярностью пула хранения. Это позволяет оптимизировать общее использование ресурсов и производительность пула хранения.
Только пулы хранения all-flash поддерживают включение DDSR, он включен по умолчанию при создании такого пула.
При включении DDSR для устройства с двумя контроллерами требуется, чтобы нераспределенная емкость пула хранения была больше или равна 5 ТБ. Для устройства с четырьмя контроллерами — больше или равна 10 ТБ.
Снепшоты работают по технологии ROW (Redirect on Write), что не должно оказывать влияния на производительность, или оно (влияние) должно быть минимально. Этот функционал лицензируется отдельно.
Включение снепшота на логическом томе изображено на рисунке ниже.
Возможность гибкой настройки — емкость, количество точек и политика с очень гибким расписанием.
В данном сценарии точки были созданы вручную.
Автоснепы каждые пять минут. Один том
В рамках этой проверки был запущен профиль нагрузки на чтение-запись, указанный на рисунке ниже. Продолжительность — 30 минут, исследуемый объект — один логический том. Производительность на старте со стороны массива.
Снепшоты создаются по расписанию: один раз в пять минут (остальные настройки без изменений). Влияния на производительность не замечено.
Автоснепы каждые пять минут. Восемь томов
В условиях этой проверки был запущен профиль нагрузки на чтение-запись, указанный на рисунке выше. Продолжительность — 30 минут, исследуемый объект — 8 логических томов и 9 точек.
Увеличение количества снепшотов с 8 до 50 штук в режиме онлайн было выполнено без проблем.
Дополнительно в рамках проверки был запущен профиль нагрузки на чтение-запись, указанный на рисунке выше. Был подключен профиль QoS на один логический том. IOPS упали примерно на 20–25% (это отработал QoS), время отклика увеличилось с 0,3 до 0,5 мс. BW упал примерно с 4,8 до 3,6 ГБ/сек. Нагрузка на CPU контроллеров не изменилась.
Группы консистентности
Группа консистентности (Consistency Group, CG) в дисковых массивах — это, как правило, логическая группа томов, которые синхронизируются между собой для обеспечения согласованности данных при репликации или создании моментальных снимков, например, банковская транзакция записывается в несколько томов (данные + журналы). Если репликация выполняется без группы консистентности, может возникнуть рассинхронизация. CG гарантирует, что-либо все блоки данных скопированы, либо ни одного.
На дисковом массиве Storage-A была создана группа консистентности, состоящая из восьми тонких логических томов объемом 6 ТБ каждый. На дисковом массиве Storage-B была выполнена аналогичная настройка. Отношение томов между собой в рамках группы консистентности изображены на рисунке ниже.
После включения репликации происходит процесс сканирования исходных томов, продолжительность зависит от объема.
После запуска процесса репликации на CG производительность IOPS просела с 42k до 36k (15%). Также это было заметно со стороны ВМ в системе виртуализации. Время отклика изменилось незначительно
Отображение скорости сканирования для каждой пары томов в рамках репликации.
Статус репликации логических томов.
Окончание репликации, переход репликационных пар в режим Idle.
Репликация и метрокластер
Ну что же, вот и дошли до самого интересного! Мы изначально очень хотели посмотреть на то, как это работает. Причина проста. Если вы не можете использовать импортное оборудование, но вам нужен метрокластер, то на текущий момент у вас есть только один вариант — конфигурация от «Аэродиска». Поэтому мы и хотели посмотреть на возможную альтернативу!
Массив предоставляет возможность использовать две политики репликации: стратегическую и адаптивную. Этот функционал лицензируется отдельно.
Стратегическая репликация. Во время начальной синхронизации все данные с массива-источника отправляются на массив-приемник, а последующие синхронизации будут только инкрементальными. Например, если репликация включена в 1:00 (политика репликации — периодическая, с циклом в один час), массив-источник и массив-приемник выполняют начальную синхронизацию, и все данные синхронизируются. В 2:00 срабатывает политика репликации, и начинается синхронизация. В этот момент синхронизируются только инкрементальные данные, то есть объем данных, изменившихся между 1:00 и 2:00.
Адаптивная репликация, или репликация в реальном времени. Как только данные на производственном хранилище меняются, они автоматически синхронизируются на резервное хранилище. В этом случае каждый I/O, записанный на основной массив, копируется на резервное хранилище в реальном времени, что минимизирует потерю данных в случае катастрофы. Если объем массива при непрерывной репликации заполняется, система автоматически переключается на стратегическую репликацию.
На массиве Storage-A для тома создается пара. Ее можно предварительно создать и на массиве Storage-B или из контекста основного массива.
Как показано на рисунке ниже, мы использовали стратегическую политику репликации.
Есть возможность устанавливать дополнительные настройки компрессии и шифрования, которые показаны на рисунке.
Производителем был подготовлен арбитр в виде виртуальной машины. На рисунке ниже отображена взаимосвязь массива Storage-A и массива Storage-B.
Проверка также выполнялась под незначительной нагрузкой (мы экспериментировали с профилями в HCIbench). Производительность на массиве Storage-A показана на рисунке. На нем изображены графики производительности массива Storage-A около 9k IOPS, время отклика, пропускная способность и загрузка контроллеров.
После этого дисковый массив Storage-A был выключен, но доступ к логическим томам по-прежнему сохранялся на чтение и запись без прерывания. При этом со стороны администратора не потребовалось никаких дополнительных действий Производительность на массиве Storage-B, на который переключился ввод-вывод, показана на рисунке. Мы видим все те же цифры по IOPS`ам и низкое время отклика!
После включения Storage-A началась синхронизация.
Со стороны виртуализации выключение массива Storage-A выглядело, как показано на рисунке.
Испытания позади, итоги перед вами
Массив имеет очень гибкие настройки по работе со снепшотами, и в наших тестах не было замечено влияния на производительность.
Функционал репликации между массивами отработал успешно как для репликации одного LUN, так и для групп консистентности.
Функционал метрокластера между массивами отработал успешно для сценария, где предполагаемая авария вызвала недоступность основного массива.
Отсутствуют собственные продукты по мультипасингу. Рекомендации по настройке под разные типы ОС найти не удалось, но использование общепринятых параметров показало достаточную степень надежности: пути не прерывались, балансировка нагрузки на портах равномерная.
Неочевидными оказались типы используемых в массиве снепшотов. В веб-интерфейсе для локальных томов отображался тип ROW, но для метрокластера в веб-интерфейсе отображался тип COW, что может быть существенным ограничением.
Предоставление хостам логических томов возможно по стандартным блочным протоколам. За время тестирования (более двух месяцев) с протоколом FC никаких проблем замечено не было, протокол iSCSI не тестировали, так как в дисковом массиве не было подходящих портов ввода-вывода.
Файловый доступ не поддерживается, но его релиз запланирован на второй квартал 2025 года.
И еще немного выводов
На наш взгляд, массивы показали себя прекрасно. Модель подходит для хранения продуктивных данных со смешанными профилями нагрузки с использованием блочных протоколов (FC) доступа и SSD-дисками.
Модель MPS5580G2 обладает широким базовым и расширенным функционалом, присущим еnterprise-сегменту, — толстые и тонкие тома, мгновенные снимки (snapshots) с использованием технологии Redirect-On-Write (что практически не влияет на производительность), контроль трафика QoS, репликация (в том числе с гибкими настойками по расписанию), метрокластер, группы консистентности, блочные протоколы доступа, клоны, возможность горизонтального масштабирования путем добавления новых контроллеров (scale out).
Также в наличии есть удобные средства по конфигурированию и управлению: простой и интуитивно понятный веб-интерфейс, графики отображения производительности как в режиме реального времени, так и исторические, утилизация энергопотребления, прогнозирование производительности и износа SSD-дисков. Большой пул настроек по управлению массивом: HA auto-recovery, Global Hot Spare, Cache Global параметры, настройки по снепшотам, дедупликации и scale out.
По результатам тестов производительности максимальные показатели дискового массива не были достигнуты из-за ряда ограничений в тестовом окружении, таких как недостаточное количество дисков, серверов и портов ввода-вывода. Но даже с учетом ограничений массив показал высокие цифры по производительности (более 150к IOPS) и стабильно низкое время отклика практически на всех случайных нагрузках.
Модель MPS5580G2 можно рассматривать как конкурентный аналог Huawei Dorado, Hitachi F series, HPE Primera, DellEMC Unity XT под задачи виртуализации и базы данных.
Maipu планирует загрузить (или уже загружает) документацию по системам хранения на свой веб-сайт, чтобы заказчики могли получить к ней доступ. Компания активно готовит страницу для обратной связи с клиентами, что поможет улучшить продукцию, оперативно собирать реальные отзывы и обеспечивать быстрое официальное реагирование.
Коллеги также поделились планами: в конце этого года они проведут базовое обучение. В следующем году будет создана система обучения для этих продуктов. Это необходимо для повышения квалификации инженеров партнеров (MCPs) и предоставления заказчикам более качественной технической поддержки. Лично мы обязательно планируем пройти эти курсы, как только официальная программа обучения станет доступной.