Современная IT инфраструктура сейчас уже немыслима без использования систем виртуализации. А виртуализация наиболее полно раскрывает свои возможности в случае использования централизованной системы хранения данных. Да и помимо этой немаловажной роли найдутся другие задачи, где может потребоваться СХД: масштабные проекты по видеонаблюдению, хранение больших массивов данных, работа с медиа и прочее.

Среди систем хранения, присутствующих на рынке в настоящее время, хотим обратить ваше внимание на СХД тайваньского производителя Qsan Technology серии XCubeSAN.

QSAN как самостоятельная компания появилась в 2008 году. Изначально команда QSAN занималась разработкой и OEM производством RAID контроллеров для различных производителей СХД. Чуть позже, заручившись поддержкой таких грандов среди ODM производителей, как Compal и Gigabyte (да-да, Gigabyte не только производит известные всем материнские платы и видеокарты, а также много чего из сектора Enterprise), перешли на производство своих собственных СХД. В России производитель присутствует почти с самого своего основания (т.е. уже почти 9 лет) и прошел за это время долгий путь от никому не известного вендора до поставщика решений, которые могут успешно конкурировать с так называемыми брендами Tier 1.

Итак, QSAN XCubeSAN – это последнее поколение СХД, сочетающее в себе максимально возможное количество технологий. Основной девиз производителя – сделать функционал Enterprise доступным малым и средним компаниям. Главное, на что следует сразу же обратить внимание, — это совершенно официальная поддержка вендором дисков сторонних производителей. Поэтому никто не будет вам связывать руки (и выворачивать карманы в поисках денежных знаков) при выборе дисковой подсистемы. Конечно, стоит сразу оговориться, что придерживаться листа совместимости в сегменте Enterprise – это, что называется, must have, иначе можно столкнуться с весьма неприятными проблемами в процессе эксплуатации.

Отдельно стоит отметить в контексте использования сторонних дисков набирающее все большую популярность построение хранилищ на базе SSD (и даже All Flash Storage). Если для некоторых типов брендированных жестких дисков еще возможны цены, близкие к «магазинным», то для SSD даже с большими проектными скидками приблизиться по стоимости, например, к HGST или Intel нереально. А это значит, что All Flash на базе QSAN будет просто не досягаем по цене при сравнении с брендами Tier 1.

Аппаратные компоненты СХД

Линейка QSAN XCubeSAN состоит из трех серий, имеющих индексы моделей XS1200, XS3200 и XS5200. Различаются они типом процессора (Pentium/Xeon, 2-4-8 ядер), что в свою очередь сказывается на пиковой производительности. В остальном «железо» и софт полностью идентичны. Поэтому в обзоре мы не будем акцентировать внимание на конкретной модели, т.к. информация применима по сути ко всем (разумеется, с некоторыми поправками).

Доступны 4 вида корпусов:

• 2U 12 bay LFF
• 3U 16 bay LFF
• 4U 24 bay LFF
• 2U 26 bay SFF

Все модели с дисками LFF (3.5”) поддерживают в том числе и установку дисков/SSD форм фактора SFF (2.5”) без каких-либо дополнительных опций.

26 дисков в корпусе 2U

Первые три вида корпусов едва ли кого-то удивят. А вот корпус 2U26 в настоящее время является весьма интересным форм-фактором. Такая высокая плотность размещения дисков достигается за счет утончения салазок для дисков, а также особому расположению ребер жесткости корпуса СХД. На текущий момент ни у кого из производителей нет подобных решений: типичное число отсеков для 2U – это 24-25. А лишние отсек-два для дисков совсем не лишние, так как позволяют более гибко подойти к вопросу построения RAID групп и не экономить на hot spare.

Универсальная салазка с диском

Далее – внутренние компоненты: блоки питания, модули охлаждения, контроллеры. Все они задублированы для обеспечения отказоустойчивости. И, разумеется, поддерживают «горячую» замену. Нет, конечно же, можно заказать СХД и с одним контроллером. Но весь прогрессивный мир давно уже пришел к выводу, что переплата за второй контроллер – это спокойствие заказчика и непрерывный доступ к сервисам, расположенным на СХД.

Задняя панель

Контроллер построен на базе процессора Intel Xeon/Pentium D-1500, который специально предназначен для использования во встраиваемых решениях. В качестве ОЗУ используется память типа DDR4 с обязательной поддержкой ECC. На плате для этого имеется 4 разъема (2 для младшей модели). Поддерживается двухканальный режим с максимальным объемом до 128ГБ (32ГБ для младшей модели). Имеется SATA DOM модуль, на котором установлена операционная система.

Контроллер, вид сверху

Для связи с внешним миром имеются два порта 10GbE iSCSI RJ-45 (обратно совместимы с 1GbE), выделенный порт управления, а также 2 порта miniSAS HD для подключения полок расширения через интерфейс SAS 12G. Помимо этого есть разъемы для подключения консоли и ИБП через COM или USB порты.

Контроллер, вид сзади

Помимо встроенного интерфейса имеются два слота для карт расширения: PCI-E x8 Gen3 и PCI-E x4 Gen2. Поддерживаются разнообразные варианты хост разъемов:

• 4x 16Gb FC (SFP+)
• 2x 16Gb FC (SFP+)
• 2x 10Gb iSCSI (10GBASE-T)
• 4x 10Gb iSCSI (SFP+)
• 4x 1Gb iSCSI (1GBASE-T)

Карты расширения

Можно как угодно комбинировать интерфейсы, в том числе и совмещать в рамках одной системы Fibre Channel и iSCSI. Единственное ограничение – конфигурация портов в обоих контроллерах должна быть одинаковой. В максимальной конфигурации в СХД с двумя контроллерами может быть до 16 портов FC 16G или до 20 портов 10G iSCSI. Конечно же меряться максимальными значениями — неблагодарное занятие, но с точки зрения практики наличие большого количества интерфейсов не только может повысить производительность в ряде сценариев, но и позволит в пределах 6-10 серверов отказаться от использования дорогостоящих коммутаторов Fibre Channel или 10Gb Ethernet.

Для защиты кэша контроллеров от внезапного отключения электропитания используется модуль Caсhe-to-Flash, состоящий из батареи или конденсатора и SSD с интерфейсом PCI-E M.2. Использование столь быстрого накопителя необходимо, чтобы успеть скопировать содержимое кэша пока элемент питания поддерживает работу контроллера. На всю операцию отводится не более 2 минут, даже если объем кэша будет максимальным — 128ГБ. При этом емкости батареи хватит на 3-4 подобных цикла, то есть, можно быть спокойным даже при повторных отключениях питания. Также хотим отметить, что для обслуживания модуля Caсhe-to-Flash не нужно извлекать блок питания, а уж тем более контроллер. Модуль имеет функцию «горячей» замены и доступен с задней панели.

Для расширения дисковой емкости возможно подключение полок XCubeDAS, которые доступны в тех же корпусах, что и сами СХД: 2U12, 3U16, 4U24, 2U26. Причем, нет никакого ограничения на конфигурацию «головы» и полок, можно сочетать их в любой комбинации. Однако, максимальное количество полок не может превышать 10, что в большинстве случаев более, чем достаточно, так как количество дисков рамках одной системы может достигать 286.

Кстати, в самой схеме подключения полок расширения к СХД имеется у QSAN имеется свое ноу-хау, связанное с обеспечением отказоустойчивости. Физически полка подключается к «голове» двумя кабелями SAS, как и у всех прочих вендоров. Но логически каждый контроллер СХД видит оба контроллера полки, в том числе и через соседа, посредством внутренней шины. В итоге, в случае перекрестного выхода из строя контроллера СХД и контроллера JBOD система продолжит свою работу (здесь, конечно, важным замечанием является то, что при такой ситуации никто не выдергивал кабели между компонентами).

Согласны, что возникновение подобного инцидента маловероятно, но если есть дополнительная защита (за которую никто денег не просит), то работать с таким решением как-то спокойнее.

Раз уж затронули тему ноу-хау, не лишним будет отметить поддержку технологии Wake-on-SAS, благодаря которой можно управлять питанием полок расширения через кабели SAS. Это может потребоваться, чтобы включать/выключать полки расширения вместе с «головой» в правильном порядке в автоматическом режиме. Конечно, выключают СХД совсем не часто. Но когда настает такой момент, совсем не лишним будет контроль действий администратора со стороны автоматики системы. Ведь, например, отключение полки раньше «головы» может привести к развалу RAID группы, если эта группа «размазана» по нескольким юнитам.

Резюмируя, можно сделать вывод, что аппаратная составляющая QSAN XCubeSAN обладает возможностями по построению совершенно разнообразных решений (от наиболее простых и бюджетных до весьма продвинутых), может интегрироваться с любыми SAN сетями (в том числе и гетерогенными), а также позволяет использовать жесткие диски и SSD сторонних производителей.

Возможности программной составляющей СХД

Основой является Linux-подобная операционная система собственной разработки — SANOS уже 4-ой версии. Управление осуществляется через браузер. Интерфейс представлен на нескольких языках, в том числе на русском. Поддерживаются стандартные протоколы http и https с возможностью изменения номеров портов для большей безопасности. Интерфейс не требует установки Java, Flash и прочих сторонних средств. Также можно осуществлять управление через протокол ssh (правда, с чуть урезанным функционалом).

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

Интерфейс управления. Также доступен для ознакомления

Важной особенностью концепции управления СХД QSAN XCubeSAN является минимум ограничений на используемые конфигурации и максимум настроек для них. Здесь никто не будет вам навязывать, например, заранее предопределённые конфигурации по дискам. Для большинства ключевых функций имеются широкие возможности по настройке, а не просто включить/выключить. Поэтому ограничением при построении конфигураций будет выступать скорее ваш здравый смысл, нежели программное обеспечение.

Обслуживание системы в процессе эксплуатации предусматривает оповещение администратора о возникших проблемах с СХД. QSAN XCubeSAN может рассылать подобную информацию по e-mail, отправлять сообщения на syslog сервер и выдавать SNMP trap. Помимо этого, о текущем состоянии можно узнать из WebGUI: подробный мониторинг аппаратных датчиков, текущую производительность всей системы, отдельных дисков, томов и портов ввода/вывода.

Мониторинг

Отдельно хотим отметить функцию интеграции СХД с источниками бесперебойного питания. Поддерживается связь с ИБП через COM и USB порты, а также через Ethernet. Итогом такой связи является возможность выключения СХД по команде от ИБП. Чаще всего в случае внезапного отключения электричества достаточно корректно завершить работу серверов, а СХД можно просто отключить от питания. Но если организовывать процесс аварийного отключения по всем правилам, то подобная интеграция СХД и ИБП будет очень кстати, т.к. позволит корректно выключить всю инфраструктуру, в том числе и систему хранения.

Раз уж зашла речь о возможных инцидентах с оборудованием, то нельзя не отметить современную тенденцию большинства вендоров по внедрению автоматической системы отсылки информации о состоянии оборудования в «облачные» сервисы, с целью анализа этой информации в Big Data и прогнозирования возможных сбоев. Сервис, безусловно, полезный, но в нашей стране он сталкивается с ожесточенным сопротивлением со стороны пользователей, которые не хотят делиться подобными данными с кем-то извне. Это может быть обусловлено разными причинами: политиками безопасности на месте эксплуатации, страхом, что будет отправлена конфиденциальная информация либо платностью такой услуги. Отчасти по этой причине QSAN не предоставляет сервис автоматического сбора данных о состоянии своих СХД. Вместо этого, для эффективной диагностики систем СХД имеет расширенный режим логирования всех внутренних процессов. Поэтому администратору достаточно отправить в техподдержку файл с debug info, чтобы инженеры смогли максимально точно определить источник проблемы.

Обновление прошивки производится «на ходу» без остановки работы системы. Для современной СХД это уже стандарт де факто, но не упомянуть об этом нельзя.

Пространство хранения в QSAN XCubeSAN основано на модной сейчас концепции пулов. Физические диски объединяются в RAID группы, которые, в свою очередь, образуют пулы. Популярность пулов в настоящее время обусловлена тем, что, в отличие от классических RAID групп, они являются в своем роде надстройкой в виде виртуализации дискового пространства и позволяют совершать ряд операций наиболее безболезненно по отношению к данным. И в первую очередь это – такая обыденность, как расширение пространства хранения. Добавление новых дисков в RAID группу всегда было весьма рисковой операцией, так как во время перестройки группы никакие алгоритмы RAID не обеспечивают защиту данных. К тому же процесс перестройки весьма небыстрый (в зависимости от объема и типа дисков мог достигать нескольких дней и даже недель), диски в этот момент испытывают повышенную нагрузку, что только может ускорить выход одного из них из строя. Поэтому, если произойдет сбой диска, то все данные, расположенные в группе, уйдут в небытие. Восстановление из резервной копии и восполнение каким-то образом измененных данных с момента создания бэкапа никак не добавит энтузиазма администраторам для проведения операций по расширению массива.

При использовании пулов, наоборот, все весьма просто. Команда расширения пула – это создание еще одной или нескольких RAID групп с присоединением их к существующим группам. В результате администратору будет доступно общее пространство как единое целое несмотря на то, что состоит оно из нескольких кусков. Рекомендуется расширять существующий пул группами такого же уровня, что и исходный, в целях получения максимальной производительности. Но при необходимости можно «склеить» в один пул, например, группы RAID5 и RAID6. Просто следует помнить, что в таком случае производительность будет ограничиваться самым медленным звеном.

В рамках единого пула можно совмещать не только группы с различными уровнями RAID, но и различные типы дисков. Более того, СХД может автоматически перемещать данные между дисками в соответствии с востребованностью этих данных. Такой функционал по перемещению данных называется тиринг (tiering). В тиринг-пуле может быть до трех уровней:

1. SSD диски – высокий, самый быстрый уровень, самые часто используемые («горячие») данные
2. Быстрые диски SAS 10K и 15K – средний уровень
3. Медленные и емкие диски 7.2K – нижний уровень, наименее используемые («холодные») данные

Для тиринг-пула можно гибко задавать расписание, когда и с каким приоритетом производить миграцию данных (хоть каждый час). Но разумным значением будет перемещение 1-2 раза в сутки, чтобы это не оказывало сильного влияния на текущие задачи и, вместе с тем, было эффективно с точки зрения итоговой производительности. Важно, что все эти настройки можно изменять «на лету».

Для томов, созданных на тиринг-пуле, можно указывать начальное положение, а также в каком направлении перемещать данные. Для всех томов доступна подробная статистика: что и куда было перемещено.

Помимо тиринга другим способом повышения быстродействия является SSD кэширование. В этом случае часто востребованные данные копируются на выделенные SSD. Хотим сразу заострить внимание на том, что в СХД QSAN SSD кэш работает не только для операций чтения, но и для операций записи. Сам кэш физически располагается на выделенных SSD, которые не доступны для хранения данных. Самих SSD в составе кэша может быть несколько (в том числе разного объема), все они используются совместно. Если используется кэш на запись, то число SSD должно быть кратно двум. Это необходимо для защиты данных (зеркалирование), т.к. в случае отказа одного из SSD важно не потерять содержимое кэша, которое еще не было записано на диски. В случае использования кэша только на чтение необходимости защищать его нет, т.к. он содержит всего лишь копию данных, расположенных на дисках.

Статистика работы кэша

В отличие от продуктов других вендоров, где функция SSD кэша имеет лишь единственную настройку «включить/выключить», в QSAN XCubeSAN данный функционал вовсе не представляет собой «черный ящик». Для всех томов, которым необходимо кэширование, выбирается «профиль поведения», в соответствии с которым данные попадают в кэш. Есть несколько предопределенных профилей (база данных, файл сервер, web сервер), а также возможность создать новый, конкретно под ваши задачи. Для него необходимо указать, какими блоками производить кэширование, а также задать количество запросов на чтение/запись, после которого блок будет скопирован в кэш. Благодаря такой гибкости в настройках данной опции СХД QSAN XCubeSAN могут показывать лучшие результаты в плане производительности в ряде пользовательских задач, нежели СХД других производителей.

Настроки SSD кэша

Без такого важного функционала, касающегося безопасности данных, как снапшоты современной СХД уже и не существует. В QSAN это, разумеется, тоже присутствует. Снапшоты работают по технологии copy-on-write. Могут создаваться вручную и по расписанию с частотой вплоть до 15 минут. Есть интеграция с Microsoft VSS для создания консистентных с точки зрения приложений снапшотов. Также они могут монтироваться в виде томов в том числе и с правами на запись.

Функции, которые основаны на технологии снапшотов также не оставлены без внимания. Это – репликация и клонирование. Они отличаются друг от друга тем, что клонирование – это создание копии тома в рамках единой системы, а репликация – это создание копии на другой физической СХД. Обе операции выполняются блочным асинхронным методом. Минимально возможный интервал – 15 минут. В качестве приемного устройства при репликации не обязательно должна быть точно такая же модель СХД. Главное, чтобы это тоже была СХД QSAN. В качестве транспорта выступает протокол iSCSI. Возможна работа через низкоскоростные каналы, в том числе и через Интернет. Имеется поддержка многопутевого ввода/вывода для обеспечения отказоустойчивости процесса и утилизации пропускной способности имеющихся каналов связи. А чтобы репликация не мешала работе основных сервисов компании, в настройках можно активировать traffic shaping. Поддерживаются различные топологии при репликации: одно и двухсторонние, один-ко-многим, многие-к-одному. Таким образом, возможно построение катастрофоустойчивых решений (disaster recovery) с различными конфигурациями.

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

XCubeSAN – это флагманская платформа QSAN, которая продолжает совершенствоваться. В частности, в стадии разработки находятся такие функции, как QoS, синхронная репликация и интеграция с VMware SRM. Все это будет доступно пользователям при будущих обновлениях прошивок. Но и с текущим функционалом XCubeSAN выглядит достаточно солидно на фоне конкурентов, что позволяет ей стать ядром IT инфраструктуры компании любого масштаба.

Проверка в деле

Познакомившись с аппаратными и программными особенностями СХД QSAN XCubeSAN, пришло время для испытаний этой платформы в деле.

Сегодня можно с уверенностью сказать, что производительность любых конфигураций с жесткими дисками на современных СХД разных вендоров плюс-минус одинаковая и определяется производительностью самих дисков. Могут быть отличия из-за различных алгоритмов кэширования или особенностей реализации RAID групп. Но эти отличия едва ли стоят детального изучения. В Enterprise сегменте ключевыми характеристиками оборудования, напрямую влияющими на его выбор, являются беспроблемная работа в составе программно-аппаратного комплекса и квалифицированная техническая поддержка. Поэтому выискивать с лупой разницу в производительности между, например, СХД, как это делают при обзорах консьюмерского «железа», никому не интересно. Однако показатели производительности все же играют роль в некоторых топовых конфигурациях, когда узким местом могут стать вовсе не накопители. Так что все приведенные ниже тесты были проведены в конфигурации All Flash.

Чтобы попытаться «положить» систему во время теста, вызвав насыщение контроллеров СХД запросами, потребуется достаточно большое количество SSD. К сожалению, мы не располагаем в постоянном доступе столь большим их количеством. Поэтому в этой статье мы приводим результаты тестов, которые проводили специалисты из StorageReview, когда писали свои обзоры СХД QSAN XCubeSAN. Они использовали 24 штуки Toshiba PX04SV SAS 3.0 SSD. Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД, но вполне хватит показать, на что в принципе способна серия XCubeSAN.

В тестах использовалось две системы на 26 дисков: младшей серии XS1200 и старшей серии XS5200. Помимо ответа на вопросы по поводу общей производительности, можно также понять, что дает более производительный процессор в СХД (на самом деле между сериями есть еще разница в объеме предустановленной кэш памяти, но в данных тестах этот показатель был одинаковый).

Если кому не интересно смотреть графики тестов, можете смело проматывать к выводам. Для остальных предоставляем более детальную информацию.

По результатам тестов можно отметить весьма достойную производительность СХД QSAN XCubeSAN. Так, в наиболее популярных тестах были достигнуты показатели более 400K IOPS@4K на чтение и более 270K IOPS@4K на запись при latency, не превышающей 2мс. А уж «в прыжке», если не взирать на значение latency, так и вовсе показатели доходят до 450K/300K IOPS на чтение/запись. Результат, конечно, не как у полноценного All Flash Array, но и стоимость решения на порядок ниже.

Что же касается младшей модели, то она отстает от топовой как по максимальным показателям производительности (до 1.5 раз), так и по latency (на синтетике мало заметно, а на реальных задачах почти вдвое). Впрочем, все равно возможно получение более 200K IOPS на большинстве реальных задач при разумном значении latency.

Вердикт

Возможность использования дисков сторонних производителей вовсе не уникальная характеристика среди вендоров СХД. И вполне закономерно возникает ассоциация с довольно своеобразной организацией поддержки у этих вендоров: общение только на английском языке, долгое ожидание запчастей, порой с возможными сюрпризами в виде их самостоятельной таможенной очистки и т.п. Поэтому не удивительна популярность в Enterprise сегменте, несмотря на повышенную стоимость, продукции производителей уровня Tier 1, которые полностью берут на себя все вопросы по послепродажной поддержке.

Стандартная гарантия на СХД Qsan включает в себя русскоязычную поддержку 9x5 NBD в течение 3-х лет с момента покупки. Вендор при наступлении гарантийного случая отправляет за свой счет опережающую замену запчасти со склада в Москве. Так что реальное время ожидания заказчиком нового компонента в большинстве случаев составит всего лишь один рабочий день. При необходимости возможна покупка дополнительных сервисных пакетов, в том числе с обслуживанием на рабочем месте, и расширение гарантийного срока до 5 лет.

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

Подводя итог нашего обзора СХД Qsan XCubeSAN, хочется отметить, что продукт получился весьма интересный, с необходимыми в реальной эксплуатации аппаратными и программными компонентами. Производительность находится на достаточно высоком уровне. А техническая поддержка соответствует ожиданиям от работы с Enterprise продуктами.