Хранение потоковых данных. Гонка за производительностью

Материал подготовлен коллегами из компании Entry

Оригинал записи

Медийные приложения (Media & Entertainment, M&E) – показательный пример отраслевого рынка, который уверенно осваивает программно-определяемое хранение. Производительная работа с большими объемами потоковых данных на классических СХД дается слишком дорогой ценой.

Программно-определяемое хранение рушит редуты традиционных поставщиков СХД, всего заметнее в приложениях с активным обращением к большим объемам данных (о трендах – в статьях “Системы хранения данных. Пожиратели пространства идут в SDS” и “Программно-определяемое хранение активных данных”). В обработке, хранении и распространении потокового видео научились обходиться без монстров, включая горизонтально-масштабируемые системы уровня NetApp FAS или EMC Isilon.  Хотя в активе лидеров рынка многолетние наработки по хранению, держать объемные данные в промышленных системах накладно: несообразно высоки прямые затраты в пересчете на единицу емкости, операционные расходы на сопровождение и модернизацию, издержки прироста производительности.

И дело не только в цене
NetApp, «ведущего поставщика Ethernet-систем хранения данных», ценят за WAFL/RAID-DP. Внутренняя файловая система хранилищ NetApp с записью повсюду (Write Anywhere File Layout, WAFL) отличается быстродействием, как для файлов, так и данных блочного доступа (SAN). Она глубоко интегрирована с RAID-менеджером. RAID-DP записывает данные полными страйпами (“случайные” записи пишутся “последовательно”), что дает быстрый RAID в режиме чередования с двойной четностью (защитой от одновременного отказа двух дисков, как в RAID 6). Технологиями Flash Pool и Flash Cache достигается баланс производительности и емкости в гибридных системах со слоем SSD над основным массивом емких HDD.

Проблемы WAFL заключаются в потере производительности при заполнении массива и высокой фрагментации данных. Хотя на уровне ОС работает фоновый дефрагментатор (“сборщик мусора”), для предсказуемой продуктивности интенсивной записи приходится оставлять 10-30% пространства свободным. Если чтение и запись имеют сходную организацию, пользователь не заметит падения производительности. При любой неоднородности размещения данных при потоковом чтении могут быть серьезные проблемы.

Что нужно потоковым приложениям
Операционная система для СХД уровня предприятия RAIDIX построена на классическом подходе RAID (read-modify-write). Приспособив расширенные инструкции стандартных процессоров Intel Xeon к реализации кода Рида-Соломона, разработчики получили уникальные по скорости алгоритмы, способные обеспечить работоспособность RAID-группы при одновременном отказе до 3-х дисков (RAID 7.3), или даже 32-х одновременно (RAID N+M). Без каких бы то ни было аппаратных RAID-контроллеров.

Быстрый расчет контрольных сумм, вкупе с рекордной надежностью и отличным использованием полезного дискового пространства, стал пропуском для RAIDIX в медийный бизнес. Именно там остра проблема стабильно высокой, без провалов, производительности работы с активными данными большого объема. С приложениями, которые большую часть времени работают с компактным ядром горячих данных, классические СХД на флэш-технологиях как-то справляются.

RAIDIX преобразует стандартное серверное оборудование в системы хранения данных высокой производительности. Поддерживаются блочные (FC, iSCSI, SAS, InfiniBand) и файловые (SMB, NFS, AFP) протоколы. Областью применения таких СХД, помимо видеопроизводства, могут быть вычислители HPC и информационные системы, построенные на архивации и передаче изображений.

От версии к версии добавляются технологии, повышающие производительность системы, как в целом, так и отдельных операций. Появилось SSD-кэширование для увеличения продуктивности транзакционных операций. Реализована раздача приоритетов определенным, критически важным приложениям – как инструмент блокировки деструктивного влияния работы некоторых приложений на работу СХД. Примером может быть запуск копирования файлов во время трансляции контента.

Пользователь может управлять RAIDIX тремя средствами: через GUI,  CLI и консоль LINUX.

Аппаратные вольности
Под RAIDIX годятся серверы на типовых компонентах, с низкой стоимостью владения и простым сервисным обслуживанием. Достаточно платформы Intel Xeon E5 16xx – у нее большой запас наращивания оперативной памяти и подключения периферии. В сетевое окружение СХД встраивается посредством FC HBA (8-16Gb) или 10-40Gb Ethernet NIC.

Объем операционных данных приложений видеомонтажа может достигать сотен терабайт – а это десятки HDD. Большую емкость набирают дисками SATA корпоративных серий или родственными им NL SAS. Как правило, диски выносят во внешний JBOD – контейнер плотной компоновки, с дублированными модулями ввода-вывода, питания и вентиляции. Многоканальное подключение JBOD к головному серверу («контроллеру») по SAS 6-12Gb гарантирует минимальные задержки и широкую полосу доступа к данным на дисках.

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

Доступность данных
Непрерывность работы гарантирует RAIDIX Failover Cluster (FC или 40GbE) –производительная платформа с высокой доступностью данных, без единой точки отказа. «Двухконтроллерное» программно-определяемое хранилище состоит из двух серверов, к которым подключается JBOD разделяемого доступа. При этом каждый контроллер может обслуживать свою RAID-группу. В кластере «Active-Active» узлы связаны интерфейсом с малыми задержками FC, SAS 12Gb или Infiniband, кэш обоих контроллеров всегда синхронизирован и находится в когерентном состоянии.  При потере одного из контроллеров на восстановление работоспособности СХД уходят считаные секунды.

У JBOD есть два независимых модуля ввода-вывода с экспандерами-дублерами. Благодаря двойному подключению дисков NL SAS, данные на них доступны при потере любого из модулей ввода-вывода – в отличие от собратьев SATA на той же механической платформе. Кроме того, NL SAS обслуживают бóльшую глубину очереди, чем SATA, что дает прирост производительности массива при той же механике жестких дисков. При этом диски NL SAS практически не отличаются по цене от SATA той же емкости.

А еще протокол SAS включает в себя контроль целостности T10 CRC по всему пути данных от диска до прикладной программы. Без технологии защиты, действующей “от двери и до двери”, эрозия данных может пройти незамеченной. В системах хранения большой емкости «тихие» ошибки дисков (silent data corruption) особенно опасны – они накапливаются,  неотслеженное повреждение данных приводит к неожиданным и тяжелым последствиям.  RAIDIX отслеживает и исправляет скрытые ошибки во время работы.

К средствам профилактики потери данных можно отнести еще две опции: упреждающую реконструкцию (оптимизация скорости чтения в процессе восстановления данных) и отсев потенциальных «смертников» (система запоминает диски с наихудшим временем отклика и перестает отправлять им запросы в течение одной секунды).

СХД в структуре видеопроизводства

Современное видеопроизводство требует значительных вычислительных ресурсов. Кроме поддержки приложений на разно-платформенных (MacOS/Windows/Linux) рабочих станциях редактирования видео, цветокоррекции или оформления, важен скоростной доступ к общим системам хранения данных большой емкости.

Доставку мультипоточных данных на стабильно высокой скорости, без гребенок и провалов, обеспечивает инфраструктура FC 8-16Gb – оттого сети FC SAN всегда были стандартом де-факто в больших телеканалах и студиях пост-производства. Встраивая FC-кластер хранения RAIDIX в существующее окружение, можно получить резкий прирост объема хранения и  скачок производительности, относительно малой кровью.

В узлы кластера ставятся двухканальные FC HBA 8 или 16Gb, массив как устройство блочного доступа (LUN) вводится в SAN и автоматически подстраивается под инициаторы подключаемых клиентов. Контроллер метаданных определяет права доступа групп пользователей к общему ресурсу и система готова к работе.

Там где FC-инфраструктуры нет, она, скорее всего, и не появится. Тому причиной быстрый рост пропускной способности сети Ethernet. Обычной практикой стало использование недорогих устройств 10-40 Gb/s, скоро дело дойдет до 100 Gb/s. Появляются доступные сетевые коммутаторы, адаптеры и протоколы передачи данных с низкими задержками. Все это открывает хорошие перспективы сетевым системам хранения данных файлового доступа.

NAS-кластер под RAIDIX отличается от FC-кластера внешними интерфейсами (ставятся 10-40Gb Ethernet NICs) и файловыми протоколами общения с клиентами (SMB, NFS, AFP).  По устройству серверных узлов и со стороны дисков (back-end) они идентичны: к узлам кластера многоканальными SAS HBA подключается совместное хранилище с дисками (Shared SAS JBOD) и настраивается синхронизация узлов, тоже по SAS.

Оценки производительности
Работа с видео высокого разрешения предполагает непрерывный мультипоточный доступ к большим объемам медиаданных. Продуктивность редактирования, временные затраты на подготовку контента напрямую зависит от характеристик систем хранения.

Оценивать характеристики СХД вне окружения, рабочих станций и живых приложений, непросто, СХД – не жесткий диск. Но сравнить особенности разных типов подключения и увидеть отклик производительности на изменение нагрузки синтетические тесты помогают.

Оба вида кластеров хранения, FC и NAS, были собраны и тестировались в лаборатории Entry.
Построенный стенд по очереди адаптировался под блочный и файловый доступ:

Мы не пытались сравнивать производительность двух типов кластеров в лоб. Выбор топологии – удел архитекторов сети. При похожем целевом назначении СХД, у них много отличий:

• FC-кластер использует блочный интерфейс доступа, NAS-кластер – файловый (SMB 2.0);
• Клиентам FC-кластера презентуются диски, клиентам NAS-кластера – сетевые папки (“шары”);
• Для одновременного доступа инициаторов к FC-кластеру хранения необходимо дополнительное ПО арбитража доступа (например, MetaSAN от Tiger Technology). В случае NAS-кластера, эти функции выполняет сам NAS. Арбитраж вносит коррективы в производительность.

Чем тестировали
Замеры проводили с помощью:

• AJA System Test 2.1 – Cтандартный для видеоиндустрии тест для оценки возможностей дисковой подсистемы по записи и проигрыванию потоков под разными разрешениями и кодеками. К сожалению, однопоточный.
• IOMeter 2008.06.18 RC2 – Синтетический тест дисковой и сетевой подсистем, позволяющий имитировать многотопоточную нагрузку в широком диапазоне параметров.

На инициаторах стояла Windows Server 2012R2.

Результаты AJA System Test

FC-кластер

NAS-кластер

По графикам видно, за что любят FC ветераны видеомонтажа: стабильную скорость чтения и записи, без больших всплесков и провалов. Никаких пропусков кадров и срывов потока.

Результаты IOMeter
Если AJA работает с одним инициатором, то IOMeter может создавать несколько потоков. Для тестирования были выбраны два идентичных сервера, каждый из которых генерировал последовательность 512КВ, 1MB и 8MB блоков (последовательное чтение/запись, при глубине очереди Q=1).

Сперва зафиксировали размер блока данных 8MB и сравнили поведение обеих СХД под одно- и двухпоточной тестовой нагрузкой – чтобы оценить их реакцию на рост нагрузки (масштабирование по клиентам). Двухпоточный вариант для NAS позволил обойти ограничение производительности для одной сессии (соединения) протокола SMB 2.0.

Повышение нагрузки привело к увеличению общей производительности, для NAS прирост был заметнее. При дальнейшем росте числа инициаторов показатели FC СХД довольно скоро выходят на полочку ограничений интерфейса. Для одного канала соединения FC 16 Gb это 1575 MB/s в режиме полудуплекса. Для NAS многое зависит от взаимодействия протоколов. На SMB 2.0 (поддерживается текущей версией RAIDIX) при нагрузке от 5 виртуальных машин мы фиксировали скорость записи 1870 MB/s, чтения – 1215 MB/s.

Во второй группе тестов замерялась производительность при двух инициаторах с размером блока 512K / 1M / 8M.

Любопытно, что для FC СХД увеличение размера блока данных тестовой последовательности сильнее подействовало на скорость записи, а для NAS – наоборот, заметнее сказалось на чтении.

Кроме тестов на сетевых клиентах, мы сделали внутренние замеры производительности RAIDIX на самом хранилище, с его 60 дисками 8TB NL SAS. Скорость считывания с дисков в оперативную память приближалась к 4 GB/s, скорость записи на диски превышала 3 GB/s – куда выше типичных 1-1.5  GB/s в тестах на клиентах.

Может ли пользователь рабочей станции выжать больше? Зависит от каналов подключения и возможностей их объединения, протоколов обмена.  То же самое верно для  СХД – наращивание ее отдачи возможно: переходом с FC 8Gb на 16Gb, c  Ethernet 10Gb на 40Gb, добавлением полок хранения и каналов доступа. Рычаги производительности – в руках пользователя.

Послевкусие
Тестовые результаты сами по себе имеют небольшую практическую ценность. Чтобы внести в инфраструктуру видеопроизводства новые подходы к хранению, приходится считаться со спецификой обслуживания большого объема активных данных,
многообразием клиентских платформ (рабочих станций), возможностями протоколов обмена, унаследованным окружением. Практика поправляет лаборантов.

Очевидно одно, «много хранить, быстро работать, не разориться при этом» – отличный стимул для перехода на программно-определяемое хранение. Независимая трансформация программной и аппаратной составляющей проектов дает свободу: от вендора, конструктива, переплаты за компоненты и вмененный сервис. Решать возникающие задачи можно доступными средствами.

Попробуйте внести конструктивное изменение в промышленную СХД.