Привет, меня зовут Павел. Я работаю ведущим системным инженером группы внедрения в департаменте вычислительных систем компании STEP LOGIC. В этом посте я поделюсь своими наблюдениями о флеш-системе хранения данных Huawei OceanStor Dorado V6, которую мы тестировали в «полях» в инфраструктуре заказчика.
Если дальше ожидаете увидеть данные по полученным в результате тестирования показателям IOPS, то спешу разочаровать. Немного отойду от привычной схемы и сначала расскажу о результатах проверки дополнительных функций. Это позволит оценить возможности ввода в эксплуатацию и дальнейшего обслуживания глазами (и руками) системного администратора, системного инженера со стороны заказчика.
Если система хранения хороша с точки зрения IOPS и Bandwidth, но неудобна в обслуживании и не имеет набора дополнительных возможностей, которые помогают организовать поддержку, миграцию и клонирование системы (точнее ее содержимого) — это может стать камнем преткновения.
Подробно остановлюсь на функциях:
- HyperSnap — мгновенный виртуальный снимок — одна из разновидностей моментальных снимков, фиксация данных в определенный момент времени.
- HyperCDP — функция создания мгновенных снимков с высокой частотой (через малый промежуток времени).
- HyperClone создает полные копии исходных данных с использованием расписания. Механизм применяется для резервного копирования, защиты, анализа и тестирования данных. В отличие от классического моментального снимка, на создание клона требуется определенное время, клон не грузит основной LUN.
- SmartQOS позволяет настроить приоритеты ввода-вывода: повысить или понизить приоритет выделенному LUN'у и тем самым управлять скоростью обмена данными.
А о результатах тестирования производительности и отказоустойчивости я напишу во второй части.
О технических параметрах Dorado V6
СХД OceanStor Dorado V6 впервые представлена в сентябре 2019 года. В линейке продуктов пять моделей, условно распределенных на три класса — low-end (Dorado 3000), mid-end (Dorado 5000/6000) и hi-end (Dorado 8000/18000). Модели в линейке объединяет схожая архитектура, интерфейс управления и набор функций. Основные различия — в максимальной емкости и производительности.
Из отличительных особенностей — OceanStor Dorado V6 базируется на процессорах и контроллерах производства компании Huawei. Из-за санкций США Huawei вынуждены были отказаться от процессоров Intel для своих СХД, перейдя на ARM-чипы собственного производства. У флагманских моделей Dorado 8000 V6 и 18000 V6 количество ядер на контроллер переваливает за сотню, а точнее — 128 и 192 ядра соответственно. Если быть точным — сам чип Kunpeng 920 на архитектуре ARMv8.2 может иметь от 24 до 64 ядер. Такое высокое суммарное количество ядер получается путем установки нескольких подобных процессоров в 1 контроллер.
Ниже речь пойдет о Huawei OceanStor Dorado 3000 V6 (24 ядра на контроллер), которая может применяться как для вспомогательных систем и сервисов, так и в качестве основной СХД для небольших компаний.
Почему выбрана именно Dorado 3000 V6?
Как это часто бывает — младшие модели оборудования выглядят не так ярко на фоне представителей hi-end из этой же линейки и незаслуженно получают меньше внимания. Поэтому после 21 миллиона IOPS, которые были достигнуты Huawei на своей OceanStor Dorado 18000 V6, хотелось посмотреть, на что годится самая бюджетная All-flash СХД от Huawei.
Заказчик, совместно с которым проводилось тестирование, планировал купить аналогичную модель СХД, но с увеличенным суммарным «сырым» объемом и дополнительной полкой расширения (Disk Enclosure). У компании были опасения в части производительности системы, которые мы и постарались преодолеть в процессе тестирования.
Коротко о стенде для тестирования
В тесте мы использовали следующую конфигурацию Huawei OceanStor Dorado 3000 V6:
- пара контроллеров Active-Active с единым кэшем 192 Гб;
- 48 процессорных ядер, по 24 ядра на каждый контроллер;
- восемь SSD-дисков 7,68 Тб;
- две карты расширения Smart-IO 4х16Gb FC;
- две карты расширения Smart-IO 4х10Gb Ethernet.
Примечание. Dorado V6 3000, в отличие от более мощных моделей в этой же линейке, поддерживает установку только накопителей SAS 3.0. NVMe формата Palm доступны начиная с модели 5000 V6.
Рисунок 1. Фронтальная панель установленной в стойку Huawei OceanStor Dorado V6 3000.
Для чистоты эксперимента, чтобы абстрагироваться от нюансов существующей инфраструктуры, уже используемой заказчиком для рабочих целей (и не нагружать лишний раз production SAN), было принято решение подключить СХД к серверу виртуализации (VMware ESXi 6.5) напрямую двумя FC-интерфейсами. Сервер виртуализации обеспечивал работу двух виртуальных машин, в которых мы запускали утилиту генерации и измерения нагрузки VDBench (Oracle), также был установлен драйвер multipath (Huawei Ultrapath).
На СХД мы создали дисковое пространство Storage Pool (далее — SP), включающее в себя все восемь SSD дисков, с параметром отказоустойчивости RAID-6 и двумя резервными дисками Hot Spare. Диски LUN, созданные на данном SP, были подключены к виртуальным машинам как RDM-диски.
HyperSnap
HyperSnap представляет собой ни что иное, как Snapshot, созданный на LUN'е. Используется для резервного копирования, тестирования и других задач.
Важно отметить, что такой Snapshot работает по принципу ROW (redirect-on-write), вместо ранее считавшимся классическим COW (copy-on-write). Согласно этому алгоритму, новые данные не заменяют на старые, а записываются на свободное место. Такой Snapshot по сути является таблицей со ссылками. При создании снимка HyperSnap СХД записывает все сведения об изменениях в специально выделенную часть виртуального диска LUN — Metadata. Снимок HyperSnap не является полной копией данных и поэтому не занимает много места.
Собственно, алгоритм ROW — уже своего рода классика для Flash-массивов.
Рисунок 2. Отличия алгоритмов COW и ROW.
Примечание. Известные системы резервного копирования, например, от Veeam и Commvault, поддерживают интеграцию с инструментами Huawei и могут использовать Snapshot для резервного копирования, расширяя таким образом «окно бэкапа» (оптимальное время, подходящее для создания копий, когда нагрузка на систему минимальна).
Технология HyperSnap позволяет подключать созданный снимок к серверу подобно обычным логическим дискам LUN. Их можно монтировать не только на чтение, но и на чтение-запись для оперативного подключения актуальных данных к тестовой среде.
На рисунке 3 показан снимок, созданный с именем LUNGroup006_last, прародителем которого является диск LUN — LUNGroup006_000. LUNGroup006_000 при этом уже был смонтирован на одной из тестовых виртуальных машин.
Рисунок 3. Мгновенный снимок HyperSnap с именем LUNGroup006.
Подключаем его на тот же хост и следим через интерфейс фирменного драйвера MultiPath от Huawei — UltraPath. Эта функция является не только важным элементом отказоустойчивости, но и просто удобным рабочим инструментом, способным прямо с хоста однозначно определить доступные тома.
Рисунок 4. Консоль управления фирменного драйвера MultiPath от Huawei — UltraPath.
В итоге мы вполне можем снять Snapshot сервиса, находящегося в Production, и смонтировать его в тестовой среде для проверки обновлений, новых решений и прочих задач, никак не затрагивая рабочую систему или сервис.
Кроме того, LUN'ы можно добавлять в так называемые Consistency Groups, что позволяет делать снимки указанных данных в один и тот же момент данных. Это крайне важно, если вы придерживаетесь рекомендаций вендоров и раскладываете файлы и логи тех же баз данных по разным LUN'ам.
HyperCDP
Если HyperSnap — механизм достаточно традиционный, то HyperCDP — развитие Snapshot с возможностью создания снимков один за другим с большой частотой. Проще говоря, это набор мгновенных снимков, который можно создавать по расписанию с задержкой минимум 3 секунды.
Важно отметить, что подключение получившегося объекта напрямую к заведенным хостам невозможно — из получившегося объекта необходимо сначала сделать копию. Из-за отсутствия записи и прямого чтения снимки HyperCDP могут быть использованы как инструмент для длительного хранения информации.
Помимо функции защиты, HyperCDP имеет еще одно важное преимущество. При использовании данной функции практически не страдает производительность. Это мы и проверим в процессе тестирования.
Для теста заведем на нашей СХД 16 LUN по 512 Гб, подключим их к одной ВМ и дадим нагрузку с помощью бенчмарка VDBench.
Примечание. VDBench сам по себе довольно прост, Oracle распространяет его бесплатно, из сопутствующего ПО требуется лишь установленный JRE.
В вызываемом файле конфигурации необходимо задать параметры, которые будут использоваться при тестировании. Допустим, VDBench будет писать блоком 8 килобайт с 70% полностью рандомного чтения и параметрами дедупликации и компрессии 2 к 1.
На СХД мы также настроим HyperCDP-план, который позволит в процессе делать снимки каждого из 16 LUN'ов с интервалом в 10 секунд. Ограничим эту задачу 500 объектами (для каждого LUN'а). Максимальное же количество в рамках одного плана может быть 60000.
Рисунок 5. Веб-интерфейс с примером созданного HyperCDP-плана.
Остается запустить VDBench с указанными ранее параметрами и наблюдать за текущей производительностью.
В начале эксперимента на тестовой ВМ изменений нет, показания IOPS находятся на том же уровне, учитывая небольшую погрешность измерений.
Рисунок 6. Результаты теста HyperCDP.
Подождем еще немного, пока количество HyperCDP-объектов всех LUN'ов не перевалит за сотню, и проверим еще раз.
Рисунок 7. Результаты теста HyperCDP с количеством объектов более 100.
Подводя промежуточные итоги, стоит отметить, что эмулируемый в рамках теста сервис не испытал каких-либо воздействий в плане деградации производительности, и за полтора часа мы получили 500 снимков 16-ти LUN'ов, что в сумме составляет 8000 объектов.
На мой взгляд, эта функция может быть востребована при работе с активно используемыми и загруженными базами данных, где за секунды число транзакций значительно возрастает и возможность отката на десяток секунд вполне пригодится.
HyperClone
Из названия HyperClone становится очевидно, что эта функция делает точную копию указанного LUN'а.
При этом созданная «связка» пары исходного и целевого LUN'ов продолжит пребывать в работоспособном состоянии, позволяя синхронизировать данные в любую сторону.
При создании клона также можно выбрать скорость синхронизации:
В отличие от снимков HyperCDP клон не грузит основной LUN. В веб-интерфейсе соответствующего раздела доступна синхронизация в обе стороны: Synchronize и Reversе Sync. Если данные на первичном LUN'е были изменены и должны быть перенесены на вторичный, используется инкрементальная синхронизация, т.к. СХД отслеживает изменения созданных пар.
Примечание. Ранее рассмотренные варианты создания снимков HyperSnap и HyperCDP занимают намного меньше дополнительного пространства на хранилище, т.к. не являются полной копией данных
Рисунок 8. Настройка HyperClone.
Для разрыва связи достаточно удалить созданную пару в разделе веб-интерфейса Data Protection, в закладке Clone Pairs.
Рисунок 9. Удаление клон-пары.
К сожалению, в рамках одной статьи трудно описать все нюансы. Поэтому ограничусь кратким подведением итогов: проверил — работает.
SmartQOS
В принципе, сервис SmartQoS — штука не новая. Системы, которые обеспечивают нужную полосу пропускания для критичных сервисов за счет приоритизации, существовали и ранее. Использовать разные LUN'ы под различные сервисы — совершенно нормальная практика. В этом случае иногда возникает необходимость выставить максимальные показатели производительности по IOPS или Bandwidth на те или иные объекты.
Рисунок 10. Настройка политики SmartQoS.
Такой подход бывает необходим в определенных ситуациях, например, утренний Boot Storm у VDI. Инженеры Huawei учли этот факт — есть возможность включать нужный режим QoS по расписанию.
Функция «прячется» под кнопкой Advanced.
Рисунок 11. Настройка расписания (раздел Advanced).
Выполнить проверку просто — необходимо создать политику SmartQOS для одного из LUN'ов с параметрами ниже.
Рисунок 12. Созданная политика SmartQoS001.
Далее снова обратимся к помощи бенчмарка VDBench (в тестировании он встретится еще не раз). СХД с точностью как в аптеке отмеряет нашей эмуляции сервиса предоставляемые IOPS'ы. Для наглядности ниже привожу показания со стороны тестового ПО и со стороны Dorado.
Рисунок 13. Результат выполнения политики SmartQOS.
Выглядит SmartQOS весьма неплохо. По результатам его тестирования могу порекомендовать Dorado к использованию в любой инфраструктуре как для оптимизации работы уже существующих сервисов, так и для изначального планирования, особенно если в СХД размещены крупные базы данных или VDI, требующие «особого подхода».
Для последних также важно наличие такой настройки как Burst, когда политика позволяет превысить максимальные значения на определенный срок, задаваемый администратором. Это поможет проще пережить уже упоминаемый ранее Boot Storm. Если у Dorado будет возможность не жертвовать другими сервисами, она спокойно перейдет в режим Burst в политике и обеспечит требуемые параметры производительности.
Подведение итогов для первой части
При подведении итогов принято говорить о преимуществах и недостатках. В данном случае хочется и похвалить, и поругать Huawei за новый веб-интерфейс. В целом, он простой и логичный. Разобраться с ним можно, даже не имея опыта общения с продуктами компании Huawei. С другой стороны, современные интерфейсы должны быть интуитивно понятны во всем. Здесь же выезжающие справа фреймы можно закрыть исключительно нажатием кнопок снизу — ОК или Cancel, хотя интуитивно хочется просто тапнуть по неактивному полю страницы.
Что касается результатов тестов — они говорят сами за себя. Dorado V6 в реальной жизни выглядит достаточно неплохо, даже в начальной своей конфигурации. По цене младшая Dorado V6 соперничает со многими гибридными СХД, которые показывают куда более скромные результаты в тестах производительности. Ее можно рассматривать к покупке практически под любые сервисы. Разве что для резервного копирования All-flash массивы все еще слишком дороги.