Erasure Code — больше пространство хранения на Nutanix



    Эта запись у нас в блоге уже появлялась пару месяцев назад. К сожалению нам строго погрозили из-за океана, чтобы мы не рассказзывали о еще не зарелизенных фичах, поэтому текст пришлось убрать. И вот теперь, в NOS 4.1.3, Erasure Code доступен для использования в public beta статусе (экспериментируйте, но пока погодите с продакшном, мы еще оптимизируем код), а значит рассказывать уже можно публично.

    Если вы уже читали мой рассказ ранее про то, как устроена NDFS, Nutanix Distributed File System, основа того, как оно все сделано в Nutanix, то наверняка отметили, что расход дискового пространства в NDFS, он, в общем, довольно «щедрый».

    Напомню, что мы не используем RAID, в его классическом понимании, когда, например, для диска держится его зеркальная копия (RAID-1), или когда для группы дисков рассчитан дополнительный код избыточности (RAID-5 или 6). Вместо этого, мы храним блок записанных на дисках данных в двух (или даже трех) местах на разных дисках и даже разных нодах. Эта схема называется у нас RAIN (Redundant Array of Independent Nodes, в пику RAID, который то же само, но …Disks). Но, с точки зрения емкости дисков системы, RF=2, то есть вариант, когда для каждого блока хранится его копия, расход места эквивалентен RAID-1, то есть под данные нам доступны 50% raw-емкости (минус еще какой-то, переменный, процент на служебные структуры и информацию, но это опустим тут).

    Да, отказоустойчивость, надежность, быстрое (минуты) восстановление при сбоях, все это так. Но все равно расход довольно большой. Особенно для людей, все еще привычно мыслящих про диски в величинах емкости raw или RAID-5. И можно сколько угодно говорить, что RAID-5 — плох и ненадежен, что он медленный на запись, что, наконец, при нынешних ценах на HDD, плата за повышенную надежность и производительность гигабайтами, отдаваемыми на отказоустойчивость, невелика, в сравнении с тем, что нам дается взамен за них. Все равно. «У нас стоит в системе четыре терабайтных диска. Почему же у нас остается даже меньше двух терабайт под наши данные?»

    Вот поэтому у Nutanix появилась идея, которая сейчас активно воплощается. Занимается ей в Nutanix, кстати, «наш», русскоязычный программист.
    Это то, что называется «erasure code» (мы назвали его EC-X, Erasure Code-X). Как это часто бывает у инженеров, название «несамоописывающее», и прижилось уже никто не знает почему. По-русски это будет, правильнее всего — «код избыточности».
    Вот как это работает.

    Если у нас есть данные, которые нас жаба давит держать на «RAID-1», то есть в режиме Replication Factor (RF) = 2, то мы можем переключить для этих данных режим хранения с RF=2(или =3) на erasure code. При этом, у нас начинает работать специальный фоновый процесс, похожий на то, как у нас осуществляется дедупликация в кластере, и, через какое-то время, вместо блока-и-копии у нас на дисках начинает храниться на дисках кластера нодов блок-блок-блок-…-и_избыточная_информация_для_них, которая позволяет однозначно восстановить содержимое блока в этой цепочке, если он будет утерян, например в результате отказа диска одной из нод.
    И когда этот процесс заканчивает обработку в фоне, вместо блока и его копии в кластере, у нас начинает храниться множество блоков, объединенных в группу, плюс отдельный блок и кодом избыточности. И в том контейнере данных, где мы включили erasure code вместо RF, мы получаем тот же объем хранящейся информации, и при этом больше свободного места для новой.
    Опять же, это немного похоже на postponed deduplication.

    Наверняка вы уже готовы тут сказать: «Ну, вы просто „изобрели“ велосипед RAID-5!», не совсем так на математическом уровне, но отдаленно принцип похож, да.

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

    Важно также то, что, с помощью Erasure Code, избыточности достаточно, чтобы восстановиться при отказе двух дисков, нод, или прочих компонентов кластера, то есть это, с точки зрения уровня отказоустойчивости, эквивалент RF=3, для которого на дисках объем usable равен около 33% от raw.
    А в случае erasure code?
    Это зависит от размеров кластера. Чем он больше по числу нод — тем выгоднее, тем больше величина разницы.



    Для 4-нодового кластера на 80TB raw получается примерно 40TB usable при RF=2. При переключении контейнера в erasure coding пространство usable составит — 53TB.
    На 5 нодах — 100 — 50 — 75, на 6 нодах — 120 — 60 — 96, на 7 — 140 — 70 — 116. Как видите, с увеличением размеров кластера, «эффективность хранения» для erasure code также растет, и может достичь 80% от raw capacity.

    Что за кодирование используется? Нет, это не Reed-Solomon Code, хорошо знакомый индустрии, и часто используемый для подобных задач. У нас пришлось придумать свой алгоритм, обеспечивающий более высокую скорость обработки и расчета. И разумеется, мы используем распределенные возможности кластера Nutanix, алгоритм распределен, подобно map-reduce, и выполняется на всех нодах кластера, что обеспечивает надежность и производительность его работы. Также важно отметить, что использование EC-X не нарушает наш принцип Data Locality. Если виртуальная машина находится на данном хосте виртуализации (ноде кластера), то и ее данные на SSD (performance tier нашего хранилища) также будут лежать локально для нее, на этой ноде, как при RF, так и при EC-X варианте хранения, что обеспечивает низкую latency и высокую дисковую производительность.

    Для чего и куда это можно применить?

    Прежде всего, это позволяет понизить стоимость хранения ($/GB), что особенно актуально для «cold storage»и capacity nodes, в особенности на больших кластерах, в том случае, если вы храните на Nutanix информацию, пусть и ценную, но не слишком «горячую», активную. И готовы за большее свободное пространство заплатить повышенной загрузкой CPU и более длительным временем восстановления.
    При этом, обратите внимание, в штатном режиме, при обычной работе с данными под erasure code, загрузка CPU при обращении к данным существенно не повышается, только при восстановлении.
    Вы также вольны выбирать, как именно защищать избыточностью ваши данные. Вы можете на одном кластере держать разные контейнеры для данных, одни — с RF=2, другие — RF=3, а какие-то — с erasure code. Для данных, достаточно горячих и критичных, вы можете выбрать какой-то из RF, а для не таких «горячих», и лежащей на нодах, где повышенная нагрузка CPU при восстановлении не критична для нас — Erasure Code.
    Опять же: выбор режима для хранения данных — за вами, и зависит от вашего выбора и от ваших приоритетов.

    Erasure Code появился в очередном релизе Nutanix OS, который приедет на ваши системы Nutanix со штатным обновлением. Обновление Nutanix, кстати, не приводит к остановке работы виртуальных машин и недоступности данных, и система обновляется Over-The-Air, «как айфон», но об этом — в следующем посте.

    Nutanix

    43,15

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 11
      +2
      Я не сильно разбираюсь в СХД чтобы вникнуть в статью, но фоток той девушки за стойкой точно нужно больше.
        0
        А в чём преимущество вашей реализации перед другими?
          0
          Смотря перед какими другими, уточните.
            0
            Допустим, от того же ceph.
              +1
              Я не великий специалист по внутреннему устройству ceph, но, например, определенных усилий потребовало сохранение Data Locality, о котором упомянуто в тексте. Дело в том, что хранение данных локально, на локально расположенных в этой ноде дисках, для использующих их VM — ода из важных и принципиальных особенностей структур данных у Nutanix. Это позволяет достичь максимальной производительности за счет снижения latency операций ввода-вывода.
              В случае RF (Replication Factor) все в целом просто. Данные всегда пишутся (и конечно затем читаются), пока VM не мигрировала — локально, на локальный SSD, а их копии — куда-то в кластер, на другие ноды.
              В случае же EC-X начинаются сложности с тем, как обеспечить, чтобы этот конкретный блок данных «не уезжал далеко», а оставался локальным для его владельца, при том, что в датастор с erasure coding может быть включено и объединено множество дисков на разных нодах. Для этого и потребовался свой алгоритм.
                0
                Спасибо за ответ!
          0
          C моей точки зрения лучшая реализация Erasure Coding сейчас есть в решении Scality RING (называется ARC). В нем используется доработанный алгоритм Reed-Solomon, при этом в наличии плюшки: локальность данных, быстрый поиск data chunks для сборки искомого объекта и минимальное проседание производительности при потере узлов — есть пример с 360 ТБ общей полезной емкости на 6 узлах, потеря 60 ТБ емкости на 1 узле вызывает пропорциональное проседание пропускной способности, но только на 2 часа, пока система не «залечится». Доступность данных 13 девяток вызывает оверхед всего 1,5 (66% сырой емкости — это полезная емкость). У решения уже куча внедрений.

          Почитать можно здесь: h20195.www2.hp.com/v2/getpdf.aspx/4AA5-4981ENW.pdf
          Аналогичный документ от самого Scality здесь (но придется оставить свои контакты): www.scality.com/resources/scality-technical-whitepaper
            0
            Scality RING — вполне интересное специализированное решение.

            Но чем-же оно «лучшее»?

            Локализация ввода-вывода, минимальное понижение производительности (за счет горизонтального масштабирования), крайне высокая скорость восстановления целостности данных и прочее — это все есть в Nutanix (лет 5 как уже).
            Плюс множество других «плюшек» которых у Scality RING просто в принципе нет (metro репликация + DR? одновременная работа RF2/3 и Erasure? заточенность под виртуализацию? и т.д. )

            Кстати наши разработчики считают что Reed Solomon (даже доработанный) уже устарел (достаточно много причин), поэтому сделали свой алгоритм (который в том числе максимально использует аппаратные инструкции новых процессоров).

            Собственно, перефразируем. Назовите пожалуйста конкретные пункты, по которым Scality RING «более лучшее» чем Nutanix.

            Почему наоборот — назвать можно десятки.
              0
              У Scality есть это все, это все лучше и этого всего больше. Почитайте Whitepaper. Например:

              • metro репликация + DR? Да, только межконтинентальная репликация и DR
              • одновременная работа RF2/3 и Erasure? Да, только RF 1/2/3/4/5/6 или Erasure Coding на выбор автоматически для каждого объекта, а не кластера как у вас
              • заточенность под виртуализацию? Да, есть прямая связь с виртуальной средой. Но это не единственная возможность. Scality может доступ к хранилищу по любым интерфейсам: блочный, файловый, объектный любого вкуса и цвета.
              • и т.д. Да, много :)


              Еще Erasure Coding у Scality лучше, чем у Nutanix пока хотя бы потому, что у него есть большой опыт практического применения. Но я это написал просто для информации — мне кажется если уж вы сраниваетесь, то сравниваться нужно с лидером рынка.
                0
                > то сравниваться нужно с лидером рынка

                Лидер рынка? Вы, должно быть, шутите :-}
                  0
                  «Да, только межконтинентальная репликация и DR»
                  Я спрашивал про синхронную репликацию (метро). Есть?

                  «каждого объекта, а не кластера как у вас» — не обманывайте себя и читателей :)
                  У нас в одном кластере можно миксовать RF2/3/Erasure — на уровне логических объектов (контейнеров).

                  «заточенность под виртуализацию? Да, есть прямая связь с виртуальной средой. „

                  Что значит “прямая связь»? Оно может работать на том же хосте физическом на котором работает гипервизор (например HyperV или ESXi)? Умеет акселерацию СХД (да тот-же VAAI?)



                  Сухой итог — вы не назвали ни одного преимущества Scality, по которому оно реально лучше.

                  p.s. «то сравниваться нужно с лидером рынка.» — именно. Nutanix (в первую очередь являясь SDS) держит 52% рынка гиперконвергентных систем, ну а то что HP пытается (достаточно истерично) на этот рынок попасть, не имея там даже нескольких процентов доли — это уже отдельная история :)

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

            Самое читаемое