Небезпеки та обмеження щодо ННМ

Нещодавно я почав використовувати LVM на деяких серверах для жорстких дисків більше 1 ТБ. Вони корисні, розширювані та досить прості в установці. Однак я не зміг знайти жодних даних про небезпеку та застереження ЛВМ.

Які недоліки використання LVM?

Підсумок

Ризики використання LVM:

• Вразлива для запису проблем кешування з SSD або VM гіпервізором
• Важче відновити дані за рахунок складніших структур на диску
• Складніше правильно змінити розмір файлових систем
• Знімки важкі у використанні, повільні та баггі
• Потрібен певний навик, щоб правильно налаштувати дані проблеми

Перші дві проблеми з LVM поєднуються: якщо кешування запису працює неправильно, і у вас втрата електроенергії (наприклад, PSU або UPS виходить з ладу), можливо, доведеться відновитись із резервного копіювання, що означає значний час простою. Основна причина використання LVM - більший час роботи (додавання дисків, зміна розміру файлових систем тощо), але важливо правильно встановити кешування записів, щоб уникнути фактичного скорочення часу роботи LVM.

- Оновлено грудень 2018 року: оновлений знімковий матеріал, включаючи стабільність ZFS та btrfs як альтернативу знімків LVM

Пом'якшення ризиків

LVM може працювати добре, якщо ви:

• Отримайте налаштування кешування записів прямо в гіпервізорі, ядрі та SSD
• Уникайте знімків LVM
• Використовуйте останні версії LVM для зміни розміру файлових систем
• Майте хороші резервні копії

Деталі

Я досліджував це досить небагато в минулому, відчував деяку втрату даних, пов’язану з LVM. Основні ризики, пов'язані з ННМ, і які я знаю, це:

Уразливий кеш-запис для запису на жорсткий диск за рахунок гіпервізорів VM, кешування диска або старих ядер Linux і ускладнює відновлення даних завдяки складнішим структурам диска - детальніше див. Нижче. Я бачив, що повні установки LVM на декількох дисках пошкоджуються без жодного шансу на відновлення, і кешування записів на жорсткий диск на жорсткому диску є небезпечною комбінацією.

• Записування кешування та переупорядкування запису на жорсткому диску важливо для хорошої продуктивності, але може не вдатися до того, щоб блоки були правильно завантажені на диск через гіпервізори VM, кешування записів на жорсткий диск, старі ядра Linux тощо.
  • Бар'єри для запису означають, що ядро ​​гарантує, що воно завершить певний запис диска до запису диска "бар'єр", щоб забезпечити відновлення файлових систем і RAID у разі раптових втрат або збоїв живлення. Такі бар'єри можуть використовувати операцію FUA (Force Unit Access) для негайного запису певних блоків на диск, що є більш ефективним, ніж повна кеш-флеш. Бар'єри можуть поєднуватися з ефективною міткою / нативної черги команд (видача декількох запитів на введення / виведення декількох дисків одночасно), що дозволяє жорсткому диску виконувати інтелектуальне переупорядкування запису, не збільшуючи ризик втрати даних.
• Гіпервізори VM можуть мати подібні проблеми: запуск LVM в Linux-гості над гіпервізором VM, таким як VMware, Xen , KVM, Hyper-V або VirtualBox, може створювати схожі проблеми з ядром без бар'єрів для запису, завдяки кешуванню записів і запису -відповідність. Уважно перевірте документацію гіпервізора на наявність "кеш-пам’яті на диск" або кеш-пам'яті для запису (присутній у KVM , VMware , Xen , VirtualBox та інших) - і протестуйте її з налаштуванням. Деякі гіпервізори, такі як VirtualBox, мають налаштування за замовчуванням, яке ігнорує будь-які спалахи диска від гостя.
• Корпоративні сервери з LVM завжди повинні використовувати RAID-контролер, що підтримується батареєю, і відключати кешування запису на жорсткому диску (у контролері є кеш-пам’ять, який підтримує акумулятор, який є швидким і безпечним) - дивіться цей коментар автора цієї статті XFS FAQ . Також може бути безпечним вимкнення бар'єрів запису в ядрі, але тестування рекомендується.
• Якщо у вас немає RAID-контролера, що підтримується батареєю, відключення кешування записів на жорсткому диску повільно запише, але зробить LVM безпечним. Ви також повинні використовувати еквівалент data=orderedопції ext3 (або data=journalдля додаткової безпеки), плюс barrier=1щоб гарантувати, що кешування ядра не впливає на цілісність. (Або використовуйте ext4, який дає змогу встановити бар'єри за замовчуванням .) Це найпростіший варіант і забезпечує хорошу цілісність даних за вартістю продуктивності. (Linux змінив параметр ext3 за замовчуванням на більш небезпечний data=writeback, тому не покладайтеся на настройки за замовчуванням для FS.)
• Щоб відключити кешування запису на жорсткий диск : додайте hdparm -q -W0 /dev/sdXвсі диски в /etc/rc.local(для SATA) або використовуйте sdparm для SCSI / SAS. Однак, згідно з цим записом у поширених запитаннях XFS (що дуже добре в цій темі), привід SATA може забути це налаштування після відновлення помилки накопичувача - значить, ви повинні використовувати SCSI / SAS, або якщо ви повинні використовувати SATA, то поставте Команда hdparm у роботі cron, що працює щохвилини.
• Щоб забезпечити кешування SSD / жорсткого диска увімкненим для кращої продуктивності: це складна область - див. Розділ нижче.
• Якщо ви використовуєте накопичувачі розширеного формату, тобто фізичні сектори 4 Кб, див. Нижче - вимкнення кешування запису може мати інші проблеми.
• Джерело живлення є критичним як для підприємства, так і для SOHO, але недостатньо для забезпечення безпеки LVM: все, що спричиняє важкий збій або втрату електроенергії (наприклад, збій ДБЖ, збій блоку живлення або виснаження акумулятора ноутбука), може втратити дані в кешах жорсткого диска.
• Дуже старі ядра Linux (2.6.x від 2009 р.) : Неповна підтримка бар'єру для запису у дуже старих версіях ядра, 2.6.32 і новіших ( 2.6.31 має деяку підтримку , тоді як 2.6.33 працює для всіх типів цільових пристроїв) - RHEL 6 використовує 2.6.32 з багатьма виправленнями. Якщо ці старі 2.6 ядра не виправлені для цих питань, велика кількість метаданих FS (включаючи журнали) може бути втрачена жорстким збоєм, який залишає дані в буферах запису на жорстких дисках (скажімо, 32 Мб на диск для загальних дисководів SATA). Втрата 32 Мб останніх написаних метаданих і даних журналів FS, які, на думку ядра, вже є на диску, зазвичай означає велику кількість FS-корупції, а отже, і втрату даних.
• Резюме: Ви повинні подбати про файлову систему, RAID, VM гіпервізор та налаштування жорсткого диска / SSD, що використовуються з LVM. Якщо ви використовуєте LVM, у вас повинні бути дуже хороші резервні копії, і обов'язково створіть резервну копію метаданих LVM, налаштування фізичних розділів, MBR та секторів завантаження томів. Також доцільно використовувати диски SCSI / SAS, оскільки вони рідше брешуть про те, як вони кешують запис - більше уважності потрібно використовувати накопичувачі SATA.

Забезпечення кешування записів увімкнено для продуктивності (та впорядкування лежачих дисків)

Більш складний, але ефективний варіант полягає в тому, щоб увімкнути кешування запису SSD / жорсткого диска та покластися на бар'єри для запису ядра, які працюють з LVM на ядрі 2.6.33+ (подвійний перевір, шукаючи повідомлення "бар'єрних" в журналах).

Ви також повинні переконатися, що налаштування RAID, налаштування гіпервізора VM та файлова система використовують бар'єри для запису (тобто вимагає, щоб диск накопичував очікувані записи до та після запису основних метаданих / журналу). XFS використовує бар'єри за замовчуванням, але ext3 цього не робить , тому для ext3 слід використовувати barrier=1в параметрах монтажу, а ще використовувати data=orderedабо data=journalяк вище.

• На жаль, деякі жорсткі диски та SSD брешуть про те, чи дійсно вони передали кеш на диск (особливо старші диски, але включаючи деякі диски SATA та деякі корпоративні SSD ) - детальніше тут . Є чудовий підсумок розробника XFS .
• Існує простий інструмент для тестування лежачих накопичувачів (сценарій Perl), або перегляньте цей фон з іншим тестуванням інструментів для переупорядкування запису в результаті кешу накопичувача. Ця відповідь охоплювала аналогічні тестування SATA-накопичувачів, які виявили проблему бар'єру запису в програмному RAID - ці тести фактично виконують весь стек пам’яті.
• Більш недавні накопичувачі SATA, що підтримують Native Command Queuing (NCQ), можуть мати меншу ймовірність - або, можливо, вони добре працюють без кешування запису через NCQ, і дуже мало приводів не можуть відключити кешування запису.
• SCSI / SAS накопичувачі, як правило, добре, оскільки їм не потрібно кешування запису для успішної роботи (через SCSI Tagged Command Queuing , аналогічно NCQ SATA).
• Якщо ваші жорсткі диски або жорсткі диски брешуть про перенесення кешу на диск, ви дійсно не можете розраховувати на бар'єри для запису і потрібно вимкнути кешування запису. Це проблема для всіх файлових систем, баз даних, менеджерів томів та програмного RAID , а не лише для LVM.

SSD - накопичувачі є проблематичними , оскільки використання кеша запису має вирішальне значення для терміну служби SSD. Найкраще використовувати SSD, який має суперконденсатор (щоб увімкнути промивання кешу при відключенні електроенергії, а отже, дозволити кеш-пам'ять не бути записаною).

• Більшість корпоративних SSD-дисків повинні бути в порядку кешування кешами запису, а деякі включають суперконденсатори.
• Деякі дешевші SSD мають проблеми, які неможливо виправити за допомогою кешування запису - список розсилки проекту PostgreSQL та вікі-сторінку Надійні записи - хороші джерела інформації. На споживчих SSD можуть виникнути основні проблеми з кешуванням записів, що призведе до втрати даних, і не включати суперконденсатори, тому вони вразливі до збоїв живлення, що спричиняють корупцію.

Настройка накопичувача розширеного формату - кешування запису, вирівнювання, RAID, GPT

• З новішими накопичувачами розширеного формату, які використовують фізичні сектори 4 кіБ, може бути важливим, щоб кешування запису диска було увімкнено, оскільки більшість таких дисків наразі емулюють 512 байт логічні сектори ( "512 емуляція" ), а деякі навіть заявляють, що мають 512-байт фізичний секторів, використовуючи 4 КіБ.
• Вимкнення кешу запису накопичувача розширеного формату може спричинити дуже великий вплив на продуктивність, якщо програма / ядро ​​виконує запис 512 байтів, оскільки такі диски покладаються на кеш, щоб накопичити записи 8 х 512 байтів перед тим, як зробити один фізичний 4 кібайт писати. Тестування рекомендується підтвердити будь-яким впливом, якщо вимкнути кеш.
• Вирівнювання НН на межі 4 Кб важливо для продуктивності, але повинно відбуватися автоматично, доки базові розділи для ПВ вирівнюються, оскільки фізичні розширення ННМ (ПЕ) за замовчуванням становлять 4 МіБ. Тут слід врахувати RAID - ця сторінка налаштування програмного забезпечення для LVM та програмного забезпечення пропонує встановити суперблок RAID в кінці гучності і (за необхідності) використовувати параметр pvcreateдля вирівнювання ПВ. Цей потік списку електронної пошти LVM вказує на роботу, виконану в ядрах протягом 2011 року, і випуск часткового блоку запису при змішуванні дисків з 512 байтовими та 4 кіБ секторами в одному LV.
• Розділ GPT з розширеним форматом потребує догляду, особливо для завантажувальних + кореневих дисків, щоб переконатися, що перший розділ LVM (PV) починається на межі 4 KiB.

Важче відновити дані завдяки складнішим структурам на диску :

• Будь-яке відновлення даних LVM, необхідних після жорсткої аварії або втрати електроенергії (через неправильне кешування запису), в кращому випадку є ручним процесом, оскільки, мабуть, немає відповідних інструментів. LVM добре зберігає свої метадані під /etc/lvm, що може допомогти відновити основну структуру LV, VG та PVs, але не допоможе втратити метадані файлової системи.
• Отже, ймовірно, буде потрібно повне відновлення після резервного копіювання. Це передбачає набагато більше простоїв, ніж швидкий fsck на основі журналу, коли не використовується LVM, і дані, записані після останньої резервної копії, будуть втрачені.
• TestDisk , ext3grep , ext3undel та інші інструменти можуть відновлювати розділи та файли з дисків, що не є LVM, але вони безпосередньо не підтримують відновлення даних LVM. TestDisk може виявити, що втрачений фізичний розділ містить PV-файл LVM, але жоден із цих інструментів не розуміє логічних обсягів LVM. Інструменти різьблення файлів, такі як PhotoRec та багато інших, працювали б, коли вони обходять файлову систему для повторного збирання файлів із блоків даних, але це остання можливість, підхід низького рівня для цінних даних і працює менш добре з фрагментованими файлами.
• Керівництво відновлення LVM можливо в деяких випадках, але є складним і вимагає багато часу - див цього прикладу і це , це , і це для того, як відновити.

Важко правильно змінити розмір файлових систем - легко змінювати розмір файлової системи часто надається як перевага LVM, але вам потрібно виконати півдесятка команд оболонки, щоб змінити розмір FS на базі LVM - це можна зробити, коли весь сервер все ще працює, а в деяких випадках при встановленому FS, але я ніколи б не ризикував останнім без попереднього резервного копіювання та використання команд, попередньо протестованих на еквівалентному сервері (наприклад, клон відновлення аварійних виробничих серверів).

• Оновлення: Більш новіші версії lvextendпідтримки опції -r( --resizefs) - якщо така є, це більш безпечний і швидкий спосіб змінити розмір LV і файлової системи, особливо якщо ви скорочуєте FS, і ви можете в основному пропустити цей розділ.
• Більшість посібників щодо зміни розміру FS на основі LVM не враховують той факт, що FS повинен бути дещо меншим за розмір LV: детальне пояснення тут . Під час скорочення файлової системи вам потрібно буде вказати новий розмір інструменту зміни розміру FS, наприклад, resize2fsдля ext3 та до lvextendабо lvreduce. Без особливої ​​обережності розміри можуть дещо відрізнятися через різницю між 1 ГБ (10 ^ 9) та 1 ГіБ (2 ^ 30), або тому, як різні інструменти округляють розміри вгору або вниз.
• Якщо ви не зробите обчислення точно (або скористаєтеся додатковими кроками поза межами найбільш очевидних), ви можете отримати FS, який занадто великий для LV. Місяці чи роки все буде здаватися нормальним, поки ви повністю не заповните FS, і тоді ви отримаєте серйозну корупцію - і якщо ви не знаєте про це питання, важко дізнатися чому, оскільки до цього часу ви також можете мати справжні помилки на диску що затуманило ситуацію. (Можливо, ця проблема впливає лише на зменшення розміру файлових систем. Однак очевидно, що зміна розміру файлових систем в будь-якому напрямку збільшує ризик втрати даних, можливо, через помилку користувача.)

• Здається, що розмір LV повинен бути більшим за розмір FS на 2 x розмір фізичної величини LVM (PE) - але перевірте посилання вище для деталей, оскільки джерело для цього не є авторитетним. Часто дозволяти 8 MiB достатньо, але, можливо, краще дозволити більше, наприклад, 100 MiB або 1 GiB, просто для безпеки. Щоб перевірити розмір PE та ваш логічний обсяг + розміри FS, використовуючи 4 KiB = 4096 байтових блоків:

  Показує розмір PE в KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Розмір усіх НН:
  lvs --units 4096b
  
  Розмір (ext3) FS, припускає розмір блоку в 4 кіБ FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Навпаки, налаштування без LVM дозволяє змінити розмір FS дуже надійним та простим - запустити Gparted та змінити розмір потрібних FS , тоді він зробить усе за вас. На серверах можна використовувати partedз оболонки.

  • Найчастіше найкраще використовувати компакт-диск Gparted Live або Parted Magic , оскільки у них є останній і часто більше помилок Gparted & ядро, ніж версія дистрибутива - я одного разу втратив цілий FS через те, що Gparted дистрибутива не оновлював належним чином під час роботи ядро. Якщо ви використовуєте Gparted дистрибутива, не забудьте перезавантажити відразу після зміни розділів, щоб перегляд ядра був правильним.

Знімки важкі у використанні, повільні та баггі - якщо знімок закінчується заздалегідь виділеним простором, він автоматично скидається . Кожен знімок даного LV є дельтою проти цього LV (а не проти попередніх знімків), який може вимагати багато місця під час зйомки файлових систем із значною активністю запису (кожен знімок більший за попередній). Безпечно створити LV-знімок, що має той самий розмір, що і оригінальний НН, оскільки знімок ніколи не втратить вільного місця.

Знімки також можуть бути дуже повільними (тобто 3 - 6 разів повільніше, ніж без LVM для цих тестів MySQL ) - див. Цю відповідь, що висвітлює різні проблеми з знімком . Повільність частково пояснюється тим, що знімки вимагають багатьох синхронних записів .

Знімки мали деякі значні помилки, наприклад, у деяких випадках вони можуть робити завантаження дуже повільним або спричиняти повний збій завантаження (тому що ядро може вичерпати очікування кореневого FS, коли це знімок LVM [зафіксовано в initramfs-toolsоновленнях Debian , березень 2015] ).

• Однак, багато помилок з умовами гонки на знімку, очевидно, були виправлені до 2015 року.
• LVM без знімків зазвичай здається налагодженою, можливо, тому, що знімки використовуються не так багато, як основні функції.

Альтернативи знімків - файлові системи та VM гіпервізори

Знімки VM / хмари:

• Якщо ви використовуєте гіпервізор VM або постачальник хмарних технологій IaaS (наприклад, VMware, VirtualBox або Amazon EC2 / EBS), їх знімки часто є набагато кращою альтернативою знімків LVM. Ви можете досить легко зробити знімок для цілей резервного копіювання (але розгляньте, як заморозити FS, перш ніж це зробити).

Знімки файлової системи:

• Знімки на рівні файлової системи з ZFS або btrfs прості у використанні і, як правило, краще, ніж LVM, якщо ви на голому металі (але ZFS здається набагато більш зрілим, просто більше клопоту встановити):

  • ZFS: зараз є реалізація ZFS ядра , яка використовується вже кілька років
  • btrfs : досі не готовий до використання ( навіть у openSUSE, який постачає його за замовчуванням і має команду, присвячену btrfs), тоді як RHEL перестала його підтримувати), а його інструменти для fsck та ремонту все ще розробляються.

Знімки для онлайн-резервного копіювання та fsck

Знімки можна використовувати для забезпечення послідовного джерела для резервного копіювання, якщо ви обережні з виділеним простором (в ідеалі знімок має той же розмір, що і резервне копіювання НН). Чудовий rsnapshot (з 1.3.1) навіть керує створенням / видаленням LVM-знімків для вас - дивіться це HOWTO на rsnapshot за допомогою LVM . Однак зверніть увагу на загальні проблеми з знімками та те, що знімок не повинен вважатися резервним копієм сам по собі.

Ви також можете використовувати знімки LVM для того, щоб робити онлайн-fsck: робити знімок LV та fsck знімок, використовуючи при цьому основний FS-знімок, не описаний тут, - однак це не зовсім просто, тому найкраще використовувати e2croncheck, як описано Тедом Ц 'o , супровідник ext3.

Вам слід тимчасово "заморозити" файлову систему під час зйомки - деякі файлові системи, такі як ext3 та XFS, зроблять це автоматично, коли LVM створює знімок.

Висновки

Незважаючи на все це, я все ще використовую LVM в деяких системах, але для налаштування робочого столу я віддаю перевагу сирим розділам. Основна перевага, яку я бачу від LVM, - це гнучкість переміщення та зміни розміру FS, коли ви повинні мати великий час роботи на сервері - якщо вам це не потрібно, gparted простіше і має менший ризик втрати даних.

LVM вимагає великої обережності щодо налаштування кешування записів через гіпервізори VM, кешування на жорсткому диску / SSD тощо, але те саме стосується використання Linux як сервера БД. Відсутність підтримки більшості інструментів ( gpartedвключаючи критичні розрахунки розміру testdiskтощо) робить його складнішим, ніж повинен бути.

Якщо ви використовуєте LVM, будьте дуже обережні зі знімками: використовуйте знімки VM / хмари, якщо це можливо, або досліджуйте ZFS / btrfs, щоб повністю уникнути LVM - ви можете виявити, що ZFS або btrs є достатньо зрілими порівняно з LVM зі знімками.

Підсумок: Якщо ви не знаєте про проблеми, перелічені вище та як їх вирішити, краще не використовувати LVM.

Я [+1] цю посаду, і принаймні для мене я думаю, що більшість проблем існують. Бачили їх під час роботи декількох 100 серверів і декількох 100 ТБ даних. Для мене LVM2 в Linux відчуває себе як "розумна ідея", у когось була. Як і деякі з них, вони часом виявляються "не розумними". Тобто, не маючи суворо відокремлених станів ядра та користувальницького простору (lvmtab), можливо, було б по-справжньому розумним, тому що можуть виникнути проблеми з корупцією (якщо ви не правильно знайдете код)

Ну, тільки що це розділення було з причини - відмінності демонструються з поводженням з втратами на PV та в режимі он-лайн повторної активації VG, тобто відсутніх ПВ, щоб повернути їх у гру - Що таке вітер від "оригінальних LVM" (AIX , HP-UX) перетворюється на лайно на LVM2, оскільки керованість станом недостатньо хороша. І навіть не змушуйте мене говорити про виявлення втрат Quorum (ха-ха) або обробку станом (якщо я видалю диск, він не буде позначений як недоступний. У ньому навіть немає чортового статусу)

Re: стабільність pvmove ... чому так

втрата даних pvmove

така стаття найвищого рейтингу в моєму блозі, гммм? Щойно я дивлюсь на диск, на якому досі вивішені дані фізскалу lvm ​​про стан від середини pvmove. Мені здається, що я маю на увазі деякі повідомлення, і загальна думка, що копіювати дані живого блоку з простору користувача просто сумно. Приємна цитата зі списку lvm ​​"здається, що vgreduce --missing не обробляє pvmove" Це означає, якщо диск відхиляється під час pvmove, тоді інструмент управління lvm змінюється з lvm на vi. Так, також сталася помилка, коли pvmove продовжується після помилки читання / запису блоку і насправді більше не записує дані на цільовий пристрій. WTF?

Re: Знімки КР робиться небезпечно, оновивши НОВІ дані в область lv знімка, а потім об'єднавшись назад, як тільки ви видалите оснащення. Це означає, що під час останнього злиття нових даних у вихідний НН ви маєте великі шипи введення-виведення, і, що ще важливіше, ви, звичайно, також маєте набагато більший ризик пошкодження даних, оскільки не знімок буде порушений, коли ви натиснете на стіна, але оригінальна.

Перевага полягає у продуктивності: робити 1 запис замість 3. Вибір швидкого, але небезпечного алгоритму - це те, чого, очевидно, очікують від людей, таких як VMware та MS, на "Unix", я вважаю, що все буде "зроблено правильно". Я не бачив великих проблем з продуктивністю, доки у мене зберігається резервна копія знімків на іншому дисководі, ніж основні дані (і резервне копіювання на ще одне, звичайно)

Re: Шлагбауми Я не впевнений, чи можна звинувачувати це в LVM. Наскільки я знаю, це було проблемою Devmapper. Але може бути якась провина за те, що насправді не піклується про цю проблему, щонайменше, від ядра 2.6 до 2.6.33. AFAIK Xen - єдиний гіпервізор, який використовує O_DIRECT для віртуальних машин, яка була проблема, коли використовується "цикл", тому що ядро все одно кешуватиметься цим. У Virtualbox принаймні є деякі налаштування для відключення таких матеріалів, а Qemu / KVM, як правило, дозволяє кешувати. Усі FUSE FS також мають там проблеми (немає O_DIRECT)

Re: Розміри Я думаю, що LVM робить "округлення" відображеного розміру. Або він використовує GiB. У будь-якому випадку вам потрібно використовувати розмір VG Pe і помножити його на номер LE на LV. Це має дати правильний розмір нетто, і це питання завжди є проблемою використання. Це погіршується файловими системами, які не помічають подібного під час fsck / mount (привіт, ext3) або не мають робочого в режимі он-лайн "fsck -n" (привіт, ext3)

Звичайно, це говорить про те, що ви не можете знайти хороших джерел для такої інформації. "скільки ЛЕ для VRA?" "що таке фіскальне зміщення для PVRA, VGDA, ... тощо"

Порівняно з оригіналом, LVM2 - це головний приклад "Ті, хто не розуміє UNIX, засуджені, щоб винаходити його погано".

Оновлення через кілька місяців: я вже потрапив у сценарій "повного знімка" для тесту. Якщо вони будуть заповнені, знімки блокуються, а не оригінальний LV. Я помилявся там, коли вперше опублікував це. Я зібрав неправильну інформацію від якогось документа, або, можливо, я зрозумів це. У своїх налаштуваннях я завжди був дуже параноїком, щоб не давати їм заповнити, і тому я ніколи не виправлявся. Можна також розширити / зменшити знімки, що є задоволенням.

Що я досі не змогла вирішити - це визначити вік знімка. Щодо їхньої продуктивності, на сторінці проекту «тонкий» фідра є примітка, в якій сказано, що техніка знімків переглядається, щоб вони не повільніше ставились із кожним знімком. Я не знаю, як вони це реалізують.

якщо ви плануєте використовувати знімки для створення резервних копій - будьте готові до головного хіта на продуктивність, коли знімок присутній. докладніше читайте тут . інакше все добре. Я використовую lvm у виробництві протягом декількох років на десятках серверів, хоча моя основна причина використовувати його - атомний знімок, а не здатність легко розширювати обсяги.

btw, якщо ви будете використовувати накопичувач 1 Тб, пам’ятайте про вирівнювання розділів - найімовірніше, цей накопичувач має фізичні сектори 4 кБ.

Адам,

Ще одна перевага: ви можете додати новий фізичний об'єм (PV), перемістити всі дані до цього PV і потім видалити старий PV без будь-яких перерв у службі. Я використовував цю здатність принаймні чотири рази за останні п’ять років.

Недолік, який я ще не бачив, чітко вказав: Існує дещо крута крива навчання для LVM2. Переважно в абстракції, яку він створює між вашими файлами та базовим носієм інформації. Якщо ви працюєте лише з кількома людьми, які діляться справами на наборі серверів, ви можете виявити додаткову складність для вашої команди в цілому. Більші команди, присвячені роботі з ІТ, зазвичай не матимуть такої проблеми.

Наприклад, ми широко використовуємо це тут у своїй роботі, і ми зайняли час, щоб навчити всю команду основам, мові та голим принципам відновлення систем, які не завантажуються належним чином.

Одне застереження, яке конкретно слід зазначити: якщо ви завантажуєтесь з логічного тома LVM2, ви ускладнили операції по відновленню, коли сервер виходить з ладу. Knoppix та друзі не завжди мають для цього потрібні речі. Отже, ми вирішили, що наш / завантажувальний каталог буде на власному розділі і завжди буде малим та рідним.

В цілому, я фанат LVM2.