Что нам стоит LVM построить (принцип работы, производительность, Thin Provision)23.02.2016 07:48

Не смотря на наличие нескольких статей на Хабре, про LVM2 и производительность Thin Provisioning, решил провести своё исследование, так как имеющиеся показались мне поверхностными.

Кому интересно, добро пожаловать под кат.

Немного о LVM2

Собственно, LVM это система управления дисковым пространством. Позволяет логически объединить несколько дисковых пространств (физические тома) в одно, и уже из этого пространства (Дисковой Группы или группы томов), можно выделять разделы (Логические Тома), доступные для работы. ОС получает к ним доступ через DevMapper.
Логические тома могут свободно размещаться в дисковой группе, занимая непрерывные или разрывные диапазоны адресов, или находится частично на разных дисках группы. Логические тома можно с легкостью изменять в размерах (а вот ФС не все так могут) или перемещать между дисками группы, а также создавать мгновенные снимки состояния логического тома (снапшот). Именно снапшоты и представляют главный интерес в статье.

Как вообще работает LVM

Идея тут проста, все вертится вокруг таблиц соответствия логических и физических адресов.
Общая схема такая: Физические тома отражаются на Дисковую группу. Дисковая группа отражается на Логические тома.
Снапшоты чуть иначе: собственная таблица ассоциирует блоки оригинального тома и блоки снапшота (копия блоков оригинала, до их модификации). Работает по принципу копирования при записи (CoW, делается копия блока оригинального тома, потом происходит запись этого блока в оригинальном томе). Создать снапшот от снапшота невозможно.

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

Производительность

Производительность толстых томов без снапшотов равна обычным дисковым разделам (разница очень мала), а как обстоят дела со снапшотами?
Тесты показали ад и ужас. Из-за CoW, операции записи в оригинальным том замедляются катастрофически! И чем больше снапшотов, тем хуже.
Несколько исправить положение дел может задание большего размера фрагмента (по умолчанию, это 4 килобайта, что дает большой объем маленьких iops). Ситуация несравнимо лучше, если писать не в оригинальный том, а в снапшот.

Тонкие тома показывают более сбалансированную картину. Скорость работы слабо зависит от числа снапшотов, и скорость значительно ниже, чем для простого толстого тома без снапшотов и близка к скорости записи в толстый снапшот. Основной вклад в тормоза дает процесс выделения места (фрагмент размером в 4 килобайта).

Итоги:

1. Простой раздел впереди по скорости, но не эффективен по занимаемому пространству
2. Толстый том быстрый, пока нет снапшотов, имеет среднюю эффективность по занимаемому пространству
3. Тонкий том самый медленный, но его скорость слабо зависит от снапшотов, самая большая эффективность по пространству

Самая быстрая ФС (в режиме записи): ext4, затем xfs, в конце ext3

Методика тестирования

Создавался раздел или логический том (толстый и тонкий) размером в 50Gb. Полученное пространство форматировалось в ext3, ext4 и xfs. После очищались все буферы и запускалась распаковка tgz архива (размещен в tmpfs в памяти) с образом Centos 7.3 Core (развернут Asterisk и FreePBX) 2Gb объемом в распакованном виде. В конце снова чистил буферы. Замер времени идет от начала распаковки, до финальной очистки буфера.
Для LVM создавался снапшот, а затем в оригинальном томе создавался каталог, куда распаковывался архив повторно. Процедуру повторял пять раз (не удаляя ни снапшотов ни копий файлов из оригинального тома).
Затем, однократно распаковывал архив в каждый снапшот.
В тестирование участвовал:

• Gigabyte Z77X-D3H
• WDC WD7500AAKS-00RBA0
• Intel® Core^™ i5–3570
• ОЗУ 16Gb

Надежность

Оценивать надежность я буду просто, по уровню сложности механизма доступа к информации. Чем он сложнее, тем его надежность ниже (к реальной надежности это имеет довольно далекое отношение).
Самым надежным, выглядит конечно обычный раздел. Пространство линейно, никаких промежуточных абстракций. Ломаться особо не чему. Из клёвых плюшек нет ничего.
Второе место займет Толстый Том. Появившиеся абстракции конечно не делают его надежнее, но добавляют массу гибкости. Восстанавливать данные из рассыпавшегося LVM не так уж и легко, но скорее всего, большинство томов будут размещены линейно, с небольшой фрагментацией (и эти фрагменты возможно будут крупными, вряд ли вы будете расширят разделы маленькими блоками).
Самыми ненадежными выглядят Тонкие Тома. Сложный механизм выделения места, изначально фрагментированное пространство (но не сами данные, они то как раз размещены компактно и даже линейно). Повреждение таблицы трансляции адресов, сделает данные крайне сложно читаемыми. К слову, надежность btrfs, zfs или ntfs на более худшем уровне. У тонких томов только распределение пространства в опасности, а у ФС еще и своих абстракций полно.

Применение в продакшене

Поддержка Thin Provisioning появилась в RedHat Enterprise Linux 6.x, а в 7-ой ветке стала умолчательным режимом для LVM еще на этапе установки, что может косвенно свидетельствовать о надежности решения, а простой LVM2 трудится уже очень давно, и серьезных проблем не вызывает.
Имея на руках оценки производительности, можно принять решение о применении той или иной технологии для различных сценариев.
К примеру, толстые тома будут хорошо работать для виртуализации массы однотипных машин, без необходимости бекапа на лету (один мастер образ, и куча снапшотов для целевых виртуалок, снять снапшот со снапшота уже нельзя). Расход места будет приемлемым, а производительность и гибкость будут на высоте. В таком сценарии редко надо писать в образ оригинала.
А тонкие тома будут достойно показывать себя как в сценарии выше (просто будут значительно медленнее), так и в других, и дадут возможность создавать снапшоты от снапшотов, и т.д. Ко всему прочему, скорость тонких томов может быть близка к толстым, после выделения места под запись или увеличения размера фрагмента.

© Habrahabr.ru