Эта запись у нас в блоге уже появлялась пару месяцев назад. К сожалению нам строго погрозили из-за океана, чтобы мы не рассказзывали о еще не зарелизенных фичах, поэтому текст пришлось убрать. И вот теперь, в 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, «как айфон», но об этом — в следующем посте.
ссылка на оригинал статьи http://habrahabr.ru/post/260685/
Добавить комментарий