СХД QSAN в качестве конкурента продукции брендам Tier 1

    Современная 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. Помимо ответа на вопросы по поводу общей производительности, можно также понять, что дает более производительный процессор в СХД (на самом деле между сериями есть еще разница в объеме предустановленной кэш памяти, но в данных тестах этот показатель был одинаковый).


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


    Посмотреть графики тестов

    Описание стенда:


    4 node Cluster на базе серверов Dell PowerEdge R740xd


    • 8 Intel Xeon Gold 6130 CPU for 269GHz в кластере (Два на ноду, 2.1GHz, 16-cores, 22MB Cache)
    • 1TB RAM (256GB на ноду, 16GB x 16 DDR4, 128GB на CPU)
    • 4 x Emulex 16GB dual-port FC HBA
    • 4 x Mellanox ConnectX-4 rNDC 25GbE dual-port NIC

    На СХД было создано 2 пула RAID10 по 12 дисков в каждом. По одному пулу на каждый контроллер СХД. На каждом пуле было создано по одному тому размером ~5TB.
    В качестве тестового ПО использовался пакет VDBench от Oracle, который помимо тестов на случайный и последовательный доступ эмулирует работу баз данных SQL и Oracle, а также работу VDI окружения.


    Используемые профили:


    • 4K Random Read: 100% Read, 128 threads, 0-120% iorate
    • 4K Random Write: 100% Write, 64 threads, 0-120% iorate
    • 64K Sequential Read: 100% Read, 16 threads, 0-120% iorate
    • 64K Sequential Write: 100% Write, 8 threads, 0-120% iorate
    • Synthetic Database: SQL and Oracle
    • VDI Full Clone and Linked Clone Traces


















    По результатам тестов можно отметить весьма достойную производительность СХД 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 продуктами.
    Поделиться публикацией
    Комментарии 38
      0
      Хотелось бы увидеть приблизительную цену на некоторые наиболее популярные модели.
        0
        Наибольшей популярностью пользуется средняя серия XS3200 как наиболее оптимальная с точки зрения стоимости/производительности. Цены на этой площадке обсуждать вроде как не принято…
        0

        Подскажите а контролееры работают Active-Active? Возможен ли интерфейс FC?

          0
          Да, конечно, контроллеры работают в режиме Active-Active. По другому в современных СХД, наверное, уже и не возможно.
          FC доступен при помощи карт расширения (до 8 портов на контроллер).
            0
            «Да, конечно, контроллеры работают в режиме Active-Active. По другому в современных СХД, наверное, уже и не возможно»
            По другому возможно, и даже хорошо работает. Посмотрите на Pure, Nimble.
              0
              Мы же про классические СХД, а не про All Flash говорим.
                0
                Nible это не ALL Flsah, вполне себе гибрид.
          0
          «Они использовали 24 штуки Toshiba PX04SV SAS 3.0 SSD. Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД»
          business.toshiba-memory.com/en-us/product/storage-products/enterprise-ssd/px04svb-px04svqxxx.html
          Sustained 4KiB Random Read 270,000 IOPS
          Этот массив не может нагрузить эти диски. Узким местом является производительность контороллеров. 2 мс для All flash это очень много.
          Стоимость нужно сравнивать Tb/$ при равной производительности, и в этом случае я не думаю что будет большая разница.
            0
            Вы сравниваете поизводительность диска внутри сервера без прослойки в виде RAID и прочих уровней абстракции. При этом сервер имеет монопольный доступ к SSD. В СХД такой режим в принципе не возможен. Между ОС и диском есть немало элементов с ненулевыми задержками и ограниченными очередями. Плюс СХД предназначена для одновременной работы с многими хостами. И поэтому не в режиме работы «однин хост — один том» не удастся достичь пиковой производительности СХД.
            Что касается latency в 2 мс, это просто мы условно ограничили показатель IOPS как некий «приемлимый». Если взглянуть на график, большая часть теста проходит с показателем не более 1 мс.
              0
              Я не сравниваю, я указал что диски не являются узким местом для этой системы. Мы с вами написали одно и тоже, данная производительность ограничивается контроллерами, а не дисками. Вы расписали в каких местах тормозит контроллер. Latency в 2 мс для All Flash не является «приемлемым», если вы сравниваете с Enterprise. Если бы Вы указали в тексте значение IOPS для 1 мс, то выглядело бы значительно лучше, тем более разница не так уж и велика.
              0

              На вкус и цвет все фломастеры IOPS разные. Для меня вообще всегда странно выглядит тест с 100% чтения. Вы где в жизни такие сервисы видели? Которые только читают и ничего не пишут. Или читают только блоком одного размера. А если читать блоком 64KiB, то 270k IOPS резко превратятся в тыкву? Это уже не говоря про то что отдельный диск, с возможностью потерять все, и диск в RAID это совершенно разные диски, в том числе по производительности. И сравнивать их в лоб некорректно. Кстати а Тошиба указала при каком количестве потоков и с какой latency один диск выдает 270k IOPS? А сможете взять 5 таких дисков и на одном сервере показать нам 1 миллион IOPS с разумным временем отклика хотя бы в синтетике?

                0
                Приведены тесты не только для 100% чтения, но и для симуляции реальных задач. И да, с 64КБ блоком производительность будет минимум в 16 раз ниже, чем с 4КБ. Это нормально.
              0
              А почему графики с ватермарком сторайджревью? Это перевод статьи? Или вы просто у них графики взяли?
                0
                Мы указали в статье, что взяли их результаты тестов
                  0
                  В таком случае принято указывать ссылку на оригинал.
                  И если вы сами тесты не проводили, как вы сделали вывод, что
                  Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД

                  где графики нагрузки на контроллеры? порты?
                    0
                    где графики нагрузки на контроллеры? порты?

                    Даже грубый подсчет для максимальных показателей 450K IOPS@4K даст нагрузку на порты менее 16Gbit/s, а для последовательного доступа 6000 MB/s ~48Gb/s. Что сильно меньше сумарной пропускной способности портов СХД в тесте (8x 16Gb/s).
                    По контроллерам, к сожалению, СХД не предоставляет отчета о нагрузке.
                      0
                      По контроллерам, к сожалению, СХД не предоставляет отчета о нагрузке.

                      тогда тем более не понятно, как сделан вывод
                      Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД

                      и на чём он основывается у вас. Или это вы так интерпретировали фразу в оригинале:
                      Overall, the XS5200 did quite well, taking full advantage of the Toshiba PX04 SAS3 SSDs we installed.


                      Вопрос в применимости данных решений, вот читаем в оригинале:
                      Of course, there's somewhat of a compromise; the feature set, interface and software integrations with popular packages like VMware leave a little to be desired as you look more upmarket at enterprise needs.

                      Ну и отсутствие компресси, дедупа и тд так же очень влияет, в том числе и на производительность. И да, при отсутствии дедупа/компресси придётся брать qsan раза в 3 большего объёма, чем его конкуренты Tier 1, и тут ещё вопрос — как оно в итоге по цене то выйдет.
                        0
                        И да, при отсутствии дедупа/компресси придётся брать qsan раза в 3 большего объёма, чем его конкуренты Tier 1, и тут ещё вопрос — как оно в итоге по цене то выйдет

                        Компрессия/дедуп будет скоро (~ 3-4 квартал) с обновлением прошивки. Что касается стоимости решения целиком, то по сравнению с конкурентами, где дедуп действительно эффективен и не приводит к катастрофическому падению производительности, Qsan оказывается в выигрыше.
                          0
                          Компрессия/дедуп будет скоро (~ 3-4 квартал) с обновлением прошивки.

                          Вот когда появится, когда будет видна эффективность и на сколько это будет влиять не производительность, тогда и обсудим. Написать софт — дело не простое, даже вон IBM в своём новом 9100 не справился софтовую компресси/дедуп сделать, воткнули асик, а уж про качество ПО азиатских компаний я промолчу.

                          Qsan оказывается в выигрыше

                          вы уж тогда спеки с ценами покажите, иначе это просто голословные заявления. Или с конкурентами по list-price сравниваете? :)
                            0
                            Насчет IBM вы не правы: дедупликация у IBM осуществляется «софтово» (если, конечно, считать софтовым вычисление sha на современных процессорах Intel). Компрессия в младшем midrange IBM (Storwize v5030) делается софтово. В старшем (Storwize v7000) — на «ускорителях» Intel QAT, в FlashSystem 9100 — либо на спроектированных IBM`ом NVMe накопителях аппаратно, либо снова аппаратно, но уже на встроенных в процессоры Intel QAT (для работы с обычныеми NVMe либо SAS дисками). Использование аппаратных ускорителей необходимо для обеспечения производительности при работе технологий data reduction, недостижимой конкурентными системами. Считаю, что IBM очень сильно угадали, сделав ставку на QAT в начале 2010х.
                              0
                              Так в чём именно я не прав? Что там не асик? Это не на столько принципиально каким конкретно аппартаным решением эти действия производить. Сторвайзы скоростью не выделяются, соответственно для FlashSystem 9100 была выбрана аппаратная реализация, т.к. IBM распихал процы уже везде где только можно это сделать и их ресурсы надо на что то тратить. Всё это сказывается опять-таки на стоимости.
                                –1
                                Вы не правы в том, что, цитирую, «IBM в своём новом 9100 не справился софтовую компресси/дедуп сделать». Это как сказать, что Вальтер Рёрль не справился выиграть гонку пешком, поэтому сел на машину. Т.о. вы не правы два раза: 1. Дедупликация там таки софтовая 2. у IBM есть реализация софтовой компрессии, но конкрентно для названной вами системы была выбрана аппаратная реализация для того, чтобы быть быстрее конкурентных систем с софтовой реализацией.

                                Ну и по поводу того, что сторвайзы не выделяются скоростью — это ваши домыслы.
                                  0
                                  это ваши домыслы

                                  Ну как сказать — вон стоят и не блещут. какой сторвайз с софтовым дедупом и компрессией можно по производительности хотя бы со старшим фасом сравнить? Судя по нашим тестам — никакой.
                                  1. Дедупликация там таки софтовая

                                  Мы же уже выше обсудили, что в 9100 она аппаратная.

                                  была выбрана аппаратная реализация

                                  По тому что с текущей реализацией их софтовой компрессии/дедупа производительность крайне не высока в сравнении с конкурентами. О чём я и говорил в самом начале. Что на уроне ПО это нужно ещё грамотно уметь реализовать.
                                    0
                                    Мы же уже выше обсудили, что в 9100 она аппаратная.
                                    Перечитайте еще раз: дедупликация софтовая, компрессия — аппаратная.
                                    вон стоят и не блещут. какой сторвайз с софтовым дедупом и компрессией можно по производительности хотя бы со старшим фасом сравнить?
                                    Вы создаете искуственные рамки. Сторвайза с соответствующим старшему FAS`у количеством ядер без аппаратной компрессии не существует. Соответственно, с младшим FAS`ом надо сравнивать младший сторвайз, со старшим — старший.
                                      0
                                      Сторвайза с соответствующим старшему FAS`у количеством ядер не существует.

                                      со старшим — старший.

                                      Так не существует с таким же кол-вом ядер или всё-таки надо со старшим сравнивать? Слишком сложная для меня фраза. Давайте так, сравнивали старший V7000 со средним FAS8200, сторвайз курил в сторонке.
                                      Ещё был V5030 против 2650, но не помню сколько с него IOPS тогда сняли. Там было примерно одинаково, но 2650 — младший, а вот 5030 — нет.
                                        0
                                        Так не существует с таким же кол-вом ядер или всё-таки надо со старшим сравнивать? Слишком сложная для меня фраза.
                                        Поправил, не существует без плат аппаратной компрессии.
                                        Ещё был V5030 против 2650, но не помню сколько с него IOPS тогда сняли. Там было примерно одинаково, но 2650 — младший, а вот 5030 — нет.
                                        Что и требовалось доказать: несмотря на маркетинговые разделения, FAS2650 является прямым конкурентом v5030: у них одинаковое количество ядер в контроллерах (6) и одинаковое количество кэш (32) и сопоставимая цена. Отсюда одинаковый результат. Аналога «младших» storwize (5010-5020) в линейке FAS не существует
                                        сравнивали старший V7000 со средним FAS8200, сторвайз курил в сторонке.
                                        Тут надо уточнить, какие конфигурации сравнивали и какой был сторвайз: v7000 мог быть -124 (4 ядра на контроллер), -524 (8 ядер на контроллер), -624 (10 ядер на контроллер) при том, что сравниваете с 16и-ядерным FAS8200. Ну и по дискам-прошивкам нюансы конфигурации могли быть.
                                          0
                                          В общем приходите в storagediscussions, расскажете какой IBM крутой и классный
                                            0
                                            imageСпасибо, конечно, за приглашение. Про IBM предпочитаю рассказывать с пользой для дела. Могу вот статью запилить про 9100.
                                              0
                                              Запилите-запилите
                0
                вы уж тогда спеки с ценами покажите, иначе это просто голословные заявления. Или с конкурентами по list-price сравниваете? :)

                Вы можете сравнить цены только либо через list price (что более или менее встречается в открытом доступе), либо придя к партнеру/дистрибьютеру с реальным проектом. По другому в IT мире никак.
                  0
                  Так вот я вас и спросил — вы то как сравнивали? Лист это не то что пальцем в небо, это просто абстрактная цифра которая может менять в вариациях до 90+%.
                    0
                    Мы строим решения для своих клиентов не только на базе Qsan. Поэтому имеем представление о ценообразовании других брендов.
                      0
                      По вашим ответам можно сделать вывод, что вы сравнивали воду с ватой. Спасибо, на этом можно закончить.
                  0
                  Был опыт эксплуатации QSAN U600Q в конфигурации из трёх корзин, в сумме 60 дисков по 6Тб, итого примерно 300Тб хранилище под систему видеонаблюдения.
                  Изначально систему ставил и настраивал подрядчик, и собрал один LUN с расшаренной по samba папкой.
                  Полгода сервера видеонаблюдения писали в сетевую папку и все было хорошо, пока, внезапно, скорость записи не стала падать примерно до нуля. В такой момент даже переставал работать web-интерфейс. Техподдержка QSAN отвечала в духе вот вам новая прошивка.
                  На панелях хранилища горели предупреждения вида: хранилище заполнено на 90% сейчас будет performance degradation, который мы и получали. Софту системы видеонаблюдения на тот момент не удавалось в автоматическом режиме удалять старые записи. Наблюдая за всем этим безобразием возник вопрос. А здесь правда настроен RAID 0 из 60 дисков? На что подрядчик отвечал, нет там JBOD. Полистав документацию и интерфейс пришли к выводу, что JBOD-ом там называется способ подключения корзин, а собственно единственный LUN действительно лежит на нулевом рейде, да, из 60 дисков.
                  Все данные отправились в /dev/null и хранилище настроили на шесть LUN, которые отдавались по iSCSI. Все прекрасно заработало, за исключением того, что после перезагрузки сервера видеонаблюдения Windows не могла подключиться к iSCSI-диску. Покопавшись, выяснили, что винда после ребута пытается подключиться по адресам вида 169.254.x.x которые рапортует ей iSCSI-target со своих отключённых сетевых интерфейсов. Нашли в настройках хранилища лишние адреса для iSCSI, и выключили их. Только осталось непонятно, почему он их отдаёт, если там нет активного линка.
                  Чуть больше полгода все было тихо, пока снова хранилка не заполнилась на пресловутые 90% хотя в самой винде диски были заполнены на 85% После переписки с техподдержкой выяснилось: сам qsan использует внутри zfs, и чтобы все работало нормально, нужно чтобы всегда было свободно внутри более 10% и нужно было заранее разбивать LUN-ы с учетом этого резерва. А в доках про это нигде нет, видимо это рассказывают только на вендорских курсах. В нашей ситуации хранилище ничего не знает про свободные 15% на уровне вышележащей ФС, тк отдаёт целый LUN. Но можно в настройках хранилища включить zero deduplication, а в самой винде пройтись по диску sdelete.
                  На некоторых LUN удалось включить deduplication, а на других хранилище отвечало, у меня нет места, в итоге вставили дополнительный диск. Им оказался первый попавшийся десктопный 500gb.
                  Прогнали в винде диск через sdelete, и свободное место на хранилище стало совпадать с таким же внутри самих iscsi-дисков. Далее на вопрос, можно ли мигрировать данные с этого дополнительного диска на 500гб, начались расхождения. В web-интерфейсе есть некая кнопка free disk, теоретически сама zfs умеет освобождать диски, но техподдержка отвечала, что тогда данные с LUN-а пропадут.
                  Все это поработало ещё несколько месяцев, пока винда не начала находить ошибки на уровне ntfs.
                  Не помню, чем это уже все закончилось, но нашёлся следующий подрядчик, который со словами, вы все сделали неправильно, опять пересобрал хранилище отправив данные как всегда в null
                    0
                    Для нормальной работы ZFS действительно требуется ~10% незанятого места на пуле. Увы, такова особенность работы этой файловой системы. Причем, удаленные данные внутри LUNов средствами файловой системы хостов на уровне ZFS не удаляются (=не высвобождаются), о чем вам, по вашим словам, и сообщила техподдержка (compression enabled, sdelete). Поэтому грамотным решением в вашем случае является резервирование 10% пространства на пуле как не размеченное. Надеемся, ваш нынешний подрядчик так и поступил.
                    Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.
                      0
                      И важное дополнение. В описываемых в статье системах ZFS не используется, поскольку это — блочные СХД. В то время как U600 — это NAS
                        0
                        RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных

                        Предполагалось, если там zfs, то она может используемые блоки данных мигрировать на другие диски, и этот диск можно вытаскивать. Только не везде явно пишут об ограничениях:
                        However, this operation fails if no other valid replicas of the data exist. For example:
                        # zpool detach newpool c1t2d0
                        cannot detach c1t2d0: only applicable to mirror and replacing vdevs
                          0
                          Если у вас под ZFS расположен RAID0, то никакими средствами вы не высвободите диск

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое