В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering)

Эдуард Шишкин анонсировал новые возможности, развиваемые в рамках проекта Reiser5. Reiser5 представляет собой существенно переработанный вариант файловой системы ReiserFS, в котором на уровне файловой системы, а не блочного устройства, реализована поддержка параллельно масштабируемых логических томов, позволяющая эффективно распределять данные по логическому тому.

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

В основу реализованного метода легло простое наблюдение, что на практике запись на диск не ведётся постоянно, а кривая нагрузки ввода-вывода имеет форму пиков. В промежутке между такими «пиками» всегда имеется возможность сбросить данные с прокси-диска, переписав в фоновом режиме все данные (или же только часть) в основное, «медленное» хранилище. Таким образом, прокси-диск всегда готов к приёму новой порции данных.

Изначально данная техника (известная как Burst Buffers) возникла в
области высокопроизводительных вычислений (HPC). Но она оказалась также востребованной и для обычных приложений, особенно для тех, которые предъявляют повышенные требования к целостности данных (обычно это разного рода базы данных). Любые изменения в каком-либо файле такие приложения выполняют атомарным способом, а именно:

  • сначала создаётся новый файл, который содержит изменённые данные;
  • потом этот новый файл записывается на диск при помощи fsync(2);
  • после этого новый файл переименовывается в старый, что автоматически
    освобождает блоки, занятые старыми данными.

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

    В Reiser5 планируется опционально отправлять на прокси-диск не только
    новые логические блоки файла, но и все грязные страницы вообще. Причём,
    не только страницы с данными, но также и с мета-данными, которые
    записываются на шагах (2) и (3).

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

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

    После добавления прокси-диска, суммарная ёмкость логическгого тома
    увеличивается на ёмкость этого диска. Мониторинг свободного места на
    прокси-диске производится так же, как и для остальных компонентов тома, т.е. при помощи утилиты volume.reiser4(8).

    Прокси-диск необходимо периодически очищать, т.е. сбрасывать данные с
    него в основное хранилище. После достижения бета-стабильности Reiser5
    очистку планируется сделать автоматической (ей будет заведовать
    специальный тред ядра). На данном же этапе ответственность за очистку
    возлагается на пользователя. Сброс данных с прокси-диска в основное
    хранилище производится простым вызовом утилиты volume.reiser4 с опцией
    «-b». В качестве аргумента нужно указать точку монтирования логического
    тома. Разумеется, очистку надо не забывать проводить периодически. Для
    этого можно написать простой shell-скрипт.

    В случае отсутствия свободного места на прокси-диске все данные
    автоматически записываются в основное хранилище. При этом по-умолчанию
    снижается общая производительность ФС (из-за постоянного вызова
    процедуры коммита всех имеющихся транзакций). Опционально можно задать
    режим без потери производительности. Однако, в этом случае дисковое
    пространство прокси-устройства будет использоваться менее эффективно.
    В качестве прокси-диска удобно использовать подраздел (брик) мета-данных, при условии, что он создан на достаточно высокопроизводительном блочном устройстве.

    Источник: opennet.ru

  • Добавить комментарий