1. Под «протоколами хранения» понимаются протоколы используемые именно в SAN сетях, в англоязычных публикация, есть понятие «storage protocols», обозначающее протоколы передачи данных в привязке к используемым в сетях хранения данных, протоколам передачи данных. Кстати Вас не смущает, что существует сеть хранения данных?
Что касается, термина «протоколы объектного хранения» — это калька с английского «Object Storage Protocols», в статье можно было использовать другие формулировки – например — «протоколы объектного доступа к системах хранения данных». так работает в основном с западными компаниями, то не произвольно проскакивают англицизмы. В блоге EMC – например прям так и пишут https://community.emc.com/docs/DOC-33680
2. Массово не хватает 8Гбит для производства кино, сейчас самый популярный формат при видеомонтаже коммерческий фильмов — несжатый 4K. Один такой формат требует 1.5ГБ/с. Обычно на одной рабочей станции одновременно обрабатывают 2-4 потока, т.е. на одну монтажную станцию нужно 3-6ГБ/с. В производстве фильмов участвуют несколько таких станций.
Только вчера прилетел проект 45ГБ/с на запись с 5 серверов, т.е. по 5ГБ/с с каждого. С ограничением для СХД 2U, а для серверов 1U. Как это впихнуть в 8Гбит/с?
Если какие-то предложения вызывают серьезные вопросы, то мы готовы их выслушать.
Вероятно, мы не смогли изложить мысли должным образом и с вашей помощью готовы раскрыть материал более подробно.
Хорошее добавление. Мы не забыли этот момент, просто статья ориентирована не на гиперконвергентные решения, а на классических решениях SAN.
Обзоры этих решений заслуживают отдельной статьи, возможно, даже не одной.
Безусловно RoCE и iWARP сокращают latency, а вопрос затрат при переходе на них довольно дискуссионный.
При операциях последовательного чтения суммарные производительности RAID 10 и RAID 6 незначительно отличаются. Более того, наш RAID 6 часто работает быстрее. Это получается в связи с тем, что у нас есть такая функция, как Advanced Reconstruction.
Работает это так: на все чанки в стайпе (Пусть, он будет размером 10+2) отправляются запросы на чтение. Дождавшись первые 10 чанков мы восстанавливаем оставшиеся по контрольным суммам. Делается это со скоростью доступа к RAM, алгоритм восстанавливает со скоростью 35 ГБ/с на ядро. В десятке же мы будем ждать самого медленного.
Периодическое возникновение ошибок чтения при тех-же параметрах никак не влияет на производительность по тем же причинам. Мы не ждем, пока диск попытается перечитать область или вернет ошибку. Мы просто восстанавливаем чанк по контрольным суммам и забываем про него.
Все хуже, если чтение не полнострайповое. В этом случае при возникновении ошибки нужно дочитать страйп и восстановить данные чанка. А это-дополнительные IO и задержки. Но на нормальных дисках вероятность ситуации ничтожно мала и никак не повлияет на средний результат и все же, адаптивный Read Ahead сделан в первую очередь для полнострайповых чтений.
Посмотрите ответ на предыдущий комментарий, полагаю, что там может быть ответ на интересующий вас вопрос.
«Простая математика» охватывает именно представленные в статье расчеты.
Мы не утверждаем, что Незнайка однозначен и «рандомен». Мы взяли некоторые характерные его черты и использовали их в качестве иллюстрации (то же самое со Знайкой). Что же касается рассуждений о пост-капиталистических реалиях, то это, пожалуй, выходит за пределы наших профессиональных компетенций :)
Алгоритм упреждающего чтения для последовательных потоков по умолчанию включен в наше решение. Его можно выключить, но в «реальных» условиях этого никто не делает. Поэтому сравнительных цифр с «полей» мы не получаем. Ниже проведен тест с использованием бенчмарки FIO c включенным и выключенным read ahead.
Параметры системы: в дисковой корзине 24 HDD, RAID6, LUN развернут на всем рэйде. Кэш рэйда — 16 гигабайт. Инициатор подключен по Infiniband напрямую к таргету. Конфиг для 1 потока: [global], direct=1, ioengine=libaio, iodepth=32, runtime=180, blocksize=1M, rw=read, filename=/dev/sdc.
Показатели чтения с выключенным read ahead: 1369 MB/sec
Показатели чтения с включенным read ahead: 2940 MB/sec
При этом максимум пропускной способности в этой конфигурации будет чуть ниже 3240 MB/sec (т.к. есть нечитаемые данные с контрольных сумм).
Мы бы хотели призвать читателей придерживаться темы статьи и обсуждать, в первую очередь, математические и технологические вопросы, а не коммерческие или лицензионные :-) На последние мы с удовольствием ответим через запрос на сайте «Рэйдикс».
По существу вопроса отвечаем: страница Инструкции по установке и настройке системы, которую вы упоминаете, содержит скриншот нашего типового лицензионного соглашения с конечным пользователем. Поскольку ПО RAIDIX является проприетарным, ООО «Рэйдикс» как правообладатель вправе устанавливать ограничения использования ПО, в том числе ограничивать его распространение.
Такие полиномы или коэффициенты матриц выбирают чтобы упростить умножения в Полях Галуа при кодировании а так же упростить векторизацию. Например, если посмотрите на нашу схему то увидите что количество XOR для умножения на примитивный элемент (х) равняется количеству ненулевых битов образующего поля многочлена, кроме первого и последнего бита. Мы берем полином f=100011101=0x11d. Его же используют и в интеловской библиотеке, но с другой векторизацией. Есть и другие многочлены, но целесообразно брать те, в которых поменьше единиц — так считаться будет быстрее. Вот тут можно найти список лучших неприводимых многочленов степени до 1000 (www.hpl.hp.com/techreports/98/HPL-98-135.pdf)
Скорость алгоритма кодирования значительно выше, чем скорость дискового массива или интерконнекта, т.е. время расчета контрольных сумм не является узким местом datapath.
Не совсем корректно выполнять сравнение RAID систем от RAIDIX и S2D, которые используются в распределенных и гиперконвергентных инфраструктурах и создавались под разные задачи.
Но все же, вот основные отличия.
• RAIDIX создавался для инфраструктур, где требуется «перемалывать» максимальное количество данных за единицу времени и требуется который QoS, имеет классическую архитектуру и может достигать производительности более чем 20 ГБ/с на запись и чтение с избыточностью около 20% и на 2х узлах. При этом производительность в режиме отказов остается примерно такой же.
• A S2D, судя по отзывам, которые, которые, конечно, нужно проверять, (также как и маркетинговые бумажки про 1,5Tib/s и 60Gb/s, распространяемые партнерами MS), очень плохо себя чувствует, когда используется защита данных с контрольными суммами, а не репликация. А использование репликации сильно меняет экономику хранения.
• RAIDIX, как классическая хранилка лучше вписывается в имеющиеся инфраструктуры, поддерживает большее количество интерфейсов доступа.
• S2D, конечно, идеально подходит для HCI на основе технологий MS.
Продукты слишком разные и создавались под разные задачи.
Для того, чтобы быть не голословным необходимо проводить тесты в одинаковых условиях и c использованием правильного подхода и, желательно, руками третьих лиц, хорошо разбирающих в обоих продуктах.
Мы будем писать про тесты производительности и подходы и, если лицензионная политика MS не запрещает, поделимся результатами.
Не думаю, что открою для вас Америку, но, все-таки, уточню:
• Цена в таких продукта определяется спецификацией
• Спецификацию конструктивнее обсуждать индивидуально
• Индивидуальное обсуждение реализуется контактной формой
Мы и так открыты для предоставлении информации желающим :) просто этот процесс у нас структурирован и упорядочен — вы заполняете форму на сайте, а наш специалист дает на него развернутый ответ.
п.с. демо-версия предоставляется без лимита по дискам, но с ограничением времени тестирования.
• InfiniBand
• NVMe
• PCIe
• SAN-сети на основе Ethernet
А вообще протоколов передачи много, есть даже RFC 1149 на передачу IP пакетов посредством почтовых голубей, так что с его помощью можно организовать целую сеть хранения данных.
Что касается, термина «протоколы объектного хранения» — это калька с английского «Object Storage Protocols», в статье можно было использовать другие формулировки – например — «протоколы объектного доступа к системах хранения данных». так работает в основном с западными компаниями, то не произвольно проскакивают англицизмы. В блоге EMC – например прям так и пишут https://community.emc.com/docs/DOC-33680
2. Массово не хватает 8Гбит для производства кино, сейчас самый популярный формат при видеомонтаже коммерческий фильмов — несжатый 4K. Один такой формат требует 1.5ГБ/с. Обычно на одной рабочей станции одновременно обрабатывают 2-4 потока, т.е. на одну монтажную станцию нужно 3-6ГБ/с. В производстве фильмов участвуют несколько таких станций.
Только вчера прилетел проект 45ГБ/с на запись с 5 серверов, т.е. по 5ГБ/с с каждого. С ограничением для СХД 2U, а для серверов 1U. Как это впихнуть в 8Гбит/с?
Вероятно, мы не смогли изложить мысли должным образом и с вашей помощью готовы раскрыть материал более подробно.
p.s. он прекрасный парень и профи своего дела.
Обзоры этих решений заслуживают отдельной статьи, возможно, даже не одной.
Безусловно RoCE и iWARP сокращают latency, а вопрос затрат при переходе на них довольно дискуссионный.
Работает это так: на все чанки в стайпе (Пусть, он будет размером 10+2) отправляются запросы на чтение. Дождавшись первые 10 чанков мы восстанавливаем оставшиеся по контрольным суммам. Делается это со скоростью доступа к RAM, алгоритм восстанавливает со скоростью 35 ГБ/с на ядро. В десятке же мы будем ждать самого медленного.
Периодическое возникновение ошибок чтения при тех-же параметрах никак не влияет на производительность по тем же причинам. Мы не ждем, пока диск попытается перечитать область или вернет ошибку. Мы просто восстанавливаем чанк по контрольным суммам и забываем про него.
Все хуже, если чтение не полнострайповое. В этом случае при возникновении ошибки нужно дочитать страйп и восстановить данные чанка. А это-дополнительные IO и задержки. Но на нормальных дисках вероятность ситуации ничтожно мала и никак не повлияет на средний результат и все же, адаптивный Read Ahead сделан в первую очередь для полнострайповых чтений.
«Простая математика» охватывает именно представленные в статье расчеты.
Мы не утверждаем, что Незнайка однозначен и «рандомен». Мы взяли некоторые характерные его черты и использовали их в качестве иллюстрации (то же самое со Знайкой). Что же касается рассуждений о пост-капиталистических реалиях, то это, пожалуй, выходит за пределы наших профессиональных компетенций :)
Параметры системы: в дисковой корзине 24 HDD, RAID6, LUN развернут на всем рэйде. Кэш рэйда — 16 гигабайт. Инициатор подключен по Infiniband напрямую к таргету. Конфиг для 1 потока: [global], direct=1, ioengine=libaio, iodepth=32, runtime=180, blocksize=1M, rw=read, filename=/dev/sdc.
Показатели чтения с выключенным read ahead: 1369 MB/sec
Показатели чтения с включенным read ahead: 2940 MB/sec
При этом максимум пропускной способности в этой конфигурации будет чуть ниже 3240 MB/sec (т.к. есть нечитаемые данные с контрольных сумм).
По существу вопроса отвечаем: страница Инструкции по установке и настройке системы, которую вы упоминаете, содержит скриншот нашего типового лицензионного соглашения с конечным пользователем. Поскольку ПО RAIDIX является проприетарным, ООО «Рэйдикс» как правообладатель вправе устанавливать ограничения использования ПО, в том числе ограничивать его распространение.
Но все же, вот основные отличия.
• RAIDIX создавался для инфраструктур, где требуется «перемалывать» максимальное количество данных за единицу времени и требуется который QoS, имеет классическую архитектуру и может достигать производительности более чем 20 ГБ/с на запись и чтение с избыточностью около 20% и на 2х узлах. При этом производительность в режиме отказов остается примерно такой же.
• A S2D, судя по отзывам, которые, которые, конечно, нужно проверять, (также как и маркетинговые бумажки про 1,5Tib/s и 60Gb/s, распространяемые партнерами MS), очень плохо себя чувствует, когда используется защита данных с контрольными суммами, а не репликация. А использование репликации сильно меняет экономику хранения.
• RAIDIX, как классическая хранилка лучше вписывается в имеющиеся инфраструктуры, поддерживает большее количество интерфейсов доступа.
• S2D, конечно, идеально подходит для HCI на основе технологий MS.
Продукты слишком разные и создавались под разные задачи.
Для того, чтобы быть не голословным необходимо проводить тесты в одинаковых условиях и c использованием правильного подхода и, желательно, руками третьих лиц, хорошо разбирающих в обоих продуктах.
Мы будем писать про тесты производительности и подходы и, если лицензионная политика MS не запрещает, поделимся результатами.
• Цена в таких продукта определяется спецификацией
• Спецификацию конструктивнее обсуждать индивидуально
• Индивидуальное обсуждение реализуется контактной формой
И это работает :)
п.с. думаю, что нам стоит включить в план еще и коммерческие публикации, а то в теме про математику обсуждать такие вопросы немного неуместно :)
п.с. демо-версия предоставляется без лимита по дискам, но с ограничением времени тестирования.