Налаштування дискових квот для користувачів на сервері Linux

Дискові квоти: як один процес забиває сервер

Дискові квоти — це не «гігієна», а захист від конкретного класу аварій.

Достатньо одного процесу — збирача логів, кеш-агента, скрипта з увімкненим налагодженням або завислого вивантажувача звітів, — який пише в спільний розділ, і зайнятість диска починає зростати непомітно: графіки моніторингу виглядають рівно до моменту, коли вільного місця залишається на лічені хвилини.

Переповнення розділу б'є не по тому сервісу, який пише найбільше. Спочатку перестають зростати логи, тому причина не видна; потім зупиняються черги завдань і приймання даних, а після зупинки сервісу застосунок віддає помилки запису, хоча процес живий.

Діагностика розтягується вдвічі: спочатку треба звільнити місце, потім розібрати, хто і чим забив розділ.

Поріг на графіку «вільно менше десяти відсотків» не рятує: між повідомленням і заповненням розділу минає менше часу, ніж потрібно черговому на розбір. Квоти перевертають логіку — обмеження ставиться на конкретний обліковий запис або групу, окремо за обсягом і за кількістю inode.

Так роблять XFS і ext4: м'яка межа сигналить і дає запас часу на реакцію, жорстка просто не пускає запис далі, залишаючи розділ живим для інших.

Розбираємо, як це закривається: які ліміти ставити сервісним і людським обліковим записам, де проходить межа між квотами та ротацією, і що робити, коли ліміт уже досягнуто.

Що дає обмеження місця: вимірювані ефекти

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

Працює це на двох порогах: м'який ліміт із періодом відстрочки попереджає власника каталогу, жорсткий — блокує запис конкретному користувачу. Далі звіт про зайнятість у розрізі користувачів і каталогів та повідомлення, яке спрацьовує до того, як місце закінчилося. XFS тримає квоти на рівні проєктів — це зручно, коли бюджет потрібен не людині, а сервісу.

Ефект — не «порядок на диску», а керована відмова: застосунок отримує помилку запису на своєму ліміті, а не завалює вузол цілком. Вільне місце залишається в системи та в сервісів, які не повинні зупинятися, а зростання орендованого обсягу вирівнюється під реальне споживання.

Варіанти дискових квот: порівняння режимів і меж

Режими квот відрізняються не стільки граничним значенням, скільки реакцією системи на його досягнення.

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

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

Порядок впровадження: від аудиту до передачі регламенту

Порядок робіт вибудовуємо так, щоб пороги з'являлися з фактичної картини споживання, а не з розміру розділу. Кожен етап закінчується артефактом, який можна перевірити й передати черговій зміні.

1. Аудит зайнятості. Збираємо зріз за розділами та обліковими записами: де лежать великі дані, хто зростає швидше за інших, скільки займають журнали й тимчасові файли. Дивимося і обсяг, і кількість об'єктів: каталог з дрібних файлів вичерпає ресурс раніше, ніж закінчиться місце.

2. Схема розподілу. Розкладаємо розділи за призначенням: домашні каталоги, робочі дані, службові та тимчасові області. Для кожної групи вирішуємо, що обмежуємо — обсяг, кількість об'єктів або обидва параметри відразу.

3. Налаштування порогів. Задаємо м'яку та жорстку межу й пільговий період: м'яка попереджає й дає час прибрати зайве, жорстка припиняє запис. Базовий профіль поширюємо на нові облікові записи, послаблення — на складання й репозиторії з передбачуваним зростанням.

4. Перевірка спрацьовування. Тестуємо на окремому записі: на м'якій межі надходить попередження, на жорсткій запис зупиняється, а вже записані дані залишаються цілими.

5. Оповіщення та звітність. Звіт про перевищення й метрика вільного місця йдуть у систему спостереження — адміністратор дізнається про проблему з оповіщення, а не від сервісу, що впав.

6. Передача регламенту. Віддаємо схему розділів, значення порогів, порядок надання послаблень та інструкцію для чергового, включно зі зняттям обмеження під час відновлення з резервної копії.

Пороги правляться без перебудови розділів, тому ліміти переглядають точково, не повторюючи аудит цілком.

Комплект на виході: конфігурації, схеми та регламенти

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

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

• Конфігурації квот: опції монтування usrquota, grpquota або prjquota, значення м'якого й жорсткого лімітів, окремий поріг за інодами — готовими фрагментами під ваші файли налаштувань.
• Схема розміщення даних: що винесено на окремий том, де домашні каталоги, де тимчасові файли складань і логи, який ліміт діє на кожному розділі.
• Таблиця лімітів за ролями та групами: скільки виділено розробникам, сервісним обліковим записам, агентам складання та сховищу резервних копій — і чим обґрунтований кожен поріг.
• Регламент обслуговування: з якою періодичністю знімається звіт про зайнятість, як узгоджується зміна ліміту, за якої частки заповнення тома запускається розширення.
• Інструкція для чергових: покроковий розбір «на розділі закінчилося місце» — як за хвилини знайти споживача, тимчасово підняти поріг і повернути значення назад.
• Звіт про зайнятість: вивантаження за користувачами та групами з топом споживачів і динамікою, тим самим скриптом, що працює за розкладом.
• Набір скриптів і завдань: увімкнення квот, зняття звіту, повідомлення в разі перевищення м'якого порогу — у системі контролю версій, з історією правок.
• Порядок відкату: як зняти обмеження без втрати даних і що дивитися в журналах, якщо після увімкнення квот сервіс не піднявся.

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

Кейс: як зупинили безконтрольне зростання розділу

На одному з проєктів із високонавантаженим бекендом кореневий розділ і /var регулярно заходили за 90%: логи застосунків не ротувалися, каталоги складання накопичували артефакти, а налагоджувальні копії баз осідали в /tmp.

Черговий раз на тиждень шукав найбільших споживачів через du і чистив файли руками, але за кілька днів місце закінчувалося знову — зростання розділу було не разовим збоєм, а стійкою динамікою.

Що змінили: /var/log, /home, /srv і каталоги складання винесли на окремі томи та увімкнули квоти за користувачами й групами — м'який ліміт із відстрочкою на тиждень і жорстка стеля, після якої запис просто не проходить.

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

Ротацію логів прив'язали до розміру й терміну зберігання, у складальних каталогів з'явився таймер, що зносить артефакти старші за кілька днів, а збір метрик через Prometheus додав видимість за квотами: видно, хто підходить до ліміту, до того як це помітить користувач.

Повідомлення на 80% зайнятості з прогнозом за швидкістю зростання замінило реакцію на інцидент підготовкою до нього.

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

За того самого профілю навантаження розділ тримається на третину вільним, і відкат до попереднього стану вже не потрібен.

Що робити, якщо розділ уже заповнений і сервіси не стартують

Заповнений розділ сам по собі рідко завалює сервіс — відмова приходить через деталі: застосунок не може створити тимчасовий файл, дописати журнал або відкрити сокет, і сервіс не стартує з незрозумілим кодом повернення. Тому спочатку з'ясовуємо, що саме займає розділ, і лише потім чистимо.

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

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

Обмеження вмикаємо відразу після звільнення місця, у два пороги: м'який — попередження й запас часу на прибирання, жорсткий — зупинка запису. Ліміт ставимо і на обсяг, і на кількість файлів: каталог з безліччю дрібних файлів вичерпує розділ раніше, ніж за обсягом.

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

Технічні сумніви перед початком робіт

Квоти змінюють не стільки розмітку диска, скільки робочі звички: до впровадження вивантаження, журнали та проміжні копії писалися «як вийде», після — запис зупиняється при вичерпанні жорсткої межі.

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

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

Чи сумісно це з резервним копіюванням?

Копіювання від облікового запису суперкористувача лімітами не обмежується, тому повне резервування й відновлення проходять як звичайно. Перевіряємо інше: щоб знімки та вивантаження не йшли в квоту сервісного користувача й на цільовому сховищі залишався запас. Ці шляхи фіксуємо в політиці окремо.

Що із системними сервісами та винятками?

Пошта, база даних, журнали й вебсервер пишуть під своїми обліковими записами, і спільний ліміт для них — погана ідея: відмова запису в журналу обернеться втратою подій.

Такі записи виводимо в окрему політику: або підвищена межа, або квота вимкнена, а зростання каталогу контролюється моніторингом.

Чи можна відкотити, якщо політика заважає роботі?

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

Обговоримо завдання й повернемося з оцінкою та планом

Оцінка за дисковими квотами залежить від того, як влаштовано зберігання саме у вас: десь достатньо увімкнути квоти на наявному розділі, а десь потрібна перерозмітка й перехід без зупинки сервісів.

Опишіть поточну картину за серверами — повернемося з оцінкою та планом, де будуть схема розміщення лімітів, порядок робіт і строки впровадження.

Що корисно розповісти або надіслати:

• Схему розділів і точок монтування: де квоти вже увімкнено, а де місце витрачається безконтрольно.
• Перелік облікових записів і груп — ліміти призначаються групі, а не кожному користувачу вручну.
• Які сервіси пишуть на диск: домашні каталоги, пошта, резервні копії, робочі набори даних — щоб квота не зупинила потрібний процес.
• Що вже траплялося: переповнення розділу, відмова запису, простої — і як їх виявляли.
• Вимоги до контролю витрат: кому й на якому порозі надходить повідомлення, чи потрібен регулярний звіт.
• Допустиме вікно робіт: чи можна перемонтувати розділ або потрібно обійтися без зупинки сервісів.

Обговоримо завдання предметно: наші інженери зберуть схему квот з окремими порогами для груп, порядок впровадження — від однієї групи користувачів до всіх, і реалістичні строки. Після погодження плану приступаємо до робіт.