Система хранения данных
IBM FlashSystem 5030 = Storwize V5030E

История данной линейки систем хранения данных началась после покупки в 2008 году небольшой израильской компании с одноименным названием «Storwize». Именно по образцу израильской системы хранения данных «XIV» был создан столь удачный в последствии графический интерфейс.

И вот уже долгое время IBM обновляет и совершенствует линейку Storwize в такт с развитием требований и технологий. Однако с 2020 года было принято решение включить некоторое количество устройств в отдельную линейку FlashSystem. На сегодня в семейство FlashSystem входят: FlashSystem 5010/5010H (ранее Storwize V5010E), FlashSystem 5030/5030H (ранее Storwize V5030E), FlashSystem 5100/5100H (ранее Storwize V5100/V5100F), FlashSystem 7200/7200H (ранее Storwize V7000 G3), FlashSystem 9200 (ранее FlashSystem 9150), FlashSystem 9200R. C литерой «H» – гибридные системы (Hybrid), с численным обозначением - All-flash.

Коротко описать позиционирование 5030H можно как гибридную (HDD/SSD) систему среднего уровня, с упрощенными функциями устройств более высокого, корпоративного класса.

В арсенале имеется:

• IBM Spectrum Virtualize
• Доступны дополнительные функции: Easy Tier, Compression, FlashCopy, Remote mirroring, Encryption и другие
• IBM Storage Insights
• Два контроллера с 6 ядерными CPU Intel 1.9GHz (Broadwell-DE)
• Интерфейсы в базе: 1/10 Gb iSCSI
• Интерфейсы опционально: 16 Gb Fibre Channel, 12 Gb SAS, 25 Gbps iSCSI, 10 Gb iSCSI/Fibre Channel over Ethernet (FCoE), 1 Gb iSCSI
• RAM Cache: до 64 GB на систему (16 GB или 32 Gb DDR3 кэш памяти на контроллер)
• До 760 дисков на одну систему и до 1520 на кластер из 2-х устройств
• Поддержка уровней RAID: 0, 1, 5, 6, 10, Distributed (DRAID 5, DRAID 6)

Немного раскроем суть некоторых вышеперечисленных пунктов.

IBM Spectrum Virtualize – ПО, разработанное для программно-определяемых систем хранения данных, ставшее в последствии частью семейства IBM Storwize и FlashSystem. Технологии, включенные в данный программный комплекс, позволяют виртуализировать подсистему логических дисков, несколько RAID массивов (причем RAID массивы могут быть разного размера и типов как SSD так и HDD) объединяются группы (пулы), дисковое пространство для томов (предоставляемых хостам) берётся из общего объема пула, то есть сразу из нескольких RAID массивов. Это позволяет с одной стороны получить большую ёмкость томов, используя небольшие диски, с другой повысить скорость работы на операциях чтения/записи. Размер тома в IBM Spectrum Virtualize ограничен 256 ТБ, что значительно превосходит возможности многих операционных систем. Особенностью же данной технологии является то, что некоторые системы (например - SAN Volume Controller) могут вообще не иметь своих дисков, они берут их из подключенных внешних СХД причем не обязательно IBM (IBM FlashSystem 5030H и Storwize V5030E могут виртуализировать внешнюю СХД только для миграции данных).

В список так же входят технологии: создание снапшотов, шифрования дисков, сжатия в реальном времени, дедупликация и IBM Easy Tier, которые обеспечивают высокий уровень экономии дискового пространства и быстродействия. Напомним Easy Tier автоматически и динамически перемещает наиболее «горячие» востребованные данные на более производительные уровни (SSD или SAS), а наименее востребованные «холодные» данные перемещает на менее производительные уровни (SAS или NLSAS).

Easy Tier

Сжатие в реальном времени, как и дедупликация в данной СХД реализованы через создание специального пула (data reduction pool), к томам которого можно применить режимы тонкого выделения пространства (thin provisioning), сжатия и дедупликации. Примечательно, что дедупликация и компрессия работают только на версияx СХД с 64 GB системного кэша. Это связанно с тем что она не имеет у себя встроенного аппаратного модуля для сжатия (компрессии) как это реализовано на более дорогих ее собратьях, поэтому используются процессоры контроллеров для сжатия и распаковки, а соответственно требуется достаточное количество быстрой памяти.

IBM Storage Insights – это облачный сервис позволяющий очень удобно мониторить свои устройства IBM, вести учёт текущих задач, производительности и событий, а также реализован удобный способ обращения в техподдержку. Тем самым быть в курсе состояния устройств хранения данных из любой точки мира. Есть как базовая бесплатная версия, так и платная, с более широким функционалом.

Для работы с сервисом нужен IBM ID (зарегистрированный аккаунт).

https://www.ibm.com/ru-ru/marketplace/analytics-driven-data-management?mhsrc=ibmsearch_a&mhq=Storage%20Insights%20

После регистрации на почту приходит ссылка на сервис, откуда можно начать настройку, все пошагово и довольно понятно.

Надо выбрать, где (на какой ОС) будет стоять сборщик данных в вашей сети.

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

Storage Insights будет ждать его внедрения

Как только пойдут пакеты от сборщика откроется панель добавления устройств.

Далее введем ip адрес СХД, логин и пароль (можно создать для этого специальную учетную запись на СХД). После подключения увидим первую сводку.

Пример графика нагрузки

Есть еще особенность при создании RAID массивов, СХД, исходя из имеющихся в ее расположении дисков (зависит от типа диска и его объёма) в GUI, дает создать только правильные с её точки зрения массивы.

Так, например, выглядит окно создание массива при выборе 6 SSD дисков.

А так при выборе 18 обычных SAS HDD

Однако через CLI можно собрать почти любой массив (почти любой, потому что, например RAID-5 и RAID-6 в данном случае не поддерживается из накопителей такого большого объёма - SSD 15Tb)

Вот так выглядит команда на создание недоступного из GUI RAID-10 из 6 дисков SSD.

Командой «lsarray» можно посмотреть имеющиеся массивы.

Распределенный RAID (6,5) в данном случае представляет из себя массив, где резервируется не какие-то конкретные диски, а лишь область на каждом из участников, в совокупности составляющая объем одного (в случае с DRAID-5) или двух дисков (когда речь идет о DRAID-6).

У нас побывала система еще со старым наименованием - IBM Storwize V5030E(в последствии переименованная в FlashSystem 5030)  (64Gb Cache, 16Gb FC, 6x15.36TB SSD, 18x2.4TB SAS 10k, Easy Tier).

В первую очередь хотелось посмотреть на работу пула с компрессией. Узнать, как это реализуется и влияет ли на производительность. Ну и конечно постараться протестировать, имитируя идеальные и реальные условия, дабы увидеть максимально возможное количество операций ввода/вывода (IOPS) и время задержки (latency).

Для тестов использовалась утилита HCIBench 2.3.1 (внутреннее ПО для тестирования Oracle Vdbench), развернутая в среде виртуализации VMware vSphere 7.

Хостом послужил IBM System x3550 M4 (RAM 64GB, 2x CPU Intel Xeon E5 2620 2.0Ghz, 2 x FC HBA Emulex 8Gb).

Гипервизор ESXi был установлен на локальный SSD (2x Intel SSD 240Gb RAID1).

HCIBench настраивалась на создание и запуск двух виртуальных машин с дисками по 300Гб, машины соответственно располагались на тестируемых разделах в СХД.

Для исключения попадания в отчет результатов тестирования системного кэша использовался предварительный «прогрев» диска 1800s (Warmup Time). Так же для проверки работы «прогрева» кэш отключался в самой СХД для тестируемого тома. Как следствие, запись результатов начинается только через 30 минут тестирования, чтобы заполнить кэш. Время тестирования (Test Time) 3600s (1 час).

Первый тест двух одинаковых томов, с компрессией и без.

Параметры: block size 4kb, 50% random, 70% read, threads 32.

Предполагалось, что на обычных дисках разница в производительности будет более заметной, поэтому мы создали для этого теста RAID-10 из шести SAS 10к дисков.

На сводном графике видно, что производительность обычного тома без компрессии выше, среднее значение около 3000 IOPS достигается гораздо быстрее. Общая динамика графика, как и ожидалось из-за идентичности тестирования схожа.

Количество операций ввода / вывода в секунду

Latency (показаны усреднённые значения)

Задержки также меньше при тестировании тома без компрессии. Но в целом, разница невелика.

Следующими проводились тесты с приоритетом на чтение и запись. Тома презентовались серверу с пула, в который был добавлен рекомендуемый системой массив Distributed RAID 6 из шести 16 Тб (полезная емкость 15.3 Тб) SSD дисков.

Тест 1: block size 4kb, 50% random, 70% read, threads 32

Тест 2: block size 4kb, 50% random, 30% read, threads 32

Количество операций ввода / вывода в секунду

Система показала хорошие результаты, в тесте 2 - где 70% операций приходится на запись ожидаемо показатель ниже (максимально 42900 IOPS), тест 1 – где 70% чтение результат лучше (максимально 52000 IOPS).

Latency (показаны усреднённые значения)

Задержки так же весьма минимальны, средний результат менее 1 миллисекунды, в максимуме был пик до 4 ms в тесте 2 (здесь, вероятно сказывается большее количество операций) и всего 0.9 в тесте 1.

Последний тест был выполнен для достижения максимального количества IOPS, его параметры приближены к «идеальным» для этой задачи:  

block size 4kb, 100% sequential, 100% read, threads 64

Сводная таблица HCIBench Report

Вероятно, можно было достичь еще более высоких показателей (в пике мы видим более 80000 IOPS), при условии использования в сервере FC HBA 16Gb в место восьми-гигабитных, но их на момент тестирование у нас не было.

Подобных тестов на максимальную производительность было сделано 4, с увеличением очереди запросов (Queue Depth 16, 32, 64, 128). Количество операций ввода / вывода росло до Queue Depth 64. Однако между QD32 и QD64 разница была уже невелика, а между QD64 и QD128 стала ещё меньше. Время отклика системы (Latency) естественно возрастало с увеличением QD.

Стоит упомянуть что при выполнении всех тестов CPU Storwize V5030E был загружен максимум до 20-30%.

 Пример графиков панели мониторинга СХД

В итоге можно сказать что СХД прекрасно прошла тесты, да количество дисков не дает выявить максимум ее производительности, устаревшие восьми гигабитные адаптеры в сервере тоже вероятно внесли свою лепту (16Gb FC на СХД). Однако стабильность при тестировании и подтверждение ожиданий весьма хороший показатель, плюс имеется немалый запас производительности.

Применение сжатия на томах в data reduction pool, определенно сказывается на производительности, однако весьма некритично. И если есть потребность в экономии дискового пространства, то сочетание дедупликации и компрессии прекрасно с этим справляются. Результативность же сжатия сильно зависит от типа файлов, в нашем случае синтетического теста и виртуальных машин сжатие было минимальным, зато дедупликация экономила место отлично убирая одинаковы системные файлы виртуальных машин.