Налаштування XFS/ext4 файлових систем для продакшн-серверів

Чому налаштування XFS за замовчуванням обвалює запис на піках

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

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

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

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

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

Це і є та деградація введення-виведення, яку на графіках видно як «диск гальмує», хоча гальмує черга операцій запису, а не носій.

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

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

Що дає коректна розмітка та параметри монтування

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

В актуальних збірках Red Hat XFS вибрано за замовчуванням, але замовчування розраховані на «середнє» навантаження — під задачу їх уточнюють. Нижче — те, що ми перевіряємо на кожному продакшн-вузлі до введення в роботу.

• Вирівнювання початку тому й розділів за межами, які розуміє накопичувач: зникає режим «читання-виправлення-запис» на кожен блок, запис перестає бути в рази повільнішим за читання, а відгук не залежить від позиції даних.
• Резерв під метадані та розмір inode під час створення тому: місце під них не закінчується задовго до вичерпання самого тому — не доводиться зупиняти сервіс і переносити дані.
• Журналювання файлової системи: після відключення живлення відновлюється узгодженість метаданих, а відновлення зводиться до перегравання останніх транзакцій — секунди замість повної перевірки тому на десятки хвилин.
• Обсяг і кількість буферів журналу: сплески запису в години пік не шикуються в чергу — розкид часу відгуку звужується, а не зростає ступенями.
• noatime або relatime у параметрах монтування: знімає десятки тисяч зайвих оновлень метаданих на добу, накопичувач не пише те, що ніхто не читає.
• Черга введення-виведення під профіль навантаження: при змішаному потоці очікування запису скорочується, важкий бекап перестає затримувати транзакції.
• Регулярний fstrim і контроль заповнення: вільні блоки повертаються накопичувачу, деградація запису не настає раптово.
• Конфігурація розмітки та монтування в репозиторії: відновлення після збою сервера відтворюване, а не «з пам’яті інженера».

Порівняння підходів: варіант, застосовність, обмеження

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

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

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

Порядок робіт: від аудиту до передачі в експлуатацію

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

1. Аудит сховища. Знімаємо зайнятість томів, розподіл розмірів файлів, частку послідовного й випадкового запису, пікові вікна. На виході — профіль навантаження замість загальних слів про «багато дрібних файлів».
2. Схема розміщення даних. Розкладаємо дані по томах і точках монтування: окремо журнали й метадані, окремо гарячий запис, окремо архіви. Схема одразу показує, який розділ деградує першим.
3. Розрахунок параметрів файлової системи. Під цю схему задаємо розмір блока, режим журналювання, ліміти inode та опції монтування. Кожен пункт пояснюємо: що він дає і чим ми за нього платимо.
4. Навантажувальні випробування диска. Проганяємо синтетику й повтор реального профілю: дивимося затримки та пропускну здатність на довгому інтервалі, а не на сплеску за хвилину.
5. Перевірка відмовостійкості. Імітуємо відмову диска, обрив, переповнення тому й втрату живлення, потім — відновлення та перевірку цілісності. Фіксуємо час простою й обсяг даних, які піднімаються з резерву.
6. Переведення в продакшн. Застосовуємо поетапно, з вікном обслуговування та планом повернення: якщо метрики виходять за межі, відкочуємося на попередню конфігурацію без втрати даних.
7. Передача в експлуатацію. Віддаємо документацію, карту розміщення, пороги моніторингу та регламент на типові збої; залишаємося на зв’язку, поки ваша команда не проведе першу планову операцію сама.

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

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

• Конфігурація монтування — робочі файли для кожного сервера з поясненням опцій рядок за рядком: чому ввімкнено noatime, чим обґрунтований discard на накопичувачах, де усвідомлено залишено режим журналювання за замовчуванням.
• Схема розділів і томів — карта дисків, розділів і точок монтування з вирівнюванням за межами блоків і зарезервованим місцем під зростання.
• Політики доступу до даних — власники й права на каталоги застосунків і журналів, окремі облікові записи сервісів замість роботи від суперкористувача.
• Інструкція з розширення тому — покроковий порядок: додати ємність, збільшити логічний том, потім розширити файлову систему на ходу (xfs_growfs або resize2fs) без зупинки сервісу.
• Регламент обслуговування сервера — періодичність контролю заповнення, пороги оповіщень, вікна планових перевірок цілісності та порядок дій при збої живлення.
• Порядок відновлення — що робити при пошкодженні метаданих, як розгортати з резервної копії та як переконатися, що дані цілі після.
• Журнал змін — кожна правка конфігурації з причиною та способом відкату.

Кейс: усунення деградації запису на файловому сервері

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

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

Метрики знімали в Prometheus — глибину черги введення-виведення, час очікування запису та час відновлення.

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

Що змінили

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

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

Метрики до і після

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

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

Налаштування XFS чи ext4: що вибрати під поточне навантаження?

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

Вибір файлової системи йде не за «новіше чи старіше», а за профілем введення-виведення: середній розмір файлу, частка випадкового доступу проти послідовного, кількість одночасних записувачів.

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

Класична схема з журналом упевнено закриває веб-вузли та службові сервіси, а том за потреби зменшується без перестворення.

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

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

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

Технічні сумніви: сумісність, ризики та відкат

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

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

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

Як відкочуються зміни, якщо щось піде не так?

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

Що змінюється для резервного копіювання?

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

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

Як перевіряєте цілісність даних після перенесення?

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

Як почати: що уточнити і в якому порядку рухатися

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

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

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

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

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