В медицине, безопасности и образовании хранить сырое видео нужно не часто. Поэтому статья и акцентирует внимание на видеопроизводстве. Другие отрасли упоминаются в контексте общего роста данных.
Нет, мы не написали свой OSD. Мы позволяем запускать OSS и OST на нашм управляющем узле СХД и привязывать переезд OSS и OST к событиям СХД. Это основная проблема размещения OSS и OST на одном сервере, мы её решили за счёт архитектуры СХД и использование собственного кластерного ПО, а не pacemaker.
Под файлом «стандартного высокого разрешения» имелось ввиду HD 1280x720. С частотой 24 кадра и компрессией 10 бит RGB получаем примерно 88 МБ/с. Сравнивали 88 МБ/с (HD) с 212 МБ/с (2K). Таким образом, разница в 2,5 раза. В 4 раза, действительно, некоторое преувеличение. Спасибо, поправили!
Основная причина использования FC – утилизация производительности RAID-массивов дисковой подсистемы на последовательных операциях доступа. Например, для того чтобы «прокачать» 6 ГБ/с (а именно столько может прокачать данная система) потребовались бы три двухпортовые 10G адаптера (с FC можно обойтись одним).
В данном сценарии мы фокусируемся не на бюджетном решении, а на оптимальном решении для одновременной работы с несколькими (до 4-х) потоками 4K-видео потоков.
Назвать конкретную «точку перехода» с условного 10G Ethernet на условный FC 16Gb сложно. Все зависит от типа нагрузки (размер кадра, частота кадров, сжатие) и количества монтажных станций, с которых ведется параллельная работа над проектом (то есть от количества одновременных сессий на СХД).
Например, для 4 станций, оперирующих с 1 потоком 4К-видео каждая, необходимая пропускная способность составит 4 х 1,5 ГБ/с = 6 ГБ/с. При этом ограничение 10G Ethernet – 1 ГБ/с. В таком случае необходимо использовать Fibre Channel.
При прочих равных использовать SAS все-таки предпочтительнее. Аргументы в пользу SAS: надёжность, время наработки на отказ, возможность использования в двухконтроллерной конфигурации.
IRP Priority ограничивается средой Windows, а модуль QoSmic позволяет распределять нагрузку в кроссплатформенной среде: при работе с MacOS, Windows, Linux. Особенно актуально это при организации рабочих станций для post production.
ответы на ваши вопросы:
— дедуп есть;
— флэш-кэш есть, пока только на чтение, в этом году выйдет и на запись;
— снапшотов пока нет, планируем сделать
— nfs/cifs/iscsi/fc — всё поддерживаем, а ещё infiniband и SAS;
— ставится как монолит, дистрибутив на основе Линукс ставится на голое железо, удобно в графическом интерфейсе, управляется через веб (графический интерфейс) и через консоль;
— под виртуализацию есть поддержка VAAI, совместимы с vSphere и Hyper-V;
— Стоимость лицензии RAIDIX определяется функциональностью (1 или 2 контроллера, протоколы доступа (типы интерфейсов), кэш, QoS) и количеством дисков. Нет ограничений по сокетам, интерфейсам или количеству ТБ. Контакты есть на сайте, обращайтесь, цены озвучим, решение подберем.
— потестировать тоже есть возможность, необходимо связаться с нами
Коллеги, «В данной статье мы хотим рассказать о том какие требования к железу предъявляет RAIDIX, описать варианты развертывания нашего SDS, привести примеры аппаратных конфигураций СХД на базе RAIDIX и возможные сферы их применения».
В данной статье мы ни слова не говорим о функциональности нашего продукта, статья о другом. Более того, если вы обратите внимание на сферы применения перечисленных конфигураций, то поймете, что интересующие вас фичи там совсем не нужны, они там лишние. Там нужны: throughput, большой объём+большая плотность+полезная ёмкость хранения, надежность и отказоустойчивость, адекватная цена. И это всё у нас есть.
Ceph — это распределенное хранилище. Это свободный софт, развернуть его не просто, поддерживать придется самостоятельно. У него куча багов и проблем. Он не быстрый.
RAIDIX — единое хранилище, не распределенная, софт для создания классической одно- или двухконтроллерной СХД. У нас коммерческий продукт, есть поддержка. Приведенные конфигурации для указанных сфер применения, будут лучше по характеристикам и ниже по цене, чем у конкурентов.
Открытых данных нет. Наш опыт тестирования ZFS показал, что высокой производительности от неё ждать не стоит. Собственно это касается всех свободных/бесплатных SDS.
RAIDIX позволяет работать с большими raid-группами с контрольными суммами, вплоть до 64 дисков на группу. При использовании больших дисков на 6-12ТБ мы рекомендуем объединять в одну группу до 12-24 HDD. Т.е. в одну группу RAID-6 (или RAID-7.3 или RAID-N+M) можно спокойно объединять 24 диска по 10-12ТБ, все будет хорошо. И это важное преимущество, поскольку увеличивается полезная ёмкость.
Можно, но возрастает избыточность. Мы хотим переживать быстро один отказ, так как это более вероятное событие, из-за этого для быстрого восстановления одного отказа у нас один empty-block.
Регенерирующие коды, которые мы тут описали, похожи внешне на RDP, EVENODD и другие XOR-based схемы. Однако, в отличие от них регенерирующие коды обладают таким прекрасным свойством, что при восстановлении отказавшего столбца (~диска/ узла кластера) требуются данные только с половины «выживших» строк, что существенно понижает количество переданных данных при восстановлении. Большинство XOR-based кодов требуют для восстановления одного столбца (~диска/ узла кластера) чтение всех строк, т.е. всего страйпа.
Для сухого нужно писать отдельную статью. Могу сделать мокрое сравнение: для задач видеонаблюдения мы интереснее, как по цене так и по технологичности.
Основная причина использования FC – утилизация производительности RAID-массивов дисковой подсистемы на последовательных операциях доступа. Например, для того чтобы «прокачать» 6 ГБ/с (а именно столько может прокачать данная система) потребовались бы три двухпортовые 10G адаптера (с FC можно обойтись одним).
В данном сценарии мы фокусируемся не на бюджетном решении, а на оптимальном решении для одновременной работы с несколькими (до 4-х) потоками 4K-видео потоков.
Назвать конкретную «точку перехода» с условного 10G Ethernet на условный FC 16Gb сложно. Все зависит от типа нагрузки (размер кадра, частота кадров, сжатие) и количества монтажных станций, с которых ведется параллельная работа над проектом (то есть от количества одновременных сессий на СХД).
Например, для 4 станций, оперирующих с 1 потоком 4К-видео каждая, необходимая пропускная способность составит 4 х 1,5 ГБ/с = 6 ГБ/с. При этом ограничение 10G Ethernet – 1 ГБ/с. В таком случае необходимо использовать Fibre Channel.
www.raidix.ru
www.raidix.ru/files/RAIDIX-Funkcionalnye-harakteristiki.pdf — здесь описание продукта и функциональность, то, что вас интересует
habrahabr.ru/company/croc/blog/246155
ответы на ваши вопросы:
— дедуп есть;
— флэш-кэш есть, пока только на чтение, в этом году выйдет и на запись;
— снапшотов пока нет, планируем сделать
— nfs/cifs/iscsi/fc — всё поддерживаем, а ещё infiniband и SAS;
— ставится как монолит, дистрибутив на основе Линукс ставится на голое железо, удобно в графическом интерфейсе, управляется через веб (графический интерфейс) и через консоль;
— под виртуализацию есть поддержка VAAI, совместимы с vSphere и Hyper-V;
— Стоимость лицензии RAIDIX определяется функциональностью (1 или 2 контроллера, протоколы доступа (типы интерфейсов), кэш, QoS) и количеством дисков. Нет ограничений по сокетам, интерфейсам или количеству ТБ. Контакты есть на сайте, обращайтесь, цены озвучим, решение подберем.
— потестировать тоже есть возможность, необходимо связаться с нами
В данной статье мы ни слова не говорим о функциональности нашего продукта, статья о другом. Более того, если вы обратите внимание на сферы применения перечисленных конфигураций, то поймете, что интересующие вас фичи там совсем не нужны, они там лишние. Там нужны: throughput, большой объём+большая плотность+полезная ёмкость хранения, надежность и отказоустойчивость, адекватная цена. И это всё у нас есть.
На ваши вопросы ответим отдельно.
RAIDIX — единое хранилище, не распределенная, софт для создания классической одно- или двухконтроллерной СХД. У нас коммерческий продукт, есть поддержка. Приведенные конфигурации для указанных сфер применения, будут лучше по характеристикам и ниже по цене, чем у конкурентов.
RAIDIX позволяет работать с большими raid-группами с контрольными суммами, вплоть до 64 дисков на группу. При использовании больших дисков на 6-12ТБ мы рекомендуем объединять в одну группу до 12-24 HDD. Т.е. в одну группу RAID-6 (или RAID-7.3 или RAID-N+M) можно спокойно объединять 24 диска по 10-12ТБ, все будет хорошо. И это важное преимущество, поскольку увеличивается полезная ёмкость.