Архив метки: erasure code

Erasure Coding X: отзывы пользователя

Интересный отзыв от одного из наших зарубежных пользователей, который начал использовать у себя Erasure Coding (EC-X):

«Мы используем платформу Nutanix в продакшне уже 10 месяцев (у нас NX-3460), и за это время обновилили ее с NOS 3.x до 4.х, а сейчас и до 4.5. Я должен сказать, что процедура апгрейда, non-disruptive и one-click — великолепна, и очень отличается в лучшую сторону от того, что нам приходилось делать раньше на других системах.
После этих обновлений мы получали заметные изменения в плане ускорения работы, а сейчас и в направлении экономии пространства хранения.

После выхода версии 4.5, на которую мы обновились также без прерывания работы, и включив EC-X на контейнере, за неделю мы получили почти 20% экономии пространства хранения без заметного влияния на дисковую производительность.»

Ниже — скриншот этого нашего контейнера.

ECX-screenshot

Erasure Coding (EC-X) в вопросах и ответах

Чем отличается Nutanix EC-X от других алгоритмов и реализации Erasure Coding?

Алгоритм оптимизирован для работы на распределенной системе. Использование распределенности, присущей Nutanix, позволяет обрабатывать ситуации с отказом дисков и восстановлением данных быстрее, и с меньшим влиянием на загрузку отдельной ноды кластера.

EC-X также реализован как «постпроцессный» механизм. При записи данные записываются на диски традиционным уже для Nutanix способом Replication Factor, а процессы Erasure Coding, высвобождающие место, начинают работать в фоне, что позволяет свести к минимуму нежелательное влияние дополнительной загрузки CPU системы для основной рабочей нагрузки по вводу-выводу данных.

Как EC-X совместим с другими технологиями уменьшения storage footprint на Nutanix, например дедупликацией и сжатием данных?

EC-X совместим с ними, и может использоваться на том же контейнере, где уже используется дедупликация или компрессия, позволяя еще немного сэкономить объем хранения.
Вот пример:
CapacityOptimization

А вот на контейнере с компрессией:
CompplusECXhighlighted

EC-X работает только для capacity tier (SATA)?

Нет, он работает на всех дисках системы, и на SATA (capacity tier), и на SSD (performance tier).

Алгоритм EC-X обрабытывает только «холодные» данные?

Как уже было сказано выше, алгоритм работает так: данные поступают на диск, и, как и раньше, записываются локально, и, синхронно, куда-то еще в кластере, обеспечивая избыточную копию. Пока все происходит также, как и раньше, это то, что мы называем «метод Replication Factor». Наконец блоки данных перестали активно писаться. Этот этап называется у Nutanix «Write Cold». Они могут продолжать активно читаться пр этом, главное, чтобы экстент, длиной 4MB, перстал именно писаться. После этого он поступает в распоряжение алгоритма EC-X.
Если этот экстент расположен на SSD, то он будет обработан алгоритмом EC-X, и место на диске будет освобождено, даже в случае, если данные в этом экстенте активно читаются, и, значит,расположены на SSD.

Как использование EC-X влияет на производительность?

Так как работа EC-X это постпроцессный алгоритм, он не влияет заметно на производительность операции записи. За единственным исключением, когда записываемые данные последовательно и многократно перезаписываются, уже после первоначальной их записи. Такое поведение вызывает бОльшую загрузку системы, когда они пишутся на контейнер с EC-X, чем когда они писались на контейнер с RF (традиционным методом Replication Factor).
Если вы прогнозируете именно такое поведение записываемых данных, то рекомендуем продолжать использовать RF, и не включать EC-X, или же с бОльшей внимательностью отнестись к профайлингу рабочей нагрузки на системе.
При своей работе алгоритм стремится хранить блоки данных на SSD, а блоки парити — на SATA, что увеличиваеи эффективность именно SSD (performance tier системы), и положительно сказывается на общей производительности системы.

Какие гипервизоры поддерживаются с EC-X?

EC-X это внутренняя функциональность платформы Nutanix, она не зависит от типа гипервизора, и остается доступной для пользователя на любом используемом гипервизоре из поддерживаемых, то есть на VMware ESXi (vSphere), Microsoft Hyper-V и Linux KVM.

Сохраняется ли при использовании EC-X принцип Data Locality (хранение данных VM «рядом с ней», на локальных дисках ноды, где она исполняется)?

Да, Data Locality сохраняется, это также одна из особенностей используемого алгоритма.

Какие типы нагрузок Nutanix лучше подходят для контейнера с EC-X, а какие не подходят?

Во-первых, следует принять во внимание, что на момент написания этого текста, «первая публикация» EC-X в версии NOS 4.1.3 является technical preview, и компания не рекомендует ее для использования в бизнес-критичном продакшне. По всей вероятности к концу года мы опубликуем окончательный релиз EC-X.
Во-вторых, очевидно, что максимум выгоды при минимуме побочных нежелательных эффектов EC-X принесет таким задачам, как файловые сервера, резервные копии и архивы, ISO-репозитории, хранилища электронной почты, разделы для записи и хранения логов.
Нежелательно использовать, или же следует особо внимательно следить за возможными нежелательныи эффектми на разделах, на которых приложения активно перезаписывают уже записанные данные в небольшой промежуток времени.
Однако помните, что EC-X можно назначить на уровне отдельного vDisk Nutanix, что позволит вам достаточно гибко выбирать вариант хранения для данной VM, например один VMDK данной VM может храниться с использованием RF, а другой — с EC-X.

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

«Теперь об этом можно написать» (с) :)
Текст был написан, и даже опубликован несколько месяцев назад на Хабре, однако нам надавали по шапке за фальстарт и упоминание еще не зарелизенной фичи, и мы были вынуждены материал убрать. На .NEXT вчера ночью про Erasure Coding было объявлено официально, как и про то, что он выходит в релиз в версии NOS 4.1.3, так что теперь эта статья имеет право на публикацию.

Если вы уже читали мой рассказ ранее про то, как устроена 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». Как это часто бывает у инженеров, название «несамоописывающее», и прижилось уже никто не знает почему. По-русски это будет, правильнее всего — «код избыточности». Вот как это работает.

Если у нас есть данные, которые нас жаба давит держать на «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 также растет.

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

Прежде всего, это позволяет понизить стоимость хранения ($/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, «как айфон», но об этом — в следующем посте.