Российская распределенная СХД. Как все устроено



    Этой весной команда «Рэйдикс» подготовила и выпустила первую версию ПО для создания распределенной блочной СХД, работающей на серверных платформах «Эльбрус-4.4» на базе микропроцессоров «Эльбрус-4С».

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

    Однако потенциал разработанной операционной системы не ограничивается российскими серверными платформами. В настоящий момент тестируется и отрабатывается совместимость со стандартными серверами x86-64, которые широко распространены на рынке. Помимо этого, продолжается «допиливание» продукта до желаемой функциональности, которая позволит осуществлять его реализацию за пределами российского рынка.

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

    Особенности распределенной СХД


    Традиционные СХД, выполненные в виде единого программно-аппаратного комплекса, имеют общую проблему, связанную с масштабированием: производительность системы, упирается в контроллеры, их количество ограничено, наращивание ёмкости путем добавления полок расширения с носителями не даёт увеличения производительности.

    При таком подходе общая производительность СХД будет падать, поскольку с увеличением ёмкости прежнему количеству контроллеров необходимо обрабатывать больше операций доступа к возросшему объему данных.

    RAIDIX RAIN поддерживает горизонтальное блочное масштабирование, в отличии от традиционных решений увеличение узлов (серверных блоков) системы приводит к линейному росту не только ёмкости, но и производительности системы. Это возможно поскольку каждый узел RAIDIX RAIN включает в себя не только носители, но и вычислительные ресурсы для ввода-вывода и обработки данных.

    Сценарии применения


    RAIDIX RAIN предполагает реализацию всех основных сценариев применения распределенной блочной СХД: инфраструктура облачного хранения, высоконагруженные базы данных и хранение аналитики Big Data. Также RAIDIX RAIN может составить конкуренцию традиционным СХД при достаточно высоких объемах данных и соответствующих финансовых возможностях клиента.

    Публичные и частные облака


    Решение обеспечивает эластичное масштабирование, необходимое для развертывания облачной инфраструктуры: производительность, пропускная способность и объем хранения увеличиваются с каждым добавленным в систему узлом.

    Базы данных


    Кластер RAIDIX RAIN в all-flash конфигурации является эффективным решением для обслуживания высоконагруженных баз данных. Решение будет доступной альтернативой продуктам Oracle Exadata для Oracle RAC.

    Аналитика больших данных


    Совместно с дополнительным ПО возможно использование решения для выполнения аналитики больших данных. RAIDIX RAIN обеспечивает значительно более высокий уровень производительности и простоты обслуживания по сравнению с кластером HDFS.

    Архитектура решения


    RAIDIX RAIN поддерживает 2 варианта развертывания: выделенный (внешний или конвергентный) и гиперконвергентный (HCI, hyper-converged-infrastructure).

    Выделенный вариант развертывания


    В выделенном варианте кластер RAIDIX RAIN представляет собой классическую программную СХД. Решение развертывается на необходимом количестве выделенных серверных узлов (не менее 3х, сверху количество практически не ограничено), ресурсы которых полностью утилизируются для задач хранения.

    Рис. 1. Выделенный вариант развертывания

    При этом программное обеспечение RAIDIX RAIN устанавливается прямо на голое железо. Приложения, сервисы, вычислительные ресурсы, использующие RAIN для хранения информации, размещаются на внешних хостах и подключают к нему по сети хранения данных (классическая архитектура ЦОД).

    Гиперконвергентный вариант развертывания


    Гиперконвергентный вариант предполагает совместное размещение вычислительных мощностей (гипервизор и производственные VM) и ресурсов хранения (программная СХД) ЦОД на одном множестве узлов, в первую очередь это актуально для виртуальных инфраструктур. При таком подходе ПО RAIN устанавливается на каждый хост (узел) инфраструктуры (HCI) в виде виртуальной машины.

    Рис. 2. Гиперконвергентный вариант развертывания

    Взаимодействие узлов кластера RAIN между собой и с конечными потребителями ресурсов хранения (серверами, приложениями) осуществляется по протоколам iSCSI (IP, IPoIB), iSER (RoCE, RDMA) или NVMeOF.

    Гиперконвергентный вариант развертывания даёт следующие преимущества:

    • Консолидация вычислительных ресурсов и ресурсов хранения (не нужно внедрять и сопровождать выделенную внешнюю СХД).
    • Совместное горизонтальное блочное масштабирование вычислительных ресурсов и ресурсов хранения.
    • Простота внедрения и сопровождения.
    • Централизованное управление.
    • Экономия стоечной ёмкости и энергопотребления.

    С точки зрения используемых носителей RAIDIX RAIN поддерживает 3 конфигурации:

    • All-flash — узлы кластера снабжаются только flash-носителями (NVMe, SSD);
    • HDD — узлы кластера снабжаются только HDD-носителями;
    • Гибридная — два независимых уровня хранения на HDD и SSD.


    Производительная отказоустойчивость


    Основная ценность RAIDIX RAIN — оптимальное соотношение производительности, отказоустойчивости и эффективного использования ёмкости хранилища.

    В рамках клиентской ИТ-инфраструктуры RAIDIX RAIN также привлекателен тем, что на выходе мы имеем «честный» блочный доступ, что выгодно отличает решение от большинства рыночных аналогов.

    В настоящее время большая часть конкурентных продуктов показывают высокую производительность, только при использовании зеркалирования. При этом полезная ёмкость хранилища сокращается в 2 раза и более: однократная репликация данных (зеркалирование) — избыточность 50%, двукратная репликация данных (двойное зеркалирование) — избыточность 66,6%.

    Использование технологий оптимизации хранения, таких как EC (Erasure Coding — помехоустойчивое кодирование), дедупликация и сжатие, реализованных в распределенных СХД, приводит к значительной деградации производительности хранилища, что неприемлемо для чувствительных к задержкам приложений.

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

    Требования по отказоустойчивости


    Изначально RAIDIX RAIN разрабатывался с четким набором исходных требований к отказоустойчивости и доступности системы:

    • Кластер должен переживать отказ не менее двух узлов, при количестве узлов строго больше 4. Для трех и четырех гарантируется отказ одной ноды.
    • Узел должен переживать отказ не менее двух дисков в каждом узле при наличии не менее 5 дисков в узле.
    • Уровень избыточности накопителей на типичном кластере (от 16 узлов) не должен превышать 30%
    • Уровень доступности данных должен быть не ниже 99,999%

    Это в значительной степени повлияло на существующую архитектуру продукта.

    Возможности Erasure Coding в распределенной СХД


    Основным подходом обеспечения отказоустойчивости RAIDIX RAIN является использование уникальных технологий Erasure Coding. Известные по флагманскому продукту компании EC используются и в распределенной СХД, что позволяет получить производительность сравнимую с зеркалированными конфигурациями. Это касается как случайной, так и последовательной нагрузки. При этом обеспечивается заданный уровень отказоустойчивости и значительно увеличивается полезная ёмкость, а накладные расходы составляют не более 30% сырой ёмкости хранилища.

    Отдельного упоминания требует высокая производительность EC RAIDIX на последовательных операциях, в частности при использовании SATA-дисков большого объема.

    В целом, RAIDIX RAIN предлагает 3 варианта помехоустойчивого кодирования:

    • для 3 узлов оптимальным является использование RAID 1;
    • для 4 узлов оптимальным является использование RAID 5;
    • для субкластера хранения от 5 до 20 узлов оптимальным подходом является использование сетевого RAID 6.


    Рис. 3. Варианты помехоустойчивого кодирования

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

    В RAID 6 при отказе 1-2 носителей внутри одного узла их восстановление происходит локально без использования распределённых контрольных сумм, минимизируя объем восстанавливаемых данных, нагрузку на сеть и общую деградацию системы.

    Домены отказа


    RAIN поддерживает концепцию доменов отказа (fault domain) или доменов доступности. Это позволяет отработать отказ не только отдельных узлов, но и целых серверных стоек или корзин, узлы которых логически группируются в домены отказа. Такая возможность достигается за счет распределения данных для обеспечения их отказоустойчивости не на уровне отдельных узлов, а на уровне доменов, что позволит пережить отказ всех сгруппированных в нем узлов (например, целой серверной стойки). В этом подходе кластер разбивается на независимые подгруппы (субкластера). Количество узлов в одной подгруппе не более 20, что и обеспечивает требование по отказоустойчивости и доступности. При этом количество подгрупп не ограничено.

    Рис. 4. Домены отказа

    Отработка любых отказов (дисков, узлов или сети) осуществляется автоматически, без остановки работы системы.

    Помимо этого, все устройства кластера RAIDIX RAIN защищены от отказа электропитания подключением к бесперебойным источникам питания (UPS). Устройства, подключенные к одному UPS, называются группой отказа по питанию.

    Характеристики и функциональность


    Рассмотрим основные функциональные характеристики RAIDIX RAIN.
    Таблица 1. Базовые характеристики RAIDIX RAIN
    Операционные характеристики Значение
    Поддерживаемые типы узлов Отечественные серверные платформы на базе процессоров «Эльбрус-4С»
    Стандартные серверы x86-64 (в перспективе)
    Поддерживаемые типы носителей SATA и SAS HDD, SATA и SAS SSD, NVMe
    Максимальный объём хранения 16 ЭБ
    Максимальный размер кластера 1024 узла
    Базовая функциональность Горячее расширение томов
    Горячее добавление узлов в кластер,
    Ребалансировка кластера
    Отработка отказов без простоев
    Технологии отказоустойчивости Отработка отказов узлов, носителей, сети.
    Помехоустойчивое кодирование (Erasure Coding) с распределением по узлам кластера: сетевой RAID 0/1/5/6.
    Коды коррекции на уровне локальных носителей узлов (локальный RAID 6)
    Домены отказа

    В качестве важной функциональной особенности RAIDIX RAIN стоит отметить, что такие сервисы, как инициализация, реконструкция и рестрайпинг (масштабирование), идут в фоновом режиме и им может выставляться параметр приоритета.

    Выставление приоритета дает пользователю возможность самостоятельно регулировать нагрузку в системе, ускоряя или замедляя работу данных сервисов. Например, приоритет 0 означает, что сервисы функционируют только в отсутствии нагрузки от клиентских приложений.

    Возможности масштабирования


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

    Рис. 5. Схема процесса масштабирования

    Гибкость архитектуры


    RAIDIX RAIN является программным продуктом и не ограничивается определенной аппаратной платформой — его концепция предполагает возможность установки на любое совместимое серверное оборудование.

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

    Поддержка различных типов носителей позволяют исходя из бюджета и решаемых задач строить на базе RAIDIX RAIN:
    1. распределенные all-flash хранилища с беспрецедентно высокой производительностью и гарантированным низким уровнем задержек;
    2. экономичные гибридные системы, удовлетворяющие большинству основных типов нагрузок.

    Показатели производительности


    В качестве заключения покажем немного цифр, полученных в результате тестирования RAIDIX RAIN на конфигурации NVMe-кластера из 6 узлов. Еще раз отметим, что на такой сборке (с серверами x86-64) продукт еще дорабатывается, и данные показатели не являются финальными.

    Тестовое окружение


    • 6 узлов по 2 диска NVMe HGST SN100
    • IB card Mellanox MT27700 Family [ConnectX-4]
    • Linux Kernel 4.11.6-1.el7.elrepo.x86_64
    • MLNX_OFED_LINUX-4.3-1.0.1.0-rhel7.4-x86_64
    • Local raid — raid 0
    • External raid – raid 6
    • Бенчмарк для тестирования FIO 3.1


    UPD: нагрузка выполнялась блоками 4КВ, последовательная — 1М, глубина очереди 32. Нагрузка запускалась на всех узлах кластера одновременно и в таблице представлен суммарный результат. Задержки не превышают 1 ms (99,9 перцентиль).

    Таблица 2. Результаты тестирования
    Тип нагрузки Значение
    Random read 100% 4 098 000 IOps
    Random write 100% 517 000 IOps
    Sequential read 100% 33.8 GB/s
    Sequential write 100% 12 GB/s
    Random read 70%/random write 30% 1000000 IOps/ 530 000 IOps
    Random read 50%/random write 50% 530 000 IOps/530 000 IOps
    Random read 30%/random write 70% 187 000 IOps/438 000 IOps
    RAIDIX
    Company
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 16

      –1
      так вот кто яровой проплатил и теперь будет грести деньги! :)
      ну и да
      сборка СХД на базе отечественного железа и отечественной операционной системы становится вполне привлекательным продуктом внутреннего рынка, в частности для заказчиков, имеющих фокус на импортозамещение.
      а какое это импортозамещение, если требует зарубежных винтов? плюс на которых еще и прошивки буржуйские… с закладками всё небось :)
        +3
        Все так. Уже выбираем цвет для корпоративной яхты :)
        +1

        Всё, что про big data, мерзковатенько попахивает. А когда с оговоркой на импортозамещение, запашок становится сильнее.

          +1
          Вы, наверно, и нанотехнологии не любите?
          +1

          Результаты тестирования без средней, минимальной и максимальной задержек, а также без указания размера блока не имеют никакого практического смысла.
          Локальный raid 0? Оооок. А в продакшн вы такую конфигурацию рекомендуете? Это же нереалистичная конфигурация, никто не будет использовать в реальной инфраструктуре ноды с двумя локальными дисками.

            0
            1. Тестирование детально не описывали здесь, поскольку тестирование распределенно кластера это большая и сложная тема, которую можно долго обсуждать ввиду большого количества параметров и правильной интерпретации результатов. Лучше все подробно расписать в отдельной статье. Над табличкой добавили информацию про параметры нагрузки.
            2. Для двух дисков этой модели при наличие сетевого RAID — локальный страйп подойдет.
            В случае отказа 1 диска будет работать сетевой RAID. За два года использования нашего кластера (32 накопителя) не было ни одного отказа.
            Также в наших нодах стоят по 16 HDD. Для них мы используем локальный RAID6. Для трех NVMe рекомендуем локальную 5-ку. Перед выбором схем защиты мы строили модель отказов системы, выдерживая уровень доступности 99.999.
              0
              Коллеги, так никто обсуждать тестирование Вас не просит, интересуют честные цифры, снятые во вполне конкретных условиях (изложенных в результатах). Совершенно не принципиально, что в других условиях производительность будет иной — это очевидно для всех, и кому надо — проведет тесты после. Но никто не мешает честно взять 3 узла вместо шести, создать по RAID-5 из 4 дисков (вместо нуля из двух), нагрузить FIO не с одной машины, а одновременно с восьми машин (чтобы запросы поступали не последовательно) — и всё. Такие нагрузочные тесты как минимум дадут и Вам трезвое понимание, что из себя представляет продукт. А умалчивание показателей лишь говорит о том, что с продуктом всё совершенно не хорошо (хотя это может быть и неверно) — увы, «презумпция невиновности» на рынке СХД не работает — продукт плохой, пока вендор не докажет обратного.
            0

            Какие варианты NVMeOF поддерживаете?

              0
              Поддерживается NVMe over Infiniband. В принципе, с небольшой доработкой можно добавить поддержку FC и RoCE.
                0

                "Взаимодействие узлов кластера RAIN между собой и с конечными потребителями ресурсов хранения (серверами, приложениями) осуществляется по протоколам iSCSI (IP, IPoIB), iSER (RoCE, RDMA) или NVMeOF."


                Немного запутали. Поддержка RoCE есть или нет?

                  0
                  Для iSER RoCE поддерживается уже в текущей сборке, для NVMeOF — пока нет, дорабатываем.
              +2
              Что-то подсказывает, что не все так радужно, как описано. Наверняка как и у других «импотозаменителей» полно детских болезней и досадных глюков. Но тем не менее надо ж с чего-то начинать и я желаю удачи Вам на этом нелегком пути. Главное, чтоб это было не просто попытка срубить бабла на волне импортозамещения, а желание создать поистине достойного продукта, которым можно гордиться.
                0
                Не все радужно. Но основные задачи касаются, скорее, расширенного функционала, а не параметров стабильной работы.
                За пожелания — отдельное спасибо :)
                +1
                Молодцы. Движетесь в правильном направлении. Немного фокус статьи уплыл в сторону Эльбрусов, в то время когда основная тема — это возможности RAIDIX RAIN. Правильный Software Defined Storage (SDS) должен быть независим от аппаратного уровня (хотя учитывать его возможности) и ограничен только возможностями гипервизора или даже контейнера. Следовательно, давать возможность поднять качественную СХД на любом железе даже с учетом политических предпочтений.
                  0
                  Спасибо! Мы действительно старались описать возможности (и потенциал) продукта, выходя за пределы отечественного железа.
                  0
                  от статьи попахивает дремучестью.
                  1. фишка exadata умение разбирать SQL, а не выступать тупым блочным сториджем для которого субд просто набор файликов. понятно что у вы не альтернатива oracle exadata.
                  2. к чему там hdfs упомянут? у вас тупой сторидж без ничего. какое отношение стоидж без ничего к бигдате и hdfs? суть hdfs в том что оно интегрировано в ядро хадупа, который запускает код на том же узле, где лежат данные. у вас же просто сторидж.

                  Only users with full accounts can post comments. Log in, please.