Тема отказоустойчивости в системах хранения данных всегда является актуальной, поскольку в наш век повсеместной виртуализации и консолидации ресурсов СХД является тем звеном, отказ которого приведет не просто к заурядной аварии, а к длительным простоям сервисов. Поэтому современные СХД имеют в своем составе множество дублированных компонент (вплоть до контроллеров). Но достаточна ли такая защита?




Абсолютно все вендоры, перечисляя характеристики СХД, обязательно упоминают о высокой отказоустойчивости своих решений, непременно добавляя термин «без единой точки отказа». Взглянем повнимательнее на типичную систему хранения данных. Для исключения простоя в обслуживании в СХД дублируются блоки питания, модули охлаждения, порты ввода/вывода, накопители (имеем ввиду RAID) и конечно же контроллеры. Если внимательно присмотреться к данной архитектуре, можно заметить, как минимум, две потенциальные точки отказа, о которых скромно умалчивают:


  1. Наличие единого бэкплейна (backplane)
  2. Наличие одной копии данных

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


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


Вполне очевидный выход для преодоления данных недостатков – это репликация на другую СХД. Если закрыть глаза на вполне ожидаемое удвоение стоимости «железа» (все же мы предполагаем, что выбирающие подобное решение люди адекватно мыслят и заранее принимают этот факт), останутся еще возможные расходы на организацию репликации в виде лицензий, дополнительного программного и аппаратного обеспечения. И главное – потребуется каким-то образом обеспечить консистентность реплицируемых данных. Т.е. строить виртуализатор СХД/vSAN/пр., что также требует денежных и временных ресурсов.


AccelStor при создании своих High Availability систем поставили целью избавиться от упомянутых выше недостатков. Так появилась интерпретация технологии Shared Nothing, что в вольном переводе означает «без использования общих устройств».


Концепция Shared Nothing представляет собой использование двух независимых нод (контроллеров), каждая из которых имеет свой набор данных. Между нодами производится синхронная репликация через интерфейс InfiniBand 56G абсолютно прозрачно для программного обеспечения, работающего поверх системы хранения. В результате не требуется применения виртуализаторов СХД, программных агентов и пр.


Физически двухнодовое решение от AccelStor может быть выполнено в двух моделях:


  • H510 — на базе Twin серверов в корпусе 2U, если требуются умеренная производительность и емкость до 44ТБ;
  • H710 — на базе отдельных 2U серверов, если требуется высокая производительность и большая емкость (до 110ТБ).


Модель H510 на базе Twin сервера



Модель H710 на базе отдельных серверов


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


Набор данных у каждой ноды имеет две группы FlexiRemap, плюс 2 hot spare. Каждая группа способна выдержать отказ одного SSD. Все поступающие запросы на запись нода в соответствии с идеологией FlexiRemap перестраивает в последовательные цепочки с блоками 4КБ, которые затем записываются на SSD в максимально комфортном для них режиме (последовательная запись). Причем хосту подтверждение записи выдается только после физического размещения данных на SSD, т.е. без кэширования в RAM. В результате достигается весьма впечатляющая производительность до 600K IOPS на запись и 1M+ IOPS на чтение (модель H710).


Как уже упоминалось ранее, синхронизация наборов данных происходит в режиме реального времени через интерфейс InfiniBand 56G, обладающий высокой пропускной способностью и низкими задержками. Для того, чтобы максимально эффективно использовать канал связи при передаче малых пакетов, перед отправкой они группируются блоками по 128КБ в так называемые data capsule. Т.к. канал связи один, для дополнительной проверки пульса используется выделенный 1GbE линк. Через него передается только heartbeat, поэтому требований к скоростным характеристикам не предъявляются.


В случае увеличения емкости системы (до 400+ТБ) за счет полок расширения они также подключаются парами для соблюдения концепции «без единой точки отказа».


Для дополнительной защиты данных (помимо того, что у AccelStor и так две копии) используется особый алгоритм поведения в случае отказа какого-либо SSD. Если SSD выйдет из строя, нода начнет ребилд данных на один из накопителей hot spare. Группа FlexiRemap, находящаяся в состоянии degraded, перейдет в режим read only. Делается это для исключения интерференций операций записи и ребилда на резервный диск, что в итоге ускоряет процесс восстановления и сокращает время, когда система потенциально уязвима. По завершению ребилда нода снова переходит в нормальный режим работы read-write.



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


Еще одним полезным свойством технологии Nothing Shared является работа нод в так называемом режиме true active-active. В отличие от «классической» архитектуры, где конкретным томом/пулом владеет только один контроллер, а второй просто выполняет операции ввода/вывода, в системах AccelStor каждая нода работает со своим набором данных и не передает запросы «соседке». В результате повышается общая производительность системы за счет параллельной обработки запросов ввода/вывода нодами и доступа к накопителям. Также фактически отсутствует такое понятие, как failover, поскольку передавать управление томами другой ноде в случае сбоя просто не нужно.


Если сравнивать технологию Nothing Shared с полноценным дублированием СХД, то она, на первый взгляд, немного уступит полноценной реализации disaster recovery в гибкости. Особенно это касается организации линии связи между системами хранения. Так, в модели H710 возможно разнести ноды на расстояние до 100м за счет использования не совсем дешевых активных оптических кабелей InfiniBand. Но даже если сравнивать с обычной реализацией синхронной репликации у других вендоров через доступный FibreChannel даже на бОльшие расстояния, решение от AccelStor окажется дешевле и проще в инсталляции/эксплуатации, т.к. нет необходимости устанавливать виртуализаторы СХД и/или производить интеграцию с программным обеспечением (что далеко не всегда возможно в принципе). Плюс, не забываем, что решения AccelStor – это All Flash массивы с производительностью выше, чем у «классических» СХД с SSD only.



При использовании технологии Nothing Shared от AccelStor реально получить доступность системы хранения на уровне 99.9999% за вполне разумную стоимость. Вместе с высокой надежностью решения, в том числе за счет использования двух копий данных, и впечатляющей производительности благодаря фирменным алгоритмам FlexiRemap, решения от AccelStor являются отличными кандидатами на ключевые позиции при построении современного датацентра.

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


  1. Tortortor
    27.02.2019 14:05

    «В отличие от «классической» архитектуры, где конкретным томом/пулом владеет только один контроллер, а второй просто выполняет операции ввода/вывода, в системах AccelStor каждая нода работает со своим набором данных и не передает запросы «соседке».»

    вот отсюда поподробней. консистенция данных?

    AccelStor
    так
    «Синхронная двунаправленная репликация между нодами.»
    или
    «не передает запросы «соседке»»
    ?


    1. AccelStor Автор
      27.02.2019 14:10

      Синхронная двунаправленная репликация между нодами.


      1. vesper-bot
        27.02.2019 14:12

        Как ведет себя система, если с двух сторон на каждую ноду пришел запрос на запись в один и тот же блок?


        1. AccelStor Автор
          27.02.2019 14:18

          Если у вас с системой хранения работает кластер, то у вашего кластера есть арбитр, не позволяющий более, чем одному хосту работать с конкретным блоком данных. Сам хост одновременно запрос на обе ноды через MPIO отправить не сможет (там round robin или fixed). Т.е. на одну из нод запрос придет раньше.


          1. Hardened
            28.02.2019 20:06

            Придёт может и раньше. А вот обслужится не факт. Что дальше будет происходить?


            1. AccelStor Автор
              01.03.2019 10:26

              Еще раз. Если у вас кластер, то в нем только один хост работает с конкретным блоком данным. Хост, имея даже несколько путей до хранилища, отправляет запрос только один раз через один путь (согласно его политике MPIO). Поэтому второй раз этот же запрос через другой путь он отправить не может.


              1. Hardened
                01.03.2019 11:44

                Но это ведь общая схема работы с MPIO. В чем ваша фишка?


                1. AccelStor Автор
                  01.03.2019 12:10

                  Запрос на изменение обработается одной нодой, затем результат синхронизируется со второй. В итоге — 2 копии данных. Disaster recovery без виртуализатора СХД, программных агентов и пр.


                  1. ximik13
                    01.03.2019 14:26

                    Disaster recovery это слишком громко сказано, учитывая дистанцию между нодами.


                    1. AccelStor Автор
                      01.03.2019 14:33

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


                      1. ximik13
                        01.03.2019 15:51

                        Можете хотя бы 3 примера таких ситуаций привести :)? И вы по прежнему не ответили на мой вопрос, что висит ниже в комментариях.


                        1. AccelStor Автор
                          01.03.2019 16:06

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


      1. ximik13
        28.02.2019 11:45

        Хост получает ack после того как блок отреплицировался на соседнюю ноду? Или сразу после записи блока на первую ноду?


  1. n1nj4p0w3r
    27.02.2019 21:45

    Звучит как DRBD


  1. nobletracer
    27.02.2019 22:10

    Вы пишите про отсутствие единой точки отказа.
    Что происходит, если падет единственный линк Infiniband 56G?


    1. AccelStor Автор
      28.02.2019 09:16

      Одна из нод отключится.