Що нам варто LVM побудувати (принцип роботи, продуктивність, Thin Provision)

Не дивлячись на наявність декількох статей на Хабре, про 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(TM) i5-3570
  • ОЗП 16Gb


Надійність

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

Застосування в продакшені

Підтримка Thin Provisioning з'явилася в RedHat Enterprise Linux 6.x, а в 7-ій гілці стала по замовчуванню режимом для LVM ще на етапі установки, що може побічно свідчити про надійність рішення, а простий LVM2 працює вже дуже давно, і серйозних проблем не викликає.
Маючи на руках оцінки продуктивності, можна прийняти рішення про застосування тієї чи іншої технології для різних сценаріїв.
Приміром, товсті томи будуть добре працювати для віртуалізації маси однотипних машин, без необхідності бекапа на льоту (один майстер образ, і купа снапшотов для цільових виртуалок, зняти снапшот з снапшота вже не можна). Витрата місця буде прийнятним, а продуктивність і гнучкість будуть на висоті. У такому сценарії рідко треба писати в образ оригіналу.
А тонкі томи будуть гідно показувати себе як в сценарії вище (просто будуть значно повільніше), так і в інших, і дадуть можливість створювати снапшоти від снапшотов, і т. д. До всього іншого, швидкість тонких томів може бути близька до товстим, після виділення місця під запис або збільшення розміру фрагмента.

Мотивуючий опитування

/>
/>


<input type=«radio» id=«vv71487»
class=«radio js-field-data»
name=«variant[]»
value=«71487» />
Допомогла вам стаття в розумінні LVM і його застосовності?
<input type=«radio» id=«vv71489»
class=«radio js-field-data»
name=«variant[]»
value=«71489» />
Сам тестував, нічого нового
<input type=«radio» id=«vv71491»
class=«radio js-field-data»
name=«variant[]»
value=«71491» />
Дивився чужі тести, нічого нового

Проголосувало 28 осіб. Утрималося 35 осіб.


Який вид розділів використовуєте найчастіше?

/>
/>

<input type=«radio» id=«vv71493»
class=«radio js-field-data»
name=«variant[]»
value=«71493» />
Простий том
<input type=«radio» id=«vv71495»
class=«radio js-field-data»
name=«variant[]»
value=«71495» />
Товстий том
<input type=«radio» id=«vv71497»
class=«radio js-field-data»
name=«variant[]»
value=«71497» />
Тонкий тому

Проголосувало 25 осіб. Утрималося 36 осіб.


Буду мігрувати на?

/>
/>

<input type=«radio» id=«vv71499»
class=«radio js-field-data»
name=«variant[]»
value=«71499» />
Простий том
<input type=«radio» id=«vv71501»
class=«radio js-field-data»
name=«variant[]»
value=«71501» />
Товстий том
<input type=«radio» id=«vv71503»
class=«radio js-field-data»
name=«variant[]»
value=«71503» />
Тонкий тому

Проголосувало 11 осіб. Утрималося 46 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.