Компания
140,98
рейтинг
18 декабря 2014 в 09:02

Разное → Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных



В конце 2008 года на тогда ещё небольшую петербуржскую компанию вышел один западный медиахолдинг примерно так:
— Это вы там упоролись по хардкору и приспособили SSE-инструкции для реализации кода Рида-Соломона?
— Да, только мы не…
— Да мне пофиг. Хотите заказ?

Проблема была в том, что видеомонтаж требовал адовой производительности, и тогда использовались RAID-5 массивы. Чем больше дисков в RAID-5 — тем выше была вероятность отказа прямо во время монтажа (для 12 дисков — 6%, а для 36 дисков — уже 17-18%). Дроп диска при монтаже недопустим: даже если диск падает в хайэндовой СХД, скорость резко деградирует. Медиахолдигу надоело с криком биться головой о стену каждый раз, и поэтому кто-то посоветовал им сумрачного русского гения.

Много позже, когда наши соотечественники подросли, возникла вторая интересная задача — Silent Data Corruption. Это такой тип ошибок хранения, когда на блине одновременно меняется и бит в основных данных, и контрольный бит. Если речь о видео или фотографии — в целом, никто даже не заметит. А если речь про медицинские данные, то это становится диагностической проблемой. Так появился специальный продукт под этот рынок.

Ниже — история того, что они делали, немного математики и результат — ОС для highload-СХД. Серьёзно, первая русская ОС, доведённая до ума и выпущенная. Хоть и для СХД.

Медиахолдинг


История началась в 2008-2009 как проект для американского заказчика. Требовалось разработать такую систему хранения данных, которая обеспечивала бы высокую производительности и при этом стоила бы меньше кластера из готовых хайэндовых СХД. У холдинга было много стандартного железа по типу Амазон-ферм — x86-архитектура, типовые полки с дисками. Предполагалось, что «эти русские» смогут написать такой управляющий софт, который будет объединять устройства в кластеры и обеспечивать тем самым надёжность.

Проблема, конечно, в том, что RAID-6 требовал очень большой вычислительной мощности для работы с полиномами, что было непростой задачей для x86 CPU. Именно поэтому производители СХД использовали и используют свои варианты и поставляют в итоге стойку как своего рода «чёрный ящик».

Но вернёмся в 2009 год. Основной задачей в начале проекта было быстрое декодирование данных. Вообще, высокой производительностью декодирования компания RAIDIX (так стали звать наших героев намного позже) занималась всегда.

Вторая задача — чтобы при выходе из строя диска не просаживалась скорость чтения-записи. Третья задача немного похожа на вторую — бороться с проблемами ошибок на HDD, которые происходят неизвестно когда и на каком носителе. Фактически, открылось новое поле работы — обнаружение скрытых дефектов данных на чтение и их исправление.

Проблемы эти были актуальны тогда только для больших, очень больших хранилищ и реально быстрых данных. По большому счёту, архитектура «обычных» СХД устраивала всех, кроме тех, кто постоянно использовал реально большие объёмы данных на чтение-запись (а не работал 80% времени с «горячим» набором данных, составляющим 5-10% СУБД).

Тогда не было как таковых стандартов end-to-end data protection (точнее, не было вменяемой реализации), да и сейчас они поддерживаются далеко не всеми дисками и контроллерми.

Решение первых задач


Начался проект. Андрей Рюрикович Фёдоров — математик и основатель компании, начал с оптимизации восстановления данных, используя типовую архитектуру процессоров Intel. Как раз тогда первая проектная группа нашла простой, но реально действенный подход к векторизации умножения на примитивный элемент поля Галу. При использовании SSE-регистров одновременно умножаются 128 элементов поля на x за несколько XOR. А как вы знаете, умножение любых полиномов в конечных полях можно свести к умножению на примитивный элемент за счет факторизации умножения. Вообще было множество идей с использованием расширенных возможностей процессоров Intel.

Когда стало понятно, что идеи, в целом, имеют успех, но требуется написание продукта уровня ОС для работы на самом низком уровне, сначала был выделен департамент, а потом была основана отдельная компания RAIDIX.

Идей было много, для проработки и проверки были найдены сотрудники университета СПБГУ. Началась работа на стыке науки и технологии — попытки создания новых алгоритмов. Например, очень много работали с обращением матриц (это алгоритмически сложная задача, но очень важная для декодирования). Ковыряли Рида-Соломона, пробовали увеличить размерность поля двух в шестнадцатой, двух в двухсот пятьдесят шестой степени, искали быстрые способы обнаружения Silent Data Corruption. Проводили опыты до прототипов на ассемблере, оценивали алгоритмическую сложность каждого варианта. В большинстве своём опыты давали отрицательный результат, но примерно на 30-40 попыток одна была положительной по производительности. Например, то же увеличение размерности поля пришлось убрать — в теории это было замечательно, но на практике вызвало ухудшение декодирования, потому что сильно увеличивался cache miss (непопадание в кэш).

Дальше шла планомерная работа по расширению RAID 7.N. Проверяли, что будет при увеличении количества дисков, разбиений на диск и так далее. Intel добавил набор инструкций AES для безопасности, среди которых обнаружилась очень удобная инструкция для умножения полиномов (pclmulqdq). Думали, что её можно использовать для кода — но после проверки преимуществ в сравнении с уже имеющейся производительностью не нашли.

Компания выросла до 60 человек, занимающихся исключительно вопросами хранения данных.

Параллельно начали работать над отказоустойчивой конфигурацией. Сначала предполагалось, что отказоустойчивый кластер будет на базе открытого ПО. Столкнулись с тем, что качество кода и его универсальность были недостаточными для решения конкретных практических задач. В это время стали появляться новые проблемы: например, при падении интерфейса традиционно на контроллере проходили перевыборы и переключение мастера. Это в совокупности занимало астрономическое время — до минуты-двух. Потребовалась новая система хостов: начали присваивать каждому очки за сессии (чем больше открытых сессий — тем больше очков), а новые хосты делали discover. В третьем поколении обнаружилось, что даже при синхронной репликации из-за особенностей реализации ПО и железа, сессия на одном контроллере могла появиться раньше, чем на другом — и возникал нежелательный хендовер с переключением. Потребовалось четвёртое поколение — свой собственный кластер-менеджер именно на работу СХД, в котором отказы хост-интерфейсов и бекэнд интерфейсов обрабатывалось правильно, с учётом всех особенностей аппаратного обеспечения. Потребовалось очень существенно доделать ПО на низком уровне, но результат того стоил — сейчас пара секунд на переключение максимум, плюс Active-Active стал куда более правильным. Добавилось автоконфигурирование корзин с дисками.

В конечном счёте сделали очень хорошую оптимизация SATA с переходом на RAID 7.3 — поддержка восстановления данных без потери производительности.

Реализация


Используется решение это вендорами СХД, а также владельцами больших хранилищ из США, Китая и Кореи. Вторая категория — непотоковые задачи интеграторов, чаще всего медиа, суперкомпьютеры, здравоохранение. Во время Олимпийских игр конечным потребителем была студия спортивного вещания «Панорама», они как раз делали картинку с олимпиады. Есть пользователи RAIDIX в Германии, Индии, Египте, России, США.

Получилось вот что:


На одном контроллере: обычное x86 железо + ОС = быстрое и очень, очень дешёвое хранилище.


Два контроллера: получается система с резервированием (но дороже).

Важная фишка — частичное восстановление тома. Есть по три контрольных суммы на каждый страйп:



Благодаря собственному алгоритму расчета RAID-массива есть возможность восстанавливать только отдельную область диска, содержащую поврежденные данные, уменьшая время восстановления массива. Это очень эффективно для массивов больших объемов.

Вторая вещь — реализован механизм упреждающей реконструкции, исключающей из процесса до двух (RAID 6) или до трех (RAID 7.3) дисков, скорость чтения с которых ниже, чем у остальных. Когда быстрее восстановить, чем прочитать — естественно, используется первый вариант.

Работает это так: из K стрипов получается K-N, необходимое для сборки участка данных. Если данные целые, чтение остальных стрипов останавливается.

Это означает, что в RAID 7.3 имея 24 диска при 3 отказах — 12 Гб/с на ядро (4 ядра) — скорость восстановления превышает скорость чтения бекапа и даже обращения к RAM — несмотря на выпадение диска, чтение сохраняется.

Следующая проблема низкого уровня — попытка выполнить чтение битого участка. Даже на энтерпрайз-системах задержка может составить 8 секунд — наверняка вы видели такие «подвисания» HDD-СХД. С учётом этого алгоритма неотдача данных с трёх дисков из 24 означает просто замедление чтение на несколько миллисекунд.

Более того, система запоминает диски с наибольшим временем отклика и перестает отправлять им запросы в течение одной секунды. Это позволяет снизить нагрузку на ресурсы системы. Дискам с наибольшим временем отклика присваивается статус «медленный» и делается уведомление о том, что стоит их заменить.


Скриншоты интерфейса

Учитывая преимущества ОС RAIDIX, многие заказчики решили мигрировать на неё. Здесь сказался недостаток размера компании — сложно петербуржскому разработчику учесть все особенности зеркалирования СУБД и других специфических данных. В последней версии были сделаны большие подвижки в сторону плавной миграции, но всё равно гладко и ровно как у хайэнд-СХД с зеркальным подключением Active-Active не получится, скорее всего потребуется отключение.

Детали


В России лично я вижу возможность получать за минимальные деньги вполне интересные варианты СХД. Мы будем собирать на нормальном стабильном железе решения, которые будут ставиться готовыми к заказчикам. Главное преимущество, конечно, рубль на Гб/с. Очень дёшево.

Например, вот конфигурация:
  • Сервер HP DL 380p gen8 (Intel Xeon E5-2660v2, 24 Гб памяти + контроллеры LSI SAS HBA 9207-8i).
  • На 2 диска разливаем ОС RAIDIX 4.2, оставшиеся 10 – 2Тб SATA.
  • Внешний интерфейс – 10 Гбит/с Ethernet.
  • 20 Тб пространства, которое можно использовать.
  • + Лицензии на 1 год (включающая ТП и обновления).
  • Цена на продажу по прайсу: 30 000$.

Полка расширения, подключенная по SAS с 12 дисками по 2Тб по прайсу – 20 000$. В цену входит предустановка ОС. Под данные на дисках с данными уходит 97% места. LUN неограниченного размера. Поддерживаются Fibre Channel; InfiniBand (FDR, QDR, DDR); iSCSI. Есть SMB, NFS, FTP, AFP, есть Hot Spare, есть ИБП, 64 диска в массиве RAID 0/ 6/ 10/ 7.3 (с тройной четностью). 8 Гб/с на RAID 6. Есть QoS. В результате — оптимальное решение для постпродашна, в частности, цветокоррекции и монтажа, для ТВ-вещания, складывания данных с HD-камер. При семействе узлов можно получить 150 Гб/с без существенного снижения надёжности и даже под Lustre — это область highload.

Вот по ссылке спека и ещё детали (PDF).

Тесты


1. Одноконтроллерная конфигурация. Сервер SuperMicro SSG-6027R-E1R12L 2 юнита. 12 дисков по 4 Тб Sata 3,5”. Внешний интерфейс 8Гбит/с FC. 48 Тб неразмеченного пространства за 12 000$

2. Двухконтроллерная конфигурация. Сервер SuperServer 6027TR-DTRF, в нем 2 платы (как блейды). Добавляем полку с 45 дисками по 4 Тб. Внешний интерфейс 8Гбит/с FC. 180 Тб неразмеченного пространства за 30 000$.

Конфигурация а — RAID 7.3 на 12 дисков. 36 Тб полезной емкости, 0,33$/Гб.
Конфигурация б — три RAID 7.3 по 15 дисков. 0,166$/Гб

FC 8G Performance

Sequential Read/Write

Operation type

Block Size

4.2.0-166, RAID6, Single (ATTO8×2)

IOps

MBps

Avg Max Response Time

read

4K

80360,8

329,1

55,8

128K

11946,7

1565,8

54,3

1M

1553,5

1628,9

98,3

write

4K

18910,8

77,4

44,8

128K

9552,2

1252,0

54,9

1M

1555,7

1631,2

100,4

Здесь — остальные результаты.

В целом


Я очень рад, что у нас «под боком» внезапно нашёлся такой производитель, решающий очень специфические задачи. Своих комплектующих компания не выпускает и других бизнес-сервисов у них нет, системной интеграцией заниматься тоже не планируют — так мы и договорились до сотрудничества. В итоге мой отдел теперь занимается, в частности, решениями на базе ОС RAIDIX. Первые внедрения в России, естественно, пойдут строго вместе с производителями.

Мы обкатали на демо-стенде некоторые конфигурации, и, в целом, довольны, хоть и нашли пару подводных камней (что нормально для новых версий ПО). Если интересны детали по внедрению — пишите на atishchenko@croc.ru, расскажу подробнее, стоит или нет.
Автор: @ATisch
КРОК
рейтинг 140,98

Комментарии (53)

  • +45
    Метафора в заголовке отчасти наркоманская, но по сути рассказаны офигительные вещи, я едва не прослезился от восторга.

    Автор, пиши ещё.
    • +1
      Однозначно, но, главное, чтобы Роском был того же мнения. Спросоня могут ведь и не понять…
      • +10
        А что тут непонятного? Вы что, не любите маслят? Под корюшку-то?
  • +28
    — Это вы там упоролись по хардкору и приспособили SSE-инструкции для реализации кода Рида-Соломона?
    — Да, только мы не…
    — Да мне пофиг. Хотите заказ?

    Вот это было очень, очень хорошо, сделало мое утро фактически. И разработка классная, удваиваю Мицгола.
  • 0
    Очень увлекательно :) Стопицот плюсов!
  • +13
    Замечательно, что у нас еще не перевелись "mad Russians", которые взяли и переписали половину дискового стека просто потому, что это круто.

    Два вопроса:
    1. Какова основа ОС RAIDIX — Linux, FreeBSD или что-то еще?
    2. Ни в коей мере не покушаюсь на вашу интеллектуальную собственность, но если вы выбрали Linux — как там дела с GPL?
    • 0
      Судя по руководству — в основе Linux (Руководство в PDF)
      Второй вопрос остается разработчикам.
    • +3
      Передал вопрос Сергею Платонову — разработчику, вот ответ: «Операционная система GNU/Linux. За основу взят клон RHEL6.
      Часть кода также под GPL, но основные вычислительные модули выделены в отдельные, таким образом чтобы не нарушать GPL. Стандартная практика для компаний, которые делают коммерческие продукты на Linux».
      • +2
        Спасибо. Раз часть кода под GPL, не подскажете, где она опубликована: в репозитории RHEL, ядра (git.kernel.org) или где-то еще?
        • +4
          GPL означает, что исходники обязаны предоставляться приобретателю программы.
          GPL не требует, чтобы исходники выкладывались в публичный доступ.

          Насколько известно, RAIDIX никаких наработок в коммьюнити не возвращал и не собирался.
          Год назад это говорилось прямым текстом.
          Сейчас Гугл по запросам «raidix git», «raidix svn» и «raidix patch» не находит ничего.

          Будем надеяться, что со временем это изменится.
      • +7
        Как-то не тянет на
        Серьёзно, первая русская ОС, доведённая до ума и выпущенная.
    • 0
      Seagate недавно вообще отпилили половину старого мусора и выпустили HDD over Ethernet
      www.seagate.com/tech-insights/kinetic-vision-how-seagate-new-developer-tools-meets-the-needs-of-cloud-storage-platforms-master-ti/
      • 0
        Это все-таки решения для другого класса задач — хранение большого количества неструктурированных редкоизменяемых данных.
        RAIDIX изначально разрабатывался как Active Storage.
        Но на холодные данные тоже смотрим. Реализуем ScaleOut NAS и будем планировать объектный доступ.
    • 0
      Как владелец полки от Рэйдикса могу заявить что там Scientific Linux.
      Конкретно у меня версия 3.3.0 на Scientific Linux release 6.1 (Carbon)
  • +1
  • 0
    InfiniBand (FDR, QDR, DDR)

    Это физика. А протокол какой? iSER, FCoIB или SRP?
    • 0
      Разработчик говорит, что в качестве протокола используются SRP (SCSIoverRDMA). SRP был разработан как основной интерфейс для рынка HPC и, как ни странно, для SMB (Supermicro выпускает недорогие блейд-шасси с IB onboard). Но для HPC сейчас Raidix переходит на модель Custer-In-the-Box, интегрируя кластер PFS и кластер блочного СХД в одной коробке.
  • 0
    Ну, 300 IOPS random write — это маловато, все таки.
    У вас система заточена на последовательное чтение больше всего, на случайных операциях результат не столь хорош:)
    Если нужны IOPS, придется покупать какой-нибуть NetApp:)
    • 0
      Тесты проводились на неиницилизированном RAID, и по сути производительность уперлась в 1 диск.
      На инициализированном RAID с правильными настройками мы получаем несколько тысяч IOPS.
      Но следует всегда учитывать следующее:
      1. Чудес не бывает, RAIDIX использует классическую схему RAID. Поэтому для RAID 7.3, 6 используется механизм read-modify-write. У NetApp нивелирует этот недостаток WAFL, но он несет и свои проблемы.
      2. В жизни не бывает 100% random. При правильном подборе размера кешей и настройках, можно добиться более высокой производительности.
      Поэтому разработчик рекомендует взять демо-систему или договорится с группой внедрения о тестах под ваши параметры.
      • +2
        Тесты проводились на неиницилизированном RAID, и по сути производительность уперлась в 1 диск.

        Немного недопонимаю, как может производительность упереться в один диск, если при записи у нас блоки должны равномерно распределяться по всем дискам? Почему не проводили тестов с правильными настройками и прогретым кешем? Где паттерны 75%/25%, 50%/50%, 25%/75%?
        Чудес не бывает, RAIDIX использует классическую схему RAID. Поэтому для RAID 7.3, 6 используется механизм read-modify-write. У NetApp нивелирует этот недостаток WAFL, но он несет и свои проблемы.

        Да, именно wafl+raid-dp я и имел ввиду, ничего лучше пока придумать не смогли:). Почему вы не сделали copy-on-write? Тем более, идеи можно было черпать, скажем, в ZFS, btrfs, в чем причина выбора классической схемы RAID?
        2. В жизни не бывает 100% random.

        Ну да, скажите это виртуальщикам с сотнями нагруженных виртуальных машин с OLTP — тут почти 100% рандом, другое дело, что паттерн не 100% рандом записи, да.
        • +2
          Причина классического подхода — первоначальная задача, для которой cow и row в лоб не подходят. Вы, наверняка, знаете, что NetApp не позиционирует свои FAS-based продукты для HPC и M&E. Для этого они используют E-Series, бывший LSI. Мы здесь не для того, чтобы поливать грязью технологии конкурента, но и слепо копировать ничего не хотим. Мы думаем, что делать. Есть разные варианты. Например, применять подход, похожий на используемый в LSFS, cow, row и тд
          Сейчас делаем man-to-many rebuild, уходя от классической схемы массивов. Затем будем больше оптимизироваться под flash. Тогда остро и встанет вопрос борьбы с write amplification, flash endurance.
          Тк эта статья популярна, будет свой блог )
        • 0
          При неинициализированном массиве парити не соответствуют данным на информационных стрипах. Поэтому каждая запись в несколько килобайт требует чтение всего страйпа, изменения контрольных сумм и запись измененного стрипа и партии на диски.
          В итоге не получаем никакого распараллеливания.

          При инициализированном массиве, мы имеем парити, соответствующую данным на стрипах с информационными полосами.
          Поэтому, при random write читаем стрип с изменяемыми данными и парити, парити пересчитываем и все записываем обратно. Получаем распараллеливание.

          Конечно, при последовательных обращениях такой проблемы нет.
          Также кэш на запись может помочь.

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

  • 0
    Есть ли снэпшоты, репликация, тиринг, и вообще какие либо сервисы кроме хранения?
    • +2
      В течении этого года Raidix разработал свой volume manager. Линуксовый LVM просто не тянет производительность.
      Как утверждает разработчик, у них есть все, чтобы заработали snapshots, tiering, thinprovisioning, репликация и т.д.
      В 2015 все постепенно добавят. В планах также блочный таргет SAS 12G, SSD кэширование, ScaleOut NAS.

  • 0
    Хорошая статья. Я долго откладывал, но в январе всё же займусь вплотную бенчмарками RAIDX vs что-нибудь, да хотя бы Adaptec 7805 + FC таргет (lio target ск. всего или Open-E). Недавно намерял на Infortrend ESDS 3000 серии (1 контроллер, 2 порта SAS2, 48 дисков SAS2 10k) 3200/2500 МиБ/с на чтение и запись соответственно при средней задержке < 10мс — просто упёрся в контроллер. На выяснение поведения при ребилде не хватило времени.
  • +1
    Вопрос. Насколько своя ос? Для описанного тут вполне достаточно взять linux и написать еще одну реализацию Software RAID массива. Кстати говоря RAID6 в linux вполне использует SSE и прочее.
    • 0
      взять linux и написать еще одну реализацию Software RAID массива

      Это не так просто. Насколько я помню историю развития Avroraid (который теперь RAIDX), то цель изначально была простой — быстрая реализация RAID-стека для видеомонтажников плюс собственный FC таргет для HBA производства ATTO. Им важен QoS — никаких провалов при потере дисков и ребилде, так и просто высокая производительность. В те годы (2010-2011) производительность готовых СХД начального уровня и отдельный PCI RAID на запись в RAID-6 упиралась примерно в 1-1.3ГБ/с (контроллеры на чипе LSI 2108 до сих пор выпускаются, например).
      Вначале всё это выглядело не очень: куча костылей к RHEL5, много действий в консоли, какая-то кривая надстройка к webmin, но производительность действительно была достойной.
      В плане администрирования давно всё поправили. Последний раз, когда я видел RAIDX, это был Scientific Linux 6-й ветки, современная и удобная веб-морда. Дело осталось за функционалом: таргеты под другие интерфейсы, репликация и т.д.
      • +2
        Это не так просто. Насколько я помню историю развития Avroraid (который теперь RAIDX), то цель изначально была простой — быстрая реализация RAID-стека для видеомонтажников плюс собственный FC таргет для HBA производства ATTO.

        Это скажем проще чем писать свою ОС с нуля для x86. Ну а так как я думал, не совсем своя ОС, а модифицированный Linux. Ну а морда то видно что люди изучали этот вопрос. Обычно как раз таки у таких продуктов управлятор ужасен :)
  • 0
    А потом вам LSI'ка кладёт весь бэкплейн (или бэкплейн всю LSI'ку), и, здравствуй, highload.
    • 0
      Я в курсе насчёт Вашего знаменитого lsi-sata-fuckup.sh, но вот как-то не срабатывает он. Пробовал год назад на каких-то SATA SSD + LSI 2308 HBA + LSISAS2X36. ЧЯДНТ? Наверное, такой серьёзный баг, всплывший 2 года назад не мог оставаться неисправленным. При такой доле на рынке SAS HBA и экспандеров ситуация «да он же просто не работает этот ваш LSI» долго актуальной быть не может.
      • 0
        Используете SSD. У SSD secure erase делается дропом всего и вся и очень быстро, а у HDD длится часами.

        У меня сейчас нет места, где можно проверить, просто вопрос в другом — 'SCSI bus hangs' я видел и на других контроллерах. Более того, в дорогих СХД используется отдельный ethernet для управления бэкплейнами (как будто обычного SCSI не хватает), что заставляет меня думать, что проблема с «подвисанием» шины является общеиндустриальной, а не локальной для конкретных драйверов.

        Если сумеете проверить поведение на новых HBA (обязательно с SATA-дисками, причём магнитными, подключенными к enclosure), скажите, мне будет очень интересно.
      • +1
        Свежие новости с фронта.

        Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)

        Всё ещё ровно так же вешается целиком кусок шины (host в терминах SCSI) при запуске скрипта.

        Так что не надо мне рассказывать про " Наверное, такой серьёзный баг, всплывший 2 года назад не мог оставаться неисправленным. При такой доле на рынке SAS HBA и экспандеров ситуация «да он же просто не работает этот ваш LSI» долго актуальной быть не может. "
  • 0
    Вопрос ко всем сразу: есть ли какой-то реестр отечественных IT компаний с перечнем их компетенций, навыков и продуктов?
    • +2
      У Федеральной службы безопасности должен быть.
    • +1
      Вот, например каталог продуктов
      www.arppsoft.ru/
  • +2
    Наслышан о вас. Молодцы.
    Года 4 назад построил своё хранилище на пол петабайта на infiniband и supermicro. В качестве файловой системы Lustre.
    Как раз для видеомонтажа. И монтажки по 40 Gb/s IB подключил. Суммарная скорость 17 гигабайт в секунду на чтение и 15 на запись.
    Собирал всё что можно из исходников и тестил, тестил, тестил.
    • 0
      Вы в Москве? RAIDIX в СПб. Но мы можем как нибудь встретится и попить кофе. Очень интересно послушать про реальный опыт использования Lustre для Media and Entertainment.
      • +1
        Обязательно встретимся, у меня командировка в начале года будет.
  • 0
    Если по заголовку и первым строкам ничего не понятно я сделал себе привычку читать радостные комментарии, если они есть, а потом статью.
    p.s. ну очень люблю новую информацию
  • 0
    я видел эту систему когда она еще называлась Avroraid и это уже тогда было неплохо.
    На недавнем НАБе открылась тайна — оказывается аврорейд — теперь райдикс)
  • 0
    У меня вопрос по эксплуатации,
    Как оно переживает отказы БП (включая обоих), как идет процесс обновления FW (ОС) и обработка сбоев этого дела?
    • 0
      Кэш в RAM, поэтому одноконтроллерная система, при неправильном проектировании, может потерять грязные сегменты кэша.
      Сейчас все больше компаний производит NVDIMM, но нормальных SDK и безбажной поддержки в BIOS нет
      Как только, появятся — будет поддержка в RAIDIX
      Поэтому для защиты от сбоев:
      -использовать внешние или внутренние SPS-модули, по одному на контроллер. При разрядке SPS, ПО получит сигнал и сбросит грязный кэш.
      -использовать двухконтроллерную конфигурацию (например, на базе Supermicro SBB)
      В DC режиме грязные сегменты кэша зеркалируются друг между контролерами и без проблем переживает любой вид отказа. Фэйловер менее секунды.

      Обновление, опять же будет только на отказоустойчивый конфигурации не требовать простоя.
      Чаще всего, это скрипт, делающий бэкап текущей конфигурации и выполняющий установку rpm.
      • 0
        Спасибо за ответы, еще интересует — сертифицируетесь ли вы с производителями железа, если да, то с какими?
        Особенно интересна официальная поддержка ваших массивов при использовании их с серверами IBM, HP, Hitachi, Fujitsu…
        Проходите ли вы какие-либо тесты на совместимость с производителями FC HBA: Emulex, Qlogic, производителями FC SAN оборудования Brocade, Cisco?
        • 0
          Есть два типа сертификации:
          односторонняя, когда нашими силами или нашими партнерами проводится тестирование аппаратного обеспечения.
          Это оборудование попадает в HCL и поддерживается нами и партнерами.
          HCL можно попросить, написав на info@raidixstorage.com

          двухсторонняя, когда вендор выполняет тестирование нашего ПО и распространяет его без нашего участи через свой канал

          Второй вариант с компаниями из первого эшелона возможен только под крупные проекты, из второго эшелона подобные отношения сложены, например, с AIC.
  • +2
    Коллеги, очень занимательное чтиво. Очень приятно что есть русские разработчики, которые что-то хорошее делают.

    Но опять-же живо напомнило про «To reinvent the wheel».

    RAID, как технология, активно умирает.

    Описанные проблемы в статье решаются RAIN архитектурами, плюс Erasue Code

    Кстати основная из традиционных RAIN ( Isilon ) — как раз и заточена в первую очередь под Медиа (насколько я знаю ВГТРК и прочие используют в РФ).

    Другой вопрос — ценообразование от Крок-а и EMC :)

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

    • –5
      Что-то в вашем комментарии не хватает слов «допилили», «Ынтерпрайз», «переделали», «лучшие решение», «как до луны», «тендеры», «отжимаем». Срочно исправить!
    • 0
      Допустим у вас малое количество файлов очень большого объема (сотни Tb), которые не влезают даже поодиночке на один узел RAIN, плюс специфика работы с данными такова, что SSD-кэш не помогает, потому запросы идут рандомно ко всем участкам файлов. К тому же хочется иметь производительность (в т.ч. по IOPS), близкую к теоретически возможной на нашем количестве дисков. RADIX как раз рассчитан на такой сценарий — не конкурент существующим распределенным системам, а хранилище, например, для необработанного видео.
      • 0
        Гхм, коллега. Но причем тут «один нод» и файлы?

        Посмотрите например stevenpoitras.com/the-nutanix-bible/ — там очень хорошо расписано про RAIN.

        Суть RAIN в том что в работе кластера участвуют одновременно _все_ шпиндели, и нет понятия spare disk как такового — опять-же, в «ребилде» все диски всего кластера участвуют.

        Как результат — скорость ребилда — в десятки раз быстрее традиционных RAID. И нет никаких заметных просадок производительности — фактически, оно просто в размере IOPS одного диска.

        Никоим образом RAIN архитектура не ограничивает размер файла размером нода — файл совершенно спокойно размазывается по всем дискам всего кластера.

        SSD тут совершенно ни причем. Isilon работает прекрасно без флеша вообще.
        • 0
          Если вы имели ввиду latency — то у обычных сетевых коммутаторов 10G (типа Аристы) она практически равна Infiniband — 320ns. Учитывая реальную latency SAS / SATA дисков — задержками сети уже можно пренебречь.

          Мало того, тот-же Nutanix (не очень уверен про Isilon) при записи на SATA диски вообще не обеспечивает data locality — ибо нет смысла, все равно задержки дисковой части намного выше.

          Сухой итог — весь кластер может быть занят одним файлом.

          image
  • 0
    «как вы знаете, умножение любых полиномов в конечных полях можно свести к умножению на примитивный элемент за счет факторизации умножения» — вспомнил универ, когда препод говорил — «тут я пропустил немного несложных вычислений...», открываешь учебник, а там две страницы мелким шрифтом.

    вопрос — есть возможность работы с энергонезависимым кэшем на запись?
    • 0
      Добрый день!
      Если есть желание, напишем статью про реализацию полиномиальный арифметики.

      Как я писал выше, с NVDIMM пока не работаем, тк полноценная поддержка со всех сторон (модули, BIOS MB, нормальный SDK, OS) пока не была нами обнаружена
      Пока что требуется использовать дополнительные модули бесперебойного питания. Внешние или внутренние.
      Но ничего безумно сложного в реализации я не вижу При благоприятном стечение обстоятельств будет поддержка модулей, использующих суперконденсаторы.
      • 0
        есть. желание читать, вникать
  • 0
    Казалось бы причем тут грибы… ;)

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

Самое читаемое Разное