Мені потрібно перенести кілька серверів на Linux, і один важливий аспект, який мені потрібно оцінити, - це те, що моя нова хост-система повинна мати еластичну ємність для зберігання. Природно, роблячи деякі основні дослідження, я натрапив на LVM.
Чи є штраф за ефективність використання lvm? Якщо так, то як я можу це виміряти?
Що я зараз розглядаю - це мати Linux як основну ОС з LVM та віртуалізованими скриньками Linux, що працюють над нею (чи слід додати LVM і в гостьовій ОС?).
Відповіді:
LVM розроблений таким чином, що не дозволяє йому дуже сильно заважати. З точки зору простору користувача, це схоже на ще один шар "віртуальних речей" на диску, і, здається, природно уявити, що всі введення-виведення повинні пройти через це, перш ніж потрапити в реальний або з реального обладнання.
Але це не так. Ядро вже має мати відображення (або фактично декілька шарів відображення), яке з'єднує операції високого рівня, такі як "записати це у файл" драйверам пристроїв, які, в свою чергу, підключаються до фактичних блоків на диску.
Коли LVM використовується, цей пошук змінюється, але це все. (Оскільки це має статися так чи інакше, робити це трохи інакше - це незначний удар продуктивності.) Якщо мова йде про фактичне написання файлу, біти приймають як прямий шлях до фізичного носія, як інакше.
Є випадки, коли LVM може спричинити проблеми з роботою. Ви хочете переконатися, що блоки LVM вирівняні належним чином до базової системи, що має відбуватися автоматично із сучасними дистрибутивами. І переконайтеся, що ви не використовуєте старі ядра, які піддаються помилкам, як цей . О, а використання знімків LVM погіршує продуктивність (і все частіше це стосується кожного активного знімка). Але в основному вплив має бути дуже малим.
Щодо останнього: як можна протестувати? Стандартний інструмент для порівняльного диска - боні ++ . Зробіть розділ за допомогою LVM, протестуйте його, витріть його та (там же, щоб інші фактори були однаковими), знову створіть звичайну файлову систему та орієнтир. Вони повинні бути близькими до однакових.
LVM, як і все інше, - змішане благо.
Щодо продуктивності, LVM трохи завадить вам, тому що це ще один шар абстракції, який потрібно опрацювати, перш ніж біти потраплять (або можна прочитати з) диску. У більшості ситуацій цей ударний показник буде практично незмірним.
До переваг LVM можна віднести те, що ви можете додати більше пам’яті до існуючих файлових систем без необхідності переміщення даних. Більшість людей люблять це за цю перевагу.
Одним з недоліків використання LVM, який використовується таким чином, є те, що якщо ваші додаткові сховища охоплюють диски (тобто включають більше одного диска), ви збільшуєте ймовірність того, що збій диска обійдеться вашим даним. Якщо ваша файлова система охоплює два диски, і будь-який з них виходить з ладу, ви, ймовірно, загублені. Для більшості людей це прийнятний ризик , пов'язаний з просторово-проти-витрат причин (наприклад , якщо це дійсно важливо буде бюджет , щоб зробити це правильно) - і тому, що, як вони кажуть, резервні копії є добре, вірно?
Для мене єдиною причиною не використовувати LVM є те, що відновлення після аварій не є (або, принаймні, не було) чітко визначеним. Диск з обсягами LVM, який мав зашифровану ОС на ньому, не міг тривіально приєднатися до іншого комп’ютера, і дані, що були відновлені з нього; багато інструкцій щодо відновлення томів LVM, здавалося, включають такі кроки, як повернення у часі та запуск vgcfgbackup, а потім скопіюйте отриманий файл / etc / lvmconf в систему, на якій розміщений ваш шланг . Сподіваюся, все змінилося за три-чотири роки, коли я востаннє мав на це дивитися, але особисто я ніколи не використовую LVM з цієї причини.
Це сказав.
У вашому випадку я б припустив, що VM будуть порівняно невеликими порівняно з хост-системою. Це означає для мене, що ви, швидше за все, хочете розширити сховище у віртуальній машині пізніше; найкраще це зробити, додавши до віртуальної машини ще один віртуальний диск, а потім зробивши файлові системи, що стосуються VM. У вас немає вразливості Spanning-декілька дисків, оскільки вірогідні диски, ймовірно, будуть знаходитися на тому ж фізичному пристрої в хост-системі.
Якщо вітрини взагалі матимуть для вас будь-яке значення, ви якось будете RAID'і хост-системою, що знизить гнучкість для подальшого зростання сховища. Тож гнучкість LVM, ймовірно, не буде потрібною.
Тому я б припустив, що ви не будете використовувати LVM в хост-системі, але встановите VM для використання LVM.
Загалом: Якщо ви додасте новий рівень складності ("ще більше робити"), нічого швидше не буде. Примітка. Ви лише додаєте роботу, а не змінюєте їх спосіб виконання роботи.
Як ти можеш щось виміряти? Ну, ви створюєте один розділ з LVM і один без, а потім використовуєте звичайний орієнтир і просто запускаєте його. Як і люди в
http://www.umiacs.umd.edu/~toaster/lvm-testing/
Як здається, лише трохи впливає на швидкість. Це, мабуть, синхронізується з висновками когось іншого, хто керував еталоном:
"ext4 швидше з LVM, ніж без, та інші орієнтири файлової системи" Нитка розсилки Linux Kernel
Але просто порівняйте його самостійно і переконайтеся, що обладнання та ОС, яку ви хочете використовувати, поводяться однаково, і чи зможете ви проігнорувати (можливо трохи) вплив додаткового рівня складності, який дає вам еластичне зберігання.
Чи слід додати LVM до гостьової ОС: Це залежить від того, чи потрібна гостьовій ОС також еластичне сховище, чи не так? Ваші потреби диктують, що вам потрібно розгорнути.
Ефективність не дуже велика, лише з lvm, але якщо ви готові взяти її, скористайтеся zfs. Ви отримуєте управління обсягом та відновлення та всілякі інші чудові функції.
Ніхто не згадує lvm2 не може змусити мультиплікацію швидкості читання та запису (подібно raid0). Я особисто використовую 3 однакові диски, і над ними lvm2 в позбавленому режимі, операції читання і запису займають 1/3 часу, це великий вплив, файлова система на три рази швидша за неї. Я знаю: будь-який диск вийде з ладу і всі дані на них не будуть доступними; але це не означає втраченого, оскільки BackUP - НЕ ПОВИНЕН, нічого подібного до Raid, LVM2, ZFS не уникатиме наявності BackUP; тому я ніколи не використовую дзеркальне відображення, raid5 тощо, я завжди використовую зачистку (щоб отримати найкращу ефективність) і синхронізував резервні копії. ZFS відмінно підходить для стиснення під час льоту, а параметр копій, більший за один, схожий на дзеркальне відображення, але одна річ, яку має ZFS, і ні в кого іншого не відбувається автоматичне відновлення під час руху бітової гнилі (біти, які спонтанно змінюються під час диск вимкнено),
Для відновлення: я використовую ZFS лише для моїх резервних копій на зовнішніх дисках, декілька (два або три) ssd з lvm2 смугастим для ОС (aftwr модернізація і повторний клон ОС), я схильний використовувати незмінні ОС; і я використовую декілька (шість) спіннін-дисків з позбавленим lvm2 для даних, як віртуальні машини, знову змінюють будь-які зміни та повторюють BackUP; тому після відмови диска мені потрібно лише замінити його та відновити останню резервну копію; зараз у мене майже 1,8 Гбіт / с швидкість запису, тому відновлення однієї віртуальної машини з BackUP займає лише менше 30 секунд (32 Гбіт на диск віртуальної машини).
Отже, моя відповідь: не використовуйте лише одне, будьте розумні та використовуйте найкраще з кожної деталі, знімається lvm2 швидше, ніж рівень mdraid 0, більше при використанні шести спінінг-дисків; одне попередження із зачисткою ssd, два та три - це добре, чотири ssd можуть погіршити продуктивність (мої тести дали нижчу швидкість запису, коли я використовував чотири однакові ssd у позбавленому режимі, незалежно від того, lvm, mdraid0 тощо), здається, що SSD TRIM і таке Посилення запису може бути основною причиною додавання більше ssd до позбавленого обсягу, що знижує швидкість запису.
Налаштування за допомогою ssd та будь-якого raid0 (позбавлений томів) вирівняйте речі ідеально, присвойте розміри кластерів у файловій системі правильно, розмір stip тощо, щоб ніхто не викликав деградації; як зразок: дисковий сектор становить 2048, так що 2K при будь-якому читанні / записі як мінімум, ніколи не використовуйте файлову систему, яка використовує кластер кластерів 512 байтів, при цьому краще використовувати розмір кластера 2K або 4K; тепер уявіть, що ви використовуєте 3xHDD, кожен з 2К секторів, тож у будь-якому кластері файлів оптимізованої файлової системи для читання / запису було б 3x2K = 6K, але це неможливо у багатьох файлових системах, тоді подумайте, що якщо використовувати розмір кластера 64K, 64K / 6K = 32 / 3, що спричиняє незбалансованість, тобто не оптимальність тощо. Зробіть математику, щоб отримати оптимальний розмір кластера.
Мої найкращі результати: розмір кластера = смугастий розмір * кількість диска на смужці; таким чином кожне читання / запис має точний розмір, який змушує працювати всі диски, тому підвищення швидкості дуже велике. Приклад розміру кластера 192K для 3 дисків з розміром смуги 64K; ще один приклад розміром кластера 192K на 6 диску з розміром смуги 32K.
І завжди пам’ятайте про тестування одного диска в блоці 4K, 8K, 16K, 32K, 64K; багато дисків дає дуже погані швидкості з меншими числами, як-то 4K, але дає більш ніж у десять разів швидший час, коли на 64K, 128K або вище.
Так, використання великих розмірів кластера може втратити просторі на лазерному кластері кожного файлу (якщо ви використовуєте мільйони файлів лише по 1 байті кожен), краще використовувати компактну / пакетну логічну систему через файлову систему, як зразок диск 4TiB з розміром кластера 4K може мати лише менше 4TiB / 4K = 1073741824 файлів по 1Byte кожен, тобто всього 1GiB, якщо всі файли розміром 1Byte (розмір кластера 4K), більший коефіцієнт розміру кластера, але якщо файли величезні, як віртуальні машини (біля 32GiB як зразок, або лише кілька мегабайт), втрачені лише на останньому кластері; настільки великі файли, великий розмір кластера набагато кращий для продуктивності, але будьте уважні, як його використовує віртуальна машина
Ніхто не скаже вам цю таємницю: всередині гостя не використовуйте розмір кластеру 4K, використовуйте той самий розмір кластера, що і розмір кластера, де розміщується віртуальний диск або його кратне число.
Так, я маніакально отримати максимальну швидкість всередині гостьових дисків, як я сказав, що з 6 обертовими дисками я наближаюся до 1,7 Гбіт / с, швидкість шини SATA III - це вузьке місце, а не самі диски. Я використовую диски високого класу (не дешеві), кеш 128MiB зі швидкістю запису 283MiB / с кожен.
Для вас і для всіх людей: Найкраще дізнатися, як розмір кластера, розмір смуги та розмір блоку повинні бути пов'язані перед тим, як зробити тест швидкості, інакше тестування LVM2 або будь-якого іншого RAID (також ZFS) може дати помилкові висновки.
Якраз зразок для такого: я перевіряю час завантаження linux з 2,5-дюймовим дисплеєм Sata II на 2x60MiB / s на 2,5 дюймів 5400 об / хв. порти), час завантаження займає лише дві секунди менше, всього дві секунди на п'ятихвилинне завантаження, чому? через те, що більшість дисків часу завантаження не використовуються, вони роблять речі на ram і процесорі, але не введення / виведення даних.
Завжди перевіряйте те, що ви будете робити в реальному дні, а не просто сильні швидкості (іншими словами, максимальна швидкість).
Максимальна швидкість добре знати, що біт не є представницьким, ви не можете використовувати диски з максимальною швидкістю 100% часу, ОС і додатки повинні робити оперативні оперативні можливості та процесор без вводу / виводу, тому на той час швидкість диска не робить матерія взагалі.
Всі люди кажуть, що SSD значно покращує швидкість завантаження Windows, на моїх тестах, які також НЕБАЛЬНІ, це лише я доводить 28 секунд на час завантаження близько восьмих хвилин.
Отже, якщо ви подобаєтесь мені: Linux при копіюванні в операційну систему для завантаження, SSD не буде кращим, ніж обертові жорсткі диски, я також протестував USB 3.1 Gen2 stick (читається 139 Мбіт / с), час завантаження впливає лише на кілька секунд на п'ятихвилинне завантаження, чому? легко, зчитування робиться при копіюванні в ram, afyer, ніж диск / ssd / usb-stick, знову не використовується на решті болта, дані - на операційній пам’яті, як на операційний диск.
Тепер я продаю всі свої SSD, які у мене є, вони не покращують копіювання на операційну систему Linux при завантаженні, але порівняльне їх порівняння говорить про те, що вони в 5 разів швидше ... дивіться, тест дає помилкові висновки ... так, тест і тест реальний денна робота.
Сподіваюсь, це може зрозуміти чоловічі речі ... LVM з поганими розмірами кластера та смужки впливають набагато більше, ніж накладні шари.